Message Boards Message Boards

0
|
5686 Views
|
6 Replies
|
7 Total Likes
View groups...
Share
Share this post:

Unexpected result from IntegerPart

Posted 6 years ago

I recieved the below output from the this input

In[116]:= 104.91/4.035

IntegerPart[104.91/4.035]

Out[116]= 26.
Out[117]= 25

Two different integers from the same calculation. Why is IntegerPart acting this way?

POSTED BY: Dennis Lawler
6 Replies

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.

POSTED BY: Daniel Lichtblau

Dennis,

I would report this to Wolfram Tech support (and post their answer!) because

FullForm[104.91/4.035]

25.999999999999996`

and

In[599]:= $MachinePrecision

Out[599]= 15.9546

but

N[104.91/4.035, 15]

gives 26.

While it is a "quirk" in MMA, Gianluca is correct that you must guard against this when using IntegerPart because for various reasons when using floats MMA results are machine precision and so answers can be slightly off. You would see this behavior for certain operations in C when casting as an integer (which may be the origin of the problem??).

Regards,

Neil

POSTED BY: Neil Singer

IntegerPart is a notoriously discontinuous function, and you are calling it very close to a jump discontinuity. The output 26. is rounded to the nearest integer for display purposes.

POSTED BY: Gianluca Gorni

But the EXACT answer really is 26. No rounding is necessary at all. Any hand calculator will get it right. Doing it by hand makes it absolutely clear. But IntegerPart still screws up? Why exactly would that be?

POSTED BY: Dennis Lawler

But the EXACT answer really is 26. ...

Reals do not have "exact answers"! And $$26. \neq 26 $$

If you want exact results you should use rational numbers, e.g.:

enter image description here

POSTED BY: Henrik Schachner

Run this ...

ToBoxes[104.91/4.035]

It comes out to 25.9999...6. So when the IntegerPart is taken, it rounds down. I am not saying this is good behavior by the Kernel, but it gives you a hint about what is going on: the issue has to do with something to do with floating point computations. I suspect there are others in the Community who will be able to speak to this in greater depth.

POSTED BY: Seth Chandler
Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Reply Preview
Attachments
Remove
or Discard

Group Abstract Group Abstract