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

Re: [Numpy-discussion] core dump when runniong tests

[Mathew Y. <my...@jp...>]

SunOS  5.10 Generic_118844-20 i86pc i386 i86pcSystem = SunOS

David M. Cooke wrote:
> On Wed, 14 Jun 2006 14:06:13 -0700
> Mathew Yeates <my...@jp...> wrote:
>
>   
>> Travis suggested I use svn and this worked!
>> Thanks Travis!
>>
>> I'm now getting 1 test failure. I'd love to dot this 'i'
>>
>> ======================================================================
>> FAIL: check_large_types (numpy.core.tests.test_scalarmath.test_power)
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>>   File 
>> "/lib/python2.4/site-packages/numpy/core/tests/test_scalarmath.py", line 
>> 42, in check_large_types
>>     assert b == 6765201, "error with %r: got %r" % (t,b)
>> AssertionError: error with <type 'float96scalar'>: got 
>> 6765201.00000000000364
>>
>> ----------------------------------------------------------------------
>> Ran 377 tests in 0.347s
>>
>> FAILED (failures=1)
>>     
>
> I'm guessing the C powl function isn't good enough on your machine.
>
> What OS are you running?
>
>   

Re: [Numpy-discussion] problem with numpy.. sometimes using numarray? and selection question

[bryce h. <bhe...@en...>]

We've had the same problem many times. There were a few causes:

* Our clean scripts don't delete c++ files, so generated code was often 
not re-generated when we switched to numpy

* Files to generate code had numeric arrays hardcoded

* we were using numerix, and the env var was not set for part of the build

How I generally detect the problem is by deleting the numeric/numarray 
package directories, then running python with the verbose flag.

Bryce

