Bugs item #1289118, was opened at 2005-09-12 14:41 Message generated for change (Comment added) made by agthorr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289118&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel Stutzbach (agthorr) Assigned to: Nobody/Anonymous (nobody) Summary: timedelta multiply and divide by floating point Initial Comment: In python 2.4.1, the datetime.timedelta type allows for the multiplication and division by integers. However, it raises a TypeError for multiplication or division by floating point numbers. This is a counterintutive restriction and I can't think of any good reason for it. For example: >>> import datetime >>> datetime.timedelta(minutes=5)/2 datetime.timedelta(0, 150) >>> datetime.timedelta(minutes=5)*0.5 Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: unsupported operand type(s) for *: 'datetime.timedelta' and 'float' ---------------------------------------------------------------------- >Comment By: Daniel Stutzbach (agthorr) Date: 2005-09-15 15:00 Message: 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. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-09-15 14:04 Message: Logged In: YES user_id=31435 timedelta arithmetic is 100% portable now, and wholly explainable in terms of universally understood integer arithmetic. Throw floats into it, and that's lost. That said, I don't have a strong objection to complicating the implementation if there _are_ strong use cases. The OP's example isn't "a use case": it's not worth anything to let someone multiply a timedelta by 0.5 instead of dividing by 2. I don't have a use case to offer in its place (never felt a need here). If someone wants to work on it, note that a timedelta can contain more than 53 bits of information, so, e.g., trying to represent a timedelta as an IEEE double-precision number of microseconds can lose information. This makes a high- qualty "computed as if to infinite precision with one rounding at the end" implementation of mixed datetime/float arithmetic tricky to do right. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2005-09-15 09:03 Message: Logged In: YES user_id=99874 I, too, would like to know what Tim thinks, but for what it's worth (not much) I find Daniel's point fairly convincing... multiplication by floats is an operation that makes sense, has only one possible obvious meaning, and is not particularly likely to cause errors (the way multiplying Decimal's with floats does). So IF it's easy to implement, I say go for it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-12 21:11 Message: Logged In: YES user_id=80475 Tim, do you prefer the current behavior? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289118&group_id=5470 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
