number series

[Chris Miller]

How is this number series helpful?

n*30.6 rounded to whole number, ie
31,61,92,122,153,184,214,245,275,306,337

To be continued.

Chriss

 

[kwbMitel]

Pure Guess [hide]Something to do with Calendars and days of the year but that's not perfect by any stretch, even when leap years are considered[/hide]

 

[karluk]

[hide]kwbMitel is probably correct that this is related to the calendar. One interpretation that works quite well is to begin the year with March rather than January, as the ancient Romans did. Then, the pattern of 30 and 31 day months exactly reproduces Chris Miller's sequence from March through the following January.

March = 31
March (31) + April (30) = 61
March (31) + April (30) + May (31) = 92
...
March (31) + April (30) + May (31) + ... + January (31) = 337

The failure, of course, happens in the 12 months from March through the following February. The 12th term in the sequence is 367, rather than 365 or 366 using the 12 months of the calendar.[/hide]

 

[Chris Miller]

Very good, I'll wait a bit until the next step, for more to join in.

Karluk think a bit more about the range of n.

Chriss

 

[Chris Miller]

Nobody else? Okay, you're both on the right track.

This series fits to get the total days of months If you're starting in March with n=0. That means you shift a Gregorian (usual) date going back 3 months, but only add 12 when the month-3 is <0 (or more mathmatically said you get the modula 12 value). Then you have a month number from 0 to 11 which is the number of months passed since March. When you're in March no month has passed yet.

Second part of the puzzle:

The easy question:
2 a) How to determine the days passed in the current month?

The harder part:
2 b) 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?
c) what about days in February in leap years?

Chriss

 

[Chris Miller]

Bonus question 3

What about this "magic number" 30.6? is it really that magic?

Chriss

 

[Chris Miller]

Hm, seems that was too easy to interest you.

Well, here the spoilers:

2a)

Spoiler

Simple, it's just the day part of the date. 1 off, obviously. So we have a simple multiplication for getting days since 1st March. The role of years is simply another multiplication with 365.25 adn taking into account each 400 years is indeed also a leap year, but 100,200, or 300 years off of a modulo 400 = 0 year have no leap year.

2b)

Spoiler

Once you can compute days since say 1.3.0001 you could simply subtract number of days until a given date from number of days until next months first day

2c)

Spoiler

Actually doesn't matter, once you can trust the date to be valid, see 2a) and to verify leap year February length you make use of the leap year rules for addressing the role of the year date part, nothing more, nothing less.

3)

Spoiler

30.6 is not the only factor producing the number series for n= 0 to 11. It's just the shortest in decimal representation. In binary with 1/2, 174, !78 etc bits, I haven't checked whats the shortest, but it wouldn't matter much today, as floating point arithmetics is solved on the CPU ALU level and does not vary essentially no matter how many bits are set. It depends more on the floating point precision (single/double/quadruple) than on the actual bit values. Single precision is completeely sufficient.

4) Final task, how about computing the julian day number of a date knowing all that?

Chriss

 

[karluk]

What about this "magic number" 30.6? is it really that magic?

In my view the interesting question is not whether 30.6 is "magic" but whether the sequence (31,61,92,122,153,184,214,245,275,306,337) is "magic". One's gut reaction is that it's unusual for any 11 month pattern to be reproducible by a sequence generated by rounding multiples of a constant. I did a rough plot which indicates it is, indeed, unusual.

Using the assumption that the 11 month sequence contains 337 days, I found only three patterns generated by round(n*x):

30 13/22 <= x < 30 11/18 generates our actual calendar from March to January.
30 11/18 <= x < 30 13/20 generates a calendar with 30 days in April, June, September and December.
30 13/20 <= x < 30 15/22 generates a calendar with 30 days in April, July, October and January.

I have not proven that this list is exhaustive, even assuming I didn't make any calculation errors. Still, if there really are only three patterns that work, I find it remarkable that our actual calendar happens to be one of them.

 

[Chris Miller]

Maybe the reason our calendar works that way is because it was constructed that way. Though it's weird why February makes that difference. The leap day was introduced 46 BC, if Google is right. So it was rather new and why would you not try to have more similar month lengths? The year could better be divided into 13 month of each 28 days plus leap day in leap years. And one other, for example new years day. Then you could have one everlasting calendar. If you introduce the leap day as an extra week day, ie let the week with the leap day have 8 days for example ... Friday Leapday, Saturday. Dito Monday, Tuesday, New Years Day, Wednesday, etc. Then the weekday names would be constant within that calendar, too. You still could have very simlilar quarters, each 3 months + 1 week.

