Re: [Python-ideas] math.nextafter

2017-02-24 Thread Nathaniel Smith 
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

2017-02-24 Thread David Mertz 
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. Lemburg  wrote:

> 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

2017-02-24 Thread Chris Barker - NOAA Federal 
On Feb 24, 2017, at 10:28 AM, Mahmoud Hashemi  wrote:

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

2017-02-24 Thread Mahmoud Hashemi 
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

2017-02-24 Thread Chris Barker 
On Fri, Feb 24, 2017 at 1:40 AM, Juraj Sukop  wrote:

>
>
> 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

2017-02-24 Thread M.-A. Lemburg 
On 24.02.2017 10:13, Nick Coghlan wrote:
> On 6 February 2017 at 20:29, M.-A. Lemburg  wrote:
> 
>> 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

2017-02-24 Thread Nick Coghlan 
On 6 February 2017 at 20:29, M.-A. Lemburg  wrote:

> 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/