Re: [sage-devel] Re: containment in a set different from containment in a set - help needed
> I must admit that I do not understand the philosophy.
>
Which part?
>
> But apart from that: for classes inheriting from ClonableArray, which have
> to implement equality (because there is no coercion to a common parent), do
> they have to implement _richcmp_ or __richcmp__ or _eq_ or __eq__? (The
> amount of magic in python / sagemath is extremely confusing to me.)
>
Double underscore stuff is usually Python (sometimes Cython; or mimicked
with __richcmp__). Single underscores tend to be hooks that Sage (or a
particular class) has set up to either avoid inheritance issues and/or
allow more flexibility in subclasses.
Best,
Travis
> On Tuesday, 13 December 2022 at 01:09:52 UTC+1 Travis Scrimshaw wrote:
>
>> +1 on what Nils said; I only find it slightly surprising initially.
>> Compare this with comparing a list to a Partition as well. Equality is a
>> bit different as a programming concept than a mathematical one. When you
>> implement a custom __eq__, then you are separating that class from the
>> coercion-based equality.
>>
>> +1 on removing the parent from the hash of ClonableArray and its family
>> tree.
>>
>> Best,
>> Travis
>>
>> On Tuesday, December 13, 2022 at 1:56:46 AM UTC+9 Nils Bruin wrote:
>>
>>> On Monday, 12 December 2022 at 00:22:30 UTC-8 axio...@yahoo.de wrote:
>>>
Ah, thank you so much!
Just to make sure that I understand the philosophy: if two elements are
supposed to compare equal, they should have parents which can be coerced
to
a common parent, right? For example, the following (which is current
behaviour) is not really what we want:
sage: A = SetPartitions(3)([[1,2],[3]])
sage: B = SetPartition([[1,2],[3]])
sage: A == B
True
sage: coercion_model.common_parent(A, B)
>>> TypeError: no common canonical parent for objects with parents: 'Set
partitions of {1, 2, 3}' and 'Set partitions'
>>>
I think that is a bit surprising, but if SetPartitions don't really
>>> occur much in binary operations I think it will be a hardly visible quirk.
>>> One has to be careful generalizing principles about how to implement
>>> coercion/equality/hashing because we a;ready know that some of the things
>>> we want lead to inconsistencies.
>>>
>>> When in doubt, the safe thing is definitely to NOT install coercions (it
>>> can always be done later), so I'd hesitate to recommend to change the
>>> behaviour above. I think you'd want at least a practical use case to
>>> justify it.
>>>
>>> Note that the relevant conversions: A.parent()(B) and B.parent()(A) do
>>> work.
>>>
>>> It seems to me the converse implication, if for two elements the
>>> coercion framework is happy to find a common parent in which they compare
>>> equal, then they should be equal in the first place, sounds a little more
>>> probable, but I suspect one can get problematic situations from that too.
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/5bb18894-a83f-4f3e-b3dd-b90687aaacc6n%40googlegroups.com.
Re: [sage-devel] Re: containment in a set different from containment in a set - help needed
https://trac.sagemath.org/ticket/34824 has a green bot, please review!
On Tuesday, 13 December 2022 at 10:03:20 UTC+1 Martin R wrote:
> I must admit that I do not understand the philosophy.
>
> But apart from that: for classes inheriting from ClonableArray, which have
> to implement equality (because there is no coercion to a common parent), do
> they have to implement _richcmp_ or __richcmp__ or _eq_ or __eq__? (The
> amount of magic in python / sagemath is extremely confusing to me.)
>
> On Tuesday, 13 December 2022 at 01:09:52 UTC+1 Travis Scrimshaw wrote:
>
>> +1 on what Nils said; I only find it slightly surprising initially.
>> Compare this with comparing a list to a Partition as well. Equality is a
>> bit different as a programming concept than a mathematical one. When you
>> implement a custom __eq__, then you are separating that class from the
>> coercion-based equality.
>>
>> +1 on removing the parent from the hash of ClonableArray and its family
>> tree.
>>
>> Best,
>> Travis
>>
>> On Tuesday, December 13, 2022 at 1:56:46 AM UTC+9 Nils Bruin wrote:
>>
>>> On Monday, 12 December 2022 at 00:22:30 UTC-8 axio...@yahoo.de wrote:
>>>
Ah, thank you so much!
Just to make sure that I understand the philosophy: if two elements are
supposed to compare equal, they should have parents which can be coerced
to
a common parent, right? For example, the following (which is current
behaviour) is not really what we want:
sage: A = SetPartitions(3)([[1,2],[3]])
sage: B = SetPartition([[1,2],[3]])
sage: A == B
True
sage: coercion_model.common_parent(A, B)
>>> TypeError: no common canonical parent for objects with parents: 'Set
partitions of {1, 2, 3}' and 'Set partitions'
>>>
I think that is a bit surprising, but if SetPartitions don't really
>>> occur much in binary operations I think it will be a hardly visible quirk.
>>> One has to be careful generalizing principles about how to implement
>>> coercion/equality/hashing because we a;ready know that some of the things
>>> we want lead to inconsistencies.
>>>
>>> When in doubt, the safe thing is definitely to NOT install coercions (it
>>> can always be done later), so I'd hesitate to recommend to change the
>>> behaviour above. I think you'd want at least a practical use case to
>>> justify it.
>>>
>>> Note that the relevant conversions: A.parent()(B) and B.parent()(A) do
>>> work.
>>>
>>> It seems to me the converse implication, if for two elements the
>>> coercion framework is happy to find a common parent in which they compare
>>> equal, then they should be equal in the first place, sounds a little more
>>> probable, but I suspect one can get problematic situations from that too.
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/9193dbd2-0cd4-46bb-9948-d1055d5b9a79n%40googlegroups.com.
Re: [sage-devel] Re: containment in a set different from containment in a set - help needed
I must admit that I do not understand the philosophy.
But apart from that: for classes inheriting from ClonableArray, which have
to implement equality (because there is no coercion to a common parent), do
they have to implement _richcmp_ or __richcmp__ or _eq_ or __eq__? (The
amount of magic in python / sagemath is extremely confusing to me.)
On Tuesday, 13 December 2022 at 01:09:52 UTC+1 Travis Scrimshaw wrote:
> +1 on what Nils said; I only find it slightly surprising initially.
> Compare this with comparing a list to a Partition as well. Equality is a
> bit different as a programming concept than a mathematical one. When you
> implement a custom __eq__, then you are separating that class from the
> coercion-based equality.
>
> +1 on removing the parent from the hash of ClonableArray and its family
> tree.
>
> Best,
> Travis
>
> On Tuesday, December 13, 2022 at 1:56:46 AM UTC+9 Nils Bruin wrote:
>
>> On Monday, 12 December 2022 at 00:22:30 UTC-8 axio...@yahoo.de wrote:
>>
>>> Ah, thank you so much!
>>>
>>> Just to make sure that I understand the philosophy: if two elements are
>>> supposed to compare equal, they should have parents which can be coerced to
>>> a common parent, right? For example, the following (which is current
>>> behaviour) is not really what we want:
>>>
>>> sage: A = SetPartitions(3)([[1,2],[3]])
>>> sage: B = SetPartition([[1,2],[3]])
>>> sage: A == B
>>> True
>>> sage: coercion_model.common_parent(A, B)
>>>
>> TypeError: no common canonical parent for objects with parents: 'Set
>>> partitions of {1, 2, 3}' and 'Set partitions'
>>>
>>
>>> I think that is a bit surprising, but if SetPartitions don't really
>> occur much in binary operations I think it will be a hardly visible quirk.
>> One has to be careful generalizing principles about how to implement
>> coercion/equality/hashing because we a;ready know that some of the things
>> we want lead to inconsistencies.
>>
>> When in doubt, the safe thing is definitely to NOT install coercions (it
>> can always be done later), so I'd hesitate to recommend to change the
>> behaviour above. I think you'd want at least a practical use case to
>> justify it.
>>
>> Note that the relevant conversions: A.parent()(B) and B.parent()(A) do
>> work.
>>
>> It seems to me the converse implication, if for two elements the coercion
>> framework is happy to find a common parent in which they compare equal,
>> then they should be equal in the first place, sounds a little more
>> probable, but I suspect one can get problematic situations from that too.
>>
>
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/7a14cd93-e026-4a8d-9c46-cfd35948dcbfn%40googlegroups.com.
