-
-
Notifications
You must be signed in to change notification settings - Fork 449
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
bugs in conversion of variable names from Maxima to Sage #6882
Comments
comment:1
Here is the relevant discussion. |
comment:2
This will also happen with %e and e, and any other similar pairs, so a fix should take care of all of them. |
comment:3
As another consequence, solving of ode y'=c*x is not correct, the free variable is messed up with a parameter, see sage-devel - thanks for
the answer should be something like 1/2cx^2 + c1 |
comment:4
See #8734 for what I think is a "needs work" solution. |
comment:5
Actually, I guess the patch at #8734 will help with the solution, but may not totally solve the problem. |
comment:6
This should fix also #9421. |
comment:7
Also, in a situation where we don't have the duplication of constants, we get
which isn't good either, though apparently that part of the expression still has type SymbolicExpression. |
comment:10
Set to critical due to dependent tickets. |
comment:12
Replying to @jasongrout:
Indeed, because the patch at #8734 (needing review) only is about vars, and it will only help with the problem in comment:3 if the then marked sage vars are renamed to some other specific string before output in desolve...(). |
Dependencies: #8734 |
comment:14
Replying to @robert-marik:
This one is resolved in #16007. So it seems only variables are left (#8734). |
comment:15
Yes, variables are all that's left, but the other way around! (Don't forget the initial examples of this ticket.) We need to disambiguate Maxima variables like |
comment:17
Priority changed as the more important fixes were outsourced to other tickets. |
comment:18
Hmm, though the BDFL originally reported this with the comment
|
comment:27
Is
I guess one could do so... I'm just trying to imagine cases in which this would be necessary due only to Sage usage. If someone uses Maxima to create variables it's quite different. |
comment:28
Replying to @kcrisman:
No but we do not want to be surprised when some new Maxima variable starting |
This comment has been minimized.
This comment has been minimized.
comment:30
Aha! I didn't catch that was the reason. I don't think Maxima introduces many new constants with |
Author: Ralf Stephan |
Commit: |
comment:32
I also found an error in the definition for maxima variable, because it didn't allow variable names without '%' or the '%' not at the beginning. Now the mentioned rules can be expressed as simple entries in symtable. New commits:
|
This comment has been minimized.
This comment has been minimized.
comment:34
You'll note that |
comment:35
Replying to @kcrisman:
It's within the measurement error:
Obviously the whole routine takes so long that the loop doesn't signify. That may be worth an optimization ticket alone.
Just put it in |
comment:36
Replying to @rwst:
It calls 120 times the function |
comment:37
Wow, those timings are indeed an eternity, though presumably not for shorter expressions. I'll put this ticket in my "finally finish reviewing" queue, then, for sure. |
Reviewer: Karl-Dieter Crisman |
comment:38
Well, it's an improvement, though still not perfect:
Neither of these are infinity in Maxima, of course. And indeed here is what the Maxima manual says about identifiers:
"A numeral may be the first character of an identifier if it is preceded by a backslash. " But I don't know that we need to translate all identifiers in Maxima to Sage here... I guess I'm torn about that.
Of course, thinking about it, that string is a Sage string, not a Maxima string, so Okay, as far as I can tell this will not break anything (let's really hope!) and fixes the actual problem without slowing down what is already a very slow process (even for |
Changed branch from u/rws/bugs_in_conversion_of_variable_names_from_maxima_to_sage to |
The ticket should implement a multi word replace and use that on a symtable with additional entries
'e':'_e', 'i':'_i', 'I':'_I'
.We do not want to be surprised when some new Maxima variable starting %i is introduced. At the moment it's really just a string replace from %i to I, without sense of word boundaries.
CC: @robert-marik
Component: calculus
Author: Ralf Stephan
Branch/Commit:
518de3e
Reviewer: Karl-Dieter Crisman
Issue created by migration from https://trac.sagemath.org/ticket/6882
The text was updated successfully, but these errors were encountered: