On Thu, Feb 2, 2012 at 10:45 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 2 February 2012 12:16, Victor Stinner <victor.stinner at haypocalc.com> wrote:
>> Let's take an NTP timestamp in format (c): (sec=0,
>> floatpart=100000000, divisor=2**32):
>>
>>>>> Decimal(100000000) * Decimal(10)**-10
>> Decimal('0.0100000000')
>>>>> Decimal(100000000) / Decimal(2)**32
>> Decimal('0.023283064365386962890625')
>>
>> You have an error of 57%. Or do you mean that not only 2**32 should be
>> modified, but also 100000000? How do you adapt 100000000 (floatpart)
>> when changing the divisor (2**32 => 10**-10)? The format (c) avoids an
>> operation (base^exponent) and avoids loosing precision.
>
> Am I missing something? If you're using the fixed point form
> (fraction, exponent) then 0.023283064365386962890625 would be written
> as (23283064365386962890625, -23). Same precision as the (100000000,
> base=2, exponent=32) format.
Yeah, Victor's persuaded me that the only two integer based formats
that would be sufficiently flexible are (integer, numerator, divisor)
and (integer, mantissa, base, exponent). The latter allows for a few
more optimised conversions in particular cases. Assuming a base of 10
would just make things unnecessarily awkward when the underlying base
is 2, though.
However, I think it's even more right to not have a protocol at all
and just use decimal.Decimal for arbitrary precision timestamps
(explicitly requested via a flag to preserve backwards compatibility).
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
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