# symbolic variable treated as sqrt(-1) when it shouldn't be

8 views

### William Stein

Sep 3, 2009, 2:28:05 PM9/3/09
to sage-devel
Hi Sage-Devel,

What do you think of this:

sage: var('x, i')
sage: solve(x^2 + i == 0, x)
[x == -sqrt(-I), x == sqrt(-I)]

Basically, I make a purely symbolic variable which I happen to call
"i", and it gets treated somewhere (presumably in Maxima) as if it
were sqrt(-1).

Here is another instance of this:

sage: var('i')
i
sage: a = i^2
sage: a
i^2
sage: a.simplify_full()
-1

So Ginac treats things fine, but our use of Maxima messes it up.

This came up for me just now when doing some symbolic calculation with
a quaternion algebra where the generators are called "i,j,k", and this
i has nothing to do with sqrt(-1).

Thoughts?

William

--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

### kcrisman

Sep 3, 2009, 3:49:04 PM9/3/09
to sage-devel

On Sep 3, 2:28 pm, William Stein <wst...@gmail.com> wrote:
> Hi Sage-Devel,
>
> What do you think of this:
>
> sage: var('x, i')
> sage: solve(x^2 + i == 0, x)
> [x == -sqrt(-I), x == sqrt(-I)]
>
> Basically, I make a purely symbolic variable which I happen to call
> "i", and it gets treated somewhere (presumably in Maxima) as if it
> were sqrt(-1).
>
> Here is another instance of this:
>
> sage: var('i')
> i
> sage: a = i^2
> sage: a
> i^2
> sage: a.simplify_full()
> -1
>
> So Ginac treats things fine, but our use of Maxima messes it up.
>
> This came up for me just now when doing some symbolic calculation with
> a quaternion algebra where the generators are called "i,j,k", and this
> i has nothing to do with sqrt(-1).
>
> Thoughts?
>
> William
>

I see your point. I guess to me it's another instance of the "should
x be predefined" question - on the whole, it's better to make this
available. It is also annoying when doing [f(i) for i in indexset],
but unless we can come up with another way to represent this, it will
be hard to do things with complexes very easily. Luckily for me, I
don't usually need that, but others may very often. Does this happen
with 'e' as well, or is that defined as a constant rather than a
variable? It seems like both are "symbolic.expression.Expression.

What do the other major systems do with this - do they insist on sqrt
(-1) or CC(i) or something like that? If everyone expects this coming
in, it is an argument for it - not decisive, but a significant
argument.

- kcrisman

### William A. Stein

Sep 3, 2009, 4:00:04 PM9/3/09
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. It's a bug, because
irregardless of anything being predefined, it makes no sense that
simplifying via *maxima* would just happen to decide that the formal
variable "i" is sqrt(-1), even though it isn't with Ginac.

William

### Jason Grout

Sep 3, 2009, 4:14:51 PM9/3/09
William Stein wrote:
> Hi Sage-Devel,
>
> What do you think of this:

I think you are right that this is a huge bug in our interface to maxima.

Jason

--
Jason Grout

### Golam Mortuza Hossain

Sep 3, 2009, 6:32:14 PM9/3/09
Hi,

On Thu, Sep 3, 2009 at 5:00 PM, William A. Stein<wst...@gmail.com> wrote:
>>> sage: var('i')
>>> i
>>> sage: a = i^2

>>> sage: a.simplify_full()
>>> -1

> 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.    It's a bug, because
> irregardless of anything being predefined, it makes no sense that
> simplifying via *maxima* would just happen to decide that the formal
> variable "i" is sqrt(-1), even though it isn't with Ginac.

This seems to be a problem with the way Sage convert back
maxima-returned string intro SR. So Maxima is NOT doing anything
wrong.

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

So as you see, we are converting both '%i' and 'i' to imaginary 'I' !!!!

Cheers,
Golam

### William Stein

Sep 3, 2009, 6:59:18 PM9/3/09
to sage-devel
2009/9/3 Golam Mortuza Hossain <gmho...@gmail.com>:

Yes, that completely nails down the bug. Thanks. This is now 6882:

http://trac.sagemath.org/sage_trac/ticket/6882

William