[Python-announce] rounder: A Python package for rounding numbers in complex objects

[1, 2, 3]}) {'a': 9, 'b': [1, 4, 9]} The package works with objects of many different types, not only those shown above. It works under both Windows and Linux. You can install it from PyPi: $ pip install rounder You will learn more about it from its GitHub repo: https://github.com/nyggus/rounder. Happy

[issue46187] Optionally support rounding for math.isqrt()

Mark Dickinson added the comment: Ah, https://math.mit.edu/research/highschool/primes/materials/2019/Gopalakrishna.pdf is interesting - they conjecture a bound on the number of iterations required, and note that under that conjecture the mod can be replaced by a subtraction. --

[issue46187] Optionally support rounding for math.isqrt()

Mark Dickinson added the comment: Thanks, Tim; very interesting. I hadn't seen this factoring algorithm before. > That wants the _ceiling_ of the square root. Looks like what it actually wants is the ceiling analog of isqrtrem: that is, it needs both the ceiling of the square root *and* the

[issue46187] Optionally support rounding for math.isqrt()

Tim Peters added the comment: I've been keeping my eyes open. The only mariginally relevant thing I've noticed is Hart's "one line factoring" method: http://wrap.warwick.ac.uk/54707/1/WRAP_Hart_S1446788712000146a.pdf That wants the _ceiling_ of the square root. And in another place it wants

[issue46467] Rounding 5, 50, 500 behaves differently depending on preceding value

Steven D'Aprano added the comment: As documented, this is not a bug. "if two multiples are equally close, rounding is done toward the even choice" https://docs.python.org/3/library/functions.html#round This is also called "Banker's Rounding" or "Round half to eve

[issue46467] Rounding 5, 50, 500 behaves differently depending on preceding value

Spencer Brown added the comment: This is intentional behaviour, if the value is 5 it rounds towards even as documented here: https://docs.python.org/3/library/functions.html#round The reason is so that if you have a bunch of random data, rounding won't slightly bias the result upward

[issue46467] Rounding 5, 50, 500 behaves differently depending on preceding value

. -- components: Interpreter Core messages: 411222 nosy: adam.ulrich priority: normal severity: normal status: open title: Rounding 5,50,500 behaves differently depending on preceding value type: behavior versions: Python 3.10 ___ Python tracker <ht

[issue46187] Optionally support rounding for math.isqrt()

Tim Peters added the comment: > Is > > i, rem = isqrt_rem(n) > i + (rem != 0) > > better than > > (isqrt(n<<2) + 1) >> 1 > > or > > n and isqrt(n-1) + 1 > > ? Define "better"? The first way is by far the most obvious of the three, and the second way the least obvious. The first way

[issue46187] Optionally support rounding for math.isqrt()

Serhiy Storchaka added the comment: Is i, rem = isqrt_rem(n) i + (rem != 0) better than (isqrt(n<<2) + 1) >> 1 or n and isqrt(n-1) + 1 ? As for use cases, there were few cases in my experience when I needed the ceiling square root, mostly in simple experiments in REPL, but

[issue46187] Optionally support rounding for math.isqrt()

extended precision functions via scaled integer arithmetic is quite niche, and anyone numerically knowledgeable enough to pull that off will have no trouble figuring out how to roll their own isqrt rounding. For them, isqrtrem would make it dead easy. Close to no demonstrated demand

[issue46187] Optionally support rounding for math.isqrt()

Raymond Hettinger added the comment: > divmod() allows easy emulation of any division rounding mode It could be used that way, but generally isn't. Please consider my original request. Adding a keyword argument is easy, clear, and has almost no mental overhead. It reads very w

[issue46187] Optionally support rounding for math.isqrt()

Case Van Horsen added the comment: FWIW, gmpy2 uses isqrt_rem. Of course, gmpy2 uses underscores a lot. And uses next_toward instead of nextafter, and copy_sign instead of copysign, and is_nan instead of isnan... :( I would keep the math module consistent and use isqrtrem. I'll look at

[issue46187] Optionally support rounding for math.isqrt()

t; integer division Speaking of which, the analogy to divmod extends just beyond the lack of an underscore in the name ;-) divmod() allows easy emulation of any division rounding mode, and an instant answer to "was the division exact?". isqrtrem() would supp

[issue46187] Optionally support rounding for math.isqrt()

Mark Dickinson added the comment: > Mark didn't mention his use case for rounded isqrt Mainly for emulation of floating-point sqrt. But the number of times I've needed rounded integer square root is small compared with the number of times I've needed rounded integer division. --

[issue46187] Optionally support rounding for math.isqrt()

Mark Dickinson added the comment: A new function isqrt_rem seems like a reasonably natural addition. (Though I'd call it "isqrtrem", partly by analogy with "divmod", and partly because the math module isn't very good at doing underscores.) -- ___

[issue46187] Optionally support rounding for math.isqrt()

Tim Peters added the comment: Suppose we added isqrt_rem(n), returning the integer pair (i, rem) such that n == i**2 + rem 0 <= rem <= 2*i Then: - Want the floor of sqrt(n)? i. - The ceiling? i + (rem != 0). - Rounded? i + (rem > i). - Is n a perfect square? not rem. That's how mpz

[issue46187] Optionally support rounding for math.isqrt()

, just truncated, and a _different_ function that returns not only isqrt(n), but also "the remainder" (n - isqrt(n)**2). The latter shows they're not averse to adding cruft that can easily be done - which makes it all the more suggestive that they _didn't_ also add other rounding mo

[issue46187] Optionally support rounding for math.isqrt()

Raymond Hettinger added the comment: So, are you going to reject my feature request? I don't understand why. Both Mark and I have had valid use cases. The implementation is straight-forward and simple. The workaround is slow and non-obvious. The default remains the same so that

[issue46187] Optionally support rounding for math.isqrt()

Tim Peters added the comment: Pretend this were the itertools module and you were responding to someone suggesting a new optional argument to one of its functions. You have tons of experience rejecting those, and much the same arguments apply, from "not every one-line function needs to be

[issue46187] Optionally support rounding for math.isqrt()

Raymond Hettinger added the comment: > I'd similarly prefer to see recipes in the docs. Can you elaborate on why you prefer having this in the docs rather than as built-in functionality? For me, the rounded case would be the most common. I don't think I'm better-off writing a wrapper with

[issue46187] Optionally support rounding for math.isqrt()

Tim Peters added the comment: [Mark] > The idea is no more than: "compute an extra bit, then use > that extra bit to determine which way to round". Thanks! Despite that this is what the derivation I sketched boiled down to, I was still missing how general the underlying principle was. Duh!

[issue46187] Optionally support rounding for math.isqrt()

Mark Dickinson added the comment: > I'd be happy to see recipes added to the docs for rounded and ceiling flavors > of isqrt, but am dubious about the value of building them in. I'd similarly prefer to see recipes in the docs. We already have such a recipe for ceil(√n). --

[issue46187] Optionally support rounding for math.isqrt()

