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

[Numpy-discussion] recarray field names

[Erin S. <esh...@ki...>]

Hi everyone -

(sigh) These gmail issues are really annoying...so I apologize
if the gmail version of this message shows up in a few days.

I brought up the issue a while back of having a simple way to
access the field names of an array. The quick summary: accessing 
field names has some oddness that needs cleaning up.  

The argument that this is important isn't too hard to make: 
most astronomers work with lists of objects with a slew of
properties and these are most naturally stored in a recarray.
We use generic file formats like FITS that don't require the
user to know what is in the file ahead of time, but once the
data is read this information should be easily accessible, both
interactively and in code.  I'm sure similar arguments can be 
made for other users.   


Thanks,
Erin

On 3/15/06, Travis Oliphant <oli...@ee...> wrote:
- Hide quoted text -
> Fernando Perez wrote:
>
> >
> > Mmh, just curious: I wonder about the wisdom of that overloading of a
> > 'magic' key (-1).  It will make thinks like
> >
> > for name in t.dtype.fields:
>
>
> No real wisdom.  More organic growth.  Intially I didn't have an ordered
> list of fields, but as more complicated data-type descriptors were
> supported, this became an important thing to have.  I should have
> probably added a n additional element to the PyArray_Descr structure.
> Remember, it was growing out of the old PyArray_Descr already and I was
> a little concerned about changing it too much (there are ramifications
> of changing this structure in several places).
>
> So, instead of adding a "ordered_names" tuple to the dtype object, I
> just stuck it in the fields dictionary.  I agree it's kind of odd
> sitting there.
>
> It probably deserves a re-factoring and pulling that out into a new
> attribute of the dtype object.
>
> This would mean that the PyArray_Descr structure would need a new object
> (names perhaps), and it would need to be tracked.
>
> Not a huge change and probably worth it before the next release.
>
>
> -Travis

Re: [Numpy-discussion] What's wrong with matrices?

[Sven S. <sve...@gm...>]

JJ schrieb:

> -----------------------------------------
> Hello Ed:
> Here are a couple of examples off the top of my head:
> 
> a = mat(arange(10))
> a.shape = (5,2)
> b = a.copy()
> c = hstack((a,b))  # should return a matrix
> type(c)
> <type 'numpy.ndarray'>


This hstack bug has been fixed recently.

> 
> a[where(a[:,0]<6)[0],0]  #should return a column
> matrix([[0, 2, 4]])

Don't know anything about this stuff.

> 
> My version is about a month old, so maybe these are fixed.  Since we are on the
> topic, I dont understand why where() returns a tupple. To me, it just means
> adding an extra '[0]' in many places in my code.  I would vote for where()
> retuning a matrix (if matrix is the default in the session).  My comment on
> transpose of a 1,n matrix producing a n,1 matrix was in response to a vote
> question on the list.  

That discussion was about pure arrays, not the matrix subclass.


> matrix is the default for a session.  Lastly, this might not be the right place
> for this comment, but it would be nice if pylab allowed numpy matrices.  

I agree, that would be nice! Maybe we can team up and invade the
matplotlib mailing list some time ;-)

-sven

Re: [Numpy-discussion] NumPy beta release plan

[Gary R. <gr...@bi...>]

Hi Travis,

My suggestion: Because you said you want to do a feature freeze, this 
should be pretty easy to handle. Wait for a feature freeze point then 
create a 1.0 branch. From then, new stuff can continue going into the 
trunk. Bug fixes go into the trunk and the 1.0 branch.

Gary R.

Travis Oliphant wrote:
> Charles R Harris wrote:
>> Hi Travis,
>>
>> Are you going to make a development branch so other things can 
>> continue going into Numpy until the 1.0 release?
> Something like that is a good idea.   I'm open to suggestions...
> 
> -Travis

Re: [Numpy-discussion] What's wrong with matrices?

[JJ <jos...@ya...>]

Ed Schofield <schofield <at> ftw.at> writes:

> 
> 
> On 08/07/2006, at 10:22 PM, JJ wrote:
> 
> > 3)  In some operations, especially range selection operations, a N, 
> > 1 matrix is
> > turned into a 1,N matrix.  This is confusing relative to matlab and  
> > problematic,
> > in my view.
> 
> This sounds like a bug.  Can you give any examples of this happening  
> with the latest release or SVN version?
> 
> > <snip>
> >
> > 5)  If X is a 1,n matrix, then X.T should return a n,1 matrix, I  
> > think.
> 
> This should be the case.  Could you post a code snippet that violates  
> it?
> 
> Thanks for your feedback, JJ!
>--------------------------------------------------
Hi Ed:
Here are a couple more items:
c = cov(a)  # a is a matrix
type(c)  # should be a matrix
<type 'numpy.ndarray'>

Also, if a is 5x2, then cov(a) is 5,5.  Is that just a convention?  I would
expect the cov to be 2,2, as in matlab.  It means I have to use more transpose
methods.

D is a 1,n matrix
(D<2).nonzero()[0] 
As per my earlier comment on which(), I wish that .nonzero() did not return a
tupple.

Re: [Numpy-discussion] What's wrong with matrices?

[JJ <jos...@ya...>]

Ed Schofield <schofield <at> ftw.at> writes:

> 
> 
> On 08/07/2006, at 10:22 PM, JJ wrote:
> 
> > 3)  In some operations, especially range selection operations, a N, 
> > 1 matrix is
> > turned into a 1,N matrix.  This is confusing relative to matlab and  
> > problematic,
> > in my view.
> 
> This sounds like a bug.  Can you give any examples of this happening  
> with the latest release or SVN version?
> 
> > <snip>
> >
> > 5)  If X is a 1,n matrix, then X.T should return a n,1 matrix, I  
> > think.
> 
> This should be the case.  Could you post a code snippet that violates  
> it?
> 
> Thanks for your feedback, JJ!
> 
-----------------------------------------
Hello Ed:
Here are a couple of examples off the top of my head:

a = mat(arange(10))
a.shape = (5,2)
b = a.copy()
c = hstack((a,b))  # should return a matrix
type(c)
<type 'numpy.ndarray'>

a[where(a[:,0]<6)[0],0]  #should return a column
matrix([[0, 2, 4]])

My version is about a month old, so maybe these are fixed.  Since we are on the
topic, I dont understand why where() returns a tupple. To me, it just means
adding an extra '[0]' in many places in my code.  I would vote for where()
retuning a matrix (if matrix is the default in the session).  My comment on
transpose of a 1,n matrix producing a n,1 matrix was in response to a vote
question on the list.  Also, I would vote for X.A*Y.A to return a matrix, if
matrix is the default for a session.  Lastly, this might not be the right place
for this comment, but it would be nice if pylab allowed numpy matrices.  Then
code like:
plot(d.A.ravel().tolist())
could be changed to plot(d) 
Hope this is of some help.
JJ

Re: [Numpy-discussion] build problem: numpy with cygwin mingw

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

Hi Sebastian,

 > I just tried my first build  from a svn checkout on windows using
 > cygwin. I want to use the non cygwin python - i.e. the non-cygwin
 > (mingw) compiler more.
 > I get a presumably very basic error:
 > Even though I follow the simple instructions on
 > http://www.scipy.org/Installing_SciPy/Windows

did you apply the patch from ticket #114, as mentioned on top of that 
page? The Cygwin build is known not to work otherwise (due to incorrect 
compiler flags, as you noticed)...

Stephan

Re: [Numpy-discussion] Args for rand and randn: call for a vote

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

Ed Schofield wrote:
> On 09/07/2006, at 12:04 AM, Robert Kern wrote:
> 
>> I would like to ask about the purpose of calling for a vote, here.  
>> What
>> authority do you intend the result to have? If you are just asking  
>> for a straw
>> poll of opinions from the list to inform Travis' decision, do you  
>> think that he
>> hasn't read the previous discussions? Are previous non-participants  
>> being drawn
>> out of the woodwork? ...
> 
> No authority at all -- it's just a straw poll.  My intention is  
> merely to ascertain whether there's indeed a groundswell of public  
> opinion for this change among NumPy's users, as is my suspicion.   
 >
> Previous non-participants are indeed coming out of the woodwork.
> 
> The reason I've listed only one alternative to the status quo is that  
> this is a simple, concrete proposal that has bubbled up several times  
> from the discussion, which may have broad enough support to tip  
> Travis's decision.
> 
> I know that you, Robert, disagree with the proposal and have put  
> forward an alternative.  Fair enough, but let's now hear what others  
> have to say.

The problem I have is that the way this happened is ineffective at doing that 
honestly. Fogel's book has a good discussion about how these should be 
conducted. You can't just pick the options that are convenient for you. You 
can't argue for your favorite in the CFV. You should provide pointers to the 
previous discussions so that newcomers can understand what the arguments are. 
You should encourage people to come up with alternatives that might achieve 
consensus rather than just picking the ones on the ballot.

Otherwise, the poll just serves as rhetorical ploy, not a way to ascertain 
people's opinions.

-- 
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] What's wrong with matrices?

[Ed S. <sch...@ft...>]

On 08/07/2006, at 10:22 PM, JJ wrote:

> 3)  In some operations, especially range selection operations, a N, 
> 1 matrix is
> turned into a 1,N matrix.  This is confusing relative to matlab and  
> problematic,
> in my view.

This sounds like a bug.  Can you give any examples of this happening  
with the latest release or SVN version?


> <snip>
>
> 5)  If X is a 1,n matrix, then X.T should return a n,1 matrix, I  
> think.

This should be the case.  Could you post a code snippet that violates  
it?


Thanks for your feedback, JJ!

-- Ed

Re: [Numpy-discussion] Args for rand and randn: call for a vote

[Ed S. <sch...@ft...>]

On 09/07/2006, at 12:04 AM, Robert Kern wrote:

> Ed Schofield wrote:
>> Last week's discussion on rand() and randn() seemed to indicate a
>> sentiment that they ought to take tuples for consistency with ones,
>> zeros, eye, identity, and empty -- that, although they are supposed
>> to be convenience functions, they are inconvenient precisely because
>> of their inconsistency with these other functions.  This issue has
>> been raised many times over the past several months.
>>
>> Travis made a change in r2572 to allow tuples as arguments, then took
>> it out again a few hours later, apparently unsure about whether this
>> was a good idea.
>>
>> I'd like to call for a vote on what people would prefer, and then ask
>> Travis to make a final pronouncement before the feature freeze.
>
> I would like to ask about the purpose of calling for a vote, here.  
> What
> authority do you intend the result to have? If you are just asking  
> for a straw
> poll of opinions from the list to inform Travis' decision, do you  
> think that he
> hasn't read the previous discussions? Are previous non-participants  
> being drawn
> out of the woodwork? ...


No authority at all -- it's just a straw poll.  My intention is  
merely to ascertain whether there's indeed a groundswell of public  
opinion for this change among NumPy's users, as is my suspicion.   
Previous non-participants are indeed coming out of the woodwork.

The reason I've listed only one alternative to the status quo is that  
this is a simple, concrete proposal that has bubbled up several times  
from the discussion, which may have broad enough support to tip  
Travis's decision.

I know that you, Robert, disagree with the proposal and have put  
forward an alternative.  Fair enough, but let's now hear what others  
have to say.

-- Ed

Re: [Numpy-discussion] NumPy beta release plan

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

Charles R Harris wrote:
> Hi Travis,
>
> Are you going to make a development branch so other things can 
> continue going into Numpy until the 1.0 release?
Something like that is a good idea.   I'm open to suggestions...

-Travis

[Numpy-discussion] build problem: numpy with cygwin mingw

[Sebastian H. <ha...@ms...>]

Hi,
I just tried my first build  from a svn checkout on windows using 
cygwin. I want to use the non cygwin python - i.e. the non-cygwin 
(mingw) compiler more.
I get a presumably very basic error:
Even though I follow the simple instructions on
http://www.scipy.org/Installing_SciPy/Windows
calling
python.exe setup.py config --compiler=mingw32 build --compiler=mingw32 
bdist_wininst

I noticed that gcc gets called without the "-mno-cygwin".
 From this follows that  _WIN32 is not defined and than I get:
<copy-paste from cygwin>
Could not locate executable gfortran
Could not locate executable f95
customize GnuFCompiler
customize GnuFCompiler
customize GnuFCompiler using config
C compiler: gcc -O2 -Wall -Wstrict-prototypes

compile options: '-Ic:\python24\include -Inumpy\core\src 
-Inumpy\core\include -I
c:\python24\include -Ic:\python24\PC -c'
gcc -O2 -Wall -Wstrict-prototypes -Ic:\python24\include -Inumpy\core\src 
-Inumpy\core\include -Ic:\python24\include -Ic:\python24\PC -c 
_configtest.c -o _config
test.o
In file included from c:/python24/include/Python.h:82,
                  from _configtest.c:2:
c:/python24/include/intobject.h:41: error: parse error before 
"PyInt_AsUnsignedLongLongMask"
</copy-paste from cygwin>

The error in the last line I traced back to this line:
#define PY_LONG_LONG __int64
in pyconfig.h  which is used because
#if defined(__GNUC__) && defined(_WIN32)
is not true if gcc is called without "-mno-cygwin"

I don't have cygwin's python installed. I neither have cygwin's
non-mingw gcc installed....


According to http://www.python.org/doc/current/inst/tweak-flags.html
the --compiler=mingw32  should tell distutils to use the "Cygwin in 
no-cygwin mode"  !?!?

What's wrong here ?

Thanks
Sebastian Haase

PS: I don't even care about ATLAS... at this point
PPS:  Is there maybe a precompiled version later than 0.9.8 avaible !?

Re: [Numpy-discussion] Args for rand and randn: call for a vote

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

On Sat, Jul 08, 2006 at 06:15:25PM -0500, Robert Kern wrote:
> Pau Gargallo wrote:
> > On 7/8/06, Robert Kern <rob...@gm...> wrote:
> >> Ed Schofield wrote:
> >>> * Should numpy.rand and numpy.randn accept sequences of dimensions as
> >>> arguments, like rand((3,3)), as an alternative to rand(3,3)?
> >>> * Should rand((3,3)) and randn((3,3)) continue to raise a TypeError?
> >> This is a false dichotomy. There are more choices here.
> >>
> >> * Remove rand and randn (at least from the toplevel namespace) and promote the
> >> use of random_sample and standard_normal which already follow the tuple convention.
> > 
> > i just wanted to point out another possible choice:
> > 
> >   * enable numpy.rand((3,3)) and make numpy.rand(3,3) raise an error
> > as zeros and ones do.
> > 
> > I suppose that you all discussed a lot about this choice also, but it
> > still seems very reasonable to me :-(
> 
> Extensively! The problem I have with it is that there are already functions 
> which do exactly that. Why have two functions that do exactly the same thing 
> with exactly the same interface but different names? I say, pick one and get rid 
> of the other if you must remove rand(3,3).

Robert, what you say is a perfectly valid solution for the spirit
of the first selection.  My +1 vote was really for _some_
functions in the top level numpy namespace that take tuple "shape"
parameters as input and generate uniform and gaussian normal
random deviates.  

If those functions are random_sample (although that is a bad name,
IMO, "random" is better -- which is already in there) and
standard_normal that is fine by me.

The problem was (is?) that rand and randn are not consistent with
everything else.  _That_ is why people are having issues.

Scott

-- 
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] What's wrong with matrices?

[JJ <jos...@ya...>]

Hello.  My 2 cents may be late on this, but I do have some thoughts as a matlab
user switching over to numpy/scipy.  I will just list my points, and I have a
general question at the end.

1)  I vote for a simple way to allow matrices to be the default (vs arrays),
with all matrix operations/functions/range selections returning matrices.
2)  Allowing more than 2D matrices would be nice, but I dont need them often.
3)  In some operations, especially range selection operations, a N,1 matrix is
turned into a 1,N matrix.  This is confusing relative to matlab and problematic,
in my view.
3)  From my experience so far, range selection is by far the most problematic
part of using numpy.  In matlab, range selection is very easy and intuitive. 
For example, if X is a 10 x 5 matrix, a = X[X[:,1]<3,1:3] works just fine.  In
numpy it is much more confusing and the code to do this is relatively lengthy. 
It would be nice if range selection for a matrix could be done using any
combination of boolean and/or integer matrices (not lists or arrays,
necessarily).  For example, boolean selection for rows and integer selection for
columns.
4)  It would be very nice if range selection could be done with real numbers,
such as 1.0, 2.0, etc.  Matlab can do this and it makes the code much simpler.   
5)  If X is a 1,n matrix, then X.T should return a n,1 matrix, I think.

I guess thats my main points.  And now I have a question.  What do people think
about the role of numpy/scipy vs. R (other than one is python and one is not)? 
What are the benefits of numpy/scipy over R?  In the future, do numpy users want
stat libraries like R has?  Or put another way, when numpy/scipy is mature, when
would you use numpy and when would you use R?

Thanks.  JJ (John)

Re: [Numpy-discussion] Args for rand and randn: call for a vote

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

