On 11 Jan 2010 20:37:37 -0800, paulgboul...@aim.com (Paul Gilmartin)
wrote:
I'm not sure that matters; the sequence of year numbers can hardly
be coerced to be closed. For example, if from 1912 (sinking of the
Titanic) I subtract 1957 (dawn of the Space Age), I get -45 (the
year Caesar
On Tue, 12 Jan 2010 09:00:36 -0700, Howard Brazee wrote:
I'm not sure that matters; the sequence of year numbers can hardly
be coerced to be closed. For example, if from 1912 (sinking of the
Titanic) I subtract 1957 (dawn of the Space Age), I get -45 (the
year Caesar proclaimed the Julian
Howard Brazee howard.bra...@cusys.edu
On 11 Jan 2010 20:37:37 -0800, paulgboul...@aim.com (Paul Gilmartin)
wrote:
I'm not sure that matters; the sequence of year numbers can hardly
be coerced to be closed. For example, if from 1912 (sinking of the
Titanic) I subtract 1957 (dawn of the
It is certainly true, as Joel C. Ewing contends, that bad leap-year code
abounds. Unfortunately, it is also true that the assorted TM-based schemes he
has presented in a sequence of posts are bad too, even radically misconceived.
First, we need a definition:
In the Julian calendar every
- Original Message -
From: john gilmore john_w_gilm...@msn.com
Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@bama.ua.edu
Sent: Monday, January 11, 2010 9:20 PM
Subject: Re: Bad leap-year code
It is certainly true, as Joel C. Ewing contends, that bad leap-year code
abounds
Gunnar Opheim (g...@bkkfiber.no) writes
This is the ISO 8601 definition, made for the modern computerized world. In
the traditional proleptic calendar (both Gregorian and Julian) there was no
year 0, AD 1 followed 1 BC.
His point is wsell taken unexceptionable, and literally correct; but I
On 01/11/2010 05:21 PM, Gunnar Opheim wrote:
- Original Message -
From: john gilmore john_w_gilm...@msn.com
Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@bama.ua.edu
Sent: Monday, January 11, 2010 9:20 PM
Subject: Re: Bad leap-year code
It is certainly true, as Joel C. Ewing
On Tue, 12 Jan 2010 02:46:22 +, john gilmore wrote:
The sequence of positive|unsigned integers is not closed under subtraction;
the need for zeros in computational schemes thus long antedates computers.
I'm not sure that matters; the sequence of year numbers can hardly
be coerced to
On 01/09/2010 06:29 PM, Paul Gilmartin wrote:
On Sat, 9 Jan 2010 16:43:42 -0600, Joel C. Ewing wrote:
This ought to be feasible (correctly) for 1901 to 2099 with two TM
instructions (and two branches). (Comments?) A third TM and branch
would handle the 400 year rule.
Wouldn't it take a
On 01/08/2010 05:23 PM, Andy Wood wrote:
No,
The error was only dividing the last digit of the year by 4 to determine
if it was a leap year. I.e. 92 is divisible by 4 but 2 is not.
There must be plenty of ways of going wrong.
However, the ones I recall were taking a two or four digit
On Sat, 9 Jan 2010 09:49:22 -0600, Joel C. Ewing wrote:
The case I remember was IBM's SDSF. The intent obviously was an
overly-clever attempt to avoid the overhead of divides by using
multiple TM instructions to test bits in the BCD year, determining leap
year by looking for years 0, 4, 8 in
On 01/09/2010 10:43 AM, Paul Gilmartin wrote:
On Sat, 9 Jan 2010 09:49:22 -0600, Joel C. Ewing wrote:
The case I remember was IBM's SDSF. The intent obviously was an
overly-clever attempt to avoid the overhead of divides by using
multiple TM instructions to test bits in the BCD year,
On 01/09/2010 04:32 PM, Joel C. Ewing wrote:
On 01/09/2010 10:43 AM, Paul Gilmartin wrote:
On Sat, 9 Jan 2010 09:49:22 -0600, Joel C. Ewing wrote:
The case I remember was IBM's SDSF. The intent obviously was an
overly-clever attempt to avoid the overhead of divides by using
multiple TM
On Sat, 9 Jan 2010 16:43:42 -0600, Joel C. Ewing wrote:
This ought to be feasible (correctly) for 1901 to 2099 with two TM
instructions (and two branches). (Comments?) A third TM and branch
would handle the 400 year rule.
Wouldn't it take a fourth TM (or a CLI) to get the 100-year rule in
14 matches
Mail list logo
