On Mon, Jun 12, 2017 at 6:55 PM, Nils Bruin <[email protected]> wrote:
>
>
> On Monday, June 12, 2017 at 4:01:19 PM UTC-7, William wrote:
>>
>>
>> What is your definition of "hashable"? I always thought of hashable
>> as basically
>> synonymous with "immutable", except for issues of efficiency. Aren't
>> floating points
>> numbers at least immutable, even if there are various other issues with
>> them?
>>
> OK, probably floats are OK if you interpret them as a finite subset of real
> numbers that are representable in the chosen representation. Once you start
> mixing precisions, you might violate hash/equality assumptions, though:
>
> sage: R1=RealField(100)
> sage: R2=RealField(20)
> sage: a=R1(pi)
> sage: b=R2(a)
> sage: a==b
> True
> sage: hash(a)==hash(b)
> False
>
> (most of the time this might be OK, though: hash is implemented as
> hash(float(...)), so apart from rounding accidents, hashes of floats at
> precisions > 53 should be OK)
This is indeed one of the serious Sage/Python gotchas, but it doesn't
really have so much to do with non-exact objects:
sage: a = Mod(1,3)
sage: b = 4
sage: a == b
True
sage: hash(a), hash(b)
(1, 4)
The result, as we all know. is that dicts (and sets) behave in a
surprising manner depending on your perspective (mathematician or
computer scientist)...
sage: v = {a:5}
sage: v[b]
KeyError
but...
sage: v[2**65-1]
5
even though
sage: a == 4, a == 2**65-1
(True, True)
---
https://cocalc.com/projects/4a5f0542-5873-4eed-a85c-a18c706e8bcd/files/support/2017-06-12-hash.ipynb
--
William (http://wstein.org)
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
