Re: [Numpy-discussion] To wrap or not to wrap.

[Charles R Harris]

On Sat, Apr 26, 2008 at 10:31 PM, Robert Kern <[EMAIL PROTECTED]> wrote:

> On Sat, Apr 26, 2008 at 11:23 PM, Charles R Harris
> <[EMAIL PROTECTED]> wrote:
> > Hi All,
> >
> > I'm working through the linalg module. There is currently variation as
> to
> > whether or not eigenvalues/singular_values/residuals, are returned as
> > arrays or as matrices. I'm leaning towards making them all matrices.
>
> Only when the inputs are matrices, right?
>

Right.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] What is __array_wrap__ supposed to do?

[Charles R Harris]

On Sat, Apr 26, 2008 at 10:31 PM, Andreas Klöckner <[EMAIL PROTECTED]>
wrote:

> On Samstag 26 April 2008, Charles R Harris wrote:
> > I'm working through the linalg module. There is currently variation as
> to
> > whether or not eigenvalues/singular_values/residuals, are returned as
> > arrays or as matrices. I'm leaning towards making them all matrices.
> What
> > do you think?
>
> IMO, the user should only get matrices if he used them to start with. I'm
> somewhat scared by all the disagreement about matrix semantics, and so if
> I
> don't touch matrices myself, I don't want them forced on me, thank you
> very
> much.
>

Well, that's what I meant, if not quite what I said.. The question is what
they
should be when the input is a matrix.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] What is __array_wrap__ supposed to do?

[Andreas Klöckner]

On Samstag 26 April 2008, Charles R Harris wrote:
> I'm working through the linalg module. There is currently variation as to
> whether or not eigenvalues/singular_values/residuals, are returned as
> arrays or as matrices. I'm leaning towards making them all matrices. What
> do you think?

IMO, the user should only get matrices if he used them to start with. I'm 
somewhat scared by all the disagreement about matrix semantics, and so if I 
don't touch matrices myself, I don't want them forced on me, thank you very 
much.

Or, if you prefer a briefer reply: NOoo! :)

Andreas


signature.asc
Description: This is a digitally signed message part.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] To wrap or not to wrap.

[Robert Kern]

On Sat, Apr 26, 2008 at 11:23 PM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
> Hi All,
>
> I'm working through the linalg module. There is currently variation as to
> whether or not eigenvalues/singular_values/residuals, are returned as
> arrays or as matrices. I'm leaning towards making them all matrices.

Only when the inputs are matrices, right?

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
 -- Umberto Eco
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] To wrap or not to wrap.

[Charles R Harris]

Hi All,

I'm working through the linalg module. There is currently variation as to
whether or not eigenvalues/singular_values/residuals, are returned as
arrays or as matrices. I'm leaning towards making them all matrices.
But I expect masked arrays will also be preserved and I don't know what
that will mean to people. What should be the standard here?

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] What is __array_wrap__ supposed to do?

[Charles R Harris]

On Sat, Apr 26, 2008 at 9:29 PM, Robert Kern <[EMAIL PROTECTED]> wrote:

> On Sat, Apr 26, 2008 at 10:04 PM, Charles R Harris
> <[EMAIL PROTECTED]> wrote:
> >
> > On Sat, Apr 26, 2008 at 8:59 PM, Robert Kern <[EMAIL PROTECTED]>
> wrote:
> > >
> > > On Sat, Apr 26, 2008 at 9:27 PM, Charles R Harris
> > > <[EMAIL PROTECTED]> wrote:
> > > > Because it doesn't do what it says it does.
> > >
> > >
> > > > Here is what the docstring says:
> > > >
> > > > Help on method_descriptor:
> > > >
> > > > __array_wrap__(...)
> > > > a.__array_wrap__(obj) -> Object of same type as a from ndarray
> obj.
> > >
> > > Python type, not numpy dtype.
> >
> > So basically it's good for keeping matrices matrices?
>
> Yes, that is what it is used for.
>

I'm working through the linalg module. There is currently variation as to
whether or not eigenvalues/singular_values/residuals, are returned as arrays
or as matrices. I'm leaning towards making them all matrices. What do you
think?

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] What is __array_wrap__ supposed to do?

[Robert Kern]

On Sat, Apr 26, 2008 at 10:04 PM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
>
> On Sat, Apr 26, 2008 at 8:59 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> >
> > On Sat, Apr 26, 2008 at 9:27 PM, Charles R Harris
> > <[EMAIL PROTECTED]> wrote:
> > > Because it doesn't do what it says it does.
> >
> >
> > > Here is what the docstring says:
> > >
> > > Help on method_descriptor:
> > >
> > > __array_wrap__(...)
> > > a.__array_wrap__(obj) -> Object of same type as a from ndarray obj.
> >
> > Python type, not numpy dtype.
>
> So basically it's good for keeping matrices matrices?

Yes, that is what it is used for.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
 -- Umberto Eco
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] What is __array_wrap__ supposed to do?

[Charles R Harris]

On Sat, Apr 26, 2008 at 8:59 PM, Robert Kern <[EMAIL PROTECTED]> wrote:

> On Sat, Apr 26, 2008 at 9:27 PM, Charles R Harris
> <[EMAIL PROTECTED]> wrote:
> > Because it doesn't do what it says it does.
>
> > Here is what the docstring says:
> >
> > Help on method_descriptor:
> >
> > __array_wrap__(...)
> > a.__array_wrap__(obj) -> Object of same type as a from ndarray obj.
>
> Python type, not numpy dtype.
>

So basically it's good for keeping matrices matrices?

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] What is __array_wrap__ supposed to do?

[Robert Kern]

On Sat, Apr 26, 2008 at 9:27 PM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
> Because it doesn't do what it says it does.

> Here is what the docstring says:
>
> Help on method_descriptor:
>
> __array_wrap__(...)
> a.__array_wrap__(obj) -> Object of same type as a from ndarray obj.

Python type, not numpy dtype.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
 -- Umberto Eco
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] What is __array_wrap__ supposed to do?

[Charles R Harris]

Because it doesn't do what it says it does.

In [31]: b.__array_wrap__(a).dtype
Out[31]: dtype('float64')

In [32]: a.__array_wrap__(b).dtype
Out[32]: dtype('int8')

In [33]: a
Out[33]:
array([[ 1.,  1.,  1.],
   [ 1.,  1.,  1.],
   [ 1.,  1.,  1.]])

In [34]: b
Out[34]:
array([[1, 1, 1],
   [1, 1, 1],
   [1, 1, 1]], dtype=int8)

Here is what the docstring says:

Help on method_descriptor:

__array_wrap__(...)
a.__array_wrap__(obj) -> Object of same type as a from ndarray obj.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Threading question for Travis

[Travis E. Oliphant]

Charles R Harris wrote:
>
>
> On Sat, Apr 26, 2008 at 11:21 AM, Travis E. Oliphant 
> <[EMAIL PROTECTED] > wrote:
>
> Charles R Harris wrote:
> > Travis,
> >
> > Is this correct?
> >
> Yes.
> > NPY_LOOP_BEGIN_THREADS;
> > switch(loop->meth) {
> > case ONE_UFUNCLOOP:
> > /*
> >  * Everything is contiguous, notswapped, aligned,
> >  * and of the right type.  -- Fastest.
> >  * Or if not contiguous, then a single-stride
> >  * increment moves through the entire array.
> >  */
> > /*fprintf(stderr, "ONE...%d\n", loop->size);*/
> > loop->function((char **)loop->bufptr, &(loop->size),
> > loop->steps, loop->funcdata);
> > UFUNC_CHECK_ERROR(loop);
> > break;
> >
> > Note that UFUNC_CHECK_ERROR calls PyErr_Occurred. That doesn't seem
> > thread safe to me. Or maybe there is something special about that
> > function I'm missing.
> Check the definition of the macro.   It only calls PyErr_Occurred
> if the
> obj variable is non-zero on the loop structure, indicating an
> OBJECT-array loop.In that case, the NPY_LOOP_BEGIN_THREADS
> does not
> actually release the GIL either.
>
>
> I'm still bothered by the fact that moving the check fixed ticket #733 
> on python2.6, whereas in python2.5 the error was caught, just too late 
> to be useful. I'm also not sure why the x |= x loop goes through a 
> buffer loop. With a nice contiguous array it should have gone straight 
> through the fast loop.
It could be the need for data-type conversion as well.
 
I need to catch up with the ticket to understand what is going on, though.

-Travis

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Threading question for Travis

[Charles R Harris]

On Sat, Apr 26, 2008 at 11:21 AM, Travis E. Oliphant <[EMAIL PROTECTED]>
wrote:

> Charles R Harris wrote:
> > Travis,
> >
> > Is this correct?
> >
> Yes.
> > NPY_LOOP_BEGIN_THREADS;
> > switch(loop->meth) {
> > case ONE_UFUNCLOOP:
> > /*
> >  * Everything is contiguous, notswapped, aligned,
> >  * and of the right type.  -- Fastest.
> >  * Or if not contiguous, then a single-stride
> >  * increment moves through the entire array.
> >  */
> > /*fprintf(stderr, "ONE...%d\n", loop->size);*/
> > loop->function((char **)loop->bufptr, &(loop->size),
> > loop->steps, loop->funcdata);
> > UFUNC_CHECK_ERROR(loop);
> > break;
> >
> > Note that UFUNC_CHECK_ERROR calls PyErr_Occurred. That doesn't seem
> > thread safe to me. Or maybe there is something special about that
> > function I'm missing.
> Check the definition of the macro.   It only calls PyErr_Occurred if the
> obj variable is non-zero on the loop structure, indicating an
> OBJECT-array loop.In that case, the NPY_LOOP_BEGIN_THREADS does not
> actually release the GIL either.
>

I'm still bothered by the fact that moving the check fixed ticket #733 on
python2.6, whereas in python2.5 the error was caught, just too late to be
useful. I'm also not sure why the x |= x loop goes through a buffer loop.
With a nice contiguous array it should have gone straight through the fast
loop.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] [python] Re: Request for advice: project to get NumPy working in IronPython

[David]

Michael Foord  voidspace.org.uk> writes:
> > are you really going to run matrix inversion on the CLR in a browser?)

Yes!




___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] access ndarray in C++

[Hoyt Koepke]

Let me say also that I tried using boost.python a while back to
interface numpy with c++, and, while I got some things working, I
found the distribution and packaging end of things an order of
magnitude more complicated than what I found with weave.  Since weave
is built into scipy, as well as blitz itself (now recently under the
BSD license), it fits really well with numpy's distutils.  The only
dependencies on the user end are numpy and scipy, which they would
need anyway from the python end of the code.

Also, I find the syntax of blitz++ to be really simple and numpy-like.  E.g.

Array A;
A.resize(20,20);
for(int i = 0; i < 20; ++i)  A(i, Range::all() ) = i;
Array B = A(Range(2,18), 0);
B *= 2;
A(2, Range(5,10) ) += 2;
Array C = B*A(2, Range(1,17) );

and so on...  (I just typed this in here, prob some typos).

Anyway, after bouncing around for a bit I think I've found this to be
the solution that most closely fits my needs.
--Hoyt

On Sat, Apr 26, 2008 at 3:54 AM, Gael Varoquaux
<[EMAIL PROTECTED]> wrote:
> On Wed, Apr 23, 2008 at 09:47:46PM -0400, Andreas Klöckner wrote:
>  > > Any numpy-specific stuff for sip?
>
>  > Not as far as I'm aware. In fact, I don't know of any uses of sip outside 
> of
>  > Qt/KDE-related things.
>
>  Airbus uses it for heavy numerical work. They claim they have benchmarked
>  all the tools and SIP was the fastest.
>  If you want more information on that, you should contact the sip
>  developer, Phil Thompson, he does some contracting job for Airbus.
>
>  Cheers,
>
>  Gaël
>
>
> ___
>  Numpy-discussion mailing list
>  Numpy-discussion@scipy.org
>  http://projects.scipy.org/mailman/listinfo/numpy-discussion
>



-- 
+++
Hoyt Koepke
UBC Department of Computer Science
http://www.cs.ubc.ca/~hoytak/
[EMAIL PROTECTED]
+++
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] leaving matrix indexing discussion

[Gael Varoquaux]

On Sat, Apr 26, 2008 at 03:13:22PM -0400, Alan G Isaac wrote:
> At this point, I am starting to feel that I have abused my
> interlocutors.  So I will withdraw from the conversation.

Let us continue this discussion after numpy 1.1 is release, with no
feeling of urgency.

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Alan G Isaac]

On Sat, 26 Apr 2008, "Travis E. Oliphant" apparently wrote:
> I'm not personally persuaded by the iteration argument, because we can 
> change iteration independently of mapping (__getitem__) access. 


Would that not impose another deviation from array behavior?
I just do not see the purpose.

I support .row and .cols iterators (returning submatrices),
and have included the idea for some time on the discussion
page http://www.scipy.org/MatrixIndexing>.

Cheers,
Alan



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] leaving matrix indexing discussion

[Alan G Isaac]

At this point, I am starting to feel that I have abused my
interlocutors.  So I will withdraw from the conversation.
Apologies to those who feel I should have done so earlier.

The core issues are, I think, on the discussion page.
http://www.scipy.org/MatrixIndexing>
I hope people will read it before presenting arguments.
And improve it too.

Cheers,
Alan Isaac



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] reshape docstrings conflicting

[Pauli Virtanen]

Hi Chuck,

Charles R Harris wrote:
[clip]
> I noticed that you removed the ReST markup of the tables in sort
> documentation. I think you should leave it in.

Also the simplified table syntax

  
header 1 header 2 header 3
  
line 1a  line 1b  line 1c
line 2a  line 2b  line 2c
  

is valid ReST [1], and easier to type and IMHO to read than the gridded
tables:

+--+--+--+
| header 1 | header 2 | header 3 |
+==+==+==+
| line 1a  | line 1b  | line 1c  |
| line 2a  | line 2b  | line 2c  |
+--+--+--+

If you strongly prefer the gridded syntax, I can revert it back.

Pauli

.. [1]
http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#simple-tables

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] prerelease proposal for matrix behavior

[Alan G Isaac]

> Alan G Isaac wrote:
>> OK, we are not converging in time for the release. 
>> So can we at least raise a TypeError on scalar 
>> indexing of matrices, so that we remain free to choose 
>> the ultimate behavior? 


On Fri, 25 Apr 2008, "Travis E. Oliphant" apparently wrote:
> I think this is wise for the time being. 


In response to Bill's concern, I chose a warning instead:
http://scipy.org/scipy/numpy/attachment/ticket/760>

fwiw,
Alan



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] reshape docstrings conflicting

[Jarrod Millman]

On Sat, Apr 26, 2008 at 11:24 AM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
> I noticed that you removed the ReST markup of the tables in sort
> documentation. I think you should leave it in.

I haven't tried to render it, but I think he just changed the tables
from ReST's grid table to ReST's simple table format:
http://docutils.sourceforge.net/docs/user/rst/quickref.html#tables

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Travis E. Oliphant]

Alan G Isaac wrote:
> On Sat, 26 Apr 2008, Gael Varoquaux apparently wrote:
>   
>> For me this is wrong. list and tuples are not 2D. Numpy 
>> arrays happen to offer this feature, but you should not 
>> use it do to multiple dimension indexing. 
>> 
>
> But there is no proposal that people should index like this.
> The underlying issue is iteration.  Currently::
>
> >>> A
> matrix([[1,  2],
> [ 3,  4]])
> >>> A = np.mat(x)
> >>> for row in A:
> ...  for col in row:
> ...   print col
> ...
> [[1  2]]
> [[3 4]]
>
> So are you saying that one should not be able to iterate 
> through to the elements of a matrix?
>   

Iteration can be handled separately with __iter__ method that returns 
the actual iterator object which may be different.   Or, as others have 
proposed .rows and .cols iterators.

I'm not personally persuaded by the iteration argument, because we can 
change iteration independently of mapping (__getitem__) access.

-Travis

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] adding ``rows`` and ``columns`` attributes to matrices

[Gael Varoquaux]

On Sat, Apr 26, 2008 at 02:42:04PM -0400, Alan G Isaac wrote:
> As others have observed: why break array
> behavior for no purpose?

Because the behavior you are relying on is IMHO a coincidence.

Are other people on the mailing list relying on this? I strongly think it
is wrong, but maybe I am the lone man.

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] adding ``rows`` and ``columns`` attributes to matrices

[Alan G Isaac]

On Sat, 26 Apr 2008, Gael Varoquaux apparently wrote:
>  for row in A.rows():
>for col in row.cols()


Actually I am in favor of adding ``rows`` and ``cols`` 
attributes to allow such iteration.  The only thing is,
I say these should be matrices (i.e., 2d).  I.e., this
should provide a symmetric syntax (for rows and columns)
for iteration across submatrices.

But once we have these, it is all the more reason not
to object to letting iteration on the matrix yield
1d arrays.  As others have observed: why break array
behavior for no purpose?

Cheers,
Alan Isaac

PS The possibility of adding these attributes is mentioned
on the discussion page:
http://www.scipy.org/MatrixIndexing>
as are most of the issues that have been coming up again.

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Gael Varoquaux]

On Sat, Apr 26, 2008 at 02:32:01PM -0400, Alan G Isaac wrote:
> A list of lists is naturally conceived as 2d,
> which is why you can initialize a 2d matrix
> with a list of lists.

> Try a Google search on "python two dimensional list"
> to confirm that I am not promoting an anomalous view.

> So I do not buy the way you are trying to parse
> language here.  (Although I'm open to a fuller
> argument.)

The object is not 2D. You can assemble several objects into something
that looks 2D, but it is not 2D.

For exemple:

[[1, 2, 3], [1, 2]]

This is not 2D in an nd array sens. It how exposes a double successiv
indexing, but doubly 1D, and no 2D.

For nD objects, I think people should rather use either nD indexing, or
explicite 1D indexing of an nD object. By this is mean "A[1, ...]" rather
than "A[1]". If the later breaks, I, for one, won't cry.

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Alan G Isaac]

>> On Sat, 26 Apr 2008, Gael Varoquaux apparently wrote:
>>> I don't see where you get your universality. 


> On Sat, Apr 26, 2008 at 11:15:14AM -0400, Alan G Isaac 
> wrote:
>> Lists, tuples, arrays ... 
>> Where is the exception? 
>> Only matrices are the only 2d container I can 
>> think of that are broken this way. 


On Sat, 26 Apr 2008, Gael Varoquaux apparently wrote:
> List and Tuples are not 2D containers. 


A list of lists is naturally conceived as 2d,
which is why you can initialize a 2d matrix
with a list of lists.

Try a Google search on "python two dimensional list"
to confirm that I am not promoting an anomalous view.

So I do not buy the way you are trying to parse
language here.  (Although I'm open to a fuller
argument.)

Cheers,
Alan



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] reshape docstrings conflicting

[Charles R Harris]

On Sat, Apr 26, 2008 at 11:29 AM, Pauli Virtanen <[EMAIL PROTECTED]> wrote:

> Hi all,
>
> The ndarray.reshape docstring claims:
>
>"Also always returns a view or raises a ValueError if that is
>impossible."
>
> whereas fromnumeric.reshape claims:
>
>"This will be a new view object if possible; otherwise, it will
>be a copy."
>
> while the code paths for both functions are the same.
>
> So, which one of these is correct? Or, does ndarray.reshape always
> return a view? This is not immediately obvious looking at the code...
>
> I'll fix up the docstrings once I know.
>

