Re: [Numpy-discussion] numpy-1.0 regress failure on OpenBSD

2006-10-27 Thread Damien Miller
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 th

Re: [Numpy-discussion] numpy-1.0 regress failure on OpenBSD

2006-10-26 Thread Travis Oliphant
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: > > > >>.

Re: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend

2006-09-14 Thread Charles R Harris
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 va>escriure:>>My main focus is on the fact that you might read '"less" than 4-bytes int, which is very confusing ! >>>I can agree it

Re: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend

2006-09-14 Thread Victoria G. Laidler
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 '>>>"less" than 4-bytes int, which is very confusing ! >>>I can agree it's confusing at first, but it's th

Re: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend

2006-09-14 Thread Francesc Altet
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 ' >> "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 wh

Re: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend

2006-09-14 Thread Andrew Straw
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

Re: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend

2006-09-13 Thread Nils Wagner
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 > > > - > Usin

Re: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend

2006-09-13 Thread Travis Oliphant
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

Re: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend

2006-09-13 Thread Travis Oliphant
Charles R Harris wrote: > > > 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 candidate > should be check

Re: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend

2006-09-13 Thread Sebastian Haase
Travis Oliphant wrote: >> Ticket #188 dtype should have nicer str representation >> Is this one now officially dead ? >> ">but str() should rather return 'int32 (little endian)' >> > It's not necessarily dead, the problem is complexity of implementation > and more clarity about h

Re: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend

2006-09-13 Thread Charles R Harris
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 th

Re: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend

2006-09-13 Thread Travis Oliphant
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

Re: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend

2006-09-13 Thread Sebastian Haase
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 rais

Re: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend

2006-09-13 Thread Albert Strasheim
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:32

Re: [Numpy-discussion] numpy 1.0

2006-07-24 Thread Travis Oliphant
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,