MathGroup Archive 2010

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Puzzled by IntegerPart

  • To: mathgroup at smc.vnet.net
  • Subject: [mg114689] Re: Puzzled by IntegerPart
  • From: Daniel Lichtblau <danl at wolfram.com>
  • Date: Mon, 13 Dec 2010 03:51:43 -0500 (EST)

----- Original Message -----
> From: "Themis Matsoukas" <tmatsoukas at me.com>
> To: mathgroup at smc.vnet.net
> Sent: Sunday, December 12, 2010 4:40:49 AM
> Subject: [mg114655] Re: Puzzled by IntegerPart
> Round and Rational have solved the problem. But I am curious, why do
> the phantom decimals not show with N?
> 
> N[100*1.15, 20]
> 
> 115.
> 
> 
> Themis

There are several things happening here, not all what you perhaps expect.

(1) Hitting 100*1.15 with N[...,20] will do nothing. N will not raise precision, and 100*1.15 is at machine precision, which N regards as less than any bignum precision (even though $MachinePrecision is around 16, for purposes of N it is better regarded as -infinity).

(2) 1.15 can be accurately represented in machine arithmetic. The binary expansion is NOT exactly equal to decimal 1.15, but 1.15 is (I believe) the closest decimal that uses less than $MachinePrecision digits in its representation. When we multiply by 100 we get truncation error, and so 115.0 is no longer the closest decimal with $MachinePrecision or fewer digits to the binary value.

(3) StandardForm, OutputForm, and some others will attempt to give a short form of decimal that corresponds to a certain binary value (more on this in item 4). It might not be the closest but I think it is guaranteed to be within one ULP (or maybe a half an ULP) of that closest binary. InputForm and FullForm will indicate the actual value, up to the limitations of binary-to-decimal conversion. One can use RealDigits with base set to 2 in order to deduce actual bit settings.

(4) I believe the system option below might also influence this behavior.

In[1]:= "MachineRealPrintPrecision" /. SystemOptions[]
Out[1]= 6

The reason is that something like 1.1499999965525 should print as 1.15 since that is the most accurate decimal to print at only 6 digits. That is to say, my notion of ULP (specifically, of where the "last" place is located) might be influenced by this.

Unfortunately I cannot seem to get that system option to work at nondefault settings, so I may be spouting nonsense in this last point. Right now I think it is a matter of the Front End and Kernel not talking about this setting. Preferences > Option Inspector > Formatting Options > Display Options > Print Precision still claims 6. Changing it to 16 does seem to bear out the remarks above.

As to why we have two ways to influence that setting, only one of which works, I need to make enquiries...

Daniel Lichtblau
Wolfram Research




  • Prev by Date: Re: Question: Compile in Mathematica 8.0
  • Next by Date: LessEqual vs Inequality, was ..Re: Replacement Rule with Sqrt in
  • Previous by thread: Re: Puzzled by IntegerPart
  • Next by thread: Re: Puzzled by IntegerPart