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

Re: [Numpy-discussion] A case for rank-0 arrays

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

Sasha wrote:

>On 2/23/06, Francesc Altet <fa...@ca...> wrote:
>  
>
>>It's a bit late, but I want to support your proposal (most of it).
>>    
>>
>
>You are not late -- you are the first to reply! When you say "most of
>it," is there anything in particular that you don't like?
>  
>
Usually nobody has a strong opinion on these issues until they encounter 
something they don't like.  I think many are still trying to understand 
what a rank-0 array is.


>>>>type(array(2)*2)
>>>>        
>>>>
><type 'int32scalar'>
>
>I believe it should result in a rank-0 array instead.
>  
>
Can you be more precise about when rank-0 array should be returned and 
when scalars should be?

>I've recently wrote ndarray round function and that code illustrates
>the problem of implicite scalar conversion:
>  
>
I think we will have issues no matter what because rank-0 arrays and 
scalars have always been with us.  We just need to nail down some rules 
for when they will show up and live by them.

Right now the rule is basically:

rank-0 arrays become array-scalars all the time.

The exceptions are

rank0.copy()
rank0.view()
array(5)
scalar.__array__()
one_el.shape=()

If you can come up with a clear set of rules for when rank-0 arrays 
should show up and when scalars should show up, then we will understand 
better what you want to do.

-Travis

Re: [Numpy-discussion] A case for rank-0 arrays

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

On 2/23/06, Francesc Altet <fa...@ca...> wrote:
> It's a bit late, but I want to support your proposal (most of it).

You are not late -- you are the first to reply! When you say "most of
it," is there anything in particular that you don't like?

> I've also come to the conclusion that scalars and rank-0 arrays should
> coexist. This is something that appears as a natural fact when you
> have to deal regularly with general algorithms for treat objects with
> different shapes. And I think you have put this very well.

Thanks for your kind words.  If we agree to legitimize rank-0 arrays,
maybe we should start by removing conversion to scalars from ufuncs.=20
Currently:

>>> type(array(2)*2)
<type 'int32scalar'>

I believe it should result in a rank-0 array instead.

I've recently wrote ndarray round function and that code illustrates
the problem of implicite scalar conversion:

                ret =3D PyNumber_Multiply((PyObject *)a, f);
                if (ret=3D=3DNULL) {Py_DECREF(f); return NULL;}
                if (PyArray_IsScalar(ret, Generic)) {
                        /* array scalars cannot be modified inplace */
                        PyObject *tmp;
                        tmp =3D PyObject_CallFunction(n_ops.rint, "O", ret)=
;
                        Py_DECREF(ret);
                        ret =3D PyObject_CallFunction(n_ops.divide, "OO",
                                                    tmp, f);
                        Py_DECREF(tmp);
                } else {
                        PyObject_CallFunction(n_ops.rint, "OO", ret, ret);
                        PyObject_CallFunction(n_ops.divide, "OOO", ret,
                                              f, ret);
                }

Re: [Numpy-discussion] Thoughts on an ndarray super-class

[Steven H. R. <st...@sh...>]

I don't have an immediate use for this, but if available, I expect that it 
would be used.

Steve
////////////////////////

Travis Oliphant wrote:
> 
> The bigndarray class is going to disappear (probably in the next release 
> of NumPy).  It was a stop-gap measure as the future of 64-bit fixes in 
> Python was unclear.  Python 2.5 will have removed the 64-bit limitations 
> that led to the bigndarray and so it will be removed. 
> I have been thinking, however, of replacing it with a super-class that 
> does not define the dimensions or strides.  
> In other words, the default array would be just a block of memory.  The 
> standard array would inherit from the default and add dimension and 
> strides pointers.
> 
> I was thinking that this might make it easier for sub-classes using 
> fixed-sized dimensions and strides.  I'm not sure if that would actually 
> be useful, but since I was thinking about the disappearance of the 
> bigndarray, I thought I would ask for comments.
> 
> -Travis
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live 
> webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> 
> 

