Opened 7 years ago

Last modified 3 years ago

#13869 new defect

Gamma of complex numbers incorrectly simplifies to factorial

Reported by: JoalHeagney Owned by: burcin
Priority: major Milestone: sage-6.4
Component: symbolics Keywords: gamma, simplify_full, simplify_factorial, maxima
Cc: benjaminfjones, dsm, eviatarbach, paulmasson Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description

If I type the following into sage-5.5 built from source,

(gamma(-i-3/2)).simplify_full()

I get the following result:

factorial(-I - 5/2)

This:

n(factorial(-I - 5/2))

gives the obvious error:

TypeError: cannot evaluate symbolic expression numerically

while:

n(gamma(-I-5/2))

gives no problems.

-0.0417366258078936 + 0.0863691073697635*I

I've only noticed this happening in 5.5 - no such problems in 5.4 (that I remember).

Change History (22)

comment:1 follow-up: Changed 7 years ago by burcin

  • Component changed from algebra to symbolics
  • Owner changed from AlexGhitza to burcin

This seems to be our doing. In simplify_factorial() we have:

return self.parent()(self._maxima_().makefact().factcomb().minfactorial())

Here is what the Maxima manual says about makefact():

transforms occurrences of binomial,gamma, and beta functions in exp to factorials. 

There is also a corresponding makegamma() function, but this will change factorials to gamma as well.

comment:2 in reply to: ↑ 1 Changed 7 years ago by kcrisman

  • Cc benjaminfjones dsm added

In Sage 5.2:

sage: (gamma(-i-3/2)).simplify_full()
factorial(-I - 5/2)
sage: a = gamma(-i-3/2)
sage: a._maxima_().makefact()
(-%i-5/2)!

This seems to be our doing. In simplify_factorial() we have:

So I agree with Burcin that this comes from us.

The problem is that we do rely on this for some examples of the (mostly improved) simplification. E.g. from #6636

sage: var('k')
k
sage: f = binomial(n,k)*factorial(k)*factorial(n-k)
sage: f._maxima_()
k!*binomial(n,k)*(n-k)!
sage: f._maxima_().makefact()
n!

On the other hand, does Maxima really want these occurrences with non-integer inputs to be transformed thusly?

comment:3 follow-up: Changed 7 years ago by JoalHeagney

So, should we report upstream?

comment:4 in reply to: ↑ 3 Changed 7 years ago by kcrisman

Replying to JoalHeagney:

So, should we report upstream?

I'm not a special functions expert, so maybe it would be nice if someone who had work interrupted reported.

comment:5 follow-up: Changed 7 years ago by JoalHeagney

Hmm, maybe not. From what I can see from the maxima documentation, it's kinda hinted that if you call makefact, it's assumed that you know what you're asking for.

Would it be possible to change the simplification code to use makegamma instead?

In the sage -maxima interface, I was able to do the following (these are all out of order cut-and-paste from my maxima session.)

(%i18) makegamma(binomial(n,k)*factorial(k)*factorial(n-k));
(%o18)                           gamma(n + 1)
(%i12) gamma_expand:true;
(%o12)                               true
(%i13) gamma(2+i);
(%o13)                        i (i + 1) gamma(i)
(%i16) makegamma(binomial(n,k)*factorial(k)*factorial(n-k));
(%o16)                            n gamma(n)

The benefits here, are that makegamma and gamma_expand functions seem to provide the same simplifications (if not more) that minfactorial and makefact do, but gamma functions can handle (by definition) more fields (RR, CC).

I don't know if we want gamma_expand to be true all the time, but it does seem to give another level of simplification, pulling out i(i+1) in my second example.

Then we could document the .makefact function so that users could convert sagemath (new default) gamma answers to factorials for themselves?

comment:6 Changed 7 years ago by JoalHeagney

In the documentation of maxima http://maxima.sourceforge.net/docs/manual/en/maxima_15.html there are also a lot of other expand options we may want to investigate as well:

E.g. besselexpand, beta_expand, expintexpand, hypergeometric and expand_hypergeometric,

comment:7 Changed 7 years ago by JoalHeagney

Another argument for the makegamma option is the following simplification from a maxima newsgroup:

(%i7) gamma_expand:true;
(%o7)                                true
(%i8) gamma(a+1)/gamma(a);
(%o8)                                  a

comment:8 in reply to: ↑ 5 Changed 7 years ago by kcrisman

Would it be possible to change the simplification code to use makegamma instead?

