BigDumbDinosaur wrote:
Ooo, that's a bit humongous. It uses a general-purpose division routine to divide by 4 when that's so simple with two right shifts. I didn't realise what the code was doing until I realised it. I would never have thought to do it that way.
I was cleaning up my general-purpose DayOfWeek routines yesterday, and they use shift-right-2, divide-by-25, shift-right-2. I had two versions, and couldn't work out which I prefered, so I've uploaded both!
One initially reduces the year MOD 400 before doing any calculations, so works up to the year 65535, but gets slower fairly quickly, the other just goes straight into the shift/div25/shift so over/under-flows at around year 52000, but is faster but slightly longer code.
BigDumbDinosaur wrote:
BigEd wrote:
We should compare the length of your code, BDD, with JGH's modified code!
Well, you can’t get something for nothing!
His is limited to a relatively small date range. Granted, most of us won’t alive and kicking by the time 2100 rolls around, so I suppose range isn’t everything. Then again, no one was paying attention to date ranges in the 1970s and the next thing you knew, it was 1999 and all that old code was a problem. 
The 32-bit UNIX year 2038 problem is only 15 years away. Jus’ sayin’.Yes, the 8-bit version is limited to an 8-bit year range, I use a modified version of it for the DOS-like 7-bit year range 1980-2107 in my code. For completeness I wanted to get it working back to 01-01-1900 as the RISC OS date epoch is 1900.
I'm sure there's probably a bit more optimisation that can be done.
Login
Register
FAQ
Search
