Re: [Numpy-discussion] numpy release

[Alan G Isaac]

On Wed, 23 Apr 2008, Bill Spotz apparently wrote:
> Gains: (1) non-scalar extractions from linear algebra 
> objects ARE and BEHAVE like linear algebra objects;

I believe this is not a gain, since there is a standard way to
do this now, which would remain under the second proposal.


> (2) a clear path for dense and sparse matrices to have the 
> same (or at least analogous) interfaces. 

This may prove true.  I'm agnostic.
What actually turns on this?
I believe it is the following:
if iterating over a sparse matrix yields sparse vectors
that behave like a sparse matrix, then iterating over a
matrix should return a vector that behaves like a matrix.
But I have not seen any detailed discussion of this design
issue.  E.g., iterating over a sparse matrix could yield
instead a sparse object that behaves like a 1d array.

I should add that if the first approach is taken,
I agree that it is natural for these "vectors" to
inherit from matrix.

With respect to the matrix object, my only "objection" has 
been that I'd like to hear someone state clearly what 
functionality is gained by following the more complex first 
proposal instead of the second proposal.  The reason: the 
cost of complexity should be justified by a gain in 
functionality.  It *may* be that the link between the 
behavior of matrices and that of sparse matrices is where 
the gain manifests, but that is not yet clear to me.

> Unless I'm misremembering, Alan is the only one who has 
> expressed concerns and he is willing to concede to the 
> design if others agree. 

I'm in no position to concede or not concede anything,
since I am not writing code, but my core concerns
will be met by either proposal.

Thanks!
Alan



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] [SciPy-dev] stats.mstats & stats.mmorestats

[Jarrod Millman]

On Mon, Apr 14, 2008 at 11:55 AM, Pierre GM <[EMAIL PROTECTED]> wrote:
>  I just committed two modules (and the corresponding unittests) to the
>  scipy.stats package. Feel free to test and send some feedback. These packages
>  are meant to replace numpy.ma.mstats and numpy.ma.morestats: may I go and
>  erase those packages from the numpy SVN ?

Yes, please go ahead and remove numpy.ma.mstats and
numpy.ma.morestats.  Also feel free to close:
http://projects.scipy.org/scipy/numpy/ticket/753

Thanks,

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numpy release

[Timothy Hochberg]

[CHOP]

The proposals thus far don't address two of the major issues I have with the
matrix class:

   1. The matrices and arrays should become more alike if possible and
   should share more of the same code base. From what I've seen, the people who
   write the code (for numpy) don't actually use matrices, they use the arrays.
   This is one of the main reasons matrices still have so many problems IMO; if
   one of the main developers were using them, they'd never have put up with
   it. This may be changing to some extent now, but the more we can make
   matrices and arrays share code and interface, the happier we'll be. None of
   the new rules strike me as helping in this arena and may in fact hurt.
   Again, IMO.
   2. This doesn't support the concept of arrays of matrices/vectors, which
   is one thing I've always wanted out of the matrix class. For example it
   would be nice to be able to spell: 'A' is a 1D array of matrices (3D)
   overall, 'B' is a 1D array of vectors (3D) overall, matrix multiply them
   together, yielding a 1D array of matrices (3D) overall. I have frequently
   run into various permutations of this problem. You can fake it with loops
   over dot, but the efficiency is very bad for small arrays, plus it's ugly.

I have lot's of vague ideas on this subject that have been floating around
my head for the past couple of years. Basically, I think the way to go is to
probably add some meta information to arrays that make them look a little
bit more like tensors. Then, if one is careful (and things work out as I
hope) matrices could be implemented as a thin layer on top of arrays. Or
perhaps, if we are very lucky, done away with altogether.

Anyway, that's all very vague and hand-wavey; if I can spring free some
time, I'll try to write something up in the not too distant future. I'm glad
to see that any major changes are being put off for a while: I think we
should be able to do better than just patch up the old matrix class.

-tim
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] access ndarray in C++

[Andreas Klöckner]

On Mittwoch 23 April 2008, Christopher Barker wrote:
> What's the status of the Boost array object? maintained? updated for
> recent numpy?

The numeric.hpp included in Boost.Python is a joke. It does not use the native 
API.

PyUblas [1] fills this gap, by allowing you to use Boost.Ublas on the C++ side 
and Numpy on the Python side. It is somewhat like what Hoyt describes, except 
for a different environment. Here's a table:

   | Hoyt   | Andreas
---++
C++ Matrix Library | Blitz++| Boost.Ublas
Wrapper Generator  | Weave  | Boost.Python
Wrapper| w_wrap.tgz | PyUblas

:) Sorry, that was too much fun to pass up.

[1] http://tiker.net/doc/pyublas/index.html

> > - sip [2]. Used for PyQt.
>
> Any numpy-specific stuff for sip?

Not as far as I'm aware. In fact, I don't know of any uses of sip outside of 
Qt/KDE-related things.

Andreas


signature.asc
Description: This is a digitally signed message part.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numpy release

[Stéfan van der Walt]

2008/4/23 Christopher Barker <[EMAIL PROTECTED]>:
>  Aside from the fact that someone needs to write the code -- why don't
>  people like the row/column vector idea? It just feels so natural to me:

I wrote most of the code last week (see the previous thread on the
mailing list for a patch).  It currently only implements Vector (not
RowVector and ColumnVector), but those two would be easy to add.

Cheers
Stéfan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Fixing/breaking histogram for numpy 1.1

[Jarrod Millman]

On Wed, Apr 23, 2008 at 3:20 PM, David Huard <[EMAIL PROTECTED]> wrote:
> I haven't found a way to fix histogram reliably without breaking the current
> behavior. There is a patch attached to the ticket, if the decision is to
> break histogram.

+1
As far as I am concerned it seems like histogram is all ready broken,
so fixing it should be more important than retaining backward
compatibility.  Is anyone opposed to David's patch:
http://projects.scipy.org/scipy/numpy/ticket/605

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numpy release

[Bill Spotz]

On Apr 23, 2008, at 3:55 PM, Christopher Barker wrote:

>> For matrix x, should x[0].A[0] == x.A[0][0]? That is, should the  
>> array
>> attribute of a Row Vector or Column Vector be 1d?
>
> Absolutely -- a vector is a 1-d array. The only difference here is  
> that
> we can preserve the concept of a row vs. a column vector -- key to
> linear algebra, which is the whole point of the Matrix class. I'd be
> just as happy if a RowVector an ColumnVector were a more unique object
> -- a 1-d array with the operation overloaded, rather than a (1,n) or
> (n,1) matrix, but I understand that would be more work.

The way I envisioned this was that RowVector and ColumnVector would  
inherit from Matrix, so that you would inherit all of the Matrix  
functionality.  They would just be special cases where ncol=0 or  
nrow=0, allowing single indexing.

If Matrix-Matrix multiplication is implemented properly, then the Row/ 
ColumnVector multiplication operators should automatically work.

>> Inconsistency in the indexing style for producing row vectors and
>> column vectors
>
> not really:

I agree with Alan here.  M[i] returns a RowVector, but there is no  
corresponding single index way to retrieve a ColumnVector (unless we  
want to use __call__() to make M(j) return a ColumnVector . . . but  
this is highly unintuitive.)

Thinking out loud: we could support

 M[i=#]   return a RowVector
 M[j=#]   return a ColumnVector
 M[#] equivalent to M[i=#]

> The fact that there is another way to get a row vector: M[i] is a  
> bonus.

Except that the behavior of M[i] is one of the driving issues of the  
conversation.

>> Loss of a standard way to extract a row or a column as a submatrix
>> (rather than a vector)

If Row/ColumnVector inherit from Matrix, then this is not strictly  
true.  There is no reason that these classes could not support [i,j]  
indexing, which means they would BE Matrices (inheritence) and they  
would BEHAVE like Matrices (except for V[i][j] . . . argh).

>> No clear gain in functionality over the simpler proposal 2.

Gains: (1) non-scalar extractions from linear algebra objects ARE and  
BEHAVE like linear algebra objects; (2) a clear path for dense and  
sparse matrices to have the same (or at least analogous) interfaces.

> Aside from the fact that someone needs to write the code -- why don't
> people like the row/column vector idea? It just feels so natural to  
> me:

Unless I'm misremembering, Alan is the only one who has expressed  
concerns and he is willing to concede to the design if others agree.

> A matrix is a 2-d array with some functionality overloaded to make it
> convenient to do linear algebra.
>
> A vector is a 1-d array with some functionality overloaded to make it
> convenient to do linear algebra.

Again, I would argue for Vectors inheriting from Matrix.  I would make  
the case based on code reuse and elegance, although these might be  
overridden by some other concern.

> And yes, maybe this will lead to tensors some day!

Don't see why not.

> Another couple questions: -- would there be constructors for vectors?
>
> np.RowVector((1,2,3,4,5))
> np.ColumnVector((1,2,3,4,5,6))

Yes.  They should be full-fledged classes, although with inheriting  
from Matrix, the implementation should be relatively small.  What about

np.Matrix()
np.Matrix()

?

> and would:
> A_RowVector.T == A_ColumnVector

Yes.

> All the example code I've seen during this discussion have been  
> examples
> of iterating and indexing -- not one has actually been linear  
> algebra --
> perhaps we should see some of those before making any decisions.


Right.  I have generally thought about this in the context of, say, a  
Krylov-space iterative method, and what that type of interface would  
lead to the most readable code.

** Bill Spotz  **
** Sandia National Laboratories  Voice: (505)845-0170  **
** P.O. Box 5800 Fax:   (505)284-0154  **
** Albuquerque, NM 87185-0370Email: [EMAIL PROTECTED] **






___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numpy release

[Christopher Barker]

Alan Isaac wrote:
> I have updated http://www.scipy.org/MatrixIndexing>
> to reflect this change (and its provisional status).

Thanks for writing this up -- it really clarifies what's being proposed. 
A few comments on that write up:

 > For matrix x, should x[0].A[0] == x.A[0][0]? That is, should the array
 > attribute of a Row Vector or Column Vector be 1d?

Absolutely -- a vector is a 1-d array. The only difference here is that 
we can preserve the concept of a row vs. a column vector -- key to 
linear algebra, which is the whole point of the Matrix class. I'd be 
just as happy if a RowVector an ColumnVector were a more unique object 
-- a 1-d array with the operation overloaded, rather than a (1,n) or 
(n,1) matrix, but I understand that would be more work.

 > Deviations from the behavior of ndarrays. Specifically, iteration over
 > a matrix will not yield 1d NumPy arrays.

Why should they? indexing a nested list gives a different result than 
indexing an ndarray, etc, etc, etc. The POINT of matrixes is that they 
are different! This proposal makes them a little more similar to 
ndarrays than the old behavior (always returning a matrix).

 > Inconsistency in the indexing style for producing row vectors and
 > column vectors

not really:

row vector: M[i,:]
column vector: M[:,i]

The fact that there is another way to get a row vector: M[i] is a bonus. 
I once proposed making M[i] raise an exception for the sake of enforcing 
consistency, but no one liked that!

 > Loss of a standard way to extract a row or a column as a submatrix
 > (rather than a vector)

What's wrong with:

M[i:i+1, :] and M[:, i:i+1]

This is totally consistent with arrays (and other python sequences). 
Yes, it's a bit more awkward, but with the new vectors, it's also going 
to be needed far less.

 > No clear gain in functionality over the simpler proposal 2.

Well, I won't judge what's "clear" but I think this adds functionality. 
The concept of row and column vectors is a key part of linear algebra. 
Sure, you can model them as matrixes that happen to have only one row or 
one column, but that's what we had, but there seem to be real issues 
with use of that. Option (2), is "Let a Matrix be a container of 1d 
arrays.". Sounds simple, but do those arrays represent row or column 
vectors? Either would make sense. The proposal is for them to be row 
vectors, which is fine, but then if you want them to act like a row 
vectors, do you need to convert them back into matrices? Even if not, 
how do you get a column vector -- by indexing the current way, and 
getting a (n,1) matrix, so that now we have inconsistency between how 
row and column vectors are treated -- not a clean API.

And this is about a clean API for linear algebra -- otherwise, we'd just 
all use arrays (which many do!)

Aside from the fact that someone needs to write the code -- why don't 
people like the row/column vector idea? It just feels so natural to me:

A matrix is a 2-d array with some functionality overloaded to make it 
convenient to do linear algebra.

A vector is a 1-d array with some functionality overloaded to make it 
convenient to do linear algebra.

A scalar is the same in both contexts, so no need to change anything there.

And yes, maybe this will lead to tensors some day!

Another couple questions: -- would there be constructors for vectors?

np.RowVector((1,2,3,4,5))
np.ColumnVector((1,2,3,4,5,6))

and would:
A_RowVector.T == A_ColumnVector

I would think so.

One more note:

All the example code I've seen during this discussion have been examples 
of iterating and indexing -- not one has actually been linear algebra -- 
perhaps we should see some of those before making any decisions.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

[EMAIL PROTECTED]
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] "aligned" matrix / ctypes

[Anne Archibald]

On 23/04/2008, Zachary Pincus <[EMAIL PROTECTED]> wrote:
> Hi,
>
>  Thanks a ton for the advice, Robert! Taking an array slice (instead of
>  trying to set up the strides, etc. myself) is a slick way of getting
>  this result indeed.

It's worth mentioning that there was some discussion of adding an
allocator for aligned arrays. It got sidetracked into a discussion of
SSE support for numpy, but there are all sorts of reasons to want
aligned arrays in numpy, as this post demonstrates. Seeing as it's
just a few lines worth of pure python, is anyone interested in writing
an aligned_empty() for numpy?

Anne
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] "aligned" matrix / ctypes

[Robert Kern]

On Wed, Apr 23, 2008 at 4:26 PM, Zachary Pincus <[EMAIL PROTECTED]> wrote:
[ I wrote]
>  > To solve the initial alignment, you overallocate a 1D array by 3 bytes
>  > and find the offset from the allocated initial address which is
>  > correctly aligned.
>
>  Sorry -- I haven't had to ever concern myself with alignment before
>  this, so I'm not sure how to go about this step. Do I just look at the
>  raw pointer address and see what offset I need to give it to get it to
>  be divisible by four?

Yes.

-- 
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 mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] "aligned" matrix / ctypes

[Zachary Pincus]

Hi,

Thanks a ton for the advice, Robert! Taking an array slice (instead of  
trying to set up the strides, etc. myself) is a slick way of getting  
this result indeed.

>> I need to allocate a numpy array that I will then pass to a camera
>> driver (via ctypes) so that the driver can fill the array with  
>> pixels.
>> The catch is that the driver requires that rows of pixels start at 4-
>> byte boundaries.
>>
>> The sample C++ code given for allocating memory for this is (pixels
>> are unsigned shorts):
>>
>> // Two bytes for each pixel, then round
>> // up to the next multiple of four.
>> long width_bytes = ( ( 2 * width_pixels ) + 3 ) & -4;
>> long allocated_size = width_bytes * height;
>> unsigned char* image_data = new unsigned char[allocated_size];

> Note that the approach above doesn't ensure that the first row is
> correctly aligned. It just assumes that the allocator will always
> start a new block aligned at 4 bytes (which may be reasonable for the
> platforms you are targetting).

Hmm, good point. The SDK/example code is pretty flakey, so I bet they  
just make this assumption.

> To solve the initial alignment, you overallocate a 1D array by 3 bytes
> and find the offset from the allocated initial address which is
> correctly aligned.

Sorry -- I haven't had to ever concern myself with alignment before  
this, so I'm not sure how to go about this step. Do I just look at the  
raw pointer address and see what offset I need to give it to get it to  
be divisible by four?

> Slice out [:allocated_size] portion of this,
> .view() it as uint16, reshape it to
> (height,width_pixels+width_pixels%2), then slice out
> [:,:width_pixels].

Everything else makes good sense. Thanks again!

Zach

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] "aligned" matrix / ctypes

[Robert Kern]

On Wed, Apr 23, 2008 at 2:10 PM, Zachary Pincus <[EMAIL PROTECTED]> wrote:
> Hello all,
>
>  I need to allocate a numpy array that I will then pass to a camera
>  driver (via ctypes) so that the driver can fill the array with pixels.
>  The catch is that the driver requires that rows of pixels start at 4-
>  byte boundaries.
>
>  The sample C++ code given for allocating memory for this is (pixels
>  are unsigned shorts):
>
>  // Two bytes for each pixel, then round
>  // up to the next multiple of four.
>  long width_bytes = ( ( 2 * width_pixels ) + 3 ) & -4;
>  long allocated_size = width_bytes * height;
>  unsigned char* image_data = new unsigned char[allocated_size];
>  I could make an empty uint8 numpy array of the required shape
>  (allocated_size,) and adjust its dtype, shape, and strides to get the
>  desired result. I'd then feed the array's ctypes data attribute to the
>  driver to get filled in. Alternately I could allocate the data buffer
>  via ctypes and then construct an array around it.

Note that the approach above doesn't ensure that the first row is
correctly aligned. It just assumes that the allocator will always
start a new block aligned at 4 bytes (which may be reasonable for the
platforms you are targetting). Ignoring that issue for a moment, the
way to make sure that the rows are aligned is very similar to how you
do it in C. Round up the row length, make an array with the larger
dimensions (height,width_pixels+width_pixels%2), then slice out
[:,:width_pixels].

To solve the initial alignment, you overallocate a 1D array by 3 bytes
and find the offset from the allocated initial address which is
correctly aligned. Slice out [:allocated_size] portion of this,
.view() it as uint16, reshape it to
(height,width_pixels+width_pixels%2), then slice out
[:,:width_pixels].

