numpy-discussion

[Numpy-discussion] Time for beta1 of NumPy 1.0

[Travis O. <oli...@ie...>]

I think it's time for the first beta-release of NumPy 1.0

I'd like to put it out within 2 weeks.  Please make any comments or 
voice major concerns so that the 1.0 release series can be as stable as 
possible.

-Travis

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

[Alan G I. <ai...@am...>]

On Thu, 29 Jun 2006, Travis Oliphant apparently wrote:=20
> Please make any comments or voice major concerns=20

A rather minor issue, but I would just like to make sure=20
that a policy decision was made not to move to a float=20
default for identity(), ones(), zeros(), and empty().
(I leave aside arange().)

I see the argument for a change to be 3-fold:
1. It is easier to introduce people to numpy if
   default data types are all float.  (I teach,
   and I want my students to use numpy.)
2. It is a better match to languages from which
   users are likely to migrate (e.g., GAUSS or
   Matlab).
3. In the uses I am most familiar with, float is
   the most frequently desired data type.  (I guess
   this may be field specific, especially for empty().)

Cheers,
Alan Isaac

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

[Stephan T. <st...@si...>]

I guess this is a change which would just break too much code. And if 
the default type should by changed for these functions, why not also for 
  array constructors?

On the other hand, many people probably use Numpy almost exclusively 
with Float64's. A convenient way to change the default type could make 
their code easier to read.
How much effort would it be to provide a convenience module that after 
importing replaces the relevant functions with wrappers that make 
Float64's the default?

Regards,
   Stephan



Alan G Isaac wrote:
> On Thu, 29 Jun 2006, Travis Oliphant apparently wrote: 
>> Please make any comments or voice major concerns 
> 
> A rather minor issue, but I would just like to make sure 
> that a policy decision was made not to move to a float 
> default for identity(), ones(), zeros(), and empty().
> (I leave aside arange().)
> 
> I see the argument for a change to be 3-fold:
> 1. It is easier to introduce people to numpy if
>    default data types are all float.  (I teach,
>    and I want my students to use numpy.)
> 2. It is a better match to languages from which
>    users are likely to migrate (e.g., GAUSS or
>    Matlab).
> 3. In the uses I am most familiar with, float is
>    the most frequently desired data type.  (I guess
>    this may be field specific, especially for empty().)
> 
> Cheers,
> Alan Isaac
> 

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

[Travis O. <oli...@ie...>]

Alan G Isaac wrote:
> On Thu, 29 Jun 2006, Travis Oliphant apparently wrote: 
>   
>> Please make any comments or voice major concerns 
>>     
>
> A rather minor issue, but I would just like to make sure 
> that a policy decision was made not to move to a float 
> default for identity(), ones(), zeros(), and empty().
> (I leave aside arange().)
>   

This was a policy decision made many months ago after discussion on this 
list and would need over-whelming pressure to change. 

> I see the argument for a change to be 3-fold:
>   

I am, however, sympathetic to the arguments for wanting floating-point 
defaults.   I wanted to change this originally but was convinced to not 
make such a major change for back-ward compatibility (more on that later). 

Nonetheless, I would support the creation of a module called something 
like defaultfloat or some-other equally impressive name ;-) which 
contained floating-point defaults of these functions (with the same 
names). 

Feel free to contribute (or at least find a better name). 


Regarding the problem of backward compatibility:

I am very enthused about the future of both NumPy and SciPy.  There have 
been a large number of new-comers to the community who have contributed 
impressively and I see very impressive things going on.    This is "a 
good thing" because these projects need many collaborators and 
contributors to be successful. 

However, I have not lost sight of the fact that we still have a major 
adoption campaign to win before declaring NumPy a success.  There are a 
lot of people who still haven't come-over from Numeric and numarray.     
Consider these download numbers:

Numeric-24.2 (released Nov. 11, 2005)

14275   py24.exe
 2905    py23.exe
 9144    tar.gz     

Numarray 1.5.1 (released Feb, 7, 2006)

10272   py24.exe
11883   py23.exe
12779   tar.gz

NumPy 0.9.8   (May 17, 2006)

 3713    py24.exe 
   558    py23.exe
 4111    tar.gz


