MathGroup Archive 2011

[Date Index] [Thread Index] [Author Index]

Search the Archive

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 
> of the radix.

Since the two input numbers are in fact different with every legitimate 
radix 2-36, I think you have encountered some bug, not a violation of 
the rule  a==b implies f(a)==f(b).

RJF


  • Prev by Date: Re: Mathematica 6.0.1 nb working, but not on Mathematica 8.0.1.
  • Next by Date: Re: read CSV
  • 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