numpy-discussion — Discussion list for all users of Numerical Python

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

[Scott R. <sr...@nr...>]

+1 for float64 for me as well.

Scott

On Fri, Jun 30, 2006 at 10:29:42AM -0400, Darren Dale wrote:
> +1 for float64
> 
> 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

-- 
-- 
Scott M. Ransom            Address:  NRAO
Phone:  (434) 296-0320               520 Edgemont Rd.
email:  sr...@nr...             Charlottesville, VA 22903 USA
GPG Fingerprint: 06A9 9553 78BE 16DB 407B  FFCA 9BFA B6FF FFD3 2989

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

[Erin S. <eri...@gm...>]

On 6/30/06, Erin Sheldon <eri...@gm...> wrote:
>    http://www.numpy.org/    -- is empty
I see this is now pointing to the sourceforge site. Must have been a
glitch there earlier as it was returning an empty page.

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

[Darren D. <dd...@co...>]

+1 for float64

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

[Erin S. <eri...@gm...>]

On 6/30/06, Simon Burton <si...@ar...> wrote:
>
> General confusion in the community. The whole numeric->numarray->numpy story
> is a little strange for people to believe. Or at least the source for
> many jokes.
> Also, there is no mention of numpy on the numarray page. The whole
> thing smells a little fishy :)

I can say that coming to numpy early this year I was confused
by this, and in fact I began by using numarray because the documentation
was available and clearly written.  I now support Travis on his book,
since none of this would be happening so rapidly without him, but as
I was looking for relief from my IDL license woes this turned me off a bit.

>From Googling, It just wasn't clear which was the future, especially since
as I dug deeper  I saw old references to numpy that were not referring
to the current project. I do think that this is more clear now, but the pages

   http://numeric.scipy.org/  --  Looks antiquated
   http://www.numpy.org/    -- is empty

are  not helping.  numeric.scipy.org needs to be converted to the
wiki look and feel of the rest of scipy.org, or at least made to look
modern.  numpy.org should point to the new page perhaps.  And
the numarray page should at least discuss the move to numpy
and have links.

Erin

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

[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

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

[Numpy-discussion] iterate along a ray: linear algebra?

[stephen e. <ste...@gm...>]

I am in the process of implementing an image processing algorithm that
requires following rays extending outwards from a starting point and
calculating the intensity derivative at each point. The idea is to find the
point where the difference in intensity goes beyond a particular threshold.

Specifically I'm examining an image of an eye to find the pupil, and the
edge of the pupil is a sharp change in intensity.

How does one iterate along a line in a 2d matrix, and is there a better way
to do this? Is this a problem that linear algebra can help with?

Thanks
Stephen Emslie

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

[Paul B. <peb...@gm...>]

On 6/30/06, Louis Cordier <lco...@po...> wrote:
>
> > 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).
>
> Secondary dependency of other projects maybe ?
> http://www.google.com/search?q=requires+Numeric+python
>
> My money is on Spambayes...
>
> On the other hand ;) isn't small numbers a good thing,
> thus the people using NumPy over Numeric/numarray knows
> that some things in NumPy might still change and thus
> their code as well.
>
> I'll risk to say their projects are probably also still
> under active development.
>
> So now would probably be the best time to make these
> type of changes. Stated differently, how would we like
> NumPy to function 2 years from now ?
>
> With float64's or with int's ? Then we should rather
> change it now.
>
> Then again where are NumPy in a crossing the chasm
> (http://en.wikipedia.org/wiki/Crossing_the_Chasm)
> sense of way, visionary or pragmatist ?
>
> Just a few random thoughts.
>
> Regards, Louis.
>
> --
> Louis Cordier <lco...@po...> cell: +27721472305
> Point45 Entertainment (Pty) Ltd. http://www.point45.org
>
>
> 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
>

+1 for float64

If we want to make Numpy the premier numerical analysis environment,
then let's get it right. I've been bitten too many times by IDL's
float32 default and Numeric's/Numarray's int32.  If backward
compatibility is the most important requirement then there would be no
reason to write Numpy.  There, I've said it.

 -- Paul

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

[Simon B. <si...@ar...>]

On Fri, 30 Jun 2006 03:33:56 -0600
Travis Oliphant <oli...@ie...> wrote:

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

General confusion in the community. The whole numeric->numarray->numpy story
is a little strange for people to believe. Or at least the source for
many jokes.
Also, there is no mention of numpy on the numarray page. The whole
thing smells a little fishy :)

Mose of the (more casual) users of python for science that i talk to are quite confused about
what is going on. It also "looks" like numpy is only a few months old.

Personally, I am ready to evangelise numpy wherever i can. (eg. Europython in 4 days time:) )

Simon.

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
>

[Numpy-discussion] MDP-2.0 released

[Tiziano Z. <t....@bi...>]

MDP version 2.0 has been released!

What is it?
-----------
Modular toolkit for Data Processing (MDP) is a data processing
framework written in Python.

 From the user's perspective, MDP consists of a collection of trainable
supervised and unsupervised algorithms that can be combined into data
processing flows. The base of readily available algorithms includes
Principal Component Analysis, two flavors of Independent Component
Analysis, Slow Feature Analysis, Gaussian Classifiers, Growing Neural
Gas, Fisher Discriminant Analysis, and Factor Analysis.

 From the developer's perspective, MDP is a framework to make the
implementation of new algorithms easier. MDP takes care of tedious
tasks like numerical type and dimensionality checking, leaving the
developer free to concentrate on the implementation of the training
and execution phases. The new elements then automatically integrate
with the rest of the library.

 As its user base is increasing, MDP might be a good candidate
for becoming a common repository of user-supplied, freely available,
Python implemented data processing algorithms.

Resources
---------
Download: http://sourceforge.net/project/showfiles.php?group_id=116959
Homepage: http://mdp-toolkit.sourceforge.net
Mailing list: http://sourceforge.net/mail/?group_id=116959

What's new in version 2.0?
--------------------------
MDP 2.0 introduces some important structural changes.  
 
 It is now possible to implement nodes with multiple training phases
and even nodes with an undetermined number of phases. This allows for
example the implementation of algorithms that need to collect some
statistics on the whole input before proceeding with the actual
training, or others that need to iterate over a training phase until a
convergence criterion is satisfied. The ability to train each phase
using chunks of input data is maintained if the chunks are generated
with iterators.

 Nodes that require supervised training can be defined in a very
straightforward way by passing additional arguments (e.g., labels or a
target output) to the 'train' method.
 
 New algorithms have been added, expanding the base of
readily available basic data processing elements. 

 MDP is now based exclusively on the NumPy Python numerical extension. 

--

 Tiziano Zito
 Institute for Theoretical Biology
 Humboldt-Universitaet zu Berlin  
 Invalidenstrasse, 43
 D-10115 Berlin, Germany

 Pietro Berkes
 Gatsby Computational Neuroscience Unit
 Alexandra House, 17 Queen Square
 London WC1N 3AR, United Kingdom

Re: [Numpy-discussion] Bug in digitize function

[Stefan v. d. W. <st...@su...>]

Hi David

On Thu, Jun 29, 2006 at 02:42:51PM -0400, David Huard wrote:
> Here is something I noticed with digitize() that I guess would qualify =
as a
> small but annoying bug.
>=20
> In [165]: x =3D rand(10); bin =3D linspace(x.min(), x.max(), 10); print=
 x.min();
> print bin[0]; digitize(x,bin)
> 0.0925030184144
> 0.0925030184144
> Out[165]: array([2, 9, 5, 9, 6, 1, 1, 1, 4, 5])
>=20
> In [166]: x =3D rand(10); bin =3D linspace(x.min(), x.max(), 10); print=
 x.min();
> print bin[0]; digitize(x,bin)
> 0.0209738428066
> 0.0209738428066
> Out[166]: array([ 5,  2,  8,  3,  0,  8,  9,  6, 10,  9])

Good catch! Fixed in SVN (along with docstring and test).

Cheers
St=E9fan

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

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

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

Secondary dependency of other projects maybe ?
http://www.google.com/search?q=requires+Numeric+python

My money is on Spambayes...

On the other hand ;) isn't small numbers a good thing,
thus the people using NumPy over Numeric/numarray knows
that some things in NumPy might still change and thus
their code as well.

I'll risk to say their projects are probably also still
under active development.

So now would probably be the best time to make these
type of changes. Stated differently, how would we like
NumPy to function 2 years from now ?

With float64's or with int's ? Then we should rather
change it now.

Then again where are NumPy in a crossing the chasm
(http://en.wikipedia.org/wiki/Crossing_the_Chasm)
sense of way, visionary or pragmatist ?

Just a few random thoughts.

Regards, Louis.

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

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

[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

[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] immediate fill after empty gives None.

[Johannes L. <a.u...@gm...>]

Hi,

> Opteron 64-bit, r2631 SVN.
>
> In [4]: depths_s2 = empty(shape=(5,),dtype=float)
> In [5]: depths_s2.fill(2.e5)
> In [6]: depths_s2
> Out[6]: array([ 200000.,  200000.,  200000.,  200000.,  200000.])
>
> In [11]: depths_s2 = (empty(shape=(5,),dtype=float)).fill(2.e5)
> In [12]: print depths_s2
> None

everything is fine. x.fill() fills x in-place and returns nothing. So in line 
11, you created an array, filled it with 2.e5, assigned the return value of 
fill() (=None) to depths_s2 and threw the array away.

HTH, Johannes

[Numpy-discussion] immediate fill after empty gives None.

[George N. <gn...@go...>]

Have I done something silly here, or is this a bug?

Opteron 64-bit, r2631 SVN.

In [4]: depths_s2 = empty(shape=(5,),dtype=float)
In [5]: depths_s2.fill(2.e5)
In [6]: depths_s2
Out[6]: array([ 200000.,  200000.,  200000.,  200000.,  200000.])

In [11]: depths_s2 = (empty(shape=(5,),dtype=float)).fill(2.e5)
In [12]: print depths_s2
None

--George Nurser.

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
> 

[Numpy-discussion] logspace behaviour/documentation

[Arnd B. <arn...@we...>]

Hi,

I am wondering a bit about the the behaviour of logspace:

Definition: numpy.logspace(start, stop, num=50, endpoint=True, base=10.0)

Reading this I would assume that
  numpy.logspace(10**-12, 0.0, 100)
gives 100 values, from start=10**-12 to stop=0.0,
equispaced on a logarithmic scale.
But this is not the case.
Instead one has to do:
  numpy.logspace(-12, 0.0, 100)

Docstring:
    Evenly spaced numbers on a logarithmic scale.

    Computes int(num) evenly spaced exponents from start to stop.
    If endpoint=True, then last exponent is stop.
    Returns base**exponents.

My impression is that only the very last line is clearly
saying what logspace does.
And of course the code itself:

    y = linspace(start,stop,num=num,endpoint=endpoint)
    return _nx.power(base,y)

Possible solutions (see below):
a) modify logspace so that numpy.logspace(10**-12, 0.0, 100) works
b) keep the current behaviour and improve the doc-string

I would be interested in opinions on this.

Best, Arnd


Possible solution for (a) (no error checking yet):

def logspace_modified(start, stop, num=50, endpoint=True):
    """Evenly spaced numbers on a logarithmic scale.

    Computes `num` evenly spaced numbers on a logarithmic scale
    from `start` to `stop`.
    If endpoint=True, then last exponent is `stop`.
    """
    lstart = log(start)
    lstop = log(stop)
    y = linspace(lstart, lstop, num=num, endpoint=endpoint)
    return exp(y)


Possible improvent of the doc-string (b) - due to Lars Bittrich:

def logspace(start,stop,num=50,endpoint=True,base=10.0):
    """Evenly spaced numbers on a logarithmic scale.

    Return 'int(num)' evenly spaced samples on a logarithmic scale from
    'base'**'start' to 'base'**'stop'.  If 'endpoint' is True, the
    last sample is 'base'**'stop'."""

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

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

On 6/29/06, Bill Baxter <wb...@gm...> wrote:
> Rand at least returns doubles:
>
> >>> num.rand(3,3).dtype.name
> 'float64'

Then I vote float64.

>> linalg.eigh(asmatrix(1))[0].dtype.name
'float64'

>> linalg.cholesky(asmatrix(1)).dtype.name
'float64'

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

[Bill B. <wb...@gm...>]

Rand at least returns doubles:

>>> num.rand(3,3).dtype.name
'float64'

--bb

On 6/30/06, Keith Goodman <kwg...@gm...> wrote:
>
> On 6/29/06, Bill Baxter <wb...@gm...> wrote:
> > I also find the int behavior of these functions strange.
> >
> > +1 float default (or double)
>
> Oh, wait. Which do I want, float or double? What does rand, eigh,
> lstsq, etc return?
>

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

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

On 6/29/06, Bill Baxter <wb...@gm...> wrote:
> I also find the int behavior of these functions strange.
>
> +1 float default (or double)

Oh, wait. Which do I want, float or double? What does rand, eigh,
lstsq, etc return?