Opened 13 years ago
Last modified 8 years ago
#6882 closed defect
bugs in conversion of variable names from Maxima to Sage — at Version 26
Reported by: | William Stein | Owned by: | Ralf Stephan |
---|---|---|---|
Priority: | major | Milestone: | sage-6.3 |
Component: | calculus | Keywords: | |
Cc: | Robert Marik | Merged in: | |
Authors: | Reviewers: | ||
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | #8734, #16007 | Stopgaps: |
Description (last modified by )
----------- sage: from sage.calculus.calculus import symbolic_expression_from_maxima_string sage: symbolic_expression_from_maxima_string('%i') I sage: symbolic_expression_from_maxima_string('i') I sage: symbolic_expression_from_maxima_string('%inf') Inf ----------- So as you see, we are converting both '%i' and 'i' to imaginary 'I' !!!!
The ticket should implement multi_word_replace()
in sage.misc.multireplace
and use that on a symtable with additional entries 'e':'_e', 'i':'_i', 'I':'_I'
.
Change History (26)
comment:1 Changed 13 years ago by
comment:2 Changed 13 years ago by
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 follow-up: 14 Changed 13 years ago by
Report Upstream: | → N/A |
---|
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 Yuri Karadzhov
[marik@um-bc107 /opt/sage-4.3.4]$ ./sage ---------------------------------------------------------------------- | Sage Version 4.3.4, Release Date: 2010-03-19 | | Type notebook() for the GUI, and license() for information. | ---------------------------------------------------------------------- sage: from sage.calculus.calculus import symbolic_expression_from_maxima_string sage: symbolic_expression_from_maxima_string('%c') c sage: c=var('c'); y=function('y',x); eq=diff(y,x)==c*x; eq D[0](y)(x) == c*x sage: desolve(eq,y,ivar=x) 1/2*c*x^2 + c
the answer should be something like 1/2*c*x^{2 + c1 }
comment:5 follow-up: 12 Changed 12 years ago by
Actually, I guess the patch at #8734 will *help* with the solution, but may not totally solve the problem.
comment:7 Changed 10 years ago by
Also, in a situation where we don't have the duplication of constants, we get
sage: c Traceback (click to the left of this block for traceback) ... NameError: name 'c' is not defined
which isn't good either, though apparently that part of the expression still has type SymbolicExpression.
comment:8 Changed 9 years ago by
Milestone: | sage-5.11 → sage-5.12 |
---|
comment:9 Changed 9 years ago by
Milestone: | sage-6.1 → sage-6.2 |
---|
comment:10 Changed 9 years ago by
Priority: | major → critical |
---|
Set to critical due to dependent tickets.
comment:12 Changed 9 years ago by
Replying to jason:
Actually, I guess the patch at #8734 will *help* with the solution, but may not totally solve the problem.
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...().
comment:13 Changed 9 years ago by
Dependencies: | → #8734 |
---|
comment:14 Changed 9 years ago by
Dependencies: | #8734 → #8734, #16007 |
---|
Replying to robert.marik:
As another consequence, solving of ode y'=c*x is not correct ... the answer should be something like 1/2*c*x^{2 + c1 }
This one is resolved in #16007. So it seems only variables are left (#8734).
comment:15 Changed 9 years ago by
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 i
and e
from the things that become those in Sage - %i
and %e
. I suppose one could take the Maxima variables i
and I
and turn them into _i
and _I
, and likewise for e, as at #16007, but I'm not sure if that's ideal or not. Thoughts?
comment:16 Changed 8 years ago by
Milestone: | sage-6.2 → sage-6.3 |
---|
comment:17 follow-up: 18 Changed 8 years ago by
Priority: | critical → minor |
---|
Priority changed as the more important fixes were outsourced to other tickets.
comment:18 Changed 8 years ago by
Priority changed as the more important fixes were outsourced to other tickets.
Hmm, though the BDFL originally reported this with the comment
I think my email must have not been clear. I think it's an instance of a *HUGE BUG* in Sage. No more, no less.
comment:19 Changed 8 years ago by
Priority: | minor → major |
---|
Maybe we can change the Maxima i
and e
to Sage _i
and _e
, leaving %i
and %e
to become i
and e
as currently, and then taking advantage of the last changes at #16007 for typesetting more-or-less properly.
comment:20 Changed 8 years ago by
Status: | new → needs_info |
---|
The original bug report on sage-devel had:
sage: var('i') i sage: i i sage: a = i^2 sage: a.simplify_full() -1
However, with develop I get i^2
. Is this ticket still valid?
comment:21 Changed 8 years ago by
And indeed,
sage: from sage.calculus.calculus import symbolic_expression_from_maxima_string sage: symbolic_expression_from_maxima_string('i') i sage: symbolic_expression_from_maxima_string('%i') I
And the original solving case William reported is also fixed.
Huh. Is this before or after #8734? (I would imagine that one would have an impact.) Anyway, I would say we add some doctests (for both the sefms
and i^2
cases) and call it a day, regardless of which ticket it depends on. Good work, since ideally one wouldn't be creating a Maxima i
and then trying to bring it to Sage.
comment:22 Changed 8 years ago by
Status: | needs_info → needs_work |
---|
With develop:
sage: from sage.calculus.calculus import symbolic_expression_from_maxima_string sage: symbolic_expression_from_maxima_string('t') t sage: symbolic_expression_from_maxima_string('i') I sage: var('i') i sage: symbolic_expression_from_maxima_string('i') i
So that example is a different animal than the ticket case.
comment:23 Changed 8 years ago by
Okay, I see. But the thing is that, in principle, we should never get i
inside Maxima without asking for it via Sage having a variable i
; we should only get %i
the imaginary in Maxima, which translates differently (and correctly) now. Does that make sense, or do you think this is still worth fixing? (We should check what happens with e
as well, maybe via ln(e)
.)
comment:24 Changed 8 years ago by
With #8734 I
can result from a Sage I
variable, from Maxima %i
, or from Maxima i
which is only creatable from Sage via the Maxima interface. But not from any trick involving the Sage variable i
due to the protection via _SAGE_VAR_
. The i
case is why Jason said #8734 will help, but not totally solve the problem.
I don't know why the i^2
example failed at all, and when exactly it stopped failing. Maybe it didn't fail; certainly nobody posted a confirmation message. And certainly we all confirmed the sefms snippet because that's what the ticket presented.
comment:25 Changed 8 years ago by
Yeah, even in Sage 4.4.4 (which I have lying around due to some custom fixes I use for research I'm too lazy to update)
sage: var('i') i sage: i i sage: a = i^2 sage: a i^2 sage: a.simplify_full() i^2
Your thoughts on a resolution? The thing that was a bug is not there any more, and the only potential bug is from 'user error', in some sense.
comment:26 Changed 8 years ago by
Description: | modified (diff) |
---|---|
Owner: | changed from Burcin Erocal to Ralf Stephan |
Summary: | bug in conversion of "i" from Maxima to Sage → bugs in conversion of variable names from Maxima to Sage |
At the moment we also get behaviour like
sage: symbolic_expression_from_maxima_string('%inf') Inf
so I think the ticket should implement multi_word_replace()
in sage.misc.multireplace
and use that on a symtable with additional entries 'e':'_e', 'i':'_i', 'I':'_I'
.
Here is the relevant discussion.