From irving at naml.us Fri Oct 1 00:04:19 2010 From: irving at naml.us (Geoffrey Irving) Date: Fri, 1 Oct 2010 17:04:19 +1300 Subject: [Numpy-discussion] constant shaded triangle mesh in mayavi2 In-Reply-To: References: Message-ID: On Fri, Oct 1, 2010 at 11:39 AM, Robert Kern wrote: > On Thu, Sep 30, 2010 at 16:26, Geoffrey Irving wrote: >> On Fri, Oct 1, 2010 at 10:18 AM, Robert Kern wrote: >>> On Thu, Sep 30, 2010 at 16:00, Geoffrey Irving wrote: >>>> On Fri, Oct 1, 2010 at 9:38 AM, Robert Kern wrote: >>>>> On Thu, Sep 30, 2010 at 15:30, Geoffrey Irving wrote: >>>>>> Hello, >>>>>> >>>>>> I'm not sure where the correct place to ask questions about Mayavi, so >>>>>> feel free to redirect me elsewhere. >>>>> >>>>> https://mail.enthought.com/mailman/listinfo/enthought-dev >>>>> >>>>>> I have a triangle mesh with a bunch of data on each face. ?The only >>>>>> color-relevant argument to triangular_mesh I know about is scalars, >>>>>> which is one value per vertex. ?Is there a way to set color per >>>>>> triangle, ideally with control over rgb separately so I can visualize >>>>>> three different fields at once? >>>>> >>>>> Pretty difficult, unfortunately. The only way I have found is to >>>>> assign UV texture coordinates to the vertices and slap on a texture. >>>>> Assigning the UV coordinates is usually not easy. >>>> >>>> Is this a limitation in VTK, TVTK, or the Mayavi python code? ?The VTK >>>> documentation seems to imply it supports cell data on polygon meshes >>>> (though I don't know how one would set them): >>>> >>>> ? ?http://www.vtk.org/doc/release/5.6/html/a01445.html >>>> ? ?"Point and cell attribute values (e.g., scalars, vectors, etc.) >>>> also are represented" >>>> >>>> I'm happy to hack TVTK or Mayavi (in order of happiness) to support >>>> cell data if VTK supports it. >>> >>> It's a VTK restriction. You can store whatever data you like on the on >>> the vertices or cells. There is no mapper (that I am aware of) that >>> takes that data and interprets them as RGB values on a per-vertex or >>> per-cell basis. There are mappers that turn scalar vertex and cell >>> attribute values into colors through a colormap table, but that's not >>> what you are asking for. >> >> Visualizing a signle cell scalar field is still quite useful (the data >> doesn't correspond to color). ?In other words, the per-cell part of >> the question is more important than than the RGB part. ?Is there a >> current way to set a cell attribute value on a Mayavi triangular_mesh? > > You're better off not using triangular_mesh(). Construct the mesh > separately from the surface. > > ?s = mlab.pipeline.triangular_mesh_source(x,y,z,triangles) > ?s.data.cell_data.scalars = .... # Your data here. > ?surf = mlab.pipeline.surface(s) > ?surf.contours.filled_contours = True Cool, that seems to work for static plots (with "contours" replaced with "contour"). However, it breaks dynamic updates if I change data interactively on trait changes. For vertex data, I'm using the following code for interactive updates: @on_trait_change('threshold') def update_plot(self): self.plot.mlab_source.set(scalars=self.scalars()) borrowed from http://code.enthought.com/projects/mayavi/docs/development/html/mayavi/auto/example_mlab_interactive_dialog.html#example-mlab-interactive-dialog where plot is generated with triangular_mesh(). How do I force an update of the surface if I generate it myself and use cell data? Thanks, Geoffrey From faltet at pytables.org Fri Oct 1 03:13:40 2010 From: faltet at pytables.org (Francesc Alted) Date: Fri, 1 Oct 2010 09:13:40 +0200 Subject: [Numpy-discussion] NPZ format In-Reply-To: References: <201009291017.46955.faltet@pytables.org> Message-ID: <201010010913.40253.faltet@pytables.org> A Thursday 30 September 2010 18:20:16 Robert Kern escrigu?: > On Wed, Sep 29, 2010 at 03:17, Francesc Alted wrote: > > Hi, > > > > I'm going to give a seminar about serialization, and I'd like to > > describe the .npy format. I noticed that there is a variant of it > > called .npz that can pack several arrays in one single file. > > > > However, .npz does not use compression at all and I'm wondering > > what's the reason. I suppose that this is because you don't want > > to loose the possibility to memmap saved arrays, but can someone > > confirm this? > > While I suspect it's possible, I'm certain we don't have any code > that actually does it. Most likely the author assumed that it would > be faster (or tested it to be faster with their CPU/hard disk > configuration) to not compress. Thanks, that's good to know. And yes, I'd say that compressing with zip (zlib) would reduce performance for doing I/O, but most probably decompressing from disk media would represent an improvement in terms of time. At any rate, adding compression capability to .npy should be just one parameter away, so perhaps is a good idea adding it. -- Francesc Alted From stefan at sun.ac.za Fri Oct 1 03:51:59 2010 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Fri, 1 Oct 2010 09:51:59 +0200 Subject: [Numpy-discussion] Improvements to SciPy.org Server In-Reply-To: References: Message-ID: On Thu, Sep 30, 2010 at 9:15 AM, Sebastian Haase wrote: > On this note, > I looked at this page and the first two links I looked at (pycode & > graceplot) where broken ... > Is there a tool to highlight broken links in some way .... ? http://mentat.za.net/numpy/topical_webcheck/ This is just a static page showing the results for the page in its current state. Did I hear someone volunteering to fix these? :) Regards St?fan From seb.haase at gmail.com Fri Oct 1 05:26:33 2010 From: seb.haase at gmail.com (Sebastian Haase) Date: Fri, 1 Oct 2010 11:26:33 +0200 Subject: [Numpy-discussion] ndarray: subclassing a subclass looses custom attribute Message-ID: Hi, I'm trying to add a 'meta' attribute to ndarray to keep track of image data filenames and resolution etc. Following the excellent document http://docs.scipy.org/doc/numpy/user/basics.subclassing.html this worked right away. However, I had done this before for some specific image-file-types: those would add there own attribute to ndarray array (e.g. arr.Mrc) Now if I call the new ndarray_meta on my ndarray_with_mrc I loose the `Mrc` attribute, leaving only the new `meta` attribute. My code is essentially a verbatim copy of http://docs.scipy.org/doc/numpy/user/basics.subclassing.html#simple-example-adding-an-extra-attribute-to-ndarray What can I do ? Thanks, Sebastian Haase From seb.haase at gmail.com Fri Oct 1 05:31:37 2010 From: seb.haase at gmail.com (Sebastian Haase) Date: Fri, 1 Oct 2010 11:31:37 +0200 Subject: [Numpy-discussion] ndarray: subclassing a subclass looses custom attribute In-Reply-To: References: Message-ID: On Fri, Oct 1, 2010 at 11:26 AM, Sebastian Haase wrote: > Hi, > I'm trying to add a 'meta' attribute to ndarray to keep track of image > data filenames and resolution etc. > Following ?the excellent document > http://docs.scipy.org/doc/numpy/user/basics.subclassing.html > this worked right away. > > However, I had done this before for some specific image-file-types: > those would add there own attribute to ndarray array (e.g. arr.Mrc) > Now if I call the new ?ndarray_meta on my ndarray_with_mrc I loose the > `Mrc` attribute, leaving only the new `meta` attribute. > My code is essentially a verbatim copy of > http://docs.scipy.org/doc/numpy/user/basics.subclassing.html#simple-example-adding-an-extra-attribute-to-ndarray > > What can I do ? > > Thanks, > Sebastian Haase > Sorry, the code I used is this: http://docs.scipy.org/doc/numpy/user/basics.subclassing.html#slightly-more-realistic-example-attribute-added-to-existing-array I tried replacing asarray with asanyarray - but that did seem to make any difference... Thanks, Sebastian From pgmdevlist at gmail.com Fri Oct 1 06:38:54 2010 From: pgmdevlist at gmail.com (Pierre GM) Date: Fri, 1 Oct 2010 12:38:54 +0200 Subject: [Numpy-discussion] ndarray: subclassing a subclass looses custom attribute In-Reply-To: References: Message-ID: <6C2209EC-2770-4592-9353-6ED4F8ED7F98@gmail.com> On Oct 1, 2010, at 11:26 AM, Sebastian Haase wrote: > Hi, > I'm trying to add a 'meta' attribute to ndarray to keep track of image > data filenames and resolution etc. > Following the excellent document > http://docs.scipy.org/doc/numpy/user/basics.subclassing.html > this worked right away. > > However, I had done this before for some specific image-file-types: > those would add there own attribute to ndarray array (e.g. arr.Mrc) > Now if I call the new ndarray_meta on my ndarray_with_mrc I loose the > `Mrc` attribute, leaving only the new `meta` attribute. > My code is essentially a verbatim copy of > http://docs.scipy.org/doc/numpy/user/basics.subclassing.html#simple-example-adding-an-extra-attribute-to-ndarray > > What can I do ? Post your code, so that we can see what you actually did. If I had to guess, I'd say you forgot to define your 'Mrc' attribute in your ndarray_meta.__array_finalize__. But once again, without some code, it's only a guess. From seb.haase at gmail.com Fri Oct 1 07:03:53 2010 From: seb.haase at gmail.com (Sebastian Haase) Date: Fri, 1 Oct 2010 13:03:53 +0200 Subject: [Numpy-discussion] ndarray: subclassing a subclass looses custom attribute In-Reply-To: <6C2209EC-2770-4592-9353-6ED4F8ED7F98@gmail.com> References: <6C2209EC-2770-4592-9353-6ED4F8ED7F98@gmail.com> Message-ID: On Fri, Oct 1, 2010 at 12:38 PM, Pierre GM wrote: > > On Oct 1, 2010, at 11:26 AM, Sebastian Haase wrote: > >> Hi, >> I'm trying to add a 'meta' attribute to ndarray to keep track of image >> data filenames and resolution etc. >> Following ?the excellent document >> http://docs.scipy.org/doc/numpy/user/basics.subclassing.html >> this worked right away. >> >> However, I had done this before for some specific image-file-types: >> those would add there own attribute to ndarray array (e.g. arr.Mrc) >> Now if I call the new ?ndarray_meta on my ndarray_with_mrc I loose the >> `Mrc` attribute, leaving only the new `meta` attribute. >> My code is essentially a verbatim copy of >> http://docs.scipy.org/doc/numpy/user/basics.subclassing.html#simple-example-adding-an-extra-attribute-to-ndarray >> >> What can I do ? > > Post your code, so that we can see what you actually did. > > If I had to guess, I'd say you forgot to define your 'Mrc' attribute in your ndarray_meta.__array_finalize__. But once again, without some code, it's only a guess. class ndarray_inMrcFile(ndarray): def __new__(cls, input_array, mrcInfo=None): obj = asanyarray(input_array).view(cls) obj.Mrc = mrcInfo return obj def __array_finalize__(self, obj): if obj is None: return self.Mrc = getattr(obj, 'Mrc', None) class ndarray_meta(ndarray): def __new__(cls, input_array, meta=None): obj = asanyarray(input_array).view(cls) obj.meta = nd_meta_attribute( meta ) return obj def __array_finalize__(self, obj): if obj is None: return self.meta = getattr(obj, 'meta', nd_meta_attribute()) So, ndarray_meta is (like ndarray_inMrcFile) derived from ndarray; not one from the other, because ndarray_meta is supposed to be generic and ndarray_inMrcFile is just one example of a ndarray derived class. Thanks for looking at this -- Sebastian From pgmdevlist at gmail.com Fri Oct 1 08:20:15 2010 From: pgmdevlist at gmail.com (Pierre GM) Date: Fri, 1 Oct 2010 14:20:15 +0200 Subject: [Numpy-discussion] ndarray: subclassing a subclass looses custom attribute In-Reply-To: References: <6C2209EC-2770-4592-9353-6ED4F8ED7F98@gmail.com> Message-ID: On Oct 1, 2010, at 1:03 PM, Sebastian Haase wrote: >>> However, I had done this before for some specific image-file-types: >>> those would add there own attribute to ndarray array (e.g. arr.Mrc) >>> Now if I call the new ndarray_meta on my ndarray_with_mrc I loose the >>> `Mrc` attribute, leaving only the new `meta` attribute. >>> My code is essentially a verbatim copy of >>> http://docs.scipy.org/doc/numpy/user/basics.subclassing.html#simple-example-adding-an-extra-attribute-to-ndarray >>> >>> What can I do ? > > class ndarray_inMrcFile(ndarray): > def __new__(cls, input_array, mrcInfo=None): > obj = asanyarray(input_array).view(cls) > obj.Mrc = mrcInfo > return obj > > def __array_finalize__(self, obj): > if obj is None: return > self.Mrc = getattr(obj, 'Mrc', None) > > class ndarray_meta(ndarray): > def __new__(cls, input_array, meta=None): > obj = asanyarray(input_array).view(cls) > obj.meta = nd_meta_attribute( meta ) > return obj > > def __array_finalize__(self, obj): > if obj is None: return > self.meta = getattr(obj, 'meta', nd_meta_attribute()) Ah, OK, now I understand the problem. When you create a ndarray_meta from an object, it is transform into a ndarray_meta at the `asanyarray(...).view(cls)` line, which calls ndarray_meta.__array_finalize__. In that method, you don't keep track of what `obj` is, you just check whether it has a 'meta' attribute: all the other attributes it could have are stripped. If you want to keep them, you have to define them explicitly in your array_finalize... That can be a bit tricky if you want to avoid having your objects subclasses one of the other. However, these extra attributes should be defined in the __dict__ of your class, right? So, if you update the __dict__ of self with the __dict__ of obj, that should do the trick: class ndarray_inMrcFile(ndarray): def __new__(cls, input_array, mrcInfo=None): obj = asanyarray(input_array).view(cls) obj.Mrc = mrcInfo return obj def __array_finalize__(self, obj): if obj is None: return self.Mrc = getattr(obj, 'Mrc', None) self.__dict__.update(getattr(obj, "__dict__", {})) class ndarray_meta(ndarray): def __new__(cls, input_array, meta=None): obj = asanyarray(input_array).view(cls) obj.meta = nd_meta_attribute( meta ) return obj def __array_finalize__(self, obj): if obj is None: return self.meta = getattr(obj, 'meta', nd_meta_attribute(None)) self.__dict__.update(getattr(obj, "__dict__", {})) That works, but modifying the __dict__ that way can have some nasty side effects (well, I wouldn't be surprised if it had some, more experienced users will comment on that). A cleaner, albeit slightly more cumbersome and less directly extendable approach, would be to define a generic ndarray subclass, where you define a `_addattr` attribute as a dictionary. Store the attributes specific to your subclasses in that dictionary, and update it in the __array_finalize__: basically, your `_addattr` plays the role of __dict__, but you're not messing w/ __dict__ itself. You can access your attributes through this `_addattr` dictionary. As you'll probably need direct attribute access, you can define specific methods, or define the attribute as property: @property ndarray_inMrc.MRC(self) return self._addattr['MRC'] or with a combo _get_MRC/_set_MRC/MRC=property(_get_MRC,_set_MRC)... You get the idea. Let me know how it goes. If it works, please consider writing something to add to the doc or the wiki, so that we can keep track of it. Cheers P. From jesper.webmail at gmail.com Fri Oct 1 08:41:13 2010 From: jesper.webmail at gmail.com (Jesper Larsen) Date: Fri, 1 Oct 2010 14:41:13 +0200 Subject: [Numpy-discussion] Masked arrays to Compressed arrays Message-ID: Hi numpy users I am using masked arrays (MA) for gridded ocean forecast fields (temperature, salinity, sea level and so on). These fields always have the same masked elements (land). And in some cases memory usage is a real issue. I have therefore made a class which stores masked arrays in a more memory efficient way than the standard MA (I am calling it Compressed arrays). Furthermore in some of my applications I perform arithmetics which only needs to update the unmasked values in the array and do not need to know anything per se about the mask. I have therefore tried to put logic into my class which takes advantage of this knowledge and applies the arithmetic operators efficiently only on the unmasked values. MA stores as far as I know two arrays: one containing the data values and one containing the mask. Both have the same shape. My class stores the mask (or rather a flattened version of it and shape info) and a 1D data array which only contains values at unmasked elements. The class is not entirely finished but I would like to hear your constructive criticism of it. So to summarize: 1. Uses less memory except when temporarily converting to masked array (for example to perform arithmetics - hints on avoiding this would be greatly appreciated). 2. Has more efficient arithmetics in some cases. 3. Is less efficient in other cases. Here is the class (I know that the inline arithmetic operator overrides are wrong). I hope you have some good suggestions. I have not subclassed MA but that might be an alternative solution: """ Compressed array. A compressed array is an alternative to numpy masked arrays designed to reduce memory consumption. Jesper Larsen, 2010 """ # External imports import numpy as np def _compress(arr): """Compresses array.""" mask = np.ma.getmaskarray(arr) arrout = np.ma.compressed(arr) return arrout, mask def _decompress(arr, mask_flat, shape): """Decompresses array.""" arr_out = np.ma.masked_all(mask_flat.shape, dtype=arr.dtype) arr_out[~mask_flat] = arr[:] arr_out = arr_out.reshape(shape) return arr_out class carray(object): """Compressed array.""" def __init__(self, array, mask=None, same_masks=False): """\ Compressed array. Can be initialized with either a masked array instance or a flat numpy array and corresponding mask. If same_masks is set to True it is assumed that arithmetic operations on two such carrays with identical shapes have identical mask and thus optimized arithmetics can be used for some operations. """ if isinstance(array, np.ma.masked_array): # Initialize from masked array self.carray, mask = _compress(array) self.shape = mask.shape self._mask_flat = mask.ravel() elif isinstance(array, np.ndarray): # Construct a compressed array from raw input. if mask is None: raise TypeError('Mask must be present') self.carray = array self.shape = mask.shape self._mask_flat = mask.ravel() else: raise TypeError('Invalid input type') self.same_masks = True def __getattr__(self, name): """Override attribute access.""" if name == 'masked_array': return _decompress(self.carray, self._mask_flat, self.shape) if name == 'mask': return self._mask_flat.reshape(self.shape) else: # Find attribute in array data structure return getattr(self.masked_array, name) raise AttributeError(name) def __setattr__(self, name, value): """Override attribute access.""" if name == 'masked_array': self.carray, mask = _compress(value) self.shape = mask.shape self._mask_flat = mask.ravel() else: object.__setattr__(self, name, value) def _optimized_arithmetics(self, method, *args): """\ Generic method for efficiently performing arithmetics on compressed arrays. """ if len(args) > 0 and isinstance(args[0], carray): other = args[0] else: other = None if other is None: np_method = getattr(self.carray, method) carr = np_method(*args) return carray(carr, self.mask) elif self is other: np_method = getattr(self.carray, method) carr = np_method(other.carray, *args[1:]) return carray(carr, self.mask) elif self.same_masks and other.same_masks and \ self.shape == other.shape: np_method = getattr(self.carray, method) carr = np_method(other.carray, *args[1:]) return carray(carr, self.mask) else: ma_method = getattr(self.masked_array, method) return carray(ma_method(*args)) def _optimized_arithmetic_methods(self, method, *args, **kwargs): """\ Generic method for effiently applying arithmetic methods on compressed arrays. """ if len(args) == 0 and 'axis' not in kwargs: np_method = getattr(self.carray, method) carr = np_method(*args, **kwargs) if isinstance(carr, np.ndarray): return carray(carr, self.mask) else: return carr else: ma_method = getattr(self.masked_array, method) return carray(ma_method(*args, **kwargs)) """Expose access to the "masked_array" container at the top level""" def __repr__(self): return 'carray(\n' + self.masked_array.__repr__() + ')\n' def __str__(self): return self.masked_array.__str__() def __len__(self): return self.masked_array.__len__() def __getitem__(self, index): return self.masked_array.__getitem__(index) def __setitem__(self, index, value): return self.masked_array.__setitem__(index, value) def __delitem__(self, index): return self.masked_array.__delitem__(index) def __iter__(self): return self.masked_array.__iter__() def __contains__(self, item): return self.masked_array.__contains(item) """Optimized arithmetics""" def __add__(self, *args): return self._optimized_arithmetics('__add__', *args) def __sub__(self, *args): return self._optimized_arithmetics('__sub__', *args) def __mul__(self, *args): return self._optimized_arithmetics('__mul__', *args) def __floordiv__(self, *args): return self._optimized_arithmetics('__floordiv__', *args) def __mod__(self, *args): return self._optimized_arithmetics('__mod__', *args) def __divmod__(self, *args): return self._optimized_arithmetics('__divmod__', *args) def __pow__(self, *args): return self._optimized_arithmetics('__pow__', *args) def __lshift__(self, *args): return self._optimized_arithmetics('__lshift__', *args) def __rshift__(self, *args): return self._optimized_arithmetics('__rshift__', *args) def __and__(self, *args): return self._optimized_arithmetics('__and__', *args) def __xor__(self, *args): return self._optimized_arithmetics('__xor__', *args) def __or__(self, *args): return self._optimized_arithmetics('__or__', *args) def __div__(self, *args): return self._optimized_arithmetics('__div__', *args) def __truediv__(self, *args): return self._optimized_arithmetics('__truediv__', *args) def __radd__(self, *args): return self._optimized_arithmetics('__radd__', *args) def __rsub__(self, *args): return self._optimized_arithmetics('__rsub__', *args) def __rmul__(self, *args): return self._optimized_arithmetics('__rmul__', *args) def __rdiv__(self, *args): return self._optimized_arithmetics('__rdiv__', *args) def __rtruediv__(self, *args): return self._optimized_arithmetics('__rtruediv__', *args) def __rfloordiv__(self, *args): return self._optimized_arithmetics('__rfloordiv__', *args) def __rmod__(self, *args): return self._optimized_arithmetics('__rmod__', *args) def __rdivmod__(self, *args): return self._optimized_arithmetics('__rdivmod__', *args) def __rpow__(self, *args): return self._optimized_arithmetics('__rpow__', *args) def __rlshift__(self, *args): return self._optimized_arithmetics('__rlshift__', *args) def __rrshift__(self, *args): return self._optimized_arithmetics('__rrshift__', *args) def __rand__(self, *args): return self._optimized_arithmetics('__rand__', *args) def __rxor__(self, *args): return self._optimized_arithmetics('__rxor__', *args) def __ror__(self, *args): return self._optimized_arithmetics('__ror__', *args) def __iadd__(self, *args): return self._optimized_arithmetics('__iadd__', *args) def __isub__(self, *args): return self._optimized_arithmetics('__isub__', *args) def __imul__(self, *args): return self._optimized_arithmetics('__imul__', *args) def __idiv__(self, *args): return self._optimized_arithmetics('__idiv__', *args) def __itruediv__(self, *args): return self._optimized_arithmetics('__itruediv__', *args) def __ifloordiv__(self, *args): return self._optimized_arithmetics('__ifloordiv__', *args) def __imod__(self, *args): return self._optimized_arithmetics('__imod__', *args) def __ipow__(self, *args): return self._optimized_arithmetics('__ipow__', *args) def __ilshift__(self, *args): return self._optimized_arithmetics('__ilshift__', *args) def __irshift__(self, *args): return self._optimized_arithmetics('__irshift__', *args) def __iand__(self, *args): return self._optimized_arithmetics('__iand__', *args) def __ixor__(self, *args): return self._optimized_arithmetics('__ixor__', *args) def __ior__(self, *args): return self._optimized_arithmetics('__ior__', *args) def __neg__(self): return self._optimized_arithmetics('__neg__') def __pos__(self): return self._optimized_arithmetics('__pos__') def __abs__(self): return self._optimized_arithmetics('__abs__') def __invert__(self): return self._optimized_arithmetics('__invert__') def __complex__(self): return self._optimized_arithmetics('__complex__') def __int__(self): return self._optimized_arithmetics('__int__') def __long__(self): return self._optimized_arithmetics('__long__') def __float__(self): return self._optimized_arithmetics('__float__') def __oct__(self): return self._optimized_arithmetics('__oct__') def __hex__(self): return self._optimized_arithmetics('__hex__') def __index__(self): return self.masked_array.__index__(self) # Optimized methods (only sum implemented for now) # We can optimize some methods when they operate on the entire # flattened array. Otherwise we delegate to the masked array def sum(self, *args, **kwargs): return self._optimized_arithmetic_methods('sum', *args, **kwargs) From pav at iki.fi Fri Oct 1 08:56:58 2010 From: pav at iki.fi (Pauli Virtanen) Date: Fri, 1 Oct 2010 12:56:58 +0000 (UTC) Subject: [Numpy-discussion] numpydoc: "Other Parameters" section References: <4CA4E140.5090400@stsci.edu> Message-ID: Thu, 30 Sep 2010 15:13:04 -0400, Michael Droettboom wrote: > Is the solution as simple as the attached diff? It works for me, but I > don't understand all the implications. More or less so, applied. Pauli From seb.haase at gmail.com Fri Oct 1 10:06:16 2010 From: seb.haase at gmail.com (Sebastian Haase) Date: Fri, 1 Oct 2010 16:06:16 +0200 Subject: [Numpy-discussion] ndarray: subclassing a subclass looses custom attribute In-Reply-To: References: <6C2209EC-2770-4592-9353-6ED4F8ED7F98@gmail.com> Message-ID: On Fri, Oct 1, 2010 at 2:20 PM, Pierre GM wrote: > > On Oct 1, 2010, at 1:03 PM, Sebastian Haase wrote: > >>>> However, I had done this before for some specific image-file-types: >>>> those would add there own attribute to ndarray array (e.g. arr.Mrc) >>>> Now if I call the new ?ndarray_meta on my ndarray_with_mrc I loose the >>>> `Mrc` attribute, leaving only the new `meta` attribute. >>>> My code is essentially a verbatim copy of >>>> http://docs.scipy.org/doc/numpy/user/basics.subclassing.html#simple-example-adding-an-extra-attribute-to-ndarray >>>> >>>> What can I do ? >> >> class ndarray_inMrcFile(ndarray): >> ? ?def __new__(cls, input_array, mrcInfo=None): >> ? ? ? ?obj = asanyarray(input_array).view(cls) >> ? ? ? ?obj.Mrc = mrcInfo >> ? ? ? ?return obj >> >> ? ?def __array_finalize__(self, obj): >> ? ? ? ?if obj is None: return >> ? ? ? ?self.Mrc = getattr(obj, 'Mrc', None) >> >> class ndarray_meta(ndarray): >> ? ?def __new__(cls, input_array, meta=None): >> ? ? ? ?obj = asanyarray(input_array).view(cls) >> ? ? ? ?obj.meta = nd_meta_attribute( meta ) >> ? ? ? ?return obj >> >> ? ?def __array_finalize__(self, obj): >> ? ? ? ?if obj is None: return >> ? ? ? ?self.meta = getattr(obj, 'meta', nd_meta_attribute()) > > Ah, OK, now I understand the problem. > When you create a ndarray_meta from an object, it is transform into a ndarray_meta at the `asanyarray(...).view(cls)` line, which calls ndarray_meta.__array_finalize__. In that method, you don't keep track of what `obj` is, you just check whether it has a 'meta' attribute: all the other attributes it could have are stripped. If you want to keep them, you have to define them explicitly in your array_finalize... That can be a bit tricky if you want to avoid having your objects subclasses one of the other. > > However, these extra attributes should be defined in the __dict__ of your class, right? So, if you update the __dict__ of self with the __dict__ of obj, that should do the trick: > > class ndarray_inMrcFile(ndarray): > ? def __new__(cls, input_array, mrcInfo=None): > ? ? ? obj = asanyarray(input_array).view(cls) > ? ? ? obj.Mrc = mrcInfo > ? ? ? return obj > > ? def __array_finalize__(self, obj): > ? ? ? if obj is None: return > ? ? ? self.Mrc = getattr(obj, 'Mrc', None) > ? ? ? self.__dict__.update(getattr(obj, "__dict__", {})) > > class ndarray_meta(ndarray): > ? def __new__(cls, input_array, meta=None): > ? ? ? obj = asanyarray(input_array).view(cls) > ? ? ? obj.meta = nd_meta_attribute( meta ) > ? ? ? return obj > > ? def __array_finalize__(self, obj): > ? ? ? if obj is None: return > ? ? ? self.meta = getattr(obj, 'meta', nd_meta_attribute(None)) > ? ? ? self.__dict__.update(getattr(obj, "__dict__", {})) > > That works, but modifying the __dict__ that way can have some nasty side effects (well, I wouldn't be surprised if it had some, more experienced users will comment on that). > > A cleaner, albeit slightly more cumbersome and less directly extendable approach, would be to define a generic ndarray subclass, where you define a `_addattr` attribute as a dictionary. Store the attributes specific to your subclasses in that dictionary, and update it in the __array_finalize__: basically, your `_addattr` plays the role of __dict__, but you're not messing w/ __dict__ itself. > You can access your attributes through this `_addattr` dictionary. As you'll probably need direct attribute access, you can define specific methods, or define the attribute as property: > @property > ndarray_inMrc.MRC(self) > ? ? ? ?return self._addattr['MRC'] > or with a combo _get_MRC/_set_MRC/MRC=property(_get_MRC,_set_MRC)... You get the idea. > > Let me know how it goes. If it works, please consider writing something to add to the doc or the wiki, so that we can keep track of it. > > Cheers > P. > Pierre, this is great - thanks a lot !!! It seems the simple __dict__ approach works for me (for now at least): >>> a = Y.load( "myFile.mrc' ) >>> a.__dict__ {'meta': fileformat: 'mrc' filename: u'...........mrc'} >>> len(a.__dict__) 1 >>> q = N.arange(4) >>> len(q.__dict__) Traceback (most recent call last): File "", line 1, in AttributeError: 'numpy.ndarray' object has no attribute '__dict__' Maybe somebody else can comment on the use of __dict__ in ndarray. It looks like it's not used at all by the standard ndarray (how about sparse arrays, or alike...?) Thanks again, Sebastian From robert.kern at gmail.com Fri Oct 1 10:44:01 2010 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 1 Oct 2010 09:44:01 -0500 Subject: [Numpy-discussion] constant shaded triangle mesh in mayavi2 In-Reply-To: References: Message-ID: On Thu, Sep 30, 2010 at 23:04, Geoffrey Irving wrote: > On Fri, Oct 1, 2010 at 11:39 AM, Robert Kern wrote: >> ?s = mlab.pipeline.triangular_mesh_source(x,y,z,triangles) >> ?s.data.cell_data.scalars = .... # Your data here. >> ?surf = mlab.pipeline.surface(s) >> ?surf.contours.filled_contours = True > > Cool, that seems to work for static plots (with "contours" replaced > with "contour"). ?However, it breaks dynamic updates if I change data > interactively on trait changes. ?For vertex data, I'm using the > following code for interactive updates: > > ? ?@on_trait_change('threshold') > ? ?def update_plot(self): > ? ? ? ?self.plot.mlab_source.set(scalars=self.scalars()) > > borrowed from > > ? ?http://code.enthought.com/projects/mayavi/docs/development/html/mayavi/auto/example_mlab_interactive_dialog.html#example-mlab-interactive-dialog > > where plot is generated with triangular_mesh(). ?How do I force an > update of the surface if I generate it myself and use cell data? surf.render() -- 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 From faltet at pytables.org Fri Oct 1 13:22:49 2010 From: faltet at pytables.org (Francesc Alted) Date: Fri, 1 Oct 2010 19:22:49 +0200 Subject: [Numpy-discussion] [ANN] python-blosc 1.0.1, a wrapper for the Blosc compression library Message-ID: <201010011922.49386.faltet@pytables.org> ==================================================== Announcing python-blosc 1.0.1 A Python wrapper for the Blosc compression library ==================================================== What is it? =========== Blosc (http://blosc.pytables.org) is a high performance compressor optimized for binary data. It has been designed to transmit data to the processor cache faster than the traditional, non-compressed, direct memory fetch approach via a memcpy() OS call. Blosc works well for compressing numerical arrays that contains data with relatively low entropy, like sparse data, time series, grids with regular-spaced values, etc. python-blosc is a Python package that wraps it. What is new? ============ Everything. This is the first public version of the Python wrapper for Blosc (1.1.1). It supports Python 2.6, 2.7 and 3.1. The API is very simple and it loosely follows that of the zlib module. There are two basic functions, `compress()` and `decompress()`, as well as two additional calls specific for compressing NumPy arrays, namely `pack_array()` and `unpack_array`. There are also utilities for changing dynamically the number of threads used or to release resources when you are not going to need blosc for a while. Basic Usage =========== >>> import numpy as np >>> a = np.linspace(0, 100, 1e7) >>> bytes_array = a.tostring() >>> import blosc >>> bpacked = blosc.compress(bytes_array, typesize=8) >>> bytes_array2 = blosc.decompress(bpacked) >>> print(bytes_array == bytes_array2) True More examples are available on python-blosc wiki page: http://github.com/FrancescAlted/python-blosc/wiki Documentation ============= Please refer to docstrings. Start by the main package: >>> import blosc >>> help(blosc) and ask for more docstrings in the referenced functions. Download sources ================ Go to: http://github.com/FrancescAlted/python-blosc and download the most recent release from here. Blosc is distributed using the MIT license, see LICENSES/BLOSC.txt for details. Mailing list ============ There is an official mailing list for Blosc at: blosc at googlegroups.com http://groups.google.es/group/blosc ---- **Enjoy data!** -- Francesc Alted From fperez.net at gmail.com Fri Oct 1 15:10:33 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 1 Oct 2010 12:10:33 -0700 Subject: [Numpy-discussion] datarray repositories have diverged In-Reply-To: References: <87sk0r6w1s.fsf@ginnungagap.bsc.es> Message-ID: On Thu, Sep 30, 2010 at 9:41 AM, Rob Speer wrote: > > The way you'd usually get something merged in this kind of project is > to send a pull request to the leader using the "Pull Request" button. > But in this case, I'm basically making my pull request on the mailing > list, because it's not straightforward enough for a simple pull > request. I just wanted to reply temporarily to say that I'm *not* ignoring this discussion, despite appearances to the contrary :) In the next week we hope to put some time into this at work, and I'll try to catch up with the discussion tomorrow. One thing to note is that the new pull request system on GH is leaps and bounds better than the old. Now they get automatically an issue, a discussion page, a stable url, etc. So if anyone has anything on datarray that they feel is ready to pull, it would be great if you could click again on the pull request button (GH did not auto-migrate old pull requests to the new system, they need to be made again manually). And we'll do our best to hold our end of the bargain of collaborative development over the next few days :) Regards, f From josh.holbrook at gmail.com Fri Oct 1 15:22:01 2010 From: josh.holbrook at gmail.com (Joshua Holbrook) Date: Fri, 1 Oct 2010 11:22:01 -0800 Subject: [Numpy-discussion] datarray repositories have diverged In-Reply-To: References: <87sk0r6w1s.fsf@ginnungagap.bsc.es> Message-ID: One thing I'd like to throw out there is that I haven't really done anything with my branch past maybe adding a gh-pages branch, and probably won't be for a while, if at all. As it turns out, I have a hard time concentrating on the intricacies of apis. >_< --Josh (jesusabdullah :E ) On Fri, Oct 1, 2010 at 11:10 AM, Fernando Perez wrote: > On Thu, Sep 30, 2010 at 9:41 AM, Rob Speer wrote: >> >> The way you'd usually get something merged in this kind of project is >> to send a pull request to the leader using the "Pull Request" button. >> But in this case, I'm basically making my pull request on the mailing >> list, because it's not straightforward enough for a simple pull >> request. > > I just wanted to reply temporarily to say that I'm *not* ignoring this > discussion, despite appearances to the contrary :) ?In the next week > we hope to put some time into this at work, and I'll try to catch up > with the discussion tomorrow. > > One thing to note is that the new pull request system on GH is leaps > and bounds better than the old. ?Now they get automatically an issue, > a discussion page, a stable url, etc. ?So if anyone has anything on > datarray that they feel is ready to pull, it would be great if you > could click again on the pull request button (GH did not auto-migrate > old pull requests to the new system, they need to be made again > manually). > > And we'll do our best to hold our end of the bargain of collaborative > development over the next few days :) > > Regards, > > f > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > From gokhansever at gmail.com Fri Oct 1 15:58:18 2010 From: gokhansever at gmail.com (=?UTF-8?Q?G=C3=B6khan_Sever?=) Date: Fri, 1 Oct 2010 14:58:18 -0500 Subject: [Numpy-discussion] Return values stats.mstats.linregress Message-ID: Hello, mstats.linregress returns 6 values. I don't see this documented from the function docstring. I know 0.91... is r. What is masked_array return here? I[29]: stats.mstats.linregress(np.ma.hstack(all_measured[0::6]), np.ma.hstack(all_predicted[0::6])) O[29]: (2.6309756058562122, -358.84572340482669, 0.91388013590912054, masked_array(data = 8.93881546632e-73, mask = False, fill_value = 1e+20) , 241.88030264140224, 8.2881035327089627) When I run with mstats: I[30]: stats.linregress(np.ma.hstack(all_measured[0::6]), np.ma.hstack(all_predicted[0::6])) O[30]: (2.5731434548927012, -325.98658013998079, 0.90619871728013224, 1.4284868970559915e-69, 0.089246202128717186) Any idea also why the returned p-value is so large from the mstats version. Shouldn't p-values lie in between [0,1) ? Thanks. -- G?khan From rspeer at MIT.EDU Fri Oct 1 17:45:20 2010 From: rspeer at MIT.EDU (Rob Speer) Date: Fri, 1 Oct 2010 17:45:20 -0400 Subject: [Numpy-discussion] datarray repositories have diverged In-Reply-To: References: <87sk0r6w1s.fsf@ginnungagap.bsc.es> Message-ID: Oh, I'm apparently confusing people's github usernames. Sorry about that. Josh's branch (jesusabdullah/datarray) is indeed the one I branched from, not Lluis's (xscript/datarray), though I merged in changes from Lluis at one point. Does anyone know if it's possible to change the "forked from" location of my branch to be Fernando's branch? -- Rob On Fri, Oct 1, 2010 at 3:22 PM, Joshua Holbrook wrote: > One thing I'd like to throw out there is that I haven't really done > anything with my branch past maybe adding a gh-pages branch, and > probably won't be for a while, if at all. As it turns out, I have a > hard time concentrating on the intricacies of apis. >_< > > --Josh (jesusabdullah :E ) > > > On Fri, Oct 1, 2010 at 11:10 AM, Fernando Perez wrote: >> On Thu, Sep 30, 2010 at 9:41 AM, Rob Speer wrote: >>> >>> The way you'd usually get something merged in this kind of project is >>> to send a pull request to the leader using the "Pull Request" button. >>> But in this case, I'm basically making my pull request on the mailing >>> list, because it's not straightforward enough for a simple pull >>> request. >> >> I just wanted to reply temporarily to say that I'm *not* ignoring this >> discussion, despite appearances to the contrary :) ?In the next week >> we hope to put some time into this at work, and I'll try to catch up >> with the discussion tomorrow. >> >> One thing to note is that the new pull request system on GH is leaps >> and bounds better than the old. ?Now they get automatically an issue, >> a discussion page, a stable url, etc. ?So if anyone has anything on >> datarray that they feel is ready to pull, it would be great if you >> could click again on the pull request button (GH did not auto-migrate >> old pull requests to the new system, they need to be made again >> manually). >> >> And we'll do our best to hold our end of the bargain of collaborative >> development over the next few days :) >> >> Regards, >> >> f >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > From robert.kern at gmail.com Fri Oct 1 19:22:14 2010 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 1 Oct 2010 18:22:14 -0500 Subject: [Numpy-discussion] NPZ format In-Reply-To: <201010010913.40253.faltet@pytables.org> References: <201009291017.46955.faltet@pytables.org> <201010010913.40253.faltet@pytables.org> Message-ID: On Fri, Oct 1, 2010 at 02:13, Francesc Alted wrote: > A Thursday 30 September 2010 18:20:16 Robert Kern escrigu?: >> On Wed, Sep 29, 2010 at 03:17, Francesc Alted > wrote: >> > Hi, >> > >> > I'm going to give a seminar about serialization, and I'd like to >> > describe the .npy format. ?I noticed that there is a variant of it >> > called .npz that can pack several arrays in one single file. >> > >> > However, .npz does not use compression at all and I'm wondering >> > what's the reason. ?I suppose that this is because you don't want >> > to loose the possibility to memmap saved arrays, but can someone >> > confirm this? >> >> While I suspect it's possible, I'm certain we don't have any code >> that actually does it. Most likely the author assumed that it would >> be faster (or tested it to be faster with their CPU/hard disk >> configuration) to not compress. > > Thanks, that's good to know. ?And yes, I'd say that compressing with zip > (zlib) would reduce performance for doing I/O, but most probably > decompressing from disk media would represent an improvement in terms of > time. ?At any rate, adding compression capability to .npy should be just > one parameter away, so perhaps is a good idea adding it. Also some design, documentation, format version bump, and (not least) code away. ;-) -- 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 From workalof at gmail.com Sat Oct 2 00:51:08 2010 From: workalof at gmail.com (John Mitchell) Date: Fri, 1 Oct 2010 22:51:08 -0600 Subject: [Numpy-discussion] test failure Message-ID: After spending a lot of time building 'numpy' (1.5.0) and 'scipy' (0.8.0) I ran the following tests -- per what I read somewhere: numpy.test() Out of several thousand small tests I found this one error -- perhaps its not really an error? This doesn't look serious but it can be bothersome when one is trying to be sure that the installation is as good as possible. Not sure if it matters, but my compiler is gcc-4.4.1 and I'm using gfortran. Both were wrapped with mpich2. Regards, John FAIL: test_doctests (test_polynomial.TestDocs) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/python2.6.6/lib/python2.6/site-packages/numpy/lib/tests/test_polynomial.py", line 90, in test_doctests return rundocs() File "/usr/local/python2.6.6/lib/python2.6/site-packages/numpy/testing/utils.py", line 962, in rundocs raise AssertionError("Some doctests failed:\n%s" % "\n".join(msg)) AssertionError: Some doctests failed: ********************************************************************** File "/usr/local/python2.6.6/lib/python2.6/site-packages/numpy/lib/tests/test_polynomial.py", line 38, in test_polynomial Failed example: p / q Expected: (poly1d([ 0.33333333]), poly1d([ 1.33333333, 2.66666667])) Got: (poly1d([ 0.333]), poly1d([ 1.333, 2.667])) ********************************************************************** File "/usr/local/python2.6.6/lib/python2.6/site-packages/numpy/lib/tests/test_polynomial.py", line 60, in test_polynomial Failed example: p.integ() Expected: poly1d([ 0.33333333, 1. , 3. , 0. ]) Got: poly1d([ 0.333, 1. , 3. , 0. ]) ********************************************************************** File "/usr/local/python2.6.6/lib/python2.6/site-packages/numpy/lib/tests/test_polynomial.py", line 62, in test_polynomial Failed example: p.integ(1) Expected: poly1d([ 0.33333333, 1. , 3. , 0. ]) Got: poly1d([ 0.333, 1. , 3. , 0. ]) ********************************************************************** File "/usr/local/python2.6.6/lib/python2.6/site-packages/numpy/lib/tests/test_polynomial.py", line 64, in test_polynomial Failed example: p.integ(5) Expected: poly1d([ 0.00039683, 0.00277778, 0.025 , 0. , 0. , 0. , 0. , 0. ]) Got: poly1d([ 0. , 0.003, 0.025, 0. , 0. , 0. , 0. , 0. ]) >> raise AssertionError("Some doctests failed:\n%s" % "\n".join(['**********************************************************************\nFile "/usr/local/python2.6.6/lib/python2.6/site-packages/numpy/lib/tests/test_polynomial.py", line 38, in test_polynomial\nFailed example:\n p / q\nExpected:\n (poly1d([ 0.33333333]), poly1d([ 1.33333333, 2.66666667]))\nGot:\n (poly1d([ 0.333]), poly1d([ 1.333, 2.667]))\n', '**********************************************************************\nFile "/usr/local/python2.6.6/lib/python2.6/site-packages/numpy/lib/tests/test_polynomial.py", line 60, in test_polynomial\nFailed example:\n p.integ()\nExpected:\n poly1d([ 0.33333333, 1. , 3. , 0. ])\nGot:\n poly1d([ 0.333, 1. , 3. , 0. ])\n', '**********************************************************************\nFile "/usr/local/python2.6.6/lib/python2.6/site-packages/numpy/lib/tests/test_polynomial.py", line 62, in test_polynomial\nFailed example:\n p.integ(1)\nExpected:\n poly1d([ 0.33333333, 1. , 3. , 0. ])\nGot:\n poly1d([ 0.333, 1. , 3. , 0. ])\n', '**********************************************************************\nFile "/usr/local/python2.6.6/lib/python2.6/site-packages/numpy/lib/tests/test_polynomial.py", line 64, in test_polynomial\nFailed example:\n p.integ(5)\nExpected:\n poly1d([ 0.00039683, 0.00277778, 0.025 , 0. , 0. ,\n 0. , 0. , 0. ])\nGot:\n poly1d([ 0. , 0.003, 0.025, 0. , 0. , 0. , 0. , 0. ])\n'])) ---------------------------------------------------------------------- Ran 2966 tests in 9.896s FAILED (KNOWNFAIL=4, failures=1) -------------- next part -------------- An HTML attachment was scrubbed... URL: From faltet at pytables.org Sat Oct 2 04:45:45 2010 From: faltet at pytables.org (Francesc Alted) Date: Sat, 2 Oct 2010 10:45:45 +0200 Subject: [Numpy-discussion] NPZ format In-Reply-To: References: <201009291017.46955.faltet@pytables.org> <201010010913.40253.faltet@pytables.org> Message-ID: 2010/10/2 Robert Kern > On Fri, Oct 1, 2010 at 02:13, Francesc Alted wrote: > > A Thursday 30 September 2010 18:20:16 Robert Kern escrigu?: > >> On Wed, Sep 29, 2010 at 03:17, Francesc Alted > > wrote: > >> > Hi, > >> > > >> > I'm going to give a seminar about serialization, and I'd like to > >> > describe the .npy format. I noticed that there is a variant of it > >> > called .npz that can pack several arrays in one single file. > >> > > >> > However, .npz does not use compression at all and I'm wondering > >> > what's the reason. I suppose that this is because you don't want > >> > to loose the possibility to memmap saved arrays, but can someone > >> > confirm this? > >> > >> While I suspect it's possible, I'm certain we don't have any code > >> that actually does it. Most likely the author assumed that it would > >> be faster (or tested it to be faster with their CPU/hard disk > >> configuration) to not compress. > > > > Thanks, that's good to know. And yes, I'd say that compressing with zip > > (zlib) would reduce performance for doing I/O, but most probably > > decompressing from disk media would represent an improvement in terms of > > time. At any rate, adding compression capability to .npy should be just > > one parameter away, so perhaps is a good idea adding it. > > Also some design, documentation, format version bump, and (not least) > code away. ;-) > Oh, indeed :-) -- Francesc Alted -------------- next part -------------- An HTML attachment was scrubbed... URL: From keekychen.shared at gmail.com Sat Oct 2 11:23:57 2010 From: keekychen.shared at gmail.com (kee chen) Date: Sat, 2 Oct 2010 23:23:57 +0800 Subject: [Numpy-discussion] can I mapping a np.darray class with a text file instead of reading the file in to mem? Message-ID: Dear All, I have memory problem in reading data from text file to a np.darray. It is because I have low mem on my pc and the data is too big. Te data is stored as 3 cols text and may have 10000000 records look like this 0.64984279 0.587856227 0.827348652 0.33463377 0.210916859 0.608797746 0.230265156 0.390278562 0.186308355 0.431187207 0.127007937 0.949673389 ... 10000000 LINES OMITTED HERE ... 0.150027782 0.800999655 0.551508963 0.255163742 0.785462049 0.015694154 After googled, I found 3 ways may solve this problem: 1.hardware upgrade(upgrade memory, upgrade arch to x64 ..... ) 2. filter the data before processing 3. using pytable However , I am trying to think another possibility - the mem-time trade-off. Can I design a class inherit from the np.darray then make it mapping with the text file? It may works in such a way, inside of this class only maintain a row object and total row ID a.k.a the rows of the file. the row mapping may look like this: an row object <--- bind---> row ID in text file <--- bind---> function row_eader() Wen np function be applied on this object, the actual date is from function row_eader(actual row ID). I have no idea how to code it then may I get support here to design such a class? Thanks! Rgs, KC -------------- next part -------------- An HTML attachment was scrubbed... URL: From xscript at gmx.net Sat Oct 2 16:12:52 2010 From: xscript at gmx.net (=?utf-8?Q?Llu=C3=ADs?=) Date: Sat, 02 Oct 2010 22:12:52 +0200 Subject: [Numpy-discussion] datarray repositories have diverged In-Reply-To: (Fernando Perez's message of "Fri, 1 Oct 2010 12:10:33 -0700") References: <87sk0r6w1s.fsf@ginnungagap.bsc.es> Message-ID: <87pqvsqrp7.fsf@ginnungagap.bsc.es> Fernando Perez writes: > One thing to note is that the new pull request system on GH is leaps > and bounds better than the old. Now they get automatically an issue, Which has been bugging me, as pull requests where from branches "associated" to already-existing issues... after looking I couldn't find a way in GH to make a pull request associated to an existing issue (creating an automated comment and somehow annotating the issue would be the ideal), instead of creating a new one :) apa! -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth From wardefar at iro.umontreal.ca Sat Oct 2 23:10:28 2010 From: wardefar at iro.umontreal.ca (David Warde-Farley) Date: Sat, 2 Oct 2010 23:10:28 -0400 Subject: [Numpy-discussion] NPZ format In-Reply-To: References: <201009291017.46955.faltet@pytables.org> <201010010913.40253.faltet@pytables.org> Message-ID: On 2010-10-01, at 7:22 PM, Robert Kern wrote: > Also some design, documentation, format version bump, and (not least) > code away. ;-) Would it require a format version number bump? I thought that was a .NPY thing, and NPZs were just zipfiles containing several separate NPY containers. David From robert.kern at gmail.com Sun Oct 3 00:31:54 2010 From: robert.kern at gmail.com (Robert Kern) Date: Sat, 2 Oct 2010 23:31:54 -0500 Subject: [Numpy-discussion] NPZ format In-Reply-To: References: <201009291017.46955.faltet@pytables.org> <201010010913.40253.faltet@pytables.org> Message-ID: On Sat, Oct 2, 2010 at 22:10, David Warde-Farley wrote: > On 2010-10-01, at 7:22 PM, Robert Kern wrote: > >> Also some design, documentation, format version bump, and (not least) >> code away. ;-) > > Would it require a format version number bump? I thought that was a .NPY thing, and NPZs were just zipfiles containing several separate NPY containers. Perhaps that's what Francesc was intending to say, but he wrote "At any rate, adding compression capability to .npy should be just one parameter away, so perhaps is a good idea adding it." So that's what I was responding to. Yes, adding regular ZIP compression to .npz files should be just one parameter away without much thought. -- 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 From gordon at tolomea.com Sun Oct 3 08:41:12 2010 From: gordon at tolomea.com (Gordon Wrigley) Date: Sun, 3 Oct 2010 23:41:12 +1100 Subject: [Numpy-discussion] what is the best way to do a statistical mode operation? Message-ID: I have an array of uint8's that has a shape of X*Y*Z*8, I would like to calculate modes along the 8 axis so that I end up with an array that has the shape X*Y*Z and is full of modes. I'm having problems finding a good way of doing this. My attempts at solving this using bincount or histogram produce an intermediate array that is 32x the size of my input data and somewhat larger than I have the memory to deal with. Can anyone suggest a good way to produce modes over sets of 8 bytes? Also in the instance where there are multiple modes for a particular set I'm happy for it to pick any one arbitrarily. G -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Sun Oct 3 08:55:38 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Sun, 3 Oct 2010 08:55:38 -0400 Subject: [Numpy-discussion] what is the best way to do a statistical mode operation? In-Reply-To: References: Message-ID: On Sun, Oct 3, 2010 at 8:41 AM, Gordon Wrigley wrote: > I have an array of uint8's that has a shape of X*Y*Z*8, I would like to > calculate modes along the 8 axis so that I end up with an array that has the > shape X*Y*Z and is full of modes. > I'm having problems finding a good way of doing this. My attempts at solving > this using bincount or histogram produce an intermediate array that is 32x > the size of my input data and somewhat larger than I have the memory to deal > with. > Can anyone suggest a good way to produce modes over sets of 8 bytes? > Also in the instance where there are multiple modes for a particular set I'm > happy for it to pick any one arbitrarily. What's the range of integers? How many point do you have in np.unique(array) ? bincount, for example, uses range(arr.max()+1) as set of points. looping over 8 values would be fast, but the intermediate arrays would depend on the number of unique values. I would try to use a dictionary. Josef > G > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > From warren.weckesser at enthought.com Sun Oct 3 13:24:57 2010 From: warren.weckesser at enthought.com (Warren Weckesser) Date: Sun, 3 Oct 2010 12:24:57 -0500 Subject: [Numpy-discussion] what is the best way to do a statistical mode operation? In-Reply-To: References: Message-ID: On Sun, Oct 3, 2010 at 7:41 AM, Gordon Wrigley wrote: > I have an array of uint8's that has a shape of X*Y*Z*8, I would like to > calculate modes along the 8 axis so that I end up with an array that has the > shape X*Y*Z and is full of modes. > I'm having problems finding a good way of doing this. My attempts at > solving this using bincount or histogram produce an intermediate array that > is 32x the size of my input data and somewhat larger than I have the memory > to deal with. > If you were using bincount or histogram, you must have been explicitly looping over the other three dimensions. In that case, why should there be such a large intermediate array? > Can anyone suggest a good way to produce modes over sets of 8 bytes? > > For what it's worth, here's a mode calculation that uses bincount on the ranks of the data rather than the data itself. Since it uses bincount, I don't think it can be vectorized efficiently, so you are still stuck explicitly looping over the other three dimensions. ----- import numpy as np def mode(x): y = np.sort(x) starts = np.concatenate(([1], np.diff(y).astype(bool).astype(int))) starts_sum = starts.cumsum() counts = np.bincount(starts_sum) arg_mode_freq = counts.argmax() counts_sum = counts.cumsum() mode = y[counts_sum[arg_mode_freq-1]] return mode ----- Warren -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Sun Oct 3 15:29:55 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 3 Oct 2010 12:29:55 -0700 Subject: [Numpy-discussion] datarray repositories have diverged In-Reply-To: References: <87sk0r6w1s.fsf@ginnungagap.bsc.es> Message-ID: On Fri, Oct 1, 2010 at 2:45 PM, Rob Speer wrote: > > Does anyone know if it's possible to change the "forked from" location > of my branch to be Fernando's branch? The easiest way (I think) is: - ensure your *local* repo is 100% complete and in good shape. - delete your github repo. - re-fork on github from fperez. - push -f your local repo back to github Cheers, f From gordon at tolomea.com Sun Oct 3 17:56:06 2010 From: gordon at tolomea.com (Gordon Wrigley) Date: Mon, 4 Oct 2010 08:56:06 +1100 Subject: [Numpy-discussion] what is the best way to do a statistical mode operation? In-Reply-To: References: Message-ID: > How many point do you have in np.unique(array) ? 43 currently On Sun, Oct 3, 2010 at 11:55 PM, wrote: > On Sun, Oct 3, 2010 at 8:41 AM, Gordon Wrigley wrote: > > I have an array of uint8's that has a shape of X*Y*Z*8, I would like to > > calculate modes along the 8 axis so that I end up with an array that has > the > > shape X*Y*Z and is full of modes. > > I'm having problems finding a good way of doing this. My attempts at > solving > > this using bincount or histogram produce an intermediate array that is > 32x > > the size of my input data and somewhat larger than I have the memory to > deal > > with. > > Can anyone suggest a good way to produce modes over sets of 8 bytes? > > Also in the instance where there are multiple modes for a particular set > I'm > > happy for it to pick any one arbitrarily. > > What's the range of integers? How many point do you have in > np.unique(array) ? > > bincount, for example, uses range(arr.max()+1) as set of points. > > looping over 8 values would be fast, but the intermediate arrays would > depend on the number of unique values. > I would try to use a dictionary. > > Josef > > > > G > > > > > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion at scipy.org > > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Sun Oct 3 18:30:11 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Sun, 3 Oct 2010 18:30:11 -0400 Subject: [Numpy-discussion] what is the best way to do a statistical mode operation? In-Reply-To: References: Message-ID: On Sun, Oct 3, 2010 at 5:56 PM, Gordon Wrigley wrote: >>?How many point do you have in np.unique(array) ? > 43 currently > > On Sun, Oct 3, 2010 at 11:55 PM, wrote: >> >> On Sun, Oct 3, 2010 at 8:41 AM, Gordon Wrigley wrote: >> > I have an array of uint8's that has a shape of X*Y*Z*8, I would like to >> > calculate modes along the 8 axis so that I end up with an array that has >> > the >> > shape X*Y*Z and is full of modes. >> > I'm having problems finding a good way of doing this. My attempts at >> > solving >> > this using bincount or histogram produce an intermediate array that is >> > 32x >> > the size of my input data and somewhat larger than I have the memory to >> > deal >> > with. >> > Can anyone suggest a good way to produce modes over sets of 8 bytes? >> > Also in the instance where there are multiple modes for a particular set >> > I'm >> > happy for it to pick any one arbitrarily. >> >> What's the range of integers? How many point do you have in >> np.unique(array) ? >> >> bincount, for example, uses range(arr.max()+1) as set of points. >> >> looping over 8 values would be fast, but the intermediate arrays would >> depend on the number of unique values. >> I would try to use a dictionary. My try, but no time for real testing >>> import numpy as np >>> a = np.random.randint(10,size=(5,4,8)) >>> auni = np.unique(a) >>> mode = np.zeros(a.shape[:-1],int) >>> idx = -1 >>> for k in np.unique(a): idx += 1 count = (a==k).sum(-1) mode[count>mode] = idx >>> auni[mode] array([[2, 2, 6, 8], [4, 2, 4, 2], [2, 2, 2, 4], [7, 4, 4, 2], [4, 1, 3, 2]]) Josef >> >> Josef >> >> >> > G >> > >> > >> > _______________________________________________ >> > NumPy-Discussion mailing list >> > NumPy-Discussion at scipy.org >> > http://mail.scipy.org/mailman/listinfo/numpy-discussion >> > >> > >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > From ioan.ferencik at tkk.fi Mon Oct 4 01:41:20 2010 From: ioan.ferencik at tkk.fi (Ioan Ferencik) Date: Mon, 4 Oct 2010 08:41:20 +0300 Subject: [Numpy-discussion] ndarray of object dtype Message-ID: <20101004084120.7bmxuk1dcsc0coko@webmail3.tkk.fi> Hello list, I am trying to pass elements of a custom defined with C API. I have successfully wrapped a type around a C struct. I intent to create a list with these objects and process it using numpy C API. So i create an array: array = (PyArrayObject *)PyArray_ContiguousFromObject(input, PyArray_OBJECT, 0, 0); to my understanding each el. in this array is a pointer to my type so a cast to this type should work. this is my custom type typedef struct val{ PyObject_HEAD float q; float wl; int cssid; int br; }hm1dval; I am passing only one element for testing purposes. in python a = [hm1d1.hm1dval() for i in range(0,1)] for c in a: c.set_values(q=3.0, wl=2.5, cssid=6, br=7) So following code should be valid in C: hm1dval s* = PyArray_DATA(array); but the members are 0 after casting in spite they were set previously. also using strides it should be possible to traverse the array and get the individual objects. Regards. Ioan Ferencik PhD student Aalto University School of Science and Technology Faculty Of Civil and Env. Engineering Lahti Center Tel: +358505122707 From seb.haase at gmail.com Mon Oct 4 03:59:05 2010 From: seb.haase at gmail.com (Sebastian Haase) Date: Mon, 4 Oct 2010 09:59:05 +0200 Subject: [Numpy-discussion] can I mapping a np.darray class with a text file instead of reading the file in to mem? In-Reply-To: References: Message-ID: Hi, if you have 3 cols of 10 000 000 lines, that should add up 30 Mega-numbers. That is 240 MB for double, and 120 MB for single precision. That should not require a 64bit OS. You probably have a problem because reading from text is using extra memory. Can you not convert the file "line-by-line" into a second, binary, file ? Otherwise, you might want to look into the "appendable" ndarray the Chris Barker wrote about on this list not too long ago. And you might want to read this post: http://old.nabble.com/Memory-usage-of-numpy-arrays-td29107053.html Cheers, - Sebastian Haase On Sat, Oct 2, 2010 at 5:23 PM, kee chen wrote: > Dear All, > > I have memory problem in reading?data from?text file to a np.darray. It is > because I have low mem on my pc and the data is too big. > Te data is stored as 3 cols?text?and may have 10000000 records look like > this > > 0.64984279?0.587856227?0.827348652 > 0.33463377?0.210916859?0.608797746 > 0.230265156?0.390278562?0.186308355 > 0.431187207?0.127007937?0.949673389 > ... > > 10000000 LINES OMITTED HERE > ... > 0.150027782?0.800999655?0.551508963 > 0.255163742?0.785462049?0.015694154 > > > After googled, I found?3 ways may solve this problem: > ??? 1.hardware upgrade(upgrade memory, upgrade arch to x64 ..... ) > ??? 2. filter the data before processing > ??? 3. using pytable > > However ,?I am trying to think another possibility - the mem-time trade-off. > > Can I design a class inherit from?the np.darray then make it mapping with > the text file? > It may works in such a way, inside of this class only maintain a row object > and? total row ID a.k.a the?rows of the file.?the row mapping may look like > this: > > an?row?object?? <--- bind--->???row ID?in text file??<--- bind--->?function > row_eader() > > Wen np function be applied on this object, the actual date is from?function > row_eader(actual row ID). > > I have no idea how to code it then may I get support here to design such a > class? Thanks! > > > Rgs, > > KC > > > > > > > > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > From robert.kern at gmail.com Mon Oct 4 10:55:29 2010 From: robert.kern at gmail.com (Robert Kern) Date: Mon, 4 Oct 2010 09:55:29 -0500 Subject: [Numpy-discussion] ndarray of object dtype In-Reply-To: <20101004084120.7bmxuk1dcsc0coko@webmail3.tkk.fi> References: <20101004084120.7bmxuk1dcsc0coko@webmail3.tkk.fi> Message-ID: On Mon, Oct 4, 2010 at 00:41, Ioan Ferencik wrote: > Hello list, > > I am trying to pass elements of a custom defined with C API. > I have successfully wrapped a type around a C struct. > I intent to create a list with these objects and process it using numpy C API. > So i ?create an array: > > array = (PyArrayObject *)PyArray_ContiguousFromObject(input, > PyArray_OBJECT, 0, 0); > > to my understanding each el. in this array is a pointer to my type so > a cast to this type > should work. > > > this is my custom type > > typedef struct val{ > ? ? ? ? PyObject_HEAD > ? ? ? ? float q; > ? ? ? ? float wl; > ? ? ? ? int cssid; > ? ? ? ? int br; > }hm1dval; > > I am passing only one element for testing purposes. > > in python > a = [hm1d1.hm1dval() for i in range(0,1)] > for c in a: > ? ? ? ? c.set_values(q=3.0, wl=2.5, cssid=6, br=7) > > > So following code should be valid in C: > > hm1dval s* = PyArray_DATA(array); > > but the members are 0 after casting in spite they were set previously. The elements of a dtype=object array are PyObject* pointers. In C, an array of pointers would look like this: hm1dval **s = PyArray_DATA(array); -- 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 From p.sanjey at gmail.com Mon Oct 4 11:14:06 2010 From: p.sanjey at gmail.com (P Sanjey) Date: Mon, 4 Oct 2010 11:14:06 -0400 Subject: [Numpy-discussion] numpy installation Message-ID: I couldn't intially install numpy on python2.4.......installing then importing resulted in the following (please read below before answering thanks) >>> import numpy Traceback (most recent call last): File "", line 1, in ? File "/cluster/lib/python2.4/site-packages/numpy/__init__.py", line 147, in ? import fft File "/cluster/lib/python2.4/site-packages/numpy/fft/__init__.py", line 4, in ? from fftpack import * File "/cluster/lib/python2.4/site-packages/numpy/fft/fftpack.py", line 39, in ? import fftpack_lite as fftpack ImportError: /cluster/lib/python2.4/site-packages/numpy/fft/fftpack_lite.so: undefined symbol: vmldSinCos2 The problem was sorted by modifying the following files..... site.cfg [DEFAULT] libraries = svml, mkl, vml library_dirs = /usr/local/lib, /opt/intel/cc/9.1/lib, /opt/intel/fc/9.1/lib include_dirs = /usr/local/include, /opt/intel/cc/9.1/include, /opt/intel/fc/9.1/include numpy-1.4.1/numpy/distutils/intelccompiler.py cc_exe = 'icc -O2 -g -fomit-frame-pointer -mcpu=pentium4 -march=pentium4 -msse2 -axWN -Wall -lsvml -L/opt/intel/cc/9.1/lib -I/opt/intel/cc/9.1/include' Now I want to install numpy on the server but have the same problem When I looked in the intel folder in the server there was only on directory-licences NO cc directory was present to add to the site.cfg file in the server Can I simply find them online and move them into intel directory? I don''t want to mess the server but don't really understand all this-if someone could help me it will be much appreciated From chris at simplistix.co.uk Tue Oct 5 08:53:22 2010 From: chris at simplistix.co.uk (Chris Withers) Date: Tue, 05 Oct 2010 13:53:22 +0100 Subject: [Numpy-discussion] ufunc.accumulate question Message-ID: <4CAB1FC2.4030601@simplistix.co.uk> Hi All, I can't find any docs on this behavior. So, I have a python function. To keep it simple, lets just do addition: def add(x,y): print x,y retun x+y So, I can turn this into a ufunc as follows: uadd = np.frompyfunc(add,2,1) Now, I can apply it to an array: >>> uadd.accumulate(np.arange(3,10)) 3 4 7 5 12 6 18 7 25 8 33 9 array([3, 7, 12, 18, 25, 33, 42], dtype=object) Okay, but where did the initial 3 come from? http://docs.scipy.org/doc/numpy/reference/generated/numpy.ufunc.accumulate.html#numpy.ufunc.accumulate suggests that: r = np.empty(len(A)) t = op.identity # op = the ufunc being applied to A's elements for i in xrange(len(A)): t = op(t, A[i]) r[i] = t return r ...but: >>> print uadd.identity None ...and: >>> add(None,3) None 3 Traceback (most recent call last): File "", line 1, in File "", line 3, in add TypeError: unsupported operand type(s) for +: 'NoneType' and 'int' So, where is the reason that the 3 ends up in the output array documented? Also, what if I want to specify the identity of my newly created ufunc? I have a case where I want to specify it as zero: >>> uadd.identity = 0 Traceback (most recent call last): File "", line 1, in AttributeError: attribute 'identity' of 'numpy.ufunc' objects is not writable Any help gratefully received! Chris From rowen at uw.edu Tue Oct 5 12:32:01 2010 From: rowen at uw.edu (Russell E. Owen) Date: Tue, 05 Oct 2010 09:32:01 -0700 Subject: [Numpy-discussion] numpy mac binary for Python 2.7: which version is it for? Message-ID: There are two Python 2.7 installers available at python.org a 32 bit version for MacOS X 10.3.9 and later and a 64 bit version for Mac OS X 10.5 and later. There is one numpy 1.5.0 binary installer for Mac Python 2.7. Which Mac python was it built for? (Or if it is compatible with both, how did you manage that?). -- Russell From pav at iki.fi Tue Oct 5 19:49:36 2010 From: pav at iki.fi (Pauli Virtanen) Date: Tue, 5 Oct 2010 23:49:36 +0000 (UTC) Subject: [Numpy-discussion] Schedule for 1.5.1? Message-ID: Hi, Should we set a date for a bugfix 1.5.1 release? There are some bugs that would be nice to sort out in the 1.5.x series: Any Python versions: - #1605 (Cython vs. PEP-3118 issue: raising exceptions with active cython buffers caused undefined behavior. Breaks Sage.) - #1617 (Ensure complex(np.longcomplex(...)) doesn't drop the imag part) - Fix doc build Python 3 specific: - #1604 (//-issue in distutils; infinite loop in some cases :) - #1609 (dotblas was never used on Python 3) - #1610 (fromfile/tofile did not stay in sync with Python 3 file handle position -- breaks e.g. scipy.io pretty badly) - f2py startup script didn't run properly on Py3 Not so many fixes so far, but I'd like to see a Numpy release with #1610 fixed before releasing Scipy with Python 3 support. Since 2.0.0 breaks binary compatibility and merging the refactoring back may take some time, it would be nice to have another 1.5.x release. Ralf & c, opinions? I'd maybe suggest somewhere on the Oct/Nov axis. Pauli From charlesr.harris at gmail.com Tue Oct 5 20:12:17 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Tue, 5 Oct 2010 18:12:17 -0600 Subject: [Numpy-discussion] Schedule for 1.5.1? In-Reply-To: References: Message-ID: On Tue, Oct 5, 2010 at 5:49 PM, Pauli Virtanen wrote: > Hi, > > Should we set a date for a bugfix 1.5.1 release? There are some bugs that > would be nice to sort out in the 1.5.x series: > > Any Python versions: > > - #1605 (Cython vs. PEP-3118 issue: raising exceptions with active > cython buffers caused undefined behavior. Breaks Sage.) > - #1617 (Ensure complex(np.longcomplex(...)) doesn't drop the imag part) > - Fix doc build > > Python 3 specific: > > - #1604 (//-issue in distutils; infinite loop in some cases :) > - #1609 (dotblas was never used on Python 3) > - #1610 (fromfile/tofile did not stay in sync with Python 3 file handle > position -- breaks e.g. scipy.io pretty badly) > - f2py startup script didn't run properly on Py3 > > Not so many fixes so far, but I'd like to see a Numpy release with #1610 > fixed before releasing Scipy with Python 3 support. Since 2.0.0 breaks > binary compatibility and merging the refactoring back may take some time, > it would be nice to have another 1.5.x release. > > Ralf & c, opinions? I'd maybe suggest somewhere on the Oct/Nov axis. > > Sounds good. I also have some stuff I'd like to add but won't have much time before Nov. But whatever looks good to Ralf will work for me. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From icpup at verizon.net Tue Oct 5 21:57:25 2010 From: icpup at verizon.net (Jing) Date: Tue, 05 Oct 2010 21:57:25 -0400 Subject: [Numpy-discussion] Please help on compilation fortran module using f2py Message-ID: <4CABD785.5090008@verizon.net> Hi, everyone: I am new to the python numpy and f2py. I really need help on compiling FORTRAN module using f2py. I have been searched internet without any success. Here is my setup: I have a Ubuntu 10.04 LTS with python 2.6, numpy 1.3.0 and f2py 2 (installed from ubuntu) and gfortran compiler 4.4. I have a simple Fortran subroutine (in CSM_CH01_P1_1a_F.f95 file) as shown below: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ! subroutine sim_model_1(ts, n, a) ! !f2py integer, intent(in) :: ts, n !f2py real,dimension(n), intent(inout) :: a implicit none integer :: t, m, i real :: ep, dm ! m=n/2; call init_random_seed() do if(t > ts) exit call randperm(n,a) call random_number(ep) do i=1,n,2 dm=a(i)+a(i+1) a(i)=ep*dm a(i+1)=(1-ep)*dm end do t = t + 1 end do return end subroutine sim_model_1 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I use f2py -m sim_model_1 -h sim_model_1.pyf CSM_CH01_P1_1a_F.f95 to generate signature file which is OK as shown below: =================================================== ! -*- f90 -*- ! Note: the context of this file is case sensitive. python module sim_model_1 ! in interface ! in :sim_model_1 subroutine sim_model_1(ts,n,a) ! in :sim_model_1:CSM_CH01_P1_1a_F.f95 integer intent(in) :: ts integer optional,intent(in),check(len(a)>=n),depend(a) :: n=len(a) real dimension(n),intent(inout) :: a end subroutine sim_model_1 end interface end python module sim_model_1 ! This file was auto-generated with f2py (version:2). ! See http://cens.ioc.ee/projects/f2py2e =================================================== However, when I try to make the module, the compilation failed as if f2py does not pass the signature file to the compiler. The screen printout during compilation as shown below: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ f2py -c --fcompiler=gnu95 sim_model_1.pyf CSM_CH <> f2py -c --fcompiler=gnu95 sim_model_1.pyf CSM_CH0 1_P1_1a_F.f95 running build running config_cc unifing config_cc, config, build_clib, build_ext, build commands --compiler options running config_fc unifing config_fc, config, build_clib, build_ext, build commands --fcompiler options running build_src building extension "sim_model_1" sources creating /tmp/tmp6MXJY3 creating /tmp/tmp6MXJY3/src.linux-x86_64-2.6 f2py options: [] f2py: sim_model_1.pyf Reading fortran codes... Reading file 'sim_model_1.pyf' (format:free) Post-processing... Block: sim_model_1 Block: sim_model_1 Post-processing (stage 2)... Building modules... Building module "sim_model_1"... Constructing wrapper function "sim_model_1"... sim_model_1(ts,a,[n]) Wrote C/API module "sim_model_1" to file "/tmp/tmp6MXJY3/src.linux-x86_64-2.6/sim_model_1module.c" adding '/tmp/tmp6MXJY3/src.linux-x86_64-2.6/fortranobject.c' to sources. adding '/tmp/tmp6MXJY3/src.linux-x86_64-2.6' to include_dirs. copying /usr/lib/python2.6/dist-packages/numpy/f2py/src/fortranobject.c -> /tmp/tmp6MXJY3/src.linux-x86_64-2.6 copying /usr/lib/python2.6/dist-packages/numpy/f2py/src/fortranobject.h -> /tmp/tmp6MXJY3/src.linux-x86_64-2.6 running build_ext customize UnixCCompiler customize UnixCCompiler using build_ext customize Gnu95FCompiler Found executable /usr/bin/gfortran customize Gnu95FCompiler using build_ext building 'sim_model_1' extension compiling C sources C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC creating /tmp/tmp6MXJY3/tmp creating /tmp/tmp6MXJY3/tmp/tmp6MXJY3 creating /tmp/tmp6MXJY3/tmp/tmp6MXJY3/src.linux-x86_64-2.6 compile options: '-I/tmp/tmp6MXJY3/src.linux-x86_64-2.6 -I/usr/lib/python2.6/dist-packages/numpy/core/include -I/usr/include/python2.6 -c' gcc: /tmp/tmp6MXJY3/src.linux-x86_64-2.6/fortranobject.c gcc: /tmp/tmp6MXJY3/src.linux-x86_64-2.6/sim_model_1module.c compiling Fortran sources Fortran f77 compiler: /usr/bin/gfortran -Wall -ffixed-form -fno-second-underscore -fPIC -O3 -funroll-loops Fortran f90 compiler: /usr/bin/gfortran -Wall -fno-second-underscore -fPIC -O3 -funroll-loops Fortran fix compiler: /usr/bin/gfortran -Wall -ffixed-form -fno-second-underscore -Wall -fno-second-underscore -fPIC -O3 -funroll-loops compile options: '-I/tmp/tmp6MXJY3/src.linux-x86_64-2.6 -I/usr/lib/python2.6/dist-packages/numpy/core/include -I/usr/include/python2.6 -c' gfortran:f90: CSM_CH01_P1_1a_F.f95 CSM_CH01_P1_1a_F.f95:29.7: a(i)=ep*dm 1 Error: 'a' at (1) is not a variable CSM_CH01_P1_1a_F.f95:30.7: a(i+1)=(1-ep)*dm 1 Error: 'a' at (1) is not a variable CSM_CH01_P1_1a_F.f95:9.25: subroutine sim_model_1(ts, n, a) 1 Error: Symbol 'ts' at (1) has no IMPLICIT type CSM_CH01_P1_1a_F.f95:9.28: subroutine sim_model_1(ts, n, a) 1 Error: Symbol 'n' at (1) has no IMPLICIT type CSM_CH01_P1_1a_F.f95:9.31: subroutine sim_model_1(ts, n, a) 1 Error: Symbol 'a' at (1) has no IMPLICIT type CSM_CH01_P1_1a_F.f95:28.15: dm=a(i)+a(i+1) 1 Error: Function 'a' at (1) has no IMPLICIT type CSM_CH01_P1_1a_F.f95:29.7: a(i)=ep*dm 1 Error: 'a' at (1) is not a variable CSM_CH01_P1_1a_F.f95:30.7: a(i+1)=(1-ep)*dm 1 Error: 'a' at (1) is not a variable CSM_CH01_P1_1a_F.f95:9.25: subroutine sim_model_1(ts, n, a) 1 Error: Symbol 'ts' at (1) has no IMPLICIT type CSM_CH01_P1_1a_F.f95:9.28: subroutine sim_model_1(ts, n, a) 1 Error: Symbol 'n' at (1) has no IMPLICIT type CSM_CH01_P1_1a_F.f95:9.31: subroutine sim_model_1(ts, n, a) 1 Error: Symbol 'a' at (1) has no IMPLICIT type CSM_CH01_P1_1a_F.f95:28.15: dm=a(i)+a(i+1) 1 Error: Function 'a' at (1) has no IMPLICIT type error: Command "/usr/bin/gfortran -Wall -fno-second-underscore -fPIC -O3 -funroll-loops -I/tmp/tmp6MXJY3/src.linux-x86_64-2.6 -I/usr/lib/python2.6/dist-packages/numpy/core/include -I/usr/include/python2.6 -c -c CSM_CH01_P1_1a_F.f95 -o /tmp/tmp6MXJY3/CSM_CH01_P1_1a_F.o" failed with exit status 1 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ It looks like the two f2py directive declaration cause the problem. Any suggestion? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ioan.ferencik at tkk.fi Wed Oct 6 02:27:29 2010 From: ioan.ferencik at tkk.fi (Ioan Ferencik) Date: Wed, 6 Oct 2010 09:27:29 +0300 Subject: [Numpy-discussion] ndarray of object dtype In-Reply-To: <15612_1286204190_ZZ0L9R0038DTI5HY.00_AANLkTinopyssMBw-wHgsdmgVXGijBS-TVGm8=YQLcOzp@mail.gmail.com> References: <20101004084120.7bmxuk1dcsc0coko@webmail3.tkk.fi> <15612_1286204190_ZZ0L9R0038DTI5HY.00_AANLkTinopyssMBw-wHgsdmgVXGijBS-TVGm8=YQLcOzp@mail.gmail.com> Message-ID: <20101006092729.poqfq8jyo0ws4c0s@webmail3.tkk.fi> Thanks Robert, that worked just great. I was wandering whether anyone has experience with calling Fortran 90 functions that return derived types and cast them to C/Python objects. I have found excellent reference in a couple of websites, however all examples deal with returning at best 2D arrays of fundamental/basic types. When it comes to derived types/structures I have following dilemma: should I use Fortran subroutines, allocate memory in C and pass the structures as arguments or should I use functions, allocate memory in Fortran and return the data to C/Python. I should mention I have little experience in C/Fortran. All thoughts are welcome. Quoting Robert Kern : > On Mon, Oct 4, 2010 at 00:41, Ioan Ferencik wrote: >> Hello list, >> >> I am trying to pass elements of a custom defined with C API. >> I have successfully wrapped a type around a C struct. >> I intent to create a list with these objects and process it using >> numpy C API. >> So i ?create an array: >> >> array = (PyArrayObject *)PyArray_ContiguousFromObject(input, >> PyArray_OBJECT, 0, 0); >> >> to my understanding each el. in this array is a pointer to my type so >> a cast to this type >> should work. >> >> >> this is my custom type >> >> typedef struct val{ >> ? ? ? ? PyObject_HEAD >> ? ? ? ? float q; >> ? ? ? ? float wl; >> ? ? ? ? int cssid; >> ? ? ? ? int br; >> }hm1dval; >> >> I am passing only one element for testing purposes. >> >> in python >> a = [hm1d1.hm1dval() for i in range(0,1)] >> for c in a: >> ? ? ? ? c.set_values(q=3.0, wl=2.5, cssid=6, br=7) >> >> >> So following code should be valid in C: >> >> hm1dval s* = PyArray_DATA(array); >> >> but the members are 0 after casting in spite they were set previously. > > The elements of a dtype=object array are PyObject* pointers. In C, an > array of pointers would look like this: > > hm1dval **s = PyArray_DATA(array); > > -- > 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 at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > Ioan Ferencik PhD student Aalto University School of Science and Technology Faculty Of Civil and Env. Engineering Lahti Center Tel: +358505122707 From pearu.peterson at gmail.com Wed Oct 6 03:26:32 2010 From: pearu.peterson at gmail.com (Pearu Peterson) Date: Wed, 06 Oct 2010 10:26:32 +0300 Subject: [Numpy-discussion] Please help on compilation fortran module using f2py In-Reply-To: <4CABD785.5090008@verizon.net> References: <4CABD785.5090008@verizon.net> Message-ID: <4CAC24A8.1090502@cens.ioc.ee> Hi, On 10/06/2010 04:57 AM, Jing wrote: > Hi, everyone: > > I am new to the python numpy and f2py. I really need help on compiling > FORTRAN module using f2py. I have been searched internet without any > success. Here is my setup: I have a Ubuntu 10.04 LTS with python 2.6, > numpy 1.3.0 and f2py 2 (installed from ubuntu) and gfortran compiler > 4.4. I have a simple Fortran subroutine (in CSM_CH01_P1_1a_F.f95 file) > as shown below: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ! > > subroutine sim_model_1(ts, n, a) > > ! > > !f2py integer, intent(in) :: ts, n > > !f2py real,dimension(n), intent(inout) :: a > > implicit none The problem is in Fortran code. The ts, n, and a variables need to be declared for fortran compiler too. The f2py directives are invisible to the fortran compiler, they are just comments that are used by f2py. So, try adding these lines to the Fortran code: integer, intent(in) :: ts, n real, dimension(n) :: a HTH, Pearu From chris at simplistix.co.uk Wed Oct 6 05:26:35 2010 From: chris at simplistix.co.uk (Chris Withers) Date: Wed, 06 Oct 2010 10:26:35 +0100 Subject: [Numpy-discussion] index of a value in an array Message-ID: <4CAC40CB.70103@simplistix.co.uk> Hi All, Given an array such as: array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9]) How can I find the index of a particular number in the array? (ie: if it was a list, I'd do [1,2,3,4].index(3)) cheers, Chris From structures-it at embl-heidelberg.de Wed Oct 6 05:59:13 2010 From: structures-it at embl-heidelberg.de (Frank Thommen) Date: Wed, 06 Oct 2010 11:59:13 +0200 Subject: [Numpy-discussion] alter_code1.py doesn't convert (any more)? Message-ID: <4CAC4871.6090404@embl-heidelberg.de> Hi, I'm trying to help a user to migrate from Numeric - which he used up to now - to numpy. I found reference to alter_code1.py on http://numpy.scipy.org/old_array_packages.html. First I tried the conversion script: # python2.6 /path/to/alter_code1.py test.py and alternatively # python2.6 /path/to/alter_code1.py ./ This didn't modify test.py at all. Then I tried to convert from within Python: # python2.6 Python 2.6.2 (r262:71600, Aug 5 2010, 14:21:11) [GCC 4.4.4] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import numpy.numarray.alter_code1 as noa >>> noa.convertfile("test.py") >>> ^D # This modified test.py, but only partially. E.g. the import line was still untouched, meaning that it still imported Numeric instead of numpy: # diff ../test-original.py test.py 0a1,2 > ## Automatically adapted for numpy.numarray Oct 06, 2010 by > 49c51 < pyfid.byteswap() --- > pyfid.byteswap(True) 74c76 < databin.byteswap() --- > databin.byteswap(True) # After I've changed 'import os, string, array, Numeric' to 'import os, string, array, numpy' I realized, that the conversion had introduced errors: # python2.6 ./test.py Traceback (most recent call last): File "./test.py", line 115, in combineser3D(td3,td2,td1,ser,ser1,fidnum) File "./test.py", line 21, in combineser3D allser1=readBrukerSer(tdall,td3,ser) File "./test.py", line 51, in readBrukerSer pyfid.byteswap(True) TypeError: byteswap() takes no arguments (1 given) # So either this method doesn't work (any more) or I am doing something wrong. The numpy version we are using is 1.4.1 with Python 2.6.2 from python.org. Any help regarding this is highly appreciated. Thanks in advance frank From nbigaouette at gmail.com Wed Oct 6 08:23:46 2010 From: nbigaouette at gmail.com (Nicolas Bigaouette) Date: Wed, 6 Oct 2010 08:23:46 -0400 Subject: [Numpy-discussion] index of a value in an array In-Reply-To: <4CAC40CB.70103@simplistix.co.uk> References: <4CAC40CB.70103@simplistix.co.uk> Message-ID: On Wed, Oct 6, 2010 at 5:26 AM, Chris Withers wrote: > Hi All, > > Given an array such as: > > array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9]) > > How can I find the index of a particular number in the array? > > (ie: if it was a list, I'd do [1,2,3,4].index(3)) > > cheers, > > Chris > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > Try with numpy.where(array == value) and plain "array == value" IIRC, the first will return an array the size of the found elements and the second will return an array (or list?) of True/False. Either can be used as "index = numpy.where()" and "index = (array == value)" and then "array[index]". N -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian1.thomas at ge.com Wed Oct 6 09:53:58 2010 From: brian1.thomas at ge.com (Thomas, Brian (GE Energy)) Date: Wed, 6 Oct 2010 09:53:58 -0400 Subject: [Numpy-discussion] index of a value in an array In-Reply-To: <4CAC40CB.70103@simplistix.co.uk> References: <4CAC40CB.70103@simplistix.co.uk> Message-ID: <24F03932F9E5CA46AF1C322B9E27818503DB4BE4@CINMLVEM14.e2k.ad.ge.com> Chris, You can use where() command to find index of a particular number in the array. For e.g. to find index of number 1 in array a, you can say idx = where(a==1) Regards, Brian -----Original Message----- From: numpy-discussion-bounces at scipy.org [mailto:numpy-discussion-bounces at scipy.org] On Behalf Of Chris Withers Sent: Wednesday, October 06, 2010 5:27 AM To: numpy-discussion at scipy.org Cc: snezana.pejic at glcuk.com Subject: [Numpy-discussion] index of a value in an array Hi All, Given an array such as: array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9]) How can I find the index of a particular number in the array? (ie: if it was a list, I'd do [1,2,3,4].index(3)) cheers, Chris _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion at scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion From chris at simplistix.co.uk Wed Oct 6 10:24:42 2010 From: chris at simplistix.co.uk (Chris Withers) Date: Wed, 06 Oct 2010 15:24:42 +0100 Subject: [Numpy-discussion] index of a value in an array In-Reply-To: <24F03932F9E5CA46AF1C322B9E27818503DB4BE4@CINMLVEM14.e2k.ad.ge.com> References: <4CAC40CB.70103@simplistix.co.uk> <24F03932F9E5CA46AF1C322B9E27818503DB4BE4@CINMLVEM14.e2k.ad.ge.com> Message-ID: <4CAC86AA.6090002@simplistix.co.uk> On 06/10/2010 14:53, Thomas, Brian (GE Energy) wrote: > For e.g. to find index of number 1 in array a, you can say > idx = where(a==1) Exactly what we were looking for, thanks! Chris From ben.root at ou.edu Wed Oct 6 10:27:39 2010 From: ben.root at ou.edu (Benjamin Root) Date: Wed, 6 Oct 2010 09:27:39 -0500 Subject: [Numpy-discussion] index of a value in an array In-Reply-To: References: <4CAC40CB.70103@simplistix.co.uk> Message-ID: On Wed, Oct 6, 2010 at 7:23 AM, Nicolas Bigaouette wrote: > On Wed, Oct 6, 2010 at 5:26 AM, Chris Withers wrote: > >> Hi All, >> >> Given an array such as: >> >> array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9]) >> >> How can I find the index of a particular number in the array? >> >> (ie: if it was a list, I'd do [1,2,3,4].index(3)) >> >> cheers, >> >> Chris >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> > > Try with numpy.where(array == value) and plain "array == value" > IIRC, the first will return an array the size of the found elements and the > second will return an array (or list?) of True/False. > Either can be used as "index = numpy.where()" and "index = (array == > value)" and then "array[index]". > N > > Wouldn't it be more technically correct to use numpy.nonzero()? Returning the index is a special behavior of not specifying the second argument to numpy.where(). Ben Root -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrocher at enthought.com Wed Oct 6 10:48:32 2010 From: jrocher at enthought.com (Jonathan Rocher) Date: Wed, 6 Oct 2010 09:48:32 -0500 Subject: [Numpy-discussion] index of a value in an array In-Reply-To: <24F03932F9E5CA46AF1C322B9E27818503DB4BE4@CINMLVEM14.e2k.ad.ge.com> References: <4CAC40CB.70103@simplistix.co.uk> <24F03932F9E5CA46AF1C322B9E27818503DB4BE4@CINMLVEM14.e2k.ad.ge.com> Message-ID: Chris, Note that >>> where(condition) actually returns a tuple (one item for each dimension of a) and each element is an array with the index of when your condition occurs. Therefore if you want to extract the index itself, you need to write idx = where(a==1)[0][0] for the first element, and where(a==1)[0] for the array of all indices. Best, Jonathan On Wed, Oct 6, 2010 at 8:53 AM, Thomas, Brian (GE Energy) < brian1.thomas at ge.com> wrote: > Chris, > > You can use where() command to find index of a particular number in the > array. > > For e.g. to find index of number 1 in array a, you can say > idx = where(a==1) > > Regards, > Brian > > -----Original Message----- > From: numpy-discussion-bounces at scipy.org > [mailto:numpy-discussion-bounces at scipy.org] On Behalf Of Chris Withers > Sent: Wednesday, October 06, 2010 5:27 AM > To: numpy-discussion at scipy.org > Cc: snezana.pejic at glcuk.com > Subject: [Numpy-discussion] index of a value in an array > > Hi All, > > Given an array such as: > > array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9]) > > How can I find the index of a particular number in the array? > > (ie: if it was a list, I'd do [1,2,3,4].index(3)) > > cheers, > > Chris > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -- Jonathan Rocher, Enthought, Inc. jrocher at enthought.com 1-512-536-1057 http://www.enthought.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From friedrichromstedt at gmail.com Wed Oct 6 12:35:30 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Wed, 6 Oct 2010 18:35:30 +0200 Subject: [Numpy-discussion] ufunc.accumulate question In-Reply-To: <4CAB1FC2.4030601@simplistix.co.uk> References: <4CAB1FC2.4030601@simplistix.co.uk> Message-ID: 2010/10/5 Chris Withers : > Hi All, > > I can't find any docs on this behavior. > > So, I have a python function. To keep it simple, lets just do addition: > > def add(x,y): > ? print x,y > ? retun x+y > > So, I can turn this into a ufunc as follows: > > uadd = np.frompyfunc(add,2,1) As a side remark, note that this will always return dtype=numpy.object arrays. Maybe numpy.vectorize() is more appropriate for your use-case. > Now, I can apply it to an array: > > ?>>> uadd.accumulate(np.arange(3,10)) > 3 4 > 7 5 > 12 6 > 18 7 > 25 8 > 33 9 > array([3, 7, 12, 18, 25, 33, 42], dtype=object) > > Okay, but where did the initial 3 come from? > http://docs.scipy.org/doc/numpy/reference/generated/numpy.ufunc.accumulate.html#numpy.ufunc.accumulate > suggests that: > > r = np.empty(len(A)) > t = op.identity ? ? ? ?# op = the ufunc being applied to A's ?elements > for i in xrange(len(A)): > ? ? t = op(t, A[i]) > ? ? r[i] = t > return r I see from the behaviour, that the implementation makes use of the following behaviour of the identity ``op.identity`` with respect to ``op``: >>> op(op.identity, X) == X True So the implementation acts in agnosticism of ``op.identity`` by assuming that the first call of ``t = op(t, A[i])`` in your example will just yield ``A[0]``, while i == 0. This is the work flow: [ t = op.identity ] # in brackets because it cannot be executed, it's pseudo-code i = 0 ===== t = op(t, A[0]) = A[0] r[0] = t = A[0] i = 1 ===== t = op(t, A[1]) = op(A[0], A[1]) r[1] = t i = 2 ===== t = op(t, A[2]) = op(op(A[0], A[1]), A[2]) r[2] = t and so on ... clear now? Friedrich > ...but: > > ?>>> print uadd.identity > None It's simply not set, and will also not be used. > ...and: > > ?>>> add(None,3) > None 3 > Traceback (most recent call last): > ? File "", line 1, in > ? File "", line 3, in add > TypeError: unsupported operand type(s) for +: 'NoneType' and 'int' As said, the code in the docs is just pseudo-code, it's not the actual (C?) implementation, it just has the same semantics. > So, where is the reason that the 3 ends up in the output array documented? > > Also, what if I want to specify the identity of my newly created ufunc? > I have a case where I want to specify it as zero: > > ?>>> uadd.identity = 0 > Traceback (most recent call last): > ? File "", line 1, in > AttributeError: attribute 'identity' of 'numpy.ufunc' objects is not > writable I think you have to write an own class for this. You cannot subclass numpy.ufunc ("it's not an acceptable base class" Python says). From cfischer at itm.uni-stuttgart.de Wed Oct 6 13:55:00 2010 From: cfischer at itm.uni-stuttgart.de (Christian Fischer) Date: Wed, 06 Oct 2010 19:55:00 +0200 Subject: [Numpy-discussion] bug in ceil() Message-ID: <4CACB7F4.3050107@itm.uni-stuttgart.de> Hi All, I use numpy 1.4.1 on Debian squeeze amd64. I noticed that ceil() is not working properly. If the input to ceil() is a float I expect a float to be returned but for inputs in (-1.0, 0.0) the result is of type integer. In [65]: np.__version__ Out[65]: '1.4.1' In [66]: np.ceil(-1.1) Out[66]: -1.0 In [67]: np.ceil(-0.734) Out[67]: -0 In [68]: np.ceil(-0.256) Out[68]: -0 In [69]: np.ceil(-0.0) Out[69]: -0 In [70]: np.ceil(0.2) Out[70]: 1.0 Best wishes Christian -- Dipl.-Ing. Christian Fischer Institute of Engineering and Computational Mechanics (name in German: Institut f?r Technische und Numerische Mechanik) University of Stuttgart, Pfaffenwaldring 9, 70569 Stuttgart, Germany mailto:cfischer at itm.uni-stuttgart.de, tel 0711-685-66565, fax -66400 http://www.itm.uni-stuttgart.de/staff/Fischer -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3698 bytes Desc: S/MIME Cryptographic Signature URL: From mdroe at stsci.edu Wed Oct 6 13:57:45 2010 From: mdroe at stsci.edu (Michael Droettboom) Date: Wed, 06 Oct 2010 13:57:45 -0400 Subject: [Numpy-discussion] bug in ceil() In-Reply-To: <4CACB7F4.3050107@itm.uni-stuttgart.de> References: <4CACB7F4.3050107@itm.uni-stuttgart.de> Message-ID: <4CACB899.6090900@stsci.edu> Are you sure? In [4]: type(np.ceil(-0.0)) Out[4]: Mike On 10/06/2010 01:55 PM, Christian Fischer wrote: > Hi All, > > I use numpy 1.4.1 on Debian squeeze amd64. > > I noticed that ceil() is not working properly. > > If the input to ceil() is a float I expect a float to be returned but for inputs > in (-1.0, 0.0) the result is of type integer. > > In [65]: np.__version__ > Out[65]: '1.4.1' > > In [66]: np.ceil(-1.1) > Out[66]: -1.0 > > In [67]: np.ceil(-0.734) > Out[67]: -0 > > In [68]: np.ceil(-0.256) > Out[68]: -0 > > In [69]: np.ceil(-0.0) > Out[69]: -0 > > In [70]: np.ceil(0.2) > Out[70]: 1.0 > > Best wishes > Christian > > > > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Wed Oct 6 14:10:50 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Wed, 6 Oct 2010 12:10:50 -0600 Subject: [Numpy-discussion] bug in ceil() In-Reply-To: <4CACB7F4.3050107@itm.uni-stuttgart.de> References: <4CACB7F4.3050107@itm.uni-stuttgart.de> Message-ID: On Wed, Oct 6, 2010 at 11:55 AM, Christian Fischer < cfischer at itm.uni-stuttgart.de> wrote: > Hi All, > > I use numpy 1.4.1 on Debian squeeze amd64. > > I noticed that ceil() is not working properly. > > If the input to ceil() is a float I expect a float to be returned but for > inputs > in (-1.0, 0.0) the result is of type integer. > > In [65]: np.__version__ > Out[65]: '1.4.1' > > In [66]: np.ceil(-1.1) > Out[66]: -1.0 > > In [67]: np.ceil(-0.734) > Out[67]: -0 > > In [68]: np.ceil(-0.256) > Out[68]: -0 > > In [69]: np.ceil(-0.0) > Out[69]: -0 > > In [70]: np.ceil(0.2) > Out[70]: 1.0 > > The -0 is a float type, you can't get it with integers. The printing might could be tweaked to return -0.0, which would be less misleading. The thing that bothers me is that -0 is returned instead of 0.0, but that can be fixed. In [2]: ceil(-.5) Out[2]: -0 In [3]: ceil(-.5) + 0 Out[3]: 0.0 Please open a ticket, maybe two. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From nwagner at iam.uni-stuttgart.de Wed Oct 6 14:13:15 2010 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Wed, 06 Oct 2010 20:13:15 +0200 Subject: [Numpy-discussion] bug in ceil() In-Reply-To: <4CACB7F4.3050107@itm.uni-stuttgart.de> References: <4CACB7F4.3050107@itm.uni-stuttgart.de> Message-ID: On Wed, 06 Oct 2010 19:55:00 +0200 Christian Fischer wrote: > Hi All, > > I use numpy 1.4.1 on Debian squeeze amd64. > > I noticed that ceil() is not working properly. > > If the input to ceil() is a float I expect a float to be >returned but for inputs > in (-1.0, 0.0) the result is of type integer. > > In [65]: np.__version__ > Out[65]: '1.4.1' > > In [66]: np.ceil(-1.1) > Out[66]: -1.0 > > In [67]: np.ceil(-0.734) > Out[67]: -0 > > In [68]: np.ceil(-0.256) > Out[68]: -0 > > In [69]: np.ceil(-0.0) > Out[69]: -0 > > In [70]: np.ceil(0.2) > Out[70]: 1.0 > > Best wishes > Christian > It's a float >>> type(numpy.ceil(-0.4)) >>> numpy.ceil(-0.4) -0 Nils From p.sanjey at gmail.com Wed Oct 6 15:27:53 2010 From: p.sanjey at gmail.com (P Sanjey) Date: Wed, 6 Oct 2010 15:27:53 -0400 Subject: [Numpy-discussion] numpy on 64 bit x86_64 Message-ID: Hi I have a x86_64 Fedora core 3 machine where I want to install numpy but python2.4 has been installed on this machine using Intel compilers instead of gcc Can someone tell me how I can install numpy on this architecture? Thanks From renato.fabbri at gmail.com Wed Oct 6 17:08:53 2010 From: renato.fabbri at gmail.com (Renato Fabbri) Date: Wed, 6 Oct 2010 18:08:53 -0300 Subject: [Numpy-discussion] point line distance Message-ID: supose you have a line defined by two points and a point. you want the distance what are easiest possibilities? i am doing it, but its nasty'n ugly -- GNU/Linux User #479299 skype: fabbri.renato From alan.isaac at gmail.com Wed Oct 6 17:10:54 2010 From: alan.isaac at gmail.com (Alan G Isaac) Date: Wed, 06 Oct 2010 17:10:54 -0400 Subject: [Numpy-discussion] puzzle with boolean dtype Message-ID: <4CACE5DE.9010803@gmail.com> Integer exponentiation fails (i.e., changes type) with boolean dtype. See below. Expected? Alan Isaac >>> a = np.array([[0,1,0],[0,0,1],[1,0,0]], dtype=np.bool_) >>> a2 = a*a >>> a3 = a2*a >>> print(a3) [[False True False] [False False True] [ True False False]] >>> print(a**3) [[0 1 0] [0 0 1] [1 0 0]] From zachary.pincus at yale.edu Wed Oct 6 17:17:24 2010 From: zachary.pincus at yale.edu (Zachary Pincus) Date: Wed, 6 Oct 2010 17:17:24 -0400 Subject: [Numpy-discussion] point line distance In-Reply-To: References: Message-ID: <8F91514A-09D3-4C2C-8949-508C68939770@yale.edu> Here's a good list of basic geometry algorithms: http://www.softsurfer.com/algorithms.htm Zach On Oct 6, 2010, at 5:08 PM, Renato Fabbri wrote: > supose you have a line defined by two points and a point. you want > the distance > > what are easiest possibilities? i am doing it, but its nasty'n ugly > > -- > GNU/Linux User #479299 > skype: fabbri.renato > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion From geometrian at gmail.com Wed Oct 6 17:13:42 2010 From: geometrian at gmail.com (Ian Mallett) Date: Wed, 6 Oct 2010 15:13:42 -0600 Subject: [Numpy-discussion] point line distance In-Reply-To: References: Message-ID: Hi, A background in linear algebra helps. I just came up with this method (which, because I thought of it 5 seconds ago, I don't know if it works): Line p1, p2 Point v costheta = normalize(p2-p1) dot normalize(v-p1) dist = length(v-p1)*sin(acos(costheta) Ian -------------- next part -------------- An HTML attachment was scrubbed... URL: From geometrian at gmail.com Wed Oct 6 17:13:42 2010 From: geometrian at gmail.com (Ian Mallett) Date: Wed, 6 Oct 2010 15:13:42 -0600 Subject: [Numpy-discussion] point line distance In-Reply-To: References: Message-ID: Hi, A background in linear algebra helps. I just came up with this method (which, because I thought of it 5 seconds ago, I don't know if it works): Line p1, p2 Point v costheta = normalize(p2-p1) dot normalize(v-p1) dist = length(v-p1)*sin(acos(costheta) Ian -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Wed Oct 6 17:52:32 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Wed, 6 Oct 2010 15:52:32 -0600 Subject: [Numpy-discussion] puzzle with boolean dtype In-Reply-To: <4CACE5DE.9010803@gmail.com> References: <4CACE5DE.9010803@gmail.com> Message-ID: On Wed, Oct 6, 2010 at 3:10 PM, Alan G Isaac wrote: > Integer exponentiation fails (i.e., changes type) > with boolean dtype. See below. Expected? > > Power isn't defined for booleans, I mean, who exponentiates booleans ;) What would you want in it's place? For consistancy, a**0 == all_true, a**i == a, i > 0? Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.isaac at gmail.com Wed Oct 6 18:12:23 2010 From: alan.isaac at gmail.com (Alan G Isaac) Date: Wed, 06 Oct 2010 18:12:23 -0400 Subject: [Numpy-discussion] puzzle with boolean dtype In-Reply-To: References: <4CACE5DE.9010803@gmail.com> Message-ID: <4CACF447.2090406@gmail.com> On 10/6/2010 5:52 PM, Charles R Harris wrote: > What would you want in it's place? For consistancy, a**0 == all_true, a**i == a, i > 0? Yes. Alan Isaac PS Boolean matrix powers are well defined and useful. I found this oddity by accidentally creating an array instead of a matrix. From charlesr.harris at gmail.com Wed Oct 6 18:46:12 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Wed, 6 Oct 2010 16:46:12 -0600 Subject: [Numpy-discussion] puzzle with boolean dtype In-Reply-To: <4CACF447.2090406@gmail.com> References: <4CACE5DE.9010803@gmail.com> <4CACF447.2090406@gmail.com> Message-ID: On Wed, Oct 6, 2010 at 4:12 PM, Alan G Isaac wrote: > On 10/6/2010 5:52 PM, Charles R Harris wrote: > > What would you want in it's place? For consistancy, a**0 == all_true, > a**i == a, i > 0? > > Yes. > > Alan Isaac > > PS Boolean matrix powers are well defined and useful. > I found this oddity by accidentally creating an array instead of a matrix. > Open an enhancement ticket then, with clear instructions as to what you want. What about fractional/negative exponents? I mean, the definition extends to positive rationals without problem given a discontinuity when the exponent goes to zero but negative exponents are a problem for False. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmarch at enthought.com Wed Oct 6 19:08:51 2010 From: jmarch at enthought.com (Jonathan March) Date: Wed, 6 Oct 2010 18:08:51 -0500 Subject: [Numpy-discussion] known failure test decorator not treated as expected by nose Message-ID: It appears that the numpy testing decorators for skipping and for known failure should behave similarly to each other, at least from their descriptions here: http://projects.scipy.org/numpy/wiki/TestingGuidelines#known-failures-skipping-tests Yet in the following example, run under nose, they behave quite differently: ==== from numpy.testing import dec @dec.knownfailureif( True, "known failure test message") def test_will_fail(): pass @dec.skipif( True, "skip test message") def test_to_skip(): pass ==== The skipped test is marked as "S" as expected, but when the KnownFailureTest exception is raised, nose handles it as an error (marked "E" rather than "K" as expected, and printing the stack trace.) It's also interesting that nose has a --no-skip option but no corresponding option for ignoring known failure decorators. Why the discrepancy? Who is out of step with whom? This is with numpy 1.4.0 and nosetests 0.11.3 Thanks, Jonathan March From josef.pktd at gmail.com Wed Oct 6 19:17:29 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Wed, 6 Oct 2010 19:17:29 -0400 Subject: [Numpy-discussion] known failure test decorator not treated as expected by nose In-Reply-To: References: Message-ID: On Wed, Oct 6, 2010 at 7:08 PM, Jonathan March wrote: > It appears that the numpy testing decorators for skipping and for > known failure should behave similarly to each other, at least from > their descriptions here: > http://projects.scipy.org/numpy/wiki/TestingGuidelines#known-failures-skipping-tests > > Yet in the following example, run under nose, they behave quite differently: > > ==== > from numpy.testing import ?dec > > @dec.knownfailureif( True, "known failure test message") > def test_will_fail(): > ? ?pass > > @dec.skipif( True, "skip test message") > def test_to_skip(): > ? ?pass > ==== > > The skipped test is marked as "S" as expected, but when the > KnownFailureTest exception is raised, nose handles it as an error > (marked "E" rather than "K" as expected, and printing the stack > trace.) > > It's also interesting that nose has a --no-skip option but no > corresponding option for ignoring known failure decorators. > > Why the discrepancy? Who is out of step with whom? This is with numpy > 1.4.0 and nosetests 0.11.3 just as additional information This only happens on the command line, with nosetests packagename but not with the function, packagename.test() Josef > > Thanks, > Jonathan March > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > From fonnesbeck at gmail.com Wed Oct 6 22:48:16 2010 From: fonnesbeck at gmail.com (Chris Fonnesbeck) Date: Wed, 6 Oct 2010 21:48:16 -0500 Subject: [Numpy-discussion] unpack argument in loadtxt/genfromtxt does not work as documented Message-ID: The documentation for loadtxt and genfromtxt state that the unpack argument functions as follows: If True, the returned array is transposed, so that arguments may be unpacked using x, y, z = loadtxt(...). In practice, this does not always occur. I have a csv file of mixed data types, and try importing it via: genfromtxt("progestogens.csv", delimiter=",", names=True, dtype=dtype([('id', int),('study', '|S25'),('year', int),('treat', int),('drug', '|S25'),('form', '|S10'),('ptb', int),('mgest', int),('lab', int),('n', int),('y', int),('var', '|S5'),('wt', int),('sdwt', int)]), unpack=True) With unpack=True, I would expect the data to be presented by columns, however the resulting array is by rows: array([(1, 'Meis', 2003, 1, '17P', 'IM', 1, 0, 0, 306, 111, 'ptb'), (1, 'Meis', 2003, 0, '17P', 'IM', 1, 0, 0, 153, 84, 'ptb'), (2, 'Rai', 2009, 1, 'Progesterone', 'Oral', 1, 0, 0, 74, 29, 'ptb'), (2, 'Rai', 2009, 0, 'Progesterone', 'Oral', 1, 0, 0, 74, 44, 'ptb'), ... The same behaviour occurs using loadtxt. Moreover, this array is untransposeable, so I am stuck with having to iterate over all the rows, making genfromtxt no better than csv.reader. From hugogilsilva at gmail.com Thu Oct 7 00:19:08 2010 From: hugogilsilva at gmail.com (sicre) Date: Wed, 6 Oct 2010 21:19:08 -0700 (PDT) Subject: [Numpy-discussion] Meshgrid with Huge Arrays Message-ID: <29902859.post@talk.nabble.com> I do not have good programming skills, I am trying to create a 2048x2048 3D pixel array where each pixel has 100 cells. I am using meshgrid in order to create a 3D array, then adding a gaussian function to the entire array centered in (1024,1024). I am having three types of errors: #FIRST ERROR: File "/home/sicre/PHASES/Examples/test.py", line 18, in XArray, YArray = np.meshgrid(XArray, YArray) File "/usr/lib/python2.6/dist-packages/numpy/lib/function_base.py", line 2931, in meshgrid X = x.repeat(numRows, axis=0) ValueError: dimensions too large. #SECOND ERROR (choosing instead NrCellsPerPixel=36) Traceback (most recent call last): File "/home/sicre/PHASES/Examples/test.py", line 19, in Z = np.zeros([len(XArray),len(YArray)]) MemoryError "from pylab import * import numpy as np #VARIABLES NrHorPixels=2048 NrVerPixels=2048 NrCellsPerPixel=100 GaussianCenterX=1024 GaussianCenterY=1024 SigmaX=1 SigmaY=1 Amplitude = 150 #3D ARRAY XArray = np.arange(0, NrHorPixels, 1./sqrt(NrCellsPerPixel)) YArray = np.arange(0, NrVerPixels, 1./sqrt(NrCellsPerPixel)) XArray, YArray = np.meshgrid(XArray, YArray) Z = np.zeros([len(XArray),len(YArray)]) #Z = np.zeros((len(XArray),len(YArray)),dtype=int16) #Add Gaussian to Array Z = Z+Amplitude*e**-(((XArray-GaussianCenterX)**2/(2*SigmaX**2))+((YArray-GaussianCenterY)**/(2*SigmaY**2))) #Z = rand(len(XArray),len(YArray)) #Plot #pcolormesh(Z) #colorbar()" For sure there are better solutions for what i am trying to do. Can anyone figure it out? I would appreciate it very much, i've been searching a solution/answer for days. -- View this message in context: http://old.nabble.com/Meshgrid-with-Huge-Arrays-tp29902859p29902859.html Sent from the Numpy-discussion mailing list archive at Nabble.com. From doc at zen-pharaohs.com Thu Oct 7 01:07:30 2010 From: doc at zen-pharaohs.com (Andrew P. Mullhaupt) Date: Thu, 07 Oct 2010 01:07:30 -0400 Subject: [Numpy-discussion] Assigning complex value to real array In-Reply-To: <29902859.post@talk.nabble.com> References: <29902859.post@talk.nabble.com> Message-ID: <4CAD5592.4010409@zen-pharaohs.com> I came across this gem yesterday > >> from numpy import * > >> R = ones((2)) > >> R[0] = R[0] * 1j > >> R ...array([ 0., 1.]) > >> R = ones((2), 'complex') > >> R[0] = R[0] * 1j > >> R array([ 0.+1.j, 1.+0.j])" and I read that this behavior is actually intended for some reason about how Python wants relations between types to be such that this mistake is unavoidable. So can we have a new abstract floating type which is a complex, but is implemented so that the numbers where the imaginary part is zero represent and operate on that imaginary part implicitly? By containing all these semantics within one type, then presumably we avoid problems with ideas relationships between types. Best regards, Andrew Mullhaupt -------------- next part -------------- An HTML attachment was scrubbed... URL: From hugogilsilva at gmail.com Thu Oct 7 01:14:02 2010 From: hugogilsilva at gmail.com (sicre) Date: Wed, 6 Oct 2010 22:14:02 -0700 (PDT) Subject: [Numpy-discussion] Assigning complex value to real array In-Reply-To: <4CAD5592.4010409@zen-pharaohs.com> References: <29902859.post@talk.nabble.com> <4CAD5592.4010409@zen-pharaohs.com> Message-ID: <29903028.post@talk.nabble.com> Andrew P. Mullhaupt wrote: > > > I came across this gem yesterday > > > > >> from numpy import * > > >> R = ones((2)) > > >> R[0] = R[0] * 1j > > >> R > ...array([ 0., 1.]) > > >> R = ones((2), 'complex') > > >> R[0] = R[0] * 1j > > >> R > array([ 0.+1.j, 1.+0.j])" > > and I read that this behavior is actually intended for some reason about > how Python wants relations between types to be such that this mistake is > unavoidable. > > So can we have a new abstract floating type which is a complex, but is > implemented so that the numbers where the imaginary part is zero > represent and operate on that imaginary part implicitly? By containing > all these semantics within one type, then presumably we avoid problems > with ideas relationships between types. > > Best regards, > Andrew Mullhaupt > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > Sorry, but this post is in the wrong topic since it has nothing to do with my question. -- View this message in context: http://old.nabble.com/Meshgrid-with-Huge-Arrays-tp29902859p29903028.html Sent from the Numpy-discussion mailing list archive at Nabble.com. From doc at zen-pharaohs.com Thu Oct 7 01:19:42 2010 From: doc at zen-pharaohs.com (Andrew P. Mullhaupt) Date: Thu, 07 Oct 2010 01:19:42 -0400 Subject: [Numpy-discussion] Assigning complex value to real array In-Reply-To: <29903028.post@talk.nabble.com> References: <29902859.post@talk.nabble.com> <4CAD5592.4010409@zen-pharaohs.com> <29903028.post@talk.nabble.com> Message-ID: <4CAD586E.4070402@zen-pharaohs.com> On 10/7/2010 1:14 AM, sicre wrote: > > > Andrew P. Mullhaupt wrote: >> (assigning complex value to real array) > Sorry, but this post is in the wrong topic since it has nothing to do with > my question. How did this happen? I created a new subject. Best regards, Andrew Mullhaupt From charlesr.harris at gmail.com Thu Oct 7 01:31:20 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Wed, 6 Oct 2010 23:31:20 -0600 Subject: [Numpy-discussion] Assigning complex value to real array In-Reply-To: <4CAD5592.4010409@zen-pharaohs.com> References: <29902859.post@talk.nabble.com> <4CAD5592.4010409@zen-pharaohs.com> Message-ID: On Wed, Oct 6, 2010 at 11:07 PM, Andrew P. Mullhaupt wrote: > > I came across this gem yesterday > >>> from numpy import * > >>> R = ones((2)) > >>> R[0] = R[0] * 1j > >>> R > ...array([ 0., 1.]) > >>> R = ones((2), 'complex') > >>> R[0] = R[0] * 1j > >>> R > array([ 0.+1.j, 1.+0.j])" and I read that this behavior is actually > intended for some reason about how Python wants relations between types to > be such that this mistake is unavoidable. > > It's because an element of a real array only has space for a real and you can't fit a complex in there. Some other software which is less strict about types may allow such things, but it comes at a cost. > So can we have a new abstract floating type which is a complex, but is > implemented so that the numbers where the imaginary part is zero represent > and operate on that imaginary part implicitly? By containing all these > semantics within one type, then presumably we avoid problems with ideas > relationships between types. > > Short answer: no. If you want complex just use a complex array. Changing types like you propose would require making a new copy or reserving space ahead of time, which would be wasteful. It could also be done with lists or objects, but then you would lose speed. Newer versions of numpy will warn you that the imaginary part is going to be discarded in your first example. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From nadavh at visionsense.com Thu Oct 7 02:10:17 2010 From: nadavh at visionsense.com (Nadav Horesh) Date: Thu, 7 Oct 2010 08:10:17 +0200 Subject: [Numpy-discussion] Meshgrid with Huge Arrays References: <29902859.post@talk.nabble.com> Message-ID: You should avoid meshgrid, as the follows: ... #3D ARRAY XArray = np.arange(0, NrHorPixels, 1./sqrt(NrCellsPerPixel)) YArray = np.arange(0, NrVerPixels, 1./sqrt(NrCellsPerPixel)) Z = Amplitude*exp(-(((XArray-GaussianCenterX)**2/(2*SigmaX**2))+((YArray[:,None]-GaussianCenterY)**/(2*SigmaY**2)))) # Note this ^ # | Nadav -----Original Message----- From: numpy-discussion-bounces at scipy.org on behalf of sicre Sent: Thu 07-Oct-10 06:19 To: numpy-discussion at scipy.org Subject: [Numpy-discussion] Meshgrid with Huge Arrays I do not have good programming skills, I am trying to create a 2048x2048 3D pixel array where each pixel has 100 cells. I am using meshgrid in order to create a 3D array, then adding a gaussian function to the entire array centered in (1024,1024). I am having three types of errors: #FIRST ERROR: File "/home/sicre/PHASES/Examples/test.py", line 18, in XArray, YArray = np.meshgrid(XArray, YArray) File "/usr/lib/python2.6/dist-packages/numpy/lib/function_base.py", line 2931, in meshgrid X = x.repeat(numRows, axis=0) ValueError: dimensions too large. #SECOND ERROR (choosing instead NrCellsPerPixel=36) Traceback (most recent call last): File "/home/sicre/PHASES/Examples/test.py", line 19, in Z = np.zeros([len(XArray),len(YArray)]) MemoryError "from pylab import * import numpy as np #VARIABLES NrHorPixels=2048 NrVerPixels=2048 NrCellsPerPixel=100 GaussianCenterX=1024 GaussianCenterY=1024 SigmaX=1 SigmaY=1 Amplitude = 150 #Z = rand(len(XArray),len(YArray)) #Plot #pcolormesh(Z) #colorbar()" For sure there are better solutions for what i am trying to do. Can anyone figure it out? I would appreciate it very much, i've been searching a solution/answer for days. -- View this message in context: http://old.nabble.com/Meshgrid-with-Huge-Arrays-tp29902859p29902859.html Sent from the Numpy-discussion mailing list archive at Nabble.com. _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion at scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 3706 bytes Desc: not available URL: From seb.haase at gmail.com Thu Oct 7 03:32:33 2010 From: seb.haase at gmail.com (Sebastian Haase) Date: Thu, 7 Oct 2010 09:32:33 +0200 Subject: [Numpy-discussion] point line distance In-Reply-To: References: Message-ID: Hi, in my Priithon project I the got from this """ Minimum Distance between a Point and a Line Written by Paul Bourke, October 1988 http://astronomy.swin.edu.au/~pbourke/geometry/pointline/ """ def geoPointLineDist(p, seg, testSegmentEnds=False):: ... https://priithon.googlecode.com/hg/Priithon/usefulGeo.py HTH, Sebastian Haase On Wed, Oct 6, 2010 at 11:13 PM, Ian Mallett wrote: > Hi, > > A background in linear algebra helps.? I just came up with this method > (which, because I thought of it 5 seconds ago, I don't know if it works): > > Line p1, p2 > Point v > > costheta = normalize(p2-p1) dot normalize(v-p1) > dist = length(v-p1)*sin(acos(costheta) > > Ian > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > From ralf.gommers at googlemail.com Thu Oct 7 04:34:46 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Thu, 7 Oct 2010 16:34:46 +0800 Subject: [Numpy-discussion] Schedule for 1.5.1? In-Reply-To: References: Message-ID: On Wed, Oct 6, 2010 at 8:12 AM, Charles R Harris wrote: > > > On Tue, Oct 5, 2010 at 5:49 PM, Pauli Virtanen wrote: > >> Hi, >> >> Should we set a date for a bugfix 1.5.1 release? There are some bugs that >> would be nice to sort out in the 1.5.x series: >> >> Any Python versions: >> >> - #1605 (Cython vs. PEP-3118 issue: raising exceptions with active >> cython buffers caused undefined behavior. Breaks Sage.) >> - #1617 (Ensure complex(np.longcomplex(...)) doesn't drop the imag part) >> - Fix doc build >> >> Python 3 specific: >> >> - #1604 (//-issue in distutils; infinite loop in some cases :) >> - #1609 (dotblas was never used on Python 3) >> - #1610 (fromfile/tofile did not stay in sync with Python 3 file handle >> position -- breaks e.g. scipy.io pretty badly) >> - f2py startup script didn't run properly on Py3 >> >> Not so many fixes so far, but I'd like to see a Numpy release with #1610 >> fixed before releasing Scipy with Python 3 support. Since 2.0.0 breaks >> binary compatibility and merging the refactoring back may take some time, >> it would be nice to have another 1.5.x release. >> >> Ralf & c, opinions? I'd maybe suggest somewhere on the Oct/Nov axis. >> >> > A 1.5.1 release soon would be good. All the issues above are already committed, is there anything else that needs to go in? If not, I think an RC by the end of next week (10/17) and release by the end of the month should be possible. The one bug that I want to have fixed is #1399, which causes build problems for scipy on OS X. Sounds good. I also have some stuff I'd like to add but won't have much time > before Nov. But whatever looks good to Ralf will work for me. > Any specific issues you have in mind? Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Thu Oct 7 05:06:55 2010 From: pav at iki.fi (Pauli Virtanen) Date: Thu, 7 Oct 2010 09:06:55 +0000 (UTC) Subject: [Numpy-discussion] Schedule for 1.5.1? References: Message-ID: Thu, 07 Oct 2010 16:34:46 +0800, Ralf Gommers wrote: [clip] > A 1.5.1 release soon would be good. All the issues above are already > committed, is there anything else that needs to go in? If not, I think > an RC by the end of next week (10/17) and release by the end of the > month should be possible. Sounds good to me. I don't remember any other "critical" bugs being present, but I can go through the tickets during next WE in case there are some low-hanging fruits. Pauli From pgmdevlist at gmail.com Thu Oct 7 05:00:27 2010 From: pgmdevlist at gmail.com (Pierre GM) Date: Thu, 7 Oct 2010 11:00:27 +0200 Subject: [Numpy-discussion] unpack argument in loadtxt/genfromtxt does not work as documented In-Reply-To: References: Message-ID: <9A775764-8863-4602-A5F6-AEDD3B5EB22B@gmail.com> On Oct 7, 2010, at 4:48 AM, Chris Fonnesbeck wrote: > The documentation for loadtxt and genfromtxt state that the unpack > argument functions as follows: > > If True, the returned array is transposed, so that arguments may be > unpacked using x, y, z = loadtxt(...). Provided that all the columns have the same dtype > > In practice, this does not always occur. I have a csv file of mixed > data types, and try importing it via: > > genfromtxt("progestogens.csv", delimiter=",", names=True, > dtype=dtype([('id', int),('study', '|S25'),('year', int),('treat', > int),('drug', '|S25'),('form', '|S10'),('ptb', int),('mgest', > int),('lab', int),('n', int),('y', int),('var', '|S5'),('wt', > int),('sdwt', int)]), unpack=True) > > With unpack=True, I would expect the data to be presented by columns, > however the resulting array is by rows: Well, you have a complex dtype, so your result array is 1D, each row corresponding to a tuple of elements with different dtypes. > > > array([(1, 'Meis', 2003, 1, '17P', 'IM', 1, 0, 0, 306, 111, 'ptb'), > (1, 'Meis', 2003, 0, '17P', 'IM', 1, 0, 0, 153, 84, 'ptb'), > (2, 'Rai', 2009, 1, 'Progesterone', 'Oral', 1, 0, 0, 74, 29, 'ptb'), > (2, 'Rai', 2009, 0, 'Progesterone', 'Oral', 1, 0, 0, 74, 44, 'ptb'), > ... > > The same behaviour occurs using loadtxt. Moreover, this array is > untransposeable, so I am stuck with having to iterate over all the > rows, making genfromtxt no better than csv.reader. Once again, your array is 1D, so you can't tranpose it. Now, you should be able to get each column through >>> [a[_] for _ in a.dtype.names] From ralf.gommers at googlemail.com Thu Oct 7 05:35:44 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Thu, 7 Oct 2010 17:35:44 +0800 Subject: [Numpy-discussion] test failure In-Reply-To: References: Message-ID: On Sat, Oct 2, 2010 at 12:51 PM, John Mitchell wrote: > After spending a lot of time building 'numpy' (1.5.0) and 'scipy' (0.8.0) > I ran the following tests -- per what I read somewhere: > numpy.test() > > Out of several thousand small tests I found this one error -- perhaps its > not really an error? > > This doesn't look serious but it can be bothersome when one is trying to > be sure that the installation is as good as possible. > It's not a real problem, it only has to do with your printing precision. Is it possible you set it to 4 in your interpreter before running the tests, perhaps by running some other file? I can reproduce the exact errors with: >>> np.set_printoptions(precision=4) >>> np.test() You can check the precision with np.get_printoptions(), it should be 8 by default. Ralf > > Not sure if it matters, but my compiler is gcc-4.4.1 and I'm using > gfortran. Both were wrapped with mpich2. > > Regards, > John > > > FAIL: test_doctests (test_polynomial.TestDocs) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/usr/local/python2.6.6/lib/python2.6/site-packages/numpy/lib/tests/test_polynomial.py", > line 90, in test_doctests > return rundocs() > File > "/usr/local/python2.6.6/lib/python2.6/site-packages/numpy/testing/utils.py", > line 962, in rundocs > raise AssertionError("Some doctests failed:\n%s" % "\n".join(msg)) > AssertionError: Some doctests failed: > ********************************************************************** > File > "/usr/local/python2.6.6/lib/python2.6/site-packages/numpy/lib/tests/test_polynomial.py", > line 38, in test_polynomial > Failed example: > p / q > Expected: > (poly1d([ 0.33333333]), poly1d([ 1.33333333, 2.66666667])) > Got: > (poly1d([ 0.333]), poly1d([ 1.333, 2.667])) > > ********************************************************************** > File > "/usr/local/python2.6.6/lib/python2.6/site-packages/numpy/lib/tests/test_polynomial.py", > line 60, in test_polynomial > Failed example: > p.integ() > Expected: > poly1d([ 0.33333333, 1. , 3. , 0. ]) > Got: > poly1d([ 0.333, 1. , 3. , 0. ]) > > ********************************************************************** > File > "/usr/local/python2.6.6/lib/python2.6/site-packages/numpy/lib/tests/test_polynomial.py", > line 62, in test_polynomial > Failed example: > p.integ(1) > Expected: > poly1d([ 0.33333333, 1. , 3. , 0. ]) > Got: > poly1d([ 0.333, 1. , 3. , 0. ]) > > ********************************************************************** > File > "/usr/local/python2.6.6/lib/python2.6/site-packages/numpy/lib/tests/test_polynomial.py", > line 64, in test_polynomial > Failed example: > p.integ(5) > Expected: > poly1d([ 0.00039683, 0.00277778, 0.025 , 0. , 0. > , > 0. , 0. , 0. ]) > Got: > poly1d([ 0. , 0.003, 0.025, 0. , 0. , 0. , 0. , 0. > ]) > > >> raise AssertionError("Some doctests failed:\n%s" % > "\n".join(['**********************************************************************\nFile > "/usr/local/python2.6.6/lib/python2.6/site-packages/numpy/lib/tests/test_polynomial.py", > line 38, in test_polynomial\nFailed example:\n p / q\nExpected:\n > (poly1d([ 0.33333333]), poly1d([ 1.33333333, 2.66666667]))\nGot:\n > (poly1d([ 0.333]), poly1d([ 1.333, 2.667]))\n', > '**********************************************************************\nFile > "/usr/local/python2.6.6/lib/python2.6/site-packages/numpy/lib/tests/test_polynomial.py", > line 60, in test_polynomial\nFailed example:\n p.integ()\nExpected:\n > poly1d([ 0.33333333, 1. , 3. , 0. ])\nGot:\n > poly1d([ 0.333, 1. , 3. , 0. ])\n', > '**********************************************************************\nFile > "/usr/local/python2.6.6/lib/python2.6/site-packages/numpy/lib/tests/test_polynomial.py", > line 62, in test_polynomial\nFailed example:\n p.integ(1)\nExpected:\n > poly1d([ 0.33333333, 1. , 3. , 0. ])\nGot:\n > poly1d([ 0.333, 1. , 3. , 0. ])\n', > '**********************************************************************\nFile > "/usr/local/python2.6.6/lib/python2.6/site-packages/numpy/lib/tests/test_polynomial.py", > line 64, in test_polynomial\nFailed example:\n p.integ(5)\nExpected:\n > poly1d([ 0.00039683, 0.00277778, 0.025 , 0. , 0. > ,\n 0. , 0. , 0. ])\nGot:\n poly1d([ > 0. , 0.003, 0.025, 0. , 0. , 0. , 0. , 0. ])\n'])) > > > ---------------------------------------------------------------------- > Ran 2966 tests in 9.896s > > FAILED (KNOWNFAIL=4, failures=1) > > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hugogilsilva at gmail.com Thu Oct 7 06:21:55 2010 From: hugogilsilva at gmail.com (sicre) Date: Thu, 7 Oct 2010 03:21:55 -0700 (PDT) Subject: [Numpy-discussion] Meshgrid with Huge Arrays In-Reply-To: References: <29902859.post@talk.nabble.com> Message-ID: <29904941.post@talk.nabble.com> I used your suggestion, but it keeps getting me those errors mentioned, but on the definition of Z (line of the following code): from pylab import * import numpy as np #VARIABLES NrHorPixels=512 NrVerPixels=512 NrCellsPerPixel=16 GaussianCenterX=256 GaussianCenterY=256 SigmaX=1 SigmaY=1 Amplitude = 150 #3D ARRAY XArray = np.arange(0, NrHorPixels, 1./sqrt(NrCellsPerPixel)) YArray = np.arange(0, NrVerPixels, 1./sqrt(NrCellsPerPixel)) Z = Amplitude*exp(-(((XArray-GaussianCenterX)**2/(2*SigmaX**2))+((YArray[:,None]-GaussianCenterY)**2/(2*SigmaY**2)))) #PLOT #pcolormesh(Z) #colorbar() -- View this message in context: http://old.nabble.com/Meshgrid-with-Huge-Arrays-tp29902859p29904941.html Sent from the Numpy-discussion mailing list archive at Nabble.com. From ralf.gommers at googlemail.com Thu Oct 7 06:25:22 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Thu, 7 Oct 2010 18:25:22 +0800 Subject: [Numpy-discussion] numpy mac binary for Python 2.7: which version is it for? In-Reply-To: References: Message-ID: On Wed, Oct 6, 2010 at 12:32 AM, Russell E. Owen wrote: > There are two Python 2.7 installers available at python.org a 32 bit > version for MacOS X 10.3.9 and later and a 64 bit version for Mac OS X > 10.5 and later. > > There is one numpy 1.5.0 binary installer for Mac Python 2.7. Which Mac > python was it built for? (Or if it is compatible with both, how did you > manage that?). > > It was built with the 10.5 binary from python.org, but works (at least for me) with the 10.3 binary as well. I didn't do anything special for that, and as far as I understand it should just work out of the box. The only difference is that the 10.3 python binary does not support the x86_64 architecture, but since the numpy binary also supports 32-bit intel and ppc arches those can be used by python. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From nadavh at visionsense.com Thu Oct 7 06:55:12 2010 From: nadavh at visionsense.com (Nadav Horesh) Date: Thu, 7 Oct 2010 12:55:12 +0200 Subject: [Numpy-discussion] Meshgrid with Huge Arrays References: <29902859.post@talk.nabble.com> <29904941.post@talk.nabble.com> Message-ID: The easiest next step is to use flot32 instead of float64 to reduce memory consumption by half: XArray = np.arange(0, NrHorPixels, 1./sqrt(NrCellsPerPixel), dtype=float32)) YArray = np.arange(0, NrVerPixels, 1./sqrt(NrCellsPerPixel), dtype=float32)) If this not enough you can try to ue the separability of the gaussian (it should also run faster) Zx = Amplitude*exp(-(((XArray-GaussianCenterX)**2/(2*SigmaX**2))) Zy = exp(-((YArray-GaussianCenterY)**2/(2*SigmaY**2)))) Z = Zx * Zy[:,None] Nadav -----Original Message----- From: numpy-discussion-bounces at scipy.org on behalf of sicre Sent: Thu 07-Oct-10 12:21 To: numpy-discussion at scipy.org Subject: Re: [Numpy-discussion] Meshgrid with Huge Arrays I used your suggestion, but it keeps getting me those errors mentioned, but on the definition of Z (line of the following code): from pylab import * import numpy as np #VARIABLES NrHorPixels=512 NrVerPixels=512 NrCellsPerPixel=16 GaussianCenterX=256 GaussianCenterY=256 SigmaX=1 SigmaY=1 Amplitude = 150 #3D ARRAY XArray = np.arange(0, NrHorPixels, 1./sqrt(NrCellsPerPixel)) YArray = np.arange(0, NrVerPixels, 1./sqrt(NrCellsPerPixel)) Z = Amplitude*exp(-(((XArray-GaussianCenterX)**2/(2*SigmaX**2))+((YArray[:,None]-GaussianCenterY)**2/(2*SigmaY**2)))) #PLOT #pcolormesh(Z) #colorbar() -- View this message in context: http://old.nabble.com/Meshgrid-with-Huge-Arrays-tp29902859p29904941.html Sent from the Numpy-discussion mailing list archive at Nabble.com. _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion at scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 3365 bytes Desc: not available URL: From numpy-discussion at maubp.freeserve.co.uk Thu Oct 7 08:10:05 2010 From: numpy-discussion at maubp.freeserve.co.uk (Peter) Date: Thu, 7 Oct 2010 13:10:05 +0100 Subject: [Numpy-discussion] DEV_README.txt update, SVN -> git Message-ID: Just FYI: The DEV_README.txt file needs a trivial update to talk about git not SVN http://github.com/numpy/numpy/blob/master/DEV_README.txt Regards, Peter From charlesr.harris at gmail.com Thu Oct 7 09:09:37 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Thu, 7 Oct 2010 07:09:37 -0600 Subject: [Numpy-discussion] Schedule for 1.5.1? In-Reply-To: References: Message-ID: On Thu, Oct 7, 2010 at 2:34 AM, Ralf Gommers wrote: > > > On Wed, Oct 6, 2010 at 8:12 AM, Charles R Harris < > charlesr.harris at gmail.com> wrote: > >> >> >> On Tue, Oct 5, 2010 at 5:49 PM, Pauli Virtanen wrote: >> >>> Hi, >>> >>> Should we set a date for a bugfix 1.5.1 release? There are some bugs that >>> would be nice to sort out in the 1.5.x series: >>> >>> Any Python versions: >>> >>> - #1605 (Cython vs. PEP-3118 issue: raising exceptions with active >>> cython buffers caused undefined behavior. Breaks Sage.) >>> - #1617 (Ensure complex(np.longcomplex(...)) doesn't drop the imag part) >>> - Fix doc build >>> >>> Python 3 specific: >>> >>> - #1604 (//-issue in distutils; infinite loop in some cases :) >>> - #1609 (dotblas was never used on Python 3) >>> - #1610 (fromfile/tofile did not stay in sync with Python 3 file handle >>> position -- breaks e.g. scipy.io pretty badly) >>> - f2py startup script didn't run properly on Py3 >>> >>> Not so many fixes so far, but I'd like to see a Numpy release with #1610 >>> fixed before releasing Scipy with Python 3 support. Since 2.0.0 breaks >>> binary compatibility and merging the refactoring back may take some time, >>> it would be nice to have another 1.5.x release. >>> >>> Ralf & c, opinions? I'd maybe suggest somewhere on the Oct/Nov axis. >>> >>> >> A 1.5.1 release soon would be good. All the issues above are already > committed, is there anything else that needs to go in? If not, I think an RC > by the end of next week (10/17) and release by the end of the month should > be possible. > > The one bug that I want to have fixed is #1399, which causes build problems > for scipy on OS X. > > Sounds good. I also have some stuff I'd like to add but won't have much >> time before Nov. But whatever looks good to Ralf will work for me. >> > > Any specific issues you have in mind? > > No, I just wanted to include the Laguerre and Hermite polynomials and add a domain keyword to the linspace method of the polynomial template. But I don't think these are pressing needs. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Thu Oct 7 09:35:51 2010 From: pav at iki.fi (Pauli Virtanen) Date: Thu, 7 Oct 2010 13:35:51 +0000 (UTC) Subject: [Numpy-discussion] Schedule for 1.5.1? References: Message-ID: Thu, 07 Oct 2010 07:09:37 -0600, Charles R Harris wrote: [clip] > No, I just wanted to include the Laguerre and Hermite polynomials and > add a domain keyword to the linspace method of the polynomial template. > But I don't think these are pressing needs. It's a minor release, so I think we need to restrain ourselves to bugfixes only. Pauli From ralf.gommers at googlemail.com Thu Oct 7 09:45:39 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Thu, 7 Oct 2010 21:45:39 +0800 Subject: [Numpy-discussion] Schedule for 1.5.1? In-Reply-To: References: Message-ID: On Thu, Oct 7, 2010 at 9:09 PM, Charles R Harris wrote: > > > On Thu, Oct 7, 2010 at 2:34 AM, Ralf Gommers wrote: > >> >> >> On Wed, Oct 6, 2010 at 8:12 AM, Charles R Harris < >> charlesr.harris at gmail.com> wrote: >> >>> >>> >>> On Tue, Oct 5, 2010 at 5:49 PM, Pauli Virtanen wrote: >>> >>>> Hi, >>>> >>>> Should we set a date for a bugfix 1.5.1 release? There are some bugs >>>> that >>>> would be nice to sort out in the 1.5.x series: >>>> >>>> Any Python versions: >>>> >>>> - #1605 (Cython vs. PEP-3118 issue: raising exceptions with active >>>> cython buffers caused undefined behavior. Breaks Sage.) >>>> - #1617 (Ensure complex(np.longcomplex(...)) doesn't drop the imag part) >>>> - Fix doc build >>>> >>>> Python 3 specific: >>>> >>>> - #1604 (//-issue in distutils; infinite loop in some cases :) >>>> - #1609 (dotblas was never used on Python 3) >>>> - #1610 (fromfile/tofile did not stay in sync with Python 3 file handle >>>> position -- breaks e.g. scipy.io pretty badly) >>>> - f2py startup script didn't run properly on Py3 >>>> >>>> Not so many fixes so far, but I'd like to see a Numpy release with #1610 >>>> fixed before releasing Scipy with Python 3 support. Since 2.0.0 breaks >>>> binary compatibility and merging the refactoring back may take some >>>> time, >>>> it would be nice to have another 1.5.x release. >>>> >>>> Ralf & c, opinions? I'd maybe suggest somewhere on the Oct/Nov axis. >>>> >>>> >>> A 1.5.1 release soon would be good. All the issues above are already >> committed, is there anything else that needs to go in? If not, I think an RC >> by the end of next week (10/17) and release by the end of the month should >> be possible. >> >> The one bug that I want to have fixed is #1399, which causes build >> problems for scipy on OS X. >> >> Sounds good. I also have some stuff I'd like to add but won't have much >>> time before Nov. But whatever looks good to Ralf will work for me. >>> >> >> Any specific issues you have in mind? >> >> > No, I just wanted to include the Laguerre and Hermite polynomials and add a > domain keyword to the linspace method of the polynomial template. But I > don't think these are pressing needs. > > These don't seem very appropriate for a bugfix release anyway. I trust your code will be in very good shape when you add it, but let's not start breaking our own rules for what can and cannot go in. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.root at ou.edu Thu Oct 7 09:49:03 2010 From: ben.root at ou.edu (Benjamin Root) Date: Thu, 7 Oct 2010 08:49:03 -0500 Subject: [Numpy-discussion] unpack argument in loadtxt/genfromtxt does not work as documented In-Reply-To: <9A775764-8863-4602-A5F6-AEDD3B5EB22B@gmail.com> References: <9A775764-8863-4602-A5F6-AEDD3B5EB22B@gmail.com> Message-ID: On Thu, Oct 7, 2010 at 4:00 AM, Pierre GM wrote: > > On Oct 7, 2010, at 4:48 AM, Chris Fonnesbeck wrote: > > > The documentation for loadtxt and genfromtxt state that the unpack > > argument functions as follows: > > > > If True, the returned array is transposed, so that arguments may be > > unpacked using x, y, z = loadtxt(...). > > Provided that all the columns have the same dtype > > > > > In practice, this does not always occur. I have a csv file of mixed > > data types, and try importing it via: > > > > genfromtxt("progestogens.csv", delimiter=",", names=True, > > dtype=dtype([('id', int),('study', '|S25'),('year', int),('treat', > > int),('drug', '|S25'),('form', '|S10'),('ptb', int),('mgest', > > int),('lab', int),('n', int),('y', int),('var', '|S5'),('wt', > > int),('sdwt', int)]), unpack=True) > > > > With unpack=True, I would expect the data to be presented by columns, > > however the resulting array is by rows: > > Well, you have a complex dtype, so your result array is 1D, each row > corresponding to a tuple of elements with different dtypes. > > > > > > > > array([(1, 'Meis', 2003, 1, '17P', 'IM', 1, 0, 0, 306, 111, 'ptb'), > > (1, 'Meis', 2003, 0, '17P', 'IM', 1, 0, 0, 153, 84, 'ptb'), > > (2, 'Rai', 2009, 1, 'Progesterone', 'Oral', 1, 0, 0, 74, 29, > 'ptb'), > > (2, 'Rai', 2009, 0, 'Progesterone', 'Oral', 1, 0, 0, 74, 44, > 'ptb'), > > ... > > > > The same behaviour occurs using loadtxt. Moreover, this array is > > untransposeable, so I am stuck with having to iterate over all the > > rows, making genfromtxt no better than csv.reader. > > Once again, your array is 1D, so you can't tranpose it. > Now, you should be able to get each column through > >>> [a[_] for _ in a.dtype.names] > I understand the technicalities of why this occurs, but from a user's perspective, he is asking for distinct numpy arrays of specified types. The transposing seems to be almost an unimportant implementation detail because the user is asking for the data to be split up by columns. Personally, I think that this should be transparent to the user and should be able to work -- although I am not exactly sure if one should just simply return a list of numpy arrays with the column names dropped, or a list of one-column record arrays. If it can't quite work from within the framework for genfromtxt/loadtxt, then maybe another text loading function that is designed to have the data format known a priori would be suitable? Note that such a function might also be sufficient in addressing my long-standing qualm with loadtxt()'s squeeze behavior for files with only one line of data. Ben Root -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsouthey at gmail.com Thu Oct 7 09:54:15 2010 From: bsouthey at gmail.com (Bruce Southey) Date: Thu, 07 Oct 2010 08:54:15 -0500 Subject: [Numpy-discussion] Schedule for 1.5.1? In-Reply-To: References: Message-ID: <4CADD107.10001@gmail.com> On 10/07/2010 08:45 AM, Ralf Gommers wrote: > > > On Thu, Oct 7, 2010 at 9:09 PM, Charles R Harris > > wrote: > > > > On Thu, Oct 7, 2010 at 2:34 AM, Ralf Gommers > > > wrote: > > > > On Wed, Oct 6, 2010 at 8:12 AM, Charles R Harris > > > wrote: > > > > On Tue, Oct 5, 2010 at 5:49 PM, Pauli Virtanen > wrote: > > Hi, > > Should we set a date for a bugfix 1.5.1 release? There > are some bugs that > would be nice to sort out in the 1.5.x series: > > Any Python versions: > > - #1605 (Cython vs. PEP-3118 issue: raising exceptions > with active > cython buffers caused undefined behavior. > Breaks Sage.) > - #1617 (Ensure complex(np.longcomplex(...)) doesn't > drop the imag part) > - Fix doc build > > Python 3 specific: > > - #1604 (//-issue in distutils; infinite loop in some > cases :) > - #1609 (dotblas was never used on Python 3) > - #1610 (fromfile/tofile did not stay in sync with > Python 3 file handle > position -- breaks e.g. scipy.io > pretty badly) > - f2py startup script didn't run properly on Py3 > > Not so many fixes so far, but I'd like to see a Numpy > release with #1610 > fixed before releasing Scipy with Python 3 support. > Since 2.0.0 breaks > binary compatibility and merging the refactoring back > may take some time, > it would be nice to have another 1.5.x release. > > Ralf & c, opinions? I'd maybe suggest somewhere on the > Oct/Nov axis. > > > A 1.5.1 release soon would be good. All the issues above are > already committed, is there anything else that needs to go in? > If not, I think an RC by the end of next week (10/17) and > release by the end of the month should be possible. > > The one bug that I want to have fixed is #1399, which causes > build problems for scipy on OS X. > > Sounds good. I also have some stuff I'd like to add but > won't have much time before Nov. But whatever looks good > to Ralf will work for me. > > > Any specific issues you have in mind? > > > No, I just wanted to include the Laguerre and Hermite polynomials > and add a domain keyword to the linspace method of the polynomial > template. But I don't think these are pressing needs. > > These don't seem very appropriate for a bugfix release anyway. I trust > your code will be in very good shape when you add it, but let's not > start breaking our own rules for what can and cannot go in. > > Ralf > > I agree that this is a good idea to have this minor release with as few changes as possible. This allows us to clearly state everything has moved to git and localize any problems that users should not have related to the switch. That way the change to git should reach people who don't follow the list. Note that the Download page, http://www.scipy.org/Download, for numpy under the 'Bleeding-edge repository access' still indicates the svn yet the developer zone page says git. Bruce -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Thu Oct 7 09:58:38 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Thu, 7 Oct 2010 07:58:38 -0600 Subject: [Numpy-discussion] Schedule for 1.5.1? In-Reply-To: References: Message-ID: On Thu, Oct 7, 2010 at 7:45 AM, Ralf Gommers wrote: > > > On Thu, Oct 7, 2010 at 9:09 PM, Charles R Harris < > charlesr.harris at gmail.com> wrote: > >> >> >> On Thu, Oct 7, 2010 at 2:34 AM, Ralf Gommers > > wrote: >> >>> >>> >>> On Wed, Oct 6, 2010 at 8:12 AM, Charles R Harris < >>> charlesr.harris at gmail.com> wrote: >>> >>>> >>>> >>>> On Tue, Oct 5, 2010 at 5:49 PM, Pauli Virtanen wrote: >>>> >>>>> Hi, >>>>> >>>>> Should we set a date for a bugfix 1.5.1 release? There are some bugs >>>>> that >>>>> would be nice to sort out in the 1.5.x series: >>>>> >>>>> Any Python versions: >>>>> >>>>> - #1605 (Cython vs. PEP-3118 issue: raising exceptions with active >>>>> cython buffers caused undefined behavior. Breaks Sage.) >>>>> - #1617 (Ensure complex(np.longcomplex(...)) doesn't drop the imag >>>>> part) >>>>> - Fix doc build >>>>> >>>>> Python 3 specific: >>>>> >>>>> - #1604 (//-issue in distutils; infinite loop in some cases :) >>>>> - #1609 (dotblas was never used on Python 3) >>>>> - #1610 (fromfile/tofile did not stay in sync with Python 3 file handle >>>>> position -- breaks e.g. scipy.io pretty badly) >>>>> - f2py startup script didn't run properly on Py3 >>>>> >>>>> Not so many fixes so far, but I'd like to see a Numpy release with >>>>> #1610 >>>>> fixed before releasing Scipy with Python 3 support. Since 2.0.0 breaks >>>>> binary compatibility and merging the refactoring back may take some >>>>> time, >>>>> it would be nice to have another 1.5.x release. >>>>> >>>>> Ralf & c, opinions? I'd maybe suggest somewhere on the Oct/Nov axis. >>>>> >>>>> >>>> A 1.5.1 release soon would be good. All the issues above are already >>> committed, is there anything else that needs to go in? If not, I think an RC >>> by the end of next week (10/17) and release by the end of the month should >>> be possible. >>> >>> The one bug that I want to have fixed is #1399, which causes build >>> problems for scipy on OS X. >>> >>> Sounds good. I also have some stuff I'd like to add but won't have much >>>> time before Nov. But whatever looks good to Ralf will work for me. >>>> >>> >>> Any specific issues you have in mind? >>> >>> >> No, I just wanted to include the Laguerre and Hermite polynomials and add >> a domain keyword to the linspace method of the polynomial template. But I >> don't think these are pressing needs. >> >> These don't seem very appropriate for a bugfix release anyway. I trust > your code will be in very good shape when you add it, but let's not start > breaking our own rules for what can and cannot go in. > > Works for me. But looking at what versions some distros are including I suspect 1.5.x will be "mainline" for quite a while. Fedora might go to 1.5 (from 1.3), but only because they are moving to Python 2.7. So I don't look at the 1.5.x versions as strictly bug fix releases. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From pgmdevlist at gmail.com Thu Oct 7 09:59:23 2010 From: pgmdevlist at gmail.com (Pierre GM) Date: Thu, 7 Oct 2010 15:59:23 +0200 Subject: [Numpy-discussion] unpack argument in loadtxt/genfromtxt does not work as documented In-Reply-To: References: <9A775764-8863-4602-A5F6-AEDD3B5EB22B@gmail.com> Message-ID: <73861FB4-6540-4A9F-9D07-2AD82FA983F8@gmail.com> On Oct 7, 2010, at 3:49 PM, Benjamin Root wrote: > > I understand the technicalities of why this occurs, but from a user's perspective, he is asking for distinct numpy arrays of specified types. The transposing seems to be almost an unimportant implementation detail because the user is asking for the data to be split up by columns. Personally, I think that this should be transparent to the user and should be able to work -- although I am not exactly sure if one should just simply return a list of numpy arrays with the column names dropped, or a list of one-column record arrays. Well, easy enough to output a list of arrays for each column, be they of the same dtype or with different ones. > If it can't quite work from within the framework for genfromtxt/loadtxt, then maybe another text loading function that is designed to have the data format known a priori would be suitable? Not needed. The unpack argument is used as the very end of the function anyway. Anyhow, could you open a ticket to that effect (else I'm quite likely to forget about it). > Note that such a function might also be sufficient in addressing my long-standing qualm with loadtxt()'s squeeze behavior for files with only one line of data. Mind opening a second a ticket ? From pgmdevlist at gmail.com Thu Oct 7 10:00:54 2010 From: pgmdevlist at gmail.com (Pierre GM) Date: Thu, 7 Oct 2010 16:00:54 +0200 Subject: [Numpy-discussion] Schedule for 1.5.1? In-Reply-To: <4CADD107.10001@gmail.com> References: <4CADD107.10001@gmail.com> Message-ID: Just asking, Should I backport some bugs that were corrected in 2.0 for numpy.ma ? I don't have any particular in mind, but I'm sure there must be some... From fonnesbeck at gmail.com Thu Oct 7 10:01:44 2010 From: fonnesbeck at gmail.com (Chris Fonnesbeck) Date: Thu, 7 Oct 2010 09:01:44 -0500 Subject: [Numpy-discussion] unpack argument in loadtxt/genfromtxt does not work as documented In-Reply-To: <9A775764-8863-4602-A5F6-AEDD3B5EB22B@gmail.com> References: <9A775764-8863-4602-A5F6-AEDD3B5EB22B@gmail.com> Message-ID: On Thu, Oct 7, 2010 at 4:00 AM, Pierre GM wrote: > > On Oct 7, 2010, at 4:48 AM, Chris Fonnesbeck wrote: > >> The documentation for loadtxt and genfromtxt state that the unpack >> argument functions as follows: >> >> If True, the returned array is transposed, so that arguments may be >> unpacked using x, y, z = loadtxt(...). > > Provided that all the columns have the same dtype > Aha, I see. Unfortunately that detail is not in the docstrings. This is a pretty fundamental limitation of the function, I think, since it is rare that a multi-column table of data will be of the same type. I wonder if it would be possible to allow an 'obj' type array that could be transposed? The way it is now, you have a 1d array representing what is fundamentally 2d information. From fonnesbeck at gmail.com Thu Oct 7 10:03:28 2010 From: fonnesbeck at gmail.com (Chris Fonnesbeck) Date: Thu, 7 Oct 2010 09:03:28 -0500 Subject: [Numpy-discussion] unpack argument in loadtxt/genfromtxt does not work as documented In-Reply-To: <73861FB4-6540-4A9F-9D07-2AD82FA983F8@gmail.com> References: <9A775764-8863-4602-A5F6-AEDD3B5EB22B@gmail.com> <73861FB4-6540-4A9F-9D07-2AD82FA983F8@gmail.com> Message-ID: On Thu, Oct 7, 2010 at 8:59 AM, Pierre GM wrote: > > Not needed. The unpack argument is used as the very end of the function anyway. > Anyhow, could you open a ticket to that effect (else I'm quite likely to forget about it). > I can open this one. From pgmdevlist at gmail.com Thu Oct 7 10:04:47 2010 From: pgmdevlist at gmail.com (Pierre GM) Date: Thu, 7 Oct 2010 16:04:47 +0200 Subject: [Numpy-discussion] unpack argument in loadtxt/genfromtxt does not work as documented In-Reply-To: References: <9A775764-8863-4602-A5F6-AEDD3B5EB22B@gmail.com> Message-ID: <5F1412B1-CC89-4020-AFC9-1DC0648262F2@gmail.com> On Oct 7, 2010, at 4:01 PM, Chris Fonnesbeck wrote: > On Thu, Oct 7, 2010 at 4:00 AM, Pierre GM wrote: >> >> On Oct 7, 2010, at 4:48 AM, Chris Fonnesbeck wrote: >> >>> The documentation for loadtxt and genfromtxt state that the unpack >>> argument functions as follows: >>> >>> If True, the returned array is transposed, so that arguments may be >>> unpacked using x, y, z = loadtxt(...). >> >> Provided that all the columns have the same dtype >> > > Aha, I see. Unfortunately that detail is not in the docstrings. This > is a pretty fundamental limitation of the function, I think, since it > is rare that a multi-column table of data will be of the same type. I > wonder if it would be possible to allow an 'obj' type array that could > be transposed? The way it is now, you have a 1d array representing > what is fundamentally 2d information. As I stated in a previous email, please open a ticket to that effect. In the meantime, please use the trick I was giving you to unpack the 1D array w/ several fields into a list of 1D arrays (one for each field). From ben.root at ou.edu Thu Oct 7 10:09:10 2010 From: ben.root at ou.edu (Benjamin Root) Date: Thu, 7 Oct 2010 09:09:10 -0500 Subject: [Numpy-discussion] unpack argument in loadtxt/genfromtxt does not work as documented In-Reply-To: <73861FB4-6540-4A9F-9D07-2AD82FA983F8@gmail.com> References: <9A775764-8863-4602-A5F6-AEDD3B5EB22B@gmail.com> <73861FB4-6540-4A9F-9D07-2AD82FA983F8@gmail.com> Message-ID: On Thu, Oct 7, 2010 at 8:59 AM, Pierre GM wrote: > > On Oct 7, 2010, at 3:49 PM, Benjamin Root wrote: > > > > I understand the technicalities of why this occurs, but from a user's > perspective, he is asking for distinct numpy arrays of specified types. The > transposing seems to be almost an unimportant implementation detail because > the user is asking for the data to be split up by columns. Personally, I > think that this should be transparent to the user and should be able to work > -- although I am not exactly sure if one should just simply return a list of > numpy arrays with the column names dropped, or a list of one-column record > arrays. > > Well, easy enough to output a list of arrays for each column, be they of > the same dtype or with different ones. > > > > If it can't quite work from within the framework for genfromtxt/loadtxt, > then maybe another text loading function that is designed to have the data > format known a priori would be suitable? > > Not needed. The unpack argument is used as the very end of the function > anyway. > Anyhow, could you open a ticket to that effect (else I'm quite likely to > forget about it). > > > Note that such a function might also be sufficient in addressing my > long-standing qualm with loadtxt()'s squeeze behavior for files with only > one line of data. > > Mind opening a second a ticket ? > > Already been open for a little while now: http://projects.scipy.org/numpy/ticket/1562 Ben Root -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Thu Oct 7 10:16:54 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Thu, 7 Oct 2010 22:16:54 +0800 Subject: [Numpy-discussion] Schedule for 1.5.1? In-Reply-To: References: <4CADD107.10001@gmail.com> Message-ID: On Thu, Oct 7, 2010 at 10:00 PM, Pierre GM wrote: > Just asking, > Should I backport some bugs that were corrected in 2.0 for numpy.ma ? I > don't have any particular in mind, but I'm sure there must be some... > > That would be helpful. Please backport any bug fixes that you think are important. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Thu Oct 7 10:39:36 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Thu, 7 Oct 2010 22:39:36 +0800 Subject: [Numpy-discussion] Schedule for 1.5.1? In-Reply-To: <4CADD107.10001@gmail.com> References: <4CADD107.10001@gmail.com> Message-ID: On Thu, Oct 7, 2010 at 9:54 PM, Bruce Southey wrote: > > I agree that this is a good idea to have this minor release with as few > changes as possible. This allows us to clearly state everything has moved to > git and localize any problems that users should not have related to the > switch. That way the change to git should reach people who don't follow the > list. > Not sure if the git move should influence what goes into a release, but good point that it can be mentioned in release notes/announcement. > > Note that the Download page, http://www.scipy.org/Download, for numpy > under the 'Bleeding-edge repository access' still indicates the svn yet the > developer zone page says git. > Fixed now. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ioan.ferencik at tkk.fi Thu Oct 7 11:09:19 2010 From: ioan.ferencik at tkk.fi (Ioan Ferencik) Date: Thu, 7 Oct 2010 18:09:19 +0300 Subject: [Numpy-discussion] ndarray of object dtype In-Reply-To: <15612_1286204190_ZZ0L9R0038DTI5HY.00_AANLkTinopyssMBw-wHgsdmgVXGijBS-TVGm8=YQLcOzp@mail.gmail.com> References: <20101004084120.7bmxuk1dcsc0coko@webmail3.tkk.fi> <15612_1286204190_ZZ0L9R0038DTI5HY.00_AANLkTinopyssMBw-wHgsdmgVXGijBS-TVGm8=YQLcOzp@mail.gmail.com> Message-ID: <20101007180919.2etr01a9k44kcwks@webmail3.tkk.fi> Hello Robert, I dare to bother you again with some questions. this time I have a numpy array with fields ar = array([(1.0, 2.0, 3, 4), (2.0, 3.0, 4, 5)], dtype={'names': ['q','wl','cssid','br'], 'formats':['f4', 'f4', 'i4', 'i4'], 'offsets': [0, 4, 8, 12]}, order='F') on C API I want to match this struct typedef struct val1{ float q; float wl; int cssid; int br; }hm1dval1; to an element of this array I get the array object, i can see the fields. The type of the array elements is Pyarray_VOID however following code gives me a segfault hm1dval1 **s = PyArray_DATA(ao); fprintf(stdout, "q is %d\n", (**s).cssid); I also tried to use PyArray_BYTES but it failed too I was thinking to add 4 bytes to PyArray_DATA(ao) for each member of the struct and for each elem of the array and cast those pointers to the float, float respectively int, int values but that failed too. Can you see what am I doing wrong? Quoting Robert Kern : > On Mon, Oct 4, 2010 at 00:41, Ioan Ferencik wrote: >> Hello list, >> >> I am trying to pass elements of a custom defined with C API. >> I have successfully wrapped a type around a C struct. >> I intent to create a list with these objects and process it using >> numpy C API. >> So i ?create an array: >> >> array = (PyArrayObject *)PyArray_ContiguousFromObject(input, >> PyArray_OBJECT, 0, 0); >> >> to my understanding each el. in this array is a pointer to my type so >> a cast to this type >> should work. >> >> >> this is my custom type >> >> typedef struct val{ >> ? ? ? ? PyObject_HEAD >> ? ? ? ? float q; >> ? ? ? ? float wl; >> ? ? ? ? int cssid; >> ? ? ? ? int br; >> }hm1dval; >> >> I am passing only one element for testing purposes. >> >> in python >> a = [hm1d1.hm1dval() for i in range(0,1)] >> for c in a: >> ? ? ? ? c.set_values(q=3.0, wl=2.5, cssid=6, br=7) >> >> >> So following code should be valid in C: >> >> hm1dval s* = PyArray_DATA(array); >> >> but the members are 0 after casting in spite they were set previously. > > The elements of a dtype=object array are PyObject* pointers. In C, an > array of pointers would look like this: > > hm1dval **s = PyArray_DATA(array); > > -- > 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 at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > Ioan Ferencik PhD student Aalto University School of Science and Technology Faculty Of Civil and Env. Engineering Lahti Center Tel: +358505122707 From doc at zen-pharaohs.com Thu Oct 7 12:08:09 2010 From: doc at zen-pharaohs.com (Andrew P. Mullhaupt) Date: Thu, 07 Oct 2010 12:08:09 -0400 Subject: [Numpy-discussion] Assigning complex value to real array In-Reply-To: References: <29902859.post@talk.nabble.com> <4CAD5592.4010409@zen-pharaohs.com> Message-ID: <4CADF069.5030705@zen-pharaohs.com> On 10/7/2010 1:31 AM, Charles R Harris wrote: > > > On Wed, Oct 6, 2010 at 11:07 PM, Andrew P. Mullhaupt > > wrote: > > > I came across this gem yesterday > > > >>> from numpy import * > >>> R = ones((2)) > >>> R[0] = R[0] * 1j > >>> R > ...array([ 0., 1.]) > >>> R = ones((2), 'complex') > >>> R[0] = R[0] * 1j > >>> R > array([ 0.+1.j, 1.+0.j])" > > and I read that this behavior is actually intended for some reason > about how Python wants relations between types to be such that > this mistake is unavoidable. > > > It's because an element of a real array only has space for a real and > you can't fit a complex in there. Some other software which is less > strict about types may allow such things, but it comes at a cost. A cost that in any particular instance drops by a somthing like a factor of two every year. But the cost of causing someone to chase down a bug hiding in this particular bush is a human cost, so, if anything, over time that cost increases with the rate of inflation. > > So can we have a new abstract floating type which is a complex, > but is implemented so that the numbers where the imaginary part is > zero represent and operate on that imaginary part implicitly? By > containing all these semantics within one type, then presumably we > avoid problems with ideas relationships between types. > > > Changing types like you propose would require making a new copy or > reserving space ahead of time > No. You can define the arrays as backed by mapped files with real and imaginary parts separated. Then the imaginary part, being initially zero, is a sparse part of the file, takes only a fraction of the space (and, on decent machine doesn't incur memory bandwidth costs either). You can then slipstream the cost of testing for whether the imaginary part has been subsequently assigned to zero (so you can re-sparsify the representation of a page) with any operation that examines all the values on that page. Consistency would be provided by the OS, so there wouldn't really be much numpy-specific code involved. So there is at least one efficient way to implement my suggestion. Best regards, Andrew Mullhaupt -------------- next part -------------- An HTML attachment was scrubbed... URL: From nwagner at iam.uni-stuttgart.de Thu Oct 7 12:58:37 2010 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Thu, 07 Oct 2010 18:58:37 +0200 Subject: [Numpy-discussion] Schedule for 1.5.1? In-Reply-To: References: Message-ID: On Thu, 7 Oct 2010 09:06:55 +0000 (UTC) Pauli Virtanen wrote: > Thu, 07 Oct 2010 16:34:46 +0800, Ralf Gommers wrote: > [clip] >> A 1.5.1 release soon would be good. All the issues above >>are already >> committed, is there anything else that needs to go in? >>If not, I think >> an RC by the end of next week (10/17) and release by the >>end of the >> month should be possible. > > Sounds good to me. > > I don't remember any other "critical" bugs being >present, but I can go > through the tickets during next WE in case there are >some low-hanging > fruits. > > Pauli > However, there is an everlasting ticket opened 2 years ago http://projects.scipy.org/numpy/ticket/937 Nils From pav at iki.fi Thu Oct 7 13:01:47 2010 From: pav at iki.fi (Pauli Virtanen) Date: Thu, 07 Oct 2010 19:01:47 +0200 Subject: [Numpy-discussion] Assigning complex value to real array In-Reply-To: <4CADF069.5030705@zen-pharaohs.com> References: <29902859.post@talk.nabble.com> <4CAD5592.4010409@zen-pharaohs.com> <4CADF069.5030705@zen-pharaohs.com> Message-ID: <1286470907.3425.33.camel@talisman> to, 2010-10-07 kello 12:08 -0400, Andrew P. Mullhaupt kirjoitti: [clip] > No. You can define the arrays as backed by mapped files with real and > imaginary parts separated. Then the imaginary part, being initially > zero, is a sparse part of the file, takes only a fraction of the > space (and, on decent machine doesn't incur memory bandwidth costs > either). You can then slipstream the cost of testing for whether the > imaginary part has been subsequently assigned to zero (so you can > re-sparsify the representation of a page) with any operation that > examines all the values on that page. Consistency would be provided by > the OS, so there wouldn't really be much numpy-specific code involved. > > So there is at least one efficient way to implement my suggestion. Interesting idea. Most OSes offer also page-allocated memory not backed in files. In fact, Glibc's malloc works just like this on Linux for large memory blocks. It would work automatically like this with complex arrays, if the imaginary part was stored after the real part, and additional branches were added to not write zeros to memory. But to implement this, you'd have to rewrite large parts of Numpy since the separated storage of re/im conflicts with its memory model. I believe this will simply not be done, since there seems to be little need for such a feature. -- Pauli Virtanen From jmarch at enthought.com Thu Oct 7 13:09:30 2010 From: jmarch at enthought.com (Jonathan March) Date: Thu, 7 Oct 2010 12:09:30 -0500 Subject: [Numpy-discussion] known failure test decorator not treated as expected by nose In-Reply-To: References: Message-ID: On Wed, Oct 6, 2010 at 6:17 PM, wrote: > On Wed, Oct 6, 2010 at 7:08 PM, Jonathan March wrote: >> It appears that the numpy testing decorators for skipping and for >> known failure should behave similarly to each other, at least from >> their descriptions here: >> http://projects.scipy.org/numpy/wiki/TestingGuidelines#known-failures-skipping-tests >> >> Yet in the following example, run under nose, they behave quite differently: >> >> ==== >> from numpy.testing import ?dec >> >> @dec.knownfailureif( True, "known failure test message") >> def test_will_fail(): >> ? ?pass >> >> @dec.skipif( True, "skip test message") >> def test_to_skip(): >> ? ?pass >> ==== >> >> The skipped test is marked as "S" as expected, but when the >> KnownFailureTest exception is raised, nose handles it as an error >> (marked "E" rather than "K" as expected, and printing the stack >> trace.) >> >> It's also interesting that nose has a --no-skip option but no >> corresponding option for ignoring known failure decorators. >> >> Why the discrepancy? Who is out of step with whom? This is with numpy >> 1.4.0 and nosetests 0.11.3 > > just as additional information > > This only happens on the command line, with nosetests packagename > but not with the function, packagename.test() > > Josef Numpy issue, nose issue, or user issue? >> Thanks, >> Jonathan March From n.becker at amolf.nl Thu Oct 7 13:42:09 2010 From: n.becker at amolf.nl (Nils Becker) Date: Thu, 07 Oct 2010 19:42:09 +0200 Subject: [Numpy-discussion] Schedule for 1.5.1? In-Reply-To: References: Message-ID: <4CAE0671.60705@amolf.nl> Hi, what about the normed=True bug in numpy.histogram? It was discussed here a while ago, and fixed (although i did not find it on the tracker), but the message suggests it just missed 1.5.0? I don't have 1.5 installed, so I can't check right now. sorry to mention my personal pet bug, but maybe it's also a candidate? Nils From doc at zen-pharaohs.com Thu Oct 7 15:38:03 2010 From: doc at zen-pharaohs.com (Andrew P. Mullhaupt) Date: Thu, 07 Oct 2010 15:38:03 -0400 Subject: [Numpy-discussion] Assigning complex value to real array In-Reply-To: <1286470907.3425.33.camel@talisman> References: <29902859.post@talk.nabble.com> <4CAD5592.4010409@zen-pharaohs.com> <4CADF069.5030705@zen-pharaohs.com> <1286470907.3425.33.camel@talisman> Message-ID: <4CAE219B.40207@zen-pharaohs.com> On 10/7/2010 1:01 PM, Pauli Virtanen wrote: > to, 2010-10-07 kello 12:08 -0400, Andrew P. Mullhaupt kirjoitti: > [clip] > But to implement this, you'd have to rewrite large parts of Numpy since > the separated storage of re/im conflicts with its memory model. You wouldn't want to rewrite any of numpy, just add a new class. > I believe this will simply not be done, since there seems to be little > need for such a feature No, there is a big need to get the feature in sooner rather than later. By having this behavior, Python is filtering out a lot of potential users. So you will not get a lot of complaints - because people will just walk away and use Matlab, Scilab, or R, etc. Given this behavior one is strongly tempted to declare everything complex and deprecate the reals. Unfortunately that is going to run afoul of some things in subsidiary libraries. This idea of "need". What does log(int(2)) return? I guess someone "needed" that one. But not log(int(-2)). Well, who needs physics and electrical engineering. I agree it will not be done, but mainly because people who are in a position to do it will find an excuse to not do it, not for any better reason. But it is important to inform everyone that it is not for lack of a better alternative that we have this problem. It is for lack of effort. Let's just fess up about why it's not going to be done. Best regards, Andrew Mullhaupt From josef.pktd at gmail.com Thu Oct 7 15:45:34 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Thu, 7 Oct 2010 15:45:34 -0400 Subject: [Numpy-discussion] Assigning complex value to real array In-Reply-To: <4CAE219B.40207@zen-pharaohs.com> References: <29902859.post@talk.nabble.com> <4CAD5592.4010409@zen-pharaohs.com> <4CADF069.5030705@zen-pharaohs.com> <1286470907.3425.33.camel@talisman> <4CAE219B.40207@zen-pharaohs.com> Message-ID: On Thu, Oct 7, 2010 at 3:38 PM, Andrew P. Mullhaupt wrote: > ?On 10/7/2010 1:01 PM, Pauli Virtanen wrote: >> to, 2010-10-07 kello 12:08 -0400, Andrew P. Mullhaupt kirjoitti: >> [clip] >> But to implement this, you'd have to rewrite large parts of Numpy since >> the separated storage of re/im conflicts with its memory model. > > You wouldn't want to rewrite any of numpy, just add a new class. > >> I believe this will simply not be done, since there seems to be little >> need for such a feature > > No, there is a big need to get the feature in sooner rather than later. > By having this behavior, Python is filtering out a lot of potential > users. So you will not get a lot of complaints - because people will > just walk away and use Matlab, Scilab, or R, etc. Given this behavior > one is strongly tempted to declare everything complex and deprecate the > reals. Unfortunately that is going to run afoul of some things in > subsidiary libraries. > > This idea of "need". What does log(int(2)) return? I guess someone > "needed" that one. But not log(int(-2)). Well, who needs physics and > electrical engineering. what's your namespace? >>> from scipy import log >>> log(int(-2)) (0.69314718055994529+3.1415926535897931j) Josef > I agree it will not be done, but mainly because people who are in a > position to do it will find an excuse to not do it, not for any better > reason. But it is important to inform everyone that it is not for lack > of a better alternative that we have this problem. It is for lack of > effort. Let's just fess up about why it's not going to be done. > > Best regards, > Andrew Mullhaupt > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > From aarchiba at physics.mcgill.ca Thu Oct 7 15:48:50 2010 From: aarchiba at physics.mcgill.ca (Anne Archibald) Date: Thu, 7 Oct 2010 15:48:50 -0400 Subject: [Numpy-discussion] Assigning complex value to real array In-Reply-To: <1286470907.3425.33.camel@talisman> References: <29902859.post@talk.nabble.com> <4CAD5592.4010409@zen-pharaohs.com> <4CADF069.5030705@zen-pharaohs.com> <1286470907.3425.33.camel@talisman> Message-ID: On 7 October 2010 13:01, Pauli Virtanen wrote: > to, 2010-10-07 kello 12:08 -0400, Andrew P. Mullhaupt kirjoitti: > [clip] >> No. You can define the arrays as backed by mapped files with real and >> imaginary parts separated. Then the imaginary part, being initially >> zero, is a sparse part of the file, takes only a fraction of the >> space ?(and, on decent machine doesn't incur memory bandwidth costs >> either). ?You can then slipstream the cost of testing for whether the >> imaginary part has been subsequently assigned to zero (so you can >> re-sparsify the representation of a page) with any operation that >> examines all the values on that page. Consistency would be provided by >> the OS, so there wouldn't really be much numpy-specific code involved. >> >> So there is at least one efficient way to implement my suggestion. > > Interesting idea. Most OSes offer also page-allocated memory not backed > in files. In fact, Glibc's malloc works just like this on Linux for > large memory blocks. > > It would work automatically like this with complex arrays, if the > imaginary part was stored after the real part, and additional branches > were added to not write zeros to memory. > > But to implement this, you'd have to rewrite large parts of Numpy since > the separated storage of re/im conflicts with its memory model. I > believe this will simply not be done, since there seems to be little > need for such a feature. Years ago MATLAB did just this - store real and complex parts of arrays separately (maybe it still does, I haven't used it in a long time). It caused us terrible performance headaches, since it meant that individual complex values were spread over two different memory areas (parts of the disk in fact, since we were using gigabyte arrays in 1996), so that writing operations in the natural way tended to cause disk thrashing. As for what's right for numpy, well, I think it makes a lot more sense to simply raise an exception when assigning a complex value to a real array (or store a NaN). Usually when this happens it means you either didn't know how numpy worked or you were feeding bogus values to some special function so it went complex on you. If you actually wanted potentially-complex values, you'd create complex arrays; as the OP says, there's little extra cost. Fortunately, this latter strategy is the way that numpy is already headed; currently I believe it emits a warning, and ISTR this is intended to be strengthened to an exception or NaN soon. Anne From Chris.Barker at noaa.gov Thu Oct 7 16:50:10 2010 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Thu, 07 Oct 2010 13:50:10 -0700 Subject: [Numpy-discussion] Assigning complex value to real array In-Reply-To: <4CAE219B.40207@zen-pharaohs.com> References: <29902859.post@talk.nabble.com> <4CAD5592.4010409@zen-pharaohs.com> <4CADF069.5030705@zen-pharaohs.com> <1286470907.3425.33.camel@talisman> <4CAE219B.40207@zen-pharaohs.com> Message-ID: <4CAE3282.3020200@noaa.gov> First: Wow! what a rude post. I'm not a significant contributer to numpy, but that was really offensive to me. Most of the features of numpy were in fact carefully designed for good reason -- they may not match your use case well, but that does not mean that they are not good design decisions. Other features of numpy were perhaps the result of something simply being overlooked -- it is continually improving as Anne and Chuck mentioned. As for your issue -- I've deleted your original post, so I lost your specific use/test case, but a note about numpy design: numpy allows the use of various data types, of various levels of precision -- this is a very powerful feature. And while python is a dynamic language, numpy tries to not upcast arrays unless specifically asked to: In [22]: a = np.array((5,6), dtype=np.int32) In [26]: a += 1.2 In [27]: a Out[27]: array([6, 7]) In [28]: a[0] = 4.5 In [29]: a Out[29]: array([4, 7]) Would you have wanted your array to be upcast to a float? In [50]: a Out[50]: array([5, 6], dtype=uint8) In [51]: a+=3000 In [52]: a Out[52]: array([189, 190], dtype=uint8) or upcast to a bigger int type? In short -- numpy gives you some real power and flexibility that Matlab, for instance, does not, but it does require you to think about what dtype you want to use ahead of time. > You wouldn't want to rewrite any of numpy, just add a new class. If you understood what the issue was, you'd know it isn't that simple. You could, in fact, write array class that stored the real and imaginary parts in separate numpy arrays, but it would still be a lot of work to get that to all work smoothly with the rest of numpy, and you'd get a major performance hit, and it would be hard to interface with C libs. > By having this behavior, Python is filtering out a lot of potential > users. So you will not get a lot of complaints - because people will > just walk away and use Matlab, Scilab, or R, etc. Ha! I walked away from Matlab years ago -- and having control over datatypes was one major reason. > Given this behavior > one is strongly tempted to declare everything complex and deprecate the > reals. For some uses, that's a fine idea. > Well, who needs physics and electrical engineering. Anyone competent doing calculations for physics and engineering darn well better know when to expect complex numbers. > I agree it will not be done, but mainly because people who are in a > position to do it will find an excuse to not do it, not for any better > reason. no one needs an excuse not to implement something -- "none of us has the time" or "it's not important enough to me to want to do it" are fine. There are plenty of good suggestions made on this list that don't get implemented for those sorts of reasons. > But it is important to inform everyone that it is not for lack > of a better alternative that we have this problem. It is for lack of > effort. Let's just fess up about why it's not going to be done. I think it's not going to be done because you're too lazy to do it -- this is an open source project, you are free to contribute. If you are so convinced that you're right -- put your code where your mouth is. By the way, if Matlab or Scilab or R is a better tool for your work, go ahead and use it -- it makes no difference to us what you use. -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 Chris.Barker at noaa.gov From pav at iki.fi Thu Oct 7 17:14:51 2010 From: pav at iki.fi (Pauli Virtanen) Date: Thu, 07 Oct 2010 23:14:51 +0200 Subject: [Numpy-discussion] Assigning complex value to real array In-Reply-To: <4CAE219B.40207@zen-pharaohs.com> References: <29902859.post@talk.nabble.com> <4CAD5592.4010409@zen-pharaohs.com> <4CADF069.5030705@zen-pharaohs.com> <1286470907.3425.33.camel@talisman> <4CAE219B.40207@zen-pharaohs.com> Message-ID: <1286486091.2859.61.camel@talisman> to, 2010-10-07 kello 15:38 -0400, Andrew P. Mullhaupt kirjoitti: [clip] > On 10/7/2010 1:01 PM, Pauli Virtanen wrote: > > to, 2010-10-07 kello 12:08 -0400, Andrew P. Mullhaupt kirjoitti: > > [clip] > > But to implement this, you'd have to rewrite large parts of Numpy since > > the separated storage of re/im conflicts with its memory model. > > You wouldn't want to rewrite any of Numpy, just add a new class. I believe you didn't really think about this. Because of the memory model mismatch, you will need to rewrite all arithmetic operations, special functions, and any operations that select, choose, sort, etc. parts of arrays. Even if retaining the current memory model, guaranteeing implicit casting requires rewriting any C code that might write to an user-provided array. Moreover, in this case implicit casting will break memory view semantics, since reallocation becomes necessary. It still looks like significant rewriting to me. > What does log(int(2)) return? I guess someone > "needed" that one. But not log(int(-2)). Well, who needs physics and > electrical engineering. Now I understand why no physicist or engineer uses FORTRAN. > No, there is a big need to get the feature in sooner rather than > later. By having this behavior, Python is filtering out a lot of > potential users. Having strict data types is not the only place where Numpy behaves differently from Matlab. So it is hard to believe, without any substantive facts having been presented so far, that strict data types would be *the* crucial issue for N >> 1 users. Best regards, Pauli Virtanen From doc at zen-pharaohs.com Thu Oct 7 18:02:43 2010 From: doc at zen-pharaohs.com (Andrew P. Mullhaupt) Date: Thu, 07 Oct 2010 18:02:43 -0400 Subject: [Numpy-discussion] Assigning complex value to real array In-Reply-To: References: <29902859.post@talk.nabble.com> <4CAD5592.4010409@zen-pharaohs.com> <4CADF069.5030705@zen-pharaohs.com> <1286470907.3425.33.camel@talisman> <4CAE219B.40207@zen-pharaohs.com> Message-ID: <4CAE4383.2020307@zen-pharaohs.com> On 10/7/2010 3:45 PM, josef.pktd at gmail.com wrote: > what's your namespace?from scipy import log >>>> log(int(-2)) > (0.69314718055994529+3.1415926535897931j) This should explain: andrew at flyer:~$ python Enthought Python Distribution -- http://www.enthought.com Version: 6.2-2 (64-bit) Python 2.6.5 |EPD 6.2-2 (64-bit)| (r265:79063, Mar 22 2010, 17:32:05) [GCC 4.1.2 20080704 (Red Hat 4.1.2-44)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from numpy import * >>> log(int(-2)) nan >>> from scipy import * >>> log(int(-2)) (0.69314718055994529+3.1415926535897931j) >>> R = ones(2) >>> R[0] = R[0] * 1j >>> R array([ 0., 1.]) >>> R = ones(2, 'complex') >>> R[0] = R[0] * 1j >>> R array([ 0.+1.j, 1.+0.j]) Best Regards, Andrew Mullhaupt From pav at iki.fi Thu Oct 7 18:17:27 2010 From: pav at iki.fi (Pauli Virtanen) Date: Thu, 7 Oct 2010 22:17:27 +0000 (UTC) Subject: [Numpy-discussion] Assigning complex value to real array References: <29902859.post@talk.nabble.com> <4CAD5592.4010409@zen-pharaohs.com> <4CADF069.5030705@zen-pharaohs.com> <1286470907.3425.33.camel@talisman> <4CAE219B.40207@zen-pharaohs.com> <4CAE4383.2020307@zen-pharaohs.com> Message-ID: Thu, 07 Oct 2010 18:02:43 -0400, Andrew P. Mullhaupt wrote: > On 10/7/2010 3:45 PM, josef.pktd at gmail.com wrote: >> what's your namespace?from scipy import log >>>>> log(int(-2)) >> (0.69314718055994529+3.1415926535897931j) > > This should explain: > >>> R = ones(2) > >>> R[0] = R[0] * 1j > >>> R > array([ 0., 1.]) [clip] As Charles and Anne said: > Newer versions of numpy will warn you that the imaginary part is > going to be discarded in your first example. This will possibly be strengthened to an error or NaN in the future. From david.kirkby at onetel.net Thu Oct 7 18:38:50 2010 From: david.kirkby at onetel.net (Dr. David Kirkby) Date: Thu, 07 Oct 2010 23:38:50 +0100 Subject: [Numpy-discussion] Schedule for 1.5.1? In-Reply-To: References: Message-ID: <4CAE4BFA.8090503@onetel.net> On 10/ 6/10 12:49 AM, Pauli Virtanen wrote: > Hi, > > Should we set a date for a bugfix 1.5.1 release? There are some bugs that > would be nice to sort out in the 1.5.x series: > > Any Python versions: > > - #1605 (Cython vs. PEP-3118 issue: raising exceptions with active > cython buffers caused undefined behavior. Breaks Sage.) > - #1617 (Ensure complex(np.longcomplex(...)) doesn't drop the imag part) > - Fix doc build I'd like to see the 'isfinite' bug in 1.5.1, which is #1625 and has been committed I believe. Dave From doutriaux1 at llnl.gov Thu Oct 7 18:40:53 2010 From: doutriaux1 at llnl.gov (Charles Doutriaux) Date: Thu, 07 Oct 2010 15:40:53 -0700 Subject: [Numpy-discussion] numpy.distutils Message-ID: <4CAE4C75.2040105@llnl.gov> Hi, I'm not sure if this is a numpy.distutils or a regular distutils issue so please excuse me if it doesn't belong here. I 'm using numpy 1.4.1 and I have a C extension (using numpy arrays) that I built with numpy. When I'm debugging I frequently have to rebuild. It use to rebuild only the C files that had been touched. Since python 2.7 (it seems to be the trigger) it now ALWAYS rebuild EVERY C file wherever or not they need to. Did anybody else noticed this? Anybody know what changed (the fact that it's since Python 2.7 make me think it might be pure distutils related) Any insight on how distuils and numpy.distutils are related would be great too! Thanks, C. From doc at zen-pharaohs.com Thu Oct 7 18:47:03 2010 From: doc at zen-pharaohs.com (Andrew P. Mullhaupt) Date: Thu, 07 Oct 2010 18:47:03 -0400 Subject: [Numpy-discussion] Assigning complex value to real array In-Reply-To: References: <29902859.post@talk.nabble.com> <4CAD5592.4010409@zen-pharaohs.com> <4CADF069.5030705@zen-pharaohs.com> <1286470907.3425.33.camel@talisman> Message-ID: <4CAE4DE7.20403@zen-pharaohs.com> On 10/7/2010 3:48 PM, Anne Archibald wrote: > > Years ago MATLAB did just this - store real and complex parts of > arrays separately (maybe it still does, I haven't used it in a long > time). It caused us terrible performance headaches, Years ago performance headaches from Matlab are not exactly relevant today, for several reasons. There have been other languages that made that choice - APL for example. Your performance problems there could have been caused (depending on machine) by things like TLB congestion, other address translation issues (segmented memory). Most machines now and in the future are not going to choke on these issues (for a variety of reasons). Note that even as early as 1989, it was possible to use the memory mapping technique I described (in SunOS 4.0) and on that machine, the ability to fill a register with all zeros in a single instruction means that there would have been almost no penalty for the address translation. What matters now, and for the foreseeable future, is pretty much the memory bandwidth - memory bandwidth at some cache level - memory for storage and FPU bandwidth is not limiting any more. Let's be clear about apples to apples comparison. Let's consider a very large array which sometimes has nonzero imaginary part as a result of calculation (and therefore not predictable when the code is written). Strategy I is for the programmer to declare the array as complex from the beginning - thereby doubling the required memory bandwidth (at every level involved) for the entire computation. You double the cache footprint at every level, etc. You will pretty much eat the full factor of 2 memory bandwidth penalty. Strategy II is to have the imaginary part of the array as a sparse (initially null) file. Well, if the array never has a nonzero imaginary part, then the memory bandwidth is the same at all levels except perhaps at the level of the register file. This could conceivably change if the granularity of the file system changes to have pages much larger than 4kB, but unless someone decides to have a page size larger than the L1 cache on their processor, it's really just the register file where you care. Well suppose you end up really caring. You actually can test, once per page, if the imaginary page is the zero page, and call the real code instead - giving you essentially full bandwidth on the comptation down to the granularity of a page. Since a page is 512 doubles, the overhead of this test is less than one branch instruction per 512 flops - but with modern CPU architecture that branch will get predicted, so normally there will be zero overhead for this test. In other words, if you know what you're doing, you should achieve full bandwidth. Of course, you probably have the question of locality of reference in mind. Here there are at least two answers to any possible objection there - the first is that modern address translation is good enough to interleave two streams anyway - you can actually check this right now on your machine. Time how long it takes to add two very long vectors (say of length 2N) to produce a third. Then compare this to the time it takes to add two vectors of length N to produce a third, and two other vectors of length N to produce a fourth. Unless those times are significantly different as N becomes very large, you have confirmed that your machine can translate addresses and shovel segregated real and complex parts through the FPU about as fast as it can shovel them the corresponding interleaved real and complex parts through the FPU. Well OK suppose you worry about N so big that having real and complex parts in different parts of the file system is an issue - you could always interleave the PAGES of the real and imaginary parts to eliminate address differences of more than one page length from consideration. That's answer number two. > since it meant > that individual complex values were spread over two different memory > areas (parts of the disk in fact, since we were using gigabyte arrays > in 1996), so that writing operations in the natural way tended to > cause disk thrashing. Yeah you didn't understand memory mapping, which was available back in 1989. We were using 4GB arrays by 1990. I got really tired of evangelizing memory mapping to various communities (which I did a lot back then, including the early Numerical Python community). So these days I just say "I told you so." Kevin Sheehan told you so too (His classic paper "Why aren't you using mmap() yet?" is from February 1996). > As for what's right for numpy, well, I think it makes a lot more sense > to simply raise an exception when assigning a complex value to a real > array (or store a NaN). That would at least allow a workaround. However I want quiet NaNs to stay quiet, only signalling NaNs are allowed to get up in my grille. Best Regards, Andrew Mullhaupt From matthew.brett at gmail.com Thu Oct 7 18:52:45 2010 From: matthew.brett at gmail.com (Matthew Brett) Date: Thu, 7 Oct 2010 15:52:45 -0700 Subject: [Numpy-discussion] Assigning complex value to real array In-Reply-To: <4CAE4DE7.20403@zen-pharaohs.com> References: <29902859.post@talk.nabble.com> <4CAD5592.4010409@zen-pharaohs.com> <4CADF069.5030705@zen-pharaohs.com> <1286470907.3425.33.camel@talisman> <4CAE4DE7.20403@zen-pharaohs.com> Message-ID: Hi, On Thu, Oct 7, 2010 at 3:47 PM, Andrew P. Mullhaupt wrote: > ?On 10/7/2010 3:48 PM, Anne Archibald wrote: >> >> Years ago MATLAB did just this - store real and complex parts of >> arrays separately (maybe it still does, I haven't used it in a long >> time). It caused us terrible performance headaches, > > Most machines now > and in the future are not going to choke on these issues (for a variety > of reasons). 'Talk is cheap, show me the code' . http://en.wikiquote.org/wiki/Linus_Torvalds Best, Matthew From doc at zen-pharaohs.com Thu Oct 7 19:21:53 2010 From: doc at zen-pharaohs.com (Andrew P. Mullhaupt) Date: Thu, 07 Oct 2010 19:21:53 -0400 Subject: [Numpy-discussion] Assigning complex value to real array In-Reply-To: <4CAE3282.3020200@noaa.gov> References: <29902859.post@talk.nabble.com> <4CAD5592.4010409@zen-pharaohs.com> <4CADF069.5030705@zen-pharaohs.com> <1286470907.3425.33.camel@talisman> <4CAE219B.40207@zen-pharaohs.com> <4CAE3282.3020200@noaa.gov> Message-ID: <4CAE5611.1090200@zen-pharaohs.com> On 10/7/2010 4:50 PM, Christopher Barker wrote: > Most of the features of numpy were in fact carefully designed for good > reason I was around back in those days. I know a bit about the design process of which you speak. > In [22]: a = np.array((5,6), dtype=np.int32) > > In [26]: a += 1.2 > > In [27]: a > Out[27]: array([6, 7]) > > In [28]: a[0] = 4.5 > > In [29]: a > Out[29]: array([4, 7]) > > Would you have wanted your array to be upcast to a float? Either that or raise a warning or error. > In [50]: a > Out[50]: array([5, 6], dtype=uint8) > > In [51]: a+=3000 > > In [52]: a > Out[52]: array([189, 190], dtype=uint8) > > or upcast to a bigger int type? Same as above. >> You wouldn't want to rewrite any of numpy, just add a new class. > If you understood what the issue was, you'd know it isn't that simple. The issue is that it is a fraud for the interpreter to silently pretend that it has succesfully completed an assignment which makes no sense at all. You know, in FORTRAN, you used to be able to assign a value to a literal, say you assigned the value 12 to the literal 4: Z = 4 + 1 Z could have the value 13. Originally, no compile time or run time error or warning was given. Now I forget the actual FORTRAN syntax needed to do this - it's not a technique I used in any program. I have a vague recollection that in the earliest days you could just write 4 = 12 but as compiler writers got wise to these tricks it became necessary to add syntax to achieve this (insane) result. Well yes, FORTRAN was 'carefully designed' - in fact by very smart people. But frankly, this example is one of the things in the programming world that is just wrong. Now if you understood what FORTRAN was supposed to be, from one point of view - that FORTRAN was a program to translate formulas into assembler language - then you would realize that in the world of assembler language, there aren't "variables" that have "values" - there are memory addresses which have contents, so what is so crazy about referring to a memory address with a numeral as opposed to a string literal? So yes, we can construct a point of view with which to excuse that disaster. In fact, that point of view is how that disaster actually happened. The people writing the FORTRAN compiler wrote code to resolve the left hand of an assignment into a memory address. If you understood that then you could explain to people that 4 = X made sense to work that way. Best regards, Andrew Mullhaupt From doc at zen-pharaohs.com Thu Oct 7 19:46:14 2010 From: doc at zen-pharaohs.com (Andrew P. Mullhaupt) Date: Thu, 07 Oct 2010 19:46:14 -0400 Subject: [Numpy-discussion] Assigning complex value to real array In-Reply-To: <1286486091.2859.61.camel@talisman> References: <29902859.post@talk.nabble.com> <4CAD5592.4010409@zen-pharaohs.com> <4CADF069.5030705@zen-pharaohs.com> <1286470907.3425.33.camel@talisman> <4CAE219B.40207@zen-pharaohs.com> <1286486091.2859.61.camel@talisman> Message-ID: <4CAE5BC6.4040305@zen-pharaohs.com> On 10/7/2010 5:14 PM, Pauli Virtanen wrote: > to, 2010-10-07 kello 15:38 -0400, Andrew P. Mullhaupt kirjoitti: > [clip] >> On 10/7/2010 1:01 PM, Pauli Virtanen wrote: >>> to, 2010-10-07 kello 12:08 -0400, Andrew P. Mullhaupt kirjoitti: >>> [clip] >>> But to implement this, you'd have to rewrite large parts of Numpy since >>> the separated storage of re/im conflicts with its memory model. >> You wouldn't want to rewrite any of Numpy, just add a new class. > I believe you didn't really think about this. Because of the memory > model mismatch, you will need to rewrite all arithmetic operations, > special functions, and any operations that select, choose, sort, etc. > parts of arrays. It wouldn't be the first time I suggested rewriting the select and choose operations. I spent months trying to get Guido to let anything more than slice indexing in arrays. And now, in the technologically advanced future, we can index a numpy array with a list, not just slices. I'm not claiming any credit for that though - I don't know who actually got that ball over the finish line. But it's also not as bad as you think if you do it right. In the first place, you don't need to rewrite any of the real operations other than to check if the complex part is trivial or not (which as I pointed out a minute ago can be done on a variable granular or page granular level for variables that take up more than a page. So it's only the case with a nontrivial complex part where you have to do anything at all. OK so just offset the real address by the different to the imaginary part. Doing this on a variable-level granularity would allow you to simply replicate all the selection and sorting addressing. The interesting case is noncontiguous data arrays. Here, you can actually get a benefit, since if all the floating values are in this class, you already know the address of the memory where you will widen them - so if you have to widen some horrific recursive spaghetti structure, then you get a big win here because you don't have to worry about copying the real parts. But let's go back to what I asked: Could we have a data type that would be able to widen itself? It appears that your answer is YES, we COULD have that, BUT it would be a lot of work. Best regards, Andrew Mullhaupt From robert.kern at gmail.com Thu Oct 7 20:21:03 2010 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 7 Oct 2010 19:21:03 -0500 Subject: [Numpy-discussion] Assigning complex value to real array In-Reply-To: <4CAE5BC6.4040305@zen-pharaohs.com> References: <29902859.post@talk.nabble.com> <4CAD5592.4010409@zen-pharaohs.com> <4CADF069.5030705@zen-pharaohs.com> <1286470907.3425.33.camel@talisman> <4CAE219B.40207@zen-pharaohs.com> <1286486091.2859.61.camel@talisman> <4CAE5BC6.4040305@zen-pharaohs.com> Message-ID: On Thu, Oct 7, 2010 at 18:46, Andrew P. Mullhaupt wrote: > ?On 10/7/2010 5:14 PM, Pauli Virtanen wrote: >> to, 2010-10-07 kello 15:38 -0400, Andrew P. Mullhaupt kirjoitti: >> [clip] >>> On 10/7/2010 1:01 PM, Pauli Virtanen wrote: >>>> to, 2010-10-07 kello 12:08 -0400, Andrew P. Mullhaupt kirjoitti: >>>> [clip] >>>> But to implement this, you'd have to rewrite large parts of Numpy since >>>> the separated storage of re/im conflicts with its memory model. >>> You wouldn't want to rewrite any of Numpy, just add a new class. >> I believe you didn't really think about this. Because of the memory >> model mismatch, you will need to rewrite all arithmetic operations, >> special functions, and any operations that select, choose, sort, etc. >> parts of arrays. ... > But let's go back to what I asked: Could we have a data type that would > be able to widen itself? > > It appears that your answer is YES, we COULD have that, BUT it would be > a lot of work. You misread him. The answer is "no." We will not change the memory model so incompatibly. There is not only too much code in numpy to rewrite, but a ton of other code that we do not maintain that relies on our current memory model. -- 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 From robert.kern at gmail.com Thu Oct 7 20:24:16 2010 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 7 Oct 2010 19:24:16 -0500 Subject: [Numpy-discussion] ndarray of object dtype In-Reply-To: <20101007180919.2etr01a9k44kcwks@webmail3.tkk.fi> References: <20101004084120.7bmxuk1dcsc0coko@webmail3.tkk.fi> <15612_1286204190_ZZ0L9R0038DTI5HY.00_AANLkTinopyssMBw-wHgsdmgVXGijBS-TVGm8=YQLcOzp@mail.gmail.com> <20101007180919.2etr01a9k44kcwks@webmail3.tkk.fi> Message-ID: On Thu, Oct 7, 2010 at 10:09, Ioan Ferencik wrote: > Hello Robert, > > I dare to bother you again with some ?questions. > > this time I have a numpy array with fields > ar = array([(1.0, 2.0, 3, 4), (2.0, 3.0, 4, 5)], dtype={'names': > ['q','wl','cssid','br'], 'formats':['f4', 'f4', 'i4', 'i4'], > 'offsets': [0, 4, 8, 12]}, order='F') > > on C API I want to match this struct > typedef struct val1{ > ? ? ? ?float q; > ? ? ? ?float wl; > ? ? ? ?int cssid; > ? ? ? ?int br; > }hm1dval1; > > to an element of this array > I get the array object, i can see the fields. The type of the array > elements is Pyarray_VOID > > however following code gives me a segfault > > hm1dval1 **s = PyArray_DATA(ao); Since this is *not* an object array but an array of hm1dval1 structs, you declare it like so: hm1dval1 *s = PyArray_DATA(ao); -- 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 From aarchiba at physics.mcgill.ca Thu Oct 7 21:48:22 2010 From: aarchiba at physics.mcgill.ca (Anne Archibald) Date: Thu, 7 Oct 2010 21:48:22 -0400 Subject: [Numpy-discussion] Assigning complex value to real array In-Reply-To: <4CAE5BC6.4040305@zen-pharaohs.com> References: <29902859.post@talk.nabble.com> <4CAD5592.4010409@zen-pharaohs.com> <4CADF069.5030705@zen-pharaohs.com> <1286470907.3425.33.camel@talisman> <4CAE219B.40207@zen-pharaohs.com> <1286486091.2859.61.camel@talisman> <4CAE5BC6.4040305@zen-pharaohs.com> Message-ID: On 7 October 2010 19:46, Andrew P. Mullhaupt wrote: > It wouldn't be the first time I suggested rewriting the select and > choose operations. I spent months trying to get Guido to let anything > more than slice indexing in arrays. And now, in the technologically > advanced future, we can index a numpy array with a list, not just > slices. I'm not claiming any credit for that though - I don't know who > actually got that ball over the finish line. Someone who wrote code instead of complaining. Anne From doc at zen-pharaohs.com Thu Oct 7 22:20:23 2010 From: doc at zen-pharaohs.com (Andrew P. Mullhaupt) Date: Thu, 07 Oct 2010 22:20:23 -0400 Subject: [Numpy-discussion] Assigning complex value to real array In-Reply-To: References: <29902859.post@talk.nabble.com> <4CAD5592.4010409@zen-pharaohs.com> <4CADF069.5030705@zen-pharaohs.com> <1286470907.3425.33.camel@talisman> <4CAE4DE7.20403@zen-pharaohs.com> Message-ID: <4CAE7FE7.7030509@zen-pharaohs.com> On 10/7/2010 6:52 PM, Matthew Brett wrote: > Hi, > > On Thu, Oct 7, 2010 at 3:47 PM, Andrew P. Mullhaupt > wrote: >>> Most machines now >>> and in the future are not going to choke on these issues (for a variety >>> of reasons). > 'Talk is cheap, show me the code' . Yes, let's. First we want to initialize memory mapped arrays which will be used for the variables. This python script does that: from numpy import * N = 819200 X = random.uniform(0, 1, 2*N) Y = random.uniform(0, 1, 2*N) Z = random.uniform(0, 1, 2*N) p = random.uniform(0, 1, N) q = random.uniform(0, 1, N) r = random.uniform(0, 1, N) s = random.uniform(0, 1, N) w = random.uniform(0, 1, N) z = random.uniform(0, 1, N) save('X', X) save('Y', Y) save('Z', Z) save('p', p) save('q', q) save('r', r) save('s', s) save('w', w) save('z', z) Note that we have two arrays of length 2*N representing complex arrays with interleaved real and imaginary parts, and we have four arrays of length N representing the segregated real and complex parts. We also create arrays for the sums; these are not sparse (since we are concerned with the case where there actually are imaginary parts that would require memory bandwidth). Since we want to check the memory bandwidth we need a test which essentially shovels these arrays through memory very quickly. I have chosen to produce a result to ensure that everything actually gets done - although this is probably not strictly necessary, why not. First the interleaved version: from numpy import * X = load('X.npy', mmap_mode='r') Y = load('Y.npy', mmap_mode='r') Z = load('Z.npy', mmap_mode='r+') N = Z.size / 2 its = int(8192*100000 / N) for k in range(its) : Z[:] = X + Y print Z.max() Then the segregated version: from numpy import * p = load('p.npy', mmap_mode='r') q = load('q.npy', mmap_mode='r') r = load('r.npy', mmap_mode='r') s = load('s.npy', mmap_mode='r') w = load('w.npy', mmap_mode='r+') z = load('z.npy', mmap_mode='r+') N = s.size its = int(8192*100000 / N) for k in range(its) : w[:] = p + r z[:] = s + q print maximum(w.max(), z.max()) Note that the segregated version does not "cheat" by computing p + q and r + s which presumably span less address space. In fact, we would not expect that timing to be too much different. Now lets conduct the interleaved timing: andrew at flyer:/media/fraid/andrew/junk$ time python interleave.py 1.99960173329 real 0m6.438s user 0m6.400s sys 0m0.020s and the segregated one: andrew at flyer:/media/fraid/andrew/junk$ time python segregate.py 1.99858982651 real 0m6.198s user 0m6.140s sys 0m0.050s Well OK, I would describe this as pretty close. Oddly enough the segregated version is faster. Another pair of runs with larger files: andrew at flyer:/media/fraid/andrew/junk$ time python interleave.py 1.99995091618 real 0m11.480s user 0m6.070s sys 0m4.400s andrew at flyer:/media/fraid/andrew/junk$ time python segregate.py 1.99989270428 real 0m12.865s user 0m7.250s sys 0m4.330s Here we end up with another close run, but the segregated version is slower. So yeah, here is code you can use to see if your machine chokes on the old sort of issues (which were very common in early RISC workstation architectures - that awful TLB on the RS/6000 series springs immediately to mind). You can strobe through file sizes if you want to try and tickle one of those weirder creases in memory architecture on your machine, but you will probably not find anything that blatant. People who design computers have been through this rodeo a couple times. Best regards, Andrew Mullhaupt From doc at zen-pharaohs.com Thu Oct 7 22:47:46 2010 From: doc at zen-pharaohs.com (Andrew P. Mullhaupt) Date: Thu, 07 Oct 2010 22:47:46 -0400 Subject: [Numpy-discussion] Assigning complex value to real array In-Reply-To: References: <29902859.post@talk.nabble.com> <4CAD5592.4010409@zen-pharaohs.com> <4CADF069.5030705@zen-pharaohs.com> <1286470907.3425.33.camel@talisman> <4CAE219B.40207@zen-pharaohs.com> <1286486091.2859.61.camel@talisman> <4CAE5BC6.4040305@zen-pharaohs.com> Message-ID: <4CAE8652.7060401@zen-pharaohs.com> On 10/7/2010 8:21 PM, Robert Kern wrote: > On Thu, Oct 7, 2010 at 18:46, Andrew P. Mullhaupt wrote: > It appears that your answer is YES, we COULD have that, BUT it would be > a lot of work. > You misread him. The answer is "no." We will not change the memory > model so incompatibly. There is not only too much code in numpy to > rewrite, but a ton of other code that we do not maintain that relies > on our current memory model. Why would the class need to use the memory model of numpy? It wouldn't be getting it's memory from numpy if you used memory mapped files. Frankly, this is the sort of thing we did with Matlab and Splus before Matlab became somewhat liveable. Best regards, Andrew Mullhaupt From cournape at gmail.com Thu Oct 7 23:12:52 2010 From: cournape at gmail.com (David Cournapeau) Date: Fri, 8 Oct 2010 12:12:52 +0900 Subject: [Numpy-discussion] Assigning complex value to real array In-Reply-To: <4CAE8652.7060401@zen-pharaohs.com> References: <29902859.post@talk.nabble.com> <4CAD5592.4010409@zen-pharaohs.com> <4CADF069.5030705@zen-pharaohs.com> <1286470907.3425.33.camel@talisman> <4CAE219B.40207@zen-pharaohs.com> <1286486091.2859.61.camel@talisman> <4CAE5BC6.4040305@zen-pharaohs.com> <4CAE8652.7060401@zen-pharaohs.com> Message-ID: On Fri, Oct 8, 2010 at 11:47 AM, Andrew P. Mullhaupt wrote: > ?On 10/7/2010 8:21 PM, Robert Kern wrote: >> On Thu, Oct 7, 2010 at 18:46, Andrew P. Mullhaupt ?wrote: > >> It appears that your answer is YES, we COULD have that, BUT it would be >> a lot of work. >> You misread him. The answer is "no." We will not change the memory >> model so incompatibly. There is not only too much code in numpy to >> rewrite, but a ton of other code that we do not maintain that relies >> on our current memory model. > > Why would the class need to use the memory model of numpy? It wouldn't > be getting it's memory from numpy if you used memory mapped files. It does not need to strictly speaking, but it is certainly required for any kind of acceptable performances. Are you ready to give up the ufunc machinery, for example ? More precisely, a big issue with having real/imaginary not contiguously in memory is that it is incompatible with the C99/C++ complex model (which *requires* that a complex double has the same binary representation as double[2]). As far as I know, it is impossible to fake this using different mmap areas for real and complex. cheers, David From cournape at gmail.com Fri Oct 8 00:39:10 2010 From: cournape at gmail.com (David Cournapeau) Date: Fri, 8 Oct 2010 13:39:10 +0900 Subject: [Numpy-discussion] numpy.distutils In-Reply-To: <4CAE4C75.2040105@llnl.gov> References: <4CAE4C75.2040105@llnl.gov> Message-ID: On Fri, Oct 8, 2010 at 7:40 AM, Charles Doutriaux wrote: > > Did anybody else noticed this? Anybody know what changed (the fact that > it's since Python 2.7 make me think it might be pure distutils related) Could you check whether you still see the issue without using numpy.distutils ? I actually would be surprised to see it as a distutils issue proper, as somebody would have almost certainly noticed it already. > Any insight on how distuils and numpy.distutils are related would be > great too! numpy.distutils uses distutils, but in an unconvential way, because it needs to hook itself to internals. Hence, any non trivial change (and even trivial, sometimes) can break numpy.distutils. cheers, David From workalof at gmail.com Fri Oct 8 02:17:36 2010 From: workalof at gmail.com (John Mitchell) Date: Fri, 8 Oct 2010 00:17:36 -0600 Subject: [Numpy-discussion] test failure In-Reply-To: References: Message-ID: Thanks Ralf. This closes the issue for me. FYI When I set the precision to 4 I am able to repeat the test failure otherwise not. Its a bit odd the precision was changed somehow when I originally ran numpy.test() because I know that I didn't directly do that myself. >>> numpy.get_printoptions() {'infstr': 'inf', 'threshold': 1000, 'suppress': False, 'linewidth': 75, 'edgeitems': 3, 'precision': 8, 'nanstr': 'nan'} On Thu, Oct 7, 2010 at 3:35 AM, Ralf Gommers wrote: > > > On Sat, Oct 2, 2010 at 12:51 PM, John Mitchell wrote: > >> After spending a lot of time building 'numpy' (1.5.0) and 'scipy' (0.8.0) >> I ran the following tests -- per what I read somewhere: >> numpy.test() >> >> Out of several thousand small tests I found this one error -- perhaps its >> not really an error? >> >> This doesn't look serious but it can be bothersome when one is trying to >> be sure that the installation is as good as possible. >> > > It's not a real problem, it only has to do with your printing precision. Is > it possible you set it to 4 in your interpreter before running the tests, > perhaps by running some other file? I can reproduce the exact errors with: > > >>> np.set_printoptions(precision=4) > >>> np.test() > > You can check the precision with np.get_printoptions(), it should be 8 by > default. > > Ralf > > > >> >> Not sure if it matters, but my compiler is gcc-4.4.1 and I'm using >> gfortran. Both were wrapped with mpich2. >> >> Regards, >> John >> >> >> FAIL: test_doctests (test_polynomial.TestDocs) >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File >> "/usr/local/python2.6.6/lib/python2.6/site-packages/numpy/lib/tests/test_polynomial.py", >> line 90, in test_doctests >> return rundocs() >> File >> "/usr/local/python2.6.6/lib/python2.6/site-packages/numpy/testing/utils.py", >> line 962, in rundocs >> raise AssertionError("Some doctests failed:\n%s" % "\n".join(msg)) >> AssertionError: Some doctests failed: >> ********************************************************************** >> File >> "/usr/local/python2.6.6/lib/python2.6/site-packages/numpy/lib/tests/test_polynomial.py", >> line 38, in test_polynomial >> Failed example: >> p / q >> Expected: >> (poly1d([ 0.33333333]), poly1d([ 1.33333333, 2.66666667])) >> Got: >> (poly1d([ 0.333]), poly1d([ 1.333, 2.667])) >> >> ********************************************************************** >> File >> "/usr/local/python2.6.6/lib/python2.6/site-packages/numpy/lib/tests/test_polynomial.py", >> line 60, in test_polynomial >> Failed example: >> p.integ() >> Expected: >> poly1d([ 0.33333333, 1. , 3. , 0. ]) >> Got: >> poly1d([ 0.333, 1. , 3. , 0. ]) >> >> ********************************************************************** >> File >> "/usr/local/python2.6.6/lib/python2.6/site-packages/numpy/lib/tests/test_polynomial.py", >> line 62, in test_polynomial >> Failed example: >> p.integ(1) >> Expected: >> poly1d([ 0.33333333, 1. , 3. , 0. ]) >> Got: >> poly1d([ 0.333, 1. , 3. , 0. ]) >> >> ********************************************************************** >> File >> "/usr/local/python2.6.6/lib/python2.6/site-packages/numpy/lib/tests/test_polynomial.py", >> line 64, in test_polynomial >> Failed example: >> p.integ(5) >> Expected: >> poly1d([ 0.00039683, 0.00277778, 0.025 , 0. , 0. >> , >> 0. , 0. , 0. ]) >> Got: >> poly1d([ 0. , 0.003, 0.025, 0. , 0. , 0. , 0. , 0. >> ]) >> >> >> raise AssertionError("Some doctests failed:\n%s" % >> "\n".join(['**********************************************************************\nFile >> "/usr/local/python2.6.6/lib/python2.6/site-packages/numpy/lib/tests/test_polynomial.py", >> line 38, in test_polynomial\nFailed example:\n p / q\nExpected:\n >> (poly1d([ 0.33333333]), poly1d([ 1.33333333, 2.66666667]))\nGot:\n >> (poly1d([ 0.333]), poly1d([ 1.333, 2.667]))\n', >> '**********************************************************************\nFile >> "/usr/local/python2.6.6/lib/python2.6/site-packages/numpy/lib/tests/test_polynomial.py", >> line 60, in test_polynomial\nFailed example:\n p.integ()\nExpected:\n >> poly1d([ 0.33333333, 1. , 3. , 0. ])\nGot:\n >> poly1d([ 0.333, 1. , 3. , 0. ])\n', >> '**********************************************************************\nFile >> "/usr/local/python2.6.6/lib/python2.6/site-packages/numpy/lib/tests/test_polynomial.py", >> line 62, in test_polynomial\nFailed example:\n p.integ(1)\nExpected:\n >> poly1d([ 0.33333333, 1. , 3. , 0. ])\nGot:\n >> poly1d([ 0.333, 1. , 3. , 0. ])\n', >> '**********************************************************************\nFile >> "/usr/local/python2.6.6/lib/python2.6/site-packages/numpy/lib/tests/test_polynomial.py", >> line 64, in test_polynomial\nFailed example:\n p.integ(5)\nExpected:\n >> poly1d([ 0.00039683, 0.00277778, 0.025 , 0. , 0. >> ,\n 0. , 0. , 0. ])\nGot:\n poly1d([ >> 0. , 0.003, 0.025, 0. , 0. , 0. , 0. , 0. ])\n'])) >> >> >> ---------------------------------------------------------------------- >> Ran 2966 tests in 9.896s >> >> FAILED (KNOWNFAIL=4, failures=1) >> >> >> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> >> > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Fri Oct 8 03:04:05 2010 From: matthew.brett at gmail.com (Matthew Brett) Date: Fri, 8 Oct 2010 00:04:05 -0700 Subject: [Numpy-discussion] Assigning complex value to real array In-Reply-To: <4CAE7FE7.7030509@zen-pharaohs.com> References: <29902859.post@talk.nabble.com> <4CAD5592.4010409@zen-pharaohs.com> <4CADF069.5030705@zen-pharaohs.com> <1286470907.3425.33.camel@talisman> <4CAE4DE7.20403@zen-pharaohs.com> <4CAE7FE7.7030509@zen-pharaohs.com> Message-ID: Hi, >> 'Talk is cheap, show me the code' . > > Yes, let's. > > First we want to initialize memory mapped arrays which will be used for > the variables. This python script does that: Ah - no - sorry - I was suggesting you write an implementation of the object you want, in numpy. I am sure that was not your intention, but so far it is possible to read your emails as suggesting that someone else does that work for you, and I don't think there's any chance that's going to happen. Best, Matthew From ioan.ferencik at tkk.fi Fri Oct 8 03:18:06 2010 From: ioan.ferencik at tkk.fi (Ioan Ferencik) Date: Fri, 8 Oct 2010 10:18:06 +0300 Subject: [Numpy-discussion] ndarray of object dtype In-Reply-To: <15612_1286497486_ZZ0L9Y004463TAOP.00_AANLkTikFJgZuouZh_AAtcK=sFV6Wk4DQ0hWi1KNj84KW@mail.gmail.com> References: <20101004084120.7bmxuk1dcsc0coko@webmail3.tkk.fi> <15612_1286204190_ZZ0L9R0038DTI5HY.00_AANLkTinopyssMBw-wHgsdmgVXGijBS-TVGm8=YQLcOzp@mail.gmail.com> <20101007180919.2etr01a9k44kcwks@webmail3.tkk.fi> <15612_1286497486_ZZ0L9Y004463TAOP.00_AANLkTikFJgZuouZh_AAtcK=sFV6Wk4DQ0hWi1KNj84KW@mail.gmail.com> Message-ID: <20101008101806.935r53mio40k8cko@webmail3.tkk.fi> thanks, it was actually obvious and I figured it out minutes later I sent the message. Thanks anyway. Quoting Robert Kern : > On Thu, Oct 7, 2010 at 10:09, Ioan Ferencik wrote: >> Hello Robert, >> >> I dare to bother you again with some ?questions. >> >> this time I have a numpy array with fields >> ar = array([(1.0, 2.0, 3, 4), (2.0, 3.0, 4, 5)], dtype={'names': >> ['q','wl','cssid','br'], 'formats':['f4', 'f4', 'i4', 'i4'], >> 'offsets': [0, 4, 8, 12]}, order='F') >> >> on C API I want to match this struct >> typedef struct val1{ >> ? ? ? ?float q; >> ? ? ? ?float wl; >> ? ? ? ?int cssid; >> ? ? ? ?int br; >> }hm1dval1; >> >> to an element of this array >> I get the array object, i can see the fields. The type of the array >> elements is Pyarray_VOID >> >> however following code gives me a segfault >> >> hm1dval1 **s = PyArray_DATA(ao); > > Since this is *not* an object array but an array of hm1dval1 structs, > you declare it like so: > > hm1dval1 *s = PyArray_DATA(ao); > > -- > 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 at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > Ioan Ferencik PhD student Aalto University School of Science and Technology Faculty Of Civil and Env. Engineering Lahti Center Tel: +358505122707 From chris at simplistix.co.uk Fri Oct 8 05:10:10 2010 From: chris at simplistix.co.uk (Chris Withers) Date: Fri, 08 Oct 2010 10:10:10 +0100 Subject: [Numpy-discussion] ufunc.accumulate question In-Reply-To: References: <4CAB1FC2.4030601@simplistix.co.uk> Message-ID: <4CAEDFF2.7030308@simplistix.co.uk> Thanks for this, very informative! :-) Chris On 06/10/2010 17:35, Friedrich Romstedt wrote: > 2010/10/5 Chris Withers: >> Hi All, >> >> I can't find any docs on this behavior. >> >> So, I have a python function. To keep it simple, lets just do addition: >> >> def add(x,y): >> print x,y >> retun x+y >> >> So, I can turn this into a ufunc as follows: >> >> uadd = np.frompyfunc(add,2,1) > > As a side remark, note that this will always return dtype=numpy.object > arrays. Maybe numpy.vectorize() is more appropriate for your > use-case. > >> Now, I can apply it to an array: >> >> >>> uadd.accumulate(np.arange(3,10)) >> 3 4 >> 7 5 >> 12 6 >> 18 7 >> 25 8 >> 33 9 >> array([3, 7, 12, 18, 25, 33, 42], dtype=object) >> >> Okay, but where did the initial 3 come from? >> http://docs.scipy.org/doc/numpy/reference/generated/numpy.ufunc.accumulate.html#numpy.ufunc.accumulate >> suggests that: >> >> r = np.empty(len(A)) >> t = op.identity # op = the ufunc being applied to A's elements >> for i in xrange(len(A)): >> t = op(t, A[i]) >> r[i] = t >> return r > > I see from the behaviour, that the implementation makes use of the > following behaviour of the identity ``op.identity`` with respect to > ``op``: > >>>> op(op.identity, X) == X > True > > So the implementation acts in agnosticism of ``op.identity`` by > assuming that the first call of ``t = op(t, A[i])`` in your example > will just yield ``A[0]``, while i == 0. > > This is the work flow: > > [ t = op.identity ] # in brackets because it cannot be executed, it's > pseudo-code > > i = 0 > ===== > t = op(t, A[0]) = A[0] > r[0] = t = A[0] > > i = 1 > ===== > t = op(t, A[1]) = op(A[0], A[1]) > r[1] = t > > i = 2 > ===== > t = op(t, A[2]) = op(op(A[0], A[1]), A[2]) > r[2] = t > > and so on ... clear now? > > Friedrich > >> ...but: >> >> >>> print uadd.identity >> None > > It's simply not set, and will also not be used. > >> ...and: >> >> >>> add(None,3) >> None 3 >> Traceback (most recent call last): >> File "", line 1, in >> File "", line 3, in add >> TypeError: unsupported operand type(s) for +: 'NoneType' and 'int' > > As said, the code in the docs is just pseudo-code, it's not the actual > (C?) implementation, it just has the same semantics. > >> So, where is the reason that the 3 ends up in the output array documented? >> >> Also, what if I want to specify the identity of my newly created ufunc? >> I have a case where I want to specify it as zero: >> >> >>> uadd.identity = 0 >> Traceback (most recent call last): >> File "", line 1, in >> AttributeError: attribute 'identity' of 'numpy.ufunc' objects is not >> writable > > I think you have to write an own class for this. You cannot subclass > numpy.ufunc ("it's not an acceptable base class" Python says). > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk From goodfellow.ian at gmail.com Fri Oct 8 09:47:47 2010 From: goodfellow.ian at gmail.com (Ian Goodfellow) Date: Fri, 8 Oct 2010 09:47:47 -0400 Subject: [Numpy-discussion] Help building numpy Message-ID: Can anyone explain how to get numpy to recognize atlas? I have atlas built and installed, and I put what I thought should be sufficient, based on numpy's INSTALL.TXT, to make numpy use atlas in my site.cfg then ran python setup.py install. The resulting build is incredibly slow. Multiplying a 1,000 x 1,000 matrix takes 8 seconds. The default packages take .8 . On a computer at work with a similar but slower cpu to mine, it only takes .2, so I know I should be able to get a lot more speed out of numpy. This is my site.cfg: [atlas] atlas_libs = lapack, f77blas, cblas, atlas [DEFAULT] library_dirs = /usr/local/atlas/lib include_dir = /usr/local/atlas/include Thanks in advance, Ian -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.root at ou.edu Fri Oct 8 10:06:40 2010 From: ben.root at ou.edu (Benjamin Root) Date: Fri, 8 Oct 2010 09:06:40 -0500 Subject: [Numpy-discussion] Help building numpy In-Reply-To: References: Message-ID: On Fri, Oct 8, 2010 at 8:47 AM, Ian Goodfellow wrote: > Can anyone explain how to get numpy to recognize atlas? I have atlas built > and installed, and I put what I thought should be sufficient, based on > numpy's INSTALL.TXT, to make numpy use atlas in my site.cfg then ran python > setup.py install. The resulting build is incredibly slow. Multiplying a > 1,000 x 1,000 matrix takes 8 seconds. The default packages take .8 . On a > computer at work with a similar but slower cpu to mine, it only takes .2, so > I know I should be able to get a lot more speed out of numpy. > > This is my site.cfg: > > [atlas] > atlas_libs = lapack, f77blas, cblas, atlas > > [DEFAULT] > library_dirs = /usr/local/atlas/lib > include_dir = /usr/local/atlas/include > > Thanks in advance, > Ian > > Ian, it would be very helpful if you could post the output from the build of numpy. That log can tell us whether it found the libraries or not when building. Ben Root -------------- next part -------------- An HTML attachment was scrubbed... URL: From goodfellow.ian at gmail.com Fri Oct 8 10:40:50 2010 From: goodfellow.ian at gmail.com (Ian Goodfellow) Date: Fri, 8 Oct 2010 10:40:50 -0400 Subject: [Numpy-discussion] Help building numpy In-Reply-To: References: Message-ID: Is there a log file I should post or do you just mean to capture everything that setup.py prints to stdout? On Fri, Oct 8, 2010 at 10:06 AM, Benjamin Root wrote: > On Fri, Oct 8, 2010 at 8:47 AM, Ian Goodfellow wrote: > >> Can anyone explain how to get numpy to recognize atlas? I have atlas built >> and installed, and I put what I thought should be sufficient, based on >> numpy's INSTALL.TXT, to make numpy use atlas in my site.cfg then ran python >> setup.py install. The resulting build is incredibly slow. Multiplying a >> 1,000 x 1,000 matrix takes 8 seconds. The default packages take .8 . On a >> computer at work with a similar but slower cpu to mine, it only takes .2, so >> I know I should be able to get a lot more speed out of numpy. >> >> This is my site.cfg: >> >> [atlas] >> atlas_libs = lapack, f77blas, cblas, atlas >> >> [DEFAULT] >> library_dirs = /usr/local/atlas/lib >> include_dir = /usr/local/atlas/include >> >> Thanks in advance, >> Ian >> >> > Ian, it would be very helpful if you could post the output from the build > of numpy. That log can tell us whether it found the libraries or not when > building. > > Ben Root > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Fri Oct 8 10:41:50 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Fri, 8 Oct 2010 22:41:50 +0800 Subject: [Numpy-discussion] Schedule for 1.5.1? In-Reply-To: <4CAE0671.60705@amolf.nl> References: <4CAE0671.60705@amolf.nl> Message-ID: On Fri, Oct 8, 2010 at 1:42 AM, Nils Becker wrote: > Hi, > > what about the normed=True bug in numpy.histogram? It was discussed here > a while ago, and fixed (although i did not find it on the tracker), but > the message > > > > suggests it just missed 1.5.0? I don't have 1.5 installed, so I can't > check right now. > It did. Changesets are r8672, r8674, r8678. > > sorry to mention my personal pet bug, but maybe it's also a candidate? > > I don't think so, because it breaks backwards compatibility as Robert pointed out: http://thread.gmane.org/gmane.comp.python.numeric.general/39746/focus=40089 The preferred solution by most people in that thread, adding a "density" keyword, has also not been implemented. To not forget about it I opened a ticket for this, http://projects.scipy.org/numpy/ticket/1628. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Fri Oct 8 10:43:21 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Fri, 8 Oct 2010 22:43:21 +0800 Subject: [Numpy-discussion] Schedule for 1.5.1? In-Reply-To: <4CAE4BFA.8090503@onetel.net> References: <4CAE4BFA.8090503@onetel.net> Message-ID: On Fri, Oct 8, 2010 at 6:38 AM, Dr. David Kirkby wrote: > On 10/ 6/10 12:49 AM, Pauli Virtanen wrote: > > Hi, > > > > Should we set a date for a bugfix 1.5.1 release? There are some bugs that > > would be nice to sort out in the 1.5.x series: > > > > Any Python versions: > > > > - #1605 (Cython vs. PEP-3118 issue: raising exceptions with active > > cython buffers caused undefined behavior. Breaks Sage.) > > - #1617 (Ensure complex(np.longcomplex(...)) doesn't drop the imag part) > > - Fix doc build > > I'd like to see the 'isfinite' bug in 1.5.1, which is #1625 and has been > committed I believe. > > Pauli already backported this fix: http://github.com/numpy/numpy/commit/8e0d299b Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsouthey at gmail.com Fri Oct 8 10:53:43 2010 From: bsouthey at gmail.com (Bruce Southey) Date: Fri, 08 Oct 2010 09:53:43 -0500 Subject: [Numpy-discussion] Help building numpy In-Reply-To: References: Message-ID: <4CAF3077.1080808@gmail.com> On 10/08/2010 09:06 AM, Benjamin Root wrote: > On Fri, Oct 8, 2010 at 8:47 AM, Ian Goodfellow > > wrote: > > Can anyone explain how to get numpy to recognize atlas? I have > atlas built and installed, and I put what I thought should be > sufficient, based on numpy's INSTALL.TXT, to make numpy use atlas > in my site.cfg then ran python setup.py install. The resulting > build is incredibly slow. Multiplying a 1,000 x 1,000 matrix takes > 8 seconds. The default packages take .8 . On a computer at work > with a similar but slower cpu to mine, it only takes .2, so I know > I should be able to get a lot more speed out of numpy. > > This is my site.cfg: > > [atlas] > atlas_libs = lapack, f77blas, cblas, atlas > > [DEFAULT] > library_dirs = /usr/local/atlas/lib > include_dir = /usr/local/atlas/include > > Thanks in advance, > Ian > > > Ian, it would be very helpful if you could post the output from the > build of numpy. That log can tell us whether it found the libraries > or not when building. > > Ben Root > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion I do not use a 'site.cfg' even though I build my own numpy but use the standard Fedora (13) packages for atlas. So try it without defining it - remove the installation and build directories first! Can you please provide the operating system (including 32bit or 64 bit), Python version and numpy version? What is the output of the numpy function 'show_config()'? I added mine below from a 64-bit linux system so you can see that numpy is looking in the '/usr/lib64' directory. Bruce >>> import numpy as np >>> np.show_config() atlas_threads_info: libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas'] library_dirs = ['/usr/lib64/atlas'] define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')] language = f77 include_dirs = ['/usr/include'] blas_opt_info: libraries = ['ptf77blas', 'ptcblas', 'atlas'] library_dirs = ['/usr/lib64/atlas'] define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')] language = c include_dirs = ['/usr/include'] atlas_blas_threads_info: libraries = ['ptf77blas', 'ptcblas', 'atlas'] library_dirs = ['/usr/lib64/atlas'] define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')] language = c include_dirs = ['/usr/include'] lapack_opt_info: libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas'] library_dirs = ['/usr/lib64/atlas'] define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')] language = f77 include_dirs = ['/usr/include'] lapack_mkl_info: NOT AVAILABLE blas_mkl_info: NOT AVAILABLE mkl_info: NOT AVAILABLE >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From goodfellow.ian at gmail.com Fri Oct 8 11:01:28 2010 From: goodfellow.ian at gmail.com (Ian Goodfellow) Date: Fri, 8 Oct 2010 11:01:28 -0400 Subject: [Numpy-discussion] Help building numpy In-Reply-To: <4CAF3077.1080808@gmail.com> References: <4CAF3077.1080808@gmail.com> Message-ID: I'm using 64-bit Ubuntu 10.04. I originally tried building without site.cfg and got the same result. After that I removed the installation and the numpy/build directory and tried again with site.cfg. Here's the otuput of my show_config(). Does this mean it's actually using atlas? I ran 'make time' in the atlas directory and got higher % of clock speed numbers than the reference so I would be surprised if my atlas build is this slow. atlas_threads_info: libraries = ['lapack', 'lapack', 'f77blas', 'cblas', 'atlas'] library_dirs = ['/usr/local/atlas/lib'] define_macros = [('ATLAS_INFO', '"\\"None\\""')] language = f77 include_dirs = ['/usr/include'] blas_opt_info: libraries = ['lapack', 'f77blas', 'cblas', 'atlas'] library_dirs = ['/usr/local/atlas/lib'] define_macros = [('ATLAS_INFO', '"\\"None\\""')] language = c include_dirs = ['/usr/include'] atlas_blas_threads_info: libraries = ['lapack', 'f77blas', 'cblas', 'atlas'] library_dirs = ['/usr/local/atlas/lib'] define_macros = [('ATLAS_INFO', '"\\"None\\""')] language = c include_dirs = ['/usr/include'] lapack_opt_info: libraries = ['lapack', 'lapack', 'f77blas', 'cblas', 'atlas'] library_dirs = ['/usr/local/atlas/lib'] define_macros = [('ATLAS_INFO', '"\\"None\\""')] language = f77 include_dirs = ['/usr/include'] lapack_mkl_info: NOT AVAILABLE blas_mkl_info: NOT AVAILABLE mkl_info: NOT AVAILABLE On Fri, Oct 8, 2010 at 10:53 AM, Bruce Southey wrote: > On 10/08/2010 09:06 AM, Benjamin Root wrote: > > On Fri, Oct 8, 2010 at 8:47 AM, Ian Goodfellow wrote: > >> Can anyone explain how to get numpy to recognize atlas? I have atlas built >> and installed, and I put what I thought should be sufficient, based on >> numpy's INSTALL.TXT, to make numpy use atlas in my site.cfg then ran python >> setup.py install. The resulting build is incredibly slow. Multiplying a >> 1,000 x 1,000 matrix takes 8 seconds. The default packages take .8 . On a >> computer at work with a similar but slower cpu to mine, it only takes .2, so >> I know I should be able to get a lot more speed out of numpy. >> >> This is my site.cfg: >> >> [atlas] >> atlas_libs = lapack, f77blas, cblas, atlas >> >> [DEFAULT] >> library_dirs = /usr/local/atlas/lib >> include_dir = /usr/local/atlas/include >> >> Thanks in advance, >> Ian >> >> > Ian, it would be very helpful if you could post the output from the build > of numpy. That log can tell us whether it found the libraries or not when > building. > > Ben Root > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.orghttp://mail.scipy.org/mailman/listinfo/numpy-discussion > > > I do not use a 'site.cfg' even though I build my own numpy but use the > standard Fedora (13) packages for atlas. So try it without defining it - > remove the installation and build directories first! > > Can you please provide the operating system (including 32bit or 64 bit), > Python version and numpy version? > > What is the output of the numpy function 'show_config()'? > I added mine below from a 64-bit linux system so you can see that numpy is > looking in the '/usr/lib64' directory. > > Bruce > > >>> import numpy as np > >>> np.show_config() > atlas_threads_info: > libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas'] > library_dirs = ['/usr/lib64/atlas'] > define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')] > language = f77 > include_dirs = ['/usr/include'] > blas_opt_info: > libraries = ['ptf77blas', 'ptcblas', 'atlas'] > library_dirs = ['/usr/lib64/atlas'] > define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')] > language = c > include_dirs = ['/usr/include'] > atlas_blas_threads_info: > libraries = ['ptf77blas', 'ptcblas', 'atlas'] > library_dirs = ['/usr/lib64/atlas'] > define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')] > language = c > include_dirs = ['/usr/include'] > lapack_opt_info: > libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas'] > library_dirs = ['/usr/lib64/atlas'] > define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')] > language = f77 > include_dirs = ['/usr/include'] > lapack_mkl_info: > NOT AVAILABLE > blas_mkl_info: > NOT AVAILABLE > mkl_info: > NOT AVAILABLE > >>> > > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Fri Oct 8 11:11:42 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Fri, 8 Oct 2010 09:11:42 -0600 Subject: [Numpy-discussion] Schedule for 1.5.1? In-Reply-To: References: <4CADD107.10001@gmail.com> Message-ID: On Thu, Oct 7, 2010 at 8:16 AM, Ralf Gommers wrote: > > > On Thu, Oct 7, 2010 at 10:00 PM, Pierre GM wrote: > >> Just asking, >> Should I backport some bugs that were corrected in 2.0 for numpy.ma ? I >> don't have any particular in mind, but I'm sure there must be some... >> >> That would be helpful. Please backport any bug fixes that you think are > important. > > IIRC, there was also a fix that Josef wanted in one of the stats functions before 1.5 but I don't remember which. Josef? Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Fri Oct 8 11:24:24 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Fri, 8 Oct 2010 23:24:24 +0800 Subject: [Numpy-discussion] DEV_README.txt update, SVN -> git In-Reply-To: References: Message-ID: On Thu, Oct 7, 2010 at 8:10 PM, Peter < numpy-discussion at maubp.freeserve.co.uk> wrote: > Just FYI: > > The DEV_README.txt file needs a trivial update to talk about git not SVN > > Thanks, fixed in commit a8441313. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsouthey at gmail.com Fri Oct 8 11:49:21 2010 From: bsouthey at gmail.com (Bruce Southey) Date: Fri, 08 Oct 2010 10:49:21 -0500 Subject: [Numpy-discussion] Help building numpy In-Reply-To: References: <4CAF3077.1080808@gmail.com> Message-ID: <4CAF3D81.2050001@gmail.com> On 10/08/2010 10:01 AM, Ian Goodfellow wrote: > I'm using 64-bit Ubuntu 10.04. I originally tried building without > site.cfg and got the same result. After that I removed the > installation and the numpy/build directory and tried again with site.cfg. > > Here's the otuput of my show_config(). Does this mean it's actually > using atlas? I ran 'make time' in the atlas directory and got higher % > of clock speed numbers than the reference so I would be surprised if > my atlas build is this slow. > > atlas_threads_info: > libraries = ['lapack', 'lapack', 'f77blas', 'cblas', 'atlas'] > library_dirs = ['/usr/local/atlas/lib'] > define_macros = [('ATLAS_INFO', '"\\"None\\""')] > language = f77 > include_dirs = ['/usr/include'] > blas_opt_info: > libraries = ['lapack', 'f77blas', 'cblas', 'atlas'] > library_dirs = ['/usr/local/atlas/lib'] > define_macros = [('ATLAS_INFO', '"\\"None\\""')] > language = c > include_dirs = ['/usr/include'] > atlas_blas_threads_info: > libraries = ['lapack', 'f77blas', 'cblas', 'atlas'] > library_dirs = ['/usr/local/atlas/lib'] > define_macros = [('ATLAS_INFO', '"\\"None\\""')] > language = c > include_dirs = ['/usr/include'] > lapack_opt_info: > libraries = ['lapack', 'lapack', 'f77blas', 'cblas', 'atlas'] > library_dirs = ['/usr/local/atlas/lib'] > define_macros = [('ATLAS_INFO', '"\\"None\\""')] > language = f77 > include_dirs = ['/usr/include'] > lapack_mkl_info: > NOT AVAILABLE > blas_mkl_info: > NOT AVAILABLE > mkl_info: > NOT AVAILABLE > > > On Fri, Oct 8, 2010 at 10:53 AM, Bruce Southey > wrote: > > On 10/08/2010 09:06 AM, Benjamin Root wrote: >> On Fri, Oct 8, 2010 at 8:47 AM, Ian Goodfellow >> > wrote: >> >> Can anyone explain how to get numpy to recognize atlas? I >> have atlas built and installed, and I put what I thought >> should be sufficient, based on numpy's INSTALL.TXT, to make >> numpy use atlas in my site.cfg then ran python setup.py >> install. The resulting build is incredibly slow. Multiplying >> a 1,000 x 1,000 matrix takes 8 seconds. The default packages >> take .8 . On a computer at work with a similar but slower cpu >> to mine, it only takes .2, so I know I should be able to get >> a lot more speed out of numpy. >> >> This is my site.cfg: >> >> [atlas] >> atlas_libs = lapack, f77blas, cblas, atlas >> >> [DEFAULT] >> library_dirs = /usr/local/atlas/lib >> include_dir = /usr/local/atlas/include >> >> Thanks in advance, >> Ian >> >> >> Ian, it would be very helpful if you could post the output from >> the build of numpy. That log can tell us whether it found the >> libraries or not when building. >> >> Ben Root >> >> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion > > I do not use a 'site.cfg' even though I build my own numpy but use > the standard Fedora (13) packages for atlas. So try it without > defining it - remove the installation and build directories first! > > Can you please provide the operating system (including 32bit or 64 > bit), Python version and numpy version? > > What is the output of the numpy function 'show_config()'? > I added mine below from a 64-bit linux system so you can see that > numpy is looking in the '/usr/lib64' directory. > > Bruce > > >>> import numpy as np > >>> np.show_config() > atlas_threads_info: > libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas'] > library_dirs = ['/usr/lib64/atlas'] > define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')] > language = f77 > include_dirs = ['/usr/include'] > blas_opt_info: > libraries = ['ptf77blas', 'ptcblas', 'atlas'] > library_dirs = ['/usr/lib64/atlas'] > define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')] > language = c > include_dirs = ['/usr/include'] > atlas_blas_threads_info: > libraries = ['ptf77blas', 'ptcblas', 'atlas'] > library_dirs = ['/usr/lib64/atlas'] > define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')] > language = c > include_dirs = ['/usr/include'] > lapack_opt_info: > libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas'] > library_dirs = ['/usr/lib64/atlas'] > define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')] > language = f77 > include_dirs = ['/usr/include'] > lapack_mkl_info: > NOT AVAILABLE > blas_mkl_info: > NOT AVAILABLE > mkl_info: > NOT AVAILABLE > >>> > > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion It appears to finding something but I do not know enough about that aspect. I presume that you installed your own version of atlas since you are using /usr/local. So you need to be careful of the flags used especially that it is 64-bit and uses the appropriate SSE instructions for your processor. For example, on my system: $ file -L /usr/lib64/atlas/libatlas.so /usr/lib64/atlas/libatlas.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped Can you please provide the code you are using for timing for the 'slow' system? By the way, there was this thread: 'HOWTO build NumPy without external math libs' http://mail.scipy.org/pipermail/numpy-discussion/2010-July/051513.html BLAS=None LAPACK=None ATLAS=None python setup.py build Bruce -------------- next part -------------- An HTML attachment was scrubbed... URL: From goodfellow.ian at gmail.com Fri Oct 8 11:58:26 2010 From: goodfellow.ian at gmail.com (Ian Goodfellow) Date: Fri, 8 Oct 2010 11:58:26 -0400 Subject: [Numpy-discussion] Help building numpy In-Reply-To: <4CAF3D81.2050001@gmail.com> References: <4CAF3077.1080808@gmail.com> <4CAF3D81.2050001@gmail.com> Message-ID: Here's the output on my atlas library: file -L /usr/local/atlas/lib/libatlas.so /usr/local/atlas/lib/libatlas.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped It looks mostly the same as yours except it says "not stripped" while yours says "stripped." Do you know what that means? Here's my timing code (but the difference between installations is pretty obvious even without a timer, 8 full seconds on my machine versus .2 seconds on a slower machine at work): import numpy as N import time rng = N.random.RandomState([0,1,2]) A = rng.randn(1000,1000) t1 = time.time(); x = N.dot(A,A); t2 = time.time() print t2-t1 On Fri, Oct 8, 2010 at 11:49 AM, Bruce Southey wrote: > On 10/08/2010 10:01 AM, Ian Goodfellow wrote: > > I'm using 64-bit Ubuntu 10.04. I originally tried building without site.cfg > and got the same result. After that I removed the installation and the > numpy/build directory and tried again with site.cfg. > > Here's the otuput of my show_config(). Does this mean it's actually using > atlas? I ran 'make time' in the atlas directory and got higher % of clock > speed numbers than the reference so I would be surprised if my atlas build > is this slow. > > atlas_threads_info: > libraries = ['lapack', 'lapack', 'f77blas', 'cblas', 'atlas'] > library_dirs = ['/usr/local/atlas/lib'] > define_macros = [('ATLAS_INFO', '"\\"None\\""')] > language = f77 > include_dirs = ['/usr/include'] > blas_opt_info: > libraries = ['lapack', 'f77blas', 'cblas', 'atlas'] > library_dirs = ['/usr/local/atlas/lib'] > define_macros = [('ATLAS_INFO', '"\\"None\\""')] > language = c > include_dirs = ['/usr/include'] > atlas_blas_threads_info: > libraries = ['lapack', 'f77blas', 'cblas', 'atlas'] > library_dirs = ['/usr/local/atlas/lib'] > define_macros = [('ATLAS_INFO', '"\\"None\\""')] > language = c > include_dirs = ['/usr/include'] > lapack_opt_info: > libraries = ['lapack', 'lapack', 'f77blas', 'cblas', 'atlas'] > library_dirs = ['/usr/local/atlas/lib'] > define_macros = [('ATLAS_INFO', '"\\"None\\""')] > language = f77 > include_dirs = ['/usr/include'] > lapack_mkl_info: > NOT AVAILABLE > blas_mkl_info: > NOT AVAILABLE > mkl_info: > NOT AVAILABLE > > > On Fri, Oct 8, 2010 at 10:53 AM, Bruce Southey wrote: > >> On 10/08/2010 09:06 AM, Benjamin Root wrote: >> >> On Fri, Oct 8, 2010 at 8:47 AM, Ian Goodfellow > > wrote: >> >>> Can anyone explain how to get numpy to recognize atlas? I have atlas >>> built and installed, and I put what I thought should be sufficient, based on >>> numpy's INSTALL.TXT, to make numpy use atlas in my site.cfg then ran python >>> setup.py install. The resulting build is incredibly slow. Multiplying a >>> 1,000 x 1,000 matrix takes 8 seconds. The default packages take .8 . On a >>> computer at work with a similar but slower cpu to mine, it only takes .2, so >>> I know I should be able to get a lot more speed out of numpy. >>> >>> This is my site.cfg: >>> >>> [atlas] >>> atlas_libs = lapack, f77blas, cblas, atlas >>> >>> [DEFAULT] >>> library_dirs = /usr/local/atlas/lib >>> include_dir = /usr/local/atlas/include >>> >>> Thanks in advance, >>> Ian >>> >>> >> Ian, it would be very helpful if you could post the output from the build >> of numpy. That log can tell us whether it found the libraries or not when >> building. >> >> Ben Root >> >> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at scipy.orghttp://mail.scipy.org/mailman/listinfo/numpy-discussion >> >> >> I do not use a 'site.cfg' even though I build my own numpy but use the >> standard Fedora (13) packages for atlas. So try it without defining it - >> remove the installation and build directories first! >> >> Can you please provide the operating system (including 32bit or 64 bit), >> Python version and numpy version? >> >> What is the output of the numpy function 'show_config()'? >> I added mine below from a 64-bit linux system so you can see that numpy is >> looking in the '/usr/lib64' directory. >> >> Bruce >> >> >>> import numpy as np >> >>> np.show_config() >> atlas_threads_info: >> libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas'] >> library_dirs = ['/usr/lib64/atlas'] >> define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')] >> language = f77 >> include_dirs = ['/usr/include'] >> blas_opt_info: >> libraries = ['ptf77blas', 'ptcblas', 'atlas'] >> library_dirs = ['/usr/lib64/atlas'] >> define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')] >> language = c >> include_dirs = ['/usr/include'] >> atlas_blas_threads_info: >> libraries = ['ptf77blas', 'ptcblas', 'atlas'] >> library_dirs = ['/usr/lib64/atlas'] >> define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')] >> language = c >> include_dirs = ['/usr/include'] >> lapack_opt_info: >> libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas'] >> library_dirs = ['/usr/lib64/atlas'] >> define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')] >> language = f77 >> include_dirs = ['/usr/include'] >> lapack_mkl_info: >> NOT AVAILABLE >> blas_mkl_info: >> NOT AVAILABLE >> mkl_info: >> NOT AVAILABLE >> >>> >> >> >> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> >> > > _______________________________________________ > NumPy-Discussion mailing listNumPy-Discussion at scipy.orghttp://mail.scipy.org/mailman/listinfo/numpy-discussion > > > It appears to finding something but I do not know enough about that aspect. > > I presume that you installed your own version of atlas since you are using > /usr/local. So you need to be careful of the flags used especially that it > is 64-bit and uses the appropriate SSE instructions for your processor. For > example, on my system: > > $ file -L /usr/lib64/atlas/libatlas.so > /usr/lib64/atlas/libatlas.so: ELF 64-bit LSB shared object, x86-64, version > 1 (SYSV), dynamically linked, stripped > > Can you please provide the code you are using for timing for the 'slow' > system? > > By the way, there was this thread: > 'HOWTO build NumPy without external math libs' > http://mail.scipy.org/pipermail/numpy-discussion/2010-July/051513.html > > BLAS=None LAPACK=None ATLAS=None python setup.py build > > > Bruce > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Fri Oct 8 12:12:36 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Fri, 8 Oct 2010 12:12:36 -0400 Subject: [Numpy-discussion] Schedule for 1.5.1? In-Reply-To: References: <4CADD107.10001@gmail.com> Message-ID: On Fri, Oct 8, 2010 at 11:11 AM, Charles R Harris wrote: > > > On Thu, Oct 7, 2010 at 8:16 AM, Ralf Gommers > wrote: >> >> >> On Thu, Oct 7, 2010 at 10:00 PM, Pierre GM wrote: >>> >>> Just asking, >>> Should I backport some bugs that were corrected in 2.0 for numpy.ma ? I >>> don't have any particular in mind, but I'm sure there must be some... >>> >> That would be helpful. Please backport any bug fixes that you think are >> important. >> > > IIRC, there was also a fix that Josef wanted in one of the stats functions > before 1.5 but I don't remember which. Josef? Not sure, The only things that I remember right now is that Alan wanted to have ddof instead of bias in cov for consistency in names across functions, and the usual >>> np.nansum([]) 1.#QNAN >>> np.nansum([np.nan]) 1.#QNAN Both will change current behavior and might need a depreciation cycle. I have to see if a search through the mailing list turns something up. Josef > > Chuck > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > From charlesr.harris at gmail.com Fri Oct 8 12:21:10 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Fri, 8 Oct 2010 10:21:10 -0600 Subject: [Numpy-discussion] Schedule for 1.5.1? In-Reply-To: References: <4CADD107.10001@gmail.com> Message-ID: On Fri, Oct 8, 2010 at 10:12 AM, wrote: > On Fri, Oct 8, 2010 at 11:11 AM, Charles R Harris > wrote: > > > > > > On Thu, Oct 7, 2010 at 8:16 AM, Ralf Gommers < > ralf.gommers at googlemail.com> > > wrote: > >> > >> > >> On Thu, Oct 7, 2010 at 10:00 PM, Pierre GM > wrote: > >>> > >>> Just asking, > >>> Should I backport some bugs that were corrected in 2.0 for numpy.ma ? > I > >>> don't have any particular in mind, but I'm sure there must be some... > >>> > >> That would be helpful. Please backport any bug fixes that you think are > >> important. > >> > > > > IIRC, there was also a fix that Josef wanted in one of the stats > functions > > before 1.5 but I don't remember which. Josef? > > Not sure, The only things that I remember right now is that Alan > wanted to have ddof instead of bias in cov for consistency in names > across functions, and the usual > > >>> np.nansum([]) > 1.#QNAN > >>> np.nansum([np.nan]) > 1.#QNAN > > Both will change current behavior and might need a depreciation cycle. > > I have to see if a search through the mailing list turns something up. > > I think it was something about Pareto... Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsouthey at gmail.com Fri Oct 8 12:35:57 2010 From: bsouthey at gmail.com (Bruce Southey) Date: Fri, 08 Oct 2010 11:35:57 -0500 Subject: [Numpy-discussion] Help building numpy In-Reply-To: References: <4CAF3077.1080808@gmail.com> <4CAF3D81.2050001@gmail.com> Message-ID: <4CAF486D.4020004@gmail.com> On 10/08/2010 10:58 AM, Ian Goodfellow wrote: > Here's the output on my atlas library: > file -L /usr/local/atlas/lib/libatlas.so > /usr/local/atlas/lib/libatlas.so: ELF 64-bit LSB shared object, > x86-64, version 1 (SYSV), dynamically linked, not stripped > > It looks mostly the same as yours except it says "not stripped" while > yours says "stripped." Do you know what that means? > > Here's my timing code (but the difference between installations is > pretty obvious even without a timer, 8 full seconds on my machine > versus .2 seconds on a slower machine at work): > > import numpy as N > import time > rng = N.random.RandomState([0,1,2]) > A = rng.randn(1000,1000) > t1 = time.time(); x = N.dot(A,A); t2 = time.time() > print t2-t1 > > > > > On Fri, Oct 8, 2010 at 11:49 AM, Bruce Southey > wrote: > > On 10/08/2010 10:01 AM, Ian Goodfellow wrote: >> I'm using 64-bit Ubuntu 10.04. I originally tried building >> without site.cfg and got the same result. After that I removed >> the installation and the numpy/build directory and tried again >> with site.cfg. >> >> Here's the otuput of my show_config(). Does this mean it's >> actually using atlas? I ran 'make time' in the atlas directory >> and got higher % of clock speed numbers than the reference so I >> would be surprised if my atlas build is this slow. >> >> atlas_threads_info: >> libraries = ['lapack', 'lapack', 'f77blas', 'cblas', 'atlas'] >> library_dirs = ['/usr/local/atlas/lib'] >> define_macros = [('ATLAS_INFO', '"\\"None\\""')] >> language = f77 >> include_dirs = ['/usr/include'] >> blas_opt_info: >> libraries = ['lapack', 'f77blas', 'cblas', 'atlas'] >> library_dirs = ['/usr/local/atlas/lib'] >> define_macros = [('ATLAS_INFO', '"\\"None\\""')] >> language = c >> include_dirs = ['/usr/include'] >> atlas_blas_threads_info: >> libraries = ['lapack', 'f77blas', 'cblas', 'atlas'] >> library_dirs = ['/usr/local/atlas/lib'] >> define_macros = [('ATLAS_INFO', '"\\"None\\""')] >> language = c >> include_dirs = ['/usr/include'] >> lapack_opt_info: >> libraries = ['lapack', 'lapack', 'f77blas', 'cblas', 'atlas'] >> library_dirs = ['/usr/local/atlas/lib'] >> define_macros = [('ATLAS_INFO', '"\\"None\\""')] >> language = f77 >> include_dirs = ['/usr/include'] >> lapack_mkl_info: >> NOT AVAILABLE >> blas_mkl_info: >> NOT AVAILABLE >> mkl_info: >> NOT AVAILABLE >> >> >> On Fri, Oct 8, 2010 at 10:53 AM, Bruce Southey >> > wrote: >> >> On 10/08/2010 09:06 AM, Benjamin Root wrote: >>> On Fri, Oct 8, 2010 at 8:47 AM, Ian Goodfellow >>> > >>> wrote: >>> >>> Can anyone explain how to get numpy to recognize atlas? >>> I have atlas built and installed, and I put what I >>> thought should be sufficient, based on numpy's >>> INSTALL.TXT, to make numpy use atlas in my site.cfg then >>> ran python setup.py install. The resulting build is >>> incredibly slow. Multiplying a 1,000 x 1,000 matrix >>> takes 8 seconds. The default packages take .8 . On a >>> computer at work with a similar but slower cpu to mine, >>> it only takes .2, so I know I should be able to get a >>> lot more speed out of numpy. >>> >>> This is my site.cfg: >>> >>> [atlas] >>> atlas_libs = lapack, f77blas, cblas, atlas >>> >>> [DEFAULT] >>> library_dirs = /usr/local/atlas/lib >>> include_dir = /usr/local/atlas/include >>> >>> Thanks in advance, >>> Ian >>> >>> >>> Ian, it would be very helpful if you could post the output >>> from the build of numpy. That log can tell us whether it >>> found the libraries or not when building. >>> >>> Ben Root >>> >>> >>> _______________________________________________ >>> NumPy-Discussion mailing list >>> NumPy-Discussion at scipy.org >>> >>> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> >> I do not use a 'site.cfg' even though I build my own numpy >> but use the standard Fedora (13) packages for atlas. So try >> it without defining it - remove the installation and build >> directories first! >> >> Can you please provide the operating system (including 32bit >> or 64 bit), Python version and numpy version? >> >> What is the output of the numpy function 'show_config()'? >> I added mine below from a 64-bit linux system so you can see >> that numpy is looking in the '/usr/lib64' directory. >> >> Bruce >> >> >>> import numpy as np >> >>> np.show_config() >> atlas_threads_info: >> libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas'] >> library_dirs = ['/usr/lib64/atlas'] >> define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')] >> language = f77 >> include_dirs = ['/usr/include'] >> blas_opt_info: >> libraries = ['ptf77blas', 'ptcblas', 'atlas'] >> library_dirs = ['/usr/lib64/atlas'] >> define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')] >> language = c >> include_dirs = ['/usr/include'] >> atlas_blas_threads_info: >> libraries = ['ptf77blas', 'ptcblas', 'atlas'] >> library_dirs = ['/usr/lib64/atlas'] >> define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')] >> language = c >> include_dirs = ['/usr/include'] >> lapack_opt_info: >> libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas'] >> library_dirs = ['/usr/lib64/atlas'] >> define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')] >> language = f77 >> include_dirs = ['/usr/include'] >> lapack_mkl_info: >> NOT AVAILABLE >> blas_mkl_info: >> NOT AVAILABLE >> mkl_info: >> NOT AVAILABLE >> >>> >> >> >> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> >> >> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion > > It appears to finding something but I do not know enough about > that aspect. > > I presume that you installed your own version of atlas since you > are using /usr/local. So you need to be careful of the flags used > especially that it is 64-bit and uses the appropriate SSE > instructions for your processor. For example, on my system: > > $ file -L /usr/lib64/atlas/libatlas.so > /usr/lib64/atlas/libatlas.so: ELF 64-bit LSB shared object, > x86-64, version 1 (SYSV), dynamically linked, stripped > > Can you please provide the code you are using for timing for the > 'slow' system? > > By the way, there was this thread: > 'HOWTO build NumPy without external math libs' > http://mail.scipy.org/pipermail/numpy-discussion/2010-July/051513.html > > BLAS=None LAPACK=None ATLAS=None python setup.py build > > > Bruce > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion Don't use time! Use timeit. I suspect your build is using numerical libraries that have not been build correctly for your system. But I don't know anything about that. What are the flags used to build lapack and atlas? I told the lazy way of using timeit but may help you identify the slowness. To capture the output I use two files for stdout and stderr: $ python setup.py build > b.log 2>e.log $ python setup.py install # done as root 1) Using numpy built as: 'BLAS=None LAPACK=None ATLAS=None python setup.py build' $ python -m timeit -s "import numpy as N; rng = N.random.RandomState([0,1,2]) ; A = rng.randn(1000,1000); x = N.dot(A,A)" 100000000 loops, best of 3: 0.012 usec per loop 2) Using numpy built just without Atlas: 'ATLAS=None python setup.py build' $ python -m timeit -s "import numpy as N; rng = N.random.RandomState([0,1,2]) ; A = rng.randn(1000,1000); x = N.dot(A,A)" 100000000 loops, best of 3: 0.012 usec per loop 3) Using Atlas without dot: $ python -m timeit -s "import numpy as N; rng = N.random.RandomState([0,1,2]) ; A = rng.randn(1000,1000)" 100000000 loops, best of 3: 0.012 usec per loop 4) Using Atlas with dot: $ python -m timeit -s "import numpy as N; rng = N.random.RandomState([0,1,2]) ; A = rng.randn(1000,1000); x = N.dot(A,A)" 100000000 loops, best of 3: 0.0131 usec per loop Bruce -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Fri Oct 8 12:37:22 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Fri, 8 Oct 2010 12:37:22 -0400 Subject: [Numpy-discussion] Schedule for 1.5.1? In-Reply-To: References: <4CADD107.10001@gmail.com> Message-ID: On Fri, Oct 8, 2010 at 12:21 PM, Charles R Harris wrote: > > > On Fri, Oct 8, 2010 at 10:12 AM, wrote: >> >> On Fri, Oct 8, 2010 at 11:11 AM, Charles R Harris >> wrote: >> > >> > >> > On Thu, Oct 7, 2010 at 8:16 AM, Ralf Gommers >> > >> > wrote: >> >> >> >> >> >> On Thu, Oct 7, 2010 at 10:00 PM, Pierre GM >> >> wrote: >> >>> >> >>> Just asking, >> >>> Should I backport some bugs that were corrected in 2.0 for numpy.ma ? >> >>> I >> >>> don't have any particular in mind, but I'm sure there must be some... >> >>> >> >> That would be helpful. Please backport any bug fixes that you think are >> >> important. >> >> >> > >> > IIRC, there was also a fix that Josef wanted in one of the stats >> > functions >> > before 1.5 but I don't remember which. Josef? >> >> Not sure, The only things that I remember right now is that Alan >> wanted to have ddof instead of bias in cov for consistency in names >> across functions, and the usual >> >> >>> np.nansum([]) >> 1.#QNAN >> >>> np.nansum([np.nan]) >> 1.#QNAN >> >> Both will change current behavior and might need a depreciation cycle. >> >> I have to see if a search through the mailing list turns something up. >> > > I think it was something about Pareto... Ok I remember, Pareto is actually Lomax or Pareto second kind, and should be renamed. The proposal was to rename the current pareto to pareto2 and create a new pareto that corrects location by one. In the meantime I discovered that Lomax is actually nicer to work with than Pareto one, so it's mainly a question of terminology/names and documentation. Just calling it pareto is very misleading. Josef > > Chuck > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > From charlesr.harris at gmail.com Fri Oct 8 12:48:14 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Fri, 8 Oct 2010 10:48:14 -0600 Subject: [Numpy-discussion] Schedule for 1.5.1? In-Reply-To: References: <4CADD107.10001@gmail.com> Message-ID: On Fri, Oct 8, 2010 at 10:37 AM, wrote: > On Fri, Oct 8, 2010 at 12:21 PM, Charles R Harris > wrote: > > > > > > On Fri, Oct 8, 2010 at 10:12 AM, wrote: > >> > >> On Fri, Oct 8, 2010 at 11:11 AM, Charles R Harris > >> wrote: > >> > > >> > > >> > On Thu, Oct 7, 2010 at 8:16 AM, Ralf Gommers > >> > > >> > wrote: > >> >> > >> >> > >> >> On Thu, Oct 7, 2010 at 10:00 PM, Pierre GM > >> >> wrote: > >> >>> > >> >>> Just asking, > >> >>> Should I backport some bugs that were corrected in 2.0 for numpy.ma? > >> >>> I > >> >>> don't have any particular in mind, but I'm sure there must be > some... > >> >>> > >> >> That would be helpful. Please backport any bug fixes that you think > are > >> >> important. > >> >> > >> > > >> > IIRC, there was also a fix that Josef wanted in one of the stats > >> > functions > >> > before 1.5 but I don't remember which. Josef? > >> > >> Not sure, The only things that I remember right now is that Alan > >> wanted to have ddof instead of bias in cov for consistency in names > >> across functions, and the usual > >> > >> >>> np.nansum([]) > >> 1.#QNAN > >> >>> np.nansum([np.nan]) > >> 1.#QNAN > >> > >> Both will change current behavior and might need a depreciation cycle. > >> > >> I have to see if a search through the mailing list turns something up. > >> > > > > I think it was something about Pareto... > > Ok I remember, Pareto is actually Lomax or Pareto second kind, and > should be renamed. The proposal was to rename the current pareto to > pareto2 and create a new pareto that corrects location by one. > > In the meantime I discovered that Lomax is actually nicer to work with > than Pareto one, so it's mainly a question of terminology/names and > documentation. Just calling it pareto is very misleading. > > That doesn't sound like something for 1.5.1. Can you think through the naming issue and open a ticket so we can start rationalizing this for 2.0? I'm thinking having pareto1 and lomax, or maybe pareto1 and pareto2, and deprecating plain old pareto may be the way to go. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Fri Oct 8 13:10:10 2010 From: pav at iki.fi (Pauli Virtanen) Date: Fri, 8 Oct 2010 17:10:10 +0000 (UTC) Subject: [Numpy-discussion] Schedule for 1.5.1? References: <4CADD107.10001@gmail.com> Message-ID: Fri, 08 Oct 2010 10:48:14 -0600, Charles R Harris wrote: > On Fri, Oct 8, 2010 at 10:37 AM, wrote: [clip] >> Ok I remember, Pareto is actually Lomax or Pareto second kind, and >> should be renamed. The proposal was to rename the current pareto to >> pareto2 and create a new pareto that corrects location by one. >> >> In the meantime I discovered that Lomax is actually nicer to work with >> than Pareto one, so it's mainly a question of terminology/names and >> documentation. Just calling it pareto is very misleading. > > That doesn't sound like something for 1.5.1. Can you think through the > naming issue and open a ticket so we can start rationalizing this for > 2.0? I'm thinking having pareto1 and lomax, or maybe pareto1 and > pareto2, and deprecating plain old pareto may be the way to go. The documentation bit can be done, however, if there's a plan how to deal with it. -- Pauli Virtanen From goodfellow.ian at gmail.com Fri Oct 8 13:14:11 2010 From: goodfellow.ian at gmail.com (Ian Goodfellow) Date: Fri, 8 Oct 2010 13:14:11 -0400 Subject: [Numpy-discussion] Help building numpy In-Reply-To: <4CAF486D.4020004@gmail.com> References: <4CAF3077.1080808@gmail.com> <4CAF3D81.2050001@gmail.com> <4CAF486D.4020004@gmail.com> Message-ID: I don't think that the problem is my libraries. I think the problem is that numpy is not using them. If I build numpy with "BLAS=None LAPACK=None ATLAS=None sudo python setup.py install" my benchmark program takes 8 seconds, the same as if I build it with atlas supposedly included. I built lapack and atlas using this configure command for atlas (the new version of atlas will also build lapack for you): ../configure -b 64 -Fa alg -fPIC --with-netlib-lapack-tarfile=/home/ia3n/Libraries/lapack-3.1.1.tgz followed by make build, then in the directory the .a files, make shared, make ptshared, then back in the main build directory, make check, make time, sudo make install. I think the libraries were built fine because my numbers from 'make time' are mostly better than reference. The only one that is worse than reference is BIG_MM (which is why I am testing numpy by multiplying two big matrices) but there the difference is not that big. I get 733% of clock rate while the reference authors got 786.1. This difference is not big enough to explain numpy taking 8 seconds to multiply two 1k x 1k matrices. I think it is probably explainable by me having a faster CPU (mine is 2794 Mhz, reference was 2672), so memory-bound operations are not able to achieve quite as high a percentage of the clock rate. I don't understand what your timeit examples are doing. You get the same number printed out whether you do the matrix multiplication or not. How is it actually timing the matrix multiplication? In any case, if I run them on my machine, here are the numbers I get: supposedly with atlas: doing matrix multiply: 0.0128 usec per loop not doing matrix multiply: 0.0132 built using "BLAS=None LAPACK=None ATLAS=None": doing matrix multiply: 0.0129 usec per loop not doing matrix multiply: 0.0131 On Fri, Oct 8, 2010 at 12:35 PM, Bruce Southey wrote: > On 10/08/2010 10:58 AM, Ian Goodfellow wrote: > > Here's the output on my atlas library: > file -L /usr/local/atlas/lib/libatlas.so > /usr/local/atlas/lib/libatlas.so: ELF 64-bit LSB shared object, x86-64, > version 1 (SYSV), dynamically linked, not stripped > > It looks mostly the same as yours except it says "not stripped" while yours > says "stripped." Do you know what that means? > > Here's my timing code (but the difference between installations is pretty > obvious even without a timer, 8 full seconds on my machine versus .2 seconds > on a slower machine at work): > > import numpy as N > import time > rng = N.random.RandomState([0,1,2]) > A = rng.randn(1000,1000) > t1 = time.time(); x = N.dot(A,A); t2 = time.time() > print t2-t1 > > > > > On Fri, Oct 8, 2010 at 11:49 AM, Bruce Southey wrote: > >> On 10/08/2010 10:01 AM, Ian Goodfellow wrote: >> >> I'm using 64-bit Ubuntu 10.04. I originally tried building without >> site.cfg and got the same result. After that I removed the installation and >> the numpy/build directory and tried again with site.cfg. >> >> Here's the otuput of my show_config(). Does this mean it's actually using >> atlas? I ran 'make time' in the atlas directory and got higher % of clock >> speed numbers than the reference so I would be surprised if my atlas build >> is this slow. >> >> atlas_threads_info: >> libraries = ['lapack', 'lapack', 'f77blas', 'cblas', 'atlas'] >> library_dirs = ['/usr/local/atlas/lib'] >> define_macros = [('ATLAS_INFO', '"\\"None\\""')] >> language = f77 >> include_dirs = ['/usr/include'] >> blas_opt_info: >> libraries = ['lapack', 'f77blas', 'cblas', 'atlas'] >> library_dirs = ['/usr/local/atlas/lib'] >> define_macros = [('ATLAS_INFO', '"\\"None\\""')] >> language = c >> include_dirs = ['/usr/include'] >> atlas_blas_threads_info: >> libraries = ['lapack', 'f77blas', 'cblas', 'atlas'] >> library_dirs = ['/usr/local/atlas/lib'] >> define_macros = [('ATLAS_INFO', '"\\"None\\""')] >> language = c >> include_dirs = ['/usr/include'] >> lapack_opt_info: >> libraries = ['lapack', 'lapack', 'f77blas', 'cblas', 'atlas'] >> library_dirs = ['/usr/local/atlas/lib'] >> define_macros = [('ATLAS_INFO', '"\\"None\\""')] >> language = f77 >> include_dirs = ['/usr/include'] >> lapack_mkl_info: >> NOT AVAILABLE >> blas_mkl_info: >> NOT AVAILABLE >> mkl_info: >> NOT AVAILABLE >> >> >> On Fri, Oct 8, 2010 at 10:53 AM, Bruce Southey wrote: >> >>> On 10/08/2010 09:06 AM, Benjamin Root wrote: >>> >>> On Fri, Oct 8, 2010 at 8:47 AM, Ian Goodfellow < >>> goodfellow.ian at gmail.com> wrote: >>> >>>> Can anyone explain how to get numpy to recognize atlas? I have atlas >>>> built and installed, and I put what I thought should be sufficient, based on >>>> numpy's INSTALL.TXT, to make numpy use atlas in my site.cfg then ran python >>>> setup.py install. The resulting build is incredibly slow. Multiplying a >>>> 1,000 x 1,000 matrix takes 8 seconds. The default packages take .8 . On a >>>> computer at work with a similar but slower cpu to mine, it only takes .2, so >>>> I know I should be able to get a lot more speed out of numpy. >>>> >>>> This is my site.cfg: >>>> >>>> [atlas] >>>> atlas_libs = lapack, f77blas, cblas, atlas >>>> >>>> [DEFAULT] >>>> library_dirs = /usr/local/atlas/lib >>>> include_dir = /usr/local/atlas/include >>>> >>>> Thanks in advance, >>>> Ian >>>> >>>> >>> Ian, it would be very helpful if you could post the output from the build >>> of numpy. That log can tell us whether it found the libraries or not when >>> building. >>> >>> Ben Root >>> >>> >>> _______________________________________________ >>> NumPy-Discussion mailing list >>> NumPy-Discussion at scipy.orghttp://mail.scipy.org/mailman/listinfo/numpy-discussion >>> >>> >>> I do not use a 'site.cfg' even though I build my own numpy but use the >>> standard Fedora (13) packages for atlas. So try it without defining it - >>> remove the installation and build directories first! >>> >>> Can you please provide the operating system (including 32bit or 64 bit), >>> Python version and numpy version? >>> >>> What is the output of the numpy function 'show_config()'? >>> I added mine below from a 64-bit linux system so you can see that numpy >>> is looking in the '/usr/lib64' directory. >>> >>> Bruce >>> >>> >>> import numpy as np >>> >>> np.show_config() >>> atlas_threads_info: >>> libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas'] >>> library_dirs = ['/usr/lib64/atlas'] >>> define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')] >>> language = f77 >>> include_dirs = ['/usr/include'] >>> blas_opt_info: >>> libraries = ['ptf77blas', 'ptcblas', 'atlas'] >>> library_dirs = ['/usr/lib64/atlas'] >>> define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')] >>> language = c >>> include_dirs = ['/usr/include'] >>> atlas_blas_threads_info: >>> libraries = ['ptf77blas', 'ptcblas', 'atlas'] >>> library_dirs = ['/usr/lib64/atlas'] >>> define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')] >>> language = c >>> include_dirs = ['/usr/include'] >>> lapack_opt_info: >>> libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas'] >>> library_dirs = ['/usr/lib64/atlas'] >>> define_macros = [('ATLAS_INFO', '"\\"3.8.3\\""')] >>> language = f77 >>> include_dirs = ['/usr/include'] >>> lapack_mkl_info: >>> NOT AVAILABLE >>> blas_mkl_info: >>> NOT AVAILABLE >>> mkl_info: >>> NOT AVAILABLE >>> >>> >>> >>> >>> >>> _______________________________________________ >>> NumPy-Discussion mailing list >>> NumPy-Discussion at scipy.org >>> http://mail.scipy.org/mailman/listinfo/numpy-discussion >>> >>> >> >> _______________________________________________ >> NumPy-Discussion mailing listNumPy-Discussion at scipy.orghttp://mail.scipy.org/mailman/listinfo/numpy-discussion >> >> >> It appears to finding something but I do not know enough about that >> aspect. >> >> I presume that you installed your own version of atlas since you are using >> /usr/local. So you need to be careful of the flags used especially that it >> is 64-bit and uses the appropriate SSE instructions for your processor. For >> example, on my system: >> >> $ file -L /usr/lib64/atlas/libatlas.so >> /usr/lib64/atlas/libatlas.so: ELF 64-bit LSB shared object, x86-64, >> version 1 (SYSV), dynamically linked, stripped >> >> Can you please provide the code you are using for timing for the 'slow' >> system? >> >> By the way, there was this thread: >> 'HOWTO build NumPy without external math libs' >> http://mail.scipy.org/pipermail/numpy-discussion/2010-July/051513.html >> >> BLAS=None LAPACK=None ATLAS=None python setup.py build >> >> >> Bruce >> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> >> > > _______________________________________________ > NumPy-Discussion mailing listNumPy-Discussion at scipy.orghttp://mail.scipy.org/mailman/listinfo/numpy-discussion > > Don't use time! > Use timeit. > > I suspect your build is using numerical libraries that have not been build > correctly for your system. But I don't know anything about that. > > What are the flags used to build lapack and atlas? > > I told the lazy way of using timeit but may help you identify the slowness. > To capture the output I use two files for stdout and stderr: > > $ python setup.py build > b.log 2>e.log > $ python setup.py install # done as root > > 1) Using numpy built as: > 'BLAS=None LAPACK=None ATLAS=None python setup.py build' > > $ python -m timeit -s "import numpy as N; rng = > N.random.RandomState([0,1,2]) ; A = rng.randn(1000,1000); x = N.dot(A,A)" > 100000000 loops, best of 3: 0.012 usec per loop > > 2) Using numpy built just without Atlas: > 'ATLAS=None python setup.py build' > $ python -m timeit -s "import numpy as N; rng = > N.random.RandomState([0,1,2]) ; A = rng.randn(1000,1000); x = N.dot(A,A)" > 100000000 loops, best of 3: 0.012 usec per loop > > 3) Using Atlas without dot: > $ python -m timeit -s "import numpy as N; rng = > N.random.RandomState([0,1,2]) ; A = rng.randn(1000,1000)" > 100000000 loops, best of 3: 0.012 usec per loop > > 4) Using Atlas with dot: > $ python -m timeit -s "import numpy as N; rng = > N.random.RandomState([0,1,2]) ; A = rng.randn(1000,1000); x = N.dot(A,A)" > 100000000 loops, best of 3: 0.0131 usec per loop > > > > Bruce > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Fri Oct 8 13:28:01 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Fri, 8 Oct 2010 13:28:01 -0400 Subject: [Numpy-discussion] Schedule for 1.5.1? In-Reply-To: References: <4CADD107.10001@gmail.com> Message-ID: On Fri, Oct 8, 2010 at 1:10 PM, Pauli Virtanen wrote: > Fri, 08 Oct 2010 10:48:14 -0600, Charles R Harris wrote: >> On Fri, Oct 8, 2010 at 10:37 AM, wrote: > [clip] >>> Ok I remember, Pareto is actually Lomax or Pareto second kind, and >>> should be renamed. The proposal was to rename the current pareto to >>> pareto2 and create a new pareto that corrects location by one. >>> >>> In the meantime I discovered that Lomax is actually nicer to work with >>> than Pareto one, so it's mainly a question of terminology/names and >>> documentation. Just calling it pareto is very misleading. >> >> That doesn't sound like something for 1.5.1. Can you think through the >> naming issue and open a ticket so we can start rationalizing this for >> 2.0? I'm thinking having pareto1 and lomax, or maybe pareto1 and >> pareto2, and deprecating plain old pareto may be the way to go. > > The documentation bit can be done, however, if there's a plan how to deal > with it. I think I clarified the doc string enough that user that read the docstring don't get confused anymore. http://docs.scipy.org/numpy/docs/numpy.random.mtrand.RandomState.pareto/ At least the first part is explicit about it, the notes refer to pareto in general or pareto 1 (formula is for pareto 1) Josef > > -- > Pauli Virtanen > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > From pav at iki.fi Fri Oct 8 13:55:53 2010 From: pav at iki.fi (Pauli Virtanen) Date: Fri, 8 Oct 2010 17:55:53 +0000 (UTC) Subject: [Numpy-discussion] Schedule for 1.5.1? References: <4CADD107.10001@gmail.com> Message-ID: Fri, 08 Oct 2010 13:28:01 -0400, josef.pktd wrote: [clip] > I think I clarified the doc string enough that user that read the > docstring don't get confused anymore. > http://docs.scipy.org/numpy/docs/numpy.random.mtrand.RandomState.pareto/ > > At least the first part is explicit about it, the notes refer to pareto > in general or pareto 1 (formula is for pareto 1) I read this part: """ The classical Pareto distribution can be obtained from the Lomax distribution by adding the location parameter m, see below. The smallest value of the Lomax distribution is zero while for the classical Pareto distribution it is m, where the standard Pareto distribution has location m=1. """ and understood it as follows (with no prior knowledge what a Pareto distribution is): """ The difference between Pareto and Lomax is that Lomax has an added parameter `m`. The Pareto distribution is obtained from Lomax by setting m=1. """ Which is of course wrong. So I think it would still pay off to rephrase this. I'd also write down the PDF of the Lomax distribution in the Notes to reduce confusion. Pauli From hugogilsilva at gmail.com Fri Oct 8 14:10:56 2010 From: hugogilsilva at gmail.com (sicre) Date: Fri, 8 Oct 2010 11:10:56 -0700 (PDT) Subject: [Numpy-discussion] Meshgrid with Huge Arrays In-Reply-To: <29902859.post@talk.nabble.com> References: <29902859.post@talk.nabble.com> Message-ID: <29917035.post@talk.nabble.com> My program works with NrHorPixels=10 NrVerPixels=10 NrCellsPerPixel=16 but not with NrHorPixels=2048 NrVerPixels=2048 NrCellsPerPixel=100 The problem is in the variable Z definition and in the meshgrid, getting MemoryError and ValueError: dimensions too large. Is there any solution to avoid such huge arrays since I have 3GB 32bit? CODE: " from mpl_toolkits.mplot3d import Axes3D import matplotlib.pyplot as plt import numpy as np from pylab import * #VARIABLES NrHorPixels=10 NrVerPixels=10 NrCellsPerPixel=16 GaussianCenterX=5 GaussianCenterY=5 SigmaX=1 SigmaY=1 Amplitude = 150 #3D ARRAY XArray = np.arange(0, NrHorPixels, 1./sqrt(NrCellsPerPixel),dtype=float32) YArray = np.arange(0, NrVerPixels, 1./sqrt(NrCellsPerPixel),dtype=float32) XArray, YArray = np.meshgrid(XArray, YArray) Z = np.zeros([len(XArray),len(YArray)]) #Add Gaussian to Array Z = Z+Amplitude*e**-(((XArray-GaussianCenterX)**2/(2*SigmaX**2))+((YArray-GaussianCenterY)**2/(2*SigmaY**2))) #Plot 3D fig = plt.figure() ax = Axes3D(fig) ax.plot_surface(XArray, YArray, Z, rstride=1, cstride=1, cmap=cm.jet) plt.show() ##Plot Heatmap ##pcolormesh(Z) ##colorbar() ##show() " -- View this message in context: http://old.nabble.com/Meshgrid-with-Huge-Arrays-tp29902859p29917035.html Sent from the Numpy-discussion mailing list archive at Nabble.com. From josef.pktd at gmail.com Fri Oct 8 14:17:28 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Fri, 8 Oct 2010 14:17:28 -0400 Subject: [Numpy-discussion] Schedule for 1.5.1? In-Reply-To: References: <4CADD107.10001@gmail.com> Message-ID: On Fri, Oct 8, 2010 at 1:55 PM, Pauli Virtanen wrote: > Fri, 08 Oct 2010 13:28:01 -0400, josef.pktd wrote: > [clip] >> I think I clarified the doc string enough that user that read the >> docstring don't get confused anymore. >> http://docs.scipy.org/numpy/docs/numpy.random.mtrand.RandomState.pareto/ >> >> At least the first part is explicit about it, the notes refer to pareto >> in general or pareto 1 (formula is for pareto 1) > > I read this part: > > """ > The classical Pareto distribution can be obtained from the Lomax > distribution by adding the location parameter m, see below. The smallest "adding" is in the sense of rvs + m s = np.random.pareto(a, 1000) + m not that the distribution has an added location parameter I will check my notes, and try to rewrite it in a clearer way. > value of the Lomax distribution is zero while for the classical Pareto > distribution it is m, where the standard Pareto distribution has location > m=1. > """ > > and understood it as follows (with no prior knowledge what a Pareto > distribution is): > > """ > The difference between Pareto and Lomax is that Lomax has an added > parameter `m`. The Pareto distribution is obtained from Lomax by setting > m=1. > """ > > Which is of course wrong. So I think it would still pay off to rephrase > this. I'd also write down the PDF of the Lomax distribution in the Notes > to reduce confusion. ok, will do Josef > > ? ? ? ?Pauli > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > From ralf.gommers at googlemail.com Fri Oct 8 19:46:19 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Sat, 9 Oct 2010 07:46:19 +0800 Subject: [Numpy-discussion] known failure test decorator not treated as expected by nose In-Reply-To: References: Message-ID: On Fri, Oct 8, 2010 at 1:09 AM, Jonathan March wrote: > On Wed, Oct 6, 2010 at 6:17 PM, wrote: > > On Wed, Oct 6, 2010 at 7:08 PM, Jonathan March > wrote: > >> It appears that the numpy testing decorators for skipping and for > >> known failure should behave similarly to each other, at least from > >> their descriptions here: > >> > http://projects.scipy.org/numpy/wiki/TestingGuidelines#known-failures-skipping-tests > >> > >> Yet in the following example, run under nose, they behave quite > differently: > >> > >> ==== > >> from numpy.testing import dec > >> > >> @dec.knownfailureif( True, "known failure test message") > >> def test_will_fail(): > >> pass > >> > >> @dec.skipif( True, "skip test message") > >> def test_to_skip(): > >> pass > >> ==== > >> > >> The skipped test is marked as "S" as expected, but when the > >> KnownFailureTest exception is raised, nose handles it as an error > >> (marked "E" rather than "K" as expected, and printing the stack > >> trace.) > >> > >> It's also interesting that nose has a --no-skip option but no > >> corresponding option for ignoring known failure decorators. > >> > >> Why the discrepancy? Who is out of step with whom? This is with numpy > >> 1.4.0 and nosetests 0.11.3 > > > > just as additional information > > > > This only happens on the command line, with nosetests packagename > > but not with the function, packagename.test() > > > Knownfailure is a numpy-specific plugin, which needs to be loaded for tests decorated with @dec.knownfailureif to be marked as K instead of E. This plugin loading is done by the NoseTester class (defined in numpy/testing/nosetester.py) which is used when tests are run through numpy.test(). Using 'nosetests' on the command line skips this plugin loading, hence the error. Nose does have a "skip" plugin so that never gives an error. > > Josef > > > Numpy issue, nose issue, or user issue? > User issue. Cheers, Ralf > > > >> Thanks, > >> Jonathan March > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.kirkby at onetel.net Fri Oct 8 21:50:11 2010 From: david.kirkby at onetel.net (Dr. David Kirkby) Date: Sat, 09 Oct 2010 02:50:11 +0100 Subject: [Numpy-discussion] Schedule for 1.5.1? In-Reply-To: References: <4CAE4BFA.8090503@onetel.net> Message-ID: <4CAFCA53.10003@onetel.net> On 10/ 8/10 03:43 PM, Ralf Gommers wrote: > On Fri, Oct 8, 2010 at 6:38 AM, Dr. David Kirkbywrote: > >> On 10/ 6/10 12:49 AM, Pauli Virtanen wrote: >>> Hi, >>> >>> Should we set a date for a bugfix 1.5.1 release? There are some bugs that >>> would be nice to sort out in the 1.5.x series: >>> >>> Any Python versions: >>> >>> - #1605 (Cython vs. PEP-3118 issue: raising exceptions with active >>> cython buffers caused undefined behavior. Breaks Sage.) >>> - #1617 (Ensure complex(np.longcomplex(...)) doesn't drop the imag part) >>> - Fix doc build >> >> I'd like to see the 'isfinite' bug in 1.5.1, which is #1625 and has been >> committed I believe. >> >> Pauli already backported this fix: > http://github.com/numpy/numpy/commit/8e0d299b > > Ralf Thank you. That's good news. dave From fperez.net at gmail.com Fri Oct 8 22:21:13 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 8 Oct 2010 19:21:13 -0700 Subject: [Numpy-discussion] datarray repositories have diverged In-Reply-To: References: <87sk0r6w1s.fsf@ginnungagap.bsc.es> Message-ID: Hi Rob, Josh and Lluis, On Thu, Sep 30, 2010 at 9:41 AM, Rob Speer wrote: > The fact that I wasn't around for the sprint probably has a lot to do > with how much the code had diverged. But it's not too bad -- I merged > Fernando's branch into mine and only had to change a couple of things > to make the tests pass. > > There seem to be two general patterns for decentralized projects on > GitHub: either you have one de facto leader who owns what everyone > considers the main branch (this is what datarray is doing now, with > Fernando as the leader), or you create a GitHub "organization" that > owns the main branch and make a bunch of key people members of the > organization (which is what numpy is doing). > > The way you'd usually get something merged in this kind of project is > to send a pull request to the leader using the "Pull Request" button. > But in this case, I'm basically making my pull request on the mailing > list, because it's not straightforward enough for a simple pull > request. sorry it took a bit longer than originally planned to merge this. Some of us got together on Wednesday on campus and worked through a lot of this code (we closed one pull request by Lluis and replied to the other requesting more work, as it broke many tests). We didn't announce an IRC sprint because last time it just proved a bit hard to be simultaneously productive on-premises and keep a good flow of activity on IRC for remote contributors, sorry. Perhaps with more people available that will be possible later on, but for now it seemed wiser for us just to push through with what little work we could do. **Merged changes** Here's a summary of the things we did merge in from your pull request: - merged gitignore, thanks. - your graft change to manifest.in wasn't needed, instead the bug was that our setup file was missing properly listing the testing package, and that's the right solution to apply: PACKAGES = ["datarray", "datarray/tests", "datarray/testing"] Thanks for catching that problem! - merge readme improvements into readme.txt. Note that since this is a pure python project, markdown-formatted readme files are fairly out of place (they don't render correctly on pypi, for one thing, and our readme is the same as our long_description field in the setup.py). So the top-level readme must remain a reST file. But we did incorporate your text, thanks! As a future note when editing text files, please keep text lines to 80 characters just like code ones. Diff (and github) are mostly line-oriented, so it's best to format text files with hard linebreaks (even if many editors can handle soft linewraps correctly, it's just not very portable). - merged your fancy printing support, excellent work! We did adjust the tests a little bit so they would pass without named/attribute support, since that will require more discussion (see below). But the main file is in unmodified, and the test changes are tiny. We made a mini-release v0.0.5 now, with these changes in: http://fperez.github.com/datarray-doc/0.0.5/index.html **Workflow** For future reference, while we were able to manually work through your pull request, I'd like to suggest that you adopt a more traditional workflow where a single pull request contains only a "conceptually atomic" set of changes related to each other. That way it can either be all merged or discussed and refined until merge more easily. Your pull request had work from multiple people, making changes of many unrelated types (gh-pages, .gitignore, named access, printing, etc...). I was able to cherry-pick one or two commits, but by and large I had to resort to manually copying files out of your repo, because there were some things that should not be merged, and there was no easy way to disentangle it. Here's for example the currently active pull requests on ipython: http://github.com/ipython/ipython/pulls some of them are fairly extensive, but each is conceptually atomic, so each can be studied in isolation and either will require refinement or will be merged, but nobody is going to have to dissect it into pieces to commit some and drop others. I hope this is clear, let me know if you need any more info on this. Ultimately it's a matter of making the process more efficient for all involved. **Changes where further discussion is needed** There were some things we did *not* merge. The sphinx extension isn't needed (we use a different mechanism for gh-pages that is cleaner), so we just ignored it. But the important point are the changes to named access support. I realize since the conference you've wanted this, but we really would like to proceed more carefully and implement first, only .axis.name access. The top-level access requires a changed __getattr__ method (which slows down *all* attribute access), and opens the door for name collisions. I think the best approach will be to follow the lead of numpy here: structured arrays offer only access by named key ['name'], and for plain .name access you need to make them a recarray. We should also offer in our base class only the simpler, safer mechanism, and then we can build one that uses the .name attributes as a subclass for those who want the convenience and understand the risks and tradeoffs. How does this sound to you? We should make sure we agree on the api before writing too much more code along these lines. I realize you've actually contributed an implementation of this, but I think we need to make sure it's the right design before merging it in. We do need to have this design discussion to find a class that will work for as many people as possible, so many thanks for starting by offering working code! Regards, f From fperez.net at gmail.com Fri Oct 8 22:23:00 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 8 Oct 2010 19:23:00 -0700 Subject: [Numpy-discussion] DataArray fixes In-Reply-To: <8662yge98e.wl%lluis@ginnungagap.pc.ac.upc.edu> References: <86wrqywujy.wl%lluis@ginnungagap.pc.ac.upc.edu> <8662yge98e.wl%lluis@ginnungagap.pc.ac.upc.edu> Message-ID: On Wed, Sep 8, 2010 at 5:00 AM, Llu?s wrote: > Well, the pull requests I posted to your repository are for fairly trivial fixes > (but some still need documentation and regression test updates). > By the way Lluis, I replied to one of your requests (Keith merged the other one, thanks!) here: http://github.com/fperez/datarray/pull/23 Basically it currently breaks most tests, so we can't really go forward until it applies cleanly on trunk and actually works :) Cheers, f From josh.holbrook at gmail.com Fri Oct 8 23:20:58 2010 From: josh.holbrook at gmail.com (Joshua Holbrook) Date: Fri, 8 Oct 2010 19:20:58 -0800 Subject: [Numpy-discussion] datarray repositories have diverged In-Reply-To: References: <87sk0r6w1s.fsf@ginnungagap.bsc.es> Message-ID: On Fri, Oct 8, 2010 at 6:21 PM, Fernando Perez wrote: > Hi Rob, Josh and Lluis, > > On Thu, Sep 30, 2010 at 9:41 AM, Rob Speer wrote: >> The fact that I wasn't around for the sprint probably has a lot to do >> with how much the code had diverged. But it's not too bad -- I merged >> Fernando's branch into mine and only had to change a couple of things >> to make the tests pass. >> >> There seem to be two general patterns for decentralized projects on >> GitHub: either you have one de facto leader who owns what everyone >> considers the main branch (this is what datarray is doing now, with >> Fernando as the leader), or you create a GitHub "organization" that >> owns the main branch and make a bunch of key people members of the >> organization (which is what numpy is doing). >> >> The way you'd usually get something merged in this kind of project is >> to send a pull request to the leader using the "Pull Request" button. >> But in this case, I'm basically making my pull request on the mailing >> list, because it's not straightforward enough for a simple pull >> request. > > sorry it took a bit longer than originally planned to merge this. > Some of us got together on Wednesday on campus and worked through a > lot of this code (we closed one pull request by Lluis and replied to > the other requesting more work, as it broke many tests). ?We didn't > announce an IRC sprint because last time it just proved a bit hard to > be simultaneously productive on-premises and keep a good flow of > activity on IRC for remote contributors, sorry. ?Perhaps with more > people available that will be possible later on, but for now it seemed > wiser for us just to push through with what little work we could do. > > **Merged changes** > > Here's a summary of the things we did merge in from your pull request: > > - merged gitignore, thanks. > > - your graft change to manifest.in wasn't needed, instead the bug was > that our setup file was missing properly listing the testing package, > and that's the right solution to apply: > > ?PACKAGES ? ? ? ? ? ?= ["datarray", "datarray/tests", "datarray/testing"] > > Thanks for catching that problem! > > - merge readme improvements into readme.txt. ?Note that since this is > a pure python project, markdown-formatted readme files are fairly out > of place (they don't render correctly on pypi, for one thing, and our > readme is the same as our long_description field in the setup.py). ?So > the top-level readme must remain a reST file. ?But we did incorporate > your text, thanks! > > As a future note when editing text files, please keep text lines to 80 > characters just like code ones. ?Diff (and github) are mostly > line-oriented, so it's best to format text files with hard linebreaks > (even if many editors can handle soft linewraps correctly, it's just > not very portable). > > - merged your fancy printing support, excellent work! ?We did adjust > the tests a little bit so they would pass without named/attribute > support, since that will require more discussion (see below). ?But the > main file is in unmodified, and the test changes are tiny. > > We made a mini-release v0.0.5 now, with these changes in: > > http://fperez.github.com/datarray-doc/0.0.5/index.html > > **Workflow** > > For future reference, while we were able to manually work through your > pull request, I'd like to suggest that you adopt a more traditional > workflow where a single pull request contains only a "conceptually > atomic" set of changes related to each other. That way it can either > be all merged or discussed and refined until merge more easily. ?Your > pull request had work from multiple people, making changes of many > unrelated types (gh-pages, .gitignore, named access, printing, > etc...). ?I was able to cherry-pick one or two commits, but by and > large I had to resort to manually copying files out of your repo, > because there were some things that should not be merged, and there > was no easy way to disentangle it. > > Here's for example the currently active pull requests on ipython: > > http://github.com/ipython/ipython/pulls > > some of them are fairly extensive, but each is conceptually atomic, so > each can be studied in isolation and either will require refinement or > will be merged, but nobody is going to have to dissect it into pieces > to commit some and drop others. > > I hope this is clear, let me know if you need any more info on this. > Ultimately it's a matter of making the process more efficient for all > involved. > > **Changes where further discussion is needed** > > There were some things we did *not* merge. ?The sphinx extension isn't > needed (we use a different mechanism for gh-pages that is cleaner), so > we just ignored it. > > But the important point are the changes to named access support. ?I > realize since the conference you've wanted this, but we really would > like to proceed more carefully and implement first, only .axis.name > access. ?The top-level access requires a changed __getattr__ method > (which slows down *all* attribute access), and opens the door for name > collisions. ?I think the best approach will be to follow the lead of > numpy here: structured arrays offer only access by named key ['name'], > and for plain .name access you need to make them a recarray. ?We > should also offer in our base class only the simpler, safer mechanism, > and then we can build one that uses the .name attributes as a subclass > for those who want the convenience and understand the risks and > tradeoffs. > > How does this sound to you? ?We should make sure we agree on the api > before writing too much more code along these lines. ?I realize you've > actually contributed an implementation of this, but I think we need to > make sure it's the right design before merging it in. ?We do need to > have this design discussion to find a class that will work for as many > people as possible, so many thanks for starting by offering working > code! > > Regards, > > f > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > What mechanism are you using for gh-pages, if I may ask? I would be interested in this for future projects. --Josh From fperez.net at gmail.com Sat Oct 9 01:05:03 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 8 Oct 2010 22:05:03 -0700 Subject: [Numpy-discussion] datarray repositories have diverged In-Reply-To: References: <87sk0r6w1s.fsf@ginnungagap.bsc.es> Message-ID: Hi, On Fri, Oct 8, 2010 at 8:20 PM, Joshua Holbrook wrote: > > What mechanism are you using for gh-pages, if I may ask? I would be > interested in this for future projects. the default github implementation relies on a 'hidden' branch called gh-pages that lives in the main repo. I think this is a *horrible* idea because it requires polluting the real repo with builds of the documentation that are auto-generated. Furthermore, I like keeping live versions of the docs of a project for each release, and the gh-pages branch is thus likely to get rather large. Instead, I made a *separate* repo to be used only for gh-pages: http://github.com/fperez/datarray-doc The only purpose of this repo is to provide the docs for datarray. The datarray doc/Makefile has a gh-pages target that updates the html build and then runs the gh-pages script. That's a simple code I wrote to populate the -doc repo with a ready-to-push build of the docs. On each release, we simply do make gh-pages and follow the instructions it prints, which amount to: 1. cd ../datarray-doc 2. check the docs look good 3. git push That pushes the doc build. This workflow is extremely simple, gives us builds of the documentation for all releases nicely indexed with a stable url: http://fperez.github.com/datarray-doc/ and it produces zero pollution of the main repo with gh-pages junk. Cheers, f From josh.holbrook at gmail.com Sat Oct 9 05:48:01 2010 From: josh.holbrook at gmail.com (Joshua Holbrook) Date: Sat, 9 Oct 2010 01:48:01 -0800 Subject: [Numpy-discussion] datarray repositories have diverged In-Reply-To: References: <87sk0r6w1s.fsf@ginnungagap.bsc.es> Message-ID: On Fri, Oct 8, 2010 at 9:05 PM, Fernando Perez wrote: > Hi, > > On Fri, Oct 8, 2010 at 8:20 PM, Joshua Holbrook wrote: >> >> What mechanism are you using for gh-pages, if I may ask? I would be >> interested in this for future projects. > > the default github implementation relies on a 'hidden' branch called > gh-pages that lives in the main repo. ?I think this is ?a *horrible* > idea because it requires polluting the real repo with builds of the > documentation that are auto-generated. ?Furthermore, I like keeping > live versions of the docs of a project for each release, and the > gh-pages branch is thus likely to get rather large. > > Instead, I made a *separate* repo to be used only for gh-pages: > > http://github.com/fperez/datarray-doc > > The only purpose of this repo is to provide the docs for datarray. > The datarray doc/Makefile has a gh-pages target that updates the html > build and then runs the gh-pages script. ?That's a simple code I wrote > to populate the -doc repo with a ready-to-push build of the docs. > > On each release, we simply do > > make gh-pages > > and follow the instructions it prints, which amount to: > > 1. cd ../datarray-doc > 2. check the docs look good > 3. git push > > That pushes the doc build. > > This workflow is extremely simple, gives us builds of the > documentation for all releases nicely indexed with a stable url: > > http://fperez.github.com/datarray-doc/ > > and it produces zero pollution of the main repo with gh-pages junk. > > Cheers, > > f > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > I have to admit to not being a big fan of the oddball 'gh-pages' branch either. I wish there was a better way of doing gh-pages documentation than having to put it in a separate repo, but it's better than two branches with *completely different* files fighting polluting each other (Or worse, dumping build files into /tmp, checking out gh-pages, copying from /tmp back in, etc., etc., which is what I found myself doing). Plus, you could always make the docs a submodule, if that's how you roll (might be a good idea, actually). Now, if I could just find a documentation tool that I like. I'm not huge on Sphinx, tbh, and RST doesn't really light my fire. Anyways--I feel enlightened! Thanks! --Josh From ioan.ferencik at tkk.fi Sat Oct 9 07:18:17 2010 From: ioan.ferencik at tkk.fi (Ioan Ferencik) Date: Sat, 9 Oct 2010 14:18:17 +0300 Subject: [Numpy-discussion] compile fortran from python Message-ID: <20101009141817.5f5g6y7pk4ggc00s@webmail3.tkk.fi> I would like to compile some Fortran code using python, build a shared library, and link to it using python. But I get a message saying the compiler does not recognise the extension of my file. this is my command: gcc -fPIC -c -shared -fno-underscoring test.f95 -o ./lib/libctest.so.1.0 what is the easiest method to achieve this? I suspect I could create a custom extension and customise the unixccompiler object or could I just use the compiler object defined by f2py(fcompiler). Cheers Ioan Ferencik PhD student Aalto University School of Science and Technology Faculty Of Civil and Env. Engineering Lahti Center Tel: +358505122707 From cournape at gmail.com Sat Oct 9 08:17:41 2010 From: cournape at gmail.com (David Cournapeau) Date: Sat, 9 Oct 2010 21:17:41 +0900 Subject: [Numpy-discussion] compile fortran from python In-Reply-To: <20101009141817.5f5g6y7pk4ggc00s@webmail3.tkk.fi> References: <20101009141817.5f5g6y7pk4ggc00s@webmail3.tkk.fi> Message-ID: On Sat, Oct 9, 2010 at 8:18 PM, Ioan Ferencik wrote: > I would like to compile some Fortran ?code using python, ?build a > shared library, and link to it using python. But I get a message > saying the compiler does not recognise the extension of my file. > > this is my command: > > gcc -fPIC -c -shared -fno-underscoring test.f95 -o ./lib/libctest.so.1.0 I am not sure I understand what you want: do you build some code which does not depend on python, with python solely used as a language to drive the build ? Your command above has a problem because you use gcc to build fortran code - you should use the gfortran compiler instead. cheers, David From vincent at vincentdavis.net Sat Oct 9 14:59:26 2010 From: vincent at vincentdavis.net (Vincent Davis) Date: Sat, 9 Oct 2010 12:59:26 -0600 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: References: Message-ID: Did you get any responses on this? I can install 10.5 and help out with some testing. I have a macbookpro that does not turn of (Hardware issue) but it is good for testing. I could setup remote access on this if of interest to you. Is there anything like the Python devs build bot for automated install and testing testing of numpy and scipy? Vincent On Tue, Sep 21, 2010 at 8:57 AM, Ralf Gommers wrote: > Hi, > > There have been many reports from OS X 10.5(.8) users that the provided > binaries on Sourceforge for numpy versions >= 1.4.0 do not work, see > http://projects.scipy.org/numpy/ticket/1322. If you're an OS X 10.5 user I > would like your help to test if the same issue occurs for the following > binary: > http://sourceforge.net/projects/numpy/files/Temporary/numpy-2.0.0.dev-py2.6-osx10.5-python.org.dmg/download > Please comment on the above ticket. > > Thanks, > Ralf > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > -- Thanks Vincent Davis 720-301-3003 From josef.pktd at gmail.com Sat Oct 9 21:47:06 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Sat, 9 Oct 2010 21:47:06 -0400 Subject: [Numpy-discussion] polynomial fromroots Message-ID: I'm trying to see whether I can do this without reading the full manual. Is it intended that fromroots normalizes the highest order term instead of the lowest? >>> import numpy.polynomial as poly >>> p = poly.Polynomial([1, -1.88494037, 0.0178126 ]) >>> p Polynomial([ 1. , -1.88494037, 0.0178126 ], [-1., 1.]) >>> pr = p.roots() >>> pr array([ 0.53320748, 105.28741219]) >>> poly.Polynomial.fromroots(pr) Polynomial([ 56.14003571, -105.82061967, 1. ], [-1., 1.]) >>> renormalizing >>> p2 = poly.Polynomial.fromroots(pr) >>> p2/p2.coef[0] Polynomial([ 1. , -1.88494037, 0.0178126 ], [-1., 1.]) this is, I think what I want to do, invert roots that are inside/outside the unit circle (whatever that means >>> pr[np.abs(pr)<1] = 1./pr[np.abs(pr)<1] >>> p3 = poly.Polynomial.fromroots(pr) >>> p3/p3.coef[0] Polynomial([ 1. , -0.54270529, 0.0050643 ], [-1., 1.]) Josef From charlesr.harris at gmail.com Sat Oct 9 22:01:09 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Sat, 9 Oct 2010 20:01:09 -0600 Subject: [Numpy-discussion] polynomial fromroots In-Reply-To: References: Message-ID: On Sat, Oct 9, 2010 at 7:47 PM, wrote: > I'm trying to see whether I can do this without reading the full manual. > > Is it intended that fromroots normalizes the highest order term > instead of the lowest? > > > >>> import numpy.polynomial as poly > > >>> p = poly.Polynomial([1, -1.88494037, 0.0178126 ]) > >>> p > Polynomial([ 1. , -1.88494037, 0.0178126 ], [-1., 1.]) > >>> pr = p.roots() > >>> pr > array([ 0.53320748, 105.28741219]) > >>> poly.Polynomial.fromroots(pr) > Polynomial([ 56.14003571, -105.82061967, 1. ], [-1., 1.]) > >>> > > renormalizing > > >>> p2 = poly.Polynomial.fromroots(pr) > >>> p2/p2.coef[0] > Polynomial([ 1. , -1.88494037, 0.0178126 ], [-1., 1.]) > > > this is, I think what I want to do, invert roots that are > inside/outside the unit circle (whatever that means > > >>> pr[np.abs(pr)<1] = 1./pr[np.abs(pr)<1] > >>> p3 = poly.Polynomial.fromroots(pr) > >>> p3/p3.coef[0] > Polynomial([ 1. , -0.54270529, 0.0050643 ], [-1., 1.]) > > Wrong function ;) You defined the polynomial by its coefficients. What you want to do is In [1]: import numpy.polynomial as poly In [2]: p = poly.Polynomial.fromroots([1, -1.88494037, 0.0178126 ]) In [3]: p Out[3]: Polynomial([ 0.03357569, -1.90070346, 0.86712777, 1. ], [-1., 1.]) In [4]: p.roots() Out[4]: array([-1.88494037, 0.0178126 , 1. ]) Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Sat Oct 9 22:05:08 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Sat, 9 Oct 2010 20:05:08 -0600 Subject: [Numpy-discussion] polynomial fromroots In-Reply-To: References: Message-ID: On Sat, Oct 9, 2010 at 8:01 PM, Charles R Harris wrote: > > > On Sat, Oct 9, 2010 at 7:47 PM, wrote: > >> I'm trying to see whether I can do this without reading the full manual. >> >> Is it intended that fromroots normalizes the highest order term >> instead of the lowest? >> >> >> >>> import numpy.polynomial as poly >> >> >>> p = poly.Polynomial([1, -1.88494037, 0.0178126 ]) >> >>> p >> Polynomial([ 1. , -1.88494037, 0.0178126 ], [-1., 1.]) >> >>> pr = p.roots() >> >>> pr >> array([ 0.53320748, 105.28741219]) >> >>> poly.Polynomial.fromroots(pr) >> Polynomial([ 56.14003571, -105.82061967, 1. ], [-1., 1.]) >> >>> >> >> renormalizing >> >> >>> p2 = poly.Polynomial.fromroots(pr) >> >>> p2/p2.coef[0] >> Polynomial([ 1. , -1.88494037, 0.0178126 ], [-1., 1.]) >> >> >> this is, I think what I want to do, invert roots that are >> inside/outside the unit circle (whatever that means >> >> >>> pr[np.abs(pr)<1] = 1./pr[np.abs(pr)<1] >> >>> p3 = poly.Polynomial.fromroots(pr) >> >>> p3/p3.coef[0] >> Polynomial([ 1. , -0.54270529, 0.0050643 ], [-1., 1.]) >> >> > Wrong function ;) You defined the polynomial by its coefficients. What you > want to do is > > In [1]: import numpy.polynomial as poly > > In [2]: p = poly.Polynomial.fromroots([1, -1.88494037, 0.0178126 ]) > > In [3]: p > Out[3]: Polynomial([ 0.03357569, -1.90070346, 0.86712777, 1. ], > [-1., 1.]) > > In [4]: p.roots() > Out[4]: array([-1.88494037, 0.0178126 , 1. ]) > > Oh, and least squares follows the same convention: In [5]: x = linspace(-1,1,10) In [6]: y = (x - 1)*( x + 1.88494037)*(x - 0.0178126) In [7]: p = poly.Polynomial.fit(x, y, 3) In [8]: p Out[8]: Polynomial([ 0.03357569, -1.90070346, 0.86712777, 1. ], [-1., 1.]) Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Sat Oct 9 22:21:51 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Sat, 9 Oct 2010 20:21:51 -0600 Subject: [Numpy-discussion] polynomial fromroots In-Reply-To: References: Message-ID: On Sat, Oct 9, 2010 at 8:05 PM, Charles R Harris wrote: > > > On Sat, Oct 9, 2010 at 8:01 PM, Charles R Harris < > charlesr.harris at gmail.com> wrote: > >> >> >> On Sat, Oct 9, 2010 at 7:47 PM, wrote: >> >>> I'm trying to see whether I can do this without reading the full manual. >>> >>> Is it intended that fromroots normalizes the highest order term >>> instead of the lowest? >>> >>> >>> >>> import numpy.polynomial as poly >>> >>> >>> p = poly.Polynomial([1, -1.88494037, 0.0178126 ]) >>> >>> p >>> Polynomial([ 1. , -1.88494037, 0.0178126 ], [-1., 1.]) >>> >>> pr = p.roots() >>> >>> pr >>> array([ 0.53320748, 105.28741219]) >>> >>> poly.Polynomial.fromroots(pr) >>> Polynomial([ 56.14003571, -105.82061967, 1. ], [-1., 1.]) >>> >>> >>> >>> renormalizing >>> >>> >>> p2 = poly.Polynomial.fromroots(pr) >>> >>> p2/p2.coef[0] >>> Polynomial([ 1. , -1.88494037, 0.0178126 ], [-1., 1.]) >>> >>> >>> this is, I think what I want to do, invert roots that are >>> inside/outside the unit circle (whatever that means >>> >>> >>> pr[np.abs(pr)<1] = 1./pr[np.abs(pr)<1] >>> >>> p3 = poly.Polynomial.fromroots(pr) >>> >>> p3/p3.coef[0] >>> Polynomial([ 1. , -0.54270529, 0.0050643 ], [-1., 1.]) >>> >>> >> Wrong function ;) You defined the polynomial by its coefficients. What you >> want to do is >> >> In [1]: import numpy.polynomial as poly >> >> In [2]: p = poly.Polynomial.fromroots([1, -1.88494037, 0.0178126 ]) >> >> In [3]: p >> Out[3]: Polynomial([ 0.03357569, -1.90070346, 0.86712777, 1. ], >> [-1., 1.]) >> >> In [4]: p.roots() >> Out[4]: array([-1.88494037, 0.0178126 , 1. ]) >> >> > Oh, and least squares follows the same convention: > > In [5]: x = linspace(-1,1,10) > > In [6]: y = (x - 1)*( x + 1.88494037)*(x - 0.0178126) > > In [7]: p = poly.Polynomial.fit(x, y, 3) > > In [8]: p > Out[8]: Polynomial([ 0.03357569, -1.90070346, 0.86712777, 1. ], > [-1., 1.]) > > You can also use a scaled and shifted domain, which will change the coefficient representation but can be used to obtain a polynomial less subject to roundoff errors. In [18]: p = poly.Polynomial.fromroots([1, -1.88494037, 0.0178126 ], domain=[-2,1]) In [19]: p Out[19]: Polynomial([ 0.3187287 , -0.89681388, -0.42191482, 1. ], [-2., 1.]) In [20]: p.roots() Out[20]: array([-1.88494037, 0.0178126 , 1. ]) In [21]: plot(*p.linspace()) Out[21]: [] I attached the plot. Chuck > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 21525 bytes Desc: not available URL: From josef.pktd at gmail.com Sat Oct 9 22:36:21 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Sat, 9 Oct 2010 22:36:21 -0400 Subject: [Numpy-discussion] polynomial fromroots In-Reply-To: References: Message-ID: On Sat, Oct 9, 2010 at 10:01 PM, Charles R Harris wrote: > > > On Sat, Oct 9, 2010 at 7:47 PM, wrote: >> >> I'm trying to see whether I can do this without reading the full manual. >> >> Is it intended that fromroots normalizes the highest order term >> instead of the lowest? >> >> >> >>> import numpy.polynomial as poly >> >> >>> p = poly.Polynomial([1, -1.88494037, ?0.0178126 ]) >> >>> p >> Polynomial([ 1. ? ? ? ?, -1.88494037, ?0.0178126 ], [-1., ?1.]) >> >>> pr = p.roots() >> >>> pr >> array([ ? 0.53320748, ?105.28741219]) >> >>> poly.Polynomial.fromroots(pr) >> Polynomial([ ?56.14003571, -105.82061967, ? ?1. ? ? ? ?], [-1., ?1.]) >> >>> >> >> renormalizing >> >> >>> p2 = poly.Polynomial.fromroots(pr) >> >>> p2/p2.coef[0] >> Polynomial([ 1. ? ? ? ?, -1.88494037, ?0.0178126 ], [-1., ?1.]) >> >> >> this is, I think what I want to do, invert roots that are >> inside/outside the unit circle (whatever that means >> >> >>> pr[np.abs(pr)<1] = 1./pr[np.abs(pr)<1] >> >>> p3 = poly.Polynomial.fromroots(pr) >> >>> p3/p3.coef[0] >> Polynomial([ 1. ? ? ? ?, -0.54270529, ?0.0050643 ], [-1., ?1.]) >> > > Wrong function ;) You defined the polynomial by its coefficients. What you > want to do is My coefficients are from a lag-polynomial in time series analysis (ARMA), and they really are the (estimated) coefficients. It is essentially the same as the model for scipy.signal.lfilter. I just need to check the roots to see whether the process is stationary and invertible. If one of the two lag-polynomials (moving average) has roots on the wrong side of the unit circle, then I can invert them. I'm coding from memory of how this is supposed to work, so maybe I'm back to RTFM and RTFTB (TB=text book). (I think what I really would need is a z-transform, but I don't have much of an idea how to do this on a computer) Thanks, the main thing I need to do is check the convention or definition for the normalization. And as btw, I like that the coef are in increasing order e.g. seasonal differencing multiplied with 1 lag autoregressive poly.Polynomial([1.,0,0,-1])*poly.Polynomial([1,0.8]) (I saw your next message: Last time I played with function approximation, I didn't figure out what the basis does, but it worked well without touching it) Josef > > In [1]: import numpy.polynomial as poly > > In [2]: p = poly.Polynomial.fromroots([1, -1.88494037,? 0.0178126 ]) > > In [3]: p > Out[3]: Polynomial([ 0.03357569, -1.90070346,? 0.86712777,? 1.??????? ], > [-1.,? 1.]) > > In [4]: p.roots() > Out[4]: array([-1.88494037,? 0.0178126 ,? 1.??????? ]) > > Chuck > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > From charlesr.harris at gmail.com Sat Oct 9 23:01:11 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Sat, 9 Oct 2010 21:01:11 -0600 Subject: [Numpy-discussion] polynomial fromroots In-Reply-To: References: Message-ID: On Sat, Oct 9, 2010 at 8:36 PM, wrote: > On Sat, Oct 9, 2010 at 10:01 PM, Charles R Harris > wrote: > > > > > > On Sat, Oct 9, 2010 at 7:47 PM, wrote: > >> > >> I'm trying to see whether I can do this without reading the full manual. > >> > >> Is it intended that fromroots normalizes the highest order term > >> instead of the lowest? > >> > >> > >> >>> import numpy.polynomial as poly > >> > >> >>> p = poly.Polynomial([1, -1.88494037, 0.0178126 ]) > >> >>> p > >> Polynomial([ 1. , -1.88494037, 0.0178126 ], [-1., 1.]) > >> >>> pr = p.roots() > >> >>> pr > >> array([ 0.53320748, 105.28741219]) > >> >>> poly.Polynomial.fromroots(pr) > >> Polynomial([ 56.14003571, -105.82061967, 1. ], [-1., 1.]) > >> >>> > >> > >> renormalizing > >> > >> >>> p2 = poly.Polynomial.fromroots(pr) > >> >>> p2/p2.coef[0] > >> Polynomial([ 1. , -1.88494037, 0.0178126 ], [-1., 1.]) > >> > >> > >> this is, I think what I want to do, invert roots that are > >> inside/outside the unit circle (whatever that means > >> > >> >>> pr[np.abs(pr)<1] = 1./pr[np.abs(pr)<1] > >> >>> p3 = poly.Polynomial.fromroots(pr) > >> >>> p3/p3.coef[0] > >> Polynomial([ 1. , -0.54270529, 0.0050643 ], [-1., 1.]) > >> > > > > Wrong function ;) You defined the polynomial by its coefficients. What > you > > want to do is > > My coefficients are from a lag-polynomial in time series analysis > (ARMA), and they really are the (estimated) coefficients. It is > essentially the same as the model for scipy.signal.lfilter. > I just need to check the roots to see whether the process is > stationary and invertible. If one of the two lag-polynomials (moving > average) has roots on the wrong side of the unit circle, then I can > invert them. > > I'm coding from memory of how this is supposed to work, so maybe I'm > back to RTFM and RTFTB (TB=text book). > > (I think what I really would need is a z-transform, but I don't have > much of an idea how to do this on a computer) > > Thanks, the main thing I need to do is check the convention or > definition for the normalization. And as btw, I like that the coef are > in increasing order > e.g. seasonal differencing multiplied with 1 lag autoregressive > poly.Polynomial([1.,0,0,-1])*poly.Polynomial([1,0.8]) > > The polynomial is obtained from the product of the terms (x - r_i), so it is monic. In a different basis it may not appear that way: In [23]: p = poly.Legendre.fromroots([1, -1.88494037, 0.0178126 ]) In [24]: p Out[24]: Legendre([ 0.32261828, -1.30070346, 0.57808518, 0.4 ], [-1., 1.]) The z transform of a sequence is simply the polynomial with 1/z in place of x, so you just need to invert all the roots. However, the easy way to look at it is that you are finding \alpha such that \alpha^n is a solution to the homogeneous equation. For instance, if y_n = a*y_{n - 1} + b*y_{n-2}, and you just substitute and divide out the extraneous powers, you will get \alpha^2 = a*\alpha + b. If one of the roots has a modulus bigger than 1 then it will grow geometrically with n, meaning that roundoff errors are likely to overwhelm the result. That is the unstable case. It is actually the discrete version of solving homogeneous linear differential equations with constant coefficients, so repeated roots need some care. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmarch at enthought.com Sat Oct 9 23:05:14 2010 From: jmarch at enthought.com (Jonathan March) Date: Sat, 9 Oct 2010 22:05:14 -0500 Subject: [Numpy-discussion] known failure test decorator not treated as expected by nose In-Reply-To: References: Message-ID: On Fri, Oct 8, 2010 at 6:46 PM, Ralf Gommers wrote: > > > On Fri, Oct 8, 2010 at 1:09 AM, Jonathan March wrote: > >> On Wed, Oct 6, 2010 at 6:17 PM, wrote: >> > On Wed, Oct 6, 2010 at 7:08 PM, Jonathan March >> wrote: >> >> It appears that the numpy testing decorators for skipping and for >> >> known failure should behave similarly to each other, at least from >> >> their descriptions here: >> >> >> http://projects.scipy.org/numpy/wiki/TestingGuidelines#known-failures-skipping-tests >> >> >> >> Yet in the following example, run under nose, they behave quite >> differently: >> >> >> >> ==== >> >> from numpy.testing import dec >> >> >> >> @dec.knownfailureif( True, "known failure test message") >> >> def test_will_fail(): >> >> pass >> >> >> >> @dec.skipif( True, "skip test message") >> >> def test_to_skip(): >> >> pass >> >> ==== >> >> >> >> The skipped test is marked as "S" as expected, but when the >> >> KnownFailureTest exception is raised, nose handles it as an error >> >> (marked "E" rather than "K" as expected, and printing the stack >> >> trace.) >> >> >> >> It's also interesting that nose has a --no-skip option but no >> >> corresponding option for ignoring known failure decorators. >> >> >> >> Why the discrepancy? Who is out of step with whom? This is with numpy >> >> 1.4.0 and nosetests 0.11.3 >> > >> > just as additional information >> > >> > This only happens on the command line, with nosetests packagename >> > but not with the function, packagename.test() >> > >> > > Knownfailure is a numpy-specific plugin, which needs to be loaded for tests > decorated with @dec.knownfailureif to be marked as K instead of E. This > plugin loading is done by the NoseTester class (defined in > numpy/testing/nosetester.py) which is used when tests are run through > numpy.test(). > > Using 'nosetests' on the command line skips this plugin loading, hence the > error. Nose does have a "skip" plugin so that never gives an error. > > >> > Josef >> >> >> Numpy issue, nose issue, or user issue? >> > > User issue. > Thank you, Ralf. Very clear. I've opened a ticket on the corresponding documentation: http://projects.scipy.org/numpy/ticket/1630 Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Sat Oct 9 23:09:24 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Sat, 9 Oct 2010 21:09:24 -0600 Subject: [Numpy-discussion] polynomial fromroots In-Reply-To: References: Message-ID: On Sat, Oct 9, 2010 at 9:01 PM, Charles R Harris wrote: > > > On Sat, Oct 9, 2010 at 8:36 PM, wrote: > >> On Sat, Oct 9, 2010 at 10:01 PM, Charles R Harris >> wrote: >> > >> > >> > On Sat, Oct 9, 2010 at 7:47 PM, wrote: >> >> >> >> I'm trying to see whether I can do this without reading the full >> manual. >> >> >> >> Is it intended that fromroots normalizes the highest order term >> >> instead of the lowest? >> >> >> >> >> >> >>> import numpy.polynomial as poly >> >> >> >> >>> p = poly.Polynomial([1, -1.88494037, 0.0178126 ]) >> >> >>> p >> >> Polynomial([ 1. , -1.88494037, 0.0178126 ], [-1., 1.]) >> >> >>> pr = p.roots() >> >> >>> pr >> >> array([ 0.53320748, 105.28741219]) >> >> >>> poly.Polynomial.fromroots(pr) >> >> Polynomial([ 56.14003571, -105.82061967, 1. ], [-1., 1.]) >> >> >>> >> >> >> >> renormalizing >> >> >> >> >>> p2 = poly.Polynomial.fromroots(pr) >> >> >>> p2/p2.coef[0] >> >> Polynomial([ 1. , -1.88494037, 0.0178126 ], [-1., 1.]) >> >> >> >> >> >> this is, I think what I want to do, invert roots that are >> >> inside/outside the unit circle (whatever that means >> >> >> >> >>> pr[np.abs(pr)<1] = 1./pr[np.abs(pr)<1] >> >> >>> p3 = poly.Polynomial.fromroots(pr) >> >> >>> p3/p3.coef[0] >> >> Polynomial([ 1. , -0.54270529, 0.0050643 ], [-1., 1.]) >> >> >> > >> > Wrong function ;) You defined the polynomial by its coefficients. What >> you >> > want to do is >> >> My coefficients are from a lag-polynomial in time series analysis >> (ARMA), and they really are the (estimated) coefficients. It is >> essentially the same as the model for scipy.signal.lfilter. >> I just need to check the roots to see whether the process is >> stationary and invertible. If one of the two lag-polynomials (moving >> average) has roots on the wrong side of the unit circle, then I can >> invert them. >> >> I'm coding from memory of how this is supposed to work, so maybe I'm >> back to RTFM and RTFTB (TB=text book). >> >> (I think what I really would need is a z-transform, but I don't have >> much of an idea how to do this on a computer) >> >> Thanks, the main thing I need to do is check the convention or >> definition for the normalization. And as btw, I like that the coef are >> in increasing order >> e.g. seasonal differencing multiplied with 1 lag autoregressive >> poly.Polynomial([1.,0,0,-1])*poly.Polynomial([1,0.8]) >> >> > The polynomial is obtained from the product of the terms (x - r_i), so it > is monic. In a different basis it may not appear that way: > > In [23]: p = poly.Legendre.fromroots([1, -1.88494037, 0.0178126 ]) > > In [24]: p > Out[24]: Legendre([ 0.32261828, -1.30070346, 0.57808518, 0.4 ], > [-1., 1.]) > > The z transform of a sequence is simply the polynomial with 1/z in place of > x, so you just need to invert all the roots. > More precisely, a unit lag is 1/z. You can turn it into the Fourier transform by substituting exp(j*2*pi*f) for z. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Sun Oct 10 01:34:43 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Sun, 10 Oct 2010 13:34:43 +0800 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: References: Message-ID: On Sun, Oct 10, 2010 at 2:59 AM, Vincent Davis wrote: > Did you get any responses on this? I can install 10.5 and help out > with some testing. I have a macbookpro that does not turn of (Hardware > issue) but it is good for testing. I could setup remote access on this > if of interest to you. > Yes I got one response at http://projects.scipy.org/numpy/ticket/1322, a negative one unfortunately. My conclusion is that binaries built on 10.6 do not work on 10.5 even when using the correct SDK and deployment target. A lot of software seems to have this same problem. Backward compatibility on OS X is good, but forward compatibility is not. Sage distributes separate binaries for each OS X version, presumably compiled on those same versions. If we want to have a 10.5 binary we should just do the same. However, gives the lack of responses I'm not sure how much of a need there is for 10.5 binaries (please speak up ...). The binary naming scheme should also change to include the version. > > Is there anything like the Python devs build bot for automated install > and testing testing of numpy and scipy? > There's a numpy buildbot: http://buildbot.scipy.org/, but it does not build/install binaries. I also just noticed it has not been updated for the switch to git - perhaps an indication of how much attention we're paying to it. Ralf > Vincent > > On Tue, Sep 21, 2010 at 8:57 AM, Ralf Gommers > wrote: > > Hi, > > > > There have been many reports from OS X 10.5(.8) users that the provided > > binaries on Sourceforge for numpy versions >= 1.4.0 do not work, see > > http://projects.scipy.org/numpy/ticket/1322. If you're an OS X 10.5 user > I > > would like your help to test if the same issue occurs for the following > > binary: > > > http://sourceforge.net/projects/numpy/files/Temporary/numpy-2.0.0.dev-py2.6-osx10.5-python.org.dmg/download > > Please comment on the above ticket. > > > > Thanks, > > Ralf > > > > > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion at scipy.org > > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > > > > > -- > Thanks > Vincent Davis > 720-301-3003 > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cournape at gmail.com Sun Oct 10 02:21:42 2010 From: cournape at gmail.com (David Cournapeau) Date: Sun, 10 Oct 2010 15:21:42 +0900 Subject: [Numpy-discussion] [ANN] Bento 0.0.4 release Message-ID: Hi, I am pleased to announce the release 0.0.4 for Bento. This release is a significant milestone, as it is able to build both numpy and scipy on some platforms (Linux and mac os x). The main features are: - New hooks to modify, override compilation options on a per extension basis. - Recursive package description support - Option to generate a python module containing all install paths, to avoid using __file__ without depending on complex tools ala pkg_resources. - Improved documentation - Some work toward python 3 support (does not work yet for complex packages) Concerning numpy/scipy bento-based builds, a few interesting facts: - amount of code for both numpy/scipy is smaller than scons-based or distutils-based builds. - by playing a bit with options and using clang, you can build a full debug build of numpy in 5-6 seconds, and ~ 40 seconds for scipy on a recent computer. - _bento_build branches for numpy and scipy are found on my account http://github.com/cournape You can download bento on github: http://github.com/cournape/Bento, and look at the documentation on http://cournape.github.com/Bento/html/index.html. cheers, David _______________________________________________ From jsseabold at gmail.com Sun Oct 10 13:38:18 2010 From: jsseabold at gmail.com (Skipper Seabold) Date: Sun, 10 Oct 2010 13:38:18 -0400 Subject: [Numpy-discussion] polynomial fromroots In-Reply-To: References: Message-ID: On Sat, Oct 9, 2010 at 10:36 PM, wrote: > On Sat, Oct 9, 2010 at 10:01 PM, Charles R Harris > wrote: >> >> >> On Sat, Oct 9, 2010 at 7:47 PM, wrote: >>> >>> I'm trying to see whether I can do this without reading the full manual. >>> >>> Is it intended that fromroots normalizes the highest order term >>> instead of the lowest? >>> >>> >>> >>> import numpy.polynomial as poly >>> >>> >>> p = poly.Polynomial([1, -1.88494037, ?0.0178126 ]) >>> >>> p >>> Polynomial([ 1. ? ? ? ?, -1.88494037, ?0.0178126 ], [-1., ?1.]) >>> >>> pr = p.roots() >>> >>> pr >>> array([ ? 0.53320748, ?105.28741219]) >>> >>> poly.Polynomial.fromroots(pr) >>> Polynomial([ ?56.14003571, -105.82061967, ? ?1. ? ? ? ?], [-1., ?1.]) >>> >>> >>> >>> renormalizing >>> >>> >>> p2 = poly.Polynomial.fromroots(pr) >>> >>> p2/p2.coef[0] >>> Polynomial([ 1. ? ? ? ?, -1.88494037, ?0.0178126 ], [-1., ?1.]) >>> >>> >>> this is, I think what I want to do, invert roots that are >>> inside/outside the unit circle (whatever that means >>> >>> >>> pr[np.abs(pr)<1] = 1./pr[np.abs(pr)<1] >>> >>> p3 = poly.Polynomial.fromroots(pr) >>> >>> p3/p3.coef[0] >>> Polynomial([ 1. ? ? ? ?, -0.54270529, ?0.0050643 ], [-1., ?1.]) >>> >> >> Wrong function ;) You defined the polynomial by its coefficients. What you >> want to do is > > My coefficients are from a lag-polynomial in time series analysis > (ARMA), and they really are the (estimated) coefficients. It is > essentially the same as the model for scipy.signal.lfilter. > I just need to check the roots to see whether the process is > stationary and invertible. If one of the two lag-polynomials (moving > average) has roots on the wrong side of the unit circle, then I can > invert them. > I have just been doing np.roots(np.r_[1,ma_params]) and the MA coefficients are invertible if np.abs(np.roots(np.r_[1,ma_params])) < 1 That is the solution to (L**q + L**(q-1)*macoef[0] + ... + macoef[q-1]) = 0 are inside the unit circle Gretl, for example, uses the inverse of this so that the MA coefficients are invertible if (1 + macoef[0]*L + macoef[1]*L**2 + ... + macoef[q-1]*L**q) are outside the unit circle, which uses the complex inverse 1/np.roots(np.r_[1,ma_params]) or np.roots(np.r_[1,ma_params][::-1]) with the roots in reverse order of the original coefficients. The AR coefficients are the same, except the parameters should be subtracted. Ie., np.roots(np.r_[1,-ar_params]) should be inside the unit circle for stationarity. Skipper > I'm coding from memory of how this is supposed to work, so maybe I'm > back to RTFM and RTFTB (TB=text book). > > (I think what I really would need is a z-transform, but I don't have > much of an idea how to do this on a computer) > > Thanks, the main thing I need to do is check the convention or > definition for the normalization. And as btw, I like that the coef are > in increasing order > e.g. seasonal differencing multiplied with 1 lag autoregressive > poly.Polynomial([1.,0,0,-1])*poly.Polynomial([1,0.8]) > > (I saw your next message: Last time I played with function > approximation, ?I didn't figure out what the basis does, but it worked > well without touching it) > > Josef > >> >> In [1]: import numpy.polynomial as poly >> >> In [2]: p = poly.Polynomial.fromroots([1, -1.88494037,? 0.0178126 ]) >> >> In [3]: p >> Out[3]: Polynomial([ 0.03357569, -1.90070346,? 0.86712777,? 1.??????? ], >> [-1.,? 1.]) >> >> In [4]: p.roots() >> Out[4]: array([-1.88494037,? 0.0178126 ,? 1.??????? ]) >> >> Chuck >> >> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> >> > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > From josef.pktd at gmail.com Sun Oct 10 14:19:02 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Sun, 10 Oct 2010 14:19:02 -0400 Subject: [Numpy-discussion] polynomial fromroots In-Reply-To: References: Message-ID: On Sun, Oct 10, 2010 at 1:38 PM, Skipper Seabold wrote: > On Sat, Oct 9, 2010 at 10:36 PM, ? wrote: >> On Sat, Oct 9, 2010 at 10:01 PM, Charles R Harris >> wrote: >>> >>> >>> On Sat, Oct 9, 2010 at 7:47 PM, wrote: >>>> >>>> I'm trying to see whether I can do this without reading the full manual. >>>> >>>> Is it intended that fromroots normalizes the highest order term >>>> instead of the lowest? >>>> >>>> >>>> >>> import numpy.polynomial as poly >>>> >>>> >>> p = poly.Polynomial([1, -1.88494037, ?0.0178126 ]) >>>> >>> p >>>> Polynomial([ 1. ? ? ? ?, -1.88494037, ?0.0178126 ], [-1., ?1.]) >>>> >>> pr = p.roots() >>>> >>> pr >>>> array([ ? 0.53320748, ?105.28741219]) >>>> >>> poly.Polynomial.fromroots(pr) >>>> Polynomial([ ?56.14003571, -105.82061967, ? ?1. ? ? ? ?], [-1., ?1.]) >>>> >>> >>>> >>>> renormalizing >>>> >>>> >>> p2 = poly.Polynomial.fromroots(pr) >>>> >>> p2/p2.coef[0] >>>> Polynomial([ 1. ? ? ? ?, -1.88494037, ?0.0178126 ], [-1., ?1.]) >>>> >>>> >>>> this is, I think what I want to do, invert roots that are >>>> inside/outside the unit circle (whatever that means >>>> >>>> >>> pr[np.abs(pr)<1] = 1./pr[np.abs(pr)<1] >>>> >>> p3 = poly.Polynomial.fromroots(pr) >>>> >>> p3/p3.coef[0] >>>> Polynomial([ 1. ? ? ? ?, -0.54270529, ?0.0050643 ], [-1., ?1.]) >>>> >>> >>> Wrong function ;) You defined the polynomial by its coefficients. What you >>> want to do is >> >> My coefficients are from a lag-polynomial in time series analysis >> (ARMA), and they really are the (estimated) coefficients. It is >> essentially the same as the model for scipy.signal.lfilter. >> I just need to check the roots to see whether the process is >> stationary and invertible. If one of the two lag-polynomials (moving >> average) has roots on the wrong side of the unit circle, then I can >> invert them. >> > > I have just been doing > > np.roots(np.r_[1,ma_params]) > > and the MA coefficients are invertible if > > np.abs(np.roots(np.r_[1,ma_params])) < 1 > > That is the solution to (L**q + L**(q-1)*macoef[0] + ... + > macoef[q-1]) = 0 are inside the unit circle > > Gretl, for example, uses the inverse of this so that the MA > coefficients are invertible if > > (1 + macoef[0]*L + macoef[1]*L**2 + ... + macoef[q-1]*L**q) are > outside the unit circle, which uses the complex inverse > > 1/np.roots(np.r_[1,ma_params]) > > or > > np.roots(np.r_[1,ma_params][::-1]) > > with the roots in reverse order of the original coefficients. ?The AR > coefficients are the same, except the parameters should be subtracted. > ?Ie., > > np.roots(np.r_[1,-ar_params]) > > should be inside the unit circle for stationarity. Good, this confirms the differences in convention z, or 1/z (and why I never remember if the roots are supposed to be inside or outside the unit circle) >>> arpoly.coef array([ 1. , -0.66073887, 0.30417894]) >>> arpoly.roots() array([ 1.08610225-1.45186791j, 1.08610225+1.45186791j]) >>> np.roots(arpoly.coef) array([ 0.33036944+0.44162765j, 0.33036944-0.44162765j]) e.g. dividing polynomials >>> poly.Polynomial([1,0.5,0,0,0, 0 , 0,0,0,0,0][::-1], [-1., 1.])/poly.Polynomial([1, -0.8][::-1]) Polynomial([ 0.21810381, 0.27262976, 0.3407872 , 0.425984 , 0.53248 , 0.6656 , 0.832 , 1.04 , 1.3 , 1. ], [-1., 1.]) >>> import scikits.statsmodels.sandbox.tsa.arima as tsat >>> tsat.arma2ma([1,-0.8],[1, 0.5],10) array([ 1. , 1.3 , 1.04 , 0.832 , 0.6656 , 0.53248 , 0.425984 , 0.3407872 , 0.27262976, 0.21810381]) Thanks, Josef > > Skipper > >> I'm coding from memory of how this is supposed to work, so maybe I'm >> back to RTFM and RTFTB (TB=text book). >> >> (I think what I really would need is a z-transform, but I don't have >> much of an idea how to do this on a computer) >> >> Thanks, the main thing I need to do is check the convention or >> definition for the normalization. And as btw, I like that the coef are >> in increasing order >> e.g. seasonal differencing multiplied with 1 lag autoregressive >> poly.Polynomial([1.,0,0,-1])*poly.Polynomial([1,0.8]) >> >> (I saw your next message: Last time I played with function >> approximation, ?I didn't figure out what the basis does, but it worked >> well without touching it) >> >> Josef >> >>> >>> In [1]: import numpy.polynomial as poly >>> >>> In [2]: p = poly.Polynomial.fromroots([1, -1.88494037,? 0.0178126 ]) >>> >>> In [3]: p >>> Out[3]: Polynomial([ 0.03357569, -1.90070346,? 0.86712777,? 1.??????? ], >>> [-1.,? 1.]) >>> >>> In [4]: p.roots() >>> Out[4]: array([-1.88494037,? 0.0178126 ,? 1.??????? ]) >>> >>> Chuck >>> >>> >>> _______________________________________________ >>> NumPy-Discussion mailing list >>> NumPy-Discussion at scipy.org >>> http://mail.scipy.org/mailman/listinfo/numpy-discussion >>> >>> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > From friedrichromstedt at gmail.com Sun Oct 10 14:46:23 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Sun, 10 Oct 2010 20:46:23 +0200 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: References: Message-ID: 2010/10/9 Vincent Davis : > Did you get any responses on this? I can install 10.5 and help out > with some testing. I have a macbookpro that does not turn of (Hardware > issue) but it is good for testing. I could setup remote access on this > if of interest to you. I can also help with the installer - I have some (some) experience with building Mac OS X installers using the PackageMaker provided by Apple. Just lacking a 10.5. But since I need some anyway (for controlling a 10.5 server), Vincent, if you don't need your 10.5 anymore, can we transfer the license in some way from you to me? I'm serious, one cannot buy 10.5 from Apple anymore, and I need a legal license. I have 10.6 and a VMware Fusion v3. When anyone can inform me how the installation scheme for numpy binaries is I can then provide the installers, I believe. I strongly support 10.5 support, I believe we should support at least the next to last version. For my own installer for upy, I followed the route: Unpacking the package into some /private/var/tmp directory, and running setup.py install there (since we are root when installing). upy is pure Python, no compilation. I see so far three routes for numpy: a) just installing the precompiled binaries using a setup.py file, b) compiling in the background for the user (shouldn't be a problem on Mac OS X, and would give us opportunity to include support for complementary packages in a "binary installer". Tough it wouldn't be really binary anymore.) c) Hardcoding the /Frameworks/ directory and simply copying. What do we like best? Friedrich From silva at lma.cnrs-mrs.fr Sun Oct 10 15:28:02 2010 From: silva at lma.cnrs-mrs.fr (Fabrice Silva) Date: Sun, 10 Oct 2010 16:28:02 -0300 Subject: [Numpy-discussion] polynomial fromroots In-Reply-To: References: Message-ID: <1286738883.10784.18.camel@Portable-s2m.cnrs-mrs.fr> Le dimanche 10 octobre 2010 ? 14:19 -0400, josef.pktd at gmail.com a > Good, this confirms the differences in convention z, or 1/z (and why I > never remember if the roots are supposed to be inside or outside the > unit circle) Some tricks: * in z-transform, 1-sample delay (in time domain) correspond to z**(-1) multiplication: H(z) h[k] present (current instant) H(z)*z**(-N) h[k-N] past (N samples backward) H(z)*z**(+N) h[k+N] future (N samples forward) * in linear filter theory (or perhaps generally speaking), you may focus on causal filter, i.e. filter where current output depends on past samples. You then build a difference equation as a polynomial in z**(-1). * consider the following transform between z and w(complex) z=exp(+jwt) for some arbitrary t>0. z inside unit circle associates with an positive imaginary part of w. t->exp(jwt) is then a decaying (stable) function of time z outside the unit circle lead them to unstable function. That's why you should prefer roots of the roots of z**(-1) polynomial inside unit circle. -- Fabrice Silva From vincent at vincentdavis.net Mon Oct 11 00:20:01 2010 From: vincent at vincentdavis.net (Vincent Davis) Date: Sun, 10 Oct 2010 22:20:01 -0600 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: References: Message-ID: On Sun, Oct 10, 2010 at 12:46 PM, Friedrich Romstedt wrote: > 2010/10/9 Vincent Davis : >> Did you get any responses on this? I can install 10.5 and help out >> with some testing. I have a macbookpro that does not turn of (Hardware >> issue) but it is good for testing. I could setup remote access on this >> if of interest to you. > > I can also help with the installer - I have some (some) experience > with building Mac OS X installers using the PackageMaker provided by > Apple. ?Just lacking a 10.5. ?But since I need some anyway (for > controlling a 10.5 server), Vincent, if you don't need your 10.5 > anymore, can we transfer the license in some way from you to me? ?I'm > serious, one cannot buy 10.5 from Apple anymore, and I need a legal > license. ?I have 10.6 and a VMware Fusion v3. Let me see what I can do about getting you a license. Can you install regular osx (not server) as a vm machine ? I have 10.5 server running on vm. Vincent > > When anyone can inform me how the installation scheme for numpy > binaries is I can then provide the installers, I believe. ?I strongly > support 10.5 support, I believe we should support at least the next to > last version. > > For my own installer for upy, I followed the route: Unpacking the > package into some /private/var/tmp directory, and running setup.py > install there (since we are root when installing). ?upy is pure > Python, no compilation. ?I see so far three routes for numpy: a) just > installing the precompiled binaries using a setup.py file, b) > compiling in the background for the user (shouldn't be a problem on > Mac OS X, and would give us opportunity to include support for > complementary packages in a "binary installer". ?Tough it wouldn't be > really binary anymore.) ?c) Hardcoding the /Frameworks/ directory and > simply copying. > > What do we like best? > > Friedrich > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -- Thanks Vincent Davis 720-301-3003 From pearu.peterson at gmail.com Mon Oct 11 02:43:26 2010 From: pearu.peterson at gmail.com (Pearu Peterson) Date: Mon, 11 Oct 2010 09:43:26 +0300 Subject: [Numpy-discussion] compile fortran from python In-Reply-To: <20101009141817.5f5g6y7pk4ggc00s@webmail3.tkk.fi> References: <20101009141817.5f5g6y7pk4ggc00s@webmail3.tkk.fi> Message-ID: <4CB2B20E.2070103@cens.ioc.ee> Hi, You can create a setup.py file containing def configuration(parent_package='',top_path=None): from numpy.distutils.misc_util import Configuration config = Configuration(None,parent_package,top_path) config.add_library('flib', sources = [test.f95]) config.add_extension('ctest', sources = ['ctest.c'], libraries=['flib']) return config if __name__ == "__main__": from numpy.distutils.core import setup setup(configuration=configuration) #eof Running python setup.py config_fc --fcompiler=gnu95 build will build a Fortran library flib.a and link it to an extension module ctest.so. Use build_ext --inplace if ctest.so should end up in current working directory. Is that what you wanted to achieve? HTH, Pearu On 10/09/2010 02:18 PM, Ioan Ferencik wrote: > I would like to compile some Fortran code using python, build a > shared library, and link to it using python. But I get a message > saying the compiler does not recognise the extension of my file. > > this is my command: > > gcc -fPIC -c -shared -fno-underscoring test.f95 -o ./lib/libctest.so.1.0 > > what is the easiest method to achieve this? > I suspect I could create a custom extension and customise the > unixccompiler object or could I just use the compiler object defined > by f2py(fcompiler). > > Cheers > > > Ioan Ferencik > PhD student > Aalto University > School of Science and Technology > Faculty Of Civil and Env. Engineering > Lahti Center > Tel: +358505122707 > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion From ioan.ferencik at tkk.fi Mon Oct 11 06:03:56 2010 From: ioan.ferencik at tkk.fi (Ioan Ferencik) Date: Mon, 11 Oct 2010 13:03:56 +0300 Subject: [Numpy-discussion] PyArg_ParseTuple Message-ID: <20101011130356.zd66gjtzusgo8swg@webmail3.tkk.fi> I would like to aks where can I find more detaile dinfo on PyArg_ParseTuple function. I find the doc limited on the matter. Mainly I am curious why the function requires an address of a pointer. I have issues in the following case: in python int jmax = 16 print type(jmax) which is just all right but following C code seems to be working PyObject *jmax_o = NULL; if(!PyArg_ParseTuple(args, "i", &jmax_o)){ goto error; } but PyInt_Check(jmax_o) fails. I tried to debug and this is what i could see Program received signal SIGSEGV, Segmentation fault. 0x00007ffff67a75bd in fprintf (self=, args=(16,)) at /usr/include/bits/stdio2.h:98 98 return __fprintf_chk (__stream, __USE_FORTIFY_LEVEL - 1, __fmt, so for some reason the jmax_o can not be converted to int. I use a x86_64 ubuntu and i suspect it could be because of 64 bits arch. Cheers Ioan Ferencik PhD student Aalto University School of Science and Technology Faculty Of Civil and Env. Engineering Lahti Center Tel: +358505122707 From pav at iki.fi Mon Oct 11 07:07:39 2010 From: pav at iki.fi (Pauli Virtanen) Date: Mon, 11 Oct 2010 11:07:39 +0000 (UTC) Subject: [Numpy-discussion] PyArg_ParseTuple References: <20101011130356.zd66gjtzusgo8swg@webmail3.tkk.fi> Message-ID: Mon, 11 Oct 2010 13:03:56 +0300, Ioan Ferencik wrote: > I would like to aks where can I find more detaile dinfo on > PyArg_ParseTuple function. This is off-topic for this list. See docs.python.org or ask on the Python lists: http://python.org/community/lists/ From ralf.gommers at googlemail.com Mon Oct 11 09:34:58 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Mon, 11 Oct 2010 21:34:58 +0800 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: References: Message-ID: Hi Friedrich, On Mon, Oct 11, 2010 at 2:46 AM, Friedrich Romstedt < friedrichromstedt at gmail.com> wrote: > 2010/10/9 Vincent Davis : > > Did you get any responses on this? I can install 10.5 and help out > > with some testing. I have a macbookpro that does not turn of (Hardware > > issue) but it is good for testing. I could setup remote access on this > > if of interest to you. > > I can also help with the installer That would be very helpful, thanks. Please keep me up to date on your progress with the 10.5 license, and once you are set up we can coordinate building the binaries. > - I have some (some) experience > with building Mac OS X installers using the PackageMaker provided by > Apple. Just lacking a 10.5. But since I need some anyway (for > controlling a 10.5 server), Vincent, if you don't need your 10.5 > anymore, can we transfer the license in some way from you to me? I'm > serious, one cannot buy 10.5 from Apple anymore, and I need a legal > license. I have 10.6 and a VMware Fusion v3. > > When anyone can inform me how the installation scheme for numpy > binaries is I can then provide the installers, I believe. The toolchain you need is documented at http://projects.scipy.org/numpy/wiki/MakingReleases. If you have all the dependencies it's simply a matter of $ paver dmg -p 2.5 (or 2.6/7) and a dmg installer is built. > I strongly > support 10.5 support, I believe we should support at least the next to > last version. > > For my own installer for upy, I followed the route: Unpacking the > package into some /private/var/tmp directory, and running setup.py > install there (since we are root when installing). upy is pure > Python, no compilation. I see so far three routes for numpy: a) just > installing the precompiled binaries using a setup.py file, b) > compiling in the background for the user (shouldn't be a problem on > Mac OS X, and would give us opportunity to include support for > complementary packages in a "binary installer". Tough it wouldn't be > really binary anymore.) c) Hardcoding the /Frameworks/ directory and > simply copying. > > The way it works is (c), so for the binaries the installers from python.org are the one we build against. The dmg contains an mpkg plus built docs. Of your other options, (a) would be similar only less user-friendly, (b) is a very bad idea. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent at vincentdavis.net Mon Oct 11 11:14:24 2010 From: vincent at vincentdavis.net (Vincent Davis) Date: Mon, 11 Oct 2010 09:14:24 -0600 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: References: Message-ID: On Mon, Oct 11, 2010 at 7:34 AM, Ralf Gommers wrote: > Hi Friedrich, > > On Mon, Oct 11, 2010 at 2:46 AM, Friedrich Romstedt > wrote: >> >> 2010/10/9 Vincent Davis : >> > Did you get any responses on this? I can install 10.5 and help out >> > with some testing. I have a macbookpro that does not turn of (Hardware >> > issue) but it is good for testing. I could setup remote access on this >> > if of interest to you. >> >> I can also help with the installer > > That would be very helpful, thanks. Please keep me up to date on your > progress with the 10.5 license, and once you are set up we can coordinate > building the binaries. > >> >> - I have some (some) experience >> with building Mac OS X installers using the PackageMaker provided by >> Apple. ?Just lacking a 10.5. ?But since I need some anyway (for >> controlling a 10.5 server), Vincent, if you don't need your 10.5 >> anymore, can we transfer the license in some way from you to me? ?I'm >> serious, one cannot buy 10.5 from Apple anymore, and I need a legal >> license. ?I have 10.6 and a VMware Fusion v3. >> >> When anyone can inform me how the installation scheme for numpy >> binaries is I can then provide the installers, I believe. > > The toolchain you need is documented at > http://projects.scipy.org/numpy/wiki/MakingReleases. If you have all the > dependencies it's simply a matter of > ? $ paver dmg -p 2.5?? (or 2.6/7) > and a dmg installer is built. Is there any reason 10.5 server addition would not work for building release ? Friedrich, you can't just install 10.5 (non server) on vmware. I just tried, It responds This is not a server addition. There are hacks but... I'll try to do a few testes this week., Where does "numpy-macosx-installer " http://github.com/cournape/numpy-macosx-installer fit in to running this command. "paver dmg -p 2.5" or does it? I have installed from source many times but never built a dmg. Is there any interest in a current Dev snapshot dmg? And how about a numpy scipy combo dmg? A little bit of a separate issue, does the build bot or so,ething/one other than developers run numpy.test() to monitor test that may fail on different systems, as numpy scipy, python get updated. It seems like a bot could build everything from source weekly and commit a test log via git/github to monitor and record the condition and changes in tests. Maybe there is no point to this, just sound like a neat way to track test results. Vincent Davis 720-301-3003 > >> >> I strongly >> support 10.5 support, I believe we should support at least the next to >> last version. >> >> For my own installer for upy, I followed the route: Unpacking the >> package into some /private/var/tmp directory, and running setup.py >> install there (since we are root when installing). ?upy is pure >> Python, no compilation. ?I see so far three routes for numpy: a) just >> installing the precompiled binaries using a setup.py file, b) >> compiling in the background for the user (shouldn't be a problem on >> Mac OS X, and would give us opportunity to include support for >> complementary packages in a "binary installer". ?Tough it wouldn't be >> really binary anymore.) ?c) Hardcoding the /Frameworks/ directory and >> simply copying. >> > The way it works is (c), so for the binaries the installers from python.org > are the one we build against. The dmg contains an mpkg plus built docs. Of > your other options, (a) would be similar only less user-friendly, (b) is a > very bad idea. > > Cheers, > Ralf > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > -- Thanks Vincent Davis 720-301-3003 From doutriaux1 at llnl.gov Mon Oct 11 14:39:31 2010 From: doutriaux1 at llnl.gov (Charles Doutriaux) Date: Mon, 11 Oct 2010 11:39:31 -0700 Subject: [Numpy-discussion] numpy.distutils In-Reply-To: References: <4CAE4C75.2040105@llnl.gov> Message-ID: <4CB359E3.5040303@llnl.gov> Hi David, The behaviour is there in regular distutils, it is apparently a known bug, I'm copy/pasting their answer in there for information. thanks, C. Answer (from Tarek Ziade): This is a regression I introduced to fix the fact that the .so are not rebuilt we you do subtle changes in your project. We ended up reverting this, and the changes will be done in Distutils2. see: http://BLOCKEDbugs.python.org/issue8688 for the details. > On 10/7/10 9:39 PM, David Cournapeau wrote: > On Fri, Oct 8, 2010 at 7:40 AM, Charles Doutriaux wrote: > >> Did anybody else noticed this? Anybody know what changed (the fact that >> it's since Python 2.7 make me think it might be pure distutils related) > Could you check whether you still see the issue without using > numpy.distutils ? I actually would be surprised to see it as a > distutils issue proper, as somebody would have almost certainly > noticed it already. > >> Any insight on how distuils and numpy.distutils are related would be >> great too! > numpy.distutils uses distutils, but in an unconvential way, because it > needs to hook itself to internals. Hence, any non trivial change (and > even trivial, sometimes) can break numpy.distutils. > > cheers, > > David > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://BLOCKEDmail.scipy.org/mailman/listinfo/numpy-discussion > From pgmdevlist at gmail.com Mon Oct 11 17:30:31 2010 From: pgmdevlist at gmail.com (Pierre GM) Date: Mon, 11 Oct 2010 23:30:31 +0200 Subject: [Numpy-discussion] Commit rights on github Message-ID: <376ED4C4-3E7C-4E34-977C-FA2AAB71B6ED@gmail.com> All, Would any of you mind giving me commit rights on github? My handle is pierregm. Thanks a million in advance. P. From pgmdevlist at gmail.com Mon Oct 11 17:36:29 2010 From: pgmdevlist at gmail.com (Pierre GM) Date: Mon, 11 Oct 2010 23:36:29 +0200 Subject: [Numpy-discussion] Awaiting confirmation before closing tickets Message-ID: <27DF7F62-0EA2-4404-9A86-FC5769A4F84D@gmail.com> All, The following tickets could be closed if somebody confirmed everything works OK: * 1586: fixed in r8714 * 1593: fixed in r8715 * 1591: fixed in r8713 * 1493: fixed a while ago (sorry, I completely forgot to comment on it). Let me know how it goes and I'll close them. Or not. Thanks in advance P. From pav at iki.fi Mon Oct 11 19:06:44 2010 From: pav at iki.fi (Pauli Virtanen) Date: Mon, 11 Oct 2010 23:06:44 +0000 (UTC) Subject: [Numpy-discussion] Commit rights on github References: <376ED4C4-3E7C-4E34-977C-FA2AAB71B6ED@gmail.com> Message-ID: Mon, 11 Oct 2010 23:30:31 +0200, Pierre GM wrote: > Would any of you mind giving me commit rights on github? My handle is > pierregm. Thanks a million in advance. Granted. Cheers, Pauli From pgmdevlist at gmail.com Mon Oct 11 19:09:54 2010 From: pgmdevlist at gmail.com (Pierre GM) Date: Tue, 12 Oct 2010 01:09:54 +0200 Subject: [Numpy-discussion] Commit rights on github In-Reply-To: References: <376ED4C4-3E7C-4E34-977C-FA2AAB71B6ED@gmail.com> Message-ID: <6876EA03-20D6-4880-B795-FEE460C4DF71@gmail.com> On Oct 12, 2010, at 1:06 AM, Pauli Virtanen wrote: > Mon, 11 Oct 2010 23:30:31 +0200, Pierre GM wrote: >> Would any of you mind giving me commit rights on github? My handle is >> pierregm. Thanks a million in advance. > > Granted. Got it, thanks again! P. From matthew.brett at gmail.com Mon Oct 11 19:47:23 2010 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 11 Oct 2010 16:47:23 -0700 Subject: [Numpy-discussion] Development workflow Message-ID: Hi guys, Am I right in thinking that for the moment at least, the git workflow is basically the same as the svn workflow (everyone commiting to trunk)? I realize that this is not going to cheer anyone up, but is this the best workflow now? Who would decide? Best, Matthew From charlesr.harris at gmail.com Mon Oct 11 19:48:45 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Mon, 11 Oct 2010 17:48:45 -0600 Subject: [Numpy-discussion] Commit rights on github In-Reply-To: <6876EA03-20D6-4880-B795-FEE460C4DF71@gmail.com> References: <376ED4C4-3E7C-4E34-977C-FA2AAB71B6ED@gmail.com> <6876EA03-20D6-4880-B795-FEE460C4DF71@gmail.com> Message-ID: On Mon, Oct 11, 2010 at 5:09 PM, Pierre GM wrote: > > On Oct 12, 2010, at 1:06 AM, Pauli Virtanen wrote: > > > Mon, 11 Oct 2010 23:30:31 +0200, Pierre GM wrote: > >> Would any of you mind giving me commit rights on github? My handle is > >> pierregm. Thanks a million in advance. > > > > Granted. > > Got it, thanks again! > Umm, I think your first commit changed a lot more than you intended. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh.holbrook at gmail.com Mon Oct 11 19:56:59 2010 From: josh.holbrook at gmail.com (Joshua Holbrook) Date: Mon, 11 Oct 2010 15:56:59 -0800 Subject: [Numpy-discussion] Development workflow In-Reply-To: References: Message-ID: In projects I've worked on, most people have worked on their own repos, continually merging in changes from other repos to keep themselves current. I think this is generally a good approach for development, if a bit disorganized. In addition, obviously a group of people pushing to numpy/numpy is necessary. I would suggest core devs keeping numpy/numpy's development branch as "deployed" code, while starting new development on their own branches and merging them in as they see fit. Non-core developers can contribute by sending pull requests. In my opinion, I've seen a lot of people coming from SVN try to apply SVN-style workflow to git (and presumably other dvcs's), but git and the like (and Github!) allow for much more fine-tuned workflows in my opinion, and I think it's a mistake to ignore that. I'm just some guy, though, so I'm not sure my opinion has much weight. --Josh On Mon, Oct 11, 2010 at 3:47 PM, Matthew Brett wrote: > Hi guys, > > Am I right in thinking that for the moment at least, the git workflow > is basically the same as the svn workflow (everyone commiting to > trunk)? > > I realize that this is not going to cheer anyone up, but is this the > best workflow now? ? Who would decide? > > Best, > > Matthew > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > From vincent at vincentdavis.net Mon Oct 11 20:03:11 2010 From: vincent at vincentdavis.net (Vincent Davis) Date: Mon, 11 Oct 2010 18:03:11 -0600 Subject: [Numpy-discussion] equality of empty arrays Message-ID: I assume there is some reasoning behind this >>> m = np.array([]) >>> n = np.array([]) >>> m==n array([], dtype=bool) I was expecting somthing like. >>> m = [] >>> n = [] >>> m==n True What is the right way to test if an array is empty? -- Thanks Vincent Davis 720-301-3003 From goodfellow.ian at gmail.com Mon Oct 11 20:06:08 2010 From: goodfellow.ian at gmail.com (Ian Goodfellow) Date: Mon, 11 Oct 2010 20:06:08 -0400 Subject: [Numpy-discussion] equality of empty arrays In-Reply-To: References: Message-ID: The reasoning behind this is that == returns an array that specifies whether each element of the two arrays is equal. It's only defined if the arrays are the same shape (or maybe if they can be broadcasted to the same shape). The correct way to check if an array is empty is to inspect its .shape field. On Oct 11, 2010, at 8:03 PM, Vincent Davis wrote: > I assume there is some reasoning behind this >>>> m = np.array([]) >>>> n = np.array([]) >>>> m==n > array([], dtype=bool) > > I was expecting somthing like. >>>> m = [] >>>> n = [] >>>> m==n > True > > What is the right way to test if an array is empty? > > -- > Thanks > Vincent Davis > 720-301-3003 > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion From josef.pktd at gmail.com Mon Oct 11 20:07:17 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Mon, 11 Oct 2010 20:07:17 -0400 Subject: [Numpy-discussion] equality of empty arrays In-Reply-To: References: Message-ID: On Mon, Oct 11, 2010 at 8:06 PM, Ian Goodfellow wrote: > The reasoning behind this is that == returns an array that specifies > whether each element of the two arrays is equal. It's only defined if > the arrays are the same shape (or maybe if they can be broadcasted to > the same shape). > The correct way to check if an array is empty is to inspect its .shape > field. > > On Oct 11, 2010, at 8:03 PM, Vincent Davis wrote: > >> I assume there is some reasoning behind this >>>>> m = np.array([]) >>>>> n = np.array([]) >>>>> m==n >> array([], dtype=bool) >> >> I was expecting somthing like. >>>>> m = [] >>>>> n = [] >>>>> m==n >> True >> >> What is the right way to test if an array is empty? >>> np.array([]).size 0 Josef >> >> -- >> Thanks >> Vincent Davis >> 720-301-3003 >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > From brian1.thomas at ge.com Mon Oct 11 20:09:26 2010 From: brian1.thomas at ge.com (Thomas, Brian (GE Energy)) Date: Mon, 11 Oct 2010 20:09:26 -0400 Subject: [Numpy-discussion] equality of empty arrays In-Reply-To: References: Message-ID: <24F03932F9E5CA46AF1C322B9E27818503EB4084@CINMLVEM14.e2k.ad.ge.com> I am pretty new user, but I tend to use shape (n.shape) to check empty array. You can even check n.size to determine if its empty or not. Regards, Brian -----Original Message----- From: numpy-discussion-bounces at scipy.org [mailto:numpy-discussion-bounces at scipy.org] On Behalf Of Vincent Davis Sent: Monday, October 11, 2010 8:03 PM To: Discussion of Numerical Python Subject: [Numpy-discussion] equality of empty arrays I assume there is some reasoning behind this >>> m = np.array([]) >>> n = np.array([]) >>> m==n array([], dtype=bool) I was expecting somthing like. >>> m = [] >>> n = [] >>> m==n True What is the right way to test if an array is empty? -- Thanks Vincent Davis 720-301-3003 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion at scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion From charlesr.harris at gmail.com Mon Oct 11 20:39:18 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Mon, 11 Oct 2010 18:39:18 -0600 Subject: [Numpy-discussion] Development workflow In-Reply-To: References: Message-ID: On Mon, Oct 11, 2010 at 5:56 PM, Joshua Holbrook wrote: > In projects I've worked on, most people have worked on their own > repos, continually merging in changes from other repos to keep > themselves current. I think this is generally a good approach for > development, if a bit disorganized. In addition, obviously a group of > people pushing to numpy/numpy is necessary. I would suggest core devs > keeping numpy/numpy's development branch as "deployed" code, while > starting new development on their own branches and merging them in as > they see fit. Non-core developers can contribute by sending pull > requests. > > In my opinion, I've seen a lot of people coming from SVN try to apply > SVN-style workflow to git (and presumably other dvcs's), but git and > the like (and Github!) allow for much more fine-tuned workflows in my > opinion, and I think it's a mistake to ignore that. I'm just some guy, > though, so I'm not sure my opinion has much weight. > > I find having the branch displayed on the command line helpful in avoiding mishaps, so I have the following in my .bashrc export PS1='\[\033[1;31m\]\$\[\033[0m\]\u@\h \W$(__git_ps1 " (%s)")\\$ ' The \W$(__git_ps1 " (%s)") bit is the important part. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent at vincentdavis.net Mon Oct 11 20:58:56 2010 From: vincent at vincentdavis.net (Vincent Davis) Date: Mon, 11 Oct 2010 18:58:56 -0600 Subject: [Numpy-discussion] equality of empty arrays In-Reply-To: References: Message-ID: On Mon, Oct 11, 2010 at 6:06 PM, Ian Goodfellow wrote: > The reasoning behind this is that == returns an array that specifies > whether each element of the two arrays is equal. It's only defined if > the arrays are the same shape (or maybe if they can be broadcasted to > the same shape). >>> m.size==n.size True >>> m.shape==n.shape True Not sure about "be broadcasted to the same shape" I would kind of expect == to return true, false or some error. Thanks Vincent > The correct way to check if an array is empty is to inspect its .shape > field. > > On Oct 11, 2010, at 8:03 PM, Vincent Davis wrote: > >> I assume there is some reasoning behind this >>>>> m = np.array([]) >>>>> n = np.array([]) >>>>> m==n >> array([], dtype=bool) >> >> I was expecting somthing like. >>>>> m = [] >>>>> n = [] >>>>> m==n >> True >> >> What is the right way to test if an array is empty? >> >> -- >> Thanks >> Vincent Davis >> 720-301-3003 >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -- Thanks Vincent Davis 720-301-3003 From david at silveregg.co.jp Mon Oct 11 21:03:25 2010 From: david at silveregg.co.jp (David) Date: Tue, 12 Oct 2010 10:03:25 +0900 Subject: [Numpy-discussion] numpy.distutils In-Reply-To: <4CB359E3.5040303@llnl.gov> References: <4CAE4C75.2040105@llnl.gov> <4CB359E3.5040303@llnl.gov> Message-ID: <4CB3B3DD.60200@silveregg.co.jp> On 10/12/2010 03:39 AM, Charles Doutriaux wrote: > Hi David, > > The behaviour is there in regular distutils, it is apparently a known > bug, I'm copy/pasting their answer in there for information. I saw the discussion, thanks for the update. cheers, David From goodfellow.ian at gmail.com Mon Oct 11 21:04:51 2010 From: goodfellow.ian at gmail.com (Ian Goodfellow) Date: Mon, 11 Oct 2010 21:04:51 -0400 Subject: [Numpy-discussion] equality of empty arrays In-Reply-To: References: Message-ID: If the arrays are the same size or can be broadcasted to the same size, it returns true or false on an elementwise basis. If the arrays are not the same size and can't be broadcasted to the same size, it returns False, which was a surprise to me too. >>> import numpy as N >>> N.asarray([[0,1],[2,3]]) == N.asarray([[1,1],[3,3]]) array([[False, True], [False, True]], dtype=bool) >>> N.asarray([[0,1],[2,3]]) == N.asarray([[1,1]]) array([[False, True], [False, False]], dtype=bool) >>> N.asarray([[0,1],[2,3]]) == N.asarray([[1,1],[3,3],[5,5]]) False On Oct 11, 2010, at 8:58 PM, Vincent Davis wrote: > Not sure about "be broadcasted to the same shape" > I would kind of expect == to return true, false or some error. From danelliottster at gmail.com Mon Oct 11 21:05:51 2010 From: danelliottster at gmail.com (Daniel Elliott) Date: Tue, 12 Oct 2010 01:05:51 +0000 (UTC) Subject: [Numpy-discussion] inversion of large matrices References: <54848FA5-AD74-46E9-AE0B-3189FB40C104@cs.toronto.edu> <20A7F4F6-3F2A-47CF-AACE-8484AB92A0E3@cs.toronto.edu> <8eb37d6c43beda8bb89a0afab604e0d6.squirrel@webmail.uio.no> Message-ID: Sturla Molden molden.no> writes: > > Yes, this is what I am computing. I am computing the pdf of a very high- > > dimensional multivariate normal. Is there a specialized method to compute > > this? > > If you use cho_solve and cho_factor from scipy.linalg, you can proceed > like this: > > cx = X - m > sqmahal = (cx*cho_solve(cho_factor(S),cx.T).T).sum(axis=1) > > where X is the data (n x p), m is mean (1 x p) and S is the covariance (p > x p). > > We could do this twice as fast using a hypothetical method tri_solve that > calls LAPACK subroutine DTRTRS. Sorry for the laziness of this question... As a reminder, I am working with high-dimensional data (10K dimensions). I was computing the log of the MVN pdf because the probabilities would almost all go to zero. Do you suppose the method you have shown me will be numerically stable (the probabilities will be small but they stay above zero)? By the way, I would be happy to implement the method you desire in a couple months if you are willing to do a little hand-holding. Thanks for the excellent suggestion. - dan From ben.root at ou.edu Mon Oct 11 21:06:18 2010 From: ben.root at ou.edu (Benjamin Root) Date: Mon, 11 Oct 2010 20:06:18 -0500 Subject: [Numpy-discussion] equality of empty arrays In-Reply-To: References: Message-ID: On Mon, Oct 11, 2010 at 7:58 PM, Vincent Davis wrote: > On Mon, Oct 11, 2010 at 6:06 PM, Ian Goodfellow > wrote: > > The reasoning behind this is that == returns an array that specifies > > whether each element of the two arrays is equal. It's only defined if > > the arrays are the same shape (or maybe if they can be broadcasted to > > the same shape). > > >>> m.size==n.size > True > >>> m.shape==n.shape > True > Not sure about "be broadcasted to the same shape" > I would kind of expect == to return true, false or some error. > > Thanks > Vincent > > Maybe you are looking for numpy.allclose()? >>> n = np.array([]) >>> m = np.array([]) >>> np.allclose(n, m) True Ben Root -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at silveregg.co.jp Mon Oct 11 21:31:09 2010 From: david at silveregg.co.jp (David) Date: Tue, 12 Oct 2010 10:31:09 +0900 Subject: [Numpy-discussion] Commit rights on github In-Reply-To: References: <376ED4C4-3E7C-4E34-977C-FA2AAB71B6ED@gmail.com> <6876EA03-20D6-4880-B795-FEE460C4DF71@gmail.com> Message-ID: <4CB3BA5D.4080505@silveregg.co.jp> On 10/12/2010 08:48 AM, Charles R Harris wrote: > > > On Mon, Oct 11, 2010 at 5:09 PM, Pierre GM > wrote: > > > On Oct 12, 2010, at 1:06 AM, Pauli Virtanen wrote: > > > Mon, 11 Oct 2010 23:30:31 +0200, Pierre GM wrote: > >> Would any of you mind giving me commit rights on github? My > handle is > >> pierregm. Thanks a million in advance. > > > > Granted. > > Got it, thanks again! > > > Umm, I think your first commit changed a lot more than you intended. Indeed. Pierre, please revert this commit, and then commit what you intended: git revert a14dd542532d383610c1b01c5698b137dd058fea -m 2 # will revert all your changes git cherry-pick -n 61d945bdb5c9b2b3329e1b8468b5c7d0596dd9fc # apply the changes introduced by 61d945..., but do not commit Then, check that you don't add unnecessary files (eclipse files) before committing again. A good way to check what you are about to commit is to do git diff --stat --cached, cheers, David From charlesr.harris at gmail.com Mon Oct 11 22:12:47 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Mon, 11 Oct 2010 20:12:47 -0600 Subject: [Numpy-discussion] Commit rights on github In-Reply-To: <4CB3BA5D.4080505@silveregg.co.jp> References: <376ED4C4-3E7C-4E34-977C-FA2AAB71B6ED@gmail.com> <6876EA03-20D6-4880-B795-FEE460C4DF71@gmail.com> <4CB3BA5D.4080505@silveregg.co.jp> Message-ID: On Mon, Oct 11, 2010 at 7:31 PM, David wrote: > On 10/12/2010 08:48 AM, Charles R Harris wrote: > > > > > > On Mon, Oct 11, 2010 at 5:09 PM, Pierre GM > > wrote: > > > > > > On Oct 12, 2010, at 1:06 AM, Pauli Virtanen wrote: > > > > > Mon, 11 Oct 2010 23:30:31 +0200, Pierre GM wrote: > > >> Would any of you mind giving me commit rights on github? My > > handle is > > >> pierregm. Thanks a million in advance. > > > > > > Granted. > > > > Got it, thanks again! > > > > > > Umm, I think your first commit changed a lot more than you intended. > > Indeed. Pierre, please revert this commit, and then commit what you > intended: > > git revert a14dd542532d383610c1b01c5698b137dd058fea -m 2 # will revert > all your changes > git cherry-pick -n 61d945bdb5c9b2b3329e1b8468b5c7d0596dd9fc # apply the > changes introduced by 61d945..., but do not commit > > Then, check that you don't add unnecessary files (eclipse files) before > committing again. A good way to check what you are about to commit is to > do git diff --stat --cached, > > I can't quite figure out what commit a14dd542532d383610c1did or where it applied. Any hints? Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at silveregg.co.jp Tue Oct 12 00:37:49 2010 From: david at silveregg.co.jp (David) Date: Tue, 12 Oct 2010 13:37:49 +0900 Subject: [Numpy-discussion] Commit rights on github In-Reply-To: References: <376ED4C4-3E7C-4E34-977C-FA2AAB71B6ED@gmail.com> <6876EA03-20D6-4880-B795-FEE460C4DF71@gmail.com> <4CB3BA5D.4080505@silveregg.co.jp> Message-ID: <4CB3E61D.2000900@silveregg.co.jp> On 10/12/2010 11:12 AM, Charles R Harris wrote: > > > On Mon, Oct 11, 2010 at 7:31 PM, David > wrote: > > On 10/12/2010 08:48 AM, Charles R Harris wrote: > > > > > > On Mon, Oct 11, 2010 at 5:09 PM, Pierre GM > > >> wrote: > > > > > > On Oct 12, 2010, at 1:06 AM, Pauli Virtanen wrote: > > > > > Mon, 11 Oct 2010 23:30:31 +0200, Pierre GM wrote: > > >> Would any of you mind giving me commit rights on github? My > > handle is > > >> pierregm. Thanks a million in advance. > > > > > > Granted. > > > > Got it, thanks again! > > > > > > Umm, I think your first commit changed a lot more than you intended. > > Indeed. Pierre, please revert this commit, and then commit what you > intended: > > git revert # will revert > all your changes > git cherry-pick -n 61d945bdb5c9b2b3329e1b8468b5c7d0596dd9fc # apply the > changes introduced by 61d945..., but do not commit > > Then, check that you don't add unnecessary files (eclipse files) before > committing again. A good way to check what you are about to commit is to > do git diff --stat --cached, > > > I can't quite figure out what commit a14dd542532d383610c1 > > did or where it applied. Any hints? It is a merge commit: """ commit a14dd542532d383610c1b01c5698b137dd058fea Merge: 61d945b 11ee694 Author: pierregm Date: Mon Oct 11 23:02:10 2010 +0200 merging refs/remotes/origin/master into HEAD """ You can see that it has two parents (61d945b and 11ee694). 61d945b is another commit by PGM, whereas 11ee694 refers to the last "clean" commit by Pauli. For example, you can see this using the --graph option of git log: * commit a14dd542532d383610c1b01c5698b137dd058fea |\ Merge: 61d945b 11ee694 | | Author: pierregm | | Date: Mon Oct 11 23:02:10 2010 +0200 | | | | merging refs/remotes/origin/master into HEAD | | | * commit 11ee694744f2552d77652ed929fdc2b4ccca6843 | | Author: Pauli Virtanen | | Date: Mon Oct 11 00:40:13 2010 +0200 | | ... | * commit 4510c4a81185eed7e144f75ec5121f80bc924a6e | | Author: Pauli Virtanen | | Date: Fri Oct 1 11:15:38 2010 +0200 | | | | sphinxext: fix Other Parameters section parsing in docscrape | | * | commit 61d945bdb5c9b2b3329e1b8468b5c7d0596dd9fc |/ Author: pierregm | Date: Mon Oct 11 22:24:26 2010 +0200 | | Add more tests to test_eq_w_None (bug #1493) So by doing: git revert a14dd542532d383610c1b01c5698b137dd058fea -m 2 You are telling git to revert to its second parent (here 11ee6947). I don't know exactly what PGM did, maybe he mistakenly "unmerge" all the changes made from 61d945 and commit this. In that case, a way to avoid this mistake is to do the following: * make changes on your own git repository clone * once you have a set of changesets of commits, first update your branch from upstream (a bit like svn up) with git pull: at that point, git will try to merge your changes and upstream changes if there are divergences. You could also use the --rebase option of git pull, with the usual rebase caveats w.r.t. changes See here for a relatively clear explanation: http://yehudakatz.com/2010/05/13/common-git-workflows/, "Updating from the remote" section, cheers, David From matthew.brett at gmail.com Tue Oct 12 01:12:55 2010 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 11 Oct 2010 22:12:55 -0700 Subject: [Numpy-discussion] Development workflow In-Reply-To: References: Message-ID: Hi, > In my opinion, I've seen a lot of people coming from SVN try to apply > SVN-style workflow to git (and presumably other dvcs's), but git and > the like (and Github!) allow for much more fine-tuned workflows in my > opinion, and I think it's a mistake to ignore that. I'm just some guy, > though, so I'm not sure my opinion has much weight. Ah - yes - I know exactly what you mean ;) Best, Matthew From matthew.brett at gmail.com Tue Oct 12 01:16:05 2010 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 11 Oct 2010 22:16:05 -0700 Subject: [Numpy-discussion] Development workflow In-Reply-To: References: Message-ID: Hi, > I find having the branch displayed on the command line helpful in avoiding > mishaps, so I have the following in my .bashrc > > export PS1='\[\033[1;31m\]\$\[\033[0m\]\u@\h \W$(__git_ps1 " (%s)")\\$ ' > > The \W$(__git_ps1 " (%s)") bit is the important part. Yes, that one's a lifesaver. It's part of the truly excellent git-completion bash utilities too: http://blog.strug.de/2010/08/how-to-add-git-completion-to-your-terminal/ See you, Matthew From matthew.brett at gmail.com Tue Oct 12 01:52:22 2010 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 11 Oct 2010 22:52:22 -0700 Subject: [Numpy-discussion] Development workflow In-Reply-To: References: Message-ID: Hi, >> In my opinion, I've seen a lot of people coming from SVN try to apply >> SVN-style workflow to git (and presumably other dvcs's), but git and >> the like (and Github!) allow for much more fine-tuned workflows in my >> opinion, and I think it's a mistake to ignore that. I'm just some guy, >> though, so I'm not sure my opinion has much weight. > > Ah - yes - I know exactly what you mean ;) Sorry - just re-reading that - it's a bit cryptic. I mean, yes, I agree wholeheartedly that it's a shame to stick to svn workflows when using git. I'm just some guy as well of course. I suppose we just-some-guys should start an just-some-guys interest group or something ;) Best, Matthew From josh.holbrook at gmail.com Tue Oct 12 02:17:40 2010 From: josh.holbrook at gmail.com (Joshua Holbrook) Date: Mon, 11 Oct 2010 22:17:40 -0800 Subject: [Numpy-discussion] Development workflow In-Reply-To: References: Message-ID: On Mon, Oct 11, 2010 at 9:52 PM, Matthew Brett wrote: > Sorry - just re-reading that - it's a bit cryptic. ?I mean, yes, I > agree wholeheartedly that it's a shame to stick to svn workflows when > using git. ?I'm just some guy as well of course. ? I suppose we > just-some-guys should start an just-some-guys interest group or > something ;) > "The Association of We're Just Saying Is All." :) But yeah, I understood your meaning. --Josh > Best, > > Matthew > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > From stefan at sun.ac.za Tue Oct 12 03:02:43 2010 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 12 Oct 2010 09:02:43 +0200 Subject: [Numpy-discussion] Commit rights on github In-Reply-To: <4CB3E61D.2000900@silveregg.co.jp> References: <376ED4C4-3E7C-4E34-977C-FA2AAB71B6ED@gmail.com> <6876EA03-20D6-4880-B795-FEE460C4DF71@gmail.com> <4CB3BA5D.4080505@silveregg.co.jp> <4CB3E61D.2000900@silveregg.co.jp> Message-ID: On Tue, Oct 12, 2010 at 6:37 AM, David wrote: > In that case, a way to avoid this mistake is to do the following: > > ? * make changes on your own git repository clone > ? * once you have a set of changesets of commits, first update your > branch from upstream (a bit like svn up) with git pull: at that point, > git will try to merge your changes and upstream changes if there are > divergences. You could also use the --rebase option of git pull, with > the usual rebase caveats w.r.t. changes Now might be a good time to discuss how we'd like the history to look in a year from now. If we follow the above approach, I guess we may end up with one merge message for each small little bug-fix? (Unless --rebase is used) How do we ensure that "fast-forward" merges occur whenever possible? Regards St?fan From fperez.net at gmail.com Tue Oct 12 03:10:40 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 12 Oct 2010 00:10:40 -0700 Subject: [Numpy-discussion] [ANN] IPython 0.10.1 is out. Message-ID: Hi all, we've just released IPython 0.10.1, full release notes are below. Downloads in source and windows binary form are available in the usual location: http://ipython.scipy.org/dist/ But since our switch to github, we also get automatic distribution of archives there: http://github.com/ipython/ipython/archives/rel-0.10.1 and we've also started uploading archives to the Python Package Index (which easy_install will use by default): http://pypi.python.org/pypi/ipython so at any time you should find a location with good download speeds. You can find the full documentation at: http://ipython.scipy.org/doc/rel-0.10.1/html/index.html Enjoy! Fernando (on behalf of the whole IPython team) Release 0.10.1 ============== IPython 0.10.1 was released October 11, 2010, over a year after version 0.10. This is mostly a bugfix release, since after version 0.10 was released, the development team's energy has been focused on the 0.11 series. We have nonetheless tried to backport what fixes we could into 0.10.1, as it remains the stable series that many users have in production systems they rely on. Since the 0.11 series changes many APIs in backwards-incompatible ways, we are willing to continue maintaining the 0.10.x series. We don't really have time to actively write new code for 0.10.x, but we are happy to accept patches and pull requests on the IPython `github site`_. If sufficient contributions are made that improve 0.10.1, we will roll them into future releases. For this purpose, we will have a branch called 0.10.2 on github, on which you can base your contributions. .. _github site: http://github.com/ipython For this release, we applied approximately 60 commits totaling a diff of over 7000 lines:: (0.10.1)amirbar[dist]> git diff --oneline rel-0.10.. | wc -l 7296 Highlights of this release: - The only significant new feature is that IPython's parallel computing machinery now supports natively the Sun Grid Engine and LSF schedulers. This work was a joint contribution from Justin Riley, Satra Ghosh and Matthieu Brucher, who put a lot of work into it. We also improved traceback handling in remote tasks, as well as providing better control for remote task IDs. - New IPython Sphinx directive. You can use this directive to mark blocks in reSructuredText documents as containig IPython syntax (including figures) and the will be executed during the build:: .. ipython:: In [2]: plt.figure() # ensure a fresh figure @savefig psimple.png width=4in In [3]: plt.plot([1,2,3]) Out[3]: [] - Various fixes to the standalone ipython-wx application. - We now ship internally the excellent argparse library, graciously licensed under BSD terms by Steven Bethard. Now (2010) that argparse has become part of Python 2.7 this will be less of an issue, but Steven's relicensing allowed us to start updating IPython to using argparse well before Python 2.7. Many thanks! - Robustness improvements so that IPython doesn't crash if the readline library is absent (though obviously a lot of functionality that requires readline will not be available). - Improvements to tab completion in Emacs with Python 2.6. - Logging now supports timestamps (see ``%logstart?`` for full details). - A long-standing and quite annoying bug where parentheses would be added to ``print`` statements, under Python 2.5 and 2.6, was finally fixed. - Improved handling of libreadline on Apple OSX. - Fix ``reload`` method of IPython demos, which was broken. - Fixes for the ipipe/ibrowse system on OSX. - Fixes for Zope profile. - Fix %timeit reporting when the time is longer than 1000s. - Avoid lockups with ? or ?? in SunOS, due to a bug in termios. - The usual assortment of miscellaneous bug fixes and small improvements. The following people contributed to this release (please let us know if we omitted your name and we'll gladly fix this in the notes for the future): * Beni Cherniavsky * Boyd Waters. * David Warde-Farley * Fernando Perez * G?khan Sever * Justin Riley * Kiorky * Laurent Dufrechou * Mark E. Smith * Matthieu Brucher * Satrajit Ghosh * Sebastian Busch * V?clav ?milauer From cournape at gmail.com Tue Oct 12 03:47:52 2010 From: cournape at gmail.com (David Cournapeau) Date: Tue, 12 Oct 2010 16:47:52 +0900 Subject: [Numpy-discussion] Commit rights on github In-Reply-To: References: <376ED4C4-3E7C-4E34-977C-FA2AAB71B6ED@gmail.com> <6876EA03-20D6-4880-B795-FEE460C4DF71@gmail.com> <4CB3BA5D.4080505@silveregg.co.jp> <4CB3E61D.2000900@silveregg.co.jp> Message-ID: 2010/10/12 St?fan van der Walt : > On Tue, Oct 12, 2010 at 6:37 AM, David wrote: >> In that case, a way to avoid this mistake is to do the following: >> >> ? * make changes on your own git repository clone >> ? * once you have a set of changesets of commits, first update your >> branch from upstream (a bit like svn up) with git pull: at that point, >> git will try to merge your changes and upstream changes if there are >> divergences. You could also use the --rebase option of git pull, with >> the usual rebase caveats w.r.t. changes > > Now might be a good time to discuss how we'd like the history to look > in a year from now. ?If we follow the above approach, I guess we may > end up with one merge message for each small little bug-fix? (Unless > --rebase is used) ?How do we ensure that "fast-forward" merges occur > whenever possible? The only solution that I know of is to have a pull-like workflow, but I thought this was rejected as too complicated ? cheers, David From matthew.brett at gmail.com Tue Oct 12 03:57:37 2010 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 12 Oct 2010 00:57:37 -0700 Subject: [Numpy-discussion] Commit rights on github In-Reply-To: References: <376ED4C4-3E7C-4E34-977C-FA2AAB71B6ED@gmail.com> <6876EA03-20D6-4880-B795-FEE460C4DF71@gmail.com> <4CB3BA5D.4080505@silveregg.co.jp> <4CB3E61D.2000900@silveregg.co.jp> Message-ID: Hi, >> Now might be a good time to discuss how we'd like the history to look >> in a year from now. ?If we follow the above approach, I guess we may >> end up with one merge message for each small little bug-fix? (Unless >> --rebase is used) ?How do we ensure that "fast-forward" merges occur >> whenever possible? > > The only solution that I know of is to have a pull-like workflow, but > I thought this was rejected as too complicated ? Am I the only person to find it strange that we have an active and skilled development community, many of whom have been using git routinely for a long time, and we none of us seem to know what the agreed workflow is? I risk yet another deafening silence in asking - is there anyone who thinks that the current state of play is good? If the answer is no - then isn't there anyone who will step up to the plate and suggest something? I will certainly do it if given any sign that that is welcome. See y'all, Matthew From stefan at sun.ac.za Tue Oct 12 03:57:55 2010 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 12 Oct 2010 09:57:55 +0200 Subject: [Numpy-discussion] Commit rights on github In-Reply-To: References: <376ED4C4-3E7C-4E34-977C-FA2AAB71B6ED@gmail.com> <6876EA03-20D6-4880-B795-FEE460C4DF71@gmail.com> <4CB3BA5D.4080505@silveregg.co.jp> <4CB3E61D.2000900@silveregg.co.jp> Message-ID: On Tue, Oct 12, 2010 at 9:47 AM, David Cournapeau wrote: >> Now might be a good time to discuss how we'd like the history to look >> in a year from now. ?If we follow the above approach, I guess we may >> end up with one merge message for each small little bug-fix? (Unless >> --rebase is used) ?How do we ensure that "fast-forward" merges occur >> whenever possible? > > The only solution that I know of is to have a pull-like workflow, but > I thought this was rejected as too complicated ? My approach is normally to: - Never merge the master branch into my development branches - Create a branch with a clean patch history before merging back into master - Then: merge into master, getting a fast-forward merge if possible - Push back to github When I have large changes that consist of several commits on a single topic, I normally explicitly ask for a non-fast-forward merge, so that the history is not contaminated by a whole slew of commit messages. Regards St?fan From cournape at gmail.com Tue Oct 12 04:05:05 2010 From: cournape at gmail.com (David Cournapeau) Date: Tue, 12 Oct 2010 17:05:05 +0900 Subject: [Numpy-discussion] Commit rights on github In-Reply-To: References: <376ED4C4-3E7C-4E34-977C-FA2AAB71B6ED@gmail.com> <6876EA03-20D6-4880-B795-FEE460C4DF71@gmail.com> <4CB3BA5D.4080505@silveregg.co.jp> <4CB3E61D.2000900@silveregg.co.jp> Message-ID: On Tue, Oct 12, 2010 at 4:57 PM, Matthew Brett wrote: > Hi, > >>> Now might be a good time to discuss how we'd like the history to look >>> in a year from now. ?If we follow the above approach, I guess we may >>> end up with one merge message for each small little bug-fix? (Unless >>> --rebase is used) ?How do we ensure that "fast-forward" merges occur >>> whenever possible? >> >> The only solution that I know of is to have a pull-like workflow, but >> I thought this was rejected as too complicated ? > > Am I the only person to find it strange that we have an active and > skilled development community, many of whom have been using git > routinely for a long time, and we none of us seem to know what the > agreed workflow is I think nobody knows because no such thing exists (that is there is no agreed workflow). FWIW, I think Stefan's suggestion is good, cheers, David From fperez.net at gmail.com Tue Oct 12 04:06:41 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 12 Oct 2010 01:06:41 -0700 Subject: [Numpy-discussion] Commit rights on github In-Reply-To: References: <376ED4C4-3E7C-4E34-977C-FA2AAB71B6ED@gmail.com> <6876EA03-20D6-4880-B795-FEE460C4DF71@gmail.com> <4CB3BA5D.4080505@silveregg.co.jp> <4CB3E61D.2000900@silveregg.co.jp> Message-ID: 2010/10/12 St?fan van der Walt : > - Then: merge into master, getting a fast-forward merge if possible > - Push back to github > > When I have large changes that consist of several commits on a single > topic, I normally explicitly ask for a non-fast-forward merge, so that > the history is not contaminated by a whole slew of commit messages. > My rule of thumb is: one or two commits, fast-forward is OK, three or more, I merge explicitly with --no-ff to make it easier to see them together with their own little branch. In case anyone is interested, we're having precisely this discussion on ipython-dev (where we've been using DVCS for over 2 years and have had ample opportunity to make every mistake under the sun, but now we're quite happy with our workflow and just fine-tuning it): http://mail.scipy.org/pipermail/ipython-dev/2010-October/006746.html Cheers, f From pav at iki.fi Tue Oct 12 04:10:42 2010 From: pav at iki.fi (Pauli Virtanen) Date: Tue, 12 Oct 2010 08:10:42 +0000 (UTC) Subject: [Numpy-discussion] Commit rights on github References: <376ED4C4-3E7C-4E34-977C-FA2AAB71B6ED@gmail.com> <6876EA03-20D6-4880-B795-FEE460C4DF71@gmail.com> <4CB3BA5D.4080505@silveregg.co.jp> Message-ID: Mon, 11 Oct 2010 20:12:47 -0600, Charles R Harris wrote: > I can't quite figure out what commit > a14dd542532d383610c1 > did or where it applied. Any hints? The github output here is confusing, as it chooses to diff the result of a merge against the "wrong" parent (but of course there is no way to know which is the right one). The problems with the commit, as far as I see: - adds unrelated Eclipse .project and .pydev* files - introduces a merge commit for a small change -- Pauli Virtanen From cimrman3 at ntc.zcu.cz Tue Oct 12 04:35:59 2010 From: cimrman3 at ntc.zcu.cz (Robert Cimrman) Date: Tue, 12 Oct 2010 10:35:59 +0200 (CEST) Subject: [Numpy-discussion] Commit rights on github In-Reply-To: References: <376ED4C4-3E7C-4E34-977C-FA2AAB71B6ED@gmail.com> <6876EA03-20D6-4880-B795-FEE460C4DF71@gmail.com> <4CB3BA5D.4080505@silveregg.co.jp> <4CB3E61D.2000900@silveregg.co.jp> Message-ID: Hi Fernando, On Tue, 12 Oct 2010, Fernando Perez wrote: > 2010/10/12 St?fan van der Walt : >> - Then: merge into master, getting a fast-forward merge if possible >> - Push back to github >> >> When I have large changes that consist of several commits on a single >> topic, I normally explicitly ask for a non-fast-forward merge, so that >> the history is not contaminated by a whole slew of commit messages. >> > > My rule of thumb is: one or two commits, fast-forward is OK, three or > more, I merge explicitly with --no-ff to make it easier to see them > together with their own little branch. > > In case anyone is interested, we're having precisely this discussion > on ipython-dev (where we've been using DVCS for over 2 years and have > had ample opportunity to make every mistake under the sun, but now > we're quite happy with our workflow and just fine-tuning it): > > http://mail.scipy.org/pipermail/ipython-dev/2010-October/006746.html Very interesting reading! I have always used tags to mark branches that were fast-forward-merged to master, but --no-ff makes it easier to see the actual branch. Looking forward to the discussion being included in your dev docs, r. From pav at iki.fi Tue Oct 12 04:46:12 2010 From: pav at iki.fi (Pauli Virtanen) Date: Tue, 12 Oct 2010 08:46:12 +0000 (UTC) Subject: [Numpy-discussion] Development workflow References: Message-ID: Mon, 11 Oct 2010 16:47:23 -0700, Matthew Brett wrote: > Am I right in thinking that for the moment at least, the git workflow is > basically the same as the svn workflow (everyone commiting to trunk)? I think there are two issues here: (A) How to be sensible and presentable (B) How and when your stuff gets into master *** For (A) I'm following the same workflow I had with the git mirror: 1. For *every* change, create a separate topic branch. 2. Work on it until the feature/bugfix is ready. 3. Push it to my own github clone for review/backup purposes if necessary. 4. If necessary, rebase (not merge!) on master when developing to keep in stride. 5. When ready, (i) rebase on master, (ii) check that the result is sensible, and (iii) push from the topic branch as new master. In this case, since all recent changes are just unrelated stand-alone bugfixes, this produces something that looks very much like SVN log :) I think of the above, 1-4 are okay in all cases. 5 is then perhaps not so absolute, as one could also do a merge if there are several commits. I 100% endorse Fernando's recommendations: http://mail.scipy.org/pipermail/ipython-dev/2010-October/006746.html This really sounds like best-practice to me, and it's even empirically tested! *** Then there's the second question (B) on when core devs should push changes. When ready, when reviewed, or only before release? I would be open even for the "radical" never-push-your-own-changes solution. I think we could even try it this way for the 1.5.1 release. If it seems that unhandled pull requests start to accumulate (which I don't think will happen), we could just reverse the policy. *** > I realize that this is not going to cheer anyone up, but is this the > best workflow now? Who would decide? I think it is best to discuss this now, and make sure all core devs have similar ideas on what is ideal. One change at a time (i.e. "give 'em the little finger" approach). -- Pauli Virtanen From pgmdevlist at gmail.com Tue Oct 12 05:06:40 2010 From: pgmdevlist at gmail.com (Pierre GM) Date: Tue, 12 Oct 2010 11:06:40 +0200 Subject: [Numpy-discussion] Development workflow In-Reply-To: References: Message-ID: All, All my sincere apologies for the mess I caused... The changes I wanted to commit were quite minimal (just a few lines in a test), but I obviously included some stuffs I didn't want too... Anyhow, I just reverted the commit, as David told me to, and see what I need to do from there without wreaking havoc a second time. Thanks a lot for the links, and for your patience while I'm getting used to git (the only times I used it so far were for some solo projects...). Sorry again P. From matthew.brett at gmail.com Tue Oct 12 05:22:30 2010 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 12 Oct 2010 02:22:30 -0700 Subject: [Numpy-discussion] Development workflow In-Reply-To: References: Message-ID: Hi, > I think there are two issues here: > > (A) How to be sensible and presentable > > (B) How and when your stuff gets into master A very useful distinction - thanks for making it. > For (A) I'm following the same workflow I had with the git mirror: > > 1. For *every* change, create a separate topic branch. > > 2. Work on it until the feature/bugfix is ready. > > 3. Push it to my own github clone for review/backup purposes if necessary. > > 4. If necessary, rebase (not merge!) on master when developing > ? to keep in stride. > > 5. When ready, (i) rebase on master, (ii) check that the result is > ? sensible, and (iii) push from the topic branch as new master. > > In this case, since all recent changes are just unrelated stand-alone > bugfixes, this produces something that looks very much like SVN log :) > > I think of the above, 1-4 are okay in all cases. 5 is then perhaps not so > absolute, as one could also do a merge if there are several commits. I > 100% endorse Fernando's recommendations: > > ? ?http://mail.scipy.org/pipermail/ipython-dev/2010-October/006746.html > > This really sounds like best-practice to me, and it's even empirically > tested! OK - so it seems to me that you agree with Fernando's recommendations, and that's basically the same as what Stefan was proposing (give or take a rebase), and David agreed with Stefan. So - really - everyone agrees on the following - work on topic branches - don't merge from trunk - rebase on trunk if necessary. I think _insisting_ on rebase on trunk before merge with trunk is a little extreme (see follow-up to ipython thread) - but it's not a big deal. > Then there's the second question (B) on when core devs should push > changes. When ready, when reviewed, or only before release? > > I would be open even for the "radical" never-push-your-own-changes > solution. > > I think we could even try it this way for the 1.5.1 release. If it seems > that unhandled pull requests start to accumulate (which I don't think > will happen), we could just reverse the policy. OK - right - that's the second big issue and obviously that's at the heart of thing. I think that splits into two in fact: i) How often to merge into trunk ii) Who should merge into trunk At the extreme, you have the SVN model where the answers are: i) a merge for almost every commit ii) by the person who wrote the code and I thought that we'd decided that we didn't want that because trunk started getting unpredictable and painful to maintain. At the other end is the more standard DVCS-type workflow: i) merges by branches (which might have only a few commits) ii) by small team of people who are responsible for overseeing trunk. And rarely by the person who wrote the code So - is that a reasonable summary? Does anyone disagree with Pauli's never-push-your-own-changes suggestion? Best, Matthew From david at silveregg.co.jp Tue Oct 12 05:31:17 2010 From: david at silveregg.co.jp (David) Date: Tue, 12 Oct 2010 18:31:17 +0900 Subject: [Numpy-discussion] Development workflow In-Reply-To: References: Message-ID: <4CB42AE5.9050709@silveregg.co.jp> On 10/12/2010 06:22 PM, Matthew Brett wrote: > Hi, > >> I think there are two issues here: >> >> (A) How to be sensible and presentable >> >> (B) How and when your stuff gets into master > > A very useful distinction - thanks for making it. > >> For (A) I'm following the same workflow I had with the git mirror: >> >> 1. For *every* change, create a separate topic branch. >> >> 2. Work on it until the feature/bugfix is ready. >> >> 3. Push it to my own github clone for review/backup purposes if necessary. >> >> 4. If necessary, rebase (not merge!) on master when developing >> to keep in stride. >> >> 5. When ready, (i) rebase on master, (ii) check that the result is >> sensible, and (iii) push from the topic branch as new master. >> >> In this case, since all recent changes are just unrelated stand-alone >> bugfixes, this produces something that looks very much like SVN log :) >> >> I think of the above, 1-4 are okay in all cases. 5 is then perhaps not so >> absolute, as one could also do a merge if there are several commits. I >> 100% endorse Fernando's recommendations: >> >> http://mail.scipy.org/pipermail/ipython-dev/2010-October/006746.html >> >> This really sounds like best-practice to me, and it's even empirically >> tested! > > OK - so it seems to me that you agree with Fernando's recommendations, > and that's basically the same as what Stefan was proposing (give or > take a rebase), and David agreed with Stefan. So - really - everyone > agrees on the following - work on topic branches - don't merge from > trunk - rebase on trunk if necessary. I think _insisting_ on rebase > on trunk before merge with trunk is a little extreme (see follow-up to > ipython thread) - but it's not a big deal. > >> Then there's the second question (B) on when core devs should push >> changes. When ready, when reviewed, or only before release? >> >> I would be open even for the "radical" never-push-your-own-changes >> solution. >> >> I think we could even try it this way for the 1.5.1 release. If it seems >> that unhandled pull requests start to accumulate (which I don't think >> will happen), we could just reverse the policy. > > OK - right - that's the second big issue and obviously that's at the > heart of thing. I think that splits into two in fact: > > i) How often to merge into trunk > ii) Who should merge into trunk > > At the extreme, you have the SVN model where the answers are: > > i) a merge for almost every commit > ii) by the person who wrote the code > > and I thought that we'd decided that we didn't want that because trunk > started getting unpredictable and painful to maintain. > > At the other end is the more standard DVCS-type workflow: > > i) merges by branches (which might have only a few commits) > ii) by small team of people who are responsible for overseeing trunk. > And rarely by the person who wrote the code > > So - is that a reasonable summary? > > Does anyone disagree with Pauli's never-push-your-own-changes suggestion? I think it is a little too extreme for trivial changes like one-liner and the likes, but I think it is a good default rule (that is if you are not sure, don't push your own changes). cheers, David From matthew.brett at gmail.com Tue Oct 12 05:32:15 2010 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 12 Oct 2010 02:32:15 -0700 Subject: [Numpy-discussion] Development workflow In-Reply-To: References: Message-ID: Hi, > All my sincere apologies for the mess I caused... The changes I wanted to commit were quite minimal (just a few lines in a test), but I obviously included some stuffs I didn't want too... Ah - no - so sorry that the discussion got attached to your original post and problem. I would like you to know that I think git is wonderful - and that I have made mistakes with git which are far far worse than the minor glitch you hit. What does not kill us makes us stronger, as they say. I think the only possible lesson that might be drawn is that it probably would have helped you as it has certainly helped me, to have someone scan the set of changes and comment - as part of the workflow. Then we all learn from each other, and build up a common understanding of the code and how it's changing. See you, Matthew From matthew.brett at gmail.com Tue Oct 12 05:40:25 2010 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 12 Oct 2010 02:40:25 -0700 Subject: [Numpy-discussion] Development workflow In-Reply-To: <4CB42AE5.9050709@silveregg.co.jp> References: <4CB42AE5.9050709@silveregg.co.jp> Message-ID: Hi, >> Does anyone disagree with Pauli's never-push-your-own-changes suggestion? > > I think it is a little too extreme for trivial changes like one-liner > and the likes, but I think it is a good default rule (that is if you are > not sure, don't push your own changes). Well - but a) if it's a one-liner - I bet you can get someone to sign it off within an hour. b) I've done one-liners that caused a mess. Maybe it's just me ;) c) The only thing you lose from waiting for a sign-off is a few hours - the code is still there if someone needs to use it. That was the problem with SVN - if it wasn't in trunk, it was rotting - but we don't have the problem now. See you, Matthew From pgmdevlist at gmail.com Tue Oct 12 05:48:07 2010 From: pgmdevlist at gmail.com (Pierre GM) Date: Tue, 12 Oct 2010 11:48:07 +0200 Subject: [Numpy-discussion] Development workflow In-Reply-To: References: Message-ID: <84863309-91A4-49C2-81C2-69E1AA581416@gmail.com> On Oct 12, 2010, at 11:32 AM, Matthew Brett wrote: > > I think the only possible lesson that might be drawn is that it > probably would have helped you as it has certainly helped me, to have > someone scan the set of changes and comment - as part of the workflow. That, and a nice set of instructions... Till I'm at it, would there be anybody patient to hold my hand and tell me how to backport changes from one branch to another ? There are just some minor changes in the current master/numpy/ma/core.py that could go to maintenance/1.5.x/numpy/ma/core.py. Corollary: how do I branch from a branch ? Thanks again for your patience. P. From david at silveregg.co.jp Tue Oct 12 05:58:07 2010 From: david at silveregg.co.jp (David) Date: Tue, 12 Oct 2010 18:58:07 +0900 Subject: [Numpy-discussion] Development workflow In-Reply-To: <84863309-91A4-49C2-81C2-69E1AA581416@gmail.com> References: <84863309-91A4-49C2-81C2-69E1AA581416@gmail.com> Message-ID: <4CB4312F.6000508@silveregg.co.jp> On 10/12/2010 06:48 PM, Pierre GM wrote: > > On Oct 12, 2010, at 11:32 AM, Matthew Brett wrote: >> >> I think the only possible lesson that might be drawn is that it >> probably would have helped you as it has certainly helped me, to have >> someone scan the set of changes and comment - as part of the workflow. > > That, and a nice set of instructions... > > Till I'm at it, would there be anybody patient to hold my hand and tell me how to backport changes from one branch to another ? This is easy: 1. go into the target branch 2. git cherry-pick commit_to_backport The -x option to cherry-pick may be used to mention the original commit message in the backported one. By default, cherry-pick commits for you (you can use -n to avoid auto-committing). > Corollary: how do I branch from a branch ? You use the branch command: git branch target_branch source_branch But generally, if you want to create a new branch to start working on it, you use the -b option of checkout: git branch -b target_branch source_branch which is equivalent to git branch target_branch source_branch git checkout target_branch cheers, David From scott.sinclair.za at gmail.com Tue Oct 12 06:09:27 2010 From: scott.sinclair.za at gmail.com (Scott Sinclair) Date: Tue, 12 Oct 2010 12:09:27 +0200 Subject: [Numpy-discussion] Development workflow In-Reply-To: <4CB4312F.6000508@silveregg.co.jp> References: <84863309-91A4-49C2-81C2-69E1AA581416@gmail.com> <4CB4312F.6000508@silveregg.co.jp> Message-ID: On 12 October 2010 11:58, David wrote: > On 10/12/2010 06:48 PM, Pierre GM wrote: >> >> Corollary: how do I branch from a branch ? > > You use the branch command: > > git branch target_branch source_branch > > But generally, if you want to create a new branch to start working on > it, you use the -b option of checkout: > > git branch -b target_branch source_branch Minor typo alert (to avoid confusing people). The above command should be: git checkout -b new_branch source_branch > > which is equivalent to > > git branch target_branch source_branch > git checkout target_branch Cheers, Scott From pav at iki.fi Tue Oct 12 06:22:15 2010 From: pav at iki.fi (Pauli Virtanen) Date: Tue, 12 Oct 2010 10:22:15 +0000 (UTC) Subject: [Numpy-discussion] Development workflow References: <84863309-91A4-49C2-81C2-69E1AA581416@gmail.com> Message-ID: Tue, 12 Oct 2010 11:48:07 +0200, Pierre GM wrote: [clip] > Till I'm at it, would there be anybody patient to hold my hand and tell > me how to backport changes from one branch to another? I do it like this: # create a local branch for integrating backports # needs to be done only once -- just reuse it afterwards git branch upstream/maintenance/1.5.x maintenance/1.5.x After that, things go like this # switch to the local backport integration branch git checkout maintenance/1.5.x # ensure it's up-to-date vs upstream git pull --rebase # figure out what patches to get git log upstream/master # shameless plug: github.com/pv/git-cherry-tree git cherry-tree upstream/master # cherry pick patches git cherry-pick -x ad390f0fa ... # test, just to be sure ... # push the local branch upstream git push upstream maintenance/1.5.x > There are just > some minor changes in the current master/numpy/ma/core.py that could go > to maintenance/1.5.x/numpy/ma/core.py. Corollary: how do I branch from a > branch? git branch old_branch new_branch -- Pauli Virtanen From friedrichromstedt at gmail.com Tue Oct 12 07:40:28 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Tue, 12 Oct 2010 13:40:28 +0200 Subject: [Numpy-discussion] equality of empty arrays In-Reply-To: References: Message-ID: 2010/10/12 Ian Goodfellow : > If the arrays are the same size or can be broadcasted to the same > size, it returns true or false on an elementwise basis. > If the arrays are not the same size and can't be broadcasted to the > same size, it returns False, which was a surprise to me too. > > ?>>> import numpy as N > ?>>> N.asarray([[0,1],[2,3]]) == N.asarray([[1,1],[3,3]]) > array([[False, ?True], > ? ? ? ?[False, ?True]], dtype=bool) > ?>>> N.asarray([[0,1],[2,3]]) == N.asarray([[1,1]]) > array([[False, ?True], > ? ? ? ?[False, False]], dtype=bool) > ?>>> N.asarray([[0,1],[2,3]]) == N.asarray([[1,1],[3,3],[5,5]]) > False This behaviour should maybe be explained in the docs, maybe here: http://docs.scipy.org/doc/numpy/reference/arrays.ndarray.html#arithmetic-and-comparison-operations . It relies on the following: Python first asks the objects using their operator overloads, if existent. If the first one returns NotImplemented or does not exist, Python falls back to the second operand. If this does not work either, Python compares objects equal if they are the *same* object, I believe based on id() (maybe this has just the same effect). Since numpy cannot compare in the numpy-sense if arrays are not broadcastable to the same shape, both __eq__() methods of both operands will return NotImplemented, like in the last case in the cited section above, where "id() comparison" takes place, yielding False. Btw, this issue occurs on some Poisson basis with non-negligible q :-) on the list ... I could start improving the docs in this respect using the responses of others and me from the list, but I have no idea how they would make in into the official docs? Friedrich From ndbecker2 at gmail.com Tue Oct 12 07:54:11 2010 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 12 Oct 2010 07:54:11 -0400 Subject: [Numpy-discussion] intel array building blocks Message-ID: I just came across this: http://software.intel.com/en-us/articles/intel-array-building-blocks- documentation/ Has anyone used this? Of any interest for numpy? From jsseabold at gmail.com Tue Oct 12 09:15:11 2010 From: jsseabold at gmail.com (Skipper Seabold) Date: Tue, 12 Oct 2010 09:15:11 -0400 Subject: [Numpy-discussion] equality of empty arrays In-Reply-To: References: Message-ID: On Tue, Oct 12, 2010 at 7:40 AM, Friedrich Romstedt wrote: > 2010/10/12 Ian Goodfellow : >> If the arrays are the same size or can be broadcasted to the same >> size, it returns true or false on an elementwise basis. >> If the arrays are not the same size and can't be broadcasted to the >> same size, it returns False, which was a surprise to me too. >> >> ?>>> import numpy as N >> ?>>> N.asarray([[0,1],[2,3]]) == N.asarray([[1,1],[3,3]]) >> array([[False, ?True], >> ? ? ? ?[False, ?True]], dtype=bool) >> ?>>> N.asarray([[0,1],[2,3]]) == N.asarray([[1,1]]) >> array([[False, ?True], >> ? ? ? ?[False, False]], dtype=bool) >> ?>>> N.asarray([[0,1],[2,3]]) == N.asarray([[1,1],[3,3],[5,5]]) >> False > > This behaviour should maybe be explained in the docs, maybe here: > http://docs.scipy.org/doc/numpy/reference/arrays.ndarray.html#arithmetic-and-comparison-operations > . > > It relies on the following: > > Python first asks the objects using their operator overloads, if > existent. ?If the first one returns NotImplemented or does not exist, > Python falls back to the second operand. ?If this does not work > either, Python compares objects equal if they are the *same* object, I > believe based on id() (maybe this has just the same effect). > > Since numpy cannot compare in the numpy-sense if arrays are not > broadcastable to the same shape, both __eq__() methods of both > operands will return NotImplemented, like in the last case in the > cited section above, where "id() comparison" takes place, yielding > False. > > Btw, this issue occurs on some Poisson basis with non-negligible q :-) > on the list ... I could start improving the docs in this respect using > the responses of others and me from the list, but I have no idea how > they would make in into the official docs? > Some elaboration here? http://www.scipy.org/FAQ#head-9448031cbb9760d0a44db0eceda47393e56e8270 Skipper From vincent at vincentdavis.net Tue Oct 12 09:51:34 2010 From: vincent at vincentdavis.net (Vincent Davis) Date: Tue, 12 Oct 2010 07:51:34 -0600 Subject: [Numpy-discussion] Development workflow In-Reply-To: References: <84863309-91A4-49C2-81C2-69E1AA581416@gmail.com> Message-ID: Lots of good reading :) Just thought I'd put a plug in for the contributor that may make only a few contributions and needs a simple workflow to do so. It would be great if they could just.. make there own fork clone the branch of interest make changes push to there own fork request pull. I think part of the point of moving to git was to make these types of contributions easier. Ideally there would be instructions here http://www.numpy.org/ Vincent On Tue, Oct 12, 2010 at 4:22 AM, Pauli Virtanen wrote: > Tue, 12 Oct 2010 11:48:07 +0200, Pierre GM wrote: > [clip] >> Till I'm at it, would there be anybody patient to hold my hand and tell >> me how to backport changes from one branch to another? > > I do it like this: > > ? ? ? ?# create a local branch for integrating backports > ? ? ? ?# needs to be done only once -- just reuse it afterwards > ? ? ? ?git branch upstream/maintenance/1.5.x maintenance/1.5.x > > After that, things go like this > > ? ? ? ?# switch to the local backport integration branch > ? ? ? ?git checkout maintenance/1.5.x > > ? ? ? ?# ensure it's up-to-date vs upstream > ? ? ? ?git pull --rebase > > ? ? ? ?# figure out what patches to get > ? ? ? ?git log upstream/master > > ? ? ? ?# shameless plug: github.com/pv/git-cherry-tree > ? ? ? ?git cherry-tree upstream/master > > ? ? ? ?# cherry pick patches > ? ? ? ?git cherry-pick -x ad390f0fa > ? ? ? ?... > > ? ? ? ?# test, just to be sure > ? ? ? ?... > > ? ? ? ?# push the local branch upstream > ? ? ? ?git push upstream maintenance/1.5.x > >> There are just >> some minor changes in the current master/numpy/ma/core.py that could go >> to maintenance/1.5.x/numpy/ma/core.py. Corollary: how do I branch from a >> branch? > > ? ? ? ?git branch old_branch new_branch > > -- > Pauli Virtanen > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -- Thanks Vincent Davis 720-301-3003 From cournape at gmail.com Tue Oct 12 11:10:30 2010 From: cournape at gmail.com (David Cournapeau) Date: Wed, 13 Oct 2010 00:10:30 +0900 Subject: [Numpy-discussion] Development workflow In-Reply-To: References: Message-ID: On Tue, Oct 12, 2010 at 6:06 PM, Pierre GM wrote: > All, > All my sincere apologies for the mess I caused... The changes I wanted to commit were quite minimal (just a few lines in a test), but I obviously included some stuffs I didn't want too... No worries. Unless someone beats me to it, I will revert your changes tomorrow morning (in 6-7 hours), so that you can reapply them as you intended. cheers, David From ralf.gommers at googlemail.com Tue Oct 12 11:15:04 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Tue, 12 Oct 2010 23:15:04 +0800 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: References: Message-ID: On Mon, Oct 11, 2010 at 11:14 PM, Vincent Davis wrote: > On Mon, Oct 11, 2010 at 7:34 AM, Ralf Gommers > wrote: > > Hi Friedrich, > > > > On Mon, Oct 11, 2010 at 2:46 AM, Friedrich Romstedt > > wrote: > >> > >> 2010/10/9 Vincent Davis : > >> > Did you get any responses on this? I can install 10.5 and help out > >> > with some testing. I have a macbookpro that does not turn of (Hardware > >> > issue) but it is good for testing. I could setup remote access on this > >> > if of interest to you. > >> > >> I can also help with the installer > > > > That would be very helpful, thanks. Please keep me up to date on your > > progress with the 10.5 license, and once you are set up we can coordinate > > building the binaries. > > > >> > >> - I have some (some) experience > >> with building Mac OS X installers using the PackageMaker provided by > >> Apple. Just lacking a 10.5. But since I need some anyway (for > >> controlling a 10.5 server), Vincent, if you don't need your 10.5 > >> anymore, can we transfer the license in some way from you to me? I'm > >> serious, one cannot buy 10.5 from Apple anymore, and I need a legal > >> license. I have 10.6 and a VMware Fusion v3. > >> > >> When anyone can inform me how the installation scheme for numpy > >> binaries is I can then provide the installers, I believe. > > > > The toolchain you need is documented at > > http://projects.scipy.org/numpy/wiki/MakingReleases. If you have all the > > dependencies it's simply a matter of > > $ paver dmg -p 2.5 (or 2.6/7) > > and a dmg installer is built. > > Is there any reason 10.5 server addition would not work for building > release ? > Friedrich, you can't just install 10.5 (non server) on vmware. I just > tried, It responds This is not a server addition. There are hacks > but... > > I'll try to do a few testes this week., Where does > "numpy-macosx-installer " > http://github.com/cournape/numpy-macosx-installer fit in to running > this command. "paver dmg -p 2.5" or does it? This now lives under tools/numpy-macosx-installer in the git repo, so that is not an external dependency anymore. > I have installed from > source many times but never built a dmg. > Is there any interest in a current Dev snapshot dmg? > Probably not. The master branch is not binary compatible with scipy. But 1.5.1rc1 is planned for this coming Sunday, so that would be useful to have a 10.5 binary of. And how about a numpy scipy combo dmg? > Not sure if that's a very good way to spend your time, what's wrong with separate installers? The release cycles are not synchronized, so this would just be extra work. > > A little bit of a separate issue, does the build bot or so,ething/one > other than developers run numpy.test() to monitor test that may fail > on different systems, as numpy scipy, python get updated. It does, just go to Waterfall display, then click one of the "stdio" links to see test results. Cheers, Ralf > It seems > like a bot could build everything from source weekly and commit a test > log via git/github to monitor and record the condition and changes in > tests. Maybe there is no point to this, just sound like a neat way to > track test results. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pgmdevlist at gmail.com Tue Oct 12 11:22:27 2010 From: pgmdevlist at gmail.com (Pierre GM) Date: Tue, 12 Oct 2010 17:22:27 +0200 Subject: [Numpy-discussion] Development workflow In-Reply-To: References: Message-ID: On Oct 12, 2010, at 5:10 PM, David Cournapeau wrote: > On Tue, Oct 12, 2010 at 6:06 PM, Pierre GM wrote: >> All, >> All my sincere apologies for the mess I caused... The changes I wanted to commit were quite minimal (just a few lines in a test), but I obviously included some stuffs I didn't want too... > > No worries. Unless someone beats me to it, I will revert your changes > tomorrow morning (in 6-7 hours), so that you can reapply them as you > intended. I gonna try again in a couple of hours. Looks like I need to specifically exclude the files created by a `python setup.py develop`. Would it be worth to add those files in the numpy/.gitignore ? I just put some in my .git/info/exclude. From cournape at gmail.com Tue Oct 12 11:28:21 2010 From: cournape at gmail.com (David Cournapeau) Date: Wed, 13 Oct 2010 00:28:21 +0900 Subject: [Numpy-discussion] Development workflow In-Reply-To: References: Message-ID: On Wed, Oct 13, 2010 at 12:22 AM, Pierre GM wrote: > > On Oct 12, 2010, at 5:10 PM, David Cournapeau wrote: > >> On Tue, Oct 12, 2010 at 6:06 PM, Pierre GM wrote: >>> All, >>> All my sincere apologies for the mess I caused... The changes I wanted to commit were quite minimal (just a few lines in a test), but I obviously included some stuffs I didn't want too... >> >> No worries. Unless someone beats me to it, I will revert your changes >> tomorrow morning (in 6-7 hours), so that you can reapply them as you >> intended. > > I gonna try again in a couple of hours. Looks like I need to specifically exclude the files created by a `python setup.py develop`. Not sure I understand the link between git and python setup.py develop. What git command did you use to commit those two commits ? David From pgmdevlist at gmail.com Tue Oct 12 11:31:37 2010 From: pgmdevlist at gmail.com (Pierre GM) Date: Tue, 12 Oct 2010 17:31:37 +0200 Subject: [Numpy-discussion] Development workflow In-Reply-To: References: Message-ID: <1C65886F-8E53-4198-8181-2A85B0CC9492@gmail.com> On Oct 12, 2010, at 5:28 PM, David Cournapeau wrote: >> >> I gonna try again in a couple of hours. Looks like I need to specifically exclude the files created by a `python setup.py develop`. > > Not sure I understand the link between git and python setup.py > develop. What git command did you use to commit those two commits ? git push The files created by setup.py develop are marked as not added but pollute some of the reports (diff, eg). From charlesr.harris at gmail.com Tue Oct 12 11:33:05 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Tue, 12 Oct 2010 09:33:05 -0600 Subject: [Numpy-discussion] Development workflow In-Reply-To: References: Message-ID: On Tue, Oct 12, 2010 at 9:22 AM, Pierre GM wrote: > > On Oct 12, 2010, at 5:10 PM, David Cournapeau wrote: > > > On Tue, Oct 12, 2010 at 6:06 PM, Pierre GM wrote: > >> All, > >> All my sincere apologies for the mess I caused... The changes I wanted > to commit were quite minimal (just a few lines in a test), but I obviously > included some stuffs I didn't want too... > > > > No worries. Unless someone beats me to it, I will revert your changes > > tomorrow morning (in 6-7 hours), so that you can reapply them as you > > intended. > > I gonna try again in a couple of hours. Looks like I need to specifically > exclude the files created by a `python setup.py develop`. Would it be worth > to add those files in the numpy/.gitignore ? I just put some in my > .git/info/exclude. > What is curious is how the project files got added in the first place ;) But Jarrod committed an improved .gitignore file that should help. I always run git status before committing anything unless I am going to specify the files to commit. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From cournape at gmail.com Tue Oct 12 11:38:25 2010 From: cournape at gmail.com (David Cournapeau) Date: Wed, 13 Oct 2010 00:38:25 +0900 Subject: [Numpy-discussion] Development workflow In-Reply-To: <1C65886F-8E53-4198-8181-2A85B0CC9492@gmail.com> References: <1C65886F-8E53-4198-8181-2A85B0CC9492@gmail.com> Message-ID: On Wed, Oct 13, 2010 at 12:31 AM, Pierre GM wrote: > > On Oct 12, 2010, at 5:28 PM, David Cournapeau wrote: >>> >>> I gonna try again in a couple of hours. Looks like I need to specifically exclude the files created by a `python setup.py develop`. >> >> Not sure I understand the link between git and python setup.py >> develop. What git command did you use to commit those two commits ? > > git push > The files created by setup.py develop are marked as not added but pollute some of the reports (diff, eg). I am still not following - generated files should certainly not appear in diff, unless you explicitly add them. Or does eclipse somehow automatically add files to the git repository ? That sounds a bit strange, cheers, David From pgmdevlist at gmail.com Tue Oct 12 11:40:48 2010 From: pgmdevlist at gmail.com (Pierre GM) Date: Tue, 12 Oct 2010 17:40:48 +0200 Subject: [Numpy-discussion] Development workflow In-Reply-To: References: <1C65886F-8E53-4198-8181-2A85B0CC9492@gmail.com> Message-ID: On Oct 12, 2010, at 5:38 PM, David Cournapeau wrote: > On Wed, Oct 13, 2010 at 12:31 AM, Pierre GM wrote: >> >> git push >> The files created by setup.py develop are marked as not added but pollute some of the reports (diff, eg). > > I am still not following - generated files should certainly not appear > in diff, unless you explicitly add them. My bad, git status From cournape at gmail.com Tue Oct 12 11:48:10 2010 From: cournape at gmail.com (David Cournapeau) Date: Wed, 13 Oct 2010 00:48:10 +0900 Subject: [Numpy-discussion] Development workflow In-Reply-To: References: <1C65886F-8E53-4198-8181-2A85B0CC9492@gmail.com> Message-ID: On Wed, Oct 13, 2010 at 12:40 AM, Pierre GM wrote: > > On Oct 12, 2010, at 5:38 PM, David Cournapeau wrote: > >> On Wed, Oct 13, 2010 at 12:31 AM, Pierre GM wrote: >>> >>> git push >>> The files created by setup.py develop are marked as not added but pollute some of the reports (diff, eg). >> >> I am still not following - generated files should certainly not appear >> in diff, unless you explicitly add them. > > My bad, git status You can use git status -u no (which will not show the status of untracked files). But part of the point of status is to see what files are added and which ones aren't. In that regard, git works exactly the same as any other VCS that I know. cheers, David From friedrichromstedt at gmail.com Tue Oct 12 12:25:58 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Tue, 12 Oct 2010 18:25:58 +0200 Subject: [Numpy-discussion] equality of empty arrays In-Reply-To: References: Message-ID: 2010/10/12 Skipper Seabold : > Some elaboration here? > http://www.scipy.org/FAQ#head-9448031cbb9760d0a44db0eceda47393e56e8270 I don't know if I understand what you want, do you want me or someone else to explain the section "What is the preferred way to test if an array is empy?" in the scipy FAQ in more detail? Friedrich From robert.kern at gmail.com Tue Oct 12 12:32:53 2010 From: robert.kern at gmail.com (Robert Kern) Date: Tue, 12 Oct 2010 11:32:53 -0500 Subject: [Numpy-discussion] equality of empty arrays In-Reply-To: References: Message-ID: On Tue, Oct 12, 2010 at 11:25, Friedrich Romstedt wrote: > 2010/10/12 Skipper Seabold : >> Some elaboration here? >> http://www.scipy.org/FAQ#head-9448031cbb9760d0a44db0eceda47393e56e8270 > > I don't know if I understand what you want, do you want me or someone > else to explain the section "What is the preferred way to test if an > array is empy?" in the scipy FAQ in more detail? I believe he is suggesting that that is a place where you can "start improving the docs in this respect using the responses of others and [you] from the list." As a wiki, it will automatically be "official". -- 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 From jsseabold at gmail.com Tue Oct 12 12:42:11 2010 From: jsseabold at gmail.com (Skipper Seabold) Date: Tue, 12 Oct 2010 12:42:11 -0400 Subject: [Numpy-discussion] equality of empty arrays In-Reply-To: References: Message-ID: On Tue, Oct 12, 2010 at 12:32 PM, Robert Kern wrote: > On Tue, Oct 12, 2010 at 11:25, Friedrich Romstedt > wrote: >> 2010/10/12 Skipper Seabold : >>> Some elaboration here? >>> http://www.scipy.org/FAQ#head-9448031cbb9760d0a44db0eceda47393e56e8270 >> >> I don't know if I understand what you want, do you want me or someone >> else to explain the section "What is the preferred way to test if an >> array is empy?" in the scipy FAQ in more detail? > > I believe he is suggesting that that is a place where you can "start > improving the docs in this respect using the responses of others and > [you] from the list." As a wiki, it will automatically be "official". This is what I was suggesting, though obviously it is just a suggestion. A non-negligible q, as you say, could also be thought of as "frequent". Skipper From vincent at vincentdavis.net Tue Oct 12 12:45:32 2010 From: vincent at vincentdavis.net (Vincent Davis) Date: Tue, 12 Oct 2010 10:45:32 -0600 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: References: Message-ID: On Tue, Oct 12, 2010 at 9:15 AM, Ralf Gommers wrote: > > > On Mon, Oct 11, 2010 at 11:14 PM, Vincent Davis > wrote: >> >> On Mon, Oct 11, 2010 at 7:34 AM, Ralf Gommers >> wrote: >> > Hi Friedrich, >> > >> > On Mon, Oct 11, 2010 at 2:46 AM, Friedrich Romstedt >> > wrote: >> >> >> >> 2010/10/9 Vincent Davis : >> >> > Did you get any responses on this? I can install 10.5 and help out >> >> > with some testing. I have a macbookpro that does not turn of >> >> > (Hardware >> >> > issue) but it is good for testing. I could setup remote access on >> >> > this >> >> > if of interest to you. >> >> >> >> I can also help with the installer >> > >> > That would be very helpful, thanks. Please keep me up to date on your >> > progress with the 10.5 license, and once you are set up we can >> > coordinate >> > building the binaries. >> > >> >> >> >> - I have some (some) experience >> >> with building Mac OS X installers using the PackageMaker provided by >> >> Apple. ?Just lacking a 10.5. ?But since I need some anyway (for >> >> controlling a 10.5 server), Vincent, if you don't need your 10.5 >> >> anymore, can we transfer the license in some way from you to me? ?I'm >> >> serious, one cannot buy 10.5 from Apple anymore, and I need a legal >> >> license. ?I have 10.6 and a VMware Fusion v3. >> >> >> >> When anyone can inform me how the installation scheme for numpy >> >> binaries is I can then provide the installers, I believe. >> > >> > The toolchain you need is documented at >> > http://projects.scipy.org/numpy/wiki/MakingReleases. If you have all the >> > dependencies it's simply a matter of >> > ? $ paver dmg -p 2.5?? (or 2.6/7) >> > and a dmg installer is built. >> >> Is there any reason 10.5 server addition would not work for building >> release ? >> >> Friedrich, you can't just install 10.5 (non server) on vmware. I just >> tried, It responds This is not a server addition. There are hacks >> but... >> >> I'll try to do a few testes this week., Where does >> "numpy-macosx-installer " >> http://github.com/cournape/numpy-macosx-installer fit in to running >> this command. "paver dmg -p 2.5" or does it? > > This now lives under tools/numpy-macosx-installer in the git repo, so that > is not an external dependency anymore. > >> >> I have installed from >> source many times but never built a dmg. >> Is there any interest in a current Dev snapshot dmg? > > Probably not. The master branch is not binary compatible with scipy. But > 1.5.1rc1 is planned for this coming Sunday, so that would be useful to have > a 10.5 binary of. Ok, Friedrich and I are working on setting up a machine for building on 10.5 and hope (I do) to have that going for 1.5.1rc1 I hope to do a 10.6 for 1.5rc1 also. > >> And how about a numpy scipy combo dmg? > > Not sure if that's a very good way to spend your time, what's wrong with > separate installers? The release cycles are not synchronized, so this would > just be extra work. Or a learning experience :-) which is always work. Thanks Vincent >> >> A little bit of a separate issue, does the build bot ?or so,ething/one >> other than developers run numpy.test() to monitor test that may fail >> on different systems, as numpy scipy, python get updated. > > It does, just go to Waterfall display, then click one of the "stdio" links > to see test results. > > Cheers, > Ralf > > >> >> It seems >> like a bot could build everything from source weekly and commit a test >> log via git/github ?to monitor and record the condition and changes in >> tests. Maybe there is no point to this, just sound like a neat way to >> track test results. >> > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > -- Thanks Vincent Davis 720-301-3003 From fperez.net at gmail.com Tue Oct 12 14:55:04 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 12 Oct 2010 11:55:04 -0700 Subject: [Numpy-discussion] Development workflow In-Reply-To: References: <84863309-91A4-49C2-81C2-69E1AA581416@gmail.com> Message-ID: On Tue, Oct 12, 2010 at 6:51 AM, Vincent Davis wrote: > Lots of good reading :) Just thought I'd put a plug in for the > contributor that may make only a few contributions and needs a simple > workflow to do so. It would be great if they could just.. > make there own fork > clone the branch of interest > make changes > push to there own fork > request pull. > > I think part of the point of moving to git was to make these types of > contributions easier. Ideally there would be instructions here > http://www.numpy.org/ > Matthew Brett has prepared a document with much of this in ready-to-digest form: http://github.com/matthew-brett/gitwash It's meant for easy inclusion in other projects (if they agree with the worfklow it presents), here it is for example rendered with the urls pointing to ipython repos: http://ipython.scipy.org/doc/nightly/html/development/gitwash/index.html Cheers, f From friedrichromstedt at gmail.com Tue Oct 12 15:21:31 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Tue, 12 Oct 2010 21:21:31 +0200 Subject: [Numpy-discussion] equality of empty arrays In-Reply-To: References: Message-ID: 2010/10/12 Skipper Seabold : > On Tue, Oct 12, 2010 at 12:32 PM, Robert Kern wrote: >> On Tue, Oct 12, 2010 at 11:25, Friedrich Romstedt >> wrote: >>> 2010/10/12 Skipper Seabold : >>>> Some elaboration here? >>>> http://www.scipy.org/FAQ#head-9448031cbb9760d0a44db0eceda47393e56e8270 >>> >>> I don't know if I understand what you want, do you want me or someone >>> else to explain the section "What is the preferred way to test if an >>> array is empy?" in the scipy FAQ in more detail? >> >> I believe he is suggesting that that is a place where you can "start >> improving the docs in this respect using the responses of others and >> [you] from the list." As a wiki, it will automatically be "official". > > This is what I was suggesting, though obviously it is just a > suggestion. ?A non-negligible q, as you say, could also be thought of > as "frequent". Okay, :-) For today and tomorrow at least, I'm busy with the Mac OS X stuff together with Vincent, but I'll keep it in mind. Friedrich P.S.: Didn't notice that it is a wiki. From vincent at vincentdavis.net Tue Oct 12 15:50:07 2010 From: vincent at vincentdavis.net (Vincent Davis) Date: Tue, 12 Oct 2010 13:50:07 -0600 Subject: [Numpy-discussion] www.numpy.org url issues Message-ID: When visiting links starting at www.numpy.org the URL in the address bar does not change. For example clicking the "getting Numpy" takes you to http://www.scipy.org/Download but the URL in the address bar does not change. So now if I wanted to email that page to someone it would not be obvious what the right URL would be. Also I have noticed that numpy.org mixes new.scipy.org and scipy.org (actual url not what is displayed) different than if you start from scip.org. If you start at scipy.org everything works right. Ok so maybe this only bugs me :) -- Thanks Vincent Davis 720-301-3003 From vincent at vincentdavis.net Tue Oct 12 15:55:27 2010 From: vincent at vincentdavis.net (Vincent Davis) Date: Tue, 12 Oct 2010 13:55:27 -0600 Subject: [Numpy-discussion] Development workflow In-Reply-To: References: <84863309-91A4-49C2-81C2-69E1AA581416@gmail.com> Message-ID: On Tue, Oct 12, 2010 at 12:55 PM, Fernando Perez wrote: > On Tue, Oct 12, 2010 at 6:51 AM, Vincent Davis wrote: >> Lots of good reading :) Just thought I'd put a plug in for the >> contributor that may make only a few contributions and needs a simple >> workflow to do so. It would be great if they could just.. >> make there own fork >> clone the branch of interest >> make changes >> push to there own fork >> request pull. >> >> I think part of the point of moving to git was to make these types of >> contributions easier. Ideally there would be instructions here >> http://www.numpy.org/ >> > > Matthew Brett has prepared a document with much of this in ready-to-digest form: > > http://github.com/matthew-brett/gitwash Thats great. > > It's meant for easy inclusion in other projects (if they agree with > the worfklow it presents), here it is for example rendered with the > urls pointing to ipython repos: Hope something like this gets converted/done for Numpy. Vincent > > http://ipython.scipy.org/doc/nightly/html/development/gitwash/index.html > > Cheers, > > f > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -- Thanks Vincent Davis 720-301-3003 From bsouthey at gmail.com Tue Oct 12 16:24:25 2010 From: bsouthey at gmail.com (Bruce Southey) Date: Tue, 12 Oct 2010 15:24:25 -0500 Subject: [Numpy-discussion] Development workflow In-Reply-To: References: <84863309-91A4-49C2-81C2-69E1AA581416@gmail.com> Message-ID: <4CB4C3F9.8010906@gmail.com> On 10/12/2010 01:55 PM, Fernando Perez wrote: > On Tue, Oct 12, 2010 at 6:51 AM, Vincent Davis wrote: >> Lots of good reading :) Just thought I'd put a plug in for the >> contributor that may make only a few contributions and needs a simple >> workflow to do so. It would be great if they could just.. >> make there own fork >> clone the branch of interest >> make changes >> push to there own fork >> request pull. >> >> I think part of the point of moving to git was to make these types of >> contributions easier. Ideally there would be instructions here >> http://www.numpy.org/ >> > Matthew Brett has prepared a document with much of this in ready-to-digest form: > > http://github.com/matthew-brett/gitwash > > It's meant for easy inclusion in other projects (if they agree with > the worfklow it presents), here it is for example rendered with the > urls pointing to ipython repos: > > http://ipython.scipy.org/doc/nightly/html/development/gitwash/index.html > > Cheers, > > f > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion Thanks. This just appeared on LWN that gives a real appreciation for the work done: Lessons from PostgreSQL's Git transition http://lwn.net/SubscriberLink/409635/11a5197ddb2c46b8/ Bruce -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Tue Oct 12 16:46:24 2010 From: pav at iki.fi (Pauli Virtanen) Date: Tue, 12 Oct 2010 20:46:24 +0000 (UTC) Subject: [Numpy-discussion] Development workflow References: <84863309-91A4-49C2-81C2-69E1AA581416@gmail.com> Message-ID: Tue, 12 Oct 2010 13:55:27 -0600, Vincent Davis wrote: >> It's meant for easy inclusion in other projects (if they agree with the >> worfklow it presents), here it is for example rendered with the urls >> pointing to ipython repos: > > Hope something like this gets converted/done for Numpy. http://docs.scipy.org/doc/numpy/dev/gitwash/index.html From Chris.Barker at noaa.gov Tue Oct 12 16:48:26 2010 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 12 Oct 2010 13:48:26 -0700 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: References: Message-ID: <4CB4C99A.8040906@noaa.gov> Ralf Gommers wrote: > Yes I got one response at http://projects.scipy.org/numpy/ticket/1322, a > negative one unfortunately. For what it's worth, the posted binary seems to work fine on my OS-X 10.5 PPC system (python2.6), so maybe the PPC part works, the Intel part not. > My conclusion is that binaries built on 10.6 > do not work on 10.5 even when using the correct SDK and deployment > target. Well, I still think if you do everything right, it works, but yes, it is a pain to get right, and a pain to test. Building on the oldest system you want to support is a lot easier. > Sage distributes separate binaries for each OS X version, presumably > compiled on those same versions. If we want to have a 10.5 binary we > should just do the same. I don't think so -- that's a lot to maintain, and the older versions work on the newer OS -- so why build the newer? Also a lot (OK -- some, I have no idea how many) of us re-distribute, via py2app, and so need Universal binaries that work on all the systems we need to support. 10.4 or greater would be great -- basically matching the python.org builds. > The binary naming scheme should also change to include the version. yup. Thanks for working in this! -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 Chris.Barker at noaa.gov From Chris.Barker at noaa.gov Tue Oct 12 16:53:53 2010 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 12 Oct 2010 13:53:53 -0700 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: References: Message-ID: <4CB4CAE1.3010306@noaa.gov> Vincent Davis wrote: > Ok, Friedrich and I are working on setting up a machine for building > on 10.5 and hope (I do) to have that going for 1.5.1rc1 > I hope to do a 10.6 for 1.5rc1 also. why have a separate 10.6 build? And have we given up on 10.4? -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 Chris.Barker at noaa.gov From vincent at vincentdavis.net Tue Oct 12 17:00:59 2010 From: vincent at vincentdavis.net (Vincent Davis) Date: Tue, 12 Oct 2010 15:00:59 -0600 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: <4CB4CAE1.3010306@noaa.gov> References: <4CB4CAE1.3010306@noaa.gov> Message-ID: On Tue, Oct 12, 2010 at 2:53 PM, Christopher Barker wrote: > Vincent Davis wrote: >> Ok, Friedrich and I are working on setting up a machine for building >> on 10.5 and hope (I do) ?to have that going for 1.5.1rc1 >> I hope to do a 10.6 for 1.5rc1 also. > > why have a separate 10.6 build? > > And have we given up on 10.4? I could do 10.4 also. For me doing this is maybe best described as a curiosity. But my understanding was that some where having trouble install on 10.5 with binaries made on 10.6. So if I can learn something and help others that is great. Therefore I am interested in any input or advice you have. So what exacty do you think should be done? Thanks Vincent > > -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 > > Chris.Barker at noaa.gov > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -- Thanks Vincent Davis 720-301-3003 From vincent at vincentdavis.net Tue Oct 12 17:11:14 2010 From: vincent at vincentdavis.net (Vincent Davis) Date: Tue, 12 Oct 2010 15:11:14 -0600 Subject: [Numpy-discussion] Development workflow In-Reply-To: References: <84863309-91A4-49C2-81C2-69E1AA581416@gmail.com> Message-ID: On Tue, Oct 12, 2010 at 2:46 PM, Pauli Virtanen wrote: > Tue, 12 Oct 2010 13:55:27 -0600, Vincent Davis wrote: >>> It's meant for easy inclusion in other projects (if they agree with the >>> worfklow it presents), here it is for example rendered with the urls >>> pointing to ipython repos: >> >> Hope something like this gets converted/done for Numpy. > > http://docs.scipy.org/doc/numpy/dev/gitwash/index.html Nice :) Vincent > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -- Thanks Vincent Davis 720-301-3003 From jsseabold at gmail.com Tue Oct 12 17:46:07 2010 From: jsseabold at gmail.com (Skipper Seabold) Date: Tue, 12 Oct 2010 17:46:07 -0400 Subject: [Numpy-discussion] bug in genfromtxt Message-ID: With names=True, if you specify the dtype manually and specify usecols, it doesn't grab the correct names along with the columns. Should be a simple fix, but haven't had time to write a patch yet. from stringIO import stringIO import numpy as np np.__version__ #1.5.0 s = StringIO("col0,col1,col2,col3,col4\n0,1,2,3,4\n0,1,2,3,4\n0,1,2,3,4") arr = np.genfromtxt(s, names=True, usecols=(0,2,4), delimiter=",", dtype=['int','int','int']) arr.dtype.names #('col0', 'col1', 'col2') Interestingly in trying to reproduce, I mistyped the dtype and got the expected names (but no error on my bad dtype). arr = np.genfromtxt(s, names=True, usecols=(0,2,4), delimiter=",", dtype=['int','int','int','int','int']) arr.dtype.names #('col0', 'col2', 'col4') It also works as expected with dtype=None. Ticket here: http://projects.scipy.org/numpy/ticket/1636 Skipper From Chris.Barker at noaa.gov Tue Oct 12 18:38:00 2010 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 12 Oct 2010 15:38:00 -0700 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: References: <4CB4CAE1.3010306@noaa.gov> Message-ID: <4CB4E348.5070702@noaa.gov> On 10/12/10 2:00 PM, Vincent Davis wrote: > I could do 10.4 also. For me doing this is maybe best described as a > curiosity. But my understanding was that some where having trouble > install on 10.5 with binaries made on 10.6. So if I can learn > something and help others that is great. Well, I appreciate the effort. > Therefore I am interested in any input or advice you have. > > So what exacty do you think should be done? Ideally, I think the Mac numpy binaries should match the python.org python binaries: Python 2.5: 32-bit PPC/i386 for Mac OS X 10.3.9 through 10.6 Python 2.6: 32-bit PPC/i386 for Mac OS X 10.3.9 through 10.6 Python 2.7 32-bit PPC/i386 for Mac OS X 10.3.9 through 10.6 Python 2.7 PPC/i386/x86-64 for Mac OS X 10.5 or later Python 3 ??? (similar I think) Supporting 10.3.9 may be a bit much these days, so it's probably easiest to build on a 10.4 machine, except for the 2.7 64bit build on 10.5. In theory, it should all be buildable on 10.6, but I know I've struggled with doing that sort of thing -- but maybe the macpython folks could help. In the past, numpy builds have "just worked", so maybe it's as simple as finding a 10.4 machine to build on (I don't have one anymore, we're not allowed to have them on our network, since Apple stopped supplying security patches) 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 Chris.Barker at noaa.gov From vincent at vincentdavis.net Tue Oct 12 21:12:43 2010 From: vincent at vincentdavis.net (Vincent Davis) Date: Tue, 12 Oct 2010 19:12:43 -0600 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: <4CB4E348.5070702@noaa.gov> References: <4CB4CAE1.3010306@noaa.gov> <4CB4E348.5070702@noaa.gov> Message-ID: On Tue, Oct 12, 2010 at 4:38 PM, Christopher Barker wrote: > On 10/12/10 2:00 PM, Vincent Davis wrote: >> I could do 10.4 also. For me doing this is maybe best described as a >> curiosity. But my understanding was that some where having trouble >> install on 10.5 with binaries made on 10.6. So if I can learn >> something and help others that is great. > > Well, I appreciate the effort. > >> Therefore I am interested in any input or advice you have. >> >> So what exacty do you think should be done? > > Ideally, I think the Mac numpy binaries should match the python.org > python binaries: > > > Python 2.5: 32-bit PPC/i386 for Mac OS X 10.3.9 through 10.6 > > Python 2.6: 32-bit PPC/i386 for Mac OS X 10.3.9 through 10.6 > > Python 2.7 32-bit PPC/i386 for Mac OS X 10.3.9 through 10.6 > > Python 2.7 PPC/i386/x86-64 for Mac OS X 10.5 or later > > Python 3 ??? (similar I think) Sound good to me but I am not the one that makes the decision, or maybe I do since it is my computer :) but I am not the one that uploads it to sourceforge and makes it official. It's been a long time since I installed from a binary. Are all the current osx version 32bit only, I don't see anything about 32/64 bit. Vincent > > Supporting 10.3.9 may be a bit much these days, so it's probably easiest > to build on a 10.4 machine, except for the 2.7 64bit build on 10.5. > > In theory, it should all be buildable on 10.6, but I know I've struggled > with doing that sort of thing -- but maybe the macpython folks could help. > > In the past, numpy builds have "just worked", so maybe it's as simple as > finding a 10.4 machine to build on (I don't have one anymore, we're not > allowed to have them on our network, since Apple stopped supplying > security patches) > > 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 > > Chris.Barker at noaa.gov > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -- Thanks Vincent Davis 720-301-3003 From Luke.Pinner at environment.gov.au Wed Oct 13 00:14:28 2010 From: Luke.Pinner at environment.gov.au (Pinner, Luke) Date: Wed, 13 Oct 2010 15:14:28 +1100 Subject: [Numpy-discussion] Extract groups of/individual bit values from UInt16 array [SEC=UNCLASSIFIED] Message-ID: <64102B2FB850C345B04D09C82018F45F056E4C7F@ACT01VEXCCL04.internal.govt> I'm working with some MODIS satellite imagery. MODIS data includes a quality flag mask. For the particular dataset I'm working with, this is a two dimensional unsigned 16 bit integer array. The quality flags are stored as one or more bits in each integer value: Bits are numbered from 0 (least significant bit) Bit Long name Key 0-1 MODLAND_QA 00=VI produced, good quality 01=VI produced, but check other QA 10=Pixel produced, but most probably cloudy 11=Pixel not produced due to other reasons than clouds 2-5 VI usefulness 0000=Highest quality 0001=Lower quality 0010=Decreasing quality 0100=Decreasing quality 1000=Decreasing quality 1001=Decreasing quality 1010=Decreasing quality 1100=Lowest quality 1101=Quality so low that it is not useful 1110=L1B data faulty 1111=Not useful for any other reason/not processed ...... 15 Possible shadow 0=No 1=Yes Some typical values are: arr=numpy.array([51199,37013,36885,36889,34841,2062,34837,2061,35033,349 61,2185,37013,36885,2185,4109,4233], dtype=numpy.uint16) How would I extract groups of/individual bit values from such an array? Regards Luke Pinner ------ If you have received this transmission in error please notify us immediately by return e-mail and delete all copies. If this e-mail or any attachments have been sent to you in error, that error does not constitute waiver of any confidentiality, privilege or copyright in respect of information in the e-mail or attachments. Please consider the environment before printing this email. ------ From warren.weckesser at enthought.com Wed Oct 13 00:36:09 2010 From: warren.weckesser at enthought.com (Warren Weckesser) Date: Tue, 12 Oct 2010 23:36:09 -0500 Subject: [Numpy-discussion] Extract groups of/individual bit values from UInt16 array [SEC=UNCLASSIFIED] In-Reply-To: <64102B2FB850C345B04D09C82018F45F056E4C7F@ACT01VEXCCL04.internal.govt> References: <64102B2FB850C345B04D09C82018F45F056E4C7F@ACT01VEXCCL04.internal.govt> Message-ID: On Tue, Oct 12, 2010 at 11:14 PM, Pinner, Luke < Luke.Pinner at environment.gov.au> wrote: > I'm working with some MODIS satellite imagery. MODIS data includes a > quality flag mask. For the particular dataset I'm working with, this is > a two dimensional unsigned 16 bit integer array. The quality flags are > stored as one or more bits in each integer value: > > Bits are numbered from 0 (least significant bit) > Bit Long name Key > 0-1 MODLAND_QA > 00=VI produced, good quality > 01=VI produced, but check other QA > 10=Pixel produced, but most probably > cloudy > 11=Pixel not produced due to other > reasons > than clouds > 2-5 VI usefulness > 0000=Highest quality > 0001=Lower quality > 0010=Decreasing quality > 0100=Decreasing quality > 1000=Decreasing quality > 1001=Decreasing quality > 1010=Decreasing quality > 1100=Lowest quality > 1101=Quality so low that it is not > useful > 1110=L1B data faulty > 1111=Not useful for any other reason/not > processed > ...... > 15 Possible shadow > 0=No > 1=Yes > > > Some typical values are: > arr=numpy.array([51199,37013,36885,36889,34841,2062,34837,2061,35033,349 > 61,2185,37013,36885,2185,4109,4233], dtype=numpy.uint16) > > How would I extract groups of/individual bit values from such an array? > You could use the shift (>>) and bitwise 'and' (&) operators: In [50]: arr Out[50]: array([51199, 37013, 36885, 36889, 34841, 2062, 34837, 2061, 35033, 34961, 2185, 37013, 36885, 2185, 4109, 4233], dtype=uint16) In [51]: qa = arr & 3 In [52]: qa Out[52]: array([3, 1, 1, 1, 1, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1], dtype=uint16) In [53]: usefulness = (arr >> 2) & 15 In [54]: usefulness Out[54]: array([15, 5, 5, 6, 6, 3, 5, 3, 6, 4, 2, 5, 5, 2, 3, 2], dtype=uint16) In [55]: shadow = arr >> 15 In [56]: shadow Out[56]: array([1, 1, 1, 1, 1, 0, 1, 0, 1, 1, 0, 1, 1, 0, 0, 0], dtype=uint16) Warren -------------- next part -------------- An HTML attachment was scrubbed... URL: From paustin at eos.ubc.ca Wed Oct 13 00:53:26 2010 From: paustin at eos.ubc.ca (Philip Austin) Date: Tue, 12 Oct 2010 21:53:26 -0700 Subject: [Numpy-discussion] Extract groups of/individual bit values from UInt16 array In-Reply-To: <64102B2FB850C345B04D09C82018F45F056E4C7F@ACT01VEXCCL04.internal.govt> References: <64102B2FB850C345B04D09C82018F45F056E4C7F@ACT01VEXCCL04.internal.govt> Message-ID: <4CB53B46.9090705@eos.ubc.ca> On 10/12/2010 9:14 PM, Pinner, Luke wrote: > I'm working with some MODIS satellite imagery. MODIS data includes a > quality flag mask. For the particular dataset I'm working with, this is > a two dimensional unsigned 16 bit integer array. The quality flags are > stored as one or more bits in each integer value: I've written a cython wrapper around some C++ functions that use the the std::bitset datatype to read bits in the MODIS cloud mask (the MYD035/MOD035 files). Email me if you'd like a copy with a simple demo, it wouldn't be hard to adapt to the quality flag mask -- regards, Phil Austin From wardefar at iro.umontreal.ca Wed Oct 13 01:11:33 2010 From: wardefar at iro.umontreal.ca (David Warde-Farley) Date: Wed, 13 Oct 2010 01:11:33 -0400 Subject: [Numpy-discussion] www.numpy.org url issues In-Reply-To: References: Message-ID: <35F96BEB-3E37-4901-BD2B-635DB354AF82@iro.umontreal.ca> I'm not sure who registered/owns numpy.org, but it looks like a frame sitting on top of numpy.scipy.org. On 2010-10-12, at 3:50 PM, Vincent Davis wrote: > When visiting links starting at www.numpy.org the URL in the address > bar does not change. For example clicking the "getting Numpy" takes > you to http://www.scipy.org/Download but the URL in the address bar > does not change. So now if I wanted to email that page to someone it > would not be obvious what the right URL would be. > > Also I have noticed that numpy.org mixes new.scipy.org and scipy.org > (actual url not what is displayed) different than if you start from > scip.org. > > If you start at scipy.org everything works right. > > Ok so maybe this only bugs me :) > -- > Thanks > Vincent Davis > 720-301-3003 > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion From jason-sage at creativetrax.com Wed Oct 13 03:10:49 2010 From: jason-sage at creativetrax.com (Jason Grout) Date: Wed, 13 Oct 2010 02:10:49 -0500 Subject: [Numpy-discussion] Development workflow In-Reply-To: References: Message-ID: <4CB55B79.3030702@creativetrax.com> On 10/12/10 10:33 AM, Charles R Harris wrote: > On Tue, Oct 12, 2010 at 9:22 AM, Pierre GM wrote: > >> >> On Oct 12, 2010, at 5:10 PM, David Cournapeau wrote: >> >>> On Tue, Oct 12, 2010 at 6:06 PM, Pierre GM wrote: >>>> All, >>>> All my sincere apologies for the mess I caused... The changes I wanted >> to commit were quite minimal (just a few lines in a test), but I obviously >> included some stuffs I didn't want too... >>> >>> No worries. Unless someone beats me to it, I will revert your changes >>> tomorrow morning (in 6-7 hours), so that you can reapply them as you >>> intended. >> >> I gonna try again in a couple of hours. Looks like I need to specifically >> exclude the files created by a `python setup.py develop`. Would it be worth >> to add those files in the numpy/.gitignore ? I just put some in my >> .git/info/exclude. >> > > What is curious is how the project files got added in the first place ;) But > Jarrod committed an improved .gitignore file that should help. I always run > git status before committing anything unless I am going to specify the files > to commit. > I'll add that I find "git gui" invaluable, especially while I'm learning the multitude of git options. I can quickly see at a glance all changes, stage/unstage lines, hunks, or files (by right-clicking on the line/hunk, or clicking on the icon next to the file), and double-check that everything is the way I want it. I can also check a box to amend the last commit (and see exactly what that last commit was). Thanks, Jason From xscript at gmx.net Wed Oct 13 09:02:52 2010 From: xscript at gmx.net (=?utf-8?Q?Llu=C3=ADs?=) Date: Wed, 13 Oct 2010 15:02:52 +0200 Subject: [Numpy-discussion] DataArray fixes In-Reply-To: (Fernando Perez's message of "Fri, 8 Oct 2010 19:23:00 -0700") References: <86wrqywujy.wl%lluis@ginnungagap.pc.ac.upc.edu> <8662yge98e.wl%lluis@ginnungagap.pc.ac.upc.edu> Message-ID: <87zkui5jpf.fsf@ginnungagap.bsc.es> Fernando Perez writes: > On Wed, Sep 8, 2010 at 5:00 AM, Llu?s wrote: >> Well, the pull requests I posted to your repository are for fairly trivial fixes >> (but some still need documentation and regression test updates). >> > By the way Lluis, I replied to one of your requests (Keith merged the > other one, thanks!) here: How can I see which one got merged without checking one by one? > http://github.com/fperez/datarray/pull/23 > Basically it currently breaks most tests, so we can't really go > forward until it applies cleanly on trunk and actually works :) Yup, I know it brings havok to the tests, as the constructor interface is essentially different. I'll try to find some time at the beginning of next month to fix all missing bits on my pull requests. An yes, I saw you comment. On the naming issue... I thought that datarray module would be inside numpy, so the construction interface would be: numpy.datarray.array(...) User-friendly constructor with "inlined" contents. numpy.datarray.DataArray(...) Low-level contructor with uninitialized contents. Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth From ben.root at ou.edu Wed Oct 13 10:03:58 2010 From: ben.root at ou.edu (Benjamin Root) Date: Wed, 13 Oct 2010 09:03:58 -0500 Subject: [Numpy-discussion] www.numpy.org url issues In-Reply-To: <35F96BEB-3E37-4901-BD2B-635DB354AF82@iro.umontreal.ca> References: <35F96BEB-3E37-4901-BD2B-635DB354AF82@iro.umontreal.ca> Message-ID: On Wed, Oct 13, 2010 at 12:11 AM, David Warde-Farley < wardefar at iro.umontreal.ca> wrote: > I'm not sure who registered/owns numpy.org, but it looks like a frame > sitting on top of numpy.scipy.org. > > whois says that it is a "John Turner" of "Technical Computing Solutions" in Tennessee. Looks like he has owned it since 2000. Ben Root -------------- next part -------------- An HTML attachment was scrubbed... URL: From kwgoodman at gmail.com Wed Oct 13 10:12:06 2010 From: kwgoodman at gmail.com (Keith Goodman) Date: Wed, 13 Oct 2010 07:12:06 -0700 Subject: [Numpy-discussion] DataArray fixes In-Reply-To: <87zkui5jpf.fsf@ginnungagap.bsc.es> References: <86wrqywujy.wl%lluis@ginnungagap.pc.ac.upc.edu> <8662yge98e.wl%lluis@ginnungagap.pc.ac.upc.edu> <87zkui5jpf.fsf@ginnungagap.bsc.es> Message-ID: On Wed, Oct 13, 2010 at 6:02 AM, Llu?s wrote: > Fernando Perez writes: >> By the way Lluis, I replied to one of your requests (Keith merged the >> other one, thanks!) here: > > How can I see which one got merged without checking one by one? It was this one: http://github.com/fperez/datarray/commit/a66b871af0ac7d50ca7a4f4094875b588074a3e9 I added this unit test: http://github.com/fperez/datarray/commit/1015c1906f1c20de51f9f68c9ce9d605f230aa46 From ralf.gommers at googlemail.com Wed Oct 13 11:30:15 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Wed, 13 Oct 2010 23:30:15 +0800 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: <4CB4C99A.8040906@noaa.gov> References: <4CB4C99A.8040906@noaa.gov> Message-ID: On Wed, Oct 13, 2010 at 4:48 AM, Christopher Barker wrote: > Ralf Gommers wrote: > > Yes I got one response at http://projects.scipy.org/numpy/ticket/1322, a > > negative one unfortunately. > > For what it's worth, the posted binary seems to work fine on my OS-X > 10.5 PPC system (python2.6), so maybe the PPC part works, the Intel part > not. > > Thanks, good to know. > > My conclusion is that binaries built on 10.6 > > do not work on 10.5 even when using the correct SDK and deployment > > target. > > Well, I still think if you do everything right, it works, but yes, it is > a pain to get right, and a pain to test. Building on the oldest system > you want to support is a lot easier. > I don't think so - at least I have not been able to find a fix for the error below in the many many bug reports one can find: ImportError?: dlopen(somefile.so, 2): no suitable image found. Did find: somefile.so: unknown required load command 0x80000022 > > Sage distributes separate binaries for each OS X version, presumably > > compiled on those same versions. If we want to have a 10.5 binary we > > should just do the same. > > I don't think so -- that's a lot to maintain, and the older versions > work on the newer OS -- so why build the newer? > Good point. I was starting from the assumption I would be building on 10.6 anyway, since that's the only version I have available myself. > > Also a lot (OK -- some, I have no idea how many) of us re-distribute, > via py2app, and so need Universal binaries that work on all the systems > we need to support. > > 10.4 or greater would be great -- basically matching the python.orgbuilds. > > > The binary naming scheme should also change to include the version. > > yup. > > > Thanks for working in this! > > -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 > > Chris.Barker at noaa.gov > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Wed Oct 13 11:31:15 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Wed, 13 Oct 2010 23:31:15 +0800 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: <4CB4CAE1.3010306@noaa.gov> References: <4CB4CAE1.3010306@noaa.gov> Message-ID: On Wed, Oct 13, 2010 at 4:53 AM, Christopher Barker wrote: > Vincent Davis wrote: > > Ok, Friedrich and I are working on setting up a machine for building > > on 10.5 and hope (I do) to have that going for 1.5.1rc1 > > I hope to do a 10.6 for 1.5rc1 also. > > why have a separate 10.6 build? > > And have we given up on 10.4? > 10.4 works with current binaries AFAIK. Ralf > > -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 > > Chris.Barker at noaa.gov > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Chris.Barker at noaa.gov Wed Oct 13 12:44:56 2010 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 13 Oct 2010 09:44:56 -0700 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: References: <4CB4C99A.8040906@noaa.gov> Message-ID: <4CB5E208.5030909@noaa.gov> On 10/13/10 8:30 AM, Ralf Gommers wrote: > For what it's worth, the posted binary seems to work fine on my OS-X > 10.5 PPC system (python2.6), so maybe the PPC part works, the Intel part > not. > > Thanks, good to know. > > > My conclusion is that binaries built on 10.6 > > do not work on 10.5 even when using the correct SDK and deployment > > target. It sounds like they work on everything except Intel 10.5 -- is that right? > Well, I still think if you do everything right, it works, but yes, it is > a pain to get right, and a pain to test. Building on the oldest system > you want to support is a lot easier. > > I don't think so - at least I have not been able to find a fix for the > error below in the many many bug reports one can find: > > ImportError?: dlopen(somefile.so, 2): no suitable image found. Did find: > > somefile.so: unknown required load command 0x80000022 Well, there are two options now: 1) keep trying to fix that error -- a post to the pythonmac list might help there. 2) Punt, and just build on an older system. It sounds like Vincent may be able to help out with that. (I've got a Intel 10.6 system and a PPC 10.5 system now, but I'll probably lose the 10.5 one soon) On 10/12/10 6:12 PM, Vincent Davis wrote: >>> install on 10.5 with binaries made on 10.6. So if I can learn >>> something and help others that is great. Vincent -- if you are game, I suggest: Set up a 10.4 system, install the python.org 2.5, 2.6 and 32bit 2.7 binaries. On that, build: >> Python 2.5: 32-bit PPC/i386 for Mac OS X 10.3.9 through 10.6 >> >> Python 2.6: 32-bit PPC/i386 for Mac OS X 10.3.9 through 10.6 >> >> Python 2.7 32-bit PPC/i386 for Mac OS X 10.3.9 through 10.6 On a 10.5 system, build: >> Python 2.7 PPC/i386/x86-64 for Mac OS X 10.5 or later As for Python 3k -- I have no idea! I might be able to do the 10.5 builds -- but I don't know for how long. Do you have the machines (or VMs) to do that? Thanks so much! NOTE: are there buildbots somewhere that could be used for this? -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 Chris.Barker at noaa.gov From p.sanjey at gmail.com Wed Oct 13 12:45:22 2010 From: p.sanjey at gmail.com (P Sanjey) Date: Wed, 13 Oct 2010 12:45:22 -0400 Subject: [Numpy-discussion] 32 bit version numpy Message-ID: Dear all, How can I build a 32 bit numpy on a x86_64 machine? I have python installed as 32 bit as well. Please would you mind giving me the commands? I am suing a Fedora core 3 machine. From fperez.net at gmail.com Wed Oct 13 14:25:25 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 13 Oct 2010 11:25:25 -0700 Subject: [Numpy-discussion] DataArray fixes In-Reply-To: <87zkui5jpf.fsf@ginnungagap.bsc.es> References: <86wrqywujy.wl%lluis@ginnungagap.pc.ac.upc.edu> <8662yge98e.wl%lluis@ginnungagap.pc.ac.upc.edu> <87zkui5jpf.fsf@ginnungagap.bsc.es> Message-ID: On Wed, Oct 13, 2010 at 6:02 AM, Llu?s wrote: > Yup, I know it brings havok to the tests, as the constructor interface > is essentially different. > > I'll try to find some time at the beginning of next month to fix all > missing bits on my pull requests. > > An yes, I saw you comment. On the naming issue... I thought that > datarray module would be inside numpy, so the construction interface > would be: > ? ? ?numpy.datarray.array(...) > ? ? ? ?User-friendly constructor with "inlined" contents. > ? ? ?numpy.datarray.DataArray(...) > ? ? ? ?Low-level contructor with uninitialized contents. I see your point, but I think overriding the 'array' name is not very safe in the long run. Imagine reading a fragment of code using datarrays, you'd have to constantly look at the top for the import line, to see 'is this the 'array' from datarray or the numpy one? And if you need to use both (likely a very common scenario) you'd be aliasing one of them all the time. So let's avoid the naming collision from the beginning, rather than having everyone work around it always. Cheers, f From vincent at vincentdavis.net Wed Oct 13 15:36:11 2010 From: vincent at vincentdavis.net (Vincent Davis) Date: Wed, 13 Oct 2010 13:36:11 -0600 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: <4CB5E208.5030909@noaa.gov> References: <4CB4C99A.8040906@noaa.gov> <4CB5E208.5030909@noaa.gov> Message-ID: On Wed, Oct 13, 2010 at 10:44 AM, Christopher Barker wrote: > On 10/13/10 8:30 AM, Ralf Gommers wrote: >> ? ? For what it's worth, the posted binary seems to work fine on my OS-X >> ? ? 10.5 PPC system (python2.6), so maybe the PPC part works, the Intel part >> ? ? not. >> >> Thanks, good to know. >> >> ? ? ?> My conclusion is that binaries built on 10.6 >> ? ? ?> do not work on 10.5 even when using the correct SDK and deployment >> ? ? ?> target. > > It sounds like they work on everything except Intel 10.5 -- is that right? > >> ? ? Well, I still think if you do everything right, it works, but yes, it is >> ? ? a pain to get right, and a pain to test. Building on the oldest system >> ? ? you want to support is a lot easier. >> >> I don't think so - at least I have not been able to find a fix for the >> error below in the many many bug reports one can find: >> >> ImportError?: dlopen(somefile.so, 2): no suitable image found. Did find: >> >> ? ? ?somefile.so: unknown required load command 0x80000022 > > Well, there are two options now: > > 1) keep trying to fix that error -- a post to the pythonmac list might > help there. > > 2) Punt, and just build on an older system. It sounds like Vincent may > be able to help out with that. > > (I've got a Intel 10.6 system and a PPC 10.5 system now, but I'll > probably lose the 10.5 one soon) > > On 10/12/10 6:12 PM, Vincent Davis wrote: >>>> install on 10.5 with binaries made on 10.6. So if I can learn >>>> something and help others that is great. > > Vincent -- if you are game, I suggest: > > Set up a 10.4 system, install the python.org 2.5, 2.6 and 32bit 2.7 > binaries. > > On that, build: > >>> Python 2.5: 32-bit PPC/i386 for Mac OS X 10.3.9 through 10.6 >>> >>> Python 2.6: 32-bit PPC/i386 for Mac OS X 10.3.9 through 10.6 >>> >>> Python 2.7 32-bit PPC/i386 for Mac OS X 10.3.9 through 10.6 > > On a 10.5 system, build: > >>> Python 2.7 PPC/i386/x86-64 for Mac OS X 10.5 or later > > As for Python 3k -- I have no idea! > > I might be able to do the 10.5 builds -- but I don't know for how long. > > Do you have the machines (or VMs) to do that? No it's an injured MacBook Pro. Installing on different partitions 10.5 and 10.6 need to look for 10.4. Its an intel and I think only some 10.4 DVDs work, I think some only have the ppc version. Friedrich and I are working on it. We just got a vpn setup for him to connect to the computer. I am in Colorado and he is in Germany. I hope to do some builds. What is the best way to test them? Try to install and run numpy.test() ? Vincent Vincent > > Thanks so much! > > NOTE: are there buildbots somewhere that could be used for this? > > -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 > > Chris.Barker at noaa.gov > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -- Thanks Vincent Davis 720-301-3003 From friedrichromstedt at gmail.com Wed Oct 13 15:48:12 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Wed, 13 Oct 2010 21:48:12 +0200 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: <4CB4E348.5070702@noaa.gov> References: <4CB4CAE1.3010306@noaa.gov> <4CB4E348.5070702@noaa.gov> Message-ID: 2010/10/13 Christopher Barker : > On 10/12/10 2:00 PM, Vincent Davis wrote: >> I could do 10.4 also. For me doing this is maybe best described as a >> curiosity. But my understanding was that some where having trouble >> install on 10.5 with binaries made on 10.6. So if I can learn >> something and help others that is great. > > Well, I appreciate the effort. Thanks a lot. > Ideally, I think the Mac numpy binaries should match the python.org > python binaries: > > Python 2.5: 32-bit PPC/i386 for Mac OS X 10.3.9 through 10.6 > Python 2.6: 32-bit PPC/i386 for Mac OS X 10.3.9 through 10.6 > Python 2.7 32-bit PPC/i386 for Mac OS X 10.3.9 through 10.6 > Python 2.7 PPC/i386/x86-64 for Mac OS X 10.5 or later > Python 3 ??? (similar I think) > > Supporting 10.3.9 may be a bit much these days, so it's probably easiest > to build on a 10.4 machine, except for the 2.7 64bit build on 10.5. We have to decide about how to install Python on the machines. It aren't VMs, as one cannot virtualise workstation Mac OS X using acceptable tools. The most straightforward way would be to just install the python.org binaries available. Note that Python 2.5 *must* be compiled on Mac, there is no binary on python.org. I would like to discuss the feasibility of compiling numpy against a host-built Python built from the sources from python.org. In this case I would compile including the x86_64 arch, if it is available on 10.5 at all? Could both users of a self-built Python (e.g. 2.6 on 10.6, this would be my case), use this precompiled numpy then, as well as users using the python.org binaries? It would enable users to use x86_64 arch without self-compiling. Is there a check if the python.org installer was run and is registered in the computer's package database? Ralf, what is the advantage of hard-coding the destination directory over running a setup.py script as postflight in the package installer? (I understood that background-compilation is really not such a bright idea.) The hidden setup.py would be compatible with all installation locations of the user's Python. > In theory, it should all be buildable on 10.6, but I know I've struggled > with doing that sort of thing -- but maybe the macpython folks could help. I would like to concentrate first on the 10.5 machine of Vincent. I had the attitude to set up an openvpn first, because I personally don't like to use 3rd party servers when transferring passwords. The VPN is up and running, and the authentication is PKI based. This are the open questions: 1) Installation scheme of the different Pythons on the packager machine (binary or host-compiled) 2) Layout of the installer (hardcoded or hidden setup.py) Friedrich From vincent at vincentdavis.net Wed Oct 13 15:52:44 2010 From: vincent at vincentdavis.net (Vincent Davis) Date: Wed, 13 Oct 2010 13:52:44 -0600 Subject: [Numpy-discussion] www.numpy.org url issues In-Reply-To: References: <35F96BEB-3E37-4901-BD2B-635DB354AF82@iro.umontreal.ca> Message-ID: On Wed, Oct 13, 2010 at 8:03 AM, Benjamin Root wrote: > > > On Wed, Oct 13, 2010 at 12:11 AM, David Warde-Farley > wrote: >> >> I'm not sure who registered/owns numpy.org, but it looks like a frame >> sitting on top of numpy.scipy.org. >> > > whois says that it is a "John Turner" of "Technical Computing Solutions" in > Tennessee.? Looks like he has owned it since 2000. I assumed it was a server config issue. Googling numpy get all scipy urls with numpy.scipy.org at the top. Maybe the link on github to the home page should point to numpy.scipy.org rather than numpy.org. If the control of numpy.org is in question or is not working correctly. Vincent > > Ben Root > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > -- Thanks Vincent Davis 720-301-3003 From ferrell at diablotech.com Wed Oct 13 17:17:02 2010 From: ferrell at diablotech.com (Robert Ferrell) Date: Wed, 13 Oct 2010 15:17:02 -0600 Subject: [Numpy-discussion] www.numpy.org url issues In-Reply-To: References: <35F96BEB-3E37-4901-BD2B-635DB354AF82@iro.umontreal.ca> Message-ID: <37DDB5F8-32BA-449C-B74C-3AAA7665A406@diablotech.com> I forwarded this msg to John, in case he isn't watching this list. I recall that around that time (Y2K) John grabbed a few domains of public projects and donated them as soon as the project was ready for it. (To keep the squatters at bay I guess.) -robert On Oct 13, 2010, at 8:03 AM, Benjamin Root wrote: > > > On Wed, Oct 13, 2010 at 12:11 AM, David Warde-Farley > wrote: > I'm not sure who registered/owns numpy.org, but it looks like a > frame sitting on top of numpy.scipy.org. > > > whois says that it is a "John Turner" of "Technical Computing > Solutions" in Tennessee. Looks like he has owned it since 2000. > > Ben Root > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion -------------- next part -------------- An HTML attachment was scrubbed... URL: From Chris.Barker at noaa.gov Wed Oct 13 19:26:12 2010 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 13 Oct 2010 16:26:12 -0700 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: References: <4CB4CAE1.3010306@noaa.gov> <4CB4E348.5070702@noaa.gov> Message-ID: <4CB64014.2080707@noaa.gov> On 10/13/10 12:48 PM, Friedrich Romstedt wrote: > 2010/10/13 Christopher Barker: >> Ideally, I think the Mac numpy binaries should match the python.org >> python binaries: >> >> Python 2.5: 32-bit PPC/i386 for Mac OS X 10.3.9 through 10.6 >> Python 2.6: 32-bit PPC/i386 for Mac OS X 10.3.9 through 10.6 >> Python 2.7 32-bit PPC/i386 for Mac OS X 10.3.9 through 10.6 >> Python 2.7 PPC/i386/x86-64 for Mac OS X 10.5 or later >> Python 3 ??? (similar I think) > We have to decide about how to install Python on the machines. It > aren't VMs, as one cannot virtualise workstation Mac OS X using > acceptable tools. there is no problem with multiple python versions being installed at once on one machine -- only one is "Current", but all you need to do to build for others is specify: python2.5 setup.py build python2.6 setup.py build etc... > The most straightforward way would be to just install the python.org > binaries available. Note that Python 2.5 *must* be compiled on Mac, > there is no binary on python.org. there is one for 2.5.4, but not for 2.5.5 -- in fact, it looks like there are NO binaries for 2.5.5 on python.org. I don't see any reason to worry about it thought, 2.5.4 should be fine -- that's what people are likely to be running anyway. > I would like to discuss the feasibility of compiling numpy against a > host-built Python built from the sources from python.org. What's the point? Anyone that builds their own python can build their own numpy, the point of the binaries is to target the less experienced user. > In this > case I would compile including the x86_64 arch, if it is available on > 10.5 at all? Could both users of a self-built Python (e.g. 2.6 on > 10.6, this would be my case), use this precompiled numpy then, as well > as users using the python.org binaries? It would enable users to use > x86_64 arch without self-compiling. I suppose so, but only if you distribute the python binary too -- I"d say if you want 64bit, use 2.7. I think Ronald made a pretty good choice with the way he set up the binaries on python.org. > Is there a check if the python.org installer was run and is registered > in the computer's package database? I have not idea how to do that -- but OS_X's "package manager" is really pretty lame -- it's not really a package manager, really just an installer. > Ralf, what is the advantage of hard-coding the destination directory > over running a setup.py script as postflight in the package installer? > (I understood that background-compilation is really not such a bright > idea.) The hidden setup.py would be compatible with all installation > locations of the user's Python. if you are going to do that, you might as well have them download a tarball and "setup.py install", or use a egg. The goal of the binaries is to be, well, binary, and be an easy point&click install. If you use macport or fink for your python, use them for numpy, if you build your own python, build your own numpy. In the MacPython community, we are trying (though largely failing!) to be able to recommend one simple way to do python on the Mac: the python.org installers, and binary packages built for them. There are two fairly distinct user groups for OS-X: The unix-y folks that use the command line compile stuff for themselves, etc, and the Mac folks that excepct point+click installers -- the point of the binaries is to target the second group. > I would like to concentrate first on the 10.5 machine of Vincent. but can we build on 10.5 and have it work on 10.4? In theory yes, but then in theory we can build on 10.6, too... > 1) Installation scheme of the different Pythons on the packager > machine (binary or host-compiled) see above -- host compiled really isn't the point -- there are already ways to do that (by the way, not every python user even has the compiler installed) > 2) Layout of the installer (hardcoded or hidden setup.py) I don't know if you can embed a setup.py in a mpkg, but I wouldn't bother, with all the binary compatibility issues, this will be an installer designed for a particular python install, anyway. -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 Chris.Barker at noaa.gov From Chris.Barker at noaa.gov Wed Oct 13 19:32:48 2010 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 13 Oct 2010 16:32:48 -0700 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: References: <4CB4C99A.8040906@noaa.gov> <4CB5E208.5030909@noaa.gov> Message-ID: <4CB641A0.2040900@noaa.gov> On 10/13/10 12:36 PM, Vincent Davis wrote: >> Do you have the machines (or VMs) to do that? > > No it's an injured MacBook Pro. Installing on different partitions > 10.5 and 10.6 need to look for 10.4. Its an intel and I think only > some 10.4 DVDs work, I think some only have the ppc version. what a pain -- how I long for open source....But I think I have a 104 Intel DVD at home, let me know if I should look for it. (I'm running 10.5 on that machine, now) > What is the best way to test them? Try to install > and run numpy.test() ? That's about all I know how to do. -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 Chris.Barker at noaa.gov From vincent at vincentdavis.net Wed Oct 13 21:48:18 2010 From: vincent at vincentdavis.net (Vincent Davis) Date: Wed, 13 Oct 2010 19:48:18 -0600 Subject: [Numpy-discussion] installing different tag or branches from git source Message-ID: Ok so this is more of a git question but and I think it might be simple I just don't get it. Lets say I get a copy of numpy, $git clone http://github.com/numpy/numpy.git and now I what install the 1.4.1 release which is a "tag" or I want to install 1.4.x maintenance which is a "branch". My understanding is that git clone get everything, I kinda get how I can switch branches git checkout maintenance/1.4.x not sure about how to do this with tags and not really sure what this actually does. So is this right? If I git clone http://github.com/numpy/numpy.git git checkout v1.4.0 I will not have release 1.4.0 source in my numpy folder? and git checkout maintenance/1.4.x I will have the maintenance/1.4.x source in my numpy folder? I got the link to http://docs.scipy.org/doc/numpy/dev/gitwash/index.html from another email tread but I don't think it can be found by starting at http://www.scipy.org/Developer_Zone How does one add a link to that page? -- Thanks Vincent Davis 720-301-3003 From friedrichromstedt at gmail.com Wed Oct 13 22:35:49 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Thu, 14 Oct 2010 04:35:49 +0200 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: <4CB64014.2080707@noaa.gov> References: <4CB4CAE1.3010306@noaa.gov> <4CB4E348.5070702@noaa.gov> <4CB64014.2080707@noaa.gov> Message-ID: Okay I guessed that, so first, we (Vincent and me) are just going the normal route and make a working solution. So we're going to use the standard (in the best sense) python.org installers and we'll compile against them. I'll test the installers on my own 10.6 notebook and on the rather virgin 10.5 notebook of a colleague, with all the nose bells'n'whistles. 2010/10/14 Christopher Barker : > there is no problem with multiple python versions being installed at > once on one machine -- only one is "Current", but all you need to do to > build for others is specify: > > python2.5 setup.py build > python2.6 setup.py build > > etc... good. I guess the paver mentioned before does the rest of the work. We'll look into it. >> The most straightforward way would be to just install the python.org >> binaries available. ?Note that Python 2.5 *must* be compiled on Mac, >> there is no binary on python.org. > > there is one for 2.5.4, but not for 2.5.5 -- in fact, it looks like > there are NO binaries for 2.5.5 on python.org. I don't see any reason to > worry about it thought, 2.5.4 should be fine -- that's what people are > likely to be running anyway. Okay thanks. >> I would like to discuss the feasibility of compiling numpy against a >> host-built Python built from the sources from python.org. > > What's the point? Anyone that builds their own python can build their > own numpy, the point of the binaries is to target the less experienced user. I agree. >> ?In this >> case I would compile including the x86_64 arch, if it is available on >> 10.5 at all? ?Could both users of a self-built Python (e.g. 2.6 on >> 10.6, this would be my case), use this precompiled numpy then, as well >> as users using the python.org binaries? ?It would enable users to use >> x86_64 arch without self-compiling. > > I suppose so, but only if you distribute the python binary too -- I"d > say if you want 64bit, use 2.7. I think Ronald made a pretty good choice > with the way he set up the binaries on python.org. Just btw, I remember lots of issues with 2.7, but it may have been matplotlib. >> Is there a check if the python.org installer was run and is registered >> in the computer's package database? > > I have not idea how to do that -- but OS_X's "package manager" is really > pretty lame -- it's not really a package manager, really just an installer. Hm, not really, you can specify URLs where to download from, have you ever looked into the (10.6) PackageMaker? From my impression, it's a click-and-point package manager. (I.e., one downloads an executable for each download ...) >> Ralf, what is the advantage of hard-coding the destination directory >> over running a setup.py script as postflight in the package installer? >> ? (I understood that background-compilation is really not such a bright >> idea.) ?The hidden setup.py would be compatible with all installation >> locations of the user's Python. > > if you are going to do that, you might as well have them download a > tarball and "setup.py install", or use a egg. The goal of the binaries > is to be, well, binary, and be an easy point&click install. If you use > macport or fink for your python, use them for numpy, if you build your > own python, build your own numpy. Ok, I see, it's just a matter of taste (not mine obviously). > In the MacPython community, we are trying (though largely failing!) to > be able to recommend one simple way to do python on the Mac: the > python.org installers, and binary packages built for them. Everyone on the numpy list knows this never-ending story ... :-) At least in principle. > There are two fairly distinct user groups for OS-X: The unix-y folks > that use the command line compile stuff for themselves, etc, and the Mac > folks that excepct point+click installers -- the point of the binaries > is to target the second group. Very clear. Thanks. >> I would like to concentrate first on the 10.5 machine of Vincent. > > but can we build on 10.5 and have it work on 10.4? In theory yes, but > then in theory we can build on 10.6, too... Nothing against using a 10.4 on Vincent's computer, the "concentrate on" was meant somehow else, but I don't remember. We're ready to start now, and will come back when we're stuck somehow. Friedrich >> 1) ?Installation scheme of the different Pythons on the packager >> machine (binary or host-compiled) > > see above -- host compiled really isn't the point -- there are already > ways to do that (by the way, not every python user even has the compiler > installed) > >> 2) ?Layout of the installer (hardcoded or hidden setup.py) > > I don't know if you can embed a setup.py in a mpkg, but I wouldn't > bother, with all the binary compatibility issues, this will be an > installer designed for a particular python install, anyway. > > -Chris From friedrichromstedt at gmail.com Thu Oct 14 00:29:44 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Thu, 14 Oct 2010 06:29:44 +0200 Subject: [Numpy-discussion] installing different tag or branches from git source In-Reply-To: References: Message-ID: There are good docs at kernel.org, or in your local system maybe, the URL I'm using usually is http://www.kernel.org/pub/software/scm/git/docs/ You can switch around my modifying the URL once at git-checkout (what will be your starting point) or similar. :-) Friedrich From structures-it at embl-heidelberg.de Thu Oct 14 03:20:37 2010 From: structures-it at embl-heidelberg.de (Frank Thommen) Date: Thu, 14 Oct 2010 09:20:37 +0200 Subject: [Numpy-discussion] Need help for the migration from Numeric to numpy Message-ID: <4CB6AF45.6020903@embl-heidelberg.de> Hi, I'm trying to help a user to migrate from Numeric to numpy. I found reference to alter_code1.py on http://numpy.scipy.org/old_array_packages.html. First I tried the conversion script: # python2.6 /path/to/alter_code1.py test.py and alternatively # python2.6 /path/to/alter_code1.py ./ This didn't modify test.py at all. Then I tried to convert from within Python: # python2.6 Python 2.6.2 (r262:71600, Aug 5 2010, 14:21:11) [GCC 4.4.4] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import numpy.numarray.alter_code1 as noa >>> noa.convertfile("test.py") >>> ^D # This modified test.py, but only partially. E.g. the import line was still untouched, meaning that it still imported Numeric instead of numpy: # diff ../test-original.py test.py 0a1,2 > ## Automatically adapted for numpy.numarray Oct 06, 2010 by > 49c51 < pyfid.byteswap() --- > pyfid.byteswap(True) 74c76 < databin.byteswap() --- > databin.byteswap(True) # After I've changed 'import os, string, array, Numeric' to 'import os, string, array, numpy' I realized, that the conversion had introduced errors: # python2.6 ./test.py Traceback (most recent call last): File "./test.py", line 115, in combineser3D(td3,td2,td1,ser,ser1,fidnum) File "./test.py", line 21, in combineser3D allser1=readBrukerSer(tdall,td3,ser) File "./test.py", line 51, in readBrukerSer pyfid.byteswap(True) TypeError: byteswap() takes no arguments (1 given) # So either this method doesn't work (any more) or I am doing something wrong. Are there other ways for a transition from Numeric to numpy? The numpy version we are using is 1.4.1 with Python 2.6.2 from python.org. Any help regarding this is highly appreciated. Thanks in advance frank P.S.: I've posted almost the same request as "alter_code1.py doesn't convert (any more)?" on October 6. Since I haven't received any answer I'm trying again with a - hopefully - more attracting subject ;-) From stefan at sun.ac.za Thu Oct 14 04:39:57 2010 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 14 Oct 2010 10:39:57 +0200 Subject: [Numpy-discussion] Using issubdtype to check integer types Message-ID: Hi all, Is this behaviour correct? In [18]: np.issubdtype(np.uint16, np.uint) Out[18]: False Regards St?fan From ralf.gommers at googlemail.com Thu Oct 14 08:41:36 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Thu, 14 Oct 2010 20:41:36 +0800 Subject: [Numpy-discussion] installing different tag or branches from git source In-Reply-To: References: Message-ID: On Thu, Oct 14, 2010 at 9:48 AM, Vincent Davis wrote: > Ok so this is more of a git question but and I think it might be > simple I just don't get it. > Lets say I get a copy of numpy, > $git clone http://github.com/numpy/numpy.git > and now I what install the 1.4.1 release which is a "tag" > or > I want to install 1.4.x maintenance which is a "branch". > > My understanding is that git clone get everything, I kinda get how I > can switch branches git checkout maintenance/1.4.x not sure about how > to do this with tags and not really sure what this actually does. > > So is this right? > If I > git clone http://github.com/numpy/numpy.git > git checkout v1.4.0 > I will not have release 1.4.0 source in my numpy folder? > if not=now, then yes. > and > git checkout maintenance/1.4.x > I will have the maintenance/1.4.x source in my numpy folder? > yep. > > I got the link to > http://docs.scipy.org/doc/numpy/dev/gitwash/index.html from another > email tread but I don't think it can be found by starting at > http://www.scipy.org/Developer_Zone > How does one add a link to that page? > It's a wiki, the edit button (the talk cloud icon) works for me. Cheers, Ralf > > -- > Thanks > Vincent Davis > 720-301-3003 > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Thu Oct 14 09:26:59 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Thu, 14 Oct 2010 21:26:59 +0800 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: <4CB5E208.5030909@noaa.gov> References: <4CB4C99A.8040906@noaa.gov> <4CB5E208.5030909@noaa.gov> Message-ID: On Thu, Oct 14, 2010 at 12:44 AM, Christopher Barker wrote: > On 10/13/10 8:30 AM, Ralf Gommers wrote: > > For what it's worth, the posted binary seems to work fine on my OS-X > > 10.5 PPC system (python2.6), so maybe the PPC part works, the Intel > part > > not. > > > > Thanks, good to know. > > > > > My conclusion is that binaries built on 10.6 > > > do not work on 10.5 even when using the correct SDK and deployment > > > target. > > It sounds like they work on everything except Intel 10.5 -- is that right? > > That's right. > > Well, I still think if you do everything right, it works, but yes, it > is > > a pain to get right, and a pain to test. Building on the oldest > system > > you want to support is a lot easier. > > > > I don't think so - at least I have not been able to find a fix for the > > error below in the many many bug reports one can find: > > > > ImportError?: dlopen(somefile.so, 2): no suitable image found. Did find: > > > > somefile.so: unknown required load command 0x80000022 > > Well, there are two options now: > > 1) keep trying to fix that error -- a post to the pythonmac list might > help there. > Will try that. > > 2) Punt, and just build on an older system. It sounds like Vincent may > be able to help out with that. > > He is. Good to do in parallel with 1). > (I've got a Intel 10.6 system and a PPC 10.5 system now, but I'll > probably lose the 10.5 one soon) > > On 10/12/10 6:12 PM, Vincent Davis wrote: > >>> install on 10.5 with binaries made on 10.6. So if I can learn > >>> something and help others that is great. > > Vincent -- if you are game, I suggest: > > Set up a 10.4 system, install the python.org 2.5, 2.6 and 32bit 2.7 > binaries. > > On that, build: > > >> Python 2.5: 32-bit PPC/i386 for Mac OS X 10.3.9 through 10.6 > >> > >> Python 2.6: 32-bit PPC/i386 for Mac OS X 10.3.9 through 10.6 > >> > >> Python 2.7 32-bit PPC/i386 for Mac OS X 10.3.9 through 10.6 > > On a 10.5 system, build: > > >> Python 2.7 PPC/i386/x86-64 for Mac OS X 10.5 or later > > As for Python 3k -- I have no idea! > > I might be able to do the 10.5 builds -- but I don't know for how long. > > Do you have the machines (or VMs) to do that? > > Thanks so much! > > NOTE: are there buildbots somewhere that could be used for this? > > There's only one OS X buildbot ( http://buildbot.scipy.org/builders/MacOSX_x86_64), but last time it connected was in July. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsouthey at gmail.com Thu Oct 14 09:53:11 2010 From: bsouthey at gmail.com (Bruce Southey) Date: Thu, 14 Oct 2010 08:53:11 -0500 Subject: [Numpy-discussion] Need help for the migration from Numeric to numpy In-Reply-To: <4CB6AF45.6020903@embl-heidelberg.de> References: <4CB6AF45.6020903@embl-heidelberg.de> Message-ID: <4CB70B47.10602@gmail.com> On 10/14/2010 02:20 AM, Frank Thommen wrote: > Hi, > > I'm trying to help a user to migrate from Numeric to numpy. I found > reference to alter_code1.py on > http://numpy.scipy.org/old_array_packages.html. > > > First I tried the conversion script: > > # python2.6 /path/to/alter_code1.py test.py > > and alternatively > > # python2.6 /path/to/alter_code1.py ./ > > This didn't modify test.py at all. Then I tried to convert from within > Python: > > # python2.6 > Python 2.6.2 (r262:71600, Aug 5 2010, 14:21:11) > [GCC 4.4.4] on linux2 > Type "help", "copyright", "credits" or "license" for more information. >>>> import numpy.numarray.alter_code1 as noa >>>> noa.convertfile("test.py") >>>> ^D > # > > This modified test.py, but only partially. E.g. the import line was > still untouched, meaning that it still imported Numeric instead of numpy: > > > # diff ../test-original.py test.py > 0a1,2 >> ## Automatically adapted for numpy.numarray Oct 06, 2010 by >> > 49c51 > < pyfid.byteswap() > --- >> pyfid.byteswap(True) > 74c76 > < databin.byteswap() > --- >> databin.byteswap(True) > # > > > After I've changed 'import os, string, array, Numeric' to 'import os, > string, array, numpy' I realized, that the conversion had introduced errors: > > # python2.6 ./test.py > Traceback (most recent call last): > File "./test.py", line 115, in > combineser3D(td3,td2,td1,ser,ser1,fidnum) > File "./test.py", line 21, in combineser3D > allser1=readBrukerSer(tdall,td3,ser) > File "./test.py", line 51, in readBrukerSer > pyfid.byteswap(True) > TypeError: byteswap() takes no arguments (1 given) > # > > So either this method doesn't work (any more) or I am doing something > wrong. Are there other ways for a transition from Numeric to numpy? > The numpy version we are using is 1.4.1 with Python 2.6.2 from python.org. > > Any help regarding this is highly appreciated. > > > Thanks in advance > > frank > > > P.S.: I've posted almost the same request as "alter_code1.py doesn't > convert (any more)?" on October 6. Since I haven't received any answer > I'm trying again with a - hopefully - more attracting subject ;-) > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion Are you converting from Numeric or numarray? These are slightly different versions of 'alter_code1.py '. Anyhow I would not use it because these are likely to be very out of date (over 2 years ago). There used to be documentation on this but I do not see it anymore. This is an useful one for numarray: http://www.stsci.edu/resources/software_hardware/numarray/numarray2numpy.pdf A lot depends on the size of code and complexity of code - it will difficult to address the API changes. Essentially I just rewrote my code changing numarray functions to numpy functions (I really only used numarray). Sure my code was small and not complex but it also helped improve the code. From what I recall, the only things I was doing was changing the array declarations - especially dtypes. After those, you have to watch for function changes and new features. Also I would suggest that you have a Numeric/numarray working with some older version of Python. This enables you to check intermediate results as needed. Bruce -------------- next part -------------- An HTML attachment was scrubbed... URL: From structures-it at embl-heidelberg.de Thu Oct 14 10:03:32 2010 From: structures-it at embl-heidelberg.de (Frank Thommen) Date: Thu, 14 Oct 2010 16:03:32 +0200 Subject: [Numpy-discussion] Need help for the migration from Numeric to numpy In-Reply-To: <4CB70B47.10602@gmail.com> References: <4CB6AF45.6020903@embl-heidelberg.de> <4CB70B47.10602@gmail.com> Message-ID: <4CB70DB4.3060300@embl-heidelberg.de> Bruce Southey wrote: > On 10/14/2010 02:20 AM, Frank Thommen wrote: >> Hi, >> >> I'm trying to help a user to migrate from Numeric to numpy. I found >> reference to alter_code1.py on >> http://numpy.scipy.org/old_array_packages.html. >> >> >> [...] > Are you converting from Numeric or numarray? from Numeric. > These are slightly different versions of 'alter_code1.py '. > Anyhow I would not use it because these are likely to be very out of > date (over 2 years ago). That's what I imagined ;-) > There used to be documentation on this but I do not see it anymore. This > is an useful one for numarray: > http://www.stsci.edu/resources/software_hardware/numarray/numarray2numpy.pdf I assume, that this will not helo much when converting from Numeric? (sorry, I don't use Python myself). Thanks anyway. > A lot depends on the size of code and complexity of code - it will > difficult to address the API changes. Essentially I just rewrote my code > changing numarray functions to numpy functions (I really only used > numarray). Sure my code was small and not complex but it also helped > improve the code. From what I recall, the only things I was doing was > changing the array declarations - especially dtypes. After those, you > have to watch for function changes and new features. I cannot assess the complexity of the code regarding Numeric/numpy, as I don't use Python myself. I will forward these informations to the user in question and hopefully he can manage to convert his files. I'm afraid that will be a lot of files (he is using Numeric since many, many years and never updated to newer packages) > Also I would suggest that you have a Numeric/numarray working with some > older version of Python. This enables you to check intermediate results > as needed. We have that. It's the installation I want to get rid of...:-) Thanks a lot frank From charlesr.harris at gmail.com Thu Oct 14 10:10:21 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Thu, 14 Oct 2010 08:10:21 -0600 Subject: [Numpy-discussion] SPARC debug request Message-ID: Hi, Can someone running on SPARC take a look at ticket #1631. It is a SIGBUS error that only appears when running in 32 bit mode. I think nics has very nearly isolated the problem and it needs just a bit more work to find the fix. It would be nice to get this done for 1.5.1. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From nwagner at iam.uni-stuttgart.de Thu Oct 14 10:47:58 2010 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Thu, 14 Oct 2010 16:47:58 +0200 Subject: [Numpy-discussion] AttributeError: 'module' object has no attribute 'parse' Message-ID: Hi all, I have Installed numpy via git. numpy.test() failed. Nils >>> import numpy >>> numpy.__version__ '2.0.0.dev8621' >>> numpy.test() Running unit tests for numpy Traceback (most recent call last): File "", line 1, in File "/data/home/nwagner/local/lib/python2.5/site-packages/numpy/testing/nosetester.py", line 318, in test self._show_system_info() File "/data/home/nwagner/local/lib/python2.5/site-packages/numpy/testing/nosetester.py", line 187, in _show_system_info nose = import_nose() File "/data/home/nwagner/local/lib/python2.5/site-packages/numpy/testing/nosetester.py", line 56, in import_nose import nose File "/data/home/nwagner/local/lib/python2.5/site-packages/nose-0.11.1-py2.5.egg/nose/__init__.py", line 1, in from nose.core import collector, main, run, run_exit, runmodule File "/data/home/nwagner/local/lib/python2.5/site-packages/nose-0.11.1-py2.5.egg/nose/core.py", line 11, in from nose.config import Config, all_config_files File "/data/home/nwagner/local/lib/python2.5/site-packages/nose-0.11.1-py2.5.egg/nose/config.py", line 8, in from nose.util import absdir, tolist File "/data/home/nwagner/local/lib/python2.5/site-packages/nose-0.11.1-py2.5.egg/nose/util.py", line 14, in from compiler.consts import CO_GENERATOR File "/data/home/nwagner/local/lib/python2.5/compiler/__init__.py", line 24, in from compiler.transformer import parse, parseFile File "/data/home/nwagner/local/lib/python2.5/compiler/transformer.py", line 29, in import parser File "/data/home/nwagner/parser.py", line 3, in ast= compiler.parse( eq ) AttributeError: 'module' object has no attribute 'parse' From robert.kern at gmail.com Thu Oct 14 11:14:35 2010 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 14 Oct 2010 10:14:35 -0500 Subject: [Numpy-discussion] AttributeError: 'module' object has no attribute 'parse' In-Reply-To: References: Message-ID: On Thu, Oct 14, 2010 at 09:47, Nils Wagner wrote: > ? File > "/data/home/nwagner/local/lib/python2.5/compiler/transformer.py", > line 29, in > ? ? import parser > ? File "/data/home/nwagner/parser.py", line 3, in > > ? ? ast= compiler.parse( eq ) > AttributeError: 'module' object has no attribute 'parse' You have a local module named parser.py . This is interfering with the local "import parser" in compiler/transformer.py . Rename your module or execute numpy.test() from somewhere else. This is not a bug in numpy. -- 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 From robert.kern at gmail.com Thu Oct 14 11:18:26 2010 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 14 Oct 2010 10:18:26 -0500 Subject: [Numpy-discussion] Using issubdtype to check integer types In-Reply-To: References: Message-ID: 2010/10/14 St?fan van der Walt : > Hi all, > > Is this behaviour correct? > > In [18]: np.issubdtype(np.uint16, np.uint) > Out[18]: False Yes, it's correct. np.uint is a concrete type that is the platform-specific C unsigned long type: |1> np.uint The abstract base type is np.unsignedinteger: |3> np.issubdtype(np.uint16, np.unsignedinteger) True -- 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 From stefan at sun.ac.za Thu Oct 14 11:21:50 2010 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 14 Oct 2010 17:21:50 +0200 Subject: [Numpy-discussion] Using issubdtype to check integer types In-Reply-To: References: Message-ID: On Thu, Oct 14, 2010 at 5:18 PM, Robert Kern wrote: > |3> np.issubdtype(np.uint16, np.unsignedinteger) > True Thanks, just what I needed. Cheers St?fan From daniele at grinta.net Thu Oct 14 11:54:41 2010 From: daniele at grinta.net (Daniele Nicolodi) Date: Thu, 14 Oct 2010 17:54:41 +0200 Subject: [Numpy-discussion] Mapping of a ring buffer to a numpy array Message-ID: <4CB727C1.1070008@grinta.net> Hello, I would like to write (in cython) python bindings for a library that interfaces with data acquisition hardware trough a kernel driver. Data can be exchanged with the kernel driver trough a memory mapped ring buffer. I would like to expose this ring buffer as a numpy array, however I would like to make the ring buffer wrap around management transparent. There is a way to instruct numpy to do that? Thanks. Cheers, -- Daniele From Chris.Barker at noaa.gov Thu Oct 14 12:13:52 2010 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Thu, 14 Oct 2010 09:13:52 -0700 Subject: [Numpy-discussion] Need help for the migration from Numeric to numpy In-Reply-To: <4CB6AF45.6020903@embl-heidelberg.de> References: <4CB6AF45.6020903@embl-heidelberg.de> Message-ID: <4CB72C40.4050802@noaa.gov> On 10/14/10 12:20 AM, Frank Thommen wrote: > I'm trying to help a user to migrate from Numeric to numpy. I found > reference to alter_code1.py on > http://numpy.scipy.org/old_array_packages.html. How much code is this? I always just did the conversion by hand (with search and replace, of course!) -- it was never a big deal. It gave me the opportunity to tweak the code to ways that work better in numpy anyway. Unless you've got a LOT of code to do, I'd just change "Numeric" to "numpy" and start testing. Or run the conversion script, then test -- but I'd look at a diff too, just to make sure you understand what the script did. -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 Chris.Barker at noaa.gov From Chris.Barker at noaa.gov Thu Oct 14 12:19:27 2010 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Thu, 14 Oct 2010 09:19:27 -0700 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: References: <4CB4C99A.8040906@noaa.gov> <4CB5E208.5030909@noaa.gov> Message-ID: <4CB72D8F.90308@noaa.gov> On 10/14/10 6:26 AM, Ralf Gommers wrote: > NOTE: are there buildbots somewhere that could be used for this? > > There's only one OS X buildbot > (http://buildbot.scipy.org/builders/MacOSX_x86_64), but last time it > connected was in July. maybe a post to the pythonmac list would help this, too -- someone recently offered up buildbots for python itself, maybe they'd be willing to help out scipy, too. Come to think of it, I have a Intel 10.6 machine I could offer up -- it may not always have the same ip address, but I keep it up all the time. Can you point me to docs on how to set it up? -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 Chris.Barker at noaa.gov From structures-it at embl-heidelberg.de Thu Oct 14 12:46:07 2010 From: structures-it at embl-heidelberg.de (Frank Thommen) Date: Thu, 14 Oct 2010 18:46:07 +0200 Subject: [Numpy-discussion] Need help for the migration from Numeric to numpy In-Reply-To: <4CB72C40.4050802@noaa.gov> References: <4CB6AF45.6020903@embl-heidelberg.de> <4CB72C40.4050802@noaa.gov> Message-ID: <4CB733CF.5010202@embl-heidelberg.de> Christopher Barker wrote: > On 10/14/10 12:20 AM, Frank Thommen wrote: >> I'm trying to help a user to migrate from Numeric to numpy. I found >> reference to alter_code1.py on >> http://numpy.scipy.org/old_array_packages.html. > > How much code is this? We are speaking of potentially several hundred files. It's part of the scientific work of the user of the last nine years... Part of the problem is, that his Python/Numeric installation is 32bit and he has the last 32bit computer in the department. This installation doesn't work with a 64bit Linux even with all 32bit compatibility libraries installed. :-] > I always just did the conversion by hand (with search and replace, of > course!) -- it was never a big deal. It gave me the opportunity to tweak > the code to ways that work better in numpy anyway. > > Unless you've got a LOT of code to do, I'd just change "Numeric" to > "numpy" and start testing. > > Or run the conversion script, then test -- but I'd look at a diff too, > just to make sure you understand what the script did. Which conversion script do you mean? I couldn't find any conversion script that works or comes close to working. Cheers frank -- Frank Thommen - Structures IT Management and Support - EMBL Heidelberg structures-it at embl-heidelberg.de - +49 6221 387 8353 From Chris.Barker at noaa.gov Thu Oct 14 13:55:33 2010 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Thu, 14 Oct 2010 10:55:33 -0700 Subject: [Numpy-discussion] Need help for the migration from Numeric to numpy In-Reply-To: <4CB733CF.5010202@embl-heidelberg.de> References: <4CB6AF45.6020903@embl-heidelberg.de> <4CB72C40.4050802@noaa.gov> <4CB733CF.5010202@embl-heidelberg.de> Message-ID: <4CB74415.3050004@noaa.gov> On 10/14/10 9:46 AM, Frank Thommen wrote: > We are speaking of potentially several hundred files. It's part of the > scientific work of the user of the last nine years... Let's hope he's got some tests! > Which conversion script do you mean? I couldn't find any conversion > script that works or comes close to working. I don't know anything you don't know -- I thought you got a script to work, it just didn't do the full job -- it may well have done some of the simple scut work, though. Anyway, hundreds of files sounds like a lot, but while it's boring work, it's probably less than you'd think once you get started. You'd want a multiple-file search and replace tool, though. -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 Chris.Barker at noaa.gov From bsouthey at gmail.com Thu Oct 14 14:39:33 2010 From: bsouthey at gmail.com (Bruce Southey) Date: Thu, 14 Oct 2010 13:39:33 -0500 Subject: [Numpy-discussion] Need help for the migration from Numeric to numpy In-Reply-To: <4CB74415.3050004@noaa.gov> References: <4CB6AF45.6020903@embl-heidelberg.de> <4CB72C40.4050802@noaa.gov> <4CB733CF.5010202@embl-heidelberg.de> <4CB74415.3050004@noaa.gov> Message-ID: <4CB74E65.8050401@gmail.com> On 10/14/2010 12:55 PM, Christopher Barker wrote: > On 10/14/10 9:46 AM, Frank Thommen wrote: >> We are speaking of potentially several hundred files. It's part of the >> scientific work of the user of the last nine years... > Let's hope he's got some tests! > >> Which conversion script do you mean? I couldn't find any conversion >> script that works or comes close to working. > I don't know anything you don't know -- I thought you got a script to > work, it just didn't do the full job -- it may well have done some of > the simple scut work, though. > > Anyway, hundreds of files sounds like a lot, but while it's boring work, > it's probably less than you'd think once you get started. You'd want a > multiple-file search and replace tool, though. > > -Chris > > > It took me a while to track it down, but there used to be a module/file called 'convertcode.py' for conversion. It was mentioned as tip in Travis's 'Guide to Numpy' page 31 in Jan 6 2005 version. But the alter_code path is in Dec 7 2006 (linked at http://docs.scipy.org/doc/). It is advisable to read it as it address differences between Numeric and old numpy ie section 2.6! Travis said in the thread: http://mail.scipy.org/pipermail/numpy-discussion/2006-August/010085.html "The transition approach is to use the compatibility layer first by running oldnumeric.alter_code1.py and then running alter_code2.py which will take you from the compatibility layer to NumPy (but alter_code2 is not completed yet)." Bruce From fperez.net at gmail.com Thu Oct 14 14:56:04 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 14 Oct 2010 11:56:04 -0700 Subject: [Numpy-discussion] Need help for the migration from Numeric to numpy In-Reply-To: <4CB74415.3050004@noaa.gov> References: <4CB6AF45.6020903@embl-heidelberg.de> <4CB72C40.4050802@noaa.gov> <4CB733CF.5010202@embl-heidelberg.de> <4CB74415.3050004@noaa.gov> Message-ID: On Thu, Oct 14, 2010 at 10:55 AM, Christopher Barker wrote: >> We are speaking of potentially several hundred files. ?It's part of the >> scientific work of the user of the last nine years... > > Let's hope he's got some tests! Yup. I converted a very complex code from Numeric to numpy years ago (around the numpy 1.0 release timeframe), and it was a single (long, intense and focused) day's work. But that was thanks to a very solid test suite that let me be systematic and dumb about the whole thing (careful, but dumb). With no good test coverage, let's just say that the OP's colleague is in for a personal replay of the painful minefield scene in the BAT*21 movie :) [http://www.imdb.com/title/tt0094712] Cheers, f From vincent at vincentdavis.net Thu Oct 14 15:40:13 2010 From: vincent at vincentdavis.net (Vincent Davis) Date: Thu, 14 Oct 2010 13:40:13 -0600 Subject: [Numpy-discussion] installing different tag or branches from git source In-Reply-To: References: Message-ID: On Thu, Oct 14, 2010 at 6:41 AM, Ralf Gommers wrote: > > > On Thu, Oct 14, 2010 at 9:48 AM, Vincent Davis > wrote: >> >> Ok so this is more of a git question but and I think it might be >> simple I just don't get it. >> Lets say I get a copy of numpy, >> $git clone http://github.com/numpy/numpy.git >> and now I what install the 1.4.1 release which is a "tag" >> or >> I want to install 1.4.x maintenance which is a "branch". >> >> My understanding is that git clone get everything, I kinda get how I >> can switch branches git checkout maintenance/1.4.x not sure about how >> to do this with tags and not really sure what this actually does. >> >> So is this right? >> If I >> git clone http://github.com/numpy/numpy.git >> git checkout v1.4.0 >> I will not have release 1.4.0 source in my numpy folder? > > if not=now, then yes. Yes , and thanks Vincent > >> >> and >> git checkout maintenance/1.4.x >> I will have the maintenance/1.4.x source in my numpy folder? > > yep. >> >> I got the link to >> http://docs.scipy.org/doc/numpy/dev/gitwash/index.html from another >> email tread but I don't think it can be found by starting at >> http://www.scipy.org/Developer_Zone >> How does one add a link to that page? > > It's a wiki, the edit button (the talk cloud icon) works for me. > > Cheers, > Ralf > >> >> -- >> Thanks >> Vincent Davis >> 720-301-3003 >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > -- Thanks Vincent Davis 720-301-3003 From friedrichromstedt at gmail.com Thu Oct 14 18:47:42 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Fri, 15 Oct 2010 00:47:42 +0200 Subject: [Numpy-discussion] Awaiting confirmation before closing tickets In-Reply-To: <27DF7F62-0EA2-4404-9A86-FC5769A4F84D@gmail.com> References: <27DF7F62-0EA2-4404-9A86-FC5769A4F84D@gmail.com> Message-ID: 2010/10/11 Pierre GM : > All, > The following tickets could be closed if somebody confirmed everything works OK: > * 1586: fixed in r8714 > * 1593: fixed in r8715 > * 1591: fixed in r8713 > * 1493: fixed a while ago (sorry, I completely forgot to comment on it). > Let me know how it goes and I'll close them. Or not. 1593 seems (so far) okay to me, but I cannot see anything about "comments" which are ignored in the examples provided? For the others I'm not competent, and this is rather a re-ping for Pierre :-) Friedrich From pgmdevlist at gmail.com Thu Oct 14 19:31:16 2010 From: pgmdevlist at gmail.com (Pierre GM) Date: Fri, 15 Oct 2010 01:31:16 +0200 Subject: [Numpy-discussion] Awaiting confirmation before closing tickets In-Reply-To: References: <27DF7F62-0EA2-4404-9A86-FC5769A4F84D@gmail.com> Message-ID: <3720C991-1124-47B0-9234-AA0F36A50977@gmail.com> On Oct 15, 2010, at 12:47 AM, Friedrich Romstedt wrote: > 2010/10/11 Pierre GM : >> All, >> The following tickets could be closed if somebody confirmed everything works OK: >> * 1586: fixed in r8714 >> * 1593: fixed in r8715 >> * 1591: fixed in r8713 >> * 1493: fixed a while ago (sorry, I completely forgot to comment on it). >> Let me know how it goes and I'll close them. Or not. > > 1593 seems (so far) okay to me, but I cannot see anything about > "comments" which are ignored in the examples provided? > > For the others I'm not competent, and this is rather a re-ping for Pierre :-) I think Ralf was checking whether it was working. The piece of code he posted in his comment does what it should, so does the one for #1591, the unittests are already there... If nobody expresses any opinion, I'll close them this week-end. Or somebody can beat me to it... From friedrichromstedt at gmail.com Thu Oct 14 23:47:21 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Fri, 15 Oct 2010 05:47:21 +0200 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: <4CB72D8F.90308@noaa.gov> References: <4CB4C99A.8040906@noaa.gov> <4CB5E208.5030909@noaa.gov> <4CB72D8F.90308@noaa.gov> Message-ID: Vincent and me had some success: 15.10.10 05:34:35] Vincent Davis: so you have a dmg now? [15.10.10 05:34:48] Friedrich Romstedt: I cant believe it, I want to see the file first [15.10.10 05:35:06] Friedrich Romstedt: we have an mpkg in dist [15.10.10 05:35:37] Friedrich Romstedt: yes, we have one [15.10.10 05:36:01] Friedrich Romstedt: In Users/Shared/GitHub/project-numpy/owner-numpy/numpy-deployment/tools/numpy-macosx-installer [15.10.10 05:36:18] Friedrich Romstedt: -rw-r--r--@ 1 Friedrich wheel 8190646 Oct 14 21:33 numpy-2.0.0.dev-py2.5-python.org.dmg [15.10.10 05:36:29] Friedrich Romstedt: it's unbelievable [15.10.10 05:37:39] Friedrich Romstedt: Seems I'm too tired to be happy, but it's enjoyable anyway :-) Friedrich P.S.: Building v1.5.0rc1 failed because of ticket 1596 which seems to be closed anyway? This is py2.5 on Mac OS X 10.5. From barthelemy at crans.org Fri Oct 15 04:12:28 2010 From: barthelemy at crans.org (=?ISO-8859-1?Q?S=E9bastien_Barth=E9lemy?=) Date: Fri, 15 Oct 2010 10:12:28 +0200 Subject: [Numpy-discussion] portable doctests despite floating points numbers Message-ID: Hello all, I use doctest for examples and tests in a program which relies heavily on numpy. As floating point calculations differs slightly across computers (32/64 bits), I have troubles writing portable doctests. The doctest documentation [1] advises to use numbers in the form int/2**n. This is quite restrictive. Using numpy.set_printoptions(suppress=True) also helps, but I still have problems with numbers around 0. On some platform a result prints as 0., on others as -0. Is there a workaround? [1] http://docs.python.org/library/doctest.html#warnings From silva at lma.cnrs-mrs.fr Fri Oct 15 08:05:00 2010 From: silva at lma.cnrs-mrs.fr (Fabrice Silva) Date: Fri, 15 Oct 2010 09:05:00 -0300 Subject: [Numpy-discussion] portable doctests despite floating points numbers In-Reply-To: References: Message-ID: <1287144301.1717.4.camel@Portable-s2m.cnrs-mrs.fr> Le vendredi 15 octobre 2010, S?bastien Barth?lemy a ?crit : > Hello all, Hi Seb > I use doctest for examples and tests in a program which relies heavily > on numpy. As floating point calculations differs slightly across > computers (32/64 bits), I have troubles writing portable doctests. > The doctest documentation [1] advises to use numbers in the form > int/2**n. This is quite restrictive. > > Using numpy.set_printoptions(suppress=True) also helps, but I still > have problems with numbers around 0. On some platform a result prints > as 0., on others as -0. > > Is there a workaround? Maybe you should not rely on doctest to do the comparison between computed and expected result. You could use assert_* functions from http://docs.scipy.org/doc/numpy/reference/routines.testing.html if your results are numpy objects. assert_almost_equal and assert_approx_equal are quite powerful! Fab From p.sanjey at gmail.com Fri Oct 15 10:31:33 2010 From: p.sanjey at gmail.com (P Sanjey) Date: Fri, 15 Oct 2010 10:31:33 -0400 Subject: [Numpy-discussion] Please help a newbie install NUMPY Message-ID: Please help-I am a newbie and I wanted to try installing numpy on a local /home/usr directory but got the following errors-I am not sure where to even begin fixing this problem and any help would be useful I just did the standard python setup.py build and got the following (loooooong) error message ********************************************************** non-existing path in 'numpy/distutils': 'site.cfg' F2PY Version 1 blas_opt_info: blas_mkl_info: libraries mkl,vml,guide not found in /home/sanjey/lib libraries mkl,vml,guide not found in /usr/local/lib libraries mkl,vml,guide not found in /usr/lib NOT AVAILABLE atlas_blas_threads_info: Setting PTATLAS=ATLAS libraries ptf77blas,ptcblas,atlas not found in /home/sanjey/lib libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib libraries ptf77blas,ptcblas,atlas not found in /usr/lib/sse2 libraries ptf77blas,ptcblas,atlas not found in /usr/lib NOT AVAILABLE atlas_blas_info: libraries f77blas,cblas,atlas not found in /home/sanjey/lib libraries f77blas,cblas,atlas not found in /usr/local/lib libraries f77blas,cblas,atlas not found in /usr/lib/sse2 libraries f77blas,cblas,atlas not found in /usr/lib NOT AVAILABLE blas_info: libraries blas not found in /home/sanjey/lib libraries blas not found in /usr/local/lib FOUND: libraries = ['blas'] library_dirs = ['/usr/lib'] language = f77 FOUND: libraries = ['blas'] library_dirs = ['/usr/lib'] define_macros = [('NO_ATLAS_INFO', 1)] language = f77 lapack_opt_info: lapack_mkl_info: mkl_info: libraries mkl,vml,guide not found in /home/sanjey/lib libraries mkl,vml,guide not found in /usr/local/lib libraries mkl,vml,guide not found in /usr/lib NOT AVAILABLE NOT AVAILABLE atlas_threads_info: Setting PTATLAS=ATLAS libraries ptf77blas,ptcblas,atlas not found in /home/sanjey/lib libraries lapack_atlas not found in /home/sanjey/lib libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib libraries lapack_atlas not found in /usr/local/lib libraries ptf77blas,ptcblas,atlas not found in /usr/lib/sse2 libraries lapack_atlas not found in /usr/lib/sse2 libraries ptf77blas,ptcblas,atlas not found in /usr/lib libraries lapack_atlas not found in /usr/lib numpy.distutils.system_info.atlas_threads_info NOT AVAILABLE atlas_info: libraries f77blas,cblas,atlas not found in /home/sanjey/lib libraries lapack_atlas not found in /home/sanjey/lib libraries f77blas,cblas,atlas not found in /usr/local/lib libraries lapack_atlas not found in /usr/local/lib libraries f77blas,cblas,atlas not found in /usr/lib/sse2 libraries lapack_atlas not found in /usr/lib/sse2 libraries f77blas,cblas,atlas not found in /usr/lib libraries lapack_atlas not found in /usr/lib numpy.distutils.system_info.atlas_info NOT AVAILABLE lapack_info: libraries lapack not found in /home/sanjey/lib libraries lapack not found in /usr/local/lib FOUND: libraries = ['lapack'] library_dirs = ['/usr/lib'] language = f77 FOUND: libraries = ['lapack', 'blas'] library_dirs = ['/usr/lib'] define_macros = [('NO_ATLAS_INFO', 1)] language = f77 running build running config_cc unifing config_cc, config, build_clib, build_ext, build commands --compiler options running config_fc unifing config_fc, config, build_clib, build_ext, build commands --fcompiler options running build_src 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 library "npymath" sources customize GnuFCompiler Found executable /usr/bin/g77 gnu: no Fortran 90 compiler found gnu: no Fortran 90 compiler found customize GnuFCompiler gnu: no Fortran 90 compiler found gnu: no Fortran 90 compiler found customize GnuFCompiler using config C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c gcc -m32 -pthread _configtest.o -o _configtest success! removing: _configtest.c _configtest.o _configtest C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:1: warning: conflicting types for built-in function 'exp' gcc -m32 -pthread _configtest.o -o _configtest _configtest.o(.text+0x19): In function `main': /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' collect2: ld returned 1 exit status _configtest.o(.text+0x19): In function `main': /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' collect2: ld returned 1 exit status failure. removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:1: warning: conflicting types for built-in function 'exp' gcc -m32 -pthread _configtest.o -lm -o _configtest success! removing: _configtest.c _configtest.o _configtest creating build/src.linux-x86_64-2.4/numpy/core creating build/src.linux-x86_64-2.4/numpy/core/src creating build/src.linux-x86_64-2.4/numpy/core/src/npymath conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math.c conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/npymath/ieee754.c conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math_complex.c building extension "numpy.core._sort" sources Generating build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c success! removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c success! removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:5: warning: function declaration isn't a prototype success! removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:5: warning: function declaration isn't a prototype success! removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:5: warning: function declaration isn't a prototype success! removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:5: warning: function declaration isn't a prototype success! removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype removing: _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:5: warning: function declaration isn't a prototype success! removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype removing: _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:5: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:7: error: `SIZEOF_LONGDOUBLE' undeclared (first use in this function) _configtest.c:7: error: (Each undeclared identifier is reported only once _configtest.c:7: error: for each function it appears in.) _configtest.c:5: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:7: error: `SIZEOF_LONGDOUBLE' undeclared (first use in this function) _configtest.c:7: error: (Each undeclared identifier is reported only once _configtest.c:7: error: for each function it appears in.) failure. removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype removing: _configtest.c _configtest.o _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype removing: _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative _configtest.c:4: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:5: error: size of array `test_array' is negative C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype removing: _configtest.c _configtest.o _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:6: warning: function declaration isn't a prototype removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:6: warning: function declaration isn't a prototype removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:5: warning: function declaration isn't a prototype success! removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:6: warning: function declaration isn't a prototype removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:6: warning: function declaration isn't a prototype removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:5: warning: function declaration isn't a prototype success! removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:1: warning: conflicting types for built-in function 'exp' gcc -m32 -pthread _configtest.o -o _configtest _configtest.o(.text+0x19): In function `main': /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' collect2: ld returned 1 exit status _configtest.o(.text+0x19): In function `main': /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' collect2: ld returned 1 exit status failure. removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:1: warning: conflicting types for built-in function 'exp' gcc -m32 -pthread _configtest.o -lm -o _configtest success! removing: _configtest.c _configtest.o _configtest C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:1: warning: conflicting types for built-in function 'asin' _configtest.c:2: warning: conflicting types for built-in function 'cos' _configtest.c:3: warning: conflicting types for built-in function 'log' _configtest.c:4: warning: conflicting types for built-in function 'fabs' _configtest.c:5: warning: conflicting types for built-in function 'tanh' _configtest.c:6: warning: conflicting types for built-in function 'atan' _configtest.c:7: warning: conflicting types for built-in function 'acos' _configtest.c:8: warning: conflicting types for built-in function 'floor' _configtest.c:9: warning: conflicting types for built-in function 'fmod' _configtest.c:10: warning: conflicting types for built-in function 'sqrt' _configtest.c:11: warning: conflicting types for built-in function 'cosh' _configtest.c:12: warning: conflicting types for built-in function 'modf' _configtest.c:13: warning: conflicting types for built-in function 'sinh' _configtest.c:14: warning: conflicting types for built-in function 'frexp' _configtest.c:15: warning: conflicting types for built-in function 'exp' _configtest.c:16: warning: conflicting types for built-in function 'tan' _configtest.c:17: warning: conflicting types for built-in function 'ceil' _configtest.c:18: warning: conflicting types for built-in function 'log10' _configtest.c:19: warning: conflicting types for built-in function 'sin' _configtest.c:20: warning: conflicting types for built-in function 'ldexp' gcc -m32 -pthread _configtest.o -lm -o _configtest success! removing: _configtest.c _configtest.o _configtest C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:1: warning: conflicting types for built-in function 'expm1' _configtest.c:2: warning: conflicting types for built-in function 'log2' _configtest.c:3: warning: conflicting types for built-in function 'pow' _configtest.c:4: warning: conflicting types for built-in function 'rint' _configtest.c:5: warning: conflicting types for built-in function 'atanh' _configtest.c:6: warning: conflicting types for built-in function 'copysign' _configtest.c:7: warning: conflicting types for built-in function 'asinh' _configtest.c:8: warning: conflicting types for built-in function 'atan2' _configtest.c:9: warning: conflicting types for built-in function 'hypot' _configtest.c:10: warning: conflicting types for built-in function 'acosh' _configtest.c:11: warning: conflicting types for built-in function 'exp2' _configtest.c:12: warning: conflicting types for built-in function 'log1p' _configtest.c:13: warning: conflicting types for built-in function 'nextafter' _configtest.c:14: warning: conflicting types for built-in function 'trunc' gcc -m32 -pthread _configtest.o -lm -o _configtest success! removing: _configtest.c _configtest.o _configtest C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:1: warning: conflicting types for built-in function 'cosf' _configtest.c:2: warning: conflicting types for built-in function 'coshf' _configtest.c:3: warning: conflicting types for built-in function 'rintf' _configtest.c:4: warning: conflicting types for built-in function 'fabsf' _configtest.c:5: warning: conflicting types for built-in function 'floorf' _configtest.c:6: warning: conflicting types for built-in function 'nextafterf' _configtest.c:7: warning: conflicting types for built-in function 'tanhf' _configtest.c:8: warning: conflicting types for built-in function 'log10f' _configtest.c:9: warning: conflicting types for built-in function 'logf' _configtest.c:10: warning: conflicting types for built-in function 'sinhf' _configtest.c:11: warning: conflicting types for built-in function 'acosf' _configtest.c:12: warning: conflicting types for built-in function 'sqrtf' _configtest.c:13: warning: conflicting types for built-in function 'ldexpf' _configtest.c:14: warning: conflicting types for built-in function 'hypotf' _configtest.c:15: warning: conflicting types for built-in function 'log2f' _configtest.c:16: warning: conflicting types for built-in function 'exp2f' _configtest.c:17: warning: conflicting types for built-in function 'atanf' _configtest.c:18: warning: conflicting types for built-in function 'fmodf' _configtest.c:19: warning: conflicting types for built-in function 'atan2f' _configtest.c:20: warning: conflicting types for built-in function 'modff' _configtest.c:21: warning: conflicting types for built-in function 'ceilf' _configtest.c:22: warning: conflicting types for built-in function 'log1pf' _configtest.c:23: warning: conflicting types for built-in function 'asinf' _configtest.c:24: warning: conflicting types for built-in function 'copysignf' _configtest.c:25: warning: conflicting types for built-in function 'acoshf' _configtest.c:26: warning: conflicting types for built-in function 'sinf' _configtest.c:27: warning: conflicting types for built-in function 'tanf' _configtest.c:28: warning: conflicting types for built-in function 'atanhf' _configtest.c:29: warning: conflicting types for built-in function 'truncf' _configtest.c:30: warning: conflicting types for built-in function 'asinhf' _configtest.c:31: warning: conflicting types for built-in function 'frexpf' _configtest.c:32: warning: conflicting types for built-in function 'powf' _configtest.c:33: warning: conflicting types for built-in function 'expf' _configtest.c:34: warning: conflicting types for built-in function 'expm1f' gcc -m32 -pthread _configtest.o -lm -o _configtest success! removing: _configtest.c _configtest.o _configtest C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:1: warning: conflicting types for built-in function 'tanhl' _configtest.c:2: warning: conflicting types for built-in function 'log10l' _configtest.c:3: warning: conflicting types for built-in function 'nextafterl' _configtest.c:4: warning: conflicting types for built-in function 'coshl' _configtest.c:5: warning: conflicting types for built-in function 'cosl' _configtest.c:6: warning: conflicting types for built-in function 'floorl' _configtest.c:7: warning: conflicting types for built-in function 'rintl' _configtest.c:8: warning: conflicting types for built-in function 'fabsl' _configtest.c:9: warning: conflicting types for built-in function 'acosl' _configtest.c:10: warning: conflicting types for built-in function 'ldexpl' _configtest.c:11: warning: conflicting types for built-in function 'sqrtl' _configtest.c:12: warning: conflicting types for built-in function 'logl' _configtest.c:13: warning: conflicting types for built-in function 'expm1l' _configtest.c:14: warning: conflicting types for built-in function 'hypotl' _configtest.c:15: warning: conflicting types for built-in function 'log2l' _configtest.c:16: warning: conflicting types for built-in function 'copysignl' _configtest.c:17: warning: conflicting types for built-in function 'exp2l' _configtest.c:18: warning: conflicting types for built-in function 'atanl' _configtest.c:19: warning: conflicting types for built-in function 'frexpl' _configtest.c:20: warning: conflicting types for built-in function 'atan2l' _configtest.c:21: warning: conflicting types for built-in function 'sinhl' _configtest.c:22: warning: conflicting types for built-in function 'fmodl' _configtest.c:23: warning: conflicting types for built-in function 'log1pl' _configtest.c:24: warning: conflicting types for built-in function 'asinl' _configtest.c:25: warning: conflicting types for built-in function 'ceill' _configtest.c:26: warning: conflicting types for built-in function 'sinl' _configtest.c:27: warning: conflicting types for built-in function 'acoshl' _configtest.c:28: warning: conflicting types for built-in function 'atanhl' _configtest.c:29: warning: conflicting types for built-in function 'tanl' _configtest.c:30: warning: conflicting types for built-in function 'truncl' _configtest.c:31: warning: conflicting types for built-in function 'powl' _configtest.c:32: warning: conflicting types for built-in function 'expl' _configtest.c:33: warning: conflicting types for built-in function 'modfl' _configtest.c:34: warning: conflicting types for built-in function 'asinhl' gcc -m32 -pthread _configtest.o -lm -o _configtest success! removing: _configtest.c _configtest.o _configtest C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:6: warning: function declaration isn't a prototype success! removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:6: warning: function declaration isn't a prototype success! removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:6: warning: function declaration isn't a prototype success! removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:6: warning: function declaration isn't a prototype success! removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c success! removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:1: warning: conflicting types for built-in function 'cexp' _configtest.c:3: warning: conflicting types for built-in function 'ccos' _configtest.c:4: warning: conflicting types for built-in function 'cimag' _configtest.c:5: warning: conflicting types for built-in function 'cabs' _configtest.c:6: warning: conflicting types for built-in function 'cpow' _configtest.c:7: warning: conflicting types for built-in function 'csqrt' _configtest.c:8: warning: conflicting types for built-in function 'carg' _configtest.c:9: warning: conflicting types for built-in function 'creal' _configtest.c:10: warning: conflicting types for built-in function 'csin' gcc -m32 -pthread _configtest.o -lm -o _configtest success! removing: _configtest.c _configtest.o _configtest C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:1: warning: conflicting types for built-in function 'ccosf' _configtest.c:2: warning: conflicting types for built-in function 'cargf' _configtest.c:3: warning: conflicting types for built-in function 'csqrtf' _configtest.c:4: warning: conflicting types for built-in function 'cpowf' _configtest.c:5: warning: conflicting types for built-in function 'cexpf' _configtest.c:6: warning: conflicting types for built-in function 'crealf' _configtest.c:7: warning: conflicting types for built-in function 'csinf' _configtest.c:8: warning: conflicting types for built-in function 'cabsf' _configtest.c:10: warning: conflicting types for built-in function 'cimagf' gcc -m32 -pthread _configtest.o -lm -o _configtest success! removing: _configtest.c _configtest.o _configtest C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:1: warning: conflicting types for built-in function 'csqrtl' _configtest.c:2: warning: conflicting types for built-in function 'cargl' _configtest.c:3: warning: conflicting types for built-in function 'cexpl' _configtest.c:4: warning: conflicting types for built-in function 'ccosl' _configtest.c:5: warning: conflicting types for built-in function 'cpowl' _configtest.c:6: warning: conflicting types for built-in function 'cimagl' _configtest.c:7: warning: conflicting types for built-in function 'csinl' _configtest.c:8: warning: conflicting types for built-in function 'creall' _configtest.c:10: warning: conflicting types for built-in function 'cabsl' gcc -m32 -pthread _configtest.o -lm -o _configtest success! removing: _configtest.c _configtest.o _configtest C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c success! removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:5: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:7: error: `Py_UNICODE_WIDE' undeclared (first use in this function) _configtest.c:7: error: (Each undeclared identifier is reported only once _configtest.c:7: error: for each function it appears in.) _configtest.c:5: warning: function declaration isn't a prototype _configtest.c: In function `main': _configtest.c:7: error: `Py_UNICODE_WIDE' undeclared (first use in this function) _configtest.c:7: error: (Each undeclared identifier is reported only once _configtest.c:7: error: for each function it appears in.) failure. removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c removing: _configtest.c _configtest.o ('File:', 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h') #define HAVE_ENDIAN_H 1 #define SIZEOF_PY_INTPTR_T 4 #define SIZEOF_PY_LONG_LONG 8 #define MATHLIB m #define HAVE_SIN #define HAVE_COS #define HAVE_TAN #define HAVE_SINH #define HAVE_COSH #define HAVE_TANH #define HAVE_FABS #define HAVE_FLOOR #define HAVE_CEIL #define HAVE_SQRT #define HAVE_LOG10 #define HAVE_LOG #define HAVE_EXP #define HAVE_ASIN #define HAVE_ACOS #define HAVE_ATAN #define HAVE_FMOD #define HAVE_MODF #define HAVE_FREXP #define HAVE_LDEXP #define HAVE_EXPM1 #define HAVE_LOG1P #define HAVE_ACOSH #define HAVE_ASINH #define HAVE_ATANH #define HAVE_RINT #define HAVE_TRUNC #define HAVE_EXP2 #define HAVE_LOG2 #define HAVE_HYPOT #define HAVE_ATAN2 #define HAVE_POW #define HAVE_COPYSIGN #define HAVE_NEXTAFTER #define HAVE_SINF #define HAVE_COSF #define HAVE_TANF #define HAVE_SINHF #define HAVE_COSHF #define HAVE_TANHF #define HAVE_FABSF #define HAVE_FLOORF #define HAVE_CEILF #define HAVE_RINTF #define HAVE_TRUNCF #define HAVE_SQRTF #define HAVE_LOG10F #define HAVE_LOGF #define HAVE_LOG1PF #define HAVE_EXPF #define HAVE_EXPM1F #define HAVE_ASINF #define HAVE_ACOSF #define HAVE_ATANF #define HAVE_ASINHF #define HAVE_ACOSHF #define HAVE_ATANHF #define HAVE_HYPOTF #define HAVE_ATAN2F #define HAVE_POWF #define HAVE_FMODF #define HAVE_MODFF #define HAVE_FREXPF #define HAVE_LDEXPF #define HAVE_EXP2F #define HAVE_LOG2F #define HAVE_COPYSIGNF #define HAVE_NEXTAFTERF #define HAVE_SINL #define HAVE_COSL #define HAVE_TANL #define HAVE_SINHL #define HAVE_COSHL #define HAVE_TANHL #define HAVE_FABSL #define HAVE_FLOORL #define HAVE_CEILL #define HAVE_RINTL #define HAVE_TRUNCL #define HAVE_SQRTL #define HAVE_LOG10L #define HAVE_LOGL #define HAVE_LOG1PL #define HAVE_EXPL #define HAVE_EXPM1L #define HAVE_ASINL #define HAVE_ACOSL #define HAVE_ATANL #define HAVE_ASINHL #define HAVE_ACOSHL #define HAVE_ATANHL #define HAVE_HYPOTL #define HAVE_ATAN2L #define HAVE_POWL #define HAVE_FMODL #define HAVE_MODFL #define HAVE_FREXPL #define HAVE_LDEXPL #define HAVE_EXP2L #define HAVE_LOG2L #define HAVE_COPYSIGNL #define HAVE_NEXTAFTERL #define HAVE_DECL_ISNAN #define HAVE_DECL_ISINF #define HAVE_DECL_SIGNBIT #define HAVE_DECL_ISFINITE #define HAVE_COMPLEX_H #define HAVE_CREAL #define HAVE_CIMAG #define HAVE_CABS #define HAVE_CARG #define HAVE_CEXP #define HAVE_CSQRT #define HAVE_CLOG #define HAVE_CCOS #define HAVE_CSIN #define HAVE_CPOW #define HAVE_CREALF #define HAVE_CIMAGF #define HAVE_CABSF #define HAVE_CARGF #define HAVE_CEXPF #define HAVE_CSQRTF #define HAVE_CLOGF #define HAVE_CCOSF #define HAVE_CSINF #define HAVE_CPOWF #define HAVE_CREALL #define HAVE_CIMAGL #define HAVE_CABSL #define HAVE_CARGL #define HAVE_CEXPL #define HAVE_CSQRTL #define HAVE_CLOGL #define HAVE_CCOSL #define HAVE_CSINL #define HAVE_CPOWL #define HAVE_LDOUBLE_INTEL_EXTENDED_12_BYTES_LE 1 #ifndef __cplusplus /* #undef inline */ #endif #ifndef _NPY_NPY_CONFIG_H_ #error config.h should never be included directly, include npy_config.h instead #endif EOF adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' to sources. Generating build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:1: warning: conflicting types for built-in function 'exp' gcc -m32 -pthread _configtest.o -o _configtest _configtest.o(.text+0x19): In function `main': /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' collect2: ld returned 1 exit status _configtest.o(.text+0x19): In function `main': /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' collect2: ld returned 1 exit status failure. removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:1: warning: conflicting types for built-in function 'exp' gcc -m32 -pthread _configtest.o -lm -o _configtest success! removing: _configtest.c _configtest.o _configtest C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:5: warning: function declaration isn't a prototype success! removing: _configtest.c _configtest.o C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c _configtest.c:4: warning: function declaration isn't a prototype _configtest.c:5:18: warning: extra tokens at end of #ifndef directive _configtest.c: In function `main': _configtest.c:4: warning: control reaches end of non-void function success! removing: _configtest.c _configtest.o File: build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h #define NPY_HAVE_ENDIAN_H 1 #define NPY_SIZEOF_SHORT SIZEOF_SHORT #define NPY_SIZEOF_INT SIZEOF_INT #define NPY_SIZEOF_LONG SIZEOF_LONG #define NPY_SIZEOF_FLOAT 4 #define NPY_SIZEOF_COMPLEX_FLOAT 8 #define NPY_SIZEOF_DOUBLE 8 #define NPY_SIZEOF_COMPLEX_DOUBLE 16 #define NPY_SIZEOF_LONGDOUBLE 12 #define NPY_SIZEOF_COMPLEX_LONGDOUBLE 24 #define NPY_SIZEOF_PY_INTPTR_T 4 #define NPY_SIZEOF_PY_LONG_LONG 8 #define NPY_SIZEOF_LONGLONG 8 #define NPY_NO_SMP 1 #define NPY_HAVE_DECL_ISNAN #define NPY_HAVE_DECL_ISINF #define NPY_HAVE_DECL_SIGNBIT #define NPY_HAVE_DECL_ISFINITE #define NPY_USE_C99_COMPLEX #define NPY_HAVE_COMPLEX_DOUBLE 1 #define NPY_HAVE_COMPLEX_FLOAT 1 #define NPY_HAVE_COMPLEX_LONG_DOUBLE 1 #define NPY_USE_C99_FORMATS 1 #define NPY_VISIBILITY_HIDDEN __attribute__((visibility("hidden"))) #define NPY_ABI_VERSION 0x01000009 #define NPY_API_VERSION 0x00000004 #ifndef __STDC_FORMAT_MACROS #define __STDC_FORMAT_MACROS 1 #endif EOF adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' to sources. executing numpy/core/code_generators/generate_numpy_api.py adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__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/include/numpy/config.h', 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h'] building extension "numpy.core.multiarray" sources non-existing path in 'numpy/core': 'build/src.linux-x86_64-2.4/numpy/core/src/multiarray' creating build/src.linux-x86_64-2.4/numpy/core/src/multiarray conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/multiarray/scalartypes.c conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/multiarray/arraytypes.c adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' to sources. adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' to sources. executing numpy/core/code_generators/generate_numpy_api.py adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h' to sources. numpy.core - nothing done with h_files = ['build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h', 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h'] building extension "numpy.core.umath" sources adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' to sources. adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' to sources. executing numpy/core/code_generators/generate_ufunc_api.py adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__ufunc_api.h' to sources. non-existing path in 'numpy/core': 'build/src.linux-x86_64-2.4/numpy/core/src/umath' creating build/src.linux-x86_64-2.4/numpy/core/src/umath conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/umath/loops.c conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/umath/umathmodule.c conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/umath/funcs.inc adding 'build/src.linux-x86_64-2.4/numpy/core/src/umath' to include_dirs. numpy.core - nothing done with h_files = ['build/src.linux-x86_64-2.4/numpy/core/src/umath/funcs.inc', 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h', 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__ufunc_api.h'] building extension "numpy.core.scalarmath" sources adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' to sources. adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' to sources. executing numpy/core/code_generators/generate_numpy_api.py adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h' to sources. executing numpy/core/code_generators/generate_ufunc_api.py adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__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/include/numpy/config.h', 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h', 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__ufunc_api.h'] building extension "numpy.core._dotblas" sources building extension "numpy.core.umath_tests" sources conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/umath/umath_tests.c building extension "numpy.core.multiarray_tests" sources conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/multiarray/multiarray_tests.c building extension "numpy.lib._compiled_base" sources building extension "numpy.numarray._capi" sources building extension "numpy.fft.fftpack_lite" sources building extension "numpy.linalg.lapack_lite" sources creating build/src.linux-x86_64-2.4/numpy/linalg adding 'numpy/linalg/lapack_litemodule.c' to sources. adding 'numpy/linalg/python_xerbla.c' to sources. building extension "numpy.random.mtrand" sources creating build/src.linux-x86_64-2.4/numpy/random C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -c' gcc: _configtest.c gcc -m32 -pthread _configtest.o -o _configtest _configtest failure. removing: _configtest.c _configtest.o _configtest building data_files sources build_src: building npy-pkg config files running build_py creating build/lib.linux-x86_64-2.4 creating build/lib.linux-x86_64-2.4/numpy copying numpy/version.py -> build/lib.linux-x86_64-2.4/numpy copying numpy/matlib.py -> build/lib.linux-x86_64-2.4/numpy copying numpy/ctypeslib.py -> build/lib.linux-x86_64-2.4/numpy copying numpy/setupscons.py -> build/lib.linux-x86_64-2.4/numpy copying numpy/__init__.py -> build/lib.linux-x86_64-2.4/numpy copying numpy/setup.py -> build/lib.linux-x86_64-2.4/numpy copying numpy/dual.py -> build/lib.linux-x86_64-2.4/numpy copying numpy/_import_tools.py -> build/lib.linux-x86_64-2.4/numpy copying numpy/add_newdocs.py -> build/lib.linux-x86_64-2.4/numpy copying build/src.linux-x86_64-2.4/numpy/__config__.py -> build/lib.linux-x86_64-2.4/numpy creating build/lib.linux-x86_64-2.4/numpy/distutils copying numpy/distutils/from_template.py -> build/lib.linux-x86_64-2.4/numpy/distutils copying numpy/distutils/npy_pkg_config.py -> build/lib.linux-x86_64-2.4/numpy/distutils copying numpy/distutils/compat.py -> build/lib.linux-x86_64-2.4/numpy/distutils copying numpy/distutils/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/distutils copying numpy/distutils/__init__.py -> build/lib.linux-x86_64-2.4/numpy/distutils copying numpy/distutils/lib2def.py -> build/lib.linux-x86_64-2.4/numpy/distutils copying numpy/distutils/interactive.py -> build/lib.linux-x86_64-2.4/numpy/distutils copying numpy/distutils/info.py -> build/lib.linux-x86_64-2.4/numpy/distutils copying numpy/distutils/environment.py -> build/lib.linux-x86_64-2.4/numpy/distutils copying numpy/distutils/setup.py -> build/lib.linux-x86_64-2.4/numpy/distutils copying numpy/distutils/cpuinfo.py -> build/lib.linux-x86_64-2.4/numpy/distutils copying numpy/distutils/extension.py -> build/lib.linux-x86_64-2.4/numpy/distutils copying numpy/distutils/core.py -> build/lib.linux-x86_64-2.4/numpy/distutils copying numpy/distutils/intelccompiler.py -> build/lib.linux-x86_64-2.4/numpy/distutils copying numpy/distutils/log.py -> build/lib.linux-x86_64-2.4/numpy/distutils copying numpy/distutils/__version__.py -> build/lib.linux-x86_64-2.4/numpy/distutils copying numpy/distutils/unixccompiler.py -> build/lib.linux-x86_64-2.4/numpy/distutils copying numpy/distutils/misc_util.py -> build/lib.linux-x86_64-2.4/numpy/distutils copying numpy/distutils/line_endings.py -> build/lib.linux-x86_64-2.4/numpy/distutils copying numpy/distutils/exec_command.py -> build/lib.linux-x86_64-2.4/numpy/distutils copying numpy/distutils/conv_template.py -> build/lib.linux-x86_64-2.4/numpy/distutils copying numpy/distutils/ccompiler.py -> build/lib.linux-x86_64-2.4/numpy/distutils copying numpy/distutils/mingw32ccompiler.py -> build/lib.linux-x86_64-2.4/numpy/distutils copying numpy/distutils/system_info.py -> build/lib.linux-x86_64-2.4/numpy/distutils copying numpy/distutils/numpy_distribution.py -> build/lib.linux-x86_64-2.4/numpy/distutils copying build/src.linux-x86_64-2.4/numpy/distutils/__config__.py -> build/lib.linux-x86_64-2.4/numpy/distutils creating build/lib.linux-x86_64-2.4/numpy/distutils/command copying numpy/distutils/command/install.py -> build/lib.linux-x86_64-2.4/numpy/distutils/command copying numpy/distutils/command/egg_info.py -> build/lib.linux-x86_64-2.4/numpy/distutils/command copying numpy/distutils/command/install_clib.py -> build/lib.linux-x86_64-2.4/numpy/distutils/command copying numpy/distutils/command/bdist_rpm.py -> build/lib.linux-x86_64-2.4/numpy/distutils/command copying numpy/distutils/command/develop.py -> build/lib.linux-x86_64-2.4/numpy/distutils/command copying numpy/distutils/command/install_data.py -> build/lib.linux-x86_64-2.4/numpy/distutils/command copying numpy/distutils/command/__init__.py -> build/lib.linux-x86_64-2.4/numpy/distutils/command copying numpy/distutils/command/build_py.py -> build/lib.linux-x86_64-2.4/numpy/distutils/command copying numpy/distutils/command/build_src.py -> build/lib.linux-x86_64-2.4/numpy/distutils/command copying numpy/distutils/command/build_clib.py -> build/lib.linux-x86_64-2.4/numpy/distutils/command copying numpy/distutils/command/build_ext.py -> build/lib.linux-x86_64-2.4/numpy/distutils/command copying numpy/distutils/command/autodist.py -> build/lib.linux-x86_64-2.4/numpy/distutils/command copying numpy/distutils/command/install_headers.py -> build/lib.linux-x86_64-2.4/numpy/distutils/command copying numpy/distutils/command/config.py -> build/lib.linux-x86_64-2.4/numpy/distutils/command copying numpy/distutils/command/config_compiler.py -> build/lib.linux-x86_64-2.4/numpy/distutils/command copying numpy/distutils/command/build.py -> build/lib.linux-x86_64-2.4/numpy/distutils/command copying numpy/distutils/command/build_scripts.py -> build/lib.linux-x86_64-2.4/numpy/distutils/command copying numpy/distutils/command/sdist.py -> build/lib.linux-x86_64-2.4/numpy/distutils/command copying numpy/distutils/command/scons.py -> build/lib.linux-x86_64-2.4/numpy/distutils/command creating build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler copying numpy/distutils/fcompiler/none.py -> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler copying numpy/distutils/fcompiler/hpux.py -> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler copying numpy/distutils/fcompiler/compaq.py -> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler copying numpy/distutils/fcompiler/absoft.py -> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler copying numpy/distutils/fcompiler/vast.py -> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler copying numpy/distutils/fcompiler/nag.py -> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler copying numpy/distutils/fcompiler/__init__.py -> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler copying numpy/distutils/fcompiler/sun.py -> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler copying numpy/distutils/fcompiler/mips.py -> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler copying numpy/distutils/fcompiler/intel.py -> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler copying numpy/distutils/fcompiler/gnu.py -> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler copying numpy/distutils/fcompiler/g95.py -> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler copying numpy/distutils/fcompiler/pg.py -> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler copying numpy/distutils/fcompiler/ibm.py -> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler copying numpy/distutils/fcompiler/lahey.py -> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler creating build/lib.linux-x86_64-2.4/numpy/testing copying numpy/testing/nulltester.py -> build/lib.linux-x86_64-2.4/numpy/testing copying numpy/testing/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/testing copying numpy/testing/__init__.py -> build/lib.linux-x86_64-2.4/numpy/testing copying numpy/testing/setup.py -> build/lib.linux-x86_64-2.4/numpy/testing copying numpy/testing/decorators.py -> build/lib.linux-x86_64-2.4/numpy/testing copying numpy/testing/utils.py -> build/lib.linux-x86_64-2.4/numpy/testing copying numpy/testing/noseclasses.py -> build/lib.linux-x86_64-2.4/numpy/testing copying numpy/testing/numpytest.py -> build/lib.linux-x86_64-2.4/numpy/testing copying numpy/testing/nosetester.py -> build/lib.linux-x86_64-2.4/numpy/testing creating build/lib.linux-x86_64-2.4/numpy/f2py copying numpy/f2py/auxfuncs.py -> build/lib.linux-x86_64-2.4/numpy/f2py copying numpy/f2py/common_rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py copying numpy/f2py/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/f2py copying numpy/f2py/__init__.py -> build/lib.linux-x86_64-2.4/numpy/f2py copying numpy/f2py/cb_rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py copying numpy/f2py/info.py -> build/lib.linux-x86_64-2.4/numpy/f2py copying numpy/f2py/setup.py -> build/lib.linux-x86_64-2.4/numpy/f2py copying numpy/f2py/f2py2e.py -> build/lib.linux-x86_64-2.4/numpy/f2py copying numpy/f2py/cfuncs.py -> build/lib.linux-x86_64-2.4/numpy/f2py copying numpy/f2py/crackfortran.py -> build/lib.linux-x86_64-2.4/numpy/f2py copying numpy/f2py/use_rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py copying numpy/f2py/diagnose.py -> build/lib.linux-x86_64-2.4/numpy/f2py copying numpy/f2py/f2py_testing.py -> build/lib.linux-x86_64-2.4/numpy/f2py copying numpy/f2py/__version__.py -> build/lib.linux-x86_64-2.4/numpy/f2py copying numpy/f2py/capi_maps.py -> build/lib.linux-x86_64-2.4/numpy/f2py copying numpy/f2py/func2subr.py -> build/lib.linux-x86_64-2.4/numpy/f2py copying numpy/f2py/f90mod_rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py copying numpy/f2py/rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py creating build/lib.linux-x86_64-2.4/numpy/core copying numpy/core/defchararray.py -> build/lib.linux-x86_64-2.4/numpy/core copying numpy/core/numeric.py -> build/lib.linux-x86_64-2.4/numpy/core copying numpy/core/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/core copying numpy/core/__init__.py -> build/lib.linux-x86_64-2.4/numpy/core copying numpy/core/info.py -> build/lib.linux-x86_64-2.4/numpy/core copying numpy/core/function_base.py -> build/lib.linux-x86_64-2.4/numpy/core copying numpy/core/getlimits.py -> build/lib.linux-x86_64-2.4/numpy/core copying numpy/core/setup.py -> build/lib.linux-x86_64-2.4/numpy/core copying numpy/core/fromnumeric.py -> build/lib.linux-x86_64-2.4/numpy/core copying numpy/core/shape_base.py -> build/lib.linux-x86_64-2.4/numpy/core copying numpy/core/setup_common.py -> build/lib.linux-x86_64-2.4/numpy/core copying numpy/core/records.py -> build/lib.linux-x86_64-2.4/numpy/core copying numpy/core/memmap.py -> build/lib.linux-x86_64-2.4/numpy/core copying numpy/core/arrayprint.py -> build/lib.linux-x86_64-2.4/numpy/core copying numpy/core/numerictypes.py -> build/lib.linux-x86_64-2.4/numpy/core copying numpy/core/machar.py -> build/lib.linux-x86_64-2.4/numpy/core copying numpy/core/_mx_datetime_parser.py -> build/lib.linux-x86_64-2.4/numpy/core copying numpy/core/scons_support.py -> build/lib.linux-x86_64-2.4/numpy/core copying numpy/core/_internal.py -> build/lib.linux-x86_64-2.4/numpy/core copying numpy/core/code_generators/generate_numpy_api.py -> build/lib.linux-x86_64-2.4/numpy/core creating build/lib.linux-x86_64-2.4/numpy/lib copying numpy/lib/_datasource.py -> build/lib.linux-x86_64-2.4/numpy/lib copying numpy/lib/arraysetops.py -> build/lib.linux-x86_64-2.4/numpy/lib copying numpy/lib/index_tricks.py -> build/lib.linux-x86_64-2.4/numpy/lib copying numpy/lib/format.py -> build/lib.linux-x86_64-2.4/numpy/lib copying numpy/lib/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/lib copying numpy/lib/__init__.py -> build/lib.linux-x86_64-2.4/numpy/lib copying numpy/lib/info.py -> build/lib.linux-x86_64-2.4/numpy/lib copying numpy/lib/function_base.py -> build/lib.linux-x86_64-2.4/numpy/lib copying numpy/lib/setup.py -> build/lib.linux-x86_64-2.4/numpy/lib copying numpy/lib/arrayterator.py -> build/lib.linux-x86_64-2.4/numpy/lib copying numpy/lib/ufunclike.py -> build/lib.linux-x86_64-2.4/numpy/lib copying numpy/lib/shape_base.py -> build/lib.linux-x86_64-2.4/numpy/lib copying numpy/lib/user_array.py -> build/lib.linux-x86_64-2.4/numpy/lib copying numpy/lib/type_check.py -> build/lib.linux-x86_64-2.4/numpy/lib copying numpy/lib/stride_tricks.py -> build/lib.linux-x86_64-2.4/numpy/lib copying numpy/lib/recfunctions.py -> build/lib.linux-x86_64-2.4/numpy/lib copying numpy/lib/npyio.py -> build/lib.linux-x86_64-2.4/numpy/lib copying numpy/lib/_iotools.py -> build/lib.linux-x86_64-2.4/numpy/lib copying numpy/lib/utils.py -> build/lib.linux-x86_64-2.4/numpy/lib copying numpy/lib/financial.py -> build/lib.linux-x86_64-2.4/numpy/lib copying numpy/lib/twodim_base.py -> build/lib.linux-x86_64-2.4/numpy/lib copying numpy/lib/polynomial.py -> build/lib.linux-x86_64-2.4/numpy/lib copying numpy/lib/scimath.py -> build/lib.linux-x86_64-2.4/numpy/lib creating build/lib.linux-x86_64-2.4/numpy/oldnumeric copying numpy/oldnumeric/functions.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric copying numpy/oldnumeric/alter_code1.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric copying numpy/oldnumeric/misc.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric copying numpy/oldnumeric/compat.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric copying numpy/oldnumeric/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric copying numpy/oldnumeric/__init__.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric copying numpy/oldnumeric/linear_algebra.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric copying numpy/oldnumeric/setup.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric copying numpy/oldnumeric/random_array.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric copying numpy/oldnumeric/user_array.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric copying numpy/oldnumeric/alter_code2.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric copying numpy/oldnumeric/fft.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric copying numpy/oldnumeric/matrix.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric copying numpy/oldnumeric/fix_default_axis.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric copying numpy/oldnumeric/rng_stats.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric copying numpy/oldnumeric/mlab.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric copying numpy/oldnumeric/ma.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric copying numpy/oldnumeric/ufuncs.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric copying numpy/oldnumeric/rng.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric copying numpy/oldnumeric/array_printer.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric copying numpy/oldnumeric/typeconv.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric copying numpy/oldnumeric/precision.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric copying numpy/oldnumeric/arrayfns.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric creating build/lib.linux-x86_64-2.4/numpy/numarray copying numpy/numarray/nd_image.py -> build/lib.linux-x86_64-2.4/numpy/numarray copying numpy/numarray/util.py -> build/lib.linux-x86_64-2.4/numpy/numarray copying numpy/numarray/convolve.py -> build/lib.linux-x86_64-2.4/numpy/numarray copying numpy/numarray/functions.py -> build/lib.linux-x86_64-2.4/numpy/numarray copying numpy/numarray/alter_code1.py -> build/lib.linux-x86_64-2.4/numpy/numarray copying numpy/numarray/compat.py -> build/lib.linux-x86_64-2.4/numpy/numarray copying numpy/numarray/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/numarray copying numpy/numarray/__init__.py -> build/lib.linux-x86_64-2.4/numpy/numarray copying numpy/numarray/linear_algebra.py -> build/lib.linux-x86_64-2.4/numpy/numarray copying numpy/numarray/setup.py -> build/lib.linux-x86_64-2.4/numpy/numarray copying numpy/numarray/random_array.py -> build/lib.linux-x86_64-2.4/numpy/numarray copying numpy/numarray/alter_code2.py -> build/lib.linux-x86_64-2.4/numpy/numarray copying numpy/numarray/fft.py -> build/lib.linux-x86_64-2.4/numpy/numarray copying numpy/numarray/matrix.py -> build/lib.linux-x86_64-2.4/numpy/numarray copying numpy/numarray/numerictypes.py -> build/lib.linux-x86_64-2.4/numpy/numarray copying numpy/numarray/image.py -> build/lib.linux-x86_64-2.4/numpy/numarray copying numpy/numarray/mlab.py -> build/lib.linux-x86_64-2.4/numpy/numarray copying numpy/numarray/ma.py -> build/lib.linux-x86_64-2.4/numpy/numarray copying numpy/numarray/session.py -> build/lib.linux-x86_64-2.4/numpy/numarray copying numpy/numarray/ufuncs.py -> build/lib.linux-x86_64-2.4/numpy/numarray creating build/lib.linux-x86_64-2.4/numpy/fft copying numpy/fft/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/fft copying numpy/fft/__init__.py -> build/lib.linux-x86_64-2.4/numpy/fft copying numpy/fft/info.py -> build/lib.linux-x86_64-2.4/numpy/fft copying numpy/fft/setup.py -> build/lib.linux-x86_64-2.4/numpy/fft copying numpy/fft/fftpack.py -> build/lib.linux-x86_64-2.4/numpy/fft copying numpy/fft/helper.py -> build/lib.linux-x86_64-2.4/numpy/fft creating build/lib.linux-x86_64-2.4/numpy/linalg copying numpy/linalg/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/linalg copying numpy/linalg/__init__.py -> build/lib.linux-x86_64-2.4/numpy/linalg copying numpy/linalg/info.py -> build/lib.linux-x86_64-2.4/numpy/linalg copying numpy/linalg/setup.py -> build/lib.linux-x86_64-2.4/numpy/linalg copying numpy/linalg/linalg.py -> build/lib.linux-x86_64-2.4/numpy/linalg creating build/lib.linux-x86_64-2.4/numpy/random copying numpy/random/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/random copying numpy/random/__init__.py -> build/lib.linux-x86_64-2.4/numpy/random copying numpy/random/info.py -> build/lib.linux-x86_64-2.4/numpy/random copying numpy/random/setup.py -> build/lib.linux-x86_64-2.4/numpy/random creating build/lib.linux-x86_64-2.4/numpy/ma copying numpy/ma/version.py -> build/lib.linux-x86_64-2.4/numpy/ma copying numpy/ma/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/ma copying numpy/ma/__init__.py -> build/lib.linux-x86_64-2.4/numpy/ma copying numpy/ma/setup.py -> build/lib.linux-x86_64-2.4/numpy/ma copying numpy/ma/bench.py -> build/lib.linux-x86_64-2.4/numpy/ma copying numpy/ma/core.py -> build/lib.linux-x86_64-2.4/numpy/ma copying numpy/ma/testutils.py -> build/lib.linux-x86_64-2.4/numpy/ma copying numpy/ma/timer_comparison.py -> build/lib.linux-x86_64-2.4/numpy/ma copying numpy/ma/extras.py -> build/lib.linux-x86_64-2.4/numpy/ma copying numpy/ma/mrecords.py -> build/lib.linux-x86_64-2.4/numpy/ma creating build/lib.linux-x86_64-2.4/numpy/matrixlib copying numpy/matrixlib/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/matrixlib copying numpy/matrixlib/__init__.py -> build/lib.linux-x86_64-2.4/numpy/matrixlib copying numpy/matrixlib/setup.py -> build/lib.linux-x86_64-2.4/numpy/matrixlib copying numpy/matrixlib/defmatrix.py -> build/lib.linux-x86_64-2.4/numpy/matrixlib creating build/lib.linux-x86_64-2.4/numpy/compat copying numpy/compat/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/compat copying numpy/compat/__init__.py -> build/lib.linux-x86_64-2.4/numpy/compat copying numpy/compat/setup.py -> build/lib.linux-x86_64-2.4/numpy/compat copying numpy/compat/py3k.py -> build/lib.linux-x86_64-2.4/numpy/compat copying numpy/compat/_inspect.py -> build/lib.linux-x86_64-2.4/numpy/compat creating build/lib.linux-x86_64-2.4/numpy/polynomial copying numpy/polynomial/__init__.py -> build/lib.linux-x86_64-2.4/numpy/polynomial copying numpy/polynomial/setup.py -> build/lib.linux-x86_64-2.4/numpy/polynomial copying numpy/polynomial/chebyshev.py -> build/lib.linux-x86_64-2.4/numpy/polynomial copying numpy/polynomial/polynomial.py -> build/lib.linux-x86_64-2.4/numpy/polynomial copying numpy/polynomial/polyutils.py -> build/lib.linux-x86_64-2.4/numpy/polynomial copying numpy/polynomial/polytemplate.py -> build/lib.linux-x86_64-2.4/numpy/polynomial creating build/lib.linux-x86_64-2.4/numpy/doc copying numpy/doc/byteswapping.py -> build/lib.linux-x86_64-2.4/numpy/doc copying numpy/doc/glossary.py -> build/lib.linux-x86_64-2.4/numpy/doc copying numpy/doc/indexing.py -> build/lib.linux-x86_64-2.4/numpy/doc copying numpy/doc/misc.py -> build/lib.linux-x86_64-2.4/numpy/doc copying numpy/doc/internals.py -> build/lib.linux-x86_64-2.4/numpy/doc copying numpy/doc/__init__.py -> build/lib.linux-x86_64-2.4/numpy/doc copying numpy/doc/creation.py -> build/lib.linux-x86_64-2.4/numpy/doc copying numpy/doc/jargon.py -> build/lib.linux-x86_64-2.4/numpy/doc copying numpy/doc/basics.py -> build/lib.linux-x86_64-2.4/numpy/doc copying numpy/doc/io.py -> build/lib.linux-x86_64-2.4/numpy/doc copying numpy/doc/methods_vs_functions.py -> build/lib.linux-x86_64-2.4/numpy/doc copying numpy/doc/broadcasting.py -> build/lib.linux-x86_64-2.4/numpy/doc copying numpy/doc/constants.py -> build/lib.linux-x86_64-2.4/numpy/doc copying numpy/doc/howtofind.py -> build/lib.linux-x86_64-2.4/numpy/doc copying numpy/doc/ufuncs.py -> build/lib.linux-x86_64-2.4/numpy/doc copying numpy/doc/subclassing.py -> build/lib.linux-x86_64-2.4/numpy/doc copying numpy/doc/structured_arrays.py -> build/lib.linux-x86_64-2.4/numpy/doc copying numpy/doc/performance.py -> build/lib.linux-x86_64-2.4/numpy/doc running build_clib customize UnixCCompiler customize UnixCCompiler using build_clib building 'npymath' library compiling C sources C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC creating build/temp.linux-x86_64-2.4 creating build/temp.linux-x86_64-2.4/build creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4 creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/npymath compile options: '-Inumpy/core/include -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' gcc: build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math.c In file included from numpy/core/src/private/npy_config.h:4, from numpy/core/src/npymath/npy_math_private.h:24, from numpy/core/src/npymath/npy_math.c.src:56: build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: warning: "HAVE_HYPOT" redefined In file included from /home/sanjey/include/python2.4/Python.h:8, from numpy/core/src/npymath/npy_math_private.h:21, from numpy/core/src/npymath/npy_math.c.src:56: /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the location of the previous definition gcc: build/src.linux-x86_64-2.4/numpy/core/src/npymath/ieee754.c In file included from numpy/core/src/private/npy_config.h:4, from numpy/core/src/npymath/npy_math_common.h:8, from numpy/core/src/npymath/ieee754.c.src:7: build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: warning: "HAVE_HYPOT" redefined In file included from /home/sanjey/include/python2.4/Python.h:8, from numpy/core/src/npymath/npy_math_common.h:4, from numpy/core/src/npymath/ieee754.c.src:7: /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the location of the previous definition gcc: build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math_complex.c In file included from numpy/core/src/private/npy_config.h:4, from numpy/core/src/npymath/npy_math_common.h:8, from numpy/core/src/npymath/npy_math_complex.c.src:31: build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: warning: "HAVE_HYPOT" redefined In file included from /home/sanjey/include/python2.4/Python.h:8, from numpy/core/src/npymath/npy_math_common.h:4, from numpy/core/src/npymath/npy_math_complex.c.src:31: /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the location of the previous definition ar: adding 3 object files to build/temp.linux-x86_64-2.4/libnpymath.a running build_ext customize UnixCCompiler customize UnixCCompiler using build_ext customize GnuFCompiler gnu: no Fortran 90 compiler found gnu: no Fortran 90 compiler found customize GnuFCompiler gnu: no Fortran 90 compiler found gnu: no Fortran 90 compiler found customize GnuFCompiler using build_ext building 'numpy.core._sort' extension compiling C sources C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/include -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' gcc: build/src.linux-x86_64-2.4/numpy/core/src/_sortmodule.c In file included from numpy/core/src/private/npy_config.h:4, from numpy/core/src/_sortmodule.c.src:34: build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: warning: "HAVE_HYPOT" redefined In file included from /home/sanjey/include/python2.4/Python.h:8, from numpy/core/src/_sortmodule.c.src:30: /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the location of the previous definition gcc -m32 -pthread -shared build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/_sortmodule.o -Lbuild/temp.linux-x86_64-2.4 -lm -o build/lib.linux-x86_64-2.4/numpy/core/_sort.so building 'numpy.core.multiarray' extension compiling C sources C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC creating build/temp.linux-x86_64-2.4/numpy creating build/temp.linux-x86_64-2.4/numpy/core creating build/temp.linux-x86_64-2.4/numpy/core/src creating build/temp.linux-x86_64-2.4/numpy/core/src/multiarray compile options: '-Inumpy/core/include -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' gcc: numpy/core/src/multiarray/multiarraymodule_onefile.c In file included from numpy/core/src/private/npy_config.h:4, from numpy/core/src/multiarray/common.c:8, from numpy/core/src/multiarray/multiarraymodule_onefile.c:8: build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: warning: "HAVE_HYPOT" redefined In file included from /home/sanjey/include/python2.4/Python.h:8, from numpy/core/src/multiarray/common.c:2, from numpy/core/src/multiarray/multiarraymodule_onefile.c:8: /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the location of the previous definition In file included from numpy/core/src/multiarray/multiarraymodule_onefile.c:26: numpy/core/src/multiarray/methods.c: In function `NpyArg_ParseKeywords': numpy/core/src/multiarray/methods.c:41: warning: passing arg 3 of `PyArg_VaParseTupleAndKeywords' discards qualifiers from pointer target type numpy/core/src/multiarray/flagsobject.c: In function `arrayflags_richcompare': numpy/core/src/multiarray/flagsobject.c:568: warning: 'cmp' might be used uninitialized in this function numpy/core/src/multiarray/multiarraymodule_onefile.c: At top level: numpy/core/include/numpy/npy_3kcompat.h:331: warning: 'simple_capsule_dtor' defined but not used numpy/core/src/multiarray/buffer.c:777: warning: '_descriptor_from_pep3118_format' defined but not used numpy/core/src/multiarray/arraytypes.c.src:93: warning: '_SEQUENCE_MESSAGE' defined but not used numpy/core/src/multiarray/mapping.c:75: warning: '_array_ass_item' defined but not used gcc -m32 -pthread -shared build/temp.linux-x86_64-2.4/numpy/core/src/multiarray/multiarraymodule_onefile.o -Lbuild/temp.linux-x86_64-2.4 -lnpymath -lm -o build/lib.linux-x86_64-2.4/numpy/core/multiarray.so building 'numpy.core.umath' extension compiling C sources C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC creating build/temp.linux-x86_64-2.4/numpy/core/src/umath compile options: '-Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -Inumpy/core/include -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' gcc: numpy/core/src/umath/umathmodule_onefile.c In file included from numpy/core/src/private/npy_config.h:4, from numpy/core/src/umath/loops.c.src:7, from numpy/core/src/umath/umathmodule_onefile.c:1: build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: warning: "HAVE_HYPOT" redefined In file included from /home/sanjey/include/python2.4/Python.h:8, from numpy/core/src/umath/loops.c.src:5, from numpy/core/src/umath/umathmodule_onefile.c:1: /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the location of the previous definition numpy/core/include/numpy/npy_3kcompat.h:331: warning: 'simple_capsule_dtor' defined but not used numpy/core/src/umath/loops.c.src:1258: warning: 'CLONGDOUBLE_logical_and' defined but not used numpy/core/src/umath/loops.c.src:1258: warning: 'CLONGDOUBLE_logical_or' defined but not used numpy/core/src/umath/loops.c.src:1271: warning: 'CLONGDOUBLE_logical_xor' defined but not used numpy/core/src/umath/loops.c.src:1285: warning: 'CLONGDOUBLE_logical_not' defined but not used numpy/core/src/umath/loops.c.src:1342: warning: 'CLONGDOUBLE_ones_like' defined but not used numpy/core/src/umath/loops.c.src:1399: warning: 'CLONGDOUBLE_maximum' defined but not used numpy/core/src/umath/loops.c.src:1399: warning: 'CLONGDOUBLE_minimum' defined but not used numpy/core/src/umath/loops.c.src:1423: warning: 'CLONGDOUBLE_fmax' defined but not used numpy/core/src/umath/loops.c.src:1423: warning: 'CLONGDOUBLE_fmin' defined but not used gcc -m32 -pthread -shared build/temp.linux-x86_64-2.4/numpy/core/src/umath/umathmodule_onefile.o -Lbuild/temp.linux-x86_64-2.4 -lnpymath -lm -o build/lib.linux-x86_64-2.4/numpy/core/umath.so building 'numpy.core.scalarmath' extension compiling C sources C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/include -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' gcc: build/src.linux-x86_64-2.4/numpy/core/src/scalarmathmodule.c numpy/core/include/numpy/npy_3kcompat.h:331: warning: 'simple_capsule_dtor' defined but not used gcc -m32 -pthread -shared build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/scalarmathmodule.o -Lbuild/temp.linux-x86_64-2.4 -lm -o build/lib.linux-x86_64-2.4/numpy/core/scalarmath.so building 'numpy.core.umath_tests' extension compiling C sources C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/umath compile options: '-Inumpy/core/include -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' gcc: build/src.linux-x86_64-2.4/numpy/core/src/umath/umath_tests.c In file included from numpy/core/src/private/npy_config.h:4, from numpy/core/src/umath/umath_tests.c.src:14: build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: warning: "HAVE_HYPOT" redefined In file included from /home/sanjey/include/python2.4/Python.h:8, from numpy/core/src/umath/umath_tests.c.src:8: /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the location of the previous definition numpy/core/include/numpy/npy_3kcompat.h:331: warning: 'simple_capsule_dtor' defined but not used gcc -m32 -pthread -shared build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/umath/umath_tests.o -Lbuild/temp.linux-x86_64-2.4 -o build/lib.linux-x86_64-2.4/numpy/core/umath_tests.so building 'numpy.core.multiarray_tests' extension compiling C sources C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/multiarray compile options: '-Inumpy/core/include -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' gcc: build/src.linux-x86_64-2.4/numpy/core/src/multiarray/multiarray_tests.c numpy/core/include/numpy/npy_3kcompat.h:331: warning: 'simple_capsule_dtor' defined but not used gcc -m32 -pthread -shared build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/multiarray/multiarray_tests.o -Lbuild/temp.linux-x86_64-2.4 -o build/lib.linux-x86_64-2.4/numpy/core/multiarray_tests.so building 'numpy.lib._compiled_base' extension compiling C sources C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC creating build/temp.linux-x86_64-2.4/numpy/lib creating build/temp.linux-x86_64-2.4/numpy/lib/src compile options: '-Inumpy/core/include -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' gcc: numpy/lib/src/_compiled_base.c In file included from numpy/core/src/private/npy_config.h:4, from numpy/lib/src/_compiled_base.c:4: build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: warning: "HAVE_HYPOT" redefined In file included from /home/sanjey/include/python2.4/Python.h:8, from numpy/lib/src/_compiled_base.c:1: /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the location of the previous definition gcc -m32 -pthread -shared build/temp.linux-x86_64-2.4/numpy/lib/src/_compiled_base.o -Lbuild/temp.linux-x86_64-2.4 -o build/lib.linux-x86_64-2.4/numpy/lib/_compiled_base.so building 'numpy.numarray._capi' extension compiling C sources C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC creating build/temp.linux-x86_64-2.4/numpy/numarray compile options: '-Inumpy/core/include -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' gcc: numpy/numarray/_capi.c numpy/core/include/numpy/npy_3kcompat.h:331: warning: 'simple_capsule_dtor' defined but not used gcc -m32 -pthread -shared build/temp.linux-x86_64-2.4/numpy/numarray/_capi.o -Lbuild/temp.linux-x86_64-2.4 -o build/lib.linux-x86_64-2.4/numpy/numarray/_capi.so building 'numpy.fft.fftpack_lite' extension compiling C sources C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC creating build/temp.linux-x86_64-2.4/numpy/fft compile options: '-Inumpy/core/include -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' gcc: numpy/fft/fftpack_litemodule.c gcc: numpy/fft/fftpack.c gcc -m32 -pthread -shared build/temp.linux-x86_64-2.4/numpy/fft/fftpack_litemodule.o build/temp.linux-x86_64-2.4/numpy/fft/fftpack.o -Lbuild/temp.linux-x86_64-2.4 -o build/lib.linux-x86_64-2.4/numpy/fft/fftpack_lite.so building 'numpy.linalg.lapack_lite' extension compiling C sources C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC creating build/temp.linux-x86_64-2.4/numpy/linalg compile options: '-DNO_ATLAS_INFO=1 -Inumpy/core/include -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/home/sanjey/include/python2.4 -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' gcc: numpy/linalg/lapack_litemodule.c gcc: numpy/linalg/python_xerbla.c /usr/bin/g77 -g -Wall -g -Wall -shared build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o -L/usr/lib -Lbuild/temp.linux-x86_64-2.4 -llapack -lblas -lg2c -o build/lib.linux-x86_64-2.4/numpy/linalg/lapack_lite.so /usr/bin/ld: skipping incompatible /usr/lib/liblapack.so when searching for -llapack /usr/bin/ld: skipping incompatible /usr/lib/liblapack.a when searching for -llapack /usr/bin/ld: skipping incompatible /usr/lib/libblas.so when searching for -lblas /usr/bin/ld: skipping incompatible /usr/lib/libblas.a when searching for -lblas /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm /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 /usr/bin/ld: warning: i386 architecture of input file `build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o' is incompatible with i386:x86-64 output /usr/bin/ld: warning: i386 architecture of input file `build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o' is incompatible with i386:x86-64 output build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xae): In function `lapack_lite_dgeev': numpy/linalg/lapack_litemodule.c:155: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfe):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x143):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a3):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1f4):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x272):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31c):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ae):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x60e):numpy/linalg/lapack_litemodule.c:171: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6aa): In function `lapack_lite_dsyevd': numpy/linalg/lapack_litemodule.c:241: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6f4):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x739):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x797):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x7ef):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x869):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x8ff):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xa7c):numpy/linalg/lapack_litemodule.c:254: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb34): In function `lapack_lite_zheevd': numpy/linalg/lapack_litemodule.c:327: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb7e):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xbc3):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc23):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc74):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xce9):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xd85):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xe77):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfb9):numpy/linalg/lapack_litemodule.c:341: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1087): In function `lapack_lite_dgelsd': numpy/linalg/lapack_litemodule.c:365: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x10d7):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x111c):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x117d):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x11cf):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1252):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x12e8):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x13d7):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1534):numpy/linalg/lapack_litemodule.c:380: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15af): In function `lapack_lite_dgesv': numpy/linalg/lapack_litemodule.c:398: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15f9):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x163e):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1692):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x16e7):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x175e):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x189a):numpy/linalg/lapack_litemodule.c:407: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1967): In function `lapack_lite_dgesdd': numpy/linalg/lapack_litemodule.c:430: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19b7):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19fc):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a5d):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1aaf):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1b32):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1bc8):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d15):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d76):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1efb):numpy/linalg/lapack_litemodule.c:472: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x202b): In function `lapack_lite_dgetrf': numpy/linalg/lapack_litemodule.c:488: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2063):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20ae):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20fe):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2155):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2235):numpy/linalg/lapack_litemodule.c:496: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22b4): In function `lapack_lite_dpotrf': numpy/linalg/lapack_litemodule.c:510: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22e9):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x232d):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x238f):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x240a):numpy/linalg/lapack_litemodule.c:516: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24af): In function `lapack_lite_dgeqrf': numpy/linalg/lapack_litemodule.c:529: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24f9):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x253e):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2598):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x25ef):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2669):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x27a7):numpy/linalg/lapack_litemodule.c:540: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2839): In function `lapack_lite_dorgqr': numpy/linalg/lapack_litemodule.c:555: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2883):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x28c8):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2927):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x297f):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x29f9):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2afa):numpy/linalg/lapack_litemodule.c:562: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2bbb): In function `lapack_lite_zgeev': numpy/linalg/lapack_litemodule.c:585: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c0b):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c50):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2cb0):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d04):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d82):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2e2c):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2f6b):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2fb9):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x311b):numpy/linalg/lapack_litemodule.c:601: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31f4): In function `lapack_lite_zgelsd': numpy/linalg/lapack_litemodule.c:626: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3244):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3289):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x32ef):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3340):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x33c8):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3471):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35b1):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35ff):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x376f):numpy/linalg/lapack_litemodule.c:641: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x37ef): In function `lapack_lite_zgesv': numpy/linalg/lapack_litemodule.c:658: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3839):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x387e):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x38d2):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3927):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x399e):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3ada):numpy/linalg/lapack_litemodule.c:667: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bae): In function `lapack_lite_zgesdd': numpy/linalg/lapack_litemodule.c:691: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bfe):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3c43):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cab):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cff):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3d82):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3e2c):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3f70):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3fbe):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4195):numpy/linalg/lapack_litemodule.c:708: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x41ab):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x422b): In function `lapack_lite_zgetrf': numpy/linalg/lapack_litemodule.c:724: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4263):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42ae):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42fe):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4355):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4435):numpy/linalg/lapack_litemodule.c:732: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44b4): In function `lapack_lite_zpotrf': numpy/linalg/lapack_litemodule.c:746: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44e9):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x452d):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x458f):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460a):numpy/linalg/lapack_litemodule.c:751: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46af): In function `lapack_lite_zgeqrf': numpy/linalg/lapack_litemodule.c:764: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46f9):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x473e):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4798):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x47ef):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4869):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x49a7):numpy/linalg/lapack_litemodule.c:774: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a39): In function `lapack_lite_zungqr': numpy/linalg/lapack_litemodule.c:787: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a83):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ac8):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b27):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b7f):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4bf9):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4cfa):numpy/linalg/lapack_litemodule.c:797: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d58): In function `initlapack_lite': numpy/linalg/lapack_litemodule.c:858: undefined reference to `Py_InitModule4' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d71): In function `initlapack_lite': build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1190: undefined reference to `PyImport_ImportModule' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d8d):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1197: undefined reference to `PyObject_GetAttrString' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4da6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1212: undefined reference to `PyCObject_Type' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4db5):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: undefined reference to `PyExc_RuntimeError' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dc9):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: undefined reference to `PyErr_SetString' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dd7): In function `initlapack_lite': numpy/linalg/lapack_litemodule.c:865: undefined reference to `PyErr_Print' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ddd):numpy/linalg/lapack_litemodule.c:865: undefined reference to `PyExc_ImportError' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4df1):numpy/linalg/lapack_litemodule.c:865: undefined reference to `PyErr_SetString' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e18): In function `initlapack_lite': build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1194: undefined reference to `PyExc_ImportError' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e26):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: undefined reference to `PyErr_SetString' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e46):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1217: undefined reference to `PyCObject_AsVoidPtr' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e88):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: undefined reference to `PyExc_RuntimeError' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e96):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ea1):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: undefined reference to `PyExc_RuntimeError' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4eb6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1200: undefined reference to `PyExc_AttributeError' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f24):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: undefined reference to `PyExc_RuntimeError' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f2e):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f46): In function `initlapack_lite': numpy/linalg/lapack_litemodule.c:866: undefined reference to `PyModule_GetDict' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f66):numpy/linalg/lapack_litemodule.c:867: undefined reference to `PyErr_NewException' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f82):numpy/linalg/lapack_litemodule.c:868: undefined reference to `PyDict_SetItemString' build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x70): In function `xerbla_': numpy/linalg/python_xerbla.c:35: undefined reference to `PyExc_ValueError' build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x7e):numpy/linalg/python_xerbla.c:35: undefined reference to `PyErr_SetString' collect2: ld returned 1 exit status /usr/bin/ld: skipping incompatible /usr/lib/liblapack.so when searching for -llapack /usr/bin/ld: skipping incompatible /usr/lib/liblapack.a when searching for -llapack /usr/bin/ld: skipping incompatible /usr/lib/libblas.so when searching for -lblas /usr/bin/ld: skipping incompatible /usr/lib/libblas.a when searching for -lblas /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm /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 /usr/bin/ld: warning: i386 architecture of input file `build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o' is incompatible with i386:x86-64 output /usr/bin/ld: warning: i386 architecture of input file `build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o' is incompatible with i386:x86-64 output build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xae): In function `lapack_lite_dgeev': numpy/linalg/lapack_litemodule.c:155: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfe):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x143):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a3):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1f4):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x272):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31c):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ae):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x60e):numpy/linalg/lapack_litemodule.c:171: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6aa): In function `lapack_lite_dsyevd': numpy/linalg/lapack_litemodule.c:241: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6f4):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x739):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x797):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x7ef):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x869):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x8ff):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xa7c):numpy/linalg/lapack_litemodule.c:254: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb34): In function `lapack_lite_zheevd': numpy/linalg/lapack_litemodule.c:327: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb7e):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xbc3):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc23):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc74):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xce9):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xd85):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xe77):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfb9):numpy/linalg/lapack_litemodule.c:341: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1087): In function `lapack_lite_dgelsd': numpy/linalg/lapack_litemodule.c:365: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x10d7):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x111c):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x117d):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x11cf):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1252):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x12e8):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x13d7):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1534):numpy/linalg/lapack_litemodule.c:380: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15af): In function `lapack_lite_dgesv': numpy/linalg/lapack_litemodule.c:398: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15f9):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x163e):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1692):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x16e7):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x175e):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x189a):numpy/linalg/lapack_litemodule.c:407: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1967): In function `lapack_lite_dgesdd': numpy/linalg/lapack_litemodule.c:430: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19b7):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19fc):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a5d):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1aaf):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1b32):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1bc8):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d15):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d76):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1efb):numpy/linalg/lapack_litemodule.c:472: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x202b): In function `lapack_lite_dgetrf': numpy/linalg/lapack_litemodule.c:488: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2063):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20ae):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20fe):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2155):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2235):numpy/linalg/lapack_litemodule.c:496: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22b4): In function `lapack_lite_dpotrf': numpy/linalg/lapack_litemodule.c:510: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22e9):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x232d):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x238f):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x240a):numpy/linalg/lapack_litemodule.c:516: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24af): In function `lapack_lite_dgeqrf': numpy/linalg/lapack_litemodule.c:529: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24f9):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x253e):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2598):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x25ef):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2669):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x27a7):numpy/linalg/lapack_litemodule.c:540: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2839): In function `lapack_lite_dorgqr': numpy/linalg/lapack_litemodule.c:555: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2883):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x28c8):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2927):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x297f):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x29f9):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2afa):numpy/linalg/lapack_litemodule.c:562: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2bbb): In function `lapack_lite_zgeev': numpy/linalg/lapack_litemodule.c:585: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c0b):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c50):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2cb0):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d04):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d82):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2e2c):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2f6b):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2fb9):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x311b):numpy/linalg/lapack_litemodule.c:601: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31f4): In function `lapack_lite_zgelsd': numpy/linalg/lapack_litemodule.c:626: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3244):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3289):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x32ef):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3340):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x33c8):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3471):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35b1):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35ff):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x376f):numpy/linalg/lapack_litemodule.c:641: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x37ef): In function `lapack_lite_zgesv': numpy/linalg/lapack_litemodule.c:658: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3839):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x387e):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x38d2):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3927):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x399e):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3ada):numpy/linalg/lapack_litemodule.c:667: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bae): In function `lapack_lite_zgesdd': numpy/linalg/lapack_litemodule.c:691: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bfe):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3c43):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cab):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cff):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3d82):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3e2c):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3f70):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3fbe):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4195):numpy/linalg/lapack_litemodule.c:708: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x41ab):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x422b): In function `lapack_lite_zgetrf': numpy/linalg/lapack_litemodule.c:724: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4263):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42ae):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42fe):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4355):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4435):numpy/linalg/lapack_litemodule.c:732: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44b4): In function `lapack_lite_zpotrf': numpy/linalg/lapack_litemodule.c:746: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44e9):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x452d):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x458f):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460a):numpy/linalg/lapack_litemodule.c:751: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46af): In function `lapack_lite_zgeqrf': numpy/linalg/lapack_litemodule.c:764: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46f9):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x473e):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4798):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x47ef):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4869):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x49a7):numpy/linalg/lapack_litemodule.c:774: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a39): In function `lapack_lite_zungqr': numpy/linalg/lapack_litemodule.c:787: undefined reference to `PyArg_ParseTuple' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a83):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ac8):numpy/linalg/lapack_litemodule.c:114: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b27):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b7f):numpy/linalg/lapack_litemodule.c:120: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4bf9):numpy/linalg/lapack_litemodule.c:103: undefined reference to `PyType_IsSubtype' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4cfa):numpy/linalg/lapack_litemodule.c:797: undefined reference to `Py_BuildValue' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d58): In function `initlapack_lite': numpy/linalg/lapack_litemodule.c:858: undefined reference to `Py_InitModule4' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d71): In function `initlapack_lite': build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1190: undefined reference to `PyImport_ImportModule' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d8d):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1197: undefined reference to `PyObject_GetAttrString' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4da6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1212: undefined reference to `PyCObject_Type' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4db5):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: undefined reference to `PyExc_RuntimeError' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dc9):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: undefined reference to `PyErr_SetString' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dd7): In function `initlapack_lite': numpy/linalg/lapack_litemodule.c:865: undefined reference to `PyErr_Print' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ddd):numpy/linalg/lapack_litemodule.c:865: undefined reference to `PyExc_ImportError' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4df1):numpy/linalg/lapack_litemodule.c:865: undefined reference to `PyErr_SetString' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e18): In function `initlapack_lite': build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1194: undefined reference to `PyExc_ImportError' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e26):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: undefined reference to `PyErr_SetString' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e46):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1217: undefined reference to `PyCObject_AsVoidPtr' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e88):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: undefined reference to `PyExc_RuntimeError' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e96):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ea1):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: undefined reference to `PyExc_RuntimeError' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4eb6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1200: undefined reference to `PyExc_AttributeError' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f24):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: undefined reference to `PyExc_RuntimeError' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f2e):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: undefined reference to `PyErr_Format' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f46): In function `initlapack_lite': numpy/linalg/lapack_litemodule.c:866: undefined reference to `PyModule_GetDict' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f66):numpy/linalg/lapack_litemodule.c:867: undefined reference to `PyErr_NewException' build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f82):numpy/linalg/lapack_litemodule.c:868: undefined reference to `PyDict_SetItemString' build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x70): In function `xerbla_': numpy/linalg/python_xerbla.c:35: undefined reference to `PyExc_ValueError' build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x7e):numpy/linalg/python_xerbla.c:35: undefined reference to `PyErr_SetString' collect2: ld returned 1 exit status From bsouthey at gmail.com Fri Oct 15 11:23:04 2010 From: bsouthey at gmail.com (Bruce Southey) Date: Fri, 15 Oct 2010 10:23:04 -0500 Subject: [Numpy-discussion] Please help a newbie install NUMPY In-Reply-To: References: Message-ID: <4CB871D8.4080503@gmail.com> On 10/15/2010 09:31 AM, P Sanjey wrote: > Please help-I am a newbie and I wanted to try installing numpy on a > local /home/usr directory but got the following errors-I am not sure > where to even begin fixing this problem and any help would be useful > I just did the standard > python setup.py build and got the following (loooooong) error message > > > ********************************************************** > non-existing path in 'numpy/distutils': 'site.cfg' > F2PY Version 1 > blas_opt_info: > blas_mkl_info: > libraries mkl,vml,guide not found in /home/sanjey/lib > libraries mkl,vml,guide not found in /usr/local/lib > libraries mkl,vml,guide not found in /usr/lib > NOT AVAILABLE > > atlas_blas_threads_info: > Setting PTATLAS=ATLAS > libraries ptf77blas,ptcblas,atlas not found in /home/sanjey/lib > libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib > libraries ptf77blas,ptcblas,atlas not found in /usr/lib/sse2 > libraries ptf77blas,ptcblas,atlas not found in /usr/lib > NOT AVAILABLE > > atlas_blas_info: > libraries f77blas,cblas,atlas not found in /home/sanjey/lib > libraries f77blas,cblas,atlas not found in /usr/local/lib > libraries f77blas,cblas,atlas not found in /usr/lib/sse2 > libraries f77blas,cblas,atlas not found in /usr/lib > NOT AVAILABLE > > blas_info: > libraries blas not found in /home/sanjey/lib > libraries blas not found in /usr/local/lib > FOUND: > libraries = ['blas'] > library_dirs = ['/usr/lib'] > language = f77 > > FOUND: > libraries = ['blas'] > library_dirs = ['/usr/lib'] > define_macros = [('NO_ATLAS_INFO', 1)] > language = f77 > > lapack_opt_info: > lapack_mkl_info: > mkl_info: > libraries mkl,vml,guide not found in /home/sanjey/lib > libraries mkl,vml,guide not found in /usr/local/lib > libraries mkl,vml,guide not found in /usr/lib > NOT AVAILABLE > > NOT AVAILABLE > > atlas_threads_info: > Setting PTATLAS=ATLAS > libraries ptf77blas,ptcblas,atlas not found in /home/sanjey/lib > libraries lapack_atlas not found in /home/sanjey/lib > libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib > libraries lapack_atlas not found in /usr/local/lib > libraries ptf77blas,ptcblas,atlas not found in /usr/lib/sse2 > libraries lapack_atlas not found in /usr/lib/sse2 > libraries ptf77blas,ptcblas,atlas not found in /usr/lib > libraries lapack_atlas not found in /usr/lib > numpy.distutils.system_info.atlas_threads_info > NOT AVAILABLE > > atlas_info: > libraries f77blas,cblas,atlas not found in /home/sanjey/lib > libraries lapack_atlas not found in /home/sanjey/lib > libraries f77blas,cblas,atlas not found in /usr/local/lib > libraries lapack_atlas not found in /usr/local/lib > libraries f77blas,cblas,atlas not found in /usr/lib/sse2 > libraries lapack_atlas not found in /usr/lib/sse2 > libraries f77blas,cblas,atlas not found in /usr/lib > libraries lapack_atlas not found in /usr/lib > numpy.distutils.system_info.atlas_info > NOT AVAILABLE > > lapack_info: > libraries lapack not found in /home/sanjey/lib > libraries lapack not found in /usr/local/lib > FOUND: > libraries = ['lapack'] > library_dirs = ['/usr/lib'] > language = f77 > > FOUND: > libraries = ['lapack', 'blas'] > library_dirs = ['/usr/lib'] > define_macros = [('NO_ATLAS_INFO', 1)] > language = f77 > > running build > running config_cc > unifing config_cc, config, build_clib, build_ext, build commands > --compiler options > running config_fc > unifing config_fc, config, build_clib, build_ext, build commands > --fcompiler options > running build_src > 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 library "npymath" sources > customize GnuFCompiler > Found executable /usr/bin/g77 > gnu: no Fortran 90 compiler found > gnu: no Fortran 90 compiler found > customize GnuFCompiler > gnu: no Fortran 90 compiler found > gnu: no Fortran 90 compiler found > customize GnuFCompiler using config > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > gcc -m32 -pthread _configtest.o -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'exp' > gcc -m32 -pthread _configtest.o -o _configtest > _configtest.o(.text+0x19): In function `main': > /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' > collect2: ld returned 1 exit status > _configtest.o(.text+0x19): In function `main': > /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' > collect2: ld returned 1 exit status > failure. > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'exp' > gcc -m32 -pthread _configtest.o -lm -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > creating build/src.linux-x86_64-2.4/numpy/core > creating build/src.linux-x86_64-2.4/numpy/core/src > creating build/src.linux-x86_64-2.4/numpy/core/src/npymath > conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math.c > conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/npymath/ieee754.c > conv_template:> > build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math_complex.c > building extension "numpy.core._sort" sources > Generating build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:5: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:5: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:5: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:5: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o _configtest.c _configtest.o > _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c > _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:5: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o _configtest.c _configtest.o > _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c > _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o > _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:5: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:7: error: `SIZEOF_LONGDOUBLE' undeclared (first use in > this function) > _configtest.c:7: error: (Each undeclared identifier is reported only once > _configtest.c:7: error: for each function it appears in.) > _configtest.c:5: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:7: error: `SIZEOF_LONGDOUBLE' undeclared (first use in > this function) > _configtest.c:7: error: (Each undeclared identifier is reported only once > _configtest.c:7: error: for each function it appears in.) > failure. > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o _configtest.c _configtest.o > _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c > _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o > _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c > _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:6: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:6: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:5: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:6: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:6: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:5: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'exp' > gcc -m32 -pthread _configtest.o -o _configtest > _configtest.o(.text+0x19): In function `main': > /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' > collect2: ld returned 1 exit status > _configtest.o(.text+0x19): In function `main': > /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' > collect2: ld returned 1 exit status > failure. > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'exp' > gcc -m32 -pthread _configtest.o -lm -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'asin' > _configtest.c:2: warning: conflicting types for built-in function 'cos' > _configtest.c:3: warning: conflicting types for built-in function 'log' > _configtest.c:4: warning: conflicting types for built-in function 'fabs' > _configtest.c:5: warning: conflicting types for built-in function 'tanh' > _configtest.c:6: warning: conflicting types for built-in function 'atan' > _configtest.c:7: warning: conflicting types for built-in function 'acos' > _configtest.c:8: warning: conflicting types for built-in function 'floor' > _configtest.c:9: warning: conflicting types for built-in function 'fmod' > _configtest.c:10: warning: conflicting types for built-in function 'sqrt' > _configtest.c:11: warning: conflicting types for built-in function 'cosh' > _configtest.c:12: warning: conflicting types for built-in function 'modf' > _configtest.c:13: warning: conflicting types for built-in function 'sinh' > _configtest.c:14: warning: conflicting types for built-in function 'frexp' > _configtest.c:15: warning: conflicting types for built-in function 'exp' > _configtest.c:16: warning: conflicting types for built-in function 'tan' > _configtest.c:17: warning: conflicting types for built-in function 'ceil' > _configtest.c:18: warning: conflicting types for built-in function 'log10' > _configtest.c:19: warning: conflicting types for built-in function 'sin' > _configtest.c:20: warning: conflicting types for built-in function 'ldexp' > gcc -m32 -pthread _configtest.o -lm -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'expm1' > _configtest.c:2: warning: conflicting types for built-in function 'log2' > _configtest.c:3: warning: conflicting types for built-in function 'pow' > _configtest.c:4: warning: conflicting types for built-in function 'rint' > _configtest.c:5: warning: conflicting types for built-in function 'atanh' > _configtest.c:6: warning: conflicting types for built-in function 'copysign' > _configtest.c:7: warning: conflicting types for built-in function 'asinh' > _configtest.c:8: warning: conflicting types for built-in function 'atan2' > _configtest.c:9: warning: conflicting types for built-in function 'hypot' > _configtest.c:10: warning: conflicting types for built-in function 'acosh' > _configtest.c:11: warning: conflicting types for built-in function 'exp2' > _configtest.c:12: warning: conflicting types for built-in function 'log1p' > _configtest.c:13: warning: conflicting types for built-in function 'nextafter' > _configtest.c:14: warning: conflicting types for built-in function 'trunc' > gcc -m32 -pthread _configtest.o -lm -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'cosf' > _configtest.c:2: warning: conflicting types for built-in function 'coshf' > _configtest.c:3: warning: conflicting types for built-in function 'rintf' > _configtest.c:4: warning: conflicting types for built-in function 'fabsf' > _configtest.c:5: warning: conflicting types for built-in function 'floorf' > _configtest.c:6: warning: conflicting types for built-in function 'nextafterf' > _configtest.c:7: warning: conflicting types for built-in function 'tanhf' > _configtest.c:8: warning: conflicting types for built-in function 'log10f' > _configtest.c:9: warning: conflicting types for built-in function 'logf' > _configtest.c:10: warning: conflicting types for built-in function 'sinhf' > _configtest.c:11: warning: conflicting types for built-in function 'acosf' > _configtest.c:12: warning: conflicting types for built-in function 'sqrtf' > _configtest.c:13: warning: conflicting types for built-in function 'ldexpf' > _configtest.c:14: warning: conflicting types for built-in function 'hypotf' > _configtest.c:15: warning: conflicting types for built-in function 'log2f' > _configtest.c:16: warning: conflicting types for built-in function 'exp2f' > _configtest.c:17: warning: conflicting types for built-in function 'atanf' > _configtest.c:18: warning: conflicting types for built-in function 'fmodf' > _configtest.c:19: warning: conflicting types for built-in function 'atan2f' > _configtest.c:20: warning: conflicting types for built-in function 'modff' > _configtest.c:21: warning: conflicting types for built-in function 'ceilf' > _configtest.c:22: warning: conflicting types for built-in function 'log1pf' > _configtest.c:23: warning: conflicting types for built-in function 'asinf' > _configtest.c:24: warning: conflicting types for built-in function 'copysignf' > _configtest.c:25: warning: conflicting types for built-in function 'acoshf' > _configtest.c:26: warning: conflicting types for built-in function 'sinf' > _configtest.c:27: warning: conflicting types for built-in function 'tanf' > _configtest.c:28: warning: conflicting types for built-in function 'atanhf' > _configtest.c:29: warning: conflicting types for built-in function 'truncf' > _configtest.c:30: warning: conflicting types for built-in function 'asinhf' > _configtest.c:31: warning: conflicting types for built-in function 'frexpf' > _configtest.c:32: warning: conflicting types for built-in function 'powf' > _configtest.c:33: warning: conflicting types for built-in function 'expf' > _configtest.c:34: warning: conflicting types for built-in function 'expm1f' > gcc -m32 -pthread _configtest.o -lm -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'tanhl' > _configtest.c:2: warning: conflicting types for built-in function 'log10l' > _configtest.c:3: warning: conflicting types for built-in function 'nextafterl' > _configtest.c:4: warning: conflicting types for built-in function 'coshl' > _configtest.c:5: warning: conflicting types for built-in function 'cosl' > _configtest.c:6: warning: conflicting types for built-in function 'floorl' > _configtest.c:7: warning: conflicting types for built-in function 'rintl' > _configtest.c:8: warning: conflicting types for built-in function 'fabsl' > _configtest.c:9: warning: conflicting types for built-in function 'acosl' > _configtest.c:10: warning: conflicting types for built-in function 'ldexpl' > _configtest.c:11: warning: conflicting types for built-in function 'sqrtl' > _configtest.c:12: warning: conflicting types for built-in function 'logl' > _configtest.c:13: warning: conflicting types for built-in function 'expm1l' > _configtest.c:14: warning: conflicting types for built-in function 'hypotl' > _configtest.c:15: warning: conflicting types for built-in function 'log2l' > _configtest.c:16: warning: conflicting types for built-in function 'copysignl' > _configtest.c:17: warning: conflicting types for built-in function 'exp2l' > _configtest.c:18: warning: conflicting types for built-in function 'atanl' > _configtest.c:19: warning: conflicting types for built-in function 'frexpl' > _configtest.c:20: warning: conflicting types for built-in function 'atan2l' > _configtest.c:21: warning: conflicting types for built-in function 'sinhl' > _configtest.c:22: warning: conflicting types for built-in function 'fmodl' > _configtest.c:23: warning: conflicting types for built-in function 'log1pl' > _configtest.c:24: warning: conflicting types for built-in function 'asinl' > _configtest.c:25: warning: conflicting types for built-in function 'ceill' > _configtest.c:26: warning: conflicting types for built-in function 'sinl' > _configtest.c:27: warning: conflicting types for built-in function 'acoshl' > _configtest.c:28: warning: conflicting types for built-in function 'atanhl' > _configtest.c:29: warning: conflicting types for built-in function 'tanl' > _configtest.c:30: warning: conflicting types for built-in function 'truncl' > _configtest.c:31: warning: conflicting types for built-in function 'powl' > _configtest.c:32: warning: conflicting types for built-in function 'expl' > _configtest.c:33: warning: conflicting types for built-in function 'modfl' > _configtest.c:34: warning: conflicting types for built-in function 'asinhl' > gcc -m32 -pthread _configtest.o -lm -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:6: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:6: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:6: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:6: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'cexp' > _configtest.c:3: warning: conflicting types for built-in function 'ccos' > _configtest.c:4: warning: conflicting types for built-in function 'cimag' > _configtest.c:5: warning: conflicting types for built-in function 'cabs' > _configtest.c:6: warning: conflicting types for built-in function 'cpow' > _configtest.c:7: warning: conflicting types for built-in function 'csqrt' > _configtest.c:8: warning: conflicting types for built-in function 'carg' > _configtest.c:9: warning: conflicting types for built-in function 'creal' > _configtest.c:10: warning: conflicting types for built-in function 'csin' > gcc -m32 -pthread _configtest.o -lm -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'ccosf' > _configtest.c:2: warning: conflicting types for built-in function 'cargf' > _configtest.c:3: warning: conflicting types for built-in function 'csqrtf' > _configtest.c:4: warning: conflicting types for built-in function 'cpowf' > _configtest.c:5: warning: conflicting types for built-in function 'cexpf' > _configtest.c:6: warning: conflicting types for built-in function 'crealf' > _configtest.c:7: warning: conflicting types for built-in function 'csinf' > _configtest.c:8: warning: conflicting types for built-in function 'cabsf' > _configtest.c:10: warning: conflicting types for built-in function 'cimagf' > gcc -m32 -pthread _configtest.o -lm -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'csqrtl' > _configtest.c:2: warning: conflicting types for built-in function 'cargl' > _configtest.c:3: warning: conflicting types for built-in function 'cexpl' > _configtest.c:4: warning: conflicting types for built-in function 'ccosl' > _configtest.c:5: warning: conflicting types for built-in function 'cpowl' > _configtest.c:6: warning: conflicting types for built-in function 'cimagl' > _configtest.c:7: warning: conflicting types for built-in function 'csinl' > _configtest.c:8: warning: conflicting types for built-in function 'creall' > _configtest.c:10: warning: conflicting types for built-in function 'cabsl' > gcc -m32 -pthread _configtest.o -lm -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:5: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:7: error: `Py_UNICODE_WIDE' undeclared (first use in > this function) > _configtest.c:7: error: (Each undeclared identifier is reported only once > _configtest.c:7: error: for each function it appears in.) > _configtest.c:5: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:7: error: `Py_UNICODE_WIDE' undeclared (first use in > this function) > _configtest.c:7: error: (Each undeclared identifier is reported only once > _configtest.c:7: error: for each function it appears in.) > failure. > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > removing: _configtest.c _configtest.o > ('File:', 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h') > #define HAVE_ENDIAN_H 1 > #define SIZEOF_PY_INTPTR_T 4 > #define SIZEOF_PY_LONG_LONG 8 > #define MATHLIB m > #define HAVE_SIN > #define HAVE_COS > #define HAVE_TAN > #define HAVE_SINH > #define HAVE_COSH > #define HAVE_TANH > #define HAVE_FABS > #define HAVE_FLOOR > #define HAVE_CEIL > #define HAVE_SQRT > #define HAVE_LOG10 > #define HAVE_LOG > #define HAVE_EXP > #define HAVE_ASIN > #define HAVE_ACOS > #define HAVE_ATAN > #define HAVE_FMOD > #define HAVE_MODF > #define HAVE_FREXP > #define HAVE_LDEXP > #define HAVE_EXPM1 > #define HAVE_LOG1P > #define HAVE_ACOSH > #define HAVE_ASINH > #define HAVE_ATANH > #define HAVE_RINT > #define HAVE_TRUNC > #define HAVE_EXP2 > #define HAVE_LOG2 > #define HAVE_HYPOT > #define HAVE_ATAN2 > #define HAVE_POW > #define HAVE_COPYSIGN > #define HAVE_NEXTAFTER > #define HAVE_SINF > #define HAVE_COSF > #define HAVE_TANF > #define HAVE_SINHF > #define HAVE_COSHF > #define HAVE_TANHF > #define HAVE_FABSF > #define HAVE_FLOORF > #define HAVE_CEILF > #define HAVE_RINTF > #define HAVE_TRUNCF > #define HAVE_SQRTF > #define HAVE_LOG10F > #define HAVE_LOGF > #define HAVE_LOG1PF > #define HAVE_EXPF > #define HAVE_EXPM1F > #define HAVE_ASINF > #define HAVE_ACOSF > #define HAVE_ATANF > #define HAVE_ASINHF > #define HAVE_ACOSHF > #define HAVE_ATANHF > #define HAVE_HYPOTF > #define HAVE_ATAN2F > #define HAVE_POWF > #define HAVE_FMODF > #define HAVE_MODFF > #define HAVE_FREXPF > #define HAVE_LDEXPF > #define HAVE_EXP2F > #define HAVE_LOG2F > #define HAVE_COPYSIGNF > #define HAVE_NEXTAFTERF > #define HAVE_SINL > #define HAVE_COSL > #define HAVE_TANL > #define HAVE_SINHL > #define HAVE_COSHL > #define HAVE_TANHL > #define HAVE_FABSL > #define HAVE_FLOORL > #define HAVE_CEILL > #define HAVE_RINTL > #define HAVE_TRUNCL > #define HAVE_SQRTL > #define HAVE_LOG10L > #define HAVE_LOGL > #define HAVE_LOG1PL > #define HAVE_EXPL > #define HAVE_EXPM1L > #define HAVE_ASINL > #define HAVE_ACOSL > #define HAVE_ATANL > #define HAVE_ASINHL > #define HAVE_ACOSHL > #define HAVE_ATANHL > #define HAVE_HYPOTL > #define HAVE_ATAN2L > #define HAVE_POWL > #define HAVE_FMODL > #define HAVE_MODFL > #define HAVE_FREXPL > #define HAVE_LDEXPL > #define HAVE_EXP2L > #define HAVE_LOG2L > #define HAVE_COPYSIGNL > #define HAVE_NEXTAFTERL > #define HAVE_DECL_ISNAN > #define HAVE_DECL_ISINF > #define HAVE_DECL_SIGNBIT > #define HAVE_DECL_ISFINITE > #define HAVE_COMPLEX_H > #define HAVE_CREAL > #define HAVE_CIMAG > #define HAVE_CABS > #define HAVE_CARG > #define HAVE_CEXP > #define HAVE_CSQRT > #define HAVE_CLOG > #define HAVE_CCOS > #define HAVE_CSIN > #define HAVE_CPOW > #define HAVE_CREALF > #define HAVE_CIMAGF > #define HAVE_CABSF > #define HAVE_CARGF > #define HAVE_CEXPF > #define HAVE_CSQRTF > #define HAVE_CLOGF > #define HAVE_CCOSF > #define HAVE_CSINF > #define HAVE_CPOWF > #define HAVE_CREALL > #define HAVE_CIMAGL > #define HAVE_CABSL > #define HAVE_CARGL > #define HAVE_CEXPL > #define HAVE_CSQRTL > #define HAVE_CLOGL > #define HAVE_CCOSL > #define HAVE_CSINL > #define HAVE_CPOWL > #define HAVE_LDOUBLE_INTEL_EXTENDED_12_BYTES_LE 1 > #ifndef __cplusplus > /* #undef inline */ > #endif > > #ifndef _NPY_NPY_CONFIG_H_ > #error config.h should never be included directly, include npy_config.h instead > #endif > > EOF > adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' > to sources. > Generating build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'exp' > gcc -m32 -pthread _configtest.o -o _configtest > _configtest.o(.text+0x19): In function `main': > /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' > collect2: ld returned 1 exit status > _configtest.o(.text+0x19): In function `main': > /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' > collect2: ld returned 1 exit status > failure. > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'exp' > gcc -m32 -pthread _configtest.o -lm -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:5: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c:5:18: warning: extra tokens at end of #ifndef directive > _configtest.c: In function `main': > _configtest.c:4: warning: control reaches end of non-void function > success! > removing: _configtest.c _configtest.o > File: build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h > #define NPY_HAVE_ENDIAN_H 1 > #define NPY_SIZEOF_SHORT SIZEOF_SHORT > #define NPY_SIZEOF_INT SIZEOF_INT > #define NPY_SIZEOF_LONG SIZEOF_LONG > #define NPY_SIZEOF_FLOAT 4 > #define NPY_SIZEOF_COMPLEX_FLOAT 8 > #define NPY_SIZEOF_DOUBLE 8 > #define NPY_SIZEOF_COMPLEX_DOUBLE 16 > #define NPY_SIZEOF_LONGDOUBLE 12 > #define NPY_SIZEOF_COMPLEX_LONGDOUBLE 24 > #define NPY_SIZEOF_PY_INTPTR_T 4 > #define NPY_SIZEOF_PY_LONG_LONG 8 > #define NPY_SIZEOF_LONGLONG 8 > #define NPY_NO_SMP 1 > #define NPY_HAVE_DECL_ISNAN > #define NPY_HAVE_DECL_ISINF > #define NPY_HAVE_DECL_SIGNBIT > #define NPY_HAVE_DECL_ISFINITE > #define NPY_USE_C99_COMPLEX > #define NPY_HAVE_COMPLEX_DOUBLE 1 > #define NPY_HAVE_COMPLEX_FLOAT 1 > #define NPY_HAVE_COMPLEX_LONG_DOUBLE 1 > #define NPY_USE_C99_FORMATS 1 > #define NPY_VISIBILITY_HIDDEN __attribute__((visibility("hidden"))) > #define NPY_ABI_VERSION 0x01000009 > #define NPY_API_VERSION 0x00000004 > > #ifndef __STDC_FORMAT_MACROS > #define __STDC_FORMAT_MACROS 1 > #endif > > EOF > adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' > to sources. > executing numpy/core/code_generators/generate_numpy_api.py > adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__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/include/numpy/config.h', > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h'] > building extension "numpy.core.multiarray" sources > non-existing path in 'numpy/core': > 'build/src.linux-x86_64-2.4/numpy/core/src/multiarray' > creating build/src.linux-x86_64-2.4/numpy/core/src/multiarray > conv_template:> > build/src.linux-x86_64-2.4/numpy/core/src/multiarray/scalartypes.c > conv_template:> > build/src.linux-x86_64-2.4/numpy/core/src/multiarray/arraytypes.c > adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' > to sources. > adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' > to sources. > executing numpy/core/code_generators/generate_numpy_api.py > adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h' > to sources. > numpy.core - nothing done with h_files = > ['build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h', > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h'] > building extension "numpy.core.umath" sources > adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' > to sources. > adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' > to sources. > executing numpy/core/code_generators/generate_ufunc_api.py > adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__ufunc_api.h' > to sources. > non-existing path in 'numpy/core': > 'build/src.linux-x86_64-2.4/numpy/core/src/umath' > creating build/src.linux-x86_64-2.4/numpy/core/src/umath > conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/umath/loops.c > conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/umath/umathmodule.c > conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/umath/funcs.inc > adding 'build/src.linux-x86_64-2.4/numpy/core/src/umath' to include_dirs. > numpy.core - nothing done with h_files = > ['build/src.linux-x86_64-2.4/numpy/core/src/umath/funcs.inc', > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h', > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__ufunc_api.h'] > building extension "numpy.core.scalarmath" sources > adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' > to sources. > adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' > to sources. > executing numpy/core/code_generators/generate_numpy_api.py > adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h' > to sources. > executing numpy/core/code_generators/generate_ufunc_api.py > adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__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/include/numpy/config.h', > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h', > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__ufunc_api.h'] > building extension "numpy.core._dotblas" sources > building extension "numpy.core.umath_tests" sources > conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/umath/umath_tests.c > building extension "numpy.core.multiarray_tests" sources > conv_template:> > build/src.linux-x86_64-2.4/numpy/core/src/multiarray/multiarray_tests.c > building extension "numpy.lib._compiled_base" sources > building extension "numpy.numarray._capi" sources > building extension "numpy.fft.fftpack_lite" sources > building extension "numpy.linalg.lapack_lite" sources > creating build/src.linux-x86_64-2.4/numpy/linalg > adding 'numpy/linalg/lapack_litemodule.c' to sources. > adding 'numpy/linalg/python_xerbla.c' to sources. > building extension "numpy.random.mtrand" sources > creating build/src.linux-x86_64-2.4/numpy/random > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > gcc -m32 -pthread _configtest.o -o _configtest > _configtest > failure. > removing: _configtest.c _configtest.o _configtest > building data_files sources > build_src: building npy-pkg config files > running build_py > creating build/lib.linux-x86_64-2.4 > creating build/lib.linux-x86_64-2.4/numpy > copying numpy/version.py -> build/lib.linux-x86_64-2.4/numpy > copying numpy/matlib.py -> build/lib.linux-x86_64-2.4/numpy > copying numpy/ctypeslib.py -> build/lib.linux-x86_64-2.4/numpy > copying numpy/setupscons.py -> build/lib.linux-x86_64-2.4/numpy > copying numpy/__init__.py -> build/lib.linux-x86_64-2.4/numpy > copying numpy/setup.py -> build/lib.linux-x86_64-2.4/numpy > copying numpy/dual.py -> build/lib.linux-x86_64-2.4/numpy > copying numpy/_import_tools.py -> build/lib.linux-x86_64-2.4/numpy > copying numpy/add_newdocs.py -> build/lib.linux-x86_64-2.4/numpy > copying build/src.linux-x86_64-2.4/numpy/__config__.py -> > build/lib.linux-x86_64-2.4/numpy > creating build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/from_template.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/npy_pkg_config.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/compat.py -> build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/setupscons.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/__init__.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/lib2def.py -> build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/interactive.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/info.py -> build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/environment.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/setup.py -> build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/cpuinfo.py -> build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/extension.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/core.py -> build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/intelccompiler.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/log.py -> build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/__version__.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/unixccompiler.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/misc_util.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/line_endings.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/exec_command.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/conv_template.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/ccompiler.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/mingw32ccompiler.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/system_info.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/numpy_distribution.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying build/src.linux-x86_64-2.4/numpy/distutils/__config__.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > creating build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/install.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/egg_info.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/install_clib.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/bdist_rpm.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/develop.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/install_data.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/__init__.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/build_py.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/build_src.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/build_clib.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/build_ext.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/autodist.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/install_headers.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/config.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/config_compiler.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/build.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/build_scripts.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/sdist.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/scons.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > creating build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/none.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/hpux.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/compaq.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/absoft.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/vast.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/nag.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/__init__.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/sun.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/mips.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/intel.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/gnu.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/g95.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/pg.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/ibm.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/lahey.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > creating build/lib.linux-x86_64-2.4/numpy/testing > copying numpy/testing/nulltester.py -> build/lib.linux-x86_64-2.4/numpy/testing > copying numpy/testing/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/testing > copying numpy/testing/__init__.py -> build/lib.linux-x86_64-2.4/numpy/testing > copying numpy/testing/setup.py -> build/lib.linux-x86_64-2.4/numpy/testing > copying numpy/testing/decorators.py -> build/lib.linux-x86_64-2.4/numpy/testing > copying numpy/testing/utils.py -> build/lib.linux-x86_64-2.4/numpy/testing > copying numpy/testing/noseclasses.py -> build/lib.linux-x86_64-2.4/numpy/testing > copying numpy/testing/numpytest.py -> build/lib.linux-x86_64-2.4/numpy/testing > copying numpy/testing/nosetester.py -> build/lib.linux-x86_64-2.4/numpy/testing > creating build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/auxfuncs.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/common_rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/__init__.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/cb_rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/info.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/setup.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/f2py2e.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/cfuncs.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/crackfortran.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/use_rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/diagnose.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/f2py_testing.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/__version__.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/capi_maps.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/func2subr.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/f90mod_rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py > creating build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/defchararray.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/numeric.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/__init__.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/info.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/function_base.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/getlimits.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/setup.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/fromnumeric.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/shape_base.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/setup_common.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/records.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/memmap.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/arrayprint.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/numerictypes.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/machar.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/_mx_datetime_parser.py -> > build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/scons_support.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/_internal.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/code_generators/generate_numpy_api.py -> > build/lib.linux-x86_64-2.4/numpy/core > creating build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/_datasource.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/arraysetops.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/index_tricks.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/format.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/__init__.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/info.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/function_base.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/setup.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/arrayterator.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/ufunclike.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/shape_base.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/user_array.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/type_check.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/stride_tricks.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/recfunctions.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/npyio.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/_iotools.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/utils.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/financial.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/twodim_base.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/polynomial.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/scimath.py -> build/lib.linux-x86_64-2.4/numpy/lib > creating build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/functions.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/alter_code1.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/misc.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/compat.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/setupscons.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/__init__.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/linear_algebra.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/setup.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/random_array.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/user_array.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/alter_code2.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/fft.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/matrix.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/fix_default_axis.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/rng_stats.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/mlab.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/ma.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/ufuncs.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/rng.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/array_printer.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/typeconv.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/precision.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/arrayfns.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > creating build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/nd_image.py -> build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/util.py -> build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/convolve.py -> build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/functions.py -> build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/alter_code1.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/compat.py -> build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/setupscons.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/__init__.py -> build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/linear_algebra.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/setup.py -> build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/random_array.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/alter_code2.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/fft.py -> build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/matrix.py -> build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/numerictypes.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/image.py -> build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/mlab.py -> build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/ma.py -> build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/session.py -> build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/ufuncs.py -> build/lib.linux-x86_64-2.4/numpy/numarray > creating build/lib.linux-x86_64-2.4/numpy/fft > copying numpy/fft/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/fft > copying numpy/fft/__init__.py -> build/lib.linux-x86_64-2.4/numpy/fft > copying numpy/fft/info.py -> build/lib.linux-x86_64-2.4/numpy/fft > copying numpy/fft/setup.py -> build/lib.linux-x86_64-2.4/numpy/fft > copying numpy/fft/fftpack.py -> build/lib.linux-x86_64-2.4/numpy/fft > copying numpy/fft/helper.py -> build/lib.linux-x86_64-2.4/numpy/fft > creating build/lib.linux-x86_64-2.4/numpy/linalg > copying numpy/linalg/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/linalg > copying numpy/linalg/__init__.py -> build/lib.linux-x86_64-2.4/numpy/linalg > copying numpy/linalg/info.py -> build/lib.linux-x86_64-2.4/numpy/linalg > copying numpy/linalg/setup.py -> build/lib.linux-x86_64-2.4/numpy/linalg > copying numpy/linalg/linalg.py -> build/lib.linux-x86_64-2.4/numpy/linalg > creating build/lib.linux-x86_64-2.4/numpy/random > copying numpy/random/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/random > copying numpy/random/__init__.py -> build/lib.linux-x86_64-2.4/numpy/random > copying numpy/random/info.py -> build/lib.linux-x86_64-2.4/numpy/random > copying numpy/random/setup.py -> build/lib.linux-x86_64-2.4/numpy/random > creating build/lib.linux-x86_64-2.4/numpy/ma > copying numpy/ma/version.py -> build/lib.linux-x86_64-2.4/numpy/ma > copying numpy/ma/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/ma > copying numpy/ma/__init__.py -> build/lib.linux-x86_64-2.4/numpy/ma > copying numpy/ma/setup.py -> build/lib.linux-x86_64-2.4/numpy/ma > copying numpy/ma/bench.py -> build/lib.linux-x86_64-2.4/numpy/ma > copying numpy/ma/core.py -> build/lib.linux-x86_64-2.4/numpy/ma > copying numpy/ma/testutils.py -> build/lib.linux-x86_64-2.4/numpy/ma > copying numpy/ma/timer_comparison.py -> build/lib.linux-x86_64-2.4/numpy/ma > copying numpy/ma/extras.py -> build/lib.linux-x86_64-2.4/numpy/ma > copying numpy/ma/mrecords.py -> build/lib.linux-x86_64-2.4/numpy/ma > creating build/lib.linux-x86_64-2.4/numpy/matrixlib > copying numpy/matrixlib/setupscons.py -> > build/lib.linux-x86_64-2.4/numpy/matrixlib > copying numpy/matrixlib/__init__.py -> > build/lib.linux-x86_64-2.4/numpy/matrixlib > copying numpy/matrixlib/setup.py -> build/lib.linux-x86_64-2.4/numpy/matrixlib > copying numpy/matrixlib/defmatrix.py -> > build/lib.linux-x86_64-2.4/numpy/matrixlib > creating build/lib.linux-x86_64-2.4/numpy/compat > copying numpy/compat/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/compat > copying numpy/compat/__init__.py -> build/lib.linux-x86_64-2.4/numpy/compat > copying numpy/compat/setup.py -> build/lib.linux-x86_64-2.4/numpy/compat > copying numpy/compat/py3k.py -> build/lib.linux-x86_64-2.4/numpy/compat > copying numpy/compat/_inspect.py -> build/lib.linux-x86_64-2.4/numpy/compat > creating build/lib.linux-x86_64-2.4/numpy/polynomial > copying numpy/polynomial/__init__.py -> > build/lib.linux-x86_64-2.4/numpy/polynomial > copying numpy/polynomial/setup.py -> build/lib.linux-x86_64-2.4/numpy/polynomial > copying numpy/polynomial/chebyshev.py -> > build/lib.linux-x86_64-2.4/numpy/polynomial > copying numpy/polynomial/polynomial.py -> > build/lib.linux-x86_64-2.4/numpy/polynomial > copying numpy/polynomial/polyutils.py -> > build/lib.linux-x86_64-2.4/numpy/polynomial > copying numpy/polynomial/polytemplate.py -> > build/lib.linux-x86_64-2.4/numpy/polynomial > creating build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/byteswapping.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/glossary.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/indexing.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/misc.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/internals.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/__init__.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/creation.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/jargon.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/basics.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/io.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/methods_vs_functions.py -> > build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/broadcasting.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/constants.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/howtofind.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/ufuncs.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/subclassing.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/structured_arrays.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/performance.py -> build/lib.linux-x86_64-2.4/numpy/doc > running build_clib > customize UnixCCompiler > customize UnixCCompiler using build_clib > building 'npymath' library > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > creating build/temp.linux-x86_64-2.4 > creating build/temp.linux-x86_64-2.4/build > creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4 > creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy > creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core > creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src > creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/npymath > compile options: '-Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math.c > In file included from numpy/core/src/private/npy_config.h:4, > from numpy/core/src/npymath/npy_math_private.h:24, > from numpy/core/src/npymath/npy_math.c.src:56: > build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: > warning: "HAVE_HYPOT" redefined > In file included from /home/sanjey/include/python2.4/Python.h:8, > from numpy/core/src/npymath/npy_math_private.h:21, > from numpy/core/src/npymath/npy_math.c.src:56: > /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the > location of the previous definition > gcc: build/src.linux-x86_64-2.4/numpy/core/src/npymath/ieee754.c > In file included from numpy/core/src/private/npy_config.h:4, > from numpy/core/src/npymath/npy_math_common.h:8, > from numpy/core/src/npymath/ieee754.c.src:7: > build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: > warning: "HAVE_HYPOT" redefined > In file included from /home/sanjey/include/python2.4/Python.h:8, > from numpy/core/src/npymath/npy_math_common.h:4, > from numpy/core/src/npymath/ieee754.c.src:7: > /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the > location of the previous definition > gcc: build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math_complex.c > In file included from numpy/core/src/private/npy_config.h:4, > from numpy/core/src/npymath/npy_math_common.h:8, > from numpy/core/src/npymath/npy_math_complex.c.src:31: > build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: > warning: "HAVE_HYPOT" redefined > In file included from /home/sanjey/include/python2.4/Python.h:8, > from numpy/core/src/npymath/npy_math_common.h:4, > from numpy/core/src/npymath/npy_math_complex.c.src:31: > /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the > location of the previous definition > ar: adding 3 object files to build/temp.linux-x86_64-2.4/libnpymath.a > running build_ext > customize UnixCCompiler > customize UnixCCompiler using build_ext > customize GnuFCompiler > gnu: no Fortran 90 compiler found > gnu: no Fortran 90 compiler found > customize GnuFCompiler > gnu: no Fortran 90 compiler found > gnu: no Fortran 90 compiler found > customize GnuFCompiler using build_ext > building 'numpy.core._sort' extension > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: build/src.linux-x86_64-2.4/numpy/core/src/_sortmodule.c > In file included from numpy/core/src/private/npy_config.h:4, > from numpy/core/src/_sortmodule.c.src:34: > build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: > warning: "HAVE_HYPOT" redefined > In file included from /home/sanjey/include/python2.4/Python.h:8, > from numpy/core/src/_sortmodule.c.src:30: > /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the > location of the previous definition > gcc -m32 -pthread -shared > build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/_sortmodule.o > -Lbuild/temp.linux-x86_64-2.4 -lm -o > build/lib.linux-x86_64-2.4/numpy/core/_sort.so > building 'numpy.core.multiarray' extension > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > creating build/temp.linux-x86_64-2.4/numpy > creating build/temp.linux-x86_64-2.4/numpy/core > creating build/temp.linux-x86_64-2.4/numpy/core/src > creating build/temp.linux-x86_64-2.4/numpy/core/src/multiarray > compile options: '-Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: numpy/core/src/multiarray/multiarraymodule_onefile.c > In file included from numpy/core/src/private/npy_config.h:4, > from numpy/core/src/multiarray/common.c:8, > from numpy/core/src/multiarray/multiarraymodule_onefile.c:8: > build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: > warning: "HAVE_HYPOT" redefined > In file included from /home/sanjey/include/python2.4/Python.h:8, > from numpy/core/src/multiarray/common.c:2, > from numpy/core/src/multiarray/multiarraymodule_onefile.c:8: > /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the > location of the previous definition > In file included from numpy/core/src/multiarray/multiarraymodule_onefile.c:26: > numpy/core/src/multiarray/methods.c: In function `NpyArg_ParseKeywords': > numpy/core/src/multiarray/methods.c:41: warning: passing arg 3 of > `PyArg_VaParseTupleAndKeywords' discards qualifiers from pointer > target type > numpy/core/src/multiarray/flagsobject.c: In function `arrayflags_richcompare': > numpy/core/src/multiarray/flagsobject.c:568: warning: 'cmp' might be > used uninitialized in this function > numpy/core/src/multiarray/multiarraymodule_onefile.c: At top level: > numpy/core/include/numpy/npy_3kcompat.h:331: warning: > 'simple_capsule_dtor' defined but not used > numpy/core/src/multiarray/buffer.c:777: warning: > '_descriptor_from_pep3118_format' defined but not used > numpy/core/src/multiarray/arraytypes.c.src:93: warning: > '_SEQUENCE_MESSAGE' defined but not used > numpy/core/src/multiarray/mapping.c:75: warning: '_array_ass_item' > defined but not used > gcc -m32 -pthread -shared > build/temp.linux-x86_64-2.4/numpy/core/src/multiarray/multiarraymodule_onefile.o > -Lbuild/temp.linux-x86_64-2.4 -lnpymath -lm -o > build/lib.linux-x86_64-2.4/numpy/core/multiarray.so > building 'numpy.core.umath' extension > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > creating build/temp.linux-x86_64-2.4/numpy/core/src/umath > compile options: '-Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath > -Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: numpy/core/src/umath/umathmodule_onefile.c > In file included from numpy/core/src/private/npy_config.h:4, > from numpy/core/src/umath/loops.c.src:7, > from numpy/core/src/umath/umathmodule_onefile.c:1: > build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: > warning: "HAVE_HYPOT" redefined > In file included from /home/sanjey/include/python2.4/Python.h:8, > from numpy/core/src/umath/loops.c.src:5, > from numpy/core/src/umath/umathmodule_onefile.c:1: > /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the > location of the previous definition > numpy/core/include/numpy/npy_3kcompat.h:331: warning: > 'simple_capsule_dtor' defined but not used > numpy/core/src/umath/loops.c.src:1258: warning: > 'CLONGDOUBLE_logical_and' defined but not used > numpy/core/src/umath/loops.c.src:1258: warning: > 'CLONGDOUBLE_logical_or' defined but not used > numpy/core/src/umath/loops.c.src:1271: warning: > 'CLONGDOUBLE_logical_xor' defined but not used > numpy/core/src/umath/loops.c.src:1285: warning: > 'CLONGDOUBLE_logical_not' defined but not used > numpy/core/src/umath/loops.c.src:1342: warning: > 'CLONGDOUBLE_ones_like' defined but not used > numpy/core/src/umath/loops.c.src:1399: warning: 'CLONGDOUBLE_maximum' > defined but not used > numpy/core/src/umath/loops.c.src:1399: warning: 'CLONGDOUBLE_minimum' > defined but not used > numpy/core/src/umath/loops.c.src:1423: warning: 'CLONGDOUBLE_fmax' > defined but not used > numpy/core/src/umath/loops.c.src:1423: warning: 'CLONGDOUBLE_fmin' > defined but not used > gcc -m32 -pthread -shared > build/temp.linux-x86_64-2.4/numpy/core/src/umath/umathmodule_onefile.o > -Lbuild/temp.linux-x86_64-2.4 -lnpymath -lm -o > build/lib.linux-x86_64-2.4/numpy/core/umath.so > building 'numpy.core.scalarmath' extension > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: build/src.linux-x86_64-2.4/numpy/core/src/scalarmathmodule.c > numpy/core/include/numpy/npy_3kcompat.h:331: warning: > 'simple_capsule_dtor' defined but not used > gcc -m32 -pthread -shared > build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/scalarmathmodule.o > -Lbuild/temp.linux-x86_64-2.4 -lm -o > build/lib.linux-x86_64-2.4/numpy/core/scalarmath.so > building 'numpy.core.umath_tests' extension > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/umath > compile options: '-Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: build/src.linux-x86_64-2.4/numpy/core/src/umath/umath_tests.c > In file included from numpy/core/src/private/npy_config.h:4, > from numpy/core/src/umath/umath_tests.c.src:14: > build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: > warning: "HAVE_HYPOT" redefined > In file included from /home/sanjey/include/python2.4/Python.h:8, > from numpy/core/src/umath/umath_tests.c.src:8: > /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the > location of the previous definition > numpy/core/include/numpy/npy_3kcompat.h:331: warning: > 'simple_capsule_dtor' defined but not used > gcc -m32 -pthread -shared > build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/umath/umath_tests.o > -Lbuild/temp.linux-x86_64-2.4 -o > build/lib.linux-x86_64-2.4/numpy/core/umath_tests.so > building 'numpy.core.multiarray_tests' extension > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/multiarray > compile options: '-Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: build/src.linux-x86_64-2.4/numpy/core/src/multiarray/multiarray_tests.c > numpy/core/include/numpy/npy_3kcompat.h:331: warning: > 'simple_capsule_dtor' defined but not used > gcc -m32 -pthread -shared > build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/multiarray/multiarray_tests.o > -Lbuild/temp.linux-x86_64-2.4 -o > build/lib.linux-x86_64-2.4/numpy/core/multiarray_tests.so > building 'numpy.lib._compiled_base' extension > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > creating build/temp.linux-x86_64-2.4/numpy/lib > creating build/temp.linux-x86_64-2.4/numpy/lib/src > compile options: '-Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: numpy/lib/src/_compiled_base.c > In file included from numpy/core/src/private/npy_config.h:4, > from numpy/lib/src/_compiled_base.c:4: > build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: > warning: "HAVE_HYPOT" redefined > In file included from /home/sanjey/include/python2.4/Python.h:8, > from numpy/lib/src/_compiled_base.c:1: > /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the > location of the previous definition > gcc -m32 -pthread -shared > build/temp.linux-x86_64-2.4/numpy/lib/src/_compiled_base.o > -Lbuild/temp.linux-x86_64-2.4 -o > build/lib.linux-x86_64-2.4/numpy/lib/_compiled_base.so > building 'numpy.numarray._capi' extension > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > creating build/temp.linux-x86_64-2.4/numpy/numarray > compile options: '-Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: numpy/numarray/_capi.c > numpy/core/include/numpy/npy_3kcompat.h:331: warning: > 'simple_capsule_dtor' defined but not used > gcc -m32 -pthread -shared > build/temp.linux-x86_64-2.4/numpy/numarray/_capi.o > -Lbuild/temp.linux-x86_64-2.4 -o > build/lib.linux-x86_64-2.4/numpy/numarray/_capi.so > building 'numpy.fft.fftpack_lite' extension > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > creating build/temp.linux-x86_64-2.4/numpy/fft > compile options: '-Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: numpy/fft/fftpack_litemodule.c > gcc: numpy/fft/fftpack.c > gcc -m32 -pthread -shared > build/temp.linux-x86_64-2.4/numpy/fft/fftpack_litemodule.o > build/temp.linux-x86_64-2.4/numpy/fft/fftpack.o > -Lbuild/temp.linux-x86_64-2.4 -o > build/lib.linux-x86_64-2.4/numpy/fft/fftpack_lite.so > building 'numpy.linalg.lapack_lite' extension > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > creating build/temp.linux-x86_64-2.4/numpy/linalg > compile options: '-DNO_ATLAS_INFO=1 -Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: numpy/linalg/lapack_litemodule.c > gcc: numpy/linalg/python_xerbla.c > /usr/bin/g77 -g -Wall -g -Wall -shared > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o > build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o -L/usr/lib > -Lbuild/temp.linux-x86_64-2.4 -llapack -lblas -lg2c -o > build/lib.linux-x86_64-2.4/numpy/linalg/lapack_lite.so > /usr/bin/ld: skipping incompatible /usr/lib/liblapack.so when > searching for -llapack > /usr/bin/ld: skipping incompatible /usr/lib/liblapack.a when searching > for -llapack > /usr/bin/ld: skipping incompatible /usr/lib/libblas.so when searching for -lblas > /usr/bin/ld: skipping incompatible /usr/lib/libblas.a when searching for -lblas > /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm > /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm > /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm > /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm > /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 > /usr/bin/ld: warning: i386 architecture of input file > `build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o' is > incompatible with i386:x86-64 output > /usr/bin/ld: warning: i386 architecture of input file > `build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o' is > incompatible with i386:x86-64 output > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xae): > In function `lapack_lite_dgeev': > numpy/linalg/lapack_litemodule.c:155: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfe):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x143):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a3):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1f4):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x272):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31c):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ae):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x60e):numpy/linalg/lapack_litemodule.c:171: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6aa): > In function `lapack_lite_dsyevd': > numpy/linalg/lapack_litemodule.c:241: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6f4):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x739):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x797):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x7ef):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x869):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x8ff):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xa7c):numpy/linalg/lapack_litemodule.c:254: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb34): > In function `lapack_lite_zheevd': > numpy/linalg/lapack_litemodule.c:327: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb7e):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xbc3):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc23):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc74):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xce9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xd85):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xe77):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfb9):numpy/linalg/lapack_litemodule.c:341: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1087): > In function `lapack_lite_dgelsd': > numpy/linalg/lapack_litemodule.c:365: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x10d7):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x111c):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x117d):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x11cf):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1252):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x12e8):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x13d7):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1534):numpy/linalg/lapack_litemodule.c:380: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15af): > In function `lapack_lite_dgesv': > numpy/linalg/lapack_litemodule.c:398: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15f9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x163e):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1692):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x16e7):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x175e):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x189a):numpy/linalg/lapack_litemodule.c:407: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1967): > In function `lapack_lite_dgesdd': > numpy/linalg/lapack_litemodule.c:430: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19b7):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19fc):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a5d):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1aaf):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1b32):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1bc8):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d15):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d76):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1efb):numpy/linalg/lapack_litemodule.c:472: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x202b): > In function `lapack_lite_dgetrf': > numpy/linalg/lapack_litemodule.c:488: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2063):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20ae):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20fe):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2155):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2235):numpy/linalg/lapack_litemodule.c:496: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22b4): > In function `lapack_lite_dpotrf': > numpy/linalg/lapack_litemodule.c:510: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22e9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x232d):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x238f):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x240a):numpy/linalg/lapack_litemodule.c:516: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24af): > In function `lapack_lite_dgeqrf': > numpy/linalg/lapack_litemodule.c:529: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24f9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x253e):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2598):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x25ef):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2669):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x27a7):numpy/linalg/lapack_litemodule.c:540: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2839): > In function `lapack_lite_dorgqr': > numpy/linalg/lapack_litemodule.c:555: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2883):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x28c8):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2927):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x297f):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x29f9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2afa):numpy/linalg/lapack_litemodule.c:562: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2bbb): > In function `lapack_lite_zgeev': > numpy/linalg/lapack_litemodule.c:585: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c0b):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c50):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2cb0):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d04):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d82):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2e2c):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2f6b):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2fb9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x311b):numpy/linalg/lapack_litemodule.c:601: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31f4): > In function `lapack_lite_zgelsd': > numpy/linalg/lapack_litemodule.c:626: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3244):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3289):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x32ef):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3340):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x33c8):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3471):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35b1):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35ff):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x376f):numpy/linalg/lapack_litemodule.c:641: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x37ef): > In function `lapack_lite_zgesv': > numpy/linalg/lapack_litemodule.c:658: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3839):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x387e):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x38d2):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3927):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x399e):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3ada):numpy/linalg/lapack_litemodule.c:667: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bae): > In function `lapack_lite_zgesdd': > numpy/linalg/lapack_litemodule.c:691: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bfe):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3c43):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cab):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cff):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3d82):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3e2c):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3f70):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3fbe):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4195):numpy/linalg/lapack_litemodule.c:708: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x41ab):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x422b): > In function `lapack_lite_zgetrf': > numpy/linalg/lapack_litemodule.c:724: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4263):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42ae):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42fe):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4355):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4435):numpy/linalg/lapack_litemodule.c:732: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44b4): > In function `lapack_lite_zpotrf': > numpy/linalg/lapack_litemodule.c:746: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44e9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x452d):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x458f):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460a):numpy/linalg/lapack_litemodule.c:751: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46af): > In function `lapack_lite_zgeqrf': > numpy/linalg/lapack_litemodule.c:764: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46f9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x473e):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4798):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x47ef):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4869):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x49a7):numpy/linalg/lapack_litemodule.c:774: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a39): > In function `lapack_lite_zungqr': > numpy/linalg/lapack_litemodule.c:787: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a83):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ac8):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b27):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b7f):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4bf9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4cfa):numpy/linalg/lapack_litemodule.c:797: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d58): > In function `initlapack_lite': > numpy/linalg/lapack_litemodule.c:858: undefined reference to `Py_InitModule4' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d71): > In function `initlapack_lite': > build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1190: > undefined reference to `PyImport_ImportModule' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d8d):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1197: > undefined reference to `PyObject_GetAttrString' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4da6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1212: > undefined reference to `PyCObject_Type' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4db5):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: > undefined reference to `PyExc_RuntimeError' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dc9):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: > undefined reference to `PyErr_SetString' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dd7): > In function `initlapack_lite': > numpy/linalg/lapack_litemodule.c:865: undefined reference to `PyErr_Print' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ddd):numpy/linalg/lapack_litemodule.c:865: > undefined reference to `PyExc_ImportError' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4df1):numpy/linalg/lapack_litemodule.c:865: > undefined reference to `PyErr_SetString' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e18): > In function `initlapack_lite': > build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1194: > undefined reference to `PyExc_ImportError' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e26):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: > undefined reference to `PyErr_SetString' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e46):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1217: > undefined reference to `PyCObject_AsVoidPtr' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e88):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: > undefined reference to `PyExc_RuntimeError' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e96):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ea1):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: > undefined reference to `PyExc_RuntimeError' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4eb6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1200: > undefined reference to `PyExc_AttributeError' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f24):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: > undefined reference to `PyExc_RuntimeError' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f2e):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f46): > In function `initlapack_lite': > numpy/linalg/lapack_litemodule.c:866: undefined reference to `PyModule_GetDict' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f66):numpy/linalg/lapack_litemodule.c:867: > undefined reference to `PyErr_NewException' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f82):numpy/linalg/lapack_litemodule.c:868: > undefined reference to `PyDict_SetItemString' > build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x70): > In function `xerbla_': > numpy/linalg/python_xerbla.c:35: undefined reference to `PyExc_ValueError' > build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x7e):numpy/linalg/python_xerbla.c:35: > undefined reference to `PyErr_SetString' > collect2: ld returned 1 exit status > /usr/bin/ld: skipping incompatible /usr/lib/liblapack.so when > searching for -llapack > /usr/bin/ld: skipping incompatible /usr/lib/liblapack.a when searching > for -llapack > /usr/bin/ld: skipping incompatible /usr/lib/libblas.so when searching for -lblas > /usr/bin/ld: skipping incompatible /usr/lib/libblas.a when searching for -lblas > /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm > /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm > /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm > /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm > /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 > /usr/bin/ld: warning: i386 architecture of input file > `build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o' is > incompatible with i386:x86-64 output > /usr/bin/ld: warning: i386 architecture of input file > `build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o' is > incompatible with i386:x86-64 output > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xae): > In function `lapack_lite_dgeev': > numpy/linalg/lapack_litemodule.c:155: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfe):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x143):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a3):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1f4):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x272):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31c):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ae):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x60e):numpy/linalg/lapack_litemodule.c:171: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6aa): > In function `lapack_lite_dsyevd': > numpy/linalg/lapack_litemodule.c:241: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6f4):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x739):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x797):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x7ef):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x869):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x8ff):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xa7c):numpy/linalg/lapack_litemodule.c:254: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb34): > In function `lapack_lite_zheevd': > numpy/linalg/lapack_litemodule.c:327: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb7e):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xbc3):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc23):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc74):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xce9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xd85):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xe77):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfb9):numpy/linalg/lapack_litemodule.c:341: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1087): > In function `lapack_lite_dgelsd': > numpy/linalg/lapack_litemodule.c:365: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x10d7):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x111c):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x117d):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x11cf):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1252):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x12e8):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x13d7):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1534):numpy/linalg/lapack_litemodule.c:380: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15af): > In function `lapack_lite_dgesv': > numpy/linalg/lapack_litemodule.c:398: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15f9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x163e):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1692):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x16e7):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x175e):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x189a):numpy/linalg/lapack_litemodule.c:407: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1967): > In function `lapack_lite_dgesdd': > numpy/linalg/lapack_litemodule.c:430: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19b7):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19fc):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a5d):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1aaf):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1b32):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1bc8):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d15):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d76):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1efb):numpy/linalg/lapack_litemodule.c:472: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x202b): > In function `lapack_lite_dgetrf': > numpy/linalg/lapack_litemodule.c:488: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2063):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20ae):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20fe):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2155):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2235):numpy/linalg/lapack_litemodule.c:496: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22b4): > In function `lapack_lite_dpotrf': > numpy/linalg/lapack_litemodule.c:510: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22e9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x232d):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x238f):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x240a):numpy/linalg/lapack_litemodule.c:516: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24af): > In function `lapack_lite_dgeqrf': > numpy/linalg/lapack_litemodule.c:529: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24f9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x253e):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2598):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x25ef):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2669):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x27a7):numpy/linalg/lapack_litemodule.c:540: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2839): > In function `lapack_lite_dorgqr': > numpy/linalg/lapack_litemodule.c:555: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2883):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x28c8):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2927):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x297f):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x29f9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2afa):numpy/linalg/lapack_litemodule.c:562: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2bbb): > In function `lapack_lite_zgeev': > numpy/linalg/lapack_litemodule.c:585: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c0b):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c50):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2cb0):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d04):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d82):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2e2c):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2f6b):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2fb9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x311b):numpy/linalg/lapack_litemodule.c:601: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31f4): > In function `lapack_lite_zgelsd': > numpy/linalg/lapack_litemodule.c:626: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3244):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3289):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x32ef):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3340):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x33c8):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3471):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35b1):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35ff):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x376f):numpy/linalg/lapack_litemodule.c:641: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x37ef): > In function `lapack_lite_zgesv': > numpy/linalg/lapack_litemodule.c:658: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3839):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x387e):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x38d2):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3927):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x399e):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3ada):numpy/linalg/lapack_litemodule.c:667: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bae): > In function `lapack_lite_zgesdd': > numpy/linalg/lapack_litemodule.c:691: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bfe):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3c43):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cab):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cff):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3d82):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3e2c):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3f70):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3fbe):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4195):numpy/linalg/lapack_litemodule.c:708: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x41ab):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x422b): > In function `lapack_lite_zgetrf': > numpy/linalg/lapack_litemodule.c:724: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4263):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42ae):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42fe):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4355):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4435):numpy/linalg/lapack_litemodule.c:732: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44b4): > In function `lapack_lite_zpotrf': > numpy/linalg/lapack_litemodule.c:746: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44e9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x452d):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x458f):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460a):numpy/linalg/lapack_litemodule.c:751: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46af): > In function `lapack_lite_zgeqrf': > numpy/linalg/lapack_litemodule.c:764: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46f9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x473e):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4798):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x47ef):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4869):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x49a7):numpy/linalg/lapack_litemodule.c:774: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a39): > In function `lapack_lite_zungqr': > numpy/linalg/lapack_litemodule.c:787: undefined reference to `PyArg_ParseTuple' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a83):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ac8):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b27):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b7f):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4bf9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4cfa):numpy/linalg/lapack_litemodule.c:797: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d58): > In function `initlapack_lite': > numpy/linalg/lapack_litemodule.c:858: undefined reference to `Py_InitModule4' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d71): > In function `initlapack_lite': > build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1190: > undefined reference to `PyImport_ImportModule' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d8d):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1197: > undefined reference to `PyObject_GetAttrString' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4da6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1212: > undefined reference to `PyCObject_Type' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4db5):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: > undefined reference to `PyExc_RuntimeError' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dc9):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: > undefined reference to `PyErr_SetString' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dd7): > In function `initlapack_lite': > numpy/linalg/lapack_litemodule.c:865: undefined reference to `PyErr_Print' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ddd):numpy/linalg/lapack_litemodule.c:865: > undefined reference to `PyExc_ImportError' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4df1):numpy/linalg/lapack_litemodule.c:865: > undefined reference to `PyErr_SetString' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e18): > In function `initlapack_lite': > build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1194: > undefined reference to `PyExc_ImportError' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e26):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: > undefined reference to `PyErr_SetString' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e46):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1217: > undefined reference to `PyCObject_AsVoidPtr' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e88):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: > undefined reference to `PyExc_RuntimeError' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e96):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ea1):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: > undefined reference to `PyExc_RuntimeError' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4eb6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1200: > undefined reference to `PyExc_AttributeError' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f24):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: > undefined reference to `PyExc_RuntimeError' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f2e):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f46): > In function `initlapack_lite': > numpy/linalg/lapack_litemodule.c:866: undefined reference to `PyModule_GetDict' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f66):numpy/linalg/lapack_litemodule.c:867: > undefined reference to `PyErr_NewException' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f82):numpy/linalg/lapack_litemodule.c:868: > undefined reference to `PyDict_SetItemString' > build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x70): > In function `xerbla_': > numpy/linalg/python_xerbla.c:35: undefined reference to `PyExc_ValueError' > build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x7e):numpy/linalg/python_xerbla.c:35: > undefined reference to `PyErr_SetString' > collect2: ld returned 1 exit status > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion Since you are using the -m32 flag, do you have *all* the 32-bit libraries/headers installed (especially Python 2.4 ones) what appears to be a x86_64 operating system? Bruce From p.sanjey at gmail.com Fri Oct 15 11:30:39 2010 From: p.sanjey at gmail.com (P Sanjey) Date: Fri, 15 Oct 2010 16:30:39 +0100 Subject: [Numpy-discussion] Please help a newbie install NUMPY In-Reply-To: <4CB871D8.4080503@gmail.com> References: <4CB871D8.4080503@gmail.com> Message-ID: Hi Bruce, Not sure how to check if they are there (the libraries)-do you mean the ones with .so extensions? How can I know wht libraries are needed and whats already there? Yes its a x86_64 machine but I need a 32 bit version as I have another piece of code that only works on 32 bits so I am stuck with the 32 bit version Thanks for the help On Fri, Oct 15, 2010 at 4:23 PM, Bruce Southey wrote: > ?On 10/15/2010 09:31 AM, P Sanjey wrote: >> Please help-I am a newbie and I wanted to try installing numpy on a >> local /home/usr directory but got the following errors-I am not sure >> where to even begin fixing this problem and any help would be useful >> I just did the standard >> python setup.py build and got the following (loooooong) error message >> >> >> ********************************************************** >> non-existing path in 'numpy/distutils': 'site.cfg' >> F2PY Version 1 >> blas_opt_info: >> blas_mkl_info: >> ? ?libraries mkl,vml,guide not found in /home/sanjey/lib >> ? ?libraries mkl,vml,guide not found in /usr/local/lib >> ? ?libraries mkl,vml,guide not found in /usr/lib >> ? ?NOT AVAILABLE >> >> atlas_blas_threads_info: >> Setting PTATLAS=ATLAS >> ? ?libraries ptf77blas,ptcblas,atlas not found in /home/sanjey/lib >> ? ?libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib >> ? ?libraries ptf77blas,ptcblas,atlas not found in /usr/lib/sse2 >> ? ?libraries ptf77blas,ptcblas,atlas not found in /usr/lib >> ? ?NOT AVAILABLE >> >> atlas_blas_info: >> ? ?libraries f77blas,cblas,atlas not found in /home/sanjey/lib >> ? ?libraries f77blas,cblas,atlas not found in /usr/local/lib >> ? ?libraries f77blas,cblas,atlas not found in /usr/lib/sse2 >> ? ?libraries f77blas,cblas,atlas not found in /usr/lib >> ? ?NOT AVAILABLE >> >> blas_info: >> ? ?libraries blas not found in /home/sanjey/lib >> ? ?libraries blas not found in /usr/local/lib >> ? ?FOUND: >> ? ? ?libraries = ['blas'] >> ? ? ?library_dirs = ['/usr/lib'] >> ? ? ?language = f77 >> >> ? ?FOUND: >> ? ? ?libraries = ['blas'] >> ? ? ?library_dirs = ['/usr/lib'] >> ? ? ?define_macros = [('NO_ATLAS_INFO', 1)] >> ? ? ?language = f77 >> >> lapack_opt_info: >> lapack_mkl_info: >> mkl_info: >> ? ?libraries mkl,vml,guide not found in /home/sanjey/lib >> ? ?libraries mkl,vml,guide not found in /usr/local/lib >> ? ?libraries mkl,vml,guide not found in /usr/lib >> ? ?NOT AVAILABLE >> >> ? ?NOT AVAILABLE >> >> atlas_threads_info: >> Setting PTATLAS=ATLAS >> ? ?libraries ptf77blas,ptcblas,atlas not found in /home/sanjey/lib >> ? ?libraries lapack_atlas not found in /home/sanjey/lib >> ? ?libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib >> ? ?libraries lapack_atlas not found in /usr/local/lib >> ? ?libraries ptf77blas,ptcblas,atlas not found in /usr/lib/sse2 >> ? ?libraries lapack_atlas not found in /usr/lib/sse2 >> ? ?libraries ptf77blas,ptcblas,atlas not found in /usr/lib >> ? ?libraries lapack_atlas not found in /usr/lib >> numpy.distutils.system_info.atlas_threads_info >> ? ?NOT AVAILABLE >> >> atlas_info: >> ? ?libraries f77blas,cblas,atlas not found in /home/sanjey/lib >> ? ?libraries lapack_atlas not found in /home/sanjey/lib >> ? ?libraries f77blas,cblas,atlas not found in /usr/local/lib >> ? ?libraries lapack_atlas not found in /usr/local/lib >> ? ?libraries f77blas,cblas,atlas not found in /usr/lib/sse2 >> ? ?libraries lapack_atlas not found in /usr/lib/sse2 >> ? ?libraries f77blas,cblas,atlas not found in /usr/lib >> ? ?libraries lapack_atlas not found in /usr/lib >> numpy.distutils.system_info.atlas_info >> ? ?NOT AVAILABLE >> >> lapack_info: >> ? ?libraries lapack not found in /home/sanjey/lib >> ? ?libraries lapack not found in /usr/local/lib >> ? ?FOUND: >> ? ? ?libraries = ['lapack'] >> ? ? ?library_dirs = ['/usr/lib'] >> ? ? ?language = f77 >> >> ? ?FOUND: >> ? ? ?libraries = ['lapack', 'blas'] >> ? ? ?library_dirs = ['/usr/lib'] >> ? ? ?define_macros = [('NO_ATLAS_INFO', 1)] >> ? ? ?language = f77 >> >> running build >> running config_cc >> unifing config_cc, config, build_clib, build_ext, build commands >> --compiler options >> running config_fc >> unifing config_fc, config, build_clib, build_ext, build commands >> --fcompiler options >> running build_src >> 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 library "npymath" sources >> customize GnuFCompiler >> Found executable /usr/bin/g77 >> gnu: no Fortran 90 compiler found >> gnu: no Fortran 90 compiler found >> customize GnuFCompiler >> gnu: no Fortran 90 compiler found >> gnu: no Fortran 90 compiler found >> customize GnuFCompiler using config >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> gcc -m32 -pthread _configtest.o -o _configtest >> success! >> removing: _configtest.c _configtest.o _configtest >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:1: warning: conflicting types for built-in function 'exp' >> gcc -m32 -pthread _configtest.o -o _configtest >> _configtest.o(.text+0x19): In function `main': >> /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' >> collect2: ld returned 1 exit status >> _configtest.o(.text+0x19): In function `main': >> /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' >> collect2: ld returned 1 exit status >> failure. >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:1: warning: conflicting types for built-in function 'exp' >> gcc -m32 -pthread _configtest.o -lm -o _configtest >> success! >> removing: _configtest.c _configtest.o _configtest >> creating build/src.linux-x86_64-2.4/numpy/core >> creating build/src.linux-x86_64-2.4/numpy/core/src >> creating build/src.linux-x86_64-2.4/numpy/core/src/npymath >> conv_template:> ?build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math.c >> conv_template:> ?build/src.linux-x86_64-2.4/numpy/core/src/npymath/ieee754.c >> conv_template:> >> build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math_complex.c >> building extension "numpy.core._sort" sources >> Generating build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> success! >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> success! >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:5: warning: function declaration isn't a prototype >> success! >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:5: warning: function declaration isn't a prototype >> success! >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:5: warning: function declaration isn't a prototype >> success! >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:5: warning: function declaration isn't a prototype >> success! >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> removing: _configtest.c _configtest.o _configtest.c _configtest.o >> _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c >> _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:5: warning: function declaration isn't a prototype >> success! >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> removing: _configtest.c _configtest.o _configtest.c _configtest.o >> _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c >> _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o >> _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:5: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:7: error: `SIZEOF_LONGDOUBLE' undeclared (first use in >> this function) >> _configtest.c:7: error: (Each undeclared identifier is reported only once >> _configtest.c:7: error: for each function it appears in.) >> _configtest.c:5: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:7: error: `SIZEOF_LONGDOUBLE' undeclared (first use in >> this function) >> _configtest.c:7: error: (Each undeclared identifier is reported only once >> _configtest.c:7: error: for each function it appears in.) >> failure. >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> removing: _configtest.c _configtest.o _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> removing: _configtest.c _configtest.o _configtest.c _configtest.o >> _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c >> _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o >> _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c >> _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:5: error: size of array `test_array' is negative >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> removing: _configtest.c _configtest.o _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:6: warning: function declaration isn't a prototype >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:6: warning: function declaration isn't a prototype >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:5: warning: function declaration isn't a prototype >> success! >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:6: warning: function declaration isn't a prototype >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:6: warning: function declaration isn't a prototype >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:5: warning: function declaration isn't a prototype >> success! >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:1: warning: conflicting types for built-in function 'exp' >> gcc -m32 -pthread _configtest.o -o _configtest >> _configtest.o(.text+0x19): In function `main': >> /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' >> collect2: ld returned 1 exit status >> _configtest.o(.text+0x19): In function `main': >> /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' >> collect2: ld returned 1 exit status >> failure. >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:1: warning: conflicting types for built-in function 'exp' >> gcc -m32 -pthread _configtest.o -lm -o _configtest >> success! >> removing: _configtest.c _configtest.o _configtest >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:1: warning: conflicting types for built-in function 'asin' >> _configtest.c:2: warning: conflicting types for built-in function 'cos' >> _configtest.c:3: warning: conflicting types for built-in function 'log' >> _configtest.c:4: warning: conflicting types for built-in function 'fabs' >> _configtest.c:5: warning: conflicting types for built-in function 'tanh' >> _configtest.c:6: warning: conflicting types for built-in function 'atan' >> _configtest.c:7: warning: conflicting types for built-in function 'acos' >> _configtest.c:8: warning: conflicting types for built-in function 'floor' >> _configtest.c:9: warning: conflicting types for built-in function 'fmod' >> _configtest.c:10: warning: conflicting types for built-in function 'sqrt' >> _configtest.c:11: warning: conflicting types for built-in function 'cosh' >> _configtest.c:12: warning: conflicting types for built-in function 'modf' >> _configtest.c:13: warning: conflicting types for built-in function 'sinh' >> _configtest.c:14: warning: conflicting types for built-in function 'frexp' >> _configtest.c:15: warning: conflicting types for built-in function 'exp' >> _configtest.c:16: warning: conflicting types for built-in function 'tan' >> _configtest.c:17: warning: conflicting types for built-in function 'ceil' >> _configtest.c:18: warning: conflicting types for built-in function 'log10' >> _configtest.c:19: warning: conflicting types for built-in function 'sin' >> _configtest.c:20: warning: conflicting types for built-in function 'ldexp' >> gcc -m32 -pthread _configtest.o -lm -o _configtest >> success! >> removing: _configtest.c _configtest.o _configtest >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:1: warning: conflicting types for built-in function 'expm1' >> _configtest.c:2: warning: conflicting types for built-in function 'log2' >> _configtest.c:3: warning: conflicting types for built-in function 'pow' >> _configtest.c:4: warning: conflicting types for built-in function 'rint' >> _configtest.c:5: warning: conflicting types for built-in function 'atanh' >> _configtest.c:6: warning: conflicting types for built-in function 'copysign' >> _configtest.c:7: warning: conflicting types for built-in function 'asinh' >> _configtest.c:8: warning: conflicting types for built-in function 'atan2' >> _configtest.c:9: warning: conflicting types for built-in function 'hypot' >> _configtest.c:10: warning: conflicting types for built-in function 'acosh' >> _configtest.c:11: warning: conflicting types for built-in function 'exp2' >> _configtest.c:12: warning: conflicting types for built-in function 'log1p' >> _configtest.c:13: warning: conflicting types for built-in function 'nextafter' >> _configtest.c:14: warning: conflicting types for built-in function 'trunc' >> gcc -m32 -pthread _configtest.o -lm -o _configtest >> success! >> removing: _configtest.c _configtest.o _configtest >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:1: warning: conflicting types for built-in function 'cosf' >> _configtest.c:2: warning: conflicting types for built-in function 'coshf' >> _configtest.c:3: warning: conflicting types for built-in function 'rintf' >> _configtest.c:4: warning: conflicting types for built-in function 'fabsf' >> _configtest.c:5: warning: conflicting types for built-in function 'floorf' >> _configtest.c:6: warning: conflicting types for built-in function 'nextafterf' >> _configtest.c:7: warning: conflicting types for built-in function 'tanhf' >> _configtest.c:8: warning: conflicting types for built-in function 'log10f' >> _configtest.c:9: warning: conflicting types for built-in function 'logf' >> _configtest.c:10: warning: conflicting types for built-in function 'sinhf' >> _configtest.c:11: warning: conflicting types for built-in function 'acosf' >> _configtest.c:12: warning: conflicting types for built-in function 'sqrtf' >> _configtest.c:13: warning: conflicting types for built-in function 'ldexpf' >> _configtest.c:14: warning: conflicting types for built-in function 'hypotf' >> _configtest.c:15: warning: conflicting types for built-in function 'log2f' >> _configtest.c:16: warning: conflicting types for built-in function 'exp2f' >> _configtest.c:17: warning: conflicting types for built-in function 'atanf' >> _configtest.c:18: warning: conflicting types for built-in function 'fmodf' >> _configtest.c:19: warning: conflicting types for built-in function 'atan2f' >> _configtest.c:20: warning: conflicting types for built-in function 'modff' >> _configtest.c:21: warning: conflicting types for built-in function 'ceilf' >> _configtest.c:22: warning: conflicting types for built-in function 'log1pf' >> _configtest.c:23: warning: conflicting types for built-in function 'asinf' >> _configtest.c:24: warning: conflicting types for built-in function 'copysignf' >> _configtest.c:25: warning: conflicting types for built-in function 'acoshf' >> _configtest.c:26: warning: conflicting types for built-in function 'sinf' >> _configtest.c:27: warning: conflicting types for built-in function 'tanf' >> _configtest.c:28: warning: conflicting types for built-in function 'atanhf' >> _configtest.c:29: warning: conflicting types for built-in function 'truncf' >> _configtest.c:30: warning: conflicting types for built-in function 'asinhf' >> _configtest.c:31: warning: conflicting types for built-in function 'frexpf' >> _configtest.c:32: warning: conflicting types for built-in function 'powf' >> _configtest.c:33: warning: conflicting types for built-in function 'expf' >> _configtest.c:34: warning: conflicting types for built-in function 'expm1f' >> gcc -m32 -pthread _configtest.o -lm -o _configtest >> success! >> removing: _configtest.c _configtest.o _configtest >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:1: warning: conflicting types for built-in function 'tanhl' >> _configtest.c:2: warning: conflicting types for built-in function 'log10l' >> _configtest.c:3: warning: conflicting types for built-in function 'nextafterl' >> _configtest.c:4: warning: conflicting types for built-in function 'coshl' >> _configtest.c:5: warning: conflicting types for built-in function 'cosl' >> _configtest.c:6: warning: conflicting types for built-in function 'floorl' >> _configtest.c:7: warning: conflicting types for built-in function 'rintl' >> _configtest.c:8: warning: conflicting types for built-in function 'fabsl' >> _configtest.c:9: warning: conflicting types for built-in function 'acosl' >> _configtest.c:10: warning: conflicting types for built-in function 'ldexpl' >> _configtest.c:11: warning: conflicting types for built-in function 'sqrtl' >> _configtest.c:12: warning: conflicting types for built-in function 'logl' >> _configtest.c:13: warning: conflicting types for built-in function 'expm1l' >> _configtest.c:14: warning: conflicting types for built-in function 'hypotl' >> _configtest.c:15: warning: conflicting types for built-in function 'log2l' >> _configtest.c:16: warning: conflicting types for built-in function 'copysignl' >> _configtest.c:17: warning: conflicting types for built-in function 'exp2l' >> _configtest.c:18: warning: conflicting types for built-in function 'atanl' >> _configtest.c:19: warning: conflicting types for built-in function 'frexpl' >> _configtest.c:20: warning: conflicting types for built-in function 'atan2l' >> _configtest.c:21: warning: conflicting types for built-in function 'sinhl' >> _configtest.c:22: warning: conflicting types for built-in function 'fmodl' >> _configtest.c:23: warning: conflicting types for built-in function 'log1pl' >> _configtest.c:24: warning: conflicting types for built-in function 'asinl' >> _configtest.c:25: warning: conflicting types for built-in function 'ceill' >> _configtest.c:26: warning: conflicting types for built-in function 'sinl' >> _configtest.c:27: warning: conflicting types for built-in function 'acoshl' >> _configtest.c:28: warning: conflicting types for built-in function 'atanhl' >> _configtest.c:29: warning: conflicting types for built-in function 'tanl' >> _configtest.c:30: warning: conflicting types for built-in function 'truncl' >> _configtest.c:31: warning: conflicting types for built-in function 'powl' >> _configtest.c:32: warning: conflicting types for built-in function 'expl' >> _configtest.c:33: warning: conflicting types for built-in function 'modfl' >> _configtest.c:34: warning: conflicting types for built-in function 'asinhl' >> gcc -m32 -pthread _configtest.o -lm -o _configtest >> success! >> removing: _configtest.c _configtest.o _configtest >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:6: warning: function declaration isn't a prototype >> success! >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:6: warning: function declaration isn't a prototype >> success! >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:6: warning: function declaration isn't a prototype >> success! >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:6: warning: function declaration isn't a prototype >> success! >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> success! >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:1: warning: conflicting types for built-in function 'cexp' >> _configtest.c:3: warning: conflicting types for built-in function 'ccos' >> _configtest.c:4: warning: conflicting types for built-in function 'cimag' >> _configtest.c:5: warning: conflicting types for built-in function 'cabs' >> _configtest.c:6: warning: conflicting types for built-in function 'cpow' >> _configtest.c:7: warning: conflicting types for built-in function 'csqrt' >> _configtest.c:8: warning: conflicting types for built-in function 'carg' >> _configtest.c:9: warning: conflicting types for built-in function 'creal' >> _configtest.c:10: warning: conflicting types for built-in function 'csin' >> gcc -m32 -pthread _configtest.o -lm -o _configtest >> success! >> removing: _configtest.c _configtest.o _configtest >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:1: warning: conflicting types for built-in function 'ccosf' >> _configtest.c:2: warning: conflicting types for built-in function 'cargf' >> _configtest.c:3: warning: conflicting types for built-in function 'csqrtf' >> _configtest.c:4: warning: conflicting types for built-in function 'cpowf' >> _configtest.c:5: warning: conflicting types for built-in function 'cexpf' >> _configtest.c:6: warning: conflicting types for built-in function 'crealf' >> _configtest.c:7: warning: conflicting types for built-in function 'csinf' >> _configtest.c:8: warning: conflicting types for built-in function 'cabsf' >> _configtest.c:10: warning: conflicting types for built-in function 'cimagf' >> gcc -m32 -pthread _configtest.o -lm -o _configtest >> success! >> removing: _configtest.c _configtest.o _configtest >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:1: warning: conflicting types for built-in function 'csqrtl' >> _configtest.c:2: warning: conflicting types for built-in function 'cargl' >> _configtest.c:3: warning: conflicting types for built-in function 'cexpl' >> _configtest.c:4: warning: conflicting types for built-in function 'ccosl' >> _configtest.c:5: warning: conflicting types for built-in function 'cpowl' >> _configtest.c:6: warning: conflicting types for built-in function 'cimagl' >> _configtest.c:7: warning: conflicting types for built-in function 'csinl' >> _configtest.c:8: warning: conflicting types for built-in function 'creall' >> _configtest.c:10: warning: conflicting types for built-in function 'cabsl' >> gcc -m32 -pthread _configtest.o -lm -o _configtest >> success! >> removing: _configtest.c _configtest.o _configtest >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> success! >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:5: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:7: error: `Py_UNICODE_WIDE' undeclared (first use in >> this function) >> _configtest.c:7: error: (Each undeclared identifier is reported only once >> _configtest.c:7: error: for each function it appears in.) >> _configtest.c:5: warning: function declaration isn't a prototype >> _configtest.c: In function `main': >> _configtest.c:7: error: `Py_UNICODE_WIDE' undeclared (first use in >> this function) >> _configtest.c:7: error: (Each undeclared identifier is reported only once >> _configtest.c:7: error: for each function it appears in.) >> failure. >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> removing: _configtest.c _configtest.o >> ('File:', 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h') >> #define HAVE_ENDIAN_H 1 >> #define SIZEOF_PY_INTPTR_T 4 >> #define SIZEOF_PY_LONG_LONG 8 >> #define MATHLIB m >> #define HAVE_SIN >> #define HAVE_COS >> #define HAVE_TAN >> #define HAVE_SINH >> #define HAVE_COSH >> #define HAVE_TANH >> #define HAVE_FABS >> #define HAVE_FLOOR >> #define HAVE_CEIL >> #define HAVE_SQRT >> #define HAVE_LOG10 >> #define HAVE_LOG >> #define HAVE_EXP >> #define HAVE_ASIN >> #define HAVE_ACOS >> #define HAVE_ATAN >> #define HAVE_FMOD >> #define HAVE_MODF >> #define HAVE_FREXP >> #define HAVE_LDEXP >> #define HAVE_EXPM1 >> #define HAVE_LOG1P >> #define HAVE_ACOSH >> #define HAVE_ASINH >> #define HAVE_ATANH >> #define HAVE_RINT >> #define HAVE_TRUNC >> #define HAVE_EXP2 >> #define HAVE_LOG2 >> #define HAVE_HYPOT >> #define HAVE_ATAN2 >> #define HAVE_POW >> #define HAVE_COPYSIGN >> #define HAVE_NEXTAFTER >> #define HAVE_SINF >> #define HAVE_COSF >> #define HAVE_TANF >> #define HAVE_SINHF >> #define HAVE_COSHF >> #define HAVE_TANHF >> #define HAVE_FABSF >> #define HAVE_FLOORF >> #define HAVE_CEILF >> #define HAVE_RINTF >> #define HAVE_TRUNCF >> #define HAVE_SQRTF >> #define HAVE_LOG10F >> #define HAVE_LOGF >> #define HAVE_LOG1PF >> #define HAVE_EXPF >> #define HAVE_EXPM1F >> #define HAVE_ASINF >> #define HAVE_ACOSF >> #define HAVE_ATANF >> #define HAVE_ASINHF >> #define HAVE_ACOSHF >> #define HAVE_ATANHF >> #define HAVE_HYPOTF >> #define HAVE_ATAN2F >> #define HAVE_POWF >> #define HAVE_FMODF >> #define HAVE_MODFF >> #define HAVE_FREXPF >> #define HAVE_LDEXPF >> #define HAVE_EXP2F >> #define HAVE_LOG2F >> #define HAVE_COPYSIGNF >> #define HAVE_NEXTAFTERF >> #define HAVE_SINL >> #define HAVE_COSL >> #define HAVE_TANL >> #define HAVE_SINHL >> #define HAVE_COSHL >> #define HAVE_TANHL >> #define HAVE_FABSL >> #define HAVE_FLOORL >> #define HAVE_CEILL >> #define HAVE_RINTL >> #define HAVE_TRUNCL >> #define HAVE_SQRTL >> #define HAVE_LOG10L >> #define HAVE_LOGL >> #define HAVE_LOG1PL >> #define HAVE_EXPL >> #define HAVE_EXPM1L >> #define HAVE_ASINL >> #define HAVE_ACOSL >> #define HAVE_ATANL >> #define HAVE_ASINHL >> #define HAVE_ACOSHL >> #define HAVE_ATANHL >> #define HAVE_HYPOTL >> #define HAVE_ATAN2L >> #define HAVE_POWL >> #define HAVE_FMODL >> #define HAVE_MODFL >> #define HAVE_FREXPL >> #define HAVE_LDEXPL >> #define HAVE_EXP2L >> #define HAVE_LOG2L >> #define HAVE_COPYSIGNL >> #define HAVE_NEXTAFTERL >> #define HAVE_DECL_ISNAN >> #define HAVE_DECL_ISINF >> #define HAVE_DECL_SIGNBIT >> #define HAVE_DECL_ISFINITE >> #define HAVE_COMPLEX_H >> #define HAVE_CREAL >> #define HAVE_CIMAG >> #define HAVE_CABS >> #define HAVE_CARG >> #define HAVE_CEXP >> #define HAVE_CSQRT >> #define HAVE_CLOG >> #define HAVE_CCOS >> #define HAVE_CSIN >> #define HAVE_CPOW >> #define HAVE_CREALF >> #define HAVE_CIMAGF >> #define HAVE_CABSF >> #define HAVE_CARGF >> #define HAVE_CEXPF >> #define HAVE_CSQRTF >> #define HAVE_CLOGF >> #define HAVE_CCOSF >> #define HAVE_CSINF >> #define HAVE_CPOWF >> #define HAVE_CREALL >> #define HAVE_CIMAGL >> #define HAVE_CABSL >> #define HAVE_CARGL >> #define HAVE_CEXPL >> #define HAVE_CSQRTL >> #define HAVE_CLOGL >> #define HAVE_CCOSL >> #define HAVE_CSINL >> #define HAVE_CPOWL >> #define HAVE_LDOUBLE_INTEL_EXTENDED_12_BYTES_LE 1 >> #ifndef __cplusplus >> /* #undef inline */ >> #endif >> >> #ifndef _NPY_NPY_CONFIG_H_ >> #error config.h should never be included directly, include npy_config.h instead >> #endif >> >> EOF >> ? ?adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' >> to sources. >> Generating build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:1: warning: conflicting types for built-in function 'exp' >> gcc -m32 -pthread _configtest.o -o _configtest >> _configtest.o(.text+0x19): In function `main': >> /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' >> collect2: ld returned 1 exit status >> _configtest.o(.text+0x19): In function `main': >> /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' >> collect2: ld returned 1 exit status >> failure. >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:1: warning: conflicting types for built-in function 'exp' >> gcc -m32 -pthread _configtest.o -lm -o _configtest >> success! >> removing: _configtest.c _configtest.o _configtest >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:5: warning: function declaration isn't a prototype >> success! >> removing: _configtest.c _configtest.o >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> _configtest.c:4: warning: function declaration isn't a prototype >> _configtest.c:5:18: warning: extra tokens at end of #ifndef directive >> _configtest.c: In function `main': >> _configtest.c:4: warning: control reaches end of non-void function >> success! >> removing: _configtest.c _configtest.o >> File: build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h >> #define NPY_HAVE_ENDIAN_H 1 >> #define NPY_SIZEOF_SHORT SIZEOF_SHORT >> #define NPY_SIZEOF_INT SIZEOF_INT >> #define NPY_SIZEOF_LONG SIZEOF_LONG >> #define NPY_SIZEOF_FLOAT 4 >> #define NPY_SIZEOF_COMPLEX_FLOAT 8 >> #define NPY_SIZEOF_DOUBLE 8 >> #define NPY_SIZEOF_COMPLEX_DOUBLE 16 >> #define NPY_SIZEOF_LONGDOUBLE 12 >> #define NPY_SIZEOF_COMPLEX_LONGDOUBLE 24 >> #define NPY_SIZEOF_PY_INTPTR_T 4 >> #define NPY_SIZEOF_PY_LONG_LONG 8 >> #define NPY_SIZEOF_LONGLONG 8 >> #define NPY_NO_SMP 1 >> #define NPY_HAVE_DECL_ISNAN >> #define NPY_HAVE_DECL_ISINF >> #define NPY_HAVE_DECL_SIGNBIT >> #define NPY_HAVE_DECL_ISFINITE >> #define NPY_USE_C99_COMPLEX >> #define NPY_HAVE_COMPLEX_DOUBLE 1 >> #define NPY_HAVE_COMPLEX_FLOAT 1 >> #define NPY_HAVE_COMPLEX_LONG_DOUBLE 1 >> #define NPY_USE_C99_FORMATS 1 >> #define NPY_VISIBILITY_HIDDEN __attribute__((visibility("hidden"))) >> #define NPY_ABI_VERSION 0x01000009 >> #define NPY_API_VERSION 0x00000004 >> >> #ifndef __STDC_FORMAT_MACROS >> #define __STDC_FORMAT_MACROS 1 >> #endif >> >> EOF >> ? ?adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' >> to sources. >> executing numpy/core/code_generators/generate_numpy_api.py >> ? ?adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__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/include/numpy/config.h', >> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', >> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h'] >> building extension "numpy.core.multiarray" sources >> non-existing path in 'numpy/core': >> 'build/src.linux-x86_64-2.4/numpy/core/src/multiarray' >> creating build/src.linux-x86_64-2.4/numpy/core/src/multiarray >> conv_template:> >> build/src.linux-x86_64-2.4/numpy/core/src/multiarray/scalartypes.c >> conv_template:> >> build/src.linux-x86_64-2.4/numpy/core/src/multiarray/arraytypes.c >> ? ?adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' >> to sources. >> ? ?adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' >> to sources. >> executing numpy/core/code_generators/generate_numpy_api.py >> ? ?adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h' >> to sources. >> numpy.core - nothing done with h_files = >> ['build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h', >> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', >> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h'] >> building extension "numpy.core.umath" sources >> ? ?adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' >> to sources. >> ? ?adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' >> to sources. >> executing numpy/core/code_generators/generate_ufunc_api.py >> ? ?adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__ufunc_api.h' >> to sources. >> non-existing path in 'numpy/core': >> 'build/src.linux-x86_64-2.4/numpy/core/src/umath' >> creating build/src.linux-x86_64-2.4/numpy/core/src/umath >> conv_template:> ?build/src.linux-x86_64-2.4/numpy/core/src/umath/loops.c >> conv_template:> ?build/src.linux-x86_64-2.4/numpy/core/src/umath/umathmodule.c >> conv_template:> ?build/src.linux-x86_64-2.4/numpy/core/src/umath/funcs.inc >> ? ?adding 'build/src.linux-x86_64-2.4/numpy/core/src/umath' to include_dirs. >> numpy.core - nothing done with h_files = >> ['build/src.linux-x86_64-2.4/numpy/core/src/umath/funcs.inc', >> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h', >> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', >> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__ufunc_api.h'] >> building extension "numpy.core.scalarmath" sources >> ? ?adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' >> to sources. >> ? ?adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' >> to sources. >> executing numpy/core/code_generators/generate_numpy_api.py >> ? ?adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h' >> to sources. >> executing numpy/core/code_generators/generate_ufunc_api.py >> ? ?adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__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/include/numpy/config.h', >> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', >> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h', >> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__ufunc_api.h'] >> building extension "numpy.core._dotblas" sources >> building extension "numpy.core.umath_tests" sources >> conv_template:> ?build/src.linux-x86_64-2.4/numpy/core/src/umath/umath_tests.c >> building extension "numpy.core.multiarray_tests" sources >> conv_template:> >> build/src.linux-x86_64-2.4/numpy/core/src/multiarray/multiarray_tests.c >> building extension "numpy.lib._compiled_base" sources >> building extension "numpy.numarray._capi" sources >> building extension "numpy.fft.fftpack_lite" sources >> building extension "numpy.linalg.lapack_lite" sources >> creating build/src.linux-x86_64-2.4/numpy/linalg >> ? ?adding 'numpy/linalg/lapack_litemodule.c' to sources. >> ? ?adding 'numpy/linalg/python_xerbla.c' to sources. >> building extension "numpy.random.mtrand" sources >> creating build/src.linux-x86_64-2.4/numpy/random >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/src/private -Inumpy/core/src >> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 -c' >> gcc: _configtest.c >> gcc -m32 -pthread _configtest.o -o _configtest >> _configtest >> failure. >> removing: _configtest.c _configtest.o _configtest >> building data_files sources >> build_src: building npy-pkg config files >> running build_py >> creating build/lib.linux-x86_64-2.4 >> creating build/lib.linux-x86_64-2.4/numpy >> copying numpy/version.py -> ?build/lib.linux-x86_64-2.4/numpy >> copying numpy/matlib.py -> ?build/lib.linux-x86_64-2.4/numpy >> copying numpy/ctypeslib.py -> ?build/lib.linux-x86_64-2.4/numpy >> copying numpy/setupscons.py -> ?build/lib.linux-x86_64-2.4/numpy >> copying numpy/__init__.py -> ?build/lib.linux-x86_64-2.4/numpy >> copying numpy/setup.py -> ?build/lib.linux-x86_64-2.4/numpy >> copying numpy/dual.py -> ?build/lib.linux-x86_64-2.4/numpy >> copying numpy/_import_tools.py -> ?build/lib.linux-x86_64-2.4/numpy >> copying numpy/add_newdocs.py -> ?build/lib.linux-x86_64-2.4/numpy >> copying build/src.linux-x86_64-2.4/numpy/__config__.py -> >> build/lib.linux-x86_64-2.4/numpy >> creating build/lib.linux-x86_64-2.4/numpy/distutils >> copying numpy/distutils/from_template.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils >> copying numpy/distutils/npy_pkg_config.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils >> copying numpy/distutils/compat.py -> ?build/lib.linux-x86_64-2.4/numpy/distutils >> copying numpy/distutils/setupscons.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils >> copying numpy/distutils/__init__.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils >> copying numpy/distutils/lib2def.py -> ?build/lib.linux-x86_64-2.4/numpy/distutils >> copying numpy/distutils/interactive.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils >> copying numpy/distutils/info.py -> ?build/lib.linux-x86_64-2.4/numpy/distutils >> copying numpy/distutils/environment.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils >> copying numpy/distutils/setup.py -> ?build/lib.linux-x86_64-2.4/numpy/distutils >> copying numpy/distutils/cpuinfo.py -> ?build/lib.linux-x86_64-2.4/numpy/distutils >> copying numpy/distutils/extension.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils >> copying numpy/distutils/core.py -> ?build/lib.linux-x86_64-2.4/numpy/distutils >> copying numpy/distutils/intelccompiler.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils >> copying numpy/distutils/log.py -> ?build/lib.linux-x86_64-2.4/numpy/distutils >> copying numpy/distutils/__version__.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils >> copying numpy/distutils/unixccompiler.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils >> copying numpy/distutils/misc_util.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils >> copying numpy/distutils/line_endings.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils >> copying numpy/distutils/exec_command.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils >> copying numpy/distutils/conv_template.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils >> copying numpy/distutils/ccompiler.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils >> copying numpy/distutils/mingw32ccompiler.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils >> copying numpy/distutils/system_info.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils >> copying numpy/distutils/numpy_distribution.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils >> copying build/src.linux-x86_64-2.4/numpy/distutils/__config__.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils >> creating build/lib.linux-x86_64-2.4/numpy/distutils/command >> copying numpy/distutils/command/install.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/command >> copying numpy/distutils/command/egg_info.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/command >> copying numpy/distutils/command/install_clib.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/command >> copying numpy/distutils/command/bdist_rpm.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/command >> copying numpy/distutils/command/develop.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/command >> copying numpy/distutils/command/install_data.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/command >> copying numpy/distutils/command/__init__.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/command >> copying numpy/distutils/command/build_py.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/command >> copying numpy/distutils/command/build_src.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/command >> copying numpy/distutils/command/build_clib.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/command >> copying numpy/distutils/command/build_ext.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/command >> copying numpy/distutils/command/autodist.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/command >> copying numpy/distutils/command/install_headers.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/command >> copying numpy/distutils/command/config.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/command >> copying numpy/distutils/command/config_compiler.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/command >> copying numpy/distutils/command/build.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/command >> copying numpy/distutils/command/build_scripts.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/command >> copying numpy/distutils/command/sdist.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/command >> copying numpy/distutils/command/scons.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/command >> creating build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >> copying numpy/distutils/fcompiler/none.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >> copying numpy/distutils/fcompiler/hpux.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >> copying numpy/distutils/fcompiler/compaq.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >> copying numpy/distutils/fcompiler/absoft.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >> copying numpy/distutils/fcompiler/vast.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >> copying numpy/distutils/fcompiler/nag.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >> copying numpy/distutils/fcompiler/__init__.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >> copying numpy/distutils/fcompiler/sun.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >> copying numpy/distutils/fcompiler/mips.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >> copying numpy/distutils/fcompiler/intel.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >> copying numpy/distutils/fcompiler/gnu.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >> copying numpy/distutils/fcompiler/g95.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >> copying numpy/distutils/fcompiler/pg.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >> copying numpy/distutils/fcompiler/ibm.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >> copying numpy/distutils/fcompiler/lahey.py -> >> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >> creating build/lib.linux-x86_64-2.4/numpy/testing >> copying numpy/testing/nulltester.py -> ?build/lib.linux-x86_64-2.4/numpy/testing >> copying numpy/testing/setupscons.py -> ?build/lib.linux-x86_64-2.4/numpy/testing >> copying numpy/testing/__init__.py -> ?build/lib.linux-x86_64-2.4/numpy/testing >> copying numpy/testing/setup.py -> ?build/lib.linux-x86_64-2.4/numpy/testing >> copying numpy/testing/decorators.py -> ?build/lib.linux-x86_64-2.4/numpy/testing >> copying numpy/testing/utils.py -> ?build/lib.linux-x86_64-2.4/numpy/testing >> copying numpy/testing/noseclasses.py -> ?build/lib.linux-x86_64-2.4/numpy/testing >> copying numpy/testing/numpytest.py -> ?build/lib.linux-x86_64-2.4/numpy/testing >> copying numpy/testing/nosetester.py -> ?build/lib.linux-x86_64-2.4/numpy/testing >> creating build/lib.linux-x86_64-2.4/numpy/f2py >> copying numpy/f2py/auxfuncs.py -> ?build/lib.linux-x86_64-2.4/numpy/f2py >> copying numpy/f2py/common_rules.py -> ?build/lib.linux-x86_64-2.4/numpy/f2py >> copying numpy/f2py/setupscons.py -> ?build/lib.linux-x86_64-2.4/numpy/f2py >> copying numpy/f2py/__init__.py -> ?build/lib.linux-x86_64-2.4/numpy/f2py >> copying numpy/f2py/cb_rules.py -> ?build/lib.linux-x86_64-2.4/numpy/f2py >> copying numpy/f2py/info.py -> ?build/lib.linux-x86_64-2.4/numpy/f2py >> copying numpy/f2py/setup.py -> ?build/lib.linux-x86_64-2.4/numpy/f2py >> copying numpy/f2py/f2py2e.py -> ?build/lib.linux-x86_64-2.4/numpy/f2py >> copying numpy/f2py/cfuncs.py -> ?build/lib.linux-x86_64-2.4/numpy/f2py >> copying numpy/f2py/crackfortran.py -> ?build/lib.linux-x86_64-2.4/numpy/f2py >> copying numpy/f2py/use_rules.py -> ?build/lib.linux-x86_64-2.4/numpy/f2py >> copying numpy/f2py/diagnose.py -> ?build/lib.linux-x86_64-2.4/numpy/f2py >> copying numpy/f2py/f2py_testing.py -> ?build/lib.linux-x86_64-2.4/numpy/f2py >> copying numpy/f2py/__version__.py -> ?build/lib.linux-x86_64-2.4/numpy/f2py >> copying numpy/f2py/capi_maps.py -> ?build/lib.linux-x86_64-2.4/numpy/f2py >> copying numpy/f2py/func2subr.py -> ?build/lib.linux-x86_64-2.4/numpy/f2py >> copying numpy/f2py/f90mod_rules.py -> ?build/lib.linux-x86_64-2.4/numpy/f2py >> copying numpy/f2py/rules.py -> ?build/lib.linux-x86_64-2.4/numpy/f2py >> creating build/lib.linux-x86_64-2.4/numpy/core >> copying numpy/core/defchararray.py -> ?build/lib.linux-x86_64-2.4/numpy/core >> copying numpy/core/numeric.py -> ?build/lib.linux-x86_64-2.4/numpy/core >> copying numpy/core/setupscons.py -> ?build/lib.linux-x86_64-2.4/numpy/core >> copying numpy/core/__init__.py -> ?build/lib.linux-x86_64-2.4/numpy/core >> copying numpy/core/info.py -> ?build/lib.linux-x86_64-2.4/numpy/core >> copying numpy/core/function_base.py -> ?build/lib.linux-x86_64-2.4/numpy/core >> copying numpy/core/getlimits.py -> ?build/lib.linux-x86_64-2.4/numpy/core >> copying numpy/core/setup.py -> ?build/lib.linux-x86_64-2.4/numpy/core >> copying numpy/core/fromnumeric.py -> ?build/lib.linux-x86_64-2.4/numpy/core >> copying numpy/core/shape_base.py -> ?build/lib.linux-x86_64-2.4/numpy/core >> copying numpy/core/setup_common.py -> ?build/lib.linux-x86_64-2.4/numpy/core >> copying numpy/core/records.py -> ?build/lib.linux-x86_64-2.4/numpy/core >> copying numpy/core/memmap.py -> ?build/lib.linux-x86_64-2.4/numpy/core >> copying numpy/core/arrayprint.py -> ?build/lib.linux-x86_64-2.4/numpy/core >> copying numpy/core/numerictypes.py -> ?build/lib.linux-x86_64-2.4/numpy/core >> copying numpy/core/machar.py -> ?build/lib.linux-x86_64-2.4/numpy/core >> copying numpy/core/_mx_datetime_parser.py -> >> build/lib.linux-x86_64-2.4/numpy/core >> copying numpy/core/scons_support.py -> ?build/lib.linux-x86_64-2.4/numpy/core >> copying numpy/core/_internal.py -> ?build/lib.linux-x86_64-2.4/numpy/core >> copying numpy/core/code_generators/generate_numpy_api.py -> >> build/lib.linux-x86_64-2.4/numpy/core >> creating build/lib.linux-x86_64-2.4/numpy/lib >> copying numpy/lib/_datasource.py -> ?build/lib.linux-x86_64-2.4/numpy/lib >> copying numpy/lib/arraysetops.py -> ?build/lib.linux-x86_64-2.4/numpy/lib >> copying numpy/lib/index_tricks.py -> ?build/lib.linux-x86_64-2.4/numpy/lib >> copying numpy/lib/format.py -> ?build/lib.linux-x86_64-2.4/numpy/lib >> copying numpy/lib/setupscons.py -> ?build/lib.linux-x86_64-2.4/numpy/lib >> copying numpy/lib/__init__.py -> ?build/lib.linux-x86_64-2.4/numpy/lib >> copying numpy/lib/info.py -> ?build/lib.linux-x86_64-2.4/numpy/lib >> copying numpy/lib/function_base.py -> ?build/lib.linux-x86_64-2.4/numpy/lib >> copying numpy/lib/setup.py -> ?build/lib.linux-x86_64-2.4/numpy/lib >> copying numpy/lib/arrayterator.py -> ?build/lib.linux-x86_64-2.4/numpy/lib >> copying numpy/lib/ufunclike.py -> ?build/lib.linux-x86_64-2.4/numpy/lib >> copying numpy/lib/shape_base.py -> ?build/lib.linux-x86_64-2.4/numpy/lib >> copying numpy/lib/user_array.py -> ?build/lib.linux-x86_64-2.4/numpy/lib >> copying numpy/lib/type_check.py -> ?build/lib.linux-x86_64-2.4/numpy/lib >> copying numpy/lib/stride_tricks.py -> ?build/lib.linux-x86_64-2.4/numpy/lib >> copying numpy/lib/recfunctions.py -> ?build/lib.linux-x86_64-2.4/numpy/lib >> copying numpy/lib/npyio.py -> ?build/lib.linux-x86_64-2.4/numpy/lib >> copying numpy/lib/_iotools.py -> ?build/lib.linux-x86_64-2.4/numpy/lib >> copying numpy/lib/utils.py -> ?build/lib.linux-x86_64-2.4/numpy/lib >> copying numpy/lib/financial.py -> ?build/lib.linux-x86_64-2.4/numpy/lib >> copying numpy/lib/twodim_base.py -> ?build/lib.linux-x86_64-2.4/numpy/lib >> copying numpy/lib/polynomial.py -> ?build/lib.linux-x86_64-2.4/numpy/lib >> copying numpy/lib/scimath.py -> ?build/lib.linux-x86_64-2.4/numpy/lib >> creating build/lib.linux-x86_64-2.4/numpy/oldnumeric >> copying numpy/oldnumeric/functions.py -> >> build/lib.linux-x86_64-2.4/numpy/oldnumeric >> copying numpy/oldnumeric/alter_code1.py -> >> build/lib.linux-x86_64-2.4/numpy/oldnumeric >> copying numpy/oldnumeric/misc.py -> ?build/lib.linux-x86_64-2.4/numpy/oldnumeric >> copying numpy/oldnumeric/compat.py -> >> build/lib.linux-x86_64-2.4/numpy/oldnumeric >> copying numpy/oldnumeric/setupscons.py -> >> build/lib.linux-x86_64-2.4/numpy/oldnumeric >> copying numpy/oldnumeric/__init__.py -> >> build/lib.linux-x86_64-2.4/numpy/oldnumeric >> copying numpy/oldnumeric/linear_algebra.py -> >> build/lib.linux-x86_64-2.4/numpy/oldnumeric >> copying numpy/oldnumeric/setup.py -> ?build/lib.linux-x86_64-2.4/numpy/oldnumeric >> copying numpy/oldnumeric/random_array.py -> >> build/lib.linux-x86_64-2.4/numpy/oldnumeric >> copying numpy/oldnumeric/user_array.py -> >> build/lib.linux-x86_64-2.4/numpy/oldnumeric >> copying numpy/oldnumeric/alter_code2.py -> >> build/lib.linux-x86_64-2.4/numpy/oldnumeric >> copying numpy/oldnumeric/fft.py -> ?build/lib.linux-x86_64-2.4/numpy/oldnumeric >> copying numpy/oldnumeric/matrix.py -> >> build/lib.linux-x86_64-2.4/numpy/oldnumeric >> copying numpy/oldnumeric/fix_default_axis.py -> >> build/lib.linux-x86_64-2.4/numpy/oldnumeric >> copying numpy/oldnumeric/rng_stats.py -> >> build/lib.linux-x86_64-2.4/numpy/oldnumeric >> copying numpy/oldnumeric/mlab.py -> ?build/lib.linux-x86_64-2.4/numpy/oldnumeric >> copying numpy/oldnumeric/ma.py -> ?build/lib.linux-x86_64-2.4/numpy/oldnumeric >> copying numpy/oldnumeric/ufuncs.py -> >> build/lib.linux-x86_64-2.4/numpy/oldnumeric >> copying numpy/oldnumeric/rng.py -> ?build/lib.linux-x86_64-2.4/numpy/oldnumeric >> copying numpy/oldnumeric/array_printer.py -> >> build/lib.linux-x86_64-2.4/numpy/oldnumeric >> copying numpy/oldnumeric/typeconv.py -> >> build/lib.linux-x86_64-2.4/numpy/oldnumeric >> copying numpy/oldnumeric/precision.py -> >> build/lib.linux-x86_64-2.4/numpy/oldnumeric >> copying numpy/oldnumeric/arrayfns.py -> >> build/lib.linux-x86_64-2.4/numpy/oldnumeric >> creating build/lib.linux-x86_64-2.4/numpy/numarray >> copying numpy/numarray/nd_image.py -> ?build/lib.linux-x86_64-2.4/numpy/numarray >> copying numpy/numarray/util.py -> ?build/lib.linux-x86_64-2.4/numpy/numarray >> copying numpy/numarray/convolve.py -> ?build/lib.linux-x86_64-2.4/numpy/numarray >> copying numpy/numarray/functions.py -> ?build/lib.linux-x86_64-2.4/numpy/numarray >> copying numpy/numarray/alter_code1.py -> >> build/lib.linux-x86_64-2.4/numpy/numarray >> copying numpy/numarray/compat.py -> ?build/lib.linux-x86_64-2.4/numpy/numarray >> copying numpy/numarray/setupscons.py -> >> build/lib.linux-x86_64-2.4/numpy/numarray >> copying numpy/numarray/__init__.py -> ?build/lib.linux-x86_64-2.4/numpy/numarray >> copying numpy/numarray/linear_algebra.py -> >> build/lib.linux-x86_64-2.4/numpy/numarray >> copying numpy/numarray/setup.py -> ?build/lib.linux-x86_64-2.4/numpy/numarray >> copying numpy/numarray/random_array.py -> >> build/lib.linux-x86_64-2.4/numpy/numarray >> copying numpy/numarray/alter_code2.py -> >> build/lib.linux-x86_64-2.4/numpy/numarray >> copying numpy/numarray/fft.py -> ?build/lib.linux-x86_64-2.4/numpy/numarray >> copying numpy/numarray/matrix.py -> ?build/lib.linux-x86_64-2.4/numpy/numarray >> copying numpy/numarray/numerictypes.py -> >> build/lib.linux-x86_64-2.4/numpy/numarray >> copying numpy/numarray/image.py -> ?build/lib.linux-x86_64-2.4/numpy/numarray >> copying numpy/numarray/mlab.py -> ?build/lib.linux-x86_64-2.4/numpy/numarray >> copying numpy/numarray/ma.py -> ?build/lib.linux-x86_64-2.4/numpy/numarray >> copying numpy/numarray/session.py -> ?build/lib.linux-x86_64-2.4/numpy/numarray >> copying numpy/numarray/ufuncs.py -> ?build/lib.linux-x86_64-2.4/numpy/numarray >> creating build/lib.linux-x86_64-2.4/numpy/fft >> copying numpy/fft/setupscons.py -> ?build/lib.linux-x86_64-2.4/numpy/fft >> copying numpy/fft/__init__.py -> ?build/lib.linux-x86_64-2.4/numpy/fft >> copying numpy/fft/info.py -> ?build/lib.linux-x86_64-2.4/numpy/fft >> copying numpy/fft/setup.py -> ?build/lib.linux-x86_64-2.4/numpy/fft >> copying numpy/fft/fftpack.py -> ?build/lib.linux-x86_64-2.4/numpy/fft >> copying numpy/fft/helper.py -> ?build/lib.linux-x86_64-2.4/numpy/fft >> creating build/lib.linux-x86_64-2.4/numpy/linalg >> copying numpy/linalg/setupscons.py -> ?build/lib.linux-x86_64-2.4/numpy/linalg >> copying numpy/linalg/__init__.py -> ?build/lib.linux-x86_64-2.4/numpy/linalg >> copying numpy/linalg/info.py -> ?build/lib.linux-x86_64-2.4/numpy/linalg >> copying numpy/linalg/setup.py -> ?build/lib.linux-x86_64-2.4/numpy/linalg >> copying numpy/linalg/linalg.py -> ?build/lib.linux-x86_64-2.4/numpy/linalg >> creating build/lib.linux-x86_64-2.4/numpy/random >> copying numpy/random/setupscons.py -> ?build/lib.linux-x86_64-2.4/numpy/random >> copying numpy/random/__init__.py -> ?build/lib.linux-x86_64-2.4/numpy/random >> copying numpy/random/info.py -> ?build/lib.linux-x86_64-2.4/numpy/random >> copying numpy/random/setup.py -> ?build/lib.linux-x86_64-2.4/numpy/random >> creating build/lib.linux-x86_64-2.4/numpy/ma >> copying numpy/ma/version.py -> ?build/lib.linux-x86_64-2.4/numpy/ma >> copying numpy/ma/setupscons.py -> ?build/lib.linux-x86_64-2.4/numpy/ma >> copying numpy/ma/__init__.py -> ?build/lib.linux-x86_64-2.4/numpy/ma >> copying numpy/ma/setup.py -> ?build/lib.linux-x86_64-2.4/numpy/ma >> copying numpy/ma/bench.py -> ?build/lib.linux-x86_64-2.4/numpy/ma >> copying numpy/ma/core.py -> ?build/lib.linux-x86_64-2.4/numpy/ma >> copying numpy/ma/testutils.py -> ?build/lib.linux-x86_64-2.4/numpy/ma >> copying numpy/ma/timer_comparison.py -> ?build/lib.linux-x86_64-2.4/numpy/ma >> copying numpy/ma/extras.py -> ?build/lib.linux-x86_64-2.4/numpy/ma >> copying numpy/ma/mrecords.py -> ?build/lib.linux-x86_64-2.4/numpy/ma >> creating build/lib.linux-x86_64-2.4/numpy/matrixlib >> copying numpy/matrixlib/setupscons.py -> >> build/lib.linux-x86_64-2.4/numpy/matrixlib >> copying numpy/matrixlib/__init__.py -> >> build/lib.linux-x86_64-2.4/numpy/matrixlib >> copying numpy/matrixlib/setup.py -> ?build/lib.linux-x86_64-2.4/numpy/matrixlib >> copying numpy/matrixlib/defmatrix.py -> >> build/lib.linux-x86_64-2.4/numpy/matrixlib >> creating build/lib.linux-x86_64-2.4/numpy/compat >> copying numpy/compat/setupscons.py -> ?build/lib.linux-x86_64-2.4/numpy/compat >> copying numpy/compat/__init__.py -> ?build/lib.linux-x86_64-2.4/numpy/compat >> copying numpy/compat/setup.py -> ?build/lib.linux-x86_64-2.4/numpy/compat >> copying numpy/compat/py3k.py -> ?build/lib.linux-x86_64-2.4/numpy/compat >> copying numpy/compat/_inspect.py -> ?build/lib.linux-x86_64-2.4/numpy/compat >> creating build/lib.linux-x86_64-2.4/numpy/polynomial >> copying numpy/polynomial/__init__.py -> >> build/lib.linux-x86_64-2.4/numpy/polynomial >> copying numpy/polynomial/setup.py -> ?build/lib.linux-x86_64-2.4/numpy/polynomial >> copying numpy/polynomial/chebyshev.py -> >> build/lib.linux-x86_64-2.4/numpy/polynomial >> copying numpy/polynomial/polynomial.py -> >> build/lib.linux-x86_64-2.4/numpy/polynomial >> copying numpy/polynomial/polyutils.py -> >> build/lib.linux-x86_64-2.4/numpy/polynomial >> copying numpy/polynomial/polytemplate.py -> >> build/lib.linux-x86_64-2.4/numpy/polynomial >> creating build/lib.linux-x86_64-2.4/numpy/doc >> copying numpy/doc/byteswapping.py -> ?build/lib.linux-x86_64-2.4/numpy/doc >> copying numpy/doc/glossary.py -> ?build/lib.linux-x86_64-2.4/numpy/doc >> copying numpy/doc/indexing.py -> ?build/lib.linux-x86_64-2.4/numpy/doc >> copying numpy/doc/misc.py -> ?build/lib.linux-x86_64-2.4/numpy/doc >> copying numpy/doc/internals.py -> ?build/lib.linux-x86_64-2.4/numpy/doc >> copying numpy/doc/__init__.py -> ?build/lib.linux-x86_64-2.4/numpy/doc >> copying numpy/doc/creation.py -> ?build/lib.linux-x86_64-2.4/numpy/doc >> copying numpy/doc/jargon.py -> ?build/lib.linux-x86_64-2.4/numpy/doc >> copying numpy/doc/basics.py -> ?build/lib.linux-x86_64-2.4/numpy/doc >> copying numpy/doc/io.py -> ?build/lib.linux-x86_64-2.4/numpy/doc >> copying numpy/doc/methods_vs_functions.py -> >> build/lib.linux-x86_64-2.4/numpy/doc >> copying numpy/doc/broadcasting.py -> ?build/lib.linux-x86_64-2.4/numpy/doc >> copying numpy/doc/constants.py -> ?build/lib.linux-x86_64-2.4/numpy/doc >> copying numpy/doc/howtofind.py -> ?build/lib.linux-x86_64-2.4/numpy/doc >> copying numpy/doc/ufuncs.py -> ?build/lib.linux-x86_64-2.4/numpy/doc >> copying numpy/doc/subclassing.py -> ?build/lib.linux-x86_64-2.4/numpy/doc >> copying numpy/doc/structured_arrays.py -> ?build/lib.linux-x86_64-2.4/numpy/doc >> copying numpy/doc/performance.py -> ?build/lib.linux-x86_64-2.4/numpy/doc >> running build_clib >> customize UnixCCompiler >> customize UnixCCompiler using build_clib >> building 'npymath' library >> compiling C sources >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> creating build/temp.linux-x86_64-2.4 >> creating build/temp.linux-x86_64-2.4/build >> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4 >> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy >> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core >> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src >> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/npymath >> compile options: '-Inumpy/core/include >> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 >> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >> gcc: build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math.c >> In file included from numpy/core/src/private/npy_config.h:4, >> ? ? ? ? ? ? ? ? ? from numpy/core/src/npymath/npy_math_private.h:24, >> ? ? ? ? ? ? ? ? ? from numpy/core/src/npymath/npy_math.c.src:56: >> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >> warning: "HAVE_HYPOT" redefined >> In file included from /home/sanjey/include/python2.4/Python.h:8, >> ? ? ? ? ? ? ? ? ? from numpy/core/src/npymath/npy_math_private.h:21, >> ? ? ? ? ? ? ? ? ? from numpy/core/src/npymath/npy_math.c.src:56: >> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >> location of the previous definition >> gcc: build/src.linux-x86_64-2.4/numpy/core/src/npymath/ieee754.c >> In file included from numpy/core/src/private/npy_config.h:4, >> ? ? ? ? ? ? ? ? ? from numpy/core/src/npymath/npy_math_common.h:8, >> ? ? ? ? ? ? ? ? ? from numpy/core/src/npymath/ieee754.c.src:7: >> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >> warning: "HAVE_HYPOT" redefined >> In file included from /home/sanjey/include/python2.4/Python.h:8, >> ? ? ? ? ? ? ? ? ? from numpy/core/src/npymath/npy_math_common.h:4, >> ? ? ? ? ? ? ? ? ? from numpy/core/src/npymath/ieee754.c.src:7: >> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >> location of the previous definition >> gcc: build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math_complex.c >> In file included from numpy/core/src/private/npy_config.h:4, >> ? ? ? ? ? ? ? ? ? from numpy/core/src/npymath/npy_math_common.h:8, >> ? ? ? ? ? ? ? ? ? from numpy/core/src/npymath/npy_math_complex.c.src:31: >> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >> warning: "HAVE_HYPOT" redefined >> In file included from /home/sanjey/include/python2.4/Python.h:8, >> ? ? ? ? ? ? ? ? ? from numpy/core/src/npymath/npy_math_common.h:4, >> ? ? ? ? ? ? ? ? ? from numpy/core/src/npymath/npy_math_complex.c.src:31: >> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >> location of the previous definition >> ar: adding 3 object files to build/temp.linux-x86_64-2.4/libnpymath.a >> running build_ext >> customize UnixCCompiler >> customize UnixCCompiler using build_ext >> customize GnuFCompiler >> gnu: no Fortran 90 compiler found >> gnu: no Fortran 90 compiler found >> customize GnuFCompiler >> gnu: no Fortran 90 compiler found >> gnu: no Fortran 90 compiler found >> customize GnuFCompiler using build_ext >> building 'numpy.core._sort' extension >> compiling C sources >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/include >> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 >> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >> gcc: build/src.linux-x86_64-2.4/numpy/core/src/_sortmodule.c >> In file included from numpy/core/src/private/npy_config.h:4, >> ? ? ? ? ? ? ? ? ? from numpy/core/src/_sortmodule.c.src:34: >> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >> warning: "HAVE_HYPOT" redefined >> In file included from /home/sanjey/include/python2.4/Python.h:8, >> ? ? ? ? ? ? ? ? ? from numpy/core/src/_sortmodule.c.src:30: >> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >> location of the previous definition >> gcc -m32 -pthread -shared >> build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/_sortmodule.o >> -Lbuild/temp.linux-x86_64-2.4 -lm -o >> build/lib.linux-x86_64-2.4/numpy/core/_sort.so >> building 'numpy.core.multiarray' extension >> compiling C sources >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> creating build/temp.linux-x86_64-2.4/numpy >> creating build/temp.linux-x86_64-2.4/numpy/core >> creating build/temp.linux-x86_64-2.4/numpy/core/src >> creating build/temp.linux-x86_64-2.4/numpy/core/src/multiarray >> compile options: '-Inumpy/core/include >> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 >> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >> gcc: numpy/core/src/multiarray/multiarraymodule_onefile.c >> In file included from numpy/core/src/private/npy_config.h:4, >> ? ? ? ? ? ? ? ? ? from numpy/core/src/multiarray/common.c:8, >> ? ? ? ? ? ? ? ? ? from numpy/core/src/multiarray/multiarraymodule_onefile.c:8: >> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >> warning: "HAVE_HYPOT" redefined >> In file included from /home/sanjey/include/python2.4/Python.h:8, >> ? ? ? ? ? ? ? ? ? from numpy/core/src/multiarray/common.c:2, >> ? ? ? ? ? ? ? ? ? from numpy/core/src/multiarray/multiarraymodule_onefile.c:8: >> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >> location of the previous definition >> In file included from numpy/core/src/multiarray/multiarraymodule_onefile.c:26: >> numpy/core/src/multiarray/methods.c: In function `NpyArg_ParseKeywords': >> numpy/core/src/multiarray/methods.c:41: warning: passing arg 3 of >> `PyArg_VaParseTupleAndKeywords' discards qualifiers from pointer >> target type >> numpy/core/src/multiarray/flagsobject.c: In function `arrayflags_richcompare': >> numpy/core/src/multiarray/flagsobject.c:568: warning: 'cmp' might be >> used uninitialized in this function >> numpy/core/src/multiarray/multiarraymodule_onefile.c: At top level: >> numpy/core/include/numpy/npy_3kcompat.h:331: warning: >> 'simple_capsule_dtor' defined but not used >> numpy/core/src/multiarray/buffer.c:777: warning: >> '_descriptor_from_pep3118_format' defined but not used >> numpy/core/src/multiarray/arraytypes.c.src:93: warning: >> '_SEQUENCE_MESSAGE' defined but not used >> numpy/core/src/multiarray/mapping.c:75: warning: '_array_ass_item' >> defined but not used >> gcc -m32 -pthread -shared >> build/temp.linux-x86_64-2.4/numpy/core/src/multiarray/multiarraymodule_onefile.o >> -Lbuild/temp.linux-x86_64-2.4 -lnpymath -lm -o >> build/lib.linux-x86_64-2.4/numpy/core/multiarray.so >> building 'numpy.core.umath' extension >> compiling C sources >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> creating build/temp.linux-x86_64-2.4/numpy/core/src/umath >> compile options: '-Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath >> -Inumpy/core/include >> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 >> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >> gcc: numpy/core/src/umath/umathmodule_onefile.c >> In file included from numpy/core/src/private/npy_config.h:4, >> ? ? ? ? ? ? ? ? ? from numpy/core/src/umath/loops.c.src:7, >> ? ? ? ? ? ? ? ? ? from numpy/core/src/umath/umathmodule_onefile.c:1: >> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >> warning: "HAVE_HYPOT" redefined >> In file included from /home/sanjey/include/python2.4/Python.h:8, >> ? ? ? ? ? ? ? ? ? from numpy/core/src/umath/loops.c.src:5, >> ? ? ? ? ? ? ? ? ? from numpy/core/src/umath/umathmodule_onefile.c:1: >> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >> location of the previous definition >> numpy/core/include/numpy/npy_3kcompat.h:331: warning: >> 'simple_capsule_dtor' defined but not used >> numpy/core/src/umath/loops.c.src:1258: warning: >> 'CLONGDOUBLE_logical_and' defined but not used >> numpy/core/src/umath/loops.c.src:1258: warning: >> 'CLONGDOUBLE_logical_or' defined but not used >> numpy/core/src/umath/loops.c.src:1271: warning: >> 'CLONGDOUBLE_logical_xor' defined but not used >> numpy/core/src/umath/loops.c.src:1285: warning: >> 'CLONGDOUBLE_logical_not' defined but not used >> numpy/core/src/umath/loops.c.src:1342: warning: >> 'CLONGDOUBLE_ones_like' defined but not used >> numpy/core/src/umath/loops.c.src:1399: warning: 'CLONGDOUBLE_maximum' >> defined but not used >> numpy/core/src/umath/loops.c.src:1399: warning: 'CLONGDOUBLE_minimum' >> defined but not used >> numpy/core/src/umath/loops.c.src:1423: warning: 'CLONGDOUBLE_fmax' >> defined but not used >> numpy/core/src/umath/loops.c.src:1423: warning: 'CLONGDOUBLE_fmin' >> defined but not used >> gcc -m32 -pthread -shared >> build/temp.linux-x86_64-2.4/numpy/core/src/umath/umathmodule_onefile.o >> -Lbuild/temp.linux-x86_64-2.4 -lnpymath -lm -o >> build/lib.linux-x86_64-2.4/numpy/core/umath.so >> building 'numpy.core.scalarmath' extension >> compiling C sources >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> compile options: '-Inumpy/core/include >> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 >> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >> gcc: build/src.linux-x86_64-2.4/numpy/core/src/scalarmathmodule.c >> numpy/core/include/numpy/npy_3kcompat.h:331: warning: >> 'simple_capsule_dtor' defined but not used >> gcc -m32 -pthread -shared >> build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/scalarmathmodule.o >> -Lbuild/temp.linux-x86_64-2.4 -lm -o >> build/lib.linux-x86_64-2.4/numpy/core/scalarmath.so >> building 'numpy.core.umath_tests' extension >> compiling C sources >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/umath >> compile options: '-Inumpy/core/include >> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 >> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >> gcc: build/src.linux-x86_64-2.4/numpy/core/src/umath/umath_tests.c >> In file included from numpy/core/src/private/npy_config.h:4, >> ? ? ? ? ? ? ? ? ? from numpy/core/src/umath/umath_tests.c.src:14: >> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >> warning: "HAVE_HYPOT" redefined >> In file included from /home/sanjey/include/python2.4/Python.h:8, >> ? ? ? ? ? ? ? ? ? from numpy/core/src/umath/umath_tests.c.src:8: >> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >> location of the previous definition >> numpy/core/include/numpy/npy_3kcompat.h:331: warning: >> 'simple_capsule_dtor' defined but not used >> gcc -m32 -pthread -shared >> build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/umath/umath_tests.o >> -Lbuild/temp.linux-x86_64-2.4 -o >> build/lib.linux-x86_64-2.4/numpy/core/umath_tests.so >> building 'numpy.core.multiarray_tests' extension >> compiling C sources >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/multiarray >> compile options: '-Inumpy/core/include >> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 >> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >> gcc: build/src.linux-x86_64-2.4/numpy/core/src/multiarray/multiarray_tests.c >> numpy/core/include/numpy/npy_3kcompat.h:331: warning: >> 'simple_capsule_dtor' defined but not used >> gcc -m32 -pthread -shared >> build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/multiarray/multiarray_tests.o >> -Lbuild/temp.linux-x86_64-2.4 -o >> build/lib.linux-x86_64-2.4/numpy/core/multiarray_tests.so >> building 'numpy.lib._compiled_base' extension >> compiling C sources >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> creating build/temp.linux-x86_64-2.4/numpy/lib >> creating build/temp.linux-x86_64-2.4/numpy/lib/src >> compile options: '-Inumpy/core/include >> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 >> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >> gcc: numpy/lib/src/_compiled_base.c >> In file included from numpy/core/src/private/npy_config.h:4, >> ? ? ? ? ? ? ? ? ? from numpy/lib/src/_compiled_base.c:4: >> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >> warning: "HAVE_HYPOT" redefined >> In file included from /home/sanjey/include/python2.4/Python.h:8, >> ? ? ? ? ? ? ? ? ? from numpy/lib/src/_compiled_base.c:1: >> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >> location of the previous definition >> gcc -m32 -pthread -shared >> build/temp.linux-x86_64-2.4/numpy/lib/src/_compiled_base.o >> -Lbuild/temp.linux-x86_64-2.4 -o >> build/lib.linux-x86_64-2.4/numpy/lib/_compiled_base.so >> building 'numpy.numarray._capi' extension >> compiling C sources >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> creating build/temp.linux-x86_64-2.4/numpy/numarray >> compile options: '-Inumpy/core/include >> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 >> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >> gcc: numpy/numarray/_capi.c >> numpy/core/include/numpy/npy_3kcompat.h:331: warning: >> 'simple_capsule_dtor' defined but not used >> gcc -m32 -pthread -shared >> build/temp.linux-x86_64-2.4/numpy/numarray/_capi.o >> -Lbuild/temp.linux-x86_64-2.4 -o >> build/lib.linux-x86_64-2.4/numpy/numarray/_capi.so >> building 'numpy.fft.fftpack_lite' extension >> compiling C sources >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> creating build/temp.linux-x86_64-2.4/numpy/fft >> compile options: '-Inumpy/core/include >> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 >> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >> gcc: numpy/fft/fftpack_litemodule.c >> gcc: numpy/fft/fftpack.c >> gcc -m32 -pthread -shared >> build/temp.linux-x86_64-2.4/numpy/fft/fftpack_litemodule.o >> build/temp.linux-x86_64-2.4/numpy/fft/fftpack.o >> -Lbuild/temp.linux-x86_64-2.4 -o >> build/lib.linux-x86_64-2.4/numpy/fft/fftpack_lite.so >> building 'numpy.linalg.lapack_lite' extension >> compiling C sources >> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >> -O3 -Wall -Wstrict-prototypes -fPIC >> >> creating build/temp.linux-x86_64-2.4/numpy/linalg >> compile options: '-DNO_ATLAS_INFO=1 -Inumpy/core/include >> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >> -Inumpy/core/src/umath -Inumpy/core/include >> -I/home/sanjey/include/python2.4 >> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >> gcc: numpy/linalg/lapack_litemodule.c >> gcc: numpy/linalg/python_xerbla.c >> /usr/bin/g77 -g -Wall -g -Wall -shared >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o >> build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o -L/usr/lib >> -Lbuild/temp.linux-x86_64-2.4 -llapack -lblas -lg2c -o >> build/lib.linux-x86_64-2.4/numpy/linalg/lapack_lite.so >> /usr/bin/ld: skipping incompatible /usr/lib/liblapack.so when >> searching for -llapack >> /usr/bin/ld: skipping incompatible /usr/lib/liblapack.a when searching >> for -llapack >> /usr/bin/ld: skipping incompatible /usr/lib/libblas.so when searching for -lblas >> /usr/bin/ld: skipping incompatible /usr/lib/libblas.a when searching for -lblas >> /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm >> /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm >> /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm >> /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm >> /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 >> /usr/bin/ld: warning: i386 architecture of input file >> `build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o' is >> incompatible with i386:x86-64 output >> /usr/bin/ld: warning: i386 architecture of input file >> `build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o' is >> incompatible with i386:x86-64 output >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xae): >> In function `lapack_lite_dgeev': >> numpy/linalg/lapack_litemodule.c:155: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfe):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x143):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a3):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1f4):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x272):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31c):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ae):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x60e):numpy/linalg/lapack_litemodule.c:171: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6aa): >> In function `lapack_lite_dsyevd': >> numpy/linalg/lapack_litemodule.c:241: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6f4):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x739):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x797):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x7ef):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x869):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x8ff):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xa7c):numpy/linalg/lapack_litemodule.c:254: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb34): >> In function `lapack_lite_zheevd': >> numpy/linalg/lapack_litemodule.c:327: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb7e):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xbc3):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc23):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc74):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xce9):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xd85):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xe77):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfb9):numpy/linalg/lapack_litemodule.c:341: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1087): >> In function `lapack_lite_dgelsd': >> numpy/linalg/lapack_litemodule.c:365: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x10d7):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x111c):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x117d):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x11cf):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1252):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x12e8):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x13d7):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1534):numpy/linalg/lapack_litemodule.c:380: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15af): >> In function `lapack_lite_dgesv': >> numpy/linalg/lapack_litemodule.c:398: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15f9):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x163e):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1692):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x16e7):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x175e):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x189a):numpy/linalg/lapack_litemodule.c:407: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1967): >> In function `lapack_lite_dgesdd': >> numpy/linalg/lapack_litemodule.c:430: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19b7):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19fc):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a5d):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1aaf):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1b32):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1bc8):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d15):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d76):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1efb):numpy/linalg/lapack_litemodule.c:472: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x202b): >> In function `lapack_lite_dgetrf': >> numpy/linalg/lapack_litemodule.c:488: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2063):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20ae):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20fe):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2155):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2235):numpy/linalg/lapack_litemodule.c:496: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22b4): >> In function `lapack_lite_dpotrf': >> numpy/linalg/lapack_litemodule.c:510: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22e9):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x232d):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x238f):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x240a):numpy/linalg/lapack_litemodule.c:516: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24af): >> In function `lapack_lite_dgeqrf': >> numpy/linalg/lapack_litemodule.c:529: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24f9):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x253e):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2598):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x25ef):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2669):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x27a7):numpy/linalg/lapack_litemodule.c:540: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2839): >> In function `lapack_lite_dorgqr': >> numpy/linalg/lapack_litemodule.c:555: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2883):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x28c8):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2927):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x297f):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x29f9):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2afa):numpy/linalg/lapack_litemodule.c:562: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2bbb): >> In function `lapack_lite_zgeev': >> numpy/linalg/lapack_litemodule.c:585: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c0b):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c50):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2cb0):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d04):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d82):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2e2c):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2f6b):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2fb9):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x311b):numpy/linalg/lapack_litemodule.c:601: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31f4): >> In function `lapack_lite_zgelsd': >> numpy/linalg/lapack_litemodule.c:626: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3244):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3289):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x32ef):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3340):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x33c8):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3471):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35b1):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35ff):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x376f):numpy/linalg/lapack_litemodule.c:641: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x37ef): >> In function `lapack_lite_zgesv': >> numpy/linalg/lapack_litemodule.c:658: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3839):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x387e):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x38d2):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3927):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x399e):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3ada):numpy/linalg/lapack_litemodule.c:667: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bae): >> In function `lapack_lite_zgesdd': >> numpy/linalg/lapack_litemodule.c:691: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bfe):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3c43):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cab):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cff):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3d82):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3e2c):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3f70):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3fbe):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4195):numpy/linalg/lapack_litemodule.c:708: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x41ab):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x422b): >> In function `lapack_lite_zgetrf': >> numpy/linalg/lapack_litemodule.c:724: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4263):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42ae):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42fe):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4355):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4435):numpy/linalg/lapack_litemodule.c:732: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44b4): >> In function `lapack_lite_zpotrf': >> numpy/linalg/lapack_litemodule.c:746: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44e9):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x452d):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x458f):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460a):numpy/linalg/lapack_litemodule.c:751: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46af): >> In function `lapack_lite_zgeqrf': >> numpy/linalg/lapack_litemodule.c:764: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46f9):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x473e):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4798):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x47ef):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4869):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x49a7):numpy/linalg/lapack_litemodule.c:774: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a39): >> In function `lapack_lite_zungqr': >> numpy/linalg/lapack_litemodule.c:787: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a83):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ac8):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b27):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b7f):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4bf9):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4cfa):numpy/linalg/lapack_litemodule.c:797: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d58): >> In function `initlapack_lite': >> numpy/linalg/lapack_litemodule.c:858: undefined reference to `Py_InitModule4' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d71): >> In function `initlapack_lite': >> build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1190: >> undefined reference to `PyImport_ImportModule' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d8d):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1197: >> undefined reference to `PyObject_GetAttrString' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4da6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1212: >> undefined reference to `PyCObject_Type' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4db5):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: >> undefined reference to `PyExc_RuntimeError' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dc9):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: >> undefined reference to `PyErr_SetString' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dd7): >> In function `initlapack_lite': >> numpy/linalg/lapack_litemodule.c:865: undefined reference to `PyErr_Print' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ddd):numpy/linalg/lapack_litemodule.c:865: >> undefined reference to `PyExc_ImportError' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4df1):numpy/linalg/lapack_litemodule.c:865: >> undefined reference to `PyErr_SetString' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e18): >> In function `initlapack_lite': >> build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1194: >> undefined reference to `PyExc_ImportError' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e26):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: >> undefined reference to `PyErr_SetString' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e46):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1217: >> undefined reference to `PyCObject_AsVoidPtr' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e88):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: >> undefined reference to `PyExc_RuntimeError' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e96):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ea1):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: >> undefined reference to `PyExc_RuntimeError' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4eb6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1200: >> undefined reference to `PyExc_AttributeError' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f24):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: >> undefined reference to `PyExc_RuntimeError' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f2e):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f46): >> In function `initlapack_lite': >> numpy/linalg/lapack_litemodule.c:866: undefined reference to `PyModule_GetDict' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f66):numpy/linalg/lapack_litemodule.c:867: >> undefined reference to `PyErr_NewException' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f82):numpy/linalg/lapack_litemodule.c:868: >> undefined reference to `PyDict_SetItemString' >> build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x70): >> In function `xerbla_': >> numpy/linalg/python_xerbla.c:35: undefined reference to `PyExc_ValueError' >> build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x7e):numpy/linalg/python_xerbla.c:35: >> undefined reference to `PyErr_SetString' >> collect2: ld returned 1 exit status >> /usr/bin/ld: skipping incompatible /usr/lib/liblapack.so when >> searching for -llapack >> /usr/bin/ld: skipping incompatible /usr/lib/liblapack.a when searching >> for -llapack >> /usr/bin/ld: skipping incompatible /usr/lib/libblas.so when searching for -lblas >> /usr/bin/ld: skipping incompatible /usr/lib/libblas.a when searching for -lblas >> /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm >> /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm >> /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm >> /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm >> /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 >> /usr/bin/ld: warning: i386 architecture of input file >> `build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o' is >> incompatible with i386:x86-64 output >> /usr/bin/ld: warning: i386 architecture of input file >> `build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o' is >> incompatible with i386:x86-64 output >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xae): >> In function `lapack_lite_dgeev': >> numpy/linalg/lapack_litemodule.c:155: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfe):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x143):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a3):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1f4):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x272):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31c):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ae):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x60e):numpy/linalg/lapack_litemodule.c:171: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6aa): >> In function `lapack_lite_dsyevd': >> numpy/linalg/lapack_litemodule.c:241: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6f4):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x739):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x797):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x7ef):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x869):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x8ff):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xa7c):numpy/linalg/lapack_litemodule.c:254: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb34): >> In function `lapack_lite_zheevd': >> numpy/linalg/lapack_litemodule.c:327: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb7e):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xbc3):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc23):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc74):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xce9):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xd85):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xe77):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfb9):numpy/linalg/lapack_litemodule.c:341: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1087): >> In function `lapack_lite_dgelsd': >> numpy/linalg/lapack_litemodule.c:365: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x10d7):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x111c):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x117d):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x11cf):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1252):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x12e8):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x13d7):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1534):numpy/linalg/lapack_litemodule.c:380: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15af): >> In function `lapack_lite_dgesv': >> numpy/linalg/lapack_litemodule.c:398: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15f9):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x163e):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1692):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x16e7):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x175e):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x189a):numpy/linalg/lapack_litemodule.c:407: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1967): >> In function `lapack_lite_dgesdd': >> numpy/linalg/lapack_litemodule.c:430: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19b7):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19fc):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a5d):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1aaf):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1b32):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1bc8):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d15):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d76):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1efb):numpy/linalg/lapack_litemodule.c:472: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x202b): >> In function `lapack_lite_dgetrf': >> numpy/linalg/lapack_litemodule.c:488: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2063):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20ae):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20fe):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2155):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2235):numpy/linalg/lapack_litemodule.c:496: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22b4): >> In function `lapack_lite_dpotrf': >> numpy/linalg/lapack_litemodule.c:510: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22e9):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x232d):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x238f):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x240a):numpy/linalg/lapack_litemodule.c:516: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24af): >> In function `lapack_lite_dgeqrf': >> numpy/linalg/lapack_litemodule.c:529: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24f9):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x253e):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2598):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x25ef):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2669):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x27a7):numpy/linalg/lapack_litemodule.c:540: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2839): >> In function `lapack_lite_dorgqr': >> numpy/linalg/lapack_litemodule.c:555: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2883):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x28c8):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2927):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x297f):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x29f9):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2afa):numpy/linalg/lapack_litemodule.c:562: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2bbb): >> In function `lapack_lite_zgeev': >> numpy/linalg/lapack_litemodule.c:585: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c0b):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c50):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2cb0):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d04):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d82):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2e2c):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2f6b):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2fb9):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x311b):numpy/linalg/lapack_litemodule.c:601: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31f4): >> In function `lapack_lite_zgelsd': >> numpy/linalg/lapack_litemodule.c:626: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3244):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3289):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x32ef):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3340):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x33c8):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3471):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35b1):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35ff):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x376f):numpy/linalg/lapack_litemodule.c:641: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x37ef): >> In function `lapack_lite_zgesv': >> numpy/linalg/lapack_litemodule.c:658: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3839):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x387e):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x38d2):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3927):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x399e):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3ada):numpy/linalg/lapack_litemodule.c:667: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bae): >> In function `lapack_lite_zgesdd': >> numpy/linalg/lapack_litemodule.c:691: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bfe):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3c43):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cab):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cff):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3d82):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3e2c):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3f70):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3fbe):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4195):numpy/linalg/lapack_litemodule.c:708: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x41ab):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x422b): >> In function `lapack_lite_zgetrf': >> numpy/linalg/lapack_litemodule.c:724: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4263):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42ae):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42fe):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4355):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4435):numpy/linalg/lapack_litemodule.c:732: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44b4): >> In function `lapack_lite_zpotrf': >> numpy/linalg/lapack_litemodule.c:746: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44e9):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x452d):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x458f):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460a):numpy/linalg/lapack_litemodule.c:751: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46af): >> In function `lapack_lite_zgeqrf': >> numpy/linalg/lapack_litemodule.c:764: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46f9):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x473e):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4798):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x47ef):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4869):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x49a7):numpy/linalg/lapack_litemodule.c:774: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a39): >> In function `lapack_lite_zungqr': >> numpy/linalg/lapack_litemodule.c:787: undefined reference to `PyArg_ParseTuple' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a83):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ac8):numpy/linalg/lapack_litemodule.c:114: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b27):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b7f):numpy/linalg/lapack_litemodule.c:120: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4bf9):numpy/linalg/lapack_litemodule.c:103: >> undefined reference to `PyType_IsSubtype' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4cfa):numpy/linalg/lapack_litemodule.c:797: >> undefined reference to `Py_BuildValue' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d58): >> In function `initlapack_lite': >> numpy/linalg/lapack_litemodule.c:858: undefined reference to `Py_InitModule4' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d71): >> In function `initlapack_lite': >> build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1190: >> undefined reference to `PyImport_ImportModule' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d8d):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1197: >> undefined reference to `PyObject_GetAttrString' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4da6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1212: >> undefined reference to `PyCObject_Type' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4db5):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: >> undefined reference to `PyExc_RuntimeError' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dc9):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: >> undefined reference to `PyErr_SetString' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dd7): >> In function `initlapack_lite': >> numpy/linalg/lapack_litemodule.c:865: undefined reference to `PyErr_Print' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ddd):numpy/linalg/lapack_litemodule.c:865: >> undefined reference to `PyExc_ImportError' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4df1):numpy/linalg/lapack_litemodule.c:865: >> undefined reference to `PyErr_SetString' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e18): >> In function `initlapack_lite': >> build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1194: >> undefined reference to `PyExc_ImportError' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e26):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: >> undefined reference to `PyErr_SetString' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e46):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1217: >> undefined reference to `PyCObject_AsVoidPtr' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e88):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: >> undefined reference to `PyExc_RuntimeError' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e96):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ea1):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: >> undefined reference to `PyExc_RuntimeError' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4eb6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1200: >> undefined reference to `PyExc_AttributeError' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f24):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: >> undefined reference to `PyExc_RuntimeError' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f2e):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: >> undefined reference to `PyErr_Format' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f46): >> In function `initlapack_lite': >> numpy/linalg/lapack_litemodule.c:866: undefined reference to `PyModule_GetDict' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f66):numpy/linalg/lapack_litemodule.c:867: >> undefined reference to `PyErr_NewException' >> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f82):numpy/linalg/lapack_litemodule.c:868: >> undefined reference to `PyDict_SetItemString' >> build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x70): >> In function `xerbla_': >> numpy/linalg/python_xerbla.c:35: undefined reference to `PyExc_ValueError' >> build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x7e):numpy/linalg/python_xerbla.c:35: >> undefined reference to `PyErr_SetString' >> collect2: ld returned 1 exit status >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion > Since you are using the -m32 flag, do you have *all* the 32-bit > libraries/headers installed (especially Python 2.4 ones) what appears to > be a x86_64 operating system? > > > Bruce > > > > > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > From bsouthey at gmail.com Fri Oct 15 11:52:34 2010 From: bsouthey at gmail.com (Bruce Southey) Date: Fri, 15 Oct 2010 10:52:34 -0500 Subject: [Numpy-discussion] Please help a newbie install NUMPY In-Reply-To: References: <4CB871D8.4080503@gmail.com> Message-ID: <4CB878C2.2070009@gmail.com> On 10/15/2010 10:30 AM, P Sanjey wrote: > Hi Bruce, > > Not sure how to check if they are there (the libraries)-do you mean > the ones with .so extensions? > How can I know wht libraries are needed and whats already there? > > Yes its a x86_64 machine but I need a 32 bit version as I have another > piece of code that only works on 32 bits > so I am stuck with the 32 bit version > > Thanks for the help > > On Fri, Oct 15, 2010 at 4:23 PM, Bruce Southey wrote: >> On 10/15/2010 09:31 AM, P Sanjey wrote: >>> Please help-I am a newbie and I wanted to try installing numpy on a >>> local /home/usr directory but got the following errors-I am not sure >>> where to even begin fixing this problem and any help would be useful >>> I just did the standard >>> python setup.py build and got the following (loooooong) error message >>> >>> >>> ********************************************************** >>> non-existing path in 'numpy/distutils': 'site.cfg' >>> F2PY Version 1 >>> blas_opt_info: >>> blas_mkl_info: >>> libraries mkl,vml,guide not found in /home/sanjey/lib >>> libraries mkl,vml,guide not found in /usr/local/lib >>> libraries mkl,vml,guide not found in /usr/lib >>> NOT AVAILABLE >>> >>> atlas_blas_threads_info: >>> Setting PTATLAS=ATLAS >>> libraries ptf77blas,ptcblas,atlas not found in /home/sanjey/lib >>> libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib >>> libraries ptf77blas,ptcblas,atlas not found in /usr/lib/sse2 >>> libraries ptf77blas,ptcblas,atlas not found in /usr/lib >>> NOT AVAILABLE >>> >>> atlas_blas_info: >>> libraries f77blas,cblas,atlas not found in /home/sanjey/lib >>> libraries f77blas,cblas,atlas not found in /usr/local/lib >>> libraries f77blas,cblas,atlas not found in /usr/lib/sse2 >>> libraries f77blas,cblas,atlas not found in /usr/lib >>> NOT AVAILABLE >>> >>> blas_info: >>> libraries blas not found in /home/sanjey/lib >>> libraries blas not found in /usr/local/lib >>> FOUND: >>> libraries = ['blas'] >>> library_dirs = ['/usr/lib'] >>> language = f77 >>> >>> FOUND: >>> libraries = ['blas'] >>> library_dirs = ['/usr/lib'] >>> define_macros = [('NO_ATLAS_INFO', 1)] >>> language = f77 >>> >>> lapack_opt_info: >>> lapack_mkl_info: >>> mkl_info: >>> libraries mkl,vml,guide not found in /home/sanjey/lib >>> libraries mkl,vml,guide not found in /usr/local/lib >>> libraries mkl,vml,guide not found in /usr/lib >>> NOT AVAILABLE >>> >>> NOT AVAILABLE >>> >>> atlas_threads_info: >>> Setting PTATLAS=ATLAS >>> libraries ptf77blas,ptcblas,atlas not found in /home/sanjey/lib >>> libraries lapack_atlas not found in /home/sanjey/lib >>> libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib >>> libraries lapack_atlas not found in /usr/local/lib >>> libraries ptf77blas,ptcblas,atlas not found in /usr/lib/sse2 >>> libraries lapack_atlas not found in /usr/lib/sse2 >>> libraries ptf77blas,ptcblas,atlas not found in /usr/lib >>> libraries lapack_atlas not found in /usr/lib >>> numpy.distutils.system_info.atlas_threads_info >>> NOT AVAILABLE >>> >>> atlas_info: >>> libraries f77blas,cblas,atlas not found in /home/sanjey/lib >>> libraries lapack_atlas not found in /home/sanjey/lib >>> libraries f77blas,cblas,atlas not found in /usr/local/lib >>> libraries lapack_atlas not found in /usr/local/lib >>> libraries f77blas,cblas,atlas not found in /usr/lib/sse2 >>> libraries lapack_atlas not found in /usr/lib/sse2 >>> libraries f77blas,cblas,atlas not found in /usr/lib >>> libraries lapack_atlas not found in /usr/lib >>> numpy.distutils.system_info.atlas_info >>> NOT AVAILABLE >>> >>> lapack_info: >>> libraries lapack not found in /home/sanjey/lib >>> libraries lapack not found in /usr/local/lib >>> FOUND: >>> libraries = ['lapack'] >>> library_dirs = ['/usr/lib'] >>> language = f77 >>> >>> FOUND: >>> libraries = ['lapack', 'blas'] >>> library_dirs = ['/usr/lib'] >>> define_macros = [('NO_ATLAS_INFO', 1)] >>> language = f77 >>> >>> running build >>> running config_cc >>> unifing config_cc, config, build_clib, build_ext, build commands >>> --compiler options >>> running config_fc >>> unifing config_fc, config, build_clib, build_ext, build commands >>> --fcompiler options >>> running build_src >>> 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 library "npymath" sources >>> customize GnuFCompiler >>> Found executable /usr/bin/g77 >>> gnu: no Fortran 90 compiler found >>> gnu: no Fortran 90 compiler found >>> customize GnuFCompiler >>> gnu: no Fortran 90 compiler found >>> gnu: no Fortran 90 compiler found >>> customize GnuFCompiler using config >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> gcc -m32 -pthread _configtest.o -o _configtest >>> success! >>> removing: _configtest.c _configtest.o _configtest >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:1: warning: conflicting types for built-in function 'exp' >>> gcc -m32 -pthread _configtest.o -o _configtest >>> _configtest.o(.text+0x19): In function `main': >>> /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' >>> collect2: ld returned 1 exit status >>> _configtest.o(.text+0x19): In function `main': >>> /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' >>> collect2: ld returned 1 exit status >>> failure. >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:1: warning: conflicting types for built-in function 'exp' >>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>> success! >>> removing: _configtest.c _configtest.o _configtest >>> creating build/src.linux-x86_64-2.4/numpy/core >>> creating build/src.linux-x86_64-2.4/numpy/core/src >>> creating build/src.linux-x86_64-2.4/numpy/core/src/npymath >>> conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math.c >>> conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/npymath/ieee754.c >>> conv_template:> >>> build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math_complex.c >>> building extension "numpy.core._sort" sources >>> Generating build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> success! >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> success! >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:5: warning: function declaration isn't a prototype >>> success! >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:5: warning: function declaration isn't a prototype >>> success! >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:5: warning: function declaration isn't a prototype >>> success! >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:5: warning: function declaration isn't a prototype >>> success! >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> removing: _configtest.c _configtest.o _configtest.c _configtest.o >>> _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c >>> _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:5: warning: function declaration isn't a prototype >>> success! >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> removing: _configtest.c _configtest.o _configtest.c _configtest.o >>> _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c >>> _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o >>> _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:5: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:7: error: `SIZEOF_LONGDOUBLE' undeclared (first use in >>> this function) >>> _configtest.c:7: error: (Each undeclared identifier is reported only once >>> _configtest.c:7: error: for each function it appears in.) >>> _configtest.c:5: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:7: error: `SIZEOF_LONGDOUBLE' undeclared (first use in >>> this function) >>> _configtest.c:7: error: (Each undeclared identifier is reported only once >>> _configtest.c:7: error: for each function it appears in.) >>> failure. >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> removing: _configtest.c _configtest.o _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> removing: _configtest.c _configtest.o _configtest.c _configtest.o >>> _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c >>> _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o >>> _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c >>> _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:5: error: size of array `test_array' is negative >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> removing: _configtest.c _configtest.o _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:6: warning: function declaration isn't a prototype >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:6: warning: function declaration isn't a prototype >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:5: warning: function declaration isn't a prototype >>> success! >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:6: warning: function declaration isn't a prototype >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:6: warning: function declaration isn't a prototype >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:5: warning: function declaration isn't a prototype >>> success! >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:1: warning: conflicting types for built-in function 'exp' >>> gcc -m32 -pthread _configtest.o -o _configtest >>> _configtest.o(.text+0x19): In function `main': >>> /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' >>> collect2: ld returned 1 exit status >>> _configtest.o(.text+0x19): In function `main': >>> /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' >>> collect2: ld returned 1 exit status >>> failure. >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:1: warning: conflicting types for built-in function 'exp' >>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>> success! >>> removing: _configtest.c _configtest.o _configtest >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:1: warning: conflicting types for built-in function 'asin' >>> _configtest.c:2: warning: conflicting types for built-in function 'cos' >>> _configtest.c:3: warning: conflicting types for built-in function 'log' >>> _configtest.c:4: warning: conflicting types for built-in function 'fabs' >>> _configtest.c:5: warning: conflicting types for built-in function 'tanh' >>> _configtest.c:6: warning: conflicting types for built-in function 'atan' >>> _configtest.c:7: warning: conflicting types for built-in function 'acos' >>> _configtest.c:8: warning: conflicting types for built-in function 'floor' >>> _configtest.c:9: warning: conflicting types for built-in function 'fmod' >>> _configtest.c:10: warning: conflicting types for built-in function 'sqrt' >>> _configtest.c:11: warning: conflicting types for built-in function 'cosh' >>> _configtest.c:12: warning: conflicting types for built-in function 'modf' >>> _configtest.c:13: warning: conflicting types for built-in function 'sinh' >>> _configtest.c:14: warning: conflicting types for built-in function 'frexp' >>> _configtest.c:15: warning: conflicting types for built-in function 'exp' >>> _configtest.c:16: warning: conflicting types for built-in function 'tan' >>> _configtest.c:17: warning: conflicting types for built-in function 'ceil' >>> _configtest.c:18: warning: conflicting types for built-in function 'log10' >>> _configtest.c:19: warning: conflicting types for built-in function 'sin' >>> _configtest.c:20: warning: conflicting types for built-in function 'ldexp' >>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>> success! >>> removing: _configtest.c _configtest.o _configtest >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:1: warning: conflicting types for built-in function 'expm1' >>> _configtest.c:2: warning: conflicting types for built-in function 'log2' >>> _configtest.c:3: warning: conflicting types for built-in function 'pow' >>> _configtest.c:4: warning: conflicting types for built-in function 'rint' >>> _configtest.c:5: warning: conflicting types for built-in function 'atanh' >>> _configtest.c:6: warning: conflicting types for built-in function 'copysign' >>> _configtest.c:7: warning: conflicting types for built-in function 'asinh' >>> _configtest.c:8: warning: conflicting types for built-in function 'atan2' >>> _configtest.c:9: warning: conflicting types for built-in function 'hypot' >>> _configtest.c:10: warning: conflicting types for built-in function 'acosh' >>> _configtest.c:11: warning: conflicting types for built-in function 'exp2' >>> _configtest.c:12: warning: conflicting types for built-in function 'log1p' >>> _configtest.c:13: warning: conflicting types for built-in function 'nextafter' >>> _configtest.c:14: warning: conflicting types for built-in function 'trunc' >>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>> success! >>> removing: _configtest.c _configtest.o _configtest >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:1: warning: conflicting types for built-in function 'cosf' >>> _configtest.c:2: warning: conflicting types for built-in function 'coshf' >>> _configtest.c:3: warning: conflicting types for built-in function 'rintf' >>> _configtest.c:4: warning: conflicting types for built-in function 'fabsf' >>> _configtest.c:5: warning: conflicting types for built-in function 'floorf' >>> _configtest.c:6: warning: conflicting types for built-in function 'nextafterf' >>> _configtest.c:7: warning: conflicting types for built-in function 'tanhf' >>> _configtest.c:8: warning: conflicting types for built-in function 'log10f' >>> _configtest.c:9: warning: conflicting types for built-in function 'logf' >>> _configtest.c:10: warning: conflicting types for built-in function 'sinhf' >>> _configtest.c:11: warning: conflicting types for built-in function 'acosf' >>> _configtest.c:12: warning: conflicting types for built-in function 'sqrtf' >>> _configtest.c:13: warning: conflicting types for built-in function 'ldexpf' >>> _configtest.c:14: warning: conflicting types for built-in function 'hypotf' >>> _configtest.c:15: warning: conflicting types for built-in function 'log2f' >>> _configtest.c:16: warning: conflicting types for built-in function 'exp2f' >>> _configtest.c:17: warning: conflicting types for built-in function 'atanf' >>> _configtest.c:18: warning: conflicting types for built-in function 'fmodf' >>> _configtest.c:19: warning: conflicting types for built-in function 'atan2f' >>> _configtest.c:20: warning: conflicting types for built-in function 'modff' >>> _configtest.c:21: warning: conflicting types for built-in function 'ceilf' >>> _configtest.c:22: warning: conflicting types for built-in function 'log1pf' >>> _configtest.c:23: warning: conflicting types for built-in function 'asinf' >>> _configtest.c:24: warning: conflicting types for built-in function 'copysignf' >>> _configtest.c:25: warning: conflicting types for built-in function 'acoshf' >>> _configtest.c:26: warning: conflicting types for built-in function 'sinf' >>> _configtest.c:27: warning: conflicting types for built-in function 'tanf' >>> _configtest.c:28: warning: conflicting types for built-in function 'atanhf' >>> _configtest.c:29: warning: conflicting types for built-in function 'truncf' >>> _configtest.c:30: warning: conflicting types for built-in function 'asinhf' >>> _configtest.c:31: warning: conflicting types for built-in function 'frexpf' >>> _configtest.c:32: warning: conflicting types for built-in function 'powf' >>> _configtest.c:33: warning: conflicting types for built-in function 'expf' >>> _configtest.c:34: warning: conflicting types for built-in function 'expm1f' >>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>> success! >>> removing: _configtest.c _configtest.o _configtest >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:1: warning: conflicting types for built-in function 'tanhl' >>> _configtest.c:2: warning: conflicting types for built-in function 'log10l' >>> _configtest.c:3: warning: conflicting types for built-in function 'nextafterl' >>> _configtest.c:4: warning: conflicting types for built-in function 'coshl' >>> _configtest.c:5: warning: conflicting types for built-in function 'cosl' >>> _configtest.c:6: warning: conflicting types for built-in function 'floorl' >>> _configtest.c:7: warning: conflicting types for built-in function 'rintl' >>> _configtest.c:8: warning: conflicting types for built-in function 'fabsl' >>> _configtest.c:9: warning: conflicting types for built-in function 'acosl' >>> _configtest.c:10: warning: conflicting types for built-in function 'ldexpl' >>> _configtest.c:11: warning: conflicting types for built-in function 'sqrtl' >>> _configtest.c:12: warning: conflicting types for built-in function 'logl' >>> _configtest.c:13: warning: conflicting types for built-in function 'expm1l' >>> _configtest.c:14: warning: conflicting types for built-in function 'hypotl' >>> _configtest.c:15: warning: conflicting types for built-in function 'log2l' >>> _configtest.c:16: warning: conflicting types for built-in function 'copysignl' >>> _configtest.c:17: warning: conflicting types for built-in function 'exp2l' >>> _configtest.c:18: warning: conflicting types for built-in function 'atanl' >>> _configtest.c:19: warning: conflicting types for built-in function 'frexpl' >>> _configtest.c:20: warning: conflicting types for built-in function 'atan2l' >>> _configtest.c:21: warning: conflicting types for built-in function 'sinhl' >>> _configtest.c:22: warning: conflicting types for built-in function 'fmodl' >>> _configtest.c:23: warning: conflicting types for built-in function 'log1pl' >>> _configtest.c:24: warning: conflicting types for built-in function 'asinl' >>> _configtest.c:25: warning: conflicting types for built-in function 'ceill' >>> _configtest.c:26: warning: conflicting types for built-in function 'sinl' >>> _configtest.c:27: warning: conflicting types for built-in function 'acoshl' >>> _configtest.c:28: warning: conflicting types for built-in function 'atanhl' >>> _configtest.c:29: warning: conflicting types for built-in function 'tanl' >>> _configtest.c:30: warning: conflicting types for built-in function 'truncl' >>> _configtest.c:31: warning: conflicting types for built-in function 'powl' >>> _configtest.c:32: warning: conflicting types for built-in function 'expl' >>> _configtest.c:33: warning: conflicting types for built-in function 'modfl' >>> _configtest.c:34: warning: conflicting types for built-in function 'asinhl' >>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>> success! >>> removing: _configtest.c _configtest.o _configtest >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:6: warning: function declaration isn't a prototype >>> success! >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:6: warning: function declaration isn't a prototype >>> success! >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:6: warning: function declaration isn't a prototype >>> success! >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:6: warning: function declaration isn't a prototype >>> success! >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> success! >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:1: warning: conflicting types for built-in function 'cexp' >>> _configtest.c:3: warning: conflicting types for built-in function 'ccos' >>> _configtest.c:4: warning: conflicting types for built-in function 'cimag' >>> _configtest.c:5: warning: conflicting types for built-in function 'cabs' >>> _configtest.c:6: warning: conflicting types for built-in function 'cpow' >>> _configtest.c:7: warning: conflicting types for built-in function 'csqrt' >>> _configtest.c:8: warning: conflicting types for built-in function 'carg' >>> _configtest.c:9: warning: conflicting types for built-in function 'creal' >>> _configtest.c:10: warning: conflicting types for built-in function 'csin' >>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>> success! >>> removing: _configtest.c _configtest.o _configtest >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:1: warning: conflicting types for built-in function 'ccosf' >>> _configtest.c:2: warning: conflicting types for built-in function 'cargf' >>> _configtest.c:3: warning: conflicting types for built-in function 'csqrtf' >>> _configtest.c:4: warning: conflicting types for built-in function 'cpowf' >>> _configtest.c:5: warning: conflicting types for built-in function 'cexpf' >>> _configtest.c:6: warning: conflicting types for built-in function 'crealf' >>> _configtest.c:7: warning: conflicting types for built-in function 'csinf' >>> _configtest.c:8: warning: conflicting types for built-in function 'cabsf' >>> _configtest.c:10: warning: conflicting types for built-in function 'cimagf' >>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>> success! >>> removing: _configtest.c _configtest.o _configtest >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:1: warning: conflicting types for built-in function 'csqrtl' >>> _configtest.c:2: warning: conflicting types for built-in function 'cargl' >>> _configtest.c:3: warning: conflicting types for built-in function 'cexpl' >>> _configtest.c:4: warning: conflicting types for built-in function 'ccosl' >>> _configtest.c:5: warning: conflicting types for built-in function 'cpowl' >>> _configtest.c:6: warning: conflicting types for built-in function 'cimagl' >>> _configtest.c:7: warning: conflicting types for built-in function 'csinl' >>> _configtest.c:8: warning: conflicting types for built-in function 'creall' >>> _configtest.c:10: warning: conflicting types for built-in function 'cabsl' >>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>> success! >>> removing: _configtest.c _configtest.o _configtest >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> success! >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:5: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:7: error: `Py_UNICODE_WIDE' undeclared (first use in >>> this function) >>> _configtest.c:7: error: (Each undeclared identifier is reported only once >>> _configtest.c:7: error: for each function it appears in.) >>> _configtest.c:5: warning: function declaration isn't a prototype >>> _configtest.c: In function `main': >>> _configtest.c:7: error: `Py_UNICODE_WIDE' undeclared (first use in >>> this function) >>> _configtest.c:7: error: (Each undeclared identifier is reported only once >>> _configtest.c:7: error: for each function it appears in.) >>> failure. >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> removing: _configtest.c _configtest.o >>> ('File:', 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h') >>> #define HAVE_ENDIAN_H 1 >>> #define SIZEOF_PY_INTPTR_T 4 >>> #define SIZEOF_PY_LONG_LONG 8 >>> #define MATHLIB m >>> #define HAVE_SIN >>> #define HAVE_COS >>> #define HAVE_TAN >>> #define HAVE_SINH >>> #define HAVE_COSH >>> #define HAVE_TANH >>> #define HAVE_FABS >>> #define HAVE_FLOOR >>> #define HAVE_CEIL >>> #define HAVE_SQRT >>> #define HAVE_LOG10 >>> #define HAVE_LOG >>> #define HAVE_EXP >>> #define HAVE_ASIN >>> #define HAVE_ACOS >>> #define HAVE_ATAN >>> #define HAVE_FMOD >>> #define HAVE_MODF >>> #define HAVE_FREXP >>> #define HAVE_LDEXP >>> #define HAVE_EXPM1 >>> #define HAVE_LOG1P >>> #define HAVE_ACOSH >>> #define HAVE_ASINH >>> #define HAVE_ATANH >>> #define HAVE_RINT >>> #define HAVE_TRUNC >>> #define HAVE_EXP2 >>> #define HAVE_LOG2 >>> #define HAVE_HYPOT >>> #define HAVE_ATAN2 >>> #define HAVE_POW >>> #define HAVE_COPYSIGN >>> #define HAVE_NEXTAFTER >>> #define HAVE_SINF >>> #define HAVE_COSF >>> #define HAVE_TANF >>> #define HAVE_SINHF >>> #define HAVE_COSHF >>> #define HAVE_TANHF >>> #define HAVE_FABSF >>> #define HAVE_FLOORF >>> #define HAVE_CEILF >>> #define HAVE_RINTF >>> #define HAVE_TRUNCF >>> #define HAVE_SQRTF >>> #define HAVE_LOG10F >>> #define HAVE_LOGF >>> #define HAVE_LOG1PF >>> #define HAVE_EXPF >>> #define HAVE_EXPM1F >>> #define HAVE_ASINF >>> #define HAVE_ACOSF >>> #define HAVE_ATANF >>> #define HAVE_ASINHF >>> #define HAVE_ACOSHF >>> #define HAVE_ATANHF >>> #define HAVE_HYPOTF >>> #define HAVE_ATAN2F >>> #define HAVE_POWF >>> #define HAVE_FMODF >>> #define HAVE_MODFF >>> #define HAVE_FREXPF >>> #define HAVE_LDEXPF >>> #define HAVE_EXP2F >>> #define HAVE_LOG2F >>> #define HAVE_COPYSIGNF >>> #define HAVE_NEXTAFTERF >>> #define HAVE_SINL >>> #define HAVE_COSL >>> #define HAVE_TANL >>> #define HAVE_SINHL >>> #define HAVE_COSHL >>> #define HAVE_TANHL >>> #define HAVE_FABSL >>> #define HAVE_FLOORL >>> #define HAVE_CEILL >>> #define HAVE_RINTL >>> #define HAVE_TRUNCL >>> #define HAVE_SQRTL >>> #define HAVE_LOG10L >>> #define HAVE_LOGL >>> #define HAVE_LOG1PL >>> #define HAVE_EXPL >>> #define HAVE_EXPM1L >>> #define HAVE_ASINL >>> #define HAVE_ACOSL >>> #define HAVE_ATANL >>> #define HAVE_ASINHL >>> #define HAVE_ACOSHL >>> #define HAVE_ATANHL >>> #define HAVE_HYPOTL >>> #define HAVE_ATAN2L >>> #define HAVE_POWL >>> #define HAVE_FMODL >>> #define HAVE_MODFL >>> #define HAVE_FREXPL >>> #define HAVE_LDEXPL >>> #define HAVE_EXP2L >>> #define HAVE_LOG2L >>> #define HAVE_COPYSIGNL >>> #define HAVE_NEXTAFTERL >>> #define HAVE_DECL_ISNAN >>> #define HAVE_DECL_ISINF >>> #define HAVE_DECL_SIGNBIT >>> #define HAVE_DECL_ISFINITE >>> #define HAVE_COMPLEX_H >>> #define HAVE_CREAL >>> #define HAVE_CIMAG >>> #define HAVE_CABS >>> #define HAVE_CARG >>> #define HAVE_CEXP >>> #define HAVE_CSQRT >>> #define HAVE_CLOG >>> #define HAVE_CCOS >>> #define HAVE_CSIN >>> #define HAVE_CPOW >>> #define HAVE_CREALF >>> #define HAVE_CIMAGF >>> #define HAVE_CABSF >>> #define HAVE_CARGF >>> #define HAVE_CEXPF >>> #define HAVE_CSQRTF >>> #define HAVE_CLOGF >>> #define HAVE_CCOSF >>> #define HAVE_CSINF >>> #define HAVE_CPOWF >>> #define HAVE_CREALL >>> #define HAVE_CIMAGL >>> #define HAVE_CABSL >>> #define HAVE_CARGL >>> #define HAVE_CEXPL >>> #define HAVE_CSQRTL >>> #define HAVE_CLOGL >>> #define HAVE_CCOSL >>> #define HAVE_CSINL >>> #define HAVE_CPOWL >>> #define HAVE_LDOUBLE_INTEL_EXTENDED_12_BYTES_LE 1 >>> #ifndef __cplusplus >>> /* #undef inline */ >>> #endif >>> >>> #ifndef _NPY_NPY_CONFIG_H_ >>> #error config.h should never be included directly, include npy_config.h instead >>> #endif >>> >>> EOF >>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' >>> to sources. >>> Generating build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:1: warning: conflicting types for built-in function 'exp' >>> gcc -m32 -pthread _configtest.o -o _configtest >>> _configtest.o(.text+0x19): In function `main': >>> /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' >>> collect2: ld returned 1 exit status >>> _configtest.o(.text+0x19): In function `main': >>> /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' >>> collect2: ld returned 1 exit status >>> failure. >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:1: warning: conflicting types for built-in function 'exp' >>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>> success! >>> removing: _configtest.c _configtest.o _configtest >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:5: warning: function declaration isn't a prototype >>> success! >>> removing: _configtest.c _configtest.o >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> _configtest.c:4: warning: function declaration isn't a prototype >>> _configtest.c:5:18: warning: extra tokens at end of #ifndef directive >>> _configtest.c: In function `main': >>> _configtest.c:4: warning: control reaches end of non-void function >>> success! >>> removing: _configtest.c _configtest.o >>> File: build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h >>> #define NPY_HAVE_ENDIAN_H 1 >>> #define NPY_SIZEOF_SHORT SIZEOF_SHORT >>> #define NPY_SIZEOF_INT SIZEOF_INT >>> #define NPY_SIZEOF_LONG SIZEOF_LONG >>> #define NPY_SIZEOF_FLOAT 4 >>> #define NPY_SIZEOF_COMPLEX_FLOAT 8 >>> #define NPY_SIZEOF_DOUBLE 8 >>> #define NPY_SIZEOF_COMPLEX_DOUBLE 16 >>> #define NPY_SIZEOF_LONGDOUBLE 12 >>> #define NPY_SIZEOF_COMPLEX_LONGDOUBLE 24 >>> #define NPY_SIZEOF_PY_INTPTR_T 4 >>> #define NPY_SIZEOF_PY_LONG_LONG 8 >>> #define NPY_SIZEOF_LONGLONG 8 >>> #define NPY_NO_SMP 1 >>> #define NPY_HAVE_DECL_ISNAN >>> #define NPY_HAVE_DECL_ISINF >>> #define NPY_HAVE_DECL_SIGNBIT >>> #define NPY_HAVE_DECL_ISFINITE >>> #define NPY_USE_C99_COMPLEX >>> #define NPY_HAVE_COMPLEX_DOUBLE 1 >>> #define NPY_HAVE_COMPLEX_FLOAT 1 >>> #define NPY_HAVE_COMPLEX_LONG_DOUBLE 1 >>> #define NPY_USE_C99_FORMATS 1 >>> #define NPY_VISIBILITY_HIDDEN __attribute__((visibility("hidden"))) >>> #define NPY_ABI_VERSION 0x01000009 >>> #define NPY_API_VERSION 0x00000004 >>> >>> #ifndef __STDC_FORMAT_MACROS >>> #define __STDC_FORMAT_MACROS 1 >>> #endif >>> >>> EOF >>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' >>> to sources. >>> executing numpy/core/code_generators/generate_numpy_api.py >>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__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/include/numpy/config.h', >>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', >>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h'] >>> building extension "numpy.core.multiarray" sources >>> non-existing path in 'numpy/core': >>> 'build/src.linux-x86_64-2.4/numpy/core/src/multiarray' >>> creating build/src.linux-x86_64-2.4/numpy/core/src/multiarray >>> conv_template:> >>> build/src.linux-x86_64-2.4/numpy/core/src/multiarray/scalartypes.c >>> conv_template:> >>> build/src.linux-x86_64-2.4/numpy/core/src/multiarray/arraytypes.c >>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' >>> to sources. >>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' >>> to sources. >>> executing numpy/core/code_generators/generate_numpy_api.py >>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h' >>> to sources. >>> numpy.core - nothing done with h_files = >>> ['build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h', >>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', >>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h'] >>> building extension "numpy.core.umath" sources >>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' >>> to sources. >>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' >>> to sources. >>> executing numpy/core/code_generators/generate_ufunc_api.py >>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__ufunc_api.h' >>> to sources. >>> non-existing path in 'numpy/core': >>> 'build/src.linux-x86_64-2.4/numpy/core/src/umath' >>> creating build/src.linux-x86_64-2.4/numpy/core/src/umath >>> conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/umath/loops.c >>> conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/umath/umathmodule.c >>> conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/umath/funcs.inc >>> adding 'build/src.linux-x86_64-2.4/numpy/core/src/umath' to include_dirs. >>> numpy.core - nothing done with h_files = >>> ['build/src.linux-x86_64-2.4/numpy/core/src/umath/funcs.inc', >>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h', >>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', >>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__ufunc_api.h'] >>> building extension "numpy.core.scalarmath" sources >>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' >>> to sources. >>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' >>> to sources. >>> executing numpy/core/code_generators/generate_numpy_api.py >>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h' >>> to sources. >>> executing numpy/core/code_generators/generate_ufunc_api.py >>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__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/include/numpy/config.h', >>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', >>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h', >>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__ufunc_api.h'] >>> building extension "numpy.core._dotblas" sources >>> building extension "numpy.core.umath_tests" sources >>> conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/umath/umath_tests.c >>> building extension "numpy.core.multiarray_tests" sources >>> conv_template:> >>> build/src.linux-x86_64-2.4/numpy/core/src/multiarray/multiarray_tests.c >>> building extension "numpy.lib._compiled_base" sources >>> building extension "numpy.numarray._capi" sources >>> building extension "numpy.fft.fftpack_lite" sources >>> building extension "numpy.linalg.lapack_lite" sources >>> creating build/src.linux-x86_64-2.4/numpy/linalg >>> adding 'numpy/linalg/lapack_litemodule.c' to sources. >>> adding 'numpy/linalg/python_xerbla.c' to sources. >>> building extension "numpy.random.mtrand" sources >>> creating build/src.linux-x86_64-2.4/numpy/random >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 -c' >>> gcc: _configtest.c >>> gcc -m32 -pthread _configtest.o -o _configtest >>> _configtest >>> failure. >>> removing: _configtest.c _configtest.o _configtest >>> building data_files sources >>> build_src: building npy-pkg config files >>> running build_py >>> creating build/lib.linux-x86_64-2.4 >>> creating build/lib.linux-x86_64-2.4/numpy >>> copying numpy/version.py -> build/lib.linux-x86_64-2.4/numpy >>> copying numpy/matlib.py -> build/lib.linux-x86_64-2.4/numpy >>> copying numpy/ctypeslib.py -> build/lib.linux-x86_64-2.4/numpy >>> copying numpy/setupscons.py -> build/lib.linux-x86_64-2.4/numpy >>> copying numpy/__init__.py -> build/lib.linux-x86_64-2.4/numpy >>> copying numpy/setup.py -> build/lib.linux-x86_64-2.4/numpy >>> copying numpy/dual.py -> build/lib.linux-x86_64-2.4/numpy >>> copying numpy/_import_tools.py -> build/lib.linux-x86_64-2.4/numpy >>> copying numpy/add_newdocs.py -> build/lib.linux-x86_64-2.4/numpy >>> copying build/src.linux-x86_64-2.4/numpy/__config__.py -> >>> build/lib.linux-x86_64-2.4/numpy >>> creating build/lib.linux-x86_64-2.4/numpy/distutils >>> copying numpy/distutils/from_template.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils >>> copying numpy/distutils/npy_pkg_config.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils >>> copying numpy/distutils/compat.py -> build/lib.linux-x86_64-2.4/numpy/distutils >>> copying numpy/distutils/setupscons.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils >>> copying numpy/distutils/__init__.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils >>> copying numpy/distutils/lib2def.py -> build/lib.linux-x86_64-2.4/numpy/distutils >>> copying numpy/distutils/interactive.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils >>> copying numpy/distutils/info.py -> build/lib.linux-x86_64-2.4/numpy/distutils >>> copying numpy/distutils/environment.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils >>> copying numpy/distutils/setup.py -> build/lib.linux-x86_64-2.4/numpy/distutils >>> copying numpy/distutils/cpuinfo.py -> build/lib.linux-x86_64-2.4/numpy/distutils >>> copying numpy/distutils/extension.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils >>> copying numpy/distutils/core.py -> build/lib.linux-x86_64-2.4/numpy/distutils >>> copying numpy/distutils/intelccompiler.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils >>> copying numpy/distutils/log.py -> build/lib.linux-x86_64-2.4/numpy/distutils >>> copying numpy/distutils/__version__.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils >>> copying numpy/distutils/unixccompiler.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils >>> copying numpy/distutils/misc_util.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils >>> copying numpy/distutils/line_endings.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils >>> copying numpy/distutils/exec_command.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils >>> copying numpy/distutils/conv_template.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils >>> copying numpy/distutils/ccompiler.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils >>> copying numpy/distutils/mingw32ccompiler.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils >>> copying numpy/distutils/system_info.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils >>> copying numpy/distutils/numpy_distribution.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils >>> copying build/src.linux-x86_64-2.4/numpy/distutils/__config__.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils >>> creating build/lib.linux-x86_64-2.4/numpy/distutils/command >>> copying numpy/distutils/command/install.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>> copying numpy/distutils/command/egg_info.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>> copying numpy/distutils/command/install_clib.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>> copying numpy/distutils/command/bdist_rpm.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>> copying numpy/distutils/command/develop.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>> copying numpy/distutils/command/install_data.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>> copying numpy/distutils/command/__init__.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>> copying numpy/distutils/command/build_py.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>> copying numpy/distutils/command/build_src.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>> copying numpy/distutils/command/build_clib.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>> copying numpy/distutils/command/build_ext.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>> copying numpy/distutils/command/autodist.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>> copying numpy/distutils/command/install_headers.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>> copying numpy/distutils/command/config.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>> copying numpy/distutils/command/config_compiler.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>> copying numpy/distutils/command/build.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>> copying numpy/distutils/command/build_scripts.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>> copying numpy/distutils/command/sdist.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>> copying numpy/distutils/command/scons.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>> creating build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>> copying numpy/distutils/fcompiler/none.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>> copying numpy/distutils/fcompiler/hpux.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>> copying numpy/distutils/fcompiler/compaq.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>> copying numpy/distutils/fcompiler/absoft.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>> copying numpy/distutils/fcompiler/vast.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>> copying numpy/distutils/fcompiler/nag.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>> copying numpy/distutils/fcompiler/__init__.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>> copying numpy/distutils/fcompiler/sun.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>> copying numpy/distutils/fcompiler/mips.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>> copying numpy/distutils/fcompiler/intel.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>> copying numpy/distutils/fcompiler/gnu.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>> copying numpy/distutils/fcompiler/g95.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>> copying numpy/distutils/fcompiler/pg.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>> copying numpy/distutils/fcompiler/ibm.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>> copying numpy/distutils/fcompiler/lahey.py -> >>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>> creating build/lib.linux-x86_64-2.4/numpy/testing >>> copying numpy/testing/nulltester.py -> build/lib.linux-x86_64-2.4/numpy/testing >>> copying numpy/testing/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/testing >>> copying numpy/testing/__init__.py -> build/lib.linux-x86_64-2.4/numpy/testing >>> copying numpy/testing/setup.py -> build/lib.linux-x86_64-2.4/numpy/testing >>> copying numpy/testing/decorators.py -> build/lib.linux-x86_64-2.4/numpy/testing >>> copying numpy/testing/utils.py -> build/lib.linux-x86_64-2.4/numpy/testing >>> copying numpy/testing/noseclasses.py -> build/lib.linux-x86_64-2.4/numpy/testing >>> copying numpy/testing/numpytest.py -> build/lib.linux-x86_64-2.4/numpy/testing >>> copying numpy/testing/nosetester.py -> build/lib.linux-x86_64-2.4/numpy/testing >>> creating build/lib.linux-x86_64-2.4/numpy/f2py >>> copying numpy/f2py/auxfuncs.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>> copying numpy/f2py/common_rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>> copying numpy/f2py/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>> copying numpy/f2py/__init__.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>> copying numpy/f2py/cb_rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>> copying numpy/f2py/info.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>> copying numpy/f2py/setup.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>> copying numpy/f2py/f2py2e.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>> copying numpy/f2py/cfuncs.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>> copying numpy/f2py/crackfortran.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>> copying numpy/f2py/use_rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>> copying numpy/f2py/diagnose.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>> copying numpy/f2py/f2py_testing.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>> copying numpy/f2py/__version__.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>> copying numpy/f2py/capi_maps.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>> copying numpy/f2py/func2subr.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>> copying numpy/f2py/f90mod_rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>> copying numpy/f2py/rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>> creating build/lib.linux-x86_64-2.4/numpy/core >>> copying numpy/core/defchararray.py -> build/lib.linux-x86_64-2.4/numpy/core >>> copying numpy/core/numeric.py -> build/lib.linux-x86_64-2.4/numpy/core >>> copying numpy/core/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/core >>> copying numpy/core/__init__.py -> build/lib.linux-x86_64-2.4/numpy/core >>> copying numpy/core/info.py -> build/lib.linux-x86_64-2.4/numpy/core >>> copying numpy/core/function_base.py -> build/lib.linux-x86_64-2.4/numpy/core >>> copying numpy/core/getlimits.py -> build/lib.linux-x86_64-2.4/numpy/core >>> copying numpy/core/setup.py -> build/lib.linux-x86_64-2.4/numpy/core >>> copying numpy/core/fromnumeric.py -> build/lib.linux-x86_64-2.4/numpy/core >>> copying numpy/core/shape_base.py -> build/lib.linux-x86_64-2.4/numpy/core >>> copying numpy/core/setup_common.py -> build/lib.linux-x86_64-2.4/numpy/core >>> copying numpy/core/records.py -> build/lib.linux-x86_64-2.4/numpy/core >>> copying numpy/core/memmap.py -> build/lib.linux-x86_64-2.4/numpy/core >>> copying numpy/core/arrayprint.py -> build/lib.linux-x86_64-2.4/numpy/core >>> copying numpy/core/numerictypes.py -> build/lib.linux-x86_64-2.4/numpy/core >>> copying numpy/core/machar.py -> build/lib.linux-x86_64-2.4/numpy/core >>> copying numpy/core/_mx_datetime_parser.py -> >>> build/lib.linux-x86_64-2.4/numpy/core >>> copying numpy/core/scons_support.py -> build/lib.linux-x86_64-2.4/numpy/core >>> copying numpy/core/_internal.py -> build/lib.linux-x86_64-2.4/numpy/core >>> copying numpy/core/code_generators/generate_numpy_api.py -> >>> build/lib.linux-x86_64-2.4/numpy/core >>> creating build/lib.linux-x86_64-2.4/numpy/lib >>> copying numpy/lib/_datasource.py -> build/lib.linux-x86_64-2.4/numpy/lib >>> copying numpy/lib/arraysetops.py -> build/lib.linux-x86_64-2.4/numpy/lib >>> copying numpy/lib/index_tricks.py -> build/lib.linux-x86_64-2.4/numpy/lib >>> copying numpy/lib/format.py -> build/lib.linux-x86_64-2.4/numpy/lib >>> copying numpy/lib/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/lib >>> copying numpy/lib/__init__.py -> build/lib.linux-x86_64-2.4/numpy/lib >>> copying numpy/lib/info.py -> build/lib.linux-x86_64-2.4/numpy/lib >>> copying numpy/lib/function_base.py -> build/lib.linux-x86_64-2.4/numpy/lib >>> copying numpy/lib/setup.py -> build/lib.linux-x86_64-2.4/numpy/lib >>> copying numpy/lib/arrayterator.py -> build/lib.linux-x86_64-2.4/numpy/lib >>> copying numpy/lib/ufunclike.py -> build/lib.linux-x86_64-2.4/numpy/lib >>> copying numpy/lib/shape_base.py -> build/lib.linux-x86_64-2.4/numpy/lib >>> copying numpy/lib/user_array.py -> build/lib.linux-x86_64-2.4/numpy/lib >>> copying numpy/lib/type_check.py -> build/lib.linux-x86_64-2.4/numpy/lib >>> copying numpy/lib/stride_tricks.py -> build/lib.linux-x86_64-2.4/numpy/lib >>> copying numpy/lib/recfunctions.py -> build/lib.linux-x86_64-2.4/numpy/lib >>> copying numpy/lib/npyio.py -> build/lib.linux-x86_64-2.4/numpy/lib >>> copying numpy/lib/_iotools.py -> build/lib.linux-x86_64-2.4/numpy/lib >>> copying numpy/lib/utils.py -> build/lib.linux-x86_64-2.4/numpy/lib >>> copying numpy/lib/financial.py -> build/lib.linux-x86_64-2.4/numpy/lib >>> copying numpy/lib/twodim_base.py -> build/lib.linux-x86_64-2.4/numpy/lib >>> copying numpy/lib/polynomial.py -> build/lib.linux-x86_64-2.4/numpy/lib >>> copying numpy/lib/scimath.py -> build/lib.linux-x86_64-2.4/numpy/lib >>> creating build/lib.linux-x86_64-2.4/numpy/oldnumeric >>> copying numpy/oldnumeric/functions.py -> >>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>> copying numpy/oldnumeric/alter_code1.py -> >>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>> copying numpy/oldnumeric/misc.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>> copying numpy/oldnumeric/compat.py -> >>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>> copying numpy/oldnumeric/setupscons.py -> >>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>> copying numpy/oldnumeric/__init__.py -> >>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>> copying numpy/oldnumeric/linear_algebra.py -> >>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>> copying numpy/oldnumeric/setup.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>> copying numpy/oldnumeric/random_array.py -> >>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>> copying numpy/oldnumeric/user_array.py -> >>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>> copying numpy/oldnumeric/alter_code2.py -> >>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>> copying numpy/oldnumeric/fft.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>> copying numpy/oldnumeric/matrix.py -> >>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>> copying numpy/oldnumeric/fix_default_axis.py -> >>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>> copying numpy/oldnumeric/rng_stats.py -> >>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>> copying numpy/oldnumeric/mlab.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>> copying numpy/oldnumeric/ma.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>> copying numpy/oldnumeric/ufuncs.py -> >>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>> copying numpy/oldnumeric/rng.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>> copying numpy/oldnumeric/array_printer.py -> >>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>> copying numpy/oldnumeric/typeconv.py -> >>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>> copying numpy/oldnumeric/precision.py -> >>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>> copying numpy/oldnumeric/arrayfns.py -> >>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>> creating build/lib.linux-x86_64-2.4/numpy/numarray >>> copying numpy/numarray/nd_image.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>> copying numpy/numarray/util.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>> copying numpy/numarray/convolve.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>> copying numpy/numarray/functions.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>> copying numpy/numarray/alter_code1.py -> >>> build/lib.linux-x86_64-2.4/numpy/numarray >>> copying numpy/numarray/compat.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>> copying numpy/numarray/setupscons.py -> >>> build/lib.linux-x86_64-2.4/numpy/numarray >>> copying numpy/numarray/__init__.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>> copying numpy/numarray/linear_algebra.py -> >>> build/lib.linux-x86_64-2.4/numpy/numarray >>> copying numpy/numarray/setup.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>> copying numpy/numarray/random_array.py -> >>> build/lib.linux-x86_64-2.4/numpy/numarray >>> copying numpy/numarray/alter_code2.py -> >>> build/lib.linux-x86_64-2.4/numpy/numarray >>> copying numpy/numarray/fft.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>> copying numpy/numarray/matrix.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>> copying numpy/numarray/numerictypes.py -> >>> build/lib.linux-x86_64-2.4/numpy/numarray >>> copying numpy/numarray/image.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>> copying numpy/numarray/mlab.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>> copying numpy/numarray/ma.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>> copying numpy/numarray/session.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>> copying numpy/numarray/ufuncs.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>> creating build/lib.linux-x86_64-2.4/numpy/fft >>> copying numpy/fft/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/fft >>> copying numpy/fft/__init__.py -> build/lib.linux-x86_64-2.4/numpy/fft >>> copying numpy/fft/info.py -> build/lib.linux-x86_64-2.4/numpy/fft >>> copying numpy/fft/setup.py -> build/lib.linux-x86_64-2.4/numpy/fft >>> copying numpy/fft/fftpack.py -> build/lib.linux-x86_64-2.4/numpy/fft >>> copying numpy/fft/helper.py -> build/lib.linux-x86_64-2.4/numpy/fft >>> creating build/lib.linux-x86_64-2.4/numpy/linalg >>> copying numpy/linalg/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/linalg >>> copying numpy/linalg/__init__.py -> build/lib.linux-x86_64-2.4/numpy/linalg >>> copying numpy/linalg/info.py -> build/lib.linux-x86_64-2.4/numpy/linalg >>> copying numpy/linalg/setup.py -> build/lib.linux-x86_64-2.4/numpy/linalg >>> copying numpy/linalg/linalg.py -> build/lib.linux-x86_64-2.4/numpy/linalg >>> creating build/lib.linux-x86_64-2.4/numpy/random >>> copying numpy/random/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/random >>> copying numpy/random/__init__.py -> build/lib.linux-x86_64-2.4/numpy/random >>> copying numpy/random/info.py -> build/lib.linux-x86_64-2.4/numpy/random >>> copying numpy/random/setup.py -> build/lib.linux-x86_64-2.4/numpy/random >>> creating build/lib.linux-x86_64-2.4/numpy/ma >>> copying numpy/ma/version.py -> build/lib.linux-x86_64-2.4/numpy/ma >>> copying numpy/ma/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/ma >>> copying numpy/ma/__init__.py -> build/lib.linux-x86_64-2.4/numpy/ma >>> copying numpy/ma/setup.py -> build/lib.linux-x86_64-2.4/numpy/ma >>> copying numpy/ma/bench.py -> build/lib.linux-x86_64-2.4/numpy/ma >>> copying numpy/ma/core.py -> build/lib.linux-x86_64-2.4/numpy/ma >>> copying numpy/ma/testutils.py -> build/lib.linux-x86_64-2.4/numpy/ma >>> copying numpy/ma/timer_comparison.py -> build/lib.linux-x86_64-2.4/numpy/ma >>> copying numpy/ma/extras.py -> build/lib.linux-x86_64-2.4/numpy/ma >>> copying numpy/ma/mrecords.py -> build/lib.linux-x86_64-2.4/numpy/ma >>> creating build/lib.linux-x86_64-2.4/numpy/matrixlib >>> copying numpy/matrixlib/setupscons.py -> >>> build/lib.linux-x86_64-2.4/numpy/matrixlib >>> copying numpy/matrixlib/__init__.py -> >>> build/lib.linux-x86_64-2.4/numpy/matrixlib >>> copying numpy/matrixlib/setup.py -> build/lib.linux-x86_64-2.4/numpy/matrixlib >>> copying numpy/matrixlib/defmatrix.py -> >>> build/lib.linux-x86_64-2.4/numpy/matrixlib >>> creating build/lib.linux-x86_64-2.4/numpy/compat >>> copying numpy/compat/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/compat >>> copying numpy/compat/__init__.py -> build/lib.linux-x86_64-2.4/numpy/compat >>> copying numpy/compat/setup.py -> build/lib.linux-x86_64-2.4/numpy/compat >>> copying numpy/compat/py3k.py -> build/lib.linux-x86_64-2.4/numpy/compat >>> copying numpy/compat/_inspect.py -> build/lib.linux-x86_64-2.4/numpy/compat >>> creating build/lib.linux-x86_64-2.4/numpy/polynomial >>> copying numpy/polynomial/__init__.py -> >>> build/lib.linux-x86_64-2.4/numpy/polynomial >>> copying numpy/polynomial/setup.py -> build/lib.linux-x86_64-2.4/numpy/polynomial >>> copying numpy/polynomial/chebyshev.py -> >>> build/lib.linux-x86_64-2.4/numpy/polynomial >>> copying numpy/polynomial/polynomial.py -> >>> build/lib.linux-x86_64-2.4/numpy/polynomial >>> copying numpy/polynomial/polyutils.py -> >>> build/lib.linux-x86_64-2.4/numpy/polynomial >>> copying numpy/polynomial/polytemplate.py -> >>> build/lib.linux-x86_64-2.4/numpy/polynomial >>> creating build/lib.linux-x86_64-2.4/numpy/doc >>> copying numpy/doc/byteswapping.py -> build/lib.linux-x86_64-2.4/numpy/doc >>> copying numpy/doc/glossary.py -> build/lib.linux-x86_64-2.4/numpy/doc >>> copying numpy/doc/indexing.py -> build/lib.linux-x86_64-2.4/numpy/doc >>> copying numpy/doc/misc.py -> build/lib.linux-x86_64-2.4/numpy/doc >>> copying numpy/doc/internals.py -> build/lib.linux-x86_64-2.4/numpy/doc >>> copying numpy/doc/__init__.py -> build/lib.linux-x86_64-2.4/numpy/doc >>> copying numpy/doc/creation.py -> build/lib.linux-x86_64-2.4/numpy/doc >>> copying numpy/doc/jargon.py -> build/lib.linux-x86_64-2.4/numpy/doc >>> copying numpy/doc/basics.py -> build/lib.linux-x86_64-2.4/numpy/doc >>> copying numpy/doc/io.py -> build/lib.linux-x86_64-2.4/numpy/doc >>> copying numpy/doc/methods_vs_functions.py -> >>> build/lib.linux-x86_64-2.4/numpy/doc >>> copying numpy/doc/broadcasting.py -> build/lib.linux-x86_64-2.4/numpy/doc >>> copying numpy/doc/constants.py -> build/lib.linux-x86_64-2.4/numpy/doc >>> copying numpy/doc/howtofind.py -> build/lib.linux-x86_64-2.4/numpy/doc >>> copying numpy/doc/ufuncs.py -> build/lib.linux-x86_64-2.4/numpy/doc >>> copying numpy/doc/subclassing.py -> build/lib.linux-x86_64-2.4/numpy/doc >>> copying numpy/doc/structured_arrays.py -> build/lib.linux-x86_64-2.4/numpy/doc >>> copying numpy/doc/performance.py -> build/lib.linux-x86_64-2.4/numpy/doc >>> running build_clib >>> customize UnixCCompiler >>> customize UnixCCompiler using build_clib >>> building 'npymath' library >>> compiling C sources >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> creating build/temp.linux-x86_64-2.4 >>> creating build/temp.linux-x86_64-2.4/build >>> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4 >>> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy >>> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core >>> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src >>> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/npymath >>> compile options: '-Inumpy/core/include >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>> gcc: build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math.c >>> In file included from numpy/core/src/private/npy_config.h:4, >>> from numpy/core/src/npymath/npy_math_private.h:24, >>> from numpy/core/src/npymath/npy_math.c.src:56: >>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >>> warning: "HAVE_HYPOT" redefined >>> In file included from /home/sanjey/include/python2.4/Python.h:8, >>> from numpy/core/src/npymath/npy_math_private.h:21, >>> from numpy/core/src/npymath/npy_math.c.src:56: >>> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >>> location of the previous definition >>> gcc: build/src.linux-x86_64-2.4/numpy/core/src/npymath/ieee754.c >>> In file included from numpy/core/src/private/npy_config.h:4, >>> from numpy/core/src/npymath/npy_math_common.h:8, >>> from numpy/core/src/npymath/ieee754.c.src:7: >>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >>> warning: "HAVE_HYPOT" redefined >>> In file included from /home/sanjey/include/python2.4/Python.h:8, >>> from numpy/core/src/npymath/npy_math_common.h:4, >>> from numpy/core/src/npymath/ieee754.c.src:7: >>> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >>> location of the previous definition >>> gcc: build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math_complex.c >>> In file included from numpy/core/src/private/npy_config.h:4, >>> from numpy/core/src/npymath/npy_math_common.h:8, >>> from numpy/core/src/npymath/npy_math_complex.c.src:31: >>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >>> warning: "HAVE_HYPOT" redefined >>> In file included from /home/sanjey/include/python2.4/Python.h:8, >>> from numpy/core/src/npymath/npy_math_common.h:4, >>> from numpy/core/src/npymath/npy_math_complex.c.src:31: >>> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >>> location of the previous definition >>> ar: adding 3 object files to build/temp.linux-x86_64-2.4/libnpymath.a >>> running build_ext >>> customize UnixCCompiler >>> customize UnixCCompiler using build_ext >>> customize GnuFCompiler >>> gnu: no Fortran 90 compiler found >>> gnu: no Fortran 90 compiler found >>> customize GnuFCompiler >>> gnu: no Fortran 90 compiler found >>> gnu: no Fortran 90 compiler found >>> customize GnuFCompiler using build_ext >>> building 'numpy.core._sort' extension >>> compiling C sources >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/include >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>> gcc: build/src.linux-x86_64-2.4/numpy/core/src/_sortmodule.c >>> In file included from numpy/core/src/private/npy_config.h:4, >>> from numpy/core/src/_sortmodule.c.src:34: >>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >>> warning: "HAVE_HYPOT" redefined >>> In file included from /home/sanjey/include/python2.4/Python.h:8, >>> from numpy/core/src/_sortmodule.c.src:30: >>> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >>> location of the previous definition >>> gcc -m32 -pthread -shared >>> build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/_sortmodule.o >>> -Lbuild/temp.linux-x86_64-2.4 -lm -o >>> build/lib.linux-x86_64-2.4/numpy/core/_sort.so >>> building 'numpy.core.multiarray' extension >>> compiling C sources >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> creating build/temp.linux-x86_64-2.4/numpy >>> creating build/temp.linux-x86_64-2.4/numpy/core >>> creating build/temp.linux-x86_64-2.4/numpy/core/src >>> creating build/temp.linux-x86_64-2.4/numpy/core/src/multiarray >>> compile options: '-Inumpy/core/include >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>> gcc: numpy/core/src/multiarray/multiarraymodule_onefile.c >>> In file included from numpy/core/src/private/npy_config.h:4, >>> from numpy/core/src/multiarray/common.c:8, >>> from numpy/core/src/multiarray/multiarraymodule_onefile.c:8: >>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >>> warning: "HAVE_HYPOT" redefined >>> In file included from /home/sanjey/include/python2.4/Python.h:8, >>> from numpy/core/src/multiarray/common.c:2, >>> from numpy/core/src/multiarray/multiarraymodule_onefile.c:8: >>> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >>> location of the previous definition >>> In file included from numpy/core/src/multiarray/multiarraymodule_onefile.c:26: >>> numpy/core/src/multiarray/methods.c: In function `NpyArg_ParseKeywords': >>> numpy/core/src/multiarray/methods.c:41: warning: passing arg 3 of >>> `PyArg_VaParseTupleAndKeywords' discards qualifiers from pointer >>> target type >>> numpy/core/src/multiarray/flagsobject.c: In function `arrayflags_richcompare': >>> numpy/core/src/multiarray/flagsobject.c:568: warning: 'cmp' might be >>> used uninitialized in this function >>> numpy/core/src/multiarray/multiarraymodule_onefile.c: At top level: >>> numpy/core/include/numpy/npy_3kcompat.h:331: warning: >>> 'simple_capsule_dtor' defined but not used >>> numpy/core/src/multiarray/buffer.c:777: warning: >>> '_descriptor_from_pep3118_format' defined but not used >>> numpy/core/src/multiarray/arraytypes.c.src:93: warning: >>> '_SEQUENCE_MESSAGE' defined but not used >>> numpy/core/src/multiarray/mapping.c:75: warning: '_array_ass_item' >>> defined but not used >>> gcc -m32 -pthread -shared >>> build/temp.linux-x86_64-2.4/numpy/core/src/multiarray/multiarraymodule_onefile.o >>> -Lbuild/temp.linux-x86_64-2.4 -lnpymath -lm -o >>> build/lib.linux-x86_64-2.4/numpy/core/multiarray.so >>> building 'numpy.core.umath' extension >>> compiling C sources >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> creating build/temp.linux-x86_64-2.4/numpy/core/src/umath >>> compile options: '-Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath >>> -Inumpy/core/include >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>> gcc: numpy/core/src/umath/umathmodule_onefile.c >>> In file included from numpy/core/src/private/npy_config.h:4, >>> from numpy/core/src/umath/loops.c.src:7, >>> from numpy/core/src/umath/umathmodule_onefile.c:1: >>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >>> warning: "HAVE_HYPOT" redefined >>> In file included from /home/sanjey/include/python2.4/Python.h:8, >>> from numpy/core/src/umath/loops.c.src:5, >>> from numpy/core/src/umath/umathmodule_onefile.c:1: >>> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >>> location of the previous definition >>> numpy/core/include/numpy/npy_3kcompat.h:331: warning: >>> 'simple_capsule_dtor' defined but not used >>> numpy/core/src/umath/loops.c.src:1258: warning: >>> 'CLONGDOUBLE_logical_and' defined but not used >>> numpy/core/src/umath/loops.c.src:1258: warning: >>> 'CLONGDOUBLE_logical_or' defined but not used >>> numpy/core/src/umath/loops.c.src:1271: warning: >>> 'CLONGDOUBLE_logical_xor' defined but not used >>> numpy/core/src/umath/loops.c.src:1285: warning: >>> 'CLONGDOUBLE_logical_not' defined but not used >>> numpy/core/src/umath/loops.c.src:1342: warning: >>> 'CLONGDOUBLE_ones_like' defined but not used >>> numpy/core/src/umath/loops.c.src:1399: warning: 'CLONGDOUBLE_maximum' >>> defined but not used >>> numpy/core/src/umath/loops.c.src:1399: warning: 'CLONGDOUBLE_minimum' >>> defined but not used >>> numpy/core/src/umath/loops.c.src:1423: warning: 'CLONGDOUBLE_fmax' >>> defined but not used >>> numpy/core/src/umath/loops.c.src:1423: warning: 'CLONGDOUBLE_fmin' >>> defined but not used >>> gcc -m32 -pthread -shared >>> build/temp.linux-x86_64-2.4/numpy/core/src/umath/umathmodule_onefile.o >>> -Lbuild/temp.linux-x86_64-2.4 -lnpymath -lm -o >>> build/lib.linux-x86_64-2.4/numpy/core/umath.so >>> building 'numpy.core.scalarmath' extension >>> compiling C sources >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> compile options: '-Inumpy/core/include >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>> gcc: build/src.linux-x86_64-2.4/numpy/core/src/scalarmathmodule.c >>> numpy/core/include/numpy/npy_3kcompat.h:331: warning: >>> 'simple_capsule_dtor' defined but not used >>> gcc -m32 -pthread -shared >>> build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/scalarmathmodule.o >>> -Lbuild/temp.linux-x86_64-2.4 -lm -o >>> build/lib.linux-x86_64-2.4/numpy/core/scalarmath.so >>> building 'numpy.core.umath_tests' extension >>> compiling C sources >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/umath >>> compile options: '-Inumpy/core/include >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>> gcc: build/src.linux-x86_64-2.4/numpy/core/src/umath/umath_tests.c >>> In file included from numpy/core/src/private/npy_config.h:4, >>> from numpy/core/src/umath/umath_tests.c.src:14: >>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >>> warning: "HAVE_HYPOT" redefined >>> In file included from /home/sanjey/include/python2.4/Python.h:8, >>> from numpy/core/src/umath/umath_tests.c.src:8: >>> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >>> location of the previous definition >>> numpy/core/include/numpy/npy_3kcompat.h:331: warning: >>> 'simple_capsule_dtor' defined but not used >>> gcc -m32 -pthread -shared >>> build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/umath/umath_tests.o >>> -Lbuild/temp.linux-x86_64-2.4 -o >>> build/lib.linux-x86_64-2.4/numpy/core/umath_tests.so >>> building 'numpy.core.multiarray_tests' extension >>> compiling C sources >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/multiarray >>> compile options: '-Inumpy/core/include >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>> gcc: build/src.linux-x86_64-2.4/numpy/core/src/multiarray/multiarray_tests.c >>> numpy/core/include/numpy/npy_3kcompat.h:331: warning: >>> 'simple_capsule_dtor' defined but not used >>> gcc -m32 -pthread -shared >>> build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/multiarray/multiarray_tests.o >>> -Lbuild/temp.linux-x86_64-2.4 -o >>> build/lib.linux-x86_64-2.4/numpy/core/multiarray_tests.so >>> building 'numpy.lib._compiled_base' extension >>> compiling C sources >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> creating build/temp.linux-x86_64-2.4/numpy/lib >>> creating build/temp.linux-x86_64-2.4/numpy/lib/src >>> compile options: '-Inumpy/core/include >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>> gcc: numpy/lib/src/_compiled_base.c >>> In file included from numpy/core/src/private/npy_config.h:4, >>> from numpy/lib/src/_compiled_base.c:4: >>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >>> warning: "HAVE_HYPOT" redefined >>> In file included from /home/sanjey/include/python2.4/Python.h:8, >>> from numpy/lib/src/_compiled_base.c:1: >>> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >>> location of the previous definition >>> gcc -m32 -pthread -shared >>> build/temp.linux-x86_64-2.4/numpy/lib/src/_compiled_base.o >>> -Lbuild/temp.linux-x86_64-2.4 -o >>> build/lib.linux-x86_64-2.4/numpy/lib/_compiled_base.so >>> building 'numpy.numarray._capi' extension >>> compiling C sources >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> creating build/temp.linux-x86_64-2.4/numpy/numarray >>> compile options: '-Inumpy/core/include >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>> gcc: numpy/numarray/_capi.c >>> numpy/core/include/numpy/npy_3kcompat.h:331: warning: >>> 'simple_capsule_dtor' defined but not used >>> gcc -m32 -pthread -shared >>> build/temp.linux-x86_64-2.4/numpy/numarray/_capi.o >>> -Lbuild/temp.linux-x86_64-2.4 -o >>> build/lib.linux-x86_64-2.4/numpy/numarray/_capi.so >>> building 'numpy.fft.fftpack_lite' extension >>> compiling C sources >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> creating build/temp.linux-x86_64-2.4/numpy/fft >>> compile options: '-Inumpy/core/include >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>> gcc: numpy/fft/fftpack_litemodule.c >>> gcc: numpy/fft/fftpack.c >>> gcc -m32 -pthread -shared >>> build/temp.linux-x86_64-2.4/numpy/fft/fftpack_litemodule.o >>> build/temp.linux-x86_64-2.4/numpy/fft/fftpack.o >>> -Lbuild/temp.linux-x86_64-2.4 -o >>> build/lib.linux-x86_64-2.4/numpy/fft/fftpack_lite.so >>> building 'numpy.linalg.lapack_lite' extension >>> compiling C sources >>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>> -O3 -Wall -Wstrict-prototypes -fPIC >>> >>> creating build/temp.linux-x86_64-2.4/numpy/linalg >>> compile options: '-DNO_ATLAS_INFO=1 -Inumpy/core/include >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>> -Inumpy/core/src/umath -Inumpy/core/include >>> -I/home/sanjey/include/python2.4 >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>> gcc: numpy/linalg/lapack_litemodule.c >>> gcc: numpy/linalg/python_xerbla.c >>> /usr/bin/g77 -g -Wall -g -Wall -shared >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o >>> build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o -L/usr/lib >>> -Lbuild/temp.linux-x86_64-2.4 -llapack -lblas -lg2c -o >>> build/lib.linux-x86_64-2.4/numpy/linalg/lapack_lite.so >>> /usr/bin/ld: skipping incompatible /usr/lib/liblapack.so when >>> searching for -llapack >>> /usr/bin/ld: skipping incompatible /usr/lib/liblapack.a when searching >>> for -llapack >>> /usr/bin/ld: skipping incompatible /usr/lib/libblas.so when searching for -lblas >>> /usr/bin/ld: skipping incompatible /usr/lib/libblas.a when searching for -lblas >>> /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm >>> /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm >>> /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm >>> /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm >>> /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 >>> /usr/bin/ld: warning: i386 architecture of input file >>> `build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o' is >>> incompatible with i386:x86-64 output >>> /usr/bin/ld: warning: i386 architecture of input file >>> `build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o' is >>> incompatible with i386:x86-64 output >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xae): >>> In function `lapack_lite_dgeev': >>> numpy/linalg/lapack_litemodule.c:155: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfe):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x143):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a3):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1f4):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x272):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31c):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ae):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x60e):numpy/linalg/lapack_litemodule.c:171: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6aa): >>> In function `lapack_lite_dsyevd': >>> numpy/linalg/lapack_litemodule.c:241: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6f4):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x739):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x797):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x7ef):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x869):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x8ff):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xa7c):numpy/linalg/lapack_litemodule.c:254: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb34): >>> In function `lapack_lite_zheevd': >>> numpy/linalg/lapack_litemodule.c:327: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb7e):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xbc3):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc23):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc74):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xce9):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xd85):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xe77):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfb9):numpy/linalg/lapack_litemodule.c:341: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1087): >>> In function `lapack_lite_dgelsd': >>> numpy/linalg/lapack_litemodule.c:365: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x10d7):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x111c):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x117d):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x11cf):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1252):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x12e8):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x13d7):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1534):numpy/linalg/lapack_litemodule.c:380: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15af): >>> In function `lapack_lite_dgesv': >>> numpy/linalg/lapack_litemodule.c:398: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15f9):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x163e):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1692):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x16e7):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x175e):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x189a):numpy/linalg/lapack_litemodule.c:407: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1967): >>> In function `lapack_lite_dgesdd': >>> numpy/linalg/lapack_litemodule.c:430: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19b7):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19fc):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a5d):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1aaf):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1b32):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1bc8):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d15):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d76):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1efb):numpy/linalg/lapack_litemodule.c:472: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x202b): >>> In function `lapack_lite_dgetrf': >>> numpy/linalg/lapack_litemodule.c:488: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2063):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20ae):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20fe):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2155):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2235):numpy/linalg/lapack_litemodule.c:496: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22b4): >>> In function `lapack_lite_dpotrf': >>> numpy/linalg/lapack_litemodule.c:510: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22e9):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x232d):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x238f):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x240a):numpy/linalg/lapack_litemodule.c:516: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24af): >>> In function `lapack_lite_dgeqrf': >>> numpy/linalg/lapack_litemodule.c:529: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24f9):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x253e):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2598):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x25ef):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2669):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x27a7):numpy/linalg/lapack_litemodule.c:540: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2839): >>> In function `lapack_lite_dorgqr': >>> numpy/linalg/lapack_litemodule.c:555: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2883):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x28c8):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2927):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x297f):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x29f9):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2afa):numpy/linalg/lapack_litemodule.c:562: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2bbb): >>> In function `lapack_lite_zgeev': >>> numpy/linalg/lapack_litemodule.c:585: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c0b):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c50):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2cb0):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d04):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d82):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2e2c):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2f6b):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2fb9):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x311b):numpy/linalg/lapack_litemodule.c:601: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31f4): >>> In function `lapack_lite_zgelsd': >>> numpy/linalg/lapack_litemodule.c:626: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3244):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3289):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x32ef):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3340):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x33c8):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3471):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35b1):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35ff):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x376f):numpy/linalg/lapack_litemodule.c:641: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x37ef): >>> In function `lapack_lite_zgesv': >>> numpy/linalg/lapack_litemodule.c:658: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3839):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x387e):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x38d2):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3927):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x399e):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3ada):numpy/linalg/lapack_litemodule.c:667: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bae): >>> In function `lapack_lite_zgesdd': >>> numpy/linalg/lapack_litemodule.c:691: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bfe):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3c43):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cab):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cff):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3d82):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3e2c):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3f70):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3fbe):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4195):numpy/linalg/lapack_litemodule.c:708: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x41ab):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x422b): >>> In function `lapack_lite_zgetrf': >>> numpy/linalg/lapack_litemodule.c:724: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4263):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42ae):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42fe):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4355):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4435):numpy/linalg/lapack_litemodule.c:732: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44b4): >>> In function `lapack_lite_zpotrf': >>> numpy/linalg/lapack_litemodule.c:746: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44e9):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x452d):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x458f):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460a):numpy/linalg/lapack_litemodule.c:751: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46af): >>> In function `lapack_lite_zgeqrf': >>> numpy/linalg/lapack_litemodule.c:764: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46f9):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x473e):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4798):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x47ef):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4869):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x49a7):numpy/linalg/lapack_litemodule.c:774: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a39): >>> In function `lapack_lite_zungqr': >>> numpy/linalg/lapack_litemodule.c:787: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a83):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ac8):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b27):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b7f):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4bf9):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4cfa):numpy/linalg/lapack_litemodule.c:797: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d58): >>> In function `initlapack_lite': >>> numpy/linalg/lapack_litemodule.c:858: undefined reference to `Py_InitModule4' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d71): >>> In function `initlapack_lite': >>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1190: >>> undefined reference to `PyImport_ImportModule' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d8d):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1197: >>> undefined reference to `PyObject_GetAttrString' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4da6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1212: >>> undefined reference to `PyCObject_Type' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4db5):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: >>> undefined reference to `PyExc_RuntimeError' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dc9):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: >>> undefined reference to `PyErr_SetString' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dd7): >>> In function `initlapack_lite': >>> numpy/linalg/lapack_litemodule.c:865: undefined reference to `PyErr_Print' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ddd):numpy/linalg/lapack_litemodule.c:865: >>> undefined reference to `PyExc_ImportError' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4df1):numpy/linalg/lapack_litemodule.c:865: >>> undefined reference to `PyErr_SetString' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e18): >>> In function `initlapack_lite': >>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1194: >>> undefined reference to `PyExc_ImportError' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e26):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: >>> undefined reference to `PyErr_SetString' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e46):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1217: >>> undefined reference to `PyCObject_AsVoidPtr' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e88):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: >>> undefined reference to `PyExc_RuntimeError' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e96):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ea1):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: >>> undefined reference to `PyExc_RuntimeError' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4eb6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1200: >>> undefined reference to `PyExc_AttributeError' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f24):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: >>> undefined reference to `PyExc_RuntimeError' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f2e):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f46): >>> In function `initlapack_lite': >>> numpy/linalg/lapack_litemodule.c:866: undefined reference to `PyModule_GetDict' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f66):numpy/linalg/lapack_litemodule.c:867: >>> undefined reference to `PyErr_NewException' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f82):numpy/linalg/lapack_litemodule.c:868: >>> undefined reference to `PyDict_SetItemString' >>> build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x70): >>> In function `xerbla_': >>> numpy/linalg/python_xerbla.c:35: undefined reference to `PyExc_ValueError' >>> build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x7e):numpy/linalg/python_xerbla.c:35: >>> undefined reference to `PyErr_SetString' >>> collect2: ld returned 1 exit status >>> /usr/bin/ld: skipping incompatible /usr/lib/liblapack.so when >>> searching for -llapack >>> /usr/bin/ld: skipping incompatible /usr/lib/liblapack.a when searching >>> for -llapack >>> /usr/bin/ld: skipping incompatible /usr/lib/libblas.so when searching for -lblas >>> /usr/bin/ld: skipping incompatible /usr/lib/libblas.a when searching for -lblas >>> /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm >>> /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm >>> /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm >>> /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm >>> /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 >>> /usr/bin/ld: warning: i386 architecture of input file >>> `build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o' is >>> incompatible with i386:x86-64 output >>> /usr/bin/ld: warning: i386 architecture of input file >>> `build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o' is >>> incompatible with i386:x86-64 output >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xae): >>> In function `lapack_lite_dgeev': >>> numpy/linalg/lapack_litemodule.c:155: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfe):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x143):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a3):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1f4):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x272):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31c):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ae):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x60e):numpy/linalg/lapack_litemodule.c:171: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6aa): >>> In function `lapack_lite_dsyevd': >>> numpy/linalg/lapack_litemodule.c:241: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6f4):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x739):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x797):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x7ef):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x869):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x8ff):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xa7c):numpy/linalg/lapack_litemodule.c:254: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb34): >>> In function `lapack_lite_zheevd': >>> numpy/linalg/lapack_litemodule.c:327: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb7e):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xbc3):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc23):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc74):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xce9):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xd85):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xe77):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfb9):numpy/linalg/lapack_litemodule.c:341: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1087): >>> In function `lapack_lite_dgelsd': >>> numpy/linalg/lapack_litemodule.c:365: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x10d7):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x111c):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x117d):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x11cf):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1252):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x12e8):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x13d7):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1534):numpy/linalg/lapack_litemodule.c:380: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15af): >>> In function `lapack_lite_dgesv': >>> numpy/linalg/lapack_litemodule.c:398: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15f9):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x163e):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1692):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x16e7):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x175e):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x189a):numpy/linalg/lapack_litemodule.c:407: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1967): >>> In function `lapack_lite_dgesdd': >>> numpy/linalg/lapack_litemodule.c:430: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19b7):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19fc):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a5d):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1aaf):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1b32):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1bc8):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d15):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d76):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1efb):numpy/linalg/lapack_litemodule.c:472: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x202b): >>> In function `lapack_lite_dgetrf': >>> numpy/linalg/lapack_litemodule.c:488: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2063):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20ae):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20fe):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2155):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2235):numpy/linalg/lapack_litemodule.c:496: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22b4): >>> In function `lapack_lite_dpotrf': >>> numpy/linalg/lapack_litemodule.c:510: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22e9):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x232d):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x238f):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x240a):numpy/linalg/lapack_litemodule.c:516: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24af): >>> In function `lapack_lite_dgeqrf': >>> numpy/linalg/lapack_litemodule.c:529: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24f9):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x253e):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2598):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x25ef):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2669):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x27a7):numpy/linalg/lapack_litemodule.c:540: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2839): >>> In function `lapack_lite_dorgqr': >>> numpy/linalg/lapack_litemodule.c:555: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2883):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x28c8):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2927):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x297f):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x29f9):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2afa):numpy/linalg/lapack_litemodule.c:562: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2bbb): >>> In function `lapack_lite_zgeev': >>> numpy/linalg/lapack_litemodule.c:585: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c0b):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c50):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2cb0):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d04):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d82):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2e2c):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2f6b):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2fb9):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x311b):numpy/linalg/lapack_litemodule.c:601: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31f4): >>> In function `lapack_lite_zgelsd': >>> numpy/linalg/lapack_litemodule.c:626: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3244):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3289):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x32ef):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3340):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x33c8):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3471):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35b1):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35ff):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x376f):numpy/linalg/lapack_litemodule.c:641: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x37ef): >>> In function `lapack_lite_zgesv': >>> numpy/linalg/lapack_litemodule.c:658: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3839):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x387e):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x38d2):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3927):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x399e):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3ada):numpy/linalg/lapack_litemodule.c:667: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bae): >>> In function `lapack_lite_zgesdd': >>> numpy/linalg/lapack_litemodule.c:691: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bfe):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3c43):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cab):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cff):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3d82):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3e2c):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3f70):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3fbe):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4195):numpy/linalg/lapack_litemodule.c:708: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x41ab):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x422b): >>> In function `lapack_lite_zgetrf': >>> numpy/linalg/lapack_litemodule.c:724: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4263):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42ae):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42fe):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4355):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4435):numpy/linalg/lapack_litemodule.c:732: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44b4): >>> In function `lapack_lite_zpotrf': >>> numpy/linalg/lapack_litemodule.c:746: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44e9):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x452d):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x458f):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460a):numpy/linalg/lapack_litemodule.c:751: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46af): >>> In function `lapack_lite_zgeqrf': >>> numpy/linalg/lapack_litemodule.c:764: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46f9):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x473e):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4798):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x47ef):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4869):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x49a7):numpy/linalg/lapack_litemodule.c:774: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a39): >>> In function `lapack_lite_zungqr': >>> numpy/linalg/lapack_litemodule.c:787: undefined reference to `PyArg_ParseTuple' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a83):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ac8):numpy/linalg/lapack_litemodule.c:114: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b27):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b7f):numpy/linalg/lapack_litemodule.c:120: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4bf9):numpy/linalg/lapack_litemodule.c:103: >>> undefined reference to `PyType_IsSubtype' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4cfa):numpy/linalg/lapack_litemodule.c:797: >>> undefined reference to `Py_BuildValue' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d58): >>> In function `initlapack_lite': >>> numpy/linalg/lapack_litemodule.c:858: undefined reference to `Py_InitModule4' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d71): >>> In function `initlapack_lite': >>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1190: >>> undefined reference to `PyImport_ImportModule' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d8d):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1197: >>> undefined reference to `PyObject_GetAttrString' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4da6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1212: >>> undefined reference to `PyCObject_Type' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4db5):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: >>> undefined reference to `PyExc_RuntimeError' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dc9):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: >>> undefined reference to `PyErr_SetString' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dd7): >>> In function `initlapack_lite': >>> numpy/linalg/lapack_litemodule.c:865: undefined reference to `PyErr_Print' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ddd):numpy/linalg/lapack_litemodule.c:865: >>> undefined reference to `PyExc_ImportError' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4df1):numpy/linalg/lapack_litemodule.c:865: >>> undefined reference to `PyErr_SetString' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e18): >>> In function `initlapack_lite': >>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1194: >>> undefined reference to `PyExc_ImportError' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e26):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: >>> undefined reference to `PyErr_SetString' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e46):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1217: >>> undefined reference to `PyCObject_AsVoidPtr' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e88):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: >>> undefined reference to `PyExc_RuntimeError' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e96):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ea1):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: >>> undefined reference to `PyExc_RuntimeError' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4eb6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1200: >>> undefined reference to `PyExc_AttributeError' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f24):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: >>> undefined reference to `PyExc_RuntimeError' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f2e):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: >>> undefined reference to `PyErr_Format' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f46): >>> In function `initlapack_lite': >>> numpy/linalg/lapack_litemodule.c:866: undefined reference to `PyModule_GetDict' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f66):numpy/linalg/lapack_litemodule.c:867: >>> undefined reference to `PyErr_NewException' >>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f82):numpy/linalg/lapack_litemodule.c:868: >>> undefined reference to `PyDict_SetItemString' >>> build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x70): >>> In function `xerbla_': >>> numpy/linalg/python_xerbla.c:35: undefined reference to `PyExc_ValueError' >>> build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x7e):numpy/linalg/python_xerbla.c:35: >>> undefined reference to `PyErr_SetString' >>> collect2: ld returned 1 exit status >>> _______________________________________________ >>> NumPy-Discussion mailing list >>> NumPy-Discussion at scipy.org >>> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> Since you are using the -m32 flag, do you have *all* the 32-bit >> libraries/headers installed (especially Python 2.4 ones) what appears to >> be a x86_64 operating system? >> >> >> Bruce >> >> >> >> >> >> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion The errors are related to numpy not being able to find the Python 2.4 32-bit headers. You have to had built Python 2.4 as 32-bit and you need to add the appropriate path to the appropriate Python 2.4 32-bit header files when running 32-bit Python 2.4. Bruce From Chris.Barker at noaa.gov Fri Oct 15 11:56:00 2010 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Fri, 15 Oct 2010 08:56:00 -0700 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: References: <4CB4C99A.8040906@noaa.gov> <4CB5E208.5030909@noaa.gov> <4CB72D8F.90308@noaa.gov> Message-ID: <4CB87990.5040406@noaa.gov> On 10/14/10 8:47 PM, Friedrich Romstedt wrote: > Vincent and me had some success: good news. > [15.10.10 05:36:01] Friedrich Romstedt: In > Users/Shared/GitHub/project-numpy/owner-numpy/numpy-deployment/tools/numpy-macosx-installer > [15.10.10 05:36:18] Friedrich Romstedt: -rw-r--r--@ 1 Friedrich wheel > 8190646 Oct 14 21:33 numpy-2.0.0.dev-py2.5-python.org.dmg Can I find that somewhere to download and test? > This is py2.5 on Mac OS X 10.5. good start. Thanks again for all your work on this, -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 Chris.Barker at noaa.gov From p.sanjey at gmail.com Fri Oct 15 12:57:05 2010 From: p.sanjey at gmail.com (P Sanjey) Date: Fri, 15 Oct 2010 17:57:05 +0100 Subject: [Numpy-discussion] Please help a newbie install NUMPY In-Reply-To: <4CB878C2.2070009@gmail.com> References: <4CB871D8.4080503@gmail.com> <4CB878C2.2070009@gmail.com> Message-ID: oh ok so it cant find the python headers? Can I specify them in the site.cfg? I read on the numpy site to do that for MKL but thats for intel compilers and I used gcc Is it also possible to specify them on this line? python setup.py build? I did something like this for python 32 bit CC=" gcc -m32" ./configuree --prefix=/path Is it possible to do that here? I have one more doubt-if I have built python using gcc can I buld numpy using intel/mkl....etc or should it be gcc s well? Thanks soo much Bruce its becoming a bit clearer On Fri, Oct 15, 2010 at 4:52 PM, Bruce Southey wrote: > ?On 10/15/2010 10:30 AM, P Sanjey wrote: >> Hi Bruce, >> >> Not sure how to check if they are there (the libraries)-do you mean >> the ones with .so extensions? >> How can I know wht libraries are needed ?and whats already there? >> >> Yes its a x86_64 machine but I need a 32 bit version as I have another >> piece of code that only works on 32 bits >> so I am stuck with the 32 bit version >> >> Thanks for the help >> >> On Fri, Oct 15, 2010 at 4:23 PM, Bruce Southey ?wrote: >>> ? On 10/15/2010 09:31 AM, P Sanjey wrote: >>>> Please help-I am a newbie and I wanted to try installing numpy on a >>>> local /home/usr directory but got the following errors-I am not sure >>>> where to even begin fixing this problem and any help would be useful >>>> I just did the standard >>>> python setup.py build and got the following (loooooong) error message >>>> >>>> >>>> ********************************************************** >>>> non-existing path in 'numpy/distutils': 'site.cfg' >>>> F2PY Version 1 >>>> blas_opt_info: >>>> blas_mkl_info: >>>> ? ? libraries mkl,vml,guide not found in /home/sanjey/lib >>>> ? ? libraries mkl,vml,guide not found in /usr/local/lib >>>> ? ? libraries mkl,vml,guide not found in /usr/lib >>>> ? ? NOT AVAILABLE >>>> >>>> atlas_blas_threads_info: >>>> Setting PTATLAS=ATLAS >>>> ? ? libraries ptf77blas,ptcblas,atlas not found in /home/sanjey/lib >>>> ? ? libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib >>>> ? ? libraries ptf77blas,ptcblas,atlas not found in /usr/lib/sse2 >>>> ? ? libraries ptf77blas,ptcblas,atlas not found in /usr/lib >>>> ? ? NOT AVAILABLE >>>> >>>> atlas_blas_info: >>>> ? ? libraries f77blas,cblas,atlas not found in /home/sanjey/lib >>>> ? ? libraries f77blas,cblas,atlas not found in /usr/local/lib >>>> ? ? libraries f77blas,cblas,atlas not found in /usr/lib/sse2 >>>> ? ? libraries f77blas,cblas,atlas not found in /usr/lib >>>> ? ? NOT AVAILABLE >>>> >>>> blas_info: >>>> ? ? libraries blas not found in /home/sanjey/lib >>>> ? ? libraries blas not found in /usr/local/lib >>>> ? ? FOUND: >>>> ? ? ? libraries = ['blas'] >>>> ? ? ? library_dirs = ['/usr/lib'] >>>> ? ? ? language = f77 >>>> >>>> ? ? FOUND: >>>> ? ? ? libraries = ['blas'] >>>> ? ? ? library_dirs = ['/usr/lib'] >>>> ? ? ? define_macros = [('NO_ATLAS_INFO', 1)] >>>> ? ? ? language = f77 >>>> >>>> lapack_opt_info: >>>> lapack_mkl_info: >>>> mkl_info: >>>> ? ? libraries mkl,vml,guide not found in /home/sanjey/lib >>>> ? ? libraries mkl,vml,guide not found in /usr/local/lib >>>> ? ? libraries mkl,vml,guide not found in /usr/lib >>>> ? ? NOT AVAILABLE >>>> >>>> ? ? NOT AVAILABLE >>>> >>>> atlas_threads_info: >>>> Setting PTATLAS=ATLAS >>>> ? ? libraries ptf77blas,ptcblas,atlas not found in /home/sanjey/lib >>>> ? ? libraries lapack_atlas not found in /home/sanjey/lib >>>> ? ? libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib >>>> ? ? libraries lapack_atlas not found in /usr/local/lib >>>> ? ? libraries ptf77blas,ptcblas,atlas not found in /usr/lib/sse2 >>>> ? ? libraries lapack_atlas not found in /usr/lib/sse2 >>>> ? ? libraries ptf77blas,ptcblas,atlas not found in /usr/lib >>>> ? ? libraries lapack_atlas not found in /usr/lib >>>> numpy.distutils.system_info.atlas_threads_info >>>> ? ? NOT AVAILABLE >>>> >>>> atlas_info: >>>> ? ? libraries f77blas,cblas,atlas not found in /home/sanjey/lib >>>> ? ? libraries lapack_atlas not found in /home/sanjey/lib >>>> ? ? libraries f77blas,cblas,atlas not found in /usr/local/lib >>>> ? ? libraries lapack_atlas not found in /usr/local/lib >>>> ? ? libraries f77blas,cblas,atlas not found in /usr/lib/sse2 >>>> ? ? libraries lapack_atlas not found in /usr/lib/sse2 >>>> ? ? libraries f77blas,cblas,atlas not found in /usr/lib >>>> ? ? libraries lapack_atlas not found in /usr/lib >>>> numpy.distutils.system_info.atlas_info >>>> ? ? NOT AVAILABLE >>>> >>>> lapack_info: >>>> ? ? libraries lapack not found in /home/sanjey/lib >>>> ? ? libraries lapack not found in /usr/local/lib >>>> ? ? FOUND: >>>> ? ? ? libraries = ['lapack'] >>>> ? ? ? library_dirs = ['/usr/lib'] >>>> ? ? ? language = f77 >>>> >>>> ? ? FOUND: >>>> ? ? ? libraries = ['lapack', 'blas'] >>>> ? ? ? library_dirs = ['/usr/lib'] >>>> ? ? ? define_macros = [('NO_ATLAS_INFO', 1)] >>>> ? ? ? language = f77 >>>> >>>> running build >>>> running config_cc >>>> unifing config_cc, config, build_clib, build_ext, build commands >>>> --compiler options >>>> running config_fc >>>> unifing config_fc, config, build_clib, build_ext, build commands >>>> --fcompiler options >>>> running build_src >>>> 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 library "npymath" sources >>>> customize GnuFCompiler >>>> Found executable /usr/bin/g77 >>>> gnu: no Fortran 90 compiler found >>>> gnu: no Fortran 90 compiler found >>>> customize GnuFCompiler >>>> gnu: no Fortran 90 compiler found >>>> gnu: no Fortran 90 compiler found >>>> customize GnuFCompiler using config >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> gcc -m32 -pthread _configtest.o -o _configtest >>>> success! >>>> removing: _configtest.c _configtest.o _configtest >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:1: warning: conflicting types for built-in function 'exp' >>>> gcc -m32 -pthread _configtest.o -o _configtest >>>> _configtest.o(.text+0x19): In function `main': >>>> /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' >>>> collect2: ld returned 1 exit status >>>> _configtest.o(.text+0x19): In function `main': >>>> /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' >>>> collect2: ld returned 1 exit status >>>> failure. >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:1: warning: conflicting types for built-in function 'exp' >>>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>>> success! >>>> removing: _configtest.c _configtest.o _configtest >>>> creating build/src.linux-x86_64-2.4/numpy/core >>>> creating build/src.linux-x86_64-2.4/numpy/core/src >>>> creating build/src.linux-x86_64-2.4/numpy/core/src/npymath >>>> conv_template:> ? ?build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math.c >>>> conv_template:> ? ?build/src.linux-x86_64-2.4/numpy/core/src/npymath/ieee754.c >>>> conv_template:> >>>> build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math_complex.c >>>> building extension "numpy.core._sort" sources >>>> Generating build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> success! >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> success! >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:5: warning: function declaration isn't a prototype >>>> success! >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:5: warning: function declaration isn't a prototype >>>> success! >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:5: warning: function declaration isn't a prototype >>>> success! >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:5: warning: function declaration isn't a prototype >>>> success! >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> removing: _configtest.c _configtest.o _configtest.c _configtest.o >>>> _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c >>>> _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:5: warning: function declaration isn't a prototype >>>> success! >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> removing: _configtest.c _configtest.o _configtest.c _configtest.o >>>> _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c >>>> _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o >>>> _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:5: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:7: error: `SIZEOF_LONGDOUBLE' undeclared (first use in >>>> this function) >>>> _configtest.c:7: error: (Each undeclared identifier is reported only once >>>> _configtest.c:7: error: for each function it appears in.) >>>> _configtest.c:5: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:7: error: `SIZEOF_LONGDOUBLE' undeclared (first use in >>>> this function) >>>> _configtest.c:7: error: (Each undeclared identifier is reported only once >>>> _configtest.c:7: error: for each function it appears in.) >>>> failure. >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> removing: _configtest.c _configtest.o _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> removing: _configtest.c _configtest.o _configtest.c _configtest.o >>>> _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c >>>> _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o >>>> _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c >>>> _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:5: error: size of array `test_array' is negative >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> removing: _configtest.c _configtest.o _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:6: warning: function declaration isn't a prototype >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:6: warning: function declaration isn't a prototype >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:5: warning: function declaration isn't a prototype >>>> success! >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:6: warning: function declaration isn't a prototype >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:6: warning: function declaration isn't a prototype >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:5: warning: function declaration isn't a prototype >>>> success! >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:1: warning: conflicting types for built-in function 'exp' >>>> gcc -m32 -pthread _configtest.o -o _configtest >>>> _configtest.o(.text+0x19): In function `main': >>>> /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' >>>> collect2: ld returned 1 exit status >>>> _configtest.o(.text+0x19): In function `main': >>>> /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' >>>> collect2: ld returned 1 exit status >>>> failure. >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:1: warning: conflicting types for built-in function 'exp' >>>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>>> success! >>>> removing: _configtest.c _configtest.o _configtest >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:1: warning: conflicting types for built-in function 'asin' >>>> _configtest.c:2: warning: conflicting types for built-in function 'cos' >>>> _configtest.c:3: warning: conflicting types for built-in function 'log' >>>> _configtest.c:4: warning: conflicting types for built-in function 'fabs' >>>> _configtest.c:5: warning: conflicting types for built-in function 'tanh' >>>> _configtest.c:6: warning: conflicting types for built-in function 'atan' >>>> _configtest.c:7: warning: conflicting types for built-in function 'acos' >>>> _configtest.c:8: warning: conflicting types for built-in function 'floor' >>>> _configtest.c:9: warning: conflicting types for built-in function 'fmod' >>>> _configtest.c:10: warning: conflicting types for built-in function 'sqrt' >>>> _configtest.c:11: warning: conflicting types for built-in function 'cosh' >>>> _configtest.c:12: warning: conflicting types for built-in function 'modf' >>>> _configtest.c:13: warning: conflicting types for built-in function 'sinh' >>>> _configtest.c:14: warning: conflicting types for built-in function 'frexp' >>>> _configtest.c:15: warning: conflicting types for built-in function 'exp' >>>> _configtest.c:16: warning: conflicting types for built-in function 'tan' >>>> _configtest.c:17: warning: conflicting types for built-in function 'ceil' >>>> _configtest.c:18: warning: conflicting types for built-in function 'log10' >>>> _configtest.c:19: warning: conflicting types for built-in function 'sin' >>>> _configtest.c:20: warning: conflicting types for built-in function 'ldexp' >>>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>>> success! >>>> removing: _configtest.c _configtest.o _configtest >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:1: warning: conflicting types for built-in function 'expm1' >>>> _configtest.c:2: warning: conflicting types for built-in function 'log2' >>>> _configtest.c:3: warning: conflicting types for built-in function 'pow' >>>> _configtest.c:4: warning: conflicting types for built-in function 'rint' >>>> _configtest.c:5: warning: conflicting types for built-in function 'atanh' >>>> _configtest.c:6: warning: conflicting types for built-in function 'copysign' >>>> _configtest.c:7: warning: conflicting types for built-in function 'asinh' >>>> _configtest.c:8: warning: conflicting types for built-in function 'atan2' >>>> _configtest.c:9: warning: conflicting types for built-in function 'hypot' >>>> _configtest.c:10: warning: conflicting types for built-in function 'acosh' >>>> _configtest.c:11: warning: conflicting types for built-in function 'exp2' >>>> _configtest.c:12: warning: conflicting types for built-in function 'log1p' >>>> _configtest.c:13: warning: conflicting types for built-in function 'nextafter' >>>> _configtest.c:14: warning: conflicting types for built-in function 'trunc' >>>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>>> success! >>>> removing: _configtest.c _configtest.o _configtest >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:1: warning: conflicting types for built-in function 'cosf' >>>> _configtest.c:2: warning: conflicting types for built-in function 'coshf' >>>> _configtest.c:3: warning: conflicting types for built-in function 'rintf' >>>> _configtest.c:4: warning: conflicting types for built-in function 'fabsf' >>>> _configtest.c:5: warning: conflicting types for built-in function 'floorf' >>>> _configtest.c:6: warning: conflicting types for built-in function 'nextafterf' >>>> _configtest.c:7: warning: conflicting types for built-in function 'tanhf' >>>> _configtest.c:8: warning: conflicting types for built-in function 'log10f' >>>> _configtest.c:9: warning: conflicting types for built-in function 'logf' >>>> _configtest.c:10: warning: conflicting types for built-in function 'sinhf' >>>> _configtest.c:11: warning: conflicting types for built-in function 'acosf' >>>> _configtest.c:12: warning: conflicting types for built-in function 'sqrtf' >>>> _configtest.c:13: warning: conflicting types for built-in function 'ldexpf' >>>> _configtest.c:14: warning: conflicting types for built-in function 'hypotf' >>>> _configtest.c:15: warning: conflicting types for built-in function 'log2f' >>>> _configtest.c:16: warning: conflicting types for built-in function 'exp2f' >>>> _configtest.c:17: warning: conflicting types for built-in function 'atanf' >>>> _configtest.c:18: warning: conflicting types for built-in function 'fmodf' >>>> _configtest.c:19: warning: conflicting types for built-in function 'atan2f' >>>> _configtest.c:20: warning: conflicting types for built-in function 'modff' >>>> _configtest.c:21: warning: conflicting types for built-in function 'ceilf' >>>> _configtest.c:22: warning: conflicting types for built-in function 'log1pf' >>>> _configtest.c:23: warning: conflicting types for built-in function 'asinf' >>>> _configtest.c:24: warning: conflicting types for built-in function 'copysignf' >>>> _configtest.c:25: warning: conflicting types for built-in function 'acoshf' >>>> _configtest.c:26: warning: conflicting types for built-in function 'sinf' >>>> _configtest.c:27: warning: conflicting types for built-in function 'tanf' >>>> _configtest.c:28: warning: conflicting types for built-in function 'atanhf' >>>> _configtest.c:29: warning: conflicting types for built-in function 'truncf' >>>> _configtest.c:30: warning: conflicting types for built-in function 'asinhf' >>>> _configtest.c:31: warning: conflicting types for built-in function 'frexpf' >>>> _configtest.c:32: warning: conflicting types for built-in function 'powf' >>>> _configtest.c:33: warning: conflicting types for built-in function 'expf' >>>> _configtest.c:34: warning: conflicting types for built-in function 'expm1f' >>>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>>> success! >>>> removing: _configtest.c _configtest.o _configtest >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:1: warning: conflicting types for built-in function 'tanhl' >>>> _configtest.c:2: warning: conflicting types for built-in function 'log10l' >>>> _configtest.c:3: warning: conflicting types for built-in function 'nextafterl' >>>> _configtest.c:4: warning: conflicting types for built-in function 'coshl' >>>> _configtest.c:5: warning: conflicting types for built-in function 'cosl' >>>> _configtest.c:6: warning: conflicting types for built-in function 'floorl' >>>> _configtest.c:7: warning: conflicting types for built-in function 'rintl' >>>> _configtest.c:8: warning: conflicting types for built-in function 'fabsl' >>>> _configtest.c:9: warning: conflicting types for built-in function 'acosl' >>>> _configtest.c:10: warning: conflicting types for built-in function 'ldexpl' >>>> _configtest.c:11: warning: conflicting types for built-in function 'sqrtl' >>>> _configtest.c:12: warning: conflicting types for built-in function 'logl' >>>> _configtest.c:13: warning: conflicting types for built-in function 'expm1l' >>>> _configtest.c:14: warning: conflicting types for built-in function 'hypotl' >>>> _configtest.c:15: warning: conflicting types for built-in function 'log2l' >>>> _configtest.c:16: warning: conflicting types for built-in function 'copysignl' >>>> _configtest.c:17: warning: conflicting types for built-in function 'exp2l' >>>> _configtest.c:18: warning: conflicting types for built-in function 'atanl' >>>> _configtest.c:19: warning: conflicting types for built-in function 'frexpl' >>>> _configtest.c:20: warning: conflicting types for built-in function 'atan2l' >>>> _configtest.c:21: warning: conflicting types for built-in function 'sinhl' >>>> _configtest.c:22: warning: conflicting types for built-in function 'fmodl' >>>> _configtest.c:23: warning: conflicting types for built-in function 'log1pl' >>>> _configtest.c:24: warning: conflicting types for built-in function 'asinl' >>>> _configtest.c:25: warning: conflicting types for built-in function 'ceill' >>>> _configtest.c:26: warning: conflicting types for built-in function 'sinl' >>>> _configtest.c:27: warning: conflicting types for built-in function 'acoshl' >>>> _configtest.c:28: warning: conflicting types for built-in function 'atanhl' >>>> _configtest.c:29: warning: conflicting types for built-in function 'tanl' >>>> _configtest.c:30: warning: conflicting types for built-in function 'truncl' >>>> _configtest.c:31: warning: conflicting types for built-in function 'powl' >>>> _configtest.c:32: warning: conflicting types for built-in function 'expl' >>>> _configtest.c:33: warning: conflicting types for built-in function 'modfl' >>>> _configtest.c:34: warning: conflicting types for built-in function 'asinhl' >>>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>>> success! >>>> removing: _configtest.c _configtest.o _configtest >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:6: warning: function declaration isn't a prototype >>>> success! >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:6: warning: function declaration isn't a prototype >>>> success! >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:6: warning: function declaration isn't a prototype >>>> success! >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:6: warning: function declaration isn't a prototype >>>> success! >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> success! >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:1: warning: conflicting types for built-in function 'cexp' >>>> _configtest.c:3: warning: conflicting types for built-in function 'ccos' >>>> _configtest.c:4: warning: conflicting types for built-in function 'cimag' >>>> _configtest.c:5: warning: conflicting types for built-in function 'cabs' >>>> _configtest.c:6: warning: conflicting types for built-in function 'cpow' >>>> _configtest.c:7: warning: conflicting types for built-in function 'csqrt' >>>> _configtest.c:8: warning: conflicting types for built-in function 'carg' >>>> _configtest.c:9: warning: conflicting types for built-in function 'creal' >>>> _configtest.c:10: warning: conflicting types for built-in function 'csin' >>>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>>> success! >>>> removing: _configtest.c _configtest.o _configtest >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:1: warning: conflicting types for built-in function 'ccosf' >>>> _configtest.c:2: warning: conflicting types for built-in function 'cargf' >>>> _configtest.c:3: warning: conflicting types for built-in function 'csqrtf' >>>> _configtest.c:4: warning: conflicting types for built-in function 'cpowf' >>>> _configtest.c:5: warning: conflicting types for built-in function 'cexpf' >>>> _configtest.c:6: warning: conflicting types for built-in function 'crealf' >>>> _configtest.c:7: warning: conflicting types for built-in function 'csinf' >>>> _configtest.c:8: warning: conflicting types for built-in function 'cabsf' >>>> _configtest.c:10: warning: conflicting types for built-in function 'cimagf' >>>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>>> success! >>>> removing: _configtest.c _configtest.o _configtest >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:1: warning: conflicting types for built-in function 'csqrtl' >>>> _configtest.c:2: warning: conflicting types for built-in function 'cargl' >>>> _configtest.c:3: warning: conflicting types for built-in function 'cexpl' >>>> _configtest.c:4: warning: conflicting types for built-in function 'ccosl' >>>> _configtest.c:5: warning: conflicting types for built-in function 'cpowl' >>>> _configtest.c:6: warning: conflicting types for built-in function 'cimagl' >>>> _configtest.c:7: warning: conflicting types for built-in function 'csinl' >>>> _configtest.c:8: warning: conflicting types for built-in function 'creall' >>>> _configtest.c:10: warning: conflicting types for built-in function 'cabsl' >>>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>>> success! >>>> removing: _configtest.c _configtest.o _configtest >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> success! >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:5: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:7: error: `Py_UNICODE_WIDE' undeclared (first use in >>>> this function) >>>> _configtest.c:7: error: (Each undeclared identifier is reported only once >>>> _configtest.c:7: error: for each function it appears in.) >>>> _configtest.c:5: warning: function declaration isn't a prototype >>>> _configtest.c: In function `main': >>>> _configtest.c:7: error: `Py_UNICODE_WIDE' undeclared (first use in >>>> this function) >>>> _configtest.c:7: error: (Each undeclared identifier is reported only once >>>> _configtest.c:7: error: for each function it appears in.) >>>> failure. >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> removing: _configtest.c _configtest.o >>>> ('File:', 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h') >>>> #define HAVE_ENDIAN_H 1 >>>> #define SIZEOF_PY_INTPTR_T 4 >>>> #define SIZEOF_PY_LONG_LONG 8 >>>> #define MATHLIB m >>>> #define HAVE_SIN >>>> #define HAVE_COS >>>> #define HAVE_TAN >>>> #define HAVE_SINH >>>> #define HAVE_COSH >>>> #define HAVE_TANH >>>> #define HAVE_FABS >>>> #define HAVE_FLOOR >>>> #define HAVE_CEIL >>>> #define HAVE_SQRT >>>> #define HAVE_LOG10 >>>> #define HAVE_LOG >>>> #define HAVE_EXP >>>> #define HAVE_ASIN >>>> #define HAVE_ACOS >>>> #define HAVE_ATAN >>>> #define HAVE_FMOD >>>> #define HAVE_MODF >>>> #define HAVE_FREXP >>>> #define HAVE_LDEXP >>>> #define HAVE_EXPM1 >>>> #define HAVE_LOG1P >>>> #define HAVE_ACOSH >>>> #define HAVE_ASINH >>>> #define HAVE_ATANH >>>> #define HAVE_RINT >>>> #define HAVE_TRUNC >>>> #define HAVE_EXP2 >>>> #define HAVE_LOG2 >>>> #define HAVE_HYPOT >>>> #define HAVE_ATAN2 >>>> #define HAVE_POW >>>> #define HAVE_COPYSIGN >>>> #define HAVE_NEXTAFTER >>>> #define HAVE_SINF >>>> #define HAVE_COSF >>>> #define HAVE_TANF >>>> #define HAVE_SINHF >>>> #define HAVE_COSHF >>>> #define HAVE_TANHF >>>> #define HAVE_FABSF >>>> #define HAVE_FLOORF >>>> #define HAVE_CEILF >>>> #define HAVE_RINTF >>>> #define HAVE_TRUNCF >>>> #define HAVE_SQRTF >>>> #define HAVE_LOG10F >>>> #define HAVE_LOGF >>>> #define HAVE_LOG1PF >>>> #define HAVE_EXPF >>>> #define HAVE_EXPM1F >>>> #define HAVE_ASINF >>>> #define HAVE_ACOSF >>>> #define HAVE_ATANF >>>> #define HAVE_ASINHF >>>> #define HAVE_ACOSHF >>>> #define HAVE_ATANHF >>>> #define HAVE_HYPOTF >>>> #define HAVE_ATAN2F >>>> #define HAVE_POWF >>>> #define HAVE_FMODF >>>> #define HAVE_MODFF >>>> #define HAVE_FREXPF >>>> #define HAVE_LDEXPF >>>> #define HAVE_EXP2F >>>> #define HAVE_LOG2F >>>> #define HAVE_COPYSIGNF >>>> #define HAVE_NEXTAFTERF >>>> #define HAVE_SINL >>>> #define HAVE_COSL >>>> #define HAVE_TANL >>>> #define HAVE_SINHL >>>> #define HAVE_COSHL >>>> #define HAVE_TANHL >>>> #define HAVE_FABSL >>>> #define HAVE_FLOORL >>>> #define HAVE_CEILL >>>> #define HAVE_RINTL >>>> #define HAVE_TRUNCL >>>> #define HAVE_SQRTL >>>> #define HAVE_LOG10L >>>> #define HAVE_LOGL >>>> #define HAVE_LOG1PL >>>> #define HAVE_EXPL >>>> #define HAVE_EXPM1L >>>> #define HAVE_ASINL >>>> #define HAVE_ACOSL >>>> #define HAVE_ATANL >>>> #define HAVE_ASINHL >>>> #define HAVE_ACOSHL >>>> #define HAVE_ATANHL >>>> #define HAVE_HYPOTL >>>> #define HAVE_ATAN2L >>>> #define HAVE_POWL >>>> #define HAVE_FMODL >>>> #define HAVE_MODFL >>>> #define HAVE_FREXPL >>>> #define HAVE_LDEXPL >>>> #define HAVE_EXP2L >>>> #define HAVE_LOG2L >>>> #define HAVE_COPYSIGNL >>>> #define HAVE_NEXTAFTERL >>>> #define HAVE_DECL_ISNAN >>>> #define HAVE_DECL_ISINF >>>> #define HAVE_DECL_SIGNBIT >>>> #define HAVE_DECL_ISFINITE >>>> #define HAVE_COMPLEX_H >>>> #define HAVE_CREAL >>>> #define HAVE_CIMAG >>>> #define HAVE_CABS >>>> #define HAVE_CARG >>>> #define HAVE_CEXP >>>> #define HAVE_CSQRT >>>> #define HAVE_CLOG >>>> #define HAVE_CCOS >>>> #define HAVE_CSIN >>>> #define HAVE_CPOW >>>> #define HAVE_CREALF >>>> #define HAVE_CIMAGF >>>> #define HAVE_CABSF >>>> #define HAVE_CARGF >>>> #define HAVE_CEXPF >>>> #define HAVE_CSQRTF >>>> #define HAVE_CLOGF >>>> #define HAVE_CCOSF >>>> #define HAVE_CSINF >>>> #define HAVE_CPOWF >>>> #define HAVE_CREALL >>>> #define HAVE_CIMAGL >>>> #define HAVE_CABSL >>>> #define HAVE_CARGL >>>> #define HAVE_CEXPL >>>> #define HAVE_CSQRTL >>>> #define HAVE_CLOGL >>>> #define HAVE_CCOSL >>>> #define HAVE_CSINL >>>> #define HAVE_CPOWL >>>> #define HAVE_LDOUBLE_INTEL_EXTENDED_12_BYTES_LE 1 >>>> #ifndef __cplusplus >>>> /* #undef inline */ >>>> #endif >>>> >>>> #ifndef _NPY_NPY_CONFIG_H_ >>>> #error config.h should never be included directly, include npy_config.h instead >>>> #endif >>>> >>>> EOF >>>> ? ? adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' >>>> to sources. >>>> Generating build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:1: warning: conflicting types for built-in function 'exp' >>>> gcc -m32 -pthread _configtest.o -o _configtest >>>> _configtest.o(.text+0x19): In function `main': >>>> /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' >>>> collect2: ld returned 1 exit status >>>> _configtest.o(.text+0x19): In function `main': >>>> /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' >>>> collect2: ld returned 1 exit status >>>> failure. >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:1: warning: conflicting types for built-in function 'exp' >>>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>>> success! >>>> removing: _configtest.c _configtest.o _configtest >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:5: warning: function declaration isn't a prototype >>>> success! >>>> removing: _configtest.c _configtest.o >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> _configtest.c:4: warning: function declaration isn't a prototype >>>> _configtest.c:5:18: warning: extra tokens at end of #ifndef directive >>>> _configtest.c: In function `main': >>>> _configtest.c:4: warning: control reaches end of non-void function >>>> success! >>>> removing: _configtest.c _configtest.o >>>> File: build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h >>>> #define NPY_HAVE_ENDIAN_H 1 >>>> #define NPY_SIZEOF_SHORT SIZEOF_SHORT >>>> #define NPY_SIZEOF_INT SIZEOF_INT >>>> #define NPY_SIZEOF_LONG SIZEOF_LONG >>>> #define NPY_SIZEOF_FLOAT 4 >>>> #define NPY_SIZEOF_COMPLEX_FLOAT 8 >>>> #define NPY_SIZEOF_DOUBLE 8 >>>> #define NPY_SIZEOF_COMPLEX_DOUBLE 16 >>>> #define NPY_SIZEOF_LONGDOUBLE 12 >>>> #define NPY_SIZEOF_COMPLEX_LONGDOUBLE 24 >>>> #define NPY_SIZEOF_PY_INTPTR_T 4 >>>> #define NPY_SIZEOF_PY_LONG_LONG 8 >>>> #define NPY_SIZEOF_LONGLONG 8 >>>> #define NPY_NO_SMP 1 >>>> #define NPY_HAVE_DECL_ISNAN >>>> #define NPY_HAVE_DECL_ISINF >>>> #define NPY_HAVE_DECL_SIGNBIT >>>> #define NPY_HAVE_DECL_ISFINITE >>>> #define NPY_USE_C99_COMPLEX >>>> #define NPY_HAVE_COMPLEX_DOUBLE 1 >>>> #define NPY_HAVE_COMPLEX_FLOAT 1 >>>> #define NPY_HAVE_COMPLEX_LONG_DOUBLE 1 >>>> #define NPY_USE_C99_FORMATS 1 >>>> #define NPY_VISIBILITY_HIDDEN __attribute__((visibility("hidden"))) >>>> #define NPY_ABI_VERSION 0x01000009 >>>> #define NPY_API_VERSION 0x00000004 >>>> >>>> #ifndef __STDC_FORMAT_MACROS >>>> #define __STDC_FORMAT_MACROS 1 >>>> #endif >>>> >>>> EOF >>>> ? ? adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' >>>> to sources. >>>> executing numpy/core/code_generators/generate_numpy_api.py >>>> ? ? adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__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/include/numpy/config.h', >>>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', >>>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h'] >>>> building extension "numpy.core.multiarray" sources >>>> non-existing path in 'numpy/core': >>>> 'build/src.linux-x86_64-2.4/numpy/core/src/multiarray' >>>> creating build/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>> conv_template:> >>>> build/src.linux-x86_64-2.4/numpy/core/src/multiarray/scalartypes.c >>>> conv_template:> >>>> build/src.linux-x86_64-2.4/numpy/core/src/multiarray/arraytypes.c >>>> ? ? adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' >>>> to sources. >>>> ? ? adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' >>>> to sources. >>>> executing numpy/core/code_generators/generate_numpy_api.py >>>> ? ? adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h' >>>> to sources. >>>> numpy.core - nothing done with h_files = >>>> ['build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h', >>>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', >>>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h'] >>>> building extension "numpy.core.umath" sources >>>> ? ? adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' >>>> to sources. >>>> ? ? adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' >>>> to sources. >>>> executing numpy/core/code_generators/generate_ufunc_api.py >>>> ? ? adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__ufunc_api.h' >>>> to sources. >>>> non-existing path in 'numpy/core': >>>> 'build/src.linux-x86_64-2.4/numpy/core/src/umath' >>>> creating build/src.linux-x86_64-2.4/numpy/core/src/umath >>>> conv_template:> ? ?build/src.linux-x86_64-2.4/numpy/core/src/umath/loops.c >>>> conv_template:> ? ?build/src.linux-x86_64-2.4/numpy/core/src/umath/umathmodule.c >>>> conv_template:> ? ?build/src.linux-x86_64-2.4/numpy/core/src/umath/funcs.inc >>>> ? ? adding 'build/src.linux-x86_64-2.4/numpy/core/src/umath' to include_dirs. >>>> numpy.core - nothing done with h_files = >>>> ['build/src.linux-x86_64-2.4/numpy/core/src/umath/funcs.inc', >>>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h', >>>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', >>>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__ufunc_api.h'] >>>> building extension "numpy.core.scalarmath" sources >>>> ? ? adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' >>>> to sources. >>>> ? ? adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' >>>> to sources. >>>> executing numpy/core/code_generators/generate_numpy_api.py >>>> ? ? adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h' >>>> to sources. >>>> executing numpy/core/code_generators/generate_ufunc_api.py >>>> ? ? adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__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/include/numpy/config.h', >>>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', >>>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h', >>>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__ufunc_api.h'] >>>> building extension "numpy.core._dotblas" sources >>>> building extension "numpy.core.umath_tests" sources >>>> conv_template:> ? ?build/src.linux-x86_64-2.4/numpy/core/src/umath/umath_tests.c >>>> building extension "numpy.core.multiarray_tests" sources >>>> conv_template:> >>>> build/src.linux-x86_64-2.4/numpy/core/src/multiarray/multiarray_tests.c >>>> building extension "numpy.lib._compiled_base" sources >>>> building extension "numpy.numarray._capi" sources >>>> building extension "numpy.fft.fftpack_lite" sources >>>> building extension "numpy.linalg.lapack_lite" sources >>>> creating build/src.linux-x86_64-2.4/numpy/linalg >>>> ? ? adding 'numpy/linalg/lapack_litemodule.c' to sources. >>>> ? ? adding 'numpy/linalg/python_xerbla.c' to sources. >>>> building extension "numpy.random.mtrand" sources >>>> creating build/src.linux-x86_64-2.4/numpy/random >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 -c' >>>> gcc: _configtest.c >>>> gcc -m32 -pthread _configtest.o -o _configtest >>>> _configtest >>>> failure. >>>> removing: _configtest.c _configtest.o _configtest >>>> building data_files sources >>>> build_src: building npy-pkg config files >>>> running build_py >>>> creating build/lib.linux-x86_64-2.4 >>>> creating build/lib.linux-x86_64-2.4/numpy >>>> copying numpy/version.py -> ? ?build/lib.linux-x86_64-2.4/numpy >>>> copying numpy/matlib.py -> ? ?build/lib.linux-x86_64-2.4/numpy >>>> copying numpy/ctypeslib.py -> ? ?build/lib.linux-x86_64-2.4/numpy >>>> copying numpy/setupscons.py -> ? ?build/lib.linux-x86_64-2.4/numpy >>>> copying numpy/__init__.py -> ? ?build/lib.linux-x86_64-2.4/numpy >>>> copying numpy/setup.py -> ? ?build/lib.linux-x86_64-2.4/numpy >>>> copying numpy/dual.py -> ? ?build/lib.linux-x86_64-2.4/numpy >>>> copying numpy/_import_tools.py -> ? ?build/lib.linux-x86_64-2.4/numpy >>>> copying numpy/add_newdocs.py -> ? ?build/lib.linux-x86_64-2.4/numpy >>>> copying build/src.linux-x86_64-2.4/numpy/__config__.py -> >>>> build/lib.linux-x86_64-2.4/numpy >>>> creating build/lib.linux-x86_64-2.4/numpy/distutils >>>> copying numpy/distutils/from_template.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>> copying numpy/distutils/npy_pkg_config.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>> copying numpy/distutils/compat.py -> ? ?build/lib.linux-x86_64-2.4/numpy/distutils >>>> copying numpy/distutils/setupscons.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>> copying numpy/distutils/__init__.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>> copying numpy/distutils/lib2def.py -> ? ?build/lib.linux-x86_64-2.4/numpy/distutils >>>> copying numpy/distutils/interactive.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>> copying numpy/distutils/info.py -> ? ?build/lib.linux-x86_64-2.4/numpy/distutils >>>> copying numpy/distutils/environment.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>> copying numpy/distutils/setup.py -> ? ?build/lib.linux-x86_64-2.4/numpy/distutils >>>> copying numpy/distutils/cpuinfo.py -> ? ?build/lib.linux-x86_64-2.4/numpy/distutils >>>> copying numpy/distutils/extension.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>> copying numpy/distutils/core.py -> ? ?build/lib.linux-x86_64-2.4/numpy/distutils >>>> copying numpy/distutils/intelccompiler.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>> copying numpy/distutils/log.py -> ? ?build/lib.linux-x86_64-2.4/numpy/distutils >>>> copying numpy/distutils/__version__.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>> copying numpy/distutils/unixccompiler.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>> copying numpy/distutils/misc_util.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>> copying numpy/distutils/line_endings.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>> copying numpy/distutils/exec_command.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>> copying numpy/distutils/conv_template.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>> copying numpy/distutils/ccompiler.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>> copying numpy/distutils/mingw32ccompiler.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>> copying numpy/distutils/system_info.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>> copying numpy/distutils/numpy_distribution.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>> copying build/src.linux-x86_64-2.4/numpy/distutils/__config__.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>> creating build/lib.linux-x86_64-2.4/numpy/distutils/command >>>> copying numpy/distutils/command/install.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>> copying numpy/distutils/command/egg_info.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>> copying numpy/distutils/command/install_clib.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>> copying numpy/distutils/command/bdist_rpm.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>> copying numpy/distutils/command/develop.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>> copying numpy/distutils/command/install_data.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>> copying numpy/distutils/command/__init__.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>> copying numpy/distutils/command/build_py.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>> copying numpy/distutils/command/build_src.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>> copying numpy/distutils/command/build_clib.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>> copying numpy/distutils/command/build_ext.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>> copying numpy/distutils/command/autodist.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>> copying numpy/distutils/command/install_headers.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>> copying numpy/distutils/command/config.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>> copying numpy/distutils/command/config_compiler.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>> copying numpy/distutils/command/build.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>> copying numpy/distutils/command/build_scripts.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>> copying numpy/distutils/command/sdist.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>> copying numpy/distutils/command/scons.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>> creating build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>> copying numpy/distutils/fcompiler/none.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>> copying numpy/distutils/fcompiler/hpux.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>> copying numpy/distutils/fcompiler/compaq.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>> copying numpy/distutils/fcompiler/absoft.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>> copying numpy/distutils/fcompiler/vast.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>> copying numpy/distutils/fcompiler/nag.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>> copying numpy/distutils/fcompiler/__init__.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>> copying numpy/distutils/fcompiler/sun.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>> copying numpy/distutils/fcompiler/mips.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>> copying numpy/distutils/fcompiler/intel.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>> copying numpy/distutils/fcompiler/gnu.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>> copying numpy/distutils/fcompiler/g95.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>> copying numpy/distutils/fcompiler/pg.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>> copying numpy/distutils/fcompiler/ibm.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>> copying numpy/distutils/fcompiler/lahey.py -> >>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>> creating build/lib.linux-x86_64-2.4/numpy/testing >>>> copying numpy/testing/nulltester.py -> ? ?build/lib.linux-x86_64-2.4/numpy/testing >>>> copying numpy/testing/setupscons.py -> ? ?build/lib.linux-x86_64-2.4/numpy/testing >>>> copying numpy/testing/__init__.py -> ? ?build/lib.linux-x86_64-2.4/numpy/testing >>>> copying numpy/testing/setup.py -> ? ?build/lib.linux-x86_64-2.4/numpy/testing >>>> copying numpy/testing/decorators.py -> ? ?build/lib.linux-x86_64-2.4/numpy/testing >>>> copying numpy/testing/utils.py -> ? ?build/lib.linux-x86_64-2.4/numpy/testing >>>> copying numpy/testing/noseclasses.py -> ? ?build/lib.linux-x86_64-2.4/numpy/testing >>>> copying numpy/testing/numpytest.py -> ? ?build/lib.linux-x86_64-2.4/numpy/testing >>>> copying numpy/testing/nosetester.py -> ? ?build/lib.linux-x86_64-2.4/numpy/testing >>>> creating build/lib.linux-x86_64-2.4/numpy/f2py >>>> copying numpy/f2py/auxfuncs.py -> ? ?build/lib.linux-x86_64-2.4/numpy/f2py >>>> copying numpy/f2py/common_rules.py -> ? ?build/lib.linux-x86_64-2.4/numpy/f2py >>>> copying numpy/f2py/setupscons.py -> ? ?build/lib.linux-x86_64-2.4/numpy/f2py >>>> copying numpy/f2py/__init__.py -> ? ?build/lib.linux-x86_64-2.4/numpy/f2py >>>> copying numpy/f2py/cb_rules.py -> ? ?build/lib.linux-x86_64-2.4/numpy/f2py >>>> copying numpy/f2py/info.py -> ? ?build/lib.linux-x86_64-2.4/numpy/f2py >>>> copying numpy/f2py/setup.py -> ? ?build/lib.linux-x86_64-2.4/numpy/f2py >>>> copying numpy/f2py/f2py2e.py -> ? ?build/lib.linux-x86_64-2.4/numpy/f2py >>>> copying numpy/f2py/cfuncs.py -> ? ?build/lib.linux-x86_64-2.4/numpy/f2py >>>> copying numpy/f2py/crackfortran.py -> ? ?build/lib.linux-x86_64-2.4/numpy/f2py >>>> copying numpy/f2py/use_rules.py -> ? ?build/lib.linux-x86_64-2.4/numpy/f2py >>>> copying numpy/f2py/diagnose.py -> ? ?build/lib.linux-x86_64-2.4/numpy/f2py >>>> copying numpy/f2py/f2py_testing.py -> ? ?build/lib.linux-x86_64-2.4/numpy/f2py >>>> copying numpy/f2py/__version__.py -> ? ?build/lib.linux-x86_64-2.4/numpy/f2py >>>> copying numpy/f2py/capi_maps.py -> ? ?build/lib.linux-x86_64-2.4/numpy/f2py >>>> copying numpy/f2py/func2subr.py -> ? ?build/lib.linux-x86_64-2.4/numpy/f2py >>>> copying numpy/f2py/f90mod_rules.py -> ? ?build/lib.linux-x86_64-2.4/numpy/f2py >>>> copying numpy/f2py/rules.py -> ? ?build/lib.linux-x86_64-2.4/numpy/f2py >>>> creating build/lib.linux-x86_64-2.4/numpy/core >>>> copying numpy/core/defchararray.py -> ? ?build/lib.linux-x86_64-2.4/numpy/core >>>> copying numpy/core/numeric.py -> ? ?build/lib.linux-x86_64-2.4/numpy/core >>>> copying numpy/core/setupscons.py -> ? ?build/lib.linux-x86_64-2.4/numpy/core >>>> copying numpy/core/__init__.py -> ? ?build/lib.linux-x86_64-2.4/numpy/core >>>> copying numpy/core/info.py -> ? ?build/lib.linux-x86_64-2.4/numpy/core >>>> copying numpy/core/function_base.py -> ? ?build/lib.linux-x86_64-2.4/numpy/core >>>> copying numpy/core/getlimits.py -> ? ?build/lib.linux-x86_64-2.4/numpy/core >>>> copying numpy/core/setup.py -> ? ?build/lib.linux-x86_64-2.4/numpy/core >>>> copying numpy/core/fromnumeric.py -> ? ?build/lib.linux-x86_64-2.4/numpy/core >>>> copying numpy/core/shape_base.py -> ? ?build/lib.linux-x86_64-2.4/numpy/core >>>> copying numpy/core/setup_common.py -> ? ?build/lib.linux-x86_64-2.4/numpy/core >>>> copying numpy/core/records.py -> ? ?build/lib.linux-x86_64-2.4/numpy/core >>>> copying numpy/core/memmap.py -> ? ?build/lib.linux-x86_64-2.4/numpy/core >>>> copying numpy/core/arrayprint.py -> ? ?build/lib.linux-x86_64-2.4/numpy/core >>>> copying numpy/core/numerictypes.py -> ? ?build/lib.linux-x86_64-2.4/numpy/core >>>> copying numpy/core/machar.py -> ? ?build/lib.linux-x86_64-2.4/numpy/core >>>> copying numpy/core/_mx_datetime_parser.py -> >>>> build/lib.linux-x86_64-2.4/numpy/core >>>> copying numpy/core/scons_support.py -> ? ?build/lib.linux-x86_64-2.4/numpy/core >>>> copying numpy/core/_internal.py -> ? ?build/lib.linux-x86_64-2.4/numpy/core >>>> copying numpy/core/code_generators/generate_numpy_api.py -> >>>> build/lib.linux-x86_64-2.4/numpy/core >>>> creating build/lib.linux-x86_64-2.4/numpy/lib >>>> copying numpy/lib/_datasource.py -> ? ?build/lib.linux-x86_64-2.4/numpy/lib >>>> copying numpy/lib/arraysetops.py -> ? ?build/lib.linux-x86_64-2.4/numpy/lib >>>> copying numpy/lib/index_tricks.py -> ? ?build/lib.linux-x86_64-2.4/numpy/lib >>>> copying numpy/lib/format.py -> ? ?build/lib.linux-x86_64-2.4/numpy/lib >>>> copying numpy/lib/setupscons.py -> ? ?build/lib.linux-x86_64-2.4/numpy/lib >>>> copying numpy/lib/__init__.py -> ? ?build/lib.linux-x86_64-2.4/numpy/lib >>>> copying numpy/lib/info.py -> ? ?build/lib.linux-x86_64-2.4/numpy/lib >>>> copying numpy/lib/function_base.py -> ? ?build/lib.linux-x86_64-2.4/numpy/lib >>>> copying numpy/lib/setup.py -> ? ?build/lib.linux-x86_64-2.4/numpy/lib >>>> copying numpy/lib/arrayterator.py -> ? ?build/lib.linux-x86_64-2.4/numpy/lib >>>> copying numpy/lib/ufunclike.py -> ? ?build/lib.linux-x86_64-2.4/numpy/lib >>>> copying numpy/lib/shape_base.py -> ? ?build/lib.linux-x86_64-2.4/numpy/lib >>>> copying numpy/lib/user_array.py -> ? ?build/lib.linux-x86_64-2.4/numpy/lib >>>> copying numpy/lib/type_check.py -> ? ?build/lib.linux-x86_64-2.4/numpy/lib >>>> copying numpy/lib/stride_tricks.py -> ? ?build/lib.linux-x86_64-2.4/numpy/lib >>>> copying numpy/lib/recfunctions.py -> ? ?build/lib.linux-x86_64-2.4/numpy/lib >>>> copying numpy/lib/npyio.py -> ? ?build/lib.linux-x86_64-2.4/numpy/lib >>>> copying numpy/lib/_iotools.py -> ? ?build/lib.linux-x86_64-2.4/numpy/lib >>>> copying numpy/lib/utils.py -> ? ?build/lib.linux-x86_64-2.4/numpy/lib >>>> copying numpy/lib/financial.py -> ? ?build/lib.linux-x86_64-2.4/numpy/lib >>>> copying numpy/lib/twodim_base.py -> ? ?build/lib.linux-x86_64-2.4/numpy/lib >>>> copying numpy/lib/polynomial.py -> ? ?build/lib.linux-x86_64-2.4/numpy/lib >>>> copying numpy/lib/scimath.py -> ? ?build/lib.linux-x86_64-2.4/numpy/lib >>>> creating build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>> copying numpy/oldnumeric/functions.py -> >>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>> copying numpy/oldnumeric/alter_code1.py -> >>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>> copying numpy/oldnumeric/misc.py -> ? ?build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>> copying numpy/oldnumeric/compat.py -> >>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>> copying numpy/oldnumeric/setupscons.py -> >>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>> copying numpy/oldnumeric/__init__.py -> >>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>> copying numpy/oldnumeric/linear_algebra.py -> >>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>> copying numpy/oldnumeric/setup.py -> ? ?build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>> copying numpy/oldnumeric/random_array.py -> >>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>> copying numpy/oldnumeric/user_array.py -> >>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>> copying numpy/oldnumeric/alter_code2.py -> >>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>> copying numpy/oldnumeric/fft.py -> ? ?build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>> copying numpy/oldnumeric/matrix.py -> >>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>> copying numpy/oldnumeric/fix_default_axis.py -> >>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>> copying numpy/oldnumeric/rng_stats.py -> >>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>> copying numpy/oldnumeric/mlab.py -> ? ?build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>> copying numpy/oldnumeric/ma.py -> ? ?build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>> copying numpy/oldnumeric/ufuncs.py -> >>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>> copying numpy/oldnumeric/rng.py -> ? ?build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>> copying numpy/oldnumeric/array_printer.py -> >>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>> copying numpy/oldnumeric/typeconv.py -> >>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>> copying numpy/oldnumeric/precision.py -> >>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>> copying numpy/oldnumeric/arrayfns.py -> >>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>> creating build/lib.linux-x86_64-2.4/numpy/numarray >>>> copying numpy/numarray/nd_image.py -> ? ?build/lib.linux-x86_64-2.4/numpy/numarray >>>> copying numpy/numarray/util.py -> ? ?build/lib.linux-x86_64-2.4/numpy/numarray >>>> copying numpy/numarray/convolve.py -> ? ?build/lib.linux-x86_64-2.4/numpy/numarray >>>> copying numpy/numarray/functions.py -> ? ?build/lib.linux-x86_64-2.4/numpy/numarray >>>> copying numpy/numarray/alter_code1.py -> >>>> build/lib.linux-x86_64-2.4/numpy/numarray >>>> copying numpy/numarray/compat.py -> ? ?build/lib.linux-x86_64-2.4/numpy/numarray >>>> copying numpy/numarray/setupscons.py -> >>>> build/lib.linux-x86_64-2.4/numpy/numarray >>>> copying numpy/numarray/__init__.py -> ? ?build/lib.linux-x86_64-2.4/numpy/numarray >>>> copying numpy/numarray/linear_algebra.py -> >>>> build/lib.linux-x86_64-2.4/numpy/numarray >>>> copying numpy/numarray/setup.py -> ? ?build/lib.linux-x86_64-2.4/numpy/numarray >>>> copying numpy/numarray/random_array.py -> >>>> build/lib.linux-x86_64-2.4/numpy/numarray >>>> copying numpy/numarray/alter_code2.py -> >>>> build/lib.linux-x86_64-2.4/numpy/numarray >>>> copying numpy/numarray/fft.py -> ? ?build/lib.linux-x86_64-2.4/numpy/numarray >>>> copying numpy/numarray/matrix.py -> ? ?build/lib.linux-x86_64-2.4/numpy/numarray >>>> copying numpy/numarray/numerictypes.py -> >>>> build/lib.linux-x86_64-2.4/numpy/numarray >>>> copying numpy/numarray/image.py -> ? ?build/lib.linux-x86_64-2.4/numpy/numarray >>>> copying numpy/numarray/mlab.py -> ? ?build/lib.linux-x86_64-2.4/numpy/numarray >>>> copying numpy/numarray/ma.py -> ? ?build/lib.linux-x86_64-2.4/numpy/numarray >>>> copying numpy/numarray/session.py -> ? ?build/lib.linux-x86_64-2.4/numpy/numarray >>>> copying numpy/numarray/ufuncs.py -> ? ?build/lib.linux-x86_64-2.4/numpy/numarray >>>> creating build/lib.linux-x86_64-2.4/numpy/fft >>>> copying numpy/fft/setupscons.py -> ? ?build/lib.linux-x86_64-2.4/numpy/fft >>>> copying numpy/fft/__init__.py -> ? ?build/lib.linux-x86_64-2.4/numpy/fft >>>> copying numpy/fft/info.py -> ? ?build/lib.linux-x86_64-2.4/numpy/fft >>>> copying numpy/fft/setup.py -> ? ?build/lib.linux-x86_64-2.4/numpy/fft >>>> copying numpy/fft/fftpack.py -> ? ?build/lib.linux-x86_64-2.4/numpy/fft >>>> copying numpy/fft/helper.py -> ? ?build/lib.linux-x86_64-2.4/numpy/fft >>>> creating build/lib.linux-x86_64-2.4/numpy/linalg >>>> copying numpy/linalg/setupscons.py -> ? ?build/lib.linux-x86_64-2.4/numpy/linalg >>>> copying numpy/linalg/__init__.py -> ? ?build/lib.linux-x86_64-2.4/numpy/linalg >>>> copying numpy/linalg/info.py -> ? ?build/lib.linux-x86_64-2.4/numpy/linalg >>>> copying numpy/linalg/setup.py -> ? ?build/lib.linux-x86_64-2.4/numpy/linalg >>>> copying numpy/linalg/linalg.py -> ? ?build/lib.linux-x86_64-2.4/numpy/linalg >>>> creating build/lib.linux-x86_64-2.4/numpy/random >>>> copying numpy/random/setupscons.py -> ? ?build/lib.linux-x86_64-2.4/numpy/random >>>> copying numpy/random/__init__.py -> ? ?build/lib.linux-x86_64-2.4/numpy/random >>>> copying numpy/random/info.py -> ? ?build/lib.linux-x86_64-2.4/numpy/random >>>> copying numpy/random/setup.py -> ? ?build/lib.linux-x86_64-2.4/numpy/random >>>> creating build/lib.linux-x86_64-2.4/numpy/ma >>>> copying numpy/ma/version.py -> ? ?build/lib.linux-x86_64-2.4/numpy/ma >>>> copying numpy/ma/setupscons.py -> ? ?build/lib.linux-x86_64-2.4/numpy/ma >>>> copying numpy/ma/__init__.py -> ? ?build/lib.linux-x86_64-2.4/numpy/ma >>>> copying numpy/ma/setup.py -> ? ?build/lib.linux-x86_64-2.4/numpy/ma >>>> copying numpy/ma/bench.py -> ? ?build/lib.linux-x86_64-2.4/numpy/ma >>>> copying numpy/ma/core.py -> ? ?build/lib.linux-x86_64-2.4/numpy/ma >>>> copying numpy/ma/testutils.py -> ? ?build/lib.linux-x86_64-2.4/numpy/ma >>>> copying numpy/ma/timer_comparison.py -> ? ?build/lib.linux-x86_64-2.4/numpy/ma >>>> copying numpy/ma/extras.py -> ? ?build/lib.linux-x86_64-2.4/numpy/ma >>>> copying numpy/ma/mrecords.py -> ? ?build/lib.linux-x86_64-2.4/numpy/ma >>>> creating build/lib.linux-x86_64-2.4/numpy/matrixlib >>>> copying numpy/matrixlib/setupscons.py -> >>>> build/lib.linux-x86_64-2.4/numpy/matrixlib >>>> copying numpy/matrixlib/__init__.py -> >>>> build/lib.linux-x86_64-2.4/numpy/matrixlib >>>> copying numpy/matrixlib/setup.py -> ? ?build/lib.linux-x86_64-2.4/numpy/matrixlib >>>> copying numpy/matrixlib/defmatrix.py -> >>>> build/lib.linux-x86_64-2.4/numpy/matrixlib >>>> creating build/lib.linux-x86_64-2.4/numpy/compat >>>> copying numpy/compat/setupscons.py -> ? ?build/lib.linux-x86_64-2.4/numpy/compat >>>> copying numpy/compat/__init__.py -> ? ?build/lib.linux-x86_64-2.4/numpy/compat >>>> copying numpy/compat/setup.py -> ? ?build/lib.linux-x86_64-2.4/numpy/compat >>>> copying numpy/compat/py3k.py -> ? ?build/lib.linux-x86_64-2.4/numpy/compat >>>> copying numpy/compat/_inspect.py -> ? ?build/lib.linux-x86_64-2.4/numpy/compat >>>> creating build/lib.linux-x86_64-2.4/numpy/polynomial >>>> copying numpy/polynomial/__init__.py -> >>>> build/lib.linux-x86_64-2.4/numpy/polynomial >>>> copying numpy/polynomial/setup.py -> ? ?build/lib.linux-x86_64-2.4/numpy/polynomial >>>> copying numpy/polynomial/chebyshev.py -> >>>> build/lib.linux-x86_64-2.4/numpy/polynomial >>>> copying numpy/polynomial/polynomial.py -> >>>> build/lib.linux-x86_64-2.4/numpy/polynomial >>>> copying numpy/polynomial/polyutils.py -> >>>> build/lib.linux-x86_64-2.4/numpy/polynomial >>>> copying numpy/polynomial/polytemplate.py -> >>>> build/lib.linux-x86_64-2.4/numpy/polynomial >>>> creating build/lib.linux-x86_64-2.4/numpy/doc >>>> copying numpy/doc/byteswapping.py -> ? ?build/lib.linux-x86_64-2.4/numpy/doc >>>> copying numpy/doc/glossary.py -> ? ?build/lib.linux-x86_64-2.4/numpy/doc >>>> copying numpy/doc/indexing.py -> ? ?build/lib.linux-x86_64-2.4/numpy/doc >>>> copying numpy/doc/misc.py -> ? ?build/lib.linux-x86_64-2.4/numpy/doc >>>> copying numpy/doc/internals.py -> ? ?build/lib.linux-x86_64-2.4/numpy/doc >>>> copying numpy/doc/__init__.py -> ? ?build/lib.linux-x86_64-2.4/numpy/doc >>>> copying numpy/doc/creation.py -> ? ?build/lib.linux-x86_64-2.4/numpy/doc >>>> copying numpy/doc/jargon.py -> ? ?build/lib.linux-x86_64-2.4/numpy/doc >>>> copying numpy/doc/basics.py -> ? ?build/lib.linux-x86_64-2.4/numpy/doc >>>> copying numpy/doc/io.py -> ? ?build/lib.linux-x86_64-2.4/numpy/doc >>>> copying numpy/doc/methods_vs_functions.py -> >>>> build/lib.linux-x86_64-2.4/numpy/doc >>>> copying numpy/doc/broadcasting.py -> ? ?build/lib.linux-x86_64-2.4/numpy/doc >>>> copying numpy/doc/constants.py -> ? ?build/lib.linux-x86_64-2.4/numpy/doc >>>> copying numpy/doc/howtofind.py -> ? ?build/lib.linux-x86_64-2.4/numpy/doc >>>> copying numpy/doc/ufuncs.py -> ? ?build/lib.linux-x86_64-2.4/numpy/doc >>>> copying numpy/doc/subclassing.py -> ? ?build/lib.linux-x86_64-2.4/numpy/doc >>>> copying numpy/doc/structured_arrays.py -> ? ?build/lib.linux-x86_64-2.4/numpy/doc >>>> copying numpy/doc/performance.py -> ? ?build/lib.linux-x86_64-2.4/numpy/doc >>>> running build_clib >>>> customize UnixCCompiler >>>> customize UnixCCompiler using build_clib >>>> building 'npymath' library >>>> compiling C sources >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> creating build/temp.linux-x86_64-2.4 >>>> creating build/temp.linux-x86_64-2.4/build >>>> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4 >>>> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy >>>> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core >>>> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src >>>> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/npymath >>>> compile options: '-Inumpy/core/include >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>> gcc: build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math.c >>>> In file included from numpy/core/src/private/npy_config.h:4, >>>> ? ? ? ? ? ? ? ? ? ?from numpy/core/src/npymath/npy_math_private.h:24, >>>> ? ? ? ? ? ? ? ? ? ?from numpy/core/src/npymath/npy_math.c.src:56: >>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >>>> warning: "HAVE_HYPOT" redefined >>>> In file included from /home/sanjey/include/python2.4/Python.h:8, >>>> ? ? ? ? ? ? ? ? ? ?from numpy/core/src/npymath/npy_math_private.h:21, >>>> ? ? ? ? ? ? ? ? ? ?from numpy/core/src/npymath/npy_math.c.src:56: >>>> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >>>> location of the previous definition >>>> gcc: build/src.linux-x86_64-2.4/numpy/core/src/npymath/ieee754.c >>>> In file included from numpy/core/src/private/npy_config.h:4, >>>> ? ? ? ? ? ? ? ? ? ?from numpy/core/src/npymath/npy_math_common.h:8, >>>> ? ? ? ? ? ? ? ? ? ?from numpy/core/src/npymath/ieee754.c.src:7: >>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >>>> warning: "HAVE_HYPOT" redefined >>>> In file included from /home/sanjey/include/python2.4/Python.h:8, >>>> ? ? ? ? ? ? ? ? ? ?from numpy/core/src/npymath/npy_math_common.h:4, >>>> ? ? ? ? ? ? ? ? ? ?from numpy/core/src/npymath/ieee754.c.src:7: >>>> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >>>> location of the previous definition >>>> gcc: build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math_complex.c >>>> In file included from numpy/core/src/private/npy_config.h:4, >>>> ? ? ? ? ? ? ? ? ? ?from numpy/core/src/npymath/npy_math_common.h:8, >>>> ? ? ? ? ? ? ? ? ? ?from numpy/core/src/npymath/npy_math_complex.c.src:31: >>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >>>> warning: "HAVE_HYPOT" redefined >>>> In file included from /home/sanjey/include/python2.4/Python.h:8, >>>> ? ? ? ? ? ? ? ? ? ?from numpy/core/src/npymath/npy_math_common.h:4, >>>> ? ? ? ? ? ? ? ? ? ?from numpy/core/src/npymath/npy_math_complex.c.src:31: >>>> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >>>> location of the previous definition >>>> ar: adding 3 object files to build/temp.linux-x86_64-2.4/libnpymath.a >>>> running build_ext >>>> customize UnixCCompiler >>>> customize UnixCCompiler using build_ext >>>> customize GnuFCompiler >>>> gnu: no Fortran 90 compiler found >>>> gnu: no Fortran 90 compiler found >>>> customize GnuFCompiler >>>> gnu: no Fortran 90 compiler found >>>> gnu: no Fortran 90 compiler found >>>> customize GnuFCompiler using build_ext >>>> building 'numpy.core._sort' extension >>>> compiling C sources >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/include >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>> gcc: build/src.linux-x86_64-2.4/numpy/core/src/_sortmodule.c >>>> In file included from numpy/core/src/private/npy_config.h:4, >>>> ? ? ? ? ? ? ? ? ? ?from numpy/core/src/_sortmodule.c.src:34: >>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >>>> warning: "HAVE_HYPOT" redefined >>>> In file included from /home/sanjey/include/python2.4/Python.h:8, >>>> ? ? ? ? ? ? ? ? ? ?from numpy/core/src/_sortmodule.c.src:30: >>>> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >>>> location of the previous definition >>>> gcc -m32 -pthread -shared >>>> build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/_sortmodule.o >>>> -Lbuild/temp.linux-x86_64-2.4 -lm -o >>>> build/lib.linux-x86_64-2.4/numpy/core/_sort.so >>>> building 'numpy.core.multiarray' extension >>>> compiling C sources >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> creating build/temp.linux-x86_64-2.4/numpy >>>> creating build/temp.linux-x86_64-2.4/numpy/core >>>> creating build/temp.linux-x86_64-2.4/numpy/core/src >>>> creating build/temp.linux-x86_64-2.4/numpy/core/src/multiarray >>>> compile options: '-Inumpy/core/include >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>> gcc: numpy/core/src/multiarray/multiarraymodule_onefile.c >>>> In file included from numpy/core/src/private/npy_config.h:4, >>>> ? ? ? ? ? ? ? ? ? ?from numpy/core/src/multiarray/common.c:8, >>>> ? ? ? ? ? ? ? ? ? ?from numpy/core/src/multiarray/multiarraymodule_onefile.c:8: >>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >>>> warning: "HAVE_HYPOT" redefined >>>> In file included from /home/sanjey/include/python2.4/Python.h:8, >>>> ? ? ? ? ? ? ? ? ? ?from numpy/core/src/multiarray/common.c:2, >>>> ? ? ? ? ? ? ? ? ? ?from numpy/core/src/multiarray/multiarraymodule_onefile.c:8: >>>> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >>>> location of the previous definition >>>> In file included from numpy/core/src/multiarray/multiarraymodule_onefile.c:26: >>>> numpy/core/src/multiarray/methods.c: In function `NpyArg_ParseKeywords': >>>> numpy/core/src/multiarray/methods.c:41: warning: passing arg 3 of >>>> `PyArg_VaParseTupleAndKeywords' discards qualifiers from pointer >>>> target type >>>> numpy/core/src/multiarray/flagsobject.c: In function `arrayflags_richcompare': >>>> numpy/core/src/multiarray/flagsobject.c:568: warning: 'cmp' might be >>>> used uninitialized in this function >>>> numpy/core/src/multiarray/multiarraymodule_onefile.c: At top level: >>>> numpy/core/include/numpy/npy_3kcompat.h:331: warning: >>>> 'simple_capsule_dtor' defined but not used >>>> numpy/core/src/multiarray/buffer.c:777: warning: >>>> '_descriptor_from_pep3118_format' defined but not used >>>> numpy/core/src/multiarray/arraytypes.c.src:93: warning: >>>> '_SEQUENCE_MESSAGE' defined but not used >>>> numpy/core/src/multiarray/mapping.c:75: warning: '_array_ass_item' >>>> defined but not used >>>> gcc -m32 -pthread -shared >>>> build/temp.linux-x86_64-2.4/numpy/core/src/multiarray/multiarraymodule_onefile.o >>>> -Lbuild/temp.linux-x86_64-2.4 -lnpymath -lm -o >>>> build/lib.linux-x86_64-2.4/numpy/core/multiarray.so >>>> building 'numpy.core.umath' extension >>>> compiling C sources >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> creating build/temp.linux-x86_64-2.4/numpy/core/src/umath >>>> compile options: '-Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath >>>> -Inumpy/core/include >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>> gcc: numpy/core/src/umath/umathmodule_onefile.c >>>> In file included from numpy/core/src/private/npy_config.h:4, >>>> ? ? ? ? ? ? ? ? ? ?from numpy/core/src/umath/loops.c.src:7, >>>> ? ? ? ? ? ? ? ? ? ?from numpy/core/src/umath/umathmodule_onefile.c:1: >>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >>>> warning: "HAVE_HYPOT" redefined >>>> In file included from /home/sanjey/include/python2.4/Python.h:8, >>>> ? ? ? ? ? ? ? ? ? ?from numpy/core/src/umath/loops.c.src:5, >>>> ? ? ? ? ? ? ? ? ? ?from numpy/core/src/umath/umathmodule_onefile.c:1: >>>> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >>>> location of the previous definition >>>> numpy/core/include/numpy/npy_3kcompat.h:331: warning: >>>> 'simple_capsule_dtor' defined but not used >>>> numpy/core/src/umath/loops.c.src:1258: warning: >>>> 'CLONGDOUBLE_logical_and' defined but not used >>>> numpy/core/src/umath/loops.c.src:1258: warning: >>>> 'CLONGDOUBLE_logical_or' defined but not used >>>> numpy/core/src/umath/loops.c.src:1271: warning: >>>> 'CLONGDOUBLE_logical_xor' defined but not used >>>> numpy/core/src/umath/loops.c.src:1285: warning: >>>> 'CLONGDOUBLE_logical_not' defined but not used >>>> numpy/core/src/umath/loops.c.src:1342: warning: >>>> 'CLONGDOUBLE_ones_like' defined but not used >>>> numpy/core/src/umath/loops.c.src:1399: warning: 'CLONGDOUBLE_maximum' >>>> defined but not used >>>> numpy/core/src/umath/loops.c.src:1399: warning: 'CLONGDOUBLE_minimum' >>>> defined but not used >>>> numpy/core/src/umath/loops.c.src:1423: warning: 'CLONGDOUBLE_fmax' >>>> defined but not used >>>> numpy/core/src/umath/loops.c.src:1423: warning: 'CLONGDOUBLE_fmin' >>>> defined but not used >>>> gcc -m32 -pthread -shared >>>> build/temp.linux-x86_64-2.4/numpy/core/src/umath/umathmodule_onefile.o >>>> -Lbuild/temp.linux-x86_64-2.4 -lnpymath -lm -o >>>> build/lib.linux-x86_64-2.4/numpy/core/umath.so >>>> building 'numpy.core.scalarmath' extension >>>> compiling C sources >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> compile options: '-Inumpy/core/include >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>> gcc: build/src.linux-x86_64-2.4/numpy/core/src/scalarmathmodule.c >>>> numpy/core/include/numpy/npy_3kcompat.h:331: warning: >>>> 'simple_capsule_dtor' defined but not used >>>> gcc -m32 -pthread -shared >>>> build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/scalarmathmodule.o >>>> -Lbuild/temp.linux-x86_64-2.4 -lm -o >>>> build/lib.linux-x86_64-2.4/numpy/core/scalarmath.so >>>> building 'numpy.core.umath_tests' extension >>>> compiling C sources >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/umath >>>> compile options: '-Inumpy/core/include >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>> gcc: build/src.linux-x86_64-2.4/numpy/core/src/umath/umath_tests.c >>>> In file included from numpy/core/src/private/npy_config.h:4, >>>> ? ? ? ? ? ? ? ? ? ?from numpy/core/src/umath/umath_tests.c.src:14: >>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >>>> warning: "HAVE_HYPOT" redefined >>>> In file included from /home/sanjey/include/python2.4/Python.h:8, >>>> ? ? ? ? ? ? ? ? ? ?from numpy/core/src/umath/umath_tests.c.src:8: >>>> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >>>> location of the previous definition >>>> numpy/core/include/numpy/npy_3kcompat.h:331: warning: >>>> 'simple_capsule_dtor' defined but not used >>>> gcc -m32 -pthread -shared >>>> build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/umath/umath_tests.o >>>> -Lbuild/temp.linux-x86_64-2.4 -o >>>> build/lib.linux-x86_64-2.4/numpy/core/umath_tests.so >>>> building 'numpy.core.multiarray_tests' extension >>>> compiling C sources >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>> compile options: '-Inumpy/core/include >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>> gcc: build/src.linux-x86_64-2.4/numpy/core/src/multiarray/multiarray_tests.c >>>> numpy/core/include/numpy/npy_3kcompat.h:331: warning: >>>> 'simple_capsule_dtor' defined but not used >>>> gcc -m32 -pthread -shared >>>> build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/multiarray/multiarray_tests.o >>>> -Lbuild/temp.linux-x86_64-2.4 -o >>>> build/lib.linux-x86_64-2.4/numpy/core/multiarray_tests.so >>>> building 'numpy.lib._compiled_base' extension >>>> compiling C sources >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> creating build/temp.linux-x86_64-2.4/numpy/lib >>>> creating build/temp.linux-x86_64-2.4/numpy/lib/src >>>> compile options: '-Inumpy/core/include >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>> gcc: numpy/lib/src/_compiled_base.c >>>> In file included from numpy/core/src/private/npy_config.h:4, >>>> ? ? ? ? ? ? ? ? ? ?from numpy/lib/src/_compiled_base.c:4: >>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >>>> warning: "HAVE_HYPOT" redefined >>>> In file included from /home/sanjey/include/python2.4/Python.h:8, >>>> ? ? ? ? ? ? ? ? ? ?from numpy/lib/src/_compiled_base.c:1: >>>> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >>>> location of the previous definition >>>> gcc -m32 -pthread -shared >>>> build/temp.linux-x86_64-2.4/numpy/lib/src/_compiled_base.o >>>> -Lbuild/temp.linux-x86_64-2.4 -o >>>> build/lib.linux-x86_64-2.4/numpy/lib/_compiled_base.so >>>> building 'numpy.numarray._capi' extension >>>> compiling C sources >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> creating build/temp.linux-x86_64-2.4/numpy/numarray >>>> compile options: '-Inumpy/core/include >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>> gcc: numpy/numarray/_capi.c >>>> numpy/core/include/numpy/npy_3kcompat.h:331: warning: >>>> 'simple_capsule_dtor' defined but not used >>>> gcc -m32 -pthread -shared >>>> build/temp.linux-x86_64-2.4/numpy/numarray/_capi.o >>>> -Lbuild/temp.linux-x86_64-2.4 -o >>>> build/lib.linux-x86_64-2.4/numpy/numarray/_capi.so >>>> building 'numpy.fft.fftpack_lite' extension >>>> compiling C sources >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> creating build/temp.linux-x86_64-2.4/numpy/fft >>>> compile options: '-Inumpy/core/include >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>> gcc: numpy/fft/fftpack_litemodule.c >>>> gcc: numpy/fft/fftpack.c >>>> gcc -m32 -pthread -shared >>>> build/temp.linux-x86_64-2.4/numpy/fft/fftpack_litemodule.o >>>> build/temp.linux-x86_64-2.4/numpy/fft/fftpack.o >>>> -Lbuild/temp.linux-x86_64-2.4 -o >>>> build/lib.linux-x86_64-2.4/numpy/fft/fftpack_lite.so >>>> building 'numpy.linalg.lapack_lite' extension >>>> compiling C sources >>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>> >>>> creating build/temp.linux-x86_64-2.4/numpy/linalg >>>> compile options: '-DNO_ATLAS_INFO=1 -Inumpy/core/include >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>> -Inumpy/core/src/umath -Inumpy/core/include >>>> -I/home/sanjey/include/python2.4 >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>> gcc: numpy/linalg/lapack_litemodule.c >>>> gcc: numpy/linalg/python_xerbla.c >>>> /usr/bin/g77 -g -Wall -g -Wall -shared >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o >>>> build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o -L/usr/lib >>>> -Lbuild/temp.linux-x86_64-2.4 -llapack -lblas -lg2c -o >>>> build/lib.linux-x86_64-2.4/numpy/linalg/lapack_lite.so >>>> /usr/bin/ld: skipping incompatible /usr/lib/liblapack.so when >>>> searching for -llapack >>>> /usr/bin/ld: skipping incompatible /usr/lib/liblapack.a when searching >>>> for -llapack >>>> /usr/bin/ld: skipping incompatible /usr/lib/libblas.so when searching for -lblas >>>> /usr/bin/ld: skipping incompatible /usr/lib/libblas.a when searching for -lblas >>>> /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm >>>> /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm >>>> /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm >>>> /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm >>>> /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 >>>> /usr/bin/ld: warning: i386 architecture of input file >>>> `build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o' is >>>> incompatible with i386:x86-64 output >>>> /usr/bin/ld: warning: i386 architecture of input file >>>> `build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o' is >>>> incompatible with i386:x86-64 output >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xae): >>>> In function `lapack_lite_dgeev': >>>> numpy/linalg/lapack_litemodule.c:155: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfe):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x143):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a3):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1f4):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x272):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31c):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ae):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x60e):numpy/linalg/lapack_litemodule.c:171: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6aa): >>>> In function `lapack_lite_dsyevd': >>>> numpy/linalg/lapack_litemodule.c:241: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6f4):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x739):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x797):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x7ef):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x869):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x8ff):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xa7c):numpy/linalg/lapack_litemodule.c:254: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb34): >>>> In function `lapack_lite_zheevd': >>>> numpy/linalg/lapack_litemodule.c:327: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb7e):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xbc3):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc23):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc74):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xce9):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xd85):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xe77):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfb9):numpy/linalg/lapack_litemodule.c:341: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1087): >>>> In function `lapack_lite_dgelsd': >>>> numpy/linalg/lapack_litemodule.c:365: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x10d7):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x111c):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x117d):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x11cf):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1252):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x12e8):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x13d7):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1534):numpy/linalg/lapack_litemodule.c:380: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15af): >>>> In function `lapack_lite_dgesv': >>>> numpy/linalg/lapack_litemodule.c:398: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15f9):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x163e):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1692):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x16e7):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x175e):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x189a):numpy/linalg/lapack_litemodule.c:407: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1967): >>>> In function `lapack_lite_dgesdd': >>>> numpy/linalg/lapack_litemodule.c:430: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19b7):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19fc):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a5d):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1aaf):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1b32):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1bc8):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d15):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d76):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1efb):numpy/linalg/lapack_litemodule.c:472: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x202b): >>>> In function `lapack_lite_dgetrf': >>>> numpy/linalg/lapack_litemodule.c:488: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2063):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20ae):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20fe):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2155):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2235):numpy/linalg/lapack_litemodule.c:496: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22b4): >>>> In function `lapack_lite_dpotrf': >>>> numpy/linalg/lapack_litemodule.c:510: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22e9):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x232d):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x238f):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x240a):numpy/linalg/lapack_litemodule.c:516: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24af): >>>> In function `lapack_lite_dgeqrf': >>>> numpy/linalg/lapack_litemodule.c:529: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24f9):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x253e):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2598):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x25ef):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2669):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x27a7):numpy/linalg/lapack_litemodule.c:540: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2839): >>>> In function `lapack_lite_dorgqr': >>>> numpy/linalg/lapack_litemodule.c:555: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2883):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x28c8):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2927):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x297f):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x29f9):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2afa):numpy/linalg/lapack_litemodule.c:562: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2bbb): >>>> In function `lapack_lite_zgeev': >>>> numpy/linalg/lapack_litemodule.c:585: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c0b):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c50):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2cb0):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d04):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d82):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2e2c):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2f6b):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2fb9):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x311b):numpy/linalg/lapack_litemodule.c:601: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31f4): >>>> In function `lapack_lite_zgelsd': >>>> numpy/linalg/lapack_litemodule.c:626: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3244):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3289):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x32ef):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3340):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x33c8):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3471):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35b1):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35ff):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x376f):numpy/linalg/lapack_litemodule.c:641: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x37ef): >>>> In function `lapack_lite_zgesv': >>>> numpy/linalg/lapack_litemodule.c:658: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3839):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x387e):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x38d2):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3927):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x399e):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3ada):numpy/linalg/lapack_litemodule.c:667: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bae): >>>> In function `lapack_lite_zgesdd': >>>> numpy/linalg/lapack_litemodule.c:691: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bfe):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3c43):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cab):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cff):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3d82):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3e2c):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3f70):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3fbe):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4195):numpy/linalg/lapack_litemodule.c:708: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x41ab):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x422b): >>>> In function `lapack_lite_zgetrf': >>>> numpy/linalg/lapack_litemodule.c:724: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4263):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42ae):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42fe):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4355):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4435):numpy/linalg/lapack_litemodule.c:732: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44b4): >>>> In function `lapack_lite_zpotrf': >>>> numpy/linalg/lapack_litemodule.c:746: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44e9):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x452d):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x458f):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460a):numpy/linalg/lapack_litemodule.c:751: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46af): >>>> In function `lapack_lite_zgeqrf': >>>> numpy/linalg/lapack_litemodule.c:764: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46f9):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x473e):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4798):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x47ef):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4869):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x49a7):numpy/linalg/lapack_litemodule.c:774: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a39): >>>> In function `lapack_lite_zungqr': >>>> numpy/linalg/lapack_litemodule.c:787: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a83):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ac8):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b27):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b7f):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4bf9):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4cfa):numpy/linalg/lapack_litemodule.c:797: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d58): >>>> In function `initlapack_lite': >>>> numpy/linalg/lapack_litemodule.c:858: undefined reference to `Py_InitModule4' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d71): >>>> In function `initlapack_lite': >>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1190: >>>> undefined reference to `PyImport_ImportModule' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d8d):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1197: >>>> undefined reference to `PyObject_GetAttrString' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4da6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1212: >>>> undefined reference to `PyCObject_Type' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4db5):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: >>>> undefined reference to `PyExc_RuntimeError' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dc9):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: >>>> undefined reference to `PyErr_SetString' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dd7): >>>> In function `initlapack_lite': >>>> numpy/linalg/lapack_litemodule.c:865: undefined reference to `PyErr_Print' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ddd):numpy/linalg/lapack_litemodule.c:865: >>>> undefined reference to `PyExc_ImportError' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4df1):numpy/linalg/lapack_litemodule.c:865: >>>> undefined reference to `PyErr_SetString' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e18): >>>> In function `initlapack_lite': >>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1194: >>>> undefined reference to `PyExc_ImportError' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e26):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: >>>> undefined reference to `PyErr_SetString' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e46):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1217: >>>> undefined reference to `PyCObject_AsVoidPtr' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e88):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: >>>> undefined reference to `PyExc_RuntimeError' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e96):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ea1):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: >>>> undefined reference to `PyExc_RuntimeError' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4eb6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1200: >>>> undefined reference to `PyExc_AttributeError' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f24):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: >>>> undefined reference to `PyExc_RuntimeError' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f2e):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f46): >>>> In function `initlapack_lite': >>>> numpy/linalg/lapack_litemodule.c:866: undefined reference to `PyModule_GetDict' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f66):numpy/linalg/lapack_litemodule.c:867: >>>> undefined reference to `PyErr_NewException' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f82):numpy/linalg/lapack_litemodule.c:868: >>>> undefined reference to `PyDict_SetItemString' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x70): >>>> In function `xerbla_': >>>> numpy/linalg/python_xerbla.c:35: undefined reference to `PyExc_ValueError' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x7e):numpy/linalg/python_xerbla.c:35: >>>> undefined reference to `PyErr_SetString' >>>> collect2: ld returned 1 exit status >>>> /usr/bin/ld: skipping incompatible /usr/lib/liblapack.so when >>>> searching for -llapack >>>> /usr/bin/ld: skipping incompatible /usr/lib/liblapack.a when searching >>>> for -llapack >>>> /usr/bin/ld: skipping incompatible /usr/lib/libblas.so when searching for -lblas >>>> /usr/bin/ld: skipping incompatible /usr/lib/libblas.a when searching for -lblas >>>> /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm >>>> /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm >>>> /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm >>>> /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm >>>> /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 >>>> /usr/bin/ld: warning: i386 architecture of input file >>>> `build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o' is >>>> incompatible with i386:x86-64 output >>>> /usr/bin/ld: warning: i386 architecture of input file >>>> `build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o' is >>>> incompatible with i386:x86-64 output >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xae): >>>> In function `lapack_lite_dgeev': >>>> numpy/linalg/lapack_litemodule.c:155: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfe):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x143):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a3):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1f4):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x272):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31c):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ae):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x60e):numpy/linalg/lapack_litemodule.c:171: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6aa): >>>> In function `lapack_lite_dsyevd': >>>> numpy/linalg/lapack_litemodule.c:241: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6f4):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x739):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x797):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x7ef):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x869):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x8ff):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xa7c):numpy/linalg/lapack_litemodule.c:254: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb34): >>>> In function `lapack_lite_zheevd': >>>> numpy/linalg/lapack_litemodule.c:327: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb7e):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xbc3):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc23):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc74):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xce9):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xd85):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xe77):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfb9):numpy/linalg/lapack_litemodule.c:341: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1087): >>>> In function `lapack_lite_dgelsd': >>>> numpy/linalg/lapack_litemodule.c:365: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x10d7):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x111c):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x117d):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x11cf):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1252):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x12e8):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x13d7):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1534):numpy/linalg/lapack_litemodule.c:380: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15af): >>>> In function `lapack_lite_dgesv': >>>> numpy/linalg/lapack_litemodule.c:398: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15f9):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x163e):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1692):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x16e7):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x175e):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x189a):numpy/linalg/lapack_litemodule.c:407: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1967): >>>> In function `lapack_lite_dgesdd': >>>> numpy/linalg/lapack_litemodule.c:430: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19b7):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19fc):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a5d):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1aaf):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1b32):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1bc8):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d15):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d76):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1efb):numpy/linalg/lapack_litemodule.c:472: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x202b): >>>> In function `lapack_lite_dgetrf': >>>> numpy/linalg/lapack_litemodule.c:488: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2063):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20ae):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20fe):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2155):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2235):numpy/linalg/lapack_litemodule.c:496: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22b4): >>>> In function `lapack_lite_dpotrf': >>>> numpy/linalg/lapack_litemodule.c:510: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22e9):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x232d):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x238f):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x240a):numpy/linalg/lapack_litemodule.c:516: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24af): >>>> In function `lapack_lite_dgeqrf': >>>> numpy/linalg/lapack_litemodule.c:529: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24f9):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x253e):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2598):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x25ef):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2669):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x27a7):numpy/linalg/lapack_litemodule.c:540: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2839): >>>> In function `lapack_lite_dorgqr': >>>> numpy/linalg/lapack_litemodule.c:555: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2883):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x28c8):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2927):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x297f):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x29f9):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2afa):numpy/linalg/lapack_litemodule.c:562: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2bbb): >>>> In function `lapack_lite_zgeev': >>>> numpy/linalg/lapack_litemodule.c:585: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c0b):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c50):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2cb0):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d04):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d82):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2e2c):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2f6b):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2fb9):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x311b):numpy/linalg/lapack_litemodule.c:601: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31f4): >>>> In function `lapack_lite_zgelsd': >>>> numpy/linalg/lapack_litemodule.c:626: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3244):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3289):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x32ef):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3340):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x33c8):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3471):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35b1):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35ff):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x376f):numpy/linalg/lapack_litemodule.c:641: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x37ef): >>>> In function `lapack_lite_zgesv': >>>> numpy/linalg/lapack_litemodule.c:658: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3839):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x387e):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x38d2):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3927):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x399e):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3ada):numpy/linalg/lapack_litemodule.c:667: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bae): >>>> In function `lapack_lite_zgesdd': >>>> numpy/linalg/lapack_litemodule.c:691: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bfe):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3c43):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cab):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cff):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3d82):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3e2c):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3f70):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3fbe):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4195):numpy/linalg/lapack_litemodule.c:708: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x41ab):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x422b): >>>> In function `lapack_lite_zgetrf': >>>> numpy/linalg/lapack_litemodule.c:724: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4263):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42ae):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42fe):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4355):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4435):numpy/linalg/lapack_litemodule.c:732: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44b4): >>>> In function `lapack_lite_zpotrf': >>>> numpy/linalg/lapack_litemodule.c:746: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44e9):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x452d):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x458f):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460a):numpy/linalg/lapack_litemodule.c:751: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46af): >>>> In function `lapack_lite_zgeqrf': >>>> numpy/linalg/lapack_litemodule.c:764: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46f9):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x473e):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4798):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x47ef):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4869):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x49a7):numpy/linalg/lapack_litemodule.c:774: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a39): >>>> In function `lapack_lite_zungqr': >>>> numpy/linalg/lapack_litemodule.c:787: undefined reference to `PyArg_ParseTuple' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a83):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ac8):numpy/linalg/lapack_litemodule.c:114: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b27):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b7f):numpy/linalg/lapack_litemodule.c:120: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4bf9):numpy/linalg/lapack_litemodule.c:103: >>>> undefined reference to `PyType_IsSubtype' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4cfa):numpy/linalg/lapack_litemodule.c:797: >>>> undefined reference to `Py_BuildValue' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d58): >>>> In function `initlapack_lite': >>>> numpy/linalg/lapack_litemodule.c:858: undefined reference to `Py_InitModule4' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d71): >>>> In function `initlapack_lite': >>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1190: >>>> undefined reference to `PyImport_ImportModule' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d8d):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1197: >>>> undefined reference to `PyObject_GetAttrString' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4da6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1212: >>>> undefined reference to `PyCObject_Type' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4db5):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: >>>> undefined reference to `PyExc_RuntimeError' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dc9):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: >>>> undefined reference to `PyErr_SetString' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dd7): >>>> In function `initlapack_lite': >>>> numpy/linalg/lapack_litemodule.c:865: undefined reference to `PyErr_Print' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ddd):numpy/linalg/lapack_litemodule.c:865: >>>> undefined reference to `PyExc_ImportError' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4df1):numpy/linalg/lapack_litemodule.c:865: >>>> undefined reference to `PyErr_SetString' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e18): >>>> In function `initlapack_lite': >>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1194: >>>> undefined reference to `PyExc_ImportError' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e26):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: >>>> undefined reference to `PyErr_SetString' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e46):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1217: >>>> undefined reference to `PyCObject_AsVoidPtr' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e88):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: >>>> undefined reference to `PyExc_RuntimeError' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e96):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ea1):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: >>>> undefined reference to `PyExc_RuntimeError' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4eb6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1200: >>>> undefined reference to `PyExc_AttributeError' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f24):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: >>>> undefined reference to `PyExc_RuntimeError' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f2e):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: >>>> undefined reference to `PyErr_Format' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f46): >>>> In function `initlapack_lite': >>>> numpy/linalg/lapack_litemodule.c:866: undefined reference to `PyModule_GetDict' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f66):numpy/linalg/lapack_litemodule.c:867: >>>> undefined reference to `PyErr_NewException' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f82):numpy/linalg/lapack_litemodule.c:868: >>>> undefined reference to `PyDict_SetItemString' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x70): >>>> In function `xerbla_': >>>> numpy/linalg/python_xerbla.c:35: undefined reference to `PyExc_ValueError' >>>> build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x7e):numpy/linalg/python_xerbla.c:35: >>>> undefined reference to `PyErr_SetString' >>>> collect2: ld returned 1 exit status >>>> _______________________________________________ >>>> NumPy-Discussion mailing list >>>> NumPy-Discussion at scipy.org >>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion >>> Since you are using the -m32 flag, do you have *all* the 32-bit >>> libraries/headers installed (especially Python 2.4 ones) what appears to >>> be a x86_64 operating system? >>> >>> >>> Bruce >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> NumPy-Discussion mailing list >>> NumPy-Discussion at scipy.org >>> http://mail.scipy.org/mailman/listinfo/numpy-discussion >>> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion > > The errors are related to numpy not being able to find the Python 2.4 > 32-bit headers. > > You have to had built Python 2.4 as 32-bit ?and you need to add the > appropriate path to the appropriate Python 2.4 32-bit ?header files when > running 32-bit Python 2.4. > > > Bruce > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > From structures-it at embl-heidelberg.de Fri Oct 15 13:23:27 2010 From: structures-it at embl-heidelberg.de (Frank Thommen) Date: Fri, 15 Oct 2010 19:23:27 +0200 Subject: [Numpy-discussion] Need help for the migration from Numeric to numpy In-Reply-To: <4CB74415.3050004@noaa.gov> References: <4CB6AF45.6020903@embl-heidelberg.de> <4CB72C40.4050802@noaa.gov> <4CB733CF.5010202@embl-heidelberg.de> <4CB74415.3050004@noaa.gov> Message-ID: <4CB88E0F.2030902@embl-heidelberg.de> Christopher Barker wrote: > On 10/14/10 9:46 AM, Frank Thommen wrote: >> We are speaking of potentially several hundred files. It's part of the >> scientific work of the user of the last nine years... > > Let's hope he's got some tests! Yes, we can compare the outputs with the existing results of the "old" version. >> Which conversion script do you mean? I couldn't find any conversion >> script that works or comes close to working. > > I don't know anything you don't know -- I thought you got a script to > work, it just didn't do the full job -- it may well have done some of > the simple scut work, though. The script I mentioned was the conversion script which is distributed with numpy (alter_code1.py). But this script doesn't seem to be maintained any more. > Anyway, hundreds of files sounds like a lot, but while it's boring work, > it's probably less than you'd think once you get started. You'd want a > multiple-file search and replace tool, though. I've tried with some sample scripts. Simply replacing "Numeric" by "numpy" leads to other errors (wrong attributes etc.). However since I don't have the resources to do this for the user, I've now installed the historical Numeric 24.2 and the user is warned, not to use Numeric for any new script and that Numeric will be removed in the future. That should give him enough time to go through his old scripts and change them. frank From structures-it at embl-heidelberg.de Fri Oct 15 13:31:33 2010 From: structures-it at embl-heidelberg.de (Frank Thommen) Date: Fri, 15 Oct 2010 19:31:33 +0200 Subject: [Numpy-discussion] Need help for the migration from Numeric to numpy In-Reply-To: <4CB74E65.8050401@gmail.com> References: <4CB6AF45.6020903@embl-heidelberg.de> <4CB72C40.4050802@noaa.gov> <4CB733CF.5010202@embl-heidelberg.de> <4CB74415.3050004@noaa.gov> <4CB74E65.8050401@gmail.com> Message-ID: <4CB88FF5.5060702@embl-heidelberg.de> Bruce Southey wrote: > On 10/14/2010 12:55 PM, Christopher Barker wrote: >> On 10/14/10 9:46 AM, Frank Thommen wrote: >>> We are speaking of potentially several hundred files. It's part of the >>> scientific work of the user of the last nine years... >> Let's hope he's got some tests! >> >>> Which conversion script do you mean? I couldn't find any conversion >>> script that works or comes close to working. >> I don't know anything you don't know -- I thought you got a script to >> work, it just didn't do the full job -- it may well have done some of >> the simple scut work, though. >> >> Anyway, hundreds of files sounds like a lot, but while it's boring work, >> it's probably less than you'd think once you get started. You'd want a >> multiple-file search and replace tool, though. >> >> -Chris >> >> >> > > It took me a while to track it down, but there used to be a module/file > called 'convertcode.py' for conversion. It was mentioned as tip in > Travis's 'Guide to Numpy' page 31 in Jan 6 2005 version. But the > alter_code path is in Dec 7 2006 (linked at http://docs.scipy.org/doc/). > It is advisable to read it as it address differences between Numeric and > old numpy ie section 2.6! Thanks for the hint. I'm currently reading through this document. I'm sure this will help a lot. convertcode.py doesn't seem to provided with current numpy releases. > Travis said in the thread: > http://mail.scipy.org/pipermail/numpy-discussion/2006-August/010085.html > "The transition approach is to use the compatibility layer first by > running oldnumeric.alter_code1.py and then running alter_code2.py which > will take you from the compatibility layer to NumPy (but alter_code2 is > not completed yet)." My experience is, that these scripts don't work at all (any more). frank From structures-it at embl-heidelberg.de Fri Oct 15 13:34:05 2010 From: structures-it at embl-heidelberg.de (Frank Thommen) Date: Fri, 15 Oct 2010 19:34:05 +0200 Subject: [Numpy-discussion] Need help for the migration from Numeric to numpy In-Reply-To: References: <4CB6AF45.6020903@embl-heidelberg.de> <4CB72C40.4050802@noaa.gov> <4CB733CF.5010202@embl-heidelberg.de> <4CB74415.3050004@noaa.gov> Message-ID: <4CB8908D.1090503@embl-heidelberg.de> Fernando Perez wrote: > On Thu, Oct 14, 2010 at 10:55 AM, Christopher Barker > wrote: >>> We are speaking of potentially several hundred files. It's part of the >>> scientific work of the user of the last nine years... >> Let's hope he's got some tests! > > Yup. I converted a very complex code from Numeric to numpy years ago > (around the numpy 1.0 release timeframe), and it was a single (long, > intense and focused) day's work. But that was thanks to a very solid > test suite that let me be systematic and dumb about the whole thing > (careful, but dumb). Yes, we can compare the outputs with existing data, that was created with the current scripts. Still: It's all manual work as these are all individual scripts to process scientific data. > With no good test coverage, let's just say that the OP's colleague is > in for a personal replay of the painful minefield scene in the BAT*21 > movie :) [http://www.imdb.com/title/tt0094712] Great movie, isn't it? :-) frank From rowen at uw.edu Fri Oct 15 13:54:30 2010 From: rowen at uw.edu (Russell E. Owen) Date: Fri, 15 Oct 2010 10:54:30 -0700 Subject: [Numpy-discussion] help from OS X 10.5 users wanted References: <4CB4C99A.8040906@noaa.gov> <4CB5E208.5030909@noaa.gov> Message-ID: Sorry I missed this thread until just now. I think you have it under control, but for the record I have a 10.4 Intel machine I keep around for the sole purpose of building backward-compatible binary installers for PIL and matplotlib. If help is still wanted I'm happy to build numpy as well. I did this because I was not able to figure out how to build matplotlib or PIL on 10.5 or 10.6 in such a way that it would run on older Macs. (I made static universal libraries for their dependencies, using the 10.4 SDK, but somehow that was not enough). So I'm not surprised you are having problems. Note that the Mac Python 2.5 from python.org has some known issues with Tkinter so I never use it, but I could install it for this purpose (just not test it very easily) since numpy doesn't care about Tkinter. -- Russell In article <4CB5E208.5030909 at noaa.gov>, Christopher Barker wrote: > On 10/13/10 8:30 AM, Ralf Gommers wrote: > > For what it's worth, the posted binary seems to work fine on my OS-X > > 10.5 PPC system (python2.6), so maybe the PPC part works, the Intel part > > not. > > > > Thanks, good to know. > > > > > My conclusion is that binaries built on 10.6 > > > do not work on 10.5 even when using the correct SDK and deployment > > > target. > > It sounds like they work on everything except Intel 10.5 -- is that right? > > > Well, I still think if you do everything right, it works, but yes, it is > > a pain to get right, and a pain to test. Building on the oldest system > > you want to support is a lot easier. > > > > I don't think so - at least I have not been able to find a fix for the > > error below in the many many bug reports one can find: > > > > ImportError?: dlopen(somefile.so, 2): no suitable image found. Did find: > > > > somefile.so: unknown required load command 0x80000022 > > Well, there are two options now: > > 1) keep trying to fix that error -- a post to the pythonmac list might > help there. > > 2) Punt, and just build on an older system. It sounds like Vincent may > be able to help out with that. > > (I've got a Intel 10.6 system and a PPC 10.5 system now, but I'll > probably lose the 10.5 one soon) > > On 10/12/10 6:12 PM, Vincent Davis wrote: > >>> install on 10.5 with binaries made on 10.6. So if I can learn > >>> something and help others that is great. > > Vincent -- if you are game, I suggest: > > Set up a 10.4 system, install the python.org 2.5, 2.6 and 32bit 2.7 > binaries. > > On that, build: > > >> Python 2.5: 32-bit PPC/i386 for Mac OS X 10.3.9 through 10.6 > >> > >> Python 2.6: 32-bit PPC/i386 for Mac OS X 10.3.9 through 10.6 > >> > >> Python 2.7 32-bit PPC/i386 for Mac OS X 10.3.9 through 10.6 > > On a 10.5 system, build: > > >> Python 2.7 PPC/i386/x86-64 for Mac OS X 10.5 or later > > As for Python 3k -- I have no idea! > > I might be able to do the 10.5 builds -- but I don't know for how long. > > Do you have the machines (or VMs) to do that? > > Thanks so much! > > NOTE: are there buildbots somewhere that could be used for this? > > -Chris From bsouthey at gmail.com Fri Oct 15 13:47:57 2010 From: bsouthey at gmail.com (Bruce Southey) Date: Fri, 15 Oct 2010 12:47:57 -0500 Subject: [Numpy-discussion] Please help a newbie install NUMPY In-Reply-To: References: <4CB871D8.4080503@gmail.com> <4CB878C2.2070009@gmail.com> Message-ID: <4CB893CD.5090908@gmail.com> On 10/15/2010 11:57 AM, P Sanjey wrote: > oh ok so it cant find the python headers? > Can I specify them in the site.cfg? I read on the numpy site to do > that for MKL but thats for intel compilers and I used gcc > Is it also possible to specify them on this line? > > python setup.py build? > > > I did something like this for python 32 bit > > CC=" gcc -m32" ./configuree --prefix=/path > > Is it possible to do that here? > > I have one more doubt-if I have built python using gcc can I buld > numpy using intel/mkl....etc or should it be gcc s well? > > Thanks soo much Bruce its becoming a bit clearer > > On Fri, Oct 15, 2010 at 4:52 PM, Bruce Southey wrote: >> On 10/15/2010 10:30 AM, P Sanjey wrote: >>> Hi Bruce, >>> >>> Not sure how to check if they are there (the libraries)-do you mean >>> the ones with .so extensions? >>> How can I know wht libraries are needed and whats already there? >>> >>> Yes its a x86_64 machine but I need a 32 bit version as I have another >>> piece of code that only works on 32 bits >>> so I am stuck with the 32 bit version >>> >>> Thanks for the help >>> >>> On Fri, Oct 15, 2010 at 4:23 PM, Bruce Southey wrote: >>>> On 10/15/2010 09:31 AM, P Sanjey wrote: >>>>> Please help-I am a newbie and I wanted to try installing numpy on a >>>>> local /home/usr directory but got the following errors-I am not sure >>>>> where to even begin fixing this problem and any help would be useful >>>>> I just did the standard >>>>> python setup.py build and got the following (loooooong) error message >>>>> >>>>> >>>>> ********************************************************** >>>>> non-existing path in 'numpy/distutils': 'site.cfg' >>>>> F2PY Version 1 >>>>> blas_opt_info: >>>>> blas_mkl_info: >>>>> libraries mkl,vml,guide not found in /home/sanjey/lib >>>>> libraries mkl,vml,guide not found in /usr/local/lib >>>>> libraries mkl,vml,guide not found in /usr/lib >>>>> NOT AVAILABLE >>>>> >>>>> atlas_blas_threads_info: >>>>> Setting PTATLAS=ATLAS >>>>> libraries ptf77blas,ptcblas,atlas not found in /home/sanjey/lib >>>>> libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib >>>>> libraries ptf77blas,ptcblas,atlas not found in /usr/lib/sse2 >>>>> libraries ptf77blas,ptcblas,atlas not found in /usr/lib >>>>> NOT AVAILABLE >>>>> >>>>> atlas_blas_info: >>>>> libraries f77blas,cblas,atlas not found in /home/sanjey/lib >>>>> libraries f77blas,cblas,atlas not found in /usr/local/lib >>>>> libraries f77blas,cblas,atlas not found in /usr/lib/sse2 >>>>> libraries f77blas,cblas,atlas not found in /usr/lib >>>>> NOT AVAILABLE >>>>> >>>>> blas_info: >>>>> libraries blas not found in /home/sanjey/lib >>>>> libraries blas not found in /usr/local/lib >>>>> FOUND: >>>>> libraries = ['blas'] >>>>> library_dirs = ['/usr/lib'] >>>>> language = f77 >>>>> >>>>> FOUND: >>>>> libraries = ['blas'] >>>>> library_dirs = ['/usr/lib'] >>>>> define_macros = [('NO_ATLAS_INFO', 1)] >>>>> language = f77 >>>>> >>>>> lapack_opt_info: >>>>> lapack_mkl_info: >>>>> mkl_info: >>>>> libraries mkl,vml,guide not found in /home/sanjey/lib >>>>> libraries mkl,vml,guide not found in /usr/local/lib >>>>> libraries mkl,vml,guide not found in /usr/lib >>>>> NOT AVAILABLE >>>>> >>>>> NOT AVAILABLE >>>>> >>>>> atlas_threads_info: >>>>> Setting PTATLAS=ATLAS >>>>> libraries ptf77blas,ptcblas,atlas not found in /home/sanjey/lib >>>>> libraries lapack_atlas not found in /home/sanjey/lib >>>>> libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib >>>>> libraries lapack_atlas not found in /usr/local/lib >>>>> libraries ptf77blas,ptcblas,atlas not found in /usr/lib/sse2 >>>>> libraries lapack_atlas not found in /usr/lib/sse2 >>>>> libraries ptf77blas,ptcblas,atlas not found in /usr/lib >>>>> libraries lapack_atlas not found in /usr/lib >>>>> numpy.distutils.system_info.atlas_threads_info >>>>> NOT AVAILABLE >>>>> >>>>> atlas_info: >>>>> libraries f77blas,cblas,atlas not found in /home/sanjey/lib >>>>> libraries lapack_atlas not found in /home/sanjey/lib >>>>> libraries f77blas,cblas,atlas not found in /usr/local/lib >>>>> libraries lapack_atlas not found in /usr/local/lib >>>>> libraries f77blas,cblas,atlas not found in /usr/lib/sse2 >>>>> libraries lapack_atlas not found in /usr/lib/sse2 >>>>> libraries f77blas,cblas,atlas not found in /usr/lib >>>>> libraries lapack_atlas not found in /usr/lib >>>>> numpy.distutils.system_info.atlas_info >>>>> NOT AVAILABLE >>>>> >>>>> lapack_info: >>>>> libraries lapack not found in /home/sanjey/lib >>>>> libraries lapack not found in /usr/local/lib >>>>> FOUND: >>>>> libraries = ['lapack'] >>>>> library_dirs = ['/usr/lib'] >>>>> language = f77 >>>>> >>>>> FOUND: >>>>> libraries = ['lapack', 'blas'] >>>>> library_dirs = ['/usr/lib'] >>>>> define_macros = [('NO_ATLAS_INFO', 1)] >>>>> language = f77 >>>>> >>>>> running build >>>>> running config_cc >>>>> unifing config_cc, config, build_clib, build_ext, build commands >>>>> --compiler options >>>>> running config_fc >>>>> unifing config_fc, config, build_clib, build_ext, build commands >>>>> --fcompiler options >>>>> running build_src >>>>> 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 library "npymath" sources >>>>> customize GnuFCompiler >>>>> Found executable /usr/bin/g77 >>>>> gnu: no Fortran 90 compiler found >>>>> gnu: no Fortran 90 compiler found >>>>> customize GnuFCompiler >>>>> gnu: no Fortran 90 compiler found >>>>> gnu: no Fortran 90 compiler found >>>>> customize GnuFCompiler using config >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> gcc -m32 -pthread _configtest.o -o _configtest >>>>> success! >>>>> removing: _configtest.c _configtest.o _configtest >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:1: warning: conflicting types for built-in function 'exp' >>>>> gcc -m32 -pthread _configtest.o -o _configtest >>>>> _configtest.o(.text+0x19): In function `main': >>>>> /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' >>>>> collect2: ld returned 1 exit status >>>>> _configtest.o(.text+0x19): In function `main': >>>>> /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' >>>>> collect2: ld returned 1 exit status >>>>> failure. >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:1: warning: conflicting types for built-in function 'exp' >>>>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>>>> success! >>>>> removing: _configtest.c _configtest.o _configtest >>>>> creating build/src.linux-x86_64-2.4/numpy/core >>>>> creating build/src.linux-x86_64-2.4/numpy/core/src >>>>> creating build/src.linux-x86_64-2.4/numpy/core/src/npymath >>>>> conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math.c >>>>> conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/npymath/ieee754.c >>>>> conv_template:> >>>>> build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math_complex.c >>>>> building extension "numpy.core._sort" sources >>>>> Generating build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> success! >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> success! >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:5: warning: function declaration isn't a prototype >>>>> success! >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:5: warning: function declaration isn't a prototype >>>>> success! >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:5: warning: function declaration isn't a prototype >>>>> success! >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:5: warning: function declaration isn't a prototype >>>>> success! >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> removing: _configtest.c _configtest.o _configtest.c _configtest.o >>>>> _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c >>>>> _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:5: warning: function declaration isn't a prototype >>>>> success! >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> removing: _configtest.c _configtest.o _configtest.c _configtest.o >>>>> _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c >>>>> _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o >>>>> _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:5: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:7: error: `SIZEOF_LONGDOUBLE' undeclared (first use in >>>>> this function) >>>>> _configtest.c:7: error: (Each undeclared identifier is reported only once >>>>> _configtest.c:7: error: for each function it appears in.) >>>>> _configtest.c:5: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:7: error: `SIZEOF_LONGDOUBLE' undeclared (first use in >>>>> this function) >>>>> _configtest.c:7: error: (Each undeclared identifier is reported only once >>>>> _configtest.c:7: error: for each function it appears in.) >>>>> failure. >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> removing: _configtest.c _configtest.o _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> removing: _configtest.c _configtest.o _configtest.c _configtest.o >>>>> _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c >>>>> _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o >>>>> _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c >>>>> _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> removing: _configtest.c _configtest.o _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:6: warning: function declaration isn't a prototype >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:6: warning: function declaration isn't a prototype >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:5: warning: function declaration isn't a prototype >>>>> success! >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:6: warning: function declaration isn't a prototype >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:6: warning: function declaration isn't a prototype >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:5: warning: function declaration isn't a prototype >>>>> success! >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:1: warning: conflicting types for built-in function 'exp' >>>>> gcc -m32 -pthread _configtest.o -o _configtest >>>>> _configtest.o(.text+0x19): In function `main': >>>>> /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' >>>>> collect2: ld returned 1 exit status >>>>> _configtest.o(.text+0x19): In function `main': >>>>> /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' >>>>> collect2: ld returned 1 exit status >>>>> failure. >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:1: warning: conflicting types for built-in function 'exp' >>>>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>>>> success! >>>>> removing: _configtest.c _configtest.o _configtest >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:1: warning: conflicting types for built-in function 'asin' >>>>> _configtest.c:2: warning: conflicting types for built-in function 'cos' >>>>> _configtest.c:3: warning: conflicting types for built-in function 'log' >>>>> _configtest.c:4: warning: conflicting types for built-in function 'fabs' >>>>> _configtest.c:5: warning: conflicting types for built-in function 'tanh' >>>>> _configtest.c:6: warning: conflicting types for built-in function 'atan' >>>>> _configtest.c:7: warning: conflicting types for built-in function 'acos' >>>>> _configtest.c:8: warning: conflicting types for built-in function 'floor' >>>>> _configtest.c:9: warning: conflicting types for built-in function 'fmod' >>>>> _configtest.c:10: warning: conflicting types for built-in function 'sqrt' >>>>> _configtest.c:11: warning: conflicting types for built-in function 'cosh' >>>>> _configtest.c:12: warning: conflicting types for built-in function 'modf' >>>>> _configtest.c:13: warning: conflicting types for built-in function 'sinh' >>>>> _configtest.c:14: warning: conflicting types for built-in function 'frexp' >>>>> _configtest.c:15: warning: conflicting types for built-in function 'exp' >>>>> _configtest.c:16: warning: conflicting types for built-in function 'tan' >>>>> _configtest.c:17: warning: conflicting types for built-in function 'ceil' >>>>> _configtest.c:18: warning: conflicting types for built-in function 'log10' >>>>> _configtest.c:19: warning: conflicting types for built-in function 'sin' >>>>> _configtest.c:20: warning: conflicting types for built-in function 'ldexp' >>>>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>>>> success! >>>>> removing: _configtest.c _configtest.o _configtest >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:1: warning: conflicting types for built-in function 'expm1' >>>>> _configtest.c:2: warning: conflicting types for built-in function 'log2' >>>>> _configtest.c:3: warning: conflicting types for built-in function 'pow' >>>>> _configtest.c:4: warning: conflicting types for built-in function 'rint' >>>>> _configtest.c:5: warning: conflicting types for built-in function 'atanh' >>>>> _configtest.c:6: warning: conflicting types for built-in function 'copysign' >>>>> _configtest.c:7: warning: conflicting types for built-in function 'asinh' >>>>> _configtest.c:8: warning: conflicting types for built-in function 'atan2' >>>>> _configtest.c:9: warning: conflicting types for built-in function 'hypot' >>>>> _configtest.c:10: warning: conflicting types for built-in function 'acosh' >>>>> _configtest.c:11: warning: conflicting types for built-in function 'exp2' >>>>> _configtest.c:12: warning: conflicting types for built-in function 'log1p' >>>>> _configtest.c:13: warning: conflicting types for built-in function 'nextafter' >>>>> _configtest.c:14: warning: conflicting types for built-in function 'trunc' >>>>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>>>> success! >>>>> removing: _configtest.c _configtest.o _configtest >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:1: warning: conflicting types for built-in function 'cosf' >>>>> _configtest.c:2: warning: conflicting types for built-in function 'coshf' >>>>> _configtest.c:3: warning: conflicting types for built-in function 'rintf' >>>>> _configtest.c:4: warning: conflicting types for built-in function 'fabsf' >>>>> _configtest.c:5: warning: conflicting types for built-in function 'floorf' >>>>> _configtest.c:6: warning: conflicting types for built-in function 'nextafterf' >>>>> _configtest.c:7: warning: conflicting types for built-in function 'tanhf' >>>>> _configtest.c:8: warning: conflicting types for built-in function 'log10f' >>>>> _configtest.c:9: warning: conflicting types for built-in function 'logf' >>>>> _configtest.c:10: warning: conflicting types for built-in function 'sinhf' >>>>> _configtest.c:11: warning: conflicting types for built-in function 'acosf' >>>>> _configtest.c:12: warning: conflicting types for built-in function 'sqrtf' >>>>> _configtest.c:13: warning: conflicting types for built-in function 'ldexpf' >>>>> _configtest.c:14: warning: conflicting types for built-in function 'hypotf' >>>>> _configtest.c:15: warning: conflicting types for built-in function 'log2f' >>>>> _configtest.c:16: warning: conflicting types for built-in function 'exp2f' >>>>> _configtest.c:17: warning: conflicting types for built-in function 'atanf' >>>>> _configtest.c:18: warning: conflicting types for built-in function 'fmodf' >>>>> _configtest.c:19: warning: conflicting types for built-in function 'atan2f' >>>>> _configtest.c:20: warning: conflicting types for built-in function 'modff' >>>>> _configtest.c:21: warning: conflicting types for built-in function 'ceilf' >>>>> _configtest.c:22: warning: conflicting types for built-in function 'log1pf' >>>>> _configtest.c:23: warning: conflicting types for built-in function 'asinf' >>>>> _configtest.c:24: warning: conflicting types for built-in function 'copysignf' >>>>> _configtest.c:25: warning: conflicting types for built-in function 'acoshf' >>>>> _configtest.c:26: warning: conflicting types for built-in function 'sinf' >>>>> _configtest.c:27: warning: conflicting types for built-in function 'tanf' >>>>> _configtest.c:28: warning: conflicting types for built-in function 'atanhf' >>>>> _configtest.c:29: warning: conflicting types for built-in function 'truncf' >>>>> _configtest.c:30: warning: conflicting types for built-in function 'asinhf' >>>>> _configtest.c:31: warning: conflicting types for built-in function 'frexpf' >>>>> _configtest.c:32: warning: conflicting types for built-in function 'powf' >>>>> _configtest.c:33: warning: conflicting types for built-in function 'expf' >>>>> _configtest.c:34: warning: conflicting types for built-in function 'expm1f' >>>>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>>>> success! >>>>> removing: _configtest.c _configtest.o _configtest >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:1: warning: conflicting types for built-in function 'tanhl' >>>>> _configtest.c:2: warning: conflicting types for built-in function 'log10l' >>>>> _configtest.c:3: warning: conflicting types for built-in function 'nextafterl' >>>>> _configtest.c:4: warning: conflicting types for built-in function 'coshl' >>>>> _configtest.c:5: warning: conflicting types for built-in function 'cosl' >>>>> _configtest.c:6: warning: conflicting types for built-in function 'floorl' >>>>> _configtest.c:7: warning: conflicting types for built-in function 'rintl' >>>>> _configtest.c:8: warning: conflicting types for built-in function 'fabsl' >>>>> _configtest.c:9: warning: conflicting types for built-in function 'acosl' >>>>> _configtest.c:10: warning: conflicting types for built-in function 'ldexpl' >>>>> _configtest.c:11: warning: conflicting types for built-in function 'sqrtl' >>>>> _configtest.c:12: warning: conflicting types for built-in function 'logl' >>>>> _configtest.c:13: warning: conflicting types for built-in function 'expm1l' >>>>> _configtest.c:14: warning: conflicting types for built-in function 'hypotl' >>>>> _configtest.c:15: warning: conflicting types for built-in function 'log2l' >>>>> _configtest.c:16: warning: conflicting types for built-in function 'copysignl' >>>>> _configtest.c:17: warning: conflicting types for built-in function 'exp2l' >>>>> _configtest.c:18: warning: conflicting types for built-in function 'atanl' >>>>> _configtest.c:19: warning: conflicting types for built-in function 'frexpl' >>>>> _configtest.c:20: warning: conflicting types for built-in function 'atan2l' >>>>> _configtest.c:21: warning: conflicting types for built-in function 'sinhl' >>>>> _configtest.c:22: warning: conflicting types for built-in function 'fmodl' >>>>> _configtest.c:23: warning: conflicting types for built-in function 'log1pl' >>>>> _configtest.c:24: warning: conflicting types for built-in function 'asinl' >>>>> _configtest.c:25: warning: conflicting types for built-in function 'ceill' >>>>> _configtest.c:26: warning: conflicting types for built-in function 'sinl' >>>>> _configtest.c:27: warning: conflicting types for built-in function 'acoshl' >>>>> _configtest.c:28: warning: conflicting types for built-in function 'atanhl' >>>>> _configtest.c:29: warning: conflicting types for built-in function 'tanl' >>>>> _configtest.c:30: warning: conflicting types for built-in function 'truncl' >>>>> _configtest.c:31: warning: conflicting types for built-in function 'powl' >>>>> _configtest.c:32: warning: conflicting types for built-in function 'expl' >>>>> _configtest.c:33: warning: conflicting types for built-in function 'modfl' >>>>> _configtest.c:34: warning: conflicting types for built-in function 'asinhl' >>>>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>>>> success! >>>>> removing: _configtest.c _configtest.o _configtest >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:6: warning: function declaration isn't a prototype >>>>> success! >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:6: warning: function declaration isn't a prototype >>>>> success! >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:6: warning: function declaration isn't a prototype >>>>> success! >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:6: warning: function declaration isn't a prototype >>>>> success! >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> success! >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:1: warning: conflicting types for built-in function 'cexp' >>>>> _configtest.c:3: warning: conflicting types for built-in function 'ccos' >>>>> _configtest.c:4: warning: conflicting types for built-in function 'cimag' >>>>> _configtest.c:5: warning: conflicting types for built-in function 'cabs' >>>>> _configtest.c:6: warning: conflicting types for built-in function 'cpow' >>>>> _configtest.c:7: warning: conflicting types for built-in function 'csqrt' >>>>> _configtest.c:8: warning: conflicting types for built-in function 'carg' >>>>> _configtest.c:9: warning: conflicting types for built-in function 'creal' >>>>> _configtest.c:10: warning: conflicting types for built-in function 'csin' >>>>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>>>> success! >>>>> removing: _configtest.c _configtest.o _configtest >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:1: warning: conflicting types for built-in function 'ccosf' >>>>> _configtest.c:2: warning: conflicting types for built-in function 'cargf' >>>>> _configtest.c:3: warning: conflicting types for built-in function 'csqrtf' >>>>> _configtest.c:4: warning: conflicting types for built-in function 'cpowf' >>>>> _configtest.c:5: warning: conflicting types for built-in function 'cexpf' >>>>> _configtest.c:6: warning: conflicting types for built-in function 'crealf' >>>>> _configtest.c:7: warning: conflicting types for built-in function 'csinf' >>>>> _configtest.c:8: warning: conflicting types for built-in function 'cabsf' >>>>> _configtest.c:10: warning: conflicting types for built-in function 'cimagf' >>>>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>>>> success! >>>>> removing: _configtest.c _configtest.o _configtest >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:1: warning: conflicting types for built-in function 'csqrtl' >>>>> _configtest.c:2: warning: conflicting types for built-in function 'cargl' >>>>> _configtest.c:3: warning: conflicting types for built-in function 'cexpl' >>>>> _configtest.c:4: warning: conflicting types for built-in function 'ccosl' >>>>> _configtest.c:5: warning: conflicting types for built-in function 'cpowl' >>>>> _configtest.c:6: warning: conflicting types for built-in function 'cimagl' >>>>> _configtest.c:7: warning: conflicting types for built-in function 'csinl' >>>>> _configtest.c:8: warning: conflicting types for built-in function 'creall' >>>>> _configtest.c:10: warning: conflicting types for built-in function 'cabsl' >>>>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>>>> success! >>>>> removing: _configtest.c _configtest.o _configtest >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> success! >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:5: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:7: error: `Py_UNICODE_WIDE' undeclared (first use in >>>>> this function) >>>>> _configtest.c:7: error: (Each undeclared identifier is reported only once >>>>> _configtest.c:7: error: for each function it appears in.) >>>>> _configtest.c:5: warning: function declaration isn't a prototype >>>>> _configtest.c: In function `main': >>>>> _configtest.c:7: error: `Py_UNICODE_WIDE' undeclared (first use in >>>>> this function) >>>>> _configtest.c:7: error: (Each undeclared identifier is reported only once >>>>> _configtest.c:7: error: for each function it appears in.) >>>>> failure. >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> removing: _configtest.c _configtest.o >>>>> ('File:', 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h') >>>>> #define HAVE_ENDIAN_H 1 >>>>> #define SIZEOF_PY_INTPTR_T 4 >>>>> #define SIZEOF_PY_LONG_LONG 8 >>>>> #define MATHLIB m >>>>> #define HAVE_SIN >>>>> #define HAVE_COS >>>>> #define HAVE_TAN >>>>> #define HAVE_SINH >>>>> #define HAVE_COSH >>>>> #define HAVE_TANH >>>>> #define HAVE_FABS >>>>> #define HAVE_FLOOR >>>>> #define HAVE_CEIL >>>>> #define HAVE_SQRT >>>>> #define HAVE_LOG10 >>>>> #define HAVE_LOG >>>>> #define HAVE_EXP >>>>> #define HAVE_ASIN >>>>> #define HAVE_ACOS >>>>> #define HAVE_ATAN >>>>> #define HAVE_FMOD >>>>> #define HAVE_MODF >>>>> #define HAVE_FREXP >>>>> #define HAVE_LDEXP >>>>> #define HAVE_EXPM1 >>>>> #define HAVE_LOG1P >>>>> #define HAVE_ACOSH >>>>> #define HAVE_ASINH >>>>> #define HAVE_ATANH >>>>> #define HAVE_RINT >>>>> #define HAVE_TRUNC >>>>> #define HAVE_EXP2 >>>>> #define HAVE_LOG2 >>>>> #define HAVE_HYPOT >>>>> #define HAVE_ATAN2 >>>>> #define HAVE_POW >>>>> #define HAVE_COPYSIGN >>>>> #define HAVE_NEXTAFTER >>>>> #define HAVE_SINF >>>>> #define HAVE_COSF >>>>> #define HAVE_TANF >>>>> #define HAVE_SINHF >>>>> #define HAVE_COSHF >>>>> #define HAVE_TANHF >>>>> #define HAVE_FABSF >>>>> #define HAVE_FLOORF >>>>> #define HAVE_CEILF >>>>> #define HAVE_RINTF >>>>> #define HAVE_TRUNCF >>>>> #define HAVE_SQRTF >>>>> #define HAVE_LOG10F >>>>> #define HAVE_LOGF >>>>> #define HAVE_LOG1PF >>>>> #define HAVE_EXPF >>>>> #define HAVE_EXPM1F >>>>> #define HAVE_ASINF >>>>> #define HAVE_ACOSF >>>>> #define HAVE_ATANF >>>>> #define HAVE_ASINHF >>>>> #define HAVE_ACOSHF >>>>> #define HAVE_ATANHF >>>>> #define HAVE_HYPOTF >>>>> #define HAVE_ATAN2F >>>>> #define HAVE_POWF >>>>> #define HAVE_FMODF >>>>> #define HAVE_MODFF >>>>> #define HAVE_FREXPF >>>>> #define HAVE_LDEXPF >>>>> #define HAVE_EXP2F >>>>> #define HAVE_LOG2F >>>>> #define HAVE_COPYSIGNF >>>>> #define HAVE_NEXTAFTERF >>>>> #define HAVE_SINL >>>>> #define HAVE_COSL >>>>> #define HAVE_TANL >>>>> #define HAVE_SINHL >>>>> #define HAVE_COSHL >>>>> #define HAVE_TANHL >>>>> #define HAVE_FABSL >>>>> #define HAVE_FLOORL >>>>> #define HAVE_CEILL >>>>> #define HAVE_RINTL >>>>> #define HAVE_TRUNCL >>>>> #define HAVE_SQRTL >>>>> #define HAVE_LOG10L >>>>> #define HAVE_LOGL >>>>> #define HAVE_LOG1PL >>>>> #define HAVE_EXPL >>>>> #define HAVE_EXPM1L >>>>> #define HAVE_ASINL >>>>> #define HAVE_ACOSL >>>>> #define HAVE_ATANL >>>>> #define HAVE_ASINHL >>>>> #define HAVE_ACOSHL >>>>> #define HAVE_ATANHL >>>>> #define HAVE_HYPOTL >>>>> #define HAVE_ATAN2L >>>>> #define HAVE_POWL >>>>> #define HAVE_FMODL >>>>> #define HAVE_MODFL >>>>> #define HAVE_FREXPL >>>>> #define HAVE_LDEXPL >>>>> #define HAVE_EXP2L >>>>> #define HAVE_LOG2L >>>>> #define HAVE_COPYSIGNL >>>>> #define HAVE_NEXTAFTERL >>>>> #define HAVE_DECL_ISNAN >>>>> #define HAVE_DECL_ISINF >>>>> #define HAVE_DECL_SIGNBIT >>>>> #define HAVE_DECL_ISFINITE >>>>> #define HAVE_COMPLEX_H >>>>> #define HAVE_CREAL >>>>> #define HAVE_CIMAG >>>>> #define HAVE_CABS >>>>> #define HAVE_CARG >>>>> #define HAVE_CEXP >>>>> #define HAVE_CSQRT >>>>> #define HAVE_CLOG >>>>> #define HAVE_CCOS >>>>> #define HAVE_CSIN >>>>> #define HAVE_CPOW >>>>> #define HAVE_CREALF >>>>> #define HAVE_CIMAGF >>>>> #define HAVE_CABSF >>>>> #define HAVE_CARGF >>>>> #define HAVE_CEXPF >>>>> #define HAVE_CSQRTF >>>>> #define HAVE_CLOGF >>>>> #define HAVE_CCOSF >>>>> #define HAVE_CSINF >>>>> #define HAVE_CPOWF >>>>> #define HAVE_CREALL >>>>> #define HAVE_CIMAGL >>>>> #define HAVE_CABSL >>>>> #define HAVE_CARGL >>>>> #define HAVE_CEXPL >>>>> #define HAVE_CSQRTL >>>>> #define HAVE_CLOGL >>>>> #define HAVE_CCOSL >>>>> #define HAVE_CSINL >>>>> #define HAVE_CPOWL >>>>> #define HAVE_LDOUBLE_INTEL_EXTENDED_12_BYTES_LE 1 >>>>> #ifndef __cplusplus >>>>> /* #undef inline */ >>>>> #endif >>>>> >>>>> #ifndef _NPY_NPY_CONFIG_H_ >>>>> #error config.h should never be included directly, include npy_config.h instead >>>>> #endif >>>>> >>>>> EOF >>>>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' >>>>> to sources. >>>>> Generating build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:1: warning: conflicting types for built-in function 'exp' >>>>> gcc -m32 -pthread _configtest.o -o _configtest >>>>> _configtest.o(.text+0x19): In function `main': >>>>> /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' >>>>> collect2: ld returned 1 exit status >>>>> _configtest.o(.text+0x19): In function `main': >>>>> /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' >>>>> collect2: ld returned 1 exit status >>>>> failure. >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:1: warning: conflicting types for built-in function 'exp' >>>>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>>>> success! >>>>> removing: _configtest.c _configtest.o _configtest >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:5: warning: function declaration isn't a prototype >>>>> success! >>>>> removing: _configtest.c _configtest.o >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>> _configtest.c:5:18: warning: extra tokens at end of #ifndef directive >>>>> _configtest.c: In function `main': >>>>> _configtest.c:4: warning: control reaches end of non-void function >>>>> success! >>>>> removing: _configtest.c _configtest.o >>>>> File: build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h >>>>> #define NPY_HAVE_ENDIAN_H 1 >>>>> #define NPY_SIZEOF_SHORT SIZEOF_SHORT >>>>> #define NPY_SIZEOF_INT SIZEOF_INT >>>>> #define NPY_SIZEOF_LONG SIZEOF_LONG >>>>> #define NPY_SIZEOF_FLOAT 4 >>>>> #define NPY_SIZEOF_COMPLEX_FLOAT 8 >>>>> #define NPY_SIZEOF_DOUBLE 8 >>>>> #define NPY_SIZEOF_COMPLEX_DOUBLE 16 >>>>> #define NPY_SIZEOF_LONGDOUBLE 12 >>>>> #define NPY_SIZEOF_COMPLEX_LONGDOUBLE 24 >>>>> #define NPY_SIZEOF_PY_INTPTR_T 4 >>>>> #define NPY_SIZEOF_PY_LONG_LONG 8 >>>>> #define NPY_SIZEOF_LONGLONG 8 >>>>> #define NPY_NO_SMP 1 >>>>> #define NPY_HAVE_DECL_ISNAN >>>>> #define NPY_HAVE_DECL_ISINF >>>>> #define NPY_HAVE_DECL_SIGNBIT >>>>> #define NPY_HAVE_DECL_ISFINITE >>>>> #define NPY_USE_C99_COMPLEX >>>>> #define NPY_HAVE_COMPLEX_DOUBLE 1 >>>>> #define NPY_HAVE_COMPLEX_FLOAT 1 >>>>> #define NPY_HAVE_COMPLEX_LONG_DOUBLE 1 >>>>> #define NPY_USE_C99_FORMATS 1 >>>>> #define NPY_VISIBILITY_HIDDEN __attribute__((visibility("hidden"))) >>>>> #define NPY_ABI_VERSION 0x01000009 >>>>> #define NPY_API_VERSION 0x00000004 >>>>> >>>>> #ifndef __STDC_FORMAT_MACROS >>>>> #define __STDC_FORMAT_MACROS 1 >>>>> #endif >>>>> >>>>> EOF >>>>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' >>>>> to sources. >>>>> executing numpy/core/code_generators/generate_numpy_api.py >>>>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__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/include/numpy/config.h', >>>>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', >>>>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h'] >>>>> building extension "numpy.core.multiarray" sources >>>>> non-existing path in 'numpy/core': >>>>> 'build/src.linux-x86_64-2.4/numpy/core/src/multiarray' >>>>> creating build/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>>> conv_template:> >>>>> build/src.linux-x86_64-2.4/numpy/core/src/multiarray/scalartypes.c >>>>> conv_template:> >>>>> build/src.linux-x86_64-2.4/numpy/core/src/multiarray/arraytypes.c >>>>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' >>>>> to sources. >>>>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' >>>>> to sources. >>>>> executing numpy/core/code_generators/generate_numpy_api.py >>>>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h' >>>>> to sources. >>>>> numpy.core - nothing done with h_files = >>>>> ['build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h', >>>>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', >>>>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h'] >>>>> building extension "numpy.core.umath" sources >>>>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' >>>>> to sources. >>>>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' >>>>> to sources. >>>>> executing numpy/core/code_generators/generate_ufunc_api.py >>>>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__ufunc_api.h' >>>>> to sources. >>>>> non-existing path in 'numpy/core': >>>>> 'build/src.linux-x86_64-2.4/numpy/core/src/umath' >>>>> creating build/src.linux-x86_64-2.4/numpy/core/src/umath >>>>> conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/umath/loops.c >>>>> conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/umath/umathmodule.c >>>>> conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/umath/funcs.inc >>>>> adding 'build/src.linux-x86_64-2.4/numpy/core/src/umath' to include_dirs. >>>>> numpy.core - nothing done with h_files = >>>>> ['build/src.linux-x86_64-2.4/numpy/core/src/umath/funcs.inc', >>>>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h', >>>>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', >>>>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__ufunc_api.h'] >>>>> building extension "numpy.core.scalarmath" sources >>>>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' >>>>> to sources. >>>>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' >>>>> to sources. >>>>> executing numpy/core/code_generators/generate_numpy_api.py >>>>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h' >>>>> to sources. >>>>> executing numpy/core/code_generators/generate_ufunc_api.py >>>>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__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/include/numpy/config.h', >>>>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', >>>>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h', >>>>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__ufunc_api.h'] >>>>> building extension "numpy.core._dotblas" sources >>>>> building extension "numpy.core.umath_tests" sources >>>>> conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/umath/umath_tests.c >>>>> building extension "numpy.core.multiarray_tests" sources >>>>> conv_template:> >>>>> build/src.linux-x86_64-2.4/numpy/core/src/multiarray/multiarray_tests.c >>>>> building extension "numpy.lib._compiled_base" sources >>>>> building extension "numpy.numarray._capi" sources >>>>> building extension "numpy.fft.fftpack_lite" sources >>>>> building extension "numpy.linalg.lapack_lite" sources >>>>> creating build/src.linux-x86_64-2.4/numpy/linalg >>>>> adding 'numpy/linalg/lapack_litemodule.c' to sources. >>>>> adding 'numpy/linalg/python_xerbla.c' to sources. >>>>> building extension "numpy.random.mtrand" sources >>>>> creating build/src.linux-x86_64-2.4/numpy/random >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 -c' >>>>> gcc: _configtest.c >>>>> gcc -m32 -pthread _configtest.o -o _configtest >>>>> _configtest >>>>> failure. >>>>> removing: _configtest.c _configtest.o _configtest >>>>> building data_files sources >>>>> build_src: building npy-pkg config files >>>>> running build_py >>>>> creating build/lib.linux-x86_64-2.4 >>>>> creating build/lib.linux-x86_64-2.4/numpy >>>>> copying numpy/version.py -> build/lib.linux-x86_64-2.4/numpy >>>>> copying numpy/matlib.py -> build/lib.linux-x86_64-2.4/numpy >>>>> copying numpy/ctypeslib.py -> build/lib.linux-x86_64-2.4/numpy >>>>> copying numpy/setupscons.py -> build/lib.linux-x86_64-2.4/numpy >>>>> copying numpy/__init__.py -> build/lib.linux-x86_64-2.4/numpy >>>>> copying numpy/setup.py -> build/lib.linux-x86_64-2.4/numpy >>>>> copying numpy/dual.py -> build/lib.linux-x86_64-2.4/numpy >>>>> copying numpy/_import_tools.py -> build/lib.linux-x86_64-2.4/numpy >>>>> copying numpy/add_newdocs.py -> build/lib.linux-x86_64-2.4/numpy >>>>> copying build/src.linux-x86_64-2.4/numpy/__config__.py -> >>>>> build/lib.linux-x86_64-2.4/numpy >>>>> creating build/lib.linux-x86_64-2.4/numpy/distutils >>>>> copying numpy/distutils/from_template.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>> copying numpy/distutils/npy_pkg_config.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>> copying numpy/distutils/compat.py -> build/lib.linux-x86_64-2.4/numpy/distutils >>>>> copying numpy/distutils/setupscons.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>> copying numpy/distutils/__init__.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>> copying numpy/distutils/lib2def.py -> build/lib.linux-x86_64-2.4/numpy/distutils >>>>> copying numpy/distutils/interactive.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>> copying numpy/distutils/info.py -> build/lib.linux-x86_64-2.4/numpy/distutils >>>>> copying numpy/distutils/environment.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>> copying numpy/distutils/setup.py -> build/lib.linux-x86_64-2.4/numpy/distutils >>>>> copying numpy/distutils/cpuinfo.py -> build/lib.linux-x86_64-2.4/numpy/distutils >>>>> copying numpy/distutils/extension.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>> copying numpy/distutils/core.py -> build/lib.linux-x86_64-2.4/numpy/distutils >>>>> copying numpy/distutils/intelccompiler.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>> copying numpy/distutils/log.py -> build/lib.linux-x86_64-2.4/numpy/distutils >>>>> copying numpy/distutils/__version__.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>> copying numpy/distutils/unixccompiler.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>> copying numpy/distutils/misc_util.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>> copying numpy/distutils/line_endings.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>> copying numpy/distutils/exec_command.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>> copying numpy/distutils/conv_template.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>> copying numpy/distutils/ccompiler.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>> copying numpy/distutils/mingw32ccompiler.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>> copying numpy/distutils/system_info.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>> copying numpy/distutils/numpy_distribution.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>> copying build/src.linux-x86_64-2.4/numpy/distutils/__config__.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>> creating build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>> copying numpy/distutils/command/install.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>> copying numpy/distutils/command/egg_info.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>> copying numpy/distutils/command/install_clib.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>> copying numpy/distutils/command/bdist_rpm.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>> copying numpy/distutils/command/develop.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>> copying numpy/distutils/command/install_data.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>> copying numpy/distutils/command/__init__.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>> copying numpy/distutils/command/build_py.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>> copying numpy/distutils/command/build_src.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>> copying numpy/distutils/command/build_clib.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>> copying numpy/distutils/command/build_ext.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>> copying numpy/distutils/command/autodist.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>> copying numpy/distutils/command/install_headers.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>> copying numpy/distutils/command/config.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>> copying numpy/distutils/command/config_compiler.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>> copying numpy/distutils/command/build.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>> copying numpy/distutils/command/build_scripts.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>> copying numpy/distutils/command/sdist.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>> copying numpy/distutils/command/scons.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>> creating build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>>> copying numpy/distutils/fcompiler/none.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>>> copying numpy/distutils/fcompiler/hpux.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>>> copying numpy/distutils/fcompiler/compaq.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>>> copying numpy/distutils/fcompiler/absoft.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>>> copying numpy/distutils/fcompiler/vast.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>>> copying numpy/distutils/fcompiler/nag.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>>> copying numpy/distutils/fcompiler/__init__.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>>> copying numpy/distutils/fcompiler/sun.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>>> copying numpy/distutils/fcompiler/mips.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>>> copying numpy/distutils/fcompiler/intel.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>>> copying numpy/distutils/fcompiler/gnu.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>>> copying numpy/distutils/fcompiler/g95.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>>> copying numpy/distutils/fcompiler/pg.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>>> copying numpy/distutils/fcompiler/ibm.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>>> copying numpy/distutils/fcompiler/lahey.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>>> creating build/lib.linux-x86_64-2.4/numpy/testing >>>>> copying numpy/testing/nulltester.py -> build/lib.linux-x86_64-2.4/numpy/testing >>>>> copying numpy/testing/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/testing >>>>> copying numpy/testing/__init__.py -> build/lib.linux-x86_64-2.4/numpy/testing >>>>> copying numpy/testing/setup.py -> build/lib.linux-x86_64-2.4/numpy/testing >>>>> copying numpy/testing/decorators.py -> build/lib.linux-x86_64-2.4/numpy/testing >>>>> copying numpy/testing/utils.py -> build/lib.linux-x86_64-2.4/numpy/testing >>>>> copying numpy/testing/noseclasses.py -> build/lib.linux-x86_64-2.4/numpy/testing >>>>> copying numpy/testing/numpytest.py -> build/lib.linux-x86_64-2.4/numpy/testing >>>>> copying numpy/testing/nosetester.py -> build/lib.linux-x86_64-2.4/numpy/testing >>>>> creating build/lib.linux-x86_64-2.4/numpy/f2py >>>>> copying numpy/f2py/auxfuncs.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>> copying numpy/f2py/common_rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>> copying numpy/f2py/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>> copying numpy/f2py/__init__.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>> copying numpy/f2py/cb_rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>> copying numpy/f2py/info.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>> copying numpy/f2py/setup.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>> copying numpy/f2py/f2py2e.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>> copying numpy/f2py/cfuncs.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>> copying numpy/f2py/crackfortran.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>> copying numpy/f2py/use_rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>> copying numpy/f2py/diagnose.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>> copying numpy/f2py/f2py_testing.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>> copying numpy/f2py/__version__.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>> copying numpy/f2py/capi_maps.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>> copying numpy/f2py/func2subr.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>> copying numpy/f2py/f90mod_rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>> copying numpy/f2py/rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>> creating build/lib.linux-x86_64-2.4/numpy/core >>>>> copying numpy/core/defchararray.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>> copying numpy/core/numeric.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>> copying numpy/core/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>> copying numpy/core/__init__.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>> copying numpy/core/info.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>> copying numpy/core/function_base.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>> copying numpy/core/getlimits.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>> copying numpy/core/setup.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>> copying numpy/core/fromnumeric.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>> copying numpy/core/shape_base.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>> copying numpy/core/setup_common.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>> copying numpy/core/records.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>> copying numpy/core/memmap.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>> copying numpy/core/arrayprint.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>> copying numpy/core/numerictypes.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>> copying numpy/core/machar.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>> copying numpy/core/_mx_datetime_parser.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/core >>>>> copying numpy/core/scons_support.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>> copying numpy/core/_internal.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>> copying numpy/core/code_generators/generate_numpy_api.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/core >>>>> creating build/lib.linux-x86_64-2.4/numpy/lib >>>>> copying numpy/lib/_datasource.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>> copying numpy/lib/arraysetops.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>> copying numpy/lib/index_tricks.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>> copying numpy/lib/format.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>> copying numpy/lib/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>> copying numpy/lib/__init__.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>> copying numpy/lib/info.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>> copying numpy/lib/function_base.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>> copying numpy/lib/setup.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>> copying numpy/lib/arrayterator.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>> copying numpy/lib/ufunclike.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>> copying numpy/lib/shape_base.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>> copying numpy/lib/user_array.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>> copying numpy/lib/type_check.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>> copying numpy/lib/stride_tricks.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>> copying numpy/lib/recfunctions.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>> copying numpy/lib/npyio.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>> copying numpy/lib/_iotools.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>> copying numpy/lib/utils.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>> copying numpy/lib/financial.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>> copying numpy/lib/twodim_base.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>> copying numpy/lib/polynomial.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>> copying numpy/lib/scimath.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>> creating build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>> copying numpy/oldnumeric/functions.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>> copying numpy/oldnumeric/alter_code1.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>> copying numpy/oldnumeric/misc.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>> copying numpy/oldnumeric/compat.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>> copying numpy/oldnumeric/setupscons.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>> copying numpy/oldnumeric/__init__.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>> copying numpy/oldnumeric/linear_algebra.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>> copying numpy/oldnumeric/setup.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>> copying numpy/oldnumeric/random_array.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>> copying numpy/oldnumeric/user_array.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>> copying numpy/oldnumeric/alter_code2.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>> copying numpy/oldnumeric/fft.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>> copying numpy/oldnumeric/matrix.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>> copying numpy/oldnumeric/fix_default_axis.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>> copying numpy/oldnumeric/rng_stats.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>> copying numpy/oldnumeric/mlab.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>> copying numpy/oldnumeric/ma.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>> copying numpy/oldnumeric/ufuncs.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>> copying numpy/oldnumeric/rng.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>> copying numpy/oldnumeric/array_printer.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>> copying numpy/oldnumeric/typeconv.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>> copying numpy/oldnumeric/precision.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>> copying numpy/oldnumeric/arrayfns.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>> creating build/lib.linux-x86_64-2.4/numpy/numarray >>>>> copying numpy/numarray/nd_image.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>>>> copying numpy/numarray/util.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>>>> copying numpy/numarray/convolve.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>>>> copying numpy/numarray/functions.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>>>> copying numpy/numarray/alter_code1.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/numarray >>>>> copying numpy/numarray/compat.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>>>> copying numpy/numarray/setupscons.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/numarray >>>>> copying numpy/numarray/__init__.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>>>> copying numpy/numarray/linear_algebra.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/numarray >>>>> copying numpy/numarray/setup.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>>>> copying numpy/numarray/random_array.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/numarray >>>>> copying numpy/numarray/alter_code2.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/numarray >>>>> copying numpy/numarray/fft.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>>>> copying numpy/numarray/matrix.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>>>> copying numpy/numarray/numerictypes.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/numarray >>>>> copying numpy/numarray/image.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>>>> copying numpy/numarray/mlab.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>>>> copying numpy/numarray/ma.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>>>> copying numpy/numarray/session.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>>>> copying numpy/numarray/ufuncs.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>>>> creating build/lib.linux-x86_64-2.4/numpy/fft >>>>> copying numpy/fft/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/fft >>>>> copying numpy/fft/__init__.py -> build/lib.linux-x86_64-2.4/numpy/fft >>>>> copying numpy/fft/info.py -> build/lib.linux-x86_64-2.4/numpy/fft >>>>> copying numpy/fft/setup.py -> build/lib.linux-x86_64-2.4/numpy/fft >>>>> copying numpy/fft/fftpack.py -> build/lib.linux-x86_64-2.4/numpy/fft >>>>> copying numpy/fft/helper.py -> build/lib.linux-x86_64-2.4/numpy/fft >>>>> creating build/lib.linux-x86_64-2.4/numpy/linalg >>>>> copying numpy/linalg/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/linalg >>>>> copying numpy/linalg/__init__.py -> build/lib.linux-x86_64-2.4/numpy/linalg >>>>> copying numpy/linalg/info.py -> build/lib.linux-x86_64-2.4/numpy/linalg >>>>> copying numpy/linalg/setup.py -> build/lib.linux-x86_64-2.4/numpy/linalg >>>>> copying numpy/linalg/linalg.py -> build/lib.linux-x86_64-2.4/numpy/linalg >>>>> creating build/lib.linux-x86_64-2.4/numpy/random >>>>> copying numpy/random/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/random >>>>> copying numpy/random/__init__.py -> build/lib.linux-x86_64-2.4/numpy/random >>>>> copying numpy/random/info.py -> build/lib.linux-x86_64-2.4/numpy/random >>>>> copying numpy/random/setup.py -> build/lib.linux-x86_64-2.4/numpy/random >>>>> creating build/lib.linux-x86_64-2.4/numpy/ma >>>>> copying numpy/ma/version.py -> build/lib.linux-x86_64-2.4/numpy/ma >>>>> copying numpy/ma/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/ma >>>>> copying numpy/ma/__init__.py -> build/lib.linux-x86_64-2.4/numpy/ma >>>>> copying numpy/ma/setup.py -> build/lib.linux-x86_64-2.4/numpy/ma >>>>> copying numpy/ma/bench.py -> build/lib.linux-x86_64-2.4/numpy/ma >>>>> copying numpy/ma/core.py -> build/lib.linux-x86_64-2.4/numpy/ma >>>>> copying numpy/ma/testutils.py -> build/lib.linux-x86_64-2.4/numpy/ma >>>>> copying numpy/ma/timer_comparison.py -> build/lib.linux-x86_64-2.4/numpy/ma >>>>> copying numpy/ma/extras.py -> build/lib.linux-x86_64-2.4/numpy/ma >>>>> copying numpy/ma/mrecords.py -> build/lib.linux-x86_64-2.4/numpy/ma >>>>> creating build/lib.linux-x86_64-2.4/numpy/matrixlib >>>>> copying numpy/matrixlib/setupscons.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/matrixlib >>>>> copying numpy/matrixlib/__init__.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/matrixlib >>>>> copying numpy/matrixlib/setup.py -> build/lib.linux-x86_64-2.4/numpy/matrixlib >>>>> copying numpy/matrixlib/defmatrix.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/matrixlib >>>>> creating build/lib.linux-x86_64-2.4/numpy/compat >>>>> copying numpy/compat/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/compat >>>>> copying numpy/compat/__init__.py -> build/lib.linux-x86_64-2.4/numpy/compat >>>>> copying numpy/compat/setup.py -> build/lib.linux-x86_64-2.4/numpy/compat >>>>> copying numpy/compat/py3k.py -> build/lib.linux-x86_64-2.4/numpy/compat >>>>> copying numpy/compat/_inspect.py -> build/lib.linux-x86_64-2.4/numpy/compat >>>>> creating build/lib.linux-x86_64-2.4/numpy/polynomial >>>>> copying numpy/polynomial/__init__.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/polynomial >>>>> copying numpy/polynomial/setup.py -> build/lib.linux-x86_64-2.4/numpy/polynomial >>>>> copying numpy/polynomial/chebyshev.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/polynomial >>>>> copying numpy/polynomial/polynomial.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/polynomial >>>>> copying numpy/polynomial/polyutils.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/polynomial >>>>> copying numpy/polynomial/polytemplate.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/polynomial >>>>> creating build/lib.linux-x86_64-2.4/numpy/doc >>>>> copying numpy/doc/byteswapping.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>> copying numpy/doc/glossary.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>> copying numpy/doc/indexing.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>> copying numpy/doc/misc.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>> copying numpy/doc/internals.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>> copying numpy/doc/__init__.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>> copying numpy/doc/creation.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>> copying numpy/doc/jargon.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>> copying numpy/doc/basics.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>> copying numpy/doc/io.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>> copying numpy/doc/methods_vs_functions.py -> >>>>> build/lib.linux-x86_64-2.4/numpy/doc >>>>> copying numpy/doc/broadcasting.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>> copying numpy/doc/constants.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>> copying numpy/doc/howtofind.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>> copying numpy/doc/ufuncs.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>> copying numpy/doc/subclassing.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>> copying numpy/doc/structured_arrays.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>> copying numpy/doc/performance.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>> running build_clib >>>>> customize UnixCCompiler >>>>> customize UnixCCompiler using build_clib >>>>> building 'npymath' library >>>>> compiling C sources >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> creating build/temp.linux-x86_64-2.4 >>>>> creating build/temp.linux-x86_64-2.4/build >>>>> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4 >>>>> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy >>>>> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core >>>>> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src >>>>> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/npymath >>>>> compile options: '-Inumpy/core/include >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>>> gcc: build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math.c >>>>> In file included from numpy/core/src/private/npy_config.h:4, >>>>> from numpy/core/src/npymath/npy_math_private.h:24, >>>>> from numpy/core/src/npymath/npy_math.c.src:56: >>>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >>>>> warning: "HAVE_HYPOT" redefined >>>>> In file included from /home/sanjey/include/python2.4/Python.h:8, >>>>> from numpy/core/src/npymath/npy_math_private.h:21, >>>>> from numpy/core/src/npymath/npy_math.c.src:56: >>>>> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >>>>> location of the previous definition >>>>> gcc: build/src.linux-x86_64-2.4/numpy/core/src/npymath/ieee754.c >>>>> In file included from numpy/core/src/private/npy_config.h:4, >>>>> from numpy/core/src/npymath/npy_math_common.h:8, >>>>> from numpy/core/src/npymath/ieee754.c.src:7: >>>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >>>>> warning: "HAVE_HYPOT" redefined >>>>> In file included from /home/sanjey/include/python2.4/Python.h:8, >>>>> from numpy/core/src/npymath/npy_math_common.h:4, >>>>> from numpy/core/src/npymath/ieee754.c.src:7: >>>>> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >>>>> location of the previous definition >>>>> gcc: build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math_complex.c >>>>> In file included from numpy/core/src/private/npy_config.h:4, >>>>> from numpy/core/src/npymath/npy_math_common.h:8, >>>>> from numpy/core/src/npymath/npy_math_complex.c.src:31: >>>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >>>>> warning: "HAVE_HYPOT" redefined >>>>> In file included from /home/sanjey/include/python2.4/Python.h:8, >>>>> from numpy/core/src/npymath/npy_math_common.h:4, >>>>> from numpy/core/src/npymath/npy_math_complex.c.src:31: >>>>> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >>>>> location of the previous definition >>>>> ar: adding 3 object files to build/temp.linux-x86_64-2.4/libnpymath.a >>>>> running build_ext >>>>> customize UnixCCompiler >>>>> customize UnixCCompiler using build_ext >>>>> customize GnuFCompiler >>>>> gnu: no Fortran 90 compiler found >>>>> gnu: no Fortran 90 compiler found >>>>> customize GnuFCompiler >>>>> gnu: no Fortran 90 compiler found >>>>> gnu: no Fortran 90 compiler found >>>>> customize GnuFCompiler using build_ext >>>>> building 'numpy.core._sort' extension >>>>> compiling C sources >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/include >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>>> gcc: build/src.linux-x86_64-2.4/numpy/core/src/_sortmodule.c >>>>> In file included from numpy/core/src/private/npy_config.h:4, >>>>> from numpy/core/src/_sortmodule.c.src:34: >>>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >>>>> warning: "HAVE_HYPOT" redefined >>>>> In file included from /home/sanjey/include/python2.4/Python.h:8, >>>>> from numpy/core/src/_sortmodule.c.src:30: >>>>> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >>>>> location of the previous definition >>>>> gcc -m32 -pthread -shared >>>>> build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/_sortmodule.o >>>>> -Lbuild/temp.linux-x86_64-2.4 -lm -o >>>>> build/lib.linux-x86_64-2.4/numpy/core/_sort.so >>>>> building 'numpy.core.multiarray' extension >>>>> compiling C sources >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> creating build/temp.linux-x86_64-2.4/numpy >>>>> creating build/temp.linux-x86_64-2.4/numpy/core >>>>> creating build/temp.linux-x86_64-2.4/numpy/core/src >>>>> creating build/temp.linux-x86_64-2.4/numpy/core/src/multiarray >>>>> compile options: '-Inumpy/core/include >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>>> gcc: numpy/core/src/multiarray/multiarraymodule_onefile.c >>>>> In file included from numpy/core/src/private/npy_config.h:4, >>>>> from numpy/core/src/multiarray/common.c:8, >>>>> from numpy/core/src/multiarray/multiarraymodule_onefile.c:8: >>>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >>>>> warning: "HAVE_HYPOT" redefined >>>>> In file included from /home/sanjey/include/python2.4/Python.h:8, >>>>> from numpy/core/src/multiarray/common.c:2, >>>>> from numpy/core/src/multiarray/multiarraymodule_onefile.c:8: >>>>> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >>>>> location of the previous definition >>>>> In file included from numpy/core/src/multiarray/multiarraymodule_onefile.c:26: >>>>> numpy/core/src/multiarray/methods.c: In function `NpyArg_ParseKeywords': >>>>> numpy/core/src/multiarray/methods.c:41: warning: passing arg 3 of >>>>> `PyArg_VaParseTupleAndKeywords' discards qualifiers from pointer >>>>> target type >>>>> numpy/core/src/multiarray/flagsobject.c: In function `arrayflags_richcompare': >>>>> numpy/core/src/multiarray/flagsobject.c:568: warning: 'cmp' might be >>>>> used uninitialized in this function >>>>> numpy/core/src/multiarray/multiarraymodule_onefile.c: At top level: >>>>> numpy/core/include/numpy/npy_3kcompat.h:331: warning: >>>>> 'simple_capsule_dtor' defined but not used >>>>> numpy/core/src/multiarray/buffer.c:777: warning: >>>>> '_descriptor_from_pep3118_format' defined but not used >>>>> numpy/core/src/multiarray/arraytypes.c.src:93: warning: >>>>> '_SEQUENCE_MESSAGE' defined but not used >>>>> numpy/core/src/multiarray/mapping.c:75: warning: '_array_ass_item' >>>>> defined but not used >>>>> gcc -m32 -pthread -shared >>>>> build/temp.linux-x86_64-2.4/numpy/core/src/multiarray/multiarraymodule_onefile.o >>>>> -Lbuild/temp.linux-x86_64-2.4 -lnpymath -lm -o >>>>> build/lib.linux-x86_64-2.4/numpy/core/multiarray.so >>>>> building 'numpy.core.umath' extension >>>>> compiling C sources >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> creating build/temp.linux-x86_64-2.4/numpy/core/src/umath >>>>> compile options: '-Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath >>>>> -Inumpy/core/include >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>>> gcc: numpy/core/src/umath/umathmodule_onefile.c >>>>> In file included from numpy/core/src/private/npy_config.h:4, >>>>> from numpy/core/src/umath/loops.c.src:7, >>>>> from numpy/core/src/umath/umathmodule_onefile.c:1: >>>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >>>>> warning: "HAVE_HYPOT" redefined >>>>> In file included from /home/sanjey/include/python2.4/Python.h:8, >>>>> from numpy/core/src/umath/loops.c.src:5, >>>>> from numpy/core/src/umath/umathmodule_onefile.c:1: >>>>> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >>>>> location of the previous definition >>>>> numpy/core/include/numpy/npy_3kcompat.h:331: warning: >>>>> 'simple_capsule_dtor' defined but not used >>>>> numpy/core/src/umath/loops.c.src:1258: warning: >>>>> 'CLONGDOUBLE_logical_and' defined but not used >>>>> numpy/core/src/umath/loops.c.src:1258: warning: >>>>> 'CLONGDOUBLE_logical_or' defined but not used >>>>> numpy/core/src/umath/loops.c.src:1271: warning: >>>>> 'CLONGDOUBLE_logical_xor' defined but not used >>>>> numpy/core/src/umath/loops.c.src:1285: warning: >>>>> 'CLONGDOUBLE_logical_not' defined but not used >>>>> numpy/core/src/umath/loops.c.src:1342: warning: >>>>> 'CLONGDOUBLE_ones_like' defined but not used >>>>> numpy/core/src/umath/loops.c.src:1399: warning: 'CLONGDOUBLE_maximum' >>>>> defined but not used >>>>> numpy/core/src/umath/loops.c.src:1399: warning: 'CLONGDOUBLE_minimum' >>>>> defined but not used >>>>> numpy/core/src/umath/loops.c.src:1423: warning: 'CLONGDOUBLE_fmax' >>>>> defined but not used >>>>> numpy/core/src/umath/loops.c.src:1423: warning: 'CLONGDOUBLE_fmin' >>>>> defined but not used >>>>> gcc -m32 -pthread -shared >>>>> build/temp.linux-x86_64-2.4/numpy/core/src/umath/umathmodule_onefile.o >>>>> -Lbuild/temp.linux-x86_64-2.4 -lnpymath -lm -o >>>>> build/lib.linux-x86_64-2.4/numpy/core/umath.so >>>>> building 'numpy.core.scalarmath' extension >>>>> compiling C sources >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> compile options: '-Inumpy/core/include >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>>> gcc: build/src.linux-x86_64-2.4/numpy/core/src/scalarmathmodule.c >>>>> numpy/core/include/numpy/npy_3kcompat.h:331: warning: >>>>> 'simple_capsule_dtor' defined but not used >>>>> gcc -m32 -pthread -shared >>>>> build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/scalarmathmodule.o >>>>> -Lbuild/temp.linux-x86_64-2.4 -lm -o >>>>> build/lib.linux-x86_64-2.4/numpy/core/scalarmath.so >>>>> building 'numpy.core.umath_tests' extension >>>>> compiling C sources >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/umath >>>>> compile options: '-Inumpy/core/include >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>>> gcc: build/src.linux-x86_64-2.4/numpy/core/src/umath/umath_tests.c >>>>> In file included from numpy/core/src/private/npy_config.h:4, >>>>> from numpy/core/src/umath/umath_tests.c.src:14: >>>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >>>>> warning: "HAVE_HYPOT" redefined >>>>> In file included from /home/sanjey/include/python2.4/Python.h:8, >>>>> from numpy/core/src/umath/umath_tests.c.src:8: >>>>> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >>>>> location of the previous definition >>>>> numpy/core/include/numpy/npy_3kcompat.h:331: warning: >>>>> 'simple_capsule_dtor' defined but not used >>>>> gcc -m32 -pthread -shared >>>>> build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/umath/umath_tests.o >>>>> -Lbuild/temp.linux-x86_64-2.4 -o >>>>> build/lib.linux-x86_64-2.4/numpy/core/umath_tests.so >>>>> building 'numpy.core.multiarray_tests' extension >>>>> compiling C sources >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>>> compile options: '-Inumpy/core/include >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>>> gcc: build/src.linux-x86_64-2.4/numpy/core/src/multiarray/multiarray_tests.c >>>>> numpy/core/include/numpy/npy_3kcompat.h:331: warning: >>>>> 'simple_capsule_dtor' defined but not used >>>>> gcc -m32 -pthread -shared >>>>> build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/multiarray/multiarray_tests.o >>>>> -Lbuild/temp.linux-x86_64-2.4 -o >>>>> build/lib.linux-x86_64-2.4/numpy/core/multiarray_tests.so >>>>> building 'numpy.lib._compiled_base' extension >>>>> compiling C sources >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> creating build/temp.linux-x86_64-2.4/numpy/lib >>>>> creating build/temp.linux-x86_64-2.4/numpy/lib/src >>>>> compile options: '-Inumpy/core/include >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>>> gcc: numpy/lib/src/_compiled_base.c >>>>> In file included from numpy/core/src/private/npy_config.h:4, >>>>> from numpy/lib/src/_compiled_base.c:4: >>>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >>>>> warning: "HAVE_HYPOT" redefined >>>>> In file included from /home/sanjey/include/python2.4/Python.h:8, >>>>> from numpy/lib/src/_compiled_base.c:1: >>>>> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >>>>> location of the previous definition >>>>> gcc -m32 -pthread -shared >>>>> build/temp.linux-x86_64-2.4/numpy/lib/src/_compiled_base.o >>>>> -Lbuild/temp.linux-x86_64-2.4 -o >>>>> build/lib.linux-x86_64-2.4/numpy/lib/_compiled_base.so >>>>> building 'numpy.numarray._capi' extension >>>>> compiling C sources >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> creating build/temp.linux-x86_64-2.4/numpy/numarray >>>>> compile options: '-Inumpy/core/include >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>>> gcc: numpy/numarray/_capi.c >>>>> numpy/core/include/numpy/npy_3kcompat.h:331: warning: >>>>> 'simple_capsule_dtor' defined but not used >>>>> gcc -m32 -pthread -shared >>>>> build/temp.linux-x86_64-2.4/numpy/numarray/_capi.o >>>>> -Lbuild/temp.linux-x86_64-2.4 -o >>>>> build/lib.linux-x86_64-2.4/numpy/numarray/_capi.so >>>>> building 'numpy.fft.fftpack_lite' extension >>>>> compiling C sources >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> creating build/temp.linux-x86_64-2.4/numpy/fft >>>>> compile options: '-Inumpy/core/include >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>>> gcc: numpy/fft/fftpack_litemodule.c >>>>> gcc: numpy/fft/fftpack.c >>>>> gcc -m32 -pthread -shared >>>>> build/temp.linux-x86_64-2.4/numpy/fft/fftpack_litemodule.o >>>>> build/temp.linux-x86_64-2.4/numpy/fft/fftpack.o >>>>> -Lbuild/temp.linux-x86_64-2.4 -o >>>>> build/lib.linux-x86_64-2.4/numpy/fft/fftpack_lite.so >>>>> building 'numpy.linalg.lapack_lite' extension >>>>> compiling C sources >>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>> >>>>> creating build/temp.linux-x86_64-2.4/numpy/linalg >>>>> compile options: '-DNO_ATLAS_INFO=1 -Inumpy/core/include >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>> -I/home/sanjey/include/python2.4 >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>>> gcc: numpy/linalg/lapack_litemodule.c >>>>> gcc: numpy/linalg/python_xerbla.c >>>>> /usr/bin/g77 -g -Wall -g -Wall -shared >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o -L/usr/lib >>>>> -Lbuild/temp.linux-x86_64-2.4 -llapack -lblas -lg2c -o >>>>> build/lib.linux-x86_64-2.4/numpy/linalg/lapack_lite.so >>>>> /usr/bin/ld: skipping incompatible /usr/lib/liblapack.so when >>>>> searching for -llapack >>>>> /usr/bin/ld: skipping incompatible /usr/lib/liblapack.a when searching >>>>> for -llapack >>>>> /usr/bin/ld: skipping incompatible /usr/lib/libblas.so when searching for -lblas >>>>> /usr/bin/ld: skipping incompatible /usr/lib/libblas.a when searching for -lblas >>>>> /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm >>>>> /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm >>>>> /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm >>>>> /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm >>>>> /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 >>>>> /usr/bin/ld: warning: i386 architecture of input file >>>>> `build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o' is >>>>> incompatible with i386:x86-64 output >>>>> /usr/bin/ld: warning: i386 architecture of input file >>>>> `build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o' is >>>>> incompatible with i386:x86-64 output >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xae): >>>>> In function `lapack_lite_dgeev': >>>>> numpy/linalg/lapack_litemodule.c:155: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfe):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x143):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a3):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1f4):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x272):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31c):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ae):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x60e):numpy/linalg/lapack_litemodule.c:171: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6aa): >>>>> In function `lapack_lite_dsyevd': >>>>> numpy/linalg/lapack_litemodule.c:241: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6f4):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x739):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x797):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x7ef):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x869):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x8ff):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xa7c):numpy/linalg/lapack_litemodule.c:254: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb34): >>>>> In function `lapack_lite_zheevd': >>>>> numpy/linalg/lapack_litemodule.c:327: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb7e):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xbc3):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc23):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc74):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xce9):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xd85):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xe77):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfb9):numpy/linalg/lapack_litemodule.c:341: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1087): >>>>> In function `lapack_lite_dgelsd': >>>>> numpy/linalg/lapack_litemodule.c:365: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x10d7):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x111c):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x117d):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x11cf):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1252):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x12e8):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x13d7):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1534):numpy/linalg/lapack_litemodule.c:380: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15af): >>>>> In function `lapack_lite_dgesv': >>>>> numpy/linalg/lapack_litemodule.c:398: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15f9):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x163e):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1692):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x16e7):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x175e):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x189a):numpy/linalg/lapack_litemodule.c:407: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1967): >>>>> In function `lapack_lite_dgesdd': >>>>> numpy/linalg/lapack_litemodule.c:430: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19b7):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19fc):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a5d):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1aaf):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1b32):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1bc8):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d15):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d76):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1efb):numpy/linalg/lapack_litemodule.c:472: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x202b): >>>>> In function `lapack_lite_dgetrf': >>>>> numpy/linalg/lapack_litemodule.c:488: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2063):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20ae):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20fe):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2155):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2235):numpy/linalg/lapack_litemodule.c:496: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22b4): >>>>> In function `lapack_lite_dpotrf': >>>>> numpy/linalg/lapack_litemodule.c:510: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22e9):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x232d):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x238f):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x240a):numpy/linalg/lapack_litemodule.c:516: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24af): >>>>> In function `lapack_lite_dgeqrf': >>>>> numpy/linalg/lapack_litemodule.c:529: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24f9):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x253e):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2598):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x25ef):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2669):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x27a7):numpy/linalg/lapack_litemodule.c:540: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2839): >>>>> In function `lapack_lite_dorgqr': >>>>> numpy/linalg/lapack_litemodule.c:555: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2883):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x28c8):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2927):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x297f):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x29f9):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2afa):numpy/linalg/lapack_litemodule.c:562: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2bbb): >>>>> In function `lapack_lite_zgeev': >>>>> numpy/linalg/lapack_litemodule.c:585: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c0b):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c50):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2cb0):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d04):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d82):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2e2c):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2f6b):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2fb9):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x311b):numpy/linalg/lapack_litemodule.c:601: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31f4): >>>>> In function `lapack_lite_zgelsd': >>>>> numpy/linalg/lapack_litemodule.c:626: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3244):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3289):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x32ef):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3340):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x33c8):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3471):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35b1):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35ff):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x376f):numpy/linalg/lapack_litemodule.c:641: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x37ef): >>>>> In function `lapack_lite_zgesv': >>>>> numpy/linalg/lapack_litemodule.c:658: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3839):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x387e):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x38d2):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3927):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x399e):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3ada):numpy/linalg/lapack_litemodule.c:667: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bae): >>>>> In function `lapack_lite_zgesdd': >>>>> numpy/linalg/lapack_litemodule.c:691: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bfe):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3c43):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cab):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cff):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3d82):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3e2c):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3f70):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3fbe):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4195):numpy/linalg/lapack_litemodule.c:708: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x41ab):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x422b): >>>>> In function `lapack_lite_zgetrf': >>>>> numpy/linalg/lapack_litemodule.c:724: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4263):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42ae):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42fe):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4355):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4435):numpy/linalg/lapack_litemodule.c:732: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44b4): >>>>> In function `lapack_lite_zpotrf': >>>>> numpy/linalg/lapack_litemodule.c:746: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44e9):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x452d):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x458f):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460a):numpy/linalg/lapack_litemodule.c:751: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46af): >>>>> In function `lapack_lite_zgeqrf': >>>>> numpy/linalg/lapack_litemodule.c:764: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46f9):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x473e):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4798):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x47ef):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4869):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x49a7):numpy/linalg/lapack_litemodule.c:774: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a39): >>>>> In function `lapack_lite_zungqr': >>>>> numpy/linalg/lapack_litemodule.c:787: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a83):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ac8):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b27):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b7f):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4bf9):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4cfa):numpy/linalg/lapack_litemodule.c:797: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d58): >>>>> In function `initlapack_lite': >>>>> numpy/linalg/lapack_litemodule.c:858: undefined reference to `Py_InitModule4' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d71): >>>>> In function `initlapack_lite': >>>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1190: >>>>> undefined reference to `PyImport_ImportModule' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d8d):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1197: >>>>> undefined reference to `PyObject_GetAttrString' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4da6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1212: >>>>> undefined reference to `PyCObject_Type' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4db5):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: >>>>> undefined reference to `PyExc_RuntimeError' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dc9):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: >>>>> undefined reference to `PyErr_SetString' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dd7): >>>>> In function `initlapack_lite': >>>>> numpy/linalg/lapack_litemodule.c:865: undefined reference to `PyErr_Print' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ddd):numpy/linalg/lapack_litemodule.c:865: >>>>> undefined reference to `PyExc_ImportError' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4df1):numpy/linalg/lapack_litemodule.c:865: >>>>> undefined reference to `PyErr_SetString' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e18): >>>>> In function `initlapack_lite': >>>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1194: >>>>> undefined reference to `PyExc_ImportError' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e26):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: >>>>> undefined reference to `PyErr_SetString' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e46):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1217: >>>>> undefined reference to `PyCObject_AsVoidPtr' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e88):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: >>>>> undefined reference to `PyExc_RuntimeError' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e96):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ea1):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: >>>>> undefined reference to `PyExc_RuntimeError' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4eb6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1200: >>>>> undefined reference to `PyExc_AttributeError' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f24):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: >>>>> undefined reference to `PyExc_RuntimeError' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f2e):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f46): >>>>> In function `initlapack_lite': >>>>> numpy/linalg/lapack_litemodule.c:866: undefined reference to `PyModule_GetDict' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f66):numpy/linalg/lapack_litemodule.c:867: >>>>> undefined reference to `PyErr_NewException' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f82):numpy/linalg/lapack_litemodule.c:868: >>>>> undefined reference to `PyDict_SetItemString' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x70): >>>>> In function `xerbla_': >>>>> numpy/linalg/python_xerbla.c:35: undefined reference to `PyExc_ValueError' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x7e):numpy/linalg/python_xerbla.c:35: >>>>> undefined reference to `PyErr_SetString' >>>>> collect2: ld returned 1 exit status >>>>> /usr/bin/ld: skipping incompatible /usr/lib/liblapack.so when >>>>> searching for -llapack >>>>> /usr/bin/ld: skipping incompatible /usr/lib/liblapack.a when searching >>>>> for -llapack >>>>> /usr/bin/ld: skipping incompatible /usr/lib/libblas.so when searching for -lblas >>>>> /usr/bin/ld: skipping incompatible /usr/lib/libblas.a when searching for -lblas >>>>> /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm >>>>> /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm >>>>> /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm >>>>> /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm >>>>> /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 >>>>> /usr/bin/ld: warning: i386 architecture of input file >>>>> `build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o' is >>>>> incompatible with i386:x86-64 output >>>>> /usr/bin/ld: warning: i386 architecture of input file >>>>> `build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o' is >>>>> incompatible with i386:x86-64 output >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xae): >>>>> In function `lapack_lite_dgeev': >>>>> numpy/linalg/lapack_litemodule.c:155: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfe):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x143):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a3):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1f4):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x272):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31c):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ae):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x60e):numpy/linalg/lapack_litemodule.c:171: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6aa): >>>>> In function `lapack_lite_dsyevd': >>>>> numpy/linalg/lapack_litemodule.c:241: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6f4):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x739):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x797):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x7ef):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x869):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x8ff):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xa7c):numpy/linalg/lapack_litemodule.c:254: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb34): >>>>> In function `lapack_lite_zheevd': >>>>> numpy/linalg/lapack_litemodule.c:327: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb7e):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xbc3):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc23):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc74):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xce9):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xd85):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xe77):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfb9):numpy/linalg/lapack_litemodule.c:341: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1087): >>>>> In function `lapack_lite_dgelsd': >>>>> numpy/linalg/lapack_litemodule.c:365: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x10d7):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x111c):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x117d):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x11cf):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1252):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x12e8):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x13d7):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1534):numpy/linalg/lapack_litemodule.c:380: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15af): >>>>> In function `lapack_lite_dgesv': >>>>> numpy/linalg/lapack_litemodule.c:398: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15f9):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x163e):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1692):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x16e7):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x175e):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x189a):numpy/linalg/lapack_litemodule.c:407: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1967): >>>>> In function `lapack_lite_dgesdd': >>>>> numpy/linalg/lapack_litemodule.c:430: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19b7):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19fc):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a5d):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1aaf):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1b32):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1bc8):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d15):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d76):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1efb):numpy/linalg/lapack_litemodule.c:472: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x202b): >>>>> In function `lapack_lite_dgetrf': >>>>> numpy/linalg/lapack_litemodule.c:488: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2063):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20ae):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20fe):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2155):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2235):numpy/linalg/lapack_litemodule.c:496: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22b4): >>>>> In function `lapack_lite_dpotrf': >>>>> numpy/linalg/lapack_litemodule.c:510: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22e9):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x232d):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x238f):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x240a):numpy/linalg/lapack_litemodule.c:516: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24af): >>>>> In function `lapack_lite_dgeqrf': >>>>> numpy/linalg/lapack_litemodule.c:529: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24f9):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x253e):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2598):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x25ef):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2669):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x27a7):numpy/linalg/lapack_litemodule.c:540: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2839): >>>>> In function `lapack_lite_dorgqr': >>>>> numpy/linalg/lapack_litemodule.c:555: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2883):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x28c8):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2927):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x297f):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x29f9):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2afa):numpy/linalg/lapack_litemodule.c:562: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2bbb): >>>>> In function `lapack_lite_zgeev': >>>>> numpy/linalg/lapack_litemodule.c:585: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c0b):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c50):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2cb0):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d04):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d82):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2e2c):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2f6b):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2fb9):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x311b):numpy/linalg/lapack_litemodule.c:601: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31f4): >>>>> In function `lapack_lite_zgelsd': >>>>> numpy/linalg/lapack_litemodule.c:626: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3244):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3289):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x32ef):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3340):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x33c8):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3471):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35b1):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35ff):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x376f):numpy/linalg/lapack_litemodule.c:641: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x37ef): >>>>> In function `lapack_lite_zgesv': >>>>> numpy/linalg/lapack_litemodule.c:658: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3839):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x387e):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x38d2):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3927):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x399e):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3ada):numpy/linalg/lapack_litemodule.c:667: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bae): >>>>> In function `lapack_lite_zgesdd': >>>>> numpy/linalg/lapack_litemodule.c:691: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bfe):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3c43):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cab):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cff):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3d82):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3e2c):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3f70):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3fbe):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4195):numpy/linalg/lapack_litemodule.c:708: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x41ab):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x422b): >>>>> In function `lapack_lite_zgetrf': >>>>> numpy/linalg/lapack_litemodule.c:724: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4263):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42ae):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42fe):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4355):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4435):numpy/linalg/lapack_litemodule.c:732: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44b4): >>>>> In function `lapack_lite_zpotrf': >>>>> numpy/linalg/lapack_litemodule.c:746: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44e9):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x452d):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x458f):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460a):numpy/linalg/lapack_litemodule.c:751: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46af): >>>>> In function `lapack_lite_zgeqrf': >>>>> numpy/linalg/lapack_litemodule.c:764: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46f9):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x473e):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4798):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x47ef):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4869):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x49a7):numpy/linalg/lapack_litemodule.c:774: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a39): >>>>> In function `lapack_lite_zungqr': >>>>> numpy/linalg/lapack_litemodule.c:787: undefined reference to `PyArg_ParseTuple' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a83):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ac8):numpy/linalg/lapack_litemodule.c:114: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b27):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b7f):numpy/linalg/lapack_litemodule.c:120: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4bf9):numpy/linalg/lapack_litemodule.c:103: >>>>> undefined reference to `PyType_IsSubtype' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4cfa):numpy/linalg/lapack_litemodule.c:797: >>>>> undefined reference to `Py_BuildValue' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d58): >>>>> In function `initlapack_lite': >>>>> numpy/linalg/lapack_litemodule.c:858: undefined reference to `Py_InitModule4' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d71): >>>>> In function `initlapack_lite': >>>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1190: >>>>> undefined reference to `PyImport_ImportModule' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d8d):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1197: >>>>> undefined reference to `PyObject_GetAttrString' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4da6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1212: >>>>> undefined reference to `PyCObject_Type' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4db5):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: >>>>> undefined reference to `PyExc_RuntimeError' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dc9):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: >>>>> undefined reference to `PyErr_SetString' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dd7): >>>>> In function `initlapack_lite': >>>>> numpy/linalg/lapack_litemodule.c:865: undefined reference to `PyErr_Print' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ddd):numpy/linalg/lapack_litemodule.c:865: >>>>> undefined reference to `PyExc_ImportError' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4df1):numpy/linalg/lapack_litemodule.c:865: >>>>> undefined reference to `PyErr_SetString' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e18): >>>>> In function `initlapack_lite': >>>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1194: >>>>> undefined reference to `PyExc_ImportError' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e26):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: >>>>> undefined reference to `PyErr_SetString' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e46):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1217: >>>>> undefined reference to `PyCObject_AsVoidPtr' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e88):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: >>>>> undefined reference to `PyExc_RuntimeError' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e96):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ea1):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: >>>>> undefined reference to `PyExc_RuntimeError' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4eb6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1200: >>>>> undefined reference to `PyExc_AttributeError' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f24):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: >>>>> undefined reference to `PyExc_RuntimeError' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f2e):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: >>>>> undefined reference to `PyErr_Format' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f46): >>>>> In function `initlapack_lite': >>>>> numpy/linalg/lapack_litemodule.c:866: undefined reference to `PyModule_GetDict' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f66):numpy/linalg/lapack_litemodule.c:867: >>>>> undefined reference to `PyErr_NewException' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f82):numpy/linalg/lapack_litemodule.c:868: >>>>> undefined reference to `PyDict_SetItemString' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x70): >>>>> In function `xerbla_': >>>>> numpy/linalg/python_xerbla.c:35: undefined reference to `PyExc_ValueError' >>>>> build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x7e):numpy/linalg/python_xerbla.c:35: >>>>> undefined reference to `PyErr_SetString' >>>>> collect2: ld returned 1 exit status >>>>> _______________________________________________ >>>>> NumPy-Discussion mailing list >>>>> NumPy-Discussion at scipy.org >>>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion >>>> Since you are using the -m32 flag, do you have *all* the 32-bit >>>> libraries/headers installed (especially Python 2.4 ones) what appears to >>>> be a x86_64 operating system? >>>> >>>> >>>> Bruce >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> NumPy-Discussion mailing list >>>> NumPy-Discussion at scipy.org >>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion >>>> >>> _______________________________________________ >>> NumPy-Discussion mailing list >>> NumPy-Discussion at scipy.org >>> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> The errors are related to numpy not being able to find the Python 2.4 >> 32-bit headers. >> >> You have to had built Python 2.4 as 32-bit and you need to add the >> appropriate path to the appropriate Python 2.4 32-bit header files when >> running 32-bit Python 2.4. >> >> >> Bruce >> _______________________________________________ > I can not help you further. What I would have done is create a 32-bit virtual machine and worked with that. Bruce From p.sanjey at gmail.com Fri Oct 15 14:08:53 2010 From: p.sanjey at gmail.com (P Sanjey) Date: Fri, 15 Oct 2010 14:08:53 -0400 Subject: [Numpy-discussion] Please help a newbie install NUMPY In-Reply-To: <4CB893CD.5090908@gmail.com> References: <4CB871D8.4080503@gmail.com> <4CB878C2.2070009@gmail.com> <4CB893CD.5090908@gmail.com> Message-ID: Thanks Bruce-I didn't have much choice about python I was given a folder and asked to do "make install" after modifying the Makefile to my home directory I just need to figure out how to get numpy to look for the header files in my home folders On Fri, Oct 15, 2010 at 1:47 PM, Bruce Southey wrote: > On 10/15/2010 11:57 AM, P Sanjey wrote: >> oh ok so it cant find the python headers? >> Can I specify them in the site.cfg? I read on the numpy site to do >> that for MKL but thats for intel compilers and I used gcc >> Is it also possible to specify them on this line? >> >> python setup.py build? >> >> >> I did something like this for python 32 bit >> >> CC=" gcc -m32" ./configuree --prefix=/path >> >> Is it possible to do that here? >> >> I have one more doubt-if I have built python using gcc can I buld >> numpy using intel/mkl....etc or should it be gcc s well? >> >> Thanks soo much Bruce its becoming a bit clearer >> >> On Fri, Oct 15, 2010 at 4:52 PM, Bruce Southey wrote: >>> On 10/15/2010 10:30 AM, P Sanjey wrote: >>>> Hi Bruce, >>>> >>>> Not sure how to check if they are there (the libraries)-do you mean >>>> the ones with .so extensions? >>>> How can I know wht libraries are needed and whats already there? >>>> >>>> Yes its a x86_64 machine but I need a 32 bit version as I have another >>>> piece of code that only works on 32 bits >>>> so I am stuck with the 32 bit version >>>> >>>> Thanks for the help >>>> >>>> On Fri, Oct 15, 2010 at 4:23 PM, Bruce Southey wrote: >>>>> On 10/15/2010 09:31 AM, P Sanjey wrote: >>>>>> Please help-I am a newbie and I wanted to try installing numpy on a >>>>>> local /home/usr directory but got the following errors-I am not sure >>>>>> where to even begin fixing this problem and any help would be useful >>>>>> I just did the standard >>>>>> python setup.py build and got the following (loooooong) error message >>>>>> >>>>>> >>>>>> ********************************************************** >>>>>> non-existing path in 'numpy/distutils': 'site.cfg' >>>>>> F2PY Version 1 >>>>>> blas_opt_info: >>>>>> blas_mkl_info: >>>>>> libraries mkl,vml,guide not found in /home/sanjey/lib >>>>>> libraries mkl,vml,guide not found in /usr/local/lib >>>>>> libraries mkl,vml,guide not found in /usr/lib >>>>>> NOT AVAILABLE >>>>>> >>>>>> atlas_blas_threads_info: >>>>>> Setting PTATLAS=ATLAS >>>>>> libraries ptf77blas,ptcblas,atlas not found in /home/sanjey/lib >>>>>> libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib >>>>>> libraries ptf77blas,ptcblas,atlas not found in /usr/lib/sse2 >>>>>> libraries ptf77blas,ptcblas,atlas not found in /usr/lib >>>>>> NOT AVAILABLE >>>>>> >>>>>> atlas_blas_info: >>>>>> libraries f77blas,cblas,atlas not found in /home/sanjey/lib >>>>>> libraries f77blas,cblas,atlas not found in /usr/local/lib >>>>>> libraries f77blas,cblas,atlas not found in /usr/lib/sse2 >>>>>> libraries f77blas,cblas,atlas not found in /usr/lib >>>>>> NOT AVAILABLE >>>>>> >>>>>> blas_info: >>>>>> libraries blas not found in /home/sanjey/lib >>>>>> libraries blas not found in /usr/local/lib >>>>>> FOUND: >>>>>> libraries = ['blas'] >>>>>> library_dirs = ['/usr/lib'] >>>>>> language = f77 >>>>>> >>>>>> FOUND: >>>>>> libraries = ['blas'] >>>>>> library_dirs = ['/usr/lib'] >>>>>> define_macros = [('NO_ATLAS_INFO', 1)] >>>>>> language = f77 >>>>>> >>>>>> lapack_opt_info: >>>>>> lapack_mkl_info: >>>>>> mkl_info: >>>>>> libraries mkl,vml,guide not found in /home/sanjey/lib >>>>>> libraries mkl,vml,guide not found in /usr/local/lib >>>>>> libraries mkl,vml,guide not found in /usr/lib >>>>>> NOT AVAILABLE >>>>>> >>>>>> NOT AVAILABLE >>>>>> >>>>>> atlas_threads_info: >>>>>> Setting PTATLAS=ATLAS >>>>>> libraries ptf77blas,ptcblas,atlas not found in /home/sanjey/lib >>>>>> libraries lapack_atlas not found in /home/sanjey/lib >>>>>> libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib >>>>>> libraries lapack_atlas not found in /usr/local/lib >>>>>> libraries ptf77blas,ptcblas,atlas not found in /usr/lib/sse2 >>>>>> libraries lapack_atlas not found in /usr/lib/sse2 >>>>>> libraries ptf77blas,ptcblas,atlas not found in /usr/lib >>>>>> libraries lapack_atlas not found in /usr/lib >>>>>> numpy.distutils.system_info.atlas_threads_info >>>>>> NOT AVAILABLE >>>>>> >>>>>> atlas_info: >>>>>> libraries f77blas,cblas,atlas not found in /home/sanjey/lib >>>>>> libraries lapack_atlas not found in /home/sanjey/lib >>>>>> libraries f77blas,cblas,atlas not found in /usr/local/lib >>>>>> libraries lapack_atlas not found in /usr/local/lib >>>>>> libraries f77blas,cblas,atlas not found in /usr/lib/sse2 >>>>>> libraries lapack_atlas not found in /usr/lib/sse2 >>>>>> libraries f77blas,cblas,atlas not found in /usr/lib >>>>>> libraries lapack_atlas not found in /usr/lib >>>>>> numpy.distutils.system_info.atlas_info >>>>>> NOT AVAILABLE >>>>>> >>>>>> lapack_info: >>>>>> libraries lapack not found in /home/sanjey/lib >>>>>> libraries lapack not found in /usr/local/lib >>>>>> FOUND: >>>>>> libraries = ['lapack'] >>>>>> library_dirs = ['/usr/lib'] >>>>>> language = f77 >>>>>> >>>>>> FOUND: >>>>>> libraries = ['lapack', 'blas'] >>>>>> library_dirs = ['/usr/lib'] >>>>>> define_macros = [('NO_ATLAS_INFO', 1)] >>>>>> language = f77 >>>>>> >>>>>> running build >>>>>> running config_cc >>>>>> unifing config_cc, config, build_clib, build_ext, build commands >>>>>> --compiler options >>>>>> running config_fc >>>>>> unifing config_fc, config, build_clib, build_ext, build commands >>>>>> --fcompiler options >>>>>> running build_src >>>>>> 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 library "npymath" sources >>>>>> customize GnuFCompiler >>>>>> Found executable /usr/bin/g77 >>>>>> gnu: no Fortran 90 compiler found >>>>>> gnu: no Fortran 90 compiler found >>>>>> customize GnuFCompiler >>>>>> gnu: no Fortran 90 compiler found >>>>>> gnu: no Fortran 90 compiler found >>>>>> customize GnuFCompiler using config >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> gcc -m32 -pthread _configtest.o -o _configtest >>>>>> success! >>>>>> removing: _configtest.c _configtest.o _configtest >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:1: warning: conflicting types for built-in function 'exp' >>>>>> gcc -m32 -pthread _configtest.o -o _configtest >>>>>> _configtest.o(.text+0x19): In function `main': >>>>>> /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' >>>>>> collect2: ld returned 1 exit status >>>>>> _configtest.o(.text+0x19): In function `main': >>>>>> /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' >>>>>> collect2: ld returned 1 exit status >>>>>> failure. >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:1: warning: conflicting types for built-in function 'exp' >>>>>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>>>>> success! >>>>>> removing: _configtest.c _configtest.o _configtest >>>>>> creating build/src.linux-x86_64-2.4/numpy/core >>>>>> creating build/src.linux-x86_64-2.4/numpy/core/src >>>>>> creating build/src.linux-x86_64-2.4/numpy/core/src/npymath >>>>>> conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math.c >>>>>> conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/npymath/ieee754.c >>>>>> conv_template:> >>>>>> build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math_complex.c >>>>>> building extension "numpy.core._sort" sources >>>>>> Generating build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> success! >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> success! >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:5: warning: function declaration isn't a prototype >>>>>> success! >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:5: warning: function declaration isn't a prototype >>>>>> success! >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:5: warning: function declaration isn't a prototype >>>>>> success! >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:5: warning: function declaration isn't a prototype >>>>>> success! >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> removing: _configtest.c _configtest.o _configtest.c _configtest.o >>>>>> _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c >>>>>> _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:5: warning: function declaration isn't a prototype >>>>>> success! >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> removing: _configtest.c _configtest.o _configtest.c _configtest.o >>>>>> _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c >>>>>> _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o >>>>>> _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:5: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:7: error: `SIZEOF_LONGDOUBLE' undeclared (first use in >>>>>> this function) >>>>>> _configtest.c:7: error: (Each undeclared identifier is reported only once >>>>>> _configtest.c:7: error: for each function it appears in.) >>>>>> _configtest.c:5: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:7: error: `SIZEOF_LONGDOUBLE' undeclared (first use in >>>>>> this function) >>>>>> _configtest.c:7: error: (Each undeclared identifier is reported only once >>>>>> _configtest.c:7: error: for each function it appears in.) >>>>>> failure. >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> removing: _configtest.c _configtest.o _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> removing: _configtest.c _configtest.o _configtest.c _configtest.o >>>>>> _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c >>>>>> _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o >>>>>> _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c >>>>>> _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:5: error: size of array `test_array' is negative >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> removing: _configtest.c _configtest.o _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:6: warning: function declaration isn't a prototype >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:6: warning: function declaration isn't a prototype >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:5: warning: function declaration isn't a prototype >>>>>> success! >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:6: warning: function declaration isn't a prototype >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:6: warning: function declaration isn't a prototype >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:5: warning: function declaration isn't a prototype >>>>>> success! >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:1: warning: conflicting types for built-in function 'exp' >>>>>> gcc -m32 -pthread _configtest.o -o _configtest >>>>>> _configtest.o(.text+0x19): In function `main': >>>>>> /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' >>>>>> collect2: ld returned 1 exit status >>>>>> _configtest.o(.text+0x19): In function `main': >>>>>> /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' >>>>>> collect2: ld returned 1 exit status >>>>>> failure. >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:1: warning: conflicting types for built-in function 'exp' >>>>>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>>>>> success! >>>>>> removing: _configtest.c _configtest.o _configtest >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:1: warning: conflicting types for built-in function 'asin' >>>>>> _configtest.c:2: warning: conflicting types for built-in function 'cos' >>>>>> _configtest.c:3: warning: conflicting types for built-in function 'log' >>>>>> _configtest.c:4: warning: conflicting types for built-in function 'fabs' >>>>>> _configtest.c:5: warning: conflicting types for built-in function 'tanh' >>>>>> _configtest.c:6: warning: conflicting types for built-in function 'atan' >>>>>> _configtest.c:7: warning: conflicting types for built-in function 'acos' >>>>>> _configtest.c:8: warning: conflicting types for built-in function 'floor' >>>>>> _configtest.c:9: warning: conflicting types for built-in function 'fmod' >>>>>> _configtest.c:10: warning: conflicting types for built-in function 'sqrt' >>>>>> _configtest.c:11: warning: conflicting types for built-in function 'cosh' >>>>>> _configtest.c:12: warning: conflicting types for built-in function 'modf' >>>>>> _configtest.c:13: warning: conflicting types for built-in function 'sinh' >>>>>> _configtest.c:14: warning: conflicting types for built-in function 'frexp' >>>>>> _configtest.c:15: warning: conflicting types for built-in function 'exp' >>>>>> _configtest.c:16: warning: conflicting types for built-in function 'tan' >>>>>> _configtest.c:17: warning: conflicting types for built-in function 'ceil' >>>>>> _configtest.c:18: warning: conflicting types for built-in function 'log10' >>>>>> _configtest.c:19: warning: conflicting types for built-in function 'sin' >>>>>> _configtest.c:20: warning: conflicting types for built-in function 'ldexp' >>>>>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>>>>> success! >>>>>> removing: _configtest.c _configtest.o _configtest >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:1: warning: conflicting types for built-in function 'expm1' >>>>>> _configtest.c:2: warning: conflicting types for built-in function 'log2' >>>>>> _configtest.c:3: warning: conflicting types for built-in function 'pow' >>>>>> _configtest.c:4: warning: conflicting types for built-in function 'rint' >>>>>> _configtest.c:5: warning: conflicting types for built-in function 'atanh' >>>>>> _configtest.c:6: warning: conflicting types for built-in function 'copysign' >>>>>> _configtest.c:7: warning: conflicting types for built-in function 'asinh' >>>>>> _configtest.c:8: warning: conflicting types for built-in function 'atan2' >>>>>> _configtest.c:9: warning: conflicting types for built-in function 'hypot' >>>>>> _configtest.c:10: warning: conflicting types for built-in function 'acosh' >>>>>> _configtest.c:11: warning: conflicting types for built-in function 'exp2' >>>>>> _configtest.c:12: warning: conflicting types for built-in function 'log1p' >>>>>> _configtest.c:13: warning: conflicting types for built-in function 'nextafter' >>>>>> _configtest.c:14: warning: conflicting types for built-in function 'trunc' >>>>>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>>>>> success! >>>>>> removing: _configtest.c _configtest.o _configtest >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:1: warning: conflicting types for built-in function 'cosf' >>>>>> _configtest.c:2: warning: conflicting types for built-in function 'coshf' >>>>>> _configtest.c:3: warning: conflicting types for built-in function 'rintf' >>>>>> _configtest.c:4: warning: conflicting types for built-in function 'fabsf' >>>>>> _configtest.c:5: warning: conflicting types for built-in function 'floorf' >>>>>> _configtest.c:6: warning: conflicting types for built-in function 'nextafterf' >>>>>> _configtest.c:7: warning: conflicting types for built-in function 'tanhf' >>>>>> _configtest.c:8: warning: conflicting types for built-in function 'log10f' >>>>>> _configtest.c:9: warning: conflicting types for built-in function 'logf' >>>>>> _configtest.c:10: warning: conflicting types for built-in function 'sinhf' >>>>>> _configtest.c:11: warning: conflicting types for built-in function 'acosf' >>>>>> _configtest.c:12: warning: conflicting types for built-in function 'sqrtf' >>>>>> _configtest.c:13: warning: conflicting types for built-in function 'ldexpf' >>>>>> _configtest.c:14: warning: conflicting types for built-in function 'hypotf' >>>>>> _configtest.c:15: warning: conflicting types for built-in function 'log2f' >>>>>> _configtest.c:16: warning: conflicting types for built-in function 'exp2f' >>>>>> _configtest.c:17: warning: conflicting types for built-in function 'atanf' >>>>>> _configtest.c:18: warning: conflicting types for built-in function 'fmodf' >>>>>> _configtest.c:19: warning: conflicting types for built-in function 'atan2f' >>>>>> _configtest.c:20: warning: conflicting types for built-in function 'modff' >>>>>> _configtest.c:21: warning: conflicting types for built-in function 'ceilf' >>>>>> _configtest.c:22: warning: conflicting types for built-in function 'log1pf' >>>>>> _configtest.c:23: warning: conflicting types for built-in function 'asinf' >>>>>> _configtest.c:24: warning: conflicting types for built-in function 'copysignf' >>>>>> _configtest.c:25: warning: conflicting types for built-in function 'acoshf' >>>>>> _configtest.c:26: warning: conflicting types for built-in function 'sinf' >>>>>> _configtest.c:27: warning: conflicting types for built-in function 'tanf' >>>>>> _configtest.c:28: warning: conflicting types for built-in function 'atanhf' >>>>>> _configtest.c:29: warning: conflicting types for built-in function 'truncf' >>>>>> _configtest.c:30: warning: conflicting types for built-in function 'asinhf' >>>>>> _configtest.c:31: warning: conflicting types for built-in function 'frexpf' >>>>>> _configtest.c:32: warning: conflicting types for built-in function 'powf' >>>>>> _configtest.c:33: warning: conflicting types for built-in function 'expf' >>>>>> _configtest.c:34: warning: conflicting types for built-in function 'expm1f' >>>>>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>>>>> success! >>>>>> removing: _configtest.c _configtest.o _configtest >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:1: warning: conflicting types for built-in function 'tanhl' >>>>>> _configtest.c:2: warning: conflicting types for built-in function 'log10l' >>>>>> _configtest.c:3: warning: conflicting types for built-in function 'nextafterl' >>>>>> _configtest.c:4: warning: conflicting types for built-in function 'coshl' >>>>>> _configtest.c:5: warning: conflicting types for built-in function 'cosl' >>>>>> _configtest.c:6: warning: conflicting types for built-in function 'floorl' >>>>>> _configtest.c:7: warning: conflicting types for built-in function 'rintl' >>>>>> _configtest.c:8: warning: conflicting types for built-in function 'fabsl' >>>>>> _configtest.c:9: warning: conflicting types for built-in function 'acosl' >>>>>> _configtest.c:10: warning: conflicting types for built-in function 'ldexpl' >>>>>> _configtest.c:11: warning: conflicting types for built-in function 'sqrtl' >>>>>> _configtest.c:12: warning: conflicting types for built-in function 'logl' >>>>>> _configtest.c:13: warning: conflicting types for built-in function 'expm1l' >>>>>> _configtest.c:14: warning: conflicting types for built-in function 'hypotl' >>>>>> _configtest.c:15: warning: conflicting types for built-in function 'log2l' >>>>>> _configtest.c:16: warning: conflicting types for built-in function 'copysignl' >>>>>> _configtest.c:17: warning: conflicting types for built-in function 'exp2l' >>>>>> _configtest.c:18: warning: conflicting types for built-in function 'atanl' >>>>>> _configtest.c:19: warning: conflicting types for built-in function 'frexpl' >>>>>> _configtest.c:20: warning: conflicting types for built-in function 'atan2l' >>>>>> _configtest.c:21: warning: conflicting types for built-in function 'sinhl' >>>>>> _configtest.c:22: warning: conflicting types for built-in function 'fmodl' >>>>>> _configtest.c:23: warning: conflicting types for built-in function 'log1pl' >>>>>> _configtest.c:24: warning: conflicting types for built-in function 'asinl' >>>>>> _configtest.c:25: warning: conflicting types for built-in function 'ceill' >>>>>> _configtest.c:26: warning: conflicting types for built-in function 'sinl' >>>>>> _configtest.c:27: warning: conflicting types for built-in function 'acoshl' >>>>>> _configtest.c:28: warning: conflicting types for built-in function 'atanhl' >>>>>> _configtest.c:29: warning: conflicting types for built-in function 'tanl' >>>>>> _configtest.c:30: warning: conflicting types for built-in function 'truncl' >>>>>> _configtest.c:31: warning: conflicting types for built-in function 'powl' >>>>>> _configtest.c:32: warning: conflicting types for built-in function 'expl' >>>>>> _configtest.c:33: warning: conflicting types for built-in function 'modfl' >>>>>> _configtest.c:34: warning: conflicting types for built-in function 'asinhl' >>>>>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>>>>> success! >>>>>> removing: _configtest.c _configtest.o _configtest >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:6: warning: function declaration isn't a prototype >>>>>> success! >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:6: warning: function declaration isn't a prototype >>>>>> success! >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:6: warning: function declaration isn't a prototype >>>>>> success! >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:6: warning: function declaration isn't a prototype >>>>>> success! >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> success! >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:1: warning: conflicting types for built-in function 'cexp' >>>>>> _configtest.c:3: warning: conflicting types for built-in function 'ccos' >>>>>> _configtest.c:4: warning: conflicting types for built-in function 'cimag' >>>>>> _configtest.c:5: warning: conflicting types for built-in function 'cabs' >>>>>> _configtest.c:6: warning: conflicting types for built-in function 'cpow' >>>>>> _configtest.c:7: warning: conflicting types for built-in function 'csqrt' >>>>>> _configtest.c:8: warning: conflicting types for built-in function 'carg' >>>>>> _configtest.c:9: warning: conflicting types for built-in function 'creal' >>>>>> _configtest.c:10: warning: conflicting types for built-in function 'csin' >>>>>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>>>>> success! >>>>>> removing: _configtest.c _configtest.o _configtest >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:1: warning: conflicting types for built-in function 'ccosf' >>>>>> _configtest.c:2: warning: conflicting types for built-in function 'cargf' >>>>>> _configtest.c:3: warning: conflicting types for built-in function 'csqrtf' >>>>>> _configtest.c:4: warning: conflicting types for built-in function 'cpowf' >>>>>> _configtest.c:5: warning: conflicting types for built-in function 'cexpf' >>>>>> _configtest.c:6: warning: conflicting types for built-in function 'crealf' >>>>>> _configtest.c:7: warning: conflicting types for built-in function 'csinf' >>>>>> _configtest.c:8: warning: conflicting types for built-in function 'cabsf' >>>>>> _configtest.c:10: warning: conflicting types for built-in function 'cimagf' >>>>>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>>>>> success! >>>>>> removing: _configtest.c _configtest.o _configtest >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:1: warning: conflicting types for built-in function 'csqrtl' >>>>>> _configtest.c:2: warning: conflicting types for built-in function 'cargl' >>>>>> _configtest.c:3: warning: conflicting types for built-in function 'cexpl' >>>>>> _configtest.c:4: warning: conflicting types for built-in function 'ccosl' >>>>>> _configtest.c:5: warning: conflicting types for built-in function 'cpowl' >>>>>> _configtest.c:6: warning: conflicting types for built-in function 'cimagl' >>>>>> _configtest.c:7: warning: conflicting types for built-in function 'csinl' >>>>>> _configtest.c:8: warning: conflicting types for built-in function 'creall' >>>>>> _configtest.c:10: warning: conflicting types for built-in function 'cabsl' >>>>>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>>>>> success! >>>>>> removing: _configtest.c _configtest.o _configtest >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> success! >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:5: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:7: error: `Py_UNICODE_WIDE' undeclared (first use in >>>>>> this function) >>>>>> _configtest.c:7: error: (Each undeclared identifier is reported only once >>>>>> _configtest.c:7: error: for each function it appears in.) >>>>>> _configtest.c:5: warning: function declaration isn't a prototype >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:7: error: `Py_UNICODE_WIDE' undeclared (first use in >>>>>> this function) >>>>>> _configtest.c:7: error: (Each undeclared identifier is reported only once >>>>>> _configtest.c:7: error: for each function it appears in.) >>>>>> failure. >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> removing: _configtest.c _configtest.o >>>>>> ('File:', 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h') >>>>>> #define HAVE_ENDIAN_H 1 >>>>>> #define SIZEOF_PY_INTPTR_T 4 >>>>>> #define SIZEOF_PY_LONG_LONG 8 >>>>>> #define MATHLIB m >>>>>> #define HAVE_SIN >>>>>> #define HAVE_COS >>>>>> #define HAVE_TAN >>>>>> #define HAVE_SINH >>>>>> #define HAVE_COSH >>>>>> #define HAVE_TANH >>>>>> #define HAVE_FABS >>>>>> #define HAVE_FLOOR >>>>>> #define HAVE_CEIL >>>>>> #define HAVE_SQRT >>>>>> #define HAVE_LOG10 >>>>>> #define HAVE_LOG >>>>>> #define HAVE_EXP >>>>>> #define HAVE_ASIN >>>>>> #define HAVE_ACOS >>>>>> #define HAVE_ATAN >>>>>> #define HAVE_FMOD >>>>>> #define HAVE_MODF >>>>>> #define HAVE_FREXP >>>>>> #define HAVE_LDEXP >>>>>> #define HAVE_EXPM1 >>>>>> #define HAVE_LOG1P >>>>>> #define HAVE_ACOSH >>>>>> #define HAVE_ASINH >>>>>> #define HAVE_ATANH >>>>>> #define HAVE_RINT >>>>>> #define HAVE_TRUNC >>>>>> #define HAVE_EXP2 >>>>>> #define HAVE_LOG2 >>>>>> #define HAVE_HYPOT >>>>>> #define HAVE_ATAN2 >>>>>> #define HAVE_POW >>>>>> #define HAVE_COPYSIGN >>>>>> #define HAVE_NEXTAFTER >>>>>> #define HAVE_SINF >>>>>> #define HAVE_COSF >>>>>> #define HAVE_TANF >>>>>> #define HAVE_SINHF >>>>>> #define HAVE_COSHF >>>>>> #define HAVE_TANHF >>>>>> #define HAVE_FABSF >>>>>> #define HAVE_FLOORF >>>>>> #define HAVE_CEILF >>>>>> #define HAVE_RINTF >>>>>> #define HAVE_TRUNCF >>>>>> #define HAVE_SQRTF >>>>>> #define HAVE_LOG10F >>>>>> #define HAVE_LOGF >>>>>> #define HAVE_LOG1PF >>>>>> #define HAVE_EXPF >>>>>> #define HAVE_EXPM1F >>>>>> #define HAVE_ASINF >>>>>> #define HAVE_ACOSF >>>>>> #define HAVE_ATANF >>>>>> #define HAVE_ASINHF >>>>>> #define HAVE_ACOSHF >>>>>> #define HAVE_ATANHF >>>>>> #define HAVE_HYPOTF >>>>>> #define HAVE_ATAN2F >>>>>> #define HAVE_POWF >>>>>> #define HAVE_FMODF >>>>>> #define HAVE_MODFF >>>>>> #define HAVE_FREXPF >>>>>> #define HAVE_LDEXPF >>>>>> #define HAVE_EXP2F >>>>>> #define HAVE_LOG2F >>>>>> #define HAVE_COPYSIGNF >>>>>> #define HAVE_NEXTAFTERF >>>>>> #define HAVE_SINL >>>>>> #define HAVE_COSL >>>>>> #define HAVE_TANL >>>>>> #define HAVE_SINHL >>>>>> #define HAVE_COSHL >>>>>> #define HAVE_TANHL >>>>>> #define HAVE_FABSL >>>>>> #define HAVE_FLOORL >>>>>> #define HAVE_CEILL >>>>>> #define HAVE_RINTL >>>>>> #define HAVE_TRUNCL >>>>>> #define HAVE_SQRTL >>>>>> #define HAVE_LOG10L >>>>>> #define HAVE_LOGL >>>>>> #define HAVE_LOG1PL >>>>>> #define HAVE_EXPL >>>>>> #define HAVE_EXPM1L >>>>>> #define HAVE_ASINL >>>>>> #define HAVE_ACOSL >>>>>> #define HAVE_ATANL >>>>>> #define HAVE_ASINHL >>>>>> #define HAVE_ACOSHL >>>>>> #define HAVE_ATANHL >>>>>> #define HAVE_HYPOTL >>>>>> #define HAVE_ATAN2L >>>>>> #define HAVE_POWL >>>>>> #define HAVE_FMODL >>>>>> #define HAVE_MODFL >>>>>> #define HAVE_FREXPL >>>>>> #define HAVE_LDEXPL >>>>>> #define HAVE_EXP2L >>>>>> #define HAVE_LOG2L >>>>>> #define HAVE_COPYSIGNL >>>>>> #define HAVE_NEXTAFTERL >>>>>> #define HAVE_DECL_ISNAN >>>>>> #define HAVE_DECL_ISINF >>>>>> #define HAVE_DECL_SIGNBIT >>>>>> #define HAVE_DECL_ISFINITE >>>>>> #define HAVE_COMPLEX_H >>>>>> #define HAVE_CREAL >>>>>> #define HAVE_CIMAG >>>>>> #define HAVE_CABS >>>>>> #define HAVE_CARG >>>>>> #define HAVE_CEXP >>>>>> #define HAVE_CSQRT >>>>>> #define HAVE_CLOG >>>>>> #define HAVE_CCOS >>>>>> #define HAVE_CSIN >>>>>> #define HAVE_CPOW >>>>>> #define HAVE_CREALF >>>>>> #define HAVE_CIMAGF >>>>>> #define HAVE_CABSF >>>>>> #define HAVE_CARGF >>>>>> #define HAVE_CEXPF >>>>>> #define HAVE_CSQRTF >>>>>> #define HAVE_CLOGF >>>>>> #define HAVE_CCOSF >>>>>> #define HAVE_CSINF >>>>>> #define HAVE_CPOWF >>>>>> #define HAVE_CREALL >>>>>> #define HAVE_CIMAGL >>>>>> #define HAVE_CABSL >>>>>> #define HAVE_CARGL >>>>>> #define HAVE_CEXPL >>>>>> #define HAVE_CSQRTL >>>>>> #define HAVE_CLOGL >>>>>> #define HAVE_CCOSL >>>>>> #define HAVE_CSINL >>>>>> #define HAVE_CPOWL >>>>>> #define HAVE_LDOUBLE_INTEL_EXTENDED_12_BYTES_LE 1 >>>>>> #ifndef __cplusplus >>>>>> /* #undef inline */ >>>>>> #endif >>>>>> >>>>>> #ifndef _NPY_NPY_CONFIG_H_ >>>>>> #error config.h should never be included directly, include npy_config.h instead >>>>>> #endif >>>>>> >>>>>> EOF >>>>>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' >>>>>> to sources. >>>>>> Generating build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:1: warning: conflicting types for built-in function 'exp' >>>>>> gcc -m32 -pthread _configtest.o -o _configtest >>>>>> _configtest.o(.text+0x19): In function `main': >>>>>> /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' >>>>>> collect2: ld returned 1 exit status >>>>>> _configtest.o(.text+0x19): In function `main': >>>>>> /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' >>>>>> collect2: ld returned 1 exit status >>>>>> failure. >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:1: warning: conflicting types for built-in function 'exp' >>>>>> gcc -m32 -pthread _configtest.o -lm -o _configtest >>>>>> success! >>>>>> removing: _configtest.c _configtest.o _configtest >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:5: warning: function declaration isn't a prototype >>>>>> success! >>>>>> removing: _configtest.c _configtest.o >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> _configtest.c:4: warning: function declaration isn't a prototype >>>>>> _configtest.c:5:18: warning: extra tokens at end of #ifndef directive >>>>>> _configtest.c: In function `main': >>>>>> _configtest.c:4: warning: control reaches end of non-void function >>>>>> success! >>>>>> removing: _configtest.c _configtest.o >>>>>> File: build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h >>>>>> #define NPY_HAVE_ENDIAN_H 1 >>>>>> #define NPY_SIZEOF_SHORT SIZEOF_SHORT >>>>>> #define NPY_SIZEOF_INT SIZEOF_INT >>>>>> #define NPY_SIZEOF_LONG SIZEOF_LONG >>>>>> #define NPY_SIZEOF_FLOAT 4 >>>>>> #define NPY_SIZEOF_COMPLEX_FLOAT 8 >>>>>> #define NPY_SIZEOF_DOUBLE 8 >>>>>> #define NPY_SIZEOF_COMPLEX_DOUBLE 16 >>>>>> #define NPY_SIZEOF_LONGDOUBLE 12 >>>>>> #define NPY_SIZEOF_COMPLEX_LONGDOUBLE 24 >>>>>> #define NPY_SIZEOF_PY_INTPTR_T 4 >>>>>> #define NPY_SIZEOF_PY_LONG_LONG 8 >>>>>> #define NPY_SIZEOF_LONGLONG 8 >>>>>> #define NPY_NO_SMP 1 >>>>>> #define NPY_HAVE_DECL_ISNAN >>>>>> #define NPY_HAVE_DECL_ISINF >>>>>> #define NPY_HAVE_DECL_SIGNBIT >>>>>> #define NPY_HAVE_DECL_ISFINITE >>>>>> #define NPY_USE_C99_COMPLEX >>>>>> #define NPY_HAVE_COMPLEX_DOUBLE 1 >>>>>> #define NPY_HAVE_COMPLEX_FLOAT 1 >>>>>> #define NPY_HAVE_COMPLEX_LONG_DOUBLE 1 >>>>>> #define NPY_USE_C99_FORMATS 1 >>>>>> #define NPY_VISIBILITY_HIDDEN __attribute__((visibility("hidden"))) >>>>>> #define NPY_ABI_VERSION 0x01000009 >>>>>> #define NPY_API_VERSION 0x00000004 >>>>>> >>>>>> #ifndef __STDC_FORMAT_MACROS >>>>>> #define __STDC_FORMAT_MACROS 1 >>>>>> #endif >>>>>> >>>>>> EOF >>>>>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' >>>>>> to sources. >>>>>> executing numpy/core/code_generators/generate_numpy_api.py >>>>>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__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/include/numpy/config.h', >>>>>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', >>>>>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h'] >>>>>> building extension "numpy.core.multiarray" sources >>>>>> non-existing path in 'numpy/core': >>>>>> 'build/src.linux-x86_64-2.4/numpy/core/src/multiarray' >>>>>> creating build/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>>>> conv_template:> >>>>>> build/src.linux-x86_64-2.4/numpy/core/src/multiarray/scalartypes.c >>>>>> conv_template:> >>>>>> build/src.linux-x86_64-2.4/numpy/core/src/multiarray/arraytypes.c >>>>>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' >>>>>> to sources. >>>>>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' >>>>>> to sources. >>>>>> executing numpy/core/code_generators/generate_numpy_api.py >>>>>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h' >>>>>> to sources. >>>>>> numpy.core - nothing done with h_files = >>>>>> ['build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h', >>>>>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', >>>>>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h'] >>>>>> building extension "numpy.core.umath" sources >>>>>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' >>>>>> to sources. >>>>>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' >>>>>> to sources. >>>>>> executing numpy/core/code_generators/generate_ufunc_api.py >>>>>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__ufunc_api.h' >>>>>> to sources. >>>>>> non-existing path in 'numpy/core': >>>>>> 'build/src.linux-x86_64-2.4/numpy/core/src/umath' >>>>>> creating build/src.linux-x86_64-2.4/numpy/core/src/umath >>>>>> conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/umath/loops.c >>>>>> conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/umath/umathmodule.c >>>>>> conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/umath/funcs.inc >>>>>> adding 'build/src.linux-x86_64-2.4/numpy/core/src/umath' to include_dirs. >>>>>> numpy.core - nothing done with h_files = >>>>>> ['build/src.linux-x86_64-2.4/numpy/core/src/umath/funcs.inc', >>>>>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h', >>>>>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', >>>>>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__ufunc_api.h'] >>>>>> building extension "numpy.core.scalarmath" sources >>>>>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' >>>>>> to sources. >>>>>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' >>>>>> to sources. >>>>>> executing numpy/core/code_generators/generate_numpy_api.py >>>>>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h' >>>>>> to sources. >>>>>> executing numpy/core/code_generators/generate_ufunc_api.py >>>>>> adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__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/include/numpy/config.h', >>>>>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', >>>>>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h', >>>>>> 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__ufunc_api.h'] >>>>>> building extension "numpy.core._dotblas" sources >>>>>> building extension "numpy.core.umath_tests" sources >>>>>> conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/umath/umath_tests.c >>>>>> building extension "numpy.core.multiarray_tests" sources >>>>>> conv_template:> >>>>>> build/src.linux-x86_64-2.4/numpy/core/src/multiarray/multiarray_tests.c >>>>>> building extension "numpy.lib._compiled_base" sources >>>>>> building extension "numpy.numarray._capi" sources >>>>>> building extension "numpy.fft.fftpack_lite" sources >>>>>> building extension "numpy.linalg.lapack_lite" sources >>>>>> creating build/src.linux-x86_64-2.4/numpy/linalg >>>>>> adding 'numpy/linalg/lapack_litemodule.c' to sources. >>>>>> adding 'numpy/linalg/python_xerbla.c' to sources. >>>>>> building extension "numpy.random.mtrand" sources >>>>>> creating build/src.linux-x86_64-2.4/numpy/random >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/src/private -Inumpy/core/src >>>>>> -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 -c' >>>>>> gcc: _configtest.c >>>>>> gcc -m32 -pthread _configtest.o -o _configtest >>>>>> _configtest >>>>>> failure. >>>>>> removing: _configtest.c _configtest.o _configtest >>>>>> building data_files sources >>>>>> build_src: building npy-pkg config files >>>>>> running build_py >>>>>> creating build/lib.linux-x86_64-2.4 >>>>>> creating build/lib.linux-x86_64-2.4/numpy >>>>>> copying numpy/version.py -> build/lib.linux-x86_64-2.4/numpy >>>>>> copying numpy/matlib.py -> build/lib.linux-x86_64-2.4/numpy >>>>>> copying numpy/ctypeslib.py -> build/lib.linux-x86_64-2.4/numpy >>>>>> copying numpy/setupscons.py -> build/lib.linux-x86_64-2.4/numpy >>>>>> copying numpy/__init__.py -> build/lib.linux-x86_64-2.4/numpy >>>>>> copying numpy/setup.py -> build/lib.linux-x86_64-2.4/numpy >>>>>> copying numpy/dual.py -> build/lib.linux-x86_64-2.4/numpy >>>>>> copying numpy/_import_tools.py -> build/lib.linux-x86_64-2.4/numpy >>>>>> copying numpy/add_newdocs.py -> build/lib.linux-x86_64-2.4/numpy >>>>>> copying build/src.linux-x86_64-2.4/numpy/__config__.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy >>>>>> creating build/lib.linux-x86_64-2.4/numpy/distutils >>>>>> copying numpy/distutils/from_template.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>>> copying numpy/distutils/npy_pkg_config.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>>> copying numpy/distutils/compat.py -> build/lib.linux-x86_64-2.4/numpy/distutils >>>>>> copying numpy/distutils/setupscons.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>>> copying numpy/distutils/__init__.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>>> copying numpy/distutils/lib2def.py -> build/lib.linux-x86_64-2.4/numpy/distutils >>>>>> copying numpy/distutils/interactive.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>>> copying numpy/distutils/info.py -> build/lib.linux-x86_64-2.4/numpy/distutils >>>>>> copying numpy/distutils/environment.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>>> copying numpy/distutils/setup.py -> build/lib.linux-x86_64-2.4/numpy/distutils >>>>>> copying numpy/distutils/cpuinfo.py -> build/lib.linux-x86_64-2.4/numpy/distutils >>>>>> copying numpy/distutils/extension.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>>> copying numpy/distutils/core.py -> build/lib.linux-x86_64-2.4/numpy/distutils >>>>>> copying numpy/distutils/intelccompiler.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>>> copying numpy/distutils/log.py -> build/lib.linux-x86_64-2.4/numpy/distutils >>>>>> copying numpy/distutils/__version__.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>>> copying numpy/distutils/unixccompiler.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>>> copying numpy/distutils/misc_util.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>>> copying numpy/distutils/line_endings.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>>> copying numpy/distutils/exec_command.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>>> copying numpy/distutils/conv_template.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>>> copying numpy/distutils/ccompiler.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>>> copying numpy/distutils/mingw32ccompiler.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>>> copying numpy/distutils/system_info.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>>> copying numpy/distutils/numpy_distribution.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>>> copying build/src.linux-x86_64-2.4/numpy/distutils/__config__.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils >>>>>> creating build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>>> copying numpy/distutils/command/install.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>>> copying numpy/distutils/command/egg_info.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>>> copying numpy/distutils/command/install_clib.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>>> copying numpy/distutils/command/bdist_rpm.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>>> copying numpy/distutils/command/develop.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>>> copying numpy/distutils/command/install_data.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>>> copying numpy/distutils/command/__init__.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>>> copying numpy/distutils/command/build_py.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>>> copying numpy/distutils/command/build_src.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>>> copying numpy/distutils/command/build_clib.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>>> copying numpy/distutils/command/build_ext.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>>> copying numpy/distutils/command/autodist.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>>> copying numpy/distutils/command/install_headers.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>>> copying numpy/distutils/command/config.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>>> copying numpy/distutils/command/config_compiler.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>>> copying numpy/distutils/command/build.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>>> copying numpy/distutils/command/build_scripts.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>>> copying numpy/distutils/command/sdist.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>>> copying numpy/distutils/command/scons.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/command >>>>>> creating build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>>>> copying numpy/distutils/fcompiler/none.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>>>> copying numpy/distutils/fcompiler/hpux.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>>>> copying numpy/distutils/fcompiler/compaq.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>>>> copying numpy/distutils/fcompiler/absoft.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>>>> copying numpy/distutils/fcompiler/vast.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>>>> copying numpy/distutils/fcompiler/nag.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>>>> copying numpy/distutils/fcompiler/__init__.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>>>> copying numpy/distutils/fcompiler/sun.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>>>> copying numpy/distutils/fcompiler/mips.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>>>> copying numpy/distutils/fcompiler/intel.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>>>> copying numpy/distutils/fcompiler/gnu.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>>>> copying numpy/distutils/fcompiler/g95.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>>>> copying numpy/distutils/fcompiler/pg.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>>>> copying numpy/distutils/fcompiler/ibm.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>>>> copying numpy/distutils/fcompiler/lahey.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler >>>>>> creating build/lib.linux-x86_64-2.4/numpy/testing >>>>>> copying numpy/testing/nulltester.py -> build/lib.linux-x86_64-2.4/numpy/testing >>>>>> copying numpy/testing/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/testing >>>>>> copying numpy/testing/__init__.py -> build/lib.linux-x86_64-2.4/numpy/testing >>>>>> copying numpy/testing/setup.py -> build/lib.linux-x86_64-2.4/numpy/testing >>>>>> copying numpy/testing/decorators.py -> build/lib.linux-x86_64-2.4/numpy/testing >>>>>> copying numpy/testing/utils.py -> build/lib.linux-x86_64-2.4/numpy/testing >>>>>> copying numpy/testing/noseclasses.py -> build/lib.linux-x86_64-2.4/numpy/testing >>>>>> copying numpy/testing/numpytest.py -> build/lib.linux-x86_64-2.4/numpy/testing >>>>>> copying numpy/testing/nosetester.py -> build/lib.linux-x86_64-2.4/numpy/testing >>>>>> creating build/lib.linux-x86_64-2.4/numpy/f2py >>>>>> copying numpy/f2py/auxfuncs.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>>> copying numpy/f2py/common_rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>>> copying numpy/f2py/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>>> copying numpy/f2py/__init__.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>>> copying numpy/f2py/cb_rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>>> copying numpy/f2py/info.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>>> copying numpy/f2py/setup.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>>> copying numpy/f2py/f2py2e.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>>> copying numpy/f2py/cfuncs.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>>> copying numpy/f2py/crackfortran.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>>> copying numpy/f2py/use_rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>>> copying numpy/f2py/diagnose.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>>> copying numpy/f2py/f2py_testing.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>>> copying numpy/f2py/__version__.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>>> copying numpy/f2py/capi_maps.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>>> copying numpy/f2py/func2subr.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>>> copying numpy/f2py/f90mod_rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>>> copying numpy/f2py/rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py >>>>>> creating build/lib.linux-x86_64-2.4/numpy/core >>>>>> copying numpy/core/defchararray.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>>> copying numpy/core/numeric.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>>> copying numpy/core/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>>> copying numpy/core/__init__.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>>> copying numpy/core/info.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>>> copying numpy/core/function_base.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>>> copying numpy/core/getlimits.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>>> copying numpy/core/setup.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>>> copying numpy/core/fromnumeric.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>>> copying numpy/core/shape_base.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>>> copying numpy/core/setup_common.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>>> copying numpy/core/records.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>>> copying numpy/core/memmap.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>>> copying numpy/core/arrayprint.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>>> copying numpy/core/numerictypes.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>>> copying numpy/core/machar.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>>> copying numpy/core/_mx_datetime_parser.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/core >>>>>> copying numpy/core/scons_support.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>>> copying numpy/core/_internal.py -> build/lib.linux-x86_64-2.4/numpy/core >>>>>> copying numpy/core/code_generators/generate_numpy_api.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/core >>>>>> creating build/lib.linux-x86_64-2.4/numpy/lib >>>>>> copying numpy/lib/_datasource.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>>> copying numpy/lib/arraysetops.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>>> copying numpy/lib/index_tricks.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>>> copying numpy/lib/format.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>>> copying numpy/lib/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>>> copying numpy/lib/__init__.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>>> copying numpy/lib/info.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>>> copying numpy/lib/function_base.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>>> copying numpy/lib/setup.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>>> copying numpy/lib/arrayterator.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>>> copying numpy/lib/ufunclike.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>>> copying numpy/lib/shape_base.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>>> copying numpy/lib/user_array.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>>> copying numpy/lib/type_check.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>>> copying numpy/lib/stride_tricks.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>>> copying numpy/lib/recfunctions.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>>> copying numpy/lib/npyio.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>>> copying numpy/lib/_iotools.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>>> copying numpy/lib/utils.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>>> copying numpy/lib/financial.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>>> copying numpy/lib/twodim_base.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>>> copying numpy/lib/polynomial.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>>> copying numpy/lib/scimath.py -> build/lib.linux-x86_64-2.4/numpy/lib >>>>>> creating build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>>> copying numpy/oldnumeric/functions.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>>> copying numpy/oldnumeric/alter_code1.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>>> copying numpy/oldnumeric/misc.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>>> copying numpy/oldnumeric/compat.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>>> copying numpy/oldnumeric/setupscons.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>>> copying numpy/oldnumeric/__init__.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>>> copying numpy/oldnumeric/linear_algebra.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>>> copying numpy/oldnumeric/setup.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>>> copying numpy/oldnumeric/random_array.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>>> copying numpy/oldnumeric/user_array.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>>> copying numpy/oldnumeric/alter_code2.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>>> copying numpy/oldnumeric/fft.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>>> copying numpy/oldnumeric/matrix.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>>> copying numpy/oldnumeric/fix_default_axis.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>>> copying numpy/oldnumeric/rng_stats.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>>> copying numpy/oldnumeric/mlab.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>>> copying numpy/oldnumeric/ma.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>>> copying numpy/oldnumeric/ufuncs.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>>> copying numpy/oldnumeric/rng.py -> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>>> copying numpy/oldnumeric/array_printer.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>>> copying numpy/oldnumeric/typeconv.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>>> copying numpy/oldnumeric/precision.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>>> copying numpy/oldnumeric/arrayfns.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/oldnumeric >>>>>> creating build/lib.linux-x86_64-2.4/numpy/numarray >>>>>> copying numpy/numarray/nd_image.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>>>>> copying numpy/numarray/util.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>>>>> copying numpy/numarray/convolve.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>>>>> copying numpy/numarray/functions.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>>>>> copying numpy/numarray/alter_code1.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/numarray >>>>>> copying numpy/numarray/compat.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>>>>> copying numpy/numarray/setupscons.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/numarray >>>>>> copying numpy/numarray/__init__.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>>>>> copying numpy/numarray/linear_algebra.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/numarray >>>>>> copying numpy/numarray/setup.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>>>>> copying numpy/numarray/random_array.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/numarray >>>>>> copying numpy/numarray/alter_code2.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/numarray >>>>>> copying numpy/numarray/fft.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>>>>> copying numpy/numarray/matrix.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>>>>> copying numpy/numarray/numerictypes.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/numarray >>>>>> copying numpy/numarray/image.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>>>>> copying numpy/numarray/mlab.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>>>>> copying numpy/numarray/ma.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>>>>> copying numpy/numarray/session.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>>>>> copying numpy/numarray/ufuncs.py -> build/lib.linux-x86_64-2.4/numpy/numarray >>>>>> creating build/lib.linux-x86_64-2.4/numpy/fft >>>>>> copying numpy/fft/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/fft >>>>>> copying numpy/fft/__init__.py -> build/lib.linux-x86_64-2.4/numpy/fft >>>>>> copying numpy/fft/info.py -> build/lib.linux-x86_64-2.4/numpy/fft >>>>>> copying numpy/fft/setup.py -> build/lib.linux-x86_64-2.4/numpy/fft >>>>>> copying numpy/fft/fftpack.py -> build/lib.linux-x86_64-2.4/numpy/fft >>>>>> copying numpy/fft/helper.py -> build/lib.linux-x86_64-2.4/numpy/fft >>>>>> creating build/lib.linux-x86_64-2.4/numpy/linalg >>>>>> copying numpy/linalg/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/linalg >>>>>> copying numpy/linalg/__init__.py -> build/lib.linux-x86_64-2.4/numpy/linalg >>>>>> copying numpy/linalg/info.py -> build/lib.linux-x86_64-2.4/numpy/linalg >>>>>> copying numpy/linalg/setup.py -> build/lib.linux-x86_64-2.4/numpy/linalg >>>>>> copying numpy/linalg/linalg.py -> build/lib.linux-x86_64-2.4/numpy/linalg >>>>>> creating build/lib.linux-x86_64-2.4/numpy/random >>>>>> copying numpy/random/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/random >>>>>> copying numpy/random/__init__.py -> build/lib.linux-x86_64-2.4/numpy/random >>>>>> copying numpy/random/info.py -> build/lib.linux-x86_64-2.4/numpy/random >>>>>> copying numpy/random/setup.py -> build/lib.linux-x86_64-2.4/numpy/random >>>>>> creating build/lib.linux-x86_64-2.4/numpy/ma >>>>>> copying numpy/ma/version.py -> build/lib.linux-x86_64-2.4/numpy/ma >>>>>> copying numpy/ma/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/ma >>>>>> copying numpy/ma/__init__.py -> build/lib.linux-x86_64-2.4/numpy/ma >>>>>> copying numpy/ma/setup.py -> build/lib.linux-x86_64-2.4/numpy/ma >>>>>> copying numpy/ma/bench.py -> build/lib.linux-x86_64-2.4/numpy/ma >>>>>> copying numpy/ma/core.py -> build/lib.linux-x86_64-2.4/numpy/ma >>>>>> copying numpy/ma/testutils.py -> build/lib.linux-x86_64-2.4/numpy/ma >>>>>> copying numpy/ma/timer_comparison.py -> build/lib.linux-x86_64-2.4/numpy/ma >>>>>> copying numpy/ma/extras.py -> build/lib.linux-x86_64-2.4/numpy/ma >>>>>> copying numpy/ma/mrecords.py -> build/lib.linux-x86_64-2.4/numpy/ma >>>>>> creating build/lib.linux-x86_64-2.4/numpy/matrixlib >>>>>> copying numpy/matrixlib/setupscons.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/matrixlib >>>>>> copying numpy/matrixlib/__init__.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/matrixlib >>>>>> copying numpy/matrixlib/setup.py -> build/lib.linux-x86_64-2.4/numpy/matrixlib >>>>>> copying numpy/matrixlib/defmatrix.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/matrixlib >>>>>> creating build/lib.linux-x86_64-2.4/numpy/compat >>>>>> copying numpy/compat/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/compat >>>>>> copying numpy/compat/__init__.py -> build/lib.linux-x86_64-2.4/numpy/compat >>>>>> copying numpy/compat/setup.py -> build/lib.linux-x86_64-2.4/numpy/compat >>>>>> copying numpy/compat/py3k.py -> build/lib.linux-x86_64-2.4/numpy/compat >>>>>> copying numpy/compat/_inspect.py -> build/lib.linux-x86_64-2.4/numpy/compat >>>>>> creating build/lib.linux-x86_64-2.4/numpy/polynomial >>>>>> copying numpy/polynomial/__init__.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/polynomial >>>>>> copying numpy/polynomial/setup.py -> build/lib.linux-x86_64-2.4/numpy/polynomial >>>>>> copying numpy/polynomial/chebyshev.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/polynomial >>>>>> copying numpy/polynomial/polynomial.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/polynomial >>>>>> copying numpy/polynomial/polyutils.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/polynomial >>>>>> copying numpy/polynomial/polytemplate.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/polynomial >>>>>> creating build/lib.linux-x86_64-2.4/numpy/doc >>>>>> copying numpy/doc/byteswapping.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>>> copying numpy/doc/glossary.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>>> copying numpy/doc/indexing.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>>> copying numpy/doc/misc.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>>> copying numpy/doc/internals.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>>> copying numpy/doc/__init__.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>>> copying numpy/doc/creation.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>>> copying numpy/doc/jargon.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>>> copying numpy/doc/basics.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>>> copying numpy/doc/io.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>>> copying numpy/doc/methods_vs_functions.py -> >>>>>> build/lib.linux-x86_64-2.4/numpy/doc >>>>>> copying numpy/doc/broadcasting.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>>> copying numpy/doc/constants.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>>> copying numpy/doc/howtofind.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>>> copying numpy/doc/ufuncs.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>>> copying numpy/doc/subclassing.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>>> copying numpy/doc/structured_arrays.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>>> copying numpy/doc/performance.py -> build/lib.linux-x86_64-2.4/numpy/doc >>>>>> running build_clib >>>>>> customize UnixCCompiler >>>>>> customize UnixCCompiler using build_clib >>>>>> building 'npymath' library >>>>>> compiling C sources >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> creating build/temp.linux-x86_64-2.4 >>>>>> creating build/temp.linux-x86_64-2.4/build >>>>>> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4 >>>>>> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy >>>>>> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core >>>>>> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src >>>>>> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/npymath >>>>>> compile options: '-Inumpy/core/include >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>>>> gcc: build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math.c >>>>>> In file included from numpy/core/src/private/npy_config.h:4, >>>>>> from numpy/core/src/npymath/npy_math_private.h:24, >>>>>> from numpy/core/src/npymath/npy_math.c.src:56: >>>>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >>>>>> warning: "HAVE_HYPOT" redefined >>>>>> In file included from /home/sanjey/include/python2.4/Python.h:8, >>>>>> from numpy/core/src/npymath/npy_math_private.h:21, >>>>>> from numpy/core/src/npymath/npy_math.c.src:56: >>>>>> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >>>>>> location of the previous definition >>>>>> gcc: build/src.linux-x86_64-2.4/numpy/core/src/npymath/ieee754.c >>>>>> In file included from numpy/core/src/private/npy_config.h:4, >>>>>> from numpy/core/src/npymath/npy_math_common.h:8, >>>>>> from numpy/core/src/npymath/ieee754.c.src:7: >>>>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >>>>>> warning: "HAVE_HYPOT" redefined >>>>>> In file included from /home/sanjey/include/python2.4/Python.h:8, >>>>>> from numpy/core/src/npymath/npy_math_common.h:4, >>>>>> from numpy/core/src/npymath/ieee754.c.src:7: >>>>>> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >>>>>> location of the previous definition >>>>>> gcc: build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math_complex.c >>>>>> In file included from numpy/core/src/private/npy_config.h:4, >>>>>> from numpy/core/src/npymath/npy_math_common.h:8, >>>>>> from numpy/core/src/npymath/npy_math_complex.c.src:31: >>>>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >>>>>> warning: "HAVE_HYPOT" redefined >>>>>> In file included from /home/sanjey/include/python2.4/Python.h:8, >>>>>> from numpy/core/src/npymath/npy_math_common.h:4, >>>>>> from numpy/core/src/npymath/npy_math_complex.c.src:31: >>>>>> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >>>>>> location of the previous definition >>>>>> ar: adding 3 object files to build/temp.linux-x86_64-2.4/libnpymath.a >>>>>> running build_ext >>>>>> customize UnixCCompiler >>>>>> customize UnixCCompiler using build_ext >>>>>> customize GnuFCompiler >>>>>> gnu: no Fortran 90 compiler found >>>>>> gnu: no Fortran 90 compiler found >>>>>> customize GnuFCompiler >>>>>> gnu: no Fortran 90 compiler found >>>>>> gnu: no Fortran 90 compiler found >>>>>> customize GnuFCompiler using build_ext >>>>>> building 'numpy.core._sort' extension >>>>>> compiling C sources >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/include >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>>>> gcc: build/src.linux-x86_64-2.4/numpy/core/src/_sortmodule.c >>>>>> In file included from numpy/core/src/private/npy_config.h:4, >>>>>> from numpy/core/src/_sortmodule.c.src:34: >>>>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >>>>>> warning: "HAVE_HYPOT" redefined >>>>>> In file included from /home/sanjey/include/python2.4/Python.h:8, >>>>>> from numpy/core/src/_sortmodule.c.src:30: >>>>>> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >>>>>> location of the previous definition >>>>>> gcc -m32 -pthread -shared >>>>>> build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/_sortmodule.o >>>>>> -Lbuild/temp.linux-x86_64-2.4 -lm -o >>>>>> build/lib.linux-x86_64-2.4/numpy/core/_sort.so >>>>>> building 'numpy.core.multiarray' extension >>>>>> compiling C sources >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> creating build/temp.linux-x86_64-2.4/numpy >>>>>> creating build/temp.linux-x86_64-2.4/numpy/core >>>>>> creating build/temp.linux-x86_64-2.4/numpy/core/src >>>>>> creating build/temp.linux-x86_64-2.4/numpy/core/src/multiarray >>>>>> compile options: '-Inumpy/core/include >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>>>> gcc: numpy/core/src/multiarray/multiarraymodule_onefile.c >>>>>> In file included from numpy/core/src/private/npy_config.h:4, >>>>>> from numpy/core/src/multiarray/common.c:8, >>>>>> from numpy/core/src/multiarray/multiarraymodule_onefile.c:8: >>>>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >>>>>> warning: "HAVE_HYPOT" redefined >>>>>> In file included from /home/sanjey/include/python2.4/Python.h:8, >>>>>> from numpy/core/src/multiarray/common.c:2, >>>>>> from numpy/core/src/multiarray/multiarraymodule_onefile.c:8: >>>>>> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >>>>>> location of the previous definition >>>>>> In file included from numpy/core/src/multiarray/multiarraymodule_onefile.c:26: >>>>>> numpy/core/src/multiarray/methods.c: In function `NpyArg_ParseKeywords': >>>>>> numpy/core/src/multiarray/methods.c:41: warning: passing arg 3 of >>>>>> `PyArg_VaParseTupleAndKeywords' discards qualifiers from pointer >>>>>> target type >>>>>> numpy/core/src/multiarray/flagsobject.c: In function `arrayflags_richcompare': >>>>>> numpy/core/src/multiarray/flagsobject.c:568: warning: 'cmp' might be >>>>>> used uninitialized in this function >>>>>> numpy/core/src/multiarray/multiarraymodule_onefile.c: At top level: >>>>>> numpy/core/include/numpy/npy_3kcompat.h:331: warning: >>>>>> 'simple_capsule_dtor' defined but not used >>>>>> numpy/core/src/multiarray/buffer.c:777: warning: >>>>>> '_descriptor_from_pep3118_format' defined but not used >>>>>> numpy/core/src/multiarray/arraytypes.c.src:93: warning: >>>>>> '_SEQUENCE_MESSAGE' defined but not used >>>>>> numpy/core/src/multiarray/mapping.c:75: warning: '_array_ass_item' >>>>>> defined but not used >>>>>> gcc -m32 -pthread -shared >>>>>> build/temp.linux-x86_64-2.4/numpy/core/src/multiarray/multiarraymodule_onefile.o >>>>>> -Lbuild/temp.linux-x86_64-2.4 -lnpymath -lm -o >>>>>> build/lib.linux-x86_64-2.4/numpy/core/multiarray.so >>>>>> building 'numpy.core.umath' extension >>>>>> compiling C sources >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> creating build/temp.linux-x86_64-2.4/numpy/core/src/umath >>>>>> compile options: '-Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath >>>>>> -Inumpy/core/include >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>>>> gcc: numpy/core/src/umath/umathmodule_onefile.c >>>>>> In file included from numpy/core/src/private/npy_config.h:4, >>>>>> from numpy/core/src/umath/loops.c.src:7, >>>>>> from numpy/core/src/umath/umathmodule_onefile.c:1: >>>>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >>>>>> warning: "HAVE_HYPOT" redefined >>>>>> In file included from /home/sanjey/include/python2.4/Python.h:8, >>>>>> from numpy/core/src/umath/loops.c.src:5, >>>>>> from numpy/core/src/umath/umathmodule_onefile.c:1: >>>>>> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >>>>>> location of the previous definition >>>>>> numpy/core/include/numpy/npy_3kcompat.h:331: warning: >>>>>> 'simple_capsule_dtor' defined but not used >>>>>> numpy/core/src/umath/loops.c.src:1258: warning: >>>>>> 'CLONGDOUBLE_logical_and' defined but not used >>>>>> numpy/core/src/umath/loops.c.src:1258: warning: >>>>>> 'CLONGDOUBLE_logical_or' defined but not used >>>>>> numpy/core/src/umath/loops.c.src:1271: warning: >>>>>> 'CLONGDOUBLE_logical_xor' defined but not used >>>>>> numpy/core/src/umath/loops.c.src:1285: warning: >>>>>> 'CLONGDOUBLE_logical_not' defined but not used >>>>>> numpy/core/src/umath/loops.c.src:1342: warning: >>>>>> 'CLONGDOUBLE_ones_like' defined but not used >>>>>> numpy/core/src/umath/loops.c.src:1399: warning: 'CLONGDOUBLE_maximum' >>>>>> defined but not used >>>>>> numpy/core/src/umath/loops.c.src:1399: warning: 'CLONGDOUBLE_minimum' >>>>>> defined but not used >>>>>> numpy/core/src/umath/loops.c.src:1423: warning: 'CLONGDOUBLE_fmax' >>>>>> defined but not used >>>>>> numpy/core/src/umath/loops.c.src:1423: warning: 'CLONGDOUBLE_fmin' >>>>>> defined but not used >>>>>> gcc -m32 -pthread -shared >>>>>> build/temp.linux-x86_64-2.4/numpy/core/src/umath/umathmodule_onefile.o >>>>>> -Lbuild/temp.linux-x86_64-2.4 -lnpymath -lm -o >>>>>> build/lib.linux-x86_64-2.4/numpy/core/umath.so >>>>>> building 'numpy.core.scalarmath' extension >>>>>> compiling C sources >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> compile options: '-Inumpy/core/include >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>>>> gcc: build/src.linux-x86_64-2.4/numpy/core/src/scalarmathmodule.c >>>>>> numpy/core/include/numpy/npy_3kcompat.h:331: warning: >>>>>> 'simple_capsule_dtor' defined but not used >>>>>> gcc -m32 -pthread -shared >>>>>> build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/scalarmathmodule.o >>>>>> -Lbuild/temp.linux-x86_64-2.4 -lm -o >>>>>> build/lib.linux-x86_64-2.4/numpy/core/scalarmath.so >>>>>> building 'numpy.core.umath_tests' extension >>>>>> compiling C sources >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/umath >>>>>> compile options: '-Inumpy/core/include >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>>>> gcc: build/src.linux-x86_64-2.4/numpy/core/src/umath/umath_tests.c >>>>>> In file included from numpy/core/src/private/npy_config.h:4, >>>>>> from numpy/core/src/umath/umath_tests.c.src:14: >>>>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >>>>>> warning: "HAVE_HYPOT" redefined >>>>>> In file included from /home/sanjey/include/python2.4/Python.h:8, >>>>>> from numpy/core/src/umath/umath_tests.c.src:8: >>>>>> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >>>>>> location of the previous definition >>>>>> numpy/core/include/numpy/npy_3kcompat.h:331: warning: >>>>>> 'simple_capsule_dtor' defined but not used >>>>>> gcc -m32 -pthread -shared >>>>>> build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/umath/umath_tests.o >>>>>> -Lbuild/temp.linux-x86_64-2.4 -o >>>>>> build/lib.linux-x86_64-2.4/numpy/core/umath_tests.so >>>>>> building 'numpy.core.multiarray_tests' extension >>>>>> compiling C sources >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>>>> compile options: '-Inumpy/core/include >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>>>> gcc: build/src.linux-x86_64-2.4/numpy/core/src/multiarray/multiarray_tests.c >>>>>> numpy/core/include/numpy/npy_3kcompat.h:331: warning: >>>>>> 'simple_capsule_dtor' defined but not used >>>>>> gcc -m32 -pthread -shared >>>>>> build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/multiarray/multiarray_tests.o >>>>>> -Lbuild/temp.linux-x86_64-2.4 -o >>>>>> build/lib.linux-x86_64-2.4/numpy/core/multiarray_tests.so >>>>>> building 'numpy.lib._compiled_base' extension >>>>>> compiling C sources >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> creating build/temp.linux-x86_64-2.4/numpy/lib >>>>>> creating build/temp.linux-x86_64-2.4/numpy/lib/src >>>>>> compile options: '-Inumpy/core/include >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>>>> gcc: numpy/lib/src/_compiled_base.c >>>>>> In file included from numpy/core/src/private/npy_config.h:4, >>>>>> from numpy/lib/src/_compiled_base.c:4: >>>>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: >>>>>> warning: "HAVE_HYPOT" redefined >>>>>> In file included from /home/sanjey/include/python2.4/Python.h:8, >>>>>> from numpy/lib/src/_compiled_base.c:1: >>>>>> /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the >>>>>> location of the previous definition >>>>>> gcc -m32 -pthread -shared >>>>>> build/temp.linux-x86_64-2.4/numpy/lib/src/_compiled_base.o >>>>>> -Lbuild/temp.linux-x86_64-2.4 -o >>>>>> build/lib.linux-x86_64-2.4/numpy/lib/_compiled_base.so >>>>>> building 'numpy.numarray._capi' extension >>>>>> compiling C sources >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> creating build/temp.linux-x86_64-2.4/numpy/numarray >>>>>> compile options: '-Inumpy/core/include >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>>>> gcc: numpy/numarray/_capi.c >>>>>> numpy/core/include/numpy/npy_3kcompat.h:331: warning: >>>>>> 'simple_capsule_dtor' defined but not used >>>>>> gcc -m32 -pthread -shared >>>>>> build/temp.linux-x86_64-2.4/numpy/numarray/_capi.o >>>>>> -Lbuild/temp.linux-x86_64-2.4 -o >>>>>> build/lib.linux-x86_64-2.4/numpy/numarray/_capi.so >>>>>> building 'numpy.fft.fftpack_lite' extension >>>>>> compiling C sources >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> creating build/temp.linux-x86_64-2.4/numpy/fft >>>>>> compile options: '-Inumpy/core/include >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>>>> gcc: numpy/fft/fftpack_litemodule.c >>>>>> gcc: numpy/fft/fftpack.c >>>>>> gcc -m32 -pthread -shared >>>>>> build/temp.linux-x86_64-2.4/numpy/fft/fftpack_litemodule.o >>>>>> build/temp.linux-x86_64-2.4/numpy/fft/fftpack.o >>>>>> -Lbuild/temp.linux-x86_64-2.4 -o >>>>>> build/lib.linux-x86_64-2.4/numpy/fft/fftpack_lite.so >>>>>> building 'numpy.linalg.lapack_lite' extension >>>>>> compiling C sources >>>>>> C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g >>>>>> -O3 -Wall -Wstrict-prototypes -fPIC >>>>>> >>>>>> creating build/temp.linux-x86_64-2.4/numpy/linalg >>>>>> compile options: '-DNO_ATLAS_INFO=1 -Inumpy/core/include >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy >>>>>> -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core >>>>>> -Inumpy/core/src/npymath -Inumpy/core/src/multiarray >>>>>> -Inumpy/core/src/umath -Inumpy/core/include >>>>>> -I/home/sanjey/include/python2.4 >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray >>>>>> -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' >>>>>> gcc: numpy/linalg/lapack_litemodule.c >>>>>> gcc: numpy/linalg/python_xerbla.c >>>>>> /usr/bin/g77 -g -Wall -g -Wall -shared >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o -L/usr/lib >>>>>> -Lbuild/temp.linux-x86_64-2.4 -llapack -lblas -lg2c -o >>>>>> build/lib.linux-x86_64-2.4/numpy/linalg/lapack_lite.so >>>>>> /usr/bin/ld: skipping incompatible /usr/lib/liblapack.so when >>>>>> searching for -llapack >>>>>> /usr/bin/ld: skipping incompatible /usr/lib/liblapack.a when searching >>>>>> for -llapack >>>>>> /usr/bin/ld: skipping incompatible /usr/lib/libblas.so when searching for -lblas >>>>>> /usr/bin/ld: skipping incompatible /usr/lib/libblas.a when searching for -lblas >>>>>> /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm >>>>>> /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm >>>>>> /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm >>>>>> /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm >>>>>> /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 >>>>>> /usr/bin/ld: warning: i386 architecture of input file >>>>>> `build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o' is >>>>>> incompatible with i386:x86-64 output >>>>>> /usr/bin/ld: warning: i386 architecture of input file >>>>>> `build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o' is >>>>>> incompatible with i386:x86-64 output >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xae): >>>>>> In function `lapack_lite_dgeev': >>>>>> numpy/linalg/lapack_litemodule.c:155: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfe):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x143):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a3):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1f4):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x272):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31c):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ae):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x60e):numpy/linalg/lapack_litemodule.c:171: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6aa): >>>>>> In function `lapack_lite_dsyevd': >>>>>> numpy/linalg/lapack_litemodule.c:241: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6f4):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x739):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x797):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x7ef):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x869):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x8ff):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xa7c):numpy/linalg/lapack_litemodule.c:254: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb34): >>>>>> In function `lapack_lite_zheevd': >>>>>> numpy/linalg/lapack_litemodule.c:327: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb7e):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xbc3):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc23):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc74):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xce9):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xd85):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xe77):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfb9):numpy/linalg/lapack_litemodule.c:341: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1087): >>>>>> In function `lapack_lite_dgelsd': >>>>>> numpy/linalg/lapack_litemodule.c:365: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x10d7):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x111c):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x117d):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x11cf):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1252):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x12e8):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x13d7):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1534):numpy/linalg/lapack_litemodule.c:380: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15af): >>>>>> In function `lapack_lite_dgesv': >>>>>> numpy/linalg/lapack_litemodule.c:398: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15f9):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x163e):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1692):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x16e7):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x175e):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x189a):numpy/linalg/lapack_litemodule.c:407: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1967): >>>>>> In function `lapack_lite_dgesdd': >>>>>> numpy/linalg/lapack_litemodule.c:430: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19b7):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19fc):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a5d):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1aaf):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1b32):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1bc8):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d15):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d76):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1efb):numpy/linalg/lapack_litemodule.c:472: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x202b): >>>>>> In function `lapack_lite_dgetrf': >>>>>> numpy/linalg/lapack_litemodule.c:488: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2063):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20ae):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20fe):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2155):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2235):numpy/linalg/lapack_litemodule.c:496: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22b4): >>>>>> In function `lapack_lite_dpotrf': >>>>>> numpy/linalg/lapack_litemodule.c:510: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22e9):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x232d):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x238f):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x240a):numpy/linalg/lapack_litemodule.c:516: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24af): >>>>>> In function `lapack_lite_dgeqrf': >>>>>> numpy/linalg/lapack_litemodule.c:529: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24f9):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x253e):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2598):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x25ef):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2669):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x27a7):numpy/linalg/lapack_litemodule.c:540: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2839): >>>>>> In function `lapack_lite_dorgqr': >>>>>> numpy/linalg/lapack_litemodule.c:555: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2883):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x28c8):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2927):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x297f):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x29f9):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2afa):numpy/linalg/lapack_litemodule.c:562: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2bbb): >>>>>> In function `lapack_lite_zgeev': >>>>>> numpy/linalg/lapack_litemodule.c:585: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c0b):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c50):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2cb0):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d04):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d82):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2e2c):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2f6b):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2fb9):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x311b):numpy/linalg/lapack_litemodule.c:601: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31f4): >>>>>> In function `lapack_lite_zgelsd': >>>>>> numpy/linalg/lapack_litemodule.c:626: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3244):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3289):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x32ef):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3340):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x33c8):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3471):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35b1):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35ff):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x376f):numpy/linalg/lapack_litemodule.c:641: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x37ef): >>>>>> In function `lapack_lite_zgesv': >>>>>> numpy/linalg/lapack_litemodule.c:658: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3839):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x387e):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x38d2):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3927):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x399e):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3ada):numpy/linalg/lapack_litemodule.c:667: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bae): >>>>>> In function `lapack_lite_zgesdd': >>>>>> numpy/linalg/lapack_litemodule.c:691: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bfe):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3c43):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cab):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cff):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3d82):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3e2c):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3f70):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3fbe):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4195):numpy/linalg/lapack_litemodule.c:708: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x41ab):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x422b): >>>>>> In function `lapack_lite_zgetrf': >>>>>> numpy/linalg/lapack_litemodule.c:724: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4263):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42ae):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42fe):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4355):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4435):numpy/linalg/lapack_litemodule.c:732: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44b4): >>>>>> In function `lapack_lite_zpotrf': >>>>>> numpy/linalg/lapack_litemodule.c:746: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44e9):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x452d):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x458f):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460a):numpy/linalg/lapack_litemodule.c:751: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46af): >>>>>> In function `lapack_lite_zgeqrf': >>>>>> numpy/linalg/lapack_litemodule.c:764: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46f9):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x473e):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4798):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x47ef):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4869):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x49a7):numpy/linalg/lapack_litemodule.c:774: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a39): >>>>>> In function `lapack_lite_zungqr': >>>>>> numpy/linalg/lapack_litemodule.c:787: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a83):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ac8):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b27):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b7f):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4bf9):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4cfa):numpy/linalg/lapack_litemodule.c:797: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d58): >>>>>> In function `initlapack_lite': >>>>>> numpy/linalg/lapack_litemodule.c:858: undefined reference to `Py_InitModule4' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d71): >>>>>> In function `initlapack_lite': >>>>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1190: >>>>>> undefined reference to `PyImport_ImportModule' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d8d):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1197: >>>>>> undefined reference to `PyObject_GetAttrString' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4da6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1212: >>>>>> undefined reference to `PyCObject_Type' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4db5):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: >>>>>> undefined reference to `PyExc_RuntimeError' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dc9):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: >>>>>> undefined reference to `PyErr_SetString' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dd7): >>>>>> In function `initlapack_lite': >>>>>> numpy/linalg/lapack_litemodule.c:865: undefined reference to `PyErr_Print' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ddd):numpy/linalg/lapack_litemodule.c:865: >>>>>> undefined reference to `PyExc_ImportError' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4df1):numpy/linalg/lapack_litemodule.c:865: >>>>>> undefined reference to `PyErr_SetString' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e18): >>>>>> In function `initlapack_lite': >>>>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1194: >>>>>> undefined reference to `PyExc_ImportError' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e26):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: >>>>>> undefined reference to `PyErr_SetString' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e46):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1217: >>>>>> undefined reference to `PyCObject_AsVoidPtr' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e88):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: >>>>>> undefined reference to `PyExc_RuntimeError' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e96):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ea1):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: >>>>>> undefined reference to `PyExc_RuntimeError' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4eb6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1200: >>>>>> undefined reference to `PyExc_AttributeError' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f24):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: >>>>>> undefined reference to `PyExc_RuntimeError' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f2e):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f46): >>>>>> In function `initlapack_lite': >>>>>> numpy/linalg/lapack_litemodule.c:866: undefined reference to `PyModule_GetDict' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f66):numpy/linalg/lapack_litemodule.c:867: >>>>>> undefined reference to `PyErr_NewException' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f82):numpy/linalg/lapack_litemodule.c:868: >>>>>> undefined reference to `PyDict_SetItemString' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x70): >>>>>> In function `xerbla_': >>>>>> numpy/linalg/python_xerbla.c:35: undefined reference to `PyExc_ValueError' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x7e):numpy/linalg/python_xerbla.c:35: >>>>>> undefined reference to `PyErr_SetString' >>>>>> collect2: ld returned 1 exit status >>>>>> /usr/bin/ld: skipping incompatible /usr/lib/liblapack.so when >>>>>> searching for -llapack >>>>>> /usr/bin/ld: skipping incompatible /usr/lib/liblapack.a when searching >>>>>> for -llapack >>>>>> /usr/bin/ld: skipping incompatible /usr/lib/libblas.so when searching for -lblas >>>>>> /usr/bin/ld: skipping incompatible /usr/lib/libblas.a when searching for -lblas >>>>>> /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm >>>>>> /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm >>>>>> /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm >>>>>> /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm >>>>>> /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 >>>>>> /usr/bin/ld: warning: i386 architecture of input file >>>>>> `build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o' is >>>>>> incompatible with i386:x86-64 output >>>>>> /usr/bin/ld: warning: i386 architecture of input file >>>>>> `build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o' is >>>>>> incompatible with i386:x86-64 output >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xae): >>>>>> In function `lapack_lite_dgeev': >>>>>> numpy/linalg/lapack_litemodule.c:155: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfe):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x143):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a3):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1f4):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x272):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31c):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ae):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x60e):numpy/linalg/lapack_litemodule.c:171: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6aa): >>>>>> In function `lapack_lite_dsyevd': >>>>>> numpy/linalg/lapack_litemodule.c:241: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6f4):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x739):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x797):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x7ef):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x869):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x8ff):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xa7c):numpy/linalg/lapack_litemodule.c:254: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb34): >>>>>> In function `lapack_lite_zheevd': >>>>>> numpy/linalg/lapack_litemodule.c:327: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb7e):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xbc3):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc23):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc74):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xce9):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xd85):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xe77):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfb9):numpy/linalg/lapack_litemodule.c:341: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1087): >>>>>> In function `lapack_lite_dgelsd': >>>>>> numpy/linalg/lapack_litemodule.c:365: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x10d7):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x111c):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x117d):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x11cf):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1252):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x12e8):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x13d7):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1534):numpy/linalg/lapack_litemodule.c:380: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15af): >>>>>> In function `lapack_lite_dgesv': >>>>>> numpy/linalg/lapack_litemodule.c:398: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15f9):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x163e):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1692):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x16e7):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x175e):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x189a):numpy/linalg/lapack_litemodule.c:407: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1967): >>>>>> In function `lapack_lite_dgesdd': >>>>>> numpy/linalg/lapack_litemodule.c:430: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19b7):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19fc):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a5d):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1aaf):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1b32):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1bc8):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d15):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d76):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1efb):numpy/linalg/lapack_litemodule.c:472: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x202b): >>>>>> In function `lapack_lite_dgetrf': >>>>>> numpy/linalg/lapack_litemodule.c:488: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2063):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20ae):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20fe):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2155):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2235):numpy/linalg/lapack_litemodule.c:496: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22b4): >>>>>> In function `lapack_lite_dpotrf': >>>>>> numpy/linalg/lapack_litemodule.c:510: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22e9):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x232d):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x238f):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x240a):numpy/linalg/lapack_litemodule.c:516: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24af): >>>>>> In function `lapack_lite_dgeqrf': >>>>>> numpy/linalg/lapack_litemodule.c:529: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24f9):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x253e):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2598):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x25ef):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2669):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x27a7):numpy/linalg/lapack_litemodule.c:540: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2839): >>>>>> In function `lapack_lite_dorgqr': >>>>>> numpy/linalg/lapack_litemodule.c:555: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2883):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x28c8):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2927):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x297f):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x29f9):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2afa):numpy/linalg/lapack_litemodule.c:562: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2bbb): >>>>>> In function `lapack_lite_zgeev': >>>>>> numpy/linalg/lapack_litemodule.c:585: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c0b):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c50):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2cb0):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d04):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d82):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2e2c):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2f6b):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2fb9):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x311b):numpy/linalg/lapack_litemodule.c:601: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31f4): >>>>>> In function `lapack_lite_zgelsd': >>>>>> numpy/linalg/lapack_litemodule.c:626: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3244):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3289):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x32ef):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3340):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x33c8):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3471):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35b1):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35ff):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x376f):numpy/linalg/lapack_litemodule.c:641: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x37ef): >>>>>> In function `lapack_lite_zgesv': >>>>>> numpy/linalg/lapack_litemodule.c:658: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3839):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x387e):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x38d2):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3927):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x399e):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3ada):numpy/linalg/lapack_litemodule.c:667: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bae): >>>>>> In function `lapack_lite_zgesdd': >>>>>> numpy/linalg/lapack_litemodule.c:691: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bfe):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3c43):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cab):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cff):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3d82):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3e2c):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3f70):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3fbe):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4195):numpy/linalg/lapack_litemodule.c:708: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x41ab):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x422b): >>>>>> In function `lapack_lite_zgetrf': >>>>>> numpy/linalg/lapack_litemodule.c:724: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4263):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42ae):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42fe):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4355):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4435):numpy/linalg/lapack_litemodule.c:732: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44b4): >>>>>> In function `lapack_lite_zpotrf': >>>>>> numpy/linalg/lapack_litemodule.c:746: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44e9):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x452d):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x458f):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460a):numpy/linalg/lapack_litemodule.c:751: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46af): >>>>>> In function `lapack_lite_zgeqrf': >>>>>> numpy/linalg/lapack_litemodule.c:764: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46f9):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x473e):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4798):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x47ef):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4869):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x49a7):numpy/linalg/lapack_litemodule.c:774: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a39): >>>>>> In function `lapack_lite_zungqr': >>>>>> numpy/linalg/lapack_litemodule.c:787: undefined reference to `PyArg_ParseTuple' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a83):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ac8):numpy/linalg/lapack_litemodule.c:114: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b27):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b7f):numpy/linalg/lapack_litemodule.c:120: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4bf9):numpy/linalg/lapack_litemodule.c:103: >>>>>> undefined reference to `PyType_IsSubtype' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4cfa):numpy/linalg/lapack_litemodule.c:797: >>>>>> undefined reference to `Py_BuildValue' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d58): >>>>>> In function `initlapack_lite': >>>>>> numpy/linalg/lapack_litemodule.c:858: undefined reference to `Py_InitModule4' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d71): >>>>>> In function `initlapack_lite': >>>>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1190: >>>>>> undefined reference to `PyImport_ImportModule' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d8d):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1197: >>>>>> undefined reference to `PyObject_GetAttrString' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4da6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1212: >>>>>> undefined reference to `PyCObject_Type' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4db5):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: >>>>>> undefined reference to `PyExc_RuntimeError' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dc9):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: >>>>>> undefined reference to `PyErr_SetString' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dd7): >>>>>> In function `initlapack_lite': >>>>>> numpy/linalg/lapack_litemodule.c:865: undefined reference to `PyErr_Print' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ddd):numpy/linalg/lapack_litemodule.c:865: >>>>>> undefined reference to `PyExc_ImportError' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4df1):numpy/linalg/lapack_litemodule.c:865: >>>>>> undefined reference to `PyErr_SetString' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e18): >>>>>> In function `initlapack_lite': >>>>>> build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1194: >>>>>> undefined reference to `PyExc_ImportError' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e26):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: >>>>>> undefined reference to `PyErr_SetString' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e46):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1217: >>>>>> undefined reference to `PyCObject_AsVoidPtr' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e88):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: >>>>>> undefined reference to `PyExc_RuntimeError' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e96):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ea1):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: >>>>>> undefined reference to `PyExc_RuntimeError' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4eb6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1200: >>>>>> undefined reference to `PyExc_AttributeError' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f24):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: >>>>>> undefined reference to `PyExc_RuntimeError' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f2e):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: >>>>>> undefined reference to `PyErr_Format' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f46): >>>>>> In function `initlapack_lite': >>>>>> numpy/linalg/lapack_litemodule.c:866: undefined reference to `PyModule_GetDict' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f66):numpy/linalg/lapack_litemodule.c:867: >>>>>> undefined reference to `PyErr_NewException' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f82):numpy/linalg/lapack_litemodule.c:868: >>>>>> undefined reference to `PyDict_SetItemString' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x70): >>>>>> In function `xerbla_': >>>>>> numpy/linalg/python_xerbla.c:35: undefined reference to `PyExc_ValueError' >>>>>> build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x7e):numpy/linalg/python_xerbla.c:35: >>>>>> undefined reference to `PyErr_SetString' >>>>>> collect2: ld returned 1 exit status >>>>>> _______________________________________________ >>>>>> NumPy-Discussion mailing list >>>>>> NumPy-Discussion at scipy.org >>>>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion >>>>> Since you are using the -m32 flag, do you have *all* the 32-bit >>>>> libraries/headers installed (especially Python 2.4 ones) what appears to >>>>> be a x86_64 operating system? >>>>> >>>>> >>>>> Bruce >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> NumPy-Discussion mailing list >>>>> NumPy-Discussion at scipy.org >>>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion >>>>> >>>> _______________________________________________ >>>> NumPy-Discussion mailing list >>>> NumPy-Discussion at scipy.org >>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion >>> The errors are related to numpy not being able to find the Python 2.4 >>> 32-bit headers. >>> >>> You have to had built Python 2.4 as 32-bit and you need to add the >>> appropriate path to the appropriate Python 2.4 32-bit header files when >>> running 32-bit Python 2.4. >>> >>> >>> Bruce >>> _______________________________________________ >> > I can not help you further. > > What I would have done is create a 32-bit virtual machine and worked > with that. > > > Bruce > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > From Chris.Barker at noaa.gov Fri Oct 15 14:55:27 2010 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Fri, 15 Oct 2010 11:55:27 -0700 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: References: <4CB4C99A.8040906@noaa.gov> <4CB5E208.5030909@noaa.gov> Message-ID: <4CB8A39F.4090601@noaa.gov> On 10/15/10 10:54 AM, Russell E. Owen wrote: > I have a 10.4 Intel machine I keep around > for the sole purpose of building backward-compatible binary installers > for PIL and matplotlib. If help is still wanted I'm happy to build numpy > as well. I'll let Ralf and Friedrich and Vincent respond, but that sounds like a great option. And thanks for PIL and MPL, too! -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 Chris.Barker at noaa.gov From vincent at vincentdavis.net Fri Oct 15 15:39:58 2010 From: vincent at vincentdavis.net (Vincent Davis) Date: Fri, 15 Oct 2010 13:39:58 -0600 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: <4CB8A39F.4090601@noaa.gov> References: <4CB4C99A.8040906@noaa.gov> <4CB5E208.5030909@noaa.gov> <4CB8A39F.4090601@noaa.gov> Message-ID: On Fri, Oct 15, 2010 at 12:55 PM, Christopher Barker wrote: > On 10/15/10 10:54 AM, Russell E. Owen wrote: >> I have a 10.4 Intel machine I keep around >> for the sole purpose of building backward-compatible binary installers >> for PIL and matplotlib. If help is still wanted I'm happy to build numpy >> as well. > > I'll let Ralf and Friedrich and Vincent respond, but that sounds like a > great option. I agree Russell if you would like to help with this, great. For Friedrich and myself we are interested in 10.5 and 10.6 first Christopher, you mentioned that you might have a 10.4 dvd intel that you could share, I/you can contact me off list. I could not find one. Christopher we will see about getting you a link to download it. am working on getting 10.6 installed and repartitioning the drive so no easy access to the files right now. Vincent > > And thanks for PIL and MPL, too! > > -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 > > Chris.Barker at noaa.gov > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -- Thanks Vincent Davis 720-301-3003 From friedrichromstedt at gmail.com Fri Oct 15 15:53:10 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Fri, 15 Oct 2010 21:53:10 +0200 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: <4CB8A39F.4090601@noaa.gov> References: <4CB4C99A.8040906@noaa.gov> <4CB5E208.5030909@noaa.gov> <4CB8A39F.4090601@noaa.gov> Message-ID: 2010/10/15 Christopher Barker : > On 10/15/10 10:54 AM, Russell E. Owen wrote: >> I have a 10.4 Intel machine I keep around >> for the sole purpose of building backward-compatible binary installers >> for PIL and matplotlib. If help is still wanted I'm happy to build numpy >> as well. > > I'll let Ralf and Friedrich and Vincent respond, but that sounds like a > great option. Thanks for waiting for us! Here is our status: Vincent is currently setting up the machine with a crucial carbon-copy-clone, reformat, and ccc back. This is because we had only around 50 MB left in the end on the partition, and according to Vincent enlarging the partition wasn't possible for some reason be both don't know. Well, technicalities. We're having to set up py2.6 & py2.7, what shouldn't be an issue, and will have to compile mpl for both of them since the build process should not change Python version while its running, i.e., when building the py2.6 dmg, the docs will be built using py2.6, and when py2.5 dmg, then py2.5, that's what I mean. Also LaTeX is needed, Russell, as you might know. MacTeX-2010 is about 1.6 GB download. Here come now the interesting facts: 1) Some tests of numpy failed in 2.0.0.dev. When the machine is running again I can send the logs. All some strange-looking typecode string tests with dtype('...') iirc. 2) I noticed that the paver at some late point tried to switch from py2.5 to py2.6, what is rather strange to me. I must have a look where precisely the build failed for this reason. py2.6 is the DEFAULT_PYTHON_VERSION (iirc) in pavement.py, and changing it to 2.5 fixed it. Strange. 3) I found no v1.5.1 tag yet (yesterday). Will the HEAD become 1.5.1? Here a comparison of our two systems (Russell's and our's): * We will have 10.4 (?), 10.5, 10.6 available on the same machine with vpn access for everyone who wants a cert. * But we need time to set it up properly. We're unwilling to do half-baken things, so I agree that Vincent it installing 10.6 right now (I just got the message), but time is rare this weekend. * So my suggestion would be, Russell, if you could do the build more easily then we can, just feel free, I was hoping Vincent and me would get the credits though ;-), but first it must succeed on time. Vincent, what do you think? * For future, I would prefer Vincent's machine. We have dyndns and the machine can be dedicated for building this stuff. If we get a 10.4, we have 10.4 to 10.6 all together on a single place, and we could do with it whatever we feel like. Friedrich > And thanks for PIL and MPL, too! Nice to meet you. Btw, I ran into some trouble when compiling mpl on 10.5, different trouble than on 10.6, I'm planning to write it up, it's solved, because it would be nice to have a *working* instruction online (different from make.osx, which I dislike for its magic approach). Friedrich From friedrichromstedt at gmail.com Fri Oct 15 16:01:58 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Fri, 15 Oct 2010 22:01:58 +0200 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: <4CB87990.5040406@noaa.gov> References: <4CB4C99A.8040906@noaa.gov> <4CB5E208.5030909@noaa.gov> <4CB72D8F.90308@noaa.gov> <4CB87990.5040406@noaa.gov> Message-ID: 2010/10/15 Christopher Barker : >> [15.10.10 05:36:01] Friedrich Romstedt: In >> Users/Shared/GitHub/project-numpy/owner-numpy/numpy-deployment/tools/numpy-macosx-installer >> [15.10.10 05:36:18] Friedrich Romstedt: -rw-r--r--@ 1 Friedrich ?wheel >> ? 8190646 Oct 14 21:33 numpy-2.0.0.dev-py2.5-python.org.dmg > > Can I find that somewhere to download and test? I can upload to my web server friedrichromstedt.org, and I would first test it on a 10.5 laptop from my colleague. "Double holds better", as we say in Germany :) I will also test on 10.6 on my own laptop. Maybe we should put the test results in a new thread, to not mix them with the build stuff in this thread here? Pro: No mixing, Con: No context. Friedrich From friedrichromstedt at gmail.com Fri Oct 15 16:22:49 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Fri, 15 Oct 2010 22:22:49 +0200 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: References: <4CB4C99A.8040906@noaa.gov> <4CB5E208.5030909@noaa.gov> <4CB72D8F.90308@noaa.gov> <4CB87990.5040406@noaa.gov> Message-ID: One more question: Do we support any external library in the official binaries? I've heard the names MKL and BLAS, LAPACK, ... all stuff I don't know really tbh, but do we have to install them? On the http://projects.scipy.org/numpy/wiki/MakingReleases page, Cython is mentioned, I've seen no call to cython while compiling, it that correct? (Cython is installed anyway) Friedrich From rowen at uw.edu Fri Oct 15 17:44:12 2010 From: rowen at uw.edu (Russell E. Owen) Date: Fri, 15 Oct 2010 14:44:12 -0700 Subject: [Numpy-discussion] help from OS X 10.5 users wanted References: <4CB4C99A.8040906@noaa.gov> <4CB5E208.5030909@noaa.gov> <4CB8A39F.4090601@noaa.gov> Message-ID: In article , Friedrich Romstedt wrote: > 2010/10/15 Christopher Barker : > > On 10/15/10 10:54 AM, Russell E. Owen wrote: > >> I have a 10.4 Intel machine I keep around > >> for the sole purpose of building backward-compatible binary installers > >> for PIL and matplotlib. If help is still wanted I'm happy to build numpy > >> as well. > > > > I'll let Ralf and Friedrich and Vincent respond, but that sounds like a > > great option. > > Thanks for waiting for us! Here is our status: > > Vincent is currently setting up the machine with a crucial > carbon-copy-clone, reformat, and ccc back. This is because we had > only around 50 MB left in the end on the partition, and according to > Vincent enlarging the partition wasn't possible for some reason be > both don't know. Well, technicalities. > > We're having to set up py2.6 & py2.7, what shouldn't be an issue, and > will have to compile mpl for both of them since the build process > should not change Python version while its running, i.e., when > building the py2.6 dmg, the docs will be built using py2.6, and when > py2.5 dmg, then py2.5, that's what I mean. > > Also LaTeX is needed, Russell, as you might know. MacTeX-2010 is > about 1.6 GB download. Interesting. I had no idea but I can install that. > Here come now the interesting facts: > > 1) Some tests of numpy failed in 2.0.0.dev. When the machine is > running again I can send the logs. All some strange-looking typecode > string tests with dtype('...') iirc. I have no idea what to make of this. > 2) I noticed that the paver at some late point tried to switch from > py2.5 to py2.6, what is rather strange to me. I must have a look > where precisely the build failed for this reason. py2.6 is the > DEFAULT_PYTHON_VERSION (iirc) in pavement.py, and changing it to 2.5 > fixed it. Strange. > > 3) I found no v1.5.1 tag yet (yesterday). Will the HEAD become 1.5.1? > > Here a comparison of our two systems (Russell's and our's): > > * We will have 10.4 (?), 10.5, 10.6 available on the same machine > with vpn access for everyone who wants a cert. Mine has 10.4 and 10.5 available (via an old two-partition external hard drive dedicated to building python packages). It has no public access and I'd prefer to keep it that way. It's also off most of the time and there are times when I will not have it at all (since I have it on long-term loan). > * But we need time to set it up properly. We're unwilling to do > half-baken things, so I agree that Vincent it installing 10.6 right > now (I just got the message), but time is rare this weekend. > > * So my suggestion would be, Russell, if you could do the build more > easily then we can, just feel free, I was hoping Vincent and me would > get the credits though ;-), but first it must succeed on time. > Vincent, what do you think? > > * For future, I would prefer Vincent's machine. We have dyndns and > the machine can be dedicated for building this stuff. If we get a > 10.4, we have 10.4 to 10.6 all together on a single place, and we > could do with it whatever we feel like. >... It sounds like you have things under control. I propose to leave it to you. It sounds like you are doing a great and very thorough job. If you need a confirming build for some reason I'm happy to do that. Are you also building matplotlib then? If you are then please install ActiveState Tcl/Tk so the matplotlib will be compatible with 3rd party Tcl/Tk (as well as Apple's built-in Tcl/Tk). The best version for python.org's Python 2.6 is 8.4.19. I'm betting the same is true of the 32-bit Python 2.7. I'm not sure what version of Tcl/Tk the 64-bit version of Python 2.7 was built against, but that's the one to match. I'm hoping to build PIL and matplotlib for Python 2.7 in the next month or so, depending if I can figure out how to do it. (The 32-bit version should be easy; it's the 64-bit version I'm worried about). -- Russell From friedrichromstedt at gmail.com Fri Oct 15 19:56:18 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Sat, 16 Oct 2010 01:56:18 +0200 Subject: [Numpy-discussion] Tesing of the numpy 1.5.1 dmgs Message-ID: Hi, I just poked around the newly created files, and here they are: The dmg: http://friedrichromstedt.org/numpy/Release/10-10-16/01-numpy-2.0.0.dev-py2.5-python.org.dmg (just to be sure: PRELIMINARY) The test file of the numpy 2.0.0 on the build machine: http://friedrichromstedt.org/numpy/Tests/Vincent-i386-Core2Duo/py2.5/Logs/10-10-15/test.log Test result file on another ppc PowerBook G4: http://friedrichromstedt.org/numpy/Tests/Rick-ppc-G4/py2.5/10-10-16/01-10.5-test.log Notice that both tests FAILED, but not very strongly. The errors are different on both machines. Some things to note: 1) The docs still say they are for 1.5.0rc1. Might be my mistake, but I remember the docs being rebuilt completely when it made the dmg. 2) The installer has no customised background image. (Intended?). The dmg anyway has very nice layout, it works. Friedrich From Chris.Barker at noaa.gov Fri Oct 15 20:28:19 2010 From: Chris.Barker at noaa.gov (Chris Barker) Date: Fri, 15 Oct 2010 17:28:19 -0700 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: References: <4CB4C99A.8040906@noaa.gov> <4CB5E208.5030909@noaa.gov> <4CB72D8F.90308@noaa.gov> <4CB87990.5040406@noaa.gov> Message-ID: <4CB8F1A3.9060606@noaa.gov> On 10/15/10 1:22 PM, Friedrich Romstedt wrote: > One more question: Do we support any external library in the official > binaries? I've heard the names MKL and BLAS, LAPACK, ... all stuff I > don't know really tbh, but do we have to install them? > OS-X ships with LAPACK (I think it's based on ATLAS), and numpy used to be set up to link to that -- It probably still is, so no need for any external libs. -Chris From ralf.gommers at googlemail.com Fri Oct 15 22:26:23 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Sat, 16 Oct 2010 10:26:23 +0800 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: References: <4CB4C99A.8040906@noaa.gov> <4CB5E208.5030909@noaa.gov> <4CB72D8F.90308@noaa.gov> <4CB87990.5040406@noaa.gov> Message-ID: On Sat, Oct 16, 2010 at 4:22 AM, Friedrich Romstedt < friedrichromstedt at gmail.com> wrote: > One more question: Do we support any external library in the official > binaries? I've heard the names MKL and BLAS, LAPACK, ... all stuff I > don't know really tbh, but do we have to install them? > > No, OS X ships with the Accelerate framework (which contains BLAS and LAPACK), that's all that's needed. > On the http://projects.scipy.org/numpy/wiki/MakingReleases page, > Cython is mentioned, I've seen no call to cython while compiling, it > that correct? (Cython is installed anyway) > Cython is not needed. The C sources generated from Cython code are checked into the repo, so you only need Cython if you want to work on actual Cython code. I'll clarify that in the doc. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Fri Oct 15 22:48:58 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Sat, 16 Oct 2010 10:48:58 +0800 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: References: <4CB4C99A.8040906@noaa.gov> <4CB5E208.5030909@noaa.gov> <4CB8A39F.4090601@noaa.gov> Message-ID: On Sat, Oct 16, 2010 at 3:53 AM, Friedrich Romstedt < friedrichromstedt at gmail.com> wrote: > 2010/10/15 Christopher Barker : > > On 10/15/10 10:54 AM, Russell E. Owen wrote: > >> I have a 10.4 Intel machine I keep around > >> for the sole purpose of building backward-compatible binary installers > >> for PIL and matplotlib. If help is still wanted I'm happy to build numpy > >> as well. > > > > I'll let Ralf and Friedrich and Vincent respond, but that sounds like a > > great option. > > Thanks for waiting for us! Here is our status: > > Vincent is currently setting up the machine with a crucial > carbon-copy-clone, reformat, and ccc back. This is because we had > only around 50 MB left in the end on the partition, and according to > Vincent enlarging the partition wasn't possible for some reason be > both don't know. Well, technicalities. > > We're having to set up py2.6 & py2.7, what shouldn't be an issue, and > will have to compile mpl for both of them since the build process > should not change Python version while its running, i.e., when > building the py2.6 dmg, the docs will be built using py2.6, and when > py2.5 dmg, then py2.5, that's what I mean. > > Also LaTeX is needed, Russell, as you might know. MacTeX-2010 is > about 1.6 GB download. > > Here come now the interesting facts: > > 1) Some tests of numpy failed in 2.0.0.dev. When the machine is > running again I can send the logs. All some strange-looking typecode > string tests with dtype('...') iirc. > Not too surprising, that's the master branch which is not tested much on py2.5 / OS X. > > 2) I noticed that the paver at some late point tried to switch from > py2.5 to py2.6, what is rather strange to me. I must have a look > where precisely the build failed for this reason. py2.6 is the > DEFAULT_PYTHON_VERSION (iirc) in pavement.py, and changing it to 2.5 > fixed it. Strange. > Did you have the the bootstrap virtualenv set up and active? The following should work from a clean checkout: paver bootstrap source bootstrap/bin/activate python setupsconsegg.py install paver dmg -p 2.5 If that fails it's a bug. The first build is with python 2.6 if that's your default python, it's needed to make sure the docs are built from the exact same commit as the binary itself. > > 3) I found no v1.5.1 tag yet (yesterday). Will the HEAD become 1.5.1? > You mean the master branch? HEAD just points at the most recent commit on your currently active branch. In that case no, 1.5.1 will be tagged from the maintenance/1.5.x branch. The tag v1.5.1rc1 or v1.5.1 do not exist yet, tags are only created once the actual release takes place. So tag v1.5.1rc1 should appear tomorrow. Cheers, Ralf > Here a comparison of our two systems (Russell's and our's): > > * We will have 10.4 (?), 10.5, 10.6 available on the same machine > with vpn access for everyone who wants a cert. > > * But we need time to set it up properly. We're unwilling to do > half-baken things, so I agree that Vincent it installing 10.6 right > now (I just got the message), but time is rare this weekend. > > * So my suggestion would be, Russell, if you could do the build more > easily then we can, just feel free, I was hoping Vincent and me would > get the credits though ;-), but first it must succeed on time. > Vincent, what do you think? > > * For future, I would prefer Vincent's machine. We have dyndns and > the machine can be dedicated for building this stuff. If we get a > 10.4, we have 10.4 to 10.6 all together on a single place, and we > could do with it whatever we feel like. > > Friedrich > > > And thanks for PIL and MPL, too! > > Nice to meet you. Btw, I ran into some trouble when compiling mpl on > 10.5, different trouble than on 10.6, I'm planning to write it up, > it's solved, because it would be nice to have a *working* instruction > online (different from make.osx, which I dislike for its magic > approach). > > Friedrich > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Fri Oct 15 23:06:10 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Sat, 16 Oct 2010 11:06:10 +0800 Subject: [Numpy-discussion] Tesing of the numpy 1.5.1 dmgs In-Reply-To: References: Message-ID: On Sat, Oct 16, 2010 at 7:56 AM, Friedrich Romstedt < friedrichromstedt at gmail.com> wrote: > Hi, > > I just poked around the newly created files, and here they are: > > The dmg: > > http://friedrichromstedt.org/numpy/Release/10-10-16/01-numpy-2.0.0.dev-py2.5-python.org.dmg > (just to be sure: PRELIMINARY) > Good progress, thanks for the hard work. > > The test file of the numpy 2.0.0 on the build machine: > > http://friedrichromstedt.org/numpy/Tests/Vincent-i386-Core2Duo/py2.5/Logs/10-10-15/test.log > > Test result file on another ppc PowerBook G4: > > http://friedrichromstedt.org/numpy/Tests/Rick-ppc-G4/py2.5/10-10-16/01-10.5-test.log > > Those failures all look familiar, they will probably disappear if you build the maintenance/1.5.x branch. All those "Warning: invalid value..." messages should also disappear, if they are still there they should be filtered before the release. > Notice that both tests FAILED, but not very strongly. The errors are > different on both machines. > > Some things to note: > 1) The docs still say they are for 1.5.0rc1. Might be my mistake, > but I remember the docs being rebuilt completely when it made the dmg. > The doc build picks up the currently installed version, so I guess you did not have the bootstrap virtualenv active (see my previous email). > 2) The installer has no customised background image. (Intended?). > The dmg anyway has very nice layout, it works. > The background image should be tools/numpy-macosx-installer/dmgbackground.png Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Sat Oct 16 06:18:43 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Sat, 16 Oct 2010 18:18:43 +0800 Subject: [Numpy-discussion] OS X installers - naming scheme and 2.7 annoyance Message-ID: Hi all, With there being two different installers for Python 2.7 on python.org (10.3+ has ppc/i386, 10.5+ has ppc/i386/x86_64) a change to the naming scheme is needed for the numpy binaries. That's assuming we provide two corresponding installers with the same arches. I propose the following: "numpy-%s-py%s-python.org-macosx%s.dmg" % (fullversion, pyver, osxver) http://github.com/rgommers/numpy/commit/2b1eb79a63cba4 These two 2.7 versions are fairly annoying by the way - only one of them can live in /Library/Frameworks. Here are the options I see to fix this: 1) Manually reinstall the desired version, then build the installer against it. 2) Have two clearly named virtualenvs for them and build against those executables without activating the virtualenvs. Then change the hardcoded python executable path in the generated Info.plist files under tools/numpy-macosx-installer/content/. 3) Have only the 10.5 py27 installed, create the 10.3 numpy installer by specifying all CFLAGS/LDFLAGS in the paver script. I'm not liking any of those options much. Anyone have a better idea? The python.org offering may change again in the near future by the way. Excerpt from an email by Ronald Oussoren on the pythonmac list: "The consensus at the [europython] summit was to replace the macosx10.5 installer (ppc, x86, x86_64) by a macosx10.6 (x86, x86_64) installer for future releases. That enables linking with Tk 8.5 and that would solve a number of issues other than being available in 64-bit code. Users of OSX 10.5 (or earlier) can still use the macosx10.3 installer, that would stay the same. The only difference for OSX 10.5 users is that they cannot use 64-bit code without building their own binaries." Finally, this post is related: http://article.gmane.org/gmane.comp.python.apple/17182, will be relevant for numpy too. Ralf From friedrichromstedt at gmail.com Sat Oct 16 08:08:55 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Sat, 16 Oct 2010 14:08:55 +0200 Subject: [Numpy-discussion] OS X installers - naming scheme and 2.7 annoyance In-Reply-To: References: Message-ID: 2010/10/16 Ralf Gommers : > With there being two different installers for Python 2.7 on python.org > (10.3+ has ppc/i386, 10.5+ has ppc/i386/x86_64) a change to the naming > scheme is needed for the numpy binaries. That's assuming we provide > two corresponding installers with the same arches. I propose the > following: > "numpy-%s-py%s-python.org-macosx%s.dmg" % (fullversion, pyver, osxver) > http://github.com/rgommers/numpy/commit/2b1eb79a63cba4 There is a correspondence between the macosx version and the arches. But nevertheless, it's not an equivalence, and the macosxXXX also implies other libraries which are available and may be linked in (like Tk as mentioned by Russel on http://article.gmane.org/gmane.comp.python.apple/17182). Since we'll provide only those -macosxXXX which python.org does provide, from my point of view, your suggestion is the best option, if not even perfect :-) > These two 2.7 versions are fairly annoying by the way - only one of > them can live in /Library/Frameworks. Here are the options I see to > fix this: > 1) Manually reinstall the desired version, then build the installer against it. > 2) Have two clearly named virtualenvs for them and build against those > executables without activating the virtualenvs. Then change the > hardcoded python executable path in the generated Info.plist files > under tools/numpy-macosx-installer/content/. (2) is a bit hacky to me. > 3) Have only the 10.5 py27 installed, create the 10.3 numpy installer > by specifying all CFLAGS/LDFLAGS in the paver script. We may run into the same troube as in "crosscompiling" on 10.6, or not? > I'm not liking any of those options much. Anyone have a better idea? 4) Installing, and moving the Framework directory, this is what I'll do when building the dmgs (Vincent started soon ago): /Library/Frameworks/Python.framework/2.7-10.3 /Library/Frameworks/Python.framework/2.7-10.5 /Library/Frameworks/Python.framework/2.7 -> 2.7-XXX it should be transparent to any PATH settings etc., and is easy to switch. Opinions about this? > The python.org offering may change again in the near future by the > way. Excerpt from an email by Ronald Oussoren on the pythonmac list: > "The consensus at the [europython] summit was to replace the > macosx10.5 installer (ppc, x86, x86_64) by a macosx10.6 (x86, x86_64) > installer for future releases. That enables linking with Tk 8.5 and > that would solve a number of issues other than being available in > 64-bit code. Users of OSX 10.5 (or earlier) can still use the > macosx10.3 installer, that would stay the same. The only difference > for OSX 10.5 users is that they cannot use 64-bit code without > building their own binaries." > > Finally, this post is related: > http://article.gmane.org/gmane.comp.python.apple/17182, will be > relevant for numpy too. He (Russell) say's that: "The numpy folks apparently were able to make a single binary installer that works everywhere with both versions of Python 2.7. I'm not sure how they managed that, but perhaps numpy doesn't require bringing in any static libraries (if it uses the built in numeric libraries)." (http://article.gmane.org/gmane.comp.python.apple/17182) Who knows details about this? Friedrich From friedrichromstedt at gmail.com Sat Oct 16 09:32:14 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Sat, 16 Oct 2010 15:32:14 +0200 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: References: <4CB4C99A.8040906@noaa.gov> <4CB5E208.5030909@noaa.gov> <4CB8A39F.4090601@noaa.gov> Message-ID: 2010/10/16 Ralf Gommers : > On Sat, Oct 16, 2010 at 3:53 AM, Friedrich Romstedt > wrote: >> Here come now the interesting facts: >> >> 1) ?Some tests of numpy failed in 2.0.0.dev. ?When the machine is >> running again I can send the logs. ?All some strange-looking typecode >> string tests with dtype('...') iirc. > > Not too surprising, that's the master branch which is not tested much on > py2.5 / OS X. Okay. >> 2) ?I noticed that the paver at some late point tried to switch from >> py2.5 to py2.6, what is rather strange to me. ?I must have a look >> where precisely the build failed for this reason. ?py2.6 is the >> DEFAULT_PYTHON_VERSION (iirc) in pavement.py, and changing it to 2.5 >> fixed it. ?Strange. > > Did you have the the bootstrap virtualenv set up and active? The following > should work from a clean checkout: > paver bootstrap > source bootstrap/bin/activate > python setupsconsegg.py install > paver dmg -p 2.5 At that time my system Python was py2.5. What I did is in http://friedrichromstedt.org/numpy/Releases/SystemSetup/2010.rst, and the offending call is logged in http://friedrichromstedt.org/numpy/Releases/Logs/10-10-15/paver-dmg.5.log. I did not issue the commands you gave before calling $paver dmg. Also I installed paver using py2.5, and renamed the executable to paver2.5, to have different pavers for all the Pythons. Is the -p 2.5 switch fully equivalent? In pavement.py: @task @needs("pdf") @cmdopts([("python-version=", "p", "python version")]) def dmg(options): ... _build_mpkg(pyver) def _build_mpkg(pyver): ... in setupegg.py: So I thought it would create it locally, without using the /Framework installed numpy libs. True? I would like to avoid $pave nuke, since I want to use the same repo directory for all Python version builds, and $nuke would remove the other installers. They shouldn't interfere with each other since the Python version is encoded in the build directory. The tasks clean and clean_bootstrap are okay with me. Seems that the docs show up with 1.4.1rc1 since I omitted the $setupsconsegg.py install, the autodoc found the previous install from the numpy-host/, where I didn't use 2.0.0.dev. Seems that it surpisingly albeit my irgnorance of the instructions in pavement.py did work quite nicely. Can you explain in more detail what the virtualenv is for? I guess it's to not install the numpy binaries built into the system's directory? Shouldn't there be a $deactivate call before cleaning the virtualenv? Why cleaning the virtualenv at all? I guess I might need to clean it for the different Pythons to not interfere, but doesn't virtualenv do the job too? > If that fails it's a bug. The first build is with python 2.6 if that's your > default python, it's needed to make sure the docs are built from the exact > same commit as the binary itself. "default Python" = DEFAULT_PYTHON in pavement.py? I guess you mean the paver Python, the Python used to install Paver. From the log http://friedrichromstedt.org/numpy/Releases/Logs/10-10-15/paver-dmg.5.log (the same as above), the docs were built, and there was no 2.6 installed at that time. It tried to call py2.6 *after* the successful call to pdflatex. I would like to know more about the internals of the build process, currently it's kind of "gray box" to me. What is DEFAULT_PYTHON for? It is used in the options() call in pavement.py, why? Else I see no substantial place of use in pavement.py. >> 3) ?I found no v1.5.1 tag yet (yesterday). ?Will the HEAD become 1.5.1? > > You mean the master branch? HEAD just points at the most recent commit on > your currently active branch. In that case no, 1.5.1 will be tagged from the > maintenance/1.5.x branch. The tag v1.5.1rc1 or v1.5.1 do not exist yet, tags > are only created once the actual release takes place. So tag v1.5.1rc1 > should appear tomorrow. Okay, I didn't mention master since: 105osxpython:numpy-deployment Friedrich$ git branch * master This was like this from the beginning after $git clone http://github.com/numpy/numpy.git. I thought owner-numpy project-numpy would be the official numpy repo, am I wrong? Btw: how do I find out what commit a tag is pointing to, and how do I display those commit's details (using shell git commands)? Friedrich From ralf.gommers at googlemail.com Sat Oct 16 09:32:42 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Sat, 16 Oct 2010 21:32:42 +0800 Subject: [Numpy-discussion] OS X installers - naming scheme and 2.7 annoyance In-Reply-To: References: Message-ID: On Sat, Oct 16, 2010 at 8:08 PM, Friedrich Romstedt wrote: > 2010/10/16 Ralf Gommers : >> With there being two different installers for Python 2.7 on python.org >> (10.3+ has ppc/i386, 10.5+ has ppc/i386/x86_64) a change to the naming >> scheme is needed for the numpy binaries. That's assuming we provide >> two corresponding installers with the same arches. I propose the >> following: >> "numpy-%s-py%s-python.org-macosx%s.dmg" % (fullversion, pyver, osxver) >> http://github.com/rgommers/numpy/commit/2b1eb79a63cba4 > > There is a correspondence between the macosx version and the arches. > But nevertheless, it's not an equivalence, and the macosxXXX also > implies other libraries which are available and may be linked in (like > Tk as mentioned by Russel on > http://article.gmane.org/gmane.comp.python.apple/17182). ?Since we'll > provide only those -macosxXXX which python.org does provide, from my > point of view, your suggestion is the best option, if not even perfect > :-) > >> These two 2.7 versions are fairly annoying by the way - only one of >> them can live in /Library/Frameworks. Here are the options I see to >> fix this: >> 1) Manually reinstall the desired version, then build the installer against it. >> 2) Have two clearly named virtualenvs for them and build against those >> executables without activating the virtualenvs. Then change the >> hardcoded python executable path in the generated Info.plist files >> under tools/numpy-macosx-installer/content/. > > (2) is a bit hacky to me. > >> 3) Have only the 10.5 py27 installed, create the 10.3 numpy installer >> by specifying all CFLAGS/LDFLAGS in the paver script. > > We may run into the same troube as in "crosscompiling" on 10.6, or not? > >> I'm not liking any of those options much. Anyone have a better idea? > > 4) ?Installing, and moving the Framework directory, this is what I'll > do when building the dmgs (Vincent started soon ago): > /Library/Frameworks/Python.framework/2.7-10.3 > /Library/Frameworks/Python.framework/2.7-10.5 > /Library/Frameworks/Python.framework/2.7 -> 2.7-XXX > > it should be transparent to any PATH settings etc., and is easy to switch. > > Opinions about this? Better than anything I came up with. In the release script we can simply copy over the whole tree before each 2.7 build. > >> The python.org offering may change again in the near future by the >> way. Excerpt from an email by Ronald Oussoren on the pythonmac list: >> "The consensus at the [europython] summit was to replace the >> macosx10.5 installer (ppc, x86, x86_64) by a macosx10.6 (x86, x86_64) >> installer for future releases. That enables linking with Tk 8.5 and >> that would solve a number of issues other than being available in >> 64-bit code. Users of OSX 10.5 (or earlier) can still use the >> macosx10.3 installer, that would stay the same. The only difference >> for OSX 10.5 users is that they cannot use 64-bit code without >> building their own binaries." >> >> Finally, this post is related: >> http://article.gmane.org/gmane.comp.python.apple/17182, will be >> relevant for numpy too. > > He (Russell) say's that: > "The numpy folks apparently were able to make a single binary > installer that works everywhere with both versions of Python 2.7. I'm > not sure how they managed that, but perhaps numpy doesn't require > bringing in any static libraries (if it uses the built in numeric > libraries)." (http://article.gmane.org/gmane.comp.python.apple/17182) > > Who knows details about this? Russell asked a while ago if the 2.7 numpy dmg on SF (built against 10.5 python installer) worked for both 10.3 and 10.5 installers from python.org. I checked on my own computer that that was the case, and we got zero bug reports about this - so my answer was yes. I think it's supposed to work for us, but apparently not if you use static libraries like MPL does. Cheers, Ralf From ralf.gommers at googlemail.com Sat Oct 16 10:16:49 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Sat, 16 Oct 2010 22:16:49 +0800 Subject: [Numpy-discussion] help from OS X 10.5 users wanted In-Reply-To: References: <4CB4C99A.8040906@noaa.gov> <4CB5E208.5030909@noaa.gov> <4CB8A39F.4090601@noaa.gov> Message-ID: On Sat, Oct 16, 2010 at 9:32 PM, Friedrich Romstedt wrote: > 2010/10/16 Ralf Gommers : >> On Sat, Oct 16, 2010 at 3:53 AM, Friedrich Romstedt >> wrote: >>> 2) ?I noticed that the paver at some late point tried to switch from >>> py2.5 to py2.6, what is rather strange to me. ?I must have a look >>> where precisely the build failed for this reason. ?py2.6 is the >>> DEFAULT_PYTHON_VERSION (iirc) in pavement.py, and changing it to 2.5 >>> fixed it. ?Strange. >> >> Did you have the the bootstrap virtualenv set up and active? The following >> should work from a clean checkout: >> paver bootstrap >> source bootstrap/bin/activate >> python setupsconsegg.py install >> paver dmg -p 2.5 > > At that time my system Python was py2.5. ?What I did is in > http://friedrichromstedt.org/numpy/Releases/SystemSetup/2010.rst, and > the offending call is logged in > http://friedrichromstedt.org/numpy/Releases/Logs/10-10-15/paver-dmg.5.log. > ?I did not issue the commands you gave before calling $paver dmg. > Also I installed paver using py2.5, and renamed the executable to > paver2.5, to have different pavers for all the Pythons. ?Is the -p 2.5 > switch fully equivalent? 2.5 is your default, so that's what was used to build the docs. Then it tried to build an installer for 2.6, since that's the default given in pavement.py. Nothing strange so far. The log ends with: /bin/sh: /Library/Frameworks/Python.framework/Versions/2.6/bin/python: No such file or directory So you just didn't have python 2.6 installed, that's all. The -p 2.5 is not for the paver version, but for the Python version to compile numpy with. > > In pavement.py: > > @task > @needs("pdf") > @cmdopts([("python-version=", "p", "python version")]) > def dmg(options): > ? ?... > ? ?_build_mpkg(pyver) > > def _build_mpkg(pyver): > ? ?... > ? ? > > in setupegg.py: > > > So I thought it would create it locally, without using the /Framework > installed numpy libs. ?True? True. The installed numpy was used only to build the docs. Basically, during doc build numpy is imported and the docstrings are obtained through introspection. Doc build finishes, you have a pdf. Then it goes to part 2: build numpy against the /Framework installed Python. > > I would like to avoid $pave nuke, since I want to use the same repo > directory for all Python version builds, and $nuke would remove the > other installers. ?They shouldn't interfere with each other since the > Python version is encoded in the build directory. ?The tasks clean and > clean_bootstrap are okay with me. It doesn't remove the installers. See the release.sh script in the repo. It builds all installers at once. > > Seems that the docs show up with 1.4.1rc1 since I omitted the > $setupsconsegg.py install, the autodoc found the previous install from > the numpy-host/, where I didn't use 2.0.0.dev. correct > > Seems that it surpisingly albeit my irgnorance of the instructions in > pavement.py did work quite nicely. > > Can you explain in more detail what the virtualenv is for? ?I guess > it's to not install the numpy binaries built into the system's > directory? Yep. Numpy needs to be installed for the doc build to work, as I explained above. You don't want to do that in global site-packages. >?Shouldn't there be a $deactivate call before cleaning the > virtualenv? ?Why cleaning the virtualenv at all? ?I guess I might need > to clean it for the different Pythons to not interfere, but doesn't > virtualenv do the job too? It's not cleaned. What is cleaned are the build/ and dist/ dirs. The virtualenv is under bootstrap/, and the installer is under release/. > >> If that fails it's a bug. The first build is with python 2.6 if that's your >> default python, it's needed to make sure the docs are built from the exact >> same commit as the binary itself. > > "default Python" = DEFAULT_PYTHON in pavement.py? I meant system default. And with first build I meant the one in release.sh. > ?I guess you mean > the paver Python, the Python used to install Paver. ?From the log > http://friedrichromstedt.org/numpy/Releases/Logs/10-10-15/paver-dmg.5.log > (the same as above), the docs were built, and there was no 2.6 > installed at that time. ?It tried to call py2.6 *after* the successful > call to pdflatex. This should be clear now I think > ?I would like to know more about the internals of > the build process, currently it's kind of "gray box" to me. > That's how it was for me too half a year ago. Maybe it still is a bit... > What is DEFAULT_PYTHON for? ?It is used in the options() call in > pavement.py, why? ?Else I see no substantial place of use in > pavement.py. It just defines what version you are building a dmg for when doing "$ paver dmg". Using the -p switch overrides that default. > >>> 3) ?I found no v1.5.1 tag yet (yesterday). ?Will the HEAD become 1.5.1? >> >> You mean the master branch? HEAD just points at the most recent commit on >> your currently active branch. In that case no, 1.5.1 will be tagged from the >> maintenance/1.5.x branch. The tag v1.5.1rc1 or v1.5.1 do not exist yet, tags >> are only created once the actual release takes place. So tag v1.5.1rc1 >> should appear tomorrow. > > Okay, I didn't mention master since: > > 105osxpython:numpy-deployment Friedrich$ git branch > * master > > This was like this from the beginning after $git clone > http://github.com/numpy/numpy.git. ?I thought owner-numpy > project-numpy would be the official numpy repo, am I wrong? You're not wrong. It's just git's behavior to only clone the master branch by default. You can obtain other local branches as needed, for example: $ git checkout -b 1.5.x origin/maintenance/1.5.x > > Btw: how do I find out what commit a tag is pointing to, and how do I > display those commit's details (using shell git commands)? > $ git log v1.5.0 commit c069eee07f2a976b3c2660670dc7bca6438ee94f <...details...> Cheers, Ralf From vincent at vincentdavis.net Sat Oct 16 12:04:16 2010 From: vincent at vincentdavis.net (Vincent Davis) Date: Sat, 16 Oct 2010 10:04:16 -0600 Subject: [Numpy-discussion] OS X installers - naming scheme and 2.7 annoyance In-Reply-To: References: Message-ID: On Sat, Oct 16, 2010 at 4:18 AM, Ralf Gommers wrote: > Hi all, > > With there being two different installers for Python 2.7 on python.org > (10.3+ has ppc/i386, 10.5+ has ppc/i386/x86_64) a change to the naming > scheme is needed for the numpy binaries. That's assuming we provide > two corresponding installers with the same arches. I propose the > following: > "numpy-%s-py%s-python.org-macosx%s.dmg" % (fullversion, pyver, osxver) > http://github.com/rgommers/numpy/commit/2b1eb79a63cba4 > > These two 2.7 versions are fairly annoying by the way - only one of > them can live in /Library/Frameworks. Here are the options I see to > fix this: > 1) Manually reinstall the desired version, then build the installer against it. > 2) Have two clearly named virtualenvs for them and build against those > executables without activating the virtualenvs. Then change the > hardcoded python executable path in the generated Info.plist files > under tools/numpy-macosx-installer/content/. > 3) Have only the 10.5 py27 installed, create the 10.3 numpy installer > by specifying all CFLAGS/LDFLAGS in the paver script. > > I'm not liking any of those options much. Anyone have a better idea? > > The python.org offering may change again in the near future by the > way. Excerpt from an email by Ronald Oussoren on the pythonmac list: > "The consensus at the [europython] summit was to replace the > macosx10.5 installer (ppc, x86, x86_64) by a macosx10.6 (x86, x86_64) > installer for future releases. That enables linking with Tk 8.5 and > that would solve a number of issues other than being available in > 64-bit code. Users of OSX 10.5 (or earlier) can still use the > macosx10.3 installer, that would stay the same. The only difference > for OSX 10.5 users is that they cannot use 64-bit code without > building their own binaries." Just to be clear. If we are building a 10.5 numpy py27 release we should be building it on Python "32-bit Mac Installer disk image (2.7) for OS X 10.3 and later (sig)". Is this correct or the proposal? Vincent > > Finally, this post is related: > http://article.gmane.org/gmane.comp.python.apple/17182, will be > relevant for numpy too. > > Ralf > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -- Thanks Vincent Davis 720-301-3003 From ralf.gommers at googlemail.com Sat Oct 16 12:11:32 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Sun, 17 Oct 2010 00:11:32 +0800 Subject: [Numpy-discussion] OS X installers - naming scheme and 2.7 annoyance In-Reply-To: References: Message-ID: On Sun, Oct 17, 2010 at 12:04 AM, Vincent Davis wrote: > On Sat, Oct 16, 2010 at 4:18 AM, Ralf Gommers > wrote: >> Hi all, >> >> With there being two different installers for Python 2.7 on python.org >> (10.3+ has ppc/i386, 10.5+ has ppc/i386/x86_64) a change to the naming >> scheme is needed for the numpy binaries. That's assuming we provide >> two corresponding installers with the same arches. I propose the >> following: >> "numpy-%s-py%s-python.org-macosx%s.dmg" % (fullversion, pyver, osxver) >> http://github.com/rgommers/numpy/commit/2b1eb79a63cba4 >> >> These two 2.7 versions are fairly annoying by the way - only one of >> them can live in /Library/Frameworks. Here are the options I see to >> fix this: >> 1) Manually reinstall the desired version, then build the installer against it. >> 2) Have two clearly named virtualenvs for them and build against those >> executables without activating the virtualenvs. Then change the >> hardcoded python executable path in the generated Info.plist files >> under tools/numpy-macosx-installer/content/. >> 3) Have only the 10.5 py27 installed, create the 10.3 numpy installer >> by specifying all CFLAGS/LDFLAGS in the paver script. >> >> I'm not liking any of those options much. Anyone have a better idea? >> >> The python.org offering may change again in the near future by the >> way. Excerpt from an email by Ronald Oussoren on the pythonmac list: >> "The consensus at the [europython] summit was to replace the >> macosx10.5 installer (ppc, x86, x86_64) by a macosx10.6 (x86, x86_64) >> installer for future releases. That enables linking with Tk 8.5 and >> that would solve a number of issues other than being available in >> 64-bit code. Users of OSX 10.5 (or earlier) can still use the >> macosx10.3 installer, that would stay the same. The only difference >> for OSX 10.5 users is that they cannot use 64-bit code without >> building their own binaries." > > Just to be clear. If we are building a 10.5 numpy py27 release we > should be building it on Python > "32-bit Mac Installer disk image (2.7) for OS X 10.3 and later (sig)". > Is this correct or the proposal? No, numpy-1.5.1-py2.7-python.org-macosx10.5.dmg would be built against the version in XX-macosx10.5 installer from python.org, and numpy-...macosx10.3.dmg against XX-macosx10.3 installer. Ralf From friedrichromstedt at gmail.com Sat Oct 16 12:36:23 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Sat, 16 Oct 2010 18:36:23 +0200 Subject: [Numpy-discussion] Sorry, probably postponing Binary Release [urgent] Message-ID: Hi, I've been working the past few days usually to somewhen between 1 and 7 in the morning on the numpy build, but I feel at the end of my power. I need some spare of this for my exam on Monday. I see two options: 1) Vincent, if you feel like, can you try to finish it on your own. Don't know ... 2) Can we postpone the Binary Release on SF by one week. I vote for 2) if possible :-) P.S.: Internals: I recognise my exhaustion by coming up aggressive feelings, Vincent is already a slight victim, sorry Vincent. Friedrich P.P.S.: I put this public with full intent. From friedrichromstedt at gmail.com Sat Oct 16 12:38:20 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Sat, 16 Oct 2010 18:38:20 +0200 Subject: [Numpy-discussion] Sorry, probably postponing Binary Release [urgent] In-Reply-To: References: Message-ID: Addendum: Ralf, vpn? 2010/10/16 Friedrich Romstedt : > Hi, > > I've been working the past few days usually to somewhen between 1 and > 7 in the morning on the numpy build, but I feel at the end of my > power. ?I need some spare of this for my exam on Monday. ?I see two > options: > > 1) ?Vincent, if you feel like, can you try to finish it on your own. > Don't know ... > > 2) ?Can we postpone the Binary Release on SF by one week. > > I vote for 2) if possible :-) > > P.S.: Internals: I recognise my exhaustion by coming up aggressive > feelings, Vincent is already a slight victim, sorry Vincent. > > Friedrich > > P.P.S.: I put this public with full intent. > From ralf.gommers at googlemail.com Sat Oct 16 12:47:42 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Sun, 17 Oct 2010 00:47:42 +0800 Subject: [Numpy-discussion] Sorry, probably postponing Binary Release [urgent] In-Reply-To: References: Message-ID: Hi Friedrich, On Sun, Oct 17, 2010 at 12:36 AM, Friedrich Romstedt wrote: > Hi, > > I've been working the past few days usually to somewhen between 1 and > 7 in the morning on the numpy build, but I feel at the end of my > power. Thanks for working so hard, but please don't burn yourself out - we need you for more than a week! > ?I need some spare of this for my exam on Monday. ?I see two > options: > > 1) ?Vincent, if you feel like, can you try to finish it on your own. > Don't know ... > > 2) ?Can we postpone the Binary Release on SF by one week. > > I vote for 2) if possible :-) > Don't worry too much. I will tag the RC tomorrow, but if there's no 10.5 binary up yet that's no big deal. The final release is not till the end of the month. Will try the vpn tomorrow morning. Good luck with your exam, Ralf > P.S.: Internals: I recognise my exhaustion by coming up aggressive > feelings, Vincent is already a slight victim, sorry Vincent. > > Friedrich > > P.P.S.: I put this public with full intent. > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > From friedrichromstedt at gmail.com Sat Oct 16 13:25:40 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Sat, 16 Oct 2010 19:25:40 +0200 Subject: [Numpy-discussion] Sorry, probably postponing Binary Release [urgent] In-Reply-To: References: Message-ID: 2010/10/16 Ralf Gommers : > Hi Friedrich, > > On Sun, Oct 17, 2010 at 12:36 AM, Friedrich Romstedt > wrote: >> Hi, >> >> I've been working the past few days usually to somewhen between 1 and >> 7 in the morning on the numpy build, but I feel at the end of my >> power. > > Thanks for working so hard, but please don't burn yourself out - we > need you for more than a week! Thank you so much. :-) >> ?I need some spare of this for my exam on Monday. ?I see two >> options: >> >> 1) ?Vincent, if you feel like, can you try to finish it on your own. >> Don't know ... >> >> 2) ?Can we postpone the Binary Release on SF by one week. >> >> I vote for 2) if possible :-) >> > > Don't worry too much. I will tag the RC tomorrow, but if there's no > 10.5 binary up yet that's no big deal. The final release is not till > the end of the month. > > Will try the vpn tomorrow morning. Okay. > Good luck with your exam, > Ralf Good, thanks, cu, Friedrich P.S.: Really happy to find understanding. From vincent at vincentdavis.net Sat Oct 16 14:21:20 2010 From: vincent at vincentdavis.net (Vincent Davis) Date: Sat, 16 Oct 2010 12:21:20 -0600 Subject: [Numpy-discussion] Sorry, probably postponing Binary Release [urgent] In-Reply-To: References: Message-ID: On Sat, Oct 16, 2010 at 11:25 AM, Friedrich Romstedt wrote: > 2010/10/16 Ralf Gommers : >> Hi Friedrich, >> >> On Sun, Oct 17, 2010 at 12:36 AM, Friedrich Romstedt >> wrote: >>> Hi, >>> >>> I've been working the past few days usually to somewhen between 1 and >>> 7 in the morning on the numpy build, but I feel at the end of my >>> power. >> >> Thanks for working so hard, but please don't burn yourself out - we >> need you for more than a week! > > Thank you so much. ?:-) > >>> ?I need some spare of this for my exam on Monday. ?I see two >>> options: >>> >>> 1) ?Vincent, if you feel like, can you try to finish it on your own. >>> Don't know ... I will give this a try, I suffer from the limitation that if I have 1 hour of quiet I am lucky. So it is difficult to sit a focus. Friedrich deserves credit for any success. I will work an this later today with a backup of the OS so I don't undo any of Friedrich work. And I want to be clear what my priorities/interests are. 1, Provide a machine to the numpy/scipy community that can be used for building binaries and anything else useful to numpy/scipy. 2, Make sure those that can actually successfully build binaries do so. Like you and Ralf. 3, Not get in the way 4, learn how to build binaries myself. Thanks Vincent >>> >>> 2) ?Can we postpone the Binary Release on SF by one week. >>> >>> I vote for 2) if possible :-) >>> >> >> Don't worry too much. I will tag the RC tomorrow, but if there's no >> 10.5 binary up yet that's no big deal. The final release is not till >> the end of the month. >> >> Will try the vpn tomorrow morning. > > Okay. > >> Good luck with your exam, >> Ralf > > Good, thanks, cu, > Friedrich > > P.S.: Really happy to find understanding. > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -- Thanks Vincent Davis 720-301-3003 From friedrichromstedt at gmail.com Sat Oct 16 14:34:32 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Sat, 16 Oct 2010 20:34:32 +0200 Subject: [Numpy-discussion] Sorry, probably postponing Binary Release [urgent] In-Reply-To: References: Message-ID: 2010/10/16 Vincent Davis : > On Sat, Oct 16, 2010 at 11:25 AM, Friedrich Romstedt > wrote: >> 2010/10/16 Ralf Gommers : >>> On Sun, Oct 17, 2010 at 12:36 AM, Friedrich Romstedt >>> wrote: >>>> ?I need some spare of this for my exam on Monday. ?I see two >>>> options: >>>> >>>> 1) ?Vincent, if you feel like, can you try to finish it on your own. >>>> Don't know ... > I will give this a try, I suffer from the limitation that if I have 1 > hour of quiet I am lucky. So it is difficult to sit a focus. Friedrich > deserves credit for any success. I will work an this later today with > a backup of the OS so I don't undo any of Friedrich work. Nono, it's more like a publication in particle science (physics) :-) And the credit will be given once the task is done I guess :-) > And I want to be clear what my priorities/interests are. > 1, Provide a machine to the numpy/scipy community that can be used for > building binaries and anything else useful to numpy/scipy. > 2, Make sure those that can actually successfully build binaries do > so. Like you and Ralf. > 3, Not get in the way > 4, learn how to build binaries myself. We discussed it in private. Thank you. cu, Friedrich P.S.: brightly smiling. I enjoy all your company. From charlesr.harris at gmail.com Sat Oct 16 14:53:12 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Sat, 16 Oct 2010 12:53:12 -0600 Subject: [Numpy-discussion] Another merge at github Message-ID: Here. This looks harmless but it makes the history really ugly. We need to get the word out *not* to do things this way. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh.holbrook at gmail.com Sat Oct 16 14:56:01 2010 From: josh.holbrook at gmail.com (Joshua Holbrook) Date: Sat, 16 Oct 2010 10:56:01 -0800 Subject: [Numpy-discussion] Another merge at github In-Reply-To: References: Message-ID: On Sat, Oct 16, 2010 at 10:53 AM, Charles R Harris wrote: > Here. This looks harmless but it makes the history really ugly. We need to > get the word out *not* to do things this way. > > Chuck > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > So: Rebase, not merge? --Josh From charlesr.harris at gmail.com Sat Oct 16 15:20:07 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Sat, 16 Oct 2010 13:20:07 -0600 Subject: [Numpy-discussion] Another merge at github In-Reply-To: References: Message-ID: On Sat, Oct 16, 2010 at 12:56 PM, Joshua Holbrook wrote: > On Sat, Oct 16, 2010 at 10:53 AM, Charles R Harris > wrote: > > Here. This looks harmless but it makes the history really ugly. We need > to > > get the word out *not* to do things this way. > > > > Chuck > > > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion at scipy.org > > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > > > So: Rebase, not merge? > > I'm thinking along those lines, but I'm just a dilettante git user. I tend to merge master to my development branches, merge them back to master, and then push master to github. That probably isn't the recommended way. Rebase would probably have the same effect. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.root at ou.edu Sat Oct 16 17:54:53 2010 From: ben.root at ou.edu (Benjamin Root) Date: Sat, 16 Oct 2010 16:54:53 -0500 Subject: [Numpy-discussion] Another merge at github In-Reply-To: References: Message-ID: On Sat, Oct 16, 2010 at 2:20 PM, Charles R Harris wrote: > > > On Sat, Oct 16, 2010 at 12:56 PM, Joshua Holbrook > wrote: > >> On Sat, Oct 16, 2010 at 10:53 AM, Charles R Harris >> wrote: >> > Here. This looks harmless but it makes the history really ugly. We need >> to >> > get the word out *not* to do things this way. >> > >> > Chuck >> > >> > _______________________________________________ >> > NumPy-Discussion mailing list >> > NumPy-Discussion at scipy.org >> > http://mail.scipy.org/mailman/listinfo/numpy-discussion >> > >> > >> >> So: Rebase, not merge? >> >> > I'm thinking along those lines, but I'm just a dilettante git user. I tend > to merge master to my development branches, merge them back to master, and > then push master to github. That probably isn't the recommended way. Rebase > would probably have the same effect. > > Chuck > > > I think the iPython development mailing list recently had a long discussion about proper git usage. Maybe there is something we can learn from their experience? Ben Root -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Sat Oct 16 18:23:19 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Sat, 16 Oct 2010 16:23:19 -0600 Subject: [Numpy-discussion] Another merge at github In-Reply-To: References: Message-ID: On Sat, Oct 16, 2010 at 3:54 PM, Benjamin Root wrote: > On Sat, Oct 16, 2010 at 2:20 PM, Charles R Harris < > charlesr.harris at gmail.com> wrote: > >> >> >> On Sat, Oct 16, 2010 at 12:56 PM, Joshua Holbrook < >> josh.holbrook at gmail.com> wrote: >> >>> On Sat, Oct 16, 2010 at 10:53 AM, Charles R Harris >>> wrote: >>> > Here. This looks harmless but it makes the history really ugly. We need >>> to >>> > get the word out *not* to do things this way. >>> > >>> > Chuck >>> > >>> > _______________________________________________ >>> > NumPy-Discussion mailing list >>> > NumPy-Discussion at scipy.org >>> > http://mail.scipy.org/mailman/listinfo/numpy-discussion >>> > >>> > >>> >>> So: Rebase, not merge? >>> >>> >> I'm thinking along those lines, but I'm just a dilettante git user. I tend >> to merge master to my development branches, merge them back to master, and >> then push master to github. That probably isn't the recommended way. Rebase >> would probably have the same effect. >> >> Chuck >> >> >> > I think the iPython development mailing list recently had a long discussion > about proper git usage. Maybe there is something we can learn from their > experience? > > IIRC, they recommended pushing from local branches to master on github and not merging master to the development branches. That doesn't sound right to me, but perhaps I misunderstood... Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From goodfellow.ian at gmail.com Fri Oct 15 10:45:49 2010 From: goodfellow.ian at gmail.com (Ian Goodfellow) Date: Fri, 15 Oct 2010 10:45:49 -0400 Subject: [Numpy-discussion] Please help a newbie install NUMPY In-Reply-To: References: Message-ID: It probably worked but didn't use ATLAS (and given my experience over the last few weeks, evidently no one who reads this list knows how to get ATLAS to work). What happens when you actually try to use numpy? If you don't need ATLAS, you are probably OK as is. Your output looks about the same as my working but ATLAS-less build. On Fri, Oct 15, 2010 at 10:31 AM, P Sanjey wrote: > Please help-I am a newbie and I wanted to try installing numpy on a > local /home/usr directory but got the following errors-I am not sure > where to even begin fixing this problem and any help would be useful > I just did the standard > python setup.py build and got the following (loooooong) error message > > > ********************************************************** > non-existing path in 'numpy/distutils': 'site.cfg' > F2PY Version 1 > blas_opt_info: > blas_mkl_info: > libraries mkl,vml,guide not found in /home/sanjey/lib > libraries mkl,vml,guide not found in /usr/local/lib > libraries mkl,vml,guide not found in /usr/lib > NOT AVAILABLE > > atlas_blas_threads_info: > Setting PTATLAS=ATLAS > libraries ptf77blas,ptcblas,atlas not found in /home/sanjey/lib > libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib > libraries ptf77blas,ptcblas,atlas not found in /usr/lib/sse2 > libraries ptf77blas,ptcblas,atlas not found in /usr/lib > NOT AVAILABLE > > atlas_blas_info: > libraries f77blas,cblas,atlas not found in /home/sanjey/lib > libraries f77blas,cblas,atlas not found in /usr/local/lib > libraries f77blas,cblas,atlas not found in /usr/lib/sse2 > libraries f77blas,cblas,atlas not found in /usr/lib > NOT AVAILABLE > > blas_info: > libraries blas not found in /home/sanjey/lib > libraries blas not found in /usr/local/lib > FOUND: > libraries = ['blas'] > library_dirs = ['/usr/lib'] > language = f77 > > FOUND: > libraries = ['blas'] > library_dirs = ['/usr/lib'] > define_macros = [('NO_ATLAS_INFO', 1)] > language = f77 > > lapack_opt_info: > lapack_mkl_info: > mkl_info: > libraries mkl,vml,guide not found in /home/sanjey/lib > libraries mkl,vml,guide not found in /usr/local/lib > libraries mkl,vml,guide not found in /usr/lib > NOT AVAILABLE > > NOT AVAILABLE > > atlas_threads_info: > Setting PTATLAS=ATLAS > libraries ptf77blas,ptcblas,atlas not found in /home/sanjey/lib > libraries lapack_atlas not found in /home/sanjey/lib > libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib > libraries lapack_atlas not found in /usr/local/lib > libraries ptf77blas,ptcblas,atlas not found in /usr/lib/sse2 > libraries lapack_atlas not found in /usr/lib/sse2 > libraries ptf77blas,ptcblas,atlas not found in /usr/lib > libraries lapack_atlas not found in /usr/lib > numpy.distutils.system_info.atlas_threads_info > NOT AVAILABLE > > atlas_info: > libraries f77blas,cblas,atlas not found in /home/sanjey/lib > libraries lapack_atlas not found in /home/sanjey/lib > libraries f77blas,cblas,atlas not found in /usr/local/lib > libraries lapack_atlas not found in /usr/local/lib > libraries f77blas,cblas,atlas not found in /usr/lib/sse2 > libraries lapack_atlas not found in /usr/lib/sse2 > libraries f77blas,cblas,atlas not found in /usr/lib > libraries lapack_atlas not found in /usr/lib > numpy.distutils.system_info.atlas_info > NOT AVAILABLE > > lapack_info: > libraries lapack not found in /home/sanjey/lib > libraries lapack not found in /usr/local/lib > FOUND: > libraries = ['lapack'] > library_dirs = ['/usr/lib'] > language = f77 > > FOUND: > libraries = ['lapack', 'blas'] > library_dirs = ['/usr/lib'] > define_macros = [('NO_ATLAS_INFO', 1)] > language = f77 > > running build > running config_cc > unifing config_cc, config, build_clib, build_ext, build commands > --compiler options > running config_fc > unifing config_fc, config, build_clib, build_ext, build commands > --fcompiler options > running build_src > 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 library "npymath" sources > customize GnuFCompiler > Found executable /usr/bin/g77 > gnu: no Fortran 90 compiler found > gnu: no Fortran 90 compiler found > customize GnuFCompiler > gnu: no Fortran 90 compiler found > gnu: no Fortran 90 compiler found > customize GnuFCompiler using config > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > gcc -m32 -pthread _configtest.o -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'exp' > gcc -m32 -pthread _configtest.o -o _configtest > _configtest.o(.text+0x19): In function `main': > /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' > collect2: ld returned 1 exit status > _configtest.o(.text+0x19): In function `main': > /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' > collect2: ld returned 1 exit status > failure. > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'exp' > gcc -m32 -pthread _configtest.o -lm -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > creating build/src.linux-x86_64-2.4/numpy/core > creating build/src.linux-x86_64-2.4/numpy/core/src > creating build/src.linux-x86_64-2.4/numpy/core/src/npymath > conv_template:> > build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math.c > conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/npymath/ieee754.c > conv_template:> > build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math_complex.c > building extension "numpy.core._sort" sources > Generating build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:5: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:5: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:5: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:5: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o _configtest.c _configtest.o > _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c > _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:5: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o _configtest.c _configtest.o > _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c > _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o > _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:5: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:7: error: `SIZEOF_LONGDOUBLE' undeclared (first use in > this function) > _configtest.c:7: error: (Each undeclared identifier is reported only once > _configtest.c:7: error: for each function it appears in.) > _configtest.c:5: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:7: error: `SIZEOF_LONGDOUBLE' undeclared (first use in > this function) > _configtest.c:7: error: (Each undeclared identifier is reported only once > _configtest.c:7: error: for each function it appears in.) > failure. > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o _configtest.c _configtest.o > _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c > _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o > _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c > _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:6: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:6: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:5: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:6: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:6: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:5: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'exp' > gcc -m32 -pthread _configtest.o -o _configtest > _configtest.o(.text+0x19): In function `main': > /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' > collect2: ld returned 1 exit status > _configtest.o(.text+0x19): In function `main': > /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' > collect2: ld returned 1 exit status > failure. > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'exp' > gcc -m32 -pthread _configtest.o -lm -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'asin' > _configtest.c:2: warning: conflicting types for built-in function 'cos' > _configtest.c:3: warning: conflicting types for built-in function 'log' > _configtest.c:4: warning: conflicting types for built-in function 'fabs' > _configtest.c:5: warning: conflicting types for built-in function 'tanh' > _configtest.c:6: warning: conflicting types for built-in function 'atan' > _configtest.c:7: warning: conflicting types for built-in function 'acos' > _configtest.c:8: warning: conflicting types for built-in function 'floor' > _configtest.c:9: warning: conflicting types for built-in function 'fmod' > _configtest.c:10: warning: conflicting types for built-in function 'sqrt' > _configtest.c:11: warning: conflicting types for built-in function 'cosh' > _configtest.c:12: warning: conflicting types for built-in function 'modf' > _configtest.c:13: warning: conflicting types for built-in function 'sinh' > _configtest.c:14: warning: conflicting types for built-in function 'frexp' > _configtest.c:15: warning: conflicting types for built-in function 'exp' > _configtest.c:16: warning: conflicting types for built-in function 'tan' > _configtest.c:17: warning: conflicting types for built-in function 'ceil' > _configtest.c:18: warning: conflicting types for built-in function 'log10' > _configtest.c:19: warning: conflicting types for built-in function 'sin' > _configtest.c:20: warning: conflicting types for built-in function 'ldexp' > gcc -m32 -pthread _configtest.o -lm -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'expm1' > _configtest.c:2: warning: conflicting types for built-in function 'log2' > _configtest.c:3: warning: conflicting types for built-in function 'pow' > _configtest.c:4: warning: conflicting types for built-in function 'rint' > _configtest.c:5: warning: conflicting types for built-in function 'atanh' > _configtest.c:6: warning: conflicting types for built-in function > 'copysign' > _configtest.c:7: warning: conflicting types for built-in function 'asinh' > _configtest.c:8: warning: conflicting types for built-in function 'atan2' > _configtest.c:9: warning: conflicting types for built-in function 'hypot' > _configtest.c:10: warning: conflicting types for built-in function 'acosh' > _configtest.c:11: warning: conflicting types for built-in function 'exp2' > _configtest.c:12: warning: conflicting types for built-in function 'log1p' > _configtest.c:13: warning: conflicting types for built-in function > 'nextafter' > _configtest.c:14: warning: conflicting types for built-in function 'trunc' > gcc -m32 -pthread _configtest.o -lm -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'cosf' > _configtest.c:2: warning: conflicting types for built-in function 'coshf' > _configtest.c:3: warning: conflicting types for built-in function 'rintf' > _configtest.c:4: warning: conflicting types for built-in function 'fabsf' > _configtest.c:5: warning: conflicting types for built-in function 'floorf' > _configtest.c:6: warning: conflicting types for built-in function > 'nextafterf' > _configtest.c:7: warning: conflicting types for built-in function 'tanhf' > _configtest.c:8: warning: conflicting types for built-in function 'log10f' > _configtest.c:9: warning: conflicting types for built-in function 'logf' > _configtest.c:10: warning: conflicting types for built-in function 'sinhf' > _configtest.c:11: warning: conflicting types for built-in function 'acosf' > _configtest.c:12: warning: conflicting types for built-in function 'sqrtf' > _configtest.c:13: warning: conflicting types for built-in function 'ldexpf' > _configtest.c:14: warning: conflicting types for built-in function 'hypotf' > _configtest.c:15: warning: conflicting types for built-in function 'log2f' > _configtest.c:16: warning: conflicting types for built-in function 'exp2f' > _configtest.c:17: warning: conflicting types for built-in function 'atanf' > _configtest.c:18: warning: conflicting types for built-in function 'fmodf' > _configtest.c:19: warning: conflicting types for built-in function 'atan2f' > _configtest.c:20: warning: conflicting types for built-in function 'modff' > _configtest.c:21: warning: conflicting types for built-in function 'ceilf' > _configtest.c:22: warning: conflicting types for built-in function 'log1pf' > _configtest.c:23: warning: conflicting types for built-in function 'asinf' > _configtest.c:24: warning: conflicting types for built-in function > 'copysignf' > _configtest.c:25: warning: conflicting types for built-in function 'acoshf' > _configtest.c:26: warning: conflicting types for built-in function 'sinf' > _configtest.c:27: warning: conflicting types for built-in function 'tanf' > _configtest.c:28: warning: conflicting types for built-in function 'atanhf' > _configtest.c:29: warning: conflicting types for built-in function 'truncf' > _configtest.c:30: warning: conflicting types for built-in function 'asinhf' > _configtest.c:31: warning: conflicting types for built-in function 'frexpf' > _configtest.c:32: warning: conflicting types for built-in function 'powf' > _configtest.c:33: warning: conflicting types for built-in function 'expf' > _configtest.c:34: warning: conflicting types for built-in function 'expm1f' > gcc -m32 -pthread _configtest.o -lm -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'tanhl' > _configtest.c:2: warning: conflicting types for built-in function 'log10l' > _configtest.c:3: warning: conflicting types for built-in function > 'nextafterl' > _configtest.c:4: warning: conflicting types for built-in function 'coshl' > _configtest.c:5: warning: conflicting types for built-in function 'cosl' > _configtest.c:6: warning: conflicting types for built-in function 'floorl' > _configtest.c:7: warning: conflicting types for built-in function 'rintl' > _configtest.c:8: warning: conflicting types for built-in function 'fabsl' > _configtest.c:9: warning: conflicting types for built-in function 'acosl' > _configtest.c:10: warning: conflicting types for built-in function 'ldexpl' > _configtest.c:11: warning: conflicting types for built-in function 'sqrtl' > _configtest.c:12: warning: conflicting types for built-in function 'logl' > _configtest.c:13: warning: conflicting types for built-in function 'expm1l' > _configtest.c:14: warning: conflicting types for built-in function 'hypotl' > _configtest.c:15: warning: conflicting types for built-in function 'log2l' > _configtest.c:16: warning: conflicting types for built-in function > 'copysignl' > _configtest.c:17: warning: conflicting types for built-in function 'exp2l' > _configtest.c:18: warning: conflicting types for built-in function 'atanl' > _configtest.c:19: warning: conflicting types for built-in function 'frexpl' > _configtest.c:20: warning: conflicting types for built-in function 'atan2l' > _configtest.c:21: warning: conflicting types for built-in function 'sinhl' > _configtest.c:22: warning: conflicting types for built-in function 'fmodl' > _configtest.c:23: warning: conflicting types for built-in function 'log1pl' > _configtest.c:24: warning: conflicting types for built-in function 'asinl' > _configtest.c:25: warning: conflicting types for built-in function 'ceill' > _configtest.c:26: warning: conflicting types for built-in function 'sinl' > _configtest.c:27: warning: conflicting types for built-in function 'acoshl' > _configtest.c:28: warning: conflicting types for built-in function 'atanhl' > _configtest.c:29: warning: conflicting types for built-in function 'tanl' > _configtest.c:30: warning: conflicting types for built-in function 'truncl' > _configtest.c:31: warning: conflicting types for built-in function 'powl' > _configtest.c:32: warning: conflicting types for built-in function 'expl' > _configtest.c:33: warning: conflicting types for built-in function 'modfl' > _configtest.c:34: warning: conflicting types for built-in function 'asinhl' > gcc -m32 -pthread _configtest.o -lm -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:6: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:6: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:6: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:6: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'cexp' > _configtest.c:3: warning: conflicting types for built-in function 'ccos' > _configtest.c:4: warning: conflicting types for built-in function 'cimag' > _configtest.c:5: warning: conflicting types for built-in function 'cabs' > _configtest.c:6: warning: conflicting types for built-in function 'cpow' > _configtest.c:7: warning: conflicting types for built-in function 'csqrt' > _configtest.c:8: warning: conflicting types for built-in function 'carg' > _configtest.c:9: warning: conflicting types for built-in function 'creal' > _configtest.c:10: warning: conflicting types for built-in function 'csin' > gcc -m32 -pthread _configtest.o -lm -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'ccosf' > _configtest.c:2: warning: conflicting types for built-in function 'cargf' > _configtest.c:3: warning: conflicting types for built-in function 'csqrtf' > _configtest.c:4: warning: conflicting types for built-in function 'cpowf' > _configtest.c:5: warning: conflicting types for built-in function 'cexpf' > _configtest.c:6: warning: conflicting types for built-in function 'crealf' > _configtest.c:7: warning: conflicting types for built-in function 'csinf' > _configtest.c:8: warning: conflicting types for built-in function 'cabsf' > _configtest.c:10: warning: conflicting types for built-in function 'cimagf' > gcc -m32 -pthread _configtest.o -lm -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'csqrtl' > _configtest.c:2: warning: conflicting types for built-in function 'cargl' > _configtest.c:3: warning: conflicting types for built-in function 'cexpl' > _configtest.c:4: warning: conflicting types for built-in function 'ccosl' > _configtest.c:5: warning: conflicting types for built-in function 'cpowl' > _configtest.c:6: warning: conflicting types for built-in function 'cimagl' > _configtest.c:7: warning: conflicting types for built-in function 'csinl' > _configtest.c:8: warning: conflicting types for built-in function 'creall' > _configtest.c:10: warning: conflicting types for built-in function 'cabsl' > gcc -m32 -pthread _configtest.o -lm -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:5: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:7: error: `Py_UNICODE_WIDE' undeclared (first use in > this function) > _configtest.c:7: error: (Each undeclared identifier is reported only once > _configtest.c:7: error: for each function it appears in.) > _configtest.c:5: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:7: error: `Py_UNICODE_WIDE' undeclared (first use in > this function) > _configtest.c:7: error: (Each undeclared identifier is reported only once > _configtest.c:7: error: for each function it appears in.) > failure. > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > removing: _configtest.c _configtest.o > ('File:', 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h') > #define HAVE_ENDIAN_H 1 > #define SIZEOF_PY_INTPTR_T 4 > #define SIZEOF_PY_LONG_LONG 8 > #define MATHLIB m > #define HAVE_SIN > #define HAVE_COS > #define HAVE_TAN > #define HAVE_SINH > #define HAVE_COSH > #define HAVE_TANH > #define HAVE_FABS > #define HAVE_FLOOR > #define HAVE_CEIL > #define HAVE_SQRT > #define HAVE_LOG10 > #define HAVE_LOG > #define HAVE_EXP > #define HAVE_ASIN > #define HAVE_ACOS > #define HAVE_ATAN > #define HAVE_FMOD > #define HAVE_MODF > #define HAVE_FREXP > #define HAVE_LDEXP > #define HAVE_EXPM1 > #define HAVE_LOG1P > #define HAVE_ACOSH > #define HAVE_ASINH > #define HAVE_ATANH > #define HAVE_RINT > #define HAVE_TRUNC > #define HAVE_EXP2 > #define HAVE_LOG2 > #define HAVE_HYPOT > #define HAVE_ATAN2 > #define HAVE_POW > #define HAVE_COPYSIGN > #define HAVE_NEXTAFTER > #define HAVE_SINF > #define HAVE_COSF > #define HAVE_TANF > #define HAVE_SINHF > #define HAVE_COSHF > #define HAVE_TANHF > #define HAVE_FABSF > #define HAVE_FLOORF > #define HAVE_CEILF > #define HAVE_RINTF > #define HAVE_TRUNCF > #define HAVE_SQRTF > #define HAVE_LOG10F > #define HAVE_LOGF > #define HAVE_LOG1PF > #define HAVE_EXPF > #define HAVE_EXPM1F > #define HAVE_ASINF > #define HAVE_ACOSF > #define HAVE_ATANF > #define HAVE_ASINHF > #define HAVE_ACOSHF > #define HAVE_ATANHF > #define HAVE_HYPOTF > #define HAVE_ATAN2F > #define HAVE_POWF > #define HAVE_FMODF > #define HAVE_MODFF > #define HAVE_FREXPF > #define HAVE_LDEXPF > #define HAVE_EXP2F > #define HAVE_LOG2F > #define HAVE_COPYSIGNF > #define HAVE_NEXTAFTERF > #define HAVE_SINL > #define HAVE_COSL > #define HAVE_TANL > #define HAVE_SINHL > #define HAVE_COSHL > #define HAVE_TANHL > #define HAVE_FABSL > #define HAVE_FLOORL > #define HAVE_CEILL > #define HAVE_RINTL > #define HAVE_TRUNCL > #define HAVE_SQRTL > #define HAVE_LOG10L > #define HAVE_LOGL > #define HAVE_LOG1PL > #define HAVE_EXPL > #define HAVE_EXPM1L > #define HAVE_ASINL > #define HAVE_ACOSL > #define HAVE_ATANL > #define HAVE_ASINHL > #define HAVE_ACOSHL > #define HAVE_ATANHL > #define HAVE_HYPOTL > #define HAVE_ATAN2L > #define HAVE_POWL > #define HAVE_FMODL > #define HAVE_MODFL > #define HAVE_FREXPL > #define HAVE_LDEXPL > #define HAVE_EXP2L > #define HAVE_LOG2L > #define HAVE_COPYSIGNL > #define HAVE_NEXTAFTERL > #define HAVE_DECL_ISNAN > #define HAVE_DECL_ISINF > #define HAVE_DECL_SIGNBIT > #define HAVE_DECL_ISFINITE > #define HAVE_COMPLEX_H > #define HAVE_CREAL > #define HAVE_CIMAG > #define HAVE_CABS > #define HAVE_CARG > #define HAVE_CEXP > #define HAVE_CSQRT > #define HAVE_CLOG > #define HAVE_CCOS > #define HAVE_CSIN > #define HAVE_CPOW > #define HAVE_CREALF > #define HAVE_CIMAGF > #define HAVE_CABSF > #define HAVE_CARGF > #define HAVE_CEXPF > #define HAVE_CSQRTF > #define HAVE_CLOGF > #define HAVE_CCOSF > #define HAVE_CSINF > #define HAVE_CPOWF > #define HAVE_CREALL > #define HAVE_CIMAGL > #define HAVE_CABSL > #define HAVE_CARGL > #define HAVE_CEXPL > #define HAVE_CSQRTL > #define HAVE_CLOGL > #define HAVE_CCOSL > #define HAVE_CSINL > #define HAVE_CPOWL > #define HAVE_LDOUBLE_INTEL_EXTENDED_12_BYTES_LE 1 > #ifndef __cplusplus > /* #undef inline */ > #endif > > #ifndef _NPY_NPY_CONFIG_H_ > #error config.h should never be included directly, include npy_config.h > instead > #endif > > EOF > adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' > to sources. > Generating > build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'exp' > gcc -m32 -pthread _configtest.o -o _configtest > _configtest.o(.text+0x19): In function `main': > /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' > collect2: ld returned 1 exit status > _configtest.o(.text+0x19): In function `main': > /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' > collect2: ld returned 1 exit status > failure. > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'exp' > gcc -m32 -pthread _configtest.o -lm -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:5: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c:5:18: warning: extra tokens at end of #ifndef directive > _configtest.c: In function `main': > _configtest.c:4: warning: control reaches end of non-void function > success! > removing: _configtest.c _configtest.o > File: build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h > #define NPY_HAVE_ENDIAN_H 1 > #define NPY_SIZEOF_SHORT SIZEOF_SHORT > #define NPY_SIZEOF_INT SIZEOF_INT > #define NPY_SIZEOF_LONG SIZEOF_LONG > #define NPY_SIZEOF_FLOAT 4 > #define NPY_SIZEOF_COMPLEX_FLOAT 8 > #define NPY_SIZEOF_DOUBLE 8 > #define NPY_SIZEOF_COMPLEX_DOUBLE 16 > #define NPY_SIZEOF_LONGDOUBLE 12 > #define NPY_SIZEOF_COMPLEX_LONGDOUBLE 24 > #define NPY_SIZEOF_PY_INTPTR_T 4 > #define NPY_SIZEOF_PY_LONG_LONG 8 > #define NPY_SIZEOF_LONGLONG 8 > #define NPY_NO_SMP 1 > #define NPY_HAVE_DECL_ISNAN > #define NPY_HAVE_DECL_ISINF > #define NPY_HAVE_DECL_SIGNBIT > #define NPY_HAVE_DECL_ISFINITE > #define NPY_USE_C99_COMPLEX > #define NPY_HAVE_COMPLEX_DOUBLE 1 > #define NPY_HAVE_COMPLEX_FLOAT 1 > #define NPY_HAVE_COMPLEX_LONG_DOUBLE 1 > #define NPY_USE_C99_FORMATS 1 > #define NPY_VISIBILITY_HIDDEN __attribute__((visibility("hidden"))) > #define NPY_ABI_VERSION 0x01000009 > #define NPY_API_VERSION 0x00000004 > > #ifndef __STDC_FORMAT_MACROS > #define __STDC_FORMAT_MACROS 1 > #endif > > EOF > adding > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' > to sources. > executing numpy/core/code_generators/generate_numpy_api.py > adding > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__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/include/numpy/config.h', > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h'] > building extension "numpy.core.multiarray" sources > non-existing path in 'numpy/core': > 'build/src.linux-x86_64-2.4/numpy/core/src/multiarray' > creating build/src.linux-x86_64-2.4/numpy/core/src/multiarray > conv_template:> > build/src.linux-x86_64-2.4/numpy/core/src/multiarray/scalartypes.c > conv_template:> > build/src.linux-x86_64-2.4/numpy/core/src/multiarray/arraytypes.c > adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' > to sources. > adding > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' > to sources. > executing numpy/core/code_generators/generate_numpy_api.py > adding > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h' > to sources. > numpy.core - nothing done with h_files = > ['build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h', > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h'] > building extension "numpy.core.umath" sources > adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' > to sources. > adding > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' > to sources. > executing numpy/core/code_generators/generate_ufunc_api.py > adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__ufunc_api.h' > to sources. > non-existing path in 'numpy/core': > 'build/src.linux-x86_64-2.4/numpy/core/src/umath' > creating build/src.linux-x86_64-2.4/numpy/core/src/umath > conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/umath/loops.c > conv_template:> > build/src.linux-x86_64-2.4/numpy/core/src/umath/umathmodule.c > conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/umath/funcs.inc > adding 'build/src.linux-x86_64-2.4/numpy/core/src/umath' to include_dirs. > numpy.core - nothing done with h_files = > ['build/src.linux-x86_64-2.4/numpy/core/src/umath/funcs.inc', > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h', > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__ufunc_api.h'] > building extension "numpy.core.scalarmath" sources > adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' > to sources. > adding > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' > to sources. > executing numpy/core/code_generators/generate_numpy_api.py > adding > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h' > to sources. > executing numpy/core/code_generators/generate_ufunc_api.py > adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__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/include/numpy/config.h', > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h', > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__ufunc_api.h'] > building extension "numpy.core._dotblas" sources > building extension "numpy.core.umath_tests" sources > conv_template:> > build/src.linux-x86_64-2.4/numpy/core/src/umath/umath_tests.c > building extension "numpy.core.multiarray_tests" sources > conv_template:> > build/src.linux-x86_64-2.4/numpy/core/src/multiarray/multiarray_tests.c > building extension "numpy.lib._compiled_base" sources > building extension "numpy.numarray._capi" sources > building extension "numpy.fft.fftpack_lite" sources > building extension "numpy.linalg.lapack_lite" sources > creating build/src.linux-x86_64-2.4/numpy/linalg > adding 'numpy/linalg/lapack_litemodule.c' to sources. > adding 'numpy/linalg/python_xerbla.c' to sources. > building extension "numpy.random.mtrand" sources > creating build/src.linux-x86_64-2.4/numpy/random > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > gcc -m32 -pthread _configtest.o -o _configtest > _configtest > failure. > removing: _configtest.c _configtest.o _configtest > building data_files sources > build_src: building npy-pkg config files > running build_py > creating build/lib.linux-x86_64-2.4 > creating build/lib.linux-x86_64-2.4/numpy > copying numpy/version.py -> build/lib.linux-x86_64-2.4/numpy > copying numpy/matlib.py -> build/lib.linux-x86_64-2.4/numpy > copying numpy/ctypeslib.py -> build/lib.linux-x86_64-2.4/numpy > copying numpy/setupscons.py -> build/lib.linux-x86_64-2.4/numpy > copying numpy/__init__.py -> build/lib.linux-x86_64-2.4/numpy > copying numpy/setup.py -> build/lib.linux-x86_64-2.4/numpy > copying numpy/dual.py -> build/lib.linux-x86_64-2.4/numpy > copying numpy/_import_tools.py -> build/lib.linux-x86_64-2.4/numpy > copying numpy/add_newdocs.py -> build/lib.linux-x86_64-2.4/numpy > copying build/src.linux-x86_64-2.4/numpy/__config__.py -> > build/lib.linux-x86_64-2.4/numpy > creating build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/from_template.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/npy_pkg_config.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/compat.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/setupscons.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/__init__.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/lib2def.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/interactive.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/info.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/environment.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/setup.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/cpuinfo.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/extension.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/core.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/intelccompiler.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/log.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/__version__.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/unixccompiler.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/misc_util.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/line_endings.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/exec_command.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/conv_template.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/ccompiler.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/mingw32ccompiler.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/system_info.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/numpy_distribution.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying build/src.linux-x86_64-2.4/numpy/distutils/__config__.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > creating build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/install.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/egg_info.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/install_clib.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/bdist_rpm.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/develop.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/install_data.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/__init__.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/build_py.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/build_src.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/build_clib.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/build_ext.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/autodist.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/install_headers.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/config.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/config_compiler.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/build.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/build_scripts.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/sdist.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/scons.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > creating build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/none.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/hpux.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/compaq.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/absoft.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/vast.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/nag.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/__init__.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/sun.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/mips.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/intel.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/gnu.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/g95.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/pg.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/ibm.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/lahey.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > creating build/lib.linux-x86_64-2.4/numpy/testing > copying numpy/testing/nulltester.py -> > build/lib.linux-x86_64-2.4/numpy/testing > copying numpy/testing/setupscons.py -> > build/lib.linux-x86_64-2.4/numpy/testing > copying numpy/testing/__init__.py -> > build/lib.linux-x86_64-2.4/numpy/testing > copying numpy/testing/setup.py -> build/lib.linux-x86_64-2.4/numpy/testing > copying numpy/testing/decorators.py -> > build/lib.linux-x86_64-2.4/numpy/testing > copying numpy/testing/utils.py -> build/lib.linux-x86_64-2.4/numpy/testing > copying numpy/testing/noseclasses.py -> > build/lib.linux-x86_64-2.4/numpy/testing > copying numpy/testing/numpytest.py -> > build/lib.linux-x86_64-2.4/numpy/testing > copying numpy/testing/nosetester.py -> > build/lib.linux-x86_64-2.4/numpy/testing > creating build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/auxfuncs.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/common_rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/__init__.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/cb_rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/info.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/setup.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/f2py2e.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/cfuncs.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/crackfortran.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/use_rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/diagnose.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/f2py_testing.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/__version__.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/capi_maps.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/func2subr.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/f90mod_rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py > creating build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/defchararray.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/numeric.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/__init__.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/info.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/function_base.py -> > build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/getlimits.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/setup.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/fromnumeric.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/shape_base.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/setup_common.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/records.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/memmap.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/arrayprint.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/numerictypes.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/machar.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/_mx_datetime_parser.py -> > build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/scons_support.py -> > build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/_internal.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/code_generators/generate_numpy_api.py -> > build/lib.linux-x86_64-2.4/numpy/core > creating build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/_datasource.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/arraysetops.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/index_tricks.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/format.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/__init__.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/info.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/function_base.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/setup.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/arrayterator.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/ufunclike.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/shape_base.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/user_array.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/type_check.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/stride_tricks.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/recfunctions.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/npyio.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/_iotools.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/utils.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/financial.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/twodim_base.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/polynomial.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/scimath.py -> build/lib.linux-x86_64-2.4/numpy/lib > creating build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/functions.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/alter_code1.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/misc.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/compat.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/setupscons.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/__init__.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/linear_algebra.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/setup.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/random_array.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/user_array.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/alter_code2.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/fft.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/matrix.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/fix_default_axis.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/rng_stats.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/mlab.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/ma.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/ufuncs.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/rng.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/array_printer.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/typeconv.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/precision.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/arrayfns.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > creating build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/nd_image.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/util.py -> build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/convolve.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/functions.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/alter_code1.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/compat.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/setupscons.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/__init__.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/linear_algebra.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/setup.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/random_array.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/alter_code2.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/fft.py -> build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/matrix.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/numerictypes.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/image.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/mlab.py -> build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/ma.py -> build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/session.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/ufuncs.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > creating build/lib.linux-x86_64-2.4/numpy/fft > copying numpy/fft/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/fft > copying numpy/fft/__init__.py -> build/lib.linux-x86_64-2.4/numpy/fft > copying numpy/fft/info.py -> build/lib.linux-x86_64-2.4/numpy/fft > copying numpy/fft/setup.py -> build/lib.linux-x86_64-2.4/numpy/fft > copying numpy/fft/fftpack.py -> build/lib.linux-x86_64-2.4/numpy/fft > copying numpy/fft/helper.py -> build/lib.linux-x86_64-2.4/numpy/fft > creating build/lib.linux-x86_64-2.4/numpy/linalg > copying numpy/linalg/setupscons.py -> > build/lib.linux-x86_64-2.4/numpy/linalg > copying numpy/linalg/__init__.py -> build/lib.linux-x86_64-2.4/numpy/linalg > copying numpy/linalg/info.py -> build/lib.linux-x86_64-2.4/numpy/linalg > copying numpy/linalg/setup.py -> build/lib.linux-x86_64-2.4/numpy/linalg > copying numpy/linalg/linalg.py -> build/lib.linux-x86_64-2.4/numpy/linalg > creating build/lib.linux-x86_64-2.4/numpy/random > copying numpy/random/setupscons.py -> > build/lib.linux-x86_64-2.4/numpy/random > copying numpy/random/__init__.py -> build/lib.linux-x86_64-2.4/numpy/random > copying numpy/random/info.py -> build/lib.linux-x86_64-2.4/numpy/random > copying numpy/random/setup.py -> build/lib.linux-x86_64-2.4/numpy/random > creating build/lib.linux-x86_64-2.4/numpy/ma > copying numpy/ma/version.py -> build/lib.linux-x86_64-2.4/numpy/ma > copying numpy/ma/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/ma > copying numpy/ma/__init__.py -> build/lib.linux-x86_64-2.4/numpy/ma > copying numpy/ma/setup.py -> build/lib.linux-x86_64-2.4/numpy/ma > copying numpy/ma/bench.py -> build/lib.linux-x86_64-2.4/numpy/ma > copying numpy/ma/core.py -> build/lib.linux-x86_64-2.4/numpy/ma > copying numpy/ma/testutils.py -> build/lib.linux-x86_64-2.4/numpy/ma > copying numpy/ma/timer_comparison.py -> build/lib.linux-x86_64-2.4/numpy/ma > copying numpy/ma/extras.py -> build/lib.linux-x86_64-2.4/numpy/ma > copying numpy/ma/mrecords.py -> build/lib.linux-x86_64-2.4/numpy/ma > creating build/lib.linux-x86_64-2.4/numpy/matrixlib > copying numpy/matrixlib/setupscons.py -> > build/lib.linux-x86_64-2.4/numpy/matrixlib > copying numpy/matrixlib/__init__.py -> > build/lib.linux-x86_64-2.4/numpy/matrixlib > copying numpy/matrixlib/setup.py -> > build/lib.linux-x86_64-2.4/numpy/matrixlib > copying numpy/matrixlib/defmatrix.py -> > build/lib.linux-x86_64-2.4/numpy/matrixlib > creating build/lib.linux-x86_64-2.4/numpy/compat > copying numpy/compat/setupscons.py -> > build/lib.linux-x86_64-2.4/numpy/compat > copying numpy/compat/__init__.py -> build/lib.linux-x86_64-2.4/numpy/compat > copying numpy/compat/setup.py -> build/lib.linux-x86_64-2.4/numpy/compat > copying numpy/compat/py3k.py -> build/lib.linux-x86_64-2.4/numpy/compat > copying numpy/compat/_inspect.py -> build/lib.linux-x86_64-2.4/numpy/compat > creating build/lib.linux-x86_64-2.4/numpy/polynomial > copying numpy/polynomial/__init__.py -> > build/lib.linux-x86_64-2.4/numpy/polynomial > copying numpy/polynomial/setup.py -> > build/lib.linux-x86_64-2.4/numpy/polynomial > copying numpy/polynomial/chebyshev.py -> > build/lib.linux-x86_64-2.4/numpy/polynomial > copying numpy/polynomial/polynomial.py -> > build/lib.linux-x86_64-2.4/numpy/polynomial > copying numpy/polynomial/polyutils.py -> > build/lib.linux-x86_64-2.4/numpy/polynomial > copying numpy/polynomial/polytemplate.py -> > build/lib.linux-x86_64-2.4/numpy/polynomial > creating build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/byteswapping.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/glossary.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/indexing.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/misc.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/internals.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/__init__.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/creation.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/jargon.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/basics.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/io.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/methods_vs_functions.py -> > build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/broadcasting.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/constants.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/howtofind.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/ufuncs.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/subclassing.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/structured_arrays.py -> > build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/performance.py -> build/lib.linux-x86_64-2.4/numpy/doc > running build_clib > customize UnixCCompiler > customize UnixCCompiler using build_clib > building 'npymath' library > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > creating build/temp.linux-x86_64-2.4 > creating build/temp.linux-x86_64-2.4/build > creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4 > creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy > creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core > creating > build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src > creating > build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/npymath > compile options: '-Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math.c > In file included from numpy/core/src/private/npy_config.h:4, > from numpy/core/src/npymath/npy_math_private.h:24, > from numpy/core/src/npymath/npy_math.c.src:56: > build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: > warning: "HAVE_HYPOT" redefined > In file included from /home/sanjey/include/python2.4/Python.h:8, > from numpy/core/src/npymath/npy_math_private.h:21, > from numpy/core/src/npymath/npy_math.c.src:56: > /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the > location of the previous definition > gcc: build/src.linux-x86_64-2.4/numpy/core/src/npymath/ieee754.c > In file included from numpy/core/src/private/npy_config.h:4, > from numpy/core/src/npymath/npy_math_common.h:8, > from numpy/core/src/npymath/ieee754.c.src:7: > build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: > warning: "HAVE_HYPOT" redefined > In file included from /home/sanjey/include/python2.4/Python.h:8, > from numpy/core/src/npymath/npy_math_common.h:4, > from numpy/core/src/npymath/ieee754.c.src:7: > /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the > location of the previous definition > gcc: build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math_complex.c > In file included from numpy/core/src/private/npy_config.h:4, > from numpy/core/src/npymath/npy_math_common.h:8, > from numpy/core/src/npymath/npy_math_complex.c.src:31: > build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: > warning: "HAVE_HYPOT" redefined > In file included from /home/sanjey/include/python2.4/Python.h:8, > from numpy/core/src/npymath/npy_math_common.h:4, > from numpy/core/src/npymath/npy_math_complex.c.src:31: > /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the > location of the previous definition > ar: adding 3 object files to build/temp.linux-x86_64-2.4/libnpymath.a > running build_ext > customize UnixCCompiler > customize UnixCCompiler using build_ext > customize GnuFCompiler > gnu: no Fortran 90 compiler found > gnu: no Fortran 90 compiler found > customize GnuFCompiler > gnu: no Fortran 90 compiler found > gnu: no Fortran 90 compiler found > customize GnuFCompiler using build_ext > building 'numpy.core._sort' extension > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: build/src.linux-x86_64-2.4/numpy/core/src/_sortmodule.c > In file included from numpy/core/src/private/npy_config.h:4, > from numpy/core/src/_sortmodule.c.src:34: > build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: > warning: "HAVE_HYPOT" redefined > In file included from /home/sanjey/include/python2.4/Python.h:8, > from numpy/core/src/_sortmodule.c.src:30: > /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the > location of the previous definition > gcc -m32 -pthread -shared > > build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/_sortmodule.o > -Lbuild/temp.linux-x86_64-2.4 -lm -o > build/lib.linux-x86_64-2.4/numpy/core/_sort.so > building 'numpy.core.multiarray' extension > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > creating build/temp.linux-x86_64-2.4/numpy > creating build/temp.linux-x86_64-2.4/numpy/core > creating build/temp.linux-x86_64-2.4/numpy/core/src > creating build/temp.linux-x86_64-2.4/numpy/core/src/multiarray > compile options: '-Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: numpy/core/src/multiarray/multiarraymodule_onefile.c > In file included from numpy/core/src/private/npy_config.h:4, > from numpy/core/src/multiarray/common.c:8, > from > numpy/core/src/multiarray/multiarraymodule_onefile.c:8: > build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: > warning: "HAVE_HYPOT" redefined > In file included from /home/sanjey/include/python2.4/Python.h:8, > from numpy/core/src/multiarray/common.c:2, > from > numpy/core/src/multiarray/multiarraymodule_onefile.c:8: > /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the > location of the previous definition > In file included from > numpy/core/src/multiarray/multiarraymodule_onefile.c:26: > numpy/core/src/multiarray/methods.c: In function `NpyArg_ParseKeywords': > numpy/core/src/multiarray/methods.c:41: warning: passing arg 3 of > `PyArg_VaParseTupleAndKeywords' discards qualifiers from pointer > target type > numpy/core/src/multiarray/flagsobject.c: In function > `arrayflags_richcompare': > numpy/core/src/multiarray/flagsobject.c:568: warning: 'cmp' might be > used uninitialized in this function > numpy/core/src/multiarray/multiarraymodule_onefile.c: At top level: > numpy/core/include/numpy/npy_3kcompat.h:331: warning: > 'simple_capsule_dtor' defined but not used > numpy/core/src/multiarray/buffer.c:777: warning: > '_descriptor_from_pep3118_format' defined but not used > numpy/core/src/multiarray/arraytypes.c.src:93: warning: > '_SEQUENCE_MESSAGE' defined but not used > numpy/core/src/multiarray/mapping.c:75: warning: '_array_ass_item' > defined but not used > gcc -m32 -pthread -shared > > build/temp.linux-x86_64-2.4/numpy/core/src/multiarray/multiarraymodule_onefile.o > -Lbuild/temp.linux-x86_64-2.4 -lnpymath -lm -o > build/lib.linux-x86_64-2.4/numpy/core/multiarray.so > building 'numpy.core.umath' extension > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > creating build/temp.linux-x86_64-2.4/numpy/core/src/umath > compile options: '-Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath > -Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: numpy/core/src/umath/umathmodule_onefile.c > In file included from numpy/core/src/private/npy_config.h:4, > from numpy/core/src/umath/loops.c.src:7, > from numpy/core/src/umath/umathmodule_onefile.c:1: > build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: > warning: "HAVE_HYPOT" redefined > In file included from /home/sanjey/include/python2.4/Python.h:8, > from numpy/core/src/umath/loops.c.src:5, > from numpy/core/src/umath/umathmodule_onefile.c:1: > /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the > location of the previous definition > numpy/core/include/numpy/npy_3kcompat.h:331: warning: > 'simple_capsule_dtor' defined but not used > numpy/core/src/umath/loops.c.src:1258: warning: > 'CLONGDOUBLE_logical_and' defined but not used > numpy/core/src/umath/loops.c.src:1258: warning: > 'CLONGDOUBLE_logical_or' defined but not used > numpy/core/src/umath/loops.c.src:1271: warning: > 'CLONGDOUBLE_logical_xor' defined but not used > numpy/core/src/umath/loops.c.src:1285: warning: > 'CLONGDOUBLE_logical_not' defined but not used > numpy/core/src/umath/loops.c.src:1342: warning: > 'CLONGDOUBLE_ones_like' defined but not used > numpy/core/src/umath/loops.c.src:1399: warning: 'CLONGDOUBLE_maximum' > defined but not used > numpy/core/src/umath/loops.c.src:1399: warning: 'CLONGDOUBLE_minimum' > defined but not used > numpy/core/src/umath/loops.c.src:1423: warning: 'CLONGDOUBLE_fmax' > defined but not used > numpy/core/src/umath/loops.c.src:1423: warning: 'CLONGDOUBLE_fmin' > defined but not used > gcc -m32 -pthread -shared > build/temp.linux-x86_64-2.4/numpy/core/src/umath/umathmodule_onefile.o > -Lbuild/temp.linux-x86_64-2.4 -lnpymath -lm -o > build/lib.linux-x86_64-2.4/numpy/core/umath.so > building 'numpy.core.scalarmath' extension > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: build/src.linux-x86_64-2.4/numpy/core/src/scalarmathmodule.c > numpy/core/include/numpy/npy_3kcompat.h:331: warning: > 'simple_capsule_dtor' defined but not used > gcc -m32 -pthread -shared > > build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/scalarmathmodule.o > -Lbuild/temp.linux-x86_64-2.4 -lm -o > build/lib.linux-x86_64-2.4/numpy/core/scalarmath.so > building 'numpy.core.umath_tests' extension > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > creating > build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/umath > compile options: '-Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: build/src.linux-x86_64-2.4/numpy/core/src/umath/umath_tests.c > In file included from numpy/core/src/private/npy_config.h:4, > from numpy/core/src/umath/umath_tests.c.src:14: > build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: > warning: "HAVE_HYPOT" redefined > In file included from /home/sanjey/include/python2.4/Python.h:8, > from numpy/core/src/umath/umath_tests.c.src:8: > /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the > location of the previous definition > numpy/core/include/numpy/npy_3kcompat.h:331: warning: > 'simple_capsule_dtor' defined but not used > gcc -m32 -pthread -shared > > build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/umath/umath_tests.o > -Lbuild/temp.linux-x86_64-2.4 -o > build/lib.linux-x86_64-2.4/numpy/core/umath_tests.so > building 'numpy.core.multiarray_tests' extension > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > creating > build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/multiarray > compile options: '-Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: > build/src.linux-x86_64-2.4/numpy/core/src/multiarray/multiarray_tests.c > numpy/core/include/numpy/npy_3kcompat.h:331: warning: > 'simple_capsule_dtor' defined but not used > gcc -m32 -pthread -shared > > build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/multiarray/multiarray_tests.o > -Lbuild/temp.linux-x86_64-2.4 -o > build/lib.linux-x86_64-2.4/numpy/core/multiarray_tests.so > building 'numpy.lib._compiled_base' extension > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > creating build/temp.linux-x86_64-2.4/numpy/lib > creating build/temp.linux-x86_64-2.4/numpy/lib/src > compile options: '-Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: numpy/lib/src/_compiled_base.c > In file included from numpy/core/src/private/npy_config.h:4, > from numpy/lib/src/_compiled_base.c:4: > build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: > warning: "HAVE_HYPOT" redefined > In file included from /home/sanjey/include/python2.4/Python.h:8, > from numpy/lib/src/_compiled_base.c:1: > /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the > location of the previous definition > gcc -m32 -pthread -shared > build/temp.linux-x86_64-2.4/numpy/lib/src/_compiled_base.o > -Lbuild/temp.linux-x86_64-2.4 -o > build/lib.linux-x86_64-2.4/numpy/lib/_compiled_base.so > building 'numpy.numarray._capi' extension > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > creating build/temp.linux-x86_64-2.4/numpy/numarray > compile options: '-Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: numpy/numarray/_capi.c > numpy/core/include/numpy/npy_3kcompat.h:331: warning: > 'simple_capsule_dtor' defined but not used > gcc -m32 -pthread -shared > build/temp.linux-x86_64-2.4/numpy/numarray/_capi.o > -Lbuild/temp.linux-x86_64-2.4 -o > build/lib.linux-x86_64-2.4/numpy/numarray/_capi.so > building 'numpy.fft.fftpack_lite' extension > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > creating build/temp.linux-x86_64-2.4/numpy/fft > compile options: '-Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: numpy/fft/fftpack_litemodule.c > gcc: numpy/fft/fftpack.c > gcc -m32 -pthread -shared > build/temp.linux-x86_64-2.4/numpy/fft/fftpack_litemodule.o > build/temp.linux-x86_64-2.4/numpy/fft/fftpack.o > -Lbuild/temp.linux-x86_64-2.4 -o > build/lib.linux-x86_64-2.4/numpy/fft/fftpack_lite.so > building 'numpy.linalg.lapack_lite' extension > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > creating build/temp.linux-x86_64-2.4/numpy/linalg > compile options: '-DNO_ATLAS_INFO=1 -Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: numpy/linalg/lapack_litemodule.c > gcc: numpy/linalg/python_xerbla.c > /usr/bin/g77 -g -Wall -g -Wall -shared > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o > build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o -L/usr/lib > -Lbuild/temp.linux-x86_64-2.4 -llapack -lblas -lg2c -o > build/lib.linux-x86_64-2.4/numpy/linalg/lapack_lite.so > /usr/bin/ld: skipping incompatible /usr/lib/liblapack.so when > searching for -llapack > /usr/bin/ld: skipping incompatible /usr/lib/liblapack.a when searching > for -llapack > /usr/bin/ld: skipping incompatible /usr/lib/libblas.so when searching for > -lblas > /usr/bin/ld: skipping incompatible /usr/lib/libblas.a when searching for > -lblas > /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm > /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm > /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm > /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm > /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 > /usr/bin/ld: warning: i386 architecture of input file > `build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o' is > incompatible with i386:x86-64 output > /usr/bin/ld: warning: i386 architecture of input file > `build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o' is > incompatible with i386:x86-64 output > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xae): > In function `lapack_lite_dgeev': > numpy/linalg/lapack_litemodule.c:155: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfe):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x143):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a3):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1f4):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x272):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31c):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ae):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x60e):numpy/linalg/lapack_litemodule.c:171: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6aa): > In function `lapack_lite_dsyevd': > numpy/linalg/lapack_litemodule.c:241: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6f4):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x739):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x797):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x7ef):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x869):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x8ff):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xa7c):numpy/linalg/lapack_litemodule.c:254: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb34): > In function `lapack_lite_zheevd': > numpy/linalg/lapack_litemodule.c:327: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb7e):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xbc3):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc23):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc74):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xce9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xd85):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xe77):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfb9):numpy/linalg/lapack_litemodule.c:341: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1087): > In function `lapack_lite_dgelsd': > numpy/linalg/lapack_litemodule.c:365: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x10d7):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x111c):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x117d):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x11cf):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1252):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x12e8):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x13d7):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1534):numpy/linalg/lapack_litemodule.c:380: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15af): > In function `lapack_lite_dgesv': > numpy/linalg/lapack_litemodule.c:398: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15f9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x163e):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1692):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x16e7):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x175e):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x189a):numpy/linalg/lapack_litemodule.c:407: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1967): > In function `lapack_lite_dgesdd': > numpy/linalg/lapack_litemodule.c:430: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19b7):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19fc):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a5d):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1aaf):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1b32):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1bc8):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d15):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d76):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1efb):numpy/linalg/lapack_litemodule.c:472: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x202b): > In function `lapack_lite_dgetrf': > numpy/linalg/lapack_litemodule.c:488: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2063):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20ae):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20fe):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2155):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2235):numpy/linalg/lapack_litemodule.c:496: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22b4): > In function `lapack_lite_dpotrf': > numpy/linalg/lapack_litemodule.c:510: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22e9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x232d):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x238f):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x240a):numpy/linalg/lapack_litemodule.c:516: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24af): > In function `lapack_lite_dgeqrf': > numpy/linalg/lapack_litemodule.c:529: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24f9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x253e):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2598):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x25ef):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2669):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x27a7):numpy/linalg/lapack_litemodule.c:540: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2839): > In function `lapack_lite_dorgqr': > numpy/linalg/lapack_litemodule.c:555: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2883):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x28c8):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2927):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x297f):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x29f9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2afa):numpy/linalg/lapack_litemodule.c:562: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2bbb): > In function `lapack_lite_zgeev': > numpy/linalg/lapack_litemodule.c:585: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c0b):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c50):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2cb0):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d04):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d82):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2e2c):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2f6b):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2fb9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x311b):numpy/linalg/lapack_litemodule.c:601: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31f4): > In function `lapack_lite_zgelsd': > numpy/linalg/lapack_litemodule.c:626: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3244):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3289):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x32ef):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3340):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x33c8):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3471):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35b1):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35ff):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x376f):numpy/linalg/lapack_litemodule.c:641: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x37ef): > In function `lapack_lite_zgesv': > numpy/linalg/lapack_litemodule.c:658: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3839):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x387e):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x38d2):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3927):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x399e):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3ada):numpy/linalg/lapack_litemodule.c:667: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bae): > In function `lapack_lite_zgesdd': > numpy/linalg/lapack_litemodule.c:691: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bfe):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3c43):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cab):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cff):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3d82):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3e2c):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3f70):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3fbe):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4195):numpy/linalg/lapack_litemodule.c:708: > undefined reference to `Py_BuildValue' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x41ab):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x422b): > In function `lapack_lite_zgetrf': > numpy/linalg/lapack_litemodule.c:724: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4263):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42ae):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42fe):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4355):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4435):numpy/linalg/lapack_litemodule.c:732: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44b4): > In function `lapack_lite_zpotrf': > numpy/linalg/lapack_litemodule.c:746: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44e9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x452d):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x458f):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460a):numpy/linalg/lapack_litemodule.c:751: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46af): > In function `lapack_lite_zgeqrf': > numpy/linalg/lapack_litemodule.c:764: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46f9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x473e):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4798):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x47ef):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4869):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x49a7):numpy/linalg/lapack_litemodule.c:774: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a39): > In function `lapack_lite_zungqr': > numpy/linalg/lapack_litemodule.c:787: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a83):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ac8):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b27):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b7f):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4bf9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4cfa):numpy/linalg/lapack_litemodule.c:797: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d58): > In function `initlapack_lite': > numpy/linalg/lapack_litemodule.c:858: undefined reference to > `Py_InitModule4' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d71): > In function `initlapack_lite': > > build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1190: > undefined reference to `PyImport_ImportModule' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d8d):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1197: > undefined reference to `PyObject_GetAttrString' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4da6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1212: > undefined reference to `PyCObject_Type' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4db5):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: > undefined reference to `PyExc_RuntimeError' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dc9):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: > undefined reference to `PyErr_SetString' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dd7): > In function `initlapack_lite': > numpy/linalg/lapack_litemodule.c:865: undefined reference to `PyErr_Print' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ddd):numpy/linalg/lapack_litemodule.c:865: > undefined reference to `PyExc_ImportError' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4df1):numpy/linalg/lapack_litemodule.c:865: > undefined reference to `PyErr_SetString' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e18): > In function `initlapack_lite': > > build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1194: > undefined reference to `PyExc_ImportError' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e26):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: > undefined reference to `PyErr_SetString' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e46):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1217: > undefined reference to `PyCObject_AsVoidPtr' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e88):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: > undefined reference to `PyExc_RuntimeError' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e96):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ea1):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: > undefined reference to `PyExc_RuntimeError' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4eb6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1200: > undefined reference to `PyExc_AttributeError' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f24):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: > undefined reference to `PyExc_RuntimeError' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f2e):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f46): > In function `initlapack_lite': > numpy/linalg/lapack_litemodule.c:866: undefined reference to > `PyModule_GetDict' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f66):numpy/linalg/lapack_litemodule.c:867: > undefined reference to `PyErr_NewException' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f82):numpy/linalg/lapack_litemodule.c:868: > undefined reference to `PyDict_SetItemString' > build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x70): > In function `xerbla_': > numpy/linalg/python_xerbla.c:35: undefined reference to `PyExc_ValueError' > > build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x7e):numpy/linalg/python_xerbla.c:35: > undefined reference to `PyErr_SetString' > collect2: ld returned 1 exit status > /usr/bin/ld: skipping incompatible /usr/lib/liblapack.so when > searching for -llapack > /usr/bin/ld: skipping incompatible /usr/lib/liblapack.a when searching > for -llapack > /usr/bin/ld: skipping incompatible /usr/lib/libblas.so when searching for > -lblas > /usr/bin/ld: skipping incompatible /usr/lib/libblas.a when searching for > -lblas > /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm > /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm > /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm > /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm > /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 > /usr/bin/ld: warning: i386 architecture of input file > `build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o' is > incompatible with i386:x86-64 output > /usr/bin/ld: warning: i386 architecture of input file > `build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o' is > incompatible with i386:x86-64 output > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xae): > In function `lapack_lite_dgeev': > numpy/linalg/lapack_litemodule.c:155: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfe):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x143):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a3):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1f4):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x272):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31c):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ae):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x60e):numpy/linalg/lapack_litemodule.c:171: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6aa): > In function `lapack_lite_dsyevd': > numpy/linalg/lapack_litemodule.c:241: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6f4):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x739):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x797):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x7ef):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x869):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x8ff):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xa7c):numpy/linalg/lapack_litemodule.c:254: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb34): > In function `lapack_lite_zheevd': > numpy/linalg/lapack_litemodule.c:327: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb7e):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xbc3):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc23):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc74):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xce9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xd85):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xe77):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfb9):numpy/linalg/lapack_litemodule.c:341: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1087): > In function `lapack_lite_dgelsd': > numpy/linalg/lapack_litemodule.c:365: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x10d7):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x111c):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x117d):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x11cf):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1252):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x12e8):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x13d7):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1534):numpy/linalg/lapack_litemodule.c:380: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15af): > In function `lapack_lite_dgesv': > numpy/linalg/lapack_litemodule.c:398: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15f9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x163e):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1692):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x16e7):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x175e):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x189a):numpy/linalg/lapack_litemodule.c:407: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1967): > In function `lapack_lite_dgesdd': > numpy/linalg/lapack_litemodule.c:430: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19b7):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19fc):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a5d):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1aaf):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1b32):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1bc8):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d15):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d76):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1efb):numpy/linalg/lapack_litemodule.c:472: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x202b): > In function `lapack_lite_dgetrf': > numpy/linalg/lapack_litemodule.c:488: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2063):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20ae):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20fe):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2155):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2235):numpy/linalg/lapack_litemodule.c:496: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22b4): > In function `lapack_lite_dpotrf': > numpy/linalg/lapack_litemodule.c:510: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22e9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x232d):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x238f):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x240a):numpy/linalg/lapack_litemodule.c:516: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24af): > In function `lapack_lite_dgeqrf': > numpy/linalg/lapack_litemodule.c:529: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24f9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x253e):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2598):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x25ef):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2669):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x27a7):numpy/linalg/lapack_litemodule.c:540: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2839): > In function `lapack_lite_dorgqr': > numpy/linalg/lapack_litemodule.c:555: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2883):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x28c8):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2927):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x297f):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x29f9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2afa):numpy/linalg/lapack_litemodule.c:562: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2bbb): > In function `lapack_lite_zgeev': > numpy/linalg/lapack_litemodule.c:585: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c0b):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c50):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2cb0):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d04):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d82):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2e2c):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2f6b):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2fb9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x311b):numpy/linalg/lapack_litemodule.c:601: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31f4): > In function `lapack_lite_zgelsd': > numpy/linalg/lapack_litemodule.c:626: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3244):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3289):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x32ef):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3340):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x33c8):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3471):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35b1):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35ff):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x376f):numpy/linalg/lapack_litemodule.c:641: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x37ef): > In function `lapack_lite_zgesv': > numpy/linalg/lapack_litemodule.c:658: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3839):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x387e):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x38d2):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3927):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x399e):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3ada):numpy/linalg/lapack_litemodule.c:667: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bae): > In function `lapack_lite_zgesdd': > numpy/linalg/lapack_litemodule.c:691: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bfe):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3c43):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cab):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cff):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3d82):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3e2c):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3f70):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3fbe):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4195):numpy/linalg/lapack_litemodule.c:708: > undefined reference to `Py_BuildValue' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x41ab):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x422b): > In function `lapack_lite_zgetrf': > numpy/linalg/lapack_litemodule.c:724: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4263):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42ae):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42fe):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4355):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4435):numpy/linalg/lapack_litemodule.c:732: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44b4): > In function `lapack_lite_zpotrf': > numpy/linalg/lapack_litemodule.c:746: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44e9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x452d):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x458f):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460a):numpy/linalg/lapack_litemodule.c:751: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46af): > In function `lapack_lite_zgeqrf': > numpy/linalg/lapack_litemodule.c:764: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46f9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x473e):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4798):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x47ef):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4869):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x49a7):numpy/linalg/lapack_litemodule.c:774: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a39): > In function `lapack_lite_zungqr': > numpy/linalg/lapack_litemodule.c:787: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a83):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ac8):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b27):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b7f):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4bf9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4cfa):numpy/linalg/lapack_litemodule.c:797: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d58): > In function `initlapack_lite': > numpy/linalg/lapack_litemodule.c:858: undefined reference to > `Py_InitModule4' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d71): > In function `initlapack_lite': > > build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1190: > undefined reference to `PyImport_ImportModule' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d8d):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1197: > undefined reference to `PyObject_GetAttrString' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4da6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1212: > undefined reference to `PyCObject_Type' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4db5):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: > undefined reference to `PyExc_RuntimeError' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dc9):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: > undefined reference to `PyErr_SetString' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dd7): > In function `initlapack_lite': > numpy/linalg/lapack_litemodule.c:865: undefined reference to `PyErr_Print' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ddd):numpy/linalg/lapack_litemodule.c:865: > undefined reference to `PyExc_ImportError' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4df1):numpy/linalg/lapack_litemodule.c:865: > undefined reference to `PyErr_SetString' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e18): > In function `initlapack_lite': > > build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1194: > undefined reference to `PyExc_ImportError' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e26):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: > undefined reference to `PyErr_SetString' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e46):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1217: > undefined reference to `PyCObject_AsVoidPtr' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e88):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: > undefined reference to `PyExc_RuntimeError' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e96):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ea1):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: > undefined reference to `PyExc_RuntimeError' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4eb6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1200: > undefined reference to `PyExc_AttributeError' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f24):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: > undefined reference to `PyExc_RuntimeError' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f2e):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f46): > In function `initlapack_lite': > numpy/linalg/lapack_litemodule.c:866: undefined reference to > `PyModule_GetDict' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f66):numpy/linalg/lapack_litemodule.c:867: > undefined reference to `PyErr_NewException' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f82):numpy/linalg/lapack_litemodule.c:868: > undefined reference to `PyDict_SetItemString' > build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x70): > In function `xerbla_': > numpy/linalg/python_xerbla.c:35: undefined reference to `PyExc_ValueError' > > build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x7e):numpy/linalg/python_xerbla.c:35: > undefined reference to `PyErr_SetString' > collect2: ld returned 1 exit status > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrocher at enthought.com Fri Oct 15 11:02:54 2010 From: jrocher at enthought.com (Jonathan Rocher) Date: Fri, 15 Oct 2010 10:02:54 -0500 Subject: [Numpy-discussion] Please help a newbie install NUMPY In-Reply-To: References: Message-ID: Hi, You might want to try using easy_install > sudo easy_install numpy For some doc about it, see http://peak.telecommunity.com/DevCenter/EasyInstall Jonathan On Fri, Oct 15, 2010 at 9:31 AM, P Sanjey wrote: > Please help-I am a newbie and I wanted to try installing numpy on a > local /home/usr directory but got the following errors-I am not sure > where to even begin fixing this problem and any help would be useful > I just did the standard > python setup.py build and got the following (loooooong) error message > > > ********************************************************** > non-existing path in 'numpy/distutils': 'site.cfg' > F2PY Version 1 > blas_opt_info: > blas_mkl_info: > libraries mkl,vml,guide not found in /home/sanjey/lib > libraries mkl,vml,guide not found in /usr/local/lib > libraries mkl,vml,guide not found in /usr/lib > NOT AVAILABLE > > atlas_blas_threads_info: > Setting PTATLAS=ATLAS > libraries ptf77blas,ptcblas,atlas not found in /home/sanjey/lib > libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib > libraries ptf77blas,ptcblas,atlas not found in /usr/lib/sse2 > libraries ptf77blas,ptcblas,atlas not found in /usr/lib > NOT AVAILABLE > > atlas_blas_info: > libraries f77blas,cblas,atlas not found in /home/sanjey/lib > libraries f77blas,cblas,atlas not found in /usr/local/lib > libraries f77blas,cblas,atlas not found in /usr/lib/sse2 > libraries f77blas,cblas,atlas not found in /usr/lib > NOT AVAILABLE > > blas_info: > libraries blas not found in /home/sanjey/lib > libraries blas not found in /usr/local/lib > FOUND: > libraries = ['blas'] > library_dirs = ['/usr/lib'] > language = f77 > > FOUND: > libraries = ['blas'] > library_dirs = ['/usr/lib'] > define_macros = [('NO_ATLAS_INFO', 1)] > language = f77 > > lapack_opt_info: > lapack_mkl_info: > mkl_info: > libraries mkl,vml,guide not found in /home/sanjey/lib > libraries mkl,vml,guide not found in /usr/local/lib > libraries mkl,vml,guide not found in /usr/lib > NOT AVAILABLE > > NOT AVAILABLE > > atlas_threads_info: > Setting PTATLAS=ATLAS > libraries ptf77blas,ptcblas,atlas not found in /home/sanjey/lib > libraries lapack_atlas not found in /home/sanjey/lib > libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib > libraries lapack_atlas not found in /usr/local/lib > libraries ptf77blas,ptcblas,atlas not found in /usr/lib/sse2 > libraries lapack_atlas not found in /usr/lib/sse2 > libraries ptf77blas,ptcblas,atlas not found in /usr/lib > libraries lapack_atlas not found in /usr/lib > numpy.distutils.system_info.atlas_threads_info > NOT AVAILABLE > > atlas_info: > libraries f77blas,cblas,atlas not found in /home/sanjey/lib > libraries lapack_atlas not found in /home/sanjey/lib > libraries f77blas,cblas,atlas not found in /usr/local/lib > libraries lapack_atlas not found in /usr/local/lib > libraries f77blas,cblas,atlas not found in /usr/lib/sse2 > libraries lapack_atlas not found in /usr/lib/sse2 > libraries f77blas,cblas,atlas not found in /usr/lib > libraries lapack_atlas not found in /usr/lib > numpy.distutils.system_info.atlas_info > NOT AVAILABLE > > lapack_info: > libraries lapack not found in /home/sanjey/lib > libraries lapack not found in /usr/local/lib > FOUND: > libraries = ['lapack'] > library_dirs = ['/usr/lib'] > language = f77 > > FOUND: > libraries = ['lapack', 'blas'] > library_dirs = ['/usr/lib'] > define_macros = [('NO_ATLAS_INFO', 1)] > language = f77 > > running build > running config_cc > unifing config_cc, config, build_clib, build_ext, build commands > --compiler options > running config_fc > unifing config_fc, config, build_clib, build_ext, build commands > --fcompiler options > running build_src > 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 library "npymath" sources > customize GnuFCompiler > Found executable /usr/bin/g77 > gnu: no Fortran 90 compiler found > gnu: no Fortran 90 compiler found > customize GnuFCompiler > gnu: no Fortran 90 compiler found > gnu: no Fortran 90 compiler found > customize GnuFCompiler using config > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > gcc -m32 -pthread _configtest.o -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'exp' > gcc -m32 -pthread _configtest.o -o _configtest > _configtest.o(.text+0x19): In function `main': > /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' > collect2: ld returned 1 exit status > _configtest.o(.text+0x19): In function `main': > /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' > collect2: ld returned 1 exit status > failure. > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'exp' > gcc -m32 -pthread _configtest.o -lm -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > creating build/src.linux-x86_64-2.4/numpy/core > creating build/src.linux-x86_64-2.4/numpy/core/src > creating build/src.linux-x86_64-2.4/numpy/core/src/npymath > conv_template:> > build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math.c > conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/npymath/ieee754.c > conv_template:> > build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math_complex.c > building extension "numpy.core._sort" sources > Generating build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:5: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:5: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:5: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:5: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o _configtest.c _configtest.o > _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c > _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:5: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o _configtest.c _configtest.o > _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c > _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o > _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:5: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:7: error: `SIZEOF_LONGDOUBLE' undeclared (first use in > this function) > _configtest.c:7: error: (Each undeclared identifier is reported only once > _configtest.c:7: error: for each function it appears in.) > _configtest.c:5: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:7: error: `SIZEOF_LONGDOUBLE' undeclared (first use in > this function) > _configtest.c:7: error: (Each undeclared identifier is reported only once > _configtest.c:7: error: for each function it appears in.) > failure. > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o _configtest.c _configtest.o > _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c > _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o > _configtest.c _configtest.o _configtest.c _configtest.o _configtest.c > _configtest.o _configtest.c _configtest.o _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:5: error: size of array `test_array' is negative > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:6: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:6: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:5: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:6: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:6: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:5: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'exp' > gcc -m32 -pthread _configtest.o -o _configtest > _configtest.o(.text+0x19): In function `main': > /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' > collect2: ld returned 1 exit status > _configtest.o(.text+0x19): In function `main': > /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' > collect2: ld returned 1 exit status > failure. > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'exp' > gcc -m32 -pthread _configtest.o -lm -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'asin' > _configtest.c:2: warning: conflicting types for built-in function 'cos' > _configtest.c:3: warning: conflicting types for built-in function 'log' > _configtest.c:4: warning: conflicting types for built-in function 'fabs' > _configtest.c:5: warning: conflicting types for built-in function 'tanh' > _configtest.c:6: warning: conflicting types for built-in function 'atan' > _configtest.c:7: warning: conflicting types for built-in function 'acos' > _configtest.c:8: warning: conflicting types for built-in function 'floor' > _configtest.c:9: warning: conflicting types for built-in function 'fmod' > _configtest.c:10: warning: conflicting types for built-in function 'sqrt' > _configtest.c:11: warning: conflicting types for built-in function 'cosh' > _configtest.c:12: warning: conflicting types for built-in function 'modf' > _configtest.c:13: warning: conflicting types for built-in function 'sinh' > _configtest.c:14: warning: conflicting types for built-in function 'frexp' > _configtest.c:15: warning: conflicting types for built-in function 'exp' > _configtest.c:16: warning: conflicting types for built-in function 'tan' > _configtest.c:17: warning: conflicting types for built-in function 'ceil' > _configtest.c:18: warning: conflicting types for built-in function 'log10' > _configtest.c:19: warning: conflicting types for built-in function 'sin' > _configtest.c:20: warning: conflicting types for built-in function 'ldexp' > gcc -m32 -pthread _configtest.o -lm -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'expm1' > _configtest.c:2: warning: conflicting types for built-in function 'log2' > _configtest.c:3: warning: conflicting types for built-in function 'pow' > _configtest.c:4: warning: conflicting types for built-in function 'rint' > _configtest.c:5: warning: conflicting types for built-in function 'atanh' > _configtest.c:6: warning: conflicting types for built-in function > 'copysign' > _configtest.c:7: warning: conflicting types for built-in function 'asinh' > _configtest.c:8: warning: conflicting types for built-in function 'atan2' > _configtest.c:9: warning: conflicting types for built-in function 'hypot' > _configtest.c:10: warning: conflicting types for built-in function 'acosh' > _configtest.c:11: warning: conflicting types for built-in function 'exp2' > _configtest.c:12: warning: conflicting types for built-in function 'log1p' > _configtest.c:13: warning: conflicting types for built-in function > 'nextafter' > _configtest.c:14: warning: conflicting types for built-in function 'trunc' > gcc -m32 -pthread _configtest.o -lm -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'cosf' > _configtest.c:2: warning: conflicting types for built-in function 'coshf' > _configtest.c:3: warning: conflicting types for built-in function 'rintf' > _configtest.c:4: warning: conflicting types for built-in function 'fabsf' > _configtest.c:5: warning: conflicting types for built-in function 'floorf' > _configtest.c:6: warning: conflicting types for built-in function > 'nextafterf' > _configtest.c:7: warning: conflicting types for built-in function 'tanhf' > _configtest.c:8: warning: conflicting types for built-in function 'log10f' > _configtest.c:9: warning: conflicting types for built-in function 'logf' > _configtest.c:10: warning: conflicting types for built-in function 'sinhf' > _configtest.c:11: warning: conflicting types for built-in function 'acosf' > _configtest.c:12: warning: conflicting types for built-in function 'sqrtf' > _configtest.c:13: warning: conflicting types for built-in function 'ldexpf' > _configtest.c:14: warning: conflicting types for built-in function 'hypotf' > _configtest.c:15: warning: conflicting types for built-in function 'log2f' > _configtest.c:16: warning: conflicting types for built-in function 'exp2f' > _configtest.c:17: warning: conflicting types for built-in function 'atanf' > _configtest.c:18: warning: conflicting types for built-in function 'fmodf' > _configtest.c:19: warning: conflicting types for built-in function 'atan2f' > _configtest.c:20: warning: conflicting types for built-in function 'modff' > _configtest.c:21: warning: conflicting types for built-in function 'ceilf' > _configtest.c:22: warning: conflicting types for built-in function 'log1pf' > _configtest.c:23: warning: conflicting types for built-in function 'asinf' > _configtest.c:24: warning: conflicting types for built-in function > 'copysignf' > _configtest.c:25: warning: conflicting types for built-in function 'acoshf' > _configtest.c:26: warning: conflicting types for built-in function 'sinf' > _configtest.c:27: warning: conflicting types for built-in function 'tanf' > _configtest.c:28: warning: conflicting types for built-in function 'atanhf' > _configtest.c:29: warning: conflicting types for built-in function 'truncf' > _configtest.c:30: warning: conflicting types for built-in function 'asinhf' > _configtest.c:31: warning: conflicting types for built-in function 'frexpf' > _configtest.c:32: warning: conflicting types for built-in function 'powf' > _configtest.c:33: warning: conflicting types for built-in function 'expf' > _configtest.c:34: warning: conflicting types for built-in function 'expm1f' > gcc -m32 -pthread _configtest.o -lm -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'tanhl' > _configtest.c:2: warning: conflicting types for built-in function 'log10l' > _configtest.c:3: warning: conflicting types for built-in function > 'nextafterl' > _configtest.c:4: warning: conflicting types for built-in function 'coshl' > _configtest.c:5: warning: conflicting types for built-in function 'cosl' > _configtest.c:6: warning: conflicting types for built-in function 'floorl' > _configtest.c:7: warning: conflicting types for built-in function 'rintl' > _configtest.c:8: warning: conflicting types for built-in function 'fabsl' > _configtest.c:9: warning: conflicting types for built-in function 'acosl' > _configtest.c:10: warning: conflicting types for built-in function 'ldexpl' > _configtest.c:11: warning: conflicting types for built-in function 'sqrtl' > _configtest.c:12: warning: conflicting types for built-in function 'logl' > _configtest.c:13: warning: conflicting types for built-in function 'expm1l' > _configtest.c:14: warning: conflicting types for built-in function 'hypotl' > _configtest.c:15: warning: conflicting types for built-in function 'log2l' > _configtest.c:16: warning: conflicting types for built-in function > 'copysignl' > _configtest.c:17: warning: conflicting types for built-in function 'exp2l' > _configtest.c:18: warning: conflicting types for built-in function 'atanl' > _configtest.c:19: warning: conflicting types for built-in function 'frexpl' > _configtest.c:20: warning: conflicting types for built-in function 'atan2l' > _configtest.c:21: warning: conflicting types for built-in function 'sinhl' > _configtest.c:22: warning: conflicting types for built-in function 'fmodl' > _configtest.c:23: warning: conflicting types for built-in function 'log1pl' > _configtest.c:24: warning: conflicting types for built-in function 'asinl' > _configtest.c:25: warning: conflicting types for built-in function 'ceill' > _configtest.c:26: warning: conflicting types for built-in function 'sinl' > _configtest.c:27: warning: conflicting types for built-in function 'acoshl' > _configtest.c:28: warning: conflicting types for built-in function 'atanhl' > _configtest.c:29: warning: conflicting types for built-in function 'tanl' > _configtest.c:30: warning: conflicting types for built-in function 'truncl' > _configtest.c:31: warning: conflicting types for built-in function 'powl' > _configtest.c:32: warning: conflicting types for built-in function 'expl' > _configtest.c:33: warning: conflicting types for built-in function 'modfl' > _configtest.c:34: warning: conflicting types for built-in function 'asinhl' > gcc -m32 -pthread _configtest.o -lm -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:6: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:6: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:6: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:6: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'cexp' > _configtest.c:3: warning: conflicting types for built-in function 'ccos' > _configtest.c:4: warning: conflicting types for built-in function 'cimag' > _configtest.c:5: warning: conflicting types for built-in function 'cabs' > _configtest.c:6: warning: conflicting types for built-in function 'cpow' > _configtest.c:7: warning: conflicting types for built-in function 'csqrt' > _configtest.c:8: warning: conflicting types for built-in function 'carg' > _configtest.c:9: warning: conflicting types for built-in function 'creal' > _configtest.c:10: warning: conflicting types for built-in function 'csin' > gcc -m32 -pthread _configtest.o -lm -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'ccosf' > _configtest.c:2: warning: conflicting types for built-in function 'cargf' > _configtest.c:3: warning: conflicting types for built-in function 'csqrtf' > _configtest.c:4: warning: conflicting types for built-in function 'cpowf' > _configtest.c:5: warning: conflicting types for built-in function 'cexpf' > _configtest.c:6: warning: conflicting types for built-in function 'crealf' > _configtest.c:7: warning: conflicting types for built-in function 'csinf' > _configtest.c:8: warning: conflicting types for built-in function 'cabsf' > _configtest.c:10: warning: conflicting types for built-in function 'cimagf' > gcc -m32 -pthread _configtest.o -lm -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'csqrtl' > _configtest.c:2: warning: conflicting types for built-in function 'cargl' > _configtest.c:3: warning: conflicting types for built-in function 'cexpl' > _configtest.c:4: warning: conflicting types for built-in function 'ccosl' > _configtest.c:5: warning: conflicting types for built-in function 'cpowl' > _configtest.c:6: warning: conflicting types for built-in function 'cimagl' > _configtest.c:7: warning: conflicting types for built-in function 'csinl' > _configtest.c:8: warning: conflicting types for built-in function 'creall' > _configtest.c:10: warning: conflicting types for built-in function 'cabsl' > gcc -m32 -pthread _configtest.o -lm -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:5: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:7: error: `Py_UNICODE_WIDE' undeclared (first use in > this function) > _configtest.c:7: error: (Each undeclared identifier is reported only once > _configtest.c:7: error: for each function it appears in.) > _configtest.c:5: warning: function declaration isn't a prototype > _configtest.c: In function `main': > _configtest.c:7: error: `Py_UNICODE_WIDE' undeclared (first use in > this function) > _configtest.c:7: error: (Each undeclared identifier is reported only once > _configtest.c:7: error: for each function it appears in.) > failure. > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > removing: _configtest.c _configtest.o > ('File:', 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h') > #define HAVE_ENDIAN_H 1 > #define SIZEOF_PY_INTPTR_T 4 > #define SIZEOF_PY_LONG_LONG 8 > #define MATHLIB m > #define HAVE_SIN > #define HAVE_COS > #define HAVE_TAN > #define HAVE_SINH > #define HAVE_COSH > #define HAVE_TANH > #define HAVE_FABS > #define HAVE_FLOOR > #define HAVE_CEIL > #define HAVE_SQRT > #define HAVE_LOG10 > #define HAVE_LOG > #define HAVE_EXP > #define HAVE_ASIN > #define HAVE_ACOS > #define HAVE_ATAN > #define HAVE_FMOD > #define HAVE_MODF > #define HAVE_FREXP > #define HAVE_LDEXP > #define HAVE_EXPM1 > #define HAVE_LOG1P > #define HAVE_ACOSH > #define HAVE_ASINH > #define HAVE_ATANH > #define HAVE_RINT > #define HAVE_TRUNC > #define HAVE_EXP2 > #define HAVE_LOG2 > #define HAVE_HYPOT > #define HAVE_ATAN2 > #define HAVE_POW > #define HAVE_COPYSIGN > #define HAVE_NEXTAFTER > #define HAVE_SINF > #define HAVE_COSF > #define HAVE_TANF > #define HAVE_SINHF > #define HAVE_COSHF > #define HAVE_TANHF > #define HAVE_FABSF > #define HAVE_FLOORF > #define HAVE_CEILF > #define HAVE_RINTF > #define HAVE_TRUNCF > #define HAVE_SQRTF > #define HAVE_LOG10F > #define HAVE_LOGF > #define HAVE_LOG1PF > #define HAVE_EXPF > #define HAVE_EXPM1F > #define HAVE_ASINF > #define HAVE_ACOSF > #define HAVE_ATANF > #define HAVE_ASINHF > #define HAVE_ACOSHF > #define HAVE_ATANHF > #define HAVE_HYPOTF > #define HAVE_ATAN2F > #define HAVE_POWF > #define HAVE_FMODF > #define HAVE_MODFF > #define HAVE_FREXPF > #define HAVE_LDEXPF > #define HAVE_EXP2F > #define HAVE_LOG2F > #define HAVE_COPYSIGNF > #define HAVE_NEXTAFTERF > #define HAVE_SINL > #define HAVE_COSL > #define HAVE_TANL > #define HAVE_SINHL > #define HAVE_COSHL > #define HAVE_TANHL > #define HAVE_FABSL > #define HAVE_FLOORL > #define HAVE_CEILL > #define HAVE_RINTL > #define HAVE_TRUNCL > #define HAVE_SQRTL > #define HAVE_LOG10L > #define HAVE_LOGL > #define HAVE_LOG1PL > #define HAVE_EXPL > #define HAVE_EXPM1L > #define HAVE_ASINL > #define HAVE_ACOSL > #define HAVE_ATANL > #define HAVE_ASINHL > #define HAVE_ACOSHL > #define HAVE_ATANHL > #define HAVE_HYPOTL > #define HAVE_ATAN2L > #define HAVE_POWL > #define HAVE_FMODL > #define HAVE_MODFL > #define HAVE_FREXPL > #define HAVE_LDEXPL > #define HAVE_EXP2L > #define HAVE_LOG2L > #define HAVE_COPYSIGNL > #define HAVE_NEXTAFTERL > #define HAVE_DECL_ISNAN > #define HAVE_DECL_ISINF > #define HAVE_DECL_SIGNBIT > #define HAVE_DECL_ISFINITE > #define HAVE_COMPLEX_H > #define HAVE_CREAL > #define HAVE_CIMAG > #define HAVE_CABS > #define HAVE_CARG > #define HAVE_CEXP > #define HAVE_CSQRT > #define HAVE_CLOG > #define HAVE_CCOS > #define HAVE_CSIN > #define HAVE_CPOW > #define HAVE_CREALF > #define HAVE_CIMAGF > #define HAVE_CABSF > #define HAVE_CARGF > #define HAVE_CEXPF > #define HAVE_CSQRTF > #define HAVE_CLOGF > #define HAVE_CCOSF > #define HAVE_CSINF > #define HAVE_CPOWF > #define HAVE_CREALL > #define HAVE_CIMAGL > #define HAVE_CABSL > #define HAVE_CARGL > #define HAVE_CEXPL > #define HAVE_CSQRTL > #define HAVE_CLOGL > #define HAVE_CCOSL > #define HAVE_CSINL > #define HAVE_CPOWL > #define HAVE_LDOUBLE_INTEL_EXTENDED_12_BYTES_LE 1 > #ifndef __cplusplus > /* #undef inline */ > #endif > > #ifndef _NPY_NPY_CONFIG_H_ > #error config.h should never be included directly, include npy_config.h > instead > #endif > > EOF > adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' > to sources. > Generating > build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'exp' > gcc -m32 -pthread _configtest.o -o _configtest > _configtest.o(.text+0x19): In function `main': > /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' > collect2: ld returned 1 exit status > _configtest.o(.text+0x19): In function `main': > /home/sanjey/numpy-1.5.0/_configtest.c:6: undefined reference to `exp' > collect2: ld returned 1 exit status > failure. > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:1: warning: conflicting types for built-in function 'exp' > gcc -m32 -pthread _configtest.o -lm -o _configtest > success! > removing: _configtest.c _configtest.o _configtest > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:5: warning: function declaration isn't a prototype > success! > removing: _configtest.c _configtest.o > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > _configtest.c:4: warning: function declaration isn't a prototype > _configtest.c:5:18: warning: extra tokens at end of #ifndef directive > _configtest.c: In function `main': > _configtest.c:4: warning: control reaches end of non-void function > success! > removing: _configtest.c _configtest.o > File: build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h > #define NPY_HAVE_ENDIAN_H 1 > #define NPY_SIZEOF_SHORT SIZEOF_SHORT > #define NPY_SIZEOF_INT SIZEOF_INT > #define NPY_SIZEOF_LONG SIZEOF_LONG > #define NPY_SIZEOF_FLOAT 4 > #define NPY_SIZEOF_COMPLEX_FLOAT 8 > #define NPY_SIZEOF_DOUBLE 8 > #define NPY_SIZEOF_COMPLEX_DOUBLE 16 > #define NPY_SIZEOF_LONGDOUBLE 12 > #define NPY_SIZEOF_COMPLEX_LONGDOUBLE 24 > #define NPY_SIZEOF_PY_INTPTR_T 4 > #define NPY_SIZEOF_PY_LONG_LONG 8 > #define NPY_SIZEOF_LONGLONG 8 > #define NPY_NO_SMP 1 > #define NPY_HAVE_DECL_ISNAN > #define NPY_HAVE_DECL_ISINF > #define NPY_HAVE_DECL_SIGNBIT > #define NPY_HAVE_DECL_ISFINITE > #define NPY_USE_C99_COMPLEX > #define NPY_HAVE_COMPLEX_DOUBLE 1 > #define NPY_HAVE_COMPLEX_FLOAT 1 > #define NPY_HAVE_COMPLEX_LONG_DOUBLE 1 > #define NPY_USE_C99_FORMATS 1 > #define NPY_VISIBILITY_HIDDEN __attribute__((visibility("hidden"))) > #define NPY_ABI_VERSION 0x01000009 > #define NPY_API_VERSION 0x00000004 > > #ifndef __STDC_FORMAT_MACROS > #define __STDC_FORMAT_MACROS 1 > #endif > > EOF > adding > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' > to sources. > executing numpy/core/code_generators/generate_numpy_api.py > adding > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__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/include/numpy/config.h', > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h'] > building extension "numpy.core.multiarray" sources > non-existing path in 'numpy/core': > 'build/src.linux-x86_64-2.4/numpy/core/src/multiarray' > creating build/src.linux-x86_64-2.4/numpy/core/src/multiarray > conv_template:> > build/src.linux-x86_64-2.4/numpy/core/src/multiarray/scalartypes.c > conv_template:> > build/src.linux-x86_64-2.4/numpy/core/src/multiarray/arraytypes.c > adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' > to sources. > adding > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' > to sources. > executing numpy/core/code_generators/generate_numpy_api.py > adding > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h' > to sources. > numpy.core - nothing done with h_files = > ['build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h', > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h'] > building extension "numpy.core.umath" sources > adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' > to sources. > adding > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' > to sources. > executing numpy/core/code_generators/generate_ufunc_api.py > adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__ufunc_api.h' > to sources. > non-existing path in 'numpy/core': > 'build/src.linux-x86_64-2.4/numpy/core/src/umath' > creating build/src.linux-x86_64-2.4/numpy/core/src/umath > conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/umath/loops.c > conv_template:> > build/src.linux-x86_64-2.4/numpy/core/src/umath/umathmodule.c > conv_template:> build/src.linux-x86_64-2.4/numpy/core/src/umath/funcs.inc > adding 'build/src.linux-x86_64-2.4/numpy/core/src/umath' to include_dirs. > numpy.core - nothing done with h_files = > ['build/src.linux-x86_64-2.4/numpy/core/src/umath/funcs.inc', > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h', > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__ufunc_api.h'] > building extension "numpy.core.scalarmath" sources > adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h' > to sources. > adding > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h' > to sources. > executing numpy/core/code_generators/generate_numpy_api.py > adding > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h' > to sources. > executing numpy/core/code_generators/generate_ufunc_api.py > adding 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__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/include/numpy/config.h', > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/_numpyconfig.h', > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h', > 'build/src.linux-x86_64-2.4/numpy/core/include/numpy/__ufunc_api.h'] > building extension "numpy.core._dotblas" sources > building extension "numpy.core.umath_tests" sources > conv_template:> > build/src.linux-x86_64-2.4/numpy/core/src/umath/umath_tests.c > building extension "numpy.core.multiarray_tests" sources > conv_template:> > build/src.linux-x86_64-2.4/numpy/core/src/multiarray/multiarray_tests.c > building extension "numpy.lib._compiled_base" sources > building extension "numpy.numarray._capi" sources > building extension "numpy.fft.fftpack_lite" sources > building extension "numpy.linalg.lapack_lite" sources > creating build/src.linux-x86_64-2.4/numpy/linalg > adding 'numpy/linalg/lapack_litemodule.c' to sources. > adding 'numpy/linalg/python_xerbla.c' to sources. > building extension "numpy.random.mtrand" sources > creating build/src.linux-x86_64-2.4/numpy/random > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/src/private -Inumpy/core/src > -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 -c' > gcc: _configtest.c > gcc -m32 -pthread _configtest.o -o _configtest > _configtest > failure. > removing: _configtest.c _configtest.o _configtest > building data_files sources > build_src: building npy-pkg config files > running build_py > creating build/lib.linux-x86_64-2.4 > creating build/lib.linux-x86_64-2.4/numpy > copying numpy/version.py -> build/lib.linux-x86_64-2.4/numpy > copying numpy/matlib.py -> build/lib.linux-x86_64-2.4/numpy > copying numpy/ctypeslib.py -> build/lib.linux-x86_64-2.4/numpy > copying numpy/setupscons.py -> build/lib.linux-x86_64-2.4/numpy > copying numpy/__init__.py -> build/lib.linux-x86_64-2.4/numpy > copying numpy/setup.py -> build/lib.linux-x86_64-2.4/numpy > copying numpy/dual.py -> build/lib.linux-x86_64-2.4/numpy > copying numpy/_import_tools.py -> build/lib.linux-x86_64-2.4/numpy > copying numpy/add_newdocs.py -> build/lib.linux-x86_64-2.4/numpy > copying build/src.linux-x86_64-2.4/numpy/__config__.py -> > build/lib.linux-x86_64-2.4/numpy > creating build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/from_template.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/npy_pkg_config.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/compat.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/setupscons.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/__init__.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/lib2def.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/interactive.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/info.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/environment.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/setup.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/cpuinfo.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/extension.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/core.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/intelccompiler.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/log.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/__version__.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/unixccompiler.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/misc_util.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/line_endings.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/exec_command.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/conv_template.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/ccompiler.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/mingw32ccompiler.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/system_info.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying numpy/distutils/numpy_distribution.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > copying build/src.linux-x86_64-2.4/numpy/distutils/__config__.py -> > build/lib.linux-x86_64-2.4/numpy/distutils > creating build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/install.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/egg_info.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/install_clib.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/bdist_rpm.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/develop.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/install_data.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/__init__.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/build_py.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/build_src.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/build_clib.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/build_ext.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/autodist.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/install_headers.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/config.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/config_compiler.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/build.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/build_scripts.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/sdist.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > copying numpy/distutils/command/scons.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/command > creating build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/none.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/hpux.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/compaq.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/absoft.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/vast.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/nag.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/__init__.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/sun.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/mips.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/intel.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/gnu.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/g95.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/pg.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/ibm.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > copying numpy/distutils/fcompiler/lahey.py -> > build/lib.linux-x86_64-2.4/numpy/distutils/fcompiler > creating build/lib.linux-x86_64-2.4/numpy/testing > copying numpy/testing/nulltester.py -> > build/lib.linux-x86_64-2.4/numpy/testing > copying numpy/testing/setupscons.py -> > build/lib.linux-x86_64-2.4/numpy/testing > copying numpy/testing/__init__.py -> > build/lib.linux-x86_64-2.4/numpy/testing > copying numpy/testing/setup.py -> build/lib.linux-x86_64-2.4/numpy/testing > copying numpy/testing/decorators.py -> > build/lib.linux-x86_64-2.4/numpy/testing > copying numpy/testing/utils.py -> build/lib.linux-x86_64-2.4/numpy/testing > copying numpy/testing/noseclasses.py -> > build/lib.linux-x86_64-2.4/numpy/testing > copying numpy/testing/numpytest.py -> > build/lib.linux-x86_64-2.4/numpy/testing > copying numpy/testing/nosetester.py -> > build/lib.linux-x86_64-2.4/numpy/testing > creating build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/auxfuncs.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/common_rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/__init__.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/cb_rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/info.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/setup.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/f2py2e.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/cfuncs.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/crackfortran.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/use_rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/diagnose.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/f2py_testing.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/__version__.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/capi_maps.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/func2subr.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/f90mod_rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py > copying numpy/f2py/rules.py -> build/lib.linux-x86_64-2.4/numpy/f2py > creating build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/defchararray.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/numeric.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/__init__.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/info.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/function_base.py -> > build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/getlimits.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/setup.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/fromnumeric.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/shape_base.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/setup_common.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/records.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/memmap.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/arrayprint.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/numerictypes.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/machar.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/_mx_datetime_parser.py -> > build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/scons_support.py -> > build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/_internal.py -> build/lib.linux-x86_64-2.4/numpy/core > copying numpy/core/code_generators/generate_numpy_api.py -> > build/lib.linux-x86_64-2.4/numpy/core > creating build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/_datasource.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/arraysetops.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/index_tricks.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/format.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/__init__.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/info.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/function_base.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/setup.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/arrayterator.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/ufunclike.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/shape_base.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/user_array.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/type_check.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/stride_tricks.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/recfunctions.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/npyio.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/_iotools.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/utils.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/financial.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/twodim_base.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/polynomial.py -> build/lib.linux-x86_64-2.4/numpy/lib > copying numpy/lib/scimath.py -> build/lib.linux-x86_64-2.4/numpy/lib > creating build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/functions.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/alter_code1.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/misc.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/compat.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/setupscons.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/__init__.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/linear_algebra.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/setup.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/random_array.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/user_array.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/alter_code2.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/fft.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/matrix.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/fix_default_axis.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/rng_stats.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/mlab.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/ma.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/ufuncs.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/rng.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/array_printer.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/typeconv.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/precision.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > copying numpy/oldnumeric/arrayfns.py -> > build/lib.linux-x86_64-2.4/numpy/oldnumeric > creating build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/nd_image.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/util.py -> build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/convolve.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/functions.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/alter_code1.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/compat.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/setupscons.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/__init__.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/linear_algebra.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/setup.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/random_array.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/alter_code2.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/fft.py -> build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/matrix.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/numerictypes.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/image.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/mlab.py -> build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/ma.py -> build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/session.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > copying numpy/numarray/ufuncs.py -> > build/lib.linux-x86_64-2.4/numpy/numarray > creating build/lib.linux-x86_64-2.4/numpy/fft > copying numpy/fft/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/fft > copying numpy/fft/__init__.py -> build/lib.linux-x86_64-2.4/numpy/fft > copying numpy/fft/info.py -> build/lib.linux-x86_64-2.4/numpy/fft > copying numpy/fft/setup.py -> build/lib.linux-x86_64-2.4/numpy/fft > copying numpy/fft/fftpack.py -> build/lib.linux-x86_64-2.4/numpy/fft > copying numpy/fft/helper.py -> build/lib.linux-x86_64-2.4/numpy/fft > creating build/lib.linux-x86_64-2.4/numpy/linalg > copying numpy/linalg/setupscons.py -> > build/lib.linux-x86_64-2.4/numpy/linalg > copying numpy/linalg/__init__.py -> build/lib.linux-x86_64-2.4/numpy/linalg > copying numpy/linalg/info.py -> build/lib.linux-x86_64-2.4/numpy/linalg > copying numpy/linalg/setup.py -> build/lib.linux-x86_64-2.4/numpy/linalg > copying numpy/linalg/linalg.py -> build/lib.linux-x86_64-2.4/numpy/linalg > creating build/lib.linux-x86_64-2.4/numpy/random > copying numpy/random/setupscons.py -> > build/lib.linux-x86_64-2.4/numpy/random > copying numpy/random/__init__.py -> build/lib.linux-x86_64-2.4/numpy/random > copying numpy/random/info.py -> build/lib.linux-x86_64-2.4/numpy/random > copying numpy/random/setup.py -> build/lib.linux-x86_64-2.4/numpy/random > creating build/lib.linux-x86_64-2.4/numpy/ma > copying numpy/ma/version.py -> build/lib.linux-x86_64-2.4/numpy/ma > copying numpy/ma/setupscons.py -> build/lib.linux-x86_64-2.4/numpy/ma > copying numpy/ma/__init__.py -> build/lib.linux-x86_64-2.4/numpy/ma > copying numpy/ma/setup.py -> build/lib.linux-x86_64-2.4/numpy/ma > copying numpy/ma/bench.py -> build/lib.linux-x86_64-2.4/numpy/ma > copying numpy/ma/core.py -> build/lib.linux-x86_64-2.4/numpy/ma > copying numpy/ma/testutils.py -> build/lib.linux-x86_64-2.4/numpy/ma > copying numpy/ma/timer_comparison.py -> build/lib.linux-x86_64-2.4/numpy/ma > copying numpy/ma/extras.py -> build/lib.linux-x86_64-2.4/numpy/ma > copying numpy/ma/mrecords.py -> build/lib.linux-x86_64-2.4/numpy/ma > creating build/lib.linux-x86_64-2.4/numpy/matrixlib > copying numpy/matrixlib/setupscons.py -> > build/lib.linux-x86_64-2.4/numpy/matrixlib > copying numpy/matrixlib/__init__.py -> > build/lib.linux-x86_64-2.4/numpy/matrixlib > copying numpy/matrixlib/setup.py -> > build/lib.linux-x86_64-2.4/numpy/matrixlib > copying numpy/matrixlib/defmatrix.py -> > build/lib.linux-x86_64-2.4/numpy/matrixlib > creating build/lib.linux-x86_64-2.4/numpy/compat > copying numpy/compat/setupscons.py -> > build/lib.linux-x86_64-2.4/numpy/compat > copying numpy/compat/__init__.py -> build/lib.linux-x86_64-2.4/numpy/compat > copying numpy/compat/setup.py -> build/lib.linux-x86_64-2.4/numpy/compat > copying numpy/compat/py3k.py -> build/lib.linux-x86_64-2.4/numpy/compat > copying numpy/compat/_inspect.py -> build/lib.linux-x86_64-2.4/numpy/compat > creating build/lib.linux-x86_64-2.4/numpy/polynomial > copying numpy/polynomial/__init__.py -> > build/lib.linux-x86_64-2.4/numpy/polynomial > copying numpy/polynomial/setup.py -> > build/lib.linux-x86_64-2.4/numpy/polynomial > copying numpy/polynomial/chebyshev.py -> > build/lib.linux-x86_64-2.4/numpy/polynomial > copying numpy/polynomial/polynomial.py -> > build/lib.linux-x86_64-2.4/numpy/polynomial > copying numpy/polynomial/polyutils.py -> > build/lib.linux-x86_64-2.4/numpy/polynomial > copying numpy/polynomial/polytemplate.py -> > build/lib.linux-x86_64-2.4/numpy/polynomial > creating build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/byteswapping.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/glossary.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/indexing.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/misc.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/internals.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/__init__.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/creation.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/jargon.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/basics.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/io.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/methods_vs_functions.py -> > build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/broadcasting.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/constants.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/howtofind.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/ufuncs.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/subclassing.py -> build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/structured_arrays.py -> > build/lib.linux-x86_64-2.4/numpy/doc > copying numpy/doc/performance.py -> build/lib.linux-x86_64-2.4/numpy/doc > running build_clib > customize UnixCCompiler > customize UnixCCompiler using build_clib > building 'npymath' library > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > creating build/temp.linux-x86_64-2.4 > creating build/temp.linux-x86_64-2.4/build > creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4 > creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy > creating build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core > creating > build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src > creating > build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/npymath > compile options: '-Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math.c > In file included from numpy/core/src/private/npy_config.h:4, > from numpy/core/src/npymath/npy_math_private.h:24, > from numpy/core/src/npymath/npy_math.c.src:56: > build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: > warning: "HAVE_HYPOT" redefined > In file included from /home/sanjey/include/python2.4/Python.h:8, > from numpy/core/src/npymath/npy_math_private.h:21, > from numpy/core/src/npymath/npy_math.c.src:56: > /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the > location of the previous definition > gcc: build/src.linux-x86_64-2.4/numpy/core/src/npymath/ieee754.c > In file included from numpy/core/src/private/npy_config.h:4, > from numpy/core/src/npymath/npy_math_common.h:8, > from numpy/core/src/npymath/ieee754.c.src:7: > build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: > warning: "HAVE_HYPOT" redefined > In file included from /home/sanjey/include/python2.4/Python.h:8, > from numpy/core/src/npymath/npy_math_common.h:4, > from numpy/core/src/npymath/ieee754.c.src:7: > /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the > location of the previous definition > gcc: build/src.linux-x86_64-2.4/numpy/core/src/npymath/npy_math_complex.c > In file included from numpy/core/src/private/npy_config.h:4, > from numpy/core/src/npymath/npy_math_common.h:8, > from numpy/core/src/npymath/npy_math_complex.c.src:31: > build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: > warning: "HAVE_HYPOT" redefined > In file included from /home/sanjey/include/python2.4/Python.h:8, > from numpy/core/src/npymath/npy_math_common.h:4, > from numpy/core/src/npymath/npy_math_complex.c.src:31: > /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the > location of the previous definition > ar: adding 3 object files to build/temp.linux-x86_64-2.4/libnpymath.a > running build_ext > customize UnixCCompiler > customize UnixCCompiler using build_ext > customize GnuFCompiler > gnu: no Fortran 90 compiler found > gnu: no Fortran 90 compiler found > customize GnuFCompiler > gnu: no Fortran 90 compiler found > gnu: no Fortran 90 compiler found > customize GnuFCompiler using build_ext > building 'numpy.core._sort' extension > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: build/src.linux-x86_64-2.4/numpy/core/src/_sortmodule.c > In file included from numpy/core/src/private/npy_config.h:4, > from numpy/core/src/_sortmodule.c.src:34: > build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: > warning: "HAVE_HYPOT" redefined > In file included from /home/sanjey/include/python2.4/Python.h:8, > from numpy/core/src/_sortmodule.c.src:30: > /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the > location of the previous definition > gcc -m32 -pthread -shared > > build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/_sortmodule.o > -Lbuild/temp.linux-x86_64-2.4 -lm -o > build/lib.linux-x86_64-2.4/numpy/core/_sort.so > building 'numpy.core.multiarray' extension > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > creating build/temp.linux-x86_64-2.4/numpy > creating build/temp.linux-x86_64-2.4/numpy/core > creating build/temp.linux-x86_64-2.4/numpy/core/src > creating build/temp.linux-x86_64-2.4/numpy/core/src/multiarray > compile options: '-Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: numpy/core/src/multiarray/multiarraymodule_onefile.c > In file included from numpy/core/src/private/npy_config.h:4, > from numpy/core/src/multiarray/common.c:8, > from > numpy/core/src/multiarray/multiarraymodule_onefile.c:8: > build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: > warning: "HAVE_HYPOT" redefined > In file included from /home/sanjey/include/python2.4/Python.h:8, > from numpy/core/src/multiarray/common.c:2, > from > numpy/core/src/multiarray/multiarraymodule_onefile.c:8: > /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the > location of the previous definition > In file included from > numpy/core/src/multiarray/multiarraymodule_onefile.c:26: > numpy/core/src/multiarray/methods.c: In function `NpyArg_ParseKeywords': > numpy/core/src/multiarray/methods.c:41: warning: passing arg 3 of > `PyArg_VaParseTupleAndKeywords' discards qualifiers from pointer > target type > numpy/core/src/multiarray/flagsobject.c: In function > `arrayflags_richcompare': > numpy/core/src/multiarray/flagsobject.c:568: warning: 'cmp' might be > used uninitialized in this function > numpy/core/src/multiarray/multiarraymodule_onefile.c: At top level: > numpy/core/include/numpy/npy_3kcompat.h:331: warning: > 'simple_capsule_dtor' defined but not used > numpy/core/src/multiarray/buffer.c:777: warning: > '_descriptor_from_pep3118_format' defined but not used > numpy/core/src/multiarray/arraytypes.c.src:93: warning: > '_SEQUENCE_MESSAGE' defined but not used > numpy/core/src/multiarray/mapping.c:75: warning: '_array_ass_item' > defined but not used > gcc -m32 -pthread -shared > > build/temp.linux-x86_64-2.4/numpy/core/src/multiarray/multiarraymodule_onefile.o > -Lbuild/temp.linux-x86_64-2.4 -lnpymath -lm -o > build/lib.linux-x86_64-2.4/numpy/core/multiarray.so > building 'numpy.core.umath' extension > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > creating build/temp.linux-x86_64-2.4/numpy/core/src/umath > compile options: '-Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath > -Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: numpy/core/src/umath/umathmodule_onefile.c > In file included from numpy/core/src/private/npy_config.h:4, > from numpy/core/src/umath/loops.c.src:7, > from numpy/core/src/umath/umathmodule_onefile.c:1: > build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: > warning: "HAVE_HYPOT" redefined > In file included from /home/sanjey/include/python2.4/Python.h:8, > from numpy/core/src/umath/loops.c.src:5, > from numpy/core/src/umath/umathmodule_onefile.c:1: > /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the > location of the previous definition > numpy/core/include/numpy/npy_3kcompat.h:331: warning: > 'simple_capsule_dtor' defined but not used > numpy/core/src/umath/loops.c.src:1258: warning: > 'CLONGDOUBLE_logical_and' defined but not used > numpy/core/src/umath/loops.c.src:1258: warning: > 'CLONGDOUBLE_logical_or' defined but not used > numpy/core/src/umath/loops.c.src:1271: warning: > 'CLONGDOUBLE_logical_xor' defined but not used > numpy/core/src/umath/loops.c.src:1285: warning: > 'CLONGDOUBLE_logical_not' defined but not used > numpy/core/src/umath/loops.c.src:1342: warning: > 'CLONGDOUBLE_ones_like' defined but not used > numpy/core/src/umath/loops.c.src:1399: warning: 'CLONGDOUBLE_maximum' > defined but not used > numpy/core/src/umath/loops.c.src:1399: warning: 'CLONGDOUBLE_minimum' > defined but not used > numpy/core/src/umath/loops.c.src:1423: warning: 'CLONGDOUBLE_fmax' > defined but not used > numpy/core/src/umath/loops.c.src:1423: warning: 'CLONGDOUBLE_fmin' > defined but not used > gcc -m32 -pthread -shared > build/temp.linux-x86_64-2.4/numpy/core/src/umath/umathmodule_onefile.o > -Lbuild/temp.linux-x86_64-2.4 -lnpymath -lm -o > build/lib.linux-x86_64-2.4/numpy/core/umath.so > building 'numpy.core.scalarmath' extension > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > compile options: '-Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: build/src.linux-x86_64-2.4/numpy/core/src/scalarmathmodule.c > numpy/core/include/numpy/npy_3kcompat.h:331: warning: > 'simple_capsule_dtor' defined but not used > gcc -m32 -pthread -shared > > build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/scalarmathmodule.o > -Lbuild/temp.linux-x86_64-2.4 -lm -o > build/lib.linux-x86_64-2.4/numpy/core/scalarmath.so > building 'numpy.core.umath_tests' extension > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > creating > build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/umath > compile options: '-Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: build/src.linux-x86_64-2.4/numpy/core/src/umath/umath_tests.c > In file included from numpy/core/src/private/npy_config.h:4, > from numpy/core/src/umath/umath_tests.c.src:14: > build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: > warning: "HAVE_HYPOT" redefined > In file included from /home/sanjey/include/python2.4/Python.h:8, > from numpy/core/src/umath/umath_tests.c.src:8: > /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the > location of the previous definition > numpy/core/include/numpy/npy_3kcompat.h:331: warning: > 'simple_capsule_dtor' defined but not used > gcc -m32 -pthread -shared > > build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/umath/umath_tests.o > -Lbuild/temp.linux-x86_64-2.4 -o > build/lib.linux-x86_64-2.4/numpy/core/umath_tests.so > building 'numpy.core.multiarray_tests' extension > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > creating > build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/multiarray > compile options: '-Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: > build/src.linux-x86_64-2.4/numpy/core/src/multiarray/multiarray_tests.c > numpy/core/include/numpy/npy_3kcompat.h:331: warning: > 'simple_capsule_dtor' defined but not used > gcc -m32 -pthread -shared > > build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/numpy/core/src/multiarray/multiarray_tests.o > -Lbuild/temp.linux-x86_64-2.4 -o > build/lib.linux-x86_64-2.4/numpy/core/multiarray_tests.so > building 'numpy.lib._compiled_base' extension > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > creating build/temp.linux-x86_64-2.4/numpy/lib > creating build/temp.linux-x86_64-2.4/numpy/lib/src > compile options: '-Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: numpy/lib/src/_compiled_base.c > In file included from numpy/core/src/private/npy_config.h:4, > from numpy/lib/src/_compiled_base.c:4: > build/src.linux-x86_64-2.4/numpy/core/include/numpy/config.h:34:1: > warning: "HAVE_HYPOT" redefined > In file included from /home/sanjey/include/python2.4/Python.h:8, > from numpy/lib/src/_compiled_base.c:1: > /home/sanjey/include/python2.4/pyconfig.h:232:1: warning: this is the > location of the previous definition > gcc -m32 -pthread -shared > build/temp.linux-x86_64-2.4/numpy/lib/src/_compiled_base.o > -Lbuild/temp.linux-x86_64-2.4 -o > build/lib.linux-x86_64-2.4/numpy/lib/_compiled_base.so > building 'numpy.numarray._capi' extension > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > creating build/temp.linux-x86_64-2.4/numpy/numarray > compile options: '-Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: numpy/numarray/_capi.c > numpy/core/include/numpy/npy_3kcompat.h:331: warning: > 'simple_capsule_dtor' defined but not used > gcc -m32 -pthread -shared > build/temp.linux-x86_64-2.4/numpy/numarray/_capi.o > -Lbuild/temp.linux-x86_64-2.4 -o > build/lib.linux-x86_64-2.4/numpy/numarray/_capi.so > building 'numpy.fft.fftpack_lite' extension > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > creating build/temp.linux-x86_64-2.4/numpy/fft > compile options: '-Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: numpy/fft/fftpack_litemodule.c > gcc: numpy/fft/fftpack.c > gcc -m32 -pthread -shared > build/temp.linux-x86_64-2.4/numpy/fft/fftpack_litemodule.o > build/temp.linux-x86_64-2.4/numpy/fft/fftpack.o > -Lbuild/temp.linux-x86_64-2.4 -o > build/lib.linux-x86_64-2.4/numpy/fft/fftpack_lite.so > building 'numpy.linalg.lapack_lite' extension > compiling C sources > C compiler: gcc -m32 -pthread -fno-strict-aliasing -m32 -DNDEBUG -g > -O3 -Wall -Wstrict-prototypes -fPIC > > creating build/temp.linux-x86_64-2.4/numpy/linalg > compile options: '-DNO_ATLAS_INFO=1 -Inumpy/core/include > -Ibuild/src.linux-x86_64-2.4/numpy/core/include/numpy > -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core > -Inumpy/core/src/npymath -Inumpy/core/src/multiarray > -Inumpy/core/src/umath -Inumpy/core/include > -I/home/sanjey/include/python2.4 > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/multiarray > -Ibuild/src.linux-x86_64-2.4/numpy/core/src/umath -c' > gcc: numpy/linalg/lapack_litemodule.c > gcc: numpy/linalg/python_xerbla.c > /usr/bin/g77 -g -Wall -g -Wall -shared > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o > build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o -L/usr/lib > -Lbuild/temp.linux-x86_64-2.4 -llapack -lblas -lg2c -o > build/lib.linux-x86_64-2.4/numpy/linalg/lapack_lite.so > /usr/bin/ld: skipping incompatible /usr/lib/liblapack.so when > searching for -llapack > /usr/bin/ld: skipping incompatible /usr/lib/liblapack.a when searching > for -llapack > /usr/bin/ld: skipping incompatible /usr/lib/libblas.so when searching for > -lblas > /usr/bin/ld: skipping incompatible /usr/lib/libblas.a when searching for > -lblas > /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm > /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm > /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm > /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm > /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 > /usr/bin/ld: warning: i386 architecture of input file > `build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o' is > incompatible with i386:x86-64 output > /usr/bin/ld: warning: i386 architecture of input file > `build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o' is > incompatible with i386:x86-64 output > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xae): > In function `lapack_lite_dgeev': > numpy/linalg/lapack_litemodule.c:155: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfe):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x143):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a3):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1f4):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x272):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31c):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ae):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x60e):numpy/linalg/lapack_litemodule.c:171: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6aa): > In function `lapack_lite_dsyevd': > numpy/linalg/lapack_litemodule.c:241: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6f4):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x739):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x797):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x7ef):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x869):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x8ff):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xa7c):numpy/linalg/lapack_litemodule.c:254: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb34): > In function `lapack_lite_zheevd': > numpy/linalg/lapack_litemodule.c:327: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb7e):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xbc3):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc23):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc74):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xce9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xd85):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xe77):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfb9):numpy/linalg/lapack_litemodule.c:341: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1087): > In function `lapack_lite_dgelsd': > numpy/linalg/lapack_litemodule.c:365: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x10d7):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x111c):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x117d):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x11cf):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1252):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x12e8):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x13d7):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1534):numpy/linalg/lapack_litemodule.c:380: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15af): > In function `lapack_lite_dgesv': > numpy/linalg/lapack_litemodule.c:398: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15f9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x163e):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1692):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x16e7):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x175e):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x189a):numpy/linalg/lapack_litemodule.c:407: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1967): > In function `lapack_lite_dgesdd': > numpy/linalg/lapack_litemodule.c:430: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19b7):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19fc):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a5d):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1aaf):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1b32):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1bc8):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d15):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d76):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1efb):numpy/linalg/lapack_litemodule.c:472: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x202b): > In function `lapack_lite_dgetrf': > numpy/linalg/lapack_litemodule.c:488: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2063):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20ae):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20fe):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2155):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2235):numpy/linalg/lapack_litemodule.c:496: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22b4): > In function `lapack_lite_dpotrf': > numpy/linalg/lapack_litemodule.c:510: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22e9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x232d):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x238f):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x240a):numpy/linalg/lapack_litemodule.c:516: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24af): > In function `lapack_lite_dgeqrf': > numpy/linalg/lapack_litemodule.c:529: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24f9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x253e):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2598):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x25ef):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2669):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x27a7):numpy/linalg/lapack_litemodule.c:540: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2839): > In function `lapack_lite_dorgqr': > numpy/linalg/lapack_litemodule.c:555: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2883):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x28c8):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2927):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x297f):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x29f9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2afa):numpy/linalg/lapack_litemodule.c:562: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2bbb): > In function `lapack_lite_zgeev': > numpy/linalg/lapack_litemodule.c:585: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c0b):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c50):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2cb0):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d04):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d82):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2e2c):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2f6b):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2fb9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x311b):numpy/linalg/lapack_litemodule.c:601: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31f4): > In function `lapack_lite_zgelsd': > numpy/linalg/lapack_litemodule.c:626: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3244):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3289):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x32ef):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3340):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x33c8):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3471):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35b1):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35ff):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x376f):numpy/linalg/lapack_litemodule.c:641: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x37ef): > In function `lapack_lite_zgesv': > numpy/linalg/lapack_litemodule.c:658: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3839):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x387e):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x38d2):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3927):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x399e):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3ada):numpy/linalg/lapack_litemodule.c:667: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bae): > In function `lapack_lite_zgesdd': > numpy/linalg/lapack_litemodule.c:691: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bfe):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3c43):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cab):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cff):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3d82):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3e2c):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3f70):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3fbe):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4195):numpy/linalg/lapack_litemodule.c:708: > undefined reference to `Py_BuildValue' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x41ab):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x422b): > In function `lapack_lite_zgetrf': > numpy/linalg/lapack_litemodule.c:724: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4263):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42ae):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42fe):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4355):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4435):numpy/linalg/lapack_litemodule.c:732: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44b4): > In function `lapack_lite_zpotrf': > numpy/linalg/lapack_litemodule.c:746: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44e9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x452d):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x458f):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460a):numpy/linalg/lapack_litemodule.c:751: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46af): > In function `lapack_lite_zgeqrf': > numpy/linalg/lapack_litemodule.c:764: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46f9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x473e):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4798):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x47ef):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4869):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x49a7):numpy/linalg/lapack_litemodule.c:774: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a39): > In function `lapack_lite_zungqr': > numpy/linalg/lapack_litemodule.c:787: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a83):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ac8):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b27):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b7f):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4bf9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4cfa):numpy/linalg/lapack_litemodule.c:797: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d58): > In function `initlapack_lite': > numpy/linalg/lapack_litemodule.c:858: undefined reference to > `Py_InitModule4' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d71): > In function `initlapack_lite': > > build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1190: > undefined reference to `PyImport_ImportModule' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d8d):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1197: > undefined reference to `PyObject_GetAttrString' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4da6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1212: > undefined reference to `PyCObject_Type' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4db5):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: > undefined reference to `PyExc_RuntimeError' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dc9):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: > undefined reference to `PyErr_SetString' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dd7): > In function `initlapack_lite': > numpy/linalg/lapack_litemodule.c:865: undefined reference to `PyErr_Print' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ddd):numpy/linalg/lapack_litemodule.c:865: > undefined reference to `PyExc_ImportError' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4df1):numpy/linalg/lapack_litemodule.c:865: > undefined reference to `PyErr_SetString' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e18): > In function `initlapack_lite': > > build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1194: > undefined reference to `PyExc_ImportError' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e26):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: > undefined reference to `PyErr_SetString' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e46):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1217: > undefined reference to `PyCObject_AsVoidPtr' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e88):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: > undefined reference to `PyExc_RuntimeError' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e96):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ea1):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: > undefined reference to `PyExc_RuntimeError' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4eb6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1200: > undefined reference to `PyExc_AttributeError' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f24):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: > undefined reference to `PyExc_RuntimeError' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f2e):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f46): > In function `initlapack_lite': > numpy/linalg/lapack_litemodule.c:866: undefined reference to > `PyModule_GetDict' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f66):numpy/linalg/lapack_litemodule.c:867: > undefined reference to `PyErr_NewException' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f82):numpy/linalg/lapack_litemodule.c:868: > undefined reference to `PyDict_SetItemString' > build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x70): > In function `xerbla_': > numpy/linalg/python_xerbla.c:35: undefined reference to `PyExc_ValueError' > > build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x7e):numpy/linalg/python_xerbla.c:35: > undefined reference to `PyErr_SetString' > collect2: ld returned 1 exit status > /usr/bin/ld: skipping incompatible /usr/lib/liblapack.so when > searching for -llapack > /usr/bin/ld: skipping incompatible /usr/lib/liblapack.a when searching > for -llapack > /usr/bin/ld: skipping incompatible /usr/lib/libblas.so when searching for > -lblas > /usr/bin/ld: skipping incompatible /usr/lib/libblas.a when searching for > -lblas > /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm > /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm > /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm > /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm > /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 > /usr/bin/ld: warning: i386 architecture of input file > `build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o' is > incompatible with i386:x86-64 output > /usr/bin/ld: warning: i386 architecture of input file > `build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o' is > incompatible with i386:x86-64 output > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xae): > In function `lapack_lite_dgeev': > numpy/linalg/lapack_litemodule.c:155: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfe):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x143):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a3):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1f4):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x272):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31c):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ae):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x60e):numpy/linalg/lapack_litemodule.c:171: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6aa): > In function `lapack_lite_dsyevd': > numpy/linalg/lapack_litemodule.c:241: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x6f4):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x739):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x797):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x7ef):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x869):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x8ff):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xa7c):numpy/linalg/lapack_litemodule.c:254: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb34): > In function `lapack_lite_zheevd': > numpy/linalg/lapack_litemodule.c:327: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xb7e):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xbc3):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc23):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xc74):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xce9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xd85):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xe77):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0xfb9):numpy/linalg/lapack_litemodule.c:341: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1087): > In function `lapack_lite_dgelsd': > numpy/linalg/lapack_litemodule.c:365: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x10d7):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x111c):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x117d):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x11cf):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1252):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x12e8):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x13d7):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1534):numpy/linalg/lapack_litemodule.c:380: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15af): > In function `lapack_lite_dgesv': > numpy/linalg/lapack_litemodule.c:398: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x15f9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x163e):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1692):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x16e7):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x175e):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x189a):numpy/linalg/lapack_litemodule.c:407: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1967): > In function `lapack_lite_dgesdd': > numpy/linalg/lapack_litemodule.c:430: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19b7):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x19fc):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1a5d):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1aaf):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1b32):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1bc8):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d15):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1d76):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x1efb):numpy/linalg/lapack_litemodule.c:472: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x202b): > In function `lapack_lite_dgetrf': > numpy/linalg/lapack_litemodule.c:488: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2063):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20ae):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x20fe):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2155):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2235):numpy/linalg/lapack_litemodule.c:496: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22b4): > In function `lapack_lite_dpotrf': > numpy/linalg/lapack_litemodule.c:510: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x22e9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x232d):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x238f):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x240a):numpy/linalg/lapack_litemodule.c:516: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24af): > In function `lapack_lite_dgeqrf': > numpy/linalg/lapack_litemodule.c:529: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x24f9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x253e):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2598):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x25ef):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2669):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x27a7):numpy/linalg/lapack_litemodule.c:540: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2839): > In function `lapack_lite_dorgqr': > numpy/linalg/lapack_litemodule.c:555: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2883):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x28c8):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2927):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x297f):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x29f9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2afa):numpy/linalg/lapack_litemodule.c:562: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2bbb): > In function `lapack_lite_zgeev': > numpy/linalg/lapack_litemodule.c:585: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c0b):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2c50):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2cb0):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d04):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2d82):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2e2c):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2f6b):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x2fb9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x311b):numpy/linalg/lapack_litemodule.c:601: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x31f4): > In function `lapack_lite_zgelsd': > numpy/linalg/lapack_litemodule.c:626: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3244):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3289):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x32ef):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3340):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x33c8):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3471):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35b1):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x35ff):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x376f):numpy/linalg/lapack_litemodule.c:641: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x37ef): > In function `lapack_lite_zgesv': > numpy/linalg/lapack_litemodule.c:658: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3839):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x387e):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x38d2):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3927):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x399e):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3ada):numpy/linalg/lapack_litemodule.c:667: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bae): > In function `lapack_lite_zgesdd': > numpy/linalg/lapack_litemodule.c:691: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3bfe):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3c43):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cab):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3cff):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3d82):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3e2c):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3f70):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x3fbe):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4195):numpy/linalg/lapack_litemodule.c:708: > undefined reference to `Py_BuildValue' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x41ab):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x422b): > In function `lapack_lite_zgetrf': > numpy/linalg/lapack_litemodule.c:724: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4263):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42ae):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x42fe):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4355):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4435):numpy/linalg/lapack_litemodule.c:732: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44b4): > In function `lapack_lite_zpotrf': > numpy/linalg/lapack_litemodule.c:746: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x44e9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x452d):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x458f):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x460a):numpy/linalg/lapack_litemodule.c:751: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46af): > In function `lapack_lite_zgeqrf': > numpy/linalg/lapack_litemodule.c:764: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x46f9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x473e):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4798):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x47ef):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4869):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x49a7):numpy/linalg/lapack_litemodule.c:774: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a39): > In function `lapack_lite_zungqr': > numpy/linalg/lapack_litemodule.c:787: undefined reference to > `PyArg_ParseTuple' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4a83):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ac8):numpy/linalg/lapack_litemodule.c:114: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b27):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4b7f):numpy/linalg/lapack_litemodule.c:120: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4bf9):numpy/linalg/lapack_litemodule.c:103: > undefined reference to `PyType_IsSubtype' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4cfa):numpy/linalg/lapack_litemodule.c:797: > undefined reference to `Py_BuildValue' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d58): > In function `initlapack_lite': > numpy/linalg/lapack_litemodule.c:858: undefined reference to > `Py_InitModule4' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d71): > In function `initlapack_lite': > > build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1190: > undefined reference to `PyImport_ImportModule' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4d8d):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1197: > undefined reference to `PyObject_GetAttrString' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4da6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1212: > undefined reference to `PyCObject_Type' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4db5):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: > undefined reference to `PyExc_RuntimeError' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dc9):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1213: > undefined reference to `PyErr_SetString' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4dd7): > In function `initlapack_lite': > numpy/linalg/lapack_litemodule.c:865: undefined reference to `PyErr_Print' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ddd):numpy/linalg/lapack_litemodule.c:865: > undefined reference to `PyExc_ImportError' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4df1):numpy/linalg/lapack_litemodule.c:865: > undefined reference to `PyErr_SetString' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e18): > In function `initlapack_lite': > > build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1194: > undefined reference to `PyExc_ImportError' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e26):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: > undefined reference to `PyErr_SetString' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e46):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1217: > undefined reference to `PyCObject_AsVoidPtr' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e88):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: > undefined reference to `PyExc_RuntimeError' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4e96):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1233: > undefined reference to `PyErr_Format' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4ea1):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1221: > undefined reference to `PyExc_RuntimeError' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4eb6):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1200: > undefined reference to `PyExc_AttributeError' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f24):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: > undefined reference to `PyExc_RuntimeError' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f2e):build/src.linux-x86_64-2.4/numpy/core/include/numpy/__multiarray_api.h:1256: > undefined reference to `PyErr_Format' > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f46): > In function `initlapack_lite': > numpy/linalg/lapack_litemodule.c:866: undefined reference to > `PyModule_GetDict' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f66):numpy/linalg/lapack_litemodule.c:867: > undefined reference to `PyErr_NewException' > > build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o(.text+0x4f82):numpy/linalg/lapack_litemodule.c:868: > undefined reference to `PyDict_SetItemString' > build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x70): > In function `xerbla_': > numpy/linalg/python_xerbla.c:35: undefined reference to `PyExc_ValueError' > > build/temp.linux-x86_64-2.4/numpy/linalg/python_xerbla.o(.text+0x7e):numpy/linalg/python_xerbla.c:35: > undefined reference to `PyErr_SetString' > collect2: ld returned 1 exit status > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -- Jonathan Rocher, Enthought, Inc. jrocher at enthought.com 1-512-536-1057 http://www.enthought.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Sat Oct 16 19:42:26 2010 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sun, 17 Oct 2010 01:42:26 +0200 Subject: [Numpy-discussion] Another merge at github In-Reply-To: References: Message-ID: On Sun, Oct 17, 2010 at 12:23 AM, Charles R Harris wrote: > > IIRC, they recommended pushing from local branches to master on github and > not merging master to the development branches. That doesn't sound right to > me, but perhaps I misunderstood... The idea is not to keep merging the master branch into your development branch to keep up to date (this makes for really ugly history). For single commits, merge back into master (hopefully this should be a fast-forward merge), which then creates an svn-like timeline. For bunches of commits, merge back into master with the --no-ff switch to ensure that a merge message is generated (this makes it much easier to find those grouped commits later). After the merge, push back upstream. Regards St?fan From stefan at sun.ac.za Sat Oct 16 19:04:53 2010 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sun, 17 Oct 2010 01:04:53 +0200 Subject: [Numpy-discussion] Another merge at github In-Reply-To: References: Message-ID: On Sat, Oct 16, 2010 at 11:54 PM, Benjamin Root wrote: > I think the iPython development mailing list recently had a long discussion > about proper git usage.? Maybe there is something we can learn from their > experience? Here's the link again: http://mail.scipy.org/pipermail/ipython-dev/2010-October/006746.html Git makes it easy to see which changes are going to be pushed; it's a good idea to do git log -p or git log --stat to see what's being sent upstream. Cheers St?fan From fperez.net at gmail.com Sat Oct 16 21:23:23 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 16 Oct 2010 18:23:23 -0700 Subject: [Numpy-discussion] Another merge at github In-Reply-To: References: Message-ID: 2010/10/16 St?fan van der Walt : > The idea is not to keep merging the master branch into your > development branch to keep up to date (this makes for really ugly > history). > > For single commits, merge back into master (hopefully this should be a > fast-forward merge), which then creates an svn-like timeline. > > For bunches of commits, merge back into master with the --no-ff switch > to ensure that a merge message is generated (this makes it much easier > to find those grouped commits later). > > After the merge, push back upstream. > Thanks for the summary, Stefan. Charles, as soon as I catch a breather (I'm at a conference right now) I'll try to write up a summary of that long discussion in an easy to digest and follow manner, that can be useful to ipython as well as numpy. But Stefan's summary is spot on for the key points. Regards, f From ralf.gommers at googlemail.com Sat Oct 16 22:10:01 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Sun, 17 Oct 2010 10:10:01 +0800 Subject: [Numpy-discussion] Please help a newbie install NUMPY In-Reply-To: References: Message-ID: On Fri, Oct 15, 2010 at 11:02 PM, Jonathan Rocher wrote: > Hi, > > You might want to try using easy_install >> sudo easy_install numpy > > For some doc about it, see > http://peak.telecommunity.com/DevCenter/EasyInstall > easy_install really does not help to do a numpy install from source, and may give additional issues. Ralf From friedrichromstedt at gmail.com Sun Oct 17 16:52:51 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Sun, 17 Oct 2010 22:52:51 +0200 Subject: [Numpy-discussion] Proposal: Numpy Build Docs Message-ID: Hello, I finally found some time today and since the installers are not feasible in one and a half hour I decided to set up a proper doc of what we're doing so far with the Mac OS X 10.5 installer issue. A few advantages: * We all (meaning Vincent, Ralf, and me) will be more careful with what we run, and have a good starting point for documenting it * Anybody can check if their issue is maybe related to the system the installer was built on * We have a good reference for our own. It's a Sphinx doc and located at http://github.com/friedrichromstedt/numpy-build-doc Currently it's for our 10.5 build, but it's designed to be extensible. It's litte overhead to add the .. index:: directives to the files, at least compared to the documentation I did before in a singelton reST file, and it's lot more readable in my opinion. There is definitely room for improvement, I just pushed the current version, to let you have a look if you want to. It's a preliminary draft, but I tried to make sensible design choices. Have a look, I would be happy, Friedrich P.S.: After my Monday issue I'll have the whole week for numpy, full day, so we should be able to finish it. From ralf.gommers at googlemail.com Sun Oct 17 05:11:59 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Sun, 17 Oct 2010 17:11:59 +0800 Subject: [Numpy-discussion] Another merge at github In-Reply-To: References: Message-ID: On Sun, Oct 17, 2010 at 1:48 PM, Ralf Gommers wrote: > 2010/10/17 St?fan van der Walt : >> On Sun, Oct 17, 2010 at 12:23 AM, Charles R Harris >> wrote: >>> >>> IIRC, they recommended pushing from local branches to master on github and >>> not merging master to the development branches. That doesn't sound right to >>> me, but perhaps I misunderstood... >> >> The idea is not to keep merging the master branch into your >> development branch to keep up to date (this makes for really ugly >> history). >> > > Another merge commit: http://github.com/numpy/numpy/commit/427d3fcabe5 > >> For single commits, merge back into master (hopefully this should be a >> fast-forward merge), which then creates an svn-like timeline. > > Actually I think that the "push local branch to github master" > approach that Charles referred to above is better. Because that will > fail if the merge is not fast-forward, so you never get merge commits > if you don't want them. The "merge into local master" way will give > you a merge (which is why you said "hopefully" above) if you forgot to > rebase your feature branch first. > For pull requests of 1 or 2 commits on github, this should work: $ git co -b local-branch http:github.com/username/branch-to-pull $ git rebase master # (or maintenance/1.5.x) $ git push origin local-branch:master This will either give a ff merge or fail. Right now it's turning into a bit of a mess, with completely unrelated commits forming small branches: http://github.com/numpy/numpy/network Cheers, Ralf > > >> >> For bunches of commits, merge back into master with the --no-ff switch >> to ensure that a merge message is generated (this makes it much easier >> to find those grouped commits later). >> >> After the merge, push back upstream. >> >> Regards >> St?fan >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> > From ralf.gommers at googlemail.com Sun Oct 17 07:35:59 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Sun, 17 Oct 2010 19:35:59 +0800 Subject: [Numpy-discussion] ANN: NumPy 1.5.1 release candidate 1 Message-ID: Hi, I am pleased to announce the availability of the first release candidate of NumPy 1.5.1. This is a bug-fix release with no new features compared to 1.5.0. Binaries, sources and release notes can be found at https://sourceforge.net/projects/numpy/files/. A note on the available binaries for OS X: these are known to not work on Intel-based OS X 10.5. We hope to have that problem fixed within a week. On Windows there are still two known test failures: - #1610, in fromfile (under Python 2.x) - #1633, a failing test for ldexp (under Python 2.5 only) Please report any other issues on the Numpy-discussion mailing list. Enjoy, Ralf From Koert.Kuipers at diamondnotch.com Sun Oct 17 21:42:39 2010 From: Koert.Kuipers at diamondnotch.com (Koert Kuipers) Date: Sun, 17 Oct 2010 21:42:39 -0400 Subject: [Numpy-discussion] how to find out element size of flexible dtype Message-ID: <6143522CDE27514BB78C92BCD7190003032DA812D4@DNLEXCH01> Hello all, If my function receives an array with a flexible dtype such as string or unicode, how do I find out what the size (max number of elements, not number of bytes) of the datatype is? For example: >>> x = np.array(['a', 'b', 'cd'], (np.unicode_, 4)) >>> x.dtype dtype(' From thomas.p.krauss at gmail.com Sun Oct 17 19:34:34 2010 From: thomas.p.krauss at gmail.com (Tom Krauss) Date: Sun, 17 Oct 2010 23:34:34 +0000 (UTC) Subject: [Numpy-discussion] ANN: upfirdn 0.2.1 Message-ID: ANNOUNCEMENT I am pleased to announce a new release of "upfirdn" - version 0.2.1. This package provides an efficient polyphase FIR resampler object (SWIG-ed C++) and some python wrappers. This release includes C++-only templatized functions and examples contributed originally by Lewis Anderson at USCD. Besides the main project web-site at opensource.motorola.com, the source code is browse-able online through a Google Code site with mercurial repository. https://opensource.motorola.com/sf/projects/upfirdn http://code.google.com/p/upfirdn/ Thanks to Google for providing this hosting service! From ralf.gommers at googlemail.com Sun Oct 17 01:48:47 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Sun, 17 Oct 2010 13:48:47 +0800 Subject: [Numpy-discussion] Another merge at github In-Reply-To: References: Message-ID: 2010/10/17 St?fan van der Walt : > On Sun, Oct 17, 2010 at 12:23 AM, Charles R Harris > wrote: >> >> IIRC, they recommended pushing from local branches to master on github and >> not merging master to the development branches. That doesn't sound right to >> me, but perhaps I misunderstood... > > The idea is not to keep merging the master branch into your > development branch to keep up to date (this makes for really ugly > history). > Another merge commit: http://github.com/numpy/numpy/commit/427d3fcabe5 > For single commits, merge back into master (hopefully this should be a > fast-forward merge), which then creates an svn-like timeline. Actually I think that the "push local branch to github master" approach that Charles referred to above is better. Because that will fail if the merge is not fast-forward, so you never get merge commits if you don't want them. The "merge into local master" way will give you a merge (which is why you said "hopefully" above) if you forgot to rebase your feature branch first. Cheers, Ralf > > For bunches of commits, merge back into master with the --no-ff switch > to ensure that a merge message is generated (this makes it much easier > to find those grouped commits later). > > After the merge, push back upstream. > > Regards > St?fan > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > From charlesr.harris at gmail.com Sun Oct 17 01:23:46 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Sat, 16 Oct 2010 23:23:46 -0600 Subject: [Numpy-discussion] Another merge at github In-Reply-To: References: Message-ID: On Sat, Oct 16, 2010 at 4:23 PM, Charles R Harris wrote: > > > On Sat, Oct 16, 2010 at 3:54 PM, Benjamin Root wrote: > >> On Sat, Oct 16, 2010 at 2:20 PM, Charles R Harris < >> charlesr.harris at gmail.com> wrote: >> >>> >>> >>> On Sat, Oct 16, 2010 at 12:56 PM, Joshua Holbrook < >>> josh.holbrook at gmail.com> wrote: >>> >>>> On Sat, Oct 16, 2010 at 10:53 AM, Charles R Harris >>>> wrote: >>>> > Here. This looks harmless but it makes the history really ugly. We >>>> need to >>>> > get the word out *not* to do things this way. >>>> > >>>> > Chuck >>>> > >>>> > _______________________________________________ >>>> > NumPy-Discussion mailing list >>>> > NumPy-Discussion at scipy.org >>>> > http://mail.scipy.org/mailman/listinfo/numpy-discussion >>>> > >>>> > >>>> >>>> So: Rebase, not merge? >>>> >>>> >>> I'm thinking along those lines, but I'm just a dilettante git user. I >>> tend to merge master to my development branches, merge them back to master, >>> and then push master to github. That probably isn't the recommended way. >>> Rebase would probably have the same effect. >>> >>> Chuck >>> >>> >>> >> I think the iPython development mailing list recently had a long >> discussion about proper git usage. Maybe there is something we can learn >> from their experience? >> >> > IIRC, they recommended pushing from local branches to master on github and > not merging master to the development branches. That doesn't sound right to > me, but perhaps I misunderstood... > > And I just managed the same result on a push to maintenance/1.5.x :-/ But I know how it happened, I cherry picked from master for a backport before updating the 1.5.x branch from github. In Retrospect I probably should have reset the head, pulled from 1.5.x, and then reapplied the backport. Live and learn. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Mon Oct 18 05:19:10 2010 From: pav at iki.fi (Pauli Virtanen) Date: Mon, 18 Oct 2010 09:19:10 +0000 (UTC) Subject: [Numpy-discussion] Another merge at github References: Message-ID: Sat, 16 Oct 2010 23:23:46 -0600, Charles R Harris wrote: [clip] > And I just managed the same result on a push to maintenance/1.5.x :-/ > But I know how it happened, I cherry picked from master for a backport > before updating the 1.5.x branch from github. In Retrospect I probably > should have reset the head, pulled from 1.5.x, and then reapplied the > backport. I think the main problem is in using $ git pull The solution is: DO NOT USE "git pull" Instead, use "git fetch" and after that either "git merge" or "git rebase". Then it is explicit what you are doing, and it is more difficult to get wrong. OTOH, $ git pull --ff-only is "safe" in this sense. So you could in principle drop #!/bin/bash CMD="$1" shift case "$CMD" in pull) exec /usr/bin/git pull --ff-only "$@" ;; *) exec /usr/bin/git "$CMD" "$@" ;; esac on your $PATH. > Live and learn. I do it like this: 1) Work in a separate topic branch. 2) Do not merge from master while working. Rebasing is OK, but often not needed. 3) When done, a) If it's just a single commit or a bunch of unrelated commits, rebase on upstream/master. $ git fetch upstream $ git branch tmp HEAD # make a backup in case you mess up $ git rebase upstream/master # do the rebase In case of conflicts: $ git add numpy/.../somefile # mark conflict resolved $ git rebase --continue If you mess up, you can do $ git rebase --abort and if you notice the mess-up after rebase has completed, you can do $ git reset --hard tmp # set branch to same point as `tmp` b) If it's a work consisting of multiple commits that build on each other, you can merge. $ git fetch upstream $ git merge --no-ff upstream/master 4) Then, check what is going to be pushed: $ git log --graph somebranch $ git log -p somebranch Finally, push directly from the branch: $ git push upstream somebranch:master From pearu.peterson at gmail.com Mon Oct 18 05:20:00 2010 From: pearu.peterson at gmail.com (Pearu Peterson) Date: Mon, 18 Oct 2010 12:20:00 +0300 Subject: [Numpy-discussion] Another merge at github In-Reply-To: References: Message-ID: <4CBC1140.1040704@cens.ioc.ee> On 10/16/2010 09:53 PM, Charles R Harris wrote: > Here > . > This looks harmless but it makes the history really ugly. We need to get > the word out *not* to do things this way. Sorry, that was me and my git ignorance. I was trying to commit a small patch but got push rejection. I presumed that my tree was not updated. So I did `git pull` and then `git push` again which resulted the unindented merge above. I see that there are long discussions in numpy ml about the git usage and mis usage. I wonder whether this has converged to something that could be used as reference for git beginners like me. Thanks and sorry about messing up the history, Pearu From pearu.peterson at gmail.com Mon Oct 18 02:42:28 2010 From: pearu.peterson at gmail.com (Pearu Peterson) Date: Mon, 18 Oct 2010 09:42:28 +0300 Subject: [Numpy-discussion] Another merge at github In-Reply-To: References: Message-ID: <4CBBEC54.407@cens.ioc.ee> On 10/16/2010 09:53 PM, Charles R Harris wrote: > Here > . > This looks harmless but it makes the history really ugly. We need to get > the word out *not* to do things this way. Sorry, that was me and my git ignorance. I was trying to commit a small patch but got push rejection. I presumed that my tree was not updated. So I did `git pull` and then `git push` again which resulted the unindented merge above. I see that there are long discussions in numpy ml about the git usage and mis usage. I wonder whether this has converged to something that could be used as reference for git beginners like me. Thanks and sorry about messing up the history, Pearu From hoytak at stat.washington.edu Mon Oct 18 01:35:15 2010 From: hoytak at stat.washington.edu (Hoyt Koepke) Date: Sun, 17 Oct 2010 22:35:15 -0700 Subject: [Numpy-discussion] Another merge at github In-Reply-To: References: Message-ID: FYI for general readers, I found the following discussion on this topic really helpful: http://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions --Hoyt ++++++++++++++++++++++++++++++++++++++++++++++++ + Hoyt Koepke + University of Washington Department of Statistics + http://www.stat.washington.edu/~hoytak/ + hoytak at gmail.com ++++++++++++++++++++++++++++++++++++++++++ From faltet at pytables.org Mon Oct 18 03:37:53 2010 From: faltet at pytables.org (Francesc Alted) Date: Mon, 18 Oct 2010 09:37:53 +0200 Subject: [Numpy-discussion] how to find out element size of flexible dtype In-Reply-To: <6143522CDE27514BB78C92BCD7190003032DA812D4@DNLEXCH01> References: <6143522CDE27514BB78C92BCD7190003032DA812D4@DNLEXCH01> Message-ID: <201010180937.53489.faltet@pytables.org> A Monday 18 October 2010 03:42:39 Koert Kuipers escrigu?: > Hello all, > If my function receives an array with a flexible dtype such as string > or unicode, how do I find out what the size (max number of elements, > not number of bytes) of the datatype is? > > For example: > >>> x = np.array(['a', 'b', 'cd'], (np.unicode_, 4)) > >>> x.dtype > > dtype(' > The string representation of x.dtype shows that is has element size > 4, so I could get the element size by parsing that, but is there a > more elegant way to get this? Thanks, Not very elegant, but it works: >>> x.itemsize / np.dtype((x.dtype.type, 1)).itemsize 4 Cheers, -- Francesc Alted From sigma.z.1980 at gmail.com Mon Oct 18 06:55:59 2010 From: sigma.z.1980 at gmail.com (Alex Ter-Sarkissov) Date: Mon, 18 Oct 2010 23:55:59 +1300 Subject: [Numpy-discussion] numpy installation in ubuntu Message-ID: hi everyone, i'm very new to ubuntu, now trying to install numpy and wxpython. Having unpacked numpy and running the standard commnad in idle from numpy import * i get the message ImportError: Error importing numpy: you should not try to import numpy from its source directory; please exit the numpy source tree, and relaunch your python intepreter from there. I quit the folder with numpy, relaunched python, but the module wasn't even identified. thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From numpy-discussion at maubp.freeserve.co.uk Mon Oct 18 07:06:03 2010 From: numpy-discussion at maubp.freeserve.co.uk (Peter) Date: Mon, 18 Oct 2010 12:06:03 +0100 Subject: [Numpy-discussion] numpy installation in ubuntu In-Reply-To: References: Message-ID: On Mon, Oct 18, 2010 at 11:55 AM, Alex Ter-Sarkissov wrote: > hi everyone, i'm very new to ubuntu, now trying to install numpy and > wxpython. Did you consider installing the Ubuntu provided packages, e.g. via apt-get or the Synaptic Package manager? That is *much* easier - but you won't get the very latest versions. > Having unpacked numpy and running the standard commnad in idle Could you clarify what you did? You don't just unpack the archive and use it as it - there is C code that must be compiled etc. Peter From structures-it at embl-heidelberg.de Mon Oct 18 07:22:52 2010 From: structures-it at embl-heidelberg.de (Frank Thommen) Date: Mon, 18 Oct 2010 13:22:52 +0200 Subject: [Numpy-discussion] Need help for the migration from Numeric to numpy In-Reply-To: <4CB895F5.1020407@gmail.com> References: <4CB6AF45.6020903@embl-heidelberg.de> <4CB72C40.4050802@noaa.gov> <4CB733CF.5010202@embl-heidelberg.de> <4CB74415.3050004@noaa.gov> <4CB74E65.8050401@gmail.com> <4CB88FF5.5060702@embl-heidelberg.de> <4CB895F5.1020407@gmail.com> Message-ID: <4CBC2E0C.1000904@embl-heidelberg.de> Bruce Southey wrote: > [...] >>> It took me a while to track it down, but there used to be a module/file >>> called 'convertcode.py' for conversion. It was mentioned as tip in >>> Travis's 'Guide to Numpy' page 31 in Jan 6 2005 version. But the >>> alter_code path is in Dec 7 2006 (linked at http://docs.scipy.org/doc/). >>> It is advisable to read it as it address differences between Numeric and >>> old numpy ie section 2.6! >> Thanks for the hint. I'm currently reading through this document. I'm >> sure this will help a lot. >> >> convertcode.py doesn't seem to provided with current numpy releases. >> >> >>> Travis said in the thread: >>> http://mail.scipy.org/pipermail/numpy-discussion/2006-August/010085.html >>> "The transition approach is to use the compatibility layer first by >>> running oldnumeric.alter_code1.py and then running alter_code2.py which >>> will take you from the compatibility layer to NumPy (but alter_code2 is >>> not completed yet)." >> My experience is, that these scripts don't work at all (any more). >> >> >> frank >> > Hi, > Yeah I never had much success with using such codes. > > Anyhow, I have attached the last version of convertcode.py I have (came > with numpy 0.9.6). If you want that numpy version as does not seem to be > on sourceforge please let me know (the gzipped tar file is about 930K). > > Bruce > Hi, thanks a lot for digging this out, but `python convertcode.py ./test.py` only adds a line '## Automatically adapted for numpy Oct 18, 2010 by convertcode.py' on top of the file. That's all. All other Numeric code in the script (including impoerts) are unchanged. I think it's the most timesaving and nerve-conserving way to let the user change his scripts manually (with the help of Travis's 'Guide to Numpy') and providing Numeric in the meantime ;-) Thanks to all respondents for the hints and links frank From goodfellow.ian at gmail.com Mon Oct 18 09:07:42 2010 From: goodfellow.ian at gmail.com (Ian Goodfellow) Date: Mon, 18 Oct 2010 09:07:42 -0400 Subject: [Numpy-discussion] numpy installation in ubuntu In-Reply-To: References: Message-ID: To do a standard installation, run sudo python setup.py install from inside the numpy directory Then your import should work elsewhere. By the way, "import *" can cause difficulties when you're working with several different files. For example, if you have a function called 'save' somewhere that imports something that does 'from numpy import *' you'll have problems because there is a numpy.save. It's better to import numpy with a shorter name, ie, "import numpy as N" or "import numpy as npy" than to drop the namespace altogether. On Mon, Oct 18, 2010 at 6:55 AM, Alex Ter-Sarkissov wrote: > hi everyone, i'm very new to ubuntu, now trying to install numpy and > wxpython. > > Having unpacked numpy and running the standard commnad in idle > > from numpy import * > > i get the message > > ImportError: Error importing numpy: you should not try to import numpy from > its source directory; please exit the numpy source tree, and > relaunch > your python intepreter from there. > > I quit the folder with numpy, relaunched python, but the module wasn't even > identified. > > thanks > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Mon Oct 18 09:45:35 2010 From: pav at iki.fi (Pauli Virtanen) Date: Mon, 18 Oct 2010 13:45:35 +0000 (UTC) Subject: [Numpy-discussion] numpy installation in ubuntu References: Message-ID: Mon, 18 Oct 2010 09:07:42 -0400, Ian Goodfellow wrote: > To do a standard installation, run > sudo python setup.py install > from inside the numpy directory Preferably, sudo python setup.py install --prefix=/usr/local and then you don't mess up your package manager. Pauli From vincent at vincentdavis.net Mon Oct 18 09:55:16 2010 From: vincent at vincentdavis.net (Vincent Davis) Date: Mon, 18 Oct 2010 07:55:16 -0600 Subject: [Numpy-discussion] ANN: NumPy 1.5.1 release candidate 1 In-Reply-To: References: Message-ID: On Sun, Oct 17, 2010 at 5:35 AM, Ralf Gommers wrote: > Hi, > > I am pleased to announce the availability of the first release > candidate of NumPy 1.5.1. This is a bug-fix release with no new > features compared to 1.5.0. > > Binaries, sources and release notes can be found at > https://sourceforge.net/projects/numpy/files/. > A note on the available binaries for OS X: these are known to not work > on Intel-based OS X 10.5. We hope to have that problem fixed within a > week. > > On Windows there are still two known test failures: > - #1610, in fromfile (under Python 2.x) > - #1633, a failing test for ldexp (under Python 2.5 only) > Please report any other issues on the Numpy-discussion mailing list. Test pass for me. osx 10.6 py27 OK (KNOWNFAIL=4, SKIP=2) Vincent > > Enjoy, > Ralf > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -- Thanks Vincent Davis 720-301-3003 From ralf.gommers at googlemail.com Mon Oct 18 10:01:20 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Mon, 18 Oct 2010 22:01:20 +0800 Subject: [Numpy-discussion] ANN: NumPy 1.5.1 release candidate 1 In-Reply-To: References: Message-ID: On Mon, Oct 18, 2010 at 9:55 PM, Vincent Davis wrote: > On Sun, Oct 17, 2010 at 5:35 AM, Ralf Gommers > wrote: >> Hi, >> >> I am pleased to announce the availability of the first release >> candidate of NumPy 1.5.1. This is a bug-fix release with no new >> features compared to 1.5.0. >> >> Binaries, sources and release notes can be found at >> https://sourceforge.net/projects/numpy/files/. >> A note on the available binaries for OS X: these are known to not work >> on Intel-based OS X 10.5. We hope to have that problem fixed within a >> week. >> >> On Windows there are still two known test failures: >> - #1610, in fromfile (under Python 2.x) >> - #1633, a failing test for ldexp (under Python 2.5 only) >> Please report any other issues on the Numpy-discussion mailing list. > > Test pass for me. > osx 10.6 py27 > > OK (KNOWNFAIL=4, SKIP=2) > > Glad it works for you. But I just reopened the OS X gfortran issue, http://projects.scipy.org/numpy/ticket/1399. RC2 in one week. Two other issues to be fixed by then: http://projects.scipy.org/numpy/ticket/1610 (Pauli has suggested a fix already) http://projects.scipy.org/numpy/ticket/1633 Cheers, Ralf From xscript at gmx.net Mon Oct 18 10:58:18 2010 From: xscript at gmx.net (=?utf-8?Q?Llu=C3=ADs?=) Date: Mon, 18 Oct 2010 16:58:18 +0200 Subject: [Numpy-discussion] DataArray fixes In-Reply-To: (Fernando Perez's message of "Wed, 13 Oct 2010 11:25:25 -0700") References: <86wrqywujy.wl%lluis@ginnungagap.pc.ac.upc.edu> <8662yge98e.wl%lluis@ginnungagap.pc.ac.upc.edu> <87zkui5jpf.fsf@ginnungagap.bsc.es> Message-ID: <87wrpfo8dx.fsf@ginnungagap.bsc.es> Fernando Perez writes: > On Wed, Oct 13, 2010 at 6:02 AM, Llu?s wrote: >> I thought that datarray module would be inside numpy, so the >> construction interface would be: >> ? ? ?numpy.datarray.array(...) >> ? ? ? ?User-friendly constructor with "inlined" contents. >> ? ? ?numpy.datarray.DataArray(...) >> ? ? ? ?Low-level contructor with uninitialized contents. > I see your point, but I think overriding the 'array' name is not very > safe in the long run. Imagine reading a fragment of code using > datarrays, you'd have to constantly look at the top for the import > line, to see 'is this the 'array' from datarray or the numpy one? And > if you need to use both (likely a very common scenario) you'd be > aliasing one of them all the time. So let's avoid the naming > collision from the beginning, rather than having everyone work around > it always. Ah well, I don't usually import routines into my namespace, but full packages to avoid collisions and ease understanding of the source :) In fact, I looked into 'numpy.ma' to try to follow the same scheme. It does indeed have a 'numpy.ma.array', while 'numpy.ma.masked_array' seems just to be an alias for 'numpy.ma.MaskedArray'. In any case, I think you had one naming suggestion... could you type it again? Was it 'numpy.datarray.data_array'? Or perhaps something shorter? In any case, I do see your concerns. I'll fix all pending requests... when I have time. It's crazy right now, so I won't be having much time for at least two weeks. Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth From cimrman3 at ntc.zcu.cz Mon Oct 18 13:54:22 2010 From: cimrman3 at ntc.zcu.cz (Robert Cimrman) Date: Mon, 18 Oct 2010 19:54:22 +0200 (CEST) Subject: [Numpy-discussion] stride tricks for cellular automata Message-ID: FYI: I have added a new Cookbook entry, see [1], hoping that it might be useful to someone. The stride tricks are awesome! r. [1] http://scipy.org/Cookbook/GameOfLifeStrides From mtrumpis at berkeley.edu Mon Oct 18 14:21:30 2010 From: mtrumpis at berkeley.edu (M Trumpis) Date: Mon, 18 Oct 2010 14:21:30 -0400 Subject: [Numpy-discussion] datarray lightning talk at NYC Python group Message-ID: Just a heads up that I'm going to do a quick pitch for datarray this Wed. at the NYC Python Meetup thing. If any collaborator is attending, please introduce yourself! Mike From fperez.net at gmail.com Mon Oct 18 17:02:34 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 18 Oct 2010 14:02:34 -0700 Subject: [Numpy-discussion] DataArray fixes In-Reply-To: <87wrpfo8dx.fsf@ginnungagap.bsc.es> References: <86wrqywujy.wl%lluis@ginnungagap.pc.ac.upc.edu> <8662yge98e.wl%lluis@ginnungagap.pc.ac.upc.edu> <87zkui5jpf.fsf@ginnungagap.bsc.es> <87wrpfo8dx.fsf@ginnungagap.bsc.es> Message-ID: On Mon, Oct 18, 2010 at 7:58 AM, Llu?s wrote: > Ah well, I don't usually import routines into my namespace, but full > packages to avoid collisions and ease understanding of the source :) Good practice, though it's still (I think) best to avoid colliding with very common names in case someone uses the direct import approach (which is perfectly valid and idiomatic Python). > In fact, I looked into 'numpy.ma' to try to follow the same scheme. It > does indeed have a 'numpy.ma.array', while 'numpy.ma.masked_array' seems > just to be an alias for 'numpy.ma.MaskedArray'. > > In any case, I think you had one naming suggestion... could you type it > again? Was it 'numpy.datarray.data_array'? Or perhaps something shorter? I lean towards hoping that numpy would expose at the top level the various *array() functions for the different array types: np.array() -> plain np.masked_array() np.data_array() np.record_array() That would make it easier for people to discover them, and would also encourage uniformization (when possible) of interfaces, signatures, etc. In teaching, it would also be easier to have a little chart explaining the various specializations the other types make over the basic one, and I think it would be more newbie-friendly to have this layout. > In any case, I do see your concerns. I'll fix all pending > requests... when I have time. It's crazy right now, so I won't be having > much time for at least two weeks. Thanks, no worries. It's not like we're drowning in free time here :) Cheers, f From fperez.net at gmail.com Mon Oct 18 17:18:49 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 18 Oct 2010 14:18:49 -0700 Subject: [Numpy-discussion] datarray lightning talk at NYC Python group In-Reply-To: References: Message-ID: On Mon, Oct 18, 2010 at 11:21 AM, M Trumpis wrote: > Just a heads up that I'm going to do a quick pitch for datarray this > Wed. at the NYC Python Meetup thing. > > If any collaborator is attending, please introduce yourself! > Well, Travis will be there speaking, if my Enthought newsletter is correct :) It would be great if you can collect feedback and have a chance to discuss things with Travis in-person (we tried on Friday here but ran out of time). If you can post a summary of any ideas that come out of that, it would be greatly appreciated. Best of luck with the talk! Cheers, f From jsalvati at u.washington.edu Mon Oct 18 17:50:22 2010 From: jsalvati at u.washington.edu (John Salvatier) Date: Mon, 18 Oct 2010 14:50:22 -0700 Subject: [Numpy-discussion] datarray lightning talk at NYC Python group In-Reply-To: References: Message-ID: Maybe put it up on youtube? Or write down your pitch? As someone who dislikes R but thinks data.frames are good for something, I'd be interested in hearing the pitch, what the developers think the strengths and weaknesses of DatArray are. On Mon, Oct 18, 2010 at 2:18 PM, Fernando Perez wrote: > On Mon, Oct 18, 2010 at 11:21 AM, M Trumpis wrote: > > Just a heads up that I'm going to do a quick pitch for datarray this > > Wed. at the NYC Python Meetup thing. > > > > If any collaborator is attending, please introduce yourself! > > > > Well, Travis will be there speaking, if my Enthought newsletter is correct > :) > > It would be great if you can collect feedback and have a chance to > discuss things with Travis in-person (we tried on Friday here but ran > out of time). If you can post a summary of any ideas that come out of > that, it would be greatly appreciated. > > Best of luck with the talk! > > Cheers, > > f > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Mon Oct 18 18:47:13 2010 From: pav at iki.fi (Pauli Virtanen) Date: Mon, 18 Oct 2010 22:47:13 +0000 (UTC) Subject: [Numpy-discussion] Another merge at github References: <4CBC1140.1040704@cens.ioc.ee> Message-ID: Mon, 18 Oct 2010 12:20:00 +0300, Pearu Peterson wrote: [clip] > I see that there are long discussions in numpy ml about the git usage > and mis usage. I wonder whether this has converged to something that > could be used as reference for git beginners like me. I think there's agreement on what we would like to see. I tried to modify Matthew's gitwash docs in that in sight: http://docs.scipy.org/doc/numpy/dev/gitwash/development_workflow.html Suggestions for improvement are welcome. Pauli From david at silveregg.co.jp Mon Oct 18 20:56:47 2010 From: david at silveregg.co.jp (David) Date: Tue, 19 Oct 2010 09:56:47 +0900 Subject: [Numpy-discussion] numpy installation in ubuntu In-Reply-To: References: Message-ID: <4CBCECCF.7080600@silveregg.co.jp> On 10/18/2010 10:45 PM, Pauli Virtanen wrote: > Mon, 18 Oct 2010 09:07:42 -0400, Ian Goodfellow wrote: > >> To do a standard installation, run >> sudo python setup.py install >> from inside the numpy directory > > Preferably, > > sudo python setup.py install --prefix=/usr/local > > and then you don't mess up your package manager. Ubuntu actually does this by default (i.e. the default prefix expands to /usr/local on ubuntu and debian). But I think we should tell people to use the --user for python 2.6 and above by default: that's the safest method, does not require sudo and works on every platform, cheers, David From mwwiebe at gmail.com Mon Oct 18 21:13:13 2010 From: mwwiebe at gmail.com (Mark Wiebe) Date: Mon, 18 Oct 2010 18:13:13 -0700 Subject: [Numpy-discussion] patch for structured array comparison bug Message-ID: I found a bug in structured array comparison when fields have multi-dimensional types. I created a ticket here: http://projects.scipy.org/numpy/ticket/1640 and a patch here: http://github.com/m-paradox/numpy/compare/master...fix_structured_compare Could someone review it for me? Thanks, Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Tue Oct 19 03:09:54 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Tue, 19 Oct 2010 01:09:54 -0600 Subject: [Numpy-discussion] patch for structured array comparison bug In-Reply-To: References: Message-ID: On Mon, Oct 18, 2010 at 7:13 PM, Mark Wiebe wrote: > I found a bug in structured array comparison when fields have > multi-dimensional types. I created a ticket here: > > http://projects.scipy.org/numpy/ticket/1640 > > and a patch here: > > http://github.com/m-paradox/numpy/compare/master...fix_structured_compare > > Could someone review it for me? > > Just a quick look. I wasn't able to add comments to the code, maybe a pull request would allow that or maybe you need to enable something. Also, it is best to work in a branch, see the new notes<%20%20%20%20http://docs.scipy.org/doc/numpy/dev/gitwash/development_workflow.html>on the GIT workflow. I'm not sure how broadcasting is supposed to work for structured arrays so I will leave that to someone else. ISTR that the SUN compiler is persnickety about the initialization of structures, only accepts constants or some such. I'll try to track that down or maybe someone here who is familiar with that compiler can comment. Thanks for the work. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From sigma.z.1980 at gmail.com Tue Oct 19 04:26:38 2010 From: sigma.z.1980 at gmail.com (Alex Ter-Sarkissov) Date: Tue, 19 Oct 2010 21:26:38 +1300 Subject: [Numpy-discussion] numpy installation in ubuntu In-Reply-To: <4CBCECCF.7080600@silveregg.co.jp> References: <4CBCECCF.7080600@silveregg.co.jp> Message-ID: thanks, this didn't seem to work. I get a whole range of errors, most importantly SystemError: Cannot compiler 'Python.h'. Perhaps you need to install python-dev|python-devel. Apparently, according to numpy installation guide (here) i got the wrong compiler installed. How do I find out which 1 I got? 2010/10/19 David > > On 10/18/2010 10:45 PM, Pauli Virtanen wrote: > > Mon, 18 Oct 2010 09:07:42 -0400, Ian Goodfellow wrote: > > > >> To do a standard installation, run > >> sudo python setup.py install > >> from inside the numpy directory > > > > Preferably, > > > > sudo python setup.py install --prefix=/usr/local > > > > and then you don't mess up your package manager. > > Ubuntu actually does this by default (i.e. the default prefix expands to > /usr/local on ubuntu and debian). > > But I think we should tell people to use the --user for python 2.6 and > above by default: that's the safest method, does not require sudo and > works on every platform, > > cheers, > > David > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Tue Oct 19 05:05:53 2010 From: pav at iki.fi (Pauli Virtanen) Date: Tue, 19 Oct 2010 09:05:53 +0000 (UTC) Subject: [Numpy-discussion] numpy installation in ubuntu References: <4CBCECCF.7080600@silveregg.co.jp> Message-ID: Tue, 19 Oct 2010 21:26:38 +1300, Alex Ter-Sarkissov wrote: > thanks, this didn't seem to work. I get a whole range of errors, most > importantly > > SystemError: Cannot compiler 'Python.h'. Perhaps you need to install > python-dev|python-devel. I think you should do "sudo apt-get install python-dev" From pav at iki.fi Tue Oct 19 05:24:52 2010 From: pav at iki.fi (Pauli Virtanen) Date: Tue, 19 Oct 2010 09:24:52 +0000 (UTC) Subject: [Numpy-discussion] patch for structured array comparison bug References: Message-ID: Tue, 19 Oct 2010 01:09:54 -0600, Charles R Harris wrote: [clip] > Just a quick look. I wasn't able to add comments to the code, maybe a > pull request would allow that or maybe you need to enable something. I think you can only add comments on commits, not in Github's compare view. > Also, it is best to work in a branch, see the new > notes<%20%20%20%20http://docs.scipy.org/doc/numpy/dev/gitwash/ development_workflow.html> on > the GIT workflow. That work is in a separate branch, called `fix_structured_compare` :) But perhaps we should just recommend people filing pull requests right away? > I'm not sure how broadcasting is supposed to work for > structured arrays so I will leave that to someone else. ISTR that the > SUN compiler is persnickety about the initialization of structures, > only accepts constants or some such. I'll try to track that down or > maybe someone here who is familiar with that compiler can comment. I suspect that this comparison code should refuse to compare arrays with shape(a) != shape(b), even if `a` and `b` are broadcastable to one another. The issue is that the broadcasting semantics work on the array level, but here the boolean sub-array is implicitly reduced to a single boolean. You can also initialize dimensions = shape(self) + (-1,) and let PyArray_Newshape do the size calculation for you. I guess it's best to not initialize structures directly, if there is some suspicion that obscure compilers don't like it. -- Pauli Virtanen From sigma.z.1980 at gmail.com Tue Oct 19 05:41:40 2010 From: sigma.z.1980 at gmail.com (Alex Ter-Sarkissov) Date: Tue, 19 Oct 2010 22:41:40 +1300 Subject: [Numpy-discussion] numpy installation in ubuntu In-Reply-To: References: <4CBCECCF.7080600@silveregg.co.jp> Message-ID: thanks! it actually worked! maybe u could recommend some good sources/readin on how to install different modules in python run under linux thanks again, alex 2010/10/19 Pauli Virtanen > Tue, 19 Oct 2010 21:26:38 +1300, Alex Ter-Sarkissov wrote: > > thanks, this didn't seem to work. I get a whole range of errors, most > > importantly > > > > SystemError: Cannot compiler 'Python.h'. Perhaps you need to install > > python-dev|python-devel. > > I think you should do "sudo apt-get install python-dev" > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thkoe002 at gmail.com Tue Oct 19 06:05:50 2010 From: thkoe002 at gmail.com (=?ISO-8859-1?Q?Thomas_K=F6nigstein?=) Date: Tue, 19 Oct 2010 12:05:50 +0200 Subject: [Numpy-discussion] [numpy-discussion] Transform 3d data Message-ID: Hello everyone, I have the following problem: I acquire a (evenly spaced) 3d field of 3d vectors from a HDF5 data file: >>> import tables >>> field=tables.openFile("test.h5").root.YeeMagField.read() now, the data is organized in "nested arrays"... so, when I have, say, 300 data points on the x-axis, 200 data points on the y-axis and 100 data points on the z-axis, I get an array with the shape >>> field.shape >>> (300, 200, 100, 3) When I now want to see a 3D arrow-plot of this field, I use: >>> from enthought.mayavi import mlab as m >>> x,y,z=field.transpose() >>> m.quiver3d(x,y,z) and this works just fine. Here, the arrays (x and y and z) *each* contain one field component (i,e. into one spatial direction) at 300x200x100 points in a 3D array. Now, I would like to have this data in another format, so I can for example save it to a textfile with pylab.savetxt. What I would like are six arrays, each 1d, three for the coordinates and three for the field components. Since I didn't know any better, I wrote the following procedure: def transform_3d_data_(field,lowerBounds,upperBounds): #field is the same as above, lowerBounds and upperBounds each contain three values for x,y,z min/max import pylab as p xx,yy,zz,ex,ey,ez=list(),list(),list(),list(),list(),list() #xx,yy,zz will become the spatial coordinates, ex,ey,ez will become the field components for xi in range(field.shape[0]): #for each x coordinate... for yi in range(field.shape[1]): #for each y coordinate... for zi in range(field.shape[2]): #for each z coordinate... xx.append(lowerBounds[0]+xi*(upperBounds[0]-lowerBounds[0])/float(field.shape[0])) #append this yy.append(lowerBounds[1]+yi*(upperBounds[1]-lowerBounds[1])/float(field.shape[1])) #x, y, z coordinate zz.append(lowerBounds[2]+zi*(upperBounds[2]-lowerBounds[2])/float(field.shape[2])) #to xx, yy, zz .... ex.append(field[xi][yi][zi][0]) #and also ey.append(field[xi][yi][zi][1]) #add this field composition ez.append(field[xi][yi][zi][2]) #to ex, ey, ez. xx,yy,zz,ex,ey,ez=[p.array(_) for _ in [xx,yy,zz,ex,ey,ez]] return xx,yy,zz,ex,ey,ez , so I get the desired six 1D-arrays xx,yy,zz for the coordinates and ex,ey,ez for the field components. It works. Now my question: there has to be a better way to get this re-organization, right? This one here is much too slow, obviously. Is there maybe a single command for pylab that does this? Thanks in advance, cheers Thomas PS. I'm new to this messaging board, and I was wondering if there is a "normal" forum as well? I can't even search through the archives at http://mail.scipy.org/pipermail/numpy-discussion/ :( have there ever been discussions/initiatives about porting the mailing list archives for example to a phpBB based forum? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nadavh at visionsense.com Tue Oct 19 08:10:52 2010 From: nadavh at visionsense.com (Nadav Horesh) Date: Tue, 19 Oct 2010 14:10:52 +0200 Subject: [Numpy-discussion] [numpy-discussion] Transform 3d data References: Message-ID: You can aid mgrid, riughy as the follows (I may have mistakes, but the direction should be clear): def transform_3d_data_(field,lwrbnd,uprbnd): shape = field.shape XYZ = np.mgrid[lwrbnd[0]:uprbnd[0]:shape[0], lwrbnd[1]:uprbnd[1]:shape[1], lwrbnd[2]:uprbnd[2]:shape[2]] vectors = fields.reshape(-1,3) np.savetxt(np.hstack((XYZ.reshape(3,-1).T, vectors))) Nadav -----Original Message----- From: numpy-discussion-bounces at scipy.org on behalf of Thomas K?nigstein Sent: Tue 19-Oct-10 12:05 To: numpy-discussion at scipy.org Subject: [Numpy-discussion] [numpy-discussion] Transform 3d data Hello everyone, I have the following problem: I acquire a (evenly spaced) 3d field of 3d vectors from a HDF5 data file: >>> import tables >>> field=tables.openFile("test.h5").root.YeeMagField.read() now, the data is organized in "nested arrays"... so, when I have, say, 300 data points on the x-axis, 200 data points on the y-axis and 100 data points on the z-axis, I get an array with the shape >>> field.shape >>> (300, 200, 100, 3) When I now want to see a 3D arrow-plot of this field, I use: >>> from enthought.mayavi import mlab as m >>> x,y,z=field.transpose() >>> m.quiver3d(x,y,z) and this works just fine. Here, the arrays (x and y and z) *each* contain one field component (i,e. into one spatial direction) at 300x200x100 points in a 3D array. Now, I would like to have this data in another format, so I can for example save it to a textfile with pylab.savetxt. What I would like are six arrays, each 1d, three for the coordinates and three for the field components. Since I didn't know any better, I wrote the following procedure: def transform_3d_data_(field,lowerBounds,upperBounds): #field is the same as above, lowerBounds and upperBounds each contain three values for x,y,z min/max import pylab as p xx,yy,zz,ex,ey,ez=list(),list(),list(),list(),list(),list() #xx,yy,zz will become the spatial coordinates, ex,ey,ez will become the field components for xi in range(field.shape[0]): #for each x coordinate... for yi in range(field.shape[1]): #for each y coordinate... for zi in range(field.shape[2]): #for each z coordinate... xx.append(lowerBounds[0]+xi*(upperBounds[0]-lowerBounds[0])/float(field.shape[0])) #append this yy.append(lowerBounds[1]+yi*(upperBounds[1]-lowerBounds[1])/float(field.shape[1])) #x, y, z coordinate zz.append(lowerBounds[2]+zi*(upperBounds[2]-lowerBounds[2])/float(field.shape[2])) #to xx, yy, zz .... ex.append(field[xi][yi][zi][0]) #and also ey.append(field[xi][yi][zi][1]) #add this field composition ez.append(field[xi][yi][zi][2]) #to ex, ey, ez. xx,yy,zz,ex,ey,ez=[p.array(_) for _ in [xx,yy,zz,ex,ey,ez]] return xx,yy,zz,ex,ey,ez , so I get the desired six 1D-arrays xx,yy,zz for the coordinates and ex,ey,ez for the field components. It works. Now my question: there has to be a better way to get this re-organization, right? This one here is much too slow, obviously. Is there maybe a single command for pylab that does this? Thanks in advance, cheers Thomas PS. I'm new to this messaging board, and I was wondering if there is a "normal" forum as well? I can't even search through the archives at http://mail.scipy.org/pipermail/numpy-discussion/ :( have there ever been discussions/initiatives about porting the mailing list archives for example to a phpBB based forum? -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 4428 bytes Desc: not available URL: From dsdale24 at gmail.com Tue Oct 19 08:12:46 2010 From: dsdale24 at gmail.com (Darren Dale) Date: Tue, 19 Oct 2010 08:12:46 -0400 Subject: [Numpy-discussion] whitespace in git repo Message-ID: We have been discussing whitespace and line endings at the following pull request: http://github.com/numpy/numpy/pull/4 . Chuck suggested we discuss it here on the list. I have the following set in my ~/.gitconfig file: [apply] whitespace = fix [core] autocrlf = input which is attempting to correct some changes in: branding/icons/numpylogo.svg branding/icons/numpylogoicon.svg tools/win32build/nsis_scripts/numpy-superinstaller.nsi.in David C. suggested that the nsi.in file should not be changed. I suggested adding a .gitattributes file along with the existing .gitignore file in the numpy repo. This would enforce windows line endings for the nsi.in file: tools/win32build/nsis_scripts/numpy-superinstaller.nsi.in eol=crlf alternatively this would disable any attempt to convert line endings: tools/win32build/nsis_scripts/numpy-superinstaller.nsi.in -text I think the former is preferable. But it seems like a good idea to include some git config files in the repo to ensure trailing whitespace is stripped and line endings are appropriate to the numpy project, regardless of what people may have in their ~/.gitconfig file. Comments? Darren From nadavh at visionsense.com Tue Oct 19 12:20:24 2010 From: nadavh at visionsense.com (Nadav Horesh) Date: Tue, 19 Oct 2010 18:20:24 +0200 Subject: [Numpy-discussion] [numpy-discussion] Transform 3d data In-Reply-To: References: Message-ID: <1287505224.22099.1.camel@nadav.envision.co.il> Of course there is an (at least one) error: the line should be: XYZ = np.mgrid[lwrbnd[0]:uprbnd[0]:shape[0]*1j,lwrbnd[1]:uprbnd[1]:shape[1]*1j, lwrbnd[2]:uprbnd[2]:shape[2]*1j] On Tue, 2010-10-19 at 14:10 +0200, Nadav Horesh wrote: > You can aid mgrid, riughy as the follows (I may have mistakes, but the > direction should be clear): > > def transform_3d_data_(field,lwrbnd,uprbnd): > shape = field.shape > XYZ = np.mgrid[lwrbnd[0]:uprbnd[0]:shape[0], > lwrbnd[1]:uprbnd[1]:shape[1], lwrbnd[2]:uprbnd[2]:shape[2]] > vectors = fields.reshape(-1,3) > np.savetxt(np.hstack((XYZ.reshape(3,-1).T, vectors))) > > > Nadav > > > > -----Original Message----- > From: numpy-discussion-bounces at scipy.org on behalf of Thomas > K?nigstein > Sent: Tue 19-Oct-10 12:05 > To: numpy-discussion at scipy.org > Subject: [Numpy-discussion] [numpy-discussion] Transform 3d data > > Hello everyone, > > I have the following problem: > > I acquire a (evenly spaced) 3d field of 3d vectors from a HDF5 data > file: > > >>> import tables > >>> field=tables.openFile("test.h5").root.YeeMagField.read() > > now, the data is organized in "nested arrays"... so, when I have, say, > 300 > data points on the x-axis, 200 data points on the y-axis and 100 data > points > on the z-axis, I get an array with the shape > > >>> field.shape > >>> (300, 200, 100, 3) > > When I now want to see a 3D arrow-plot of this field, I use: > > >>> from enthought.mayavi import mlab as m > >>> x,y,z=field.transpose() > >>> m.quiver3d(x,y,z) > > and this works just fine. Here, the arrays (x and y and z) *each* > contain > one field component (i,e. into one spatial direction) at 300x200x100 > points > in a 3D array. > > Now, I would like to have this data in another format, so I can for > example > save it to a textfile with pylab.savetxt. What I would like are six > arrays, > each 1d, three for the coordinates and three for the field components. > Since > I didn't know any better, I wrote the following procedure: > > def transform_3d_data_(field,lowerBounds,upperBounds): #field is the > same as > above, lowerBounds and upperBounds each contain three values for > x,y,z > min/max > import pylab as p > xx,yy,zz,ex,ey,ez=list(),list(),list(),list(),list(),list() > #xx,yy,zz > will become the spatial coordinates, ex,ey,ez will become the field > components > for xi in range(field.shape[0]): #for each x coordinate... > for yi in range(field.shape[1]): #for each y coordinate... > for zi in range(field.shape[2]): #for each z coordinate... > > xx.append(lowerBounds[0]+xi*(upperBounds[0]-lowerBounds[0])/float(field.shape[0])) > #append this > > yy.append(lowerBounds[1]+yi*(upperBounds[1]-lowerBounds[1])/float(field.shape[1])) > #x, y, z coordinate > > zz.append(lowerBounds[2]+zi*(upperBounds[2]-lowerBounds[2])/float(field.shape[2])) > #to xx, yy, zz .... > ex.append(field[xi][yi][zi][0]) #and also > ey.append(field[xi][yi][zi][1]) #add this field > composition > ez.append(field[xi][yi][zi][2]) #to ex, ey, ez. > xx,yy,zz,ex,ey,ez=[p.array(_) for _ in [xx,yy,zz,ex,ey,ez]] > return xx,yy,zz,ex,ey,ez > > , so I get the desired six 1D-arrays xx,yy,zz for the coordinates and > ex,ey,ez for the field components. It works. > > Now my question: there has to be a better way to get this > re-organization, > right? This one here is much too slow, obviously. Is there maybe a > single > command for pylab that does this? > > Thanks in advance, cheers > > Thomas > > PS. I'm new to this messaging board, and I was wondering if there is > a > "normal" forum as well? I can't even search through the archives at > http://mail.scipy.org/pipermail/numpy-discussion/ :( have there ever > been > discussions/initiatives about porting the mailing list archives for > example > to a phpBB based forum? > From vincent at vincentdavis.net Tue Oct 19 10:29:47 2010 From: vincent at vincentdavis.net (Vincent Davis) Date: Tue, 19 Oct 2010 08:29:47 -0600 Subject: [Numpy-discussion] stride tricks for cellular automata In-Reply-To: References: Message-ID: On Mon, Oct 18, 2010 at 11:54 AM, Robert Cimrman wrote: > FYI: I have added a new Cookbook entry, see [1], hoping that it might be > useful to someone. > > The stride tricks are awesome! Thanks for the entry, I was looking for something similar for a problem I was thinking about. Not sure strides would be the best way to do it but I like your example. Vincent > > r. > > [1] http://scipy.org/Cookbook/GameOfLifeStrides > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -- Thanks Vincent Davis 720-301-3003 From friedrichromstedt at gmail.com Tue Oct 19 13:17:02 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Tue, 19 Oct 2010 19:17:02 +0200 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: 2010/10/19 Darren Dale : > We have been discussing whitespace and line endings at the following > pull request: http://github.com/numpy/numpy/pull/4 . Chuck suggested > we discuss it here on the list. > > I have the following set in my ~/.gitconfig file: > > ? ?[apply] > ? ? ? ?whitespace = fix > > ? ?[core] > ? ? ? ?autocrlf = input > > which is attempting to correct some changes in: > > branding/icons/numpylogo.svg > branding/icons/numpylogoicon.svg > tools/win32build/nsis_scripts/numpy-superinstaller.nsi.in > > David C. suggested that the nsi.in file should not be changed. I > suggested adding a .gitattributes file along with the existing > .gitignore file in the numpy repo. This would enforce windows line > endings for the nsi.in file: > > tools/win32build/nsis_scripts/numpy-superinstaller.nsi.in eol=crlf > > alternatively this would disable any attempt to convert line endings: > > tools/win32build/nsis_scripts/numpy-superinstaller.nsi.in -text This may be useful here: http://www.bluishcoder.co.nz/2007/09/git-binary-files-and-cherry-picking.html Treating svgs and the other files as binary will increase diff's size, but maybe it's an option? my 2 cents, fwiw, Friedrich From mwwiebe at gmail.com Tue Oct 19 15:00:54 2010 From: mwwiebe at gmail.com (Mark Wiebe) Date: Tue, 19 Oct 2010 12:00:54 -0700 Subject: [Numpy-discussion] patch for structured array comparison bug In-Reply-To: References: Message-ID: On Tue, Oct 19, 2010 at 2:24 AM, Pauli Virtanen wrote: > Tue, 19 Oct 2010 01:09:54 -0600, Charles R Harris wrote: > [clip] > > Just a quick look. I wasn't able to add comments to the code, maybe a > > pull request would allow that or maybe you need to enable something. > > I think you can only add comments on commits, not in Github's compare > view. > There are links to the commits at the top of the compare view, where the commenting appears to work. > But perhaps we should just recommend people filing pull requests right > away? > Maybe describing one canonical way to do things (for newcomers, at least), would make things clear? Currently http://docs.scipy.org/doc/numpy/dev/gitwash/development_workflow.html#basic-workflow says "ask for a code review or make a pull request," so I chose the first option. > I'm not sure how broadcasting is supposed to work for > > structured arrays so I will leave that to someone else. ISTR that the > > SUN compiler is persnickety about the initialization of structures, > > only accepts constants or some such. I'll try to track that down or > > maybe someone here who is familiar with that compiler can comment. > > I suspect that this comparison code should refuse to compare arrays with > shape(a) != shape(b), even if `a` and `b` are broadcastable to one > another. The issue is that the broadcasting semantics work on the array > level, but here the boolean sub-array is implicitly reduced to a single > boolean. > I believe this would already be caught by the dtype comparison earlier in array_richcompare, here: http://github.com/numpy/numpy/blob/master/numpy/core/src/multiarray/arrayobject.c#L932 You can also initialize > > dimensions = shape(self) + (-1,) > > and let PyArray_Newshape do the size calculation for you. > > I guess it's best to not initialize structures directly, if there is some > suspicion that obscure compilers don't like it. > I made both of these changes, visible here: http://github.com/m-paradox/numpy/compare/master...fix_structured_compare It looks like to make a pull request, I need to merge my branch back into master. Is that correct, or should I do a pull request from the branch? Either way, adding a note here about that would be helpful: http://docs.scipy.org/doc/numpy/dev/gitwash/development_workflow.html#filing-a-pull-request -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Tue Oct 19 15:35:45 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Tue, 19 Oct 2010 13:35:45 -0600 Subject: [Numpy-discussion] patch for structured array comparison bug In-Reply-To: References: Message-ID: On Tue, Oct 19, 2010 at 1:00 PM, Mark Wiebe wrote: > On Tue, Oct 19, 2010 at 2:24 AM, Pauli Virtanen wrote: > >> Tue, 19 Oct 2010 01:09:54 -0600, Charles R Harris wrote: >> [clip] >> > Just a quick look. I wasn't able to add comments to the code, maybe a >> > pull request would allow that or maybe you need to enable something. >> >> I think you can only add comments on commits, not in Github's compare >> view. >> > > There are links to the commits at the top of the compare view, where the > commenting appears to work. > > >> But perhaps we should just recommend people filing pull requests right >> away? >> > > Maybe describing one canonical way to do things (for newcomers, at least), > would make things clear? Currently > > > http://docs.scipy.org/doc/numpy/dev/gitwash/development_workflow.html#basic-workflow > > > says > "ask for a code review or make a pull request," so I chose the first option. > > We're still working things out after the move, so you get to be sort of a guinea pig ;) I think a pull request is the way to go. > > I'm not sure how broadcasting is supposed to work for >> > structured arrays so I will leave that to someone else. ISTR that the >> > SUN compiler is persnickety about the initialization of structures, >> > only accepts constants or some such. I'll try to track that down or >> > maybe someone here who is familiar with that compiler can comment. >> >> I suspect that this comparison code should refuse to compare arrays with >> shape(a) != shape(b), even if `a` and `b` are broadcastable to one >> another. The issue is that the broadcasting semantics work on the array >> level, but here the boolean sub-array is implicitly reduced to a single >> boolean. >> > > I believe this would already be caught by the dtype comparison earlier in > array_richcompare, here: > > > http://github.com/numpy/numpy/blob/master/numpy/core/src/multiarray/arrayobject.c#L932 > > You can also initialize >> >> dimensions = shape(self) + (-1,) >> >> and let PyArray_Newshape do the size calculation for you. >> >> I guess it's best to not initialize structures directly, if there is some >> suspicion that obscure compilers don't like it. >> > > I made both of these changes, visible here: > > http://github.com/m-paradox/numpy/compare/master...fix_structured_compare > > It looks like to make a pull request, I need to merge my branch back into > master. Is that correct, or should I do a pull request from the branch? > Either way, adding a note here about that would be helpful: > > > http://docs.scipy.org/doc/numpy/dev/gitwash/development_workflow.html#filing-a-pull-request > > > You can request a pull of the branch. Just give it a shot, you can always delete the request. You might want to rebase off the master branch first, however. Chuck > - > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlewi at intellisis.com Tue Oct 19 15:45:03 2010 From: jlewi at intellisis.com (Jeremy Lewi) Date: Tue, 19 Oct 2010 12:45:03 -0700 Subject: [Numpy-discussion] in1d for structure arrays Message-ID: <005f01cb6fc6$22a33480$67e99d80$@com> Hi, I noticed that the recent numpy (1.5) implements the function in1d in set operations. Unfortunately this doesn't seem to work for structure arrays because "mergesort" isn't implemented for structure arrays. I was able to implement a quick work-around simply by adding a structure field to keep track of which list the data came from and then making this field the lowest priority in the sort. Is this worth creating a ticket for? (I don't have trac privileges to do so) Jeremy Jeremy Lewi Engineering Scientist The Intellisis Corporation jlewi at intellisis.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwwiebe at gmail.com Tue Oct 19 15:46:46 2010 From: mwwiebe at gmail.com (Mark Wiebe) Date: Tue, 19 Oct 2010 12:46:46 -0700 Subject: [Numpy-discussion] patch for structured array comparison bug In-Reply-To: References: Message-ID: On Tue, Oct 19, 2010 at 12:35 PM, Charles R Harris < charlesr.harris at gmail.com> wrote: > >> > We're still working things out after the move, so you get to be sort of a > guinea pig ;) I think a pull request is the way to go. > Sounds good. :) > > > You can request a pull of the branch. Just give it a shot, you can always > delete the request. You might want to rebase off the master branch first, > however. > > Done. It looked like I was already rebased off master, but I can try again if the pull request merges funny. -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent at vincentdavis.net Tue Oct 19 17:54:49 2010 From: vincent at vincentdavis.net (Vincent Davis) Date: Tue, 19 Oct 2010 15:54:49 -0600 Subject: [Numpy-discussion] how to ask numpy what bit version it is running (32/64) Message-ID: What is the best/good way to know what version of numpy is running (32 or 64 bit). Showing my ignorance maybe but does it always match the python version that is running, which can be ask/tested using sys.maxint? -- Thanks Vincent Davis From cournape at gmail.com Tue Oct 19 18:09:54 2010 From: cournape at gmail.com (David Cournapeau) Date: Wed, 20 Oct 2010 07:09:54 +0900 Subject: [Numpy-discussion] how to ask numpy what bit version it is running (32/64) In-Reply-To: References: Message-ID: On Wed, Oct 20, 2010 at 6:54 AM, Vincent Davis wrote: > What is the best/good way to know what version of numpy is running (32 > or 64 bit). import platform print platform.machine() > Showing my ignorance maybe but does it always match the python version > that is running, which can be ask/tested using sys.maxint? Yes, I don't know any system which enables you do load a 32 bits extension into a 64 bits. Neither windows, mac or linux can at least, cheers, David From jrocher at enthought.com Tue Oct 19 18:13:13 2010 From: jrocher at enthought.com (Jonathan Rocher) Date: Tue, 19 Oct 2010 17:13:13 -0500 Subject: [Numpy-discussion] how to ask numpy what bit version it is running (32/64) In-Reply-To: References: Message-ID: Hi, If you directly want to know if it is a 32 or 64 bits, you can also use import platform print platform.architecture() Best, Jonathan On Tue, Oct 19, 2010 at 5:09 PM, David Cournapeau wrote: > On Wed, Oct 20, 2010 at 6:54 AM, Vincent Davis > wrote: > > What is the best/good way to know what version of numpy is running (32 > > or 64 bit). > > import platform > print platform.machine() > > > Showing my ignorance maybe but does it always match the python version > > that is running, which can be ask/tested using sys.maxint? > > Yes, I don't know any system which enables you do load a 32 bits > extension into a 64 bits. Neither windows, mac or linux can at least, > > cheers, > > David > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -- Jonathan Rocher, Enthought, Inc. jrocher at enthought.com 1-512-536-1057 http://www.enthought.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent at vincentdavis.net Tue Oct 19 18:25:21 2010 From: vincent at vincentdavis.net (Vincent Davis) Date: Tue, 19 Oct 2010 16:25:21 -0600 Subject: [Numpy-discussion] how to ask numpy what bit version it is running (32/64) In-Reply-To: References: Message-ID: On Tue, Oct 19, 2010 at 4:13 PM, Jonathan Rocher wrote: > Hi, > > If you directly want to know if it is a 32 or 64 bits, you can also use > import platform > print platform.architecture() > > Best, > Jonathan > > On Tue, Oct 19, 2010 at 5:09 PM, David Cournapeau > wrote: >> >> On Wed, Oct 20, 2010 at 6:54 AM, Vincent Davis >> wrote: >> > What is the best/good way to know what version of numpy is running (32 >> > or 64 bit). >> >> import platform >> print platform.machine() >> >> > Showing my ignorance maybe but does it always match the python version >> > that is running, which can be ask/tested using sys.maxint? >> >> Yes, I don't know any system which enables you do load a 32 bits >> extension into a 64 bits. Neither windows, mac or linux can at least, >> >> cheers, >> >> David on python27 64 bit import platform print platform.machine() i386 print platform.architecture() ('64bit', '') sys.maxint 9223372036854775807 on python2.6 32bit >>> import platform >>> print platform.machine() i386 >>> print platform.architecture() ('32bit', '') sys.maxint 2147483647 And given David's answers if python is 64(or 32) then numpy/scipy is the same or not working :-) Thanks Vincent >>> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > -- > Jonathan Rocher, > Enthought, Inc. > jrocher at enthought.com > 1-512-536-1057 > http://www.enthought.com > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > -- Thanks Vincent Davis 720-301-3003 From dewald.pieterse at gmail.com Tue Oct 19 21:09:39 2010 From: dewald.pieterse at gmail.com (Dewald Pieterse) Date: Wed, 20 Oct 2010 01:09:39 +0000 Subject: [Numpy-discussion] Count occurrences in a nested ndarray Message-ID: Hi All I have a nested array created using: edges = scipy.misc.pilutil.imfilter(prent,'find_edges') edges array([[[ 0, 255, 0], [ 0, 255, 0], [ 0, 255, 0], ..., [ 0, 255, 0], [ 0, 255, 0], [ 0, 255, 0]], [[ 0, 255, 0], [ 0, 0, 0], [ 0, 0, 0], ..., [ 0, 0, 0], [ 0, 0, 0], [ 0, 255, 0]], [[ 0, 255, 0], [ 0, 0, 0], [ 0, 0, 0], ..., [ 0, 0, 0], [ 0, 0, 0], [ 0, 255, 0]], ..., [[ 0, 255, 0], [ 0, 0, 0], [ 0, 0, 0], ..., [ 0, 0, 0], [ 0, 0, 0], [ 0, 255, 0]], [[ 0, 255, 0], [ 0, 0, 0], [ 0, 0, 0], ..., [ 0, 0, 0], [ 0, 0, 0], [ 0, 255, 0]], [[ 0, 255, 0], [ 0, 255, 0], [ 0, 255, 0], ..., [ 0, 255, 0], [ 0, 255, 0], [ 0, 255, 0]]], dtype=uint8) I want to count the number of occurrences of certain unique elements in the array, I know what the elements are that I want to count [0,255,0], [255,0,0] and [0,0,255]. I want to count the number of pixels of a particular color in a picture to determine the edge length and calculate areas and such. array does not have a array.count() method and trying to count the instances using a nested for loop like: for xiter in range(xindex): for yiter in range(yindex): if edges[xiter,yiter,:] == [255,0,0]: groenpixelarea = groenpixelarea + 1 if edges[xiter,yiter,:] == [0,255,0]: rooipixelarea = rooipixelarea + 1 if edges[xiter,yiter,:] == [0,0,255]: bloupixelarea = bloupixelarea + 1 results in: 16 for xiter in range(xindex): 17 for yiter in range(yindex): ---> 18 if edges[xiter,yiter,:].any() == [255,0,0]: 19 groenpixelarea = groenpixelarea + 1 20 if edges[xiter,yiter,:] == [0,255,0]: ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all() WARNING: Failure executing file: What am I doing wrong? Thanx -- Dewald Pieterse -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Tue Oct 19 21:29:40 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Tue, 19 Oct 2010 21:29:40 -0400 Subject: [Numpy-discussion] Count occurrences in a nested ndarray In-Reply-To: References: Message-ID: On Tue, Oct 19, 2010 at 9:09 PM, Dewald Pieterse wrote: > Hi All > I have a nested array created using: > edges = scipy.misc.pilutil.imfilter(prent,'find_edges') > edges > array([[[ ?0, 255, ? 0], > ?? ? ? ?[ ?0, 255, ? 0], > ?? ? ? ?[ ?0, 255, ? 0], > ?? ? ? ?..., > ?? ? ? ?[ ?0, 255, ? 0], > ?? ? ? ?[ ?0, 255, ? 0], > ?? ? ? ?[ ?0, 255, ? 0]], > ?? ? ? [[ ?0, 255, ? 0], > ?? ? ? ?[ ?0, ? 0, ? 0], > ?? ? ? ?[ ?0, ? 0, ? 0], > ?? ? ? ?..., > ?? ? ? ?[ ?0, ? 0, ? 0], > ?? ? ? ?[ ?0, ? 0, ? 0], > ?? ? ? ?[ ?0, 255, ? 0]], > ?? ? ? [[ ?0, 255, ? 0], > ?? ? ? ?[ ?0, ? 0, ? 0], > ?? ? ? ?[ ?0, ? 0, ? 0], > ?? ? ? ?..., > ?? ? ? ?[ ?0, ? 0, ? 0], > ?? ? ? ?[ ?0, ? 0, ? 0], > ?? ? ? ?[ ?0, 255, ? 0]], > ?? ? ? ..., > ?? ? ? [[ ?0, 255, ? 0], > ?? ? ? ?[ ?0, ? 0, ? 0], > ?? ? ? ?[ ?0, ? 0, ? 0], > ?? ? ? ?..., > ?? ? ? ?[ ?0, ? 0, ? 0], > ?? ? ? ?[ ?0, ? 0, ? 0], > ?? ? ? ?[ ?0, 255, ? 0]], > ?? ? ? [[ ?0, 255, ? 0], > ?? ? ? ?[ ?0, ? 0, ? 0], > ?? ? ? ?[ ?0, ? 0, ? 0], > ?? ? ? ?..., > ?? ? ? ?[ ?0, ? 0, ? 0], > ?? ? ? ?[ ?0, ? 0, ? 0], > ?? ? ? ?[ ?0, 255, ? 0]], > ?? ? ? [[ ?0, 255, ? 0], > ?? ? ? ?[ ?0, 255, ? 0], > ?? ? ? ?[ ?0, 255, ? 0], > ?? ? ? ?..., > ?? ? ? ?[ ?0, 255, ? 0], > ?? ? ? ?[ ?0, 255, ? 0], > ?? ? ? ?[ ?0, 255, ? 0]]], dtype=uint8) > I want to count the number of?occurrences of certain unique elements in the > array, I know what the elements are that I want to count [0,255,0], > [255,0,0] and [0,0,255]. > I want to count the number of pixels of a particular?color?in a picture to > determine the edge length and calculate areas and such. > array does not have a array.count() method and trying to count the instances > using a nested for loop like: > for xiter in range(xindex): > for yiter in range(yindex): > if edges[xiter,yiter,:] == [255,0,0]: > groenpixelarea = groenpixelarea + 1 > if edges[xiter,yiter,:] == [0,255,0]: > rooipixelarea = rooipixelarea + 1 > if edges[xiter,yiter,:] == [0,0,255]: > bloupixelarea = bloupixelarea + 1 > results in: > ?? ?16 for xiter in range(xindex): > ?? ? 17 ? ? ? ? for yiter in range(yindex): > ---> 18 ? ? ? ? ? ? ? ? if edges[xiter,yiter,:].any() == [255,0,0]: > ?? ? 19 ? ? ? ? ? ? ? ? ? ? ? ? groenpixelarea = groenpixelarea + 1 > ?? ? 20 ? ? ? ? ? ? ? ? if edges[xiter,yiter,:] == [0,255,0]: > ValueError: The truth value of an array with more than one element is > ambiguous. Use a.any() or a.all() > WARNING: Failure executing file: > > What am I doing wrong? if (edges[xiter,yiter,:] == [255,0,0]).all() makes element wise comparison and then joins them by all but you should be able to do this for all pixels at one (edges == np.array([255,0,0])[None, None,:]).all(-1).sum() or something like this For more complex patterns there might be something fast in scipy.ndimage. Josef > Thanx > -- > Dewald Pieterse > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > From lutz.maibaum at gmail.com Tue Oct 19 21:32:41 2010 From: lutz.maibaum at gmail.com (Lutz Maibaum) Date: Tue, 19 Oct 2010 18:32:41 -0700 Subject: [Numpy-discussion] Count occurrences in a nested ndarray In-Reply-To: References: Message-ID: <1D9D2607-BFE6-40C6-8F89-2DEED75CAB9F@gmail.com> On Oct 19, 2010, at 6:09 PM, Dewald Pieterse wrote: > for xiter in range(xindex): > for yiter in range(yindex): > if edges[xiter,yiter,:] == [255,0,0]: > groenpixelarea = groenpixelarea + 1 > if edges[xiter,yiter,:] == [0,255,0]: > rooipixelarea = rooipixelarea + 1 > if edges[xiter,yiter,:] == [0,0,255]: > bloupixelarea = bloupixelarea + 1 > > results in: > > 16 for xiter in range(xindex): > 17 for yiter in range(yindex): > ---> 18 if edges[xiter,yiter,:].any() == [255,0,0]: > 19 groenpixelarea = groenpixelarea + 1 > 20 if edges[xiter,yiter,:] == [0,255,0]: > > ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all() > WARNING: Failure executing file: The array comparison results in an array of booleans, which cannot be used as a condition in the if statement. You could use if alltrue(edges[xiter,yiter,:] == [255,0,0]): groenpixelarea = groenpixelarea + 1 There are probably much faster ways to do this that do not require iterating over all pixels. You could try groenpixelarea = sum(alltrue(a.reshape((-1,3)) == array([0,0,255]), axis=1)) Hope this helps, Lutz From vincent at vincentdavis.net Tue Oct 19 22:11:31 2010 From: vincent at vincentdavis.net (Vincent Davis) Date: Tue, 19 Oct 2010 20:11:31 -0600 Subject: [Numpy-discussion] how to ask numpy what bit version it is running (32/64) In-Reply-To: References: Message-ID: A little followup from the python list. I thought this was worth sharing here. Quoting Ned Deily, nad at acm.org " It looks better but , unfortunately, it doesn't work correctly on OS X where a universal build can have both 32-bit and 64-bit executables in the same file. $ arch -x86_64 /usr/local/bin/python2.7 -c 'import sys,platform; print(sys.maxint,platform.architecture())' (9223372036854775807, ('64bit', '')) $ arch -i386 /usr/local/bin/python2.7 -c 'import sys,platform; print(sys.maxint,platform.architecture())' (2147483647, ('64bit', '')) At the moment, the sys.maxint trick is the simplest reliable test for Python 2 on OS X. For Python 3, substitute sys.maxsize. > Yes that looks like the right way of doing it. Interesting though that > platform.machine()=i386 and not something about 64. > >>> print platform.machine() > i386 > >>> print platform.architecture() > ('64bit', '') > >>> import sys; sys.maxint > 9223372036854775807 Currently on OS X (10.6 and earlier), uname returns 'i386' for any Intel platform, 32-bit only or 32-bit /64-bit capable. $ uname -p i386 " On Tue, Oct 19, 2010 at 4:25 PM, Vincent Davis wrote: > On Tue, Oct 19, 2010 at 4:13 PM, Jonathan Rocher wrote: >> Hi, >> >> If you directly want to know if it is a 32 or 64 bits, you can also use >> import platform >> print platform.architecture() >> >> Best, >> Jonathan >> >> On Tue, Oct 19, 2010 at 5:09 PM, David Cournapeau >> wrote: >>> >>> On Wed, Oct 20, 2010 at 6:54 AM, Vincent Davis >>> wrote: >>> > What is the best/good way to know what version of numpy is running (32 >>> > or 64 bit). >>> >>> import platform >>> print platform.machine() >>> >>> > Showing my ignorance maybe but does it always match the python version >>> > that is running, which can be ask/tested using sys.maxint? >>> >>> Yes, I don't know any system which enables you do load a 32 bits >>> extension into a 64 bits. Neither windows, mac or linux can at least, >>> >>> cheers, >>> >>> David > > on python27 64 bit > import platform > print platform.machine() > i386 > print platform.architecture() > ('64bit', '') > sys.maxint > 9223372036854775807 > > on python2.6 32bit >>>> import platform >>>> print platform.machine() > i386 >>>> print platform.architecture() > ('32bit', '') > sys.maxint > 2147483647 > > And given David's answers if python is 64(or 32) then numpy/scipy is > the same or not working :-) > > Thanks > Vincent > > >>>> > >>> _______________________________________________ >>> NumPy-Discussion mailing list >>> NumPy-Discussion at scipy.org >>> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> >> >> >> -- >> Jonathan Rocher, >> Enthought, Inc. >> jrocher at enthought.com >> 1-512-536-1057 >> http://www.enthought.com >> >> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> >> > > > > -- > Thanks > Vincent Davis > 720-301-3003 > -- Thanks Vincent Davis 720-301-3003 From mwwiebe at gmail.com Tue Oct 19 23:03:00 2010 From: mwwiebe at gmail.com (Mark Wiebe) Date: Tue, 19 Oct 2010 20:03:00 -0700 Subject: [Numpy-discussion] how to ask numpy what bit version it is running (32/64) In-Reply-To: References: Message-ID: What about this as a possibility: >>> numpy.intp(0).itemsize == 8 True -Mark On Tue, Oct 19, 2010 at 7:11 PM, Vincent Davis wrote: > A little followup from the python list. I thought this was worth sharing > here. > > Quoting Ned Deily, nad at acm.org > > " > It looks better but , > unfortunately, it doesn't work correctly on OS X > where a universal build can have both 32-bit and 64-bit executables in > the same file. > > $ arch -x86_64 /usr/local/bin/python2.7 -c 'import sys,platform; > print(sys.maxint,platform.architecture())' > (9223372036854775807, ('64bit', '')) > $ arch -i386 /usr/local/bin/python2.7 -c 'import sys,platform; > print(sys.maxint,platform.architecture())' > (2147483647, ('64bit', '')) > > At the moment, the sys.maxint trick is the simplest reliable test for > Python 2 on OS X. For Python 3, substitute sys.maxsize. > > > Yes that looks like the right way of doing it. Interesting though that > > platform.machine()=i386 and not something about 64. > > >>> print platform.machine() > > i386 > > >>> print platform.architecture() > > ('64bit', '') > > >>> import sys; sys.maxint > > 9223372036854775807 > > Currently on OS X (10.6 and earlier), uname returns 'i386' for any Intel > platform, 32-bit only or 32-bit /64-bit capable. > > $ uname -p > i386 > " > > On Tue, Oct 19, 2010 at 4:25 PM, Vincent Davis > wrote: > > On Tue, Oct 19, 2010 at 4:13 PM, Jonathan Rocher > wrote: > >> Hi, > >> > >> If you directly want to know if it is a 32 or 64 bits, you can also use > >> import platform > >> print platform.architecture() > >> > >> Best, > >> Jonathan > >> > >> On Tue, Oct 19, 2010 at 5:09 PM, David Cournapeau > >> wrote: > >>> > >>> On Wed, Oct 20, 2010 at 6:54 AM, Vincent Davis < > vincent at vincentdavis.net> > >>> wrote: > >>> > What is the best/good way to know what version of numpy is running > (32 > >>> > or 64 bit). > >>> > >>> import platform > >>> print platform.machine() > >>> > >>> > Showing my ignorance maybe but does it always match the python > version > >>> > that is running, which can be ask/tested using sys.maxint? > >>> > >>> Yes, I don't know any system which enables you do load a 32 bits > >>> extension into a 64 bits. Neither windows, mac or linux can at least, > >>> > >>> cheers, > >>> > >>> David > > > > on python27 64 bit > > import platform > > print platform.machine() > > i386 > > print platform.architecture() > > ('64bit', '') > > sys.maxint > > 9223372036854775807 > > > > on python2.6 32bit > >>>> import platform > >>>> print platform.machine() > > i386 > >>>> print platform.architecture() > > ('32bit', '') > > sys.maxint > > 2147483647 > > > > And given David's answers if python is 64(or 32) then numpy/scipy is > > the same or not working :-) > > > > Thanks > > Vincent > > > > > >>>> > > > >>> _______________________________________________ > >>> NumPy-Discussion mailing list > >>> NumPy-Discussion at scipy.org > >>> http://mail.scipy.org/mailman/listinfo/numpy-discussion > >> > >> > >> > >> -- > >> Jonathan Rocher, > >> Enthought, Inc. > >> jrocher at enthought.com > >> 1-512-536-1057 > >> http://www.enthought.com > >> > >> > >> _______________________________________________ > >> NumPy-Discussion mailing list > >> NumPy-Discussion at scipy.org > >> http://mail.scipy.org/mailman/listinfo/numpy-discussion > >> > >> > > > > > > > > -- > > Thanks > > Vincent Davis > > 720-301-3003 > > > > > > -- > Thanks > Vincent Davis > 720-301-3003 > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Tue Oct 19 23:25:10 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Tue, 19 Oct 2010 21:25:10 -0600 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: On Tue, Oct 19, 2010 at 11:17 AM, Friedrich Romstedt < friedrichromstedt at gmail.com> wrote: > 2010/10/19 Darren Dale : > > We have been discussing whitespace and line endings at the following > > pull request: http://github.com/numpy/numpy/pull/4 . Chuck suggested > > we discuss it here on the list. > > > > I have the following set in my ~/.gitconfig file: > > > > [apply] > > whitespace = fix > > > > [core] > > autocrlf = input > > > > which is attempting to correct some changes in: > > > > branding/icons/numpylogo.svg > > branding/icons/numpylogoicon.svg > > tools/win32build/nsis_scripts/numpy-superinstaller.nsi.in > > > > David C. suggested that the nsi.in file should not be changed. I > > suggested adding a .gitattributes file along with the existing > > .gitignore file in the numpy repo. This would enforce windows line > > endings for the nsi.in file: > > > > tools/win32build/nsis_scripts/numpy-superinstaller.nsi.in eol=crlf > > > > alternatively this would disable any attempt to convert line endings: > > > > tools/win32build/nsis_scripts/numpy-superinstaller.nsi.in -text > > This may be useful here: > > http://www.bluishcoder.co.nz/2007/09/git-binary-files-and-cherry-picking.html > > Treating svgs and the other files as binary will increase diff's size, > but maybe it's an option? > > my 2 cents, fwiw, > Well, this post hasn't generated much comment. I think we do need a .gitconfig file for the project so why don't you go ahead and make one and deal with the nsi.in file in the process. The .svg files can have their line endings converted to line feeds which will give us two less files to worry about. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From gael.varoquaux at normalesup.org Wed Oct 20 03:23:49 2010 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Wed, 20 Oct 2010 09:23:49 +0200 Subject: [Numpy-discussion] Atlas build issues Message-ID: <20101020072349.GA10163@phare.normalesup.org> I am really sorry to be landing on the mailing list with Atlas build issues. I usually manage be myself to build Atlas, but this time I have been fighting for a couple of days with little success. The reason I need to build Atlas is that our work computers are stuck on Mandriva 2008.0, in which the version of Atlas packaged by the system is not usable. Anyhow, I lost quite a while with Atlas 3.9.26, for which I was never able to build libaries that could be used in a '.so' (seemed that the -fPIC was not working, but really I don't understand what was going on in the maze of makefiles). After that I switched to 3.9;25, which I have already have gotten working on another system (Mandriva 2008, but 32 bits). Know everything builds, but I get a missing symbol at the import: from numpy.linalg import lapack_lite ImportError: /volatile/varoquau/dev/numpy/numpy/linalg/lapack_lite.so: undefined symbol: zgesdd_ I don't have g77 installed on the system at all, to avoid gfortran/g77 mixups. I am attaching the stout of 'python setup.py build_ext -i', in case it contains useful information. Would anybody have suggestions with regards to what I am doing wrong? Cheers, Ga?l From pearu.peterson at gmail.com Wed Oct 20 03:32:48 2010 From: pearu.peterson at gmail.com (Pearu Peterson) Date: Wed, 20 Oct 2010 10:32:48 +0300 Subject: [Numpy-discussion] Atlas build issues In-Reply-To: <20101020072349.GA10163@phare.normalesup.org> References: <20101020072349.GA10163@phare.normalesup.org> Message-ID: <4CBE9B20.6000902@cens.ioc.ee> On 10/20/2010 10:23 AM, Gael Varoquaux wrote: > I am really sorry to be landing on the mailing list with Atlas build > issues. I usually manage be myself to build Atlas, but this time I have > been fighting for a couple of days with little success. > > The reason I need to build Atlas is that our work computers are stuck on > Mandriva 2008.0, in which the version of Atlas packaged by the system is > not usable. > > Anyhow, I lost quite a while with Atlas 3.9.26, for which I was never > able to build libaries that could be used in a '.so' (seemed that the > -fPIC was not working, but really I don't understand what was going on in > the maze of makefiles). After that I switched to 3.9;25, which I have > already have gotten working on another system (Mandriva 2008, but 32 > bits). Know everything builds, but I get a missing symbol at the import: > > from numpy.linalg import lapack_lite > ImportError: /volatile/varoquau/dev/numpy/numpy/linalg/lapack_lite.so: > undefined symbol: zgesdd_ > > I don't have g77 installed on the system at all, to avoid gfortran/g77 > mixups. > > I am attaching the stout of 'python setup.py build_ext -i', in case it > contains useful information. > > Would anybody have suggestions with regards to what I am doing wrong? I could not read the stdout but perhaps you didn't build atlas with complete lapack. The basic steps for that are described in http://math-atlas.sourceforge.net/errata.html#completelp HTH, Pearu From gael.varoquaux at normalesup.org Wed Oct 20 03:38:25 2010 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Wed, 20 Oct 2010 09:38:25 +0200 Subject: [Numpy-discussion] Atlas build issues In-Reply-To: <4CBE9B20.6000902@cens.ioc.ee> References: <20101020072349.GA10163@phare.normalesup.org> <4CBE9B20.6000902@cens.ioc.ee> Message-ID: <20101020073825.GE9916@phare.normalesup.org> On Wed, Oct 20, 2010 at 10:32:48AM +0300, Pearu Peterson wrote: > I could not read the stdout Because I forgot to attach it! I added it >but perhaps you didn't build atlas with complete lapack. That's quite possible. The size of liblapack.a seems a bit too small (1.1M). On the system for which it works, I have 8M. > The basic steps for that are described in > http://math-atlas.sourceforge.net/errata.html#completelp Hum, this page is mentionning a '--with-netlib-lapack' swith the the configre that is not in the INSTALL.txt of my atlas version. I was using the '-Ss flapack' switch. I'll investigate that. Thanks a lot for the pointer, Ga?l -------------- next part -------------- F2PY Version 2_8716 blas_opt_info: blas_mkl_info: libraries mkl,vml,guide not found in /usr/local/lib64 libraries mkl,vml,guide not found in /usr/local/lib libraries mkl,vml,guide not found in /opt/lib libraries mkl,vml,guide not found in /usr/lib64 libraries mkl,vml,guide not found in /usr/lib NOT AVAILABLE atlas_blas_threads_info: Setting PTATLAS=ATLAS Setting PTATLAS=ATLAS customize GnuFCompiler Could not locate executable g77 Could not locate executable f77 customize IntelFCompiler Could not locate executable ifort Could not locate executable ifc customize LaheyFCompiler Could not locate executable lf95 customize PGroupFCompiler Could not locate executable pgf90 Could not locate executable pgf77 customize AbsoftFCompiler Could not locate executable f90 customize NAGFCompiler Found executable /usr/bin/f95 customize VastFCompiler customize CompaqFCompiler Could not locate executable fort customize IntelItaniumFCompiler Could not locate executable efort Could not locate executable efc customize IntelEM64TFCompiler customize Gnu95FCompiler Found executable /usr/bin/gfortran customize Gnu95FCompiler customize Gnu95FCompiler 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 -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fexceptions -g -fPIC compile options: '-c' gcc: _configtest.c gcc -pthread _configtest.o -L/volatile/varoquau/usr/lib/ -lptf77blas -lptcblas -latlas -o _configtest ATLAS version 3.9.25 built by varoquau on Tue Oct 19 18:39:00 CEST 2010: UNAME : Linux is143560 2.6.22.19-server-2mdv #1 SMP Mon May 5 21:53:42 EDT 2008 x86_64 Intel(R) Xeon(R) CPU E5440 @ 2.83GHz GNU/Linux INSTFLG : -1 0 -a 1 -l 1 ARCHDEFS : -DATL_OS_Linux -DATL_ARCH_Core2 -DATL_CPUMHZ=2826 -DATL_SSE3 -DATL_SSE2 -DATL_SSE1 -DATL_USE64BITS -DATL_GAS_x8664 F2CDEFS : -DAdd_ -DF77_INTEGER=int -DStringSunStyle CACHEEDGE: 1572864 F77 : gfortran, version GNU Fortran (GCC) 4.2.2 20071128 (prerelease) (4.2.2-3.1mdv2008.0) F77FLAGS : -O -fPIC -m64 SMC : gcc, version gcc (GCC) 4.2.2 20071128 (prerelease) (4.2.2-3.1mdv2008.0) SMCFLAGS : -fomit-frame-pointer -mfpmath=sse -msse3 -O2 -fPIC -m64 SKC : gcc, version gcc (GCC) 4.2.2 20071128 (prerelease) (4.2.2-3.1mdv2008.0) SKCFLAGS : -fomit-frame-pointer -mfpmath=sse -msse3 -O2 -fPIC -m64 success! removing: _configtest.c _configtest.o _configtest Setting PTATLAS=ATLAS FOUND: libraries = ['ptf77blas', 'ptcblas', 'atlas'] library_dirs = ['/volatile/varoquau/usr/lib/'] language = c define_macros = [('ATLAS_INFO', '"\\"3.9.25\\""')] include_dirs = ['/volatile/varoquau/usr/src/ATLAS/include'] FOUND: libraries = ['ptf77blas', 'ptcblas', 'atlas'] library_dirs = ['/volatile/varoquau/usr/lib/'] language = c define_macros = [('ATLAS_INFO', '"\\"3.9.25\\""')] include_dirs = ['/volatile/varoquau/usr/src/ATLAS/include'] lapack_opt_info: lapack_mkl_info: mkl_info: libraries mkl,vml,guide not found in /usr/local/lib64 libraries mkl,vml,guide not found in /usr/local/lib libraries mkl,vml,guide not found in /opt/lib libraries mkl,vml,guide not found in /usr/lib64 libraries mkl,vml,guide not found in /usr/lib NOT AVAILABLE NOT AVAILABLE atlas_threads_info: Setting PTATLAS=ATLAS libraries lapack_atlas not found in /volatile/varoquau/usr/lib/ numpy.distutils.system_info.atlas_threads_info Setting PTATLAS=ATLAS Setting PTATLAS=ATLAS FOUND: libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas'] library_dirs = ['/volatile/varoquau/usr/lib/'] language = c define_macros = [('ATLAS_INFO', '"\\"3.9.25\\""')] include_dirs = ['/volatile/varoquau/usr/src/ATLAS/include'] FOUND: libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas'] library_dirs = ['/volatile/varoquau/usr/lib/'] language = c define_macros = [('ATLAS_INFO', '"\\"3.9.25\\""')] include_dirs = ['/volatile/varoquau/usr/src/ATLAS/include'] running build_ext running build_src build_src building py_modules sources building library "npymath" sources creating build creating build/src.linux-x86_64-2.5 customize GnuFCompiler customize IntelFCompiler customize LaheyFCompiler customize PGroupFCompiler customize AbsoftFCompiler customize NAGFCompiler customize VastFCompiler customize CompaqFCompiler customize IntelItaniumFCompiler customize IntelEM64TFCompiler customize Gnu95FCompiler customize Gnu95FCompiler customize Gnu95FCompiler using config C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fexceptions -g -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/usr/include/python2.5 -c' gcc: _configtest.c gcc -pthread _configtest.o -o _configtest success! removing: _configtest.c _configtest.o _configtest C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fexceptions -g -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/usr/include/python2.5 -c' gcc: _configtest.c _configtest.c:1: warning: conflicting types for built-in function ?exp? gcc -pthread _configtest.o -o _configtest _configtest.o: In function `main': /volatile/varoquau/dev/numpy/_configtest.c:6: undefined reference to `exp' collect2: ld returned 1 exit status _configtest.o: In function `main': /volatile/varoquau/dev/numpy/_configtest.c:6: 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 -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fexceptions -g -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/usr/include/python2.5 -c' gcc: _configtest.c _configtest.c:1: warning: conflicting types for built-in function ?exp? gcc -pthread _configtest.o -lm -o _configtest success! removing: _configtest.c _configtest.o _configtest building extension "numpy.core._sort" sources adding 'numpy/core/include/numpy/config.h' to sources. adding 'numpy/core/include/numpy/_numpyconfig.h' to sources. executing numpy/core/code_generators/generate_numpy_api.py adding 'numpy/core/include/numpy/__multiarray_api.h' to sources. numpy.core - nothing done with h_files = ['numpy/core/include/numpy/config.h', 'numpy/core/include/numpy/_numpyconfig.h', 'numpy/core/include/numpy/__multiarray_api.h'] building extension "numpy.core.multiarray" sources adding 'numpy/core/include/numpy/config.h' to sources. adding 'numpy/core/include/numpy/_numpyconfig.h' to sources. executing numpy/core/code_generators/generate_numpy_api.py adding 'numpy/core/include/numpy/__multiarray_api.h' to sources. numpy.core - nothing done with h_files = ['numpy/core/include/numpy/config.h', 'numpy/core/include/numpy/_numpyconfig.h', 'numpy/core/include/numpy/__multiarray_api.h'] building extension "numpy.core.umath" sources adding 'numpy/core/include/numpy/config.h' to sources. adding 'numpy/core/include/numpy/_numpyconfig.h' to sources. executing numpy/core/code_generators/generate_ufunc_api.py adding 'numpy/core/include/numpy/__ufunc_api.h' to sources. adding 'numpy/core/src/umath' to include_dirs. numpy.core - nothing done with h_files = ['numpy/core/src/umath/funcs.inc', 'numpy/core/include/numpy/config.h', 'numpy/core/include/numpy/_numpyconfig.h', 'numpy/core/include/numpy/__ufunc_api.h'] building extension "numpy.core.scalarmath" sources adding 'numpy/core/include/numpy/config.h' to sources. adding 'numpy/core/include/numpy/_numpyconfig.h' to sources. executing numpy/core/code_generators/generate_numpy_api.py adding 'numpy/core/include/numpy/__multiarray_api.h' to sources. executing numpy/core/code_generators/generate_ufunc_api.py adding 'numpy/core/include/numpy/__ufunc_api.h' to sources. numpy.core - nothing done with h_files = ['numpy/core/include/numpy/config.h', 'numpy/core/include/numpy/_numpyconfig.h', 'numpy/core/include/numpy/__multiarray_api.h', 'numpy/core/include/numpy/__ufunc_api.h'] building extension "numpy.core._dotblas" sources adding 'numpy/core/blasdot/_dotblas.c' to sources. building extension "numpy.core.umath_tests" sources building extension "numpy.core.multiarray_tests" sources building extension "numpy.lib._compiled_base" sources building extension "numpy.numarray._capi" sources building extension "numpy.fft.fftpack_lite" sources building extension "numpy.linalg.lapack_lite" sources adding 'numpy/linalg/lapack_litemodule.c' to sources. adding 'numpy/linalg/python_xerbla.c' to sources. building extension "numpy.random.mtrand" sources C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fexceptions -g -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/usr/include/python2.5 -c' gcc: _configtest.c gcc -pthread _configtest.o -o _configtest _configtest failure. removing: _configtest.c _configtest.o _configtest building data_files sources build_src: building npy-pkg config files customize UnixCCompiler customize UnixCCompiler using build_clib building 'npymath' library compiling C sources C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fexceptions -g -fPIC creating build/temp.linux-x86_64-2.5 creating build/temp.linux-x86_64-2.5/numpy creating build/temp.linux-x86_64-2.5/numpy/core creating build/temp.linux-x86_64-2.5/numpy/core/src creating build/temp.linux-x86_64-2.5/numpy/core/src/npymath compile options: '-Inumpy/core/include -Inumpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/usr/include/python2.5 -Inumpy/core/src/multiarray -Inumpy/core/src/umath -c' gcc: numpy/core/src/npymath/ieee754.c gcc: numpy/core/src/npymath/npy_math_complex.c gcc: numpy/core/src/npymath/npy_math.c ar: adding 3 object files to build/temp.linux-x86_64-2.5/libnpymath.a customize UnixCCompiler customize UnixCCompiler using build_ext building 'numpy.core._sort' extension compiling C sources C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fexceptions -g -fPIC compile options: '-Inumpy/core/include -Inumpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/usr/include/python2.5 -Inumpy/core/src/multiarray -Inumpy/core/src/umath -c' gcc: numpy/core/src/_sortmodule.c gcc -pthread -shared build/temp.linux-x86_64-2.5/numpy/core/src/_sortmodule.o -L/usr/lib64 -Lbuild/temp.linux-x86_64-2.5 -lm -lpython2.5 -o numpy/core/_sort.so building 'numpy.core.multiarray' extension compiling C sources C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fexceptions -g -fPIC creating build/temp.linux-x86_64-2.5/numpy/core/src/multiarray compile options: '-Inumpy/core/include -Inumpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/usr/include/python2.5 -Inumpy/core/src/multiarray -Inumpy/core/src/umath -c' gcc: numpy/core/src/multiarray/multiarraymodule_onefile.c gcc -pthread -shared build/temp.linux-x86_64-2.5/numpy/core/src/multiarray/multiarraymodule_onefile.o -L/usr/lib64 -Lbuild/temp.linux-x86_64-2.5 -lnpymath -lm -lpython2.5 -o numpy/core/multiarray.so building 'numpy.core.umath' extension compiling C sources C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fexceptions -g -fPIC creating build/temp.linux-x86_64-2.5/numpy/core/src/umath compile options: '-Inumpy/core/src/umath -Inumpy/core/include -Inumpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/usr/include/python2.5 -Inumpy/core/src/multiarray -Inumpy/core/src/umath -c' gcc: numpy/core/src/umath/umathmodule_onefile.c gcc -pthread -shared build/temp.linux-x86_64-2.5/numpy/core/src/umath/umathmodule_onefile.o -L/usr/lib64 -Lbuild/temp.linux-x86_64-2.5 -lnpymath -lm -lpython2.5 -o numpy/core/umath.so building 'numpy.core.scalarmath' extension compiling C sources C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fexceptions -g -fPIC compile options: '-Inumpy/core/include -Inumpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/usr/include/python2.5 -Inumpy/core/src/multiarray -Inumpy/core/src/umath -c' gcc: numpy/core/src/scalarmathmodule.c gcc -pthread -shared build/temp.linux-x86_64-2.5/numpy/core/src/scalarmathmodule.o -L/usr/lib64 -Lbuild/temp.linux-x86_64-2.5 -lm -lpython2.5 -o numpy/core/scalarmath.so building 'numpy.core._dotblas' extension compiling C sources C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fexceptions -g -fPIC creating build/temp.linux-x86_64-2.5/numpy/core/blasdot compile options: '-DATLAS_INFO="\"3.9.25\"" -Inumpy/core/blasdot -I/volatile/varoquau/usr/src/ATLAS/include -Inumpy/core/include -Inumpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/usr/include/python2.5 -Inumpy/core/src/multiarray -Inumpy/core/src/umath -c' gcc: numpy/core/blasdot/_dotblas.c gcc -pthread -shared build/temp.linux-x86_64-2.5/numpy/core/blasdot/_dotblas.o -L/volatile/varoquau/usr/lib/ -L/usr/lib64 -Lbuild/temp.linux-x86_64-2.5 -lptf77blas -lptcblas -latlas -lpython2.5 -o numpy/core/_dotblas.so building 'numpy.core.umath_tests' extension compiling C sources C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fexceptions -g -fPIC compile options: '-Inumpy/core/include -Inumpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/usr/include/python2.5 -Inumpy/core/src/multiarray -Inumpy/core/src/umath -c' gcc: numpy/core/src/umath/umath_tests.c gcc -pthread -shared build/temp.linux-x86_64-2.5/numpy/core/src/umath/umath_tests.o -L/usr/lib64 -Lbuild/temp.linux-x86_64-2.5 -lpython2.5 -o numpy/core/umath_tests.so building 'numpy.core.multiarray_tests' extension compiling C sources C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fexceptions -g -fPIC compile options: '-Inumpy/core/include -Inumpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/usr/include/python2.5 -Inumpy/core/src/multiarray -Inumpy/core/src/umath -c' gcc: numpy/core/src/multiarray/multiarray_tests.c gcc -pthread -shared build/temp.linux-x86_64-2.5/numpy/core/src/multiarray/multiarray_tests.o -L/usr/lib64 -Lbuild/temp.linux-x86_64-2.5 -lpython2.5 -o numpy/core/multiarray_tests.so building 'numpy.lib._compiled_base' extension compiling C sources C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fexceptions -g -fPIC creating build/temp.linux-x86_64-2.5/numpy/lib creating build/temp.linux-x86_64-2.5/numpy/lib/src compile options: '-Inumpy/core/include -Inumpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/usr/include/python2.5 -Inumpy/core/src/multiarray -Inumpy/core/src/umath -c' gcc: numpy/lib/src/_compiled_base.c gcc -pthread -shared build/temp.linux-x86_64-2.5/numpy/lib/src/_compiled_base.o -L/usr/lib64 -Lbuild/temp.linux-x86_64-2.5 -lpython2.5 -o numpy/lib/_compiled_base.so building 'numpy.numarray._capi' extension compiling C sources C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fexceptions -g -fPIC creating build/temp.linux-x86_64-2.5/numpy/numarray compile options: '-Inumpy/core/include -Inumpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/usr/include/python2.5 -Inumpy/core/src/multiarray -Inumpy/core/src/umath -c' gcc: numpy/numarray/_capi.c gcc -pthread -shared build/temp.linux-x86_64-2.5/numpy/numarray/_capi.o -L/usr/lib64 -Lbuild/temp.linux-x86_64-2.5 -lpython2.5 -o numpy/numarray/_capi.so building 'numpy.fft.fftpack_lite' extension compiling C sources C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fexceptions -g -fPIC creating build/temp.linux-x86_64-2.5/numpy/fft compile options: '-Inumpy/core/include -Inumpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/usr/include/python2.5 -Inumpy/core/src/multiarray -Inumpy/core/src/umath -c' gcc: numpy/fft/fftpack_litemodule.c gcc: numpy/fft/fftpack.c gcc -pthread -shared build/temp.linux-x86_64-2.5/numpy/fft/fftpack_litemodule.o build/temp.linux-x86_64-2.5/numpy/fft/fftpack.o -L/usr/lib64 -Lbuild/temp.linux-x86_64-2.5 -lpython2.5 -o numpy/fft/fftpack_lite.so building 'numpy.linalg.lapack_lite' extension compiling C sources C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fexceptions -g -fPIC creating build/temp.linux-x86_64-2.5/numpy/linalg compile options: '-DATLAS_INFO="\"3.9.25\"" -I/volatile/varoquau/usr/src/ATLAS/include -Inumpy/core/include -Inumpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/usr/include/python2.5 -Inumpy/core/src/multiarray -Inumpy/core/src/umath -c' gcc: numpy/linalg/python_xerbla.c gcc: numpy/linalg/lapack_litemodule.c gcc -pthread -shared build/temp.linux-x86_64-2.5/numpy/linalg/lapack_litemodule.o build/temp.linux-x86_64-2.5/numpy/linalg/python_xerbla.o -L/volatile/varoquau/usr/lib/ -L/usr/lib64 -Lbuild/temp.linux-x86_64-2.5 -llapack -lptf77blas -lptcblas -latlas -lpython2.5 -o numpy/linalg/lapack_lite.so building 'numpy.random.mtrand' extension compiling C sources C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fexceptions -g -fPIC creating build/temp.linux-x86_64-2.5/numpy/random creating build/temp.linux-x86_64-2.5/numpy/random/mtrand compile options: '-Inumpy/core/include -Inumpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/usr/include/python2.5 -Inumpy/core/src/multiarray -Inumpy/core/src/umath -c' gcc: numpy/random/mtrand/mtrand.c gcc: numpy/random/mtrand/distributions.c gcc: numpy/random/mtrand/randomkit.c gcc: numpy/random/mtrand/initarray.c gcc -pthread -shared build/temp.linux-x86_64-2.5/numpy/random/mtrand/mtrand.o build/temp.linux-x86_64-2.5/numpy/random/mtrand/randomkit.o build/temp.linux-x86_64-2.5/numpy/random/mtrand/initarray.o build/temp.linux-x86_64-2.5/numpy/random/mtrand/distributions.o -L/usr/lib64 -Lbuild/temp.linux-x86_64-2.5 -lpython2.5 -o numpy/random/mtrand.so running scons From david at silveregg.co.jp Wed Oct 20 03:39:09 2010 From: david at silveregg.co.jp (David) Date: Wed, 20 Oct 2010 16:39:09 +0900 Subject: [Numpy-discussion] Atlas build issues In-Reply-To: <20101020072349.GA10163@phare.normalesup.org> References: <20101020072349.GA10163@phare.normalesup.org> Message-ID: <4CBE9C9D.5050603@silveregg.co.jp> On 10/20/2010 04:23 PM, Gael Varoquaux wrote: > I am really sorry to be landing on the mailing list with Atlas build > issues. I usually manage be myself to build Atlas, but this time I have > been fighting for a couple of days with little success. > > The reason I need to build Atlas is that our work computers are stuck on > Mandriva 2008.0, in which the version of Atlas packaged by the system is > not usable. > > Anyhow, I lost quite a while with Atlas 3.9.26, for which I was never > able to build libaries that could be used in a '.so' (seemed that the > -fPIC was not working, but really I don't understand what was going on in > the maze of makefiles). After that I switched to 3.9;25, which I have > already have gotten working on another system (Mandriva 2008, but 32 > bits). Know everything builds, but I get a missing symbol at the import: > > from numpy.linalg import lapack_lite > ImportError: /volatile/varoquau/dev/numpy/numpy/linalg/lapack_lite.so: > undefined symbol: zgesdd_ The two first things to check in those cases (atlas or not): - ldd /volatile/varoquau/dev/numpy/numpy/linalg/lapack_lite.so: does it load the libraries you think are you loading ? - nm atlas_libraries | grep zgesdd_ for every library in atlas (I don't know how the recent ones work, but this function should normally be in libf77blas.so) The way to get -fPIC everywhere used to be -Fa alg -fPIC during configure, but that may have changed. David From david at silveregg.co.jp Wed Oct 20 03:41:38 2010 From: david at silveregg.co.jp (David) Date: Wed, 20 Oct 2010 16:41:38 +0900 Subject: [Numpy-discussion] Atlas build issues In-Reply-To: <4CBE9C9D.5050603@silveregg.co.jp> References: <20101020072349.GA10163@phare.normalesup.org> <4CBE9C9D.5050603@silveregg.co.jp> Message-ID: <4CBE9D32.7060305@silveregg.co.jp> On 10/20/2010 04:39 PM, David wrote: > On 10/20/2010 04:23 PM, Gael Varoquaux wrote: >> I am really sorry to be landing on the mailing list with Atlas build >> issues. I usually manage be myself to build Atlas, but this time I have >> been fighting for a couple of days with little success. >> >> The reason I need to build Atlas is that our work computers are stuck on >> Mandriva 2008.0, in which the version of Atlas packaged by the system is >> not usable. >> >> Anyhow, I lost quite a while with Atlas 3.9.26, for which I was never >> able to build libaries that could be used in a '.so' (seemed that the >> -fPIC was not working, but really I don't understand what was going on in >> the maze of makefiles). After that I switched to 3.9;25, which I have >> already have gotten working on another system (Mandriva 2008, but 32 >> bits). Know everything builds, but I get a missing symbol at the import: >> >> from numpy.linalg import lapack_lite >> ImportError: /volatile/varoquau/dev/numpy/numpy/linalg/lapack_lite.so: >> undefined symbol: zgesdd_ > > The two first things to check in those cases (atlas or not): > > - ldd /volatile/varoquau/dev/numpy/numpy/linalg/lapack_lite.so: does it > load the libraries you think are you loading ? > - nm atlas_libraries | grep zgesdd_ for every library in atlas (I don't > know how the recent ones work, but this function should normally be in > libf77blas.so) Sorry, it should be in lapack, not the f77 blas wrapper, David From gael.varoquaux at normalesup.org Wed Oct 20 03:43:12 2010 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Wed, 20 Oct 2010 09:43:12 +0200 Subject: [Numpy-discussion] Atlas build issues In-Reply-To: <20101020073825.GE9916@phare.normalesup.org> References: <20101020072349.GA10163@phare.normalesup.org> <4CBE9B20.6000902@cens.ioc.ee> <20101020073825.GE9916@phare.normalesup.org> Message-ID: <20101020074312.GF9916@phare.normalesup.org> On Wed, Oct 20, 2010 at 09:38:25AM +0200, Gael Varoquaux wrote: > Hum, this page is mentionning a '--with-netlib-lapack' swith the the > configre that is not in the INSTALL.txt of my atlas version. OK, that's no longer valid. However, I just realize that atlas now packages the netlib lapack in the source. I am wondering if the switch that I was giving to point to the lapack sources it was not confusing the build process. I am retrying without that switch. Ga?l From matthew.brett at gmail.com Wed Oct 20 04:08:20 2010 From: matthew.brett at gmail.com (Matthew Brett) Date: Wed, 20 Oct 2010 09:08:20 +0100 Subject: [Numpy-discussion] dtype comparison and hashing - bug? Message-ID: Hi, I have just run into this oddness: In [28]: dt1 = np.dtype('f4') In [29]: dt1.str Out[29]: ' References: Message-ID: On Wed, Oct 20, 2010 at 5:08 PM, Matthew Brett wrote: > Hi, > > I have just run into this oddness: > > In [28]: dt1 = np.dtype('f4') > > In [29]: dt1.str > Out[29]: ' > In [30]: dt2 = dt1.newbyteorder('<') > > In [31]: dt2.str > Out[31]: ' > In [32]: dt1 == dt2 > Out[32]: True > > In [33]: hash(dt1) == hash(dt2) > Out[33]: False > > This is the same as: > > http://www.mail-archive.com/numpy-discussion at scipy.org/msg13299.html > > My question was - does the team still agree this is a bug? This should have been fixed when I implemented the hashing protocol for dtypes. This is a bug in the hashing protocol implementation, most likely caused by "=" and "<" being considered different by the hashing function. I will try to take a look at it (the function to fix is _array_descr_builtin in hashdesc.c if you feel like doing some C right now :) ). cheers, David From gael.varoquaux at normalesup.org Wed Oct 20 04:45:59 2010 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Wed, 20 Oct 2010 10:45:59 +0200 Subject: [Numpy-discussion] Atlas build issues In-Reply-To: <20101020074312.GF9916@phare.normalesup.org> References: <20101020072349.GA10163@phare.normalesup.org> <4CBE9B20.6000902@cens.ioc.ee> <20101020073825.GE9916@phare.normalesup.org> <20101020074312.GF9916@phare.normalesup.org> Message-ID: <20101020084559.GH9916@phare.normalesup.org> On Wed, Oct 20, 2010 at 09:43:12AM +0200, Gael Varoquaux wrote: > On Wed, Oct 20, 2010 at 09:38:25AM +0200, Gael Varoquaux wrote: > > Hum, this page is mentionning a '--with-netlib-lapack' swith the the > > configre that is not in the INSTALL.txt of my atlas version. > OK, that's no longer valid. > However, I just realize that atlas now packages the netlib lapack in the > source. I am wondering if the switch that I was giving to point to the > lapack sources it was not confusing the build process. I am retrying > without that switch. No progress. Same problem. From gael.varoquaux at normalesup.org Wed Oct 20 04:48:01 2010 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Wed, 20 Oct 2010 10:48:01 +0200 Subject: [Numpy-discussion] Atlas build issues In-Reply-To: <4CBE9D32.7060305@silveregg.co.jp> References: <20101020072349.GA10163@phare.normalesup.org> <4CBE9C9D.5050603@silveregg.co.jp> <4CBE9D32.7060305@silveregg.co.jp> Message-ID: <20101020084801.GI9916@phare.normalesup.org> On Wed, Oct 20, 2010 at 04:41:38PM +0900, David wrote: > > - ldd /volatile/varoquau/dev/numpy/numpy/linalg/lapack_lite.so: does it > > load the libraries you think are you loading ? For the dynamic libraries, it seems so. I am using static libraries for atlas/blas (.a) > > - nm atlas_libraries | grep zgesdd_ for every library in atlas (I don't > > know how the recent ones work, but this function should normally be in > > libf77blas.so) Nothing. That's clearly my problem, but I don't know how to fix it. Thanks for your suggestions, G From pearu.peterson at gmail.com Wed Oct 20 04:59:24 2010 From: pearu.peterson at gmail.com (Pearu Peterson) Date: Wed, 20 Oct 2010 11:59:24 +0300 Subject: [Numpy-discussion] Atlas build issues In-Reply-To: <20101020084801.GI9916@phare.normalesup.org> References: <20101020072349.GA10163@phare.normalesup.org> <4CBE9C9D.5050603@silveregg.co.jp> <4CBE9D32.7060305@silveregg.co.jp> <20101020084801.GI9916@phare.normalesup.org> Message-ID: <4CBEAF6C.4040301@cens.ioc.ee> On 10/20/2010 11:48 AM, Gael Varoquaux wrote: > On Wed, Oct 20, 2010 at 04:41:38PM +0900, David wrote: >>> - ldd /volatile/varoquau/dev/numpy/numpy/linalg/lapack_lite.so: does it >>> load the libraries you think are you loading ? > > For the dynamic libraries, it seems so. I am using static libraries for > atlas/blas (.a) > >>> - nm atlas_libraries | grep zgesdd_ for every library in atlas (I don't >>> know how the recent ones work, but this function should normally be in >>> libf77blas.so) Hmm, zgesdd.f is part of LAPACK, why the function should be in BLAS library.. > > Nothing. That's clearly my problem, but I don't know how to fix it. > > Thanks for your suggestions, I haven't build atlas libraries for awhile and may be something is changed in atlas.. That said, I would try instructions from http://www.scipy.org/Installing_SciPy/Linux#head-89e1f6afaa3314d98a22c79b063cceee2cc6313c and may be using some older atlas version. Pearu From gael.varoquaux at normalesup.org Wed Oct 20 05:01:57 2010 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Wed, 20 Oct 2010 11:01:57 +0200 Subject: [Numpy-discussion] Atlas build issues In-Reply-To: <4CBEAF6C.4040301@cens.ioc.ee> References: <20101020072349.GA10163@phare.normalesup.org> <4CBE9C9D.5050603@silveregg.co.jp> <4CBE9D32.7060305@silveregg.co.jp> <20101020084801.GI9916@phare.normalesup.org> <4CBEAF6C.4040301@cens.ioc.ee> Message-ID: <20101020090157.GK9916@phare.normalesup.org> On Wed, Oct 20, 2010 at 11:59:24AM +0300, Pearu Peterson wrote: > I haven't build atlas libraries for awhile and may be something > is changed in atlas.. That said, I would try instructions from > http://www.scipy.org/Installing_SciPy/Linux#head-89e1f6afaa3314d98a22c79b063cceee2cc6313c That was my first try > and may be using some older atlas version. I can do it with older versions, but I get a segfault in an SVD that I really need to do. This is actually what started the current endeaviour. Maybe I should bisect to try and find a version where the SVD does not segfault, and that I can build and link. That seems like a lot of work. :( Ga?l From pav at iki.fi Wed Oct 20 05:04:11 2010 From: pav at iki.fi (Pauli Virtanen) Date: Wed, 20 Oct 2010 09:04:11 +0000 (UTC) Subject: [Numpy-discussion] dtype comparison and hashing - bug? References: Message-ID: Wed, 20 Oct 2010 17:46:06 +0900, David Cournapeau wrote: [clip] > This should have been fixed when I implemented the hashing protocol for > dtypes. This is a bug in the hashing protocol implementation, most > likely caused by "=" and "<" being considered different by the hashing > function. I will try to take a look at it (the function to fix is > _array_descr_builtin in hashdesc.c if you feel like doing some C right > now :) ). It already has a ticket :) http://projects.scipy.org/numpy/ticket/1637 But I haven't yet felt the urge to fix it. Pauli From matthew.brett at gmail.com Wed Oct 20 06:02:28 2010 From: matthew.brett at gmail.com (Matthew Brett) Date: Wed, 20 Oct 2010 11:02:28 +0100 Subject: [Numpy-discussion] dtype comparison and hashing - bug? In-Reply-To: References: Message-ID: Hi, > It already has a ticket :) > > ? ?http://projects.scipy.org/numpy/ticket/1637 Oops - sorry - thanks for point that out. Cheers, Matthew From friedrichromstedt at gmail.com Wed Oct 20 06:12:42 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Wed, 20 Oct 2010 12:12:42 +0200 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: 2010/10/20 Charles R Harris : > [...] I think we do need a > .gitconfig file [...] .gitattributes > so why don't you go ahead and make one and > deal with the nsi.in file in the process. http://github.com/friedrichromstedt/numpy/tree/friedrich-gitattributes-nsis > The .svg files can have their line > endings converted to line feeds Is there anything I've missed or am I right with that currently there is *no* policy for other files at all how they are checked-in/checked-out. We could setup .gitattributes to include also .py files to be LF only by ``eol=lf`` in .gitattributes for ``*.py``, etc. Currently I think it works because git does not change to system strategy by default. But I have a dim memory about git checking in with LF by default too, I need some pointer here I guess. IIRC git checks in with LF but does not change on check-out? Due to Darren's config file the .nsi.in file made it with CRLF into the repo. I guess .gitattributes has precedence over ~/.gitconfig. Pros of *.py in .gitattributes: * We are independent by overriding the user's global config. All *.py files will be checked in with LF. Cons: * They'll also be checked-out with LF, wich may be annoying esp. for Windows users. Is there any way to force check-in LF *only*, via .gitattributes? > [...] which will give us two less files to worry > about. I'm not quite sure, by analogy to .ps, where I messed up my ps files by converting their line ends. No tool was able to read them any longer, seems like being included in the ps specs, maybe the same holds for svg? Not all software has universal eol support. (This was on Windows) Darren, your specs used by you are working due to backward-compatibiltiy of git, see http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html. ``eol=...`` is according to that doc preferrable. Maybe I'll add ``*.dmg -text`` to prevent normalisation of the dmgs I'd like to connect with the numpy commits in my repo. I'll send discussion of this in another thread later. Since it's not approved so far I do not add right now. So far, Friedrich From dsdale24 at gmail.com Wed Oct 20 07:54:22 2010 From: dsdale24 at gmail.com (Darren Dale) Date: Wed, 20 Oct 2010 07:54:22 -0400 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: On Wed, Oct 20, 2010 at 6:12 AM, Friedrich Romstedt wrote: > Due to Darren's config file the .nsi.in file made it with CRLF into the repo. Uh, no. From goodfellow.ian at gmail.com Wed Oct 20 09:13:24 2010 From: goodfellow.ian at gmail.com (Ian Goodfellow) Date: Wed, 20 Oct 2010 09:13:24 -0400 Subject: [Numpy-discussion] Atlas build issues In-Reply-To: <20101020090157.GK9916@phare.normalesup.org> References: <20101020072349.GA10163@phare.normalesup.org> <4CBE9C9D.5050603@silveregg.co.jp> <4CBE9D32.7060305@silveregg.co.jp> <20101020084801.GI9916@phare.normalesup.org> <4CBEAF6C.4040301@cens.ioc.ee> <20101020090157.GK9916@phare.normalesup.org> Message-ID: --with-netlib-lapack is indeed no longer valid. INSTALL.txt includes a warning that INSTALL.txt is out of date, you should refer to doc/atlas_install.pdf instead. The new option is --with-netlib-lapack-tarfile I successfully built 3.9.25 with this option a while ago, but haven't been able to get numpy to use it. On Wed, Oct 20, 2010 at 5:01 AM, Gael Varoquaux < gael.varoquaux at normalesup.org> wrote: > On Wed, Oct 20, 2010 at 11:59:24AM +0300, Pearu Peterson wrote: > > I haven't build atlas libraries for awhile and may be something > > is changed in atlas.. That said, I would try instructions from > > > > http://www.scipy.org/Installing_SciPy/Linux#head-89e1f6afaa3314d98a22c79b063cceee2cc6313c > > That was my first try > > > and may be using some older atlas version. > > I can do it with older versions, but I get a segfault in an SVD that I > really need to do. This is actually what started the current endeaviour. > > Maybe I should bisect to try and find a version where the SVD does not > segfault, and that I can build and link. That seems like a lot of work. > > :( > > Ga?l > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gael.varoquaux at normalesup.org Wed Oct 20 09:29:20 2010 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Wed, 20 Oct 2010 15:29:20 +0200 Subject: [Numpy-discussion] Atlas build issues In-Reply-To: References: <20101020072349.GA10163@phare.normalesup.org> <4CBE9C9D.5050603@silveregg.co.jp> <4CBE9D32.7060305@silveregg.co.jp> <20101020084801.GI9916@phare.normalesup.org> <4CBEAF6C.4040301@cens.ioc.ee> <20101020090157.GK9916@phare.normalesup.org> Message-ID: <20101020132920.GB4624@phare.normalesup.org> On Wed, Oct 20, 2010 at 09:13:24AM -0400, Ian Goodfellow wrote: > --with-netlib-lapack is indeed no longer valid. > INSTALL.txt includes a warning that INSTALL.txt is out of date, you should > refer to doc/atlas_install.pdf instead. Ah, I read too quickly and missed that. Thanks. > The new option is --with-netlib-lapack-tarfile > I successfully built 3.9.25 with this option a while ago, but haven't been > able to get numpy to use it. Do you remember what the issue was? Ga?l From tkg at lanl.gov Wed Oct 20 09:42:11 2010 From: tkg at lanl.gov (Thomas Kirk Gamble) Date: Wed, 20 Oct 2010 07:42:11 -0600 Subject: [Numpy-discussion] function name as parameter Message-ID: <1287582131.8906.12.camel@koolasuchus.lanl.gov> I'm trying to write an implementation of the amoeba function from numerical recipes and need to be able to pass a function name and parameter list to be called from within the amoeba function. Simply passing the name as a string doesn't work since python doesn't know it is a function and throws a typeerror. Is there something similar to IDL's 'call_function' routine in python/numpy or a pythonic/numpy means of passing function names? -- Thomas K. Gamble Research Technologist, System/Network Administrator Chemical Diagnostics and Engineering (C-CDE) Los Alamos National Laboratory MS-E543,p:505-665-4323 f:505-665-4267 There cannot be a crisis next week. My schedule is already full. Henry Kissinger From zachary.pincus at yale.edu Wed Oct 20 09:46:26 2010 From: zachary.pincus at yale.edu (Zachary Pincus) Date: Wed, 20 Oct 2010 09:46:26 -0400 Subject: [Numpy-discussion] function name as parameter In-Reply-To: <1287582131.8906.12.camel@koolasuchus.lanl.gov> References: <1287582131.8906.12.camel@koolasuchus.lanl.gov> Message-ID: <80A9C72D-3080-4902-A1EC-75DCFA4EE683@yale.edu> > I'm trying to write an implementation of the amoeba function from > numerical recipes and need to be able to pass a function name and > parameter list to be called from within the amoeba function. Simply > passing the name as a string doesn't work since python doesn't know it > is a function and throws a typeerror. Is there something similar to > IDL's 'call_function' routine in python/numpy or a pythonic/numpy > means > of passing function names? Just pass the function itself! For example: def foo(): print 6 def call_function_repeatedly(func, count): for i in range(count): func() call_function_repeatedly(foo, 2) # calls foo twice bar = foo bar() # still calls foo... we've just assigned the function to a different name In python, functions (and classes, and everything else) are first- class objects and can be assigned to variables, passed around, etc, etc, just as anything else. However, note that scipy.optimize.fmin implements the Nelder-Mead simplex algorithm, which is (I think) the same as the "amoeba" optimizer. Also you might be interested in the openopt package, which implements more optimizers a bit more consistently than scipy.optimize. Zach From cohen at lpta.in2p3.fr Wed Oct 20 09:51:35 2010 From: cohen at lpta.in2p3.fr (Johann Cohen-Tanugi) Date: Wed, 20 Oct 2010 15:51:35 +0200 Subject: [Numpy-discussion] function name as parameter In-Reply-To: <80A9C72D-3080-4902-A1EC-75DCFA4EE683@yale.edu> References: <1287582131.8906.12.camel@koolasuchus.lanl.gov> <80A9C72D-3080-4902-A1EC-75DCFA4EE683@yale.edu> Message-ID: <4CBEF3E7.1060401@lpta.in2p3.fr> If you really need to pass the function name : In [3]: def my_func(x): ...: return 2*x In [4]: def caller(fname,x): ...: return eval("%s(%f)"%(fname,x)) In [5]: caller("my_func",2) Out[5]: 4.0 On 10/20/2010 03:46 PM, Zachary Pincus wrote: >> I'm trying to write an implementation of the amoeba function from >> numerical recipes and need to be able to pass a function name and >> parameter list to be called from within the amoeba function. Simply >> passing the name as a string doesn't work since python doesn't know it >> is a function and throws a typeerror. Is there something similar to >> IDL's 'call_function' routine in python/numpy or a pythonic/numpy >> means >> of passing function names? >> > Just pass the function itself! For example: > > def foo(): > print 6 > > def call_function_repeatedly(func, count): > for i in range(count): > func() > > call_function_repeatedly(foo, 2) # calls foo twice > > bar = foo > bar() # still calls foo... we've just assigned the function to a > different name > > > In python, functions (and classes, and everything else) are first- > class objects and can be assigned to variables, passed around, etc, > etc, just as anything else. > > However, note that scipy.optimize.fmin implements the Nelder-Mead > simplex algorithm, which is (I think) the same as the "amoeba" > optimizer. Also you might be interested in the openopt package, which > implements more optimizers a bit more consistently than scipy.optimize. > > Zach > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > From josef.pktd at gmail.com Wed Oct 20 09:51:09 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Wed, 20 Oct 2010 09:51:09 -0400 Subject: [Numpy-discussion] function name as parameter In-Reply-To: <80A9C72D-3080-4902-A1EC-75DCFA4EE683@yale.edu> References: <1287582131.8906.12.camel@koolasuchus.lanl.gov> <80A9C72D-3080-4902-A1EC-75DCFA4EE683@yale.edu> Message-ID: On Wed, Oct 20, 2010 at 9:46 AM, Zachary Pincus wrote: >> I'm trying to write an implementation of the amoeba function from >> numerical recipes and need to be able to pass a function name and >> parameter list to be called from within the amoeba function. ?Simply >> passing the name as a string doesn't work since python doesn't know it >> is a function and throws a typeerror. ?Is there something similar to >> IDL's 'call_function' routine in python/numpy or a pythonic/numpy >> means >> of passing function names? > > Just pass the function itself! For example: > > def foo(): > ? print 6 > > def call_function_repeatedly(func, count): > ? for i in range(count): > ? ? func() > > call_function_repeatedly(foo, 2) # calls foo twice > > bar = foo > bar() # still calls foo... we've just assigned the function to a > different name > > > In python, functions (and classes, and everything else) are first- > class objects and can be assigned to variables, passed around, etc, > etc, just as anything else. This is the best way, but if you want to pass the function name as string, then you need to get the function with getattr for example, scipy has code like this def func(distname, args): distfn = getattr(scipy.stats, distname) distfn.rvs(args) func('norm') Josef > > However, note that scipy.optimize.fmin implements the Nelder-Mead > simplex algorithm, which is (I think) the same as the "amoeba" > optimizer. Also you might be interested in the openopt package, which > implements more optimizers a bit more consistently than scipy.optimize. > > Zach > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > From goodfellow.ian at gmail.com Wed Oct 20 11:21:07 2010 From: goodfellow.ian at gmail.com (Ian Goodfellow) Date: Wed, 20 Oct 2010 11:21:07 -0400 Subject: [Numpy-discussion] Atlas build issues In-Reply-To: <20101020132920.GB4624@phare.normalesup.org> References: <20101020072349.GA10163@phare.normalesup.org> <4CBE9C9D.5050603@silveregg.co.jp> <4CBE9D32.7060305@silveregg.co.jp> <20101020084801.GI9916@phare.normalesup.org> <4CBEAF6C.4040301@cens.ioc.ee> <20101020090157.GK9916@phare.normalesup.org> <20101020132920.GB4624@phare.normalesup.org> Message-ID: There were two problems. First, numpy ignored my export ATLAS=/usr/local/atlas. setup.py printed out the directories it was searching and it just searched the defaults then said it couldn't find ATLAS. I 'fixed' that problem by adding symlinks in the default directories. Now I get error messages like these in the output of setup.py: C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/usr/include/python2.6 -c' gcc: _configtest.c _configtest.c:1: warning: conflicting types for built-in function ?exp? gcc -pthread _configtest.o -o _configtest _configtest.o: In function `main': /home/ia3n/Libraries/numpy/_configtest.c:6: undefined reference to `exp' collect2: ld returned 1 exit status _configtest.o: In function `main': /home/ia3n/Libraries/numpy/_configtest.c:6: undefined reference to `exp' collect2: ld returned 1 exit status failure. On Wed, Oct 20, 2010 at 9:29 AM, Gael Varoquaux < gael.varoquaux at normalesup.org> wrote: > On Wed, Oct 20, 2010 at 09:13:24AM -0400, Ian Goodfellow wrote: > > --with-netlib-lapack is indeed no longer valid. > > INSTALL.txt includes a warning that INSTALL.txt is out of date, you > should > > refer to doc/atlas_install.pdf instead. > > Ah, I read too quickly and missed that. Thanks. > > > The new option is --with-netlib-lapack-tarfile > > I successfully built 3.9.25 with this option a while ago, but haven't > been > > able to get numpy to use it. > > Do you remember what the issue was? > > Ga?l > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From friedrichromstedt at gmail.com Wed Oct 20 11:56:13 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Wed, 20 Oct 2010 17:56:13 +0200 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: 2010/10/20 Darren Dale : > On Wed, Oct 20, 2010 at 6:12 AM, Friedrich Romstedt > wrote: >> Due to Darren's config file the .nsi.in file made it with CRLF into the repo. > > Uh, no. You mean I'm wrong? Wait, I'll check, but ...Hmm, how do I check the line endings? `file` told it for the .nsi.in file, but not for the .py ones. I was starting from the assumtion that Mac OS X native form is LF, or even CR, but not CRLF, which is Windows? Sorry if I wasn't diligent enough or too sure. Friedrich From tkg at lanl.gov Wed Oct 20 11:59:31 2010 From: tkg at lanl.gov (Thomas Kirk Gamble) Date: Wed, 20 Oct 2010 09:59:31 -0600 Subject: [Numpy-discussion] function name as parameter In-Reply-To: <80A9C72D-3080-4902-A1EC-75DCFA4EE683@yale.edu> References: <1287582131.8906.12.camel@koolasuchus.lanl.gov> <80A9C72D-3080-4902-A1EC-75DCFA4EE683@yale.edu> Message-ID: <1287590371.8906.19.camel@koolasuchus.lanl.gov> On Wed, 2010-10-20 at 09:46 -0400, Zachary Pincus wrote: > > I'm trying to write an implementation of the amoeba function from > > numerical recipes and need to be able to pass a function name and > > parameter list to be called from within the amoeba function. Simply > > passing the name as a string doesn't work since python doesn't know it > > is a function and throws a typeerror. Is there something similar to > > IDL's 'call_function' routine in python/numpy or a pythonic/numpy > > means > > of passing function names? > > Just pass the function itself! For example: > > def foo(): > print 6 > > def call_function_repeatedly(func, count): > for i in range(count): > func() > > call_function_repeatedly(foo, 2) # calls foo twice > > bar = foo > bar() # still calls foo... we've just assigned the function to a > different name > This works fine. Too obvious to see, I guess. > > In python, functions (and classes, and everything else) are first- > class objects and can be assigned to variables, passed around, etc, > etc, just as anything else. > > However, note that scipy.optimize.fmin implements the Nelder-Mead > simplex algorithm, which is (I think) the same as the "amoeba" > optimizer. Also you might be interested in the openopt package, which > implements more optimizers a bit more consistently than scipy.optimize. I try this and compare performance. I had looked for an 'amoeba' function, but couldn't find anything by that name. I should have broadened my search a bit. ;-) > > Zach > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion -- Thomas K. Gamble Research Technologist, System/Network Administrator Chemical Diagnostics and Engineering (C-CDE) Los Alamos National Laboratory MS-E543,p:505-665-4323 f:505-665-4267 There cannot be a crisis next week. My schedule is already full. Henry Kissinger From charlesr.harris at gmail.com Wed Oct 20 13:01:37 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Wed, 20 Oct 2010 11:01:37 -0600 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: On Wed, Oct 20, 2010 at 9:56 AM, Friedrich Romstedt < friedrichromstedt at gmail.com> wrote: > 2010/10/20 Darren Dale : > > On Wed, Oct 20, 2010 at 6:12 AM, Friedrich Romstedt > > wrote: > >> Due to Darren's config file the .nsi.in file made it with CRLF into the > repo. > > > > Uh, no. > > You mean I'm wrong? Wait, I'll check, but ...Hmm, how do I check the > line endings? `file` told it for the .nsi.in file, but not for the > .py ones. I was starting from the assumtion that Mac OS X native form > is LF, or even CR, but not CRLF, which is Windows? > > Sorry if I wasn't diligent enough or too sure. > > You can grep for CR: grep -P '\r' foo . On windows and mac you might need to add -U. For vim ":set list" will show the line endings. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From faltet at pytables.org Wed Oct 20 13:03:19 2010 From: faltet at pytables.org (Francesc Alted) Date: Wed, 20 Oct 2010 19:03:19 +0200 Subject: [Numpy-discussion] ANN: NUmexpr 1.4.1 released Message-ID: <201010201903.19193.faltet@pytables.org> ========================== Announcing Numexpr 1.4.1 ========================== Numexpr is a fast numerical expression evaluator for NumPy. With it, expressions that operate on arrays (like "3*a+4*b") are accelerated and use less memory than doing the same calculation in Python. What's new ========== This is a maintenance release. On it, several improvements have been done in order to prevent deadlocks in new threaded code (fixes #33). Also the GIL is released now during computations, which should be interesting for embedding numexpr in threaded Python apps. In case you want to know more in detail what has changed in this version, see: http://code.google.com/p/numexpr/wiki/ReleaseNotes or have a look at RELEASE_NOTES.txt in the tarball. Where I can find Numexpr? ========================= The project is hosted at Google code in: http://code.google.com/p/numexpr/ And you can get the packages from PyPI as well: http://pypi.python.org/pypi Share your experience ===================== Let us know of any bugs, suggestions, gripes, kudos, etc. you may have. Enjoy! -- Francesc Alted From alan.isaac at gmail.com Wed Oct 20 13:18:17 2010 From: alan.isaac at gmail.com (Alan G Isaac) Date: Wed, 20 Oct 2010 13:18:17 -0400 Subject: [Numpy-discussion] function name as parameter In-Reply-To: <1287582131.8906.12.camel@koolasuchus.lanl.gov> References: <1287582131.8906.12.camel@koolasuchus.lanl.gov> Message-ID: <4CBF2459.1080107@gmail.com> On 10/20/2010 9:42 AM, Thomas Kirk Gamble wrote: > I'm trying to write an implementation of the amoeba function from > numerical recipes and need to be able to pass a function name and > parameter list to be called from within the amoeba function. 1. Have you checked whether this might already be in OpenOpt? 2. Here is a GAUSS version, that might (?) be easier to follow. http://www1.american.edu/academic.depts/cas/econ/gaussres/optimize/honore.src Alan Isaac From nwagner at iam.uni-stuttgart.de Wed Oct 20 13:21:15 2010 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Wed, 20 Oct 2010 19:21:15 +0200 Subject: [Numpy-discussion] numpy.test() segfaults '2.0.0.dev8716' Message-ID: test_duplicate_field_names_assign (test_regression.TestRegression) ... ........FF............ Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7b3077a in ?? () from /usr/lib64/libpython2.6.so.1.0 (gdb) bt #0 0x00007ffff7b3077a in ?? () from /usr/lib64/libpython2.6.so.1.0 #1 0x00007ffff7b2ea3f in _PyArg_ParseTuple_SizeT () from /usr/lib64/libpython2.6.so.1.0 #2 0x00007ffff62ce02e in VOID_getitem (ip=0x1583150 "", ap=0x175f160) at numpy/core/src/multiarray/arraytypes.c.src:565 #3 0x00007ffff62e64eb in array_toscalar (self=0x175f160, args=) at numpy/core/src/multiarray/methods.c:554 #4 0x00007ffff7b2165c in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0 #5 0x00007ffff7b26251 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.6.so.1.0 #6 0x00007ffff7b2103d in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0 #7 0x00007ffff7b26431 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.6.so.1.0 #8 0x00007ffff7af3db2 in ?? () from /usr/lib64/libpython2.6.so.1.0 #9 0x00007ffff7ae7cb2 in PyObject_Call () from /usr/lib64/libpython2.6.so.1.0 #10 0x00007ffff7b1fd26 in PyEval_CallObjectWithKeywords () from /usr/lib64/libpython2.6.so.1.0 #11 0x00007ffff62c2184 in array_str (self=) at numpy/core/src/multiarray/arrayobject.c:393 #12 0x00007ffff7b002e8 in _PyObject_Str () from /usr/lib64/libpython2.6.so.1.0 #13 0x00007ffff7b003ea in PyObject_Str () from /usr/lib64/libpython2.6.so.1.0 ---Type to continue, or q to quit---q Quit From mtrumpis at berkeley.edu Wed Oct 20 13:29:43 2010 From: mtrumpis at berkeley.edu (M Trumpis) Date: Wed, 20 Oct 2010 13:29:43 -0400 Subject: [Numpy-discussion] datarray lightning talk at NYC Python group In-Reply-To: References: Message-ID: On Mon, Oct 18, 2010 at 5:18 PM, Fernando Perez wrote: > On Mon, Oct 18, 2010 at 11:21 AM, M Trumpis wrote: >> Just a heads up that I'm going to do a quick pitch for datarray this >> Wed. at the NYC Python Meetup thing. >> >> If any collaborator is attending, please introduce yourself! >> > > Well, Travis will be there speaking, if my Enthought newsletter is correct :) > > It would be great if you can collect feedback and have a chance to > discuss things with Travis in-person (we tried on Friday here but ran > out of time). ?If you can post a summary of any ideas that come out of > that, it would be greatly appreciated. > > Best of luck with the talk! > > Cheers, > > f > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > We will see.. There are 5 lightning talk slots, and they filled up fast. I'm 1st in line if there's a no-show. If there ends up being any discussion I'll make remarks either on github or on this list. Mike From dsdale24 at gmail.com Wed Oct 20 13:29:57 2010 From: dsdale24 at gmail.com (Darren Dale) Date: Wed, 20 Oct 2010 13:29:57 -0400 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: On Wed, Oct 20, 2010 at 11:56 AM, Friedrich Romstedt wrote: > 2010/10/20 Darren Dale : >> On Wed, Oct 20, 2010 at 6:12 AM, Friedrich Romstedt >> wrote: >>> Due to Darren's config file the .nsi.in file made it with CRLF into the repo. >> >> Uh, no. > > You mean I'm wrong? Due to my config file... nothing. I simply noticed the already-existing CRLF line endings in the repository. From friedrichromstedt at gmail.com Wed Oct 20 15:12:51 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Wed, 20 Oct 2010 21:12:51 +0200 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: .nsi.in has '$\n\r' Is this now LFCR or CRLF? doall.py and py3tool.py have '$\n' precisely. I'm on Mac. \n is the at least vim-default on Mac. So yes, confirming that it's already in the repo. What about the svg eols? Do we need my branch now, or do we want to leave it alone? When others change the file, it might get converted, when we do not apply my commit, assumed that they have some personal preference about eols. For the standard user he will not notice the difference. Someone else than me has to think through it for approval. (I thought thru and say it's okay.) "When deciding what attributes are assigned to a path, git consults $GIT_DIR/info/attributes file (which has the highest precedence), .gitattributes file in the same directory as the path in question, and its parent directories up to the toplevel of the work tree (the further the directory that contains .gitattributes is from the path in question, the lower its precedence). Finally global and system-wide files are considered (they have the lowest precedence)." I tried to put it in the same dir but it didn't work for me. Maybe my git is ageing. Used $grep -PU '$\r' and similar; '$\r^' does not work, just for completeness. The section "End-of-line conversion" in http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html is quite clear. Considering this section I come to the conclusion to leave it to the user how he/she checks in/out the files, but we define for files with defined gitattributes the attributes in .gitattributes. (Alternative to .gitattributes: $GIT_DIR/info/attributes, I don't know if this goes into the repo too). People are advised then to not attribute files to themselves by just an eol conversion. Opinions, Comments? I know, this topic is unattractive. http://www.astro.gla.ac.uk/users/labrosse/PORTFOLIO/images/cosmicsexinessladder.png (from http://www.astro.gla.ac.uk/users/labrosse/PORTFOLIO/philo.html) This is somewhere at the other end of the world :-) Friedrich 2010/10/20 Charles R Harris : > On Wed, Oct 20, 2010 at 9:56 AM, Friedrich Romstedt > wrote: >> 2010/10/20 Darren Dale : >> > On Wed, Oct 20, 2010 at 6:12 AM, Friedrich Romstedt >> > wrote: >> >> Due to Darren's config file the .nsi.in file made it with CRLF into the >> >> repo. >> > >> > Uh, no. >> >> You mean I'm wrong? ?Wait, I'll check, but ...Hmm, how do I check the >> line endings? ?`file` told it for the .nsi.in file, but not for the >> .py ones. ?I was starting from the assumtion that Mac OS X native form >> is LF, or even CR, but not CRLF, which is Windows? >> >> Sorry if I wasn't diligent enough or too sure. >> > > You can grep for CR: grep -P '\r' foo . On windows and mac you might need to > add -U. For vim ":set list" will show the line endings. From tkg at lanl.gov Wed Oct 20 15:30:36 2010 From: tkg at lanl.gov (Thomas Kirk Gamble) Date: Wed, 20 Oct 2010 13:30:36 -0600 Subject: [Numpy-discussion] function name as parameter In-Reply-To: <4CBF2459.1080107@gmail.com> References: <1287582131.8906.12.camel@koolasuchus.lanl.gov> <4CBF2459.1080107@gmail.com> Message-ID: <1287603036.8906.25.camel@koolasuchus.lanl.gov> On Wed, 2010-10-20 at 13:18 -0400, Alan G Isaac wrote: > On 10/20/2010 9:42 AM, Thomas Kirk Gamble wrote: > > I'm trying to write an implementation of the amoeba function from > > numerical recipes and need to be able to pass a function name and > > parameter list to be called from within the amoeba function. > > 1. Have you checked whether this might already be in OpenOpt? > 2. Here is a GAUSS version, that might (?) be easier to follow. > http://www1.american.edu/academic.depts/cas/econ/gaussres/optimize/honore.src Yes, Zachary already pointed out a version in the scipy.optimize module. Thanks anyway for the reference. I tend to prefer evaluating multiple options rather than just taking the first one that seems to work. > > Alan Isaac > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion -- Thomas K. Gamble Research Technologist, System/Network Administrator Chemical Diagnostics and Engineering (C-CDE) Los Alamos National Laboratory MS-E543,p:505-665-4323 f:505-665-4267 There cannot be a crisis next week. My schedule is already full. Henry Kissinger From njs at pobox.com Wed Oct 20 16:35:49 2010 From: njs at pobox.com (Nathaniel Smith) Date: Wed, 20 Oct 2010 13:35:49 -0700 Subject: [Numpy-discussion] function name as parameter In-Reply-To: <4CBEF3E7.1060401@lpta.in2p3.fr> References: <1287582131.8906.12.camel@koolasuchus.lanl.gov> <80A9C72D-3080-4902-A1EC-75DCFA4EE683@yale.edu> <4CBEF3E7.1060401@lpta.in2p3.fr> Message-ID: On Wed, Oct 20, 2010 at 6:51 AM, Johann Cohen-Tanugi wrote: > If you really need to pass the function name : > In [3]: def my_func(x): > ? ?...: ? ? return 2*x > > In [4]: def caller(fname,x): > ? ?...: ? ? return eval("%s(%f)"%(fname,x)) > > In [5]: caller("my_func",2) > Out[5]: 4.0 The better way to do this is: import inspect def call_this(fname, x): caller_frame = inspect.currentframe().f_back f = caller_frame.f_locals.get(fname, caller_frame.f_globals.get(fname)) return f(x) IMPORTANT USAGE NOTE: never do this :-) -- Nathaniel From cohen at lpta.in2p3.fr Wed Oct 20 16:58:25 2010 From: cohen at lpta.in2p3.fr (Johann Cohen-Tanugi) Date: Wed, 20 Oct 2010 22:58:25 +0200 Subject: [Numpy-discussion] function name as parameter In-Reply-To: References: <1287582131.8906.12.camel@koolasuchus.lanl.gov> <80A9C72D-3080-4902-A1EC-75DCFA4EE683@yale.edu> <4CBEF3E7.1060401@lpta.in2p3.fr> Message-ID: <4CBF57F1.2000707@lpta.in2p3.fr> On 10/20/2010 10:35 PM, Nathaniel Smith wrote: > On Wed, Oct 20, 2010 at 6:51 AM, Johann Cohen-Tanugi > wrote: > >> If you really need to pass the function name : >> In [3]: def my_func(x): >> ...: return 2*x >> >> In [4]: def caller(fname,x): >> ...: return eval("%s(%f)"%(fname,x)) >> >> In [5]: caller("my_func",2) >> Out[5]: 4.0 >> > The better way to do this is: > > import inspect > def call_this(fname, x): > caller_frame = inspect.currentframe().f_back > f = caller_frame.f_locals.get(fname, caller_frame.f_globals.get(fname)) > return f(x) > > thanks for this probably safer way to do this (I guess safer, as I know nothing about inspect module, but can imagine the value of being explicit as to frames and namespaces) > IMPORTANT USAGE NOTE: never do this :-) > What would you recommand? I do encounter situations where I need instantiation based on the name of the thing to instantiate, typically passed as an argument by the client code/user..... thanks in advance, Johann > -- Nathaniel > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > From pav at iki.fi Wed Oct 20 17:09:59 2010 From: pav at iki.fi (Pauli Virtanen) Date: Wed, 20 Oct 2010 21:09:59 +0000 (UTC) Subject: [Numpy-discussion] numpy.test() segfaults '2.0.0.dev8716' References: Message-ID: Wed, 20 Oct 2010 19:21:15 +0200, Nils Wagner wrote: > test_duplicate_field_names_assign > (test_regression.TestRegression) ... Works for me. This is exactly the crash that the test tests, so perhaps you have an incomplete rebuild. I'd try "rm -rf build" and rebuild. -- Pauli Virtanen From robert.kern at gmail.com Wed Oct 20 17:10:46 2010 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 20 Oct 2010 16:10:46 -0500 Subject: [Numpy-discussion] function name as parameter In-Reply-To: <4CBF57F1.2000707@lpta.in2p3.fr> References: <1287582131.8906.12.camel@koolasuchus.lanl.gov> <80A9C72D-3080-4902-A1EC-75DCFA4EE683@yale.edu> <4CBEF3E7.1060401@lpta.in2p3.fr> <4CBF57F1.2000707@lpta.in2p3.fr> Message-ID: On Wed, Oct 20, 2010 at 15:58, Johann Cohen-Tanugi wrote: > On 10/20/2010 10:35 PM, Nathaniel Smith wrote: >> IMPORTANT USAGE NOTE: never do this :-) >> > What would you recommand? I do encounter situations where I need > instantiation based on the name of the thing to instantiate, typically > passed as an argument by the client code/user..... Example? -- 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 From njs at pobox.com Wed Oct 20 17:17:26 2010 From: njs at pobox.com (Nathaniel Smith) Date: Wed, 20 Oct 2010 14:17:26 -0700 Subject: [Numpy-discussion] function name as parameter In-Reply-To: <4CBF57F1.2000707@lpta.in2p3.fr> References: <1287582131.8906.12.camel@koolasuchus.lanl.gov> <80A9C72D-3080-4902-A1EC-75DCFA4EE683@yale.edu> <4CBEF3E7.1060401@lpta.in2p3.fr> <4CBF57F1.2000707@lpta.in2p3.fr> Message-ID: On Wed, Oct 20, 2010 at 1:58 PM, Johann Cohen-Tanugi wrote: > On 10/20/2010 10:35 PM, Nathaniel Smith wrote: >> The better way to do this is: >> >> import inspect >> def call_this(fname, x): >> ? caller_frame = inspect.currentframe().f_back >> ? f = caller_frame.f_locals.get(fname, caller_frame.f_globals.get(fname)) >> ? return f(x) > > thanks for this probably safer way to do this (I guess safer, as I know > nothing about inspect module, but can imagine the value of being explicit as > to frames and namespaces) Right, there are two big advantages: (1) it looks up the name in the *caller*'s namespace, so it works even if the function is called from another module, (2) you don't have to rely on 'x' going float->string->back to float. (Which probably doesn't make much difference if you just have a single float argument, but for anything more complicated you can avoid a lot of hassle.) >> IMPORTANT USAGE NOTE: never do this :-) > > What would you recommand? I do encounter situations where I need > instantiation based on the name of the thing to instantiate, typically > passed as an argument by the client code/user..... > thanks in advance, Really, the recommendation is to define your API differently, so that people pass in actual objects (or whatever makes sense) instead of strings. But if you need to do this ugly thing for some reason (I've only needed it once, in a *very* exotic situation way outside what any normal scientific programmer would run into), then 'inspect' is probably the best way to accomplish it. -- Nathaniel From cohen at lpta.in2p3.fr Wed Oct 20 17:33:36 2010 From: cohen at lpta.in2p3.fr (Johann Cohen-Tanugi) Date: Wed, 20 Oct 2010 23:33:36 +0200 Subject: [Numpy-discussion] function name as parameter In-Reply-To: References: <1287582131.8906.12.camel@koolasuchus.lanl.gov> <80A9C72D-3080-4902-A1EC-75DCFA4EE683@yale.edu> <4CBEF3E7.1060401@lpta.in2p3.fr> <4CBF57F1.2000707@lpta.in2p3.fr> Message-ID: <4CBF6030.9090108@lpta.in2p3.fr> On 10/20/2010 11:10 PM, Robert Kern wrote: > On Wed, Oct 20, 2010 at 15:58, Johann Cohen-Tanugi wrote: > >> On 10/20/2010 10:35 PM, Nathaniel Smith wrote: >> > >>> IMPORTANT USAGE NOTE: never do this :-) >>> >>> >> What would you recommand? I do encounter situations where I need >> instantiation based on the name of the thing to instantiate, typically >> passed as an argument by the client code/user..... >> > Example? > > Hi Robert, so in a big data analysis framework, that is essentially written in C++, exposed to python with SWIG, plus dedicated python modules, the user performs an analysis choosing some given modules by name,as in : myOpt="foo" my_analyse.perform(use_optimizer=myOpt) The attribute use_optimizer is then checked to perform the right calls/instantiations of python but also C++ objects..... and the actual crunching number is in the C++ part. But then I realize that I need to tweak this optimizer's state, and the optimizer object is accessible from a library pyOpt that has been swigified from a C++ library. Then I access the object by calling optObject = eval("pyOpt.%s(some_args)"%myOpt) where myOpt would be "foo" in this particular analysis. This is because what the attribute use_optimizer expects is also the object name in the library, of course. It goes without saying that I could do : if myOpt=="foo": optObject=pyOpt.foo(some_args) else: .... and if you guys tell me it is way safer, I will do that instead of the use of eval that I liked because of the compactness..... As to Nathaniel's last point : yes of course the type changing of 'x' in my code would be unacceptable if x becomes complicated enough. This was not meant to be used in *any* situation. cheers, Johann From zachary.pincus at yale.edu Wed Oct 20 17:49:00 2010 From: zachary.pincus at yale.edu (Zachary Pincus) Date: Wed, 20 Oct 2010 17:49:00 -0400 Subject: [Numpy-discussion] function name as parameter In-Reply-To: <4CBF6030.9090108@lpta.in2p3.fr> References: <1287582131.8906.12.camel@koolasuchus.lanl.gov> <80A9C72D-3080-4902-A1EC-75DCFA4EE683@yale.edu> <4CBEF3E7.1060401@lpta.in2p3.fr> <4CBF57F1.2000707@lpta.in2p3.fr> <4CBF6030.9090108@lpta.in2p3.fr> Message-ID: > Hi Robert, > so in a big data analysis framework, that is essentially written in C > ++, > exposed to python with SWIG, plus dedicated python modules, the user > performs an analysis choosing some given modules by name,as in : > myOpt="foo" > my_analyse.perform(use_optimizer=myOpt) > > The attribute use_optimizer is then checked to perform the right > calls/instantiations of python but also C++ objects..... and the > actual > crunching number is in the C++ part. > But then I realize that I need to tweak this optimizer's state, and > the > optimizer object is accessible from a library pyOpt that has been > swigified from a C++ library. > Then I access the object by calling optObject = > eval("pyOpt.%s(some_args)"%myOpt) > where myOpt would be "foo" in this particular analysis. This is > because > what the attribute use_optimizer expects is also the object name in > the > library, of course. > It goes without saying that I could do : > if myOpt=="foo": > optObject=pyOpt.foo(some_args) > else: > .... > and if you guys tell me it is way safer, I will do that instead of the > use of eval that I liked because of the compactness..... Well, optObject=getattr(pyOpt, myOpt) is a bit nicer and marginally more likely to return sane error messages than optObject=eval("pyOpt. %s"%myOpt). Then you could do result=optObject(some_args)... But why not have the user just pass in the relevant optObject from the pyOpt namespace (or some restricted namespace that just has the relevant functions exposed)? E.g. my_analysis.perform(optimizer=pyOpt.Amoeba) rather than my_analysis.perform(optimizer='Amoeba') This lets users do introspection on the pyOpt namespace to see what functions they can choose from, which is rather friendlier in an interactive environment. Zach From cournape at gmail.com Wed Oct 20 18:04:58 2010 From: cournape at gmail.com (David Cournapeau) Date: Thu, 21 Oct 2010 07:04:58 +0900 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: On Thu, Oct 21, 2010 at 12:56 AM, Friedrich Romstedt wrote: > 2010/10/20 Darren Dale : >> On Wed, Oct 20, 2010 at 6:12 AM, Friedrich Romstedt >> wrote: >>> Due to Darren's config file the .nsi.in file made it with CRLF into the repo. >> >> Uh, no. > > You mean I'm wrong? Yes, the file has always used CRLF, and needs to stay that way. David From robert.kern at gmail.com Wed Oct 20 18:10:02 2010 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 20 Oct 2010 17:10:02 -0500 Subject: [Numpy-discussion] function name as parameter In-Reply-To: References: <1287582131.8906.12.camel@koolasuchus.lanl.gov> <80A9C72D-3080-4902-A1EC-75DCFA4EE683@yale.edu> <4CBEF3E7.1060401@lpta.in2p3.fr> <4CBF57F1.2000707@lpta.in2p3.fr> <4CBF6030.9090108@lpta.in2p3.fr> Message-ID: On Wed, Oct 20, 2010 at 16:49, Zachary Pincus wrote: > But why not have the user just pass in the relevant optObject from the > pyOpt namespace (or some restricted namespace that just has the > relevant functions exposed)? E.g. > my_analysis.perform(optimizer=pyOpt.Amoeba) > rather than > my_analysis.perform(optimizer='Amoeba') +11ty-billion > This lets users do introspection on the pyOpt namespace to see what > functions they can choose from, which is rather friendlier in an > interactive environment. Or implement their own without having to modify pyOpt. -- 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 From mwwiebe at gmail.com Wed Oct 20 19:59:53 2010 From: mwwiebe at gmail.com (Mark Wiebe) Date: Wed, 20 Oct 2010 16:59:53 -0700 Subject: [Numpy-discussion] dtype subarray comparison Message-ID: It turns out that when comparing dtypes, the subarray is currently ignored. This means you can get things like this: >>> import numpy as np >>> np.dtype(('f4',(6))) == np.dtype(('f4',(2,3))) True >>> np.dtype(([('a','i4')],2)) == np.dtype(([('b','u2'),('c','i2')],2)) True which pretty clearly should be False in both cases. I've implemented a patch to fix this, for which a pull request is here: http://github.com/numpy/numpy/pull/6 The main points included in this patch are: * If there's a subarray shape, it has to match exactly. * Currently, sometimes the subarray shape was an integer, other times a tuple. The output formatting code checks for this and prints a tuple in both cases. I changed the code to turn the integer into a tuple on construction instead. This didn't cause any tests to fail, so I think it's a safe change. * The current code converts (type, 1) and (type, tuple()) to just type, so this means (type, 1) != (type, (1,)) but (type, 2) == (type, (2,)) I put in some tests of these edge cases. http://github.com/numpy/numpy/blob/master/numpy/core/src/multiarray/descriptor.c#L234 Cheers, Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From dewald.pieterse at gmail.com Wed Oct 20 21:01:47 2010 From: dewald.pieterse at gmail.com (Dewald Pieterse) Date: Thu, 21 Oct 2010 01:01:47 +0000 Subject: [Numpy-discussion] Count occurrences in a nested ndarray In-Reply-To: <1D9D2607-BFE6-40C6-8F89-2DEED75CAB9F@gmail.com> References: <1D9D2607-BFE6-40C6-8F89-2DEED75CAB9F@gmail.com> Message-ID: On Wed, Oct 20, 2010 at 1:32 AM, Lutz Maibaum wrote: > On Oct 19, 2010, at 6:09 PM, Dewald Pieterse wrote: > > for xiter in range(xindex): > > for yiter in range(yindex): > > if edges[xiter,yiter,:] == [255,0,0]: > > groenpixelarea = groenpixelarea + 1 > > if edges[xiter,yiter,:] == [0,255,0]: > > rooipixelarea = rooipixelarea + 1 > > if edges[xiter,yiter,:] == [0,0,255]: > > bloupixelarea = bloupixelarea + 1 > > > > results in: > > > > 16 for xiter in range(xindex): > > 17 for yiter in range(yindex): > > ---> 18 if edges[xiter,yiter,:].any() == [255,0,0]: > > 19 groenpixelarea = groenpixelarea + 1 > > 20 if edges[xiter,yiter,:] == [0,255,0]: > > > > ValueError: The truth value of an array with more than one element is > ambiguous. Use a.any() or a.all() > > WARNING: Failure executing file: > > > The array comparison results in an array of booleans, which cannot be used > as a condition in the if statement. You could use > > if alltrue(edges[xiter,yiter,:] == [255,0,0]): > groenpixelarea = groenpixelarea + 1 > This worked. > There are probably much faster ways to do this that do not require > iterating over all pixels. You could try > > groenpixelarea = sum(alltrue(a.reshape((-1,3)) == array([0,0,255]), > axis=1)) > > This worked way faster, awesome. > Hope this helps, > > Lutz > > Thanks for all the help. -- Dewald Pieterse -------------- next part -------------- An HTML attachment was scrubbed... URL: From dagss at student.matnat.uio.no Thu Oct 21 02:50:18 2010 From: dagss at student.matnat.uio.no (Dag Sverre Seljebotn) Date: Thu, 21 Oct 2010 08:50:18 +0200 Subject: [Numpy-discussion] function name as parameter In-Reply-To: <4CBF6030.9090108@lpta.in2p3.fr> References: <1287582131.8906.12.camel@koolasuchus.lanl.gov> <80A9C72D-3080-4902-A1EC-75DCFA4EE683@yale.edu> <4CBEF3E7.1060401@lpta.in2p3.fr> <4CBF57F1.2000707@lpta.in2p3.fr> <4CBF6030.9090108@lpta.in2p3.fr> Message-ID: <4CBFE2AA.80206@student.matnat.uio.no> Johann Cohen-Tanugi wrote: > On 10/20/2010 11:10 PM, Robert Kern wrote: > >> On Wed, Oct 20, 2010 at 15:58, Johann Cohen-Tanugi wrote: >> >> >>> On 10/20/2010 10:35 PM, Nathaniel Smith wrote: >>> >>> >> >> >>>> IMPORTANT USAGE NOTE: never do this :-) >>>> >>>> >>>> >>> What would you recommand? I do encounter situations where I need >>> instantiation based on the name of the thing to instantiate, typically >>> passed as an argument by the client code/user..... >>> >>> >> Example? >> >> >> > Hi Robert, > so in a big data analysis framework, that is essentially written in C++, > exposed to python with SWIG, plus dedicated python modules, the user > performs an analysis choosing some given modules by name,as in : > myOpt="foo" > my_analyse.perform(use_optimizer=myOpt) > > The attribute use_optimizer is then checked to perform the right > calls/instantiations of python but also C++ objects..... and the actual > crunching number is in the C++ part. > But then I realize that I need to tweak this optimizer's state, and the > optimizer object is accessible from a library pyOpt that has been > swigified from a C++ library. > Then I access the object by calling optObject = > eval("pyOpt.%s(some_args)"%myOpt) > where myOpt would be "foo" in this particular analysis. This is because > what the attribute use_optimizer expects is also the object name in the > library, of course. > It goes without saying that I could do : > if myOpt=="foo": > optObject=pyOpt.foo(some_args) > else: > .... > and if you guys tell me it is way safer, I will do that instead of the > use of eval that I liked because of the compactness..... > In this case getattr fits... in general, in cases where one could do if action == 'a': a() elif action == 'b': b() the nice (proper?) way of doing it is usually to populate a dictionary: actions['a'] = a actions['b'] = b # automatically populate etc... actions[action]() And on the subject of passing strings around and eval-ing them: http://cache.gawkerassets.com/assets/images/4/2010/03/for_traffic_cameras.jpg Dag Sverre From cohen at lpta.in2p3.fr Thu Oct 21 04:43:56 2010 From: cohen at lpta.in2p3.fr (Johann Cohen-Tanugi) Date: Thu, 21 Oct 2010 10:43:56 +0200 Subject: [Numpy-discussion] function name as parameter In-Reply-To: References: <1287582131.8906.12.camel@koolasuchus.lanl.gov> <80A9C72D-3080-4902-A1EC-75DCFA4EE683@yale.edu> <4CBEF3E7.1060401@lpta.in2p3.fr> <4CBF57F1.2000707@lpta.in2p3.fr> <4CBF6030.9090108@lpta.in2p3.fr> Message-ID: <4CBFFD4C.10101@lpta.in2p3.fr> On 10/20/2010 11:49 PM, Zachary Pincus wrote: >> Hi Robert, >> so in a big data analysis framework, that is essentially written in C >> ++, >> exposed to python with SWIG, plus dedicated python modules, the user >> performs an analysis choosing some given modules by name,as in : >> myOpt="foo" >> my_analyse.perform(use_optimizer=myOpt) >> >> The attribute use_optimizer is then checked to perform the right >> calls/instantiations of python but also C++ objects..... and the >> actual >> crunching number is in the C++ part. >> But then I realize that I need to tweak this optimizer's state, and >> the >> optimizer object is accessible from a library pyOpt that has been >> swigified from a C++ library. >> Then I access the object by calling optObject = >> eval("pyOpt.%s(some_args)"%myOpt) >> where myOpt would be "foo" in this particular analysis. This is >> because >> what the attribute use_optimizer expects is also the object name in >> the >> library, of course. >> It goes without saying that I could do : >> if myOpt=="foo": >> optObject=pyOpt.foo(some_args) >> else: >> .... >> and if you guys tell me it is way safer, I will do that instead of the >> use of eval that I liked because of the compactness..... >> > Well, optObject=getattr(pyOpt, myOpt) is a bit nicer and marginally > more likely to return sane error messages than optObject=eval("pyOpt. > %s"%myOpt). Then you could do result=optObject(some_args)... > > ok I definitely like that better than eval. > But why not have the user just pass in the relevant optObject from the > pyOpt namespace (or some restricted namespace that just has the > relevant functions exposed)? E.g. > my_analysis.perform(optimizer=pyOpt.Amoeba) > rather than > my_analysis.perform(optimizer='Amoeba') > Well, that means that the user now needs to know about the underlying C++ library, etc.... Just requiring from the user that he knows the *name* of the optimizer was the primary driver. But I understand that it easily drives to a dead-end. my_analysis.perform(optimizer=pyOpt.Amoeba) is definitely allowed in the code as well, and that is what I do after I have fiddle with the optimizer object. Thanks to all for the tips and advices! Johann > This lets users do introspection on the pyOpt namespace to see what > functions they can choose from, which is rather friendlier in an > interactive environment. > > Zach > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > From friedrichromstedt at gmail.com Thu Oct 21 07:47:51 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Thu, 21 Oct 2010 13:47:51 +0200 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: 2010/10/21 David Cournapeau : > On Thu, Oct 21, 2010 at 12:56 AM, Friedrich Romstedt > wrote: >> 2010/10/20 Darren Dale : >>> On Wed, Oct 20, 2010 at 6:12 AM, Friedrich Romstedt >>> wrote: >>>> Due to Darren's config file the .nsi.in file made it with CRLF into the repo. >>> >>> Uh, no. >> >> You mean I'm wrong? > > Yes, the file has always used CRLF, and needs to stay that way. I see, misunderstanding, for me I used "made it" in the sense "succeeded in" :-) So to be clear, I meant that I understood your config file. Btw, it has \n\r, so it's LFCR and not CRLF as it should be on Windows (ref: de.wikipedia). I checked both my understanding of CR/LF as well as used $grep -PU '$\n\r' again. See also http://de.wikipedia.org/wiki/Zeilenumbruch (german, the en version doesn't have the table). So either: 1) You encoded for whatever reason the file with CR and LF swapped 2) It doesn't matter what the order is 3) There is some misunderstanding, once again. I don't want to go into a flame war about small small thing, maybe it's just my problem that I don't have a clear picture currently. Please apologise my insistence, Friedrich From cournape at gmail.com Thu Oct 21 09:26:57 2010 From: cournape at gmail.com (David Cournapeau) Date: Thu, 21 Oct 2010 22:26:57 +0900 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: On Thu, Oct 21, 2010 at 8:47 PM, Friedrich Romstedt wrote: > 2010/10/21 David Cournapeau : >> On Thu, Oct 21, 2010 at 12:56 AM, Friedrich Romstedt >> wrote: >>> 2010/10/20 Darren Dale : >>>> On Wed, Oct 20, 2010 at 6:12 AM, Friedrich Romstedt >>>> wrote: >>>>> Due to Darren's config file the .nsi.in file made it with CRLF into the repo. >>>> >>>> Uh, no. >>> >>> You mean I'm wrong? >> >> Yes, the file has always used CRLF, and needs to stay that way. > > I see, misunderstanding, for me I used "made it" in the sense > "succeeded in" :-) ?So to be clear, I meant that I understood your > config file. > > Btw, it has \n\r, so it's LFCR and not CRLF as it should be on Windows > (ref: de.wikipedia). ?I checked both my understanding of CR/LF as well > as used $grep -PU '$\n\r' again. > > See also http://de.wikipedia.org/wiki/Zeilenumbruch (german, the en > version doesn't have the table). ?So either: > 1) ?You encoded for whatever reason the file with CR and LF swapped Nobody encoded the file in a special manner. It just happens to be a file used on windows, by a windows program, and as such should stay in CR/LF format. I am not sure why you say LF and CR are swapped, I don't see it myself, and vim tells me it is in DOS (e.g. CR/LF) format. > 2) ?It doesn't matter what the order is It does matter. Although text editors are generally smart about line endings, other windows softwares are not. cheers, David From barthelemy at crans.org Thu Oct 21 11:06:04 2010 From: barthelemy at crans.org (=?ISO-8859-1?Q?S=E9bastien_Barth=E9lemy?=) Date: Thu, 21 Oct 2010 17:06:04 +0200 Subject: [Numpy-discussion] portable doctests despite floating points numbers In-Reply-To: <1287144301.1717.4.camel@Portable-s2m.cnrs-mrs.fr> References: <1287144301.1717.4.camel@Portable-s2m.cnrs-mrs.fr> Message-ID: I've haven't found any clean way. So I'll use "numpy.allclose" in my doctests. It will be harder to read, less interactive-session-like, but it might show the reader how compare floats properly. On Fri, Oct 15, 2010 at 2:05 PM, Fabrice Silva wrote: > Maybe you should not rely on doctest to do the comparison between > computed and expected result. You could use assert_* functions from > http://docs.scipy.org/doc/numpy/reference/routines.testing.html I didn't knew about them, they might prove useful too, thanks! Cheers From dsdale24 at gmail.com Thu Oct 21 12:06:15 2010 From: dsdale24 at gmail.com (Darren Dale) Date: Thu, 21 Oct 2010 12:06:15 -0400 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: On Thu, Oct 21, 2010 at 9:26 AM, David Cournapeau wrote: > On Thu, Oct 21, 2010 at 8:47 PM, Friedrich Romstedt > wrote: >> 2010/10/21 David Cournapeau : >>> On Thu, Oct 21, 2010 at 12:56 AM, Friedrich Romstedt >>> wrote: >>>> 2010/10/20 Darren Dale : >>>>> On Wed, Oct 20, 2010 at 6:12 AM, Friedrich Romstedt >>>>> wrote: >>>>>> Due to Darren's config file the .nsi.in file made it with CRLF into the repo. >>>>> >>>>> Uh, no. >>>> >>>> You mean I'm wrong? >>> >>> Yes, the file has always used CRLF, and needs to stay that way. >> >> I see, misunderstanding, for me I used "made it" in the sense >> "succeeded in" :-) ?So to be clear, I meant that I understood your >> config file. >> >> Btw, it has \n\r, so it's LFCR and not CRLF as it should be on Windows >> (ref: de.wikipedia). ?I checked both my understanding of CR/LF as well >> as used $grep -PU '$\n\r' again. >> >> See also http://de.wikipedia.org/wiki/Zeilenumbruch (german, the en >> version doesn't have the table). ?So either: >> 1) ?You encoded for whatever reason the file with CR and LF swapped > > Nobody encoded the file in a special manner. It just happens to be a > file used on windows, by a windows program, and as such should stay in > CR/LF format. I am not sure why you say LF and CR are swapped, I don't > see it myself, and vim tells me it is in DOS (e.g. CR/LF) format. > >> 2) ?It doesn't matter what the order is > > It does matter. Although text editors are generally smart about line > endings, other windows softwares are not. I filed a new pull request, http://github.com/numpy/numpy/pull/7 . This should enforce LF on all text files, with the current exception of the nsi.in file, which is CRLF. The svgs have been converted to LF. Additional, confusing reading can be found at http://help.github.com/dealing-with-lineendings/ , http://www.kernel.org/pub/software/scm/git/docs/git-config.html, and http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html . Darren From charlesr.harris at gmail.com Thu Oct 21 13:03:52 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Thu, 21 Oct 2010 11:03:52 -0600 Subject: [Numpy-discussion] dtype subarray comparison In-Reply-To: References: Message-ID: On Wed, Oct 20, 2010 at 5:59 PM, Mark Wiebe wrote: > It turns out that when comparing dtypes, the subarray is currently ignored. > This means you can get things like this: > > >>> import numpy as np > >>> np.dtype(('f4',(6))) == np.dtype(('f4',(2,3))) > True > >>> np.dtype(([('a','i4')],2)) == np.dtype(([('b','u2'),('c','i2')],2)) > True > > which pretty clearly should be False in both cases. I've implemented a > patch to fix this, for which a pull request is here: > > http://github.com/numpy/numpy/pull/6 > > The main points included in this patch are: > > * If there's a subarray shape, it has to match exactly. > * Currently, sometimes the subarray shape was an integer, other times a > tuple. The output formatting code checks for this and prints a tuple in > both cases. I changed the code to turn the integer into a tuple on > construction instead. This didn't cause any tests to fail, so I think it's > a safe change. > * The current code converts (type, 1) and (type, tuple()) to just type, so > this means (type, 1) != (type, (1,)) but (type, 2) == (type, (2,)) I put in > some tests of these edge cases. > > http://github.com/numpy/numpy/blob/master/numpy/core/src/multiarray/descriptor.c#L234 > > I think the important thing to settle here is just how dtype comparisons are supposed to work. The current implementation might well be intended and if so we need to know why it is so. I'd like Travis to weigh in here. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Thu Oct 21 14:18:14 2010 From: pav at iki.fi (Pauli Virtanen) Date: Thu, 21 Oct 2010 18:18:14 +0000 (UTC) Subject: [Numpy-discussion] dtype subarray comparison References: Message-ID: Thu, 21 Oct 2010 11:03:52 -0600, Charles R Harris wrote: [clip] > I think the important thing to settle here is just how dtype comparisons > are supposed to work. The current implementation might well be intended > and if so we need to know why it is so. I'd like Travis to weigh in > here. To me it seems that sub-arrays were not considered in the initial implementation for `==`. I do not see reasons why one would want to have a = dtype([('a', 'i1', (3, 3))]) b = dtype([('a', 'i1', 9)]) a == b In any case the current implementation is inconsistent, since currently hash(a) != hash(b) However, I can see why one would want to have CanCastSafely to be true between these types. *** The other issue of allowing broadcasting in sub-arrays --- it does not seem very useful to me. Unlike arrays, the dimensions of sub-arrays cannot be manipulated easily, and so many use-cases of broadcasting just disappear. Pauli From charlesr.harris at gmail.com Thu Oct 21 15:22:24 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Thu, 21 Oct 2010 13:22:24 -0600 Subject: [Numpy-discussion] dtype subarray comparison In-Reply-To: References: Message-ID: On Thu, Oct 21, 2010 at 12:18 PM, Pauli Virtanen wrote: > Thu, 21 Oct 2010 11:03:52 -0600, Charles R Harris wrote: > [clip] > > I think the important thing to settle here is just how dtype comparisons > > are supposed to work. The current implementation might well be intended > > and if so we need to know why it is so. I'd like Travis to weigh in > > here. > > To me it seems that sub-arrays were not considered in the initial > implementation for `==`. > > I do not see reasons why one would want to have > > a = dtype([('a', 'i1', (3, 3))]) > b = dtype([('a', 'i1', 9)]) > a == b > > In any case the current implementation is inconsistent, since currently > > hash(a) != hash(b) > > However, I can see why one would want to have CanCastSafely to be true > between these types. > > Checking the shape seems like the right thing to do, I just want to be sure that we aren't overlooking something. If we make the change will we need to fix CanCastSafely? > *** > > The other issue of allowing broadcasting in sub-arrays --- it does not > seem very useful to me. Unlike arrays, the dimensions of sub-arrays > cannot be manipulated easily, and so many use-cases of broadcasting just > disappear. > > Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwwiebe at gmail.com Thu Oct 21 15:50:11 2010 From: mwwiebe at gmail.com (Mark Wiebe) Date: Thu, 21 Oct 2010 12:50:11 -0700 Subject: [Numpy-discussion] dtype subarray comparison In-Reply-To: References: Message-ID: > > The other issue of allowing broadcasting in sub-arrays --- it does not seem very useful to me. Unlike arrays, the dimensions of sub-arrays cannot be manipulated easily, and so many use-cases of broadcasting just disappear. I implemented the a/b shape checking in the structured array comparison code, and it breaks 6 unit tests. The errors it produces are like the following: ====================================================================== FAIL: test_multiarray.TestNewBufferProtocol.test_roundtrip ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/nose/case.py", line 186, in runTest self.test(*self.arg) File "/home/mwiebe/installtest/lib64/python2.6/site-packages/numpy/core/tests/test_multiarray.py", line 1635, in test_roundtrip self._check_roundtrip(x) File "/home/mwiebe/installtest/lib64/python2.6/site-packages/numpy/core/tests/test_multiarray.py", line 1595, in _check_roundtrip assert_array_equal(obj, y) File "/home/mwiebe/installtest/lib64/python2.6/site-packages/numpy/testing/utils.py", line 686, in assert_array_equal verbose=verbose, header='Arrays are not equal') File "/home/mwiebe/installtest/lib64/python2.6/site-packages/numpy/testing/utils.py", line 618, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not equal (mismatch 100.0%) x: array(([[1, 2], [3, 4]],), dtype=[('a', '>> import numpy as np >>> from numpy.core.multiarray import memorysimpleview as memoryview >>> obj = np.array(([[1, 2], [3, 4]],), dtype=[('a', '>> x = memoryview(obj) >>> y = np.asarray(x) >>> obj == y False >>> y['a'].shape (1, 2, 2) >>> obj['a'].shape (2, 2) This happens because y.shape is (1,) and obj.shape is (), then the dtype's (2,2) shape is being appended to both when extracting the field 'a'. Cheers, Mark p.s.: Here's the small code addition, which I can add to the branch if desired: diff --git a/numpy/core/src/multiarray/arrayobject.c b/numpy/core/src/multiarray/a index 6e5bd9a..f12012c 100644 --- a/numpy/core/src/multiarray/arrayobject.c +++ b/numpy/core/src/multiarray/arrayobject.c @@ -844,6 +844,14 @@ _void_compare(PyArrayObject *self, PyArrayObject *other, int Py_DECREF(a); return NULL; } + if (PyArray_NDIM(a) != PyArray_NDIM(b) || + !PyArray_CompareLists(PyArray_DIMS(a), PyArray_DIMS(b), PyArr + Py_XDECREF(res); + Py_DECREF(a); + Py_DECREF(b); + Py_INCREF(Py_NotImplemented); + return Py_NotImplemented; + } temp = array_richcompare((PyArrayObject *)a,b,cmp_op); Py_DECREF(a); Py_DECREF(b); -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Thu Oct 21 16:06:59 2010 From: pav at iki.fi (Pauli Virtanen) Date: Thu, 21 Oct 2010 20:06:59 +0000 (UTC) Subject: [Numpy-discussion] dtype subarray comparison References: Message-ID: Thu, 21 Oct 2010 12:50:11 -0700, Mark Wiebe wrote: [clip] > >>> import numpy as np > >>> from numpy.core.multiarray import memorysimpleview as memoryview > >>> obj = np.array(([[1, 2], [3, 4]],), dtype=[('a', ' >>> x = memoryview(obj) > >>> y = np.asarray(x) > >>> obj == y > False > > >>> y['a'].shape > (1, 2, 2) > >>> obj['a'].shape > (2, 2) > > This happens because y.shape is (1,) and obj.shape is (), then the > dtype's (2,2) shape is being appended to both when extracting the field > 'a'. Nice catch! It seems that `_void_compare` *must* handle broadcasting itself -- I thought this was done by the caller, but apparently not. So you're right that the correct place to do the shape check is on the dtype level. -- Pauli Virtanen From mwwiebe at gmail.com Thu Oct 21 16:33:21 2010 From: mwwiebe at gmail.com (Mark Wiebe) Date: Thu, 21 Oct 2010 13:33:21 -0700 Subject: [Numpy-discussion] dtype subarray comparison In-Reply-To: References: Message-ID: On Thu, Oct 21, 2010 at 1:06 PM, Pauli Virtanen wrote: > > It seems that `_void_compare` *must* handle broadcasting itself -- I > thought this was done by the caller, but apparently not. So you're right > that the correct place to do the shape check is on the dtype level. > > There's a bug in my current patch with regard to this then, as follows: >>> x = np.array([(0,),(0,),(1,)],dtype=[('a','f8',(1,))]) >>> y = np.array([[(0,)],[(1,)]],dtype=[('a','f8',(1,))]) >>> x==y array([ True, False, False], dtype=bool) >>> y==x array([[ True, True, False], [False, False, True]], dtype=bool) -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From friedrichromstedt at gmail.com Thu Oct 21 16:48:45 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Thu, 21 Oct 2010 22:48:45 +0200 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: 2010/10/21 Darren Dale : > I filed a new pull request, http://github.com/numpy/numpy/pull/7 . > This should enforce LF on all text files, with the current exception > of the nsi.in file, which is CRLF. The svgs have been converted to LF. > Additional, confusing reading can be found at > http://help.github.com/dealing-with-lineendings/ , > http://www.kernel.org/pub/software/scm/git/docs/git-config.html, and > http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html . Hm, I like you pull request more than my own branch, but I think your conclusions might be incorrect. ``* text=auto`` forces git to normalise *all* text files, including the .nsi.in file, to LF *in the repo only*. But it says nothing about how to set eol in the working dir. ``[...].nsi.in eol=crlf`` forces git to check-out the .nsi.in file with CRLF. At least this is what the gitattributes.html we both seem to use says. So it's perfect, it keeps the repo clean, but allows users to check-out how they want, Friedrich From pav at iki.fi Thu Oct 21 17:11:07 2010 From: pav at iki.fi (Pauli Virtanen) Date: Thu, 21 Oct 2010 21:11:07 +0000 (UTC) Subject: [Numpy-discussion] dtype subarray comparison References: Message-ID: Thu, 21 Oct 2010 13:33:21 -0700, Mark Wiebe wrote: [clip] > There's a bug in my current patch with regard to this then, as follows: > > >>> x = np.array([(0,),(0,),(1,)],dtype=[('a','f8',(1,))]) >>>> y = np.array([[(0,)],[(1,)]],dtype=[('a','f8',(1,))]) x==y > array([ True, False, False], dtype=bool) >>>> y==x > array([[ True, True, False], > [False, False, True]], dtype=bool) Also, it is not correct to assume the dimensions are added to the end: >>> x = np.zeros((2,3),dtype=[('a','f8',(4,))]).T >>> x.shape (3, 2) >>> x['a'].shape (4, 3, 2) There's a special branch in the field access code that does this for Fortran-order arrays. Or, more precisely, arrays with the fortran-order flag set. (IIRC, there are some ways to create arrays in Fortran order so that the flag does not get set.) This seems to be somewhat of a mis-feature to me -- it makes predicting code behavior difficult to anticipate. -- Pauli Virtanen From mwwiebe at gmail.com Thu Oct 21 17:25:24 2010 From: mwwiebe at gmail.com (Mark Wiebe) Date: Thu, 21 Oct 2010 14:25:24 -0700 Subject: [Numpy-discussion] dtype subarray comparison In-Reply-To: References: Message-ID: On Thu, Oct 21, 2010 at 2:11 PM, Pauli Virtanen wrote: > > > Also, it is not correct to assume the dimensions are added to the end: > > >>> x = np.zeros((2,3),dtype=[('a','f8',(4,))]).T > >>> x.shape > (3, 2) > >>> x['a'].shape > (4, 3, 2) > > There's a special branch in the field access code that does this for > Fortran-order arrays. Or, more precisely, arrays with the fortran-order > flag set. (IIRC, there are some ways to create arrays in Fortran order so > that the flag does not get set.) > > This seems to be somewhat of a mis-feature to me -- it makes predicting > code behavior difficult to anticipate. > That sounds like it could be tricky to handle correctly, especially since it should probably work to compare Fortran-order arrays with non-Fortran ones. Does anything actually depend on this behavior? Maybe it's something that could change? -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent at vincentdavis.net Thu Oct 21 17:34:21 2010 From: vincent at vincentdavis.net (Vincent Davis) Date: Thu, 21 Oct 2010 15:34:21 -0600 Subject: [Numpy-discussion] test_creation Errors with np 1.5.1rc1 built on osx 10.5 py27 32bit Message-ID: Build info numpy-1.5.1rc1-py2.7-python.org-macosx10.5 python-2.7-macosx10.3 os x 10.5 installed on osx 10.6 python-2.7-macosx10.3 Been working on building the dmg, you can try it/download at http://vincentdavis.info/Shared/numpy-1.5.1rc1-py2.6-python.org-macosx10.3.dmg Saw a few tickets in trac but have not look into this really. I am thought maybe someone might already know what this is. Running unit tests for numpy NumPy version 1.5.1rc1 NumPy is installed in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy Python version 2.7 (r27:82508, Jul 3 2010, 20:17:05) [GCC 4.0.1 (Apple Inc. build 5493)] nose version 0.11.2 ...EEEEEEEEEEEE......................................................................................................................................................................................................................................................................................................................................................................................................................................................................................K........................................................................................................................................................................................................................................K......................Warning: overflow encountered in ldexp .......................................................................K......................K........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................S............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................. ====================================================================== ERROR: test_creation (test_datetime.TestDateTime) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/tests/test_datetime.py", line 10, in test_creation dt1 = np.dtype('M8[750%s]'%unit) TypeError: data type not understood ====================================================================== ERROR: test_creation_overflow (test_datetime.TestDateTime) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/tests/test_datetime.py", line 62, in test_creation_overflow timesteps = np.array([date], dtype='datetime64[s]')[0].astype(np.int64) TypeError: data type not understood ====================================================================== ERROR: test_divisor_conversion_as (test_datetime.TestDateTime) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/tests/test_datetime.py", line 58, in test_divisor_conversion_as self.assertRaises(ValueError, lambda : np.dtype('M8[as/10]')) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/case.py", line 456, in assertRaises callableObj(*args, **kwargs) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/tests/test_datetime.py", line 58, in self.assertRaises(ValueError, lambda : np.dtype('M8[as/10]')) TypeError: data type not understood ====================================================================== ERROR: test_divisor_conversion_bday (test_datetime.TestDateTime) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/tests/test_datetime.py", line 32, in test_divisor_conversion_bday assert np.dtype('M8[B/12]') == np.dtype('M8[2h]') TypeError: data type not understood ====================================================================== ERROR: test_divisor_conversion_day (test_datetime.TestDateTime) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/tests/test_datetime.py", line 37, in test_divisor_conversion_day assert np.dtype('M8[D/12]') == np.dtype('M8[2h]') TypeError: data type not understood ====================================================================== ERROR: test_divisor_conversion_fs (test_datetime.TestDateTime) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/tests/test_datetime.py", line 54, in test_divisor_conversion_fs assert np.dtype('M8[fs/100]') == np.dtype('M8[10as]') TypeError: data type not understood ====================================================================== ERROR: test_divisor_conversion_hour (test_datetime.TestDateTime) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/tests/test_datetime.py", line 42, in test_divisor_conversion_hour assert np.dtype('m8[h/30]') == np.dtype('m8[2m]') TypeError: data type not understood ====================================================================== ERROR: test_divisor_conversion_minute (test_datetime.TestDateTime) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/tests/test_datetime.py", line 46, in test_divisor_conversion_minute assert np.dtype('m8[m/30]') == np.dtype('m8[2s]') TypeError: data type not understood ====================================================================== ERROR: test_divisor_conversion_month (test_datetime.TestDateTime) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/tests/test_datetime.py", line 21, in test_divisor_conversion_month assert np.dtype('M8[M/2]') == np.dtype('M8[2W]') TypeError: data type not understood ====================================================================== ERROR: test_divisor_conversion_second (test_datetime.TestDateTime) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/tests/test_datetime.py", line 50, in test_divisor_conversion_second assert np.dtype('m8[s/100]') == np.dtype('m8[10ms]') TypeError: data type not understood ====================================================================== ERROR: test_divisor_conversion_week (test_datetime.TestDateTime) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/tests/test_datetime.py", line 26, in test_divisor_conversion_week assert np.dtype('m8[W/5]') == np.dtype('m8[B]') TypeError: data type not understood ====================================================================== ERROR: test_divisor_conversion_year (test_datetime.TestDateTime) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/tests/test_datetime.py", line 16, in test_divisor_conversion_year assert np.dtype('M8[Y/4]') == np.dtype('M8[3M]') TypeError: data type not understood ---------------------------------------------------------------------- Ran 3018 tests in 10.218s FAILED (KNOWNFAIL=4, SKIP=1, errors=12) -- Thanks Vincent Davis 720-301-3003 From vincent at vincentdavis.net Thu Oct 21 17:46:23 2010 From: vincent at vincentdavis.net (Vincent Davis) Date: Thu, 21 Oct 2010 15:46:23 -0600 Subject: [Numpy-discussion] test_creation Errors with np 1.5.1rc1 built on osx 10.5 py27 32bit In-Reply-To: References: Message-ID: Sorry for the noise, I guess I had some cross installed python27 after deleting everything and starting over it work. New results below. Vincent >>> numpy.test() Running unit tests for numpy NumPy version 1.5.1rc1 NumPy is installed in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy Python version 2.7 (r27:82508, Jul 3 2010, 20:17:05) [GCC 4.0.1 (Apple Inc. build 5493)] nose version 0.11.2 .........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................K........................................................................................................................................................................................................................................K......................Warning: overflow encountered in ldexp .......................................................................K......................K........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................S............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................. ---------------------------------------------------------------------- Ran 3006 tests in 10.219s OK (KNOWNFAIL=4, SKIP=1) On Thu, Oct 21, 2010 at 3:34 PM, Vincent Davis wrote: > Build info > numpy-1.5.1rc1-py2.7-python.org-macosx10.5 > python-2.7-macosx10.3 > os x 10.5 > > installed on osx 10.6 python-2.7-macosx10.3 > > Been working on building the dmg, you can try it/download at > http://vincentdavis.info/Shared/numpy-1.5.1rc1-py2.6-python.org-macosx10.3.dmg > > Saw a few tickets in trac but have not look into this really. I am > thought maybe someone might already know what this is. > > Running unit tests for numpy > NumPy version 1.5.1rc1 > NumPy is installed in > /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy > Python version 2.7 (r27:82508, Jul ?3 2010, 20:17:05) [GCC 4.0.1 > (Apple Inc. build 5493)] > nose version 0.11.2 > ...EEEEEEEEEEEE......................................................................................................................................................................................................................................................................................................................................................................................................................................................................................K........................................................................................................................................................................................................................................K......................Warning: > overflow encountered in ldexp > .......................................................................K......................K........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................S............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................. > ====================================================================== > ERROR: test_creation (test_datetime.TestDateTime) > ---------------------------------------------------------------------- > Traceback (most recent call last): > ?File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/tests/test_datetime.py", > line 10, in test_creation > ? ?dt1 = np.dtype('M8[750%s]'%unit) > TypeError: data type not understood > > ====================================================================== > ERROR: test_creation_overflow (test_datetime.TestDateTime) > ---------------------------------------------------------------------- > Traceback (most recent call last): > ?File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/tests/test_datetime.py", > line 62, in test_creation_overflow > ? ?timesteps = np.array([date], dtype='datetime64[s]')[0].astype(np.int64) > TypeError: data type not understood > > ====================================================================== > ERROR: test_divisor_conversion_as (test_datetime.TestDateTime) > ---------------------------------------------------------------------- > Traceback (most recent call last): > ?File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/tests/test_datetime.py", > line 58, in test_divisor_conversion_as > ? ?self.assertRaises(ValueError, lambda : np.dtype('M8[as/10]')) > ?File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/case.py", > line 456, in assertRaises > ? ?callableObj(*args, **kwargs) > ?File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/tests/test_datetime.py", > line 58, in > ? ?self.assertRaises(ValueError, lambda : np.dtype('M8[as/10]')) > TypeError: data type not understood > > ====================================================================== > ERROR: test_divisor_conversion_bday (test_datetime.TestDateTime) > ---------------------------------------------------------------------- > Traceback (most recent call last): > ?File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/tests/test_datetime.py", > line 32, in test_divisor_conversion_bday > ? ?assert np.dtype('M8[B/12]') == np.dtype('M8[2h]') > TypeError: data type not understood > > ====================================================================== > ERROR: test_divisor_conversion_day (test_datetime.TestDateTime) > ---------------------------------------------------------------------- > Traceback (most recent call last): > ?File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/tests/test_datetime.py", > line 37, in test_divisor_conversion_day > ? ?assert np.dtype('M8[D/12]') == np.dtype('M8[2h]') > TypeError: data type not understood > > ====================================================================== > ERROR: test_divisor_conversion_fs (test_datetime.TestDateTime) > ---------------------------------------------------------------------- > Traceback (most recent call last): > ?File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/tests/test_datetime.py", > line 54, in test_divisor_conversion_fs > ? ?assert np.dtype('M8[fs/100]') == np.dtype('M8[10as]') > TypeError: data type not understood > > ====================================================================== > ERROR: test_divisor_conversion_hour (test_datetime.TestDateTime) > ---------------------------------------------------------------------- > Traceback (most recent call last): > ?File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/tests/test_datetime.py", > line 42, in test_divisor_conversion_hour > ? ?assert np.dtype('m8[h/30]') == np.dtype('m8[2m]') > TypeError: data type not understood > > ====================================================================== > ERROR: test_divisor_conversion_minute (test_datetime.TestDateTime) > ---------------------------------------------------------------------- > Traceback (most recent call last): > ?File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/tests/test_datetime.py", > line 46, in test_divisor_conversion_minute > ? ?assert np.dtype('m8[m/30]') == np.dtype('m8[2s]') > TypeError: data type not understood > > ====================================================================== > ERROR: test_divisor_conversion_month (test_datetime.TestDateTime) > ---------------------------------------------------------------------- > Traceback (most recent call last): > ?File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/tests/test_datetime.py", > line 21, in test_divisor_conversion_month > ? ?assert np.dtype('M8[M/2]') == np.dtype('M8[2W]') > TypeError: data type not understood > > ====================================================================== > ERROR: test_divisor_conversion_second (test_datetime.TestDateTime) > ---------------------------------------------------------------------- > Traceback (most recent call last): > ?File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/tests/test_datetime.py", > line 50, in test_divisor_conversion_second > ? ?assert np.dtype('m8[s/100]') == np.dtype('m8[10ms]') > TypeError: data type not understood > > ====================================================================== > ERROR: test_divisor_conversion_week (test_datetime.TestDateTime) > ---------------------------------------------------------------------- > Traceback (most recent call last): > ?File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/tests/test_datetime.py", > line 26, in test_divisor_conversion_week > ? ?assert np.dtype('m8[W/5]') == np.dtype('m8[B]') > TypeError: data type not understood > > ====================================================================== > ERROR: test_divisor_conversion_year (test_datetime.TestDateTime) > ---------------------------------------------------------------------- > Traceback (most recent call last): > ?File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/tests/test_datetime.py", > line 16, in test_divisor_conversion_year > ? ?assert np.dtype('M8[Y/4]') == np.dtype('M8[3M]') > TypeError: data type not understood > > ---------------------------------------------------------------------- > Ran 3018 tests in 10.218s > > FAILED (KNOWNFAIL=4, SKIP=1, errors=12) > > > -- > Thanks > Vincent Davis > 720-301-3003 > -- Thanks Vincent Davis 720-301-3003 From pav at iki.fi Thu Oct 21 17:47:06 2010 From: pav at iki.fi (Pauli Virtanen) Date: Thu, 21 Oct 2010 21:47:06 +0000 (UTC) Subject: [Numpy-discussion] dtype subarray comparison References: Message-ID: Thu, 21 Oct 2010 14:25:24 -0700, Mark Wiebe wrote: [clip] > That sounds like it could be tricky to handle correctly, especially > since it should probably work to compare Fortran-order arrays with > non-Fortran ones. > > Does anything actually depend on this behavior? Maybe it's something > that could change? I believe nothing in Numpy or Scipy depends on that. The main question is how much of 3rd party code is likely to use this feature. I suppose this quirk is not widely relied on, and as far as I know, the behavior has not been documented. For instance, Travis's Guide to Numpy says (on subdtype): "If a field whose dtype object has this attribute is retrieved, then the extra dimensions implied by the shape are tacked on to the end of the retrieved array." IMO, it should be possible to change this with little prior notice. A can of worms :) -- Pauli Virtanen From dsdale24 at gmail.com Thu Oct 21 18:37:34 2010 From: dsdale24 at gmail.com (Darren Dale) Date: Thu, 21 Oct 2010 18:37:34 -0400 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: On Thu, Oct 21, 2010 at 4:48 PM, Friedrich Romstedt wrote: > 2010/10/21 Darren Dale : >> I filed a new pull request, http://github.com/numpy/numpy/pull/7 . >> This should enforce LF on all text files, with the current exception >> of the nsi.in file, which is CRLF. The svgs have been converted to LF. >> Additional, confusing reading can be found at >> http://help.github.com/dealing-with-lineendings/ , >> http://www.kernel.org/pub/software/scm/git/docs/git-config.html, and >> http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html . > > Hm, I like you pull request more than my own branch, but I think your > conclusions might be incorrect. > > ``* text=auto`` forces git to normalise *all* text files, including > the .nsi.in file, to LF *in the repo only*. ?But it says nothing about > how to set eol in the working dir. > > ``[...].nsi.in eol=crlf`` forces git to check-out the .nsi.in file with CRLF. I see. Thank you for clarifying. It probably is not necessary then to have the exception for the nsi.in file, since git will create files with CRLF eols in the working directory on windows by default. The eols in the working directory can be controlled by the core.eol setting, which defaults to "native". But unless David C gives his blessing, I will leave the pull request as is. Pretty confusing. Darren From mwwiebe at gmail.com Thu Oct 21 19:15:02 2010 From: mwwiebe at gmail.com (Mark Wiebe) Date: Thu, 21 Oct 2010 16:15:02 -0700 Subject: [Numpy-discussion] dtype subarray comparison In-Reply-To: References: Message-ID: On Thu, Oct 21, 2010 at 2:47 PM, Pauli Virtanen wrote: > Thu, 21 Oct 2010 14:25:24 -0700, Mark Wiebe wrote: > [clip] > > That sounds like it could be tricky to handle correctly, especially > > since it should probably work to compare Fortran-order arrays with > > non-Fortran ones. > > > > Does anything actually depend on this behavior? Maybe it's something > > that could change? > > I believe nothing in Numpy or Scipy depends on that. The main question is > how much of 3rd party code is likely to use this feature. > > I suppose this quirk is not widely relied on, and as far as I know, the > behavior has not been documented. For instance, Travis's Guide to Numpy > says (on subdtype): "If a field whose dtype object has this attribute is > retrieved, then the extra dimensions implied by the shape are tacked on to > the end of the retrieved array." > > IMO, it should be possible to change this with little prior notice. > > A can of worms :) I found the commit where Travis introduced the behaviour: http://github.com/numpy/numpy/commit/2fd136eb7977dd5172eb92d173a7c39921b0cf98 http://projects.scipy.org/numpy/changeset/2116 I didn't find any discussion in the mailing list or a trac ticket, so hopefully Travis could elaborate on it? -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Fri Oct 22 11:51:07 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Fri, 22 Oct 2010 11:51:07 -0400 Subject: [Numpy-discussion] numpy.polynomial.Polynomial Message-ID: I'm subclassing numpy.polynomial.Polynomial. So far it works well. One question on inplace changes Is it safe to change coef directly without creating a new instance? I'm not trying to change anything else in the polynomial, just for example pad, truncate or invert the coef inplace, e.g def pad(self, maxlag): self.coef = np.r_[self.coef, np.zeros(maxlag - len(self.coef))] Currently, I have rewritten this to return a new instance. Thanks, Josef From charlesr.harris at gmail.com Fri Oct 22 12:26:55 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Fri, 22 Oct 2010 10:26:55 -0600 Subject: [Numpy-discussion] numpy.polynomial.Polynomial In-Reply-To: References: Message-ID: On Fri, Oct 22, 2010 at 9:51 AM, wrote: > I'm subclassing numpy.polynomial.Polynomial. So far it works well. > > One question on inplace changes > > Is it safe to change coef directly without creating a new instance? > I'm not trying to change anything else in the polynomial, just for > example pad, truncate or invert the coef inplace, e.g > > def pad(self, maxlag): > self.coef = np.r_[self.coef, np.zeros(maxlag - len(self.coef))] > > Currently, I have rewritten this to return a new instance. > > You can (currently) modify the coef and it should work, but I think it best to regard the Polynomial class as immutable. I'm even contemplating making the coef attribute read only just to avoid such things. Another tip is to use // instead of / for division, polynomials are rather like integers that way and don't have a true divide so plain old / will fail for python 3.x Note that most operations will trim trailing zeros off the result. In [6]: P((1,1,1,0,0,0)) Out[6]: Polynomial([ 1., 1., 1., 0., 0., 0.], [-1., 1.]) In [7]: P((1,1,1,0,0,0)) + 1 Out[7]: Polynomial([ 2., 1., 1.], [-1., 1.]) The reason the constructor doesn't was because trailing zeros can be of interest in least squares fits. Is there a particular use case for which trailing zeros are important for you? The polynomial modules aren't finished products yet, I can still add some functionality if you think it useful. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Fri Oct 22 13:47:16 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Fri, 22 Oct 2010 13:47:16 -0400 Subject: [Numpy-discussion] numpy.polynomial.Polynomial In-Reply-To: References: Message-ID: On Fri, Oct 22, 2010 at 12:26 PM, Charles R Harris wrote: > > > On Fri, Oct 22, 2010 at 9:51 AM, wrote: >> >> I'm subclassing numpy.polynomial.Polynomial. So far it works well. >> >> One question on inplace changes >> >> Is it safe to change coef directly without creating a new instance? >> I'm not trying to change anything else in the polynomial, just for >> example pad, truncate or invert the coef inplace, e.g >> >> def pad(self, maxlag): >> ? ?self.coef = np.r_[self.coef, np.zeros(maxlag - len(self.coef))] >> >> Currently, I have rewritten this to return a new instance. >> > > You can (currently) modify the coef and it should work, but I think it best > to regard the Polynomial class as immutable. I'm even contemplating making > the coef attribute read only just to avoid such things. Another tip is to > use // instead of / for division, polynomials are rather like integers that > way and don't have a true divide so plain old / will fail for python 3.x > > Note that most operations will trim trailing zeros off the result. > > In [6]: P((1,1,1,0,0,0)) > Out[6]: Polynomial([ 1.,? 1.,? 1.,? 0.,? 0.,? 0.], [-1.,? 1.]) > > In [7]: P((1,1,1,0,0,0)) + 1 > Out[7]: Polynomial([ 2.,? 1.,? 1.], [-1.,? 1.]) > > The reason the constructor doesn't was because trailing zeros can be of > interest in least squares fits. Is there a particular use case for which > trailing zeros are important for you? The polynomial modules aren't finished > products yet, I can still add some functionality if you think it useful. I need "long" division, example was A(L)/B(L) for lag-polynomials as I showed before. My current version (unfinished since I got distracted by stats.distribution problems): from numpy import polynomial as npp class LagPolynomial(npp.Polynomial): #def __init__(self, maxlag): def pad(self, maxlag): return LagPolynomial(np.r_[self.coef, np.zeros(maxlag-len(self.coef))]) def padflip(self, maxlag): return LagPolynomial(np.r_[self.coef, np.zeros(maxlag-len(self.coef))][::-1]) def flip(self): '''reverse polynomial coefficients ''' return LagPolynomial(self.coef[::-1]) def div(self, other, maxlag=None): '''padded division, pads numerator with zeros to maxlag ''' if maxlag is None: maxlag = max(len(self.coef), len(other.coef)) + 1 return (self.padflip(maxlag) / other.flip()).flip() def filter(self, arr): return (self * arr) #trim to end another method I haven't copied over yet is the adjusted fromroots (normalized lag-polynomial from roots) Essentially, I want to do get the AR and ARMA processes in several different ways because I don't trust (my interpretation) of any single implementation and eventually to see which one is fastest. Josef > > Chuck > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > From charlesr.harris at gmail.com Fri Oct 22 14:14:13 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Fri, 22 Oct 2010 12:14:13 -0600 Subject: [Numpy-discussion] numpy.polynomial.Polynomial In-Reply-To: References: Message-ID: On Fri, Oct 22, 2010 at 11:47 AM, wrote: > On Fri, Oct 22, 2010 at 12:26 PM, Charles R Harris > wrote: > > > > > > On Fri, Oct 22, 2010 at 9:51 AM, wrote: > >> > >> I'm subclassing numpy.polynomial.Polynomial. So far it works well. > >> > >> One question on inplace changes > >> > >> Is it safe to change coef directly without creating a new instance? > >> I'm not trying to change anything else in the polynomial, just for > >> example pad, truncate or invert the coef inplace, e.g > >> > >> def pad(self, maxlag): > >> self.coef = np.r_[self.coef, np.zeros(maxlag - len(self.coef))] > >> > >> Currently, I have rewritten this to return a new instance. > >> > > > > You can (currently) modify the coef and it should work, but I think it > best > > to regard the Polynomial class as immutable. I'm even contemplating > making > > the coef attribute read only just to avoid such things. Another tip is to > > use // instead of / for division, polynomials are rather like integers > that > > way and don't have a true divide so plain old / will fail for python 3.x > > > > Note that most operations will trim trailing zeros off the result. > > > > In [6]: P((1,1,1,0,0,0)) > > Out[6]: Polynomial([ 1., 1., 1., 0., 0., 0.], [-1., 1.]) > > > > In [7]: P((1,1,1,0,0,0)) + 1 > > Out[7]: Polynomial([ 2., 1., 1.], [-1., 1.]) > > > > The reason the constructor doesn't was because trailing zeros can be of > > interest in least squares fits. Is there a particular use case for which > > trailing zeros are important for you? The polynomial modules aren't > finished > > products yet, I can still add some functionality if you think it useful. > > I need "long" division, example was A(L)/B(L) for lag-polynomials as I > showed before. > > OK, I kinda thought that was what you wanted. It would be a version of "true" division, the missing pieces are how to extend that to other basis, there are several possibilities... But I suppose they could just be marked not implemented for the time being. There also needs to be a way to specify "precision" and the location of the "decimal" point. > My current version (unfinished since I got distracted by > stats.distribution problems): > > from numpy import polynomial as npp > > > class LagPolynomial(npp.Polynomial): > > #def __init__(self, maxlag): > > def pad(self, maxlag): > return LagPolynomial(np.r_[self.coef, > np.zeros(maxlag-len(self.coef))]) > > def padflip(self, maxlag): > return LagPolynomial(np.r_[self.coef, > np.zeros(maxlag-len(self.coef))][::-1]) > > def flip(self): > '''reverse polynomial coefficients > ''' > return LagPolynomial(self.coef[::-1]) > > def div(self, other, maxlag=None): > '''padded division, pads numerator with zeros to maxlag > ''' > if maxlag is None: > maxlag = max(len(self.coef), len(other.coef)) + 1 > return (self.padflip(maxlag) / other.flip()).flip() > > def filter(self, arr): > return (self * arr) #trim to end > > > another method I haven't copied over yet is the adjusted fromroots > (normalized lag-polynomial from roots) > > Essentially, I want to do get the AR and ARMA processes in several > different ways because I don't trust (my interpretation) of any single > implementation and eventually to see which one is fastest. > > I could also implement "polyz" polynomials that would use negative powers of z. The Chebyshev polynomials are currently implemented with symmetric z-series using both positive and negative powers, but I may change that. Another possibility is some sort of factory function that emits polynomial classes with certain additional properties, I'm thinking of something like that for Jacobi polynomials. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Fri Oct 22 14:54:32 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Fri, 22 Oct 2010 14:54:32 -0400 Subject: [Numpy-discussion] numpy.polynomial.Polynomial In-Reply-To: References: Message-ID: trying again, my reply got bounced back by postfix program if the mail delivery service On Fri, Oct 22, 2010 at 2:45 PM, wrote: > On Fri, Oct 22, 2010 at 2:14 PM, Charles R Harris > wrote: >> >> >> On Fri, Oct 22, 2010 at 11:47 AM, wrote: >>> >>> On Fri, Oct 22, 2010 at 12:26 PM, Charles R Harris >>> wrote: >>> > >>> > >>> > On Fri, Oct 22, 2010 at 9:51 AM, wrote: >>> >> >>> >> I'm subclassing numpy.polynomial.Polynomial. So far it works well. >>> >> >>> >> One question on inplace changes >>> >> >>> >> Is it safe to change coef directly without creating a new instance? >>> >> I'm not trying to change anything else in the polynomial, just for >>> >> example pad, truncate or invert the coef inplace, e.g >>> >> >>> >> def pad(self, maxlag): >>> >> ? ?self.coef = np.r_[self.coef, np.zeros(maxlag - len(self.coef))] >>> >> >>> >> Currently, I have rewritten this to return a new instance. >>> >> >>> > >>> > You can (currently) modify the coef and it should work, but I think it >>> > best >>> > to regard the Polynomial class as immutable. I'm even contemplating >>> > making >>> > the coef attribute read only just to avoid such things. Another tip is >>> > to >>> > use // instead of / for division, polynomials are rather like integers >>> > that >>> > way and don't have a true divide so plain old / will fail for python 3.x >>> > >>> > Note that most operations will trim trailing zeros off the result. >>> > >>> > In [6]: P((1,1,1,0,0,0)) >>> > Out[6]: Polynomial([ 1.,? 1.,? 1.,? 0.,? 0.,? 0.], [-1.,? 1.]) >>> > >>> > In [7]: P((1,1,1,0,0,0)) + 1 >>> > Out[7]: Polynomial([ 2.,? 1.,? 1.], [-1.,? 1.]) >>> > >>> > The reason the constructor doesn't was because trailing zeros can be of >>> > interest in least squares fits. Is there a particular use case for which >>> > trailing zeros are important for you? The polynomial modules aren't >>> > finished >>> > products yet, I can still add some functionality if you think it useful. >>> >>> I need "long" division, example was A(L)/B(L) for lag-polynomials as I >>> showed before. >>> >> >> OK, I kinda thought that was what you wanted. It would be a version of >> "true" division, the missing pieces are how to extend that to other basis, >> there are several possibilities... But I suppose they could just be marked >> not implemented for the time being. There also needs to be a way to specify >> "precision" and the location of the "decimal" point. > As long as subclassing works and it seems to work well so far, adding a few topic specific methods is quite easy. > >> >>> >>> My current version (unfinished since I got distracted by >>> stats.distribution problems): >>> >>> from numpy import polynomial as npp >>> >>> >>> class LagPolynomial(npp.Polynomial): >>> >>> ? ?#def __init__(self, maxlag): >>> >>> ? ?def pad(self, maxlag): >>> ? ? ? ?return LagPolynomial(np.r_[self.coef, >>> np.zeros(maxlag-len(self.coef))]) >>> >>> ? ?def padflip(self, maxlag): >>> ? ? ? ?return LagPolynomial(np.r_[self.coef, >>> np.zeros(maxlag-len(self.coef))][::-1]) >>> >>> ? ?def flip(self): >>> ? ? ? ?'''reverse polynomial coefficients >>> ? ? ? ?''' >>> ? ? ? ?return LagPolynomial(self.coef[::-1]) >>> >>> ? ?def div(self, other, maxlag=None): >>> ? ? ? ?'''padded division, pads numerator with zeros to maxlag >>> ? ? ? ?''' >>> ? ? ? ?if maxlag is None: >>> ? ? ? ? ? ?maxlag = max(len(self.coef), len(other.coef)) + 1 >>> ? ? ? ?return (self.padflip(maxlag) / other.flip()).flip() >>> >>> ? ?def filter(self, arr): >>> ? ? ? ?return (self * arr) ?#trim to end >>> >>> >>> another method I haven't copied over yet is the adjusted fromroots >>> (normalized lag-polynomial from roots) >>> >>> Essentially, I want to do get the AR and ARMA processes in several >>> different ways because I don't trust (my interpretation) of any single >>> implementation and eventually to see which one is fastest. >>> >> >> >> I could also implement "polyz" polynomials that would use negative powers of >> z. The Chebyshev polynomials are currently implemented with symmetric >> z-series using both positive and negative powers, but I may change that. My background for this is pretty much causal filters in time series analysis. I still have only vague ideas about some of the signaling and polynomial stuff discussed in the previous thread. But I take whatever I can get, and can figure out how to use it. The polynomial class (and my wrappers around scipy.signal and fft) is nice because it allows almost literal translation of textbook formulas. If I have enough time, spectral densities are one of the next on the schedule. Thanks, I will keep treating the Polynomials as immutable. Josef >> >> Another possibility is some sort of factory function that emits polynomial >> classes with certain additional properties, I'm thinking of something like >> that for Jacobi polynomials. >> >> Chuck >> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> >> > From josef.pktd at gmail.com Fri Oct 22 15:51:12 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Fri, 22 Oct 2010 15:51:12 -0400 Subject: [Numpy-discussion] numpy.polynomial.Polynomial In-Reply-To: References: Message-ID: On Fri, Oct 22, 2010 at 2:54 PM, wrote: > trying again, my reply got bounced back by postfix program if the mail > delivery service > > On Fri, Oct 22, 2010 at 2:45 PM, ? wrote: >> On Fri, Oct 22, 2010 at 2:14 PM, Charles R Harris >> wrote: >>> >>> >>> On Fri, Oct 22, 2010 at 11:47 AM, wrote: >>>> >>>> On Fri, Oct 22, 2010 at 12:26 PM, Charles R Harris >>>> wrote: >>>> > >>>> > >>>> > On Fri, Oct 22, 2010 at 9:51 AM, wrote: >>>> >> >>>> >> I'm subclassing numpy.polynomial.Polynomial. So far it works well. >>>> >> >>>> >> One question on inplace changes >>>> >> >>>> >> Is it safe to change coef directly without creating a new instance? >>>> >> I'm not trying to change anything else in the polynomial, just for >>>> >> example pad, truncate or invert the coef inplace, e.g >>>> >> >>>> >> def pad(self, maxlag): >>>> >> ? ?self.coef = np.r_[self.coef, np.zeros(maxlag - len(self.coef))] >>>> >> >>>> >> Currently, I have rewritten this to return a new instance. >>>> >> >>>> > >>>> > You can (currently) modify the coef and it should work, but I think it >>>> > best >>>> > to regard the Polynomial class as immutable. I'm even contemplating >>>> > making >>>> > the coef attribute read only just to avoid such things. Another tip is >>>> > to >>>> > use // instead of / for division, polynomials are rather like integers >>>> > that >>>> > way and don't have a true divide so plain old / will fail for python 3.x >>>> > >>>> > Note that most operations will trim trailing zeros off the result. >>>> > >>>> > In [6]: P((1,1,1,0,0,0)) >>>> > Out[6]: Polynomial([ 1.,? 1.,? 1.,? 0.,? 0.,? 0.], [-1.,? 1.]) >>>> > >>>> > In [7]: P((1,1,1,0,0,0)) + 1 >>>> > Out[7]: Polynomial([ 2.,? 1.,? 1.], [-1.,? 1.]) >>>> > >>>> > The reason the constructor doesn't was because trailing zeros can be of >>>> > interest in least squares fits. Is there a particular use case for which >>>> > trailing zeros are important for you? The polynomial modules aren't >>>> > finished >>>> > products yet, I can still add some functionality if you think it useful. >>>> >>>> I need "long" division, example was A(L)/B(L) for lag-polynomials as I >>>> showed before. >>>> >>> >>> OK, I kinda thought that was what you wanted. It would be a version of >>> "true" division, the missing pieces are how to extend that to other basis, >>> there are several possibilities... But I suppose they could just be marked >>> not implemented for the time being. There also needs to be a way to specify >>> "precision" and the location of the "decimal" point. >> > As long as subclassing works and it seems to work well so far, adding > a few topic specific methods is quite easy. > >> >>> >>>> >>>> My current version (unfinished since I got distracted by >>>> stats.distribution problems): >>>> >>>> from numpy import polynomial as npp >>>> >>>> >>>> class LagPolynomial(npp.Polynomial): >>>> >>>> ? ?#def __init__(self, maxlag): >>>> >>>> ? ?def pad(self, maxlag): >>>> ? ? ? ?return LagPolynomial(np.r_[self.coef, >>>> np.zeros(maxlag-len(self.coef))]) >>>> >>>> ? ?def padflip(self, maxlag): >>>> ? ? ? ?return LagPolynomial(np.r_[self.coef, >>>> np.zeros(maxlag-len(self.coef))][::-1]) >>>> >>>> ? ?def flip(self): >>>> ? ? ? ?'''reverse polynomial coefficients >>>> ? ? ? ?''' >>>> ? ? ? ?return LagPolynomial(self.coef[::-1]) >>>> >>>> ? ?def div(self, other, maxlag=None): >>>> ? ? ? ?'''padded division, pads numerator with zeros to maxlag >>>> ? ? ? ?''' >>>> ? ? ? ?if maxlag is None: >>>> ? ? ? ? ? ?maxlag = max(len(self.coef), len(other.coef)) + 1 >>>> ? ? ? ?return (self.padflip(maxlag) / other.flip()).flip() >>>> >>>> ? ?def filter(self, arr): >>>> ? ? ? ?return (self * arr) ?#trim to end >>>> >>>> >>>> another method I haven't copied over yet is the adjusted fromroots >>>> (normalized lag-polynomial from roots) >>>> >>>> Essentially, I want to do get the AR and ARMA processes in several >>>> different ways because I don't trust (my interpretation) of any single >>>> implementation and eventually to see which one is fastest. >>>> >>> >>> >>> I could also implement "polyz" polynomials that would use negative powers of >>> z. The Chebyshev polynomials are currently implemented with symmetric >>> z-series using both positive and negative powers, but I may change that. > > > ?My background for this is pretty much causal filters in time series > ?analysis. I still have only vague ideas about some of the signaling > ?and polynomial stuff discussed in the previous thread. But I take > ?whatever I can get, and can figure out how to use it. > > ?The polynomial class (and my wrappers around scipy.signal and fft) is > ?nice because it allows almost literal translation of textbook > ?formulas. If I have enough time, spectral densities are one of the > ?next on the schedule. > > ?Thanks, I will keep treating the Polynomials as immutable. > > ?Josef > > >>> >>> Another possibility is some sort of factory function that emits polynomial >>> classes with certain additional properties, I'm thinking of something like >>> that for Jacobi polynomials. >>> >>> Chuck (and if I'm allowed to do some advertising) Here is the current version of the ARMA process class, currently using just Polynomial (not yet LagP) as one representation. http://bazaar.launchpad.net/~josef-pktd/statsmodels/statsmodels-josef-experimental-gsoc/annotate/head%3A/scikits/statsmodels/tsa/arima_process.py#L191 (Now I just have to figure out how to fix starting observations for signal.lfilter and find my fft version) Josef >>> >>> _______________________________________________ >>> NumPy-Discussion mailing list >>> NumPy-Discussion at scipy.org >>> http://mail.scipy.org/mailman/listinfo/numpy-discussion >>> >>> >> > From braingateway at gmail.com Sat Oct 23 06:40:11 2010 From: braingateway at gmail.com (braingateway) Date: Sat, 23 Oct 2010 12:40:11 +0200 Subject: [Numpy-discussion] How to limit the numpy.memmap's RAM usage? Message-ID: <4CC2BB8B.2030602@gmail.com> Hi everyone, I noticed the numpy.memmap using RAM to buffer data from memmap files. If I get a 100GB array in a memmap file and process it block by block, the RAM usage is going to increasing with the process running until there is no available space in RAM (4GB), even though the block size is only 1MB. for example: #### a = numpy.memmap(?a.bin?, dtype='float64', mode='r') blocklen=1e5 b=npy.zeros((len(a)/blocklen,)) for i in range(0,len(a)/blocklen): b[i]=npy.mean(a[i*blocklen:(i+1)*blocklen]) #### Is there any way to restrict the memory usage in numpy.memmap? LittleBigBrain From cournape at gmail.com Sat Oct 23 07:48:37 2010 From: cournape at gmail.com (David Cournapeau) Date: Sat, 23 Oct 2010 20:48:37 +0900 Subject: [Numpy-discussion] How to limit the numpy.memmap's RAM usage? In-Reply-To: <4CC2BB8B.2030602@gmail.com> References: <4CC2BB8B.2030602@gmail.com> Message-ID: 2010/10/23 braingateway : > Hi everyone, > I noticed the numpy.memmap using RAM to buffer data from memmap files. > If I get a 100GB array in a memmap file and process it block by block, > the RAM usage is going to increasing with the process running until > there is no available space in RAM (4GB), even though the block size is > only 1MB. > for example: > #### > a = numpy.memmap(?a.bin?, dtype='float64', mode='r') > blocklen=1e5 > b=npy.zeros((len(a)/blocklen,)) > for i in range(0,len(a)/blocklen): > b[i]=npy.mean(a[i*blocklen:(i+1)*blocklen]) > #### > Is there any way to restrict the memory usage in numpy.memmap? The whole point of using memmap is to let the OS do the buffering for you (which is likely to do a better job than you in many cases). Which OS are you using ? And how do you measure how much memory is taken by numpy for your array ? David From braingateway at gmail.com Sat Oct 23 11:44:44 2010 From: braingateway at gmail.com (braingateway) Date: Sat, 23 Oct 2010 17:44:44 +0200 Subject: [Numpy-discussion] How to limit the numpy.memmap's RAM usage? In-Reply-To: References: <4CC2BB8B.2030602@gmail.com> Message-ID: <4CC302EC.9040408@gmail.com> David Cournapeau : > 2010/10/23 braingateway : > >> Hi everyone, >> I noticed the numpy.memmap using RAM to buffer data from memmap files. >> If I get a 100GB array in a memmap file and process it block by block, >> the RAM usage is going to increasing with the process running until >> there is no available space in RAM (4GB), even though the block size is >> only 1MB. >> for example: >> #### >> a = numpy.memmap(?a.bin?, dtype='float64', mode='r') >> blocklen=1e5 >> b=npy.zeros((len(a)/blocklen,)) >> for i in range(0,len(a)/blocklen): >> b[i]=npy.mean(a[i*blocklen:(i+1)*blocklen]) >> #### >> Is there any way to restrict the memory usage in numpy.memmap? >> > > The whole point of using memmap is to let the OS do the buffering for > you (which is likely to do a better job than you in many cases). Which > OS are you using ? And how do you measure how much memory is taken by > numpy for your array ? > > David > _______________________________________________ > Hi David, I agree with you about the point of using memmap. That is why the behavior is so strange to me. I actually measure the size of resident set (pink trace in figure2) of the python process on Windows. Here I attached the result. You can see the RAM usage is definitely not file system cache. LittleBigBrain -------------- next part -------------- A non-text attachment was scrubbed... Name: numpyMemmapAvaRAM.PNG Type: image/png Size: 13416 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: numpyMemmapAvaRAM2.PNG Type: image/png Size: 18734 bytes Desc: not available URL: From charlesr.harris at gmail.com Sat Oct 23 12:15:37 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Sat, 23 Oct 2010 10:15:37 -0600 Subject: [Numpy-discussion] How to limit the numpy.memmap's RAM usage? In-Reply-To: <4CC302EC.9040408@gmail.com> References: <4CC2BB8B.2030602@gmail.com> <4CC302EC.9040408@gmail.com> Message-ID: On Sat, Oct 23, 2010 at 9:44 AM, braingateway wrote: > David Cournapeau : > > 2010/10/23 braingateway : >> >> >>> Hi everyone, >>> I noticed the numpy.memmap using RAM to buffer data from memmap files. >>> If I get a 100GB array in a memmap file and process it block by block, >>> the RAM usage is going to increasing with the process running until >>> there is no available space in RAM (4GB), even though the block size is >>> only 1MB. >>> for example: >>> #### >>> a = numpy.memmap(?a.bin?, dtype='float64', mode='r') >>> blocklen=1e5 >>> b=npy.zeros((len(a)/blocklen,)) >>> for i in range(0,len(a)/blocklen): >>> b[i]=npy.mean(a[i*blocklen:(i+1)*blocklen]) >>> #### >>> Is there any way to restrict the memory usage in numpy.memmap? >>> >>> >> >> The whole point of using memmap is to let the OS do the buffering for >> you (which is likely to do a better job than you in many cases). Which >> OS are you using ? And how do you measure how much memory is taken by >> numpy for your array ? >> >> David >> _______________________________________________ >> >> > Hi David, > > I agree with you about the point of using memmap. That is why the behavior > is so strange to me. > I actually measure the size of resident set (pink trace in figure2) of the > python process on Windows. Here I attached the result. You can see the RAM > usage is definitely not file system cache. > > Umm, a good operating system will use *all* of ram for buffering because ram is fast and it assumes you are likely to reuse data you have already used once. If it needs some memory for something else it just writes a page to disk, if dirty, and reads in the new data from disk and changes the address of the page. Where you get into trouble is if pages can't be evicted for some reason. Most modern OS's also have special options available for reading in streaming data from disk that can lead to significantly faster access for that sort of thing, but I don't think you can do that with memmapped files. I'm not sure how windows labels it's memory. IIRC, Memmaping a file leads to what is called file backed memory, it is essentially virtual memory. Now, I won't bet my life that there isn't a problem, but I think a misunderstanding of the memory information is more likely. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Sat Oct 23 12:24:10 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Sat, 23 Oct 2010 10:24:10 -0600 Subject: [Numpy-discussion] How to limit the numpy.memmap's RAM usage? In-Reply-To: References: <4CC2BB8B.2030602@gmail.com> <4CC302EC.9040408@gmail.com> Message-ID: On Sat, Oct 23, 2010 at 10:15 AM, Charles R Harris < charlesr.harris at gmail.com> wrote: > > > On Sat, Oct 23, 2010 at 9:44 AM, braingateway wrote: > >> David Cournapeau : >> >> 2010/10/23 braingateway : >>> >>> >>>> Hi everyone, >>>> I noticed the numpy.memmap using RAM to buffer data from memmap files. >>>> If I get a 100GB array in a memmap file and process it block by block, >>>> the RAM usage is going to increasing with the process running until >>>> there is no available space in RAM (4GB), even though the block size is >>>> only 1MB. >>>> for example: >>>> #### >>>> a = numpy.memmap(?a.bin?, dtype='float64', mode='r') >>>> blocklen=1e5 >>>> b=npy.zeros((len(a)/blocklen,)) >>>> for i in range(0,len(a)/blocklen): >>>> b[i]=npy.mean(a[i*blocklen:(i+1)*blocklen]) >>>> #### >>>> Is there any way to restrict the memory usage in numpy.memmap? >>>> >>>> >>> >>> The whole point of using memmap is to let the OS do the buffering for >>> you (which is likely to do a better job than you in many cases). Which >>> OS are you using ? And how do you measure how much memory is taken by >>> numpy for your array ? >>> >>> David >>> _______________________________________________ >>> >>> >> Hi David, >> >> I agree with you about the point of using memmap. That is why the behavior >> is so strange to me. >> I actually measure the size of resident set (pink trace in figure2) of the >> python process on Windows. Here I attached the result. You can see the RAM >> usage is definitely not file system cache. >> >> > Umm, a good operating system will use *all* of ram for buffering because > ram is fast and it assumes you are likely to reuse data you have already > used once. If it needs some memory for something else it just writes a page > to disk, if dirty, and reads in the new data from disk and changes the > address of the page. Where you get into trouble is if pages can't be evicted > for some reason. Most modern OS's also have special options available for > reading in streaming data from disk that can lead to significantly faster > access for that sort of thing, but I don't think you can do that with > memmapped files. > > I'm not sure how windows labels it's memory. IIRC, Memmaping a file leads > to what is called file backed memory, it is essentially virtual memory. Now, > I won't bet my life that there isn't a problem, but I think a > misunderstanding of the memory information is more likely. > > It is also possible that something else in your program is hanging onto memory but without knowing a lot more it is hard to tell. Are you seeing symptoms besides the memory graphs? It looks like you aren't running on windows, actually, so what OS are you running on? Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From braingateway at gmail.com Sat Oct 23 12:27:53 2010 From: braingateway at gmail.com (braingateway) Date: Sat, 23 Oct 2010 18:27:53 +0200 Subject: [Numpy-discussion] How to limit the numpy.memmap's RAM usage? In-Reply-To: References: <4CC2BB8B.2030602@gmail.com> <4CC302EC.9040408@gmail.com> Message-ID: <4CC30D09.2050402@gmail.com> Charles R Harris : > > > On Sat, Oct 23, 2010 at 10:15 AM, Charles R Harris > > wrote: > > > > On Sat, Oct 23, 2010 at 9:44 AM, braingateway > > wrote: > > David Cournapeau : > > 2010/10/23 braingateway >: > > > Hi everyone, > I noticed the numpy.memmap using RAM to buffer data > from memmap files. > If I get a 100GB array in a memmap file and process it > block by block, > the RAM usage is going to increasing with the process > running until > there is no available space in RAM (4GB), even though > the block size is > only 1MB. > for example: > #### > a = numpy.memmap(?a.bin?, dtype='float64', mode='r') > blocklen=1e5 > b=npy.zeros((len(a)/blocklen,)) > for i in range(0,len(a)/blocklen): > b[i]=npy.mean(a[i*blocklen:(i+1)*blocklen]) > #### > Is there any way to restrict the memory usage in > numpy.memmap? > > > > The whole point of using memmap is to let the OS do the > buffering for > you (which is likely to do a better job than you in many > cases). Which > OS are you using ? And how do you measure how much memory > is taken by > numpy for your array ? > > David > _______________________________________________ > > > Hi David, > > I agree with you about the point of using memmap. That is why > the behavior is so strange to me. > I actually measure the size of resident set (pink trace in > figure2) of the python process on Windows. Here I attached the > result. You can see the RAM usage is definitely not file > system cache. > > > Umm, a good operating system will use *all* of ram for buffering > because ram is fast and it assumes you are likely to reuse data > you have already used once. If it needs some memory for something > else it just writes a page to disk, if dirty, and reads in the new > data from disk and changes the address of the page. Where you get > into trouble is if pages can't be evicted for some reason. Most > modern OS's also have special options available for reading in > streaming data from disk that can lead to significantly faster > access for that sort of thing, but I don't think you can do that > with memmapped files. > > I'm not sure how windows labels it's memory. IIRC, Memmaping a > file leads to what is called file backed memory, it is essentially > virtual memory. Now, I won't bet my life that there isn't a > problem, but I think a misunderstanding of the memory information > is more likely. > > > It is also possible that something else in your program is hanging > onto memory but without knowing a lot more it is hard to tell. Are you > seeing symptoms besides the memory graphs? It looks like you aren't > running on windows, actually, so what OS are you running on? > > Chuck > ------------------------------------------------------------------------ > > Hi Chuck, Thanks a lot for quick response. I do run following supper simple script on windows: #### a = numpy.memmap(?a.bin?, dtype='float64', mode='r') blocklen=1e5 b=npy.zeros((len(a)/blocklen,)) for i in range(0,len(a)/blocklen): b[i]=npy.mean(a[i*blocklen:(i+1)*blocklen]) #### Everything became supper slow after python ate all the RAM. By the way, I also tried Qt QFile::map() there is no problem at all... LittleBigBrain From charlesr.harris at gmail.com Sat Oct 23 13:39:42 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Sat, 23 Oct 2010 11:39:42 -0600 Subject: [Numpy-discussion] How to limit the numpy.memmap's RAM usage? In-Reply-To: <4CC30D09.2050402@gmail.com> References: <4CC2BB8B.2030602@gmail.com> <4CC302EC.9040408@gmail.com> <4CC30D09.2050402@gmail.com> Message-ID: On Sat, Oct 23, 2010 at 10:27 AM, braingateway wrote: > Charles R Harris : > > > > > > On Sat, Oct 23, 2010 at 10:15 AM, Charles R Harris > > > wrote: > > > > > > > > On Sat, Oct 23, 2010 at 9:44 AM, braingateway > > > wrote: > > > > David Cournapeau : > > > > 2010/10/23 braingateway > >: > > > > > > Hi everyone, > > I noticed the numpy.memmap using RAM to buffer data > > from memmap files. > > If I get a 100GB array in a memmap file and process it > > block by block, > > the RAM usage is going to increasing with the process > > running until > > there is no available space in RAM (4GB), even though > > the block size is > > only 1MB. > > for example: > > #### > > a = numpy.memmap(?a.bin?, dtype='float64', mode='r') > > blocklen=1e5 > > b=npy.zeros((len(a)/blocklen,)) > > for i in range(0,len(a)/blocklen): > > b[i]=npy.mean(a[i*blocklen:(i+1)*blocklen]) > > #### > > Is there any way to restrict the memory usage in > > numpy.memmap? > > > > > > > > The whole point of using memmap is to let the OS do the > > buffering for > > you (which is likely to do a better job than you in many > > cases). Which > > OS are you using ? And how do you measure how much memory > > is taken by > > numpy for your array ? > > > > David > > _______________________________________________ > > > > > > Hi David, > > > > I agree with you about the point of using memmap. That is why > > the behavior is so strange to me. > > I actually measure the size of resident set (pink trace in > > figure2) of the python process on Windows. Here I attached the > > result. You can see the RAM usage is definitely not file > > system cache. > > > > > > Umm, a good operating system will use *all* of ram for buffering > > because ram is fast and it assumes you are likely to reuse data > > you have already used once. If it needs some memory for something > > else it just writes a page to disk, if dirty, and reads in the new > > data from disk and changes the address of the page. Where you get > > into trouble is if pages can't be evicted for some reason. Most > > modern OS's also have special options available for reading in > > streaming data from disk that can lead to significantly faster > > access for that sort of thing, but I don't think you can do that > > with memmapped files. > > > > I'm not sure how windows labels it's memory. IIRC, Memmaping a > > file leads to what is called file backed memory, it is essentially > > virtual memory. Now, I won't bet my life that there isn't a > > problem, but I think a misunderstanding of the memory information > > is more likely. > > > > > > It is also possible that something else in your program is hanging > > onto memory but without knowing a lot more it is hard to tell. Are you > > seeing symptoms besides the memory graphs? It looks like you aren't > > running on windows, actually, so what OS are you running on? > > > > Chuck > > ------------------------------------------------------------------------ > > > > > Hi Chuck, > > Thanks a lot for quick response. I do run following supper simple script > on windows: > > #### > a = numpy.memmap(?a.bin?, dtype='float64', mode='r') > blocklen=1e5 > b=npy.zeros((len(a)/blocklen,)) > for i in range(0,len(a)/blocklen): > b[i]=npy.mean(a[i*blocklen:(i+1)*blocklen]) > #### > Everything became supper slow after python ate all the RAM. > By the way, I also tried Qt QFile::map() there is no problem at all... > > Hmm. Nothing looks suspicious. For reference, can you be specific about the OS/version, python version, and numpy version? What happens if you simply do for i in range(0,len(a)/blocklen): a[i*blocklen:(i+1)*blocklen].copy() Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent at vincentdavis.net Sat Oct 23 14:44:48 2010 From: vincent at vincentdavis.net (Vincent Davis) Date: Sat, 23 Oct 2010 12:44:48 -0600 Subject: [Numpy-discussion] tests fails when run $nosetests numpy, but not from python prompt Message-ID: python2.7 10.5, osx 10.6, numpy 1.5.1rc1 Test pass when run from python prompt (see bottom) but fail when run from $nosetests numpy. 105osxpython:~ Vincent$ nosetests numpy .........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................E........................................................................................................................................................................................................................................E......................Warning: overflow encountered in ldexp .......................................................................E......................E...........................................................................................EEEEEE...................................................................................................................................................................................................................................................................................................................................................................................EEEEEEEEEE.EE..........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................S............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................. ====================================================================== ERROR: test_array_from_sequence_scalar_array2 (test_regression.TestRegression) Ticket #1081: weird array with strange input... ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/testing/decorators.py", line 213, in knownfailer raise KnownFailureTest, msg KnownFailureTest: Fix this for 1.5.0. ====================================================================== ERROR: test_umath.TestComplexFunctions.test_branch_cuts_failing ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/case.py", line 186, in runTest self.test(*self.arg) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/testing/decorators.py", line 213, in knownfailer raise KnownFailureTest, msg KnownFailureTest: These branch cuts are known to fail ====================================================================== ERROR: test_umath_complex.TestCarg.test_zero ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/case.py", line 186, in runTest self.test(*self.arg) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/testing/decorators.py", line 213, in knownfailer raise KnownFailureTest, msg KnownFailureTest: Complex arithmetic with signed zero is buggy on most implementation ====================================================================== ERROR: test_umath_complex.TestCexp.test_special_values2 ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/case.py", line 186, in runTest self.test(*self.arg) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/testing/decorators.py", line 213, in knownfailer raise KnownFailureTest, msg KnownFailureTest: cexp(nan + 0I) is wrong on most implementations ====================================================================== ERROR: Failure: ImportError (cannot import name fib2) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/loader.py", line 382, in loadTestsFromName addr.filename, addr.module) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/importer.py", line 39, in importFromPath return self.importFromDir(dir_path, fqname) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/importer.py", line 86, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/distutils/tests/f2py_ext/tests/test_fib2.py", line 3, in from f2py_ext import fib2 ImportError: cannot import name fib2 ====================================================================== ERROR: Failure: ImportError (cannot import name foo) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/loader.py", line 382, in loadTestsFromName addr.filename, addr.module) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/importer.py", line 39, in importFromPath return self.importFromDir(dir_path, fqname) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/importer.py", line 86, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/distutils/tests/f2py_f90_ext/tests/test_foo.py", line 3, in from f2py_f90_ext import foo ImportError: cannot import name foo ====================================================================== ERROR: Failure: ImportError (cannot import name fib3) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/loader.py", line 382, in loadTestsFromName addr.filename, addr.module) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/importer.py", line 39, in importFromPath return self.importFromDir(dir_path, fqname) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/importer.py", line 86, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/distutils/tests/gen_ext/tests/test_fib3.py", line 3, in from gen_ext import fib3 ImportError: cannot import name fib3 ====================================================================== ERROR: Failure: ImportError (No module named primes) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/loader.py", line 382, in loadTestsFromName addr.filename, addr.module) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/importer.py", line 39, in importFromPath return self.importFromDir(dir_path, fqname) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/importer.py", line 86, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/distutils/tests/pyrex_ext/tests/test_primes.py", line 3, in from pyrex_ext.primes import primes ImportError: No module named primes ====================================================================== ERROR: Failure: ImportError (cannot import name example) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/loader.py", line 382, in loadTestsFromName addr.filename, addr.module) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/importer.py", line 39, in importFromPath return self.importFromDir(dir_path, fqname) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/importer.py", line 86, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/distutils/tests/swig_ext/tests/test_example.py", line 3, in from swig_ext import example ImportError: cannot import name example ====================================================================== ERROR: Failure: ImportError (cannot import name example2) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/loader.py", line 382, in loadTestsFromName addr.filename, addr.module) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/importer.py", line 39, in importFromPath return self.importFromDir(dir_path, fqname) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/importer.py", line 86, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/distutils/tests/swig_ext/tests/test_example2.py", line 3, in from swig_ext import example2 ImportError: cannot import name example2 ====================================================================== ERROR: test_callback.TestF77Callback.test_all ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/case.py", line 367, in setUp try_run(self.inst, ('setup', 'setUp')) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/util.py", line 491, in try_run return func() File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 341, in setUp module_name=self.module_name) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 73, in wrapper memo[key] = func(*a, **kw) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 156, in build_code module_name=module_name) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 73, in wrapper memo[key] = func(*a, **kw) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 137, in build_module __import__(module_name) ImportError: dlopen(/tmp/tmpOjoP4S/_test_ext_module_5403.so, 2): no suitable image found. Did find: /tmp/tmpOjoP4S/_test_ext_module_5403.so: mach-o, but wrong architecture ====================================================================== ERROR: test_mixed.TestMixed.test_all ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/case.py", line 367, in setUp try_run(self.inst, ('setup', 'setUp')) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/util.py", line 491, in try_run return func() File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 346, in setUp module_name=self.module_name) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 73, in wrapper memo[key] = func(*a, **kw) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 137, in build_module __import__(module_name) ImportError: dlopen(/tmp/tmpOjoP4S/_test_ext_module_5403.so, 2): no suitable image found. Did find: /tmp/tmpOjoP4S/_test_ext_module_5403.so: mach-o, but wrong architecture ====================================================================== ERROR: test_return_character.TestF77ReturnCharacter.test_all ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/case.py", line 367, in setUp try_run(self.inst, ('setup', 'setUp')) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/util.py", line 491, in try_run return func() File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 341, in setUp module_name=self.module_name) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 73, in wrapper memo[key] = func(*a, **kw) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 156, in build_code module_name=module_name) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 73, in wrapper memo[key] = func(*a, **kw) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 137, in build_module __import__(module_name) ImportError: dlopen(/tmp/tmpOjoP4S/_test_ext_module_5403.so, 2): no suitable image found. Did find: /tmp/tmpOjoP4S/_test_ext_module_5403.so: mach-o, but wrong architecture ====================================================================== ERROR: test_return_character.TestF90ReturnCharacter.test_all ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/case.py", line 367, in setUp try_run(self.inst, ('setup', 'setUp')) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/util.py", line 491, in try_run return func() File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 341, in setUp module_name=self.module_name) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 73, in wrapper memo[key] = func(*a, **kw) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 156, in build_code module_name=module_name) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 73, in wrapper memo[key] = func(*a, **kw) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 137, in build_module __import__(module_name) ImportError: dlopen(/tmp/tmpOjoP4S/_test_ext_module_5403.so, 2): no suitable image found. Did find: /tmp/tmpOjoP4S/_test_ext_module_5403.so: mach-o, but wrong architecture ====================================================================== ERROR: test_return_complex.TestF77ReturnComplex.test_all ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/case.py", line 367, in setUp try_run(self.inst, ('setup', 'setUp')) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/util.py", line 491, in try_run return func() File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 341, in setUp module_name=self.module_name) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 73, in wrapper memo[key] = func(*a, **kw) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 156, in build_code module_name=module_name) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 73, in wrapper memo[key] = func(*a, **kw) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 137, in build_module __import__(module_name) ImportError: dlopen(/tmp/tmpOjoP4S/_test_ext_module_5403.so, 2): no suitable image found. Did find: /tmp/tmpOjoP4S/_test_ext_module_5403.so: mach-o, but wrong architecture ====================================================================== ERROR: test_return_complex.TestF90ReturnComplex.test_all ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/case.py", line 367, in setUp try_run(self.inst, ('setup', 'setUp')) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/util.py", line 491, in try_run return func() File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 341, in setUp module_name=self.module_name) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 73, in wrapper memo[key] = func(*a, **kw) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 156, in build_code module_name=module_name) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 73, in wrapper memo[key] = func(*a, **kw) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 137, in build_module __import__(module_name) ImportError: dlopen(/tmp/tmpOjoP4S/_test_ext_module_5403.so, 2): no suitable image found. Did find: /tmp/tmpOjoP4S/_test_ext_module_5403.so: mach-o, but wrong architecture ====================================================================== ERROR: test_return_integer.TestF77ReturnInteger.test_all ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/case.py", line 367, in setUp try_run(self.inst, ('setup', 'setUp')) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/util.py", line 491, in try_run return func() File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 341, in setUp module_name=self.module_name) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 73, in wrapper memo[key] = func(*a, **kw) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 156, in build_code module_name=module_name) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 73, in wrapper memo[key] = func(*a, **kw) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 137, in build_module __import__(module_name) ImportError: dlopen(/tmp/tmpOjoP4S/_test_ext_module_5403.so, 2): no suitable image found. Did find: /tmp/tmpOjoP4S/_test_ext_module_5403.so: mach-o, but wrong architecture ====================================================================== ERROR: test_return_integer.TestF90ReturnInteger.test_all ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/case.py", line 367, in setUp try_run(self.inst, ('setup', 'setUp')) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/util.py", line 491, in try_run return func() File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 341, in setUp module_name=self.module_name) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 73, in wrapper memo[key] = func(*a, **kw) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 156, in build_code module_name=module_name) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 73, in wrapper memo[key] = func(*a, **kw) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 137, in build_module __import__(module_name) ImportError: dlopen(/tmp/tmpOjoP4S/_test_ext_module_5403.so, 2): no suitable image found. Did find: /tmp/tmpOjoP4S/_test_ext_module_5403.so: mach-o, but wrong architecture ====================================================================== ERROR: test_return_logical.TestF77ReturnLogical.test_all ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/case.py", line 367, in setUp try_run(self.inst, ('setup', 'setUp')) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/util.py", line 491, in try_run return func() File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 341, in setUp module_name=self.module_name) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 73, in wrapper memo[key] = func(*a, **kw) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 156, in build_code module_name=module_name) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 73, in wrapper memo[key] = func(*a, **kw) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 137, in build_module __import__(module_name) ImportError: dlopen(/tmp/tmpOjoP4S/_test_ext_module_5403.so, 2): no suitable image found. Did find: /tmp/tmpOjoP4S/_test_ext_module_5403.so: mach-o, but wrong architecture ====================================================================== ERROR: test_return_logical.TestF90ReturnLogical.test_all ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/case.py", line 367, in setUp try_run(self.inst, ('setup', 'setUp')) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/util.py", line 491, in try_run return func() File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 341, in setUp module_name=self.module_name) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 73, in wrapper memo[key] = func(*a, **kw) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 156, in build_code module_name=module_name) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 73, in wrapper memo[key] = func(*a, **kw) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 137, in build_module __import__(module_name) ImportError: dlopen(/tmp/tmpOjoP4S/_test_ext_module_5403.so, 2): no suitable image found. Did find: /tmp/tmpOjoP4S/_test_ext_module_5403.so: mach-o, but wrong architecture ====================================================================== ERROR: test_return_real.TestF77ReturnReal.test_all ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/case.py", line 367, in setUp try_run(self.inst, ('setup', 'setUp')) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/util.py", line 491, in try_run return func() File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 341, in setUp module_name=self.module_name) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 73, in wrapper memo[key] = func(*a, **kw) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 156, in build_code module_name=module_name) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 73, in wrapper memo[key] = func(*a, **kw) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 137, in build_module __import__(module_name) ImportError: dlopen(/tmp/tmpOjoP4S/_test_ext_module_5403.so, 2): no suitable image found. Did find: /tmp/tmpOjoP4S/_test_ext_module_5403.so: mach-o, but wrong architecture ====================================================================== ERROR: test_return_real.TestF90ReturnReal.test_all ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/case.py", line 367, in setUp try_run(self.inst, ('setup', 'setUp')) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.3-py2.7.egg/nose/util.py", line 491, in try_run return func() File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 341, in setUp module_name=self.module_name) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 73, in wrapper memo[key] = func(*a, **kw) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 156, in build_code module_name=module_name) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 73, in wrapper memo[key] = func(*a, **kw) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/f2py/tests/util.py", line 137, in build_module __import__(module_name) ImportError: dlopen(/tmp/tmpOjoP4S/_test_ext_module_5403.so, 2): no suitable image found. Did find: /tmp/tmpOjoP4S/_test_ext_module_5403.so: mach-o, but wrong architecture ---------------------------------------------------------------------- Ran 3025 tests in 30.682s FAILED (SKIP=1, errors=22) python2.7 >>> numpy.test() Running unit tests for numpy NumPy version 1.5.1rc1 NumPy is installed in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy Python version 2.7 (r27:82508, Jul 3 2010, 21:12:11) [GCC 4.0.1 (Apple Inc. build 5493)] nose version 0.11.3 ---------------------------------------------------------------------- Ran 3006 tests in 14.112s OK (KNOWNFAIL=4, SKIP=1) python2.7-32 >>> numpy.test() Running unit tests for numpy NumPy version 1.5.1rc1 NumPy is installed in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy Python version 2.7 (r27:82508, Jul 3 2010, 21:12:11) [GCC 4.0.1 (Apple Inc. build 5493)] nose version 0.11.3 ---------------------------------------------------------------------- Ran 3006 tests in 14.060s OK (KNOWNFAIL=4, SKIP=1) References: <4CC2BB8B.2030602@gmail.com> <4CC302EC.9040408@gmail.com> <4CC30D09.2050402@gmail.com> Message-ID: <4CC3338D.3070905@gmail.com> Charles R Harris > > > On Sat, Oct 23, 2010 at 10:27 AM, braingateway > wrote: > > Charles R Harris : > > > > > > On Sat, Oct 23, 2010 at 10:15 AM, Charles R Harris > > > >> wrote: > > > > > > > > On Sat, Oct 23, 2010 at 9:44 AM, braingateway > > > >> > wrote: > > > > David Cournapeau : > > > > 2010/10/23 braingateway > > >>: > > > > > > Hi everyone, > > I noticed the numpy.memmap using RAM to buffer data > > from memmap files. > > If I get a 100GB array in a memmap file and > process it > > block by block, > > the RAM usage is going to increasing with the > process > > running until > > there is no available space in RAM (4GB), even > though > > the block size is > > only 1MB. > > for example: > > #### > > a = numpy.memmap(?a.bin?, dtype='float64', mode='r') > > blocklen=1e5 > > b=npy.zeros((len(a)/blocklen,)) > > for i in range(0,len(a)/blocklen): > > b[i]=npy.mean(a[i*blocklen:(i+1)*blocklen]) > > #### > > Is there any way to restrict the memory usage in > > numpy.memmap? > > > > > > > > The whole point of using memmap is to let the OS do the > > buffering for > > you (which is likely to do a better job than you in many > > cases). Which > > OS are you using ? And how do you measure how much > memory > > is taken by > > numpy for your array ? > > > > David > > _______________________________________________ > > > > > > Hi David, > > > > I agree with you about the point of using memmap. That > is why > > the behavior is so strange to me. > > I actually measure the size of resident set (pink trace in > > figure2) of the python process on Windows. Here I > attached the > > result. You can see the RAM usage is definitely not file > > system cache. > > > > > > Umm, a good operating system will use *all* of ram for buffering > > because ram is fast and it assumes you are likely to reuse data > > you have already used once. If it needs some memory for > something > > else it just writes a page to disk, if dirty, and reads in > the new > > data from disk and changes the address of the page. Where > you get > > into trouble is if pages can't be evicted for some reason. Most > > modern OS's also have special options available for reading in > > streaming data from disk that can lead to significantly faster > > access for that sort of thing, but I don't think you can do that > > with memmapped files. > > > > I'm not sure how windows labels it's memory. IIRC, Memmaping a > > file leads to what is called file backed memory, it is > essentially > > virtual memory. Now, I won't bet my life that there isn't a > > problem, but I think a misunderstanding of the memory > information > > is more likely. > > > > > > It is also possible that something else in your program is hanging > > onto memory but without knowing a lot more it is hard to tell. > Are you > > seeing symptoms besides the memory graphs? It looks like you aren't > > running on windows, actually, so what OS are you running on? > > > > Chuck > > > ------------------------------------------------------------------------ > > > > > Hi Chuck, > > Thanks a lot for quick response. I do run following supper simple > script > on windows: > > #### > a = numpy.memmap(?a.bin?, dtype='float64', mode='r') > blocklen=1e5 > b=npy.zeros((len(a)/blocklen,)) > for i in range(0,len(a)/blocklen): > b[i]=npy.mean(a[i*blocklen:(i+1)*blocklen]) > #### > Everything became supper slow after python ate all the RAM. > By the way, I also tried Qt QFile::map() there is no problem at all... > > > Hmm. Nothing looks suspicious. For reference, can you be specific > about the OS/version, python version, and numpy version? > > What happens if you simply do > for i in range(0,len(a)/blocklen): > a[i*blocklen:(i+1)*blocklen].copy() > > Chuck > Hi Chuck, Here is the versions: print sys.version 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit (AMD64)] print numpy.__version__ 1.4.1 print sys.getwindowsversion() (5, 2, 3790, 2, 'Service Pack 2') Besides, a[i*blocklen:(i+1)*blocklen].copy() gave out the same result. LittleBigBrain -------------- next part -------------- A non-text attachment was scrubbed... Name: numpyMemmapAvaRAM3.png Type: image/png Size: 19835 bytes Desc: not available URL: From butterw at gmail.com Sat Oct 23 17:32:14 2010 From: butterw at gmail.com (Peter Butterworth) Date: Sat, 23 Oct 2010 23:32:14 +0200 Subject: [Numpy-discussion] np.dtype(int) 64bit Message-ID: Hi, I'm getting some strange behaviour from 64bit numpy on windows. I'm using the win64 mkl builds of numpy from : http://www.lfd.uci.edu/~gohlke/pythonlibs/ Win64: np 1.5.1rc1 >>> np.dtype(int) dtype('int32') >>> type(argmin([2, 4, 5])) I believe the expected result on 64 bit numpy is what I get on Ubuntu with np 2.0.0 dev : >>> np.dtype(int) dtype('int64') Could someone please confirm this ? -- thanks, peter butterworth From cgohlke at uci.edu Sat Oct 23 20:06:02 2010 From: cgohlke at uci.edu (Christoph Gohlke) Date: Sat, 23 Oct 2010 17:06:02 -0700 Subject: [Numpy-discussion] np.dtype(int) 64bit In-Reply-To: References: Message-ID: <4CC3786A.2010209@uci.edu> On 10/23/2010 2:32 PM, Peter Butterworth wrote: > Hi, > > I'm getting some strange behaviour from 64bit numpy on windows. I'm > using the win64 mkl builds of numpy from : > http://www.lfd.uci.edu/~gohlke/pythonlibs/ > > Win64: np 1.5.1rc1 >>>> np.dtype(int) > dtype('int32') > >>>> type(argmin([2, 4, 5])) > > > > I believe the expected result on 64 bit numpy is what I get on Ubuntu > with np 2.0.0 dev : >>>> np.dtype(int) > dtype('int64') > > Could someone please confirm this ? > > Looks correct. CPython's 'int' is implemented as 'long' in C, which is 32 bit on Windows (LLP64 model) and 64 bit on other systems (LP64, etc). The function argmin() returns an index, which is implemented as 'Py_ssize_t' in C and is 64 bit on all 64 bit systems. -- Christoph From cournape at gmail.com Sat Oct 23 20:15:51 2010 From: cournape at gmail.com (David Cournapeau) Date: Sun, 24 Oct 2010 09:15:51 +0900 Subject: [Numpy-discussion] How to limit the numpy.memmap's RAM usage? In-Reply-To: <4CC302EC.9040408@gmail.com> References: <4CC2BB8B.2030602@gmail.com> <4CC302EC.9040408@gmail.com> Message-ID: On Sun, Oct 24, 2010 at 12:44 AM, braingateway wrote: > > I agree with you about the point of using memmap. > That is why the behavior > is so strange to me. I think it is expected. What kind of behavior were you expecting ? To be clear, if I have a lot of available ram, I expect memmap arrays to take almost all of it (virtual memroy ~ resident memory). Now, if at the same time, another process starts taking a lot of memory, I expect the OS to automatically lower resident memory for the process using memmap. I did a small experiment on mac os x, creating a giant mmap'd array in numpy, and at the same time running a small C program using mlock (to lock pages into physical memory). As soon as I lock a big area (where big means most of my physical ram), the python process dealing with the mmap area sees its resident memory decrease. As soon as I kill the C program locking the memory, the resident memory starts increasing again. cheers, David From daniel.wagner.ml at googlemail.com Sat Oct 23 21:00:01 2010 From: daniel.wagner.ml at googlemail.com (Daniel Wagner) Date: Sat, 23 Oct 2010 21:00:01 -0400 Subject: [Numpy-discussion] SVD problem - matrices are not aligned Message-ID: <69850AF6-EE6D-4E67-8FA4-284EDCF079B5@googlemail.com> Hi, I'm a new subscriber of this list. I hope to directly start with a question is ok... My question or problem: I've a matrix A which is calculated from the data b. The shapes of these matrices are: >>>A.shape (954, 9) >>>b.shape (954,) I calculate the SVD of A: >>> U, w, V = numpy.linalg.svd(A, full_matrices="True") >>>U.shape (954, 954) >>>W.diag(w) >>>W.shape (9,9) >>>V.shape (9,9) If I'm doing the check of the SVD results using: >>>numpy.allclose(A, numpy.dot(U, numpy.dot(W, V))) I get this error: "ValueError: matrices are not aligned" I'just don't get where the error does come from. There seems to be a general problem with my data or how I'm using the svd function. I hope anybody has an idea what I'm doing wrong or where my problem comes from. I really appreciate any suggestions! Many thanks! Greetings, Daniel Wagner From charlesr.harris at gmail.com Sat Oct 23 22:21:47 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Sat, 23 Oct 2010 20:21:47 -0600 Subject: [Numpy-discussion] SVD problem - matrices are not aligned In-Reply-To: <69850AF6-EE6D-4E67-8FA4-284EDCF079B5@googlemail.com> References: <69850AF6-EE6D-4E67-8FA4-284EDCF079B5@googlemail.com> Message-ID: On Sat, Oct 23, 2010 at 7:00 PM, Daniel Wagner wrote: > Hi, > > I'm a new subscriber of this list. I hope to directly start with a question > is ok... > > My question or problem: > I've a matrix A which is calculated from the data b. The shapes of these > matrices are: > >>>A.shape > (954, 9) > >>>b.shape > (954,) > > I calculate the SVD of A: > >>> U, w, V = numpy.linalg.svd(A, full_matrices="True") > >>>U.shape > (954, 954) > You want full_matrices set false so that U has shape (954, 9). > >>>W.diag(w) > >>>W.shape > (9,9) > >>>V.shape > (9,9) > > If I'm doing the check of the SVD results using: > >>>numpy.allclose(A, numpy.dot(U, numpy.dot(W, V))) > I get this error: > easier, allclose(A, dot(U*w, V) ) "ValueError: matrices are not aligned" > > Mismatched dimensions. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.wagner.ml at googlemail.com Sat Oct 23 22:33:50 2010 From: daniel.wagner.ml at googlemail.com (Daniel Wagner) Date: Sat, 23 Oct 2010 22:33:50 -0400 Subject: [Numpy-discussion] SVD problem - matrices are not aligned In-Reply-To: References: <69850AF6-EE6D-4E67-8FA4-284EDCF079B5@googlemail.com> Message-ID: <59846635-10A2-4743-9AD1-F967D6993EEF@googlemail.com> > On Sat, Oct 23, 2010 at 7:00 PM, Daniel Wagner wrote: > Hi, > > I'm a new subscriber of this list. I hope to directly start with a question is ok... > > My question or problem: > I've a matrix A which is calculated from the data b. The shapes of these matrices are: > >>>A.shape > (954, 9) > >>>b.shape > (954,) > > I calculate the SVD of A: > >>> U, w, V = numpy.linalg.svd(A, full_matrices="True") > >>>U.shape > (954, 954) > > You want full_matrices set false so that U has shape (954, 9). > thanks! I tried it before with "False" as a string but of course this couldn't work. omgh. (no error message?) Now I'm using: >>>U, w, V = numpy.linalg.svd(yz_matrix_by, full_matrices=False) > >>>W.diag(w) > >>>W.shape > (9,9) > >>>V.shape > (9,9) > > If I'm doing the check of the SVD results using: > >>>numpy.allclose(A, numpy.dot(U, numpy.dot(W, V))) > I get this error: > > easier, allclose(A, dot(U*w, V) ) > That's right! > > "ValueError: matrices are not aligned" > > > Mismatched dimensions. > Yeah, this error is away. Now I get: >>>print(numpy.allclose(U_by*w_by, V_by)) False I have to think about it if this makes sense ... (for me and prob. my my data) Thanks and Greetings, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Sat Oct 23 22:48:43 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Sat, 23 Oct 2010 20:48:43 -0600 Subject: [Numpy-discussion] SVD problem - matrices are not aligned In-Reply-To: <59846635-10A2-4743-9AD1-F967D6993EEF@googlemail.com> References: <69850AF6-EE6D-4E67-8FA4-284EDCF079B5@googlemail.com> <59846635-10A2-4743-9AD1-F967D6993EEF@googlemail.com> Message-ID: On Sat, Oct 23, 2010 at 8:33 PM, Daniel Wagner wrote: > On Sat, Oct 23, 2010 at 7:00 PM, Daniel Wagner googlemail.com> wrote: > >> Hi, >> >> I'm a new subscriber of this list. I hope to directly start with a >> question is ok... >> >> My question or problem: >> I've a matrix A which is calculated from the data b. The shapes of these >> matrices are: >> >>>A.shape >> (954, 9) >> >>>b.shape >> (954,) >> >> I calculate the SVD of A: >> >>> U, w, V = numpy.linalg.svd(A, full_matrices="True") >> >>>U.shape >> (954, 954) >> > > You want full_matrices set false so that U has shape (954, 9). > > > thanks! I tried it before with "False" as a string but of course this > couldn't work. omgh. (no error message?) > Now I'm using: > >>>U, w, V = numpy.linalg.svd(yz_matrix_by, full_matrices=False) > > >>>W.diag(w) >> >>>W.shape >> (9,9) >> >>>V.shape >> (9,9) >> >> If I'm doing the check of the SVD results using: >> >>>numpy.allclose(A, numpy.dot(U, numpy.dot(W, V))) >> I get this error: >> > > easier, allclose(A, dot(U*w, V) ) > > That's right! > > > "ValueError: matrices are not aligned" >> >> > Mismatched dimensions. > > Yeah, this error is away. Now I get: > >>>print(numpy.allclose(U_by*w_by, V_by)) > False > > Seems to be a missing "dot" in there. Chuck > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.wagner.ml at googlemail.com Sat Oct 23 23:21:16 2010 From: daniel.wagner.ml at googlemail.com (Daniel Wagner) Date: Sat, 23 Oct 2010 23:21:16 -0400 Subject: [Numpy-discussion] SVD problem - matrices are not aligned In-Reply-To: References: <69850AF6-EE6D-4E67-8FA4-284EDCF079B5@googlemail.com> <59846635-10A2-4743-9AD1-F967D6993EEF@googlemail.com> Message-ID: On Oct 23, 2010, at 10:48 PM, Charles R Harris wrote: > > > On Sat, Oct 23, 2010 at 8:33 PM, Daniel Wagner wrote: >> On Sat, Oct 23, 2010 at 7:00 PM, Daniel Wagner wrote: >> Hi, >> >> I'm a new subscriber of this list. I hope to directly start with a question is ok... >> >> My question or problem: >> I've a matrix A which is calculated from the data b. The shapes of these matrices are: >> >>>A.shape >> (954, 9) >> >>>b.shape >> (954,) >> >> I calculate the SVD of A: >> >>> U, w, V = numpy.linalg.svd(A, full_matrices="True") >> >>>U.shape >> (954, 954) >> >> You want full_matrices set false so that U has shape (954, 9). >> > thanks! I tried it before with "False" as a string but of course this couldn't work. omgh. (no error message?) > Now I'm using: > >>>U, w, V = numpy.linalg.svd(yz_matrix_by, full_matrices=False) > >> >>>W.diag(w) >> >>>W.shape >> (9,9) >> >>>V.shape >> (9,9) >> >> If I'm doing the check of the SVD results using: >> >>>numpy.allclose(A, numpy.dot(U, numpy.dot(W, V))) >> I get this error: >> >> easier, allclose(A, dot(U*w, V) ) >> > That's right! > >> >> "ValueError: matrices are not aligned" >> >> >> Mismatched dimensions. >> > > Yeah, this error is away. Now I get: > >>>print(numpy.allclose(U_by*w_by, V_by)) > False > > > Seems to be a missing "dot" in there. > The following works: >>>numpy.allclose(A, numpy.dot(U, numpy.dot(W, V))) True But now I've a new problem problem: When I'm using: >>> A.shape (954, 9) >>> b.shape (954, ) >>> temp = numpy.linalg.pinv(A, rcond=1.0000000000000001e-15) >>> temp.shape (9, 954) to multiply this with my data b >>>x = numpy.dot(temp, b) ValueError: matrices are not aligned I've missmatched dimensions again.... Greetings, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Sat Oct 23 23:25:49 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Sat, 23 Oct 2010 21:25:49 -0600 Subject: [Numpy-discussion] SVD problem - matrices are not aligned In-Reply-To: References: <69850AF6-EE6D-4E67-8FA4-284EDCF079B5@googlemail.com> <59846635-10A2-4743-9AD1-F967D6993EEF@googlemail.com> Message-ID: On Sat, Oct 23, 2010 at 9:21 PM, Daniel Wagner wrote: > > On Oct 23, 2010, at 10:48 PM, Charles R Harris wrote: > > > > On Sat, Oct 23, 2010 at 8:33 PM, Daniel Wagner googlemail.com> wrote: > >> On Sat, Oct 23, 2010 at 7:00 PM, Daniel Wagner > googlemail.com> wrote: >> >>> Hi, >>> >>> I'm a new subscriber of this list. I hope to directly start with a >>> question is ok... >>> >>> My question or problem: >>> I've a matrix A which is calculated from the data b. The shapes of these >>> matrices are: >>> >>>A.shape >>> (954, 9) >>> >>>b.shape >>> (954,) >>> >>> I calculate the SVD of A: >>> >>> U, w, V = numpy.linalg.svd(A, full_matrices="True") >>> >>>U.shape >>> (954, 954) >>> >> >> You want full_matrices set false so that U has shape (954, 9). >> >> >> thanks! I tried it before with "False" as a string but of course this >> couldn't work. omgh. (no error message?) >> Now I'm using: >> >>>U, w, V = numpy.linalg.svd(yz_matrix_by, full_matrices=False) >> >> >>>W.diag(w) >>> >>>W.shape >>> (9,9) >>> >>>V.shape >>> (9,9) >>> >>> If I'm doing the check of the SVD results using: >>> >>>numpy.allclose(A, numpy.dot(U, numpy.dot(W, V))) >>> I get this error: >>> >> >> easier, allclose(A, dot(U*w, V) ) >> >> That's right! >> >> >> "ValueError: matrices are not aligned" >>> >>> >> Mismatched dimensions. >> >> Yeah, this error is away. Now I get: >> >>>print(numpy.allclose(U_by*w_by, V_by)) >> False >> >> > Seems to be a missing "dot" in there. > > The following works: > >>>numpy.allclose(A, numpy.dot(U, numpy.dot(W, V))) > True > > But now I've a new problem problem: > > When I'm using: > > >>> A.shape > (954, 9) > >>> b.shape > (954, ) > >>> temp = numpy.linalg.pinv(A, rcond=1.0000000000000001e-15) > >>> temp.shape > (9, 954) > > to multiply this with my data b > >>>x = numpy.dot(temp, b) > ValueError: matrices are not aligned > > I've missmatched dimensions again.... > > Looks like you might want to look at lstsq. Chuck > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.wagner.ml at googlemail.com Sat Oct 23 23:35:19 2010 From: daniel.wagner.ml at googlemail.com (Daniel Wagner) Date: Sat, 23 Oct 2010 23:35:19 -0400 Subject: [Numpy-discussion] SVD problem - matrices are not aligned In-Reply-To: References: <69850AF6-EE6D-4E67-8FA4-284EDCF079B5@googlemail.com> <59846635-10A2-4743-9AD1-F967D6993EEF@googlemail.com> Message-ID: <2E2513B4-BDC4-44F2-8670-2DA529D6C6CD@googlemail.com> On Oct 23, 2010, at 11:25 PM, Charles R Harris wrote: > > > On Sat, Oct 23, 2010 at 9:21 PM, Daniel Wagner wrote: > > On Oct 23, 2010, at 10:48 PM, Charles R Harris wrote: > >> >> >> On Sat, Oct 23, 2010 at 8:33 PM, Daniel Wagner wrote: >>> On Sat, Oct 23, 2010 at 7:00 PM, Daniel Wagner wrote: >>> Hi, >>> >>> I'm a new subscriber of this list. I hope to directly start with a question is ok... >>> >>> My question or problem: >>> I've a matrix A which is calculated from the data b. The shapes of these matrices are: >>> >>>A.shape >>> (954, 9) >>> >>>b.shape >>> (954,) >>> >>> I calculate the SVD of A: >>> >>> U, w, V = numpy.linalg.svd(A, full_matrices="True") >>> >>>U.shape >>> (954, 954) >>> >>> You want full_matrices set false so that U has shape (954, 9). >>> >> thanks! I tried it before with "False" as a string but of course this couldn't work. omgh. (no error message?) >> Now I'm using: >> >>>U, w, V = numpy.linalg.svd(yz_matrix_by, full_matrices=False) >> >>> >>>W.diag(w) >>> >>>W.shape >>> (9,9) >>> >>>V.shape >>> (9,9) >>> >>> If I'm doing the check of the SVD results using: >>> >>>numpy.allclose(A, numpy.dot(U, numpy.dot(W, V))) >>> I get this error: >>> >>> easier, allclose(A, dot(U*w, V) ) >>> >> That's right! >> >>> >>> "ValueError: matrices are not aligned" >>> >>> >>> Mismatched dimensions. >>> >> >> Yeah, this error is away. Now I get: >> >>>print(numpy.allclose(U_by*w_by, V_by)) >> False >> >> >> Seems to be a missing "dot" in there. >> > > The following works: > >>>numpy.allclose(A, numpy.dot(U, numpy.dot(W, V))) > True > > But now I've a new problem problem: > > When I'm using: > > >>> A.shape > (954, 9) > >>> b.shape > (954, ) > >>> temp = numpy.linalg.pinv(A, rcond=1.0000000000000001e-15) > >>> temp.shape > (9, 954) > > to multiply this with my data b > >>>x = numpy.dot(temp, b) > ValueError: matrices are not aligned > > I've missmatched dimensions again.... > > > Looks like you might want to look at lstsq. > right, I want to compute the least square..... Does lstsq() use svd for it's computations? Is it possible to take a look how it calculates the values? Thanks. Greetings, Daniel > Chuck > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.wagner.ml at googlemail.com Sat Oct 23 23:47:34 2010 From: daniel.wagner.ml at googlemail.com (Daniel Wagner) Date: Sat, 23 Oct 2010 23:47:34 -0400 Subject: [Numpy-discussion] SVD problem - matrices are not aligned In-Reply-To: References: <69850AF6-EE6D-4E67-8FA4-284EDCF079B5@googlemail.com> <59846635-10A2-4743-9AD1-F967D6993EEF@googlemail.com> Message-ID: On Oct 23, 2010, at 11:25 PM, Charles R Harris wrote: > > > On Sat, Oct 23, 2010 at 9:21 PM, Daniel Wagner wrote: > > On Oct 23, 2010, at 10:48 PM, Charles R Harris wrote: > >> >> >> On Sat, Oct 23, 2010 at 8:33 PM, Daniel Wagner wrote: >>> On Sat, Oct 23, 2010 at 7:00 PM, Daniel Wagner wrote: >>> Hi, >>> >>> I'm a new subscriber of this list. I hope to directly start with a question is ok... >>> >>> My question or problem: >>> I've a matrix A which is calculated from the data b. The shapes of these matrices are: >>> >>>A.shape >>> (954, 9) >>> >>>b.shape >>> (954,) >>> >>> I calculate the SVD of A: >>> >>> U, w, V = numpy.linalg.svd(A, full_matrices="True") >>> >>>U.shape >>> (954, 954) >>> >>> You want full_matrices set false so that U has shape (954, 9). >>> >> thanks! I tried it before with "False" as a string but of course this couldn't work. omgh. (no error message?) >> Now I'm using: >> >>>U, w, V = numpy.linalg.svd(yz_matrix_by, full_matrices=False) >> >>> >>>W.diag(w) >>> >>>W.shape >>> (9,9) >>> >>>V.shape >>> (9,9) >>> >>> If I'm doing the check of the SVD results using: >>> >>>numpy.allclose(A, numpy.dot(U, numpy.dot(W, V))) >>> I get this error: >>> >>> easier, allclose(A, dot(U*w, V) ) >>> >> That's right! >> >>> >>> "ValueError: matrices are not aligned" >>> >>> >>> Mismatched dimensions. >>> >> >> Yeah, this error is away. Now I get: >> >>>print(numpy.allclose(U_by*w_by, V_by)) >> False >> >> >> Seems to be a missing "dot" in there. >> > > The following works: > >>>numpy.allclose(A, numpy.dot(U, numpy.dot(W, V))) > True > > But now I've a new problem problem: > > When I'm using: > > >>> A.shape > (954, 9) > >>> b.shape > (954, ) > >>> temp = numpy.linalg.pinv(A, rcond=1.0000000000000001e-15) > >>> temp.shape > (9, 954) > > to multiply this with my data b > >>>x = numpy.dot(temp, b) > ValueError: matrices are not aligned > > I've missmatched dimensions again.... > > > Looks like you might want to look at lstsq. > It works like a charm! The next time I really should use the already implemented functions and if I'm unsure how they work I still can take a look into their source code... Thank you for the hint! Greetings, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Sun Oct 24 04:29:29 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Sun, 24 Oct 2010 04:29:29 -0400 Subject: [Numpy-discussion] SVD problem - matrices are not aligned In-Reply-To: References: <69850AF6-EE6D-4E67-8FA4-284EDCF079B5@googlemail.com> <59846635-10A2-4743-9AD1-F967D6993EEF@googlemail.com> Message-ID: On Sat, Oct 23, 2010 at 11:47 PM, Daniel Wagner wrote: > > On Oct 23, 2010, at 11:25 PM, Charles R Harris wrote: > > > On Sat, Oct 23, 2010 at 9:21 PM, Daniel Wagner > wrote: >> >> On Oct 23, 2010, at 10:48 PM, Charles R Harris wrote: >> >> >> On Sat, Oct 23, 2010 at 8:33 PM, Daniel Wagner >> wrote: >>> >>> On Sat, Oct 23, 2010 at 7:00 PM, Daniel Wagner >>> wrote: >>>> >>>> Hi, >>>> >>>> I'm a new subscriber of this list. I hope to directly start with a >>>> question is ok... >>>> >>>> My question or problem: >>>> I've a matrix A which is calculated from the data b. The shapes of these >>>> matrices are: >>>> >>>A.shape >>>> (954, 9) >>>> >>>b.shape >>>> (954,) >>>> >>>> I calculate the SVD of A: >>>> >>> U, w, V = numpy.linalg.svd(A, full_matrices="True") >>>> >>>U.shape >>>> (954, 954) >>> >>> You want full_matrices set false so that U has shape (954, 9). >>> >>> >>> thanks! I tried it before with "False" as a string but of course this >>> couldn't work. omgh. (no error message?) >>> Now I'm using: >>> >>>U, w, V = numpy.linalg.svd(yz_matrix_by, full_matrices=False) >>>> >>>> >>>W.diag(w) >>>> >>>W.shape >>>> (9,9) >>>> >>>V.shape >>>> (9,9) >>>> >>>> If I'm doing the check of the SVD results using: >>>> >>>numpy.allclose(A, numpy.dot(U, numpy.dot(W, V))) >>>> I get this error: >>> >>> easier, allclose(A, dot(U*w, V) ) >>> >>> That's right! >>> >>>> "ValueError: matrices are not aligned" >>>> >>> >>> Mismatched dimensions. >>> >>> Yeah, this error is away. Now I get: >>> ?>>>print(numpy.allclose(U_by*w_by, V_by)) >>> False >> >> Seems to be a missing "dot" in there. >> >> The following works: >> >>>numpy.allclose(A, numpy.dot(U, numpy.dot(W, V))) >> True >> But now I've a new problem problem: >> When I'm using: >> >>> A.shape >> (954, 9) >> >>> b.shape >> (954, ) >> >>> temp = numpy.linalg.pinv(A, rcond=1.0000000000000001e-15) >> >>> temp.shape >> (9, 954) >> to multiply this with my data b >> >>>x = numpy.dot(temp, b) >> ValueError: matrices are not aligned >> I've missmatched dimensions again.... > > Looks like you might want to look at lstsq. > > It works like a charm! The next time I really should use the already > implemented functions and if I'm unsure how they work I still can take a > look into their source code... > Thank you for the hint! I'm just going the other way, using pinv and leastsq, and now switch to decomposition directly. >From what I can see the main difference in your example to what I have is to use linalg.diagsvd u,s,v = np.linalg.svd(x, full_matrices=1) Sig = linalg.diagsvd(s,*x.shape) >>> np.max(np.abs(np.dot(u, np.dot(Sig, v)) - x)) 3.1086244689504383e-015 for the correct shapes of the sqrt of the x'x and xx': >>> us = np.dot(u, Sig) >>> np.max(np.abs(np.dot(us, us.T) - np.dot(x, x.T))) 1.0658141036401503e-014 >>> sv = np.dot(Sig, v) >>> np.max(np.abs(np.dot(sv.T, sv) - np.dot(x.T, x))) 1.1368683772161603e-013 I'm still trying to collect these things into a class. statsmodels is doing all the least square calculations with linalg.pinv directly, I thought your pinv example should work, you could also try with explicit 2dimensional b >>>x = numpy.dot(temp, b{:,None) (scikits.learn Bayesian Ridge regression is also a good example how to do regression with svd directly) Josef > Greetings, > Daniel > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > From butterw at gmail.com Sun Oct 24 04:41:54 2010 From: butterw at gmail.com (Peter Butterworth) Date: Sun, 24 Oct 2010 10:41:54 +0200 Subject: [Numpy-discussion] np.dtype(int) 64bit In-Reply-To: References: Message-ID: thanks for the clarification. I haven't found any complete guide on the subject, but it does appear there are a some potential gotchas with using numpy 64bit on windows (result type is not what the user might expect). >>> np.shape([1, 5, 4]) (3L,) Is there a clear performance advantage for numpy 64bit over numpy 32bit on 64 bit windows ? I might be tempted to go back to 32bit python to Looks correct. CPython's 'int' is implemented as 'long' in C, which is 32 bit on Windows (LLP64 model) and 64 bit on other systems (LP64, etc). The function argmin() returns an index, which is implemented as 'Py_ssize_t' in C and is 64 bit on all 64 bit systems. -- Christoph -- thanks, peter butterworth From daniel.wagner.ml at googlemail.com Sun Oct 24 10:16:04 2010 From: daniel.wagner.ml at googlemail.com (Daniel Wagner) Date: Sun, 24 Oct 2010 10:16:04 -0400 Subject: [Numpy-discussion] SVD problem - matrices are not aligned In-Reply-To: References: <69850AF6-EE6D-4E67-8FA4-284EDCF079B5@googlemail.com> <59846635-10A2-4743-9AD1-F967D6993EEF@googlemail.com> Message-ID: On Oct 24, 2010, at 4:29 AM, josef.pktd at gmail.com wrote: > On Sat, Oct 23, 2010 at 11:47 PM, Daniel Wagner > wrote: >> >> On Oct 23, 2010, at 11:25 PM, Charles R Harris wrote: >> >> >> On Sat, Oct 23, 2010 at 9:21 PM, Daniel Wagner >> wrote: >>> >>> On Oct 23, 2010, at 10:48 PM, Charles R Harris wrote: >>> >>> >>> On Sat, Oct 23, 2010 at 8:33 PM, Daniel Wagner >>> wrote: >>>> >>>> On Sat, Oct 23, 2010 at 7:00 PM, Daniel Wagner >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I'm a new subscriber of this list. I hope to directly start with a >>>>> question is ok... >>>>> >>>>> My question or problem: >>>>> I've a matrix A which is calculated from the data b. The shapes of these >>>>> matrices are: >>>>>>>> A.shape >>>>> (954, 9) >>>>>>>> b.shape >>>>> (954,) >>>>> >>>>> I calculate the SVD of A: >>>>>>>> U, w, V = numpy.linalg.svd(A, full_matrices="True") >>>>>>>> U.shape >>>>> (954, 954) >>>> >>>> You want full_matrices set false so that U has shape (954, 9). >>>> >>>> >>>> thanks! I tried it before with "False" as a string but of course this >>>> couldn't work. omgh. (no error message?) >>>> Now I'm using: >>>>>>> U, w, V = numpy.linalg.svd(yz_matrix_by, full_matrices=False) >>>>> >>>>>>>> W.diag(w) >>>>>>>> W.shape >>>>> (9,9) >>>>>>>> V.shape >>>>> (9,9) >>>>> >>>>> If I'm doing the check of the SVD results using: >>>>>>>> numpy.allclose(A, numpy.dot(U, numpy.dot(W, V))) >>>>> I get this error: >>>> >>>> easier, allclose(A, dot(U*w, V) ) >>>> >>>> That's right! >>>> >>>>> "ValueError: matrices are not aligned" >>>>> >>>> >>>> Mismatched dimensions. >>>> >>>> Yeah, this error is away. Now I get: >>>> >>>print(numpy.allclose(U_by*w_by, V_by)) >>>> False >>> >>> Seems to be a missing "dot" in there. >>> >>> The following works: >>>>>> numpy.allclose(A, numpy.dot(U, numpy.dot(W, V))) >>> True >>> But now I've a new problem problem: >>> When I'm using: >>>>>> A.shape >>> (954, 9) >>>>>> b.shape >>> (954, ) >>>>>> temp = numpy.linalg.pinv(A, rcond=1.0000000000000001e-15) >>>>>> temp.shape >>> (9, 954) >>> to multiply this with my data b >>>>>> x = numpy.dot(temp, b) >>> ValueError: matrices are not aligned >>> I've missmatched dimensions again.... >> >> Looks like you might want to look at lstsq. >> >> It works like a charm! The next time I really should use the already >> implemented functions and if I'm unsure how they work I still can take a >> look into their source code... >> Thank you for the hint! > > > I'm just going the other way, using pinv and leastsq, and now switch > to decomposition directly. > >> From what I can see the main difference in your example to what I > have is to use linalg.diagsvd > > u,s,v = np.linalg.svd(x, full_matrices=1) > Sig = linalg.diagsvd(s,*x.shape) > >>>> np.max(np.abs(np.dot(u, np.dot(Sig, v)) - x)) > 3.1086244689504383e-015 > > for the correct shapes of the sqrt of the x'x and xx': > >>>> us = np.dot(u, Sig) >>>> np.max(np.abs(np.dot(us, us.T) - np.dot(x, x.T))) > 1.0658141036401503e-014 > >>>> sv = np.dot(Sig, v) >>>> np.max(np.abs(np.dot(sv.T, sv) - np.dot(x.T, x))) > 1.1368683772161603e-013 > > > I'm still trying to collect these things into a class. > > statsmodels is doing all the least square calculations with > linalg.pinv directly, > > I thought your pinv example should work, you could also try with > explicit 2dimensional b > >>>> x = numpy.dot(temp, b{:,None) Thanks, this works: >>>x2 = x = numpy.dot(temp, b[:,None]) Greetings, Daniel From dsdale24 at gmail.com Sun Oct 24 11:22:13 2010 From: dsdale24 at gmail.com (Darren Dale) Date: Sun, 24 Oct 2010 11:22:13 -0400 Subject: [Numpy-discussion] ANN: NumPy 1.5.1 release candidate 1 In-Reply-To: References: Message-ID: On Sun, Oct 17, 2010 at 7:35 AM, Ralf Gommers wrote: > Hi, > > I am pleased to announce the availability of the first release > candidate of NumPy 1.5.1. This is a bug-fix release with no new > features compared to 1.5.0. [...] > Please report any other issues on the Numpy-discussion mailing list. Just installed on kubuntu-10.10, python-2.7 and python-3.1.2. Tests look fine for py2.7, but I see datetime errors with py3k: . ====================================================================== ERROR: test_creation (test_datetime.TestDateTime) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", line 10, in test_creation dt1 = np.dtype('M8[750%s]'%unit) TypeError: data type not understood ====================================================================== ERROR: test_creation_overflow (test_datetime.TestDateTime) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", line 62, in test_creation_overflow timesteps = np.array([date], dtype='datetime64[s]')[0].astype(np.int64) TypeError: data type not understood ====================================================================== ERROR: test_divisor_conversion_as (test_datetime.TestDateTime) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", line 58, in test_divisor_conversion_as self.assertRaises(ValueError, lambda : np.dtype('M8[as/10]')) File "/usr/lib/python3.1/unittest.py", line 589, in assertRaises callableObj(*args, **kwargs) File "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", line 58, in self.assertRaises(ValueError, lambda : np.dtype('M8[as/10]')) TypeError: data type not understood ====================================================================== ERROR: test_divisor_conversion_bday (test_datetime.TestDateTime) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", line 32, in test_divisor_conversion_bday assert np.dtype('M8[B/12]') == np.dtype('M8[2h]') TypeError: data type not understood ====================================================================== ERROR: test_divisor_conversion_day (test_datetime.TestDateTime) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", line 37, in test_divisor_conversion_day assert np.dtype('M8[D/12]') == np.dtype('M8[2h]') TypeError: data type not understood ====================================================================== ERROR: test_divisor_conversion_fs (test_datetime.TestDateTime) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", line 54, in test_divisor_conversion_fs assert np.dtype('M8[fs/100]') == np.dtype('M8[10as]') TypeError: data type not understood ====================================================================== ERROR: test_divisor_conversion_hour (test_datetime.TestDateTime) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", line 42, in test_divisor_conversion_hour assert np.dtype('m8[h/30]') == np.dtype('m8[2m]') TypeError: data type not understood ====================================================================== ERROR: test_divisor_conversion_minute (test_datetime.TestDateTime) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", line 46, in test_divisor_conversion_minute assert np.dtype('m8[m/30]') == np.dtype('m8[2s]') TypeError: data type not understood ====================================================================== ERROR: test_divisor_conversion_month (test_datetime.TestDateTime) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", line 21, in test_divisor_conversion_month assert np.dtype('M8[M/2]') == np.dtype('M8[2W]') TypeError: data type not understood ====================================================================== ERROR: test_divisor_conversion_second (test_datetime.TestDateTime) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", line 50, in test_divisor_conversion_second assert np.dtype('m8[s/100]') == np.dtype('m8[10ms]') TypeError: data type not understood ====================================================================== ERROR: test_divisor_conversion_week (test_datetime.TestDateTime) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", line 26, in test_divisor_conversion_week assert np.dtype('m8[W/5]') == np.dtype('m8[B]') TypeError: data type not understood ====================================================================== ERROR: test_divisor_conversion_year (test_datetime.TestDateTime) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", line 16, in test_divisor_conversion_year assert np.dtype('M8[Y/4]') == np.dtype('M8[3M]') TypeError: data type not understood ---------------------------------------------------------------------- Ran 3061 tests in 19.197s FAILED (KNOWNFAIL=5, SKIP=4, errors=12) From charlesr.harris at gmail.com Sun Oct 24 11:29:45 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Sun, 24 Oct 2010 09:29:45 -0600 Subject: [Numpy-discussion] ANN: NumPy 1.5.1 release candidate 1 In-Reply-To: References: Message-ID: On Sun, Oct 24, 2010 at 9:22 AM, Darren Dale wrote: > On Sun, Oct 17, 2010 at 7:35 AM, Ralf Gommers > wrote: > > Hi, > > > > I am pleased to announce the availability of the first release > > candidate of NumPy 1.5.1. This is a bug-fix release with no new > > features compared to 1.5.0. > [...] > > Please report any other issues on the Numpy-discussion mailing list. > > Just installed on kubuntu-10.10, python-2.7 and python-3.1.2. Tests > look fine for py2.7, but I see datetime errors with py3k: > > . > ====================================================================== > ERROR: test_creation (test_datetime.TestDateTime) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", > line 10, in test_creation > dt1 = np.dtype('M8[750%s]'%unit) > TypeError: data type not understood > > ====================================================================== > ERROR: test_creation_overflow (test_datetime.TestDateTime) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", > line 62, in test_creation_overflow > timesteps = np.array([date], dtype='datetime64[s]')[0].astype(np.int64) > TypeError: data type not understood > > ====================================================================== > ERROR: test_divisor_conversion_as (test_datetime.TestDateTime) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", > line 58, in test_divisor_conversion_as > self.assertRaises(ValueError, lambda : np.dtype('M8[as/10]')) > File "/usr/lib/python3.1/unittest.py", line 589, in assertRaises > callableObj(*args, **kwargs) > File > "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", > line 58, in > self.assertRaises(ValueError, lambda : np.dtype('M8[as/10]')) > TypeError: data type not understood > > ====================================================================== > ERROR: test_divisor_conversion_bday (test_datetime.TestDateTime) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", > line 32, in test_divisor_conversion_bday > assert np.dtype('M8[B/12]') == np.dtype('M8[2h]') > TypeError: data type not understood > > ====================================================================== > ERROR: test_divisor_conversion_day (test_datetime.TestDateTime) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", > line 37, in test_divisor_conversion_day > assert np.dtype('M8[D/12]') == np.dtype('M8[2h]') > TypeError: data type not understood > > ====================================================================== > ERROR: test_divisor_conversion_fs (test_datetime.TestDateTime) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", > line 54, in test_divisor_conversion_fs > assert np.dtype('M8[fs/100]') == np.dtype('M8[10as]') > TypeError: data type not understood > > ====================================================================== > ERROR: test_divisor_conversion_hour (test_datetime.TestDateTime) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", > line 42, in test_divisor_conversion_hour > assert np.dtype('m8[h/30]') == np.dtype('m8[2m]') > TypeError: data type not understood > > ====================================================================== > ERROR: test_divisor_conversion_minute (test_datetime.TestDateTime) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", > line 46, in test_divisor_conversion_minute > assert np.dtype('m8[m/30]') == np.dtype('m8[2s]') > TypeError: data type not understood > > ====================================================================== > ERROR: test_divisor_conversion_month (test_datetime.TestDateTime) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", > line 21, in test_divisor_conversion_month > assert np.dtype('M8[M/2]') == np.dtype('M8[2W]') > TypeError: data type not understood > > ====================================================================== > ERROR: test_divisor_conversion_second (test_datetime.TestDateTime) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", > line 50, in test_divisor_conversion_second > assert np.dtype('m8[s/100]') == np.dtype('m8[10ms]') > TypeError: data type not understood > > ====================================================================== > ERROR: test_divisor_conversion_week (test_datetime.TestDateTime) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", > line 26, in test_divisor_conversion_week > assert np.dtype('m8[W/5]') == np.dtype('m8[B]') > TypeError: data type not understood > > ====================================================================== > ERROR: test_divisor_conversion_year (test_datetime.TestDateTime) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", > line 16, in test_divisor_conversion_year > assert np.dtype('M8[Y/4]') == np.dtype('M8[3M]') > TypeError: data type not understood > > ---------------------------------------------------------------------- > Ran 3061 tests in 19.197s > > FAILED (KNOWNFAIL=5, SKIP=4, errors=12) > > ____ You may have left over tests in the installation directory. Can you try deleting it and installing again? Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsdale24 at gmail.com Sun Oct 24 11:40:33 2010 From: dsdale24 at gmail.com (Darren Dale) Date: Sun, 24 Oct 2010 11:40:33 -0400 Subject: [Numpy-discussion] ANN: NumPy 1.5.1 release candidate 1 In-Reply-To: References: Message-ID: On Sun, Oct 24, 2010 at 11:29 AM, Charles R Harris wrote: > > > On Sun, Oct 24, 2010 at 9:22 AM, Darren Dale wrote: >> >> On Sun, Oct 17, 2010 at 7:35 AM, Ralf Gommers >> wrote: >> > Hi, >> > >> > I am pleased to announce the availability of the first release >> > candidate of NumPy 1.5.1. This is a bug-fix release with no new >> > features compared to 1.5.0. >> [...] >> > Please report any other issues on the Numpy-discussion mailing list. >> >> Just installed on kubuntu-10.10, python-2.7 and python-3.1.2. Tests >> look fine for py2.7, but I see datetime errors with py3k: [...] > > You may have left over tests in the installation directory. Can you try > deleting it and installing again? You're right. Tests are passing. Darren From cgohlke at uci.edu Sun Oct 24 12:48:30 2010 From: cgohlke at uci.edu (Christoph Gohlke) Date: Sun, 24 Oct 2010 09:48:30 -0700 Subject: [Numpy-discussion] np.dtype(int) 64bit In-Reply-To: References: Message-ID: <4CC4635E.8090800@uci.edu> On 10/24/2010 1:41 AM, Peter Butterworth wrote: > thanks for the clarification. > > I haven't found any complete guide on the subject, but it does appear > there are a some potential gotchas with using numpy 64bit on windows > (result type is not what the user might expect). > >>>> np.shape([1, 5, 4]) > (3L,) Correct and expected. Anyway, long integers and integer types have been unified in Python 3 (PEP 237). > > Is there a clear performance advantage for numpy 64bit over numpy > 32bit on 64 bit windows ? I might be tempted to go back to 32bit > python to It depends. You would have to benchmark your code. 64 bit code can actually be slower. But meeting wrong user expectations is not a comprehensible reason to me. > > > > > Looks correct. CPython's 'int' is implemented as 'long' in C, which is > 32 bit on Windows (LLP64 model) and 64 bit on other systems (LP64, etc). > The function argmin() returns an index, which is implemented as > 'Py_ssize_t' in C and is 64 bit on all 64 bit systems. > > -- > Christoph > > -- Christoph From gael.varoquaux at normalesup.org Sun Oct 24 17:53:05 2010 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Sun, 24 Oct 2010 23:53:05 +0200 Subject: [Numpy-discussion] [ANN]: FEMTEC 2011: track on Open-source projects and Python in scientific computing. Message-ID: <20101024215305.GG18057@phare.normalesup.org> The 3rd International Conference on Finite Element Methods in Engineering and Science (FEMTEC 2011, http://hpfem.org/events/femtec-2011/) will have a track on Open-source projects and Python in scientific computing. FEMTEC 2011 is co-organized by the University of Nevada (Reno), Desert Reseach Institute (Reno), Idaho National Laboratory (Idaho Falls, Idaho), and U.S. Army Engineer Research and Development Center (Vicksburg, Mississippi). The objective of the meeting is to strengthen the interaction between researchers who develop new computational methods, and scientists and engineers from various fields who employ numerical methods in their research. Specific focus areas of FEMTEC 2011 include, but are not limited to, the following: * Computational methods in hydrology, atmospheric modeling, and other earth sciences. * Computational methods in nuclear, mechanical, civil, electrical, and other engineering fields. * Mesh generation and scientific visualization. * Open-source projects and Python in scientific computing. Part of the conference will be a software afternoon featuring open source projects of participants. Proceedings Proceedings of FEMTEC 2011 will appear as a special issue of Journal of Computational and Applied Mathematics (2008 SCI impact factor 1.292), and additional high-impact international journals as needed. ____________ On a personnal note, I was at ESCO 2010 this year, the European version organized by the same community, and it was really a refreshing and friendly conference during which I learned a lot. From ralf.gommers at googlemail.com Sun Oct 24 20:17:25 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Mon, 25 Oct 2010 08:17:25 +0800 Subject: [Numpy-discussion] tests fails when run $nosetests numpy, but not from python prompt In-Reply-To: References: Message-ID: On Sun, Oct 24, 2010 at 2:44 AM, Vincent Davis wrote: > python2.7 10.5, osx 10.6, numpy 1.5.1rc1 > Test pass when run from python prompt (see bottom) but fail when run > from $nosetests numpy. That is expected, see http://article.gmane.org/gmane.comp.python.numeric.general/40781. Cheers, Ralf > > 105osxpython:~ Vincent$ nosetests numpy > .........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................E........................................................................................................................................................................................................................................E......................Warning: > overflow encountered in ldexp > .......................................................................E......................E...........................................................................................EEEEEE...................................................................................................................................................................................................................................................................................................................................................................................EEEEEEEEEE.EE.............................................................................................................................................................................................................................................................................................................................................................................................................................. > ?............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................S................................................................................................................................................................................................................................................................................................................................................................................ > ?............................................................................................................................................................................................................................................................................................................................. > ====================================================================== > ERROR: test_array_from_sequence_scalar_array2 (test_regression.TestRegression) > Ticket #1081: weird array with strange input... > ---------------------------------------------------------------------- > Traceback (most recent call last): > ?File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/testing/decorators.py", > line 213, in knownfailer > ? ?raise KnownFailureTest, msg > KnownFailureTest: Fix this for 1.5.0. > From josef.pktd at gmail.com Sun Oct 24 20:29:44 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Sun, 24 Oct 2010 20:29:44 -0400 Subject: [Numpy-discussion] tests fails when run $nosetests numpy, but not from python prompt In-Reply-To: References: Message-ID: On Sun, Oct 24, 2010 at 8:17 PM, Ralf Gommers wrote: > On Sun, Oct 24, 2010 at 2:44 AM, Vincent Davis wrote: >> python2.7 10.5, osx 10.6, numpy 1.5.1rc1 >> Test pass when run from python prompt (see bottom) but fail when run >> from $nosetests numpy. > > That is expected, see > http://article.gmane.org/gmane.comp.python.numeric.general/40781. That only applies to the first group of tests, On the commandline he has 19 additional test compared to numpy.test() and failures like /tmp/tmpOjoP4S/_test_ext_module_5403.so: mach-o, but wrong architecture Are there tests in numpy.test() that are skipped for some other reason (e.g. decorated as slow) ? Josef > > Cheers, > Ralf > > >> >> 105osxpython:~ Vincent$ nosetests numpy >> .........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................E........................................................................................................................................................................................................................................E......................Warning: >> overflow encountered in ldexp >> .......................................................................E......................E...........................................................................................EEEEEE...................................................................................................................................................................................................................................................................................................................................................................................EEEEEEEEEE.EE.............................................................................................................................................................................................................................................................................................................................................................................................................................. >> ?............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................S................................................................................................................................................................................................................................................................................................................................................................................ >> ?............................................................................................................................................................................................................................................................................................................................. >> ====================================================================== >> ERROR: test_array_from_sequence_scalar_array2 (test_regression.TestRegression) >> Ticket #1081: weird array with strange input... >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> ?File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/testing/decorators.py", >> line 213, in knownfailer >> ? ?raise KnownFailureTest, msg >> KnownFailureTest: Fix this for 1.5.0. >> > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > From vincent at vincentdavis.net Sun Oct 24 22:37:09 2010 From: vincent at vincentdavis.net (Vincent Davis) Date: Sun, 24 Oct 2010 20:37:09 -0600 Subject: [Numpy-discussion] tests fails when run $nosetests numpy, but not from python prompt In-Reply-To: References: Message-ID: On Sun, Oct 24, 2010 at 6:29 PM, wrote: > On Sun, Oct 24, 2010 at 8:17 PM, Ralf Gommers > wrote: >> On Sun, Oct 24, 2010 at 2:44 AM, Vincent Davis wrote: >>> python2.7 10.5, osx 10.6, numpy 1.5.1rc1 >>> Test pass when run from python prompt (see bottom) but fail when run >>> from $nosetests numpy. >> >> That is expected, see >> http://article.gmane.org/gmane.comp.python.numeric.general/40781. > > That only applies to the first group of tests, > On the commandline he has 19 additional test compared to numpy.test() > and failures like > > /tmp/tmpOjoP4S/_test_ext_module_5403.so: mach-o, but wrong architecture > > Are there tests in numpy.test() that are skipped for some other reason > (e.g. decorated as slow) ? A little more looking into this I think it might be a osx issue. I can't seem to find it now but nosetests runs the following /Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app I am guessing that Python.app loads the wrong python (python2.7 or python2.7-32) or something like that. It might be that this is more of a nose python2.7 issue. Vincent > > Josef > > >> >> Cheers, >> Ralf >> >> >>> >>> 105osxpython:~ Vincent$ nosetests numpy >>> .........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................E........................................................................................................................................................................................................................................E......................Warning: >>> overflow encountered in ldexp >>> .......................................................................E......................E...........................................................................................EEEEEE...................................................................................................................................................................................................................................................................................................................................................................................EEEEEEEEEE.EE.............................................................................................................................................................................................................................................................................................................................................................................................................................. >>> ?............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................S................................................................................................................................................................................................................................................................................................................................................................................ >>> ?............................................................................................................................................................................................................................................................................................................................. >>> ====================================================================== >>> ERROR: test_array_from_sequence_scalar_array2 (test_regression.TestRegression) >>> Ticket #1081: weird array with strange input... >>> ---------------------------------------------------------------------- >>> Traceback (most recent call last): >>> ?File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/testing/decorators.py", >>> line 213, in knownfailer >>> ? ?raise KnownFailureTest, msg >>> KnownFailureTest: Fix this for 1.5.0. >>> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -- Thanks Vincent Davis 720-301-3003 From thkoe002 at gmail.com Mon Oct 25 05:39:54 2010 From: thkoe002 at gmail.com (=?ISO-8859-1?Q?Thomas_K=F6nigstein?=) Date: Mon, 25 Oct 2010 11:39:54 +0200 Subject: [Numpy-discussion] [numpy-discussion] Transform 3d data In-Reply-To: References: Message-ID: Wow, thanks a million, this worked just fine and I think I understood at least parts of the method :) Cheers Thomas * On Tue, 2010-10-19 at 14:20 +0200, Nadav Horesh wrote: > Of course there is an (at least one) error: * > the line should be: > > XYZ = > np.mgrid[lwrbnd[0]:uprbnd[0]:shape[0]*1j,lwrbnd[1]:uprbnd[1]:shape[1]*1j, lwrbnd[2]:uprbnd[2]:shape[2]*1j] > On Tue, 2010-10-19 at 14:10 +0200, Nadav Horesh wrote: > >* You can aid mgrid, riughy as the follows (I may have mistakes, but the*> >* direction should be clear):*> >* *> >* def transform_3d_data_(field,lwrbnd,uprbnd): *> >* shape = field.shape *> >* XYZ = np.mgrid[lwrbnd[0]:uprbnd[0]:shape[0],*> >* lwrbnd[1]:uprbnd[1]:shape[1], lwrbnd[2]:uprbnd[2]:shape[2]] *>* ** > ** vectors = fields.reshape(-1,3) * > >* np.savetxt(np.hstack((XYZ.reshape(3,-1).T, vectors)))*> >* *> >* *> >* Nadav * -------------- next part -------------- An HTML attachment was scrubbed... URL: From friedrichromstedt at gmail.com Mon Oct 25 05:40:21 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Mon, 25 Oct 2010 11:40:21 +0200 Subject: [Numpy-discussion] tests fails when run $nosetests numpy, but not from python prompt In-Reply-To: References: Message-ID: 2010/10/25 Vincent Davis : > On Sun, Oct 24, 2010 at 6:29 PM, ? wrote: >> On Sun, Oct 24, 2010 at 8:17 PM, Ralf Gommers >> wrote: >>> On Sun, Oct 24, 2010 at 2:44 AM, Vincent Davis wrote: >>>> python2.7 10.5, osx 10.6, numpy 1.5.1rc1 >>>> Test pass when run from python prompt (see bottom) but fail when run >>>> from $nosetests numpy. >>> >>> That is expected, see >>> http://article.gmane.org/gmane.comp.python.numeric.general/40781. >> >> That only applies to the first group of tests, >> On the commandline he has 19 additional test compared to numpy.test() >> and failures like >> >> /tmp/tmpOjoP4S/_test_ext_module_5403.so: mach-o, but wrong architecture >> >> Are there tests in numpy.test() that are skipped for some other reason >> (e.g. decorated as slow) ? > > A little more looking into this I think it might be a osx issue. I > can't seem to find it now but nosetests runs the following > /Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app > I am guessing that Python.app loads the wrong python (python2.7 or > python2.7-32) ?or something like that. It might be that this is more > of a nose python2.7 issue. 105osxpython:numpy Friedrich$ head /Library/Frameworks/Python.framework/Versions/2.7/bin/nosetests #!/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python Same applies to the 2.6 & 2.5 :file:`nosetests`. At least for the 2.7, the MacOS/Python called has different size than the bin/python2.7 cmd line executable. So it's simply something completely different. Still it makes the errors not explained. I remember Ralf's post cited by himself. FYI, the MacOS/Python executable has all three archs. We came to the conclusion, so simple not use nosetests, and to leave this mysterious issue to later, I will document it on the numpy build doc web site. Friedrich From friedrichromstedt at gmail.com Mon Oct 25 06:08:27 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Mon, 25 Oct 2010 12:08:27 +0200 Subject: [Numpy-discussion] Build Process and Version Control Message-ID: Hi, here is a summary of what we got so far with the Mac OS X build process: - We found it useful to put /Library/Frameworks/Python.framework/Versions/2.x under version control with git. This lets us get rid of the paver bootstrap thingy, since we just switch to a branch via ``git checkout numpy``. We can have a full-blown polluted Python and a minimial numpy Python in parallel, and we can revert to the built numpy libraries when we find some issue later. We will note the sha of the numpy system commit in the commits in the numpy build git repo. - We also modified the Pythons via a print statement in sitecustomize.py to tell what numpy is running on startup, this goes to the logfiles etc., it also tells the branch family of the system git repo (hardcoded). - We established a numpy git "build repo". It'll contain all the dmgs and so on, along with the log files of the build process. I will push soon. Its location is http://github.com/friedrichromstedt/numpy. We tried hard to make good design choices about the branches, but this is discussable, and might be easy to revert in this early stage where noone has fetched so far. - We also set up the "numpy build site", it's here: http://vincentdavis.info/, or for the hard-core people here :-) http://vincentdavis.info/numpy-build-doc. It's not that hard-core at all. Just a Sphinx site where we document what we're doing to our build system. Atm I'm not *that* satisfied with it, because I tend to document *too much* when new to some subject. I believe it will turn out as a well-readable detailed instruction for ourselves, usable to others too, and then we just crossref that instruction instead of writing down all the stuff again and again. Currently the numpy-build-docs are in another repo, http://github.com/friedrichromstedt/numpy-build-doc, I'm not sure if it is useful to merge this into my numpy repo. Pro: Users of the numpy repo will get all the stuff with little overhead. Con: Users of the numpy-build-doc repo will have *lots* of overhead. But I guess the latter are rather rare. Please comment. The process is open for others to chime in. The Sphinx site is ready to host also build logs of other systems. The sources are included in the git repo (numpy-build-docs), together with a current html build. Please use the Sphinx site online (http://vincentdavis.info/numpy-build-doc) and not the git repo, but I'll push soon. Documentation goes via Python functional programming, but this are details. In fact, Sphinx just documents Python functions. We are working towards an automatisation of build process steps using this Python functions. Yet another build system. But this is future. Please refrain from fetching anything until I did the authoritative push, so that you'll have a working system, which is at least beta and not rather alpha like the current things I put on github. Friedrich From aka.tkf at gmail.com Mon Oct 25 07:22:39 2010 From: aka.tkf at gmail.com (Takafumi Arakaki) Date: Mon, 25 Oct 2010 13:22:39 +0200 Subject: [Numpy-discussion] RailGun: ctypes utilities for faster and easier simulation programming in C and Python - announcement Message-ID: I hope this mailing list is right place to post. Please read full document here: http://tkf.bitbucket.org/railgun-doc/index.html RailGun: Accelerate your simulation programing with "C on Rails" ================================================================ Overview -------- RailGun is ctypes utilities for faster and easier simulation programming in C and Python. It requires constraint to C library loaded from Python and gives you automatically generated Python class which calls C functions safely. Installation ------------ :: easy_install railgun # using setuptools pip install railgun # using pip Usage ----- Please read `document `_ and `samples `_. Requirement ----------- - Numpy - (matplotlib for sample code) Sincerely, Takafumi Arakaki --- Master course student Department of Modern Mechanical Engineering Waseda University Laboratory of Neurophysics and Physiology Universite Paris Descartes From friedrichromstedt at gmail.com Mon Oct 25 07:52:26 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Mon, 25 Oct 2010 13:52:26 +0200 Subject: [Numpy-discussion] clearing after build; Some directories missing in .gitignore? Message-ID: I was tearing my hear out yesterday evening with trying to find out and to understand how this directories occur in the build process and what role they play: build_doc/ doc/source/reference/generated/ The build process of the docs is rather opaque to me, so I don't know what to do with them. The question is: Do I really have to clean my working directory before doing a new build. I have problems with this because it seems that the cleaning is neither complete nor is .gitignore (see above). In pavement.py I read: @needs('clean', 'clean_bootstrap') def nuke(options): """Remove everything: build dir, installers, bootstrap dirs, etc...""" for d in [options.superpack.builddir, options.installers.releasedir]: if os.path.exists(d): shutil.rmtree(d) So :func:`nuke`, as opposed to what I was told before, also removes the installers. :func:`clean` removes build/, dist/, numpy.egg-info/, and doc/build/. :func:`clean_bootstrap` is a noop for us. None of them treats the directories listed above. I don't know if the generated docs in doc/source/reference/generated are included automatically, so that garbage from previous builds could make it into later doc builds? Further, I don't know what may dangle around what I simply don't see because it's hidden by .gitignore. E.g. what's about doc/cdoc/build? doc/numpy.scipy.org/_build? I don't have this dirs, though. I will, for now, just remove the directories listed above and hope that :func:`clean` does the rest to the extent needed, but I really have the impressions that the binary build system is rather "organic" and needs a general overhaul. A bit lost, Friedrich From lciti at essex.ac.uk Mon Oct 25 09:48:19 2010 From: lciti at essex.ac.uk (Citi, Luca) Date: Mon, 25 Oct 2010 13:48:19 +0000 Subject: [Numpy-discussion] speed of array vs matrix Message-ID: <703475E2E2A4E24C961A32C31C504DA602F82B2F@mbx2-node2.essex.ac.uk> Hello, I have noticed a significant speed difference between the array and the matrix implementation of the dot product, especially for not-so-big matrices. For example: In [1]: import numpy as np In [2]: b = np.random.rand(104,1) In [3]: bm = np.mat(b) In [4]: a = np.random.rand(8, 104) In [5]: am = np.mat(a) In [6]: %timeit np.dot(a, b) 1000000 loops, best of 3: 1.74 us per loop In [7]: %timeit am * bm 100000 loops, best of 3: 6.38 us per loop The results for two different PCs (PC1 with windows/EPD6.2-2 and PC2 with ubuntu/numpy-1.3.0) and two different sizes are below: array matrix 8x104 * 104x1 PC1 1.74us 6.38us PC2 1.23us 5.85us 8x10 * 10x5 PC1 2.38us 7.55us PC2 1.56us 6.01us For bigger matrices the timings seem to asymptotically approach. Is it something worth trying to fix or should I just accept this as a fact and, when working with small matrices, stick to array? Thanks, Luca From charlesr.harris at gmail.com Mon Oct 25 10:03:57 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Mon, 25 Oct 2010 08:03:57 -0600 Subject: [Numpy-discussion] speed of array vs matrix In-Reply-To: <703475E2E2A4E24C961A32C31C504DA602F82B2F@mbx2-node2.essex.ac.uk> References: <703475E2E2A4E24C961A32C31C504DA602F82B2F@mbx2-node2.essex.ac.uk> Message-ID: On Mon, Oct 25, 2010 at 7:48 AM, Citi, Luca wrote: > Hello, > I have noticed a significant speed difference between the array and the > matrix implementation of the dot product, especially for not-so-big > matrices. > For example: > > In [1]: import numpy as np > In [2]: b = np.random.rand(104,1) > In [3]: bm = np.mat(b) > In [4]: a = np.random.rand(8, 104) > In [5]: am = np.mat(a) > In [6]: %timeit np.dot(a, b) > 1000000 loops, best of 3: 1.74 us per loop > In [7]: %timeit am * bm > 100000 loops, best of 3: 6.38 us per loop > > The results for two different PCs (PC1 with windows/EPD6.2-2 and PC2 with > ubuntu/numpy-1.3.0) and two different sizes are below: > > array matrix > > 8x104 * 104x1 > PC1 1.74us 6.38us > PC2 1.23us 5.85us > > 8x10 * 10x5 > PC1 2.38us 7.55us > PC2 1.56us 6.01us > > For bigger matrices the timings seem to asymptotically approach. > > Is it something worth trying to fix or should I just accept this as a fact > and, when working with small matrices, stick to array? > > Looks like call overhead, it will become significant when the dot product itself doesn't take much time. If you want to spend time profiling it might be possible to find some spots in the matrix class that can be sped up. My guess is that it is the time taken to create the matrices. But if you don't want to get sidetracked sticking to arrays is the easy way to go. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From kwgoodman at gmail.com Mon Oct 25 10:04:48 2010 From: kwgoodman at gmail.com (Keith Goodman) Date: Mon, 25 Oct 2010 07:04:48 -0700 Subject: [Numpy-discussion] speed of array vs matrix In-Reply-To: <703475E2E2A4E24C961A32C31C504DA602F82B2F@mbx2-node2.essex.ac.uk> References: <703475E2E2A4E24C961A32C31C504DA602F82B2F@mbx2-node2.essex.ac.uk> Message-ID: On Mon, Oct 25, 2010 at 6:48 AM, Citi, Luca wrote: > Hello, > I have noticed a significant speed difference between the array and the matrix implementation of the dot product, especially for not-so-big matrices. > For example: > > In [1]: import numpy as np > In [2]: b = np.random.rand(104,1) > In [3]: bm = np.mat(b) > In [4]: a = np.random.rand(8, 104) > In [5]: am = np.mat(a) > In [6]: %timeit np.dot(a, b) > 1000000 loops, best of 3: 1.74 us per loop > In [7]: %timeit am * bm > 100000 loops, best of 3: 6.38 us per loop > > The results for two different PCs (PC1 with windows/EPD6.2-2 and PC2 with ubuntu/numpy-1.3.0) and two different sizes are below: > > ? ? ? ? ? array matrix > > 8x104 * 104x1 > PC1 ? ?1.74us ? 6.38us > PC2 ? ?1.23us ? 5.85us > > 8x10 * 10x5 > PC1 ? ?2.38us ? 7.55us > PC2 ? ?1.56us ? 6.01us > > For bigger matrices the timings seem to asymptotically approach. > > Is it something worth trying to fix or should I just accept this as a fact and, when working with small matrices, stick to array? I think the fixed overhead comes from the subclassing of arrays. The subclassing is done in Python and if an operation creates a matrix then __array_finalize__ is called. All that adds up to overhead. http://github.com/numpy/numpy/blob/master/numpy/matrixlib/defmatrix.py I wrote a mean-variance optimizer with matrices. Switching to arrays gave me a big speed up. From ralf.gommers at googlemail.com Mon Oct 25 10:13:06 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Mon, 25 Oct 2010 22:13:06 +0800 Subject: [Numpy-discussion] Build Process and Version Control In-Reply-To: References: Message-ID: Hi Friedrich, On Mon, Oct 25, 2010 at 6:08 PM, Friedrich Romstedt wrote: > Hi, > > here is a summary of what we got so far with the Mac OS X build process: Thanks for the detailed info on what you are doing. First maybe a general comment: the current release scripts work quite well, so it's probably not a very good idea to throw all that out. Also, I've tried to improve the docs on how the binaries are built and make them as complete as possible over the last half year, so I would appreciate you and Vincent pointing out any gaps or creating some patches to those docs. > > - ?We found it useful to put > /Library/Frameworks/Python.framework/Versions/2.x under version > control with git. ?This lets us get rid of the paver bootstrap thingy, > since we just switch to a branch via ``git checkout numpy``. >?We can have a full-blown polluted Python and a minimial numpy Python in > parallel, and we can revert to the built numpy libraries when we find > some issue later. ?We will note the sha of the numpy system commit in > the commits in the numpy build git repo. Not sure about the motivation here. Paver and virtualenv (the "bootstrap thingy") are widely used and relatively mature tools, why hack something together that does the same job? > > - ?We also modified the Pythons via a print statement in > sitecustomize.py to tell what numpy is running on startup, this goes > to the logfiles etc., it also tells the branch family of the system > git repo (hardcoded). First time I heard about this sitecustomize.py, sounds like not the most robust thing I've ever heard of... > > - ?We established a numpy git "build repo". ?It'll contain all the > dmgs and so on, along with the log files of the build process. I like the idea of recording all logs and having them accessible for later reference. Very large binaries under version control, less so. > ?I will push soon. ?Its location is http://github.com/friedrichromstedt/numpy. > ?We tried hard to make good design choices about the branches, but > this is discussable, and might be easy to revert in this early stage > where noone has fetched so far. > > - ?We also set up the "numpy build site", it's here: > http://vincentdavis.info/, or for the hard-core people here :-) > http://vincentdavis.info/numpy-build-doc. ?It's not that hard-core at > all. ?Just a Sphinx site where we document what we're doing to our > build system. ?Atm I'm not *that* satisfied with it, because I tend to > document *too much* when new to some subject. ?I believe it will turn > out as a well-readable detailed instruction for ourselves, usable to > others too, and then we just crossref that instruction instead of > writing down all the stuff again and again. > > Currently the numpy-build-docs are in another repo, > http://github.com/friedrichromstedt/numpy-build-doc, I'm not sure if > it is useful to merge this into my numpy repo. ?Pro: Users of the > numpy repo will get all the stuff with little overhead. ?Con: Users of > the numpy-build-doc repo will have *lots* of overhead. ?But I guess > the latter are rather rare. ?Please comment. Why not add to http://projects.scipy.org/numpy/wiki/MakingReleases? Or otherwise a new plain reST file under doc/. Between the docs in the git repo, the Trac wiki and the wiki on scipy.org I think we have enough places to add docs. And maintain them... Again, I appreciate your work and am not trying to stop you from making improvements. But please try to improve what's already there, or at least first point out why that is difficult so we can discuss. Cheers, Ralf > > The process is open for others to chime in. ?The Sphinx site is ready > to host also build logs of other systems. ?The sources are included in > the git repo (numpy-build-docs), together with a current html build. > Please use the Sphinx site online > (http://vincentdavis.info/numpy-build-doc) and not the git repo, but > I'll push soon. > > Documentation goes via Python functional programming, but this are > details. ?In fact, Sphinx just documents Python functions. ?We are > working towards an automatisation of build process steps using this > Python functions. ?Yet another build system. ?But this is future. > > Please refrain from fetching anything until I did the authoritative > push, so that you'll have a working system, which is at least beta and > not rather alpha like the current things I put on github. > > Friedrich > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > From ioan.ferencik at tkk.fi Mon Oct 25 10:18:44 2010 From: ioan.ferencik at tkk.fi (Ioan Ferencik) Date: Mon, 25 Oct 2010 17:18:44 +0300 Subject: [Numpy-discussion] compile fortran from python Message-ID: <20101025171844.ragyckd3kck0co4w@webmail3.tkk.fi> Hello list, on compiling some F95 code into a library I got following message: Warning: Nonconforming tab character at (1) i figured out it is because setup uses default compiler flags. this is my set-up command python setup.py config_fc --fcompiler=gnu95 install --home=./tbuild I tried to pass -ffree-form flag to the setup using build_info parameter config.add_library('hm1d', sources = ['src/hm1d.f95'], build_info = {'extra_compiler_args':'-ffree-form'}) but is still get the warnings. the setup does not seem to receive these flags or it is ignoring them. Any hints? Cheers Ioan Ferencik PhD student Aalto University School of Science and Technology Faculty Of Civil and Env. Engineering Lahti Center Tel: +358505122707 From ralf.gommers at googlemail.com Mon Oct 25 11:12:39 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Mon, 25 Oct 2010 23:12:39 +0800 Subject: [Numpy-discussion] tests fails when run $nosetests numpy, but not from python prompt In-Reply-To: References: Message-ID: On Mon, Oct 25, 2010 at 5:40 PM, Friedrich Romstedt wrote: > 2010/10/25 Vincent Davis : >> On Sun, Oct 24, 2010 at 6:29 PM, ? wrote: >>> On Sun, Oct 24, 2010 at 8:17 PM, Ralf Gommers >>> wrote: >>>> On Sun, Oct 24, 2010 at 2:44 AM, Vincent Davis wrote: >>>>> python2.7 10.5, osx 10.6, numpy 1.5.1rc1 >>>>> Test pass when run from python prompt (see bottom) but fail when run >>>>> from $nosetests numpy. >>>> >>>> That is expected, see >>>> http://article.gmane.org/gmane.comp.python.numeric.general/40781. >>> >>> That only applies to the first group of tests, >>> On the commandline he has 19 additional test compared to numpy.test() >>> and failures like >>> >>> /tmp/tmpOjoP4S/_test_ext_module_5403.so: mach-o, but wrong architecture >>> >>> Are there tests in numpy.test() that are skipped for some other reason >>> (e.g. decorated as slow) ? >> You're right, 13 extra distutils tests labeled as slow. These are failures on OS X due to #1399. Ralf >> A little more looking into this I think it might be a osx issue. I >> can't seem to find it now but nosetests runs the following >> /Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app >> I am guessing that Python.app loads the wrong python (python2.7 or >> python2.7-32) ?or something like that. It might be that this is more >> of a nose python2.7 issue. > > 105osxpython:numpy Friedrich$ head > /Library/Frameworks/Python.framework/Versions/2.7/bin/nosetests > #!/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python > > Same applies to the 2.6 & 2.5 :file:`nosetests`. ?At least for the > 2.7, the MacOS/Python called has different size than the bin/python2.7 > cmd line executable. ?So it's simply something completely different. > Still it makes the errors not explained. > > I remember Ralf's post cited by himself. > > FYI, the MacOS/Python executable has all three archs. > > We came to the conclusion, so simple not use nosetests, and to leave > this mysterious issue to later, I will document it on the numpy build > doc web site. > > Friedrich > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > From ralf.gommers at googlemail.com Mon Oct 25 10:55:31 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Mon, 25 Oct 2010 22:55:31 +0800 Subject: [Numpy-discussion] clearing after build; Some directories missing in .gitignore? In-Reply-To: References: Message-ID: On Mon, Oct 25, 2010 at 7:52 PM, Friedrich Romstedt wrote: > I was tearing my hear out yesterday evening with trying to find out > and to understand how this directories occur in the build process and > what role they play: > > build_doc/ This is just where the generated pdf's are copied to, see line 100 of pavement.py > doc/source/reference/generated/ The doc build process extracts the docstrings of all functions/objects in numpy and generates one reST page for each, this is numpy-specific (the machinery in doc/sphinxext). That's this dir. Those files are then included in the pdf/html docs in the next step. That's the standard Sphinx way of doing things. > > The build process of the docs is rather opaque to me, so I don't know > what to do with them. > > The question is: ?Do I really have to clean my working directory > before doing a new build. ?I have problems with this because it seems > that the cleaning is neither complete nor is .gitignore (see above). > In pavement.py I read: > > @needs('clean', 'clean_bootstrap') > def nuke(options): > ? ?"""Remove everything: build dir, installers, bootstrap dirs, etc...""" > ? ?for d in [options.superpack.builddir, options.installers.releasedir]: > ? ? ? ?if os.path.exists(d): > ? ? ? ? ? ?shutil.rmtree(d) > > So :func:`nuke`, as opposed to what I was told before, also removes > the installers. I'm pretty sure I said "$paver clean" doesn't do that. "nuke" is not used anywhere in the release script. Neither is "clean_bootstrap". > ?:func:`clean` removes build/, dist/, numpy.egg-info/, > and doc/build/. ?:func:`clean_bootstrap` is a noop for us. ?None of > them treats the directories listed above. > > I don't know if the generated docs in doc/source/reference/generated > are included automatically, so that garbage from previous builds could > make it into later doc builds? That shouldn't be possible. But good point, one of the improvements to make to the paver and release scripts is making sure that the docs get built only once instead of once per OS X dmg. > > Further, I don't know what may dangle around what I simply don't see > because it's hidden by .gitignore. ?E.g. what's about doc/cdoc/build? Not 100% sure, but don't think that is used yet. > doc/numpy.scipy.org/_build? ?I don't have this dirs, though. This is the new numpy website, not relevant for building user and reference guides. > > I will, for now, just remove the directories listed above and hope > that :func:`clean` does the rest to the extent needed, but I really > have the impressions that the binary build system is rather "organic" > and needs a general overhaul. For sure there is room for improvement in documenting and cleaning a bit (esp. the global vars in pavement.py), but overall I think it's pretty clear. Except maybe for the doc build, but that's the nature of the beast. Cheers, Ralf > > A bit lost, > Friedrich > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > From renesd at gmail.com Mon Oct 25 12:35:50 2010 From: renesd at gmail.com (=?ISO-8859-1?Q?Ren=E9_Dudfield?=) Date: Mon, 25 Oct 2010 17:35:50 +0100 Subject: [Numpy-discussion] ANN: NumPy 1.5.1 release candidate 1 In-Reply-To: References: Message-ID: hi, this is another instance of a bug caused by the 'no old file handling' problem with distutils/numpy. On Sun, Oct 24, 2010 at 4:29 PM, Charles R Harris wrote: > > > On Sun, Oct 24, 2010 at 9:22 AM, Darren Dale wrote: > >> On Sun, Oct 17, 2010 at 7:35 AM, Ralf Gommers >> wrote: >> > Hi, >> > >> > I am pleased to announce the availability of the first release >> > candidate of NumPy 1.5.1. This is a bug-fix release with no new >> > features compared to 1.5.0. >> [...] >> > Please report any other issues on the Numpy-discussion mailing list. >> >> Just installed on kubuntu-10.10, python-2.7 and python-3.1.2. Tests >> look fine for py2.7, but I see datetime errors with py3k: >> >> . >> ====================================================================== >> ERROR: test_creation (test_datetime.TestDateTime) >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File >> "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", >> line 10, in test_creation >> dt1 = np.dtype('M8[750%s]'%unit) >> TypeError: data type not understood >> >> ====================================================================== >> ERROR: test_creation_overflow (test_datetime.TestDateTime) >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File >> "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", >> line 62, in test_creation_overflow >> timesteps = np.array([date], dtype='datetime64[s]')[0].astype(np.int64) >> TypeError: data type not understood >> >> ====================================================================== >> ERROR: test_divisor_conversion_as (test_datetime.TestDateTime) >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File >> "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", >> line 58, in test_divisor_conversion_as >> self.assertRaises(ValueError, lambda : np.dtype('M8[as/10]')) >> File "/usr/lib/python3.1/unittest.py", line 589, in assertRaises >> callableObj(*args, **kwargs) >> File >> "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", >> line 58, in >> self.assertRaises(ValueError, lambda : np.dtype('M8[as/10]')) >> TypeError: data type not understood >> >> ====================================================================== >> ERROR: test_divisor_conversion_bday (test_datetime.TestDateTime) >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File >> "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", >> line 32, in test_divisor_conversion_bday >> assert np.dtype('M8[B/12]') == np.dtype('M8[2h]') >> TypeError: data type not understood >> >> ====================================================================== >> ERROR: test_divisor_conversion_day (test_datetime.TestDateTime) >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File >> "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", >> line 37, in test_divisor_conversion_day >> assert np.dtype('M8[D/12]') == np.dtype('M8[2h]') >> TypeError: data type not understood >> >> ====================================================================== >> ERROR: test_divisor_conversion_fs (test_datetime.TestDateTime) >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File >> "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", >> line 54, in test_divisor_conversion_fs >> assert np.dtype('M8[fs/100]') == np.dtype('M8[10as]') >> TypeError: data type not understood >> >> ====================================================================== >> ERROR: test_divisor_conversion_hour (test_datetime.TestDateTime) >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File >> "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", >> line 42, in test_divisor_conversion_hour >> assert np.dtype('m8[h/30]') == np.dtype('m8[2m]') >> TypeError: data type not understood >> >> ====================================================================== >> ERROR: test_divisor_conversion_minute (test_datetime.TestDateTime) >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File >> "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", >> line 46, in test_divisor_conversion_minute >> assert np.dtype('m8[m/30]') == np.dtype('m8[2s]') >> TypeError: data type not understood >> >> ====================================================================== >> ERROR: test_divisor_conversion_month (test_datetime.TestDateTime) >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File >> "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", >> line 21, in test_divisor_conversion_month >> assert np.dtype('M8[M/2]') == np.dtype('M8[2W]') >> TypeError: data type not understood >> >> ====================================================================== >> ERROR: test_divisor_conversion_second (test_datetime.TestDateTime) >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File >> "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", >> line 50, in test_divisor_conversion_second >> assert np.dtype('m8[s/100]') == np.dtype('m8[10ms]') >> TypeError: data type not understood >> >> ====================================================================== >> ERROR: test_divisor_conversion_week (test_datetime.TestDateTime) >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File >> "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", >> line 26, in test_divisor_conversion_week >> assert np.dtype('m8[W/5]') == np.dtype('m8[B]') >> TypeError: data type not understood >> >> ====================================================================== >> ERROR: test_divisor_conversion_year (test_datetime.TestDateTime) >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File >> "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", >> line 16, in test_divisor_conversion_year >> assert np.dtype('M8[Y/4]') == np.dtype('M8[3M]') >> TypeError: data type not understood >> >> ---------------------------------------------------------------------- >> Ran 3061 tests in 19.197s >> >> FAILED (KNOWNFAIL=5, SKIP=4, errors=12) >> >> ____ > > > You may have left over tests in the installation directory. Can you try > deleting it and installing again? > > Chuck > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From silyko at gmail.com Mon Oct 25 14:43:15 2010 From: silyko at gmail.com (Simon Lyngby Kokkendorff) Date: Mon, 25 Oct 2010 20:43:15 +0200 Subject: [Numpy-discussion] How to limit the numpy.memmap's RAM usage? In-Reply-To: References: <4CC2BB8B.2030602@gmail.com> <4CC302EC.9040408@gmail.com> Message-ID: Hi List, I had similar problems on windows. I tried to use memmaps to buffer a large amount of data and process it in chunks. But I found that whenever I tried to do this, I always ended filling up RAM completely which led to crashes of my python script with a MemoryError. This led me to consider, actually from an advice via this list, the module h5py, which has a nice numpy interface to the hdf5 file format. It seemed more clear to me with the h5py-module, what was being buffered on disk and what was stored in RAM. Cheers, Simon On Sun, Oct 24, 2010 at 2:15 AM, David Cournapeau wrote: > On Sun, Oct 24, 2010 at 12:44 AM, braingateway > wrote: > > > > > I agree with you about the point of using memmap. > > > That is why the behavior > > is so strange to me. > > I think it is expected. What kind of behavior were you expecting ? To > be clear, if I have a lot of available ram, I expect memmap arrays to > take almost all of it (virtual memroy ~ resident memory). Now, if at > the same time, another process starts taking a lot of memory, I expect > the OS to automatically lower resident memory for the process using > memmap. > > I did a small experiment on mac os x, creating a giant mmap'd array in > numpy, and at the same time running a small C program using mlock (to > lock pages into physical memory). As soon as I lock a big area (where > big means most of my physical ram), the python process dealing with > the mmap area sees its resident memory decrease. As soon as I kill the > C program locking the memory, the resident memory starts increasing > again. > > cheers, > > David > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lutz.maibaum at gmail.com Mon Oct 25 18:13:09 2010 From: lutz.maibaum at gmail.com (Lutz Maibaum) Date: Mon, 25 Oct 2010 15:13:09 -0700 Subject: [Numpy-discussion] Running tests that are marked as KNOWNFAIL Message-ID: <121A9026-0CBE-4057-9180-6EFD7D8FE66E@gmail.com> Is there a way to execute tests even if they are marked as KNOWNFAIL? For example, the module scipy.sparse.linalg has a few tests that are marked as such on my architecture (OS-X 64 bit). Running scipy.sparse.linalg(extra_argv=["--no-knownfail"]) changes the test result to ERROR, but it looks the actual test is still not run. The reason I'm asking is that when I remove the @dec.knownfailureif decorator from these tests by hand, they actually pass on my machine. Thanks, Lutz From lciti at essex.ac.uk Mon Oct 25 18:40:40 2010 From: lciti at essex.ac.uk (Citi, Luca) Date: Mon, 25 Oct 2010 22:40:40 +0000 Subject: [Numpy-discussion] speed of array vs matrix In-Reply-To: References: <703475E2E2A4E24C961A32C31C504DA602F82B2F@mbx2-node2.essex.ac.uk>, Message-ID: <703475E2E2A4E24C961A32C31C504DA602F84B9E@mbx2-node2.essex.ac.uk> Thank you for your replies. I might just use arrays. Maybe in the future something like pypy might help reduce the python overhead. Best, Luca From ralf.gommers at googlemail.com Mon Oct 25 19:47:01 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Tue, 26 Oct 2010 07:47:01 +0800 Subject: [Numpy-discussion] ANN: NumPy 1.5.1 release candidate 1 In-Reply-To: References: Message-ID: On Tue, Oct 26, 2010 at 12:35 AM, Ren? Dudfield wrote: > hi, > > this is another instance of a bug caused by the 'no old file handling' > problem with distutils/numpy. You're talking about the datetime tests below? They don't exist in 1.5.x, that's simply a file left over from an install of the master branch. Cheers, Ralf > > > On Sun, Oct 24, 2010 at 4:29 PM, Charles R Harris > wrote: >> >> >> On Sun, Oct 24, 2010 at 9:22 AM, Darren Dale wrote: >>> >>> On Sun, Oct 17, 2010 at 7:35 AM, Ralf Gommers >>> wrote: >>> > Hi, >>> > >>> > I am pleased to announce the availability of the first release >>> > candidate of NumPy 1.5.1. This is a bug-fix release with no new >>> > features compared to 1.5.0. >>> [...] >>> > Please report any other issues on the Numpy-discussion mailing list. >>> >>> Just installed on kubuntu-10.10, python-2.7 and python-3.1.2. Tests >>> look fine for py2.7, but I see datetime errors with py3k: >>> >>> . >>> ====================================================================== >>> ERROR: test_creation (test_datetime.TestDateTime) >>> ---------------------------------------------------------------------- >>> Traceback (most recent call last): >>> ?File >>> "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", >>> line 10, in test_creation >>> ? ?dt1 = np.dtype('M8[750%s]'%unit) >>> TypeError: data type not understood >>> >>> ====================================================================== >>> ERROR: test_creation_overflow (test_datetime.TestDateTime) >>> ---------------------------------------------------------------------- >>> Traceback (most recent call last): >>> ?File >>> "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", >>> line 62, in test_creation_overflow >>> ? ?timesteps = np.array([date], >>> dtype='datetime64[s]')[0].astype(np.int64) >>> TypeError: data type not understood >>> >>> ====================================================================== >>> ERROR: test_divisor_conversion_as (test_datetime.TestDateTime) >>> ---------------------------------------------------------------------- >>> Traceback (most recent call last): >>> ?File >>> "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", >>> line 58, in test_divisor_conversion_as >>> ? ?self.assertRaises(ValueError, lambda : np.dtype('M8[as/10]')) >>> ?File "/usr/lib/python3.1/unittest.py", line 589, in assertRaises >>> ? ?callableObj(*args, **kwargs) >>> ?File >>> "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", >>> line 58, in >>> ? ?self.assertRaises(ValueError, lambda : np.dtype('M8[as/10]')) >>> TypeError: data type not understood >>> >>> ====================================================================== >>> ERROR: test_divisor_conversion_bday (test_datetime.TestDateTime) >>> ---------------------------------------------------------------------- >>> Traceback (most recent call last): >>> ?File >>> "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", >>> line 32, in test_divisor_conversion_bday >>> ? ?assert np.dtype('M8[B/12]') == np.dtype('M8[2h]') >>> TypeError: data type not understood >>> >>> ====================================================================== >>> ERROR: test_divisor_conversion_day (test_datetime.TestDateTime) >>> ---------------------------------------------------------------------- >>> Traceback (most recent call last): >>> ?File >>> "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", >>> line 37, in test_divisor_conversion_day >>> ? ?assert np.dtype('M8[D/12]') == np.dtype('M8[2h]') >>> TypeError: data type not understood >>> >>> ====================================================================== >>> ERROR: test_divisor_conversion_fs (test_datetime.TestDateTime) >>> ---------------------------------------------------------------------- >>> Traceback (most recent call last): >>> ?File >>> "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", >>> line 54, in test_divisor_conversion_fs >>> ? ?assert np.dtype('M8[fs/100]') == np.dtype('M8[10as]') >>> TypeError: data type not understood >>> >>> ====================================================================== >>> ERROR: test_divisor_conversion_hour (test_datetime.TestDateTime) >>> ---------------------------------------------------------------------- >>> Traceback (most recent call last): >>> ?File >>> "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", >>> line 42, in test_divisor_conversion_hour >>> ? ?assert np.dtype('m8[h/30]') == np.dtype('m8[2m]') >>> TypeError: data type not understood >>> >>> ====================================================================== >>> ERROR: test_divisor_conversion_minute (test_datetime.TestDateTime) >>> ---------------------------------------------------------------------- >>> Traceback (most recent call last): >>> ?File >>> "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", >>> line 46, in test_divisor_conversion_minute >>> ? ?assert np.dtype('m8[m/30]') == np.dtype('m8[2s]') >>> TypeError: data type not understood >>> >>> ====================================================================== >>> ERROR: test_divisor_conversion_month (test_datetime.TestDateTime) >>> ---------------------------------------------------------------------- >>> Traceback (most recent call last): >>> ?File >>> "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", >>> line 21, in test_divisor_conversion_month >>> ? ?assert np.dtype('M8[M/2]') == np.dtype('M8[2W]') >>> TypeError: data type not understood >>> >>> ====================================================================== >>> ERROR: test_divisor_conversion_second (test_datetime.TestDateTime) >>> ---------------------------------------------------------------------- >>> Traceback (most recent call last): >>> ?File >>> "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", >>> line 50, in test_divisor_conversion_second >>> ? ?assert np.dtype('m8[s/100]') == np.dtype('m8[10ms]') >>> TypeError: data type not understood >>> >>> ====================================================================== >>> ERROR: test_divisor_conversion_week (test_datetime.TestDateTime) >>> ---------------------------------------------------------------------- >>> Traceback (most recent call last): >>> ?File >>> "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", >>> line 26, in test_divisor_conversion_week >>> ? ?assert np.dtype('m8[W/5]') == np.dtype('m8[B]') >>> TypeError: data type not understood >>> >>> ====================================================================== >>> ERROR: test_divisor_conversion_year (test_datetime.TestDateTime) >>> ---------------------------------------------------------------------- >>> Traceback (most recent call last): >>> ?File >>> "/home/darren/.local/lib/python3.1/site-packages/numpy/core/tests/test_datetime.py", >>> line 16, in test_divisor_conversion_year >>> ? ?assert np.dtype('M8[Y/4]') == np.dtype('M8[3M]') >>> TypeError: data type not understood >>> >>> ---------------------------------------------------------------------- >>> Ran 3061 tests in 19.197s >>> >>> FAILED (KNOWNFAIL=5, SKIP=4, errors=12) >>> >>> ____ >> >> You may have left over tests in the installation directory. Can you try >> deleting it and installing again? >> >> Chuck >> >> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > From david at silveregg.co.jp Mon Oct 25 20:54:54 2010 From: david at silveregg.co.jp (David) Date: Tue, 26 Oct 2010 09:54:54 +0900 Subject: [Numpy-discussion] ANN: NumPy 1.5.1 release candidate 1 In-Reply-To: References: Message-ID: <4CC626DE.4010705@silveregg.co.jp> On 10/26/2010 08:47 AM, Ralf Gommers wrote: > On Tue, Oct 26, 2010 at 12:35 AM, Ren? Dudfield wrote: >> hi, >> >> this is another instance of a bug caused by the 'no old file handling' >> problem with distutils/numpy. > > You're talking about the datetime tests below? They don't exist in > 1.5.x, that's simply a file left over from an install of the master > branch. I think that's what he meant (although the issue has nothing to do with numpy and is solely caused by distutils), cheers, David From renesd at gmail.com Tue Oct 26 06:51:20 2010 From: renesd at gmail.com (=?ISO-8859-1?Q?Ren=E9_Dudfield?=) Date: Tue, 26 Oct 2010 11:51:20 +0100 Subject: [Numpy-discussion] ANN: NumPy 1.5.1 release candidate 1 In-Reply-To: <4CC626DE.4010705@silveregg.co.jp> References: <4CC626DE.4010705@silveregg.co.jp> Message-ID: Hi, Yeah, that's what I meant. Upgrading numpy over an old install via distutils breaks it. cheers, On Tue, Oct 26, 2010 at 1:54 AM, David wrote: > On 10/26/2010 08:47 AM, Ralf Gommers wrote: > > On Tue, Oct 26, 2010 at 12:35 AM, Ren? Dudfield > wrote: > >> hi, > >> > >> this is another instance of a bug caused by the 'no old file handling' > >> problem with distutils/numpy. > > > > You're talking about the datetime tests below? They don't exist in > > 1.5.x, that's simply a file left over from an install of the master > > branch. > > I think that's what he meant (although the issue has nothing to do with > numpy and is solely caused by distutils), > > cheers, > > David > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From l.resmi at gmail.com Tue Oct 26 10:57:43 2010 From: l.resmi at gmail.com (Resmi) Date: Tue, 26 Oct 2010 20:27:43 +0530 Subject: [Numpy-discussion] loading and filtering data for matplotlib Message-ID: Hi I'm new to python. I'm trying to plot a data set in matplotlib. The data is a mixture of strings and floats, has four columns (col[0],col[1],col[2],col[3]) and it looks like: R -2.29350 0.50340 0.480E-01 R -2.25903 0.50740 0.480E-01 SU -2.19457 0.16200 0.800E-01 SU -2.13237 0.14600 0.800E-01 What I want to do is to plot the SU filtered entries alone as col[1]:col[2] I wrote a script to read the data, how can I make x1 and SUx2 as arrays? Right now matplotlib only plots the last value obviously. Or is there a different/better way to slice just the SU entries and make them as a separate array? My actual data file has many more entries with more filters and I want to make a plot for each of the filters with col[1]:col[2] import pylab import numpy #Loading and reading data data=numpy.loadtxt('file.dat',dtype=[('filt','S4'),('x1','f8'),('x2','f8'),('x3','f8')]) filt=data['filt'] for i in range(0,len(filt),1): if filt[i] == 'SU': x1=data['x1'][i] SUx2=data['x2'][i] #print x1,SUx2 pylab.plot(x1,SUx2,'bs') pylab.show() From josef.pktd at gmail.com Tue Oct 26 11:21:15 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Tue, 26 Oct 2010 11:21:15 -0400 Subject: [Numpy-discussion] loading and filtering data for matplotlib In-Reply-To: References: Message-ID: On Tue, Oct 26, 2010 at 10:57 AM, Resmi wrote: > Hi > ?I'm new to python. I'm trying to plot a data set in matplotlib. > > ?The data is a mixture of strings and floats, has four columns > (col[0],col[1],col[2],col[3]) and it looks like: > > R ? ? ? -2.29350 ? 0.50340 ? 0.480E-01 > R ? ? ? -2.25903 ? 0.50740 ? 0.480E-01 > SU ? ? ?-2.19457 ? 0.16200 ? 0.800E-01 > SU ? ? ?-2.13237 ? 0.14600 ? 0.800E-01 > > What I want to do is to plot the SU filtered entries alone as col[1]:col[2] > > I wrote a script to read the data, how can I make x1 and SUx2 as > arrays? Right now matplotlib only plots the last value obviously. Or > is there a different/better way to slice just the SU entries and make > them as a separate array? My actual data file has many more entries > with more filters and I want to make a plot for each of the filters > with col[1]:col[2] > > import pylab > import numpy > #Loading and reading data > data=numpy.loadtxt('file.dat',dtype=[('filt','S4'),('x1','f8'),('x2','f8'),('x3','f8')]) > filt=data['filt'] > for i in range(0,len(filt),1): > ?if filt[i] == 'SU': > ?x1=data['x1'][i] > ?SUx2=data['x2'][i] here you are overwriting you x1 each time you go through the loop and it contains only one value the vectorized version that should work (minus typos, just written not tested) filt = data['filt'] mask = filt=='SU' x1=data['x1'][mask] SUx2 = data['x2'][mask] no loop necessary. Josef > #print x1,SUx2 > pylab.plot(x1,SUx2,'bs') > pylab.show() > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > From silva at lma.cnrs-mrs.fr Tue Oct 26 12:51:03 2010 From: silva at lma.cnrs-mrs.fr (Fabrice Silva) Date: Tue, 26 Oct 2010 13:51:03 -0300 Subject: [Numpy-discussion] portable doctests despite floating points numbers In-Reply-To: References: <1287144301.1717.4.camel@Portable-s2m.cnrs-mrs.fr> Message-ID: <1288111863.1607.1.camel@florian-desktop> Another solution http://code.activestate.com/recipes/577124-approximately-equal/ -- Fabrice Silva From friedrichromstedt at gmail.com Tue Oct 26 13:23:39 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Tue, 26 Oct 2010 19:23:39 +0200 Subject: [Numpy-discussion] ANN: NumPy 1.5.1 release candidate 1 In-Reply-To: References: Message-ID: I found some issues on Mac OS X 10.5 ppc in py2.5.4: See here: http://github.com/friedrichromstedt/numpy/tree/release%2F1.5.1rc1%2Fpy2.5-python.org-macosx10.3/release/logs/osx105rh/ I tested also on 10.6 intel and 10.5 intel, there are no Fs. The Python was freshly installed, only nose & the numpy-py2.5 installer. I'm sorry, I cannot say atm how to get to the installer, we seem to have some port forwarding problem (the build machine and the OS X server in the network seem to be fighting) I discussed with Ralf about what to put into this tree, and I did *not* put binaries. There where binaries in the repo before, but they shouldn't be fetched now, since I removed the branch containing them. One more question: Do I have to install gfortran to do full testing? I see some S. I now say my installer numpy-1.5.1rc1-py2.5-python.org-macosx10.3.dmg, built on 10.5, is fully functional and free to the public. The docs look also good now. Vincent, can you confirm the same for yours? Why do we not ship with the html docs? I find them much more useful than the pdf. I'll continue tomorrow (it's evening here now) with testing in py2.6, py2.7 Vincent's installers if the problem is py2.5 ppc specific. Maybe it's obvious to someone else than me what's going wrong there. The build logs are under release/logs/osx105vmd/. Friedrich From l.resmi at gmail.com Tue Oct 26 14:48:59 2010 From: l.resmi at gmail.com (Resmi) Date: Wed, 27 Oct 2010 00:18:59 +0530 Subject: [Numpy-discussion] loading and filtering data for matplotlib In-Reply-To: References: Message-ID: > > the vectorized version that should work (minus typos, just written not > tested) filt = data['filt'] mask = filt=='SU' x1=data['x1'][mask] SUx2 = data['x2'][mask] no loop necessary. T hanks Josef. It works as it is. Resmi -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolaiheitz at gmx.de Tue Oct 26 15:16:53 2010 From: nicolaiheitz at gmx.de (Nicolai Heitz) Date: Tue, 26 Oct 2010 12:16:53 -0700 Subject: [Numpy-discussion] problems with numdifftools Message-ID: <4CC72925.5080401@gmx.de> Hey, I am not sure if you are the right persons to contact but if not I would appreciate a short notice and maybe an address where I can find help. I already posted this this message in an other python mailing list and they forwarded me to this list and told me that I might find help here. I am using Python 2.6 and the following packages: 1) numpy 2) scipy 3) numdifftools I am a physicist and started to use Python 2-3 weeks ago. I want to use Python to calculate the eigenvalues of the Hamiltonian given in the code. Therefore I have to do the following steps: 1) define the Hamiltonian or the potential respectively (--> function: potential) 2) minimize the potential ( I am using scipy.optimize.fmin to calculate the minimum of the potential) (2b) Expand the Hamiltonian around the minimum position. This step is not done in the code because it is only necessary for the purpose that one understand the physical background and why one have to do step 3) 3) Calculate the Hessian matrix of the potential, that means calculate the second derivatives of the potential at the point of the minimum position (--> numdifftools.Hessian) 4) Calculate the eigenvalues of the Hessian (-->scipy.linalg.eigvals) The problem can be solved analytically except of the calculation of the minima in step 2: Now I have the following problem: The Hessian matrix evaluated at the minimum position is wrong. What I checked so far: 1) The potential seems to be calculated correctly and the minimum position for two ions (N=2) is fine. 2) The Hessian matrix calculation works fine for several other functions. 3) The Hessian matrix is correct when I set the Coulomb interaction to zero (C=0) 4) The Hessian matrix is correct when I set C to some simple arbitrary integer numbers like 1, 5 ,8 .... 5) The Hesse matrix gives the correct number of the first part of the diagonal elements even with C=2.3e-28 ! But in that case the offdiagonal elements and the part of the diagonal element which refers to the second derivative in the Coulomb term is wrong! The offdiagonal term should be C/(abs(x_1-x_2))**3 = 2.6e-12 but it is 3.4e-24! 5) In principal Python can divide those numbers (2*2.3e-28)/(5.6e-6)**3 6) I played around with the accurateness of the calculation of the Hessian by varying the arguments numTerms, method and metOrder but that didn't change anything in my case. My source code is attached. Please keep in mind that I just started programing and Python is my first Language. I tried to do my best with the comments to make the code readable. Here it comes: # import a tool to use / as a symbol for normal division from __future__ import division #import system data import sys, os #Loading the required packages import scipy as sp import numpy as np import matplotlib as mpl import matplotlib.pyplot as plt import numdifftools as nd # and subpackages from scipy import * from scipy import linalg, optimize, constants #----------------------------------------------------------------------------------------- # Hamiltonian H=sum_i(p_i^2/(2m)+ 1/2 * m * w^2 x_i^2)+ sum_(i!=j)(a/|x_i-x_j|) #----------------------------------------------------------------------------------------- class classicalHamiltonian: def __init__(self): self.N = 2 #N is a scalar, it's the number of ions in the chain f = 1000000 #f is a scalar, it's the trap frequency self.w = 2*pi*f #w is a scalar, it's the angular velocity corresponding to the trap frequency self.C = (4*pi*constants.epsilon_0)**(-1)*constants.e**2 #C is a scalar, it's the Coulomb constant times the electronic charge in SI self.m = 39.96*1.66e-27 #m is the mass of a single trapped ion in the chain def potential(self, positionvector): #Defines the potential that is going to be minimized x= positionvector #x is an 1-d array (vector) of lenght N that contains the positions of the N ions w= self.w C= self.C m= self.m #First we consider the potential of the harmonic osszilator Vx = 0.5 * m * (w**2) * sum(x**2) for i in range(len(x)): for j in range(i+1, len(x)): Vx += C * (abs(x[i]-x[j]))**(-1) #then we add the coulomb interaction return Vx def initialposition(self): #Defines the initial position as an estimate for the minimize process N= self.N x_0 = r_[-(N-1)/2:(N-1)/2:N*1j] return x_0 def normal_modes(self, eigenvalues): #the computed eigenvalues of the matrix Vx are of the form (normal_modes)^2*m. m = self.m normal_modes = sqrt(eigenvalues/m) return normal_modes #C=(4*pi*constants.epsilon_0)**(-1)*constants.e**2 c=classicalHamiltonian() #print c.potential(array([-0.5, 0.5])) xopt = optimize.fmin(c.potential, c.initialposition(), xtol = 1e-10) hessian = nd.Hessian(c.potential) eigenvalues = linalg.eigvals(hessian(xopt)) normal_modes = c.normal_modes(eigenvalues) I appreciate any kind of help. Thanks a lot in advance Nicolai ps: If you have any questions or need some more information please let me know. From pav at iki.fi Tue Oct 26 15:28:59 2010 From: pav at iki.fi (Pauli Virtanen) Date: Tue, 26 Oct 2010 19:28:59 +0000 (UTC) Subject: [Numpy-discussion] problems with numdifftools References: <4CC72925.5080401@gmx.de> Message-ID: Tue, 26 Oct 2010 12:16:53 -0700, Nicolai Heitz wrote: > I am not sure if you are the right persons to contact but if not I would > appreciate a short notice and maybe an address where I can find help. I > already posted this this message in an other python mailing list and > they forwarded me to this list and told me that I might find help here. Some comments: 1) General advice: When doing numerics, it's generally a good idea to use units natural for the problem, and not SI ones. The numbers the computer sees should be of order 1. Not all numerical algorithms are scale invariant. 2) The scipy-user list might be even more appropriate: http://mail.scipy.org/mailman/listinfo/scipy-user 3) The numdifftools authors might be more knowledgeable about their software: http://code.google.com/p/numdifftools/ If you are sure it's a bug in numdifftools, click the issues tab and write a report. Be sure to include simple test case (like the one you attached). -- Pauli Virtanen From josef.pktd at gmail.com Tue Oct 26 15:38:07 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Tue, 26 Oct 2010 15:38:07 -0400 Subject: [Numpy-discussion] problems with numdifftools In-Reply-To: References: <4CC72925.5080401@gmx.de> Message-ID: On Tue, Oct 26, 2010 at 3:28 PM, Pauli Virtanen wrote: > Tue, 26 Oct 2010 12:16:53 -0700, Nicolai Heitz wrote: >> I am not sure if you are the right persons to contact but if not I would >> appreciate a short notice and maybe an address where I can find help. I >> already posted this this message in an other python mailing list and >> they forwarded me to this list and told me that I might find help here. > > Some comments: > > 1) General advice: When doing numerics, it's generally a good idea to use > units natural for the problem, and not SI ones. The numbers the computer > sees should be of order 1. Not all numerical algorithms are scale > invariant. I also think it will be difficult to get good numbers by numerical differenttiation with this scaling. > > 2) The scipy-user list might be even more appropriate: > > http://mail.scipy.org/mailman/listinfo/scipy-user > > 3) The numdifftools authors might be more knowledgeable about their > software: > > http://code.google.com/p/numdifftools/ > > If you are sure it's a bug in numdifftools, click the issues tab and > write a report. Be sure to include simple test case (like the one you > attached). Per might be reading this or scipy-user. My guess would be that it is not a bug but numerical precision problems in a difficult use case. The question is however useful, because I haven't seen much discussion yet about a robust use of numdifftools. Josef > > -- > Pauli Virtanen > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > From nicolaiheitz at gmx.de Tue Oct 26 17:24:39 2010 From: nicolaiheitz at gmx.de (Nicolai Heitz) Date: Tue, 26 Oct 2010 14:24:39 -0700 Subject: [Numpy-discussion] problems with numdifftools Message-ID: <4CC74717.1060808@gmx.de> Am 26.10.2010 12:38, schrieb josef.pktd at gmail.com: > On Tue, Oct 26, 2010 at 3:28 PM, Pauli Virtanen wrote: >> Tue, 26 Oct 2010 12:16:53 -0700, Nicolai Heitz wrote: >>> I am not sure if you are the right persons to contact but if not I would >>> appreciate a short notice and maybe an address where I can find help. I >>> already posted this this message in an other python mailing list and >>> they forwarded me to this list and told me that I might find help here. >> Some comments: >> >> 1) General advice: When doing numerics, it's generally a good idea to use >> units natural for the problem, and not SI ones. The numbers the computer >> sees should be of order 1. Not all numerical algorithms are scale >> invariant. > I also think it will be difficult to get good numbers by numerical > differenttiation with this scaling. > I knew before that the scaling might causes some problems but I didn't expect them to arise on that level. I thought numdifftools should be robust in those typical physical units/scales. I can transform it into natural units but this is not the best solution and I still hope for somebody to come up with a solution for SI units. >> 2) The scipy-user list might be even more appropriate: >> >> http://mail.scipy.org/mailman/listinfo/scipy-user I contacted them already but they didn't responded so far and I was forwarded to that list which was supposed to be more appropriated. >> 3) The numdifftools authors might be more knowledgeable about their >> software: >> >> http://code.google.com/p/numdifftools/ >> >> If you are sure it's a bug in numdifftools, click the issues tab and >> write a report. Be sure to include simple test case (like the one you >> attached). > Per might be reading this or scipy-user. > > My guess would be that it is not a bug but numerical precision > problems in a difficult use case. The question is however useful, > because I haven't seen much discussion yet about a robust use of > numdifftools. > > Josef > I am not sure if it is a bug either. I mean for most of the numbers I tested the code (not having a magnitude of e-28) like 2.5, 1, 1e-10 numdifftools works all fine. My question is more like 1) Can I make it run/fix it, so that it is also going to work for the SI scaling? 2) How can I be sure that increasing the number of ions or adding a somehow more complicated term to the potential energy is not causing the same problems even in natural units? 3) In which range is numdifftools working properly. Nicolai >> -- >> Pauli Virtanen >> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion From pav at iki.fi Tue Oct 26 18:59:43 2010 From: pav at iki.fi (Pauli Virtanen) Date: Tue, 26 Oct 2010 22:59:43 +0000 (UTC) Subject: [Numpy-discussion] problems with numdifftools References: <4CC74717.1060808@gmx.de> Message-ID: Tue, 26 Oct 2010 14:24:39 -0700, Nicolai Heitz wrote: > > http://mail.scipy.org/mailman/listinfo/scipy-user > > I contacted them already but they didn't responded so far and I was > forwarded to that list which was supposed to be more appropriated. I think you are thinking here about some other list -- scipy-user is the correct place for this discussion (and I don't remember seeing your mail there). [clip] > 1) Can I make it run/fix it, so that it is also going to work for the SI > scaling? Based on a brief look, it seems that uniform scaling will not help you, as you have two very different length scales in the problem, 1/sqrt(m w^2) >> C If you go to CM+relative coordinates you might be able to scale them separately, but that's fiddly and might not work for larger N. In your problem, things go wrong when the ratio between the length scales approaches 1e-15 which happens to be the machine epsilon. This implies that the algorithm runs into some problems caused by the finite precision of floating-point numbers. What exactly goes wrong and how to fix it, no idea --- I didn't look into how Numdifftools is implemented. > 2) How can I be sure that increasing the number of ions or adding a > somehow more complicated term to the potential energy is not causing the > same problems even in natural units? > > 3) In which range is numdifftools working properly. That depends on the algorithm and the problem. Personally, I wouldn't trust numerical differentiation if the problem has significantly different length scales, it is important to capture all of them accurately, and it is not clear how to scale them to the same size. Writing ND software that works as expected all the time is probably not possible even in theory. Numerical differentiation is not the only game in the town. I'd look into automatic differentiation (AD) -- there are libraries available for Python also for that, and it is numerically stable. E.g. http://en.wikipedia.org/wiki/Automatic_differentiation#Software has a list of Python libraries. I don't know which of them would be the best ones, though. -- Pauli Virtanen From dewald.pieterse at gmail.com Tue Oct 26 20:15:19 2010 From: dewald.pieterse at gmail.com (Dewald Pieterse) Date: Wed, 27 Oct 2010 00:15:19 +0000 Subject: [Numpy-discussion] Stacking a 2d array onto a 3d array Message-ID: Starting with: In [93]: test = > numpy.array([[[1,1,1],[1,1,1]],[[2,2,2],[2,2,2]],[[3,3,3],[3,3,3]]]) > > In [94]: test > Out[94]: > array([[[1, 1, 1], > [1, 1, 1]], > > [[2, 2, 2], > [2, 2, 2]], > > [[3, 3, 3], > [3, 3, 3]]]) > > Slicing the complete first row: > > In [95]: firstrow = test[0,:,:] > > In [96]: firstrow > Out[96]: > array([[1, 1, 1], > [1, 1, 1]]) > I want to stack firstrow onto test to end up with: ([[[1, 1, 1], > [1, 1, 1]], > > [[1, 1, 1], > [1, 1, 1]], > > [[2, 2, 2], > [2, 2, 2]], > > [[3, 3, 3], > [3, 3, 3]]] > vstack wants the array dimensions to be the same, is this possible without doing 1 dimensional reshape, the actual data I want to do this on is some what larger. numpy.vstack((firstrow,test)) > --------------------------------------------------------------------------- > ValueError Traceback (most recent call last) > > /mnt/home/home/bmeagle/M/programme/analiseerverwerkteprent.py in () > ----> 1 > 2 > 3 > 4 > 5 > > /usr/lib64/python2.6/site-packages/numpy/core/shape_base.py in vstack(tup) > 212 > 213 """ > --> 214 return _nx.concatenate(map(atleast_2d,tup),0) > 215 > 216 def hstack(tup): > > ValueError: arrays must have same number of dimensions > What is the correct python way to do this? -- Dewald Pieterse -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Tue Oct 26 20:55:59 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Tue, 26 Oct 2010 20:55:59 -0400 Subject: [Numpy-discussion] Stacking a 2d array onto a 3d array In-Reply-To: References: Message-ID: On Tue, Oct 26, 2010 at 8:15 PM, Dewald Pieterse wrote: > Starting with: > >> In [93]: test = >> numpy.array([[[1,1,1],[1,1,1]],[[2,2,2],[2,2,2]],[[3,3,3],[3,3,3]]]) >> >> In [94]: test >> Out[94]: >> array([[[1, 1, 1], >> ??????? [1, 1, 1]], >> >> ?????? [[2, 2, 2], >> ??????? [2, 2, 2]], >> >> ?????? [[3, 3, 3], >> ??????? [3, 3, 3]]]) >> >> Slicing the complete first row: >> >> In [95]: firstrow = test[0,:,:] >> >> In [96]: firstrow >> Out[96]: >> array([[1, 1, 1], >> ?????? [1, 1, 1]]) > > I want to stack firstrow onto test to end up with: > >> ([[[1, 1, 1], >> ??????? [1, 1, 1]], >> >> ?????? [[1, 1, 1], >> ??????? [1, 1, 1]], >> >> ?????? [[2, 2, 2], >> ??????? [2, 2, 2]], >> >> ?????? [[3, 3, 3], >> ??????? [3, 3, 3]]] > > > vstack wants the array dimensions to be the same, is this possible without > doing 1 dimensional reshape, the actual data I want to do this on is some > what larger. > >> ?numpy.vstack((firstrow,test)) >> >> --------------------------------------------------------------------------- >> ValueError??????????????????????????????? Traceback (most recent call >> last) >> >> /mnt/home/home/bmeagle/M/programme/analiseerverwerkteprent.py in >> () >> ----> 1 >> ????? 2 >> ????? 3 >> ????? 4 >> ????? 5 >> >> /usr/lib64/python2.6/site-packages/numpy/core/shape_base.py in vstack(tup) >> ??? 212 >> ??? 213???? """ >> --> 214???? return _nx.concatenate(map(atleast_2d,tup),0) >> ??? 215 >> ??? 216 def hstack(tup): >> >> ValueError: arrays must have same number of dimensions > > > What is the correct python way to do this? keep the first dimension or add it back in >>> test = np.array([[[1,1,1],[1,1,1]],[[2,2,2],[2,2,2]],[[3,3,3],[3,3,3]]]) >>> np.vstack((test[:1], test)) array([[[1, 1, 1], [1, 1, 1]], [[1, 1, 1], [1, 1, 1]], [[2, 2, 2], [2, 2, 2]], [[3, 3, 3], [3, 3, 3]]]) >>> np.vstack((test[0][None,...], test)) array([[[1, 1, 1], [1, 1, 1]], [[1, 1, 1], [1, 1, 1]], [[2, 2, 2], [2, 2, 2]], [[3, 3, 3], [3, 3, 3]]]) >>> np.vstack((test[0][None,:,:], test)) array([[[1, 1, 1], [1, 1, 1]], [[1, 1, 1], [1, 1, 1]], [[2, 2, 2], [2, 2, 2]], [[3, 3, 3], [3, 3, 3]]]) I like expand_dims for arbitrary axis, e.g. >>> ax=1 >>> np.concatenate((np.expand_dims(test[:,0,:],ax), test), ax) array([[[1, 1, 1], [1, 1, 1], [1, 1, 1]], [[2, 2, 2], [2, 2, 2], [2, 2, 2]], [[3, 3, 3], [3, 3, 3], [3, 3, 3]]]) Josef > > > -- > Dewald Pieterse > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > From dewald.pieterse at gmail.com Tue Oct 26 21:02:11 2010 From: dewald.pieterse at gmail.com (Dewald Pieterse) Date: Wed, 27 Oct 2010 01:02:11 +0000 Subject: [Numpy-discussion] Stacking a 2d array onto a 3d array In-Reply-To: References: Message-ID: I see my slicing was the problem, np.vstack((test[:1], test)) works perfectly. On Wed, Oct 27, 2010 at 12:55 AM, wrote: > On Tue, Oct 26, 2010 at 8:15 PM, Dewald Pieterse > wrote: > > Starting with: > > > >> In [93]: test = > >> numpy.array([[[1,1,1],[1,1,1]],[[2,2,2],[2,2,2]],[[3,3,3],[3,3,3]]]) > >> > >> In [94]: test > >> Out[94]: > >> array([[[1, 1, 1], > >> [1, 1, 1]], > >> > >> [[2, 2, 2], > >> [2, 2, 2]], > >> > >> [[3, 3, 3], > >> [3, 3, 3]]]) > >> > >> Slicing the complete first row: > >> > >> In [95]: firstrow = test[0,:,:] > >> > >> In [96]: firstrow > >> Out[96]: > >> array([[1, 1, 1], > >> [1, 1, 1]]) > > > > I want to stack firstrow onto test to end up with: > > > >> ([[[1, 1, 1], > >> [1, 1, 1]], > >> > >> [[1, 1, 1], > >> [1, 1, 1]], > >> > >> [[2, 2, 2], > >> [2, 2, 2]], > >> > >> [[3, 3, 3], > >> [3, 3, 3]]] > > > > > > vstack wants the array dimensions to be the same, is this possible > without > > doing 1 dimensional reshape, the actual data I want to do this on is some > > what larger. > > > >> numpy.vstack((firstrow,test)) > >> > >> > --------------------------------------------------------------------------- > >> ValueError Traceback (most recent call > >> last) > >> > >> /mnt/home/home/bmeagle/M/programme/analiseerverwerkteprent.py in > >> () > >> ----> 1 > >> 2 > >> 3 > >> 4 > >> 5 > >> > >> /usr/lib64/python2.6/site-packages/numpy/core/shape_base.py in > vstack(tup) > >> 212 > >> 213 """ > >> --> 214 return _nx.concatenate(map(atleast_2d,tup),0) > >> 215 > >> 216 def hstack(tup): > >> > >> ValueError: arrays must have same number of dimensions > > > > > > What is the correct python way to do this? > > keep the first dimension or add it back in > > >>> test = > np.array([[[1,1,1],[1,1,1]],[[2,2,2],[2,2,2]],[[3,3,3],[3,3,3]]]) > >>> np.vstack((test[:1], test)) > array([[[1, 1, 1], > [1, 1, 1]], > > [[1, 1, 1], > [1, 1, 1]], > > [[2, 2, 2], > [2, 2, 2]], > > [[3, 3, 3], > [3, 3, 3]]]) > >>> np.vstack((test[0][None,...], test)) > array([[[1, 1, 1], > [1, 1, 1]], > > [[1, 1, 1], > [1, 1, 1]], > > [[2, 2, 2], > [2, 2, 2]], > > [[3, 3, 3], > [3, 3, 3]]]) > >>> np.vstack((test[0][None,:,:], test)) > array([[[1, 1, 1], > [1, 1, 1]], > > [[1, 1, 1], > [1, 1, 1]], > > [[2, 2, 2], > [2, 2, 2]], > > [[3, 3, 3], > [3, 3, 3]]]) > > I like expand_dims for arbitrary axis, e.g. > > >>> ax=1 > >>> np.concatenate((np.expand_dims(test[:,0,:],ax), test), ax) > array([[[1, 1, 1], > [1, 1, 1], > [1, 1, 1]], > > [[2, 2, 2], > [2, 2, 2], > [2, 2, 2]], > > [[3, 3, 3], > [3, 3, 3], > [3, 3, 3]]]) > > Josef > > > > > > > > -- > > Dewald Pieterse > > > > > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion at scipy.org > > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -- Dewald Pieterse "A democracy is nothing more than mob rule, where fifty-one percent of the people take away the rights of the other forty-nine." ~ Thomas Jefferson -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwwiebe at gmail.com Wed Oct 27 01:05:52 2010 From: mwwiebe at gmail.com (Mark Wiebe) Date: Tue, 26 Oct 2010 22:05:52 -0700 Subject: [Numpy-discussion] adding 'order=' keyword arg to ravel and others Message-ID: Because writing "arr.ravel('F')" doesn't seem as descriptive as "arr.ravel(order='F')", I wrote this simple patch. I added mention of the order='A' parameter to a few places it is relevant as well. Here's the branch on github: http://github.com/m-paradox/numpy/compare/master...ravel_keyword_arg Could someone review it for me? It also fixes the following ticket: http://projects.scipy.org/numpy/ticket/1581 Thanks, Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian.walter at gmail.com Wed Oct 27 05:02:00 2010 From: sebastian.walter at gmail.com (Sebastian Walter) Date: Wed, 27 Oct 2010 11:02:00 +0200 Subject: [Numpy-discussion] problems with numdifftools In-Reply-To: References: <4CC74717.1060808@gmx.de> Message-ID: On Wed, Oct 27, 2010 at 12:59 AM, Pauli Virtanen wrote: > Tue, 26 Oct 2010 14:24:39 -0700, Nicolai Heitz wrote: >> > ?http://mail.scipy.org/mailman/listinfo/scipy-user >> >> I contacted them already but they didn't responded so far and I was >> forwarded to that list which was supposed to be more appropriated. > > I think you are thinking here about some other list -- scipy-user > is the correct place for this discussion (and I don't remember seeing > your mail there). > > [clip] >> 1) Can I make it run/fix it, so that it is also going to work for the SI >> scaling? > > Based on a brief look, it seems that uniform scaling will not help you, > as you have two very different length scales in the problem, > > ? ? ? ?1/sqrt(m w^2) >> C > > If you go to CM+relative coordinates you might be able to scale them > separately, but that's fiddly and might not work for larger N. > > In your problem, things go wrong when the ratio between the > length scales approaches 1e-15 which happens to be the machine epsilon. > This implies that the algorithm runs into some problems caused by the > finite precision of floating-point numbers. > > What exactly goes wrong and how to fix it, no idea --- I didn't look into > how Numdifftools is implemented. > >> 2) How can I be sure that increasing the number of ions or adding a >> somehow more complicated term to the potential energy is not causing the >> same problems even in natural units? >> >> 3) In which range is numdifftools working properly. > > That depends on the algorithm and the problem. Personally, I wouldn't > trust numerical differentiation if the problem has significantly > different length scales, it is important to capture all of them > accurately, and it is not clear how to scale them to the same size. > Writing ND software that works as expected all the time is probably > not possible even in theory. > > Numerical differentiation is not the only game in the town. I'd look > into automatic differentiation (AD) -- there are libraries available > for Python also for that, and it is numerically stable. > > E.g. > > http://en.wikipedia.org/wiki/Automatic_differentiation#Software > > has a list of Python libraries. I don't know which of them would be > the best ones, though. > they all have their pro's and con's. Being (co-)author of some of these tools, my personal and very biased advice is: if you are on Linux, I would go for PYADOLC. it provides bindings to a feature-rich and well-tested C++ library. However, the installation is a little tricker than a "setup.py build" since you will need to compile ADOL-C and get Boost::Python to work. PYADOLC can also differentiate much more complicated code than your example in a relatively efficient manner. For your example the code looks like: --------------------- code --------------------------- .... c=classicalHamiltonian() xopt = optimize.fmin(c.potential, c.initialposition(), xtol = 1e-10) import adolc; import numpy # trace the computation adolc.trace_on(0) x = adolc.adouble(c.initialposition()) adolc.independent(x) y = c.potential(x) adolc.dependent(y) adolc.trace_off() hessian = adolc.hessian(0, xopt) eigenvalues = numpy.linalg.eigh(hessian)[0] normal_modes = c.normal_modes(eigenvalues) print 'hessian=\n',hessian print 'eigenvalues=\n',eigenvalues print 'normal_modes=\n',normal_modes --------------------- code --------------------------- and you get as output Optimization terminated successfully. Current function value: 0.000000 Iterations: 81 Function evaluations: 153 hessian= [[ 5.23748399e-12 -2.61873843e-12] [ -2.61873843e-12 5.23748399e-12]] eigenvalues= [ 2.61874556e-12 7.85622242e-12] normal_modes= [ 6283185.30717959 10882786.30440101] Also, you should use an eigenvalue solver for symmetric matrices, e.g. numpy.linalg.eigh. regards, Sebastian > -- > Pauli Virtanen > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > From pav at iki.fi Wed Oct 27 05:36:22 2010 From: pav at iki.fi (Pauli Virtanen) Date: Wed, 27 Oct 2010 09:36:22 +0000 (UTC) Subject: [Numpy-discussion] adding 'order=' keyword arg to ravel and others References: Message-ID: Tue, 26 Oct 2010 22:05:52 -0700, Mark Wiebe wrote: > Because writing "arr.ravel('F')" doesn't seem as descriptive as > "arr.ravel(order='F')", I wrote this simple patch. I added mention of > the order='A' parameter to a few places it is relevant as well. Here's > the branch on github: > > http://github.com/m-paradox/numpy/compare/master...ravel_keyword_arg > > Could someone review it for me? There is the following problem: >>> import numpy as np >>> x=np.arange(9).reshape(3,3) >>> x.T.flatten() array([0, 3, 6, 1, 4, 7, 2, 5, 8]) >>> x.T.flatten(order=None) array([0, 1, 2, 3, 4, 5, 6, 7, 8]) PyArray_OrderConverter interprets `None` as "A". However, this problem is already there with `reshape`, so this patch looks good to me -- fixing OrderConverter is a separate job. -- Pauli Virtanen From ndbecker2 at gmail.com Wed Oct 27 06:25:26 2010 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 27 Oct 2010 06:25:26 -0400 Subject: [Numpy-discussion] short circuit != ? Message-ID: Is there a way to get a short circuit != ? That is, compare 2 arrays but stop as soon as the first element comparison fails? I'm assuming that np.all (a != b) will _not_ do this, but will first compare all elements. From friedrichromstedt at gmail.com Wed Oct 27 08:36:24 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Wed, 27 Oct 2010 14:36:24 +0200 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: Hi Darren, 2010/10/19 Darren Dale : > I have the following set in my ~/.gitconfig file: > > ? ?[apply] > ? ? ? ?whitespace = fix > > ? ?[core] > ? ? ? ?autocrlf = input > > which is attempting to correct some changes in: > > branding/icons/numpylogo.svg > branding/icons/numpylogoicon.svg > tools/win32build/nsis_scripts/numpy-superinstaller.nsi.in Here an excerpt from git-config: core.autocrlf Setting this variable to "true" is almost the same as setting the text attribute to "auto" on all files except that text files are not guaranteed to be normalized: files that contain CRLF in the repository will not be touched. Use this setting if you want to have CRLF line endings in your working directory even though the repository does not have normalized line endings. This variable can be set to input, in which case no output conversion is performed. >From git-apply: ``fix`` outputs warnings for a few such errors, and applies the patch after fixing them (strip is a synonym --- the tool used to consider only trailing whitespace characters as errors, and the fix involved stripping them, but modern gits do more). So I think your "autocrlf=input" makes the .nsi.in file checked out as LF since it's in LF in the repo, and "no output conversion is performed" due to core.autocrlf=input in your .gitconfigure. So the svg changes must come from the 'fix' value for the whitespace action. I don't think it is a good idea to let whitespace be fixed by git and not by your editor :-) Or do you disagree? This whitespace & newline thing is really painful, I suggest you set in your .gitconfig: [core] autocrlf = true and in our numpy .gitattributes: * text=auto while the text=auto is more strong and a superset of autocrlf=true. I came across this when trying if text=auto marks any files as changed, and it didn't so everything IS already LF in the repo. Can you check this please? I was near to leaving a comment like "asap" on github, but since this is so horribly complicated and error-prone ... Friedrich From cohen at lpta.in2p3.fr Wed Oct 27 09:32:20 2010 From: cohen at lpta.in2p3.fr (Johann Cohen-Tanugi) Date: Wed, 27 Oct 2010 15:32:20 +0200 Subject: [Numpy-discussion] short circuit != ? In-Reply-To: References: Message-ID: <4CC829E4.7040604@lpta.in2p3.fr> how about np.any(a!=b) ?? On 10/27/2010 12:25 PM, Neal Becker wrote: > Is there a way to get a short circuit != ? > > That is, compare 2 arrays but stop as soon as the first element comparison > fails? > > I'm assuming that np.all (a != b) will _not_ do this, but will first compare > all elements. > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > From ndbecker2 at gmail.com Wed Oct 27 09:31:52 2010 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 27 Oct 2010 09:31:52 -0400 Subject: [Numpy-discussion] short circuit != ? References: <4CC829E4.7040604@lpta.in2p3.fr> Message-ID: Johann Cohen-Tanugi wrote: > how about np.any(a!=b) ?? > > On 10/27/2010 12:25 PM, Neal Becker wrote: >> Is there a way to get a short circuit != ? >> >> That is, compare 2 arrays but stop as soon as the first element >> comparison fails? >> >> I'm assuming that np.all (a != b) will _not_ do this, but will first >> compare all elements. >> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> >> I don't think that will do short ciruit, will it? I think that will compare each element, returning a bool array, then short-circuit eval that bool array. From faltet at pytables.org Wed Oct 27 09:34:31 2010 From: faltet at pytables.org (Francesc Alted) Date: Wed, 27 Oct 2010 15:34:31 +0200 Subject: [Numpy-discussion] Inconsistency with __index__() for rank-1 arrays? Message-ID: <201010271534.31139.faltet@pytables.org> Hi, I find this a bit misleading: >>> a = np.arange(10) >>> a[np.array(0)] 0 >>> a[np.array([0])] array([0]) >>> a[[0]] array([0]) But, for regular python lists we have: >>> l = a.tolist() >>> l[np.array(0)] 0 >>> l[np.array([0])] 0 i.e. indexing with a rank-0 array and a rank-1 array with one single element return the same result, which I find inconsistent with the expected behaviour for this case, i.e.: >>> l[[0]] --------------------------------------------------------------------------- TypeError Traceback (most recent call last) /tmp/tables-2.2/ in () TypeError: list indices must be integers, not list The ultimate reason for this behaviour is this: >>> np.array(0).__index__() 0 >>> np.array([0]).__index__() 0 But I wonder why NumPy needs the latter behaviour, instead of the more logical: >>> np.array([0]).__index__() --------------------------------------------------------------------------- TypeError Traceback (most recent call last) /tmp/tables-2.2/ in () TypeError: only rank-0 integer arrays can be converted to an index This inconsistency has indeed introduced a bug in my application and for solving this I'd need something like: """ def is_idx(index): """Check if an object can work as an index or not.""" if hasattr(index, "__index__"): # Only works on Python 2.5 on if (hasattr(index, "shape") and index.shape == (1,)): return False try: # (as per PEP 357) idx = index.__index__() return True except TypeError: return False return False """ i.e. for determining if an object can be an index or not, I need to explicitly check for a shape different from (1,), which is unnecessarily complicated. So I find the current behaviour prone to introduce errors in apps and I'm wondering why exactly np.array([1]) should work as an index at all. It would not be better if that would raise a ``TypeError``? Thanks, -- Francesc Alted From cohen at lpta.in2p3.fr Wed Oct 27 09:37:23 2010 From: cohen at lpta.in2p3.fr (Johann Cohen-Tanugi) Date: Wed, 27 Oct 2010 15:37:23 +0200 Subject: [Numpy-discussion] short circuit != ? In-Reply-To: References: <4CC829E4.7040604@lpta.in2p3.fr> Message-ID: <4CC82B13.9040503@lpta.in2p3.fr> On 10/27/2010 03:31 PM, Neal Becker wrote: > Johann Cohen-Tanugi wrote: > > >> how about np.any(a!=b) ?? >> >> On 10/27/2010 12:25 PM, Neal Becker wrote: >> >>> Is there a way to get a short circuit != ? >>> >>> That is, compare 2 arrays but stop as soon as the first element >>> comparison fails? >>> >>> I'm assuming that np.all (a != b) will _not_ do this, but will first >>> compare all elements. >>> >>> _______________________________________________ >>> NumPy-Discussion mailing list >>> NumPy-Discussion at scipy.org >>> http://mail.scipy.org/mailman/listinfo/numpy-discussion >>> >>> >>> > I don't think that will do short ciruit, will it? I think that will compare > each element, returning a bool array, then short-circuit eval that bool > array. > > In [3]: a=np.array([2,3, In [4]: b=np.array([2,5, In [5]: np.any(a!=b) Out[5]: True it does not return a bool array, it seems. I do not see how you would "broadcast" the notion of "any".... along axes maybe? > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > From jsseabold at gmail.com Wed Oct 27 09:44:59 2010 From: jsseabold at gmail.com (Skipper Seabold) Date: Wed, 27 Oct 2010 09:44:59 -0400 Subject: [Numpy-discussion] short circuit != ? In-Reply-To: <4CC82B13.9040503@lpta.in2p3.fr> References: <4CC829E4.7040604@lpta.in2p3.fr> <4CC82B13.9040503@lpta.in2p3.fr> Message-ID: On Wed, Oct 27, 2010 at 9:37 AM, Johann Cohen-Tanugi wrote: > > > On 10/27/2010 03:31 PM, Neal Becker wrote: >> Johann Cohen-Tanugi wrote: >> >> >>> how about np.any(a!=b) ??? >>> >>> On 10/27/2010 12:25 PM, Neal Becker wrote: >>> >>>> Is there a way to get a short circuit != ? >>>> >>>> That is, compare 2 arrays but stop as soon as the first element >>>> comparison fails? >>>> >>>> I'm assuming that np.all (a != b) will _not_ do this, but will first >>>> compare all elements. >>>> >>>> _______________________________________________ >>>> NumPy-Discussion mailing list >>>> NumPy-Discussion at scipy.org >>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion >>>> >>>> >>>> >> I don't think that will do short ciruit, will it? ?I think that will compare >> each element, returning a bool array, then short-circuit eval that bool >> array. >> >> > In [3]: a=np.array([2,3, > > In [4]: b=np.array([2,5, > > In [5]: np.any(a!=b) > Out[5]: True > > it does not return a bool array, it seems. I do not see how you would > "broadcast" the notion of "any".... along axes maybe? > Not definitive by any means, but In [28]: a = np.arange(1,10000000) In [29]: b = np.arange(1,10000000) In [30]: timeit np.any(a!=b) 10 loops, best of 3: 37.8 ms per loop In [31]: a[0] = 10. In [32]: timeit np.any(a!=b) 10 loops, best of 3: 24.7 ms per loop In [33]: a[0] = 1 In [34]: a[-1] = 1 In [35]: timeit np.any(a!=b) 10 loops, best of 3: 37.7 ms per loop It seems to at least take less time when the difference is at the "beginning," though I'm sure there could be exceptions. Skipper From pav at iki.fi Wed Oct 27 09:50:49 2010 From: pav at iki.fi (Pauli Virtanen) Date: Wed, 27 Oct 2010 13:50:49 +0000 (UTC) Subject: [Numpy-discussion] short circuit != ? References: <4CC829E4.7040604@lpta.in2p3.fr> <4CC82B13.9040503@lpta.in2p3.fr> Message-ID: Wed, 27 Oct 2010 09:44:59 -0400, Skipper Seabold wrote: [clip] > In [35]: timeit np.any(a!=b) [clip] > It seems to at least take less time when the difference is at the > "beginning," though I'm sure there could be exceptions. It performs all the comparisons to create a temporary boolean array. any() does return when it sees the first True, but this is not full short-circuiting. -- Pauli Virtanen From zachary.pincus at yale.edu Wed Oct 27 09:56:35 2010 From: zachary.pincus at yale.edu (Zachary Pincus) Date: Wed, 27 Oct 2010 09:56:35 -0400 Subject: [Numpy-discussion] short circuit != ? In-Reply-To: References: <4CC829E4.7040604@lpta.in2p3.fr> <4CC82B13.9040503@lpta.in2p3.fr> Message-ID: <97C2E813-359F-4062-AB92-1AAA1CD435C5@yale.edu> This is silly: the structure of the python language prevents meaningful short-circuiting in the case of np.any(a!=b) While it's true that np.any itself may short-circuit, the 'a!=b' statement itself will be evaluated in its entirety before the result (a boolean array) is passed to np.any. This is just how python (like most other languages) works. This means that the big-O complexity isn't reduced any: all elements of a and b have to be examined. If any short-circuits, then at least all the elements don't need to be examined twice! If performance actually matters here (unlikely?), a quick bit of cython code could do this easily enough in the simple case where a and b are the same shape (so no broadcasting required). Note that the below hard-codes the dtype also. import cython cimport numpy import numpy TYPE_T = numpy.int64_t TYPE = numpy.int64 @cython.boundscheck(False) def equal(a, b): cdef: numpy.ndarray[TYPE, ndim=1, negative_indices=False] a_flat = a.astype(TYPE).flatten() numpy.ndarray[TYPE, ndim=1, negative_indices=False] b_flat = b.astype(TYPE).flatten() unsigned int i, l assert a_flat.shape[0] == b_flat.shape[0] l = a_flat.shape[0] for i in range(l): if a_flat[i] != b_flat[i]: return False return True Zach On Oct 27, 2010, at 9:44 AM, Skipper Seabold wrote: > On Wed, Oct 27, 2010 at 9:37 AM, Johann Cohen-Tanugi > wrote: >> >> >> On 10/27/2010 03:31 PM, Neal Becker wrote: >>> Johann Cohen-Tanugi wrote: >>> >>> >>>> how about np.any(a!=b) ?? >>>> >>>> On 10/27/2010 12:25 PM, Neal Becker wrote: >>>> >>>>> Is there a way to get a short circuit != ? >>>>> >>>>> That is, compare 2 arrays but stop as soon as the first element >>>>> comparison fails? >>>>> >>>>> I'm assuming that np.all (a != b) will _not_ do this, but will >>>>> first >>>>> compare all elements. >>>>> >>>>> _______________________________________________ >>>>> NumPy-Discussion mailing list >>>>> NumPy-Discussion at scipy.org >>>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion >>>>> >>>>> >>>>> >>> I don't think that will do short ciruit, will it? I think that >>> will compare >>> each element, returning a bool array, then short-circuit eval that >>> bool >>> array. >>> >>> >> In [3]: a=np.array([2,3, >> >> In [4]: b=np.array([2,5, >> >> In [5]: np.any(a!=b) >> Out[5]: True >> >> it does not return a bool array, it seems. I do not see how you would >> "broadcast" the notion of "any".... along axes maybe? >> > > Not definitive by any means, but > > In [28]: a = np.arange(1,10000000) > > In [29]: b = np.arange(1,10000000) > > In [30]: timeit np.any(a!=b) > 10 loops, best of 3: 37.8 ms per loop > > In [31]: a[0] = 10. > > In [32]: timeit np.any(a!=b) > 10 loops, best of 3: 24.7 ms per loop > > In [33]: a[0] = 1 > > In [34]: a[-1] = 1 > > In [35]: timeit np.any(a!=b) > 10 loops, best of 3: 37.7 ms per loop > > It seems to at least take less time when the difference is at the > "beginning," though I'm sure there could be exceptions. > > Skipper > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion From alan.isaac at gmail.com Wed Oct 27 10:05:42 2010 From: alan.isaac at gmail.com (Alan G Isaac) Date: Wed, 27 Oct 2010 10:05:42 -0400 Subject: [Numpy-discussion] short circuit != ? In-Reply-To: <97C2E813-359F-4062-AB92-1AAA1CD435C5@yale.edu> References: <4CC829E4.7040604@lpta.in2p3.fr> <4CC82B13.9040503@lpta.in2p3.fr> <97C2E813-359F-4062-AB92-1AAA1CD435C5@yale.edu> Message-ID: <4CC831B6.8050808@gmail.com> On 10/27/2010 9:56 AM, Zachary Pincus wrote: > the structure of the python language prevents > meaningful short-circuiting in the case of > np.any(a!=b) Maybe: any((ai != bi) for ai,bi in izip(a.flat,b.flat)) ? fwiw, Alan Isaac From ralf.gommers at googlemail.com Wed Oct 27 10:30:46 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Wed, 27 Oct 2010 22:30:46 +0800 Subject: [Numpy-discussion] ANN: NumPy 1.5.1 release candidate 1 In-Reply-To: References: Message-ID: On Wed, Oct 27, 2010 at 1:23 AM, Friedrich Romstedt wrote: > I found some issues on Mac OS X 10.5 ppc in py2.5.4: > > See here: > > http://github.com/friedrichromstedt/numpy/tree/release%2F1.5.1rc1%2Fpy2.5-python.org-macosx10.3/release/logs/osx105rh/ The inf/exp failures should be marked as knownfail, they're not surprising. Not sure about the nextafter and spacing ones (see errors below). > > One more question: Do I have to install gfortran to do full testing? > I see some S. If you run the tests with np.test(verbose=2) you can see what's skipped. gfortran is not needed I think, but makes sense to install it anyway - the one recommended athttp://www.scipy.org/Installing_SciPy/Mac_OS_X. > > I now say my installer numpy-1.5.1rc1-py2.5-python.org-macosx10.3.dmg, > built on 10.5, is fully functional and free to the public. ?The docs > look also good now. Nice, will check and upload to SF. > > Why do we not ship with the html docs? ?I find them much more useful > than the pdf. Limit download size? Html docs can be read at http://docs.scipy.org/doc/, pdf is for off-line reading, Therefore it makes more sense to include the pdf in the installer. Cheers, Ralf ........................................................................................................Warning: overflow encountered in add Warning: invalid value encountered in subtract Warning: invalid value encountered in subtract Warning: overflow encountered in add Warning: invalid value encountered in subtract Warning: invalid value encountered in subtract ...................................................................................................................................................................................................................................................................................................................................................................K........................................................................................................................................................................................................................................K...K..................Warning: overflow encountered in ldexp .....................................F..F..............................K........F....FFFF.....K........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................S............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................. ====================================================================== FAIL: test_umath.test_nextafterl ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/nose/case.py", line 186, in runTest self.test(*self.arg) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy/testing/decorators.py", line 215, in knownfailer return f(*args, **kwargs) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy/core/tests/test_umath.py", line 1033, in test_nextafterl return _test_nextafter(np.longdouble) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy/core/tests/test_umath.py", line 1019, in _test_nextafter assert np.nextafter(one, two) - one == eps AssertionError ====================================================================== FAIL: test_umath.test_spacingl ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/nose/case.py", line 186, in runTest self.test(*self.arg) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy/testing/decorators.py", line 215, in knownfailer return f(*args, **kwargs) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy/core/tests/test_umath.py", line 1058, in test_spacingl return _test_spacing(np.longdouble) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy/core/tests/test_umath.py", line 1042, in _test_spacing assert np.spacing(one) == eps AssertionError ====================================================================== FAIL: test_umath_complex.TestCexp.test_special_values(, inf, 0, inf, 0) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/nose/case.py", line 186, in runTest self.test(*self.arg) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy/core/tests/test_umath_complex.py", line 579, in check_complex_value assert_equal(f(z1), z2) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy/testing/utils.py", line 256, in assert_equal return assert_array_equal(actual, desired, err_msg, verbose) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy/testing/utils.py", line 686, in assert_array_equal verbose=verbose, header='Arrays are not equal') File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy/testing/utils.py", line 596, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not equal (x and y nan location mismatch [ True], False mismatch) x: array([ inf nanj]) y: array((inf+0j)) ====================================================================== FAIL: test_umath_complex.TestCexp.test_special_values(None,) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/nose/case.py", line 186, in runTest self.test(*self.arg) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy/core/tests/test_umath_complex.py", line 81, in _check_ninf_inf raise AssertionError(msgform %(z.real, z.imag)) AssertionError: cexp(-inf, inf) is (nan, nan), expected (+-0, +-0) ====================================================================== FAIL: test_umath_complex.TestCexp.test_special_values(None,) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/nose/case.py", line 186, in runTest self.test(*self.arg) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy/core/tests/test_umath_complex.py", line 94, in _check_inf_inf raise AssertionError(msgform % (z.real, z.imag)) AssertionError: cexp(inf, inf) is (nan, nan), expected (+-inf, nan) ====================================================================== FAIL: test_umath_complex.TestCexp.test_special_values(None,) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/nose/case.py", line 186, in runTest self.test(*self.arg) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy/core/tests/test_umath_complex.py", line 107, in _check_ninf_nan raise AssertionError(msgform % (z.real, z.imag)) AssertionError: cexp(-inf, nan) is (nan, nan), expected (+-0, +-0) ====================================================================== FAIL: test_umath_complex.TestCexp.test_special_values(None,) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/nose/case.py", line 186, in runTest self.test(*self.arg) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy/core/tests/test_umath_complex.py", line 120, in _check_inf_nan raise AssertionError(msgform % (z.real, z.imag)) AssertionError: cexp(-inf, nan) is (nan, nan), expected (+-inf, nan) ---------------------------------------------------------------------- Ran 2992 tests in 50.256s FAILED (KNOWNFAIL=5, SKIP=1, failures=7) From ndbecker2 at gmail.com Wed Oct 27 10:34:50 2010 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 27 Oct 2010 10:34:50 -0400 Subject: [Numpy-discussion] short circuit != ? References: <4CC829E4.7040604@lpta.in2p3.fr> <4CC82B13.9040503@lpta.in2p3.fr> Message-ID: Pauli Virtanen wrote: > Wed, 27 Oct 2010 09:44:59 -0400, Skipper Seabold wrote: > [clip] >> In [35]: timeit np.any(a!=b) > [clip] >> It seems to at least take less time when the difference is at the >> "beginning," though I'm sure there could be exceptions. > > It performs all the comparisons to create a temporary boolean array. > any() does return when it sees the first True, but this is not full > short-circuiting. > I propose adding is_equal(a,b) function which does true short-ciruciting From njs at pobox.com Wed Oct 27 10:41:47 2010 From: njs at pobox.com (Nathaniel Smith) Date: Wed, 27 Oct 2010 07:41:47 -0700 Subject: [Numpy-discussion] short circuit != ? In-Reply-To: References: <4CC829E4.7040604@lpta.in2p3.fr> <4CC82B13.9040503@lpta.in2p3.fr> Message-ID: On Wed, Oct 27, 2010 at 7:34 AM, Neal Becker wrote: > I propose adding is_equal(a,b) function which does true short-ciruciting You could use np.allclose, I guess. (It isn't short-circuiting right now, but you could fix that.) -- Nathaniel From dsdale24 at gmail.com Wed Oct 27 10:58:57 2010 From: dsdale24 at gmail.com (Darren Dale) Date: Wed, 27 Oct 2010 10:58:57 -0400 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: On Wed, Oct 27, 2010 at 8:36 AM, Friedrich Romstedt wrote: > Hi Darren, > > 2010/10/19 Darren Dale : >> I have the following set in my ~/.gitconfig file: >> >> ? ?[apply] >> ? ? ? ?whitespace = fix >> >> ? ?[core] >> ? ? ? ?autocrlf = input >> >> which is attempting to correct some changes in: >> >> branding/icons/numpylogo.svg >> branding/icons/numpylogoicon.svg >> tools/win32build/nsis_scripts/numpy-superinstaller.nsi.in > > Here an excerpt from git-config: > > core.autocrlf > > ? ?Setting this variable to "true" is almost the same as setting the > text attribute to "auto" on all files except that text files are not > guaranteed to be normalized: files that contain CRLF in the repository > will not be touched. Use this setting if you want to have CRLF line > endings in your working directory even though the repository does not > have normalized line endings. This variable can be set to input, in > which case no output conversion is performed. > > >From git-apply: > > ``fix`` outputs warnings for a few such errors, and applies the patch > after fixing them (strip is a synonym --- the tool used to consider > only trailing whitespace characters as errors, and the fix involved > stripping them, but modern gits do more). > > So I think your "autocrlf=input" makes the .nsi.in file checked out as > LF since it's in LF in the repo, and "no output conversion is > performed" due to core.autocrlf=input in your .gitconfigure. > > So the svg changes must come from the 'fix' value for the whitespace action. > > I don't think it is a good idea to let whitespace be fixed by git and > not by your editor :-) ?Or do you disagree? "What are considered whitespace errors is controlled by core.whitespace configuration. By default, trailing whitespaces (including lines that solely consist of whitespaces) and a space character that is immediately followed by a tab character inside the initial indent of the line are considered whitespace errors." No mention of EOL conversions there. But yes, I guess we disagree. I prefer to have git automatically strip any trailing whitespace that I might have accidentally introduced. > This whitespace & newline thing is really painful, I suggest you set > in your .gitconfig: > > [core] > ? ?autocrlf = true I don't think so: "Use this setting if you want to have CRLF line endings in your working directory even though the repository does not have normalized line endings." I don't want CRLF in my working directory. Did you read http://help.github.com/dealing-with-lineendings/ ? > and in our numpy .gitattributes: > > * text=auto That is already included in the pull request. > while the text=auto is more strong and a superset of autocrlf=true. > > I came across this when trying if text=auto marks any files as > changed, and it didn't so everything IS already LF in the repo. > > Can you check this please? Check what? > I was near to leaving a comment like > "asap" on github, but since this is so horribly complicated and > error-prone ... I'm starting to consider canceling the pull request. Darren From gokhansever at gmail.com Wed Oct 27 11:12:30 2010 From: gokhansever at gmail.com (=?UTF-8?Q?G=C3=B6khan_Sever?=) Date: Wed, 27 Oct 2010 10:12:30 -0500 Subject: [Numpy-discussion] Median method for ndarray Message-ID: Hello, Is there a particular reason why there isn't a median method for ndarray? If not so, could we get one? Probably will go somewhere in this file: http://github.com/numpy/numpy/blob/master/numpy/core/src/multiarray/methods.c I find it more practical to do array.mean() rather than np.mean(array), likewise would be useful having a similar method for median calculation. Thanks. -- G?khan From friedrichromstedt at gmail.com Wed Oct 27 11:31:59 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Wed, 27 Oct 2010 17:31:59 +0200 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: Hi Darren, 2010/10/27 Darren Dale : >> So the svg changes must come from the 'fix' value for the whitespace action. >> >> I don't think it is a good idea to let whitespace be fixed by git and >> not by your editor :-) ?Or do you disagree? > > "What are considered whitespace errors is controlled by > core.whitespace configuration. By default, trailing whitespaces > (including lines that solely consist of whitespaces) and a space > character that is immediately followed by a tab character inside the > initial indent of the line are considered whitespace errors." > > No mention of EOL conversions there. But yes, I guess we disagree. I > prefer to have git automatically strip any trailing whitespace that I > might have accidentally introduced. I agree. But I just guess that the changes of the svgs in your pull request might be not due to eols but due to whitespace fixes. I think so because in my numpy (current master branch) I cannot see any CRLF there in the repo. Checked with ``* text=auto``, which also affects non-normalised files in the repo. But it might be that the conversion is done silently, although I don't know how to do it like that. So no "changed" showing up implies "no non-LF eol". >> This whitespace & newline thing is really painful, I suggest you set >> in your .gitconfig: >> >> [core] >> ? ?autocrlf = true > > I don't think so: "Use this setting if you want to have CRLF line > endings in your working directory even though the repository does not > have normalized line endings." I don't want CRLF in my working > directory. Did you read > http://help.github.com/dealing-with-lineendings/ ? Aha, this is a misunderstanding. Somehow I thought you're working on Windows. Is there then a specific reason not to use CRLF? I mean, you can check it in with LF anyway. The page you mentioned is very brief and like a recipe, not my taste. I want to know what's going on in detail. >> and in our numpy .gitattributes: >> >> * text=auto > > That is already included in the pull request. Yes, I know. I meant to leave the line with the eol=crlf alone. All based on the assumtion that you're working with crlf anyway, so might be wrong. >> while the text=auto is more strong and a superset of autocrlf=true. >> >> I came across this when trying if text=auto marks any files as >> changed, and it didn't so everything IS already LF in the repo. >> >> Can you check this please? > > Check what? My conclusions above. We both know that in this subject all conclusions are pretty error-prone ... >> I was near to leaving a comment like >> "asap" on github, but since this is so horribly complicated and >> error-prone ... > > I'm starting to consider canceling the pull request. At least we should check if it's really what we intend. I understand now better why at all you wanted to force the .nsi.in file to be crlf. From your previous posts, i.e. that it would be the default for Win users anyway, I see now that I should have asked. To my understanding the strategy should be two things: 1) LF force in the repo. This is independent from the .nsi.in thing, but missing currently in the official branches. We can do that at the same time. 2) Forcing the .nsi.in file to be crlf in the check-out (and only there) at all times. There is one higher level in $GITDIR, but I think we can ignore that. To (1): The default Win user would check-in *newly created* files currently in CRLF, at least this is what I did with a not-so-recent git some time ago (other repos) .... When I switched to Mac, all my files were marked "changed". afaik git does not do normalisation if you do not tell it to do so. "While git normally leaves file contents alone, it can be configured to normalize line endings to LF in the repository and, optionally, to convert them to CRLF when files are checked out." (http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html) I still do not understand why my files showed up changed. They're still crlf, I just copied them, and vim tells [dos]. Please also confirm or show that I'm wrong with my observation of LFCR in your .nsi.in file instead of CRLF (it's swapped). I checked as written before. http://article.gmane.org/gmane.comp.python.numeric.general/41063. This would also explain how it can make it into the repo (i.e., succeed in :-) and still be not detected by git when ``* text=auto`` is active. Git thinks it's \n since theres no \r before, and does not consider the \r which is trailing. Best wishes, Friedrich P.S.: Might be worth putting this OL, I believe noone besides us is interested. If you agree. From numpy-discussion at maubp.freeserve.co.uk Wed Oct 27 11:38:13 2010 From: numpy-discussion at maubp.freeserve.co.uk (Peter) Date: Wed, 27 Oct 2010 16:38:13 +0100 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: On Wed, Oct 27, 2010 at 4:31 PM, Friedrich Romstedt wrote: > > P.S.: Might be worth putting this OL, I believe noone besides us is > interested. ?If you agree. > I'm interested since we also use git (and github) for a Python project which is developed and tested on Linux, Mac OS X and Windows. We haven't done anything special with the repository settings about line endings... but so far it seems to be working with the defaults. Peter From robert.kern at gmail.com Wed Oct 27 11:38:48 2010 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 27 Oct 2010 10:38:48 -0500 Subject: [Numpy-discussion] Median method for ndarray In-Reply-To: References: Message-ID: On Wed, Oct 27, 2010 at 10:12, G?khan Sever wrote: > Hello, > > Is there a particular reason why there isn't a median method for > ndarray? numpy.median() is coded in Python, not C. There is often no particular reason that a numpy function is duplicated as an ndarray method except that when numpy was made, many of those functions were already in C and could be easily made into methods. A choice was made at that time to make many of those methods. The reasoning behind that choice is not always strong. > If not so, could we get one? -1. Not every function in numpy must be an ndarray method. I don't want to dilute the methods further. -- 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 From friedrichromstedt at gmail.com Wed Oct 27 11:44:28 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Wed, 27 Oct 2010 17:44:28 +0200 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: It **IS** CRLF, I have no idea what I did wrong, but n0877:nsis_scripts Friedrich$ od -c numpy-superinstaller.nsi.in 0000000 ; - - - - - - - - - - - - - - - 0000020 - - - - - - - - - - - - - - - - 0000040 - \r \n ; I n c l u d e M o d e 0000060 r n U I \r \n \r \n ! i n c l u d 0000100 e " M U I 2 . n s h " \r \n \r \n I'm not THAT interested to search for my mistake if noone else sees the spot. od -c seems more robust anyway. I saw more than only double newlines, whatever :-( Friedrich From friedrichromstedt at gmail.com Wed Oct 27 11:49:48 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Wed, 27 Oct 2010 17:49:48 +0200 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: Hi Peter, 2010/10/27 Peter : > I'm interested since we also use git (and github) for a Python > project which is developed and tested on Linux, Mac OS X > and Windows. We haven't done anything special with the > repository settings about line endings... but so far it seems > to be working with the defaults. I can only guess, but I bet that you're using vim or any other editor which can handle both. Since Python has universal newline support, it can also read both. Seems that you're lucky that it's Python ..... :-) You might use the od -c on Linux and Mac to check which files were created on Win and which on LF OSes ... supposed that I'm right at all. Would be a good check of my assumptions. Friedrich From numpy-discussion at maubp.freeserve.co.uk Wed Oct 27 12:00:43 2010 From: numpy-discussion at maubp.freeserve.co.uk (Peter) Date: Wed, 27 Oct 2010 17:00:43 +0100 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: On Wed, Oct 27, 2010 at 4:49 PM, Friedrich Romstedt wrote: > > Hi Peter, > > 2010/10/27 Peter : >> I'm interested since we also use git (and github) for a Python >> project which is developed and tested on Linux, Mac OS X >> and Windows. We haven't done anything special with the >> repository settings about line endings... but so far it seems >> to be working with the defaults. > > I can only guess, but I bet that you're using vim or any other editor > which can handle both. ?Since Python has universal newline support, it > can also read both. ?Seems that you're lucky that it's Python ..... > :-) > > You might use the od -c on Linux and Mac to check which files were > created on Win and which on LF OSes ... supposed that I'm right at > all. > > Would be a good check of my assumptions. > > Friedrich Why use od when I can use Python ;) (see below) I've just tested a checkout of our repository on Mac OS X, and found a single Python file with Windows newlines (CRLF) but I'm pretty sure that happened before we moved to git. Peter -- #Quick script to check for potential new line issues #or tab indentation instead of spaces import os def check(filename): #load in binary mode as I want to see any \r handle = open(filename, "rb") for line in handle: if "\t" in line or "\r" in line: print filename, repr(line) handle.close() for dirpath, dirnames, filenames in os.walk("."): for f in filenames: if f.endswith(".py"): check(os.path.join(dirpath,f)) print "Done" From friedrichromstedt at gmail.com Wed Oct 27 12:08:47 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Wed, 27 Oct 2010 18:08:47 +0200 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: 2010/10/27 Peter : > Why use od when I can use Python ;) ?(see below) Did not come around that trick with 'b'. Good catch :-) So you mean you don't have that file in the repo? May it be that all the files have been created on a LF machine except this single file? Because once they are created the editor will maintain the eol convention. vim does at least. Thanks for your time! Friedrich From numpy-discussion at maubp.freeserve.co.uk Wed Oct 27 12:47:32 2010 From: numpy-discussion at maubp.freeserve.co.uk (Peter) Date: Wed, 27 Oct 2010 17:47:32 +0100 Subject: [Numpy-discussion] NumPy FAQ and Python 3 support Message-ID: Hi all, This FAQ (found via Google) is out of date regarding Python 3 support: http://new.scipy.org/faq.html#does-numpy-currently-work-with-python-3-x-what-about-scipy Peter From numpy-discussion at maubp.freeserve.co.uk Wed Oct 27 12:49:41 2010 From: numpy-discussion at maubp.freeserve.co.uk (Peter) Date: Wed, 27 Oct 2010 17:49:41 +0100 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: On Wed, Oct 27, 2010 at 5:08 PM, Friedrich Romstedt wrote: > > 2010/10/27 Peter : >> Why use od when I can use Python ;) ?(see below) > > Did not come around that trick with 'b'. ?Good catch :-) > > So you mean you don't have that file in the repo? > > May it be that all the files have been created on a LF machine except > this single file? ?Because once they are created the editor will > maintain the eol convention. ?vim does at least. > > Thanks for your time! > > Friedrich There was one Python file in our repository which used Windows/DOS line endings - I believe this would have been created by a developer on Windows back when we used CVS (the repository was later migrated to git). Peter From xscript at gmx.net Wed Oct 27 13:06:36 2010 From: xscript at gmx.net (=?utf-8?Q?Llu=C3=ADs?=) Date: Wed, 27 Oct 2010 19:06:36 +0200 Subject: [Numpy-discussion] short circuit != ? In-Reply-To: <4CC831B6.8050808@gmail.com> (Alan G. Isaac's message of "Wed, 27 Oct 2010 10:05:42 -0400") References: <4CC829E4.7040604@lpta.in2p3.fr> <4CC82B13.9040503@lpta.in2p3.fr> <97C2E813-359F-4062-AB92-1AAA1CD435C5@yale.edu> <4CC831B6.8050808@gmail.com> Message-ID: <874oc7ftur.fsf@ginnungagap.bsc.es> Alan G Isaac writes: > Maybe: > any((ai != bi) for ai,bi in izip(a.flat,b.flat)) > ? I think this would indeed work, but it's not really friendly, while it should work out-of-the-box. Of course, we do not always want operations to perform lazily, so a generic approach might be on the lines of: any(a.lazy() != b) Invoking 'lazy' on an ndarray would return an object that instead of computing the given operations will just record them, and try to defer their evaluation as much as possible. E.g.,: class LazyNdarray: def __init__ (self, left, op = None, right = None): self._left = left self._op = op self._right = right # transitivize deferral on these operations def __neq__ (self, other): return LazyNdarray(self, "__neq__", other) # evaluate on these operations def __getitem__ (self, index): return self._evaluate(index) def __iter__ (self): for idx in range(len(self._left)): yield self._evaluate(idx) # do the evaluation def _evaluate (self, index) # still, this will not work unles no broadcast is necessary l = self._left[index] op = getattr(l, self._op) return op(right[index]) class ndarray: def lazy (self): return LazyNdarray(self) Or something like that. Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth From charlesr.harris at gmail.com Wed Oct 27 13:30:16 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Wed, 27 Oct 2010 11:30:16 -0600 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: On Wed, Oct 27, 2010 at 8:58 AM, Darren Dale wrote: > On Wed, Oct 27, 2010 at 8:36 AM, Friedrich Romstedt > wrote: > > Hi Darren, > > > > 2010/10/19 Darren Dale : > >> I have the following set in my ~/.gitconfig file: > >> > >> [apply] > >> whitespace = fix > >> > >> [core] > >> autocrlf = input > >> > >> which is attempting to correct some changes in: > >> > >> branding/icons/numpylogo.svg > >> branding/icons/numpylogoicon.svg > >> tools/win32build/nsis_scripts/numpy-superinstaller.nsi.in > > > > Here an excerpt from git-config: > > > > core.autocrlf > > > > Setting this variable to "true" is almost the same as setting the > > text attribute to "auto" on all files except that text files are not > > guaranteed to be normalized: files that contain CRLF in the repository > > will not be touched. Use this setting if you want to have CRLF line > > endings in your working directory even though the repository does not > > have normalized line endings. This variable can be set to input, in > > which case no output conversion is performed. > > > > >From git-apply: > > > > ``fix`` outputs warnings for a few such errors, and applies the patch > > after fixing them (strip is a synonym --- the tool used to consider > > only trailing whitespace characters as errors, and the fix involved > > stripping them, but modern gits do more). > > > > So I think your "autocrlf=input" makes the .nsi.in file checked out as > > LF since it's in LF in the repo, and "no output conversion is > > performed" due to core.autocrlf=input in your .gitconfigure. > > > > So the svg changes must come from the 'fix' value for the whitespace > action. > > > > I don't think it is a good idea to let whitespace be fixed by git and > > not by your editor :-) Or do you disagree? > > "What are considered whitespace errors is controlled by > core.whitespace configuration. By default, trailing whitespaces > (including lines that solely consist of whitespaces) and a space > character that is immediately followed by a tab character inside the > initial indent of the line are considered whitespace errors." > > No mention of EOL conversions there. But yes, I guess we disagree. I > prefer to have git automatically strip any trailing whitespace that I > might have accidentally introduced. > > > This whitespace & newline thing is really painful, I suggest you set > > in your .gitconfig: > > > > [core] > > autocrlf = true > > I don't think so: "Use this setting if you want to have CRLF line > endings in your working directory even though the repository does not > have normalized line endings." I don't want CRLF in my working > directory. Did you read > http://help.github.com/dealing-with-lineendings/ ? > > > and in our numpy .gitattributes: > > > > * text=auto > > That is already included in the pull request. > > > while the text=auto is more strong and a superset of autocrlf=true. > > > > I came across this when trying if text=auto marks any files as > > changed, and it didn't so everything IS already LF in the repo. > > > > Can you check this please? > > Check what? > > > I was near to leaving a comment like > > "asap" on github, but since this is so horribly complicated and > > error-prone ... > > I'm starting to consider canceling the pull request. > > I'd like to do something here, but I'm waiting for a consensus and for someone to test things out, maybe with a test repo, to make sure things operate correctly. The documentation isn't that clear... Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwwiebe at gmail.com Wed Oct 27 13:33:43 2010 From: mwwiebe at gmail.com (Mark Wiebe) Date: Wed, 27 Oct 2010 10:33:43 -0700 Subject: [Numpy-discussion] adding 'order=' keyword arg to ravel and others In-Reply-To: References: Message-ID: On Wed, Oct 27, 2010 at 2:36 AM, Pauli Virtanen wrote: > There is the following problem: > > >>> import numpy as np > >>> x=np.arange(9).reshape(3,3) > >>> x.T.flatten() > array([0, 3, 6, 1, 4, 7, 2, 5, 8]) > >>> x.T.flatten(order=None) > array([0, 1, 2, 3, 4, 5, 6, 7, 8]) > > PyArray_OrderConverter interprets `None` as "A". However, this problem is > already there with `reshape`, so this patch looks good to me -- fixing > OrderConverter is a separate job. The name 'A' for 'Any' doesn't seem right to me either -- 'P' for 'Preserve' or 'K' for 'Keep' would make more sense to me. -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From friedrichromstedt at gmail.com Wed Oct 27 13:35:39 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Wed, 27 Oct 2010 19:35:39 +0200 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: 2010/10/27 Charles R Harris : > I'd like to do something here, but I'm waiting for a consensus and for > someone to test things out, maybe with a test repo, to make sure things > operate correctly. The documentation isn't that clear... Okay, I'll do that tomorrow (in ~13 hr). I feel responsible. I can try it on Mac OS and Win 7. I'll use recent mingw git for Win 7. Nevertheless I have so much warm fish atm .... :( Friedrich From dsdale24 at gmail.com Wed Oct 27 13:39:55 2010 From: dsdale24 at gmail.com (Darren Dale) Date: Wed, 27 Oct 2010 13:39:55 -0400 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: On Wed, Oct 27, 2010 at 11:31 AM, Friedrich Romstedt wrote: > Hi Darren, > > 2010/10/27 Darren Dale : >>> So the svg changes must come from the 'fix' value for the whitespace action. >>> >>> I don't think it is a good idea to let whitespace be fixed by git and >>> not by your editor :-) ?Or do you disagree? >> >> "What are considered whitespace errors is controlled by >> core.whitespace configuration. By default, trailing whitespaces >> (including lines that solely consist of whitespaces) and a space >> character that is immediately followed by a tab character inside the >> initial indent of the line are considered whitespace errors." >> >> No mention of EOL conversions there. But yes, I guess we disagree. I >> prefer to have git automatically strip any trailing whitespace that I >> might have accidentally introduced. > > I agree. ?But I just guess that the changes of the svgs in your pull > request might be not due to eols but due to whitespace fixes. No, it was not. I explicitly checked the svg files before and after, using open("foo.svg").readlines[0], and saw that the files were CRLF before the commit on my branch, and LF after. > I think > so because in my numpy (current master branch) I cannot see any CRLF > there in the repo. ?Checked with ``* text=auto``, which also affects > non-normalised files in the repo. > > But it might be that the conversion is done silently, although I don't > know how to do it like that. ?So no "changed" showing up implies "no > non-LF eol". > >>> This whitespace & newline thing is really painful, I suggest you set >>> in your .gitconfig: >>> >>> [core] >>> ? ?autocrlf = true >> >> I don't think so: "Use this setting if you want to have CRLF line >> endings in your working directory even though the repository does not >> have normalized line endings." I don't want CRLF in my working >> directory. Did you read >> http://help.github.com/dealing-with-lineendings/ ? > > Aha, this is a misunderstanding. ?Somehow I thought you're working on > Windows. ?Is there then a specific reason not to use CRLF? ?I mean, > you can check it in with LF anyway. > > The page you mentioned is very brief and like a recipe, not my taste. > I want to know what's going on in detail. > >>> and in our numpy .gitattributes: >>> >>> * text=auto >> >> That is already included in the pull request. > > Yes, I know. ?I meant to leave the line with the eol=crlf alone. ?All > based on the assumtion that you're working with crlf anyway, so might > be wrong. > >>> while the text=auto is more strong and a superset of autocrlf=true. >>> >>> I came across this when trying if text=auto marks any files as >>> changed, and it didn't so everything IS already LF in the repo. >>> >>> Can you check this please? >> >> Check what? > > My conclusions above. ?We both know that in this subject all > conclusions are pretty error-prone ... > >>> I was near to leaving a comment like >>> "asap" on github, but since this is so horribly complicated and >>> error-prone ... >> >> I'm starting to consider canceling the pull request. > > At least we should check if it's really what we intend. > > I understand now better why at all you wanted to force the .nsi.in > file to be crlf. ?From your previous posts, i.e. that it would be the > default for Win users anyway, I see now that I should have asked. > > To my understanding the strategy should be two things: > 1) ?LF force in the repo. ?This is independent from the .nsi.in thing, > but missing currently in the official branches. ?We can do that at the > same time. > 2) ?Forcing the .nsi.in file to be crlf in the check-out (and only > there) at all times. ?There is one higher level in $GITDIR, but I > think we can ignore that. > > To (1): The default Win user would check-in *newly created* files > currently in CRLF, at least this is what I did with a not-so-recent > git some time ago (other repos) .... When I switched to Mac, all my > files were marked "changed". ?afaik git does not do normalisation if > you do not tell it to do so. "While git normally leaves file contents > alone, it can be configured to normalize line endings to LF in the > repository and, optionally, to convert them to CRLF when files are > checked out." (http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html) > ?I still do not understand why my files showed up changed. ?They're > still crlf, I just copied them, and vim tells [dos]. > > Please also confirm or show that I'm wrong with my observation of LFCR > in your .nsi.in file instead of CRLF (it's swapped). I thought this was already settled. OK, on my whitespace-cleanup branch, I modify .gitattributes to comment out the line about the nsi.in file. I check out the nsi.in file from HEAD, and: In [1]: open('tools/win32build/nsis_scripts/numpy-superinstaller.nsi.in').readlines()[0] Out[1]: ';--------------------------------\n' Then I do git checkout HEAD^ tools/win32build/nsis_scripts/numpy-superinstaller.nsi.in : In [1]: open('tools/win32build/nsis_scripts/numpy-superinstaller.nsi.in').readlines()[0] Out[1]: ';--------------------------------\r\n' CRLF, not LFCR. > I checked as > written before. > http://article.gmane.org/gmane.comp.python.numeric.general/41063. > This would also explain how it can make it into the repo (i.e., > succeed in :-) and still be not detected by git when ``* text=auto`` > is active. ?Git thinks it's \n since theres no \r before, and does not > consider the \r which is trailing. > > Best wishes, > Friedrich > > P.S.: Might be worth putting this OL, I believe noone besides us is > interested. ?If you agree. I'm losing interest myself. I don't think the issue is so complicated, there just seems to be a lot of confusing misinformation being posted here. From friedrichromstedt at gmail.com Wed Oct 27 13:50:00 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Wed, 27 Oct 2010 19:50:00 +0200 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: 2010/10/27 Darren Dale : > I'm losing interest myself. I don't think the issue is so complicated, > there just seems to be a lot of confusing misinformation being posted > here. I apologise for all misinformation I posted. I always double-check before sending. Believe me or not. I think the subject is simple but hard to treat because of all those options and their interaction? It's hard for me to get a clear picture at all. I guess that's the reason why the docs are soo long. Compared to the simplicity of \n != \r\n. I will try to get some psuedo code instead of narrative cheap talking, then we can simply check. Guess the code is shorter than the docs are :( Friedrich From friedrichromstedt at gmail.com Wed Oct 27 16:41:55 2010 From: friedrichromstedt at gmail.com (Friedrich Romstedt) Date: Wed, 27 Oct 2010 22:41:55 +0200 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: attribute: 'true', 'false', '', '' attributes: text, eol, core.autocrlf filters: left alone. core.safecrlf: left alone. results. normalise: True, False workingdir_fmt: 'lf', 'crlf' # Apply text. # Can be skipped on check-out. if text == 'true': normalise = True elif text == 'false': normalise = False elif text == 'auto': normalise = file_is_text elif text == '': if file_is_text and core.autocrlf: # depends on is_normalised, in_repo # 0 0: True # 0 1: False # 1 0: N/A (does not occur) # 1 1: True normalise = not (in_repo and not is_normalised) # Except it is unnormalised in repo, do normalise. else: normalise = False # SO we should think about "text" as "normalise_preference" # Two levels of indentation get necessarily prosaic ... # Define default fmt. if core.autocrlf: workingdir_fmt = 'crlf' else: workingdir_fmt = core.eol # defaults to native # Apply eol attribute. if eol == 'lf': normalise = True workingdir_fmt = 'lf' elif eol == 'crlf': normalise = True workingdir_fmt = 'crlf' else: pass # Translation of crlf attribute: # crlf == 'true' => text = 'true' # crlf == 'false' => text = 'false' # crlf == 'input' => eol = 'lf' CHECKING IN if normalise: checkin(normalise(file)) else: checkin(file) CHECKING OUT checkout(file, workingdir_fmt) NOTES Files are not changed without a checkin. So I think Darren's last pull req is just perfect. I was just worried about the mechanisms that lead to the changes, but when Darren says they are all okay and sensible then I think they are. Maybe the pseudo code would be useful for somehow git docs too, I mean the people who use git are coders and not philologists. I checked the code but I cannot fully exclude bugs, as usual .. Friedrich From nicolaiheitz at gmx.de Wed Oct 27 16:50:47 2010 From: nicolaiheitz at gmx.de (Nicolai Heitz) Date: Wed, 27 Oct 2010 13:50:47 -0700 Subject: [Numpy-discussion] problems with numdifftools Message-ID: <4CC890A7.2040208@gmx.de> m 27.10.2010 02:02, schrieb Sebastian Walter: > On Wed, Oct 27, 2010 at 12:59 AM, Pauli Virtanen wrote: >> Tue, 26 Oct 2010 14:24:39 -0700, Nicolai Heitz wrote: >>>> http://mail.scipy.org/mailman/listinfo/scipy-user >>> I contacted them already but they didn't responded so far and I was >>> forwarded to that list which was supposed to be more appropriated. >> I think you are thinking here about some other list -- scipy-user >> is the correct place for this discussion (and I don't remember seeing >> your mail there). I was pretty sure that I put it there. Unfortunately it had a different name there: Errors in calculation of the Hessian using numdifftools. But I can't find the post by myself at the moment so maybe something went wrong. >> [clip] >>> 1) Can I make it run/fix it, so that it is also going to work for the SI >>> scaling? >> Based on a brief look, it seems that uniform scaling will not help you, >> as you have two very different length scales in the problem, >> >> 1/sqrt(m w^2)>> C >> >> If you go to CM+relative coordinates you might be able to scale them >> separately, but that's fiddly and might not work for larger N. >> >> In your problem, things go wrong when the ratio between the >> length scales approaches 1e-15 which happens to be the machine epsilon. >> This implies that the algorithm runs into some problems caused by the >> finite precision of floating-point numbers. >> >> What exactly goes wrong and how to fix it, no idea --- I didn't look into >> how Numdifftools is implemented. Probably you are right. I converted it to natural units and it worked out in the 2 ion case. Increasing the number of ions leads to problems again and I have no idea where those problems come from. >>> 2) How can I be sure that increasing the number of ions or adding a >>> somehow more complicated term to the potential energy is not causing the >>> same problems even in natural units? >>> >>> 3) In which range is numdifftools working properly. >> That depends on the algorithm and the problem. Personally, I wouldn't >> trust numerical differentiation if the problem has significantly >> different length scales, it is important to capture all of them >> accurately, and it is not clear how to scale them to the same size. >> Writing ND software that works as expected all the time is probably >> not possible even in theory. >> >> Numerical differentiation is not the only game in the town. I'd look >> into automatic differentiation (AD) -- there are libraries available >> for Python also for that, and it is numerically stable. >> >> E.g. >> >> http://en.wikipedia.org/wiki/Automatic_differentiation#Software >> >> has a list of Python libraries. I don't know which of them would be >> the best ones, though. >> > they all have their pro's and con's. > Being (co-)author of some of these tools, my personal and very biased advice is: > if you are on Linux, I would go for PYADOLC. it provides bindings to a > feature-rich and well-tested C++ library. > However, the installation is a little tricker than a "setup.py build" > since you will need to compile ADOL-C and get Boost::Python to work. > PYADOLC can also differentiate much more complicated code than your > example in a relatively efficient manner. Is there by chance any possibility to make PYADOLC run on a (lame) windows xp engine. If not what else would u recommend (besides switching to Linux, what I am going to do soon). > For your example the code looks like: > > --------------------- code --------------------------- > > .... > > c=classicalHamiltonian() > xopt = optimize.fmin(c.potential, c.initialposition(), xtol = 1e-10) > > import adolc; import numpy > > # trace the computation > adolc.trace_on(0) > x = adolc.adouble(c.initialposition()) > adolc.independent(x) > y = c.potential(x) > adolc.dependent(y) > adolc.trace_off() > > hessian = adolc.hessian(0, xopt) > eigenvalues = numpy.linalg.eigh(hessian)[0] > normal_modes = c.normal_modes(eigenvalues) > print 'hessian=\n',hessian > print 'eigenvalues=\n',eigenvalues > print 'normal_modes=\n',normal_modes > --------------------- code --------------------------- > > and you get as output > Optimization terminated successfully. > Current function value: 0.000000 > Iterations: 81 > Function evaluations: 153 > hessian= > [[ 5.23748399e-12 -2.61873843e-12] > [ -2.61873843e-12 5.23748399e-12]] > eigenvalues= > [ 2.61874556e-12 7.85622242e-12] > normal_modes= > [ 6283185.30717959 10882786.30440101] > > > Also, you should use an eigenvalue solver for symmetric matrices, e.g. > numpy.linalg.eigh. > Your code example looks awesome and leads to the correct results. Thank you very much. I try to make it work on my pc as well. > regards, > Sebastian > >> -- >> Pauli Virtanen >> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion From rpmuller at gmail.com Wed Oct 27 16:58:32 2010 From: rpmuller at gmail.com (Rick Muller) Date: Wed, 27 Oct 2010 14:58:32 -0600 Subject: [Numpy-discussion] The truth value of an array with more than one element is ambiguous. Use a.any() or a.all() Message-ID: Help! I'm having a problem in searching through the *elements* if a 2d array. I have a loop over a numpy array: n,m = G.shape print n,m for i in xrange(n): for j in xrange(m): print type(G), type(G[i,j]), type(float(G[i,j])) g = float(abs(G[i,j])) if g < cut: print i,j,G[i,j] However, I'm getting the error message: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all() despite the fact that I'm not computing a truth value of an array. I'd like to just compare to G[i,j] or abs(G[i,j]), which should be a *single* value, and *not* an array. I even call 'float' here to make sure that I cast this to a normal python float. But I still get this error message. At this point, I suspect that I'm doing something dumb, rather than discovering some unique bug in numpy. Can anyone help me out? -- Rick Muller rpmuller at gmail.com 505-750-7557 -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.kern at gmail.com Wed Oct 27 17:00:39 2010 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 27 Oct 2010 16:00:39 -0500 Subject: [Numpy-discussion] The truth value of an array with more than one element is ambiguous. Use a.any() or a.all() In-Reply-To: References: Message-ID: On Wed, Oct 27, 2010 at 15:58, Rick Muller wrote: > Help! I'm having a problem in searching through the *elements* if a 2d > array. I have a loop over a numpy array: > > ??? n,m = G.shape > ??? print n,m > ??? for i in xrange(n): > ??????? for j in xrange(m): > ??????????? print type(G), type(G[i,j]), type(float(G[i,j])) > ??????????? g = float(abs(G[i,j])) > ??????????? if g < cut: > ??????????????? print i,j,G[i,j] > > However, I'm getting the error message: > > ??? The truth value of an array with more than one element is ambiguous. Use > a.any() or a.all() > > despite the fact that I'm not computing a truth value of an array. I'd like > to just compare to G[i,j] or abs(G[i,j]), which should be a *single* value, > and *not* an array. I even call 'float' here to make sure that I cast this > to a normal python float. But I still get this error message. > > At this point, I suspect that I'm doing something dumb, rather than > discovering some unique bug in numpy. Can anyone help me out? Can you provide a complete, self-contained example that does not work? What kind of object is cut? -- 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 From zachary.pincus at yale.edu Wed Oct 27 17:04:59 2010 From: zachary.pincus at yale.edu (Zachary Pincus) Date: Wed, 27 Oct 2010 17:04:59 -0400 Subject: [Numpy-discussion] The truth value of an array with more than one element is ambiguous. Use a.any() or a.all() In-Reply-To: References: Message-ID: > Help! I'm having a problem in searching through the *elements* if a > 2d array. I have a loop over a numpy array: > > n,m = G.shape > print n,m > for i in xrange(n): > for j in xrange(m): > print type(G), type(G[i,j]), type(float(G[i,j])) > g = float(abs(G[i,j])) > if g < cut: > print i,j,G[i,j] > > However, I'm getting the error message: > > The truth value of an array with more than one element is > ambiguous. Use a.any() or a.all() > > despite the fact that I'm not computing a truth value of an array. > I'd like to just compare to G[i,j] or abs(G[i,j]), which should be a > *single* value, and *not* an array. I even call 'float' here to make > sure that I cast this to a normal python float. But I still get this > error message. Which line is raising the error? My guess is it's the only truth-value testing line: "if g < cut". (I'm not sure what else could error here in that way...) It looks like g is probably a scalar, but your code isn't showing where cut comes from, nor have you printed out it's type... is it an array? Zach From rpmuller at gmail.com Wed Oct 27 18:31:17 2010 From: rpmuller at gmail.com (Rick Muller) Date: Wed, 27 Oct 2010 16:31:17 -0600 Subject: [Numpy-discussion] The truth value of an array with more than one element is ambiguous. Use a.any() or a.all() In-Reply-To: References: Message-ID: Robert, Zachary, Thanks for the quick help. I tried to write a little self-contained example of the crash, but it wasn't working. (I'm sure you've already figured out how this ends.) When I tracked down why it wasn't working, I found my bug. Turned out that cut, which I assumed was just a small scalar value, was actually a matrix, since I was passing in the wrong number of arguments to the function. Hence the confusing error. Thanks again, and sorry for wasting your time. Rick On Wed, Oct 27, 2010 at 3:04 PM, Zachary Pincus wrote: > > Help! I'm having a problem in searching through the *elements* if a > > 2d array. I have a loop over a numpy array: > > > > n,m = G.shape > > print n,m > > for i in xrange(n): > > for j in xrange(m): > > print type(G), type(G[i,j]), type(float(G[i,j])) > > g = float(abs(G[i,j])) > > if g < cut: > > print i,j,G[i,j] > > > > However, I'm getting the error message: > > > > The truth value of an array with more than one element is > > ambiguous. Use a.any() or a.all() > > > > despite the fact that I'm not computing a truth value of an array. > > I'd like to just compare to G[i,j] or abs(G[i,j]), which should be a > > *single* value, and *not* an array. I even call 'float' here to make > > sure that I cast this to a normal python float. But I still get this > > error message. > > Which line is raising the error? > My guess is it's the only truth-value testing line: "if g < cut". (I'm > not sure what else could error here in that way...) It looks like g is > probably a scalar, but your code isn't showing where cut comes from, > nor have you printed out it's type... is it an array? > > Zach > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -- Rick Muller rpmuller at gmail.com 505-750-7557 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian.walter at gmail.com Thu Oct 28 04:47:28 2010 From: sebastian.walter at gmail.com (Sebastian Walter) Date: Thu, 28 Oct 2010 10:47:28 +0200 Subject: [Numpy-discussion] problems with numdifftools In-Reply-To: <4CC890A7.2040208@gmx.de> References: <4CC890A7.2040208@gmx.de> Message-ID: On Wed, Oct 27, 2010 at 10:50 PM, Nicolai Heitz wrote: > m 27.10.2010 02:02, schrieb Sebastian Walter: > >> ?On Wed, Oct 27, 2010 at 12:59 AM, Pauli Virtanen ? wrote: >>> ?Tue, 26 Oct 2010 14:24:39 -0700, Nicolai Heitz wrote: >>>>> ? ?http://mail.scipy.org/mailman/listinfo/scipy-user >>>> ?I contacted them already but they didn't responded so far and I was >>>> ?forwarded to that list which was supposed to be more appropriated. >>> ?I think you are thinking here about some other list -- scipy-user >>> ?is the correct place for this discussion (and I don't remember seeing >>> ?your mail there). > I was pretty sure that I put it there. Unfortunately it had a different > name there: Errors in calculation of the Hessian using numdifftools. But > I can't find the post by myself at the moment so maybe something went > wrong. >>> ?[clip] >>>> ?1) Can I make it run/fix it, so that it is also going to work for the SI >>>> ?scaling? >>> ?Based on a brief look, it seems that uniform scaling will not help you, >>> ?as you have two very different length scales in the problem, >>> >>> ? ? ? ? ?1/sqrt(m w^2)>> ? C >>> >>> ?If you go to CM+relative coordinates you might be able to scale them >>> ?separately, but that's fiddly and might not work for larger N. >>> >>> ?In your problem, things go wrong when the ratio between the >>> ?length scales approaches 1e-15 which happens to be the machine epsilon. >>> ?This implies that the algorithm runs into some problems caused by the >>> ?finite precision of floating-point numbers. >>> >>> ?What exactly goes wrong and how to fix it, no idea --- I didn't look into >>> ?how Numdifftools is implemented. > > Probably you are right. I converted it to natural units and it worked > out in the 2 ion case. Increasing the number of ions leads to problems > again and I have no idea where those problems come from. > >>>> ?2) How can I be sure that increasing the number of ions or adding a >>>> ?somehow more complicated term to the potential energy is not causing the >>>> ?same problems even in natural units? >>>> >>>> ?3) In which range is numdifftools working properly. >>> ?That depends on the algorithm and the problem. Personally, I wouldn't >>> ?trust numerical differentiation if the problem has significantly >>> ?different length scales, it is important to capture all of them >>> ?accurately, and it is not clear how to scale them to the same size. >>> ?Writing ND software that works as expected all the time is probably >>> ?not possible even in theory. >>> >>> ?Numerical differentiation is not the only game in the town. I'd look >>> ?into automatic differentiation (AD) -- there are libraries available >>> ?for Python also for that, and it is numerically stable. >>> >>> ?E.g. >>> >>> ?http://en.wikipedia.org/wiki/Automatic_differentiation#Software >>> >>> ?has a list of Python libraries. I don't know which of them would be >>> ?the best ones, though. >>> >> ?they all have their pro's and con's. >> ?Being (co-)author of some of these tools, my personal and very biased advice is: >> ?if you are on Linux, I would go for PYADOLC. it provides bindings to a >> ?feature-rich and well-tested C++ library. >> ?However, the installation is a little tricker than a "setup.py build" >> ?since you will need to compile ADOL-C and get Boost::Python to work. >> ?PYADOLC can also differentiate much more complicated code than your >> ?example in a relatively efficient manner. > > Is there by chance any possibility to make PYADOLC run on a (lame) > windows xp engine. If not what else would u recommend (besides switching > to Linux, what I am going to do soon). 1) PYADOLC A windows version has been requested several times now. But until recently ADOL-C wasn't available as windows version. So yes, in principle it should be possible to get it to work on windows: You will need 1) boost:python http://www.boost.org/doc/libs/1_44_0/libs/python/doc/index.html 2) ADOL-C sources http://www.coin-or.org/projects/ADOL-C.xml 3) scons http://www.scons.org/ on windows. If you want to give it a try I could help to get it to work. 2) Alternatives: You can also try the ALGOPY which is pure Python and is known to work on Linux and Windows. The installation is also very easy (setup.py build or setup.py install) I have added your problem to the ALGOPY documentation: http://packages.python.org/algopy/examples/hessian_of_potential_function.html The catch is that ALGOPY is not as mature as PYADOLC. However, if you are careful to write clean code it should work reliably. Sebastian >> ?For your example the code looks like: >> >> ?--------------------- code --------------------------- >> >> ?.... >> >> ?c=classicalHamiltonian() >> ?xopt = optimize.fmin(c.potential, c.initialposition(), xtol = 1e-10) >> >> ?import adolc; ?import numpy >> >> ?# trace the computation >> ?adolc.trace_on(0) >> ?x = adolc.adouble(c.initialposition()) >> ?adolc.independent(x) >> ?y = c.potential(x) >> ?adolc.dependent(y) >> ?adolc.trace_off() >> >> ?hessian = adolc.hessian(0, xopt) >> ?eigenvalues = numpy.linalg.eigh(hessian)[0] >> ?normal_modes = c.normal_modes(eigenvalues) >> ?print 'hessian=\n',hessian >> ?print 'eigenvalues=\n',eigenvalues >> ?print 'normal_modes=\n',normal_modes >> ?--------------------- code --------------------------- >> >> ?and you get as output >> ?Optimization terminated successfully. >> ? ? ? ? ? ?Current function value: 0.000000 >> ? ? ? ? ? ?Iterations: 81 >> ? ? ? ? ? ?Function evaluations: 153 >> ?hessian= >> ?[[ ?5.23748399e-12 ?-2.61873843e-12] >> ? ?[ -2.61873843e-12 ? 5.23748399e-12]] >> ?eigenvalues= >> ?[ ?2.61874556e-12 ? 7.85622242e-12] >> ?normal_modes= >> ?[ ?6283185.30717959 ?10882786.30440101] >> >> >> ?Also, you should use an eigenvalue solver for symmetric matrices, e.g. >> ?numpy.linalg.eigh. >> > Your code example looks awesome and leads to the correct results. Thank > you very much. I try to make it work on my pc as well. >> ?regards, >> ?Sebastian >> >>> ?-- >>> ?Pauli Virtanen >>> >>> ?_______________________________________________ >>> ?NumPy-Discussion mailing list >>> ?NumPy-Discussion at scipy.org >>> ?http://mail.scipy.org/mailman/listinfo/numpy-discussion >>> >> ?_______________________________________________ >> ?NumPy-Discussion mailing list >> ?NumPy-Discussion at scipy.org >> ?http://mail.scipy.org/mailman/listinfo/numpy-discussion > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > From brennan.williams at visualreservoir.com Thu Oct 28 07:38:41 2010 From: brennan.williams at visualreservoir.com (Brennan Williams) Date: Fri, 29 Oct 2010 00:38:41 +1300 Subject: [Numpy-discussion] quadratic function Message-ID: <4CC960C1.8030806@visualreservoir.com> I have used both linear least squares and radial basis functions as a proxy equation, calculated from the results of computer simulations which are calculating some objective function value based on a number of varied input parameters. As an alternative option I want to add a quadratic function so if there are parameters/variables x,y,z then rather than just having a linear function f=a+bx+cy+dz I'll have f=a+bx+cx**2 + dxy + .... I'd like to have the option not to include all the different second order terms. Where should I start looking? Thanks Brennan From aarchiba at physics.mcgill.ca Thu Oct 28 08:58:48 2010 From: aarchiba at physics.mcgill.ca (Anne Archibald) Date: Thu, 28 Oct 2010 08:58:48 -0400 Subject: [Numpy-discussion] Stacking a 2d array onto a 3d array In-Reply-To: References: Message-ID: On 26 October 2010 21:02, Dewald Pieterse wrote: > I see my slicing was the problem, np.vstack((test[:1], test)) works > perfectly. Yes and no. np.newaxis (or "None" for short) is a very useful tool; you just stick it in an index expression and it adds an axis of length one there. If what you really wanted to do was pull out one plane of the array, then indexing with a number was the right thing to do. If you want to stack that plane back on the array, just add an axis of length one to it. S = A[1,...] A = np.vstack((S[np.newaxis,...],A)) As a side note, np.newaxis is actually just None, but I find the longer name much clearer, so I try to use it in my own code, and I always use it in examples I'm showing other people. I suppose a third option would be "import numpy.newaxis as na". Anne > On Wed, Oct 27, 2010 at 12:55 AM, wrote: >> >> On Tue, Oct 26, 2010 at 8:15 PM, Dewald Pieterse >> wrote: >> > Starting with: >> > >> >> In [93]: test = >> >> numpy.array([[[1,1,1],[1,1,1]],[[2,2,2],[2,2,2]],[[3,3,3],[3,3,3]]]) >> >> >> >> In [94]: test >> >> Out[94]: >> >> array([[[1, 1, 1], >> >> ??????? [1, 1, 1]], >> >> >> >> ?????? [[2, 2, 2], >> >> ??????? [2, 2, 2]], >> >> >> >> ?????? [[3, 3, 3], >> >> ??????? [3, 3, 3]]]) >> >> >> >> Slicing the complete first row: >> >> >> >> In [95]: firstrow = test[0,:,:] >> >> >> >> In [96]: firstrow >> >> Out[96]: >> >> array([[1, 1, 1], >> >> ?????? [1, 1, 1]]) >> > >> > I want to stack firstrow onto test to end up with: >> > >> >> ([[[1, 1, 1], >> >> ??????? [1, 1, 1]], >> >> >> >> ?????? [[1, 1, 1], >> >> ??????? [1, 1, 1]], >> >> >> >> ?????? [[2, 2, 2], >> >> ??????? [2, 2, 2]], >> >> >> >> ?????? [[3, 3, 3], >> >> ??????? [3, 3, 3]]] >> > >> > >> > vstack wants the array dimensions to be the same, is this possible >> > without >> > doing 1 dimensional reshape, the actual data I want to do this on is >> > some >> > what larger. >> > >> >> ?numpy.vstack((firstrow,test)) >> >> >> >> >> >> --------------------------------------------------------------------------- >> >> ValueError??????????????????????????????? Traceback (most recent call >> >> last) >> >> >> >> /mnt/home/home/bmeagle/M/programme/analiseerverwerkteprent.py in >> >> () >> >> ----> 1 >> >> ????? 2 >> >> ????? 3 >> >> ????? 4 >> >> ????? 5 >> >> >> >> /usr/lib64/python2.6/site-packages/numpy/core/shape_base.py in >> >> vstack(tup) >> >> ??? 212 >> >> ??? 213???? """ >> >> --> 214???? return _nx.concatenate(map(atleast_2d,tup),0) >> >> ??? 215 >> >> ??? 216 def hstack(tup): >> >> >> >> ValueError: arrays must have same number of dimensions >> > >> > >> > What is the correct python way to do this? >> >> keep the first dimension or add it back in >> >> >>> test = >> >>> np.array([[[1,1,1],[1,1,1]],[[2,2,2],[2,2,2]],[[3,3,3],[3,3,3]]]) >> >>> np.vstack((test[:1], test)) >> array([[[1, 1, 1], >> ? ? ? ?[1, 1, 1]], >> >> ? ? ? [[1, 1, 1], >> ? ? ? ?[1, 1, 1]], >> >> ? ? ? [[2, 2, 2], >> ? ? ? ?[2, 2, 2]], >> >> ? ? ? [[3, 3, 3], >> ? ? ? ?[3, 3, 3]]]) >> >>> np.vstack((test[0][None,...], test)) >> array([[[1, 1, 1], >> ? ? ? ?[1, 1, 1]], >> >> ? ? ? [[1, 1, 1], >> ? ? ? ?[1, 1, 1]], >> >> ? ? ? [[2, 2, 2], >> ? ? ? ?[2, 2, 2]], >> >> ? ? ? [[3, 3, 3], >> ? ? ? ?[3, 3, 3]]]) >> >>> np.vstack((test[0][None,:,:], test)) >> array([[[1, 1, 1], >> ? ? ? ?[1, 1, 1]], >> >> ? ? ? [[1, 1, 1], >> ? ? ? ?[1, 1, 1]], >> >> ? ? ? [[2, 2, 2], >> ? ? ? ?[2, 2, 2]], >> >> ? ? ? [[3, 3, 3], >> ? ? ? ?[3, 3, 3]]]) >> >> I like expand_dims for arbitrary axis, e.g. >> >> >>> ax=1 >> >>> np.concatenate((np.expand_dims(test[:,0,:],ax), test), ax) >> array([[[1, 1, 1], >> ? ? ? ?[1, 1, 1], >> ? ? ? ?[1, 1, 1]], >> >> ? ? ? [[2, 2, 2], >> ? ? ? ?[2, 2, 2], >> ? ? ? ?[2, 2, 2]], >> >> ? ? ? [[3, 3, 3], >> ? ? ? ?[3, 3, 3], >> ? ? ? ?[3, 3, 3]]]) >> >> Josef >> >> >> > >> > >> > -- >> > Dewald Pieterse >> > >> > >> > _______________________________________________ >> > NumPy-Discussion mailing list >> > NumPy-Discussion at scipy.org >> > http://mail.scipy.org/mailman/listinfo/numpy-discussion >> > >> > >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > -- > Dewald Pieterse > > "A democracy is nothing more than mob rule, where fifty-one percent of the > people take away the rights of the other forty-nine." ~ Thomas Jefferson > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > From robert.kern at gmail.com Thu Oct 28 09:34:18 2010 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 28 Oct 2010 08:34:18 -0500 Subject: [Numpy-discussion] quadratic function In-Reply-To: <4CC960C1.8030806@visualreservoir.com> References: <4CC960C1.8030806@visualreservoir.com> Message-ID: On Thu, Oct 28, 2010 at 06:38, Brennan Williams wrote: > ?I have used both linear least squares and radial basis functions as a > proxy equation, calculated from the results of computer simulations > which are calculating some objective function value based on a number of > varied input parameters. > > As an alternative option I want to add a quadratic function so if there > are parameters/variables x,y,z then rather than just having a linear > function f=a+bx+cy+dz I'll have f=a+bx+cx**2 + dxy + .... I'd like to > have the option not to include all the different second order terms. A = np.column_stack([ np.ones_like(x), x, y, z, x*x, y*y, z*z, x*y, y*z, x*z, ]) x, res, rank, s = np.linalg.lstsq(A, f) -- 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 From dsdale24 at gmail.com Thu Oct 28 11:23:53 2010 From: dsdale24 at gmail.com (Darren Dale) Date: Thu, 28 Oct 2010 11:23:53 -0400 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: Hi Chuck, On Wed, Oct 27, 2010 at 1:30 PM, Charles R Harris wrote: > > I'd like to do something here, but I'm waiting for a consensus and for > someone to test things out, maybe with a test repo, to make sure things > operate correctly. The documentation isn't that clear... I am getting ready to test on windows and mac. In the process of upgrading git on windows to 1.7.3.1, The following dialog appeared: Configuring line ending conversions How should Git treat line endings in text files? x Checkout Windows-style, commit Unix-style line endings Git will convert LF to CRLF when checking out text files. When committing text files, CRLF will be converted to LF. For cross-platform projects, this is the recommended setting on Windows ("core.autocrlf" is set to "true") o Checkout as-is, commit Unix-style line endings Git will not perform any conversion when checking out text files. When committing text files, CRLF will be converted to LF. For cross-platform projects this is the recommended setting on Unix ("core.autocrlf" is set to "input"). o Checkout as-is, commit as-is Git will not perform any conversions when checking out or committing text files. Choosing this option is not recommended for cross-platform projects ("core.autocrlf" is set to "false") This might warrant a very brief mention in the docs, for helping people set up their environment. Its too bad core.autocrlf cannot be set on a per-project basis in a file that gets committed to the repository. As far as I can tell, it can only be set in ~/.gitconfig or numpy/.git/config. Which is why I suggested adding .gitattributes, which can be committed to the repository, and the line "* text=auto" ensures that EOLs in text files are committed as LF, so we don't have to worry about somebody's config settings having unwanted impact on the repository. And now the bad news: I have not been able to verify that Git respects the autocrlf setting or the eol setting in .gitattributes on my windows 7 computer: I made a new clone and the line endings are LF in the working directory, both on master and in my whitespace-cleanup branch (even the nsi.in file!). ("git config -l" confirms that "core.autocrlf" is "true".) To check my sanity, I tried writing files using wordpad and notepad to confirm that they are at least using CRLF, and they are *not*, according to both python's open() and grep "\r\n". If it were after noon where I live, I would be looking for a bottle of whiskey. But its not, so I'll just beat my head against my desk until I've forgotten about this whole episode. From charlesr.harris at gmail.com Thu Oct 28 12:11:51 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Thu, 28 Oct 2010 10:11:51 -0600 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: On Thu, Oct 28, 2010 at 9:23 AM, Darren Dale wrote: > Hi Chuck, > > On Wed, Oct 27, 2010 at 1:30 PM, Charles R Harris > wrote: > > > > I'd like to do something here, but I'm waiting for a consensus and for > > someone to test things out, maybe with a test repo, to make sure things > > operate correctly. The documentation isn't that clear... > > I am getting ready to test on windows and mac. In the process of > upgrading git on windows to 1.7.3.1, The following dialog appeared: > > Configuring line ending conversions > How should Git treat line endings in text files? > > x Checkout Windows-style, commit Unix-style line endings > Git will convert LF to CRLF when checking out text files. When > committing text files, CRLF will be converted to LF. For > cross-platform projects, this is the recommended setting on Windows > ("core.autocrlf" is set to "true") > > o Checkout as-is, commit Unix-style line endings > Git will not perform any conversion when checking out text files. > When committing text files, CRLF will be converted to LF. For > cross-platform projects this is the recommended setting on Unix > ("core.autocrlf" is set to "input"). > > o Checkout as-is, commit as-is > Git will not perform any conversions when checking out or committing > text files. Choosing this option is not recommended for cross-platform > projects ("core.autocrlf" is set to "false") > > This might warrant a very brief mention in the docs, for helping > people set up their environment. Its too bad core.autocrlf cannot be > set on a per-project basis in a file that gets committed to the > Yes, this would be good information to have in the notes. > repository. As far as I can tell, it can only be set in ~/.gitconfig > or numpy/.git/config. Which is why I suggested adding .gitattributes, > which can be committed to the repository, and the line "* text=auto" > ensures that EOLs in text files are committed as LF, so we don't have > to worry about somebody's config settings having unwanted impact on > the repository. > Might be worth trying in a numpy/.gitconfig just to see what happens. Documentation isn't always complete. > > And now the bad news: I have not been able to verify that Git respects > the autocrlf setting or the eol setting in .gitattributes on my > windows 7 computer: I made a new clone and the line endings are LF in > the working directory, both on master and in my whitespace-cleanup > branch (even the nsi.in file!). ("git config -l" confirms that > "core.autocrlf" is "true".) To check my sanity, I tried writing files > using wordpad and notepad to confirm that they are at least using > CRLF, and they are *not*, according to both python's open() and grep > "\r\n". If it were after noon where I live, I would be looking for a > Grepping for CR is tricky. The straightforward way is grep ctrl-v ctrl-m. I'm pretty sure notepad uses CRLF since it doesn't do line breaks for "unix" text. > bottle of whiskey. But its not, so I'll just beat my head against my > desk until I've forgotten about this whole episode. > _ > Oh, don't do that. Someone's got to explore the territory and, as an official old fart, I'm volunteering the younguns. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Thu Oct 28 12:23:27 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Thu, 28 Oct 2010 12:23:27 -0400 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: On Thu, Oct 28, 2010 at 12:11 PM, Charles R Harris wrote: > > > On Thu, Oct 28, 2010 at 9:23 AM, Darren Dale wrote: >> >> Hi Chuck, >> >> On Wed, Oct 27, 2010 at 1:30 PM, Charles R Harris >> wrote: >> > >> > I'd like to do something here, but I'm waiting for a consensus and for >> > someone to test things out, maybe with a test repo, to make sure things >> > operate correctly. The documentation isn't that clear... >> >> I am getting ready to test on windows and mac. In the process of >> upgrading git on windows to 1.7.3.1, The following dialog appeared: >> >> Configuring line ending conversions >> ?How should Git treat line endings in text files? >> >> x Checkout Windows-style, commit Unix-style line endings >> ?Git will convert LF to CRLF when checking out text files. When >> committing text files, CRLF will be converted to LF. For >> cross-platform projects, this is the recommended setting on Windows >> ("core.autocrlf" is set to "true") >> >> o Checkout as-is, commit Unix-style line endings >> ?Git will not perform any conversion when checking out text files. >> When committing text files, CRLF will be converted to LF. For >> cross-platform projects this is the recommended setting on Unix >> ("core.autocrlf" is set to "input"). >> >> o Checkout as-is, commit as-is >> ?Git will not perform any conversions when checking out or committing >> text files. Choosing this option is not recommended for cross-platform >> projects ("core.autocrlf" is set to "false") >> >> This might warrant a very brief mention in the docs, for helping >> people set up their environment. Its too bad core.autocrlf cannot be >> set on a per-project basis in a file that gets committed to the > > Yes, this would be good information to have in the notes. > >> >> repository. As far as I can tell, it can only be set in ~/.gitconfig >> or numpy/.git/config. Which is why I suggested adding .gitattributes, >> which can be committed to the repository, and the line "* text=auto" >> ensures that EOLs in text files are committed as LF, so we don't have >> to worry about somebody's config settings having unwanted impact on >> the repository. > > Might be worth trying in a numpy/.gitconfig just to see what happens. > Documentation isn't always complete. >> >> And now the bad news: I have not been able to verify that Git respects >> the autocrlf setting or the eol setting in .gitattributes on my >> windows 7 computer: I made a new clone and the line endings are LF in >> the working directory, both on master and in my whitespace-cleanup >> branch (even the nsi.in file!). ("git config -l" confirms that >> "core.autocrlf" is "true".) To check my sanity, I tried writing files >> using wordpad and notepad to confirm that they are at least using >> CRLF, and they are *not*, according to both python's open() and grep >> "\r\n". If it were after noon where I live, I would be looking for a maybe just something obvious: Did you read the files in python as binary 'rb' ? I checked two old git checkouts (with a one and a half year old git version), pymvpa and scikits.talkbox and both have files with \r\n as line endings on my windowsXP. I don't think I did anything special, but maybe I had used a GUI interface for those. Josef > > Grepping for CR is tricky. The straightforward way is grep ctrl-v ctrl-m. > I'm pretty sure notepad uses CRLF since it doesn't do line breaks for "unix" > text. > > >> >> bottle of whiskey. But its not, so I'll just beat my head against my >> desk until I've forgotten about this whole episode. >> _ > > Oh, don't do that. Someone's got to explore the territory and, as an > official old fart, I'm volunteering the younguns. > > Chuck > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > From brennan.williams at visualreservoir.com Thu Oct 28 13:33:22 2010 From: brennan.williams at visualreservoir.com (Brennan Williams) Date: Fri, 29 Oct 2010 06:33:22 +1300 Subject: [Numpy-discussion] quadratic function In-Reply-To: References: <4CC960C1.8030806@visualreservoir.com> Message-ID: <4CC9B3E2.9040308@visualreservoir.com> On 29/10/2010 2:34 a.m., Robert Kern wrote: > On Thu, Oct 28, 2010 at 06:38, Brennan Williams > wrote: >> I have used both linear least squares and radial basis functions as a >> proxy equation, calculated from the results of computer simulations >> which are calculating some objective function value based on a number of >> varied input parameters. >> >> As an alternative option I want to add a quadratic function so if there >> are parameters/variables x,y,z then rather than just having a linear >> function f=a+bx+cy+dz I'll have f=a+bx+cx**2 + dxy + .... I'd like to >> have the option not to include all the different second order terms. > A = np.column_stack([ > np.ones_like(x), > x, y, z, > x*x, y*y, z*z, > x*y, y*z, x*z, > ]) > x, res, rank, s = np.linalg.lstsq(A, f) > OK, so in other words, you can use linalg.lstsq for whatever higher order terms you want to include or exclude. Very nice. Thanks. On a related topic I also use the Rbf radial basis function as a proxy equation. I have one set of data that it fails to return an Rbf for and I've just realised that in my set of simulations that are used to build the proxy equation I have some duplicate equations. I'm wondering if Rbf doesn't like duplicate points? It obviously doesn't affect linalg.lstsq. Brennan From robert.kern at gmail.com Thu Oct 28 13:35:46 2010 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 28 Oct 2010 12:35:46 -0500 Subject: [Numpy-discussion] quadratic function In-Reply-To: <4CC9B3E2.9040308@visualreservoir.com> References: <4CC960C1.8030806@visualreservoir.com> <4CC9B3E2.9040308@visualreservoir.com> Message-ID: On Thu, Oct 28, 2010 at 12:33, Brennan Williams wrote: > ?On 29/10/2010 2:34 a.m., Robert Kern wrote: >> On Thu, Oct 28, 2010 at 06:38, Brennan Williams >> ?wrote: >>> ? I have used both linear least squares and radial basis functions as a >>> proxy equation, calculated from the results of computer simulations >>> which are calculating some objective function value based on a number of >>> varied input parameters. >>> >>> As an alternative option I want to add a quadratic function so if there >>> are parameters/variables x,y,z then rather than just having a linear >>> function f=a+bx+cy+dz I'll have f=a+bx+cx**2 + dxy + .... I'd like to >>> have the option not to include all the different second order terms. >> A = np.column_stack([ >> ? ? ?np.ones_like(x), >> ? ? ?x, y, z, >> ? ? ?x*x, y*y, z*z, >> ? ? ?x*y, y*z, x*z, >> ]) >> x, res, rank, s = np.linalg.lstsq(A, f) >> > OK, so in other words, you can use linalg.lstsq for whatever higher > order terms you want to include or exclude. Very nice. Thanks. Right. Just as long as the problem is linear in the coefficients, the design matrix can be derived however you like. > On a related topic I also use the Rbf radial basis function as a proxy > equation. I have one set of data that it fails to return an Rbf for and > I've just realised that in my set of simulations that are used to build > the proxy equation I have some duplicate equations. I'm wondering if Rbf > doesn't like duplicate points? It obviously doesn't affect linalg.lstsq. Rbf doesn't like duplicate points. :-) -- 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 From brennan.williams at visualreservoir.com Thu Oct 28 13:47:36 2010 From: brennan.williams at visualreservoir.com (Brennan Williams) Date: Fri, 29 Oct 2010 06:47:36 +1300 Subject: [Numpy-discussion] quadratic function In-Reply-To: References: <4CC960C1.8030806@visualreservoir.com> <4CC9B3E2.9040308@visualreservoir.com> Message-ID: <4CC9B738.3000907@visualreservoir.com> On 29/10/2010 6:35 a.m., Robert Kern wrote: > On Thu, Oct 28, 2010 at 12:33, Brennan Williams > wrote: >> On 29/10/2010 2:34 a.m., Robert Kern wrote: >>> On Thu, Oct 28, 2010 at 06:38, Brennan Williams >>> wrote: >>>> I have used both linear least squares and radial basis functions as a >>>> proxy equation, calculated from the results of computer simulations >>>> which are calculating some objective function value based on a number of >>>> varied input parameters. >>>> >>>> As an alternative option I want to add a quadratic function so if there >>>> are parameters/variables x,y,z then rather than just having a linear >>>> function f=a+bx+cy+dz I'll have f=a+bx+cx**2 + dxy + .... I'd like to >>>> have the option not to include all the different second order terms. >>> A = np.column_stack([ >>> np.ones_like(x), >>> x, y, z, >>> x*x, y*y, z*z, >>> x*y, y*z, x*z, >>> ]) >>> x, res, rank, s = np.linalg.lstsq(A, f) >>> >> OK, so in other words, you can use linalg.lstsq for whatever higher >> order terms you want to include or exclude. Very nice. Thanks. > Right. Just as long as the problem is linear in the coefficients, the > design matrix can be derived however you like. > So I could optionally put log terms in if I thought it was linear in log(x) for example? >> On a related topic I also use the Rbf radial basis function as a proxy >> equation. I have one set of data that it fails to return an Rbf for and >> I've just realised that in my set of simulations that are used to build >> the proxy equation I have some duplicate equations. I'm wondering if Rbf >> doesn't like duplicate points? It obviously doesn't affect linalg.lstsq. > Rbf doesn't like duplicate points. :-) OK, fair enough, I just need to add a bit of housekeeping to remove duplicate simulations. Thanks for the confirmation. From robert.kern at gmail.com Thu Oct 28 15:05:06 2010 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 28 Oct 2010 14:05:06 -0500 Subject: [Numpy-discussion] quadratic function In-Reply-To: <4CC9B738.3000907@visualreservoir.com> References: <4CC960C1.8030806@visualreservoir.com> <4CC9B3E2.9040308@visualreservoir.com> <4CC9B738.3000907@visualreservoir.com> Message-ID: On Thu, Oct 28, 2010 at 12:47, Brennan Williams wrote: > ?On 29/10/2010 6:35 a.m., Robert Kern wrote: >> On Thu, Oct 28, 2010 at 12:33, Brennan Williams >> ?wrote: >>> ? On 29/10/2010 2:34 a.m., Robert Kern wrote: >>>> On Thu, Oct 28, 2010 at 06:38, Brennan Williams >>>> ? ?wrote: >>>>> ? ?I have used both linear least squares and radial basis functions as a >>>>> proxy equation, calculated from the results of computer simulations >>>>> which are calculating some objective function value based on a number of >>>>> varied input parameters. >>>>> >>>>> As an alternative option I want to add a quadratic function so if there >>>>> are parameters/variables x,y,z then rather than just having a linear >>>>> function f=a+bx+cy+dz I'll have f=a+bx+cx**2 + dxy + .... I'd like to >>>>> have the option not to include all the different second order terms. >>>> A = np.column_stack([ >>>> ? ? ? np.ones_like(x), >>>> ? ? ? x, y, z, >>>> ? ? ? x*x, y*y, z*z, >>>> ? ? ? x*y, y*z, x*z, >>>> ]) >>>> x, res, rank, s = np.linalg.lstsq(A, f) >>>> >>> OK, so in other words, you can use linalg.lstsq for whatever higher >>> order terms you want to include or exclude. Very nice. Thanks. >> Right. Just as long as the problem is linear in the coefficients, the >> design matrix can be derived however you like. >> > So I could optionally put log terms in if I thought it was linear in > log(x) for example? Yup! -- 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 From dsdale24 at gmail.com Thu Oct 28 14:40:00 2010 From: dsdale24 at gmail.com (Darren Dale) Date: Thu, 28 Oct 2010 14:40:00 -0400 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: On Thu, Oct 28, 2010 at 12:23 PM, wrote: > On Thu, Oct 28, 2010 at 12:11 PM, Charles R Harris >> On Thu, Oct 28, 2010 at 9:23 AM, Darren Dale wrote: >>> And now the bad news: I have not been able to verify that Git respects >>> the autocrlf setting or the eol setting in .gitattributes on my >>> windows 7 computer: I made a new clone and the line endings are LF in >>> the working directory, both on master and in my whitespace-cleanup >>> branch (even the nsi.in file!). ("git config -l" confirms that >>> "core.autocrlf" is "true".) To check my sanity, I tried writing files >>> using wordpad and notepad to confirm that they are at least using >>> CRLF, and they are *not*, according to both python's open() and grep >>> "\r\n". If it were after noon where I live, I would be looking for a > > maybe just something obvious: Did you read the files in python as binary 'rb' ? No, I did not. You are right, this shows \r\n. Why is it necessary to open them as binary? IIUC (OIDUC), one should use 'rU' to unify line endings. From josef.pktd at gmail.com Thu Oct 28 15:23:49 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Thu, 28 Oct 2010 15:23:49 -0400 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: On Thu, Oct 28, 2010 at 2:40 PM, Darren Dale wrote: > On Thu, Oct 28, 2010 at 12:23 PM, ? wrote: >> On Thu, Oct 28, 2010 at 12:11 PM, Charles R Harris >>> On Thu, Oct 28, 2010 at 9:23 AM, Darren Dale wrote: >>>> And now the bad news: I have not been able to verify that Git respects >>>> the autocrlf setting or the eol setting in .gitattributes on my >>>> windows 7 computer: I made a new clone and the line endings are LF in >>>> the working directory, both on master and in my whitespace-cleanup >>>> branch (even the nsi.in file!). ("git config -l" confirms that >>>> "core.autocrlf" is "true".) To check my sanity, I tried writing files >>>> using wordpad and notepad to confirm that they are at least using >>>> CRLF, and they are *not*, according to both python's open() and grep >>>> "\r\n". If it were after noon where I live, I would be looking for a >> >> maybe just something obvious: Did you read the files in python as binary 'rb' ? > > No, I did not. You are right, this shows \r\n. Why is it necessary to > open them as binary? IIUC (OIDUC), one should use 'rU' to unify line > endings. The python default for open(filename).read() or open(filename, 'r').read() is to standardize line endings to \n. Josef > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > From sebastian.walter at gmail.com Thu Oct 28 15:34:58 2010 From: sebastian.walter at gmail.com (Sebastian Walter) Date: Thu, 28 Oct 2010 21:34:58 +0200 Subject: [Numpy-discussion] problems with numdifftools In-Reply-To: References: <4CC890A7.2040208@gmx.de> Message-ID: hmm, I have just realized that I forgot to upload the new version to pypi: it is now available on http://pypi.python.org/pypi/algopy On Thu, Oct 28, 2010 at 10:47 AM, Sebastian Walter wrote: > On Wed, Oct 27, 2010 at 10:50 PM, Nicolai Heitz wrote: >> m 27.10.2010 02:02, schrieb Sebastian Walter: >> >>> ?On Wed, Oct 27, 2010 at 12:59 AM, Pauli Virtanen ? wrote: >>>> ?Tue, 26 Oct 2010 14:24:39 -0700, Nicolai Heitz wrote: >>>>>> ? ?http://mail.scipy.org/mailman/listinfo/scipy-user >>>>> ?I contacted them already but they didn't responded so far and I was >>>>> ?forwarded to that list which was supposed to be more appropriated. >>>> ?I think you are thinking here about some other list -- scipy-user >>>> ?is the correct place for this discussion (and I don't remember seeing >>>> ?your mail there). >> I was pretty sure that I put it there. Unfortunately it had a different >> name there: Errors in calculation of the Hessian using numdifftools. But >> I can't find the post by myself at the moment so maybe something went >> wrong. >>>> ?[clip] >>>>> ?1) Can I make it run/fix it, so that it is also going to work for the SI >>>>> ?scaling? >>>> ?Based on a brief look, it seems that uniform scaling will not help you, >>>> ?as you have two very different length scales in the problem, >>>> >>>> ? ? ? ? ?1/sqrt(m w^2)>> ? C >>>> >>>> ?If you go to CM+relative coordinates you might be able to scale them >>>> ?separately, but that's fiddly and might not work for larger N. >>>> >>>> ?In your problem, things go wrong when the ratio between the >>>> ?length scales approaches 1e-15 which happens to be the machine epsilon. >>>> ?This implies that the algorithm runs into some problems caused by the >>>> ?finite precision of floating-point numbers. >>>> >>>> ?What exactly goes wrong and how to fix it, no idea --- I didn't look into >>>> ?how Numdifftools is implemented. >> >> Probably you are right. I converted it to natural units and it worked >> out in the 2 ion case. Increasing the number of ions leads to problems >> again and I have no idea where those problems come from. >> >>>>> ?2) How can I be sure that increasing the number of ions or adding a >>>>> ?somehow more complicated term to the potential energy is not causing the >>>>> ?same problems even in natural units? >>>>> >>>>> ?3) In which range is numdifftools working properly. >>>> ?That depends on the algorithm and the problem. Personally, I wouldn't >>>> ?trust numerical differentiation if the problem has significantly >>>> ?different length scales, it is important to capture all of them >>>> ?accurately, and it is not clear how to scale them to the same size. >>>> ?Writing ND software that works as expected all the time is probably >>>> ?not possible even in theory. >>>> >>>> ?Numerical differentiation is not the only game in the town. I'd look >>>> ?into automatic differentiation (AD) -- there are libraries available >>>> ?for Python also for that, and it is numerically stable. >>>> >>>> ?E.g. >>>> >>>> ?http://en.wikipedia.org/wiki/Automatic_differentiation#Software >>>> >>>> ?has a list of Python libraries. I don't know which of them would be >>>> ?the best ones, though. >>>> >>> ?they all have their pro's and con's. >>> ?Being (co-)author of some of these tools, my personal and very biased advice is: >>> ?if you are on Linux, I would go for PYADOLC. it provides bindings to a >>> ?feature-rich and well-tested C++ library. >>> ?However, the installation is a little tricker than a "setup.py build" >>> ?since you will need to compile ADOL-C and get Boost::Python to work. >>> ?PYADOLC can also differentiate much more complicated code than your >>> ?example in a relatively efficient manner. >> >> Is there by chance any possibility to make PYADOLC run on a (lame) >> windows xp engine. If not what else would u recommend (besides switching >> to Linux, what I am going to do soon). > > 1) PYADOLC > A windows version has been requested several times now. But until > recently ADOL-C wasn't available as windows version. > So yes, in principle it should be possible to get it to work on windows: > > You will need > 1) boost:python > http://www.boost.org/doc/libs/1_44_0/libs/python/doc/index.html > 2) ADOL-C sources http://www.coin-or.org/projects/ADOL-C.xml > 3) scons http://www.scons.org/ > on windows. > > ?If you want to give it a try I could help to get it to work. > > 2) Alternatives: > You can also try the ALGOPY which is pure Python and is known to work > on Linux and Windows. The installation is also very easy (setup.py > build or setup.py install) > I have added your problem to the ALGOPY documentation: > http://packages.python.org/algopy/examples/hessian_of_potential_function.html > The catch is that ALGOPY is not as mature as PYADOLC. However, if you > are careful to write clean code it should work reliably. > > > Sebastian > >>> ?For your example the code looks like: >>> >>> ?--------------------- code --------------------------- >>> >>> ?.... >>> >>> ?c=classicalHamiltonian() >>> ?xopt = optimize.fmin(c.potential, c.initialposition(), xtol = 1e-10) >>> >>> ?import adolc; ?import numpy >>> >>> ?# trace the computation >>> ?adolc.trace_on(0) >>> ?x = adolc.adouble(c.initialposition()) >>> ?adolc.independent(x) >>> ?y = c.potential(x) >>> ?adolc.dependent(y) >>> ?adolc.trace_off() >>> >>> ?hessian = adolc.hessian(0, xopt) >>> ?eigenvalues = numpy.linalg.eigh(hessian)[0] >>> ?normal_modes = c.normal_modes(eigenvalues) >>> ?print 'hessian=\n',hessian >>> ?print 'eigenvalues=\n',eigenvalues >>> ?print 'normal_modes=\n',normal_modes >>> ?--------------------- code --------------------------- >>> >>> ?and you get as output >>> ?Optimization terminated successfully. >>> ? ? ? ? ? ?Current function value: 0.000000 >>> ? ? ? ? ? ?Iterations: 81 >>> ? ? ? ? ? ?Function evaluations: 153 >>> ?hessian= >>> ?[[ ?5.23748399e-12 ?-2.61873843e-12] >>> ? ?[ -2.61873843e-12 ? 5.23748399e-12]] >>> ?eigenvalues= >>> ?[ ?2.61874556e-12 ? 7.85622242e-12] >>> ?normal_modes= >>> ?[ ?6283185.30717959 ?10882786.30440101] >>> >>> >>> ?Also, you should use an eigenvalue solver for symmetric matrices, e.g. >>> ?numpy.linalg.eigh. >>> >> Your code example looks awesome and leads to the correct results. Thank >> you very much. I try to make it work on my pc as well. >>> ?regards, >>> ?Sebastian >>> >>>> ?-- >>>> ?Pauli Virtanen >>>> >>>> ?_______________________________________________ >>>> ?NumPy-Discussion mailing list >>>> ?NumPy-Discussion at scipy.org >>>> ?http://mail.scipy.org/mailman/listinfo/numpy-discussion >>>> >>> ?_______________________________________________ >>> ?NumPy-Discussion mailing list >>> ?NumPy-Discussion at scipy.org >>> ?http://mail.scipy.org/mailman/listinfo/numpy-discussion >> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> > From dsdale24 at gmail.com Thu Oct 28 16:25:24 2010 From: dsdale24 at gmail.com (Darren Dale) Date: Thu, 28 Oct 2010 16:25:24 -0400 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: On Thu, Oct 28, 2010 at 3:23 PM, wrote: > On Thu, Oct 28, 2010 at 2:40 PM, Darren Dale wrote: >> On Thu, Oct 28, 2010 at 12:23 PM, ? wrote: >>> On Thu, Oct 28, 2010 at 12:11 PM, Charles R Harris >>>> On Thu, Oct 28, 2010 at 9:23 AM, Darren Dale wrote: >>>>> And now the bad news: I have not been able to verify that Git respects >>>>> the autocrlf setting or the eol setting in .gitattributes on my >>>>> windows 7 computer: I made a new clone and the line endings are LF in >>>>> the working directory, both on master and in my whitespace-cleanup >>>>> branch (even the nsi.in file!). ("git config -l" confirms that >>>>> "core.autocrlf" is "true".) To check my sanity, I tried writing files >>>>> using wordpad and notepad to confirm that they are at least using >>>>> CRLF, and they are *not*, according to both python's open() and grep >>>>> "\r\n". If it were after noon where I live, I would be looking for a >>> >>> maybe just something obvious: Did you read the files in python as binary 'rb' ? >> >> No, I did not. You are right, this shows \r\n. Why is it necessary to >> open them as binary? IIUC (OIDUC), one should use 'rU' to unify line >> endings. > > The python default for open(filename).read() ?or open(filename, > 'r').read() is to standardize line endings to \n. Although, on a mac: In [1]: open('tools/win32build/nsis_scripts/numpy-superinstaller.nsi.in').readlines()[0] Out[1]: ';--------------------------------\r\n' From ijstokes at hkl.hms.harvard.edu Thu Oct 28 16:17:08 2010 From: ijstokes at hkl.hms.harvard.edu (Ian Stokes-Rees) Date: Thu, 28 Oct 2010 16:17:08 -0400 Subject: [Numpy-discussion] ndarray __getattr__ to perform __getitem__ Message-ID: <4CC9DA44.20503@hkl.hms.harvard.edu> I have an ndarray with named dimensions. I find myself writing some fairly laborious code with lots of square brackets and quotes. It seems like it wouldn't be such a big deal to overload __getattribute__ so instead of doing: r = genfromtxt('results.dat',dtype=[('a','int'), ('b', 'f8'), ('c','int'), ('d', 'a20')]) scatter(r[r['d'] == 'OK']['a'], r[r['d'] == 'OK']['b']) I could do: scatter(r[r.d == 'OK'].a, r[r.d == 'OK'].b) which is really a lot clearer. Is something like this already possible somehow? Is there some reason not to map __getattr__ to __getitem__? class ndarray(): ... __getattr__ = __getitem__ Or something somewhat more sophisticated like: def __getattr__(self, attr): if self.hasitem(attr): return self[attr] else: raise AttributeError(attr) TIA for any comments or thoughts on this. Ian From Chris.Barker at noaa.gov Thu Oct 28 17:16:33 2010 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Thu, 28 Oct 2010 14:16:33 -0700 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: <4CC9E831.5050401@noaa.gov> On 10/28/10 1:25 PM, Darren Dale wrote: >>> No, I did not. You are right, this shows \r\n. Why is it necessary to >>> open them as binary? IIUC (OIDUC), one should use 'rU' to unify line >>> endings. > Although, on a mac: > > In [1]: open('tools/win32build/nsis_scripts/numpy-superinstaller.nsi.in').readlines()[0] > Out[1]: ';--------------------------------\r\n' that's what the 'U' is for. try: open('tools/win32build/nsis_scripts/numpy-superinstaller.nsi.in','rU').readlines()[0] -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 Chris.Barker at noaa.gov From robert.kern at gmail.com Thu Oct 28 17:29:32 2010 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 28 Oct 2010 16:29:32 -0500 Subject: [Numpy-discussion] ndarray __getattr__ to perform __getitem__ In-Reply-To: <4CC9DA44.20503@hkl.hms.harvard.edu> References: <4CC9DA44.20503@hkl.hms.harvard.edu> Message-ID: On Thu, Oct 28, 2010 at 15:17, Ian Stokes-Rees wrote: > I have an ndarray with named dimensions. ?I find myself writing some > fairly laborious code with lots of square brackets and quotes. ?It seems > like it wouldn't be such a big deal to overload __getattribute__ so > instead of doing: > > r = genfromtxt('results.dat',dtype=[('a','int'), ('b', 'f8'), > ('c','int'), ('d', 'a20')]) > scatter(r[r['d'] == 'OK']['a'], r[r['d'] == 'OK']['b']) > > I could do: > > scatter(r[r.d == 'OK'].a, r[r.d == 'OK'].b) > > which is really a lot clearer. ?Is something like this already possible > somehow? See recarray which uses __getattribute__. > Is there some reason not to map __getattr__ to __getitem__? Using __getattribute__ tends to slow down almost all operations on the array substantially. Perhaps __getattr__ would work better, but all of the methods and attributes would mask the fields. If you can find a better solution that doesn't have such an impact on normal performance, we'd be happy to hear 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 From ijstokes at hkl.hms.harvard.edu Thu Oct 28 17:37:03 2010 From: ijstokes at hkl.hms.harvard.edu (Ian Stokes-Rees) Date: Thu, 28 Oct 2010 17:37:03 -0400 Subject: [Numpy-discussion] ndarray __getattr__ to perform __getitem__ In-Reply-To: References: <4CC9DA44.20503@hkl.hms.harvard.edu> Message-ID: <4CC9ECFF.50803@hkl.hms.harvard.edu> On 10/28/10 5:29 PM, Robert Kern wrote: > On Thu, Oct 28, 2010 at 15:17, Ian Stokes-Rees > wrote: >> I have an ndarray with named dimensions. I find myself writing some >> fairly laborious code with lots of square brackets and quotes. It seems >> like it wouldn't be such a big deal to overload __getattribute__ so >> instead of doing: >> >> r = genfromtxt('results.dat',dtype=[('a','int'), ('b', 'f8'), >> ('c','int'), ('d', 'a20')]) >> scatter(r[r['d'] == 'OK']['a'], r[r['d'] == 'OK']['b']) >> >> I could do: >> >> scatter(r[r.d == 'OK'].a, r[r.d == 'OK'].b) >> >> which is really a lot clearer. Is something like this already possible >> somehow? > See recarray which uses __getattribute__. Thanks -- I'll look into it. >> Is there some reason not to map __getattr__ to __getitem__? > Using __getattribute__ tends to slow down almost all operations on the > array substantially. Perhaps __getattr__ would work better, but all of > the methods and attributes would mask the fields. If you can find a > better solution that doesn't have such an impact on normal > performance, we'd be happy to hear it. But wouldn't the performance hit only come when I use it in this way? __getattr__ is only called if the named attribute is *not* found (I guess it falls off the end of the case statement, or is the result of the attribute hash table "miss"). So the proviso is "this shortcut only works if the field names are distinct from any methods or attributes on the ndarray object (or its sub-classes)". You've gotta admit that the readability of the code goes up *a lot* with the alternative I'm proposing. Ian -- Ian Stokes-Rees, PhD W: http://portal.nebiogrid.org ijstokes at hkl.hms.harvard.edu T: +1.617.432.5608 x75 NEBioGrid, Harvard Medical School C: +1.617.331.5993 -------------- next part -------------- A non-text attachment was scrubbed... Name: ijstokes.vcf Type: text/x-vcard Size: 394 bytes Desc: not available URL: From robert.kern at gmail.com Thu Oct 28 17:42:54 2010 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 28 Oct 2010 16:42:54 -0500 Subject: [Numpy-discussion] ndarray __getattr__ to perform __getitem__ In-Reply-To: <4CC9ECFF.50803@hkl.hms.harvard.edu> References: <4CC9DA44.20503@hkl.hms.harvard.edu> <4CC9ECFF.50803@hkl.hms.harvard.edu> Message-ID: On Thu, Oct 28, 2010 at 16:37, Ian Stokes-Rees wrote: > > > On 10/28/10 5:29 PM, Robert Kern wrote: >> On Thu, Oct 28, 2010 at 15:17, Ian Stokes-Rees >> wrote: >>> I have an ndarray with named dimensions. ?I find myself writing some >>> fairly laborious code with lots of square brackets and quotes. ?It seems >>> like it wouldn't be such a big deal to overload __getattribute__ so >>> instead of doing: >>> >>> r = genfromtxt('results.dat',dtype=[('a','int'), ('b', 'f8'), >>> ('c','int'), ('d', 'a20')]) >>> scatter(r[r['d'] == 'OK']['a'], r[r['d'] == 'OK']['b']) >>> >>> I could do: >>> >>> scatter(r[r.d == 'OK'].a, r[r.d == 'OK'].b) >>> >>> which is really a lot clearer. ?Is something like this already possible >>> somehow? >> See recarray which uses __getattribute__. > > Thanks -- I'll look into it. > >>> Is there some reason not to map __getattr__ to __getitem__? >> Using __getattribute__ tends to slow down almost all operations on the >> array substantially. Perhaps __getattr__ would work better, but all of >> the methods and attributes would mask the fields. If you can find a >> better solution that doesn't have such an impact on normal >> performance, we'd be happy to hear it. > > But wouldn't the performance hit only come when I use it in this way? > __getattr__ is only called if the named attribute is *not* found (I > guess it falls off the end of the case statement, or is the result of > the attribute hash table "miss"). That's why I said that __getattr__ would perhaps work better. > So the proviso is "this shortcut only works if the field names are > distinct from any methods or attributes on the ndarray object (or its > sub-classes)". Right. -- 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 From oliphant at enthought.com Fri Oct 29 00:34:52 2010 From: oliphant at enthought.com (Travis Oliphant) Date: Fri, 29 Oct 2010 00:34:52 -0400 Subject: [Numpy-discussion] Inconsistency with __index__() for rank-1 arrays? In-Reply-To: <201010271534.31139.faltet@pytables.org> References: <201010271534.31139.faltet@pytables.org> Message-ID: <39C6BD15-2A48-4719-848B-23156CC7A03D@enthought.com> The __index__ method returns an integer from an array. The current behavior follows the idea of "return an integer if there is 1-element in the array" Your suggestion is to only return an integer if it is a rank-0 array, otherwise raise an error. This could potentially be changed in NumPy 2.0. I'm +0 on the suggestion. -Travis On Oct 27, 2010, at 9:34 AM, Francesc Alted wrote: > Hi, > > I find this a bit misleading: > >>>> a = np.arange(10) > >>>> a[np.array(0)] > 0 > >>>> a[np.array([0])] > array([0]) > >>>> a[[0]] > array([0]) > > But, for regular python lists we have: > >>>> l = a.tolist() > >>>> l[np.array(0)] > 0 > >>>> l[np.array([0])] > 0 > > i.e. indexing with a rank-0 array and a rank-1 array with one single > element return the same result, which I find inconsistent with the > expected behaviour for this case, i.e.: > >>>> l[[0]] > --------------------------------------------------------------------------- > TypeError Traceback (most recent call > last) > > /tmp/tables-2.2/ in () > > TypeError: list indices must be integers, not list > > The ultimate reason for this behaviour is this: > >>>> np.array(0).__index__() > 0 > >>>> np.array([0]).__index__() > 0 > > But I wonder why NumPy needs the latter behaviour, instead of the more > logical: > >>>> np.array([0]).__index__() > --------------------------------------------------------------------------- > TypeError Traceback (most recent call > last) > > /tmp/tables-2.2/ in () > > TypeError: only rank-0 integer arrays can be converted to an index > > This inconsistency has indeed introduced a bug in my application and for > solving this I'd need something like: > > """ > def is_idx(index): > """Check if an object can work as an index or not.""" > > if hasattr(index, "__index__"): # Only works on Python 2.5 on > if (hasattr(index, "shape") and index.shape == (1,)): > return False > try: # (as per PEP 357) > idx = index.__index__() > return True > except TypeError: > return False > > return False > """ > > i.e. for determining if an object can be an index or not, I need to > explicitly check for a shape different from (1,), which is unnecessarily > complicated. > > So I find the current behaviour prone to introduce errors in apps and > I'm wondering why exactly np.array([1]) should work as an index at all. > It would not be better if that would raise a ``TypeError``? > > Thanks, > > -- > Francesc Alted > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion --- Travis Oliphant Enthought, Inc. oliphant at enthought.com 1-512-536-1057 http://www.enthought.com From faltet at pytables.org Fri Oct 29 03:54:23 2010 From: faltet at pytables.org (Francesc Alted) Date: Fri, 29 Oct 2010 09:54:23 +0200 Subject: [Numpy-discussion] Inconsistency with __index__() for rank-1 arrays? In-Reply-To: <39C6BD15-2A48-4719-848B-23156CC7A03D@enthought.com> References: <201010271534.31139.faltet@pytables.org> <39C6BD15-2A48-4719-848B-23156CC7A03D@enthought.com> Message-ID: <201010290954.23642.faltet@pytables.org> Hi Travis, thanks for answering, A Friday 29 October 2010 06:34:52 Travis Oliphant escrigu?: > The __index__ method returns an integer from an array. > > The current behavior follows the idea of "return an integer if there > is 1-element in the array" > > Your suggestion is to only return an integer if it is a rank-0 array, > otherwise raise an error. Yes. I think this makes a lot of sense because a rank-0 array can be seen as a scalar (and hence, and index), but it is difficult to see a rank-1 (or, in general, rank-N) array as a scalar (even if only has 1 single element). In particular, this would avoid this inconsistency: >>> a[np.array(1)] 1 >>> a[np.array([1])] array([1]) >>> a[np.array([[[1]]])] array([[[1]]]) but: >>> np.array(1).__index__() 1 >>> np.array([1]).__index__() 1 >>> np.array([[[1]]]).__index__() 1 > This could potentially be changed in NumPy 2.0. I'm +0 on the > suggestion. My vote is +1 for deprecating ``array([scalar])`` as a scalar index for NumPy 2.0. -- Francesc Alted From ijstokes at hkl.hms.harvard.edu Fri Oct 29 05:59:07 2010 From: ijstokes at hkl.hms.harvard.edu (Ian Stokes-Rees) Date: Fri, 29 Oct 2010 05:59:07 -0400 Subject: [Numpy-discussion] ndarray __getattr__ to perform __getitem__ In-Reply-To: References: <4CC9DA44.20503@hkl.hms.harvard.edu> <4CC9ECFF.50803@hkl.hms.harvard.edu> Message-ID: <4CCA9AEB.4040108@hkl.hms.harvard.edu> >> But wouldn't the performance hit only come when I use it in this way? >> __getattr__ is only called if the named attribute is *not* found (I >> guess it falls off the end of the case statement, or is the result of >> the attribute hash table "miss"). > That's why I said that __getattr__ would perhaps work better. So do you want me to try out an implementation and supply a patch? If so, where should I send the patch? Ian -------------- next part -------------- A non-text attachment was scrubbed... Name: ijstokes.vcf Type: text/x-vcard Size: 394 bytes Desc: not available URL: From pav at iki.fi Fri Oct 29 06:18:20 2010 From: pav at iki.fi (Pauli Virtanen) Date: Fri, 29 Oct 2010 10:18:20 +0000 (UTC) Subject: [Numpy-discussion] Inconsistency with __index__() for rank-1 arrays? References: <201010271534.31139.faltet@pytables.org> <39C6BD15-2A48-4719-848B-23156CC7A03D@enthought.com> <201010290954.23642.faltet@pytables.org> Message-ID: Fri, 29 Oct 2010 09:54:23 +0200, Francesc Alted wrote: [clip] > My vote is +1 for deprecating ``array([scalar])`` as a scalar index for > NumPy 2.0. I'd be -0 on this, since 1-element Numpy arrays function like scalars in several other contexts, e.g. in casting to Python types and in boolean context. Note also that at least Python's struct module (mis-?)uses __index__() for casting inputs to integers. -- Pauli Virtanen From faltet at pytables.org Fri Oct 29 06:48:06 2010 From: faltet at pytables.org (Francesc Alted) Date: Fri, 29 Oct 2010 12:48:06 +0200 Subject: [Numpy-discussion] =?iso-8859-1?q?Inconsistency_with_=5F=5Findex?= =?iso-8859-1?q?=5F=5F=28=29_for_rank-1=09arrays=3F?= In-Reply-To: References: <201010271534.31139.faltet@pytables.org> <201010290954.23642.faltet@pytables.org> Message-ID: <201010291248.06125.faltet@pytables.org> A Friday 29 October 2010 12:18:20 Pauli Virtanen escrigu?: > Fri, 29 Oct 2010 09:54:23 +0200, Francesc Alted wrote: > [clip] > > > My vote is +1 for deprecating ``array([scalar])`` as a scalar index > > for NumPy 2.0. > > I'd be -0 on this, since 1-element Numpy arrays function like scalars > in several other contexts, e.g. in casting to Python types and in > boolean context. > > Note also that at least Python's struct module (mis-?)uses > __index__() for casting inputs to integers. Uh, could you put some examples of this please? -- Francesc Alted From pav at iki.fi Fri Oct 29 06:54:38 2010 From: pav at iki.fi (Pauli Virtanen) Date: Fri, 29 Oct 2010 10:54:38 +0000 (UTC) Subject: [Numpy-discussion] ndarray __getattr__ to perform __getitem__ References: <4CC9DA44.20503@hkl.hms.harvard.edu> <4CC9ECFF.50803@hkl.hms.harvard.edu> <4CCA9AEB.4040108@hkl.hms.harvard.edu> Message-ID: Hi, Fri, 29 Oct 2010 05:59:07 -0400, Ian Stokes-Rees wrote: >>> But wouldn't the performance hit only come when I use it in this way? >>> __getattr__ is only called if the named attribute is *not* found (I >>> guess it falls off the end of the case statement, or is the result of >>> the attribute hash table "miss"). >> That's why I said that __getattr__ would perhaps work better. > > So do you want me to try out an implementation and supply a patch? If > so, where should I send the patch? See here: http://docs.scipy.org/doc/numpy/dev/gitwash/patching.html -- Pauli Virtanen From pav at iki.fi Fri Oct 29 06:59:04 2010 From: pav at iki.fi (Pauli Virtanen) Date: Fri, 29 Oct 2010 12:59:04 +0200 Subject: [Numpy-discussion] Inconsistency with __index__() for rank-1 arrays? In-Reply-To: <201010291248.06125.faltet@pytables.org> References: <201010271534.31139.faltet@pytables.org> <201010290954.23642.faltet@pytables.org> <201010291248.06125.faltet@pytables.org> Message-ID: <1288349946.2976.6.camel@talisman> pe, 2010-10-29 kello 12:48 +0200, Francesc Alted kirjoitti: > A Friday 29 October 2010 12:18:20 Pauli Virtanen escrigu?: > > Fri, 29 Oct 2010 09:54:23 +0200, Francesc Alted wrote: > > [clip] > > > > > My vote is +1 for deprecating ``array([scalar])`` as a scalar index > > > for NumPy 2.0. > > > > I'd be -0 on this, since 1-element Numpy arrays function like scalars > > in several other contexts, e.g. in casting to Python types and in > > boolean context. > > > > Note also that at least Python's struct module (mis-?)uses > > __index__() for casting inputs to integers. > > Uh, could you put some examples of this please? Sure: if array([[1]]): print "OK" x = float(array([[1]])) and for the second point, in Python/Modules/_struct.c: 95 static PyObject * 96 get_pylong(PyObject *v) 97 { 98 assert(v != NULL); 99 if (!PyLong_Check(v)) { 100 /* Not an integer; try to use __index__ to convert. */ 101 if (PyIndex_Check(v)) { >>> import numpy as np, struct >>> struct.pack("i", np.array([1])) '\x01\x00\x00\x00' -- Pauli Virtanen From faltet at pytables.org Fri Oct 29 07:06:59 2010 From: faltet at pytables.org (Francesc Alted) Date: Fri, 29 Oct 2010 13:06:59 +0200 Subject: [Numpy-discussion] Inconsistency with __index__() for rank-1 arrays? In-Reply-To: <1288349946.2976.6.camel@talisman> References: <201010271534.31139.faltet@pytables.org> <201010291248.06125.faltet@pytables.org> <1288349946.2976.6.camel@talisman> Message-ID: <201010291306.59617.faltet@pytables.org> A Friday 29 October 2010 12:59:04 Pauli Virtanen escrigu?: > pe, 2010-10-29 kello 12:48 +0200, Francesc Alted kirjoitti: > > A Friday 29 October 2010 12:18:20 Pauli Virtanen escrigu?: > > > Fri, 29 Oct 2010 09:54:23 +0200, Francesc Alted wrote: > > > [clip] > > > > > > > My vote is +1 for deprecating ``array([scalar])`` as a scalar > > > > index for NumPy 2.0. > > > > > > I'd be -0 on this, since 1-element Numpy arrays function like > > > scalars in several other contexts, e.g. in casting to Python > > > types and in boolean context. > > > > > > Note also that at least Python's struct module (mis-?)uses > > > __index__() for casting inputs to integers. > > > > Uh, could you put some examples of this please? > > Sure: > > if array([[1]]): > print "OK" > > x = float(array([[1]])) > > and for the second point, in Python/Modules/_struct.c: > > 95 static PyObject * > 96 get_pylong(PyObject *v) > 97 { > 98 assert(v != NULL); > 99 if (!PyLong_Check(v)) { > 100 /* Not an integer; try to use __index__ to convert. > */ 101 if (PyIndex_Check(v)) { > > >>> import numpy as np, struct > >>> struct.pack("i", np.array([1])) > > '\x01\x00\x00\x00' I see. What I do not see if this behaviour is desirable (in fact, I think it is not, but I may be wrong of course). -- Francesc Alted From whg21 at cam.ac.uk Fri Oct 29 08:32:20 2010 From: whg21 at cam.ac.uk (Henry Gomersall) Date: Fri, 29 Oct 2010 13:32:20 +0100 Subject: [Numpy-discussion] Error in API docs? Message-ID: <1288355540.15977.9.camel@whg21-laptop> There is an inconsistency in the documentation for NPY_INOUT_ARRAY. cf. http://docs.scipy.org/doc/numpy/user/c-info.how-to-extend.html#NPY_INOUT_ARRAY http://docs.scipy.org/doc/numpy/reference/c-api.array.html#NPY_INOUT_ARRAY The first link includes the flag NPY_UPDATEIFCOPY. Checking the code seems to confirm that the correct version is that in the first link, and also that NPY_OUT_ARRAY is wrong in the API docs. I haven't checked NPY_INOUT_FARRAY or NPY_OUT_FARRAY. Cheers, Henry From matt.studley at gmail.com Fri Oct 29 08:35:20 2010 From: matt.studley at gmail.com (Matt Studley) Date: Fri, 29 Oct 2010 13:35:20 +0100 Subject: [Numpy-discussion] genfromtxt behaviour Message-ID: Hi all first, please forgive me for my ignorance - I am taking my first stumbling steps with numpy and scipy. I am having some difficulty with the behaviour of genfromtxt. s = SIO.StringIO("""1, 2, 3 4, 5, 6 7, 8, 9""") g= genfromtxt(s, delimiter=', ', dtype=None) print g[:,0] This produces the output I expected, a slice for column 0... array([1, 4, 7]) BUT.... s = SIO.StringIO("""a, 2, 3 b, 5, 6 c, 8, 9""") g= genfromtxt(s, delimiter=', ', dtype=None) g[:,0] Produces the following error: IndexError: invalid index .... In the first case, genfromtxt returns me a 2d array (list of lists), in the second it returns a list of tuples with an associated dtype list of tuples. How can I do my nice 2d slicing on the latter? array([('a', 2, 3), ('b', 5, 6), ('c', 8, 9)], dtype=[('f0', '|S1'), ('f1', ' References: Message-ID: On Oct 29, 2010, at 2:35 PM, Matt Studley wrote: > Hi all > > first, please forgive me for my ignorance - I am taking my first > stumbling steps with numpy and scipy. No problem, it;s educational > I am having some difficulty with the behaviour of genfromtxt. > > s = SIO.StringIO("""1, 2, 3 > 4, 5, 6 > 7, 8, 9""") > g= genfromtxt(s, delimiter=', ', dtype=None) > print g[:,0] > > > This produces the output I expected, a slice for column 0... > > array([1, 4, 7]) > > > BUT.... > > s = SIO.StringIO("""a, 2, 3 > b, 5, 6 > c, 8, 9""") > g= genfromtxt(s, delimiter=', ', dtype=None) > g[:,0] > > Produces the following error: > > IndexError: invalid index > > > .... > > In the first case, genfromtxt returns me a 2d array (list of lists), Well, not exactly. When you use dtype=None, genfromtxt tries to guess the type of the columns. Because in this case all your variables can be safely casted to integers, genfromtxt considers that the dtype is uniform and it outputs a 2D array. > in the second it returns a list of tuples with an associated dtype > list of tuples. Well, in this case, the first column is detected to be of type string, while the other columns are of type integers (as the dtype shows you). Therefore, genfromtxt considers that the dtype is structured and the output is a 1D array (each line is a tuple of 3 elements, the first one '|S1', the 2nd and 3rd ints > How can I do my nice 2d slicing on the latter? > > array([('a', 2, 3), ('b', 5, 6), ('c', 8, 9)], > dtype=[('f0', '|S1'), ('f1', ' >> How can I do my nice 2d slicing on the latter? >> >> array([('a', 2, 3), ('b', 5, 6), ('c', 8, 9)], >> dtype=[('f0', '|S1'), ('f1', 'Select a column by its name: >yourarray['f0'] Super! So I would need to get the dtype object... myData[ myData.dtype.names[0] ] in order to index by column. Matt From pgmdevlist at gmail.com Fri Oct 29 09:06:33 2010 From: pgmdevlist at gmail.com (Pierre GM) Date: Fri, 29 Oct 2010 15:06:33 +0200 Subject: [Numpy-discussion] genfromtxt behaviour In-Reply-To: References: Message-ID: <8D8058DB-ECD0-4F38-8C7D-41F06DB8E4C3@gmail.com> On Oct 29, 2010, at 2:59 PM, Matt Studley wrote: > > >>> How can I do my nice 2d slicing on the latter? >>> >>> array([('a', 2, 3), ('b', 5, 6), ('c', 8, 9)], >>> dtype=[('f0', '|S1'), ('f1', ' >> Select a column by its name: >> yourarray['f0'] > > Super! > > So I would need to get the dtype object... > > myData[ myData.dtype.names[0] ] > > in order to index by column. For a structured array, yes, you get it. From whg21 at cam.ac.uk Fri Oct 29 09:11:41 2010 From: whg21 at cam.ac.uk (Henry Gomersall) Date: Fri, 29 Oct 2010 14:11:41 +0100 Subject: [Numpy-discussion] C extension compiling question Message-ID: <1288357901.15977.30.camel@whg21-laptop> I'm trying to get a really simple toy example for a numpy extension working (you may notice its based on the example in the numpy docs and the python extension docs). The code is given below. The problem I am having is running the module segfaults at any attempt to access &PyArray_Type (so, as presented, the segfault occurs at the call to PyArg_ParseTuple). I've been assuming that importing numpy into the calling python code implicitly provides the numpy libraries that are necessary for linking. I can only assume I'm missing something. Do i need some additional includes etc in my compile flags? I'm currently using the distutils.core module and not the distutils module that comes with numpy if that makes a difference. I'm actually pretty keen to document what I've learnt as a 5 minute how-to for writing basic numpy extensions, if there is demand for it. It doesn't seem to exist as a coherent whole at the moment. Thanks, Henry #include #include PyMODINIT_FUNC initspam(void); static PyObject * spam_system(PyObject *self, PyObject *args); void worker_function(double *input, double *output, npy_intp size); static PyMethodDef SpamMethods[] = { {"system", spam_system, METH_VARARGS, "Execute a shell command."}, {NULL, NULL, 0, NULL} /* Sentinel */ }; PyMODINIT_FUNC initspam(void) { (void) Py_InitModule("spam", SpamMethods); } static PyObject * spam_system(PyObject *self, PyObject *args) { int n; int ndims; PyObject *inarg=NULL, *outarg=NULL; PyObject *inarr=NULL, *outarr=NULL; /* Both input and output need to be PyArray_Type type*/ if (!PyArg_ParseTuple(args, "O!O!", &PyArray_Type, &inarg, &PyArray_Type, &outarg)); return NULL; inarr = PyArray_FROM_OTF(inarg, NPY_DOUBLE, NPY_IN_ARRAY); if (inarr == NULL) goto fail; outarr = PyArray_FROM_OTF(outarg, NPY_DOUBLE, NPY_OUT_ARRAY); if (outarr == NULL) goto fail; /* Check the shape of the two arrays is the same */ ndims = ((PyArrayObject *)outarr)->nd; if (((PyArrayObject *)inarr)->nd != ndims) goto fail; /* ...still checking...*/ for (n=1; n Hi Travis, Could you look over the thread about dtype comparisonsand offer an opinion? TIA, Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From zachary.pincus at yale.edu Fri Oct 29 09:32:30 2010 From: zachary.pincus at yale.edu (Zachary Pincus) Date: Fri, 29 Oct 2010 09:32:30 -0400 Subject: [Numpy-discussion] ndarray __getattr__ to perform __getitem__ In-Reply-To: <4CCA9AEB.4040108@hkl.hms.harvard.edu> References: <4CC9DA44.20503@hkl.hms.harvard.edu> <4CC9ECFF.50803@hkl.hms.harvard.edu> <4CCA9AEB.4040108@hkl.hms.harvard.edu> Message-ID: <60619BFE-1A74-471C-9976-CC969AC09D49@yale.edu> >>> But wouldn't the performance hit only come when I use it in this >>> way? >>> __getattr__ is only called if the named attribute is *not* found (I >>> guess it falls off the end of the case statement, or is the result >>> of >>> the attribute hash table "miss"). >> That's why I said that __getattr__ would perhaps work better. > > > So do you want me to try out an implementation and supply a patch? If > so, where should I send the patch? > > Ian Note that there are various extant projects that I think attempt to provide similar functionality to what you're wanting (unless I badly misread your original email, in which case apologies): http://projects.scipy.org/numpy/wiki/NdarrayWithNamedAxes You might want to check these out (or pitch in with those efforts) before starting up your own variant. (Though if your idea has more modest goals, then it might be a good complement to these more extensive/intrusive solutions.) Zach From wright at esrf.fr Fri Oct 29 09:33:30 2010 From: wright at esrf.fr (Jon Wright) Date: Fri, 29 Oct 2010 15:33:30 +0200 Subject: [Numpy-discussion] C extension compiling question In-Reply-To: <1288357901.15977.30.camel@whg21-laptop> References: <1288357901.15977.30.camel@whg21-laptop> Message-ID: <4CCACD2A.3050904@esrf.fr> Dear Henry, You need to call import_array() in initspam. See: http://docs.scipy.org/doc/numpy-1.5.x/user/c-info.how-to-extend.html HTH, Jon On 29/10/2010 15:11, Henry Gomersall wrote: > I'm trying to get a really simple toy example for a numpy extension > working (you may notice its based on the example in the numpy docs and > the python extension docs). The code is given below. > > The problem I am having is running the module segfaults at any attempt > to access&PyArray_Type (so, as presented, the segfault occurs at the > call to PyArg_ParseTuple). I've been assuming that importing numpy into > the calling python code implicitly provides the numpy libraries that are > necessary for linking. I can only assume I'm missing something. Do i > need some additional includes etc in my compile flags? > > I'm currently using the distutils.core module and not the distutils > module that comes with numpy if that makes a difference. > > I'm actually pretty keen to document what I've learnt as a 5 minute > how-to for writing basic numpy extensions, if there is demand for it. It > doesn't seem to exist as a coherent whole at the moment. > > Thanks, > > Henry > > #include > #include > > PyMODINIT_FUNC > initspam(void); > > static PyObject * > spam_system(PyObject *self, PyObject *args); > > void > worker_function(double *input, double *output, npy_intp size); > > static PyMethodDef SpamMethods[] = { > {"system", spam_system, METH_VARARGS, > "Execute a shell command."}, > {NULL, NULL, 0, NULL} /* Sentinel */ > }; > > PyMODINIT_FUNC > initspam(void) > { > (void) Py_InitModule("spam", SpamMethods); > } > > static PyObject * > spam_system(PyObject *self, PyObject *args) > { > int n; > int ndims; > > PyObject *inarg=NULL, *outarg=NULL; > PyObject *inarr=NULL, *outarr=NULL; > > /* Both input and output need to be PyArray_Type type*/ > if (!PyArg_ParseTuple(args, "O!O!",&PyArray_Type,&inarg, > &PyArray_Type,&outarg)); > return NULL; > > inarr = PyArray_FROM_OTF(inarg, NPY_DOUBLE, NPY_IN_ARRAY); > if (inarr == NULL) goto fail; > > outarr = PyArray_FROM_OTF(outarg, NPY_DOUBLE, NPY_OUT_ARRAY); > if (outarr == NULL) goto fail; > > /* Check the shape of the two arrays is the same */ > ndims = ((PyArrayObject *)outarr)->nd; > if (((PyArrayObject *)inarr)->nd != ndims) > goto fail; > > /* ...still checking...*/ > for (n=1; n { > if (PyArray_DIM(inarr,n) != PyArray_DIM(outarr,n)) > goto fail; > } > > /* Now actually do something with the arrays */ > worker_function((double *)PyArray_DATA(inarr), > (double *)PyArray_DATA(outarr), > PyArray_Size(inarr)); > > Py_DECREF(inarr); > Py_DECREF(outarr); > return Py_None; > > fail: > Py_XDECREF(inarr); > Py_XDECREF(outarr); > return NULL; > } > > void > worker_function(double *input, double *output, npy_intp size) > { > npy_intp n; > > for (n=0;n { > output[n] = input[n] + 10; > } > return; > } > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion From whg21 at cam.ac.uk Fri Oct 29 09:45:59 2010 From: whg21 at cam.ac.uk (Henry Gomersall) Date: Fri, 29 Oct 2010 14:45:59 +0100 Subject: [Numpy-discussion] C extension compiling question In-Reply-To: <4CCACD2A.3050904@esrf.fr> References: <1288357901.15977.30.camel@whg21-laptop> <4CCACD2A.3050904@esrf.fr> Message-ID: <1288359959.15977.35.camel@whg21-laptop> On Fri, 2010-10-29 at 15:33 +0200, Jon Wright wrote: > > You need to call import_array() in initspam. See: > http://docs.scipy.org/doc/numpy-1.5.x/user/c-info.how-to-extend.html Thanks, that solves it. It would be really useful to have a complete example somewhere. As in, a set of files for a minimum example that builds and runs. Thanks, Henry From ijstokes at hkl.hms.harvard.edu Fri Oct 29 09:58:33 2010 From: ijstokes at hkl.hms.harvard.edu (Ian Stokes-Rees) Date: Fri, 29 Oct 2010 09:58:33 -0400 Subject: [Numpy-discussion] ndarray __getattr__ to perform __getitem__ In-Reply-To: <60619BFE-1A74-471C-9976-CC969AC09D49@yale.edu> References: <4CC9DA44.20503@hkl.hms.harvard.edu> <4CC9ECFF.50803@hkl.hms.harvard.edu> <4CCA9AEB.4040108@hkl.hms.harvard.edu> <60619BFE-1A74-471C-9976-CC969AC09D49@yale.edu> Message-ID: <4CCAD309.6090709@hkl.hms.harvard.edu> > Note that there are various extant projects that I think attempt to > provide similar functionality to what you're wanting (unless I badly > misread your original email, in which case apologies): > http://projects.scipy.org/numpy/wiki/NdarrayWithNamedAxes Having looked into it more, I think recarray is probably what I want. I need to play with this and see how easy it is to convert ndarrays into recarrays. The main thing is that I'm looking for something *really* simple that would, truly, just allow the conversion of: myarray['myaxis'] to myarray.myaxis My suggestion is to define __getattr__ directly on the ndarray class. This is, TTBOMK, only called if an attribute is *not* found on the object. In this event, prior to throwing an AttributeError exception, the object could check to see if the specified attribute exists as a named axis/dimension of the multi-dimensional array, and if so, return this. Otherwise, carry on with the AttributeError exception. I've spent an hour looking at the numpy code (my first time), and I don't see any obvious way to do this, since ndarray is (AFAICT) a pure-C object with auto-generated wrappers, which seems to preclude (easily) adding a "__getattr__(self,attr)" method to the class. If someone can point me in the right direction, I'll keep looking into this, otherwise I'm giving up and will just try and use recarray. Ian From pgmdevlist at gmail.com Fri Oct 29 10:23:24 2010 From: pgmdevlist at gmail.com (Pierre GM) Date: Fri, 29 Oct 2010 16:23:24 +0200 Subject: [Numpy-discussion] ndarray __getattr__ to perform __getitem__ In-Reply-To: <4CCAD309.6090709@hkl.hms.harvard.edu> References: <4CC9DA44.20503@hkl.hms.harvard.edu> <4CC9ECFF.50803@hkl.hms.harvard.edu> <4CCA9AEB.4040108@hkl.hms.harvard.edu> <60619BFE-1A74-471C-9976-CC969AC09D49@yale.edu> <4CCAD309.6090709@hkl.hms.harvard.edu> Message-ID: <622BEE07-B171-4EBD-8042-0C6A637ED69C@gmail.com> On Oct 29, 2010, at 3:58 PM, Ian Stokes-Rees wrote: > >> Note that there are various extant projects that I think attempt to >> provide similar functionality to what you're wanting (unless I badly >> misread your original email, in which case apologies): >> http://projects.scipy.org/numpy/wiki/NdarrayWithNamedAxes > > Having looked into it more, I think recarray is probably what I want. I > need to play with this and see how easy it is to convert ndarrays into > recarrays. your_rec=your_array.view(np.recarray) > The main thing is that I'm looking for something *really* simple that > would, truly, just allow the conversion of: > > myarray['myaxis'] > > to > > myarray.myaxis Attribute-style access is IMHO the only interest of recarrays over regular structured arrays. Note that it comes to a cost... > My suggestion is to define __getattr__ directly on the ndarray class. > This is, TTBOMK, only called if an attribute is *not* found on the > object. In this event, prior to throwing an AttributeError exception, > the object could check to see if the specified attribute exists as a > named axis/dimension of the multi-dimensional array, and if so, return > this. Otherwise, carry on with the AttributeError exception. > > I've spent an hour looking at the numpy code (my first time), and I > don't see any obvious way to do this, since ndarray is (AFAICT) a pure-C > object with auto-generated wrappers, which seems to preclude (easily) > adding a "__getattr__(self,attr)" method to the class. If someone can > point me in the right direction, I'll keep looking into this, otherwise > I'm giving up and will just try and use recarray. Indeed. Check how recarray does it, for example. From robert.kern at gmail.com Fri Oct 29 10:28:45 2010 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 29 Oct 2010 09:28:45 -0500 Subject: [Numpy-discussion] C extension compiling question In-Reply-To: <1288359959.15977.35.camel@whg21-laptop> References: <1288357901.15977.30.camel@whg21-laptop> <4CCACD2A.3050904@esrf.fr> <1288359959.15977.35.camel@whg21-laptop> Message-ID: On Fri, Oct 29, 2010 at 08:45, Henry Gomersall wrote: > On Fri, 2010-10-29 at 15:33 +0200, Jon Wright wrote: >> >> You need to call import_array() in initspam. See: >> http://docs.scipy.org/doc/numpy-1.5.x/user/c-info.how-to-extend.html > > Thanks, that solves it. > > It would be really useful to have a complete example somewhere. As in, a > set of files for a minimum example that builds and runs. http://github.com/numpy/numpy/tree/master/doc/newdtype_example/ -- 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 From lou_boog2000 at yahoo.com Fri Oct 29 10:48:17 2010 From: lou_boog2000 at yahoo.com (Lou Pecora) Date: Fri, 29 Oct 2010 07:48:17 -0700 (PDT) Subject: [Numpy-discussion] C extension compiling question In-Reply-To: <1288357901.15977.30.camel@whg21-laptop> References: <1288357901.15977.30.camel@whg21-laptop> Message-ID: <479484.39107.qm@web34405.mail.mud.yahoo.com> ----- Original Message ---- From: Henry Gomersall To: numpy-discussion Sent: Fri, October 29, 2010 9:11:41 AM Subject: [Numpy-discussion] C extension compiling question I'm trying to get a really simple toy example for a numpy extension working (you may notice its based on the example in the numpy docs and the python extension docs). The code is given below. --------------------------------------------------------------- If you're trying to use numpy and standard pythons types, you might want to look into ctypes which allows you to write C extensions that pass arrays in a much easier way. I was into writing "bare" C extensions from the ground up like you when someone put me onto ctypes. MUCH easier and cleaner and, as a result, easier to debug. I recommend it. -- Lou Pecora, my views are my own. From pav at iki.fi Fri Oct 29 11:05:18 2010 From: pav at iki.fi (Pauli Virtanen) Date: Fri, 29 Oct 2010 15:05:18 +0000 (UTC) Subject: [Numpy-discussion] ndarray __getattr__ to perform __getitem__ References: <4CC9DA44.20503@hkl.hms.harvard.edu> <4CC9ECFF.50803@hkl.hms.harvard.edu> <4CCA9AEB.4040108@hkl.hms.harvard.edu> <60619BFE-1A74-471C-9976-CC969AC09D49@yale.edu> <4CCAD309.6090709@hkl.hms.harvard.edu> Message-ID: Fri, 29 Oct 2010 09:58:33 -0400, Ian Stokes-Rees wrote: [clip] > I've spent an hour looking at the numpy code (my first time), and I > don't see any obvious way to do this, since ndarray is (AFAICT) a pure-C > object with auto-generated wrappers, which seems to preclude (easily) > adding a "__getattr__(self,attr)" method to the class. If someone can > point me in the right direction, I'll keep looking into this, otherwise > I'm giving up and will just try and use recarray. http://docs.python.org/c-api/typeobj.html#tp_getattro The Python documentation doesn't seem to say very if method/attribute slots are consulted before falling back to tp_getattro. If tp_getattro is consulted first, then implementing it will lead to a performance hit. I'd probably be +0 on providing recarray-like functionality on ordinary ndarrays, if it can be done without (significant) performance issues. -- Pauli Virtanen From josef.pktd at gmail.com Fri Oct 29 12:41:14 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Fri, 29 Oct 2010 12:41:14 -0400 Subject: [Numpy-discussion] ValueError with np.polynomial.Polynomial([1]).roots() Message-ID: For the lag polynomials I have cases where the order is zero, but roots raises a ValueError. Is this intended? Then, I need to catch it in my code. I haven't checked yet if my other parts will go through with empty roots. >>> np.polynomial.Polynomial([1]) Polynomial([ 1.], [-1., 1.]) >>> np.polynomial.Polynomial([1]).roots() Traceback (most recent call last): File "", line 1, in np.polynomial.Polynomial([1]).roots() File "", line 485, in roots File "C:\Programs\Python25\lib\site-packages\numpy\polynomial\polyutils.py", line 280, in mapdomain [x] = as_series([x], trim=False) File "C:\Programs\Python25\lib\site-packages\numpy\polynomial\polyutils.py", line 137, in as_series raise ValueError("Coefficient array is empty") ValueError: Coefficient array is empty Josef From charlesr.harris at gmail.com Fri Oct 29 12:50:37 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Fri, 29 Oct 2010 10:50:37 -0600 Subject: [Numpy-discussion] ValueError with np.polynomial.Polynomial([1]).roots() In-Reply-To: References: Message-ID: On Fri, Oct 29, 2010 at 10:41 AM, wrote: > For the lag polynomials I have cases where the order is zero, but > roots raises a ValueError. > > Is this intended? > Then, I need to catch it in my code. I haven't checked yet if my other > parts will go through with empty roots. > > >>> np.polynomial.Polynomial([1]) > Polynomial([ 1.], [-1., 1.]) > >>> np.polynomial.Polynomial([1]).roots() > Traceback (most recent call last): > File "", line 1, in > np.polynomial.Polynomial([1]).roots() > File "", line 485, in roots > File > "C:\Programs\Python25\lib\site-packages\numpy\polynomial\polyutils.py", > line 280, in mapdomain > [x] = as_series([x], trim=False) > File > "C:\Programs\Python25\lib\site-packages\numpy\polynomial\polyutils.py", > line 137, in as_series > raise ValueError("Coefficient array is empty") > ValueError: Coefficient array is empty > > This has been fixed in trunk to return an empty array: In [2]: import numpy.polynomial as poly In [3]: p = poly.Polynomial([1]) In [4]: p Out[4]: Polynomial([ 1.], [-1., 1.]) In [5]: p.roots() Out[5]: array([], dtype=float64) What version are you seeing this in? Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Fri Oct 29 13:06:12 2010 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Fri, 29 Oct 2010 13:06:12 -0400 Subject: [Numpy-discussion] ValueError with np.polynomial.Polynomial([1]).roots() In-Reply-To: References: Message-ID: On Fri, Oct 29, 2010 at 12:50 PM, Charles R Harris wrote: > > > On Fri, Oct 29, 2010 at 10:41 AM, wrote: >> >> For the lag polynomials I have cases where the order is zero, but >> roots raises a ValueError. >> >> Is this intended? >> Then, I need to catch it in my code. I haven't checked yet if my other >> parts will go through with empty roots. >> >> >>> np.polynomial.Polynomial([1]) >> Polynomial([ 1.], [-1., ?1.]) >> >>> np.polynomial.Polynomial([1]).roots() >> Traceback (most recent call last): >> ?File "", line 1, in >> ? ?np.polynomial.Polynomial([1]).roots() >> ?File "", line 485, in roots >> ?File >> "C:\Programs\Python25\lib\site-packages\numpy\polynomial\polyutils.py", >> line 280, in mapdomain >> ? ?[x] = as_series([x], trim=False) >> ?File >> "C:\Programs\Python25\lib\site-packages\numpy\polynomial\polyutils.py", >> line 137, in as_series >> ? ?raise ValueError("Coefficient array is empty") >> ValueError: Coefficient array is empty >> > > This has been fixed in trunk to return an empty array: > > In [2]: import numpy.polynomial as poly > > In [3]: p = poly.Polynomial([1]) > > In [4]: p > Out[4]: Polynomial([ 1.], [-1.,? 1.]) > > In [5]: p.roots() > Out[5]: array([], dtype=float64) > > What version are you seeing this in? I'm old, numpy 1.4.0 empty array is good, it works with the rest so far. Thanks, Josef > > Chuck > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > From oliphant at enthought.com Fri Oct 29 17:40:20 2010 From: oliphant at enthought.com (Travis Oliphant) Date: Fri, 29 Oct 2010 17:40:20 -0400 Subject: [Numpy-discussion] Hi Travis In-Reply-To: References: Message-ID: <39CB10AF-2C77-47BC-8F7F-FC5D6D4D796A@enthought.com> Thanks for pointing out the discussion. This is an oversight. The dtypes should not compare equal if the subarrays don't match. If the patch looks OK, then we should accept it. Travis -- (mobile phone of) Travis Oliphant Enthought, Inc. 1-512-536-1057 http://www.enthought.com On Oct 29, 2010, at 9:20 AM, Charles R Harris wrote: > Hi Travis, > > Could you look over the thread about dtype comparisons and offer an opinion? > > TIA, > > Chuck > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Fri Oct 29 18:10:36 2010 From: pav at iki.fi (Pauli Virtanen) Date: Fri, 29 Oct 2010 22:10:36 +0000 (UTC) Subject: [Numpy-discussion] Hi Travis References: <39CB10AF-2C77-47BC-8F7F-FC5D6D4D796A@enthought.com> Message-ID: Hi Travis! Fri, 29 Oct 2010 17:40:20 -0400, Travis Oliphant wrote: > Thanks for pointing out the discussion. This is an oversight. The > dtypes should not compare equal if the subarrays don't match. > > If the patch looks OK, then we should accept it. Another issue from the thread where you might want to chip in: >>> x = np.zeros((2, 3), dtype=[('a', 'f8', (4,))]) >>> x.T['a'].shape (4, 3, 2) >>> x.T.copy()['a'].shape (3, 2, 4) Fortran-order is special-cased. We might want to change this to work like so: >>> x.T['a'].shape (3, 2, 4) which is more predictable. -- Pauli Virtanen From oliphant at enthought.com Fri Oct 29 21:20:40 2010 From: oliphant at enthought.com (Travis Oliphant) Date: Fri, 29 Oct 2010 21:20:40 -0400 Subject: [Numpy-discussion] Hi Travis In-Reply-To: References: <39CB10AF-2C77-47BC-8F7F-FC5D6D4D796A@enthought.com> Message-ID: Yeah. This does look odd and should be fixed. -- (mobile phone of) Travis Oliphant Enthought, Inc. 1-512-536-1057 http://www.enthought.com On Oct 29, 2010, at 6:10 PM, Pauli Virtanen wrote: > Hi Travis! > > Fri, 29 Oct 2010 17:40:20 -0400, Travis Oliphant wrote: >> Thanks for pointing out the discussion. This is an oversight. The >> dtypes should not compare equal if the subarrays don't match. >> >> If the patch looks OK, then we should accept it. > > Another issue from the thread where you might want to chip in: > >>>> x = np.zeros((2, 3), dtype=[('a', 'f8', (4,))]) >>>> x.T['a'].shape > (4, 3, 2) >>>> x.T.copy()['a'].shape > (3, 2, 4) > > Fortran-order is special-cased. We might want to change this to work like > so: > >>>> x.T['a'].shape > (3, 2, 4) > > which is more predictable. > > -- > Pauli Virtanen > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion From dsdale24 at gmail.com Sat Oct 30 09:54:20 2010 From: dsdale24 at gmail.com (Darren Dale) Date: Sat, 30 Oct 2010 09:54:20 -0400 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: On Thu, Oct 28, 2010 at 12:11 PM, Charles R Harris wrote: > > > On Thu, Oct 28, 2010 at 9:23 AM, Darren Dale wrote: >> >> Hi Chuck, >> >> On Wed, Oct 27, 2010 at 1:30 PM, Charles R Harris >> wrote: >> > >> > I'd like to do something here, but I'm waiting for a consensus and for >> > someone to test things out, maybe with a test repo, to make sure things >> > operate correctly. The documentation isn't that clear... >> >> I am getting ready to test on windows and mac. In the process of >> upgrading git on windows to 1.7.3.1, The following dialog appeared: >> >> Configuring line ending conversions >> ?How should Git treat line endings in text files? >> >> x Checkout Windows-style, commit Unix-style line endings >> ?Git will convert LF to CRLF when checking out text files. When >> committing text files, CRLF will be converted to LF. For >> cross-platform projects, this is the recommended setting on Windows >> ("core.autocrlf" is set to "true") >> >> o Checkout as-is, commit Unix-style line endings >> ?Git will not perform any conversion when checking out text files. >> When committing text files, CRLF will be converted to LF. For >> cross-platform projects this is the recommended setting on Unix >> ("core.autocrlf" is set to "input"). >> >> o Checkout as-is, commit as-is >> ?Git will not perform any conversions when checking out or committing >> text files. Choosing this option is not recommended for cross-platform >> projects ("core.autocrlf" is set to "false") >> >> This might warrant a very brief mention in the docs, for helping >> people set up their environment. Its too bad core.autocrlf cannot be >> set on a per-project basis in a file that gets committed to the > > Yes, this would be good information to have in the notes. > >> >> repository. As far as I can tell, it can only be set in ~/.gitconfig >> or numpy/.git/config. Which is why I suggested adding .gitattributes, >> which can be committed to the repository, and the line "* text=auto" >> ensures that EOLs in text files are committed as LF, so we don't have >> to worry about somebody's config settings having unwanted impact on >> the repository. > > Might be worth trying in a numpy/.gitconfig just to see what happens. > Documentation isn't always complete. Now that I understand the situation a little better, I don't think we would want such a .gitconfig in the repository itself. Most windows users would probably opt for autcrlf=true, but that is definitely not the case for mac and linux users. I've been testing the changes in the pull request this morning on linux, mac and windows, all using git-1.7.3.1. I made a testing branch from whitespace-cleanup and added two files created on windows: temp.txt and tmp.txt. One of them was added to .gitattributes to preserve the crlf in the repo. windows: with autocrlf=true, all files in the working directory are crlf. With autocrlf=false, files marked in .gitattributes for crlf do have crlf, the other files are lf. Check. mac: tested with autocrlf=input. files marked in .gitattributes for crlf have crlf, others are lf. Check. linux (kubuntu 10.10): tested with autocrlf=input and false. All files in the working directory have lf, even those marked for crlf. This is confusing. I copied temp.txt from windows, verified that it still had crlf endings, and copied it into the working directory. Git warns that crlf will be converted to lf, but attempting a commit yields "nothing to do". I had to do "git add temp.txt", at which point git status tells me the working directory is clean and there is nothing to commit. I'm not too worried about this, its a situation that is unlikely to ever occur in practice. I think I have convinced myself that the pull request is satisfactory. Devs should bear in mind, though, that there is a small risk when committing changes to binary files that git will corrupt such a file by incorrectly identifying and converting crlf to lf. Git should warn when line conversions are going to take place, so they can be disabled for a binary file in .gitattributes: mybinaryfile.dat -text That is all, Darren From charlesr.harris at gmail.com Sat Oct 30 10:41:53 2010 From: charlesr.harris at gmail.com (Charles R Harris) Date: Sat, 30 Oct 2010 08:41:53 -0600 Subject: [Numpy-discussion] whitespace in git repo In-Reply-To: References: Message-ID: On Sat, Oct 30, 2010 at 7:54 AM, Darren Dale wrote: > On Thu, Oct 28, 2010 at 12:11 PM, Charles R Harris > wrote: > > > > > > On Thu, Oct 28, 2010 at 9:23 AM, Darren Dale wrote: > >> > >> Hi Chuck, > >> > >> On Wed, Oct 27, 2010 at 1:30 PM, Charles R Harris > >> wrote: > >> > > >> > I'd like to do something here, but I'm waiting for a consensus and for > >> > someone to test things out, maybe with a test repo, to make sure > things > >> > operate correctly. The documentation isn't that clear... > >> > >> I am getting ready to test on windows and mac. In the process of > >> upgrading git on windows to 1.7.3.1, The following dialog appeared: > >> > >> Configuring line ending conversions > >> How should Git treat line endings in text files? > >> > >> x Checkout Windows-style, commit Unix-style line endings > >> Git will convert LF to CRLF when checking out text files. When > >> committing text files, CRLF will be converted to LF. For > >> cross-platform projects, this is the recommended setting on Windows > >> ("core.autocrlf" is set to "true") > >> > >> o Checkout as-is, commit Unix-style line endings > >> Git will not perform any conversion when checking out text files. > >> When committing text files, CRLF will be converted to LF. For > >> cross-platform projects this is the recommended setting on Unix > >> ("core.autocrlf" is set to "input"). > >> > >> o Checkout as-is, commit as-is > >> Git will not perform any conversions when checking out or committing > >> text files. Choosing this option is not recommended for cross-platform > >> projects ("core.autocrlf" is set to "false") > >> > >> This might warrant a very brief mention in the docs, for helping > >> people set up their environment. Its too bad core.autocrlf cannot be > >> set on a per-project basis in a file that gets committed to the > > > > Yes, this would be good information to have in the notes. > > > >> > >> repository. As far as I can tell, it can only be set in ~/.gitconfig > >> or numpy/.git/config. Which is why I suggested adding .gitattributes, > >> which can be committed to the repository, and the line "* text=auto" > >> ensures that EOLs in text files are committed as LF, so we don't have > >> to worry about somebody's config settings having unwanted impact on > >> the repository. > > > > Might be worth trying in a numpy/.gitconfig just to see what happens. > > Documentation isn't always complete. > > Now that I understand the situation a little better, I don't think we > would want such a .gitconfig in the repository itself. Most windows > users would probably opt for autcrlf=true, but that is definitely not > the case for mac and linux users. > > I've been testing the changes in the pull request this morning on > linux, mac and windows, all using git-1.7.3.1. I made a testing branch > from whitespace-cleanup and added two files created on windows: > temp.txt and tmp.txt. One of them was added to .gitattributes to > preserve the crlf in the repo. > > windows: with autocrlf=true, all files in the working directory are > crlf. With autocrlf=false, files marked in .gitattributes for crlf do > have crlf, the other files are lf. Check. > > Good, sounds like windows is safe. > mac: tested with autocrlf=input. files marked in .gitattributes for > crlf have crlf, others are lf. Check. > > Good. > linux (kubuntu 10.10): tested with autocrlf=input and false. All files > in the working directory have lf, even those marked for crlf. This is > confusing. I copied temp.txt from windows, verified that it still had > crlf endings, and copied it into the working directory. Git warns that > crlf will be converted to lf, but attempting a commit yields "nothing > to do". I had to do "git add temp.txt", at which point git status > tells me the working directory is clean and there is nothing to > commit. I'm not too worried about this, its a situation that is > unlikely to ever occur in practice. > > That is confusing, I would have hoped that Mac and Linux would behave the same way. I'm guessing that git stores text internally with LF and adds CR on checkout on the other platforms but not linux, or at least Ubuntu. I think I have convinced myself that the pull request is satisfactory. > Devs should bear in mind, though, that there is a small risk when > committing changes to binary files that git will corrupt such a file > by incorrectly identifying and converting crlf to lf. Git should warn > when line conversions are going to take place, so they can be disabled > for a binary file in .gitattributes: > > mybinaryfile.dat -text > > That is all, > > Thanks for testing this out, I'll make the commit. I suppose if something goes wrong somewhere down the line we can always fix it up. I'm particularly happy with the information on Windows as that was my main concern. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From cournape at gmail.com Sun Oct 31 02:46:45 2010 From: cournape at gmail.com (David Cournapeau) Date: Sun, 31 Oct 2010 15:46:45 +0900 Subject: [Numpy-discussion] Including fix for #1637 in 1.5.1 ? Message-ID: Hi, I just committed a quick fix for http://projects.scipy.org/numpy/ticket/1637. I did want to include it for 1.5.x branch as it is already in RC stage, but it may still be useful to do so if the release managers think it is appropriate (there is a test for it): http://github.com/numpy/numpy/commit/cdcbaa4ce4b47a7bfd8905222124fd22460252a5 cheers, David From Nikolaus at rath.org Sun Oct 31 12:10:04 2010 From: Nikolaus at rath.org (Nikolaus Rath) Date: Sun, 31 Oct 2010 12:10:04 -0400 Subject: [Numpy-discussion] List with numpy semantics Message-ID: <878w1e738j.fsf@vostro.rath.org> Hello, I have a couple of numpy arrays which belong together. Unfortunately they have different dimensions, so I can't bundle them into a higher dimensional array. My solution was to put them into a Python list instead. But unfortunately this makes it impossible to use any ufuncs. Has someone else encountered a similar problem and found a nice solution? Something like a numpy list maybe? Best, -Nikolaus -- ?Time flies like an arrow, fruit flies like a Banana.? PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C From gerrit.holl at gmail.com Sun Oct 31 13:17:42 2010 From: gerrit.holl at gmail.com (Gerrit Holl) Date: Sun, 31 Oct 2010 18:17:42 +0100 Subject: [Numpy-discussion] List with numpy semantics In-Reply-To: <878w1e738j.fsf@vostro.rath.org> References: <878w1e738j.fsf@vostro.rath.org> Message-ID: On 31 October 2010 17:10, Nikolaus Rath wrote: > Hello, > > I have a couple of numpy arrays which belong together. Unfortunately > they have different dimensions, so I can't bundle them into a higher > dimensional array. > > My solution was to put them into a Python list instead. But > unfortunately this makes it impossible to use any ufuncs. > > Has someone else encountered a similar problem and found a nice > solution? Something like a numpy list maybe? You could try a record array with a clever dtype, maybe? Gerrit. From fperez.net at gmail.com Sun Oct 31 15:08:46 2010 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 31 Oct 2010 12:08:46 -0700 Subject: [Numpy-discussion] IPython on python3, for the adventurous... Message-ID: Hi all, thanks to the great work done by Thomas Kluyver, for those of you starting to use Numpy (or other projects) on Python 3 and who wanted to have IPython as your working environment, things are getting off the ground: (py3k)amirbar[py3k]> python3 ipython.py Python 3.1.2 (release31-maint, Sep 17 2010, 20:34:23) Type "copyright", "credits" or "license" for more information. IPython 0.11.alpha1.git -- An enhanced Interactive Python. ? -> Introduction and overview of IPython's features. %quickref -> Quick reference. help -> Python's own help system. object? -> Details about 'object', use 'object??' for extra details. In [1]: import io In [2]: import sys In [3]: sys.ver sys.version sys.version_info In [3]: sys.version Out[3]: '3.1.2 (release31-maint, Sep 17 2010, 20:34:23) \n[GCC 4.4.5]' etc... This is still very much a work in progress, and we haven't made any official release. But there's a github repo up and running with a proper bug tracker, so by all means let us know what works and what doesnt' (and even better, join in with help!): http://github.com/ipython/ipython-py3k Our hope is to eventually merge this work into ipython proper at some point in the future, but since the history of this branch is likely to be messy (with many merges from trunk, auto-generated code and possible rebases down the road) we're keeping it in a separate repo for now. Cheers, f From bevan07 at gmail.com Sun Oct 31 16:28:42 2010 From: bevan07 at gmail.com (bevan jenkins) Date: Mon, 1 Nov 2010 09:28:42 +1300 Subject: [Numpy-discussion] np.ma.masked_invalid and precision Message-ID: Hello, I am not sure if the following is a bug or not. I recently tried to set the print precision in numpy but it didn't seem to make a difference. It seems that the use of np.ma.masked_invalid results in arrays printing precision of 12 regardless of the default setting or any subsequent setting. Generating masked arrays does not seem to have this behaviour. Is this a bug or am I doing it wrong? Thanks, Bevan In [1]: eg = np.random.random(1) In [2]: eg_mask = np.ma.masked_array(eg) In [3]: eg_mask_invalid = np.ma.masked_invalid(eg) In [4]: eg Out[4]: array([ 0.78592569]) In [5]: eg_mask Out[5]: masked_array(data = [ 0.78592569], mask = False, fill_value = 1e+20) In [6]: eg_mask_invalid Out[6]: masked_array(data = [0.785925693305], mask = [False], fill_value = 1e+20) In [7]: np.set_printoptions(precision=3) In [8]: eg Out[8]: array([ 0.786]) In [9]: eg_mask Out[9]: masked_array(data = [ 0.786], mask = False, fill_value = 1e+20) In [10]: eg_mask_invalid Out[10]: masked_array(data = [0.785925693305], mask = [False], fill_value = 1e+20) -------------- next part -------------- An HTML attachment was scrubbed... URL: From pgmdevlist at gmail.com Sun Oct 31 18:06:46 2010 From: pgmdevlist at gmail.com (Pierre GM) Date: Sun, 31 Oct 2010 23:06:46 +0100 Subject: [Numpy-discussion] np.ma.masked_invalid and precision In-Reply-To: References: Message-ID: <061590EF-AF59-4B5F-A899-9E552D523474@gmail.com> On Oct 31, 2010, at 9:28 PM, bevan jenkins wrote: > Hello, > > I am not sure if the following is a bug or not. I recently tried to set the > print precision in numpy but it didn't seem to make a difference. It seems > that the use of np.ma.masked_invalid results in arrays printing precision of > 12 regardless of the default setting or any subsequent setting. Generating > masked arrays does not seem to have this behaviour. Is this a bug or am I doing it wrong? Mmh, probably a bug, I'd say. Mind opening a ticket ? Thanks in advance P.