MathGroup Archive 2011

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

Search the Archive

Re: CAS that uses convert/binary/decimal ..... / Retraction.

  • To: mathgroup at smc.vnet.net
  • Subject: [mg117840] Re: CAS that uses convert/binary/decimal ..... / Retraction.
  • From: Richard Fateman <fateman at eecs.berkeley.edu>
  • Date: Fri, 1 Apr 2011 02:34:50 -0500 (EST)
  • References: <4D949BCF.1050509@eecs.berkeley.edu> <4D94AAA4.6020802@eecs.berkeley.edu> <4D94C2F4.1090504@wolfram.com> <4D94FB7F.7060307@eecs.berkeley.edu>

I misunderstood the documentation for the "convert" function used by 
Dan.  I apologize for sowing confusion.
Dan DOES have an example for that other CAS that violates my suggested 
rule  a==b should imply f[a]==f[b].
Dan is right here.

In case you care, here's more info.



What does convert(120,binary, 8)  do??

  It takes decimal 10, and produces decimal 1111000.  If you look at 
that number slantwise as though it were a binary number, it has the same 
value as  120 [decimal]. , and has no more than 8 digits.

That number 1111000 is of course NOT a binary number, but a decimal 
number, masquerading. If you add 9 to it, you get 11110009.

Arghh.  I was looking at the documentation for convert(10, decimal, 8)  
where that 3rd argument is the RADIX not the number of digits!.

In this case, convert(120,decimal,8) returns the decimal number 80,   
since 120 [octal]  is 1*8^2+2*8 = 80 [decimal]. So my mistake here.

   Let me see if I can review my statements in the light of my new 
understanding!!

If you set the default number of (decimal) digits to be used in 
calculations to 30, you  indeed have
evalb(v15=v30)   is true
evalb(f(v15)=f(v30)) is false.   This is the situation I think is 
problematical and I challenged DL to find an example in another CAS. He 
found it.

However,

Digits:=50

evalb(v15=v30) is false.

This CAS erroneously (in my opinion)  considers as equal,  the two 
obviously distinct numbers v15 and v30
11101010101000111101001111011001011101.0000010011011101001011
11101010101000111101001111011001011101.0000010010111111001010
                                                  ^^^^^^^^^^^^
because they agree to 30 decimal digits,  if the default for comparisons 
is 30 digits. (oh, yes, they are
decimal numbers, even though they use exclusively the digits 0 and 1)

and it also considers the following two distinct f(*)  values
-2376566258299167.79880941334661
-2376566258299167.79926741543706
                     ^^^^^^^^^^^^
as different, since they are equal for only first 18 decimal digits, not 
30 digits.

One fix would be to set the default number of digits high enough, 
something that would be tricky to compute.
Another fix would be to replace any comparisons of software floats, at 
least those where the precisions differed, by a more elaborate test that 
checks ALL the digits.  Here is one:

floatSameQ :=(x,y)->evalb( evalf[max(length(x),length(y))] (x-y)=0)


in this case, regardless of the setting of Digits, the two numbers v15 
and v30 will be distinguishable by floatSameQ(v15,v30) unless they are 
indeed identical in every bit. This test also concludes that
5.0 from 5.00. Poking around in this CAS I am reminded of the difficulty 
in finding relevant tools in a system that is not used regularly.

Conclusion:  Dan DID find a flaw;  the test for equality was too lax. If 
equality-testing is done by "equal up to the number of default digits", 
this can happen.

There should be a simpler example if you are just allowed to increase or 
decrease precision, not involving "conversion to binary".





RJF











  • Prev by Date: Re: NonlinearFit for specific data
  • Next by Date: Re: why extending numbers by zeros instead of dropping precision is a good idea
  • Previous by thread: Re: Subject: Re: Rational[a,b] vs Rational[1,2]
  • Next by thread: Root Reduce