Re: [Python-ideas] math.nextafter
On Feb 24, 2017 5:29 PM, "David Mertz"wrote: Marc-André slightly misspelled the recent-ish addition of math.isclose(), but I agree that it is absolutely where a "nextafter" belongs. The function signature is already relatively complex to cover several different but related use cases. I.e.: is_close(a, b, *, rel_tol=1e-09, abs_tol=0.0) -> bool I think an additional keyword-only argument for `nextafter_tol` (maybe a different spelling) would fit very naturally there. This would allow someone to specify 1 for that degree of closeness, but it would also allow them to specify some integer larger than 1 without needed to write a loop calling `nextafter()` repeatedly. My 2c: I disagree -- numerical tolerance based closeness is fundamentally different than floating point representation based closeness (often discussed with the term "ulp" = "unit in the last place". For example, the number that's closest to 1.0 from above is twice as far away in numerical terms as the number that's closest to it from below. Mixing these two concepts in one function is just confusing, and we're not going to run out of names. It's also a little weird to jump from nextafter to isclose, since AFAIK they have pretty much non-overlapping use cases... FWIW, numpy provides all of the following as separate functions: * an isclose equivalent * nextafter * a function for counting the number of ulps between two floats * a function for checking that two floats differ by at most N ulps I'm not enough of an expert on numerical analysis to have an opinion on how useful these would be for Python itself. They certainly are part of a complete IEEE754 implementation, and useful for exploring the details of how floats work, if nothing else. -n ___ 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] math.nextafter
Marc-André slightly misspelled the recent-ish addition of math.isclose(), but I agree that it is absolutely where a "nextafter" belongs. The function signature is already relatively complex to cover several different but related use cases. I.e.: is_close(a, b, *, rel_tol=1e-09, abs_tol=0.0) -> bool I think an additional keyword-only argument for `nextafter_tol` (maybe a different spelling) would fit very naturally there. This would allow someone to specify 1 for that degree of closeness, but it would also allow them to specify some integer larger than 1 without needed to write a loop calling `nextafter()` repeatedly. Yours, David... On Fri, Feb 24, 2017 at 5:29 AM, M.-A. Lemburgwrote: > Perhaps closeto() could be extended to address the use case: > > "Match anything within N number of smallest float representable > intervals around float value x" > > https://www.python.org/dev/peps/pep-0485/ > > This could then be used to detect cases where it doesn't > make sense to run additional rounds of refinement to > find roots or local minima, since IEEE floats simply don't > provide enough accuracy to dig deeper. > -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. ___ 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] math.nextafter
On Feb 24, 2017, at 10:28 AM, Mahmoud Hashemiwrote: By the way, it looks like math doesn't have machine epsilon either: > > > https://en.wikipedia.org/wiki/Machine_epsilon > > Pretty sure machine epsilon is in the sys module's float_info object. Ahh, thanks! I though I remembered it was somewhere. Or are you saying it would be handy to alias sys.float_info.epsilon over to the math module too? That might be a good idea, yes. Particularly if other related functions are added as being discussed. -CHB ___ 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] math.nextafter
By the way, it looks like math doesn't have machine epsilon either: > > > https://en.wikipedia.org/wiki/Machine_epsilon > > which would be handy as well. > > -CHB > > Pretty sure machine epsilon is in the sys module's float_info object. Or are you saying it would be handy to alias sys.float_info.epsilon over to the math module too? Mahmoud ___ 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] math.nextafter
On Fri, Feb 24, 2017 at 1:40 AM, Juraj Sukopwrote: > > > On Fri, Feb 24, 2017 at 5:01 AM, Chris Barker > wrote: > >> cause if your computation was that perfect, why not just check for zero? >> >> > A polynomial root may simply be not representable in double precision > floating-point format. > Indeed. > Per the example I posted above, the best one can hope for in such > situation is to find (x, nextafter(x, float('inf'))) interval which has > opposite function value signs. > I'm not much of a numerical analyst, but I think the number of applications in which the computation is accurate to the limit of float precision is vanishingly small -- so you need something larger than the smallest representable non-zero value anyway. Also many time when one is looking for a "zero", you are really looking for the difference between two values to be zero -- in which case isclose() is the right tool for the job. Thus this kind of thing is useful primarily for "exploring the behaviour of numerical algorithm implementations" as Nick said. Which doesn't mean it wouldn't' be useful to have in Python. Someone said: " it's very much tied to whatever float type Python happens to use on a platform." Which is the whole point -- if one could assume that Python is using IEEE 754 64 bit floats, then you could write these functions yourself but it's built-in then the implementation can make sure it's correct for the platform/etc that you are currently running on. By the way, it looks like math doesn't have machine epsilon either: https://en.wikipedia.org/wiki/Machine_epsilon which would be handy as well. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ 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] math.nextafter
On 24.02.2017 10:13, Nick Coghlan wrote: > On 6 February 2017 at 20:29, M.-A. Lemburgwrote: > >> On 04.02.2017 12:59, Stephan Houben wrote: >>> Hi all, >>> >>> Visual C++ 2015 supports this one: >>> >>> https://msdn.microsoft.com/en-us/library/h0dff77w.aspx >>> >>> In any case, this is easy to implement an efficient fallback in C, unlike >>> the fma() function we discussed some time ago. >>> >>> To put this in a bit wider perspective: would it be useful to investigate >>> how much of the C99 math library could >>> be supported in Python in general? >> >> +1 from me for those features which can be emulated for >> platforms which don't have the math lib function >> available and are not too esoteric (though many of those >> have already been added), e.g. cbt() may be useful. >> >> Now, with respect to the one mentioned in the subject, >> I'm not sure how useful this would be in the stdlib, >> since it's very much tied to whatever float type Python >> happens to use on a platform. >> > > Just from an API point of view, a more idiomatically-Pythonic concept seems > to me to be a "floatrange()" construct, where the default step was defined > by the internal representation (i.e. it would increment by the smallest > possible value). > > I'm not sure of any use cases outside exploring the behaviour of numerical > algorithm implementations in the presence of mathematical discontinuities, > though. Perhaps closeto() could be extended to address the use case: "Match anything within N number of smallest float representable intervals around float value x" https://www.python.org/dev/peps/pep-0485/ This could then be used to detect cases where it doesn't make sense to run additional rounds of refinement to find roots or local minima, since IEEE floats simply don't provide enough accuracy to dig deeper. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Feb 24 2017) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/ ___ 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] math.nextafter
On 6 February 2017 at 20:29, M.-A. Lemburgwrote: > On 04.02.2017 12:59, Stephan Houben wrote: > > Hi all, > > > > Visual C++ 2015 supports this one: > > > > https://msdn.microsoft.com/en-us/library/h0dff77w.aspx > > > > In any case, this is easy to implement an efficient fallback in C, unlike > > the fma() function we discussed some time ago. > > > > To put this in a bit wider perspective: would it be useful to investigate > > how much of the C99 math library could > > be supported in Python in general? > > +1 from me for those features which can be emulated for > platforms which don't have the math lib function > available and are not too esoteric (though many of those > have already been added), e.g. cbt() may be useful. > > Now, with respect to the one mentioned in the subject, > I'm not sure how useful this would be in the stdlib, > since it's very much tied to whatever float type Python > happens to use on a platform. > Just from an API point of view, a more idiomatically-Pythonic concept seems to me to be a "floatrange()" construct, where the default step was defined by the internal representation (i.e. it would increment by the smallest possible value). I'm not sure of any use cases outside exploring the behaviour of numerical algorithm implementations in the presence of mathematical discontinuities, though. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/