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

[Numpy-discussion] segfault when calling PyArray_DescrFromType

[Martin W. <mar...@gm...>]

Hi list,

I'm trying to build an C extension, which uses arrays. It builds, and I can 
import it  from python, but the very first call to a numpy function

    ea = (PyObject *) PyArray_DescrFromType (PyArray_INT);

gives me a segfault.

I have absolutely no clue, but

nm -l mymodule.so | grep rray

gives

000026a0 b 
PyArray_API  /usr/lib/python2.4/site-packages/numpy/core/include/numpy/__multiarray_api.h:316

and this line reads

static void **PyArray_API=NULL;

which looks suspicious to me. Something wrong with my setup.py?

Any suggestions?

Regards, Martin.

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

[Darren D. <dd...@co...>]

On Thursday 09 February 2006 3:21 am, Bill Baxter wrote:
> I added some content to the "NumPy/SciPy for Matlab users" page on the
> scipy wiki.
>
> But my knowledge of NumPy/SciPy isn't sufficient to fill in the whole chart
> of equivalents that I laid out.
> If folks who know both could browse by and maybe fill in a blank or two,
> that would be great.  I think this will be a helpful "getting started" page
> for newbies to NumPy coming from matlab, like me.  One of the most
> frustrating things is when you sit down and can't figure out how to do the
> most basic things that do in your sleep in another environment (like making
> a column vector).  So hopefully this page will help.
>
> The URL is : http://www.scipy.org/Wiki/NumPy_for_Matlab_Addicts

I filled in a couple of places, where I could. 


I have a question about upcasting related to this example:

a with elements less than 0.5 zeroed out:
Matlab: a .* (a>0.5)
NumPy: where(a<0.5, 0, a)
	
I think numpy should be able to do a*a>0.5 as well, but instead one must do: 
a*(a>0.5).astype('i')

Is it desireable to upcast bools in this case? I think so, one could always 
recover the current behavior by doing:
(a*(a>0.5)).astype('?')

Darren

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

[Matthew B. <mat...@gm...>]

Hi Bill,

On 2/9/06, Bill Baxter <wb...@gm...> wrote:
> I added some content to the "NumPy/SciPy for Matlab users" page on the sc=
ipy
> wiki.

Thanks a lot for doing this.  Did you see this excellent reference?=20
Maybe it would be useful to combine effort in some way?

http://www.37mm.no/matlab-python-xref.html

Best,

Matthew

[Numpy-discussion] Matlab page on scipy wiki

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

I added some content to the "NumPy/SciPy for Matlab users" page on the scip=
y
wiki.

But my knowledge of NumPy/SciPy isn't sufficient to fill in the whole chart
of equivalents that I laid out.
If folks who know both could browse by and maybe fill in a blank or two,
that would be great.  I think this will be a helpful "getting started" page
for newbies to NumPy coming from matlab, like me.  One of the most
frustrating things is when you sit down and can't figure out how to do the
most basic things that do in your sleep in another environment (like making
a column vector).  So hopefully this page will help.

The URL is : http://www.scipy.org/Wiki/NumPy_for_Matlab_Addicts

Thanks,
Bill Baxter

Re: [Numpy-discussion] newunicode branch started to fix unicode to always be UCS4

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

Travis Oliphant wrote:

>
> I've started a branch on SVN to fix the unicode implementation in 
> NumPy so that internally all unicode arrays use UCS4.  When a scalar 
> is obtained it will be the Python unicode scalar and the required 
> conversions (and data-copying) will be done.
> If anybody would like to help the branch is
>
Well, it turned out not to be too difficult.  It is done.   All Unicode 
arrays are now always 4-bytes-per character in NumPy.   The length is 
specified in terms of characters (not bytes).  This is different than 
other types, but it's consistent with the use of Unicode as characters.

The array-scalar that a unicode array produces inherits directly from 
Python unicode type which has either 2 or 4 bytes depending on the build.

On narrow builds where Python unicode is only 2-bytes, the 4-byte 
unicode is converted to 2-byte using surrogate pairs.  

There may be lingering bugs of course, so please try it out and report 
problems.

-Travis

