[Numpy-discussion] Derivatives (fwd)
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
> This seemed relevant to pass back to the numeric list - hope you
> 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
> is not a full-blown encyclopedia on all subtleties of doing
> 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
> a lot of thought even if the algorithm seems perfect. That applies
> 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
> period. We should define a symbol called infinity and put the
> definition of tan, sin .... for all known angles then interpolate
> needed for the rest, or whatever is used to actually compute those
> - ------- End of Forwarded Message
> I believe you're actually talking about the math module, not the
> module (I'm not aware of tan or pi definitions in numeric, but I
> bothered to double check that). Never the less, I think it has
> as Numeric is all about doing serious number crunching. This problem
> 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
> named constants that have relevance in their domain (pi in this case).
> would fix the problem:
> math.tan(math.pi) = -1.22460635382e-16
> but it still doesn't solve your problem because the named constant
> the mathematical operation performed on it before it's passed into the
> function, ruining whatever intimate knowledge of the given named
> 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
> routines with the knowledge of how to process that expression).
> had that, even for your example, should the answer be positive or
> Another obvious solution is just to assume that any floating point
> infinity and any underflow is zero. This obviously won't work because
> asymptotic functions (say 1/x^3) will overflow or underflow at values
> for which the correct answer is not properly infinity or zero.
> It is interesting to note that Matlab's behaviour is the same as
> which would indicate to me that there's not some easy solution to this
> that Guido et. al. overlooked. I haven't really researched the problem
> (although now I'm interested), but I'd be interested if anyone has a
> for (or reference to) how this problem can be solved in a general
> programming language at all (as there exists the distinct possibility
> can not be done in Python without breaking backwards compatibility).
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 5.0i for non-commercial use
> Charset: noconv
> -----END PGP SIGNATURE-----
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
More information about the Numpy-discussion