[Disclaimer: "comparison" here only means testing for equality here,
"comparison" in the sense of testing for a (partial) ordering.]
On Sep 15, 5:13 am, Simon King <simon.k...@uni-jena.de> wrote:
> Hi!But then the only bug-less hash functions on the integers are the
> I think we are talking about two different topics here, that should be
> 1) The hash must obey the law. If you find two objects that evaluate
trivial ones, due to GF(p)(a) == a+p.
> Other CAS (Sage, but also Magma, IIRC) would say that "a!=b for elementsMagma draws a different conclusion, though. Comparison of ZZ(1) and
> of different parent" is *impractical*.
GF(p)(1) raises an error. There is another operator 'cmpeq' that
returns false if 'eq' would give an error and the result of 'eq'
otherwise. For instance, a dictionary (associative array) needs a
universe declared (parent for the keys) so that it's clear what
Floats are not a main concern in Magma, however, and some different
> RealField(10)!(1/3) eq RealField(20)!(1/3);
> As long as the pushout is canonical (which might be difficult to prove, so,That does break transitivity of equality rather thoroughly. If you
> there could be bugs in it as well), it totally makes sense to say:
> "a==b holds, because R=GF(2)['x'] is the pushout of GF(2) and ZZ['x'],
> and R(a)==R(b)."
want to insist hashing is coarser than equality (along *any* path) you
quickly arrive at only trivial hash functions, due to 0 == GF(3)(0) ==
3 == GF(2)(1) == 1 and the fact that hash equality is necessarily
I suspect this is because we allow quotient operations in automatic
> [equality] Being intransitive, elements are bad cache keys with the usual ==. OneYou've just made RJF's weekend, and given an indication that
> could argue that users should be aware of it and take precautions. But
> it would be nice to support the user by, say, a version of
> cached_function that uses a different key comparison.
Greenspun's tenth rule can probably be extended beyond C and Fortran.
This is why lisp has a whole bunch of different equality test (equal,
eq, eql, equalp). Whatever you're going to add, it probably needs
> It would be easy to define a "cached_by_id" decorator, that returns aThat would not solve the "fuzzy" problem, which I think is the most
> cached function, so that parents on the argument list are compared by
> identity, and everything else (in particular, any element) is compared
> in a coercion-free way: "parent(X) is parent(Y) and X==Y". Namely, if
> parent(X) is parent(Y) then X==Y will not rely on coercion.
likely to cause insidious bugs. I think within parent, "hash" (if it
exists) should be strictly coarser than equality.
At the same time, one gains a lot of (untrustworthy) functionality by
This is incredibly useful in practice. Yes, the proper approach is to
I'm not so sure that being hashable is so essential, so my initial bet
The other problem, that dictionaries with keys from different parents
If the "stronger comparison" is only to take into account the parents
as key (for suitable definition for "parent"). I would expect the
Please don't use is_identical(). Identity already has a meaning in
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.