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/ |
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 |
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 |
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 |
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 |
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/> |
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/> |
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 |
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/> |
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 |
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 |
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 |
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/> |
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 |
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 |
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 |
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 |
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 |
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 |
Free forum by Nabble | Edit this page |