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

Re: [Numpy-discussion] Fwd: Collection.findTransformation() never stops

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

Dr. Seth Olsen wrote:
>
> Hi Travis,
>
> I would very happily accept the Scientific and MMTK patches.  Thank 
> you very much for the offer.

Look at http://www.scipy.org/Porting_to_NumPy

for information (and patches) on how to convert ScientificPython and 
MMTK to use NumPy.  I managed to get the codes to build and install but 
they are not tested.  Any problems you encounter would be useful to know 
about.

You can patch the code by changing to the top-level directory and entering

patch -p1 < patch_file

If it works for you, please email the developers and let them know how 
easy it can be (hopefully).

Best,

-Travis

Re: [Numpy-discussion] Fwd: Collection.findTransformation() never stops

[Dr. S. O. <set...@gm...>]

Hi Travis,

I would very happily accept the Scientific and MMTK patches.  Thank you very
much for the offer.

I hadn't thought much about it until very recently, when the advent of a new
IT structure in our laboratory forced me to upgrade my existing software.
It was then that it became obvious that the LAPACK routines called by
Numeric and MMTK were refusing to work.  I've spent the day trying to
wrestle with the problem (I am by no means an expert).  I finally decided to
get around the problems by altering the problem-solving routines in MMTK by
using routines from numpy and then immediately applying a=Numeric.array(
a.tolist()), which has stopped my script from gagging (although I have still
to demonstrate to myself that everything is working).  The uses to which I
apply MMTK usually mean that the matrices in question are pretty small, so I
don't have to worry too much about speed.

I was suprised to note, however, that a straightforward application of F2PY
to some fresh downloaded LAPACK F77 code did not work, and sent my machine
into a similar endless whirr as I had seen at the beginning of the day.
Apparently there's something sinister going on...

Cheers,

Seth

On 9/19/06, Travis Oliphant <oli...@ie...> wrote:
>
> Dr. Seth Olsen wrote:
> >
> > Hi Bill,
> >
> > MMTK has not made the conversion over to the new numpy module.  It is
> > built against the old Numeric code, and the word from its developers
> > is that changing to numpy cannot be a priority now.
> >
> My suggestion is to *kindly* put pressure on them.
>
> I've spent at least a hundred hours making it easy for people to port
> Numeric and Numarray-built code to NumPy.    Because of this, I'm a
> little bit frustrated by this kind of response.  I understand it will
> take time for people to migrate, but it really does not take that long
> to port code to use NumPy.
>
> I've offered to do it for any open source code.   In fact, I just spent
> 30 minutes and ported both Scientific Python and MMTK to use numpy.
> I'll send you a patch if you want.     It is true, that the result needs
> to be better tested, but I'm confident that any errors which might
> remain in the compatibility layer will be easily fixable (and we need
> people who are willing to do the tests to fix them).
>
> I'd rather not do this, but if necessary we can easily create an SVN
> tree of third-party packages ported to use NumPy if the package-owners
> are not willing to do it.   Keeping Numeric packages around except for
> legacy systems will only make things harder.
>
> I'll repeat the same offer I've made before:  I will gladly give my book
> and my help to any open source library author who will make porting to
> NumPy a priority for their package.  Note, however, my (free) ports to
> use NumPy do not use any "numerix-style" layer.  The library is
> converted to work with NumPy alone.  In other words, I won't spend any
> more "spare" time supporting 3 array packages.
>
> Best regards,
>
> -Travis
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>



-- 
ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms

Dr Seth Olsen, PhD
Postdoctoral Fellow, Biomolecular Modeling Group
Centre for Computational Molecular Science
Australian Institute for Bioengineering and Nanotechnology (Bldg. 75)
The University of Queensland
Qld 4072, Brisbane, Australia

tel (617) 3346 3976
fax (617) 33654623
email: s.o...@uq...
Web: www.ccms.uq.edu.au

ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
The opinions expressed here are my own and do not reflect the positions of
the University of Queensland.

Re: [Numpy-discussion] Fwd: Collection.findTransformation() never stops

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

Dr. Seth Olsen wrote:
>
> Hi Bill,
>
> MMTK has not made the conversion over to the new numpy module.  It is 
> built against the old Numeric code, and the word from its developers 
> is that changing to numpy cannot be a priority now.
>
My suggestion is to *kindly* put pressure on them. 

I've spent at least a hundred hours making it easy for people to port 
Numeric and Numarray-built code to NumPy.    Because of this, I'm a 
little bit frustrated by this kind of response.  I understand it will 
take time for people to migrate, but it really does not take that long 
to port code to use NumPy.   

I've offered to do it for any open source code.   In fact, I just spent 
30 minutes and ported both Scientific Python and MMTK to use numpy.    
I'll send you a patch if you want.     It is true, that the result needs 
to be better tested, but I'm confident that any errors which might 
remain in the compatibility layer will be easily fixable (and we need 
people who are willing to do the tests to fix them).

I'd rather not do this, but if necessary we can easily create an SVN 
tree of third-party packages ported to use NumPy if the package-owners 
are not willing to do it.   Keeping Numeric packages around except for 
legacy systems will only make things harder.

I'll repeat the same offer I've made before:  I will gladly give my book 
and my help to any open source library author who will make porting to 
NumPy a priority for their package.  Note, however, my (free) ports to 
use NumPy do not use any "numerix-style" layer.  The library is 
converted to work with NumPy alone.  In other words, I won't spend any 
more "spare" time supporting 3 array packages.

Best regards,

-Travis

Re: [Numpy-discussion] max argmax combo

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

