Mathematica does it correctly. How is another question.
But I guess the idea is to pass it through some kind of database of
exact solutions then optionally evaluate it.
Mathematica is very good at that (symbolic stuff)
>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 3/1/00, 4:40:35 PM, "Zow" Terry Brugger <zow@pensive.llnl.gov> wrote
regarding [Numpy-discussion] Derivatives (fwd):
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
Hassan,
This seemed relevant to pass back to the numeric list - hope you
don't mind.
My comments follow.
- ------- Forwarded Message
Date: Wed, 01 Mar 2000 19:46:42 +0000
From: Hassan Aurag <aurag@crm.umontreal.ca>
To: zow@llnl.gov, Gmath-devel@lists.sourceforge.net
Subject: Re: [Gmath-devel] Re: [Numpy-discussion] Derivatives
I have to agree with you on most counts that Numerical Recipes in
C=20
is not a full-blown encyclopedia on all subtleties of doing
numerical=20
computations.
However it does its job greatly for a big class of stuff I am=20
interested in: minimization, non-linear system of equations solving=20
(The newton routine given there is good, accurate and fast.)
There are errors and problems as in most other numerical books. In=20
truth, I don't think there is anything fully correct out there.
When trying to make computations you have to do a lot of testing
and=20
a lot of thought even if the algorithm seems perfect. That applies
to=20
all books, recipes et al.
I have just discovered that tan(pi/2) =3D 1.63317787284e+16 in=20
numerical python. And we all know this is bad. It should be
infinity=20
period. We should define a symbol called infinity and put the
correct=20
definition of tan, sin .... for all known angles then interpolate
if=20
needed for the rest, or whatever is used to actually compute those
thing=
s.
Peace
<snip>
- ------- End of Forwarded Message
I believe you're actually talking about the math module, not the
numeric
module (I'm not aware of tan or pi definitions in numeric, but I
haven't
bothered to double check that). Never the less, I think it has
relevance here
as Numeric is all about doing serious number crunching. This problem
is caused
by the lack of infinite precision in python. Of course, how is it even
possible to perform infinite precision on non-rational numbers?
The obvious solution is to allow the routine (tan() in this case) to
recognize
named constants that have relevance in their domain (pi in this case).
This
would fix the problem:
math.tan(math.pi) = -1.22460635382e-16
but it still doesn't solve your problem because the named constant
would have
the mathematical operation performed on it before it's passed into the
function, ruining whatever intimate knowledge of the given named
constant that
routine has.
Perhaps you could get the routine to recognize rational math on named
constants (the problem with that solution is how do you not burden
other
routines with the knowledge of how to process that expression).
Assuming you
had that, even for your example, should the answer be positive or
negative
infinity?
Another obvious solution is just to assume that any floating point
overflow is
infinity and any underflow is zero. This obviously won't work because
some
asymptotic functions (say 1/x^3) will overflow or underflow at values
for x
for which the correct answer is not properly infinity or zero.
It is interesting to note that Matlab's behaviour is the same as
Python's,
which would indicate to me that there's not some easy solution to this
problem
that Guido et. al. overlooked. I haven't really researched the problem
at all
(although now I'm interested), but I'd be interested if anyone has a
proposal
for (or reference to) how this problem can be solved in a general
purpose
programming language at all (as there exists the distinct possibility
that it
can not be done in Python without breaking backwards compatibility).
Terry
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv
iQA/AwUBOL2OUqfuGVwXgOQkEQJTpQCggOuFT2ZVavzMhy+jZgoehnrK5uIAoMzO
D5OOdLtBvT97ee7vkckO+0Qt
=SmqL
-----END PGP SIGNATURE-----
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/numpy-discussion
Hassan Aurag
Zow Terry Brugger