On Fri, Jan 22, 2016 at 12:58 AM, Buck Evan <buck.2...@gmail.com> wrote: > Fredrik: > Thank you for your thoughtful reply! > > On Thu, Jan 21, 2016 at 2:48 PM Fredrik Johansson > <fredrik.johans...@gmail.com> wrote: >> >> Arb (which is now in Sage) permits computing incomplete gamma >> functions with rigorous error bounds over arbitrary-precision >> real/complex (interval) fields. > > > I don't find the incomplete function. Am I looking in the wrong section? > http://fredrikj.net/arb/acb.html?highlight=gamma#gamma-function
Yes; see http://fredrikj.net/arb/acb_hypgeom.html?highlight=gamma#incomplete-gamma-functions >> >> Supporting the different regularized >> versions is just a matter of dividing by a complete gamma function. > > > My understanding is that computing the regularized function directly gives > less error than division of two huge numbers, but I don't truly understand > the theory of numeric error. This is not a problem with an arbitrary precision backend (you can increase the precision to compensate). Anyway, it's not hard to implement the asymptotic cases separately. >> >> Looking at the attachment, I don't know if the logarithmic versions of >> incomplete gamma functions are really useful. > > > Why would gamma_log(a, x) be less useful than gamma_log(a)? > Certainly the incomplete functions increase to astronomical quantities > similarly to the complete function. Anyway, that doesn't seem to be an > argument to make it unavailable. Sure, but this is not really concern if using Sage's RR. You could make the case for having a log=True option for any function that grows exponentially, but in that case, why not just work with a type that supports large numbers? There are of course exceptions: the usual gamma function and the scaled complementary error function come to mind. I'm not saying it couldn't be useful, but do you have a concrete application in mind for gamma_log(a, x) that would make it worth the added complexity? As soon as you introduce options, you have a lot more special cases to worry about handling correctly in the implementation. I don't even know how you would define the logarithm of the incomplete gamma function for complex numbers to make it useful. The usual log gamma function is not defined as log(gamma(z)). > However I do hear the point that I shouldn't worry about this edge case at > all. > >> >> The regularized >> incomplete gamma functions P and Q are quite standard and used in >> statistics, I think. > > > That's a useful note. That's what I'm seeing in my research as well. > >> >> Personally, I think the usual gamma() function is too important in its >> own right to complicate by adding extra options. I would rather leave >> gamma() a single-argument function and have separate functions for >> logarithmic and incomplete gamma functions of various kinds. > > > Options and number of arguments are separate issues, in my mind. > The one extreme would be gamma(a) while the other would be gamma(a, x1=0, > x2=oo, log=False, regularized=False). > > > I believe you and Nils agree that the 'log' and 'regularized' options are > sketchy. I think I agree too. However the three-argument gamma (the > generalized gamma) is a useful normal form for the upper and lower > incomplete functions. > >> >> In mpmath, there is a single function gammainc() that covers all cases of >> incomplete gamma functions. But it's not necessary to do it in that >> particular way. > > > mpmath.gammainc() with one argument calculates the complete gamma, which > makes it feel miss-named and redundant to me. This is, again, motivated by having a clean interface for the ordinary gamma function. But that's subjective. >> If you want symbolic manipulation to be aware of different variants, >> >> you probably need to do something in Pynac/SymPy/Maxima rather than >> Sage itself. > > > All three, or just one? > If one, is it my decision, or predetermined by details of sage? I don't know. Fredrik -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
