On Tue, Feb 26, 2013 at 10:59:26AM +, Simon King wrote:
> Namely, if I am not mistaken, comparison on elements should not be
> implemented by providing __eq__, __ne__ and __cmp__, explicitly invoking
> the coercion model. Instead, for a *Python* class, one should just define
> __cmp__ as always
Hi Simon,
On Tue, Feb 26, 2013 at 10:11:08AM +, Simon King wrote:
> Then all what I have to do is change some tests of the form
> sage: F4 == F2 # F4 was NOT defined just like F2
> Expected:
> True
> Got:
> False
>
> sage: F1.zero() == F2.zero
Hi,
On 2013-02-26, Simon King wrote:
>> That's perfect: I don't want this coercion :-)
>
> No?
> ...
> So, you *really* don't want a coercion between parents that have
> previously evaluated equal? I.e., in a case where the only difference is
> the prefix? Then I just change the test above.
And
Hi Nicolas,
On 2013-02-26, Nicolas M. Thiery wrote:
>> In my current (not yet posted) patch, the coercion is missing:
>> sage: G = CombinatorialFreeModule(ZZ, [1,2,3,4], prefix="G")
>> sage: y = CombinatorialFreeModule(ZZ, [1,2,3,4], prefix='y')
>> sage: G.has_coerce_map_from(y)
>> False
On Tue, Feb 26, 2013 at 12:20:14AM +, Simon King wrote:
> When I made CombinatorialFreeModule inherit from UniqueRepresentation (not
> only from the new CachedRepresentation), then only very few tests failed (some
> of them in my coercion tutorial). All of it easy to fix. So, I had a wrong
> me
Hi Nicolas,
On 2013-02-25, Nicolas M. Thiery wrote:
> On Mon, Feb 25, 2013 at 07:17:57PM +, Simon King wrote:
>> - Make CombinatorialFreeModule a unique parent, i.e., different prefixes
>> will result in distinct and unequal modules (as suggested by Nicolas).
>> I mentioned in my previous
On Mon, Feb 25, 2013 at 07:17:57PM +, Simon King wrote:
> - Make CombinatorialFreeModule a unique parent, i.e., different prefixes
> will result in distinct and unequal modules (as suggested by Nicolas).
> I mentioned in my previous post that this change will not be trivial,
> but perhaps
Hi Nicolas,
On 2013-02-25, Nicolas M. Thiery wrote:
> On the other hand, I personally consider that ``G == y`` is buggy: it
> should return False; the user explicitly asked for G and y to be
> distinct even if they are trivially isomorphic.
The problem that bites us here: cached_method/cached_fu
Hi Nicolas,
On 2013-02-25, Nicolas M. Thiery wrote:
> It was a design decision that the user could create his "own" free
> module by specifying a prefix, even if the base ring and index set is
> the same. So the result for ``G is y`` is as desired.
>
> On the other hand, I personally consider tha
