Re: YANFCQ [Yet Another Non-FastCode Question]: TDateTime -> uSec resolution

Lord Crc wrote:
> Hmm, I found that it's not correct in all cases. For instance, try
> passing it 1 - 1 / UsecsPerDay, ie one usec before midnight. The
> integer approach is more correct, although the naive delphi version is
> slower:

All kinds of rounding issues are playing up here. For one thing it is
imperative to carefully control the FPU control word, otherwise Round and
Trunc will perform tricks on you. Depending on the context, adding
"OneMicroSecond" (=1/USecsPerDay) will get you an integer increment of the
Usec count, or not. This drives me nuts. But this just means there's a
fundamental limitation of Double-precision math here that is difficult or
impossible to work around in all cases. For example if you set up the
TDateTime input as a pure Time (no date component) then precision is much
better than if you start with a combined Date+Time value; in this case
Frac(ATime) gets dangerously close to hacking off half-microseconds or more.

> procedure DecodeTimeUsec4(const ATime: TDateTime; out
<...> asm

Looks good, I'll give it a spin.
Thanks!

--
Kristofer


.