I have a suggestion to make inspired by the current discussion about trigonometric functions in degrees, and the desire to have them show "exact" values in some special cases. I suggest that it would be useful to have operators for performing **approximate** comparisons. I believe that such operators would be useful both for students learning using Python as well as experts doing numerical computations. For discussion purpose, I will use ~= as representing an operator testing for approximate equality. (I will show some sample usage below). When teaching students, the availability of both == and ~= would give the opportunity to discuss the fact that numerical computations using floats are approximate, while having the possibility to write code that is readable using the approximate equality operator instead of the strict equality operator when needed. Before I started writing this email, I had noticed that numpy includes at least two functions (isclose and allclose) whose purpose is to perform such approximate comparisons. [1] I had completely missed the fact that Python added the function isclose() in the math module in version 3.5, as described in PEP 485 [0]. I would suggest that the possibility of using operators instead of explicit function calls could make programs easier to write and read, both for beginners and experts alike. I note that PEP 485 makes no mention of introducing operators as a possibility. In addition to an approximate equality operator, it would be natural to include two additional operators, greater than or approximately equal, and lesser than or approximately equal. These could be written respectively as
Some time ago, I created a toy module [2] to enable easy experiments with some syntactic additions to Python. Using this module, I created a very poor and limited implementation that shows what using these proposed o[erators might look like [3] ... My current implementation is slightly different from either Numpy or Python's math.isclose() function [This may no longer be the case soon as I plan to change it to use Python's version instead.] . As is the case for isclose(), there are two paramaters to be set to determine if the values are close enough to be considered approximately equal: an absolute tolerance and a relative one. Given that one cannot pass parameters to an operator, my implementation includes a function which can change the values of these parameters for a given session. If these new operators were to be added to Python, such a function would either have to be added as a builtin or as a special function in the math module. Here's a sample session for demonstration purpose... $ python -m experimental experimental console version 0.9.5. [Python version: 3.6.1] ~~> 0.1 + 0.2 0.30000000000000004 ~~> 0.1 + 0.2 == 0.3 False ~~> from __experimental__ import approx ~~> 0.1 + 0.2 ~= 0.3 # use approximately equal operator True ~~> 0.1 + 0.2 <~= 0.3 True ~~> 0.1 + 0.2 >~= 0.3 True ~~> 2 ** 0.5 1.4142135623730951 ~~> 2**0.5 ~= 1.414 False ~~> set_tols(0.001, 0.001) ~~> 2**0.5 ~= 1.414 True André Roberge [0] https://www.python.org/dev/peps/pep-0485/ [1] See for example https://docs.scipy.org/doc/numpy-1.14.0/reference/generated/numpy.isclose.ht... [2] https://github.com/aroberge/experimental [3] https://github.com/aroberge/experimental/blob/master/experimental/transforme...
On Fri, 15 Jun 2018 14:38:22 -0300 Andre Roberge <andre.roberge@gmail.com> wrote:
On the one hand, this matches the corresponding math notation quite pleasantly. On the other hand, it doesn't seem so useful that it deserves to be a builtin operator. I'm also not sure we want to encourage its use for anything other than experimenting at the prompt and writing unit tests. Being able to set a global tolerance setting is an anti-pattern IMHO, regardless of the operator proposal. Regards Antoine.
On 6/15/18 1:38 PM, Andre Roberge wrote:
The big issue with 'approximately equals' is that the definition of it is hard to come up with. This is especially true for small values. In particular how small does a number need to be to be ~= 0. You also get inconsistencies, you can have a ~= b, and b ~= c but not a ~= c. You can have a + b ~= c but not a ~= c - b should 0.0000001 ~= 0.00000011 To properly handle this sort of thing you need that tolerance parameter, but the values you give should be carefully though about for THAT comparison, having a 'global' value is apt to lead to laziness and wrong answers. -- Richard Damon
On Fri, Jun 15, 2018 at 3:12 PM Richard Damon <Richard@damon-family.org> wrote:
Both you and Antoine Pitrou made an excellent point about relying on non-explicitly defined values for the tolerance parameters. I've made some changes to my proof-of-concept model [1] so that it requires the user to define the two tolerance parameters (relative and absolute) in a way that they are accessible within the scope where the operators are used. I also use the existing isclose() function in the math module instead of my previous version - and use the same name for the two parameters. Here's a sample session:
python -m experimental experimental console version 0.9.6. [Python version: 3.6.1]
~~> from __experimental__ import approx ~~> 0.1 + 0.2 0.30000000000000004 ~~> 0.1 + 0.2 == 0.3 False ~~> # Attempt to use approximate comparison with defining tolerances ~~> 0.1 + 0.2 ~= 0.3 Traceback (most recent call last): File "<console>", line 1, in <module> NameError: name 'rel_tol' is not defined ~~> rel_tol = abs_tol = 1e-8 ~~> 0.1 + 0.2 ~= 0.3 True ~~> 2**0.5 ~= 1.414 False ~~> abs_tol = 0.001 ~~> 2**0.5 ~= 1.414 True I would predict that most of the usage would be in some if or while statements, rather than simple comparisons like those illustrated above. With this change, would using these operators (as "syntactic sugar") be a worthwhile addition for: * people doing heavy numerical work and wanting code as readable as possible * teaching mostly beginners about finite precision for floating point arithmetics * people wishing to have trigonometric functions with arguments in degrees, as in a current discussion on this forum. [1] available on github as mentioned previously or using "pip install experimental André Roberge
On Fri, Jun 15, 2018 at 3:56 PM, Andre Roberge <andre.roberge@gmail.com> wrote:
* people doing heavy numerical work and wanting code as readable as possible
IME serious numerical work doesn't use approximate equality tests at all, except in test assertions.
* teaching mostly beginners about finite precision for floating point arithmetics
Given that approximate equality tests are almost never the right solution, I would be worried that emphasizing them to beginners would send them down the wrong path. This is already a common source of confusion and trap for non-experts.
* people wishing to have trigonometric functions with arguments in degrees, as in a current discussion on this forum.
AFAICT approximate equality checks aren't really useful for that, no. (I also don't understand why people in that argument are so worried about exact precision for 90° and 30° when it's impossible for all the other angles.) Python is *very* stingy with adding new operators; IIRC only 3 have been added over the last ~30 years (**, //, @). I don't think ~= is going to make it. -n -- Nathaniel J. Smith -- https://vorpus.org
On Fri, Jun 15, 2018 at 05:31:57PM -0700, Nathaniel Smith wrote:
I wouldn't go that far. It is quite common to write abs(x - y) < e or similar, to see whether x and y are within a certain distance of each other. APL even made their equals operator an "approximate equality" operator. So I don't think it is completely crazy to want an operator for this. But I think that falls short of "a good idea for Python".
Certainly it is an area that is rife with superstitition, like the idea that you should "never" compare two floats for equality, or folklore about what tolerance you should use. https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-number...
Indeed. The last thing a maths library should be doing is making arbitrary choices that some value is "close enough" and return "the value we think you want". "Hi, the number you gave is pretty close to 60°, so I'm going to round the answer off whether you want me to or not." Its okay for people to make their own determination what "close enough" means, and for many purposes 0.99 could be close enough to 1. But the library shouldn't. [...]
Exponentiation ** goes back to Python 1.5, so I think that's only two new operators :-) -- Steve
On Fri, 15 Jun 2018 14:38:22 -0300 Andre Roberge <andre.roberge@gmail.com> wrote:
On the one hand, this matches the corresponding math notation quite pleasantly. On the other hand, it doesn't seem so useful that it deserves to be a builtin operator. I'm also not sure we want to encourage its use for anything other than experimenting at the prompt and writing unit tests. Being able to set a global tolerance setting is an anti-pattern IMHO, regardless of the operator proposal. Regards Antoine.
On 6/15/18 1:38 PM, Andre Roberge wrote:
The big issue with 'approximately equals' is that the definition of it is hard to come up with. This is especially true for small values. In particular how small does a number need to be to be ~= 0. You also get inconsistencies, you can have a ~= b, and b ~= c but not a ~= c. You can have a + b ~= c but not a ~= c - b should 0.0000001 ~= 0.00000011 To properly handle this sort of thing you need that tolerance parameter, but the values you give should be carefully though about for THAT comparison, having a 'global' value is apt to lead to laziness and wrong answers. -- Richard Damon
On Fri, Jun 15, 2018 at 3:12 PM Richard Damon <Richard@damon-family.org> wrote:
Both you and Antoine Pitrou made an excellent point about relying on non-explicitly defined values for the tolerance parameters. I've made some changes to my proof-of-concept model [1] so that it requires the user to define the two tolerance parameters (relative and absolute) in a way that they are accessible within the scope where the operators are used. I also use the existing isclose() function in the math module instead of my previous version - and use the same name for the two parameters. Here's a sample session:
python -m experimental experimental console version 0.9.6. [Python version: 3.6.1]
~~> from __experimental__ import approx ~~> 0.1 + 0.2 0.30000000000000004 ~~> 0.1 + 0.2 == 0.3 False ~~> # Attempt to use approximate comparison with defining tolerances ~~> 0.1 + 0.2 ~= 0.3 Traceback (most recent call last): File "<console>", line 1, in <module> NameError: name 'rel_tol' is not defined ~~> rel_tol = abs_tol = 1e-8 ~~> 0.1 + 0.2 ~= 0.3 True ~~> 2**0.5 ~= 1.414 False ~~> abs_tol = 0.001 ~~> 2**0.5 ~= 1.414 True I would predict that most of the usage would be in some if or while statements, rather than simple comparisons like those illustrated above. With this change, would using these operators (as "syntactic sugar") be a worthwhile addition for: * people doing heavy numerical work and wanting code as readable as possible * teaching mostly beginners about finite precision for floating point arithmetics * people wishing to have trigonometric functions with arguments in degrees, as in a current discussion on this forum. [1] available on github as mentioned previously or using "pip install experimental André Roberge
On Fri, Jun 15, 2018 at 3:56 PM, Andre Roberge <andre.roberge@gmail.com> wrote:
* people doing heavy numerical work and wanting code as readable as possible
IME serious numerical work doesn't use approximate equality tests at all, except in test assertions.
* teaching mostly beginners about finite precision for floating point arithmetics
Given that approximate equality tests are almost never the right solution, I would be worried that emphasizing them to beginners would send them down the wrong path. This is already a common source of confusion and trap for non-experts.
* people wishing to have trigonometric functions with arguments in degrees, as in a current discussion on this forum.
AFAICT approximate equality checks aren't really useful for that, no. (I also don't understand why people in that argument are so worried about exact precision for 90° and 30° when it's impossible for all the other angles.) Python is *very* stingy with adding new operators; IIRC only 3 have been added over the last ~30 years (**, //, @). I don't think ~= is going to make it. -n -- Nathaniel J. Smith -- https://vorpus.org
On Fri, Jun 15, 2018 at 05:31:57PM -0700, Nathaniel Smith wrote:
I wouldn't go that far. It is quite common to write abs(x - y) < e or similar, to see whether x and y are within a certain distance of each other. APL even made their equals operator an "approximate equality" operator. So I don't think it is completely crazy to want an operator for this. But I think that falls short of "a good idea for Python".
Certainly it is an area that is rife with superstitition, like the idea that you should "never" compare two floats for equality, or folklore about what tolerance you should use. https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-number...
Indeed. The last thing a maths library should be doing is making arbitrary choices that some value is "close enough" and return "the value we think you want". "Hi, the number you gave is pretty close to 60°, so I'm going to round the answer off whether you want me to or not." Its okay for people to make their own determination what "close enough" means, and for many purposes 0.99 could be close enough to 1. But the library shouldn't. [...]
Exponentiation ** goes back to Python 1.5, so I think that's only two new operators :-) -- Steve
participants (6)
-
Andre Roberge -
Antoine Pitrou -
Chris Angelico -
Nathaniel Smith -
Richard Damon -
Steven D'Aprano