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