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

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

```On 3/30/2011 4:20 PM, Daniel Lichtblau wrote:
>> (RJF) People of a certain sophistication will realize that not all
>> decimal numbers have exact binary representations. Just [as] the
>> fraction 1/3 does not have an exact decimal representation.  We must
>> live with some version of this radix stuff and hope we can explain it
>> when necessary.
>
> (DL) Yes, but...I will surmise that any program using binary
> representation and decimal input will exhibit the pathology my example
> purported to show.
I think this pathology is unrelated to the question of   a==b  but f(a)
!= f(b), because in this example a==b is false.

In brief,
I think you are actually converting a string that looks like a decimal
number by treating it first like it is a base-60 number, and writing it
out in binary, and then taking that string converting it to decimal.
Somehow the underlying system is tricked into thinking two different
numbers are the same, perhaps because it is not programmed to handle
base 60 in the first place.

>
> For a specific example, I can get the bad behavior by round-trip
> conversion to-from binary.
>
> > Digits := 30:
> > f := x -> evalf(convert(x,decimal,2) - (6 + sqrt(2))20/106):
this function includes a conversion of the binary number x into
decimal.  Thus convert(0.1,decimal, 2) returns 0.5 [decimal] because
0.1[binary]= 0.5 [decimal].

Converting a number like 0.5, which is not on the face of it a binary
number at all, into decimal, produces 2.5 [decimal], so it is apparently
taking the place value of 1/2, and multiplying it by 5, and getting 2.5.

This system distinguishes commands typed on the top level from
programmatic evaluation.

> > v15 := convert(evalf[15](251942729309.018542),binary,60):
> > v30 := convert(evalf[30](251942729309.018542),binary,60):
> > evalb(v15=v30);
>                                      true
hm... set b15:= evalf[15](251942729309.018542)
and   set b30:= evalf[30](251942729309.018542).
now write a function qq:= x-> convert(x,binary,60).
apply it by  qq(b15).
oops, this system does not allow conversion of base 60 numbers, and
gives an error message unless  the base is between 2 and 36.
So how did DL's example actually work, since he apparently uttered
something illegal. And apparently produced objects that compared equal
when they were not.  Perhaps an error compounding an error??

how is it possible to produce v15 and v30, much less test to see if they
are equal?

note that if we do not use 60 for the base, for every base between 2 and
36 inclusive,  v15 and v30 are different.

>
> > val15 := f(v15);
>                          val15 := 0.000457127208979235
>
> > val30 := f(v30);
>                                                     -6
>                          val30 := -0.874881474866 10
>
> > evalb(val2=val3);
>                                      false
> A bit contorted, I admit.
I suspect that this relies on (a) violating the conditions on the
command "convert" and somehow bypassing the check,  by evaluating the
command "at the top level"  rather than programmatically, step by step.
And then (b) taking the result which is perhaps an illegal object, and
operating further with it.

> Mayber outside the scope of general usage. But it serves to show
> specifically that starting with decimal and having binary under the
> hood will not, in general, play nice with silent appending of zeros,
> whether digits or bits, past the last significant figure to the right