Issue 8947: Provide as_integer_ratio() method to Decimal (original) (raw)

Created on 2010-06-08 20:51 by belopolsky, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
issue8947.patch mark.dickinson,2010-06-11 12:38
issue8947_2.patch mark.dickinson,2010-06-11 12:56
Messages (11)
msg107345 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-06-08 20:51
Here is my use case: recently implemented timedelta * float operation starts with converting float to an int ratio. The same algorithm can be used for decimals, but they don't support as_integer_ratio().
msg107348 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-06-08 21:10
This seems like a reasonable request to me; I'd like to see a little bit of convergence between the float and Decimal APIs. One difference between the two types that's worth noting is that the float.as_integer_ratio() method can never take a ridiculous amount of time or memory, whereas Decimal.as_integer_ratio() could: e.g., consider Decimal('1e999999999').as_integer_ratio(). But I don't really see that as a problem.
msg107542 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-06-11 12:38
Here's a patch.
msg107543 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-06-11 12:56
Updated patch, taking into account comments from merwok and exarkun on #python-dev: - remove doctests for infinity and nan, replace with a sentence explaining what happens for such inputs. - replace 'snAN' with saner spelling 'snan'.
msg107622 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-06-12 03:24
Nice implementation. I wonder if the /5 loop can be eliminated by noting that /5 is *2 followed by decimal shift. (Probably not without fast decimal arithmetics.) A few documentation nits: 1. In Decimal methods there is no consistency in referring to self. I see "given Decimal", "the number", and "the argument" in three entries around as_integer_ratio(). 2. Is there a reason that docstring is more detailed than manual entry? I think the manual should describe exceptions. 3. Is there a reason to use different language for float.as_integer_ratio() and Decimal.as_integer_ratio()? I know, ""A foolish consistency is the hobgoblin of little minds..." - feel free to ignore my observations. A tiny code nit: to me it would be clearer to start with d2 = d5 = -self._exp after the "# Find d2, d5 ..." comment. For a moment I was puzzled why you promise d2 and d5, but then process d5 only. Also, by the time of the "if not self" check, special case has been eliminated, so you can simply check self._int == 0.
msg108600 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-06-25 14:35
Raymond, do you have any thoughts on this proposal?
msg108613 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2010-06-25 18:07
-0 I don't think we really need this (we've already got a reasonable conversion to Fraction). In general, we should have a aversion to adding any methods to the decimal API because it is already very fat. Adding more methods makes it harder to figure out which one is the right one to use.
msg108615 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-06-25 18:27
Raymond, conversion to Fraction does not really help in my use case of supporting timedelta * Decimal by duck typing. I can think of many other use cases where it will be helpful to accept either float or decimal without loss of precision. Is there an alternative way to achieve that which does not require importing the decimal module first?
msg108944 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-06-29 20:07
After discussions on IRC, I'm going to close this as rejected. Convergence of the float and Decimal APIs is a nice idea, but in this case it's not clear that it really works. In particular, for duck typing to be sensible, int and Fraction would also have to grow an as_integer_ratio method. And that seems a superfluous when those two types already have the same functionality in the form of .numerator and .denominator attributes. I also agree with Raymond that we shouldn't be fattening the decimal API without good reason. Alexander: wouldn't conversion to Fraction solve the issue in this case? The Fraction constructor accepts floats, Decimal instances and ints directly.
msg313767 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2018-03-13 18:56
Apologies: the title change was accidental. Reverted.
msg313768 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2018-03-13 19:04
This issue has been superseded by #25928.
History
Date User Action Args
2022-04-11 14:57:02 admin set github: 53193
2018-03-13 19:04:17 belopolsky set superseder: Add Decimal.as_integer_ratio()resolution: rejected -> duplicatemessages: + stage: patch review -> resolved
2018-03-13 18:56:54 mark.dickinson set messages: +
2018-03-13 09:19:24 mark.dickinson set title: as_integer_ratio Decimal -> Provide as_integer_ratio() method to Decimal
2018-03-13 09:19:08 mark.dickinson set title: Provide as_integer_ratio() method to Decimal -> as_integer_ratio Decimal
2010-06-29 20:07:25 mark.dickinson set status: open -> closedresolution: rejectedmessages: +
2010-06-25 18:27:18 belopolsky set messages: +
2010-06-25 18:07:51 rhettinger set messages: +
2010-06-25 14:35:39 mark.dickinson set nosy: + rhettingermessages: +
2010-06-12 03:24:51 belopolsky set messages: +
2010-06-11 12:56:36 mark.dickinson set files: + issue8947_2.patchmessages: +
2010-06-11 12:38:16 mark.dickinson set files: + issue8947.patchkeywords: + patchmessages: + stage: patch review
2010-06-09 15:31:30 skrah set nosy: + skrah
2010-06-08 21🔞45 mark.dickinson set assignee: mark.dickinson
2010-06-08 21:10:29 mark.dickinson set nosy: + mark.dickinsonmessages: +
2010-06-08 20:51:06 belopolsky create