Hi Pauli,

I noticed that you removed the ReST markup of the tables in sort
documentation. I think you should leave it in.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Gael Varoquaux]

On Sat, Apr 26, 2008 at 02:01:45PM -0400, Alan G Isaac wrote:
> >>> A
> matrix([[1,  2],
> [ 3,  4]])
> >>> A = np.mat(x)
> >>> for row in A:
> ...  for col in row:
> ...   print col
> ...
> [[1  2]]
> [[3 4]]

> So are you saying that one should not be able to iterate 
> through to the elements of a matrix?

I kinda expect this was the real issue.

I think the only way to get consistent behavior for such code is either

* to use a syntax similar to dictionnaries:

for row in A.rows():
for col in row.cols()

  I actually think this is much better than the code you currently use,

* or implement row and column objects.

The problem in your code is that you do not distinguish iterating over
rows and columns, and in linear algebra these are different objects. The
two solutions I propose do this distinction. My favorite one is the first
one (the rows and cols methods).

Cheers,

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Alan G Isaac]

On Sat, 26 Apr 2008, Gael Varoquaux apparently wrote:
> For me this is wrong. list and tuples are not 2D. Numpy 
> arrays happen to offer this feature, but you should not 
> use it do to multiple dimension indexing. 

But there is no proposal that people should index like this.
The underlying issue is iteration.  Currently::

>>> A
matrix([[1,  2],
[ 3,  4]])
>>> A = np.mat(x)
>>> for row in A:
...  for col in row:
...   print col
...
[[1  2]]
[[3 4]]

So are you saying that one should not be able to iterate 
through to the elements of a matrix?

So many natural expectations are broken by the current behavior!

Cheers,
Alan



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] reshape docstrings conflicting

[Pauli Virtanen]

Hi all,

The ndarray.reshape docstring claims:

"Also always returns a view or raises a ValueError if that is   
impossible."

whereas fromnumeric.reshape claims:

"This will be a new view object if possible; otherwise, it will
be a copy."

while the code paths for both functions are the same.

So, which one of these is correct? Or, does ndarray.reshape always
return a view? This is not immediately obvious looking at the code...

I'll fix up the docstrings once I know.

-- 
Pauli Virtanen
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Threading question for Travis

[Travis E. Oliphant]

Charles R Harris wrote:
> Travis,
>
> Is this correct?
>
Yes.
> NPY_LOOP_BEGIN_THREADS;
> switch(loop->meth) {
> case ONE_UFUNCLOOP:
> /*
>  * Everything is contiguous, notswapped, aligned,
>  * and of the right type.  -- Fastest.
>  * Or if not contiguous, then a single-stride
>  * increment moves through the entire array.
>  */
> /*fprintf(stderr, "ONE...%d\n", loop->size);*/
> loop->function((char **)loop->bufptr, &(loop->size),
> loop->steps, loop->funcdata);
> UFUNC_CHECK_ERROR(loop);
> break;
>
> Note that UFUNC_CHECK_ERROR calls PyErr_Occurred. That doesn't seem 
> thread safe to me. Or maybe there is something special about that 
> function I'm missing.
Check the definition of the macro.   It only calls PyErr_Occurred if the 
obj variable is non-zero on the loop structure, indicating an 
OBJECT-array loop.In that case, the NPY_LOOP_BEGIN_THREADS does not 
actually release the GIL either.

-Travis

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] tests in distutils/exec_command.py

[Pearu Peterson]

On Sat, April 26, 2008 7:53 pm, Zbyszek Szmek wrote:
> Hi,
> while looking at test coverage statistics published Stéfan van der Walt
> at http://mentat.za.net/numpy/coverage/, I noticed that the
> least-covered file, numpy/distutils/exec_command.py has it's own
> test routines, e.g.:
> def test_svn(**kws):
> s,o = exec_command(['svn','status'],**kws)
> assert s,(s,o)
> print 'svn ok'
>
> called as
> if __name__ == "__main__":
>test_svn(use_tee=1)
>
> The sense of this test seems reversed (svn status runs just fine):
> Traceback (most recent call last):
>   File "numpy/distutils/exec_command.py", line 591, in 
> test_svn(use_tee=1)
>   File "numpy/distutils/exec_command.py", line 567, in test_svn
> assert s,(s,o)
> AssertionError: (0, '')
>
> Should the test be cleaned up and moved into a seperate file in
> numpy/distutils/tests/ ?

Note that not all tests in exec_command.py are platform independent
(as it is the case with most distutils tools in general). So, be careful
when copying the tests to numpy/distutils/tests.

Pearu

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] tests in distutils/exec_command.py

[Zbyszek Szmek]

