Mailman 3 January 2003 - SciPy-Dev

cow: 'Connection reset by peer' timeout problem?
by Simon Saubern Feb. 1, 2003

Feb. 1, 2003

I'm re-posting this message here as I didn't get any replies on the scipy-users list: I've been using cow to try out some distributed calculations. Everything works fine if I use a subset of my data, but when I use the full set I get "error: (10054, 'Connection reset by peer')" messages on the master unit (see below for full output). I can operate on larger and larger subsets until I get to the point where if the slaves take more than about 4 minutes to complete a task, the above error appears at the master. That is, connections are established (confirmed using netstat), processing occurs on the slaves and keeps going, but the master times out after about 4min. Is this a 'keep alive' problem? If so, how can I extend the time out period? The setup: 10 x slave + master, all Win2K SP-3 Python 2.2.2 latest scipy binary for Win cowname['data']=data # a list 35000 long. lendata=range(7000) # just use a subset bessy=None while not bessy: bessy=cowname.loop_code('do something;do something;calc=function(data[x])',loop_var='x',inputs={'x':lendata},returns=['calc']) bessy gets processed here 'data' is quite large and takes a while to transfer over the network. But by doing it once and looping over the index, I minimize network movements. The 'python' process on each slave uses about 85MB. Increasing 'lendata' eventually causes the 'Connection reset by peer' message to appear. Any pointers welcomed. ---------------error output File "C:\PROGRA~1\Python22\Lib\site-packages\scipy\cow\cow.py", line 823, in loop_code return self.loop_send_recv(package,loop_data,loop_var) File "C:\PROGRA~1\Python22\Lib\site-packages\scipy\cow\cow.py", line 847, in loop_send_recv results = self._send_recv(package,addendums) File "C:\PROGRA~1\Python22\Lib\site-packages\scipy\cow\cow.py", line 345, in _send_recv self.last_results = self._recv() File "C:\PROGRA~1\Python22\Lib\site-packages\scipy\cow\cow.py", line 303, in _recv results.append(worker.recv()) File "C:\PROGRA~1\Python22\Lib\site-packages\scipy\cow\sync_cluster.py", line 404, in recv package = self.channel.read() File "C:\PROGRA~1\Python22\Lib\site-packages\scipy\cow\sync_cluster.py", line 164, in read x = self.rfile.read() File "c:\Program Files\Python22\lib\socket.py", line 228, in read new = self._sock.recv(k) error: (10054, 'Connection reset by peer') >>> ------------ -- Cheers, Simon

2 1

Re: [SciPy-dev] referenced symbol not found
by Alain Sartout Jan. 30, 2003

Jan. 30, 2003

