firefox global variables woes

[rh]

JRS: In article

dated Sat, 12 Feb 2005 18:06:26, seen in rh



It would be more readable, and might be better, to work along the lines
of (/* ++ */ implies conversion of range 1..12 to 0..11)

daysInMo = /* ++ */ m==2 ? expression(y) : expression(m)

++m==2 ? 28 + !(y&3 || y&15 && !(y%25)) : 28 | m>>3^m|2 }
or 28 | ( ++m==2 ? !(y&3 || y&15 && !(y%25)) : m>>3^m|2 ) }

which seem slightly faster than

28 | ( m^1 && ++m>>3^m|2 || !(y&3 || y&15 && !(y%25)) )

Right, but if utmost speed is the predominant criteria, then Lasse's
method is really the one of choice.

Also, in terms of speed of the above, I believe I can provide another
incarnation which brings a similar marginal speed advantage over the
tertiary form, and provides a clearer separation of the Feb
calculation.

But it all depends on what the goal is. Mine, in this case, happened to
be to achieve a succinct, efficient computation by taking an
interesting departure from the usual arithmetical approach in producing
a result. And I think it's good that some may wonder how that somewhat
obscure expression can possibly provide the correct result. Those
wishing to find out, aren't going to get much of a leg up with it
converted to tertiary form, which necessarily removes some of the
intentional bit mangling shortcut logic.

Your criteria may, and quite likely will, differ.

../rh

 

[Dr John Stockton]

JRS: In article <[email protected]>
, dated Sun, 13 Feb 2005 20:36:50, seen in rh

Right, but if utmost speed is the predominant criteria, then Lasse's
method is really the one of choice.

I've lost track of that one; is it the one using something like

(0xeefbb3>>(2*m))&3

for the lengths of the non-Feb months?

My present implementation of that seems of similar speed to the best of
the others; but my simple testing is better on the slower routines of a
set than on the faster ones.

Also, in terms of speed of the above, I believe I can provide another
incarnation which brings a similar marginal speed advantage over the
tertiary form, and provides a clearer separation of the Feb
calculation.

But it all depends on what the goal is. Mine, in this case, happened to
be to achieve a succinct, efficient computation by taking an
interesting departure from the usual arithmetical approach in producing
a result. And I think it's good that some may wonder how that somewhat
obscure expression can possibly provide the correct result. Those
wishing to find out, aren't going to get much of a leg up with it
converted to tertiary form, which necessarily removes some of the
intentional bit mangling shortcut logic.

Well, I have two distinct interests.

One is to find the fastest reasonably-short and compact javascript
implementation - for example, the following may be fast but is not
necessarily compact in use of storage :-

function SomeOtherRoutine(y, m) { var x = y + '' + m // Demo only
alert(x)
return x }

A = []

function ML(y, m) { var T, U
if (!(T=A[y])) A[y] = T = []
if (!(U=T[m])) T[m] = U = SomeOtherRoutine(y, m)
return U }

x = [ML(2, 4), ML(2, 4), ML(3, 5), ML(2, 4)]

which Alerts only twice but sets x to [24,24,35,24]

so clearly if SomeOtherRoutine (a stand-in for DaysinMonth) was lengthy
in execution in comparison with failing the two IF conditions AND if ML
were called repeatedly for a limited number of parameters, them ML could
beat direct use of SomeOtherRoutine. But for many combinations of y & m
with little repetition, ML is a waste of both time and space.


The other, in this specific case, is to find the "algebraically-best"
routine that uses the approximate numerical regularity of the months
(like Zeller) rather than doing bit-juggling.




I have found a published efficient-looking routine to get Week Number
(ISO 8601) from CJD (days from Julian BC 4713-01-01 00:00:00h local
time) by arithmetic without going via explicit YMD; getting day-of-week
is easy (indeed, that day was a Monday), and I have bodged Year. Has
anyone seen a routine of similar nature to do the reverse, YWD to CJD
(not necessarily in javascript)?

 

[rh]

JRS: In article

, dated Sun, 13 Feb 2005 20:36:50, seen in rh


I've lost track of that one; is it the one using something like

(0xeefbb3>>(2*m))&3

for the lengths of the non-Feb months?

That's right, except his implementation used a shift to accomplish the
multiplication by 2. However, the change doesn't appear to affect the
speed significantly.

My present implementation of that seems of similar speed to the best of
the others; but my simple testing is better on the slower routines of a
set than on the faster ones.

My timing tests, adjusting for the loop overhead, show Lasse's version
to be almost twice the speed of the others.

Well, I have two distinct interests.

One is to find the fastest reasonably-short and compact javascript
implementation - for example, the following may be fast but is not
necessarily compact in use of storage :-

function SomeOtherRoutine(y, m) { var x = y + '' + m // Demo only
alert(x)
return x }

A = []

function ML(y, m) { var T, U
if (!(T=A[y])) A[y] = T = []
if (!(U=T[m])) T[m] = U = SomeOtherRoutine(y, m)
return U }

x = [ML(2, 4), ML(2, 4), ML(3, 5), ML(2, 4)]

which Alerts only twice but sets x to [24,24,35,24]

so clearly if SomeOtherRoutine (a stand-in for DaysinMonth) was lengthy
in execution in comparison with failing the two IF conditions AND if ML
were called repeatedly for a limited number of parameters, them ML could
beat direct use of SomeOtherRoutine. But for many combinations of y & m
with little repetition, ML is a waste of both time and space.

As you say, that depends entirely on how time consuming
someOtherRoutine is. In this specific case, the computation is highly
efficient, and re-computation would surely be more appropriate, both in
time and space, than caching values.

The other, in this specific case, is to find the "algebraically-best"
routine that uses the approximate numerical regularity of the months
(like Zeller) rather than doing bit-juggling.

That sounds like fun, but I think I'll content myself with bit-munging
for the present. ;-)

<...>

../rh