I am going to respond to the comments below, since they come from a senior member of the symbolic computation community. I would have appreciated them a lot more if they were better informed, at least by reading the original project proposal also posted on this list [1], and intended as constructive criticism instead of just trolling.
[1] https://groups.google.com/forum/#!topic/sage-devel/00_Is5q_0IY On Wed, 29 May 2013 15:08:02 -0700 (PDT) rjf <fate...@gmail.com> wrote: > On Tuesday, May 28, 2013 5:46:13 AM UTC-7, Harald Schilly wrote: > > > > Mathematical Functions Library > > Eviatar Bach <http://www.phas.ubc.ca/%7Eeviatarb/> – University of > > British Columbia in Vancouver, Canada > > (Mentor: Flavia Stan, Backup: Burcin Erocal) > > > > Sage interfaces with multiple third-party libraries, such as MPFR, > > GSL, GP/PARI, mpmath, and Maxima, for numerical evaluation of > > special functions. There are significant discrepancies between > > these backends in the performance for numerical approximations of > > the same expression. An initial benchmark reveals, for example, > > that calculating spherical_bessel_J(1, 5.2) with SciPy is over 100 > > times faster than with Maxima. > > The project has the following goals: > > > > 1. develop a benchmark framework to determine which backend > > should be used by default to evaluate a special function over a > > specific domain, > > This sounds like a really bad idea for 2 reasons. > 1. none of the backends are stationary. If someone comes up with a > spherical_bessel evaluator that is 100X faster > yet again than SciPy, but is in Maxima, you are losing. The point of the benchmark framework is to be able to repeat the measurements when the backends change, on different platforms, etc. See explanation of item 2 from [1]. > 2. To determine over an arbitrary span of floats which program is > most accurate and fastest requires a fairly > sophisticated set of tests. For example even a function like sine > can be delicate to evaluate, say at a high integer > multiple of pi. And how do the functions respond at singularities? > Just generating random arguments is > not sensible. Again, see explanation of item 2 from [1]. > Oh, for some programs you may need to figure out what to do with > unbounded inputs (integers, bigfloats). How is this related? We already have interfaces to the packages mentioned above to handle conversion issues. > > 1. > > 2. create symbolic wrappers for all the special functions that > > can be evaluated numerically by a package included in Sage, > > > > > Um, I'm not sure what is required here, but maybe just bookkeeping?? Yes, these are simple wrappers in Sage. Somebody needs to write them. > > 1. > > 2. create a data structure for generalized hypergeometric > > functions and extend the symbolic wrappers to obtain > > representations in terms of generalized hypergeometric functions > > when possible, > > huh? Wouldn't it always be possible to express generalized > > hypergeometric > functions as generalized hypergeometric functions? For example, we want the software to convert bessel_j(2,x) to 1/8*x^2*hypergeometric_pfq(0, 1, 3, -1/4*x^2). > If you mean to simplify them, whose algorithm are you going to use? > Or did you not know about such things? The goal is to provide a basis to implement algorithms used in DDMF [2]. [2] http://ddmf.msr-inria.inria.fr/ > > 1. > > 2. implement closure properties for holonomic functions as a > > next step to improve the symbolic processing of special functions > > in Sage. Cheers, Burcin -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
