<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Alan Lovejoy wrote:
<blockquote cite="midmd5:64756D6D79206D657373616765206964" type="cite">
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<meta content="MSHTML 6.00.2900.2873" name="GENERATOR">
<div align="left" dir="ltr"><span class="405053716-21042006"><font
color="#0000ff" face="Arial" size="2"><br>
<font color="#000000" face="Times New Roman" size="3"></font></font></span></div>
<div align="left" dir="ltr"><span class="405053716-21042006"><font
color="#0000ff" face="Arial" size="2">Whatever the case, a thesis
requirement (or a desire to learn by doing) is admittedly a valid
reason to reinvent the wheel. I've done the same myself.</font></span></div>
</blockquote>
You are right! We planned this thesis after me going to ESUG last
year... <br>
[snip]<br>
<blockquote cite="midmd5:64756D6D79206D657373616765206964" type="cite">
<div><font><font><font color="#0000ff" face="Arial" size="2"><span
class="405053716-21042006">P.S. I'm sure we'll have more to talk
about "as time goes by." (Heh)</span></font></font></font></div>
</blockquote>
Cool!, let's keep in touch.<br>
<br>
Hernan.<br>
<blockquote cite="midmd5:64756D6D79206D657373616765206964" type="cite">
<div align="left" dir="ltr"><br>
</div>
<div class="OutlookMessageHeader" align="left" dir="ltr" lang="en-us">
<hr tabindex="-1"><font face="Tahoma" size="2"><b>From:</b>
<a class="moz-txt-link-abbreviated" href="mailto:squeak-dev-bounces@lists.squeakfoundation.org">squeak-dev-bounces@lists.squeakfoundation.org</a>
[<a class="moz-txt-link-freetext" href="mailto:squeak-dev-bounces@lists.squeakfoundation.org">mailto:squeak-dev-bounces@lists.squeakfoundation.org</a>] <b>On Behalf Of
</b>Hernan Wilkinson<br>
<b>Sent:</b> Friday, April 21, 2006 5:49 AM<br>
<b>To:</b> The general-purpose Squeak developers list<br>
<b>Subject:</b> Re: The Timing of Time<br>
</font><br>
</div>
Alan Lovejoy wrote:
<blockquote cite="midmd5:64756D6D79206D657373616765206964" type="cite">
<pre wrap="">Jeff, Hernan:
I also will put my comments in-line, following Hernan's, preceded by ##:
-----Original Message-----
From: <a class="moz-txt-link-abbreviated"
href="mailto:squeak-dev-bounces@lists.squeakfoundation.org">squeak-dev-bounces@lists.squeakfoundation.org</a>
[<a class="moz-txt-link-freetext"
href="mailto:squeak-dev-bounces@lists.squeakfoundation.org">mailto:squeak-dev-bounces@lists.squeakfoundation.org</a>] On Behalf Of Hernan
Wilkinson
Sent: Thursday, April 20, 2006 3:20 PM
To: The general-purpose Squeak developers list
Subject: Re: The Timing of Time
Hi Jeff, I will answer your questions over Alan's responses to make it easy
to compare both solutions. (I hope Alan you don't mind...)
Alan Lovejoy wrote:
[snip]
</pre>
<blockquote type="cite">
<pre wrap="">Date equality works correctly between different calendars, and
Timepoint equality works correctly between different time zones and/or
different calendars.
</pre>
</blockquote>
<pre wrap=""><!---->Chalten does not have support for time zone or different calendars. It just
support the Gregorian Calendar; we are planning to add support to other
calendars and time zone but in different packages... it is not common to
use other calendars than the Gregorian and we don't want to make the most
commonly used abstraction difficult to understand because of that support.
## Non-gregorian calendars in Chronos are completely invisible to
programmers who don't want or need them. In fact, all the non-Gregorian
calendar classes could simply be removed, and the only Chronos code that
would break would be example code in comments (if you can call such
code-in-the-comments "Chronos code.") Where in any of the Chronos examples
you've seen in this discussion can you spot the fact that Chronos even
supports calendars other than the Gregorian? I mention it in passing, but
there's no evidence of it in any of the code examples.
</pre>
</blockquote>
You are right, but I did not say that Chronos had that problem, I just
said what we wanted to avoid, that's all... <br>
<blockquote cite="midmd5:64756D6D79206D657373616765206964" type="cite">
<pre wrap="">## Why not just use Chronos for time zones and for non-Gregorian calendars?
I've already done the hard work--and you'll find the job is a lot harder
than you currently imagine. The opportunity for synergy between Chalten and
Chronos in this area seems very strong to me.
</pre>
</blockquote>
I agree. As I said in other mails:<br>
1) We have to add that functionality to Chalten because it is part of
the thesis that Maxi has to write. It would be of great help to "use"
what you did with Chronos, to merge your ideas with ours, but first we
have to analyze Chronos, understand how it is design and implemented,
etc. So, yeah, I agree with what you say. I'll let you know personally
(I think it does not make sense to use the squeak list for this) what
are the next steps once we decide them <br>
2) I believe, as you say, that we and all the smalltalk community can
benefit from merging Chronos and Chalten, so if I say something that
Chalten does is not to say that Chronos does not, I don't know how
Chronos is implemented, all the functionality it covers, etc.<br>
<blockquote cite="midmd5:64756D6D79206D657373616765206964" type="cite">
<pre wrap=""> </pre>
<blockquote type="cite">
<pre wrap="">It's easy to convert a Chronos YearMonthDay or Timepoint into a count
of days, or to convert a count of days into a YearMonthDay or Timepoint:
YearMonthDay daysSinceEpoch: YearMonthDay today daysSinceEpoch.
</pre>
</blockquote>
<pre wrap=""><!---->Same for Chalten. For example:
( January first, 2006) numberOfDaysFromBaseDate --> Returns "38351
days".
But as you can see it returns a Measure. They also are immutable,
comparable, can be put in Sets, Dictionaries, etc.
I believe that the fact that we return a Measure and not just a numbers
makes "explicit" the meaning of the returned object. It is not just
38351 but "38351 days"
## Chronos:
##
## 1) YearMonthDay today - (YearMonthDay year: 1901 day: 1) =>
38460:00:00:00 (38460 days as a duration object)
## 2) YearMonthDay today civilDurationSince: (YearMonthDay
year: 1901 day: 1)=> P105Y3M19D (also a duration object, representing 105
years, 3 months, 19 days)
## Chronos durational objects are immutable, comparable, can be used in
Sets, Dictionaries, etc.
</pre>
</blockquote>
Defenitly you know more than we know about the time domain. We have not
gone into too much detail on the civil calendars, etc. But I like the
idea of using measure instead of duration because as conceptual
entities, they represent the same. The only difference is that measures
are more generic because they can be use as measure of time, length,
money, etc. So, I like the idea of using measure because when you get
used to it, you don't have to care anymore about all the different
classes that represent, in an abstract way, the same concept, like
Duration, Money, Length, etc. All those concept can be represented as
Measures. But hey, that's my idea and not everybody has to agree with
me...<br>
<blockquote cite="midmd5:64756D6D79206D657373616765206964" type="cite">
<pre wrap="">What's the advantage? Well, there are many, for example:
1) If you see the message #numberOfDaysFromBaseDate we, as programmer,
know that it will return a number or a measure in this case, but what
happens if you just see the object "38351"? You will not be able to know if
they are days, seconds, years or what ever meaning it has. If instead you
see "38351 days", now you know you are dealing with days. But not only we as
programmers will notice that, the whole idea of Aconcagua is that the
computer will handle any arithmetic mistake you can have mixing measure of
different units. Using measures, you will never mix days and years. For
example:
a) If the model returns numbers instead of measures, you could
write:
( January first, 2006) numberOfDaysFromBaseDate + ( January
first, 2006) year yearsFromBaseDate --> That is 38351 + 106 = 40357
There is no way to know from the result that you added days and
years.
b) If the model returns measures:
( January first, 2006) numberOfDaysFromBaseDate + ( January
first, 2006) year yearsFromBaseDate --> It will return "38351 days + 106
years"
As you can see, it does not mix up days and years because they
are not interchangeable. A year can be 365 or 366 days in the Gregorian
calendar.
2) Because we use measures, if you want to know the number of hours from
the base date, you can do:
( January first, 2006) numberOfDaysFromBaseDate convertTo:
TimeUnits hour --> Returns " 920424 hours".
Or seconds:
( January first, 2006) numberOfDaysFromBaseDate convertTo:
TimeUnits hour --> Returns " 3313526400 seconds"
There is no need for a class Duration or special messages to get the
number of seconds from base date, etc.
## I generally agree with Hernan's explanation of the motivation for using
durational objects. But there are times when integer numbers are better.
For one thing, the messages to get the count of days must exist in order to
create the durational values. And whith a Chrohos durational object, there
is no need to convert it from days to hours--the same object encompasses all
units from nanoseconds to weeks.
</pre>
</blockquote>
But I think that if you have a Duration and want its value in seconds
you will have to send it the message #asSeconds or something like
that... Maybe I'm wrong, but if that is the case I prefer to have more
polymorphic objects (measures) and less messages, for me is easier to
remember.<br>
<blockquote cite="midmd5:64756D6D79206D657373616765206964" type="cite">
<pre wrap="">## By the way, if you are intrigued by the Aconcagua domain-specific
language for measures, you should also check out Frink:
<a class="moz-txt-link-freetext"
href="http://futureboy.homeip.net/frinkdocs/">http://futureboy.homeip.net/frinkdocs/</a>
</pre>
</blockquote>
Ok, thanks!. I'll check that out<br>
<blockquote cite="midmd5:64756D6D79206D657373616765206964" type="cite">
<pre wrap=""> </pre>
<blockquote type="cite">
<pre wrap="">So the problem of indexing by a date resolves to the problem of
indexing by an integer. It's also possible to convert a date into a
count of months or years since the calendar epoch, and to convert a
count of months or years since a calendar epoch into a date.
Both YearMonthDay and Timepoint (which inherits from YearMonthDay)
support date and time arithmetic operations:
#addingYears:
#subtractingYears:
#addingMonths:
#subtractingMonths:
#addingDays:
#subtractingDays:
#addingYears:months:days:
#subtractingYears:months:days:
#addingHours:
#subtractingHours:
#addingMinutes:
#subtractingMinutes:
#addingSeconds:
#subtractingSeconds:
#addingSeconds:nanonseconds:
#subtractingSeconds:nanoseconds:
</pre>
</blockquote>
<pre wrap=""><!---->Well, here is an example of how we simplified the protocol of all
PointInTime objects using measures. For the same porpouse that Alan shows in
Chronos, we have only two messages: #next: and #previous: (we don't use add
and subtract for semantinc issues, but that another problem it does not make
sense to talk about now). For example:
GregorianDate today next: 10 * TimeUnits day -> Will return "
April 30, 2006" if today is " April 20, 2006"
## YearMonthDay today + (CalendarDayDuration * 10)
</pre>
</blockquote>
Cool, I'm learning about Chronos. From the functionality point of view,
they are equal, but for me is difficult to understand at first sight
what CalendarDayDuration mean. I understand now, but I tried "10 *
CalendarDayDuration" and it did not work... so they do not conform to
the commutative property that one expect from arithmetic operations...
We face those problems when doing Aconcagua, that's why we create a new
abstraction called ArithmeticObject (that if we could, Number should
subclass it). <br>
Anyway, as I said before, I believe that Measure is a more generic and
abstract way of representing time durations and the good thing about
measures is that all measures are polymorphic!. The same is not true
for Duration, Money (if it existed), Length (if it is created) etc. <br>
<br>
[I erased some of the examples because they are equivalent to the one
above]<br>
<blockquote cite="midmd5:64756D6D79206D657373616765206964" type="cite">
<pre wrap=""> GregorianDay today next: 3 * TimeUnits day --> Will return "Sunday"
if today is "Thursday"
## YearMonthDay today + (CalendarDayDuration * 3)
## Timepoint today + (CalendarDayDuration * 3)
## Timeperiod today + (CalendarDayDuration * 3)
</pre>
</blockquote>
But this examples you provide do not have the same result as in Chalten.<br>
<pre wrap="">YearMonthDay today + (CalendarDayDuration * 3) --> Returns an instance of YearMonthDay instead of an object that represent a day in a week, like in Chalten that returns "Thursday", and instance of GregorianDay (it is not the same as GregorianDate).
The other two examples do not return a day also. (By the way, what is the difference between YearMonthDay and Timepoint? I see you use it in a different way as we do...)
</pre>
<br>
<blockquote cite="midmd5:64756D6D79206D657373616765206964" type="cite">
<pre wrap=""> GregorianMonth current previous: 2 * TimeUnits month --> Will return "
February" if the current month is " April"
etc.
## Timeperiod currentMonth - (MonthDuration * 2)
</pre>
</blockquote>
This example also is not the same as what I showed with Chalten. My
example return a Month, in this case "February" that is instance of
GregorianMonth...<br>
<br>
[snip]<br>
<blockquote cite="midmd5:64756D6D79206D657373616765206964" type="cite">
<pre wrap="">We do not implemented the #+, #-, etc. messages in PointInTime objects
because those message do not keep the same semantic as the arithmetic
message. For example. if you do "1 + 2" you get "3". That is, you are adding
number, you get a number. But for dates is not the same... For example
"GregorianDate today + 10 days" would not return a measure of days but a new
date, so it does not match the semantics of the arithmetic +.
Of course this is a decision we made and not everybody could like or agree
with that... but we believe it makes more clear the model's language.
## Chronos implements the #+ and #- messages for two reasons:
##
## 1) It's required by the ANSI Smalltalk Standard.
## 2) In mathematics, the semantics of + and - depend upon the algebra one
formally defines. There is no general requirement that both operands of the
+ or - opertor be of the same type. "Mixed mode" arithmetic expressions are
common, useful and formally well defined.
</pre>
</blockquote>
That's find. When we did Chalten we decided not to follow the ANSI
standard because we do not agree with some abstractions they propose.<br>
About the mathematic semantics, as you say, you can define what ever
you want for the + and -, we just believe that doing so you loose
polymorphisms and we did not what to do that. I mean, you can not use
the + with number and duration polymorphically. Instead in Aconcagua,
the +, - , etc. can be used with number and measures polymorphically.<br>
<blockquote cite="midmd5:64756D6D79206D657373616765206964" type="cite">
<pre wrap=""> </pre>
<blockquote type="cite">
<pre wrap="">The "duration" instance variable might have the value
"ScientificDuration
hours: 3.5", or it might have the value "CalendarDuration months: 3."
The "baseTimepoint" instance variable could hold either a Timepoint, a
YearMonthDay--or even a Timeperiod (interval of time.) For example,
"Timeperiod currentMonth + (CalendarDuration days: 5)" (if executed
during the month of April, 2006) evaluates to "2006-04-06/P1M" (the
one-month interval starting 6 April 2006.)
</pre>
</blockquote>
<pre wrap=""><!---->Chalten also have an abstraction for this, it named Timespan. It represents
segment of the time line. For example:
GregorianTimespan from: GregorianDate today duration: 20 * TimeUnits day
--> Returns "20 days from April 20, 2006"
## Timeperiod from: YearMonthDay today duration: CalendarDayDuration * 20 =>
2006-04-20/P20D (ISO 8601 notation for "the 20-day period starting with
2006-04-20")
</pre>
</blockquote>
Definitively you have more idea about time standards that we do....<br>
<blockquote cite="midmd5:64756D6D79206D657373616765206964" type="cite">
<pre wrap=""> GregorianTimespan from: GregorianYear current duration: 10 * TimeUnits
year --> Returns " 10 years from Year 2006"
## Chronos doesn't have a "Year" class -- and that's one of the obvious
opportunities for synergy between Chalten and Chronos</pre>
</blockquote>
We also have the abstraction GregorianDay (ie. Monday) ,
GregorianDayOfMonth (ie. January 1) and GregorianMonthOfYear (January
2006)<br>
Just to understand a little bit more about Chronos, does it have those
abstractions?<br>
<br>
## It's also serendipitous that both Timeperiod and GregorianTimespan
use<br>
<blockquote cite="midmd5:64756D6D79206D657373616765206964" type="cite">
<pre wrap="">#from:duration: as instance creation methods--must be the right method name.
</pre>
</blockquote>
jaja. I agree....<br>
<br>
<blockquote cite="midmd5:64756D6D79206D657373616765206964" type="cite">
<pre wrap=""> GregorianTimespan from: GregorianMonth current duration: 2 * TimeUnits
month --> Returns " 2 months from April"
## Yet another opportunity for synergy...
</pre>
</blockquote>
Ok, I made a question before about this... It is answered now.<br>
<blockquote cite="midmd5:64756D6D79206D657373616765206964" type="cite">
<pre wrap=""> GregorianTimespan from: GregorianDay today duration: 2 * TimeUnits day
--> Returns " 2 days from Thursday"
GregorianTimespan from: GregorianDayOfMonth today duration: 25 *
TimeUnits day --> Returns " 25 days from April 20"
## Timeperiod from: DayOfMonth today duration: CalendarDayDuration * 25
## Timeperiod from: DayOfYear today duration: CalendarDayDuration * 25
## Timeperiod from: WeekOfMonthDayOfWeek today duration: CalendarDayDuration
* 25
## Timeperiod from: GregorianEaster canonical duration: CalendarDayDuration
* 25
GregorianTimespan from: GregorianMonthOfYear current duration: 12 *
TimeUnits month --> Returns " 12 months from April of Year 2006"
## Yet another opportunity for synergy...
</pre>
</blockquote>
Ok, cool.<br>
<blockquote cite="midmd5:64756D6D79206D657373616765206964" type="cite">
<pre wrap=""> GregorianTimespan from: TimeOfDay now duration: 12 * TimeUnits hour
--> Returns " 12 hours from 18:53:33" (I wrote the mail at 18:53:33)
## Uh, oh: Both Chronos and Chalten use the class name TimeOfDay. This won't
matter in VW, but Squeak really needs namespaces or class boxes...
## Timeperiod from: TimeOfDay now duration: 12 * HourDuration
</pre>
</blockquote>
It is good to see we use the same names...<br>
<blockquote cite="midmd5:64756D6D79206D657373616765206964" type="cite">
<pre wrap=""> GregorianTimespan from: GregorianDateTime now duration: 12 * TimeUnits
hour --> Returns " 12 hours from April 20, 2006 18:54:14"
Look how easy is to use the same abstraction, GregorianTimespan, to any type
of PointInTime. I think we could achieve that because we are using measures
and all point in times are polymorphic. (By the way, we use
GregorianTimespan because Chronology already defines Timespan) We also have
time intervals, that are instances of the class "ArihtmeticObjectInterval"
(I think not a good name). We could not use the Interval class for many
reason. Anyway, ArihtmeticObjectInterval is an interval of any type of
Magnitude, for example Measures, Numbers and of course PointInTimes. For
example:
GregorianDate today to: December first, 2006 --> Returns an interval
from today to December fist 2006 by 1 day
GregorianDate today to: December first, 2006 by: 10 * TimeUnits day
--> Returns an interval from today to December fist 2006 with steps of
10 days
## I considered implementing a TemporalInterval where the step value would
be specified. In the end, I decided to simply make it easy to enumerate
between the endpoints of a Timeperiod using any ScientificDuration or
CivilDuration as the step value, and let applications manage the step value
as they care to. Implementing a TemporalInterval on top of Timeperiod would
be easy to do. Perhaps this is another opportunity for synergy between
Chronos and Chalten.
GregorianMonth current to: December by: 2 * TimeUnits month --> Now,
and interval of months.... the same for other time points...
## Yet another opportunity for synergy...
</pre>
</blockquote>
Cool.... we have a lot of thing to talk about... Maxi is taken notes on
this so we can take advantage of what we have talk so far<br>
<blockquote cite="midmd5:64756D6D79206D657373616765206964" type="cite">
<pre wrap="">Because these objects are intervals, they are polymorphic with Collection:
(GregorianDate today to: December first, 2006) select: [ :aDate |
aDate isMonday ] --> Returns all Mondays from today to December first
(GregorianYear current to: (GregorianYear number: 3000) ) select: [
:aYear | aYear isLeap ] --> Returns all leap year up to year 3000
(January first, 2006 to: GregorianDate today) collect: [ :aDate |
aDate distanceTo: GregorianDate today ] --> Returns an array with
measures from 109 days to 0 days
</pre>
</blockquote>
<blockquote cite="midmd5:64756D6D79206D657373616765206964" type="cite">
<blockquote type="cite">
<pre wrap="">Does that answer your question about indexing?
Jeff: "What should happen if you start at January 28'th and advance by a
month and then go back by a month?
Jan28 --> Feb28 --> (Jan 28 or Jan 31?) Can we agree on some
conventions? "
(YearMonthDay year: 2006 month: 1 day: 28) + 1 months => 2006-02-28
(YearMonthDay year: 2006 month: 1 day: 31) + 1 months => 2006-02-28
(YearMonthDay year: 2006 month: 1 day: 28) + 1 months - 1 months =>
2006-01-28
(YearMonthDay year: 2006 month: 1 day: 31) + 1 months - 1 months =>
2006-01-28
(Note: "1 months" works in VW and Dolphin, but not in Squeak, where
"(CalendarDuration months: 1)" must be used instead--or you could add a
#months and #years method to Integer yourself.)
</pre>
</blockquote>
<pre wrap=""><!---->In Chalten we have a set of units that are interchangeable for years,
moths, decades, etc. and another for days, hours, seconds, weeks, etc.
Notice that time units are not the same as time points (there is an
object for years, ie. GregorianYear, and there is a unit to measure
years, ie. TimeUnit year)
That means that measures expressed in days can not be converted to
months or years and vicersa. (Is 30 days a month? or 31 days? etc.)
Because of the irregularity of the Gregorian calendar we decided not to
allow movements of point in times with measure of units of less
granularity that the point in time granularity. For example:
GregorianDate today next: 1 * TimeUnits second --> Is not allowed
But we added for convenience that possibility of doing:
(January thirtyfirst, 2006 next: 1 * TimeUnits month) --> Returns
February 28, 2006
(January thirtyfirst, 2006 next: 1 * TimeUnits month) previous: 1 *
TimeUnits month --> Returns January 28, 2006
I don't like this behavior but we added because we people are used to it.
## YearMonthDay today addingSeconds: 1000 => 2006-04-20T00:16:40
## This case is no different than "3 / 4" or "100 factorial."
Autoconvervion/autopromotion is the Smalltalk way.
</pre>
</blockquote>
Ok, your solution is different.<br>
Well, Alan, this helped us to understand more about Chronos... as you
say we should find the way to merge the models. I'll let you know what
our ideas are as soon as we decide them. Let's keep in touch.<br>
<br>
Bye,<br>
Hernan.<br>
<blockquote cite="midmd5:64756D6D79206D657373616765206964" type="cite">
<pre wrap="">Well, the mail became longer that I expected. I hope it helps you to
understand Chalten and also compare it with other solutions.
Bye,
Hernan
</pre>
<blockquote type="cite">
<pre wrap="">Chronos implements date arithmetic to satisfy the typical business use
</pre>
</blockquote>
<pre wrap=""><!---->case.
</pre>
<blockquote type="cite">
<pre wrap="">If you want "scientific" behavior, use a ScientificDuration. If you want a
"month" to always be 30 days, use a "monthDuration" value defined as
"CalendarDuration days: 30."
But these questions just scratch the surface. There's a lot more than can
and should be asked.
--Alan
-----Original Message-----
From: <a class="moz-txt-link-abbreviated"
href="mailto:squeak-dev-bounces@lists.squeakfoundation.org">squeak-dev-bounces@lists.squeakfoundation.org</a>
[<a class="moz-txt-link-freetext"
href="mailto:squeak-dev-bounces@lists.squeakfoundation.org">mailto:squeak-dev-bounces@lists.squeakfoundation.org</a>] On Behalf Of Jeffrey
J. Hallman
Sent: Wednesday, April 19, 2006 9:10 AM
To: <a class="moz-txt-link-abbreviated"
href="mailto:squeak-dev@lists.squeakfoundation.org">squeak-dev@lists.squeakfoundation.org</a>
Subject: Re: The Timing of Time
I'm enjoying the discussion about calendars and times, but I'd like to
direct some attention to the idea of a TimeIndex. I came at this from
another direction, thinking of a TimeSeries as data indexed by time, which
leads to the idea of a TimeIndex.
In my current implementation, a TimeIndex has two instance variables: a
</pre>
</blockquote>
<pre wrap=""><!---->freq
</pre>
<blockquote type="cite">
<pre wrap="">symbol (such as #weeklyMonday, #monthly, #hourly, etc.) and an integer
period, which represents the number of periods elapsed since the base
</pre>
</blockquote>
<pre wrap=""><!---->period
</pre>
<blockquote type="cite">
<pre wrap="">for that freq. TimeIndex understands '+' and '-', so if 'z'
is the weeklyMonday time index for April 17 2006, then (z - 4) asYmd yields
20060320, and so on.
My TimeSeries class is a subclass of Matrix with an additional instance
variable called 'start' which is a TimeIndex, and has accessors like
TimeSeries>>atTimeIndex:
TimeSeries>>atTimeIndex:put:
TimeSeries>>atTimeIndex:column:
TimeSeries>>atTimeIndex:column:put:
I've found this scheme works pretty well, and will probably generalize it a
bit more by making TimeIndex an abstract class with subclasses for
</pre>
</blockquote>
<pre wrap=""><!---->different
</pre>
<blockquote type="cite">
<pre wrap="">kinds of sequences.
I think a package that wants to handle date and time issues should have
something like a TimeIndex in it that allows sequences of various
frequencies to be defined. At the same time, the implementation should be
simple enough to be easily understood, and indexing into a TimeSeries
</pre>
</blockquote>
<pre wrap=""><!---->should
</pre>
<blockquote type="cite">
<pre wrap="">be very fast. If indexing isn't fast, we'll end up with ugly code in every
TimeSeries method that that converts TimeIndex'es to row numbers and back.
Trust me, you really don't want that.
So how do these various packages handle indexing data by time?
A second issue is how to handle date arithmetic. Some durations are based
on linear time (e.g., weeks, seconds, hours, etc.) and others are based on
the calendar (months, years, etc.). The distinction between these two
</pre>
</blockquote>
<pre wrap=""><!---->leads
</pre>
<blockquote type="cite">
<pre wrap="">to questions like: What should happen if you start at January 28'th and
advance by a month and then go back by a month?
Jan28 --> Feb28 --> (Jan 28 or Jan 31?) Can we agree on some
conventions?
Jeff Hallman
</pre>
</blockquote>
<pre wrap=""><!---->
--
______________________________
Lic. Hernán A. Wilkinson
Gerente de Desarrollo y Tecnología
Mercap S.R.L.
Tacuari 202 - 7mo Piso - Tel: 54-11-4878-1118
Buenos Aires - Argentina
<a class="moz-txt-link-freetext" href="http://www.mercapsoftware.com">http://www.mercapsoftware.com</a>
---------------------------------------------------------------------
Este mensaje es confidencial. Puede contener informacion amparada
por el secreto profesional. Si usted ha recibido este e-mail por error,
por favor comuniquenoslo inmediatamente via e-mail y tenga la
amabilidad de eliminarlo de su sistema; no debera copiar el mensaje
ni divulgar su contenido a ninguna persona. Muchas gracias.
This message is confidential. It may also contain information that is
privileged or otherwise legally exempt from disclosure. If you have
received it by mistake please let us know by e-mail immediately and
delete it from your system; you should also not copy the message nor
disclose its contents to anyone. Thanks.
---------------------------------------------------------------------
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
______________________________
Lic. Hernán A. Wilkinson
Gerente de Desarrollo y Tecnología
Mercap S.R.L.
Tacuari 202 - 7mo Piso - Tel: 54-11-4878-1118
Buenos Aires - Argentina
<a class="moz-txt-link-freetext" href="http://www.mercapsoftware.com">http://www.mercapsoftware.com</a>
---------------------------------------------------------------------
Este mensaje es confidencial. Puede contener informacion amparada
por el secreto profesional. Si usted ha recibido este e-mail por error,
por favor comuniquenoslo inmediatamente via e-mail y tenga la
amabilidad de eliminarlo de su sistema; no debera copiar el mensaje
ni divulgar su contenido a ninguna persona. Muchas gracias.
This message is confidential. It may also contain information that is
privileged or otherwise legally exempt from disclosure. If you have
received it by mistake please let us know by e-mail immediately and
delete it from your system; you should also not copy the message nor
disclose its contents to anyone. Thanks.
--------------------------------------------------------------------- </pre>
<pre wrap="">
<hr size="4" width="90%">
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
______________________________
Lic. Hernán A. Wilkinson
Gerente de Desarrollo y Tecnología
Mercap S.R.L.
Tacuari 202 - 7mo Piso - Tel: 54-11-4878-1118
Buenos Aires - Argentina
<a class="moz-txt-link-freetext" href="http://www.mercapsoftware.com">http://www.mercapsoftware.com</a>
---------------------------------------------------------------------
Este mensaje es confidencial. Puede contener informacion amparada
por el secreto profesional. Si usted ha recibido este e-mail por error,
por favor comuniquenoslo inmediatamente via e-mail y tenga la
amabilidad de eliminarlo de su sistema; no debera copiar el mensaje
ni divulgar su contenido a ninguna persona. Muchas gracias.
This message is confidential. It may also contain information that is
privileged or otherwise legally exempt from disclosure. If you have
received it by mistake please let us know by e-mail immediately and
delete it from your system; you should also not copy the message nor
disclose its contents to anyone. Thanks.
--------------------------------------------------------------------- </pre>
</body>
</html>