That's a great solution. I think the only other alternative would be to
return an array instead of a range, which would be unfortunate.
On Wednesday, July 2, 2014 9:50:34 AM UTC-4, Ivar Nesje wrote:
>
> Hmm... Everything with floating point ranges is inherently difficult,
> because we want to g
Hmm... Everything with floating point ranges is inherently difficult,
because we want to give users the full accuracy (not cheat like Matlab
does).
In order for the slicing behaviour to be exactly right, it seems to me that
we would need to store a start and a step increment, so that the
calcu
Unfortunately, it is not always possible to construct a range such that the
exact value of the endpoints is retained. Matlab cheats here, and changes
the step size to ensure that the endpoints are retained. A Julian range,
however, must always have one unique step. For more information, see t
Thanks. I had mistakenly thought that linrange would retain the exact
value of its end points, as does linspace.
My actual application is to reproduce the functionality of Matlab's
optional histc output:
[n,bin] = histc(x, edges)
Here, (using Matlab notation), bin is an integer-valued vecto
It is not a shocker to me. The problem is that Floating point numbers
represent binary fractions, and there is no way for linrange() to actually
get equidistant values you are looking for. It has to do approximations,
and thus it will sometimes miss closest possible value. That means equality
c
