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

Re: [Numpy-discussion] Building on Windows

[Stephan T. <st...@si...>]

> So, go ahead and let us know what problems you are having.   You are 
> correct that my main build platform is not Windows, but I think several 
> other people do use Windows regularly and we definitely want to support it.

I attached a patch to ticket #114 that fixes various build issues. I've 
also updated http://www.scipy.org/Installing_SciPy/Windows with a new 
tutorial on how to build Numpy/Scipy on Windows. Any comments or 
suggestions are very welcome.

Should we make ATLAS-optimized Windows binaries of Numpy available? 
Maybe starting with 0.9.8? I could provide (32bit) Athlon64 binaries.

Stephan

Re: [Numpy-discussion] numpy.float64(numpy.NaN)!=numpy.NaN

[Simon B. <si...@ar...>]

On Mon, 15 May 2006 09:21:59 -0400
Sasha <nd...@ma...> wrote:

> 
> BTW,
> 
> >>> from numpy import *
> >>> nan == nan
> False
> 
> >>> from decimal import *
> >>> Decimal('NaN') == Decimal('NaN')
> False
> 
> and finally (may not work on all platforms):
> 
> >>> float('NaN') == float('NaN')
> False

Yes. It looks like the "isnan" function is what I need.

I use NaN for missing data points, and I do masking
on NaN, etc. Quite handy really.

Simon.

-- 
Simon Burton, B.Sc.
Licensed PO Box 8066
ANU Canberra 2601
Australia
Ph. 61 02 6249 6940
http://arrowtheory.com 

Re: [Numpy-discussion] numpy.float64(numpy.NaN)!=numpy.NaN

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

BTW,

>>> from numpy import *
>>> nan =3D=3D nan
False

>>> from decimal import *
>>> Decimal('NaN') =3D=3D Decimal('NaN')
False

and finally (may not work on all platforms):

>>> float('NaN') =3D=3D float('NaN')
False



On 5/15/06, Sasha <nd...@ma...> wrote:
> It's a feature IEEE standard requires that NaNs are not equal to any
> floating point numbers including other NaNs.
>
> On 5/15/06, Simon Burton <si...@ar...> wrote:
> >
> > >>> numpy.float64(numpy.NaN)=3D=3Dnumpy.NaN
> > False
> >
> > Hmm. Bug or feature ?
> >
> > >>> numpy.__version__
> > 0.9.7.2502
> >
> > Simon.
> >
> > --
> > Simon Burton, B.Sc.
> > Licensed PO Box 8066
> > ANU Canberra 2601
> > Australia
> > Ph. 61 02 6249 6940
> > http://arrowtheory.com
> >
> >
> > -------------------------------------------------------
> > Using Tomcat but need to do more? Need to support web services, securit=
y?
> > Get stuff done quickly with pre-integrated technology to make your job =
easier
> > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geron=
imo
> > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> > _______________________________________________
> > Numpy-discussion mailing list
> > Num...@li...
> > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> >
>

Re: [Numpy-discussion] numpy.float64(numpy.NaN)!=numpy.NaN

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

It's a feature IEEE standard requires that NaNs are not equal to any
floating point numbers including other NaNs.

On 5/15/06, Simon Burton <si...@ar...> wrote:
>
> >>> numpy.float64(numpy.NaN)=3D=3Dnumpy.NaN
> False
>
> Hmm. Bug or feature ?
>
> >>> numpy.__version__
> 0.9.7.2502
>
> Simon.
>
> --
> Simon Burton, B.Sc.
> Licensed PO Box 8066
> ANU Canberra 2601
> Australia
> Ph. 61 02 6249 6940
> http://arrowtheory.com
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job ea=
sier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim=
o
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

Re: [Numpy-discussion] numpy.float64(numpy.NaN)!=numpy.NaN

[Simon B. <si...@ar...>]

On Mon, 15 May 2006 17:08:46 +1000
Simon Burton <si...@ar...> wrote:

> 
> >>> numpy.float64(numpy.NaN)==numpy.NaN
> False
> 
> Hmm. Bug or feature ?

I don't know, but I just found the isnan function.
Along with some other curious functions:
['isnan', 'nan', 'nan_to_num', 'nanargmax', 'nanargmin', 'nanmax', 'nanmin', 'nansum']

:)

Simon.


-- 
Simon Burton, B.Sc.
Licensed PO Box 8066
ANU Canberra 2601
Australia
Ph. 61 02 6249 6940
http://arrowtheory.com 

RE: [Numpy-discussion] numpy.float64(numpy.NaN)!=numpy.NaN

[Albert S. <fu...@gm...>]

Hey Simon

I think this is a feature. NaN is never equal to anything else, including
itself. MATLAB does the same thing:

>> nan==nan
ans =
     0
>> inf==inf
ans =
     1

Regards,

Albert

> -----Original Message-----
> From: num...@li... [mailto:numpy-
> dis...@li...] On Behalf Of Simon Burton
> Sent: 15 May 2006 09:09
> To: num...@li...
> Subject: [Numpy-discussion] numpy.float64(numpy.NaN)!=numpy.NaN
> 
> 
> >>> numpy.float64(numpy.NaN)==numpy.NaN
> False
> 
> Hmm. Bug or feature ?
> 
> >>> numpy.__version__
> 0.9.7.2502
> 
> Simon.

Re: [Numpy-discussion] numpy.float64(numpy.NaN)!=numpy.NaN

[Johannes L. <a.u...@gm...>]

Hi,

> >>> numpy.float64(numpy.NaN)==numpy.NaN
>
> False
>

According to the standards, two NaNs should never be equal (since nan 
represents an 'unknown' value). So the 'real' bug is this:

------------------------
In [1]: import numpy as N

In [2]: N.nan == N.nan   # wrong result!
Out[2]: True

In [3]: N.array([N.nan]) == N.array([N.nan])   # correct result
Out[3]: array([False], dtype=bool)

In [4]: N.__version__
Out[4]: '0.9.7.2484'
------------------------

Johannes

[Numpy-discussion] numpy.float64(numpy.NaN)!=numpy.NaN

[Simon B. <si...@ar...>]

>>> numpy.float64(numpy.NaN)==numpy.NaN
False

Hmm. Bug or feature ?

>>> numpy.__version__
0.9.7.2502

Simon.

-- 
Simon Burton, B.Sc.
Licensed PO Box 8066
ANU Canberra 2601
Australia
Ph. 61 02 6249 6940
http://arrowtheory.com 

Re: [Numpy-discussion] downsample vector with averaging

[Stephen W. <ste...@cs...>]

John Hunter wrote:

>
>An open source version (GPL) for octave by Paul Kienzle, who is one of
>the authors of the matplotlib quadmesh functionality and apparently a
>python convertee, is here
>
>   http://users.powernet.co.uk/kienzle/octave/matcompat/scripts/signal/decimate.m
>
>and it looks like someone has already translated this to python using
>scipy.signal
>
>  http://www.bigbold.com/snippets/posts/show/1209
>
>Some variant of this would be a nice addition to scipy.  
>
>  
>
I agree, and I just found by experiment, putting the code from the 
second link into scipy was pretty easy (I put it into signaltools.py).  
But the Octave code is GPL and the Python translation is pretty much a 
straight copy of it.  Plus I don't know how to get hold of the Python 
translator.  So, how to proceed from here?

[Numpy-discussion] Re: Dot product threading?

[Robert K. <rob...@gm...>]

Angus McMorland wrote:
> Is there a way to specify which dimensions I want dot to work over?

Use swapaxes() on the arrays to put the desired axes in the right places.