On 9/18/06, Charles R Harris <cha...@gm...> wrote:
>
>
>
> On 9/18/06, Bill Baxter <wb...@gm...> wrote:
> >
> > On 9/19/06, Charles R Harris <cha...@gm...> wrote:
> > > On 9/18/06, Bill Baxter <wb...@gm...> wrote:
> > > > I find myself often wanting both the max and the argmax of an array.
> > > > (And same for the other arg* functions)
> >
> > > > You have to do something like
> > > >     a = rand(10,5)
> > > >     imax = a.argmax(axis=0)
> > > >     vmax = a[(imax, range(5))]
> > > >
> > > I don't generally like overloading return values, the function starts
> > to
> > > lose its definition and becomes a bit baroque where simply changing a
> > > keyword value can destroy the viability of the following code.
> >
> > Agreed.  Seems like the only justification is if you get multiple
> > results from one calculation but only rarely want the extra values.
> > It doesn't make sense to always return them, but it's also not worth
> > making a totally different function.
> >
> >
> > > But I can see the utility of what you want. Hmm,  this problem is not
> > unique to argmax.
> > > Maybe what we need is a general way to extract values, something like
> > >
> > > extract(a, imax, axis=0)
> > >
> > > to go along with all the single axis functions.
> >
> > Yes, I think that would be easier to remember.
> >
> > It should also work for the axis=None case.
> >   imax = a.argmax(axis=None)
> >   v = extract(a, imax, axis=None)
>
>
> It shouldn't be too difficult to jig something up given all the example
> code. I can do that, but I would like more input first. The questions I have
> are these.
>
> 1) Should it be done?
> 2) Should it be a method? (functions being somewhat deprecated)
> 3) What name should it have?
>
> I think Travis will have to weigh in on this. IIRC, he felt that the
> number of methods was getting out of hand.
>
> --Bill
>
>
> Chuck
>

I note that argsort also produces indexes that are hard to use in the ndim>1
case. The two problems aren't quite equivalent because argsort maintains
ndim while argmax reduces ndim by one, but it would be nice if there was
something that would work for both. Using imax[...,newaxis] would make the
shapes compatible for input but then the output would need to lose the
newaxis on return. Hmmm. These are both examples of an indirect indexing
problem where the indices on the specified axis are a function of the
indices on the other axis. Using the other indices in the argmax case yields
a scalar index while in the argsort case it yields a 1d array that can be
used for fancy indexing. I'm just floating around here trying to think of a
consistent way to regard these things. Ummm, and I think this could work. In
fact, the arrays could be even deeper and fancy indexing on the specified
axis would produce what was essentially an array of arrays. This is sort of
the photo-negative version of take.

Apropos the overloaded return types, I think that that is precisely what
makes it tricky to use functions that may return either copies or views. The
results should really be marked read only because otherwise unexpected
results can arise.

Chuck

Re: [Numpy-discussion] ***[Possible UCE]*** Re: Fwd: Collection.findTransformation() never stops

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

Dr. Seth Olsen wrote:
>
> Hi MMTKers and NUMPYers,
>
> Bill's answer to my inquiry about the problem I'm having with 
> Collection.findTransformation() (and also, incidentally, with the 
> dgesvd call in Subspace.getBasis(), has convinced me that I can no 
> long use MMTK without changing some of the code over to numpy.  I have 
> already been able to determine that invoking 
> numpy.oldnumeric.alter_code1.convertall() over the MMTK directory tree 
> is not the answer.

Why not?    It should be.  That is the recommended way to begin porting 
code.

If we need to improve alter_code, we cannot do it unless we receive bug 
reports.  Please tell us what difficulty you had.


-Travis

Re: [Numpy-discussion] max argmax combo

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

On 9/18/06, Bill Baxter <wb...@gm...> wrote:
>
> On 9/19/06, Charles R Harris <cha...@gm...> wrote:
> > On 9/18/06, Bill Baxter <wb...@gm...> wrote:
> > > I find myself often wanting both the max and the argmax of an array.
> > > (And same for the other arg* functions)
>
> > > You have to do something like
> > >     a = rand(10,5)
> > >     imax = a.argmax(axis=0)
> > >     vmax = a[(imax, range(5))]
> > >
> > I don't generally like overloading return values, the function starts to
> > lose its definition and becomes a bit baroque where simply changing a
> > keyword value can destroy the viability of the following code.
>
> Agreed.  Seems like the only justification is if you get multiple
> results from one calculation but only rarely want the extra values.
> It doesn't make sense to always return them, but it's also not worth
> making a totally different function.
>
>
> > But I can see the utility of what you want. Hmm,  this problem is not
> unique to argmax.
> > Maybe what we need is a general way to extract values, something like
> >
> > extract(a, imax, axis=0)
> >
> > to go along with all the single axis functions.
>
> Yes, I think that would be easier to remember.
>
> It should also work for the axis=None case.
>   imax = a.argmax(axis=None)
>   v = extract(a, imax, axis=None)


It shouldn't be too difficult to jig something up given all the example
code. I can do that, but I would like more input first. The questions I have
are these.

1) Should it be done?
2) Should it be a method? (functions being somewhat deprecated)
3) What name should it have?

I think Travis will have to weigh in on this. IIRC, he felt that the number
of methods was getting out of hand.

--Bill


Chuck

Re: [Numpy-discussion] max argmax combo

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

On 9/19/06, Charles R Harris <cha...@gm...> wrote:
> On 9/18/06, Bill Baxter <wb...@gm...> wrote:
> > I find myself often wanting both the max and the argmax of an array.
> > (And same for the other arg* functions)

> > You have to do something like
> >     a = rand(10,5)
> >     imax = a.argmax(axis=0)
> >     vmax = a[(imax, range(5))]
> >
> I don't generally like overloading return values, the function starts to
> lose its definition and becomes a bit baroque where simply changing a
> keyword value can destroy the viability of the following code.

Agreed.  Seems like the only justification is if you get multiple
results from one calculation but only rarely want the extra values.
It doesn't make sense to always return them, but it's also not worth
making a totally different function.


> But I can see the utility of what you want. Hmm,  this problem is not unique to argmax.
> Maybe what we need is a general way to extract values, something like
>
> extract(a, imax, axis=0)
>
> to go along with all the single axis functions.

Yes, I think that would be easier to remember.

It should also work for the axis=None case.
  imax = a.argmax(axis=None)
  v = extract(a, imax, axis=None)



--Bill

Re: [Numpy-discussion] Fwd: Collection.findTransformation() never stops

[Dr. S. O. <set...@gm...>]

Hi MMTKers and NUMPYers,

Bill's answer to my inquiry about the problem I'm having with
Collection.findTransformation() (and also, incidentally, with the dgesvd
call in Subspace.getBasis(), has convinced me that I can no long use MMTK
without changing some of the code over to numpy.  I have already been able
to determine that invoking numpy.oldnumeric.alter_code1.convertall() over
the MMTK directory tree is not the answer.  Has anyone on either of these
lists ever tried this before and, if so, can it be done (without destroying
my sanity)?

Cheers,

Seth

On 9/19/06, Dr. Seth Olsen <set...@gm...> wrote:
>
>
> Hi Bill,
>
> MMTK has not made the conversion over to the new numpy module.  It is
> built against the old Numeric code, and the word from its developers is that
> changing to numpy cannot be a priority now.
>
> Cheers,
>
> Seth
>
>
> On 9/19/06, Bill Baxter <wb...@gm...> wrote:
> >
> > Hey there,
> > I don't see anything called "LinearAlgegra.eigenvectors()".  Do you
> > maybe mean numpy.linalg.eig?
> > Which version of numpy are you using?
> > The latest release is 1.0b5.
> >
> > >>> import numpy
> > >>> numpy.__version__
> > '1.0b5'
> >
> > >>> numpy.linalg.eig([[2,1],[1,2]])
> > (array([ 3.,  1.]),
> > array([[ 0.70710678, -0.70710678],
> >        [ 0.70710678,  0.70710678]]))
> >
> > I'm on WindowsXP, though.
> > Regards,
> > Bill
> >
> > On 9/19/06, Dr. Seth Olsen <set...@gm...> wrote:
> > >
> > > Hi Numpyers,
> > >
> > > I recently sent the message below to the MMTK mailing list, but it's
> > really
> > > a problem with LinearAlgebra.py.  The routine
> > LinearAlgebra.eigenvectors()
> > > never stops, even when I try to diagonalize a very simple 2x2
> > matrix.  I've
> > > tried this on two machines with completely standard FC4 and FC5
> > > installations using the default libraries and atlas libraries
> > downloaded and
> > > installed via yum.  Does anyone on this list have any experience with
> > this
> > > problem?
> > >
> > > Cheers,
> > >
> > > Seth
> > >
> > > ---------- Forwarded message ----------
> > > From: Dr. Seth Olsen <set...@gm... >
> > > Date: Sep 19, 2006 10:38 AM
> > > Subject: Re: Collection.findTransformation() never stops
> > > To: mm...@py..., mm...@st...
> > >
> > >
> > > Hi MMTKers,
> > >
> > > The problem with Collection.findTransformation() that I reported
> > earlier is
> > > due to a problem with LinearAlgebra.eigenvectors().  This algortithm
> > does
> > > not seem to stop - it can't even manage to find the eigenvectors of
> > the 2x2
> > > square matrix [[2,1],[1,2]].  Asking for this causes a long wait
> > followed by
> > > CPU overheat warnings.  Moreover, I have recompiled Numeric23.8 with
> > newly
> > > installed atlas libraries, but it still won't work.  I have had this
> > problem
> > > now on 2 machines (one running FC4 with , the other FC5, both pentium
> > 4
> > > machines), with atlas lapack/blas libraries installed freshly via yum
> > and
> > > linked as per the recommendations found in setup.py .  THE FEDORA
> > > INSTALLATIONS ON BOTH MACHINES IS STANDARD - everything has been
> > downloaded
> > > and installed via the fedora yum repositories.
> > >
> > > As the eigenvectors() routine in LinearAlgebra.py is obviously going
> > to be a
> > > heavily used algorithm (not just in MMTK), is it really possible that
> > no one
> > > has had this problem before?
> > >
> > > Cheers,
> > >
> > > Seth
> > >
> > >
> > >  On 9/18/06, Dr. Seth Olsen < set...@gm...> wrote:
> > > >
> > > >
> > > > Hi MMTKers,
> > > >
> > > > I'm having a bit of trouble with
> > > MMTK.Collection.findTransformation .  When I use this member
> > > function, the computer never stops thinking until I kill the
> > process.  I've
> > > waited a couple of hours and still nothing.  I get the same thing if I
> > try
> > > to take a step back and use
> > > Collection.findTransformationAsQuaternion.  Has anyone had
> > > this problem before?
> > > >
> > > > Cheers,
> > > >
> > > > Seth
> > > >
> > > > --
> > > >
> > > ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
> > > >
> > > > Dr Seth Olsen, PhD
> > > > Postdoctoral Fellow, Biomolecular Modeling Group
> > > > Centre for Computational Molecular Science
> > > > Australian Institute for Bioengineering and Nanotechnology (Bldg.
> > 75)
> > > > The University of Queensland
> > > > Qld 4072, Brisbane, Australia
> > > >
> > > > tel (617) 3346 3976
> > > > fax (617) 33654623
> > > > email: s.o...@uq...
> > > > Web: www.ccms.uq.edu.au
> > > >
> > > >
> > > ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
> > > > The opinions expressed here are my own and do not reflect the
> > positions of
> > > the University of Queensland.
> > >
> > >
> > >
> > > --
> > > ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
> > >
> > > Dr Seth Olsen, PhD
> > > Postdoctoral Fellow, Biomolecular Modeling Group
> > > Centre for Computational Molecular Science
> > > Australian Institute for Bioengineering and Nanotechnology (Bldg. 75)
> > > The University of Queensland
> > > Qld 4072, Brisbane, Australia
> > >
> > > tel (617) 3346 3976
> > > fax (617) 33654623
> > > email: s.o...@uq...
> > > Web: www.ccms.uq.edu.au
> > >
> > > ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
> > > The opinions expressed here are my own and do not reflect the
> > positions of
> > > the University of Queensland.
> > >
> > > --
> > > ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
> > >
> > > Dr Seth Olsen, PhD
> > > Postdoctoral Fellow, Biomolecular Modeling Group
> > > Centre for Computational Molecular Science
> > > Australian Institute for Bioengineering and Nanotechnology (Bldg. 75)
> > > The University of Queensland
> > > Qld 4072, Brisbane, Australia
> > >
> > > tel (617) 3346 3976
> > > fax (617) 33654623
> > > email: s.o...@uq...
> > > Web: www.ccms.uq.edu.au
> > >
> > > ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
> > > The opinions expressed here are my own and do not reflect the
> > positions of
> > > the University of Queensland.
> > >
> > -------------------------------------------------------------------------
> > > Take Surveys. Earn Cash. Influence the Future of IT
> > > Join SourceForge.net's Techsay panel and you'll get the chance to
> > share your
> > > opinions on IT & business topics through brief surveys -- and earn
> > cash
> > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >
> > >
> > > _______________________________________________
> > > Numpy-discussion mailing list
> > > Num...@li...
> > > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> > >
> > >
> > >
> >
> > -------------------------------------------------------------------------
> >
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> > your
> > opinions on IT & business topics through brief surveys -- and earn cash
> >
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Numpy-discussion mailing list
> > Num...@li...
> > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> >
>
>
>
> --
>
> ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
>
> Dr Seth Olsen, PhD
> Postdoctoral Fellow, Biomolecular Modeling Group
> Centre for Computational Molecular Science
> Australian Institute for Bioengineering and Nanotechnology (Bldg. 75)
> The University of Queensland
> Qld 4072, Brisbane, Australia
>
> tel (617) 3346 3976
> fax (617) 33654623
> email: s.o...@uq...
> Web: www.ccms.uq.edu.au
>
> ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
> The opinions expressed here are my own and do not reflect the positions of
> the University of Queensland.
>



-- 
ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms

Dr Seth Olsen, PhD
Postdoctoral Fellow, Biomolecular Modeling Group
Centre for Computational Molecular Science
Australian Institute for Bioengineering and Nanotechnology (Bldg. 75)
The University of Queensland
Qld 4072, Brisbane, Australia

tel (617) 3346 3976
fax (617) 33654623
email: s.o...@uq...
Web: www.ccms.uq.edu.au

ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
The opinions expressed here are my own and do not reflect the positions of
the University of Queensland.

Re: [Numpy-discussion] max argmax combo

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

On 9/18/06, Bill Baxter <wb...@gm...> wrote:
>
> I find myself often wanting both the max and the argmax of an array.
> (And same for the other arg* functions)
> Of course I can do argmax first then use fancy indexing to get the max as
> well.
> But the result of argmax isn't really in a format that's readily
> usable as an index.
> You have to do something like
>     a = rand(10,5)
>     imax = a.argmax(axis=0)
>     vmax = a[(imax, range(5))]
>
> Which isn't terrible, just always takes me a moment to remember the
> proper indexing expression.
> Would a way to get the argmax and the max at the same time be of
> interest to anyone else?  Maybe an extra 'ret' arg on argmax?
>
>    a = rand(10,5)
>    imax,vmax = a.argmax(axis=0,retmax=True)


I don't generally like overloading return values, the function starts to
lose its definition and becomes a bit baroque where simply changing a
keyword value can destroy the viability of the following code. But I can see
the utility of what you want. Hmm,  this problem is not unique to argmax.
Maybe what we need is a general way to extract values, something like

extract(a, imax, axis=0)

to go along with all the single axis functions.

Chuck

[Numpy-discussion] max argmax combo

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

I find myself often wanting both the max and the argmax of an array.
(And same for the other arg* functions)
Of course I can do argmax first then use fancy indexing to get the max as well.
But the result of argmax isn't really in a format that's readily
usable as an index.
You have to do something like
    a = rand(10,5)
    imax = a.argmax(axis=0)
    vmax = a[(imax, range(5))]

Which isn't terrible, just always takes me a moment to remember the
proper indexing expression.
Would a way to get the argmax and the max at the same time be of
interest to anyone else?  Maybe an extra 'ret' arg on argmax?

   a = rand(10,5)
   imax,vmax = a.argmax(axis=0,retmax=True)

--Bill

Re: [Numpy-discussion] unique1d: renaming retindx to return_index

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

Grepping through numpy/**/*.py, the only three functions I could find
with an argument to specify extra return values are:

  linspace(start, stop, num=50, endpoint=True, retstep=False)
  average(a, axis=None weights=None, returned=False)
  unique1d(ar1, retindx=False)

If unique1d is going to change to return_index, then linspace should
probably also change to return_step to maintain consistency.  And
maybe average should change to 'return_count'  or [ick]
'return_denominator'.

--bb

On 9/19/06, Stefan van der Walt <st...@su...> wrote:
> Hi,
>
> Would anyone object if I changed the signature of
>
> unique1d(ar1, retindx=False)
>
> to
>
> unique1d(ar1, return_index=False)?
>
> I find retindx both harder to read and to type than return_index.
>

Re: [Numpy-discussion] Fwd: Collection.findTransformation() never stops

[Dr. S. O. <set...@gm...>]

Hi Bill,

MMTK has not made the conversion over to the new numpy module.  It is built
against the old Numeric code, and the word from its developers is that
changing to numpy cannot be a priority now.

Cheers,

Seth

On 9/19/06, Bill Baxter <wb...@gm...> wrote:
>
> Hey there,
> I don't see anything called "LinearAlgegra.eigenvectors()".  Do you
> maybe mean numpy.linalg.eig?
> Which version of numpy are you using?
> The latest release is 1.0b5.
>
> >>> import numpy
> >>> numpy.__version__
> '1.0b5'
>
> >>> numpy.linalg.eig([[2,1],[1,2]])
> (array([ 3.,  1.]),
> array([[ 0.70710678, -0.70710678],
>        [ 0.70710678,  0.70710678]]))
>
> I'm on WindowsXP, though.
> Regards,
> Bill
>
> On 9/19/06, Dr. Seth Olsen <set...@gm...> wrote:
> >
> > Hi Numpyers,
> >
> > I recently sent the message below to the MMTK mailing list, but it's
> really
> > a problem with LinearAlgebra.py.  The routine LinearAlgebra.eigenvectors
> ()
> > never stops, even when I try to diagonalize a very simple 2x2
> matrix.  I've
> > tried this on two machines with completely standard FC4 and FC5
> > installations using the default libraries and atlas libraries downloaded
> and
> > installed via yum.  Does anyone on this list have any experience with
> this
> > problem?
> >
> > Cheers,
> >
> > Seth
> >
> > ---------- Forwarded message ----------
> > From: Dr. Seth Olsen <set...@gm... >
> > Date: Sep 19, 2006 10:38 AM
> > Subject: Re: Collection.findTransformation() never stops
> > To: mm...@py..., mm...@st...
> >
> >
> > Hi MMTKers,
> >
> > The problem with Collection.findTransformation() that I reported earlier
> is
> > due to a problem with LinearAlgebra.eigenvectors().  This algortithm
> does
> > not seem to stop - it can't even manage to find the eigenvectors of the
> 2x2
> > square matrix [[2,1],[1,2]].  Asking for this causes a long wait
> followed by
> > CPU overheat warnings.  Moreover, I have recompiled Numeric23.8 with
> newly
> > installed atlas libraries, but it still won't work.  I have had this
> problem
> > now on 2 machines (one running FC4 with , the other FC5, both pentium 4
> > machines), with atlas lapack/blas libraries installed freshly via yum
> and
> > linked as per the recommendations found in setup.py.  THE FEDORA
> > INSTALLATIONS ON BOTH MACHINES IS STANDARD - everything has been
> downloaded
> > and installed via the fedora yum repositories.
> >
> > As the eigenvectors() routine in LinearAlgebra.py is obviously going to
> be a
> > heavily used algorithm (not just in MMTK), is it really possible that no
> one
> > has had this problem before?
> >
> > Cheers,
> >
> > Seth
> >
> >
> >  On 9/18/06, Dr. Seth Olsen <set...@gm...> wrote:
> > >
> > >
> > > Hi MMTKers,
> > >
> > > I'm having a bit of trouble with
> > MMTK.Collection.findTransformation.  When I use this member
> > function, the computer never stops thinking until I kill the
> process.  I've
> > waited a couple of hours and still nothing.  I get the same thing if I
> try
> > to take a step back and use
> > Collection.findTransformationAsQuaternion.  Has anyone had
> > this problem before?
> > >
> > > Cheers,
> > >
> > > Seth
> > >
> > > --
> > >
> > ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
> > >
> > > Dr Seth Olsen, PhD
> > > Postdoctoral Fellow, Biomolecular Modeling Group
> > > Centre for Computational Molecular Science
> > > Australian Institute for Bioengineering and Nanotechnology (Bldg. 75)
> > > The University of Queensland
> > > Qld 4072, Brisbane, Australia
> > >
> > > tel (617) 3346 3976
> > > fax (617) 33654623
> > > email: s.o...@uq...
> > > Web: www.ccms.uq.edu.au
> > >
> > >
> > ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
> > > The opinions expressed here are my own and do not reflect the
> positions of
> > the University of Queensland.
> >
> >
> >
> > --
> > ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
> >
> > Dr Seth Olsen, PhD
> > Postdoctoral Fellow, Biomolecular Modeling Group
> > Centre for Computational Molecular Science
> > Australian Institute for Bioengineering and Nanotechnology (Bldg. 75)
> > The University of Queensland
> > Qld 4072, Brisbane, Australia
> >
> > tel (617) 3346 3976
> > fax (617) 33654623
> > email: s.o...@uq...
> > Web: www.ccms.uq.edu.au
> >
> > ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
> > The opinions expressed here are my own and do not reflect the positions
> of
> > the University of Queensland.
> >
> > --
> > ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
> >
> > Dr Seth Olsen, PhD
> > Postdoctoral Fellow, Biomolecular Modeling Group
> > Centre for Computational Molecular Science
> > Australian Institute for Bioengineering and Nanotechnology (Bldg. 75)
> > The University of Queensland
> > Qld 4072, Brisbane, Australia
> >
> > tel (617) 3346 3976
> > fax (617) 33654623
> > email: s.o...@uq...
> > Web: www.ccms.uq.edu.au
> >
> > ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
> > The opinions expressed here are my own and do not reflect the positions
> of
> > the University of Queensland.
> >
> -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> > opinions on IT & business topics through brief surveys -- and earn cash
> >
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >
> > _______________________________________________
> > Numpy-discussion mailing list
> > Num...@li...
> > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> >
> >
> >
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>



-- 
ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms

Dr Seth Olsen, PhD
Postdoctoral Fellow, Biomolecular Modeling Group
Centre for Computational Molecular Science
Australian Institute for Bioengineering and Nanotechnology (Bldg. 75)
The University of Queensland
Qld 4072, Brisbane, Australia

tel (617) 3346 3976
fax (617) 33654623
email: s.o...@uq...
Web: www.ccms.uq.edu.au

ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
The opinions expressed here are my own and do not reflect the positions of
the University of Queensland.

Re: [Numpy-discussion] Fwd: Collection.findTransformation() never stops

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

Hey there,
I don't see anything called "LinearAlgegra.eigenvectors()".  Do you
maybe mean numpy.linalg.eig?
Which version of numpy are you using?
The latest release is 1.0b5.

>>> import numpy
>>> numpy.__version__
'1.0b5'

>>> numpy.linalg.eig([[2,1],[1,2]])
(array([ 3.,  1.]),
 array([[ 0.70710678, -0.70710678],
       [ 0.70710678,  0.70710678]]))

I'm on WindowsXP, though.
Regards,
Bill

On 9/19/06, Dr. Seth Olsen <set...@gm...> wrote:
>
> Hi Numpyers,
>
> I recently sent the message below to the MMTK mailing list, but it's really
> a problem with LinearAlgebra.py.  The routine LinearAlgebra.eigenvectors()
> never stops, even when I try to diagonalize a very simple 2x2 matrix.  I've
> tried this on two machines with completely standard FC4 and FC5
> installations using the default libraries and atlas libraries downloaded and
> installed via yum.  Does anyone on this list have any experience with this
> problem?
>
> Cheers,
>
> Seth
>
> ---------- Forwarded message ----------
> From: Dr. Seth Olsen <set...@gm... >
> Date: Sep 19, 2006 10:38 AM
> Subject: Re: Collection.findTransformation() never stops
> To: mm...@py..., mm...@st...
>
>
> Hi MMTKers,
>
> The problem with Collection.findTransformation() that I reported earlier is
> due to a problem with LinearAlgebra.eigenvectors().  This algortithm does
> not seem to stop - it can't even manage to find the eigenvectors of the 2x2
> square matrix [[2,1],[1,2]].  Asking for this causes a long wait followed by
> CPU overheat warnings.  Moreover, I have recompiled Numeric23.8 with newly
> installed atlas libraries, but it still won't work.  I have had this problem
> now on 2 machines (one running FC4 with , the other FC5, both pentium 4
> machines), with atlas lapack/blas libraries installed freshly via yum and
> linked as per the recommendations found in setup.py.  THE FEDORA
> INSTALLATIONS ON BOTH MACHINES IS STANDARD - everything has been downloaded
> and installed via the fedora yum repositories.
>
> As the eigenvectors() routine in LinearAlgebra.py is obviously going to be a
> heavily used algorithm (not just in MMTK), is it really possible that no one
> has had this problem before?
>
> Cheers,
>
> Seth
>
>
>  On 9/18/06, Dr. Seth Olsen <set...@gm...> wrote:
> >
> >
> > Hi MMTKers,
> >
> > I'm having a bit of trouble with
> MMTK.Collection.findTransformation.  When I use this member
> function, the computer never stops thinking until I kill the process.  I've
> waited a couple of hours and still nothing.  I get the same thing if I try
> to take a step back and use
> Collection.findTransformationAsQuaternion.  Has anyone had
> this problem before?
> >
> > Cheers,
> >
> > Seth
> >
> > --
> >
> ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
> >
> > Dr Seth Olsen, PhD
> > Postdoctoral Fellow, Biomolecular Modeling Group
> > Centre for Computational Molecular Science
> > Australian Institute for Bioengineering and Nanotechnology (Bldg. 75)
> > The University of Queensland
> > Qld 4072, Brisbane, Australia
> >
> > tel (617) 3346 3976
> > fax (617) 33654623
> > email: s.o...@uq...
> > Web: www.ccms.uq.edu.au
> >
> >
> ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
> > The opinions expressed here are my own and do not reflect the positions of
> the University of Queensland.
>
>
>
> --
> ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
>
> Dr Seth Olsen, PhD
> Postdoctoral Fellow, Biomolecular Modeling Group
> Centre for Computational Molecular Science
> Australian Institute for Bioengineering and Nanotechnology (Bldg. 75)
> The University of Queensland
> Qld 4072, Brisbane, Australia
>
> tel (617) 3346 3976
> fax (617) 33654623
> email: s.o...@uq...
> Web: www.ccms.uq.edu.au
>
> ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
> The opinions expressed here are my own and do not reflect the positions of
> the University of Queensland.
>
> --
> ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
>
> Dr Seth Olsen, PhD
> Postdoctoral Fellow, Biomolecular Modeling Group
> Centre for Computational Molecular Science
> Australian Institute for Bioengineering and Nanotechnology (Bldg. 75)
> The University of Queensland
> Qld 4072, Brisbane, Australia
>
> tel (617) 3346 3976
> fax (617) 33654623
> email: s.o...@uq...
> Web: www.ccms.uq.edu.au
>
> ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
> The opinions expressed here are my own and do not reflect the positions of
> the University of Queensland.
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
>
>

[Numpy-discussion] Fwd: Collection.findTransformation() never stops

[Dr. S. O. <set...@gm...>]

Hi Numpyers,

I recently sent the message below to the MMTK mailing list, but it's really
a problem with LinearAlgebra.py.  The routine LinearAlgebra.eigenvectors()
never stops, even when I try to diagonalize a very simple 2x2 matrix.  I've
tried this on two machines with completely standard FC4 and FC5
installations using the default libraries and atlas libraries downloaded and
installed via yum.  Does anyone on this list have any experience with this
problem?

Cheers,

Seth

---------- Forwarded message ----------
From: Dr. Seth Olsen <set...@gm...>
Date: Sep 19, 2006 10:38 AM
Subject: Re: Collection.findTransformation() never stops
To: mm...@py..., mm...@st...


Hi MMTKers,

The problem with Collection.findTransformation() that I reported earlier is
due to a problem with LinearAlgebra.eigenvectors().  This algortithm does
not seem to stop - it can't even manage to find the eigenvectors of the 2x2
square matrix [[2,1],[1,2]].  Asking for this causes a long wait followed by
CPU overheat warnings.  Moreover, I have recompiled Numeric23.8 with newly
installed atlas libraries, but it still won't work.  I have had this problem
now on 2 machines (one running FC4 with , the other FC5, both pentium 4
machines), with atlas lapack/blas libraries installed freshly via yum and
linked as per the recommendations found in setup.py.  THE FEDORA
INSTALLATIONS ON BOTH MACHINES IS STANDARD - everything has been downloaded
and installed via the fedora yum repositories.

As the eigenvectors() routine in LinearAlgebra.py is obviously going to be a
heavily used algorithm (not just in MMTK), is it really possible that no one
has had this problem before?

Cheers,

Seth


On 9/18/06, Dr. Seth Olsen <set...@gm...> wrote:
>
>
> Hi MMTKers,
>
> I'm having a bit of trouble with MMTK.Collection.findTransformation.  When
> I use this member function, the computer never stops thinking until I kill
> the process.  I've waited a couple of hours and still nothing.  I get the
> same thing if I try to take a step back and use
> Collection.findTransformationAsQuaternion.  Has anyone had this problem
> before?
>
> Cheers,
>
> Seth
>
> --
> ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
>
> Dr Seth Olsen, PhD
> Postdoctoral Fellow, Biomolecular Modeling Group
> Centre for Computational Molecular Science
> Australian Institute for Bioengineering and Nanotechnology (Bldg. 75)
> The University of Queensland
> Qld 4072, Brisbane, Australia
>
> tel (617) 3346 3976
> fax (617) 33654623
> email: s.o...@uq...
> Web: www.ccms.uq.edu.au
>
> ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
> The opinions expressed here are my own and do not reflect the positions of
> the University of Queensland.
>



-- 
ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms

Dr Seth Olsen, PhD
Postdoctoral Fellow, Biomolecular Modeling Group
Centre for Computational Molecular Science
Australian Institute for Bioengineering and Nanotechnology (Bldg. 75)
The University of Queensland
Qld 4072, Brisbane, Australia

tel (617) 3346 3976
fax (617) 33654623
email: s.o...@uq...
Web: www.ccms.uq.edu.au

ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
The opinions expressed here are my own and do not reflect the positions of
the University of Queensland.


-- 
ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms

Dr Seth Olsen, PhD
Postdoctoral Fellow, Biomolecular Modeling Group
Centre for Computational Molecular Science
Australian Institute for Bioengineering and Nanotechnology (Bldg. 75)
The University of Queensland
Qld 4072, Brisbane, Australia

tel (617) 3346 3976
fax (617) 33654623
email: s.o...@uq...
Web: www.ccms.uq.edu.au

ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms
The opinions expressed here are my own and do not reflect the positions of
the University of Queensland.

[Numpy-discussion] unique1d: renaming retindx to return_index

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

Hi,

Would anyone object if I changed the signature of

unique1d(ar1, retindx=3DFalse)

to

unique1d(ar1, return_index=3DFalse)?

I find retindx both harder to read and to type than return_index.

Thanks.
St=E9fan

Re: [Numpy-discussion] record descriptors: trailing unused bytes

[Martin W. <Mar...@mp...>]

On Monday 18 September 2006 20:46, Travis Oliphant wrote:
> Martin Wiechert wrote:
> > Hi list,
> >
> > does anybody know, if in C in the PyArray_Descr struct it is safe to
> > manually change descr->elsize and descr->alignment as long as these are
> > compatible and descr->elsize is large enough to hold all fields? Of
> > course I mean before any array is constructed using descr.
>
> Well, you should really make a copy of the PyArray_Descr structure and
> then fill it in as desired unless you are sure that no other arrays have
> are using that particular data-type object to describe their own data:
> PyArray_DescrNew gives you a new copy based on an old one (you just get
> a reference to the funciton pointers in the 'f' member so don't go
> changing those).
>
> I guess your statement about "before any array is constructed using
> descr" means you are sure that there are no other arrays using the old
> elsize and alignment.
>
> Then it should be fine.  There are not supposed to be any assumptions
> about the data-types except for what is explicitly provided in the
> data-type object (PyArray_Descr *).  So, changing them will change the
> data-type and things should ideally work.
>
> -Travis
>

Thanks

>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your opinions on IT & business topics through brief surveys -- and earn
> cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] visual programming

