#14054: Cythoned UniqueRepresentation
-----------------------------------------------+----------------------------
Reporter: SimonKing | Owner: tbd
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-5.8
Component: performance | Resolution:
Keywords: cython UniqueRepresentation | Work issues:
Report Upstream: N/A | Reviewers: Travis
Scrimshaw
Authors: Simon King | Merged in:
Dependencies: #14017 | Stopgaps:
-----------------------------------------------+----------------------------
Comment (by tscrim):
Hey,
Replying to [comment:17 nbruin]:
> What's your rationale to define 'a < b' etc. when `a is b`? I agree that
it's likely that your answers are what any ordering override will want,
but Python does not mandate any particular properties of semantics of
these operators. So I think the proper thing is to just not do anything
there. It's going to be a rare occasion anyway, so a little speed gain
won't be very noticeable anyway.
So how would you want comparisons in the complex numbers to behave? In
python, they return an error:
{{{
sage: complex(2+2*i) < complex(2-2*i)
---------------------------------------------------------------------------
TypeError Traceback (most recent call
last)
<ipython-input-2-ce2e269601f6> in <module>()
----> 1 complex(Integer(2)+Integer(2)*i) <
complex(Integer(2)-Integer(2)*i)
TypeError: no ordering relation is defined for complex numbers
}}}
However in sage they are not so well-behaved (see #14088):
{{{
sage: CC(1+2*i) < CC(2-2*i)
True
}}}
so there's no prescribed sage way.
As far as the actual comparison code, I think it would be better to do
something like
{{{
if m == 2:
return True
elif m == 3:
return False
else:
return m == 1 or m == 5
}}}
but this is a micro-optimization, so feel free to ignore this.
> The behaviour you are implementing is much easier to explain if you
don't override those cases: Then you can just say that `WithRichCmpById`
provides `__hash__`, `__eq__` and `__ne__`, period.
>
> I think `WithEqualityById` would make a better conceptual name that is
less dependent on the implementation, by the way. Your motivation here
seems to be as much to provide conceptual units in preference of just
technical implementation tools as to provide more efficient
implementations. Someone writing a Python class may not know what
"richcomp" is, and doesn't need to.
I believe the response to both of these points depends on how we want to
do comparison between objects (when there is not a [natural] ordering).
Last thing for now, shouldn't we issue a deprecation warning for
`FastHashable_class` since it has changed locations?
Thanks,[[BR]]
Travis
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14054#comment:18>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
