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

```

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