-
-
Notifications
You must be signed in to change notification settings - Fork 434
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Element richcmp: never use id() #22029
Comments
comment:1
Do you plan to work on this? If yes, fill in your name as reviewer. If no, let me know. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
comment:4
Replying to @jdemeyer:
as author? owner?
I've started doing experiments, but I'll most likely need help from people who understand the parts of Sage that rely on the current behavior. At the very least I'll try to push a first draft in the next few days. |
comment:5
My main concern right now is that An option might be to try again with Another idea would be to do introduce utilities like
and then use Yet another variant would be to pass a comparison function (or, equivalently but probably better in view of the transition to python3, a Any advice? |
comment:6
Replying to @mezzarobba:
Sorry, I meant as author. |
comment:7
By the way, why did you remove the reference to the sage-devel thread? |
Author: Marc Mezzarobba |
comment:8
Replying to @mezzarobba:
Because I didn't understand how to interpret it. A hyperlink would be better. |
comment:9
Replying to @mezzarobba:
Why does it rely on sorting vertices? |
comment:10
Replying to @jdemeyer:
I personally prefer Message-Ids, as they don't depend on a particular archive... |
comment:11
Replying to @jdemeyer:
In |
This comment has been minimized.
This comment has been minimized.
comment:13
Replying to @mezzarobba:
It's also important to note the difference between old-style |
comment:14
Replying to @jdemeyer:
I'm not sure I follow you: |
comment:15
Replying to @mezzarobba:
If you have no information on the objects you're sorting, I don't think there is anything that can save you. If your objects are guaranteed to be hashable you could try sorting on the hash, but that will leave your results undefined when hashes clash. In any case, if you rely on "first try what the object implements and then use a fallback if that fails", you're doomed. In fact, if you allow your vertices to be labelled with arbitrary objects, you're already losing transitivity of equality in sage, via the standard
It seems that labels get mangled anyway, though, so I think them not being sorted properly is only a minor concern by comparison (sorry):
It seems to me the only sane approaches are to not rely on sorting (in python it seems being hashable is more ubiquitous than being sortable, so fast lookup is likely better accomplished via hash functions), or to declare that the labels are sortable (making failure a user error). This stuff causes real problems: since the old python interface for https://groups.google.com/forum/#!topic/sage-nt/aP5LP09sADY This has convinced me that the only sane approach is to deprecate "cmp" style interfaces as quickly as possible and instead rely on "richcmp", with errors for ordering if not obviously correct. |
comment:16
Here is a first attempt. All (standard, long) tests should pass unless I made a last-minute mistake. See the commit messages for some comments. I'm not 100% happy with the changes, but I don't think I can do much better in a reasonable amount of time, feel free to commit improvements to the existing branch! Last 10 new commits:
|
Commit: |
comment:17
I am a strong -1 on the removal of the The failures you have in |
comment:18
This is bad:
|
comment:19
Replying to @tscrim:
Ugly, I agree, but safer in generic code (because of cases where equality is not decidable, like expressions, or where not enough information is available, like with intervals)... And code that might end up comparing objects of different type is generic code.
I might do it, but I'd like first to understand in detail the alternative you are suggesting, and to see some evidence of a consensus that it is a better option. In any case, please feel free to commit improvements yourself, and I'll do my best to review them. |
comment:20
Replying to @jdemeyer:
What do you mean? If I understand right, this is an issue that will solve itself if sage ever switches to Python3... |
Changed branch from u/jdemeyer/22029-richcmp to u/mmezzarobba/22029-richcmp |
comment:147
As for the actual content: I'm happy with this version, and I'm ready to give it positive review once the patchbot comes back green with the new pynac release. I'm still not 100% convinced that the way you are handling non-Elements and coercion failures is optimal, but even if not, it shouldn't be too hard to change later if this turns out to be an issue. |
comment:148
The tests pass on my box. |
Changed reviewer from Julian Rüth to Julian Rüth, Marc Mezzarobba |
comment:149
Replying to @mezzarobba:
What do you mean exactly? I'm open to suggestions for improvement. What I want is that comparisons involving the coercion model behave just like comparisons in Python 3 should behave. This means: if the objects cannot be compared, raise an error instead of returning some arbitrary value. |
comment:150
Replying to @jdemeyer:
We had this discussion two years ago when I started this ticket, and frankly I don't remember all the details. But I think it revolved around the following points:
|
comment:151
Replying to @mezzarobba:
I would argue that, when there is no common parent, elements clearly cannot be equal. This is also consistent with Python 3 where uncomparable objects can still be compared by
Again, if those elements don't coerce to a common parent, they cannot be equal.
As far as I know, we are consistent.
Exactly.
Exactly. Returning
I don't remember precisely. Anyway, I changed my mind and I'm convinced now that raising an error is the right thing to do. |
Changed branch from u/mmezzarobba/22029-richcmp to |
As discussed in the sage-devel thread starting with
<o21nte$6jp$1@blaine.gmane.org>
(https://groups.google.com/d/msg/sage-devel/YVFdxPH6avk/4OZUmzLHBgAJ),coercion_model.richcmp()
should not fall back on comparing by type/id.This branch implements comparisons for
Element
the same way as in Python 3: aTypeError
is raised for uncomparable objects (instead of comparing byid
).Dependencies: #22297, #22344, #22346, #22369, #22370, #22371, #22372, #22373, #22376, #22382, #24968, #26917, #26931, #26933, #26934, #26935, #26936, #26937, #26938, #26947, #27003, #27009, #27010, #27026, #27027, #27029, #27123, #27241
Depends on #27241
CC: @fchapoton
Component: coercion
Keywords: richcmp
Author: Marc Mezzarobba, Jeroen Demeyer
Branch/Commit:
e311ab1
Reviewer: Julian Rüth, Marc Mezzarobba
Issue created by migration from https://trac.sagemath.org/ticket/22029
The text was updated successfully, but these errors were encountered: