[Numpy-discussion] Derivatives (fwd)
Hassan Aurag
aurag at crm.umontreal.ca
Wed Mar 1 21:19:10 CST 2000
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 at 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 at crm.umontreal.ca>
> To: zow at llnl.gov, Gmath-devel at 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 at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/numpy-discussion
More information about the Numpy-discussion
mailing list