[Date Index]
[Thread Index]
[Author Index]
Re: Mathematica 20x slower than Java at arithmetic/special functions, is
*To*: mathgroup at smc.vnet.net
*Subject*: [mg115900] Re: Mathematica 20x slower than Java at arithmetic/special functions, is
*From*: AES <siegman at stanford.edu>
*Date*: Tue, 25 Jan 2011 04:20:41 -0500 (EST)
*References*: <ihiab8$m3b$1@smc.vnet.net> <ihjltm$t5p$1@smc.vnet.net>
Relevant to this thread -- maybe? (I'm not qualified to say)
Some years ago I was doing some optical beam modal expansions involving
numerical expansions of sums over Hermite-gaussian, Laguerre-gaussian,
and Legendre functions with indexes running from n=0 up to, in extreme
cases, n=60 or 70 -- just doing them as 'brute force' Mathematica
Sum[]s: no compiling (and no checking on timing).
In some cases I wanted to observe effects of small variations of
function arguments about special values like z = Pi, but without getting
diverted into any attempts at doing first order analytical perturbations
or expansions of the sums or their individual terms.
Soon became apparent that if I evaluated, say, a 64-term sum for
arguments z = 0.998 Pi, 0.999 Pi, Pi, 1.001 Pi, 1.002 Pi, I could see
obvious numerical round-off errors in the results.
But if I did the exact same calculations except writing the arguments as
z = 998 Pi/1000, 999 Pi/1000, Pi, 1001 Pi/1000, 1002 Pi/ 1000, I got
results that appeared to be accurate to the final digit in the results.
I assumed this meant that Mathematica detected these exact inputs, and
automatically switched to a (slower) exact arithmetical evaluation of
the terms in the series (??). In the cases at issue here, maybe
Mathematic does something similar -- and Java doesn't?
Prev by Date:
**Recursive function**
Next by Date:
**Re: adding a keyboard shortcut for double brackets**
Previous by thread:
**Re: Mathematica 20x slower than Java at arithmetic/special functions, is**
Next by thread:
**Re: Mathematica 20x slower than Java at arithmetic/special functions, is**
| |