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

> > I posted that 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)

o make people aware 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&#x

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... https://www.girlgeniusonline.co

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. 6

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 mea

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 a

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 furth

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)

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 proce

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 num

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

om: Python-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

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 represent

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)

you prefer, 4140 +/- 5.) > I claim a similar issue plagues 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 mi

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)

ect 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 wr

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 represent

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 ar

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

gt; evaluation 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 alm

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)

valuation 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 as c

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 >> > "unreliable"

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 n

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 on

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 peop

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 p

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 notic

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)

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", &

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)

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

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

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", &

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 anythin

Re: Question about Decimal and rounding

"Thomas Jollans" wrote in message news:19223891-2006-d496-bdfe-32776834e...@tjol.eu... On 27/04/18 10:21, Frank Millman wrote: > I have an object which represents a Decimal type. > > It can receive input from various sources. It has to round the value to > a particular scale factor before sto

Re: Question about Decimal and rounding

t the "obvious" way to check whether a Decimal number is an integer is simply: >>> d1 = Decimal('1.1') >>> d2 = Decimal('3') >>> int(d1) == d1 False >>> int(d2) == d2 True Final thoughts: * Beware of spending too much time on premature

Question about Decimal and rounding

Hi all I have an object which represents a Decimal type. It can receive input from various sources. It has to round the value to a particular scale factor before storing it. The scale factor can vary, so it has to be looked up every time, which is a slight overhead. I thought I could speed it

Re: Rounding a number

rg/mailman/listinfo/python-list Thanks I know there are more than one way to round and answer. I was hoping that using the {:7,.0f} formatting had a solution. There are definite tradeoffs, but since you're rounding to integer size, the round() function works fine. If you wanted tenths

Re: Rounding a number

On Thu, 30 Apr 2015 22:00:17 +0200, Thijs Engels wrote: >round(65253, -3) > >might be what you are looking for... > > >On Thu, Apr 30, 2015, at 21:49, Seymore4Head wrote: >> I have this page book marked. >> https://mkaz.com/2012/10/10/python-string-format/ >> >> I am getting numbers from sixty t

Re: Rounding a number

On 30/04/2015 21:00, Thijs Engels wrote: On Thu, Apr 30, 2015, at 21:49, Seymore4Head wrote: I have this page book marked. https://mkaz.com/2012/10/10/python-string-format/ I am getting numbers from sixty thousand to two hundred thousand. I would like to round them to the nearest thousand. So 6

Re: Rounding a number

round(65253, -3) might be what you are looking for... On Thu, Apr 30, 2015, at 21:49, Seymore4Head wrote: > I have this page book marked. > https://mkaz.com/2012/10/10/python-string-format/ > > I am getting numbers from sixty thousand to two hundred thousand. > I would like to round them to the

Rounding a number

I have this page book marked. https://mkaz.com/2012/10/10/python-string-format/ I am getting numbers from sixty thousand to two hundred thousand. I would like to round them to the nearest thousand. So 65,253 should read 65,000. How? Total=2100 for x in range (10,35): count=1000/x print ("

Re: Rounding off Values of dicts (in a list) to 2 decimal points

