On Apr 13, 2004, at 4:34 PM, Paul Moore wrote:
> "Batista, Facundo" <FBatista at uniFON.com.ar> writes:
>
> [...]
>
>> Actually, imposing the limit means more code and complexity, and I
>> don't
>> find any benefit. But as I answered to Paul, I'm searching for
>> community
>> agreement before changing functionality that I found in the
>> implementation
>
> [...]
>
>> So, while Decimal(25) == 25 is True, hash(Decimal(25)) should be
>> equal to
>> hash(25).
>>
>> The detail is that you can NOT compare Decimal to floats or strings,
>> so
>> maybe we should not worry about them to give the same hashes.
>>
>> I'm OK to make hash(int or long) == hash(Decimal(int or long)). But
>> only to
>> int or long, not float nor string.
>>
>> Do you agree?
>
> So far, I've found your instincts to be pretty good. I'd say
>
> 1. Remove the limits.
> 2. Make hashes the same for int/long, but not str/float.
Make hash(Decimal('123.1')) == hash(Decimal('123.1')) .. there is no
reason not to. What's the point of having a Decimal type if the only
way to get an accurate representation of a non-integer is to do some
garbage like Decimal(1231)/Decimal(10)?
hash(float(1.0)) == hash(Decimal(1)) comes for free, because
hash(float(1.0)) == hash(1). For the few other non-integer numbers
that can be accurately represented as floating point, it might make
sense to keep the same property? Though I suppose that is pretty
what-the-heck-does-C-do specific, so I wouldn't blame anyone if this
property couldn't be maintained.
> 3. While I'm at it, I'm OK with the names you suggest for the 3 extra
> functions.
-bob
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