I don't see any reason why not. If we start using Maxima code more like it's meant to be, that is a good thing, as long as we can keep as many simplifications as possible working.

I don't know if we want gamma_expand to be true all the time, but it does seem to give another level of simplification, pulling out i(i+1) in my second example.

The standard thing we do is make another simplify_blah function and then add that to simplify_full. Heck, why not add those other expand things too eventually... we might want to wait until the stuff for symbolic hypergeometric and bessels is in first for those, though :-)

comment:9 follow-up: Changed 7 years ago by JoalHeagney

  • Keywords simplify_factorial maxima added

Hah hah hah.

You won't believe this, but I went to the maxima-bugs newsgroup and found out that maxima has the following behaviour:

(%i2) float((%i + 3)!);   
(%o2)              4.980156681183563 %i + 1.5494982830181063

So, the issue seems to be:

  • maxima treats x! and gamma(x+1) identically in regards to dealing with complex numbers (which I think is mathematically appalling).
  • so if there's any difference between sagemath and maxima regarding (3 + i)!, it's sagemath's doing.

comment:10 in reply to: ↑ 9 Changed 7 years ago by benjaminfjones

Replying to JoalHeagney:

  • maxima treats x! and gamma(x+1) identically in regards to dealing with complex numbers (which I think is mathematically appalling).
  • so if there's any difference between sagemath and maxima regarding (3 + i)!, it's sagemath's doing.

Why is that appalling? \Gamma is a natural extension of factorial to the complex plane that agrees with factorial everywhere that factorial is defined.

+1 to exposing more simplification options from Maxima.

comment:11 Changed 7 years ago by JoalHeagney

I don't argue with using gamma to extend factorial - just find it worrying that maxima treats factorial as equivalent to gamma. Much the same way sage doesn't treat ZZ as identically equivalent to RR, despite the fact that every element of ZZ appears in RR.

I'm finishing moving house for the next few days (2000km by car), and won't have reliable Internet for about a month after, so I am unable to code anything up, but I would much prefer that if we/maxima are going to treat factorial = gamma, to replace simplify_factorial with simplify_gamma instead?

Out of curiosity, does anyone know how we would do the maxima gamma_expand:true; function call from sage/python?

comment:12 Changed 7 years ago by eviatarbach

  • Cc eviatarbach added

comment:13 Changed 6 years ago by jdemeyer

  • Milestone changed from sage-5.11 to sage-5.12

comment:14 Changed 6 years ago by vbraun_spam

  • Milestone changed from sage-6.1 to sage-6.2

comment:15 Changed 6 years ago by vbraun_spam

  • Milestone changed from sage-6.2 to sage-6.3

comment:16 Changed 5 years ago by vbraun_spam

  • Milestone changed from sage-6.3 to sage-6.4

comment:17 Changed 5 years ago by JoalHeagney

Okay, after a long time, I think I can say that this ticket could be modified/closed.

Using the following I can get the behaviour I want from sage:

maxima.eval("gamma_expand:true")

and similar to set the different options for maxima expansion and:

var('n,k')
maxima.makegamma(binomial(n,k)*factorial(k)*factorial(n-k)).sage()

maxima.makegamma((gamma(i-3/2)).simplify_full()).sage()

to force expressions back to gammas rather than factorials.

Messy, but effective.

comment:18 Changed 5 years ago by kcrisman

Well, I'll go with modify, not close, because we would both want to document this workaround as well as still decide what to do. I mean, if makegamma really does do the same thing as the other one, maybe we could replace it... but I wonder whether it would take things in factorial form and then make them gammas, perhaps also controverting expectations. In reality, simplification isn't always equivalence... Anyway, I haven't looked at this for quite some time so maybe my comments make no sense anyway!

comment:19 follow-up: Changed 5 years ago by kcrisman

Note also that gamma_expand does alter some other stuff, like incomplete gammas, that come up in various integrals.

Maybe making that simplify_gamma function is the best idea after all. Maybe.

comment:20 Changed 5 years ago by rws

The issue with N(factorial(...)) is #17489.

Last edited 5 years ago by rws (previous) (diff)

comment:21 in reply to: ↑ 19 Changed 5 years ago by rws

Replying to kcrisman:

Note also that gamma_expand does alter some other stuff, like incomplete gammas, that come up in various integrals.

Maybe making that simplify_gamma function is the best idea after all. Maybe.

I have a proposal at #17737.

comment:22 Changed 3 years ago by paulmasson

  • Cc paulmasson added
Note: See TracTickets for help on using tickets.