Joining list. Calendar reforms.

[Mark J. Reed]

On Mon, Jun 29, 2009 at 1:21 PM, MIKE OSSIPOFF<nkklrp@...> wrote:
> 1. Middle-after-Solstice:
>
> The lag of (say) a calendar summer is the delay by which its middle follows the summer solstice.

That is the definition I would have expected, but you seemed to be
giving a value for lag based on a climate.  Hence my confusion.

> 2. Equal bounding lagged declinations:
>
> Find a number, N, such that the solar declination N days before the end of calendar summer is the same as the solar declination N days before the beginning of calendar summer. Then, N days is the timelag of that calendar summer.

So, say our calendar summer is June 1 through August 31, with a
midpoint of July 17.  Based on this year, when the solstice was on
June 20 and the declination equivalence points are May 6 and August 5,
such a calendar summer has a lag of either 27 or 25.5 days.

Is the goal to have a lag of zero?  Or is the goal to create a
calendar that matches the lag based on current conventional
definitions of the calendrical location of the seasons?

--
Mark J. Reed <markjreed@...>

[Irv Bromberg]

On 2009 Jun 29, at 12:16 , Mark J. Reed wrote:

On Mon, Jun 29, 2009 at 12:09 PM, Irv Bromberg<irv.bromberg@...> wrote:

Irv replies:  The direct expression for the Gregorian leap rule is more

complex than a properly implemented smoothly spread leap rule:

It's more complex to write code to calculate, yes.  But it is much
simpler for a human to determine.  That's the trade-off.  Any sort of
evenly-spread rule would make the leap/common status of a year (is
there a word for that quality, btw?) nearly impossible to determine mentally.

That's not a trade-off.  Nobody needs to determine it mentally, they just look at the printed calendar, finished.

Anyhow, for a smoothly spread leap day calendar, one has either 4 or 5 years to figure out when the next leap year will be, or for a smoothly spread leap week calendar, one has either 6 or 5 years.

I'm surprised you didn't make the more obvious comment.  Try using a calculator to reckon the leap status by either method.  Well, you probably won't have difficulty doing it, but try asking the "man on the street".  Without a "MOD" or "MODULUS" button on a hand-held calculator, most people are hopelessly lost, even though it is actually straightforward to use such a calculator:  perform the division, subtract the integer component of the result, multiply the remaining fraction by the original divisor, and round to an integer (if necessary), then that is the remainder of the MODULUS operation.  Such a calculation is easy to implement in a programmable calculator, although I would use an expression like modulus( x, y ) = x – y * floor( x / y ) on any programmable device.  Very few people own such programmable calculators, and fewer still would know how to implement such an expression.

Go with the printed calendar or a published list of leap years.

People in the orient following a traditional lunisolar calendar have no hope of figuring out the leap status of any year in their head, they just follow the published calendar.

Even the simple leap rule of the traditional Hebrew calendar, with is a smoothly spread 19-year cycle, is followed from the published calendar.

Only calendarists, computer programmers, and calendar publishers need the details.

-- Irv Bromberg, Toronto, Canada

<http://www.sym454.org/>

[MIKE OSSIPOFF]

 
Irv--
 
You wrote:

> Mike, you aren't thinking about how calendars are used. You are focused only on the design of a printed calendar that people will follow this year and next year.
>
> What about the millions of dated database transactions that take place every day? What about calendrical calculations that go on "behind-the-scenes" to determine the duration of a loan, or a contract, or when a product will expire, how many days until or since such-and-such, and so on? All such calculations need efficient calendrical calculations that work directly, efficiently and unambiguously.
 
I reply:
 
I understand that. And, though computers wouldn't have a problem with a serial rule, such a rule would make it difficult for people to verify for themselves, without a computer, whether a distant future date is a leapyear.
 
Also, it's just occurred to me that, the more arithmetic has to be done (as with a serial rule), the more round-off error occurs, and the more the result will depend on how many digits the machine is calculating with. Definitely, if a one-step-evaluation rule is more consistently machine-independent, then that is strong justification for preferring a one-step-evaluation rule.
 
But, maybe, for explanatory purposes, if a rule can be written either way, the serial way of writing the leapyear rule might make for an easier, simpler explanation of the rule, even if the one-step-evaluation is much better for practical use.
 
Anyway, I do understand that one-step-evaluation is a better idea for practical calculation--especially today, when the roundoff-error problem occurred to me.

I"d said:

> Mike continued: I claim that the great simplicity and obviousness of Minimum Drift outweighs the computational convenience advantage of a single-step-evaluation leap rule

You replied:

