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

Reply via email to