numpy-discussion — Discussion list for all users of Numerical Python

Re: [Numpy-discussion] Should dot return 1x1 matrix as scalar?

[Paulo J. S. S. <pjs...@im...>]

I am sorry, but I don't agree with you.

The matrix class seems to be there to help people with numerical linear
algebra algorithms "a la matlab". Is this an incorrect assumption? 
The behavior I am asking can be restricted to the matrix class objects
only. However as dot already makes a scalar out the multiplication of
two rank-1 arrays (in which case it computes the inner product), I
thought that this behavior could be extended to matrix objects. Another
possibility (without touching dot) would be to change the functions
__mul__, __rmul__, and  __imul__ in the matrix class to deal with 1x1
matrices as scalars. That would be OK to me too.

The current behavior is odd when writing numerical algorithms. Take a
look at these two examples:

1) Computing the norm:

The natural way:

def norm(x): return sqrt(x.T*x)

But in this case you can't write norm(v)*v!

Then, you have then to define norm as

def norm(x): return sqrt(x.T*x).item()

2) The conjugate gradient iteration:

alpha = (r.T*r) / (p.T*A*p)
x += alpha*p
rold = rnew
r += alpha*(A*p)
beta = (r.T*r) / (rold.T*rold)
p = -r + beta*p

This returns an error on second, forth, and the last equation! In all
these cases, you'll need a call to the "item" method.

Finally, the example you gave 

(x*x.T)*(x.T*x)

does not make sense as matrix multiplication formula unless you
interpret the first part as a scalar. You seem to be happy that the
compiler got "the mistake". But in any Mathematics book the formula
above would be considered OK as the first part would be interpreted as
an inner product (and the second an outer product). In my opinion, it is
not a mistake in a linear algebra setting.

My 2 cents,

Paulo

-- 
Paulo José da Silva e Silva 
Professor Assistente do Dep. de Ciência da Computação
(Assistant Professor of the Computer Science Dept.)
Universidade de São Paulo - Brazil

e-mail: rs...@im...           Web: http://www.ime.usp.br/~rsilva

Teoria é o que não entendemos o     (Theory is something we don't)
suficiente para chamar de prática.  (understand well enough to call
practice)

[Numpy-discussion] numpy revision 1894 fails to build on Solaris

[Christopher H. <ch...@st...>]

Hi Travis,

Numpy failed to build in this morning's regression test.  A cursory look 
seems to indicate that the build failure is related to the umathmodule 
changes.  I'm looking into this now.  I've included the build log in 
case you can recognize the problem right away.

Chris

Re: [Numpy-discussion] Should dot return 1x1 matrix as scalar?

[Alan G I. <ai...@am...>]

On Fri, 13 Jan 2006, "Paulo J. S. Silva" apparently wrote: 
> I was playing with the matrix type in numpy and I felt the "need" to 
> have the "dot" function returning a 1x1 matrix as a scalar. 

Since a 1x1 matrix is not a scalar,
the current behavior is desirable, IMO.
Specifically, I want an error in the last
example below, since otherwise matrix multiplication
will not be associative.
Cheers,
Alan Isaac


PS Current behavior:
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as N
>>> x = N.mat(range(10))
>>> x
matrix([[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]])
>>> x*x.T
matrix([[285]])
>>> 285*x
matrix([[   0,  285,  570,  855, 1140, 1425, 1710, 1995, 2280, 2565]])
>>> (x*x.T)*(x.T*x)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Python24\Lib\site-packages\numpy\core\defmatrix.py", line 128, in __m
ul__
    return N.dot(self, other)
ValueError: objects are not aligned

[Numpy-discussion] Should dot return 1x1 matrix as scalar?

[Paulo J. S. S. <pjs...@im...>]

Hello,

I was playing with the matrix type in numpy and I felt the "need" to
have the "dot" function returning a 1x1 matrix as a scalar. This would
allow for expressions like:

x = matrix(arange(10.))
versorX  = x / sqrt(x.T*x)

Right now, I have to write:

versorX = x / sqrt(x.T*x).item()

Actually, a.T*b can not always be used as the inner product with the
current behavior.

Note that dot already returns scalars when we multiply rank-1 arrays,
but matrices are always rank-2.

Best,

Paulo

Re: [Numpy-discussion] Numpy and the old scipy

[Travis O. <oli...@ie...>]

Andrea Riciputi wrote:

>
> Since I use both Numeric and SciPy (the old one) on a daily basis for  
> my job, I'd like to know if it's still the case, or if it is now  
> possible to install the new numpy package side by side with the old  
> scipy (and Numeric as well).


You can install NumPy and Numeric side-by-side just fine.  They use 
different name spaces.

In order to install new and old scipy you will definitely need to 
install one of them to another location besides site-packages (probably 
new scipy). 

Then you will need to make sure your sys.path is set up properly to find 
the scipy you are interested in using for that session.    In principle 
new scipy is almost identical to old scipy except internally it uses 
NumPy instead of Numeric.

So, once you convert from Numeric to NumPy, converting to the new scipy 
is done (it depends on if you regularly imported scipy_base or  
scipy_distutils.  If you did those are gone.  scipy_base--->numpy  and 
scipy_distutils--->scipy.distutils.

Keep us posted as to the difficulties as they arise...

-Travis

[Numpy-discussion] Numpy and the old scipy

[Andrea R. <ari...@pi...>]

Hi all,
I'm a long time Numeric and SciPy user and I've been following with  
interest the development of the new Numpy package since last year  
when Travis started rewriting Numeric (thanks a lot Travis!).

Now that Numpy seems in a quite-ready state I'd like to give it a try  
(and hopefully help the developer in the bug fixing cycle). However I  
remember that in its early days (when it was still named scipy_core)  
it was not possible to install both the old scipy version (I mean  
version 0.3.2) and the new one.

Since I use both Numeric and SciPy (the old one) on a daily basis for  
my job, I'd like to know if it's still the case, or if it is now  
possible to install the new numpy package side by side with the old  
scipy (and Numeric as well).

Thanks,
  Andrea.

[Numpy-discussion] Overlapping websites?

[Colin J. W. <cj...@sy...>]

There are now:
   http://www.numpy.org and
   http://sourceforge.net/projects/numpy/

These seem to be synonyms.  Are two URI's needed?

Numeric 24, not that I use it, seems to have been lost.

Colin W.
  

Re: [Numpy-discussion] Who will use numpy.ma?

[Travis O. <oli...@ie...>]

Joris De Ridder wrote:

>>>>y = array([1, nan, 0.47])
>>>>sort(y)
>>>>        
>>>>
>array([ 1.        ,         nan,  0.47      ])
>
>No exception, no sorting. Is this a feature or a bug? :)
>  
>
It's a "problem" that the user needs to be aware of, but I'm not sure 
how to fix.

Notice that the same problem exists with python
try:

b =y.tolist()
b.sort()

Same effect.

The problem may be that nans are always False on comparison with another 
object and this ends up confusing the sort functions. 

To fix it we would have to write a special nan-sort or else remove the 
nans entirely, but I don't think we should check for nans for every sort 
of floating-point values, because it would be slower.  So, the user 
needs to do that.

-Travis

Re: [Numpy-discussion] Who will use numpy.ma?

[Sasha <nd...@ma...>]

With Paul's permission I am posting his arguments and my responses.
Numpy.ma will follow Paul's design and there is now a wiki page
dedicated to the effort to make ma work better in numpy. (See
http://projects.scipy.org/scipy/numpy/wiki/MaskedArray).

-- sasha

On 1/12/06, Sasha <nd...@ma...> wrote:
> Paul,
>
> Thank you very much for your insights and once again thanks for all
> the great work that you've done.  I've noticed that your reply was not
> posted on any list, do you mind if I forward it to numpy-user?  Please
> see more below.
>
> On 1/12/06, Paul F. Dubois <pa...@pf...> wrote:
> > What special values? Are you sure this works on any platform? What, for
> > example, is the special value for integer arrays? For arrays of objects=
?
> >
> Yes, these are hard questions.  For floats nan is an obvious choice and
> IEEE support is getting better on the new hardware. For objects None is
> a fine choice.  For integers some may argue for sys.maxint, and given tha=
t
> numpy integer arithmetics is already handling overflow a check for maxint=
 will
> not add much complexity. Yet don't get me wrong: I don't see any replacem=
ent
> for ma myself.
>
> > How do replaceable mathematical operations make any difference? The
> > fundamental problem is that if array x has special values in some place=
s
> > and array y has them in some other places, how do you create a result
> > that has special values in the correct places AND is of a type for whic=
h
> > those special values are still treated as 'missing'. How do you do this=
?
> >
>
> Replaceable operations would allow one to redefine all operations on inte=
ger
> arrays to treat say sys.maxint as invariant and cast it to nan in floatin=
g point
> conversions without changing the logic of main line numpy.
>
> > I converted MA to ma but did not have time to flesh out all the
> > differences with the new ndarray. I was hoping the community would do
> > that.
>
> Me too.  That's was the point of my post - to find out the size of the co=
munity
> rather than to suggest an alternative.
>
> > I am retired.
> >
> You deserve it.
>
> > It is my belief that the approach you outline is not workable, but
> > perhaps I am not understanding it properly.
> >
> I don't have any workable approach other than enchancing ma to work
> better with numpy.  This is what I am doing right now.
>
> > If I, who have thought about this a lot, do not know for sure, what
> > information can you derive from a poll of the general public, who will
> > not think through these issues very carefully?
> >
> I was trying to poll numpy community to find out how many people actually
> use ma in real projects.  This would determine how well tested the new fe=
atures
> will be and how quickly any bugs will be discovered and fixed.
> Unfortunately, I have
> not seen a single response saying - I've been using MA for X years on
> Y projects and
> plan on using it as we upgrade to numpy.  There was a lot of
> theoretical discussions
> and a pointer to a plotting library that has recently added MA
> support, but no testimony
> from end users.
>
> > I am close to absolutely positive that subclassing won't particularly
> > ease the task.
> >
> I thought about this a little, and I think you are right. Subclassing
> may improve speed a little, but all methods will need to be adapted
> the same ways as it is done without subclassing.
>
> > For the reason I indicated, I don't care to engage in public discussion=
s
> > of complex technical issues so I have not cc'd this to the group.
> >
> I respect that, but please allow me to forward at least portions of
> this correspondence
> to the community. Your insights are invaluable.
>
> -- sasha
>
> >
> > Sasha wrote:
> > > MA is intended to be a drop-in replacement for Numeric arrays that ca=
n
> > > explicitely handle missing observations.  With the recent improvement=
s
> > > to the array object in NumPy, the MA library has fallen behind.  Ther=
e
> > > are more than 50 methods in the ndarray object that are not present i=
n
> > > ma.array.
> > >
> > > I would like to hear from people who work with datasets with missing
> > > observations? Do you use MA? Do you think with the support for nan's
> > > and replaceable mathematical operations, should missing observations
> > > be handled in numpy using special values rather than an array of
> > > masks?
> > >
> > > Thanks.
> > >
> > > -- sasha
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: Splunk Inc. Do you grep through lo=
g files
> > > for problems?  Stop!  Download the new AJAX search engine that makes
> > > searching your log files as easy as surfing the  web.  DOWNLOAD SPLUN=
K!
> > > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick
> > > _______________________________________________
> > > Numpy-discussion mailing list
> > > Num...@li...
> > > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> > >
> >
>

[Numpy-discussion] Re: [Numpy-user] Optional shape in array description

[Travis O. <oli...@ie...>]

Francesc Altet wrote:

>Hi,
>
>I went over a weirdness on interpretation of the optional shape in the
>descriptor of types when declaring records.
>
>In [176]: numpy.zeros((2,), dtype=[('c1', 'f4')])
>Out[176]: array([(0.0,), (0.0,)], dtype=(void,4))
>
>So far, so good. However:
>
>In [177]: numpy.zeros((2,), dtype=[('c1', 'f4', 1)])
>Out[177]: array([(array([ 0.], dtype=float32),), (array([ 0.], 
>dtype=float32),)], dtype=(void,4))
>
>And:
>
>In [178]: numpy.zeros((2,), dtype=[('c1', 'f4', (1,))])
>Out[178]: array([(array([ 0.], dtype=float32),), (array([ 0.], 
>dtype=float32),)], dtype=(void,4))
>
>i.e. the very same value is obtained specifying shape=1 and shape=(1,).
>
>OTOH, in the point 3 of the description of the __array_descr__ of the
>array protocol (http://numeric.scipy.org/array_interface.html), one
>can read:
>
>"""
>An optional shape tuple providing how many times this part of the
>record should be repeated.  Assumed (1,) if not given.
>"""
>
>But this is clearly not what it is implemented.
>
>IMO, the correct thing (and what the numarray does) would be:
>
>In [176]: numpy.zeros((2,), dtype=[('c1', 'f4')])
>Out[176]: array([(0.0,), (0.0,)], dtype=(void,4))
>In [192]: numpy.zeros((2,), dtype=[('c1', 'f4')])[0][0]
>Out[192]: 0.0
>
>In [177]: numpy.zeros((2,), dtype=[('c1', 'f4', 1)])
>Out[177]: array([(0.0,), (0.0,)], dtype=(void,4))
>In [193]: numpy.zeros((2,), dtype=[('c1', 'f4', 1)])[0][0]
>Out[193]: 0.0
>
>In [178]: numpy.zeros((2,), dtype=[('c1', 'f4', (1,))])
>Out[178]: array([(array([ 0.], dtype=float32),), (array([ 0.], 
>dtype=float32),)], dtype=(void,4))
>In [194]: numpy.zeros((2,), dtype=[('c1', 'f4', (1,))])[0][0]
>Out[194]: array([ 0.], dtype=float32)
>
>i.e. that shape=1 would be equivalent to don't specify it (scalar
>case), and shape=(1,) would be equivalent to declare the field as
>unidimensional but with one element.
>  
>
This is what is now done in SVN...

Thanks for catching the corner case.  We should also change the verbage 
on the array_protocol page.

-Travis

Re: [Numpy-discussion] Re: [SciPy-user] [SciPy-dev] Long live to numpy (and its list as well)

[Travis O. <oli...@ie...>]

kon...@la... wrote:

> Separate lists will encourage a  split in the community, and create 
> lots of crosspostings.


This convinced me...

I closed the numpy-user list (already closed the numpy-devel list).

Please make all numpy-related posts to

num...@li...

It would help if users would make clear in the subject if they are not 
posting regarding current NumPy, but that their post is specific to 
Numarray and/or Numeric.

-Travis

Re: [Numpy-discussion] Long live to numpy (and its list as well)

[David M. C. <co...@ph...>]

On Jan 12, 2006, at 12:55 , Andrew Straw wrote:

> kon...@la... wrote:
>
>> On 12.01.2006, at 18:13, Sebastian Haase wrote:
>>
>>> Obviously there are going to be lots of posts regarding "transition
>>> from
>>> Numeric/numarray to NumPy" -- are they all supposed to cross post !?
>>>
>>> My vote (and that's how I read Konrad's - correct my if I'm wrong)
>>> is to
>>> continue using numpy-discussion and NOT have another lists (numpy-
>>> user) .
>>
>>
>> I agree. It makes sense to have a separate developer list for those
>> who work *on* NumPy, but please let's stick to a single list for
>> users of all Python array packages. Separate lists will encourage a
>> split in the community, and create lots of crosspostings.
>
> I agree as well. In the last days, there have been several posts by
> authors who clearly missed ongoing discussions following from an
> original cross-post because further discussion took place  
> exclusively on
> an unsubscribed list. Can we shut down numpy-user? It's only been  
> around
> a couple weeks, and I bet everyone subscribed there is also on
> numpy-discussion.

I'd have to agree too. For one thing, the names are too similar: what  
really is the difference between -discussion and -user? numpy- 
discussion has a long history: this includes archives on  
sourceforge.net, gmane.org, and elsewhere, which gives a one-stop  
shop for searching archives, instead of having to remember to look up  
(or forgetting to look up) in several lists. It's also better for  
newcomers to only have one obvious list to post to.

At the moment, I'd also say numpy is still closely linked with scipy  
in terms of developers, so a separate numpy-dev list would be premature.

-- 
|>|\/|<
/------------------------------------------------------------------\
|David M. Cooke              http://arbutus.physics.mcmaster.ca/dmc/
|co...@ph...

Re: Re[2]: [Numpy-discussion] Two bugs in numpy 0.9.2 and a suggestion.

[Paulo J. S. S. <pjs...@im...>]

Thank Alan and David for calling my attention back to the matrix object
in numpy/numarray.

I usually avoided using it because my first contact comes from Numeric
where the Matrix objects don't play nicely with ufunctions:

In [1]:from Numeric import *
In [2]:from Matrix import Matrix
In [3]:a = Matrix([1.,2,3])
In [4]:sin(a)
Out[4]:array([       [ 0.84147098,  0.90929743,  0.14112001]])

See... The sine of a Matrix was not a Matrix anymore. I didn't realize
this was fixed in numarray:

In [1]:from numarray import *
In [2]:from numarray.matrix import Matrix
In [3]:a = Matrix([1.,2,3])
In [4]:sin(a)
Out[4]:_Matrix([ 0.84147098,  0.90929743,  0.14112001])

And numpy keeps the nice behavior:

In [1]:from numpy import *
In [2]:a = matrix([1.,2,3])
In [3]:sin(a)
Out[3]:matrix([[ 0.84147098,  0.90929743,  0.14112001]])

Great! 

Best,

Paulo

Re: [Numpy-discussion] Re: [SciPy-user] [SciPy-dev] Long live to numpy (and its list as well)

[Fernando P. <Fer...@co...>]

Christopher Barker wrote:
> Sebastian Haase wrote:
> 
>>now  we have two more !
> 
> 
> I think it's only one: numpy-dev got dropped.
> 
> 
>>Obviously there are going to be lots of posts regarding "transition from 
>>Numeric/numarray to NumPy" -- are they all supposed to cross post !?
> 
> 
> No, they should post to numpy-user. If it's about numpy, post there. 
> Period. If it's about Numeric or numarray, and NOT numpy, then post to 
> the old list. As I imagine there are a lot of folks that are not 
> interested in the latest developments, and are "just using" one of the 
> older packages, then the old list has a valuable place.

I don't really have an opinion on this matter, and have run out of mental 
bandwith to follow it.  But I'd like to ask that, when the dust settles, could 
the powers-that-be please put up a clear notice on the new wiki as to what the 
lists are, and the purpose of each, with links to the relevant subscription pages?

Cheers,

f

Re: [Numpy-discussion] Re: [SciPy-user] [SciPy-dev] Long live to numpy (and its list as well)

[Christopher B. <Chr...@no...>]

Sebastian Haase wrote:
> now  we have two more !

I think it's only one: numpy-dev got dropped.

> Obviously there are going to be lots of posts regarding "transition from 
> Numeric/numarray to NumPy" -- are they all supposed to cross post !?

No, they should post to numpy-user. If it's about numpy, post there. 
Period. If it's about Numeric or numarray, and NOT numpy, then post to 
the old list. As I imagine there are a lot of folks that are not 
interested in the latest developments, and are "just using" one of the 
older packages, then the old list has a valuable place.

Personally, I filter them both to the same place, so it makes little 
difference to me, though all that cross-posting gets annoying.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [Numpy-discussion] Re: [SciPy-user] [SciPy-dev] Long live to numpy (and its list as well)

[Andrew S. <str...@as...>]

kon...@la... wrote:

> On 12.01.2006, at 18:13, Sebastian Haase wrote:
>
>> Obviously there are going to be lots of posts regarding "transition 
>> from
>> Numeric/numarray to NumPy" -- are they all supposed to cross post !?
>>
>> My vote (and that's how I read Konrad's - correct my if I'm wrong) 
>> is to
>> continue using numpy-discussion and NOT have another lists (numpy-
>> user) .
>
>
> I agree. It makes sense to have a separate developer list for those 
> who work *on* NumPy, but please let's stick to a single list for 
> users of all Python array packages. Separate lists will encourage a 
> split in the community, and create lots of crosspostings.

I agree as well. In the last days, there have been several posts by
authors who clearly missed ongoing discussions following from an
original cross-post because further discussion took place exclusively on
an unsubscribed list. Can we shut down numpy-user? It's only been around
a couple weeks, and I bet everyone subscribed there is also on
numpy-discussion.

Cheers!
Andrew

Re: [Numpy-discussion] Two bugs in numpy 0.9.2 and a suggestion.

[Colin J. W. <cj...@sy...>]

Alan G Isaac wrote:

>Paulo wrote:
>  
>
>>>Now the suggestion. What about adding a "transpose" property (in the 
>>>Python parlance) to ndarray objects? I would call it "t". 
>>>      
>>>
>
>
>On Thu, 12 Jan 2006, "Colin J. Williams" apparently wrote: 
>  
>
>>Or "T" to distinguish properties, 
>>    
>>
>
>You mean like this?  Or something else?
>Alan Isaac
>
>  
>
>>>>import numpy as N
>>>>x = N.mat([[1,2,3],[4,5,6]])
>>>>y = x.T
>>>>y
>>>>        
>>>>
>matrix([[1, 4],
>       [2, 5],
>       [3, 6]])
>
>
>  
>
Thanks.  Yes, exactly.

Colin W.

>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
>_______________________________________________
>Numpy-discussion mailing list
>Num...@li...
>https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
>  
>

Re: [Numpy-discussion] Re: [SciPy-user] [SciPy-dev] Long live to numpy (and its list as well)

[<kon...@la...>]

On 12.01.2006, at 18:13, Sebastian Haase wrote:

> Obviously there are going to be lots of posts regarding "transition  
> from
> Numeric/numarray to NumPy" -- are they all supposed to cross post !?
>
> My vote (and that's how I read Konrad's - correct my if I'm wrong)  
> is to
> continue using numpy-discussion and NOT have another lists (numpy- 
> user) .

I agree. It makes sense to have a separate developer list for those  
who work *on* NumPy, but please let's stick to a single list for  
users of all Python array packages. Separate lists will encourage a  
split in the community, and create lots of crosspostings.

Konrad.
--
------------------------------------------------------------------------ 
-------
Konrad Hinsen
Laboratoire Leon Brillouin (CEA-CNRS), CEA Saclay,
91191 Gif-sur-Yvette Cedex, France
Tel.: +33-1 69 08 79 25
Fax: +33-1 69 08 82 61
E-Mail: kh...@ce...
------------------------------------------------------------------------ 
-------

Re: [Numpy-discussion] Re: [SciPy-user] [SciPy-dev] Long live to numpy (and its list as well)

[Sebastian H. <ha...@ms...>]

On Thursday 12 January 2006 03:21, Francesc Altet wrote:
> A Dijous 12 Gener 2006 11:52, kon...@la... va escriure:
> > On 05.01.2006, at 23:03, Francesc Altet wrote:
> > > Accordingly, my vote is also:
> > >
> > > +1 numpy-discussion
> >
> > +1 from me as well. Same reason.
>
> The outcome of the discussion is that it has been created a new list
> called num...@li... for discussing the new NumPy package.
> Apparently, the numpy-discussion will still be the place for
> discussing Numeric/numarray issues.
>
I'm sorry to disagree,
I really think there are to many lists now ! The start of this "lists 
discussion" was about _reducing_ the total number of scipy/numpy lists, now 
we have two more !
Obviously there are going to be lots of posts regarding "transition from 
Numeric/numarray to NumPy" -- are they all supposed to cross post !?

My vote (and that's how I read Konrad's - correct my if I'm wrong) is to 
continue using numpy-discussion and NOT have another lists (numpy-user) .

My two cents,
Sebastian Haase

Re[2]: [Numpy-discussion] Two bugs in numpy 0.9.2 and a suggestion.

[Alan G I. <ai...@am...>]

Paulo wrote:
>> Now the suggestion. What about adding a "transpose" property (in the=20
>> Python parlance) to ndarray objects? I would call it "t".=20


On Thu, 12 Jan 2006, "Colin J. Williams" apparently wrote:=20
> Or "T" to distinguish properties,=20

You mean like this?  Or something else?
Alan Isaac

>>> import numpy as N
>>> x =3D N.mat([[1,2,3],[4,5,6]])
>>> y =3D x.T
>>> y
matrix([[1, 4],
       [2, 5],
       [3, 6]])

Re: [Numpy-discussion] Two bugs in numpy 0.9.2 and a suggestion.

[Tim H. <tim...@co...>]

Paulo J. S. Silva wrote:

[SNIP]

>Now the suggestion. What about adding a "transpose" property (in the
>Python parlance) to ndarray objects? I would call it "t". The following
>Python code explains what I mean:
>
>from numpy import *
>class Myndarray(ndarray):
>    t = property(transpose, None, None)
>
>If you add this 3 lines to a file, import the Myndarray class, and
>create one of such arrays you will get transpose(a) by simply typing
>a.t. This allow for the following type of code (which I prefer):
>
>cost = dot(c.t, x)
>
>instead of 
>
>cost = dot(transpose(c), x)
>
>or 
>
>cost = dot(c.transpose(), x)
>
>Such a compact notation can be a blessing in code that needs lots of
>transpose (like the BFGS formula for example).
>
>If I knew more about writing C extensions for Python I would try to do
>it myself, but I don't. Is it possible to define properties in a C
>extension?
>  
>
Wouldn't this be more appropriate in Matrix (I'm assuming numpy has an 
equivalent to Numeric/Numarray's Matrix class)? For general N-D arrays I 
rarely find transpose without axes arguments to be useful, so for me 
this would would just amount to extra cruft.


-tim



>Best,
>
>Paulo
>  
>

Re: [Numpy-discussion] Two bugs in numpy 0.9.2 and a suggestion.

[Colin J. W. <cj...@sy...>]

Paulo J. S. Silva wrote:

>Hello,
>
>I have just installed numpy 0.9.2 in my system. Thanks for the good
>work. I think I got two bugs:
>
>1) In the numpy.linalg method the cholesky decomposition doesn't work
>because the function triu is not available from numpy.core. If you add a
>line "from numpy import triu" on the top of the linalg.py file (with the
>other imports), it starts working.
>
>2) If you try to instantiate a ndarray with weird parameters it can
>segfault and abort the interpreter. For example try to do the following:
>
>a = arange(10.)
>b = ndarray(a)
>
>Now the suggestion. What about adding a "transpose" property (in the
>Python parlance) to ndarray objects? I would call it "t". 
>
Or "T" to distinguish properties, which require no parentheses, from 
methods, whch do require parentheses?

Colin W.

Re: [Numpy-discussion] Who will use numpy.ma?

[Bruce S. <bso...@gm...>]

Hi,
For any data collection in the real world, actual missing values occur very
frequently - almost a certainity. For various operations there is probably
no difference in what is really used, the main thing that comes to mind is
the ability to separate those values that are actually missing i.e.
unobserved from those that are obtained from mathematical functions like
division by zero. However, it has been some time since I looked at the
options so I am out-of-date. Perhaps the approach of the R language (
http://wwwr-project.org) may provide suitable approach to this.

A second aspect of the masked arrays that is very neat is to be able to
choose a masking value and it can be changed. This is a really feature that
you don't realize how great it really is unless you have it! . It is very
easy to identify and work with elements of the array that meet changing
criteria just by changing the mask rather than a series of complex boolean
operations and steps to get the same results.

Regards
Bruce


On 1/11/06, Sasha <nd...@ma...> wrote:
>
> MA is intended to be a drop-in replacement for Numeric arrays that can
> explicitely handle missing observations.  With the recent improvements
> to the array object in NumPy, the MA library has fallen behind.  There
> are more than 50 methods in the ndarray object that are not present in
> ma.array.
>
> I would like to hear from people who work with datasets with missing
> observations? Do you use MA? Do you think with the support for nan's
> and replaceable mathematical operations, should missing observations
> be handled in numpy using special values rather than an array of
> masks?
>
> Thanks.
>
> -- sasha
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id=16865&opclick
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

Re: [Numpy-discussion] Who will use numpy.ma?

[Joris De R. <jo...@st...>]

> With the recent improvements to the array object in NumPy, 
> the MA library has fallen behind.  There are more than 50 methods 
> in the ndarray object that are not present in ma.array.

I guess maintaining MA means double work, doesn't it? So, even if
MA is updated now, in the future it's likely to be always somewhat behind.
This is perhaps an argument against the use of this library? I wouldn't
like to extensively use a library that will be phased out in a couple of 
years because it turns out to be somewhat redundant and/or behind
w.r.t. the rest of numpy.

The fact that with numpy you can do things like

>>> from numpy import *
>>> x = sin(1./arange(3.))              # arbitrary example
>>> x[1] = nan                             # 'masking' an element
>>> x = where(isnan(x), 10., x)      # replacing masks by a number
>>> x = where(x >= 10, nan, x)      # clipping with nan replacement
>>> y = sin(x)                               # sin(nan) = nan

fulfils most of my needs. However, I haven't compared execution times 
for large arrays. Note that using NaNs, we don't distinguish between NaN
and NA (not available). I am not sure this won't bite us somewhere in
the future.

I have a related question. numpy introduces the functions nanargmax(), 
nanargmin(), nanmax(), nanmin(), and nansum(). Was there a special 
reason to introduce extra nan... functions rather than adding an option
like ignore_nan = True to the normal functions? Is this a performance 
issue? Will similar nan... equivalents be introduced for the functions
mean() and reduce()?
 
A side remark: 

>>> y = array([1, nan, 0.47])
>>> sort(y)
array([ 1.        ,         nan,  0.47      ])

No exception, no sorting. Is this a feature or a bug? :)

J.

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

[Numpy-discussion] Two bugs in numpy 0.9.2 and a suggestion.

[Paulo J. S. S. <pjs...@im...>]

Hello,

I have just installed numpy 0.9.2 in my system. Thanks for the good
work. I think I got two bugs:

1) In the numpy.linalg method the cholesky decomposition doesn't work
because the function triu is not available from numpy.core. If you add a
line "from numpy import triu" on the top of the linalg.py file (with the
other imports), it starts working.

2) If you try to instantiate a ndarray with weird parameters it can
segfault and abort the interpreter. For example try to do the following:

a = arange(10.)
b = ndarray(a)

Now the suggestion. What about adding a "transpose" property (in the
Python parlance) to ndarray objects? I would call it "t". The following
Python code explains what I mean:

from numpy import *
class Myndarray(ndarray):
    t = property(transpose, None, None)

If you add this 3 lines to a file, import the Myndarray class, and
create one of such arrays you will get transpose(a) by simply typing
a.t. This allow for the following type of code (which I prefer):

cost = dot(c.t, x)

instead of 

cost = dot(transpose(c), x)

or 

cost = dot(c.transpose(), x)

Such a compact notation can be a blessing in code that needs lots of
transpose (like the BFGS formula for example).

If I knew more about writing C extensions for Python I would try to do
it myself, but I don't. Is it possible to define properties in a C
extension?

Best,

Paulo
-- 
Paulo José da Silva e Silva 
Professor Assistente do Dep. de Ciência da Computação
(Assistant Professor of the Computer Science Dept.)
Universidade de São Paulo - Brazil

e-mail: rs...@im...           Web: http://www.ime.usp.br/~rsilva

Teoria é o que não entendemos o     (Theory is something we don't)
suficiente para chamar de prática.  (understand well enough to call
practice)