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