I think it's all been said, but a few comments:
On Sun, Feb 11, 2018 at 2:19 PM, Nils Becker

Generating equidistantly spaced grids is simply not always possible.

exactly -- and linspace gives pretty much teh best possible result, guaranteeing tha tthe start an end points are exact, and the spacing is within an ULP or two (maybe we could make that within 1 ULP always, but not sure that's worth it).

The reason is that the absolute spacing of the possible floating point numbers depends on their magnitude [1].

Also that the exact spacing may not be exactly representable in FP -- so you have to have at least one space that's a bit off to get the end points right (or have the endpoints not exact).

If you - for some reason - want the same grid spacing everywhere you may choose an appropriate new spacing.

well, yeah, but usually you are trying to fit to some other constraint. I'm still confused as to where these couple of ULPs actually cause problems, unless you are doing in appropriate FP comparisons elsewhere. Curiously, either by design or accident, arange() seems to do something

similar as was mentioned by Eric. It creates a new grid spacing by adding and subtracting the starting point of the grid. This often has similar effect as adding and subtracting N*dx (e.g. if the grid is symmetric around 0.0). Consequently, arange() seems to trade keeping the grid spacing constant for a larger error in the grid size and consequently in the end point.

interesting -- but it actually makes sense -- that is the definition of
arange(), borrowed from range(), which was designed for integers, and, in
fact, pretty much mirroered the classic C index for loop:
for (int i=0; i

1. Comparison to calculations with decimal can be difficult as not all simple decimal step sizes are exactly representable as

finite floating point numbers.

yeah, this is what I mean by inappropriate use of Decimal -- decimal is not inherently "more accurate" than fp -- is just can represent _decimal_ numbers exactly, which we are all use to -- we want 1 / 10 to be exact, but dont mind that 1 / 3 isn't. Decimal also provided variable precision -- so it can be handy for that. I kinda wish Python had an arbitrary precision binary floating point built in... -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov