[Numpy-discussion] return index of maximum value in an array easily?
Dear all, Are we going to consider returning the index of maximum value in an array easily without calling np.argmax and np.unravel_index consecutively? I saw few posts in mailing archive and stackover flow on this, when I tried to return the index of maximum value of 2d array. It seems that I am not the first to be confused by this. http://stackoverflow.com/questions/11377028/getting-index-of-numpy-ndarray http://old.nabble.com/maximum-value-and-corresponding-index-td24834930.html http://stackoverflow.com/questions/5469286/how-to-get-the-index-of-a-maximum-element-in-a-numpy-array http://stackoverflow.com/questions/4150542/determine-index-of-highest-value-in-pythons-numpy cheers, Chao -- *** Chao YUE Laboratoire des Sciences du Climat et de l'Environnement (LSCE-IPSL) UMR 1572 CEA-CNRS-UVSQ Batiment 712 - Pe 119 91191 GIF Sur YVETTE Cedex Tel: (33) 01 69 08 29 02; Fax:01.69.08.77.16 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] return index of maximum value in an array easily?
Hi Chao, in two dimensions the following works very well: In [97]: a = np.random.randn(5,7) In [98]: a[divmod(a.argmax(), a.shape[1])] Out[98]: 1.3680204597100922 In [99]: a.max() Out[99]: 1.3680204597100922 In [100]: In [100]: b = a[divmod(a.argmax(), a.shape[1])] In [101]: b==a.max() Out[101]: True Cheers, Hanno On 10.01.2013 10:40, Chao YUE wrote: Dear all, Are we going to consider returning the index of maximum value in an array easily without calling np.argmax and np.unravel_index consecutively? I saw few posts in mailing archive and stackover flow on this, when I tried to return the index of maximum value of 2d array. It seems that I am not the first to be confused by this. http://stackoverflow.com/questions/11377028/getting-index-of-numpy-ndarray [1] http://old.nabble.com/maximum-value-and-corresponding-index-td24834930.html [2] http://stackoverflow.com/questions/5469286/how-to-get-the-index-of-a-maximum-element-in-a-numpy-array [3] http://stackoverflow.com/questions/4150542/determine-index-of-highest-value-in-pythons-numpy [4] cheers, Chao -- *** Chao YUE Laboratoire des Sciences du Climat et de l'Environnement (LSCE-IPSL) UMR 1572 CEA-CNRS-UVSQ Batiment 712 - Pe 119 91191 GIF Sur YVETTE Cedex Tel: (33) 01 69 08 29 02; Fax:01.69.08.77.16 Links: -- [1] http://stackoverflow.com/questions/11377028/getting-index-of-numpy-ndarray [2] http://old.nabble.com/maximum-value-and-corresponding-index-td24834930.html [3] http://stackoverflow.com/questions/5469286/how-to-get-the-index-of-a-maximum-element-in-a-numpy-array [4] http://stackoverflow.com/questions/4150542/determine-index-of-highest-value-in-pythons-numpy ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion -- Hanno Klemm kl...@phys.ethz.ch ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] int and long issues
Hi, I find this to be a little strange: x = numpy.arange(10) isinstance(x[0],int) gives True y = numpy.where(x 5)[0] isinstance(y[0],int) gives False isinstance(y[0],long) gives True Specs: Python 2.7.2, numpy-1.6.1, Win7, 64 bit Best regards, Mads -- +-+ | Mads Ipsen | +--+--+ | Gåsebæksvej 7, 4. tv | | | DK-2500 Valby| phone: +45-29716388 | | Denmark | email: mads.ip...@gmail.com | +--+--+ ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: first previews of WinPython for Python 3 32/64bit
Pierre Raybaut pierre.raybaut at gmail.com writes: Hi all, I'm pleased to announce that the first previews of WinPython for Python 3 32bit and 64bit are available (WinPython v3.3.0.0alpha1): http://code.google.com/p/winpython/ This first release based on Python 3 required to migrate the following libraries which were only available for Python 2: * formlayout 1.0.12 * guidata 1.6.0dev1 * guiqwt 2.3.0dev1 * Spyder 2.1.14dev Please note that these libraries are still development release. [Special thanks to Christoph Gohlke for patching and building a version of PyQwt compatible with Python 3.3] Hey Pierre, i just want to say thanks for your work. I use spyder, winpython (no more hassle with administration) and guiqwt (fastest plotting library under pyqt) daily and love them. greetings Till ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] int and long issues
On Thu, 2013-01-10 at 11:32 +0100, Mads Ipsen wrote: Hi, I find this to be a little strange: x = numpy.arange(10) isinstance(x[0],int) gives True y = numpy.where(x 5)[0] isinstance(y[0],int) gives False isinstance(y[0],long) Check what type(x[0])/type(y[0]) prints, I expect these are very different, because the default integer type and the integer type used for indexing (addressing memory in general) are not necessarily the same. And because of that, `y[0]` probably simply isn't compatible to the datatype of a python integer for your hardware and OS (for example for me, your code works). So on python 2 (python 3 abolishes int and makes long the only integer, so this should work as expected there) you have to just check both even in the python context, because you can never really know (there may be some nice trick for that, but not sure). And if you want to allow for rare 0d arrays as well (well they are very rare admittingly)... it gets even a bit hairier. gives True Specs: Python 2.7.2, numpy-1.6.1, Win7, 64 bit Best regards, Mads -- +-+ | Mads Ipsen | +--+--+ | Gåsebæksvej 7, 4. tv | | | DK-2500 Valby| phone: +45-29716388 | | Denmark | email: mads.ip...@gmail.com | +--+--+ ___ 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] int and long issues
On Thu, 2013-01-10 at 11:32 +0100, Mads Ipsen wrote: Hi, I find this to be a little strange: x = numpy.arange(10) isinstance(x[0],int) gives True y = numpy.where(x 5)[0] isinstance(y[0],int) gives False isinstance(y[0],long) Check what type(x[0])/type(y[0]) prints, I expect these are very different, because the default integer type and the integer type used for indexing (addressing memory in general) are not necessarily the same. And because of that, `y[0]` probably simply isn't compatible to the datatype of a python integer for your hardware and OS (for example for me, your code works). So on python 2 (python 3 abolishes int and makes long the only integer, so this should work as expected there) you have to just check both even in the python context, because you can never really know (there may be some nice trick for that, but not sure). And if you want to allow for rare 0d arrays as well (well they are very rare admittingly)... it gets even a bit hairier. Regards, Sebastian gives True Specs: Python 2.7.2, numpy-1.6.1, Win7, 64 bit Best regards, Mads -- +-+ | Mads Ipsen | +--+--+ | Gåsebæksvej 7, 4. tv | | | DK-2500 Valby| phone: +45-29716388 | | Denmark | email: mads.ip...@gmail.com | +--+--+ ___ 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] Linear least squares
QR without column pivoting is a nice option for safe problems, but it doesn't provide a reliable indication of rank reduction. I also don't find pinv useful once the rank goes down, since it relies on Euclidean distance having relevance in parameter space and that is seldom a sound assumption, usually it is better to reformulate the problem or remove a column from the design matrix. Oh, i always taught that lstsq is more or less using the same procedure as pinv. Maybe you can give me a hint which algorithm is the most stable, as system (sum of expontials) is not very stable? My numerical lectures were some year ago. greetings Till ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] int and long issues
Sebastian - thanks - very helpful. Best regards, Mads On 10/01/2013 12:06, Sebastian Berg wrote: On Thu, 2013-01-10 at 11:32 +0100, Mads Ipsen wrote: Hi, I find this to be a little strange: x = numpy.arange(10) isinstance(x[0],int) gives True y = numpy.where(x 5)[0] isinstance(y[0],int) gives False isinstance(y[0],long) Check what type(x[0])/type(y[0]) prints, I expect these are very different, because the default integer type and the integer type used for indexing (addressing memory in general) are not necessarily the same. And because of that, `y[0]` probably simply isn't compatible to the datatype of a python integer for your hardware and OS (for example for me, your code works). So on python 2 (python 3 abolishes int and makes long the only integer, so this should work as expected there) you have to just check both even in the python context, because you can never really know (there may be some nice trick for that, but not sure). And if you want to allow for rare 0d arrays as well (well they are very rare admittingly)... it gets even a bit hairier. gives True Specs: Python 2.7.2, numpy-1.6.1, Win7, 64 bit Best regards, Mads -- +-+ | Mads Ipsen | +--+--+ | Gåsebæksvej 7, 4. tv | | | DK-2500 Valby| phone: +45-29716388 | | Denmark | email: mads.ip...@gmail.com | +--+--+ ___ 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 -- +-+ | Mads Ipsen | +--+--+ | Gåsebæksvej 7, 4. tv | | | DK-2500 Valby| phone: +45-29716388 | | Denmark | email: mads.ip...@gmail.com | +--+--+ ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpydoc for python 3?
Hi, Jaakko Luttinen jaakko.luttinen at aalto.fi writes: I'm trying to use numpydoc (Sphinx extension) for my project written in Python 3.2. However, installing numpydoc gives errors shown at http://pastebin.com/MPED6v9G and although it says Successfully installed numpydoc, trying to import numpydoc raises errors.. Could this be fixed or am I doing something wrong? Numpydoc hasn't been ported to Python 3 so far. This probably wouldn't a very large amount of work --- patches are accepted! -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Remove support for numeric and numarray in 1.8
Hi, Just to note, as they plan to remove there dependency on it this year, is it bad that they can't use 1.8 for a few mounts until they finish the conversion? They already have a working version. They can continue to use it for as long they want. The only advantage for them if the compat layers are kept is the abbility for them to use the new numpy 1.8 a few monts earlier. I don't know enough about this issue, but from Nathaniel description, the consequence of dropping it in 1.8 seam light compared to the potential problem in my view. But the question is, how many other group are in there situation? Can we make a big warning printed when we compile again those compatibility layer to make it clear they will get removed? (probably it is already like that) my 2 cents Fred On Wed, Jan 9, 2013 at 6:41 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Wed, Jan 9, 2013 at 4:21 PM, Christopher Hanley chan...@gmail.com wrote: After poking around our code base and talking to a few folks I predict that we at STScI can remove our dependence on the numpy-numarray compatibility layer by the end of this calendar year. I'm unsure of what the timeline for numpy 1.8 is so I don't know if this schedule supports removal of the compatibility layer from 1.8 or not. Together with the previous post that puts the kibosh on removing either numeric or numarray support from 1.8, at least if we get 1.8 before the end of summer. It's good to know where folks stand with regard to those packages, we'll give it another shot next year. Chuck ___ 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] numpydoc for python 3?
The files in numpy/doc/sphinxext/ and numpydoc/ (from PyPI) are a bit different. Which ones should be modified? -Jaakko On 01/10/2013 02:04 PM, Pauli Virtanen wrote: Hi, Jaakko Luttinen jaakko.luttinen at aalto.fi writes: I'm trying to use numpydoc (Sphinx extension) for my project written in Python 3.2. However, installing numpydoc gives errors shown at http://pastebin.com/MPED6v9G and although it says Successfully installed numpydoc, trying to import numpydoc raises errors.. Could this be fixed or am I doing something wrong? Numpydoc hasn't been ported to Python 3 so far. This probably wouldn't a very large amount of work --- patches are accepted! ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpydoc for python 3?
Jaakko Luttinen jaakko.luttinen at aalto.fi writes: The files in numpy/doc/sphinxext/ and numpydoc/ (from PyPI) are a bit different. Which ones should be modified? The stuff in sphinxext/ is the development version of the package on PyPi, so the changes should be made in sphinxext/ -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpydoc for python 3?
On 01/10/2013 05:04 PM, Pauli Virtanen wrote: Jaakko Luttinen jaakko.luttinen at aalto.fi writes: The files in numpy/doc/sphinxext/ and numpydoc/ (from PyPI) are a bit different. Which ones should be modified? The stuff in sphinxext/ is the development version of the package on PyPi, so the changes should be made in sphinxext/ Thanks! I'm trying to run the tests with Python 2 using nosetests, but I get some errors http://pastebin.com/Mp9i8T2f . Am I doing something wrong? How should I run the tests? If I run nosetests on the numpydoc folder from PyPI, all the tests are successful. -Jaakko ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Building Numpy 1.6.2 for Python 3.3 on Windows
Hi,
I run `python3 setup.py config` and then
python3 setup.py build --compiler=mingw32
but it picks that I have MSVC 10 and complains about manifests.
Why, or even better, how to compile with available MinGW compilers?
Here is log:
C:\src\numpy-1.6.2python3 setup.py --compiler=mingw32
Converting to Python3 via 2to3...
Running from numpy source directory.usage: setup.py [global_opts] cmd1
[cmd1_opts] [cmd2 [cmd2_opts] ...]
or: setup.py --help [cmd1 cmd2 ...]
or: setup.py --help-commands
or: setup.py cmd --help
error: option --compiler not recognized
C:\src\numpy-1.6.2python3 setup.py build --compiler=mingw32
Converting to Python3 via 2to3...
F2PY Version 2
blas_opt_info:
blas_mkl_info:
FOUND:
libraries = ['mkl_rt']
library_dirs = ['C:/Progra~1/Intel/Compos~1/mkl/lib/ia32']
include_dirs = ['C:/Progra~1/Intel/Compos~1/mkl/include']
define_macros = [('SCIPY_MKL_H', None)]
FOUND:
libraries = ['mkl_rt']
library_dirs = ['C:/Progra~1/Intel/Compos~1/mkl/lib/ia32']
include_dirs = ['C:/Progra~1/Intel/Compos~1/mkl/include']
define_macros = [('SCIPY_MKL_H', None)]
non-existing path in 'numpy\\lib': 'benchmarks'
lapack_opt_info:
lapack_mkl_info:
mkl_info:
FOUND:
libraries = ['mkl_rt']
library_dirs = ['C:/Progra~1/Intel/Compos~1/mkl/lib/ia32']
include_dirs = ['C:/Progra~1/Intel/Compos~1/mkl/include']
define_macros = [('SCIPY_MKL_H', None)]
FOUND:
libraries = ['mkl_rt']
library_dirs = ['C:/Progra~1/Intel/Compos~1/mkl/lib/ia32']
include_dirs = ['C:/Progra~1/Intel/Compos~1/mkl/include']
define_macros = [('SCIPY_MKL_H', None)]
FOUND:
libraries = ['mkl_rt']
library_dirs = ['C:/Progra~1/Intel/Compos~1/mkl/lib/ia32']
include_dirs = ['C:/Progra~1/Intel/Compos~1/mkl/include']
define_macros = [('SCIPY_MKL_H', None)]
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
building library npymath sources
customize GnuFCompiler
Could not locate executable g77
Could not locate executable f77
customize IntelVisualFCompiler
Could not locate executable ifort
Could not locate executable ifl
customize AbsoftFCompiler
Could not locate executable f90
customize CompaqVisualFCompiler
Could not locate executable DF
customize IntelItaniumVisualFCompiler
Could not locate executable efl
customize Gnu95FCompiler
Found executable C:\MinGW\bin\gfortran.exe
Found executable C:\MinGW\bin\gfortran.exe
Running from numpy source directory.customize Gnu95FCompiler
customize Gnu95FCompiler using config
Traceback (most recent call last):
File C:\src\numpy-1.6.2\build\py3k\numpy\distutils\mingw32ccompiler.py,
line 399, in msvc_manifest_xml
fullver = _MSVCRVER_TO_FULLVER[str(maj * 10 + min)]
KeyError: '100'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File setup.py, line 214, in module
setup_package()
File setup.py, line 207, in setup_package
configuration=configuration )
File C:\src\numpy-1.6.2\build\py3k\numpy\distutils\core.py, line 186, in
setup
return old_setup(**new_attr)
File c:\python33\lib\distutils\core.py, line 148, in setup
dist.run_commands()
File c:\python33\lib\distutils\dist.py, line 917, in run_commands
self.run_command(cmd)
File c:\python33\lib\distutils\dist.py, line 936, in run_command
cmd_obj.run()
File C:\src\numpy-1.6.2\build\py3k\numpy\distutils\command\build.py, line
37, in run
old_build.run(self)
File c:\python33\lib\distutils\command\build.py, line 126, in run
self.run_command(cmd_name)
File c:\python33\lib\distutils\cmd.py, line 313, in run_command
self.distribution.run_command(command)
File c:\python33\lib\distutils\dist.py, line 936, in run_command
cmd_obj.run()
File C:\src\numpy-1.6.2\build\py3k\numpy\distutils\command\build_src.py,
line 152, in run
self.build_sources()
File C:\src\numpy-1.6.2\build\py3k\numpy\distutils\command\build_src.py,
line 163, in build_sources
self.build_library_sources(*libname_info)
File C:\src\numpy-1.6.2\build\py3k\numpy\distutils\command\build_src.py,
line 298, in build_library_sources
sources = self.generate_sources(sources, (lib_name, build_info))
File C:\src\numpy-1.6.2\build\py3k\numpy\distutils\command\build_src.py,
line 385, in generate_sources
source = func(extension, build_dir)
File numpy\core\setup.py, line 694, in get_mathlib_info
st = config_cmd.try_link('int main(void) { return 0;}')
File c:\python33\lib\distutils\command\config.py, line 246, in try_link
libraries, library_dirs, lang)
File C:\src\numpy-1.6.2\build\py3k\numpy\distutils\command\config.py, line
146, in _link
generate_manifest(self)
File
Re: [Numpy-discussion] Remove support for numeric and numarray in 1.8
I'm all for a big scary warning on import. Fair warning is good for everyone, not just our developers. As for testing, our software that uses the API is tested nightly. So if our software stops working, and the compatibility layer is the cause, we would definitely be looking into what happened. :-) In any case, fair warning of dropped support in 1.8 and removal in 1.9 is fine with us. Thanks, Chris On Wed, Jan 9, 2013 at 6:38 PM, Nathaniel Smith n...@pobox.com wrote: On Wed, Jan 9, 2013 at 11:21 PM, Christopher Hanley chan...@gmail.com wrote: After poking around our code base and talking to a few folks I predict that we at STScI can remove our dependence on the numpy-numarray compatibility layer by the end of this calendar year. I'm unsure of what the timeline for numpy 1.8 is so I don't know if this schedule supports removal of the compatibility layer from 1.8 or not. It'd be nice if 1.8 were out before that, but that doesn't really matter -- let us know when you get it sorted? Also, would it help if we added a big scary warning at import time to annoy your more recalcitrant developers with? :-) The basic issue is that none of us actually use this stuff, it has no tests, the rest of numpy is changing around it, and we have no idea if it works, so at some point it makes more sense for us to just stop shipping the compat layer and let anyone who still needs it maintain their own copy of the code. -n ___ 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] Building Numpy 1.6.2 for Python 3.3 on Windows
On Thu, Jan 10, 2013 at 3:56 PM, klo klo...@gmail.com wrote: Hi, I run `python3 setup.py config` and then python3 setup.py build --compiler=mingw32 but it picks that I have MSVC 10 and complains about manifests. Why, or even better, how to compile with available MinGW compilers? I reported this issue/bug to the mailing list recently as part of a discussion with Ralf which lead to various fixes being made to get NumPy to compile with either mingw32 or MSCV 10. http://mail.scipy.org/pipermail/numpy-discussion/2012-November/064454.html My workaround is to change the default compiler for Python 3, by creating C:\Python33\Lib\distutils\distutils.cfg containing: [build] compiler=mingw32 Peter ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Remove support for numeric and numarray in 1.8
based on our situation On 10/01/2013 9:02 AM, Christopher Hanley wrote: I'm all for a big scary warning on import. Fair warning is good for everyone, not just our developers. agree As for testing, our software that uses the API is tested nightly. So if our software stops working, and the compatibility layer is the cause, we would definitely be looking into what happened. :-) same (but not necesairlly with the very latest numpy) . In any case, fair warning of dropped support in 1.8 and removal in 1.9 is fine with us. not sure. It all depends on the timing. I'd prefer to revisit the topic once 1.8 is actually going to come out. Raul Thanks, Chris On Wed, Jan 9, 2013 at 6:38 PM, Nathaniel Smith n...@pobox.com wrote: On Wed, Jan 9, 2013 at 11:21 PM, Christopher Hanley chan...@gmail.com wrote: After poking around our code base and talking to a few folks I predict that we at STScI can remove our dependence on the numpy-numarray compatibility layer by the end of this calendar year. I'm unsure of what the timeline for numpy 1.8 is so I don't know if this schedule supports removal of the compatibility layer from 1.8 or not. It'd be nice if 1.8 were out before that, but that doesn't really matter -- let us know when you get it sorted? Also, would it help if we added a big scary warning at import time to annoy your more recalcitrant developers with? :-) The basic issue is that none of us actually use this stuff, it has no tests, the rest of numpy is changing around it, and we have no idea if it works, so at some point it makes more sense for us to just stop shipping the compat layer and let anyone who still needs it maintain their own copy of the code. -n ___ 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
Re: [Numpy-discussion] Building Numpy 1.6.2 for Python 3.3 on Windows
I reported this issue/bug to the mailing list recently as part of a discussion with Ralf which lead to various fixes being made to get NumPy to compile with either mingw32 or MSCV 10. http://mail.scipy.org/pipermail/numpy-discussion/2012-November/064454.html My workaround is to change the default compiler for Python 3, by creating C:\Python33\Lib\distutils\distutils.cfg containing: [build] compiler=mingw32 Thanks, but I have already set C:\Python33\Lib\distutils\distutils.cfg: [build] compiler=mingw32 [build_ext] compiler=mingw32 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Building Numpy 1.6.2 for Python 3.3 on Windows
On 1/10/2013 8:35 AM, klo wrote: I reported this issue/bug to the mailing list recently as part of a discussion with Ralf which lead to various fixes being made to get NumPy to compile with either mingw32 or MSCV 10. http://mail.scipy.org/pipermail/numpy-discussion/2012-November/064454.html My workaround is to change the default compiler for Python 3, by creating C:\Python33\Lib\distutils\distutils.cfg containing: [build] compiler=mingw32 Thanks, but I have already set C:\Python33\Lib\distutils\distutils.cfg: [build] compiler=mingw32 [build_ext] compiler=mingw32 Numpy = 1.6 is not compatible with Python 3.3. Use numpy = 1.7.0rc1. Christoph ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Which Python to use for Mac binaries
Ondřej, Vincent, and Ralf (and others..) Thank you so much for doing all this -- it's a great service to the MacPython community. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Building Numpy 1.6.2 for Python 3.3 on Windows
Numpy = 1.6 is not compatible with Python 3.3. Use numpy = 1.7.0rc1. Thanks for the tip 1.7.0rc builds without issue ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Building Numpy 1.6.2 for Python 3.3 on Windows
Numpy = 1.6 is not compatible with Python 3.3. Use numpy = 1.7.0rc1.
Thanks for the tip
1.7.0rc builds without issue
Actually, this isn't over. It builds fine, but when I try to import
numpy I get error:
...
from numpy.linalg import lapack_lite
ImportError: DLL load failed: The specified module could not be found.
Google reveals that PATH has to be updated with C:\Python33\Scripts
path, but then when I run `python3 setup.py build` I get another
error:
C:\src\numpy-1.7.0rc1python3 setup.py build
Converting to Python3 via 2to3...
Running from numpy source directory.
F2PY Version 2
blas_opt_info:
blas_mkl_info:
FOUND:
define_macros = [('SCIPY_MKL_H', None)]
libraries = ['mkl_rt']
include_dirs = ['C:/Progra~1/Intel/Compos~1/mkl/include']
library_dirs = ['C:/Progra~1/Intel/Compos~1/mkl/lib/ia32']
FOUND:
define_macros = [('SCIPY_MKL_H', None)]
libraries = ['mkl_rt']
include_dirs = ['C:/Progra~1/Intel/Compos~1/mkl/include']
library_dirs = ['C:/Progra~1/Intel/Compos~1/mkl/lib/ia32']
non-existing path in 'numpy\\lib': 'benchmarks'
lapack_opt_info:
lapack_mkl_info:
mkl_info:
FOUND:
define_macros = [('SCIPY_MKL_H', None)]
libraries = ['mkl_rt']
include_dirs = ['C:/Progra~1/Intel/Compos~1/mkl/include']
library_dirs = ['C:/Progra~1/Intel/Compos~1/mkl/lib/ia32']
FOUND:
define_macros = [('SCIPY_MKL_H', None)]
libraries = ['mkl_rt']
include_dirs = ['C:/Progra~1/Intel/Compos~1/mkl/include']
library_dirs = ['C:/Progra~1/Intel/Compos~1/mkl/lib/ia32']
FOUND:
define_macros = [('SCIPY_MKL_H', None)]
libraries = ['mkl_rt']
include_dirs = ['C:/Progra~1/Intel/Compos~1/mkl/include']
library_dirs = ['C:/Progra~1/Intel/Compos~1/mkl/lib/ia32']
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.win32-3.3
creating build\src.win32-3.3\numpy
creating build\src.win32-3.3\numpy\distutils
building library npymath sources
Building import library (ARCH=x86): c:\python33\libs\libpython33.a
Traceback (most recent call last):
File setup.py, line 214, in module
setup_package()
File setup.py, line 207, in setup_package
configuration=configuration )
File C:\src\numpy-1.7.0rc1\build\py3k\numpy\distutils\core.py, line 186, in
setup
return old_setup(**new_attr)
File c:\python33\lib\distutils\core.py, line 148, in setup
dist.run_commands()
File c:\python33\lib\distutils\dist.py, line 917, in run_commands
self.run_command(cmd)
File c:\python33\lib\distutils\dist.py, line 936, in run_command
cmd_obj.run()
File C:\src\numpy-1.7.0rc1\build\py3k\numpy\distutils\command\build.py,
line 37, in run
old_build.run(self)
File c:\python33\lib\distutils\command\build.py, line 126, in run
self.run_command(cmd_name)
File c:\python33\lib\distutils\cmd.py, line 313, in run_command
self.distribution.run_command(command)
File c:\python33\lib\distutils\dist.py, line 936, in run_command
cmd_obj.run()
File C:\src\numpy-1.7.0rc1\build\py3k\numpy\distutils\command\build_src.py,
line 152, in run
self.build_sources()
File C:\src\numpy-1.7.0rc1\build\py3k\numpy\distutils\command\build_src.py,
line 163, in build_sources
self.build_library_sources(*libname_info)
File C:\src\numpy-1.7.0rc1\build\py3k\numpy\distutils\command\build_src.py,
line 298, in build_library_sources
sources = self.generate_sources(sources, (lib_name, build_info))
File C:\src\numpy-1.7.0rc1\build\py3k\numpy\distutils\command\build_src.py,
line 385, in generate_sources
source = func(extension, build_dir)
File numpy\core\setup.py, line 646, in get_mathlib_info
st = config_cmd.try_link('int main(void) { return 0;}')
File c:\python33\lib\distutils\command\config.py, line 243, in try_link
self._check_compiler()
File C:\src\numpy-1.7.0rc1\build\py3k\numpy\distutils\command\config.py,
line 45, in _check_compiler
old_config._check_compiler(self)
File c:\python33\lib\distutils\command\config.py, line 98, in
_check_compiler
dry_run=self.dry_run, force=1)
File C:\src\numpy-1.7.0rc1\build\py3k\numpy\distutils\ccompiler.py, line
560, in new_compiler
compiler = klass(None, dry_run, force)
File C:\src\numpy-1.7.0rc1\build\py3k\numpy\distutils\mingw32ccompiler.py,
line 91, in __init__
build_import_library()
File C:\src\numpy-1.7.0rc1\build\py3k\numpy\distutils\mingw32ccompiler.py,
line 383, in build_import_library
return _build_import_library_x86()
File C:\src\numpy-1.7.0rc1\build\py3k\numpy\distutils\mingw32ccompiler.py,
line 428, in _build_import_library_x86
dlist, flist = lib2def.parse_nm(nm_output)
Re: [Numpy-discussion] Building Numpy 1.6.2 for Python 3.3 on Windows
Actually, this isn't over. It builds fine, but when I try to import numpy I get error: ... Sorry for the noise, after re-reading tracelog, I realized that I accidentally removed c:\python33\libs\libpython33.a while removing previous non-working numpy build Cheers ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Which Python to use for Mac binaries
On Wed, Jan 9, 2013 at 11:21 PM, Ralf Gommers ralf.gomm...@gmail.com wrote: Sure, no problem. For the part that needs to be built on 10.6 that is. Vincent's box still has 10.5, right? Yes. Ondrej ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Which Python to use for Mac binaries
On Thu, Jan 10, 2013 at 9:26 AM, Chris Barker - NOAA Federal chris.bar...@noaa.gov wrote: Ondřej, Vincent, and Ralf (and others..) Thank you so much for doing all this -- it's a great service to the MacPython community. Chris, thank you for your help as well! Ondrej ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Building Numpy 1.6.2 for Python 3.3 on Windows
On Thu, Jan 10, 2013 at 12:20 PM, klo klo...@gmail.com wrote: Actually, this isn't over. It builds fine, but when I try to import numpy I get error: ... Sorry for the noise, after re-reading tracelog, I realized that I accidentally removed c:\python33\libs\libpython33.a while removing previous non-working numpy build Cool, I am glad to hear that 1.7.0rc1 works great. Thanks for letting us know. Ondrej ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
