Bill Stoddard wrote:
Work up a patch to the apr_time macros and I'll benchmark it. This should be
an easy and non intrusive thing to do.
I tried to create a patch yesterday, but no luck. Given the
wide range of values over which the macro has to work, I couldn't
come up with with a macro that was
ject: approximating division by a million Re: Why not POSIX time_t?
>
>
> Building upon Cliff's formulas, here's another idea
> for doing faster conversions of the current apr_time_t
> format to seconds:
>
> What we want is t/100
>
> What we can do easily i
Ben Laurie wrote:
Brian Pane wrote:
Building upon Cliff's formulas, here's another idea
for doing faster conversions of the current apr_time_t
format to seconds:
What we want is t/100
What we can do easily is t/1048576
But what can we add to t/1048576 to approximate t/100?
If I solve for 'C
Brian Pane wrote:
Building upon Cliff's formulas, here's another idea
for doing faster conversions of the current apr_time_t
format to seconds:
What we want is t/100
What we can do easily is t/1048576
But what can we add to t/1048576 to approximate t/100?
If I solve for 'C' in
t/100 =
Building upon Cliff's formulas, here's another idea
for doing faster conversions of the current apr_time_t
format to seconds:
What we want is t/100
What we can do easily is t/1048576
But what can we add to t/1048576 to approximate t/100?
If I solve for 'C' in
t/100 = t/1048576 + t/C
I
Cliff Woolley wrote:
On Mon, 15 Jul 2002, Brian Pane wrote:
seconds = (t >> 20) + (t >> 24)
That probably isn't accurate enough, but you get the basic idea:
sum a couple of t/(2^n) terms to approximate t/100.
What do you think?
Sounds like the right idea. But I'm still not sure this i
On Mon, 15 Jul 2002, Brian Pane wrote:
> seconds = (t >> 20) + (t >> 24)
>
> That probably isn't accurate enough, but you get the basic idea:
> sum a couple of t/(2^n) terms to approximate t/100.
>
> What do you think?
Sounds like the right idea. But I'm still not sure this isn't too
compli
