On Saturday, 4 February 2012 17:38:00 UTC+8, Dr. David Kirkby wrote: > > On 02/ 4/12 05:00 AM, Dima Pasechnik wrote: > > > > > > On Saturday, 4 February 2012 11:53:35 UTC+8, Dr. David Kirkby wrote: > >> > >> > >> > >> On 2 February 2012 23:05, rjf<> wrote: > >> > >>> > >>> I don't know about arithmetic on ARM specifically, but there is > >>> something > >>> wrong with a gamma() function that fails to return an integer (perhaps > >>> in float format) when it is > >>> given an integer argument (perhaps in float format), and the answer is > >>> exactly representable > >>> as an integer in float format. > >>> > >> > >> Would you say this is true for any function foobar(), or gamma() in > >> particular? > >> > > > > It's well-known how to compute gamma() better than it is implemented in > > (e)glibc, the prevalent Linux libc implementation, > > which computes exp(lgamma()) rather than gamma() directly. > > > > See e.g. > > http://oai.cwi.nl/oai/asset/10080/10080A.pdf > > > > Perhaps I should give it to a student, to re-write in C or Cython > > If there are no significant disadvantages to this algorithm, it would be > worth > trying to get the gnu developers to use it in the c library. The best > chance of > doing that would be to write it in C. >
in fact it looks as it's implemented in GSL (see gsl/gsl_specfunc.h, function gsl_sf_gamma()), using Temme's algorithm (see the link above). It there any reason Sage uses the libc's gamma() instead? Dima Dave > > -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
