David Vincent-Jones wrote:
> I have a series of time-stamps taken from a pump station where I need
to
> evaluate the operating intervals in minutes.
>
> . . .
>
> I have been doing this the hard way with lots of 'intervention' but
> probably somebody has already solved this elegantly and ideas would
be
> appreciated.
>
At the risk of boring (annoying?) those who have read my ideas
on this topic here before, I would like to point out briefly how J
could handle such matters very elegantly indeed.
Times and dates are very commonly used in calculations and
are not able to be simplified in the way that weights and
measures and money have been persuaded to be wholly
decimal.
Therefore it is feasible to express times and dates in much
the same way that 1j2 and 3r4 and the like are expressed.
A date would have at least a y and an m embedded as in
2008y12m01 and this could be extended to greater precision
as in 2008y12m1d1h46m19 for example.
The difference between two dates would be a time interval
expressible for example as 2h34m58.56 with the possibility
of including days and possibly weeks in front of such
values.
There would need to be rules as to how the different
arithmetic functions would handle date or time arguments;
for example a time could be added to or subtracted from
a date but not multiplied; a time interval could be multiplied
or divided by an ordinary number, but not added or subtracted.
There would need to be functions analogous to j. to construct
times or dates from ordinary numbers, others to extract
ordinary numbers from dates or times and to format them
for printing.
This is only a brief description, and clearly it would take
a good deal of work to fully design and implement such
a facility. I would argue, however, that the simplicity of
representation and conversion of such important values
as dates and times, and the ability to put them into
numeric arrays without boxing, would make the effort
well worthwhile. It would also allow such matters
as leap years and leap seconds to be handled by the J
interpreter, a further simplification and one which would
remove the source of inaccuracies.
Neville Holmes, P.O. Box 2412, Bakery Hill 3354, Victoria
Stay connected to the people that matter most with a smarter inbox. Take
a look http://au.docs.yahoo.com/mail/smarterinbox
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm