Re: Why Mathematica does not issue a warning when the calculations
- To: mathgroup at smc.vnet.net
- Subject: [mg117645] 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:52:46 -0500 (EST)
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.
>
> 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.
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.
>
> This is exactly the situation you had requested.
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.
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.
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.
(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.
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.
>
> 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
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.
Consider the program in Mathematica, f[x_]:= N[Pi,Precision[x]].
Clearly f[a] and f[b] will be different.
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...
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. 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.
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)
>
>
>> Fortran 77 has two (maybe more?) sine functions for different
>> precisions. Starting with an exact integer 2, you presumably get
>> different results for sin(1.0 * 2) and sin(1.0d0 * 2). The
>> intrinsic functions for different precisions are different. Perhaps
>> this is what you are getting at. If you call two different functions
>> "the same" then it would seem that you might get different answers on
>> inputs that are the same value (in Fortran or any other system).
>>
>> though the situation in Mathematica is kind of the reverse. That is,
>> you have a function, say s[x_,y_]:=x-y. It is not really a single
>> function of two arguments. Really it is a function of 4 arguments,
>>
>> s(x,y, Precision(x), Precision(y),
>>
>> and the result is computed by something like
>>
>> SetPrecision(RawSubtract(x,y),Min(prec1,prec2))
>>
>> Calling a function like this requires you to distinguish x and y if
>> they have different values or different precisions.
>> Mathematica hides the precision of numbers from the user during
>> ordinary arithmetic.
>
> I might buy this argument if it were significance arithmetic under
> discussion. But then you would not be using the argument, because it
> would go in the direction of your point, to wit, that
> a==b but f(a)!=f(b) is bad semantics.
I don't know what f77 does if you compare a single to a double float.
Perhaps a type error? I was able to find this
6) Do not compare arithmetic expressions of different types; type convert
explicitly.
at
http://www.slac.stanford.edu/BFROOT/www/Computing/Programming/Standards/F77_Style_Guide
>
> Since it is just fixed precisiona rithmetic being used, and
> evaluations are arithmetically the same, I don't buy it at all.
>
>
>>> (DL)
>>>>> Significance arithmetic might exacerbate this in different cases,
>>>>> but the issue is quite present with fixed precision.
>>>
>>> (RJF)
>>>> Maybe an example here of another language or system where this
>>>> issue occurs would help?
>>>
>>> The above behavior will manifest in any program that uses fixed
>>> precision and supports bigfloats.
>> If you change the precision the function is different.
>
> 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?
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
> I am sure such examples exist. Not so sure significance arithmetic
> will play a fundamental role, though.
I don't know if the above example constitutes any significance
arithmetic or not.
... snip..
> I think what you want is a different language...
Or the same language with different semantics.
RJF