#20246: Use `with strict_equality(True)` to work around hashing of p-adics
-------------------------------------+-------------------------------------
Reporter: saraedum | Owner:
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-7.2
Component: padics | Resolution:
Keywords: days71 | Merged in:
Authors: Julian Rüth | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/saraedum/use__with_strict_equality_true___to_work_around_hashing_of_p_adics|
f4c5a9db729ccf911517039fdced282588210133
Dependencies: #16342, #16339 | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by nbruin):
Replying to [comment:22 roed]:
> The huge problem with `cache_key` is that any object that can
recursively contain an inexact element needs to now define a `cache_key`.
Polynomials, matrices, parents that are defined by polynomials.... It's a
nightmare to add all of these `cache_keys`.
Only the ones that actually get used as cache keys need one. Using a
p-adic number as a dictionary key (including a cache) is likely a
programming/logic error, so the only places where you need to allow it is
where you think the convenience of being able to do it is sufficiently
important. There's no need to universally announce that any object
containing p-adics can be used as a cache key.
And if I understand correctly, the cache_key can be implemented quite high
in the hierarchy, so you wouldn't need to so terribly many of them, and
their implementations are trivial. I can see how it might seem like a
nightmare, but actually doing it for the cases where you need it might not
be so bad. The remaining cases will get pretty good error messages because
it's just a hashing failure.
(As an example for how seemingly nightmarish changes turn out to be not so
bad, look at #20028. In the end that wasn't nearly as bad as it seemed
when we started out. The main thing was changing doctests, and that would
not be an issue here)
> And if `strict_equality` is used sparingly, I don't think it's that bad.
I think that qualification already relegates it to a last resort solution,
only to be implemented if the others are thoroughly unworkable. And
implementing `cache_key` routines in strategic places as the need arises
should be quite workable.
I really think making the meaning of equality tests depend on the program
state is a very undesirable step to make and compared to that,
implementing some `cache_key` routines doesn't seem so bad.
--
Ticket URL: <http://trac.sagemath.org/ticket/20246#comment:23>
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 https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
