On Thu, 29 Sep 2011 11:36:21 +1300, Greg Ewing wrote:
>> I do hope, though, that the chosen name is *not*:
>>
>> - 'interval'
>>
>> - 'interpolate' or similar
>
> Would 'subdivide' be acceptable?
I'm not great at finding names, and I don't totally love it, but I
certainly don't see any probl
Fernando Perez wrote:
Now, I *suspect* (but don't remember for sure) that the option to have it
right-hand-open-ended was to match the mental model people have for range:
In [5]: linspace(0, 10, 10, endpoint=False)
Out[5]: array([ 0., 1., 2., 3., 4., 5., 6., 7., 8., 9.])
In [6]: rang
On Tue, 27 Sep 2011 11:25:48 +1000, Steven D'Aprano wrote:
> The audience for numpy is a small minority of Python users, and they
Certainly, though I'd like to mention that scientific computing is a major
success story for Python, so hopefully it's a minority with something to
contribute
> te
Ethan Furman wrote:
Well, actually, I'd be using it with dates. ;)
Seems to me that one size isn't going to fit all.
Maybe we really want two functions:
interpolate(start, end, count)
Requires a type supporting addition and division,
designed to work predictably and accurat
Ethan Furman writes:
> Well, actually, I'd be using it with dates. ;)
Why are you representing dates with floats?
(That's a rhetorical question, don't answer it.)
This is the whole problem with this discussion. Guido is saying (and
I think it's plausible though I don't have enough experience
On Sep 27, 2011, at 3:22 PM, Ethan Furman wrote:
> Well, actually, I'd be using it with dates. ;)
FWIW, an approach using itertools is pretty general but even it doesn't work
for dates :-)
>>> from itertools import count, takewhile
>>> from decimal import Decimal
>>> from fractions import Fra
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/27/2011 05:39 PM, Greg Ewing wrote:
> Ethan Furman wrote:
>
>> If it's generic, why should it live in math?
>
> Generic? Maybe that's it: grange()
>
> It's also an English word, unfortunately one with a completely
> unrelated meaning. :-(
One
Guido van Rossum wrote:
On Tue, Sep 27, 2011 at 1:21 PM, Ethan Furman wrote:
Guido van Rossum wrote:
But why offer an API that is an attractive nuisance? I don't think
that it is a burden to the user to have to specify "from 0 to 2 inches
in 8 steps" instead of "from 0 to 2 inches in 1/4 inch
Ethan Furman wrote:
If it's generic, why should it live in math?
Generic? Maybe that's it: grange()
It's also an English word, unfortunately one with a
completely unrelated meaning. :-(
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http
Alexander Belopolsky wrote:
("Comb" (noun) brings up the right image, but is probably too
informal and may be confused with a short for "combination.")
And also with "comb filter" for those who are into
signal processing.
--
Greg
___
Python-Dev mai
On Tue, Sep 27, 2011 at 1:21 PM, Ethan Furman wrote:
> Guido van Rossum wrote:
>>
>> But why offer an API that is an attractive nuisance? I don't think
>> that it is a burden to the user to have to specify "from 0 to 2 inches
>> in 8 steps" instead of "from 0 to 2 inches in 1/4 inch steps". (And
>
Alexander Belopolsky wrote:
I don't think we'll gain anything by
copying numpy code because linspace(start, stop, num) is effectively
just
arange(0, num) * step + start
I don't think the intention was to literally copy the
code, but to investigate borrowing the algorithm, in case
it was using
Guido van Rossum wrote:
But why offer an API that is an attractive nuisance? I don't think
that it is a burden to the user to have to specify "from 0 to 2 inches
in 8 steps" instead of "from 0 to 2 inches in 1/4 inch steps". (And
what if they tried to say "from 0 to 3 1/4 inches in 1/2 inch steps
On Tue, Sep 27, 2011 at 1:12 PM, Eric Snow wrote:
> On Tue, Sep 27, 2011 at 12:20 PM, Ethan Furman wrote:
>> Good points. So how about:
>>
>> some_name_here(start, stop, *, step=None, count=None)
>>
>> ? I personally would use the step value far more often than the count
>> value.
>
> Let's cal
On Tue, Sep 27, 2011 at 1:05 PM, Alexander Belopolsky
wrote:
> On Tue, Sep 27, 2011 at 2:53 PM, Guido van Rossum wrote:
>> On Tue, Sep 27, 2011 at 11:48 AM, Alexander Belopolsky
>> wrote:
>>> On Tue, Sep 27, 2011 at 2:36 PM, Guido van Rossum wrote:
>>> ..
But that's exactly what we don't *
On Tue, Sep 27, 2011 at 12:20 PM, Ethan Furman wrote:
> Good points. So how about:
>
> some_name_here(start, stop, *, step=None, count=None)
>
> ? I personally would use the step value far more often than the count
> value.
Let's call it xrange() or maybe range_ex().But seriously,
here's an
On Tue, Sep 27, 2011 at 2:53 PM, Guido van Rossum wrote:
> On Tue, Sep 27, 2011 at 11:48 AM, Alexander Belopolsky
> wrote:
>> On Tue, Sep 27, 2011 at 2:36 PM, Guido van Rossum wrote:
>> ..
>>> But that's exactly what we don't *want* you to do! Because (unless you
>>> are a numerical wizard) you
On 9/27/2011 1:03 PM, Guido van Rossum wrote:
mimicking the behavior of range() for floats is a bad idea, and that
we need to come up with a name for an API that takes start/stop/count
arguments instead of start/stop/step.
[In the following, I use count as the number of intervals; the number o
Guido van Rossum wrote:
On Tue, Sep 27, 2011 at 11:20 AM, Ethan Furman wrote:
I personally would use the step value far more often than the count
value.
But that's exactly what we don't *want* you to do! Because (unless you
are a numerical wizard) you probably aren't doing the error analysis
On Tue, Sep 27, 2011 at 11:48 AM, Alexander Belopolsky
wrote:
> On Tue, Sep 27, 2011 at 2:36 PM, Guido van Rossum wrote:
> ..
>> But that's exactly what we don't *want* you to do! Because (unless you
>> are a numerical wizard) you probably aren't doing the error analysis
>> needed to avoid the "u
On Tue, Sep 27, 2011 at 2:36 PM, Guido van Rossum wrote:
..
> But that's exactly what we don't *want* you to do! Because (unless you
> are a numerical wizard) you probably aren't doing the error analysis
> needed to avoid the "unexpected extra point" problem due to floating
> point inaccuracies. F
On Tue, Sep 27, 2011 at 2:20 PM, Ethan Furman wrote:
..
> Good points. So how about:
>
> some_name_here(start, stop, *, step=None, count=None)
>
+1
The unusual optional first arguments is one of the things I dislike
about range(). Shouldn't step default to 1.0? Also, when count is
given, stop
On Tue, Sep 27, 2011 at 11:20 AM, Ethan Furman wrote:
>I personally would use the step value far more often than the count
> value.
But that's exactly what we don't *want* you to do! Because (unless you
are a numerical wizard) you probably aren't doing the error analysis
needed to avoid the "unex
Steven D'Aprano wrote:
Ethan Furman wrote:
What about the idea of this signature?
frange([start], stop, step=None, count=None)
Then when count is desired, it can be specified, and when step is
sufficient, no change is necessary.
A default of start=0 makes sense for integer range, because t
Ethan Furman wrote:
What about the idea of this signature?
frange([start], stop, step=None, count=None)
Then when count is desired, it can be specified, and when step is
sufficient, no change is necessary.
A default of start=0 makes sense for integer range, because the most
common use for
Guido van Rossum wrote:
On Tue, Sep 27, 2011 at 10:11 AM, Alexander Belopolsky wrote:
The name "frange" does not necessarily imply that we have to mimic the
API completely. As long as frange(10.0) and frange(1.0, 10.0) works
as expected while addressing floating point subtleties through
optiona
On Tue, Sep 27, 2011 at 10:11 AM, Alexander Belopolsky
wrote:
> On Tue, Sep 27, 2011 at 1:03 PM, Guido van Rossum wrote:
> ..
>> Um, I think you better read the thread. :-) I successfully argued that
>> mimicking the behavior of range() for floats is a bad idea, and that
>> we need to come up wit
On Tue, Sep 27, 2011 at 1:03 PM, Guido van Rossum wrote:
..
> Um, I think you better read the thread. :-) I successfully argued that
> mimicking the behavior of range() for floats is a bad idea, and that
> we need to come up with a name for an API that takes start/stop/count
> arguments instead of
I as well think the construct should support other types as it sounds an
awful lot like the missing for(;;) loop construct.
Concerning the api, if we use spread(start, step, count) we don't rely on a
division method even though the caller probably does. Just mentioning
another option.
--Yuval Gre
On Tue, Sep 27, 2011 at 9:16 AM, Alexander Belopolsky
wrote:
> On Tue, Sep 27, 2011 at 11:44 AM, Raymond Hettinger
> wrote:
> ..
>> In the math module, we used an f prefix to differentiate math.fsum() from
>> the built-in sum() function. That suggests frange() as a possible name for
>> a varia
On Tue, Sep 27, 2011 at 12:20 PM, Steven D'Aprano wrote:
> If it happened
> to support dates, that would be great, but I think that a daterange()
> function in the datetime module would be more appropriate.
Or even more appropriately in the calendar module. The problem is
that we may already hav
Steven D'Aprano wrote:
Alexander Belopolsky wrote:
In addition to Steven's criticisms of numpy.linspace(), I would like a
new function to work with types other than float. It certainly makes
sense to have range-like functionality for fractions and decimal
floats, but also I often find a need t
Alexander Belopolsky wrote:
In addition to Steven's criticisms of numpy.linspace(), I would like a
new function to work with types other than float. It certainly makes
sense to have range-like functionality for fractions and decimal
floats, but also I often find a need to generate a list of equ
On Tue, Sep 27, 2011 at 11:44 AM, Raymond Hettinger
wrote:
..
> In the math module, we used an f prefix to differentiate math.fsum() from the
> built-in sum() function. That suggests frange() as a possible name for a
> variant of range() that creates floats.
>
> That works reasonably well if th
Raymond Hettinger wrote:
On Sep 27, 2011, at 11:24 AM, Ethan Furman wrote:
Alexander Belopolsky wrote:
On Tue, Sep 27, 2011 at 2:23 AM, Greg Ewing wrote:
..
And I don't like "linspace" either. Something more self
explanatory such as "subdivide" or "interpolate" might
be better.
"Grid" would
Alexander Belopolsky wrote:
On Tue, Sep 27, 2011 at 2:23 AM, Greg Ewing wrote:
..
And I don't like "linspace" either. Something more self
explanatory such as "subdivide" or "interpolate" might
be better.
"Grid" would be nice and short, but may suggest 2-dimentional result.
Whatever word we c
On Sep 27, 2011, at 11:24 AM, Ethan Furman wrote:
> Alexander Belopolsky wrote:
>> On Tue, Sep 27, 2011 at 2:23 AM, Greg Ewing
>> wrote:
>> ..
>>> And I don't like "linspace" either. Something more self
>>> explanatory such as "subdivide" or "interpolate" might
>>> be better.
>> "Grid" would be
Alexander Belopolsky wrote:
On Tue, Sep 27, 2011 at 2:23 AM, Greg Ewing wrote:
..
And I don't like "linspace" either. Something more self
explanatory such as "subdivide" or "interpolate" might
be better.
"Grid" would be nice and short, but may suggest 2-dimentional result.
Whatever word we c
On Tue, Sep 27, 2011 at 2:23 AM, Greg Ewing wrote:
..
> And I don't like "linspace" either. Something more self
> explanatory such as "subdivide" or "interpolate" might
> be better.
"Grid" would be nice and short, but may suggest 2-dimentional result.
Whatever word we choose, I think it should b
On Mon, Sep 26, 2011 at 9:25 PM, Steven D'Aprano wrote:
..
> The audience for numpy is a small minority of Python users, and they tend to
> be more sophisticated. I'm sure they can cope with two functions with
> different APIs
>
> While continuity of API might be a good thing, we shouldn't accept
Guido van Rossum wrote:
Or, maybe what I'm trying to say is, if the
user has start/end/count but the API wants start/step/count, after
computing step = (end-start) / count, the value of start + count*step
might not quite equal to end; whereas if the user has start/step/count
but the API wants sta
On Mon, Sep 26, 2011 at 6:25 PM, Steven D'Aprano wrote:
> While continuity of API might be a good thing, we shouldn't accept a poor
> API just for the sake of continuity. I have some criticisms of the linspace
> API.
[...]
> * I'm not sure that start/end/count is a better API than start/step/coun
Fernando Perez wrote:
On Sat, 24 Sep 2011 08:13:11 -0700, Guido van Rossum wrote:
I expect that to implement a version worthy of the stdlib math module,
i.e. that computes values that are correct within 0.5ULP under all
circumstances (e.g. lots of steps, or an end point close to the end of
the
On Sat, 24 Sep 2011 08:13:11 -0700, Guido van Rossum wrote:
> I expect that to implement a version worthy of the stdlib math module,
> i.e. that computes values that are correct within 0.5ULP under all
> circumstances (e.g. lots of steps, or an end point close to the end of
> the floating point ra
On Sat, Sep 24, 2011 at 10:21 PM, Steven D'Aprano wrote:
> Guido van Rossum wrote:
>> I believe this API is fundamentally wrong for float ranges, even if
>> it's great for int ranges, and I will fight against adding it to the
>> stdlib in that form.
>
> I wasn't proposing it to be in the standard
Guido van Rossum wrote:
On Fri, Sep 23, 2011 at 7:13 PM, Steven D'Aprano wrote:
http://code.activestate.com/recipes/577068-floating-point-range/
I notice that your examples carefully skirt around the rounding issues.
I also carefully *didn't* claim that it made rounding issues disappear
compl
On 9/23/2011 10:40 PM, Guido van Rossum wrote:
On Fri, Sep 23, 2011 at 7:13 PM, Steven D'Aprano wrote:
I also carefully *didn't* claim that it made rounding issues disappear
completely. I'll add a note clarifying that rounding still occurs and as a
consequence results can be unexpected.
To
On Fri, Sep 23, 2011 at 11:55 PM, Georg Brandl wrote:
> Am 24.09.2011 04:40, schrieb Guido van Rossum:
>> On Fri, Sep 23, 2011 at 7:13 PM, Steven D'Aprano wrote:
> http://code.activestate.com/recipes/577068-floating-point-range/
I notice that your examples carefully skirt around the
Am 24.09.2011 04:40, schrieb Guido van Rossum:
> On Fri, Sep 23, 2011 at 7:13 PM, Steven D'Aprano wrote:
http://code.activestate.com/recipes/577068-floating-point-range/
>>>
>>> I notice that your examples carefully skirt around the rounding issues.
>>
>> I also carefully *didn't* claim that
On Fri, Sep 23, 2011 at 7:13 PM, Steven D'Aprano wrote:
>>> http://code.activestate.com/recipes/577068-floating-point-range/
>>
>> I notice that your examples carefully skirt around the rounding issues.
>
> I also carefully *didn't* claim that it made rounding issues disappear
> completely. I'll a
Guido van Rossum wrote:
On Fri, Sep 23, 2011 at 6:36 PM, Steven D'Aprano wrote:
Ethan Furman wrote:
A question came up on StackOverflow about range objects and floating point
numbers. I thought about writing an frange that did for floats what range
does for ints,
For what it's worth, here's
On Fri, Sep 23, 2011 at 6:36 PM, Steven D'Aprano wrote:
> Ethan Furman wrote:
>>
>> A question came up on StackOverflow about range objects and floating point
>> numbers. I thought about writing an frange that did for floats what range
>> does for ints,
>
>
> For what it's worth, here's mine:
>
>
Ethan Furman wrote:
A question came up on StackOverflow about range objects and floating
point numbers. I thought about writing an frange that did for floats
what range does for ints,
For what it's worth, here's mine:
http://code.activestate.com/recipes/577068-floating-point-range/
--
S
Ethan Furman wrote:
The only reason I'm aware of at the moment is to prevent loss of
functionality from 2.x range to 3.x range.
Since 2.x range(...) is equivalent to 3.x list(range(...)), I don't
see any loss of functionality there.
Comparing range objects directly in 3.x is like comparing xr
Martin v. Löwis wrote:
Yes, I realize this is because range returned a list in 2.x. However,
aren't __contains__, __getitem__, count, and index implemented in 3.x
range because 2.x range returned lists?
No, they are implemented because they are meaningful, and with an
obvious meaning. "Is 30 i
> Yes, I realize this is because range returned a list in 2.x. However,
> aren't __contains__, __getitem__, count, and index implemented in 3.x
> range because 2.x range returned lists?
No, they are implemented because they are meaningful, and with an
obvious meaning. "Is 30 in the range from 10
Le Fri, 23 Sep 2011 13:23:26 -0700,
Ethan Furman a écrit :
>
> So the question becomes, Why does it implement the Sequence ABC?
Because these operations are trivial to implement and it would be
suboptimal to have to instantiate the full list to run them?
_
On Fri, Sep 23, 2011 at 1:23 PM, Ethan Furman wrote:
> The only reason I'm aware of at the moment is to prevent loss of
> functionality from 2.x range to 3.x range.
>
> I'm -0 with a decision to not have range be orderable; but I understand
> there are bigger fish to fry. :)
I don't believe ther
Benjamin Peterson wrote:
2011/9/23 Ethan Furman :
Benjamin Peterson wrote:
2011/9/23 Ethan Furman :
Follow-up question: since the original range returned lists, and
comparisons
do make sense for lists, should the new range also implement them?
What would be the use-case?
The only reason I'm
2011/9/23 Ethan Furman :
> Benjamin Peterson wrote:
>>
>> 2011/9/23 Ethan Furman :
>
>>>
>>>
>>> Follow-up question: since the original range returned lists, and
>>> comparisons
>>> do make sense for lists, should the new range also implement them?
>>
>> What would be the use-case?
>
> The only rea
On 2011-09-23, at 20:23 , Guido van Rossum wrote:
> Also, Ethan, I hope you're familiar with the reason why there is no
> range() support for floats currently? (Briefly, things like range(0.0,
> 0.8, step=0.1) could include or exclude the end point depending on
> rounding, which makes for troubleso
Benjamin Peterson wrote:
2011/9/23 Ethan Furman :
>>
Follow-up question: since the original range returned lists, and comparisons
do make sense for lists, should the new range also implement them?
What would be the use-case?
The only reason I'm aware of at the moment is to prevent loss of
Guido van Rossum wrote:
Also, Ethan, I hope you're familiar with the reason why there is no
range() support for floats currently? (Briefly, things like range(0.0,
0.8, step=0.1) could include or exclude the end point depending on
rounding, which makes for troublesome semantics.)
Good point, tha
Also, Ethan, I hope you're familiar with the reason why there is no
range() support for floats currently? (Briefly, things like range(0.0,
0.8, step=0.1) could include or exclude the end point depending on
rounding, which makes for troublesome semantics.)
On Fri, Sep 23, 2011 at 11:14 AM, Benjamin
2011/9/23 Ethan Furman :
> A question came up on StackOverflow about range objects and floating point
> numbers. I thought about writing an frange that did for floats what range
> does for ints, so started examining the range class. I noticed it has
> __le__, __lt__, __eq__, __ne__, __ge__, and _
A question came up on StackOverflow about range objects and floating
point numbers. I thought about writing an frange that did for floats
what range does for ints, so started examining the range class. I
noticed it has __le__, __lt__, __eq__, __ne__, __ge__, and __gt__
methods. Some experime
66 matches
Mail list logo
