[date_time] Suggestion for duration division operator

Time durations can be divided by an integer to produce a duration (e.g. hours(1)/60 == minutes(1);), but can't be divided by another duration to produce an integer (e.g. hours(1)/minutes(1) == 60;). Could this be added to time_duration.hpp: int operator/(const duration_type& d) const { return (ticks_ / d.ticks_); } or maybe better, this: double operator/(const duration_type& d) const { return (static_cast<double>(ticks_) / d.ticks_); } The same thing can already be accomplished already with duration1.ticks()/duration2.ticks(), but duration1/duration2 seems more natural and fits well with the rest of the date_time operators. Beth

Beth Jacobson wrote:
Time durations can be divided by an integer to produce a duration (e.g. hours(1)/60 == minutes(1);), but can't be divided by another duration to produce an integer (e.g. hours(1)/minutes(1) == 60;).
Could this be added to time_duration.hpp:
int operator/(const duration_type& d) const { return (ticks_ / d.ticks_); }
Reasonable -- of course it will have the usual integer division issues.
or maybe better, this:
double operator/(const duration_type& d) const { return (static_cast<double>(ticks_) / d.ticks_); }
The same thing can already be accomplished already with duration1.ticks()/duration2.ticks(), but duration1/duration2 seems more natural and fits well with the rest of the date_time operators.
Well, I've managed to avoid injecting any "fuzzy floating point logic" into date_time up till now. I guess I'd like to hear a compelling use case from you or others as to why this is really needed. Partially because if I add it to date_time I might have to add it to my standard proposal and defend it. In the current version of the proposal I've tried to hone down the interface footprint as much as possible without leaving out anything vital. Be aware the one of my arguments will likely be that it's trivial enough for you to write: //beths_time_extensions.h namespace boost { namespace posix_time { double operator/(const time_duration& lhs, const time_duration& rhs) const { return (static_cast<double>(lhs.ticks()) / rhs.ticks()); } }} I have a whole directory full of 'jeffs cool date time extenstions' that will never make it into the library because they're just not vitally important to the core problem. Finally, if you write it you get to handle the support email if the double math or comparisons fail you -- personally I don't trust it ;-) Jeff

Jeff Garland wrote:
Beth Jacobson wrote:
Time durations can be divided by an integer to produce a duration (e.g. hours(1)/60 == minutes(1);), but can't be divided by another duration to produce an integer (e.g. hours(1)/minutes(1) == 60;).
Could this be added to time_duration.hpp:
int operator/(const duration_type& d) const { return (ticks_ / d.ticks_); }
Reasonable -- of course it will have the usual integer division issues.
or maybe better, this:
double operator/(const duration_type& d) const { return (static_cast<double>(ticks_) / d.ticks_); }
The same thing can already be accomplished already with duration1.ticks()/duration2.ticks(), but duration1/duration2 seems more natural and fits well with the rest of the date_time operators.
Well, I've managed to avoid injecting any "fuzzy floating point logic" into date_time up till now. I guess I'd like to hear a compelling use case from you or others as to why this is really needed.
Given your arguments, I'm afraid I can't come up with one. In the field I'm working in (crop modeling), dividing durations is a vital function, but I can't think of a compelling reason for it to be a member function. Thanks for your time and attention on this, and thank you for the date_time library. It fits the modeling paradigm beautifully, and it's a pleasure to use. Regards, Beth

On Sat, 06 May 2006 15:34:27 -0400, Beth Jacobson wrote
Jeff Garland wrote:
Given your arguments, I'm afraid I can't come up with one. In the field I'm working in (crop modeling), dividing durations is a vital function, but I can't think of a compelling reason for it to be a member function.
Thanks for your time and attention on this, and thank you for the date_time library. It fits the modeling paradigm beautifully, and it's a pleasure to use.
Thanks Beth -- that's always good to hear :-) Jeff

On 5/5/06, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
I have a whole directory full of 'jeffs cool date time extenstions' that will never make it into the library because they're just not vitally important to the core problem
Perhaps these would be worthy candidates for libs/date_time/example? -- Caleb Epstein caleb dot epstein at gmail dot com

Caleb Epstein wrote:
On 5/5/06, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
I have a whole directory full of 'jeffs cool date time extenstions' that will never make it into the library because they're just not vitally important to the core problem
Perhaps these would be worthy candidates for libs/date_time/example?
Oh sure, maybe someday. I've got my hands full this year, though, so don't hold your breath ;-) Jeff
participants (3)
-
Beth Jacobson
-
Caleb Epstein
-
Jeff Garland