[issue45620] A misleading url in 'Floating Point Arithmetic' page

Akuli added the comment: If you still have the problem, can you show us what headers your browser sends to websites? You can see that by running in Python: import socket print(socket.create_server(('127.0.0.1', 12345)).accept()[0].recv(1024).decode()) and then going to

[issue45620] A misleading url in 'Floating Point Arithmetic' page

肖小小 added the comment: It shows the drug ad slogan even with the google search result. http://www.strong19.com/I searched 'The Perils of Floating Point lahey' -- ___ Python tracker

[issue45620] A misleading url in 'Floating Point Arithmetic' page

肖小小 added the comment: I was redirect to http://www.strong19.com/ so is this my internet problem? -- ___ Python tracker ___ ___

[issue45620] A misleading url in 'Floating Point Arithmetic' page

肖小小 added the comment: It shows the drug ad slogan even with the google search result. I searched 'The Perils of Floating Point lahey'http://www.strong19.com/ -- ___ Python tracker

[issue45620] A misleading url in 'Floating Point Arithmetic' page

肖小小 added the comment: Thanks! Works for me in browser now.http://www.strong19.com/ -- nosy: +xiaox55066 ___ Python tracker ___ ___

[issue45620] A misleading url in 'Floating Point Arithmetic' page

Eric V. Smith added the comment: @Akuli: thanks for checking. And thanks so much for the awesome debugging with curl: that was the key to solving the problem. I didn't hear back from lahey.com what the problem was, but I'd sure be curious to know! -- resolution: -> third party

[issue45620] A misleading url in 'Floating Point Arithmetic' page

Akuli added the comment: Thanks! Works for me in browser now. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue45620] A misleading url in 'Floating Point Arithmetic' page

Eric V. Smith added the comment: I notified lahey.com, and it looks like the behavior is now normal (at least, it looks okay by testing with the curl commands). Could someone who say this problem in a browser please double-check? -- ___ Python

[issue45620] A misleading url in 'Floating Point Arithmetic' page

Change by Eric V. Smith : -- resolution: works for me -> stage: resolved -> status: closed -> open ___ Python tracker ___ ___

[issue45620] A misleading url in 'Floating Point Arithmetic' page

Eric V. Smith added the comment: That's interesting. I see the same behavior. So this seems to be a problem on www.lahey.com. I'll see if I can report it to them. -- ___ Python tracker

[issue45620] A misleading url in 'Floating Point Arithmetic' page

Akuli added the comment: To me, it redirects or doesn't redirect to the drugs site, depending on what Accept-Language header your browser sends. And when the redirecting happens, the site is in chinese. (I don't speak chinese, and I don't know why my browser is sending zh-CN in

[issue45620] A misleading url in 'Floating Point Arithmetic' page

Sonia added the comment: Thanks! -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45620] A misleading url in 'Floating Point Arithmetic' page

Eric V. Smith added the comment: The link on the doc page also works for me, sending me to http://www.lahey.com/float.htm. I think the problem is with @hanhantw's browser or ISP, or similar. I'm going to close this. -- nosy: +eric.smith resolution: -> works for me stage: ->

[issue45620] A misleading url in 'Floating Point Arithmetic' page

Sonia added the comment: It shows the drug ad slogan even with the google search result. I searched 'The Perils of Floating Point lahey' -- Added file: https://bugs.python.org/file50395/截圖 2021-10-27 下午5.02.02.png ___ Python tracker

[issue45620] A misleading url in 'Floating Point Arithmetic' page

Sonia added the comment: I was redirect to https://www.hmbags.tw so is this my internet problem? -- ___ Python tracker ___ ___

[issue45620] A misleading url in 'Floating Point Arithmetic' page

Dennis Sweeney added the comment: I was unable to replicate this. I see the correct article "The Perils of Floating Point" at lahey.com/float.htm. Is the site still incorrect for you, or did the Lahey site fix the issue? -- assignee: -> docs@python components: +Documentation nosy:

[issue45620] A misleading url in 'Floating Point Arithmetic' page

://www.stat.cmu.edu/~brian/711/week03/perils-of-floating-point.pdf -- messages: 405070 nosy: hanhantw priority: normal severity: normal status: open title: A misleading url in 'Floating Point Arithmetic' page versions: Python 3.10 ___ Python tracker <ht

[issue33022] Floating Point Arithmetic Inconsistency (internal off-by-one)

Tim Peters added the comment: What did you expect? The precision of Python ints is limited only by the amount of memory you have, but Python floats are IEEE-754 double precision numbers, and have only 53 bits of precision. 2**53 + 1 simply can't be represented exactly as a

[issue33022] Floating Point Arithmetic Inconsistency (internal off-by-one)

94.0 ``` Notably 9007199254740991 = 2**53 -1 Probably an internal off by one? -- messages: 313420 nosy: ddg priority: normal severity: normal status: open title: Floating Point Arithmetic Inconsistency (internal off-by-one) versions: Python 3.6 ___ P

[issue26291] Floating-point arithmetic

New submission from good.bad: print(1 - 0.8) 0.19996 print(1 - 0.2) 0.8 why not 0.2? -- messages: 259622 nosy: goodbad priority: normal severity: normal status: open title: Floating-point arithmetic versions: Python 3.5 ___ Python

[issue26291] Floating-point arithmetic

Emanuel Barry added the comment: This is due to how floating point numbers are handled under the hood. See http://effbot.org/pyfaq/why-are-floating-point-calculations-so-inaccurate.htm and https://docs.python.org/3/tutorial/floatingpoint.html for some useful read about why Python behaves like

Re: Python -- floating point arithmetic

David Mainzer d...@tu-clausthal.de wrote: All your comments helped me and now i know how it works in python ! This has nothing to do with Python. What you're seeing is the way IEEE-754 floating point arithmetic works. You'd see these same results in any programming language, including assembly

Re: Python -- floating point arithmetic

In article mailman.426.1278606698.1673.python-l...@python.org, Chris Rebert c...@rebertia.com wrote: On Thu, Jul 8, 2010 at 8:52 AM, Giacomo Boffi giacomo.bo...@polimi.it wrote: Zooko O'Whielacronx zo...@zooko.com writes: I'm starting to think that one should use Decimals by default and

Re: Python -- floating point arithmetic

On Thu, 08 Jul 2010 06:04:33 +0200, David Cournapeau wrote: On Thu, Jul 8, 2010 at 5:41 AM, Zooko O'Whielacronx zo...@zooko.com wrote: I'm starting to think that one should use Decimals by default and reserve floats for special cases. This is somewhat analogous to the way that Python

Re: Python -- floating point arithmetic

On Jul 8, 12:53 am, Zooko O'Whielacronx zo...@zooko.com wrote: I don't understand. I described two different problems: problem one is that the inputs, outputs and literals of your program might be in a different encoding (in my experience they have most commonly been in decimal). Problem two

Re: Python -- floating point arithmetic

On 07/07/2010 08:08 PM, Raymond Hettinger wrote: On Jul 7, 5:55 am, Mark Dickinson dicki...@gmail.com wrote: On Jul 7, 1:05 pm, david mainzer d...@tu-clausthal.de wrote: Dear Python-User, today i create some slides about floating point arithmetic. I used an example from http

Re: Python -- floating point arithmetic

On Jul 8, 7:23 am, Mark Dickinson dicki...@gmail.com wrote: On Jul 8, 11:58 am, Adam Skutt ask...@gmail.com wrote: accurately.  Moreover, in general, it's impossible to even round operations involving transcendental functions to an arbitrary fixed- precision, you may need effectively

Re: Python -- floating point arithmetic

Wolfram Hinderer wrote: On 7 Jul., 19:32, Ethan Furman et...@stoneleaf.us wrote: Nobody wrote: On Wed, 07 Jul 2010 15:08:07 +0200, Thomas Jollans wrote: you should never rely on a floating-point number to have exactly a certain value. Never is an overstatement. There are situations

Re: Python -- floating point arithmetic

On Jul 8, 2:00 pm, Adam Skutt ask...@gmail.com wrote: On Jul 8, 7:23 am, Mark Dickinson dicki...@gmail.com wrote: On Jul 8, 11:58 am, Adam Skutt ask...@gmail.com wrote: accurately.  Moreover, in general, it's impossible to even round operations involving transcendental functions to an

Re: Python -- floating point arithmetic

Adam Skutt ask...@gmail.com wrote: On Jul 8, 7:23 am, Mark Dickinson dicki...@gmail.com wrote: On Jul 8, 11:58 am, Adam Skutt ask...@gmail.com wrote: accurately.  Moreover, in general, it's impossible to even round operations involving transcendental functions to an arbitrary fixed-

Re: Python -- floating point arithmetic

On Jul 8, 9:22 am, Mark Dickinson dicki...@gmail.com wrote: On Jul 8, 2:00 pm, Adam Skutt ask...@gmail.com wrote: On Jul 8, 7:23 am, Mark Dickinson dicki...@gmail.com wrote: On Jul 8, 11:58 am, Adam Skutt ask...@gmail.com wrote: accurately.  Moreover, in general, it's impossible to

Re: Python -- floating point arithmetic

Zooko O'Whielacronx zo...@zooko.com wrote: I'm starting to think that one should use Decimals by default and reserve floats for special cases. Only if one has Power6 (or 7) which has hardware support for BCD. Otherwise you will have slow applications. Victor. -- Victor Eijkhout -- eijkhout

Re: Python -- floating point arithmetic

On Jul 8, 3:29 pm, Adam Skutt ask...@gmail.com wrote: On Jul 8, 9:22 am, Mark Dickinson dicki...@gmail.com wrote: On Jul 8, 2:00 pm, Adam Skutt ask...@gmail.com wrote:  For some computations, the number of bits required to get the desired precision can quickly overwhelm the finite

Re: Python -- floating point arithmetic

Zooko O'Whielacronx zo...@zooko.com writes: I'm starting to think that one should use Decimals by default and reserve floats for special cases. would you kindly lend me your Decimals ruler? i need to measure the sides of the triangle whose area i have to compute --

Re: Python -- floating point arithmetic

On Thu, Jul 8, 2010 at 8:52 AM, Giacomo Boffi giacomo.bo...@polimi.it wrote: Zooko O'Whielacronx zo...@zooko.com writes: I'm starting to think that one should use Decimals by default and reserve floats for special cases. would you kindly lend me your Decimals ruler? i need to measure the

Re: Python -- floating point arithmetic

On Thu, Jul 8, 2010 at 4:58 AM, Adam Skutt ask...@gmail.com wrote: I can't think of any program I've ever written where the inputs are actually intended to be decimal.  Consider a simple video editing program, and the user specifies a frame rate 23.976 fps.  Is that what they really wanted?  

Re: Python -- floating point arithmetic

On Jul 8, 11:36 am, Mark Dickinson dicki...@gmail.com wrote: I think that's because we're talking at cross-purposes. To clarify, suppose you want to compute some value (pi;  log(2); AGM(1, sqrt(2)); whatever...) to 1000 significant decimal places. Then typically the algorithm (sometimes known

Re: Python -- floating point arithmetic

On Jul 8, 2:59 pm, Stefan Krah stefan-use...@bytereef.org wrote: pow() is trickier. Exact results have to be weeded out before attempting the correction loop for correct rounding, and this is complicated. For example, in decimal this expression takes a long time (in cdecimal the power

Re: Python -- floating point arithmetic

On Jul 8, 12:38 pm, Zooko O'Whielacronx zo...@zooko.com wrote: On Thu, Jul 8, 2010 at 4:58 AM, Adam Skutt ask...@gmail.com wrote: I can't think of any program I've ever written where the inputs are actually intended to be decimal.  Consider a simple video editing program, and the user

Re: Python -- floating point arithmetic

Adam Skutt ask...@gmail.com wrote: I actually agree with much of what you've said.  It was just the impossible claim that went over the top (IMO).  The MPFR library amply demonstrates that computing many transcendental functions to arbitrary precision, with correctly rounded results, is

Re: Python -- floating point arithmetic

Mark Dickinson dicki...@gmail.com wrote: On Jul 8, 2:59 pm, Stefan Krah stefan-use...@bytereef.org wrote: pow() is trickier. Exact results have to be weeded out before attempting the correction loop for correct rounding, and this is complicated. For example, in decimal this expression

Re: Python -- floating point arithmetic

On Thu, Jul 8, 2010 at 11:22 AM, Adam Skutt ask...@gmail.com wrote: On Jul 8, 12:38 pm, Zooko O'Whielacronx zo...@zooko.com wrote: Now as a programmer you have two choices: … 1. accept what they typed in and losslessly store it in a decimal: … 2. accept what they typed in and lossily convert

Re: Python -- floating point arithmetic

On Jul 8, 2:00 pm, Stefan Krah stefan-use...@bytereef.org wrote: This whole argument is a misunderstanding. Mark and I argue that correct rounding is quite feasible in practice, you argue that you want guaranteed execution times and memory usage. This is clear now, but was not so apparent in

Re: Python -- floating point arithmetic

On 8 Jul., 15:10, Ethan Furman et...@stoneleaf.us wrote: Interesting.  I knew when I posted my above comment that I was ignoring such situations.  I cannot comment on the code itself as I am unaware of the algorithm, and haven't studied numbers extensively (although I do find them very

Re: Python -- floating point arithmetic

Wolfram Hinderer wolfram.hinde...@googlemail.com writes: JFTR, it works because a+b == a+b (while I don't think that a+b == b+a holds for all a and b). I'm pretty sure IEEE 754 addition is always commutative (except maybe in the presence of infinity or NaN and maybe not even then). It differs

Re: Python -- floating point arithmetic

On Jul 8, 9:52 pm, Wolfram Hinderer wolfram.hinde...@googlemail.com wrote: JFTR, it works because a+b == a+b (while I don't think that a+b == b+a holds for all a and b). Actually, that's one of the few identities that's safe. Well, for non- NaN IEEE 754 floating-point, at any rate. And

Python -- floating point arithmetic

Dear Python-User, today i create some slides about floating point arithmetic. I used an example from http://docs.python.org/tutorial/floatingpoint.html so i start the python shell on my linux machine: d...@maxwell $ python Python 2.6.5 (release26-maint, May 25 2010, 12:37:06) [GCC 4.3.4

Python -- floating point arithmetic

-BEGIN PGP SIGNED MESSAGE- Hash: SHA384 Dear Python-User, today i create some slides about floating point arithmetic. I used an example from http://docs.python.org/tutorial/floatingpoint.html so i start the python shell on my linux machine: d...@maxwell $ python Python 2.6.5

Re: Python -- floating point arithmetic

On Jul 7, 1:05 pm, david mainzer d...@tu-clausthal.de wrote: Dear Python-User, today i create some slides about floating point arithmetic. I used an example from http://docs.python.org/tutorial/floatingpoint.html so i start the python shell on my linux machine: d...@maxwell $ python

Re: Python -- floating point arithmetic

On 07/07/2010 02:05 PM, david mainzer wrote: today i create some slides about floating point arithmetic. I used an example from http://docs.python.org/tutorial/floatingpoint.html so i start the python shell on my linux machine: d...@maxwell $ python Python 2.6.5 (release26-maint, May

Re: Python -- floating point arithmetic

can anybody tell me how python internal represent a float number?? It's an IEEE 754 double precision float on all hardware platforms that support IEEE 754 semantics. Python follows the C99 standards for double and complex numbers. Christian --

Re: Python -- floating point arithmetic

On Jul 7, 2010, at 9:08 AM, Thomas Jollans wrote: On 07/07/2010 02:05 PM, david mainzer wrote: today i create some slides about floating point arithmetic. I used an example from http://docs.python.org/tutorial/floatingpoint.html so i start the python shell on my linux machine: d...@maxwell

Re: Python -- floating point arithmetic

david mainzer wrote: sum = 0.0 for i in range(10): ... sum += 0.1 ... sum 0.99989 But thats looks a little bit wrong for me ... i must be a number greater then 1.0 because 0.1 = 0.155511151231257827021181583404541015625000 in python ... if i print

Re: Python -- floating point arithmetic

david mainzer wrote: sum = 0.0 for i in range(10): ... sum += 0.1 ... sum 0.99989 But thats looks a little bit wrong for me ... i must be a number greater then 1.0 because 0.1 = 0.155511151231257827021181583404541015625000 in python ... if i print

Re: Python -- floating point arithmetic

relatively simple rules. Even if the CPU has a built-in random number generator, it will *not* be used to generate the least-significant bits of a floating-point arithmetic result. The second and third cases above assume that floating-point arithmetic follows IEEE-754 (the second case is likely to be true

Re: Python -- floating point arithmetic

Nobody wrote: On Wed, 07 Jul 2010 15:08:07 +0200, Thomas Jollans wrote: you should never rely on a floating-point number to have exactly a certain value. Never is an overstatement. There are situations where you can rely upon a floating-point number having exactly a certain value. It's not

Re: Python -- floating point arithmetic

On Jul 7, 5:55 am, Mark Dickinson dicki...@gmail.com wrote: On Jul 7, 1:05 pm, david mainzer d...@tu-clausthal.de wrote: Dear Python-User, today i create some slides about floating point arithmetic. I used an example from http://docs.python.org/tutorial/floatingpoint.html so i

Re: Python -- floating point arithmetic

On 7 Jul., 19:32, Ethan Furman et...@stoneleaf.us wrote: Nobody wrote: On Wed, 07 Jul 2010 15:08:07 +0200, Thomas Jollans wrote: you should never rely on a floating-point number to have exactly a certain value. Never is an overstatement. There are situations where you can rely upon a

Re: Python -- floating point arithmetic

I'm starting to think that one should use Decimals by default and reserve floats for special cases. This is somewhat analogous to the way that Python provides arbitrarily-big integers by default and Python programmers only use old-fashioned fixed-size integers for special cases, such as

Re: Python -- floating point arithmetic

On Thu, Jul 8, 2010 at 5:41 AM, Zooko O'Whielacronx zo...@zooko.com wrote: I'm starting to think that one should use Decimals by default and reserve floats for special cases. This is somewhat analogous to the way that Python provides arbitrarily-big integers by default and Python programmers

Re: Python -- floating point arithmetic

On Wed, Jul 7, 2010 at 10:04 PM, David Cournapeau courn...@gmail.com wrote: Decimal vs float is a different matter altogether: decimal has downsides compared to float. First, there is this irreconcilable fact that no matter how small your range is, it is impossible to represent exactly all

[issue4637] Binary floating point and decimal floating point arithmetic

New submission from Retro vinet...@gmail.com: Please consider of making the default floating point arithmetic in Python 3.x be decimal floating point arithmetic. -- components: Interpreter Core messages: 77645 nosy: Retro, gvanrossum severity: normal status: open title: Binary floating

[issue4637] Binary floating point and decimal floating point arithmetic

Guido van Rossum gu...@python.org added the comment: This was discussed recently on python-dev (or was it python-ideas). The world is not ready for this. Please refer to the archive for motivation. -- resolution: - rejected status: open - closed

floating point arithmetic

Hi all, I understand that due to different arithmetic used in floating points they are just approximations. Hence, 180/100=1 in my python interpreter. How can I tackle this problem of inaccurate floating point numbers? thank you regards xtd -- http://mail.python.org/mailman/listinfo/python-list

Re: floating point arithmetic

I understand that due to different arithmetic used in floating points they are just approximations. Hence, 180/100=1 in my python interpreter. No, that's not the reason you get 1, it's because the current version of python does integer division by default. Try doing 180.0/100 or including from

Re: floating point arithmetic

On Aug 26, 4:11 pm, fred8865 [EMAIL PROTECTED] wrote: Hi all, I understand that due to different arithmetic used in floating points they are just approximations. Hence, 180/100=1 in my python interpreter. How can I tackle this problem of inaccurate floating point numbers? Try actually using

Re: floating point arithmetic

On Aug 27, 7:11 am, fred8865 [EMAIL PROTECTED] wrote: I understand that due to different arithmetic used in floating points they are just approximations. Hence, 180/100=1 in my python interpreter. It's not hence. What you are seeing is truncating integer division. How can I tackle this

Re: floating point arithmetic

thanks guys fred8865 wrote: Hi all, I understand that due to different arithmetic used in floating points they are just approximations. Hence, 180/100=1 in my python interpreter. How can I tackle this problem of inaccurate floating point numbers? thank you regards xtd --

Re: floating point arithmetic

John Machin wrote: On Aug 27, 7:11 am, fred8865 [EMAIL PROTECTED] wrote: I understand that due to different arithmetic used in floating points they are just approximations. Hence, 180/100=1 in my python interpreter. It's not hence. What you are seeing is truncating integer division. How

Re: floating point arithmetic

En Tue, 26 Aug 2008 18:11:30 -0300, fred8865 [EMAIL PROTECTED] escribi�: I understand that due to different arithmetic used in floating points they are just approximations. Hence, 180/100=1 in my python interpreter. How can I tackle this problem of inaccurate floating point numbers? thank you