[Bryan C. <br...@co...>]

On Mon, 2006-09-18 at 09:29 -0700, Mathew Yeates wrote:
> semi off topic.
> Does anyone know of any good visual programming tools? Forever ago, I 
> used to use something called Khoros for image processing and I found it 
> very useful. You connect boxes which represent different processing 
> steps. At about the same time, there was something similar to Khoros 
> from SGI. Explorer was its name, I think.

Looking at the Khoros commercial site (now AccuSoft), it looks like a
more polished version of OpenDX (which also offers a visual programming
system). See http://www.opendx.org/index2.php 

The problem with OpenDX is the cr*ppy Motif-based GUI (particularly so
if you use Windows). I prefer VTK (www.vtk.org) which offers similar
concepts (pipeline execution of data filtering/visualisation blocks) but
in a programmatic form based on python (which we like...). 

BC


> 
> Anybody out there use this sort of thing? Matlab doesn't offer it, 
> right? Nor matplotlib?
> 
> Mathew
> 
> 
> 
> -------------------------------------------------------------------------
> 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

Re: [Numpy-discussion] Segfault on byteswap() on recarrays

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

Matthew Brett wrote:
> Hi,
>
> I noticed this works:
>
> In [5]:a = array((1,), dtype=[('one', '<i4')])
>
> In [6]:a.byteswap()
> Out[6]:
> array((16777216,),
>       dtype=[('one', '<i4')])
>
> But, extending the recarray leads to a segfault on byteswapping:
>
> In [8]:a = array((1, 2), dtype=[('one', '<i4'),('two', '<i4')])
>
> In [9]:a.byteswap()
> Segmentation fault
>   
Great catch.   Fixed in SVN.

-Travis

Re: [Numpy-discussion] buggy buggy bugyy: format and casting ==> BUG in numpy.sum?

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

Christopher Barker schrieb:
> Sven Schreiber wrote:
>> on my 1.0b5 I also see this docstring which indeed seems obsolete.
> 
> I get this docs string from :
> 
>  >>> import numpy as N
>  >>> N.__version__
> '1.0b5'
>  >>> a = N.arange(10)
>  >>> help( a.sum)
> 
> """
> sum(...)
>      a.sum(axis=None, dtype=None) -> Sum of array over given axis.
> 
>      Sum the array over the given axis.  If the axis is None, sum over
>      all dimensions of the array.
> 
> """
> 
> that looks right to me.
> 
> -Chris
> 

Well here's what we had in mind:

sum(x, axis=None, dtype=None, out=None)

(...)

       Examples:
    >>> sum([0.5, 1.5])
    2.0
    >>> sum([0.5, 1.5], dtype=Int32)
    1
    >>> sum([[0, 1], [0, 5]])
    array([0, 6])
    >>> sum([[0, 1], [0, 5]], axis=1)
    array([1, 5])


And you can see the third example would now be wrong, giving a scalar of
6 now.
-sven

[Numpy-discussion] static build

[Mike R. <mr...@ca...>]

I need build core numpy (plus possible dft) static into python.a
Can someone point me to the right direction.

Currently I built some libs but blocked on _internal.

 From my Setup.local:

NPSRC=/home/mrovner/src/numpy-0.9.8
NPBLD=$(NPSRC)/build/src.linux-i686-2.4
NPINC=-I$(NPSRC)/numpy/core/include -I$(NPBLD)/numpy/core 
-I$(NPSRC)/numpy/core/src
multiarray $(NPSRC)/numpy/core/src/multiarraymodule.c $(NPINC)
umath $(NPBLD)/numpy/core/src/umathmodule.c $(NPINC)
scalarmath $(NPBLD)/numpy/core/src/scalarmathmodule.c $(NPINC)
_sort $(NPBLD)/numpy/core/src/_sortmodule.c $(NPINC)
_compiled_base $(NPSRC)/numpy/lib/src/_compiled_base.c $(NPINC)

Thanks,
Mike

[Numpy-discussion] Segfault on byteswap() on recarrays

[Matthew B. <mat...@gm...>]

Hi,

I noticed this works:

In [5]:a = array((1,), dtype=[('one', '<i4')])

In [6]:a.byteswap()
Out[6]:
array((16777216,),
      dtype=[('one', '<i4')])

But, extending the recarray leads to a segfault on byteswapping:

