From joe at enthought.com Wed Feb 1 04:49:17 2006 From: joe at enthought.com (Joe Cooper) Date: Wed, 01 Feb 2006 03:49:17 -0600 Subject: [SciPy-dev] The new SciPy.org Message-ID: <43E0841D.2020809@enthought.com> Hi all, I've made a few changes to the site, per suggestions from various folks: - Site is now accessible at http://www.scipy.org and it doesn't redirect to /Wiki. The /Wiki path is still accessible, as I found that there's no way to make Firefox/Mozilla forget about the cached redirect page short of flushing your browser cache. I recommend doing so, if you plan to link to SciPy.org. The preferred link will be without the /Wiki path. - Mailing Lists have their own heading. - svn.scipy.org is in its own virtual domain. This makes it impossible for me or anyone to cause the trouble with svn access Robert ran into this morning by messing with the www.scipy.org configuration. - Logo has been added. From arnd.baecker at web.de Wed Feb 1 06:08:28 2006 From: arnd.baecker at web.de (Arnd Baecker) Date: Wed, 1 Feb 2006 12:08:28 +0100 (CET) Subject: [SciPy-dev] an atttempt at sandbox/xplt Message-ID: Hi, I had a try to get get sandbox/xplt working. Attached is a diff how far I got. Compiling works, but I got the directory structure wrong (I essentially understand nothing about scipy distutils, so this is not surprising ;-). Presently stuff gets installed into scipy/xplt/sandbox (fine sofar) and scipy/xplt/sandbox/Lib/sandbox/xplt (contains *.c, *.h, *.gp, *.gs) scipy/xplt/sandbox/scipy/sandbox/xplt (contains gistC.so) According to the old scipy diretory structure gistC.so should directly end up in scipy/xplt/ and the only directory in scipy/xplt should be gistdata/ containing *.gs and *.gp files. Before I start digging further, does an expert see straight away what has to be done to correct the above? Best, Arnd -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: svn_diff.diff URL: From pearu at scipy.org Wed Feb 1 07:54:18 2006 From: pearu at scipy.org (Pearu Peterson) Date: Wed, 1 Feb 2006 06:54:18 -0600 (CST) Subject: [SciPy-dev] an atttempt at sandbox/xplt In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Arnd Baecker wrote: > Hi, > > I had a try to get get sandbox/xplt working. > Attached is a diff how far I got. > > Compiling works, but I got the directory structure wrong > (I essentially understand nothing about scipy distutils, so > this is not surprising ;-). > Presently stuff gets installed into > scipy/xplt/sandbox (fine sofar) > and > scipy/xplt/sandbox/Lib/sandbox/xplt (contains *.c, *.h, *.gp, *.gs) > scipy/xplt/sandbox/scipy/sandbox/xplt (contains gistC.so) > > According to the old scipy diretory structure > gistC.so should directly end up in scipy/xplt/ > and the only directory in scipy/xplt should > be gistdata/ containing *.gs and *.gp files. > > Before I start digging further, does an expert see > straight away what has to be done to correct the above? The last line in your patch should read config.add_data_dir(('gistdata',xplt_path)) Anyway, I have applied your patch with few modifications to svn. Thanks, Pearu From pearu at scipy.org Wed Feb 1 07:56:22 2006 From: pearu at scipy.org (Pearu Peterson) Date: Wed, 1 Feb 2006 06:56:22 -0600 (CST) Subject: [SciPy-dev] an atttempt at sandbox/xplt In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Pearu Peterson wrote: > The last line in your patch should read > config.add_data_dir(('gistdata',xplt_path)) ..that is config.add_data_files(('gistdata',xplt_files)) Pearu From arnd.baecker at web.de Wed Feb 1 09:41:36 2006 From: arnd.baecker at web.de (Arnd Baecker) Date: Wed, 1 Feb 2006 15:41:36 +0100 (CET) Subject: [SciPy-dev] an atttempt at sandbox/xplt In-Reply-To: References: Message-ID: Hi, On Wed, 1 Feb 2006, Pearu Peterson wrote: > On Wed, 1 Feb 2006, Arnd Baecker wrote: > > > Hi, > > > > I had a try to get get sandbox/xplt working. > > Attached is a diff how far I got. > > > > Compiling works, but I got the directory structure wrong > > (I essentially understand nothing about scipy distutils, so > > this is not surprising ;-). > > Presently stuff gets installed into > > scipy/xplt/sandbox (fine sofar) > > and > > scipy/xplt/sandbox/Lib/sandbox/xplt (contains *.c, *.h, *.gp, *.gs) > > scipy/xplt/sandbox/scipy/sandbox/xplt (contains gistC.so) > > > > According to the old scipy diretory structure > > gistC.so should directly end up in scipy/xplt/ > > and the only directory in scipy/xplt should > > be gistdata/ containing *.gs and *.gp files. > > > > Before I start digging further, does an expert see > > straight away what has to be done to correct the above? > > The last line in your patch should read > config.add_data_dir(('gistdata',xplt_path)) > > Anyway, I have applied your patch with few modifications to svn. Thanks a lot Pearu! gistC.so ends up in the right place now. There is also a duplicate under scipy/xplt/sandbox/scipy/sandbox/xplt/gistC.so Not sure where this comes from/how to get rid off this. Note that presently xplt is not yet working (a few replaces from `scipy.xplt` to `scipy.sandbox.xplt` have to be made). After this, the first error is a typecode one. I will look into all this over the weekend. Best, Arnd From pearu at scipy.org Wed Feb 1 10:34:44 2006 From: pearu at scipy.org (Pearu Peterson) Date: Wed, 1 Feb 2006 09:34:44 -0600 (CST) Subject: [SciPy-dev] an atttempt at sandbox/xplt In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Arnd Baecker wrote: > gistC.so ends up in the right place now. > There is also a duplicate under > scipy/xplt/sandbox/scipy/sandbox/xplt/gistC.so > Not sure where this comes from/how to get rid off this. I don't have it. May was there from an old build. Try rm -rf build rm -rf path/to/installation/dir/of/xplt and re-install scipy. > Note that presently xplt is not yet working > (a few replaces from `scipy.xplt` to `scipy.sandbox.xplt` > have to be made). After this, the first error is > a typecode one. I will look into all this over the weekend. I have fixed xplt so that it imports, well, almost. The only remaining issue is with find_mask. It was defined in Numeric.arrayfns but I couldn't find an equivalent function from numpy. Travis? Pearu From arnd.baecker at web.de Wed Feb 1 12:09:26 2006 From: arnd.baecker at web.de (Arnd Baecker) Date: Wed, 1 Feb 2006 18:09:26 +0100 (CET) Subject: [SciPy-dev] an atttempt at sandbox/xplt In-Reply-To: References: Message-ID: On Wed, 1 Feb 2006, Pearu Peterson wrote: > On Wed, 1 Feb 2006, Arnd Baecker wrote: > > > gistC.so ends up in the right place now. > > There is also a duplicate under > > scipy/xplt/sandbox/scipy/sandbox/xplt/gistC.so > > Not sure where this comes from/how to get rid off this. > > I don't have it. May was there from an old build. > Try > rm -rf build > rm -rf path/to/installation/dir/of/xplt > and re-install scipy. Autsch - yes I forgot the first one ... > > Note that presently xplt is not yet working > > (a few replaces from `scipy.xplt` to `scipy.sandbox.xplt` > > have to be made). After this, the first error is > > a typecode one. I will look into all this over the weekend. > > I have fixed xplt so that it imports, well, almost. Great - you saved my weekend! ;-) > The only remaining > issue is with find_mask. It was defined in Numeric.arrayfns but I couldn't > find an equivalent function from numpy. Travis? This really sounds if xplt is close to working again - thanks a lot for your effort! Best, Arnd From oliphant.travis at ieee.org Wed Feb 1 12:25:38 2006 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Wed, 01 Feb 2006 10:25:38 -0700 Subject: [SciPy-dev] an atttempt at sandbox/xplt In-Reply-To: References: Message-ID: <43E0EF12.3030509@ieee.org> Arnd Baecker wrote: >On Wed, 1 Feb 2006, Pearu Peterson wrote: > > > The old arrayfns module is now inside the xplt distribution as gistfuncs. With this module, xplt now appears to be working. I installed it in it's own directory (by running python setup.py install from within xplt) and it appears to be working normally. -Travis From ndbecker2 at gmail.com Wed Feb 1 14:50:41 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 01 Feb 2006 14:50:41 -0500 Subject: [SciPy-dev] Found! - Why scipy-0.4.4 won't build on FC5 Message-ID: It looks like the problem is in numpy/distutils/fcompiler/gnu.py It's the version_pattern! Old f77: f77 --version GNU Fortran (GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-54.fc5)) 3.2.3 20030502 (Red Hat Linux 3.2.3-13) New gfortran: gfortran --version GNU Fortran 95 (GCC) 4.1.0 20060128 (Red Hat 4.1.0-0.17) Notice this doesn't match version_pattern: version_pattern = r'GNU Fortran 95 \(GCC (?P[^\s*\)]+)' Also, doesn't gnu.py need this? 'linker_so' : [fc_exe,"-shared", "-Wall"], (-shared was missing) From arnd.baecker at web.de Wed Feb 1 15:26:52 2006 From: arnd.baecker at web.de (Arnd Baecker) Date: Wed, 1 Feb 2006 21:26:52 +0100 (CET) Subject: [SciPy-dev] an atttempt at sandbox/xplt In-Reply-To: <43E0EF12.3030509@ieee.org> References: <43E0EF12.3030509@ieee.org> Message-ID: On Wed, 1 Feb 2006, Travis Oliphant wrote: > Arnd Baecker wrote: > > >On Wed, 1 Feb 2006, Pearu Peterson wrote: > > > The old arrayfns module is now inside the xplt distribution as > gistfuncs. With this module, xplt now appears to be working. > > I installed it in it's own directory (by running python setup.py install > from within xplt) and it appears to be working normally. I installed it "normally", and everything seems to work fine at a first glance. This will make our transition to numpy/new scipy much easier, as we don't have to port things to MPL at the same time (and not everything can be ported from xplt to MPL at the moment ...). *Many* thanks, Arnd From arnd.baecker at web.de Wed Feb 1 15:46:24 2006 From: arnd.baecker at web.de (Arnd Baecker) Date: Wed, 1 Feb 2006 21:46:24 +0100 (CET) Subject: [SciPy-dev] scipy.org Message-ID: Hi, I just tried to put my personal page into the homepage category. http://www.scipy.org/CategoryHomepage It seems to have worked, but http://www.scipy.org/ArndBaecker is using restructured text and this seems to be a bit incompatible with the text ---- CategoryHomepage which is added to support the Category. Presumably not worth any effort to correct this, but I wanted to mention it. I have also put my personal installation notes at http://www.scipy.org/ArndBaecker/InstallScipy (hope this is ok?). Feel free to reuse it at whatever place. Best, Arnd From cookedm at physics.mcmaster.ca Wed Feb 1 17:35:30 2006 From: cookedm at physics.mcmaster.ca (David M. Cooke) Date: Wed, 01 Feb 2006 17:35:30 -0500 Subject: [SciPy-dev] Changing return types in C API In-Reply-To: (ndarray@mac.com's message of "Tue, 31 Jan 2006 22:26:46 -0500") References: Message-ID: Sasha writes: > This probably belongs to numpy-discussion. More below. > > On 1/31/06, David M. Cooke wrote: >> ... >> Could we change the API so that PyArrayObject * is used as the return >> type? >> > > -1 > > Exposing the definition of the object structs is discouraged in python > code. See for example a comment in intobject.h /*The type PyIntObject > is (unfortunately) exposed here so we can declare _Py_TrueStruct and > _Py_ZeroStruct in boolobject.h; don't use this. */ In numpy this is > necessary for performance reasons so that accessors can be implemented > as macros. Making return types PyArrayObject * will likely lead > people to use direct access to struct members instead of macros. Well, I *already* use direct access :-). That's the way you do it with Numeric... But I'll concede your point: the preferred way should be PyArray_DATA and friends. I notice that CAPI.txt in numpy/doc just mentions the macros. Changing the data member of PyArrayObject to void* would make those easier to use. >> On a similar note: the 'data' member of PyArrayObject's is a char *, >> where it really should be a void *. Being a void pointer would have >> the advantage of not needing the cast in cases like this: >> >> double *adata = (double)(a->data); > > I think you meant (double*) Yep. >> It would also mean that accidentally dereferencing the pointer would >> be a compiler error: currently, a->data[0] is valid, but if a->data >> was a void *, it wouldn't be. >> > > +1 > > Note, however that implicit cast is illegal in C++ and may generate > warnings on some compilers (I think gcc -pedantic would, but not > sure). As long as it's fine in the headers, C++ can use the explicit cast. However, for C++ I'd suggest wrapping using templates. I've got something like this that I used for Numeric template struct PyArray_type_info { static PyArray_TYPES type() { return PyArray_NOTYPE; } static const char* name() { return "notype"; } } template <> struct PyArray_type_info { static PyArray_TYPES type() { return PyArray_DOUBLE } static const char* name() { return "double"; } } then, something like template struct ArrayObject { typedef PyArray_type_info type_info; PyObject *a; T* data() { return static_cast(PyArray_DATA(a)); } // Add strides, flags, [] and () operators, etc. } template ArrayObject contiguous_from_any(PyObject *obj, int min, int max) { PyObject *ao = PyArray_ContiguousFromAny(obj, PyArray_type_info.type(), min, max); ArrayObject a = {ao}; return a; } then your code becomes the simple ArrayObject a = contiguous_from_any(obj, 1, 1); double *d = ao.data(); Or something like that; this is untested code. But using template specialization like this could cut down a lot of casting, and make things safer in C++. Plus you could add refcount handling and all that :-) > Another problem with void* is that a->data + n will become > invalid, which is used in many places if I recall correctly. > (a->data + n code is actually suboptimal when n is not constant > because most CPUs have special opcodes for pointer arithmetics that > compilers can generate if n is compile time constant) I'll look for those. One trouble is the strides member of PyArrayObject; it's harder by a bit to apply a stride given in bytes to a double * (say). Although this is the same problem that you'd have after casting from the char* to the double *. -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm at physics.mcmaster.ca From paustin at eos.ubc.ca Wed Feb 1 18:13:20 2006 From: paustin at eos.ubc.ca (Philip Austin) Date: Wed, 1 Feb 2006 15:13:20 -0800 Subject: [SciPy-dev] Changing return types in C API In-Reply-To: References: Message-ID: <17377.16528.222966.57180@owl.eos.ubc.ca> David M. Cooke writes: > ArrayObject a = contiguous_from_any(obj, 1, 1); > double *d = ao.data(); > > Or something like that; this is untested code. But using template > specialization like this could cut down a lot of casting, and make > things safer in C++. Plus you could add refcount handling and all > that :-) On this topic: I've just about finished testing our boost:::python::numeric helper functions (http://www.eos.ubc.ca/research/clouds/num_util.html) with numpy. The only change required was a new free function to replace array.typecode(). Once I finish the cleanup and a couple of new examples I'll post the link to the topical software page with a short description. Regards, Phil From strawman at astraw.com Wed Feb 1 18:20:41 2006 From: strawman at astraw.com (Andrew Straw) Date: Wed, 01 Feb 2006 15:20:41 -0800 Subject: [SciPy-dev] scipy.org In-Reply-To: References: Message-ID: <43E14249.5050504@astraw.com> You could do (untested, but you get the idea): {{{#!format rst 99% of your content as RST here }}} ----- CategoryHomepage Arnd Baecker wrote: >Hi, > >I just tried to put my personal page into the homepage category. > http://www.scipy.org/CategoryHomepage >It seems to have worked, but > http://www.scipy.org/ArndBaecker >is using restructured text and this seems to be a bit >incompatible with the text > > ---- > CategoryHomepage > >which is added to support the Category. > >Presumably not worth any effort to correct this, but >I wanted to mention it. > >I have also put my personal installation notes at > http://www.scipy.org/ArndBaecker/InstallScipy >(hope this is ok?). Feel free to reuse it at whatever place. > >Best, Arnd > >_______________________________________________ >Scipy-dev mailing list >Scipy-dev at scipy.net >http://www.scipy.net/mailman/listinfo/scipy-dev > > From oliphant at ee.byu.edu Wed Feb 1 18:28:02 2006 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Wed, 01 Feb 2006 16:28:02 -0700 Subject: [SciPy-dev] Changing return types in C API In-Reply-To: References: Message-ID: <43E14402.3050504@ee.byu.edu> David M. Cooke wrote: >Sasha writes: > > >I'll look for those. One trouble is the strides member of >PyArrayObject; it's harder by a bit to apply a stride given in bytes >to a double * (say). Although this is the same problem that you'd have >after casting from the char* to the double *. > > This is the real trouble. The reason data is a char* is because strides is given in bytes. If we were to change the meaning of strides to "elements", this would break a lot of code that assumes it is given in bytes. Also, there is much more flexibility when strides can be given in terms of bytes. You can define a record with float, int16 elements, and now the float array can also be defined easily using strides. Of course it is a misaligned array, but that is the point of the ALIGNED flag... -Travis From cookedm at physics.mcmaster.ca Wed Feb 1 18:51:00 2006 From: cookedm at physics.mcmaster.ca (David M. Cooke) Date: Wed, 01 Feb 2006 18:51:00 -0500 Subject: [SciPy-dev] Changing return types in C API In-Reply-To: <43E14402.3050504@ee.byu.edu> (Travis Oliphant's message of "Wed, 01 Feb 2006 16:28:02 -0700") References: <43E14402.3050504@ee.byu.edu> Message-ID: Travis Oliphant writes: > David M. Cooke wrote: > >>Sasha writes: >> >> >>I'll look for those. One trouble is the strides member of >>PyArrayObject; it's harder by a bit to apply a stride given in bytes >>to a double * (say). Although this is the same problem that you'd have >>after casting from the char* to the double *. >> >> > > This is the real trouble. The reason data is a char* is because strides > is given in bytes. If we were to change the meaning of strides to > "elements", this would break a lot of code that assumes it is given in > bytes. > > Also, there is much more flexibility when strides can be given in terms > of bytes. You can define a record with > float, int16 elements, and now the float array can also be defined > easily using strides. Of course it is a misaligned array, but that is > the point of the ALIGNED flag... Hmm.. Ok, how about this? Change the definition of PyArray_DATA to #define PyArray_DATA(obj) ((void *)(((PyArrayObject *)(obj))->data)) (i.e., throw in an explicit void * cast). If you're assigning to a char *, this will still work for bytes. If you're dereferencing it, the compiler should throw an error. Also, introduce #define PyArray_BYTES(obj) (((PyArrayObject *)(obj))->data) when you actually want the byte-based version. -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm at physics.mcmaster.ca From oliphant at ee.byu.edu Wed Feb 1 18:57:08 2006 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Wed, 01 Feb 2006 16:57:08 -0700 Subject: [SciPy-dev] Changing return types in C API In-Reply-To: References: <43E14402.3050504@ee.byu.edu> Message-ID: <43E14AD4.3070806@ee.byu.edu> David M. Cooke wrote: >Ok, how about this? Change the definition of PyArray_DATA to > >#define PyArray_DATA(obj) ((void *)(((PyArrayObject *)(obj))->data)) > >(i.e., throw in an explicit void * cast). If you're assigning to a >char *, this will still work for bytes. If you're dereferencing it, >the compiler should throw an error. Also, introduce > >#define PyArray_BYTES(obj) (((PyArrayObject *)(obj))->data) > >when you actually want the byte-based version. > > Sounds great. -Travis From oliphant.travis at ieee.org Wed Feb 1 19:56:55 2006 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Wed, 01 Feb 2006 17:56:55 -0700 Subject: [SciPy-dev] an atttempt at sandbox/xplt In-Reply-To: References: <43E0EF12.3030509@ieee.org> Message-ID: Arnd Baecker wrote: > On Wed, 1 Feb 2006, Travis Oliphant wrote: > > >>Arnd Baecker wrote: >> >> >>>On Wed, 1 Feb 2006, Pearu Peterson wrote: >>> >> >>The old arrayfns module is now inside the xplt distribution as >>gistfuncs. With this module, xplt now appears to be working. >> >>I installed it in it's own directory (by running python setup.py install >>from within xplt) and it appears to be working normally. > > > I installed it "normally", and everything seems to work fine > at a first glance. > > This will make our transition to numpy/new scipy > much easier, as we don't have to port things to MPL at the same > time (and not everything can be ported from xplt to MPL > at the moment ...). > After a few more fixes, I can run the gistdemolow.py and gistdemohigh.py scripts through to completion. So, now we have xplt back for those who used it. It's not as pretty and/or flexible as matplotlib, but it sure is much faster... -Travis From nwagner at mecha.uni-stuttgart.de Thu Feb 2 03:54:16 2006 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Thu, 02 Feb 2006 09:54:16 +0100 Subject: [SciPy-dev] an atttempt at sandbox/xplt In-Reply-To: References: <43E0EF12.3030509@ieee.org> Message-ID: <43E1C8B8.3090503@mecha.uni-stuttgart.de> Travis Oliphant wrote: >Arnd Baecker wrote: > >>On Wed, 1 Feb 2006, Travis Oliphant wrote: >> >> >> >>>Arnd Baecker wrote: >>> >>> >>> >>>>On Wed, 1 Feb 2006, Pearu Peterson wrote: >>>> >>>> >>>The old arrayfns module is now inside the xplt distribution as >>>gistfuncs. With this module, xplt now appears to be working. >>> >>>I installed it in it's own directory (by running python setup.py install >>> >>>from within xplt) and it appears to be working normally. >> >> >>I installed it "normally", and everything seems to work fine >>at a first glance. >> >>This will make our transition to numpy/new scipy >>much easier, as we don't have to port things to MPL at the same >>time (and not everything can be ported from xplt to MPL >>at the moment ...). >> >> > >After a few more fixes, I can run the gistdemolow.py and gistdemohigh.py >scripts through to completion. > >So, now we have xplt back for those who used it. It's not as pretty >and/or flexible as matplotlib, but it sure is much faster... > >-Travis > >_______________________________________________ >Scipy-dev mailing list >Scipy-dev at scipy.net >http://www.scipy.net/mailman/listinfo/scipy-dev > Hi Travis, Do you have no reason for moving xplt into scipy/Lib/ ? You have mentioned the speed edge of xplt against matplotlib. This gives reason to have it directly available in scipy (at least for me). Nils From robert.kern at gmail.com Thu Feb 2 10:46:04 2006 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 02 Feb 2006 09:46:04 -0600 Subject: [SciPy-dev] an atttempt at sandbox/xplt In-Reply-To: <43E1C8B8.3090503@mecha.uni-stuttgart.de> References: <43E0EF12.3030509@ieee.org> <43E1C8B8.3090503@mecha.uni-stuttgart.de> Message-ID: <43E2293C.1070303@gmail.com> Nils Wagner wrote: > Do you have no reason for moving xplt into scipy/Lib/ ? > You have mentioned the speed edge of xplt against matplotlib. > This gives reason to have it directly available in scipy (at least for me). I'm sure there are reasons to want to move xplt back into scipy/Lib/. However, I think there are better reasons for keeping it out. xplot is X-only. It is not cross-platform. xplt can never be *the* plotting package, and if it is in scipy/Lib/, people will think it is. In the past, people have made scipy a dependency for their projects "only for the plotting". xplt was never intended to languish in the sandbox for this long. People volunteered to take over its development elsewhere as its own package. If you want xplt to be a living project, register the project on Sourceforge (or Berlios, or wherever) and move the code over. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From jonathan.taylor at utoronto.ca Thu Feb 2 14:36:27 2006 From: jonathan.taylor at utoronto.ca (Jonathan Taylor) Date: Thu, 2 Feb 2006 14:36:27 -0500 Subject: [SciPy-dev] an atttempt at sandbox/xplt In-Reply-To: <43E2293C.1070303@gmail.com> References: <43E0EF12.3030509@ieee.org> <43E1C8B8.3090503@mecha.uni-stuttgart.de> <43E2293C.1070303@gmail.com> Message-ID: <463e11f90602021136o29b98a83hbcf4e652f57ad71d@mail.gmail.com> I agree... there should really only be one plotting package in scipy or things will be confusing. Among matplotlibs other features, its similarity to matlab makes it the ideal choice since we are sort of positioning ourselves to lure past matlab users. J. On 2/2/06, Robert Kern wrote: > Nils Wagner wrote: > > > Do you have no reason for moving xplt into scipy/Lib/ ? > > You have mentioned the speed edge of xplt against matplotlib. > > This gives reason to have it directly available in scipy (at least for me). > > I'm sure there are reasons to want to move xplt back into scipy/Lib/. However, I > think there are better reasons for keeping it out. xplot is X-only. It is not > cross-platform. xplt can never be *the* plotting package, and if it is in > scipy/Lib/, people will think it is. In the past, people have made scipy a > dependency for their projects "only for the plotting". > > xplt was never intended to languish in the sandbox for this long. People > volunteered to take over its development elsewhere as its own package. If you > want xplt to be a living project, register the project on Sourceforge (or > Berlios, or wherever) and move the code over. > > -- > Robert Kern > robert.kern at gmail.com > > "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 oliphant.travis at ieee.org Thu Feb 2 15:33:14 2006 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Thu, 02 Feb 2006 13:33:14 -0700 Subject: [SciPy-dev] an atttempt at sandbox/xplt In-Reply-To: <43E2293C.1070303@gmail.com> References: <43E0EF12.3030509@ieee.org> <43E1C8B8.3090503@mecha.uni-stuttgart.de> <43E2293C.1070303@gmail.com> Message-ID: <43E26C8A.9020801@ieee.org> Robert Kern wrote: >Nils Wagner wrote: > > > >I'm sure there are reasons to want to move xplt back into scipy/Lib/. However, I >think there are better reasons for keeping it out. > I think the scipy library is best thought of as a toolbox of calculation routines. Some of the commands may produce plots as output, but the user will have to supply some plotting library that just conforms to a (yet-to-be?) established interface. While originally it was envisioned that something like matplotlib would grow inside of scipy itself, that's not what happened (and we are probably all better for it). However, xplt still fills a need not met yet by matplotlib (it's *very* fast comparitively and can do simple 3d surface plots). Thus it should have a home somewhere. I'm way too in love with SVN to use sourceforge for its home until sourceforge gets their SVN program out of beta. It should also be recognized that xplt is pygist + some fixes + python tools so in an ideal world pygist and xplt would just merge. I should clarify a mistaken notion that Robert has though. Despite its name, xplt *is cross-platform*. It works on Windows as well as X. There is partial support for Mac-OSX, as well. So, while I've never been in-love with xplt, it can still have a useful role to play. I actually don't mind if it stays in the sandbox, but I think releases should be made separately and not under the scipy namespace. -Travis From robert.kern at gmail.com Thu Feb 2 15:49:10 2006 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 02 Feb 2006 14:49:10 -0600 Subject: [SciPy-dev] an atttempt at sandbox/xplt In-Reply-To: <43E26C8A.9020801@ieee.org> References: <43E0EF12.3030509@ieee.org> <43E1C8B8.3090503@mecha.uni-stuttgart.de> <43E2293C.1070303@gmail.com> <43E26C8A.9020801@ieee.org> Message-ID: <43E27046.3070506@gmail.com> Travis Oliphant wrote: > However, xplt still fills a need not met yet by matplotlib (it's *very* > fast comparitively and can do simple 3d surface plots). Thus it should > have a home somewhere. I'm way too in love with SVN to use sourceforge > for its home until sourceforge gets their SVN program out of beta. There's always Berlios. http://developer.berlios.de/ > I should clarify a mistaken notion that Robert has though. Despite its > name, xplt *is cross-platform*. It works on Windows as well as X. > There is partial support for Mac-OSX, as well. So, while I've never > been in-love with xplt, it can still have a useful role to play. I > actually don't mind if it stays in the sandbox, but I think releases > should be made separately and not under the scipy namespace. Yes, I was mistaken. Sorry about that. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From gruben at bigpond.net.au Thu Feb 2 19:17:53 2006 From: gruben at bigpond.net.au (Gary Ruben) Date: Fri, 03 Feb 2006 11:17:53 +1100 Subject: [SciPy-dev] tidy up code before 1.0 Message-ID: <43E2A131.8070609@bigpond.net.au> Just a comment that I noticed the numpy source might benefit from being run through pychecker, which finds some unused references. I also noticed some TAB characters have found their way into the source. I didn't check the scipy source. PyLint might find different things too. And perhaps a run through with splint for the C source. Gary R. From Fernando.Perez at colorado.edu Thu Feb 2 19:26:11 2006 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Thu, 02 Feb 2006 17:26:11 -0700 Subject: [SciPy-dev] tidy up code before 1.0 In-Reply-To: <43E2A131.8070609@bigpond.net.au> References: <43E2A131.8070609@bigpond.net.au> Message-ID: <43E2A323.3030209@colorado.edu> Gary Ruben wrote: > Just a comment that I noticed the numpy source might benefit from being > run through pychecker, which finds some unused references. I also > noticed some TAB characters have found their way into the source. I > didn't check the scipy source. PyLint might find different things too. > And perhaps a run through with splint for the C source. +1. In particular, TABs should be absolutely forbidden: mixed tab/space code is a recipe for disaster in python (it's happened to me in the past with patches for ipython, and the resulting bugs can be maddening to track, as the code may actually appear correct on your screen depending on your particular choice of tab/space display settings). tabnanny.py and 'untabify.py -t 4', from /usr/lib/python2.X/Tools/scripts, are our friends here. Cheers, f PS - I'm not going into a tab-vs-spaces war here: the fact is that numpy is (as the python stdlib) mostly 4-space-indent code, so all contributed code should follow this standard, regardless of the contributor's personal preferences. This page has my basic ipython contributor guidelines: http://projects.scipy.org/ipython/ipython/wiki/DeveloperGuidelines Feel free to copy any of this you may like to the scipy dev wiki. From cookedm at physics.mcmaster.ca Thu Feb 2 20:01:36 2006 From: cookedm at physics.mcmaster.ca (David M. Cooke) Date: Thu, 02 Feb 2006 20:01:36 -0500 Subject: [SciPy-dev] tidy up code before 1.0 In-Reply-To: <43E2A131.8070609@bigpond.net.au> (Gary Ruben's message of "Fri, 03 Feb 2006 11:17:53 +1100") References: <43E2A131.8070609@bigpond.net.au> Message-ID: Gary Ruben writes: > Just a comment that I noticed the numpy source might benefit from being > run through pychecker, which finds some unused references. I also > noticed some TAB characters have found their way into the source. I > didn't check the scipy source. PyLint might find different things too. > And perhaps a run through with splint for the C source. > Gary R. I've been doing some of this as I go. Another tool that's handy is Pyflakes (http://divmod.org/projects/pyflakes) which works like PyLint, but doesn't worry about style. One trouble is the number of import * that are used, which tend to pull in a bunch of stuff not needed for the module. I've been working on reducing those too, with appropiate __all__'s. -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm at physics.mcmaster.ca From chris at trichech.us Thu Feb 2 21:37:43 2006 From: chris at trichech.us (Christopher Fonnesbeck) Date: Thu, 2 Feb 2006 21:37:43 -0500 Subject: [SciPy-dev] undefined symbol errors in scipy svn Message-ID: <756CD190-E42A-4209-BB9D-F19C00BC7630@trichech.us> I have been unable to build scipy from svn on OSX this week. I keep getting undefined symbol errors, but I am using the same compilers that I have always been using (gcc 3.3 and g77 3.4.4). Numpy builds fine. /usr/local/bin/g77 -L/usr/local/lib build/temp.darwin-8.4.0- Power_Macintosh-2.4/build/src/Lib/fftpack/_fftpackmodule.o build/ temp.darwin-8.4.0-Power_Macintosh-2.4/Lib/fftpack/src/zfft.o build/ temp.darwin-8.4.0-Power_Macintosh-2.4/Lib/fftpack/src/drfft.o build/ temp.darwin-8.4.0-Power_Macintosh-2.4/Lib/fftpack/src/zrfft.o build/ temp.darwin-8.4.0-Power_Macintosh-2.4/Lib/fftpack/src/zfftnd.o build/ temp.darwin-8.4.0-Power_Macintosh-2.4/build/src/fortranobject.o -L/ usr/local/lib -L/usr/local/lib/gcc/powerpc-apple-darwin7.9.0/3.4.4 - Lbuild/temp.darwin-8.4.0-Power_Macintosh-2.4 -ldfftpack -lfftw3 -lg2c -lcc_dynamic -o build/lib.darwin-8.4.0-Power_Macintosh-2.4/scipy/ fftpack/_fftpack.so -lSystemStubs /usr/bin/ld: Undefined symbols: _PyArg_ParseTupleAndKeywords _PyCObject_AsVoidPtr _PyCObject_Type _PyComplex_Type _PyDict_SetItemString _PyErr_Clear _PyErr_Format _PyErr_NewException _PyErr_Occurred _PyErr_SetString _PyExc_RuntimeError _PyImport_ImportModule _PyInt_Type _PyModule_GetDict _PyNumber_Int _PyObject_GetAttrString _PySequence_Check _PySequence_GetItem _PyString_FromString _PyString_Type _PyType_IsSubtype _PyType_Type _Py_BuildValue _Py_FatalError _Py_InitModule4 __Py_NoneStruct _PyCObject_FromVoidPtr _PyDict_DelItemString _PyDict_GetItemString _PyDict_New _PyExc_AttributeError _PyExc_TypeError _PyExc_ValueError _PyObject_Free _PyObject_Str _PyObject_Type _PyString_AsString _PyString_ConcatAndDel _Py_FindMethod __PyObject_New _MAIN__ collect2: ld returned 1 exit status /usr/bin/ld: Undefined symbols: _PyArg_ParseTupleAndKeywords _PyCObject_AsVoidPtr _PyCObject_Type _PyComplex_Type _PyDict_SetItemString _PyErr_Clear _PyErr_Format _PyErr_NewException _PyErr_Occurred _PyErr_SetString _PyExc_RuntimeError _PyImport_ImportModule _PyInt_Type _PyModule_GetDict _PyNumber_Int _PyObject_GetAttrString _PySequence_Check _PySequence_GetItem _PyString_FromString _PyString_Type _PyType_IsSubtype _PyType_Type _Py_BuildValue _Py_FatalError _Py_InitModule4 __Py_NoneStruct _PyCObject_FromVoidPtr _PyDict_DelItemString _PyDict_GetItemString _PyDict_New _PyExc_AttributeError _PyExc_TypeError _PyExc_ValueError _PyObject_Free _PyObject_Str _PyObject_Type _PyString_AsString _PyString_ConcatAndDel _Py_FindMethod __PyObject_New _MAIN__ collect2: ld returned 1 exit status error: Command "/usr/local/bin/g77 -L/usr/local/lib build/ temp.darwin-8.4.0-Power_Macintosh-2.4/build/src/Lib/fftpack/ _fftpackmodule.o build/temp.darwin-8.4.0-Power_Macintosh-2.4/Lib/ fftpack/src/zfft.o build/temp.darwin-8.4.0-Power_Macintosh-2.4/Lib/ fftpack/src/drfft.o build/temp.darwin-8.4.0-Power_Macintosh-2.4/Lib/ fftpack/src/zrfft.o build/temp.darwin-8.4.0-Power_Macintosh-2.4/Lib/ fftpack/src/zfftnd.o build/temp.darwin-8.4.0-Power_Macintosh-2.4/ build/src/fortranobject.o -L/usr/local/lib -L/usr/local/lib/gcc/ powerpc-apple-darwin7.9.0/3.4.4 -Lbuild/temp.darwin-8.4.0- Power_Macintosh-2.4 -ldfftpack -lfftw3 -lg2c -lcc_dynamic -o build/ lib.darwin-8.4.0-Power_Macintosh-2.4/scipy/fftpack/_fftpack.so - lSystemStubs" failed with exit status 1 -- Christopher J. Fonnesbeck Population Ecologist, Marine Mammal Section Fish & Wildlife Research Institute (FWC) St. Petersburg, FL Adjunct Assistant Professor Warnell School of Forest Resources University of Georgia Athens, GA T: 727.235.5570 E: chris at trichech.us -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2417 bytes Desc: not available URL: From chris at trichech.us Thu Feb 2 21:54:54 2006 From: chris at trichech.us (Christopher Fonnesbeck) Date: Thu, 2 Feb 2006 21:54:54 -0500 Subject: [SciPy-dev] plans for stats.py? Message-ID: <60C1FB46-1146-4A50-9CB2-13958212C41F@trichech.us> I have been trying to run some basic analyses in scipy.stats, but have had little success. A simple t-test using ttest_ind crashes: In [3]: ttest_ind([4,5,6,7,3,5,7],[7,9,5,3,4,2,6]) ------------------------------------------------------------------------ --- exceptions.TypeError Traceback (most recent call last) /Users/chris/ /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site- packages/scipy-0.4.5.1576-py2.4-macosx-10.4-ppc.egg/scipy/stats/ stats.py in ttest_ind(a=array([4, 5, 6, 7, 3, 5, 7]), b=array([7, 9, 5, 3, 4, 2, 6]), axis=0, printit=False, name1='Samp1', name2='Samp2', writemode='a') 1441 if type(t) == ArrayType: 1442 probs = reshape(probs,t.shape) -> 1443 if len(probs) == 1: global len = undefined probs = 0.89621601307466014 1444 probs = probs[0] 1445 TypeError: len() of unsized object I get a similar result with anova. Are there any plans in place to re-vamp this module? It is very poorly documented -- arguments are not described for many functions, for example. I am willing to begin a revision of this code, but did not want to step on any toes. Regards, C. -- Christopher J. Fonnesbeck Population Ecologist, Marine Mammal Section Fish & Wildlife Research Institute (FWC) St. Petersburg, FL Adjunct Assistant Professor Warnell School of Forest Resources University of Georgia Athens, GA T: 727.235.5570 E: chris at trichech.us -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2417 bytes Desc: not available URL: From chris at trichech.us Thu Feb 2 22:03:21 2006 From: chris at trichech.us (Christopher Fonnesbeck) Date: Thu, 2 Feb 2006 22:03:21 -0500 Subject: [SciPy-dev] plans for stats.py? In-Reply-To: <60C1FB46-1146-4A50-9CB2-13958212C41F@trichech.us> References: <60C1FB46-1146-4A50-9CB2-13958212C41F@trichech.us> Message-ID: <539D4D4D-B7B8-46E8-BD85-ADE4DC80E9D5@trichech.us> On Feb 2, 2006, at 9:54 PM, Christopher Fonnesbeck wrote: > It is very poorly documented -- arguments are not described for > many functions, for example. Actually, I take that back. It is pretty well documented, just inconsistent. Some functions are thoroughly documented, other not at all (e.g. lines 2584-2637). C. -- Christopher J. Fonnesbeck Population Ecologist, Marine Mammal Section Fish & Wildlife Research Institute (FWC) St. Petersburg, FL Adjunct Assistant Professor Warnell School of Forest Resources University of Georgia Athens, GA T: 727.235.5570 E: chris at trichech.us -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2417 bytes Desc: not available URL: From oliphant.travis at ieee.org Thu Feb 2 22:05:24 2006 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Thu, 02 Feb 2006 20:05:24 -0700 Subject: [SciPy-dev] plans for stats.py? In-Reply-To: <60C1FB46-1146-4A50-9CB2-13958212C41F@trichech.us> References: <60C1FB46-1146-4A50-9CB2-13958212C41F@trichech.us> Message-ID: <43E2C874.20501@ieee.org> Christopher Fonnesbeck wrote: > I have been trying to run some basic analyses in scipy.stats, but > have had little success. A simple t-test using ttest_ind crashes: > > In [3]: ttest_ind([4,5,6,7,3,5,7],[7,9,5,3,4,2,6]) > ------------------------------------------------------------------------ > --- > exceptions.TypeError Traceback (most > recent call last) > > /Users/chris/ > > /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site- > packages/scipy-0.4.5.1576-py2.4-macosx-10.4-ppc.egg/scipy/stats/ > stats.py in ttest_ind(a=array([4, 5, 6, 7, 3, 5, 7]), b=array([7, 9, > 5, 3, 4, 2, 6]), axis=0, printit=False, name1='Samp1', name2='Samp2', > writemode='a') > 1441 if type(t) == ArrayType: > 1442 probs = reshape(probs,t.shape) > -> 1443 if len(probs) == 1: > global len = undefined > probs = 0.89621601307466014 > 1444 probs = probs[0] > 1445 > > TypeError: len() of unsized object > > I get a similar result with anova. > > Are there any plans in place to re-vamp this module? It is very > poorly documented -- arguments are not described for many functions, > for example. I am willing to begin a revision of this code, but did > not want to step on any toes. > Don't worry about that. The stats module desperately needs some attention. Robert will probably have opinions on some of the functions, but most of them are adapted from Gary Stragman's original code. I suspect there are still "conversion" issues that have not been taken care of. This for example, looks like a problem when probs is a scalar. It should be recoded to probs.size == 1 -Travis From robert.kern at gmail.com Thu Feb 2 22:16:59 2006 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 02 Feb 2006 21:16:59 -0600 Subject: [SciPy-dev] undefined symbol errors in scipy svn In-Reply-To: <756CD190-E42A-4209-BB9D-F19C00BC7630@trichech.us> References: <756CD190-E42A-4209-BB9D-F19C00BC7630@trichech.us> Message-ID: <43E2CB2B.5030805@gmail.com> Christopher Fonnesbeck wrote: > I have been unable to build scipy from svn on OSX this week. I keep > getting undefined symbol errors, but I am using the same compilers that > I have always been using (gcc 3.3 and g77 3.4.4). Numpy builds fine. > > /usr/local/bin/g77 -L/usr/local/lib build/temp.darwin-8.4.0- > Power_Macintosh-2.4/build/src/Lib/fftpack/_fftpackmodule.o build/ > temp.darwin-8.4.0-Power_Macintosh-2.4/Lib/fftpack/src/zfft.o build/ > temp.darwin-8.4.0-Power_Macintosh-2.4/Lib/fftpack/src/drfft.o build/ > temp.darwin-8.4.0-Power_Macintosh-2.4/Lib/fftpack/src/zrfft.o build/ > temp.darwin-8.4.0-Power_Macintosh-2.4/Lib/fftpack/src/zfftnd.o build/ > temp.darwin-8.4.0-Power_Macintosh-2.4/build/src/fortranobject.o -L/ > usr/local/lib -L/usr/local/lib/gcc/powerpc-apple-darwin7.9.0/3.4.4 - > Lbuild/temp.darwin-8.4.0-Power_Macintosh-2.4 -ldfftpack -lfftw3 -lg2c > -lcc_dynamic -o build/lib.darwin-8.4.0-Power_Macintosh-2.4/scipy/ > fftpack/_fftpack.so -lSystemStubs > /usr/bin/ld: Undefined symbols: > _PyArg_ParseTupleAndKeywords > _PyCObject_AsVoidPtr I don't see this with the latest numpy and scipy. OS X 10.4, gcc 3.3, g77 3.4. The arguments you are missing are "-undefined dynamic_lookup -bundle". Look at line 67 of numpy/distutils/fcompiler/gnu.py for where it ought to be set. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From robert.kern at gmail.com Thu Feb 2 22:20:14 2006 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 02 Feb 2006 21:20:14 -0600 Subject: [SciPy-dev] plans for stats.py? In-Reply-To: <43E2C874.20501@ieee.org> References: <60C1FB46-1146-4A50-9CB2-13958212C41F@trichech.us> <43E2C874.20501@ieee.org> Message-ID: <43E2CBEE.90901@gmail.com> Travis Oliphant wrote: > Don't worry about that. The stats module desperately needs some > attention. Robert will probably have opinions on some of the > functions, but most of them are adapted from Gary Stragman's original > code. I have opinions on just about everything. But the important one here is "If it doesn't work with reasonable inputs, and you can't figure out how to fix it, toss it somewhere in the sandbox with some notes about what you learned, what arguments failed, what you think it ought to be doing." If people complain, then they should know how to properly document it or fix it. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From chris at trichech.us Fri Feb 3 07:51:26 2006 From: chris at trichech.us (Christopher Fonnesbeck) Date: Fri, 3 Feb 2006 07:51:26 -0500 Subject: [SciPy-dev] plans for stats.py? In-Reply-To: <43E2CBEE.90901@gmail.com> References: <60C1FB46-1146-4A50-9CB2-13958212C41F@trichech.us> <43E2C874.20501@ieee.org> <43E2CBEE.90901@gmail.com> Message-ID: On Feb 2, 2006, at 10:20 PM, Robert Kern wrote: > If people complain, then > they should know how to properly document it or fix it. OK, since I complained, I will try to fix it. Rather than tinker with the extant code, however, I will work from scratch. By the way, I notice lots .lyx code in certain modules in scipy. Is this a "scipy standard" for documentation? If so, I am wondering why lyx rather than just plain LaTeX? C. -- Christopher J. Fonnesbeck Population Ecologist, Marine Mammal Section Fish & Wildlife Research Institute (FWC) St. Petersburg, FL Adjunct Assistant Professor Warnell School of Forest Resources University of Georgia Athens, GA T: 727.235.5570 E: chris at trichech.us -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2417 bytes Desc: not available URL: From aisaac at american.edu Fri Feb 3 10:51:16 2006 From: aisaac at american.edu (Alan G Isaac) Date: Fri, 3 Feb 2006 10:51:16 -0500 Subject: [SciPy-dev] plans for stats.py? In-Reply-To: References: <60C1FB46-1146-4A50-9CB2-13958212C41F@trichech.us><43E2C874.20501@ieee.org> <43E2CBEE.90901@gmail.com> Message-ID: On Fri, 3 Feb 2006, Christopher Fonnesbeck apparently wrote: > By the way, I notice lots .lyx code in certain modules in > scipy. Is this a "scipy standard" for documentation? If > so, I am wondering why lyx rather than just plain LaTeX? Yes. And ideally as supported by reST: http://svn.berlios.de/viewcvs/docutils/trunk/sandbox/jensj/latex_math/ Cheers, Alan Isaac From chris at trichech.us Fri Feb 3 11:13:26 2006 From: chris at trichech.us (Christopher Fonnesbeck) Date: Fri, 3 Feb 2006 11:13:26 -0500 Subject: [SciPy-dev] undefined symbol errors in scipy svn In-Reply-To: <43E2CB2B.5030805@gmail.com> References: <756CD190-E42A-4209-BB9D-F19C00BC7630@trichech.us> <43E2CB2B.5030805@gmail.com> Message-ID: On Feb 2, 2006, at 10:16 PM, Robert Kern wrote: > I don't see this with the latest numpy and scipy. OS X 10.4, gcc > 3.3, g77 3.4. > The arguments you are missing are "-undefined dynamic_lookup - > bundle". Look at > line 67 of numpy/distutils/fcompiler/gnu.py for where it ought to > be set. Thanks Robert, It seems the problem came when I was trying to do a static build (I assume I am doing this right): LDFLAGS=-L/usr/local/lib python setup.py build If I remove the LDFLAGS variable from the call, it builds fine. C. -- Christopher J. Fonnesbeck Population Ecologist, Marine Mammal Section Fish & Wildlife Research Institute (FWC) St. Petersburg, FL Adjunct Assistant Professor Warnell School of Forest Resources University of Georgia Athens, GA T: 727.235.5570 E: chris at trichech.us -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2417 bytes Desc: not available URL: From charlesr.harris at gmail.com Fri Feb 3 12:04:04 2006 From: charlesr.harris at gmail.com (Charles R Harris) Date: Fri, 3 Feb 2006 10:04:04 -0700 Subject: [SciPy-dev] tidy up code before 1.0 In-Reply-To: <43E2A323.3030209@colorado.edu> References: <43E2A131.8070609@bigpond.net.au> <43E2A323.3030209@colorado.edu> Message-ID: On 2/2/06, Fernando Perez wrote: > > [snip] > +1. In particular, TABs should be absolutely forbidden: mixed tab/space > code > is a recipe for disaster in python (it's happened to me in the past with > patches for ipython, and the resulting bugs can be maddening to track, as > the > code may actually appear correct on your screen depending on your > particular > choice of tab/space display settings). In vim I set tabs and soft tabs to different values (8 and 4) so that the true tabs show up and can be removed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Fernando.Perez at colorado.edu Fri Feb 3 12:08:35 2006 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Fri, 03 Feb 2006 10:08:35 -0700 Subject: [SciPy-dev] tidy up code before 1.0 In-Reply-To: References: <43E2A131.8070609@bigpond.net.au> <43E2A323.3030209@colorado.edu> Message-ID: <43E38E13.5050000@colorado.edu> Charles R Harris wrote: > On 2/2/06, Fernando Perez wrote: > >>[snip] >>+1. In particular, TABs should be absolutely forbidden: mixed tab/space >>code >>is a recipe for disaster in python (it's happened to me in the past with >>patches for ipython, and the resulting bugs can be maddening to track, as >>the >>code may actually appear correct on your screen depending on your >>particular >>choice of tab/space display settings). > > > > In vim I set tabs and soft tabs to different values (8 and 4) so that the > true tabs show up and can be removed. Well, it's still possible to be visually tripped even with this safeguard in place: if foo: if bar: baz bang Where does bang go? It looks like it goes below bar, but it's meant to be only indented one level. If the logic of the code isn't obvious enough, something like this can _very easily_ go unnoticed. It's happened to me in the past, and it has caused me hours of bug hunting. From past experience, mixed tabs/spaces in python are just a bad idea. IMO, they should raise a syntax error, period. Cheers, f From robert.kern at gmail.com Fri Feb 3 12:13:51 2006 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 03 Feb 2006 11:13:51 -0600 Subject: [SciPy-dev] plans for stats.py? In-Reply-To: References: <60C1FB46-1146-4A50-9CB2-13958212C41F@trichech.us> <43E2C874.20501@ieee.org> <43E2CBEE.90901@gmail.com> Message-ID: <43E38F4F.2000505@gmail.com> Christopher Fonnesbeck wrote: > On Feb 2, 2006, at 10:20 PM, Robert Kern wrote: > >> If people complain, then >> they should know how to properly document it or fix it. > > OK, since I complained, I will try to fix it. Rather than tinker with > the extant code, however, I will work from scratch. That's fine, and thank you! But what I meant was "If people complain about the function being moved out of the main package into the sandbox, ...". Presumably, if their code breaks because a function moves, then they know what the function does and is supposed to be doing. > By the way, I notice lots .lyx code in certain modules in scipy. Is > this a "scipy standard" for documentation? If so, I am wondering why > lyx rather than just plain LaTeX? Because Travis O. likes it, and he was the one writing those particular docs. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From robert.kern at gmail.com Fri Feb 3 12:19:09 2006 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 03 Feb 2006 11:19:09 -0600 Subject: [SciPy-dev] undefined symbol errors in scipy svn In-Reply-To: References: <756CD190-E42A-4209-BB9D-F19C00BC7630@trichech.us> <43E2CB2B.5030805@gmail.com> Message-ID: <43E3908D.8000109@gmail.com> Christopher Fonnesbeck wrote: > On Feb 2, 2006, at 10:16 PM, Robert Kern wrote: > >> I don't see this with the latest numpy and scipy. OS X 10.4, gcc 3.3, >> g77 3.4. >> The arguments you are missing are "-undefined dynamic_lookup - >> bundle". Look at >> line 67 of numpy/distutils/fcompiler/gnu.py for where it ought to be >> set. > > Thanks Robert, > > It seems the problem came when I was trying to do a static build (I > assume I am doing this right): > > LDFLAGS=-L/usr/local/lib python setup.py build > > If I remove the LDFLAGS variable from the call, it builds fine. That's probably a bug in numpy.distutils, and probably the part that I wrote for OS X support. I'll look into it. Note that you can add link flags like this directly to build_ext: python setup.py build_ext --library-dirs=/usr/local/lib:/some/other/lib build Hopefully, that's not going to interfere with any other settings. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From oliphant.travis at ieee.org Fri Feb 3 13:03:36 2006 From: oliphant.travis at ieee.org (Travis E. Oliphant) Date: Fri, 03 Feb 2006 11:03:36 -0700 Subject: [SciPy-dev] plans for stats.py? In-Reply-To: References: <60C1FB46-1146-4A50-9CB2-13958212C41F@trichech.us> <43E2C874.20501@ieee.org> <43E2CBEE.90901@gmail.com> Message-ID: Christopher Fonnesbeck wrote: > On Feb 2, 2006, at 10:20 PM, Robert Kern wrote: > >> If people complain, then >> they should know how to properly document it or fix it. > > > OK, since I complained, I will try to fix it. Rather than tinker with > the extant code, however, I will work from scratch. > > By the way, I notice lots .lyx code in certain modules in scipy. Is > this a "scipy standard" for documentation? If so, I am wondering why > lyx rather than just plain LaTeX? Which modules are these? There are .lyx files in the distribution, but there shouldn't be .lyx "code" in the modules themselves as far as I know. The .lyx files in the directories are there for documentation. And yes, Lyx is a standard for SciPy Documentation. The reason is that there are LyX editors that make it easier to write LyX files then pure LaTeX. These viewers are available for popular platforms. See http://www.lyx.org. -Travis From aisaac at american.edu Fri Feb 3 18:01:11 2006 From: aisaac at american.edu (Alan G Isaac) Date: Fri, 3 Feb 2006 18:01:11 -0500 Subject: [SciPy-dev] plans for stats.py? In-Reply-To: References: <60C1FB46-1146-4A50-9CB2-13958212C41F@trichech.us><43E2C874.20501@ieee.org> <43E2CBEE.90901@gmail.com> Message-ID: On Fri, 03 Feb 2006, "Travis E. Oliphant" apparently wrote: > The reason is that there are LyX editors that make it > easier to write LyX files then pure LaTeX. LyX allows LaTeX export. Alan Isaac PS I am not arguing for a change in practice, just making sure the information is known. From jonathan.taylor at utoronto.ca Mon Feb 6 02:28:20 2006 From: jonathan.taylor at utoronto.ca (Jonathan Taylor) Date: Mon, 6 Feb 2006 02:28:20 -0500 Subject: [SciPy-dev] Fwd: SciPy/NumPy website In-Reply-To: <1139209974.27924.253623276@webmail.messagingengine.com> References: <1139209974.27924.253623276@webmail.messagingengine.com> Message-ID: <463e11f90602052328u1e9549adg6dd2e8aea9a8ee8b@mail.gmail.com> I got this email a bit ago. Kevin raises some good points... especially changing wikipedia. I am not sure about forums though. I think we might need more users before thats useful. What do you guys think? Jon. ---------- Forwarded message ---------- From: Kevin Christman Date: Feb 6, 2006 2:12 AM Subject: SciPy/NumPy website To: jonathan.taylor at utoronto.ca I noticed that you're part of the SciPy website team. 2 notes: 1. With all the great changes happening on scipy.org, maybe Wikipedia's entry for SciPy and NumPy need an update. 2. Also, are there any plans for hosting some forums, especially for newbie help on the website? The Mailing lists might work fine for development, but I think that an open forum where people can give and get code advice could be useful. Keep up the great work! I'm using it (and matplotlib) instead of Matlab for an engineering project. Thanks, Kevin Christman chrike at wwc.edu From strawman at astraw.com Mon Feb 6 12:14:02 2006 From: strawman at astraw.com (Andrew Straw) Date: Mon, 06 Feb 2006 09:14:02 -0800 Subject: [SciPy-dev] Matplotlib, scipy? In-Reply-To: <1e2af89e0602050343i79b33f9cqc22d34979901b77d@mail.gmail.com> References: <1e2af89e0601290430r1ce9a5fbt7b54a87eca7d3cc6@mail.gmail.com> <43DCFB31.6060704@astraw.com> <1e2af89e0602050343i79b33f9cqc22d34979901b77d@mail.gmail.com> Message-ID: <43E783DA.6020702@astraw.com> Hi Matthew, (I'm moving this thread back onto a public list. It's scipy-dev now because most of the scipy.org website discussion happens here.) Matthew Brett wrote: >Hi, > >I was just emailing Travis about the Installation pages on the Wiki. >I was wondering if it would be worthwhile to reorganize the >installation information a bit, as at the moment it seems rather >scattered across the FAQ, installation pages, and various recipes for >different platforms. > Yes, this is because to get the wiki going as quickly as possible I basically tried importing information from old sources with as little modification as possible. I didn't spend as much time on re-organization as I would have liked. I agree that it's problematic to have an installation instructions (not questions) in the FAQ and also in an installation page. >Also I noticed that there is no seperable >installation guide for NumPy and SciPy. > > Good point. This is surely because of the scipy_core phase of numpy's existance. It should be a fairly high priority to more clearly delineate these bits of information. >I would be very happy to help reorganize this if there was interest. > > We would be very happy for you to help reorganize. :) There is interest! >Specifically, I would want to take the installation stuff out of the >FAQ, and have something like this: > >Installing numpy - requirements, binary installation, building >Installing scipy - requirements (including numpy), binary installation, building > >Building NumPy - requirements, optional, optimization, advanced >compilation options >ditto SciPy > >From these pages; >Setting up C compiler for windows, linux, mac etc >Setting up fortran compiler for etc >Optimized BLAS/LAPACK libraries > >etc, > >Does this sound sensible to you? I am hesitant to go ahead on a >change that big without some consensus... > > I think the consensus is that we're very into review-by-wiki. I don't think anyone considers the website structure crystallized (or even particularly great, just better than it was before), so please feel free to streamline it as you see fit. I only ask that any pages you decide to delete or move be replaced with a new page containing #redirect NewPageLocation For those who don't know, the RecentChanges page on the website lets you see all recent page modifications. Cheers! Andrew From ashuang at gmail.com Mon Feb 6 17:46:15 2006 From: ashuang at gmail.com (Albert Huang) Date: Mon, 6 Feb 2006 17:46:15 -0500 Subject: [SciPy-dev] signal.signaltools.py missing import numpy.exp Message-ID: signal.signaltools.gaussian and signal.signaltools.general_gaussian depend on numpy.exp, which is not currently imported. The attached patch fixes this. Regards, Albert -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: signaltools-import-exp.patch.txt URL: From charlesr.harris at gmail.com Thu Feb 9 13:05:09 2006 From: charlesr.harris at gmail.com (Charles R Harris) Date: Thu, 9 Feb 2006 11:05:09 -0700 Subject: [SciPy-dev] Bugs? Message-ID: Hi, Running latest numpy from cvs I get things like: >>> arange(25) array([-1214459252, -1214447606, -1214446384, -1214019752, -1212353482, 0, 0, 0, 0, 0, 0, 0, 1, 2, 4, 105, 10000, 9898072, 166961568, 167979252, 167979252, 168017420, 690120039, 1029992041, 1919249698]) And >>> a = arange(25) >>> a.sort(kind='merge') Traceback (most recent call last): File "", line 1, in ? TypeError: desired sort not supported for this type The other sorts, 'heap' and 'quick', work fine. Any thoughts? Numpy was compiled with gcc version 3.4.4 20050721 (Red Hat 3.4.4-2) and the OS is 32 bit fc3 running on an athlon64. Chuck From robert.kern at gmail.com Thu Feb 9 13:15:59 2006 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 09 Feb 2006 12:15:59 -0600 Subject: [SciPy-dev] Bugs? In-Reply-To: References: Message-ID: <43EB86DF.7020600@gmail.com> Charles R Harris wrote: > Hi, > > Running latest numpy from cvs I get things like: > > >>>>arange(25) > > array([-1214459252, -1214447606, -1214446384, -1214019752, -1212353482, > 0, 0, 0, 0, 0, > 0, 0, 1, 2, 4, > 105, 10000, 9898072, 166961568, 167979252, > 167979252, 168017420, 690120039, 1029992041, 1919249698]) > > And > > >>>>a = arange(25) >>>>a.sort(kind='merge') > > Traceback (most recent call last): > File "", line 1, in ? > TypeError: desired sort not supported for this type > > The other sorts, 'heap' and 'quick', work fine. Any thoughts? Revision 2085 works fine for me on OS X. Did you "rm -r ./build/" before building? Some parts deep inside the C code changed recently. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From charlesr.harris at gmail.com Thu Feb 9 13:31:09 2006 From: charlesr.harris at gmail.com (Charles R Harris) Date: Thu, 9 Feb 2006 11:31:09 -0700 Subject: [SciPy-dev] Bugs? In-Reply-To: <43EB86DF.7020600@gmail.com> References: <43EB86DF.7020600@gmail.com> Message-ID: OK, Removing the build directory fixed things up. Why isn't this part of the normal build? A nit here, the cflags are: '-pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -m32 -march=i386 -mtune=pentium4 -D_GNU_SOURCE -fPIC -mcpu=athlon64 -fomit-frame-pointers -ffast-math -fno-strict-aliasing -fPIC' With -mcpu=athlon64 the flags -march=i386 -mtune=pentium4 are unnecessary and possibly counterproductive, at least for recent compiler versions. The cpu flag alone sets both the instruction set and tuning for the athlon. On 2/9/06, Robert Kern wrote: > Charles R Harris wrote: > > Hi, > > > > Running latest numpy from cvs I get things like: > > > > > >>>>arange(25) > > > > array([-1214459252, -1214447606, -1214446384, -1214019752, -1212353482, > > 0, 0, 0, 0, 0, > > 0, 0, 1, 2, 4, > > 105, 10000, 9898072, 166961568, 167979252, > > 167979252, 168017420, 690120039, 1029992041, 1919249698]) > > > > And > > > > > >>>>a = arange(25) > >>>>a.sort(kind='merge') > > > > Traceback (most recent call last): > > File "", line 1, in ? > > TypeError: desired sort not supported for this type > > > > The other sorts, 'heap' and 'quick', work fine. Any thoughts? > > Revision 2085 works fine for me on OS X. Did you "rm -r ./build/" before > building? Some parts deep inside the C code changed recently. > > -- > Robert Kern > robert.kern at gmail.com > > "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 charlesr.harris at gmail.com Thu Feb 9 13:58:38 2006 From: charlesr.harris at gmail.com (Charles R Harris) Date: Thu, 9 Feb 2006 11:58:38 -0700 Subject: [SciPy-dev] Bugs? In-Reply-To: References: <43EB86DF.7020600@gmail.com> Message-ID: Correction, The documentation for gcc3.4 says -march=cpu-type Generate instructions for the machine type cpu-type. The choices for cpu-type are the same as for -mtune. Moreover, specifying -march=cpu-type implies -mtune=cpu-type. -mcpu=cpu-type A deprecated synonym for -mtune. So it looks like the flags should just be -march=athlon64. I sympathize with anyone trying to set up the correct gcc flags. It gives me a headache trying to keep track of all the gcc options. Chuck On 2/9/06, Charles R Harris wrote: > OK, > > Removing the build directory fixed things up. Why isn't this part of > the normal build? > > A nit here, the cflags are: > > '-pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -m32 -march=i386 > -mtune=pentium4 -D_GNU_SOURCE -fPIC -mcpu=athlon64 > -fomit-frame-pointers -ffast-math -fno-strict-aliasing -fPIC' > > With -mcpu=athlon64 the flags -march=i386 -mtune=pentium4 are > unnecessary and possibly counterproductive, at least for recent > compiler versions. The cpu flag alone sets both the instruction set > and tuning for the athlon. > > On 2/9/06, Robert Kern wrote: > > Charles R Harris wrote: > > > Hi, > > > > > > Running latest numpy from cvs I get things like: > > > > > > > > >>>>arange(25) > > > > > > array([-1214459252, -1214447606, -1214446384, -1214019752, -1212353482, > > > 0, 0, 0, 0, 0, > > > 0, 0, 1, 2, 4, > > > 105, 10000, 9898072, 166961568, 167979252, > > > 167979252, 168017420, 690120039, 1029992041, 1919249698]) > > > > > > And > > > > > > > > >>>>a = arange(25) > > >>>>a.sort(kind='merge') > > > > > > Traceback (most recent call last): > > > File "", line 1, in ? > > > TypeError: desired sort not supported for this type > > > > > > The other sorts, 'heap' and 'quick', work fine. Any thoughts? > > > > Revision 2085 works fine for me on OS X. Did you "rm -r ./build/" before > > building? Some parts deep inside the C code changed recently. > > > > -- > > Robert Kern > > robert.kern at gmail.com > > > > "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 robert.kern at gmail.com Thu Feb 9 14:00:32 2006 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 09 Feb 2006 13:00:32 -0600 Subject: [SciPy-dev] Bugs? In-Reply-To: References: <43EB86DF.7020600@gmail.com> Message-ID: <43EB9150.7030603@gmail.com> Charles R Harris wrote: > OK, > > Removing the build directory fixed things up. Why isn't this part of > the normal build? It's only necessary when someone makes relatively large changes to certain parts of the C code. Our particular combination of extension modules importing other extension modules isn't handled by distutils' simple dependency calculations. Wiping out ./build/ is only a good thing when those parts of the C code change. Otherwise, it's a nuisance. OTOH, if you do want to clean out the build directory every time, then just do something like this (in a script or from memory or whatever you like): $ python setup.py clean build_src build_clib build_ext build -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From charlesr.harris at gmail.com Thu Feb 9 14:06:02 2006 From: charlesr.harris at gmail.com (Charles R Harris) Date: Thu, 9 Feb 2006 12:06:02 -0700 Subject: [SciPy-dev] Bugs? In-Reply-To: <43EB9150.7030603@gmail.com> References: <43EB86DF.7020600@gmail.com> <43EB9150.7030603@gmail.com> Message-ID: On 2/9/06, Robert Kern wrote: > Charles R Harris wrote: > > OK, > > > > Removing the build directory fixed things up. Why isn't this part of > > the normal build? > > It's only necessary when someone makes relatively large changes to certain parts > of the C code. Our particular combination of extension modules importing other > extension modules isn't handled by distutils' simple dependency calculations. > > Wiping out ./build/ is only a good thing when those parts of the C code change. > Otherwise, it's a nuisance. OTOH, if you do want to clean out the build > directory every time, then just do something like this (in a script or from > memory or whatever you like): > > $ python setup.py clean build_src build_clib build_ext build Thanks Robert. Building from scratch goes fast enough that I think I'll just nuke the build directory every time to avoid any potential problems. Chuck From jh at oobleck.astro.cornell.edu Thu Feb 9 14:13:30 2006 From: jh at oobleck.astro.cornell.edu (Joe Harrington) Date: Thu, 9 Feb 2006 14:13:30 -0500 Subject: [SciPy-dev] Fwd: SciPy/NumPy website In-Reply-To: (scipy-dev-request@scipy.net) References: Message-ID: <200602091913.k19JDUhI020540@oobleck.astro.cornell.edu> Agree on Wikipedia. I added Gmane links on the Mailing Lists page, and some explanatory text. Are there any forum features Gmane doesn't have? Do we need an open list that anyone can post to? --jh-- From robert.kern at gmail.com Thu Feb 9 14:24:48 2006 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 09 Feb 2006 13:24:48 -0600 Subject: [SciPy-dev] Fwd: SciPy/NumPy website In-Reply-To: <200602091913.k19JDUhI020540@oobleck.astro.cornell.edu> References: <200602091913.k19JDUhI020540@oobleck.astro.cornell.edu> Message-ID: <43EB9700.10107@gmail.com> Joe Harrington wrote: > Agree on Wikipedia. > > I added Gmane links on the Mailing Lists page, and some explanatory > text. Are there any forum features Gmane doesn't have? Do we need an > open list that anyone can post to? We've done that before and got spammed into submission, IIRC. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From jh at oobleck.astro.cornell.edu Thu Feb 9 14:30:47 2006 From: jh at oobleck.astro.cornell.edu (Joe Harrington) Date: Thu, 9 Feb 2006 14:30:47 -0500 Subject: [SciPy-dev] Fwd: SciPy/NumPy website In-Reply-To: <43EB9700.10107@gmail.com> (message from Robert Kern on Thu, 09 Feb 2006 13:24:48 -0600) References: <200602091913.k19JDUhI020540@oobleck.astro.cornell.edu> <43EB9700.10107@gmail.com> Message-ID: <200602091930.k19JUlmf020683@oobleck.astro.cornell.edu> >> I added Gmane links on the Mailing Lists page, and some explanatory >> text. Are there any forum features Gmane doesn't have? Do we need an >> open list that anyone can post to? >We've done that before and got spammed into submission, IIRC. The lists are/have been on gmane for a while. I didn't put them there, and we don't get much spam on the lists now. How would our linking to the existing gmane pages increase spam? Gmane has anti-spam measures that they claim are good enough, and that they will improve if they are not. --jh-- From robert.kern at gmail.com Thu Feb 9 14:34:02 2006 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 09 Feb 2006 13:34:02 -0600 Subject: [SciPy-dev] Fwd: SciPy/NumPy website In-Reply-To: <200602091930.k19JUlmf020683@oobleck.astro.cornell.edu> References: <200602091913.k19JDUhI020540@oobleck.astro.cornell.edu> <43EB9700.10107@gmail.com> <200602091930.k19JUlmf020683@oobleck.astro.cornell.edu> Message-ID: <43EB992A.8090706@gmail.com> Joe Harrington wrote: >>>I added Gmane links on the Mailing Lists page, and some explanatory >>>text. Are there any forum features Gmane doesn't have? Do we need an >>>open list that anyone can post to? > >>We've done that before and got spammed into submission, IIRC. > > The lists are/have been on gmane for a while. I didn't put them > there, and we don't get much spam on the lists now. How would our > linking to the existing gmane pages increase spam? Gmane has > anti-spam measures that they claim are good enough, and that they will > improve if they are not. Sorry, I meant allowing posting to the list for non-subscribers. IIRC, we now require people to subscribe before posting because of the spam. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From jh at oobleck.astro.cornell.edu Thu Feb 9 14:52:50 2006 From: jh at oobleck.astro.cornell.edu (Joe Harrington) Date: Thu, 9 Feb 2006 14:52:50 -0500 Subject: [SciPy-dev] Fwd: SciPy/NumPy website In-Reply-To: <43EB992A.8090706@gmail.com> (message from Robert Kern on Thu, 09 Feb 2006 13:34:02 -0600) References: <200602091913.k19JDUhI020540@oobleck.astro.cornell.edu> <43EB9700.10107@gmail.com> <200602091930.k19JUlmf020683@oobleck.astro.cornell.edu> <43EB992A.8090706@gmail.com> Message-ID: <200602091952.k19Jqoml020764@oobleck.astro.cornell.edu> >>>>I added Gmane links on the Mailing Lists page, and some explanatory >>>>text. Are there any forum features Gmane doesn't have? Do we need an >>>>open list that anyone can post to? >> >>>We've done that before and got spammed into submission, IIRC. >> >> The lists are/have been on gmane for a while. I didn't put them >> there, and we don't get much spam on the lists now. How would our >> linking to the existing gmane pages increase spam? Gmane has >> anti-spam measures that they claim are good enough, and that they will >> improve if they are not. >Sorry, I meant allowing posting to the list for non-subscribers. IIRC, we now >require people to subscribe before posting because of the spam. Ah, understand. It may work to allow anonymous posting to a forum list made for that purpose, through an interface like gmane that has good input spam filtering. I don't know much about those interfaces, though. Let's not, for now, unless we hear more from the users that it's wanted. --jh-- From Fernando.Perez at colorado.edu Thu Feb 9 16:09:21 2006 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Thu, 09 Feb 2006 14:09:21 -0700 Subject: [SciPy-dev] Fwd: SciPy/NumPy website In-Reply-To: <200602091952.k19Jqoml020764@oobleck.astro.cornell.edu> References: <200602091913.k19JDUhI020540@oobleck.astro.cornell.edu> <43EB9700.10107@gmail.com> <200602091930.k19JUlmf020683@oobleck.astro.cornell.edu> <43EB992A.8090706@gmail.com> <200602091952.k19Jqoml020764@oobleck.astro.cornell.edu> Message-ID: <43EBAF81.80006@colorado.edu> Joe Harrington wrote: >>>>>I added Gmane links on the Mailing Lists page, and some explanatory >>>>>text. Are there any forum features Gmane doesn't have? Do we need an >>>>>open list that anyone can post to? >>> >>>>We've done that before and got spammed into submission, IIRC. >>> >>>The lists are/have been on gmane for a while. I didn't put them >>>there, and we don't get much spam on the lists now. How would our >>>linking to the existing gmane pages increase spam? Gmane has >>>anti-spam measures that they claim are good enough, and that they will >>>improve if they are not. > > >>Sorry, I meant allowing posting to the list for non-subscribers. IIRC, we now >>require people to subscribe before posting because of the spam. > > > Ah, understand. It may work to allow anonymous posting to a forum > list made for that purpose, through an interface like gmane that has > good input spam filtering. I don't know much about those interfaces, > though. Let's not, for now, unless we hear more from the users that > it's wanted. No need. The verification via gmane is so easy that there's no need to change anything. Non subscribers, the first time they post via gmane, will need to authenticate themselves _to gmane_, via an email. Once they do that, it's smooth sailing. In summary: don't change anything. What we have keeps open spamming under control, and doesn't place an undue burden on posters. Cheers, f From jh at oobleck.astro.cornell.edu Thu Feb 9 16:25:03 2006 From: jh at oobleck.astro.cornell.edu (Joe Harrington) Date: Thu, 9 Feb 2006 16:25:03 -0500 Subject: [SciPy-dev] Fwd: SciPy/NumPy website In-Reply-To: <43EBAF81.80006@colorado.edu> (message from Fernando Perez on Thu, 09 Feb 2006 14:09:21 -0700) References: <200602091913.k19JDUhI020540@oobleck.astro.cornell.edu> <43EB9700.10107@gmail.com> <200602091930.k19JUlmf020683@oobleck.astro.cornell.edu> <43EB992A.8090706@gmail.com> <200602091952.k19Jqoml020764@oobleck.astro.cornell.edu> <43EBAF81.80006@colorado.edu> Message-ID: <200602092125.k19LP3OF021189@oobleck.astro.cornell.edu> >> Ah, understand. It may work to allow anonymous posting to a forum >> list made for that purpose, through an interface like gmane that has >> good input spam filtering. I don't know much about those interfaces, >> though. Let's not, for now, unless we hear more from the users that >> it's wanted. >No need. The verification via gmane is so easy that there's no need to change >anything. Non subscribers, the first time they post via gmane, will need to >authenticate themselves _to gmane_, via an email. Once they do that, it's >smooth sailing. >In summary: don't change anything. What we have keeps open spamming under >control, and doesn't place an undue burden on posters. That's the same burden as signing up on our site, since gmane isn't so popular that everyone has an account already. But, let's wait for complaints before making an open list nobody will subscribe to. Jonathan, did you have additional forum features in mind that gmane does not provide? We need a couple of people to do the wikipedia entry. Someone close to code development, to ensure the story is told right, and if that person is pressed for time maybe a user who can write well and will pull in some graphics and a simple cookbook example. This entry may be important for attracting new users, so please make sure it has good keywords for the likely searches. Volunteers? Should this be wikied internally and then posted, or should we use wikipedia's wiki and do it in the open? --jh-- From jh at oobleck.astro.cornell.edu Fri Feb 10 12:43:18 2006 From: jh at oobleck.astro.cornell.edu (Joe Harrington) Date: Fri, 10 Feb 2006 12:43:18 -0500 Subject: [SciPy-dev] old Scipy.org Message-ID: <200602101743.k1AHhI3t026967@oobleck.astro.cornell.edu> Hi Joe, I've now been contacted by several people who wonder where the old Scipy.org site is (the Plone site). I asked about it shortly after the conversion, and asked you yesterday in private email, but I have received no reply. Lots of links on both our own and others's sites are now dead. Joe, I hope you'll at least let us know what's up today. I hope the data are not lost. Having the old site available for continued conversion was a pre-conversion requirement that was made very clear. I know you're very busy, but please at least let us know the status of the data. We're worried. [If Joe is out, could someone at Enthought let us know so we don't interpret silence as trouble?] Thanks, --jh-- From robert.kern at gmail.com Fri Feb 10 12:50:39 2006 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 10 Feb 2006 11:50:39 -0600 Subject: [SciPy-dev] old Scipy.org In-Reply-To: <200602101743.k1AHhI3t026967@oobleck.astro.cornell.edu> References: <200602101743.k1AHhI3t026967@oobleck.astro.cornell.edu> Message-ID: <43ECD26F.5040703@gmail.com> Joe Harrington wrote: > Hi Joe, > > I've now been contacted by several people who wonder where the old > Scipy.org site is (the Plone site). I asked about it shortly after > the conversion, and asked you yesterday in private email, but I have > received no reply. Lots of links on both our own and others's sites > are now dead. Joe, I hope you'll at least let us know what's up > today. I hope the data are not lost. Having the old site available > for continued conversion was a pre-conversion requirement that was > made very clear. I know you're very busy, but please at least let us > know the status of the data. We're worried. http://new.scipy.org:8080/scipy.org -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From jh at oobleck.astro.cornell.edu Fri Feb 10 12:59:57 2006 From: jh at oobleck.astro.cornell.edu (Joe Harrington) Date: Fri, 10 Feb 2006 12:59:57 -0500 Subject: [SciPy-dev] old Scipy.org In-Reply-To: <43ECD26F.5040703@gmail.com> (message from Robert Kern on Fri, 10 Feb 2006 11:50:39 -0600) References: <200602101743.k1AHhI3t026967@oobleck.astro.cornell.edu> <43ECD26F.5040703@gmail.com> Message-ID: <200602101759.k1AHxvkE027039@oobleck.astro.cornell.edu> Phew! Thanks, Robert. I've added a link in Developer_Zone in the appropriate place, for migration purposes. Do people think there should be a more prominent link, like on the front page or in the nav bar? There is undoubtedly some wiki redirection magic we can do so old links either go to the right new place or to the old place...Andrew? --jh-- From travis at enthought.com Fri Feb 10 13:16:44 2006 From: travis at enthought.com (Travis N. Vaught) Date: Fri, 10 Feb 2006 12:16:44 -0600 Subject: [SciPy-dev] old Scipy.org In-Reply-To: <43ECD26F.5040703@gmail.com> References: <200602101743.k1AHhI3t026967@oobleck.astro.cornell.edu> <43ECD26F.5040703@gmail.com> Message-ID: <43ECD88C.9060702@enthought.com> Robert Kern wrote: > Joe Harrington wrote: > >> Hi Joe, >> >> I've now been contacted by several people who wonder where the old >> Scipy.org site is (the Plone site). I asked about it shortly after >> the conversion, and asked you yesterday in private email, but I have >> received no reply. Lots of links on both our own and others's sites >> are now dead. Joe, I hope you'll at least let us know what's up >> today. I hope the data are not lost. Having the old site available >> for continued conversion was a pre-conversion requirement that was >> made very clear. I know you're very busy, but please at least let us >> know the status of the data. We're worried. >> > > http://new.scipy.org:8080/scipy.org > > FWIW, that's an older version of the old site--which may suit most folks just fine, since it was a bit stagnant over the past year. I've put in a ticket to make the newest old site available, just to minimize work lost. Travis -- ........................ Travis N. Vaught CEO Enthought, Inc. http://www.enthought.com ........................ From guyer at nist.gov Fri Feb 10 13:50:04 2006 From: guyer at nist.gov (Jonathan Guyer) Date: Fri, 10 Feb 2006 13:50:04 -0500 Subject: [SciPy-dev] old Scipy.org In-Reply-To: <200602101759.k1AHxvkE027039@oobleck.astro.cornell.edu> References: <200602101743.k1AHhI3t026967@oobleck.astro.cornell.edu> <43ECD26F.5040703@gmail.com> <200602101759.k1AHxvkE027039@oobleck.astro.cornell.edu> Message-ID: On Feb 10, 2006, at 12:59 PM, Joe Harrington wrote: > There is undoubtedly some wiki redirection magic we can do so old > links either go to the right new place or to the old place...Andrew? That or .htaccess files. Links should never break. Never. From joe at enthought.com Fri Feb 10 16:04:11 2006 From: joe at enthought.com (Joe Cooper) Date: Fri, 10 Feb 2006 15:04:11 -0600 Subject: [SciPy-dev] old Scipy.org In-Reply-To: <200602101743.k1AHhI3t026967@oobleck.astro.cornell.edu> References: <200602101743.k1AHhI3t026967@oobleck.astro.cornell.edu> Message-ID: <43ECFFCB.6070201@enthought.com> My understanding was that everything anyone wanted had already been pulled off of the old site before I flipped the switch to the new one. But don't panic. The data is fine, and in fact, the site has never been shutdown. It just doesn't work very well anymore with a new domain name (and I don't have time at the moment to dig into plone to figure out how to change all of those image/css/js paths to go to the right place). It can be reached at http://old.scipy.org Joe Harrington wrote: > Hi Joe, > > I've now been contacted by several people who wonder where the old > Scipy.org site is (the Plone site). I asked about it shortly after > the conversion, and asked you yesterday in private email, but I have > received no reply. Lots of links on both our own and others's sites > are now dead. Joe, I hope you'll at least let us know what's up > today. I hope the data are not lost. Having the old site available > for continued conversion was a pre-conversion requirement that was > made very clear. I know you're very busy, but please at least let us > know the status of the data. We're worried. > > [If Joe is out, could someone at Enthought let us know so we don't > interpret silence as trouble?] > > Thanks, > > --jh-- From robert.kern at gmail.com Fri Feb 10 16:18:07 2006 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 10 Feb 2006 15:18:07 -0600 Subject: [SciPy-dev] old Scipy.org In-Reply-To: <43ECFFCB.6070201@enthought.com> References: <200602101743.k1AHhI3t026967@oobleck.astro.cornell.edu> <43ECFFCB.6070201@enthought.com> Message-ID: <43ED030F.5020708@gmail.com> Joe Cooper wrote: > My understanding was that everything anyone wanted had already been > pulled off of the old site before I flipped the switch to the new one. > But don't panic. > > The data is fine, and in fact, the site has never been shutdown. It > just doesn't work very well anymore with a new domain name (and I don't > have time at the moment to dig into plone to figure out how to change > all of those image/css/js paths to go to the right place). > > It can be reached at http://old.scipy.org The wikis are still unaccessible even by manually typing in the URL directly. E.g. http://old.scipy.org/wikis/topical_software/ -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From jh at oobleck.astro.cornell.edu Fri Feb 10 17:25:45 2006 From: jh at oobleck.astro.cornell.edu (Joe Harrington) Date: Fri, 10 Feb 2006 17:25:45 -0500 Subject: [SciPy-dev] old Scipy.org In-Reply-To: <2923a1803fcf9bb477da6b3345064914@stsci.edu> (message from Perry Greenfield on Fri, 10 Feb 2006 17:08:07 -0500) References: <200602101743.k1AHhI3t026967@oobleck.astro.cornell.edu> <43ECFFCB.6070201@enthought.com> <3f3a3edf6c2bcc7c8ff9cdcfe5854d7d@stsci.edu> <43ED0A29.1080204@enthought.com> <200602102156.k1ALukmd006899@oobleck.astro.cornell.edu> <2923a1803fcf9bb477da6b3345064914@stsci.edu> Message-ID: <200602102225.k1AMPjgi007058@oobleck.astro.cornell.edu> There are now instructions for getting to the old Plone site's wikis and other pages in Developer_Zone. It's painful, but it works. --jh-- From ndarray at mac.com Fri Feb 10 23:38:41 2006 From: ndarray at mac.com (Sasha) Date: Fri, 10 Feb 2006 23:38:41 -0500 Subject: [SciPy-dev] NumPy Glossary: a request for review Message-ID: Sorry for cross posting. This request clearly relevant to the NumPy list, but Wiki instructs that such requests should be posted on scipy-dev. Please review http://scipy.org/NumPyGlossary . From travis at enthought.com Fri Feb 10 23:44:49 2006 From: travis at enthought.com (Travis N. Vaught) Date: Fri, 10 Feb 2006 22:44:49 -0600 Subject: [SciPy-dev] old Scipy.org In-Reply-To: <43ED030F.5020708@gmail.com> References: <200602101743.k1AHhI3t026967@oobleck.astro.cornell.edu> <43ECFFCB.6070201@enthought.com> <43ED030F.5020708@gmail.com> Message-ID: <43ED6BC1.7010807@enthought.com> Robert Kern wrote: > Joe Cooper wrote: > >> ... >> It can be reached at http://old.scipy.org >> > > The wikis are still unaccessible even by manually typing in the URL directly. E.g. > > http://old.scipy.org/wikis/topical_software/ > The old.scipy.org plone site now looks sane (or as sane as it ever did). And the wikis work for me as well. Perhaps we could override the MissingPage system page in our MoinMoin instance to include a suggested link with the 'old.scipy.org' address. I've no idea if this is possible to do with a Moin macro or not. Probably not worth too much time, but at least the prose guidance of how to try to edit a broken link to get where you want to go would be useful on the MissingPage. I think Andrew S. or Chris F. has to do this, however. Best, Travis From perry at stsci.edu Sat Feb 11 00:11:45 2006 From: perry at stsci.edu (Perry Greenfield) Date: Sat, 11 Feb 2006 00:11:45 -0500 Subject: [SciPy-dev] interactive data analysis tutorial migrated to scipy.org Message-ID: <409c1f1b197b9f05b4a492765d7a5249@stsci.edu> I've just finished migrating those tutorial pages to scipy.org and updated the developer zone reference to it. I'll leave it to someone else to decide if it should be referred to on the document page. The developer zone page should be updated to use a different example to get to the old wiki since the tutorial is now available on the new site. Perry From Fernando.Perez at colorado.edu Sat Feb 11 01:20:39 2006 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Fri, 10 Feb 2006 23:20:39 -0700 Subject: [SciPy-dev] interactive data analysis tutorial migrated to scipy.org In-Reply-To: <409c1f1b197b9f05b4a492765d7a5249@stsci.edu> References: <409c1f1b197b9f05b4a492765d7a5249@stsci.edu> Message-ID: <43ED8237.1090908@colorado.edu> Perry Greenfield wrote: > I've just finished migrating those tutorial pages to scipy.org and > updated the developer zone reference to it. I'll leave it to someone > else to decide if it should be referred to on the document page. Umh. Can I vote YES? That tutorial is an excellent document, which I've pointed a LOT of people to (and had good responses to). It most certainly belongs on the doc page. Cheers, f From ndarray at mac.com Sat Feb 11 01:51:37 2006 From: ndarray at mac.com (Sasha) Date: Sat, 11 Feb 2006 01:51:37 -0500 Subject: [SciPy-dev] interactive data analysis tutorial migrated to scipy.org In-Reply-To: <409c1f1b197b9f05b4a492765d7a5249@stsci.edu> References: <409c1f1b197b9f05b4a492765d7a5249@stsci.edu> Message-ID: This tutorial uses numarray, but contains a promise "when PyFITS is ported to use numpy, the tutorial will be updated to use it instead of numarray." The tutorial is excellent and clearly deserves to be prominently displayed, but while it uses numarray it may confuse new users about the status of numpy. On 2/11/06, Perry Greenfield wrote: > I've just finished migrating those tutorial pages to scipy.org and > updated the developer zone reference to it. I'll leave it to someone > else to decide if it should be referred to on the document page. The > developer zone page should be updated to use a different example to get > to the old wiki since the tutorial is now available on the new site. From nwagner at mecha.uni-stuttgart.de Sat Feb 11 04:38:30 2006 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Sat, 11 Feb 2006 10:38:30 +0100 Subject: [SciPy-dev] NumPy_for_Matlab_Addicts Message-ID: Hi, The QR decomposition is already available in scipy. qr(a, overwrite_a=0, lwork=None) QR decomposition of an M x N matrix a. Description: Find a unitary matrix, q, and an upper-trapezoidal matrix r such that q * r = a Inputs: a -- the matrix overwrite_a=0 -- if non-zero then discard the contents of a, i.e. a is used as a work array if possible. lwork=None -- >= shape(a)[1]. If None (or -1) compute optimal work array size. Outputs: q, r -- matrices such that q * r = a Nils From aisaac at american.edu Sat Feb 11 09:51:05 2006 From: aisaac at american.edu (Alan G Isaac) Date: Sat, 11 Feb 2006 09:51:05 -0500 Subject: [SciPy-dev] NumPy_for_Matlab_Addicts In-Reply-To: References: Message-ID: On Sat, 11 Feb 2006, Nils Wagner apparently wrote: > The QR decomposition is already available in scipy. But missing from numpy.linalg Cheers, Alan Isaac From pebarrett at gmail.com Sat Feb 11 11:34:43 2006 From: pebarrett at gmail.com (Paul Barrett) Date: Sat, 11 Feb 2006 11:34:43 -0500 Subject: [SciPy-dev] interactive data analysis tutorial migrated to scipy.org In-Reply-To: References: <409c1f1b197b9f05b4a492765d7a5249@stsci.edu> Message-ID: <40e64fa20602110834m253f6163q829ac7edf2ea5768@mail.gmail.com> So how much longer before PyFITS is ready for numpy? Might this also be a good time to separate the convenience functions (i.e. getheader, getdata, etc.) of PyFITS into a new module? -- Paul On 2/11/06, Sasha wrote: > > This tutorial uses numarray, but contains a promise "when PyFITS is > ported to use numpy, the tutorial will be updated to use it instead of > numarray." The tutorial is excellent and clearly deserves to be > prominently displayed, but while it uses numarray it may confuse new > users about the status of numpy. > > On 2/11/06, Perry Greenfield wrote: > > I've just finished migrating those tutorial pages to scipy.org and > > updated the developer zone reference to it. I'll leave it to someone > > else to decide if it should be referred to on the document page. The > > developer zone page should be updated to use a different example to get > > to the old wiki since the tutorial is now available on the new site. > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev > -- Paul Barrett, PhD Johns Hopkins University Assoc. Research Scientist Dept of Physics and Astronomy Phone: 240-593-0028 Baltimore, MD 21218 -------------- next part -------------- An HTML attachment was scrubbed... URL: From perry at stsci.edu Sat Feb 11 12:23:22 2006 From: perry at stsci.edu (Perry Greenfield) Date: Sat, 11 Feb 2006 12:23:22 -0500 Subject: [SciPy-dev] interactive data analysis tutorial migrated to scipy.org In-Reply-To: <40e64fa20602110834m253f6163q829ac7edf2ea5768@mail.gmail.com> References: <409c1f1b197b9f05b4a492765d7a5249@stsci.edu> <40e64fa20602110834m253f6163q829ac7edf2ea5768@mail.gmail.com> Message-ID: On Feb 11, 2006, at 11:34 AM, Paul Barrett wrote: > So how much longer before PyFITS is ready for numpy? > Not long I hope. It's working for images, and the tables capability is coming on line. I'm hoping most of the work from this point on is fairly straightforward. I hate to try to give a specific time, but weeks rather than months now (I hope). For some time we'll have to support both numarray and numpy. We were hoping that some sort of matplotlib/numerix approach could be used, but indications are that it will more likely just be two different source modules (where which one loads depends on your preference, it will still be called pyfits). > Might this also be a good time to separate the convenience functions > (i.e. getheader, getdata, etc.) of PyFITS into a new module? > Possibly. There's been a little discussion about this. This is a good time to raise the issue so if people have suggestions, we're listening. Perry From Fernando.Perez at colorado.edu Sat Feb 11 14:25:11 2006 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Sat, 11 Feb 2006 12:25:11 -0700 Subject: [SciPy-dev] A wiki question on user pages Message-ID: <43EE3A17.4000702@colorado.edu> Hi all, I was wondering if it would be a good idea to make a few broad categories on the wiki, so that all the WikiNames aren't purely top-level. In particular, user pages seem like a good candidate for a users/ directory to exist. So far, I'm aware of these two (there may be more) http://scipy.org/ArndBaecker http://scipy.org/PearuPeterson It might be nicer to have them under http://scipy.org/users/ArndBaecker http://scipy.org/users/PearuPeterson no? This would also make it easier to have a users/Index page listing all existing user pages (there's probably a Moin macro that can do that automatically). For Trac wikis I know this kind of organization is possible, it may also be the case for Moin. I'm not advocating a 12-levels-deep structure, but at least a few categories like users/ doc/ cookbook/ might help keep the wiki sanely organized for the long run. Thoughts? f From steve at shrogers.com Sat Feb 11 16:12:59 2006 From: steve at shrogers.com (Steven H. Rogers) Date: Sat, 11 Feb 2006 14:12:59 -0700 Subject: [SciPy-dev] A wiki question on user pages In-Reply-To: <43EE3A17.4000702@colorado.edu> References: <43EE3A17.4000702@colorado.edu> Message-ID: <43EE535B.5020105@shrogers.com> G'day Fernando: I think this is a good idea. This (http://moinmoin.wikiwikiweb.de/FeatureRequests/UserPageSubdirectory) seems to indicate that MoinMoin 1.5 has an option to do something like this with a s separate UserHome wiki. Regards, Steve Fernando Perez wrote: > Hi all, > > I was wondering if it would be a good idea to make a few broad categories on > the wiki, so that all the WikiNames aren't purely top-level. In particular, > user pages seem like a good candidate for a users/ directory to exist. So > far, I'm aware of these two (there may be more) > > http://scipy.org/ArndBaecker > http://scipy.org/PearuPeterson > > It might be nicer to have them under > > http://scipy.org/users/ArndBaecker > http://scipy.org/users/PearuPeterson > > no? This would also make it easier to have a users/Index page listing all > existing user pages (there's probably a Moin macro that can do that > automatically). > > For Trac wikis I know this kind of organization is possible, it may also be > the case for Moin. > > I'm not advocating a 12-levels-deep structure, but at least a few categories like > > users/ > doc/ > cookbook/ > > might help keep the wiki sanely organized for the long run. Thoughts? > > f > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev > > -- Steven H. Rogers, Ph.D., steve at shrogers.com Weblog: http://shrogers.com/weblog "He who refuses to do arithmetic is doomed to talk nonsense." -- John McCarthy From nwagner at mecha.uni-stuttgart.de Mon Feb 13 05:05:57 2006 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Mon, 13 Feb 2006 11:05:57 +0100 Subject: [SciPy-dev] Possibly bug in sparse.py Message-ID: <43F05A05.3020800@mecha.uni-stuttgart.de> >>> a = spdiags([[1,2,3,4,5],[6,5,8,9,10]],[0,1],5,5) Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.4/site-packages/scipy/sparse/sparse.py", line 1841, in spdiags diagfunc = eval('sparsetools.'+_transtabl[mtype]+'diatocsr') File "", line 0, in ? AttributeError: 'module' object has no attribute 'ddiatocsr' From nwagner at mecha.uni-stuttgart.de Mon Feb 13 05:13:13 2006 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Mon, 13 Feb 2006 11:13:13 +0100 Subject: [SciPy-dev] Dense to sparse operator Message-ID: <43F05BB9.4000504@mecha.uni-stuttgart.de> Hi all, How can I "transform" a dense matrix into a sparse matrix in scipy ? Nils From nwagner at mecha.uni-stuttgart.de Mon Feb 13 05:23:12 2006 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Mon, 13 Feb 2006 11:23:12 +0100 Subject: [SciPy-dev] Dense to sparse operator In-Reply-To: <43F05BB9.4000504@mecha.uni-stuttgart.de> References: <43F05BB9.4000504@mecha.uni-stuttgart.de> Message-ID: <43F05E10.6090005@mecha.uni-stuttgart.de> Nils Wagner wrote: >Hi all, > >How can I "transform" a dense matrix into a sparse matrix in scipy ? > >Nils > > >_______________________________________________ >Scipy-dev mailing list >Scipy-dev at scipy.net >http://www.scipy.net/mailman/listinfo/scipy-dev > >>> A array([[ 2. , -0.9, 0. , 0. ], [-1.1, 2. , -0.9, 0. ], [ 0. , -1.1, 2. , -0.9], [ 0. , 0. , -1.1, 2. ]]) >>> Asp=csc_matrix(A) >>> Asp <4x4 sparse matrix of type '' with 10 stored elements (space for 10) in Compressed Sparse Column format> >>> print Asp (0, 0) 2.0 (1, 0) -1.1 (0, 1) -0.9 (1, 1) 2.0 (2, 1) -1.1 (1, 2) -0.9 (2, 2) 2.0 (3, 2) -1.1 (2, 3) -0.9 (3, 3) 2.0 >>> A.csc_matrix() Traceback (most recent call last): File "", line 1, in ? AttributeError: 'numpy.ndarray' object has no attribute 'csc_matrix' The opposite way round works fine >>> Asp.todense() array([[ 2. , -0.9, 0. , 0. ], [-1.1, 2. , -0.9, 0. ], [ 0. , -1.1, 2. , -0.9], [ 0. , 0. , -1.1, 2. ]]) Nils From cimrman3 at ntc.zcu.cz Mon Feb 13 05:36:00 2006 From: cimrman3 at ntc.zcu.cz (Robert Cimrman) Date: Mon, 13 Feb 2006 11:36:00 +0100 Subject: [SciPy-dev] Dense to sparse operator In-Reply-To: <43F05E10.6090005@mecha.uni-stuttgart.de> References: <43F05BB9.4000504@mecha.uni-stuttgart.de> <43F05E10.6090005@mecha.uni-stuttgart.de> Message-ID: <43F06110.3010907@ntc.zcu.cz> Nils Wagner wrote: > Nils Wagner wrote: > >>Hi all, >> >>How can I "transform" a dense matrix into a sparse matrix in scipy ? >> >>Nils >> >> >>_______________________________________________ >>Scipy-dev mailing list >>Scipy-dev at scipy.net >>http://www.scipy.net/mailman/listinfo/scipy-dev >> >> >>>>A > > array([[ 2. , -0.9, 0. , 0. ], > [-1.1, 2. , -0.9, 0. ], > [ 0. , -1.1, 2. , -0.9], > [ 0. , 0. , -1.1, 2. ]]) > >>>>Asp=csc_matrix(A) >>>>Asp > > <4x4 sparse matrix of type '' > with 10 stored elements (space for 10) > in Compressed Sparse Column format> > >>>>print Asp > > (0, 0) 2.0 > (1, 0) -1.1 > (0, 1) -0.9 > (1, 1) 2.0 > (2, 1) -1.1 > (1, 2) -0.9 > (2, 2) 2.0 > (3, 2) -1.1 > (2, 3) -0.9 > (3, 3) 2.0 > >>>>A.csc_matrix() > > Traceback (most recent call last): > File "", line 1, in ? > AttributeError: 'numpy.ndarray' object has no attribute 'csc_matrix' > > The opposite way round works fine > > >>>>Asp.todense() > > array([[ 2. , -0.9, 0. , 0. ], > [-1.1, 2. , -0.9, 0. ], > [ 0. , -1.1, 2. , -0.9], > [ 0. , 0. , -1.1, 2. ]]) > > Nils Hi Nils, the problem here is, that the dense matrices (or numpy arrays) are not on the same level as the sparse matrix module - the sparse matrix module knows about and uses the numpy arrays, while the numpy arrays are not aware of the sparse matrix module. That is why you can do sparseA.todense() and you cannot do denseA.tosparse() or something similar (but it would be nice :-)) - use instead the form sparseA = csc_matrix( densaA ), or any other sparse matrix construcotr, just like you did. r. From nwagner at mecha.uni-stuttgart.de Mon Feb 13 07:01:50 2006 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Mon, 13 Feb 2006 13:01:50 +0100 Subject: [SciPy-dev] Could not resolve hostname `ipython.scipy.org' Message-ID: <43F0752E.2020709@mecha.uni-stuttgart.de> The svn access to ipython is broken. svn: PROPFIND request failed on '/svn/ipython/ipython/trunk' svn: PROPFIND of '/svn/ipython/ipython/trunk': Could not resolve hostname `ipython.scipy.org': Temporary failure in name resolution (http://ipython.scipy.org) From schofield at ftw.at Mon Feb 13 08:57:31 2006 From: schofield at ftw.at (Ed Schofield) Date: Mon, 13 Feb 2006 14:57:31 +0100 Subject: [SciPy-dev] scipy 0.4.6 release? In-Reply-To: <43E21738.4060105@ieee.org> References: <43DA1A6F.3050103@hoc.net> <1138380174.43da4d8ed9ae6@webmail.colorado.edu> <43E1A561.6000103@dslextreme.com> <43E1F355.1050001@ftw.at> <43E21738.4060105@ieee.org> Message-ID: <43F0904B.1040901@ftw.at> Travis Oliphant wrote: > Ed Schofield wrote: > >> I think this is a good idea. The most recent release (0.4.4) also isn't >> compatible with the latest NumPy (0.9.4). I could work on making a new >> release this weekend if people agree. >> > I'll roll out NumPy 0.9.5 at the same time so we have two versions > that work together. There have been some bug-fixes and a few (minor) > feature changes. Hi Travis, How's it going with the NumPy 0.9.5 release? I've now built a SciPy 0.4.6 tarball and Win32 binaries against NumPy 0.9.5.2094. I'm getting one unit test failure with this version of NumPy (see below), but all the SciPy unit tests pass for me on x86 Linux and Win32 (XP). If you'd like to make any more changes before NumPy 0.9.5 that require changes to SciPy, I can re-build the binaries. Otherwise I'll post the release whenever you're ready. -- Ed ====================================================================== ERROR: check_bug_r2089 (numpy.core.oldnumeric.test_oldnumeric.test_put) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/numpy/core/tests/test_oldnumeric.py", line 11, in check_bug_r2089 put(a,[1],array([2.2])) File "/usr/lib/python2.4/site-packages/numpy/core/oldnumeric.py", line 199, in put return a.put(v,ind) TypeError: array cannot be safely cast to required type ---------------------------------------------------------------------- Ran 256 tests in 0.518s FAILED (errors=1) From Fernando.Perez at colorado.edu Mon Feb 13 13:09:43 2006 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Mon, 13 Feb 2006 11:09:43 -0700 Subject: [SciPy-dev] Could not resolve hostname `ipython.scipy.org' In-Reply-To: <43F0752E.2020709@mecha.uni-stuttgart.de> References: <43F0752E.2020709@mecha.uni-stuttgart.de> Message-ID: <43F0CB67.6030805@colorado.edu> Nils Wagner wrote: > The svn access to ipython is broken. > > svn: PROPFIND request failed on '/svn/ipython/ipython/trunk' > svn: PROPFIND of '/svn/ipython/ipython/trunk': Could not resolve > hostname `ipython.scipy.org': Temporary failure in name resolution > (http://ipython.scipy.org) Well, every access to ipython.scipy.org seems broken :( I'll ping Enthought directly for help, thanks for reporting this. Cheers, f From travis at enthought.com Mon Feb 13 13:12:17 2006 From: travis at enthought.com (Travis N. Vaught) Date: Mon, 13 Feb 2006 12:12:17 -0600 Subject: [SciPy-dev] Could not resolve hostname `ipython.scipy.org' In-Reply-To: <43F0CB67.6030805@colorado.edu> References: <43F0752E.2020709@mecha.uni-stuttgart.de> <43F0CB67.6030805@colorado.edu> Message-ID: <43F0CC01.40606@enthought.com> This is already submitted internally as a ticket...I'll run it to ground ASAP. Travis Fernando Perez wrote: > Nils Wagner wrote: > >> The svn access to ipython is broken. >> >> svn: PROPFIND request failed on '/svn/ipython/ipython/trunk' >> svn: PROPFIND of '/svn/ipython/ipython/trunk': Could not resolve >> hostname `ipython.scipy.org': Temporary failure in name resolution >> (http://ipython.scipy.org) >> > > Well, every access to ipython.scipy.org seems broken :( > > I'll ping Enthought directly for help, thanks for reporting this. > > Cheers, > > f > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev > -- ........................ Travis N. Vaught CEO Enthought, Inc. http://www.enthought.com ........................ From curtis at lpl.arizona.edu Mon Feb 13 13:20:30 2006 From: curtis at lpl.arizona.edu (Curtis Cooper) Date: Mon, 13 Feb 2006 11:20:30 -0700 (MST) Subject: [SciPy-dev] Weave Documentation Message-ID: Hi everyone, I am a graduate student at the University of Arizona, Tucson. I have been using STSCI's numarray package productively for two years but just switched to NumPy (fairly seamlessly, though there have been a few hitches). I am enthusiastic about the potential of Scientific Python and would like to help some, although I'm very busy this semester finishing up my dissertation. Anyway, I'm a frequent Weave user. This question relates to the transition to the new-Wiki site. Basically, the documentation of scipy.weave on the old site was excellent. I'm not sure there's much point in rewriting it. To make weave documented on the main scipy.org page, can we just hyperlink to the old pages? This seems to be a common symptom of the switch to Wiki-style. The format/layout of the new site is indeed better, but the content by in large has not been transferred. Cheers, Curtis * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Curtis S. Cooper, Graduate Research Assistant * * Lunar and Planetary Laboratory, University of Arizona * * http://www.lpl.arizona.edu/~curtis/ * * Kuiper Space Sciences, Rm. 318 * * 1629 E. University Blvd., * * Tucson, AZ 85721 * * * * * * * * * * * * * * * * Wk: (520) 621-1471 * * * * * * * * * * * * * From Fernando.Perez at colorado.edu Mon Feb 13 13:51:56 2006 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Mon, 13 Feb 2006 11:51:56 -0700 Subject: [SciPy-dev] Could not resolve hostname `ipython.scipy.org' In-Reply-To: <43F0CC01.40606@enthought.com> References: <43F0752E.2020709@mecha.uni-stuttgart.de> <43F0CB67.6030805@colorado.edu> <43F0CC01.40606@enthought.com> Message-ID: <43F0D54C.8030909@colorado.edu> Travis N. Vaught wrote: > This is already submitted internally as a ticket...I'll run it to ground > ASAP. > Great, many thanks. Probably collateral damage from this weekend's apache meltdown, I'd imagine. Regards, f From nwagner at mecha.uni-stuttgart.de Mon Feb 13 13:54:27 2006 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Mon, 13 Feb 2006 19:54:27 +0100 Subject: [SciPy-dev] Eigentest: Test matrices for large-scale eigenproblems Message-ID: Hi all, This might be of interest. From: "G. W. (Pete) Stewart" Date: Mon, 13 Feb 2006 09:19:06 -0500 (EST) Subject: Eigentest: Test matrices for large-scale eigenproblems Che Rung Lee I have written a package Eigentest that produces real test matrices with known eigensystems. A test matrix, called an eigenmat, is generated in a factored form, in which the user can specify the eigenvalues and has some control over the condition of the eigenvalues and eigenvectors. An eigenmat A of order n requires only O(n) storage for its representation. Auxiliary programs permit the computation of (A - s*I)*b, (A - s*I)'*b, inv(A - s*I)*b, and inv(A - s*I)'*b in O(n) operations. A special routine computes specified eigenvectors of an eigenmat and the condition of its eigenvalues. Thus eigenmats are suitable for testing algorithms based on Krylov sequences, as well as others based on matrix vector products. The package contains implementations in Fortran 77, Fortran 95, C, and Matlab. The Eigentest package can be downloaded via my home page http://www.cs.umd.edu/~stewart/ For a paper describing Eigentest click on the Contents link in the same page. Pete Stewart Nils From robert.kern at gmail.com Mon Feb 13 17:19:37 2006 From: robert.kern at gmail.com (Robert Kern) Date: Mon, 13 Feb 2006 16:19:37 -0600 Subject: [SciPy-dev] Could not resolve hostname `ipython.scipy.org' In-Reply-To: <43F0D54C.8030909@colorado.edu> References: <43F0752E.2020709@mecha.uni-stuttgart.de> <43F0CB67.6030805@colorado.edu> <43F0CC01.40606@enthought.com> <43F0D54C.8030909@colorado.edu> Message-ID: <43F105F9.5000506@gmail.com> Fernando Perez wrote: > Travis N. Vaught wrote: > >>This is already submitted internally as a ticket...I'll run it to ground >>ASAP. > > Great, many thanks. Probably collateral damage from this weekend's apache > meltdown, I'd imagine. It's fixed now. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From nwagner at mecha.uni-stuttgart.de Tue Feb 14 04:49:31 2006 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Tue, 14 Feb 2006 10:49:31 +0100 Subject: [SciPy-dev] Possibly bug in sparse.py Message-ID: <43F1A7AB.7060908@mecha.uni-stuttgart.de> C =dot(A,XX)+dot(XX,B) File "/usr/local/lib/python2.4/site-packages/scipy/sparse/sparse.py", line 532, in __add__ raise ValueError, "inconsistent shapes" ValueError: inconsistent shapes >>> A <317x317 sparse matrix of type '' with 7327 stored elements (space for 7327) in COOrdinate format> >>> XX array([[0, 1, 1, ..., 1, 1, 1], [1, 0, 1, ..., 1, 1, 1], [1, 1, 0, ..., 1, 1, 1], ..., [1, 1, 1, ..., 1, 1, 1], [1, 1, 1, ..., 1, 1, 1], [1, 1, 1, ..., 1, 1, 1]]) >>> shape(XX) (317, 10) >>> shape(B) (10, 10) >>> B <10x10 sparse matrix of type '' with 28 stored elements (space for 28) in Compressed Sparse Column format> How can I fix this problem ? Nils From pearu at scipy.org Tue Feb 14 05:00:14 2006 From: pearu at scipy.org (Pearu Peterson) Date: Tue, 14 Feb 2006 04:00:14 -0600 (CST) Subject: [SciPy-dev] could not connect to server http://svn.scipy.org In-Reply-To: <43F105F9.5000506@gmail.com> References: <43F0752E.2020709@mecha.uni-stuttgart.de> <43F0CB67.6030805@colorado.edu> <43F0CC01.40606@enthought.com> <43F0D54C.8030909@colorado.edu> <43F105F9.5000506@gmail.com> Message-ID: Hi, There are still some problems with svn.scipy.org pearu at p4:~/svn/numpy$ svn update svn: PROPFIND request failed on '/svn/numpy/trunk' svn: PROPFIND of '/svn/numpy/trunk': could not connect to server (http://svn.scipy.org) ping svn.scipy.org works. Pearu From cimrman3 at ntc.zcu.cz Tue Feb 14 06:01:55 2006 From: cimrman3 at ntc.zcu.cz (Robert Cimrman) Date: Tue, 14 Feb 2006 12:01:55 +0100 Subject: [SciPy-dev] Possibly bug in sparse.py In-Reply-To: <43F1A7AB.7060908@mecha.uni-stuttgart.de> References: <43F1A7AB.7060908@mecha.uni-stuttgart.de> Message-ID: <43F1B8A3.3090306@ntc.zcu.cz> Nils Wagner wrote: > C =dot(A,XX)+dot(XX,B) > File "/usr/local/lib/python2.4/site-packages/scipy/sparse/sparse.py", > line 532, in __add__ > raise ValueError, "inconsistent shapes" > ValueError: inconsistent shapes > >>>>A > > <317x317 sparse matrix of type '' > with 7327 stored elements (space for 7327) > in COOrdinate format> > >>>>XX > > array([[0, 1, 1, ..., 1, 1, 1], > [1, 0, 1, ..., 1, 1, 1], > [1, 1, 0, ..., 1, 1, 1], > ..., > [1, 1, 1, ..., 1, 1, 1], > [1, 1, 1, ..., 1, 1, 1], > [1, 1, 1, ..., 1, 1, 1]]) > >>>>shape(XX) > > (317, 10) > >>>>shape(B) > > (10, 10) > > >>>>B > > <10x10 sparse matrix of type '' > with 28 stored elements (space for 28) > in Compressed Sparse Column format> > > How can I fix this problem ? First, use A * XX + XX * B instead of dot, since dot is a numpy.core function and as such cannot handle sparse matrices. Then there was a bug in the coo_matrix() constructor (not fixed yet in svn, cannot log in...) causing that the shape was one less than the actual shape... Thanks for debugging! --- Side note, not directly related to your problem: Another bug in the coo_matrix() constructor is that it does not work for all value types (e.g. int32), because some dtypes are probably missing in the type translation table of sparse.py - can someone (Travis? :) help with this? I have followed the recent changes to the dtype object only superficially... r. From nwagner at mecha.uni-stuttgart.de Tue Feb 14 06:59:49 2006 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Tue, 14 Feb 2006 12:59:49 +0100 Subject: [SciPy-dev] Possibly bug in sparse.py In-Reply-To: <43F1B8A3.3090306@ntc.zcu.cz> References: <43F1A7AB.7060908@mecha.uni-stuttgart.de> <43F1B8A3.3090306@ntc.zcu.cz> Message-ID: <43F1C635.4070904@mecha.uni-stuttgart.de> Robert Cimrman wrote: >Nils Wagner wrote: > >> C =dot(A,XX)+dot(XX,B) >> File "/usr/local/lib/python2.4/site-packages/scipy/sparse/sparse.py", >>line 532, in __add__ >> raise ValueError, "inconsistent shapes" >>ValueError: inconsistent shapes >> >> >>>>>A >>>>> >><317x317 sparse matrix of type '' >> with 7327 stored elements (space for 7327) >> in COOrdinate format> >> >> >>>>>XX >>>>> >>array([[0, 1, 1, ..., 1, 1, 1], >> [1, 0, 1, ..., 1, 1, 1], >> [1, 1, 0, ..., 1, 1, 1], >> ..., >> [1, 1, 1, ..., 1, 1, 1], >> [1, 1, 1, ..., 1, 1, 1], >> [1, 1, 1, ..., 1, 1, 1]]) >> >> >>>>>shape(XX) >>>>> >>(317, 10) >> >> >>>>>shape(B) >>>>> >>(10, 10) >> >> >> >>>>>B >>>>> >><10x10 sparse matrix of type '' >> with 28 stored elements (space for 28) >> in Compressed Sparse Column format> >> >>How can I fix this problem ? >> > >First, use A * XX + XX * B instead of dot, since dot is a numpy.core >function and as such cannot handle sparse matrices. > >Then there was a bug in the coo_matrix() constructor (not fixed yet in >svn, cannot log in...) causing that the shape was one less than the >actual shape... Thanks for debugging! > >--- >Side note, not directly related to your problem: > >Another bug in the coo_matrix() constructor is that it does not work for >all value types (e.g. int32), because some dtypes are probably missing >in the type translation table of sparse.py - can someone (Travis? :) >help with this? I have followed the recent changes to the dtype object >only superficially... > >r. > >_______________________________________________ >Scipy-dev mailing list >Scipy-dev at scipy.net >http://www.scipy.net/mailman/listinfo/scipy-dev > Hi Robert, Thank you for your comments. Meanwhile I ask you to reply to some questions raised up w.r.t. to sparse matrix objects. See FAQ_sparse.py for details. I look forward to hearing from you. Cheers Nils -------------- next part -------------- A non-text attachment was scrubbed... Name: FAQ_sparse.py Type: text/x-python Size: 421 bytes Desc: not available URL: From nwagner at mecha.uni-stuttgart.de Tue Feb 14 07:22:32 2006 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Tue, 14 Feb 2006 13:22:32 +0100 Subject: [SciPy-dev] Counterpart to eye --> speye Message-ID: <43F1CB88.6050005@mecha.uni-stuttgart.de> Hi all, Is a counterpart to eye available in scipy ? I mean something like def speye(n): return csc_matrix(eye(n)) Nils From cimrman3 at ntc.zcu.cz Tue Feb 14 08:19:53 2006 From: cimrman3 at ntc.zcu.cz (Robert Cimrman) Date: Tue, 14 Feb 2006 14:19:53 +0100 Subject: [SciPy-dev] Counterpart to eye --> speye In-Reply-To: <43F1CB88.6050005@mecha.uni-stuttgart.de> References: <43F1CB88.6050005@mecha.uni-stuttgart.de> Message-ID: <43F1D8F9.1010408@ntc.zcu.cz> Nils Wagner wrote: > Hi all, > > Is a counterpart to eye available in scipy ? > > I mean something like > > def speye(n): > return csc_matrix(eye(n)) > If you don't want to pass through a full matrix, you can do e.g.: import scipy.sparse as sp import scipy as nm ii = nm.arange( 10 ) v = nm.ones( 10, dtype = nm.float64 ) a = sp.coo_matrix( v, (ii, ii) ) In [55]:a Out[55]: <10x10 sparse matrix of type '' with 10 stored elements (space for 10) in COOrdinate format> In [56]:p a (0, 0) 1.0 (1, 1) 1.0 (2, 2) 1.0 (3, 3) 1.0 (4, 4) 1.0 (5, 5) 1.0 (6, 6) 1.0 (7, 7) 1.0 (8, 8) 1.0 (9, 9) 1.0 r. From nwagner at mecha.uni-stuttgart.de Tue Feb 14 08:29:06 2006 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Tue, 14 Feb 2006 14:29:06 +0100 Subject: [SciPy-dev] More bugs in sparse.py Message-ID: <43F1DB22.5020501@mecha.uni-stuttgart.de> Hi Robert, I followed your advice and replaced dot by * This results in R0 = C-(A*X0+X0*B) File "/usr/local/lib/python2.4/site-packages/scipy/sparse/sparse.py", line 537, in __add__ c, rowc, ptrc, ierr = func(data1, self.rowind[:nnz1], self.indptr, data2, ocs.rowind[:nnz2], ocs.indptr) ValueError: failed to create intent(cache|hide)|optional array-- must have defined dimensions but got (0,) >>> A <317x317 sparse matrix of type '' with 7280 stored elements (space for 7327) in Compressed Sparse Column format> >>> X0 <317x10 sparse matrix of type '' with 0 stored elements (space for 100) in Compressed Sparse Column format> >>> C <317x10 sparse matrix of type '' with 3170 stored elements (space for 3828) in Compressed Sparse Column format> >>> B <10x10 sparse matrix of type '' with 28 stored elements (space for 28) in Compressed Sparse Column format> Nils From cimrman3 at ntc.zcu.cz Tue Feb 14 08:56:32 2006 From: cimrman3 at ntc.zcu.cz (Robert Cimrman) Date: Tue, 14 Feb 2006 14:56:32 +0100 Subject: [SciPy-dev] Possibly bug in sparse.py In-Reply-To: <43F1C635.4070904@mecha.uni-stuttgart.de> References: <43F1A7AB.7060908@mecha.uni-stuttgart.de> <43F1B8A3.3090306@ntc.zcu.cz> <43F1C635.4070904@mecha.uni-stuttgart.de> Message-ID: <43F1E190.4000005@ntc.zcu.cz> Nils Wagner wrote: > Hi Robert, > > Thank you for your comments. > Meanwhile I ask you to reply to some questions raised up w.r.t. to > sparse matrix objects. > See FAQ_sparse.py for details. > > I look forward to hearing from you. > > Cheers > Nils look at the answers Ed gave you a while ago on scipy-user :-) r. From robert.kern at gmail.com Tue Feb 14 11:27:34 2006 From: robert.kern at gmail.com (Robert Kern) Date: Tue, 14 Feb 2006 10:27:34 -0600 Subject: [SciPy-dev] could not connect to server http://svn.scipy.org In-Reply-To: References: <43F0752E.2020709@mecha.uni-stuttgart.de> <43F0CB67.6030805@colorado.edu> <43F0CC01.40606@enthought.com> <43F0D54C.8030909@colorado.edu> <43F105F9.5000506@gmail.com> Message-ID: <43F204F6.6030004@gmail.com> Pearu Peterson wrote: > Hi, > > There are still some problems with svn.scipy.org > > pearu at p4:~/svn/numpy$ svn update > svn: PROPFIND request failed on '/svn/numpy/trunk' > svn: PROPFIND of '/svn/numpy/trunk': could not connect to server > (http://svn.scipy.org) > > ping svn.scipy.org works. Apache fell over again. It is fixed, now. I would like to note that we are currently without a full-time sysadmin (actually, we've never had a full-time sysadmin, but have even less of one now). If you know any good sysadmins in Austin, TX, we would love to hear from them. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From oliphant.travis at ieee.org Tue Feb 14 14:48:02 2006 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Tue, 14 Feb 2006 12:48:02 -0700 Subject: [SciPy-dev] Possibly bug in sparse.py In-Reply-To: <43F1B8A3.3090306@ntc.zcu.cz> References: <43F1A7AB.7060908@mecha.uni-stuttgart.de> <43F1B8A3.3090306@ntc.zcu.cz> Message-ID: <43F233F2.2050006@ieee.org> Robert Cimrman wrote: >e note, not directly related to your problem: > >Another bug in the coo_matrix() constructor is that it does not work for >all value types (e.g. int32), because some dtypes are probably missing >in the type translation table of sparse.py - can someone (Travis? :) >help with this? I have followed the recent changes to the dtype object >only superficially... > > This has never worked because the conversion to csc_matrix is not supported for anything but the four basic data types. We could fix the constructor so that the array could be constructed, though, and only raise an error when a conversion is attempted. -Travis From eric at enthought.com Tue Feb 14 15:45:54 2006 From: eric at enthought.com (eric jones) Date: Tue, 14 Feb 2006 14:45:54 -0600 Subject: [SciPy-dev] [Numpy-discussion] NumPy Glossary: a request for review In-Reply-To: <43F2328E.8090306@noaa.gov> References: <43ED700B.10903@bigpond.net.au> <43ED7C3D.6070705@bigpond.net.au> <43F110D6.6060302@noaa.gov> <43F2328E.8090306@noaa.gov> Message-ID: <43F24182.2090501@enthought.com> Christopher Barker wrote: > Sasha wrote: >> However, if others think a link to more detailed explanation belongs >> to glossary entries, the natural destination of the link would be a >> page in Travis' book. > > Not unless that glossary is part of the book. Links in the Wiki should > point to the wiki, or maybe to other openly available sources on the web. > > A link isn't critical, but a page about broadcasting would still be > nice, it's a great feature of numpy. I wrote an article a while back for PyZine about broadcasting. Janet worked on it and ran it through some Word->Moin filter: http://moinmoin.wikiwikiweb.de/MicrosoftWordConverter which did pretty well: http://www.scipy.org/EricsBroadcastingDoc It still needs some work (still missing images), but it is probably a pretty good place to point for more broadcasting details. Perhaps it needs a different location as well? thanks, eric > > -Chris > > From curtis at lpl.arizona.edu Tue Feb 14 23:41:13 2006 From: curtis at lpl.arizona.edu (Curtis Cooper) Date: Tue, 14 Feb 2006 21:41:13 -0700 (MST) Subject: [SciPy-dev] segmentation fault Message-ID: Hi, I just updated my numpy from subversion build 2064 to be current with the svn repository. Multidimensional array code that worked in the previous version now causes a segmentation fault on my system. I have reverted back to 2064 for the present, which seems to work fine. I have not diagnosed the problem in greater detail. But a segmentation fault is a very strange error for a python program, especially as numpy checks for array out of bounds. Thanks, Curtis From oliphant.travis at ieee.org Wed Feb 15 00:54:30 2006 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Tue, 14 Feb 2006 22:54:30 -0700 Subject: [SciPy-dev] segmentation fault In-Reply-To: References: Message-ID: <43F2C216.4050204@ieee.org> Curtis Cooper wrote: >Hi, > >I just updated my numpy from subversion build 2064 to be current with >the svn repository. Multidimensional array code that worked in the >previous version now causes a segmentation fault on my system. I have >reverted back to 2064 for the present, which seems to work fine. I have >not diagnosed the problem in greater detail. But a segmentation fault is >a very strange error for a python program, especially as numpy checks for >array out of bounds. > > It should not segfault, of course. But, sometimes we forget to check something and segfaults can occur. Please post the code that is segfaulting. Also, make sure to cleanly build (i.e. rm -fr build in the head numpy directory). -Travis From ndarray at mac.com Wed Feb 15 01:10:42 2006 From: ndarray at mac.com (Sasha) Date: Wed, 15 Feb 2006 01:10:42 -0500 Subject: [SciPy-dev] segmentation fault In-Reply-To: <43F2C216.4050204@ieee.org> References: <43F2C216.4050204@ieee.org> Message-ID: > Please post the code that is segfaulting. Also, make sure to cleanly > build (i.e. rm -fr build in the head numpy directory). If the segfaulting code is too big to post, you can use Linus Torvalds' method to locate the change that introduced the problem. You start with known good (2064) and known bad (current) versions and disect the version range until you find the offending change. http://www.kernel.org/pub/software/scm/git/docs/howto/isolate-bugs-with-bisect.txt From nwagner at mecha.uni-stuttgart.de Wed Feb 15 05:44:07 2006 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Wed, 15 Feb 2006 11:44:07 +0100 Subject: [SciPy-dev] ValueError: failed to create intent(cache|hide)|optional array-- must have defined dimensions but got (0, ) Message-ID: <43F305F7.7010900@mecha.uni-stuttgart.de> Hi all, I have used the latest svn version of scipy. BTW X= is initialized as follows X0 = csc_matrix((n,s)) The problem which I have reported yesterday is R0 = C-(A*X0+X0*B) File "/usr/local/lib/python2.4/site-packages/scipy/sparse/sparse.py", line 537, in __add__ c, rowc, ptrc, ierr = func(data1, self.rowind[:nnz1], self.indptr, data2, ocs.rowind[:nnz2], ocs.indptr) ValueError: failed to create intent(cache|hide)|optional array-- must have defined dimensions but got (0,) >>> C <317x10 sparse matrix of type '' with 3170 stored elements (space for 3828) in Compressed Sparse Column format> >>> A <317x317 sparse matrix of type '' with 7280 stored elements (space for 7327) in Compressed Sparse Column format> >>> X0 <317x10 sparse matrix of type '' with 0 stored elements (space for 100) in Compressed Sparse Column format> >>> B <10x10 sparse matrix of type '' with 28 stored elements (space for 28) in Compressed Sparse Column format> From nwagner at mecha.uni-stuttgart.de Wed Feb 15 09:14:26 2006 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Wed, 15 Feb 2006 15:14:26 +0100 Subject: [SciPy-dev] Segfault on 64 bit machine with latest svn Message-ID: <43F33742.1010000@mecha.uni-stuttgart.de> Hi all, I am getting a segfault Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 12703)] PyArray_SortkindConverter (obj=0x0, sortkind=) at multiarraymodule.c:4112 4112 *sortkind = PyArray_QUICKSORT; (gdb) bt #0 PyArray_SortkindConverter (obj=0x0, sortkind=) at multiarraymodule.c:4112 #1 0x00002aaab63ea5a5 in init_ns_transforms () at __multiarray_api.h:766 #2 0x00002aaaaac6643b in _PyImport_LoadDynamicModule () from /usr/lib64/libpython2.4.so.1.0 #3 0x00002aaaaac645e3 in load_module () from /usr/lib64/libpython2.4.so.1.0 #4 0x00002aaaaac64dda in import_submodule () from /usr/lib64/libpython2.4.so.1.0 #5 0x00002aaaaac64fd8 in load_next () from /usr/lib64/libpython2.4.so.1.0 #6 0x00002aaaaac655dd in PyImport_ImportModuleEx () from /usr/lib64/libpython2.4.so.1.0 #7 0x00002aaaaac48633 in builtin___import__ () from /usr/lib64/libpython2.4.so.1.0 #8 0x00002aaaaac1c13c in PyCFunction_Call () from /usr/lib64/libpython2.4.so.1.0 #9 0x00002aaaaabf7f20 in PyObject_Call () from /usr/lib64/libpython2.4.so.1.0 #10 0x00002aaaaac4b5c9 in PyEval_CallObjectWithKeywords () from /usr/lib64/libpython2.4.so.1.0 #11 0x00002aaaaac4cd15 in PyEval_EvalFrame () from /usr/lib64/libpython2.4.so.1.0 Any idea ? Nils From nwagner at mecha.uni-stuttgart.de Wed Feb 15 10:25:58 2006 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Wed, 15 Feb 2006 16:25:58 +0100 Subject: [SciPy-dev] Segfault on 64 bit machine with latest svn In-Reply-To: <43F33742.1010000@mecha.uni-stuttgart.de> References: <43F33742.1010000@mecha.uni-stuttgart.de> Message-ID: <43F34806.7020406@mecha.uni-stuttgart.de> Nils Wagner wrote: >Hi all, > >I am getting a segfault > >Program received signal SIGSEGV, Segmentation fault. >[Switching to Thread 16384 (LWP 12703)] >PyArray_SortkindConverter (obj=0x0, sortkind=) at >multiarraymodule.c:4112 >4112 *sortkind = PyArray_QUICKSORT; >(gdb) bt >#0 PyArray_SortkindConverter (obj=0x0, sortkind=) >at multiarraymodule.c:4112 >#1 0x00002aaab63ea5a5 in init_ns_transforms () at __multiarray_api.h:766 >#2 0x00002aaaaac6643b in _PyImport_LoadDynamicModule () from >/usr/lib64/libpython2.4.so.1.0 >#3 0x00002aaaaac645e3 in load_module () from /usr/lib64/libpython2.4.so.1.0 >#4 0x00002aaaaac64dda in import_submodule () from >/usr/lib64/libpython2.4.so.1.0 >#5 0x00002aaaaac64fd8 in load_next () from /usr/lib64/libpython2.4.so.1.0 >#6 0x00002aaaaac655dd in PyImport_ImportModuleEx () from >/usr/lib64/libpython2.4.so.1.0 >#7 0x00002aaaaac48633 in builtin___import__ () from >/usr/lib64/libpython2.4.so.1.0 >#8 0x00002aaaaac1c13c in PyCFunction_Call () from >/usr/lib64/libpython2.4.so.1.0 >#9 0x00002aaaaabf7f20 in PyObject_Call () from >/usr/lib64/libpython2.4.so.1.0 >#10 0x00002aaaaac4b5c9 in PyEval_CallObjectWithKeywords () from >/usr/lib64/libpython2.4.so.1.0 >#11 0x00002aaaaac4cd15 in PyEval_EvalFrame () from >/usr/lib64/libpython2.4.so.1.0 > > Any idea ? > >Nils > >_______________________________________________ >Scipy-dev mailing list >Scipy-dev at scipy.net >http://www.scipy.net/mailman/listinfo/scipy-dev > It seems to be introduced in version 0.9.5.2109. Here is a test code to reproduce the segfault Nils -------------- next part -------------- A non-text attachment was scrubbed... Name: seg_test.py Type: text/x-python Size: 112 bytes Desc: not available URL: From schofield at ftw.at Wed Feb 15 10:43:34 2006 From: schofield at ftw.at (Ed Schofield) Date: Wed, 15 Feb 2006 16:43:34 +0100 Subject: [SciPy-dev] Segfault on 64 bit machine with latest svn In-Reply-To: <43F34806.7020406@mecha.uni-stuttgart.de> References: <43F33742.1010000@mecha.uni-stuttgart.de> <43F34806.7020406@mecha.uni-stuttgart.de> Message-ID: <43F34C26.3080308@ftw.at> Nils Wagner wrote: >It seems to be introduced in version 0.9.5.2109. >Here is a test code to reproduce the segfault > > I'm not getting this. Are you sure you've recompiled scipy and matplotlib from scratch against your latest numpy version? -- Ed From nwagner at mecha.uni-stuttgart.de Wed Feb 15 10:47:19 2006 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Wed, 15 Feb 2006 16:47:19 +0100 Subject: [SciPy-dev] Segfault on 64 bit machine with latest svn In-Reply-To: <43F34C26.3080308@ftw.at> References: <43F33742.1010000@mecha.uni-stuttgart.de> <43F34806.7020406@mecha.uni-stuttgart.de> <43F34C26.3080308@ftw.at> Message-ID: <43F34D07.2000000@mecha.uni-stuttgart.de> Ed Schofield wrote: >Nils Wagner wrote: > > >>It seems to be introduced in version 0.9.5.2109. >>Here is a test code to reproduce the segfault >> >> >> > >I'm not getting this. Are you sure you've recompiled scipy and >matplotlib from scratch against your latest numpy version? > >-- Ed > >_______________________________________________ >Scipy-dev mailing list >Scipy-dev at scipy.net >http://www.scipy.net/mailman/listinfo/scipy-dev > Ed, I didn't recompile matplotlib - Now I have done that and the segfault vanished; sorry for the noise. Is it always necessary to recompile matplotlib ? Nils From schofield at ftw.at Wed Feb 15 10:59:18 2006 From: schofield at ftw.at (Ed Schofield) Date: Wed, 15 Feb 2006 16:59:18 +0100 Subject: [SciPy-dev] Segfault on 64 bit machine with latest svn In-Reply-To: <43F34D07.2000000@mecha.uni-stuttgart.de> References: <43F33742.1010000@mecha.uni-stuttgart.de> <43F34806.7020406@mecha.uni-stuttgart.de> <43F34C26.3080308@ftw.at> <43F34D07.2000000@mecha.uni-stuttgart.de> Message-ID: <43F34FD6.8060900@ftw.at> Nils Wagner wrote: >I didn't recompile matplotlib - Now I have done that and the segfault >vanished; sorry for the noise. > >Is it always necessary to recompile matplotlib ? > > Yes, at least until numpy has a stable binary interface. And I'd argue that this should not be a priority ;) -- Ed From oliphant.travis at ieee.org Wed Feb 15 13:27:33 2006 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Wed, 15 Feb 2006 11:27:33 -0700 Subject: [SciPy-dev] Segfault on 64 bit machine with latest svn In-Reply-To: <43F34D07.2000000@mecha.uni-stuttgart.de> References: <43F33742.1010000@mecha.uni-stuttgart.de> <43F34806.7020406@mecha.uni-stuttgart.de> <43F34C26.3080308@ftw.at> <43F34D07.2000000@mecha.uni-stuttgart.de> Message-ID: <43F37295.1020300@ieee.org> Nils Wagner wrote: >Ed Schofield wrote: > > >>Nils Wagner wrote: >> >> >> >> >>>It seems to be introduced in version 0.9.5.2109. >>>Here is a test code to reproduce the segfault >>> >>> >>> >>> >>> >>I'm not getting this. Are you sure you've recompiled scipy and >>matplotlib from scratch against your latest numpy version? >> >>-- Ed >> >>_______________________________________________ >>Scipy-dev mailing list >>Scipy-dev at scipy.net >>http://www.scipy.net/mailman/listinfo/scipy-dev >> >> >> >Ed, > >I didn't recompile matplotlib - Now I have done that and the segfault >vanished; sorry for the noise. > >Is it always necessary to recompile matplotlib ? > > > It should be necessary only when the NumPy C-API version number changes (which is fairly often at this point --- should slow down after the next release). There is now a check against this which should help diagnose these kinds of errors. -Travis From nwagner at mecha.uni-stuttgart.de Thu Feb 16 03:22:15 2006 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Thu, 16 Feb 2006 09:22:15 +0100 Subject: [SciPy-dev] A link to the Bug tracker on www.scipy.org Message-ID: <43F43637.6080205@mecha.uni-stuttgart.de> Hi all, I cannot find a link to a bug tracking system on www.scipy.org. Am I missing something ? Nils From robert.kern at gmail.com Thu Feb 16 03:26:20 2006 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 16 Feb 2006 02:26:20 -0600 Subject: [SciPy-dev] A link to the Bug tracker on www.scipy.org In-Reply-To: <43F43637.6080205@mecha.uni-stuttgart.de> References: <43F43637.6080205@mecha.uni-stuttgart.de> Message-ID: <43F4372C.5000500@gmail.com> Nils Wagner wrote: > Hi all, > > I cannot find a link to a bug tracking system on www.scipy.org. > Am I missing something ? http://www.scipy.org/Developer_Zone links to http://projects.scipy.org/scipy/scipy -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From nwagner at mecha.uni-stuttgart.de Thu Feb 16 03:48:18 2006 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Thu, 16 Feb 2006 09:48:18 +0100 Subject: [SciPy-dev] A link to the Bug tracker on www.scipy.org In-Reply-To: <43F4372C.5000500@gmail.com> References: <43F43637.6080205@mecha.uni-stuttgart.de> <43F4372C.5000500@gmail.com> Message-ID: <43F43C52.9010506@mecha.uni-stuttgart.de> Robert Kern wrote: >Nils Wagner wrote: > >>Hi all, >> >>I cannot find a link to a bug tracking system on www.scipy.org. >>Am I missing something ? >> > >http://www.scipy.org/Developer_Zone > > links to > >http://projects.scipy.org/scipy/scipy > > Robert, In my humble opinion it would be helpful to have an entry "Bug Tracker" on the home page like SciPy Documentation Mailing Lists Download snip Bug Tracker --> http://projects.scipy.org/scipy/scipy What is your opinion ? Nils From robert.kern at gmail.com Thu Feb 16 03:52:48 2006 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 16 Feb 2006 02:52:48 -0600 Subject: [SciPy-dev] A link to the Bug tracker on www.scipy.org In-Reply-To: <43F43C52.9010506@mecha.uni-stuttgart.de> References: <43F43637.6080205@mecha.uni-stuttgart.de> <43F4372C.5000500@gmail.com> <43F43C52.9010506@mecha.uni-stuttgart.de> Message-ID: <43F43D60.10203@gmail.com> Nils Wagner wrote: > In my humble opinion it would be helpful to have an entry "Bug Tracker" > on the home page > like > > SciPy > Documentation > Mailing Lists > Download > > snip > > Bug Tracker --> http://projects.scipy.org/scipy/scipy > > What is your opinion ? Other people seem to be finding it okay. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From nwagner at mecha.uni-stuttgart.de Thu Feb 16 04:02:39 2006 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Thu, 16 Feb 2006 10:02:39 +0100 Subject: [SciPy-dev] A link to the Bug tracker on www.scipy.org In-Reply-To: <43F43D60.10203@gmail.com> References: <43F43637.6080205@mecha.uni-stuttgart.de> <43F4372C.5000500@gmail.com> <43F43C52.9010506@mecha.uni-stuttgart.de> <43F43D60.10203@gmail.com> Message-ID: <43F43FAF.6050207@mecha.uni-stuttgart.de> Robert Kern wrote: >Nils Wagner wrote: > > >>In my humble opinion it would be helpful to have an entry "Bug Tracker" >>on the home page >>like >> >>SciPy >>Documentation >>Mailing Lists >>Download >> >>snip >> >>Bug Tracker --> http://projects.scipy.org/scipy/scipy >> >>What is your opinion ? >> > >Other people seem to be finding it okay. > > If you look at the title index http://www.scipy.org/TitleIndex you should find an entry for "Bugs" Nils From robert.kern at gmail.com Thu Feb 16 04:05:33 2006 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 16 Feb 2006 03:05:33 -0600 Subject: [SciPy-dev] A link to the Bug tracker on www.scipy.org In-Reply-To: <43F43FAF.6050207@mecha.uni-stuttgart.de> References: <43F43637.6080205@mecha.uni-stuttgart.de> <43F4372C.5000500@gmail.com> <43F43C52.9010506@mecha.uni-stuttgart.de> <43F43D60.10203@gmail.com> <43F43FAF.6050207@mecha.uni-stuttgart.de> Message-ID: <43F4405D.5000108@gmail.com> Nils Wagner wrote: > If you look at the title index > > http://www.scipy.org/TitleIndex > > you should find an entry for "Bugs" It's a Wiki. If you want a page named Bugs, go ahead and add a page named Bugs. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From nwagner at mecha.uni-stuttgart.de Thu Feb 16 09:08:21 2006 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Thu, 16 Feb 2006 15:08:21 +0100 Subject: [SciPy-dev] Sparse matrices and different types Message-ID: <43F48755.9090007@mecha.uni-stuttgart.de> I am confused by various types fname = 'cavity01.mtx.gz' A = io.mmread(gzip.open(fname)) >>> A <317x317 sparse matrix of type '' with 7280 stored elements (space for 7327) in Compressed Sparse Row format> >>> type(A) VT Vi Traceback (most recent call last): File "ggsl.py", line 116, in ? V,H,P = g_arnoldi(A,B,R0,n,s,k) File "ggsl.py", line 78, in g_arnoldi H[i,j] = trace(dot(Vi.transpose(),VT)) File "/usr/lib64/python2.4/site-packages/scipy/sparse/sparse.py", line 214, in __getattr__ raise AttributeError, attr + " not found" AttributeError: __float__ not found Is this a bug ? Nils From travis at enthought.com Thu Feb 16 14:17:08 2006 From: travis at enthought.com (Travis N. Vaught) Date: Thu, 16 Feb 2006 13:17:08 -0600 Subject: [SciPy-dev] ANN: Python Enthought Edition Version 0.9.2 Released Message-ID: <43F4CFB4.1080305@enthought.com> Enthought is pleased to announce the release of Python Enthought Edition Version 0.9.2 (http://code.enthought.com/enthon/) -- a python distribution for Windows. This is a kitchen-sink-included Python distribution including the following packages/tools out of the box: Numeric 24.2 SciPy 0.3.3 IPython 0.6.15 Enthought Tool Suite 1.0.2 wxPython 2.6.1.0 PIL 1.1.4 mingw 20030504-1 f2py 2.45.241_1926 MayaVi 1.5 Scientific Python 2.4.5 VTK 4.4 and many more... 0.9.2 Release Notes Summary --------------------------- Version 0.9.2 of Python Enthought Edition is the first to include the Enthought Tool Suite Package (http://code.enthought.com/ets/). Other changes include upgrading to Numeric 24.2, including MayaVi 1.5 (rather than 1.3) and removing a standalone PyCrust package in favor of the one included with wxPython. Also, elementtree and celementtree have been added to the distribution. Notably, this release is still based on Python 2.3.5 and still includes SciPy 0.3.3. You'll also notice that we have changed the version numbering to a major.minor.point format (from a build number format). see full release notes at: http://code.enthought.com/release/changelog-enthon0.9.2.shtml Best, Travis N. Vaught From nwagner at mecha.uni-stuttgart.de Fri Feb 17 03:03:04 2006 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Fri, 17 Feb 2006 09:03:04 +0100 Subject: [SciPy-dev] Problems with quadrature.py Message-ID: <43F58338.2070608@mecha.uni-stuttgart.de> m,abserr = integrate.quadrature(f,0.0,1.0,args=p) File "/usr/lib/python2.4/site-packages/scipy/integrate/quadrature.py", line 74, in quadrature newval = fixed_quad(vec_func,a,b,(func,)+args,n)[0] TypeError: unsupported operand type(s) for +: 'function' and 'int' Is this a bug ? Nils p[0] = 1 p[1] = 1 def f(x,p): return x**2*(1.0-0.5*x)**(p[0]+p[1]+2) From arnd.baecker at web.de Fri Feb 17 06:36:03 2006 From: arnd.baecker at web.de (Arnd Baecker) Date: Fri, 17 Feb 2006 12:36:03 +0100 (CET) Subject: [SciPy-dev] A wiki question on user pages In-Reply-To: <43EE3A17.4000702@colorado.edu> References: <43EE3A17.4000702@colorado.edu> Message-ID: On Sat, 11 Feb 2006, Fernando Perez wrote: > Hi all, > > I was wondering if it would be a good idea to make a few broad categories on > the wiki, so that all the WikiNames aren't purely top-level. In particular, > user pages seem like a good candidate for a users/ directory to exist. So > far, I'm aware of these two (there may be more) > > http://scipy.org/ArndBaecker > http://scipy.org/PearuPeterson > > It might be nicer to have them under > > http://scipy.org/users/ArndBaecker > http://scipy.org/users/PearuPeterson +1 from me for this! > no? This would also make it easier to have a users/Index page listing all > existing user pages (there's probably a Moin macro that can do that > automatically). There are these Categories, http://www.scipy.org/CategoryHomepage When editing a page you can make it belong to some category. Still I agree that a slightly more hierarchical structure would help a lot. > For Trac wikis I know this kind of organization is possible, it may also be > the case for Moin. > > I'm not advocating a 12-levels-deep structure, but at least a few categories like > > users/ > doc/ > cookbook/ > > might help keep the wiki sanely organized for the long run. Thoughts? I absolutely agree. In addition, I find it very confusing to have http://www.scipy.org/wikis/topical_software/Tutorial but neither http://www.scipy.org/wikis/topical_software/ nor http://www.scipy.org/wikis/ exist? Also one could think of putting projects which have many pages into a subtree (for example all http://www.scipy.org/AstroLib related pages) BTW, what is the local site map "http://www.scipy.org/?action=LocalSiteMap" supposed to show? Without any background knowledge I thought that it would display all pages, but that does not seem to be the case. Also, pages like http://www.scipy.org/NumPy_Tutorial?action=LocalSiteMap look confusing to me (why, for example, is "SciPy [view]" part of this?). Am I missing something obvious about this? Best, Arnd P.S.: And now I know, why I recently claimed to have found no options to attach a file to a page: After a search ("baecker" in my case) you get http://www.scipy.org/ArndBaecker?highlight=%28baecker%29 and then there the "More actions" menu only shows "Show Raw Text"/"Show Print View" ;-) From travis at enthought.com Fri Feb 17 11:45:17 2006 From: travis at enthought.com (Travis N. Vaught) Date: Fri, 17 Feb 2006 10:45:17 -0600 Subject: [SciPy-dev] [Numpy-discussion] ANN: Python Enthought Edition Version 0.9.2 Released In-Reply-To: References: <43F4CFB4.1080305@enthought.com> Message-ID: <43F5FD9D.2090706@enthought.com> Arnd Baecker wrote: > On Thu, 16 Feb 2006, Travis N. Vaught wrote: > > >> Enthought is pleased to announce the release of Python Enthought Edition >> Version 0.9.2 (http://code.enthought.com/enthon/) -- a python >> distribution for Windows. This is a kitchen-sink-included Python >> distribution including the following packages/tools out of the box: >> >> Numeric 24.2 >> SciPy 0.3.3 >> IPython 0.6.15 >> Enthought Tool Suite 1.0.2 >> wxPython 2.6.1.0 >> PIL 1.1.4 >> mingw 20030504-1 >> f2py 2.45.241_1926 >> MayaVi 1.5 >> Scientific Python 2.4.5 >> VTK 4.4 >> and many more... >> > > Brilliant - many thanks for the effort! > > I was just about to ask for the plans about numpy/scipy, > but the changelog at > http://code.enthought.com/release/changelog-enthon0.9.2.shtml > shows quite a bit of activity in this direction! > > Do you have an estimate about when a numpy/scipy version > of the Enthought Edition might happen? > > Many thanks, > > Arnd > It's a bit difficult to say with much accuracy, so I'll be transparent but imprecise. Our release of Enthon versions typically tracks the state of the platform we are using for the custom software development we do to pay the bills. Thus, our current project code typically has to be ported to build and run on a cobbled-together build of the newer versions before we do a release. I realize this is a drag on the release schedule for Enthon, but it's how we allocate resources to the builds. Enough excuses, though--we are working on the migration of our project code now (Pearu Peterson) and I expect in weeks (rather than months) we'll have an Enthon release candidate with Python 2.4.2, and the latest SciPy and NumPy on Windows. Robert Kern is already working on a project that is based on this tool chain, so the wedge is in place. Thanks for the interest! (and sorry for the cross-post) Travis From mmetz at astro.uni-bonn.de Mon Feb 20 03:28:29 2006 From: mmetz at astro.uni-bonn.de (Manuel Metz) Date: Mon, 20 Feb 2006 09:28:29 +0100 Subject: [SciPy-dev] Kuipers statistics Message-ID: <43F97DAD.1010905@astro.uni-bonn.de> Hi, I have attached a patch for the file /Lib/special/cephes/kolmogorov.c. This patch adds a function 'kuiper(y)' which is very similar to the function 'kolmogorov(y)', which is required for the K-S-Test. Kuipers statistics is a variant of K-S statistics which is invariant on a circle. I did not write an inverse function yet (is't not monotonic in it's first derivative) and also did not include patches for the corresponding .py files. Is there any interest to include the Kuiper statistics into SciPy ??? Manuel -------------- next part -------------- A non-text attachment was scrubbed... Name: kolmogorov.patch Type: text/x-patch Size: 986 bytes Desc: not available URL: From arnd.baecker at web.de Mon Feb 20 06:11:08 2006 From: arnd.baecker at web.de (Arnd Baecker) Date: Mon, 20 Feb 2006 12:11:08 +0100 (CET) Subject: [SciPy-dev] wiki and attachments Message-ID: Moin, for a new set of pages on MayaVi2/tvtk I wanted to upload some files, but I did this with a wrong path. So I ended up with two empty files vis_quad.png simple_tvtk_cone.py at http://www.scipy.org/Cookbook/MayaVi/tvtk?action=info but I am not allowed to either delete or replace them. Is there some way to replace those files? In general: would it technically be possible that page creators are automatically added to the list of people which are allowed to delete attachments for those pages? (or does MoinMoin not allow such fine-grained access control?). This might make updating of attachments easier. Sorry about that, Arnd From mmetz at astro.uni-bonn.de Mon Feb 20 08:10:46 2006 From: mmetz at astro.uni-bonn.de (Manuel Metz) Date: Mon, 20 Feb 2006 14:10:46 +0100 Subject: [SciPy-dev] Numerical Message-ID: <43F9BFD6.1000009@astro.uni-bonn.de> Hi, I know that development of Numeric has ceased and we should switch to numpy. Nevertheless there will be some code around which still uses Numeric, maybe for some years. Therefore: I found a memory leak in Numeric 24.2. I noticed it on Windows and Linux (Debian). The following code consumes lots of memory which it should not do !!! from Numeric import * for i in xrange(1000000): a = array( [1,2,3] ) b = a.tolist() # <- here seams to be the memory leak Could anyone fix that !? PLEASE ! Manuel From strawman at astraw.com Mon Feb 20 12:52:54 2006 From: strawman at astraw.com (Andrew Straw) Date: Mon, 20 Feb 2006 09:52:54 -0800 Subject: [SciPy-dev] wiki and attachments In-Reply-To: References: Message-ID: <43FA01F6.5050300@astraw.com> Hi Arnd, I added you to http://scipy.org/EditorsGroup That should allow you to delete attachments (all over the wiki). Can you tell me if it doesn't work for some reason? Arnd Baecker wrote: >Moin, > >for a new set of pages on MayaVi2/tvtk I wanted to >upload some files, but I did this with a wrong path. >So I ended up with two empty files > vis_quad.png > simple_tvtk_cone.py >at http://www.scipy.org/Cookbook/MayaVi/tvtk?action=info >but I am not allowed to either delete or replace them. > >Is there some way to replace those files? > >In general: would it technically be possible that >page creators are automatically >added to the list of people which are allowed to delete >attachments for those pages? >(or does MoinMoin not allow such fine-grained access control?). >This might make updating of attachments easier. > >Sorry about that, > >Arnd > > >_______________________________________________ >Scipy-dev mailing list >Scipy-dev at scipy.net >http://www.scipy.net/mailman/listinfo/scipy-dev > > From sebastien.dementen at alumni.insead.edu Mon Feb 20 22:14:07 2006 From: sebastien.dementen at alumni.insead.edu (DE MENTEN Sebastien) Date: Tue, 21 Feb 2006 11:14:07 +0800 Subject: [SciPy-dev] integration of Unum in scipy Message-ID: <521836FA9A33D147A2C81D0B95480CA7018618C7@MEDUSA3.SGP.insead.intra> Hi, I discovered one year ago Unum (http://home.tiscali.be/be052320/Unum.html), a very useful python package to deal with units (i.e. kg, MW, kV, ...). I subsequently used it in a power plant model where I could manipulate (+,-,/,* + conversion) various quantities like fuel (GJ), power (MW, MWh), efficiencies (MWh/GJ), half-life (hour) in a robust (ie consistent an error-free) way. One weakness at that time was its integration with Numeric. Using functions such as sum, cumsum & co on Unum objects was not giving the ideal result. Today, with the added capabilities of ufuncs (namely array_wrap) this problem vanishes. Hence, it could make sense to integrate it nicely with scipy. Any thought? Seb -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.kern at gmail.com Mon Feb 20 22:30:39 2006 From: robert.kern at gmail.com (Robert Kern) Date: Mon, 20 Feb 2006 21:30:39 -0600 Subject: [SciPy-dev] integration of Unum in scipy In-Reply-To: <521836FA9A33D147A2C81D0B95480CA7018618C7@MEDUSA3.SGP.insead.intra> References: <521836FA9A33D147A2C81D0B95480CA7018618C7@MEDUSA3.SGP.insead.intra> Message-ID: <43FA895F.3030800@gmail.com> DE MENTEN Sebastien wrote: > Hi, > > I discovered one year ago Unum > (http://home.tiscali.be/be052320/Unum.html), a very useful python > package to deal with units (i.e. kg, MW, kV, ?). > > I subsequently used it in a power plant model where I could manipulate > (+,-,/,* + conversion) various quantities like fuel (GJ), power (MW, > MWh), efficiencies (MWh/GJ), half-life (hour) in a robust (ie consistent > an error-free) way. > > One weakness at that time was its integration with Numeric. Using > functions such as sum, cumsum & co on Unum objects was not giving the > ideal result. Today, with the added capabilities of ufuncs (namely > array_wrap) this problem vanishes. Well, I wouldn't say that the problem "vanishes" so much as "maybe becomes tractable." Only experience will tell how tractable. > Hence, it could make sense to integrate it nicely with scipy. It would certainly be nice for Unum to be able to handle numpy arrays well. However, we cannot accept Unum into scipy since it is GPLed. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From sebastien.dementen at alumni.insead.edu Mon Feb 20 23:30:05 2006 From: sebastien.dementen at alumni.insead.edu (DE MENTEN Sebastien) Date: Tue, 21 Feb 2006 12:30:05 +0800 Subject: [SciPy-dev] integration of Unum in scipy Message-ID: <521836FA9A33D147A2C81D0B95480CA70186194B@MEDUSA3.SGP.insead.intra> > > One weakness at that time was its integration with Numeric. Using > > functions such as sum, cumsum & co on Unum objects was not giving the > > ideal result. Today, with the added capabilities of ufuncs (namely > > array_wrap) this problem vanishes. > > Well, I wouldn't say that the problem "vanishes" so much as "maybe becomes > tractable." Only experience will tell how tractable. > At least, the point (my personal Unumeric showstopper) which bothered me really vanished :) > > Hence, it could make sense to integrate it nicely with scipy. > > It would certainly be nice for Unum to be able to handle numpy arrays > well. > However, we cannot accept Unum into scipy since it is GPLed. I think the author (Pierre Denis) could change his mind and the license as he does not feel too strong about it (it was more a default choice if I remember correctly). Anyway, in case of positive answer I will ask him permission for both the integration and the license change. The question is more about a formal integration in scipy: a) The code is mature, clearly written and not huge (engine code is 600 loc and unit definitions code is 1 loc per unit). Its integration should not be a big deal. b) The package nicely fills a gap in the scientific toolkit. Hence, is the license the only problem? Seb From robert.kern at gmail.com Tue Feb 21 00:20:15 2006 From: robert.kern at gmail.com (Robert Kern) Date: Mon, 20 Feb 2006 23:20:15 -0600 Subject: [SciPy-dev] integration of Unum in scipy In-Reply-To: <521836FA9A33D147A2C81D0B95480CA70186194B@MEDUSA3.SGP.insead.intra> References: <521836FA9A33D147A2C81D0B95480CA70186194B@MEDUSA3.SGP.insead.intra> Message-ID: <43FAA30F.4040502@gmail.com> DE MENTEN Sebastien wrote: > I think the author (Pierre Denis) could change his mind and the license > as he does not feel too strong about it (it was more a default choice if > I remember correctly). Anyway, in case of positive answer I will ask him > permission for both the integration and the license change. > > The question is more about a formal integration in scipy: > a) The code is mature, clearly written and not huge (engine code is 600 > loc and unit definitions code is 1 loc per unit). Its integration should > not be a big deal. > b) The package nicely fills a gap in the scientific toolkit. > > Hence, is the license the only problem? Somewhat. Personally, I have Issues with all existing unit packages mostly summarized by how they handle (or don't handle) temperatures. We've discussed this before. Start here: http://www.scipy.net/pipermail/scipy-user/2005-March/004263.html The package that probably gets it right is enthought.units (disclosure: I work for Enthought). It is an extended version of Michael Aivazis' pyre.units package which implements some logic for intelligently handling temperature scales among lots of other things. OTOH, I haven't reviewed it thoroughly or used it in anger. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From schofield at ftw.at Tue Feb 21 06:05:18 2006 From: schofield at ftw.at (Ed Schofield) Date: Tue, 21 Feb 2006 12:05:18 +0100 Subject: [SciPy-dev] Kuipers statistics In-Reply-To: <43F97DAD.1010905@astro.uni-bonn.de> References: <43F97DAD.1010905@astro.uni-bonn.de> Message-ID: <43FAF3EE.2020408@ftw.at> Manuel Metz wrote: >Hi, >I have attached a patch for the file /Lib/special/cephes/kolmogorov.c. >This patch adds a function 'kuiper(y)' which is very similar to the >function 'kolmogorov(y)', which is required for the K-S-Test. Kuipers >statistics is a variant of K-S statistics which is invariant on a circle. > >I did not write an inverse function yet (is't not monotonic in it's >first derivative) and also did not include patches for the corresponding >.py files. > >Is there any interest to include the Kuiper statistics into SciPy ??? > > Thanks for the patch! I don't know much about this field, but I suspect we'd be glad to include it. I'm not sure which directory the function should go in, since it's not part of the cephes library. Perhaps Lib/special/c_misc/? -- Ed From arnd.baecker at web.de Tue Feb 21 06:39:18 2006 From: arnd.baecker at web.de (Arnd Baecker) Date: Tue, 21 Feb 2006 12:39:18 +0100 (CET) Subject: [SciPy-dev] wiki and attachments In-Reply-To: <43FA01F6.5050300@astraw.com> References: <43FA01F6.5050300@astraw.com> Message-ID: Hi Andrew, On Mon, 20 Feb 2006, Andrew Straw wrote: > Hi Arnd, I added you to http://scipy.org/EditorsGroup > > That should allow you to delete attachments (all over the wiki). ok, I will handle that with care ... ;-) > Can you > tell me if it doesn't work for some reason? Works fine - many thanks! Arnd From fonnesbeck at gmail.com Tue Feb 21 10:09:27 2006 From: fonnesbeck at gmail.com (Chris Fonnesbeck) Date: Tue, 21 Feb 2006 10:09:27 -0500 Subject: [SciPy-dev] static builds of scipy Message-ID: <723eb6930602210709p24fc06f2vc82f233a66fdaf47@mail.gmail.com> What is the proper way to build scipy statically? I tried the following syntax (which works for numpy): LDFLAGS=-L/usr/local/lib python setup.py build But this does not build with the LDFLAG variable specified: /usr/local/bin/g77 -L/usr/local/lib build/temp.darwin-8.5.0-Power_Macintosh-2.4/build/src/Lib/fftpack/_fftpackmodule.o build/temp.darwin-8.5.0-Power_Macintosh-2.4/Lib/fftpack/src/zfft.o build/temp.darwin-8.5.0-Power_Macintosh-2.4/Lib/fftpack/src/drfft.o build/temp.darwin-8.5.0-Power_Macintosh-2.4/Lib/fftpack/src/zrfft.o build/temp.darwin-8.5.0-Power_Macintosh-2.4/Lib/fftpack/src/zfftnd.o build/temp.darwin-8.5.0-Power_Macintosh-2.4/build/src/fortranobject.o -L/usr/local/lib -L/usr/local/lib/gcc/powerpc-apple-darwin7.9.0/3.4.4 -Lbuild/temp.darwin-8.5.0-Power_Macintosh-2.4 -ldfftpack -lfftw3 -lg2c -lcc_dynamic -o build/lib.darwin-8.5.0-Power_Macintosh-2.4/scipy/fftpack/_fftpack.so -lSystemStubs /usr/bin/ld: Undefined symbols: _PyArg_ParseTupleAndKeywords _PyCObject_AsVoidPtr _PyCObject_Type _PyComplex_Type _PyDict_SetItemString _PyErr_Clear _PyErr_Format _PyErr_NewException _PyErr_Occurred _PyErr_SetString _PyExc_RuntimeError _PyImport_ImportModule _PyInt_Type _PyModule_GetDict _PyNumber_Int _PyObject_GetAttrString _PySequence_Check _PySequence_GetItem _PyString_FromString _PyString_Type _PyType_IsSubtype _PyType_Type _Py_BuildValue _Py_FatalError _Py_InitModule4 __Py_NoneStruct _PyCObject_FromVoidPtr _PyDict_DelItemString _PyDict_GetItemString _PyDict_New _PyExc_AttributeError _PyExc_TypeError _PyExc_ValueError _PyObject_Free _PyObject_Str _PyObject_Type _PyString_AsString _PyString_ConcatAndDel _Py_FindMethod __PyObject_New _MAIN__ collect2: ld returned 1 exit status /usr/bin/ld: Undefined symbols: _PyArg_ParseTupleAndKeywords _PyCObject_AsVoidPtr _PyCObject_Type _PyComplex_Type _PyDict_SetItemString _PyErr_Clear _PyErr_Format _PyErr_NewException _PyErr_Occurred _PyErr_SetString _PyExc_RuntimeError _PyImport_ImportModule _PyInt_Type _PyModule_GetDict _PyNumber_Int _PyObject_GetAttrString _PySequence_Check _PySequence_GetItem _PyString_FromString _PyString_Type _PyType_IsSubtype _PyType_Type _Py_BuildValue _Py_FatalError _Py_InitModule4 __Py_NoneStruct _PyCObject_FromVoidPtr _PyDict_DelItemString _PyDict_GetItemString _PyDict_New _PyExc_AttributeError _PyExc_TypeError _PyExc_ValueError _PyObject_Free _PyObject_Str _PyObject_Type _PyString_AsString _PyString_ConcatAndDel _Py_FindMethod __PyObject_New _MAIN__ collect2: ld returned 1 exit status error: Command "/usr/local/bin/g77 -L/usr/local/lib build/temp.darwin-8.5.0-Power_Macintosh-2.4/build/src/Lib/fftpack/_fftpackmodule.o build/temp.darwin-8.5.0-Power_Macintosh-2.4/Lib/fftpack/src/zfft.o build/temp.darwin-8.5.0-Power_Macintosh-2.4/Lib/fftpack/src/drfft.o build/temp.darwin-8.5.0-Power_Macintosh-2.4/Lib/fftpack/src/zrfft.o build/temp.darwin-8.5.0-Power_Macintosh-2.4/Lib/fftpack/src/zfftnd.o build/temp.darwin-8.5.0-Power_Macintosh-2.4/build/src/fortranobject.o -L/usr/local/lib -L/usr/local/lib/gcc/powerpc-apple-darwin7.9.0/3.4.4 -Lbuild/temp.darwin-8.5.0-Power_Macintosh-2.4 -ldfftpack -lfftw3 -lg2c -lcc_dynamic -o build/lib.darwin-8.5.0-Power_Macintosh-2.4/scipy/fftpack/_fftpack.so -lSystemStubs" failed with exit status 1 Any pointers most appreciated. C. -- Chris Fonnesbeck + Atlanta, GA + http://trichech.us From sebastien.dementen at alumni.insead.edu Tue Feb 21 11:42:33 2006 From: sebastien.dementen at alumni.insead.edu (DE MENTEN Sebastien) Date: Wed, 22 Feb 2006 00:42:33 +0800 Subject: [SciPy-dev] integration of Unum in scipy Message-ID: <521836FA9A33D147A2C81D0B95480CA701861F8D@MEDUSA3.SGP.insead.intra> > Somewhat. Personally, I have Issues with all existing unit packages mostly > summarized by how they handle (or don't handle) temperatures. We've > discussed > this before. Start here: > > http://www.scipy.net/pipermail/scipy-user/2005-March/004263.html > I share your view expressed in http://www.scipy.net/pipermail/scipy-user/2005-March/004266.html (absolute temperature translation is not a unit conversion). However, after looking at the implementation in enthought.units, I have two questions: 1) Is the dependence on the rest of enthough framework (e.g. traits) easily replaced/removed? 2) Am I right in saying that the system is tight to the SI? Are the 7 physical unit dimensions hardcoded? Is it possible to add exotic system of units (e.g. currencies)? Unum provides an engine that enables the creation of units (m,kg,...) as well as unum objects (3 m/s, [3,6,7] kg,...). In this regard, it looks more generic than enthought.units. Finally, do you have feedback on people using this module in enthought? Best, Seb From travis at enthought.com Tue Feb 21 11:58:27 2006 From: travis at enthought.com (Travis N. Vaught) Date: Tue, 21 Feb 2006 10:58:27 -0600 Subject: [SciPy-dev] integration of Unum in scipy In-Reply-To: <521836FA9A33D147A2C81D0B95480CA701861F8D@MEDUSA3.SGP.insead.intra> References: <521836FA9A33D147A2C81D0B95480CA701861F8D@MEDUSA3.SGP.insead.intra> Message-ID: <43FB46B3.50008@enthought.com> DE MENTEN Sebastien wrote: >> Somewhat. Personally, I have Issues with all existing unit packages >> > mostly > >> summarized by how they handle (or don't handle) temperatures. We've >> discussed >> this before. Start here: >> >> http://www.scipy.net/pipermail/scipy-user/2005-March/004263.html >> >> > > I share your view expressed in > http://www.scipy.net/pipermail/scipy-user/2005-March/004266.html > (absolute temperature translation is not a unit conversion). However, > after looking at the implementation in enthought.units, I have two > questions: > 1) Is the dependence on the rest of enthough framework (e.g. traits) > easily replaced/removed? > 2) Am I right in saying that the system is tight to the SI? Are the 7 > physical unit dimensions hardcoded? Is it possible to add exotic system > of units (e.g. currencies)? > > Unum provides an engine that enables the creation of units (m,kg,...) as > well as unum objects (3 m/s, [3,6,7] kg,...). In this regard, it looks > more generic than enthought.units. > > Finally, do you have feedback on people using this module in enthought? > > Best, > > Seb > > Seb, The ties to traits, etc., _should_ all be optional. The base package (units.unit) is usable in a very stand-alone way. It is correct that the system is "tight to the SI" -- you'd have to derive a class or modify the core functionality to extend for things like currency. For "quantities" we typically use the quantity module, which allows for a composite object that has 'data' and 'units' where data can be a float, or an array (or other sequence) of floats. This was to enable the performance gains of dealing with math on arrays of floats rather than an array of unit objects. There is much more in the overall package which handles both Unit Systems and, orthogonally, some style information (default ranges, plotting styles, etc.) that is completely optional. As far as feedback goes, the core units package is very trouble-free for us--we haven't had to do much to the code in a while for it to perform for us. On the other hand, the total package sees quite a bit of tweaking and cajoling to get it integrated into applications in the way we want with the performance we want. HTH, Travis -- ........................ Travis N. Vaught CEO Enthought, Inc. http://www.enthought.com ........................ From robert.kern at gmail.com Tue Feb 21 12:50:59 2006 From: robert.kern at gmail.com (Robert Kern) Date: Tue, 21 Feb 2006 11:50:59 -0600 Subject: [SciPy-dev] static builds of scipy In-Reply-To: <723eb6930602210709p24fc06f2vc82f233a66fdaf47@mail.gmail.com> References: <723eb6930602210709p24fc06f2vc82f233a66fdaf47@mail.gmail.com> Message-ID: <43FB5303.3070800@gmail.com> Chris Fonnesbeck wrote: > What is the proper way to build scipy statically? I tried the > following syntax (which works for numpy): > > LDFLAGS=-L/usr/local/lib python setup.py build python setup.py build_ext -L/usr/local/lib build -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From sebastien.dementen at alumni.insead.edu Tue Feb 21 12:51:24 2006 From: sebastien.dementen at alumni.insead.edu (DE MENTEN Sebastien) Date: Wed, 22 Feb 2006 01:51:24 +0800 Subject: [SciPy-dev] integration of Unum in scipy Message-ID: <521836FA9A33D147A2C81D0B95480CA701862005@MEDUSA3.SGP.insead.intra> > Seb, > > The ties to traits, etc., _should_ all be optional. The base package > (units.unit) is usable in a very stand-alone way. It is correct that > the system is "tight to the SI" -- you'd have to derive a class or > modify the core functionality to extend for things like currency. > > For "quantities" we typically use the quantity module, which allows for > a composite object that has 'data' and 'units' where data can be a > float, or an array (or other sequence) of floats. This was to enable > the performance gains of dealing with math on arrays of floats rather > than an array of unit objects. Was it specifically targeted at Numeric integration (i.e. is it the same kind of problem I bumped into with Unum)? If it is, then with wrap_array functionality from numpy, this is not necessary anymore. Hence, I would favor I lighter approach (no redundant "quantity" concept). > There is much more in the overall package which handles both Unit > Systems and, orthogonally, some style information (default ranges, > plotting styles, etc.) that is completely optional. > > As far as feedback goes, the core units package is very trouble-free for > us--we haven't had to do much to the code in a while for it to perform > for us. On the other hand, the total package sees quite a bit of > tweaking and cajoling to get it integrated into applications in the way > we want with the performance we want. (see above for performance with arrays) About feedback, I had something else in mind that the question you answered. Do you have users who sends you questions, congratulations or criticisms or who recommend the package to others? i.e. are there "real" users of the package outside Enthought? Best, Seb From travis at enthought.com Tue Feb 21 14:48:33 2006 From: travis at enthought.com (Travis N. Vaught) Date: Tue, 21 Feb 2006 13:48:33 -0600 Subject: [SciPy-dev] integration of Unum in scipy In-Reply-To: <521836FA9A33D147A2C81D0B95480CA701862005@MEDUSA3.SGP.insead.intra> References: <521836FA9A33D147A2C81D0B95480CA701862005@MEDUSA3.SGP.insead.intra> Message-ID: <43FB6E91.1010305@enthought.com> DE MENTEN Sebastien wrote: > ... > About feedback, I had something else in mind that the question you > answered. Do you have users who sends you questions, congratulations or > criticisms or who recommend the package to others? i.e. are there "real" > users of the package outside Enthought? > We have not heard of usage outside Enthought. It has only been available as a packaged release (part of ETS) since December (and lightly publicized at that), though we've been using it internally for quite some time (~2 years for units, ~6 months in its current form under the enthought.units package). Travis From nwagner at mecha.uni-stuttgart.de Wed Feb 22 06:58:28 2006 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Wed, 22 Feb 2006 12:58:28 +0100 Subject: [SciPy-dev] scipy.test(1,10) results in 11 errors Message-ID: <43FC51E4.3010400@mecha.uni-stuttgart.de> AttributeError: 'module' object has no attribute 'hmean' AttributeError: 'module' object has no attribute 'mode' NameError: global name 'logsumexp' is not defined Ran 1011 tests in 1.862s FAILED (errors=11) Can someone reproduce these errors ? Nils From fonnesbeck at gmail.com Wed Feb 22 11:02:35 2006 From: fonnesbeck at gmail.com (Chris Fonnesbeck) Date: Wed, 22 Feb 2006 11:02:35 -0500 Subject: [SciPy-dev] static builds of scipy In-Reply-To: <43FB5303.3070800@gmail.com> References: <723eb6930602210709p24fc06f2vc82f233a66fdaf47@mail.gmail.com> <43FB5303.3070800@gmail.com> Message-ID: <723eb6930602220802x37306740ld82dc4b88c189bf9@mail.gmail.com> On 2/21/06, Robert Kern wrote: > Chris Fonnesbeck wrote: > > What is the proper way to build scipy statically? I tried the > > following syntax (which works for numpy): > > > > LDFLAGS=-L/usr/local/lib python setup.py build > > python setup.py build_ext -L/usr/local/lib build > Any idea why I might be getting the following error while trying a static build (doesnt occur when I do not specify the build_ext argument): gcc options: '-fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fPIC -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-prototypes' compile options: '-DSCIPY_FFTW3_H -I/usr/local/include -Ibuild/src -I/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/numpy/core/include -I/Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 -c' /usr/local/bin/g77 -undefined dynamic_lookup -bundle build/temp.darwin-8.5.0-Power_Macintosh-2.4/build/src/Lib/fftpack/_fftpackmodule.o build/temp.darwin-8.5.0-Power_Macintosh-2.4/Lib/fftpack/src/zfft.o build/temp.darwin-8.5.0-Power_Macintosh-2.4/Lib/fftpack/src/drfft.o build/temp.darwin-8.5.0-Power_Macintosh-2.4/Lib/fftpack/src/zrfft.o build/temp.darwin-8.5.0-Power_Macintosh-2.4/Lib/fftpack/src/zfftnd.o build/temp.darwin-8.5.0-Power_Macintosh-2.4/build/src/fortranobject.o -L/usr/local/lib -L/usr/local/lib/gcc/powerpc-apple-darwin7.9.0/3.4.4 -L/usr/local/lib -Lbuild/temp.darwin-8.5.0-Power_Macintosh-2.4 -ldfftpack -lfftw3 -lg2c -lcc_dynamic -o build/lib.darwin-8.5.0-Power_Macintosh-2.4/scipy/fftpack/_fftpack.so -lSystemStubs /usr/bin/ld: can't locate file for: -ldfftpack collect2: ld returned 1 exit status /usr/bin/ld: can't locate file for: -ldfftpack collect2: ld returned 1 exit status error: Command "/usr/local/bin/g77 -undefined dynamic_lookup -bundle build/temp.darwin-8.5.0-Power_Macintosh-2.4/build/src/Lib/fftpack/_fftpackmodule.o build/temp.darwin-8.5.0-Power_Macintosh-2.4/Lib/fftpack/src/zfft.o build/temp.darwin-8.5.0-Power_Macintosh-2.4/Lib/fftpack/src/drfft.o build/temp.darwin-8.5.0-Power_Macintosh-2.4/Lib/fftpack/src/zrfft.o build/temp.darwin-8.5.0-Power_Macintosh-2.4/Lib/fftpack/src/zfftnd.o build/temp.darwin-8.5.0-Power_Macintosh-2.4/build/src/fortranobject.o -L/usr/local/lib -L/usr/local/lib/gcc/powerpc-apple-darwin7.9.0/3.4.4 -L/usr/local/lib -Lbuild/temp.darwin-8.5.0-Power_Macintosh-2.4 -ldfftpack -lfftw3 -lg2c -lcc_dynamic -o build/lib.darwin-8.5.0-Power_Macintosh-2.4/scipy/fftpack/_fftpack.so -lSystemStubs" failed with exit status 1 -- Chris Fonnesbeck + Atlanta, GA + http://trichech.us From robert.kern at gmail.com Wed Feb 22 12:34:08 2006 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 22 Feb 2006 11:34:08 -0600 Subject: [SciPy-dev] static builds of scipy In-Reply-To: <723eb6930602220802x37306740ld82dc4b88c189bf9@mail.gmail.com> References: <723eb6930602210709p24fc06f2vc82f233a66fdaf47@mail.gmail.com> <43FB5303.3070800@gmail.com> <723eb6930602220802x37306740ld82dc4b88c189bf9@mail.gmail.com> Message-ID: <43FCA090.5020901@gmail.com> Chris Fonnesbeck wrote: > On 2/21/06, Robert Kern wrote: > >>Chris Fonnesbeck wrote: >> >>>What is the proper way to build scipy statically? I tried the >>>following syntax (which works for numpy): >>> >>>LDFLAGS=-L/usr/local/lib python setup.py build >> >>python setup.py build_ext -L/usr/local/lib build >> > > > Any idea why I might be getting the following error while trying a > static build (doesnt occur when I do not specify the build_ext > argument): > > gcc options: '-fno-strict-aliasing -Wno-long-double -no-cpp-precomp > -mno-fused-madd -fPIC -fno-common -dynamic -DNDEBUG -g -O3 -Wall > -Wstrict-prototypes' > compile options: '-DSCIPY_FFTW3_H -I/usr/local/include -Ibuild/src > -I/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/numpy/core/include > -I/Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 > -c' > /usr/local/bin/g77 -undefined dynamic_lookup -bundle > build/temp.darwin-8.5.0-Power_Macintosh-2.4/build/src/Lib/fftpack/_fftpackmodule.o > build/temp.darwin-8.5.0-Power_Macintosh-2.4/Lib/fftpack/src/zfft.o > build/temp.darwin-8.5.0-Power_Macintosh-2.4/Lib/fftpack/src/drfft.o > build/temp.darwin-8.5.0-Power_Macintosh-2.4/Lib/fftpack/src/zrfft.o > build/temp.darwin-8.5.0-Power_Macintosh-2.4/Lib/fftpack/src/zfftnd.o > build/temp.darwin-8.5.0-Power_Macintosh-2.4/build/src/fortranobject.o > -L/usr/local/lib -L/usr/local/lib/gcc/powerpc-apple-darwin7.9.0/3.4.4 > -L/usr/local/lib -Lbuild/temp.darwin-8.5.0-Power_Macintosh-2.4 > -ldfftpack -lfftw3 -lg2c -lcc_dynamic -o > build/lib.darwin-8.5.0-Power_Macintosh-2.4/scipy/fftpack/_fftpack.so > -lSystemStubs > /usr/bin/ld: can't locate file for: -ldfftpack > collect2: ld returned 1 exit status The dependency handling between numpy.distutils commands is not the greatest. Sometimes you have to specify all of the intermediate commands. For example, all of my build lines look like this (any other commands being elided by ...): $ python setup.py ... build_src build_clib build_ext build ... In particular, you are missing the build_clib command which will build libdfftpack.a for you. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From cimrman3 at ntc.zcu.cz Thu Feb 23 06:46:48 2006 From: cimrman3 at ntc.zcu.cz (Robert Cimrman) Date: Thu, 23 Feb 2006 12:46:48 +0100 Subject: [SciPy-dev] system_info problem Message-ID: <43FDA0A8.6020105@ntc.zcu.cz> Hi, I am trying to (finally) move UMFPACK out of the sandbox to the scipy proper and so I need checking for its libraries via system_info.py of numpy distutils. I have added a new section to site.cfg: [umfpack] library_dirs = /home/share/software/packages/UMFPACK/UMFPACK/Lib:/home/share/software/packages/UMFPACK/AMD/Lib include_dirs = /home/share/software/packages/UMFPACK/UMFPACK/Include umfpack_libs = umfpack, amd the names of the libraries are libumfpack.a, libamd.a - they are correctly found in 'system_info._check_libs()' by 'self._lib_list(lib_dir, libs, exts)', but then the function fails, since 'len(found_libs) == len(libs)' which is wrong. Can some numpy.distutils expert help me? Below is the new umfpack_info class I have written using the blas_info class as template. yours clueless, r. PS: I do this because I prefer having the umfpack installed separately. It will be used, if present, to replace the default superLU-based sparse solver. Moving its sources under scipy/Lib/sparse would solve this issue, but Tim Davis recently changed the license of UMFPACK to GPL, and so the last version available for the direct inclusion is 4.4. (4.6 is the current one). Opinions are of course welcome. -- class umfpack_info(system_info): section = 'umfpack' dir_env_var = 'UMFPACK' _lib_names = ['umfpack', 'amd'] includes = 'umfpack.h' notfounderror = UmfpackNotFoundError def calc_info(self): info = {} lib_dirs = self.get_lib_dirs() print lib_dirs umfpack_libs = self.get_libs('umfpack_libs', self._lib_names) print umfpack_libs for d in lib_dirs: libs = self.check_libs(d,umfpack_libs,[]) print d, libs if libs is not None: dict_append(info,libraries=libs) break else: return include_dirs = self.get_include_dirs() print include_dirs h = (self.combine_paths(lib_dirs+include_dirs,includes) or [None])[0] if h: h = os.path.dirname(h) dict_append(info,include_dirs=[h]) print info self.set_info(**info) From pearu at scipy.org Thu Feb 23 06:38:33 2006 From: pearu at scipy.org (Pearu Peterson) Date: Thu, 23 Feb 2006 05:38:33 -0600 (CST) Subject: [SciPy-dev] scipy.test(1,10) results in 11 errors In-Reply-To: <43FC51E4.3010400@mecha.uni-stuttgart.de> References: <43FC51E4.3010400@mecha.uni-stuttgart.de> Message-ID: On Wed, 22 Feb 2006, Nils Wagner wrote: > AttributeError: 'module' object has no attribute 'hmean' > AttributeError: 'module' object has no attribute 'mode' > NameError: global name 'logsumexp' is not defined > > Ran 1011 tests in 1.862s > > FAILED (errors=11) > > Can someone reproduce these errors ? Now fixed in numpy svn. These errors occured due to a numpy.testing bug. Pearu From ndbecker2 at gmail.com Thu Feb 23 21:34:14 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 23 Feb 2006 21:34:14 -0500 Subject: [SciPy-dev] scipy.io.read_array error reading from pipe Message-ID: It seems read_array wants to seek. Is this really necessary? Is there a workaround? ~/remez/remez2 | ./plotfft.py Traceback (most recent call last): File "./plotfft.py", line 12, in ? x = scipy.io.read_array (sys.stdin) File "/usr/lib64/python2.4/site-packages/scipy/io/array_import.py", line 348, in read_array ascii_object = ascii_stream(fileobject, lines=lines, comment=comment, linesep=linesep) File "/usr/lib64/python2.4/site-packages/scipy/io/array_import.py", line 126, in __init__ self._pos = self.file.tell() IOError: [Errno 29] Illegal seek From jonas at mwl.mit.edu Fri Feb 24 02:13:22 2006 From: jonas at mwl.mit.edu (Eric Jonas) Date: Fri, 24 Feb 2006 02:13:22 -0500 Subject: [SciPy-dev] rv_frozen for rv_discrete RVs? Message-ID: <20060224071322.GC7267@convolution.mwl.mit.edu> I've finally started playing around with the scipy.stats package, and I note that there doesn't appear to be a pmf function in rv_frozen. Thus, attempts to do: myrv = stats.poisson(0.5) x = myrv.pmf(r_[0:100]) yield: AttributeError: rv_frozen instance has no attribute 'pmf' Am I missing something here? I tried simply adding: def pmf(self,x): return self.dist.pmf(x,*self.args,**self.kwds) to stats/distributions.py and got the expected behavior, i.e. myrv.pmf now works as expected. I'm curious if I'm missing something, using this incorrectly, or if it's just a simple bug :) By the way, whoever came up with this distributions framework really rocks my socks! ...Eric From nwagner at mecha.uni-stuttgart.de Fri Feb 24 09:56:44 2006 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Fri, 24 Feb 2006 15:56:44 +0100 Subject: [SciPy-dev] CHANGELOG for numpy/scipy ? Message-ID: <43FF1EAC.8090404@mecha.uni-stuttgart.de> Hi all, Is it possible to add a CHANGELOG to numpy/scipy ? Matplotlib comes with such a file and I find it useful w.r.t. to bugfixes, new features, etc. Any comment ? Nils From oliphant at ee.byu.edu Fri Feb 24 19:11:27 2006 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Fri, 24 Feb 2006 17:11:27 -0700 Subject: [SciPy-dev] CHANGELOG for numpy/scipy ? In-Reply-To: <43FF1EAC.8090404@mecha.uni-stuttgart.de> References: <43FF1EAC.8090404@mecha.uni-stuttgart.de> Message-ID: <43FFA0AF.2050805@ee.byu.edu> Nils Wagner wrote: >Hi all, > >Is it possible to add a CHANGELOG to numpy/scipy ? >Matplotlib comes with such a file and I find it useful w.r.t. to >bugfixes, new features, etc. > > svn log produces it for you :-) Assuming people have been adding their commit comments faithfully. -Travis From nwagner at mecha.uni-stuttgart.de Sat Feb 25 01:45:03 2006 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Sat, 25 Feb 2006 07:45:03 +0100 Subject: [SciPy-dev] CHANGELOG for numpy/scipy ? In-Reply-To: <43FFA0AF.2050805@ee.byu.edu> References: <43FF1EAC.8090404@mecha.uni-stuttgart.de> <43FFA0AF.2050805@ee.byu.edu> Message-ID: On Fri, 24 Feb 2006 17:11:27 -0700 Travis Oliphant wrote: > Nils Wagner wrote: > >>Hi all, >> >>Is it possible to add a CHANGELOG to numpy/scipy ? >>Matplotlib comes with such a file and I find it useful >>w.r.t. to >>bugfixes, new features, etc. >> >> > svn log > > produces it for you :-) Assuming people have been >adding their commit > comments faithfully. > > -Travis > Great ! Thank you ! Nils > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev From ndarray at mac.com Sat Feb 25 01:49:49 2006 From: ndarray at mac.com (Sasha) Date: Sat, 25 Feb 2006 01:49:49 -0500 Subject: [SciPy-dev] CHANGELOG for numpy/scipy ? In-Reply-To: References: <43FF1EAC.8090404@mecha.uni-stuttgart.de> <43FFA0AF.2050805@ee.byu.edu> Message-ID: On 2/25/06, Nils Wagner wrote: > On Fri, 24 Feb 2006 17:11:27 -0700 > Travis Oliphant wrote: > > svn log > > > > produces it for you :-) Assuming people have been > >adding their commit > > comments faithfully. > > > > -Travis > > > Great ! Thank you ! You might also like http://projects.scipy.org/scipy/numpy/timeline http://projects.scipy.org/scipy/scipy/timeline From steve at shrogers.com Sat Feb 25 10:24:26 2006 From: steve at shrogers.com (Steven H. Rogers) Date: Sat, 25 Feb 2006 08:24:26 -0700 Subject: [SciPy-dev] Conferences Message-ID: <440076AA.5050400@shrogers.com> There doesn't seem to be any conference information on the new MorinMoin based web site. Are there plans for SciPy06? It would be nice to have conference page with an announcement for the next conference and links to the Plone pages for previous conferences/workshops. The conferences are helpful for promoting SciPy and the presentations have a lot of useful material. This information should be easy to find. I couldn't find anything on the new site and will start such a page if it doesn't already exist. I suppose it should go in the Developer Zone until it's reasonably polished? Regards Steve From robert.kern at gmail.com Sat Feb 25 12:47:44 2006 From: robert.kern at gmail.com (Robert Kern) Date: Sat, 25 Feb 2006 11:47:44 -0600 Subject: [SciPy-dev] Conferences In-Reply-To: <440076AA.5050400@shrogers.com> References: <440076AA.5050400@shrogers.com> Message-ID: <44009840.3070105@gmail.com> Steven H. Rogers wrote: > There doesn't seem to be any conference information on the new MorinMoin > based web site. > > Are there plans for SciPy06? We plan to have one certainly, but we haven't decided on details, yet. > It would be nice to have conference page with an announcement for the > next conference and links to the Plone pages for previous > conferences/workshops. The conferences are helpful for promoting SciPy > and the presentations have a lot of useful material. This information > should be easy to find. > > I couldn't find anything on the new site and will start such a page if > it doesn't already exist. I suppose it should go in the Developer Zone > until it's reasonably polished? I think a really good target for volunteer effort would be to migrate the old conference pages over to the new Wiki. When we've made some decisions about dates and such, we will issue a real Call For Papers and write the page for SciPy06. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From brendansimons at yahoo.ca Sat Feb 25 21:24:19 2006 From: brendansimons at yahoo.ca (Brendan Simons) Date: Sat, 25 Feb 2006 21:24:19 -0500 Subject: [SciPy-dev] Scipy Homepage in Safari In-Reply-To: References: Message-ID: <86549F2C-4040-4BD6-AB9F-A3A9CFE7495A@yahoo.ca> Hello All. Sorry if this has been noticed before, but viewed with Safari, the logo on the new scipy.org page clashes with the header bar. In Firefox, the two match perfectly. I don't know enough about CSS to submit a patch. You can see a screenshot here: http://www.flickr.com/photos/28928816 at N00/104426499/in/ set-72057594070348078/ Brendan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From steve at shrogers.com Sat Feb 25 22:13:12 2006 From: steve at shrogers.com (Steven H. Rogers) Date: Sat, 25 Feb 2006 20:13:12 -0700 Subject: [SciPy-dev] Conferences In-Reply-To: <44009840.3070105@gmail.com> References: <440076AA.5050400@shrogers.com> <44009840.3070105@gmail.com> Message-ID: <44011CC8.7090200@shrogers.com> Robert Kern wrote: > > > I think a really good target for volunteer effort would be to migrate the old > conference pages over to the new Wiki. When we've made some decisions about > dates and such, we will issue a real Call For Papers and write the page for SciPy06. > I've created a conferences page (http://scipy.org/Developer_Zone/Conferences) and begun porting the conference pages from the old site, starting with SciPy2005. The other years are linked to the old site. The images on the SciPy2005 page are still liked to the old site as I don't know how to upload images to MoinMoin. I used tables to make the page look more or less like the old one, but there may be a better way to do this. Steve -- Steven H. Rogers, Ph.D., steve at shrogers.com Weblog: http://shrogers.com/weblog "He who refuses to do arithmetic is doomed to talk nonsense." -- John McCarthy From robert.kern at gmail.com Sat Feb 25 22:16:01 2006 From: robert.kern at gmail.com (Robert Kern) Date: Sat, 25 Feb 2006 21:16:01 -0600 Subject: [SciPy-dev] Conferences In-Reply-To: <44011CC8.7090200@shrogers.com> References: <440076AA.5050400@shrogers.com> <44009840.3070105@gmail.com> <44011CC8.7090200@shrogers.com> Message-ID: <44011D71.80103@gmail.com> Steven H. Rogers wrote: > Robert Kern wrote: > >> I think a really good target for volunteer effort would be to migrate >> the old >> conference pages over to the new Wiki. When we've made some decisions >> about >> dates and such, we will issue a real Call For Papers and write the >> page for SciPy06. > > I've created a conferences page > (http://scipy.org/Developer_Zone/Conferences) and begun porting the > conference pages from the old site, starting with SciPy2005. The other > years are linked to the old site. The images on the SciPy2005 page are > still liked to the old site as I don't know how to upload images to > MoinMoin. I used tables to make the page look more or less like the old > one, but there may be a better way to do this. They look great! Thank you! -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From travis at enthought.com Sat Feb 25 22:42:10 2006 From: travis at enthought.com (Travis N. Vaught) Date: Sat, 25 Feb 2006 21:42:10 -0600 Subject: [SciPy-dev] Scipy Homepage in Safari In-Reply-To: <86549F2C-4040-4BD6-AB9F-A3A9CFE7495A@yahoo.ca> References: <86549F2C-4040-4BD6-AB9F-A3A9CFE7495A@yahoo.ca> Message-ID: <44012392.4090601@enthought.com> Brendan, Apparently it's a png-on-pre-tiger-Safari-issue--at least according to this: http://hsivonen.iki.fi/png-gamma/ I've changed it from a png to a gif, hoping this will do the trick. Let me know how it looks. You may have to clear your cache or do other things to get the .gif image. Thanks for pointing this out. Travis Brendan Simons wrote: > Hello All. > > Sorry if this has been noticed before, but viewed with Safari, the > logo on the new scipy.org page clashes with the header bar. In > Firefox, the two match perfectly. I don't know enough about CSS to > submit a patch. You can see a screenshot here: > > http://www.flickr.com/photos/28928816 at N00/104426499/in/ > set-72057594070348078/ > > Brendan > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev > -- ........................ Travis N. Vaught CEO Enthought, Inc. http://www.enthought.com ........................ From brendansimons at yahoo.ca Sun Feb 26 01:30:11 2006 From: brendansimons at yahoo.ca (Brendan Simons) Date: Sun, 26 Feb 2006 01:30:11 -0500 Subject: [SciPy-dev] Scipy Homepage in Safari In-Reply-To: References: Message-ID: <9C0731FF-EBC3-46A5-94F8-6C3B3523AFC4@yahoo.ca> The gif fixes things, thanks. Weird though, I'm running Tiger. They must not have addressed the png bug completely yet. -Brendan > Brendan, > > Apparently it's a png-on-pre-tiger-Safari-issue--at least according > to this: > > http://hsivonen.iki.fi/png-gamma/ > > I've changed it from a png to a gif, hoping this will do the > trick. Let > me know how it looks. You may have to clear your cache or do other > things to get the .gif image. > > Thanks for pointing this out. > > Travis > > Brendan Simons wrote: > > Hello All. > > > > Sorry if this has been noticed before, but viewed with Safari, the > > logo on the new scipy.org page clashes with the header bar. In > > Firefox, the two match perfectly. I don't know enough about CSS to > > submit a patch. You can see a screenshot here: > > > > http://www.flickr.com/photos/28928816 at N00/104426499/in/ > > set-72057594070348078/ > > > > Brendan > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.yahoo.com > > > > _______________________________________________ > > Scipy-dev mailing list > > Scipy-dev at scipy.net > > http://www.scipy.net/mailman/listinfo/scipy-dev > > > > -- > ........................ > Travis N. Vaught > CEO > Enthought, Inc. > http://www.enthought.com __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com