Re: [Numpy-discussion] float96 on windows32 is float64?
I just did a quick test across all supported EPD platforms: win-64: float96 No, float128 No win-32: float96 No, float128 No osx-64: float96 No, float128 Yes osx-32: float96 No, float128 Yes rh3-64: float96 No, float128 Yes rh3-32: float96 Yes, float128 No rh5-64: float96 No, float128 Yes rh5-32: float96 Yes, float128 No sol-64: float96 No, float128 Yes sol-32: float96 Yes, float128 No I have no explanation for this, but I'm guessing David C. has. I'll look more into this tomorrow. - Ilan On Fri, Mar 16, 2012 at 12:40 AM, Matthew Brett matthew.br...@gmail.com wrote: Hi, On Thu, Mar 15, 2012 at 10:26 PM, Ilan Schnell ischn...@enthought.com wrote: To be more precise. On both 32-bit and 64-bit Windows machines I don't see.float96 as well as np.float128 Do you have any idea why I am seeing float96 and you are not? I'm on XP with the current sourceforge 1.6.1 exe installer with python.org 2.7 (and same for python.org 2.6 and numpy 1.5.1). Thanks, Matthew ___ 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] Minus zero
Here's an array a = [[ -2.66453526e-15, 4.49564793e-02, 1.14401980e+00], [ 2.02475000e+00, 2.06970648e+00, 1.14401980e+00], [ 2.02475000e+00, 4.49564793e-02, 3.16876980e+00], [ -2.66453526e-15, 2.06970648e+00, 3.16876980e+00], [ -2.66453526e-15, 4.49564793e-02, 5.19351980e+00], [ 2.02475000e+00, 2.06970648e+00, 5.19351980e+00], [ 2.02475000e+00, 4.49564793e-02, 7.21826980e+00], [ 0.e+00, 2.02475000e+00, 7.08662500e+00]] Now, call array_repr(a, precision=12, suppress_small=True) which gives the output array([[-0. , 0.0449564793, 1.1440198 ], [ 2.02475 , 2.06970648 , 1.1440198 ], [ 2.02475 , 0.0449564793, 3.1687698 ], [-0. , 2.06970648 , 3.1687698 ], [-0. , 0.0449564793, 5.1935198 ], [ 2.02475 , 2.06970648 , 5.1935198 ], [ 2.02475 , 0.0449564793, 7.2182698 ], [ 0. , 2.02475 , 7.086625]]) * Since the flag 'suppress_small=True' is used, I'd expect a '0.' instead of a '-0.' or maybe this is intentional. * Also, wouldn't '0.0' instead of '0.' be more readable (and there's certainly space enough to add it)? 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] Commit PR 229 breaks build
On Fri, Mar 16, 2012 at 1:44 AM, Ralf Gommers
ralf.gomm...@googlemail.comwrote:
On Fri, Mar 16, 2012 at 12:45 AM, Charles R Harris
charlesr.har...@gmail.com wrote:
On my machines anyway.
Running from numpy source directory.
non-existing path in 'numpy/distutils': 'site.cfg'
F2PY Version 2
numpy/core/setup_common.py:86: MismatchCAPIWarning: API mismatch
detected, the C API version numbers have to be updated. Current C api
version is 6, with checksum eb54c77ff4149bab310324cd7c0cb176, but recorded
checksum for C API version 6 in codegen_dir/cversions.txt is
e61d5dc51fa1c6459328266e215d6987. If functions were added in the C API, you
have to update C_API_VERSION in numpy/core/setup_common.pyc.
MismatchCAPIWarning)
blas_opt_info:
blas_mkl_info:
libraries mkl,vml,guide not found in ['/usr/local/lib64',
'/usr/local/lib', '/usr/lib64', '/usr/lib']
NOT AVAILABLE
atlas_blas_threads_info:
Setting PTATLAS=ATLAS
Setting PTATLAS=ATLAS
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 /home/charris/Workspace/numpy.git/numpy/distutils/core.py, line
152, in setup
config = configuration()
File setup.py, line 147, in configuration
config.add_subpackage('numpy')
File /home/charris/Workspace/numpy.git/numpy/distutils/misc_util.py,
line 1002, in add_subpackage
caller_level = 2)
File /home/charris/Workspace/numpy.git/numpy/distutils/misc_util.py,
line 971, in get_subpackage
caller_level = caller_level + 1)
File /home/charris/Workspace/numpy.git/numpy/distutils/misc_util.py,
line 908, in _get_configuration_from_setup_py
config = setup_module.configuration(*args)
File numpy/setup.py, line 9, in configuration
config.add_subpackage('core')
File /home/charris/Workspace/numpy.git/numpy/distutils/misc_util.py,
line 1002, in add_subpackage
caller_level = 2)
File /home/charris/Workspace/numpy.git/numpy/distutils/misc_util.py,
line 971, in get_subpackage
caller_level = caller_level + 1)
File /home/charris/Workspace/numpy.git/numpy/distutils/misc_util.py,
line 908, in _get_configuration_from_setup_py
config = setup_module.configuration(*args)
File numpy/core/setup.py, line 901, in configuration
blas_info = get_info('blas_opt',0)
File
/home/charris/Workspace/numpy.git/numpy/distutils/system_info.py, line
325, in get_info
return cl().get_info(notfound_action)
File
/home/charris/Workspace/numpy.git/numpy/distutils/system_info.py, line
478, in get_info
self.calc_info()
File
/home/charris/Workspace/numpy.git/numpy/distutils/system_info.py, line
1465, in calc_info
atlas_info = get_info('atlas_blas_threads')
File
/home/charris/Workspace/numpy.git/numpy/distutils/system_info.py, line
325, in get_info
return cl().get_info(notfound_action)
File
/home/charris/Workspace/numpy.git/numpy/distutils/system_info.py, line
478, in get_info
self.calc_info()
File /home/charris/Workspace/numpy.git/numpy/distutils/system_info.py
numpy/distutils/system_info.py, line 1090, in calc_info
dict_append(atlas, **atlas_extra_info)
NameError: global name 'atlas_extra_info' is not defined
Commenting out line 1090 in numpy/distutils/system_info.py fixes the
problem, but I'm pretty sure that isn't the right fix.
Does it work when you add:
atlas_version, atlas_extra_info = get_atlas_version(**atlas)
on line 1090?
I thought the testing was extensive enough (we did 3 machines, different
OSes and site.cfg's), but apparently not. Sorry about that.
That fixes the problem for me.
Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] float96 on windows32 is float64?
On Fri, Mar 16, 2012 at 2:10 AM, Ilan Schnell ischn...@enthought.com wrote: I just did a quick test across all supported EPD platforms: win-64: float96 No, float128 No win-32: float96 No, float128 No osx-64: float96 No, float128 Yes osx-32: float96 No, float128 Yes rh3-64: float96 No, float128 Yes rh3-32: float96 Yes, float128 No rh5-64: float96 No, float128 Yes rh5-32: float96 Yes, float128 No sol-64: float96 No, float128 Yes sol-32: float96 Yes, float128 No numpy 1.5.1 MingW, on python 2.6 win32 has float96, float128 no numpy 1.6.1 Gohlke (MKL I think) on python 3.2 win64 no float96, no float128 Josef I have no explanation for this, but I'm guessing David C. has. I'll look more into this tomorrow. - Ilan On Fri, Mar 16, 2012 at 12:40 AM, Matthew Brett matthew.br...@gmail.com wrote: Hi, On Thu, Mar 15, 2012 at 10:26 PM, Ilan Schnell ischn...@enthought.com wrote: To be more precise. On both 32-bit and 64-bit Windows machines I don't see.float96 as well as np.float128 Do you have any idea why I am seeing float96 and you are not? I'm on XP with the current sourceforge 1.6.1 exe installer with python.org 2.7 (and same for python.org 2.6 and numpy 1.5.1). Thanks, Matthew ___ 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] draft enum NEP
On Mar 16, 2012 1:02 AM, Stéfan van der Walt stefan ste...@sun.ac.za@ste...@sun.ac.za sun.ac.za ste...@sun.ac.za wrote: On Thu, Mar 15, 2012 at 4:02 PM, Nathaniel Smith njs n...@pobox.com@n...@pobox.com pobox.com n...@pobox.com wrote: I'm not sure what it would even mean to treat this kind of data as flags, since you can't take the bitwise-or of two strings... This makes a more sense outside of ndarrays, where you would do something like: enum FLAG0 = 1, FLAG1 = 2, FLAG2 = 4 do_something(data, mode=FLAG0 FLAG2) The enum is therefore just a handle for its numerical value. While it may not be that useful in an array, I think Mark was just pointing out that there may be other similar use cases, such as enumerating from 0 to N-1, or in reverse from N-1 down to 0, or in steps of 2, or in powers of 2, etc. Right, there may be. But are there? That's the question :-) It looks like R doesn't support anything except 1, ..., N numbering. There's really no reason it would either, since in their design the underlying integer values are almost entirely hidden from users. You could get at them if you wanted, but I bet less than 1% of users are even aware that factors and integers have anything to do with each other. Factors are just documented to be a way to store an array of strings drawn from a limited ordered list. (The ordering is important for things like polynomial coding and treatment versus baseline coding.) HDF5 supports arbitrary symbol-integer mappings. 0, ..., N-1 coding makes the common problem of creating an indicator matrix very convenient: ind = np.zeros((enum_a.length, len(enum_.dtype.levels)), dtype=bool) ind[:, enum_a.view(dtype=np.int32)] = True But we can't restrict ourselves to only this coding if we want compatibility with HDF5 or R (because R is 1-based). So I guess supporting arbitrary mappings is worth it - though I doubt this flexibility will be used much. I'm curious if anyone can think of a reason they'd use it besides interoperability. Cheers, - Nathaniel ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] draft enum NEP
Hi all, I have spent some time thinking about things, and discussing them with folks nearby. I actually got to wondering whether we really need new dtypes for this. It seems like enumerated values or factor levels could be cast as an annotation or metadata that could be attached to any existing integral dtypes. It spells differently enough that I have put up an alternate version that reflects this notion. I'd like to see what folks think of this direction: https://github.com/bryevdv/numpy/blob/enum/doc/neps/enum_alt.rst So this would require adding machinery to existing dtypes to behave properly when there is factor metadata present. Perhaps that is not an acceptable trade-off, but it seems worth discussing. I think a very similar approach could be used to add categorical ranges to any numerical or string types (I think they are called shingles in R?) Please let me know what you think. Bryan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] remove redundant dimension in a ndarray?
Dear all, Do we have a function in numpy that can automatically shrink a ndarray with redundant dimension? like I have a ndarray with shape of (13,1,1,160,1), now I have written a small function to change the array to dimension of (13,160) [reduce the extra dimension with length as 1]. but I just would like to know maybe there is already something which can do this there ? 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] remove redundant dimension in a ndarray?
Dear Chao, Do we have a function in numpy that can automatically shrink a ndarray with redundant dimension? like I have a ndarray with shape of (13,1,1,160,1), now I have written a small function to change the array to dimension of (13,160) [reduce the extra dimension with length as 1]. but I just would like to know maybe there is already something which can do this there ? np.squeeze Cheers, Derek ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] unique along axis?
On Mon, Mar 12, 2012 at 8:04 PM, Neal Becker ndbeck...@gmail.com wrote: I see unique does not take an axis arg. Suggested way to apply unique to each column of a 2d array? A for-loop? I'm guessing that there isn't an axis keyword because the number of unique elements per column may not be the same, so you can't return an ndarray. Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] numpy + MKL problems
Dear users, I was playing around with my numpy configuration, and it is now no longer working. Whenever I try to run anything with it, I get: ...MKL FATAL ERROR: /opt/intel/mkl/10.0.3.020/lib/em64t/: cannot read file data: Is a directory My site.cfg file is (in case it helps!): [DEFAULT] library_dirs = /usr/lib include_dirs = /usr/include [fftw] libraries = fftw3 [mkl] library_dirs = /opt/intel/mkl/10.0.3.020/lib/em64t include_dirs = /opt/intel/mkl/10.0.3.020/include mkl_libs = mkl_intel_lp64,mkl_intel_thread,mkl_core I have followed the directions for installing it from source, and it was working fine earlier today. But I'm not really sure what I had changed so it would go from working to not working. Any advice would be appreciated! Dr. Glen Jenness Schmidt Group Department of Chemistry University of Wisconsin - Madison ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy + MKL problems
On Mar 16, 2012, at 8:00 PM, Glen Jenness wrote: Dear users, I was playing around with my numpy configuration, and it is now no longer working. Whenever I try to run anything with it, I get: ...MKL FATAL ERROR: /opt/intel/mkl/10.0.3.020/lib/em64t/: cannot read file data: Is a directory My site.cfg file is (in case it helps!): [DEFAULT] library_dirs = /usr/lib include_dirs = /usr/include [fftw] libraries = fftw3 [mkl] library_dirs = /opt/intel/mkl/10.0.3.020/lib/em64t include_dirs = /opt/intel/mkl/10.0.3.020/include mkl_libs = mkl_intel_lp64,mkl_intel_thread,mkl_core I have followed the directions for installing it from source, and it was working fine earlier today. But I'm not really sure what I had changed so it would go from working to not working. This might be related with: http://projects.scipy.org/numpy/ticket/993 being fixed in the last few hours. Could you please bisect (http://webchick.net/node/99) and tell us which commit is the bad one? Thanks! -- Francesc Alted ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy + MKL problems
Fransesc, I don't think that's the problem-I'm working with a version of numpy I had downloaded back in Dec/Jan and have not updated it since. However, doing a LD_PRELOAD seems to have fixed the problem, but now whenever I'm running a script I get: python 2.4.3 GCC 4.1.2 20070626 (Red Hat 4.1.2-14) 64bit ELF on Linux x86_64 redhat 5.2 Final python: symbol lookup error: /opt/intel/mkl/ 10.0.3.020/lib/em64t/libmkl_lapack.so: undefined symbol: mkl_lapack_dgetrf Glen On Fri, Mar 16, 2012 at 8:17 PM, Francesc Alted franc...@continuum.iowrote: On Mar 16, 2012, at 8:00 PM, Glen Jenness wrote: Dear users, I was playing around with my numpy configuration, and it is now no longer working. Whenever I try to run anything with it, I get: ...MKL FATAL ERROR: /opt/intel/mkl/10.0.3.020/lib/em64t/: cannot read file data: Is a directory My site.cfg file is (in case it helps!): [DEFAULT] library_dirs = /usr/lib include_dirs = /usr/include [fftw] libraries = fftw3 [mkl] library_dirs = /opt/intel/mkl/10.0.3.020/lib/em64t include_dirs = /opt/intel/mkl/10.0.3.020/include mkl_libs = mkl_intel_lp64,mkl_intel_thread,mkl_core I have followed the directions for installing it from source, and it was working fine earlier today. But I'm not really sure what I had changed so it would go from working to not working. This might be related with: http://projects.scipy.org/numpy/ticket/993 being fixed in the last few hours. Could you please bisect ( http://webchick.net/node/99) and tell us which commit is the bad one? Thanks! -- Francesc Alted ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion -- Dr. Glen Jenness Schmidt Group Department of Chemistry University of Wisconsin - Madison ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy + MKL problems
On Mar 16, 2012, at 8:28 PM, Glen Jenness wrote: Fransesc, I don't think that's the problem-I'm working with a version of numpy I had downloaded back in Dec/Jan and have not updated it since. However, doing a LD_PRELOAD seems to have fixed the problem, but now whenever I'm running a script I get: python 2.4.3 GCC 4.1.2 20070626 (Red Hat 4.1.2-14) 64bit ELF on Linux x86_64 redhat 5.2 Final python: symbol lookup error: /opt/intel/mkl/10.0.3.020/lib/em64t/libmkl_lapack.so: undefined symbol: mkl_lapack_dgetrf So, if numpy has not changed, then something else does, right? Have you upgraded MKL? GCC? Installed Intel C compiler? -- Francesc Alted ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] float96 on windows32 is float64?
Hi, On Fri, Mar 16, 2012 at 5:36 AM, josef.p...@gmail.com wrote: On Fri, Mar 16, 2012 at 2:10 AM, Ilan Schnell ischn...@enthought.com wrote: I just did a quick test across all supported EPD platforms: win-64: float96 No, float128 No win-32: float96 No, float128 No osx-64: float96 No, float128 Yes osx-32: float96 No, float128 Yes rh3-64: float96 No, float128 Yes rh3-32: float96 Yes, float128 No rh5-64: float96 No, float128 Yes rh5-32: float96 Yes, float128 No sol-64: float96 No, float128 Yes sol-32: float96 Yes, float128 No numpy 1.5.1 MingW, on python 2.6 win32 has float96, float128 no numpy 1.6.1 Gohlke (MKL I think) on python 3.2 win64 no float96, no float128 Josef I have no explanation for this, but I'm guessing David C. has. I'll look more into this tomorrow. - Ilan Oh dear - I completely forgot the previous thread that I started on this : http://mail.scipy.org/pipermail/numpy-discussion/2011-November/059233.html You young people, don't laugh, this will happen to you one day. Anyway, summarizing, it appears that windows float96: a) Is stored as an 80 bit extended precision number b) Uses float64 precision for all calculations. c) Is specific to MingW builds of numpy - I think. Perhaps David C you'll correct me if I've got that wrong, Best, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy + MKL problems
None of that-this is why it has been so frustrating! Only thing I did was remove the folders in the ./build directory in order to get a cleaner slate, and just changed a couple libraries in site.cfg, and got the error, and it persisted even when I went back to the libraries I had given it when I got it to work. So I am really confused as to what could have caused the issue to start with. Anyways, it seems okay now-I had to add mkl_lapack to the library list. Everything isn't 100% yet, but I can now work with it. On Fri, Mar 16, 2012 at 8:35 PM, Francesc Alted franc...@continuum.iowrote: On Mar 16, 2012, at 8:28 PM, Glen Jenness wrote: Fransesc, I don't think that's the problem-I'm working with a version of numpy I had downloaded back in Dec/Jan and have not updated it since. However, doing a LD_PRELOAD seems to have fixed the problem, but now whenever I'm running a script I get: python 2.4.3 GCC 4.1.2 20070626 (Red Hat 4.1.2-14) 64bit ELF on Linux x86_64 redhat 5.2 Final python: symbol lookup error: /opt/intel/mkl/ 10.0.3.020/lib/em64t/libmkl_lapack.so: undefined symbol: mkl_lapack_dgetrf So, if numpy has not changed, then something else does, right? Have you upgraded MKL? GCC? Installed Intel C compiler? -- Francesc Alted ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion -- Dr. Glen Jenness Schmidt Group Department of Chemistry University of Wisconsin - Madison ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
