number series (continued)
number series (continued)
(OP)
As contiuation of thread1551-1811866: number series
Let me spoil as far as the series has to do with the calendar. I think it's still appropriate to wish you a Happy New Year and I thought I'd continue with the puzzle a bit.
Further spoilers and explanations in spoiler tags...
First a summary of the questions asked:
31,61,92,122,153,184,214,245,275,306,337
1. How is this number series helpful.
It's created by rounding n*30.6 to the nearest whole number.
2a) How to determine the days passed in the current month? See spoiler in the linked thread, in short:
2b) when you don't want to rely on the date having a correct day part, what can you do, besides knowing how long months are?
2c) what about days in February in leap years?
3) What about this "magic number" 30.6? is it really that magic?
4) Final question: How about computing the (a) Julian day number of a date knowing all that?
I'll get back to this in a few days. Greetings, especially to karluk.
Let me spoil as far as the series has to do with the calendar. I think it's still appropriate to wish you a Happy New Year and I thought I'd continue with the puzzle a bit.
Further spoilers and explanations in spoiler tags...
First a summary of the questions asked:
31,61,92,122,153,184,214,245,275,306,337
1. How is this number series helpful.
It's created by rounding n*30.6 to the nearest whole number.
2a) How to determine the days passed in the current month? See spoiler in the linked thread, in short:
Spoiler:
Well, that's simply the days of a date, or off by one, if you want to be strict.
2b) when you don't want to rely on the date having a correct day part, what can you do, besides knowing how long months are?
2c) what about days in February in leap years?
Spoiler:
The previous spoiler suggests computing the difference of an entered date (assumed to be correct) to the first of next month (which is easy to construct without knowing month length, of course), and then compute the difference. The difference of 29th February to 1st March in leap years will be 1, indicating that there is the leap day, or 0 in non-leap years. That implies having such a formula, the number series points in that direction, while it starts counting on March 1st and is not yet clear on how to deal with January and February dates, but we'll get there.
The goal now has shifted to computing a day number, yet another spoiler: The goal is a Julian day number, that's the number of days past a specific ultimo date. It doesn't have to be that specific, any ultimo date is okay to be able to use such a day number for further usual date computation problems like date differences (they simply become differences of day numbers) or determining the weekday (make any Monday or Sunday the ultimo date and weekdays become the day number mod 7). It's also the base idea of UNIX timestamps in seconds or nanoseconds, but one step after the other...
The goal now has shifted to computing a day number, yet another spoiler: The goal is a Julian day number, that's the number of days past a specific ultimo date. It doesn't have to be that specific, any ultimo date is okay to be able to use such a day number for further usual date computation problems like date differences (they simply become differences of day numbers) or determining the weekday (make any Monday or Sunday the ultimo date and weekdays become the day number mod 7). It's also the base idea of UNIX timestamps in seconds or nanoseconds, but one step after the other...
3) What about this "magic number" 30.6? is it really that magic?
Spoiler:
30.6 is just the shortest in decimal representation. There is a small window from about 3.591 to 3.681 where this works. Which is not to be expected from computing 365/12. For a whole year the short February skews it too much, but when starting to count in March it evens out better, the average month length of March to next years January is 337/11, approximately 30.64 days.
Correction of my previous spoiler: In binary with bits of value 1/2, 1/4, 1/8, 1/16, etc. , I haven't checked what's the shortest. I later came up with 979, binary 1111010011. If you divide that by 32 you get exactly 30.59375, which is near 3.6 and, more important, within the valid interval. Karluk computed the interval more precise in the form of quotients, by the way. The main advantage is now you can do integer operations, which run much faster than floating point.
Correction of my previous spoiler: In binary with bits of value 1/2, 1/4, 1/8, 1/16, etc. , I haven't checked what's the shortest. I later came up with 979, binary 1111010011. If you divide that by 32 you get exactly 30.59375, which is near 3.6 and, more important, within the valid interval. Karluk computed the interval more precise in the form of quotients, by the way. The main advantage is now you can do integer operations, which run much faster than floating point.
4) Final question: How about computing the (a) Julian day number of a date knowing all that?
I'll get back to this in a few days. Greetings, especially to karluk.
Chriss
RE: number series (continued)
Thank you very much for following up on the earlier thread. I will be very interested to see where your calculations take you.
RE: number series (continued)
And after I reimplemented my idea I found the JS code I wrote earlier in my browsers devtools.
Now I have two implementations that are not fully congruent in their results and I have to find out whather the old or the new me is right, so to say.
In short the idea is:
Spoiler:
Once you have such a number you have a general measure of past days since some ultimo date and can transpose between different calendars. And the fun is it all is just some simple integer maths.
Chriss
RE: number series (continued)
Still, I think it's nice to see a way of calculating this from scratch with simple math.
Spoiler:
CODE
My next steps will be enriching this with date transposing to other calendars including historic calendars, taking into account where which calendar was introduced. But this will just be tedious.
Chriss