Mark Dickinson added the comment: > did you invent this? The idea is no more than: "compute an extra bit, then use that extra bit to determine which way to round". More generally, for any real number x, the nearest integer to x (rounding ties towards +infinity) is `⌊(⌊2x⌋ + 1

[issue46187] Optionally support rounding for math.isqrt()

Tim Peters added the comment: All cool. Since I doubt these new rounding modes will get much use anyway, it's not worth arguing about. If I were to do this for myself, the rounding argument would be one of the three values {-1, 0, +1}, which are already more than good enough as mnemonics

[issue46187] Optionally support rounding for math.isqrt()

t(x)). If those are the starting point, then round, floor, and ceil are a logical progression from the existing code. It is also consistent with how the numeric tower approaches various ways of rounding. -- ___ Python tracker <https://bugs.pyth

[issue46187] Optionally support rounding for math.isqrt()

Tim Peters added the comment: FYI, I had a simpler derivation in mind. Say sqrt(n) = r + f where r = isqrt(n) and 0 <= f < 1. Then sqrt(4n) = 2 * sqrt(n) = 2*(r + f) = 2r + 2f, with 0 <= 2f < 2. If f < 0.5, 2f < 1, so isqrt(4n) = 2r, and we shouldn't round r up either. If f > 0.5, 2f > 1,

[issue46187] Optionally support rounding for math.isqrt()

Tim Peters added the comment: >> can we use the decimal module's names for the supported >> rounding modes? > I'm not sure those make sense because we never get to > exactly half. There is only floor, ceil, and round, > not half_up, half_even, etc. So use de

[issue46187] Optionally support rounding for math.isqrt()

red roots y, y+1, and y+1. > can we use the decimal module's names for the supported rounding modes? I'm not sure those make sense because we never get to exactly half. There is only floor, ceil, and round, not half_up, half_even, etc. -- ___

[issue46187] Optionally support rounding for math.isqrt()

e of building them in. If they are added via an optional rounding argument, can we use the decimal module's names for the supported rounding modes? -- ___ Python tracker <https://bugs.

[issue46187] Optionally support rounding for math.isqrt()

Mark Dickinson added the comment: FWIW, when this need has turned up for me (which it has, a couple of times), I've used this: def risqrt(n): return (isqrt(n<<2) + 1) >> 1 But I'll admit that that's a bit non-obvious. -- ___ Python tracker

[issue46187] Optionally support rounding for math.isqrt()

t(x * scale) s.append(x) return s -- assignee: mark.dickinson components: Library (Lib) messages: 409243 nosy: mark.dickinson, rhettinger, tim.peters priority: normal severity: normal status: open title: Optionally support rounding for math.isqrt() type: enhancement versi

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

hat to make people aware of danger of float comparison, > not because I was not understanding what happened. And I posted to show that equality is not the problem, and that float comparison is not dangerous. > We can see there is a difference on the lsb, due to rounding. > >

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

of danger of float comparison, not because I was not understanding what happened. We can see there is a difference on the lsb, due to rounding. >>> (0.3+0.3+0.3).hex() '0x1.cp-1' >>> 0.9.hex() '0x1.dp-1' >>> An isclose() function

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

On 22/11/21 4:58 am, Grant Edwards wrote: Yep, IIRC, it was a 4 bit processor because 4 bits is what it takes to represent one decimal digit. That was the Saturn, first used in the HP-71B. The original architecture (known as the "Nut")was weirder than that. It operated serially on 56 bit words

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

On 2021-11-22 05:43:48 +1100, Chris Angelico wrote: > On Mon, Nov 22, 2021 at 5:42 AM Peter J. Holzer wrote: > > (I think I used Math::BigRat in Perl, but I've been > > programming in Perl for a lot longer.) > > Rodents Of Unusual Size? I don't think they exist...

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

On 2021-11-21 10:57:55 +1100, Chris Angelico wrote: > And if decimal floating point were common, other "surprise" behaviour > would be cited, like how x < y and (x+y)/2 < x. Yup. Took me a bit to find an example, but this can happen. My HP-48 calculator uses a mantissa of 12 decimal digits.

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

On Mon, Nov 22, 2021 at 5:42 AM Peter J. Holzer wrote: > (I think I used Math::BigRat in Perl, but I've been > programming in Perl for a lot longer.) > Rodents Of Unusual Size? I don't think they exist... ChrisA -- https://mail.python.org/mailman/listinfo/python-list

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

On 2021-11-20 03:25:53 +, Ben Bacarisse wrote: > Chris Angelico writes: > > > It does mean exactly what it meant in grade school, just as 1/3 means > > exactly what it meant in grade school. Now try to represent 1/3 on a > > blackboard, as a decimal fraction. If that's impossible, does it

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

ould like to report the following issue: > > > > > > > > Working with floats i noticed that: > > > > > > > > int(23.99/12) returns 1, and > > > > int(23.999/12) returns 2 > > > > > > > > This implies that

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

On 2021-11-21, Greg Ewing wrote: > On 21/11/21 2:18 pm, Grant Edwards wrote: >> My recollection is that it was quite common back in the days before FP >> hardware was "a thing" on small computers. CPM and DOS compilers for >> various languages often gave the user a choice between binary FP and >>

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

On 21/11/21 2:18 pm, Grant Edwards wrote: My recollection is that it was quite common back in the days before FP hardware was "a thing" on small computers. CPM and DOS compilers for various languages often gave the user a choice between binary FP and decimal (BCD) FP. It's also very common for

RE: Unexpected behaviour of math.floor, round and int functions (rounding)

- From: Python-list On Behalf Of Chris Angelico Sent: Saturday, November 20, 2021 8:03 PM To: python-list@python.org Subject: Re: Unexpected behaviour of math.floor, round and int functions (rounding) On Sun, Nov 21, 2021 at 11:39 AM Avi Gross via Python-list wrote: > > Can I suggest

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

On Sun, Nov 21, 2021 at 1:20 PM Rob Cliffe via Python-list wrote: > > > > On 21/11/2021 01:02, Chris Angelico wrote: > > > > If you have a number with a finite binary representation, you can > > guarantee that it can be represented finitely in decimal too. > > Infinitely repeating expansions come

RE: Unexpected behaviour of math.floor, round and int functions (rounding)

abort when the cycle is seen to be repeating. Another is to leave when the result seems close enough. However, my comments about over/underflow may apply here as enough iterations with representable numbers may at some point result in the kind of rounding error that warps the results of further ca

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

On 21/11/2021 01:02, Chris Angelico wrote: If you have a number with a finite binary representation, you can guarantee that it can be represented finitely in decimal too. Infinitely repeating expansions come from denominators that are coprime with the numeric base. Not quite, e.g. 1/14 is

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

On Sun, Nov 21, 2021 at 12:56 PM Avi Gross via Python-list wrote: > > Not at all, Robb. I am not intending to demean Mathematicians as one of my > degrees is in that subject and I liked it. I mean that some things in > mathematics are not as intuitive to people when they first encounter them,

RE: Unexpected behaviour of math.floor, round and int functions (rounding)

ply is not expected to apply for a non-abelian case. -Original Message- From: Python-list On Behalf Of Rob Cliffe via Python-list Sent: Saturday, November 20, 2021 6:19 PM To: Subject: Re: Unexpected behaviour of math.floor, round and int functions (rounding) On 20/11/2021 22:59, Avi Gross

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

On 2021-11-21, Chris Angelico wrote: >> I think there have been attempts to use a decimal representation in some >> accounting packages or database applications that allow any decimal numbers >> to be faithfully represented and used in calculations. Generally this is not >> a very efficient

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

On Sun, Nov 21, 2021 at 11:39 AM Avi Gross via Python-list wrote: > > Can I suggest a way to look at it, Grant? > > In base 10, we represent all numbers as the (possibly infinite) sum of ten > raised to some integral power. Not infinite. If you allow an infinite sequence of digits, you create

RE: Unexpected behaviour of math.floor, round and int functions (rounding)

-list On Behalf Of Grant Edwards Sent: Saturday, November 20, 2021 5:24 PM To: python-list@python.org Subject: Re: Unexpected behaviour of math.floor, round and int functions (rounding) On 2021-11-20, Ben Bacarisse wrote: > You seem to be agreeing with me. It's the floating point p

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

On Sun, Nov 21, 2021 at 10:55 AM Ben Bacarisse wrote: > > Grant Edwards writes: > > > On 2021-11-20, Ben Bacarisse wrote: > > > >> You seem to be agreeing with me. It's the floating point part that is > >> the issue, not the base itself. > > > > No, it's the base. Floating point can't

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

Grant Edwards writes: > On 2021-11-20, Ben Bacarisse wrote: > >> You seem to be agreeing with me. It's the floating point part that is >> the issue, not the base itself. > > No, it's the base. Floating point can't represent 3/10 _because_ it's > base 2 floating point. Floating point in base 10

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

ues using a computer to deal with stored > numbers, perhaps not stored 100% perfectly as discussed, and doing > calculations. The result often comes out more precisely than warranted. I > suspect there are modules out there that might do multi-step calculations > where at each step, numb

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

On 20/11/2021 22:59, Avi Gross via Python-list wrote: there are grey lines along the way where some mathematical proofs do weird things like IGNORE parts of a calculation by suggesting they are going to zero much faster than other parts and then wave a mathematical wand about what happens when

RE: Unexpected behaviour of math.floor, round and int functions (rounding)

suspect there are modules out there that might do multi-step calculations where at each step, numbers generated with extra precision are throttled back so the extra precision is set to zeroes after rounding to avoid the small increments adding up. Others may just do the calculations and keep track and rem

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

On Sun, Nov 21, 2021 at 9:22 AM Grant Edwards wrote: > > On 2021-11-20, Chris Angelico wrote: > > > But you learn that it isn't the same as 1/3. That's my point. You > > already understand that it is *impossible* to write out 1/3 in > > decimal. Is it such a stretch to discover that you cannot

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

On 2021-11-20, Ben Bacarisse wrote: > You seem to be agreeing with me. It's the floating point part that is > the issue, not the base itself. No, it's the base. Floating point can't represent 3/10 _because_ it's base 2 floating point. Floating point in base 10 doesn't have any problem

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

On 2021-11-20, Chris Angelico wrote: > But you learn that it isn't the same as 1/3. That's my point. You > already understand that it is *impossible* to write out 1/3 in > decimal. Is it such a stretch to discover that you cannot write 3/10 > in binary? For many people, it seems to be. There

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

as late as possible, but even those cannot handle many numbers. More likely it would just store rationals as rationals - or, in other words, fractions.Fraction(). > So the reality is that most computer programming is ultimately BINARY as in > BASE 2. At some level almost anyth

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

On Sun, Nov 21, 2021 at 6:51 AM Ben Bacarisse wrote: > > Chris Angelico writes: > > > On Sat, Nov 20, 2021 at 3:41 PM Ben Bacarisse wrote: > >> > >> Chris Angelico writes: > >> > >> > On Sat, Nov 20, 2021 at 12:43 PM Ben Bacarisse > >> > wrote: > >> >> > >> >> Chris Angelico writes: > >> >>

RE: Unexpected behaviour of math.floor, round and int functions (rounding)

s evaluation as late as possible, but even those cannot handle many numbers. So the reality is that most computer programming is ultimately BINARY as in BASE 2. At some level almost anything is rounded and imprecise. About all we want to guarantee is that any rounding or truncation done is a

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

Chris Angelico writes: > On Sat, Nov 20, 2021 at 3:41 PM Ben Bacarisse wrote: >> >> Chris Angelico writes: >> >> > On Sat, Nov 20, 2021 at 12:43 PM Ben Bacarisse >> > wrote: >> >> >> >> Chris Angelico writes: >> >> >> >> > On Sat, Nov 20, 2021 at 9:07 AM Ben Bacarisse >> >> > wrote: >> >>

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

On Sat, Nov 20, 2021 at 3:41 PM Ben Bacarisse wrote: > > Chris Angelico writes: > > > On Sat, Nov 20, 2021 at 12:43 PM Ben Bacarisse wrote: > >> > >> Chris Angelico writes: > >> > >> > On Sat, Nov 20, 2021 at 9:07 AM Ben Bacarisse > >> > wrote: > >> >> > >> >> Chris Angelico writes: > >> >>

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

Chris Angelico writes: > On Sat, Nov 20, 2021 at 12:43 PM Ben Bacarisse wrote: >> >> Chris Angelico writes: >> >> > On Sat, Nov 20, 2021 at 9:07 AM Ben Bacarisse wrote: >> >> >> >> Chris Angelico writes: >> >> >> >> > On Sat, Nov 20, 2021 at 5:08 AM ast wrote: >> >> >> >> >> >>> 0.3 + 0.3

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

On Sat, Nov 20, 2021 at 12:43 PM Ben Bacarisse wrote: > > Chris Angelico writes: > > > On Sat, Nov 20, 2021 at 9:07 AM Ben Bacarisse wrote: > >> > >> Chris Angelico writes: > >> > >> > On Sat, Nov 20, 2021 at 5:08 AM ast wrote: > >> > >> >> >>> 0.3 + 0.3 + 0.3 == 0.9 > >> >> False > >> > >

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

Chris Angelico writes: > On Sat, Nov 20, 2021 at 9:07 AM Ben Bacarisse wrote: >> >> Chris Angelico writes: >> >> > On Sat, Nov 20, 2021 at 5:08 AM ast wrote: >> >> >> >>> 0.3 + 0.3 + 0.3 == 0.9 >> >> False >> > >> > That's because 0.3 is not 3/10. It's not because floats are >> >

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

On 20/11/2021 10.21, Chris Angelico wrote: > On Sat, Nov 20, 2021 at 7:39 AM dn via Python-list > wrote: >>> 0.3 + 0.3 + 0.3 == 0.9 False >>> >>> That's because 0.3 is not 3/10. It's not because floats are >>> "unreliable" or "inaccurate". It's because the ones you're entering >>> are

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

On Sat, Nov 20, 2021 at 9:07 AM Ben Bacarisse wrote: > > Chris Angelico writes: > > > On Sat, Nov 20, 2021 at 5:08 AM ast wrote: > > >> >>> 0.3 + 0.3 + 0.3 == 0.9 > >> False > > > > That's because 0.3 is not 3/10. It's not because floats are > > "unreliable" or "inaccurate". It's because the

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

Chris Angelico writes: > On Sat, Nov 20, 2021 at 5:08 AM ast wrote: >> >>> 0.3 + 0.3 + 0.3 == 0.9 >> False > > That's because 0.3 is not 3/10. It's not because floats are > "unreliable" or "inaccurate". It's because the ones you're entering > are not what you think they are. > > When will

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

On Sat, Nov 20, 2021 at 7:39 AM dn via Python-list wrote: > >> >>> 0.3 + 0.3 + 0.3 == 0.9 > >> False > > > > That's because 0.3 is not 3/10. It's not because floats are > > "unreliable" or "inaccurate". It's because the ones you're entering > > are not what you think they are. > > > > When will

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

On 20/11/2021 09.17, Chris Angelico wrote: > On Sat, Nov 20, 2021 at 5:08 AM ast wrote: >> Le 19/11/2021 à 03:51, MRAB a écrit : >>> On 2021-11-19 02:40, 2qdxy4rzwzuui...@potatochowder.com wrote: On 2021-11-18 at 23:16:32 -0300, René Silva Valdés wrote: > Working with floats i

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

; Hello, I would like to report the following issue: > >>> > >>> Working with floats i noticed that: > >>> > >>> int(23.99/12) returns 1, and > >>> int(23.999/12) returns 2 > >>> > >>> This implies that int(

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

This implies that int() function is rounding ... It's not int() that's doing the rounding; that second numerator is being rounded before being divided by 12: Python 3.9.7 (default, Oct 10 2021, 15:13:22) [GCC 11.1.0] on linux Type "help", "copyright", "credi

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

(23.99/12) returns 1, and int(23.999/12) returns 2 This implies that int() function is rounding ... It's not int() that's doing the rounding; that second numerator is being rounded before being divided by 12: Python 3.9.7 (default, Oct 10 2021, 15:13:22) [GCC

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

(23.999/12) returns 2 This implies that int() function is rounding ... It's not int() that's doing the rounding; that second numerator is being rounded before being divided by 12: Python 3.9.7 (default, Oct 10 2021, 15:13:22) [GCC 11.1.0] on linux Type "

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

This implies that int() function is rounding ... It's not int() that's doing the rounding; that second numerator is being rounded before being divided by 12: Python 3.9.7 (default, Oct 10 2021, 15:13:22) [GCC 11.1.0] on linux Type "help", "copyright", "credi

Re: Unexpected behaviour of math.floor, round and int functions (rounding)

On 2021-11-18 at 23:16:32 -0300, René Silva Valdés wrote: > Hello, I would like to report the following issue: > > Working with floats i noticed that: > > int(23.99/12) returns 1, and > int(23.999/12) returns 2 > > This implies that int() functi

Unexpected behaviour of math.floor, round and int functions (rounding)

Hello, I would like to report the following issue: Working with floats i noticed that: int(23.99/12) returns 1, and int(23.999/12) returns 2 This implies that int() function is rounding, which doesn't appear to be expected (documentation doesn't say anything about

[issue45702] Python/dtoa.c requires 53 bit hardware rounding unavalable on x64

Oleg Iarygin added the comment: When I first saw "default rounding precision of 64 bits", I've thought it's about "64 bit precision", aka binary64, aka double. So I suggested that the code expects some hardly known Intel FPU-specific binary56 instead. Now, after a seco

[issue45702] Python/dtoa.c requires 53 bit hardware rounding unavalable on x64

Mark Dickinson added the comment: I'm not sure I understand the problem that you're reporting - what issues are you seeing in practice? x64 should be fine here. In normal circumstances, the compiled version of dtoa.c will be using SSE2 instructions and will already be doing floating-point

[issue45702] Python/dtoa.c requires 53 bit hardware rounding unavalable on x64

New submission from Oleg Iarygin : File configure.ac:4617 states the following: > # The short float repr introduced in Python 3.1 requires the > # correctly-rounded string <-> double conversion functions from > # Python/dtoa.c, which in turn require that the FPU uses 53-b

[issue45347] datetime subject to rounding?

Daniele Varrazzo added the comment: Considering that I have found another pair of dates failing equality, and they are too on the last Sunday of October, the hypothesis of rounding in timezone code starts to look likely Python 3.7.9 (default, Jan 12 2021, 17:26:22) [GCC 8.3.0] on linux

[issue45347] datetime subject to rounding?

Change by Daniel Fortunov : -- nosy: +dfortunov ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45347] datetime subject to rounding?

Joachim Jablon added the comment: It may or it may not be obvious to some, but in year 5328, October 31st is the last Sunday of October, which in Rome, as in the rest of EU, according to the 202X rules, means it’s the day we shift from summer time (in Rome UTC+2) to standard time (in Rome

[issue45347] datetime subject to rounding?

Raymond Hettinger added the comment: Related: https://bugs.python.org/issue44831 -- nosy: +rhettinger ___ Python tracker ___ ___

[issue45347] datetime subject to rounding?

imedelta(seconds=3600 ... True False True >>> for i in range(3): ... ref = dt.datetime(5327 + i, 10, 31, tzinfo=dt.timezone.utc) ... print(ref.astimezone(ZoneInfo(key='Europe/Rome')) - ref.astimezone(dt.timezone(dt.timedelta(seconds=3600 ... 0:00:00 0:00:00 0:00:00 Is this a f

[issue20499] Rounding errors with statistics.variance

Steven D'Aprano added the comment: Regarding the call to sorted that you removed. I just realised that this was buggy! In my testing, I found that there was a consistent speed-up by summing fractions in order of increasing denominators (small denominators first): >>> from fractions import

[issue20499] Rounding errors with statistics.variance

Steven D'Aprano added the comment: > rhettinger requested a review from stevendaprano yesterday This is not a complaint Raymond, but you're too quick for me! Your changes look good to me, thank you. -- ___ Python tracker

[issue20499] Rounding errors with statistics.variance

Change by Raymond Hettinger : -- assignee: steven.daprano -> rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue20499] Rounding errors with statistics.variance

Raymond Hettinger added the comment: New changeset 3c30805b58421a1e2aa613052b6d45899f9b1b5d by Raymond Hettinger in branch '3.10': [3.10] bpo-20499: Rounding error in statistics.pvariance (GH-28230) (GH-28248) https://github.com/python/cpython/commit/3c30805b58421a1e2aa613052b6d45899f9b1b5d

[issue20499] Rounding errors with statistics.variance

Change by Raymond Hettinger : -- pull_requests: +26669 pull_request: https://github.com/python/cpython/pull/28248 ___ Python tracker ___

[issue20499] Rounding errors with statistics.variance

Change by Raymond Hettinger : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue20499] Rounding errors with statistics.variance

Raymond Hettinger added the comment: New changeset 4a5cccb02bb2254634c0fbb2cbb14e2e7f45e2d5 by Raymond Hettinger in branch 'main': bpo-20499: Rounding error in statistics.pvariance (GH-28230) https://github.com/python/cpython/commit/4a5cccb02bb2254634c0fbb2cbb14e2e7f45e2d5

[issue20499] Rounding errors with statistics.variance

Change by Raymond Hettinger : -- nosy: +rhettinger nosy_count: 4.0 -> 5.0 pull_requests: +26650 stage: -> patch review pull_request: https://github.com/python/cpython/pull/28230 ___ Python tracker

[issue20499] Rounding errors with statistics.variance

Irit Katriel added the comment: Reproduced on 3.11: >>> statistics.pvariance([0,0,1]) 0.4 >>> statistics.variance([0,0,2]) 1.3335 -- nosy: +iritkatriel versions: +Python 3.10, Python 3.11, Python 3.9 -Python 3.5 ___

[issue41598] Adding support for rounding modes to builtin round

Raymond Hettinger added the comment: Given that most of commenters don't think this is a good idea, I'm going to mark it as closed. Feel free to continue the discussion on python-ideas. If it gains traction, open this back up and give it more core-developer attention. --

[issue41598] Adding support for rounding modes to builtin round

Vedran Čačić added the comment: Well, of course, but that's possible even now, and people still reach for `round`. I guess the problem is that it's too easily accessible. :-) -- ___ Python tracker

[issue41598] Adding support for rounding modes to builtin round

, or str.format() (all of which have the same underlying implementation) to do your float-to-string-for-display-purposes work. I just don't see how getting a binary float via decimal rounding would be useful. -- ___ Python tracker <ht

[issue41598] Adding support for rounding modes to builtin round

Vedran Čačić added the comment: > Personally, I think I'd rather have easier ways to create Decimal objects Wouldn't everybody? :-P But that's been proposed at least 4 times already and never got anywhere. My proposal is at least original, has a precedent at the above link (strings as

[issue41598] Adding support for rounding modes to builtin round

Mark Dickinson added the comment: @Vedran: > I have tons of these ideas, but usually am afraid of voicing them ... Always good to have ideas brought up, so long as there's no expectation that every idea gets implemented. :-) But I think rounding a string is probably another

  1   2   3   4   5   6   >