Re: [Numpy-discussion] __numpy_ufunc__

2017-02-22 Thread Marten van Kerkwijk
HI Stephan, Indeed, `__array_ufunc__` is None would be for classes that interact with arrays only as if they were any other numeric type, and thus have no use for ufuncs, but may need normal operations (astropy's `Unit` class is a reasonably good example). Your example also makes clear that,

Re: [Numpy-discussion] Fortran order in recarray.

2017-02-22 Thread Alex Rogozhnikov
Hi Stephan, thanks for the note. The progress over last two years wasn't impressive IMO, but I hope you'll manage. As you suggest, I'll have a look at xarray too, as I see xarray.Dataset. I was sure that it doesn't work with non-homogeneous data at all, clearly I need to refresh my opinion.

Re: [Numpy-discussion] Fortran order in recarray.

2017-02-22 Thread Alex Rogozhnikov
> 22 февр. 2017 г., в 20:39, josef.p...@gmail.com написал(а): > > > > On Wed, Feb 22, 2017 at 11:57 AM, Alex Rogozhnikov > > wrote: > Hi Matthew, > maybe it is not the best place to discuss problems of pandas, but to show > that

Re: [Numpy-discussion] Fortran order in recarray.

2017-02-22 Thread Stephan Hoyer
On Wed, Feb 22, 2017 at 8:57 AM, Alex Rogozhnikov < alex.rogozhni...@yandex.ru> wrote: > Pandas may be nice, if you need a report, and you need get it done > tomorrow. Then you'll throw away the code. When we initially used pandas as > main data storage in yandex/rep, it looked like an good idea,

Re: [Numpy-discussion] Fortran order in recarray.

2017-02-22 Thread josef . pktd
On Wed, Feb 22, 2017 at 11:57 AM, Alex Rogozhnikov < alex.rogozhni...@yandex.ru> wrote: > Hi Matthew, > maybe it is not the best place to discuss problems of pandas, but to show > that I am not missing something, let's consider a simple example. > > # simplest DataFrame > x =

Re: [Numpy-discussion] __numpy_ufunc__

2017-02-22 Thread Stephan Hoyer
On Wed, Feb 22, 2017 at 6:31 AM, Marten van Kerkwijk < m.h.vankerkw...@gmail.com> wrote: > It seems to me entirely logical (but then it would, I suggested it > before...) that we allow opting out by setting `__array_ufunc__` to > None; in that case, binops return NotImplemented and ufuncs raise >

Re: [Numpy-discussion] Fortran order in recarray.

2017-02-22 Thread Alex Rogozhnikov
Hi Matthew, maybe it is not the best place to discuss problems of pandas, but to show that I am not missing something, let's consider a simple example. # simplest DataFrame x = pandas.DataFrame(dict(a=numpy.arange(10), b=numpy.arange(10, 20))) # simplest indexing. Can you predict results

Re: [Numpy-discussion] Numpy Development Queries

2017-02-22 Thread Matthew Harrigan
Ashwin, I don't know your background but perhaps it is similar to mine. I use numpy extensively in my day job and starting contributing to numpy a few months ago. From using numpy, I found some things that I thought should be added/improved. I researched them and the associated numpy code

Re: [Numpy-discussion] Fortran order in recarray.

2017-02-22 Thread Matthew Harrigan
Alex, Can you please post some code showing exactly what you are trying to do and any issues you are having, particularly the "irritating problems with its row indexing and some other problems" you quote above? On Wed, Feb 22, 2017 at 10:34 AM, Robert McLeod wrote: > Just

Re: [Numpy-discussion] Fortran order in recarray.

2017-02-22 Thread Francesc Alted
2017-02-22 16:30 GMT+01:00 Kiko : > > > 2017-02-22 16:23 GMT+01:00 Alex Rogozhnikov : > >> Hi Francesc, >> thanks a lot for you reply and for your impressive job on bcolz! >> >> Bcolz seems to make stress on compression, which is not of much

Re: [Numpy-discussion] Fortran order in recarray.

2017-02-22 Thread Robert McLeod
Just as a note, Appveyor supports uploading modules to "public websites": https://packaging.python.org/appveyor/ The main issue I would see from this, is the PyPi has my password stored on my machine in a plain text file. I'm not sure whether there's a way to provide Appveyor with a SSH key

Re: [Numpy-discussion] Fortran order in recarray.

2017-02-22 Thread Kiko
2017-02-22 16:23 GMT+01:00 Alex Rogozhnikov : > Hi Francesc, > thanks a lot for you reply and for your impressive job on bcolz! > > Bcolz seems to make stress on compression, which is not of much interest > for me, but the *ctable*, and chunked operations look very

Re: [Numpy-discussion] __numpy_ufunc__

2017-02-22 Thread Marten van Kerkwijk
Hi All, I'd very much like to get `__array_ufunc__` in, and am willing to do some work, but fear we need to get past the last sticking point. As I noted in Chuck's PR [1], in python 3.6 there is now an explicit language change [2], which I think is relevant: ``` It is now possible to set a

Re: [Numpy-discussion] Fortran order in recarray.

2017-02-22 Thread Francesc Alted
Hi Alex, 2017-02-22 12:45 GMT+01:00 Alex Rogozhnikov : > Hi Nathaniel, > > > pandas > > > yup, the idea was to have minimal pandas.DataFrame-like storage (which I > was using for a long time), > but without irritating problems with its row indexing and some other >

Re: [Numpy-discussion] Could we simplify backporting?

2017-02-22 Thread Marten van Kerkwijk
Hi Ralf, Yes, good to think about other policies. For astropy, we do the decision by labelling with the bug-fix branch (with a policy that it really should fix a bug), and inserting text in that release's bug-fix notes (we really should automate that part...). Then, backporting is done shortly

Re: [Numpy-discussion] Fortran order in recarray.

2017-02-22 Thread Alex Rogozhnikov
Hi Nathaniel, > pandas yup, the idea was to have minimal pandas.DataFrame-like storage (which I was using for a long time), but without irritating problems with its row indexing and some other problems like interaction with matplotlib. > A dict of arrays? that's what I've started from

Re: [Numpy-discussion] Could we simplify backporting?

2017-02-22 Thread Ralf Gommers
On Wed, Feb 22, 2017 at 7:52 AM, Marten van Kerkwijk < m.h.vankerkw...@gmail.com> wrote: > Hi All, > > In gh-8594, a question came up how to mark things that should be > backported and Chuck commented [1]: > > > Our backport policy is still somewhat ad hoc, especially as I the only > one who has