In [8]:a = array((1, 2), dtype=[('one', '<i4'),('two', '<i4')])

In [9]:a.byteswap()
Segmentation fault

Thanks,

Matthew

Re: [Numpy-discussion] 1.0b5 Installation on OS X

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

David Andrews wrote:

> I'm unable to install the 1.0b5 release from the .mpkg on OS X - when
> it comes to the two checkboxes to select the platlib and the scripts,
> both are greyed out.  The installer then claims 'Cannot continue:
> Nothing to install'.

hmmm. It works just fine for me -- just clicking OK as I go merrily along.

OS version? python version? processor?

Also, try deleting or renaming any existing install you have from 
site-packages, then try again.

-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] Changing byte ordering with astype fails with 0d arrays

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

Matthew Brett wrote:
> Hi,
>
> As expected:
>
> In [67]:a = array([1], dtype='<i4')
>
> In [68]:a.astype('>i4').dtype
> Out[68]:dtype('>i4')
>
> I was also expecting this to work for 0d arrays, but it doesn't:
>
> In [69]:a = array(1, dtype='<i4')
>
> In [70]:a.astype('>i4').dtype
> Out[70]:dtype('<i4')
>
>   
The problem is that the astype method is returning an array scalar (it 
used to be that 0-d arrays were "avoided" at all costs).  We've since 
relaxes this requirement and I think here's another place where it needs 
to be relaxed. 

