       Re: Why Mathematica does not issue a warning when the calculations

• To: mathgroup at smc.vnet.net
• Subject: [mg117632] Re: Why Mathematica does not issue a warning when the calculations
• From: Richard Fateman <fateman at eecs.berkeley.edu>
• Date: Tue, 29 Mar 2011 06:50:26 -0500 (EST)

```On 3/25/2011 8:33 AM, Daniel Lichtblau wrote:
... snip
>
>> (RJF)We've discussed this before. If you have a true function f, that
>> is a procedure whose results depend only on its argument(s), then when
>> A is equal to B, f(A) should be
>> equal to f(B). This is fundamental to programming and to mathematics,
>> but is violated by Mathematica.
> Probably by other mathematical programming languages as well. Especially in the operating world of finite precision arithmetic. It's something people often get used to (of necessity, if you work on this stuff).
I disagree that this is a common problem, although it would probably not be
allowed to discuss particular other mathematical programming languages
in this forum.
So far as I can tell, it has nothing to do with finite precision
arithmetic unless you
have some notion that "equality" means something like "close enough for
government work".

In Mathematica  there are two kinds of equality:  ==  and === . The
latter means IDENTICAL.
Consider a=SetPrecision[2,40]    b=SetPrecision[2,50].   I could
sympathize with  a==b  being
true, but certainly not a===b, which says they are IDENTICAL, and in my
book, f[a] must equal
f[b] for all functions f.  Yet let f=Precision, and you see we get

2.000000000000000001000 == 2  is False, but
2.00000000000000000100  == 2  is True.

Such rules of the road lead to situations in which a==b  but a-b is not
zero,

... snip...
>> This is not the understanding in Mathematica, where (for software
>> bigfloats)
>> 2.000000000000000000 is more like shorthand for
>> "all numbers between
>> 1.9999999999999999995
>> 2.0000000000000000005
>> "
>> (DL may be willing and able to explain what Mathematica REALLY does)
> Somethin along the lines you suggest. Your alternative approach is fine for handling of integers. It does not work so well for inputs such as 1.3 which do not translate exactly to finite binary representations. But Mathematica semantics would still be violated by upping precision, and that in no way contradicts the documentation remarks about ratcheting precision internally, as they refer to handling of exact input (N[2,10] et al are not exact, and they are what FractionalPart sees).
The simplest way of having consistent mathematical semantics in a
programming language is to  have the programming language obey the rules
of mathematical semantics.  Each step away from this, as imposed by the
reality of finiteness of computers etc, tends to add hazards.
That's why floating-point arithmetic is cluttered with
underflow/overflow/rounding  etc, that does not occur with rational
arithmetic.
There has to be a tradeoff in utility vs deviation from mathematics for
each such step. In my view
Mathematica adds more steps and therefore more hazards.

> I think there may be some since then. No matter. We find it works well for what we need.
apparentlyy
>   Your view, roughly, is that we picked it up off the garbage heap of numerics literature.
no, I speculate that Wolfram took the idea that is taught in Physics 101
lab about carrying significant figures when you are combining
measurements, and thought that it would be a great idea to put this into
a programming language.  He might even have thought that he invented it.
(That is, a programming language with significance arithmetic).  I truly
doubt that Wolfram studied any serious numerical analysis literature,
and I would certainly not expect him to study its garbage heap :)
>   Perhaps so. In all the conferences I've attended, I've only once heard it disparaged  (not derided, but disparaged) as a bad method.
For disparagement, one need not look any further than the wikipedia
article, at least last time I looked.
>   More below. Anyway, it may be helpful to bear in mind that (unlike these endless threads), this usage is not academic to us. We rely on it for those other things, like putting kids through school. Maybe the folks who shied away from it in the literature had similar considerations? That would make for a humerous rift between theory and practice...
Tempting, but I will refrain.
>
>> I thought you were claiming that Mathematica had the
>> lion's share of bigfloat usage.
> No. Though I suspect it does, once you get past the 200 digit mark or so.
Past the 200 (decimal) digit mark, I think most usage would be in trying
to prove/disprove number-theory conjectures,
though there are some poorly formulated geometry problems that might
require this. Unless Mathematica gives really
direct access to libraries, it would not be a good choice.  But I think
it (eventually) calls GMP and such.

>   This is to exclude the slightly high precision scientific computational apps, and those possibly ubiquitous cryptography apps, which will dominate any usage of Mathematica. (Caveat: with emergence of Wolfram|Alpha, this could change. Though I doubt W|A gets tremendous high precision usage at this time).
>
>
>>> It is fairly obvious that nobody knows the extent to which bignum
>>> arithmetic is used, either within or outside of Mathematica. My
>>> claim is that those who use it in Mathematica seem to get along with
>>> it.
>> Except for the ones who post those annoying questions here:)
> I'm not sure your plural is justified. Certainly the original post in this thread was about a limitation of machine arithmetic functionality. One that, I might add, is readily overcome with Mathematica's bignum arithmetic semantics.
>
OK, if we are going to talk about the original post, the answer looks
absurd.
To remind the patient readers, if there are any left..
N[FractionalPart[(6 + Sqrt)20]]

Result:

-160.   (Though I get -64).

Why  does this appear  absurd?  For a starter, that expression is
non-negative, so the fractional part of it
would have to be non-negative.  Next, the fractional part p would have
to obey the relation
0<=p<1.0

So the answer -160 is crazy, and FractionalPart would seem to be nonsense.
Actually, it is not total nonsense, just somewhat silly.  It is
apparently computed as

FractionPart[x]= x- IntegerPart[x]

where IntegerPart works pretty hard to work for arbitrary expressions,
in this case resulting in (6 + Sqrt)^20 - 251942729309018542 ,  which
is correct if  inconvenient.

now it appears that the next part of the computation  N[%] is the guilty
party, and that
it might say "uhoh,  there are too many digits there for me to do that
calculation
in hardware float without catastrophic loss of accuracy .."  but instead
of saying
that, it just burps out an answer.  Doing N[%,3] invokes the software
floats and
indeed uses enough precision to get 3 digits right IN THE ANSWER, which is
nice. Clearly 3 digits internally is insufficient.

It seems to me that a cure for all this is to allow IntegerPart and
FractionPart
to operate only on explicit rational and float expressions.  Any float
expression
that has more digits to the left of the decimal (actually binary) point
than precision, is equal to a particular integer, and has zero
fractional part.

Among other advantages: the result can be explained.

...snip...
>> (RJF) My impression is that the actual primary use of Grobner basis
>> computations is to
>> write papers on Grobner basis computations, and the other "uses" are
>> "in principle" "demonstrations". This may have changed with a more
>> numerical
>> approach, however.
> Your impression is off insofar as industrial usage goes. For example, we use them in NSolve, exact equation solving, some polynomial algebra, and probably a few places I am forgetting.

You are right.  I should have expanded my statement to include ..
"primary use of Grobner basis
computations is to write papers AND PROGRAMS ...".
Unfortunately, including GB in "NSolve" (etc.)  does not, to me, really
represent an application of GB.
It represents a situation in which a well-intentioned programmer
presents an opportunity for
someone to use GB to solve a problem.  With luck the program may be
applied in simple
circumstances that permit a simple solution.
But a so-called application in "commutative algebra" does not represent
an application.  (Here, I am
perhaps going out on a limb saying that I won't count "an application to
pure mathematics"
as a true application.)

The rather extensive wikipedia article on the topic lists many many
applications, most of which are
of the type I do not count, or are of the form "in principle we could do
this with GB, and so it is
an application"  though in fact no one could ever realistically use GB
for it except on exceedingly
toy-like instances.  (Occasionally one can let a problem run for a very
long time if you only have
to solve it one time, as in some robotics problems.)

I have only limited personal experience with trying to use GB, on 2
kinds of problems, oil reservoir
simulation  and the inverse problem of imaging via CAT scan or similar.
A recent (2008)  PhD thesis
by M-LTorrente on Applications to the Oil Industry seems to show the
situation has not changed.
That is, casting a problem in terms of GB is unlikely to be a useful
step in realistically
solving that problem.  This does not prevent the writing of a paper
exploiting a vastly simplified formulation.

While the numbers may change somewhat, consider that you could solve a
problem characterized
by 6 or 10 parameters and 3 variables using GB. Increasing the number of
variables may
increase the computation cost exponentially.  In practice there will be
10,000 parameters and
200 variables.

I am not, incidentally, saying there is an alternative symbolic method
to replace GB that is much faster.
Instead, I am suggesting that if you can reframe and simplify your
question as a numerical procedure, you stand
a much better chance of getting a result.

As an analogy, one could ask for a factorization of a polynomial over an
algebraic number field, but
if all you need is an approximation of a root near a particular point,
maybe that is what you should ask for.

>   Not an academic exercise, those applications. Also starting to make inroads in hybrid polynomial algebra computation e.g handling of low precision inputs. Not yet sure if that will fly, though.
I remain skeptical.
>
>> Are you claiming that now people are buying Mathematica to run GB
>> computations?
>> And are you claiming furthermore this could only be done in
>> significance
>> arithmetic?
> Neither. And most definitely not the first.
Then I think we may agree on this.
> I am claiming that this is extremely useful for the "bigger picture" technology it enables, a few parts of which I noted just above. Whether people buy Mathemntica for that stuff I would not know. Pretty sure it does not hurt though.
>
I do not fault Mathematica's Solve program for eventually trying GB; if
people ask for all solutions to polynomial
systems.  I think a really good program would point out that what a user
asks for may not be what he
really wants, and enter into a dialog of some sort.

...snip..
> There are some issues with IEEE arithmetic, by the way. That too is a work in progress (I'm sure this is not news to Kahan).
There are certainly issues, many of which were probably raised in the
IEEE754 standards committee deliberations;
also there is a more recent standards committee for (non-binary -- in
particular decimal)  arithmetic.  Curiously
some of the issues there include cases in which people would prefer
results that are less accurate..

RJF

```

• Prev by Date: Re: Why Mathematica does not issue a warning when the calculations
• Next by Date: Re: how do I solve for this
• Previous by thread: Re: Why Mathematica does not issue a warning when the calculations
• Next by thread: Re: Why Mathematica does not issue a warning when the calculations