Hi,
while looking at test coverage statistics published Stéfan van der Walt
at http://mentat.za.net/numpy/coverage/, I noticed that the 
least-covered file, numpy/distutils/exec_command.py has it's own 
test routines, e.g.:
def test_svn(**kws):
s,o = exec_command(['svn','status'],**kws)
assert s,(s,o)
print 'svn ok'

called as 
if __name__ == "__main__":
   test_svn(use_tee=1)

The sense of this test seems reversed (svn status runs just fine):
Traceback (most recent call last):
  File "numpy/distutils/exec_command.py", line 591, in 
test_svn(use_tee=1)
  File "numpy/distutils/exec_command.py", line 567, in test_svn
assert s,(s,o)
AssertionError: (0, '')

Should the test be cleaned up and moved into a seperate file in 
numpy/distutils/tests/ ?

Regard,
Zbyszek

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Movement of ma breaks matplotlib

[Jarrod Millman]

On Fri, Apr 25, 2008 at 10:19 PM, Anne Archibald
<[EMAIL PROTECTED]> wrote:
>  In the upcoming release of numpy. numpy.core.ma ceases to exist. One
>  must use numpy.ma (for the new interface) or numpy.oldnumeric.ma (for
>  the old interface). This has the unfortunate effect of breaking
>  matplotlib(which does "from numpy.core.ma import *") - I cannot even
>  "import pylab" with a stock matplotlib (0.90.1) and an SVN numpy. Is
>  this an intended effect?

You need matplotlib 0.91.2 or later.  0.91.2 was released in January:
http://matplotlib.sourceforge.net/whats_new.html

Thanks,

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Gael Varoquaux]

On Sat, Apr 26, 2008 at 11:15:14AM -0400, Alan G Isaac wrote:
> On Sat, 26 Apr 2008, Gael Varoquaux apparently wrote:
> > I don't see where you get your universality. 

> Lists, tuples, arrays ...
> Where is the exception?
> Only matrices are the only 2d container I can
> think of that are broken this way.

List and Tuples are not 2D containers.

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Gael Varoquaux]

On Sat, Apr 26, 2008 at 11:13:12AM -0400, Alan G Isaac wrote:
> On Sat, 26 Apr 2008, Gael Varoquaux apparently wrote:
> > I claim b is more important than a. IMHO, a is plain 
> > wrong: you should't be indexing x with x[0][0]. 


> Why??

Because a 2D object is not a list of list. It is more than that. The
numpy array actually exposes this interface, but I think using it
systematicaly when it is not required is abuse. Moreover you are creating
temporary objects that are useless and harmful. They are harmful for
performance: you have to create useless objects and call their
__getitem__ functions. 

> Would you say this about a 2d array?

Of course. Even more. Suppose you have an nd array, with n=10, to index
object using 10 different indexing, ie A[a][b]... you have to create 9
intermediate objects that get indexed. This is ridiculous and potentially
very harmful for performance.

> The core argument has been that it is a **basic 
> expectation** of the behavior of 2d array-like objects that 
> you will be able to get, e.g., the first element with x[0][0].
> (E.g., lists, tuples, arrays ... is there an exception??

For me this is wrong. list and tuples are not 2D. Numpy arrays happen to
offer this feature, but you should not use it do to multiple dimension
indexing.


> I teach with matrices and I thought you might too: if so, 
> you surely have run into this expectation (which is **natural**).

Well, I don't find it that natural. I would naturally expect A[0][0] to
be invalid. I have not heavily run into that expectation. People around
me are used to indexing with several indexes. This probably comes from
their fortran/Mathematica/Maple/Matlab background. I can see that someone
coming from C would expect this multiple consecutive indexing. This is
because C has no notion of multiple dimension objects. The C model is
limited and not as powerful as modern array programming languages, let us
just move along.

> In fact I truly doubt anyone has not been puzzled on first 
> encounter by this::

> >>> x
> matrix([[1, 2],
> [3, 4]])
> >>> x[0]
> matrix([[1, 2]])
> >>> x[0][0]
> matrix([[1, 2]])

Well, actually, I can say that this behavior is surprising. When I teach
numpy and somebody encounters this behavior (which doesn't happen often,
because people use multiple dimension indexing), I have to point out that
x[0] is a 2D object also.

I sympathize with your crusade to fix this inconvenience. This is why I
support the RowVector/ColumnVector proposal. However your proposal breaks
what I consider as normal and important for something I consider should
be avoided.

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Alan G Isaac]

On Sat, 26 Apr 2008, Gael Varoquaux apparently wrote:
> We may desagree on what is Right, but the breaks backward 
> compatibility, and thus is a breakage and should be given 
> a lot of thought. 


I agree with this.  I am a matrix user, and I have given it 
a lot of thought.  I have been making this case for a *long* 
time.  It has come to a head because of the announced desire 
to severely constrain API changes moving forward.

As I am best able to understand you abstract view, the right 
thing to do would be for matrices to raise an error in 
response to a scalar index.  However, I deduce, you would 
just leave things alone to avoid backward incompatibility.

I weight the future more heavily.  We are approaching a last 
chance to do things better, and we should seize it.

