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

Re: Re: Re: odd mathematica blindspot

• To: mathgroup at smc.vnet.net
• Subject: [mg56570] Re: [mg56548] Re: [mg56502] Re: odd mathematica blindspot
• From: Daniel Lichtblau <danl at wolfram.com>
• Date: Fri, 29 Apr 2005 03:20:34 -0400 (EDT)
• References: <d4klbs$eg7$1@smc.vnet.net> <200504270153.VAA01785@smc.vnet.net> <200504280640.CAA24722@smc.vnet.net>
• Sender: owner-wri-mathgroup at wolfram.com

Edward Peschko wrote:
> From: Edward Peschko <esp5 at pge.com>
To: mathgroup at smc.vnet.net
> Bcc: 
> Subject: [mg56570] [mg56548] Re: [mg56502] Re: odd mathematica blindspot
> Reply-To: 
> 
> On Tue, Apr 26, 2005 at 09:53:49PM -0400, Skirmantas wrote:
> 
>>Hi Ed,
>>
>>By definition, 9999999999999/10000000000000 is an exact rational number, whereas 0.5 is an approximate real number:
> 
> 
> Well, that's completely unintuitive..  I understand it, but it still rubs me the 
> wrong way for some reason. '.5' on paper means that to me - .5 - not .4999999999
> or .50000000001 or whatever internal representation the computer chooses.

That's the key: what does it mean to the software or hardware?

As a machine number it means a base 2 representation. No harm thus far, 
because .5 can be exactly represented in base 2. But it also means that 
further numeric manipulation might be done using machine arithmetic.

I'll try to point out the source of the trouble in the example that 
failed. It was

Solve[(9999999999999/10000000000000)^x == .5, x]

An intermediate step involved computing

Log[9999999999999/10000000000000, .5]

The problem is that the first argument is very close to 1, and the 
presence of .5 coerces the entire computation to machine arithmetic, so 
se get a result that suffers quite a bit (quite a few bits) from 
cencellation error. Why? Because we had to compute

Log[N[9999999999999/10000000000000]]

This is only valid to about three decimal places. When we use the result 
in Solve, it is discarded in the verification process because the 
residual is deemed too large. You can see the result if you do

Solve[..., VerifySolutions->False]

There are ways to work around this. For example, you might use exact or 
higher precision inputs. I'm looking into the possibility of having 
Solve convert explicitly to rationals when it is working with 
transcendental equations. This ploy certainly will address your 
particular example but I cannot guarantee we will go this route, because 
it has the potential to break more than it fixes.


> In fact, 
> that's why I got Mathematica in the first place, to get away from this approximate
> stuff.
> 
> Why couldn't mathematica treat .5 as a string, make the internal calculation 
> and turn .5 into 5/10? Or, barring that, is there a conversion function for this 
> (going back and forth between rational and approximate real?
> 
> Ed

You might want to read up on the basic evaluation semantics of 
Mathematica. It has a parser, as do all programming languages. It does 
not convert numbers to strings (quite the contrary). If you want to do 
that you use the function ToString[...]. If you want to numeric inputs 
to be made into fractions you can use Rationalize[...,0] (the second 
argument is a tolerance which says, in effect, to rationalize everything 
no matter how bad the approximation may be).

Needless to say, if your intent is to sue exact arithmetic, by all means 
you can do so. Just don't expect the program to convert approximate 
numbers for you unless you ask it to.


Daniel Lichtblau
Wolfram Research

• References:
  • Re: odd mathematica blindspot
    • From: Skirmantas <skirmantas.janusonis@yale.edu>
  • Re: Re: odd mathematica blindspot
    • From: Edward Peschko <esp5@pge.com>