Y2K++

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Y2K++

Amos Shapir
This is from the Risks Digest (a most recommended resource for computer
people) at
http://catless.ncl.ac.uk/Risks/24.11.html in an article of that subject, by
Jim Horning:

"...For some reason, I
happened to look more closely than usual at one of the charts, and noticed
something odd about the labeling of the year axis, and started inspecting
them all.  Most of them contain dates in the 31st and 41st centuries!

For example, the chart for the Pioneer High Yield Fund "(SINCE 03/31/98)" is
labeled with consecutive years

  4098 3099 2000 1001 4001 4002 2003 1004 4004 3005

Apparently the dates escaped the notice of the humans (if any) at
McGraw-Hill and TruSource who were in the loop in the preparation of these
documents.  It is interesting to speculate what combination of programming
errors would yield this precise sequence of dates."



The next article in that digest,"Risks of naive date calculation" may also
be of interest for members of this list.

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Reply | Threaded
Open this post in threaded view
|

Re: Y2K++

Palmen, KEV (Karl)
Dear Amos and Calendar People

-----Original Message-----
From: East Carolina University Calendar discussion List
[mailto:[hidden email]]On Behalf Of Amos Shapir
Sent: 08 December 2005 15:05
To: [hidden email]
Subject: Y2K++


This is from the Risks Digest (a most recommended resource for computer
people) at
http://catless.ncl.ac.uk/Risks/24.11.html in an article of that subject, by
Jim Horning:

"...For some reason, I
happened to look more closely than usual at one of the charts, and noticed
something odd about the labeling of the year axis, and started inspecting
them all.  Most of them contain dates in the 31st and 41st centuries!

For example, the chart for the Pioneer High Yield Fund "(SINCE 03/31/98)" is
labeled with consecutive years

  4098 3099 2000 1001 4001 4002 2003 1004 4004 3005

KARL SAYS:
They could actually be quarter years with a 0 as a separator between the one-digit quarter number and a two-digit year number. This would be equivalent to.

1998/Q4 1999/Q3 2000/Q2 2001/Q1
2001/Q4 2002/Q4 2003/Q2 2004/Q1
2004/Q4 2005/Q3

They occur exactly once every three quarters, except for a glitch in 2002.

Karl

