[issue15136] Decimal accepting Fraction
Raymond Hettinger added the comment: Thanks Nick. I'll go ahead and close this one, leaving the Decimal module only with lossless coercions that do not depend on the decimal context (this matches the underlying design of the decimal module which treats all numbers as exact, and only applying to the result of an arithmetic operation). If needed, a new issue can be opened for a format specifier for the Fraction type. It seems that we're all in agreement that that would be useful for the fractions module. -- resolution: - rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15136] Decimal accepting Fraction
Nick Coghlan added the comment: There is indeed a regression in decimal.localcontext with the C accelerator: omitting the argument entirely still works, but passing None explicitly now fails. I created #15783 for that. On the topic of this thread, I'm also -1 on conversion methods, but +1 on string formatting support. There's an obvious benefit in providing the latter in order to get a better feel for the value of a rational number by displaying a Decimal approximation, but questionable benefit in providing the former. Explicit conversion is sufficiently rare that I'm OK with the idea of either going via a string (as used to be necessary for binary floats) or by explicitly casting the numerator to Decimal, then dividing by the denominator (no need to cast them both). -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15136] Decimal accepting Fraction
Terry J. Reedy added the comment: After reading the comments, I am ambivalent about a conversion function, and given the lack of consensus or even a clear majority, -1. (Which implies a change in issue title.) I am +1 on using the new .format() machinery to have fractions format themselves. (Unless Python already does so for other purposes, it should do so without importing decimal.) The uploaded function passes the included test cases. I guess the rounding should be whatever we do for floats. I fudged that in the example. -- Added file: http://bugs.python.org/file26997/fracdec.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15136] Decimal accepting Fraction
Changes by Chris Rebert pyb...@rebertia.com: -- nosy: +cvrebert ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15136] Decimal accepting Fraction
Mark Dickinson added the comment:
I think *both* proposals are sensible. Fraction already has .from_decimal
(using Decimal), so .to_decimal (also using Decimal) is sensible.
Well, there's a difference: conversion from Decimal to Fraction is
well-defined, with a unique, unambiguous result (excluding non-convertibles
like infinities and nans); in particular, the value of any Decimal is exactly
representable as a Fraction, so there's little information loss. (There *is*
still some information loss, since Decimal('1.00') and Decimal('1.0') both
covert to the same fraction, for example.)
On the other hand, not every Fraction is exactly representable as a Decimal, so
the result of conversion from Fraction to Decimal needs information about how
many decimal places to produce, what rounding mode to use, what the ideal
exponent should be in the case of exact results, etc. I think Zachary's idea
of supporting a context argument, and using the current context if none is
supplied, is the way to go here. The division should end up using an ideal
exponent of 0, which doesn't seem unreasonable.
To the patch: It looks fine, as far as it goes. It needs tests. To avoid the
repetition of the division code, I'd suggest doing something like:
if context is None:
context = getcontext()
Yes, supporting __format__ is going to be a bit more work. :-)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15136
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15136] Decimal accepting Fraction
Stefan Krah added the comment:
I agree with Mark's arguments. Yesterday I tried to use as_decimal() in
a small program and it did not feel natural to me. I'll probably continue
to use Decimal(f.numerator) / f.denominator.
If this goes in, I'd prefer that as_decimal() always uses a localcontext().
As the patch stands, using as_decimal() pollutes the global context flags,
which can be quite unexpected:
from fractions import Fraction as F
F(1, 3).as_decimal()
Decimal('0.')
import decimal
decimal.getcontext()
Context(prec=28, rounding=ROUND_HALF_EVEN, Emin=-99, Emax=99,
capitals=1, clamp=0, flags=[Inexact, Rounded], traps=[InvalidOperation,
DivisionByZero, Overflow])
If the function takes a context argument, it might be better to move it
into the decimal module as Decimal.from_fraction(context).
So I'm -1/7 on as_decimal(), but +1 for the __format__() method.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15136
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15136] Decimal accepting Fraction
Zachary Ware added the comment: (Mark:) To the patch: It looks fine, as far as it goes. It needs tests. I remembered tests about 5 minutes after I submitted the initial patch :P. Here's a patch with some tests. Note that I've never really done tests, so please let me know if there need to be more/less/different tests. To avoid the repetition of the division code, I'd suggest doing something like: if context is None: context = getcontext() (Stefan:) If this goes in, I'd prefer that as_decimal() always uses a localcontext(). As the patch stands, using as_decimal() pollutes the global context flags, which can be quite unexpected My first attempt was simply: def as_decimal(self, context=None): with localcontext(context): return Decimal(self.numerator) / Decimal(self.denominator) Looking through decimal.py, it looks like that should work (and in fact it does in 3.2.3), but it seems that _decimal will only accept a context as the argument to localcontext(), not None. Is that expected, or does that need an issue? I didn't catch that the patch pollutes the global context flags, that is indeed ugly and unacceptable. If the function takes a context argument, it might be better to move it into the decimal module as Decimal.from_fraction(context). Perhaps both? Implement Decimal.from_fraction(f, context) to do the real work, and then Fraction.to_decimal() as: def to_decimal(self): return Decimal.from_fraction(self, None) Those who really care about the context (Decimal users working with a Fraction) can get what they want, and those who don't (Fraction users who want to see a Decimal representation) don't have to bother, and fractions.py isn't polluted with stuff about contexts. -- Added file: http://bugs.python.org/file26989/issue15136_with_tests.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15136] Decimal accepting Fraction
Zachary Ware added the comment: I came across this issue and thought it might be within my means to attempt a patch, so here's the first step towards one. I liked Terry's suggestion of implementing __format__ using .as_decimal, so that's what I'm working towards with this. The first part is (or seems to be, I am pretty new at this and may well have missed something obvious :-)) pretty easy. The attached patch is pretty self-explanatory, I think. I figure if the user wants something specific from their fraction-as-a-decimal, they're probably working with other decimals already and will be able to supply a context. Otherwise, if they just want to see a decimal representation, they'll probably be fine with the default context and don't have to worry about it. The __format__ part, though, seems kind of daunting. For one thing, Decimal's implementation looks pretty hairy and scary from my perspective; duplicating it for Fraction would be quite a feat. For another, the standard format spec doesn't seem to me to cleanly apply to fractional representations--what should be filled, how should alignment work, how would width be divided up, what exactly does precision mean? I've had a thought, though; what if Fraction.__format__ simply looks for a 'D' at the end of format_spec? If it's found, just return format(self.as_decimal(), format_spec[:-1]. Otherwise, format using to-be-determined rules specific to fractions, including rules for, say, mixed fractions or denominator of a certain size. Thoughts? -- keywords: +patch nosy: +zach.ware Added file: http://bugs.python.org/file26975/issue15136_as_decimal.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15136] Decimal accepting Fraction
Raymond Hettinger raymond.hettin...@gmail.com added the comment: Something like Fraction.as_decimal(prec=28) would be reasonable. -- priority: normal - low ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15136] Decimal accepting Fraction
Mark Dickinson dicki...@gmail.com added the comment: Something like Fraction.as_decimal(prec=28) would be reasonable. I'd prefer an implementation of Fraction.__format__. That solves the SO user's need exactly. Note that he/she didn't care about the Decimal type, but only wanted to be able to *print* digits of a Fraction; the __format__ method is the OOWTDI. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15136] Decimal accepting Fraction
Terry J. Reedy tjre...@udel.edu added the comment: I think *both* proposals are sensible. Fraction already has .from_decimal (using Decimal), so .to_decimal (also using Decimal) is sensible. It also has .from_float, with 'f.to_float' spelled f.__float__, normally called as float(f). On the other hand, part of the point of the new format system was/is to allow 'other' classes to tie into format specs with custom .__format__. Currently, Fraction inherits .__format__ from object, which only recognizes 's' specifications. (Anything else gives a misleading 'str' error message that is the subject of another issue.) I think it should get a custom .__format__, which could use f.to_decimal(prec), where prec is calculated from the format spec. -- nosy: +eric.smith, terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15136] Decimal accepting Fraction
New submission from Jon Clements jon...@googlemail.com:
I'm not a numeric expert but I was looking at a post on S/O which related to
converting a Fraction to a certain amount of decimal places. I've had a hunt on
the tracker but couldn't find anything relevant, but if I've missed it, I
apologise.
# F=Fraction, D=Decimal classes
If I try num = D( F(5, 7) )
I get: TypeError: Cannot convert Fraction(5, 7) to Decimal
So I do:
D(f.numerator) / D(f.denominator)
Decimal('0.7142857142857142857142857143')
Which I think is the correct result?
I guess my question is - should Decimal do this implicitly for Fraction?
--
components: Library (Lib)
messages: 163397
nosy: joncle
priority: normal
severity: normal
status: open
title: Decimal accepting Fraction
type: enhancement
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15136
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15136] Decimal accepting Fraction
Ramchandra Apte maniandra...@gmail.com added the comment: +1 -- nosy: +ramchandra.apte ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15136] Decimal accepting Fraction
Mark Dickinson dicki...@gmail.com added the comment: I guess my question is - should Decimal do this implicitly for Fraction? I'd prefer not. All other cases of Decimal construction (from float, from string, etc.) are lossless with results that don't depend on the current context; construction from a Fraction will usually involve rounding, with results depending on the current rounding-mode and precision. Having the division operation explicit (making it obvious that there's rounding involved) looks better to me. -- nosy: +mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15136] Decimal accepting Fraction
Jon Clements jon...@googlemail.com added the comment: Mark - I bow to your superiour knowledge here. However, would not a classmethod of .from_fraction be welcome? ie, I could write: d = D.from_fraction(5, 7) Then the documents labour the point about what you've mentioned? Just an idea, but fully realise you're the man best suited to decide, so I'll be happy with whatever you say. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15136] Decimal accepting Fraction
Jon Clements jon...@googlemail.com added the comment: Not sure what's going on with my machine today: keep sending things to early. I meant: D.from_fraction(F) where if F is not of type Fraction, then the args are used to construct a Fraction - so can use an existing or create one. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15136] Decimal accepting Fraction
Mark Dickinson dicki...@gmail.com added the comment: would not a classmethod of .from_fraction be welcome? That depends. :-) Certainly a new classmethod seems better to me than extending the constructor to allow Fractions. I'm not convinced that there's a real need for this feature, though, especially given how easy it is do directly. So I'm -1 on extending the constructor, -0 on adding a .from_fraction method. I'm adding other decimally people to the nosy for their opinions. -- versions: +Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15136] Decimal accepting Fraction
Changes by Mark Dickinson dicki...@gmail.com: -- nosy: +rhettinger, skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15136] Decimal accepting Fraction
Mark Dickinson dicki...@gmail.com added the comment: BTW, the StackOverflow question helped me understand the use-case here: http://stackoverflow.com/q/11154954/270986 The perspective is that of a *Fraction* user who wants to be able to easily see the Decimal expansion of a Fraction to an arbitrary number of decimal places. (I was trying to understand why a *Decimal* user would care about converting from Fraction instances, but that's the wrong way around.) That desire to have an easy way to see the digits of a Fraction seems reasonable to me, but I'm not sure that having a Decimal method is the right way to go about it. Another possible solution would be to implement a decent __format__ method for Fraction, so that somebody could do: format(Fraction(1, 7), '.17g') '0.14285714285714286' -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15136] Decimal accepting Fraction
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- assignee: - rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15136] Decimal accepting Fraction
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- versions: +Python 3.4 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15136] Decimal accepting Fraction
Jon Clements jon...@googlemail.com added the comment:
The more I think about this - the shades of grey kick in.
D.from_fraction(F or creatable F)
Then it would be 'reasonable to assume' for a F.to_decimal() to exist.
Possibly with an optional context argument.
Then, what happens if I do D('2.45') * F(24 / 19)...
I'll leave it to the experts, but have noticed Raymond has ideas for this, but
not yet commented?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15136
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
