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

[Numpy-discussion] Tagging releases under CVS (was RE: [Numpy-discussion] Building Numpy under Python 1.6, Windows)

[Jonathan M. G. <jon...@va...>]

To tag the version you currently have checked out, go into the root 
directory of the module (e.g., Numeric) and AFTER CHECKING IN ALL 
MODIFICATIONS do

cvs tag [-c] <symbolic-tag>

where <symbolic-tag> is the tag name. This will apply <symbolic-tag> to the 
current revision of each file that you have checked out. It is important to 
note that the tag is applied to the repository so it is essential that you 
check in all modified files and resolve conflicts BEFORE tagging the 
repository. The -c flag tells cvs to check that all files in the local 
directory are unmodified and warns you if they are not.

The restrictions on the tag name are not well-documented, but if they match 
the regular expression

^[A-Za-z][A-Za-z_0-9-]+$

they will work (i.e., matching this regex is a sufficient but perhaps not 
necessary condition). Tags that begin with [0-9] or that contain [ \t.,;:] 
will not work.

If you want to go back and tag old releases without checking them out, then 
if there is a target date that you can use to identify the version (e.g., a 
release date), you can run

cvs rtag -D <date> <symbolic-tag> <module>

Where <date> is the date. For format, the following excerpt from the 
Cederqvist manual may help:

>A wide variety of date formats are supported by CVS.  The most standard 
>ones are ISO8601 (from the International Standards Organization) and the 
>Internet e-mail standard (specified in RFC822 as amended by RFC1123).
>
>ISO8601 dates have many variants but a few examples are:
>
>1972-09-24
>1972-09-24 20:05

This command will tag all files in <module> at the latest revision on or 
before <date> with tag <symbolic-tag>.

I hope this is helpful to you.

At 05:29 PM 9/18/2000, Paul F. Dubois wrote:
>We haven't been doing cvs tags. I suppose if I could remember how to do them
>I would do them when I am the one cutting the release (CVS is not my usual
>source control system).

Best regards,
Jonathan

RE: [Numpy-discussion] Building Numpy under Python 1.6, Windows

[Paul F. D. <pau...@ho...>]

Would you try syncing up to the repository and try again? I redid this stuff
over the weekend because so many people are having trouble. The thing should
build in lapack by default and it is in an optional package to boot. I
didn't announce this because I wanted some of my fellow developers to suffer
first, but they don't seem to be in a suffering mood today.

Do cvs update -d -P to get the new structure.

We haven't been doing cvs tags. I suppose if I could remember how to do them
I would do them when I am the one cutting the release (CVS is not my usual
source control system).


> -----Original Message-----
> From: num...@li...
> [mailto:num...@li...]On Behalf Of
> Jonathan M. Gilligan
> Sent: Monday, September 18, 2000 2:34 PM
> To: num...@li...
> Cc: Jonathan M. Gilligan
> Subject: [Numpy-discussion] Building Numpy under Python 1.6, Windows
>
>
> I have recently upgraded to Python 1.6 (final). Now I can't
> figure out how
> to build Numpy with lapack_lite under windows. There is not a
> makefile for
> lapack_lite for MSVC and the instructions in README don't really
> help. All
> that setup.py will do is complain that lapack_lite is not installed.
>

[Numpy-discussion] Problem Solved Re: Building Numpy under Python 1.6, Windows

[Jonathan M. G. <jon...@va...>]

I have solved my problem building numpy under Python 1.6, windows. The 
problem was that Demos/NumTut/greece.pik was improperly checked into the 
CVS repository as a text file, when it should have been binary.

Jonathan

[Numpy-discussion] Building Numpy under Python 1.6, Windows

[Jonathan M. G. <jon...@va...>]

I have recently upgraded to Python 1.6 (final). Now I can't figure out how 
to build Numpy with lapack_lite under windows. There is not a makefile for 
lapack_lite for MSVC and the instructions in README don't really help. All 
that setup.py will do is complain that lapack_lite is not installed.

Specifically, are there specific compiler flags that I need to use to 
compile lapack lite? Should I just emulate the unix version and do

cl -c *.c
lib -out:blas.lib blas_lite.obj
lib -out:lapack.lib dlapack_lite.obj f2c_lite.obj zlapack_lite.obj

I tried doing this, but when I try to run the NumTut examples, I get the 
following error:

D:\Programming\python\Numerical\Demo>python
Python 1.6 (#0, Sep  5 2000, 08:16:13) [MSC 32 bit (Intel)] on win32
Copyright (c) 1995-2000 Corporation for National Research Initiatives.
All Rights Reserved.
Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam.
All Rights Reserved.
 >>> import NumTut
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "NumTut\__init__.py", line 14, in ?
     greece = pickle.load(open(os.path.join(_dir, 'greece.pik'), 'rb')) / 256.0
   File "D:\Programming\python\Python 1.6\lib\pickle.py", line 855, in load
     return Unpickler(file).load()
   File "D:\Programming\python\Python 1.6\lib\pickle.py", line 515, in load
     dispatch[key](self)
   File "D:\Programming\python\Python 1.6\lib\pickle.py", line 688, in 
load_globa
l
     klass = self.find_class(module, name)
   File "D:\Programming\python\Python 1.6\lib\pickle.py", line 698, in 
find_class

     raise SystemError, \
  from module Numericto import class array_constructor
 >>>


FWIW, I am using the versions from 
:pserver:ano...@cv...:/cvsroot/numpy, module 
Numerical, checked out as of Sept. 14. I didn't see any tags defined in the 
repository corresponding to release 16.x. Did I miss something? Should the 
releases not be getting tagged in the CVS repository?

Thanks for any pointers,
Jonathan

[Numpy-discussion] Re: New put function

[Travis O. <Oli...@ma...>]

Paul,

Great job on the new put function.  I can't wait to try it out.  This goes
a long way towards eliminating one of the few complaints I've heard about
Numerical Python when compared to other similar environments. 

-Travis

Re: [Numpy-discussion] Numeric addition: put

[David A. <Da...@Ac...>]

> In the CVS sources there is now a new function "put".
> "put" is roughly the opposite of "take"

yeah!  Go, Paul, Go!

=)

--david

[Numpy-discussion] Numeric addition: put

[Paul F. D. <pau...@ho...>]

In the CVS sources there is now a new function "put".
"put" is roughly the opposite of "take"

put(x, indices, values) is roughly
    x.flat[j] = values[j] for all j in indices

The fine print will appear in the manuals shortly.

Re: [Numpy-discussion] Da Blas

[Robert K. <ke...@it...>]

On Sat, 16 Sep 2000, Frank Horowitz wrote:

> At 11:30 AM -0400 9/15/00, Scott M. Ransom wrote:
> >Frank Horowitz wrote:
> >>
> >> However, when I
> >> coerced the distutils system to get around that bug (by specifying
> >> "/usr/lib " with a trailing blank for the BLASLIBDIR and LAPACKLIBDIR
> >> variables in setup.py) the same problem (i.e. an "ImportError:
> >> /usr/lib/liblapack.so.3: undefined symbol: e_wsfe" in importing
> >> lapack_lite) ultimately manifested itself.
> >
> >This problem is easily fixed (at least on linux) by performing the link
> >of lapack_lite.so with g77 instead of gcc (this is required because the
> >lapack and/or blas libraries are based on fortran object files...).
> 
> Good on ya, Scott. You nailed it. When I did this by hand, it worked. What
> I now need to figure out is how to coerce distutils into doing that
> automagically so others can benefit without this pain!

Adding "-lg2c" to the end of the gcc (not g77) link line always did the
trick for me with FORTRAN libraries. I'm not sure if g77 does anything
more than that compared with gcc for linking.

> 	Cheers,
> 		Frank Horowitz

--
Robert Kern
ke...@ca...

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter

Re: [Numpy-discussion] Da Blas

[Frank H. <fr...@ne...>]

At 11:30 AM -0400 9/15/00, Scott M. Ransom wrote:
>Frank Horowitz wrote:
>>
>> However, when I
>> coerced the distutils system to get around that bug (by specifying
>> "/usr/lib " with a trailing blank for the BLASLIBDIR and LAPACKLIBDIR
>> variables in setup.py) the same problem (i.e. an "ImportError:
>> /usr/lib/liblapack.so.3: undefined symbol: e_wsfe" in importing
>> lapack_lite) ultimately manifested itself.
>
>This problem is easily fixed (at least on linux) by performing the link
>of lapack_lite.so with g77 instead of gcc (this is required because the
>lapack and/or blas libraries are based on fortran object files...).

Good on ya, Scott. You nailed it. When I did this by hand, it worked. What
I now need to figure out is how to coerce distutils into doing that
automagically so others can benefit without this pain!

	Cheers,
		Frank Horowitz

Dr. Frank Horowitz                  __  \
CSIRO Exploration & Mining       ,~'  L_|\    Australian
39 Fairway, PO Box 437,       ;-'         \   Geodynamics
Nedlands, WA  6009  Australia (            \  Cooperative
      Phone +61 9 284 8431    +    ___     /  Research
      Fax   +61 9 389 1906     L~~'   "\__/   Centre
fr...@ne...                   W

Re: [Numpy-discussion] Da Blas

[Scott M. R. <ra...@cf...>]

Frank Horowitz wrote:
> 
> However, when I
> coerced the distutils system to get around that bug (by specifying
> "/usr/lib " with a trailing blank for the BLASLIBDIR and LAPACKLIBDIR
> variables in setup.py) the same problem (i.e. an "ImportError:
> /usr/lib/liblapack.so.3: undefined symbol: e_wsfe" in importing
> lapack_lite) ultimately manifested itself.

This problem is easily fixed (at least on linux) by performing the link
of lapack_lite.so with g77 instead of gcc (this is required because the
lapack and/or blas libraries are based on fortran object files...).

For instance the out-of-box link command on my machine (Debian 2.2) is:

gcc -shared build/temp.linux2/Src/lapack_litemodule.o -L/usr/local/lib
-L/usr/lib -llapack -lblas -o build/lib.linux2/lapack_lite.so

Simply change the 'gcc' to 'g77' and everything works nicely.

Not sure if this is specific to Linux or not...

Scott
 
-- 
Scott M. Ransom                   Address:  Harvard-Smithsonian CfA
Phone:  (617) 495-4142                      60 Garden St.  MS 10 
email:  ra...@cf...              Cambridge, MA  02138
GPG Fingerprint: 06A9 9553 78BE 16DB 407B  FFCA 9BFA B6FF FFD3 2989

Re: [Numpy-discussion] Da Blas

[Frank H. <fr...@ne...>]

At 3:14 PM -0700 14/9/00, <du...@us...> wrote:
>Well, I certainly didn't mean to flame anyone in particular, so I'm sorry
>that Frank was offended.

Publicly apologized, and publicly accepted. I'm sorry I lost my cool.

Ray Beausoleil and I are having a look at this too. He's coming at 
the problem from a Windows perspective, and I'm coming at it from a 
Linux/Unix perspective.

It's going to be a little slow going for me at first, since it 
appears that I'm going to have to get my head around the distutils 
way of doing things....

Just in case it saves anyone else following a false lead, yes, there 
is a bug in the (Linux Mandrake 7.1; but probably any unix-ish box) 
compile line for building the lapack_lite.so shared library (i.e. 
what is generated on my box is "-L/usr/lib-llapack" which obviously 
is missing a blank before the "-llapack" substring).  However, when I 
coerced the distutils system to get around that bug (by specifying 
"/usr/lib " with a trailing blank for the BLASLIBDIR and LAPACKLIBDIR 
variables in setup.py) the same problem (i.e. an "ImportError: 
/usr/lib/liblapack.so.3: undefined symbol: e_wsfe" in importing 
lapack_lite) ultimately manifested itself. So my advice is not to 
bother tracking that one down (although it probably should be 
reported as a bug in distutils, since adding that trailing blank 
algorithmically instead of in a user modifiable configuration string 
is the "right thing to do", TM.).

I'm still puzzled by Thomas Breul's report of preloading an f2c 
library squashing the bug under RedHat 6.2(?). That does not work 
under Mandrake, although clearly there is some bloody symbol table 
missing from somewhere. The trouble is to find out where, and then to 
coerce distutils to deal with that in a portable way...

	Frank
-- 
--
Frank Horowitz                                      fr...@ne...
CSIRO-Exploration & Mining, PO Box 437, Nedlands, WA 6009,       AUSTRALIA
Direct: +61 8 9284 8431;  FAX: +61 8 9389 1906; Reception: +61 8 9389 8421

[Numpy-discussion] Survey available on lapack_lite question

[Paul F. D. <pau...@ho...>]

I have started a survey on sourceforge which asks the question, should
lapack_lite and the modules that depend upon it be moved to the optional
Packages section.

Pros: this would move these modules out of a privleged position into
equality with other "application" packages. Their presence in the core is
unnecessary. The compilation problems, as yet unsolved, with lapack_lite vs.
alternate implementations, break the installation of the core even for
people who are not using the facilities.

Cons: It would require extra effort to install the Numerical distribution
from source and get back to the current status quo. Some people would be
confused at the changes.

Note: If we did it "right", and made these things into packages instead of
modules that install into Numeric, changes to scripts would be required, but
that is not being proposed here. My vision of this change is that they would
still install directly into Numeric, and would be included in all "prebuilt"
distributions.

[Numpy-discussion] Da Blas

[Paul F. D. <pau...@ho...>]

Well, I certainly didn't mean to flame anyone in particular, so I'm sorry
that Frank was offended. I suppose I got irritated when I tried to solve one
problem and simply created one that was harder to solve. I don't think any
of us quite appreciated how bad the situation is. No good deed goes
unpunished.

I tried yesterday to help someone internally with an SGI system. They had
two new wrinkles on this:

a. They had their own blas but not their own lapack, in /usr/lib. Well, I
had allowed for that in my second version, but of course the imprecision of
the -L stuff makes it possible to get the wrong one that way.

b. I did get the /usr/lib version of the blas, and boy was it the wrong one,
since apparently there are two binary modes on an SGI and it was not -n32
like Python expected. Neither was the lapack_lite one. I had to edit the
Makefile. That problem could be avoided using distutils to do the compile.

The solution was to edit setup.py to remove /usr/lib from the search list.

The problem with simply using the desired library as a binary instead of a
library is that you would load all of it. I do not know how much control you
can get with the -l -L paradigm, especially in a portable way.

[Numpy-discussion] NumPy built distributions >

[Michel S. <sa...@sc...>]

Hello,

We have a download site for Python module (which I meant to make public .. just
didn't have time yet).

It enables downloading precompiled Python interpreters (my users are no wanting
to have to compile the interpreter) and a large number of Python extensions
including Numeric for the following platforms:

sgi IRIX5
sgi IRIX6
sun SunOS5
Dec Alpha
Linux

feel free to give it a shot !

http://www.scripps.edu/~sanner/Python and scroll down to Downloads

Any feed back is welcome !

-Michel

-- 

-----------------------------------------------------------------------

>>>>>>>>>> AREA CODE CHANGE <<<<<<<<< we are now 858 !!!!!!!

Michel F. Sanner Ph.D.                   The Scripps Research Institute
Assistant Professor			Department of Molecular Biology
					  10550 North Torrey Pines Road
Tel. (858) 784-2341				     La Jolla, CA 92037
Fax. (858) 784-2860
sa...@sc...                        http://www.scripps.edu/sanner
-----------------------------------------------------------------------

[Numpy-discussion] Sourceforge down time scheduled -- heads up

[Paul F. D. <pau...@ho...>]

-----Original Message-----
From: no...@so... [mailto:no...@so...]
Sent: Tuesday, September 12, 2000 6:18 PM
To: no...@so...
Subject: SourceForge: Important Site News


Dear SourceForge User,

As the Director of SourceForge, I want to thank you in making
SourceForge the most successful Open Source Development Site in the
World.  We just surpassed 60,000 registered users and 8,800 open
source projects.  

We have a lot of exciting things planned for SourceForge in the coming
months.  These include faster servers, improved connectivity, mirrored
servers, and the addition of more hardware platforms to our compile
farm (including Sparc, PowerPC, Alpha, and more).

Did I mention additional storage?  The new servers that we will be
adding to the site will increase the total storage on SourceForge by
an additional 6 terabytes.

In 10 days we will begin the first phase of our new hardware build
out. This phase involves moving the primary site to our new location
in Fremont, California.  This move will take place on Friday night
(Sept 22nd) at 10pm and continue to 8am Saturday morning (Pacific
Standard Time).  During this time the site will be off-line as we 
make the physical change.  

I know many of you use Sourceforge as your primary development
environment, so I want to apologize in advance for the inconvenience
of this downtime.   If you have any concerns about this, please feel
free to email me.

I will write you again as this date nears, with a reminder and an
update.

Thank you again for using SourceForge.net

--
Patrick McGovern
Director of SourceForge.net 
Pa...@so...


---------------------
This email was sent from sourceforge.net. To change your email receipt
preferences, please visit the site and edit your account via the
"Account Maintenance" link.

Direct any questions to ad...@so..., or reply to this email.

RE: [Numpy-discussion] NumPy built distributions

[Paul F. D. <pau...@ho...>]

I'm willing to add any built distributions that you make. In the longer run
I am happy to welcome additional developers who just want to be able to do
these releases.

Here is what you do:
ftp downloads.sourceforge.net
cd /incoming
Upload your file
Send me email telling me the name of the file. I will reply when I have done
it. I don't know how long they let the files sit in incoming before blowing
them away but let's try it and see how things work out.

Please name the files so that they indicate the platform if not obvious,
Numeric version AND the Python version with which they were built. I suggest
something like Numeric-16.0-Python1.6.rpm, etc. The Python versions 1.5.2,
1.6, and 2.0 are incompatible.

> -----Original Message-----
> From: num...@li...
> [mailto:num...@li...]On Behalf Of
> Goodger, David
> Sent: Tuesday, September 12, 2000 7:33 AM
> To: num...@li...
> Cc: ro...@je...
> Subject: [Numpy-discussion] NumPy built distributions
>
>
> ATTN: Numeric Python project administrators
>
> There is a lot of interest in NumPy out there. Every time a new version of
> Numeric or Python comes out, people are interested in obtaining built
> distributions. Many of us are not able to build from source; without a
> repository of built distributions I'm afraid that many people
> will give up.
>
> The MacOS community is lucky that Jack Jansen, who maintains the MacPython
> distribution, also includes a built NumPy with his installers. Other OSes
> are not so lucky.
>
> Robin Becker (ro...@je...) has built NumPy for Win32 many
> times and emails copies to those who request them. Unfortunately for him,
> but fortunately for NumPy, the demand is getting too high for
> this method of
> distribution. It would be great if these built distributions were
> available
> for all, with minimal overhead to developers/packagers.
>
> Would it be possible to add Robin's installers to the FTP site? How should
> he (or I, if he's not able) go about this?
>
> David Goodger
> Systems Administrator, Advanced Systems
> Automation Tooling Systems Inc., Automation Systems Division
> direct: (519) 653-4483 ext. 7121    fax: (519) 650-6695
> e-mail: dgo...@at...
>         go...@us...
>
>
> From NumPy's Open Discussion forum
> (http://sourceforge.net/forum/forum.php?forum_id=3847):
>
> 	By: rgbecker ( Robin Becker )
> 	 Numeric-16.0 win32 builds [ reply ]
> 	2000-Sep-09 03:57
> 	I have built and zipped binaries for Numeric-16.0 for
> Python-1.5.2/1.6b1/2.0b1
> 	I am fed up with sending these binaries to people individually.
> 	Is there an FTP location I could use on the sourceforge site?
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> http://lists.sourceforge.net/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] NumPy built distributions

[David A. <Da...@Ac...>]

> Would it be possible to add Robin's installers to the FTP site? How should
> he (or I, if he's not able) go about this?

I'm working on it right now.  I need to repackage his code a bit since he
just shipped me the .pyds and I'd like to make it a drop-in zip file
(meaning I just add the .py and the .pth file).

--david

Re: [Numpy-discussion] Row/Column delete

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

> What I am doing right now is: Set up a new matrix with one less row
> or column (zeros()), then copy all the rows/columns but the one I'd
> like to delete to the new matrix.

I haven't done any comparisons, but I suspect that Numeric.take() is
faster for large arrays. Try this:

def delete_row(matrix, row):
   return Numeric.take(matrix, range(row) + range(row+1, matrix.shape[0]))

def delete_column(matrix, column):
   return Numeric.take(matrix,
                       range(column) + range(column+1, matrix.shape[1]),
                       axis = 1)

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] Row/Column delete

[<hi...@di...>]

> What I am doing right now is: Set up a new matrix with one less row
> or column (zeros()), then copy all the rows/columns but the one I'd
> like to delete to the new matrix.

I haven't done any comparisons, but I suspect that Numeric.take() is
faster for large arrays. Try this:

def delete_row(matrix, row):
   return Numeric.take(matrix, range(row) + range(row+1, matrix.shape[0]))

def delete_column(matrix, column):
   return Numeric.take(matrix,
                       range(column) + range(column+1, matrix.shape[1]),
                       axis = 1)

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] Row/Column delete

[Oliver H. <o.h...@sm...>]

Konrad Hinsen (hi...@cn...) wrote:

> I haven't done any comparisons, but I suspect that Numeric.take() is
> faster for large arrays. Try this:

Yes, indeed. Actually, it is so fast that the first time I rewrote the 
script last week I was quite convinced it had to be buggy.

Thanks again everyone,


	Oliver

-- 
Oliver Hofmann  -  University of Cologne  -  Department of Biochemistry
   o.h...@sm... - se...@gm... - co...@th...

"It's too bad she won't live. But then, who does?"
                                                    <Gaff, Blade Runner>

[Numpy-discussion] NumPy built distributions

[Goodger, D. <dgo...@at...>]

ATTN: Numeric Python project administrators

There is a lot of interest in NumPy out there. Every time a new version of
Numeric or Python comes out, people are interested in obtaining built
distributions. Many of us are not able to build from source; without a
repository of built distributions I'm afraid that many people will give up.

The MacOS community is lucky that Jack Jansen, who maintains the MacPython
distribution, also includes a built NumPy with his installers. Other OSes
are not so lucky.

Robin Becker (ro...@je...) has built NumPy for Win32 many
times and emails copies to those who request them. Unfortunately for him,
but fortunately for NumPy, the demand is getting too high for this method of
distribution. It would be great if these built distributions were available
for all, with minimal overhead to developers/packagers.

Would it be possible to add Robin's installers to the FTP site? How should
he (or I, if he's not able) go about this?

David Goodger
Systems Administrator, Advanced Systems
Automation Tooling Systems Inc., Automation Systems Division
direct: (519) 653-4483 ext. 7121    fax: (519) 650-6695
e-mail: dgo...@at...
        go...@us...


From NumPy's Open Discussion forum
(http://sourceforge.net/forum/forum.php?forum_id=3847):

	By: rgbecker ( Robin Becker ) 
	 Numeric-16.0 win32 builds [ reply ]   
	2000-Sep-09 03:57  
	I have built and zipped binaries for Numeric-16.0 for
Python-1.5.2/1.6b1/2.0b1 
	I am fed up with sending these binaries to people individually. 
	Is there an FTP location I could use on the sourceforge site?  

[Numpy-discussion] Univariate and multivariate density estimation using Python

[Jon S. <js...@wm...>]

Hello, all.

I am announcing a C extension module which computes univariate and
multivariate probability density functions by means of a kernel-based
approach.

The module includes functions to perform the estimation using the
following kernels:
* One-dimensional data:
	Epanechnikov
	Biweight
	Triangular
* 2 or 3-dimensional data:
	Epanechnikov
	Multivariate gaussian

For multivariate data, there is the optional feature of scaling each axis 
by means of a matrix. This approach allows the definition of Fukunaga-type
estimators.

The functions in the module are used as follows:

import KPDF
# edata and gdata must be numpy arrays of shapes (N,) and (E,) 
# while h is a scalar
# pdf1 is a numpy array which holds the PDF evaluated at points
# gdata with experimental data in edata. pdf1.shape=(E,)
pdf1=KPDF.UPDFEpanechnikov(edata,gdata,h)

# For multivariate estimation, edata and gdata must be numpy arrays of
# shapes (N,2|3) and (E,2|3) while h is a scalar
# pdf2 is a numpy array which holds the PDF evaluated at points
# gdata with experimental data in edata. pdf2.shape=(E,)
pdf2=KPDF.MPDFEpanechnikov(e2data,g2data,h)

# For Fukunaga-type estimators, Sm1 must be a numpy array 2x2(3x3)
# and holds the covariance matrix. sqrtdetS is the square root of the
# determinant 
pdf2=KPDF.MPDFEpanechnikov(e2data,g2data,h,Sm1,sqrtdetS)

There is not a lot of documentation in the module, but I have a serious
commitment of preparing it soon.

It can be downloaded from:
http://starship.python.net/crew/jsaenz/KPDF.tar.gz

Feedback of interested users will be greatly appreciated.

Regards.


Jon Saenz.				| Tfno: +34 946012470
Depto. Fisica Aplicada II               | Fax:  +34 944648500
Facultad de Ciencias.   \\ Universidad del Pais Vasco \\
Apdo. 644   \\ 48080 - Bilbao  \\ SPAIN

[Numpy-discussion] ANNOUNCEMENT: Fortran to Python Interface Generator, 2nd Rel.

[Pearu P. <pe...@io...>]

FPIG - Fortran to Python Interface Generator

I am pleased to announce the second public release of f2py
(version 2.264):

     http://cens.ioc.ee/projects/f2py2e/

f2py is a command line tool for binding Python and Fortran codes.  It
scans Fortran 77/90/95 codes and generates a Python C/API module that
makes it possible to call Fortran routines from Python.  No Fortran or
C expertise is required for using this tool.

Features include:

   *** All basic Fortran types are supported:
         integer[ | *1 | *2 | *4 | *8 ], logical[ | *1 | *2 | *4 | *8 ], 
         character[ | *(*) | *1 | *2 | *3 | ... ]
         real[ | *4 | *8 | *16 ], double precision,
         complex[ | *8 | *16 | *32 ]

   *** Multi-dimensional arrays of (almost) all basic types.
       Dimension specifications: 
		 <dim> | <start>:<end> | * | :

   *** Supported attributes:
         intent([ in | inout | out | hide | in,out | inout,out ])
	 dimension(<dimspec>)
	 depend([<names>])
	 check([<C-booleanexpr>])
	 note(<LaTeX text>)
	 optional, required, external

   *** Calling Fortran 77/90/95 subroutines and functions.  Also
       Fortran 90/95 module routines.  Internal initialization of
       optional arguments.

   *** Accessing COMMON blocks from Python.  Accessing Fortran 90/95
       module data coming soon.

   *** Call-back functions: calling Python functions from Fortran with
       very flexible hooks.

   *** In Python, arguments of the interfaced functions may be of
       different type - necessary type conversations are done
       internally in C level.

   *** Automatically generates documentation (__doc__,LaTeX) for
       interface functions.

   *** Automatically generates signature files --- user has full
       control over the interface constructions.  Automatically
       detects the signatures of call-back functions, solves argument
       dependencies, etc.

   *** Automatically generates Makefile for compiling Fortran and C
       codes and linking them to a shared module. Many compilers are
       supported: gcc, Compaq Fortran, VAST/f90 Fortran, Absoft
       F77/F90, MIPSpro 7 Compilers, etc.  Platforms: Intel/Alpha
       Linux, HP-UX, IRIX64.

   *** Complete User's Guide in various formats (html,ps,pdf,dvi).

   *** f2py users list is available for support, feedback, etc.

More information about f2py, see 

     http://cens.ioc.ee/projects/f2py2e/

f2py is released under the LGPL license.

Sincerely,
     Pearu Peterson <pe...@io...>
     September 12, 2000

<P><A HREF="http://cens.ioc.ee/projects/f2py2e/">f2py 2.264</A> - The
Fortran to Python Interface Generator (12-Sep-00)

[Numpy-discussion] Reference on numpy home page

[Paul F. D. <pau...@ho...>]

Travis,

I added a reference to your multipack home page on
http://numpy.sourceforge.net. I encourage you and other nummies to edit that
section of the home page to add other references to primary collections of
numpy-compatible software, or to add details to my descriptions.

To do it, log in via ssh to sourceforge, cd to /home/groups/numpy/htdocs,
and edit index.html.
I think we can rely on sloth to prevent edit conflicts, there being so few
of us.

Paul

Re: [Numpy-discussion] 2 i/o questions and an announcement

[<ni...@ni...>]

> From my understanding of the code, Numpy2 uses the buffer
> interface. This would be the basis for a fast exchange of data between
> PIL and Numpy arrays.

I should have been more specific <:)  This problem was related to the 
current version of NumPy's interaction with PIUL.

> Regarding IO the pickling of arrays is quite
> fast. Have you tried this already?

So is array.fromfile (faster I would expect).  The issue at hand is not 
the read speed, but avoiding reading into memory then re-copying it over 
to NumPy formats.

> That's right. If you want to read binary formats, for which you
> know the data layout the numpyio package from Travis
> Oliphant is very fast and memory efficient, because it
> builds up the array during the read/write so no copy
> of the data string needs to be in memory.

Ah-ha!  Sounds exactly what I wanted.  I'll check it out.

Thanks, Nick.