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 >> > behavior, since it transposing a 1D array is meaningless. However, this >> > can >> > often lead to unexpected errors since this is rarely what you want. You >> > can >> > convert the array to 2D, using `np.atleast_2d` or `arr[None]`, but this >> > makes simple linear algebra computations more difficult. >> > >> > I propose adding an argument to transpose, perhaps called `expand` or >> > `expanddim`, which if `True` (it is `False` by default) will force the >> > array >> > to be at least 2D. A shortcut property, `ndarray.T2`, would be the same >> > as >> > `ndarray.transpose(True)`. >> >> 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, m) >> matrices, and transpose each of those matrices, so the output shape is >> (..., m, n). And since this operation intrinsically acts on arrays >> with shape (..., n, m) then trying to apply it to a 0d or 1d array >> would be an error. >> > > My intention was to make linear algebra operations easier in numpy. With > the @ operator available, it is now very easy to do basic linear algebra on > arrays without needing the matrix class. But getting an array into a state > where you can use the @ operator effectively is currently pretty verbose and > confusing. I was trying to find a way to make the @ operator more useful. Can you elaborate on what you're doing that you find verbose and confusing, maybe paste an example? I've never had any trouble like this doing linear algebra with @ or dot (which have similar semantics for 1d arrays), which is probably just because I've had different use cases, but it's much easier to talk about these things with a concrete example in front of us to put everyone on the same page. -n -- Nathaniel J. Smith -- https://vorpus.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
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 "correct" shape. Ideally, a row vector is (1, N) and a column vector is (N,1). Though I know there are places that a 1-D array is treated as a column vector. > > >> BTW, if transposing a (N,) array gives you a (N,1) array, what does >> transposing a (N,1) array give you? >> >> (1,N) or (N,) ? >> > > 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` function. > my point is that for 2D arrays: arr.T.T == arr, but in this case, we would be making a one way street: when you transpose a 1D array, you treat it as a row vector, and return a "column vector" -- a (N,1) array. But when you transpose a "column vector" to get a row vector, you get a (1,N) array, not a (N) array. So I think we need to either have proper row and column vectors (to go with matrices) or require people to create the appropriate 2D arrays. Perhaps there should be an easier more obvious way to spell "make this a column vector", but I don't think .T is it. Though arr.shape = (-1,1) has always worked fine for me. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
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` function. I truly hope nothing is done like this. But underlying the proposal is apparently the idea that there be an attribute equivalent to `atleast_2d`. Then call it `d2p`. You can now have `a.d2p.T` which is a lot more explicit and general than say `a.T2`, while requiring only 3 more keystrokes. (It's still horribly ugly, though, and I hope this too is dismissed.) Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
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 then it would > be clear. But while there has been a lot of discussion about that in > the past, the fact is that no one wants it bad enough to write the > code. > > So I think it's better to keep Numpy arrays "pure", and if you want to > change the rank of an array, you do so explicitly. > 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. > BTW, if transposing a (N,) array gives you a (N,1) array, what does > transposing a (N,1) array give you? > > (1,N) or (N,) ? > 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` function. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
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, this > can > > often lead to unexpected errors since this is rarely what you want. You > can > > convert the array to 2D, using `np.atleast_2d` or `arr[None]`, but this > > makes simple linear algebra computations more difficult. > > > > I propose adding an argument to transpose, perhaps called `expand` or > > `expanddim`, which if `True` (it is `False` by default) will force the > array > > to be at least 2D. A shortcut property, `ndarray.T2`, would be the same > as > > `ndarray.transpose(True)`. > > 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, m) > matrices, and transpose each of those matrices, so the output shape is > (..., m, n). And since this operation intrinsically acts on arrays > with shape (..., n, m) then trying to apply it to a 0d or 1d array > would be an error. > > My intention was to make linear algebra operations easier in numpy. With the @ operator available, it is now very easy to do basic linear algebra on arrays without needing the matrix class. But getting an array into a state where you can use the @ operator effectively is currently pretty verbose and confusing. I was trying to find a way to make the @ operator more useful. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
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 a row vector or a column vector for > the purposes of transposition? The "correct" answer is not clear to me. > > Juan. > > On Wed, Apr 6, 2016 at 12:26 PM, Alan Isaac wrote: > >> On 4/5/2016 10: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 can often lead to unexpected errors since this is rarely >>> what you want. You can convert the array to 2D, using `np.atleast_2d` >>> or `arr[None]`, but this makes simple linear algebra computations more >>> difficult. >>> >>> I propose adding an argument to transpose, perhaps called `expand` or >>> `expanddim`, which if `True` (it is `False` by default) will force the >>> array to be at least 2D. A shortcut property, `ndarray.T2`, would be >>> the same as `ndarray.transpose(True)`. >>> >> >> >> >> Use `dot`. E.g., >> m.dot(a) >> >> hth, >> Alan Isaac >> >> >> >> ___ >> 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 > > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
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 > can > > often lead to unexpected errors since this is rarely what you want. You > can > > convert the array to 2D, using `np.atleast_2d` or `arr[None]`, but this > > makes simple linear algebra computations more difficult. > > > > I propose adding an argument to transpose, perhaps called `expand` or > > `expanddim`, which if `True` (it is `False` by default) will force the > array > > to be at least 2D. A shortcut property, `ndarray.T2`, would be the same > as > > `ndarray.transpose(True)`. > > 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, m) > matrices, and transpose each of those matrices, so the output shape is > (..., m, n). And since this operation intrinsically acts on arrays > with shape (..., n, m) then trying to apply it to a 0d or 1d array > would be an error. > > -n > > -- > Nathaniel J. Smith -- https://vorpus.org > I agree that we could really use a shorter syntax for a broadcasting transpose. Swapaxes is far too verbose for something that should be so common now that we've introduced the new matmul operator. That said, the fact that 1-D vectors are conceptually so similar to row vectors makes transposing a 1-D array a potential pitfall for a lot of people. When broadcasting along the leading dimension, a (n) shaped array and a (1, n) shaped array are already treated as equivalent. Treating a 1-D array like a row vector for transposes seems like a reasonable way to make things more intuitive for users. Rather than raising an error for arrays with fewer than two dimensions, the new syntax could be made equivalent to np.swapaxes(np.atleast2d(arr), -1, -2). From the standpoint of broadcasting semantics, using atleast2d can be viewed as allowing broadcasting along the inner dimensions. Though that's not a common thing, at least there's a precedent. The only downside I can see with allowing T2 to call atleast2d is that it would make things like A @ b and A @ b.T2 equivalent when B is one-dimensional. That's already the case with our current syntax though. There's some inherent design tension between the fact that broadcasting usually prepends ones to fill in missing dimensions and the fact that our current linear algebra semantics often treat rows as columns, but making 1-D arrays into rows makes a lot of sense as far as user experience goes. Great ideas everyone! Best, -Ian Henriksen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ndarray.T2 for 2D transpose
> I think that the problem is not that it doesn't raise an error for 1D array, > but that it doesn't do anything useful to 1D arrays. Raising an error would > change nothing to the way transpose is used now. No, but it would make it clear that you can't expect transpose to make a 1D array into a2D array. > For a 1D array a of shape (N,), I expect a.T2 to be of shape (N, 1), Why not (1,N)? -- it is not well defined, though I suppose it's not so bad to establish a convention that a 1-D array is a "row vector" rather than a "column vector". 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 then it would be clear. But while there has been a lot of discussion about that in the past, the fact is that no one wants it bad enough to write the code. So I think it's better to keep Numpy arrays "pure", and if you want to change the rank of an array, you do so explicitly. I use: A_vector.shape = (-1,1) BTW, if transposing a (N,) array gives you a (N,1) array, what does transposing a (N,1) array give you? (1,N) or (N,) ? -CHB > which > is useful when writing formulas, and clearer that a[None].T. Actually I'd > like a.T to do that alreadu, but I guess backward compatibility is more > important. > > > ___ > 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] 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 > I'm a purist. Consider using PRNGs that actually expose truly independent streams instead of a single shared stream: https://github.com/bashtage/ng-numpy-randomstate -- Robert Kern ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
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 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 {
>> > PyObject_HEAD
>> > struct __pyx_vtabstruct_6mtrand_RandomState *__pyx_vtab;
>> > rk_state *internal_state;
>> > PyObject *lock;
>> > PyObject *state_address;
>> > };
>> >
>> > So
>> > 1. Why the change?
>> > 2. How can I write portable code?
>>
>> There is no C API to RandomState at this time, stable, portable or
> otherwise. It's all private implementation detail. If you would like a
> stable and portable C API for RandomState, you will need to contribute one
> using PyCapsules to expose the underlying rk_state* pointer.
>>
>> https://docs.python.org/2.7/c-api/capsule.html
>
> I'm very wary about the idea of exposing the rk_state pointer at all. We
> could have a C API to random but my strong preference would be for
> something that only exposes opaque function calls that take a RandomState
> and return some random numbers, and getting even this right in a clean and
> maintainable way isn't trivial.
>
> Obviously another option is to call one of the python methods to get an
> ndarray and read out its memory contents. If you can do this in a batch
> (fetching a bunch of numbers for each call) to amortize the additional
> overhead of going through python, then it might work fine. (Python
> overhead is not actually that much -- mostly just having to do a handful
> of extra allocations.)
>
> Or, possibly the best option, one could use one of the many fine C random
> libraries inside your code, and if you need your code to be deterministic
> given a RandomState you could derive your state initialization from a
> single call to some RandomState method.
>
> -n
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
I'm a purist.
Yes, if there were an api use mkl random functions from a RandomState object
that would solve my problem. Or even if there was an API to get a
internal_state pointer from a RandomState object.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
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 __pyx_obj_6mtrand_RandomState {
> > PyObject_HEAD
> > rk_state *internal_state;
> > PyObject *lock;
> > };
> >
> > But with 1.11 it's:
> > struct __pyx_obj_6mtrand_RandomState {
> > PyObject_HEAD
> > struct __pyx_vtabstruct_6mtrand_RandomState *__pyx_vtab;
> > rk_state *internal_state;
> > PyObject *lock;
> > PyObject *state_address;
> > };
> >
> > So
> > 1. Why the change?
> > 2. How can I write portable code?
>
> There is no C API to RandomState at this time, stable, portable or
otherwise. It's all private implementation detail. If you would like a
stable and portable C API for RandomState, you will need to contribute one
using PyCapsules to expose the underlying rk_state* pointer.
>
> https://docs.python.org/2.7/c-api/capsule.html
I'm very wary about the idea of exposing the rk_state pointer at all. We
could have a C API to random but my strong preference would be for
something that only exposes opaque function calls that take a RandomState
and return some random numbers, and getting even this right in a clean and
maintainable way isn't trivial.
Obviously another option is to call one of the python methods to get an
ndarray and read out its memory contents. If you can do this in a batch
(fetching a bunch of numbers for each call) to amortize the additional
overhead of going through python, then it might work fine. (Python overhead
is not actually that much -- mostly just having to do a handful of extra
allocations.)
Or, possibly the best option, one could use one of the many fine C random
libraries inside your code, and if you need your code to be deterministic
given a RandomState you could derive your state initialization from a
single call to some RandomState method.
-n
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
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 __pyx_obj_6mtrand_RandomState {
>>> PyObject_HEAD
>>> rk_state *internal_state;
>>> PyObject *lock;
>>> };
>>>
>>> But with 1.11 it's:
>>> struct __pyx_obj_6mtrand_RandomState {
>>> PyObject_HEAD
>>> struct __pyx_vtabstruct_6mtrand_RandomState *__pyx_vtab;
>>> rk_state *internal_state;
>>> PyObject *lock;
>>> PyObject *state_address;
>>> };
>>>
>>> So
>>> 1. Why the change?
>>> 2. How can I write portable code?
>>
>> There is no C API to RandomState at this time, stable, portable or
>> otherwise. It's all private implementation detail. If you would like a
>> stable and portable C API for RandomState, you will need to contribute
>> one using PyCapsules to expose the underlying rk_state* pointer.
>>
>> https://docs.python.org/2.7/c-api/capsule.html
>>
>> --
>> Robert Kern
>
> I don't see how pycapsule helps here. What I need is, my C++ code
> receives
> a RandomState object. I need to call e.g., rk_random, passing the pointer
> to rk_state - code looks like this;
>
> RandomState* r = (RandomState*)(rs.ptr());
> //result_type buffer;
> //rk_fill ((void*)&buffer, sizeof(buffer), r->internal_state);
> if (sizeof(result_type) == sizeof (uint64_t))
> return rk_ulong (r->internal_state);
> else if (sizeof(result_type) == sizeof (uint32_t))
> return rk_random (r->internal_state);
Nevermind, I see it's described here:
https://docs.python.org/2.7/extending/extending.html#using-capsules
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
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
>> rk_state *internal_state;
>> PyObject *lock;
>> };
>>
>> But with 1.11 it's:
>> struct __pyx_obj_6mtrand_RandomState {
>> PyObject_HEAD
>> struct __pyx_vtabstruct_6mtrand_RandomState *__pyx_vtab;
>> rk_state *internal_state;
>> PyObject *lock;
>> PyObject *state_address;
>> };
>>
>> So
>> 1. Why the change?
>> 2. How can I write portable code?
>
> There is no C API to RandomState at this time, stable, portable or
> otherwise. It's all private implementation detail. If you would like a
> stable and portable C API for RandomState, you will need to contribute one
> using PyCapsules to expose the underlying rk_state* pointer.
>
> https://docs.python.org/2.7/c-api/capsule.html
>
> --
> Robert Kern
I don't see how pycapsule helps here. What I need is, my C++ code receives
a RandomState object. I need to call e.g., rk_random, passing the pointer
to rk_state - code looks like this;
RandomState* r = (RandomState*)(rs.ptr());
//result_type buffer;
//rk_fill ((void*)&buffer, sizeof(buffer), r->internal_state);
if (sizeof(result_type) == sizeof (uint64_t))
return rk_ulong (r->internal_state);
else if (sizeof(result_type) == sizeof (uint32_t))
return rk_random (r->internal_state);
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
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 NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
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;
> PyObject *lock;
> };
>
> But with 1.11 it's:
> struct __pyx_obj_6mtrand_RandomState {
> PyObject_HEAD
> struct __pyx_vtabstruct_6mtrand_RandomState *__pyx_vtab;
> rk_state *internal_state;
> PyObject *lock;
> PyObject *state_address;
> };
>
> So
> 1. Why the change?
> 2. How can I write portable code?
There is no C API to RandomState at this time, stable, portable or
otherwise. It's all private implementation detail. If you would like a
stable and portable C API for RandomState, you will need to contribute one
using PyCapsules to expose the underlying rk_state* pointer.
https://docs.python.org/2.7/c-api/capsule.html
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
[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 {
PyObject_HEAD
struct __pyx_vtabstruct_6mtrand_RandomState *__pyx_vtab;
rk_state *internal_state;
PyObject *lock;
PyObject *state_address;
};
So
1. Why the change?
2. How can I write portable code?
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
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 NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
[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 https://gist.github.com/maedoc/a41cb253011ad55edacca560a66dff76 I build from Git master with BLAS=none LAPACK=none ATLAS=none python setup.py install Currently, most of NumPy works, except linear algebra calls, like pinv, which segfault inside the MKL: np.__config__.show() shows NumPy thinks it linked against OpenBLAS with a CBLAS ABI, not a standard Fortran BLAS api. Is there a way to force the NumPy build to ignore OpenBLAS and assume it's calling the standard Fortran style BLAS functions? Thanks in advance for any comments or suggestions, Marmaduke [1] http://fr.mathworks.com/help/matlab/call-python-libraries.html ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
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? >> >> Alternatively, would it make sense to add a local patch to our openblas >> builds to blacklist the piledriver kernel and then distribute them now? (I'm >> not immediately sure what would be involved in doing this but it seems >> unlikely that it would require anything tricky?) > > I tried to force use the NEHALEM or the BARCELONA driver on a PILEDRIVER > AMD box and while it fixes the original test failure in isolve it > causes this other > scipy test to fail: > > == > FAIL: test_nanmedian_all_axis (test_stats.TestNanFunc) > -- > Traceback (most recent call last): > File > "/usr/local/lib/python2.7/site-packages/scipy/stats/tests/test_stats.py", > line 242, in test_nanmedian_all_axis > assert_equal(len(w), 4) > File "/usr/local/lib/python2.7/site-packages/numpy/testing/utils.py", > line 375, in assert_equal > raise AssertionError(msg) > AssertionError: > Items are not equal: > ACTUAL: 1 > DESIRED: 4 I'm reading this email next to https://github.com/xianyi/OpenBLAS-CI/issues/10#issuecomment-206195714 and I'm confused :-). -n -- Nathaniel J. Smith -- https://vorpus.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
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, m) > matrices, and transpose each of those matrices, so the output shape is > (..., m, n). And since this operation intrinsically acts on arrays > with shape (..., n, m) then trying to apply it to a 0d or 1d array > would be an error. I think that the problem is not that it doesn't raise an error for 1D array, but that it doesn't do anything useful to 1D arrays. Raising an error would change nothing to the way transpose is used now. For a 1D array a of shape (N,), I expect a.T2 to be of shape (N, 1), which is useful when writing formulas, and clearer that a[None].T. Actually I'd like a.T to do that alreadu, but I guess backward compatibility is more important. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
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 blacklist the piledriver kernel and then distribute them now? (I'm > not immediately sure what would be involved in doing this but it seems > unlikely that it would require anything tricky?) I tried to force use the NEHALEM or the BARCELONA driver on a PILEDRIVER AMD box and while it fixes the original test failure in isolve it causes this other scipy test to fail: == FAIL: test_nanmedian_all_axis (test_stats.TestNanFunc) -- Traceback (most recent call last): File "/usr/local/lib/python2.7/site-packages/scipy/stats/tests/test_stats.py", line 242, in test_nanmedian_all_axis assert_equal(len(w), 4) File "/usr/local/lib/python2.7/site-packages/numpy/testing/utils.py", line 375, in assert_equal raise AssertionError(msg) AssertionError: Items are not equal: ACTUAL: 1 DESIRED: 4 -- Olivier http://twitter.com/ogrisel - http://github.com/ogrisel ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
