Re: How to increase Working Precision?

On Mar 10, 1:53 pm, "Richard J. Fateman" <fate...@xxxxxxxxxxxxxxxxx>
wrote:
Daniel Lichtblau wrote:

(Dave) I think we disagree on the big picture. I find
the above example to be a small annoyance in what
is a very large and generally outstanding system.
(RJF) A large system that messes up arithmetic?

(I think it was actually Mark M. who wrote that bit about the "big
picture".)


(DanL)Ummmm, that last would be an opinion, no? I really do not think you
have presented a case whereby everyone will automatically agree with
that assessment.

I don't get credit for letting "generally outstanding" slip by?

Yeah, you get some. That is to say, I agree with Mark that it is a
generally outstanding program, but also recognize I don't get to claim
that as a fact.


Why I think I am entitled to my opinion:

Certainly a system that provides a scientific library in which any
expression can be evaluated to any requested accuracy would be very nice.

Even a system that does this for many or "most" expressions would be
nice. (Mathematica, I think, claims to fit here)

For readers of this newsgroup who might not know the history of my
stated concern, let me point out that in Mathematica it is possible to
produce something that looks like 0. but acts quite strangely. This
object can be produced as the result of a long (or perhaps short)
computation, or you can create it directly by r=SetAccuracy[1.0,0].

r has the property that it prints as 0.
r has the property that r+1 also prints as 0.
r has the property that r+1 == r evaluates as True.
There are many more properties that anyone with a copy of the program
can explore. Like r is a solution to the equation sin(x)=cos(x).

It is too easy for a number like r to be produced by a naive user, or
even a sophisticated one who doesn't understand the arithmetic.

This raises some reasonable points.

I am happy and surprised to notice there are at least a few people
giving this thread some serious reading. So I thought I would say a
bit more about this issue you raise. For one, some people may be
unfamiliar with what you mean. I also think it would be useful to show
a bit of how this arithmetic is functioning (or disfunctioning,
depending on your take).

We'll go back to the example from a few notes ago.

http://groups.google.com/group/sci.math.symbolic/msg/e0b31cb1a4c085b2

I'll skip the interval computations and get to the main part. The gist
was to investigate the quotient of 10.065, with five digits "correct",
and 9.95, with three correct digits.

In[1]:= quot = 10.065`5/9.95`3;

In[2]:= {quot, InputForm[quot]}
Out[2]= {1.01, 1.0115577889447236183`2.9956786262173565}

To repeat from that other post, we have 1.01 to about three digits
precision. So what does this have to do with those zeros you mention?
Well, let's subtract various values that one might claim to be the
quotient, and thereby produce some zeros.

In[4]:= diff = quot-101/100;

In[5]:= {diff,InputForm[diff]}
-2
Out[5]= {0. 10 , 0.0015577889447236183`0.1831965451629747}

Is it really zero? Well, no, not quite. It printed as zero because it
is deemed to have too little precision to print otherwise
(specifically, what would one print? There is not enough precision to
be certain of even one digit.) Let's go for a "closer" approximation.

In[6]:= diff2 = quot-1011/1000;

In[7]:= {diff2,InputForm[diff2]}
-2
Out[7]= {0. 10 , 0``2.9906879277383736}

At this point we have no significant bits, just a zero to three digits
accuracy.

What about adding things and getting no change? Here is an example of
that. We'll add 1/1000, a value smaller than the accuracy of our zero,
and see that it remains zero.

In[13]:= sum1 = 1/1000+diff2;

In[14]:= {sum1,InputForm[sum1]}
-2
Out[14]= {0. 10 , 0``2.9906879277383736}

Whether this is good or bad behavior probably depends on ones
perspective. I think it is the right result.

Let's move up a bit. We'll add 1/100 to that zero.

In[16]:= {sum2,InputForm[sum2]}
-2
Out[16]= {0. 10 , 0.01`0.9906879277383746}

Still prints as a zero, but actually it seems to be 1/100, to almost
one digit of precision. Indeed, if we instead had added 1/99, we'd see
that digit printed without recourse to InputForm.

In[17]:= 1/99+diff2
Out[17]= 0.01

Me, I think it would have been better had sum2 printed like this. But
that is something of a formatting issue as opposed to a math issue.
What matters from the latter perspective is the underlying value, and
how it combines with other values in arithmetic. Let's add another
1/1000.

In[19]:= sum2plus = sum2+1/1000;

In[20]:= {sum2plus,InputForm[sum2plus]}
Out[20]= {0.01, 0.011`1.0320806128965996}

So we get that first digit printed in the default output format, and
we see that we have that last 1/1000 tucked away inside.

Now sum2, while formatted (in OutputForm) the same as diff2, is by no
means equal to it.

In[21]:= sum2==diff2
Out[21]= False

But it is deemed equal to sum2plus, because that last 1/1000 is not
appearing as significant.

In[22]:= sum2==sum2plus
Out[22]= True

To understand this in detail one would need to see the underlying
representation of the two values. NumericalMath`$NumberBits will give
us the lsit of "known" (or "good") bits, the bits we have stored but
that are not deemed significant ("bad" bits, or guard bits if you
prefer), and the exponent of the first significant bit. We see that
the two values that were deemed equal have the same good bits.

In[27]:= NumericalMath`$NumberBits[sum2]
Out[27]= {1, {1, 0, 1}, {0, 0, 0, 1, 1, 1, 1, 0, 1, 0, 1, 1, 1, 0, 0,
0, 0,
1, 0, 1, 0, 0, 0, 1, 1, 1, 1, 0, 1, 0, 1, 1, 1, 0, 0, 0, 0, 1, 0,
1, 0,
0, 0, 1, 1, 1, 1, 0, 1, 0, 1, 1, 1, 0, 0}, -6}

In[28]:= NumericalMath`$NumberBits[sum2plus]
Out[28]= {1, {1, 0, 1}, {1, 0, 1, 0, 0, 0, 0, 1, 1, 1, 0, 0, 1, 0, 1,
0, 1,
1, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 1, 0, 0, 1,
0, 0,
1, 1, 0, 1, 1, 1, 0, 1, 0, 0, 1, 1, 0, 0}, -6}

I will reiterate that I think this handling is all quite reasonable (I
realize we do not have consensus here); moreover I find it to be
fairly useful. Possibly all the more as Wolfram Research expands the
curated data collection introduced in version 6, since a significant
portion of it involves physical constants known only to modest
precision. That is to say, I think it is helpful to know when
computations with such values might have stopped being meaningful
because all precision was lost.

Daniel Lichtblau
Wolfram Research
.

Relevant Pages

  • Re: Singles to Doubles
    ... In internal promotion from lower precision to higher, there isn't any information as to what the missing decimal digits should be -- that they should be zero is only one of a large set of possible values. ... The way to force that in any modern language I'm familiar with is essentially what we've been discussing here...make a decimal representation that looks like the number you want and then let the i/o routines read that in, doing the hard work of converting its internal representation to match as closely as possible. ...
    (microsoft.public.vb.general.discussion)
  • Re: Calendrical centering
    ... Detonation of the first A-bomb July 16, ... That's a reason I like the end of the Younger Dryas as a zero point. ... Digital watches would need to carry 18 digits, ... Moreover, the setting of today's current time lacks a bit of precision, ...
    (talk.origins)
  • Re: Calendrical centering
    ... Detonation of the first A-bomb July 16, ... That's a reason I like the end of the Younger Dryas as a zero point. ... Digital watches would need to carry 18 digits, ... Moreover, the setting of today's current time lacks a bit of precision, ...
    (talk.origins)
  • Re: How do I stop Excel from changing last digit in a number entry?
    ... Excel can only show up to 15 digits of precision, ... changes the last digit to a zero. ...
    (microsoft.public.excel.newusers)
  • Re: float bug? perl 5.8, DBI and oracle 10.2.0
    ... precision numbers in oracle, you've got 38 decimal digits to play ... and with minimal coaxing perl will handle them as ... digits from a 32 bit floating point number - I'll go out on a limb ... and hazard that one can expect 12 or so digits from a 64 bit floating ...
    (perl.dbi.users)