This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mark.dickinson
Recipients mark.dickinson, serhiy.storchaka, skrah, tom.pohl
Date 2012-11-12.09:52:20
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1352713941.35.0.384348329926.issue16460@psf.upfronthosting.co.za>
In-reply-to
Content
Tom: there's no reasonable way to define all 3 of /, // and % for floating-point numbers that avoids all user surprises.  There are a couple of notes (nos 2 and 3) at the bottom of the documentation page you refer to that attempt to explain some of the potential difficulties here.

> I cannot think of a reasonable use case for the floor division.

Indeed, one has to be careful when using floating-point for *anything* where tiny numerical errors can significant:  rounding is another example of this.

What's your application?  There may be better ways of doing what you're trying to do.  If you're working with financial data, you might want to look at the decimal module.  If you're working with Python floats (or floating-point arithmetic in *any* programming language), your code has to be robust in the face of small errors.

> math.floor(1/0.1) returns the expected 10.0

Yep.  What happens here is that the exact result of 1 / 0.1 is just a touch under 10.0, but the closest representable float to that exact result is 10.0 itself.  So the result of the division is rounded up to 10.0, and then the floor returns 10.0

> and the doc says that the floor division should behave the same.

Where do the docs say that?
History
Date User Action Args
2012-11-12 09:52:21mark.dickinsonsetrecipients: + mark.dickinson, skrah, serhiy.storchaka, tom.pohl
2012-11-12 09:52:21mark.dickinsonsetmessageid: <1352713941.35.0.384348329926.issue16460@psf.upfronthosting.co.za>
2012-11-12 09:52:21mark.dickinsonlinkissue16460 messages
2012-11-12 09:52:20mark.dickinsoncreate