Re: [Python-ideas] Approximately equal operator
On Sat, Jun 16, 2018 at 8:51 PM, Steven D'Aprano wrote: >> 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. > > Exponentiation ** goes back to Python 1.5, so I think that's only two > new operators :-) > I'm not sure if they count or not, but 'await' and 'yield' are kinda like unary operators. But yeah, the language is deliberately stingy there. ChrisA ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Approximately equal operator
On Fri, Jun 15, 2018 at 05:31:57PM -0700, Nathaniel Smith wrote: > On Fri, Jun 15, 2018 at 3:56 PM, Andre Roberge > 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. 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". > > * 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. 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-numbers-2012-edition/ > > * 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. 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. [...] > 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. Exponentiation ** goes back to Python 1.5, so I think that's only two new operators :-) -- Steve ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Approximately equal operator
On Fri, Jun 15, 2018 at 3:56 PM, Andre Roberge 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 ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Approximately equal operator
On 6/15/18 1:38 PM, Andre Roberge wrote: > 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 >~= and <~=. I did consider using some relevant utf-8 > symbol instead of combination of ascii characters, but I think that it > would be easier to write programs if one does not require characters > nor found on any normal keyboard. > > 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.30004 > ~~> 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.html > > [2] https://github.com/aroberge/experimental > > [3] > https://github.com/aroberge/experimental/blob/master/experimental/transformers/readme.md#approxpy > 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.001 ~= 0.0011 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 ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Approximately equal operator
On Fri, 15 Jun 2018 14:38:22 -0300 Andre Roberge wrote: > > 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.30004 > ~~> 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 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. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Approximately equal operator
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 >~= and <~=. I did consider using some relevant utf-8 symbol instead of combination of ascii characters, but I think that it would be easier to write programs if one does not require characters nor found on any normal keyboard. 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.30004 ~~> 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.html [2] https://github.com/aroberge/experimental [3] https://github.com/aroberge/experimental/blob/master/experimental/transformers/readme.md#approxpy ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