Pau Gargallo wrote:
> On 7/8/06, Robert Kern <rob...@gm...> wrote:
>> Ed Schofield wrote:
>>> * Should numpy.rand and numpy.randn accept sequences of dimensions as
>>> arguments, like rand((3,3)), as an alternative to rand(3,3)?
>>> * Should rand((3,3)) and randn((3,3)) continue to raise a TypeError?
>> This is a false dichotomy. There are more choices here.
>>
>> * Remove rand and randn (at least from the toplevel namespace) and promote the
>> use of random_sample and standard_normal which already follow the tuple convention.
> 
> i just wanted to point out another possible choice:
> 
>   * enable numpy.rand((3,3)) and make numpy.rand(3,3) raise an error
> as zeros and ones do.
> 
> I suppose that you all discussed a lot about this choice also, but it
> still seems very reasonable to me :-(

Extensively! The problem I have with it is that there are already functions 
which do exactly that. Why have two functions that do exactly the same thing 
with exactly the same interface but different names? I say, pick one and get rid 
of the other if you must remove rand(3,3).

-- 
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] Args for rand and randn: call for a vote

[Pau G. <pau...@gm...>]

On 7/8/06, Robert Kern <rob...@gm...> wrote:
> Ed Schofield wrote:
> > * Should numpy.rand and numpy.randn accept sequences of dimensions as
> > arguments, like rand((3,3)), as an alternative to rand(3,3)?
>
> > * Should rand((3,3)) and randn((3,3)) continue to raise a TypeError?
>
> This is a false dichotomy. There are more choices here.
>
> * Remove rand and randn (at least from the toplevel namespace) and promote the
> use of random_sample and standard_normal which already follow the tuple convention.
>

i just wanted to point out another possible choice:

  * enable numpy.rand((3,3)) and make numpy.rand(3,3) raise an error
as zeros and ones do.

I suppose that you all discussed a lot about this choice also, but it
still seems very reasonable to me :-(

pau

Re: [Numpy-discussion] Args for rand and randn: call for a vote

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

Ed Schofield wrote:
> Last week's discussion on rand() and randn() seemed to indicate a  
> sentiment that they ought to take tuples for consistency with ones,  
> zeros, eye, identity, and empty -- that, although they are supposed  
> to be convenience functions, they are inconvenient precisely because  
> of their inconsistency with these other functions.  This issue has  
> been raised many times over the past several months.
> 
> Travis made a change in r2572 to allow tuples as arguments, then took  
> it out again a few hours later, apparently unsure about whether this  
> was a good idea.
> 
> I'd like to call for a vote on what people would prefer, and then ask  
> Travis to make a final pronouncement before the feature freeze.

I would like to ask about the purpose of calling for a vote, here. What 
authority do you intend the result to have? If you are just asking for a straw 
poll of opinions from the list to inform Travis' decision, do you think that he 
hasn't read the previous discussions? Are previous non-participants being drawn 
out of the woodwork? Or do you intend the majority winner of the vote to force 
Travis' decision? In which case, who comprises the voting membership, and why?

Voting is a notoriously bad way to make decisions in software development. Open 
source did not change that. It should be a very rare occurrence and happen in 
very specific circumstances. Two CFVs in as many days is entirely unreasonable. 
And when a vote *is* taken, it should be done with much more care than I think 
you are showing here (specifically, a CFV should not be making the case for only 
one of the choices).

Karl Fogel's book _Producing Open Source Software_ thoroughly discusses these 
issues:

   http://producingoss.com/html-chunk/consensus-democracy.html#voting

-- 
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] .M .A .T .H attribute result

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

Hi all,

On 7/8/06, Fernando Perez <fpe...@gm...> wrote:
>
> Hi all,
>
> On 7/7/06, Travis Oliphant <oli...@ee...> wrote:
> >
> > I didn't compile the results, but the discussion on the idea of adding
> > new attributes to the array object led to the following result.
> >
> > Added:  .T attribute to mean self.transpose()
>
> [...]
>
> > .H
> >
> > A few were in favor, but this can now be written .T.conj()  which is not
> > bad so does not get a new attribute.
>
> I didn't have strong feelings one way or another on this, so I didn't
> vote, but at this point I'd like to make a comment before the freeze.
> Given that .T went in, I'd argue that .H should be in as well.
> Basically, I now think these two should have been considered as a
> bundle and not as separate options.


+1. H is just the complex counterpart of T.

Chuck

Re: [Numpy-discussion] .M .A .T .H attribute result

[Fernando P. <fpe...@gm...>]

Hi all,

On 7/7/06, Travis Oliphant <oli...@ee...> wrote:
>
> I didn't compile the results, but the discussion on the idea of adding
> new attributes to the array object led to the following result.
>
> Added:  .T attribute to mean self.transpose()

[...]

> .H
>
> A few were in favor, but this can now be written .T.conj()  which is not
> bad so does not get a new attribute.

I didn't have strong feelings one way or another on this, so I didn't
vote, but at this point I'd like to make a comment before the freeze.
Given that .T went in, I'd argue that .H should be in as well.
Basically, I now think these two should have been considered as a
bundle and not as separate options.

The reason isn't (just) my OCD surfacing again, but the fact that the
hermitian conjugate plays /exactly/ the role that transposition plays,
in regards to defining norms and (positive definite) inner products,
when complex arrays are in play.

The fact that numpy has excellent complex support is a major source of
joy for many.  I think that having .T but not .H would be a big wart
in this regard.  If you are trying to write code for inner products
with complex arrays, the natural language change from real ones is:

 dot(A.T,B)  -> dot(A.H,B)

For people who play with quantum mechanics this is an everyday need
(self-adjoint operators require expressions like this all the time),
but I suspect its use will be common in any field requiring normed
spaces with complex arrays.

Just my 1e-2j

Cheers,

f

Re: [Numpy-discussion] Args for rand and randn: call for a vote

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

Ed Schofield wrote:
> Last week's discussion on rand() and randn() seemed to indicate a  
> sentiment that they ought to take tuples for consistency with ones,  
> zeros, eye, identity, and empty -- that, although they are supposed  
> to be convenience functions, they are inconvenient precisely because  
> of their inconsistency with these other functions.  This issue has  
> been raised many times over the past several months.
> 
> Travis made a change in r2572 to allow tuples as arguments, then took  
> it out again a few hours later, apparently unsure about whether this  
> was a good idea.

He was experimenting to see if it was technically easy or not.

> I'd like to call for a vote on what people would prefer, and then ask  
> Travis to make a final pronouncement before the feature freeze.
> 
> * Should numpy.rand and numpy.randn accept sequences of dimensions as  
> arguments, like rand((3,3)), as an alternative to rand(3,3)?

-1 This is worse than the problem it's trying to solve. You'll still see the 
inconsistent rand(3,3) in people's code.

> * Should rand((3,3)) and randn((3,3)) continue to raise a TypeError?

This is a false dichotomy. There are more choices here.

* Remove rand and randn (at least from the toplevel namespace) and promote the 
use of random_sample and standard_normal which already follow the tuple convention.

-- 
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] NumPy beta release plan

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

Hi Travis,

Are you going to make a development branch so other things can continue
going into Numpy until the 1.0 release?

Chuck

On 7/8/06, Darren Dale <dd...@co...> wrote:
>
> On Saturday 08 July 2006 4:04 am, Stephan Tolksdorf wrote:
> > Hi Travis,
> >
> > thanks for putting all the effort into NumPy.
> >
> >  > Unless there is a serious issue pointed out, the only thing that
> should
> >  > be changed at this point are bug-fixes, documentation strings, and
> added
> >  > tests.  Once 1.0b1 is released nothing but those things can be added.
> >
> > The beginning of the beta phase might also be the best time to address
> > the most severe NumPy.distutils issues, so that all changes can be
> > extensively tested during the beta:
>
> The number of people in my lab using numpy/scipy/matplotlib is starting to
> increase. Last week I was trying to get a couple of graduate students set
> up.
> They were using MacOS X 10.4 with gcc3.3, and we were never successful in
> getting numpy to build. I think the problem was the same as reported at
> http://mail.python.org/pipermail/pythonmac-sig/2006-March/016703.html. We
> ended up getting things installed by installing scipy with fink.
>
> >   - warning messages are only shown if compilation fails (NumPy should
> > build warning free)
>
> One of the guys I was working with tried installing every compiler out
> there
> to get rid of all the compiler not found messages that were reported
> during
> the attempted numpy builds. I guess he thought these messages were
> critical
> errors, since they are rendered in red lettering.
>
> Darren
>
> 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] I think something broke badly today in numpy/scipy...

[Fernando P. <fpe...@gm...>]

On 7/8/06, Travis Oliphant <oli...@ie...> wrote:

> Hey Fernando.   I think I found the problem.   It was the same problem
> causing the BFGS test to fail in SciPy.

