Opened 12 years ago

Last modified 7 years ago

#6882 closed defect

bugs in conversion of variable names from Maxima to Sage — at Version 26

Reported by: was Owned by: rws
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 rws)

-----------
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 12 years ago by kcrisman

Here is the relevant discussion.

comment:2 Changed 12 years ago by kcrisman

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: Changed 11 years ago by robert.marik

  • 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 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 11 years ago by jason

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

comment:5 follow-up: Changed 11 years ago by jason

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

comment:6 Changed 11 years ago by robert.marik

  • Cc robert.marik added

This should fix also #9421.

comment:7 Changed 9 years ago by kcrisman

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 jdemeyer

  • Milestone changed from sage-5.11 to sage-5.12

comment:9 Changed 7 years ago by vbraun_spam

  • Milestone changed from sage-6.1 to sage-6.2

comment:10 Changed 7 years ago by rws

  • Priority changed from major to critical

Set to critical due to dependent tickets.

comment:11 Changed 7 years ago by rws

Last edited 7 years ago by rws (previous) (diff)

comment:12 in reply to: ↑ 5 Changed 7 years ago by rws

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 7 years ago by rws

  • Dependencies set to #8734

comment:14 in reply to: ↑ 3 Changed 7 years ago by rws

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

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

comment:15 Changed 7 years ago by kcrisman

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 7 years ago by kcrisman (previous) (diff)

comment:16 Changed 7 years ago by vbraun_spam

  • Milestone changed from sage-6.2 to sage-6.3

comment:17 follow-up: Changed 7 years ago by rws

  • 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 kcrisman

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 kcrisman

  • 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 more-or-less properly.

comment:20 Changed 7 years ago by rws

  • Status changed from new to 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 7 years ago by kcrisman

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 rws

  • 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 kcrisman

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 rws

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 kcrisman

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 7 years ago by rws

  • 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'.

Note: See TracTickets for help on using tickets.