Fernando Perez wrote:
> On 6/15/06, Eric Emsellem <ems...@ob...> wrote:
>   
>> Hi,
>>
>> I have written a number of small modules where I now systematically use
>> numpy.
>>
>> I have in principle used the latest versions of the different
>> array/Science modules (scipy, numpy, ..) but still at some point during
>> a selection, it crashes on numpy because it seems that the array
>> correspond to "numarray" arrays.
>>     
>
> [...]
>
>   
>> QUESTION 1: Any hint on where numarray could still be appearing?
>>     
>
> Not a final answer, but I've had the same thing happen to me recently
> (I'm making the transition right now) with extension modules which
> were built against Numeric (in my case).  They return old Numeric
> arrays (I had 23.7, without the array interface) and numpy is not
> happy.
>
> Rebuilding all my extensions against numpy  fixed the problem.
>
> Cheers,
>
> f
>
>
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
>   

Re: [Numpy-discussion] problem with numpy.. sometimes using numarray? and selection question

[Fernando P. <fpe...@gm...>]

On 6/15/06, Eric Emsellem <ems...@ob...> wrote:
> Hi,
>
> I have written a number of small modules where I now systematically use
> numpy.
>
> I have in principle used the latest versions of the different
> array/Science modules (scipy, numpy, ..) but still at some point during
> a selection, it crashes on numpy because it seems that the array
> correspond to "numarray" arrays.

[...]

> QUESTION 1: Any hint on where numarray could still be appearing?

Not a final answer, but I've had the same thing happen to me recently
(I'm making the transition right now) with extension modules which
were built against Numeric (in my case).  They return old Numeric
arrays (I had 23.7, without the array interface) and numpy is not
happy.

Rebuilding all my extensions against numpy  fixed the problem.

Cheers,

f

Re: [Numpy-discussion] https access to svn.scipy.org

[Glen W. M. <Gle...@sw...>]

On Thu, Jun 15, 2006 at 12:02:42PM -0500, Jeff Strunk wrote:
> svn over https works now.

Thanks Jeff -- that solved my svn woes.

Glen

Re: [Numpy-discussion] https access to svn.scipy.org

[Jeff S. <js...@en...>]

svn over https works now.

Jeff Strunk
IT Administrator
Enthought, Inc

On Thursday 15 June 2006 11:58 am, Jeff Strunk wrote:
> Hi Glen,
>
> I'll see about enabling SSL for svn on svn.scipy.org.
>
> Jeff Strunk
> IT Administrator
> Enthought, Inc.
>
> On Thursday 15 June 2006 9:04 am, Glen W. Mabey wrote:
> > Hello,
> >
> > I am attempting to use the svn versions of numpy and scipy, but
> > apparently (according to
> > http://www.sipfoundry.org/tools/svn-tips.html#proxy ) I am behind a
> > less-than-agreeable web proxy, because I get
> >
> >   $ svn co http://svn.scipy.org/svn/numpy/trunk numpy
> >   svn: REPORT request failed on '/svn/numpy/!svn/vcc/default'
> >   svn: REPORT of '/svn/numpy/!svn/vcc/default': 400 Bad Request
> > (http://svn.scipy.org)
> >
> > The solution suggested in the above URL is to use https instead,
> > however, when I attempt this
> >
> >   $ svn co https://svn.scipy.org/svn/numpy/trunk numpy
> >   svn: PROPFIND request failed on '/svn/numpy/trunk'
> >   svn: PROPFIND of '/svn/numpy/trunk': 405 Method Not Allowed
> > (https://svn.scipy.org)
> >
> > it appears that svn.scipy.org is not setup to employ SSL.  Is this an
> > easy thing to do?
> >
> > Please forgive me if this is just an issue of svn-ignorance on my part.
> >
> > Thanks,
> > Glen Mabey
> >
> >
> > _______________________________________________
> > Numpy-discussion mailing list
> > Num...@li...
> > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] https access to svn.scipy.org

[Jeff S. <js...@en...>]

Hi Glen,

I'll see about enabling SSL for svn on svn.scipy.org.

Jeff Strunk
IT Administrator
Enthought, Inc.


On Thursday 15 June 2006 9:04 am, Glen W. Mabey wrote:
> Hello,
>
> I am attempting to use the svn versions of numpy and scipy, but
> apparently (according to
> http://www.sipfoundry.org/tools/svn-tips.html#proxy ) I am behind a
> less-than-agreeable web proxy, because I get
>
>   $ svn co http://svn.scipy.org/svn/numpy/trunk numpy
>   svn: REPORT request failed on '/svn/numpy/!svn/vcc/default'
>   svn: REPORT of '/svn/numpy/!svn/vcc/default': 400 Bad Request
> (http://svn.scipy.org)
>
> The solution suggested in the above URL is to use https instead,
> however, when I attempt this
>
>   $ svn co https://svn.scipy.org/svn/numpy/trunk numpy
>   svn: PROPFIND request failed on '/svn/numpy/trunk'
>   svn: PROPFIND of '/svn/numpy/trunk': 405 Method Not Allowed
> (https://svn.scipy.org)
>
> it appears that svn.scipy.org is not setup to employ SSL.  Is this an
> easy thing to do?
>
> Please forgive me if this is just an issue of svn-ignorance on my part.
>
> Thanks,
> Glen Mabey
>
>
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

[Numpy-discussion] https access to svn.scipy.org

[Glen W. M. <Gle...@sw...>]

Hello,

I am attempting to use the svn versions of numpy and scipy, but
apparently (according to http://www.sipfoundry.org/tools/svn-tips.html#proxy )
I am behind a less-than-agreeable web proxy, because I get

  $ svn co http://svn.scipy.org/svn/numpy/trunk numpy
  svn: REPORT request failed on '/svn/numpy/!svn/vcc/default'
  svn: REPORT of '/svn/numpy/!svn/vcc/default': 400 Bad Request (http://svn.scipy.org)

The solution suggested in the above URL is to use https instead,
however, when I attempt this

  $ svn co https://svn.scipy.org/svn/numpy/trunk numpy
  svn: PROPFIND request failed on '/svn/numpy/trunk'
  svn: PROPFIND of '/svn/numpy/trunk': 405 Method Not Allowed (https://svn.scipy.org)

it appears that svn.scipy.org is not setup to employ SSL.  Is this an
easy thing to do?

Please forgive me if this is just an issue of svn-ignorance on my part.

Thanks,
Glen Mabey

[Numpy-discussion] problem with numpy.. sometimes using numarray? and selection question

[Eric E. <ems...@ob...>]

Hi,

I have written a number of small modules where I now systematically use
numpy.

I have in principle used the latest versions of the different
array/Science modules (scipy, numpy, ..) but still at some point during
a selection, it crashes on numpy because it seems that the array
correspond to "numarray" arrays.

e.g.:
##################################
selection = (rell >= 1.) * (rell < ES0.maxEFFR[indgal])
##################################
### rell is an array of reals and ES0.maxEFFR[indgal] is a real number.

gives the error:
==========
/usr/local/lib/python2.4/site-packages/numarray/numarraycore.py:376:
UserWarning: __array__ returned non-NumArray instance
  _warnings.warn("__array__ returned non-NumArray instance")
/usr/local/lib/python2.4/site-packages/numarray/ufunc.py in
_cache_miss2(self, n1, n2, out)
    919         (in1, in2), inform, scalar = _inputcheck(n1, n2)
    920
--> 921         mode, win1, win2, wout, cfunc, ufargs = \
    922               self._setup(in1, in2, inform, out)
    923

/usr/local/lib/python2.4/site-packages/numarray/ufunc.py in _setup(self,
in1, in2, inform, out)
    965             if out is None: wout = in2.new(outtypes[0])
    966         if inform == "vv":
--> 967             intypes = (in1._type, in2._type)
    968             inarr1, inarr2 = in1._dualbroadcast(in2)
    969             fform, convtypes, outtypes, cfunc =
self._typematch_N(intypes, inform)

AttributeError: 'numpy.ndarray' object has no attribute '_type'
================================================

QUESTION 1: Any hint on where numarray could still be appearing?

QUESTION 2: how would you make a selection using "and" and "or" such as:
                selection = (condition 1) "and" (condition2 "or" condition3)
so that "selection" contains 0 and 1 according to the right hand side.

Thanks,

Eric
P.S.:
my config is:

matplotlib version 0.87.3
verbose.level helpful
interactive is False
platform is linux2
numerix numpy 0.9.9.2624
font search path
['/usr/local/lib/python2.4/site-packages/matplotlib/mpl-data']
backend GTKAgg version 2.8.2
Python 2.4.2 (#1, May  2 2006, 08:13:46)
IPython 0.7.2 -- An enhanced Interactive Python.

I am using numerix = numpy in matplotlibrc. I am also using NUMERIX =
numpy when building pyfits.

-- 
====================================================================
Eric Emsellem                             ems...@ob...
                           Centre de Recherche Astrophysique de Lyon
9 av. Charles-Andre                        tel: +33 (0)4 78 86 83 84
69561 Saint-Genis Laval Cedex              fax: +33 (0)4 78 86 83 86
France                    http://www-obs.univ-lyon1.fr/eric.emsellem
====================================================================

Re: [Numpy-discussion] Don't like the short names like lstsq and irefft

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

On 6/15/06, Paul Dubois <pfd...@gm...> wrote:
> And yes, I think FFT is a name. (:->  Exception for that.


There are more exceptions that Numeric is not taking advantage of:

equal, less, greater, ... -> eq, lt, gt, ...
inverse, generalized_inverse -> inv, pinv

In my view it is more important that code is easy to read rather than
easy to write. Interactive users will disagree, but in programming you
write once and read/edit forever :).

Again, there is no defense for abbreviating linear_least_squares
because it is unlikely to appear in an expression and waste valuable
horisontal space.  Contracting generalised_inverse is appropriate and
numpy does the right thing in this case.

The eig.., svd and cholesky choice of names is unfortunate because
three different abbreviation schemes are used: first syllable,
acronym and first word.  I would say: when in doubt spell it in full.

Re: [Numpy-discussion] Don't like the short names like lstsq and irefft

[Alexander B. <ale...@gm...>]

On 6/15/06, Paul Dubois <pfd...@gm...> wrote:
> And yes, I think FFT is a name. (:->  Exception for that.


There are more exceptions that Numeric is not taking advantage of:

equal, less, greater, ... -> eq, lt, gt, ...
inverse, generalized_inverse -> inv, pinv

In my view it is more important that code is easy to read rather than
easy to write. Interactive users will disagree, but in programming you
write once and read/edit forever :).

Again, there is no defense for abbreviating linear_least_squares
because it is unlikely to appear in an expression and waste valuable
horisontal space.  Contracting generalised_inverse is appropriate and
numpy does the right thing in this case.

The eig.., svd and cholesky choice of names is unfortunate because
three different abbreviation schemes are used: first syllable,
acronym and first word.  I would say: when in doubt spell it in full.

Re: [Numpy-discussion] numpy.test() fails on Redhat Enterprise and Solaris

[Christopher H. <ch...@st...>]

The last successful run was with revision 2613.  However, revision 2624 
appears to have corrected the problem on Solaris.

Thanks,
Chris




Travis Oliphant wrote:
> Christopher Hanley wrote:
> 
>> The daily numpy build and tests I run have failed for revision 2617. 
>> Below is the error message I receive on my RHE 3 box:
>>
>> ====================================================================== 
>> FAIL: Check reading the nested fields of a nested array (1st level) 
>> ---------------------------------------------------------------------- 
>> Traceback (most recent call last):  File 
>> "/data/sparty1/dev/site-packages/lib/python/numpy/core/tests/test_numerictypes.py", 
>> line 283, in check_nested1_acessors    dtype='U2'))  File 
>> "/data/sparty1/dev/site-packages/lib/python/numpy/testing/utils.py", 
>> line 139, in assert_equal    return assert_array_equal(actual, 
>> desired, err_msg)  File 
>> "/data/sparty1/dev/site-packages/lib/python/numpy/testing/utils.py", 
>> line 215, in assert_array_equal    verbose=verbose, header='Arrays are 
>> not equal')  File 
>> "/data/sparty1/dev/site-packages/lib/python/numpy/testing/utils.py", 
>> line 207, in assert_array_compare    assert cond, msg AssertionError: 
>> Arrays are not equal
>> (mismatch 100.0%) x: array([u'NN', u'OO'],      dtype='<U8') y: 
>> array([u'NN', u'OO'],      dtype='<U2')
>>
>> On my Solaris 8 box this same test causes a bus error:
>>
>> Check creation of single-dimensional objects ... ok Check creation of 
>> 0-dimensional objects ... ok Check creation of multi-dimensional 
>> objects ... ok Check creation of single-dimensional objects ... ok 
>> Check reading the top fields of a nested array ... ok Check reading 
>> the nested fields of a nested array (1st level)Bus Error (core dumped)
>>
>>   
> 
> Do you know when was the last successful run?   I think I know what may 
> be causing this, but the change was introduced several weeks ago...
> 
> -Travis
> 

[Numpy-discussion] Disable linking against external libs

[Damien M. <dj...@mi...>]

Hi,

What is the intended way to disable linking against installed libraries
(blas, lapack, etc) in site.cfg? I know I can do:

[blas]
blah_libs = XXXnonexistXXX

but that strikes me as less than elegant.

FYI I want to do this to make package building deterministic; not
varying based on what the package builder happens to have installed on
his/her machine

-d

Re: [Numpy-discussion] numpy segv on OpenBSD

[Fernando P. <fpe...@gm...>]

On 6/15/06, Damien Miller <dj...@mi...> wrote:
> David M. Cooke wrote:
> > Can you update to the latest svn? We may have fixed it already: valgrind is
> > showing up nothing for me.
>
> Ok, but dumb question: how do I check out the SVN trunk? Sourceforge
> lists details for CVS only... (unless I'm missing something)

http://scipy.org/Developer_Zone

Cheers,

f

Re: [Numpy-discussion] numpy segv on OpenBSD

[Arnd B. <arn...@we...>]

On Thu, 15 Jun 2006, Damien Miller wrote:

> David M. Cooke wrote:
> > Can you update to the latest svn? We may have fixed it already: valgrind is
> > showing up nothing for me.
>
> Ok, but dumb question: how do I check out the SVN trunk? Sourceforge
> lists details for CVS only... (unless I'm missing something)

See "Bleeding-edge repository access" under
http://www.scipy.org/Download

I.e. for numpy:
  svn co http://svn.scipy.org/svn/numpy/trunk numpy

Best, Arnd

Re: [Numpy-discussion] numpy segv on OpenBSD

[Damien M. <dj...@mi...>]

David M. Cooke wrote:
> Can you update to the latest svn? We may have fixed it already: valgrind is
> showing up nothing for me.

Ok, but dumb question: how do I check out the SVN trunk? Sourceforge
lists details for CVS only... (unless I'm missing something)

-d

Re: [Numpy-discussion] numpy segv on OpenBSD

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

Damien Miller wrote:
> Hi,
>
> I'm trying to make an OpenBSD package on numpy-0.9.5, but it receives a
> malloc fault in the check_types() self-test as it tries to free() a junk
> pointer. In case you are not aware, OpenBSD's malloc() implementation
> does a fair bit of randomisation that makes it (deliberately) sensitive
> to memory management errors.
>   
This problem has been worked around in NumPy SVN.  It is a problem with 
Python that has been fixed in Python SVN as well. 

You can either comment-out the test or update to latest SVN.

-Travis

Re: [Numpy-discussion] core dump when runniong tests

[David M. C. <co...@ph...>]

On Wed, 14 Jun 2006 14:06:13 -0700
Mathew Yeates <my...@jp...> wrote:

> Travis suggested I use svn and this worked!
> Thanks Travis!
> 
> I'm now getting 1 test failure. I'd love to dot this 'i'
> 
> ======================================================================
> FAIL: check_large_types (numpy.core.tests.test_scalarmath.test_power)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File 
> "/lib/python2.4/site-packages/numpy/core/tests/test_scalarmath.py", line 
> 42, in check_large_types
>     assert b == 6765201, "error with %r: got %r" % (t,b)
> AssertionError: error with <type 'float96scalar'>: got 
> 6765201.00000000000364
> 
> ----------------------------------------------------------------------
> Ran 377 tests in 0.347s
> 
> FAILED (failures=1)

I'm guessing the C powl function isn't good enough on your machine.

What OS are you running?

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

Re: [Numpy-discussion] numpy segv on OpenBSD

[David M. C. <co...@ph...>]

On Thu, 15 Jun 2006 15:22:57 +1000 (EST)
Damien Miller <dj...@mi...> wrote:

> Hi,
> 
> I'm trying to make an OpenBSD package on numpy-0.9.5, but it receives a
> malloc fault in the check_types() self-test as it tries to free() a junk
> pointer. In case you are not aware, OpenBSD's malloc() implementation
> does a fair bit of randomisation that makes it (deliberately) sensitive
> to memory management errors.
> 
> Instumenting the check_types test and scalartypes.inc.src's
> gen_dealloc() and gen_alloc() functions I noticed that the error occurs
> up after calling gen_dealloc() on a complex128scalar that was created as
> check_types's "valb" variable as it is GC'd.
> 
> The check_types tests work fine on the complex64scalar type and all
> the other preceeding types. I'm not familiar with the guts of numpy
> at all (and I can't even find the declaration of the complex128scalar
> type in the source). What difference between complex64scalar and
> complex128scalar should I look for to debug this further?

Can you update to the latest svn? We may have fixed it already: valgrind is
showing up nothing for me.

A complex128scalar is a complex number made up of doubles (float64); a
complex64 is one of floats (float32).

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

Re: [Numpy-discussion] memory leak in array

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

saa...@sf... wrote:

> Update: I posted this message on the comp.lang.python forum and their 
> response was to get the numbers of references with sys.getrefcount(obj). 
> After doing this I see that iterative counters used to count occurrences 
> and nested loop counters (ii & jj) as seen in the code example below are the
> culprits with the worst ones over 1M:
> 
> 		 for ii in xrange(0,40):	
> 		    for jj in xrange(0,20):

Where are you getting this 1M figure? Is that supposed to mean "1 Megabyte of
memory"? Because they don't consume that much memory. In fact, all of the small
integers between -1 and 100, I believe (but certainly all of them in xrange(0,
40)) are shared. There is only one 0 object and only one 10 object, etc. That is
why their refcount is so high.

You're going down a dead end here.

> 			try:
> 			    nc = y[a+ii,b+jj]
> 			except IndexError: nc = 0
> 			
> 			if nc == "1" or nc == "5":

What is the dtype of y? You are testing for strings, but assigning integers.

-- 
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

Re: [Numpy-discussion] numpy segv on OpenBSD

[Damien M. <dj...@mi...>]

On Thu, 15 Jun 2006, Damien Miller wrote:

> Hi,
> 
> I'm trying to make an OpenBSD package on numpy-0.9.5, but it receives a

bah, I'm actually using numpy-0.9.8 (not 0.9.5).

-d

[Numpy-discussion] numpy segv on OpenBSD

[Damien M. <dj...@mi...>]

Hi,

I'm trying to make an OpenBSD package on numpy-0.9.5, but it receives a
malloc fault in the check_types() self-test as it tries to free() a junk
pointer. In case you are not aware, OpenBSD's malloc() implementation
does a fair bit of randomisation that makes it (deliberately) sensitive
to memory management errors.

Instumenting the check_types test and scalartypes.inc.src's
gen_dealloc() and gen_alloc() functions I noticed that the error occurs
up after calling gen_dealloc() on a complex128scalar that was created as
check_types's "valb" variable as it is GC'd.

The check_types tests work fine on the complex64scalar type and all
the other preceeding types. I'm not familiar with the guts of numpy
at all (and I can't even find the declaration of the complex128scalar
type in the source). What difference between complex64scalar and
complex128scalar should I look for to debug this further?

A backtrace is below for the curious.

-d

(gdb) bt
#0  0x0ff49975 in kill () from /usr/lib/libc.so.39.1
#1  0x0ff822c3 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
#2  0x0ff69649 in wrterror (p=0x2ff18460 "free_pages: pointer to wrong page")
    at /usr/src/lib/libc/stdlib/malloc.c:434
#3  0x0ff6970b in wrtwarning (p=0x2ff18460 "free_pages: pointer to wrong page")
    at /usr/src/lib/libc/stdlib/malloc.c:444
#4  0x0ff6ac53 in free_pages (ptr=0x7e0033b0, index=516111, info=0x0)
    at /usr/src/lib/libc/stdlib/malloc.c:1343
#5  0x0ff6a6f4 in ifree (ptr=0x7e0033b0)
    at /usr/src/lib/libc/stdlib/malloc.c:1770
#6  0x0ff6a8d1 in free (ptr=0x7e0033b0)
    at /usr/src/lib/libc/stdlib/malloc.c:1838
#7  0x0d259117 in gentype_dealloc (v=0x7e0033b0) at scalartypes.inc.src:283
#8  0x0c5fc778 in PyEval_EvalFrame () from /usr/local/lib/libpython2.4.so.0.0
#9  0x0c5feeb6 in PyEval_EvalCodeEx () from /usr/local/lib/libpython2.4.so.0.0
#10 0x0c60072f in fast_function () from /usr/local/lib/libpython2.4.so.0.0
#11 0x0c60036d in call_function () from /usr/local/lib/libpython2.4.so.0.0
#12 0x0c5fe42f in PyEval_EvalFrame () from /usr/local/lib/libpython2.4.so.0.0
#13 0x0c5feeb6 in PyEval_EvalCodeEx () from /usr/local/lib/libpython2.4.so.0.0
#14 0x0c5bf2f2 in function_call () from /usr/local/lib/libpython2.4.so.0.0
#15 0x0c5abe40 in PyObject_Call () from /usr/local/lib/libpython2.4.so.0.0
#16 0x0c600c6b in ext_do_call () from /usr/local/lib/libpython2.4.so.0.0
#17 0x0c5fe83c in PyEval_EvalFrame () from /usr/local/lib/libpython2.4.so.0.0
---Type <return> to continue, or q <return> to quit---
#18 0x0c5feeb6 in PyEval_EvalCodeEx () from /usr/local/lib/libpython2.4.so.0.0
#19 0x0c5bf2f2 in function_call () from /usr/local/lib/libpython2.4.so.0.0
#20 0x0c5abe40 in PyObject_Call () from /usr/local/lib/libpython2.4.so.0.0
#21 0x0c5b2bd4 in instancemethod_call ()
   from /usr/local/lib/libpython2.4.so.0.0
#22 0x0c5abe40 in PyObject_Call () from /usr/local/lib/libpython2.4.so.0.0
#23 0x0c600aa1 in do_call () from /usr/local/lib/libpython2.4.so.0.0
#24 0x0c6002fa in call_function () from /usr/local/lib/libpython2.4.so.0.0
#25 0x0c5fe42f in PyEval_EvalFrame () from /usr/local/lib/libpython2.4.so.0.0
#26 0x0c5feeb6 in PyEval_EvalCodeEx () from /usr/local/lib/libpython2.4.so.0.0
#27 0x0c5bf2f2 in function_call () from /usr/local/lib/libpython2.4.so.0.0
#28 0x0c5abe40 in PyObject_Call () from /usr/local/lib/libpython2.4.so.0.0
#29 0x0c5b2bd4 in instancemethod_call ()
   from /usr/local/lib/libpython2.4.so.0.0
#30 0x0c5abe40 in PyObject_Call () from /usr/local/lib/libpython2.4.so.0.0
#31 0x0c5e5c9f in slot_tp_call () from /usr/local/lib/libpython2.4.so.0.0
#32 0x0c5abe40 in PyObject_Call () from /usr/local/lib/libpython2.4.so.0.0
#33 0x0c600aa1 in do_call () from /usr/local/lib/libpython2.4.so.0.0
#34 0x0c6002fa in call_function () from /usr/local/lib/libpython2.4.so.0.0
#35 0x0c5fe42f in PyEval_EvalFrame () from /usr/local/lib/libpython2.4.so.0.0
#36 0x0c5feeb6 in PyEval_EvalCodeEx () from /usr/local/lib/libpython2.4.so.0.0
#37 0x0c5bf2f2 in function_call () from /usr/local/lib/libpython2.4.so.0.0
#38 0x0c5abe40 in PyObject_Call () from /usr/local/lib/libpython2.4.so.0.0
---Type <return> to continue, or q <return> to quit---
#39 0x0c600c6b in ext_do_call () from /usr/local/lib/libpython2.4.so.0.0
#40 0x0c5fe83c in PyEval_EvalFrame () from /usr/local/lib/libpython2.4.so.0.0
#41 0x0c5feeb6 in PyEval_EvalCodeEx () from /usr/local/lib/libpython2.4.so.0.0
#42 0x0c5bf2f2 in function_call () from /usr/local/lib/libpython2.4.so.0.0
#43 0x0c5abe40 in PyObject_Call () from /usr/local/lib/libpython2.4.so.0.0
#44 0x0c5b2bd4 in instancemethod_call ()
   from /usr/local/lib/libpython2.4.so.0.0
#45 0x0c5abe40 in PyObject_Call () from /usr/local/lib/libpython2.4.so.0.0
#46 0x0c5e5c9f in slot_tp_call () from /usr/local/lib/libpython2.4.so.0.0
#47 0x0c5abe40 in PyObject_Call () from /usr/local/lib/libpython2.4.so.0.0
#48 0x0c600aa1 in do_call () from /usr/local/lib/libpython2.4.so.0.0
#49 0x0c6002fa in call_function () from /usr/local/lib/libpython2.4.so.0.0
#50 0x0c5fe42f in PyEval_EvalFrame () from /usr/local/lib/libpython2.4.so.0.0
#51 0x0c6007b0 in fast_function () from /usr/local/lib/libpython2.4.so.0.0
#52 0x0c60036d in call_function () from /usr/local/lib/libpython2.4.so.0.0
#53 0x0c5fe42f in PyEval_EvalFrame () from /usr/local/lib/libpython2.4.so.0.0
#54 0x0c5feeb6 in PyEval_EvalCodeEx () from /usr/local/lib/libpython2.4.so.0.0
#55 0x0c60072f in fast_function () from /usr/local/lib/libpython2.4.so.0.0
#56 0x0c60036d in call_function () from /usr/local/lib/libpython2.4.so.0.0
#57 0x0c5fe42f in PyEval_EvalFrame () from /usr/local/lib/libpython2.4.so.0.0
#58 0x0c5feeb6 in PyEval_EvalCodeEx () from /usr/local/lib/libpython2.4.so.0.0
#59 0x0c5fc1a7 in PyEval_EvalCode () from /usr/local/lib/libpython2.4.so.0.0
#60 0x0c61d060 in run_node () from /usr/local/lib/libpython2.4.so.0.0
---Type <return> to continue, or q <return> to quit---
#61 0x0c61c0b1 in PyRun_SimpleFileExFlags ()
   from /usr/local/lib/libpython2.4.so.0.0
#62 0x0c61ba49 in PyRun_AnyFileExFlags ()
   from /usr/local/lib/libpython2.4.so.0.0
#63 0x0c622bab in Py_Main () from /usr/local/lib/libpython2.4.so.0.0
#64 0x1c000d60 in main ()

[Numpy-discussion] memory leak in array

[<saa...@sf...>]

Hi

I'm new to programming in python and I hope that this is the problem.

I've created a cellular automata program in python with the numpy array
extensions. After each cycle/iteration the memory used to examine and
change the array as determined by the transition rules is never freed.
I've tried using "del" on every variable possible, but that hasn't
worked. I've read all the forums for helpful hints on what to do, but
nothing has worked so far. I've even tried the "python memory
verification" (beta) program, which did point to numpy.dtype and
numpy.ndarray as increasing objects, before the whole computer crashed.

I can supply the code if needed. I'm desperate because this is part of
my thesis, and if I can't get this fixed, I'll try another programming
language.

Update: I posted this message on the comp.lang.python forum and their 
response was to get the numbers of references with sys.getrefcount(obj). 
After doing this I see that iterative counters used to count occurrences 
and nested loop counters (ii & jj) as seen in the code example below are the
culprits with the worst ones over 1M:

		 for ii in xrange(0,40):	
		    for jj in xrange(0,20):
			try:
			    nc = y[a+ii,b+jj]
			except IndexError: nc = 0
			
			if nc == "1" or nc == "5":
			    news = news +1
			    if news == 100:
				break
			    else:
				pass
			    y[a+ii,b+jj] = 4
			else:
			    pass


The version of python I'm using is 2.4.3 and the version of NumPy is 0.9.8



thanks in advance
Sonja 

[Numpy-discussion] acml and numpy install problems

[JJ <jos...@ya...>]

Hello.  I wrote to the list about a week ago regarding
slow speed of numpy relative to matlab.  Im fairly
sure that my installation of numpy had problems.  So I
am trying this time with the acml libraries for my AMD
Athelon 64 bit machine.  New machine with FC_5.  I was
able to install the acml libraries without much
trouble, and install UMFPACK and AMD without apparent
errors.  But I did have many errors when I tried to
install numpy.  My install messages are copied below. 
Apparently, numpy does see the acml libraries but
finds them faulty, or something.  I could use some
clues if anyone has any.  Also, I did set: 
setenv LD_LIBRARY_PATH /opt/acml3.1.0/gnu64/lib
# setenv LD_RUN_PATH /opt/acml3.1.0/gnu64/lib 

Here is my config file:
-----------------------------------
[atlas]
library_dirs = /opt/acml3.1.0/gnu64/lib
include_dirs = /opt/acml3.1.0/gnu64/include
atlas_libs = acml
language = f77

[blas]
library_dirs = /opt/acml3.1.0/gnu64/lib
include_dirs = /opt/acml3.1.0/gnu64/include
atlas_libs = acml
language = f77

[laplack]
library_dirs = /opt/acml3.1.0/gnu64/lib
include_dirs = /opt/acml3.1.0/gnu64/include
atlas_libs = acml
language = f77

[amd]
library_dirs = /usr/local/scipy/AMD/Lib
include_dirs = /usr/local/scipy/AMD/Include
amd_libs = amd
language =c

[umfpack]
library_dirs = /usr/local/scipy/UMFPACK/Lib
include_dirs = /usr/local/scipy/UMFPACK/Include
umfpack_libs = umfpack
language = c
------------------------------------
I have set symbolic links between lacml and libacml.

Here is the first half of the output, where most of
the errors are:
--------------------------------
[root@fedora-newamd numpy]# python setup.py install
Running from numpy source directory.
No module named __svn_version__
F2PY Version 2_2624
blas_opt_info:
blas_mkl_info:
  libraries mkl,vml,guide not find in /usr/local/lib
  libraries mkl,vml,guide not find in /usr/lib
  NOT AVAILABLE

atlas_blas_threads_info:
Setting PTATLAS=ATLAS
Setting PTATLAS=ATLAS
Setting PTATLAS=ATLAS
  FOUND:
    libraries = ['acml']
    library_dirs = ['/opt/acml3.1.0/gnu64/lib']
    language = c

customize GnuFCompiler
customize GnuFCompiler
customize GnuFCompiler using config
compiling '_configtest.c':

/* This file is generated from
numpy_distutils/system_info.py */
void ATL_buildinfo(void);
int main(void) {
  ATL_buildinfo();
  return 0;
}
C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG
-O2 -g -pipe -Wall -Wp,-D _FORTIFY_SOURCE=2
-fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic
-D_GNU_SOURCE -fPIC -fPIC

compile options: '-c'
gcc: _configtest.c
gcc -pthread _configtest.o -L/opt/acml3.1.0/gnu64/lib
-lacml -o _configtest
_configtest.o: In function `main':
/usr/local/numpy/_configtest.c:5: undefined reference
to `ATL_buildinfo'
/opt/acml3.1.0/gnu64/lib/libacml.so: undefined
reference to `do_lio'
/opt/acml3.1.0/gnu64/lib/libacml.so: undefined
reference to `e_wsle'
/opt/acml3.1.0/gnu64/lib/libacml.so: undefined
reference to `e_wsfe'
/opt/acml3.1.0/gnu64/lib/libacml.so: undefined
reference to `z_abs'
/opt/acml3.1.0/gnu64/lib/libacml.so: undefined 
... <snip> ...
reference to `s_wsle'
/opt/acml3.1.0/gnu64/lib/libacml.so: undefined
reference to `s_wsfe'
/opt/acml3.1.0/gnu64/lib/libacml.so: undefined
reference to `s_copy'
collect2: ld returned 1 exit status
_configtest.o: In function `main':
/usr/local/numpy/_configtest.c:5: undefined reference
to `ATL_buildinfo'
/opt/acml3.1.0/gnu64/lib/libacml.so: undefined
reference to `do_lio'
/opt/acml3.1.0/gnu64/lib/libacml.so: undefined
reference to `e_wsle'
/opt/acml3.1.0/gnu64/lib/libacml.so: undefined
reference to `e_wsfe'
... <snip> ...
reference to `s_wsle'
/opt/acml3.1.0/gnu64/lib/libacml.so: undefined
reference to `s_wsfe'
/opt/acml3.1.0/gnu64/lib/libacml.so: undefined
reference to `s_copy'
collect2: ld returned 1 exit status
failure.
removing: _configtest.c _configtest.o
Status: 255
Output:
  FOUND:
    libraries = ['acml']
    library_dirs = ['/opt/acml3.1.0/gnu64/lib']
    language = c
    define_macros = [('NO_ATLAS_INFO', 2)]

lapack_opt_info:
lapack_mkl_info:
mkl_info:
  libraries mkl,vml,guide not find in /usr/local/lib
  libraries mkl,vml,guide not find in /usr/lib
  NOT AVAILABLE

  NOT AVAILABLE

atlas_threads_info:
Setting PTATLAS=ATLAS
  libraries lapack_atlas not find in
/opt/acml3.1.0/gnu64/lib
  libraries lapack not find in
/opt/acml3.1.0/gnu64/lib
  libraries acml not find in /usr/local/lib
  libraries lapack_atlas not find in /usr/local/lib
  libraries acml not find in /usr/lib
  libraries lapack_atlas not find in /usr/lib
numpy.distutils.system_info.atlas_threads_info
Setting PTATLAS=ATLAS
/usr/local/numpy/numpy/distutils/system_info.py:881:
UserWarning:
*********************************************************************
    Could not find lapack library within the ATLAS
installation.
*********************************************************************

  warnings.warn(message)
Setting PTATLAS=ATLAS
  FOUND:
    libraries = ['acml']
    library_dirs = ['/opt/acml3.1.0/gnu64/lib']
    language = c
    define_macros = [('ATLAS_WITHOUT_LAPACK', None)]

customize GnuFCompiler
customize GnuFCompiler
customize GnuFCompiler using config
compiling '_configtest.c':

/* This file is generated from
numpy_distutils/system_info.py */
void ATL_buildinfo(void);
int main(void) {
  ATL_buildinfo();
  return 0;
}
C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG
-O2 -g -pipe -Wall -Wp,-D _FORTIFY_SOURCE=2
-fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic
-D_GNU_SOURCE -fPIC -fPIC

compile options: '-c'
gcc: _configtest.c
gcc -pthread _configtest.o -L/opt/acml3.1.0/gnu64/lib
-lacml -o _configtest
_configtest.o: In function `main':
/usr/local/numpy/_configtest.c:5: undefined reference
to `ATL_buildinfo'
/opt/acml3.1.0/gnu64/lib/libacml.so: undefined
reference to `do_lio'
/opt/acml3.1.0/gnu64/lib/libacml.so: undefined
reference to `e_wsle'
/opt/acml3.1.0/gnu64/lib/libacml.so: undefined
reference to `e_wsfe'

...<snip> ...
/opt/acml3.1.0/gnu64/lib/libacml.so: undefined
reference to `acos'
/opt/acml3.1.0/gnu64/lib/libacml.so: undefined
reference to `s_wsle'
/opt/acml3.1.0/gnu64/lib/libacml.so: undefined
reference to `s_wsfe'
/opt/acml3.1.0/gnu64/lib/libacml.so: undefined
reference to `s_copy'
collect2: ld returned 1 exit status
failure.
removing: _configtest.c _configtest.o
Status: 255
Output:
lapack_info:
  libraries lapack not find in /usr/local/lib
  libraries lapack not find in /usr/lib
  NOT AVAILABLE

/usr/local/numpy/numpy/distutils/system_info.py:1163:
UserWarning:
    Lapack (http://www.netlib.org/lapack/) libraries
not found.
    Directories to search for the libraries can be
specified in the
    numpy/distutils/site.cfg file (section [lapack])
or by setting
    the LAPACK environment variable.
  warnings.warn(LapackNotFoundError.__doc__)
lapack_src_info:
  NOT AVAILABLE

/usr/local/numpy/numpy/distutils/system_info.py:1166:
UserWarning:
    Lapack (http://www.netlib.org/lapack/) sources not
found.
    Directories to search for the sources can be
specified in the
    numpy/distutils/site.cfg file (section
[lapack_src]) or by setting
    the LAPACK_SRC environment variable.
  warnings.warn(LapackSrcNotFoundError.__doc__)
  NOT AVAILABLE

running install
running build
running config_fc
running build_src
building py_modules sources
creating build
creating build/src.linux-x86_64-2.4
creating build/src.linux-x86_64-2.4/numpy
creating build/src.linux-x86_64-2.4/numpy/distutils
building extension "numpy.core.multiarray" sources
creating build/src.linux-x86_64-2.4/numpy/core
Generating
build/src.linux-x86_64-2.4/numpy/core/config.h
customize GnuFCompiler
customize GnuFCompiler
customize GnuFCompiler using config
C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG
-O2 -g -pipe -Wall -Wp,-D _FORTIFY_SOURCE=2
-fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic
-D_GNU_SOURCE -fPIC -fPIC

compile options: '-I/usr/include/python2.4
-Inumpy/core/src -Inumpy/core/include 
-I/usr/include/python2.4 -c'
gcc: _configtest.c
_configtest.c: In function ‘main’:
_configtest.c:50: warning: format ‘%d’ expects type
‘int’, but argument 4 has ty pe ‘long unsigned int’
_configtest.c:57: warning: format ‘%d’ expects type
‘int’, but argument 4 has ty pe ‘long unsigned int’
_configtest.c:72: warning: format ‘%d’ expects type
‘int’, but argument 4 has ty pe ‘long unsigned int’
gcc -pthread _configtest.o -L/usr/local/lib -L/usr/lib
-o _configtest
/usr/bin/ld: skipping incompatible
/usr/lib/libpthread.so when searching for -lp thread
/usr/bin/ld: skipping incompatible
/usr/lib/libpthread.a when searching for -lpt hread
/usr/bin/ld: skipping incompatible /usr/lib/libc.so
when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib/libc.a
when searching for -lc
_configtest
success!
removing: _configtest.c _configtest.o _configtest
C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG
-O2 -g -pipe -Wall -Wp,-D _FORTIFY_SOURCE=2
-fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic
-D_GNU_SOURCE -fPIC -fPIC

compile options: '-Inumpy/core/src
-Inumpy/core/include -I/usr/include/python2.4  -c'
gcc: _configtest.c
gcc -pthread _configtest.o -o _configtest
_configtest.o: In function `main':
/usr/local/numpy/_configtest.c:5: undefined reference
to `exp'
collect2: ld returned 1 exit status
_configtest.o: In function `main':
/usr/local/numpy/_configtest.c:5: undefined reference
to `exp'
collect2: ld returned 1 exit status
failure.
removing: _configtest.c _configtest.o
C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG
-O2 -g -pipe -Wall -Wp,-D _FORTIFY_SOURCE=2
-fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic
-D_GNU_SOURCE -fPIC -fPIC

compile options: '-Inumpy/core/src
-Inumpy/core/include -I/usr/include/python2.4  -c'
gcc: _configtest.c
gcc -pthread _configtest.o -lm -o _configtest
_configtest
success!
removing: _configtest.c _configtest.o _configtest
C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG
-O2 -g -pipe -Wall -Wp,-D _FORTIFY_SOURCE=2
-fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic
-D_GNU_SOURCE -fPIC -fPIC

compile options: '-Inumpy/core/src
-Inumpy/core/include -I/usr/include/python2.4  -c'
gcc: _configtest.c
_configtest.c: In function ‘main’:
_configtest.c:4: warning: statement with no effect
gcc -pthread _configtest.o -lm -o _configtest
success!
removing: _configtest.c _configtest.o _configtest
C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG
-O2 -g -pipe -Wall -Wp,-D _FORTIFY_SOURCE=2
-fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic
-D_GNU_SOURCE -fPIC -fPIC

compile options: '-Inumpy/core/src
-Inumpy/core/include -I/usr/include/python2.4  -c'
gcc: _configtest.c
_configtest.c: In function ‘main’:
_configtest.c:4: warning: statement with no effect
gcc -pthread _configtest.o -lm -o _configtest
success!
removing: _configtest.c _configtest.o _configtest
C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG
-O2 -g -pipe -Wall -Wp,-D _FORTIFY_SOURCE=2
-fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic
-D_GNU_SOURCE -fPIC -fPIC

compile options: '-Inumpy/core/src
-Inumpy/core/include -I/usr/include/python2.4  -c'
gcc: _configtest.c
_configtest.c: In function ‘main’:
_configtest.c:4: warning: statement with no effect
gcc -pthread _configtest.o -lm -o _configtest
success!
removing: _configtest.c _configtest.o _configtest
C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG
-O2 -g -pipe -Wall -Wp,-D _FORTIFY_SOURCE=2
-fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic
-D_GNU_SOURCE -fPIC -fPIC

compile options: '-Inumpy/core/src
-Inumpy/core/include -I/usr/include/python2.4  -c'
gcc: _configtest.c
_configtest.c: In function ‘main’:
_configtest.c:4: warning: statement with no effect
gcc -pthread _configtest.o -lm -o _configtest
success!
removing: _configtest.c _configtest.o _configtest
C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG
-O2 -g -pipe -Wall -Wp,-D _FORTIFY_SOURCE=2
-fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic
-D_GNU_SOURCE -fPIC -fPIC

compile options: '-Inumpy/core/src
-Inumpy/core/include -I/usr/include/python2.4  -c'
gcc: _configtest.c
_configtest.c: In function ‘main’:
_configtest.c:4: warning: statement with no effect
gcc -pthread _configtest.o -lm -o _configtest
success!
removing: _configtest.c _configtest.o _configtest
C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG
-O2 -g -pipe -Wall -Wp,-D _FORTIFY_SOURCE=2
-fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic
-D_GNU_SOURCE -fPIC -fPIC

compile options: '-Inumpy/core/src
-Inumpy/core/include -I/usr/include/python2.4  -c'
gcc: _configtest.c
_configtest.c: In function ‘main’:
_configtest.c:4: warning: statement with no effect
gcc -pthread _configtest.o -lm -o _configtest
success!
removing: _configtest.c _configtest.o _configtest
C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG
-O2 -g -pipe -Wall -Wp,-D _FORTIFY_SOURCE=2
-fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic
-D_GNU_SOURCE -fPIC -fPIC

compile options: '-Inumpy/core/src
-Inumpy/core/include -I/usr/include/python2.4  -c'
gcc: _configtest.c
_configtest.c: In function ‘main’:
_configtest.c:4: warning: statement with no effect
gcc -pthread _configtest.o -lm -o _configtest
success!
removing: _configtest.c _configtest.o _configtest
C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG
-O2 -g -pipe -Wall -Wp,-D _FORTIFY_SOURCE=2
-fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic
-D_GNU_SOURCE -fPIC -fPIC

compile options: '-Inumpy/core/src
-Inumpy/core/include -I/usr/include/python2.4  -c'
gcc: _configtest.c
_configtest.c: In function ‘main’:
_configtest.c:4: warning: statement with no effect
gcc -pthread _configtest.o -lm -o _configtest
success!
removing: _configtest.c _configtest.o _configtest
C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG
-O2 -g -pipe -Wall -Wp,-D _FORTIFY_SOURCE=2
-fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic
-D_GNU_SOURCE -fPIC -fPIC

compile options: '-Inumpy/core/src
-Inumpy/core/include -I/usr/include/python2.4  -c'
gcc: _configtest.c
_configtest.c: In function ‘main’:
_configtest.c:4: warning: statement with no effect
gcc -pthread _configtest.o -lm -o _configtest
success!
removing: _configtest.c _configtest.o _configtest
C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG
-O2 -g -pipe -Wall -Wp,-D _FORTIFY_SOURCE=2
-fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic
-D_GNU_SOURCE -fPIC -fPIC

compile options: '-Inumpy/core/src
-Inumpy/core/include -I/usr/include/python2.4  -c'
gcc: _configtest.c
_configtest.c: In function ‘main’:
_configtest.c:4: warning: statement with no effect
gcc -pthread _configtest.o -lm -o _configtest
success!
removing: _configtest.c _configtest.o _configtest
  adding
'build/src.linux-x86_64-2.4/numpy/core/config.h' to
sources.
executing
numpy/core/code_generators/generate_array_api.py
  adding
'build/src.linux-x86_64-2.4/numpy/core/__multiarray_api.h'
to sources.
creating build/src.linux-x86_64-2.4/numpy/core/src
conv_template:>
build/src.linux-x86_64-2.4/numpy/core/src/scalartypes.inc
  adding 'build/src.linux-x86_64-2.4/numpy/core/src'
to include_dirs.
conv_template:>
build/src.linux-x86_64-2.4/numpy/core/src/arraytypes.inc
numpy.core - nothing done with h_files=
['build/src.linux-x86_64-2.4/numpy/core/
src/scalartypes.inc',
'build/src.linux-x86_64-2.4/numpy/core/src/arraytypes.inc'
, 'build/src.linux-x86_64-2.4/numpy/core/config.h',
'build/src.linux-x86_64-2.4/
numpy/core/__multiarray_api.h']
building extension "numpy.core.umath" sources
  adding
'build/src.linux-x86_64-2.4/numpy/core/config.h' to
sources.
executing
numpy/core/code_generators/generate_ufunc_api.py
  adding
'build/src.linux-x86_64-2.4/numpy/core/__ufunc_api.h'
to sources.
conv_template:>
build/src.linux-x86_64-2.4/numpy/core/src/umathmodule.c
  adding 'build/src.linux-x86_64-2.4/numpy/core/src'
to include_dirs.
numpy.core - nothing done with h_files=
['build/src.linux-x86_64-2.4/numpy/core/
src/scalartypes.inc',
'build/src.linux-x86_64-2.4/numpy/core/src/arraytypes.inc'
, 'build/src.linux-x86_64-2.4/numpy/core/config.h',
'build/src.linux-x86_64-2.4/
numpy/core/__ufunc_api.h']
building extension "numpy.core._sort" sources
  adding
'build/src.linux-x86_64-2.4/numpy/core/config.h' to
sources.
  adding
'build/src.linux-x86_64-2.4/numpy/core/__multiarray_api.h'
to sources.
conv_template:>
build/src.linux-x86_64-2.4/numpy/core/src/_sortmodule.c
numpy.core - nothing done with h_files=
['build/src.linux-x86_64-2.4/numpy/core/ config.h',
'build/src.linux-x86_64-2.4/numpy/core/__multiarray_api.h']
building extension "numpy.core.scalarmath" sources
  adding
'build/src.linux-x86_64-2.4/numpy/core/config.h' to
sources.
  adding
'build/src.linux-x86_64-2.4/numpy/core/__multiarray_api.h'
to sources.
  adding
'build/src.linux-x86_64-2.4/numpy/core/__ufunc_api.h'
to sources.
conv_template:>
build/src.linux-x86_64-2.4/numpy/core/src/scalarmathmodule.c
numpy.core - nothing done with h_files=
['build/src.linux-x86_64-2.4/numpy/core/ config.h',
'build/src.linux-x86_64-2.4/numpy/core/__multiarray_api.h',
'build/sr
c.linux-x86_64-2.4/numpy/core/__ufunc_api.h']
building extension "numpy.core._dotblas" sources
  adding 'numpy/core/blasdot/_dotblas.c' to sources.
building extension "numpy.lib._compiled_base" sources
building extension "numpy.dft.fftpack_lite" sources
building extension "numpy.linalg.lapack_lite" sources
creating build/src.linux-x86_64-2.4/numpy/linalg
### Warning:  Using unoptimized lapack ###
---------------------------------------------
Any ideas?  I am still a novice and could use some
suggestions.  Thanks much.  JJ

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Numpy-discussion] Don't like the short names like lstsq and irefft

[Scott R. <sr...@nr...>]

On Wed, Jun 14, 2006 at 09:47:20PM -0700, Paul Dubois wrote:
> And yes, I think FFT is a name. (:->  Exception for that.

I agree.  As are sinh, cosh, tanh, sinc, exp, log10 and various
other very commonly used (and not only in programming) names.
lstsq, eig, irefft, etc are not.

Scott

-- 
Scott M. Ransom            Address:  NRAO
Phone:  (434) 296-0320               520 Edgemont Rd.
email:  sr...@nr...             Charlottesville, VA 22903 USA
GPG Fingerprint: 06A9 9553 78BE 16DB 407B  FFCA 9BFA B6FF FFD3 2989

Re: [Numpy-discussion] Don't like the short names like lstsq and irefft

[Paul D. <pfd...@gm...>]

Bertrand Meyer has pointed out that abbreviations are usually a bad idea.
The problem is that abbreviations are not unique so you can't guess what
they are. Whereas (modulo some library-wide conventions about names)
linearLeastSquares or the like is unique. At the very least you're more
likely to get it right.

Any python user can abbreviate anything they like any way they like for
interactive work.

And yes, I think FFT is a name. (:->  Exception for that.