>  Is either option better? How does one construct a numpy array around a
>  ctypes memory object? Can the array "take over" the memory management
>  for the buffer?

Whenever possible, I try to get numpy to do the allocating. That saves
many headaches. It is possible to do otherwise, but let's cover that
only if you need it.

-- 
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 mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numpy release

[Alan Isaac]

On Wed, 23 Apr 2008, Stéfan van der Walt wrote:
> Done in r5072. 

Much appreciated.
I have updated http://www.scipy.org/MatrixIndexing>
to reflect this change (and its provisional status).
Alan



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] access ndarray in C++

[Robert Kern]

On Wed, Apr 23, 2008 at 3:46 PM, Thomas Hrabe <[EMAIL PROTECTED]> wrote:
>  I have discovered a bug in ndarrayobject.h by the way. I do not know which
> numpy version we have installed here, but when compiling my c code with
> -pendantic I got this error:
>
>
> /home/global/python32/lib/python2.4/site-packages/numpy/core/include/numpy/ndarrayobject.h:192:
> error: comma at end of enumerator list
>
> /home/global/python32/lib/python2.4/site-packages/numpy/core/include/numpy/ndarrayobject.h:199:
> error: comma at end of enumerator list
>
> /home/global/python32/lib/python2.4/site-packages/numpy/core/include/numpy/ndarrayobject.h:211:
> error: comma at end of enumerator list
>
>  I have no access to the newest numpy version, so if anybody has, please fix
> it... (in case its not on full purpose for something...)

Fixed in SVN, 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 mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] access ndarray in C++

[Thomas Hrabe]

Finally!

http://scipy.org/Cookbook/C_Extensions
is a nice example. 
I have discovered a bug in ndarrayobject.h by the way. I do not know which 
numpy version we have installed here, but when compiling my c code with 
-pendantic I got this error:

/home/global/python32/lib/python2.4/site-packages/numpy/core/include/numpy/ndarrayobject.h:192:
 error: comma at end of enumerator list
/home/global/python32/lib/python2.4/site-packages/numpy/core/include/numpy/ndarrayobject.h:199:
 error: comma at end of enumerator list
/home/global/python32/lib/python2.4/site-packages/numpy/core/include/numpy/ndarrayobject.h:211:
 error: comma at end of enumerator list

I have no access to the newest numpy version, so if anybody has, please fix 
it... (in case its not on full purpose for something...)

Thank you and I bet I will post here again soon,
Thomas

-Original Message-
From: [EMAIL PROTECTED] on behalf of Christopher Barker
Sent: Wed 4/23/2008 1:15 PM
To: Discussion of Numerical Python
Subject: Re: [Numpy-discussion] access ndarray in C++
 
Christopher Barker wrote:
> Thomas Hrabe wrote:
> I'd poke around the wiki, and this mailing list archives, for more examples.

This may help:

http://scipy.org/Cookbook/C_Extensions

-CHB


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

[EMAIL PROTECTED]
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numpy release

[Stéfan van der Walt]

2008/4/23 Jarrod Millman <[EMAIL PROTECTED]>:
> On Wed, Apr 23, 2008 at 11:32 AM, Anne Archibald
>  <[EMAIL PROTECTED]> wrote:
>  >  > So ... fixing x[0][0] for matrices should wait
>  >  >  until 1.2.  Is that correct?
>  >
>  >  It seems to me that everyone agrees that the current situation is
>  >  broken, but there is considerable disagreement on what the correct fix
>  >  is. My inclination is to apply the minimal fix you suggest, with tests
>  >  and documentation, as a stopgap, and let the different factions sort
>  >  it out by discussion on the way to 1.2.
>
>  +1
>  That sound reasonable to me.

Done in r5072.

Cheers
Stéfan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numpy release

[David Huard]

2008/4/23, Stéfan van der Walt <[EMAIL PROTECTED]>:
>
> Hi Jarrod
>
> Of those tickets, the following are serious:
>
> http://projects.scipy.org/scipy/numpy/ticket/605 (a patch is
> available?, David Huard)
>   Fixing of histogram.
>

I haven't found a way to fix histogram reliably without breaking the current
behavior. There is a patch attached to the ticket, if the decision is to
break histogram.

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] access ndarray in C++

[Christopher Barker]

Christopher Barker wrote:
> Thomas Hrabe wrote:
> I'd poke around the wiki, and this mailing list archives, for more examples.

This may help:

http://scipy.org/Cookbook/C_Extensions

-CHB


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

[EMAIL PROTECTED]
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] access ndarray in C++

[Hoyt Koepke]

Just to add something from personal experience in case it's useful...

I write a lot of code that works on numpy arrays that goes between
python and c++ (too used to OO to stick with pure c). I've been using
scipy.weave to interface to blitz++ arrays in my c++ code.  The
blitz++ library has been wonderful in my experience -- it supports
arrays up to 11 dimensions, slicing, etc.  -- essentially a very
useful subset of numpy's operations.  It's also nice because it can
interface without copying any data; it just provides a wrapper class
that sits on a numpy array.  The library is included as part of scipy.

I recently wrote a function that automatically generates wrappers for
a c++ function that accepts blitz++ arrays which I recently posted to
the scipy list.  You just specify function names and the list of
argument types (nparrays included) and it generates the wrapper code.
Quite easy.  It's pertinent to the discussion here, so I'll send it
again.  Included is a full working example with setup.py.  let me know
if it helps/is confusing/doesn't work/etc.

--Hoyt





On Wed, Apr 23, 2008 at 12:30 PM, Andreas Klöckner
<[EMAIL PROTECTED]> wrote:
> On Mittwoch 23 April 2008, Christopher Barker wrote:
>  > NOTE:
>  > Most folks now think that the pain of writing extensions completely by
>  > hand is not worth it -- it's just too easy to make reference counting
>  > mistakes, etc. Most folks are now using one of:
>  >
>  > Cython (or Pyrex)
>  > SWIG
>  > ctypes
>
>  IMO, all of these deal better with C than they do with C++. There is also a
>  number of more C++-affine solutions:
>
>  - Boost Python [1]. Especially if you want usable C++ integration. (ie. more
>  than basic templates, etc.)
>
>  - sip [2]. Used for PyQt.
>
>  Andreas
>
>  [1] http://www.boost.org/doc/libs/1_35_0/libs/python/doc/index.html
>  [2] http://www.riverbankcomputing.co.uk/sip/index.php
>
> ___
>  Numpy-discussion mailing list
>  Numpy-discussion@scipy.org
>  http://projects.scipy.org/mailman/listinfo/numpy-discussion
>
>



-- 
+++
Hoyt Koepke
UBC Department of Computer Science
http://www.cs.ubc.ca/~hoytak/
[EMAIL PROTECTED]
+++


weave_wrapper.tar.gz
Description: GNU Zip compressed data
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] access ndarray in C++

[Christopher Barker]

Andreas Klöckner wrote:
> IMO, all of these deal better with C than they do with C++. 

True, though SWIG works OK with C++.

 > There is also a
> number of more C++-affine solutions:
> 
> - Boost Python [1]. Especially if you want usable C++ integration. (ie. more 
> than basic templates, etc.)

What's the status of the Boost array object? maintained? updated for 
recent numpy?

> - sip [2]. Used for PyQt.

Any numpy-specific stuff for sip?

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

[EMAIL PROTECTED]

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] OSX installer: please test

[Christopher Barker]

Christopher Burns wrote:
> I've built a Universal Mac binary for numpy 1.1.0.   If 
> Mac people would kindly test it, I'd appreciate any feedback.
> 
> 
> Download here:
> https://cirl.berkeley.edu/numpy/numpy-1.1.0rc1-py2.5-macosx10.5.dmg

Note that it's called *osx10.5.dmg, but it seems to work just fine on 
10.4 -- same python.

All tests pass:
Dual PPC G5
OS-X 10.4.11
python.org version 2.5.1

Thanks!

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

[EMAIL PROTECTED]
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] access ndarray in C++

[Andreas Klöckner]

On Mittwoch 23 April 2008, Christopher Barker wrote:
> NOTE:
> Most folks now think that the pain of writing extensions completely by
> hand is not worth it -- it's just too easy to make reference counting
> mistakes, etc. Most folks are now using one of:
>
> Cython (or Pyrex)
> SWIG
> ctypes

IMO, all of these deal better with C than they do with C++. There is also a 
number of more C++-affine solutions:

- Boost Python [1]. Especially if you want usable C++ integration. (ie. more 
than basic templates, etc.)

- sip [2]. Used for PyQt.

Andreas

[1] http://www.boost.org/doc/libs/1_35_0/libs/python/doc/index.html
[2] http://www.riverbankcomputing.co.uk/sip/index.php


signature.asc
Description: This is a digitally signed message part.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] OSX installer: please test

[Robert Kern]

