#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.

Reply via email to