tril, triu, document/ implementation conflict
Hi, I just noticed a document/ implementation conflict with tril and triu. According tril documentation it should return of same shape and data-type as called. But this is not the case at least with dtype bool. The input shape is referred as (M, N) in tril and triu, but as (N, M) in tri. Inconsistent? Also I'm not very happy with the performance, at least dtype bool can be accelerated as follows. In []: M= ones((2000, 3000), dtype= bool) In []: timeit triu(M) 10 loops, best of 3: 173 ms per loop In []: timeit triu_(M) 10 loops, best of 3: 107 ms per loop In []: M= asarray(M, dtype= int) In []: timeit triu(M) 10 loops, best of 3: 160 ms per loop In []: timeit triu_(M) 10 loops, best of 3: 163 ms per loop In []: M= asarray(M, dtype= float) In []: timeit triu(M) 10 loops, best of 3: 195 ms per loop In []: timeit triu_(M) 10 loops, best of 3: 157 ms per loop I have attached a crude 'fix' incase someone is interested. Regards, eat
On Wed, Jan 26, 2011 at 7:22 AM, eat <e.antero.tammi@gmail.com> wrote:
Hi,
I just noticed a document/ implementation conflict with tril and triu. According tril documentation it should return of same shape and data-type as called. But this is not the case at least with dtype bool.
The input shape is referred as (M, N) in tril and triu, but as (N, M) in tri. Inconsistent?
Also I'm not very happy with the performance, at least dtype bool can be accelerated as follows.
In []: M= ones((2000, 3000), dtype= bool) In []: timeit triu(M) 10 loops, best of 3: 173 ms per loop In []: timeit triu_(M) 10 loops, best of 3: 107 ms per loop
In []: M= asarray(M, dtype= int) In []: timeit triu(M) 10 loops, best of 3: 160 ms per loop In []: timeit triu_(M) 10 loops, best of 3: 163 ms per loop
In []: M= asarray(M, dtype= float) In []: timeit triu(M) 10 loops, best of 3: 195 ms per loop In []: timeit triu_(M) 10 loops, best of 3: 157 ms per loop
I have attached a crude 'fix' incase someone is interested.
You could open a ticket for this. just one comment: I don't think this is readable, especially if we only look at the source of the function with np.source out= mul(ge(so(ar(m.shape[0]), ar(m.shape[1])), -k), m) from np.source(np.tri) with numpy 1.5.1 m = greater_equal(subtract.outer(arange(N), arange(M)),-k) Josef
Regards, eat _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi, On Wed, Jan 26, 2011 at 2:35 PM, <josef.pktd@gmail.com> wrote:
On Wed, Jan 26, 2011 at 7:22 AM, eat <e.antero.tammi@gmail.com> wrote:
Hi,
I just noticed a document/ implementation conflict with tril and triu. According tril documentation it should return of same shape and data-type as called. But this is not the case at least with dtype bool.
The input shape is referred as (M, N) in tril and triu, but as (N, M) in tri. Inconsistent?
Any comments about the names for rows and cols. I prefer (M, N).
Also I'm not very happy with the performance, at least dtype bool can be accelerated as follows.
In []: M= ones((2000, 3000), dtype= bool) In []: timeit triu(M) 10 loops, best of 3: 173 ms per loop In []: timeit triu_(M) 10 loops, best of 3: 107 ms per loop
In []: M= asarray(M, dtype= int) In []: timeit triu(M) 10 loops, best of 3: 160 ms per loop In []: timeit triu_(M) 10 loops, best of 3: 163 ms per loop
In []: M= asarray(M, dtype= float) In []: timeit triu(M) 10 loops, best of 3: 195 ms per loop In []: timeit triu_(M) 10 loops, best of 3: 157 ms per loop
I have attached a crude 'fix' incase someone is interested.
You could open a ticket for this.
just one comment: I don't think this is readable, especially if we only look at the source of the function with np.source
out= mul(ge(so(ar(m.shape[0]), ar(m.shape[1])), -k), m)
from np.source(np.tri) with numpy 1.5.1 m = greater_equal(subtract.outer(arange(N), arange(M)),-k)
I agree, thats why I called it crude. Before opening a ticket I'll try to figure out if there exists somewhere in numpy .astype functionality, but not copying if allready proper dtype. Also I'm afraid that I can't produce sufficient testing. Regards, eat
Josef
Regards, eat _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
participants (2)
-
eat -
josef.pktd＠gmail.com