The right questions looking forward:

- what behavior allows the most generic code?
- what behavior breaks fewest expectations?
- what behavior is most useful?

Cheers,
Alan Isaac

PS I cannot recall: do you use matrices?


___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Alan G Isaac]

On Sat, 26 Apr 2008, Gael Varoquaux apparently wrote:
> I don't see where you get your universality. 

Lists, tuples, arrays ...
Where is the exception?
Only matrices are the only 2d container I can
think of that are broken this way.

Cheers,
Alan Isaac



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Alan G Isaac]

On Sat, 26 Apr 2008, Gael Varoquaux apparently wrote:
> I claim b is more important than a. IMHO, a is plain 
> wrong: you should't be indexing x with x[0][0]. 


Why?? Would you say this about a 2d array?
Why the difference?

The core argument has been that it is a **basic 
expectation** of the behavior of 2d array-like objects that 
you will be able to get, e.g., the first element with x[0][0].
(E.g., lists, tuples, arrays ... is there an exception??
It should not be broken!)

I teach with matrices and I thought you might too: if so, 
you surely have run into this expectation (which is **natural**).
In fact I truly doubt anyone has not been puzzled on first 
encounter by this::

>>> x
matrix([[1, 2],
[3, 4]])
>>> x[0]
matrix([[1, 2]])
>>> x[0][0]
matrix([[1, 2]])

Another argument, which I agree with, has been that matrix 
behavior should match 2d array behavior except where there 
is a clear payoff from deviation.

What I do agree with, which I take to be implicit in your 
statement, is that if users of matrices should generally use 
multiple indexes.  But that does not answer the question 
about what we should offer when x[0] is requested.
(Or, more crucially, what you get when you iterate over
a matrix.)

Cheers,
Alan Isaac

PS If you have good arguments, please add them to
http://www.scipy.org/MatrixIndexing>



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] prerelease proposal for matrix behavior

[Alan G Isaac]

On Fri, 25 Apr 2008, "Travis E. Oliphant" apparently wrote:
> At this point, I'm leaning in the direction of the 
> RowVector / ColumnVector approach (even if these are not 
> really advertised and just used during indexing). 

I believe that this conflicts with submatrix extraction.
Details follow.

Suppose ``x`` is a matrix, and I say ``v=A[0]``.
What is ``v``?

1. If ``v`` is a 1d array, its behavior is known.
E.g., ``v[0]`` is the first element
and ``v[0,0]`` is an IndexError.
If we want to keep submatrix extraction (as we should),
we give up ``x[0] == x[0,:]``.

2. If ``v`` is a matrix, its behavior can be learned
by the experienced but breaks basic expectations
(the x[0][0] problem).

3. If ``v`` is a "RowVector" what behavior do we get?
Suppose the idea is that this will rescue
``x[0][0]==x[0,0]`` **and** ``x[0]=x[0,:]``.
But then we must give up that ``x[0,:]`` is a submatrix.
Must ``v`` deviate from submatrix behavior in an important way?
Yes:  ``v[0][0]`` is an IndexError.
(Note that the same problem arises if we just override
``__getitem__`` for the matrix class to special case
row and column matrices.)

Since submatrix extraction is fundamental, I think it is 
a *very* bad idea to give it up.  If so, then under the 
RowVector proposal we must give up ``x[0]==x[0,:]``.
But this is just what we give up with
the much simpler proposal that ``v`` be a 1d array.

Cheers,
Alan



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] prerelease proposal for matrix behavior

[Alan G Isaac]

On Sat, 26 Apr 2008, Bill Baxter apparently wrote:
> Any change to the behavior of x[0] for matrices is going to break a lot of 
> code. 

OK, how about a warning then?
E.g., see attached patch.

Cheers,
Alan

--- defmatrix.old   Sat Apr 26 09:34:11 2008
+++ defmatrix.pySat Apr 26 09:37:13 2008
@@ -1,6 +1,7 @@
 __all__ = ['matrix', 'bmat', 'mat', 'asmatrix']
 
 import sys
+import warnings
 import numeric as N
 from numeric import concatenate, isscalar, binary_repr
 
@@ -119,6 +120,9 @@
 return
 
 def __getitem__(self, index):
+if isscalar(index):
+warnings.warn("scalar indexing of matrices is deprecated, use 
x[i,:] instead",
+ DeprecationWarning, stacklevel=2)
 self._getitem = True
 try:
 out = N.ndarray.__getitem__(self, index)
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] access ndarray in C++

[Gael Varoquaux]

On Wed, Apr 23, 2008 at 09:47:46PM -0400, Andreas Klöckner wrote:
> > Any numpy-specific stuff for sip?

> Not as far as I'm aware. In fact, I don't know of any uses of sip outside of 
> Qt/KDE-related things.

Airbus uses it for heavy numerical work. They claim they have benchmarked
all the tools and SIP was the fastest. 
If you want more information on that, you should contact the sip
developer, Phil Thompson, he does some contracting job for Airbus.

Cheers,

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Threading question for Travis

[Charles R Harris]

Travis,

Is this correct?

NPY_LOOP_BEGIN_THREADS;
switch(loop->meth) {
case ONE_UFUNCLOOP:
/*
 * Everything is contiguous, notswapped, aligned,
 * and of the right type.  -- Fastest.
 * Or if not contiguous, then a single-stride
 * increment moves through the entire array.
 */
/*fprintf(stderr, "ONE...%d\n", loop->size);*/
loop->function((char **)loop->bufptr, &(loop->size),
loop->steps, loop->funcdata);
UFUNC_CHECK_ERROR(loop);
break;

Note that UFUNC_CHECK_ERROR calls PyErr_Occurred. That doesn't seem thread
safe to me. Or maybe there is something special about that function I'm
missing.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Gael Varoquaux]

On Fri, Apr 25, 2008 at 01:40:29PM -0400, Alan G Isaac wrote:
> On Fri, 25 Apr 2008, Stéfan van der Walt wrote:
> > workaround would break x[0] == x[0,:] 


> But there is not universal agreement that x[0] == x[0,:] is 
> desirable.  In contrast, there *is* universal agreement that
> x[0][0]==x[0,0] is desirable.  Or so I've understood the 
> discussion.

I DON'T AGREE! Sorry for yelling, but I don't see where you get your
universality. You want to break backward incompatibility to accomodated
wrongful indexing, and break rightful indexing. 

I don't know why people are indexing matrices with A[x][y], but they
shouldn't. We have multidimensional objects, and a lot of effort has been
put in that. Indexing with one dimension only is poor amongst other
things for performance reasons. We also see that it breaks indexing
semantics and fobrid doing clever indexing. That cannot be worked around,
because by indexing with one dimension you are putting less information
into the indexing routine than by indexing with two dimension.

> Thus I do not see  x[0] != x[0,:] as breakage:
> it is desirable. 

You may think what you want. We may desagree on what is Right, but the
breaks backward compatibility, and thus is a breakage and should be given
a lot of thought.

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] untenable matrix behavior in SVN

[Gael Varoquaux]

On Fri, Apr 25, 2008 at 01:04:53PM -0400, Alan G Isaac wrote:
> On Fri, 25 Apr 2008, Stéfan van der Walt apparently wrote:
> > The agreement was:
> > a) That x[0][0] should be equal to x[0,0] and 
> > b) That x[0,:] should be equal to x[0] (as for ndarrays)

> 1. This is **not** what I understood as the agreement
> (and I think the current solution is bad).
> I certainly did not mean to support the change that
> as implemented, and it is not clear to me that others
> did either.

> 2. These two goals are substantially in conflict for 
> matrices, as we are seeing.

> 3. The important goal, (goal a., which everyone agrees on),
> has NOT been accomplished by the current change:
> x[0][0] raises a TypeError when x is a 1 by N matrix.

I claim b is more important than a. IMHO, a is plain wrong: you should't
be indexing x with x[0][0]. I am OK making a work, as long as it doesn't
break b. In addition breaking be is backward incompatible changes for no
good reason (replacing one missfeature with another).

I would like this issue addressed in next release, not this one. I have
the feeling the discussion is not sane enough, right now.

Cheers,

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] 2D array to 3D

[Robert Kern]

2008/4/25 tournesol <[EMAIL PROTECTED]>:
> Hi All.
>
>  Is there a easy way to insert 1D(j) array into another 2D array(B:jxk)
>  and conver B to B:ixjxk ?
>
>  ex:)
>
>  >>> from numpy import *
>  >>> a=arange(4)
>  >>> a
>  array([0, 1, 2, 3])
>  >>> b=arange(9)
>  >>> b.shape=3,3
>  >>> b
>  array([[0, 1, 2],
>  [3, 4, 5],
>  [6, 7, 8]])
>
>  I just wanna insert A into B
>  B:1x3x3,
>
>  [[[ 0, 1, 2, 3],
>  [ 4, 5, 6, 7],
>  [ 8, 9, 10, 11]]
>
>
>  B:2x3x3,
>
>  [[[ 0, 1, 2, 3],
>  [ 4, 5, 6, 7],
>  [ 8, 9, 10, 11]]
>
>  [[ 0, 1, 2, 3],
>  [ 4, 5, 6, 7],
>  [ 8, 9, 10, 11]]]
>
>  B:3x3x3,
>  [[[ 0, 1, 2, 3],
>  [ 4, 5, 6, 7],
>  [ 8, 9, 10, 11]]
>
>  [[ 0, 1, 2, 3],
>  [ 4, 5, 6, 7],
>  [ 8, 9, 10, 11]]
>
>  [[ 0, 1, 2, 3],
>  [ 4, 5, 6, 7],
>  [ 8, 9, 10, 11]]]

I'm sorry, but I cannot understand what you are asking for.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
 -- Umberto Eco
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion