It is not just that float to decimal conversion is exact. The Decimal constructor is exact for all possible inputs be they int, float, string or the tuple of ints representation. This is important because part of the idea of the decimal module is to have precise control over how things like rounding are managed. You want the constructor which is not a context method to be exact so that you can then use a context to control any subsequent rounding. That way you can guarantee to round up for example or trap the inexact signal.
The proper solution is really to have a way of spelling numbers exactly rather than trying to recover after a lossy conversion. That is the benefit that decimal and fraction literals would provide and without them strings are the next best thing.
The only problem I see here is the misconception âusing decimal literalsâ. All confusion disappears simply by learning not to make that false assumption. In principle, if there are no decimal literals, one shouldnât be making that assumption anyway.
Regarding the parenthesized statement, older versions of Python used to display a (sometimes) different representation of the float. So, another thing to learn is that the float-literal to float correspondence is many to one. The assumption that one literal shows ânot exactnessâ more than other is also another unwarranted assumption.
The point was - yes, we can add literals for Fractions without this. But just as Paul - I donât see big benefits from this shortcut. F(1,2) is not too much worse than 1/2f and definitely expects less from the reader.
Thatâs a kind of changes, on which I would buy decimal literals:)
But changing meaning of floatâs to be decimal floatâs - is something for Python 4.0. Probably, this ship sailed.
I donât think itâs a real problem. Binary floats (assuming system, implementing the C Annex F) have much more stuff than exposed by Pythonâs float type API.
Iâll preface this by saying that I agree that Oscarâs point about exactness in the constructor conflicts with (and almost certainly supersedes) a goal of making the constructor to be more user-friendly.
Curiously, my proposal is that the conversion would be inexact, but still lossless. Since Decimal has far more precision than float, there are many possible Decimal values that evaluate to the same float, for any given float. The difference would be that the Decimal intermediate would be chosen to, e.g., use the shortest precision needed to guarantee a unique Decimal for every float, rather than the current choice of using as much precision as required to exactly represent the provided float.
(Itâs also worth noting that Decimal â float is almost always lossy, unless the initial Decimal happens to be the exact value returned by the Decimal constructor.)
Naming is honestly the hard part here. I used D to provide brevity (consistent with the opening proposal to create Decimal literals), but this would not be an appropriate name to include in the standard library. If we were to add a helper function to the decimal module, it would need to be sort enough to be handy, but not conflict or cause confusion with the existing uses of decimal and Decimal. Options Iâd consider would be decimal.dec or, more verbosely, decimal.as_decimal. Does anyone else have other suggestions?
If thereâs support for it, Iâd be happy to propose adding such a recipe to the docs as a first step, but I think recipes are much less discoverable and have poorer UX relative to including a function in the decimal module.
You are reinventing David Gayâs algorithm for finding the shortest floating point representation, thatâs used by str() circa CPython 3.1. But you can explicitly construct such Decimal instance from a float f as Decimal(str(f)).
This decimal value, in general, will be not equal to f mathematically. It will be a different rational number. Why the hell this silent lossy conversion will be better than current approach, which just choose equal number? (BTW, all you save â just two characters: D(0.1) vs D("0.1").)
Current Decimal(float) form is useful for people to get exact decimal fraction, equal to the given binary floating-point number. It will be odd if different Decimal constructors (i.e. Decimal() and Decimal.from_float()) will interpret same input differently.
Thatâs why there is no implicit conversion from Decimalâs in the float constructor.
What about rich comparisons? Are you sure, that < and > will return something âexpectedâ (from the school) after you âfixâ equality?
Yup, youâre right that changing the behavior of how the Decimal constructor handles floats is a bad idea. Consider it dropped.
Since the outcome of this thread appears to be a ânoâ on introducing Decimal literals to the language. As I understood it, the primary motivation is to improve the ergonomics of creating Decimal objects from literals (particularly the footgun that Decimal(0.1) != Decimal("0.1")). I was hoping to explore other avenues to improve those ergonomics. But I am probably out of my depth and will bow out from that process.
2 extra symbols does really really matter. Itâs friction every time you type a number.
I think the constuctor Iâd want thatâs closest to being compatible with Python is Decimal(0,1)==Decimal("0.1"). If itâs in the standard library we could even push for linters/formatters to format it as Decimal(0,1) instead of Decimal(0, 1).
Decimal(0,1) is currently a TypeError, so this might be backwards compatible.
Decimal("0.001") would still give issues. But youâd provide a better solution to 9/10 cases.
Could you be a bit more specific why itâs horrible?
It mirrors fractions.Fraction(1, 3) which works quite well, and there are plenty of countries around the world where 0,1 is the default way to write numbers with decimals.
Itâs abuse of notation, most programming languages donât use commaâs for decimal numbers.
And the fact that it doesnât work in all cases is more proof that this is a bad idea.
Writing Decimal("1e-1") as Decimal(1, e=-1) seems more justifiable, but saves at most 1 character.
Cell In[3], line 3
Decimal(0, 0010)
^
SyntaxError: leading zeros in decimal integer literals are not permitted; use an 0o prefix for octal integers
both the part before and after the comma have to be valid integers. Integers canât have leading zeros. Itâs going to crash immediately, and tell you precisely where you did something wrong. As errors go, thatâs a pretty good case.
I agree that the extra symbols matter. There really is a usability difference between D("1.1") and 1.1d.
The problem is that decimals simply arenât useful enough to justify new syntax. They are a convenient example of a case where a good literal syntax matters, but they just arenât used enough in practice.
I donât think Iâve ever written or seen real-world code that uses decimals. And I doubt that would have been different if decimal literals were built in. My experience is just in one particular field, so the experience of others may vary, but I doubt the overall result will be much different - decimals simply arenât used very often.
IMO, the only way weâd get a literal format for decimals is as a side-effect of some form of âuser defined literalsâ feature, that gains its justification from being applicable to a number of different use cases, each of which might on their own be insufficient. But I donât think that even that is likely - very few languages support user defined literals (C++ is the only mainstream one that I know of) suggesting that they arenât as useful in practice as you might think.
Agreed. Thatâs why I did not propose new syntax . Just Decimal(12,34), a syntax that works well for 90% of cases.
Iâve got real production code where decimals would have been useful. Specifically, in testing. I wanted to assert things were equal, but float rounding got in the way.
In the end I went with octal numbers. Itâs a good enough solution.
But it doesnât work in an useful way. As has been pointed out, it canât represent 1.01.
The 90%[1] of cases you claim excludes many reasonable examples, and it does so in a pretty unintuitive (at least IMO) way.
Seriously, having to write D("1.01") rather than D(1.01) was enough to make you rewrite the logic of your production code? That seems rather extreme (and while Iâm not disputing your claim, I donât think itâs anywhere near typical enough to prove anything).
It may very well be that the trade off makes it not worthwhile to introduce Decimal literals but I think it is important to see the problem more broadly than just using the Decimal type. In Python different numeric types can be mixed, converted, coerced, compared etc and ultimately numbers of all types when specified explicitly in code are created from literals e.g.:
The issue is not just about wanting to use the Decimal and Fraction types themselves but rather about being able to specify an exact numeric value as an input to any operation including the constructor of any other numeric type. Currently the best we have for this is to use string literals but we donât want to allow strings to be coerced implicitly into numeric types so we need the explicit conversion (D(s)) everywhere.
So would an âunparsed numberâ literal be helpful? Something like 0u123.456 which produces a string literal "123.456"? That would provide a generic solution, which would be essentially a âdrop inâ solution (as numeric types typically already have some sort of âconstruct from stringâ operation, precisely because of the exactness issue).
The problem, of course, is that 0u123.456 is no simpler in any real sense than "123.456".
User perception is important - but is it that important? I honestly donât knowâŠ
Personally, I would use Fraction and Decimal way more often if there were literals for it.
Although I donât often need these in production, but they are very useful when prototyping / doing analytical work.
Currently, I have preset imports for environments where I do this - from decimal import decimal as D; from fraction import fraction as F, but if there were literals for these, then it would both:
be more convenient and less ambiguous than one-letter aliases in places where I do those
I would use them more often for calculations when I just open REPL for some quick calculations. Now I mostly donât bother and get satisfactory result from float.
But this is my personal case.
From POV of longer term consequences of such, I would guess that one positive is that it would accelerate progress for decimal & fractions in all areas, such as performance, features and compatibility with the rest.
So all in all I am ±0 - donât have sufficient information for strong opinion, but from userâs perspective I would be pleased with this for sure.
E.g. To me this would be quite convenient (maybe not as pretty (initially clear) as having . and /, but unambiguous and avoids most of / some of (valid) criticism that I have seen in this thread):
Given that 0x1 uses 0x as a prefix, having 0d mean 0. (but in decimal) would be very confusing. 0d0.1 seems far more likely to be acceptable. Thereâs no equivalent confusion with 1f2 but I think it would be considered too obscure in practice.
. Just