On Mon, May 28, 2018, 20:41 Stephan Hoyer wrote:
> On Mon, May 28, 2018 at 7:36 PM Eric Wieser
> wrote:
>
>> which ensure that it is still well defined (as the identity) on 1d
>> arrays.
>>
>> This strikes me as a bad idea. There’s already enough confusion from
>> beginners that array_1d.T is a
Apart from the math-validity discussion, in my experience errors are used a
bit too generously in the not-allowed ops. No ops are fine once you learn
more about them such as transpose on 1D arrays (good or bad is another
discussion). But raising errors bloat the computational code too much. "Is
it
On Tue, May 29, 2018 at 12:16 PM, Daπid wrote:
> Right now, np.int(8).T throws an error, but np.transpose(np.int(8)) gives a
> 0-d array. On one hand, it is nice to be able to use the same code for
`np.int` is just python `int`! What you mean is `np.int64(8).T` which
works fine, so does `np.array
On 29 May 2018 at 05:40, Stephan Hoyer wrote:
> But given that idiomatic NumPy code uses 1D arrays in favor of explicit
> row/column vectors with shapes (1,n) and (n,1), I do think it does make
> sense for matrix transpose on 1D arrays to be the identity, because matrix
> transpose should convert
On Tue, May 29, 2018 at 5:40 AM, Stephan Hoyer wrote:
> But given that idiomatic NumPy code uses 1D arrays in favor of explicit
> row/column vectors with shapes (1,n) and (n,1), I do think it does make
> sense for matrix transpose on 1D arrays to be the identity, because matrix
> transpose should
On Mon, May 28, 2018 at 7:36 PM Eric Wieser
wrote:
> which ensure that it is still well defined (as the identity) on 1d arrays.
>
> This strikes me as a bad idea. There’s already enough confusion from
> beginners that array_1d.T is a no-op. If we introduce a matrix-transpose,
> it should either e
which ensure that it is still well defined (as the identity) on 1d arrays.
This strikes me as a bad idea. There’s already enough confusion from
beginners that array_1d.T is a no-op. If we introduce a matrix-transpose,
it should either error on <1d inputs with a useful message, or insert the
extra
On Mon, May 28, 2018 at 4:26 PM, Stephan Hoyer wrote:
> On Mon, May 21, 2018 at 5:42 PM Matti Picus wrote:
>>
>> - create a wrapper that can convince the ufunc mechanism to call
>> __array_ufunc__ even on functions that are not true ufuncs
>
>
> I am somewhat opposed to this approach, because __a
On Mon, May 21, 2018 at 5:42 PM Matti Picus wrote:
> - create a wrapper that can convince the ufunc mechanism to call
> __array_ufunc__ even on functions that are not true ufuncs
>
I am somewhat opposed to this approach, because __array_ufunc__ is about
overloading ufuncs, and as soon as we rela
I have made progress with resolving the issue that matmul, the operation
which implements `a @ b`, is not a ufunc [2]. Discussion on the issue,
which prevents the __array_ufunc__ mechanism for overriding matmul on
subclasses of ndarray, yeilded two approaches:
- create a wrapper that can convi
10 matches
Mail list logo
