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

Re: [Numpy-discussion] Matlab page on scipy wiki

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

Sasha wrote:
> On 2/10/06, Travis Oliphant <oli...@ee...> wrote:
>> The whole point of r_ is to allow you to use slice notation to build
>> ranges easily.  I wrote it precisely to make it easier to construct
>> arrays in a simliar style that Matlab allows.
> 
> Maybe it is just me, but r_ is rather unintuitive.  I would expect
> something like this to be called "c" for "combine" or "concatenate."  
> This is the name used by S+ and R.

I agree that c or c_ (don't care which) is more intuitive but I can 
understand why it's ended up as it has. Even v or v_ for 'vector' or a 
or a_ for 'array' would also make sense to me. I must say that Travis's 
example numpy.r_[1,0,1:5,0,1] highlights my pet hate with python - that 
the upper limit on an integer range is non-inclusive. I'm sure the BDFL 
has some excuse for this silliness.

Gary R

Re: [Numpy-discussion] BUG(?): array([None])==None test

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

Pearu Peterson wrote:

>
> Hi,
>
> While converting some Numeric based code to numpy, I noticed that
> in Numeric
>
>   array([None])==None
>
> returns array([1]) while in numpy it returns False.
>
> Is this expected behaviour or a bug?


It's expected behavior.

If you do an equality test on None then False is returned while True is 
returned on an inequality test to None.

-Travis

Re: [Numpy-discussion] Re: NumPy Glossary Was:Matlab page on scipy wiki

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

Joe Harrington <jh...@oo...> writes:

> [...]

Put this it on the wiki (seriously).

Another thing to look at is the "Producing Open Source Software" book
that's been mentioned before (http://producingoss.com/). There's a
section on wiki's that useful to keep in mind at
http://producingoss.com/html-chunk/index.html

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

[Numpy-discussion] Array literal

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

Recent discussion of the numpy catenator (r_) made me realize that
Python syntax allows us to effectively implement an array literal.
>>> from numpy import r_ as a
>>> a[1:3,5:9]
array([1, 2, 5, 6, 7, 8])
>>> a[1, 2, 5, 6, 7, 8]
array([1, 2, 5, 6, 7, 8])

One can think of a[1, 2, 5, 6, 7, 8] as an array literal.  To me it
looks very "pythonic": [...] already has a meaning of list literal and
python uses single-letter modifier in string literals to denote raw
strings.  In other words a[...] is to [...] what r"..." is to "...".=20
The catenator can probably be generalized to cover all use cases of
the "array" constructor.  For example:

a(shape=3D(2,3))[1:3,5:9] may return array([[1,2,5],[6,7,8]])
a(shape=3D(2,3))[1] may return ones((2,3))
a(shape=3D(2,3))[...] may return empty((2,3))
a(shape=3D(2,3))[1, 2, ...] may return array([[1,2,1],[2,1,2]])

dtype and other array(...) arguments can be passed similarly to shape
above.  If this syntax proves successful, ndarray repr may be changed
to return "a[...]" instead of "array([...])" and thus make new users
immediately aware of this way to represent arrays.

Re: [Numpy-discussion] Matlab page on scipy wiki

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

I would be against any meaningful name because it will look too much
like a function and people will be trying to use (...) instead of
[...] with it.  A single-letter identifier will look more like syntax
and the concatenator is really just a clever way to take advantage of
Python syntax that recognizes slices inside [].  Novices may just
think that something like c[1:3,9:20]
is an array literal like r"xyz" for raw strings (another argument against "=
r"!).

On 2/10/06, Eric Firing <ef...@ha...> wrote:
> Travis Oliphant wrote:
> > Christopher Barker wrote:
> >
> >> Colin J. Williams wrote:
> >>
> >>>> numpy.r_[1,0,range(1,5),0,1]
> >>>
> >>>
> >>
> >>> This seems to be a neat idea but not in the usual Python style.
> >>
> >>
> >>
> >> Exactly. couldn't it at least get a meaningful, but short, name?
> >
> >
> > It is meaningful :-)  r_ means row concatenation...  (but, it has taken
> > on more functionality than that).  What name do you suggest?
>
> "cat"?  "rcat"? "catr"?  "catter"?
>
> Eric
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

Re: [Numpy-discussion] Matlab page on scipy wiki

[Eric F. <ef...@ha...>]

Travis Oliphant wrote:
> Christopher Barker wrote:
> 
>> Colin J. Williams wrote:
>>
>>>> numpy.r_[1,0,range(1,5),0,1]
>>>
>>>
>>
>>> This seems to be a neat idea but not in the usual Python style.
>>
>>
>>
>> Exactly. couldn't it at least get a meaningful, but short, name?
> 
> 
> It is meaningful :-)  r_ means row concatenation...  (but, it has taken 
> on more functionality than that).  What name do you suggest?

