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>
- Re: odd mathematica blindspot