This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author agthorr
Recipients
Date 2005-09-15.22:00:29
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Logged In: YES 
user_id=6324

Let me elaborate on the use-case where I originally ran into
this.

I'm conducting a series of observation experiments where I
measure the duration of an event.  I then want to do various
statistical analysis such as computing the mean, median,
etc.  Originally, I tried using standard functions such as
lmean from the stats.py package.  However, these sorts of
functions divide by a float at the end, causing them to fail
on timedelta objects.  Thus, I have to either write my own
special functions, or convert the timedelta objects to
integers first (then convert them back afterwards).

Basically, I want timedelta objects to look and act like
fixed-point arithmetic objects so that I can reuse other
functions on them that were originally developed to operate
on floats.  More importantly, I'd rather not have to
maintain two different versions of the functions to deal
with different types.

For implementation, why not multiply the float times .day,
.seconds, and .microseconds separately, then propagate and
fraction parts into the next smallest group (e.g., 0.5 days
becomes 24*60*60*0.5 seconds).

I agree it'd be possible to lose information with the wrong
sequence of operations, but that's always the case when
using floating point numbers.  In other words, that, too, is
what I would expect from the timedelta implementation.
History
Date User Action Args
2007-08-23 14:34:31adminlinkissue1289118 messages
2007-08-23 14:34:31admincreate