On 9/23/2011 10:40 PM, Guido van Rossum wrote:
On Fri, Sep 23, 2011 at 7:13 PM, Steven D'Aprano<st...@pearwood.info> 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 avoid inclusion/exclusion errors, you should be testing values against a stop value that is (except for rounding errors) half a step above the last value you want to yield. In other words, subtract or add step/2.0 to the stop value according to whether or not you want it excluded or included.
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 completely agree. For range(n), n is both the stop value and number of ints generated. It is otherwise stop-start, which is to say, stop = start + n, which is why there is no need for an n-based api (all this is by design).
Maybe we can come up with a better API, and e.g. specify begin and end points and the number of subdivisions? E.g. frange(0.0, 2.1, 3) would generate [0.0, 0.7, 1.4]. Or maybe it would even be better to use inclusive end points? OTOH if you consider extending the API to complex numbers, it might be better to specify an initial value, a step, and a count. So frange(0.0, 0.7, 3) to generate [0.0, 0.7, 1.4]. Probably it shouldn't be called frange then.
In float use cases I can think of, one wants either both or neither end point. If neither, one probably wants points at .5*step, 1.5*step, etc., where step calculated as (right-left)/n.
-- Terry Jan Reedy _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
