Re: [Numpy-discussion] ndarray.T2 for 2D transpose

On Tue, Apr 5, 2016 at 11:14 PM, Nathaniel Smith wrote: > On Tue, Apr 5, 2016 at 7:11 PM, Todd wrote: > > When you try to transpose a 1D array, it does nothing. This is the > correct > > behavior, since it transposing a 1D array is meaningless. However,

Re: [Numpy-discussion] ndarray.T2 for 2D transpose

I would make `arr.T2` the same as `np.atleast_2d(arr).T`. So a 1D array would act as a row vector, since that is already the convention for coercing 1D arrays to 2D. On Tue, Apr 5, 2016 at 10:49 PM, Juan Nunez-Iglesias wrote: > Todd, > > Would you consider a 1D array to be

Re: [Numpy-discussion] ndarray.T2 for 2D transpose

On 4/6/2016 1:47 PM, Todd wrote: My suggestion is that this explicitly increases the number of dimensions to at least 2. The result will always have at least 2 dimensions. So 0D -> 2D, 1D -> 2D, 2D -> 2D, 3D -> 3D, 4D -> 4D, etc. So this would be equivalent to the existing `atleast_2d`

Re: [Numpy-discussion] ndarray.T2 for 2D transpose

On Wed, Apr 6, 2016 at 11:44 AM, Chris Barker - NOAA Federal < chris.bar...@noaa.gov> wrote: > But the truth is that Numpy arrays are arrays, not matrices and vectors. > > The "right" way to do this is to properly extend and support the > matrix object, adding row and column vector objects, and

Re: [Numpy-discussion] ndarray.T2 for 2D transpose

On Tue, Apr 5, 2016 at 9:14 PM Nathaniel Smith wrote: > On Tue, Apr 5, 2016 at 7:11 PM, Todd wrote: > > When you try to transpose a 1D array, it does nothing. This is the > correct > > behavior, since it transposing a 1D array is meaningless. However, this

Re: [Numpy-discussion] ndarray.T2 for 2D transpose

On Wed, Apr 6, 2016 at 10:43 AM, Todd wrote: > On Tue, Apr 5, 2016 at 11:14 PM, Nathaniel Smith wrote: >> >> On Tue, Apr 5, 2016 at 7:11 PM, Todd wrote: >> > When you try to transpose a 1D array, it does nothing. This is the >> > correct

Re: [Numpy-discussion] ndarray.T2 for 2D transpose

On Wed, Apr 6, 2016 at 10:47 AM, Todd wrote: > > I think that cat is already out of the bag. As long as you can do matrix > multiplication on arrays using the @ operator, I think they aren't really > "pure" anymore. > not really -- you still need to use arrays that are the

Re: [Numpy-discussion] ndarray.T2 for 2D transpose

Nathaniel Smith pobox.com> writes: > An alternative that was mentioned in the bug tracker > (https://github.com/numpy/numpy/issues/7495), possibly by me, would be > to have arr.T2 act as a stacked-transpose operator, i.e. treat an arr > with shape (..., n, m) as being a (...)-shaped stack of (n,

Re: [Numpy-discussion] Using OpenBLAS for manylinux wheels

On Wed, Apr 6, 2016 at 2:04 AM, Olivier Grisel wrote: > 2016-04-05 19:44 GMT+02:00 Nathaniel Smith : >> >>> I propose to hold off distributing the OpenBLAS wheels until the >>> OpenBLAS tests are clean on the OpenBLAS buildbots - any objections? >> >>

[Numpy-discussion] Build NumPy against MATLAB BLAS & Lapack

hi I'm trying to provide a Python numerical library to colleagues who are MATLAB users, since recent MATLAB versions include an official method for calling Python [1], and I'm struggling to build NumPy which is compatible with MATLAB's libraries. My current site.cfg is here

Re: [Numpy-discussion] Using OpenBLAS for manylinux wheels

Yes sorry I forgot to update the thread. Actually I am no longer sure how I go this error. I am re-running the full test suite because I cannot reproduce it when running the test_stats.py module alone. -- Olivier ___ NumPy-Discussion mailing list

Re: [Numpy-discussion] Using OpenBLAS for manylinux wheels

2016-04-05 19:44 GMT+02:00 Nathaniel Smith : > >> I propose to hold off distributing the OpenBLAS wheels until the >> OpenBLAS tests are clean on the OpenBLAS buildbots - any objections? > > Alternatively, would it make sense to add a local patch to our openblas > builds to

[Numpy-discussion] mtrand.c update 1.11 breaks my crappy code

I have C++ code that tries to share the mtrand state. It unfortunately depends on the layout of RandomState which used to be: struct __pyx_obj_6mtrand_RandomState { PyObject_HEAD rk_state *internal_state; PyObject *lock; }; But with 1.11 it's: struct __pyx_obj_6mtrand_RandomState {

Re: [Numpy-discussion] Using OpenBLAS for manylinux wheels

I updated the issue: https://github.com/xianyi/OpenBLAS-CI/issues/10#issuecomment-206195714 The random test_nanmedian_all_axis failure is unrelated to openblas and should be ignored. -- Olivier ___ NumPy-Discussion mailing list

Re: [Numpy-discussion] mtrand.c update 1.11 breaks my crappy code

Robert Kern wrote: > On Wed, Apr 6, 2016 at 2:18 PM, Neal Becker wrote: >> >> I have C++ code that tries to share the mtrand state. It unfortunately >> depends on the layout of RandomState which used to be: >> >> struct __pyx_obj_6mtrand_RandomState { >> PyObject_HEAD >>

Re: [Numpy-discussion] mtrand.c update 1.11 breaks my crappy code

On Apr 6, 2016 06:31, "Robert Kern" wrote: > > On Wed, Apr 6, 2016 at 2:18 PM, Neal Becker wrote: > > > > I have C++ code that tries to share the mtrand state. It unfortunately > > depends on the layout of RandomState which used to be: > > > > struct

Re: [Numpy-discussion] mtrand.c update 1.11 breaks my crappy code

On Wed, Apr 6, 2016 at 2:18 PM, Neal Becker wrote: > > I have C++ code that tries to share the mtrand state. It unfortunately > depends on the layout of RandomState which used to be: > > struct __pyx_obj_6mtrand_RandomState { > PyObject_HEAD > rk_state *internal_state; >

Re: [Numpy-discussion] mtrand.c update 1.11 breaks my crappy code

Neal Becker wrote: > Robert Kern wrote: > >> On Wed, Apr 6, 2016 at 2:18 PM, Neal Becker wrote: >>> >>> I have C++ code that tries to share the mtrand state. It unfortunately >>> depends on the layout of RandomState which used to be: >>> >>> struct

Re: [Numpy-discussion] mtrand.c update 1.11 breaks my crappy code

Nathaniel Smith wrote: > On Apr 6, 2016 06:31, "Robert Kern" wrote: >> >> On Wed, Apr 6, 2016 at 2:18 PM, Neal Becker wrote: >> > >> > I have C++ code that tries to share the mtrand state. It unfortunately >> > depends on the layout of RandomState

Re: [Numpy-discussion] mtrand.c update 1.11 breaks my crappy code

On Wed, Apr 6, 2016 at 4:17 PM, Neal Becker wrote: > I prefer to use a single instance of a RandomState so that there are > guarantees about the independence of streams generated from python random > functions, and from my c++ code. True, there are simpler approaches - but