In [2]: numpy.swapaxes?
Type:           function
Base Class:     <type 'function'>
String Form:    <function swapaxes at 0x5d6d30>
Namespace:      Interactive
File:
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/numpy-0.9.7.2476-py2.4-macosx-10.4-ppc.egg/numpy/core/oldnumeric.py
Definition:     numpy.swapaxes(a, axis1, axis2)
Docstring:
    swapaxes(a, axis1, axis2) returns array a with axis1 and axis2
    interchanged.


In [3]: numpy.dot?
Type:           builtin_function_or_method
Base Class:     <type 'builtin_function_or_method'>
String Form:    <built-in function dot>
Namespace:      Interactive
Docstring:
    matrixproduct(a,b)
    Returns the dot product of a and b for arrays of floating point types.
    Like the generic numpy equivalent the product sum is over
    the last dimension of a and the second-to-last dimension of b.
    NB: The first argument is not conjugated.

-- 
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] Dot product threading?

[Angus M. <am...@gm...>]

Is there a way to specify which dimensions I want dot to work over?

For example, if I have two arrays:

    In [78]:ma = array([4,5,6]) # shape = (1,3)
    In [79]:mb = ma.transpose()   # shape = (3,1)
    In [80]:dot(mb,ma)
    Out[80]:
    array([[16, 20, 24],
           [20, 25, 30],
           [24, 30, 36]])

No problems there.
Now I want to do that multiple times, threading over the first dimension
of larger arrays:

    In [85]:mc = array([[[4,5,6]],[[7,8,9]]])        # shape = (2, 1, 3)
    In [86]:md = array([[[4],[5],[6]],[[7],[8],[9]]]) #shape = (2, 3, 1)

and I want to calculate the two (3, 1) x (1, 3) dot products to get a
shape = (2, 3, 3) result, so that

    res[i,...] == dot(md[i,...], mc[i,...])

From my example above res[0,...] would be the same as dot(mb,ma) and
res[1,...] would be

    In [108]:dot(md[1,...],mc[1,...])
    Out[108]:
    array([[49, 56, 63],
           [56, 64, 72],
           [63, 72, 81]])

I could do it by explicitly looping over the first dimension (as
suggested by my generic example), but it seems like there should be a
better way by specifying to the dot function the dimensions over which
it should be 'dotting'.

Cheers,

Angus.
-- 
Angus McMorland
email a.m...@au...
mobile +64-21-155-4906

PhD Student, Neurophysiology / Multiphoton & Confocal Imaging
Physiology, University of Auckland
phone +64-9-3737-599 x89707

Armourer, Auckland University Fencing
Secretary, Fencing North Inc.

Re: [Numpy-discussion] NumPy, Numeric or numarray or all of them?

[<ma...@lo...>]

Christopher Barker wrote:
> Mateusz Łoskot wrote:
> 
>> I'm a developer contributing to GDAL project (http://www.gdal.org).
>> GDAL is a core GeoSpatial Librarry that has had Python bindings
>> for a while. Recently, we did get some reports from users that GDAL
>> bindings do not work with NumPy package.
> 
> 
> Speaking as a long time numpy (Numeric, etc.) user, and a new user of
> GDAL, I had no idea GDAL worked with num* at all! at least not directly.

Yes, it is :-)

> In fact, I thought I was going to have to write that code myself. Where
> do I find docs for this? I'm sure I've just missed something, but I'm
> finding the docs a bit sparse.

Do you mean docs for Python bindings of GDAL?
AFAIK the only docs for Python oriented users is the "GDAL API Tutorial"
(http://www.gdal.org/gdal_tutorial.html).
Although, I'm not sure if there is or not manual reference
for gdal.py module, so I'll take up this subject soon.

In the meantime, I'd suggest to use epydoc tool to generate
some manual - it won't be a complete reference but
it can be usable.

> On the other hand, I am also finding GDAL to be an excellent library,
> and have so far gotten it to do what I need it to do. So kudos!

Thanks!

>> Can we consider NumPy as the only package in future?
>> Simply, we are wondering which Python library we should develop for
>> NumPy, Numeric or numarray to be most generally useful.
> 
> 
> Speaking as a very interested observer, but not a developer of any of
> the num* packages:
> 
> numpy is the way of the future. As an observer, I think that's pretty
> clear. On the other hand, it is still beta software, so dropping Numeric
> just yet may not be appropriate. If you don't already support numarray,
> there is no reason to do so now.
> 
> It will do the python numerical community a world of good for all of us
> to get back to a single array package.
> 
> Note also that we hope some day to get a simple n-d array object into
> the python standard library. When that happens, that object is all but
> guaranteed to be compatible with numpy.

There are two separate bindings to Python in GDAL:
- native, called traditional
- SWIG based, called New Generation Python

So, we've decided to port the latter to NumPy.

Thank you
-- 
Mateusz Łoskot
http://mateusz.loskot.net

Re: [Numpy-discussion] NumPy, Numeric or numarray or all of them?

[<ma...@lo...>]

Travis Oliphant wrote:
> Mateusz ?oskot wrote:
> 
>> 
>> I'm a developer contributing to GDAL project (http://www.gdal.org).
>>  GDAL is a core GeoSpatial Librarry that has had Python bindings 
>> for a while. Recently, we did get some reports from users that GDAL
>>  bindings do not work with NumPy package.
> 
> 
> Most packages can be "ported" simply by replacing include 
> "Numeric/arrayobject.h" with include "numpy/arrayobject.h" and making
>  sure the include files are retrieved from the right place. NumPy was
>  designed to make porting from Numeric a breeze.

Yes, portging to NumPy seems to be straightforward.

>> This situation brings some questions we'd like to ask NumPy Dev
>> Team:
>> 
>> Is it fair to say we are unlikely to see Numeric releases for new 
>> Pythons in the future?
>> 
> 
> Yes, that's fair. Nobody is maintaining Numeric.

I understand.

>> Can we consider NumPy as the only package in future?
>> 
> 
> Yes. That's where development is currently active.

Clear.
So, I'm now working on moving GDAL bindings to Python to NumPy.

>> What's the recommended way to go now?
>> 
> 
> 
> I've ported tens of packages to NumPy from Numeric and have had very 
> little trouble. It is not difficult. Most of the time, simply
> replacing the *.h file with the one from numpy works fine. It might
> be a bit trickier to get your headers from the right place. The
> directory is returned by
> 
> import numpy.distutils 
> numpy.distutils.misc_util.get_numpy_include_dirs()
> 
> Give it a try it's not very difficult.

Thank you very much for valuable tips.
I've just started to port it. I'll give some note about results.

Cheers
-- 
Mateusz Łoskot
http://mateusz.loskot.net

Re: [Numpy-discussion] Creating small arrays from strings and concatenating with empty arrays

[Charles R H. <cha...@gm...>]

On 5/11/06, Bill Baxter <wb...@gm...> wrote:
>
> Ahh, I hadn't noticed the fromstring/fromfile methods.
>
> Hmm.  That seems ok for making a row-at-a-time, but it doesn't support th=
e
> full syntax of the matrix string constructor,  which allows for things li=
ke
>
> >>> numpy.matrix("[1 2; 2 3;3 4]")
> matrix([[1, 2],
>        [2, 3],
>        [3, 4]])
>

You can reshape the array returned by fromstring, i.e.,

In [6]: fromstring("1 2 2 3 3 4", sep=3D" ").reshape(-1,2)
Out[6]:
array([[1, 2],
       [2, 3],
       [3, 4]])

Chuck

[Numpy-discussion] Some numpy.distutils question

[Stephan T. <st...@si...>]

Hi all

Could maybe someone explain which combinations of Blas, Atlas and Lapack 
Numpy should support in principle? For example, atlas_info in 
system_info.py takes a special code path and defines a macro when 
'lapack' is not among the found libraries but a lib with the hard-coded 
name 'lapack_atlas' is. This looks like a Numpy with ATLAS-only option, 
but it is not documented.

It looks like the numpy.distutils mingw32compiler class is copy of the 
one in the python distutils - but it seems to be out of date. Shouldn't 
we now make use of the Python one, or resync numpy's code?

What should be done with the suppressed compiler warnings? Should there 
be some config switch to activate them, should they always be shown?

Ciao,
   Stephan

[Numpy-discussion] Weird slicing behavior

[David H. <dav...@gm...>]

Hi,

I noticed that slicing outside bounds with lists returns the whole list :
>>> a =3D range(5)
>>> a[-7:]
[0, 1, 2, 3, 4]

while in numpy, array has a weird behavior
>>> a =3D numpy.arange(5)
>>> a[-7:]
array([3, 4])   # Ok, it takes modulo(index, length)

but

>>> a[-11:]
array([0, 1, 2, 3, 4]) # ???

Cheers,
David

Re: [Numpy-discussion] Creating small arrays from strings and concatenating with empty arrays

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

Bill Baxter wrote:
> it doesn't support the
> full syntax of the matrix string constructor,  which allows for things like
> 
>>>> numpy.matrix("[1 2; 2 3;3 4]")
> matrix([[1, 2],
>       [2, 3],
>       [3, 4]])
> 

> I think an array version of the matrix string constructor that returns the
> latter would be handy.
> But it's admittedly a pretty minor thing.

I agree it's pretty minor indeed, but as long as the code is in the 
matrix object, why not in the array object as well?

As I think about it, I can see two reasons:

1) arrays are n-d. after commas and semi-colons, how do you construct a 
higher-than-rank-two array?

2) is it really that much harder to type the parentheses?:

I suppose there is a bit of inefficiency in creating all those tuples, 
just to have them dumped, but I can't imagine that ever really matters.

By the way, you can do:
 >>> a = numpy.fromstring("1 2; 2 3; 3 4", sep=" ").reshape((-1,2))
 >>> a
array([[1, 2],
        [2, 3],
        [3, 4]])

Which, admittedly, is kind of clunky, and, in fact, the ";" is being 
ignored, but you can put it there to remind yourself what you meant.

A note about fromstring/fromfile:

I sometimes might have a mix of separators, like the above example. It 
would be nice I I could pass in more than one that would get used. the 
above example will only work if there is a space in addition to the 
semi-colon. It would be nice to be able to do:

a = numpy.fromstring("1 2;2 3;3 4", sep=" ;")
or
a = numpy.fromstring("1,2;2,3;3,4", sep=",;")

and have that work.

Travis, I believe you said that this code was inspired by my Scanfile 
code I posted on this list a while back. In that code, I allowed any 
character that ?scanf didn't interpret as a number be used as a 
separator: if you asked for the next ten numbers in the file, you'd get 
the next ten numbers, regardless of what was in between them.

While that seems kind of ripe for masking errors, I find that I need to 
know what the file format I'm working with looks like anyway, and while 
this approach might mask an error when you read the data, it'll show up 
soon enough later on, and it sure does make it easy to use and code. 
Maybe a special string for sep could give us this behavior, like "*" or 
something.

I'm also not sure it's the best idea to put this functionality into 
fromstring, rather than a separate function, perhaps fromtext()? (or 
scantext(), or ? ) That's not a big deal, but it just seems like it's a 
bit hidden there, and scanning a string is a very different operation 
that interpreting that string as binary data.

-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] Who uses matrix?

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

Bill Baxter wrote:

