On Monday, October 27, 2014 1:13:29 PM UTC-7, Robert Bradshaw wrote: > Currently, the only place preparsing modifies valid code is for > literals, which is surprising enough but at least easy to explain. >
There is one more: the "^" -> "**" substitution. Without it I think many mathematicians would find sage's interface unacceptable, though. Changing the meaning of == depending on the context is a really scary > proposition to me. I would also argue that equality "across parents" > is the Pythonic choice: > > sage: int(1) == float(1) > True > I don't think you can extrapolate sensible behaviour for a computer algebra system out of python's standard numerical stack. For one thing, for Python, numerical parents always more or less "inject" into a common parent, so that one hash function always does the trick. In fact, since any numerical type in python is represented by (a tuple of) rational numbers, a single function defined on the rationals suffices, and this is indeed what cpython does: https://docs.python.org/3/library/stdtypes.html#hashing-of-numeric-types (I wasn't able to find a ref for Python2 on this, so I hope Python 2 does the same). As we know by allowing equality across coercion via non-injective maps we are in a fundamentally different situation for ZZ in sage already. > We should make it easier to have associative containers with this > notion of comparison if that's the crux of the issue. Most of the time I expect it would be a matter of fixing the parent/structure of keys beforehand and do any required coercions on the keys before lookup. Then the task gets reduced to ensuring that equality/hash are compatible within parents (and possibly closely affiliated structures). , e.g. compare on (parent(a), a) rather than just a. I would even consider > making > elements by default unhashable by default, and one would have to write > cache[a.key()] or cache[a.isomorphic_key()] to use them as keys. That's just horrible! the same would apply to sets of elements! Your suggestion would mean that we cannot even get the elements of ZZ/5ZZ as a set any more. I think the main thing we're finding with p-adics is that hashing/equality are mismatched *within* the parent. I think that's going too far. We'll just have to go with an equality notion in the p-adics that is consistent with a sufficiently faithful hash, and if that means that O(5^1) != O(5^3) then we'll have to live with that. I think a base line is that we should be able to have a "subset of <parent>" type that works reliably, i.e., a finite enumerated set that knows where its elements live. In practice people will probably just use python's "set" and enforce the parents themselves (or not). -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