-- 
Steven H. Rogers, Ph.D., st...@sh...
Weblog: http://shrogers.com/weblog
"He who refuses to do arithmetic is doomed to talk nonsense."
-- John McCarthy

Re: [Numpy-discussion] help(xxx) vs print(xxx.__doc__)

[<co...@ph...>]

"Bill Baxter" <wb...@gm...> writes:

> Can someone explain why help(numpy.r_) doesn't contain all the information in
> print(numpy.r_.__doc__)?
>
> Namely you don't get the helpful example showing usage with 'help' that you get
> with '.__doc__'.
>
> I'd rather be able to use 'help' as the one-stop shop for built-in
> documentation.  It's less typing and just looks nicer.

Huh, odd. Note that in IPython, numpy.r_? and numpy.r_.__doc__ give
the same results.

And I thought I was being clever when I rewrote numpy.r_ :-) Looks
like help() looks at the class __doc__ first, while IPython looks at
the object's __doc__ first.

I've fixed this in svn.

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

[Numpy-discussion] Re: array.argmax() question

[Ryan K. <rya...@gm...>]

Is the right answer to just use flatten()?

i.e. ind=3Dabs(mymat).argmax()
     maxelem=3Dmymat.flatten()[ind]

On 2/23/06, Ryan Krauss <rya...@gm...> wrote:
> Is this the expected behavior for array.argmax():
>
> ipdb> abs(real(disps)).max()
> Out[38]: 1.7373584411866401e-05
> ipdb> abs(real(disps)).argmax()
> Out[38]: 32
> ipdb> shape(disps)
> Out[38]: (11, 3)
> ipdb> disps[11,1]
> *** IndexError: invalid index
> ipdb> disps[10,1]
> Out[38]: 0j
> ipdb> disps[10,2]
> Out[38]: (-1.7373584411866401e-05+5.2046737124258386e-21j)
>
> Basically, I want to find the element with the largest absolute value
> in a matrix and use it to scale by.  But I need to correct for the
> possibility that the largest abs value may be from a negative number.
> So, I need to get the corresponding element itself.
>
> My array is shape (11,3) and argmax without an axis argument returns
> 32, which would be the index if the matrix was reshaped into a (33,)
> vector.  Is there a clean way to extract the element based on the
> output of argmax? (and in my case it is actually using the output of
> argmax to extract the element from the matrix without the abs).  Or do
> I need to reshape the matrix into a vector first?
>
> Thanks,
>
> Ryan
>

[Numpy-discussion] array.argmax() question

[Ryan K. <rya...@gm...>]

Is this the expected behavior for array.argmax():

ipdb> abs(real(disps)).max()
Out[38]: 1.7373584411866401e-05
ipdb> abs(real(disps)).argmax()
Out[38]: 32
ipdb> shape(disps)
Out[38]: (11, 3)
ipdb> disps[11,1]
*** IndexError: invalid index
ipdb> disps[10,1]
Out[38]: 0j
ipdb> disps[10,2]
Out[38]: (-1.7373584411866401e-05+5.2046737124258386e-21j)

Basically, I want to find the element with the largest absolute value
in a matrix and use it to scale by.  But I need to correct for the
possibility that the largest abs value may be from a negative number.=20
So, I need to get the corresponding element itself.

My array is shape (11,3) and argmax without an axis argument returns
32, which would be the index if the matrix was reshaped into a (33,)
vector.  Is there a clean way to extract the element based on the
output of argmax? (and in my case it is actually using the output of
argmax to extract the element from the matrix without the abs).  Or do
I need to reshape the matrix into a vector first?

Thanks,

Ryan

Re: [Numpy-discussion] A proposal to implement round in C Was: Rookie problems - Why is C-code much faster?

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

Generally, C99 support in MSVC.NET is pretty much nil, except for maybe
support for "inline" (which MS had already added prior to the C99
standard).  This wikipedia article links to a quote from the Visual C++
program manager at Microsoft saying "In general we don't see a lot of deman=
d
for C99 features":
      http://en.wikipedia.org/wiki/C_programming_language#C99