> On 5/11/06, *Robert Hetland* <he...@ta... 
> <mailto:he...@ta...>> wrote:
>
>
>     Is it worth it to convert the arrays to matrices in order to do this
>     handful of calculation?  Almost.  I covet the shorthand .T notation
>     in matrix object while getting RSI typing in t-r-a-n-s-p-o-s-e.
>     Also, for involved calculations inverse, transpose et. al are long
>     enough words such that the line always wraps, resulting in less-
>     readable code.
>
Note that T(a) is only one character longer than a.T and is trivially 
implementable today. If you're doing enough typing of t-r-a-n-s-p-o-s-e 
to induce RSI, it's surely not going to hurt you to type:

    def T(a): return a.transpose()

etc, somewhere at the top of your module.

>
> +1 on a .T shortcut for arrays.
> +1 on a .H shortcut for arrays, too.  (Instead of .conj().transpose())

-1.

These are really only meaningul for 2D arrays. Without the axis keyword 
they generally do the wrong things for arrays of other dimensionality 
(there I usually, but not always, want to transpose the first two or 
last two axes). In addition, ndarray is already overstuffed with methods 
and attributes, let's not add any more without careful consideration.

> I'm not wild about the .I shortcut.  I prefer to see big expensive 
> operations like a matrix inverse to stand out a little more when I'm 
> looking at the code.  And I hardly ever need an inverse anyway 
> (usually an lu_factor or SVD or something like that will do what I 
> need more efficiently and robustly than directly taking an inverse).

Agreed. In addition, inverse is another thing that's specific to 2D arrays.

