On Thu, Apr 08, 2021 at 11:05:45AM -0700, Tobias Neumann wrote:
> I'm sure there are tons of these implementations available, but here's
> another one
> (one that I also use in production):
>
> https://www.netlib.org/amos/ https://dl.acm.org/doi/10.1145/7921.214331
> The paper gives a nice visual presentation of which method is used in which
> region.
> It's quite complicated indeed.
It is one of "good loking" that I mentioned. It should be
fine when you are satisfied with real p (it suppors complex x).
But we need complex p.
> What is your policy on integrating such functions in FriCAS? Only native
> SPAD
> implementations, or are interfaces to C/Fortran OK? Consequently, is
> arbitrary precision a requirement
> or is double precision enough?
My policy is "never say never". It is pragmatic choice: how badly
we need given function, what is effort to reimplement compared to
resue etc. Having said that, up to now looking at various
factors in most cases my conclusion was to provide implementation
in Spad. Factors are:
- I am mostly looking at long time perspecitive, adding a
single function in moderate improvement and can wait
some time
- beside double precision version we would like to have multiple
precision one (not as absolute requirement, but strong
preference)
- eventually we would like to cover a lot of functions and
full range of arguments. For this it is natural to
modify/tweak existing code and Spad it preferable there
- one can use symbolic version to help create numeric one. One
can use multiple precision version to help develop double
precision one
- we would like not only code but also explanation why it
works
ATM we have a few functions that actual implementation
is multiple-precision only, double variant is just wrapper for
multiple precision. For elliptic functions we have separate
double precision version using popular Carlson method. And we
have multiple-precison version based on Gauss-Landen transforms.
There are still holes and bugs, but overall IMO it one of best
implementations available. Let me add there there is some
not entirely trivial math there to avoid errors. I have
somewhat rough (unfinished) paper describing the issue.
One reason that it is unfinished is that there are few things
to work out: there is still one corner case in ellipticPi that
should be handled (and currently remain unhadled) and few
uniplemented functions like Weirestrass Sigma and Jacobi Theta.
When finished we should have very good implementation with
explanation how this is done.
For Airy, Bessel and hypegometric F01 there is extra constraint:
we have existing code and new version should improve it
as opposed to regression. Since existing version is double
precision one, it is natural to improve double precision
version before providing multiple precision one. Actually,
the core isssue is similar in both cases: to have good
implementation we need to handle large complex arguments.
> Personally I would not mind having specialized C/Fortran codes like arb,
> flint etc. that are well packaged
> and self-contained included or optional in FriCAS. And with that,
> generally, some C/Fortran
> interfacing, even at the cost of supporting less Lisp implementations (I
> think in practice only ecl and sbcl work anyway?)
There is Closure CL, AFAIK it works fine. I do not know how
many FriCAS users buid it on top of Closure CL, but it is
quite good Lisp implementation. One higlight is precise
garbage collector: with sbcl (and probably ecl too) it can
happen that there is free memory but garbage collector can
not reclaim it and consequently one get "out of memory"
error. In practice when one get "out of memory" erorr
it is hard to tell exactly what is the reason. Theoretically
Closure CL should behave better in this case.
AFAICS Clisp works, but is least preferable due to performance.
Old GCL mostly works, but there is a bug not present when
using older implementations. Newest (git checkout) GCL
currently does not work.
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/20210408193323.GB27175%40math.uni.wroc.pl.