So it's not clear the situtation will change any time soon.  I don't know i=
f
VC8 is any better in its C99 support.  I doubt it.  Wikipedia says Borland
is dragging their feet too.

--Bill

On 2/24/06, Bill Baxter <wb...@gm...> wrote:
>
> There doesn't seem to be any rint() round() or nearestint() defined in
> MSVC 7.1.  Can't find it in an MSDN search either.  I think that's why a
> lot of people in the game biz, at least, use that lrintf function written
> using intrinsics that I posted a link to earlier.  I first heard about th=
at
> on the gd-algorithms mailing list.
>
> --Bill
>
> On 2/24/06, Travis Oliphant <oli...@ie...> wrote:
> >
> > Sasha wrote:
> >
> > >Rint ufunc and ndarray metod "round" are in svn.  x.round(...) is
> > >about 20x faster than around(x) for decimals=3D0 and about 6x faster f=
or
> > >decimals>0.  The case decimals<0   is slower on integers, but it
> > >actually does something :-)
> > >
> > >
> > Great job.  Thanks for adding this, Sasha...
> >
> > I think many will enjoy using it.
> >
> > Regarding portability:  On my system rint says it conforms to BSD 4.3.
> > How portable is that?
> >
> > Can anyone try it out on say the MSVC compiler for windows?
> >
> > -Travis
> >
> >
> >
> >

Re: [Numpy-discussion] A proposal to implement round in C Was: Rookie problems - Why is C-code much faster?

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

There doesn't seem to be any rint() round() or nearestint() defined in MSVC
7.1.  Can't find it in an MSDN search either.  I think that's why a lot of
people in the game biz, at least, use that lrintf function written using
intrinsics that I posted a link to earlier.  I first heard about that on th=
e
gd-algorithms mailing list.

--Bill

On 2/24/06, Travis Oliphant <oli...@ie...> wrote:
>
> Sasha wrote:
>
> >Rint ufunc and ndarray metod "round" are in svn.  x.round(...) is
> >about 20x faster than around(x) for decimals=3D0 and about 6x faster for
> >decimals>0.  The case decimals<0   is slower on integers, but it
> >actually does something :-)
> >
> >
> Great job.  Thanks for adding this, Sasha...
>
> I think many will enjoy using it.
>
> Regarding portability:  On my system rint says it conforms to BSD 4.3.
> How portable is that?
>
> Can anyone try it out on say the MSVC compiler for windows?
>
> -Travis
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> that extends applications into web and mobile media. Attend the live
> webcast
> and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>



--
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] help(xxx) vs print(xxx.__doc__)

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

Can someone explain why help(numpy.r_) doesn't contain all the information
in print(numpy.r_.__doc__)?

Namely you don't get the helpful example showing usage with 'help' that you
get with '.__doc__'.

I'd rather be able to use 'help' as the one-stop shop for built-in
documentation.  It's less typing and just looks nicer.

Thanks,
--Bill

Re: [Numpy-discussion] A proposal to implement round in C Was: Rookie problems - Why is C-code much faster?

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

Sasha wrote:

>Rint ufunc and ndarray metod "round" are in svn.  x.round(...) is
>about 20x faster than around(x) for decimals=0 and about 6x faster for
>decimals>0.  The case decimals<0   is slower on integers, but it
>actually does something :-)
>  
>
Great job.  Thanks for adding this, Sasha...

I think many will enjoy using it. 

Regarding portability:  On my system rint says it conforms to BSD 4.3.  
How portable is that? 

Can anyone try it out on say the MSVC compiler for windows?

-Travis

Re: [Numpy-discussion] inconsistent use of axis= keyword argument?

[Gary R. <gr...@bi...>]

>> Have you thought of a nice way to generate html from the xml source to 
>> incorporate this into the scipy website?
> 
> that's easy, i'll do it tomorrow.

Hi Vidar,
I can open it now. Excellent. I can still see a couple of references to 
numarray and Numeric in there which should be removed if possible, 
including in the title.

Regarding an html version: It would be nice to gerenate as much 
cross-reference material as possible out of the XML source. I don't 
think there will be space for all the alternatives on a single html 
page, so maybe you could generate separate html files for numpy versus 
Matlab/Octave, numpy versus IDL, numpy versus R. Have you kept the 
Numeric version in the source? If so, maybe you could also generate 
numpy versus Numeric. Another idea is to put the numpy column in one 
frame and all the others together in a frame next to it which can be 
scrolled sideways to reveal the other environment of choice. Another 
more difficult idea is to put some javascript in it to allow selection 
but this is probably not worth the effort.

>> We'd need a way of making the xml editable via a wiki interface
>> and automatically generating multiple views or something.
> 
> hmmm... :)

Yes; hmmm is right. Actually, I'm sure that's a bad idea. It's better if 
you maintain control of the original, otherwise it will lose utility for 
you as a general purpose cross reference which we, the lucky numpy users 
get a side benefit from.

Gary R.

[Numpy-discussion] RE: repmat equivalent

[Alex L. <ale...@gm...>]

Another thought:

def repmat(a,m,n):
   from scipy import hstack, vstack
   a =3D eval('hstack(('+n*'a,'+'))')
   return eval('vstack(('+m*'a,'+'))')

may hstack() and vstack() be better for 1d arrays?

>>> from scipy import *
numerix Numeric 24.2
>>> a  =3D array([1,2])
>>> repmat(a,2,3)
array([[1, 2, 1, 2, 1, 2],
      [1, 2, 1, 2, 1, 2]])
>>> equal(repmat(1,1,1),1)
array([       [1]],'b')

of course, scipy.linalg.kron(ones((m,n,p,...)),a) is more robust and
works for higher dimensions. probably it's the best.

Re: [Numpy-discussion] A proposal to implement round in C Was: Rookie problems - Why is C-code much faster?

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

Rint ufunc and ndarray metod "round" are in svn.  x.round(...) is
about 20x faster than around(x) for decimals=3D0 and about 6x faster for
decimals>0.  The case decimals<0   is slower on integers, but it
actually does something :-)

Re: [Numpy-discussion] inconsistent use of axis= keyword argument?

[Vidar G. <vid...@37...>]

===== Original message from Gary Ruben | 24 Feb 2006:
> the pdf file appears to be broken. I get an error when I try to open it.

sorry, i've uploaded the files again, and tested it,
so hopefully it will work for you now.

> Have you thought of a nice way to generate html from the xml source to 
> incorporate this into the scipy website?

that's easy, i'll do it tomorrow.

> We'd need a way of making the xml editable via a wiki interface
> and automatically generating multiple views or something.

hmmm... :)

Re: [Numpy-discussion] optimizing power() for complex and real cases

[<co...@ph...>]

Tim Hochberg <tim...@co...> writes:

> David M. Cooke wrote:
>
>>Tim Hochberg <tim...@co...> writes:
>>
>>>David M. Cooke wrote:
>>>
>>>
> [SNIP]
>
>>
>>I've gone through your code you checked in, and fixed it up. Looks
>>good. One side effect is that
>>
>>def zl(x):
>>    a = ones_like(x)
>>    a[:] = 0
>>    return a
>>
>>is now faster than zeros_like(x) :-)
>>
>>
> I noticed that ones_like was faster than zeros_like, but I didn't
> think to try that. That's pretty impressive considering how
> ridicuously easy it was to write.

