On Mar 22, 2010, at 2:23 AM, Mark Dickinson wrote: > Note that comparisons are a separate issue: those always need to be > done exactly (at least for equality, and once you're doing it for > equality it makes sense to make the other comaprisons exact as well), > else the rule that x == y implies hash(x) == hash(y) would become > untenable. Again, this is the pattern that already exists for > int<->float and Fraction<->float interactions: comparisons are exact, > but arithmetic operations involve a lossy conversion. My instinct says that we're asking for trouble if comparisons have different coercion rules than arithmetic operations. That would suggest that we follow the chain of lossless conversions: Fraction + float --> Fraction Fraction + decimal --> Fraction Decimal + float --> Decimal That way, arithmetic coercions match comparison coercions. We preserve get Mark's fast, clean new universal hash function. The equality/hash homomorphism is preserved. And a decimal context is not needed for any of the coercions (it is needed for the addition between two decimals once coercion has happened, but that is completely normal for Decimal so there are no surprises). Raymond
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4