Opened 12 years ago
Last modified 7 years ago
#6882 closed defect
bugs in conversion of variable names from Maxima to Sage — at Version 33
Reported by:  was  Owned by:  rws 

Priority:  major  Milestone:  sage6.3 
Component:  calculus  Keywords:  
Cc:  robert.marik  Merged in:  
Authors:  Ralf Stephan  Reviewers:  
Report Upstream:  N/A  Work issues:  
Branch:  u/rws/bugs_in_conversion_of_variable_names_from_maxima_to_sage (Commits, GitHub, GitLab)  Commit:  518de3e62533cd209997107f903192f1a31d118c 
Dependencies:  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 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.
Change History (33)
comment:1 Changed 12 years ago by
comment:2 Changed 12 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 followup: ↓ 14 Changed 12 years ago by
 Report Upstream set to N/A
As another consequence, solving of ode y'=c*x is not correct, the free variable is messed up with a parameter, see sagedevel  thanks for Yuri Karadzhov
[marik@umbc107 /opt/sage4.3.4]$ ./sage   Sage Version 4.3.4, Release Date: 20100319   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:4 Changed 11 years ago by
See #8734 for what I think is a "needs work" solution.
comment:5 followup: ↓ 12 Changed 11 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 9 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 8 years ago by
 Milestone changed from sage5.11 to sage5.12
comment:9 Changed 8 years ago by
 Milestone changed from sage6.1 to sage6.2
comment:10 Changed 8 years ago by
 Priority changed from major to critical
Set to critical due to dependent tickets.
comment:11 Changed 8 years ago by
comment:12 in reply to: ↑ 5 Changed 8 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 8 years ago by
 Dependencies set to #8734
comment:14 in reply to: ↑ 3 Changed 8 years ago by
 Dependencies changed from #8734 to #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 8 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 7 years ago by
 Milestone changed from sage6.2 to sage6.3
comment:17 followup: ↓ 18 Changed 7 years ago by
 Priority changed from critical to minor
Priority changed as the more important fixes were outsourced to other tickets.
comment:18 in reply to: ↑ 17 Changed 7 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 7 years ago by
 Priority changed from minor to 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 moreorless properly.
comment:20 Changed 7 years ago by
 Status changed from new to needs_info
The original bug report on sagedevel 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 7 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 7 years ago by
 Status changed from needs_info to 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 7 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 7 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 7 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 followup: ↓ 27 Changed 7 years ago by
 Description modified (diff)
 Owner changed from burcin to rws
 Summary changed from bug in conversion of "i" from Maxima to Sage to 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'
.
comment:27 in reply to: ↑ 26 ; followup: ↓ 28 Changed 7 years ago by
At the moment we also get behaviour like
sage: symbolic_expression_from_maxima_string('%inf') Inf
Is %inf
a normal Maxima expression, though? They just use inf
and minf
, I believe, which we replace correctly.
so I think the ticket should implement
multi_word_replace()
insage.misc.multireplace
and use that on a symtable with additional entries'e':'_e', 'i':'_i', 'I':'_I'
.
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 in reply to: ↑ 27 ; followup: ↓ 30 Changed 7 years ago by
Replying to kcrisman:
Is
%inf
a normal Maxima expression, though? They just useinf
andminf
, I believe, which we replace correctly.
No but 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.
comment:29 Changed 7 years ago by
 Description modified (diff)
comment:30 in reply to: ↑ 28 Changed 7 years ago by
Is
%inf
a normal Maxima expression, though? They just useinf
andminf
, I believe, which we replace correctly.No but 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
toI
, without sense of word boundaries.
Aha! I didn't catch that was the reason. I don't think Maxima introduces many new constants with %
but I see your point.
comment:31 Changed 7 years ago by
 Branch set to u/rws/bugs_in_conversion_of_variable_names_from_maxima_to_sage
comment:32 Changed 7 years ago by
 Commit set to 518de3e62533cd209997107f903192f1a31d118c
 Dependencies #8734, #16007 deleted
 Status changed from needs_work to needs_review
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:
4e07383  6882: add rules for e, i, I

e5a5343  6882: do word search/replace for symtable keys

4c1b0eb  6882: correction to previous commit

518de3e  6882: add symable rules for e,i,I; fix maxima_var; add doctests

comment:33 Changed 7 years ago by
 Description modified (diff)
Here is the relevant discussion.