Howard Brazee
> 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 -
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 Julia
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 procla
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 t
On 01/11/2010 05:21 PM, Gunnar Opheim wrote:
> - Original Message -
> From: "john gilmore"
> Newsgroups: bit.listserv.ibm-main
> To:
> Sent: Monday, January 11, 2010 9:20 PM
> Subject: Re: Bad leap-year code
>
>
>>
>> It is certainly true,
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
- Original Message -
From: "john gilmore"
Newsgroups: bit.listserv.ibm-main
To:
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. Unfortunately, it is al
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
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.
>
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
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
>>>
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 yea
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
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
14 matches
Mail list logo
