Re: [Numpy-discussion] f2py and setup.py how can I specify where the .so file goes?
On 10 July 2013 17:50, Jose Gomez-Dans jgomezd...@gmail.com wrote:
Hi,
I am building a package that exposes some Fortran libraries through f2py.
The packages directory looks like this:
setup.py
my_pack/
|
|--__init__.py
|-- some.pyf
|--- code.f90
I thoughat that once installed, I'd get the .so and __init__.py in the same
directory (namely ~/.local/lib/python2.7/site-packages/my_pack/). However, I
get
~/.local/lib/python2.7/site-packages/mypack_fortran.so
~/.local/lib/python2.7/site-packages/my_pack__fortran-1.0.2-py2.7.egg-info
~/.local/lib/python2.7/site-packages/my_pack/__init__.py
Thet setup file is this at the end, I am clearly missing some option here to
move the *.so into the my_pack directory Anybody know which one?
Cheers
Jose
[setup.py]
#!/usr/bin/env python
def configuration(parent_package='',top_path=None):
from numpy.distutils.misc_util import Configuration
config = Configuration(parent_package,top_path)
config.add_extension('mypack_fortran', ['the_pack/code.f90'] )
return config
if __name__ == __main__:
from numpy.distutils.core import setup
# Global variables for this extension:
name = mypack_fortran # name of the generated python
extension (.so)
description = blah
author =
author_email =
setup( name=name,\
description=description, \
author=author, \
author_email = author_email, \
configuration = configuration, version=1.0.2,\
packages=[my_pack])
Something like the following should work...
from numpy.distutils.core import setup, Extension
my_ext = Extension(name = 'my_pack._fortran',
sources = ['my_pack/code.f90'])
if __name__ == __main__:
setup(name = 'my_pack',
description = ...,
author =...,
author_email = ...,
version = ...,
packages = ['my_pack'],
ext_modules = [my_ext],
)
Cheers,
Scott
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Allow == and != to raise errors
Hey, the array comparisons == and != never raise errors but instead simply return False for invalid comparisons. The main example are arrays of non-matching dimensions, and object arrays with invalid element-wise comparisons: In [1]: np.array([1,2,3]) == np.array([1,2]) Out[1]: False In [2]: np.array([1, np.array([2, 3])], dtype=object) == [1, 2] Out[2]: False This seems wrong to me, and I am sure not just me. I doubt any large projects makes use of such comparisons and assume that most would prefer the shape mismatch to raise an error, so I would like to change it. But I am a bit unsure especially about smaller projects. So to keep the transition a bit safer could imagine implementing a FutureWarning for these cases (and that would at least notify new users that what they are doing doesn't seem like the right thing). So the question is: Is such a change safe enough, or is there some good reason for the current behavior that I am missing? Regards, Sebastian (There may be other issues with structured types that would continue returning False I think, because neither side knows how to compare) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Allow == and != to raise errors
I can see where you are getting at, but I would have to disagree. First of all, when a comparison between two mis-shaped arrays occur, you get back a bone fide python boolean, not a numpy array of bools. So if any action was taken on the result of such a comparison assumed that the result was some sort of an array, it would fail (yes, this does make it a bit difficult to trace back the source of the problem, but not impossible). Second, no semantics are broken with this. Are the arrays equal or not? If they weren't broadcastible, then returning False for == and True for != makes perfect sense to me. At least, that is my take on it. Cheers! Ben Root On Fri, Jul 12, 2013 at 8:38 AM, Sebastian Berg sebast...@sipsolutions.netwrote: Hey, the array comparisons == and != never raise errors but instead simply return False for invalid comparisons. The main example are arrays of non-matching dimensions, and object arrays with invalid element-wise comparisons: In [1]: np.array([1,2,3]) == np.array([1,2]) Out[1]: False In [2]: np.array([1, np.array([2, 3])], dtype=object) == [1, 2] Out[2]: False This seems wrong to me, and I am sure not just me. I doubt any large projects makes use of such comparisons and assume that most would prefer the shape mismatch to raise an error, so I would like to change it. But I am a bit unsure especially about smaller projects. So to keep the transition a bit safer could imagine implementing a FutureWarning for these cases (and that would at least notify new users that what they are doing doesn't seem like the right thing). So the question is: Is such a change safe enough, or is there some good reason for the current behavior that I am missing? Regards, Sebastian (There may be other issues with structured types that would continue returning False I think, because neither side knows how to compare) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] f2py and setup.py how can I specify where the .so file goes?
Hi Scott, thanks for your help. On 12 July 2013 10:02, Scott Sinclair scott.sinclair...@gmail.com wrote: Something like the following should work... [...] Your suggestion works like what I already had. The issue is that the .so created by the Extension is copied to copying blah/blah/lib/python2.7/site-packages/ and not to blah/blah/lib/python2.7/site-packages/my_pack As it is, Python finds it with no problems (as site-packages is in the PYTHONPATH), but I'm worried that that might not be the case with all possible setups. But maybe that's the way it's suppossed to work. Thanks! Jose ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] read-only or immutable masked array
Hi, I use masked arrays to mark missing values in data and found it very convenient, although sometimes counterintuitive. I'd like to make a pool of masked arrays (shared between several processing steps) read-only (both data and mask property) to protect the arrays from accidental modification (and the array users from hours of debugging). The regular ndarray trick array.flags.writeable = False is perfectly fine, but it does not work on ma-s. Moreover, mask hardening only protects masked elements, and does not raise error (as I'd expect). Could you recommend an easy way to set an ma read-only? Thanks, Gregorio ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] read-only or immutable masked array
On Fri, Jul 12, 2013 at 4:41 PM, Gregorio Bastardo gregorio.basta...@gmail.com wrote: array.flags.writeable = False is perfectly fine, but it does not work on ma-s. Moreover, mask hardening only protects masked elements, and does not raise error (as I'd expect). You probably have to modify the underlying array and mask: x = np.ma.array(...) x.mask.flags.writeable = False x.data.flags.writeable = False Stéfan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] numpy.sign query
The docs for numpy.sign at http://docs.scipy.org/doc/numpy/reference/generated/numpy.sign.html do not indicate how complex numbers are handled. Currently, np.sign appears to return the sign of the real part as a complex value. Was this an explicit choice? Was x/abs(x) considered (for non-zero elements)? Thanks, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Allow == and != to raise errors
I also don't like that idea, but I'm not able to come to a good reasoning like Benjamin. I don't see advantage to this change and the reason isn't good enough to justify breaking the interface I think. But I don't think we rely on this, so if the change goes in, it probably won't break stuff or they will be easily seen and repared. Fred On Fri, Jul 12, 2013 at 9:13 AM, Benjamin Root ben.r...@ou.edu wrote: I can see where you are getting at, but I would have to disagree. First of all, when a comparison between two mis-shaped arrays occur, you get back a bone fide python boolean, not a numpy array of bools. So if any action was taken on the result of such a comparison assumed that the result was some sort of an array, it would fail (yes, this does make it a bit difficult to trace back the source of the problem, but not impossible). Second, no semantics are broken with this. Are the arrays equal or not? If they weren't broadcastible, then returning False for == and True for != makes perfect sense to me. At least, that is my take on it. Cheers! Ben Root On Fri, Jul 12, 2013 at 8:38 AM, Sebastian Berg sebast...@sipsolutions.net wrote: Hey, the array comparisons == and != never raise errors but instead simply return False for invalid comparisons. The main example are arrays of non-matching dimensions, and object arrays with invalid element-wise comparisons: In [1]: np.array([1,2,3]) == np.array([1,2]) Out[1]: False In [2]: np.array([1, np.array([2, 3])], dtype=object) == [1, 2] Out[2]: False This seems wrong to me, and I am sure not just me. I doubt any large projects makes use of such comparisons and assume that most would prefer the shape mismatch to raise an error, so I would like to change it. But I am a bit unsure especially about smaller projects. So to keep the transition a bit safer could imagine implementing a FutureWarning for these cases (and that would at least notify new users that what they are doing doesn't seem like the right thing). So the question is: Is such a change safe enough, or is there some good reason for the current behavior that I am missing? Regards, Sebastian (There may be other issues with structured types that would continue returning False I think, because neither side knows how to compare) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] new free software for knapsack problem
Hi all, FYI new free software for knapsack problem ( http://en.wikipedia.org/wiki/Knapsack_problem ) has been made (written in Python language); it can solve possibly constrained, possibly (with interalg ) nonlinear and multiobjective problems with specifiable accuracy. Along with interalg lots of MILP solvers can be used. See http://openopt.org/KSP for details. Regards, Dmitrey. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] flip array on axis
Am 10.07.2013 17:06, schrieb Matthew Brett: Hi, On Wed, Jul 10, 2013 at 11:02 AM, Andreas Hilboll li...@hilboll.de wrote: Hi, there are np.flipud and np.fliplr methods to flip 2d arrays on the first and second dimension, respectively. What can I do to flip an array on an axis which I don't know before runtime? I'd really like to see a np.flip(arr, axis) method which lets me specify which axis to flip on. I have something like that that's a few lines long: https://github.com/nipy/nibabel/blob/master/nibabel/orientations.py#L231 Cheers, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion Hi Matthew, is it okay with you as the original author in nipy if I copy the flip_axis function to numpy, more or less verbatim, including tests? Cheers, Andreas. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Allow == and != to raise errors
On Fri, Jul 12, 2013 at 3:35 PM, Frédéric Bastien no...@nouiz.org wrote: I also don't like that idea, but I'm not able to come to a good reasoning like Benjamin. I don't see advantage to this change and the reason isn't good enough to justify breaking the interface I think. But I don't think we rely on this, so if the change goes in, it probably won't break stuff or they will be easily seen and repared. Fred On Fri, Jul 12, 2013 at 9:13 AM, Benjamin Root ben.r...@ou.edu wrote: I can see where you are getting at, but I would have to disagree. First of all, when a comparison between two mis-shaped arrays occur, you get back a bone fide python boolean, not a numpy array of bools. So if any action was taken on the result of such a comparison assumed that the result was some sort of an array, it would fail (yes, this does make it a bit difficult to trace back the source of the problem, but not impossible). Second, no semantics are broken with this. Are the arrays equal or not? If they weren't broadcastible, then returning False for == and True for != makes perfect sense to me. At least, that is my take on it. Cheers! Ben Root On Fri, Jul 12, 2013 at 8:38 AM, Sebastian Berg sebast...@sipsolutions.net wrote: Hey, the array comparisons == and != never raise errors but instead simply return False for invalid comparisons. The main example are arrays of non-matching dimensions, and object arrays with invalid element-wise comparisons: In [1]: np.array([1,2,3]) == np.array([1,2]) Out[1]: False In [2]: np.array([1, np.array([2, 3])], dtype=object) == [1, 2] Out[2]: False This seems wrong to me, and I am sure not just me. I doubt any large projects makes use of such comparisons and assume that most would prefer the shape mismatch to raise an error, so I would like to change it. But I am a bit unsure especially about smaller projects. So to keep the transition a bit safer could imagine implementing a FutureWarning for these cases (and that would at least notify new users that what they are doing doesn't seem like the right thing). So the question is: Is such a change safe enough, or is there some good reason for the current behavior that I am missing? Regards, Sebastian (There may be other issues with structured types that would continue returning False I think, because neither side knows how to compare) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion I thought Benjamin sounds pretty convincing, and since I never use this, I don't care. However, I (and I'm pretty convinced all statsmodels code) uses equality comparison only element wise. Getting a boolean back is an indicator for a bug, which is most of the time easy to trace back. There is an inconsistency in the behavior with the inequalities. np.array([1,2,3]) np.array([1,2]) Traceback (most recent call last): File stdin, line 1, in module ValueError: shape mismatch: objects cannot be broadcast to a single shape np.array([1,2,3]) = np.array([1,2]) Traceback (most recent call last): File stdin, line 1, in module ValueError: shape mismatch: objects cannot be broadcast to a single shape (np.array([1,2,3]) == np.array([1,2])).any() Traceback (most recent call last): File stdin, line 1, in module AttributeError: 'bool' object has no attribute 'any' The last one could be misleading and difficult to catch. np.any(np.array([1,2,3]) == np.array([1,2])) False numpy 1.5.1 since I'm playing rear guard Josef Josef ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.sign query
On Fri, Jul 12, 2013 at 12:53 PM, Alan G Isaac alan.is...@gmail.com wrote: The docs for numpy.sign at http://docs.scipy.org/doc/numpy/reference/generated/numpy.sign.html do not indicate how complex numbers are handled. Currently, np.sign appears to return the sign of the real part as a complex value. Was this an explicit choice? Was x/abs(x) considered (for non-zero elements)? ISTR some discussion of that. Personally, I like the x/abs(x) idea. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] nansum, nanmean, nanvar, nanstd
Hi All, I've been working on Benjamin's PR, which I took down as he didn't have time to finish it. I've made the following changes and thought I'd run them past others before putting up a new pull request. 1. The new functions are consolidated with the old ones inn (new) numpy/lib/nanfunctions.py. 2. There is a new test module numpy/lib/tests/test_nanfunctions.py 3. The functions punt to standard routines if the array is not inexact. 4. If the array is inexact, then so must be the optional out and dtype arguments. 5. Nans are returned for all nan axis, no warnings are raised. 6. If cnt - ddof = 0 the result is Nan for that axis, no warnings are raised. 7. For scalar returns the type of the array, or the type given by the dtype option, is preserved. Number 7 does not hold for current mean, var, and std. I propose that those functions be fixed. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] PIL and NumPy
NumPy Folks,
I want to load images with PIL and then operate on them with NumPy.
According to the PIL and NumPy documentation, I would expect the
following to work, but it is not.
Python 2.7.4 (default, Apr 19 2013, 18:28:01)
[GCC 4.7.3] on linux2
Type help, copyright, credits or license for more information.
import numpy
numpy.version.version
import Image
Image.VERSION
'1.1.7'
im = Image.open('big-0.png')
im.size
(2550, 3300)
ar = numpy.asarray(im)
ar.size
1
ar.shape
()
ar
array(PIL.PngImagePlugin.PngImageFile image mode=LA size=2550x3300 at
0x1E5BA70, dtype=object)
By not working I mean that I would have expected the data to be
loaded/available in ar. PIL and NumPy/SciPy seem to be working fine
independently of each other. Any guidance?
Brady
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] PIL and NumPy
NumPy Folks,
Sorry for the self-reply, but I have determined that this may have
something to do with an alpha channel being present. When I remove the
alpha channel, things appear to work as I expect. Any discussion on
the matter?
Brady
On Fri, Jul 12, 2013 at 10:00 PM, Brady McCary brady.mcc...@gmail.com wrote:
NumPy Folks,
I want to load images with PIL and then operate on them with NumPy.
According to the PIL and NumPy documentation, I would expect the
following to work, but it is not.
Python 2.7.4 (default, Apr 19 2013, 18:28:01)
[GCC 4.7.3] on linux2
Type help, copyright, credits or license for more information.
import numpy
numpy.version.version
import Image
Image.VERSION
'1.1.7'
im = Image.open('big-0.png')
im.size
(2550, 3300)
ar = numpy.asarray(im)
ar.size
1
ar.shape
()
ar
array(PIL.PngImagePlugin.PngImageFile image mode=LA size=2550x3300 at
0x1E5BA70, dtype=object)
By not working I mean that I would have expected the data to be
loaded/available in ar. PIL and NumPy/SciPy seem to be working fine
independently of each other. Any guidance?
Brady
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
