I think the problem is quite easy to solve, without changing the
"documentation" behaviour.
The doc says:
Help on built-in function arange in module numpy.core.multiarray:
/
arange(...)
arange([start,] stop[, step,], dtype=None)
Return evenly spaced values within a given interval.
Values are generated within the half-open interval ``[start, stop)``
(in other words, the interval including `start` but excluding `stop`).
For integer arguments the function is equivalent to the Python built-in
`range <http://docs.python.org/lib/built-in-funcs.html>`_ function,
but returns a ndarray rather than a list.
/
stop is exclusive "by definition". So substracting a very small value to
stop when processing "stop" I think is the best way.
Matteo
Il 10/02/2012 02:22, Drew Frank ha scritto:
On Thu, Feb 9, 2012 at 3:40 PM, Benjamin Root <ben.r...@ou.edu
<mailto:ben.r...@ou.edu>> wrote:
On Thursday, February 9, 2012, Sturla Molden <stu...@molden.no
<mailto:stu...@molden.no>> wrote:
>
>
> Den 9. feb. 2012 kl. 22:44 skrev eat <e.antero.ta...@gmail.com
<mailto:e.antero.ta...@gmail.com>>:
>
>>
> Maybe this issue is raised also earlier, but wouldn't it be more
consistent to let arange operate only with integers (like Python's
range) and let linspace handle the floats as well?
>
>
> Perhaps. Another possibility would be to let arange take decimal
arguments, possibly entered as text strings.
> Sturla
Personally, I treat arange() to mean, "give me a sequence of
values from x to y, exclusive, with a specific step size".
Nowhere in that statement does it guarantee a particular number
of elements. Whereas linspace() means, "give me a sequence of
evenly spaced numbers from x to y, optionally inclusive, such that
there are exactly N elements". They complement each other well.
I agree -- both functions are useful and I think about them the same
way. The unfortunate part is that tiny precision errors in y can make
arange appear to be "sometimes-exclusive" rather than always
exclusive. I've always imagined there to be a sort of duality between
the two functions, where arange(low, high, step) == linspace(low,
high-step, round((high-low)/step)) in cases where (high - low)/step is
integral, but it turns out this is not the case.
There are times when I intentionally will specify a range where
the step size will not nicely fit. i.e.- np.arange(1, 7, 3.5). I
wouldn't want this to change.
Nor would I. What I meant to express earlier is that I like how
Matlab addresses this particular class of floating point precision
errors, not that I think arange output should somehow include both
endpoints.
My vote is that if users want matlab-colon-like behavior, we could
make a new function - maybe erange() for "exact range"?
Ben Root
That could work; it would completely replace arange for me in every
circumstance I can think of, but I understand we can't just go
changing the behavior of core functions.
Drew
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
--
-------------------------------------------------------
Matteo Malosio, Eng.
Researcher
ITIA-CNR (www.itia.cnr.it)
Institute of Industrial Technologies and Automation
National Research Council
via Bassini 15, 20133 MILANO, ITALY
Ph: +39 0223699625
Fax: +39 0223699925
e-mail:matteo.malo...@itia.cnr.it
-------------------------------------------------------
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