But it still puzzles me why the month that occasionally has the leap day wouldn't be a 30 or 31 day month. As 365.25/12 is 30.44 days there should be more 30 day months, then there wouldn't need to be a short February. A very possible difficulty of course is to get a reformation even of something as simple as a calendar in a non digital era.





Chriss

 

[karluk]

I found two more month patterns that can be generated by round(n*x). Although what I did doesn't rise to the level of mathematical proof, I was more systematic this time. There's a reasonable chance I've found all of the patterns. (Note: I did not bother to convert decimals to exact fractions. I made some mistakes when I did so in my previous post.)

30.5909 <= x < 30.6111 generates our actual calendar from March to January.
30.6111 <= x < 30.6250 generates a calendar with 30 days in April, June, September and December.
30.6250 <= x < 30.6428 generates a calendar with 30 days in April, July, September and December.
30.6428 <= x < 30.6500 generates a calendar with 30 days in April, July, October and December.
30.6500 <= x < 30.6818 generates a calendar with 30 days in April, July, October and January.

 

[Chris Miller]

karluk,

30.5909 <= x < 30.6111. That's the range for the "magic number", I thought it was a wider range, but still a bit room to wiggle room.

If there would be no valid factor, a short series with just 12 or 11 elements can always be nudged to what you want. Obviously that needs to be nonlinear, but one thing is clear: If you don't shift February to be the last month its exception would make it quite impossible to have a simple series.

The next step would be to move this from a floating point to integer arithmetic.

Chriss

 

[karluk]

Converting to exact fractions:

30 13/22 <= x < 30 11/18 generates our actual calendar from March to January.
30 11/18 <= x < 30 5/8 generates a calendar with 30 days in April, June, September and December.
30 5/8 <= x < 30 9/14 generates a calendar with 30 days in April, July, September and December.
30 9/14 <= x < 30 13/20 generates a calendar with 30 days in April, July, October and December.
30 13/20 <= x < 30 15/22 generates a calendar with 30 days in April, July, October and January.

 

[Chris Miller]

A binary factor in the valid range for our actual calendar is 11110.10011,
Multiply by 32 and you have 1111010011, that's 979. How could that be used?

Chriss

 

[karluk]

The fact that all of these ranges are bounded by exact fractions is not surprising. It's caused by the behavior of the round() function. As an example, take the 30 11/18 boundary between our calendar and one with a 30 day December. Using Chriss's magic number x=30.6, the ninth month, November, has a function value of round(9 * 30.6) = round(275.4) = 275. November's value of 275 comes from rounding down. As x continues to increase, there will come a point at which November gets rounded up to 276. The calendar interpretation of this is that November has become a 31 day month, taking a day away from December, which is now a 30 day month. Algebraically, we need 9 * x = 275.5 or x = 30 11/18 as the transition point.

The upper boundary of each range is determined by which 30 day month goes most quickly from rounding down to rounding up. This leads to an iterative process for calculating the five ranges listed above. The process ends when x gets large enough to make the entire 11 months contain more than 337 days.

 

[Chris Miller]

Maybe you still think of n>11? Then let me help by stating the days of whole years will not be computed from extending the series but from the year including leap year rules.
But regarding calendar reforms that would work better indeed months would need to be redefined, even if you want to stay with 12 months.

The reason to switch to integer is that integer arithmetic is faster than floating point. Another hint: Think about what the factor 979 instead of 30.59375 means and how it effects rounding.

Chriss

 

[karluk]

Sorry, Chris. I'm in real danger of hijacking this thread. I have more to say about round(n*x) functions, but my remarks are increasingly off topic for this thread. I will probably start a separate thread so I have a fresh place to record my thoughts.

 

[Chris Miller]

I look forward to that. I am not at all against spawning ideas that lead to a totally new thread.

Chriss

 

[Chris Miller]

Regarding to use 979 instead of 30.59375:

Spoiler

Well, as said this is 32x the factor for days, but you could now do integer arithmetics, which is faster. You just have to round to the next multiple of 32 and finally divide by 32 to get days.

The reference still is round(n*30.6), with n between 1 and 11:
31,61,92,122,153,184,214,245,275,306,337
n*979+16 bitwise and 0xffe0, with n between 1 and 11 (the +16 is like adding +.5 to the normal product for rounding by the ceiling function):
992, 1952, 2944, 3904, 4896, 5888, 6848, 7840, 8800, 9792, 10784
That Divided by 32 (or shifted right 5 bits:
31,61,92,122,153,184,214,245,275,306,337

Chriss