-Travis

Re: [Numpy-discussion] feasability study to migrate from numarray to numpy

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

mg wrote:
> Hi all,
>
> I am doing a feseability study to migrate our Python based FEM 
> applications from Numarray to Numpy.
>
> First, I tried to install Numpy from Python-2.4 on linux-x86, 
> linux-86-64bit. So, all work fine. Great! Moreover, I change easily the 
> BLAS linked libraries. I tried with ATLAS and GOTO. Great again!
>
> Second, I try to do the same think on windows-x86 without success. So my 
> first question is: is Numpy-1.0b5 has been tested and is supported on 
> Windows?
>   
Yes, it should work.  Builds for windows were provided.   But, perhaps 
there are configuration issues for your system that we are not handling 
correctly.

> Third, I tried to install Numpy from Python-2.5, which is our standard 
> Python, on linux-x86... and the compilation stopped during the 
> compilation of core/src/multiarraymodule.c. So my second question is: is 
> there a workaround or is the porting to Python2.5 is yet schedule?
>   
There was a problem with Python 2.5 and NumPy 1.0 that is fixed in SVN.  
Look for NumPy 1.0rc1 to come out soon.
> My third question is: is the tool to migrate the numarray based Python 
> scripts (numpy.numarray.alter_code1) work fine? (I suppose yes...)
>   
It needs more testing.  It would be great if you could help us find and 
fix bugs in it.   I don't have a lot of numarray code to test.
> We have created a lot of bindings in order to pilote our generic-C++ 
> framework with Python scripts. So, about the Numpy API, is it widely 
> different than the Numarray API? (We will order the Numpy Guide too.)
>   
It is more similar to the Numeric C-API.  However, the numarray C-API is 
completely supported by including numpy/libnumarray.h so you should be 
able to convert your C code very easily.   Any problems encountered 
should be noted and we'll get them fixed.
> To not duplicate large numerical memory arrays, Numarray allows to 
> aliasing the memory of some bindings with arrays from Numarray, and we 
> have used this feature intensively. So, I wonder if it is currently 
> supported (or even scheduled)?
I'm pretty sure the answer is yes (because the Numarray C-API is 
supported), though I'm not exactly sure what you mean.  Do you mean that 
you have memory created in the C/C++ framework and then you have an 
array use that memory for it's data area?  If that is what you mean, 
then the answer is definitely yes.


-Travis

Re: [Numpy-discussion] buggy buggy bugyy: format and casting ==> BUG in numpy.sum?

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

Eric Emsellem wrote:
> Hi again
>
> after some hours of debugging I finally (I think) found the problem:
>
> numpy.sum([[0,1,2],[2,3,4]])
> 24
>
> numpy.sum([[0,1,2],[2,3,4]],axis=0)
> array([2, 4, 6])
>
> numpy.sum([[0,1,2],[2,3,4]],axis=1)
> array([3, 9])
>
>
> Isn't the first line supposed to act as with "axis=0" by default (see
> help numpy.sum!)...???
> Not setting axis=0 it sums everything!
>   
See the Release Notes page on www.scipy.org.  It documents everything 
that has changed.  Several things will break old code as indicated. 

There are several options for keeping old code working:

1) Use the numpy.oldnumeric compatibility layer which keeps the same 
definitions and defaults as Numeric

2) Use conversion tools (like the recently added fix_default_axis) tool 
to automatically insert axis=0 arguments in all code where it is not 
present (or to automatically change the import to oldnumeric).

For the future, you must specify which axis you mean for a Nd array or 
the code will assume you meant to work over the entire N-d array.

We all recognize this is a pain to change.  That's why the backward 
compatibilty options are avaiable and the tools have been written.  
Believe me, I know what a pain it is.  I have had to keep SciPy and 
Matplotlib working with all the changes to NumPy. 



-Travis