Re: milli/micro seconds
I want the overflow behavior for DT and DT::Duration objects that support scientific time math. The second is the official unit of time in the SI system. So I'd like to have a a class that supports 10^9 - 10^-9 seconds. Possible names are: DateTime::Wrapper::SI DateTime::Wrapper::Units DateTime::Wrapper::SIUnits Units that would overflow to larger intervals: gigasecond megasecond kilosecond hectosecond decasecond Units that would translate to nanoseconds with overflow to larger intervals: decisecond centisecond millisecond microsecond nanosecond Of course there are many more units that would require Math::BigInt. :) Cheers, -J --
Re: milli/micro seconds
Hi Rick, Cool idea .. and I'll add DateTime::Wrapper::AllowThingsToOverflow (or something shorter) that allows you to construct with overflowing parameters (like 75 seconds, 124 minutes, 34 hours, 98 days and 16 months) Are you still going to do this? I already want to subclass it for something. :) -J --
Re: milli/micro seconds
Dave already said that he was open to adding a flag to control the overflow behavior if anyone could provide a valid reason for needing it. It sounds like you have a good reason, so post it and see if he will add the flag. -ben On Mon, Jun 16, 2003 at 08:43:50AM -1000, Joshua Hoblitt wrote: Hi Rick, Cool idea .. and I'll add DateTime::Wrapper::AllowThingsToOverflow (or something shorter) that allows you to construct with overflowing parameters (like 75 seconds, 124 minutes, 34 hours, 98 days and 16 months) Are you still going to do this? I already want to subclass it for something. :) -J --
Re: milli/micro seconds
On Wed, 11 Jun 2003, Dave Rolsky wrote: On Tue, 10 Jun 2003, Joshua Hoblitt wrote: I've started on milliseconds and microseconds support (DT::Duration to start with). I hope nobody else has already done this. Um, don't we already have this with nanoseconds? What are you thinking of adding? Adding millisecond and microsecond constructor parameters to DT and DT::Duration that just convert to be to stored as nanoseconds. Probably add delta_millisecond and delta_microsecond methods to DT::Duration. This is listed in the TODO. -J --
Re: milli/micro seconds
At 9:29 AM -1000 11/6/03, Joshua Hoblitt wrote: I'm willing to concede that DT::Duration can be left alone but I really think that millisecond and microsecond support would be useful for DT. In fact I think it would be consistent with the rest of the API as you don't have to specify a year as 365 days either. While I know that a millisecond needs to be multiplied by 10**6 to convert it nanoseconds I don't think that qualifies as common knowledge. DISCLAIMER The following is tacked on as a reply to Joshua's post, but that it just to give it context. This in no way is a personal attack on him or anyone else who has talked about sub-second accessors and constructors, but rather on the whole idea in general. /DISCLAIMER Datetimers, I can understand why we look like we need all this stuff for milli-, micro- and nano-seconds, but it is exactly what I was scared of when we were talking about sub-second support. Nano-, Milli- and Micro- seconds are not different things like hours an minutes are, they're just fractional seconds. We really should have just left it as floating seconds, or as fractional seconds rather than settling on some arbitrary precision like nanoseconds. If we allow a constructor for nano-, micro- and milli- then maybe we should allow one for decaminutes? The same with accessors. They're just descriptions of the same thing: fractions. A millisecond is 1/1000 seconds, a decaminute is 10/1 minutes. You can represent time with accessors like: -hour:-minute:-second, but accessors like micro- and milli- are ambiguous. They look like the other accessors so can you just 'whack them on'? $dt-hour . ':' . $ct-minute . ':' . $st-second . '.' . $dt-millisecond . $dt-microsecond . $dt-nanosecond I doubt it. You'll have to pick your precision and only use that. We really should have just left it as -second and -fractional_second and probably -floating_second($precision) (returning floating, not fractional seconds). We especially don't need them in the constructor. It's confusing now: $dt = DateTime-new(%date, second=12, nanosecond=345) Is that 12.345 seconds? Nup. It's 12.00345 (I think). $dt = DateTime-new(%date, second=12, fractional_second=345) Is that 12.345 seconds? Nup. It's 357 seconds! Imagine extra constructors, it feels good at first: $dt = DateTime-new( year=2003, month=6, day=12, hour=7, minute=22, second=12, millisecond=345, microsecond=678, nanosecond=901 ); However, the accessors don't 'behave' themselves: $dt-year== 2003 .. yup $dt-month == 6.. yup $dt-day == 12 .. yup $dt-hour== 7.. yup $dt-minute == 22 .. yup $dt-second == 12 .. yup $dt-millisecond == 347 .. oops $dt-microsecond == 345678 .. hang on, where did all that come from, we constructed it with just '678' $dt-nanosecond == 345678901 .. same here, it used to be just '901' Of course you could have extra accessors for -just_nanoseconods (returns 901), -just_microseconds and -just_milliseconds, but it's all a little silly. Can't we can the nanosecond and just talk about seconds (and fractional seconds)? Cheers! Rick -- There are 10 kinds of people: those that understand binary, and those that don't. The day Microsoft makes something that doesn't suck is the day they start selling vacuum cleaners Write a wise proverb and your name will live forever. -- Anonymous
Re: milli/micro seconds
At 4:36 PM -0500 11/6/03, Dave Rolsky wrote: No, if anything, we'll can the fractional_second constructor parameter. Nanoseconds are here to stay, because I don't want to add bigfloat to the mix, and I want us to be accurate. Dave, can you explain to me again why we need nanosecond (an arbitraty fraction) rather than just using fractional seconds? (not floating, fractional) What we're talking about *is* fractional seconds, why not just call it that? There's no imprecision that doesn't already exist in your computer. If your computer can only handle floats down to 6 decimal places, then you're screwed with any other math anyway! Even if it handles it way down to 100 places, as soon as you ask for 'half the googliseconds' you loose precision. Cheers! Rick -- There are 10 kinds of people: those that understand binary, and those that don't. The day Microsoft makes something that doesn't suck is the day they start selling vacuum cleaners Write a wise proverb and your name will live forever. -- Anonymous
Re: milli/micro seconds
On Thu, 12 Jun 2003, Rick Measham wrote: At 4:36 PM -0500 11/6/03, Dave Rolsky wrote: No, if anything, we'll can the fractional_second constructor parameter. Nanoseconds are here to stay, because I don't want to add bigfloat to the mix, and I want us to be accurate. Dave, can you explain to me again why we need nanosecond (an arbitraty fraction) rather than just using fractional seconds? (not floating, fractional) What we're talking about *is* fractional seconds, why not just call it that? There's no imprecision that doesn't already exist in your computer. If your computer can only handle floats down to 6 decimal places, then you're screwed with any other math anyway! Even if it handles it way down to 100 places, as soon as you ask for 'half the googliseconds' you loose precision. Now you're confusing me! Fractional by itself doesn't mean anything, does it? You can't just the numerator without the denominator. In our case, the denominator is 1,000,000,000 and the numerator is the the value of the nanosecond parameter. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: milli/micro seconds
On Wed, 11 Jun 2003, Tim Bunce wrote: On Wed, Jun 11, 2003 at 09:29:31AM -1000, Joshua Hoblitt wrote: While I know that a millisecond needs to be multiplied by 10**6 to convert it nanoseconds I don't think that qualifies as common knowledge. Sounds like a documentation patch is needed :) It wouldn't hurt but I still think this would a convenient feature. The amount of code is minimal. Although I suppose it could be achieved with a wrapper class. -J --
Re: milli/micro seconds
Ok - this thread has certainly caused a lot of controversy. To comment on Rick's comments - I think that Dave made the correct decision to have fixed precision subsecond resolution. I in no way so attempting to insinuate this wasn't the right thing to done. I will _NOT_ submit a patch to add more constructor parameters. Instead... Proposal: A new 2nd tier namespace for wrapper classes. DateTime::Wrap or DateTime::Wrapper DateTime::Wrapper::SubSecond will accept parameters for resolutions from 10 to 10^9 subseconds. With corresponding methods returning these units. Comments? -J --
Re: milli/micro seconds
At 12:19 PM -1000 11/6/03, Joshua Hoblitt wrote: Proposal: A new 2nd tier namespace for wrapper classes. DateTime::Wrap or DateTime::Wrapper DateTime::Wrapper::SubSecond will accept parameters for resolutions from 10 to 10^9 subseconds. With corresponding methods returning these units. Cool idea .. and I'll add DateTime::Wrapper::AllowThingsToOverflow (or something shorter) that allows you to construct with overflowing parameters (like 75 seconds, 124 minutes, 34 hours, 98 days and 16 months) Cheers! Rick -- There are 10 kinds of people: those that understand binary, and those that don't. The day Microsoft makes something that doesn't suck is the day they start selling vacuum cleaners Write a wise proverb and your name will live forever. -- Anonymous
Re: milli/micro seconds
On Wed, 11 Jun 2003, Joshua Hoblitt wrote:
DateTime::Wrapper::SubSecond will accept parameters for resolutions from
10 to 10^9 subseconds. With corresponding methods returning these
units.
This seems like overkill for something which will basically do:
my $nano = $p{micro} * 1000;
Which is why I wanted to put it in the core. This seems to be a
circular argument. :)
The problem with making it a constructor option is that if a user passes
nanosecond _and_ micro/milli parameters, it's confusing. It's bad enough
that fractional_second and nanosecond are overlapping, and in a really
weird way now that I look more closely!
Ugh, the fractional_second parameter must go. The docs for it are all
wrong, and what it's actually doing is _really_ odd.
Anyway, I _really_ don't like having mututally exclusive, but overlapping,
constructor parameters. This makes for hard-to-read docs. Ideally, each
parameter is unique, and falls into the category of required, has
default, or optional.
I said a _wrapper_ was overkill because you could just as easily write
something like:
micro_as_nano { $_[0] * 1000 }
milli_as_nano { $_[0] * 100 }
and then do:
DateTime-new( ..., nanosecond = milli_as_nano(500) )
Isn't that simpler? Is there any need to wrap all the DateTime
constructors? No, obviously not. It's two one-liner exported functions
that are mere syntactic sugar!
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: milli/micro seconds
Ugh, the fractional_second parameter must go. The docs for it are all
wrong, and what it's actually doing is _really_ odd.
Sounds reasonable.
Anyway, I _really_ don't like having mututally exclusive, but overlapping,
constructor parameters. This makes for hard-to-read docs. Ideally, each
parameter is unique, and falls into the category of required, has
default, or optional.
I said a _wrapper_ was overkill because you could just as easily write
something like:
micro_as_nano { $_[0] * 1000 }
milli_as_nano { $_[0] * 100 }
and then do:
DateTime-new( ..., nanosecond = milli_as_nano(500) )
Isn't that simpler? Is there any need to wrap all the DateTime
constructors? No, obviously not. It's two one-liner exported functions
that are mere syntactic sugar!
Ya - too bad there aren't isn't any preprocessor other then source filters. I don't
like writing structural code over and over again.
-J
--
