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:

Status badges

Description (last modified by Ralf Stephan)

-----------
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 Karl-Dieter Crisman

Here is the relevant discussion.

comment:2 Changed 13 years ago by Karl-Dieter Crisman

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 Changed 13 years ago by Robert Marik

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*x2 + c1

comment:4 Changed 12 years ago by Jason Grout

See #8734 for what I think is a "needs work" solution.

comment:5 Changed 12 years ago by Jason Grout

Actually, I guess the patch at #8734 will *help* with the solution, but may not totally solve the problem.

comment:6 Changed 12 years ago by Robert Marik

Cc: Robert Marik added

This should fix also #9421.

comment:7 Changed 10 years ago by Karl-Dieter Crisman

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 Jeroen Demeyer

Milestone: sage-5.11sage-5.12

comment:9 Changed 9 years ago by For batch modifications

Milestone: sage-6.1sage-6.2

comment:10 Changed 9 years ago by Ralf Stephan

Priority: majorcritical

Set to critical due to dependent tickets.

comment:11 Changed 9 years ago by Ralf Stephan

Last edited 9 years ago by Ralf Stephan (previous) (diff)

comment:12 in reply to:  5 Changed 9 years ago by Ralf Stephan

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 Ralf Stephan

Dependencies: #8734

comment:14 in reply to:  3 Changed 9 years ago by Ralf Stephan

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*x2 + c1

This one is resolved in #16007. So it seems only variables are left (#8734).

comment:15 Changed 9 years ago by Karl-Dieter Crisman

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?

Last edited 9 years ago by Karl-Dieter Crisman (previous) (diff)

comment:16 Changed 8 years ago by For batch modifications

Milestone: sage-6.2sage-6.3

comment:17 Changed 8 years ago by Ralf Stephan

Priority: criticalminor

Priority changed as the more important fixes were outsourced to other tickets.

comment:18 in reply to:  17 Changed 8 years ago by Karl-Dieter Crisman

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 Karl-Dieter Crisman

Priority: minormajor

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 Ralf Stephan

Status: newneeds_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 Karl-Dieter Crisman

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 Ralf Stephan

Status: needs_infoneeds_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 Karl-Dieter Crisman

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 Ralf Stephan

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 Karl-Dieter Crisman

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 Ralf Stephan

Description: modified (diff)
Owner: changed from Burcin Erocal to Ralf Stephan
Summary: bug in conversion of "i" from Maxima to Sagebugs 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'.

Note: See TracTickets for help on using tickets.