On Thursday, October 3, 2013 11:03:17 AM UTC-7, Neil Cerutti wrote: > On 2013-10-03, trip...@gmail.com wrote: > > > thekey=[{"a": 80.0, "b": 0.0, "c": 10.0, "d": 10.0}, {"a": > > > 100.0, "b": 0.0, "c": 0.0, "d": 0.0}, {"a": 80.0, "b": 0.0, > > > "c": 10.0, "d": 10.0}, {"a": 90.0, "b": 0.0, "c"

Re: Rounding off Values of dicts (in a list) to 2 decimal points

On 2013-10-03, trip...@gmail.com wrote: > thekey=[{"a": 80.0, "b": 0.0, "c": 10.0, "d": 10.0}, {"a": > 100.0, "b": 0.0, "c": 0.0, "d": 0.0}, {"a": 80.0, "b": 0.0, > "c": 10.0, "d": 10.0}, {"a": 90.0, "b": 0.0, "c": 0.0, "d": > 10.0}] > > However, at the URL, the values show up as 90.4327869412

Re: Rounding off Values of dicts (in a list) to 2 decimal points

trip...@gmail.com wrote: > On Wednesday, October 2, 2013 10:01:16 AM UTC-7, tri...@gmail.com wrote: >> am trying to round off values in a dict to 2 decimal points but have been >> unsuccessful so far. The input I have is like this: >> >> >> >> >> >> y = [{'a': 80.0, 'b': 0.0786235, 'c': 1

Re: Rounding off Values of dicts (in a list) to 2 decimal points

On Wednesday, October 2, 2013 10:01:16 AM UTC-7, tri...@gmail.com wrote: > am trying to round off values in a dict to 2 decimal points but have been > unsuccessful so far. The input I have is like this: > > > > > > y = [{'a': 80.0, 'b': 0.0786235, 'c': 10.0, 'd': 10.6742903}, {'a': > 80.

Re: Rounding off Values of dicts (in a list) to 2 decimal points

#x27;: 10.9762304}] > > I want to round off all the values to two decimal points using > the ceil function. Here's what I have: I recommend using the builtin function round instead of math.ceil. math.ceil doesn't do what is normally thought of as rounding. In addition, it supports r

Re: Rounding off Values of dicts (in a list) to 2 decimal points

On Wed, Oct 2, 2013 at 1:01 PM, wrote: > am trying to round off values in a dict to 2 decimal points but have been > unsuccessful so far. The input I have is like this: > > > y = [{'a': 80.0, 'b': 0.0786235, 'c': 10.0, 'd': 10.6742903}, {'a': > 80.73246, 'b': 0.0, 'c': 10.780323, 'd': 10.0

Re: Rounding off Values of dicts (in a list) to 2 decimal points

0 > return > roundingVals_toTwoDeci() > > But it is not working - I am still getting the old values. You are assigning to a local variable, v. Instead, store the new values back to the dict like this: d[k] = ceil(v*100)/100.0 And you don't need to declare y glob

Re: Rounding off Values of dicts (in a list) to 2 decimal points

> def roundingVals_toTwoDeci(): > global y > for d in y: > for k, v in d.items(): > v = ceil(v*100)/100.0 > return > roundingVals_toTwoDeci() > > > > But it is not working - I am still getting the old values. You're not assigning the rou

Rounding off Values of dicts (in a list) to 2 decimal points

am trying to round off values in a dict to 2 decimal points but have been unsuccessful so far. The input I have is like this: y = [{'a': 80.0, 'b': 0.0786235, 'c': 10.0, 'd': 10.6742903}, {'a': 80.73246, 'b': 0.0, 'c': 10.780323, 'd': 10.0}, {'a': 80.7239, 'b': 0.7823640, 'c': 10.0, 'd':

Re: Generating equally-spaced floats with least rounding error

On 9/25/2011 3:36 AM, Arnaud Delobelle wrote: On 24 September 2011 23:10, Terry Reedy wrote: The best you can do for this example is ['%20.18f' % (i/10 ) for i in range(0, 22, 3)] ['0.00', '0.299989', '0.599978', '0.900022', '1.199

Re: Generating equally-spaced floats with least rounding error

Terry Reedy wrote: > I do hope you did not stop with my lead-in sentence, and read to the > end, where I gave you most of the answer you were looking for, without > using the fractions module. Yes, I read your entire post, thank you, and for my purposes I'm happy with the fractions module. --

Re: Generating equally-spaced floats with least rounding error

On 24 September 2011 23:10, Terry Reedy wrote: > On 9/24/2011 10:18 AM, Arnaud Delobelle wrote: >>      ((n-i)*a + i*b)/n for i in range(n+1) > ['%20.18f' % x for x in [((7-i)*0.0 + i*2.1)/7 for i in range(8)]] > ['0.00', '0.299989', '0.599978', > '0.9

Re: Generating equally-spaced floats with least rounding error

= with floats anyway. >>> F(2.1)==F(21,10) False >>> F(2.1) Fraction(4728779608739021, 2251799813685248) That denominator is a power of 2 (2**51 as it happens), which is unsurprising for something created from an IEEE floating point value. Rounding F(21,10) off to fit into float

Re: Generating equally-spaced floats with least rounding error

On 9/25/2011 1:21 AM, Steven D'Aprano wrote: Terry Reedy wrote: On 9/24/2011 9:53 AM, Steven D'Aprano wrote: [...] [0.0 + i*width for i in range(8)] [0.0, 0.3, 0.6, 0.8999, 1.2, 1.5, 1.7998, 2.1] The 4th and 7th values have rounding errors, the rest are

Re: Generating equally-spaced floats with least rounding error

On Sun, Sep 25, 2011 at 3:31 PM, Steven D'Aprano wrote:>> If you look again at the code I used, I did. I just did it inside the list> comp. You did, but you created a Fraction from a float; my version used Fraction(21,10) instead of (effectively) Fraction(2.1). My description was a little sloppy,

Re: Generating equally-spaced floats with least rounding error

On Sep 24, 6:53 am, Steven D'Aprano wrote: > I'm trying to generate a sequence of equally-spaced numbers between a lower > and upper limit. Given arbitrary limits, what is the best way to generate a > list of equally spaced floats with the least rounding error for each poi

Re: Generating equally-spaced floats with least rounding error

Chris Angelico wrote: > On Sun, Sep 25, 2011 at 3:01 AM, Steven D'Aprano > wrote: >> Mark Dickinson wrote: >> >>> Using Fraction for intermediate calculations actually works perfectly >>> for this, since conversions from float to Fraction are exact, while >>> conversions from Fraction to float ar

Re: Generating equally-spaced floats with least rounding error

Terry Reedy wrote: > On 9/24/2011 9:53 AM, Steven D'Aprano wrote: [...] >>>>> [0.0 + i*width for i in range(8)] >> [0.0, 0.3, 0.6, 0.8999, 1.2, 1.5, 1.7998, 2.1] >> >> The 4th and 7th values have rounding errors, the rest are exa

Re: Generating equally-spaced floats with least rounding error

Arnaud Delobelle wrote: > On these examples, using fractions is no better than what I suggested > in my previous post. I'm sorry, I can't see your previous post. Perhaps it isn't available on my news provider? -- Steven -- http://mail.python.org/mailman/listinfo/python-list

Re: Generating equally-spaced floats with least rounding error

On 9/24/2011 9:53 AM, Steven D'Aprano wrote: I'm trying to generate a sequence of equally-spaced numbers between a lower and upper limit. Given arbitrary limits, what is the best way to generate a list of equally spaced floats with the least rounding error for each point? For example,

Re: Generating equally-spaced floats with least rounding error

>>> import numpy >>> numpy.arange(0, 3, 0.3) array([ 0. , 0.3, 0.6, 0.9, 1.2, 1.5, 1.8, 2.1, 2.4, 2.7]) -- http://mail.python.org/mailman/listinfo/python-list

Re: Generating equally-spaced floats with least rounding error

Arnaud Delobelle wrote: > start, stop, n = -1, 1.1, 7 > [float(F(start) + i*(F(stop)-F(start))/n) for i in range(n+1)] > > [-1.0, -0.7, -0.39997, -0.09996, > > 0.20004, 0.5001, 0.8, 1.1] > > >>> start, stop, n = -1, 1.1, 7 > >>> [((n-i)*st

Re: Generating equally-spaced floats with least rounding error

On 24 September 2011 18:01, Steven D'Aprano wrote: > Mark Dickinson wrote: > >> Using Fraction for intermediate calculations actually works perfectly >> for this, since conversions from float to Fraction are exact, while >> conversions from Fraction to float are correctly rounded.  So if >> you're

Re: Generating equally-spaced floats with least rounding error

On Sep 24, 6:01 pm, Steven D'Aprano wrote: > Ah, I knew it was too easy! > > >>> from fractions import Fraction as F > >>> start, stop, n = 1, 3.1, 7 > >>> [float(F(start) + i*(F(stop)-F(start))/n) for i in range(n+1)] > > [1.0, 1.3, 1.6, 1.9001, 2.2, 2.5, 2.8003, 3.1] I b

Re: Generating equally-spaced floats with least rounding error

On Sun, Sep 25, 2011 at 3:01 AM, Steven D'Aprano wrote: > Mark Dickinson wrote: > >> Using Fraction for intermediate calculations actually works perfectly >> for this, since conversions from float to Fraction are exact, while >> conversions from Fraction to float are correctly rounded.  So if >> y

Re: Generating equally-spaced floats with least rounding error

Mark Dickinson wrote: > Using Fraction for intermediate calculations actually works perfectly > for this, since conversions from float to Fraction are exact, while > conversions from Fraction to float are correctly rounded. So if > you're using Python, you're not too bothered about efficiency, an

Re: Generating equally-spaced floats with least rounding error

On Sun, Sep 25, 2011 at 12:26 AM, Mel wrote: > low_limit + (total_width * i) / intervals > Definite improvement, if the range is comparatively small. Multiply first, then divide. ChrisA -- http://mail.python.org/mailman/listinfo/python-list

Re: Generating equally-spaced floats with least rounding error

On Sep 24, 5:46 pm, Steven D'Aprano wrote: > Speed is important, but secondary to correctness. To be honest, I never even > thought of using fractions as an intermediate result -- I was thinking of > generating lists of Fractions. I think I can use this approach. Speed could be improved greatly b

Re: Generating equally-spaced floats with least rounding error

list of equally spaced floats with the least rounding error >> for each point? >> >> For example, suppose I want to divide the range 0 to 2.1 into 7 equal >> intervals, then the end-points of each interval are: >> >> (0.0)---(0.3)---(0.6)---(0.9)---(1.2)---(1.5)--

Re: Generating equally-spaced floats with least rounding error

On Sep 24, 2:53 pm, Steven D'Aprano wrote: > I'm trying to generate a sequence of equally-spaced numbers between a lower > and upper limit. Given arbitrary limits, what is the best way to generate a > list of equally spaced floats with the least rounding error for each poi

Re: Generating equally-spaced floats with least rounding error

Steven D'Aprano wrote: > I'm trying to generate a sequence of equally-spaced numbers between a > lower and upper limit. Given arbitrary limits, what is the best way to > generate a list of equally spaced floats with the least rounding error for > each point? > > Fo

Re: Generating equally-spaced floats with least rounding error

On Sep 24, 2011 2:59 PM, "Chris Angelico" wrote: > > On Sat, Sep 24, 2011 at 11:53 PM, Steven D'Aprano > wrote: > > #1 add multiples of the width to the starting value, 0. > > > > #2 subtract multiples of width from the ending value, 2.1. > > #3, go half and half - generate the lower half by addi

Re: Generating equally-spaced floats with least rounding error

ven, there isn't a better way to distinguish the values showing rounding errors automatically). (I guess dealing manually with values obtained by .as_integer_ratio() doesn't count as pure float operation...) vbr -- http://mail.python.org/mailman/listinfo/python-list

Re: Generating equally-spaced floats with least rounding error

On Sat, Sep 24, 2011 at 11:53 PM, Steven D'Aprano wrote: > #1 add multiples of the width to the starting value, 0. > > #2 subtract multiples of width from the ending value, 2.1. #3, go half and half - generate the lower half by adding to the lower bound, and the upper half by subtracting from the

Generating equally-spaced floats with least rounding error

I'm trying to generate a sequence of equally-spaced numbers between a lower and upper limit. Given arbitrary limits, what is the best way to generate a list of equally spaced floats with the least rounding error for each point? For example, suppose I want to divide the range 0 to 2.1 into 7

Re: Rounding up to the next 100

On Jan 21, 1:58 pm, noydb wrote: > Sorry, although what I really need is the string-number rounded UP > every time.  So if the number is 3890.32, it needs to go to 3900; if > the number is 3811.345, it needs to go to 3900 also. > > So, Florian's answer works. Another option is using math.ceil and

Re: Rounding up to the next 100

* noydb: Sorry, although what I really need is the string-number rounded UP every time. So if the number is 3890.32, it needs to go to 3900; if the number is 3811.345, it needs to go to 3900 also. So, Florian's answer works. You might also consider -100*(-3579.127893//100) :-) Which avoi

RE: Rounding up to the next 100

> From: Arnaud Delobelle > > > > >>> XstrNmbr = 3579.127893 > > I meant > >>> XstrNmbr = "3579.127893" > > > >>> round(float(XstrNmbr), -2) > > 3600.0 Ah, then you will need to cast it first. >>> XstrNmbr = '3579.127893' >>> round(float(XstrNmbr) ,-2) 3600.0 The information contained in

Re: Rounding up to the next 100

Sorry, although what I really need is the string-number rounded UP every time. So if the number is 3890.32, it needs to go to 3900; if the number is 3811.345, it needs to go to 3900 also. So, Florian's answer works. -- http://mail.python.org/mailman/listinfo/python-list

Re: Rounding up to the next 100

On Jan 21, 4:30 pm, michael.coll-ba...@verizonwireless.com wrote: > > From: noydb > > If one has a floating number as a string, is there a spiffy way to > > round that string-number UP to the nearest 100? > > > XstrNmbr = 3579.127893 -- would want to round that to 3600. > > What's wrong with round?

Re: Rounding up to the next 100

* michael.coll-ba...@verizonwireless.com: From: noydb If one has a floating number as a string, is there a spiffy way to round that string-number UP to the nearest 100? XstrNmbr = 3579.127893 -- would want to round that to 3600. What's wrong with round? round( XstrNmbr, -2 ) seems to d

Re: Rounding up to the next 100

noydb writes: > If one has a floating number as a string, is there a spiffy way to > round that string-number UP to the nearest 100? > > XstrNmbr = 3579.127893 -- would want to round that to 3600. math.ceil(3579.127893/100)*100 Florian -- GUIs programmieren mit Python und Glade:

RE: Rounding up to the next 100

> From: noydb > If one has a floating number as a string, is there a spiffy way to > round that string-number UP to the nearest 100? > > XstrNmbr = 3579.127893 -- would want to round that to 3600. What's wrong with round? round( XstrNmbr, -2 ) seems to do the trick. Or do you want to get ri

Re: Rounding up to the next 100

Arnaud Delobelle writes: > >>> XstrNmbr = 3579.127893 I meant >>> XstrNmbr = "3579.127893" > >>> round(float(XstrNmbr), -2) > 3600.0 -- Arnaud -- http://mail.python.org/mailman/listinfo/python-list

Re: Rounding up to the next 100

noydb writes: > If one has a floating number as a string, is there a spiffy way to > round that string-number UP to the nearest 100? > > XstrNmbr = 3579.127893 -- would want to round that to 3600. > > Thanks for any help! >>> XstrNmbr = 3579.127893 >>> round(float(XstrNmbr), -2) 3600.0 >>> HTH

  1   2   3   >