Re: [Numpy-discussion] Derivatives (fwd)

[Hassan A. <au...@cr...>]

 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 <zo...@pe...> 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 <au...@cr...>
> To:      zo...@ll..., Gma...@li...
> 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
> Num...@li...
> http://lists.sourceforge.net/mailman/listinfo/numpy-discussion