On 9/26/2018 7:26 AM, j...@math.brown.edu wrote:
To paraphrase:
1. Where was the 3.0 change discussed?
2. What was the rationale?
I think these have been answered as well as possible.
3. Can the change be reverted?
It 'could be', but will not be reverted?
4. Should something be added to the d
On Wed, Sep 26, 2018 at 7:29 AM wrote:
>
> I recently found out about Python 3's round-to-even change (via
> https://github.com/cosmologicon/pywat!) and am having trouble finding
> where that change was discussed.
That GitHub project is hilarious especially the NaN stuff...
Rounding is from engi
On Mon, Oct 1, 2018 at 9:36 AM Steven D'Aprano wrote:
> Then we can add a keyword only argument to round:
>
> round(number, ndigits=0, *, mode=ROUND_HALF_EVEN)
>
> To use it, you can import the rounding mode you want from math:
>
> from math import ROUND_CEILING
> round(x, 3, mode=ROUN
On Mon, Oct 01, 2018 at 10:50:36AM +1300, Greg Ewing wrote:
> Alex Walters wrote:
> >Other use case is finance, where you can end up with interest calculations
> >that are fractional of the base unit of currency. US$2.345 is impossible
> >to
> >represent in real currency, so it has to be rounded.
On 9/30/18 6:15 PM, Greg Ewing wrote:
> Chris Angelico wrote:
>> ]That
>> means that any representable number actually has to indicate a range
>> of values centered on that value.
>
> That's not always true -- it depends on the source of the
> information. For example, a reading of 5 seconds on a c
On Mon, Oct 1, 2018 at 8:17 AM Greg Ewing wrote:
>
> Chris Angelico wrote:
> > ]That
> > means that any representable number actually has to indicate a range
> > of values centered on that value.
>
> That's not always true -- it depends on the source of the
> information. For example, a reading of
Chris Angelico wrote:
]That
means that any representable number actually has to indicate a range
of values centered on that value.
That's not always true -- it depends on the source of the
information. For example, a reading of 5 seconds on a clock
with 1 second resolution actually represents a
Steven D'Aprano wrote:
(It's also called Dutch Rounding.)
Oh, so *that's* why Python does it! Fair enough. :-)
Similarly for differences. If you perform many subtractions (let's say
you are paying off a loan, and calculating interest, then rounding to
the nearest cent) you have to care about
Alex Walters wrote:
Other use case is finance, where you can end up with interest calculations
that are fractional of the base unit of currency. US$2.345 is impossible to
represent in real currency, so it has to be rounded.
This brings us back to my original point about floating point
accuracy
On Sun, Sep 30, 2018 at 10:18 PM Steven D'Aprano wrote:
>
> On Sat, Sep 29, 2018 at 09:40:03PM -0400, Alex Walters wrote:
> > My experience and that of many users of
> > the python irc channel on freenode is that round-half-to-even is not the
> > intuitive, or even desired, behavior - round-half-u
On Sat, Sep 29, 2018 at 09:40:03PM -0400, Alex Walters wrote:
> ...and we have a stats module that would be a great place for a round
> function that needs to cancel rounding errors.
This has nothing to do with statistics.
You should consider that this is often called "Banker's Rounding" and
wh
> -Original Message-
> From: Python-Dev list=sdamon@python.org> On Behalf Of Greg Ewing
> Sent: Saturday, September 29, 2018 9:50 PM
> To: python-dev@python.org
> Subject: Re: [Python-Dev] Change in Python 3's "round" behavior
>
> I don't really get the statistical argument. If you
12 matches
Mail list logo