While it is hard to read too much into numbers, this tells me that there 
are about 10,000 current users of Numeric/Numarray who have not even 
*tried* NumPy.  In fact, Numarray downloads of 1.5.1 went up 
significantly from its earlier  releases. Why is that?   It could be 
that many of the downloads are "casual" users who need it for some other 
application (in which case they wouldn't feel inclined to try NumPy).

On the other hand, it is also possible that many are still scared away 
by the pre-1.0 development-cycle --- it has been a bit bumpy for the 
stalwarts who've braved the rapids as NumPy has matured.  Changes like 
the proposal to move common functions from default integer to default 
float are exactly the kind of thing that leads people to wait on getting 
NumPy. 
 
One thing I've learned about Open Source development is that it can be 
hard to figure out exactly what is bothering people and get good 
critical feedback:  people are more likely to just walk away with their 
complaints than to try and verbalize and/or post them.    So, looking at 
adoption patterns can be a reasonable way to pick up on attitudes. 

It would appear that there is still a remarkable number of people who 
are either waiting for NumPy 1.0 or waiting for something else.  I'm not 
sure.   I think we have to wait until 1.0 to find out.  Therefore, 
bug-fixes and stabilizing the NumPy API is my #1 priority right now.

The other day I read a post by Alex Martelli (an influential Googler) to 
the Python list where he was basically suggesting that people stick with 
Numeric until things "stabilize".  I can hope he meant "until NumPy 1.0 
comes out"  but he didn't say that and maybe he meant "until the array 
in Python stabilizes."

I hope he doesn't mean the rumors about an array object in Python 
itself.  Let me be the first to assure everyone that rumors of a 
"capable" array object in Python have been greatly exaggerated.  I would 
be thrilled if we could just get the "infra-structure" into Python so 
that different extension modules could at least agree on an array 
interface.   That is a far cry from fulfilling the needs of any current 
Num user, however.

I say all this only to point out why de-stabilizing changes are 
difficult to do at this point, and to encourage anyone with an interest 
to continue to promote NumPy.   If you are at all grateful for its 
creation, then please try to encourage those whom you know to push for 
NumPy adoption (or at least a plan for its adoption) in the near future. 

Best regards,

-Travis

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

[James G. <jg...@ca...>]

Travis Oliphant wrote:
> Nonetheless, I would support the creation of a module called something 
> like defaultfloat or some-other equally impressive name ;-) which 
> contained floating-point defaults of these functions (with the same 
> names). 

I'd also like to see a way to make the constructors create floating-point arrays 
by default.

> Numeric-24.2 (released Nov. 11, 2005)
> 
> 14275   py24.exe
>  2905    py23.exe
>  9144    tar.gz     
> 
> Numarray 1.5.1 (released Feb, 7, 2006)
> 
> 10272   py24.exe
> 11883   py23.exe
> 12779   tar.gz
> 
> NumPy 0.9.8   (May 17, 2006)
> 
>  3713    py24.exe 
>    558    py23.exe
>  4111    tar.gz
> 
> 
> While it is hard to read too much into numbers, this tells me that there 
> are about 10,000 current users of Numeric/Numarray who have not even 
> *tried* NumPy.  In fact, Numarray downloads of 1.5.1 went up 
> significantly from its earlier  releases. Why is that?   It could be 
> that many of the downloads are "casual" users who need it for some other 
> application (in which case they wouldn't feel inclined to try NumPy).
> 
> On the other hand, it is also possible that many are still scared away 
> by the pre-1.0 development-cycle --- it has been a bit bumpy for the 
> stalwarts who've braved the rapids as NumPy has matured.  Changes like 
> the proposal to move common functions from default integer to default 
> float are exactly the kind of thing that leads people to wait on getting 
> NumPy. 

(just as an aside, a further possibility is the relative availability of 
documentation for numpy and the other array packages. I entirely understand the 
reasoning behind the Guide to NumPy being a for-money offering but it does 
present a significant barrier to adoption, particularly in an environment where 
the alternatives all offer for-free documentation above and beyond what is 
available in the docstrings).

-- 
"You see stars that clear have been dead for years
But the idea just lives on..." -- Bright Eyes

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

[Bruce S. <bso...@gm...>]

Hi,
You should be encouraged by the trend from Numeric to numarray because
the tar users clearly are prepared to upgrade.

In terms of the education program, the 1.0 release is the best
starting point as there is a general phobia for pre-1.0 releases (and
dot zero releases).

Also, Python 2.5 is coming so it probably a good time to attempt to
educate the exe users on numpy. One way is to provide numpy first (it
may be a little too harsh to say only) so people see it when they
upgrade.

There are two key aspects that are probably very much related that
needs to happen with the 1.0 release:
1) Identify those "[s]econdary dependency" projects as Louis states
(BioPython also comes to mind) and get them to convert.
2) Get the major distros (e.g. openSUSE) to include numpy and not
Numeric. In turn this should also make people who packages (like rpms)
also use numpy.

