On 01/10/18 21:45, Michael Felt wrote:
On 9/30/2018 2:17 PM, Steven D'Aprano wrote:
(It's also called Dutch Rounding.)
Ah - as to why - and from school! (as so-called intuitive! rather desired!).
A test score goes from 5.5 to 6.0 - which becomes passing.
Oh, do I recall my children's
On 9/30/2018 2:17 PM, Steven D'Aprano wrote:
> (It's also called Dutch Rounding.)
Ah - as to why - and from school! (as so-called intuitive! rather desired!).
A test score goes from 5.5 to 6.0 - which becomes passing.
Oh, do I recall my children's frustrations when they had a X.4Y score -
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
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
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,
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
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
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
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
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
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
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 -
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
> -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 r
I don't really get the statistical argument. If you're doing something
like calculating an average and care about accuracy, why are you rounding
the values before averaging? Why not average first and then round the
result if you need to?
--
Greg
___
> -Original Message-
> From: Python-Dev list=sdamon@python.org> On Behalf Of Steven D'Aprano
> Sent: Thursday, September 27, 2018 9:54 AM
> To: python-dev@python.org
> Subject: Re: [Python-Dev] Change in Python 3's "round" behavior
>
> On Thu
Greg Ewing writes:
> (BTW, how do you provide a citation for "common knowledge"?-)
Aumann, Robert J. [1976], "Agreeing to Disagree." Annals of
Statistics 4, pp. 1236-1239
is what I usually use. :-)
___
Python-Dev mailing list
Python-Dev@python.org
On Thu, Sep 27, 2018 at 05:55:07PM +1200, Greg Ewing wrote:
> j...@math.brown.edu wrote:
> >I understand from
> >https://github.com/cosmologicon/pywat/pull/40#discussion_r219962259
> >that "to always round up... can theoretically skew the data"
>
> *Very* theoretically. If the number is even a
j...@math.brown.edu wrote:
I understand from
https://github.com/cosmologicon/pywat/pull/40#discussion_r219962259
that "to always round up... can theoretically skew the data"
*Very* theoretically. If the number is even a whisker bigger than
2.5 it's going to get rounded up regardless:
>>>
On Wed, Sep 26, 2018 at 07:26:17AM -0400, j...@math.brown.edu wrote:
> I did find the revealingly-invalid bug report
> https://bugs.python.org/issue32956 ("python 3 round bug"), so I asked
> there, but wanted to invite anyone else on this list who might be
> interested to help.
What about those
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.
I did find the revealingly-invalid bug report
https://bugs.python.org/issue32956 ("python 3 round bug"), so I asked
there, but
21 matches
Mail list logo
