I think it's time to accept PEP 485. I've re-read it once more, and it looks like the text is in great shape. (My only recommendation would be to update the Abstract to state that we're specifically adding math.isclose().) A wording question: "This implementation has a flag that lets the user select which relative tolerance test to apply -- this PEP does not suggest that that be retained, but rather than the weak test be selected." -- I think this was meant to say "... rather *that* the weak test be selected", right? (It would be nice if the sample implementation defaulted to the choice in the PEP.) However, those are just minor edits, and I hereby approve the PEP. Thanks Chris and everyone else for the fruitful discussion (and thanks especially to Chris for eventually ending the bikeshedding and writing a PEP that explains each of the choices). Congrats! -- --Guido van Rossum (python.org/~guido)
Thank you Guido. It'll be nice to see this all come to something. Thanks to all who contributed to the discussion -- despite this being a pretty simple function, I learned a lot and far more fully appreciate the nuance of all of this. I'll edit the text as you suggest, and then work on a patch -- I'm sure I'll have questions for Python-dev when I actually do that, but I'll get started on my own and see how far I get. -Chris On Fri, Feb 27, 2015 at 11:38 AM, Guido van Rossum <guido@python.org> wrote:
I think it's time to accept PEP 485. I've re-read it once more, and it looks like the text is in great shape. (My only recommendation would be to update the Abstract to state that we're specifically adding math.isclose().)
A wording question: "This implementation has a flag that lets the user select which relative tolerance test to apply -- this PEP does not suggest that that be retained, but rather than the weak test be selected." -- I think this was meant to say "... rather *that* the weak test be selected", right? (It would be nice if the sample implementation defaulted to the choice in the PEP.)
However, those are just minor edits, and I hereby approve the PEP. Thanks Chris and everyone else for the fruitful discussion (and thanks especially to Chris for eventually ending the bikeshedding and writing a PEP that explains each of the choices). Congrats!
-- --Guido van Rossum (python.org/~guido)
-- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On 02/27/2015 12:07 PM, Chris Barker wrote:
Thank you Guido.
It'll be nice to see this all come to something.
Thanks to all who contributed to the discussion -- despite this being a pretty simple function, I learned a lot and far more fully appreciate the nuance of all of this.
I'll edit the text as you suggest, and then work on a patch -- I'm sure I'll have questions for Python-dev when I actually do that, but I'll get started on my own and see how far I get.
-Chris
There's another typo: The "Large tolerances" section, references a "string test". Perhaps that should be "strong test", but that would seem to contradict the sentence which follows. -- Dr. Gary Herron Department of Computer Science DigiPen Institute of Technology (425) 895-4418
On Fri, Feb 27, 2015 at 11:38 AM, Guido van Rossum <guido@python.org <mailto:guido@python.org>> wrote:
I think it's time to accept PEP 485. I've re-read it once more, and it looks like the text is in great shape. (My only recommendation would be to update the Abstract to state that we're specifically adding math.isclose().)
A wording question: "This implementation has a flag that lets the user select which relative tolerance test to apply -- this PEP does not suggest that that be retained, but rather than the weak test be selected." -- I think this was meant to say "... rather *that* the weak test be selected", right? (It would be nice if the sample implementation defaulted to the choice in the PEP.)
However, those are just minor edits, and I hereby approve the PEP. Thanks Chris and everyone else for the fruitful discussion (and thanks especially to Chris for eventually ending the bikeshedding and writing a PEP that explains each of the choices). Congrats!
-- --Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
--
Christopher Barker, Ph.D. Oceanographer
Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov <mailto:Chris.Barker@noaa.gov>
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/gherron%40islandtraining....
On 28 Feb 2015 06:16, "Chris Barker" <chris.barker@noaa.gov> wrote:
Thank you Guido.
It'll be nice to see this all come to something.
Thanks to all who contributed to the discussion -- despite this being a
pretty simple function, I learned a lot and far more fully appreciate the nuance of all of this. The simple enhancements are often the hardest to get consensus on, but also often the most beneficial in the long run. Thanks for pushing this one through to completion! Regards, Nick.
On Fri, Feb 27, 2015 at 12:07 PM, Chris Barker <chris.barker@noaa.gov> wrote:
I'll edit the text as you suggest,
Done.
and then work on a patch -- I'm sure I'll have questions for Python-dev when I actually do that, but I'll get started on my own and see how far I get.
OK -- big question 1: As far as I can tell, the math module is entirely a C extension. So I can: 1) write isclose() in C -- I could probably do that (It's been a while -- I'm a big Cython fan these days...) and I'd probably punt on having it work with anything other than floats if I did that -- which would fit how most of the match module works anyway. 2) Write it in Python, and monkey-patch it in to the math module -- I honestly have no idea how to do that, but as I can add a new name to the math module after importing it, it should be doable --but I have no idea where the code would go. Suggestions?? Thanks, -Chris
-Chris
On Fri, Feb 27, 2015 at 11:38 AM, Guido van Rossum <guido@python.org> wrote:
I think it's time to accept PEP 485. I've re-read it once more, and it looks like the text is in great shape. (My only recommendation would be to update the Abstract to state that we're specifically adding math.isclose().)
A wording question: "This implementation has a flag that lets the user select which relative tolerance test to apply -- this PEP does not suggest that that be retained, but rather than the weak test be selected." -- I think this was meant to say "... rather *that* the weak test be selected", right? (It would be nice if the sample implementation defaulted to the choice in the PEP.)
However, those are just minor edits, and I hereby approve the PEP. Thanks Chris and everyone else for the fruitful discussion (and thanks especially to Chris for eventually ending the bikeshedding and writing a PEP that explains each of the choices). Congrats!
-- --Guido van Rossum (python.org/~guido)
--
Christopher Barker, Ph.D. Oceanographer
Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
-- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
It should be written in C. I thought you knew. :-) I guess it's okay to drop Decimal support (*). Complex support probably should be in cmath. But this is an amendmend to the PEP as accepted. If anyone cares about these changes they should speak up, otherwise the PEP should be updated. (*) Adding it to the decimal module would require a discussion with Raymond Hettinger, but Decimal users can probably copy and paste the formula from the PEP. On Monday, March 2, 2015, Chris Barker <chris.barker@noaa.gov> wrote:
On Fri, Feb 27, 2015 at 12:07 PM, Chris Barker <chris.barker@noaa.gov <javascript:_e(%7B%7D,'cvml','chris.barker@noaa.gov');>> wrote:
I'll edit the text as you suggest,
Done.
and then work on a patch -- I'm sure I'll have questions for Python-dev when I actually do that, but I'll get started on my own and see how far I get.
OK -- big question 1:
As far as I can tell, the math module is entirely a C extension. So I can:
1) write isclose() in C -- I could probably do that (It's been a while -- I'm a big Cython fan these days...) and I'd probably punt on having it work with anything other than floats if I did that -- which would fit how most of the match module works anyway.
2) Write it in Python, and monkey-patch it in to the math module -- I honestly have no idea how to do that, but as I can add a new name to the math module after importing it, it should be doable --but I have no idea where the code would go.
Suggestions??
Thanks, -Chris
-Chris
On Fri, Feb 27, 2015 at 11:38 AM, Guido van Rossum <guido@python.org <javascript:_e(%7B%7D,'cvml','guido@python.org');>> wrote:
I think it's time to accept PEP 485. I've re-read it once more, and it looks like the text is in great shape. (My only recommendation would be to update the Abstract to state that we're specifically adding math.isclose().)
A wording question: "This implementation has a flag that lets the user select which relative tolerance test to apply -- this PEP does not suggest that that be retained, but rather than the weak test be selected." -- I think this was meant to say "... rather *that* the weak test be selected", right? (It would be nice if the sample implementation defaulted to the choice in the PEP.)
However, those are just minor edits, and I hereby approve the PEP. Thanks Chris and everyone else for the fruitful discussion (and thanks especially to Chris for eventually ending the bikeshedding and writing a PEP that explains each of the choices). Congrats!
-- --Guido van Rossum (python.org/~guido)
--
Christopher Barker, Ph.D. Oceanographer
Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov <javascript:_e(%7B%7D,'cvml','Chris.Barker@noaa.gov');>
--
Christopher Barker, Ph.D. Oceanographer
Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov <javascript:_e(%7B%7D,'cvml','Chris.Barker@noaa.gov');>
-- --Guido van Rossum (on iPad)
On Mon, Mar 2, 2015 at 10:39 PM, Guido van Rossum <guido@python.org> wrote:
It should be written in C. I thought you knew. :-)
It crossed my mind when we talked about the math module -- but I didn't really think about it... I guess it's okay to drop Decimal support (*). Complex support probably
should be in cmath.
fair enough -- and easy enough to do if we do float-only in math, and complex-only in cmath. But this is an amendmend to the PEP as accepted. If anyone cares about
these changes they should speak up, otherwise the PEP should be updated.
will do.
(*) Adding it to the decimal module would require a discussion with Raymond Hettinger, but Decimal users can probably copy and paste the formula from the PEP.
yup -- but maybe worth putting in there while we're at it. though as Decimal is arbitrary precision, maybe it's not needed.... -Chris
On Monday, March 2, 2015, Chris Barker <chris.barker@noaa.gov> wrote:
On Fri, Feb 27, 2015 at 12:07 PM, Chris Barker <chris.barker@noaa.gov> wrote:
I'll edit the text as you suggest,
Done.
and then work on a patch -- I'm sure I'll have questions for Python-dev when I actually do that, but I'll get started on my own and see how far I get.
OK -- big question 1:
As far as I can tell, the math module is entirely a C extension. So I can:
1) write isclose() in C -- I could probably do that (It's been a while -- I'm a big Cython fan these days...) and I'd probably punt on having it work with anything other than floats if I did that -- which would fit how most of the match module works anyway.
2) Write it in Python, and monkey-patch it in to the math module -- I honestly have no idea how to do that, but as I can add a new name to the math module after importing it, it should be doable --but I have no idea where the code would go.
Suggestions??
Thanks, -Chris
-Chris
On Fri, Feb 27, 2015 at 11:38 AM, Guido van Rossum <guido@python.org> wrote:
I think it's time to accept PEP 485. I've re-read it once more, and it looks like the text is in great shape. (My only recommendation would be to update the Abstract to state that we're specifically adding math.isclose().)
A wording question: "This implementation has a flag that lets the user select which relative tolerance test to apply -- this PEP does not suggest that that be retained, but rather than the weak test be selected." -- I think this was meant to say "... rather *that* the weak test be selected", right? (It would be nice if the sample implementation defaulted to the choice in the PEP.)
However, those are just minor edits, and I hereby approve the PEP. Thanks Chris and everyone else for the fruitful discussion (and thanks especially to Chris for eventually ending the bikeshedding and writing a PEP that explains each of the choices). Congrats!
-- --Guido van Rossum (python.org/~guido)
--
Christopher Barker, Ph.D. Oceanographer
Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
--
Christopher Barker, Ph.D. Oceanographer
Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
-- --Guido van Rossum (on iPad)
-- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On Mon, Mar 2, 2015 at 10:48 PM, Chris Barker <chris.barker@noaa.gov> wrote:
On Mon, Mar 2, 2015 at 10:39 PM, Guido van Rossum <guido@python.org> wrote:
(*) Adding it to the decimal module would require a discussion with
Raymond Hettinger, but Decimal users can probably copy and paste the formula from the PEP.
yup -- but maybe worth putting in there while we're at it. though as Decimal is arbitrary precision, maybe it's not needed....
It's not really arbitrary precision, it's decimal *floating* point with a large but finite precision, so all the same arguments apply. But my reasoning was more that (at least when I was last involved in the project) the decimal module tries to stick pretty close to the IEEE 754 standard (maybe nowadays a later version?) and random Python-only additions are controversial. -- --Guido van Rossum (python.org/~guido)
2015-03-03 6:25 GMT+01:00 Chris Barker <chris.barker@noaa.gov>:
As far as I can tell, the math module is entirely a C extension. So I can: (...) 2) Write it in Python, and monkey-patch it in to the math module -- I honestly have no idea how to do that, but as I can add a new name to the math module after importing it, it should be doable --but I have no idea where the code would go.
Maybe it's time to rename the math module to _math and create a math.py module, like _decimal/decimal? math.py should end with "from _math import *". It may be interesting to have Python implementation of math.fsum(), math.factorial(), math.degrees() and math.radians(). Extract of fsum() comment: Full precision summation of a sequence of floats. def msum(iterable): partials = [] # sorted, non-overlapping partial sums for x in iterable: i = 0 for y in partials: if abs(x) < abs(y): x, y = y, x hi = x + y lo = y - (hi - x) if lo: partials[i] = lo i += 1 x = hi partials[i:] = [x] return sum_exact(partials) The C implementation of factorial is not naive: "Divide-and-conquer factorial algorithm" (see the C code). Obvisouly, a expect lower performances from Python code manipulating numbers (because of the cost of boxing-unboxing, cost of functions calls, etc.). But it might help other Python implementations to implement the math module. Victor
On 03/03/2015 01:17 AM, Victor Stinner wrote:
2015-03-03 6:25 GMT+01:00 Chris Barker :
As far as I can tell, the math module is entirely a C extension. So I can:
2) Write it in Python, and monkey-patch it in to the math module -- I honestly have no idea how to do that, but as I can add a new name to the math module after importing it, it should be doable --but I have no idea where the code would go.
Maybe it's time to rename the math module to _math and create a math.py module, like _decimal/decimal? math.py should end with "from _math import *".
+1 -- ~Ethan~
On Tue, Mar 3, 2015 at 8:43 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
On 03/03/2015 01:17 AM, Victor Stinner wrote:
Maybe it's time to rename the math module to _math and create a math.py module, like _decimal/decimal? math.py should end with "from _math import *".
+1
What do folks think? If we're going to do this, I'll write isclose() in python. And I could do the work to split it out, too, I suppose. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
No. On Wed, Mar 4, 2015 at 12:12 PM, Chris Barker <chris.barker@noaa.gov> wrote:
On Tue, Mar 3, 2015 at 8:43 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
On 03/03/2015 01:17 AM, Victor Stinner wrote:
Maybe it's time to rename the math module to _math and create a math.py module, like _decimal/decimal? math.py should end with "from _math import *".
+1
What do folks think? If we're going to do this, I'll write isclose() in python. And I could do the work to split it out, too, I suppose.
-Chris
--
Christopher Barker, Ph.D. Oceanographer
Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (python.org/~guido)
On Wed, Mar 4, 2015 at 3:14 PM Chris Barker <chris.barker@noaa.gov> wrote:
On Tue, Mar 3, 2015 at 8:43 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
On 03/03/2015 01:17 AM, Victor Stinner wrote:
Maybe it's time to rename the math module to _math and create a math.py module, like _decimal/decimal? math.py should end with "from _math import *".
+1
What do folks think? If we're going to do this, I'll write isclose() in python. And I could do the work to split it out, too, I suppose.
My vote -- as always -- is to do it in Python. If someone is sufficiently motivated to re-implement in C then that's great, but I don't think it should be required to be in C.
In this case I disagree. The math module mostly wraps the C math library and the bar should remain high for things to be added to it. Let this be someone's opportunity to learn C (I guess not Chris's :-). On Wed, Mar 4, 2015 at 12:23 PM, Brett Cannon <brett@python.org> wrote:
On Wed, Mar 4, 2015 at 3:14 PM Chris Barker <chris.barker@noaa.gov> wrote:
On Tue, Mar 3, 2015 at 8:43 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
On 03/03/2015 01:17 AM, Victor Stinner wrote:
Maybe it's time to rename the math module to _math and create a math.py module, like _decimal/decimal? math.py should end with "from _math import *".
+1
What do folks think? If we're going to do this, I'll write isclose() in python. And I could do the work to split it out, too, I suppose.
My vote -- as always -- is to do it in Python. If someone is sufficiently motivated to re-implement in C then that's great, but I don't think it should be required to be in C.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (python.org/~guido)
On Wed, Mar 4, 2015 at 12:33 PM, Guido van Rossum <guido@python.org> wrote:
In this case I disagree. The math module mostly wraps the C math library and the bar should remain high for things to be added to it. Let this be someone's opportunity to learn C (I guess not Chris's :-).
As it happens, the first C code I ever wrote, beyond toy examples, was python extensions. I dropped that for Cython a good while ago, but I can remember enough for this simple function ;-) I agree that it's not worth going to python for the math module for just this -- but others were proposing other reasons to do it. Back to look at K&R ;-) -Chris
On Wed, Mar 4, 2015 at 12:23 PM, Brett Cannon <brett@python.org> wrote:
On Wed, Mar 4, 2015 at 3:14 PM Chris Barker <chris.barker@noaa.gov> wrote:
On Tue, Mar 3, 2015 at 8:43 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
On 03/03/2015 01:17 AM, Victor Stinner wrote:
Maybe it's time to rename the math module to _math and create a math.py module, like _decimal/decimal? math.py should end with "from _math import *".
+1
What do folks think? If we're going to do this, I'll write isclose() in python. And I could do the work to split it out, too, I suppose.
My vote -- as always -- is to do it in Python. If someone is sufficiently motivated to re-implement in C then that's great, but I don't think it should be required to be in C.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (python.org/~guido)
-- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
2015-03-03 10:17 GMT+01:00 Victor Stinner <victor.stinner@gmail.com>:
Maybe it's time to rename the math module to _math and create a math.py module, like _decimal/decimal? math.py should end with "from _math import *".
Since the idea looks to be well accepted, I proposed a patch to implement it: http://bugs.python.org/issue23595? math.py contains 4 constants (e, pi, inf, nan; nan is optionnal) and 4 functions: degrees(), radians(), factorial(), fsum(). See the issue for details. Victor
participants (7)
-
Brett Cannon -
Chris Barker -
Ethan Furman -
Gary Herron -
Guido van Rossum -
Nick Coghlan -
Victor Stinner