Re: [Python-Dev] Mixing float and Decimal -- thread reboot
Raymond Hettinger wrote: > > On Mar 20, 2010, at 6:54 PM, Nick Coghlan wrote: >> >> I suggest a 'linearised' numeric tower that looks like: >> >> int -> Decimal -> Fraction -> float -> complex > > Is that a typo? Shouldn't Decimal and float go between Fraction and > complex? > > The abstract numeric tower is: > > Number Complex Real Rational Integral > > where both Decimal and float have operations associated with reals. I don't actually mind either way - the pragmatic tower is about coding convenience rather than numeric purity (and mixing Fractions and Decimals in the same algorithm is somewhat nonsensical - they're designed for two completely different problem domains). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal & amp; lt; -& amp; gt; float comparisons in py3k.
Greg Ewing wrote:
> Nick Coghlan wrote:
>
>> Note that Antoine's point was that float("0.1") and
>> Decimal.from_float(0.1) should compare equal.
>
> That would mean that Decimal("0.1") != float("0.1"), which might be
> surprising to someone who didn't realise they were mixing floats
> and decimals.
That's fine - binary floats *are* surprising. That's why Decimal exists
in the first place.
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Fwd: Broken link to download (Mac OS X)
Hey all, This seems to happen whenever we do a new release (we've had a couple of emails to [email protected] about it since 2.6.5 was released). The main download page for Python has a broken link for the Mac installer (because it hasn't been built yet I assume): http://python.org/download/ The link 404s, with no explanation or alternate link - so for the casual user who wants to install Python 2.6 on Mac OS X they are sorely-out-of-luck. Not being able to provide a mac installer at the same time as other platforms is one thing (and I accept that is unavoidable), breaking the download links for Mac users for unspecified lengths of time is just bad practise. If we create a new stable release without a Mac installer can we at least provide a brief explanation and link to the *previous version* until the new version is ready? All the best, Michael Original Message Subject:Broken link to down Date: Sun, 21 Mar 2010 13:40:36 + From: Ben Hodgson To: [email protected] Hey there, In case you don't know, the link on http://www.python.org/download/ to the Python 2.6.5 Mac Installer Disk Image (http://www.python.org/ftp/python/2.6.5/python-2.6.5_macosx10.3.dmg) is broken. Cheers, Ben -- Ben Hodgson http://benhodgson.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mixing float and Decimal -- thread reboot
On Sat, Mar 20, 2010 at 6:54 PM, Nick Coghlan wrote: > Guido van Rossum wrote: >> I think we should seriously reconsider allowing mixed arithmetic >> involving Decimal, not just mixed comparisons. > > I'm glad I'm not the only one that started wondering that. I > wasn't quite game enough to actually suggest it though :) > >> There is one choice which I'm not sure about. Should a mixed >> float/Decimal operation return a float or a Decimal? I note that >> Fraction (which *is* properly embedded in the numeric tower) supports >> this and returns a float result in this case. While I earlier >> proposed to return the most "complicated" type of the two, i.e. >> Decimal, I now think it may also make sense to return a float, being >> the most "fuzzy" type in the numeric tower. This would also make >> checking for accidental floats easier, since floats now propagate >> throughout the computation (like NaN) and a simple assertion that the >> result is a Decimal instance suffices to check that no floats were >> implicitly mixed into the computation. > > To blend a couple of different ideas from the thread reboot together: > > I suggest a 'linearised' numeric tower that looks like: > > int -> Decimal -> Fraction -> float -> complex > > As Adam stated, this is a pragmatic tower stating which implicit > coercions are defined by the code, not a formal mathematical relationship. > > Note that this would involve adding mixed Fraction/Decimal arithmetic as > well as Decimal/float arithmetic. Yes, that was my intention too. > I placed Decimal to the left of > Fraction to keep Decimal's dependencies clear and because Decimal -> > Fraction conversions appear straightforward (using power of 10 > denominators) without introducing the precision issues that would arise > in Decimal -> Fraction conversions. This is just wrong. Decimal is much more like float than like int or Fraction, due to its rounding behavior. (You cannot produce exact results for 1/3 using either Decimal or float.) Clearly the difficult decision is whether Decimal is between Fraction and float, or between float and complex (I prefer not to say "to the left/right of" since PEP 3141 orders the types in the opposite way as people have been doing here). Both are floating point types that sometimes produce rounded results (e.g. 1/3); the difference is that they use different bases and that Decimal has configurable precision when rounding. I would make float the last station before complex, whereas Mark would prefer Decimal to go there. I defer to Mark, who has thought a lot more about Decimal than I have. > I also like the idea of adding the decimal context signal that Facundo > suggests (e.g. under the name ImplicitCoercionToBinaryFloat). Yes, this is what I was trying to say (but didn't find the right words for). > So "quick and dirty don't need a perfect answer" operations end up with > ordinary binary floats, while more precise code can enable the signal > trap to ensure the calculation fails noisily if binary floats are > introduced. But does this break a tie for the relative ordering of Decimal and float in the tower? > Allowing implicit operations would also finally allow Decimal to be > registered with numbers.Real. Right, that's one aspect of what I meant by "embedded in the numeric tower". > Whatever we decide to do will need to be codified in a PEP though. > "Cleaning Up Python's Numeric Tower" or something along those lines. The cleanup is really just specific to Decimal -- int, Fraction and float are already properly embedded in the tower (PEP 3141 doesn't advertise Fraction enough, since it predates it). That we may have to change the __hash__ implementation for the other types is merely a compromise towards efficiency. >> The implementation of __hash__ will be complicated, and it may make >> sense to tweak the hash function of float, Fraction and Decimal to >> make it easier to ensure that for values that can be represented in >> either type the hash matches the equality. But this sounds a >> worthwhile price to pay for proper embedding in the numeric tower. > > And Mark appears to already have a good answer to that problem. Which I still have to review. (Mark, if you're there, could you make a brief post here on the mathematical definition of the new hash you're proposing, and why it is both efficient to compute and good (enough) as a hash function?) -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mixing float and Decimal -- thread reboot
On Sun, Mar 21, 2010 at 9:53 AM, Guido van Rossum wrote: > Which I still have to review. (Mark, if you're there, could you make a > brief post here on the mathematical definition of the new hash you're > proposing, and why it is both efficient to compute and good (enough) > as a hash function?) Never mind, Mark. I found your explanation here: http://codereview.appspot.com/660042/diff/19001/11009?column_width=80 -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal & amp; lt; -& amp; gt; float comparisons in py3k.
On Sat, Mar 20, 2010 at 11:59 PM, Nick Coghlan wrote:
> Greg Ewing wrote:
>> Nick Coghlan wrote:
>>
>>> Note that Antoine's point was that float("0.1") and
>>> Decimal.from_float(0.1) should compare equal.
>>
>> That would mean that Decimal("0.1") != float("0.1"), which might be
>> surprising to someone who didn't realise they were mixing floats
>> and decimals.
>
> That's fine - binary floats *are* surprising. That's why Decimal exists
> in the first place.
Decimals can be just as surprising:
>>> Decimal(1) / Decimal(3) * Decimal(3) == Decimal(1)
False
>>>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [RELEASED] Python 3.1.2
On behalf of the Python development team, I'm joyful to announce the second bugfix release of the Python 3.1 series, Python 3.1.2. This bug fix release fixes numerous issues found in 3.1.1, and is considered a production release. The Python 3.1 version series focuses on the stabilization and optimization of the features and changes that Python 3.0 introduced. For example, the new I/O system has been rewritten in C for speed. File system APIs that use unicode strings now handle paths with undecodable bytes in them. Other features include an ordered dictionary implementation, a condensed syntax for nested with statements, and support for ttk Tile in Tkinter. For a more extensive list of changes in 3.1, see http://doc.python.org/3.1/whatsnew/3.1.html or Misc/NEWS in the Python distribution. To download Python 3.1.2 visit: http://www.python.org/download/releases/3.1.2/ A list of changes in 3.1.2 can be found here: http://svn.python.org/projects/python/tags/r312/Misc/NEWS The 3.1 documentation can be found at: http://docs.python.org/3.1 Bugs can always be reported to: http://bugs.python.org Enjoy! -- Benjamin Peterson Release Manager benjamin at python.org (on behalf of the entire python-dev team and 3.1.2's contributors) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mixing float and Decimal -- thread reboot
>> >> Note that this would involve adding mixed Fraction/Decimal arithmetic as >> well as Decimal/float arithmetic. > > Yes, that was my intention too. +1 > >> I placed Decimal to the left of >> Fraction to keep Decimal's dependencies clear and because Decimal -> >> Fraction conversions appear straightforward (using power of 10 >> denominators) without introducing the precision issues that would arise >> in Decimal -> Fraction conversions. > > This is just wrong. Decimal is much more like float than like int or > Fraction, due to its rounding behavior. (You cannot produce exact > results for 1/3 using either Decimal or float.) Right. We should be guided by: fractions are a superset of decimals which are a superset of binary floats. And by: binary floats and decimal floats both implement all of the operations for the Real abstract base class. > > Yes, this is what I was trying to say (but didn't find the right words for). > >> So "quick and dirty don't need a perfect answer" operations end up with >> ordinary binary floats, while more precise code can enable the signal >> trap to ensure the calculation fails noisily if binary floats are >> introduced. > > But does this break a tie for the relative ordering of Decimal and > float in the tower? > It seems to me that Decimals and floats should be considered at the same level (i.e. both implement Real). Mixed Decimal and float should coerce to Decimal because it can be done losslessly. There is no need to embed a notion of "imperfect answer". Numbers themselves are exact and many mixed operations can be exact is the coercions go the right way. Some folks who have had bad experiences with representation error (i.e. 1.1 cannot be exactly represented as a binary float) or with round-off error (i.e. 1.0 / 7.0 must be rounded) tend to think of both binary or decimal floats as necessarily inexact. But that is not the case, exact accounting work is perfectly feasable with decimals. Remember, the notion of inexactness is a taint, not an intrinsic property of a type. Even the Scheme numeric tower recognizes this. LIkewise, the decimal specification also spells-out this notion as basic to its design. > >> Whatever we decide to do will need to be codified in a PEP though. >> "Cleaning Up Python's Numeric Tower" or something along those lines. > > The cleanup is really just specific to Decimal -- int, Fraction and > float are already properly embedded in the tower (PEP 3141 doesn't > advertise Fraction enough, since it predates it). That we may have to > change the __hash__ implementation for the other types is merely a > compromise towards efficiency. I believe that no "clean-up" is necessary. Decimal already implements the Real ABC. All that is necessary is the common __hash__ algorithm and removing the restriction between decimal/float interaction so that any two instances of Real can interoperate with one another. Raymond___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mixing float and Decimal -- thread reboot
On Mar 20, 2010, at 9:40 PM, Greg Ewing wrote: > Mark Dickinson wrote: > >> Except that float is fixed-width (typically 53 bits of precision), >> while Decimal allows a user-specified, arbitrarily large, precision; > > Yes, but it still has *some* fixed limit at any given > moment, so the result of an operation on Decimals always > has the potential to produce an inexact result. It's > not like an int or Fraction where the result can expand > to whatever size is needed. I'm thinking that I need to do more work on the Decimal documentation. There still seems to be a profound misunderstanding of its capabilities (i.e. that an Inexact flag can be set to preclude any inexact operations, that the precision can be automatically extended as needed during a calculation, or that many types of calculations can be done exactly especially if floor division is used). If rounded is needed, it can be controlled explicitly. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mixing float and Decimal -- thread reboot
On Mar 21, 2010, at 10:02 AM, Guido van Rossum wrote: > On Sun, Mar 21, 2010 at 9:53 AM, Guido van Rossum wrote: >> Which I still have to review. (Mark, if you're there, could you make a >> brief post here on the mathematical definition of the new hash you're >> proposing, and why it is both efficient to compute and good (enough) >> as a hash function?) > > Never mind, Mark. I found your explanation here: > http://codereview.appspot.com/660042/diff/19001/11009?column_width=80 I'm often dazzled by Mark's brilliance, but this is an especially nice bit of reasoning. Raymond___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mixing float and Decimal -- thread reboot
On Sun, 21 Mar 2010 11:25:34 -0700, Raymond Hettinger
wrote:
> It seems to me that Decimals and floats should be considered at
> the same level (i.e. both implement Real).
>
> Mixed Decimal and float should coerce to Decimal because it can be
> done losslessly.
>
> There is no need to embed a notion of "imperfect answer".
> Numbers themselves are exact and many mixed operations
> can be exact is the coercions go the right way.
I think the concern here is rather about operations such as:
1.1 + Decimal('1.1')
The calculation may produce an "exact" result, but it won't be the exact
result expected, because the conversion from string (at the program text
file level) to float was lossy. Thus the desire for some mechanism to
know that floats and decimals have been mixed anywhere in the calculations
that led up to whatever result number you are looking at. And to have
doing so trigger an exception if requested by the programmer.
--
R. David Murray www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mixing float and Decimal -- thread reboot
On Sun, Mar 21, 2010 at 00:58, Nick Coghlan wrote: > I don't actually mind either way - the pragmatic tower is about coding > convenience rather than numeric purity (and mixing Fractions and > Decimals in the same algorithm is somewhat nonsensical - they're > designed for two completely different problem domains). I think the rule I've been going on is that ideal types (int, Fraction) are on one end and pragmatic types (float, complex) are on the other. Since Decimal can be used exactly it clearly bridges both groups. *However*, there's other possible types out there, and would they fit into my system? I've just taken a look at sympy and although it's clearly an ideal type, it also allows mixing with float and complex, both producing sympy types. That puts it clearly past float and complex in the tower. I have no ideal where Decimal should go. -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mixing float and Decimal -- thread reboot
On Mar 21, 2010, at 11:50 AM, R. David Murray wrote:
> On Sun, 21 Mar 2010 11:25:34 -0700, Raymond Hettinger
> wrote:
>> It seems to me that Decimals and floats should be considered at
>> the same level (i.e. both implement Real).
>>
>> Mixed Decimal and float should coerce to Decimal because it can be
>> done losslessly.
>>
>> There is no need to embed a notion of "imperfect answer".
>> Numbers themselves are exact and many mixed operations
>> can be exact is the coercions go the right way.
>
> I think the concern here is rather about operations such as:
>
>1.1 + Decimal('1.1')
>
> The calculation may produce an "exact" result, but it won't be the exact
> result expected, because the conversion from string (at the program text
> file level) to float was lossy. Thus the desire for some mechanism to
> know that floats and decimals have been mixed anywhere in the calculations
> that led up to whatever result number you are looking at. And to have
> doing so trigger an exception if requested by the programmer.
That makes sense. That's why Guido proposed a context flag in
decimal to issue a warning for implicit mixing of decimals and floats.
What I was talking about was a different issue. The question of
where to stack decimals in the hierarchy was erroneously
being steered by the concept that both decimal and binary floats
are intrinsically inexact. But that would be incorrect, inexactness
is a taint, the numbers themselves are always exact.
I really like Guido's idea of a context flag to control whether
mixing of decimal and binary floats will issue a warning.
The default should be to issue the warning (because unless
you know what you're doing, it is most likely an error).
Raymond
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal & amp; lt; -& amp; gt; float comparisons in py3k.
Nick Coghlan wrote: That's fine - binary floats *are* surprising. That's why Decimal exists in the first place. This argument could equally well be used the other way -- someone using Decimal is doing so precisely because they *don't* want to be surprised, in which case they would probably prefer to get an exception. The fundamental problem here is that there are two possible reasons for a mixed float-decimal operation: 1) The user is thinking in terms of floats and has happened to get a Decimal mixed in somehow. 2) The user is thinking in terms of Decimals and has happened to get a float mixed in somehow. There is no way of distinguishing between these automatically. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 3.1.2
On 3/21/2010 1:12 PM, Benjamin Peterson wrote: On behalf of the Python development team, I'm joyful to announce the second bugfix release of the Python 3.1 series, Python 3.1.2. Thanks for the work. This bug fix release fixes numerous issues found in 3.1.1, and is considered a production release. The Python 3.1 version series focuses on the stabilization and optimization of the features and changes that Python 3.0 introduced. For example, the new I/O system has been rewritten in C for speed. File system APIs that use unicode strings now handle paths with undecodable bytes in them. Other features include an ordered dictionary implementation, a condensed syntax for nested with statements, and support for ttk Tile in Tkinter. For a more extensive list of changes in 3.1, see http://doc.python.org/3.1/whatsnew/3.1.html or Misc/NEWS in the Python distribution. To download Python 3.1.2 visit: http://www.python.org/download/releases/3.1.2/ A list of changes in 3.1.2 can be found here: http://svn.python.org/projects/python/tags/r312/Misc/NEWS There seem to be about a hundred fixes. The 3.1 documentation can be found at: http://docs.python.org/3.1 Bugs can always be reported to: http://bugs.python.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mixing float and Decimal -- thread reboot
Raymond Hettinger wrote: Remember, the notion of inexactness is a taint, not an intrinsic property of a type. Even the Scheme numeric tower recognizes this. LIkewise, the decimal specification also spells-out this notion as basic to its design. I'm not sure it really does, otherwise every decimal value would have a flag indicating whether it was tainted with inexactness, and this flag would propagate through calculations. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal & amp; lt; -& amp; gt; float comparisons in py3k.
On Mon, 22 Mar 2010 08:47:53 am Greg Ewing wrote:
> Nick Coghlan wrote:
> > That's fine - binary floats *are* surprising. That's why Decimal
> > exists in the first place.
>
> This argument could equally well be used the other way --
> someone using Decimal is doing so precisely because they
> *don't* want to be surprised, in which case they would
> probably prefer to get an exception.
Then they're in for a terrible, terrible disappointment. Rounding issues
don't go away because you're using Decimal instead of float, and I
can't imagine anyone would like an exception in the following cases:
>>> Decimal(1)/Decimal(3)*Decimal(3) == Decimal(1)
False
>>> Decimal(2).sqrt()**Decimal(2) == Decimal(2)
False
>>> Decimal(10**28)+Decimal(1)-Decimal(10**28) == Decimal(1)
False
Rounding isn't the only surprise:
>>> x = Decimal("NAN"); x == x
False
Decimals are floats, but using radix 10 instead of radix 2.
--
Steven D'Aprano
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mixing float and Decimal -- thread reboot
On Sun, Mar 21, 2010 at 11:25 AM, Raymond Hettinger wrote: > Right. We should be guided by: > fractions are a superset of decimals which are a superset of binary > floats. But mixed Fraction-float operations return floats, not Fractions. > And by: > binary floats and decimal floats both implement all of the operations > for the Real abstract base class. Sure, but that doesn't help us decide what mixed Decimal-float operations should return. > It seems to me that Decimals and floats should be considered at > the same level (i.e. both implement Real). Agreed, but doesn't help. (Except against the idea that Decimal goes on the "integer" side of Fraction, which is just wrong.) > Mixed Decimal and float should coerce to Decimal because it can be > done losslessly. But mixed Fraction-float returns float even though returning Fraction could be done losslessly. The real criterion should be what's more useful, not what can be done losslessly. > There is no need to embed a notion of "imperfect answer". > Numbers themselves are exact and many mixed operations > can be exact if the coercions go the right way. Division cannot, in general (I consider floor division a bastard child of the integers). And for multiplication it seems that rounding at some point becomes necessary since the alternative would be to use infinite precision. > Some folks who have had bad experiences with representation > error (i.e. 1.1 cannot be exactly represented as a binary float) or > with round-off error (i.e. 1.0 / 7.0 must be rounded) tend to think > of both binary or decimal floats as necessarily inexact. But that > is not the case, exact accounting work is perfectly feasable > with decimals. Remember, the notion of inexactness is a taint, > not an intrinsic property of a type. Even the Scheme numeric > tower recognizes this. LIkewise, the decimal specification also > spells-out this notion as basic to its design. I really don't think advertising Decimal as having exact operations is the right thing to do. Sure, it is the right data type for all accounting operations -- but that is a very specialized use case, where certain round-off errors are desirable (since nobody wants fractional pennies in their bill). > I believe that no "clean-up" is necessary. Decimal already implements > the Real ABC. All that is necessary is the common __hash__ algorithm > and removing the restriction between decimal/float interaction so that > any two instances of Real can interoperate with one another. Call it by any name you want. We're looking at revising the hash function and allowing mixed operations between Decimal and float, with signal that warns about these operations. I see two open issues: whether mixed Decimal-float operations should return Decimal and float, and whether the warning about such operations should be on or off by default. My gut tells me that the signal should be off by default. My gut doesn't say much about whether the result should be float or Decimal, but I want the reasoning to reach a decision to be sound. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mixing float and Decimal -- thread reboot
Raymond Hettinger wrote: Since decimal also allows arbitrary sizes, all long ints can be exactly represented (this was even one of the design goals for the decimal module). There may be something we need to clarify here. I've been imagining that the implicit conversions to Decimal that we're talking about would be done to whatever precision is set in the context. Am I wrong about that? Is the intention to always use enough digits to get an exact representation? -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mixing float and Decimal -- thread reboot
Raymond Hettinger wrote: The question of where to stack decimals in the hierarchy was erroneously being steered by the concept that both decimal and binary floats are intrinsically inexact. But that would be incorrect, inexactness is a taint, the numbers themselves are always exact. I don't think that's correct. "Numbers are always exact" is a simplification due to choosing not to attach an inexactness flag to every value. Without such a flag, we don't really know whether any given value is exact or not, we can only guess. The reason for regarding certain types as "implicitly inexact" is something like this: If you start with exact ints, and do only int operations with them, you must end up with exact ints. But the same is not true of float or Decimal: even if you start with exact values, you can end up with inexact ones. I really like Guido's idea of a context flag to control whether mixing of decimal and binary floats will issue a warning. Personally I feel that far too much stuff concerning decimals is controlled by implicit context parameters. It gives me the uneasy feeling that I don't know what the heck any given decimal operation is going to do. It's probably justified in this case, though. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mixing float and Decimal -- thread reboot
Raymond Hettinger wrote: The question of where to stack decimals in the hierarchy was erroneously being steered by the concept that both decimal and binary floats are intrinsically inexact. But that would be incorrect, inexactness is a taint, the numbers themselves are always exact. I don't think that's correct. "Numbers are always exact" is a simplification due to choosing not to attach an inexactness flag to every value. Without such a flag, we don't really know whether any given value is exact or not, we can only guess. The reason for regarding certain types as "implicitly inexact" is something like this: If you start with exact ints, and do only int operations with them, you must end up with exact ints. But the same is not true of float or Decimal: even if you start with exact values, you can end up with inexact ones. I really like Guido's idea of a context flag to control whether mixing of decimal and binary floats will issue a warning. Personally I feel that far too much stuff concerning decimals is controlled by implicit context parameters. It gives me the uneasy feeling that I don't know what the heck any given decimal operation is going to do. It's probably justified in this case, though. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mixing float and Decimal -- thread reboot
On Mar 21, 2010, at 3:35 PM, Guido van Rossum wrote:
>
>> It seems to me that Decimals and floats should be considered at
>> the same level (i.e. both implement Real).
>
> Agreed, but doesn't help. (Except against the idea that Decimal goes
> on the "integer" side of Fraction, which is just wrong.)
Woohoo! Glad you agree.
I was concerned that idea
was gathering a following.
>
>> There is no need to embed a notion of "imperfect answer".
>> Numbers themselves are exact and many mixed operations
>> can be exact if the coercions go the right way.
>
> Division cannot, in general (I consider floor division a bastard child
> of the integers). And for multiplication it seems that rounding at
> some point becomes necessary since the alternative would be to use
> infinite precision.
Perception here is probably dictated by the use case of the beholder :-)
In the accounting world, such operations are very common (part of
getting three apples for one dollar recorded as 0.33, 0.33, and 0.34
in the individual apple accounts). Cost allocation tools use floor
division all the time. Amortization computations always have to
take into account that real payments and interest charges do not have
fractional pennies (or sometimes fractional dollars) and have to
readjust the amortization accordingly (usually with small roundings
to the interest charges and a small adjustment to the final payment).
> Call it by any name you want. We're looking at revising the hash
> function and allowing mixed operations between Decimal and float, with
> signal that warns about these operations. I see two open issues:
> whether mixed Decimal-float operations should return Decimal and
> float, and whether the warning about such operations should be on or
> off by default. My gut tells me that the signal should be off by
> default. My gut doesn't say much about whether the result should be
> float or Decimal, but I want the reasoning to reach a decision to be
> sound.
My vote is for:
decimal + float --> decimal
and to emit a warning by default.
Reasoning for coercion to decimal:
1) decimal + float can be done losslessly and meaningfully
2) decimal/float comparisons can give a useful and non-confusing result for:
1.1 == Decimal('1.1')
This needs to return False since the two values:
a) have different hash values (under either proposal) and
b) are in-fact, not equal
But, if the decimal were coerced to a binary float, the relation would return
True:
>>> float(decimal.Decimal('1.1')) == 1.1
True
This is bad.
Reasoning for emitting a warning by default:
1) Real actual use cases for mixed decimal / float operations are rare.
2) But accidental mixed decimal / float is an easy mistake to make.
3) Implicit coercion hides the error.
4) A warning flag gives you a chance to catch your error.
5) A warning is educational (it makes sure that you understand
what your program is doing)
6). A warning is easily silenced either through a) the warnings module,
b) setting a context flag in decimal, or c) by making the coercion explicit
using Decimal.from_float().
Raymond
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mixing float and Decimal -- thread reboot
On Mon, 22 Mar 2010 06:31:57 am Raymond Hettinger wrote: > I really like Guido's idea of a context flag to control whether > mixing of decimal and binary floats will issue a warning. > The default should be to issue the warning (because unless > you know what you're doing, it is most likely an error). When you say "warning", do you mean warning.warn(), or an exception? I'd like to put in a vote for allowing naive users with low requirements for accuracy and precision to be able to type something like this in the interactive interpreter: >>> Decimal(1) + 1.0 and get two (in whatever type is decided on) without having to change the context or deal with an exception. Yes, this means that they may be surprised if they perform an operation which suffers from rounding errors, but that's no worse than what happens with floats. If naive users are going to use the interpreter as a calculator, they're going to start off using floats and ints simply because they require less typing. My idea is to allow a gentle learning curve with Decimal (and Fraction) without scaring them off with exceptions or excessive warnings: a single warning per session would be okay, a warning after every operation would be excessive in my opinion, and exceptions by default would be right out. -- Steven D'Aprano ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal & amp; lt; -& amp; gt; float comparisons in py3k.
Steven D'Aprano wrote: Then they're in for a terrible, terrible disappointment. Rounding issues don't go away because you're using Decimal instead of float, No, but what I mean is that they prefer to be surprised in unsurprising ways, so to speak. Everyone knows that floating point numbers have limited precision. What really surprises people is when *binary* floating point numbers behave differently from the decimal ones they're used to. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mixing float and Decimal -- thread reboot
On Mar 21, 2010, at 3:50 PM, Greg Ewing wrote:
> Raymond Hettinger wrote:
>
>> Since decimal also allows arbitrary sizes, all long ints can be
>> exactly represented (this was even one of the design goals
>> for the decimal module).
>
> There may be something we need to clarify here. I've been
> imagining that the implicit conversions to Decimal that
> we're talking about would be done to whatever precision
> is set in the context. Am I wrong about that?
Yes. The conversion to decimal is independent of the
current context.
The background docs for the decimal module makes its design
intention clear. All numbers are exact. Rounding and context
adjustments only apply to the *results (of operations.
The module is designed that way. Its background documents
confirm that viewpoint. And its operations are designed to support
that world view (i.e. unary plus is an operation that can change a
value). Also, we confirmed that point-of-view with the person
who wrote the spec.
> Is the intention
> to always use enough digits to get an exact representation?
Yes. That is in-fact what Decimal.fromfloat() does.
That agrees with the decimal constructor itself which is not context sensitive:
>>> decimal.getcontext().prec = 5
>>> decimal.Decimal('3.1415926535')# Notice this value doesn't get
rounded
Decimal('3.1415926535')
>>> decimal.Decimal('3.1415926535') + 0 # This result does get rounded.
Decimal('3.1416')
>>> # Also, rounding does not get applied during an equality check
>>> decimal.getcontext().prec = 5
>>> decimal.Decimal('3.1415926535') == decimal.Decimal('3.1416')
False
Raymond
P.S. Thanks for asking the question.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mixing float and Decimal -- thread reboot
On Mar 21, 2010, at 3:59 PM, Steven D'Aprano wrote: > On Mon, 22 Mar 2010 06:31:57 am Raymond Hettinger wrote: >> I really like Guido's idea of a context flag to control whether >> mixing of decimal and binary floats will issue a warning. >> The default should be to issue the warning (because unless >> you know what you're doing, it is most likely an error). > > When you say "warning", do you mean warning.warn(), or an exception? I'm not sure I understand your question. I did mean warnings.warn(). But that does raise a catchable exception or it can be suppressed through the warnings module. It should probably be set to warn no more than once. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mixing float and Decimal -- thread reboot
On Sun, Mar 21, 2010 at 4:16 PM, Raymond Hettinger wrote: > > On Mar 21, 2010, at 3:59 PM, Steven D'Aprano wrote: > >> On Mon, 22 Mar 2010 06:31:57 am Raymond Hettinger wrote: >>> I really like Guido's idea of a context flag to control whether >>> mixing of decimal and binary floats will issue a warning. >>> The default should be to issue the warning (because unless >>> you know what you're doing, it is most likely an error). >> >> When you say "warning", do you mean warning.warn(), or an exception? > > > I'm not sure I understand your question. I did mean warnings.warn(). > But that does raise a catchable exception or it can be suppressed > through the warnings module. It should probably be set to > warn no more than once. I would hope it could use whatever mechanism is already used for other conditions in the decimal module such as Underflow, Inexact, Rounded etc. But I have to admit I don't know exactly what those do. It appears they can either raise an exception or call a handle() method on the given exception. Are you thinking of putting the warn() call inside that handle() method? -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mixing float and Decimal -- thread reboot
On Mar 21, 2010, at 6:24 PM, Guido van Rossum wrote: > On Sun, Mar 21, 2010 at 4:16 PM, Raymond Hettinger > wrote: >> >> On Mar 21, 2010, at 3:59 PM, Steven D'Aprano wrote: >> >>> On Mon, 22 Mar 2010 06:31:57 am Raymond Hettinger wrote: I really like Guido's idea of a context flag to control whether mixing of decimal and binary floats will issue a warning. The default should be to issue the warning (because unless you know what you're doing, it is most likely an error). >>> >>> When you say "warning", do you mean warning.warn(), or an exception? >> >> >> I'm not sure I understand your question. I did mean warnings.warn(). >> But that does raise a catchable exception or it can be suppressed >> through the warnings module. It should probably be set to >> warn no more than once. > > I would hope it could use whatever mechanism is already used for other > conditions in the decimal module such as Underflow, Inexact, Rounded > etc. But I have to admit I don't know exactly what those do. It > appears they can either raise an exception or call a handle() method > on the given exception. Are you thinking of putting the warn() call > inside that handle() method? Yes. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mixing float and Decimal -- thread reboot
On Sun, Mar 21, 2010 at 16:59, Steven D'Aprano wrote: > If naive users are going to use the interpreter as a calculator, they're > going to start off using floats and ints simply because they require > less typing. My idea is to allow a gentle learning curve with Decimal > (and Fraction) without scaring them off with exceptions or excessive > warnings: a single warning per session would be okay, a warning after > every operation would be excessive in my opinion, and exceptions by > default would be right out. That strikes me as a passive-aggressive way of saying we tolerate it for interactive use, but don't you dare mix them for real programs. A warning should be regarded as a bug in real programs — unless it's a transitional measure — so it might as well be an exception. Don't guess and all that. -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
