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: <email@example.com>
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:= "MachineRealPrintPrecision" /. SystemOptions
> Out= 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
> 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.
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