07(15(09
Reply | Threaded
Open this post in threaded view
|

Best Before 29 Feb 2006 RE: Y2K++

Palmen, KEV (Karl)
In reply to this post by Amos Shapir
Dear Amos and Calendar People

-----Original Message-----
From: East Carolina University Calendar discussion List
[mailto:[hidden email]]On Behalf Of Amos Shapir
Sent: 08 December 2005 15:05
To: [hidden email]
Subject: Y2K++

The next article in that digest,"Risks of naive date calculation" may also
be of interest for members of this list.

It's at
http://catless.ncl.ac.uk/Risks/24.11.html#subj10

I see it concerns an invalid date used for some cookies

BEST BEFORE 29 FEB 2006

It then said:
--- quote ---
The computer scientist in me wants to know if the comparison to a
(currently) non-existent date should:

 * always fail (Cookies are stale now),
 * always succeed (Cookies will never get stale)
 * throw an exception (Cookies should not exist in this universe)
--- end quote ---

I'd probably take to be equivalent to

BEST BEFORE 1 MAR 2006

This suggests that the operator BEFORE can be applied to some invalid dates, such as 31 June 2006, but of course not all invalid dates (e.g. 12 NEVER 2004 ).


Karl

07(15(09
Reply | Threaded
Open this post in threaded view
|

Comparison of Invalid Dates FW: Best Before 29 Feb 2006 RE: Y2K++

Palmen, KEV (Karl)
In reply to this post by Amos Shapir
Dear Calendar People

Last week I said this

-----Original Message-----
From: Palmen, KEV (Karl)
Sent: 09 December 2005 14:54
To: 'East Carolina University Calendar discussion List'
Subject: Best Before 29 Feb 2006 RE: Y2K++


Dear Amos and Calendar People

-----Original Message-----
From: East Carolina University Calendar discussion List
[mailto:[hidden email]]On Behalf Of Amos Shapir
Sent: 08 December 2005 15:05
To: [hidden email]
Subject: Y2K++

The next article in that digest,"Risks of naive date calculation" may also
be of interest for members of this list.

It's at
http://catless.ncl.ac.uk/Risks/24.11.html#subj10

I see it concerns an invalid date used for some cookies

BEST BEFORE 29 FEB 2006

It then said:
--- quote ---
The computer scientist in me wants to know if the comparison to a
(currently) non-existent date should:

 * always fail (Cookies are stale now),
 * always succeed (Cookies will never get stale)
 * throw an exception (Cookies should not exist in this universe)
--- end quote ---

I'd probably take to be equivalent to

BEST BEFORE 1 MAR 2006

This suggests that the operator BEFORE can be applied to some invalid dates, such as 31 June 2006, but of course not all invalid dates (e.g. 12 NEVER 2004 ).

KARL SAYS: Actually one could make a valid comparison with 12 NEVER 2004, provided the date you compare is of a different year. E.g.

1 January 2003 BEFORE 12 Never 2004 is TRUE
12 December 2005 BEFORE 12 Never 2004 is FALSE
12 Never 2004 BEFORE 16 Octember 2005 is TRUE
12 Never 2004 BEFORE 12 December 2004 is INVALID
12 Never 2004 BEFORE 12 December Wah! is INVALID


Karl

07(15(12
Reply | Threaded
Open this post in threaded view
|

Re: Comparison of Invalid Dates FW: Best Before 29 Feb 2006 RE: Y2K++

Lance Latham
RE:
 
> This suggests that the operator BEFORE can be
> applied to some invalid dates, such as 31 June 2006,
> but of course not all invalid dates (e.g. 12 NEVER
> 2004 ).

Lance replies:
This thread is now wandering into the area of the
'Allen algebra' that describes the 13 possible
relations between two temporal intervals.
 
> KARL SAYS: Actually one could make a valid
> comparison with 12 NEVER 2004, provided the date you
> compare is of a different year. E.g.
>
> 1 January 2003 BEFORE 12 Never 2004 is TRUE
> 12 December 2005 BEFORE 12 Never 2004 is FALSE
> 12 Never 2004 BEFORE 16 Octember 2005 is TRUE
> 12 Never 2004 BEFORE 12 December 2004 is INVALID
> 12 Never 2004 BEFORE 12 December Wah! is INVALID

Lance replies:
Generally, it's better to identify a date as invalid
and reject it, prior to using it in expressions in the
Allen algebra.

Karl's examples get into an aspect of interval
temporal logic that I like to call 'fuzzy dates',
although that term has definitions in fuzzy logic that
are not the same. In the 3rd example, the 'month' unit
is invalid for both intervals. In such a case, the
interval can be treated as 'fuzzy', in the sense that
the next largest valid temporal unit can be used to
define the interval. In this case, 2004 occurs before
2005, and the assertion is true.

In the 4th case, the month 'Never' is invalid, and the
next largest unit for both intervals is the same, so
no comparison is possible. In the 5th case, the month
of interval 1 and the year of interval 2 are invalid,
and again, no comparison is possible.

For those who wish to pursue this topic in more
detail, the Allen algebra leads to decidability
problems, and questions of NP-completeness. It is
possible, for example, to construct graphs depicting
events (nodes) and sets of relations (edges or
vertices) that represent situations, and deduce
possible temporal relations between 2 events.
Interestingly, however, it is possible to deduce
inconsistent relations when comparison of edges is
done in a pair-wise fashion; this is one area where
decidability enters the picture.

In one sense, all temporal declarations are
declarations of intervals, except for the 'instant',
which is analogous to a mathematical point; while an
interval is analogous to a line. Thus, in one sense,
all intervals are 'fuzzy'.

-Lance


Lance Latham
[hidden email]
Phone:    (518) 274-0570
Address: 78 Hudson Avenue/1st Floor, Green Island, NY 12183
 




__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 
Reply | Threaded
Open this post in threaded view
|

Re: Comparison of Invalid Dates FW: Best Before 29 Feb 2006 RE: Y2K++

Irv Bromberg
In reply to this post by Palmen, KEV (Karl)
On Dec 12, 2005, at 10:28, Palmen, KEV (Karl) wrote:

> I see it concerns an invalid date used for some cookies
>
> BEST BEFORE 29 FEB 2006
>
> It then said:
> --- quote ---
> The computer scientist in me wants to know if the comparison to a
> (currently) non-existent date should:
>
>  * always fail (Cookies are stale now),
>  * always succeed (Cookies will never get stale)
>  * throw an exception (Cookies should not exist in this universe)
> --- end quote ---

BROMBERG says:

Reingold & Dershowitz, in "Calendrical Calculations:  The Millennium
Edition" (CCME) discuss this issue with regard to their functions to
convert a separated date to a rata die (ordinal number of days since
proleptic Gregorian January 1st of year 1, where that day is day 1),
and where my functions differ from theirs I support the same concept
(for example in the Symmetry454 Calendar and Rectified Hebrew Calendar
arithmetic functions), which is (and please note that I am NOT quoting
their book, but rather explaining the gist of their stated policy):

If a day number is passed which is greater than the number of days in
the month, the rata die returned, without any special exception
processing to handle this situation, is that which would have been
returned if that day number actually existed.  This works because the
year and month are first used to calculate the rata die of the
beginning of the month, then the day number (less one day) is simply
added to that.

Likewise if a month number is passed which is greater than the number
of months in the year, then the rata die returned is that which would
have been returned if that month number existed at the position that
would be expected relative to the last existing month in the year.  Of
course if the month is a string, then the conversion to a month number
is program-defined.  If no exception is thrown, most likely a
non-existent month like "never" would be converted to zero, which, for
the Gregorian Calendar, would land in December of the prior year if one
used the CCME fixed-from-gregorian function or the equivalent.  In
other words, fixed-from-gregorian returns the same rata die for
2005/00/24 as it does for the valid date 2004/12/24, and
gregorian-from-fixed always returns 2004/12/24 for that rata die.

Likewise if the year number is non-numeric, how it would be converted
to a year number would be program-dependent.  If it is converted to a
number at all, then zero may be most likely, which would land
accordingly in the year zero (or Julian 1 BC).

The Reingold & Dershowitz generic procedure for determining if a date
is valid, which can be used with any calendar at all and any date
regardless of the leap rule or anything about the calendar structure,
is to use an appropriate function (such as theirs) to convert the
separated date to a rata die, and then the inverse function to convert
the rata die back to the separated calendar date.  For example, using
their CCME function definitions:  fixed-from-gregorian, followed by
gregorian-from-fixed.  If the separated date that comes back is the
same as the original date, then the date is valid, otherwise it is
invalid.

-- Irv Bromberg, University of Toronto, Canada

<http://www.sym454.org/>
Reply | Threaded
Open this post in threaded view
|

Re: Comparison of Invalid Dates FW: Best Before 29 Feb 2006 RE: Y2K++

Palmen, KEV (Karl)
In reply to this post by Palmen, KEV (Karl)
Dear Irv and Calendar People

Have a festive time on March 300th this year!

Karl

07(15(12 till noon

-----Original Message-----
From: East Carolina University Calendar discussion List
[mailto:[hidden email]]On Behalf Of Irv Bromberg
Sent: 12 December 2005 21:42
To: [hidden email]
Subject: Re: Comparison of Invalid Dates FW: Best Before 29 Feb 2006 RE:
Y2K++


On Dec 12, 2005, at 10:28, Palmen, KEV (Karl) wrote:

> I see it concerns an invalid date used for some cookies
>
> BEST BEFORE 29 FEB 2006
>
> It then said:
> --- quote ---
> The computer scientist in me wants to know if the comparison to a
> (currently) non-existent date should:
>
>  * always fail (Cookies are stale now),
>  * always succeed (Cookies will never get stale)
>  * throw an exception (Cookies should not exist in this universe)
> --- end quote ---

BROMBERG says:

Reingold & Dershowitz, in "Calendrical Calculations:  The Millennium
Edition" (CCME) discuss this issue with regard to their functions to
convert a separated date to a rata die (ordinal number of days since
proleptic Gregorian January 1st of year 1, where that day is day 1),
and where my functions differ from theirs I support the same concept
(for example in the Symmetry454 Calendar and Rectified Hebrew Calendar
arithmetic functions), which is (and please note that I am NOT quoting
their book, but rather explaining the gist of their stated policy):

If a day number is passed which is greater than the number of days in
the month, the rata die returned, without any special exception
processing to handle this situation, is that which would have been
returned if that day number actually existed.  This works because the
year and month are first used to calculate the rata die of the
beginning of the month, then the day number (less one day) is simply
added to that.

Likewise if a month number is passed which is greater than the number
of months in the year, then the rata die returned is that which would
have been returned if that month number existed at the position that
would be expected relative to the last existing month in the year.  Of
course if the month is a string, then the conversion to a month number
is program-defined.  If no exception is thrown, most likely a
non-existent month like "never" would be converted to zero, which, for
the Gregorian Calendar, would land in December of the prior year if one
used the CCME fixed-from-gregorian function or the equivalent.  In
other words, fixed-from-gregorian returns the same rata die for
2005/00/24 as it does for the valid date 2004/12/24, and
gregorian-from-fixed always returns 2004/12/24 for that rata die.

Likewise if the year number is non-numeric, how it would be converted
to a year number would be program-dependent.  If it is converted to a
number at all, then zero may be most likely, which would land
accordingly in the year zero (or Julian 1 BC).

The Reingold & Dershowitz generic procedure for determining if a date
is valid, which can be used with any calendar at all and any date
regardless of the leap rule or anything about the calendar structure,
is to use an appropriate function (such as theirs) to convert the
separated date to a rata die, and then the inverse function to convert
the rata die back to the separated calendar date.  For example, using
their CCME function definitions:  fixed-from-gregorian, followed by
gregorian-from-fixed.  If the separated date that comes back is the
same as the original date, then the date is valid, otherwise it is
invalid.

-- Irv Bromberg, University of Toronto, Canada

<http://www.sym454.org/>
Reply | Threaded
Open this post in threaded view
|

Re: Comparison of Invalid Dates FW: Best Before 29 Feb 2006 RE: Y2K++

Palmen, KEV (Karl)
In reply to this post by Palmen, KEV (Karl)
Dear Lance and Calendar People

-----Original Message-----
From: East Carolina University Calendar discussion List
[mailto:[hidden email]]On Behalf Of Lance Latham
Sent: 12 December 2005 16:39
To: [hidden email]
Subject: Re: Comparison of Invalid Dates FW: Best Before 29 Feb 2006 RE:
Y2K++


RE:
 
> This suggests that the operator BEFORE can be
> applied to some invalid dates, such as 31 June 2006,
> but of course not all invalid dates (e.g. 12 NEVER
> 2004 ).

Lance replies:
This thread is now wandering into the area of the
'Allen algebra' that describes the 13 possible
relations between two temporal intervals.
 
For those who wish to pursue this topic in more
detail, the Allen algebra leads to decidability
problems, and questions of NP-completeness. It is
possible, for example, to construct graphs depicting
events (nodes) and sets of relations (edges or
vertices) that represent situations, and deduce
possible temporal relations between 2 events.
Interestingly, however, it is possible to deduce
inconsistent relations when comparison of edges is
done in a pair-wise fashion; this is one area where
decidability enters the picture.

KARL SAYS: Allen Algebra seems to be so advanced that I can't find an article about it in Wikipedia and when I Google it I get Allen's Algebra, which seems to be about the same thing. This leads to Allen's interval algebra.

I then find (when Googling Interval Algebra)
http://www.cse.iitk.ac.in/~amit/interval/interval.html
which seems to be about what Lance is talking about. It even lists 13 relations.

Here they are with calendric examples

 October 2005 is BEFORE December 2005
   November 2005 MEETS December 2005
         AD 2005 OVERLAPS 5766 AH
    January 2005 STARTS 2005
   March 2005 is CONTAINED-BY 2005
   December 2005 FINISHES 2005
   December 2005 EQUALS 2005-12-01 to 2005-12-31
         2005 is STARTED-BY January 2005
            2005 CONTAINS March 2005
         2005 is FINISHED-BY December 2005
      5766 AH is OVERLAPPED-BY AD 2005
December 2005 is MET-BY November 2005
December 2005 is AFTER October 2005

Intuitively one would think that MEETS = MET-BY and OVERLAPS = OVERLAPPED-BY.
But, the MEETER must start before the MEETEE and the OVERLAPPER must start before the OVERLAPPEE (5766 AH started in October 2005).

Then any pair of intervals has exactly ONE of these relations.

For finding valid BEFORE and AFTER relations between invalid dates, each invalid date is taken to be an interval. For example 29 FEB 2006, is taken to be in instant between 28 FEB 2006 and 1 MAR 2006, while 12 NEVER 2004 is taken to be the year 2004.


Karl

07(15(13
Reply | Threaded
Open this post in threaded view
|

Re: Comparison of Invalid Dates FW: Best Before 29 Feb 2006 RE: Y2K++

Palmen, KEV (Karl)
In reply to this post by Palmen, KEV (Karl)
Dear Lance, Irv, Victor and Calendar People

The method that Irv mentions here differs from mine, in which interval is equivalent to each invalid date. In particular, for Irv's suggestion each such interval is a single day.
 

Here are some examples:
           
29 FEB 2006
KARL: Instant between 28 FEB 2006 and 1 MAR 2006
IRV:  1 MAR 2006

300 March 2005
KARL: Instant between 31 March 2005 and 1 April 2005
IRV: 25 December 2005

2005-14-14
KARL: Instant between 2005-12-31 and 2006-01-01
IRV:  2006-02-14

12 NEVER 2004
KARL: year 2004
IRV: depends on interpretation of NEVER

Monday December 2005
KARL: December 2005 or
      Monday 5 December to Monday 26 December inclusive
IRV: ???

December 2005
KARL: December 2005
IRV: possibly, 30 November 2005

12 16 December 2005
KARL: possibly, 12-16 December 2005
IRV: ???

13 December
KARL: All time (i.e. no comparison is valid )
IRV: ???

13 December 2005-2009
KARL: 13 December 2005 to 13 December 2009 inclusive
IRV: ???

Doomsday
KARL: All time (i.e. no comparison is valid )
IRV: ???

Note that only BEFORE and AFTER comparisons can be used in my method, whereas BEFOR, AFTER and EQUALS can be applied to Irv's method.

Karl

07(15(13

-----Original Message-----
From: East Carolina University Calendar discussion List
[mailto:[hidden email]]On Behalf Of Irv Bromberg
Sent: 12 December 2005 21:42
To: [hidden email]
Subject: Re: Comparison of Invalid Dates FW: Best Before 29 Feb 2006 RE:
Y2K++


On Dec 12, 2005, at 10:28, Palmen, KEV (Karl) wrote:

> I see it concerns an invalid date used for some cookies
>
> BEST BEFORE 29 FEB 2006
>
> It then said:
> --- quote ---
> The computer scientist in me wants to know if the comparison to a
> (currently) non-existent date should:
>
>  * always fail (Cookies are stale now),
>  * always succeed (Cookies will never get stale)
>  * throw an exception (Cookies should not exist in this universe)
> --- end quote ---

BROMBERG says:

Reingold & Dershowitz, in "Calendrical Calculations:  The Millennium
Edition" (CCME) discuss this issue with regard to their functions to
convert a separated date to a rata die (ordinal number of days since
proleptic Gregorian January 1st of year 1, where that day is day 1),
and where my functions differ from theirs I support the same concept
(for example in the Symmetry454 Calendar and Rectified Hebrew Calendar
arithmetic functions), which is (and please note that I am NOT quoting
their book, but rather explaining the gist of their stated policy):

If a day number is passed which is greater than the number of days in
the month, the rata die returned, without any special exception
processing to handle this situation, is that which would have been
returned if that day number actually existed.  This works because the
year and month are first used to calculate the rata die of the
beginning of the month, then the day number (less one day) is simply
added to that.

Likewise if a month number is passed which is greater than the number
of months in the year, then the rata die returned is that which would
have been returned if that month number existed at the position that
would be expected relative to the last existing month in the year.  Of
course if the month is a string, then the conversion to a month number
is program-defined.  If no exception is thrown, most likely a
non-existent month like "never" would be converted to zero, which, for
the Gregorian Calendar, would land in December of the prior year if one
used the CCME fixed-from-gregorian function or the equivalent.  In
other words, fixed-from-gregorian returns the same rata die for
2005/00/24 as it does for the valid date 2004/12/24, and
gregorian-from-fixed always returns 2004/12/24 for that rata die.

Likewise if the year number is non-numeric, how it would be converted
to a year number would be program-dependent.  If it is converted to a
number at all, then zero may be most likely, which would land
accordingly in the year zero (or Julian 1 BC).

The Reingold & Dershowitz generic procedure for determining if a date
is valid, which can be used with any calendar at all and any date
regardless of the leap rule or anything about the calendar structure,
is to use an appropriate function (such as theirs) to convert the
separated date to a rata die, and then the inverse function to convert
the rata die back to the separated calendar date.  For example, using
their CCME function definitions:  fixed-from-gregorian, followed by
gregorian-from-fixed.  If the separated date that comes back is the
same as the original date, then the date is valid, otherwise it is
invalid.

-- Irv Bromberg, University of Toronto, Canada

<http://www.sym454.org/>
Reply | Threaded
Open this post in threaded view
|

Re: Comparison of Invalid Dates FW: Best Before 29 Feb 2006 RE: Y2K++

Lance Latham
In reply to this post by Palmen, KEV (Karl)
RE:

> KARL SAYS: Allen Algebra seems to be so advanced
> that I can't find an article about it in Wikipedia
> and when I Google it I get Allen's Algebra, which
> seems to be about the same thing. This leads to
> Allen's interval algebra.


Lance replies:
Over time, the term has been shortened to just 'Allen
algebra'. The Allen algebra is not complex at all, but
its ramifications can get get hairy in a hurry.

The original paper is:

Allen, J.F. (1983). "Maintaining Knowledge about
Temporal Intervals", CACM, 26 (11), 832-843.

Most of the work done in exploring the Allen algebra
has been performed under the rubric of 'artificial
intelligence', where the determination and
representation of temporal interval information is
extremely important. This matter is central to the
so-called 'frame problem'.

A good exemplar paper might be:

Jonsson, P., Drakengren, T., Backstrom, C. (1999).
"Computational complexity of relating time points with
intervals", Artifical Intelligence, 109, 273-295.

which looks at computational complexity, or

Krokhin, A., Jeavons, P., Jonsson, P. (2003).
"Reasoning about Temporal Relations: The Tractable
Subalgebras of Allen's Interval Algebra", JACM, 50
(5), 591-640.

which looks at the tractability issue after dividing
the algebra into subsets.

There are other algebras based on slightly different
assumptions, such as instants and intervals, versus
intervals only. For that, try:

Vilain, M.B. (1982). "A system for reasoning about
time", in Proceedings AAAI-82, Pittsburgh, PA,
197-201.

From the work on interval temporal logic have sprung
still more variants and applications, such as
'Duration Calculus'.

> Intuitively one would think that MEETS = MET-BY and
> OVERLAPS = OVERLAPPED-BY.
> But, the MEETER must start before the MEETEE and the
> OVERLAPPER must start before the OVERLAPPEE (5766 AH
> started in October 2005).

Lance replies:
There are exactly 13 possible relations between two
proper intervals. An interval is 'proper' if it has
duration, i.e., is not an instant. Anyone can sit down
and come up with these on his own with a little
thought. The easiest way to do this is to represent
the intervals graphically:

         xxxxxxxxxxxx

                         yyyyyyyyyyyy

Here, interval 'x' occurs strictly before interval
'y'. In the Allen algebra, "x < y".

        xxxxxxxxxxxxxx
                      yyyyyyyyyyyyyyy

Here, 'x' meets 'y', or "x m y", or "m (x, y)".

                      xxxxxxxxxxxxxxxx
        yyyyyyyyyyyyyy

Here, 'x' is met by 'y', and one can say "x m' y", to
indicate an inverse. Other notations are used also,
like superscript "-1", 'mi', other letters, etc.

Obviously, there are really 7 basic relations, each of
which has an inverse. In the case of the 'equals'
relation, the relation is its own inverse, so we have
13 separate and distinct relations, not 14.

One of the more complex results in the Allen paper was
the systematic working out of the possible
consequences of two relations, in a very large table.
A problem with the algebra is its tendency to
exponentially blow up in terms of the number of
possible cases to consider. You get simplicity up
front, but you pay for it later.

 > For finding valid BEFORE and AFTER relations
between
> invalid dates, each invalid date is taken to be an
> interval. For example 29 FEB 2006, is taken to be in
> instant between 28 FEB 2006 and 1 MAR 2006, while 12
> NEVER 2004 is taken to be the year 2004.

Lance replies:
There are two separate considerations here. One is the
algebra itself, and the other is my personal approach
to invalid data. Since Irv's comments are involved
here, I'll just fold everything into one reply.

As Irv pointed out, it is possible as Dershowitz and
Reingold do, to treat dates in a comprehensive way
that returns a value in almost every case.

There is nothing wrong with this approach; rather what
is involved is one's approach to processing data, the
purposes for which code is written, and the
environment in which it is written.

D&R represents a more academic approach, in which one
writes intelligent code that returns a value whenever
possible. The emphasis is on clever code, reducing the
number of exceptions, and dependence upon the
assumption that users are smart enough to use the code
properly.

My approach has been conditioned by years of
experience designing and writing code for large
systems that see daily use. In that environment,
cleverness of any kind is anathema, one writes code so
simple that the newbie can fix it, and one assumes
that the users are malicious idiots. As a matter of
practical experience, I have found that weeding out
invalid or suspicious data prior to processing is
simply the wisest course, and I believe that approach
is well-supported by the tenets of software
engineering, whatever the hell that is.

The point is, different environments and purposes
produce different assumptions and approaches.

Regarding Karl's examples, I would observe that a date
should  not be an instant, but should be a proper
interval. The conundrum here is that 29 FEB 2006 is
either (a) invalid or (b) the same as 01 MAR 2006
using the more relaxed rules. Hence, it cannot obey a
'between' relation, i.e., a < b, b < c. Regarding it
as invalid avoids a lot of problems.

Regarding the promotion of an invalid date to the next
larger temporal unit, that is again a matter of
approach and definition. Personally, I believe that
the wisest course is to treat such a date as invalid.
This topic moves the discussion into the area of
'fuzzy dates'. There are a number of ways to define
such a thing. One way is to define a weighting
function, along the lines of fuzzy logic. Another is
to identify the smallest valid temporal unit and then
define the interval by the resulting endpoints, which
is the 'promotion' process.

Generally, I believe, such a process is not wise, but
situations can arise in which it, or something very
like it, becomes necessary. For example, assume a
genealogy (or other) database that records dates of
birth and death. For some early records, one may have
only a year or year and month of birth (and/or death).
To treat such a 'date' consistently as an interval,
one must use the promotion process, which does, in
fact, represent the uncertainty in the date. Properly
handling the relations between intervals, using the
Allen relations, is critical to defining functions
that ensure data integrity in the database.

As a practical example, if a child were born on 20 DEC
1783, and the father only is known to have died in
1783, the birth can be flagged as potentially
questionable. If 'Daddy' actually died in January of
1783, the widow may have been a bit quicker to seek
solace than 'Daddy' would have liked. If he died in
October 1783, we don't have the same obvious problem.
If he died in 1782, we have a definite problem for
parentage regardless.

Backing up several paragraphs, I would also add that,
again, the lack of recognition that technical
chronology is a proper field of study in its own right
has led to the scattering of the literature and the
diffusion of information across a large number of
other fields.

-Lance
 

Lance Latham
[hidden email]
Phone:    (518) 274-0570
Address: 78 Hudson Avenue/1st Floor, Green Island, NY 12183
 




__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 
Reply | Threaded
Open this post in threaded view
|

Re: Comparison of Invalid Dates FW: Best Before 29 Feb 2006 RE: Y2K++

Lance Latham
In reply to this post by Palmen, KEV (Karl)
RE:
   
> 29 FEB 2006
> KARL: Instant between 28 FEB 2006 and 1 MAR 2006
> IRV:  1 MAR 2006

Lance replies:

No.

The Allen algebra only is defined for proper
intervals. If you wish to mix instants and intervals,
there are other reasoning systems that do that. Vide
the Vilain reference in my previous post. Other
systems only operate with instants. There are logical
and/or philosophical problems regardless of which
choice you make, mostly related to the question of the
'density' of time.

Do not confuse the algebra itself with the convention
used for dealing with invalid dates.

-Lance


Lance Latham
[hidden email]
Phone:    (518) 274-0570
Address: 78 Hudson Avenue/1st Floor, Green Island, NY 12183
 




__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 
Reply | Threaded
Open this post in threaded view
|

Re: Comparison of Invalid Dates FW: Best Before 29 Feb 2006 RE: Y2K++

Palmen, KEV (Karl)
In reply to this post by Palmen, KEV (Karl)
Dear Lance and Calendar People

-----Original Message-----
From: East Carolina University Calendar discussion List
[mailto:[hidden email]]On Behalf Of Lance Latham
Sent: 13 December 2005 15:49
To: [hidden email]
Subject: Re: Comparison of Invalid Dates FW: Best Before 29 Feb 2006 RE:
Y2K++


RE:
   
> 29 FEB 2006
> KARL: Instant between 28 FEB 2006 and 1 MAR 2006
> IRV:  1 MAR 2006

Lance replies:

No.

The Allen algebra only is defined for proper
intervals. If you wish to mix instants and intervals,
there are other reasoning systems that do that. Vide
the Vilain reference in my previous post. Other
systems only operate with instants. There are logical
and/or philosophical problems regardless of which
choice you make, mostly related to the question of the
'density' of time.

Do not confuse the algebra itself with the convention
used for dealing with invalid dates.

KARL SAYS: I'm sure a subset of the 13 relationships would apply, even if the Allen algebra does not itself apply.

Generally, from any two dates d1 and d2 valid or invalid exactly ONE of the following applies:

d1 is BEFORE d2
d1 is EQUAL to d2
d1 is AFTER d2
d1 is INVALID-TO d2

BEFORE, AFTER and EQUAL follow the rules of a partial ordering for all dates and a full ordering for all valid dates.

I've noticed another difference between Irv's scheme and mine.

In Irv's scheme two dates are EQUAL if they correspond to the same interval (always of one day). Also Irv's scheme is fully ordered for all dates (i.e. there is no pair of dates that are INVALID-TO each other).

In my scheme, two dates must be of the same form to be EQUAL (e.g. 29 FEB 2006 = 2006-02-29 ) and not just have the same interval ( 29 FEB 2006 != 30 FEB 2006) or
(12 NEVER 2004 != 14 NEVER 2004). My scheme is not fully ordered but has the INVALID-TO relationship, which may occur is either date is invalid.
Each interval of valid dates that corresponds to an invalid date must be derivable from the partial ordering relationship of all dates, which is fully ordered for valid dates.

I realise that all valid dates plus those like 29 FEB 2006 are fully ordered and so are all BEFORE, EQUAL or AFTER each other. However unlike the valid dates alone, not all intervals of finite duration are closed. For example, one can have N FEB 2006, when N is any integer, which has no beginning or end date.


Karl

07(15(13
Reply | Threaded
Open this post in threaded view
|

Re: Comparison of Invalid Dates FW: Best Before 29 Feb 2006 RE: Y2K++

Irv Bromberg
In reply to this post by Lance Latham
On Dec 13, 2005, at 10:40, Lance Latham wrote:
> Regarding Karl's examples, I would observe that a date
> should  not be an instant, but should be a proper
> interval. The conundrum here is that 29 FEB 2006 is
> either (a) invalid or (b) the same as 01 MAR 2006
> using the more relaxed rules. Hence, it cannot obey a
> 'between' relation, i.e., a < b, b < c. Regarding it
> as invalid avoids a lot of problems.

BROMBERG says:

What am I missing here?

(February has 35 days, so 29 Feb is perfectly valid, no?)

-- Irv Bromberg, Toronto, Canada

<http://www.sym454.org/>
Reply | Threaded
Open this post in threaded view
|

Re: Comparison of Invalid Dates FW: Best Before 29 Feb 2006 RE: Y2K++

Palmen, KEV (Karl)
In reply to this post by Palmen, KEV (Karl)
Dear Irv and Calendar People

-----Original Message-----
From: East Carolina University Calendar discussion List
[mailto:[hidden email]]On Behalf Of Irv Bromberg
Sent: 13 December 2005 18:53
To: [hidden email]
Subject: Re: Comparison of Invalid Dates FW: Best Before 29 Feb 2006 RE:
Y2K++


On Dec 13, 2005, at 10:40, Lance Latham wrote:
> Regarding Karl's examples, I would observe that a date
> should  not be an instant, but should be a proper
> interval. The conundrum here is that 29 FEB 2006 is
> either (a) invalid or (b) the same as 01 MAR 2006
> using the more relaxed rules. Hence, it cannot obey a
> 'between' relation, i.e., a < b, b < c. Regarding it
> as invalid avoids a lot of problems.

BROMBERG says:

What am I missing here?

(February has 35 days, so 29 Feb is perfectly valid, no?)

An appropriate example for the Symmetry Calendar would be March 30, which could be considered to be AFTER all valid dates in January and February, while being BEFORE all valid dates in April and all later months. So it could be considered to occur in an instant between March 28 and April 1 in the symmetry calendar. The same would also apply to March 29 and its instant occurs BEFORE the instant for March 30.

Karl

07(15(13 till noon
Reply | Threaded
Open this post in threaded view
|

Re: Comparison of Invalid Dates FW: Best Before 29 Feb 2006 RE: Y2K++

Lance Latham
In reply to this post by Palmen, KEV (Karl)
RE:

> Do not confuse the algebra itself with the
> convention
> used for dealing with invalid dates.
>
> KARL SAYS: I'm sure a subset of the 13 relationships
> would apply, even if the Allen algebra does not
> itself apply.

Lance replies:
The 13 relations are specifically defined within the
Allen algebra, and specifically concern proper
intervals. It might be possible to define analogous
relations between an instant and a proper interval for
some cases. An instant might be contained in an
interval, for example, but the converse cannot be
true; nor can equality or overlap be true.

 
> Generally, from any two dates d1 and d2 valid or
> invalid exactly ONE of the following applies:
>
> d1 is BEFORE d2
> d1 is EQUAL to d2
> d1 is AFTER d2
> d1 is INVALID-TO d2

Lance replies:

It might be interesting to work out the ramifications
of specific conventions for invalid dates.

Note also that in defining 'date' one may use
different calendars. In fact, that is part of the
utility of defining dates that way. So, one can
actually handle the fact that a Jewish date, for
example, does not exactly 'equal' a Gregorian date, a
fact that we generally sweep under the rug with a bit
of hand-waving when performing date conversions.
Karl's classification above is thus not true, but
could be worked into something useful with a fuller
analysis, and a focus on a specific definition of
invalidity and its consequences for interval
representation.

> BEFORE, AFTER and EQUAL follow the rules of a
> partial ordering for all dates and a full ordering
> for all valid dates.
>
> I've noticed another difference between Irv's scheme
> and mine.
>
> In Irv's scheme two dates are EQUAL if they
> correspond to the same interval (always of one day).
> Also Irv's scheme is fully ordered for all dates
> (i.e. there is no pair of dates that are INVALID-TO
> each other).

Lance replies:
The relevant interval for calendric matters is
typically the unit day. As I noted above, that varies
somewhat, depending upon the calendar. Also note that
defining dates in terms of temporal intervals permits
adjustments for 'longitude of use', advanced time, and
so forth. These are useful for accuracte calculation
in the context of 'DOO technology', i.e., determining
the impact of day of observance (DOO) across multiple
calendric systems and defining authorities for a given
period of time.

The problem with the above scheme is that 'invalid-to'
is not defined. Perhaps it could be defined in the
context of a specific convention for converting
invalid dates to proper intervals.
 
> In my scheme, two dates must be of the same form to
> be EQUAL (e.g. 29 FEB 2006 = 2006-02-29 ) and not
> just have the same interval ( 29 FEB 2006 != 30 FEB
> 2006) or
> (12 NEVER 2004 != 14 NEVER 2004). My scheme is not
> fully ordered but has the INVALID-TO relationship,
> which may occur is either date is invalid.

Lance replies:
If I understand this correctly, a date like 35 Never
2018 (Gregorian) would be promoted under a set of (as
yet undefined) rules to be '2018', which would be the
interval 01 JAN 2018 through 31 DEC 2018, but would
not be 'equal' to that interval because it is not 'of
the same form'. The date 35 Never 2018 would be
'invalid-to' that interval, however, since the date is
invalid. The result seems to defeat te purpose of the
promotion process.

I suppose that I am failing to understand the purpose
of the 'invalid-to' relation. Either an invalid date
can be mapped to a valid proper interval, or it
cannot, under a specific convention. If it cannot be
so mapped, then the question does not concern a new
relation, but the fact that the data is simply
invalid. If it can be so mapped, then we just move
along with the Allen relations. In neither case do I
detect a need for a new relation.

> Each interval of valid dates that corresponds to an
> invalid date must be derivable from the partial
> ordering relationship of all dates, which is fully
> ordered for valid dates.
>
> I realise that all valid dates plus those like 29
> FEB 2006 are fully ordered and so are all BEFORE,
> EQUAL or AFTER each other.

Lance replies:
Again, that's a matter of definition of invalid date,
and what to do about invalid data in general. Which
was the original question. I have indicated that
option 3, 'cookies do not exist in this Universe' is
probably the best option, in my opinion. As I
indicated in prior messages, that's a matter of
context and approach, and really has nothing to do
with relations in the Allen algebra per se.

Also, recall the Jewish/Gregorian date issue. One must
admit the 'overlap' cases. If a calendar were to
define dates ('days') in terms of tithis, or in terms
of 'daeg' and 'niht' (half-days), then one would need
to include the 'contains' relations as well.

Also, one cannot identify a specific relation unless
the 2 intervals are exactly known, in terms of their
endpoints.

> However unlike the valid
> dates alone, not all intervals of finite duration
> are closed. For example, one can have N FEB 2006,
> when N is any integer, which has no beginning or end
> date.

Lance replies:
Karl has hit upon a central problem of definition for
temporal intervals, which is the question of infinity.
How one deals with that has a lot to do with how the
algebra works. Normally, one declares 'a' and 'b' to
be instants and declares an interval to be a period P
such that [a, b] is a proper interval if a < b, so
that D ([a, b]) > 0, where 'D' represents duration of
the interval, and is defined as (b - a). An instant,
for example, is an interval [a, a], with duration 0,
and is not a proper interval. How to represent an
interval that is open on one end is a problem. One
solution is just to say that infinity is a point
(instant), and move on. Another solution excludes such
intervals from the universe of discourse altogether.

In summary, I believe that Karl has the germ of a good
idea here. I do believe that one needs to define a
specific convention for transforming invalid dates to
proper intervals before discussing the matter in
detail. Clearly, some dates will still be invalid. '37
Octember Wah' is not a valid Gregorian date, no matter
what your (reasonable) convention might be. Not even
in Irv's Universe.

-Lance


Lance Latham
[hidden email]
Phone:    (518) 274-0570
Address: 78 Hudson Avenue/1st Floor, Green Island, NY 12183
 




__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 
Reply | Threaded
Open this post in threaded view
|

Re: Comparison of Invalid Dates FW: Best Before 29 Feb 2006 RE: Y2K++

Lance Latham
In reply to this post by Irv Bromberg
RE:

> What am I missing here?
>
> (February has 35 days, so 29 Feb is perfectly valid,
> no?)

Lance replies:
Irv, if your February has 35 days, you're good to go,
no problem. My coment concerned the observation that
instants (no duration) should not be confused with
proper intervals in the Allen algebra.

-Lance


Lance Latham
[hidden email]
Phone:    (518) 274-0570
Address: 78 Hudson Avenue/1st Floor, Green Island, NY 12183
 




__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 
Reply | Threaded
Open this post in threaded view
|

Re: Comparison of Invalid Dates FW: Best Before 29 Feb 2006 RE: Y2K++

Lance Latham
In reply to this post by Palmen, KEV (Karl)
RE:

> An appropriate example for the Symmetry Calendar
> would be March 30, which could be considered to be
> AFTER all valid dates in January and February, while
> being BEFORE all valid dates in April and all later
> months. So it could be considered to occur in an
> instant between March 28 and April 1 in the symmetry
> calendar. The same would also apply to March 29 and
> its instant occurs BEFORE the instant for March 30.

Lance replies:
I repeat, an instant is not a proper interval. A day
has duration, and cannot be an instant, if defined in
a manner consistent with the Allen algebra. Or
interval logic, generally.

-Lance


Lance Latham
[hidden email]
Phone:    (518) 274-0570
Address: 78 Hudson Avenue/1st Floor, Green Island, NY 12183
 




__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 
Reply | Threaded
Open this post in threaded view
|

Re: Comparison of Invalid Dates FW: Best Before 29 Feb 2006 RE: Y2K++

Palmen, KEV (Karl)
In reply to this post by Palmen, KEV (Karl)
Dear Lance and Calendar People

-----Original Message-----
From: East Carolina University Calendar discussion List
[mailto:[hidden email]]On Behalf Of Lance Latham
Sent: 14 December 2005 14:17
To: [hidden email]
Subject: Re: Comparison of Invalid Dates FW: Best Before 29 Feb 2006 RE:
Y2K++


RE:

> Do not confuse the algebra itself with the
> convention
> used for dealing with invalid dates.
>
> KARL SAYS: I'm sure a subset of the 13 relationships
> would apply, even if the Allen algebra does not
> itself apply.

Lance replies:
The 13 relations are specifically defined within the
Allen algebra, and specifically concern proper
intervals. It might be possible to define analogous
relations between an instant and a proper interval for
some cases. An instant might be contained in an
interval, for example, but the converse cannot be
true; nor can equality or overlap be true.

KARL SAYS:
Yes. Also, the Allen Algebra seems to be defined for intervals of real numbers, whereas intervals of valid dates are like intervals of integers and so the MEETS and MET_BY relationships may be inapplicable.

 
> Generally, from any two dates d1 and d2 valid or
> invalid exactly ONE of the following applies:
>
> d1 is BEFORE d2
> d1 is EQUAL to d2
> d1 is AFTER d2
> d1 is INVALID-TO d2

KARL SAYS:
This implies a definition of INVALID-TO in terms of the other 3 relationships. Note the these relationships apply only to dates and not also to intervals.


LANCE CONTINUES:
Lance replies:

It might be interesting to work out the ramifications
of specific conventions for invalid dates.

Note also that in defining 'date' one may use
different calendars. In fact, that is part of the
utility of defining dates that way. So, one can
actually handle the fact that a Jewish date, for
example, does not exactly 'equal' a Gregorian date, a
fact that we generally sweep under the rug with a bit
of hand-waving when performing date conversions.
Karl's classification above is thus not true,

KARL: This would not be covered by BEFORE, AFTER, EQUALS and INVALID_TO.

but could be worked into something useful with a fuller
analysis, and a focus on a specific definition of
invalidity and its consequences for interval
representation.


LANCE CONTINUES (first quoting me):
> In my scheme, two dates must be of the same form to
> be EQUAL (e.g. 29 FEB 2006 = 2006-02-29 ) and not
> just have the same interval ( 29 FEB 2006 != 30 FEB
> 2006) or
> (12 NEVER 2004 != 14 NEVER 2004). My scheme is not
> fully ordered but has the INVALID-TO relationship,
> which may occur is either date is invalid.

Lance replies:
If I understand this correctly, a date like 35 Never
2018 (Gregorian) would be promoted under a set of (as
yet undefined) rules to be '2018', which would be the
interval 01 JAN 2018 through 31 DEC 2018, but would
not be 'equal' to that interval because it is not 'of
the same form'. The date 35 Never 2018 would be
'invalid-to' that interval, however, since the date is
invalid. The result seems to defeat te purpose of the
promotion process.

KARL SAYS:
Yes, but I regard the mapping of an invalid date to an interval to be derivative of the BEFORE, EQUALS, AFTER and INVALID-TO relationships between DATES including invalid dates. Lance is talking about applying these same relationships to dates and intervals. I'm talking about deriving the intervals from these relationships.

LANCE CONTINUES:
I suppose that I am failing to understand the purpose
of the 'invalid-to' relation. Either an invalid date
can be mapped to a valid proper interval, or it
cannot, under a specific convention. If it cannot be
so mapped, then the question does not concern a new
relation, but the fact that the data is simply
invalid. If it can be so mapped, then we just move
along with the Allen relations. In neither case do I
detect a need for a new relation.

KARL SAYS:
I think Lance's misunderstanding arises from him thinking that the BEFORE, AFTER, EQUALS and INVALID_TO that I defined apply to intervals. I'm sorry that I didn't make that clear in my previous note.

I see the following scenarios when comparing valid dates with an invalid date J via the BEFORE, AFTER, EQUALS and INVALID_TO relationships between DATES.

1) All valid dates are AFTER J [a].
2) There exists a valid date F so that all valid dates AFTER F are AFTER J
and all other valid dates are INVALID_TO J [ia].
3) There exist valid dates B BEFORE F, so that all valid dates AFTER F are AFTER J, all valid dates BEFORE B are BEFORE J and all other valid dates are INVALID_TO J [bia].
4) There is a valid date E such that E EQUALS J all other valid dates are either BEFORE J or AFTER J [bea].
5) All valid dates are either BEFORE J or AFTER J [ba].
6) There exists a valid date B so that all valid dates BEFORE B are BEFORE J
and all other valid dates are INVALID_TO J [bi].
7) All valid dates are BEFORE J [b].
8) All valid dates are INVALID_TO J [i].

Note that BEFORE, AFTER and EQUALS form a partial ordering over all dates and a full ordering over valid dates. Two valid dates are EQUAL only if they are the same date.

All Irv's invalid dates follow scenario 4 [bea].
My examples have been either scenario 3 [bia] or 5 [ba].
One could have an invalid date 'START OF TIME' that follows scenario 1 [a] or 'BC' that follows scenario 2 [ia].

The situation of comparing 2 invalid dates is more complicated and I may deal with it later on. This could lead to lots of fun with improper intervals.

> Each interval of valid dates that corresponds to an
> invalid date must be derivable from the partial
> ordering relationship of all dates, which is fully
> ordered for valid dates.
>
> I realise that all valid dates plus those like 29
> FEB 2006 are fully ordered and so are all BEFORE,
> EQUAL or AFTER each other.

Lance replies:
Again, that's a matter of definition of invalid date,
and what to do about invalid data in general. Which
was the original question. I have indicated that
option 3, 'cookies do not exist in this Universe' is
probably the best option, in my opinion.

KARL SAYS: This is scenario 8, which would apply all invalid dates that yield no useful information such as '12 Never Wah!' or 'COOKIES'.

LANCE CONTINUES:
As I indicated in prior messages, that's a matter of
context and approach, and really has nothing to do
with relations in the Allen algebra per se.

KARL SAYS: I have taken a different approach to the Allen algebra.

Also, recall the Jewish/Gregorian date issue. One must
admit the 'overlap' cases. If a calendar were to
define dates ('days') in terms of tithis, or in terms
of 'daeg' and 'niht' (half-days), then one would need
to include the 'contains' relations as well.

KARL SAYS:
This is another issue. One could expand BEFORE, AFTER, EQUALS, INVALID_TO to cover this. The 8 interval scenarios could then be much more complicated.
I'm not prepared to do this. It would require replacing the full/partial ordering of dates with some full/partial ordering-like thingy based on an Allen algebra or the like.

This may explain why Lance rejects improper intervals (i.e. instances) out of hand. This was the very basis of what I said in the thread right at the beginning and Lance has since slipped in the idea of extending this to multiple calendars with dates starting at different times. I'm not going to do this.

What I will say is extending it to multiple calendars (even with same date starts) limits the context and hence makes dates such as '14 December 2005' invalid, because we don't know whether it is a Gregorian, Julian, IFC or Dee date.


Karl

07(15(14
Reply | Threaded
Open this post in threaded view
|

Re: Comparison of Invalid Dates FW: Best Before 29 Feb 2006 RE: Y2K++

Lance Latham
RE:

> KARL SAYS:
> Yes. Also, the Allen Algebra seems to be defined for
> intervals of real numbers, whereas intervals of
> valid dates are like intervals of integers and so
> the MEETS and MET_BY relationships may be
> inapplicable.

Lance replies:
Absolutely, yes, we are talking about a real number
line here, and translating dates to JD#s or something
equivalent. The Allen algebra requires that; an
'overlap' is not possible with single integer units.

I see from Karl's comments that the discussion
actually diverges on that basis.

> KARL SAYS:
> This implies a definition of INVALID-TO in terms of
> the other 3 relationships. Note the these
> relationships apply only to dates and not also to
> intervals.

Lance replies:
Okay, an example of how this discussion has diverged
on the real-integer matter. For the purposes of the
Allen algebra, a date would be a 24-hour period that
can be represented as a pair of real numbers on a
linear time scale like the JD# system. If the date
were Gregorian, then we would define that interval P
as [beg, end], where P.beg = 2399999.5 and P.end =
2400000.5, for example. A 'corresponding' Jewish date
might be defined as [2399999.25, 2400000.25].
 
In the Allen algebra, a date IS an interval. So what
Karl has in mind is something related.
 
> KARL SAYS:
> Yes, but I regard the mapping of an invalid date to
> an interval to be derivative of the BEFORE, EQUALS,
> AFTER and INVALID-TO relationships between DATES
> including invalid dates. Lance is talking about
> applying these same relationships to dates and
> intervals. I'm talking about deriving the intervals
> from these relationships.

Lance replies:
The Allen algebra does not require that intervals be
metrically and precisely known in every case, in order
to obtain information about relative timing. If 'a <
b' and 'b < c' are given, that we can deduce 'a < c'
without ever knowing precise values. In fact,
developing a way of 'relative' reasoning was part of
the original reason for developing the algebra in the
first place.

Okay, so we're NOT talking about the Allen algebra,
but about something that we can tentatively call
"Karl's algebra". Fair enough, this may be useful. In
that case, different conventions for transforming
invalid dates to valid dates may produce sub-algebras.

If the definitions are formalized and notation
tightened up, we probably have the start of something
interesting here.

-Lance
 

Lance Latham
[hidden email]
Phone:    (518) 274-0570
Address: 78 Hudson Avenue/1st Floor, Green Island, NY 12183
 




__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com