> Irv replies: If you say so, but frankly I don't understand your Minimum Drift rule at all, so I'll have to take your word on how simple and obvious it is.
 
I reply:
 
Then it isn't so obvious after-all, at least not without a little statement about its motivation.
But then you'll agree that it's natural.
 
You continued:
 
I previously asked where the numeric coefficients came from and you didn't answer that question.
 
I reply:
 
SorrY--I didn't find that question yet. After my efforts to post my fixed-calendar proposal suggestions all in one posting, I'm only now catching up on what has been said here in the past few days.
 
1.24219 days is the amount by which a 52-week fixed calendar drifts ahead each year, when a non-leapyear ends.
Negative 5.75781 is 7 minus 1.24219. That's where those two numbers in Minimum Drift came from.
 
Motivation for Minimum Drift:
 
For a 52-week fixed calendar:
 
Each time a non-leapyear ends, the calendar year gains 1.24219 days with respect to the equinoxes. For a particular date, the solar ecliptic longitude that, last year, coincided with that date, now won't occur till an additional 1.24219 days later in the calendar.
 
I defined "d" as the position of Gregorian June 1, minus the middle of the designated lyc. June 1's position's signed displacement from the middle of the designated lyc, expressed in days.
 
Minor detail: I've just now realized that I should have said, instead, that d is the middle of the designated lyc, minus the position of June 1. The negative of the signed displacement of June 1's position from the middle of the designated lyc, expressed in days. (I described the calculation of d in more detail in the posting entitled "Vol.I). You probably know how easy it can be to get a direction like that backwards.
 
So, when the end of a non-leapyear makes the year gain 1.24219 days, as described above, d is increased by 1.24219. At the end of a leapyear, d is, additionally decreased by 7 days, because the year loses 7 days, because it takes 7 extra days for the next year to start. So, then, the change in d is 1.24219 - 7. That's minus 5.75781. That accounts for the rule about how d changes at the end of a leapyear and at the end of a non-leapyear.
 
I want the absolute value of d to be as small as possible for the next year. So the absolute value of next year's d is abs(d+1.24219) if the current year isn't a leapyear, and is abs(d-5.75781) if the current year is a leapyear. I want that to be as small as possible. So I choose whichever of those is smaller. So, if abs(d-5.75781) is smaller than abs(d+1.24219), then I want the current year to be a leapyear, because then next year's d will be smaller than it would be if it were a non-leapyear.
 
Conclusion of this part of this reply. There may be more.
 
Mike Ossipoff
 
 
 
 
 
 
 
 
 
 
_________________________________________________________________
Insert movie times and more without leaving Hotmail®.
http://windowslive.com/Tutorial/Hotmail/QuickAdd?ocid=TXT_TAGLM_WL_HM_Tutorial_QuickAdd_062009

[Irv Bromberg]

On 2009 Jun 29, at 15:36 , MIKE OSSIPOFF wrote:

Irv wrote:  What about the millions of dated database transactions that take place every day? What about calendrical calculations that go on "behind-the-scenes" to determine the duration of a loan, or a contract, or when a product will expire, how many days until or since such-and-such, and so on? All such calculations need efficient calendrical calculations that work directly, efficiently and unambiguously.

Mike replied:  I understand that. And, though computers wouldn't have a problem with a serial rule, such a rule would make it difficult for people to verify for themselves, without a computer, whether a distant future date is a leapyear.

Irv replies:  Of course computers would have a major problem with a serially calculated leap rule.  Yes, they can calculate 2000+ loops in the blink of an eye, but each system handling database transactions would be executing such loops many millions of times per day, why bother when a simple expression can give the leap status directly?

Mike continued:  1.24219 days is the amount by which a 52-week fixed calendar drifts ahead each year, when a non-leapyear ends.
Negative 5.75781 is 7 minus 1.24219. That's where those two numbers in Minimum Drift came from.

Irv replies:  OK, then those are the wrong numbers, just as I suspected.

The numbers you should use depend on the calendar mean year that you select.  You appear to have selected, unwittingly no doubt, the mean tropical year, which is an inappropriate choice in any event for any calendar, whereas if you are insisting on using the equivalent to Gregorian leap rule then you must use 1.2425 and 5.7575, respectively, in order to maintain the intended relationship between the calendars.

Each time a non-leapyear ends, the calendar year gains 1.24219 days with respect to the equinoxes. For a particular date, the solar ecliptic longitude that, last year, coincided with that date, now won't occur till an additional 1.24219 days later in the calendar.

Irv replies:  Not with respect to the equinoxes, it is with respect to the mean tropical year, which is appreciably shorter than the mean northward equinoctial year.  You should'nt care about the mean southward equinoctial year, because it is rapidly getting shorter in the present era and for thousand of years to come, not suitable for a fixed arithmetic leap rule.

I defined "d" as the position of Gregorian June 1, minus the middle of the designated lyc. June 1's position's signed displacement from the middle of the designated lyc, expressed in days.

Irv replies:  So what is it that you care about?  If June 1st is so important, then one would expect the north solstice to matter, whose mean year is even shorter than the mean tropical year.  If you are tracking the Gregorian mean year, then it is actually about 12 seconds longer than the mean northward equinoctial year.  I'm at a loss to understand what you are after, although it still seems to be just an arbitrary re-labeling of Gregorian dates.

I highly recommend the book "Calendrical Calculations" by Dershowitz and Reingold, see:

http://emr.cs.iit.edu/home/reingold/calendar-book/third-edition/

-- Irv Bromberg, Toronto, Canada

<http://www.sym454.org/>

[MIKE OSSIPOFF]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Mark--

I'd said:

> > 1. Middle-after-Solstice:
> >
> > The lag of (say) a calendar summer is the delay by which its middle follows the summer solstice.
 
> That is the definition I would have expected, but you seemed to be
> giving a value for lag based on a climate. Hence my confusion.

I've been determining how much the seasons lag behind changes in the solar declination, by finding how much, say, the time of winter minimum temperature, or the middle of wither otherwise measured, lags  behind the winter solstice. And I've also been wanting a the calendar seasons of a seasonal calendar to lag, by that same amount, behind changes in the declination, as reckoned in those two ways that I described.
 
I'd said:

> > 2. Equal bounding lagged declinations:
> >
> > Find a number, N, such that the solar declination N days before the end of calendar summer is the same as the solar declination N days before the beginning of calendar summer. Then, N days is the timelag of that calendar summer.
>
You replied:

> So, say our calendar summer is June 1 through August 31, with a
> midpoint of July 17. Based on this year, when the solstice was on
> June 20 and the declination equivalence points are May 6 and August 5,
> such a calendar summer has a lag of either 27 or 25.5 days.

I reply:

Yes.


>You continued:

> Is the goal to have a lag of zero? Or is the goal to create a
> calendar that matches the lag based on current conventional
> definitions of the calendrical location of the seasons?

I reply:

I've been seeking for the lag of the calendar seasons to be the same as the actual seasonal lag determined from temperature records.

If people in the northern hemisphere feel that summer arrives with June, and if the middle of the usual range of variation of the seasonal time lag is 1.25 months, then those two facts, together, determine the length of summer in the northern hemisphere. They suggest that summer ends in late September. And that accords well with people's experience, in Santa Cruz, about when is the best time of year to go to the beach, or to swim in the ocean.

Mike Ossipoff

---

Insert movie times and more without leaving Hotmail®. See how.

[MIKE OSSIPOFF]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Irv--

You wrote:

Of course computers would have a major problem with a serially calculated leap rule.  Yes, they can calculate 2000+ loops in the blink of an eye, but each system handling database transactions would be executing such loops many millions of times per day, why bother when a simple expression can give the leap status directly?

I reply:

Fair enough. It's more practical to use the more efficient procedure.

You continued:

Mike continued:  1.24219 days is the amount by which a 52-week fixed calendar drifts ahead each year, when a non-leapyear ends.
Negative 5.75781 is 7 minus 1.24219. That's where those two numbers in Minimum Drift came from.

Irv replies:  OK, then those are the wrong numbers, just as I suspected.

The numbers you should use depend on the calendar mean year that you select.  You appear to have selected, unwittingly no doubt, the mean tropical year

I reply:

I intentionally selected the mean tropical year. The goal of the Mean-Drift leapyear rule is not to keep the fixed Subjective Seasonal Calendar synchonised as well as possible with the current Gregorian dates. It's to keep the position of NorthI/1 as close as possible to the middle of the designated lyc. The middle of the designated lyc is a point on the ecliptic. I want to minimize the calendar's drift on the ecliptic.

That's because I want solar ecliptic longitude on NorthI/1 to coincide as closely as possible to the midpoint of the variation of the solar ecliptic longitude for June 1, during the designated lyc.

Because I want, as nearly as possible, for NorthI/1 to be at the same time of year as the average time of year for June 1. (That's a looser wording of what I said in the paragraph before).

You wrote:

 ...in order to maintain the intended relationship between the calendars.


I reply:

I'm not trying to maintain a relationship between the calendars. I want the relationship between the new calendar and the time of year based on solar ecliptic longitude, to be as close as possible to the average of what that relationship was for the old calendar.

I'd said:

Each time a non-leapyear ends, the calendar year gains 1.24219 days with respect to the equinoxes. For a particular date, the solar ecliptic longitude that, last year, coincided with that date, now won't occur till an additional 1.24219 days later in the calendar.

Irv replies:  Not with respect to the equinoxes, it is with respect to the mean tropical year

I reply:

My wording was a little careless there. I meant with respect to the mean tropical year. I understand that the difference between the length of the mean tropical year and any particular actual tropical year amounts to only a few minutes, not enough to be a  problem for the calendar.

Also, I realize that, even in a small region of the eclliptic, the sun's rate of motion on the ecliptic varies slightly from day to day, but not by enough to make the leapyear rule problematically inaccurate.

Mike Ossipoff

I'd said:

I defined "d" as the position of Gregorian June 1, minus the middle of the designated lyc. June 1's position's signed displacement from the middle of the designated lyc, expressed in days.

You replied:

So what is it that you care about? 

I reply:

I want the correspondence between NorthI/1 and the ecliptic longitude time of year to be as close as possible to the average correspondence between Gregorian June 1 and the ecliptic longitude time of year.

You wrote:

 I'm at a loss to understand what you are after

I reply:

I hope that I've clarified that, above in this reply.

You continued:

, although it still seems to be just an arbitrary re-labeling of Gregorian dates.

I reply:

In the fixed version of the Subjective Seasonal Calendar, NorthI/1 will shift some, with respect to June 1. So it isn't a re-labeling of Gregorian dates.

But, in my proposal of the nonfixed version, leapday would be in the 2nd month of South. (SouthII), and for days that are before leapyear in both the old and new calendars, and for days that are after leapyear in both the old and new calendars, yes there would be a constant match between the new date and the old date. Does that mean that the calendar is nothing but a re-labeling? The purpose is for the year-divisions, and their names, to explicitly refer to the seasons of the year, as near as possible to the way people perceive those seasons.

I agree that it isn't really important that NorthI/1 always coincide with June 1. But it's easy to achieve, by having leapday before summer, and it dramatizes the intent of the calendar to reflect the seasons, for people who consider summer to arrive with June.

By the way, the reason why, in the nonfixed calendar, I'd have leapday in SouthII instead of SouthI is because SouthII would ordinarily be shorter than SouthI, and it's better to have leapday in a shorter month. Also, I'd like having it near the same time as in the current calendar.

Mike Ossipoff

---

Insert movie times and more without leaving Hotmail®. See how.

[Mark J. Reed]

On Mon, Jun 29, 2009 at 4:25 PM, MIKE OSSIPOFF<nkklrp@...> wrote:
> I've been determining how much the seasons lag behind changes in the solar
> declination, by finding how much, say, the time of winter minimum
> temperature, or the middle of wither otherwise measured, lags  behind the
> winter solstice.

OK, that has nothing to do with the definitions you gave me of lag,
which were both with respect to some defined 'calendar season'.  But I
see now the above is the yardstick against which you are comparing the
calendrical lag.  Fair enough.

> If people in the northern hemisphere feel that summer arrives with June, and
> if the middle of the usual range of variation of the seasonal time lag is
> 1.25 months, then those two facts, together, determine the length of summer
> in the northern hemisphere.

Uhm, wait.  Now you're conflating the calendar lag again.  Forget the
calendar - pretend June doesn't exist.  What is the lag between the
solstices and the temperature maxima?

--
Mark J. Reed <markjreed@...>

[MIKE OSSIPOFF]

Irv--

I think a symmetrical leapyear rule is more aesthetically-appealing, in addition to being more accurate. I wouldn't consider anything else for a leapweek calendar.

It's just that, for a nonfixed calendar, I'd rather keep the reform proposal simple by not changing the leapyear system.

You wrote:

The wobble of the Gregorian calendar leap rule is what is responsible for the fact that this century the northward equinox never falls on March 21st.  It mostly falls on March 20th, and later in this century it will often fall on March 19th.  

I reply:

Certainly that's annoying, and, for a nonfixed calendar, it would be better to not have so much drift. Much lower drift could be achieved with a symmetrical leapyear rule. But that has to be weighed against proposal-simplicity.

You wrote:

Who says that wobble isn't a problem?  Has the Catholic Church said that it is of no concern?  If so, then have they said how far out it would have to be before they do get concerned?
Who says that the greater wobble due to the leap week (which is much shorter term than the Gregorian wobble discussed above) is acceptable?  Or not?

I reply:

A calendar reform advocate pointed out at his website that the temperature fluctuations from one day to the next, and from one year to the next, are greater than the change in the average temperature over the duration representing the wobble of a leapweek calendar.

I'd said:

Another advantage of keeping the Gregorian leapyear system for a nonfixed calendar is that, then, it's possible to ensure that NorthI/1 is _always_ on Gregorian June 1.

You replied:

I can't imagine why that would be an advantage in any way.  If you are going to reform the calendar, then why would you want the Gregorian still around?  

I reply:

If, in the nonfixed version, NorthI/1 always coincides with June 1, that could serve to dramatize the intent of the seasonal calendar. I'm not saying that it's important that those two dates always match. In the fixed version, with its leapweeks, those two dates would shift with respect to eachother.

Mike Ossipoff


_________________________________________________________________
Windows Live™: Keep your life in sync.
http://windowslive.com/explore?ocid=TXT_TAGLM_WL_BR_life_in_synch_062009

[MIKE OSSIPOFF]

I'd said:

>> If people in the northern hemisphere feel that summer arrives with June, and
>> if the middle of the usual range of variation of the seasonal time lag is
>> 1.25 months, then those two facts, together, determine the length of summer
>> in the northern hemisphere.

You replied:

> Uhm, wait. Now you're conflating the calendar lag again. Forget the
> calendar - pretend June doesn't exist. What is the lag between the
> solstices and the temperature maxima?

I reply:

I estimate that 1.25 months is the best figure to use, being at the middle of the lag's usual range of variation in the temperate zones.

But yes, I'm conflating the calendar lag with the actual seasonal lag--I'm assuming that  the calendar lag is the same as the estimated actual seasonal lag. And then I'm asking: How long must North be, if calendar lag has that value, and if North begins on June 1?

And I'm saying that, if North starts on June 1, and if the calendar lag is 38 days (because that's my estimate of the actual lag), then North will be 117 or 118 days long (depending on which of those two calendar-lag definitions is applied).

Mike Ossipoff



_________________________________________________________________
Windows Live™: Keep your life in sync.
http://windowslive.com/explore?ocid=TXT_TAGLM_WL_BR_life_in_synch_062009

[Karl Palmen]

Dear Mark and Calendar People

-----Original Message-----
From: East Carolina University Calendar discussion List [mailto:CALNDR-L@...] On Behalf Of Mark J. Reed
Sent: 29 June 2009 17:30
To: CALNDR-L@...
Subject: Re: June-September season

On Mon, Jun 29, 2009 at 12:08 PM, MIKE OSSIPOFF<nkklrp@...> wrote:
> As for summer ending in February, are you sure that you aren't just basing that on the assumption of four equal seasons?

Who cares what he's basing it on?  Your statement was that everyone
perceives things a certain way.  That statement has been proven false
many times over.

> For summer to begin with December, and end when February ends, implies a seasonal timelag much shorter than that which I found average for Australia in the worldwide temperature records book.

I still don't understand how you're defining this "lag".

Take Amberley as an example.  Its high temperature of the year falls
in January; that should presumably be midsummer.  The low temperature
of the year falls in July, so that should presumably be midwinter.
The temperature midpoints between those extremes, presumably the
middle of the transitional seasons, fall in April/May and Sept/Oct.
Which looks pretty darn close to equal quarters to me.

KARL SAYS: This just means that the mid-points of the quarters are evenly spaced. Unequal quarters of the type Mike suggests have that property.

Karl

10(10(07 till noon

[Karl Palmen]

Dear Calendar People

Earlier posts have demonstrated that Irv does not value any kind of calendar simplicity other than computational simplicity. I'd advise Mike to take note of this and not seek Irv's approval for any leap year rule simpler than what Irv has proposed.

The Gregorian leap year rule is simpler than a smoothly spread leap rule in both the pattern of leap years it produces and in how it is specified.

However, the case of smoothly spread leap year equivalent to the Gregorian is not completely beyond mental calculation. Its 400-year cycle has eleven 33-year cycles and a 37-year cycle. The middle (5th) leap year of the 37-year cycle is the 400th year. One then notes (5 leap years later) that the 21st year is the only leap year that is 5 years after the previous leap year and 37 years after the previous such year. One can then calculate the leap years that are five years after the previous leap years by adding the multiples of 33 to 21 while staying below 400, giving 021, 054, 087, 120, 153, 186, 219, 252, 285, 318, 351 and 384. The other leap years are a multiple of four after the previous one of these years listed, but never one year before one of these years listed.

The leap years are also those years Y for which
(( 97*Y + 48 ) mod 400 ) < 97
which gives no hint of the above-mentioned pattern.

Also the formulae the Helios gave for his term calendar do not reveal all of this calendar's simplicity. I had to point it out.

Karl

10(10(08

-----Original Message-----
From: East Carolina University Calendar discussion List [mailto:CALNDR-L@...] On Behalf Of Mark J. Reed
Sent: 29 June 2009 17:17
To: CALNDR-L@...
Subject: Re: June-September season

On Mon, Jun 29, 2009 at 12:09 PM, Irv Bromberg<irv.bromberg@...> wrote:
> Irv replies:  The direct expression for the Gregorian leap rule is more
> complex than a properly implemented smoothly spread leap rule:

It's more complex to write code to calculate, yes.  But it is much
simpler for a human to determine.  That's the trade-off.  Any sort of
evenly-spread rule would make the leap/common status of a year (is
there a word for that quality, btw?) nearly impossible to determine
mentally.

--
Mark J. Reed <markjreed@...>

[Karl Palmen]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Dear Mike, Irv and Calendar People

 

I see in these arguments a failure to differentiate between the calendar rules and the algorithm used to implement the calendar rules.

 

The two need not be the same. No calendar can demand that its dates are calculated by a specific algorithm. Any algorithm that gives the same results will do. In particular specifying the leap year by a serial rule does not imply that it must be calculated in that manner.

 

Karl

 

10(10(08

 

From: East Carolina University Calendar discussion List [mailto:CALNDR-L@...] On Behalf Of MIKE OSSIPOFF
Sent: 29 June 2009 22:09
To: CALNDR-L@...
Subject: Re: June-September season

 

Irv--

You wrote:

Of course computers would have a major problem with a serially calculated leap rule.  Yes, they can calculate 2000+ loops in the blink of an eye, but each system handling database transactions would be executing such loops many millions of times per day, why bother when a simple expression can give the leap status directly?

I reply:

Fair enough. It's more practical to use the more efficient procedure.

 

--
Scanned by iCritical.

[Karl Palmen]

Dear Calendar People

It is not clear what Mike means by a symmetrical leap year rule.

The Gregorian Leap year rule produces a symmetrical sequence of leap
years (with mirror image pairs such as (2000, 2000), (1996, 2004),
(1992, 2008), (1988, 2012), etc.. ).

Is ISO-week based years have a completely asymmetrical sequence of
53-week leap years, but if Sunday starting weeks were used it too would
be symmetrical.

Irv's 293-year cycle rule for the Symmetry454 calendar also has a
symmetrical sequence of leap years. In this sequence the mirror image
pairs of all years are (first, last), (second, penultimate), etc.. ).
Such a symmetry has the property that the first year starts at exactly
the same moment as the mean year. Such symmetry is only possible with a
cycle of an odd number of years.

Karl

10(10(08

-----Original Message-----
From: East Carolina University Calendar discussion List
[mailto:CALNDR-L@...] On Behalf Of MIKE OSSIPOFF
Sent: 29 June 2009 22:34
To: CALNDR-L@...
Subject: Re: June-September season

Irv--

I think a symmetrical leapyear rule is more aesthetically-appealing, in
addition to being more accurate. I wouldn't consider anything else for a
leapweek calendar.

It's just that, for a nonfixed calendar, I'd rather keep the reform
proposal simple by not changing the leapyear system.

You wrote:

The wobble of the Gregorian calendar leap rule is what is responsible
for the fact that this century the northward equinox never falls on
March 21st.  It mostly falls on March 20th, and later in this century it
will often fall on March 19th.  

I reply:

Certainly that's annoying, and, for a nonfixed calendar, it would be
better to not have so much drift. Much lower drift could be achieved
with a symmetrical leapyear rule. But that has to be weighed against
proposal-simplicity.

You wrote:

Who says that wobble isn't a problem?  Has the Catholic Church said that
it is of no concern?  If so, then have they said how far out it would
have to be before they do get concerned?
Who says that the greater wobble due to the leap week (which is much
shorter term than the Gregorian wobble discussed above) is acceptable?
Or not?

I reply:

A calendar reform advocate pointed out at his website that the
temperature fluctuations from one day to the next, and from one year to
the next, are greater than the change in the average temperature over
the duration representing the wobble of a leapweek calendar.

I'd said:

Another advantage of keeping the Gregorian leapyear system for a
nonfixed calendar is that, then, it's possible to ensure that NorthI/1
is _always_ on Gregorian June 1.

You replied:

I can't imagine why that would be an advantage in any way.  If you are
going to reform the calendar, then why would you want the Gregorian
still around?  

I reply:

If, in the nonfixed version, NorthI/1 always coincides with June 1, that
could serve to dramatize the intent of the seasonal calendar. I'm not
saying that it's important that those two dates always match. In the
fixed version, with its leapweeks, those two dates would shift with
respect to eachother.

Mike Ossipoff


_________________________________________________________________
Windows Live(tm): Keep your life in sync.
http://windowslive.com/explore?ocid=TXT_TAGLM_WL_BR_life_in_synch_062009
--
Scanned by iCritical.

[Mark J. Reed]

True.  But the danger lies in developing a serial rule which has no
shortcut formula.  And even if there is a shortcut, finding it can be
difficult.  I'm reminded of the problem of calculating the length of a
given Hebrew year; taken at face value, the rule as usually given
requires infinite regress, since the length of a year winds up
depending on that of the adjacent years.  Only by noting the
deterministic patterns (by mathematically eliminating impossible
sequences) do you get a tractable problem.

On 6/30/09, Palmen, KEV (Karl) <karl.palmen@...> wrote:

> Dear Mike, Irv and Calendar People
>
>
>
> I see in these arguments a failure to differentiate between the calendar
> rules and the algorithm used to implement the calendar rules.
>
>
>
> The two need not be the same. No calendar can demand that its dates are
> calculated by a specific algorithm. Any algorithm that gives the same
> results will do. In particular specifying the leap year by a serial rule
> does not imply that it must be calculated in that manner.
>
>
>
> Karl
>
>
>
> 10(10(08
>
>
>
> From: East Carolina University Calendar discussion List
> [mailto:CALNDR-L@...] On Behalf Of MIKE OSSIPOFF
> Sent: 29 June 2009 22:09
> To: CALNDR-L@...
> Subject: Re: June-September season
>
>
>
> Irv--
>
> You wrote:
>
> Of course computers would have a major problem with a serially
> calculated leap rule.  Yes, they can calculate 2000+ loops in the blink
> of an eye, but each system handling database transactions would be
> executing such loops many millions of times per day, why bother when a
> simple expression can give the leap status directly?
>
> I reply:
>
> Fair enough. It's more practical to use the more efficient procedure.
>
>
>
>
>
>
>
> --
> Scanned by iCritical.
>
>

--
Sent from my mobile device

Mark J. Reed <markjreed@...>

[Christopher Vance-8]

My point was that around here (in the temperate parts) the general
understanding is that no season has parts in both June and September,
or in both December and March for that matter. Every season begins and
ends on (Gregorian) month boundaries and last for three months each.

In other parts of the country, there are only two seasons - wet and
dry (I guess they're determined observationally) - or six seasons for
some indigenous cultures.

You are not going to establish any definition of 'season' sufficiently
well to eradicate all the conflicting preexisting definitions.

Just like there are some practices which are so deeply rooted you will
just have to accept that they're part of any calendar - such as a
seven day week with no offdays.

-- Christopher

On Tue, Jun 30, 2009 at 2:08 AM, MIKE OSSIPOFF<nkklrp@...> wrote:

>
> Christopher VAnce wrote:
>
>> Summer starts in December and lasts until February.
>> It's winter that starts in June, and it only lasts until August.
>>
>> By definition I am part of 'everyone' and am therefore a counter example.
>>
>> -- Christopher
>
> I reply:
>
> Thank you, Christopher, for confirming that, in the southern hemisphere, summer arrives with December.
>
> As for summer ending in February, are you sure that you aren't just basing that on the assumption of four equal seasons?
>
> For summer to begin with December, and end when February ends, implies a seasonal timelag much shorter than that which I found average for Australia in the worldwide temperature records book. The Australian temperature records in the book indicated that, in Australia, the seasonal timelag varies between .75 and 1.75, as is typical in the north and south temperate zones. A summer lasting from December 1 to February 28, when its timelag is calculated from the amount by which its middle lags behind the summer solstice there, implies a seasonal timelag of only about .79 months, near the very low end of the range of variation in Australia.
>
> Using the 1.25 month usual midrange, that, according to the worldwide record-book, as valid in Australia as anywhere else, you get a summer that, when beginning on December 1, lasts into the last few days of March.
>
> Mike Ossipoff
>
>
> _________________________________________________________________
> Windows Live™ SkyDrive™: Get 25 GB of free online storage.
> http://windowslive.com/online/skydrive?ocid=TXT_TAGLM_WL_SD_25GB_062009
>

--
Christopher Vance

[Deckers, Michael-2]

   I do not want to interfere -- just some algebra:

   On 2009-06-29 14:39:06Z, MIKE OSSIPOFF <nkklrp@...> wrote:

>  A year is a leap year if, for that year's d, abs(d-5.75781) < abs(d+1.24219)

   This is obviously the same as saying that d is greater than 7/2 - 1.24219.
   Together with the following specification of the change in d from year to
   year:

>  After the end of a year that isn't a leapyear, add 1.24219 to d.
>  After the end of a leapyear, subtract 5.75781 from d.

   we see that for integral Y:
                                year( Y )is a leap year
   if and only if
                  ( (Y + 1)·365.24219 + 7/2 + d0 ) mod 7
                    is > 0 and <= 1.24219

   where d0 is the value of d for the year Y = 0. This is again
   equivalent to
                  ( 7/2 - Y·365.24219 - d0 ) mod 7 < 1.24219

   For this last formula, some list members would claim that it uses
   an "accumulator".

   Michael Deckers.

[Karl Palmen]

Dear Calendar People

If Michael Deckers is correct in his understanding of Mike Ossipoff's
leap year rule, then I can show, that it's a 700,000-year cycle with
124,219 leap years spread as evenly as possible and so can be easily
computed.

-----Original Message-----
From: East Carolina University Calendar discussion List
[mailto:CALNDR-L@...] On Behalf Of Deckers, Michael
Sent: 30 June 2009 15:49
To: CALNDR-L@...
Subject: Re: June-September season


   I do not want to interfere -- just some algebra:

   On 2009-06-29 14:39:06Z, MIKE OSSIPOFF <nkklrp@...> wrote:

>  A year is a leap year if, for that year's d, abs(d-5.75781) <
abs(d+1.24219)

   This is obviously the same as saying that d is greater than 7/2 -
1.24219.
   Together with the following specification of the change in d from
year to
   year:

>  After the end of a year that isn't a leapyear, add 1.24219 to d.
>  After the end of a leapyear, subtract 5.75781 from d.

   we see that for integral Y:
                                year( Y )is a leap year
   if and only if
                  ( (Y + 1)*365.24219 + 7/2 + d0 ) mod 7
                    is > 0 and <= 1.24219

   where d0 is the value of d for the year Y = 0. This is again
   equivalent to
                  ( 7/2 - Y*365.24219 - d0 ) mod 7 < 1.24219

   For this last formula, some list members would claim that it uses
   an "accumulator".

KARL SAYS: Then we can get rid of the fractions by multiplying both
sides by 100,000 (assuming that d0 has nor more than five decimal
places):

( 350,000 - 36,524,219*Y - 100,000*d0) mod (700,000) < 124,219

Noting that 36,400,000 is divisible by 700,000 we then get:

( (350,000 - 100,000*d0) - 124,219*Y ) mod (700,000) < 124,219)

which is a 700,000-year cycle with 124,219 leap years spread as evenly
as possible. Algorithms for such a cycle are well known.

I've also checked that 124,219 = 17*7307 (prime divisors) and so is
prime relative to 700,000. Therefore, the 700,000-year cycle is not a
repetition of a shorter cycle.

Karl

10(10(08

--
Scanned by iCritical.

[MIKE OSSIPOFF]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Karl--
 
You wrote:
 
> It is not clear what Mike means by a symmetrical leap year rule.
 
I mean a leapyear rule that tries to keep the calendrical drift minimized, making each year a leap year, or not, whichever will result in the least drift for the following year.
 
By "drift", in this context, I mean the amount by which the solar ecliptic longitude for some particular designated calendar date differs from the solar ecliptic longitude that you want to keep that date close to.
 
I thought that "symmetrical leapyear system" or "symmetrical" leapyear rule" was the term, on this mailing-list, for such a leapyear system.
 
If I were naming that kind of leapyear rule, I'd call it a constantly drift-minimizing leapyear rule.
 
Mike Ossipoff

 

---

Hotmail® has ever-growing storage! Don’t worry about storage limits. Check it out.

[MIKE OSSIPOFF]

Some parts of this message have been removed. Learn more about Nabble's security policy.

 
Christopher and Calendar People,
 
You wrote:
 
> My point was that around here (in the temperate parts) the general
> understanding is that no season has parts in both June and September,
> or in both December and March for that matter. Every season begins and
> ends on (Gregorian) month boundaries and last for three months each.
>
 
It's interesting to hear from people faraway places about seasonal perceptions. My question is: Are you sure that this perception of 3-month seasons is from personal direct perception, or, rather, of a cultural nature, a traditional or media-perpeturated notion?
 
Mike Ossipoff
 
 
 

---

Windows Live™ SkyDrive™: Get 25 GB of free online storage. Get it on your BlackBerry or iPhone.

[MIKE OSSIPOFF]

Some parts of this message have been removed. Learn more about Nabble's security policy.

 
Chris, Karl & Calendar People,
 
Thanks for the encouraging information that Minimum Drift is efficiently computable
 
Mike Ossipoff
 

---

Lauren found her dream laptop. Find the PC that’s right for you.