On Fri, Feb 26, 2010 at 3:59 PM, Florent Hivert <
florent.hiv...@univ-rouen.fr> wrote:

>       Hi there,
>
> In order to sanitize the behavior of objects, parents and elements in sage,
> I'm about to add some tests to the framework. I think they are all
> reasonable
> but I may be asking to much. Please comment about the following:
>
>  1 - Any SageObject must have an equality methods such that
>      self == self and self != None
>

I don't think this should be true for an arbitrary SageObject.  There are
some (eg subclasses of sage.factory.UniqueFactory) that are mainly used
either internally or as object constructors.  I don't think we need to
support GF == GF for example.

Requiring it for Parents and Elements seems completely reasonable on the
other hand.  Perhaps CategoryObjects as well.


>   2 - Element construction should be idempotent. More precisely, for any
>     element e within parent P, the equality P(e) == e must hold.
>     This is for example needed by the constructor of many Parent with a
> base
>     ring, such as matrices.
>

+1


>   3 - .zero() and .one() must never be mutable. I'd like to enforce this by
>     computing .__hash__(). Here I see two possibilities:
>        * decide that for any monoid M, if M.one() implement __hash__ it
> must
>          returns an int (not an Integer) and not raise an exception like in
>          sage: m = matrix([1]).__hash__()
>          ...
>          TypeError: mutable matrices are unhashable
>

I have no problem with requiring an int return value, though I'm not sure
how compliant the current sage library is with this condition.  I don't like
the requirement that __hash__ never raise an error: we want to allow mutable
matrices.


>        * decide that element of any monoid must have a __hash__ method,
>           which may raise an error for mutable element but never on .one()
>           (and .zero() in a commutative monoid).


This seems like the better option.  Though some have raised objections to
the idea of zero() and one() returning immutable elements, it did seem to be
the consensus in that thread.

David

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Reply via email to