looking for a javascript calendar...

[RobG]

Re: looking for a javascript calendar...

Dr John Stockton wrote:
[...][color=blue]
>
> So October has 30 days in .auau ?[/color]

I think it's pronounced "Ow Ow". Thanks.
[color=blue]
>
> After if (...) return there is no need for an else.
>
> No need to test M==2 more than once.
>
> function getMonthDays(Y, M) {
> if ( M==4 || M==6 || M==9 || M==11) return 30
> if ( M==2 ) return 28 + (Y%4==0 && ( Y%100!=0 || Y%400==0))
> return 31 }[/color]

I think this one is easiest to understand, but...
[color=blue]
>
> function getMonthDays(Y, M) {
> return M==4 || M==6 || M==9 || M==11 ? 30 :
> M==2 ? 28 + (Y%4==0 && ( Y%100!=0 || Y%400==0)) : 31 }[/color]

this one has the best trade-off between simplicity and clarity.

[...][color=blue]
> The first two make a redundant test for non-centurial leap years. The
> rest would be efficient if compiled, but maybe not so when interpreted.
>[/color]

These may have their good points in terms of exploitation of
JavaScript features, but testing showed them all to take almost
exactly the same amount of time.

I had to calculate the number of days in each month of they year
for 20,000 years to get reasonable numbers (about 400ms), so I
don't think optimisation for speed is required here.

I tried optimising by first testing for months with 31 days:

return M==1 || ... M==12? 30:

but it was 10% slower - I guess all those ORs are slow.



--
Rob

[Matt Kruse]

Re: looking for a javascript calendar...

Dr John Stockton wrote:[color=blue]
> [various getMonthDays functions][/color]

I suggest putting braces and semi-colons in there. It makes code much more
readable and avoids mistakes by others if they want to modify the code. It's
always a good idea to use them, IMO.
[color=blue]
> function getMonthDays(Y, M) {
> if ( M==4 || M==6 || M==9 || M==11) return 30
> if ( M==2 ) return 28 + (Y%4==0 && ( Y%100!=0 || Y%400==0))
> return 31 }[/color]

I recommend this instead...

function getMonthDays(Y, M) {
if ( M==4 || M==6 || M==9 || M==11) {
return 30;
}
if ( M==2 ) {
if (Y%4==0 && ( Y%100!=0 || Y%400==0)) {
return 29;
}
return 28;
}
return 31;
}

It's a few bytes more than yours, but will execute with identical speed over
thousands of iterations and is much, much clearer.

Trading code clarity for compactness is a common mistake. Avoid it.

--
Matt Kruse

http://www.JavascriptToolbox.com

[Dr John Stockton]

Re: looking for a javascript calendar...

JRS: In article <0D9Sd.613$Ud4. 49129@news.optu s.net.au>, dated Mon, 21
Feb 2005 00:07:24, seen in news:comp.lang. javascript, RobG
<rgqld@iinet.ne t.auau> posted :[color=blue]
>
> I tried optimising by first testing for months with 31 days:
>
> return M==1 || ... M==12? 30:
>
> but it was 10% slower - I guess all those ORs are slow.[/color]


Just count the number of tests done for each of the 12 months, and add.

For the 7 31-day months it will be 1+2+3+4+5+6+7 = 28, for the remaining
5 months (omitting the leap part) it will be 8 each = 40, sum 68.

Test the 4 30-day months first, 1+2+3+4 = 10, the remaining 8 months
have 5 tests = 40, sum = 50.

OR should be fast; but it is another operation to do. The time taken
for operations that map well onto the instruction set will be dominated
by the time taken in handling the operands, whether compiled or
interpreted.

That's one reason why a Zeller-type arithmetic operation, if likely to
be possible, is often worth investigating - though in this case it can
be beaten.

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demo n.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demo n.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.

[Dr John Stockton]

Re: looking for a javascript calendar...

JRS: In article <cvbflh0is5@new s1.newsguy.com> , dated Sun, 20 Feb 2005
20:05:33, seen in news:comp.lang. javascript, Matt Kruse
<newsgroups@mat tkruse.com> posted :[color=blue]
>Dr John Stockton wrote:[color=green]
>> [various getMonthDays functions][/color]
>
>I suggest putting braces and semi-colons in there. It makes code much more
>readable and avoids mistakes by others if they want to modify the code. It's
>always a good idea to use them, IMO.
>[color=green]
>> function getMonthDays(Y, M) {
>> if ( M==4 || M==6 || M==9 || M==11) return 30
>> if ( M==2 ) return 28 + (Y%4==0 && ( Y%100!=0 || Y%400==0))
>> return 31 }[/color]
>
>I recommend this instead...
>
>function getMonthDays(Y, M) {
> if ( M==4 || M==6 || M==9 || M==11) {
> return 30;
> }
> if ( M==2 ) {
> if (Y%4==0 && ( Y%100!=0 || Y%400==0)) {
> return 29;
> }
> return 28;
> }
> return 31;
>}
>
>It's a few bytes more than yours, but will execute with identical speed over
>thousands of iterations and is much, much clearer.
>
>Trading code clarity for compactness is a common mistake. Avoid it.[/color]

Bloated source. The more {} one has, the longer it takes a reader to
see how they match. Code is most readable if, when indented for
structure, the indentation level changes the least and there are fewest
lines.


Yours would be improved as, in part,

if ( M!=2 ) return 31 // also get that case lexically out of the way
if (Y%4==0 && ( Y%100!=0 || Y%400==0)) return 29
return 28

which has less nesting. I'd prefer to reverse the logic of the last two
lines of that, disposing of the common case first; but that should not
affect speed.

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demo n.co.uk/> - FAQqish topics, acronyms & links;
some Astro stuff via astro.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.

[Matt Kruse]

Re: looking for a javascript calendar...

Dr John Stockton wrote:[color=blue][color=green]
>> Trading code clarity for compactness is a common mistake. Avoid it.[/color]
> Bloated source. The more {} one has, the longer it takes a reader to
> see how they match.[/color]

"Bloated"? Tell me, what advantage does your version have, other than saving
space?
As a learning/instructional tool, the version I posted is far superior. It's
also a better style for making future changes to code (although this method
itself doesn't lend itself to future changes).

Code should be written clearly and explicitly in order to increase clarity
maintainability . For use in applications or sites, it is a good idea to then
compress the original source by removing unnecessary whitespace, etc. But
for development, debugging, and sharing, more readable code is better.
[color=blue]
> Code is most readable if, when indented for
> structure, the indentation level changes the least and there are
> fewest lines.[/color]

I don't believe this is true at all.
I think your statements go against most general rules about code
readability.
[color=blue]
> Yours would be improved as, in part,
> if ( M!=2 ) return 31 // also get that case lexically out of the way
> if (Y%4==0 && ( Y%100!=0 || Y%400==0)) return 29
> return 28
> which has less nesting.[/color]

It has less nesting, but is harder to read. Furthermore, leaving out {}
increases the risk of future bugs.
And it runs at about the same speed as the better-written version.

--
Matt Kruse

http://www.JavascriptToolbox.com