Re: [AD] use double for al_current_time and al_rest?

[Elias Pschernig <elias@xxxxxxxxxx>]

On Fri, 2007-12-28 at 14:53 +0100, Andrei Ellman wrote:
>  > If we want nanoseconds instead of milliseconds, a 32-bit integer would
>  > not work though for al_get_current_time, as it would overflow pretty
>  > fast (after 4 seconds) - but both Linux and Windows timers would provide
>  > us with that precision nowadays so seems a pity just rounding it down.
> 
> Why not just use a 64-bit integer internally for representing the time. 
> While floating point numbers have a greater dynamic range, they are 
> prone to undeflow when the exponent becomes too large. A 64 bit integer 
> is equally as long as a 64 bit double.
> 
> Internally, all calculations involving the timer will be done using 64 
> bit integers. The user-level functions that access and manipulate the 
> timer will use doubles. The double will be converted to a 64-bit integer 
> before it is used in timer-calculation. Likewise, functions for 
> retrieving the timer value will convert the result to doubles. As well 
> as doubles, the timer can be set/accessed using Allegro's 'fixed' type 
> if anyone wants to set the timer using fixed's. If speed of timer 
> access/manipulation really is reqired, another set of functions can be 
> written that uses the native timer-format (64-bit integer) to avoid the 
> overhead of conversion, but the docs will recommend using a 'double' 
> number of seconds for ease of use.

Makes sense. I still think it might be overkill (as I said, for 90 days
of continuous time, the precision would stay below nanoseconds with
seconds expressed as double) - but if we would have more time related
functions like something to get the unix time and not just the time
since Allegro was initialized, this solution would combine the
advantages of both.

-- 
Elias Pschernig <elias@xxxxxxxxxx>