This may mean having to support both Numeric and numpy in the initial phase.

Regards
Bruce


On 6/30/06, Travis Oliphant <oli...@ie...> wrote:
> Alan G Isaac wrote:
> > On Thu, 29 Jun 2006, Travis Oliphant apparently wrote:
> >
> >> Please make any comments or voice major concerns
> >>
> >
> > A rather minor issue, but I would just like to make sure
> > that a policy decision was made not to move to a float
> > default for identity(), ones(), zeros(), and empty().
> > (I leave aside arange().)
> >
>
> This was a policy decision made many months ago after discussion on this
> list and would need over-whelming pressure to change.
>
> > I see the argument for a change to be 3-fold:
> >
>
> I am, however, sympathetic to the arguments for wanting floating-point
> defaults.   I wanted to change this originally but was convinced to not
> make such a major change for back-ward compatibility (more on that later).
>
> Nonetheless, I would support the creation of a module called something
> like defaultfloat or some-other equally impressive name ;-) which
> contained floating-point defaults of these functions (with the same
> names).
>
> Feel free to contribute (or at least find a better name).
>
>
> Regarding the problem of backward compatibility:
>
> I am very enthused about the future of both NumPy and SciPy.  There have
> been a large number of new-comers to the community who have contributed
> impressively and I see very impressive things going on.    This is "a
> good thing" because these projects need many collaborators and
> contributors to be successful.
>
> However, I have not lost sight of the fact that we still have a major
> adoption campaign to win before declaring NumPy a success.  There are a
> lot of people who still haven't come-over from Numeric and numarray.
> Consider these download numbers:
>
> Numeric-24.2 (released Nov. 11, 2005)
>
> 14275   py24.exe
>  2905    py23.exe
>  9144    tar.gz
>
> Numarray 1.5.1 (released Feb, 7, 2006)
>
> 10272   py24.exe
> 11883   py23.exe
> 12779   tar.gz
>
> NumPy 0.9.8   (May 17, 2006)
>
>  3713    py24.exe
>    558    py23.exe
>  4111    tar.gz
>
>
> While it is hard to read too much into numbers, this tells me that there
> are about 10,000 current users of Numeric/Numarray who have not even
> *tried* NumPy.  In fact, Numarray downloads of 1.5.1 went up
> significantly from its earlier  releases. Why is that?   It could be
> that many of the downloads are "casual" users who need it for some other
> application (in which case they wouldn't feel inclined to try NumPy).
>
> On the other hand, it is also possible that many are still scared away
> by the pre-1.0 development-cycle --- it has been a bit bumpy for the
> stalwarts who've braved the rapids as NumPy has matured.  Changes like
> the proposal to move common functions from default integer to default
> float are exactly the kind of thing that leads people to wait on getting
> NumPy.
>
> One thing I've learned about Open Source development is that it can be
> hard to figure out exactly what is bothering people and get good
> critical feedback:  people are more likely to just walk away with their
> complaints than to try and verbalize and/or post them.    So, looking at
> adoption patterns can be a reasonable way to pick up on attitudes.
>
> It would appear that there is still a remarkable number of people who
> are either waiting for NumPy 1.0 or waiting for something else.  I'm not
> sure.   I think we have to wait until 1.0 to find out.  Therefore,
> bug-fixes and stabilizing the NumPy API is my #1 priority right now.
>
> The other day I read a post by Alex Martelli (an influential Googler) to
> the Python list where he was basically suggesting that people stick with
> Numeric until things "stabilize".  I can hope he meant "until NumPy 1.0
> comes out"  but he didn't say that and maybe he meant "until the array
> in Python stabilizes."
>
> I hope he doesn't mean the rumors about an array object in Python
> itself.  Let me be the first to assure everyone that rumors of a
> "capable" array object in Python have been greatly exaggerated.  I would
> be thrilled if we could just get the "infra-structure" into Python so
> that different extension modules could at least agree on an array
> interface.   That is a far cry from fulfilling the needs of any current
> Num user, however.
>
> I say all this only to point out why de-stabilizing changes are
> difficult to do at this point, and to encourage anyone with an interest
> to continue to promote NumPy.   If you are at all grateful for its
> creation, then please try to encourage those whom you know to push for
> NumPy adoption (or at least a plan for its adoption) in the near future.
>
> Best regards,
>
> -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
>

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

[Jon W. <wr...@es...>]

Travis Oliphant wrote:

>I hope he doesn't mean the rumors about an array object in Python 
>itself.  Let me be the first to assure everyone that rumors of a 
>"capable" array object in Python have been greatly exaggerated.  I would 
>be thrilled if we could just get the "infra-structure" into Python so 
>that different extension modules could at least agree on an array 
>interface.   That is a far cry from fulfilling the needs of any current 
>Num user, however.
>  
>
Having {pointer + dimensions + strides + type} in the python core would 
be an incredible step forward - this is far more important than changing 
my python code to do functionally the same thing with numpy instead of 
Numeric. If the new array object supports most of the interface of the 
current "array" module then it is already very capable for many tasks. 
It would be great if it also works with Jython (etc).

Bruce Southley wrote:

>1) Identify those "[s]econdary dependency" projects as Louis states
>(BioPython also comes to mind) and get them to convert.
>
As author of a (fairly obscure) secondary dependency package it is not 
clear that this is right time to convert. I very much admire the 
matplotlib approach of using Numerix and see this as a better solution 
than switching (or indeed re-writing in java/c++ etc). However, looking 
into the matplotlib SVN I see:

_image.cpp      2420      4 weeks      cmoad      applied Andrew Straw's 
numpy patch
numerix/_sp_imports.py      2478      2 weeks      teoliphant      Make 
recent changes backward compatible with numpy 0.9.8
numerix/linearalgebra/__init__.py      2474      2 weeks      teoliphant 
     Fix import error for new numpy

While I didn't look at either the code or the diff the comments clearly 
read as: "DON'T SWITCH YET". Get the basearray into the python core and 
for sure I will be using that, whatever it is called. I was tempted to 
switch to numarray in the past because of the nd_image, but I don't see 
that in numpy just yet?

Seeing this on the mailing list:

>So far the vote is 8 for float, 1 for int.
>
... is yet another hint that I can remain with Numeric as a library, at 
least until numpy has a frozen interface/behaviour.

I am very supportive of the work going on but have some technical 
concerns about switching. To pick some examples, it appears that 
numpy.lib.function_base.median makes a copy, sorts and picks the middle 
element. Some reading at http://ndevilla.free.fr/median/median/index.html
or even (eek!) numerical recipes indicates this is not good news. Not to 
single one routine out, I was also saddened to find both Numeric and 
numpy use double precision lapack routines for single precision 
arguments. A diff of numpy's linalg.py with Numeric's LinearAlgebra.py 
goes a long way to explaining why there is resistance to change from 
Numeric to numpy. The boilerplate changes and you only get "norm" (which 
I am suspicious about - vector 2 norms are in blas, some matrix 2 norms 
are in lapack/*lange.f and computing all singular values when you only 
want the biggest or smallest one is a surprising algorithmic choice). I 
realise it might sound like harsh criticism - but I don't see what numpy 
adds for number crunching over and above Numeric. Clearly there *is* a 
lot more in terms of python integration, but I really don't want to do 
number crunching with python itself ;-)

For numpy to really be better than Numeric I would like to find 
algorithm selections according to the array dimensions and type. Getting 
the basearray type into the python core is the key - then it makes sense 
to get the best of breed algorithms working as you can rely on the 
basearray being around for many years to come.

Please please please get basearray into the python core! How can we help 
with that?


Jon

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

[Louis C. <lco...@po...>]

> Numeric-24.2 (released Nov. 11, 2005)
>
> 14275   py24.exe
> 2905    py23.exe
> 9144    tar.gz
>
> Numarray 1.5.1 (released Feb, 7, 2006)
>
> 10272   py24.exe
> 11883   py23.exe
> 12779   tar.gz
>
> NumPy 0.9.8   (May 17, 2006)
>
> 3713    py24.exe
>   558    py23.exe
> 4111    tar.gz

Here is some trends with a pretty picture.

http://www.google.com/trends?q=numarray%2C+NumPy%2C+Numeric+Python

Unfortunatle Numeric alone is to general a term to use.
But I would say NumPy is looking good. ;)


-- 
Louis Cordier <lco...@po...> cell: +27721472305
Point45 Entertainment (Pty) Ltd. http://www.point45.org

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

[Christopher B. <Chr...@no...>]

Robert Kern wrote:
> Whatever else you do, leave arange() alone. It should never have accepted floats 
> in the first place.

Just to make sure we're clear: Because one should use linspace() for that?

If so, this would be the time to raise an error (or at least a 
deprecation warning) when arange() is called with Floats.

I have a LOT of code that does that! In fact, I posted a question here 
recently and got a lot of answers and suggested code, and not one person 
suggested that I shouldn't use arange() with floats.

Did Numeric have linspace() It doesn't look like it to me.

-Chris




-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

[Robert K. <rob...@gm...>]

Christopher Barker wrote:
> Robert Kern wrote:
>> Whatever else you do, leave arange() alone. It should never have accepted floats 
>> in the first place.
> 
> Just to make sure we're clear: Because one should use linspace() for that?

More or less. Depending on the step and endpoint that you choose, it can be 
nearly impossible for the programmer to predict how many elements are going to 
be generated.

> If so, this would be the time to raise an error (or at least a 
> deprecation warning) when arange() is called with Floats.
> 
> I have a LOT of code that does that! In fact, I posted a question here 
> recently and got a lot of answers and suggested code, and not one person 
> suggested that I shouldn't use arange() with floats.

I should have been more specific, but I did express disapproval in the code 
sample I gave:

   x = arange(minx, maxx+step, step)  # oy.

Since your question wasn't about that specifically, I used the technique that 
your original sample did.

> Did Numeric have linspace() It doesn't look like it to me.

It doesn't. It was originally contributed to Scipy by Fernando, IIRC. It's 
small, so it is easy to copy if you need to maintain support for Numeric, still.

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

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

[Charles R H. <cha...@gm...>]

All,

This is bit off topic, but a while ago there were some complaints about the
usefulness of distutils. I note that KDE has gone over to using cmake after
trying scon. I am not familiar with cmake, but perhaps someone here knows
more and can comment on its suitability.

Chuck

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

[Robert K. <rob...@gm...>]

Charles R Harris wrote:
> All,
> 
> This is bit off topic, but a while ago there were some complaints about 
> the usefulness of distutils. I note that KDE has gone over to using 
> cmake after trying scon. I am not familiar with cmake, but perhaps 
> someone here knows more and can comment on its suitability.

None at all. I have nightmares about it every time I need to rebuild VTK.

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

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

[Albert S. <fu...@gm...>]

Hey Chuck

> -----Original Message-----
> From: num...@li... [mailto:numpy-
> dis...@li...] On Behalf Of Charles R Harris
> Sent: 01 July 2006 19:57
> To: Robert Kern
> Cc: num...@li...
> Subject: Re: [Numpy-discussion] Time for beta1 of NumPy 1.0
> 
> All,
> 
> This is bit off topic, but a while ago there were some complaints about
> the usefulness of distutils. I note that KDE has gone over to using cmake
> after trying scon. I am not familiar with cmake, but perhaps someone here
> knows more and can comment on its suitability.

CMake definately warrants investigation, but I think SCons might be a better
way to go. I think it would make it easier to reuse large parts of the
existing build code (e.g. conv_template.py could be converted into a SCons
builder without too much effort). Reusing parts of distutils and setuptools
would also be easier if the new tool is somehow Python-aware.

I think the main problem with distutils in the NumPy context is that it was
never designed to build C/Fortran code over so many platforms with to many
possible build configurations. python setup.py install works pretty well,
but any kind of non-default configuration can become a bit hairy, despite
the excellent work on NumPy extensions to distutils.

I'd like to take a stab at doing something with SCons in a few weeks' time.
Does anybody want to brainstorm on some ideas for what is needed from a
better build system for NumPy? Maybe a wiki page?

Regards,

Albert

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

[Bruce S. <bso...@gm...>]

Hi,
Linux Weekly News (http://lwn.net) had an very interesting article on
KDE's switch on June 19, 2006 by Alexander Neundorf:

http://lwn.net/Articles/187923/

The full article is at:
http://lwn.net/Articles/188693/

This should be freely available to all.  Also, the current US Linux
Magazine (June or July 2006 ) has a small feature on cmake as well.

Regards
Bruce

On 7/1/06, Albert Strasheim <fu...@gm...> wrote:
> Hey Chuck
>
> > -----Original Message-----
> > From: num...@li... [mailto:numpy-
> > dis...@li...] On Behalf Of Charles R Harris
> > Sent: 01 July 2006 19:57
> > To: Robert Kern
> > Cc: num...@li...
> > Subject: Re: [Numpy-discussion] Time for beta1 of NumPy 1.0
> >
> > All,
> >
> > This is bit off topic, but a while ago there were some complaints about
> > the usefulness of distutils. I note that KDE has gone over to using cmake
> > after trying scon. I am not familiar with cmake, but perhaps someone here
> > knows more and can comment on its suitability.
>
> CMake definately warrants investigation, but I think SCons might be a better
> way to go. I think it would make it easier to reuse large parts of the
> existing build code (e.g. conv_template.py could be converted into a SCons
> builder without too much effort). Reusing parts of distutils and setuptools
> would also be easier if the new tool is somehow Python-aware.
>
> I think the main problem with distutils in the NumPy context is that it was
> never designed to build C/Fortran code over so many platforms with to many
> possible build configurations. python setup.py install works pretty well,
> but any kind of non-default configuration can become a bit hairy, despite
> the excellent work on NumPy extensions to distutils.
>
> I'd like to take a stab at doing something with SCons in a few weeks' time.
> Does anybody want to brainstorm on some ideas for what is needed from a
> better build system for NumPy? Maybe a wiki page?
>
> Regards,
>
> Albert
>
>
> 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
>

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

[David C. <da...@ar...>]

Albert Strasheim wrote:
> Hey Chuck
>
>   
>> -----Original Message-----
>> From: num...@li... [mailto:numpy-
>> dis...@li...] On Behalf Of Charles R Harris
>> Sent: 01 July 2006 19:57
>> To: Robert Kern
>> Cc: num...@li...
>> Subject: Re: [Numpy-discussion] Time for beta1 of NumPy 1.0
>>
>> All,
>>
>> This is bit off topic, but a while ago there were some complaints about
>> the usefulness of distutils. I note that KDE has gone over to using cmake
>> after trying scon. I am not familiar with cmake, but perhaps someone here
>> knows more and can comment on its suitability.
>>     
>
> CMake definately warrants investigation, but I think SCons might be a better
> way to go. I think it would make it easier to reuse large parts of the
> existing build code (e.g. conv_template.py could be converted into a SCons
> builder without too much effort). Reusing parts of distutils and setuptools
> would also be easier if the new tool is somehow Python-aware.
>
> I think the main problem with distutils in the NumPy context is that it was
> never designed to build C/Fortran code over so many platforms with to many
> possible build configurations. python setup.py install works pretty well,
> but any kind of non-default configuration can become a bit hairy, despite
> the excellent work on NumPy extensions to distutils.
>
> I'd like to take a stab at doing something with SCons in a few weeks' time.
> Does anybody want to brainstorm on some ideas for what is needed from a
> better build system for NumPy? Maybe a wiki page?
>   
I have a small experience with scons, as a replacement of the auto* 
tools for small packages
on my own (requirements for cross-building, library and header 
dependency, build of libraries, etc...). So I am willing to share my 
somewhat limited experience with scons (the code I am building scons 
with is using cblas/clapack, and has libraries + some unit testing, so 
we would not start from scratch). Also, I have access to x86 and ppc 
linux + mac os x + windows easily, which makes it easy to test on some 
common platforms,

David

P.S: Some comments on scons :

I don't know distutils, so I can only compare to autotools: from *my* 
experience, you should think about scons as a Makefile replacement, and 
as a build framework to build onto. The main pro of scons:

 - having a real language for build rules programming is a real plus. It 
makes it much easier to extend that autoconf, for example (debugging m4 
macro is not something I can enjoy much, and I am sure I am not alone).
- the dependency checking works great
- parallel build is explicitly handled
- scons knows how to build library (static and shared) on the plateforms 
it supports
- can be included in the project so scons does not need to be installed 
if needed (I have never used this feature myself).

The main cons:
 - configuration part: there are some tools to test library/header a la 
autoconf, but this is far from great in the present situation, mainly 
because of the next point
 - option handling from the command line: there is some support, but 
nothing is automatic. On the long run, this is painful.
 - No support for library versioning; I am not sure about rpath support, 
which is useful for non-standard path installation. I don't know how 
difficult it would be to implement for all platforms (I have some
 - can be slow for big projects ? I have seen quite big projects (eg 
ardour: several hundred of .c and .h files) using scons, and it was not 
really slow, and I don't think it would be a problem for something like 
numpy which size is nothing compared to kde.

To sum it up: as a make replacement, from a developer POV, it works 
great. As a tool for *distribution*, I am less convinced. For people 
familiar with autotools, scons is a great automake replacement. 
Everything else has to be implemented: autoconf, libtool, etc... My 
understanding is that those two tools (autoconf and libtool) are the 
ones most needed for numpy, so there is a lot of work to do if we want 
to use scons.

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

[Robert K. <rob...@gm...>]

Albert Strasheim wrote:
> I'd like to take a stab at doing something with SCons in a few weeks' time.
> Does anybody want to brainstorm on some ideas for what is needed from a
> better build system for NumPy? Maybe a wiki page?

I strongly believe that we need to be using whatever build system is the 
standard for Python packages. I'm happy to see distutils go away in favor of 
something better, but that "something better" needs to be actively promoted as 
*the* replacement for distutils for *all* Python packages, not just numpy.

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

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

[Sasha <nd...@ma...>]

On 7/1/06, Robert Kern <rob...@gm...> wrote:
> ...
> I strongly believe that we need to be using whatever build system is the
> standard for Python packages. I'm happy to see distutils go away in favor of
> something better, but that "something better" needs to be actively promoted as
> *the* replacement for distutils for *all* Python packages, not just numpy.
>

I strongly agree.  Distutils is in such a bad shape partially because
extension packages either not use distutils or extend distutils in
non-standard ways.  Python-dev is not an easy crowd to deal with, but
in the long run investing effort in improving core distutils will pay
off.

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

[Paulo J. S. S. <pjs...@im...>]

+1 for float64.

I'll teach Introduction to Numerical Linear Algebra next term and I will
use numpy!

Best,

Paulo
-- 
Paulo José da Silva e Silva 
Professor Assistente do Dep. de Ciência da Computação
(Assistant Professor of the Computer Science Dept.)
Universidade de São Paulo - Brazil

e-mail: pjssilva at ime.usp.br      Web: http://www.ime.usp.br/~pjssilva

Teoria é o que não entendemos o     (Theory is something we don't)
suficiente para chamar de prática.  (understand well enough to call
practice)

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

[Alan I. <ai...@am...>]

On Fri, 30 Jun 2006, Travis Oliphant wrote: 
> I am, however, sympathetic to the arguments for wanting 
> floating-point defaults.   I wanted to change this 
> originally but was convinced to not make such a major 
> change for back-ward compatibility (more on that later). 

Before 1.0, it seems right to go with the best design
and take some short-run grief for it if necessary.

If the right default is float, but extant code will be hurt,
then let float be the default and put the legacy-code fix 
(function redefinition) in the compatability module.

One view ...

Alan Isaac

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

[Steve L. <st...@ar...>]

> Before 1.0, it seems right to go with the best design
> and take some short-run grief for it if necessary.
>
> If the right default is float, but extant code will be hurt,
> then let float be the default and put the legacy-code fix
> (function redefinition) in the compatability module

+1 on this very idea.

(sorry for sending this directly to you @ first, Alan)

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

[Keith G. <kwg...@gm...>]

On 6/29/06, Alan G Isaac <ai...@am...> wrote:
> On Thu, 29 Jun 2006, Travis Oliphant apparently wrote:
> > Please make any comments or voice major concerns
>
> A rather minor issue, but I would just like to make sure
> that a policy decision was made not to move to a float
> default for identity(), ones(), zeros(), and empty().
> (I leave aside arange().)
>
> I see the argument for a change to be 3-fold:
> 1. It is easier to introduce people to numpy if
>    default data types are all float.  (I teach,
>    and I want my students to use numpy.)
> 2. It is a better match to languages from which
>    users are likely to migrate (e.g., GAUSS or
>    Matlab).
> 3. In the uses I am most familiar with, float is
>    the most frequently desired data type.  (I guess
>    this may be field specific, especially for empty().)

So far the vote is 8 for float, 1 for int.

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

[Glen W. M. <Gle...@sw...>]

On Fri, Jun 30, 2006 at 07:15:39AM -0700, Keith Goodman wrote:
> So far the vote is 8 for float, 1 for int.

+1 for float64.

Glen

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

[Tim H. <tim...@co...>]

Regarding choice of float or int for default:

The number one priority for numpy should be to unify the three disparate 
Python numeric packages. Whatever choice of defaults facilitates that is 
what I support.

Personally, given no other constraints, I would probably just get rid of 
the defaults all together and make the user choose.

-tim

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

[Keith G. <kwg...@gm...>]

On 6/29/06, Alan G Isaac <ai...@am...> wrote:
> On Thu, 29 Jun 2006, Travis Oliphant apparently wrote:
> > Please make any comments or voice major concerns
>
> A rather minor issue, but I would just like to make sure
> that a policy decision was made not to move to a float
> default for identity(), ones(), zeros(), and empty().
> (I leave aside arange().)
>
> I see the argument for a change to be 3-fold:
> 1. It is easier to introduce people to numpy if
>    default data types are all float.  (I teach,
>    and I want my students to use numpy.)
> 2. It is a better match to languages from which
>    users are likely to migrate (e.g., GAUSS or
>    Matlab).
> 3. In the uses I am most familiar with, float is
>    the most frequently desired data type.  (I guess
>    this may be field specific, especially for empty().)

I vote float.

Re: [Numpy-discussion] Time for beta1 of NumPy 1.0

[Sasha <nd...@ma...>]

I vote for no change.  It will be a major backward compatibility
headache with applications that rely on integer arrays breaking in
mysterious ways. If float wins, I hope there will be a script to
update old code. Detecting single argument calls to these functions is
probably not very hard.

On 6/29/06, Keith Goodman <kwg...@gm...> wrote:
> On 6/29/06, Alan G Isaac <ai...@am...> wrote:
> > On Thu, 29 Jun 2006, Travis Oliphant apparently wrote:
> > > Please make any comments or voice major concerns
> >
> > A rather minor issue, but I would just like to make sure
> > that a policy decision was made not to move to a float
> > default for identity(), ones(), zeros(), and empty().
> > (I leave aside arange().)
> >
> > I see the argument for a change to be 3-fold:
> > 1. It is easier to introduce people to numpy if
> >    default data types are all float.  (I teach,
> >    and I want my students to use numpy.)
> > 2. It is a better match to languages from which
> >    users are likely to migrate (e.g., GAUSS or
> >    Matlab).
> > 3. In the uses I am most familiar with, float is
> >    the most frequently desired data type.  (I guess
> >    this may be field specific, especially for empty().)
>
> I vote float.
>
> 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
>