-
-
Notifications
You must be signed in to change notification settings - Fork 488
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
substitute_function() can leave limits unevaluated #17553
Comments
comment:1
Unfortunately that workaround doesn't work when exponentials are involved. The
Here's what I'm trying out to work around this:
I've tried poking around the maxima_lib module for a more straightforward way to ask Maxima to evaluate the limit without the data loss involved in the |
comment:2
It seems that the inert form of "limit" isn't easily transformed back into one that is considered for evaluation, so once the limit is sitting there as an unevaluated one, substituting into it doesn't give you a limit that is attempted to be evaluated. Perhaps we need a "simplify_limit" that substitutes all the "%LIMIT" symbols for "$LIMIT" in a maxima expression:
Alternatively, perhaps we should change the translation of the "limit" operator to be "$LIMIT" instead of "%LIMIT" (at the cost of re-evaluating any limits when they pass from sage to maxima). I don't know where exactly that conversion happens, because it does seem to be partially in place already:
I suspect that this is the culprit:
(note the explicit "'" there: it's the inert limit). We also have
which gets picked up because the first encounter of the limit symbol is the inert "%limit" on the maxima side, which primes the dict with that translation. This is easily overridden if desired. However, "simplify" and friends don't use In short, we may need to instantiate our own "limit" operator in ginac to accommodate the different translation options, unless we're happy with a "simplify_limit" routine instead. |
comment:3
Yes, thank you. I was just converging on the same conclusions about I've been assuming that when I see "limit( ..., x, 0.1 )" in a result, it's going to be passed back to maxima in a form that'll re-evaluate the limit. I'd vote for implementing it that way rather than requiring the user to do "simplify_limit" manually at the appropriate times. But I'm sure other users are doing infinite sums and such things that are better not to re-evaluate... |
comment:4
Hmm, I didn't realize you could use python functions in
:-) Note using Update: here it is in
|
comment:5
Replying to @sagetrac-wonder:
Smart solution. There is an
should do the trick. The fact that
indicates that we really should be making a symbol for "limit" beforehand (and equip it with the right translations) CORRECTION: The symbol to use is
|
comment:6
Replying to @nbruin:
Thanks! Yes, that also works. |
Here is an example:
This is a simplified case of a situation that's been biting me in an expression that's passed to odeint() after being computed: it breaks the integration because it fails to evaluate to a float expression.
Component: symbolics
Issue created by migration from https://trac.sagemath.org/ticket/17553
The text was updated successfully, but these errors were encountered: