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

[Elias Pschernig <elias@xxxxxxxxxx>]

On Thu, 2007-12-27 at 14:06 -0800, Chris Robinson wrote:
> On Thursday 27 December 2007 09:49:15 am Elias Pschernig wrote:
> > Yes, but as I said, this is very unlikely to be an isse - for a timespan
> > of 90 days double would stay at nanosecond precision (whereas the
> > current version already would wrap around the milliseconds at 50 days).
> 
> Except it's easier to handle integer overflow (use unsigned values and just 
> subtract differences), whereas floats/doubles would just continue to count 
> upward, losing more and more decimal precision and eventually losing 
> whole-number precision, until hitting Inf or NaN or something and grinding to 
> a halt.

Yes, but who will let their program run for a year? :P Anyway, maybe we
can add a function: al_set_current_time(double t) which resets the value
(might also be useful if we keep an integer value) - to better allow
handling overflow. I.e. the user could then simply reset each day
instead of having to deal with the 50 or how many days, depending on
what type is used.

> Plus, with doubles being 64-bit, on 32-bit compilers (GCC at least), they'll 
> be passed through memory by a hidden reference (unlike 32-bit floats that can 
> be passed on the stack/in registers).

I have no 32-bit compiler to test with, but I doubt that would matter. I
always used lots of sqrt/sin/cos and so on in 32-bit programs who all
use double and never noticed performance hits by it.

> IMO, al_rest() might work well with a float taken in seconds (rest time isn't 
> gauranteed to be accurate anyway), but al_current_time() would be best as an 
> integer value of some sort.

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.

-- 
Elias Pschernig <elias@xxxxxxxxxx>