Hello Pearu, Thanks for help... > >Same here.. I am stuck with atlas when using gcc-2.95.3 compiler >(I am getting > >/tmp/pp_atlas/bin/SunOS_Gnu2.95.3_SunUS2_2/ATLrun.sh \ >/tmp/pp_atlas/tune/blas/gemm/SunOS_Gnu2.95.3_SunUS2_2 xdfc \ >res/dNCNB20_1000 >dNB=20, ld=1000,20,20, mu=2, nu=3, ku=12, lat=4: time=1.320, mflop=166.97 >dNB=20, ld=1000,20,20, mu=2, nu=3, ku=12, lat=4: time=1.300, mflop=169.54 >dNB=20, ld=1000,20,20, mu=2, nu=3, ku=12, lat=4: time=1.290, mflop=170.85 >*** Signal 10 - core dumped > >when running 'make install arch=SunOS_Gnu2.95.3_SunUS2_2' but >direct execution of > >/tmp/pp_atlas/bin/SunOS_Gnu2.95.3_SunUS2_2/ATLrun.sh \ >/tmp/pp_atlas/tune/blas/gemm/SunOS_Gnu2.95.3_SunUS2_2 xdfc \ >res/dNCNB20_1000 > >always succeeds. Any hints are appreciated about what could be >going on here.). > >Could you share your experience with building atlas libraries on SunOS? >The contents of ATLAS/Make.<arch> would be very helpful. trace running : ./ATLrun.sh /src/solaris8/ATLAS/tune/blas/gemm/SunOS_UNKNOWN_12/xdfc dNB=60, ld=24,24,60, mu=5, nu=3, ku=24, lat=5: time=0.830, mflop=1219.80 dNB=60, ld=24,24,60, mu=5, nu=3, ku=24, lat=5: time=0.830, mflop=1219.80 dNB=60, ld=24,24,60, mu=5, nu=3, ku=24, lat=5: time=0.820, mflop=1234.68 You will find in attachement Make.SunOS_UNKNOW_12 ATLAS was compiled using both gcc ans SUN forte6 suite (SUN CC and F77) >Can you determine in which (system) library this symbol __sincos is >defined? No...! >One should never try building python packages containing extension >modules in their installation directories such as > /usr/local/lib/python2.2/site-packages/... >! It will never work because sources are not installed. >So, try > > cd cvs/scipy/linalg > python setup_atlas_version.py build_ext --inplace --force trying that in source dir : python setup_atlas_version.py build_ext --inplace --force atlas_info: FOUND: libraries = ['lapack', 'f77blas', 'cblas', 'atlas'] library_dirs = ['/usr/local/lib/atlas'] include_dirs = ['/usr/local/include'] running build_ext building 'atlas_version' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/usr/local/include/python2.2 -c /src/solaris8/SciPy-0.2.0_alpha_144.4350/linalg/atlas_version.c -o build/temp.solaris-2.8-sun4u-2.2/atlas_version.o gcc: /src/solaris8/SciPy-0.2.0_alpha_144.4350/linalg/atlas_version.c: No such file or directory gcc: no input files error: command 'gcc' failed with exit status 1 >Can you import other extension modules? Try > > cd /usr/local/lib/python2.2/site-packages/scipy/<modulename> > ls *.so > for example "import clapack" in linalg module works (or Numeric also...) imports are OK Alain. ------Alain SARTOUT---------------------------------------------------------- office : IRMA - CNRS UMR 7501, 7 rue Rene Descartes F-67084 STRASBOURG phone : (33) [0]3 90 24 01 72 fax: (33) [0]3 90 24 03 28 e-mail : Alain.Sartout(a)math.u-strasbg.fr WWW : http://www-irma.u-strasbg.fr ----------------------------------------------------------------------------- # ---------------------------------- # Make sure we get the correct shell # ---------------------------------- SHELL = /bin/sh # ------------------------------------------------- # Name indicating the platform to configure BLAS to # ------------------------------------------------- ARCH = SunOS_UNKNOWN_12 # ------------------- # Various directories # ------------------- TOPdir = /src/solaris8/ATLAS INCdir = $(TOPdir)/include/$(ARCH) SYSdir = $(TOPdir)/tune/sysinfo/$(ARCH) GMMdir = $(TOPdir)/src/blas/gemm/$(ARCH) UMMdir = $(GMMdir) GMVdir = $(TOPdir)/src/blas/gemv/$(ARCH) GR1dir = $(TOPdir)/src/blas/ger/$(ARCH) L1Bdir = $(TOPdir)/src/blas/level1/$(ARCH) L2Bdir = $(TOPdir)/src/blas/level2/$(ARCH) L3Bdir = $(TOPdir)/src/blas/level3/$(ARCH) TSTdir = $(TOPdir)/src/testing/$(ARCH) AUXdir = $(TOPdir)/src/auxil/$(ARCH) CBLdir = $(TOPdir)/interfaces/blas/C/src/$(ARCH) FBLdir = $(TOPdir)/interfaces/blas/F77/src/$(ARCH) BINdir = $(TOPdir)/bin/$(ARCH) LIBdir = $(TOPdir)/lib/$(ARCH) PTSdir = $(TOPdir)/src/pthreads MMTdir = $(TOPdir)/tune/blas/gemm/$(ARCH) MVTdir = $(TOPdir)/tune/blas/gemv/$(ARCH) R1Tdir = $(TOPdir)/tune/blas/ger/$(ARCH) L1Tdir = $(TOPdir)/tune/blas/level1/$(ARCH) L3Tdir = $(TOPdir)/tune/blas/level3/$(ARCH) # --------------------------------------------------------------------- # Name and location of scripts for running executables during tuning # --------------------------------------------------------------------- ATLRUN = $(BINdir)/ATLrun.sh ATLFWAIT = $(BINdir)/xatlas_waitfile # --------------------- # Libraries to be built # --------------------- ATLASlib = $(LIBdir)/libatlas.a CBLASlib = $(LIBdir)/libcblas.a F77BLASlib = $(LIBdir)/libf77blas.a PTCBLASlib = $(LIBdir)/libptcblas.a PTF77BLASlib = $(LIBdir)/libptf77blas.a LAPACKlib = $(LIBdir)/liblapack.a TESTlib = $(LIBdir)/libtstatlas.a # ------------------------------------------- # Upper bound on largest cache size, in bytes # ------------------------------------------- L2SIZE = -DL2SIZE=4194304 # --------------------------------------- # Command setting up correct include path # --------------------------------------- INCLUDES = -I$(TOPdir)/include -I$(TOPdir)/include/$(ARCH) \ -I$(TOPdir)/include/contrib # ------------------------------------------- # Defines for setting up F77/C interoperation # ------------------------------------------- F2CDEFS = # -------------------------------------- # Special defines for user-supplied GEMM # -------------------------------------- UMMDEFS = # ------------------------------ # Architecture identifying flags # ------------------------------ ARCHDEFS = -DATL_OS_SunOS # ------------------------------------------------------------------- # NM is the flag required to name a compiled object/executable # OJ is the flag required to compile to object rather than executable # These flags are used by all compilers. # ------------------------------------------------------------------- NM = -o OJ = -c # --------------------------------------------------------------------------- # Fortran 77 compiler and the flags to use. Presently, ATLAS does not itself # use any Fortran 77, but vendor BLAS are typically written for Fortran, so # any links that include non-ATLAS BLAS will use FLINKER instead of CLINKER # --------------------------------------------------------------------------- F77 = /opt/SUNWspro/bin/f77 F77FLAGS = -dalign -native -xO5 -mt FLINKER = $(F77) FLINKFLAGS = $(F77FLAGS) FCLINKFLAGS = $(FLINKFLAGS) # --------------------------------------------------------------------------- # Various C compilers, and the linker to be used when we are not linking in # non-ATLAS BLAS (which usually necessitate using the Fortran linker). # The C compilers recognized by ATLAS are: # CC : Compiler to use to compile regular, non-generated code # MCC : Compiler to use to compile generated, highly-optimized code # XCC : Compiler to be used on the compile engine of a cross-compiler # These will typically all be the same. An example of where this is not # the case would be DEC ALPHA 21164, where you want to use gcc for MCC, # because DEC's cc does not allow the programmer access to all 32 floating # point registers. However, on normal C code, DEC's cc produces much faster # code than gcc, so you CC set to cc. Of course, any system where you are # cross-compiling, you will need to set XCC differently than CC & MCC. # --------------------------------------------------------------------------- CDEFS = $(L2SIZE) $(INCLUDES) $(F2CDEFS) $(ARCHDEFS) -DATL_NCPU=12 GOODGCC = /usr/local/bin/gcc CC = /opt/SUNWspro/bin/cc CCFLAG0 = -dalign -fsingle -xO5 -native -mt CCFLAGS = $(CDEFS) $(CCFLAG0) MCC = /opt/SUNWspro/bin/cc MMFLAGS = -dalign -fsingle -xO2 -native -mt XCC = /opt/SUNWspro/bin/cc XCCFLAGS = $(CDEFS) -dalign -fsingle -xO5 -native -mt CLINKER = $(CC) CLINKFLAGS = $(CCFLAGS) BC = $(CC) BCFLAGS = $(CCFLAGS) ARCHIVER = ar ARFLAGS = r RANLIB = echo # ------------------------------------- # tar, gzip, gunzip, and parallel make # ------------------------------------- TAR = /usr/bin/tar GZIP = /usr/bin/gzip GUNZIP = /usr/bin/gunzip PMAKE = $(MAKE) # ------------------------------------ # Reference and system libraries # ------------------------------------ BLASlib = -xlic_lib=sunperf FBLASlib = FLAPACKlib = LIBS = -lpthread -lm # ---------------------------------------------------------- # ATLAS install resources (include arch default directories) # ---------------------------------------------------------- ARCHDEF = MMDEF = INSTFLAGS = # --------------------------------------- # Generic targets needed by all makefiles # --------------------------------------- waitfile:

1 0

referenced symbol not found
by Alain Sartout Jan. 30, 2003

Jan. 30, 2003

Hello, I have problems for a scipy installation on Sun solaris8. I have try a lot compilation for all software list (pyhon, lapack, atlas etc...) whith SunCC, gcc for different version of python etc... It never works! Here the output from python when I try to import scipy : ----------------------- irmasrv3 [290] > python Python 2.2.2 (#5, Jan 29 2003, 14:13:36) [GCC 3.2] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import scipy Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/local/lib/python2.2/site-packages/scipy/__init__.py", line 49, in ? import special, io, linalg, stats, fftpack File "/usr/local/lib/python2.2/site-packages/scipy/special/__init__.py", line 326, in ? from special import * File "/usr/local/lib/python2.2/site-packages/scipy/special/special.py", line 5, in ? from cephes import * ImportError: ld.so.1: python: fatal: relocation error: file /usr/local/lib/python2.2/site-packages/scipy/special/cephes.so: symbol __sincos: referenced symbol not found ----------------------- Here, somme informations about software versions : irmasrv3 [291] > python -c 'import os,sys;print os.name,sys.platform' posix sunos5 irmasrv3 [292] > uname -a SunOS irmasrv3 5.8 Generic_108528-12 sun4u sparc SUNW,Sun-Fire irmasrv3 [293] > gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.2/specs Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls Thread model: posix gcc version 3.2 irmasrv3 [294] > g77 --version GNU Fortran (GCC 3.2) 3.2 20020814 (release) Copyright (C) 2002 Free Software Foundation, Inc. irmasrv3 [295] > python -c 'import sys;print sys.version' 2.2.2 (#5, Jan 29 2003, 14:13:36) [GCC 3.2] irmasrv3 [296] > python -c 'import Numeric;print Numeric.__version__' 22.0 irmasrv3 [297] > f2py -v 2.32.225-1419 irmasrv3 [467] # cd /usr/local/lib/python2.2/site-packages/scipy/linalg irmasrv3 [468] # python setup_atlas_version.py build_ext --inplace --force atlas_info: FOUND: libraries = ['lapack', 'f77blas', 'cblas', 'atlas'] library_dirs = ['/usr/local/lib/atlas'] include_dirs = ['/usr/local/include'] running build_ext building 'atlas_version' extension creating build creating build/temp.solaris-2.8-sun4u-2.2 gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/usr/local/include/python2.2 -c /usr/local/lib/python2.2/site-packages/scipy/linalg/atlas_version.c -o build/temp.solaris-2.8-sun4u-2.2/atlas_version.o gcc: /usr/local/lib/python2.2/site-packages/scipy/linalg/atlas_version.c: No such file or directory gcc: no input files error: command 'gcc' failed with exit status 1 irmasrv3 [472] # python scipy_distutils/system_info.py atlas_info: FOUND: libraries = ['lapack', 'f77blas', 'cblas', 'atlas'] library_dirs = ['/usr/local/lib/atlas'] include_dirs = ['/usr/local/include'] blas_info: NOT AVAILABLE blas_src_info: NOT AVAILABLE dfftw_info: FOUND: libraries = ['drfftw', 'dfftw'] library_dirs = ['/usr/local/lib'] define_macros = [('SCIPY_DFFTW_H', None)] include_dirs = ['/usr/local/include'] dfftw_threads_info: FOUND: libraries = ['drfftw_threads', 'dfftw_threads'] library_dirs = ['/usr/local/lib'] define_macros = [('SCIPY_DFFTW_THREADS_H', None)] include_dirs = ['/usr/local/include'] djbfft_info: NOT AVAILABLE fftw_info: FOUND: libraries = ['fftw', 'rfftw'] library_dirs = ['/usr/local/lib'] define_macros = [('SCIPY_FFTW_H', None)] include_dirs = ['/usr/local/include'] fftw_threads_info: NOT AVAILABLE lapack_info: FOUND: libraries = ['lapack'] library_dirs = ['/usr/local/lib'] lapack_src_info: NOT AVAILABLE sfftw_info: NOT AVAILABLE sfftw_threads_info: NOT AVAILABLE x11_info: NOT AVAILABLE Thanks for your help Alain. ------Alain SARTOUT---------------------------------------------------------- office : IRMA - CNRS UMR 7501, 7 rue Rene Descartes F-67084 STRASBOURG phone : (33) [0]3 90 24 01 72 fax: (33) [0]3 90 24 03 28 e-mail : Alain.Sartout(a)math.u-strasbg.fr WWW : http://www-irma.u-strasbg.fr -----------------------------------------------------------------------------

2 1

Broken link in www.scipy.org
by Roy at SEVENtwentyfour Inc. Jan. 30, 2003

Jan. 30, 2003

There appears to be a problem on this page of your site. On page http://www.scipy.org/site_content/tutorials/FAQ when you click on "Cathedral and the Bazaar", the link to http://www.tuxedo.org/~esr/writings/cathedral-bazaar/ gives the error: Not found. As recommended by the Robot Guidelines, this email is to explain our robots activities and to let you know about one of the broken links we encountered. LinkWalker does not store or publish the content of your pages, but rather uses the link information to update our map of the World Wide Web. Are these reports helpful? I'd love some feedback. If you prefer not to receive these occasional error notices please let me know. Roy Bryant ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Roy Bryant, roybryant(a)seventwentyfour.com President SEVENtwentyfour Inc. ("Always watching the Web") http://www.seventwentyfour.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Inconsisten return type from discrete dists.
by Otto Tronarp Jan. 27, 2003

Jan. 27, 2003

Hello, I started looking on writing some unit tests anyway. While doing that I discovered that the return type from discrete distributions where inconsistent or rather they all seems to return floats except for randint. Further, some of them also returns a array of length 1 when called without size argument while others return a simple number. For the first issue I feel that it is more natural for them to return ints, the attached patch, return_ints.pathc, fixes that. For the second issue I think that it is more convenient if they always returns an array. I have no patch for that, but I can fix it if that is the consensus. While I wrote the unit tests I also found more bugs. There seem to be a missing function in rv.py, namley _check_shape. By the look of how it's used it should do something like this: def _check_shape(size): if isinstance(size, tuple): Ns = reduce(operator.mul, size) else: Ns = size return (size, Ns) Attached patch, missing_check_shape.patch, fixes that. I also have a couple of question on coding guide lines. 1 - What is the correct way to check if a array is of integer type? 2 - What is the correct way to call things from Numeric? i.e. scipy.shape(a) or Numeric.shape(a)? Regards, Otto

3 5

Problem with stats.distributions.randint
by Otto Tronarp Jan. 27, 2003

Jan. 27, 2003

Hi, I'm having problem with stats.distributions.randint, I get the following traceback: >>> ri = scipy.stats.distributions.randint(0,5) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/home/zzap/sandbox/py-lib/lib/python2.2/site-packages/scipy/stats/distri butions.py", line 2727, in __call__ U = rv.random(size=self._size) AttributeError: 'module' object has no attribute 'random' So I took a look in rv.py and I couldn't find any there. By the look of the cvslog it seems like a lot of functionality was moved from rv to distributions about 2 month ago and by the look of it random was moved so I tried to change that line to U = random(size=self._size) But now I get: ri=scipy.stats.distributions.randint(0,5) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/home/zzap/sandbox/py-lib/lib/python2.2/site-packages/scipy/stats/distributions.py", line 2727, in __call__ U = random(size=self._size) AttributeError: randint_gen instance has no attribute '_size' Poking around in the source a little more it seem like the only place where self._size is set is in rv_discrete.rvs and that one is called from rvc_discrete.__call__, but since randint_gen overides the __call__ method it's never set. Am I correct in my analysis? If so is the attached patch the correct cure? Regards, Otto

4 10

Error in stats/discrete.lyx
by Otto Tronarp Jan. 27, 2003

Jan. 27, 2003

While writing the unit tests for the discrete distributions I looked a little in discrete.lyx to fresh up my memory on some of the distributions. And there seems to be an error in the section on negative binomial distribution. It says "..can be defined as the number of independent trials required to accumulate a total of n successes" which gives a valid range for k as k>=n. However, I always thought it was the number of failures before reaching n success and hence k>=0. The result from stats.nbinom seems to agree with me, it seldom generates numbers larger than n. I don't have a patch for this since the docs seems to be written with an old version of lyx that I don't have. Regards, Otto

2 2

still getting undefined symbols on scipy builds on SunOS
by eric jones Jan. 24, 2003

Jan. 24, 2003

Hey Pearu, I've added the mvec library to the SunOS compiler, and that, along with your additions, solved my build problems on an f90 project that we discussed a week or so ago. But, I just noticed scipy doesn't all link correctly on sun now -- at least the linalg library doesn't on my machine when building with Forte f90. I get undefined symbols for s_stop and s_copy on calc_lwork and _flinalg. I expect the others have similar problems. bash-2.05$ nm calc_lwork.so | grep s_copy [236] | 0| 0|NOTY |GLOB |0 |UNDEF |s_copy When looking at the object file, I don't see this symbol anywhere, which means it is coming from some other library? bash-2.05$ nm -A calc_lwork.o | grep s_copy bash-2.05$ I added f77_compat which has: bash-2.05$ cd /opt/SUNWspro/lib bash-2.05$ nm -A *.so | grep s_copy libf77compat.so: [1800] | 109760| 292|FUNC |GLOB |0 |9 |__s_copy libf77compat.so: [900] | 0| 0|FILE |LOCL |0 |ABS |s_copy.c libfsu.so: [3657] | 121972| 492|FUNC |GLOB |0 |9 |__f90_s_copy libfsu.so: [1168] | 0| 0|FILE |LOCL |0 |ABS |f90s_copy.c Do you think there is some name mangling issues occurring here, or is it that I need to add a different library? Oooo. I think I figured it out. I bet my version of atlas was built with g77. Yep: bash-2.05$ cd /usr/lib bash-2.05$ nm liblapack.a | grep s_copy [6] | 0| 0|NOTY |GLOB |0 |UNDEF |s_copy So, adding -L/opt/sfw/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3 -lg2c to the link line gets everything to compile. So, should atlas_info try and go a step further and check what compiler was used to build lapack and friends? If it sees g77, it could add the library g2c and the appropriate library directory to the path. The combinations are endless, but, since ATLAS is usually built with gcc, the given case is probably pretty common. I'd like to hear your ideas (or anyone elses), as I might have missed an easier approach. Thanks, eric ---------------------------------------------- eric jones 515 Congress Ave www.enthought.com Suite 1614 512 536-1057 Austin, Tx 78701

2 1

"Lifestyle Trades"
by Trump Trading Report Jan. 17, 2003

Jan. 17, 2003

"Im talking about a trade so big, so perfect, so incredible that it could singlehandedly change your entire lifestyle..." Trump Trading Report Searching for the "Big One" I have been educating and helping individuals make insightful and strategic investment decisions for many years. Along with this brief introduction I have included some of the recent big moves that I have predicted, and their results. I have worked on these strategies for several years now trying to unlock the secrets that only the markets know. Coming to only one simple conclusion, I have found that everyone whom I have seen make it big, I mean really big seemed to hit that one home run, they had that one trade that just seemed to make them a fortune. These so called "Big Ones" have fascinated me for as long as I can remember. Their elusiveness and mystique simply send chills down my spine. I'm not the only one, people everywhere seem to want the opportunity to hit it big just once. On the floor, we used to call it a "lifestyle trade", a trade so big, so perfect, so incredible that it could singlehandedly change your entire lifestyle. These are the opportunities I am talking about, these are the opportunities that are out there. Don't let people tell you they are not. I have seen them, I have felt them, I have watched them over the past several years change peoples lives. I have watched them buy exotic cars, build million dollar getaways, pay for college tuition's...All you have to do is find the right wave and ride it out. The money is there..., the markets are there..., it is all just sitting there waiting for you...,can you pick the right one??? Recent "Big Ones" Coffee (1999) $25,000 into $217,875.....Corn (2002) $5,000 into $47,000.....S&P 500 (1998) $24,000 into $1,025,750.....Crude Oil (2002) Gains of over $16,000 per contract.....Sugar (2000) $6,400 into $82,200.....Soybeans (2002) $12,000 into $125,400.....Silver (2002) $10,000 into $44,800.....Orange Juice (2001) $11,000 to $72,000.....Gold (1999) $8,500 into $148,400.....Lean Hogs (2002) $14,000 into $179,600.....Unleaded Gas (2002) $25,000 into $194,040 All for only $20 month You will receive In-depth Market Analysis, the latest Industry Breaking News, Detailed Trading Strategies and Comprehensive Professional Commentary all for only $20 per month. "I have subscribed to hundreds of so called investment newsletters, but none give me the real inside scoop or hot tips on the big moves like the Trump Trading Report ." Dr. Davenport, Missouri "If I had to recommend just one man to follow, or one newsletter to read, this would be the one. These strategies and reports could make you an absolute fortune." Lance J. Holbrook, Texas "Absolutely the best, finally something everyone can understand, a must for anyone trading in today's markets." John Noblit, Arizona "The information is fantastic, its as if I am right there looking over his shoulder." Larry Rains, California No Risk Money Back Guarantee If at any time you are not completely satisfied with the Trump Trading Report or its content we will refund 100% of your monthly cost. No Questions Asked!!! Sign Me Up Today Call Toll Free 1-800-357-5249 for Master Card and Visa Send Personal Checks to: PO Box 481934, Kansas City, MO 64148 Questions and additional Information: kvt(a)casstel.net or visit www.trumptrading.com If you have received this email in error we appologize, this leter is being sent to pre-qualified addresses whom have indicated investment interest. To be removed please reply to this email with remove in the subject area.

1 0

SciPy 0.2
by Travis Oliphant Jan. 14, 2003

Jan. 14, 2003

We really need to get SciPy 0.2 done, right. What has left to be done. Should I spend time writing more docs, or writing more tests? Probably both, right? Are packaging issues all that remain. There are stable ATLAS binaries that work for many cases, now, so everybody doesn't have to compile ATLAS. Are we waiting for Chaco to mature, more? What needs to be done to complete the 0.2 cycle? -Travis O. -- Travis Oliphant Assistant Professor 459 CB Electrical and Computer Engineering Brigham Young University Provo, UT 84602 Tel: (801) 422-3108 oliphant.travis(a)ieee.org

2 1