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
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,
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 lo
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.c
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
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 {
PyOb
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;
> }
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.
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_s
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
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 {
> > PyObjec
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_6m
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.
Consi
> 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
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 er
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 col
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
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 th
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
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.
Idea
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 meaning
21 matches
Mail list logo