yyyymmdd=: 100 #. 2005 1 1 +"1 ] 1e5 3 [EMAIL PROTECTED] 10 12 30
hhmmss=: 100 #. 1e5 3 [EMAIL PROTECTED] 24 60 60
a=: yyyymmdd ,. hhmmss NB. two integers per date/time
4{.a
20100429 14454
20071003 184431
20130306 63535
20070910 204122
b=: yyyymmdd + hhmmss % 1e6 NB. one float per date/time
4{.b
2.01004e7 2.0071e7 2.01303e7 2.00709e7
":!.18 ]4 {. b
20100429.014454 20071003.184431002 20130306.063535001 20070910.204121999
7!:5 ;:'a b' NB. same amount of space
1.04858e6 1.04858e6
ts=: 6!:2 , 7!:[EMAIL PROTECTED]
ts '~. a'
0.0321281 2.09792e6
ts '~. b'
0.0450853 2.09779e6
Integer nub is slightly faster and more robust.
----- Original Message -----
From: Roger Hui <[EMAIL PROTECTED]>
Date: Friday, May 2, 2008 11:16
Subject: Re: [Jprogramming] RE: [Jgeneral] NUB Problem
To: Programming forum <[email protected]>
> Unless I'm going to do date arithmetic (e.g. 10 days from 20080526),
> I like yymmdd because I can tell at a glance what the thing is.
> For date and time I would use 2 integers, yyyymmdd hhmmss,
> which is the same amount of space as a single floating point number
> without the tolerance problem.
>
>
>
> ----- Original Message -----
> From: Tracy Harms <[EMAIL PROTECTED]>
> Date: Friday, May 2, 2008 10:53
> Subject: [Jprogramming] RE: [Jgeneral] NUB Problem
> To: [email protected]
>
> > Raul wrote:
> >
> > > ... those floating point numbers are times
> > > packed as YYYYMMDD.hhmmss
> > > ...
> > > Basically: convert to a more compact format
> > > ...
> > > An even better approach might be to capture
> > > that original time stamp as character data,
> > > rather than using #:
> >
> >
> > While I recognize that a textual representation may be
> > best, there may be several advantages to recording
> > time numerically. It seems to me that when such an
> > approach is taken Julian dating should be used. I
> > think 32-bit representation is adequate to support the
> > fractions-of-a-day required here, but even if it is
> > not the origin can be adjusted (by approx. 2.45e6
> > days) to provide plenty of fractional accuracy.
> >
> > So, my recommendation: Continue to handle temporal
> > values with floating point, but change to use Julian
> > dating.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
