#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 roed):
Replying to [comment:21 nbruin]:
> It would seem to me that storing data keyed by "imprecise" data like
p-adic numbers is likely a program error. Are we sure that allowing cached
data keyed by p-adics is essential?
Yes. The main application is for cached methods, which use dictionaries
to store the results.
In other contexts, I agree that using p-adics as keys for a dictionary is
likely a program error. But dicts and hashing are sufficiently central to
Python's idioms that being able to use them if you really need to is
convenient. I think that forcing the user to use a context is a good
compromise between not allowing dicts at all and letting them shoot
themselves in the foot by allowing inexact keys.
> The solution proposed here -- introducing a global flag to change the
semantics of comparison -- scares me. It sounds like a horrible bugtrap to
me. Note that python allows for multiple threads. Changing a global flag
like this would not only make the particular thread this happens in non-
threadsafe, but it would change the behaviour of other threads too (that
may otherwise think they are threadsafe).
I agree that it's a little scary, and Julian and I talked about threading.
Is Sage actually threadsafe? Is anyone using threading with Sage?
> I think it's even worse: whenever one uses `with
strict_precision(True):` one would need to know exactly what code gets
executed inside to know if any code there depends on the semantics of
equality testing. That's virtually impossible to do. It would certainly
mean that one cannot put that command anywhere where any remotely generic
code gets executed (because you need to *check* all the code that might
get executed).
Yes: `strict_equality` should only be turned on for actually inserting an
object into a dictionary. And the reason that it's a stack is so that you
can turn it off when calling back into generic code. But just because you
can't wrap large blocks of code in `strict_equality(True)` doesn't mean
that it's not useful. And the documentation on the context clearly
explains the dangers of using it.
> I think it's worth quite a bit to avoid having to put in this horrible
hack, including looking at the scenarios that seem to need this feature
and see how they can be rewritten to not need p-adics to be hashable.
>
> I would suggest that going the `cache_key` route is the most promissing.
p-adic numbers are then not hashable (as they are supposed to be) and
hence composite objects that hash by hashing their constituents, are not
hashable either if they contain p-adic numbers. Those objects should have
a cache_key method as a fall-back, if they are required to be "cacheable".
>
> I agree it's ugly, but it's a lot less error-prone than making equality
semantics depend on a global flag.
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`.
And if `strict_equality` is used sparingly, I don't think it's that bad.
--
Ticket URL: <http://trac.sagemath.org/ticket/20246#comment:22>
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.