[Python-ideas] Float range class

[Chris Barker]

On Fri, Jan 9, 2015 at 1:24 PM, Guido van Rossum <guido at python.org> wrote:

> On Fri, Jan 9, 2015 at 12:58 PM, Andrew Barnert <
> abarnert at yahoo.com.dmarc.invalid> wrote:
>
>> [...]
>> arange is actually very easy to get right, but hard to _use_ properly. A
>> half-open range of values from 0 to .9 by .3 is going to include a number
>> just under 0.9 if properly implemented. However you slice it, .3*3<.9,
>> .3+.3+.3<.9, etc., so that number belongs in the range. [...]
>>
>
> I don't know if this some kind of fp in-joke that I'm missing, but I find
> that the wording "if properly implemented" comes on a little strong. It
> depends on behavior of IEEE binary fp that's far from obvious -- I observe
> that .3*4 > 1.2, for example.
>

That's the entire point here. See Warren's examples from the other day.

And I went and got all sidetracked, so I think my key point was lost, and I
also think I agree with Andrew, despite my notes being apparently unclear.
So I'm going to try to make a couple clear, simple suggestions:

It would be good to have something that provides ranges of floating point
numbers (and maybe other number-like things, like rational, and Decimals,
and datetimes)

But we should NOT have a floating point range(), rather a floating point
linspace, or similar.

Andrew wrote:

> arange is actually very easy to get right, but hard to _use_ properly.


agreed  -- I wasn't being clear, but that's what I meant -- my point was
that EITHER a range() for FP OR a self-implemented version is all too
likely to get the a different result than the user has in mind. whether
than measn you implimented if poorly or used it poorly is kin dof
irelevant, but your way of expressing it makes it more clear why we dont'
want the "attractive nuisance" of an fp range().


> linspace is harder to get right, but very easy to use properly.


yes, exactly. Also, we need to keep in mind common use cases -- range() is
exactly the right thing for teh common use cases of compatibility with
sequence indexing -- which is irrelvent to FP use.

Either the user cares about the delta, or the number of elements, and they
either care about the end point or not.

range() is oriented to caring about the number elements, secondarily about
the delta, thirdly about the about the end point.

and these all can be inferred from each-other pretty easily with integers.
But the end points and number of elements can not be as easily inferred for
FP.

linspace() is oriented to caring primarily about the end points,
secondarily about the number of elements, only thirdly about the delta.

I would argue that this use case is more common for FP use, AND that
inferring the delta from linspace is less error prone than inferring the
end points from range(), and thus linspace is the "right" thing to
implement for FP.

And probably for the other non-integer types as well.

So, having linspace in the stdlib sounds good--not just to avoid people
> implementing it wrong, but to avoid people implementing and/or using arange
> when they should be using linspace.
>

yes -- so much better said!


> In fact, maybe even make range's TypeError message reference linspace when
> given floats, as sum does for str.join?
> In the less common cases where arange really was what you wanted, and you
> know how to use it, you almost certainly can implement it yourself.


I like that too.

-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 at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150109/bef58bb7/attachment-0001.html>