On Thu, Feb 9, 2012 at 12:20 PM, Drew Frank <drewfr...@gmail.com> wrote:
> Eric Firing <efiring <at> hawaii.edu> writes: > > > > > On 02/08/2012 09:31 PM, teomat wrote: > > > > > > Hi, > > > > > > Am I wrong or the numpy.arange() function is not correct 100%? > > > > > > Try to do this: > > > > > > In [7]: len(np.arange(3.1, 4.9, 0.1)) > > > Out[7]: 18 > > > > > > In [8]: len(np.arange(8.1, 9.9, 0.1)) > > > Out[8]: 19 > > > > > > I would expect the same result for each command. > > > > Not after more experience with the wonders of floating point! > > Nice-looking decimal numbers often have long, drawn-out, inexact > > floating point (base 2) representations. That leads to exactly this > > sort of problem. > > > > numpy.linspace is provided to help get around some of these surprises; > > or you can use an integer sequence and then scale and shift it. > > > > Eric > > > > > > > > All the best > > > > > > > > > I also found this surprising -- not because I lack experience with floating > point, but because I do have experience with MATLAB. In MATLAB, the > corresponding operation 3.1:0.1:4.9 has length 19 because of an explicit > tolerance parameter used in the implmentation > ( > http://www.mathworks.com/support/solutions/en/data/1-4FLI96/index.html?solution=1-4FLI96 > ). > > Of course, NumPy is not MATLAB :). That said, I prefer the MATLAB > behavior in > this case -- even though it has a bit of a "magic" feel to it, I find it > hard to > imagine code that operates correctly given the Python semantics and > incorrectly > under MATLAB's. Thoughts? > > Matlab didn't have integers, so they did the best they could ;) Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion