[Python-ideas] Float range class

[M.-A. Lemburg]

On 09.01.2015 12:40, Todd wrote:
> On Fri, Jan 9, 2015 at 12:28 PM, M.-A. Lemburg <mal at egenix.com> wrote:
> 
>> On 09.01.2015 12:01, Chris Angelico wrote:
>>> On Fri, Jan 9, 2015 at 9:55 PM, M.-A. Lemburg <mal at egenix.com> wrote:
>>>>> This is what I am talking about.  The idea would be to have something
>> that
>>>>> is, as much as possible, identical to the existing range.  I
>> understand it
>>>>> has floating-point issues, but any other approach would as well.
>>>>
>>>> This should do the trick:
>>>>
>>>> def frange(start, stop, steps):
>>>>     start = float(start)
>>>>     stop = float(stop)
>>>>     steps = int(steps)
>>>>     for i in range(steps + 1):
>>>>         yield ((steps - i) * start + i * stop) / steps
>>>
>>> Thing is, a range object is a lot more than just an iterable. In many
>>> ways, it acts just like list(self) would - you can index it, slice it,
>>> etc:
>>>
>>>>>> r = range(10, 101, 10)
>>>>>> list(r)
>>> [10, 20, 30, 40, 50, 60, 70, 80, 90, 100]
>>>>>> r.index(70)
>>> 6
>>>>>> r[6]
>>> 70
>>>>>> len(r)
>>> 10
>>>>>> r[1:-4:2]
>>> range(20, 70, 20)
>>>
>>> Does frange() need to be able to do all these operations?
>> <snip>
>> IMO, the only reason for having an frange() function in (probably)
>> the math module is to provide an implementation which tries to
>> reduce fp rounding problems to a minimum.
>>
>> Other than that, it's just too simple to add straight to the
>> application code in a way which exactly fits the purpose and
>> functionality needed by that application.
>>
>>
> I think the wide usage of numpy.arange and numpy.linspace is evidence
> against that conclusion.

Well, we're talking about the stdlib here. numpy is used in a
specific application space where such questions arise often.

The scope for the stdlib is different. It's meant to cover
features needed by a very wide range of users in a wide
variety of application spaces.

Having a stdlib functions which returns evenly spaced floats is
useful for people, but more on the grounds that the implementation
can be tricky to get right. The above is just a first stab at it.
I'm sure Mark Dickinson and Tim Peters will have better ideas
on how to reduce fp rounding issues some more.

In general, you always have to find a compromise between usefulness
of new features in the stdlib and the maintenance effort introduced
by them. If there's a very active maintainer, the barrier for
entry is lower. If people just submit a patch and then leave
the code unmaintained, things are different.

That is to say: if you'd volunteer to maintain a rangetools
module for at least the next 5 years, chances are higher this
will get accepted. See Raymond's itertools and collections
as good examples.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 09 2015)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> mxODBC Plone/Zope Database Adapter ...       http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::

   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/