[Numpy-discussion] datetime uses API deprecated in python3.1
Hi Travis,
The warning is
dep.py:6: PendingDeprecationWarning: The CObject API is deprecated as of
Python 3.1. Please convert to using the Capsule API.
np.dtype('M8[3M/40]')
This doesn't happen with the old dtypes, so I assume it is associated with
something introduced for datetime. Any ideas? I've attached a script that
shows the warning.
Chuck
import numpy as np
import warnings
warnings.simplefilter('always')
assert np.dtype('M8[3M/40]') == np.dtype('M8[54h]')
np.dtype('M8[3M/40]')
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] numpy.test() failures in 2.0.0.dev8233
==
FAIL:
test_multiarray.TestNewBufferProtocol.test_export_endian
--
Traceback (most recent call last):
File
/home/nwagner/local/lib64/python2.6/site-packages/nose-0.11.2.dev-py2.6.egg/nose/case.py,
line 183, in runTest
self.test(*self.arg)
File
/home/nwagner/local/lib64/python2.6/site-packages/numpy/core/tests/test_multiarray.py,
line 1582, in test_export_endian
assert y.format in 'l'
AssertionError
==
FAIL:
test_multiarray.TestNewBufferProtocol.test_export_record
--
Traceback (most recent call last):
File
/home/nwagner/local/lib64/python2.6/site-packages/nose-0.11.2.dev-py2.6.egg/nose/case.py,
line 183, in runTest
self.test(*self.arg)
File
/home/nwagner/local/lib64/python2.6/site-packages/numpy/core/tests/test_multiarray.py,
line 1561, in test_export_record
assert y.format ==
'T{b:a:=h:b:=l:c:=q:d:B:e:=H:f:=L:g:=Q:h:=d:i:=d:j:=g:k:4s:l:=4w:m:3x:n:?:o:}'
AssertionError
==
FAIL:
test_multiarray.TestNewBufferProtocol.test_export_simple_1d
--
Traceback (most recent call last):
File
/home/nwagner/local/lib64/python2.6/site-packages/nose-0.11.2.dev-py2.6.egg/nose/case.py,
line 183, in runTest
self.test(*self.arg)
File
/home/nwagner/local/lib64/python2.6/site-packages/numpy/core/tests/test_multiarray.py,
line 1514, in test_export_simple_1d
assert y.format == '=l'
AssertionError
==
FAIL:
test_multiarray.TestNewBufferProtocol.test_export_subarray
--
Traceback (most recent call last):
File
/home/nwagner/local/lib64/python2.6/site-packages/nose-0.11.2.dev-py2.6.egg/nose/case.py,
line 183, in runTest
self.test(*self.arg)
File
/home/nwagner/local/lib64/python2.6/site-packages/numpy/core/tests/test_multiarray.py,
line 1576, in test_export_subarray
assert y.itemsize == 16
AssertionError
--
Ran 2519 tests in 21.494s
FAILED (KNOWNFAIL=4, failures=4)
nose.result.TextTestResult run=2519 errors=0 failures=4
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Request for testing
Hi All,
I would be much obliged if some folks would run the attached script and
report the output, numpy version, and python version. It just runs
np.isinf(np.inf), which raises an invalid value warning with current
numpy. As far as I can see the function itself hasn't changed since
numpy1.3, yet numpy1.3 python2.5 gives no such warning.
Chuck
import numpy as np
import warnings
warnings.simplefilter('always')
np.seterr(invalid='print')
print (np.isinf(np.inf))
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Request for testing
On Sun, Feb 21, 2010 at 7:30 PM, Charles R Harris charlesr.har...@gmail.com wrote: Hi All, I would be much obliged if some folks would run the attached script and report the output, numpy version, and python version. It just runs np.isinf(np.inf), which raises an invalid value warning with current numpy. As far as I can see the function itself hasn't changed since numpy1.3, yet numpy1.3 python2.5 gives no such warning. This is most likely a bug in isinf or how we use it - the warning is not new, but was hidden before because of the FPU error stage set to ignore instead of warning. I am afraid dealing with this correctly cannot be done in a short time frame: the issues are quite subtle, and very platform dependent. cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Request for testing
On Sun, 21 Feb 2010 03:30:31 -0700
Charles R Harris charlesr.har...@gmail.com wrote:
Hi All,
I would be much obliged if some folks would run the
attached script and
report the output, numpy version, and python version. It
just runs
np.isinf(np.inf), which raises an invalid value
warning with current
numpy. As far as I can see the function itself hasn't
changed since
numpy1.3, yet numpy1.3 python2.5 gives no such
warning.
Chuck
python -i isinf.py
2.0.0.dev8233
2.6.2
import numpy as np
import warnings
import platform
print np.__version__
print platform.python_version()
warnings.simplefilter('always')
np.seterr(invalid='print')
print (np.isinf(np.inf))
Nils
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.test() failures in 2.0.0.dev8233
Hi,
Please remind me what platform you are running on. Also, please update
and re-run the tests, and check the output from
import numpy as np
from numpy.core.multiarray import memorysimpleview as memoryview
dt = [('a', np.int8), ('b', np.int16),
('c', np.int32), ('d', np.int64),
('e', np.uint8), ('f', np.uint16),
('g', np.uint32), ('h', np.uint64),
('i', np.float), ('j', np.double),
('k', np.longdouble), ('l', 'S4'),
('m', 'U4'), ('n', 'V3'), ('o', '?')]
x = np.array([(1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
'', '', ' ', True)], dtype=dt)
print memoryview(x).format
x = np.array([1,2,3], dtype='i4')
print memoryview(x).format
x = np.array(([[1,2],[3,4]],), dtype=[('a', (int, (2,2)))])
print memoryview(x).format
print memoryview(x).itemsize
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.test() failures in 2.0.0.dev8233
On Sun, 21 Feb 2010 13:22:41 +0200
Pauli Virtanen p...@iki.fi wrote:
Hi,
Please remind me what platform you are running on. Also,
please update
and re-run the tests, and check the output from
import numpy as np
from numpy.core.multiarray import memorysimpleview as
memoryview
dt = [('a', np.int8), ('b', np.int16),
('c', np.int32), ('d', np.int64),
('e', np.uint8), ('f', np.uint16),
('g', np.uint32), ('h', np.uint64),
('i', np.float), ('j', np.double),
('k', np.longdouble), ('l', 'S4'),
('m', 'U4'), ('n', 'V3'), ('o', '?')]
x = np.array([(1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
'', '', ' ', True)], dtype=dt)
print memoryview(x).format
x = np.array([1,2,3], dtype='i4')
print memoryview(x).format
x = np.array(([[1,2],[3,4]],), dtype=[('a', (int,
(2,2)))])
print memoryview(x).format
print memoryview(x).itemsize
T{b:a:=h:b:=i:c:=l:d:B:e:=H:f:=I:g:=L:h:=d:i:=d:j:=g:k:4s:l:=4w:m:3x:n:?:o:}
i
T{(2,2)=l:a:}
32
Linux-2.6.31.12-0.1-default-x86_64-with-SuSE-11.2-x86_64
2.0.0.dev8235
Nils
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Request for testing
On 2/21/2010 5:30 AM, Charles R Harris wrote:
I would be much obliged if some folks would run the attached script and
report the output, numpy version, and python version.
No problem with NumPy 1.3.0 (from superpack) on Python 2.6.4 under Vista.
Alan Isaac
Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on
win32
Type help, copyright, credits or license for more information.
import numpy as np
import warnings
warnings.simplefilter('always')
np.seterr(invalid='print')
{'over': 'ignore', 'divide': 'ignore', 'invalid': 'ignore', 'under': 'ignore'}
print (np.isinf(np.inf))
True
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Python 3 porting
Hi, The test suite passes now on Pythons 2.4 - 3.1. Further testing is very welcome -- also on Python 2.x. Please check that your favourite software still builds and works with SVN trunk Numpy. Currently, Scipy has some known failures because of (i) removed new= keyword in numpy.histogram (ii) Cython supports only native size/alignment PEP 3118 buffers, and Numpy arrays are most naturally expressed in the standardized sizes. Supporting the full struct module alignment stuff appears to be a slight PITA. I'll try to take a look at how to address this. But everything else seems to work on Python 2.6. *** Python version 2.4.6 (#2, Jan 21 2010, 23:27:36) [GCC 4.4.1] Ran 2509 tests in 18.892s OK (KNOWNFAIL=4, SKIP=2) Python version 2.5.4 (r254:67916, Jan 20 2010, 21:44:03) [GCC 4.4.1] Ran 2512 tests in 18.531s OK (KNOWNFAIL=4) Python version 2.6.4 (r264:75706, Dec 7 2009, 18:45:15) [GCC 4.4.1] Ran 2519 tests in 19.367s OK (KNOWNFAIL=4) Python version 3.1.1+ (r311:74480, Nov 2 2009, 14:49:22) [GCC 4.4.1] Ran 2518 tests in 23.239s OK (KNOWNFAIL=5) Cheers, Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Request for testing
My machine is a PPC dual G5, running Mac OS X 10.5.8
~ $ python
Python 2.5.4 (r254:67917, Dec 23 2008, 14:57:27)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type help, copyright, credits or license for more information.
import numpy as np
import warnings
warnings.simplefilter('always')
np.seterr(invalid='print')
{'over': 'ignore', 'divide': 'ignore', 'invalid': 'ignore', 'under':
'ignore'}
print (np.isinf(np.inf))
True
np.__version__
'1.4.0.dev7577'
On Feb 21, 2010, at 5:30 AM, Charles R Harris wrote:
Hi All,
I would be much obliged if some folks would run the attached script
and report the output, numpy version, and python version. It just
runs np.isinf(np.inf), which raises an invalid value warning with
current numpy. As far as I can see the function itself hasn't
changed since numpy1.3, yet numpy1.3 python2.5 gives no such
warning.
Chuck
isinf.py___
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] Request for testing
On Sun, Feb 21, 2010 at 6:30 PM, Charles R Harris charlesr.har...@gmail.com wrote: Hi All, I would be much obliged if some folks would run the attached script and report the output, numpy version, and python version. It just runs np.isinf(np.inf), which raises an invalid value warning with current numpy. As far as I can see the function itself hasn't changed since numpy1.3, yet numpy1.3 python2.5 gives no such warning. $ python isinf.py Warning: invalid value encountered in isinf True Python 2.6.4, on Snow Leopard NumPy trunk r8233 Cheers, Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Python 3 porting
AWESOME :) On Sun, Feb 21, 2010 at 1:43 PM, Pauli Virtanen p...@iki.fi wrote: Hi, The test suite passes now on Pythons 2.4 - 3.1. Further testing is very welcome -- also on Python 2.x. Please check that your favourite software still builds and works with SVN trunk Numpy. Currently, Scipy has some known failures because of (i) removed new= keyword in numpy.histogram (ii) Cython supports only native size/alignment PEP 3118 buffers, and Numpy arrays are most naturally expressed in the standardized sizes. Supporting the full struct module alignment stuff appears to be a slight PITA. I'll try to take a look at how to address this. But everything else seems to work on Python 2.6. *** Python version 2.4.6 (#2, Jan 21 2010, 23:27:36) [GCC 4.4.1] Ran 2509 tests in 18.892s OK (KNOWNFAIL=4, SKIP=2) Python version 2.5.4 (r254:67916, Jan 20 2010, 21:44:03) [GCC 4.4.1] Ran 2512 tests in 18.531s OK (KNOWNFAIL=4) Python version 2.6.4 (r264:75706, Dec 7 2009, 18:45:15) [GCC 4.4.1] Ran 2519 tests in 19.367s OK (KNOWNFAIL=4) Python version 3.1.1+ (r311:74480, Nov 2 2009, 14:49:22) [GCC 4.4.1] Ran 2518 tests in 23.239s OK (KNOWNFAIL=5) Cheers, Pauli ___ 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] Request for testing
On Sun, Feb 21, 2010 at 2:30 AM, Charles R Harris charlesr.har...@gmail.com wrote: I would be much obliged if some folks would run the attached script and report the output, numpy version, and python version. import isinf Warning: invalid value encountered in isinf True Python 2.6.4 (r264:75706, Dec 7 2009, 18:43:55) [GCC 4.4.1] on linux2 Numpy '1.4.0rc2' ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Request for testing
On Sun, Feb 21, 2010 at 3:33 AM, David Cournapeau courn...@gmail.comwrote: On Sun, Feb 21, 2010 at 7:30 PM, Charles R Harris charlesr.har...@gmail.com wrote: Hi All, I would be much obliged if some folks would run the attached script and report the output, numpy version, and python version. It just runs np.isinf(np.inf), which raises an invalid value warning with current numpy. As far as I can see the function itself hasn't changed since numpy1.3, yet numpy1.3 python2.5 gives no such warning. This is most likely a bug in isinf or how we use it - the warning is not new, but was hidden before because of the FPU error stage set to ignore instead of warning. I am afraid dealing with this correctly cannot be done in a short time frame: the issues are quite subtle, and very platform dependent. The script enables the warning so the difference shouldn't depend on the recent change in the warnings default. I was thinking it more likely had something to do with the build environment/python version/compiler flags/.etc. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Request for testing
Charles R Harris wrote: Hi All, I would be much obliged if some folks would run the attached script and report the output, numpy version, and python version. It just runs np.isinf(np.inf), which raises an invalid value warning with current numpy. As far as I can see the function itself hasn't changed since numpy1.3, yet numpy1.3 python2.5 gives no such warning. Python 2.5.4 on Mac OSX 10.5.8 (EPD 5.0.0): I do not get a warning with numpy 1.3.0 or 2.0.0.dev8233. Warren ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Request for testing
On Sun, Feb 21, 2010 at 5:30 AM, Charles R Harris charlesr.har...@gmail.com wrote: Hi All, I would be much obliged if some folks would run the attached script and report the output, numpy version, and python version. It just runs np.isinf(np.inf), which raises an invalid value warning with current numpy. As far as I can see the function itself hasn't changed since numpy1.3, yet numpy1.3 python2.5 gives no such warning. Chuck On Kubuntu 9.10 with recent trunk. $ python2.5 isinf.py True $ python2.6 isinf.py Warning: invalid value encountered in isinf True Skipper PS. I also see a lot of the divide by zero warnings now (which are helpful) and wondered if they weren't related. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Request for testing
Charles R Harris wrote: Hi All, I would be much obliged if some folks would run the attached script and report the output, numpy version, and python version. It just runs np.isinf(np.inf), which raises an invalid value warning with current numpy. As far as I can see the function itself hasn't changed since numpy1.3, yet numpy1.3 python2.5 gives no such warning. Chuck efir...@manini:~$ python test/isinf.py Warning: invalid value encountered in isinf True In [4]:numpy.version.version Out[4]:'1.5.0.dev8042' Python 2.6.4 (r264:75706, Dec 7 2009, 18:45:15) Ubuntu 9.10 Eric ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Request for testing
$ python isinf.py Warning: invalid value encountered in isinf True machine: gentoo linux on amd64 python 2.6.4 (64 bit) gcc 4.3.4 numpy.__version__ == '1.4.0' glibc 2.10.1 Nadav -Original Message- From: numpy-discussion-boun...@scipy.org on behalf of Charles R Harris Sent: Sun 21-Feb-10 12:30 To: numpy-discussion Subject: [Numpy-discussion] Request for testing Hi All, I would be much obliged if some folks would run the attached script and report the output, numpy version, and python version. It just runs np.isinf(np.inf), which raises an invalid value warning with current numpy. As far as I can see the function itself hasn't changed since numpy1.3, yet numpy1.3 python2.5 gives no such warning. Chuck winmail.dat___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] datetime uses API deprecated in python3.1
su, 2010-02-21 kello 02:13 -0700, Charles R Harris kirjoitti:
The warning is
dep.py:6: PendingDeprecationWarning: The CObject API is deprecated as
of Python 3.1. Please convert to using the Capsule API.
np.dtype('M8[3M/40]')
This doesn't happen with the old dtypes, so I assume it is associated
with something introduced for datetime. Any ideas? I've attached a
script that shows the warning.
The PyCObjects are used at least within the __array_struct__ interface,
ufuncs, and apparently the datetime extra data is stored within one in
the array metadata dict.
The Capsule API seems pretty much the same as the CObject API. (Why the
name change?) We can probably #define PyCapsule_* compatibility defines
in npy_3kcompat.h that use PyCObject on 2.x, and use the real thing on
3.x.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Request for testing
On Sun, Feb 21, 2010 at 4:30 AM, Charles R Harris charlesr.har...@gmail.com
wrote:
Hi All,
I would be much obliged if some folks would run the attached script and
report the output, numpy version, and python version. It just runs
np.isinf(np.inf), which raises an invalid value warning with current
numpy. As far as I can see the function itself hasn't changed since
numpy1.3, yet numpy1.3 python2.5 gives no such warning.
Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[gse...@ccn ~]$ python isinf.py
True
[gse...@ccn various]$ python sysinfo.py
Platform :
Linux-2.6.31.9-174.fc12.i686.PAE-i686-with-fedora-12-Constantine
Python : ('CPython', 'tags/r262', '71600')
NumPy : 1.5.0.dev8038
--
Gökhan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] datetime uses API deprecated in python3.1
su, 2010-02-21 kello 20:17 +0200, Pauli Virtanen kirjoitti: [clip] The Capsule API seems pretty much the same as the CObject API. (Why the name change?) We can probably #define PyCapsule_* compatibility defines in npy_3kcompat.h that use PyCObject on 2.x, and use the real thing on 3.x. Btw, I read that PyCObjects are completely gone on Python 3.2, so apparently we *have* to make this transition. Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] datetime uses API deprecated in python3.1
On Sun, Feb 21, 2010 at 11:34 AM, Pauli Virtanen p...@iki.fi wrote: su, 2010-02-21 kello 20:17 +0200, Pauli Virtanen kirjoitti: [clip] The Capsule API seems pretty much the same as the CObject API. (Why the name change?) We can probably #define PyCapsule_* compatibility defines in npy_3kcompat.h that use PyCObject on 2.x, and use the real thing on 3.x. Btw, I read that PyCObjects are completely gone on Python 3.2, so apparently we *have* to make this transition. I haven't looked closely at the new API. If you think the fix is as easy as some defines, go for it. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Python 3 porting
Pauli Virtanen wrote: Hi, The test suite passes now on Pythons 2.4 - 3.1. Further testing is very welcome -- also on Python 2.x. Please check that your favourite software still builds and works with SVN trunk Numpy. Currently, Scipy has some known failures because of (i) removed new= keyword in numpy.histogram (ii) Cython supports only native size/alignment PEP 3118 buffers, and Numpy arrays are most naturally expressed in the standardized sizes. Supporting the full struct module alignment stuff appears to be a slight PITA. I'll try Hmm. How much would it help if Cython dealt with standardized sizes when possible? Is Cython the only reason to have NumPy export native size/alignment? Also, wouldn't it be a pain to export align=True dtypes in standard size/alignment? (As a quick hack in SciPy, there's always np.ndarray[int, cast=True] to skip the format string checking (size is still checked).) Dag Sverre ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Request for testing
No Warning for me:
└─(08:26 $)─ python isinf.py
True
└─(08:26 $)─ python2.5 isinf.py
True
Python 2.6.4 (r264:75706, Dec 7 2009, 18:43:55)
[GCC 4.4.1] on linux2
Python 2.5.4 (r254:67916, Jan 20 2010, 21:43:02)
[GCC 4.4.1] on linux2
numpy.version.version
'1.3.0'
└─(08:33 $)─ uname -a
Linux cudos0803 2.6.31-19-generic #56-Ubuntu SMP Thu Jan 28 02:39:34 UTC 2010
x86_64 GNU/Linux
└─(08:31 $)─ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 9.10
Release: 9.10
Codename: karmic
On 02/21/10 03:30, Charles R Harris wrote:
Hi All,
I would be much obliged if some folks would run the attached script and report
the output, numpy version, and python version. It just runs np.isinf(np.inf),
which raises an invalid value warning with current numpy. As far as I can
see
the function itself hasn't changed since numpy1.3, yet numpy1.3 python2.5
gives no such warning.
Chuck
import numpy as np
import warnings
warnings.simplefilter('always')
np.seterr(invalid='print')
print (np.isinf(np.inf))
___
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] ask.scipy.org
Hello, Since after Robert Kern showed http://advice.mechanicalkern.com/ on SciPy09 there are many similar initiatives that uses stackoverflow.com (SO) layout. Some smart guys come up with this site http://stackexchange.com/ to those who want to have a simple but a paid solution. I don't have an intention of creating controversial discussion. It just to my eyes SO has a very appealing and easy to use interface and it's getting some number of posts related to scientific Python tools. I usually suggest my friends to use the mailing lists first and SO for their questions. Some prefer mailing lists some not. Mailing lists require more steps to get in however SO register step is much easier due to OpenID logging. Without belabouring further, It would be good to link R. Kern's advice site to either ask.scipy or advice.scipy or another alternative to attract new-comers easily. I am more in favor of the ask.scipy.org option. Thus I can refer the people (hear I mean mostly non-programmers or students/programmers without Python experience), simply to go ask.scipy.orgfor their first questions instead of telling them to search answers at many different mediums. What do you think? -- Gökhan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ask.scipy.org
On Sun, Feb 21, 2010 at 16:00, Gökhan Sever gokhanse...@gmail.com wrote: Hello, Since after Robert Kern showed http://advice.mechanicalkern.com/ on SciPy09 there are many similar initiatives that uses stackoverflow.com (SO) layout. Some smart guys come up with this site http://stackexchange.com/ to those who want to have a simple but a paid solution. Indeed, stackexchange.com is the paid hosting option from the Stack Overflow team. I don't have an intention of creating controversial discussion. It just to my eyes SO has a very appealing and easy to use interface and it's getting some number of posts related to scientific Python tools. I usually suggest my friends to use the mailing lists first and SO for their questions. Some prefer mailing lists some not. Mailing lists require more steps to get in however SO register step is much easier due to OpenID logging. Without belabouring further, It would be good to link R. Kern's advice site to either ask.scipy or advice.scipy or another alternative to attract new-comers easily. I am more in favor of the ask.scipy.org option. Thus I can refer the people (hear I mean mostly non-programmers or students/programmers without Python experience), simply to go ask.scipy.org for their first questions instead of telling them to search answers at many different mediums. What do you think? I spent some time on Friday getting Plurk's Solace tweaked for our use (for various reasons, it's much better code to deal with than the CNPROG software currently running advice.mechanicalkern.com). http://opensource.plurk.com/Solace/ I still need to investigate how to migrate the content from the old site over, but ask.scipy.org should be up and running quite soon. -- 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@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ask.scipy.org
On Mon, Feb 22, 2010 at 7:06 AM, Robert Kern robert.k...@gmail.com wrote: I spent some time on Friday getting Plurk's Solace tweaked for our use (for various reasons, it's much better code to deal with than the CNPROG software currently running advice.mechanicalkern.com). http://opensource.plurk.com/Solace/ I still need to investigate how to migrate the content from the old site over, but ask.scipy.org should be up and running quite soon. This is great news. Thank you very much for the effort ! David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ask.scipy.org
On Sun, Feb 21, 2010 at 4:06 PM, Robert Kern robert.k...@gmail.com wrote: On Sun, Feb 21, 2010 at 16:00, Gökhan Sever gokhanse...@gmail.com wrote: Hello, Since after Robert Kern showed http://advice.mechanicalkern.com/ on SciPy09 there are many similar initiatives that uses stackoverflow.com (SO) layout. Some smart guys come up with this site http://stackexchange.com/ to those who want to have a simple but a paid solution. Indeed, stackexchange.com is the paid hosting option from the Stack Overflow team. I don't have an intention of creating controversial discussion. It just to my eyes SO has a very appealing and easy to use interface and it's getting some number of posts related to scientific Python tools. I usually suggest my friends to use the mailing lists first and SO for their questions. Some prefer mailing lists some not. Mailing lists require more steps to get in however SO register step is much easier due to OpenID logging. Without belabouring further, It would be good to link R. Kern's advice site to either ask.scipy or advice.scipy or another alternative to attract new-comers easily. I am more in favor of the ask.scipy.org option. Thus I can refer the people (hear I mean mostly non-programmers or students/programmers without Python experience), simply to go ask.scipy.org for their first questions instead of telling them to search answers at many different mediums. What do you think? I spent some time on Friday getting Plurk's Solace tweaked for our use (for various reasons, it's much better code to deal with than the CNPROG software currently running advice.mechanicalkern.com). http://opensource.plurk.com/Solace/ I still need to investigate how to migrate the content from the old site over, but ask.scipy.org should be up and running quite soon. Thanks for your efforts Robert. Please let us know when the new site is up. -- 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@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion -- Gökhan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Python 3 porting
su, 2010-02-21 kello 20:45 +0100, Dag Sverre Seljebotn kirjoitti:
Pauli Virtanen wrote:
[clip]
Currently, Scipy has some known failures because of
(i) removed new= keyword in numpy.histogram
(ii) Cython supports only native size/alignment PEP 3118 buffers, and
Numpy arrays are most naturally expressed in the standardized
sizes. Supporting the full struct module alignment stuff appears
to be a slight PITA. I'll try
Hmm. How much would it help if Cython dealt with standardized sizes when
possible? Is Cython the only reason to have NumPy export native
size/alignment?
Possibly. Anyway, I managed to implement this so that the format string
is in the native+aligned '@' form when possible, and falls back to the
unaligned alternatives when not.
Now the question is: should it prefer the standard unaligned types ('=')
or the native types ('^')? For non-native byte orders of course there is
only the standard alternative. This also means that long doubles or
64-bit long longs in non-native byte order cannot be exported.
Btw, do you know if the '@' format should include the padding xxx or
not? And if not, does the implicit padding also pad the end of the
structure to even alignment? Or is alignment = itemsize always?
Also, wouldn't it be a pain to export align=True dtypes in standard
size/alignment?
Not really, as the padding needed for alignment is computed at the time
the dtype is constructed, so the necessary info is readily available.
It's actually exporting '@' dtypes properly that's painful, since this
requires thinking about what information must be omitted, and checking
when it is possible to do.
Notes to self:
- I think I possibly forgot the possible padding at the end of the
dtype in the provider.
- '@' format strings should probably not include padding that is
included in the alignment. I assumed this in the consumer interface,
but forgot about it in the provider. Roundtrips probably work all
right, though, since explicit padding causes zero implicit padding.
Pauli
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] datetime uses API deprecated in python3.1
On Sun, Feb 21, 2010 at 11:34 AM, Pauli Virtanen p...@iki.fi wrote: su, 2010-02-21 kello 20:17 +0200, Pauli Virtanen kirjoitti: [clip] The Capsule API seems pretty much the same as the CObject API. (Why the name change?) We can probably #define PyCapsule_* compatibility defines in npy_3kcompat.h that use PyCObject on 2.x, and use the real thing on 3.x. Btw, I read that PyCObjects are completely gone on Python 3.2, so apparently we *have* to make this transition. It does look like the old interface can be emulated with the new objects, but the need for a 'name' might cause trouble. I suppose that will depend on how the current objects are used. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Building Windows binaries on OS X
On Tue, Feb 9, 2010 at 9:54 AM, David Cournapeau courn...@gmail.com wrote: On Mon, Feb 8, 2010 at 9:14 PM, Ralf Gommers Final question is about Atlas and friends. Is 3.8.3 the best version to install? Does it compile out of the box under Wine? Is this page http://www.scipy.org/Installing_SciPy/Windows still up-to-date with regard to the Lapack/Atlas info and does it apply for Wine? Atlas 3.9.x should not be used, it is too unstable IMO (it is a dev version after all, and windows receives little testing compared to unix). I will put the Atlas binaries I am using somewhere - building Atlas is already painful, but building it with a limited architecture on windows takes it to a whole new level (it is not supported by atlas, you have to patch the build system by yourself). Hi David, did you find time to put those Atlas binaries somewhere? Thanks, Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
