Pure Guess

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

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

Bonus question 3

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

Chriss

Hm, seems that was too easy to interest you.

Well, here the spoilers:

2a)

2b)

2c)

3)

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

Chriss

Quote (Chris Miller)

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.

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

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.

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

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.

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

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.

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

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.

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

Chriss

Regarding to use 979 instead of 30.59375:

Chriss