limit (and in fact Maxima in general) has minimal understanding of intervals and interval arithmetic. For example, sign(x^2+sin(x)+2) => pnz.
It would be great to fix that, but it's not really a "bug", but "known limitation". In the gamma example, und is "correct" in the best-effort sense, because it includes the zero case.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
By defining a simplim%function for the gamma function, it's not too hard to catch some easy cases. For that scheme to work, you also have to turn off the way the limit code converts all gamma expressions into factorial expressions (that happens in the function extra-simp).
All this could, I suppose be done with the current scheme of converting to factorial form, but I think that the following is inelegant:
(%i3) limit(gamma(x),x,2/3);
(%o3) (-(1/3))!
Surely most users would prefer gamma(2/3). To fix up other problems that surface by making such changes requires a fair amount of work.
Simple demo from a work in progress:
(%i5) limit(gamma(5+sin(x)),x,inf);
(%o5) ind
(%i6) limit(gamma(5+sin(x))/x,x,inf);
(%o6) 0
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Re "the current scheme of converting to factorial form", it does produce some strange results, but it simplifies the code compared to handling gamma and ! separately.
The original sin is of course supporting two distinct functions. But they are not handled symmetrically. For example, there is minfactorial but no mingamma, so you need to do something like makegamma(minfactorial(makefact(ex))). But gammalim doesn't apply to factorial. makegamma works on pochhammer, and makefactorial doesn't. But pochhammer(1,x) returns x! and not gamma(x+1). stirling works on gamma but not !.
Presumably some users prefer one and others prefer the other. (I hope that no real users (as opposed to perverse testers like you and me) write expressions like x!/gamma(x).) This is different from sin and cos, where they are invariably used together, even though they are related in a similar way.
The "obvious" solution is to use one of them universally as the internal representation, and only support the other as an input/output form, perhaps under the control of a switch, e.g., show_gammafact. So with show_gammafact=factorial, gamma(x) would display as (x-1)!.
We could even set that variable when the user enters one or the other, but that might be more and not less confusing for users....
All this to say that it's not a limit problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
limit(and in fact Maxima in general) has minimal understanding of intervals and interval arithmetic. For example,sign(x^2+sin(x)+2) => pnz.It would be great to fix that, but it's not really a "bug", but "known limitation". In the
gammaexample,undis "correct" in the best-effort sense, because it includes thezerocase.By defining a
simplim%functionfor the gamma function, it's not too hard to catch some easy cases. For that scheme to work, you also have to turn off the way the limit code converts all gamma expressions into factorial expressions (that happens in the functionextra-simp).All this could, I suppose be done with the current scheme of converting to factorial form, but I think that the following is inelegant:
Surely most users would prefer
gamma(2/3). To fix up other problems that surface by making such changes requires a fair amount of work.Simple demo from a work in progress:
Re "the current scheme of converting to factorial form", it does produce some strange results, but it simplifies the code compared to handling gamma and ! separately.
The original sin is of course supporting two distinct functions. But they are not handled symmetrically. For example, there is minfactorial but no mingamma, so you need to do something like makegamma(minfactorial(makefact(ex))). But gammalim doesn't apply to factorial. makegamma works on pochhammer, and makefactorial doesn't. But pochhammer(1,x) returns x! and not gamma(x+1). stirling works on gamma but not !.
Presumably some users prefer one and others prefer the other. (I hope that no real users (as opposed to perverse testers like you and me) write expressions like x!/gamma(x).) This is different from sin and cos, where they are invariably used together, even though they are related in a similar way.
The "obvious" solution is to use one of them universally as the internal representation, and only support the other as an input/output form, perhaps under the control of a switch, e.g., show_gammafact. So with show_gammafact=factorial, gamma(x) would display as (x-1)!.
We could even set that variable when the user enters one or the other, but that might be more and not less confusing for users....
All this to say that it's not a limit problem.