|
From: | Robert T. Short |
Subject: | Re: improving special functions in GSoC 2017 |
Date: | Sun, 26 Jun 2016 14:05:59 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 |
On 06/25/2016 11:52 PM, John W. Eaton wrote:
There was some discussion of this a few years ago (something like 2011 or 2012). At the time Amos was still the best option that we could find. I don't remember all the details, but other libraries (including boost) didn't handle things like complex arguments or other some other crucial element. Hopefully things have changed since then, but that was the conclusion at that time. I was not able to find that thread so my memory is not refreshed. I put in a bunch of tests at the time we had the discussion. It seems, though, that I didn't do any for complex arguments. I have no clue how I missed that.On 06/26/2016 02:08 AM, Colin Macdonald wrote:On 25/06/16 02:54, Marco Caliari wrote:"Special functions are expected by users to just work".So I just found that our "besselj" gives NaNs for values like "1e10". >> besselj(1, 1e9) ans = -5.21042264155388e-06 >> besselj(1, 1e10) ans = NaN + NaNi https://savannah.gnu.org/bugs/index.php?48316 That's not some wild exotic function: its a common Bessel function! Why are we not just calling some free-licensed library that nails these things?Amos was the best thing I knew of at the time. If there is something better now, or a standard library solution, then perhaps we should be using it. Propose a patch and a test suite.jwe
I played around with python (scipy.special) a bit and didn't see any obvious issues so it might be worth looking at the library they use.
Bob
[Prev in Thread] | Current Thread | [Next in Thread] |