+1
> Therefore, at #12290, I am fixing the hash values (and moreover I
> speed-up the hash of matrix spaces considerably).
Cool.
> However, it seems that the coercion framework relies on the bug.
> Namely, when fixing it, one gets
> sage: A = matrix(ZZ, 5, range(30), sparse=False)
> sage: B = matrix(ZZ, 5, range(30), sparse=True)
> sage: C = matrix(QQ, 5, range(30), sparse=True)
> sage: A.elementwise_product(C).is_dense()
> True
> sage: B.elementwise_product(C).is_sparse()
>
> ---------------------------------------------------------------------------
> TypeError Traceback (most recent
> call last)
> ...
> TypeError: no common canonical parent for objects with parents:
> 'Full MatrixSpace of 5 by 6 sparse matrices over Integer Ring' and
> 'Full MatrixSpace of 5 by 6 sparse matrices over Rational Field'
>
> The problem can be fixed by making matrix spaces unique parents (but I
> didn't check yet whether it creates other problems).
>
> Question to you: Do you see an obvious reason why matrix spaces should
> not be unique parents?
If at all possible, I for myself would rather have them as unique
parents.
On the other hand, I remember it was argued against it for
VectorSpaces: indeed users might want to create several copies of a
given vector space, in particular to use different scalar products.
I don't know if there are similar needs/use for matrix spaces.
In the case of VectorSpaces, I would be more in favor of having unique
parents, and making the scalar product a part of the data to construct
the vector space. That is:
VectorSpace(QQ,3, scalar_product=...)
would model QQ^3, *endowed* with the given scalar product, which is
different from QQ^3.
Also, we could still allow the user to create his/her private vector
space by specifying an extra key to the constructor (that's what
CombinatorialFreeModule does). But that might require some refactoring
and might break backward compatibility.
Cheers,
Nicolas
--
Nicolas M. Thi�ry "Isil" <nth...@users.sf.net>
http://Nicolas.Thiery.name/