Quick question: many types have methods one_element() and zero_element() which are used a lot. For example, ZZ.one() and ZZ.zero() are aliases for ZZ.one_element() and ZZ.zero_element(). Is your intention to deprecate these longer names?
John On 26 February 2010 21:16, David Roe <r...@math.harvard.edu> wrote: > > > 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 > -- 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
