From jos_edw at mail.com  Mon Jun  3 10:56:59 2002
From: jos_edw at mail.com (JOSEPH  EDWARD.)
Date: Mon, 3 Jun 2002 16:56:59 +0200
Subject: [SciPy-dev] please kindly get back to me
Message-ID: <20020603150004.357093EA21@www.scipy.com>

ATTN:   
I STUMBLED IN TO YOUR CONTACT BY STROCK OF LUCK AFRTER 
A LONG SEARCH FOR AN HONEST AND TRUST WORTHY PERSON WHO
COULD HANDLE ISSUE WITH HIGH CONFIDENTIALITY.
I WAS SO DELIGHTED WHEN I GOT YOUR CONTACT AND I DECIDED 
TO CONTACT YOU AND SOLICITE FOR YOUR KIND ASSISTANCE.
I HOPE YOU WILL LET THIS ISSUE TO REMAIN CONFIDENTIAL EVEN
IF YOU ARE NOT INTERESTED BECAUSE OF MY STATUS.
I PRESUME THIS MAIL WILL NOT BE A SURPRISE TO YOU.
I AM AN ACCOUNTANT WITH THE MINISTRY OF MINERAL
RESOURCES AND ENERGY IN SOUTH AFRICA AND ALSO A MEMBER
OF CONTRACTS AWARDING COMMITTEE OF THIS MINISTRY UNDER
SOUTH AFRICA GOVERNMENT.

MANY YEARS AGO, SOUTH AFRICA GOVERNMENT ASKED THIS
COMMITTEE TO AWARDS CONTRACTS TO FOREIGN FIRMS, WHICH
I AND 2 OF MY PARTNERS ARE THE LEADER OF THIS
COMMITTEE, WITH OUR GOOD POSITION , THIS CONTRACRS
WAS OVER INVOICED TO THE TUNE OF US$25,600,000:00 AS A

DEAL TO BE BENEFIT BY THE THREE TOP MEMBER OF THIS
COMMITTEE.
NOW THE CONTRACTS VALUE HAS BEEN PAID OFF TO THE
ACTUAL CONTRACTORS THAT EXECUTED THIS JOBS, ALL WE
WANT NOW IS A TRUSTED FOREIGN PARTNER LIKE YOU THAT WE

SHALL FRONT WITH HIS BANKING ACCOUNT NUMBER TO CLAIM
THE OVER INFLATED SUM.
UPON OUR AGREEMEENT TO CARRY ON THIS TRANSACTION WITH
YOU, THE SAID FUND WILL BE SHARE AS FOLLOWS.
75% WILL BE FOR US IN SOUTH AFRICA.
20% FOR USING YOUR ACCOUNT AND OTHER CONTRIBUTION
THAT MIGHT REQIURED FROM YOU.
5% IS SET ASIDE FOR THE UP FRONT EXPENCES THAT
WILL BE ENCOUNTER BY BOTH PARTY TO GET ALL NECESSARY
DOCUMENTS AND FORMARLITIES THAT WILL JUSTIFY YOU AS
THE RIGHTFUL OWNER OF THIS FUND.
IF YOU ARE INTERESTED IN THIS TRANSACTION, KINDLY
REPLY THIS MASSEGE WITH ALL YOUR PHONE AND FAX
NUMBERS, TO ENABLE US FURNISH YOU WITH DETAILS AND
PROCEDURES OF THIS TRANSACTION.
GOD BLESS YOU
YOURS FAITHFULLY.

JOSEPH EDWARD.






From heiko at hhenkelmann.de  Fri Jun  7 16:43:01 2002
From: heiko at hhenkelmann.de (Heiko Henkelmann)
Date: Fri, 7 Jun 2002 22:43:01 +0200
Subject: [SciPy-dev] patch for filter_design.py in scipy.signal
Message-ID: <000b01c20e63$eadb7fc0$d3d99e3e@arrow>

Hello there,

I found the following problem:


ActivePython 2.1, build 210 ActiveState)
based on Python 2.1 (#15, Apr 19 2001, 10:28:27) [MSC 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from scipy import signal
>>> signal.butter(6,0.5)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "c:\usr\python21\scipy\signal\filter_design.py", line 484, in butter
    return iirfilter(N, Wn, btype=btype, analog=analog, output=output,
ftype='butter')
  File "c:\usr\python21\scipy\signal\filter_design.py", line 465, in
iirfilter
    b, a = bilinear(b, a, fs=fs)
  File "c:\usr\python21\scipy\signal\filter_design.py", line 313, in
bilinear
    bprime[j] = val
TypeError: can't convert complex to float; use e.g. abs(z)
>>>


The following patch fixes it:


*** C:\WINDOWS\TEMP\filter_design.py Fri Jun  7 22:32:30 2002
--- C:\WINDOWS\TEMP\filter_design.pyF9gqgq Fri Jun  7 22:32:30 2002
***************
*** 448,453 ****
--- 448,456 ----
          z, p, k = typefunc(N, rp, rs)

      b, a = zpk2tf(z,p,k)
+     if a.typecode() in ['F','D']:
+         # we are dealing with real filter coefficients
+         a = a.real.copy()

      # transform to lowpass, bandpass, highpass, or bandstop
      if btype == 'lowpass':


Can anyone apply this to the CVS repository?


Thanx

Heiko




From oliphant.travis at ieee.org  Sat Jun  8 18:13:36 2002
From: oliphant.travis at ieee.org (Travis Oliphant)
Date: 08 Jun 2002 16:13:36 -0600
Subject: [SciPy-dev] patch for filter_design.py in scipy.signal
In-Reply-To: <000b01c20e63$eadb7fc0$d3d99e3e@arrow>
References: <000b01c20e63$eadb7fc0$d3d99e3e@arrow>
Message-ID: <1023574418.11754.2.camel@travis>

On Fri, 2002-06-07 at 14:43, Heiko Henkelmann wrote:

> Can anyone apply this to the CVS repository?

Fixed.  Thanks for the report.

-Travis




From targetemailextractor at btamail.net.cn  Mon Jun 10 07:17:34 2002
From: targetemailextractor at btamail.net.cn (targetemailextractor at btamail.net.cn)
Date: Mon, 10 Jun 2002 19:17:34 +0800
Subject: [SciPy-dev] ADV: Direct Email Blaster, email addresses extractor,maillist verify, maillist manager ...........
Message-ID: <20020610112004.A9A6A3EA21@www.scipy.com>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20020610/c30bd85f/attachment.html>

From eric at enthought.com  Sun Jun 16 04:07:21 2002
From: eric at enthought.com (eric jones)
Date: Sun, 16 Jun 2002 03:07:21 -0500
Subject: [SciPy-dev] fmin question
Message-ID: <000101c2150c$d779a6a0$6b01a8c0@ericlaptop>

I was just to get up to speed on the optimization library, and got the
following:

>>> optimize.fmin(optimize.rosen,[.3],xtol=1e-7)
Optimization terminated successfully.
         Current function value: 0.000000
         Iterations: 19
         Function evaluations: 56
array([ 0.31000002])
>>> optimize.fmin(optimize.rosen,[.3,.3],xtol=1e-7)
Optimization terminated successfully.
         Current function value: 0.000000
         Iterations: 80
         Function evaluations: 153
array([ 1.00000001,  1.00000002])

I understand the 2nd argument to be an array of initial guesses.  If so,
shouldn't the results returned be the same?  

eric




From eric at enthought.com  Sun Jun 16 04:14:31 2002
From: eric at enthought.com (eric jones)
Date: Sun, 16 Jun 2002 03:14:31 -0500
Subject: [SciPy-dev] fmin question
In-Reply-To: <000101c2150c$d779a6a0$6b01a8c0@ericlaptop>
Message-ID: <000201c2150d$d7a79f00$6b01a8c0@ericlaptop>

Never mind -- just looked at the rosen function and now see that it
takes a vector as input.

> -----Original Message-----
> From: scipy-dev-admin at scipy.net [mailto:scipy-dev-admin at scipy.net] On
> Behalf Of eric jones
> Sent: Sunday, June 16, 2002 3:07 AM
> To: scipy-dev at scipy.org
> Subject: [SciPy-dev] fmin question
> 
> 
> I was just to get up to speed on the optimization library, and got the
> following:
> 
> >>> optimize.fmin(optimize.rosen,[.3],xtol=1e-7)
> Optimization terminated successfully.
>          Current function value: 0.000000
>          Iterations: 19
>          Function evaluations: 56
> array([ 0.31000002])
> >>> optimize.fmin(optimize.rosen,[.3,.3],xtol=1e-7)
> Optimization terminated successfully.
>          Current function value: 0.000000
>          Iterations: 80
>          Function evaluations: 153
> array([ 1.00000001,  1.00000002])
> 
> I understand the 2nd argument to be an array of initial guesses.  If
so,
> shouldn't the results returned be the same?
> 
> eric
> 
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev



From travis at enthought.com  Mon Jun 17 19:38:52 2002
From: travis at enthought.com (Travis N. Vaught)
Date: Mon, 17 Jun 2002 18:38:52 -0500
Subject: [SciPy-dev] [ANN] SciPy '02 - Python for Scientific Computing Workshop
Message-ID: <KPEIKEPEIBGNGNKHDILIAENCDGAA.travis@enthought.com>

----------------------------------------
Python for Scientific Computing Workshop
----------------------------------------
CalTech, Pasadena, CA
Septemer 5-6, 2002

http://www.scipy.org/site_content/scipy02

This workshop provides a unique opportunity to learn and affect what is
happening in the realm of scientific computing with Python. Attendees will
have the opportunity to review the available tools and how they apply to
specific problems. By providing a forum for developers to share their Python
expertise with the wider industrial, academic, and research
communities, this workshop will foster collaboration and facilitate the
sharing of software components, techniques and a vision for high level
language use in scientific computing.

The two-day workshop will be a mix of invited talks and training sessions in
the morning. The afternoons will be breakout sessions with the intent of
getting standardization of tools and interfaces.

The cost of the workshop is $50.00 and includes 2 breakfasts and 2 lunches
on Sept. 5th and 6th, one dinner on Sept. 5th, and snacks during breaks.

There is a limit of 50 attendees.  Should we exceed the limit of 50
registrants, the 50 persons
selected to attend will be invited individually by the organizers.

Discussion about the conference may be directed to the SciPy-user mailing
list:

mailto:scipy-user at scipy.org

http://www.scipy.org/MailList


-------------
Co-Hosted By:
-------------

The National Biomedical Computation Resource (NBCR, SDSC, San Diego, CA)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
http://nbcr.sdsc.edu
The mission of the National Biomedical Computation Resource at the San Diego
Supercomputer Center is to conduct, catalyze, and enable biomedical research
by harnessing advanced computational technology.


The Center for Advanced Computing Research (CACR, CalTech, Pasadena, CA)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
http://nbcr.sdsc.edu
CACR is dedicated to the pursuit of excellence in the field of
high-performance computing, communication, and data engineering. Major
activities include carrying out large-scale scientific and engineering
applications on parallel supercomputers and coordinating collaborative
research projects on high-speed network technologies, distributed computing
and database methodologies, and related topics. Our goal is to help further
the state of the art in scientific computing.


Enthought, Inc. (Austin, TX)
^^^^^^^^^^^^^^^
http://enthought.com
Enthought, Inc. provides business and scientific computing solutions through
software development, consulting and training.



From cweng at cwnetdg.io  Thu Jun 20 17:16:00 2002
From: cweng at cwnetdg.io (Engineering Staff)
Date: Thu, 20 Jun 2002 15:16:00 -0600 (GMT)
Subject: [SciPy-dev] Virus Alert
Message-ID: <200206202116.PAA20731@DGAccess.cwnetdg.io>

The mail message (file: rights.pif) you sent to wrseay at cwnetdg.io contains a virus (WORM_KLEZ.H). (on DGAccess)


From targetemailextractor at btamail.net.cn  Fri Jun 21 02:19:58 2002
From: targetemailextractor at btamail.net.cn (targetemailextractor at btamail.net.cn)
Date: Fri, 21 Jun 2002 14:19:58 +0800
Subject: [SciPy-dev] ADV: Direct email blaster, email addresses extractor, maillist verify, maillist manager...........
Message-ID: <20020621062317.21ED73EABC@www.scipy.com>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20020621/72f2f449/attachment.html>

From eric at enthought.com  Fri Jun 21 19:06:56 2002
From: eric at enthought.com (eric jones)
Date: Fri, 21 Jun 2002 18:06:56 -0500
Subject: [SciPy-dev] adding LAPACK and BLAS to the source code
Message-ID: <000301c21978$570bb470$6b01a8c0@ericlaptop>

Hey group,

We just had the unpleasant experience of getting SciPy to build on the
Sun architecture.  In the end, it didn't prove that hard -- it was all
the mis-steps that were painful.  Most of SciPy builds without a hitch
-- it is only the LAPACK and BLAS stuff that causes major problems.

The issue is that many LAPACK's are built with vendor specific compilers
instead of g77, so getting the correct libraries to link in when
compiling with distutils is a major headache.  And, once the link works,
the headaches continue with chasing down random seg-faults.  These
appear to come from the library issues.

We worked with ATLAS for a while, but finally backed off to working with
just the standard LAPACK and BLAS.  The result was a pain free build
because gcc and g77 were used all the way through.  I expect building
everything with the Sun compilers would also go fairly smoothly using
this approach.  It seems like most of the questions we get on building
SciPy have to do with ATLAS and linear algebra.  On windows and Linux,
we about have this problem licked.  But its still difficult on platforms
with multiple compilers.  So, I am planning to put LAPACK and BLAS into
the SciPy CVS so that they are built with the same compiler as the rest
of SciPy and no longer have to be built separately.  This will increase
the repository size substantially (LAPACK is big), but has little other
side effects.  We'll set up the building of LAPACK and BLAS so that they
are optional -- if you have ATLAS or other LAPACK libraries you'd like
to use, you can specify them in the site.cfg package -- or at least
specify that system_info should search for them.  This search will be
turned off by default, however, so that incompatible lapack/blas/atlas
libraries are not found.

I think this will ease the build process for everyone and still allows
for using the optimized libraries.  If there are no major objections,
please let me know.  If not, I'll make the addition Tuesday or
Wednesday.

Eric






From adam at scipy.com  Sat Jun 22 16:54:28 2002
From: adam at scipy.com (Adam Barker)
Date: Sat, 22 Jun 2002 15:54:28 -0500 (CDT)
Subject: [SciPy-dev] Test - please ignore
Message-ID: <20020622205428.1B3283EABE@www.scipy.com>

Hi folks,

I'm running some tests on the scipy mailing lists, as we've had a couple of problems with bounces lately.  Please pardon my dust.

Thank you,

Adam


From eric at enthought.com  Sun Jun 23 15:45:28 2002
From: eric at enthought.com (eric jones)
Date: Sun, 23 Jun 2002 14:45:28 -0500
Subject: [SciPy-dev] adding LAPACK and BLAS to the source code
Message-ID: <000001c21aee$87195c40$6b01a8c0@ericlaptop>

Hey group,

Apologies if you get this twice -- we had a mail list hiccup earlier
this week, and I don't think this went out correctly.


We just had the unpleasant experience of getting SciPy to build on the
Sun architecture.  In the end, it didn't prove that hard -- it was all
the mis-steps that were painful.  Most of SciPy builds without a hitch
-- it is only the LAPACK and BLAS stuff that causes major problems.

The issue is that many LAPACK's are built with vendor specific compilers
instead of g77, so getting the correct libraries to link in when
compiling with distutils is a major headache.  And, once the link works,
the headaches continue with chasing down random seg-faults that appear
to come from incompatible library ABI issues.

We worked with ATLAS for a while, but finally backed off to working with
just the standard LAPACK and BLAS.  The result was a pain free build
because gcc and g77 were used all the way through.  I expect building
everything with the Sun compilers would also go fairly smoothly using
this approach.  It seems like most of the questions we get on building
SciPy have to do with ATLAS and linear algebra.  On windows and Linux,
we about have this problem licked.  But its still difficult on platforms
with multiple compilers.  So, I am planning to put LAPACK and BLAS into
the SciPy CVS so that they are built with the same compiler as the rest
of SciPy and no longer have to be built separately.  This will increase
the repository size substantially (LAPACK is big), but has little other
side effects.  We'll set up the building of LAPACK and BLAS so that they
are optional -- if you have ATLAS or other LAPACK libraries you'd like
to use, you can specify them in the site.cfg package -- or at least
specify that system_info should search for them.  This search will be
turned off by default, however, so that incompatible lapack/blas/atlas
libraries are not found.

I think this will ease the build process for everyone and still allows
for using the optimized libraries.  If there are no major objections,
please let me know.  If not, I'll make the addition Tuesday or
Wednesday.

Eric



From oliphant.travis at ieee.org  Sun Jun 23 22:05:02 2002
From: oliphant.travis at ieee.org (Travis Oliphant)
Date: 23 Jun 2002 20:05:02 -0600
Subject: [SciPy-dev] adding LAPACK and BLAS to the source code
In-Reply-To: <000001c21aee$87195c40$6b01a8c0@ericlaptop>
References: <000001c21aee$87195c40$6b01a8c0@ericlaptop>
Message-ID: <1024884303.26892.10.camel@travis>

On Sun, 2002-06-23 at 13:45, eric jones wrote:
> Hey group,
> 
> Apologies if you get this twice -- we had a mail list hiccup earlier
> this week, and I don't think this went out correctly.
> 
> 
> We just had the unpleasant experience of getting SciPy to build on the
> Sun architecture.  In the end, it didn't prove that hard -- it was all
> the mis-steps that were painful.  Most of SciPy builds without a hitch
> -- it is only the LAPACK and BLAS stuff that causes major problems.
>

I had thought it would be easier to get optimized LAPACK and BLAS with
Sun systems. 
 
> The issue is that many LAPACK's are built with vendor specific compilers
> instead of g77, so getting the correct libraries to link in when
> compiling with distutils is a major headache.  And, once the link works,
> the headaches continue with chasing down random seg-faults that appear
> to come from incompatible library ABI issues.

Ah, this is the problem with using those.

> 
> We worked with ATLAS for a while, but finally backed off to working with
> just the standard LAPACK and BLAS.  

Why did ATLAS not work?


> The result was a pain free build
> because gcc and g77 were used all the way through.  I expect building
> everything with the Sun compilers would also go fairly smoothly using
> this approach.  It seems like most of the questions we get on building
> SciPy have to do with ATLAS and linear algebra.  On windows and Linux,
> we about have this problem licked.  But its still difficult on platforms
> with multiple compilers.  So, I am planning to put LAPACK and BLAS into
> the SciPy CVS so that they are built with the same compiler as the rest
> of SciPy and no longer have to be built separately.  

Won't this result in slow code on those machines?


> This will increase
> the repository size substantially (LAPACK is big), but has little other
> side effects.  We'll set up the building of LAPACK and BLAS so that they
> are optional -- if you have ATLAS or other LAPACK libraries you'd like
> to use, you can specify them in the site.cfg package -- or at least
> specify that system_info should search for them.  This search will be
> turned off by default, however, so that incompatible lapack/blas/atlas
> libraries are not found.
> 

It seems like in CVS the default should be to use the optimized LAPACK
given that this is the default most of the developers would want to
use.   Is the site.cfg file managed by CVS?  If so, then our constant
changes to this file will undoubtedly result in checking in a version
that searches by default.  

It would seem that a check for certain machines and a subsequent turning
off of that option would be better.


-Travis





From eric at enthought.com  Mon Jun 24 10:53:42 2002
From: eric at enthought.com (eric jones)
Date: Mon, 24 Jun 2002 09:53:42 -0500
Subject: [SciPy-dev] adding LAPACK and BLAS to the source code
In-Reply-To: <1024884303.26892.10.camel@travis>
Message-ID: <000001c21b8e$ef179000$6b01a8c0@ericlaptop>

> -----Original Message-----
> From: scipy-dev-admin at scipy.net [mailto:scipy-dev-admin at scipy.net] On
> Behalf Of Travis Oliphant
> Sent: Sunday, June 23, 2002 9:05 PM
> To: scipy-dev at scipy.net
> Subject: Re: [SciPy-dev] adding LAPACK and BLAS to the source code
> 
> On Sun, 2002-06-23 at 13:45, eric jones wrote:
> > Hey group,
> >
> > Apologies if you get this twice -- we had a mail list hiccup earlier
> > this week, and I don't think this went out correctly.
> >
> >
> > We just had the unpleasant experience of getting SciPy to build on
the
> > Sun architecture.  In the end, it didn't prove that hard -- it was
all
> > the mis-steps that were painful.  Most of SciPy builds without a
hitch
> > -- it is only the LAPACK and BLAS stuff that causes major problems.
> >
> 
> I had thought it would be easier to get optimized LAPACK and BLAS with
> Sun systems.
> 
> > The issue is that many LAPACK's are built with vendor specific
compilers
> > instead of g77, so getting the correct libraries to link in when
> > compiling with distutils is a major headache.  And, once the link
works,
> > the headaches continue with chasing down random seg-faults that
appear
> > to come from incompatible library ABI issues.
> 
> Ah, this is the problem with using those.

Well, really, I'm not sure that its the C ABI.  I would have thought
(and do think) that gcc is compatible with the native compiler ABI.  I'm
more suspicious about g77 and f77 library incompatibilities/clashes,
especially with IO routines.  This is all speculations because we never
chased down the real problems -- it just took to long.

> 
> >
> > We worked with ATLAS for a while, but finally backed off to working
with
> > just the standard LAPACK and BLAS.
> 
> Why did ATLAS not work?

One time it was name mangling issues, another Fortran compiler issues.
The deal is that making "mistakes" in the build process is extremely
high.  If the created library has to incorrect name mangling, or the
wrong fortran compiler setting, or whatever, you don't find out until 5
hours later (on Sun).  

> 
> 
> > The result was a pain free build
> > because gcc and g77 were used all the way through.  I expect
building
> > everything with the Sun compilers would also go fairly smoothly
using
> > this approach.  It seems like most of the questions we get on
building
> > SciPy have to do with ATLAS and linear algebra.  On windows and
Linux,
> > we about have this problem licked.  But its still difficult on
platforms
> > with multiple compilers.  So, I am planning to put LAPACK and BLAS
into
> > the SciPy CVS so that they are built with the same compiler as the
rest
> > of SciPy and no longer have to be built separately.
> 
> Won't this result in slow code on those machines?

The resulting code was actually pretty fast.  There was a factor of 5-10
improvement over Numeric's linear algebra stuff.

I'm sure it is still quite a bit slower than ATLAS, but in many cases,
just getting the capability is much more important than having the
ultimate in speed.

> 
> > This will increase
> > the repository size substantially (LAPACK is big), but has little
other
> > side effects.  We'll set up the building of LAPACK and BLAS so that
they
> > are optional -- if you have ATLAS or other LAPACK libraries you'd
like
> > to use, you can specify them in the site.cfg package -- or at least
> > specify that system_info should search for them.  This search will
be
> > turned off by default, however, so that incompatible
lapack/blas/atlas
> > libraries are not found.
> >
> 
> It seems like in CVS the default should be to use the optimized LAPACK
> given that this is the default most of the developers would want to
> use.   Is the site.cfg file managed by CVS?  If so, then our constant
> changes to this file will undoubtedly result in checking in a version
> that searches by default.

I think this will probably work fine on Linux since gcc is the main tool
here, and compatibility issues are much less likely to crop up.  Perhaps
a nm check on the found ATLAS library to find out if the libraries
symbols match what SciPy expects would be a good idea though.

Another question on Linux that is likely to become more and more
important is whether gcc 3.x compiled libraries are compatible with gcc
2.9x ibraries?

Outside of the Linux and Windows worlds, defaulting to optimized
libraries has problems.  On Sun, all the libraries existed (ATLAS,
vendor supplied blas, lapack were all in /usr/lib), and were detected by
the SciPy, but none of these libraries would work because of the
mentioned issues.  So, having SciPy automatically detect and choose
these optimized libraries is problematic on non-Linux Unix platforms.

> 
> It would seem that a check for certain machines and a subsequent
turning
> off of that option would be better.

That sounds fine to me -- if Linux choose optimized by default.  If
other Unix, choose LAPACK/BLAS by default.

eric



From prabhu at aero.iitm.ernet.in  Mon Jun 24 14:14:54 2002
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Mon, 24 Jun 2002 23:44:54 +0530
Subject: [SciPy-dev] adding LAPACK and BLAS to the source code
In-Reply-To: <000001c21aee$87195c40$6b01a8c0@ericlaptop>
References: <000001c21aee$87195c40$6b01a8c0@ericlaptop>
Message-ID: <15639.24990.317821.560867@monster.linux.in>

>>>>> "EJ" == eric jones <eric at enthought.com> writes:

    EJ> We just had the unpleasant experience of getting SciPy to
    EJ> build on the Sun architecture.  In the end, it didn't prove
    EJ> that hard -- it was all the mis-steps that were painful.  Most
    EJ> of SciPy builds without a hitch -- it is only the LAPACK and
    EJ> BLAS stuff that causes major problems.

Right now my biggest trouble with scipy is that it needs a recent
version of Atlas.  The version that Debian ships with is too old for
scipy.  Some of my older code does not work with scipy anymore because
my build is broken.  I already need to download too many packages from
source.  While I understand that a newer version of atlas has features
that are worth it, sometimes folks dont use the features.  By making
it mandatory to install atlas it becomes hard to use scipy.  Packaging
lapack might eliminate these problems but by sticking lapack into
scipy's CVS tree aren't we making the scipy cvs tree that much bigger?
Sticking it in CVS also means that even if the package is removed it
still lingers in the attic (which can be painful sometimes).  Also,
aren't there any other issues with including lapack in scipy?  Aren't
we in some sense forking lapack or is lapack no longer under
development??

cheers,
prabhu


From eric at enthought.com  Mon Jun 24 14:41:11 2002
From: eric at enthought.com (eric jones)
Date: Mon, 24 Jun 2002 13:41:11 -0500
Subject: [SciPy-dev] adding LAPACK and BLAS to the source code
In-Reply-To: <15639.24990.317821.560867@monster.linux.in>
Message-ID: <000501c21bae$b6563e40$6b01a8c0@ericlaptop>


> -----Original Message-----
> From: scipy-dev-admin at scipy.net [mailto:scipy-dev-admin at scipy.net] On
> Behalf Of Prabhu Ramachandran
> Sent: Monday, June 24, 2002 1:15 PM
> To: scipy-dev at scipy.net
> Subject: [SciPy-dev] adding LAPACK and BLAS to the source code
> 
> >>>>> "EJ" == eric jones <eric at enthought.com> writes:
> 
>     EJ> We just had the unpleasant experience of getting SciPy to
>     EJ> build on the Sun architecture.  In the end, it didn't prove
>     EJ> that hard -- it was all the mis-steps that were painful.  Most
>     EJ> of SciPy builds without a hitch -- it is only the LAPACK and
>     EJ> BLAS stuff that causes major problems.
> 
> Right now my biggest trouble with scipy is that it needs a recent
> version of Atlas.  The version that Debian ships with is too old for
> scipy.  Some of my older code does not work with scipy anymore because
> my build is broken.  I already need to download too many packages from
> source.  While I understand that a newer version of atlas has features
> that are worth it, sometimes folks dont use the features.  By making
> it mandatory to install atlas it becomes hard to use scipy.  Packaging
> lapack might eliminate these problems but by sticking lapack into
> scipy's CVS tree aren't we making the scipy cvs tree that much bigger?

It does grow -- I see this as the major drawback.

> Sticking it in CVS also means that even if the package is removed it
> still lingers in the attic (which can be painful sometimes).  

I haven't dealt with this, but (perhaps naively) feel this isn't that
huge of an issue.  If there is evidence to the contrary, please
elaborate.  I guess the other deal is that I don't think we'll take it
out in the future, accept when a new version of LAPACK comes out.

> Also,
> aren't there any other issues with including lapack in scipy?  Aren't
> we in some sense forking lapack or is lapack no longer under
> development??

We're not really forking since I doubt we make any modifications -- its
purely a logistical issue.  We already have code from FFTPACK, ODEPACK,
FITPACK, cephes, amos, etc. in SciPy.  We have made a few modifications
in these to get them working on newer compilers, etc., but nothing to
major.  There kept there just to make building SciPy easier.  LAPACK
would be included for the same reason.  

Eric




From Chuck.Harris at sdl.usu.edu  Mon Jun 24 16:13:28 2002
From: Chuck.Harris at sdl.usu.edu (Chuck Harris)
Date: Mon, 24 Jun 2002 14:13:28 -0600
Subject: [SciPy-dev] adding LAPACK and BLAS to the source code
Message-ID: <A55D0D8A70975D4FBE9441512E9CF8BC61242B@cobra.usurf.usu.edu>

> 
> We're not really forking since I doubt we make any 
> modifications -- its
> purely a logistical issue.  We already have code from 
> FFTPACK, ODEPACK,
> FITPACK, cephes, amos, etc. in SciPy.  We have made a few 
> modifications
> in these to get them working on newer compilers, etc., but nothing to
> major.  There kept there just to make building SciPy easier.  LAPACK
> would be included for the same reason.  
> 
> Eric
> 
Perhaps prebuilt libraries could be made available for optional download.
They are already available on the net, but it can be a pain chasing them
down and getting them installed. And maybe they still don't work. At least links to working versions would be helpful.

Chuck

> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev
> 


From travis at enthought.com  Mon Jun 24 18:56:06 2002
From: travis at enthought.com (Travis N. Vaught)
Date: Mon, 24 Jun 2002 17:56:06 -0500
Subject: [SciPy-dev] [ANN] SciPy '02 - Python for Scientific Computing Workshop
Message-ID: <KPEIKEPEIBGNGNKHDILIMECNDHAA.travis@enthought.com>

Apologies if you are receiving this a second time. (mailing list problems
should be fixed now)

----------------------------------------
Python for Scientific Computing Workshop
----------------------------------------
CalTech, Pasadena, CA
Septemer 5-6, 2002

http://www.scipy.org/site_content/scipy02

This workshop provides a unique opportunity to learn and affect what is
happening in the realm of scientific computing with Python. Attendees will
have the opportunity to review the available tools and how they apply to
specific problems. By providing a forum for developers to share their Python
expertise with the wider industrial, academic, and research communities,
this workshop will foster collaboration and facilitate the sharing of
software components, techniques and a vision for high level language use in
scientific computing.

The two-day workshop will be a mix of invited talks and training sessions in
the morning. The afternoons will be breakout sessions with the intent of
getting standardization of tools and interfaces.

The cost of the workshop is $50.00 and includes 2 breakfasts and 2 lunches
on Sept. 5th and 6th, one dinner on Sept. 5th, and snacks during breaks.

There is a limit of 50 attendees.  Should we exceed the limit of 50
registrants, the 50 persons selected to attend will be invited individually
by the organizers.

Discussion about the conference may be directed to the SciPy-user mailing
list:

mailto:scipy-user at scipy.org

http://www.scipy.org/MailList


-------------
Co-Hosted By:
-------------

The National Biomedical Computation Resource (NBCR, SDSC, San Diego, CA)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
http://nbcr.sdsc.edu
The mission of the National Biomedical Computation Resource at the San Diego
Supercomputer Center is to conduct, catalyze, and enable biomedical research
by harnessing advanced computational technology.


The Center for Advanced Computing Research (CACR, CalTech, Pasadena, CA)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
http://nbcr.sdsc.edu
CACR is dedicated to the pursuit of excellence in the field of
high-performance computing, communication, and data engineering. Major
activities include carrying out large-scale scientific and engineering
applications on parallel supercomputers and coordinating collaborative
research projects on high-speed network technologies, distributed computing
and database methodologies, and related topics. Our goal is to help further
the state of the art in scientific computing.


Enthought, Inc. (Austin, TX)
^^^^^^^^^^^^^^^
http://enthought.com
Enthought, Inc. provides business and scientific computing solutions through
software development, consulting and training.  Enthought also fosters the
development of SciPy, an open source library of scientific tools for Python.



From prabhu at aero.iitm.ernet.in  Mon Jun 24 23:25:15 2002
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Tue, 25 Jun 2002 08:55:15 +0530
Subject: [SciPy-dev] [ANN] SciPy '02 - Python for Scientific Computing Workshop
In-Reply-To: <KPEIKEPEIBGNGNKHDILIMECNDHAA.travis@enthought.com>
References: <KPEIKEPEIBGNGNKHDILIMECNDHAA.travis@enthought.com>
Message-ID: <15639.58011.470778.762214@monster.linux.in>

>>>>> "TNV" == Travis N Vaught <travis at enthought.com> writes:

    TNV> ---------------------------------------- Python for
    TNV> Scientific Computing Workshop
    TNV> ---------------------------------------- CalTech, Pasadena,
    TNV> CA Septemer 5-6, 2002

    TNV> http://www.scipy.org/site_content/scipy02

Sounds great!  Would it be possible to put up the slides or even
recordings of the event on the web for those who cannot make it?

cheers,
prabhu


From prabhu at aero.iitm.ernet.in  Mon Jun 24 23:28:40 2002
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Tue, 25 Jun 2002 08:58:40 +0530
Subject: [SciPy-dev] adding LAPACK and BLAS to the source code
In-Reply-To: <000501c21bae$b6563e40$6b01a8c0@ericlaptop>
References: <15639.24990.317821.560867@monster.linux.in>
	<000501c21bae$b6563e40$6b01a8c0@ericlaptop>
Message-ID: <15639.58216.633557.912143@monster.linux.in>

>>>>> "EJ" == eric jones <eric at enthought.com> writes:

    >> Sticking it in CVS also means that even if the package is
    >> removed it still lingers in the attic (which can be painful
    >> sometimes).

    EJ> I haven't dealt with this, but (perhaps naively) feel this
    EJ> isn't that huge of an issue.  If there is evidence to the
    EJ> contrary, please elaborate.  I guess the other deal is that I
    EJ> don't think we'll take it out in the future, accept when a new
    EJ> version of LAPACK comes out.

If you choose to backup your entire CVS tree you'll also end up
backing up all of the files in the attic.  This can be painful.

    >> Also, aren't there any other issues with including lapack in
    >> scipy?  Aren't we in some sense forking lapack or is lapack no
    >> longer under development??

    EJ> We're not really forking since I doubt we make any
    EJ> modifications -- its purely a logistical issue.  We already
    EJ> have code from FFTPACK, ODEPACK, FITPACK, cephes, amos,
    EJ> etc. in SciPy.  We have made a few modifications in these to
    EJ> get them working on newer compilers, etc., but nothing to
    EJ> major.  There kept there just to make building SciPy easier.
    EJ> LAPACK would be included for the same reason.

Sure, but its one more thing to keep track of.  If you really dont
think its too big a deal I guess it makes sense to just go ahead and
add lapack as well.  Maybe you could put all these extra packages into
a separate cvs module so that only folks who want it can check it out?
This way the extras are separated from the main scipy code.  Just a
thought.


cheers,
prabhu


From travis at enthought.com  Tue Jun 25 00:03:23 2002
From: travis at enthought.com (Travis N. Vaught)
Date: Mon, 24 Jun 2002 23:03:23 -0500
Subject: [SciPy-dev] [ANN] SciPy '02 - Python for Scientific Computing Workshop
In-Reply-To: <15639.58011.470778.762214@monster.linux.in>
Message-ID: <KPEIKEPEIBGNGNKHDILIAEDEDHAA.travis@enthought.com>

> >>>>> "PR" == Prabhu Ramachandran [prabhu at aero.iitm.ernet.in] writes:
>
> >>>>> "TNV" == Travis N Vaught <travis at enthought.com> writes:
>
>     TNV> ---------------------------------------- Python for
>     TNV> Scientific Computing Workshop
>     TNV> ---------------------------------------- CalTech, Pasadena,
>     TNV> CA Septemer 5-6, 2002
>
>     TNV> http://www.scipy.org/site_content/scipy02
>
PR> Sounds great!  Would it be possible to put up the slides or even
PR> recordings of the event on the web for those who cannot make it?
PR>
PR> cheers,
PR> prabhu

It is certainly our (Enthought's) intention to aggregate as many of the
presentation materials as possible and post them to the SciPy site.  I'm not
sure recording the presentations or discussions is possible, but we'll look
into it.

I'm sure that any conclusions reached in the breakout sessions will be
revealed in continuing discussions in the mail lists, but we'll work on
formally reporting these as well.

Perhaps a live webcast and instant messaging with remote participants will
premiere at SciPy '03?

TV



From pearu at cens.ioc.ee  Tue Jun 25 01:36:04 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 25 Jun 2002 08:36:04 +0300 (EEST)
Subject: [SciPy-dev] adding LAPACK and BLAS to the source code
In-Reply-To: <15639.58216.633557.912143@monster.linux.in>
Message-ID: <Pine.LNX.4.21.0206250823420.17998-100000@cens.kybi>

On Tue, 25 Jun 2002, Prabhu Ramachandran wrote:

> Sure, but its one more thing to keep track of.  If you really dont
> think its too big a deal I guess it makes sense to just go ahead and
> add lapack as well.  Maybe you could put all these extra packages into
> a separate cvs module so that only folks who want it can check it out?
> This way the extras are separated from the main scipy code.  Just a
> thought.

Another thought is to commit lapack source to CVS as a single tar.gz file.
And removing BLAS,INSTALL,TESTING, and TIMING directories from the
LAPACK distribution (keeping only SRC directory) will reduce the
size of LAPACK sources considerably (39MB -> 15MB or 2MB when gzipped).

Notice that BLAS sources shipped with LAPACK are not complete. So,
the above applies also to BLAS.

Pearu



From eric at enthought.com  Tue Jun 25 12:51:37 2002
From: eric at enthought.com (eric jones)
Date: Tue, 25 Jun 2002 11:51:37 -0500
Subject: [SciPy-dev] adding LAPACK and BLAS to the source code
In-Reply-To: <Pine.LNX.4.21.0206250823420.17998-100000@cens.kybi>
Message-ID: <000001c21c68$92bef5c0$6b01a8c0@ericlaptop>

> -----Original Message-----
> From: scipy-dev-admin at scipy.net [mailto:scipy-dev-admin at scipy.net] On
> Behalf Of Pearu Peterson
> Sent: Tuesday, June 25, 2002 12:36 AM
> To: scipy-dev at scipy.net
> Subject: RE: [SciPy-dev] adding LAPACK and BLAS to the source code
> 
> 
> On Tue, 25 Jun 2002, Prabhu Ramachandran wrote:
> 
> > Sure, but its one more thing to keep track of.  If you really dont
> > think its too big a deal I guess it makes sense to just go ahead and
> > add lapack as well.  Maybe you could put all these extra packages
into
> > a separate cvs module so that only folks who want it can check it
out?
> > This way the extras are separated from the main scipy code.  Just a
> > thought.
> 
> Another thought is to commit lapack source to CVS as a single tar.gz
file.
> And removing BLAS,INSTALL,TESTING, and TIMING directories from the
> LAPACK distribution (keeping only SRC directory) will reduce the
> size of LAPACK sources considerably (39MB -> 15MB or 2MB when
gzipped).

This sounds like a good idea.  The only issue is that Windows doesn't
come with tar.  There is a zlib module in python that solve the zipped
issue.  There is also a tarfile module running around that would make
tar unnecessary, but last time I tried it, it wasn't that stable.
Anyone know if its current state?

eric




From kern at caltech.edu  Tue Jun 25 13:06:55 2002
From: kern at caltech.edu (Robert Kern)
Date: Tue, 25 Jun 2002 10:06:55 -0700
Subject: [SciPy-dev] adding LAPACK and BLAS to the source code
In-Reply-To: <000001c21c68$92bef5c0$6b01a8c0@ericlaptop>
References: <Pine.LNX.4.21.0206250823420.17998-100000@cens.kybi> <000001c21c68$92bef5c0$6b01a8c0@ericlaptop>
Message-ID: <20020625170655.GA15669@taliesen.caltech.edu>

On Tue, Jun 25, 2002 at 11:51:37AM -0500, eric jones wrote:

[snip]

> This sounds like a good idea.  The only issue is that Windows doesn't
> come with tar. 

WinZIP opens gzipped tarballs just fine.

-- 
Robert Kern
Ruddock House President
kern at caltech.edu

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


From eric at enthought.com  Tue Jun 25 13:11:53 2002
From: eric at enthought.com (eric jones)
Date: Tue, 25 Jun 2002 12:11:53 -0500
Subject: [SciPy-dev] adding LAPACK and BLAS to the source code
In-Reply-To: <20020625170655.GA15669@taliesen.caltech.edu>
Message-ID: <000101c21c6b$672f80c0$6b01a8c0@ericlaptop>


> -----Original Message-----
> From: scipy-dev-admin at scipy.net [mailto:scipy-dev-admin at scipy.net] On
> Behalf Of Robert Kern
> Sent: Tuesday, June 25, 2002 12:07 PM
> To: scipy-dev at scipy.net
> Subject: Re: [SciPy-dev] adding LAPACK and BLAS to the source code
> 
> On Tue, Jun 25, 2002 at 11:51:37AM -0500, eric jones wrote:
> 
> [snip]
> 
> > This sounds like a good idea.  The only issue is that Windows
doesn't
> > come with tar.
> 
> WinZIP opens gzipped tarballs just fine.

Right, but the build process would have to do this on the fly, and
making an os.system call to winzip is not a reliable option.  While
widely used, it isn't nearly as ubiquitous as tar is on Unix machines.

Eric


> 
> --
> Robert Kern
> Ruddock House President
> kern at caltech.edu
> 
> "In the fields of hell where the grass grows high
>  Are the graves of dreams allowed to die."
>   -- Richard Harter
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev



From prabhu at aero.iitm.ernet.in  Tue Jun 25 13:21:44 2002
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Tue, 25 Jun 2002 22:51:44 +0530
Subject: [SciPy-dev] adding LAPACK and BLAS to the source code
In-Reply-To: <000001c21c68$92bef5c0$6b01a8c0@ericlaptop>
References: <Pine.LNX.4.21.0206250823420.17998-100000@cens.kybi>
	<000001c21c68$92bef5c0$6b01a8c0@ericlaptop>
Message-ID: <15640.42664.612720.33459@monster.linux.in>

>>>>> "EJ" == eric jones <eric at enthought.com> writes:

    EJ> This sounds like a good idea.  The only issue is that Windows
    EJ> doesn't come with tar.  There is a zlib module in python that
    EJ> solve the zipped issue.  There is also a tarfile module
    EJ> running around that would make tar unnecessary, but last time
    EJ> I tried it, it wasn't that stable.  Anyone know if its current
    EJ> state?

I havent tried it but saw the 0.4 announcement.  I believe it fixes
many issues.  Unfortunately I cant seem to reach the web page.  FWIW
here it is:

http://www.gustaebel.de/lars/tarfile/

prabhu


From kern at caltech.edu  Tue Jun 25 13:35:00 2002
From: kern at caltech.edu (Robert Kern)
Date: Tue, 25 Jun 2002 10:35:00 -0700
Subject: [SciPy-dev] adding LAPACK and BLAS to the source code
In-Reply-To: <000101c21c6b$672f80c0$6b01a8c0@ericlaptop>
References: <20020625170655.GA15669@taliesen.caltech.edu> <000101c21c6b$672f80c0$6b01a8c0@ericlaptop>
Message-ID: <20020625173500.GA17250@taliesen.caltech.edu>

On Tue, Jun 25, 2002 at 12:11:53PM -0500, eric jones wrote:
> 
> 
> > -----Original Message-----
> > From: scipy-dev-admin at scipy.net [mailto:scipy-dev-admin at scipy.net] On
> > Behalf Of Robert Kern
> > Sent: Tuesday, June 25, 2002 12:07 PM
> > To: scipy-dev at scipy.net
> > Subject: Re: [SciPy-dev] adding LAPACK and BLAS to the source code
> > 
> > On Tue, Jun 25, 2002 at 11:51:37AM -0500, eric jones wrote:
> > 
> > [snip]
> > 
> > > This sounds like a good idea.  The only issue is that Windows
> doesn't
> > > come with tar.
> > 
> > WinZIP opens gzipped tarballs just fine.
> 
> Right, but the build process would have to do this on the fly, and
> making an os.system call to winzip is not a reliable option.  While
> widely used, it isn't nearly as ubiquitous as tar is on Unix machines.

True, true. In that case zipping it and using zipfile from the Standard
Library would be best.

> Eric

-- 
Robert Kern
Ruddock House President
kern at caltech.edu

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


From prabhu at aero.iitm.ernet.in  Tue Jun 25 13:59:29 2002
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Tue, 25 Jun 2002 23:29:29 +0530
Subject: [SciPy-dev] adding LAPACK and BLAS to the source code
In-Reply-To: <20020625173500.GA17250@taliesen.caltech.edu>
References: <20020625170655.GA15669@taliesen.caltech.edu>
	<000101c21c6b$672f80c0$6b01a8c0@ericlaptop>
	<20020625173500.GA17250@taliesen.caltech.edu>
Message-ID: <15640.44929.455206.551090@monster.linux.in>

>>>>> "RK" == Robert Kern <kern at caltech.edu> writes:

    >> Right, but the build process would have to do this on the fly,
    >> and making an os.system call to winzip is not a reliable
    >> option.  While widely used, it isn't nearly as ubiquitous as
    >> tar is on Unix machines.

    RK> True, true. In that case zipping it and using zipfile from the
    RK> Standard Library would be best.

Yes, it seems the best portable way of doing this.  However there are
problems with this approach too.  Compressed zip files will require
that the zlib module be compiled.  My install has zlib but does every
Python install include the zlib module?  The other problem with using
a zip file to distribute lapack along with CVS is that the smallest
change of a file inside the zip file will require a fresh download.
It would also mess up CVS because CVS is pretty lousy with binary
files.  So if anything changes it would cause problems.  One
possibility is that the build utilities look for a zip file in a
specific directory and those folks who need to use the lapack sources
simply download the new version and stick it in the right place.  The
builder uses this and compiles everything.  This way we keep the zip
file out of CVS's hair.

cheers,
prabhu



From eric at enthought.com  Fri Jun 28 00:57:49 2002
From: eric at enthought.com (eric jones)
Date: Thu, 27 Jun 2002 23:57:49 -0500
Subject: [SciPy-dev] scipy on irix -- problems with bsplines
Message-ID: <000001c21e60$5a4302f0$6b01a8c0@ericlaptop>

SciPy builds failed in the signal module when trying to build on an SGI
system.

Has anyone seen the following error when building something on IRIX with
gcc 2.95.2?  

25 sgi> gcc -c C_bspline_util.c
C_bspline_util.c: In function `C_IIR_order1':
C_bspline_util.c:28: Unable to access real part of complex value in a
hard register on this target
26 sgi> gcc -c  Z_bspline_util.c
27 sgi> 

It happens in several of the bspline files for complex values, but not
for double complex.  The relevant lines of code from bspline_util.c are:

21 void 
22 C_IIR_order1 (a1, a2, x, y, N, stridex, stridey) 
23     __complex__ float a1; 
24     __complex__ float a2; 
25     __complex__ float *x; 
26     __complex__ float *y; 
27     int N, stridex, stridey; 
28 { 
29     __complex__ float *yvec = y+stridey; 
30    __complex__ float *xvec = x+stridex; 
31    int n; 
32
33    for (n=1; n < N; n++) { 
34	*yvec = *xvec * a1 + *(yvec-stridey) * a2; 
35	yvec += stridey; 
36	xvec += stridex; 
37    } 
38 }

The only references I saw on the net were to previous problems when
building libstdc++ with 2.95.1 on SGI and ALPHA machines.

The good news is, other than this problem, SciPy builds on IRIX using
gcc and linking to the blas and scs(lapack) platform specific libraries.


I also tried building python with MIPSPro C compiler and then SciPy
using
The MIPSPro compiler suite.  The python build worked fine after getting
readline issues sorted out, and it appeared to work fine.  However,
python core dumped in the middle of building the flapack wrappers with
f2py, so it looks like something is working quite right in the python
build.  I'd like to get this working, so if anyone has built
SciPy/Python entirely with MIPSPro, fill me in on the secrets.

Thanks,
eric



From loredo at astrosun.astro.cornell.edu  Fri Jun 28 17:18:30 2002
From: loredo at astrosun.astro.cornell.edu (Tom Loredo)
Date: Fri, 28 Jun 2002 17:18:30 -0400 (EDT)
Subject: [SciPy-dev] Install fails on Solaris 5.7
Message-ID: <200206282118.g5SLIUC27700@laplace.astro.cornell.edu>

Hi folks-

Just downloaded the latest snapshot:  SciPy-0.2.0_alpha_103.3567.
The install chugs along fine until it reaches fastumath:

scipy_base.fastumath fastumath needs fortran libraries 0 0
building 'scipy_base.fastumath' extension
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/home/laplace/include/python2.2 -c /home/laplace/src/python/SciPy-0.2.0_alpha_103.3567/scipy_base/fastumathmodule.c -o build/temp.solaris-2.7-sun4u-2.2/fastumathmodule.o
/home/laplace/src/python/SciPy-0.2.0_alpha_103.3567/scipy_base/fastumathmodule.c:24:36: fastumath_nounsigned.inc: No such file or directory
/home/laplace/include/python2.2/Numeric/arrayobject.h:275: warning: `PyArray_API' defined but not used
/home/laplace/include/python2.2/Numeric/ufuncobject.h:131: warning: `PyUFunc_API' defined but not used
error: command 'gcc' failed with exit status 1


I can't find any .inc files anywhere in the snapshot; I don't know if
that's what's causing the failure or not.  Any hints?

Thanks,
Tom


From eric at enthought.com  Fri Jun 28 17:14:05 2002
From: eric at enthought.com (eric jones)
Date: Fri, 28 Jun 2002 16:14:05 -0500
Subject: [SciPy-dev] Install fails on Solaris 5.7
In-Reply-To: <200206282118.g5SLIUC27700@laplace.astro.cornell.edu>
Message-ID: <000001c21ee8$bc32d890$6b01a8c0@ericlaptop>

Hey Tom,

I just ran into this too.  It has to do with some changes in the CVS
sources that didn't make it into the MANIFEST.in file (the file that
controls what gets put in the source tar balls each night).  I fixed
these today, and tonight's tarballs should work.  

You can fix your problem today by just going to the cvs repository
online

http://www.scipy.org/site_content/remap?rmurl=http%3A//scipy.net/cgi-bin
/viewcvsx.cgi/scipy/scipy_base/

and copying the two .inc files you see there into your scipy/scipy_base
directory.  Then build again.

Hopefully that will work.  

By the way, what lapack are you compiling against?

Eric

> -----Original Message-----
> From: scipy-dev-admin at scipy.net [mailto:scipy-dev-admin at scipy.net] On
> Behalf Of Tom Loredo
> Sent: Friday, June 28, 2002 4:19 PM
> To: scipy-dev at scipy.org
> Subject: [SciPy-dev] Install fails on Solaris 5.7
> 
> 
> Hi folks-
> 
> Just downloaded the latest snapshot:  SciPy-0.2.0_alpha_103.3567.
> The install chugs along fine until it reaches fastumath:
> 
> scipy_base.fastumath fastumath needs fortran libraries 0 0
> building 'scipy_base.fastumath' extension
> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -
> I/home/laplace/include/python2.2 -c /home/laplace/src/python/SciPy-
> 0.2.0_alpha_103.3567/scipy_base/fastumathmodule.c -o
build/temp.solaris-
> 2.7-sun4u-2.2/fastumathmodule.o
> /home/laplace/src/python/SciPy-
> 0.2.0_alpha_103.3567/scipy_base/fastumathmodule.c:24:36:
> fastumath_nounsigned.inc: No such file or directory
> /home/laplace/include/python2.2/Numeric/arrayobject.h:275: warning:
> `PyArray_API' defined but not used
> /home/laplace/include/python2.2/Numeric/ufuncobject.h:131: warning:
> `PyUFunc_API' defined but not used
> error: command 'gcc' failed with exit status 1
> 
> 
> I can't find any .inc files anywhere in the snapshot; I don't know if
> that's what's causing the failure or not.  Any hints?
> 
> Thanks,
> Tom
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev



From pearu at cens.ioc.ee  Sat Jun 29 12:24:43 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Sat, 29 Jun 2002 19:24:43 +0300 (EEST)
Subject: [SciPy-dev] scipy on irix -- problems with bsplines
In-Reply-To: <000001c21e60$5a4302f0$6b01a8c0@ericlaptop>
Message-ID: <Pine.LNX.4.21.0206291916220.1604-100000@cens.kybi>

On Thu, 27 Jun 2002, eric jones wrote:

> I also tried building python with MIPSPro C compiler and then SciPy
> using
> The MIPSPro compiler suite.  The python build worked fine after getting
> readline issues sorted out, and it appeared to work fine.  However,
> python core dumped in the middle of building the flapack wrappers with
> f2py, so it looks like something is working quite right in the python
> build.  I'd like to get this working, so if anyone has built
> SciPy/Python entirely with MIPSPro, fill me in on the secrets.

Did you disable g77 compiler from the header
of scipy/linalg/setup_linalg.py?
In the latest CVS version of linalg the g77 compiler is forced only for
win32.

Another question: does your irix have ranlib? In irix64-6.5-2.1 that I can
access it is missing.

Pearu



From pearu at cens.ioc.ee  Sat Jun 29 17:13:52 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Sun, 30 Jun 2002 00:13:52 +0300 (EEST)
Subject: [SciPy-dev] scipy on irix -- problems with bsplines
In-Reply-To: <000001c21e60$5a4302f0$6b01a8c0@ericlaptop>
Message-ID: <Pine.LNX.4.21.0206292355020.8927-100000@cens.kybi>

Hi Eric,

On Thu, 27 Jun 2002, eric jones wrote:

> I also tried building python with MIPSPro C compiler and then SciPy
> using
> The MIPSPro compiler suite.  The python build worked fine after getting
> readline issues sorted out, and it appeared to work fine.  However,
> python core dumped in the middle of building the flapack wrappers with
> f2py, so it looks like something is working quite right in the python
> build.  I'd like to get this working, so if anyone has built
> SciPy/Python entirely with MIPSPro, fill me in on the secrets.

I have build SciPy entirely with MIPSPro compilers. Here follows my setup:

Python 2.1.1 (#1, Oct 21 2001, 16:10:39) [C] on irix646
Numeric 20.2.1
$ cc -version 
MIPSpro Compilers: Version 7.30
$ f77 -version
MIPSpro Compilers: Version 7.30
No ATLAS. LAPACK (3.3.14) and BLAS are built from their source (the latest
SciPy in CVS supports this feature).

My guess is that the secret you are looking for is to remove forcing g77
in scipy/setup.py file.

All tests (level=10) pass except weave tests. Typical error messages from
weave tests are: 

cc-1132 cc: ERROR File = /usr/include/CC/istream, Line = 43
  The class "std::char_traits<char>" has no member "off_type".

    typedef typename _Traits::off_type off_type;
                              ^
          detected during instantiation of class
                    "std::basic_istream<char, std::char_traits<char>>" at
line 92 of "/usr/include/CC/strstream"


cc-1079 cc: ERROR File = /usr/include/CC/strstream, Line = 136
  A type specifier is expected.

    typedef char_traits<char>::off_type off_type;


Regards,
	Pearu