Re: [Numpy-discussion] MapIter api
On Mon, Apr 15, 2013 at 1:27 PM, Sebastian Berg wrote: > On Mon, 2013-04-15 at 11:16 -0600, Charles R Harris wrote: > > > > > > On Mon, Apr 15, 2013 at 10:29 AM, Sebastian Berg > > wrote: > > Hey, > > > > the MapIter API has only been made public in master right? So > > it is no > > problem at all to change at least the mapiter struct, right? > > > > I got annoyed at all those special cases that make things > > difficult to > > get an idea where to put i.e. to fix the boolean array-like > > stuff. So > > actually started rewriting it (and I already got one big > > function that > > does all index preparation -- ok it is untested but its > > basically > > there). > > > > I would guess it is not really a big problem even if it was > > public for > > longer, since you shouldn't do those direct struct access > > probably? But > > just checking. > > > > Since I got the test which mimics complex indexes in the > > tests, I thinks > > it should actually be feasible to do bigger refactoring there > > without > > having to worry too much about breaking things. > > > > > > Looks like the public API went in last August but didn't make it into > > the 1.7.x release. What sort of schedule are you looking at? > > > Not sure about a schedule, I somewhat think it is not even that hard, > but of course it would still take a while (once I get a bit further, I > will put it out there, hopefully someone else will be interested to > help), but certainly not aiming to get anything done for 1.8. > > My first idea was to just do the parsing differently and keep the > mapiter part identical (or with minor modifications). That seems > actually impractical, since MapIter has a lot of stuff that it does not > need. Plus it seems to me that it might be worth it to use the new > nditer. One could try keep the fields somewhat identical (likely > identical enough to be binary compatible with that ufunc.at pull request > even), but I am not even sure that that is something to aim for, since > the ufunc.at could be modified too (and might get good speed > improvements out of that). > > - Sebastian > > Makes me wonder if we should expose the API in 1.8 if you are thinking a change might be appropriate. Or am I missing something here? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] MapIter api
On Mon, 2013-04-15 at 11:16 -0600, Charles R Harris wrote: > > > On Mon, Apr 15, 2013 at 10:29 AM, Sebastian Berg > wrote: > Hey, > > the MapIter API has only been made public in master right? So > it is no > problem at all to change at least the mapiter struct, right? > > I got annoyed at all those special cases that make things > difficult to > get an idea where to put i.e. to fix the boolean array-like > stuff. So > actually started rewriting it (and I already got one big > function that > does all index preparation -- ok it is untested but its > basically > there). > > I would guess it is not really a big problem even if it was > public for > longer, since you shouldn't do those direct struct access > probably? But > just checking. > > Since I got the test which mimics complex indexes in the > tests, I thinks > it should actually be feasible to do bigger refactoring there > without > having to worry too much about breaking things. > > > Looks like the public API went in last August but didn't make it into > the 1.7.x release. What sort of schedule are you looking at? > Not sure about a schedule, I somewhat think it is not even that hard, but of course it would still take a while (once I get a bit further, I will put it out there, hopefully someone else will be interested to help), but certainly not aiming to get anything done for 1.8. My first idea was to just do the parsing differently and keep the mapiter part identical (or with minor modifications). That seems actually impractical, since MapIter has a lot of stuff that it does not need. Plus it seems to me that it might be worth it to use the new nditer. One could try keep the fields somewhat identical (likely identical enough to be binary compatible with that ufunc.at pull request even), but I am not even sure that that is something to aim for, since the ufunc.at could be modified too (and might get good speed improvements out of that). - Sebastian > Chuck > > > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] MapIter api
On Mon, Apr 15, 2013 at 10:29 AM, Sebastian Berg wrote: > Hey, > > the MapIter API has only been made public in master right? So it is no > problem at all to change at least the mapiter struct, right? > > I got annoyed at all those special cases that make things difficult to > get an idea where to put i.e. to fix the boolean array-like stuff. So > actually started rewriting it (and I already got one big function that > does all index preparation -- ok it is untested but its basically > there). > > I would guess it is not really a big problem even if it was public for > longer, since you shouldn't do those direct struct access probably? But > just checking. > > Since I got the test which mimics complex indexes in the tests, I thinks > it should actually be feasible to do bigger refactoring there without > having to worry too much about breaking things. > > Looks like the public API went in last August but didn't make it into the 1.7.x release. What sort of schedule are you looking at? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] MapIter api
Hey, the MapIter API has only been made public in master right? So it is no problem at all to change at least the mapiter struct, right? I got annoyed at all those special cases that make things difficult to get an idea where to put i.e. to fix the boolean array-like stuff. So actually started rewriting it (and I already got one big function that does all index preparation -- ok it is untested but its basically there). I would guess it is not really a big problem even if it was public for longer, since you shouldn't do those direct struct access probably? But just checking. Since I got the test which mimics complex indexes in the tests, I thinks it should actually be feasible to do bigger refactoring there without having to worry too much about breaking things. Regards, Sebastian ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Pruned / sparse FFT 2D
Hi, I have a sparse cloud of points of ~10^4 points randomly scattered around a triangular domain [1] from which I want to take the Fourier transform. I have been looking for algorithms and found one library, but only appears to be for the 1-D case (and seems there is no documentation). In [3] there is C code for the FFTW, but seems it code is itself pruned (pun intended). Does anyone have a clue about how to perform it? Speed is not a big issue, but accuracy is quite important. Thanks, David. [1] http://www.asaaf.org/~davidmh/coverage.png [2] https://pypi.python.org/pypi/pynfftls/1.0 [3] http://www.fftw.org/pruned.html ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