"cat"?  "rcat"? "catr"?  "catter"?

Eric

Re: [Numpy-discussion] Matlab page on scipy wiki

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

Actually, what would be wrong with a single letter "c" or "r" for the
concatenator?  NumPy already has one single-letter global identifier -
"e", so it will not be against any naming standard.  I don't think
either "c" or "r" will conflict with anything in the standard library.
 I would still prefer "c" because "r" is taken by RPy.


On 2/10/06, Sasha <nd...@ma...> wrote:
> To tell you the truth I dislike trailing underscore much more than the
> choice of letter.  In my code I will probably be renaming all these
> foo_ to delete the underscore foo_(...) or foo_[...] is way too ugly
> for my taste.  However I fully admit that it is just a matter of taste
> and it is trivial to rename things on import in Python.
>
> PS: Trailing underscore reminds me of C++ - the language that I
> happily live without :-)
>
> On 2/10/06, Ryan Krauss <rya...@gm...> wrote:
> > The problem is that c_ at least used to mean "column concatenate" and
> > concatenate is too long to type.
> >
> > On 2/10/06, Sasha <nd...@ma...> wrote:
> > > On 2/10/06, Travis Oliphant <oli...@ee...> wrote:
> > > > The whole point of r_ is to allow you to use slice notation to buil=
d
> > > > ranges easily.  I wrote it precisely to make it easier to construct
> > > > arrays in a simliar style that Matlab allows.
> > >
> > > Maybe it is just me, but r_ is rather unintuitive.  I would expect
> > > something like this to be called "c" for "combine" or "concatenate."
> > > This is the name used by S+ and R.
> > >
> > > From R manual:
> > > """
> > > c                    package:base                    R Documentation
> > > Combine Values into a Vector or List
> > > ...
> > > Examples:
> > >      c(1,7:9)
> > > ...
> > > """
> > >
> > >
> > > -------------------------------------------------------
> > > 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://sel.as-us.falkag.net/sel?cmdlnk&kid=103432&bid#0486&dat=121642
> > > _______________________________________________
> > > Numpy-discussion mailing list
> > > Num...@li...
> > > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> > >
> >
>

Re: [Numpy-discussion] Matlab page on scipy wiki

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

To tell you the truth I dislike trailing underscore much more than the
choice of letter.  In my code I will probably be renaming all these
foo_ to delete the underscore foo_(...) or foo_[...] is way too ugly
for my taste.  However I fully admit that it is just a matter of taste
and it is trivial to rename things on import in Python.

PS: Trailing underscore reminds me of C++ - the language that I
happily live without :-)

On 2/10/06, Ryan Krauss <rya...@gm...> wrote:
> The problem is that c_ at least used to mean "column concatenate" and
> concatenate is too long to type.
>
> On 2/10/06, Sasha <nd...@ma...> wrote:
> > On 2/10/06, Travis Oliphant <oli...@ee...> wrote:
> > > The whole point of r_ is to allow you to use slice notation to build
> > > ranges easily.  I wrote it precisely to make it easier to construct
> > > arrays in a simliar style that Matlab allows.
> >
> > Maybe it is just me, but r_ is rather unintuitive.  I would expect
> > something like this to be called "c" for "combine" or "concatenate."
> > This is the name used by S+ and R.
> >
> > From R manual:
> > """
> > c                    package:base                    R Documentation
> > Combine Values into a Vector or List
> > ...
> > Examples:
> >      c(1,7:9)
> > ...
> > """
> >
> >
> > -------------------------------------------------------
> > 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://sel.as-us.falkag.net/sel?cmdlnk&kid=103432&bid#0486&dat=121642
> > _______________________________________________
> > Numpy-discussion mailing list
> > Num...@li...
> > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> >
>

Re: [Numpy-discussion] Matlab page on scipy wiki

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

On 2/10/06, Travis Oliphant <oli...@ee...> wrote:
> The whole point of r_ is to allow you to use slice notation to build
> ranges easily.  I wrote it precisely to make it easier to construct
> arrays in a simliar style that Matlab allows.

Maybe it is just me, but r_ is rather unintuitive.  I would expect
something like this to be called "c" for "combine" or "concatenate." =20
This is the name used by S+ and R.

From R manual:
"""
c                    package:base                    R Documentation
Combine Values into a Vector or List
...
Examples:
     c(1,7:9)
...
"""

Re: [Numpy-discussion] Matlab page on scipy wiki

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

Christopher Barker wrote:

> Colin J. Williams wrote:
>
>>> numpy.r_[1,0,range(1,5),0,1]
>>
>
>> This seems to be a neat idea but not in the usual Python style.
>
>
> Exactly. couldn't it at least get a meaningful, but short, name?

It is meaningful :-)  r_ means row concatenation...  (but, it has taken 
on more functionality than that).  What name do you suggest?

>
> And is there a way to use it to concatenate along other axis? I 
> couldn't see a way.

Yes, add a string at the end with the number of the axis you want to 
concatenate along.  But, you have to have that axis to start with or the 
result is no different.  The default is to concatenate along the last axis.

Thus  (the ndmin keyword forces the array to have a minimum number of 
dimensions --- prepended).

a = array([1,2,3],ndmin=2)  
b = array([1,2,3],ndmin=2)


c = r_[a,b,'0']

print c

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


print r_[a,b,'1']

[[1 2 3 1 2 3]]


-Travis

Re: [Numpy-discussion] Matlab page on scipy wiki

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

Alan G Isaac wrote:

>On Fri, 10 Feb 2006, Stefan van der Walt apparently wrote: 
>  
>
>>In Octave that would be 
>>[1, 0, 1:4, 0, 1] 
>>Using numpy we currently do 
>>concatenate([[1, 0], arange(1,5), [0, 1]]) or 
>>vstack(...) 
>>    
>>
>
>numpy.r_[1,0,range(1,5),0,1]
>  
>

or even faster

numpy.r_[1,0,1:5,0,1]

The whole point of r_ is to allow you to use slice notation to build 
ranges easily.  I wrote it precisely to make it easier to construct 
arrays in a simliar style that Matlab allows. 

-Travis

Re: [Numpy-discussion] Matlab page on scipy wiki

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

Colin J. Williams wrote:
>> numpy.r_[1,0,range(1,5),0,1]

> This seems to be a neat idea but not in the usual Python style.

Exactly. couldn't it at least get a meaningful, but short, name?

And is there a way to use it to concatenate along other axis? I couldn't 
see a way.

-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] Matlab page on scipy wiki

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

Bill Baxter wrote:
> By the way, is there any python way to tell which package a symbol is coming
> from?

Yes. Don't use "import *".

There is a long tradition of using NumPy this way:

from numpy import *

But now I always use it this way:

import numpy as N

(or nx, or whatever short name you want). I like it, because it's always 
clear where stuff is coming from. numpy's addition of a number of 
methods for what used to be functions helps make this more convenient too.

"Namespaces are one honking great idea -- let's do more of those!"

from: http://www.python.org/doc/Humor.html#zen


-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] array shift and |=, copy, and backward operations

[Perry G. <pe...@st...>]

On Feb 10, 2006, at 3:45 PM, Nico wrote:
>
> I finally noticed that
>
> a = array([0,1,0,0])
> a[1:] |= a[:-1] | False
>
> also works, but I can't figure out why...
>
Because the expression on the right generates a new copy, thus 
eliminating the problem of overwriting itself.

Re: [Numpy-discussion] array shift and |=, copy, and backward operations

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

Nico wrote:

>Hi!
>
>a = array([0,1,0,0])
>a[1:] |= a[:-1]
>
>gives the unexpected result [0 1 1 1] instead of [0 1 1 0] because
>python performs the |= on the forst cell, then on the second, and so on.
>
>I found two ways to get it right, with a copy:
>b = a.copy()
>a[1:] |= b[:-1]
>  
>
You could also do:

a[1:] = a[1:] | a[:-1]

This is nearly the same as the copy version, but uses very slightly less 
space and is clearer IMO.

>or working backward:
>a[-1:1:-1] |= a[-2:0:-1]
>
>which is better, in terms of speed (and memory management), for large 3D
>arrays?
>  
>
The backwards version will be better in terms of memory usage and almost 
certainly in terms of speed as well since it avoids and extra copy and 
should have better locality of reference (also because of no extra 
copy). It's a little obscure though. I'd be tempted to do something like.

a_rev = a[::-1]
a_rev[:-1] |= a_rev[1:]
# a holds result.

Another question / suggestion is: are you using a[0]. This looks like an 
operation where you may well be throwing away a[0] when you are done 
anyway. If that is the case, would it work to use:

a[:-1] |= a[1:]
a = a[:-1]

This last will give you the same result as the others except that the 
first value will be missing.

-tim

Re: [Numpy-discussion] array shift and |=, copy, and backward operations

[Nico <nic...@li...>]

> a = array([0,1,0,0])
> a[1:] |= a[:-1]
>
> gives the unexpected result [0 1 1 1] instead of [0 1 1 0] because
> python performs the |= on the first cell, then on the second, and so on.
>
> I found two ways to get it right, with a copy:
> b = a.copy()
> a[1:] |= b[:-1]
>
> or working backward:
> a[-1:1:-1] |= a[-2:0:-1]

I finally noticed that

a = array([0,1,0,0])
a[1:] |= a[:-1] | False

also works, but I can't figure out why...

-- 
Nico

[Numpy-discussion] array shift and |=, copy, and backward operations

[Nico <nic...@li...>]

Hi!

a = array([0,1,0,0])
a[1:] |= a[:-1]

gives the unexpected result [0 1 1 1] instead of [0 1 1 0] because
python performs the |= on the forst cell, then on the second, and so on.

I found two ways to get it right, with a copy:
b = a.copy()
a[1:] |= b[:-1]

or working backward:
a[-1:1:-1] |= a[-2:0:-1]

which is better, in terms of speed (and memory management), for large 3D
arrays?

-- 
Nico

[Numpy-discussion] Test test_minrelpath.py on unix for me

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

Could someone try the attached diff on a unixy system? It works under 
windows, but it's easy to mess up those \/'s.

Thanks,

-tim

Re: [Numpy-discussion] Is there a known problem compiling numpy with VC7? Success

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

Pearu Peterson wrote:

>
>
> On Thu, 9 Feb 2006, Tim Hochberg wrote:
>
>> Tim Hochberg wrote:
>>
>>> Pearu Peterson wrote:
>>>
>>>>
>>>>
>>>> On Thu, 9 Feb 2006, Tim Hochberg wrote:
>>>>
>>>>> I had this fantasy that default_lib_dirs would get picked up 
>>>>> automagically; however that does not happen. I still ended up 
>>>>> putting:
>>>>>
>>>>>           from  numpy.distutils import system_info
>>>>>           library_dirs = system_info.default_lib_dirs
>>>>>           result = 
>>>>> config_cmd.try_run(tc,include_dirs=[python_include], 
>>>>> library_dirs=library_dirs)
>>>>>
>>>>> into setup.py. Is that acceptable? It's not very elegant.
>>>>
>>>>
>>>>
>>>>
>>>> No, don't use system_info.default_lib_dirs.
>>>>
>>>> Use distutils.sysconfig.get_python_lib() to get the directory that 
>>>> contains Python library.
>>>
>>>
>>>
>>> That's the wrong library. Get_python_lib gives you the location of 
>>> the python standard library, not the location of python24.lib. The 
>>> former being python24/Lib (or python24/Lib/site-packages depending 
>>> what options you feed get_python_lib) 'and the latter being 
>>> python24/libs on my box.
>>
>
> Ok, but using system_info.default_lib_dirs is still wrong, this list 
> is not designed for this purpose..


OK.

>
>> To follow up on this a little bit, I investigated how distutils 
>> itself finds python24.lib. It turns out that it is in build_ext.py, 
>> near line 168. The relevant code is:
>>
>>       # also Python's library directory must be appended to library_dirs
>>       if os.name == 'nt':
>>           self.library_dirs.append(os.path.join(sys.exec_prefix, 
>> 'libs'))
>
>
> Hmm, this should be effective also for numpy.distutils. 
> self.library_dirs and other such attributes are used in 
> distutils.command.build_ext.run() method while our 
> numpy.distutils.command.build_ext.run() doesn't. So, I we have to do 
> is to update numpy.distutils.command.build_ext.run() method to resolve 
> this issue. This should fix also rpath issues that was reported on 
> this list for certain platforms. I'll look fixing it today..


While your looking at it, keep in mind that the original failure that I 
was trying to fix occurs when numpy/core/setup.py calls 
config_cmd.try_run.  I'm not certain, but I suspect that this isn't 
going to got through numpy.distutils.command.build_ext. One strategy 
would be to put a functions somewhere that returns these extra libray 
directories somewhere appropriate and call it from both 
numpy.distutils.command.build_ext and numpy/core/setup.py. It could look 
like:

def get_extra_library_dirs():
    if os.name == 'nt':
          return [os.path.join(sys.exec_prefix, 'libs')]
    else:
          return []

I'm not sure what would be an appropriate place for it though.

-tim

>
> Pearu
>
>

Re: [Numpy-discussion] Matlab page on scipy wiki

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

Sven Schreiber wrote:
> Fernando Perez schrieb:
> 
>>Bill Baxter wrote:
>>
>>>For what it's worth, matlab's rank function just calls svd, and
>>>returns the
>>>number singular values greater than a tolerance.  The implementation is a
>>>whopping 5 lines long.
>>
>>Yup, and it would be pretty much the same 5 lines in numpy, with the
>>same semantics.
>>
>>Here's a quick and dirty implementation for old-scipy (I don't have
>>new-scipy on this box):
>>
> 
> 
> Is there any reason not to use the algorithm implicit in lstsq, as in:
> rk = linalg.lstsq(M, ones(p))[2]

Simplicity?  lstsq goes through a lot of contortions (needed for other 
reasons), and uses lapack's *gelss.  If you read its man page:

PURPOSE
        DGELSS computes the minimum  norm  solution  to  a  real  linear  least
        squares problem: Minimize 2-norm(| b - A*x |).

        using  the  singular  value  decomposition  (SVD)  of A. A is an M-by-N
        matrix which may be rank-deficient.

        Several right hand side vectors b and solution vectors x can be handled
        in a single call; they are stored as the columns of the M-by-NRHS right
        hand side matrix B and the N-by-NRHS solution matrix X.

        The effective rank of A is determined by treating as zero those  singu-
        lar  values which are less than RCOND times the largest singular value.


So you've gone through all that extra complexity, to get back what a direct 
call to svd would give you (caveat: the quick version I posted used absolute 
tolerance, while this one is relative; that can be trivially fixed).

Given that a direct SVD call fits the definition of what we are computing (a 
numerical estimation of a matrix rank), I completely fail to see the point of 
going through several additional layers of unnecessary complexity, which both 
add cost and obscure the intent of the calculation.

But perhaps I'm missing something...

Cheers,

f

[Numpy-discussion] gnuplot problem with numpy

[Brian B. <bb...@br...>]

Hello,

I have been trying to use the Gnuplot1.7.py module, but it doesn't seem to work with 
numpy (although it works with Numeric).  The following code plots two "identical" 
sets of data, but the numpy data gets rounded to the nearest integer when passed to 
Gnuplot.  What is odd is that the offending code in utils.py, is the function 
float_array(m), which does the conversion that I do in this script, but it doesn't 
seem to work.  Any ideas?

#----------------------------
import numpy
import Numeric
import Gnuplot

g = Gnuplot.Gnuplot(debug=1)
dh=.1;
x=numpy.arange(dh,2+dh,dh,'d')
y1 = x**2


y2=y1

d1 = Gnuplot.Data(x, y1,
                  title='numpy',
                  with='points')  # doesn't work
d2 = Gnuplot.Data(Numeric.asarray(x,'f'), Numeric.asarray(y2,'f'),
                  title='Numeric',
                  with='points')   # works

g.plot(d1,d2)

#----------------------------




			thanks,

				bb

-- 
-----------------

             bb...@br...
             http://web.bryant.edu/~bblais

Re: [Numpy-discussion] Matlab page on scipy wiki

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

David M. Cooke wrote:

>Bill Baxter <wb...@gm...> writes:
>
>  
>
>>Some kind soul added 'svd' and 'inv' to the NumPy/SciPi columns, but those
>>don't seem to be defined, at least for the versions of NumPy/SciPy that I
>>have.    Are they new?  Or are they perhaps defined by a 3rd package in your
>>environment?
>>    
>>
>
>They're in numpy.linalg.
>
>  
>
>>By the way, is there any python way to tell which package a symbol is coming
>>from?
>>    
>>
>
>Check it's __module__ attribute.
>
>  
>
Yes, but not all objects have this attribute and some do not yet have a 
docstring. 

Colin W.

[Numpy-discussion] Re: NumPy Glossary Was:Matlab page on scipy wiki

[Joe H. <jh...@oo...>]

Look, people are making this into something it isn't, and hating that.
I'm the last person in the world to want rules and bureaucrazy!
However, to make the wiki accomplish our goals, we need to agree on
some basic standards of judgement that we apply to ourselves.  We did
agree on some goals after SciPy '04: we want Python to be the
environment of choice for EVERYONE to do numerical manipulation and
data display, and to get there we need to present ourselves well (see
the ASP roadmap, linked at the bottom of DevZone).  I'm going to lay
out my reasoning why a particular workflow will reach that goal.  The
idea is to take full advantage of the Wiki Way without having the
liabilities of the Wiki Way.  I'm sorry this is long.  I have three
proposals due Thursday and I don't have time to edit much.

Bill, your argument is that you want to see a work in progress,
something you and anyone else can just go and contribute to whenever
you see a need, and that benefits from others making contributions
continually.  That's great from the point of view of an experienced
user of array math (in Python or otherwise) who is used to and
interested in contributing in the Wiki Way.  I'm sure most list
members, even of the scipy-user list, are still in this category.

It is therefore crucial for all of us to remember that such people are
*not* the main viewers of the site, at least not in the future we said
we hoped for, and probably not even now.  Most viewers are
dyed-in-the-wool users and potential users.  They want to see a clean,
professional, straightforward site with the simple life laid out
before them: bulletproof, current, binary installs for all their
preferred platform(s); readable, grammatical, complete, current,
well-assembled documentation for beginners and experts, both tutorial
and reference; examples, screenshots, demos; lots of good, indexed,
well-documented, shared software; and an active community.  "Under
construction" is an annoyance at best, and a deal-killer to many.
They may contribute someday, but that's not in their minds yet.

Recall that we have in our vision not just practicing scientists, but
also secondary-school students and their teachers, students taking
their only math or science course in college (under direction from
their professors and TAs), and even photographers and others who would
have need of the manipulations NumPy allows without necessarily
understanding them.  Our failure to gather a large following to date
is largely due to our not (yet) delivering on the site/project vision
above.  The reunification that is NumPy allows us to change that.
There are a LOT of people lurking, waiting for things to clean up and
professionalize.  Once they jump in, they'll tell their peers, who
have never heard of us, and so on.  The pure Wiki Way will never
produce the site that will start this hoped-for avalanche of ordinary
users.  Wikis are always under construction, always bleeding-edge,
always overdone in areas where their developers have interest, and
always weak in crucial places where they don't.

That said, wikis are *great* incubators.  Wikis get individual
subprojects completed fast and well by breaking down the barriers to
contribution and review.  DevZone tries to take advantage of the Wiki
Way while still producing a polished site.

The point of DevZone is twofold: first, focus contributors looking for
a project on the things that most need help: our weak spots, like
documentation.  I'm getting about an email a week from new people
looking to help.  This wasn't the case a month ago or before; it was
more like 1-2 a year.  Second, isolate the worst of "under
constructon" from the general view, so we don't look like a pile of
stubs, go-nowhere links, and abandonned or outdated projects.  The
second item probably makes more sense for larger projects (a user's
guide, etc.) than for pages like the glossary.  The model for workflow
is that projects are announced to the lists and immediately started in
DevZone.  When they reach a basic level of completeness and
cleanliness, something like a 1.0 release, they get a link from the
main site.  When they are no longer in need of new helpers or when
their development curve levels off, the DevZone link goes away.

Right now, it's pretty loose when to put the link in from the main
site to a project's page.  Anyone can do it.  To avoid a Wiki War, we
need to have some common vision for how much of a construction zone we
want the main site to be.