On Wed, Apr 23, 2008 at 9:51 AM, Robert Pyle <[EMAIL PROTECTED]> wrote:
> Here are some more complete tests on my assorted Macs.
>
>  Note that on the dual G5 tower, /usr/local/lib/libgfortran.2.dylib
>  seems to be missing, under both Tiger (10.4.11) and Leopard (10.5.2).
>  However, under both operating systems, /usr/local/gfortran/lib/
>  libgfortran.2.dylib exists, as does /usr/local/lib/libgfortran.3.dylib.
>
>  There is a soft link from /usr/local/lib/libgfortran.dylib to /usr/
>  local/lib/libgfortran.3.dylib .  Should numpy be looking for
>  libgfortran.dylib rather than libgfortran.2.dylib?  (I'm just
>  guessing; I have no idea why the file is needed.)

numpy doesn't. scipy does. Unfortunately, some code snuck in that
requires scipy. The code itself is optional, but the test suite loads
it to test. It will be removed.

-- 
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 mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] "aligned" matrix / ctypes

[Zachary Pincus]

Hello all,

I need to allocate a numpy array that I will then pass to a camera  
driver (via ctypes) so that the driver can fill the array with pixels.  
The catch is that the driver requires that rows of pixels start at 4- 
byte boundaries.

The sample C++ code given for allocating memory for this is (pixels  
are unsigned shorts):

// Two bytes for each pixel, then round
// up to the next multiple of four.
long width_bytes = ( ( 2 * width_pixels ) + 3 ) & -4;
long allocated_size = width_bytes * height;
unsigned char* image_data = new unsigned char[allocated_size];
I could make an empty uint8 numpy array of the required shape  
(allocated_size,) and adjust its dtype, shape, and strides to get the  
desired result. I'd then feed the array's ctypes data attribute to the  
driver to get filled in. Alternately I could allocate the data buffer  
via ctypes and then construct an array around it.

Is either option better? How does one construct a numpy array around a  
ctypes memory object? Can the array "take over" the memory management  
for the buffer?

Thanks for any suggestions,
Zach
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numpy release

[Jarrod Millman]

On Wed, Apr 23, 2008 at 11:32 AM, Anne Archibald
<[EMAIL PROTECTED]> wrote:
>  > So ... fixing x[0][0] for matrices should wait
>  >  until 1.2.  Is that correct?
>
>  It seems to me that everyone agrees that the current situation is
>  broken, but there is considerable disagreement on what the correct fix
>  is. My inclination is to apply the minimal fix you suggest, with tests
>  and documentation, as a stopgap, and let the different factions sort
>  it out by discussion on the way to 1.2.

+1
That sound reasonable to me.

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] access ndarray in C++

[Christopher Barker]

Thomas Hrabe wrote:
> One can find multiple approaches to arrays, the old numeric array and 
> the new ndarray. The new stuff seems to be backward compatible.

mostly, yes. numpy (ndarray) is the only option going forward, as it's 
the only one being maintained.

> However, where is a free  documentation of the ndarray?

You are right, the most complete set is Travis' book. It's a pretty good 
deal when you consider that he wrote much of numpy -- if it saves you an 
hour, it's worth the money!

That being said, I think you were pointed to:

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

Which should get you going, though it does seem to be missing your key 
question:

> Which headers do I have to use in order to access the ndarray object 
> that, in my eyes, should be compatible wit PyObject in some way?

#include 

You should use distutils to compile your extension, and in your 
setup.py, you can put:

include_dirs=[numpy.get_include()]

and the header should be found.

> run in C should look like this:
> PyObject run{
> PyObject* ndArray;
> PyArg_ParseTuple( argv,  ,ndArray);

I think you had that right before -- you were just using the wrong headers:

PyArg_ParseTuple(args, "O!",&PyArray_Type, &array)

> Is it possible to access the ndarray object like this?

yes, something like that certainly should work.

When you've got it worked out, please add it to the Wiki.

I'd poke around the wiki, and this mailing list archives, for more examples.

NOTE:
Most folks now think that the pain of writing extensions completely by 
hand is not worth it -- it's just too easy to make reference counting 
mistakes, etc. Most folks are now using one of:

Cython (or Pyrex)
SWIG
ctypes

For example, the SWIG typemaps distributed with numpy make it very easy 
to pass a numpy array into a C function such as:

void MyFunc(int i, int j, int k, double *arr)

where *arr is a pointer to a block of doubles that represent an (i,j,k) 
3-d array.

Equally easy methods are available with Cython and ctypes.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

[EMAIL PROTECTED]
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numpy release

[Anne Archibald]

On 23/04/2008, Alan Isaac <[EMAIL PROTECTED]> wrote:
> On Wed, 23 Apr 2008, Sebastian Haase wrote:
>  > What used to be referred to a the 1.1 version, that can
>  > break more stuff, to allow for a cleaner design, will now
>  > be 1.2
>
> So ... fixing x[0][0] for matrices should wait
>  until 1.2.  Is that correct?

It seems to me that everyone agrees that the current situation is
broken, but there is considerable disagreement on what the correct fix
is. My inclination is to apply the minimal fix you suggest, with tests
and documentation, as a stopgap, and let the different factions sort
it out by discussion on the way to 1.2.

Objections?

Anne
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numpy release

[Alan Isaac]

On Wed, 23 Apr 2008, Sebastian Haase wrote:
> What used to be referred to a the 1.1 version, that can 
> break more stuff, to allow for a cleaner design, will now 
> be 1.2 

So ... fixing x[0][0] for matrices should wait
until 1.2.  Is that correct?

Thank you,
Alan Isaac




___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] access ndarray in C++

[Thomas Hrabe]

Hi all,

first of all, thank you for the rich spectrum of answers, especially to Joris' 
sample code.

What I still do not understand is the following:

One can find multiple approaches to arrays, the old numeric array and the new 
ndarray.
The new stuff seems to be backward compatible. However, where is a free 
documentation of the ndarray?

Which headers do I have to use in order to access the ndarray object that, in 
my eyes, should be compatible wit PyObject in some way?
I find definitions of the old array types, but none for the ndarray.
I tend to give Joris code a try; but, however, the whole situation confueses me.
Joris code (the ndarray.h) does not include any numpy object definition for 
instance.

All I want to do is the following:

>a = numpy.array([1,1,1])
>a.__class__
  


mymod.run(a )

run in C should look like this:
PyObject run{
PyObject* ndArray;
PyArg_ParseTuple( argv,  ,ndArray);

for(x axis)
 for(y axis)
  do something with ndArray.data[x][y];

return something.
}

Is it possible to access the ndarray object like this? I do not want to create 
new array objects right now, later maybe. 
There must be a predefined way to access the data in C without using a custom 
hack.

Finally, my primary aim is to access 3dimensional arrays of floats in C.

Best,
Thomas


-Original Message-
From: [EMAIL PROTECTED] on behalf of Thomas Hrabe
Sent: Tue 4/22/2008 2:38 PM
To: numpy-discussion@scipy.org
Subject: [Numpy-discussion] access ndarray in C++
 
Hi all!

I am currently developing a python module in C/C++ which is supposed to access 
nd arrays as defined by the following command in python

a = numpy.array([1,1,1])

I want to access the array the following way and use the nd array data for 
further processing in C.

mymod.doSthg(a)

The example code on 
http://numpy.sourceforge.net/numdoc/HTML/numdoc.htm#pgfId-36721

 (!PyArg_ParseTuple(args, "O!",&PyArray_Type, &array))

does not work for nd arrays. I always get 
TypeError: argument 1 must be array, not numpy.ndarray

I assume the error is the constant provided as the third parameter, saying that 
the imput is of PyArray_Type and no nd array.

So here are my questions:
1. is there any good tutorial / example code for acessing nd arrays in C?
2. what is the difference between both (arrays and nd arrays? - I am new to 
python and heard there were different approaches to arrays and that nd arrays 
work better for multi dimensional applications. Is this right?)
3. which one of both will be used in the future?

Thank you in advance for your help,
Thomas

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numpy release

[Stéfan van der Walt]

Hi Jarrod

Of those tickets, the following are serious:

http://projects.scipy.org/scipy/numpy/ticket/605 (a patch is
available?, David Huard)
  Fixing of histogram.

http://projects.scipy.org/scipy/numpy/ticket/551 (old regression,
Chuck and Travis)
  Unpickled arrays don't work as expected, because of memory alignment issues.

http://projects.scipy.org/scipy/numpy/ticket/748 (old regression, Stefan)
  ifft pads incorrectly.  I can fix this tonight, if someone would
verify that this is, indeed, a bug.

http://projects.scipy.org/scipy/numpy/ticket/751 (old/new regression,
Stefan, David C*)
  ALL section not recognised in site.cfg.  In Python 2.6, the DEFAULT
section no longer works.  I replaced it with ALL, but apparently not
everything works as expected.  David has a way to reproduce the
problem, so I hope he can have a look, otherwise I'll try and fix it
tomorrow.

Regards
Stéfan

2008/4/23 Jarrod Millman <[EMAIL PROTECTED]>:
> On Wed, Apr 23, 2008 at 6:21 AM, Stéfan van der Walt <[EMAIL PROTECTED]> 
> wrote:
>  >  The question is: what blocks the release of 1.1?  The following
>  >  tickets deserve attention:
>  >
>  >  http://projects.scipy.org/scipy/numpy/ticket/750
>  >  http://projects.scipy.org/scipy/numpy/ticket/605
>  >  http://projects.scipy.org/scipy/numpy/ticket/551
>  >  http://projects.scipy.org/scipy/numpy/ticket/738
>  >  http://projects.scipy.org/scipy/numpy/ticket/743
>  >  http://projects.scipy.org/scipy/numpy/ticket/748
>  >  http://projects.scipy.org/scipy/numpy/ticket/751
>  >  http://projects.scipy.org/scipy/numpy/ticket/736
>  >
>  >  Further issues:
>  >
>  >  - Alan's matrix indexing: x[0][0] for matrices currently yield x[0]
>
>  I was still hoping to get 1.1.0 out ASAP.  Unfortunately, I have been
>  too busy for the last week to pay attention to the release blockers.
>  The last time I looked the only issues I felt absolutely needed to be
>  resolved before the release were:
>  1.  Testing the Windows binary, which is now done.
>  2.  Testing the Mac binary, which is now done.
>  3.  Testing or removing fromregex, which is now done:
>  http://projects.scipy.org/scipy/numpy/ticket/719
>
>  I haven't looked carefully at the above tickets, but at a cursory
>  glance it didn't seem like there were any new regressions.  Stefan
>  could you confirm that?  If so, I would like to branch 1.1.x and tag
>  1.1.0 on Friday night.  Unless there is some concrete reason that we
>  need to delay this release any longer, I will send out an email later
>  today with an 'official' timeline for the release, which will probably
>  be on Monday if I tag on Friday night.
>
>  Thanks,
>
>  --
>  Jarrod Millman
>  Computational Infrastructure for Research Labs
>  10 Giannini Hall, UC Berkeley
>  phone: 510.643.4014
>  http://cirl.berkeley.edu/
>
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numpy release

[Jarrod Millman]

On Wed, Apr 23, 2008 at 6:21 AM, Stéfan van der Walt <[EMAIL PROTECTED]> wrote:
>  The question is: what blocks the release of 1.1?  The following
>  tickets deserve attention:
>
>  http://projects.scipy.org/scipy/numpy/ticket/750
>  http://projects.scipy.org/scipy/numpy/ticket/605
>  http://projects.scipy.org/scipy/numpy/ticket/551
>  http://projects.scipy.org/scipy/numpy/ticket/738
>  http://projects.scipy.org/scipy/numpy/ticket/743
>  http://projects.scipy.org/scipy/numpy/ticket/748
>  http://projects.scipy.org/scipy/numpy/ticket/751
>  http://projects.scipy.org/scipy/numpy/ticket/736
>
>  Further issues:
>
>  - Alan's matrix indexing: x[0][0] for matrices currently yield x[0]

I was still hoping to get 1.1.0 out ASAP.  Unfortunately, I have been
too busy for the last week to pay attention to the release blockers.
The last time I looked the only issues I felt absolutely needed to be
resolved before the release were:
1.  Testing the Windows binary, which is now done.
2.  Testing the Mac binary, which is now done.
3.  Testing or removing fromregex, which is now done:
http://projects.scipy.org/scipy/numpy/ticket/719

I haven't looked carefully at the above tickets, but at a cursory
glance it didn't seem like there were any new regressions.  Stefan
could you confirm that?  If so, I would like to branch 1.1.x and tag
1.1.0 on Friday night.  Unless there is some concrete reason that we
need to delay this release any longer, I will send out an email later
today with an 'official' timeline for the release, which will probably
be on Monday if I tag on Friday night.

Thanks,

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] finding minimum distance using arrays

[Christopher Barker]

Nadav Horesh wrote:
> def distance(v1,v2):
>return sqrt(((v2-v1)**2).sum())

note that Roberts version didn't compute the sqrt, as to find the 
minimum distance, you can just used the squared value.

If you do want the actual distance, then you might want to use 
numpy.hypot, something like (untested):

import numpy as np

def distance(v1, v2):
diff = v1-v2
return np.hypot(diff[:,0], diff[:,1])

It should be faster -- less data copying, one loop.

By the way, it would be nice to have a version that would take a NX2 
array, so you could write: np.hypot(v1-v2)

or even np.EuclidDistance(v1, v2)

But maybe it's not worth bloating numpy for...


-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

[EMAIL PROTECTED]
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] access ndarray in C++

[Joris De Ridder]

On 23 Apr 2008, at 17:50, Tommy Grav wrote:

>
> On Apr 23, 2008, at 11:26 AM, Joris De Ridder wrote:
>
>>
>> They are attached to the wiki page. Click on "Attachments" in the  
>> menu
>> on the left.
>>
>> Joris
>
> Thanks. Didn't know that wiki's had that :)
>
> I tried you example on a Mac OS X 10.5.2 (I am not using Scons) and  
> got
>
> [skathi:~/Work/myCode/pyCextensions] tgrav% gcc -dynamiclib
> myextension.cpp -o libmyextension.dylibUndefined symbols:
>   "___gxx_personality_v0", referenced from:
>   ___gxx_personality_v0$non_lazy_ptr in cct0CmDB.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
>
> Anyone have any idea what I am doing wrong?


Try

g++ -o myextension.os -c -fPIC myextension.cpp
g++ -o libmyextension.dylib -dynamiclib myextension.os

on the bash prompt. (Or use Scons :-).

Joris


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

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Warning: converting a masked element to nan

[Pierre GM]

On Wednesday 23 April 2008 04:00:13 Eric Firing wrote:
> I think there is a bug in that method; it always returns a nan,
> sometimes with the warning, and sometimes without.  By analogy with the
> ndarray method, it should raise an exception if the array has more than
> one element, and it there is only one element, it should try to convert
> it to a python float.

OK, fixed in SVN5071, along with __int__
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] access ndarray in C++

[Bill Spotz]

On Apr 23, 2008, at 9:50 AM, Tommy Grav wrote:
>
> On Apr 23, 2008, at 11:26 AM, Joris De Ridder wrote:
>
>>
>> They are attached to the wiki page. Click on "Attachments" in the  
>> menu
>> on the left.
>>
>> Joris
>
> Thanks. Didn't know that wiki's had that :)
>
> I tried you example on a Mac OS X 10.5.2 (I am not using Scons) and  
> got
>
> [skathi:~/Work/myCode/pyCextensions] tgrav% gcc -dynamiclib
> myextension.cpp -o libmyextension.dylibUndefined symbols:
>   "___gxx_personality_v0", referenced from:
>   ___gxx_personality_v0$non_lazy_ptr in cct0CmDB.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
>
> Anyone have any idea what I am doing wrong?


These "personality" errors indicate a version mismatch with the gcc  
compiilers.

** Bill Spotz  **
** Sandia National Laboratories  Voice: (505)845-0170  **
** P.O. Box 5800 Fax:   (505)284-0154  **
** Albuquerque, NM 87185-0370Email: [EMAIL PROTECTED] **






___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] access ndarray in C++

[Tommy Grav]

On Apr 23, 2008, at 11:26 AM, Joris De Ridder wrote:

>
> They are attached to the wiki page. Click on "Attachments" in the menu
> on the left.
>
> Joris

Thanks. Didn't know that wiki's had that :)

I tried you example on a Mac OS X 10.5.2 (I am not using Scons) and got

[skathi:~/Work/myCode/pyCextensions] tgrav% gcc -dynamiclib  
myextension.cpp -o libmyextension.dylibUndefined symbols:
   "___gxx_personality_v0", referenced from:
   ___gxx_personality_v0$non_lazy_ptr in cct0CmDB.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

Anyone have any idea what I am doing wrong?

Cheers
   Tommy

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numpy release

[Ondrej Certik]

On Wed, Apr 23, 2008 at 4:56 PM, Sebastian Haase <[EMAIL PROTECTED]> wrote:
>
> On Wed, Apr 23, 2008 at 2:32 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote:
>  > On Mon, Apr 14, 2008 at 12:06 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote:
>  >  > Hi Jarrod,
>  >  >
>  >  >  any news with the 1.0.5? If you have same prerelease, I'd like to test
>  >  >  it. Debian has just moved from python2.4 to python2.5 yesterday, so
>  >  >  I'd like to test numpy in advance, I am sure there will be some issues
>  >  >  to fix.
>  >
>  >  What is the plan with the release? There are some minor problems in
>  >  the Debian package, some of which are fixed by the new release.
>  >  I didn't fix those in Debian as I thought the new release is coming
>  >  out. But if it's going to take let's say month or two, I'll fix the
>  >  current Debian package now.
>  >
>
>  The problem is, that it was noticed that non-backwards compatible
>  changes were committed into svn.
>  Most noticeably a complete rewrite of the "ma" (Masked Array) package was 
> done.
>  As a consequence it was decided, they no one would be interested in
>  "temporarily taking those changes out" "just to release 1.0.5".
>
>  Instead the next release will be called 1.1 -- which is (only; rather
>  still) "mostly" compatible with 1.0.x
>  What used to be referred to a the 1.1 version, that can break more
>  stuff, to allow for a cleaner design, will now be 1.2

OK, so I think we are going to try to fix the package in Debian right
now and not wait for the release.

I think this uncertainty about releases and about backward
compatibility is not good. The same about uncertainty where f2py is
going to end up.
But you know the drill "talk is cheap, show me the code", so I know I
could step up and help Jarrod with the release, but unfortunately, I
don't have time for it. :)

Ondrej
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] access ndarray in C++

[Andreas Klöckner]

On Mittwoch 23 April 2008, Albert Strasheim wrote:
> Hello,
>
> On Tue, Apr 22, 2008 at 11:38 PM, Thomas Hrabe <[EMAIL PROTECTED]> wrote:
> >  I am currently developing a python module in C/C++ which is supposed to
> > access nd arrays as defined by the following command in python
>
> You might also be interested in:
>
> http://mathema.tician.de/software/pyublas

Argh-- you scooped me! :)

I'm preparing version 0.92.1 right now, due out later today. It should iron 
out most of the wrinkles that are still present in the current version, 0.92.

--Andreas


signature.asc
Description: This is a digitally signed message part.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] access ndarray in C++

[Stéfan van der Walt]

2008/4/23 Tommy Grav <[EMAIL PROTECTED]>:
>
>  On Apr 22, 2008, at 9:56 PM, Joris De Ridder wrote:
>
>  >
>  > On http://www.scipy.org/JorisDeRidder I've just put an example how I
>  > passed multidimensional Numpy arrays to C++ using ctypes. Perhaps
>  > it's helpful for your application. I didn't put it in the cookbook
>  > yet, because I would first like to test it a bit more. Up to now I
>  > didn't experience any bugs though.
>  >
>  > Joris
>
>  As a total newbie in the field of extensions, where do I find
>  ndarray.h and numpyctypes?

import numpy as np
print np.get_include()

numpyctypes is np.ctypeslib, I assume.

Regards
Stéfan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] access ndarray in C++

[Joris De Ridder]

They are attached to the wiki page. Click on "Attachments" in the menu  
on the left.

Joris


On 23 Apr 2008, at 17:19, Tommy Grav wrote:

>
> On Apr 22, 2008, at 9:56 PM, Joris De Ridder wrote:
>
>>
>> On http://www.scipy.org/JorisDeRidder I've just put an example how I
>> passed multidimensional Numpy arrays to C++ using ctypes. Perhaps
>> it's helpful for your application. I didn't put it in the cookbook
>> yet, because I would first like to test it a bit more. Up to now I
>> didn't experience any bugs though.
>>
>> Joris
>
> As a total newbie in the field of extensions, where do I find
> ndarray.h and numpyctypes?
>
> Cheers
>   Tommy
> ___
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion


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

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] access ndarray in C++

[Tommy Grav]

On Apr 22, 2008, at 9:56 PM, Joris De Ridder wrote:

>
> On http://www.scipy.org/JorisDeRidder I've just put an example how I  
> passed multidimensional Numpy arrays to C++ using ctypes. Perhaps  
> it's helpful for your application. I didn't put it in the cookbook  
> yet, because I would first like to test it a bit more. Up to now I  
> didn't experience any bugs though.
>
> Joris

As a total newbie in the field of extensions, where do I find  
ndarray.h and numpyctypes?

Cheers
   Tommy
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numpy release

[Sebastian Haase]

On Wed, Apr 23, 2008 at 2:32 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 14, 2008 at 12:06 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote:
>  > Hi Jarrod,
>  >
>  >  any news with the 1.0.5? If you have same prerelease, I'd like to test
>  >  it. Debian has just moved from python2.4 to python2.5 yesterday, so
>  >  I'd like to test numpy in advance, I am sure there will be some issues
>  >  to fix.
>
>  What is the plan with the release? There are some minor problems in
>  the Debian package, some of which are fixed by the new release.
>  I didn't fix those in Debian as I thought the new release is coming
>  out. But if it's going to take let's say month or two, I'll fix the
>  current Debian package now.
>

The problem is, that it was noticed that non-backwards compatible
changes were committed into svn.
Most noticeably a complete rewrite of the "ma" (Masked Array) package was done.
As a consequence it was decided, they no one would be interested in
"temporarily taking those changes out" "just to release 1.0.5".

Instead the next release will be called 1.1 -- which is (only; rather
still) "mostly" compatible with 1.0.x
What used to be referred to a the 1.1 version, that can break more
stuff, to allow for a cleaner design, will now be 1.2

HTH,
Sebastian Haase
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] OSX installer: please test

[Robert Pyle]

Here are some more complete tests on my assorted Macs.

Note that on the dual G5 tower, /usr/local/lib/libgfortran.2.dylib  
seems to be missing, under both Tiger (10.4.11) and Leopard (10.5.2).   
However, under both operating systems, /usr/local/gfortran/lib/ 
libgfortran.2.dylib exists, as does /usr/local/lib/libgfortran.3.dylib.

There is a soft link from /usr/local/lib/libgfortran.dylib to /usr/ 
local/lib/libgfortran.3.dylib .  Should numpy be looking for  
libgfortran.dylib rather than libgfortran.2.dylib?  (I'm just  
guessing; I have no idea why the file is needed.)

Bob Pyle

#

700 MHz G3 iBook, OSX 10.4.11:

Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import numpy as np
 >>> np.test(all=True)
Numpy is installed in /Library/Frameworks/Python.framework/Versions/ 
2.5/lib/python2.5/site-packages/numpy
Numpy version 1.1.0rc1
Python version 2.5.2 (r252:60911, Feb 22 2008, 07:57:53) [GCC 4.0.1  
(Apple Computer, Inc. build 5363)]

[ ... many successful tests ... ]

Failed importing /Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packages/numpy/ma/tests/test_morestats.py: No module  
named scipy.stats.distributions

[ ... more successful tests ... ]

./Library/Frameworks/ 
Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy/core/ 
ma.py:609: UserWarning: Cannot automatically convert masked array to  
numeric because data
 is masked in one or more locations.
   warnings.warn("Cannot automatically convert masked array to "\
E... 
 
 
..E...
==
ERROR: check_testUfuncRegression (numpy.core.tests.test_ma.TestUfuncs)
--
Traceback (most recent call last):
   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packages/numpy/core/tests/test_ma.py", line 691, in  
check_testUfuncRegression
 self.failUnless(eq(ur.filled(0), mr.filled(0), f))
   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packages/numpy/ma/core.py", line 1556, in filled
 result = self._data.copy()
   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packages/numpy/ma/core.py", line 1478, in _get_data
 return self.view(self._baseclass)
TypeError: Cannot change data-type for object array.

==
ERROR: check_testUfuncRegression (numpy.ma.tests.test_old_ma.TestUfuncs)
--
Traceback (most recent call last):
   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packages/numpy/ma/tests/test_old_ma.py", line 657, in  
check_testUfuncRegression
 uf = getattr(umath, f)
NameError: global name 'umath' is not defined

--
Ran 1215 tests in 14.448s

FAILED (errors=2)


#

Dual G5 tower, OSX 10.4.11:

~ $ python
Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import numpy as np
 >>> np.test(all=True)
Numpy is installed in /Library/Frameworks/Python.framework/Versions/ 
2.5/lib/python2.5/site-packages/numpy
Numpy version 1.1.0rc1
Python version 2.5.2 (r252:60911, Feb 22 2008, 07:57:53) [GCC 4.0.1  
(Apple Computer, Inc. build 5363)]

[ ... many successful tests ... ]


Failed importing /Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packa

Re: [Numpy-discussion] access ndarray in C++

[Albert Strasheim]

Hello,

On Tue, Apr 22, 2008 at 11:38 PM, Thomas Hrabe <[EMAIL PROTECTED]> wrote:
>  I am currently developing a python module in C/C++ which is supposed to
> access nd arrays as defined by the following command in python

You might also be interested in:

http://mathema.tician.de/software/pyublas

Regards,

Albert
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numpy release

[Stéfan van der Walt]

2008/4/23 Ondrej Certik <[EMAIL PROTECTED]>:
>  What is the plan with the release? There are some minor problems in
>  the Debian package, some of which are fixed by the new release.
>  I didn't fix those in Debian as I thought the new release is coming
>  out. But if it's going to take let's say month or two, I'll fix the
>  current Debian package now.

The question is: what blocks the release of 1.1?  The following
tickets deserve attention:

http://projects.scipy.org/scipy/numpy/ticket/750
http://projects.scipy.org/scipy/numpy/ticket/605
http://projects.scipy.org/scipy/numpy/ticket/551
http://projects.scipy.org/scipy/numpy/ticket/738
http://projects.scipy.org/scipy/numpy/ticket/743
http://projects.scipy.org/scipy/numpy/ticket/748
http://projects.scipy.org/scipy/numpy/ticket/751
http://projects.scipy.org/scipy/numpy/ticket/736

Further issues:

- Alan's matrix indexing: x[0][0] for matrices currently yield x[0]

Regards
Stéfan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] About sse, automatic vectorization and deployment issues

[David Cournapeau]

Hi,

I just came across a long thread on sse, automatic vectorization by 
gcc and deployment issues (linux specific, but still relevant for numpy 
I think). I thought it was interesting, and tackles most issues we would 
face once we go to that route:

http://lalists.stanford.edu/lad/2008/04/0023.html

cheers,

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numpy release

[Ondrej Certik]

On Mon, Apr 14, 2008 at 12:06 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote:
> Hi Jarrod,
>
>  any news with the 1.0.5? If you have same prerelease, I'd like to test
>  it. Debian has just moved from python2.4 to python2.5 yesterday, so
>  I'd like to test numpy in advance, I am sure there will be some issues
>  to fix.

What is the plan with the release? There are some minor problems in
the Debian package, some of which are fixed by the new release.
I didn't fix those in Debian as I thought the new release is coming
out. But if it's going to take let's say month or two, I'll fix the
current Debian package now.

Thanks,
Ondrej
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] f2py: optional parameters and present() bug?

[Pearu Peterson]

Garry Willgoose wrote:
> in a F90 routine called from python the present() test (for optional  
> parameters) always returns true whether the parameter is present in  
> the function call or not. My F90 test code looks like this
> 
> subroutine test(test1,test2,test3)
>integer,intent(in) :: test1
>integer,intent(in),optional :: test2
>integer,intent(inout),optional :: test3
>  write (*,*) test1,present(test2),present(test3)
>  if (present(test2)) write (*,*) 'test2',test2
>  if (present(test3)) then
>write (*,*) 'test3',test3
>test3=5
>  end if
> end subroutine test
> 
> The output from python calls to this routine (its inside a module  
> tsdtm.tsg ... just to explain why the function looks like it does). I  
> have just created this with f2py automatically generating the  
> interface with no hand modification of the interfaces. What this test  
> shows is that present() always returns true no matter (1) the intent  
> (2) whether the parameter is present in the call, or (3) the type of  
> the parameter (real, integer ... though I haven't tested arrays etc)  
> as well.

f2py generated wrappers always call Fortran functions with the
full list of arguments. This is the reason why present always
returns True. With the current f2py I can only suggest the following
workaround:

!f2py integer intent(in), optional :: test2 = -1
! assuming that -1 is the magic value that indicates that option was not 
specified.
if (present(test2).and.(.not.(test2.eq.-1))) ...

> Secondly I can't see how to get the returned value of 'test3'. It  
> doesn't seem to be returned as a result of the function?

Yes, because f2py treats `intent(inout)` arguments as input arguments
that can be changed in place. Add the following comment to F90 code:

!f2py intent(out) test3

that will make the wrapper to return the value of test3.

> The docs say f2py handles optional parameters and other than present 
> () my testing suggests that optional parameters seem otherwise OK.  

Yes, f2py is not aware of the present function. Adding present awarness
support is not trivial as it may be compiler dependent (f2py would
need to know what is the value of an optional arguments such that
present would return False). However, there exists a technique to
circumvent this problem that I plan to implement for g3 f2py.

HTH,
Pearu
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] access ndarray in C++

[Joris De Ridder]

Hi Sebastian,

> this is a great ( short ) recipe !

Thanks!

> Could you elaborate on the line
> "You need to compile myextension.cpp and make a shared library from
> it. The easiest way is to use Scons with the constructor file: !?

David already gave the answer. Scons allows you to make shared  
libraries of your C++ code without having to worry about whether it  
should be a .dll,  a .so, or a .dylab library. Plus, it's very easy to  
install.

Cheers,
Joris


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

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] access ndarray in C++

[Matthieu Brucher]

>
> the compiler, the compiler flags, the linker, the linker flags, the
> location of Python.h, etc...
>
>
> > With a simple extension builder, we didn't encountered any bug
> > although we have a fair number of extensions.
>
>
> Building a helloworld like extension or say numpy.core is kind of the
> same from a build point of view. The problem really is to work in many
> different configurations (for example supporting building python
> extensions for a different python than the one running scons), on
> different platforms.



Indeed, if you want a different python, a more complex builder has to be
written, I agree ;)

Matthieu

Waf (a project which started as a fork of scons and is now a totally
> different project for all purpose) has a python tool, and it is 300
> lines of code:
>
> http://code.google.com/p/waf/source/browse/trunk/wafadmin/Tools/python.py
>
> And it has more support for this kind of things than scons. My current
> work for a python extension for scons is ~ 200 lines, not including unit
> tests.
>
>
> cheers,
>
> David
> ___
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>



-- 
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] access ndarray in C++

[David Cournapeau]

