[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
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**
| |