The development model I'm discussing is a little like the Plone model,
except that there is no elite administrator who decides when things
move up to the main site.  We dumped Plone for performance reasons,
and because the administrators were too busy with their Enthought work
to have time to do much on the site.  But, the basic Plone idea of
internal incubation is a good one.  In my ideal world, a group
(potentially including everyone, at least to a small degree) would
write a (large) doc and periodically ask the list to take a look and
comment.  At some point, they'd ask for objections to putting it on
the main site.  They'd try to satisfy any objections, and then put it
up.  I'd trust the authors of a smaller doc (that therefore was both
easier to write and had more people willing to give a quick review) to
make the decision to promote to the main site themselves.  This is
exactly what code developers do when cutting releases: ensure that
when a version goes public, it is reasonably clean, consistent, and
complete.

At the moment, some pages, most notably Documentation, are a mess.
Clear out all the "incompletes", and those pages will look like
Cookbook: cool but with gaping holes.  I think that would be an
improvement, particularly if we state on those pages that documents in
early stages of construction are in DevZone, and provide a link.  We
could link those docs at the bottom of Documentation, but there is a
point in a project's life cycle when it would be linked both from the
main site and in DevZone.  Do we want those projects to have two links
on the same page?  And do we really want all that "under construction"
in people's faces?

In the future, we will have good docs and a more spanning set of
recipes.  At that point, if we have embraced the pure Wiki Way, we
will have a hard time agreeing no longer to do early construction in
the main site.  The loads of construction between the gems will turn
away many of the huge class of non-expert users.  SciPy will thus gain
fewer users, and therefore attract fewer contributors and grow more
slowly.  My point now is to get our community culture to include a
sense of professionalism and pride about what we present to the world.
Unless you're a fool or you have no competition, you dress well for a
job interview.  We're not fools, and we have very healthy competition.
The main site is the first impression we make on new users.  My goal
is to prevent it from being the last.

--jh--

Re: [Numpy-discussion] Matlab page on scipy wiki

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

Alan G Isaac wrote:

>On Fri, 10 Feb 2006, Stefan van der Walt apparently wrote: 
>  
>
>>In Octave that would be 
>>[1, 0, 1:4, 0, 1] 
>>Using numpy we currently do 
>>concatenate([[1, 0], arange(1,5), [0, 1]]) or 
>>vstack(...) 
>>    
>>
>
>numpy.r_[1,0,range(1,5),0,1]
>
>fwiw,
>Alan Isaac
>  
>
This seems to be a neat idea but not in the usual Python style.

 >>> help(numpy.r_)
Help on concatenator in module numpy.lib.index_tricks object:

class concatenator(__builtin__.object)
 |  Translates slice objects to concatenation along an axis.
 | 
 |  Methods defined here:
 | 
 |  __getitem__(self, key)
 | 
 |  __getslice__(self, i, j)
 | 
 |  __init__(self, axis=0, matrix=False)
 | 
 |  __len__(self)
 | 
 |  ----------------------------------------------------------------------
 |  Data and other attributes defined here:
 | 
 |  __dict__ = <dictproxy object>
 |      dictionary for instance variables (if defined)
 | 
 |  __weakref__ = <attribute '__weakref__' of 'concatenator' objects>
 |      list of weak references to the object (if defined)

The help refers to concatenator, presumably r_ is a synonym, but that 
name is not
available to the user:
 >>> numpy.concatenator
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
AttributeError: 'module' object has no attribute 'concatenator'
 >>>

If r_ is a class, couldn't it have have a more mnemonic name and, in the 
usual
Python style, start with an upper case letter?

help(numpy.r_.__init__)
Help on method __init__ in module numpy.lib.index_tricks:

__init__(self, axis=0, matrix=False) unbound 
numpy.lib.index_tricks.concatenator method

 >>>

Colin W.

Re[2]: [Numpy-discussion] Matlab page on scipy wiki

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

On Fri, 10 Feb 2006, Stefan van der Walt apparently wrote: 
> In Octave that would be 
> [1, 0, 1:4, 0, 1] 
> Using numpy we currently do 
> concatenate([[1, 0], arange(1,5), [0, 1]]) or 
> vstack(...) 

numpy.r_[1,0,range(1,5),0,1]

fwiw,
Alan Isaac