This is all expected behavior. I'll try to explain each aspect, though most have been covered separately.
What is the quotient?
In[84]:= quot =104.91/4.035
(* Out[84]= 26. *)
Is it really 26.00... or not?
In[86]:= InputForm[quot]
(* Out[86]//InputForm=
25.999999999999996 *)
So no, it's not an "exact" twenty six point zero. Is this a bug in display of Out[85]
? No. Substantial work many years ago went into getting a "good" output form, one that is accurate to as many places as digits shown. 26. is the correct form, for showing up to 6 places. The fact that the actual result is a hair under 26 accounts for why IntegerPart
gives 25 (that much I would think is not controversial).
What about the comparison to the "equivalent" exact computation.
In[89]:= exactquot = 104910/4035
(* Out[89]= 26 *)
This actually is different, by an ULP from quot
as computed in machine arithmetic. But that computations was not wrong. The conversion from decimal to binary is lossy for all decimals not exactly representable in binary, and standard floating point arithmetic, as used in the Mathematica kernel, will be affected by that.
So why do (some) calculators get 26? This is due to use of BCD ("binary-coded decimal") arithmetic many use. It is not affected by lossy decimal-to-binary conversion, but is substantially slower than native machine arithmetic. More to the point, it is not used in Mathematica.
I hope this addresses some of the concerns raised above.