## number series

## number series

(OP)

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.

n*30.6 rounded to whole number, ie

31,61,92,122,153,184,214,245,275,306,337

To be continued.

Chriss

## RE: number series

## Hidden:

## RE: number series

## Hidden:

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.

## RE: number series

Karluk think a bit more about the range of n.

Chriss

## RE: number series

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

## RE: number series

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

Chriss

## RE: number series

Well, here the spoilers:

2a)

## Spoiler:

2b)

## Spoiler:

2c)

## Spoiler:

3)

## Spoiler:

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

Chriss

## RE: number series

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.

## RE: number series

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

## RE: number series

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.

## RE: number series

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

## RE: number series

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.

## RE: number series

Multiply by 32 and you have 1111010011, that's 979. How could that be used?

Chriss

## RE: number series

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.

## RE: number series

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

## RE: number series

## RE: number series

Chriss

## RE: number series

## Spoiler:

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