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

Re: Puzzled by IntegerPart

• To: mathgroup at smc.vnet.net
• Subject: [mg114741] Re: Puzzled by IntegerPart
• From: Joseph Gwinn <joegwinn at comcast.net>
• Date: Tue, 14 Dec 2010 06:58:51 -0500 (EST)
• References: <ie4mqh$94v$1@smc.vnet.net>

In article <ie4mqh$94v$1 at smc.vnet.net>,
 Daniel Lichtblau <danl at wolfram.com> wrote:

> ----- 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:  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...

I struggled with just this problem when computing divisors and results 
for a 48-bit DDS (direct digital synthesis) waveform generator chip.  

There was no difficulty to compute the digits, but I could not get Mathematica 
to print enough digits.  In my flailing around trying various 
approaches, nowhere was MachineRealPrintPrecision mentioned, a key 
omission in the online documentation.  

If memory serves, Tech Support didn't know of this either.

I just searched the Documentation Center for MachineRealPrintPrecision - 
no hit, so this is an undocumented option.

It would seem that this option should be documented, and references in 
all relevant functions and options.  


Joe Gwinn