Might be useful to move zeros_like and empty_like to ufuncs :-) (Well,
they'd be better written as regular C functions, though.)

>>One problem I had is that in PyArray_SetNumericOps, the "copy" method
>>wasn't picked up on. It may be due to the order of initialization of
>>the ndarray type, or something (since "copy" isn't a ufunc, it's
>>initialized in a different place). I couldn't figure out how to fiddle
>>that, so I replaced the x.copy() call with a call to PyArray_Copy().
>>
>>
> Interesting. It worked fine here.

Actually, it works fine in the sense that it works. However, if you
time it, it was obvious that it wasn't using an optimized version
(x**1 was as slow as x**1.1).

> I kind of like power and scalar_power. Then ** could be advertised as
> calling scalar_power for scalars and power for arrays. Scalar power
> would do optimizations on integer and half_integer powers. Of course
> there's no real way to enforce that scalar power is passed scalars,
> since presumably it would be a ufunc, short of making _scalar_power a
> ufunc instead and doing something like:
>
> def scalar_power(x, y):
>    "compute x**y, where y is a scalar optimizing integer and half
> integer powers possibly at some minor loss of accuracy"
>    if not is_scalar(y): raise ValuerError("Naughty!!")
>    return _scalar_power(x,y)

I'm tempted to make it have the same signature as power, but call
power if passed an array (or, at the ufunc level, if the stride for
the second argument is non-zero).

>>Another point is to look at __div__, and use reciprocal if the
>>dividend is 1.
>>
>>
> That would be easy, but wouldn't it be just as easy to optimize
> __div__ for scalar divisions. Should probably check that this isn't
> just as fast since it would be a lot more general.

Hmm, scalar division and multiplication could both be speed up:

In [36]: a = arange(10000, dtype=float)
In [37]: %time for i in xrange(100000): a * 1.0
CPU times: user 3.30 s, sys: 0.00 s, total: 3.30 s
Wall time: 3.39
In [38]: b = array([1.])
In [39]: %time for i in xrange(100000): a * b
CPU times: user 2.63 s, sys: 0.00 s, total: 2.63 s
Wall time: 2.71

The differences in times are probably due to creating an array to hold
1.0.

When I have time, I'll look at the ufunc machinery. Since ufuncs are
just passed pointers to data and strides, there's no reason (besides
increasing complexity ;-) to build an ndarray object for scalars.

Alternatively, allow passing scalars to ufuncs: you could define a
ufunc (like our scalar_power) to take an array argument and a scalar
argument. Or, power could be defined to take (array, array) or (array,
scalar), and the ufunc machinery would choose the appropiate one.

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

Re: [Numpy-discussion] inconsistent use of axis= keyword argument?

[Gary R. <gr...@bi...>]

Hi Vidar,
the pdf file appears to be broken. I get an error when I try to open it. 
Have you thought of a nice way to generate html from the xml source to 
incorporate this into the scipy website? I don't think it should be part 
of the wiki. We'd need a way of making the xml editable via a wiki 
interface and automatically generating multiple views or something.
regards,
Gary

Vidar Gundersen wrote:
> (i've been updating the cross reference of MATLAB synonymous
> commands in Numeric Python to NumPy. I've kept Numeric/numarray
> alternatives in the source XML, but omitted it in the PDF outputs.
> see, http://37mm.no/download/matlab-python-xref.pdf.
> feedback is highly appreciated.)
<snip>

[Numpy-discussion] repmat equivalent

[Alex L. <ale...@gm...>]

I am also mostly Matlab user and I like repmat() a lot. I just
realized that in SciPy, i am confused about NumPy/SciPy, but it is
possible in both :-)) it is much, much easier. Just use r_[a,a] and
c_[a,a] and you get a concatination like repmat() does. if you need
'm' times row concatenation of matrix, you can use (sorry for the ugly
way, Pythoners):
eval('r_['+m*'a,'+']')

then, the repmat is just: (qute, isn't it)

def repmat(a,m,n):
    from scipy import r_, c_
    a =3D eval('r_['+m*'a,'+']')
    return eval('c_['+n*'a,'+']')

the test is:

>>> from scipy import *
numerix Numeric 24.2
>>> a =3D array([[0,1],[2,3]])
>>> a
array([[0, 1],
       [2, 3]])
>>> repmat(a,2,3)
array([[0, 1, 0, 1, 0, 1],
       [2, 3, 2, 3, 2, 3],
       [0, 1, 0, 1, 0, 1],
       [2, 3, 2, 3, 2, 3]])

Best,
Alex Liberzon <ale...@gm...>

Re: [Numpy-discussion] repmat equivalent?

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

Hello

On 2/23/06, Travis Oliphant <oli...@ie...> wrote:
> Albert Strasheim wrote:
>
> >Hello all
> >
> >I recently started using NumPy and one function that I am really
> >missing from MATLAB/Octave is repmat. This function is very useful for
> >implementing algorithms as matrix multiplications instead of for
> >loops.
> >
> >
> There is a function in scipy.linalg called kron that could be brought
> over which can do a repmat.

I quickly tried a few of my test cases with following implementation of rep=
mat:

from numpy import asarray
from scipy.linalg import kron

def repmat(a, m, n):
   a =3D asarray(a)
   return kron(ones((m, n)), a)

This test:

a =3D repmat(1, 1, 1)
assert_equal(a, 1)

fails with:

ValueError: 0-d arrays can't be concatenated

and this test:

a =3D repmat(array([1,2]), 2, 3)
assert_array_equal(a, array([[1,2,1,2,1,2], [1,2,1,2,1,2]]))

fails with:

AssertionError: Arrays are not equal (shapes (12,), (2, 6) mismatch)

Regards

Albert

Re: [Numpy-discussion] repmat equivalent?

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

Hello all

On 2/23/06, Travis Oliphant <oli...@ie...> wrote:
> Albert Strasheim wrote:
>
> >Hello all
> >
> >I recently started using NumPy and one function that I am really
> >missing from MATLAB/Octave is repmat. This function is very useful for
> >implementing algorithms as matrix multiplications instead of for
> >loops.
> >
> >
> There is a function in scipy.linalg called kron that could be brought
> over which can do a repmat.

<snip>

> Thus,
>
> kron(ones((2,3)), arr)
>
>  >>> sl.kron(ones((2,3)),arr)
> array([[1, 2, 1, 2, 1, 2],
>        [3, 4, 3, 4, 3, 4],
>        [1, 2, 1, 2, 1, 2],
>        [3, 4, 3, 4, 3, 4]])
>
> gives you the equivalent of
>
> repmat(arr, 2,3)

Thanks! Merging this into numpy would be much appreciated. Stefan van
der Walt did some benchmarks and this approach seems faster than
anything we managed for 2D arrays.

However, I'm a bit concerned about the ones(n,m) that is needed by
this implementation. It seems to me that this would double the memory
requirements of this repmat function, which is fine when working with
small matrices, but could be a problem with larger ones.

Any thoughts?

Regards

Albert

[Numpy-discussion] Re: Up-to-date bugtracker for NumPy?

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

Norbert Nemec wrote:
> Hi there,
> 
> is there any bugtracker for NumPy actually in active use? Sourceforge
> has one for numarray and one for "numpy", but the latter one contains
> only old bugs (probably for Numeric?)

http://projects.scipy.org/scipy/numpy

Click "New Ticket" up at the top to enter a new bug.

-- 
Robert Kern
rob...@gm...

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter

Re: [Numpy-discussion] Up-to-date bugtracker for NumPy?

[Norbert N. <Nor...@gm...>]

Guess the question was answered before I even asked it: The bug that I
reported two hours ago has already been fixed and closed by Travis.
Amazing reaction time!



Norbert Nemec wrote:

>Hi there,
>
>is there any bugtracker for NumPy actually in active use? Sourceforge
>has one for numarray and one for "numpy", but the latter one contains
>only old bugs (probably for Numeric?)
>
>Greetings,
>Norbert
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by xPML, a groundbreaking scripting language
>that extends applications into web and mobile media. Attend the live webcast
>and join the prime developer group breaking into this new coding territory!
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>_______________________________________________
>Numpy-discussion mailing list
>Num...@li...
>https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
>
>  
>

[Numpy-discussion] Up-to-date bugtracker for NumPy?

[Norbert N. <Nor...@gm...>]

Hi there,

is there any bugtracker for NumPy actually in active use? Sourceforge
has one for numarray and one for "numpy", but the latter one contains
only old bugs (probably for Numeric?)

Greetings,
Norbert

[Numpy-discussion] Re: inconsistent use of axis= keyword argument?

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

Vidar Gundersen wrote:

> and i also wonder why concatenate can't be used to stack 1-d
> arrays on top of each other, returning a 2-d array?

Use vstack() for that. Also note its companions, hstack() and column_stack().

-- 
Robert Kern
rob...@gm...

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter

Re: [Numpy-discussion] repmat equivalent?

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

Albert Strasheim wrote:

>Hello all
>
>I recently started using NumPy and one function that I am really
>missing from MATLAB/Octave is repmat. This function is very useful for
>implementing algorithms as matrix multiplications instead of for
>loops.
>  
>
There is a function in scipy.linalg called kron that could be brought 
over which can do a repmat.


In file: /usr/lib/python2.4/site-packages/scipy/linalg/basic.py

def kron(a,b):
    """kronecker product of a and b

    Kronecker product of two matrices is block matrix
    [[ a[ 0 ,0]*b, a[ 0 ,1]*b, ... , a[ 0 ,n-1]*b  ],
     [ ...                                   ...   ],
     [ a[m-1,0]*b, a[m-1,1]*b, ... , a[m-1,n-1]*b  ]]
    """
    if not a.flags['CONTIGUOUS']:
        a = reshape(a, a.shape)
    if not b.flags['CONTIGUOUS']:
        b = reshape(b, b.shape)
    o = outerproduct(a,b)
    o=o.reshape(a.shape + b.shape)
    return concatenate(concatenate(o, axis=1), axis=1)


Thus,

kron(ones((2,3)), arr)

 >>> sl.kron(ones((2,3)),arr)
array([[1, 2, 1, 2, 1, 2],
       [3, 4, 3, 4, 3, 4],
       [1, 2, 1, 2, 1, 2],
       [3, 4, 3, 4, 3, 4]])

gives you the equivalent of

repmat(arr, 2,3)

We could bring this over from scipy into numpy as it is simple enough.

It has a multidimensional extension (i.e. you can pass in a and b as 
higher dimensional arrays),  But, don't ask me to explain it to you 
because I can't without further study....

-Travis

Re: [Numpy-discussion] inconsistent use of axis= keyword argument?

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

Vidar Gundersen wrote:

>(i've been updating the cross reference of MATLAB synonymous
>commands in Numeric Python to NumPy. I've kept Numeric/numarray
>alternatives in the source XML, but omitted it in the PDF outputs.
>see, http://37mm.no/download/matlab-python-xref.pdf.
>feedback is highly appreciated.)
>
>
>as i was working on this, i started wondering why 
>
>a.max(0), a.min(0), a.ptp(0), a.flatten(0), ...
>
>does not allow the axis=0 keyword argument used with
>the exact same meaning for:
>  
>

It's actually consistent.  These only have a single argument and so 
don't use keywords.   But, I can see now that it might be nice to have 
keywords even if there is only one argument. 

Feel free to submit a patch.

>m.mean(axis=0), m.sum(axis=0), ...
>  
>

These have multiple arguments, so the keywords are important.

>
>and i also wonder why concatenate can't be used to stack 1-d
>arrays on top of each other, returning a 2-d array?
>axis relates to the number of axes in the original array(s)?
>  
>
Because it's ambiguous what you mean to do.  1-d arrays only have a 
single axis.  How do you propose to tell concatenate to alter the shape 
of the output array and in what direction?  We've left it to the user to 
do that, like you do in the second example.

When you have more than one dimension on input, then it is clear what 
you mean by "stack" along an axis.  With only one-dimension, it isn't 
clear what is meant.