[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
Prev by Date:
**Re: Re: Using BarChart in a Widget**
Next by Date:
**Re: Re: Re: odd mathematica blindspot**
Previous by thread:
**Re: Re: odd mathematica blindspot**
Next by thread:
** Re: odd mathematica blindspot**
| |