[...]

> The problem should be fixed in SVN.

Confirmed.  With:

numpy version: 0.9.9.2788
scipy version: 0.5.0.2057

I checked on two machines (home/office) and all is good now.  I only
had to make a tiny change to my hand-written extensions for the new C
API names, and all checks OK now.

> Very sorry...

Considering how much you've given us, I don't really think you even
have the /right/ to apologize to anyone ;)

Many thanks for such a remarkable fix, given my impossibly vague bug
report.  You rock.

f

Re: [Numpy-discussion] Args for rand and randn: call for a vote

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

Ed Schofield wrote:
<mailto:da...@te...>
> * Should numpy.rand and numpy.randn accept sequences of dimensions as  
> arguments, like rand((3,3)), as an alternative to rand(3,3)?
>   

For allowing tuples:
+1

For *only* allowing tuples:
+1

Alan Isaac

[Numpy-discussion] more bdist_mpkg issues (setuptools)

[<lis...@ma...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Now that I figured out how to get at bdist_mpkg, I am experiencing  
issues with building extensions. I am trying to set them up as before  
with distutils except with the following import statement:

from setuptools import setup, Extension

However, my f2py extension is not recognized:

building 'PyMC.flib' extension
error: unknown file type '.f' (from 'PyMC/flib.f')

Any pointers to what I might be missing are most appreciated.

Thanks,
C.

- --
Christopher Fonnesbeck
+ Atlanta, GA
+ fonnesbeck at mac.com
+ Contact me on AOL IM using email address


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFEr9Gvkeka2iCbE4wRAg+YAJwPIDDMCQ7GB0CEriKZAFBO8RM3dwCfX1PY
Uz0/44rWk1n5i6U9o6Q7pVw=
=j9vl
-----END PGP SIGNATURE-----

Re: [Numpy-discussion] recarray field names

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

It was suggested that I put off this discussion until we were closer
to the 1.0 release. Perhaps now is a good time to bring it up once
again?  The quick summary: accessing field names has some
oddness that needs cleaning up.

On 3/15/06, Travis Oliphant <oli...@ee...> wrote:
> Fernando Perez wrote:
>
> >
> > Mmh, just curious: I wonder about the wisdom of that overloading of a
> > 'magic' key (-1).  It will make thinks like
> >
> > for name in t.dtype.fields:
>
>
> No real wisdom.  More organic growth.  Intially I didn't have an ordered
> list of fields, but as more complicated data-type descriptors were
> supported, this became an important thing to have.  I should have
> probably added a n additional element to the PyArray_Descr structure.
> Remember, it was growing out of the old PyArray_Descr already and I was
> a little concerned about changing it too much (there are ramifications
> of changing this structure in several places).
>
> So, instead of adding a "ordered_names" tuple to the dtype object, I
> just stuck it in the fields dictionary.  I agree it's kind of odd
> sitting there.
>
> It probably deserves a re-factoring and pulling that out into a new
> attribute of the dtype object.
>
> This would mean that the PyArray_Descr structure would need a new object
> (names perhaps), and it would need to be tracked.
>
> Not a huge change and probably worth it before the next release.
>
>
> -Travis

[Numpy-discussion] Fwd: bdist_mpkg

[<lis...@ma...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Never mind, I see that it is in setupegg.py.

C.

Begin forwarded message:

> From: lis...@ma...
> Date: July 8, 2006 11:11:02 AM EDT
> To: num...@li...
> Subject: bdist_mpkg
>
> As of recent svn updates, I can no longer build numpy binaries for  
> OS X using bdist_mpkg. How do I restore this capability, or is  
> there a better way of building Mac binaries?
>
> Thanks,
> C.
>
> --
> Christopher Fonnesbeck
> + Atlanta, GA
> + fonnesbeck at mac.com
> + Contact me on AOL IM using email address
>
>

- --
Christopher Fonnesbeck
+ Atlanta, GA
+ fonnesbeck at mac.com
+ Contact me on AOL IM using email address




- --
Christopher Fonnesbeck
+ Atlanta, GA
+ fonnesbeck at mac.com
+ Contact me on AOL IM using email address


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFEr8xbkeka2iCbE4wRAmxWAJ9jx/jFRJW0N4vCrh5H3SmN9IffvgCfWrRH
pT90YecS/SM47DEzfeOSWKU=
=D8D1
-----END PGP SIGNATURE-----