Re: Why Mathematica does not issue a warning when the calculations
- To: mathgroup at smc.vnet.net
- Subject: [mg117672] Re: Why Mathematica does not issue a warning when the calculations
- From: Daniel Lichtblau <danl at wolfram.com>
- Date: Tue, 29 Mar 2011 06:57:51 -0500 (EST)
----- Original Message -----
> From: "Richard Fateman" <fateman at eecs.berkeley.edu>
> To: "Daniel Lichtblau" <danl at wolfram.com>
> Cc: "Richard Fateman" <fateman at cs.berkeley.edu>, mathgroup at smc.vnet.net
> Sent: Monday, March 28, 2011 11:32:41 PM
> Subject: Re: [mg117570] Re: Why Mathematica does not issue a warning when the calculations
> On 3/28/2011 4:36 PM, Daniel Lichtblau wrote:
> > Richard Fateman wrote:
> >
> > (DL)
> >> [...] If this is not deemed to qualify as
> >>> the type of situation you describe [...]
> >>> , then the more direct variant below will certainly suffice.
> >>>
> >>> In[36]:= b1 = With[{prec=10},
> >>> Block[{$MinPrecision=prec,$MaxPrecision=prec},
> >>> SetPrecision[-251942729309018542,prec] + (6 + Sqrt[2])^20]]
> >>> Out[36]= 0.6619679453
> >>>
> >>> In[37]:= b2 = With[{prec},
> >>> Block[{$MinPrecision=prec,$MaxPrecision=prec},
> >>> SetPrecision[-251942729309018542,prec] + (6 + Sqrt[2])^20]]
> >>> Out[37]= 0.68777820337396297032
> >>>
> >>> In[38]:= b1 == b2
> >>> Out[38]= False
> >>>
> >>> This is truncation at work, behind the scenes.
> >
> > (RJF)
> >> Again, these are two different functions, and there is no reason
> >> for
> >> them to result in the same answer.
> >
> > Heh. This is quite not the case (and I don't mean "not quite"...)
> >
> > The function being applied is
> >
> > f(x) = x + (6 + Sqrt[2])^20
> It is clearly not the function being applied in either case, as a
> simple
> perusal of the text shows.
Not sure what you think it is. Anyone reasonably familiar with Mathematica
bigfloat numerics will recognize it as a fixed precision evaluation of
exactly that function. If you translate it to other programs it
will be even more obviously just that(no With...Block... to
sow confusion).
I cannot tell if you are simply not understanding the code, or
intentionally making up junk. I'm not even sure which would be
the more charitable assumption, given your professional background.
One can perhaps understand my frustration, given that you have me
trying to nail jello to a wall.
(DL)
> > The inputs are both equal to -251942729309018542
> >
> > In[2]:= SetPrecision[-251942729309018542,10] ==
> > SetPrecision[-251942729309018542,20]
> > Out[2]= True
> Actually, they are "==" when you test in Mathematica, but they are not
> the same, as you can see by running them through InputForm.
No argument. But your claims were in regard to "equal" values, in the sense
of mathematics. Not "same" values in the sense of inner representation.
> Call them a and b, resp. to precision 10 and 20.
> So for a start, they are distinguishable. Indeed, let p= a-b. p==
> 0``-7.401301829825771, whatever. Now you may say that p is equal to
> zero, because Mathematica also says p==0. but if it is, it is
> certainly
> a strange zero. The USUAL zero has the property that 5+p==5. In this
> case, 5+p==p. Indeed, looking at the input forms it appears that
> InputForm[p] is character by character the same as InputForm[p+5].
> Oh, you might also be distressed to note that a==b, but also
> a==b+10^8. a===b+10^7, but not 10^8. whoa.
>
> But I digress. I shouldn't argue against this part of your argument,
> since clearly in Mathematica, a==b.
Right. Another reason would be that I already went on record as agreeing
the above has its peculiarities. Mind you, I do not think they are
especially "bad". Just peculiar.
(DL)
> > This is exactly the situation you had requested.
(RJF)
> OK, I agree. Mathematica's notion of == is such that these two items
> test equal. Indeed, since Mathematica appears to keep all the digits
> of this particular exact integer around, and just slosh the
> "precision"... they have the same digits, just that more or less of
> them are hidden.
While that is quite true, it is not pertinent to the fixed precision
evaluation I produced. In particular, you will see similar behavior
from trying the same evaluation in other programs.
> For example, Round[a] -- miraculously this 10 digit number rounds
> exactly to an 18 digit integer! Studying the properties of
> floating-point arithmetic using Mathematica would be quite a
> challenge.
No argument. It might be a chore, and indeed I doubt Mathematica
would be good for that purpose without serious care taken on the
part of the person writing the lectures (or whatever).
(RJF)
> On the other hand, not all digits of all numbers are kept around:
> Round[SetPrecision[100!,20]]-Round[SetPrecision[100!,10]] is not zero!
> But for 25!, it is.
>
> > I mention this in careful detail in case anyone is (a) still reading
> > this and (b) failing to see exactly how the example fits the bill.
> OK on (a) and (b).
> >
> > To be more specific, here is what you had earlier stated.
> >
> > "the fact that 2.0000==2.000000000 is True (etc) means that
> > a==b and both a and b are numbers, does not mean that f[a]==f[b] [in
> > Mathematica]. I view this as problematical, even if most people
> > don't
> > ever even notice it."
> OK, you provided an example that shows a == b, f[a]=!=f[b], in
> Mathematica.
I provided considerably more.
I showed that this happens with fixed precision. So you will
see it with other programs as well, provided they support an
equality test that allows for
lower precision bignum == higher precision bignum
I moreover showed that at least one such program has that
behavior.
> (though the two functions are different...) But your effort agrees
> with
> my point, that a==b does not mean f[a]==f[b] in Mathematica.
Or several other programs, I dare say. Did you try any of them
on the example I showed?
> So now we try to find another program that does the same thing;
> showing
> that Mathematica is not alone here.
> In fact you contend that ALL programming systems must do the same
> thing.
Not so. I contend that any program that claims 2.000==2.0000000
will do what I showed. Programs that do not support the above
equality are immune from this. But they probably also don't
get much usage. Frankly, any program with arbitrary precision
bigfloats that claims 2.0000!=2.0000000 is probably on some
scrap heap.
(DL)
> > You added shortly afterward:
> >
> > "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."
> >
> > What I showed was an example in which it would be violated by any
> > program, working in fixed precision arithmetic, that also claims
> > 2.0000==2.000000000. I suspect this applies to at least a few of the
> > programs that implement bigfloats. You might recognize one such
> > below.
> >
> > type(2.0000=2.000000000, 'equation' );
> > true
(RJF)
> OK, now this is a subtle point:
>
> it doesn't matter what program this is, because here is a program that
> says that two numbers of different (apparent) precision, or which are
> at least typed in differently, can be equal as values. I don't have a
> problem with that at all, and I don't see any issue since extending
> 2.0000 to more digits by adding zeros is the same. Or another way of
> doing this is to notice that both 2.0000 and 2.0000000 are exactly the
> same rational number, in fact the integer 2, and as such they are
> numerically equal.
>
> If, however, they are distinguishable, say, by checking the precision
> associated with the value, they are not the SAME. They are not
> identical.
True, and yet irrelevant, because...
> Consider the program in Mathematica, f[x_]:= N[Pi,Precision[x]].
> Clearly f[a] and f[b] will be different.
...Again I remind you that your original remarks, and request for
an example, were in reference to equality. If the issue is
one of "sameness", it even becomes more difficult to get
Mathematica to show the bad behavior. Also somewhat less important,
because equality testing is not usually done via SameQ.
That said, I agree Mathematica is a bit tricky in SameQ semantics with
regard to retaining of hidden guard bits and related matters.
> However you offer two different programs, one of which sets precision
> to 10, and the other to 20.
>
> >
> > Summary statement: What you wrote to indicate why my example does
> > not
> > qualify strikes me as elaborate gyration.
> OK, here is what I think SHOULD happen. I use a hypothetical computer
> algebra system that resembles Mathematica but not entirely...
> OK, here is what I think SHOULD happen. I use a hypothetical computer
> algebra system that resembles Mathematica but not entirely...
>
> exact= -251942729309018542;
> a=SetPrecision[exact, 10] --> answer is -2.519427293 * 10^17 or
> something very close to that in binary
> b=SetPrecision[exact, 20] --> answer is -2.5194272930901854200*10^17
>
> a-b --> convert both to longest precision and subtract.
Why does this make sense? You are manufacturing digits (which
happen to be zero) for the lower precision value. This will
do Really Bad Things if the underlying representation is
binary-based. In effect you'd be putting garbage right where
you are trying to avoid it.
I'm not sure that adding binary (as opposed to decimal) zeros
would be any better an idea, in this setting.
Anyway, this is your desired semantics so presumably you think
this behavior is fine. I raise the issues mostly to indicate why
I do not think it is such a good direction to take.
> Answer is
> -7.30704*10^5 NOT ZERO. By contrast, Mathematica effectively
> converts both to the SHORTEST precision and subtracts.
>
> a==exact is False. The number format for a doesn't represent all the
> digits in exact
> b==exact is True. The number format for b DOES represent all the
> digits.
> a==b is False. This maintains the transitivity of the
> mathematical equality relation.
>
> now define the function f[x,newprec]:= N[x+(6+sqrt(2))^20 ,newprec]
>
> f[b,n] == f[exact,n] FOR ALL n, because b==exact in this system.
This will in general not be achievable, if n is larger than the
precision of b. At least not with semantics that does comparison
by raising rather than lowering precision.
> f[a,n] =!=f[exact,n] except for n<10 or so. This function gives
> different answers for different input.
> f[a,n]=!= f[b,n] ditto.
>
> but now you say, what if I don't want to specify newprec? You have a
> few choices.
> For example, let newprec be the highest precision of any number in the
> expression.
> or newprec could be some global precision set outside f.
> or convert everything to hardware floats (ugh)
> [...]
(DL)
> > Okay...
> > Let me turn around the question. In the present statement of the
> > problem, when is Mathematica claiming
> > a==b, f(a)!=f(b), AND precision is the same for both?
(RJF)
> Because the precision is generally concealed from the user, most
> people
> don't take the extra effort to look for it.
> If a==b and their precision is the same or not, who would know?
>
> But since you ask, here is an example.
>
> r0000`5
> s0003`5
> f[x_]:=Round[x]
>
> note that Mathematica says r==s, and they both have the same
> precision,
> 5. (oh, r==s-13, as well)
>
> f[r] != f[s] is true. QED
Nice example. It shows a bit of pathology, which is to say it is in the gray area
between a Mathematica weak spot and programmer "error" (for not checking that
precision is insufficient for the task at hand. But you would be quite right to
point to such behavior as being unintuitive and hence posing trouble for the unwary.
(DL)
> > I think what you want is a different language...
(RJF)
> Or the same language with different semantics.
Which would be sufficiently alien to Mathematica as to make it a
different language.
Which in turn makes me wonder what is your fixation with mathematica, since you
yourself so clearly do not like the numeric behavior, and other programs
actually support more closely the behavior you do like. Academic exercise?
I'd be more charitably disposed, had you simply recognized from the
beginning that my example met your request. This could be either by
explicit statement, or implicitly by just dropping the matter. Nailing
jello is not what I want to be doing just after having done my taxes.
Also it rather removes this from any semblence of scholarly
discussion--brings it closer to an "is too" "is not" level. That what
you really want in your discourse?
Daniel Lichtblau
Wolfram Research