Re: [Numpy-discussion] numpy-1.0 regress failure on OpenBSD
On Thu, 26 Oct 2006, Travis Oliphant wrote: Unless you want to help with tracking how long double is interpreted on several platforms, then just ignore the test. (It actually wasn't being run in 1.0b1). I'm happy to help - do you have a testcase that I can run on the various platforms that OpenBSD supports? -d - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy-1.0 regress failure on OpenBSD
Damien Miller wrote: Hi, I have just got around to updating OpenBSD's numpy port from 1.0b1 to 1.0 and am running into the following regress failure: .Warning: overflow encountered in exp F... == FAIL: Ticket #112 -- Traceback (most recent call last): File /usr/ports/math/py-numpy/w-py-numpy-1.0/fake-i386/usr/local/lib/python2.4/site-packages/numpy/core/tests/test_regression.py, line 220, in check_longfloat_repr assert(str(a)[1:9] == str(a[0])[:8]) AssertionError -- Ran 513 tests in 3.471s FAILED (failures=1) The variable 'a' seems to contain '[Inf]', so the failure appears related to the overflow warning. Any clues on how I can debug this further? Unless you want to help with tracking how long double is interpreted on several platforms, then just ignore the test. (It actually wasn't being run in 1.0b1). -Travis - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend
Travis Oliphant wrote: I'd like to make the first release-candidate of NumPy 1.0 this weekend. Any additions wanting to make the first official release candidate should be checked in by then. -Travis - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion Is it possible to circumvent the error messages if one uses Python2.4 ? ImportError: ctypes is not available. Nils - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend
Travis Oliphant wrote:
Sebastian Haase wrote:
Travis Oliphant wrote:
It's not necessarily dead, the problem is complexity of implementation
and more clarity about how all dtypes are supposed to be printed, not
just this particular example. A patch would be very helpful here. If
desired it could be implemented in _internal.py and called from there in
arrayobject.c
But, to get you thinking... How should the following be printed
dtype('c4')
dtype('a4,i8,3f4')
dtype('3f4')
-Travis
I would argue that if the simple cases were addressed first those would
cover 90% (if not 99% for most people) of the cases occurring in
people's daily use.
For complex types (like 'a4,i8,3f4') I actually think the current text
is compact and good.
(Lateron one could think about
'c4' -- '4 chars'
'3f4' -- '3 float32s'
but already I don't know: is there any difference between 'c4' and
'4c1'? What is the difference between 'c4' and 'a4' !?
)
My main focus is on the fact that you might read 'i4' as
less than 4-bytes int, which is very confusing !
I can agree it's confusing at first, but it's the same syntax the struct
module uses which is the Python precedent for this.
I'm happy with seeing the repr() value since I know what it means, but I
can see Sebastian's point. Perhaps there's a middle ground -- the str()
representation for simple dtypes could contain both the repr() value and
an English description. For example, something along the lines of
dtype('i4') (4 byte integer, little endian). For more complex dtypes,
the repr() string could be given without any kind of English translation.
-Andrew
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend
El dj 14 de 09 del 2006 a les 02:11 -0700, en/na Andrew Straw va
escriure:
My main focus is on the fact that you might read 'i4' as
less than 4-bytes int, which is very confusing !
I can agree it's confusing at first, but it's the same syntax the struct
module uses which is the Python precedent for this.
I'm happy with seeing the repr() value since I know what it means, but I
can see Sebastian's point. Perhaps there's a middle ground -- the str()
representation for simple dtypes could contain both the repr() value and
an English description. For example, something along the lines of
dtype('i4') (4 byte integer, little endian). For more complex dtypes,
the repr() string could be given without any kind of English translation.
+1
I was very used (and happy) to the numarray string representation for
types ('Int32', 'Complex64'...) and looking at how NumPy represents it
now, I'd say that this is a backwards step in readability. Something
like 'i4' would look good for a low-level library, but not for a
high-level one like NumPy, IMO.
Cheers,
--
0,0 Francesc Altet http://www.carabos.com/
V V Cárabos Coop. V. Enjoy Data
-
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend
Francesc Altet wrote:
El dj 14 de 09 del 2006 a les 02:11 -0700, en/na Andrew Straw va
escriure:
My main focus is on the fact that you might read 'i4' as
less than 4-bytes int, which is very confusing !
I can agree it's confusing at first, but it's the same syntax the struct
module uses which is the Python precedent for this.
I'm happy with seeing the repr() value since I know what it means, but I
can see Sebastian's point. Perhaps there's a middle ground -- the str()
representation for simple dtypes could contain both the repr() value and
an English description. For example, something along the lines of
dtype('i4') (4 byte integer, little endian). For more complex dtypes,
the repr() string could be given without any kind of English translation.
+1
I was very used (and happy) to the numarray string representation for
types ('Int32', 'Complex64'...) and looking at how NumPy represents it
now, I'd say that this is a backwards step in readability. Something
like 'i4' would look good for a low-level library, but not for a
high-level one like NumPy, IMO.
I agree entirely.
The first type I got 'i4' instead of 'Int32', my reaction was What the
hell is that?
It looked disturbingly like line-noise corrupted text to me! (Blast from
the past...)
+1 from me as well.
Vicki Laidler
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend
On 9/14/06, Victoria G. Laidler [EMAIL PROTECTED] wrote:
Francesc Altet wrote:El dj 14 de 09 del 2006 a les 02:11 -0700, en/na Andrew Straw vaescriure:My main focus is on the fact that you might read 'i4' asless than 4-bytes int, which is very confusing !
I can agree it's confusing at first, but it's the same syntax the structmodule uses which is the Python precedent for this.
I'm happy with seeing the repr() value since I know what it means, but Ican see Sebastian's point. Perhaps there's a middle ground -- the str()representation for simple dtypes could contain both the repr() value and
an English description. For example, something along the lines ofdtype('i4') (4 byte integer, little endian). For more complex dtypes,the repr() string could be given without any kind of English translation.
+1I was very used (and happy) to the numarray string representation fortypes ('Int32', 'Complex64'...) and looking at how NumPy represents itnow, I'd say that this is a backwards step in readability. Something
like 'i4' would look good for a low-level library, but not for ahigh-level one like NumPy, IMO.I agree entirely.The first type I got 'i4' instead of 'Int32', my reaction was What the
hell is that?It looked disturbingly like line-noise corrupted text to me! (Blast fromthe past...)+1 from me as well.Just to balance the voting, I think things are fine as they are. As Travis says, the '' is already used in the Python structure module and the rest doesn't take much time getting used to. However, the docstring for the dtype class is a bit lacking. It shouldn't be too much work to fix that up.
Chuck
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend
Hello all I just ran NumPy and SciPy through Valgrind, and everything looks clean on that the NumPy side. Some other things that could be fixed for RC1: - GCC 4.1.1 warning in ufuncobject.c: numpy/core/src/ufuncobject.c: In function âPyUFunc_RegisterLoopForTypeâ: numpy/core/src/ufuncobject.c:3215: warning: cmp may be used uninitialized in this function - Time to kill the dft package? /usr/lib/python2.4/site-packages/numpy/dft/__init__.py:2: UserWarning: The dft subpackage will be removed by 1.0 final -- it is now called fft warnings.warn(The dft subpackage will be removed by 1.0 final -- it is now called fft) - Test failure == ERROR: check_instance_methods (numpy.core.tests.test_defmatrix.test_matrix_return) -- Traceback (most recent call last): File /usr/lib/python2.4/site-packages/numpy/core/tests/test_defmatrix.py, line 166, in check_instance_methods b = f(*args) ValueError: setitem must have at least one argument Although not strictly NumPy issues, the following crops up when you run the SciPy test suite through Valgrind: Valgrind warnings when running scipy.integrate.tests.test_integrate.test_odeint http://projects.scipy.org/scipy/scipy/ticket/246 Valgrind warnings when running Cephes tests http://projects.scipy.org/scipy/scipy/ticket/247 Memory leak in fitpack http://projects.scipy.org/scipy/scipy/ticket/248 I think I've figured out #248. #246 should be relatively easy to fix. #247 is... interesting. Regards, Albert -Original Message- From: [EMAIL PROTECTED] [mailto:numpy- [EMAIL PROTECTED] On Behalf Of Travis Oliphant Sent: 13 September 2006 22:18 To: numpy-discussion Subject: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend I'd like to make the first release-candidate of NumPy 1.0 this weekend. Any additions wanting to make the first official release candidate should be checked in by then. -Travis - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend
Hi! I would like to hear about three tickets I submitted some time ago: Ticket #230 a**2 not executed as a*a if a.dtype = int32 is this easy to fix ? Ticket #229 numpy.random.poisson(0) should return 0 I hope there is agreement that the edge-case of 0 should/could be handled without raising an exception. I submitted a patch (please test first!) any comments on this one. Ticket #188 dtype should have nicer str representation Is this one now officially dead ? i4 is not intuitively readable ! 'i4' as repr() is OK but str() should rather return 'int32 (little endian)' Read also: http://aspn.activestate.com/ASPN/Mail/Message/3207949 Thanks, Sebastian Haase On Wednesday 13 September 2006 13:18, Travis Oliphant wrote: I'd like to make the first release-candidate of NumPy 1.0 this weekend. Any additions wanting to make the first official release candidate should be checked in by then. -Travis - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend
Sebastian Haase wrote:
Hi!
I would like to hear about three tickets I submitted some time ago:
Ticket #230 a**2 not executed as a*a if a.dtype = int32
is this easy to fix ?
Fixed. Now, all arrays with a**2 are executed as a*a (float arrays are
still
executed as square(a) (is this needed)?
Ticket #229 numpy.random.poisson(0) should return 0
I hope there is agreement that the edge-case of 0 should/could be handled
without raising an exception. I submitted a patch (please test first!)
any comments on this one.
Fixed. This seems reasonable to me.
Ticket #188 dtype should have nicer str representation
Is this one now officially dead ?
i4 is not intuitively readable ! 'i4' as repr() is OK
but str() should rather return 'int32 (little endian)'
It's not necessarily dead, the problem is complexity of implementation
and more clarity about how all dtypes are supposed to be printed, not
just this particular example. A patch would be very helpful here. If
desired it could be implemented in _internal.py and called from there in
arrayobject.c
But, to get you thinking... How should the following be printed
dtype('c4')
dtype('a4,i8,3f4')
dtype('3f4')
-Travis
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend
On 9/13/06, Travis Oliphant [EMAIL PROTECTED] wrote: I'd like to make the first release-candidate of NumPy 1.0 this weekend.Any additions wanting to make the first official release candidateshould be checked in by then.There are a few cleanups and added functionality I have in mind but nothing that would affect the release. Do you plan to keep the 1.0 release as is with only added fixes and then make a 1.1 release not too long after that contains additions, or are you thinking that modifications that don't affect the API should all go into 1.0.x or some such? Chuck - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend
Charles R Harris wrote: On 9/13/06, *Travis Oliphant* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I'd like to make the first release-candidate of NumPy 1.0 this weekend. Any additions wanting to make the first official release candidate should be checked in by then. There are a few cleanups and added functionality I have in mind but nothing that would affect the release. Do you plan to keep the 1.0 release as is with only added fixes and then make a 1.1 release not too long after that contains additions, or are you thinking that modifications that don't affect the API should all go into 1.0.x or some such? The plan is for 1.0.x to contain modifications that don't affect the API (good additions should be O.K.). We want extensions compiled against 1.0.x to work for a long time. The 1.1 release won't be for at least a year and probably longer. 1.0.1 would be a maintenance release of the 1.0 release. -Travis - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy 1.0
Graham Cummins wrote: Greetings, I just downloaded numpy 1.0b1. I see a lot of changes from 0.9.8, and I'm curious as to whether these changes will be a lasting property of numpy 1.0 and later. Most of the changes relate to nomenclature for type constants (e.g. int32, complex128, newaxis) and functions (e.g. inverse_real_fft - ifft). Although it takes some time to comb through code for all of the possible name changes (there are lots!), it's easy enough to do. Release notes will be forthcoming. These changes will be lasting... What changed is that old names were placed only in a compatibility module (numpy.oldnumeric). Import from there if you want the old names (convertcode was also changed to alter Numeric--numpy.oldnumeric. This was done so as to make it clearer what is old and for compatibility purposes only and what new code should be written with. The thing that is taking me longer is (as usual) converting c extensions. Float32, and PyArray_Float32 used to be defined in 0.9.8, and are now not. AFAICT, npy_float works in the same way Float32 used to work, but I haven't yet figured out what to use in place of PyArray_Float32 in, for example PyArray_FROM_OTF(data, ?? , ALIGNED | CONTIGUOUS); Here, we assigned the prefixes NPY_ and npy_ to all the old CAPITALIZED and uncapitalized names, respectively to avoid the problem of name clashes which occurs commonly when using NumPy to wrap another library. The un-prefixed names are still available when you use #include numpy/noprefix.h(which is what NumPy itself uses). On another topic, when I install numpy (version 0.9.8 or 1.0b1) using seutup.py install, the headers needed to build extensions don't get moved into my python distribution directory tree. I've been moving these files by hand, and that seems to work, but could I pass some argument to distutils that would do this automatically? To support multiple-version installations of NumPy (like eggs allow) it's important to put the headers in their own location and not in a system-wide directory. If you want to place them system-wide, you currently need to copy them by hand. But, it's not recommended to do that. Just append the output of numpy.get_include() to the list of include directories. -Travis - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