Re: [Numpy-discussion] arange(start, stop, step) and floating point (Ticket #8)

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

Sasha wrote:

>On 2/8/06, Tim Hochberg <tim...@co...> wrote:
>  
>
>>Sasha wrote:
>>Isn't that bad numerically? That is, isn't (n*step) much more accurate
>>than (step + step + ....)?
>>    
>>
>
>It does not matter whether n*step is more accurate than step+...+step.
> As long as arange uses stop+=step loop to fill in the values, the
>last element may exceed stop even if start + length*step does not. 
>One may argue that filling with start + i*step is more accurate, but
>that will probably be much slower (even than my O(N) algorithm).
>
>  
>
>>It also seems needlessly inefficient;
>>    
>>
>I proposed O(N) algorithm just to counter Robert's argument that it is
>not possible to ensure the invariant.  On the other hand I don't think
>it is that bad - I would expect the length computing loop to be much
>faster than the main loop that involves main memory.
>
>  
>
>>you
>>should be able to to it in at most a few steps:
>>
>>length = (stop - start)/step
>>while length * step < stop:
>>    length += 1
>>while length * step >= stop:
>>   length -= 1
>>
>>Fix errors, convert to C and enjoy. It should normally take only a few
>>tries to get the right N.
>>    
>>
>
>This will not work (even if you fix the error of missing start+ in the
>conditions :-): start + length*step < stop  does not guarantee than
>start + step + ... + step < stop.
>  
>

Indeed. When I first was thinking about this, I assumed that arange was 
computed as essentially start + range(0, n)*step. Not, as an 
accumulation. After I actually looked at what arange did, I failed to 
update my thinking -- my mistake, sorry.

>  
>
>>I see that the internals of range use repeated adding to make the range.
>>I imagine that is why you proposed the repeated adding. I think that
>>results in error that's on the order of length ULP, while multiplying
>>would result in error on the order of 1 ULP. So perhaps we should fix
>>XXX_fill to be more accurate if nothing else.
>>
>>    
>>
>
>I don't think accuracy of XXX_fill for fractional steps is worth improving.
>  
>
I would think that would depend on (a) how hard it is to do (I think the 
answer to that is not hard at all), (b) how much of a performance impact 
would it have (some, probably, since one's adding a multiply, and (c) 
how much one values the minor increase in accuracy versus whatever 
performance impact this might have. The change I was referring to would 
look more or less like:

static void
FLOAT_fill(float *buffer, intp length, void *ignored)
{
    intp i;   
    float start = buffer[0];
    float delta = buffer[1];
    delta -= start;
    /*start += (delta + delta); */
    buffer += 2;
    for (i=2; i<length; i++, buffer++) {
        *buffer = start + i*delta;
       /** buffer = start; */
       /* start += delta; */
    }
}


 [I will note that performance doesn't seem to have been of overriding 
concern in writing XXX_fill, since unless I'm mistaken, there's an 
integer add in the inner loop that could be optimized out (buffermax = 
buffer+length could be calculated and used as the loop boundary; i could 
be dropped entirely -- of course doing that would make the 
multiplication based solution look that much worse performance wise].

>In the cases where accuracy matters, one can always use integral step
>and multiply the result by a float.  However, if anything is done to
>that end, I would suggest to generalize XXX_fill functions to allow
>accumulation be performed using a different type similarly to the way
>op.reduce and op.accumulate functions us their (new in numpy) dtype
>argument.
>  
>
Really? That seems unnecessarily baroque.

>>>3. Change arange to ensure that arange(..., stop, ...)[-1] < stop.
>>>
>>>      
>>>
>>I see that Travis has vetoed this in any event, but perhaps we should
>>fix up the fill functions to be more accurate and maybe most of the
>>problem would just magically go away.
>>    
>>
>
>The more I think about this, the more I am convinced that using arange
>with a non-integer step is a bad idea.  Since making it illegal is not
>an option, I don't see much of a point in changing exactly how bad it
>is. Users who want fractional steps should just be educated about
>linspace.
>  
>
Are integer steps with noninteger start and stop safe?  For that matter 
are integer steps safe for sufficiently large, floating point, but 
integral, values of start and stop. It seems like they might well not 
be, but I haven't thought it through very well. I suppose that even if 
this was technically unsafe, in practice it would probably be pretty 
hard to get into trouble in that way.

Regards,

-tim

Re: [Numpy-discussion] arange(start, stop, step) and floating point (Ticket #8)

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

On 2/8/06, Tim Hochberg <tim...@co...> wrote:
> Sasha wrote:
> Isn't that bad numerically? That is, isn't (n*step) much more accurate
> than (step + step + ....)?

It does not matter whether n*step is more accurate than step+...+step.
 As long as arange uses stop+=3Dstep loop to fill in the values, the
last element may exceed stop even if start + length*step does not.=20
One may argue that filling with start + i*step is more accurate, but
that will probably be much slower (even than my O(N) algorithm).

> It also seems needlessly inefficient;
I proposed O(N) algorithm just to counter Robert's argument that it is
not possible to ensure the invariant.  On the other hand I don't think
it is that bad - I would expect the length computing loop to be much
faster than the main loop that involves main memory.

> you
> should be able to to it in at most a few steps:
>
> length =3D (stop - start)/step
> while length * step < stop:
>     length +=3D 1
> while length * step >=3D stop:
>    length -=3D 1
>
> Fix errors, convert to C and enjoy. It should normally take only a few
> tries to get the right N.

This will not work (even if you fix the error of missing start+ in the
conditions :-): start + length*step < stop  does not guarantee than
start + step + ... + step < stop.

> I see that the internals of range use repeated adding to make the range.
> I imagine that is why you proposed the repeated adding. I think that
> results in error that's on the order of length ULP, while multiplying
> would result in error on the order of 1 ULP. So perhaps we should fix
> XXX_fill to be more accurate if nothing else.
>

I don't think accuracy of XXX_fill for fractional steps is worth improving.
In the cases where accuracy matters, one can always use integral step
and multiply the result by a float.  However, if anything is done to
that end, I would suggest to generalize XXX_fill functions to allow
accumulation be performed using a different type similarly to the way
op.reduce and op.accumulate functions us their (new in numpy) dtype
argument.

> >3. Change arange to ensure that arange(..., stop, ...)[-1] < stop.
> >
> I see that Travis has vetoed this in any event, but perhaps we should
> fix up the fill functions to be more accurate and maybe most of the
> problem would just magically go away.

The more I think about this, the more I am convinced that using arange
with a non-integer step is a bad idea.  Since making it illegal is not
an option, I don't see much of a point in changing exactly how bad it
is. Users who want fractional steps should just be educated about
linspace.

Re: [Numpy-discussion] creating column vectors

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

Sven Schreiber wrote:
>> Take a little time to get used to it, and you'll become very glad
>> that numpy works the way it does, rather than like Matlab.

> I bet you won't be very successful in
> the Gauss et al. camp with that marketing slogan...

It's not a marketing slogan. It's a suggestion for someone that has 
already decided to learn Python+Numpy.

Whenever you use something new, you shouldn't try to use it the same way 
that you use a different tool. We say the same thing to people that try 
to write Python like it's C.

> does not sound very pythonic; the "you'll get used to it, and trust me,
> even if you don't understand it now, it's great afterwards"-approach
> sounds more like the pre-python era (you may insert a language of your
> choice here ;-)

The difference is that you really will like it better, not just get used 
to it.

> I don't see why numpy cannot preserve the features that are important to
> you (and which I know nothing about) and at the same time make life more
> intuitive and easier for 2d-dummies like myself -- 

Because a matrix is not the same as an array. A matrix can be 
represented by a 2-d matrix, but a matrix can not represent an arbitrary 
n-d array (at  least not easily!). If you're really doing a lot of 
linear algebra, then you want to use the matrix package. I haven't used 
it, but it should have a way to easily create a column vector for you.

Python (and NumPy) is a much more powerful and flexible language than 
Matlab (Or gauss, or IDL, or...) Once you learn to use it, you will be 
happy you did. I was a major Matlab fan a while back. I spend 5 years in 
grad school using it, and did my entire dissertation with it. I've 
recently been helping a friend with some Matlab code, and I find it 
painful to use. You'll see.

Or was that too smug?

-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] creating column vectors

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

Thanks.  To be honest I wrote that page in the middle of composing my email
to Chris just so something would be there when people clicked on the link.
:-)    I think my 1-minute draft of that chart needs a different
organization, because, as you point out, things are different in NumPy
depending on whether you have a Matrix or an Array.  Maybe it should be a
3-way comparison of Matlab / NumPy Array / NumPy Matrix instead.

--bb

On 2/9/06, Sven Schreiber <sve...@gm...> wrote:
>
> Bill Baxter schrieb:
>
> >
> > If you can spare the time, I'd love to hear you elaborate on that.  Wha=
t
> > are some specifics that make you say 'thank goodness for numpy!'?  If
> > you have some good ones, I'd like to put them up on
> > http://www.scipy.org/NumPy_for_Matlab_Addicts (of course you're more
> > than welcome to cut out the middle man and just post them directly on
> > the wiki there yourself...)
> >
> > --Bill Baxter
>
> Just one addition/correction for your page (sorry won't do it myself,
> all those different wiki engines/syntaxes...): a * b is only
> element-wise if a and b are not numpy-matrices, afaik that's the main
> reason why it's so important to know whether you're working with
> numpy-arrays or with its subclass numpy-matrix.
> -sven
>
>
> -------------------------------------------------------
> 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?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] creating column vectors

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

Bill Baxter schrieb:

> 
> If you can spare the time, I'd love to hear you elaborate on that.  What
> are some specifics that make you say 'thank goodness for numpy!'?  If
> you have some good ones, I'd like to put them up on
> http://www.scipy.org/NumPy_for_Matlab_Addicts (of course you're more
> than welcome to cut out the middle man and just post them directly on
> the wiki there yourself...)
> 
> --Bill Baxter

Just one addition/correction for your page (sorry won't do it myself,
all those different wiki engines/syntaxes...): a * b is only
element-wise if a and b are not numpy-matrices, afaik that's the main
reason why it's so important to know whether you're working with
numpy-arrays or with its subclass numpy-matrix.
-sven

Re: [Numpy-discussion] arange(start, stop, step) and floating point (Ticket #8)

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

Tim Hochberg wrote:

>>
>
>
> I see that Travis has vetoed this in any event, but perhaps we should 
> fix up the fill functions to be more accurate and maybe most of the 
> problem would just magically go away.


To do something different than arange has always done we need a new 
function, not change what arange does and thus potentially break lots of 
code.

How do you propose to make the fill funtions more accurate?   I'm 
certainly willing to see improvements there.

-Travis

Re: [Numpy-discussion] creating column vectors

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

Christopher Barker schrieb:

> 
> numpy is not a Matlab clone, nor should it be. That's exactly why I use
> it! Take a little time to get used to it, and you'll become very glad
> that numpy works the way it does, rather than like Matlab.
> 

well, I have taken that time because I was already into python (glue
everyting together, you know), but I bet you won't be very successful in
the Gauss et al. camp with that marketing slogan... also, your statement
does not sound very pythonic; the "you'll get used to it, and trust me,
even if you don't understand it now, it's great afterwards"-approach
sounds more like the pre-python era (you may insert a language of your
choice here ;-)

I don't see why numpy cannot preserve the features that are important to
you (and which I know nothing about) and at the same time make life more
intuitive and easier for 2d-dummies like myself -- in a lot of ways,
it's already accomplished, I'd say it just needs the finishing touch.

cheers,
sven

Re: [Numpy-discussion] creating column vectors

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

On 2/9/06, Christopher Barker <Chr...@no...> wrote:
>
>
> numpy is not a Matlab clone, nor should it be. That's exactly why I use
> it! Take a little time to get used to it, and you'll become very glad
> that numpy works the way it does, rather than like Matlab.




If you can spare the time, I'd love to hear you elaborate on that.  What ar=
e
some specifics that make you say 'thank goodness for numpy!'?  If you have
some good ones, I'd like to put them up on
http://www.scipy.org/NumPy_for_Matlab_Addicts (of course you're more than
welcome to cut out the middle man and just post them directly on the wiki
there yourself...)

--Bill Baxter

Re: [Numpy-discussion] arange(start, stop, step) and floating point (Ticket #8)

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

On 2/8/06, Travis Oliphant <oli...@ee...> wrote:
> +5
>
> We can't really do anything else at this point since this behavior has
> been what is with us for a long time.

I guess this closes the dispute.  I've commited a new docstring to SVN.

Re: [Numpy-discussion] arange(start, stop, step) and floating point (Ticket #8)

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

Sasha wrote:

>On 2/8/06, Robert Kern <rob...@gm...> wrote:
>  
>
>> ...
>>arange() does allow for fractional steps unlinke range(). You may fix the
>>docstring if you like. However, I don't think it is possible to ensure that
>>invariant in the face of floating point. That's why we have linspace().
>>    
>>
>
>There is certainly a way to ensure that arange(..., stop, ...)[-1] <
>stop in the face of floating point -- just repeat start += step with
>start in a volatile double variable until it exceeds stop to get the
>length of the result.   There might be an O(1) solution as well, but
>it may require some assumptions about the floating point unit.
>  
>
Isn't that bad numerically? That is, isn't (n*step) much more accurate 
than (step + step + ....)? It also seems needlessly inefficient; you 
should be able to to it in at most a few steps:

length = (stop - start)/step
while length * step < stop:
    length += 1
while length * step >= stop:
   length -= 1

Fix errors, convert to C and enjoy. It should normally take only a few 
tries to get the right N.

I see that the internals of range use repeated adding to make the range. 
I imagine that is why you proposed the repeated adding. I think that 
results in error that's on the order of length ULP, while multiplying 
would result in error on the order of 1 ULP. So perhaps we should fix 
XXX_fill to be more accurate if nothing else.

>In any case, I can do one of the following depending on a vote:
>
>1 (default). Document length=ceil((stop - start)/step) in the arange docstring
>  
>
That has the virtue of being easy to explain.

>2. Change arange to be a fast equivalent of array(range(start, stop,
>step), dtype).
>  
>
No thank you.

>3. Change arange to ensure that arange(..., stop, ...)[-1] < stop.
>  
>


I see that Travis has vetoed this in any event, but perhaps we should 
fix up the fill functions to be more accurate and maybe most of the 
problem would just magically go away.

-tim

Re: [Numpy-discussion] Constructing array from generator expression/iterator

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

Array constructor does not support arbitrary iterables.  For example:

>>> array(iter([1,2,3]))
array(<listiterator object at 0xf735c5cc>, dtype=3Dobject)

In Numeric, it was not possible to try to iterate throught the object
in array constructor because rank-0 arrays were iterable and would
lead to infinite recursion.  Since this problem was fixed in numpy, I
don't see much of a problem in implementing such feature.



On 2/8/06, Stephan Tolksdorf <and...@gm...> wrote:
> Hi
>
> I'm new to Numpy and just stumbled over the following problem in Numpy
> 0.9.4:
>
> array(x**2 for x in range(10))
>
> does not return what one (me) would suspect, i.e.
>
> array([x**2 for x in range(10)])
>
> Is this expected behavior?
>
> Stephan
>
>
>
>
> -------------------------------------------------------
> 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] arange(start, stop, step) and floating point (Ticket #8)

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

Sasha wrote:

>On 2/8/06, Robert Kern <rob...@gm...> wrote:
>  
>
>> ...
>>arange() does allow for fractional steps unlinke range(). You may fix the
>>docstring if you like. However, I don't think it is possible to ensure that
>>invariant in the face of floating point. That's why we have linspace().
>>    
>>
>
>There is certainly a way to ensure that arange(..., stop, ...)[-1] <
>stop in the face of floating point -- just repeat start += step with
>start in a volatile double variable until it exceeds stop to get the
>length of the result.   There might be an O(1) solution as well, but
>it may require some assumptions about the floating point unit.
>
>In any case, I can do one of the following depending on a vote:
>
>1 (default). Document length=ceil((stop - start)/step) in the arange docstring
>  
>
+5

We can't really do anything else at this point since this behavior has 
been what is with us for a long time.

-Travis

Re: [Numpy-discussion] Constructing array from generator expression/iterator

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

Stephan Tolksdorf wrote:

> Hi
>
> I'm new to Numpy and just stumbled over the following problem in Numpy 
> 0.9.4:
>
> array(x**2 for x in range(10))
>
> does not return what one (me) would suspect, i.e.
>
> array([x**2 for x in range(10)])
>
> Is this expected behavior?


The array constructor does not current "understand" generators objects.  
It only understands sequence objects.   It could be made to work but is 
based on code written long before there were generators.  

So, instead you get a 0-d Object-array containing the generator.

Just use list comprehensions instead.

-Travis

Re: [Numpy-discussion] arange(start, stop, step) and floating point (Ticket #8)

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

On 2/8/06, Robert Kern <rob...@gm...> wrote:
>  ...
> arange() does allow for fractional steps unlinke range(). You may fix the
> docstring if you like. However, I don't think it is possible to ensure th=
at
> invariant in the face of floating point. That's why we have linspace().

There is certainly a way to ensure that arange(..., stop, ...)[-1] <
stop in the face of floating point -- just repeat start +=3D step with
start in a volatile double variable until it exceeds stop to get the
length of the result.   There might be an O(1) solution as well, but
it may require some assumptions about the floating point unit.

In any case, I can do one of the following depending on a vote:

1 (default). Document length=3Dceil((stop - start)/step) in the arange docs=
tring
2. Change arange to be a fast equivalent of array(range(start, stop,
step), dtype).
3. Change arange to ensure that arange(..., stop, ...)[-1] < stop.

Please vote on 1-3.

-- sasha

[Numpy-discussion] Constructing array from generator expression/iterator

[Stephan T. <and...@gm...>]

Hi

I'm new to Numpy and just stumbled over the following problem in Numpy 
0.9.4:

array(x**2 for x in range(10))

does not return what one (me) would suspect, i.e.

array([x**2 for x in range(10)])

Is this expected behavior?

Stephan

[Numpy-discussion] newunicode branch started to fix unicode to always be UCS4

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

I've started a branch on SVN to fix the unicode implementation in NumPy 
so that internally all unicode arrays use UCS4.  When a scalar is 
obtained it will be the Python unicode scalar and the required 
conversions (and data-copying) will be done. 

If anybody would like to help the branch is

http://svn.scipy.org/svn/numpy/branches/newunicode

-Travis

[Numpy-discussion] arange(start, stop, step) and floating point (Ticket #8)

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

Sasha (from the ticket comments):
"""I would prefer if arange, would do what range does and round step, possibly
with a warning for fractional steps. In other words, arange(start, stop, step,
dtype) should be an optimized version of array(range(start, stop, step), dtype).
If this is not acceptable, I think arange(start,stop,step)[-1] < stop should be
an invariant and floating point issues should be properly addressed.
"""

arange() does allow for fractional steps unlinke range(). You may fix the
docstring if you like. However, I don't think it is possible to ensure that
invariant in the face of floating point. That's why we have linspace().

-- 
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] creating column vectors

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

Stefan van der Walt wrote:
> This is probably a silly question, but what is the best way of
> creating column vectors?

I do this:
 >>> import numpy as N
 >>> v = N.arange(10)
 >>> v
array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9])
 >>> v.shape = (-1,1)
 >>> v
array([[0],
        [1],
        [2],
        [3],
        [4],
        [5],
        [6],
        [7],
        [8],
        [9]])



>  'arange' always returns a row vector

no, it doesn't, it returns a 1-dimensional vector.

> Numpy-masters: Is there a way to set a user- or project-specific config
> switch or something like that to always get matrix results when dealing
> with 1d and 2d arrays? I think that would make numpy much more
> attractive for people like Stefan and me coming from the 2d world.

numpy is not a Matlab clone, nor should it be. That's exactly why I use 
it! Take a little time to get used to it, and you'll become very glad 
that numpy works the way it does, rather than like Matlab.

-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] creating column vectors

[Stefan v. d. W. <st...@su...>]

On Wed, Feb 08, 2006 at 06:44:54PM +0100, Sven Schreiber wrote:
> Gerard Vermeulen schrieb:
>=20
> >> mat(arange(1,10)).transpose()
> >>
> >> works, but seems a bit long-winded (in comparison to MATLAB's [1:10]=
').
>=20
> >=20
> > What about this?
> >=20
> > arange(1, 10)[:, NewAxis]
> >=20
>=20
> The numpy-book beats both of us (see my previous post) in terms of
> minimal typing overhead by suggesting r_[1:10,'c'] which produces a
> matrix type, very nice.

Thanks for your effort, that's exactly what I was looking for!  Time
to get hold of that book...

Cheers
St=E9fan

Re: [Numpy-discussion] creating column vectors

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

Gerard Vermeulen schrieb:

>> mat(arange(1,10)).transpose()
>>
>> works, but seems a bit long-winded (in comparison to MATLAB's [1:10]').

> 
> What about this?
> 
> arange(1, 10)[:, NewAxis]
> 

The numpy-book beats both of us (see my previous post) in terms of
minimal typing overhead by suggesting r_[1:10,'c'] which produces a
matrix type, very nice.
Compared to [1:10]', that's quite good already...
-sven