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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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

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 =
=E2PyUFunc_RegisterLoopForType=E2:
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

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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 =3D 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: num...@li... [mailto:numpy-
> dis...@li...] 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
>=20
> I'd like to make the first release-candidate of NumPy 1.0 this =
weekend.
>=20
> Any additions wanting to make the first official release candidate
> should be checked in by then.
>=20
> -Travis

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=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

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

Travis Oliphant wrote:

>> 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

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 !

As far as a patch is concerned: is _internal.py already being called now 
from arrayobject.c for the str() and repr() methods ? And is there so 
far any difference in str() and repr() ?
I assume that repr() has to stay exactly the way it is right now - right !?

Thanks,
Sebastian

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.
> As far as a patch is concerned: is _internal.py already being called now 
> from arrayobject.c for the str() and repr() methods ? And is there so 
>   
Yes, you can easily make a call to _internal.py from arrayobject.c (it's 
how some things are actually implemented). 

If you just provide a Python function to call for dtype.__str__ then 
that would suffice.
> far any difference in str() and repr() ?
> I assume that repr() has to stay exactly the way it is right now - right !?
>
>   
Yeah, the repr() probably needs to stay the same

-Travis

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 !
> >>  =20
> >>    =20
> > I can agree it's confusing at first, but it's the same syntax the struc=
t=20
> > module uses which is the Python precedent for this.
> >  =20
> 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,

--=20
>0,0<   Francesc Altet     http://www.carabos.com/
V   V   C=C3=A1rabos Coop. V.   Enjoy Data
 "-"

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

On 9/14/06, Victoria G. Laidler <la...@st...> 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 '<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.

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

On 9/13/06, Travis Oliphant <oli...@ie...> 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?

Chuck

Charles R Harris wrote:
>
>
> On 9/13/06, *Travis Oliphant* <oli...@ie... 
> <mailto:oli...@ie...>> 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

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=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> 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

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

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

A package for scientific computing with Python

numpy-discussion