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

Re: [Numpy-discussion] RPMs out of date, have problems

[Konrad H. <hi...@cn...>]

Joe Harrington <jh...@oo...> writes:

> The latest Numeric release on the web site is 20.3.  The latest with
> an RPM is 20.1, and that RPM has a problem: it creates a directory in
> the system root directory.  Paul D. says he will implement a solution
> but doesn't have the experience with RPMs (or the time) to find the
> problem quickly.  I haven't dealt with building Python packages or

If someone can give a precise description of the problem, I'll look at
it, I think I have done enough RPMs to find my way... The RPMs
generated by Distutils are often good enough, but sometimes need some
manual cleanup.

> distutils (is distutils a separate thing or part of Python?) at all.

It is a part of Python since Python 1.6.

> installation manager.  We need these (very) early adopters, so I think
> that having a current Numeric RPM for i386 Linux (and the equivalent

I agree in principle, but providing Linux binary RPMs is becoming more
and more messy: it depends on the Python version and on the
distribution, sometimes even the distribution version number. That's a
lot of RPMs. Source RPMs are easier, with some care they should work
everywhere, but installation requires a compiler plus some of the
"-devel" packages that not everyone has.

> Also, it would be more consistent with the RPM naming scheme to call
> the RPM "python-Numeric" (or "python-numeric", or even "numpy") rather
> than just "Numeric".  If that's hard or philosophically undesirable,

Agreed.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hi...@cn...
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------

Re: [Numpy-discussion] RPMs out of date, have problems

[Gerard V. <gve...@la...>]

Hi,

Try

python setup.py bdist_rpm

Works like a charm.
The same for the subdirectories/subpackages (maybe
after installation of the main RPMs).

Gerard

PS: it is impossible to provide binary RPMs, because
there are too many different Linux distributions.

On Wednesday 02 January 2002 20:29, Joe Harrington wrote:
> Hi folks,
>
> Problem:
>
> The latest Numeric release on the web site is 20.3.  The latest with
> an RPM is 20.1, and that RPM has a problem: it creates a directory in
> the system root directory.  Paul D. says he will implement a solution
> but doesn't have the experience with RPMs (or the time) to find the
> problem quickly.  I haven't dealt with building Python packages or
> distutils (is distutils a separate thing or part of Python?) at all.
> Can someone with the relevant experience fix the current problem and
> help Paul implement the solution so he can post current RPMs that
> install right?  Ditto anyone who knows how to make packages for Debian,
> Solaris, and other popular package managers.
>
> Rationale:
>
> As I've mentionned previously, I'm getting an increasing number of
> queries from astronomers who want to play with Numeric.  At this stage
> many of the converts will be application code contributors who will
> help build a library of discipline-specific routines.  In talking to
> these people, I am finding them less than patient with the good 'ol
> tarball (a position I take myself, following the experience of
> maintaining the Clue Files, see
> ftp://oobleck.astro.cornell.edu/pub/clues.tar.gz).  To them, it's not
> serious software if it isn't prepared under their system's
> installation manager.  We need these (very) early adopters, so I think
> that having a current Numeric RPM for i386 Linux (and the equivalent
> for i386 Debian GNU/Linux and Solaris Sparc architectures, if someone
> knows how to build them) would be a Good Thing.  Trivial install ->
> more users, more users -> more volunteers and more contributed code.
>
> Also, it would be more consistent with the RPM naming scheme to call
> the RPM "python-Numeric" (or "python-numeric", or even "numpy") rather
> than just "Numeric".  If that's hard or philosophically undesirable,
> don't bother, but the name has changed a few times, so I hope it isn't
> a big deal.  Sysadmins have to deal with more than 1000 packages now,
> and knowing what a package is just by looking at the name is a big
> help.  Also, you can do things like 'rpm -qa | grep python' and get a
> list of all the python-related packages on your system.  "Numeric" is
> too general outside the context of Python.
>
> All of the above goes for Numarray, when its developers are ready for
> the community at large to start writing code that uses it.
>
> Thanks,
>
> --jh--
>
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] RPMs out of date, have problems

[Scott R. <ra...@ph...>]

Hello All,

Debian (unstable -- which is actually quite stable) provides slightly more 
up-to-date packages of numeric (20.2) and its extensions.  You can find them 
here:

http://packages.debian.org/unstable/math/python-numeric.html
http://packages.debian.org/unstable/interpreters/python-numeric-ext.html

For a quick hack at a more up-to-date RPM, it _might_ be possible to use 
alien to convert the *.debs to *.rpms...

Scott

PS:  As an astronomer myself, I am also seeing an increasing interest in my 
collegues towards python and numeric (especially since I keep preaching the 
Python gospel to them ;)

On January 2, 2002 02:29 pm, Joe Harrington wrote:
> Hi folks,
>
> Problem:
>
> The latest Numeric release on the web site is 20.3.  The latest with
> an RPM is 20.1, and that RPM has a problem: it creates a directory in
> the system root directory.  Paul D. says he will implement a solution
> but doesn't have the experience with RPMs (or the time) to find the
> problem quickly.  I haven't dealt with building Python packages or
> distutils (is distutils a separate thing or part of Python?) at all.
> Can someone with the relevant experience fix the current problem and
> help Paul implement the solution so he can post current RPMs that
> install right?  Ditto anyone who knows how to make packages for Debian,
> Solaris, and other popular package managers.
>
> Rationale:
>
> As I've mentionned previously, I'm getting an increasing number of
> queries from astronomers who want to play with Numeric.  At this stage
> many of the converts will be application code contributors who will
> help build a library of discipline-specific routines.  In talking to
> these people, I am finding them less than patient with the good 'ol
> tarball (a position I take myself, following the experience of
> maintaining the Clue Files, see
> ftp://oobleck.astro.cornell.edu/pub/clues.tar.gz).  To them, it's not
> serious software if it isn't prepared under their system's
> installation manager.  We need these (very) early adopters, so I think
> that having a current Numeric RPM for i386 Linux (and the equivalent
> for i386 Debian GNU/Linux and Solaris Sparc architectures, if someone
> knows how to build them) would be a Good Thing.  Trivial install ->
> more users, more users -> more volunteers and more contributed code.
>
> Also, it would be more consistent with the RPM naming scheme to call
> the RPM "python-Numeric" (or "python-numeric", or even "numpy") rather
> than just "Numeric".  If that's hard or philosophically undesirable,
> don't bother, but the name has changed a few times, so I hope it isn't
> a big deal.  Sysadmins have to deal with more than 1000 packages now,
> and knowing what a package is just by looking at the name is a big
> help.  Also, you can do things like 'rpm -qa | grep python' and get a
> list of all the python-related packages on your system.  "Numeric" is
> too general outside the context of Python.
>
> All of the above goes for Numarray, when its developers are ready for
> the community at large to start writing code that uses it.
>
> Thanks,
>
> --jh--
>
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

-- 
Scott M. Ransom              Address:  McGill Univ. Physics Dept.
Phone:  (514) 398-6492                 3600 University St., Rm 338
email:  ra...@ph...       Montreal, QC  Canada H3A 2T8 
GPG Fingerprint: 06A9 9553 78BE 16DB 407B  FFCA 9BFA B6FF FFD3 2989

[Numpy-discussion] RPMs out of date, have problems

[Joe H. <jh...@oo...>]

Hi folks,

Problem:

The latest Numeric release on the web site is 20.3.  The latest with
an RPM is 20.1, and that RPM has a problem: it creates a directory in
the system root directory.  Paul D. says he will implement a solution
but doesn't have the experience with RPMs (or the time) to find the
problem quickly.  I haven't dealt with building Python packages or
distutils (is distutils a separate thing or part of Python?) at all.
Can someone with the relevant experience fix the current problem and
help Paul implement the solution so he can post current RPMs that
install right?  Ditto anyone who knows how to make packages for Debian,
Solaris, and other popular package managers.

Rationale:

As I've mentionned previously, I'm getting an increasing number of
queries from astronomers who want to play with Numeric.  At this stage
many of the converts will be application code contributors who will
help build a library of discipline-specific routines.  In talking to
these people, I am finding them less than patient with the good 'ol
tarball (a position I take myself, following the experience of
maintaining the Clue Files, see
ftp://oobleck.astro.cornell.edu/pub/clues.tar.gz).  To them, it's not
serious software if it isn't prepared under their system's
installation manager.  We need these (very) early adopters, so I think
that having a current Numeric RPM for i386 Linux (and the equivalent
for i386 Debian GNU/Linux and Solaris Sparc architectures, if someone
knows how to build them) would be a Good Thing.  Trivial install ->
more users, more users -> more volunteers and more contributed code.

Also, it would be more consistent with the RPM naming scheme to call
the RPM "python-Numeric" (or "python-numeric", or even "numpy") rather
than just "Numeric".  If that's hard or philosophically undesirable,
don't bother, but the name has changed a few times, so I hope it isn't
a big deal.  Sysadmins have to deal with more than 1000 packages now,
and knowing what a package is just by looking at the name is a big
help.  Also, you can do things like 'rpm -qa | grep python' and get a
list of all the python-related packages on your system.  "Numeric" is
too general outside the context of Python.

All of the above goes for Numarray, when its developers are ready for
the community at large to start writing code that uses it.

Thanks,

--jh--

[Numpy-discussion] Numeric 21.0a1 in CVS

[Paul F. D. <pa...@pf...>]

Version 21.0a1 -- in CVS only
Please help me test the following. I have tested on Windows / Python
2.2.

Implement true division operations for Python 2.2 (Bruce Sherwood, our
hero).

New functions in Numeric; they work on any sequence a that can be
converted to a
Numeric array.

        def rank (a):
            "Get the rank of a (the number of dimensions, not a matrix
rank)"
        def shape (a):
            "Get the shape of a"
        def size (a, axis=None):
            "Get the number of elements in a, or along a certain axis."
                                
        def average (a, axis=0, weights=None, returned = 0):
            """average(a, axis=0, weights=None)
               Computes average along indicated axis. 
               Inputs can be integer or floating types.
               Return type is floating but depends on spacesaver flags.
               If weights are given, result is
sum(a*weights)/sum(weights)
               weights if given must have a's shape or be the 1-d with
length the size
               of a in the given axis.
               If returned, return a tuple: the result and the sum of
the weights 
               or count of values.
               if axis is None, average over the entire array

               raises ZeroDivisionError if appropriate when result is
scalar.
            """

RE: [Numpy-discussion] trouble ingegrating Numpy arrays into a class statement

[Paul F. D. <pa...@pf...>]

Without asking why in the world you would want to do this:
class Cond:
    x1=0
    y1=0
    z1=0
    x2=0
    y2=0
    z2=0
    DelX=0
    DelY=0
    DelZ=0

wire = map(lambda dummy: Cond(), range(20))
print wire[10].x1

This makes a list. If you really INSIST on a Numeric array, add
import Numeric
wire = Numeric.array(wire)

But this will be an array of type O. If your real concern is that the
size will 
be huge, you might want to make arrays out of each member instead. You
have your choice of making the syntax wire.x1[10] or wire[10].x1, but
the latter requires additional technique.

Also I doubt that you mean what you said. If each instance is to have
its own values, and 
the ones above are just the initial values, it is much more proper to
do:
class Cond:
    def __init__ (self, **kw):
        d = { 'x1':0, ... put them all here }
        d.update(kw)
        for k, v in d.items():
            setattr(self, k, v)

That allows you to make instances all these way: Cond(), Cond(x1=4),
Cond(x1=1,y2=1), 
Cond(x1=0
    y1=0
    z1=0
    x2=0
    y2=0
    z2=0
    DelX=0
    DelY=0
    DelZ=0
)

-----Original Message-----
From: num...@li...
[mailto:num...@li...] On Behalf Of Rob
Sent: Monday, December 24, 2001 9:37 AM
To: num...@li...
Subject: [Numpy-discussion] trouble ingegrating Numpy arrays into a
class statement


I have this Class:

class Cond:
    x1=0
    y1=0
    z1=0
    x2=0
    y2=0
    z2=0
    DelX=0
    DelY=0
    DelZ=0

What I want is for Cond to be a Numpy array of 20 values, each with the
above members.  Thus I could say in a statement:

wire=Cond
a= wire[10].x1
b= wire[5].z2       etc...  

How can I go about this?  Thanks,  Rob.      and Merry Christmas!!!!!!!

ps. this is for an FEM-MOM grid generator



-- 
The Numeric Python EM Project

www.pythonemproject.com

_______________________________________________
Numpy-discussion mailing list Num...@li...
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

[Numpy-discussion] trouble ingegrating Numpy arrays into a class statement

[Rob <ro...@py...>]

I have this Class:

class Cond:
    x1=0
    y1=0
    z1=0
    x2=0
    y2=0
    z2=0
    DelX=0
    DelY=0
    DelZ=0

What I want is for Cond to be a Numpy array of 20 values, each with the
above members.  Thus I could say in a statement:

wire=Cond
a= wire[10].x1
b= wire[5].z2       etc...  

How can I go about this?  Thanks,  Rob.      and Merry Christmas!!!!!!!

ps. this is for an FEM-MOM grid generator



-- 
The Numeric Python EM Project

www.pythonemproject.com

Re: [Numpy-discussion] Re: my Numpy statements are slower than indexed formulations in somecases

[Rob <ro...@py...>]

Problem solved.  I had one last for loop in there.  Its odd that as I
gradually got rid of the for loops, the speed went down, but when I got
rid of the last on, bingo!   That routine now runs at a 1/10 of its
original time.  Rob.


Rob wrote:
> 
> Rob wrote:
> >
> > I have a number of thse routines in some EM code.  I've tried to
> > Numpyize them, but end up with code that runs even slower.
> >
> > Here is the old indexed routing:
> >
> > -----------------
> > for JJ in range(0,TotExtMetalEdgeNum):
> >
> >     McVector+=Ccc[0:TotExtMetalEdgeNum,JJ] * VcVector[JJ]
> > ----------------
> >
> > Here is the Numpy version:
> >
> > ---------------------
> > McVector= add.reduce(transpose(Ccc[...] * VcVector[...]))
> > ---------------------
> >
> > I wonder if there is another faster way to do this?  Thanks,  Rob.
> >
> > --
> 
> I did speed things up just a tiny bit by using:
> 
> add.reduce(Ccc*VcVector,1) instead of
> add.reduce(transpose(Ccc*VcVector).
> 
> But I'm still running way slower than an indexed array scheme.   Rob.
> > The Numeric Python EM Project
> >
> > www.pythonemproject.com
> 
> --
> The Numeric Python EM Project
> 
> www.pythonemproject.com
> 
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

-- 
The Numeric Python EM Project

www.pythonemproject.com

[Numpy-discussion] Re: my Numpy statements are slower than indexed formulations in some cases

[Rob <ro...@py...>]

Rob wrote:
> 
> I have a number of thse routines in some EM code.  I've tried to
> Numpyize them, but end up with code that runs even slower.
> 
> Here is the old indexed routing:
> 
> -----------------
> for JJ in range(0,TotExtMetalEdgeNum):
> 
>     McVector+=Ccc[0:TotExtMetalEdgeNum,JJ] * VcVector[JJ]
> ----------------
> 
> Here is the Numpy version:
> 
> ---------------------
> McVector= add.reduce(transpose(Ccc[...] * VcVector[...]))
> ---------------------
> 
> I wonder if there is another faster way to do this?  Thanks,  Rob.
> 
> --

I did speed things up just a tiny bit by using:

add.reduce(Ccc*VcVector,1) instead of
add.reduce(transpose(Ccc*VcVector).

But I'm still running way slower than an indexed array scheme.   Rob.
> The Numeric Python EM Project
> 
> www.pythonemproject.com

-- 
The Numeric Python EM Project

www.pythonemproject.com

[Numpy-discussion] next step for numarray

[Perry G. <pe...@st...>]

I just thought I would write a few words about what will be
happening with numarray development. At the moment it is
quiescent since we have another internal project to finish.
Hopefully that will be done in 3 weeks or so; we will start
work on numarray again. I've gotten feedback from Guido
regarding the safety issue; he made it clear that we should
not be able to let the user crash Python, even if they can
do that only by bypassing the public interface. Since there
may be implications for the C-API we are making that our
highest priority (though I don't think it will seriously
change the API).

Thanks for the feedback so far. We will raise other 
specific issues as we get closer to dealing with them.

Perry

RE: [Numpy-discussion] float** arrays and Numarray

[Perry G. <pe...@st...>]

> I use Numeric to transfer images between various image processing 
> systems. Numarray includes most of the image data memory layouts that I 
> have seen except for:
> 
> Some C types need to be added (as several people have already commented).
> 
> Some systems define an array as a "pointer to an array of pointers to 
> ...". "Numerical Recipes in C" explains this approach clearly. Could 
> this perhaps be implemented in Numarray as a buffer interface with 
> multiple data segments?
> 
> Thanks,
> Ed Jones

That's an interesting question. I don't think that such a representation
makes much sense for numarray internally (for example, it makes it
difficult to reshape the object without creating new pointer arrays--
or data segments as mentioned above). I doubt that we would take
this approach.

On the other hand, I don't see why the C-API could not create such
a representation (i.e., creating the necessary pointer arrays). 
I guess the  main question is whether how memory mangement is
done for these pointer arrays since they are not part of the
numarray object (one may have to explicitly deallocate them
in the C code). The main usefulness of this approach is that 
it allows a simple indexing notation multidimensional arrays in
C. (On the other hand, perhaps the same could be largely accomplished
with C macros.) A drawback is that it can imply significant memory
overheads if the shape of the array is skinny in the wrong dimension.

But no, we haven't really thought much about it yet.

Perry

Re: [Numpy-discussion] converting IDL to python

[eric <er...@en...>]

I'm not an IDL user, but have thought some about the same sort of project
for either executing Matlab scripts from Python, or perhaps translating them
to Python.  On the face of it, it seems doable.  Of the incompatibilities
I've thought about, the magic NARGOUT variable that tells Matlab how many
output results are expected from a functions seems the most difficult.  It
might be handled in Python by examining the parse tree, but it isn't a
trivial translation.

Another option would be embedding Octave which is a Matlab work alike.  I
think it is a little behind the current Matlab release though.

There might be some synergy between projects aiming to execute IDL/Matlab
code from Python.

eric


----- Original Message -----
From: "Rick White" <rl...@st...>
To: "Mark Fardal" <fa...@co...>
Cc: "numpy" <num...@li...>
Sent: Wednesday, December 19, 2001 12:30 AM
Subject: Re: [Numpy-discussion] converting IDL to python


> On Tue, 18 Dec 2001, Mark Fardal wrote:
>
> > earlier this month Joe Harrington posted this:
> >
> >   NASA's immediate objective will be a complete data-analysis system to
> >   replace IDL, in short order, including an IDL-to-python converter
> >   program.  That shouldn't be hard as IDL is a simple language, and PyDL
> >   may have solved much of that problem.
> >
> > I'm an IDL user, and I'm currently trying to see if I can switch over
> > to python.  It strikes me that an IDL-to-python converter program is a
> > VERY ambitious idea.  While IDL's syntax is rather similar to Python,
> > and less powerful (so that there is less to translate), there are
> > enough differences between them that conversion is probably not a
> > simple task.  For example, in IDL:
> >
> >   arguments are passed by reference
> >   array storage order is different
> >   there's a different notion of "truth" than in Python
> >   a structure type exists, and a notation for slicing arrays of
structures
> >   trailing "degenerate" array dimensions are truncated in a
hard-to-predict way
> >   array subscripting generates copy, not reference
> >
> > I'm sure there are some other big differences too.
>
> I'm thinking about this problem too.  For the PyRAF system
> (pyraf.stsci.edu), I wrote a set of Python programs that parse IRAF CL
> scripts and automatically translate them to Python.  CL scripts have a
> much less regular syntax than IDL (making them harder to parse), but the
> CL has a vastly more limited functionality (making it easier to translate
> the results to IDL.)  I did have to deal with issues similar to those
> above.  E.g., the CL does pass arguments by reference (sometimes -- I told
> you it is irregular!) and I figured out how to handle that.  The array
> storage order doesn't strike me as a biggie, it is just necessary to swap
> the order of indices.  The CL also has a different notion of truth
> (boolean expressions have the value yes or no, which are magic values
> along the lines of None in Python.)  The IDL notion of truth is really
> pretty similar to Python's when you get down to it.
>
> The new numeric array module that we have been working on (numarray) also
> supports the equivalent of arrays of structures that can be sliced and
> indexed just like arrays of numbers.  We had IDL structures (among other
> things) in mind when we developed this capability, and think our version
> is a significant improvement over IDL.  We also have arrays of strings
> and aim to have all the basic array functionality that is available in
> IDL.  (By the way, I'm a long-time IDL user and am reasonably expert in
it.)
>
> The hardest part (as you mention) is that IDL has a really large
> collection of built-in functions which probably will not be readily
> available in Python.  Until someone writes things like the morphological
> dilation and erosion operations, it won't be possible to translate IDL
> programs that use them.  And there will always be some weird corners of
> IDL behavior where it just would not be worth the effort to try to
> replicate exactly what IDL does.  That's true in the CL translation too
> -- but it does not seem to be a big limitation, because users tend to stay
> away from those weird spots too.
>
> My conclusion is that an automatic conversion of (most) IDL to Python
> probably can be done with a reasonable amount of work.  It certainly is
> not trivial, but I think (based on my experience with the CL) that it is
> not impossibly difficult either.  I'm hoping to take a shot at this
> sometime during the next 6 months.
> Rick
>
> Richard L. White    rl...@st...    http://sundog.stsci.edu/rick/
> Space Telescope Science Institute
> Baltimore, MD
>
>
>
>
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

Re: [Numpy-discussion] converting IDL to python

[<jm...@en...>]

"eric" <er...@en...> writes:

> I'm not familiar with these erosion and dialation functions.  Are they
> something that should be in SciPy?  We could start an "idl" package that
> houses functions familiar to this community.  Or maybe they should live in
> another place like "signal" or maybe an image processing package.
> Thoughts?

Dilation and erosion are image processing functions used to "grow" and
"shrink" objects and boundaries.  They are part of a group of image
operators based on the theory of mathematical morphology.  Overall,
they are very extremely useful for shape/size analysis on images.

Yes, they should certainly be part of any image processing toolbox for
Python.  Here is a link for a commercial math. morphology toolbox for
matlab: http://www.mmorph.com

- Joe

-- 
Joseph M. Reinhardt, Ph.D.   Department of Biomedical Engineering
joe...@ui...      University of Iowa, Iowa City, IA  52242
Telephone: 319-335-5634      FAX:       319-335-5631

Re: [Numpy-discussion] converting IDL to python

[eric <er...@en...>]

Rick and Joe,

I'm not familiar with these erosion and dialation functions.  Are they
something that should be in SciPy?  We could start an "idl" package that
houses functions familiar to this community.  Or maybe they should live in
another place like "signal" or maybe an image processing package.  Thoughts?

I've crossed posted this to the sci...@sc... list as this is probably
the best place to continue such a discussion.

eric


----- Original Message -----
From: "Joe Reinhardt" <jm...@en...>
To: <num...@li...>
Sent: Wednesday, December 19, 2001 11:12 PM
Subject: [Numpy-discussion] converting IDL to python


>
> Rick White writes:
> > The hardest part (as you mention) is that IDL has a really large
> > collection of built-in functions which probably will not be readily
> > available in Python.  Until someone writes things like the morphological
> > dilation and erosion operations, it won't be possible to translate IDL
> > programs that use them.
>
> By the way, I do have binary erosion and dilation, along with
> connected components analysis, flood fill region grow, and several
> other common 2D/3D image processing functions working in NumPy.
>
> I would be glad to share them.    I don't know how similar the
> interface is to IDL, since I have never used IDL.
>
> - Joe Reinhardt
>
>
>
> --
> Joseph M. Reinhardt, Ph.D.   Department of Biomedical Engineering
> joe...@ui...      University of Iowa, Iowa City, IA  52242
> Telephone: 319-335-5634      FAX:       319-335-5631
>
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

[Numpy-discussion] converting IDL to python

[<jm...@en...>]

Rick White writes:
> The hardest part (as you mention) is that IDL has a really large
> collection of built-in functions which probably will not be readily
> available in Python.  Until someone writes things like the morphological
> dilation and erosion operations, it won't be possible to translate IDL
> programs that use them.  

By the way, I do have binary erosion and dilation, along with
connected components analysis, flood fill region grow, and several
other common 2D/3D image processing functions working in NumPy.  

I would be glad to share them.    I don't know how similar the
interface is to IDL, since I have never used IDL.

- Joe Reinhardt



-- 
Joseph M. Reinhardt, Ph.D.   Department of Biomedical Engineering
joe...@ui...      University of Iowa, Iowa City, IA  52242
Telephone: 319-335-5634      FAX:       319-335-5631

[Numpy-discussion] float** arrays and Numarray

[Edward C. J. <edc...@er...>]

I use Numeric to transfer images between various image processing 
systems. Numarray includes most of the image data memory layouts that I 
have seen except for:

Some C types need to be added (as several people have already commented).

Some systems define an array as a "pointer to an array of pointers to 
...". "Numerical Recipes in C" explains this approach clearly. Could 
this perhaps be implemented in Numarray as a buffer interface with 
multiple data segments?

Thanks,
Ed Jones

Re: [Numpy-discussion] converting IDL to python

[Rick W. <rl...@st...>]

On Tue, 18 Dec 2001, Mark Fardal wrote:

> earlier this month Joe Harrington posted this:
> 
>   NASA's immediate objective will be a complete data-analysis system to
>   replace IDL, in short order, including an IDL-to-python converter
>   program.  That shouldn't be hard as IDL is a simple language, and PyDL
>   may have solved much of that problem.
> 
> I'm an IDL user, and I'm currently trying to see if I can switch over
> to python.  It strikes me that an IDL-to-python converter program is a
> VERY ambitious idea.  While IDL's syntax is rather similar to Python,
> and less powerful (so that there is less to translate), there are
> enough differences between them that conversion is probably not a
> simple task.  For example, in IDL:
> 
>   arguments are passed by reference
>   array storage order is different
>   there's a different notion of "truth" than in Python
>   a structure type exists, and a notation for slicing arrays of structures
>   trailing "degenerate" array dimensions are truncated in a hard-to-predict way
>   array subscripting generates copy, not reference
> 
> I'm sure there are some other big differences too.  

I'm thinking about this problem too.  For the PyRAF system
(pyraf.stsci.edu), I wrote a set of Python programs that parse IRAF CL
scripts and automatically translate them to Python.  CL scripts have a
much less regular syntax than IDL (making them harder to parse), but the
CL has a vastly more limited functionality (making it easier to translate
the results to IDL.)  I did have to deal with issues similar to those
above.  E.g., the CL does pass arguments by reference (sometimes -- I told
you it is irregular!) and I figured out how to handle that.  The array
storage order doesn't strike me as a biggie, it is just necessary to swap
the order of indices.  The CL also has a different notion of truth
(boolean expressions have the value yes or no, which are magic values
along the lines of None in Python.)  The IDL notion of truth is really
pretty similar to Python's when you get down to it.

The new numeric array module that we have been working on (numarray) also
supports the equivalent of arrays of structures that can be sliced and
indexed just like arrays of numbers.  We had IDL structures (among other
things) in mind when we developed this capability, and think our version
is a significant improvement over IDL.  We also have arrays of strings
and aim to have all the basic array functionality that is available in
IDL.  (By the way, I'm a long-time IDL user and am reasonably expert in it.)

The hardest part (as you mention) is that IDL has a really large
collection of built-in functions which probably will not be readily
available in Python.  Until someone writes things like the morphological
dilation and erosion operations, it won't be possible to translate IDL
programs that use them.  And there will always be some weird corners of
IDL behavior where it just would not be worth the effort to try to
replicate exactly what IDL does.  That's true in the CL translation too
-- but it does not seem to be a big limitation, because users tend to stay
away from those weird spots too.

My conclusion is that an automatic conversion of (most) IDL to Python
probably can be done with a reasonable amount of work.  It certainly is
not trivial, but I think (based on my experience with the CL) that it is
not impossibly difficult either.  I'm hoping to take a shot at this
sometime during the next 6 months.
				Rick

Richard L. White    rl...@st...    http://sundog.stsci.edu/rick/
Space Telescope Science Institute
Baltimore, MD

[Numpy-discussion] converting IDL to python

[Mark F. <fa...@co...>]

Hi,

earlier this month Joe Harrington posted this:

  NASA's immediate objective will be a complete data-analysis system to
  replace IDL, in short order, including an IDL-to-python converter
  program.  That shouldn't be hard as IDL is a simple language, and PyDL
  may have solved much of that problem.

I'm an IDL user, and I'm currently trying to see if I can switch over
to python.  It strikes me that an IDL-to-python converter program is a
VERY ambitious idea.  While IDL's syntax is rather similar to Python,
and less powerful (so that there is less to translate), there are
enough differences between them that conversion is probably not a
simple task.  For example, in IDL:

  arguments are passed by reference
  array storage order is different
  there's a different notion of "truth" than in Python
  a structure type exists, and a notation for slicing arrays of structures
  trailing "degenerate" array dimensions are truncated in a hard-to-predict way
  array subscripting generates copy, not reference

I'm sure there are some other big differences too.  

Then there is major functionality in IDL that is missing in Python. *
(Like plotting. :-)  It's hard to translate a routine when you have
nothing to translate it to.

I've looked at PyDL.  It seems a nice little crutch, and it makes the
learning curve a little shallower for people converting from IDL to
Python.  It's very far from being a complete translation from one
language to the other.

I don't know what Joe had in mind for a converter program.  One that
took care of braindead syntax conversion, while leaving the more
difficult issues for a human programmer to translate, might not be too
hard and could be pretty useful.  I think it would be a bad idea to
hold out for something that automatically produced working code.

my $.02 (worth only $0.0127 US)
Mark Fardal
University of Victoria

* I'm stuck in Python 1.5 until the New Year, so have yet to see what
SciPy has to offer.  Maybe SciPy-Sumo is getting close.

[Numpy-discussion] Windows / 2.2 version up

[Paul F. D. <pa...@pf...>]

I built the Windows installers for Python-2.2 and they should appear at
sourceforge shortly.

Re: Need help with bdist_wininst, was Re: [Python-Dev] RE: [Numpy-discussion] Python 2.2

[<ba...@zo...>]

>>>>> "TH" == Thomas Heller <tho...@io...> writes:

    TH> I've just fixed the bdist_wininst command in CVS.  There is
    TH> not much time left before the release of Python 2.2 (how much
    TH> exactly?).

About 3 days. :)

-Barry

RE: Need help with bdist_wininst, was Re: [Python-Dev] RE: [Numpy-discussion] Python 2.2

[Tim P. <ti...@zo...>]

[Thomas Heller]
> I've just fixed the bdist_wininst command in CVS.

Thank you!
> There is not much time left before the release of Python 2.2 (how 
> much exactly?).

2.2 final should be released this Friday.

Re: Need help with bdist_wininst, was Re: [Python-Dev] RE: [Numpy-discussion] Python 2.2

[M.-A. L. <ma...@le...>]

Thomas Heller wrote:
> 
> I've just fixed the bdist_wininst command in CVS.
> There is not much time left before the release of Python 2.2 (how much exactly?).
> 
> To make sure that the current version works correctly, I would
> kindly request some testers to build windows installers from some
> of their package distributions, and check them to make sure they work
> correctly.
> 
> The full story is in bug [#483982]: Python 2.2b2 bdist_wininst crashes:
> http://sourceforge.net/tracker/index.php?func=detail&aid=483982&group_id=5470&atid=105470
> 
> To test the new version, you only have to replace the file
> Lib/distutils/command/bdist_wininst.py in your Python 2.2 distribution
> with the new one from CVS (rev 1.27):
> 
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Lib/distutils/command/bdist_wininst.py

FYI, I just tested it with egenix-mx-base and egenix-mx-commercial
and both seem to work just fine.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                   http://www.egenix.com/files/python/

Need help with bdist_wininst, was Re: [Python-Dev] RE: [Numpy-discussion] Python 2.2

[Thomas H. <tho...@io...>]

I've just fixed the bdist_wininst command in CVS.
There is not much time left before the release of Python 2.2 (how much exactly?).

To make sure that the current version works correctly, I would
kindly request some testers to build windows installers from some
of their package distributions, and check them to make sure they work
correctly.

The full story is in bug [#483982]: Python 2.2b2 bdist_wininst crashes:
http://sourceforge.net/tracker/index.php?func=detail&aid=483982&group_id=5470&atid=105470

To test the new version, you only have to replace the file
Lib/distutils/command/bdist_wininst.py in your Python 2.2 distribution
with the new one from CVS (rev 1.27):

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Lib/distutils/command/bdist_wininst.py

Thanks,

Thomas

RE: [Python-Dev] RE: [Numpy-discussion] Python 2.2

[Paul F. D. <pa...@pf...>]

I am on Windows Me, so there is no concept of administrator.

-----Original Message-----
From: num...@li...
[mailto:num...@li...] On Behalf Of Guido
van Rossum
Sent: Monday, December 17, 2001 8:16 AM
To: Paul F. Dubois
Cc: 'Ray Drew'; num...@li...;
pyt...@py...
Subject: Re: [Python-Dev] RE: [Numpy-discussion] Python 2.2


> I downloaded and installed 2.2c1 and built the Numeric installers. 
> However, when I run them they all fail when the installation begins 
> (after one clicks the final click to install) with an access 
> violation. I removed any previous Numeric and it still happened.
> 
> Building and installing with setup.py install works ok.

I don't know anything about your installers, but could it be that you
were trying to install without Administrator permissions?  That used to
crash the previous Python installer too.  (The new one doesn't, but it's
a commercial product so we can't share it.)

--Guido van Rossum (home page: http://www.python.org/~guido/)

_______________________________________________
Numpy-discussion mailing list Num...@li...
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Python-Dev] RE: [Numpy-discussion] Python 2.2

[Thomas H. <tho...@io...>]

> I downloaded and installed 2.2c1 and built the Numeric installers.
> However, when I run them they all fail when the installation begins
> (after one clicks the final click to install) with an access violation.
> I removed any previous Numeric and it still happened.
> 
> Building and installing with setup.py install works ok.
> 
Are you talking about bdist_wininst installers?
I just could reproduce a problem with them (after renaming
away all my zip.exe programs in the PATH).

Thomas