> I just finished writing my first few hundred lines of code using array 
> instead of matrix.  It went fine.  Here are my impressions: it was 
> nice not having to worry so much about whether my vectors were row 
> vectors or column vectors all the time, or whether this or that was 
> matrix type or not.  It felt much less like I was fighting with numpy 
> than when I was using matrix.  I also ported a little bit of matlab 
> code that was full of apostrophes (matlab's transpose operator).  With 
> numpy arrays, all but one of the transposes went away.    I realized 
> also that most of what I end up doing is wrangling data to get it in 
> the right shape and form so that I can to do just a few lines of 
> linear algebra on it, similar to what you observe, Rob, so it makes 
> little sense to have everything be matrices all the time.
>
> So looks like I'm joining the camp of "matrix -- not worth the bother" 
> folks.  The .T shortcut for arrays would still be nice though. 
>
> And some briefer way to make a new axis than 'numpy.newaxis' would be 
> nice too (I'm trying to keep my global namespace clean these days).
> --- Whoa I just noticed that a[None,:] has the same effect as 
> 'newaxis'.  Is that a blessed way to do things?

numpy.newaxis *is* None. I don't think that I'd spell it that way since 
None doesn't really have the same conotations as newaxis, so I think 
I'll stick with np.newaxis, which is how I spell these things.

For an even weirder example, which only exists in a parallel universe, I 
thought about proposing alls as another alias for None. This was so 
that, for instance, one could do:

    sum(a, axes=all)

instead of sum(a, axes=None). That's clearer, but the cognitive 
disonance of 'all=None' scared me away.

-tim

Re: [Numpy-discussion] Who uses matrix?

[Sven S. <sve...@gm...>]

Bill Baxter schrieb:

> So looks like I'm joining the camp of "matrix -- not worth the bother"
> folks.  The .T shortcut for arrays would still be nice though. 
> 

Bill, I think I see what you mean. Nevertheless, I prefer my vectors to
have a row-or-column orientation, for example because the requirement of
conforming shapes for multiplication reveals (some of) my bugs when I
slice a vector out of a matrix but along the wrong axis. It seems that
otherwise I would get a bogus result without necessarily realizing it.

I guess that also tells something about my inefficient matrix coding
style in general, but still... For rapidly implementing some published
formulae I prefer to map them to (numpy) code as directly and
proof-readably as possible, at least initially. And that means with
matrices.

cheers,
sven

Re: [Numpy-discussion] Who uses matrix?

[Bill B. <wb...@gm...>]

On 5/11/06, Robert Hetland <he...@ta...> wrote:
>
>
> Is it worth it to convert the arrays to matrices in order to do this
> handful of calculation?  Almost.  I covet the shorthand .T notation
> in matrix object while getting RSI typing in t-r-a-n-s-p-o-s-e.
> Also, for involved calculations inverse, transpose et. al are long
> enough words such that the line always wraps, resulting in less-
> readable code.


+1 on a .T shortcut for arrays.
+1 on a .H shortcut for arrays, too.  (Instead of .conj().transpose())

I'm not wild about the .I shortcut.  I prefer to see big expensive
operations like a matrix inverse to stand out a little more when I'm lookin=
g
at the code.  And I hardly ever need an inverse anyway (usually an lu_facto=
r
or SVD or something like that will do what I need more efficiently and
robustly than directly taking an inverse).

I just finished writing my first few hundred lines of code using array
instead of matrix.  It went fine.  Here are my impressions: it was nice not
having to worry so much about whether my vectors were row vectors or column
vectors all the time, or whether this or that was matrix type or not.  It
felt much less like I was fighting with numpy than when I was using matrix.
I also ported a little bit of matlab code that was full of apostrophes
(matlab's transpose operator).  With numpy arrays, all but one of the
transposes went away.    I realized also that most of what I end up doing i=
s
wrangling data to get it in the right shape and form so that I can to do
just a few lines of linear algebra on it, similar to what you observe, Rob,
so it makes little sense to have everything be matrices all the time.

So looks like I'm joining the camp of "matrix -- not worth the bother"
folks.  The .T shortcut for arrays would still be nice though.

And some briefer way to make a new axis than 'numpy.newaxis' would be nice
too (I'm trying to keep my global namespace clean these days).
--- Whoa I just noticed that a[None,:] has the same effect as 'newaxis'.  I=
s
that a blessed way to do things?


Regards,
Bill

Re: [Numpy-discussion] Re: numpy crash on numpy.tri(-1)

[Bill B. <wb...@gm...>]

Sorry about the lack of detail.  The platform is Windows.  I'm using
binaries off the Scipy website.
And by crash I mean a dialog pops up in my pycrust shell saying
"pythonw.exehas encountered a problem and needs to close.  We are
sorry for the
inconvenience", and then asks me if I want to send Microsoft an error
report.

Perhaps it is fixed in a more recent version of numpy, though.

--bb

On 5/12/06, Robert Kern <rob...@gm...> wrote:
>
> Bill Baxter wrote:
> > Subject says it all.  numpy.tri(-1) crashes the python process.
> >
> >>>> numpy.__version__
> > '0.9.6'
>
> On OS X:
>
> >>> import numpy
> >>> numpy.tri(-1)
> array([], shape=3D(0, 0), dtype=3Dint32)
> >>> numpy.__version__
> '0.9.7.2476'
>
> While probably not "right" in any sense of the word, it doesn't crash in
> recent
> versions.
>
> In the future, it would be good to post the output of the crash. Sometime=
s
> people use the word "crash" to imply that an exception made it to the
> toplevel
> rather than, say, a segfault at the C level. Knowing what kind of "crash"
> is
> important. With segfaults, it is also usually helpful to know the platfor=
m
> you
> are on. With segfaults in linear algebra code, it is extremely helpful to
> know
> what BLAS and LAPACK you used to compile numpy.
>
> Thank you.
>
> --
> 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
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim=
o
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>



--=20
William V. Baxter III
OLM Digital
Kono Dens Building Rm 302
1-8-8 Wakabayashi Setagaya-ku
Tokyo, Japan  154-0023
+81 (3) 3422-3380

[Numpy-discussion] Re: numpy crash on numpy.tri(-1)

[Robert K. <rob...@gm...>]

Bill Baxter wrote:
> Subject says it all.  numpy.tri(-1) crashes the python process.
> 
>>>> numpy.__version__
> '0.9.6'

On OS X:

>>> import numpy
>>> numpy.tri(-1)
array([], shape=(0, 0), dtype=int32)
>>> numpy.__version__
'0.9.7.2476'

While probably not "right" in any sense of the word, it doesn't crash in recent
versions.

In the future, it would be good to post the output of the crash. Sometimes
people use the word "crash" to imply that an exception made it to the toplevel
rather than, say, a segfault at the C level. Knowing what kind of "crash" is
important. With segfaults, it is also usually helpful to know the platform you
are on. With segfaults in linear algebra code, it is extremely helpful to know
what BLAS and LAPACK you used to compile numpy.

Thank you.

-- 
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] numpy crash on numpy.tri(-1)

[Bill B. <wb...@gm...>]

Subject says it all.  numpy.tri(-1) crashes the python process.

>>> numpy.__version__
'0.9.6'

--bb

Re: [Numpy-discussion] Creating small arrays from strings and concatenating with empty arrays

[Bill B. <wb...@gm...>]

Ahh, I hadn't noticed the fromstring/fromfile methods.

Hmm.  That seems ok for making a row-at-a-time, but it doesn't support the
full syntax of the matrix string constructor,  which allows for things like

>>> numpy.matrix("[1 2; 2 3;3 4]")
matrix([[1, 2],
       [2, 3],
       [3, 4]])

On the other hand since it's 'matrix',  it turns things like "1 2 3" into
[[1,2,3]] instead of just [1,2,3].
I think an array version of the matrix string constructor that returns the
latter would be handy.
But it's admittedly a pretty minor thing.

---bb

On 5/12/06, Christopher Barker <Chr...@no...> wrote:
>
>
> Bill Baxter wrote:
> > Two quick questions:
> > ---------1------------
> > Is there any better way to intialize an array from a string than this:
> >
> >    A =3D asarray(matrix("1 2 3"))
>
> How about:
>
> >>> import numpy as N
> >>> N.fromstring("1 2 3", sep =3D " ")
> array([1, 2, 3])
>
> or
>
> >>> N.fromstring("1 2 3", dtype =3D N.Float, sep =3D " ")
> array([ 1.,  2.,  3.])
>
> If you pass a non-empty "sep" parameter, it parses the string, rather
> than treating is as binary data. fromfile works this way too -- thanks
> Travis!
>
> -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...
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim=
o
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>



--=20
William V. Baxter III
OLM Digital
Kono Dens Building Rm 302
1-8-8 Wakabayashi Setagaya-ku
Tokyo, Japan  154-0023
+81 (3) 3422-3380

Re: [Numpy-discussion] resize()

[Filip W. <fi...@ft...>]

Hi joris,

> I was surprised by the following effect of resize()

>>>> from numpy import *                    # 0.9.6
>>>> a = array([1,2,3,4])
>>>> a.resize(2,2)
>>>> a
> array([[1, 2],
>        [3, 4]])
>>>> a.resize(2,3)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> ValueError: cannot resize an array that has been referenced or is referencing
> another array in this way.  Use the resize function

> Where exactly is the reference? I just started the interactive python shell,
> did nothing else...


You have also typed
>>> a

which in turn prints repr() of the array and causes some side effect in
the interactive mode (the `a` array is also referenced by _ special
variable after this). Try running this code as a script or use `print a`:

a.resize(2,2)
>>> print a
[[1 2]
 [3 4]]
>>> a.resize(2,3)
>>> print a
[[1 2 3]
 [4 0 0]]


> On the other hand, restarting python and executing

>>>> from numpy import *
>>>> a = array([1,2,3,4])
>>>> a.resize(2,3)
>>>> a
> array([[1, 2, 3],
>        [4, 0, 0]])

> does work...

Yes, no extra referencing before array resizing here.

> Why didn't it work for the first case?

This is just a small interactive mode feature and does not happen during
normal script execution.

cheers,
fw