Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

Register Log in
  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

number series

Status
Not open for further replies.
Chris Miller

Chris Miller

Programmer
Joined
Oct 28, 2020
Messages
5,032
Location
DE
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
 
Sort by date Sort by votes
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]
 
Upvote 0 Downvote
[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]

 
Upvote 0 Downvote
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
 
Upvote 0 Downvote
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
 
Upvote 0 Downvote
Bonus question 3

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

Chriss
 
Upvote 0 Downvote
Hm, seems that was too easy to interest you.

Well, here the spoilers:

2a)
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)
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)
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)
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
 
Upvote 0 Downvote
Chris Miller said:
What about this "magic number" 30.6? is it really that magic?
Click to expand...

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.
 
Upvote 0 Downvote
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
 
Upvote 0 Downvote
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.
 
Upvote 0 Downvote
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
 
Upvote 0 Downvote
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.
 
Upvote 0 Downvote
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
 
Upvote 0 Downvote
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.
 
Upvote 0 Downvote
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
 
Upvote 0 Downvote
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.
 
Upvote 0 Downvote
I look forward to that. I am not at all against spawning ideas that lead to a totally new thread.

Chriss
 
Upvote 0 Downvote
Regarding to use 979 instead of 30.59375:

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
 
Upvote 0 Downvote
Status
Not open for further replies.

Similar threads

Chris Miller
  • Locked
  • Question Question
number series (continued)
Replies
3
Views
594
Chris Miller
Chris Miller
jimoo
  • Locked
  • Question Question
Odd number of pigs in cages
2 3
Replies
55
Views
3K
Olaf Doschke
Olaf Doschke
GwydionM
  • Locked
  • Question Question
What's the chance of a six-number run in a lottery
2
Replies
29
Views
2K
CajunCenturion
CajunCenturion

Part and Inventory Search

Sponsor

Back
Top