Re: [Numpy-discussion] improving arange()? introducing fma()?

Interesting... ``` static void @NAME@_fill(@type@ *buffer, npy_intp length, void *NPY_UNUSED(ignored)) { npy_intp i; @type@ start = buffer[0]; @type@ delta = buffer[1]; delta -= start; for (i = 2; i < length; ++i) { buffer[i] = start + i*delta; } } ``` So, the second value is computed using the d

Re: [Numpy-discussion] improving arange()? introducing fma()?

Can’t arange and linspace operations with floats be done internally Yes, and they probably should be - they’re done this way as a hack because the api exposed for custom dtypes is here

Re: [Numpy-discussion] improving arange()? introducing fma()?

I apologize if I'm missing something basic, but why are floats being accumulated in the first place? Can't arange and linspace operations with floats be done internally similar to `start + np.arange(num_steps) * step_size`? I.e. always accumulate (really increment) integers to limit errors. On F

Re: [Numpy-discussion] improving arange()? introducing fma()?

On Fri, Feb 9, 2018 at 12:19 PM, Chris Barker wrote: > On Wed, Feb 7, 2018 at 12:09 AM, Ralf Gommers > wrote: >> >> It is partly a plea for some development of numerically accurate >>> functions for computing lat/lon grids from a combination of inputs: bounds, >>> counts, and resolutions. >>> >

Re: [Numpy-discussion] improving arange()? introducing fma()?

On Wed, Feb 7, 2018 at 12:09 AM, Ralf Gommers wrote: > > It is partly a plea for some development of numerically accurate >> functions for computing lat/lon grids from a combination of inputs: bounds, >> counts, and resolutions. >> > Can you be more specific about what problems you've run into --

[Numpy-discussion] type promotion rules for integers

What considerations formed the basis for choosing the next type promotion behavior in numpy: In[2] : a = np.array([10], dtype=np.int64) b = np.array([10], dtype=np.uint64) (a+b).dtype Out[2]: dtype('float64') Why the `object` dtype was not chosen for the resulting dtype? Are ther

[Numpy-discussion] dtype argument description for np.array

Currently in docstring the description of dtype argument for np.array says this: dtype : data-type, optional > The desired data-type for the array. If not given, then the type will > be determined as the minimum type required to hold the objects in the > sequence. This argument can o