[Numpy-discussion] numpy.dtype has the wrong size, try recompiling
This question on Stack Overflow: http://stackoverflow.com/questions/38197086/sklearn-numpy-dtype-has-the-wrong-size-try-recompiling-in-both-pycharm-and-te If I remember correctly this has something to do with Cython, right? Can't remeber the details though, can someone help that poor soul out? Jaime -- (\__/) ( O.o) ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.dtype has the wrong size, try recompiling
On Tue, Jul 5, 2016 at 4:22 AM, Jaime Fernández del Río < jaime.f...@gmail.com> wrote: > This question on Stack Overflow: > > > http://stackoverflow.com/questions/38197086/sklearn-numpy-dtype-has-the-wrong-size-try-recompiling-in-both-pycharm-and-te > > If I remember correctly this has something to do with Cython, right? Can't > remeber the details though, can someone help that poor soul out? > from what I understood many years ago (based mainly on what David Cournapeau was saying) http://stackoverflow.com/questions/17709641/valueerror-numpy-dtype-has-the-wrong-size-try-recompiling Josef > > Jaime > > -- > (\__/) > ( O.o) > ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes > de dominación mundial. > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Picking rows with the first (or last) occurrence of each key
> Except it doesn’t seem to meet your original spec, which retrieved > the first item of each *run* of an index value? No, just what I was looking for. As I indicated in my original post, "I'm probably going to botch the description..." It's quite likely that my problem specification wasn't as crisp as it should have been. S ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] f2py output module name
Hi, I'm following this guide: http://docs.scipy.org/doc/numpy-dev/f2py/getting-started.html#the-quick-and-smart-way I'm on Windows with gfortran and VS2015. When I run: f2py -c -m fib3 fib3.f as output I dont get "fib3.pyd", but "fib3.cp35-win_amd64.pyd". Does anyone know how to get correctly named module in this case? Thanks ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] f2py output module name
On Tue, Jul 5, 2016 at 9:18 PM, klo uo wrote:
> Hi, I'm following this guide:
> http://docs.scipy.org/doc/numpy-dev/f2py/getting-started.html#the-quick-and-smart-way
>
> I'm on Windows with gfortran and VS2015. When I run:
>
> f2py -c -m fib3 fib3.f
>
> as output I dont get "fib3.pyd", but "fib3.cp35-win_amd64.pyd".
>
> Does anyone know how to get correctly named module in this case?
>
That is the right output, see https://www.python.org/dev/peps/pep-3149. You
can check the expected extension tag with
`sysconfig.get_config_var('SOABI')`.
There may be a way to turn that off, but why would you?
Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] f2py output module name
So on Linux too, there is "ABI" suffix too, for generated module... I misunderstood. I was renaming generated module to "fib3.pyd" to be able to do "import fib3", but now I see it's not necessary - it's importable the same regardless the name of generated module :) Thanks ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Added atleast_nd, request for clarification/cleanup of atleast_3d
Hi, I have generalized np.atleast_1d, np.atleast_2d, np.atleast_3d with a function np.atleast_nd in PR#7804 (https://github.com/numpy/numpy/pull/7804). As a result of this PR, I have a couple of questions about `np.atleast_3d`. `np.atleast_3d` appears to do something weird with the dimensions: If the input is 1D, it prepends and appends a size-1 dimension. If the input is 2D, it appends a size-1 dimension. This is inconsistent with `np.atleast_2d`, which always prepends (as does `np.atleast_nd`). - Is there any reason for this behavior? - Can it be cleaned up (e.g., by reimplementing `np.atleast_3d` in terms of `np.atleast_nd`, which is actually much simpler)? This would be a slight API change since the output would not be exactly the same. Thanks, -Joe ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Added atleast_nd, request for clarification/cleanup of atleast_3d
On Jul 5, 2016 9:09 PM, "Joseph Fox-Rabinovitz" wrote: > > Hi, > > I have generalized np.atleast_1d, np.atleast_2d, np.atleast_3d with a > function np.atleast_nd in PR#7804 > (https://github.com/numpy/numpy/pull/7804). > > As a result of this PR, I have a couple of questions about > `np.atleast_3d`. `np.atleast_3d` appears to do something weird with > the dimensions: If the input is 1D, it prepends and appends a size-1 > dimension. If the input is 2D, it appends a size-1 dimension. This is > inconsistent with `np.atleast_2d`, which always prepends (as does > `np.atleast_nd`). > > - Is there any reason for this behavior? > - Can it be cleaned up (e.g., by reimplementing `np.atleast_3d` in > terms of `np.atleast_nd`, which is actually much simpler)? This would > be a slight API change since the output would not be exactly the same. Changing atleast_3d seems likely to break a bunch of stuff... Beyond that, I find it hard to have an opinion about the best design for these functions, because I don't think I've ever encountered a situation where they were actually what I wanted. I'm not a big fan of coercing dimensions in the first place, for the usual "refuse to guess" reasons. And then generally if I do want to coerce an array to another dimension, then I have some opinion about where the new dimensions should go, and/or I have some opinion about the minimum acceptable starting dimension, and/or I have a maximum dimension in mind. (E.g. "coerce 1d inputs into a column matrix; 0d or 3d inputs are an error" -- atleast_2d is zero-for-three on that requirements list.) I don't know how typical I am in this. But it does make me wonder if the atleast_* functions act as an attractive nuisance, where new users take their presence as an implicit recommendation that they are actually a useful thing to reach for, even though they... aren't that. And maybe we should be recommending folk move away from them rather than trying to extend them further? Or maybe they're totally useful and I'm just missing it. What's your use case that motivates atleast_nd? -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Added atleast_nd, request for clarification/cleanup of atleast_3d
On Wed, Jul 6, 2016 at 7:06 AM, Nathaniel Smith wrote: On Jul 5, 2016 9:09 PM, "Joseph Fox-Rabinovitz" > wrote: > > > > Hi, > > > > I have generalized np.atleast_1d, np.atleast_2d, np.atleast_3d with a > > function np.atleast_nd in PR#7804 > > (https://github.com/numpy/numpy/pull/7804). > > > > As a result of this PR, I have a couple of questions about > > `np.atleast_3d`. `np.atleast_3d` appears to do something weird with > > the dimensions: If the input is 1D, it prepends and appends a size-1 > > dimension. If the input is 2D, it appends a size-1 dimension. This is > > inconsistent with `np.atleast_2d`, which always prepends (as does > > `np.atleast_nd`). > > > > - Is there any reason for this behavior? > > - Can it be cleaned up (e.g., by reimplementing `np.atleast_3d` in > > terms of `np.atleast_nd`, which is actually much simpler)? This would > > be a slight API change since the output would not be exactly the same. > > Changing atleast_3d seems likely to break a bunch of stuff... > > Beyond that, I find it hard to have an opinion about the best design for > these functions, because I don't think I've ever encountered a situation > where they were actually what I wanted. I'm not a big fan of coercing > dimensions in the first place, for the usual "refuse to guess" reasons. And > then generally if I do want to coerce an array to another dimension, then I > have some opinion about where the new dimensions should go, and/or I have > some opinion about the minimum acceptable starting dimension, and/or I have > a maximum dimension in mind. (E.g. "coerce 1d inputs into a column matrix; > 0d or 3d inputs are an error" -- atleast_2d is zero-for-three on that > requirements list.) > > I don't know how typical I am in this. But it does make me wonder if the > atleast_* functions act as an attractive nuisance, where new users take > their presence as an implicit recommendation that they are actually a > useful thing to reach for, even though they... aren't that. And maybe we > should be recommending folk move away from them rather than trying to > extend them further? > > Or maybe they're totally useful and I'm just missing it. What's your use > case that motivates atleast_nd? > I think you're just missing it:) atleast_1d/2d are used quite a bit in Scipy and Statsmodels (those are the only ones I checked), and in the large majority of cases it's the best thing to use there. There's a bunch of atleast_2d calls with a transpose appended because the input needs to be treated as columns instead of rows, but that's still efficient and readable enough. For 3D/nD I can see that you'd need more control over where the dimensions go, but 1D/2D are fine. Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