Matthieu Brucher wrote:
>
> Having a good python extension builder is also more difficult than I
> first expected, too (you can't retrieve options for MS compilers from
> distutils, for example and I would like to support building with and
> without distutils' help).
>
>
> What are these options that must be retrieved? 

the compiler, the compiler flags, the linker, the linker flags, the 
location of Python.h, etc...

> With a simple extension builder, we didn't encountered any bug 
> although we have a fair number of extensions.

Building a helloworld like extension or say numpy.core is kind of the 
same from a build point of view. The problem really is to work in many 
different configurations (for example supporting building python 
extensions for a different python than the one running scons), on 
different platforms.

Waf (a project which started as a fork of scons and is now a totally 
different project for all purpose) has a python tool, and it is 300 
lines of code:

http://code.google.com/p/waf/source/browse/trunk/wafadmin/Tools/python.py

And it has more support for this kind of things than scons. My current 
work for a python extension for scons is ~ 200 lines, not including unit 
tests.

cheers,

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Warning: converting a masked element to nan

[Pierre GM]

On Wednesday 23 April 2008 04:00:13 Eric Firing wrote:
> I think there is a bug in that method; it always returns a nan,
> sometimes with the warning, and sometimes without.  

Well, the first time you get a warning, you don't the following times.

> By analogy with the 
> ndarray method, it should raise an exception if the array has more than
> one element, and it there is only one element, it should try to convert
> it to a python float.

Sounds like a plan. I'll take care of that tomorrow.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] access ndarray in C++

[Matthieu Brucher]

>
> Having a good python extension builder is also more difficult than I
> first expected, too (you can't retrieve options for MS compilers from
> distutils, for example and I would like to support building with and
> without distutils' help).


What are these options that must be retrieved? With a simple extension
builder, we didn't encountered any bug although we have a fair number of
extensions.

Matthieu
-- 
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] f2py: optional parameters and present() bug?

[Garry Willgoose]

in a F90 routine called from python the present() test (for optional  
parameters) always returns true whether the parameter is present in  
the function call or not. My F90 test code looks like this

subroutine test(test1,test2,test3)
   integer,intent(in) :: test1
   integer,intent(in),optional :: test2
   integer,intent(inout),optional :: test3
 write (*,*) test1,present(test2),present(test3)
 if (present(test2)) write (*,*) 'test2',test2
 if (present(test3)) then
   write (*,*) 'test3',test3
   test3=5
 end if
end subroutine test

The output from python calls to this routine (its inside a module  
tsdtm.tsg ... just to explain why the function looks like it does). I  
have just created this with f2py automatically generating the  
interface with no hand modification of the interfaces. What this test  
shows is that present() always returns true no matter (1) the intent  
(2) whether the parameter is present in the call, or (3) the type of  
the parameter (real, integer ... though I haven't tested arrays etc)  
as well.

Secondly I can't see how to get the returned value of 'test3'. It  
doesn't seem to be returned as a result of the function?

The docs say f2py handles optional parameters and other than present 
() my testing suggests that optional parameters seem otherwise OK.  
I'm on Mac OSX and using numpy 1.0.3. Any thoughts?

 >>> print tsimdtm.tsg.test.__doc__
test - Function signature:
   test(test1,[test2,test3])
Required arguments:
   test1 : input int
Optional arguments:
   test2 : input int
   test3 : in/output rank-0 array(int,'i')
 >>> tsimdtm.tsg.test(1)
  1 T T
  test2 0
  test3 0
 >>> tsimdtm.tsg.test(1,2)
  1 T T
  test2 2
  test3 0
 >>> tsimdtm.tsg.test(1,2,3)
  1 T T
  test2 2
  test3 3
 >>> tsimdtm.tsg.test(1,test2=2)
  1 T T
  test2 2
  test3 0
 >>> tsimdtm.tsg.test(1,test3=3)
  1 T T
  test2 0
  test3 3
 >>> tsimdtm.tsg.test(1,test2=2,test3=3)
  1 T T
  test2 2
  test3 3





Prof Garry Willgoose,
Australian Professorial Fellow in Environmental Engineering,
Director, Centre for Climate Impact Management (C2IM),
School of Engineering, The University of Newcastle,
Callaghan, 2308
Australia.

Centre webpage: www.c2im.org.au

Phone: (International) +61 2 4921 6050 (Tues-Fri AM); +61 2 6545 9574  
(Fri PM-Mon)
FAX: (International) +61 2 4921 6991 (Uni); +61 2 6545 9574 (personal  
and Telluric)
Env. Engg. Secretary: (International) +61 2 4921 6042

email:  [EMAIL PROTECTED];  
[EMAIL PROTECTED]
email-for-life: [EMAIL PROTECTED]
personal webpage: www.telluricresearch.com/garry

"Do not go where the path may lead, go instead where there is no path  
and leave a trail"
   Ralph Waldo Emerson






___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Warning: converting a masked element to nan

[Eric Firing]

Vincent Schut wrote:
> Hi,
> 
> Using maskedarrays (from svn numpy trunk), I sometimes get this warning:
> 
> "Warning: converting a masked element to nan".
> 
> It is not entirely clear to me what it means, and why it happens. Does 
> it mean that numpy.ma is converting an element of the data part of the 
> MA to NaN, on it's own? If so, why, and when? Or does it mean that I 
> deliberatly have changed a data element to NaN, and if so, why on earth 
> should I be warned for that? I think it is pretty normal to be able to 
> create NaN's in my array... Or does it mean yet something else?
> 
> And, also important: how can I avoid this (not suppress, but what should 
> I stop doing that currently triggers this warning)?
> 
> I hope someone could eleborate a bit on this...

Maybe you are doing something equivalent to this:

In [1]:xx = ma.array([1.1,2.2], mask=[True,False])

In [2]:float(xx)
/usr/local/lib/python2.5/site-packages/numpy/ma/core.py:1744: 
UserWarning: Warning: converting a masked element to nan.
   warnings.warn("Warning: converting a masked element to nan.")
Out[2]:nan

It is the __float__ method of the masked array that gives this warning.

I think there is a bug in that method; it always returns a nan, 
sometimes with the warning, and sometimes without.  By analogy with the 
ndarray method, it should raise an exception if the array has more than 
one element, and it there is only one element, it should try to convert 
it to a python float.

Eric


> 
> Cheers,
> Vincent.
> 
> ___
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] access ndarray in C++

[David Cournapeau]

Matthieu Brucher wrote:
> Hi David !
>
> Is it possible to construct a Python module with Scons without 
> tampering with different flags? I think you built your own builder 
> (just like I did), but did you manage to put it in Scons 0.98 ?

Unfortunately, no. I had to make a choice on which features to push to a 
good enough quality for 0.98 timeframe, and better fortran support was 
more important than python extension builder for me (I can incorporate a 
python extension builder without touching scons sources, but fixing 
fortran support meant that my own scons was different than official 
scons, which is not good).

Having a good python extension builder is also more difficult than I 
first expected, too (you can't retrieve options for MS compilers from 
distutils, for example and I would like to support building with and 
without distutils' help).

cheers,

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] access ndarray in C++

[Matthieu Brucher]

Hi David !

Is it possible to construct a Python module with Scons without tampering
with different flags? I think you built your own builder (just like I did),
but did you manage to put it in Scons 0.98 ?

Matthieu

2008/4/23, David Cournapeau <[EMAIL PROTECTED]>:
>
> Sebastian Haase wrote:
> >
> > Hi Joris,
> > this is a great ( short ) recipe ! Could you elaborate on the line
> > "You need to compile myextension.cpp and make a shared library from
> > it. The easiest way is to use Scons with the constructor file:"
> > !?
> > How do you call Scons in your example !? On Windows ( = cygwin !? ) ,
> > Linux and on OS-X ?
> >
>
>
> I think Joris mentioned scons because that's the easiest way to build a
> shared library in a cross platform way (taking care of -fPIC on unix,
> linker option, etc...).
>
> Scons is like make, and SConstruct files are like makefiles: you just
> call scons instead of make when you have a SConstruct file.
>
>
> > Scons is now part of numpy (svn), right ?  (at least the scons version
> you mean)
> >
>
>
> I think this had nothing to do with using scons to build numpy/scipy per
> se (numpy svn does not include scons, BTW, only hooks to call scons from
> distutils).
>
> cheers,
>
>
> David
>
> ___
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>



-- 
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] access ndarray in C++

[David Cournapeau]

Sebastian Haase wrote:
>
> Hi Joris,
> this is a great ( short ) recipe ! Could you elaborate on the line
> "You need to compile myextension.cpp and make a shared library from
> it. The easiest way is to use Scons with the constructor file:"
> !?
> How do you call Scons in your example !? On Windows ( = cygwin !? ) ,
> Linux and on OS-X ?
>   

I think Joris mentioned scons because that's the easiest way to build a 
shared library in a cross platform way (taking care of -fPIC on unix, 
linker option, etc...).

Scons is like make, and SConstruct files are like makefiles: you just 
call scons instead of make when you have a SConstruct file.

> Scons is now part of numpy (svn), right ?  (at least the scons version you 
> mean)
>   

I think this had nothing to do with using scons to build numpy/scipy per 
se (numpy svn does not include scons, BTW, only hooks to call scons from 
distutils).

cheers,

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Warning: converting a masked element to nan

[Pierre GM]

Vincent,
As a generic rule, this warning is output when the masked value 
(numpy.ma.masked) has to be converted to a float: in that case, a NaN is 
returned. Now, the exact reason why the masked value has to be converted is 
specific to your problem. A simple example of when this warning occurs would 
help to give you a detailed answer. 
Note that in the previous version (numpy.oldnumeric.ma), an exception was 
raised instead of a warning. I thought it was a bit too drastic.

> Does
> it mean that numpy.ma is converting an element of the data part of the
> MA to NaN, on it's own? 

No, it shouldn't affect the data part.

> Or does it mean that I 
> deliberatly have changed a data element to NaN, and if so, why on earth
> should I be warned for that? I think it is pretty normal to be able to
> create NaN's in my array... Or does it mean yet something else?

Take it as a note-to-self: somewhere down the line, a masked value had to be 
converted to a float, not a 0d array

> And, also important: how can I avoid this (not suppress, but what should
> I stop doing that currently triggers this warning)?

Once again, that depends, and I;m sorry I can be more specific than that: I 
don't have a particular example in mind...
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] access ndarray in C++

[Sebastian Haase]

On Wed, Apr 23, 2008 at 3:56 AM, Joris De Ridder
<[EMAIL PROTECTED]> wrote:
>
>
> On http://www.scipy.org/JorisDeRidder I've just put an example how I passed
> multidimensional Numpy arrays to C++ using ctypes. Perhaps it's helpful for
> your application. I didn't put it in the cookbook yet, because I would first
> like to test it a bit more. Up to now I didn't experience any bugs though.
>
> Joris
>

Hi Joris,
this is a great ( short ) recipe ! Could you elaborate on the line
"You need to compile myextension.cpp and make a shared library from
it. The easiest way is to use Scons with the constructor file:"
!?
How do you call Scons in your example !? On Windows ( = cygwin !? ) ,
Linux and on OS-X ?
Scons is now part of numpy (svn), right ?  (at least the scons version you mean)

Thanks again,
Sebastian Haase
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] different behaviour in asfarray(None)

[Stéfan van der Walt]

2008/4/23 Travis E. Oliphant <[EMAIL PROTECTED]>:
> I'm curious who made the change and why.  There was code intentionally
> there to interpret None as nan for float arrays.   So, I don't
> understand why and/or when it changed.

I find that behaviour counterintuitive (I'm not the one who changed it, though).

Why shouldn't asfarray behave the same way as np.array(x).astype(float)?

Regards
Stéfan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Warning: converting a masked element to nan

[Vincent Schut]

Hi,

Using maskedarrays (from svn numpy trunk), I sometimes get this warning:

"Warning: converting a masked element to nan".

It is not entirely clear to me what it means, and why it happens. Does 
it mean that numpy.ma is converting an element of the data part of the 
MA to NaN, on it's own? If so, why, and when? Or does it mean that I 
deliberatly have changed a data element to NaN, and if so, why on earth 
should I be warned for that? I think it is pretty normal to be able to 
create NaN's in my array... Or does it mean yet something else?

And, also important: how can I avoid this (not suppress, but what should 
I stop doing that currently triggers this warning)?

I hope someone could eleborate a bit on this...

Cheers,
Vincent.

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion