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

Hi there, Is this the implementation of fma? https://github.com/nschloe/pyfma Cheers, Arnaldo . |\ _/]_\_ ~"~^~ Arnaldo D'Amaral Pereira Granja Russo c i c l o t u x . o r g 2018-02-25 8:34 GMT-03:00 Nils Becker : > Hey, > > >> Anyone that unders

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

Hey, > Anyone that understands FP better than I do: > > In the above code, you are multiplying the step by an integer -- is there > any precision loss when you do that?? > > Elementary operations (add, sub, mul, div) are demanded to be correctly rounded (cr) by IEEE, i.e. accurate within +/- 0.5

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

On Fri, Feb 9, 2018 at 1:16 PM, Matthew Harrigan wrote: > 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. al

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

On Thu, Feb 22, 2018 at 11:57 AM, Sebastian Berg wrote: > > First, you are right...Decimal is not the right module for this. I > > think instead I should use the 'fractions' module for loading grid > > spec information from strings (command-line, configs, etc). The > > tricky part is getting the

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

On Thu, 2018-02-22 at 14:33 -0500, Benjamin Root wrote: > Sorry, I have been distracted with xarray improvements the past > couple of weeks. > > Some thoughts on what has been discussed: > > First, you are right...Decimal is not the right module for this. I > think instead I should use the 'fract

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

Sorry, I have been distracted with xarray improvements the past couple of weeks. Some thoughts on what has been discussed: First, you are right...Decimal is not the right module for this. I think instead I should use the 'fractions' module for loading grid spec information from strings (command-l

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

@Ben: Have you found a solution to your problem? Are there thinks we could do in numpy to make it better? -CHB On Mon, Feb 12, 2018 at 9:33 AM, Chris Barker wrote: > I think it's all been said, but a few comments: > > On Sun, Feb 11, 2018 at 2:19 PM, Nils Becker > wrote: > >> Generating equid

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

I think it's all been said, but a few comments: On Sun, Feb 11, 2018 at 2:19 PM, Nils Becker wrote: > 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, a

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

A slightly longer comment although I have to admit that it misses the discussion here partially. Still I hope it provides some background to your question. Generating equidistantly spaced grids is simply not always possible. The reason is that the absolute spacing of the possible floating point nu

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

I just want to add a few links related to the topic: https://mail.python.org/pipermail/numpy-discussion/2007-September/029129.html https://quantumwise.com/forum/index.php?topic=110.0#.VIVgyIctjRZ https://mail.python.org/pipermail/numpy-discussion/2012-February/060238.html http://nbviewer.jupyter.o

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 --

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

On Wed, Feb 7, 2018 at 2:57 AM, Benjamin Root wrote: > Note, the following is partly to document my explorations in computing > lat/on grids in numpy lately, in case others come across these issues in > the future. It is partly a plea for some development of numerically > accurate functions for c

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

Note, the following is partly to document my explorations in computing lat/on grids in numpy lately, in case others come across these issues in the future. It is partly a plea for some development of numerically accurate functions for computing lat/lon grids from a combination of inputs: bounds, co