Equality of expressions (inside a matrix)

[Jan Groenewald]

Hi

Is this the intended behaviour, for A==B to say False instead of returning the expression?

sage: A=matrix([(x+1)*(x-1)]); B=matrix([x^2-1]);
sage: A==B
False
sage: A.simplify_rational()==B
True

This is not popular with our students. Some other examples...

sage: (x+1)*(x-1) == x^2-1  
(x - 1)*(x + 1) == x^2 - 1
sage: ((x+1)*(x-1)).simplify_rational() == x^2-1
x^2 - 1 == x^2 - 1
sage: x == x
x == x
sage: x == 3
x == 3
sage: x=3
sage: x == 3
True
sage: x == x
True


Regards,
Jan

--
  .~.
  /V\     Jan Groenewald
 /( )\    www.aims.ac.za
 ^^-^^

[Timo Kluck]

Op dinsdag 12 maart 2013 13:23:20 UTC+1 schreef Jan Groenewald het volgende:

sage: x == x

x == x
sage: x == 3
x == 3
sage: x=3
sage: x == 3
True
sage: x == x
True

This one is only confusing in an interactive session. Sage defers checking an expression for validity (and calling Maxima) as long as possible. Note that

    sage: if x == x: print("True")
    True

because we implicitly force it to a bool.

In general, it is desirable to defer this (possibly extremely slow!) truth evaluation as long as possible, but maybe it makes sense to at least want to do this before displaying it. So maybe it can be in an expressions's __repr__ function? I suggest checking it for truth and if that yields a definite answer (can we know that?), return repr(True) or repr(False) instead of the expressions representation.

Timo
 

[kcrisman]

This also came up on a Facebook post with regard to the following (somewhat simplified):

sage: var('x,y')

(x, y)

sage: A = vector([x])

sage: B = vector([y])

sage: A == B

False

I think it's possible for us to ask for more delay in such evaluation, but I suspect we'd have to make objects "symbolic".  Or would it be possible to override  __eq__() for this?  We do that for a lot of other things, but (perhaps ironically) it isn't necessary for symbolic expressions, since they (including ones like x == x) initialized via Gi/Pynac and so circumvent this, as far as I could tell.

- kcrisman

[Timo Kluck]

Op dinsdag 12 maart 2013 14:24:02 UTC+1 schreef kcrisman het volgende:

This also came up on a Facebook post with regard to the following (somewhat simplified):

sage: var('x,y')

(x, y)

sage: A = vector([x])

sage: B = vector([y])

sage: A == B

False

I think it's possible for us to ask for more delay in such evaluation, but I suspect we'd have to make objects "symbolic". 

I would personally love to be able to do something like this:

sage: var('x,y', parent=VectorSpace(CC,2))
sage: x * y
TypeError
sage: var('M', parent=GL(CC, 2))
sage: M*x == y
M * x == y

and then be able to substitute y = vector([1,2]), M = matrix([[1,2],[3,4]]) into these expressions and solve for x ... Of course, we could write down these kind of examples with more complicated rings/modules/(non-cummutative) algebras/Lie algebras instead.

Has anyone ever made efforts in that direction?
Timo

[Nils Bruin]

On Mar 12, 5:23 am, Jan Groenewald <j...@aims.ac.za> wrote:
> Hi
>
> Is this the intended behaviour, for A==B to say False instead of returning
> the expression?
>
> sage: A=matrix([(x+1)*(x-1)]); B=matrix([x^2-1]);
> sage: A==B

> *False*
> sage: A.simplify_rational()==B
> *True*

What surprises me is that equality testing of matrices with SR
elements seems more picky than pairwise equality testing of their
entries, not that it gets eagerly converted to a boolean (as in most
of sage), rather than turned into a "symbolic equation" (as happens
with SR elements).

Indeed,

sage: [ bool(a==b) for a,b in zip(list(A),list(B))]
[True]

so it may be worth looking into. I would expect that "A==B" would give
the same result as

sage: all(a for a,b in zip(list(A),list(B)) if a==b)
True

and it doesn't.

If you would prefer that

_(x,y)=0
A=matrix([x])
B=matrix([y])
A==B

returns a symbolic equation rather than True/False you would need to
change Matrix_symbolic_dense. In the process, you'd probably have to
break its inheritance from Matrix as well, so you'd end up
implementing the whole linear algebra stack separately. You'd also
have to somehow account for a "Matrix_symbolic_dense" being a
component of " ... == ..." and hence being an element of SR itself. It
would make SR even more of a black hole than it already is.

In return, you might be able to write

det( matrix[[a,b],[c,d]]^n - matrix[[1,0],[0,1]])

whether you'd be able to do anything with it would depend on the
various back-ends.

[Simon King]

Hi Jan,

On 2013-03-12, Jan Groenewald <j...@aims.ac.za> wrote:
> sage: A=matrix([(x+1)*(x-1)]); B=matrix([x^2-1]);
> sage: A==B

> *False*
> sage: A.simplify_rational()==B
> *True*

>
> This is not popular with our students. Some other examples...
>
> sage: (x+1)*(x-1) == x^2-1
> (x - 1)*(x + 1) == x^2 - 1
> sage: ((x+1)*(x-1)).simplify_rational() == x^2-1
> x^2 - 1 == x^2 - 1
> sage: x == x
> x == x
> sage: x == 3
> x == 3
> sage: x=3
> sage: x == 3
> True
> sage: x == x
> True

Are all your examples of this kind? Then why are you using symbolic
expressions at all? If your students would use proper polynomials
instead (P.<x> = QQ[], for example), they would get what they expect in
the examples above.

Cheers,
Simon

[Jan Groenewald]

Hi

No, the core example is inside a matrix

A==B
False
A.simplify_rational()==B
True

That is not good. Worth a ticket?

Regards,

Jan

--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
To post to this group, send email to sage-...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Simon King]

Hi Jan,

On 2013-03-14, Jan Groenewald <j...@aims.ac.za> wrote:
> --e89a8f83aa332c3afc04d7e540f8

> No, the core example is inside a matrix

I don't understand what you mean by this.

> A==B
> False
> A.simplify_rational()==B
> True
>
> That is not good. Worth a ticket?

I don't think so. I guess there is a good reason not to simplify
symbolic expressions by default.

As I said in my previous post: Provided that all your examples are
with matrices whose coefficients are polynomials, your students
should simply work with matrices over a polynomial ring.

Such as:
sage: P.<x> = CC[]

sage: A=matrix([(x+1)*(x-1)]); B=matrix([x^2-1])
sage: A == B

True

Of course, the matrices would then not have a simplify_rational method.

Generally, it seems to me that one should use the symbolic ring only
when really needed.

Best regards,
Simon

[Michael Orlitzky]

On 03/14/2013 03:34 PM, Simon King wrote:
> Hi Jan,
>
> On 2013-03-14, Jan Groenewald <j...@aims.ac.za> wrote:
>> --e89a8f83aa332c3afc04d7e540f8
>> No, the core example is inside a matrix
>
> I don't understand what you mean by this.
>
>> A==B
>> False
>> A.simplify_rational()==B
>> True
>>
>> That is not good. Worth a ticket?
>
> I don't think so. I guess there is a good reason not to simplify
> symbolic expressions by default.

I disagree; I'd create one even if nobody wants to fix it at the moment.
The problem here isn't about simplification -- equal expressions become
unequal when you wrap them in a matrix:

sage: f = x*(x+1)
sage: g = x^2 + x
sage: bool(f == g)
True
sage: bool([f] == [g])
True
sage: bool(matrix([f]) == matrix([g]))
False

> As I said in my previous post: Provided that all your examples are
> with matrices whose coefficients are polynomials, your students
> should simply work with matrices over a polynomial ring.

Ideally, yeah, everyone would be using polynomials. But you learn [a] ==
[b] before you learn what a ring is. And sage's interface to a lot of
this stuff is nonsensical unless you've had a few algebra classes. Plus,
there are a lot of nice methods available on symbolic expressions that
aren't there for polynomials. And you can reuse some of what you know
from e.g. Mathematica there.

There are plenty of reasons to choose (or be stuck with) symbolic
expressions, so the fact that they're not the best tool for the job
shouldn't dissuade us from fixing what looks like a bug to me.

[David Roe]

>>
>> That is not good. Worth a ticket?
>
> I don't think so. I guess there is a good reason not to simplify
> symbolic expressions by default.

I disagree; I'd create one even if nobody wants to fix it at the moment.
The problem here isn't about simplification -- equal expressions become
unequal when you wrap them in a matrix:

  sage: f = x*(x+1)
  sage: g = x^2 + x
  sage: bool(f == g)
  True
  sage: bool([f] == [g])
  True
  sage: bool(matrix([f]) == matrix([g]))
  False

+1.  I think this is a bug and we should have a ticket for it.
David

[Simon King]

Hi Michael,

On 2013-03-15, Michael Orlitzky <mic...@orlitzky.com> wrote:
> sage: bool(f == g)
> True
> sage: bool([f] == [g])
> True
> sage: bool(matrix([f]) == matrix([g]))
> False

Ah, I missed that the coefficients do evaluate equal. In this case, I
agree it is a bug.

Cheers,
Simon

[Jan Groenewald]

This is now http://trac.sagemath.org/sage_trac/ticket/14277

--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
To post to this group, send email to sage-...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.