From rkern at ucsd.edu  Fri Oct  1 00:16:35 2004
From: rkern at ucsd.edu (Robert Kern)
Date: Thu, 30 Sep 2004 21:16:35 -0700
Subject: [SciPy-dev] Pre-release fixes
In-Reply-To: <415CD1D4.8010004@ee.byu.edu>
References: <415CAC60.4060604@ucsd.edu> <415CD1D4.8010004@ee.byu.edu>
Message-ID: <415CDA23.8030807@ucsd.edu>

Travis Oliphant wrote:
> Robert Kern wrote:
> 
>> I've just checked in a fix for fastumath's logical functions. They 
>> used to give wrong answers on OSX and caused some tests to fail. I 
>> believe this to be an endianness issue, but I don't have another 
>> big-endian machine to test on. All tests still pass on Athlon/Linux.
>>
>> The changes made largely track what Numeric did, so I'm not sure if 
>> these were conscious deviations to speed up fastumath or just a 
>> failure to keep up with the bugfixes in Numeric.
>>
>> I have only implemented fastumath_unsigned.inc as yet. I will make 
>> similar changes in fastumath_nounsigned.inc as I accumulate tuits.
>>
>> Travis, could you check my changes to make sure I didn't revert 
>> differences you deliberately made? If they were deliberate, then we 
>> need to figure a way to revert to the correct, if slower, Numeric 
>> implementations on the Mac.
> 
> 
> I'm not sure what the problem is here.  But I think you undid deliberate 
> changes that have implications for alter_numeric() and need to be 
> discussed. 
> I had intentially made the results of all logical operations be unsigned 
> bytes.  What was broken about this on the Mac?

Here are the tests that fail. The first two are what led me to the "fix" 
in the first place. The CDF failures are newer (I haven't seen them 
until today because I always used my version of fastumath_unsigned.inc 
for some months now), but all tests pass with my version.

A quick summary:

 >>> scipy.logical_and.reduce([1,1])
16777217


======================================================================
FAIL: check_nd (scipy_base.function_base.test_function_base.test_all)
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/scipy_base/tests/test_function_base.py", 
line 39, in check_nd
     assert_array_equal(alltrue(y1),[0,0,1])
   File 
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/scipy_test/testing.py", 
line 659, in assert_array_equal
     assert cond,\
AssertionError:
Arrays are not equal (mismatch 33.3333333333%):
         Array 1: [       0        0 16777217]
         Array 2: [0 0 1]


======================================================================
FAIL: check_nd (scipy_base.function_base.test_function_base.test_any)
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/scipy_base/tests/test_function_base.py", 
line 23, in check_nd
     assert_array_equal(sometrue(y1),[1,1,0])
   File 
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/scipy_test/testing.py", 
line 659, in assert_array_equal
     assert cond,\
AssertionError:
Arrays are not equal (mismatch 66.6666666667%):
         Array 1: [16777216 16777216        0]
         Array 2: [1 1 0]


======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_alpha)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.8901307480205483,)

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_anglit)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = 0.134833494822; pval = nan; alpha = 0.01
args = ()

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_arcsine)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = 0.107380700111; pval = nan; alpha = 0.01
args = ()

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_beta)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.3058217448839688, 1.638923226210558)

======================================================================
FAIL: check_cdf 
(scipy.stats.distributions.test_distributions.test_betaprime)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.7946828675209945, 1.3659679931964808)

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_bradford)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.995535943496068,)

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_burr)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.7999727389493319, 1.0291342027239256)

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_cauchy)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = 0.143052525322; pval = nan; alpha = 0.01
args = ()

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_chi)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.6750617919359232,)

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_chi2)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.5046670059082969,)

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_dgamma)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.8843762379065128,)

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_dweibull)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.1843576971636054,)

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_erlang)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (4, 0.91640849579812245, 0.79817883530002565)

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_expon)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = 0.107035405269; pval = nan; alpha = 0.01
args = ()

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_exponpow)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.1084215205292667,)

======================================================================
FAIL: check_cdf 
(scipy.stats.distributions.test_distributions.test_exponweib)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.9765503019823849, 1.8216168224929503)

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_f)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.8477848988062577, 1.7773122402806831)

======================================================================
FAIL: check_cdf 
(scipy.stats.distributions.test_distributions.test_fatiguelife)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.354274749801879,)

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_fisk)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.2761579637690608,)

======================================================================
FAIL: check_cdf 
(scipy.stats.distributions.test_distributions.test_foldcauchy)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.6521602833511251,)

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_foldnorm)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.7554136027893463,)

======================================================================
FAIL: check_cdf 
(scipy.stats.distributions.test_distributions.test_frechet_l)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.3212613080139093,)

======================================================================
FAIL: check_cdf 
(scipy.stats.distributions.test_distributions.test_frechet_r)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.831564794039293,)

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_gamma)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.6083153459617701,)

======================================================================
FAIL: check_cdf 
(scipy.stats.distributions.test_distributions.test_genextreme)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = 0.0909121314685; pval = nan; alpha = 0.01
args = (1.7210441119052327,)

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_gengamma)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = 0.15651460886; pval = nan; alpha = 0.01
args = (1.1265602049356369, 1.789773633933041)

======================================================================
FAIL: check_cdf 
(scipy.stats.distributions.test_distributions.test_genhalflogistic)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = 0.0612444996834; pval = nan; alpha = 0.01
args = (1.8490619343641432,)

======================================================================
FAIL: check_cdf 
(scipy.stats.distributions.test_distributions.test_genlogistic)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.419426229431517,)

======================================================================
FAIL: check_cdf 
(scipy.stats.distributions.test_distributions.test_genpareto)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = 0.135486149788; pval = nan; alpha = 0.01
args = (1.4346656353328937,)

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_gilbrat)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = 0.131796498598; pval = nan; alpha = 0.01
args = ()

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_gompertz)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.2018899800407579,)

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_gumbel_l)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = 0.168374500672; pval = nan; alpha = 0.01
args = ()

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_gumbel_r)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = 0.150828138987; pval = nan; alpha = 0.01
args = ()

======================================================================
FAIL: check_cdf 
(scipy.stats.distributions.test_distributions.test_halfcauchy)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = 0.101199208697; pval = nan; alpha = 0.01
args = ()

======================================================================
FAIL: check_cdf 
(scipy.stats.distributions.test_distributions.test_halflogistic)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = 0.113176395496; pval = nan; alpha = 0.01
args = ()

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_halfnorm)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = 0.150618899083; pval = nan; alpha = 0.01
args = ()

======================================================================
FAIL: check_cdf 
(scipy.stats.distributions.test_distributions.test_hypsecant)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = 0.128143958251; pval = nan; alpha = 0.01
args = ()

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_laplace)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = 0.213923497995; pval = nan; alpha = 0.01
args = ()

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_loggamma)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.1019995326307017,)

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_logistic)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = 0.0543847779433; pval = nan; alpha = 0.01
args = ()

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_lognorm)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.7085755404653427,)

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_lomax)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.3353241977770063,)

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_maxwell)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = 0.115218121035; pval = nan; alpha = 0.01
args = ()

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_nakagami)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.886918043114695,)

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_ncf)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.6070744080464818, 1.4502566675774289, 1.4943408411354844)

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_nct)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.4704379855857841, 1.7611435834086047)

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_ncx2)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.2394290524371847, 1.3550394000897465)

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_norm)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = 0.159503246745; pval = nan; alpha = 0.01
args = ()

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_pareto)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.7004776605275855,)

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_powerlaw)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.5178586665615643,)

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_rayleigh)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = 0.0521100146552; pval = nan; alpha = 0.01
args = ()

======================================================================
FAIL: check_cdf 
(scipy.stats.distributions.test_distributions.test_reciprocal)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = 0.0984953045845; pval = nan; alpha = 0.01
args = (0.52198748250163574, 1.5219874825016357)

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_t)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.1703651942244617,)

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_triang)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = 0.120754329364; pval = nan; alpha = 0.01
args = (0.31036819444097996,)

======================================================================
FAIL: check_cdf 
(scipy.stats.distributions.test_distributions.test_tukeylambda)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.4154560974523536,)

======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_uniform)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = 0.207966844241; pval = nan; alpha = 0.01
args = ()

======================================================================
FAIL: check_cdf 
(scipy.stats.distributions.test_distributions.test_weibull_max)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.8048478136464641,)

======================================================================
FAIL: check_cdf 
(scipy.stats.distributions.test_distributions.test_weibull_min)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "<string>", line 10, in check_cdf
AssertionError: D = nan; pval = nan; alpha = 0.01
args = (1.4914168094327804,)

----------------------------------------------------------------------
Ran 936 tests in 14.693s

FAILED (failures=60)

> Could you explain your changes here, better?

Mostly, I just patched in what was in Numeric and things began to work. 
There's no more rationale than that.

-- 
Robert Kern
rkern at ucsd.edu

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



From oliphant at ee.byu.edu  Fri Oct  1 00:17:27 2004
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Thu, 30 Sep 2004 22:17:27 -0600
Subject: [SciPy-dev] MCMC, Kalman Filtering, AI for SciPy?
In-Reply-To: <415CD4F3.9060004@colorado.edu>
References: <E1CAzvF-0005Yy-00@fisher.forestry.uga.edu>
	<4156440A.1040204@ee.byu.edu>	<41566CBD.70005@enthought.com>
	<415855AD.4060701@sdl.usu.edu>	<41599AC4.1030907@ee.byu.edu>
	<Pine.LNX.4.61.0409290711450.4439@scipy.org>	<415BBA66.802@enthought.com>
	<415C65DD.30204@colorado.edu> <415CC25E.6080900@enthought.com>
	<415CD4F3.9060004@colorado.edu>
Message-ID: <415CDA57.2060107@ee.byu.edu>

Fernando Perez wrote:

> eric jones wrote:
>
>> Hmmm.  So here is the main thing I see that needs to be fixed from 
>> this email... why the heck aren't you a committer??  I thought you 
>> already had commit access.
>>
>> I will ask Joe to add you to the list (whether you want to or not :-)
>
>
Absolutely,

It is as easy for you to make commits as it is for you to tell us about 
them.

Come on in,  the water's fine...

-Travis



From oliphant at ee.byu.edu  Fri Oct  1 00:26:19 2004
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Thu, 30 Sep 2004 22:26:19 -0600
Subject: [SciPy-dev] MCMC, Kalman Filtering, AI for SciPy?
In-Reply-To: <415BB88B.50408@enthought.com>
References: <E1CAzvF-0005Yy-00@fisher.forestry.uga.edu>
	<4156440A.1040204@ee.byu.edu>	<41566CBD.70005@enthought.com>
	<415855AD.4060701@sdl.usu.edu>	<41599AC4.1030907@ee.byu.edu>
	<Pine.LNX.4.61.0409290711450.4439@scipy.org>	<415ADFDA.3000200@sdl.usu.edu>
	<415B20AC.4080103@ucsd.edu> <415B2303.5010301@sdl.usu.edu>
	<415B9C7D.4000008@ucsd.edu> <415BB88B.50408@enthought.com>
Message-ID: <415CDC6B.6000000@ee.byu.edu>

eric jones wrote:

>>> Lattice methods, where do they go? How about useful data structures 
>>> or combinatorics? So on and so forth. I think the upper level GAMS 
>>> categories cover sufficient range that most things can be put into a 
>>> directory without embarrassment. As to the detailed breakdown in the 
>>> GAMS sub-classifications, I am not so sure.
>>
>>
We should do the /lib top-level directory and also put under it nice 
general purpose data structures and other generally useful things that 
don't have another obvious home.


>>
> Here is where the current SciPy modules would likely get lumped in the 
> GAMS hierarchy.
>
> scipy/
>  analysis/
>  numbertheory/
>  functions/           special
>  linalg/              linalg, sparse
>  interpolation/       interpolate
>  rootfinding/
>  optimization/        optimize, ga
>  calculus/            integrate
>  diffeq/              integraltransforms/  fftpack
>  approximation/
>  probstat/            stats
>  simulation/
>  datahandling/        io
>  symbolic/
>  geometry/
>  graphics/            xplt, gplt, plt
>  service/             gui_thread
>  develop/
>  other/               cow, cluster ??, signal  ??
>
>
> (Cluster and signal didn't fit anywhere obvious to me)

I got the name signal from MATLAB's signals toolbox.  

>
> The naming conventions are often quite similar.  The SciPy names are 
> generally shorter which is nice for typing.  Where SciPy has multiple 
> packages [(linalg, sparse), (optimize, ga), etc.], it is likely a good 
> idea.  Like you, I don't want to see a deep nesting in the package 
> structure.
> Looking at this, I don't see any real reason to reorganize top level 
> package names.  Are any of them that bad or misleading?  On the other 
> hand, I do think we should reorganize the functions within them some 
> to fix the places where they are organized based on "build" 
> convenience instead of actual function.  This will probably 
> necessitate the addition of new top level groups and maybe the pruning 
> of one of the current ones.  I've made a Wiki page to keep suggestions 
> that people have:

Some reorganization is probably needed, but I think that more work 
should be done on getting some kind of standard searchable help working 
well, first.  The only draw-back to the .chm idea is that I don't know 
how to make .chm files.


> I used to love "from xxx import *" and swore it was the right way to 
> handle Numeric, etc. since I few "array" and friends as builtin 
> functions...  I guess I've been hanging out with to many computer 
> scientists lately.  Or perhaps it is the few times where I have 
> wondered "where is function xxx [which is broken] coming from?" and 
> struggled through a large codebase to track it down.  We've had a 
> nasty bug or two where one import * unexpectedly clobbered some 
> functions from a previous import *.  In any case, it is a (seldom 
> broken) policy to never use import * in our code bases at Enthought.  
> It is probably a good idea to apply this same policy to SciPy.  Doing 
> so would partially solve the problem you discuss.

I think the current wisdom is to rarely use from import * in package 
code (I would say never but I think it is effective in the __init__ 
files of packages to make names available for the user).  But, often in 
interactive mode and some small scripts one will use from import * quite 
often.

-Travis



From Fernando.Perez at colorado.edu  Fri Oct  1 00:39:07 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Thu, 30 Sep 2004 22:39:07 -0600
Subject: [SciPy-dev] MCMC, Kalman Filtering, AI for SciPy?
In-Reply-To: <415CDA57.2060107@ee.byu.edu>
References: <E1CAzvF-0005Yy-00@fisher.forestry.uga.edu>
	<4156440A.1040204@ee.byu.edu>	<41566CBD.70005@enthought.com>
	<415855AD.4060701@sdl.usu.edu>	<41599AC4.1030907@ee.byu.edu>
	<Pine.LNX.4.61.0409290711450.4439@scipy.org>	<415BBA66.802@enthought.com>
	<415C65DD.30204@colorado.edu> <415CC25E.6080900@enthought.com>
	<415CD4F3.9060004@colorado.edu> <415CDA57.2060107@ee.byu.edu>
Message-ID: <415CDF6B.2030500@colorado.edu>

Travis Oliphant wrote:

>>>I will ask Joe to add you to the list (whether you want to or not :-)
>>
>>
> Absolutely,
> 
> It is as easy for you to make commits as it is for you to tell us about 
> them.
> 
> Come on in,  the water's fine...

:)

Thanks for the welcome, I really appreciate it.  I'm glad to see this release 
coming out nicely, and I think good momentum is building.  In general my time 
for core scipy contributions is limited, as ipython itself consumes most of 
it.  But I'll certainly do my best.

BTW, I'll try to have soon a new release of ipython which, together with 
matplotlib 0.63, irons out the last wrinkles for a pretty good integration 
between the two in terms of interactive/plotting work.  So I think the ideas 
discussed at the conference are coming together...

Cheers,

f



From Fernando.Perez at colorado.edu  Fri Oct  1 00:46:54 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Thu, 30 Sep 2004 22:46:54 -0600
Subject: [SciPy-dev] MCMC, Kalman Filtering, AI for SciPy?
In-Reply-To: <415CDC6B.6000000@ee.byu.edu>
References: <E1CAzvF-0005Yy-00@fisher.forestry.uga.edu>
	<4156440A.1040204@ee.byu.edu>	<41566CBD.70005@enthought.com>
	<415855AD.4060701@sdl.usu.edu>	<41599AC4.1030907@ee.byu.edu>
	<Pine.LNX.4.61.0409290711450.4439@scipy.org>	<415ADFDA.3000200@sdl.usu.edu>
	<415B20AC.4080103@ucsd.edu> <415B2303.5010301@sdl.usu.edu>
	<415B9C7D.4000008@ucsd.edu> <415BB88B.50408@enthought.com>
	<415CDC6B.6000000@ee.byu.edu>
Message-ID: <415CE13E.20903@colorado.edu>

Travis Oliphant wrote:

> Some reorganization is probably needed, but I think that more work 
> should be done on getting some kind of standard searchable help working 
> well, first.  The only draw-back to the .chm idea is that I don't know 
> how to make .chm files.

I don't either, but I found this prechm.py, in python's CVS at Doc/tools:

http://cvs.sourceforge.net/viewcvs.py/*checkout*/python/python/dist/src/Doc/tools/prechm.py?content-type=text%2Fplain&rev=1.20

I haven't tested it, but from the docstring, it will take html files and wrap 
them into a .chm file.  We could give it a try, and if it works well enough, 
make a bundle of docs in this format.

Cheers,

f



From rkern at ucsd.edu  Fri Oct  1 00:53:59 2004
From: rkern at ucsd.edu (Robert Kern)
Date: Thu, 30 Sep 2004 21:53:59 -0700
Subject: [SciPy-dev] MCMC, Kalman Filtering, AI for SciPy?
In-Reply-To: <415CE13E.20903@colorado.edu>
References: <E1CAzvF-0005Yy-00@fisher.forestry.uga.edu>
	<4156440A.1040204@ee.byu.edu>	<41566CBD.70005@enthought.com>
	<415855AD.4060701@sdl.usu.edu>	<41599AC4.1030907@ee.byu.edu>
	<Pine.LNX.4.61.0409290711450.4439@scipy.org>	<415ADFDA.3000200@sdl.usu.edu>
	<415B20AC.4080103@ucsd.edu> <415B2303.5010301@sdl.usu.edu>
	<415B9C7D.4000008@ucsd.edu> <415BB88B.50408@enthought.com>
	<415CDC6B.6000000@ee.byu.edu> <415CE13E.20903@colorado.edu>
Message-ID: <415CE2E7.7050306@ucsd.edu>

Fernando Perez wrote:
> Travis Oliphant wrote:
> 
>> Some reorganization is probably needed, but I think that more work 
>> should be done on getting some kind of standard searchable help 
>> working well, first.  The only draw-back to the .chm idea is that I 
>> don't know how to make .chm files.
> 
> 
> I don't either, but I found this prechm.py, in python's CVS at Doc/tools:
> 
> http://cvs.sourceforge.net/viewcvs.py/*checkout*/python/python/dist/src/Doc/tools/prechm.py?content-type=text%2Fplain&rev=1.20 
> 
> 
> I haven't tested it, but from the docstring, it will take html files and 
> wrap them into a .chm file.  We could give it a try, and if it works 
> well enough, make a bundle of docs in this format.

Not quite, AFAICT. It massages the existing HTML to what's necessary for 
Microsoft's help authoring tools to work. Their Windows-only software is 
still necessary to build the CHM file itself.

-- 
Robert Kern
rkern at ucsd.edu

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



From joe at enthought.com  Fri Oct  1 01:59:36 2004
From: joe at enthought.com (Joe Cooper)
Date: Fri, 01 Oct 2004 00:59:36 -0500
Subject: [SciPy-dev] MCMC, Kalman Filtering, AI for SciPy?
In-Reply-To: <415CD4F3.9060004@colorado.edu>
References: <E1CAzvF-0005Yy-00@fisher.forestry.uga.edu>
	<4156440A.1040204@ee.byu.edu>	<41566CBD.70005@enthought.com>
	<415855AD.4060701@sdl.usu.edu>	<41599AC4.1030907@ee.byu.edu>
	<Pine.LNX.4.61.0409290711450.4439@scipy.org>	<415BBA66.802@enthought.com>
	<415C65DD.30204@colorado.edu> <415CC25E.6080900@enthought.com>
	<415CD4F3.9060004@colorado.edu>
Message-ID: <415CF248.1070309@enthought.com>

Fernando Perez wrote:
> eric jones wrote:
> 
>> Hmmm.  So here is the main thing I see that needs to be fixed from 
>> this email... why the heck aren't you a committer??  I thought you 
>> already had commit access.
>>
>> I will ask Joe to add you to the list (whether you want to or not :-)
> 
> 
> Well, I actually might be, I'm not sure.  I have commit access 
> (obviously) to ipython's directory in scipy's CVS.  That may or may not 
> give me access to the rest of scipy, I just don't know how things are 
> set up.  I was also a bit hesitant, but with your approval, I'll go 
> ahead in the future (once things are confirmed working).
> 
> Thanks  (or not, I'm not sure it's a good thing for my already 
> non-existent free time :)

Hi Fernando,

You've always had access to commit to scipy (or at least since I setup 
ipython).  Let me know if you have any problems.



From nwagner at mecha.uni-stuttgart.de  Fri Oct  1 04:01:20 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Fri, 01 Oct 2004 10:01:20 +0200
Subject: [SciPy-dev] Hessenberg form
Message-ID: <415D0ED0.8070704@mecha.uni-stuttgart.de>

Hi all,

I'd like to have a function called hess
in linalg which reduces a general matrix A to upper Hessenberg form
before the next release.

Any comment ?


 Nils





From pearu at cens.ioc.ee  Fri Oct  1 07:12:19 2004
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Fri, 1 Oct 2004 14:12:19 +0300 (EEST)
Subject: [SciPy-dev] Re: [Scipy-cvs] world/scipy_core/scipy_distutils
 from_template.py, 1.6, 1.7
In-Reply-To: <20041001083008.B1AD13EB27@www.scipy.com>
Message-ID: <Pine.LNX.4.21.0410011406430.9973-100000@cens.kybi>


Travis,

What is the reason that process_str() lowers its input?
There may be other macros in addition to MIN, MAX that .pyf files may
contain and it would be nice to if process_str would not lower the input.

Pearu

On Fri, 1 Oct 2004 travo at scipy.org wrote:

> Update of /home/cvsroot/world/scipy_core/scipy_distutils
> In directory scipy.org:/tmp/cvs-serv19408/scipy_core/scipy_distutils
> 
> Modified Files:
> 	from_template.py 
> Log Message:
> Added wrappers to iterative methods
> 
> 
> Index: from_template.py
> ===================================================================
> RCS file: /home/cvsroot/world/scipy_core/scipy_distutils/from_template.py,v
> retrieving revision 1.6
> retrieving revision 1.7
> diff -C2 -d -r1.6 -r1.7
> *** from_template.py	31 Aug 2004 01:00:05 -0000	1.6
> --- from_template.py	1 Oct 2004 08:30:06 -0000	1.7
> ***************
> *** 173,176 ****
> --- 173,187 ----
>           char = str[ind]
>       return ''.join(extra)
> + 
> + maxre = re.compile(r"max[(](.+),(.+)[)]")
> + minre = re.compile(r"min[(](.+),(.+)[)]")
> + 
> + def fix_capitals(astr):
> +     # Need to convert max(x,x) to MAX(x,x)
> +     #  and min(x,x) to MIN(x,x)
> +     astr = maxre.sub(r"MAX(\g<1>,\g<2>)",astr)
> +     astr = minre.sub(r"MIN(\g<1>,\g<2>)",astr)
> +     return astr
> +     
>       
>   def process_str(allstr):
> ***************
> *** 184,193 ****
>       oldend = 0
>       for sub in struct:
> !         writestr += newstr[oldend:sub[0]]
>           expanded = expand_sub(newstr[sub[0]:sub[1]],get_line_header(newstr,sub[0]))
> !         writestr += expanded
>           oldend =  sub[1]
>   
> !     writestr += newstr[oldend:]
>       return writestr
>   
> --- 195,205 ----
>       oldend = 0
>       for sub in struct:
> !         writestr += fix_capitals(newstr[oldend:sub[0]])
>           expanded = expand_sub(newstr[sub[0]:sub[1]],get_line_header(newstr,sub[0]))
> !         writestr += fix_capitals(expanded)
>           oldend =  sub[1]
>   
> ! 
> !     writestr += fix_capitals(newstr[oldend:])
>       return writestr
>   
> 
> _______________________________________________
> Scipy-cvs mailing list
> Scipy-cvs at scipy.org
> http://scipy.net/mailman/listinfo/scipy-cvs
> 




From prabhu at aero.iitm.ernet.in  Fri Oct  1 10:56:38 2004
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Fri, 1 Oct 2004 20:26:38 +0530
Subject: [SciPy-dev] gui_thread and wxPython-2.5.2.8
Message-ID: <16733.28710.594895.848623@monster.linux.in>

Hi,

I noticed that gui_thread does not work with wxPython-2.5.2.8.  It
worked perfectly under 2.4.x.  So I spent quite a bit of time figuring
out what was going on today.  I finally have something that works.
The only problem is that the solution requires a small patch to
wx/__init__.py in the wxPython installation.  Of course, I am using
Pearu's excellent wxPython_thread code to handle the threading issues.

AFAICT the major problem with 2.5.2.8 and gui_thread is that a lot is
done when one does `import wx`.  This is unlike 2.4.x where importing
wxPython alone merely imports wxc.  It also turns out that a function
called `_core_._wxPySetDictionary(vars())` in wx/_core.py is the major
pain in the neck.  Boy did that take a while to figure out!

What do you folks recommend that I do about the issue.  Does someone
have the time to look at my changes to gui_thread/wxPython_thread.py
and the patch to wx/__init__.py and help?  Should I also ask Robin
Dunn if I could work out a cleaner solution by perhaps changing the
way _wxPySetDictionary works?  I am not sure.

Any advice would be appreciated.  In any case the result of my hacking
is that with 2 small patches one can use gui_thread fully from within
IPython for both new and old (not tested but should work) versions of
wxPython.

Also, if 0.3.2 is round the corner is this a good thing to push into
scipy?  I am not sure how many folks use gui_thread, but it would
certainly be cool if this could make it into 0.3.2.

Comments/suggestions?

cheers,
prabhu



From aisaac at american.edu  Fri Oct  1 09:20:14 2004
From: aisaac at american.edu (Alan G Isaac)
Date: Fri, 1 Oct 2004 09:20:14 -0400 (Eastern Daylight Time)
Subject: [SciPy-dev] Hessenberg form
In-Reply-To: <415D0ED0.8070704@mecha.uni-stuttgart.de>
References: <415D0ED0.8070704@mecha.uni-stuttgart.de>
Message-ID: <Mahogany-0.66.0-1532-20041001-114646.00@american.edu>

On Fri, 01 Oct 2004, Nils Wagner apparently wrote:
> I'd like to have a function called hess
> in linalg which reduces a general matrix A to upper Hessenberg form
> before the next release.
> Any comment ?

The suggested name is perhaps unfortunate.  I would expect
hess to take a function and point as arguments and to return
a matrix of numerical partial derivatives (i.e., the
Hessian).

Cheers,
Alan Isaac





From Fernando.Perez at colorado.edu  Fri Oct  1 12:11:55 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 01 Oct 2004 10:11:55 -0600
Subject: [SciPy-dev] gui_thread and wxPython-2.5.2.8
In-Reply-To: <16733.28710.594895.848623@monster.linux.in>
References: <16733.28710.594895.848623@monster.linux.in>
Message-ID: <415D81CB.1080800@colorado.edu>

Prabhu Ramachandran schrieb:

> Any advice would be appreciated.  In any case the result of my hacking
> is that with 2 small patches one can use gui_thread fully from within
> IPython for both new and old (not tested but should work) versions of
> wxPython.
> 
> Also, if 0.3.2 is round the corner is this a good thing to push into
> scipy?  I am not sure how many folks use gui_thread, but it would
> certainly be cool if this could make it into 0.3.2.

This is great, as far as I'm concerned.  I'm sorry I can't currently help, as 
I'm too swamped on the next ipython release.  But since that work is geared to 
make ipython+matplotlib work as smoothly as possible with wx and gtk, having 
this in the scipy release would be a great complement.

These gui/threading issues are _way_ over the head of most day-to-day 
scientists (including myself :), so the more we can automate this and make the 
tools (scipy, ipython, matplotlib) as foolproof as possible in this regard, 
the better we'll be.  Most scientists will just roll their eyes if we give 
them a maze of instructions just to pop a plot window which doesn't lock up 
their shell, so I think that for the current goals of 'easy out-of-box use for 
the common scientist', this is a very worthy addition.

Just my $.02

Best,

f



From Fernando.Perez at colorado.edu  Fri Oct  1 12:11:55 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 01 Oct 2004 10:11:55 -0600
Subject: [SciPy-dev] gui_thread and wxPython-2.5.2.8
In-Reply-To: <16733.28710.594895.848623@monster.linux.in>
References: <16733.28710.594895.848623@monster.linux.in>
Message-ID: <415D81CB.1080800@colorado.edu>

Prabhu Ramachandran schrieb:

> Any advice would be appreciated.  In any case the result of my hacking
> is that with 2 small patches one can use gui_thread fully from within
> IPython for both new and old (not tested but should work) versions of
> wxPython.
> 
> Also, if 0.3.2 is round the corner is this a good thing to push into
> scipy?  I am not sure how many folks use gui_thread, but it would
> certainly be cool if this could make it into 0.3.2.

This is great, as far as I'm concerned.  I'm sorry I can't currently help, as 
I'm too swamped on the next ipython release.  But since that work is geared to 
make ipython+matplotlib work as smoothly as possible with wx and gtk, having 
this in the scipy release would be a great complement.

These gui/threading issues are _way_ over the head of most day-to-day 
scientists (including myself :), so the more we can automate this and make the 
tools (scipy, ipython, matplotlib) as foolproof as possible in this regard, 
the better we'll be.  Most scientists will just roll their eyes if we give 
them a maze of instructions just to pop a plot window which doesn't lock up 
their shell, so I think that for the current goals of 'easy out-of-box use for 
the common scientist', this is a very worthy addition.

Just my $.02

Best,

f



From Fernando.Perez at colorado.edu  Fri Oct  1 12:12:33 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 01 Oct 2004 10:12:33 -0600
Subject: [SciPy-dev] MCMC, Kalman Filtering, AI for SciPy?
In-Reply-To: <415CF248.1070309@enthought.com>
References: <E1CAzvF-0005Yy-00@fisher.forestry.uga.edu>
	<4156440A.1040204@ee.byu.edu>	<41566CBD.70005@enthought.com>
	<415855AD.4060701@sdl.usu.edu>	<41599AC4.1030907@ee.byu.edu>
	<Pine.LNX.4.61.0409290711450.4439@scipy.org>	<415BBA66.802@enthought.com>
	<415C65DD.30204@colorado.edu> <415CC25E.6080900@enthought.com>
	<415CD4F3.9060004@colorado.edu> <415CF248.1070309@enthought.com>
Message-ID: <415D81F1.2000302@colorado.edu>

Joe Cooper schrieb:
> Fernando Perez wrote:
> 
>>eric jones wrote:
>>
>>
>>>Hmmm.  So here is the main thing I see that needs to be fixed from 
>>>this email... why the heck aren't you a committer??  I thought you 
>>>already had commit access.
>>>
>>>I will ask Joe to add you to the list (whether you want to or not :-)
>>
>>
>>Well, I actually might be, I'm not sure.  I have commit access 
>>(obviously) to ipython's directory in scipy's CVS.  That may or may not 
>>give me access to the rest of scipy, I just don't know how things are 
>>set up.  I was also a bit hesitant, but with your approval, I'll go 
>>ahead in the future (once things are confirmed working).
>>
>>Thanks  (or not, I'm not sure it's a good thing for my already 
>>non-existent free time :)
> 
> 
> Hi Fernando,
> 
> You've always had access to commit to scipy (or at least since I setup 
> ipython).  Let me know if you have any problems.

Great, many thanks.  I guess I was OK all along, sorry for the bother.

Regards,

f



From Fernando.Perez at colorado.edu  Fri Oct  1 12:22:25 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 01 Oct 2004 10:22:25 -0600
Subject: [SciPy-dev] Scipy help and documentation for end users
In-Reply-To: <415CE2E7.7050306@ucsd.edu>
References: <E1CAzvF-0005Yy-00@fisher.forestry.uga.edu>
	<4156440A.1040204@ee.byu.edu>	<41566CBD.70005@enthought.com>
	<415855AD.4060701@sdl.usu.edu>	<41599AC4.1030907@ee.byu.edu>
	<Pine.LNX.4.61.0409290711450.4439@scipy.org>	<415ADFDA.3000200@sdl.usu.edu>
	<415B20AC.4080103@ucsd.edu> <415B2303.5010301@sdl.usu.edu>
	<415B9C7D.4000008@ucsd.edu> <415BB88B.50408@enthought.com>
	<415CDC6B.6000000@ee.byu.edu> <415CE13E.20903@colorado.edu>
	<415CE2E7.7050306@ucsd.edu>
Message-ID: <415D8441.3060000@colorado.edu>

[ I'm relabeling this thread so it stands out, as I think this is a rather 
important topic, hopefully the discussion can continue here and it will be 
more obvious when browsing the archives.]

Robert Kern schrieb:
> Fernando Perez wrote:

>>I don't either, but I found this prechm.py, in python's CVS at Doc/tools:
>>
>>http://cvs.sourceforge.net/viewcvs.py/*checkout*/python/python/dist/src/Doc/tools/prechm.py?content-type=text%2Fplain&rev=1.20 
>>
>>
>>I haven't tested it, but from the docstring, it will take html files and 
>>wrap them into a .chm file.  We could give it a try, and if it works 
>>well enough, make a bundle of docs in this format.
> 
> 
> Not quite, AFAICT. It massages the existing HTML to what's necessary for 
> Microsoft's help authoring tools to work. Their Windows-only software is 
> still necessary to build the CHM file itself.

Bummer.  I didn't have time to run a test last night.

This page has a useful discussion of documentation generation under Linux:

http://www.jeanweber.com/howto/linux-help.htm

One option would be to use DocBook, which Lyx and OpenOffice both support. 
But DocBook has a reputation for complexity, I don't really know how justified 
or it truly is.

But back to the chm format as a possibility, perhaps not all is lost.  While 
there seems to be no native linux authoring tool, this thing:

http://www.soft411.com/company/AbeeTech/Abee-CHM-Maker-freeware.htm

is Windows freeware.  I suspect, being a win95-compatible small program, it 
will probably run just fine under Wine.  So perhaps this could be used to make 
the .chm files, which seems to be the sticking point.  We've seen there are 
good X window clients for this format, we just need to solve the authoring issue.

Anyway, whether it's docbook or chm, we certainly need a solid 
documentation/help system integrated into this to make python/scipy more 
approachable to new scientists.  These are just some suggestions, and I'm sure 
others know more about this than I do.

Best,

f



From chris at fisher.forestry.uga.edu  Fri Oct  1 12:25:38 2004
From: chris at fisher.forestry.uga.edu (Christopher Fonnesbeck)
Date: Fri, 1 Oct 2004 12:25:38 -0400
Subject: [SciPy-dev] MCMC, Kalman Filtering, AI for SciPy?
In-Reply-To: <415D81F1.2000302@colorado.edu>
References: <E1CAzvF-0005Yy-00@fisher.forestry.uga.edu>
	<4156440A.1040204@ee.byu.edu>	<41566CBD.70005@enthought.com>
	<415855AD.4060701@sdl.usu.edu>	<41599AC4.1030907@ee.byu.edu>
	<Pine.LNX.4.61.0409290711450.4439@scipy.org>	<415BBA66.802@enthought.com>
	<415C65DD.30204@colorado.edu> <415CC25E.6080900@enthought.com>
	<415CD4F3.9060004@colorado.edu> <415CF248.1070309@enthought.com>
	<415D81F1.2000302@colorado.edu>
Message-ID: <87A596B9-13C6-11D9-9093-000A956FDAC0@fisher.forestry.uga.edu>

So, returning to the original subject of this thread, has anyone had a 
chance to take a peek at PyMC, to assess whether it is something that 
SciPy would benefit from having? The response has been positive so far, 
so if integration of the MCMC, KF and RL modules from PyMC was to 
occur, what would be the initial steps toward this? I assume this would 
occur after the move to SVN, reorganization, etc.

Cheers,
Chris

--
Christopher J. Fonnesbeck ( f o n n e s b e c k @ m a c . c o m )
Georgia Cooperative Fish & Wildlife Research Unit
University of Georgia, Athens GA



From prabhu at aero.iitm.ernet.in  Fri Oct  1 12:31:22 2004
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Fri, 1 Oct 2004 22:01:22 +0530
Subject: [SciPy-dev] gui_thread and wxPython-2.5.2.8
In-Reply-To: <415D81CB.1080800@colorado.edu>
References: <16733.28710.594895.848623@monster.linux.in>
	<415D81CB.1080800@colorado.edu>
Message-ID: <16733.34394.636979.103254@monster.linux.in>

>>>>> "FP" == Fernando Perez <Fernando.Perez at colorado.edu> writes:

    FP> Prabhu Ramachandran schrieb:
    >> Any advice would be appreciated.  In any case the result of my
    >> hacking is that with 2 small patches one can use gui_thread
    >> fully from within IPython for both new and old (not tested but
    >> should work) versions of wxPython.
    >>
    >> Also, if 0.3.2 is round the corner is this a good thing to push
    >> into scipy?  I am not sure how many folks use gui_thread, but
    >> it would certainly be cool if this could make it into 0.3.2.

    FP> This is great, as far as I'm concerned.  I'm sorry I can't

Thanks for the feedback!  Much appreciated.

    FP> currently help, as I'm too swamped on the next ipython
    FP> release.  But since that work is geared to make
    FP> ipython+matplotlib work as smoothly as possible with wx and
    FP> gtk, having this in the scipy release would be a great
    FP> complement.

In theory, gui_thread could be extended to work for PyGtk also but
that will take time and effort and most of all a reasonably intimate
knowledge of PyGtk.

    FP> These gui/threading issues are _way_ over the head of most
    FP> day-to-day scientists (including myself :), so the more we can

Well, I took a long while tracking this one down.  Considering that I
wrote an earlier version of this a long while ago, I can completely
understand the difficulty.  I think Pearu's approach is really quite
elegant and works well.  My primary difficulty was figuring out where
the problem was!

I have a question that you might be able to help with.  I want to do
this:

    Create a module that shadows an existing module in the filesystem.
    Lets say, site-packages/wx/__init__.py.  I want to create a new
    module with code that does something else (and not have to create
    a file!).  Like say: "def f(): print 'hello world'", call that the "wx"
    module, and make Python believe nothing is wrong (insert it into
    sys.modules or whatever) then do a 'reload(wx)' to re-read the
    real __init__.py just like normal.  I'd like the code to be simple
    and not have to use complex import hooks.

Is this possible?  If it is I could probably eliminate the wxPython
patch.

cheers,
prabhu



From oliphant at ee.byu.edu  Fri Oct  1 12:39:07 2004
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Fri, 01 Oct 2004 10:39:07 -0600
Subject: [SciPy-dev] Re: [Scipy-cvs] world/scipy_core/scipy_distutils
	from_template.py, 1.6, 1.7
In-Reply-To: <Pine.LNX.4.21.0410011406430.9973-100000@cens.kybi>
References: <Pine.LNX.4.21.0410011406430.9973-100000@cens.kybi>
Message-ID: <415D882B.3040903@ee.byu.edu>

Pearu Peterson wrote:

>Travis,
>
>What is the reason that process_str() lowers its input?
>There may be other macros in addition to MIN, MAX that .pyf files may
>contain and it would be nice to if process_str would not lower the input.
>
>  
>
I think because fortran is not case-sensitive and it made some of the 
programming easier at first.   But, you are right that it does seem to 
create problems that will only grow.  A better fix is to not alter the 
input.  I didn't want to worry about that last night....

-Travis



From oliphant at ee.byu.edu  Fri Oct  1 12:49:02 2004
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Fri, 01 Oct 2004 10:49:02 -0600
Subject: [SciPy-dev] Pre-release fixes
In-Reply-To: <415CDA23.8030807@ucsd.edu>
References: <415CAC60.4060604@ucsd.edu> <415CD1D4.8010004@ee.byu.edu>
	<415CDA23.8030807@ucsd.edu>
Message-ID: <415D8A7E.6070005@ee.byu.edu>

Robert Kern wrote:

> Travis Oliphant wrote:
>
>> Robert Kern wrote:
>>
>>> I've just checked in a fix for fastumath's logical functions. They 
>>> used to give wrong answers on OSX and caused some tests to fail. I 
>>> believe this to be an endianness issue, but I don't have another 
>>> big-endian machine to test on. All tests still pass on Athlon/Linux.
>>>
>>> The changes made largely track what Numeric did, so I'm not sure if 
>>> these were conscious deviations to speed up fastumath or just a 
>>> failure to keep up with the bugfixes in Numeric.
>>>
>>> I have only implemented fastumath_unsigned.inc as yet. I will make 
>>> similar changes in fastumath_nounsigned.inc as I accumulate tuits.
>>>
>>> Travis, could you check my changes to make sure I didn't revert 
>>> differences you deliberately made? If they were deliberate, then we 
>>> need to figure a way to revert to the correct, if slower, Numeric 
>>> implementations on the Mac.
>>
>>
>>
>> I'm not sure what the problem is here.  But I think you undid 
>> deliberate changes that have implications for alter_numeric() and 
>> need to be discussed. I had intentially made the results of all 
>> logical operations be unsigned bytes.  What was broken about this on 
>> the Mac?
>
>
> Here are the tests that fail. The first two are what led me to the 
> "fix" in the first place. The CDF failures are newer (I haven't seen 
> them until today because I always used my version of 
> fastumath_unsigned.inc for some months now), but all tests pass with 
> my version.
>
> A quick summary:
>
I appreciate you finding this bug.   I had no idea it was there and it 
has probably been there for some time. 

What I don't get is that your fix just changes the type of the pointer 
to be assigned to, but (presumably) doesn't change the type of the array 
being populated.  So, why doesn't this create problems?

How can you have an output array that is UInt8 but assign to it as if it 
were Int32?  This seems like an endian-ness issue and your fix is 
fooling the MAC platform.  But, how would this work on other 
little-endian platforms?

-Travis




From Fernando.Perez at colorado.edu  Fri Oct  1 12:54:39 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 01 Oct 2004 10:54:39 -0600
Subject: [SciPy-dev] gui_thread and wxPython-2.5.2.8
In-Reply-To: <16733.34394.636979.103254@monster.linux.in>
References: <16733.28710.594895.848623@monster.linux.in>
	<415D81CB.1080800@colorado.edu>
	<16733.34394.636979.103254@monster.linux.in>
Message-ID: <415D8BCF.5020605@colorado.edu>

Prabhu Ramachandran schrieb:

> I have a question that you might be able to help with.  I want to do
> this:
> 
>     Create a module that shadows an existing module in the filesystem.
>     Lets say, site-packages/wx/__init__.py.  I want to create a new
>     module with code that does something else (and not have to create
>     a file!).  Like say: "def f(): print 'hello world'", call that the "wx"
>     module, and make Python believe nothing is wrong (insert it into
>     sys.modules or whatever) then do a 'reload(wx)' to re-read the
>     real __init__.py just like normal.  I'd like the code to be simple
>     and not have to use complex import hooks.
> 
> Is this possible?  If it is I could probably eliminate the wxPython
> patch.

I think it is possible.  You can fool python's idea of what a module is quite 
easily:

In [14]: sys.modules['code'] = sys.modules['time']

In [15]: code.<TAB>
code.accept2dyear  code.daylight      code.strftime      code.tzname
code.altzone       code.gmtime        code.strptime      code.tzset
code.asctime       code.localtime     code.struct_time
code.clock         code.mktime        code.time
code.ctime         code.sleep         code.timezone

These are all time's functions :)

In [15]: reload code
-------> reload(code)
Out[15]: <module 'time' from '/usr/lib/python2.3/lib-dynload/timemodule.so'>

So I think what you have in mind should work.  My only concern is that you 
seem to want to reload the _original_ wx/__init__.py, so I'm not sure I 
understand correclty where you want to do the trapping.  But overall, I think 
this kind of game can _definitely_ be played from the outside of Wx.  This is 
one of the benefits of python's extremely strong dynamic nature.

Best,

f



From oliphant at ee.byu.edu  Fri Oct  1 12:57:05 2004
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Fri, 01 Oct 2004 10:57:05 -0600
Subject: [SciPy-dev] Pre-release fixes
In-Reply-To: <415CDA23.8030807@ucsd.edu>
References: <415CAC60.4060604@ucsd.edu> <415CD1D4.8010004@ee.byu.edu>
	<415CDA23.8030807@ucsd.edu>
Message-ID: <415D8C61.3040604@ee.byu.edu>

Robert Kern wrote:

> Travis Oliphant wrote:
>
>> Robert Kern wrote:
>>
>>> I've just checked in a fix for fastumath's logical functions. They 
>>> used to give wrong answers on OSX and caused some tests to fail. I 
>>> believe this to be an endianness issue, but I don't have another 
>>> big-endian machine to test on. All tests still pass on Athlon/Linux.
>>>
>>> The changes made largely track what Numeric did, so I'm not sure if 
>>> these were conscious deviations to speed up fastumath or just a 
>>> failure to keep up with the bugfixes in Numeric.
>>>
>>> I have only implemented fastumath_unsigned.inc as yet. I will make 
>>> similar changes in fastumath_nounsigned.inc as I accumulate tuits.
>>>
>>> Travis, could you check my changes to make sure I didn't revert 
>>> differences you deliberately made? If they were deliberate, then we 
>>> need to figure a way to revert to the correct, if slower, Numeric 
>>> implementations on the Mac.
>>
>>
>>
>> I'm not sure what the problem is here.  But I think you undid 
>> deliberate changes that have implications for alter_numeric() and 
>> need to be discussed. I had intentially made the results of all 
>> logical operations be unsigned bytes.  What was broken about this on 
>> the Mac?
>
>
> Here are the tests that fail. The first two are what led me to the 
> "fix" in the first place. The CDF failures are newer (I haven't seen 
> them until today because I always used my version of 
> fastumath_unsigned.inc for some months now), but all tests pass with 
> my version.
>

I think I know what is wrong.  Apparently, the reduce method expects the 
output type to be the same as the input type.  So, when the underlying 
code is called in that context, what actually gets passed in is not an 
unsigned byte array.  Thus, when the code casts the pointer to an 
unsigned byte pointer, it is filling in only a portion of the memory.  
On little-endian machines this is working fine, but on big-endian 
machines it's the wrong portion to be filling in.   Robert's fix will 
correct the problem for reduce on MacOS but then I'm not sure that 
logical_and will work correctly on two arrays still as in that context 
the output array should be a UInt8 and so you will be filling a UInt8 
array assuming it is IntXX. 

Bottom line is I don't think the fixes will work on all platforms but 
will fix one at the expense of another?  Can you comment on this Robert?

Darn,  this seems like a pretty serious problem.

-Travis



From pearu at scipy.org  Fri Oct  1 13:19:29 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Fri, 1 Oct 2004 12:19:29 -0500 (CDT)
Subject: [SciPy-dev] Re: [Scipy-cvs] world/scipy_core/scipy_distutils
	from_template.py, 1.6, 1.7
In-Reply-To: <415D882B.3040903@ee.byu.edu>
References: <Pine.LNX.4.21.0410011406430.9973-100000@cens.kybi>
	<415D882B.3040903@ee.byu.edu>
Message-ID: <Pine.LNX.4.61.0410011213120.21635@scipy.org>



On Fri, 1 Oct 2004, Travis Oliphant wrote:

>> What is the reason that process_str() lowers its input?
>> There may be other macros in addition to MIN, MAX that .pyf files may
>> contain and it would be nice to if process_str would not lower the input.
>> 
>> 
> I think because fortran is not case-sensitive and it made some of the 
> programming easier at first.   But, you are right that it does seem to create 
> problems that will only grow.  A better fix is to not alter the input.  I 
> didn't want to worry about that last night....

Using re.I in the arguments of re functions should force case-insensitivity
where required (e.g. matching subroutine|function blocks etc.).

At the moment the current approach is fine with me but in future (after 
0.3.2) I'd like to make from_template.py more robust as it is used also
for a .pyf file which content is case-sensitive.

Pearu



From oliphant at ee.byu.edu  Fri Oct  1 13:49:23 2004
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Fri, 01 Oct 2004 11:49:23 -0600
Subject: [SciPy-dev] Re: [Scipy-cvs] world/scipy_core/scipy_distutils
	from_template.py, 1.6, 1.7
In-Reply-To: <Pine.LNX.4.61.0410011213120.21635@scipy.org>
References: <Pine.LNX.4.21.0410011406430.9973-100000@cens.kybi>
	<415D882B.3040903@ee.byu.edu>
	<Pine.LNX.4.61.0410011213120.21635@scipy.org>
Message-ID: <415D98A3.7070406@ee.byu.edu>

Pearu Peterson wrote:

>
> Using re.I in the arguments of re functions should force 
> case-insensitivity
> where required (e.g. matching subroutine|function blocks etc.).
>
> At the moment the current approach is fine with me but in future 
> (after 0.3.2) I'd like to make from_template.py more robust as it is 
> used also
> for a .pyf file which content is case-sensitive.
>
Agreed.



From nwagner at mecha.uni-stuttgart.de  Fri Oct  1 13:56:21 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Fri, 01 Oct 2004 19:56:21 +0200
Subject: [SciPy-dev] Hessenberg form
In-Reply-To: <Mahogany-0.66.0-1532-20041001-114646.00@american.edu>
Message-ID: <web-9961617@uni-stuttgart.de>

On Fri, 1 Oct 2004 09:20:14 -0400 (Eastern Daylight Time)
  Alan G Isaac <aisaac at american.edu> wrote:
>On Fri, 01 Oct 2004, Nils Wagner apparently wrote:
>> I'd like to have a function called hess
>> in linalg which reduces a general matrix A to upper 
>>Hessenberg form
>> before the next release.
>> Any comment ?
>
>The suggested name is perhaps unfortunate.  I would 
>expect
>hess to take a function and point as arguments and to 
>return
>a matrix of numerical partial derivatives (i.e., the
>Hessian).
>
>Cheers,
>Alan Isaac
>
BTW, Matlab uses the same naming convention.

http://www.mathworks.com/access/helpdesk/help/techdoc/ref/hess.html

Cheers,

          Nils

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

Dr.-Ing. Nils Wagner

Universit?t Stuttgart
Institut A f?r Mechanik

Pfaffenwaldring 9
D-70550 Stuttgart

Phone: +49 (0)711 685 6262
Fax:   +49 (0)711 685 6282

E-mail: nwagner at mecha.uni-stuttgart.de
URL:    http://www.mecha.uni-stuttgart.de



From Fernando.Perez at colorado.edu  Fri Oct  1 14:05:44 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 01 Oct 2004 12:05:44 -0600
Subject: [SciPy-dev] Hessenberg form
In-Reply-To: <web-9961617@uni-stuttgart.de>
References: <web-9961617@uni-stuttgart.de>
Message-ID: <415D9C78.9070300@colorado.edu>

Nils Wagner schrieb:
> On Fri, 1 Oct 2004 09:20:14 -0400 (Eastern Daylight Time)
>   Alan G Isaac <aisaac at american.edu> wrote:
> 
>>On Fri, 01 Oct 2004, Nils Wagner apparently wrote:
>>
>>>I'd like to have a function called hess
>>>in linalg which reduces a general matrix A to upper 
>>>Hessenberg form
>>>before the next release.
>>>Any comment ?
>>
>>The suggested name is perhaps unfortunate.  I would 
>>expect
>>hess to take a function and point as arguments and to 
>>return
>>a matrix of numerical partial derivatives (i.e., the
>>Hessian).
>>
>>Cheers,
>>Alan Isaac
>>
> 
> BTW, Matlab uses the same naming convention.
> 
> http://www.mathworks.com/access/helpdesk/help/techdoc/ref/hess.html

Which doesn't make it right.

I'd actually much rather have hessian and hessenberg be the actual names, to 
avoid this kind of potential confusion.  Long names may be a bit annoying, but 
in my book clarity tends to win.  Individual users can always do 
'hess=hessenberg' inside their codes if so desired, away from public shame :)

Best,

f



From prabhu at aero.iitm.ernet.in  Fri Oct  1 15:24:09 2004
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Sat, 2 Oct 2004 00:54:09 +0530
Subject: [SciPy-dev] gui_thread and wxPython-2.5.2.8
In-Reply-To: <415D8BCF.5020605@colorado.edu>
References: <16733.28710.594895.848623@monster.linux.in>
	<415D81CB.1080800@colorado.edu>
	<16733.34394.636979.103254@monster.linux.in>
	<415D8BCF.5020605@colorado.edu>
Message-ID: <16733.44761.20641.733372@monster.linux.in>

>>>>> "FP" == Fernando Perez <Fernando.Perez at colorado.edu> writes:

    >> Is this possible?  If it is I could probably eliminate the
    >> wxPython patch.

    FP> I think it is possible.  You can fool python's idea of what a
    FP> module is quite easily:

    FP> In [14]: sys.modules['code'] = sys.modules['time']

Well, what do you think I've been doing all day? ;-) Thanks anyway for
the suggestion.  I tried again armed with working code and tasted
success at last!  I have a patch for gui_thread that requires no
modifications to wxPython itself!  All that slogging was of use in the
end. :-)

Essentially, I have wxPython-2.5.x apps working from IPython via
gui_thread.  I don't have wxPython-2.4.x handy here but I don't think
I have changed anything in the code for that.  There is one irritating
warning message from pexec on exit from the interpreter but I can live
with that.

I think I'll check in my changes in a little while.  Please do test it
out and let me know if there are problems.  I'm particularly
interested in other platforms, Windows, Mac and also wxPython-2.4.x.

Here is a simple test you can run:

import gui_thread
gui_thread.start()
from gui_thread.examples import SimpleFrame
a = SimpleFrame()
a.Show()
a.SetTitle('Hey! this works!')


cheers,
prabhu



From rkern at ucsd.edu  Fri Oct  1 15:47:09 2004
From: rkern at ucsd.edu (Robert Kern)
Date: Fri, 01 Oct 2004 12:47:09 -0700
Subject: [SciPy-dev] Pre-release fixes
In-Reply-To: <415D8C61.3040604@ee.byu.edu>
References: <415CAC60.4060604@ucsd.edu> <415CD1D4.8010004@ee.byu.edu>
	<415CDA23.8030807@ucsd.edu> <415D8C61.3040604@ee.byu.edu>
Message-ID: <415DB43D.6020602@ucsd.edu>

Travis Oliphant wrote:
[snip]
> I think I know what is wrong.  Apparently, the reduce method expects the 
> output type to be the same as the input type.  So, when the underlying 
> code is called in that context, what actually gets passed in is not an 
> unsigned byte array.  Thus, when the code casts the pointer to an 
> unsigned byte pointer, it is filling in only a portion of the memory.  
> On little-endian machines this is working fine, but on big-endian 
> machines it's the wrong portion to be filling in.   Robert's fix will 
> correct the problem for reduce on MacOS but then I'm not sure that 
> logical_and will work correctly on two arrays still as in that context 
> the output array should be a UInt8 and so you will be filling a UInt8 
> array assuming it is IntXX.

Check the signatures again. The logical_* functions use 
divide_safe_signatures which does not output to UInt8.

CVS on Athlon/Linux:

 >>> from scipy import *
 >>> a = array([0,1])
 >>> b = array([1,1])
 >>> logical_and(a,b)
array([0, 1])
 >>> logical_and(a.astype(Float),b.astype(Float))
array([  0.00000000e+000,   4.94065646e-324])
 >>> logical_and(a.astype(Float32),b.astype(Float32))
array([  0.00000000e+000   1.40129846e-45],'f')
 >>> logical_and.reduce(array([[0,1],[1,1]]).astype(Float))
array([ 0.,  1.])
 >>> import struct
 >>> struct.unpack('f', '\x01\x00\x00\x00')
(1.4012984643248171e-45,)
 >>> struct.unpack('d', '\x01\x00\x00\x00\x00\x00\x00\x00')
(4.9406564584124654e-324,)

> Bottom line is I don't think the fixes will work on all platforms but 
> will fix one at the expense of another?  Can you comment on this Robert?

Yes, just changing the signatures to correctly output to UInt8 solves 
the logical_and(a, b) problem just fine with either endianness. The 
logical_and.reduce(b) problem needs more work. Even changing the 
signatures still makes logical_and.reduce(b) return an array the same 
type as b.

> Darn,  this seems like a pretty serious problem.
> 
> -Travis

-- 
Robert Kern
rkern at ucsd.edu

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



From prabhu at aero.iitm.ernet.in  Fri Oct  1 15:50:35 2004
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Sat, 2 Oct 2004 01:20:35 +0530
Subject: [SciPy-dev] gui_thread and wxPython-2.5.2.8
In-Reply-To: <16733.44761.20641.733372@monster.linux.in>
References: <16733.28710.594895.848623@monster.linux.in>
	<415D81CB.1080800@colorado.edu>
	<16733.34394.636979.103254@monster.linux.in>
	<415D8BCF.5020605@colorado.edu>
	<16733.44761.20641.733372@monster.linux.in>
Message-ID: <16733.46347.277148.567665@monster.linux.in>

>>>>> "PR" == Prabhu Ramachandran <prabhu at aero.iitm.ernet.in> writes:

    PR> I think I'll check in my changes in a little while.  Please do
    PR> test it out and let me know if there are problems.  I'm
    PR> particularly interested in other platforms, Windows, Mac and
    PR> also wxPython-2.4.x.

I've just checked this in.  Please do test it and let me know if there
are problems.

Thanks!

cheers,
prabhu



From Fernando.Perez at colorado.edu  Fri Oct  1 16:28:42 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 01 Oct 2004 14:28:42 -0600
Subject: [SciPy-dev] gui_thread and wxPython-2.5.2.8
In-Reply-To: <16733.44761.20641.733372@monster.linux.in>
References: <16733.28710.594895.848623@monster.linux.in>
	<415D81CB.1080800@colorado.edu>	<16733.34394.636979.103254@monster.linux.in>
	<415D8BCF.5020605@colorado.edu>
	<16733.44761.20641.733372@monster.linux.in>
Message-ID: <415DBDFA.9050601@colorado.edu>

Prabhu Ramachandran schrieb:

> Essentially, I have wxPython-2.5.x apps working from IPython via
> gui_thread.  I don't have wxPython-2.4.x handy here but I don't think
> I have changed anything in the code for that.  There is one irritating
> warning message from pexec on exit from the interpreter but I can live
> with that.

This is great.  Having this work reliably will be a big boon for anyone 
wanting to do GUI work, but I'm most interested right now in matplotlib.  I've 
been working on trying to have ipython run all the matplotlib examples 
reliably, and the ones that try to build a full gui blow it up badly.  I've 
suggested to John adding an ipython trap, which would at least prevent the 
crashes.  But with the gui_thread work, we could simply build it in 
completely, and have a suggestion for new users:

1. Get scipy, matplotlib and ipython current.
2. Set your matplotlib GUI choice to WXAgg.
3. Everything works automatically!  Plots, full guis, interactive control of 
the gui from within the shell, etc.

I think this is the kind of setup which will really attract new users.

> 
> I think I'll check in my changes in a little while.  Please do test it
> out and let me know if there are problems.  I'm particularly
> interested in other platforms, Windows, Mac and also wxPython-2.4.x.
> 
> Here is a simple test you can run:
> 
> import gui_thread
> gui_thread.start()

Is there any reason the gui_thread module can't just call start() itself upon 
import?  Are there valid situations where one may want to delay this call?

> from gui_thread.examples import SimpleFrame
> a = SimpleFrame()
> a.Show()
> a.SetTitle('Hey! this works!')

Unfortunately it doesn't work with 2.4:

In [2]: wx.VERSION
Out[2]: (2, 4, 2, 4, 'u')

New session:

In [1]: import gui_thread

In [2]: gui_thread.start()
Traceback (most recent call last):
   File "scipy_base/pexec.py", line 56, in run
     exec (code, frame.f_globals,frame.f_locals)
   File "<string>", line 3, in ?
ImportError: /usr/lib/python2.3/site-packages/wx/_core_.so: cannot open shared 
object file: No such file or directory

I can't build 2.5 right now, sorry.  2.4 is what my Fedora Core 2 box has:

Looking in Installed Packages:
Name                                Arch   Version                  Repo
--------------------------------------------------------------------------------
wxPythonGTK2                        i386   2.4.2.4-0.fdr.3.2        db


Cheers,

f



From pearu at scipy.org  Fri Oct  1 16:53:00 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Fri, 1 Oct 2004 15:53:00 -0500 (CDT)
Subject: [SciPy-dev] gui_thread and wxPython-2.5.2.8
In-Reply-To: <415DBDFA.9050601@colorado.edu>
References: <16733.28710.594895.848623@monster.linux.in>
	<415D81CB.1080800@colorado.edu><415D8BCF.5020605@colorado.edu>
	<415DBDFA.9050601@colorado.edu>
Message-ID: <Pine.LNX.4.61.0410011551300.21635@scipy.org>



On Fri, 1 Oct 2004, Fernando Perez wrote:

>> I think I'll check in my changes in a little while.  Please do test it
>> out and let me know if there are problems.  I'm particularly
>> interested in other platforms, Windows, Mac and also wxPython-2.4.x.
>> 
>> Here is a simple test you can run:
>> 
>> import gui_thread
>> gui_thread.start()
>
> Is there any reason the gui_thread module can't just call start() itself upon 
> import?  Are there valid situations where one may want to delay this call?
>
>> from gui_thread.examples import SimpleFrame
>> a = SimpleFrame()
>> a.Show()
>> a.SetTitle('Hey! this works!')
>
> Unfortunately it doesn't work with 2.4:
>
> In [2]: wx.VERSION
> Out[2]: (2, 4, 2, 4, 'u')
>
> New session:
>
> In [1]: import gui_thread
>
> In [2]: gui_thread.start()
> Traceback (most recent call last):
>  File "scipy_base/pexec.py", line 56, in run
>    exec (code, frame.f_globals,frame.f_locals)
>  File "<string>", line 3, in ?
> ImportError: /usr/lib/python2.3/site-packages/wx/_core_.so: cannot open 
> shared object file: No such file or directory

I got the same error and the fix is soon in CVS..

Pearu



From pearu at scipy.org  Fri Oct  1 17:00:06 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Fri, 1 Oct 2004 16:00:06 -0500 (CDT)
Subject: [SciPy-dev] gui_thread and wxPython-2.5.2.8
In-Reply-To: <16733.44761.20641.733372@monster.linux.in>
References: <16733.28710.594895.848623@monster.linux.in>
	<415D81CB.1080800@colorado.edu><415D8BCF.5020605@colorado.edu>
	<16733.44761.20641.733372@monster.linux.in>
Message-ID: <Pine.LNX.4.61.0410011556100.21635@scipy.org>



On Sat, 2 Oct 2004, Prabhu Ramachandran wrote:

> I think I'll check in my changes in a little while.  Please do test it
> out and let me know if there are problems.  I'm particularly
> interested in other platforms, Windows, Mac and also wxPython-2.4.x.
>
> Here is a simple test you can run:
>
> import gui_thread
> gui_thread.start()
> from gui_thread.examples import SimpleFrame
> a = SimpleFrame()
> a.Show()
> a.SetTitle('Hey! this works!')

With the patch that I just commited to CVS this example works
with wxPython-2.4.x. However there seems to be still some issues.
For example, adding

   b = SimpleFrame()

to the simple test will segfault Python.
Or, when closing the frame and then running

   a = SimpleFrame()

again will hang Python.

Does this happen also with wx-2.5?

Pearu



From aisaac at american.edu  Fri Oct  1 16:41:46 2004
From: aisaac at american.edu (Alan G Isaac)
Date: Fri, 1 Oct 2004 16:41:46 -0400 (Eastern Daylight Time)
Subject: [SciPy-dev] Hessenberg form
In-Reply-To: <415D9C78.9070300@colorado.edu>
References: <web-9961617@uni-stuttgart.de><415D9C78.9070300@colorado.edu>
Message-ID: <Mahogany-0.66.0-1464-20041001-165041.00@american.edu>

>> BTW, Matlab uses the same naming convention.
>> http://www.mathworks.com/access/helpdesk/help/techdoc/ref/hess.html

On Fri, 01 Oct 2004, Fernando Perez apparently wrote:
> Which doesn't make it right.
> I'd actually much rather have hessian and hessenberg be the actual names, to
> avoid this kind of potential confusion.  Long names may be a bit annoying, but
> in my book clarity tends to win.  Individual users can always do
> 'hess=hessenberg' inside their codes if so desired, away from public shame :)

I strongly agree.
Cheers,
Alan Isaac
PS As a contrast to Matlab, hessp() does the Hessian
computation in GAUSS.




From Fernando.Perez at colorado.edu  Fri Oct  1 16:49:49 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 01 Oct 2004 14:49:49 -0600
Subject: [SciPy-dev] gui_thread and wxPython-2.5.2.8
In-Reply-To: <Pine.LNX.4.61.0410011551300.21635@scipy.org>
References: <16733.28710.594895.848623@monster.linux.in>
	<415D81CB.1080800@colorado.edu><415D8BCF.5020605@colorado.edu>
	<415DBDFA.9050601@colorado.edu>
	<Pine.LNX.4.61.0410011551300.21635@scipy.org>
Message-ID: <415DC2ED.3040905@colorado.edu>

Pearu Peterson schrieb:

>>In [1]: import gui_thread
>>
>>In [2]: gui_thread.start()
>>Traceback (most recent call last):
>> File "scipy_base/pexec.py", line 56, in run
>>   exec (code, frame.f_globals,frame.f_locals)
>> File "<string>", line 3, in ?
>>ImportError: /usr/lib/python2.3/site-packages/wx/_core_.so: cannot open 
>>shared object file: No such file or directory
> 
> 
> I got the same error and the fix is soon in CVS..

Great.  I just checked it and it works here.  In the normal python interpreter 
I got a strange threading exception upon exit on one occasion, but I can't 
reproduce it.  On others, I get segfaults upon exit.

For whatever strange reason, ipython doesn't segfault.

Best,

f



From Fernando.Perez at colorado.edu  Fri Oct  1 16:53:34 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 01 Oct 2004 14:53:34 -0600
Subject: [SciPy-dev] gui_thread and wxPython-2.5.2.8
In-Reply-To: <Pine.LNX.4.61.0410011556100.21635@scipy.org>
References: <16733.28710.594895.848623@monster.linux.in>
	<415D81CB.1080800@colorado.edu><415D8BCF.5020605@colorado.edu>
	<16733.44761.20641.733372@monster.linux.in>
	<Pine.LNX.4.61.0410011556100.21635@scipy.org>
Message-ID: <415DC3CE.3060107@colorado.edu>

Pearu Peterson schrieb:
> 
> On Sat, 2 Oct 2004, Prabhu Ramachandran wrote:
> 
> 
>>I think I'll check in my changes in a little while.  Please do test it
>>out and let me know if there are problems.  I'm particularly
>>interested in other platforms, Windows, Mac and also wxPython-2.4.x.
>>
>>Here is a simple test you can run:
>>
>>import gui_thread
>>gui_thread.start()
>>from gui_thread.examples import SimpleFrame
>>a = SimpleFrame()
>>a.Show()
>>a.SetTitle('Hey! this works!')
> 
> 
> With the patch that I just commited to CVS this example works
> with wxPython-2.4.x. However there seems to be still some issues.
> For example, adding
> 
>    b = SimpleFrame()
> 
> to the simple test will segfault Python.
> Or, when closing the frame and then running
> 
>    a = SimpleFrame()
> 
> again will hang Python.

Somewhat similar results here, but not identical.  I can add/show a few more 
frames and it seems to work for a while (add, .Show(), close, etc).  But 
eventually I do get a segfault.  It happens eventually, but not necessarily on 
the 2nd (or third...) try always.  Again, this is under wxpython 2.4.

Cheers,

f



From prabhu at aero.iitm.ernet.in  Fri Oct  1 17:01:31 2004
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Sat, 2 Oct 2004 02:31:31 +0530
Subject: [SciPy-dev] gui_thread and wxPython-2.5.2.8
In-Reply-To: <Pine.LNX.4.61.0410011556100.21635@scipy.org>
References: <16733.28710.594895.848623@monster.linux.in>
	<415D81CB.1080800@colorado.edu> <415D8BCF.5020605@colorado.edu>
	<16733.44761.20641.733372@monster.linux.in>
	<Pine.LNX.4.61.0410011556100.21635@scipy.org>
Message-ID: <16733.50603.415489.287314@monster.linux.in>

>>>>> "PP" == Pearu Peterson <pearu at scipy.org> writes:

    PP> On Sat, 2 Oct 2004, Prabhu Ramachandran wrote:

    PP> With the patch that I just commited to CVS this example works
    PP> with wxPython-2.4.x. However there seems to be still some
    PP> issues.  For example, adding

    PP>    b = SimpleFrame()

    PP> to the simple test will segfault Python.  Or, when closing the
    PP> frame and then running

    PP>    a = SimpleFrame()

    PP> again will hang Python.

    PP> Does this happen also with wx-2.5?

Hmm, thats very strange.  I don't get this error on 2.5.x *but* on any
complex application I do get hard to debug, wierd and random errors.
So it appears that all is not well.  Also, does wxPython-2.4.x have a
'wx/' directory in sys.path?  If that is not the case, _import_wx_core
should never be called and the errors Fernando or you are seeing
should not show up since nothing should have changed in these cases
from the original behavior.  Unless the original behavior was itself
broken.

I'll try and check this stuff out on another machine tommorow.

cheers,
prabhu



From Fernando.Perez at colorado.edu  Fri Oct  1 17:05:44 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 01 Oct 2004 15:05:44 -0600
Subject: [SciPy-dev] gui_thread and wxPython-2.5.2.8
In-Reply-To: <16733.50603.415489.287314@monster.linux.in>
References: <16733.28710.594895.848623@monster.linux.in>
	<415D81CB.1080800@colorado.edu> <415D8BCF.5020605@colorado.edu>
	<16733.44761.20641.733372@monster.linux.in>
	<Pine.LNX.4.61.0410011556100.21635@scipy.org>
	<16733.50603.415489.287314@monster.linux.in>
Message-ID: <415DC6A8.7080402@colorado.edu>

Prabhu Ramachandran schrieb:
>>>>>>"PP" == Pearu Peterson <pearu at scipy.org> writes:
> 
> 
>     PP> On Sat, 2 Oct 2004, Prabhu Ramachandran wrote:
> 
>     PP> With the patch that I just commited to CVS this example works
>     PP> with wxPython-2.4.x. However there seems to be still some
>     PP> issues.  For example, adding
> 
>     PP>    b = SimpleFrame()
> 
>     PP> to the simple test will segfault Python.  Or, when closing the
>     PP> frame and then running
> 
>     PP>    a = SimpleFrame()
> 
>     PP> again will hang Python.
> 
>     PP> Does this happen also with wx-2.5?
> 
> Hmm, thats very strange.  I don't get this error on 2.5.x *but* on any
> complex application I do get hard to debug, wierd and random errors.
> So it appears that all is not well.  Also, does wxPython-2.4.x have a
> 'wx/' directory in sys.path?  If that is not the case, _import_wx_core

This is my sys.path:

...
  '/usr/lib/python23.zip',
  '/usr/lib/python2.3',
  '/usr/lib/python2.3/plat-linux2',
  '/usr/lib/python2.3/lib-tk',
  '/usr/lib/python2.3/lib-dynload',
  '/usr/lib/python2.3/site-packages',
  '/usr/lib/python2.3/site-packages/Numeric',
  '/usr/lib/python2.3/site-packages/gtk-2.0',
...

In [6]: wx?
Type:           module
Base Class:     <type 'module'>
String Form:    <module 'wx' from 
'/usr/lib/python2.3/site-packages/wx/__init__.pyc'>

HTH,

f



From oliphant at ee.byu.edu  Fri Oct  1 18:12:53 2004
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Fri, 01 Oct 2004 16:12:53 -0600
Subject: [SciPy-dev] Pre-release fixes
In-Reply-To: <415DB43D.6020602@ucsd.edu>
References: <415CAC60.4060604@ucsd.edu> <415CD1D4.8010004@ee.byu.edu>
	<415CDA23.8030807@ucsd.edu> <415D8C61.3040604@ee.byu.edu>
	<415DB43D.6020602@ucsd.edu>
Message-ID: <415DD665.5010709@ee.byu.edu>

Robert Kern wrote:

> Travis Oliphant wrote:
> [snip]
>
>> I think I know what is wrong.  Apparently, the reduce method expects 
>> the output type to be the same as the input type.  So, when the 
>> underlying code is called in that context, what actually gets passed 
>> in is not an unsigned byte array.  Thus, when the code casts the 
>> pointer to an unsigned byte pointer, it is filling in only a portion 
>> of the memory.  On little-endian machines this is working fine, but 
>> on big-endian machines it's the wrong portion to be filling in.   
>> Robert's fix will correct the problem for reduce on MacOS but then 
>> I'm not sure that logical_and will work correctly on two arrays still 
>> as in that context the output array should be a UInt8 and so you will 
>> be filling a UInt8 array assuming it is IntXX.
>
>
> Check the signatures again. The logical_* functions use 
> divide_safe_signatures which does not output to UInt8.

O.K..

Apparently, the logical_and and logical_or functions cannot be converted 
to have UInt8 output and still have reduce work.

Reduce will only work reliably when the output type is the same as the 
input type.  As logical_and and logical_or are used with reduce quite a 
bit, I think our best option is to do what Robert was doing and keep 
logical_and, logical_or, and logical_xor  as returning the type of their 
inputs.

So, if there are no complaints,  go ahead Robert and submit the changes 
you have made to CVS (I won't get in your way again...) so that 
divide_safe_signatures are O.K. and the logical_XXX functions are 
changed so the output type is the same as the input type.

-Travis





From eric at enthought.com  Fri Oct  1 18:33:08 2004
From: eric at enthought.com (eric jones)
Date: Fri, 01 Oct 2004 17:33:08 -0500
Subject: [SciPy-dev] Hessenberg form
In-Reply-To: <Mahogany-0.66.0-1464-20041001-165041.00@american.edu>
References: <web-9961617@uni-stuttgart.de><415D9C78.9070300@colorado.edu>
	<Mahogany-0.66.0-1464-20041001-165041.00@american.edu>
Message-ID: <415DDB24.7070402@enthought.com>

Alan G Isaac wrote:

>>>BTW, Matlab uses the same naming convention.
>>>http://www.mathworks.com/access/helpdesk/help/techdoc/ref/hess.html
>>>      
>>>
>
>On Fri, 01 Oct 2004, Fernando Perez apparently wrote:
>  
>
>>Which doesn't make it right.
>>I'd actually much rather have hessian and hessenberg be the actual names, to
>>avoid this kind of potential confusion.  Long names may be a bit annoying, but
>>in my book clarity tends to win.  Individual users can always do
>>'hess=hessenberg' inside their codes if so desired, away from public shame :)
>>    
>>
>
>I strongly agree.
>  
>
+1

>Cheers,
>Alan Isaac
>PS As a contrast to Matlab, hessp() does the Hessian
>computation in GAUSS.
>
>
>_______________________________________________
>Scipy-dev mailing list
>Scipy-dev at scipy.net
>http://www.scipy.net/mailman/listinfo/scipy-dev
>  
>




From prabhu at aero.iitm.ernet.in  Sat Oct  2 09:24:11 2004
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Sat, 2 Oct 2004 18:54:11 +0530
Subject: [SciPy-dev] gui_thread and wxPython-2.5.2.8
In-Reply-To: <415DC6A8.7080402@colorado.edu>
References: <16733.28710.594895.848623@monster.linux.in>
	<415D81CB.1080800@colorado.edu> <415D8BCF.5020605@colorado.edu>
	<16733.44761.20641.733372@monster.linux.in>
	<Pine.LNX.4.61.0410011556100.21635@scipy.org>
	<16733.50603.415489.287314@monster.linux.in>
	<415DC6A8.7080402@colorado.edu>
Message-ID: <16734.44027.711214.659475@monster.linux.in>

>>>>> "FP" == Fernando Perez <Fernando.Perez at colorado.edu> writes:

    >> Hmm, thats very strange.  I don't get this error on 2.5.x *but*
    >> on any complex application I do get hard to debug, wierd and
    >> random errors.  So it appears that all is not well.  Also, does
    >> wxPython-2.4.x have a 'wx/' directory in sys.path?  If that is
    >> not the case, _import_wx_core

    FP> This is my sys.path:

    FP> In [6]: wx?  Type: module Base Class: <type 'module'> String
    FP> Form: <module 'wx' from
    FP> '/usr/lib/python2.3/site-packages/wx/__init__.pyc'>

Hmm, in my lab's 2.4.0.7 install there is no such wx directory.  Does
your 'wx' directory have any extension modules?

cheers,
prabhu



From prabhu at aero.iitm.ernet.in  Sat Oct  2 09:16:15 2004
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Sat, 2 Oct 2004 18:46:15 +0530
Subject: [SciPy-dev] gui_thread and wxPython-2.5.2.8
In-Reply-To: <16733.50603.415489.287314@monster.linux.in>
References: <16733.28710.594895.848623@monster.linux.in>
	<415D81CB.1080800@colorado.edu> <415D8BCF.5020605@colorado.edu>
	<16733.44761.20641.733372@monster.linux.in>
	<Pine.LNX.4.61.0410011556100.21635@scipy.org>
	<16733.50603.415489.287314@monster.linux.in>
Message-ID: <16734.43551.930991.925215@monster.linux.in>

>>>>> "PR" == Prabhu Ramachandran <prabhu at aero.iitm.ernet.in> writes:

[ errors with earlier gui_thread ]

    PR> Hmm, thats very strange.  I don't get this error on 2.5.x
    PR> *but* on any complex application I do get hard to debug, wierd
    PR> and random errors.  So it appears that all is not well.  Also,
    PR> does wxPython-2.4.x have a 'wx/' directory in sys.path?  If
    PR> that is not the case, _import_wx_core should never be called
    PR> and the errors Fernando or you are seeing should not show up
    PR> since nothing should have changed in these cases from the
    PR> original behavior.  Unless the original behavior was itself
    PR> broken.

    PR> I'll try and check this stuff out on another machine tommorow.

I did not check it on another machine but have everything working
quite nicely on my machine with wxPython-2.5.2.8u.  So much so that I
can run the wxPythonDemo and apart from one or two items which break,
pretty much everything else runs nicely (including the OpenGL canvas
demos).  Editing traits work, generating several windows also works.

In the earlier code I made some bad mistakes.  Particularly I did not
wait for the imports to complete.  I also did not import all the
extension modules which means some of them were not wrapped.  The
other problem was that there appeared to be a deadlock of some sort
which I've worked around by adding a small timeout to the wait.  This
appears to fix all the hanging interpreter issues.  The proof of the
pudding is that it runs bulk of wxPythonDemo nicely, which is good
enough for me. :)

Now, I haven't tested this under an older version of wxPython.  The
approach I use for the newer 2.5.x series is quite different from that
used in the original code.

Could someone who has wxPython-2.5.x installed please help testing the
code out.  I've spent several hours on this and could use a little
help with the testing on other machines/platforms.

I'll go over my code once and then check my changes in in an hour or
so.  Once that code is in, if others can test on their wx-2.5.x
installations and see if it works ok, we can look at improving the
2.4.x behavior.  I believe the same approach that I use for wx-2.5.x
will work nicely for wxPython-2.4.x.  The idea is that I create a
dummy 'wx' or 'wxPython' module, manually find all the extension
modules to import, import them, generate the wrapper functions for
these, reload the *real* module, then start the threading stuff.  This
works nicely because all the extension modules are wrapped.


cheers,
prabhu



From prabhu at aero.iitm.ernet.in  Sat Oct  2 09:21:06 2004
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Sat, 2 Oct 2004 18:51:06 +0530
Subject: [SciPy-dev] gui_thread and wxPython-2.5.2.8
In-Reply-To: <415DBDFA.9050601@colorado.edu>
References: <16733.28710.594895.848623@monster.linux.in>
	<415D81CB.1080800@colorado.edu>
	<16733.34394.636979.103254@monster.linux.in>
	<415D8BCF.5020605@colorado.edu>
	<16733.44761.20641.733372@monster.linux.in>
	<415DBDFA.9050601@colorado.edu>
Message-ID: <16734.43842.9091.426897@monster.linux.in>

>>>>> "FP" == Fernando Perez <Fernando.Perez at colorado.edu> writes:

[...]
    FP> 1. Get scipy, matplotlib and ipython current.
    FP> 2. Set your matplotlib GUI choice to WXAgg.
    FP> 3. Everything works automatically!  Plots, full guis,
    FP>    interactive control of
    FP> the gui from within the shell, etc.

    FP> I think this is the kind of setup which will really attract
    FP> new users.

Yes, but its not going to be easy.  If we are lucky gui_thread will
just be a stop gap arrangement before IPython can be retargetted to
any Python shell.  I think that will be easier to get working
*reliably* than gui_thread.  But, for now, gui_thread might be a
decent temporary arrangement.

    >> Here is a simple test you can run:
    >>
    >> import gui_thread gui_thread.start()

    FP> Is there any reason the gui_thread module can't just call
    FP> start() itself upon import?  Are there valid situations where
    FP> one may want to delay this call?

Well, this is really so we don't remove the original code.  Gui_thread
is not too well used and not tested out enough for us to know what is
to be removed and whats to be left there.  I just have an IPython
profile to do this job for me.

    >> from gui_thread.examples import SimpleFrame a = SimpleFrame()
    >> a.Show() a.SetTitle('Hey! this works!')

    FP> Unfortunately it doesn't work with 2.4:

    FP> In [2]: wx.VERSION Out[2]: (2, 4, 2, 4, 'u')

Once the wx-2.5 support is reasonably stable, it should hopefully be
easier to get the earlier versions also working.

Thanks for testing and feedback.

cheers,
prabhu



From prabhu at aero.iitm.ernet.in  Sat Oct  2 10:06:48 2004
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Sat, 2 Oct 2004 19:36:48 +0530
Subject: [SciPy-dev] gui_thread: please test under 2.5.x
Message-ID: <16734.46585.305.429444@monster.linux.in>

Hi,

I've checked in a version that works nicely for me from the
interpreter with pretty complex apps like wxPythonDemo.  For example:

 import gui_thread
 gui_thread.start()
 cd <path_to_wxPython_demo>
 import Main
 d = Main.wxPythonDemo(None, 'a')
 d.Show(1)
 d.SetTitle('wxPythonDemo from IPython!')

This well enough for me under wxPython-2.5.2.8u and I'm happy.  I'll
try and work on a version similar to this that works for earlier
wxPython versions.  This version is not guaranteed to work with the
demo for wxPython-2.4.x and is untested for that version.

In the meantime *please* test gui_thread and see if it works for you
on your platform/machine using wxPython-2.5.x.

Thanks!

cheers,
prabhu



From prabhu at aero.iitm.ernet.in  Sat Oct  2 14:46:02 2004
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Sun, 3 Oct 2004 00:16:02 +0530
Subject: [SciPy-dev] gui_thread: works with 2.4.x and 2.5.x!
Message-ID: <16734.63338.619737.327429@monster.linux.in>

Hi everyone,

Finally, some good news!  I have gui_thread working nicely using both
wxPython 2.4.x and 2.5.x on Linux.  I've tested this on Debian Sarge
with wxPython-2.5.2.8u (built from source) and wxPython-2.4.2.6
installed via apt-get install libwxgtk2.4-python.

With the new code I am able to run the respective wxPython demo's
interactively from within IPython and script it!

I've checked in this into CVS.  Please test it out and let me know if
there are problems.

cheers,
prabhu



From Fernando.Perez at colorado.edu  Sat Oct  2 15:24:11 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sat, 02 Oct 2004 13:24:11 -0600
Subject: [SciPy-dev] gui_thread: works with 2.4.x and 2.5.x!
In-Reply-To: <16734.63338.619737.327429@monster.linux.in>
References: <16734.63338.619737.327429@monster.linux.in>
Message-ID: <415F005B.3060107@colorado.edu>

Prabhu Ramachandran wrote:
> Hi everyone,
> 
> Finally, some good news!  I have gui_thread working nicely using both
> wxPython 2.4.x and 2.5.x on Linux.  I've tested this on Debian Sarge
> with wxPython-2.5.2.8u (built from source) and wxPython-2.4.2.6
> installed via apt-get install libwxgtk2.4-python.
> 
> With the new code I am able to run the respective wxPython demo's
> interactively from within IPython and script it!
> 
> I've checked in this into CVS.  Please test it out and let me know if
> there are problems.

I won't have a chance to test this til Monday, unfortunately.  I'll let you 
know then what I get.

Cheers,

f



From pearu at scipy.org  Sat Oct  2 16:28:45 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Sat, 2 Oct 2004 15:28:45 -0500 (CDT)
Subject: [SciPy-dev] gui_thread: works with 2.4.x and 2.5.x!
In-Reply-To: <16734.63338.619737.327429@monster.linux.in>
References: <16734.63338.619737.327429@monster.linux.in>
Message-ID: <Pine.LNX.4.61.0410021438310.21635@scipy.org>



On Sun, 3 Oct 2004, Prabhu Ramachandran wrote:

> Hi everyone,
>
> Finally, some good news!  I have gui_thread working nicely using both
> wxPython 2.4.x and 2.5.x on Linux.  I've tested this on Debian Sarge
> with wxPython-2.5.2.8u (built from source) and wxPython-2.4.2.6
> installed via apt-get install libwxgtk2.4-python.

This is great!

> With the new code I am able to run the respective wxPython demo's
> interactively from within IPython and script it!
>
> I've checked in this into CVS.  Please test it out and let me know if
> there are problems.

No problems here with wxPython 2.4.2.4.

Pearu



From pearu at scipy.org  Sun Oct  3 20:57:21 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Sun, 3 Oct 2004 19:57:21 -0500 (CDT)
Subject: [SciPy-dev] Hessenberg form
In-Reply-To: <415D0ED0.8070704@mecha.uni-stuttgart.de>
References: <415D0ED0.8070704@mecha.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.61.0410031956210.21635@scipy.org>



On Fri, 1 Oct 2004, Nils Wagner wrote:

> Hi all,
>
> I'd like to have a function called hess
> in linalg which reduces a general matrix A to upper Hessenberg form
> before the next release.
>
> Any comment ?

It's now in scipy CVS. See scipy.linalg.hessenberg.

Pearu



From answer at tnoo.net  Mon Oct  4 15:06:23 2004
From: answer at tnoo.net (=?iso-8859-1?q?Martin_L=FCthi?=)
Date: 04 Oct 2004 11:06:23 -0800
Subject: [SciPy-dev] Bug in scipy import
Message-ID: <m3mzz25mmo.fsf@sandy.gi.alaska.edu>

Hi

There is a subtle bug in the import structure of scipy which nearly drove me
crazy.

Here is how to reproduce it:

====
import scipy
====

imports and executes any file named "new.py" in the current working
directory. 

Python 2.3.3 (#1, Apr  6 2004, 01:47:39) 
[GCC 3.3.3 (SuSE Linux)] on linux2

scipy.__version__
'0.3.1_285.4270'

Thanks, Martin
-- 
Martin L?thi                 answer at tnoo.net




From Fernando.Perez at colorado.edu  Mon Oct  4 20:11:20 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Mon, 04 Oct 2004 18:11:20 -0600
Subject: [SciPy-dev] gui_thread and wxPython-2.5.2.8
In-Reply-To: <16733.44761.20641.733372@monster.linux.in>
References: <16733.28710.594895.848623@monster.linux.in>
	<415D81CB.1080800@colorado.edu>	<16733.34394.636979.103254@monster.linux.in>
	<415D8BCF.5020605@colorado.edu>
	<16733.44761.20641.733372@monster.linux.in>
Message-ID: <4161E6A8.4040101@colorado.edu>

Prabhu Ramachandran schrieb:

> Here is a simple test you can run:
> 
> import gui_thread
> gui_thread.start()
> from gui_thread.examples import SimpleFrame
> a = SimpleFrame()
> a.Show()
> a.SetTitle('Hey! this works!')

Mmh :(  With scipy CVS from a moment ago, this is what I'm getting:

In [1]: import gui_thread

In [2]: gui_thread.start()

In [3]: from gui_thread.examples import SimpleFrame
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)

/home/fperez/test/<console>

/home/fperez/test/gui_thread/examples.py

/home/fperez/test/gui_thread/examples.py in SimpleFrame()

/usr/lib/python2.3/site-packages/wxPython/misc.py in __init__(self, *_args, 
**_kwargs)
     102 class wxSize(wxSizePtr):
     103     def __init__(self,*_args,**_kwargs):
--> 104         self.this = miscc.new_wxSize(*_args,**_kwargs)
     105         self.thisown = 1
     106

/home/fperez/test/<string> in new_wxSize(*args, **kws)

AttributeError: AttrHolder instance has no attribute 'result'


And the WxPython demo doesn't seem to work either:

planck[~/test]> cd /usr/share/doc/wxPythonGTK2-2.4.2.4/demo/
planck[demo]> ip
Python 2.3.3 (#1, May  7 2004, 10:31:40)
Type "copyright", "credits" or "license" for more information.

IPython 0.6.4.rc1 -- An enhanced Interactive Python.
?       -> Introduction to IPython's features.
@magic  -> Information about IPython's 'magic' @ functions.
help    -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.

In [1]: import gui_thread

In [2]: gui_thread.start()

In [3]: import Main

In [4]: d = Main.wxPythonDemo(None, 'a')
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)

/usr/share/doc/wxPythonGTK2-2.4.2.4/demo/<console>

TypeError: __init__() takes exactly 4 arguments (3 given)


Is it a problem on my side?  I'll gladly run more tests if you nudge me a bit 
in the right direction.

Best,

f



From prabhu at aero.iitm.ernet.in  Mon Oct  4 22:59:46 2004
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Tue, 5 Oct 2004 08:29:46 +0530
Subject: [SciPy-dev] gui_thread and wxPython-2.5.2.8
In-Reply-To: <4161E6A8.4040101@colorado.edu>
References: <16733.28710.594895.848623@monster.linux.in>
	<415D81CB.1080800@colorado.edu>
	<16733.34394.636979.103254@monster.linux.in>
	<415D8BCF.5020605@colorado.edu>
	<16733.44761.20641.733372@monster.linux.in>
	<4161E6A8.4040101@colorado.edu>
Message-ID: <16738.3618.61873.892612@monster.linux.in>

>>>>> "FP" == Fernando Perez <Fernando.Perez at colorado.edu> writes:

    FP> Prabhu Ramachandran schrieb:
    >> Here is a simple test you can run:
    >>
    >> import gui_thread gui_thread.start() from gui_thread.examples
    >> import SimpleFrame a = SimpleFrame() a.Show() a.SetTitle('Hey!
    >> this works!')

    FP> Mmh :( With scipy CVS from a moment ago, this is what I'm
    FP> getting:

    FP> /home/fperez/test/<string> in new_wxSize(*args, **kws)

    FP> AttributeError: AttrHolder instance has no attribute 'result'

That is wierd I agree but could be due to the first import, my
suspicion is that I need to increase the timeout on the Event object
from 0.5 to a full second or two.  In anycase just try it again (exit
ipython and restart immediately) and it should work.

[...]
    FP> In [4]: d = Main.wxPythonDemo(None, 'a')
    FP> ---------------------------------------------------------------------------
    FP> TypeError Traceback (most recent call last)

    FP> /usr/share/doc/wxPythonGTK2-2.4.2.4/demo/<console>

    FP> TypeError: __init__() takes exactly 4 arguments (3 given)

Well, that is a user error!  :-> 

Just like it says, the 2.4.x demo __init__ takes 3 args and not 2 like
the 2.5.x one does.  Try this:

 d = Main.wxPythonDemo(None, -1, 'a')

Let me know how it goes.  Thanks for testing.

cheers,
prabhu



From oliphant at ee.byu.edu  Tue Oct  5 05:26:52 2004
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Tue, 05 Oct 2004 03:26:52 -0600
Subject: [SciPy-dev] Re: [SciPy-user] Matrix square root
In-Reply-To: <Pine.LNX.4.61.0410040728460.21635@scipy.org>
References: <416132AE.4080509@soton.ac.uk>
	<4161359E.8080403@mecha.uni-stuttgart.de>
	<Pine.LNX.4.61.0410040728460.21635@scipy.org>
Message-ID: <416268DC.3060804@ee.byu.edu>

Pearu Peterson wrote:

>
>
> On Mon, 4 Oct 2004, Nils Wagner wrote:
>
>> AFAIK there is no direct support for sqrtm but you may use funm.
>
>
> I just discovered that there might be a bug in funm. I have added
> a test to scipy.linalg.test_matfuncs that demonstrates the bug.
> So, be aware to check the results of funm(..,sqrt).

As far as I undertand, the idea of a general purpose matrix function has 
precision problems.   The algorithm in scipy is based on a published 
algorithm using the Schur decomposition.   That is why it is usually a 
good idea to write separate algorithms for special matrix functions if 
possible.

Is this really a bug, or just a problem with using the generic funm 
algorithm when a more accurate algorithm exists.

The fact that you can return a reasonable square root for non-special 
matrices makes me believe that it is not a bug in funm, but a 
demonstration that the generic funm algorithm does not always produce 
the best results for specific functions of matrices.  



-Travis O.




From oliphant at ee.byu.edu  Tue Oct  5 05:33:07 2004
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Tue, 05 Oct 2004 03:33:07 -0600
Subject: [SciPy-dev] Bug in scipy import
In-Reply-To: <m3mzz25mmo.fsf@sandy.gi.alaska.edu>
References: <m3mzz25mmo.fsf@sandy.gi.alaska.edu>
Message-ID: <41626A53.5010905@ee.byu.edu>

Martin L?thi wrote:

>Hi
>
>There is a subtle bug in the import structure of scipy which nearly drove me
>crazy.
>
>Here is how to reproduce it:
>
>====
>import scipy
>====
>
>imports and executes any file named "new.py" in the current working
>directory. 
>
>Python 2.3.3 (#1, Apr  6 2004, 01:47:39) 
>[GCC 3.3.3 (SuSE Linux)] on linux2
>
>scipy.__version__
>'0.3.1_285.4270'
>
>  
>
I think this 'bug' will happen anytime you name a file using a Python 
module name that another module is expecting.    Your  new.py file is 
over-riding the Python module new here that parts of scipy depends on.

Try naming a file re.py in your current directory and you will get 
similar problems.  

-Travis



From nwagner at mecha.uni-stuttgart.de  Tue Oct  5 06:30:46 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Tue, 05 Oct 2004 12:30:46 +0200
Subject: [SciPy-dev] Re: [SciPy-user] Matrix square root
In-Reply-To: <416268DC.3060804@ee.byu.edu>
References: <416132AE.4080509@soton.ac.uk>
	<4161359E.8080403@mecha.uni-stuttgart.de>
	<Pine.LNX.4.61.0410040728460.21635@scipy.org>
	<416268DC.3060804@ee.byu.edu>
Message-ID: <416277D6.5020807@mecha.uni-stuttgart.de>

Travis Oliphant wrote:

> Pearu Peterson wrote:
>
>>
>>
>> On Mon, 4 Oct 2004, Nils Wagner wrote:
>>
>>> AFAIK there is no direct support for sqrtm but you may use funm.
>>
>>
>>
>> I just discovered that there might be a bug in funm. I have added
>> a test to scipy.linalg.test_matfuncs that demonstrates the bug.
>> So, be aware to check the results of funm(..,sqrt).
>
>
> As far as I undertand, the idea of a general purpose matrix function 
> has precision problems.   The algorithm in scipy is based on a 
> published algorithm using the Schur decomposition.   That is why it is 
> usually a good idea to write separate algorithms for special matrix 
> functions if possible.
>
> Is this really a bug, or just a problem with using the generic funm 
> algorithm when a more accurate algorithm exists.
>
> The fact that you can return a reasonable square root for non-special 
> matrices makes me believe that it is not a bug in funm, but a 
> demonstration that the generic funm algorithm does not always produce 
> the best results for specific functions of matrices. 
>
>
> -Travis O.
>
>
Travis,

Again, Higham is a source for this issue.
http://www.ma.man.ac.uk/~higham/talks/
How and how not to compute the matrix square root (1997)

Also published in

Numerical Algorithms
*15* (2): 227-242, 1997
/Copyright ? 1997 Kluwer Academic Publishers/
/All rights reserved/


    Stable iterations for the matrix square root


Nils

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



 



From nwagner at mecha.uni-stuttgart.de  Tue Oct  5 06:47:54 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Tue, 05 Oct 2004 12:47:54 +0200
Subject: [SciPy-dev] Re: [SciPy-user] Matrix square root
In-Reply-To: <416268DC.3060804@ee.byu.edu>
References: <416132AE.4080509@soton.ac.uk>
	<4161359E.8080403@mecha.uni-stuttgart.de>
	<Pine.LNX.4.61.0410040728460.21635@scipy.org>
	<416268DC.3060804@ee.byu.edu>
Message-ID: <41627BDA.90600@mecha.uni-stuttgart.de>

Travis Oliphant wrote:

> Pearu Peterson wrote:
>
>>
>>
>> On Mon, 4 Oct 2004, Nils Wagner wrote:
>>
>>> AFAIK there is no direct support for sqrtm but you may use funm.
>>
>>
>>
>> I just discovered that there might be a bug in funm. I have added
>> a test to scipy.linalg.test_matfuncs that demonstrates the bug.
>> So, be aware to check the results of funm(..,sqrt).
>
>
> As far as I undertand, the idea of a general purpose matrix function 
> has precision problems.   The algorithm in scipy is based on a 
> published algorithm using the Schur decomposition.   That is why it is 
> usually a good idea to write separate algorithms for special matrix 
> functions if possible.
>
> Is this really a bug, or just a problem with using the generic funm 
> algorithm when a more accurate algorithm exists.
>
> The fact that you can return a reasonable square root for non-special 
> matrices makes me believe that it is not a bug in funm, but a 
> demonstration that the generic funm algorithm does not always produce 
> the best results for specific functions of matrices. 
>
>
> -Travis O.
>
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev


Travis,

Please find attached a quick and dirty implementation of sqrtm using
Denman-Beavers and Schulz iteration as suggested by Higham.
This might be a starting point for sqrtm in scipy...
Any comments ?

Nils



 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: narep.py
Type: text/x-python
Size: 1100 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20041005/5d208142/attachment.py>

From Fernando.Perez at colorado.edu  Tue Oct  5 13:40:23 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 05 Oct 2004 11:40:23 -0600
Subject: [SciPy-dev] gui_thread and wxPython-2.5.2.8
In-Reply-To: <16738.3618.61873.892612@monster.linux.in>
References: <16733.28710.594895.848623@monster.linux.in>
	<415D81CB.1080800@colorado.edu>	<16733.34394.636979.103254@monster.linux.in>
	<415D8BCF.5020605@colorado.edu>	<16733.44761.20641.733372@monster.linux.in>
	<4161E6A8.4040101@colorado.edu>
	<16738.3618.61873.892612@monster.linux.in>
Message-ID: <4162DC87.9070409@colorado.edu>

Prabhu Ramachandran schrieb:
>>>>>>"FP" == Fernando Perez <Fernando.Perez at colorado.edu> writes:
> 
> 
>     FP> Prabhu Ramachandran schrieb:
>     >> Here is a simple test you can run:
>     >>
>     >> import gui_thread gui_thread.start() from gui_thread.examples
>     >> import SimpleFrame a = SimpleFrame() a.Show() a.SetTitle('Hey!
>     >> this works!')
> 
>     FP> Mmh :( With scipy CVS from a moment ago, this is what I'm
>     FP> getting:
> 
>     FP> /home/fperez/test/<string> in new_wxSize(*args, **kws)
> 
>     FP> AttributeError: AttrHolder instance has no attribute 'result'
> 
> That is wierd I agree but could be due to the first import, my
> suspicion is that I need to increase the timeout on the Event object
> from 0.5 to a full second or two.  In anycase just try it again (exit
> ipython and restart immediately) and it should work.

No, no luck.  I tried several quick restarts, with the same results.  And I 
get the same problem with the wx demo (after fixing the args):

In [1]: import gui_thread

In [2]: gui_thread.start()

In [3]: import Main

In [4]: d = Main.wxPythonDemo(None,-1, 'a')
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)

/usr/share/doc/wxPythonGTK2-2.4.2.4/demo/<console>

/usr/share/doc/wxPythonGTK2-2.4.2.4/demo/Main.py in __init__(self, parent, id, 
title)
     298     def __init__(self, parent, id, title):
     299         wx.Frame.__init__(self, parent, -1, title, size = (800, 600),
--> 300 
style=wx.DEFAULT_FRAME_STYLE|wx.NO_FULL_REPAINT_ON_RESIZE)
     301
     302         self.cwd = os.getcwd()

/usr/lib/python2.3/site-packages/wxPython/frames.py in __init__(self, *_args, 
**_kwargs)
     149 class wxFrame(wxFramePtr):
     150     def __init__(self,*_args,**_kwargs):
--> 151         self.this = framesc.new_wxFrame(*_args,**_kwargs)
     152         self.thisown = 1
     153         self._setOORInfo(self)

/usr/share/doc/wxPythonGTK2-2.4.2.4/demo/<string> in new_wxFrame(*args, **kws)

AttributeError: AttrHolder instance has no attribute 'result'


Furthermore, with the SimpleFrame example, now things hang when I try to quit 
ipython.  And once I hit Ctrl-C, I get the following (truncated) message:

Exception exceptions.AttributeError: <exceptions.AttributeError instance at 
0x2a88504c> in

I don't know why the message gets truncated, I tried maximizing the terminal 
and it still is incomplete.

Something isn't quite right here...

Best,

f



From prabhu at aero.iitm.ernet.in  Tue Oct  5 13:57:38 2004
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Tue, 5 Oct 2004 23:27:38 +0530
Subject: [SciPy-dev] gui_thread and wxPython-2.5.2.8
In-Reply-To: <4162DC87.9070409@colorado.edu>
References: <16733.28710.594895.848623@monster.linux.in>
	<415D81CB.1080800@colorado.edu>
	<16733.34394.636979.103254@monster.linux.in>
	<415D8BCF.5020605@colorado.edu>
	<16733.44761.20641.733372@monster.linux.in>
	<4161E6A8.4040101@colorado.edu>
	<16738.3618.61873.892612@monster.linux.in>
	<4162DC87.9070409@colorado.edu>
Message-ID: <16738.57490.800815.195052@monster.linux.in>

>>>>> "FP" == Fernando Perez <Fernando.Perez at colorado.edu> writes:

    >> That is wierd I agree but could be due to the first import, my
    >> suspicion is that I need to increase the timeout on the Event
    >> object from 0.5 to a full second or two.  In anycase just try
    >> it again (exit ipython and restart immediately) and it should
    >> work.

    FP> No, no luck.  I tried several quick restarts, with the same
    FP> results.  And I get the same problem with the wx demo (after
    FP> fixing the args):

[...]

    FP> Something isn't quite right here...

It could be the LANG=C thing that Michael Reimpell reported.  Try
this:

LANG=C ipython
[gui_thread tests]

and see what you get.  If that does not fix it, you could try to edit
wxBackgroundApp.py and change the finished.wait(0.5) to
something larger like finished.wait(2.0) and retry.  

Either way do let me know what works.  On my machine I'm able to run
wxPython apps from inside IDLE using gui_thread (not that I use IDLE
at all, but just to show that its now possible to do it). :)

cheers,
prabhu



From Fernando.Perez at colorado.edu  Tue Oct  5 13:59:49 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 05 Oct 2004 11:59:49 -0600
Subject: [SciPy-dev] gui_thread and wxPython-2.5.2.8
In-Reply-To: <16738.57490.800815.195052@monster.linux.in>
References: <16733.28710.594895.848623@monster.linux.in>
	<415D81CB.1080800@colorado.edu>	<16733.34394.636979.103254@monster.linux.in>
	<415D8BCF.5020605@colorado.edu>	<16733.44761.20641.733372@monster.linux.in>
	<4161E6A8.4040101@colorado.edu>	<16738.3618.61873.892612@monster.linux.in>
	<4162DC87.9070409@colorado.edu>
	<16738.57490.800815.195052@monster.linux.in>
Message-ID: <4162E115.50009@colorado.edu>

Prabhu Ramachandran schrieb:
>>>>>>"FP" == Fernando Perez <Fernando.Perez at colorado.edu> writes:
> 
> 
>     >> That is wierd I agree but could be due to the first import, my
>     >> suspicion is that I need to increase the timeout on the Event
>     >> object from 0.5 to a full second or two.  In anycase just try
>     >> it again (exit ipython and restart immediately) and it should
>     >> work.
> 
>     FP> No, no luck.  I tried several quick restarts, with the same
>     FP> results.  And I get the same problem with the wx demo (after
>     FP> fixing the args):
> 
> [...]
> 
>     FP> Something isn't quite right here...
> 
> It could be the LANG=C thing that Michael Reimpell reported.  Try
> this:

Yup, see my reply just sent into the other thread...

f



From nwagner at mecha.uni-stuttgart.de  Wed Oct  6 03:22:56 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Wed, 06 Oct 2004 09:22:56 +0200
Subject: [SciPy-dev] Matrix Structure Plots in scipy ?
Message-ID: <41639D50.6070209@mecha.uni-stuttgart.de>

Hi all,

First of all I would like to thank Pearu for implementing
Matrix Market I/O support !

The number of outputs is more than described in help (io.mmio)


    mmread(source)
        Reads the contents of the Matrix Market file 'filename' into the 
matrix 'A'.

        Inputs:

          source    - Matrix Market filename (extension .mtx) or open 
file object.

        Outputs:

          a         - sparse or full matrix

Actually

b,m,n,s = mmread('young1c')

should be used.

Is it possible to generate matrix structure plots in scipy ?
http://math.nist.gov/MatrixMarket/structureplots.html

BTW, there is another "important" matrix format namely matrices 
generated by NASTRAN (commercial Finite Element program).There exists 
already a tool that can read and write both dense and sparse matrices, 
either real or complex, either little or big endian, and either text 
(any precision) or binary. You can find the code by downloading

http://savannah.nongnu.org/cgi-bin/viewcvs/tops/tops/usr/extra/op4tools/

Pearu, please can you manage the support of this format in scipy too ?
I believe devoutly, that many users will appreciate this feature.

Thanks in advance

                                     Nils




From pearu at scipy.org  Wed Oct  6 08:19:52 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Wed, 6 Oct 2004 07:19:52 -0500 (CDT)
Subject: [SciPy-dev] Matrix Structure Plots in scipy ?
In-Reply-To: <41639D50.6070209@mecha.uni-stuttgart.de>
References: <41639D50.6070209@mecha.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.61.0410060716560.21635@scipy.org>



On Wed, 6 Oct 2004, Nils Wagner wrote:

> The number of outputs is more than described in help (io.mmio)
>
>
>   mmread(source)
>       Reads the contents of the Matrix Market file 'filename' into the 
> matrix 'A'.
>
>       Inputs:
>
>         source    - Matrix Market filename (extension .mtx) or open file 
> object.
>
>       Outputs:
>
>         a         - sparse or full matrix
>
> Actually
>
> b,m,n,s = mmread('young1c')
>
> should be used.

Since the values for m,n,s are available via mminfo then I have changed 
the signature of mmread to

   a = mmread(source)

Btw, one can now also write sparse matrices using mmwrite.

Pearu



From nwagner at mecha.uni-stuttgart.de  Wed Oct  6 08:06:00 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Wed, 06 Oct 2004 14:06:00 +0200
Subject: [SciPy-dev] Matrix Structure Plots in scipy ?
In-Reply-To: <Pine.LNX.4.61.0410060716560.21635@scipy.org>
References: <41639D50.6070209@mecha.uni-stuttgart.de>
	<Pine.LNX.4.61.0410060716560.21635@scipy.org>
Message-ID: <4163DFA8.9040108@mecha.uni-stuttgart.de>

Pearu Peterson wrote:

>
>
> On Wed, 6 Oct 2004, Nils Wagner wrote:
>
>> The number of outputs is more than described in help (io.mmio)
>>
>>
>>   mmread(source)
>>       Reads the contents of the Matrix Market file 'filename' into 
>> the matrix 'A'.
>>
>>       Inputs:
>>
>>         source    - Matrix Market filename (extension .mtx) or open 
>> file object.
>>
>>       Outputs:
>>
>>         a         - sparse or full matrix
>>
>> Actually
>>
>> b,m,n,s = mmread('young1c')
>>
>> should be used.
>
>
> Since the values for m,n,s are available via mminfo then I have 
> changed the signature of mmread to
>
>   a = mmread(source)
>
> Btw, one can now also write sparse matrices using mmwrite.

Is it also possible, that mmread returns sparse matrices when reading
sparse matrices from *.mtx ?

Is it generally possible to switch between sparse and dense format of 
matrices
in scipy ?

Now, scipy has some iterative solvers for linear systems. Can I use both
dense and sparse matrices with respect to cg,... ?

How about sparse eigensolvers in scipy e.g. ARPACK ?

Nils


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



 



From pearu at scipy.org  Wed Oct  6 08:50:13 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Wed, 6 Oct 2004 07:50:13 -0500 (CDT)
Subject: [SciPy-dev] Matrix Structure Plots in scipy ?
In-Reply-To: <4163DFA8.9040108@mecha.uni-stuttgart.de>
References: <41639D50.6070209@mecha.uni-stuttgart.de>
	<4163DFA8.9040108@mecha.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.61.0410060745230.21635@scipy.org>



On Wed, 6 Oct 2004, Nils Wagner wrote:

> Is it also possible, that mmread returns sparse matrices when reading
> sparse matrices from *.mtx ?

Now yes, mmread will return coo_matrix instance when reading coordinate
.mtx files.

> Is it generally possible to switch between sparse and dense format of 
> matrices in scipy ?

Yes.
>From sparse to dense: <spmatrix instance>.todense()
>From dense to sparse: <spmatrix class>(<array>)

For more info, see scipy.sparse.Sparse.

> Now, scipy has some iterative solvers for linear systems. Can I use both
> dense and sparse matrices with respect to cg,... ?
>
> How about sparse eigensolvers in scipy e.g. ARPACK ?

Cannot answer these questions right now...

Pearu



From nwagner at mecha.uni-stuttgart.de  Wed Oct  6 08:51:15 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Wed, 06 Oct 2004 14:51:15 +0200
Subject: [SciPy-dev] Matrix Structure Plots in scipy ?
In-Reply-To: <Pine.LNX.4.61.0410060745230.21635@scipy.org>
References: <41639D50.6070209@mecha.uni-stuttgart.de>
	<4163DFA8.9040108@mecha.uni-stuttgart.de>
	<Pine.LNX.4.61.0410060745230.21635@scipy.org>
Message-ID: <4163EA43.4010803@mecha.uni-stuttgart.de>

Pearu Peterson wrote:

>
>
> On Wed, 6 Oct 2004, Nils Wagner wrote:
>
>> Is it also possible, that mmread returns sparse matrices when reading
>> sparse matrices from *.mtx ?
>
>
> Now yes, mmread will return coo_matrix instance when reading coordinate
> .mtx files.
>
>> Is it generally possible to switch between sparse and dense format of 
>> matrices in scipy ?
>
>
> Yes.
>
>> From sparse to dense: <spmatrix instance>.todense()
>> From dense to sparse: <spmatrix class>(<array>)
>
>
> For more info, see scipy.sparse.Sparse.
>
>> Now, scipy has some iterative solvers for linear systems. Can I use both
>> dense and sparse matrices with respect to cg,... ?
>>
>> How about sparse eigensolvers in scipy e.g. ARPACK ?
>
>
> Cannot answer these questions right now...
>
There seems to be an interface to ARPACK, but  I don't know anything
about its possibilities...

http://jrfonseca.dyndns.org/work/phd/

Any comments ?

Nils

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



 




From pearu at scipy.org  Wed Oct  6 15:04:50 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Wed, 6 Oct 2004 14:04:50 -0500 (CDT)
Subject: [SciPy-dev] Plan for releasing Scipy 0.3.2
Message-ID: <Pine.LNX.4.61.0410061342160.21635@scipy.org>


Hi,

I think we are ready to make the release: with the recent Scipy from CVS 
all tests pass ok on Debian (sid) P4 and AMD MP boxes, Gentoo Opteron box, 
and a WinNT box.

If you think that there are some important bugs to be fixed, you still got
about 12 hours. I plan to tag Scipy CVS tree tomorrow morning (Estonian 
time), create tar-balls, etc. See

   http://www.scipy.org/development/releasescipy.txt

for relevant tasks.

Please, let me know if there is any reason that I should hold on for 
tagging CVS tree.

I can also make binaries for Linux system but it would be create if 
someone could create RPMs (Joe?) and Win32 installers (Travis?) after 
tar-balls are available.

Thanks,
Pearu



From nwagner at mecha.uni-stuttgart.de  Wed Oct  6 14:59:02 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Wed, 06 Oct 2004 20:59:02 +0200
Subject: [SciPy-dev] Plan for releasing Scipy 0.3.2
In-Reply-To: <Pine.LNX.4.61.0410061342160.21635@scipy.org>
Message-ID: <web-10110640@uni-stuttgart.de>

On Wed, 6 Oct 2004 14:04:50 -0500 (CDT)
  Pearu Peterson <pearu at scipy.org> wrote:
>
>Hi,
>
>I think we are ready to make the release: with the recent 
>Scipy from CVS all tests pass ok on Debian (sid) P4 and 
>AMD MP boxes, Gentoo Opteron box, and a WinNT box.
>
>If you think that there are some important bugs to be 
>fixed, you still got
>about 12 hours. 
Pearu,

I still have problems with 

from scipy.xplt import *
see my previous e-mail.

It works quite well a few weeks ago.
Following Travis, I have upgraded Numeric to 23.5
but nothing happened.

I am also using the latest scipy from cvs.

Any pointer would be appreciated.

Thanks
           Nils
  
I plan to tag Scipy CVS tree tomorrow 
>morning (Estonian time), create tar-balls, etc. See
>
>   http://www.scipy.org/development/releasescipy.txt
>
>for relevant tasks.
>
>Please, let me know if there is any reason that I should 
>hold on for tagging CVS tree.
>
>I can also make binaries for Linux system but it would be 
>create if someone could create RPMs (Joe?) and Win32 
>installers (Travis?) after tar-balls are available.
>
>Thanks,
>Pearu
>
>_______________________________________________
>Scipy-dev mailing list
>Scipy-dev at scipy.net
>http://www.scipy.net/mailman/listinfo/scipy-dev

  



From oliphant at ee.byu.edu  Wed Oct  6 17:05:37 2004
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Wed, 06 Oct 2004 15:05:37 -0600
Subject: [SciPy-dev] Plan for releasing Scipy 0.3.2
In-Reply-To: <Pine.LNX.4.61.0410061342160.21635@scipy.org>
References: <Pine.LNX.4.61.0410061342160.21635@scipy.org>
Message-ID: <41645E21.3070105@ee.byu.edu>

Pearu Peterson wrote:

>
> Hi,
>
> I think we are ready to make the release: with the recent Scipy from 
> CVS all tests pass ok on Debian (sid) P4 and AMD MP boxes, Gentoo 
> Opteron box, and a WinNT box.
>
> If you think that there are some important bugs to be fixed, you still 
> got
> about 12 hours. I plan to tag Scipy CVS tree tomorrow morning 
> (Estonian time), create tar-balls, etc. See
>
>   http://www.scipy.org/development/releasescipy.txt
>
> for relevant tasks.
>
> Please, let me know if there is any reason that I should hold on for 
> tagging CVS tree.
>
> I can also make binaries for Linux system but it would be create if 
> someone could create RPMs (Joe?) and Win32 installers (Travis?) after 
> tar-balls are available.


I can make Win32 installers appropriate for my system (i.e. the ATLAS I 
use) --- later in coming would be generic-type Win32 installers.

I can make RPMS appropriate for Mandrake 10.0 as well.

-Travis



From oliphant at ee.byu.edu  Wed Oct  6 17:08:22 2004
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Wed, 06 Oct 2004 15:08:22 -0600
Subject: [SciPy-dev] Re: Plan for releasing Scipy 0.3.2
In-Reply-To: <m2zn2zvaoc.fsf@pchoel.psh>
References: <Pine.LNX.4.61.0410061342160.21635@scipy.org>
	<m2zn2zvaoc.fsf@pchoel.psh>
Message-ID: <41645EC6.1040308@ee.byu.edu>

Berthold H?llmann wrote:

>Pearu Peterson <pearu at scipy.org> writes:
>
>  
>
>>Hi,
>>
>>I think we are ready to make the release: with the recent Scipy from
>>CVS all tests pass ok on Debian (sid) P4 and AMD MP boxes, Gentoo
>>Opteron box, and a WinNT box.
>>
>>If you think that there are some important bugs to be fixed, you still got
>>about 12 hours. I plan to tag Scipy CVS tree tomorrow morning
>>(Estonian time), create tar-balls, etc. See
>>
>>   http://www.scipy.org/development/releasescipy.txt
>>
>>for relevant tasks.
>>
>>Please, let me know if there is any reason that I should hold on for
>>tagging CVS tree.
>>
>>I can also make binaries for Linux system but it would be create if
>>someone could create RPMs (Joe?) and Win32 installers (Travis?) after
>>tar-balls are available.
>>    
>>
>
>Testing the actual CVS on a SuSE 9.0 with gcc 3.4.2 I get
>
>  
>
>>python -c "import scipy ; scipy.test()"/usr/local/lib/python2.4/whrandom.py:38: DeprecationWarning: the whrandom module is deprecated; please use the random module
>>    
>>
>  DeprecationWarning)
>   !! No test file 'test_Mplot.py' found for <module 'scipy.xplt.Mplot' from '...-packages/scipy/xplt/Mplot.pyc'>
>(lots of "!! No test..." and test output)
>.Testing weibull_min
>.........
>======================================================================
>FAIL: check_basic (scipy.stats.morestats.test_morestats.test_shapiro)
>----------------------------------------------------------------------
>Traceback (most recent call last):
>  File "/usr/local/lib/python2.4/site-packages/scipy/stats/tests/test_morestats.py", 
>line 40, in check_basic
>    assert_almost_equal(pw,0.52459925413131714,3)
>  File "/usr/local/lib/python2.4/site-packages/scipy_test/testing.py", line 606, in a
>ssert_almost_equal
>    assert round(abs(desired - actual),decimal) == 0, msg
>AssertionError: 
>Items are not equal:
>DESIRED: 0.52459925413131714
>ACTUAL: 1.0
>
>----------------------------------------------------------------------
>Ran 972 tests in 9.784s
>  
>

Do you get this error consistently or just once in a while?

-Travis



From Fernando.Perez at colorado.edu  Wed Oct  6 17:20:19 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 06 Oct 2004 15:20:19 -0600
Subject: [SciPy-dev] Plan for releasing Scipy 0.3.2
In-Reply-To: <41645E21.3070105@ee.byu.edu>
References: <Pine.LNX.4.61.0410061342160.21635@scipy.org>
	<41645E21.3070105@ee.byu.edu>
Message-ID: <41646193.6090006@colorado.edu>

Travis Oliphant schrieb:
> Pearu Peterson wrote:
> 
> 
>>Hi,
>>
>>I think we are ready to make the release: with the recent Scipy from 
>>CVS all tests pass ok on Debian (sid) P4 and AMD MP boxes, Gentoo 
>>Opteron box, and a WinNT box.
>>
>>If you think that there are some important bugs to be fixed, you still 
>>got
>>about 12 hours. I plan to tag Scipy CVS tree tomorrow morning 
>>(Estonian time), create tar-balls, etc. See
>>
>>  http://www.scipy.org/development/releasescipy.txt
>>
>>for relevant tasks.
>>
>>Please, let me know if there is any reason that I should hold on for 
>>tagging CVS tree.

I worry that gui_thread is really not ready for public consumption:

planck[pylab]> cd  /usr/share/doc/wxPythonGTK2-2.4.2.4/demo/
planck[demo]> ip
Python 2.3.3 (#1, May  7 2004, 10:31:40)
Type "copyright", "credits" or "license" for more information.

IPython 0.6.4.rc1 -- An enhanced Interactive Python.
?       -> Introduction to IPython's features.
%magic  -> Information about IPython's 'magic' % functions.
help    -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.

In [1]: import gui_thread

In [2]: gui_thread.start()

In [3]: import Main

In [4]: d = Main.wxPythonDemo(None,-1, 'a')
Segmentation fault

Prabhu is getting very good results with wxpython 2.5, but it seems that for 
2.4 there are serious problems still.  I've been running several small tests 
which he has suggested, but with no positive results yet.

Considering that this is on an up-to-date Fedora 2 install, perhaps gui_thread 
  should be disabled for WxPython 2.4.  Printing a warning and telling users 
that gui_thread only supports 2.5 would be better than segfaulting :)

Best,

f



From bhoel at web.de  Wed Oct  6 17:34:36 2004
From: bhoel at web.de (=?iso-8859-15?q?Berthold_H=F6llmann?=)
Date: Wed, 06 Oct 2004 23:34:36 +0200
Subject: [SciPy-dev] Re: Plan for releasing Scipy 0.3.2
In-Reply-To: <41645EC6.1040308@ee.byu.edu> (Travis Oliphant's message of
	"Wed, 06 Oct 2004 15:08:22 -0600")
References: <Pine.LNX.4.61.0410061342160.21635@scipy.org>
	<m2zn2zvaoc.fsf@pchoel.psh> <41645EC6.1040308@ee.byu.edu>
Message-ID: <m2vfdnv8cz.fsf@pchoel.psh>

Travis Oliphant <oliphant at ee.byu.edu> writes:

> Berthold H?llmann wrote:
>
>>Pearu Peterson <pearu at scipy.org> writes:
>>
>>
>>
>>
>>Testing the actual CVS on a SuSE 9.0 with gcc 3.4.2 I get
>>
>>
>>
>>>python -c "import scipy ; scipy.test()"/usr/local/lib/python2.4/whrandom.py:38: DeprecationWarning: the whrandom module is deprecated; please use the random module
>>>
>>>
>>  DeprecationWarning)
>>   !! No test file 'test_Mplot.py' found for <module 'scipy.xplt.Mplot' from '...-packages/scipy/xplt/Mplot.pyc'>
>>(lots of "!! No test..." and test output)
>>.Testing weibull_min
>>.........
>>======================================================================
>>FAIL: check_basic (scipy.stats.morestats.test_morestats.test_shapiro)
>>----------------------------------------------------------------------
>>Traceback (most recent call last):
>>  File
>> "/usr/local/lib/python2.4/site-packages/scipy/stats/tests/test_morestats.py",
>> line 40, in check_basic
>>    assert_almost_equal(pw,0.52459925413131714,3)
>>  File "/usr/local/lib/python2.4/site-packages/scipy_test/testing.py", line 606, in a
>>ssert_almost_equal
>>    assert round(abs(desired - actual),decimal) == 0, msg
>> AssertionError: Items are not equal:
>>DESIRED: 0.52459925413131714
>>ACTUAL: 1.0
>>
>>----------------------------------------------------------------------
>>Ran 972 tests in 9.784s
>>
>>
>
> Do you get this error consistently or just once in a while?

I get it twice for two tries. Is this consistently enough? Also the

/usr/local/lib/python2.4/whrandom.py:38: DeprecationWarning: the whrandom module is deprecated; please use the random module

comes everytime I run the tests;-)

Regards
Berthold
-- 
bhoel at web.de / http://starship.python.net/crew/bhoel/



From oliphant at ee.byu.edu  Wed Oct  6 17:56:42 2004
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Wed, 06 Oct 2004 15:56:42 -0600
Subject: [SciPy-dev] Re: Plan for releasing Scipy 0.3.2
In-Reply-To: <m2vfdnv8cz.fsf@pchoel.psh>
References: <Pine.LNX.4.61.0410061342160.21635@scipy.org>
	<m2zn2zvaoc.fsf@pchoel.psh> <41645EC6.1040308@ee.byu.edu>
	<m2vfdnv8cz.fsf@pchoel.psh>
Message-ID: <41646A1A.7090201@ee.byu.edu>


>>> DeprecationWarning)
>>>  !! No test file 'test_Mplot.py' found for <module 'scipy.xplt.Mplot' from '...-packages/scipy/xplt/Mplot.pyc'>
>>>(lots of "!! No test..." and test output)
>>>.Testing weibull_min
>>>.........
>>>======================================================================
>>>FAIL: check_basic (scipy.stats.morestats.test_morestats.test_shapiro)
>>>----------------------------------------------------------------------
>>>Traceback (most recent call last):
>>> File
>>>"/usr/local/lib/python2.4/site-packages/scipy/stats/tests/test_morestats.py",
>>>line 40, in check_basic
>>>   assert_almost_equal(pw,0.52459925413131714,3)
>>> File "/usr/local/lib/python2.4/site-packages/scipy_test/testing.py", line 606, in a
>>>ssert_almost_equal
>>>   assert round(abs(desired - actual),decimal) == 0, msg
>>>AssertionError: Items are not equal:
>>>DESIRED: 0.52459925413131714
>>>ACTUAL: 1.0
>>>
>>>----------------------------------------------------------------------
>>>Ran 972 tests in 9.784s
>>>
>>>
>>>      
>>>
>>Do you get this error consistently or just once in a while?
>>    
>>
>
>I get it twice for two tries. Is this consistently enough? Also the
>
>/usr/local/lib/python2.4/whrandom.py:38: DeprecationWarning: the whrandom module is deprecated; please use the random module
>
>
>  
>
Thanks for the information.  This looks like a genuine bug.  You should 
not be getting this much of a difference.  Is the problem related to gcc 
3.4.2?  Is anybody using that particular compiler?   The problem is the 
statlib.swilk  function.  Apparently, It is not returning the correct 
value on your system.   This function is in Fortran and so either gcc 
3.4.2 is compiling it differently or the f2py-generated interface is not 
functioning correctly.

Could you manually run the test that is failing and give the output of 
stats.shapiro(x2) using the x2 in the test_morestats.py file near line 40?

Thanks,

-Travis O.






From pearu at scipy.org  Wed Oct  6 18:19:26 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Wed, 6 Oct 2004 17:19:26 -0500 (CDT)
Subject: [SciPy-dev] Plan for releasing Scipy 0.3.2
In-Reply-To: <41646193.6090006@colorado.edu>
References: <Pine.LNX.4.61.0410061342160.21635@scipy.org>
	<41645E21.3070105@ee.byu.edu> <41646193.6090006@colorado.edu>
Message-ID: <Pine.LNX.4.61.0410061713260.21635@scipy.org>



On Wed, 6 Oct 2004, Fernando Perez wrote:

> I worry that gui_thread is really not ready for public consumption:
>
> planck[pylab]> cd  /usr/share/doc/wxPythonGTK2-2.4.2.4/demo/
> planck[demo]> ip
> Python 2.3.3 (#1, May  7 2004, 10:31:40)
> Type "copyright", "credits" or "license" for more information.
>
> IPython 0.6.4.rc1 -- An enhanced Interactive Python.
> ?       -> Introduction to IPython's features.
> %magic  -> Information about IPython's 'magic' % functions.
> help    -> Python's own help system.
> object? -> Details about 'object'. ?object also works, ?? prints more.
>
> In [1]: import gui_thread
>
> In [2]: gui_thread.start()
>
> In [3]: import Main
>
> In [4]: d = Main.wxPythonDemo(None,-1, 'a')
> Segmentation fault
>
> Prabhu is getting very good results with wxpython 2.5, but it seems that for 
> 2.4 there are serious problems still.  I've been running several small tests 
> which he has suggested, but with no positive results yet.
>
> Considering that this is on an up-to-date Fedora 2 install, perhaps 
> gui_thread  should be disabled for WxPython 2.4.  Printing a warning and 
> telling users that gui_thread only supports 2.5 would be better than 
> segfaulting :)

I have no problems with using gui_thread on a Debian system with 
wxPythonSrc-2.4.2.4. So, I wouldn't disable gui_thread for myself;)
My environment: Python 2.3.4, LANG is unset, Numeric 23.5.

Could you try to use libwadpy or some other tool to find out which part of 
wxPython is segfaulting?

Pearu



From Fernando.Perez at colorado.edu  Wed Oct  6 18:07:19 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 06 Oct 2004 16:07:19 -0600
Subject: [SciPy-dev] Plan for releasing Scipy 0.3.2
In-Reply-To: <Pine.LNX.4.61.0410061713260.21635@scipy.org>
References: <Pine.LNX.4.61.0410061342160.21635@scipy.org>
	<41645E21.3070105@ee.byu.edu> <41646193.6090006@colorado.edu>
	<Pine.LNX.4.61.0410061713260.21635@scipy.org>
Message-ID: <41646C97.4080006@colorado.edu>

Pearu Peterson schrieb:
> I have no problems with using gui_thread on a Debian system with 
> wxPythonSrc-2.4.2.4. So, I wouldn't disable gui_thread for myself;)
> My environment: Python 2.3.4, LANG is unset, Numeric 23.5.

Ok, here's a bit more useful info: if I set LANG to C, it all looks pretty 
good.  If I leave one of the fedora defaults, even an english one:

planck[demo]> echo $LANG
en_US.UTF-8

I get guaranteed segfaults.  I'm going to guess it's a bug related to UTF-8 
handling deep in the bowels of wx and/or GTK.

> Could you try to use libwadpy or some other tool to find out which part of 
> wxPython is segfaulting?

Unfortunately I can't really commit to deeply debugging this problem at the 
library level (WX) right now.  That kind of bug hunting in C libs is very time 
consuming, and at the moment I can only spend short bursts of time on this 
performing small tests.  Hopefully the LANG info  proves useful, since that's 
the most I'm likely to be able to provide.  Can you see if you get similar 
problems with UTF-8 settings?

Perhaps doing a hard LANG=C inside gui_thread is a viable option also.  Not 
ideal, but better than a segfault :)

Cheers,

f



From pearu at scipy.org  Wed Oct  6 18:37:53 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Wed, 6 Oct 2004 17:37:53 -0500 (CDT)
Subject: [SciPy-dev] Plan for releasing Scipy 0.3.2
In-Reply-To: <41646C97.4080006@colorado.edu>
References: <Pine.LNX.4.61.0410061342160.21635@scipy.org>
	<41645E21.3070105@ee.byu.edu>
	<Pine.LNX.4.61.0410061713260.21635@scipy.org>
	<41646C97.4080006@colorado.edu>
Message-ID: <Pine.LNX.4.61.0410061732550.21635@scipy.org>



On Wed, 6 Oct 2004, Fernando Perez wrote:

> Pearu Peterson schrieb:
>> I have no problems with using gui_thread on a Debian system with 
>> wxPythonSrc-2.4.2.4. So, I wouldn't disable gui_thread for myself;)
>> My environment: Python 2.3.4, LANG is unset, Numeric 23.5.
>
> Ok, here's a bit more useful info: if I set LANG to C, it all looks pretty 
> good.  If I leave one of the fedora defaults, even an english one:
>
> planck[demo]> echo $LANG
> en_US.UTF-8
>
> I get guaranteed segfaults.  I'm going to guess it's a bug related to UTF-8 
> handling deep in the bowels of wx and/or GTK.

>> Could you try to use libwadpy or some other tool to find out which part of 
>> wxPython is segfaulting?
>
> Unfortunately I can't really commit to deeply debugging this problem at the 
> library level (WX) right now.  That kind of bug hunting in C libs is very 
> time consuming, and at the moment I can only spend short bursts of time on 
> this performing small tests.  Hopefully the LANG info  proves useful, since 
> that's the most I'm likely to be able to provide.  Can you see if you get 
> similar problems with UTF-8 settings?

No. Using `LANG=en_US.UTF-8 python` does not cause any problems here on 
Debian box: I can even run multiple wxPython demo instances.

> Perhaps doing a hard LANG=C inside gui_thread is a viable option also.  Not 
> ideal, but better than a segfault :)

I agree. But have you tested that adding 'os.environ["LANG"]="C"' to 
gui_thread will fix the problem? If so, then we should use it in 0.3.2.

Pearu



From pearu at scipy.org  Wed Oct  6 18:40:41 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Wed, 6 Oct 2004 17:40:41 -0500 (CDT)
Subject: [SciPy-dev] Re: Plan for releasing Scipy 0.3.2
In-Reply-To: <m2vfdnv8cz.fsf@pchoel.psh>
References: <Pine.LNX.4.61.0410061342160.21635@scipy.org>
	<m2zn2zvaoc.fsf@pchoel.psh>
	<41645EC6.1040308@ee.byu.edu> <m2vfdnv8cz.fsf@pchoel.psh>
Message-ID: <Pine.LNX.4.61.0410061726210.21635@scipy.org>



On Wed, 6 Oct 2004, [iso-8859-15] Berthold H?llmann wrote:

> Also the
>
> /usr/local/lib/python2.4/whrandom.py:38: DeprecationWarning: the whrandom module is deprecated; please use the random module
>
> comes everytime I run the tests;-)

Well, you are using Python 2.4 that warns depreciated modules since 2.1.
Since we support Python 2.1 and up in scipy, we should be able to fix this 
warning..

Pearu

From Fernando.Perez at colorado.edu  Wed Oct  6 18:19:48 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 06 Oct 2004 16:19:48 -0600
Subject: [SciPy-dev] Plan for releasing Scipy 0.3.2
In-Reply-To: <Pine.LNX.4.61.0410061342160.21635@scipy.org>
References: <Pine.LNX.4.61.0410061342160.21635@scipy.org>
Message-ID: <41646F84.2060006@colorado.edu>

Pearu Peterson schrieb:
> Hi,
> 
> I think we are ready to make the release: with the recent Scipy from CVS 
> all tests pass ok on Debian (sid) P4 and AMD MP boxes, Gentoo Opteron box, 
> and a WinNT box.
> 
> If you think that there are some important bugs to be fixed, you still got
> about 12 hours. I plan to tag Scipy CVS tree tomorrow morning (Estonian 
> time), create tar-balls, etc. See
> 
>    http://www.scipy.org/development/releasescipy.txt
> 
> for relevant tasks.
> 
> Please, let me know if there is any reason that I should hold on for 
> tagging CVS tree.

Just for the record, on my Fedora core 2 box, with CVS scipy from a moment ago:

planck[~/misc]> python
Python 2.3.3 (#1, May  7 2004, 10:31:40)
[GCC 3.3.3 20040412 (Red Hat Linux 3.3.3-7)] on linux2

...

In [1]: import scipy

In [2]: scipy.__version__
Out[2]: '0.3.1_287.4334'

In [3]: scipy.test(level=10)
    !! No test file 'test_Mplot.py' found for <module 'scipy.xplt.Mplot' from 
'...-packages/scipy/xplt/Mplot.pyc'>
    !! No test file 'test_lena.py' found for <module 'scipy.plt.lena' from 
'...te-packages/scipy/plt/lena.pyc'>



... A bunch more of these, I don't know if they matter.  I can post the full 
list if it matters.

Then, after a while:

.Testing weibull_max
.Testing weibull_min
.....
----------------------------------------------------------------------
Ran 986 tests in 115.357s

OK


So here, things are looking pretty good (except for the gui_thread thingie 
elsewhere in this thread).

Best,

f



From pearu at scipy.org  Wed Oct  6 18:46:04 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Wed, 6 Oct 2004 17:46:04 -0500 (CDT)
Subject: [SciPy-dev] Plan for releasing Scipy 0.3.2
In-Reply-To: <41646F84.2060006@colorado.edu>
References: <Pine.LNX.4.61.0410061342160.21635@scipy.org>
	<41646F84.2060006@colorado.edu>
Message-ID: <Pine.LNX.4.61.0410061742290.21635@scipy.org>



On Wed, 6 Oct 2004, Fernando Perez wrote:

> Just for the record, on my Fedora core 2 box, with CVS scipy from a moment 
> ago:
>
> planck[~/misc]> python
> Python 2.3.3 (#1, May  7 2004, 10:31:40)
> [GCC 3.3.3 20040412 (Red Hat Linux 3.3.3-7)] on linux2
>
> ...
>
> In [1]: import scipy
>
> In [2]: scipy.__version__
> Out[2]: '0.3.1_287.4334'
>
> In [3]: scipy.test(level=10)
>   !! No test file 'test_Mplot.py' found for <module 'scipy.xplt.Mplot' from 
> '...-packages/scipy/xplt/Mplot.pyc'>
>   !! No test file 'test_lena.py' found for <module 'scipy.plt.lena' from 
> '...te-packages/scipy/plt/lena.pyc'>
>
> ... A bunch more of these, I don't know if they matter.  I can post the full 
> list if it matters.

These messages are reminders to implement more tests to scipy. Once we 
will have a good coverage of scipy with tests in some nice day, we can 
disable these annoying messages;)

Pearu



From Fernando.Perez at colorado.edu  Wed Oct  6 18:28:14 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 06 Oct 2004 16:28:14 -0600
Subject: [SciPy-dev] Plan for releasing Scipy 0.3.2
In-Reply-To: <Pine.LNX.4.61.0410061732550.21635@scipy.org>
References: <Pine.LNX.4.61.0410061342160.21635@scipy.org>
	<41645E21.3070105@ee.byu.edu>	<Pine.LNX.4.61.0410061713260.21635@scipy.org>
	<41646C97.4080006@colorado.edu>
	<Pine.LNX.4.61.0410061732550.21635@scipy.org>
Message-ID: <4164717E.2010401@colorado.edu>

Pearu Peterson schrieb:
>>Perhaps doing a hard LANG=C inside gui_thread is a viable option also.  Not 
>>ideal, but better than a segfault :)
> 
> 
> I agree. But have you tested that adding 'os.environ["LANG"]="C"' to 
> gui_thread will fix the problem? If so, then we should use it in 0.3.2.

Well, it's worse.  Even though I got the previous time things to work with 
LANG=C, it's actually kind of random.  Sometimes it works, sometimes it 
segfaults.  And setting it from python (os.environ) or from the shell doesn't 
really seem to matter (at least not in a useful way).

Sorry if I can't be of more help on this.  Tracking down a problem like this 
one can be hell.  I guess I just worry in case it's not just something with my 
box, as Fedora2 is a fairly popular platform.  But it would be useful to have 
feedback from other Fedora2 users: if it's just a misconfig on my system, then 
we don't have to worry about it.  But if it's a problem likely to bite all 
Fedora2 users, then I'd say it's a bigger worry.

Cheers,

f



From prabhu at aero.iitm.ernet.in  Wed Oct  6 21:03:07 2004
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Thu, 7 Oct 2004 06:33:07 +0530
Subject: [SciPy-dev] Plan for releasing Scipy 0.3.2
In-Reply-To: <41646F84.2060006@colorado.edu>
References: <Pine.LNX.4.61.0410061342160.21635@scipy.org>
	<41646F84.2060006@colorado.edu>
Message-ID: <16740.38347.860162.317064@monster.linux.in>

>>>>> "FP" == Fernando Perez <Fernando.Perez at colorado.edu> writes:

    FP> Pearu Peterson schrieb:

    FP> Just for the record, on my Fedora core 2 box, with CVS scipy
    FP> from a moment ago:

[...]
    FP> So here, things are looking pretty good (except for the
    FP> gui_thread thingie elsewhere in this thread).

Well, I can't devote any more time to this either.  Perhaps the only
thing to do would be to run python under gdb and see where it dies.

gdb python
(gdb) r
>>> import gui_thread
...
SEGFAULT
(gdb) bt

Even if you did that there is no guarantee that we'll be able to fix
it.  I think we'll just have to leave it at that.  gui_thread works
nicely for me under both 2.4 and 2.5.

cheers,
prabhu



From rkern at ucsd.edu  Wed Oct  6 21:32:07 2004
From: rkern at ucsd.edu (Robert Kern)
Date: Wed, 06 Oct 2004 18:32:07 -0700
Subject: [SciPy-dev] Plan for releasing Scipy 0.3.2
In-Reply-To: <Pine.LNX.4.61.0410061342160.21635@scipy.org>
References: <Pine.LNX.4.61.0410061342160.21635@scipy.org>
Message-ID: <41649C97.8040709@ucsd.edu>

SciPy CVS passes all tests on Mac OSX 10.3.5 with ATLAS. Even gui_thread 
with wxPython 2.5.2.7 works.

-- 
Robert Kern
rkern at ucsd.edu

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



From prabhu at aero.iitm.ernet.in  Thu Oct  7 03:07:58 2004
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Thu, 7 Oct 2004 12:37:58 +0530
Subject: [SciPy-dev] Plan for releasing Scipy 0.3.2
In-Reply-To: <41649C97.8040709@ucsd.edu>
References: <Pine.LNX.4.61.0410061342160.21635@scipy.org>
	<41649C97.8040709@ucsd.edu>
Message-ID: <16740.60238.328508.816658@monster.linux.in>

>>>>> "RK" == Robert Kern <rkern at ucsd.edu> writes:

    RK> SciPy CVS passes all tests on Mac OSX 10.3.5 with ATLAS. Even
    RK> gui_thread with wxPython 2.5.2.7 works.

Thanks, that gui_thread works on the Mac is good news.  So far no
reports from the Windows users. :(

cheers,
prabhu



From pearu at scipy.org  Thu Oct  7 04:54:57 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Thu, 7 Oct 2004 03:54:57 -0500 (CDT)
Subject: [SciPy-dev] Plan for releasing Scipy 0.3.2
In-Reply-To: <16740.60238.328508.816658@monster.linux.in>
References: <Pine.LNX.4.61.0410061342160.21635@scipy.org>
	<41649C97.8040709@ucsd.edu>
	<16740.60238.328508.816658@monster.linux.in>
Message-ID: <Pine.LNX.4.61.0410070344250.21635@scipy.org>



On Thu, 7 Oct 2004, Prabhu Ramachandran wrote:

>>>>>> "RK" == Robert Kern <rkern at ucsd.edu> writes:
>
>    RK> SciPy CVS passes all tests on Mac OSX 10.3.5 with ATLAS. Even
>    RK> gui_thread with wxPython 2.5.2.7 works.
>
> Thanks, that gui_thread works on the Mac is good news.  So far no
> reports from the Windows users. :(

Just tried under Windows:

import gui_thread
gui_thread.start()
from scipy.plt import *
plot([1,2])

works fine. However, running wxPython demo did not quite work. There 
appeared a Tip-window already before `d.Show()` but that freezed. But 
Python prompt was interactive. The main window of the demo program did not 
show up at all.

Pearu



From pearu at scipy.org  Thu Oct  7 09:53:44 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Thu, 7 Oct 2004 08:53:44 -0500 (CDT)
Subject: [SciPy-dev] Releasing Scipy 0.3.2, closing up
Message-ID: <Pine.LNX.4.61.0410070841200.21635@scipy.org>


Hi,

I have created a branch for Scipy 0.3.2 release. To check it out, use

   cvs checkout -r v0_3_2 -d scipy_v0_3_2 scipy
   cd scipy_v0_3_2
   cvs checkout -r v0_3_2 scipy_core

(assuming that you have CVSROOT set properly). Use this branch *only* to 
create 0.3.2 Scipy source or binary distributions and for minor bug fixes.

I have already uploaded 0.3.2 Scipy sources to

   http://www.scipy.org/download/scipy/src/

Now I'll start making statically linked binaries for Linux.

Finally, we'll need:

- RPMs (Travis,Joe?)
- Win32 installers (Travis,Pearu?)
- Update http://www.scipy.org/download/ page.
- Sending out release announcements (Eric?, Travis?,..)

Regards,
Pearu



From bhoel at web.de  Thu Oct  7 14:49:43 2004
From: bhoel at web.de (=?iso-8859-15?q?Berthold_H=F6llmann?=)
Date: Thu, 07 Oct 2004 20:49:43 +0200
Subject: [SciPy-dev] Re: Plan for releasing Scipy 0.3.2
In-Reply-To: <41646A1A.7090201@ee.byu.edu> (Travis Oliphant's message of
	"Wed, 06 Oct 2004 15:56:42 -0600")
References: <Pine.LNX.4.61.0410061342160.21635@scipy.org>
	<m2zn2zvaoc.fsf@pchoel.psh> <41645EC6.1040308@ee.byu.edu>
	<m2vfdnv8cz.fsf@pchoel.psh> <41646A1A.7090201@ee.byu.edu>
Message-ID: <m2ekka1hyw.fsf@pchoel.psh>

Travis Oliphant <oliphant at ee.byu.edu> writes:

...
>>
>>
> Thanks for the information.  This looks like a genuine bug.  You
> should not be getting this much of a difference.  Is the problem
> related to gcc 3.4.2?  Is anybody using that particular compiler?
> The problem is the statlib.swilk  function.  Apparently, It is not
> returning the correct value on your system.   This function is in
> Fortran and so either gcc 3.4.2 is compiling it differently or the
> f2py-generated interface is not functioning correctly.

OK, the problem seems to be related to the gcc version. When I compile
scipy CVS with gcc 3.3.1 "python -c 'import scipy ; scipy.test()'"
finishes without error, even with 

>python
Python 2.4a3 (#1, Sep  9 2004, 20:49:30) 
[GCC 3.4.2] on linux2


> Could you manually run the test that is failing and give the output of
> stats.shapiro(x2) using the x2 in the test_morestats.py file near line
> 40?

I get

0.959027051926 1.0

from

print w,pw

Regards
Berthold
-- 
bhoel at web.de / http://starship.python.net/crew/bhoel/



From jelle.feringa at ezct.net  Tue Oct  5 10:51:23 2004
From: jelle.feringa at ezct.net (Jelle Feringa // EZCT / Amsterdam)
Date: Tue, 5 Oct 2004 16:51:23 +0200
Subject: [SciPy-dev] python / mathematica
Message-ID: <20041005145030.CCF9E18000EE@mwinf0108.wanadoo.fr>

Dear Mr Perez,

I'm sorry to get back to a discussing which has been long due.
My interest in combining the powers of both Mathematica and Python.
I've been checking out for instance PY_ML, I'm sure you are aware of it,
also the fact that its outdated (for Mathematica v3, I'm using 5)
Could you be so kind to point me in the right direction for the interface as
being discussed in the scipy forum?

Best regards,

Jelle Feringa.


------------------
http://www.scipy.org/documentation/mailman?fn=scipy-dev/2002-September/00116
2.html -----

On Fri, 13 Sep 2002, Mark Evans wrote:

> My particular project involved an ActiveX chart control interfaced to
> wxPython, and a Python interface to both Mathematica and Numerical Python.
> We were creating a technical workspace environment with Python as the
> front end and Numpy / Mathematica as cooperating back ends.
> I can't tell you what relief I felt after I switched from CXX to Boost.

That sounds very interesting. Did this project ever make it to the public? 
Here in my group we use Mathematica a _lot_ and I'm pushing python hard for 
the numerical parts (as a replacement for matlab, trying to only write 
C/Fortran when absolutely necessary). But being able to have the python and 
mathematica parts talk would be great. Could you provide a bit more info on 
this?

Since it's a bit off the original thread topic, feel free to either respond 
privately or start a new thread.

Cheers,

f.





From answer at tnoo.net  Tue Oct  5 13:52:35 2004
From: answer at tnoo.net (=?iso-8859-1?q?Martin_L=FCthi?=)
Date: 05 Oct 2004 09:52:35 -0800
Subject: [SciPy-dev] Re: Bug in scipy import
References: <m3mzz25mmo.fsf@sandy.gi.alaska.edu> <41626A53.5010905@ee.byu.edu>
Message-ID: <m3is9p59y4.fsf@sandy.gi.alaska.edu>

Hi Travis

Thanks for your explanation.

Travis Oliphant <oliphant at ee.byu.edu> writes:

> >====
> >import scipy
> >====
> >
> >imports and executes any file named "new.py" in the current working

> I think this 'bug' will happen anytime you name a file using a Python module
> name that another module is expecting.    Your  new.py file is over-riding the
> Python module new here that parts of scipy depends on.
> 
> Try naming a file re.py in your current directory and you will get similar
> problems.  -Travis

So whether a given library works depends on the file names that one has in a
random directory. Hmmm. This is a nasty behavior, and I'm glad I never run
this before. To me this looks like a design flaw if the module names from the
standard library are not __somehow__ protected.

I'll have to ponder about PYTHON_PATH, but this whole business seems to be
quite fragile. As little as I like Java, the module naming scheme is the one
thing that they got right. Time for a PEP?

Best, Martin

-- 
Martin L?thi                 answer at tnoo.net



From answer at tnoo.net  Wed Oct  6 20:25:34 2004
From: answer at tnoo.net (=?iso-8859-1?q?Martin_L=FCthi?=)
Date: Wed, 06 Oct 2004 16:25:34 -0800
Subject: [SciPy-dev] Test failures
Message-ID: <m3hdp774sh.fsf@sandy.gi.alaska.edu>

Hi 

Here is the output (2 failures, 2 errors) of the tests on my box

Python 2.3.3 (#1, Apr  6 2004, 01:47:39) 
[GCC 3.3.3 (SuSE Linux)] on linux2

gcc version 3.3.3

>>> scipy.__version__
'0.3.1_287.4340'


======================================================================
ERROR: check_defective1 (scipy.linalg.matfuncs.test_matfuncs.test_signm)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.3/site-packages/scipy/linalg/tests/test_matfuncs.py", lin
e 48, in check_defective1
    r = signm(a)
  File "/usr/lib/python2.3/site-packages/scipy/linalg/matfuncs.py", line 267, in s
ignm
    iS0 = inv(S0)
  File "/usr/lib/python2.3/site-packages/scipy/linalg/basic.py", line 176, in inv
    a1 = asarray_chkfinite(a)
  File "/usr/lib/python2.3/site-packages/scipy_base/function_base.py", line 33, in
 asarray_chkfinite
    raise ValueError, "Array must not contain infs or nans."
ValueError: Array must not contain infs or nans.

======================================================================
ERROR: check_defective3 (scipy.linalg.matfuncs.test_matfuncs.test_signm)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.3/site-packages/scipy/linalg/tests/test_matfuncs.py", lin
e 69, in check_defective3
    r = signm(a)
  File "/usr/lib/python2.3/site-packages/scipy/linalg/matfuncs.py", line 267, in s
ignm
    iS0 = inv(S0)
  File "/usr/lib/python2.3/site-packages/scipy/linalg/basic.py", line 176, in inv
    a1 = asarray_chkfinite(a)
  File "/usr/lib/python2.3/site-packages/scipy_base/function_base.py", line 33, in
 asarray_chkfinite
    raise ValueError, "Array must not contain infs or nans."
ValueError: Array must not contain infs or nans.

======================================================================
FAIL: check_nils_20Feb04 (scipy.linalg.basic.test_basic.test_solve)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.3/site-packages/scipy/linalg/tests/test_basic.py", line 1
12, in check_nils_20Feb04
    assert_array_almost_equal(X,Ainv)
  File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 684, in asse
rt_array_almost_equal
    assert cond,\
AssertionError: 
Arrays are not almost equal (mismatch 50.0%):
        Array 1: [[-43.6032104+13.1816127j  18.994452 +15.8269203j]
 [ 37.1899302 +2.3715189j  -9.3834051-17.4805578j]]
        Array 2: [[-27.7762901 -5.8128393j  18.994452 +15.8269203j]
 [ 19.7093724+11.754924j   -9.3834051-17.4805578j]]


======================================================================
FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_gumbel_l)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "<string>", line 10, in check_cdf
AssertionError: D = 0.292383217812; pval = 0.00455751677656; alpha = 0.01
args = ()

----------------------------------------------------------------------
Ran 972 tests in 2.078s

FAILED (failures=2, errors=2)

-- 
Martin L?thi                 answer at tnoo.net



From Fernando.Perez at colorado.edu  Thu Oct  7 20:32:20 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Thu, 07 Oct 2004 18:32:20 -0600
Subject: [SciPy-dev] Re: Bug in scipy import
In-Reply-To: <m3is9p59y4.fsf@sandy.gi.alaska.edu>
References: <m3mzz25mmo.fsf@sandy.gi.alaska.edu> <41626A53.5010905@ee.byu.edu>
	<m3is9p59y4.fsf@sandy.gi.alaska.edu>
Message-ID: <4165E014.2090504@colorado.edu>

Martin L?thi schrieb:

> So whether a given library works depends on the file names that one has in a
> random directory. Hmmm. This is a nasty behavior, and I'm glad I never run
> this before. To me this looks like a design flaw if the module names from the
> standard library are not __somehow__ protected.
> 
> I'll have to ponder about PYTHON_PATH, but this whole business seems to be
> quite fragile. As little as I like Java, the module naming scheme is the one
> thing that they got right. Time for a PEP?

Don't bother.  As of python 2.4 (or is it 2.5?, I don't recall), imports will 
require an absolute path, so this problem should be much less common.

http://www.python.org/peps/pep-0328.html

Best,

f



From Fernando.Perez at colorado.edu  Thu Oct  7 23:12:04 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Thu, 07 Oct 2004 21:12:04 -0600
Subject: [SciPy-dev] python / mathematica
In-Reply-To: <20041005145030.CCF9E18000EE@mwinf0108.wanadoo.fr>
References: <20041005145030.CCF9E18000EE@mwinf0108.wanadoo.fr>
Message-ID: <41660584.5040706@colorado.edu>

Jelle Feringa // EZCT / Amsterdam schrieb:
> Dear Mr Perez,
> 
> I'm sorry to get back to a discussing which has been long due.
> My interest in combining the powers of both Mathematica and Python.
> I've been checking out for instance PY_ML, I'm sure you are aware of it,
> also the fact that its outdated (for Mathematica v3, I'm using 5)
> Could you be so kind to point me in the right direction for the interface as
> being discussed in the scipy forum?

Well, I don't really know more than what's on that archive.  I don't have 
direct contact with the person who mentioned the mathematica project, so you'd 
have to dig him out of the internet :)

Here, we've mostly just kept mathematica and python as parallel tools without 
much communication.  All I can offer, I guess, are a couple of little 
utilities I wrote to facilitate exchaning _data_ between the two with minimal 
fuss.  But this is NOT an API for cross-calling, just a way to automatically 
generate a .py module from within a mathematica file and to auto-generate a .m 
file out of python variables.  I'll just post them here in case they are 
useful to you or others.  I guess that perhaps some of this could make it into 
some 'utilities' area of scipy, much like the facilities for interfacing with 
matlab files.  Obviously this requires having mathematica installed, since I 
didn't write anything for reading .m files in python.

Best,

f

Please note that while the code below has been used for real work, it's not 
exhaustively tested.  Test first :)

#############################
# Python code
import sys
import Numeric as N

def MathematicaSave(fname,varnames,ns=None,precision=18):
     """Save a list of names to a Mathematica file.

     The resulting file can be used in Mathematica via '<<fname'.

     Inputs:

     - fname: name of mathematica file, typically ending in .m.

     - varnames: a list/tuple of names to be used

     Optional:

     - ns: a namespace where the list of names is to be evaluated, typically
     locals().  If not provided, this function automatically extracts the
     locals() of the caller.

     - precision: float precision passed to Numeric's array2string function.

     Caveats:

     - This function is NOT perfect, because Mathematica's floating point
     format requires changing numbers from 1.23e+04 to 1.23^*+04.  This is done
     as a string replacement on 'e', so accidentally strings may end up
     modified (though for normal strings the code tries to avoid this).

     - Mathematica does NOT allow underscores in variable names.  This function
     simply removes them blindly, so if you try to save both 'ab' and 'a_b',
     the second one will overwrite the first."""

     # get all variables first
     if ns is None:
         ns = sys._getframe(1).f_locals
     val = {}
     try:
         for varname in varnames:
             val[varname] = ns[varname]
     except KeyError,key:
         print '*** ERROR ***'
         print 'Variable not found:',key
         print 'Aborting without creating file \'%s\'' % fname
         return

     # Our values for generating repr().  There's a bug in array2string, so I
     # need to put things into sys and use repr(), which seems to be the only
     # string-generating function which works correctly
     output_line_width = 80
     float_output_precision = precision

     # Don't mess up user settings
     save_olw = save_fop = 0
     if hasattr(sys,'output_line_width'):
         save_olw = 1
         save_olw_val = sys.output_line_width
     if hasattr(sys,'float_output_precision'):
         save_fop = 1
         save_fop_val = sys.float_output_precision

     # Store values in sys
     sys.output_line_width = output_line_width
     sys.float_output_precision = float_output_precision

     # if we get this far, we have everything we need for saving
     mfile = open(fname,'w')
     print >> mfile,'(* File automatically created by Python. *)\n'
     for name in varnames:
         var = val[name]
         if type(var) == N.ArrayType: # numeric arrays
             vstr = N.array_repr(var)
             vstr = vstr.replace('[','{').replace(']','}').replace('e','*^')
             vstr = vstr.replace('array(','').replace(')','')
         elif isinstance(var,str):  # simple strings
             vstr = '"%s"' % var
         elif hasattr(var,'__getslice__'):  # lists, tuples, etc
             vstr = str(var).replace('[','{').replace(']','}').replace('e','*^')
         elif isinstance(var,(float,complex)):  # single float/complex numbers
             vstr = str(var).replace('e','*^')
         else: # the rest.  This probably won't be valid Mathematica
               # except for integers.
             vstr = str(var)
         # Save the variable's representation to the Mathematica file, removing
         # all underscores from the name
         print >> mfile,'%s = %s;\n' % (name.replace('_',''),vstr)
     mfile.close()

     # Restore user settings
     if save_olw:
         sys.output_line_width = save_olw_val
     if save_fop:
         sys.float_output_precision = save_fop_val


#############################
# Mathematica code

pythonSave[fname_, symnames_List, precision_:24] := Module[
       {k, sym, symname, snamestr, symCForm, pysym, pyfile},
       pyfile = OpenWrite[fname];
       (* Write python header.
             Mathematica uses "\< ... \>" for multiline strings *)

       WriteString[pyfile,
         "\<\"\"\" *** FILE AUTO-GENERATED BY MATHEMATICA.  DO NOT EDIT!!! *** \
\"\"\"

from Numeric import array

\>"];
       For[k = 1, k <= Length[symnames], k++,
         symname = Extract[Unevaluated[symnames], k, Hold];
         snamestr =
           StringReplace[ToString[symname], {"Hold[" -> "", "]" -> ""}];
         sym = SetPrecision[ReleaseHold[symname], precision];
         pysym = ToString[sym, CForm];
         (* Print["name: ", symname];
           Print["name2: ", snamestr];
           Print["sym:  ", sym]; *)
         (* For lists,
           CForm doesn't cut it in python, we need to change things a bit *)

               If[Head[sym] === List,

           pysym = StringForm["array(`1`)",
                 StringReplace[pysym, {"List(" -> "[", ")" -> "]"}]];
           ];
         WriteString[pyfile, StringForm["`1` = `2`\n\n", snamestr, pysym]];
         ]; (* End for loop *)
       Close[pyfile];
       ] (* End module *);
SetAttributes[pySave, HoldRest];

#############################



From Fernando.Perez at colorado.edu  Wed Oct  6 22:40:44 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 06 Oct 2004 20:40:44 -0600
Subject: [SciPy-dev] Plan for releasing Scipy 0.3.2
In-Reply-To: <16740.38347.860162.317064@monster.linux.in>
References: <Pine.LNX.4.61.0410061342160.21635@scipy.org>
	<41646F84.2060006@colorado.edu>
	<16740.38347.860162.317064@monster.linux.in>
Message-ID: <4164ACAC.30003@colorado.edu>

Prabhu Ramachandran wrote:

> Even if you did that there is no guarantee that we'll be able to fix
> it.  I think we'll just have to leave it at that.  gui_thread works
> nicely for me under both 2.4 and 2.5.

Well,  I'll leave the decision up to you guys.  Hopefully it's something funky 
  with my system and we won't get failures on all Fedora2 boxes out there. 
Without hearing from other FC2 users, it's really hard to tell right now.

Fedora3 is due for release in a few weeks, and I assume it will have wx 2.5. 
Perhaps that will fix things.

Cheers,

f



From pearu at scipy.org  Sat Oct  9 18:00:13 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Sat, 9 Oct 2004 17:00:13 -0500 (CDT)
Subject: [SciPy-dev] scipy and ATLAS (in)dependency
Message-ID: <Pine.LNX.4.61.0410091614130.26420@scipy.org>


Hi,

Today I was reading "Special Session: Making Python attractive to 
General Scientists (Harrington, Greenfield)" notes in

   http://www.scipy.org/wikis/scipy04/ConferenceSchedule

and I was a bit surprised on one of the conclusions that maybe ATLAS 
optimization should be undone due to difficulties in building ATLAS.

Though, IMHO, building recent versions of ATLAS libraries is not difficult 
at all on Linux platforms and not even on MS Windows (there are 
step-by-step instructions available on Scipy site), it just may be a very
time consuming process ;).
It's not even an issue for Mac as Scipy uses its vecLib framework.
I can't say much on the situation on other unix platforms such as irix, 
sun, etc due to the lack of access to such platforms. But most of current 
and potential Scipy users are either on MS Windows, Linux, or Mac anyway..

But that was not the point I was surprised on. It was acctually the fact 
that people seem to be unaware of the possibility to build Scipy without
ATLAS dependency by using Fortran sources of BLAS and LAPACK libraries.
Let me stress that nothing in Scipy requires specifically ATLAS libraries, 
the corresponding interface in scipy.linalg is smart enough to pick up 
ATLAS optimized routines when available and use Fortran BLAS/LAPACK 
routines when they are not.

My point is that there is (almost) nothing to do to "undo ATLAS 
optimization" in Scipy. ATLAS is optional already. However, when ATLAS is 
not available then Scipy needs BLAS/LAPACK libraries that currently must 
be provided by the system or users must download them from Netlib. I think 
that BLAS/LAPACK libraries are the only external libraries that Scipy 
currently depends on.

To get rid of this dependency, I'd suggest include the sources of 
BLAS/LAPACK libraries to Scipy, and use them silently when optimized 
BLAS/LAPACK libraries are not available. This would be very similar to 
scipy.fftpack that silently uses Fortran fftpack sources when FFTW 
libraries are not found.

Just wanted to clear some things up..
Pearu



From rkern at ucsd.edu  Sat Oct  9 20:47:57 2004
From: rkern at ucsd.edu (Robert Kern)
Date: Sat, 09 Oct 2004 17:47:57 -0700
Subject: [SciPy-dev] scipy and ATLAS (in)dependency
In-Reply-To: <Pine.LNX.4.61.0410091614130.26420@scipy.org>
References: <Pine.LNX.4.61.0410091614130.26420@scipy.org>
Message-ID: <416886BD.1020307@ucsd.edu>

Pearu Peterson wrote:

[snip]

> It's not even an issue for Mac as Scipy uses its vecLib framework.

vecLib, which *is* ATLAS under the covers, unfortunately does not 
contain the row-major versions of functions. I still always link against 
a full ATLAS library, but vecLib makes a nice backup for those that 
don't want to spend a day compiling ATLAS.

-- 
Robert Kern
rkern at ucsd.edu

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



From perry at stsci.edu  Sat Oct  9 21:40:31 2004
From: perry at stsci.edu (Perry Greenfield)
Date: Sat, 9 Oct 2004 21:40:31 -0400
Subject: [SciPy-dev] scipy and ATLAS (in)dependency
Message-ID: <NEBBIJKBMLDBLNCEEFOCIEPDFHAA.perry@stsci.edu>

Pearu Peterson wrote:

> Hi,
>
> Today I was reading "Special Session: Making Python attractive to
> General Scientists (Harrington, Greenfield)" notes in
>
>    http://www.scipy.org/wikis/scipy04/ConferenceSchedule
>
> and I was a bit surprised on one of the conclusions that maybe ATLAS
> optimization should be undone due to difficulties in building ATLAS.
>
> Though, IMHO, building recent versions of ATLAS libraries is not
> difficult
> at all on Linux platforms and not even on MS Windows (there are
> step-by-step instructions available on Scipy site), it just may be a very
> time consuming process ;).
> It's not even an issue for Mac as Scipy uses its vecLib framework.
> I can't say much on the situation on other unix platforms such as irix,
> sun, etc due to the lack of access to such platforms. But most of current
> and potential Scipy users are either on MS Windows, Linux, or Mac anyway..
>
> But that was not the point I was surprised on. It was acctually the fact
> that people seem to be unaware of the possibility to build Scipy without
> ATLAS dependency by using Fortran sources of BLAS and LAPACK libraries.
> Let me stress that nothing in Scipy requires specifically ATLAS
> libraries,
> the corresponding interface in scipy.linalg is smart enough to pick up
> ATLAS optimized routines when available and use Fortran BLAS/LAPACK
> routines when they are not.
>
> My point is that there is (almost) nothing to do to "undo ATLAS
> optimization" in Scipy. ATLAS is optional already. However, when ATLAS is
> not available then Scipy needs BLAS/LAPACK libraries that currently must
> be provided by the system or users must download them from
> Netlib. I think
> that BLAS/LAPACK libraries are the only external libraries that Scipy
> currently depends on.
>
> To get rid of this dependency, I'd suggest include the sources of
> BLAS/LAPACK libraries to Scipy, and use them silently when optimized
> BLAS/LAPACK libraries are not available. This would be very similar to
> scipy.fftpack that silently uses Fortran fftpack sources when FFTW
> libraries are not found.
>
> Just wanted to clear some things up..
> Pearu
>
As one of the notetakers I'll admit I don't have much personal
experience with the issue so I could have gotten the conversation
wrong. But I think the gist was that some felt that there should be
easy-to-install binary packaging for all popular platforms, not
easy-to-build packaging (though of course one hopes that is also
available). If having an optimized ATLAS got in the way of that
goal, then it was argued that it would be better to have a slow version
of the linear algebra libraries in the easy-to-install binaries.
Those that needed the optimized versions could build it themselves.
The stress was on making it very painless for people to install
the general setup on their machines and that meant binary installers.
If the conclusion that optimized atlas made that harder (either
on the people doing the binary packaging--thus it never happens--
or the people doing the installing) is wrong, then I should correct
the notes. But I think that was the point of the comments.

Perry




From eric at enthought.com  Sat Oct  9 22:33:22 2004
From: eric at enthought.com (eric jones)
Date: Sat, 09 Oct 2004 21:33:22 -0500
Subject: [SciPy-dev] scipy and ATLAS (in)dependency
In-Reply-To: <NEBBIJKBMLDBLNCEEFOCIEPDFHAA.perry@stsci.edu>
References: <NEBBIJKBMLDBLNCEEFOCIEPDFHAA.perry@stsci.edu>
Message-ID: <41689F72.4040404@enthought.com>

Perry Greenfield wrote:

>Pearu Peterson wrote:
>
>  
>
>>Hi,
>>
>>Today I was reading "Special Session: Making Python attractive to
>>General Scientists (Harrington, Greenfield)" notes in
>>
>>   http://www.scipy.org/wikis/scipy04/ConferenceSchedule
>>
>>and I was a bit surprised on one of the conclusions that maybe ATLAS
>>optimization should be undone due to difficulties in building ATLAS.
>>
>>Though, IMHO, building recent versions of ATLAS libraries is not
>>difficult
>>at all on Linux platforms and not even on MS Windows (there are
>>step-by-step instructions available on Scipy site), it just may be a very
>>time consuming process ;).
>>It's not even an issue for Mac as Scipy uses its vecLib framework.
>>I can't say much on the situation on other unix platforms such as irix,
>>sun, etc due to the lack of access to such platforms. But most of current
>>and potential Scipy users are either on MS Windows, Linux, or Mac anyway..
>>
>>But that was not the point I was surprised on. It was acctually the fact
>>that people seem to be unaware of the possibility to build Scipy without
>>ATLAS dependency by using Fortran sources of BLAS and LAPACK libraries.
>>Let me stress that nothing in Scipy requires specifically ATLAS
>>libraries,
>>the corresponding interface in scipy.linalg is smart enough to pick up
>>ATLAS optimized routines when available and use Fortran BLAS/LAPACK
>>routines when they are not.
>>
>>My point is that there is (almost) nothing to do to "undo ATLAS
>>optimization" in Scipy. ATLAS is optional already. However, when ATLAS is
>>not available then Scipy needs BLAS/LAPACK libraries that currently must
>>be provided by the system or users must download them from
>>Netlib. I think
>>that BLAS/LAPACK libraries are the only external libraries that Scipy
>>currently depends on.
>>
>>To get rid of this dependency, I'd suggest include the sources of
>>BLAS/LAPACK libraries to Scipy, and use them silently when optimized
>>BLAS/LAPACK libraries are not available. This would be very similar to
>>scipy.fftpack that silently uses Fortran fftpack sources when FFTW
>>libraries are not found.
>>
>>Just wanted to clear some things up..
>>Pearu
>>
>>    
>>
>As one of the notetakers I'll admit I don't have much personal
>experience with the issue so I could have gotten the conversation
>wrong. But I think the gist was that some felt that there should be
>easy-to-install binary packaging for all popular platforms, not
>easy-to-build packaging (though of course one hopes that is also
>available). If having an optimized ATLAS got in the way of that
>goal, then it was argued that it would be better to have a slow version
>of the linear algebra libraries in the easy-to-install binaries.
>Those that needed the optimized versions could build it themselves.
>The stress was on making it very painless for people to install
>the general setup on their machines and that meant binary installers.
>If the conclusion that optimized atlas made that harder (either
>on the people doing the binary packaging--thus it never happens--
>or the people doing the installing) is wrong, then I should correct
>the notes. But I think that was the point of the comments.
>  
>
I remember that the discussion mainly focused on binary packages also.  
It isn't that we should remove ATLAS from the options available to 
people building from CVS, but that ATLAS makes building RPMs harder to 
do cleanly (in an automated way) and also calls for many more versions 
of installers for win32.  I think our approach has been to provide 
Pentium III optimized ATLAS in the Python -- Enthought Edition that we 
make available.

Joe Harrington took a pole to see how many people would object to have a 
single generic version of SciPy on the web site for each primary 
platform instead of multiple optimized binaries.  80-90% of the room 
thought this was a good idea to reduce the pain on the people 
maintaining packages.

So:
1.  I don't think we should remove that ATLAS from the system, but it 
might be worth while to make it more obvious (on web pages or whatever)  
to people building from CVS that ATLAS isn't required. 

2. Adding LAPACK/BLAS to the repository would add a lot of code to the 
repository.  I'm not all together opposed to this, but I'm not sure it 
is that great of an idea either. 90% of serious users will link to a 
more optimized version (even if it is a generic version of ATLAS).  This 
pushes me to -0 on the idea.

3. Building a single binary per platform for download from SciPy using a 
generic version of ATLAS is a reasonable trade-off between maintenance 
headache and performance (with "reasonable" here defined by a community 
pole).

thanks,
eric

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



From Fernando.Perez at colorado.edu  Sat Oct  9 23:17:05 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sat, 09 Oct 2004 21:17:05 -0600
Subject: [SciPy-dev] scipy and ATLAS (in)dependency
In-Reply-To: <41689F72.4040404@enthought.com>
References: <NEBBIJKBMLDBLNCEEFOCIEPDFHAA.perry@stsci.edu>
	<41689F72.4040404@enthought.com>
Message-ID: <4168A9B1.1020702@colorado.edu>

eric jones wrote:

> of installers for win32.  I think our approach has been to provide 
> Pentium III optimized ATLAS in the Python -- Enthought Edition that we 
> make available.

I think at least on x86, a P-III is a very reasonable baseline for the 'easy' 
distribution, likely to satisfy I'd bet most users.  Those to whom the 
difference between an SSE-2, P-IV optimized ATLAS and a P-III one is truly 
significant, can definitely take care of themselves and build it.  Given that 
scipy.org already provides a number of precompiled ATLASes (thank you!), most 
of the hard part is already solved even for hand-builds.

Quite honestly, these days building scipy even from CVS very easy (assuming 
you have already Numeric and F2PY in place).  Pseudo shell script follows 
(make it a real one simply by defining ARCH and SCIPY_PATH):

ARCH=P4SSE2_2HT  # set to the right string for your arch
PATH_TO_SCIPY=/your/path/to/scipy

#Grab a prebuilt ATLAS from scipy.org, according to your architecture:
wget 
http://www.scipy.org/download/atlasbinaries/linux/atlas3.6.0_Linux_${ARCH}.tgz

# Unpack the tarball, this makes directory Linux_$ARCH:
tar -xzf atlas3.6.0_Linux_${ARCH}.tgz

./install_atlas.py Linux_${ARCH}
# This is a tiny script I wrote for this purpose, which just copies things
# in the right place.  It's trivial, but it saves me from actually having
# to think what to do.  Attached in case anybody cares.

cd $SCIPY_PATH
cvs -q up -P -d  # update CVS
python setup.py install

That's it! And after you've done it once (so atlas is in place), you really 
just need to re-run the last two lines to update/reinstall.  I used to cringe 
(years ago) at the thought of building scipy by hand, but these days it's 
honestly trivial.

But back to the original topic, I really think the P-III ATLAS is an excellent 
compromise point for most users: it keeps the maintainer's burden under 
control and makes a very good (if not tip-top optimal) click-and-run scipy 
install feasible for new users.

Cheers,

f
-------------- next part --------------
A non-text attachment was scrubbed...
Name: install_atlas.py
Type: text/x-python
Size: 1046 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20041009/ada36cf1/attachment.py>

From M.Reimpell at tu-bs.de  Mon Oct 11 08:04:05 2004
From: M.Reimpell at tu-bs.de (Michael Reimpell)
Date: Mon, 11 Oct 2004 14:04:05 +0200
Subject: [SciPy-dev] Re: scipy and ATLAS (in)dependency
In-Reply-To: <4168A9B1.1020702@colorado.edu>
References: <NEBBIJKBMLDBLNCEEFOCIEPDFHAA.perry@stsci.edu>
	<41689F72.4040404@enthought.com> <4168A9B1.1020702@colorado.edu>
Message-ID: <200410111404.06000.M.Reimpell@tu-bs.de>

> Quite honestly, these days building scipy even from CVS very easy 
(...)
> python setup.py install

For at least some system administrators scattering files into the system 
without adequate packaging managment is not an option. Supported software has 
to fit into the system mainenance process, i.e. on most systems "apt-get 
upgrade" should keep the software up to date. At the moment scipy an its 
dependencies are not very rpm-friendly:

Numeric and SciPy both are statically linked against lapack and blas resp. 
atlas. While this may enhance speed, it also hands the architecture 
dependence over to SciPy.

The standard blas package, at least for fedora core 2, does not contain all 
libraries needed to build SciPy. Thus, this package has to be replaced which 
may interfere with other applications like octave and scilab.

F2PY's setup.py has some failing preconditions about the path, when changing 
to the 'src' directory in line 49:
"F2PY Version 2.43.239_1835
Traceback (most recent call last):
  File "setup.py", line 131, in ?
    if 'install' in sys.argv and need_scipy_distutils():
  File "setup.py", line 49, in need_scipy_distutils
    os.chdir('src')
OSError: [Errno 2] No such file or directory: 'src'
Fehler: Bad exit status from /var/tmp/rpm-tmp.43647 (%install)"
This prevents the rpm from being build.

Both, SciPy and Scipy_core have failing preconditions about the number of rpm 
packages build. E.g. on fedora core 2 the rpm packages build in 
build/bdist.linux-i686/rpm/RPMS/i386/ are SciPy-0.3.1_287.4340-1.i386.rpm and 
SciPy-debuginfo-0.3.1_287.4340-1.i386.rpm

Another minor issue is that the spelling of the package names is inconsistent: 
SciPy vs. Scipy vs. scipy.

Ways to overcome these problems could be: 
Dynamically link atlas and lapack libraries and provide reasonable default rpm 
packages, e.g. i386, i686, athlon and x86_64, for them and standard packages 
(i386, noarch) for the rest.

Statically link atlas and lapack libraries and provide reasonable default rpm 
packages.

Provide src-rpm packages or spec-files.

Michael



From pearu at scipy.org  Mon Oct 11 09:53:58 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Mon, 11 Oct 2004 08:53:58 -0500 (CDT)
Subject: [SciPy-dev] Re: scipy and ATLAS (in)dependency
In-Reply-To: <200410111404.06000.M.Reimpell@tu-bs.de>
References: <NEBBIJKBMLDBLNCEEFOCIEPDFHAA.perry@stsci.edu>
	<41689F72.4040404@enthought.com>
	<200410111404.06000.M.Reimpell@tu-bs.de>
Message-ID: <Pine.LNX.4.61.0410110757470.3819@scipy.org>



On Mon, 11 Oct 2004, Michael Reimpell wrote:

>> Quite honestly, these days building scipy even from CVS very easy
> (...)
>> python setup.py install
>
> For at least some system administrators scattering files into the system
> without adequate packaging managment is not an option. Supported software has
> to fit into the system mainenance process, i.e. on most systems "apt-get
> upgrade" should keep the software up to date. At the moment scipy an its
> dependencies are not very rpm-friendly:

See
   http://www.scipy.org/development/packagescipy.txt

Btw, scipy and its dependencies are now available also as a part of Debian 
sid system thanks to Jos? Fonseca, Alexandre Fayolle and Marco 
Presi. So, if RPM packagers would follow the above document then it should 
be possible to build RPMs without dependency conflicts.

> Numeric and SciPy both are statically linked against lapack and blas resp.
> atlas. While this may enhance speed, it also hands the architecture
> dependence over to SciPy.

And so? Any software that is linked against atlas will have this 
dependence.

> The standard blas package, at least for fedora core 2, does not contain all
> libraries needed to build SciPy. Thus, this package has to be replaced which
> may interfere with other applications like octave and scilab.

To build Scipy, you'll need blas and lapack libraries as minimum. You 
don't need atlas to build Scipy.

> F2PY's setup.py has some failing preconditions about the path, when changing
> to the 'src' directory in line 49:
> "F2PY Version 2.43.239_1835
> Traceback (most recent call last):
>  File "setup.py", line 131, in ?
>    if 'install' in sys.argv and need_scipy_distutils():
>  File "setup.py", line 49, in need_scipy_distutils
>    os.chdir('src')
> OSError: [Errno 2] No such file or directory: 'src'
> Fehler: Bad exit status from /var/tmp/rpm-tmp.43647 (%install)"
> This prevents the rpm from being build.

For some reasons src/fortranobject.{c,h} files were not written to
a MANIFEST file when building RPMs with 'setup.py bdist_rpm'.
I worked around this issue that by including MANIFEST.in to MANIFEST.in.
Try F2PY-2.43.239_1844 again.

> Both, SciPy and Scipy_core have failing preconditions about the number of rpm
> packages build. E.g. on fedora core 2 the rpm packages build in
> build/bdist.linux-i686/rpm/RPMS/i386/ are SciPy-0.3.1_287.4340-1.i386.rpm and
> SciPy-debuginfo-0.3.1_287.4340-1.i386.rpm

This is either distutils or fedora core 2 issue, not Scipy. Have you tried 
building rpms for any other python package with extension modules using 
'setup.py bdist_rpm' in your system? I'll bet you'll get similar failures.

> Another minor issue is that the spelling of the package names is inconsistent:
> SciPy vs. Scipy vs. scipy.

I agree. I would drop using SciPy and use Scipy when referring to the 
project and scipy when referring to Python package.

> Ways to overcome these problems could be:
> Dynamically link atlas and lapack libraries and provide reasonable default rpm
> packages, e.g. i386, i686, athlon and x86_64, for them and standard packages
> (i386, noarch) for the rest.
>
> Statically link atlas and lapack libraries and provide reasonable default rpm
> packages.
>
> Provide src-rpm packages or spec-files.

I hope that someone who is expert in building RPMs could contribute to 
resolve this issue. I can build binaries for a general Linux system and 
make Win32 installers, but I don't have time nor resources to deal with 
RPMs myself.

Regards,
Pearu

From Fernando.Perez at colorado.edu  Mon Oct 11 19:33:54 2004
From: Fernando.Perez at colorado.edu (Fernando.Perez at colorado.edu)
Date: Mon, 11 Oct 2004 17:33:54 -0600
Subject: [SciPy-dev] CVS build just failed
Message-ID: <1097537634.416b1862155b4@webmail.colorado.edu>

Hi all,

I'm trying to build CVS scipy on a new Fedora Core 2 box, and I'm failing pretty
early on.  I suspect the problem is with f2py and not scipy itself.  Here's the
error:

...
compiling Fortran sources
g77(f77) options: '-Wall -fno-second-underscore -Vaxlib -i_dynamic -O3 -funroll-
loops -march=pentium4 -mmmx -msse2 -msse -malign-double -fomit-frame-pointer'
ifc(f90) options: '-Vaxlib -i_dynamic -Vaxlib -i_dynamic -O3 -funroll-loops -mar
ch=pentium4 -mmmx -msse2 -msse -malign-double -fomit-frame-pointer'
ifc(fix) options: '-Vaxlib -i_dynamic -Vaxlib -i_dynamic -O3 -funroll-loops -mar
ch=pentium4 -mmmx -msse2 -msse -malign-double -fomit-frame-pointer'
compile options: '-c'
g77:f77: Lib/fftpack/dfftpack/dcosqb.f
g77: `-V' must come at the start of the command line
g77: `-V' must come at the start of the command line
error: Command "/usr/bin/g77 -Wall -fno-second-underscore -Vaxlib -i_dynamic -O3
 -funroll-loops -march=pentium4 -mmmx -msse2 -msse -malign-double -fomit-frame-p
ointer -c -c Lib/fftpack/dfftpack/dcosqb.f -o build/temp.linux-i686-2.3/Lib/fftp
ack/dfftpack/dcosqb.o" failed with exit status 1


###
I grabbed the latest f2py from the webpage a moment ago (2.43.239_1844) and the
scipy is current CVS.  Any help would be much appreciated.

best,

f



From pearu at scipy.org  Tue Oct 12 01:07:50 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Tue, 12 Oct 2004 00:07:50 -0500 (CDT)
Subject: [SciPy-dev] CVS build just failed
In-Reply-To: <1097537634.416b1862155b4@webmail.colorado.edu>
References: <1097537634.416b1862155b4@webmail.colorado.edu>
Message-ID: <Pine.LNX.4.61.0410112346320.11778@scipy.org>



On Mon, 11 Oct 2004 Fernando.Perez at colorado.edu wrote:

> Hi all,
>
> I'm trying to build CVS scipy on a new Fedora Core 2 box, and I'm failing pretty
> early on.  I suspect the problem is with f2py and not scipy itself.  Here's the
> error:
>
> ...
> compiling Fortran sources
> g77(f77) options: '-Wall -fno-second-underscore -Vaxlib -i_dynamic -O3 -funroll-
> loops -march=pentium4 -mmmx -msse2 -msse -malign-double -fomit-frame-pointer'
> ifc(f90) options: '-Vaxlib -i_dynamic -Vaxlib -i_dynamic -O3 -funroll-loops -mar
> ch=pentium4 -mmmx -msse2 -msse -malign-double -fomit-frame-pointer'
> ifc(fix) options: '-Vaxlib -i_dynamic -Vaxlib -i_dynamic -O3 -funroll-loops -mar
> ch=pentium4 -mmmx -msse2 -msse -malign-double -fomit-frame-pointer'
> compile options: '-c'
> g77:f77: Lib/fftpack/dfftpack/dcosqb.f
> g77: `-V' must come at the start of the command line
> g77: `-V' must come at the start of the command line
> error: Command "/usr/bin/g77 -Wall -fno-second-underscore -Vaxlib -i_dynamic -O3
> -funroll-loops -march=pentium4 -mmmx -msse2 -msse -malign-double -fomit-frame-p
> ointer -c -c Lib/fftpack/dfftpack/dcosqb.f -o build/temp.linux-i686-2.3/Lib/fftp
> ack/dfftpack/dcosqb.o" failed with exit status 1
>
>
> ###
> I grabbed the latest f2py from the webpage a moment ago (2.43.239_1844) and the
> scipy is current CVS.  Any help would be much appreciated.

f2py has little to do with this failure, it's more scipy_distutils or an
end-user issue.

For some reason g77 is used for Fortran 77 codes and ifc for Fortran 90
codes, and the compiler flags get mixed up. Such a situation should not 
happen normally as whenever you specify Fortran compiler to be ifc, it 
should be used both for Fortran 77 and 90 codes.
How did you specified fortran compilers? What command line are you using 
for building scipy?
The correct way to specify ifc is:

   python setup.py config_fc --fcompiler=intel build

Just check, building scipy CVS works ok on a Debian box using the latest 
f2py and intel fortran compilers 7.1 and 8.0. Although compiling 
Lib/linalg/iterative/getbreak.f fails with ifc-7.1, probably due 
to a compiler bug.

Pearu



From Fernando.Perez at colorado.edu  Tue Oct 12 00:58:29 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Mon, 11 Oct 2004 22:58:29 -0600
Subject: [SciPy-dev] CVS build just failed
In-Reply-To: <Pine.LNX.4.61.0410112346320.11778@scipy.org>
References: <1097537634.416b1862155b4@webmail.colorado.edu>
	<Pine.LNX.4.61.0410112346320.11778@scipy.org>
Message-ID: <416B6475.6000708@colorado.edu>

Pearu Peterson wrote:

> For some reason g77 is used for Fortran 77 codes and ifc for Fortran 90
> codes, and the compiler flags get mixed up. Such a situation should not 
> happen normally as whenever you specify Fortran compiler to be ifc, it 
> should be used both for Fortran 77 and 90 codes.
> How did you specified fortran compilers? What command line are you using 
> for building scipy?
> The correct way to specify ifc is:
> 
>    python setup.py config_fc --fcompiler=intel build

Mmh, weird.  This is on a new freshly installed machine, but a friend's.  I'm 
not sure how his environment variables were set up; I simply typed

python setup.py build

without specifying anything else.  Is it normal for scipy_distutils to pick up 
mixed compilers in this case?  I guess I can use the line you suggested and 
just build everything with g77.  Could it be that this user's environment was 
set up in a way which confused distutils?  He's not (yet) a python user, so I 
don't know how much f2py-specific setup he might have in his home account, but 
perhaps there was some leftover crud from some old project.

Which environment variables should I look for which could cause this?  Besides 
getting it to work (which I can do with your suggestion above), I'd like to 
make sure that for a fresh new user something like this can't accidentally 
happen.  This is the kind of error which tends to discourage new users, so if 
a bit of additional instructions can prevent it, we can add that to the info 
on the website.

Many thanks for your help!

Best,

f



From pearu at scipy.org  Tue Oct 12 01:43:39 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Tue, 12 Oct 2004 00:43:39 -0500 (CDT)
Subject: [SciPy-dev] CVS build just failed
In-Reply-To: <416B6475.6000708@colorado.edu>
References: <1097537634.416b1862155b4@webmail.colorado.edu>
	<Pine.LNX.4.61.0410112346320.11778@scipy.org>
	<416B6475.6000708@colorado.edu>
Message-ID: <Pine.LNX.4.61.0410120030160.11778@scipy.org>



On Mon, 11 Oct 2004, Fernando Perez wrote:

> Pearu Peterson wrote:
>
>> For some reason g77 is used for Fortran 77 codes and ifc for Fortran 90
>> codes, and the compiler flags get mixed up. Such a situation should not 
>> happen normally as whenever you specify Fortran compiler to be ifc, it 
>> should be used both for Fortran 77 and 90 codes.
>> How did you specified fortran compilers? What command line are you using 
>> for building scipy?
>> The correct way to specify ifc is:
>> 
>>    python setup.py config_fc --fcompiler=intel build
>
> Mmh, weird.  This is on a new freshly installed machine, but a friend's.  I'm 
> not sure how his environment variables were set up; I simply typed
>
> python setup.py build
>
> without specifying anything else.  Is it normal for scipy_distutils to pick 
> up mixed compilers in this case?

No. In fact, since scipy does not have any Fortran 90 sources, you 
shouldn't see the configuration info for fix and f90 compilers at all.
And that's most strange behaviour in this case, see fcompiler._compile 
method for details.

> I guess I can use the line you suggested 
> and just build everything with g77.  Could it be that this user's environment 
> was set up in a way which confused distutils?  He's not (yet) a python user, 
> so I don't know how much f2py-specific setup he might have in his home 
> account, but perhaps there was some leftover crud from some old project.
>
> Which environment variables should I look for which could cause this? 
> Besides getting it to work (which I can do with your suggestion above), I'd 
> like to make sure that for a fresh new user something like this can't 
> accidentally happen.  This is the kind of error which tends to discourage new 
> users, so if a bit of additional instructions can prevent it, we can add that 
> to the info on the website.

scipy_distutils/fcompiler.py looks for the following environment 
variables ( see customize method):
   F77, F90, F77FLAGS, F90FLAGS, FREEFLAGS, FOPT, FARCH, FDEBUG, FFLAGS, 
LDSHARED, LDFLAGS, RANLIB, ARFLAGS

Check also the output of

   python gnufcompiler.py --verbose
   python intelfcompiler.py --verbose
   python fcompiler.py --verbose

Pearu



From Fernando.Perez at colorado.edu  Tue Oct 12 01:25:01 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Mon, 11 Oct 2004 23:25:01 -0600
Subject: [SciPy-dev] CVS build just failed
In-Reply-To: <Pine.LNX.4.61.0410120030160.11778@scipy.org>
References: <1097537634.416b1862155b4@webmail.colorado.edu>
	<Pine.LNX.4.61.0410112346320.11778@scipy.org>	<416B6475.6000708@colorado.edu>
	<Pine.LNX.4.61.0410120030160.11778@scipy.org>
Message-ID: <416B6AAD.9000606@colorado.edu>

Pearu Peterson wrote:

>>
>>without specifying anything else.  Is it normal for scipy_distutils to pick 
>>up mixed compilers in this case?
> 
> 
> No. In fact, since scipy does not have any Fortran 90 sources, you 
> shouldn't see the configuration info for fix and f90 compilers at all.
> And that's most strange behaviour in this case, see fcompiler._compile 
> method for details.

[...]

Thanks, Pearu.  I don't have access to this box right now, I'll try to get 
there tomorrow and report on the tests you suggested.

Cheers,

f



From prabhu_r at users.sf.net  Tue Oct 12 09:35:27 2004
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Tue, 12 Oct 2004 19:05:27 +0530
Subject: [SciPy-dev] Weave: ext_module headers problems
Message-ID: <16747.56735.156062.270392@monster.linux.in>

Hi,

This question is mostly for Eric.  In ext_tools.ext_module this is the
definition of build_information:

    def build_information(self):
        info = [self.customize] + self._build_information + \
               self.arg_specs().build_information()
        # ...

This means that any headers added via

  ext_module.customize.add_header('foo') 

are added *before* Python.h and this triggers warnings when the
functions are compiled.  This is also what is invoked for all
weave.inline calls (see inline_tools.py line 433).

To get around this I've changed the definition to:

    def build_information(self):
        info = self._build_information + [self.customize] +\
               self.arg_specs().build_information()
        # ...

This fixes the warnings and puts the user headers last.  I am not sure
there is any specific reason that you put self.customize first.  I
just thought I'd check with you before checking the change into CVS.

Thanks.

cheers,
prabhu



From Fernando.Perez at colorado.edu  Tue Oct 12 13:53:44 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 12 Oct 2004 11:53:44 -0600
Subject: [SciPy-dev] CVS build just failed
In-Reply-To: <Pine.LNX.4.61.0410120030160.11778@scipy.org>
References: <1097537634.416b1862155b4@webmail.colorado.edu>
	<Pine.LNX.4.61.0410112346320.11778@scipy.org>	<416B6475.6000708@colorado.edu>
	<Pine.LNX.4.61.0410120030160.11778@scipy.org>
Message-ID: <416C1A28.1060409@colorado.edu>

Pearu Peterson schrieb:
> 

> scipy_distutils/fcompiler.py looks for the following environment 
> variables ( see customize method):
>    F77, F90, F77FLAGS, F90FLAGS, FREEFLAGS, FOPT, FARCH, FDEBUG, FFLAGS, 
> LDSHARED, LDFLAGS, RANLIB, ARFLAGS

FFLAGS was the culprit!  As I said, this was on a friend's machine using his 
user account for the build, and he had some explicit FFLAGS set to -Vaxlib... 
for jobs with the intel compiler.  This threw scipy_distutils for a loop, I guess.

Many thanks for your help.  I don't really know if there is a sensible way to 
anticipate this for newbies like myself who are so prone to making plain dumb 
mistakes...

Anyway, it's solved, and all tests pass happily with current CVS, Numeric 23.5 
and ATLAS for Hyperthreaded P4 from scipy's ATLAS binaries page.

Best regards, and sorry for bothering with such a stupid error on my part.

Fernando.



From eric at enthought.com  Wed Oct 13 02:08:18 2004
From: eric at enthought.com (eric jones)
Date: Wed, 13 Oct 2004 01:08:18 -0500
Subject: [SciPy-dev] Weave: ext_module headers problems
In-Reply-To: <16747.56735.156062.270392@monster.linux.in>
References: <16747.56735.156062.270392@monster.linux.in>
Message-ID: <416CC652.1010904@enthought.com>

Hey Prabhu,

I have some memory of the order being important for another code section 
(like support_code), but I can't concoct an example that breaks off 
hand.  There isn't a unit test that exercises this.

It is reasonable to expect Python.h to always be the first include -- 
except for the special case of blitz.h always needing to be first in a 
file which is special-cased in the weave code generation (gotta love 
that...).

It is OK to check in the change.  If we find an example it breaks in the 
future, we will need to find an approach that gets all the code sections 
assembled in the correct order.

eric

Prabhu Ramachandran wrote:

>Hi,
>
>This question is mostly for Eric.  In ext_tools.ext_module this is the
>definition of build_information:
>
>    def build_information(self):
>        info = [self.customize] + self._build_information + \
>               self.arg_specs().build_information()
>        # ...
>
>This means that any headers added via
>
>  ext_module.customize.add_header('foo') 
>
>are added *before* Python.h and this triggers warnings when the
>functions are compiled.  This is also what is invoked for all
>weave.inline calls (see inline_tools.py line 433).
>
>To get around this I've changed the definition to:
>
>    def build_information(self):
>        info = self._build_information + [self.customize] +\
>               self.arg_specs().build_information()
>        # ...
>
>This fixes the warnings and puts the user headers last.  I am not sure
>there is any specific reason that you put self.customize first.  I
>just thought I'd check with you before checking the change into CVS.
>
>Thanks.
>
>cheers,
>prabhu
>
>_______________________________________________
>Scipy-dev mailing list
>Scipy-dev at scipy.net
>http://www.scipy.net/mailman/listinfo/scipy-dev
>  
>



From prabhu_r at users.sf.net  Wed Oct 13 03:09:42 2004
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Wed, 13 Oct 2004 12:39:42 +0530
Subject: [SciPy-dev] Weave: ext_module headers problems
In-Reply-To: <416CC652.1010904@enthought.com>
References: <16747.56735.156062.270392@monster.linux.in>
	<416CC652.1010904@enthought.com>
Message-ID: <16748.54454.42022.16733@monster.linux.in>

Hi Eric,

Thanks for the clarification.  I've just checked in the change.

cheers,
prabhu

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

    EJ> Hey Prabhu, I have some memory of the order being important
    EJ> for another code section (like support_code), but I can't
    EJ> concoct an example that breaks off hand.  There isn't a unit
    EJ> test that exercises this.

[...]
    EJ> It is OK to check in the change.  If we find an example it
    EJ> breaks in the future, we will need to find an approach that
    EJ> gets all the code sections assembled in the correct order.



From prabhu_r at users.sf.net  Wed Oct 13 03:18:38 2004
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Wed, 13 Oct 2004 12:48:38 +0530
Subject: [SciPy-dev] Weave: ext_module headers problems
In-Reply-To: <16748.54454.42022.16733@monster.linux.in>
References: <16747.56735.156062.270392@monster.linux.in>
	<416CC652.1010904@enthought.com>
	<16748.54454.42022.16733@monster.linux.in>
Message-ID: <16748.54990.293126.351798@monster.linux.in>

>>>>> "PR" == Prabhu Ramachandran <prabhu_r at users.sf.net> writes:

    PR> Hi Eric, Thanks for the clarification.  I've just checked in
    PR> the change.

Ouch, you beat me to it, but left a parenthesis hanging in line 215.
I'll fix that.

cheers,
prabhu




From pearu at scipy.org  Wed Oct 13 09:17:39 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Wed, 13 Oct 2004 08:17:39 -0500 (CDT)
Subject: [SciPy-dev] ANN: SciPy 0.3.2 Released
Message-ID: <Pine.LNX.4.61.0410130804100.11778@scipy.org>


Hi,

Scipy 0.3.2 has been released and binaries are available from the 
scipy.org site:

   http://www.scipy.org

Scipy 0.3.2 is a bug fix release of Scipy 0.3 including the following new 
features:

- wxPython 2.5 support
- reading/writing dense/sparse matrices in Matrix Market format
- iterative solvers, new functions sqrtm, hessenberg
- Constrained Optimization BY Linear Approximation
- discrete Boltzmann, Planck, Levy distributions
- Scipy tests pass now also on 64-bit systems and Mac OSX
etc.

The complete release notes can be found here:

   http://www.scipy.org/download/scipy_release_notes_0.3.2.html

Best regards,

Pearu

BTW Scipy is:
-------------
Scipy is an open source library of scientific tools for Python. Scipy 
supplements the popular Numeric module, gathering a variety of high level 
science and engineering modules together as a single package.

Scipy includes modules for graphics and plotting, optimization, 
integration, special functions, signal and image processing, genetic 
algorithms, ODE solvers, and others.



From nwagner at mecha.uni-stuttgart.de  Thu Oct 14 02:56:03 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Thu, 14 Oct 2004 08:56:03 +0200
Subject: [SciPy-dev] Bug tracker
Message-ID: <416E2303.9010807@mecha.uni-stuttgart.de>

Hi all,

Many of the entries in the bug tracker are outdated.
Is it possible to remove obsolete messages ?
Where can I place a wishlist for new features
(e.g. Rank-revealing QR,...)

Any comment ?

                            Nils



From rkern at ucsd.edu  Thu Oct 14 03:21:05 2004
From: rkern at ucsd.edu (Robert Kern)
Date: Thu, 14 Oct 2004 00:21:05 -0700
Subject: [SciPy-dev] Bug tracker
In-Reply-To: <416E2303.9010807@mecha.uni-stuttgart.de>
References: <416E2303.9010807@mecha.uni-stuttgart.de>
Message-ID: <416E28E1.3010607@ucsd.edu>

Nils Wagner wrote:

> Where can I place a wishlist for new features
> (e.g. Rank-revealing QR,...)

Either use the "feature" or "wish" priorities in the tracker, or add 
your requests to the wiki:

http://www.scipy.org/wikis/featurerequests/

-- 
Robert Kern
rkern at ucsd.edu

"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 Oct 14 03:28:22 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Thu, 14 Oct 2004 09:28:22 +0200
Subject: [SciPy-dev] Bug tracker
In-Reply-To: <416E28E1.3010607@ucsd.edu>
References: <416E2303.9010807@mecha.uni-stuttgart.de>
	<416E28E1.3010607@ucsd.edu>
Message-ID: <416E2A96.2020302@mecha.uni-stuttgart.de>

Robert Kern wrote:

> Nils Wagner wrote:
>
>> Where can I place a wishlist for new features
>> (e.g. Rank-revealing QR,...)
>
>
> Either use the "feature" or "wish" priorities in the tracker, or add 
> your requests to the wiki:
>
> http://www.scipy.org/wikis/featurerequests/
>
Is it really useful to have such a redundance (wiki and "feature" or 
"wish" in the tracker)?

 



From rkern at ucsd.edu  Thu Oct 14 03:43:23 2004
From: rkern at ucsd.edu (Robert Kern)
Date: Thu, 14 Oct 2004 00:43:23 -0700
Subject: [SciPy-dev] Bug tracker
In-Reply-To: <416E2A96.2020302@mecha.uni-stuttgart.de>
References: <416E2303.9010807@mecha.uni-stuttgart.de>
	<416E28E1.3010607@ucsd.edu> <416E2A96.2020302@mecha.uni-stuttgart.de>
Message-ID: <416E2E1B.3070603@ucsd.edu>

Nils Wagner wrote:
> Robert Kern wrote:
> 
>> Nils Wagner wrote:
>>
>>> Where can I place a wishlist for new features
>>> (e.g. Rank-revealing QR,...)
>>
>>
>>
>> Either use the "feature" or "wish" priorities in the tracker, or add 
>> your requests to the wiki:
>>
>> http://www.scipy.org/wikis/featurerequests/
>>
> Is it really useful to have such a redundance (wiki and "feature" or 
> "wish" in the tracker)?

<shrug> The wiki is better for public and persistent discussion. The 
tracker is best used when you have patches to offer.

-- 
Robert Kern
rkern at ucsd.edu

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



From bgoli at sun.ac.za  Thu Oct 14 07:33:48 2004
From: bgoli at sun.ac.za (Brett G. Olivier)
Date: Thu, 14 Oct 2004 13:33:48 +0200
Subject: [SciPy-dev] scipy-0.3.2 and gnuplot install
Message-ID: <416E641C.3090300@sun.ac.za>

Hi

I just noticed that neither
 SciPy_complete-0.3.2.zip nor
 SciPy_complete-0.3.2.tar.gz
contain wgnuplot.exe and gnuplot_helper.exe in /lib/gplt which causes 
installation under windows to fail.

Best regards
Brett



From greenfield at comcast.net  Sat Oct  9 20:57:28 2004
From: greenfield at comcast.net (Perry Greenfield)
Date: Sat, 9 Oct 2004 20:57:28 -0400
Subject: [SciPy-dev] scipy and ATLAS (in)dependency
In-Reply-To: <Pine.LNX.4.61.0410091614130.26420@scipy.org>
Message-ID: <NEBBIJKBMLDBLNCEEFOCCEPDFHAA.greenfield@comcast.net>

Pearu Peterson wrote:

> Hi,
>
> Today I was reading "Special Session: Making Python attractive to
> General Scientists (Harrington, Greenfield)" notes in
>
>    http://www.scipy.org/wikis/scipy04/ConferenceSchedule
>
> and I was a bit surprised on one of the conclusions that maybe ATLAS
> optimization should be undone due to difficulties in building ATLAS.
>
> Though, IMHO, building recent versions of ATLAS libraries is not
> difficult
> at all on Linux platforms and not even on MS Windows (there are
> step-by-step instructions available on Scipy site), it just may be a very
> time consuming process ;).
> It's not even an issue for Mac as Scipy uses its vecLib framework.
> I can't say much on the situation on other unix platforms such as irix,
> sun, etc due to the lack of access to such platforms. But most of current
> and potential Scipy users are either on MS Windows, Linux, or Mac anyway..
>
> But that was not the point I was surprised on. It was acctually the fact
> that people seem to be unaware of the possibility to build Scipy without
> ATLAS dependency by using Fortran sources of BLAS and LAPACK libraries.
> Let me stress that nothing in Scipy requires specifically ATLAS
> libraries,
> the corresponding interface in scipy.linalg is smart enough to pick up
> ATLAS optimized routines when available and use Fortran BLAS/LAPACK
> routines when they are not.
>
> My point is that there is (almost) nothing to do to "undo ATLAS
> optimization" in Scipy. ATLAS is optional already. However, when ATLAS is
> not available then Scipy needs BLAS/LAPACK libraries that currently must
> be provided by the system or users must download them from
> Netlib. I think
> that BLAS/LAPACK libraries are the only external libraries that Scipy
> currently depends on.
>
> To get rid of this dependency, I'd suggest include the sources of
> BLAS/LAPACK libraries to Scipy, and use them silently when optimized
> BLAS/LAPACK libraries are not available. This would be very similar to
> scipy.fftpack that silently uses Fortran fftpack sources when FFTW
> libraries are not found.
>
> Just wanted to clear some things up..
> Pearu
>
As one of the notetakers I'll admit I don't have much personal
experience with the issue so I could have gotten the conversation
wrong. But I think the gist was that some felt that there should be
easy-to-install binary packaging for all popular platforms, not
easy-to-build packaging (though of course one hopes that is also
available). If having an optimized ATLAS got in the way of that
goal, then it was argued that it would be better to have a slow version
of the linear algebra libraries in the easy-to-install binaries.
Those that needed the optimized versions could build it themselves.
The stress was on making it very painless for people to install
the general setup on their machines and that meant binary installers.
If the conclusion that optimized atlas made that harder (either
on the people doing the binary packaging--thus it never happens--
or the people doing the installing) is wrong, then I should correct
the notes. But I think that was the point of the comments.

Perry




From jh at oobleck.astro.cornell.edu  Mon Oct 18 17:35:03 2004
From: jh at oobleck.astro.cornell.edu (Joe Harrington)
Date: Mon, 18 Oct 2004 17:35:03 -0400
Subject: [SciPy-dev] Accessible SciPy (ASP) project
Message-ID: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu>

			   Accessible SciPy

		       Request for Comments #1

			  Joseph Harrington
			   Perry Greenfield

At SciPy '04 we had an animated Birds-of-a-Feather session about
making SciPy more accessible to the general scientific user.  The
session and the many conversations that followed cleared up a lot of
issues and myths about SciPy.  Among a core group of about a dozen
participants, a consensus began to emerge about what needs to be done.
The purpose of this document is to lay out our understanding of that
consensus for your comment (whether or not you have been involved up
to now), to announce our intention to make this vision a reality, and
to solicit everyone's participation and support.  Many hands make
light work, and many brains, properly channeled, make great work.  We
thus introduce the Accessible SciPy (ASP) project.

Please take a moment to look at the BoF presentation, minutes, and
summary at http://www.scipy.org/wikis/scipy04/ConferenceSchedule.
With those documents as background, we lay out the problem, our dream,
and a path to get there.

THE PROBLEM

Python is wonderful for doing scientific computation.  Those who try
it are thrilled by the freedom from arbitrary limitations, legacy
syntaxes, and license managers.  Some of the applications and demos
are stunning.

At the same time, the experience of a new user who comes to SciPy
"cold" is awful.  There is little in the way of instructions for
installing it and running it, even to the "Hello, world!" stage, and
much of that information is outdated.  There is a lengthy description
of the build process, which most users could never follow even if they
wanted to.  It is not even clear what components are in SciPy, what
else is needed, and what the add-ons do.  It is to the millions of
such potential users (which includes every high-school science student
in the world) that the current effort is directed.

We need to say at this point that we are not picking on Enthought.  In
fact, what's on their servers works a great deal better than they
advertise.  One of us was able to do a "yum install SciPy" on a laptop
at the conference.  But, the word "yum" appears nowhere on the web
site, nor does the URL for the repository.  We need to take the
resources being made available by Enthought and create from them the
user experience SciPy needs to thrive.

WHAT'S EXPECTED BY NEW USERS

New users who are not "bit-heads" expect a first-time experience that
goes something like this:

1. They hear about SciPy and are somehow induced to find the site and
   visit.

2. They see a brief front page that says what SciPy is, lists some
   features, and points to a page with more info.  There is a
   reasonable number of relevant links, all clearly laid out on a page
   that is not too busy.  Words on the front page invite them to
   download and try the software.

3. They click "download", and go to a friendly page that offers a
   binary install package for the current version of the software for
   their machine (and others, but they don't care about that).  It
   also offers instructions for installing the package on their
   platform.  For platforms like Red Hat and Debian Linux, the
   instructions say what lines to add to yum.conf or its Debian
   equivalent, though the option to download the binary package
   directly also exists.  The instructions end with:
	how to configure (if necessary, hopefully not),
	how to test the install,
	where to go for help if the install failed,
	a pointer to a "Getting Started With SciPy" document.
   They follow the instructions and it installs fine.

4. They read the "Getting Started" document, which is about 20 pages
   and contains:
   a. A brief (1/2 page) description of SciPy's key characteristics
      from a new user's point of view
   b. A get-your-feet-wet tutorial, for example:
	make a sine wave and a parabola, add them, and plot,
	read some ASCII data and plot it,
	do a Fourier transform of the data and plot it,
	read an image and display it,
	make a second image, add it to the first, and display it, and
	extract an image section, manipulate it, and display it.
   c. The basic (non-programming) Python syntax, including
      array creation, access, and manipulation.
   d. The key elements of Python's interaction with the operating
      system (e.g., the most important environment variables, how to
      tell it where routines are stored, etc.).
   e. A statement on the current state of the software, that there is
      flux in graphics and the underlying array package, but that the
      functionality we teach in the docs will not (likely) go away.
   f. Sources of further information and support, both in the
      downloaded package and on the web.

5. Encouraged by the smoothness of the experience so far, the user
   dives right into some topical docs (for astronomy, biology, etc.),
   buys a book on Python (or even SciPy), subscribes to scipy-user and
   a topical list, downloads add-ons, and becomes productive almost
   immediately.

OUR SOLUTION TO THE CONUNDRUM OF OPEN DEVELOPMENT

SciPy both suffers and benefits from being Open Source Software.  On
the one hand, many developers work on it and it is quite powerful.  On
the other, there is no central organization, so packages can conflict,
there is duplicated work, there are holes, etc.

ASP proposes to provide the organization that is lacking.  Through a
community-driven process, we will solicit help in resolving the issues
and in implementing the solutions.  We will guide new users toward
what the community feels are the best packages for each basic task, so
that new users experience a unified software package with clear
documentation.  At the same time, we will continue to provide the
broadest array of application software possible, and will index all
the available packages and functionality so people can make informed
choices if they decide the defaults are not what they need.

Mainly, we will guide users through selective documentation.  For
example, once we select a more capable graphics package that supports
all platforms, the general user documentation will teach that package
rather than xplt or gplt.  The latter would continue to exist, would
receive whatever support their developers and fans chose to give them,
and would be listed along with all the other graphics options.  They
would merely not be emphasized in the tutorial documentation.  Thus,
nobody will lose functionality or choice.

It is possible that, in the future, another package may supplant one
that the documentation promotes.  In that case, after due
deliberation, we may decide to rewrite the documents to reflect that
change.  Of course, such a change would be undertaken only in
compelling circumstances.

WHAT'S NEEDED TO GET THERE

At the BoF, we identified three key areas that needed to be worked on
in order to realize the experience above: packaging, the web site, and
documentation.  We also identified two situations, graphics and the
numeric/Numarray split, that will confuse (and therefore discourage)
new users until they are resolved.  We will address these first, as
they frame the packaging issues.

SOFTWARE ISSUES

On the graphics front, there are two included packages, gplt and xplt.
One works best on Unix, the other on Windows.  Neither is much to
write home about, and all this is acknowledged.  Considerable effort
has gone into Chaco, but the package has not matured as fast as some
had hoped, and it is still not ready (according to most).  A new
player, matplotlib, is gaining popularity.  With the exception of
contour plots, which are being actively worked on, it seems to
implement the 2D plotting capability of Matlab, with both a similar
user interface to Matlab and a more capable Python-like class library.
It is interactive (you can click on a screen plot and adjust it in
real time).  It works on all platforms.  The BoF consensus was to base
the new documentation on matplotlib and to de-emphasize gplt and xplt
by not mentioning them in the docs at all.  They would remain in SciPy
indefinitely.  Supporters of Chaco may advocate for the selection of
that package instead.  Whether the community goes for this idea will
depend in large part on the state of Chaco (including package
documentation and maintainability by people other than the original
authors) when this decision is made.

On the numeric/Numarray front, it is a problem for some that Numarray
performance is worse for small arrays than that of the older numeric.
Other issues exist as well.  Perry Greenfield is working on getting
the two packages to co-exist such that which one to use can become a
run-time choice of the user, and so that package maintainers can
independently choose to use either one.  It is hoped that ultimately
Numarray will be superior to numeric in all respects, so that numeric
can be deprecated and then later removed.  Thus, the BoF consensus was
to document the use of Numarray for interactive work.

For now, Numarray and matplotlib would not be in the SciPy core.
Numarray will enter the core when the coexistence issues are resolved
and the developers accept it.  matplotlib may enter the core when its
release schedule slows down, but at this point matplotlib releases
much more frequently than SciPy and there are substantial improvements
with each release.  If matplotlib were in the core, users would be
stuck with an incomplete and beta package until the next release of
SciPy, which could be many months away.

PACKAGING

New users generally will not build software from source code anymore.
The packaging goal is thus to produce binary packages for Linux under
both RPM and the Debian Package Manager, and for Mac, Windows, and Sun
using their native package managers.  Support for each of these (and
for other platforms) depends on interested users participating and
contributing good packages on a timely basis.  We appreciate any help
the software developers can provide in producing the packages, but
we expect that most of the packaging work will be done by volunteers
who specialize in this task.

The BoF consensus was to distribute SciPy, Numarray, and matplotlib as
separate binary packages, possibly tied together by a meta-package
that contained only dependencies (for YUM and APT users).  In
addition, the conference was sufficiently impressed with the
interactive experience offered by IPython that it would be included
until it entered the SciPy core.  That move was discussed positively
at the conference.  Optimized matrix routines may be included, or may
be available as an option, depending on our ability both to produce
them in a timely fashion and to provide a simple new-user experience.

DOCUMENTATION

Documentation is undoubtedly the area where the largest number of work
hours remain to be done.  It needs rewriting, or writing for the first
time, at all levels visible to users.  Because of this and the beta
nature of some of the packages, it makes sense to focus on shorter
documents that address specific tasks, rather than something like a
paper book (though that might make sense two to three years from now).
It is important for docs to be well-written: clear, concise,
grammatical, current, complete, correct, and visible.  Thus, it makes
sense to coordinate this effort closely between the writers, relevant
developers, and those planning the overall effort.  The approach of
writing shorter docs will enable participation by a larger group of
writers, thus (we hope) completing the first draft of each document
sooner.  It will also make updates and rewrites easier.  Of course, it
will be important to provide good cross-references to other documents
and the web site, and to keep these up to date.  Needed documentss:

What is SciPy? (listing of features and included packages)
Installing and Testing SciPy on Red Hat Linux
				Debian Gnu-Linux
				MAC
				Windows
				Sun
Getting Started with SciPy
SciPy for IDL Users, with cheat sheet
SciPy for Matlab Users, with cheat sheet
SciPy User's Guide
SciPy Reference Manual
SciPy for Astronomy, Biology, Chemistry, etc.

It was noted at the BoF that Enthought has substantial documentation
in its Windows package in .chm format, and that there is now an X
reader for these files.  Those documents will be broken out for
non-Windows users and may form the bases for one or more of the
documents above, assuming cooperation from Enthought on permissions
and copyrights.

Translations are always a good idea, but can only be obtained in a
community project through the work of competent volunteers.  The
quality of our documentation will be vastly improved by user testing
and comment, and by the participation of more than one person in the
creation of each document.  However, content determines form, so we
should not be shy about making first drafts available, provided that
we continue to work on them.

We will need to agree on a set of standards for writing documents.
Certainly all docs should be available in PDF and HTML, and the source
should be modifiable by anyone on any platform.  The Windows .chm
format may also be a viable target if good tools exist to do it under
Linux and Mac as well as Windows.  The source form must be viable in
the long term and must not leave us in a bind if the text-processing
software ceases to be supported.  Structured Text and LaTeX have been
suggested.  MSWord and other proprietary forms are out.  The major
need for formulae in scientific documentation may push us to LaTeX,
perhaps with a standardized format, but this is open for discussion.

WEB SITE

Probably the easiest step is improving the web site.  Enthought has
provided a Plone-based site, which means that updates by many
contributors will be easy and many features are already there.  Much
of the content needs updating, and many new areas are needed.  For
example:

- The site says that unit tests are the main need from the community.
  Our needs are broader, as evidenced by the BoF conclusions.

- The documentation above needs to be placed on the site as it becomes
  available.

- Pages and mailing lists are needed for topical discussions, each
  managed by a field representative.

- The YUM archive and other download sites need to be linked to the
  main pages.

- The utilitarian, Plone-out-of-the-box appearance should be replaced
  by one with more legible buttons and some lightweight graphics that
  make the page attractive.

- A page with demos and screen shots should be added.

- Pages that present and possibly rate add-on packages are needed.

- Pages of user recipes and web links are needed.

- A page of demos would be nice.

- Throughout, it needs to be clear who is responsible for each page
  and how to reach that person.

- Overall, the site needs to be reorganized to give new users the
  experience outlined above, without making it much less useful for
  experienced users to navigate.

Essentially, scipy.org needs to become a one-stop-shopping web portal
for scientific computing in Python.  By providing current, complete,
and accessible information in an attractive format, the web site will
show potential users that this software is serious business, that it
will not be difficult to learn, and that it is actively maintained by
a large user community.

PRIORITIES

The three areas for improvement can proceed in parallel.  Since
packaging issues affect the documentation, those should be resolved
as soon as possible.

For packaging, we need to:

1. determine whether the idea of replacing xplt and gplt with
matplotlib in the docs is acceptable to the community,

2. determine whether IPython should go into the core,

3. determine whether the "coexistence" approach for resolving the
numeric/Numarray split is a good idea.

Then, we need to roll and field-test the binary packages.  The latter
effort will require volunteers, so if you want your package or
platform to be supported, please sign up.

For documentation, we need to agree on a common source format, an open
copyright, and some stylistic guidelines.  Documents are needed in
roughly the order listed above, though if someone is very inspired to
start on a later one, he or she should proceed.  Suggestions for
additional documents are welcome, as are volunteers to write them.

Goals for the web site are less clear than for packaging and
documentation.  Some mailing list brainstorming on content and format
issues would be a good idea, starting with those above.  Then, we need
to identify page maintainers and get them access.  Several individuals
stepped forward at the BoF, and a web human interface designer has
volunteered to help.  Again, more volunteers are needed.

TOPICAL SOFTWARE

As a parallel effort, there is now critical mass in several
disciplines for the creation of topic-specific software.  For example,
in astronomy, most data come in Flexible Image Transport System (FITS)
format, and there is a package written by Paul Barrett that reads and
writes FITS files in Python.  We wish to encourage these
contributions, to provide guidance for a seamless integration with the
main packages, and to help new users find these resources.  We can
start by hosting topical mailing lists at scipy.org and by providing a
variety of web resources, including package or topic home pages, lists
of packages by topic, and lists of links to packages hosted elsewhere.

ADVOCACY

Once the basics are in place, we can start advocating SciPy to the
broader scientific community.  With luck and a little effort, this
should expand the group of contributors so that the remaining work can
be done more quickly.  Suggestions from the BoF included a conference
kit so that someone can set up a booth that advocates SciPy simply by
printing some posters and handouts and setting up a computer.  Others
included lunchtime talks in departments, killer demos, comparison web
pages, and the best advocacy of all, being a good example to peers.
The BoF identified the need for a user survey.  Individuals can best
judge when and to whom they advocate SciPy.  However, it would make
sense to coordinate any major presentations with the SciPy community,
to ensure good synchronization with new releases, web site work, etc.

CONCLUSION

SciPy is a community project, and the community should coordinate and
review what goes into SciPy.  In that vein, this document is a genuine
request for your comments, and we will hope to maintain this format in
the future so that all voices can be heard.  If you are willing to
work on any part of this effort, please make your intentions known by
adding your name and email (spam-obscured, if you like) to the ASP
Wiki at http://www.scipy.org/wikis/accessible_scipy/.  Since this is a
community project, please be prepared to accept edits, corrections,
and updates from the community, and to ask for help or to hand off
your work to someone else when you are no longer able or willing to
maintain it at the level or rate that is needed.

The vision above is a large one.  However, none of the steps is
particularly large.  Many projects can proceed in parallel and we gain
from the completion of each task.  Discussion will continue, for now,
on the scipy-dev at scipy.org mailing list, with major announcements
copied to scipy-user.  If this topic comes to dominate the list, it
may be split off into its own list, but for now we want to keep all
those working on SciPy apprised of our efforts.  We invite you to join
us in making SciPy the environment of choice for technical
computation, starting with your comments on the plan outlined above.

--jh--



From jh at oobleck.astro.cornell.edu  Mon Oct 18 23:05:18 2004
From: jh at oobleck.astro.cornell.edu (Joe Harrington)
Date: Mon, 18 Oct 2004 23:05:18 -0400
Subject: [SciPy-dev] SciPy Topical Pages wiki
Message-ID: <200410190305.i9J35I4r011460@oobleck.astro.cornell.edu>

Topical or domain-specific pages were a need identified at the SciPy
'04 conference.  Several of these exist, some with their own mailing
lists.  I have just created a wiki page to index such pages, so that
scipy.org can become a portal where users can go to locate any
software that runs under or with SciPy.  The URL is:

http://www.scipy.org/wikis/topical_software/DirectoryOfSciPyTopicalPages

(next time I ask for a wiki, I'll suggest a shorter name...)

What's needed now is for people who maintain such pages to link to
them from the wiki, with just a few words to help users find their
way.  Please list them alphabetically by the most obvious topic name.

Initially, I'm sure there will be some reshuffling.  Maybe the 3D page
I proposed will become a graphics page, for example.  Likely some
areas have two competing pages at the moment.  The few pages that
exist already are not currently hosted on scipy.org.  We'll work
through all that.  For now, please link any topical pages from the
wiki.  If you have items to list on a topical page, hold out for a few
days and see if an appropriate page shows up.  If not, either
volunteer to manage it or ask here on scipy-dev for someone else to
host it.  Please do not list pages for individual packages on the
Topical wiki.

Ideally, the topical pages will eventually be hosted on SciPy.org.
That way, if someone loses interest or moves institutions, the page is
still there for everyone and a new maintainer can be found.  It also
includes the content of those pages in the scipy.org search engine.
So, I encourage page maintainers to follow the instructions on the
wiki and move their pages to scipy.org.  If you prefer to have a
different format for your page, such as a plain web page in the
scipy.org site or a wiki, please bring that up here or ask the
scipy.org web team.  At some point we'll have guidelines for what
format is best.  Experience will tell.

Ok, have at it!

--jh--



From aisaac at american.edu  Tue Oct 19 00:06:54 2004
From: aisaac at american.edu (Alan G Isaac)
Date: Tue, 19 Oct 2004 00:06:54 -0400 (Eastern Daylight Time)
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu>
Message-ID: <Mahogany-0.66.0-1556-20041019-001146.00@american.edu>

On Mon, 18 Oct 2004, Joe Harrington apparently wrote:
> 		       Request for Comments #1


Are user comments desirable?
If so ...

i. Documentation:
make it clear what is copied under what circumstances,
e.g. why a[1][1]=2 can fail to do what a[1,1]=2 does.

ii. axes:
the current SciPy change of the default axes from
the Numeric and numarray defaults is a sure source
of confusion to new users, who are likely to be
relying on the Numeric manual supplemental SciPy guidance!
Please make SciPy adopt the Numeric and numarray
axes conventions and avoid needless confusion here.

iii. matrices:
I can see no reason for matrix objects not to
have many more attributes.  Why should a new
user look for linalg.det(A) instead of just
being able to say A.det?  Similarly for many
linear algebra actions on matrices, esp.
decompositions.  SciPy can change the packages
it relies on for these services at will, as
long as users get a stable interface in
the matrices themselves.

fwiw,
Alan Isaac





From aisaac at american.edu  Tue Oct 19 00:06:54 2004
From: aisaac at american.edu (Alan G Isaac)
Date: Tue, 19 Oct 2004 00:06:54 -0400 (Eastern Daylight Time)
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu>
Message-ID: <Mahogany-0.66.0-1556-20041019-001146.00@american.edu>

On Mon, 18 Oct 2004, Joe Harrington apparently wrote:
> 		       Request for Comments #1


Are user comments desirable?
If so ...

i. Documentation:
make it clear what is copied under what circumstances,
e.g. why a[1][1]=2 can fail to do what a[1,1]=2 does.

ii. axes:
the current SciPy change of the default axes from
the Numeric and numarray defaults is a sure source
of confusion to new users, who are likely to be
relying on the Numeric manual supplemental SciPy guidance!
Please make SciPy adopt the Numeric and numarray
axes conventions and avoid needless confusion here.

iii. matrices:
I can see no reason for matrix objects not to
have many more attributes.  Why should a new
user look for linalg.det(A) instead of just
being able to say A.det?  Similarly for many
linear algebra actions on matrices, esp.
decompositions.  SciPy can change the packages
it relies on for these services at will, as
long as users get a stable interface in
the matrices themselves.

fwiw,
Alan Isaac





From rkern at ucsd.edu  Tue Oct 19 00:50:07 2004
From: rkern at ucsd.edu (Robert Kern)
Date: Mon, 18 Oct 2004 21:50:07 -0700
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <Mahogany-0.66.0-1556-20041019-001146.00@american.edu>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu>
	<Mahogany-0.66.0-1556-20041019-001146.00@american.edu>
Message-ID: <41749CFF.3050009@ucsd.edu>

Alan G Isaac wrote:

> ii. axes:
> the current SciPy change of the default axes from
> the Numeric and numarray defaults is a sure source
> of confusion to new users, who are likely to be
> relying on the Numeric manual supplemental SciPy guidance!
> Please make SciPy adopt the Numeric and numarray
> axes conventions and avoid needless confusion here.

1. Neither Numeric nor numarray have a consistent axis convention to adopt.

2. The only function defined by Numeric that gets overridden by scipy 
and has an axis argument different is cumsum. scipy's cumsum is 
consistent with the axis convention chosen for scipy.

3. Numeric's documentation is incorrect wrt axis defaults for a couple 
of functions in any case.

I'm willing to entertain the suggestion that scipy's cumsum should be 
renamed so as to not override Numeric's (as scipy's prod and cumprod are 
named so as to not override Numeric's product and cumproduct).

> iii. matrices:
> I can see no reason for matrix objects not to
> have many more attributes.  Why should a new
> user look for linalg.det(A) instead of just
> being able to say A.det?  Similarly for many
> linear algebra actions on matrices, esp.
> decompositions.  SciPy can change the packages
> it relies on for these services at will, as
> long as users get a stable interface in
> the matrices themselves.

The main reason is likely that no one has stepped up to implement, 
document, and test these attributes. Write up a patch, submit it to the 
issue tracker <URL:http://www.scipy.net/roundup/scipy/index>, and assign 
the issue to me (rkern).

-- 
Robert Kern
rkern at ucsd.edu

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



From aisaac at american.edu  Tue Oct 19 11:01:30 2004
From: aisaac at american.edu (Alan G Isaac)
Date: Tue, 19 Oct 2004 11:01:30 -0400 (Eastern Daylight Time)
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <41749CFF.3050009@ucsd.edu>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu><Mahogany-0.66.0-1556-20041019-001146.00@american.edu><41749CFF.3050009@ucsd.edu>
Message-ID: <Mahogany-0.66.0-1560-20041019-122101.00@american.edu>

On Mon, 18 Oct 2004, Robert Kern apparently wrote:
> 1. Neither Numeric nor numarray have a consistent axis convention to adopt.

In numarray (which seeks Numeric compatibility) we find

axis=-1:
all of fft stuff
sort, argsort, argmin, argmax, trapz, diff

axis=0:
all of the linear algebra stuff
(except diff in mlab.py, which numarray no longer documents)
along with repeat, concatenate, compress, reduce,
accumulate, average, take, alltrue, sometrue, zreduce,
areduce, put

I consider it a convention to say:
all of the linear algebra stuff uses axis=0,
all of fft stuff uses axis=-1

If the axis question seems pressing for the other functions,
I suggest that for sort, argsort, argmin, argmax, trapz,
diff SciPy can *require* an axis argument, and document this
prominently.  Any other deviation is going to eventually
lead somebody to make a terrible mistake.

It is not tenable for users to know that SciPy relies on
Numeric/numarray but adopts different default behavior.
And, as I said before, this complicates documentation
efforts, which could be a shared effort across Numeric,
numarray, and SciPy.

fwiw,
Alan Isaac





From eric at enthought.com  Tue Oct 19 13:18:09 2004
From: eric at enthought.com (eric jones)
Date: Tue, 19 Oct 2004 12:18:09 -0500
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <Mahogany-0.66.0-1560-20041019-122101.00@american.edu>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu><Mahogany-0.66.0-1556-20041019-001146.00@american.edu><41749CFF.3050009@ucsd.edu>
	<Mahogany-0.66.0-1560-20041019-122101.00@american.edu>
Message-ID: <41754C51.4080703@enthought.com>

Alan G Isaac wrote:

>On Mon, 18 Oct 2004, Robert Kern apparently wrote:
>  
>
>>1. Neither Numeric nor numarray have a consistent axis convention to adopt.
>>    
>>
>
>In numarray (which seeks Numeric compatibility) we find
>
>axis=-1:
>all of fft stuff
>sort, argsort, argmin, argmax, trapz, diff
>
>axis=0:
>all of the linear algebra stuff
>(except diff in mlab.py, which numarray no longer documents)
>along with repeat, concatenate, compress, reduce,
>accumulate, average, take, alltrue, sometrue, zreduce,
>areduce, put
>
>I consider it a convention to say:
>all of the linear algebra stuff uses axis=0,
>all of fft stuff uses axis=-1
>
>If the axis question seems pressing for the other functions,
>I suggest that for sort, argsort, argmin, argmax, trapz,
>diff SciPy can *require* an axis argument, and document this
>prominently.  Any other deviation is going to eventually
>lead somebody to make a terrible mistake.
>
>It is not tenable for users to know that SciPy relies on
>Numeric/numarray but adopts different default behavior.
>And, as I said before, this complicates documentation
>efforts, which could be a shared effort across Numeric,
>numarray, and SciPy.
>  
>
Hey Alan,

I'm sorry you don't like it.  Rest assured it is a well discussed 
topic.  There is a long thread on the numpy-discussion mailing list 
entitled "default axis for numarray" if you would like to see more 
history of points from both sides.  Here is a summary of the reason that 
axis=-1 is used in SciPy.

SciPy adopted axis=-1 for all functions for the sake of consistency 
across the entire user experience with array operations.  As people add 
modules, there is no question what to use for operations that reduce 
dimensionality along a certain axis.  Also there is no question from a 
user's point of view what type of function they are using.  They don't 
have to decide whether an operation is a "reduction" type operation or a 
time series type operation which is the current distinction for 
Numeric.  Some people may have that rule memorized and be able to apply 
it across the libraries consistently, but it takes getting use.  My 
personal experience, experience teaching and also with clients learning 
python has been counter to yours and suggests that a single rule across 
all functions is more easily learned and intuitive.  The rule has the 
added benefit of working over contiguous regions of memory without 
requiring a copying of strided data into an intermediate buffer.  This 
is more efficient and is likely why axis=-1 was chosen for fft and 
friends in the first place.

I don't like the idea of requiring a keyword argument.  Documenting more 
thoroughly is a good idea as with many many things in the SciPy world.

thanks,
eric


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



From aisaac at american.edu  Tue Oct 19 15:14:57 2004
From: aisaac at american.edu (Alan G Isaac)
Date: Tue, 19 Oct 2004 15:14:57 -0400 (Eastern Daylight Time)
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <41754C51.4080703@enthought.com>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu><Mahogany-0.66.0-1556-20041019-001146.00@american.edu><41749CFF.3050009@ucsd.edu>
	<Mahogany-0.66.0-1560-20041019-122101.00@american.edu><41754C51.4080703@enthought.com>
Message-ID: <Mahogany-0.66.0-532-20041019-151802.00@american.edu>

On Tue, 19 Oct 2004, eric jones apparently wrote:
> I'm sorry you don't like it.

That is really not my objection, although
of course everyone has preferences.

If Numeric and numarray were to adopt the
SciPy convention, I would be perfectly
satisfied.  (It seems hard to go that
direction.)

Or, if SciPy provided its own names and
used its own convention, instead of
over-riding Numeric (or numarray) names,
I would also be happy.  Especially if
SciPy names were readily identifiable
as such.  (Of course, one can always
be careful on one's own, but relying on
users to be careful is generally a bad
idea when it is avoidable.)

The issue is consistency.

Can you find me a SciPy user who never uses
Numeric or numarray directly?  Unless this
is most of SciPy users, conflicting defaults
for the same function names will eventually
lead someone to make a terrible mistake.

I intend that claim to be too obvious to
require justification; is it?

Cheers,
Alan Isaac





From eric at enthought.com  Tue Oct 19 15:55:41 2004
From: eric at enthought.com (eric jones)
Date: Tue, 19 Oct 2004 14:55:41 -0500
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <Mahogany-0.66.0-532-20041019-151802.00@american.edu>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu><Mahogany-0.66.0-1556-20041019-001146.00@american.edu><41749CFF.3050009@ucsd.edu>
	<Mahogany-0.66.0-1560-20041019-122101.00@american.edu><41754C51.4080703@enthought.com>
	<Mahogany-0.66.0-532-20041019-151802.00@american.edu>
Message-ID: <4175713D.7030402@enthought.com>

Hey Alan,

Alan G Isaac wrote:

>On Tue, 19 Oct 2004, eric jones apparently wrote:
>  
>
>>I'm sorry you don't like it.
>>    
>>
>
>That is really not my objection, although
>of course everyone has preferences.
>
>If Numeric and numarray were to adopt the
>SciPy convention, I would be perfectly
>satisfied.  (It seems hard to go that
>direction.)
>  
>
There were long discussions about this when numarray was built.

>Or, if SciPy provided its own names and
>used its own convention, instead of
>over-riding Numeric (or numarray) names,
>I would also be happy.  Especially if
>SciPy names were readily identifiable
>as such.  (Of course, one can always
>be careful on one's own, but relying on
>users to be careful is generally a bad
>idea when it is avoidable.)
>
>The issue is consistency.
>  
>
Yes.  We both argue for that.  It is just that you are for consistency 
across libraries (a good thing).  SciPy has chosen to rectify an 
inconsistency (the axis argument) among functions within for numeric 
computing (also a good thing).  The disagreement is which consideration 
trumps the other.

>Can you find me a SciPy user who never uses
>Numeric or numarray directly?  Unless this
>is most of SciPy users, conflicting defaults
>for the same function names will eventually
>lead someone to make a terrible mistake.
>  
>

I agree that the inconsistency is unfortunate.  So are the other 
inconsitencies with Numeric.  For example, SciPy allows comparisons 
between complex numbers by comparing the real part (like Matlab). 

 >>> from scipy import *
 >>> a = array((1,2,3+3j))
 >>> b = array((1,3,3+4j))
 >>> a < b
array([0, 1, 0],'b')

It doesn't throw exceptions and stop computation for div-by-zero and 
other floating point exceptions.

 >>> a = array((-1.,0.,1.))
 >>> a/0.
array([ -1.#INF0000e+000,  -1.#IND0000e+000,   1.#INF0000e+000])

So there are other differences besides 'axis" arguments.  They number is 
small, but there are strong feelings about the benefit of each of the 
ones that stayed.

The SciPy namespace includes everything from Numeric, and the intent is 
that you would use one or the other in your application (either use 
scipy for all imports, or use Numeric).  Using them together indeed will 
result in different behaviors and therefore is a potential problem.  In 
practice, this has not be a major issue at least for us.  We just always 
use SciPy for everything.

When Numarray was implemented by STSci, it used the same conventions 
used in SciPy and chose to maintain backward compatibility with Numeric 
in others.  Experience with new users has led me to believe that the 
SciPy "axis" approach is more intuitive and so I was disappointed in the 
decisions to maintain backward compatiblity with Numeric in these 
areas.  But not terribly so.  It hasn't presented major problems.  So, 
SciPy is destined to have a few different behaviors than either Numeric 
or Numarray (which also behave differently than each other in places). 

thanks,
eric

>I intend that claim to be too obvious to
>require justification; is it?
>
>Cheers,
>Alan Isaac
>
>
>
>_______________________________________________
>Scipy-dev mailing list
>Scipy-dev at scipy.net
>http://www.scipy.net/mailman/listinfo/scipy-dev
>  
>



From rkern at ucsd.edu  Tue Oct 19 17:54:30 2004
From: rkern at ucsd.edu (Robert Kern)
Date: Tue, 19 Oct 2004 14:54:30 -0700
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <Mahogany-0.66.0-532-20041019-151802.00@american.edu>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu><Mahogany-0.66.0-1556-20041019-001146.00@american.edu><41749CFF.3050009@ucsd.edu>
	<Mahogany-0.66.0-1560-20041019-122101.00@american.edu><41754C51.4080703@enthought.com>
	<Mahogany-0.66.0-532-20041019-151802.00@american.edu>
Message-ID: <41758D16.1010806@ucsd.edu>

Alan G Isaac wrote:

> Or, if SciPy provided its own names and
> used its own convention, instead of
> over-riding Numeric (or numarray) names,
> I would also be happy.  Especially if
> SciPy names were readily identifiable
> as such.  (Of course, one can always
> be careful on one's own, but relying on
> users to be careful is generally a bad
> idea when it is avoidable.)

Please stop using the plural. There is precisely one function whose axis 
default gets overridden in this manner, and that is cumsum(). Given that 
there are unittests for it, I can only assume that the override is 
deliberate and chosen with the Numeric incompatibility in mind.

You can still disagree about that decision, but please constrain your 
comments to the specifics: namely, that you think cumsum()'s axis 
argument should default to 0.

My position is that cumsum() should remain as it is, but it and all 
other changes to Numeric's behaviours should be documented. To that end, 
I've started a wiki page.

http://www.scipy.org/wikis/accessible_scipy/NumericCompatibility

-- 
Robert Kern
rkern at ucsd.edu

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



From swisher at enthought.com  Tue Oct 19 19:08:03 2004
From: swisher at enthought.com (Janet Swisher)
Date: Tue, 19 Oct 2004 18:08:03 -0500
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu>
Message-ID: <00bf01c4b630$7c74a080$9c01a8c0@SWISHER>

Some thoughts on documentation:

> -----Original Message-----
> DOCUMENTATION
> 
> Documentation is undoubtedly the area where the largest 
> number of work hours remain to be done.  It needs rewriting, 
> or writing for the first time, at all levels visible to 
> users.  Because of this and the beta nature of some of the 
> packages, it makes sense to focus on shorter documents that 
> address specific tasks, rather than something like a paper 
> book (though that might make sense two to three years from 
> now). It is important for docs to be well-written: clear, 
> concise, grammatical, current, complete, correct, and 
> visible.  

I am happy to help with the "grammatical" part, and with the "clear,
concise" part for any author who wants suggestions in that area. The
user/developer community are the best ones to create "current, complete,
correct" content for docs, so I applaud this effort. (The "visible" part
should be a result of the web site efforts.) I would definitely encourage
anyone to share their hard-won knowledge, even if they don't have greatest
writing skills. The open source peer review process can hone the text, once
the content exists. 

Focussing on shorter documents also defers one of the factors that can make
otherwise well-written documents less usable: poor organization. A short
document has less opportunity to be poorly structured than a long one. A
collection of short documents can be assembled into a helpful organization
as it evolves.

>Needed documentss:

Some of these documents already exist, but perhaps need to be refocussed. 

> What is SciPy? (listing of features and included packages) 

The FAQ document addresses some of these issues. It doesn't have to retain
its current FAQ structure if that's not helpful. (I have also thought about
using Plone features to add true FAQs.)

> Installing and Testing SciPy on Red Hat Linux
> 				Debian Gnu-Linux
> 				MAC
> 				Windows
> 				Sun
> Getting Started with SciPy

There is a "tutorial", but it is not what I usually think of as a tutorial,
which is a step-by-step walk-through of a basic usage scenario that
illustrates commonly-used functions. The existing tutorial starts out that
way, but becomes more of an overview of each of the sub-packages. 

> SciPy for IDL Users, with cheat sheet
> SciPy for Matlab Users, with cheat sheet
> SciPy User's Guide

The current "tutorial" might morph into a general User's Guide.

> SciPy Reference Manual

The existing API doc is generated using epydoc. The docstrings need much
improvement. This is an area where lots of people could contribute a little
bit. We would need to establish some standards to follow (can of worms, to
be opened later).

> SciPy for Astronomy, Biology, Chemistry, etc.
> 
> It was noted at the BoF that Enthought has substantial 
> documentation in its Windows package in .chm format, and that 
> there is now an X reader for these files.  Those documents 
> will be broken out for non-Windows users and may form the 
> bases for one or more of the documents above, assuming 
> cooperation from Enthought on permissions and copyrights.

Eric has the final word on this, but I would think that any use of existing
content that conforms to SciPy's BSD-style license would be acceptable. We
can probably come up with a documentation-oriented variant of the license,
like FreeBSD has
(http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/LEGALNOTICE.html). 

> Translations are always a good idea, but can only be obtained 
> in a community project through the work of competent 
> volunteers.  The quality of our documentation will be vastly 
> improved by user testing and comment, and by the 
> participation of more than one person in the creation of each 
> document.  However, content determines form, so we should not 
> be shy about making first drafts available, provided that we 
> continue to work on them.

OOoAuthors (http://www.oooauthors.org/) is an example of an open source
documentation project that we might emulate.

> We will need to agree on a set of standards for writing 
> documents. Certainly all docs should be available in PDF and 
> HTML, and the source should be modifiable by anyone on any 
> platform.  The Windows .chm format may also be a viable 
> target if good tools exist to do it under Linux and Mac as 
> well as Windows.  The source form must be viable in the long 
> term and must not leave us in a bind if the text-processing 
> software ceases to be supported.  Structured Text and LaTeX 
> have been suggested.  MSWord and other proprietary forms are 
> out.  The major need for formulae in scientific documentation 
> may push us to LaTeX, perhaps with a standardized format, but 
> this is open for discussion.

For any given tool, there is the burden of learning to use the tool, added
to the cognitive load of actually writing the document. No matter how
popular the tool you pick is, there will be some potential contributors who
aren't familiar with it, and have to pay that extra price in order to
participate. As always, there is also a trade-off in ease-of-use vs. power
and flexibility. To keep the barrier to entry low, it might make sense to
use a simple tool (such as ST or RST) for short documents and a powerful
tool (such as LaTeX or DocBook) for longer documents. Note that short
documents can be created directly on the SciPy.org site using Plone or (with
the Zope ExternalEditor plug-in) in the editor of your choice. On the other
hand, if one of the goals is including these docs in the download packages,
that solution might not meet it. On the third hand, many open source
projects have howtos and such that are available only online.

Thanks, Joe, for contributing the energy and enthusiasm to move this
forward.

Regards,
-------------------------
Janet Swisher
Senior Technical Writer
Enthought, Inc.
1-512-536-1057



From aisaac at american.edu  Wed Oct 20 01:53:31 2004
From: aisaac at american.edu (Alan G Isaac)
Date: Wed, 20 Oct 2004 01:53:31 -0400 (Eastern Daylight Time)
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <41758D16.1010806@ucsd.edu>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu><Mahogany-0.66.0-1556-20041019-001146.00@american.edu><41749CFF.3050009@ucsd.edu><Mahogany-0.66.0-1560-20041019-122101.00@american.edu><41754C51.4080703@enthought.com><Mahogany-0.66.0-532-20041019-151802.00@american.edu><41758D16.1010806@ucsd.edu>
Message-ID: <Mahogany-0.66.0-1424-20041020-022251.00@american.edu>

On Tue, 19 Oct 2004, Robert Kern apparently wrote:
> Please stop using the plural. There is precisely one
> function whose axis default gets overridden in this
> manner, and that is cumsum(). Given that there are
> unittests for it, I can only assume that the override is
> deliberate and chosen with the Numeric incompatibility in
> mind.

I get your point, but I see this a bit differently.
i. True, cumprod has a different name, but not one that
differentiates it for a new user
ii. sum has been marked for a possible axis change
(in function_base.py)
iii. On this list it has been emphasized that
        a. the entire Numeric namespace is imported, and
        b. SciPy probably intends to implement a consistent
           convention for axis specification, suggesting an
           unknown number of overrides as time goes by

Look, I'm just a user, and a newbie at that.  I only offered
my view because the developers seem to be interested in
what will make SciPy easy for newbies.  So I thought it
might be useful to hear from a user who got tripped up by
the default axis change.  (Fortunately, it was not serious.)
I have had my say, and I should shut up now.

> My position is that cumsum() should remain as it is, but
> it and all other changes to Numeric's behaviours should be
> documented. To that end, I've started a wiki page.
> http://www.scipy.org/wikis/accessible_scipy/NumericCompatibility

As a user, I will find this very useful.  If you agree, I
will add cumprod to this list, although it is not
technically an override.  Perhaps a "false friends" category
is needed.

Thank you,
Alan Isaac





From barrett at stsci.edu  Thu Oct 21 08:13:41 2004
From: barrett at stsci.edu (Paul Barrett)
Date: Thu, 21 Oct 2004 08:13:41 -0400
Subject: [SciPy-dev] SciPy Topical Pages wiki
In-Reply-To: <200410190305.i9J35I4r011460@oobleck.astro.cornell.edu>
References: <200410190305.i9J35I4r011460@oobleck.astro.cornell.edu>
Message-ID: <4177A7F5.1040008@stsci.edu>

Joe Harrington wrote:

>Topical or domain-specific pages were a need identified at the SciPy
>'04 conference.  Several of these exist, some with their own mailing
>lists.  I have just created a wiki page to index such pages, so that
>scipy.org can become a portal where users can go to locate any
>software that runs under or with SciPy.  The URL is:
>
>http://www.scipy.org/wikis/topical_software/DirectoryOfSciPyTopicalPages
>  
>
Can we get these pages back on line?

 -- Paul

-- 
Paul Barrett, PhD      Space Telescope Science Institute
Phone: 410-338-4475    ESS/Science Software Branch
FAX:   410-338-4767    Baltimore, MD 21218



From arnd.baecker at web.de  Thu Oct 21 10:49:53 2004
From: arnd.baecker at web.de (Arnd Baecker)
Date: Thu, 21 Oct 2004 16:49:53 +0200 (CEST)
Subject: [SciPy-dev] xplt issues
Message-ID: <Pine.LNX.4.51.0410211642360.14469@ptpcp2.phy.tu-dresden.de>

Hi,

As already discussed some time ago on the scipy-user mailing list
we have compiled a list of issues/bugs/wishes concerning scipy.xplt.

The notes below are written in Restructured text and the html version
(+example files) can be found at
  http://www.physik.tu-dresden.de/~baecker/tmp/xplt/xplt_issues.html

Best,

Jan Braun and Arnd Baecker


############################
.. -*- mode: rst -*-

===========
Xplt issues
===========


Remark ahead
============

As already discussed some time ago on this mailing list
we have compiled a list of issues/bugs/wishes concerning xplt.

This text is written in Restructured text
(`ReSt <http://docutils.sourceforge.net/rst.html>`_
and the html version can be found at
`xplt_issues.html
<http://www.physik.tu-dresden.de/~baecker/tmp/xplt/xplt_issues.html>`_).

This text is structured in three parts:

1. Differences between Windows/Linux
2. Platform independent problems
3. A wishlist for improvements of the present behavior

.. contents::


PART I, PORTING PROBLEMS
========================


Plotting one point
------------------

Plotting one point using xplt.plg() leads to differing results
under Windows/Linux depending on the method used:

1. using plg with 1-element arrays: this works fine under Windows,
   where xplt/gist plots a single point at the specified position.
   Under Linux no point is obtained (if one uses standard parameters
   for plg) and you won't see any graphical output.

2. To get xplt/Linux plotting a single point you need to plot a line
   from the point to itself. Alternatively, one can  disable the
   plotting of lines and change the marker.

Try the example `plot_single_points.py <plot_single_points.py>`_ on
Windows and Linux to see this.

::

  from scipy.xplt import *

  x=0.5
  y=1.0
  window()
  pldefault(marks=0)

  # plotting a line from/to the same point
  plg(x*ones(2),y*ones(2),type="dot",marks=0,msize=5)

  # plotting a single point
  plg([1],[1],marks=0,type=0,marker=1,msize=5)



Pause() and Windows
-------------------

The pause() command does not work under Windows. This code

::

  from scipy.xplt import pause

  for x in arange(40):
      print x
      pause( 100 )

should print the numbers from 0 to 39 but will stop right after
printing 0 if started under windows. Example: `pause_windows.py
<pause_windows.py>`_.


Undefined background colors
---------------------------

It seems that the background color of plots depends
on the window manager.
So some people happily plot white symbols on their grey
background, whereas with a different window manager
one can end up with white symbols on a white background.

It would be a good to force a default
background color in the plotting template.


PART II, GENERAL PLOTTING ISSUES
================================


Labeling and titles
-------------------

Without defined limits() the labels given with x-/ylabel are lost
with every scale change.
Using limits() preserves the scale and labels. It even brings back
labels, that were lost after a rescale.
Titles however, are only lost by using fma(). (Applies to titles
defined by pl-/title.)

::

  from scipy.xplt import *

  window( wait=1 )
  xlabel( "xlabel" )	  # creates the xlabel

  x=arange( 100 )

  plg( x, x )		  # destroys the label

  limits( 0, 75, 0, 75 )  # label reappears

  plg( x, x )		  # label is preserved by limits

  fma()
  plg( x, 0.5*x )         # labels are lost now
                          # although the limits are preserved
                          # a new call to limits() won't bring it back

  xlabel( "xlabel" )      # recreating label till next fma()

  plg( x, x )             # labels preserved by old limits


It is not possible to get around multiple label/title definitions
even using limits().
It would be useful to have these commands installing
labels and titles as permanent as the limits used.
Example: `labeling.py <labeling.py>`_.


Missing axes in empty Windows and corrupted mouse input (animate,fma)
---------------------------------------------------------------------

By default xplt knows two coordinate systems for mouse input.
By setting limits() or plotting into a window the default coordinate
system is specified by the visible part of the axes.
In interactive simulations it is often necessary that a user
selects coordinates using the mouse.

All this works fine most of the time, however,
problems occur using the animate() mode or in new windows. Switching
buffers with fma() lets xplt loose the frame of reference for mouse
input. In fact you will get some coordinates between zero and one. If
you don't want to use normalized device coordinates you have to plot
after the fma() or use the axes() command. Supplying limits wont
help.

animate() mode even has another interesting behavior in conjunction
with the mouse() command. If you advance a frame, take mouse input and
draw _one_ graph, the axes are adjusted to the full length, but only a
part of the graph is shown.

::

  from scipy.xplt import *

  window( wait=1 )
  x=arange( 100 )

  animate( 1 )

  plg( .5*x,x)
  fma()
  m=mouse( -1, 1 )                      # mouse input

  print "used c. system:      ", m[8]
  print "  position of mouse: ( ", m[3], ", ", m[4], ")"

  plg( .5*x,x)

  fma()		      # only part of the plot is shown
		      # wont occur if more than one graph is plotted

  m=mouse(-1,1)
  print  "used c. system: ", m[8]     # uses "wrong" coordinate system "0"
  print "  position of mouse: ( ", m[3], ", ", m[4], ")"

  plg(x,x)            # we need to plot something __without__
                      # advancing a frame (no visible change)
  m=mouse(-1,1)
  print  "used c. system: ", m[8]     # now we get the correct c. system "1"
  print "  position of mouse: ( ", m[3], ", ", m[4], ")"

This example is available as `mouse_coords.py <mouse_coords.py>`_.


Plot symbols
------------

The symbols are not properly centered to the point they correspond
to. This seems to be just a vertical problem.

::

  x=arange(0.0,1.01,0.5)

  plg(x*x,x,marker=2,type=0,msize=4,color="red")
  plg(x*x,x,marker=1,type=0,msize=4)
  plg(x*x,x,marker=3,type=0,msize=4,color="green")
  plg(x*x,x,marker=4,type=0,msize=4,)

The different colors are just for illustration and
the effect is not size-dependent, for an example see
`centered_plot_symbols.py <centered_plot_symbols.py>`_.


Memory errors with arrays
-------------------------

::

  x=arange(0.0,1.0,0.1)
  y=2
  plg(y,2)

This code results in the misleading message (??)

::

  MemoryError

Especially beginners have difficulties to correct the code.
A more helpful error message would be better as it should be easy to
check that the arrays are real and of the same length.
Even floats (not arrays) should be allowed as input, IM-HO.


Fast repeated mouse events
--------------------------

Fast clicking on plot windows results in zoom/unzoom events even if
mouse input is desired. This may lead to the impossibility to
restore the original viewport.
While it is possible to disable zoom with zoom_factor( 1 ), it would
be helpful to deactivate the movement of the viewport,


PART III, Wishlist items
========================

Arbitrary size windows under X
-------------------------------

The only possibility to influence the size of windows is the dpi
parameter, which lets one choose between 75 and 100 dpi.
It would be nice to define different window-sizes for display.


Positioning of windows (x-geometry)
-----------------------------------

In addition to the preceeding point it would be nice to define a
window-position.
At the moment you have to rely on the window manager facilities, so
you can't assure useful positions of multiple plot windows.


Several windows and Mouse-clicks
--------------------------------

::

  from scipy.xplt import *

  x=arange( 0.0, 1.0, 0.1 )
  window( 0 )
  plg( x, x )
  window( 1 )
  plg( x*x, x )
  while 1:
      m=mouse( 1, 1, "Click with the mouse, finish with right-click" )
      if m[9]==3: break


Clicking in window 0 one gets the last coordinates
clicked in window 1, but no meaningful answer.


Would it be possible to

- return the correct click-coordinates regardless of the
  "active" window
- add mouse[11] as return parameter
  which contains the window number in which the user clicked
- supply a non-blocking function to report waiting mouse events


Minor
-----

Under X11:

- xlabel too close to the graph
- ylabel too close to the left border







From swisher at enthought.com  Thu Oct 21 11:07:11 2004
From: swisher at enthought.com (Janet Swisher)
Date: Thu, 21 Oct 2004 10:07:11 -0500
Subject: [SciPy-dev] SciPy Topical Pages wiki
In-Reply-To: <4177A7F5.1040008@stsci.edu>
Message-ID: <003901c4b77f$a439af70$ab01a8c0@SWISHER>

Somehow the name of the wiki's root page got changed from
DirectoryOfSciPyTopicalPages to FrontPage. The wiki had a method expecting
the former name.

This link should now work:
http://www.scipy.org/wikis/topical_software/

--Janet

> -----Original Message-----
> From: scipy-dev-bounces at scipy.net 
> [mailto:scipy-dev-bounces at scipy.net] On Behalf Of Paul Barrett
> Sent: Thursday, October 21, 2004 7:14 AM
> To: SciPy Developers List
> Subject: Re: [SciPy-dev] SciPy Topical Pages wiki
> 
> 
> Joe Harrington wrote:
> 
> >Topical or domain-specific pages were a need identified at the SciPy 
> >'04 conference.  Several of these exist, some with their own mailing 
> >lists.  I have just created a wiki page to index such pages, so that 
> >scipy.org can become a portal where users can go to locate 
> any software 
> >that runs under or with SciPy.  The URL is:
> >
> >http://www.scipy.org/wikis/topical_software/DirectoryOfSciPyT
opicalPage
>s
>  
>
Can we get these pages back on line?

 -- Paul

-- 
Paul Barrett, PhD      Space Telescope Science Institute
Phone: 410-338-4475    ESS/Science Software Branch
FAX:   410-338-4767    Baltimore, MD 21218

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



From stephen.walton at csun.edu  Thu Oct 21 13:59:35 2004
From: stephen.walton at csun.edu (Stephen Walton)
Date: Thu, 21 Oct 2004 10:59:35 -0700
Subject: [SciPy-dev] SciPy Topical Pages wiki
In-Reply-To: <003901c4b77f$a439af70$ab01a8c0@SWISHER>
References: <003901c4b77f$a439af70$ab01a8c0@SWISHER>
Message-ID: <1098381575.8249.15.camel@freyer.sfo.csun.edu>

On Thu, 2004-10-21 at 08:07, Janet Swisher wrote:

> This link should now work:
> http://www.scipy.org/wikis/topical_software/

This is probably a Plone issue, but the names of the topics appear in
large, black, boldface type;  i.e., there's no visible indication that
the topic titles are actually hyperlinks to the topic Wikis.  They
should be blue and/or underlined as are the other hyperlinks on the
page.

-- 
Stephen Walton <stephen.walton at csun.edu>
Dept. of Physics & Astronomy, Cal State Northridge
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20041021/c24549b1/attachment.sig>

From oliphant at ee.byu.edu  Thu Oct 21 18:40:16 2004
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Thu, 21 Oct 2004 16:40:16 -0600
Subject: [SciPy-dev] Problems building SciPy with Visual Studio 7.0 (.NET)
Message-ID: <41783AD0.6030008@ee.byu.edu>


I have colleagues who are struggling to build scipy using the Visual 
Studio 7.0 (.NET) compiler

Does anybody know if there are problems building scipy with this compiler?

Thanks,

-Travis



From eric at enthought.com  Fri Oct 22 01:55:52 2004
From: eric at enthought.com (eric jones)
Date: Fri, 22 Oct 2004 00:55:52 -0500
Subject: [SciPy-dev] Problems building SciPy with Visual Studio 7.0 (.NET)
In-Reply-To: <41783AD0.6030008@ee.byu.edu>
References: <41783AD0.6030008@ee.byu.edu>
Message-ID: <4178A0E8.5060805@enthought.com>

I'm interested in this also, although I've never tried very hard with 
anything but gcc...

eric

Travis Oliphant wrote:

>
> I have colleagues who are struggling to build scipy using the Visual 
> Studio 7.0 (.NET) compiler
>
> Does anybody know if there are problems building scipy with this 
> compiler?
>
> Thanks,
>
> -Travis
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev




From pearu at scipy.org  Fri Oct 22 03:31:02 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Fri, 22 Oct 2004 02:31:02 -0500 (CDT)
Subject: [SciPy-dev] Problems building SciPy with Visual Studio 7.0 (.NET)
In-Reply-To: <41783AD0.6030008@ee.byu.edu>
References: <41783AD0.6030008@ee.byu.edu>
Message-ID: <Pine.LNX.4.61.0410220222500.10441@scipy.org>



On Thu, 21 Oct 2004, Travis Oliphant wrote:

>
> I have colleagues who are struggling to build scipy using the Visual Studio 
> 7.0 (.NET) compiler
>
> Does anybody know if there are problems building scipy with this compiler?

I have troubles building scipy even with MSVC-6.0. Basically the 
problem boils down to how to create a gcc.lib file from libgcc.a needed 
for linking mingw32 compiled files to msvc extension modules.

Pearu



From barrett at stsci.edu  Fri Oct 22 13:10:45 2004
From: barrett at stsci.edu (Paul Barrett)
Date: Fri, 22 Oct 2004 13:10:45 -0400
Subject: [SciPy-dev] Re: [Fwd: Scipy topical software wiki]
In-Reply-To: <4176A2FB.70604@stsci.edu>
References: <4176A2FB.70604@stsci.edu>
Message-ID: <41793F15.5000701@stsci.edu>


Russell and I could use some help with the following problems and I thought that 
these issues my be useful to a wider audience.

  -- Paul



This page:
http://www.scipy.org/wikis/topical_software/DirectoryOfSciPyTopicalPages
does not exist but a search turned up the AstroPy page.

I have corrected the mailing list info and made a few minor edits,
but there are several I'd like to see resolved before making this the
official AstroPy page:

* Cosmetic glitches:

- Many words have question marks after them. Based on my limited wiki
experience and some testing, it seems that the wiki *THINKS* these
words *SHOULD* be links to other pages, and is "helpfully" generating
"you could add a page here" links. How do I stop this? (Sigh. I
thought only Microsoft went in for this level of fake pseudo-helpful
intelligence.)

- All my html links have too much space before them. How can I fix this?

* Documentation (which would probably allow me to fix the first two):

The SciPy wiki site seems to be missing documentation on the format
used for SciPy wiki pages. Thus not only am I flying blind, but
anyone else who edits this page will also be doing so. That gives me
the heebie-jeebies.



From swisher at enthought.com  Fri Oct 22 14:28:50 2004
From: swisher at enthought.com (Janet Swisher)
Date: Fri, 22 Oct 2004 13:28:50 -0500
Subject: [SciPy-dev] Re: [Fwd: Scipy topical software wiki]
In-Reply-To: <41793F15.5000701@stsci.edu>
Message-ID: <006701c4b864$fa289320$ab01a8c0@SWISHER>



> -----Original Message-----
 
> Russell and I could use some help with the following problems 
> and I thought that 
> these issues my be useful to a wider audience.
> 
>   -- Paul
> 
> 
> 
> This page: 
> http://www.scipy.org/wikis/topical_software/DirectoryOfSciPyTo
picalPages
does not exist but a search turned up the AstroPy page.

The name of this page got changed after the initial announcement was sent
out. Sorry about that. This URL should work:
http://www.scipy.org/wikis/topical_software

>I have corrected the mailing list info and made a few minor edits, but
there are several I'd like to see resolved before making this the official
AstroPy page:
>
>* Cosmetic glitches:
>
>- Many words have question marks after them. Based on my limited wiki
experience and some testing, it seems that the wiki *THINKS* these words
*SHOULD* be links to other pages, and is "helpfully" generating "you could
add a page here" links. How do I stop this? (Sigh. I thought only Microsoft
went in for this level of fake pseudo-helpful
>intelligence.)

The wiki thinks any word in CamelCaps is a potential link. You can escape
words by putting "!" in front of them. I'll look into whether it's possible
to declare words that should be globally escaped (like "SciPy").

>- All my html links have too much space before them. How can I fix this?

Are you using a text-based browser? If not, you should see little icons
before most links, such a globe for web addresses, a page for FTP addresses,
etc. I think that is the cause of the "extra" space.

>* Documentation (which would probably allow me to fix the first two):
>
>The SciPy wiki site seems to be missing documentation on the format used
for SciPy wiki pages. Thus not only am I flying blind, but anyone else who
edits this page will also be doing so. That gives me the heebie-jeebies.

The SciPy.org wikis use Zwiki (http://zwiki.org/). You can use Structured
Text, ReStructured Text, HTML, or plain text for pages. These chapters of
the Zwiki User Guide are most likely to be useful to users: 
http://zwiki.org/Chapter03BasicUsage
http://zwiki.org/Chapter04Editing

I'll add links to the Zwiki docs to the ASP and Topical SW wikis.

--Janet



From krivilli at unberwoot.net  Sat Oct 23 02:11:34 2004
From: krivilli at unberwoot.net (krivilli at unberwoot.net)
Date: Sat, 23 Oct 2004 01:11:34 -0500 (CDT)
Subject: [SciPy-dev] scipy_test/testing.py: assert_approx_equal -- array
	version (patch)
Message-ID: <3361.200.162.216.175.1098511894.squirrel@200.162.216.175>

HI,

-I'm using scipy_test/testing.py as a 1st try to add tests units into my scripts and reuse some of
it in scipy.optimize.

-When dealing with something like optimize.leastsq, I needed to compare its resulted array (i.e.
optimize.leastsq(...)[0]) against its accuracy. I didn't find anything I could use for this matter
in 'testing.py'. I was looking for a n-dimensional (n>1) version of assert_approx_equal. So I
wrote one (in fact, i just extented 'assert_approx_equal' for n-arrays); I'm not sure if there is
similar code lying around somewhere in scipy_test.


-Bellow goes the patch against testing.py (cvs):



*** testing.py	2004-10-06 20:03:34.000000000 -0300
--- testing.py	2004-10-23 02:06:34.000000000 -0300
***************
*** 10,16 ****
      # If Numeric and scipy_base  are not available, then some of the
      # functions below will not be available.
      from Numeric import alltrue,equal,shape,ravel,around,zeros,Float64,asarray,\
!          less_equal,array2string,less
      import scipy_base.fastumath as math
  except ImportError:
      pass
--- 10,16 ----
      # If Numeric and scipy_base  are not available, then some of the
      # functions below will not be available.
      from Numeric import alltrue,equal,shape,ravel,around,zeros,Float64,asarray,\
!          less_equal,array2string,less,floor,fabs,log10,Float
      import scipy_base.fastumath as math
  except ImportError:
      pass
***************
*** 689,694 ****
--- 689,735 ----
          print x, y
          raise ValueError, 'arrays are not almost equal'

+ __all__.append('assert_array_approx_equal')
+ def assert_array_approx_equal(x,y,significant=7,err_msg=''):
+     x, y = asarray((x, y),Float)
+     msg = '\nItems are not equal to %d significant digits:\n' % significant
+     msg += err_msg
+
+     try:
+         cond = alltrue(equal(shape(x),shape(y)))
+         if not cond:
+             msg = msg + ' (shapes mismatch):\n\t'\
+                   'Shape of array 1: %s\n\tShape of array 2: %s' % (shape(x),shape(y))
+         assert cond, msg + '\n\t' + err_msg
+
+         # Normalized the numbers to be in range (-10.0,10.0)
+         scale = pow(10,floor(log10(0.5*(abs(x)+abs(y)))))
+         try:
+             sc_x = x/scale
+         except ZeroDivisionError:
+             sc_x = zeros(shape(x))
+         try:
+             sc_y = y/scale
+         except ZeroDivisionError:
+             sc_y = zeros(shape(y))
+
+         reduced = fabs(sc_x - sc_y) <= pow(10.,-1*significant)
+         cond = alltrue(reduced)
+         if not cond:
+             s1 = array2string(x,precision=significant+1)
+             s2 = array2string(y,precision=significant+1)
+             if len(s1)>120: s1 = s1[:120] + '...'
+             if len(s2)>120: s2 = s2[:120] + '...'
+             match = 100-100.0*reduced.tolist().count(1)/len(reduced)
+             msg = msg + ' (mismatch %s%%):\n\tArray 1: %s\n\tArray 2: %s' % (match,s1,s2)
+         assert cond,\
+                msg + '\n\t' + err_msg
+     except ValueError:
+         print sys.exc_value
+         print shape(x),shape(y)
+         print x, y
+         raise ValueError, 'arrays are not approximately equal'
+
  __all__.append('assert_array_less')
  def assert_array_less(x,y,err_msg=''):
      x,y = asarray(x), asarray(y)





regards,

-- roberto (krivilli)



From jh at oobleck.astro.cornell.edu  Thu Oct 28 10:12:22 2004
From: jh at oobleck.astro.cornell.edu (Joe Harrington)
Date: Thu, 28 Oct 2004 10:12:22 -0400
Subject: [SciPy-dev] ASP: comments on the web site
Message-ID: <200410281412.i9SECMDe006344@oobleck.astro.cornell.edu>

Things have been quiet since we posted the ASP RFC, at least on the
concerns it raised.  It really is a request for your comments, and not
just a private plan of Perry's and mine.  Success in this area will
require everyone's participation, even if it's just evaluating what
others have done or said and expressing your opinions on this list.
All we're asking for at this point is for you to read the RFC, make
some comments in email, and help populate some wiki pages with links
and concerns.  If you're willing to do real work later, we're also
asking for you to sign up in the area you can work in.

So far only one discipline (astronomy) has posted a page of links on
the "Topical Software" wiki.  Subsequent to posting his page, Russell
Owen offered a critique of the web site, which we identified in the
ASP RFC as needing a makeover.  He's not on this list but hee allowed
me to post his comments here.  Please chime in and respond with your
own ideas of how to make the web site better, both to serve your needs
and to serve those of potential new users.

Finally, would someone from biology and from graphics please step up
to maintain similar pages for those areas?  We need someone from
*every* field, but I know there's lots of good application software in
both those areas.  Maintaining a wiki or a regular page takes only a
small amount of time, an hour a month or less once the page is up, but
it's a crucial step in attracting a broader user base.

Thanks!

--jh--

------- Start of forwarded message -------
In-Reply-To: <006301c4bba0$8c284f70$9c01a8c0 at SWISHER>
Date: Wed, 27 Oct 2004 14:48:16 -0700
To: "Janet Swisher" <swisher at enthought.com>,
        "'Russell E Owen'" <rowen at u.washington.edu>
From: Russell E Owen <rowen at u.washington.edu>
Subject: RE: Help with SciPy.org Wikis
Cc: <joneric at enthought.com>, <jh at oobleck.astro.cornell.edu>
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 
	oobleck.astro.cornell.edu
X-Spam-Level: 
X-Spam-Status: No, hits=-4.9 required=3.9 tests=BAYES_00 autolearn=ham 
	version=2.63

At 4:12 PM -0500 2004-10-26, Janet Swisher wrote:
>>  On the edit tab for a wiki page, a set of options near the bottom
>>  determines which format the wiki uses to interpret the page. If you
>>  edit an existing page, notice which format it is in.
>>  "
>>
>>  So..."notice which format it is in". Sounds good, but HOW?
>
>What I had in mind is that, when you edit a page, you can note which of the
>format radio buttons is selected. I guess I need to make that more explicit.
>
>>  Better yet, how to change it?
>
>You can change the selected radio button, but that does not change the
>contents of the page. If you want to change a page, for example, from ST to
>RST, you would have to make the formatting changes manually.
>...
>When you click the Edit tab, the contents of the page are full of HTML tags,
>and the HTML radio button is selected.

OK, I tried with Safari as well and I see no radio buttons, so I 
think they really and truly are missing (or I am being spectacularly 
blind).

I suspect one needs more god-like privileges than I have to see them, 
perhaps because if a user can see them, a user can toggle them. (If 
so, not allowing just anybody to change how a page is parsed is 
certainly reasonable).

In any case, this is a problem because every editor should be able to 
clearly see what format a page is in.

>>  Request:
>>  - Permanent links to "Topical Software" and "Help with SciPy.org
>>  Wikis" would be a big win. Right now they are only visible because
>>  they are new enough to appear in "recent items".
>
>"Topical Software" is permanently listed in the navigation tree under
>"Wikis". The user does have to know to click "Wikis" to see it. "Help with
>SciPy.org Wikis" is now linked from the root page of the Wikis folder and
>from the root page of the published wikis (except the one for the SciPy 2004
>Conference, which is now mainly historical).
>
>Do you have suggestions about where else these items could be linked that
>would be more visible?

Since you ask, here are my impressions and suggestions.

First the impressions:
- - From the SciPy home page, there is no clue that this site has any 
general "science with Python" information. It just seems to be a site 
about the SciPy software project.
- - One has to first go to "Other Wikis" and then look way down through 
a page that is mostly about SciPy to find "Topical Software".
- - "Topical Software" is not evocative.
- - Burying it so deeply and not mentioning it on the home page give 
the impression that it is very much an afterthoght and not integrated 
into the site.

Suggestions:
- - Rename "Topcial Software" to something like "Python Tools for Science".
- - Explicitly mention "Python Tools for Science" in the text on the 
home page. Try to briefly explain that it exists and perhaps WHY it 
exists. Just a sentence or two should do it. *Talking* about it and 
not just

Further cleanups to consider:
- - Consolidate some of the items in Navigation.
- - Get rid of "Wikis" and those pages to other, more obvious, sub-headings.
- - SciPy should be a recognized link on every scipy wiki (to the SciPy 
home page).

The navigation bar might look like this (with changes noted under each topic):

Navigation:
About SciPy
- - no change (except as mentioned for the body text above)
Documentation:
- - includes "Wikis" links: "Troubleshooting", "SciPy User's Guide 
Wiki" and "Help with SciPy.org Wikis"
   this is touchy and may not fully work because I realize you have 
non-wiki versions of the docs as well,
   but I have seen success with offering users both versions 
side-by-side (let them choose
   if they want docs cluttered up with user comments or not)
Development:
- - include CVS and get rid of the CVS link (i.e. bury the CVS page one 
level deeper)
Bug Tracker:
- - include the standard navigation panel that we are discussing
Mailing Lists
- - no change
Science with Python
- - This is the "Topical Software" page, renamed and brought up one level

Anyway, there are my 2 bits, such as they are. Best of luck with the 
site and the project.

- -- Russell

P.S. Regarding the gaps I was seeing before every link; it turned out 
that enabling background images displayed the icons. If those really 
are background images I am truly amazed, but however it's being done 
seems to work (except for leaving gaps when one doesn't want to see 
images).
------- End of forwarded message -------



From jdhunter at ace.bsd.uchicago.edu  Thu Oct 28 10:33:12 2004
From: jdhunter at ace.bsd.uchicago.edu (John Hunter)
Date: Thu, 28 Oct 2004 09:33:12 -0500
Subject: [SciPy-dev] ASP: comments on the web site
In-Reply-To: <200410281412.i9SECMDe006344@oobleck.astro.cornell.edu> (Joe
	Harrington's message of "Thu, 28 Oct 2004 10:12:22 -0400")
References: <200410281412.i9SECMDe006344@oobleck.astro.cornell.edu>
Message-ID: <m3k6tagbfb.fsf@peds-pc311.bsd.uchicago.edu>

>>>>> "Joe" == Joe Harrington <jh at oobleck.astro.cornell.edu> writes:

    Joe> Finally, would someone from biology and from graphics please
    Joe> step up to maintain similar pages for those areas?  We need
    Joe> someone from *every* field, but I know there's lots of good
    Joe> application software in both those areas.  Maintaining a wiki
    Joe> or a regular page takes only a small amount of time, an hour
    Joe> a month or less once the page is up, but it's a crucial step
    Joe> in attracting a broader user base.

Hmm biology and graphics background, that sounds familiar to me....

I'll do the graphics....  I'll try to be fair, I promise :-).  There
is already a page summarizing python for 3D - I think we can just link
to them for now (but they do leave out VTK...)

  http://www.py3d.org/links

JDH



From jdhunter at ace.bsd.uchicago.edu  Thu Oct 28 10:33:12 2004
From: jdhunter at ace.bsd.uchicago.edu (John Hunter)
Date: Thu, 28 Oct 2004 09:33:12 -0500
Subject: [SciPy-dev] ASP: comments on the web site
In-Reply-To: <200410281412.i9SECMDe006344@oobleck.astro.cornell.edu> (Joe
	Harrington's message of "Thu, 28 Oct 2004 10:12:22 -0400")
References: <200410281412.i9SECMDe006344@oobleck.astro.cornell.edu>
Message-ID: <m3k6tagbfb.fsf@peds-pc311.bsd.uchicago.edu>

>>>>> "Joe" == Joe Harrington <jh at oobleck.astro.cornell.edu> writes:

    Joe> Finally, would someone from biology and from graphics please
    Joe> step up to maintain similar pages for those areas?  We need
    Joe> someone from *every* field, but I know there's lots of good
    Joe> application software in both those areas.  Maintaining a wiki
    Joe> or a regular page takes only a small amount of time, an hour
    Joe> a month or less once the page is up, but it's a crucial step
    Joe> in attracting a broader user base.

Hmm biology and graphics background, that sounds familiar to me....

I'll do the graphics....  I'll try to be fair, I promise :-).  There
is already a page summarizing python for 3D - I think we can just link
to them for now (but they do leave out VTK...)

  http://www.py3d.org/links

JDH



From prabhu_r at users.sf.net  Thu Oct 28 13:34:41 2004
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Thu, 28 Oct 2004 23:04:41 +0530
Subject: [SciPy-dev] ASP: comments on the web site
In-Reply-To: <200410281412.i9SECMDe006344@oobleck.astro.cornell.edu>
References: <200410281412.i9SECMDe006344@oobleck.astro.cornell.edu>
Message-ID: <16769.11697.203071.494751@monster.linux.in>

>>>>> "JH" == Joe Harrington <jh at oobleck.astro.cornell.edu> writes:

    JH> Things have been quiet since we posted the ASP RFC, at least
    JH> on the concerns it raised.  It really is a request for your
    JH> comments, and not just a private plan of Perry's and mine.
    JH> Success in this area will require everyone's participation,
    JH> even if it's just evaluating what others have done or said and
    JH> expressing your opinions on this list.  All we're asking for
    JH> at this point is for you to read the RFC, make some comments
    JH> in email, and help populate some wiki pages with links and
    JH> concerns.  If you're willing to do real work later, we're also
    JH> asking for you to sign up in the area you can work in.

General comments: The ideas sounded very good and quite comprehensive
and I really did not have much to say.  The only problem was how do we
get people involved.  Unfortunately, I have no good solutions for
that.  All the people I know already spend quite a bit of their spare
time writing the various pieces of software.

As regards links to useful software, I sent in a bunch of links to
Fernando after the conference.  I'm not sure what happened.

Why not have a catch all links page with all the links locally sorted
into simple categories.  Its easier to do it that way rather than
manage the links from different places.  What do you think?

cheers,
prabhu



From prabhu_r at users.sf.net  Thu Oct 28 13:34:41 2004
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Thu, 28 Oct 2004 23:04:41 +0530
Subject: [SciPy-dev] ASP: comments on the web site
In-Reply-To: <200410281412.i9SECMDe006344@oobleck.astro.cornell.edu>
References: <200410281412.i9SECMDe006344@oobleck.astro.cornell.edu>
Message-ID: <16769.11697.203071.494751@monster.linux.in>

>>>>> "JH" == Joe Harrington <jh at oobleck.astro.cornell.edu> writes:

    JH> Things have been quiet since we posted the ASP RFC, at least
    JH> on the concerns it raised.  It really is a request for your
    JH> comments, and not just a private plan of Perry's and mine.
    JH> Success in this area will require everyone's participation,
    JH> even if it's just evaluating what others have done or said and
    JH> expressing your opinions on this list.  All we're asking for
    JH> at this point is for you to read the RFC, make some comments
    JH> in email, and help populate some wiki pages with links and
    JH> concerns.  If you're willing to do real work later, we're also
    JH> asking for you to sign up in the area you can work in.

General comments: The ideas sounded very good and quite comprehensive
and I really did not have much to say.  The only problem was how do we
get people involved.  Unfortunately, I have no good solutions for
that.  All the people I know already spend quite a bit of their spare
time writing the various pieces of software.

As regards links to useful software, I sent in a bunch of links to
Fernando after the conference.  I'm not sure what happened.

Why not have a catch all links page with all the links locally sorted
into simple categories.  Its easier to do it that way rather than
manage the links from different places.  What do you think?

cheers,
prabhu



From Fernando.Perez at colorado.edu  Thu Oct 28 13:50:14 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Thu, 28 Oct 2004 11:50:14 -0600
Subject: [SciPy-dev] ASP: comments on the web site
In-Reply-To: <16769.11697.203071.494751@monster.linux.in>
References: <200410281412.i9SECMDe006344@oobleck.astro.cornell.edu>
	<16769.11697.203071.494751@monster.linux.in>
Message-ID: <41813156.6010704@colorado.edu>

Prabhu Ramachandran wrote:

> As regards links to useful software, I sent in a bunch of links to
> Fernando after the conference.  I'm not sure what happened.

Coming... I am putting the page together with summaries of projects, but I've 
been away for 2 weeks at conferences, with nearly zero time to work on this 
(and a stupid hotel room without internet access, so I can't work on it in the 
evenings).  I'll be back home next week, and I'll get this out of the way. 
Sorry for the delay.

f



From swisher at enthought.com  Thu Oct 28 16:01:05 2004
From: swisher at enthought.com (Janet Swisher)
Date: Thu, 28 Oct 2004 15:01:05 -0500
Subject: [SciPy-dev] ASP: comments on the web site
In-Reply-To: <200410281412.i9SECMDe006344@oobleck.astro.cornell.edu>
Message-ID: <004b01c4bd28$dbf53c00$9c01a8c0@SWISHER>

I've figured out how to disable automatic linking of names in CamelCaps
(such as SciPy and AstroPy). This was creating extraneous "?"s after such
names, which Russell and others found annoying.

The wikis still support the following forms of linking:

* Free-form page names in single brackets [foo] or double brackets [[foo]]
* Bare URLs
* HTML links, on HTML or Structured Text pages
* Structured Text links ("link text":URL) on ST pages
* ReStructured Text links on RST pages (see
http://docutils.sourceforge.net/docs/user/rst/quickref.html#hyperlink-target
s for details)

--Janet

> -----Original Message-----
> From: scipy-dev-bounces at scipy.net 
> [mailto:scipy-dev-bounces at scipy.net] On Behalf Of Joe Harrington
> Sent: Thursday, October 28, 2004 9:12 AM
> To: scipy-dev at scipy.org
> Cc: jh at oobleck.astro.cornell.edu
> Subject: [SciPy-dev] ASP: comments on the web site
> 
> 
> Things have been quiet since we posted the ASP RFC, at least 
> on the concerns it raised.  It really is a request for your 
> comments, and not just a private plan of Perry's and mine.  
> Success in this area will require everyone's participation, 
> even if it's just evaluating what others have done or said 
> and expressing your opinions on this list. All we're asking 
> for at this point is for you to read the RFC, make some 
> comments in email, and help populate some wiki pages with 
> links and concerns.  If you're willing to do real work later, 
> we're also asking for you to sign up in the area you can work in.
> 
> So far only one discipline (astronomy) has posted a page of 
> links on the "Topical Software" wiki.  Subsequent to posting 
> his page, Russell Owen offered a critique of the web site, 
> which we identified in the ASP RFC as needing a makeover.  
> He's not on this list but hee allowed me to post his comments 
> here.  Please chime in and respond with your own ideas of how 
> to make the web site better, both to serve your needs and to 
> serve those of potential new users.
> 
> Finally, would someone from biology and from graphics please 
> step up to maintain similar pages for those areas?  We need 
> someone from
> *every* field, but I know there's lots of good application 
> software in both those areas.  Maintaining a wiki or a 
> regular page takes only a small amount of time, an hour a 
> month or less once the page is up, but it's a crucial step in 
> attracting a broader user base.
> 
> Thanks!
> 
> --jh--
> 
> ------- Start of forwarded message -------
> In-Reply-To: <006301c4bba0$8c284f70$9c01a8c0 at SWISHER>
> Date: Wed, 27 Oct 2004 14:48:16 -0700
> To: "Janet Swisher" <swisher at enthought.com>,
>         "'Russell E Owen'" <rowen at u.washington.edu>
> From: Russell E Owen <rowen at u.washington.edu>
> Subject: RE: Help with SciPy.org Wikis
> Cc: <joneric at enthought.com>, <jh at oobleck.astro.cornell.edu>
> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 
> 	oobleck.astro.cornell.edu
> X-Spam-Level: 
> X-Spam-Status: No, hits=-4.9 required=3.9 tests=BAYES_00 
> autolearn=ham 
> 	version=2.63
> 
> At 4:12 PM -0500 2004-10-26, Janet Swisher wrote:
> >>  On the edit tab for a wiki page, a set of options near 
> the bottom  
> >> determines which format the wiki uses to interpret the 
> page. If you  
> >> edit an existing page, notice which format it is in.  "
> >>
> >>  So..."notice which format it is in". Sounds good, but HOW?
> >
> >What I had in mind is that, when you edit a page, you can 
> note which of 
> >the format radio buttons is selected. I guess I need to make 
> that more 
> >explicit.
> >
> >>  Better yet, how to change it?
> >
> >You can change the selected radio button, but that does not 
> change the 
> >contents of the page. If you want to change a page, for 
> example, from 
> >ST to RST, you would have to make the formatting changes 
> manually. ...
> >When you click the Edit tab, the contents of the page are 
> full of HTML tags,
> >and the HTML radio button is selected.
> 
> OK, I tried with Safari as well and I see no radio buttons, so I 
> think they really and truly are missing (or I am being spectacularly 
> blind).
> 
> I suspect one needs more god-like privileges than I have to see them, 
> perhaps because if a user can see them, a user can toggle them. (If 
> so, not allowing just anybody to change how a page is parsed is 
> certainly reasonable).
> 
> In any case, this is a problem because every editor should be able to 
> clearly see what format a page is in.
> 
> >>  Request:
> >>  - Permanent links to "Topical Software" and "Help with SciPy.org  
> >> Wikis" would be a big win. Right now they are only visible 
> because  
> >> they are new enough to appear in "recent items".
> >
> >"Topical Software" is permanently listed in the navigation 
> tree under 
> >"Wikis". The user does have to know to click "Wikis" to see 
> it. "Help 
> >with SciPy.org Wikis" is now linked from the root page of the Wikis 
> >folder and from the root page of the published wikis (except the one 
> >for the SciPy 2004 Conference, which is now mainly historical).
> >
> >Do you have suggestions about where else these items could be linked 
> >that would be more visible?
> 
> Since you ask, here are my impressions and suggestions.
> 
> First the impressions:
> - - From the SciPy home page, there is no clue that this site has any 
> general "science with Python" information. It just seems to be a site 
> about the SciPy software project.
> - - One has to first go to "Other Wikis" and then look way 
> down through 
> a page that is mostly about SciPy to find "Topical Software".
> - - "Topical Software" is not evocative.
> - - Burying it so deeply and not mentioning it on the home page give 
> the impression that it is very much an afterthoght and not integrated 
> into the site.
> 
> Suggestions:
> - - Rename "Topcial Software" to something like "Python Tools 
> for Science".
> - - Explicitly mention "Python Tools for Science" in the text on the 
> home page. Try to briefly explain that it exists and perhaps WHY it 
> exists. Just a sentence or two should do it. *Talking* about it and 
> not just
> 
> Further cleanups to consider:
> - - Consolidate some of the items in Navigation.
> - - Get rid of "Wikis" and those pages to other, more 
> obvious, sub-headings.
> - - SciPy should be a recognized link on every scipy wiki (to 
> the SciPy 
> home page).
> 
> The navigation bar might look like this (with changes noted 
> under each topic):
> 
> Navigation:
> About SciPy
> - - no change (except as mentioned for the body text above)
> Documentation:
> - - includes "Wikis" links: "Troubleshooting", "SciPy User's Guide 
> Wiki" and "Help with SciPy.org Wikis"
>    this is touchy and may not fully work because I realize you have 
> non-wiki versions of the docs as well,
>    but I have seen success with offering users both versions 
> side-by-side (let them choose
>    if they want docs cluttered up with user comments or not)
> Development:
> - - include CVS and get rid of the CVS link (i.e. bury the 
> CVS page one 
> level deeper)
> Bug Tracker:
> - - include the standard navigation panel that we are 
> discussing Mailing Lists
> - - no change
> Science with Python
> - - This is the "Topical Software" page, renamed and brought 
> up one level
> 
> Anyway, there are my 2 bits, such as they are. Best of luck with the 
> site and the project.
> 
> - -- Russell
> 
> P.S. Regarding the gaps I was seeing before every link; it turned out 
> that enabling background images displayed the icons. If those really 
> are background images I am truly amazed, but however it's being done 
> seems to work (except for leaving gaps when one doesn't want to see 
> images).
> ------- End of forwarded message -------
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net http://www.scipy.net/mailman/listinfo/scipy-dev
> 



From charles.harris at sdl.usu.edu  Fri Oct 29 12:12:45 2004
From: charles.harris at sdl.usu.edu (Charles Harris)
Date: Fri, 29 Oct 2004 10:12:45 -0600
Subject: [SciPy-dev] Testing for powers of two
Message-ID: <F3B41B92D722CE4D9F5AB205DCD498B8794975@cobra.usurf.usu.edu>

There was a discussion some time ago about testing for powers of two.
The other day I saw a nifty version go by on the LKML, courtesy of
Linus. Namely:

is_power_of_two = x && !(x & (x - 1))

which works for all numbers except possibly the number x8000, which if
twos complement will probably give an underflow on subtraction of 1. So
for signed numbers:

is_power_of_two = x > 0 && !(x & (x - 1))

Chuck



From pearu at scipy.org  Sun Oct 31 05:05:31 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Sun, 31 Oct 2004 04:05:31 -0600 (CST)
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu>
Message-ID: <Pine.LNX.4.61.0410310308450.31648@scipy.org>



On Mon, 18 Oct 2004, Joe Harrington wrote:

> DOCUMENTATION
>
<snip>

> It was noted at the BoF that Enthought has substantial documentation
> in its Windows package in .chm format, and that there is now an X
> reader for these files.  Those documents will be broken out for
> non-Windows users and may form the bases for one or more of the
> documents above, assuming cooperation from Enthought on permissions
> and copyrights.
>
> Translations are always a good idea, but can only be obtained in a
> community project through the work of competent volunteers.  The
> quality of our documentation will be vastly improved by user testing
> and comment, and by the participation of more than one person in the
> creation of each document.  However, content determines form, so we
> should not be shy about making first drafts available, provided that
> we continue to work on them.
>
> We will need to agree on a set of standards for writing documents.
> Certainly all docs should be available in PDF and HTML, and the source
> should be modifiable by anyone on any platform.  The Windows .chm
> format may also be a viable target if good tools exist to do it under
> Linux and Mac as well as Windows.  The source form must be viable in
> the long term and must not leave us in a bind if the text-processing
> software ceases to be supported.  Structured Text and LaTeX have been
> suggested.  MSWord and other proprietary forms are out.  The major
> need for formulae in scientific documentation may push us to LaTeX,
> perhaps with a standardized format, but this is open for discussion.

I agree that MSWord is out, even OpenOffice or StarOffice would be out 
for me.

Python documentation project is moving from using LaTeX to ReST (note 
that ReST is different form ST). ReST has LaTeX capabilities but only for 
its LaTeX output. But in principle we can generate any desired format 
from LaTeX.

Personally, I would prefer ReST (as the future standard documentation 
tool in Python) or LaTeX (as a very powerful documentation tool in 
general both in past and future). I have put ReST before LaTeX (in other 
cases it would be reversed) because ReST could be used in documentation 
strings as well.

I could use Lyx but I consider it as WYSIWYG-LaTeX which does not impress 
me much when using Auctex Emacs mode in working with LaTeX documents.

As I have understood from earlier discussions that LaTeX may scare people 
away from writing documentation for Scipy. But let me ask may be a bit 
harsh question: are these people able to produce good quality technical 
documentation for Scipy if they reject to learn LaTeX basics? Afterall, 
LaTeX is not that difficult to use, especially when we can provide 
documentation templates to get started easy, and there are nice LaTeX 
frontends available for Windows as well.

> PRIORITIES
>
> The three areas for improvement can proceed in parallel.  Since
> packaging issues affect the documentation, those should be resolved
> as soon as possible.
>
> For packaging, we need to:
>
> 1. determine whether the idea of replacing xplt and gplt with
> matplotlib in the docs is acceptable to the community,

Fine with me (as I am not currently using any of these tools yet).

> 2. determine whether IPython should go into the core,

I am using it on dayly basis, so +1 from me.

> 3. determine whether the "coexistence" approach for resolving the
> numeric/Numarray split is a good idea.

First, we need to get Numarray support to Scipy and then we can make 
decicions on the above.

> Then, we need to roll and field-test the binary packages.  The latter
> effort will require volunteers, so if you want your package or
> platform to be supported, please sign up.
>
> For documentation, we need to agree on a common source format, an open
> copyright, and some stylistic guidelines.  Documents are needed in
> roughly the order listed above, though if someone is very inspired to
> start on a later one, he or she should proceed.  Suggestions for
> additional documents are welcome, as are volunteers to write them.
>
> Goals for the web site are less clear than for packaging and
> documentation.  Some mailing list brainstorming on content and format
> issues would be a good idea, starting with those above.  Then, we need
> to identify page maintainers and get them access.  Several individuals
> stepped forward at the BoF, and a web human interface designer has
> volunteered to help.  Again, more volunteers are needed.

This is good that people offered help at the BoF, but not enough to get 
real work done. I think now we should take the next step and ask specific 
help in person.

Regards,
Pearu



From rkern at ucsd.edu  Sun Oct 31 18:44:28 2004
From: rkern at ucsd.edu (Robert Kern)
Date: Sun, 31 Oct 2004 15:44:28 -0800
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <Pine.LNX.4.61.0410310308450.31648@scipy.org>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu>
	<Pine.LNX.4.61.0410310308450.31648@scipy.org>
Message-ID: <418578DC.9090304@ucsd.edu>

Pearu Peterson wrote:

>> 2. determine whether IPython should go into the core,
> 
> I am using it on dayly basis, so +1 from me.

How exactly is this supposed to work? An IPython package under scipy_core?

If so, what is the benefit? The only one that I can see is that when you 
install scipy_core, you also install IPython. I don't see this being 
much more useful than putting the IPython download link right next to 
scipy's on the download page.

IPython seems to be orthogonal to scipy. I'd be -1 on making IPython 
depend on scipy or scipy_core. IPython's potential audience is much 
wider than scipy's. Looking the other way, I don't think scipy would 
benefit much from having IPython as part of it. Perhaps when IPython 
gets rewritten to be a more flexible library for building interactive 
environments, then it would make some sense to bundle IPython into scipy.

But for now, I'm -1.

-- 
Robert Kern
rkern at ucsd.edu

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



From eric at enthought.com  Sun Oct 31 22:56:13 2004
From: eric at enthought.com (eric jones)
Date: Sun, 31 Oct 2004 21:56:13 -0600
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <Pine.LNX.4.61.0410310308450.31648@scipy.org>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu>
	<Pine.LNX.4.61.0410310308450.31648@scipy.org>
Message-ID: <4185B3DD.1010907@enthought.com>

Pearu Peterson wrote:

>
>
> On Mon, 18 Oct 2004, Joe Harrington wrote:
>
>> DOCUMENTATION
>>
> <snip>
>
>> It was noted at the BoF that Enthought has substantial documentation
>> in its Windows package in .chm format, and that there is now an X
>> reader for these files.  Those documents will be broken out for
>> non-Windows users and may form the bases for one or more of the
>> documents above, assuming cooperation from Enthought on permissions
>> and copyrights.
>>
>> Translations are always a good idea, but can only be obtained in a
>> community project through the work of competent volunteers.  The
>> quality of our documentation will be vastly improved by user testing
>> and comment, and by the participation of more than one person in the
>> creation of each document.  However, content determines form, so we
>> should not be shy about making first drafts available, provided that
>> we continue to work on them.
>>
>> We will need to agree on a set of standards for writing documents.
>> Certainly all docs should be available in PDF and HTML, and the source
>> should be modifiable by anyone on any platform.  The Windows .chm
>> format may also be a viable target if good tools exist to do it under
>> Linux and Mac as well as Windows.  The source form must be viable in
>> the long term and must not leave us in a bind if the text-processing
>> software ceases to be supported.  Structured Text and LaTeX have been
>> suggested.  MSWord and other proprietary forms are out.  The major
>> need for formulae in scientific documentation may push us to LaTeX,
>> perhaps with a standardized format, but this is open for discussion.
>
>
> I agree that MSWord is out, even OpenOffice or StarOffice would be out 
> for me.
>
> Python documentation project is moving from using LaTeX to ReST (note 
> that ReST is different form ST). ReST has LaTeX capabilities but only 
> for its LaTeX output. But in principle we can generate any desired 
> format from LaTeX.
>
> Personally, I would prefer ReST (as the future standard documentation 
> tool in Python) or LaTeX (as a very powerful documentation tool in 
> general both in past and future). I have put ReST before LaTeX (in 
> other cases it would be reversed) because ReST could be used in 
> documentation strings as well.
>
> I could use Lyx but I consider it as WYSIWYG-LaTeX which does not 
> impress me much when using Auctex Emacs mode in working with LaTeX 
> documents.
>
> As I have understood from earlier discussions that LaTeX may scare 
> people away from writing documentation for Scipy. But let me ask may 
> be a bit harsh question: are these people able to produce good quality 
> technical documentation for Scipy if they reject to learn LaTeX 
> basics? Afterall, LaTeX is not that difficult to use, especially when 
> we can provide documentation templates to get started easy, and there 
> are nice LaTeX frontends available for Windows as well.

Of the two options, ReST is much more preferable to me.  I, and many 
others, use Word as my primary documenting tool and dislike LaTeX very 
much.  Of the open options, I (and many others) would be most 
comfortable in OpenOffice.  However, I also think that ReST has many 
benefits (better diffs in a code repository, editable in any editor, 
etc.) that are compelling.  Imposing the LaTeX learning curve and 
infrastructure requirements on would-be contributors is too limiting in 
my opinion.  So, of the imperfect solutions, ReST seems the most 
palatable to the most people.

eric



From aisaac at american.edu  Sun Oct 31 23:59:43 2004
From: aisaac at american.edu (Alan G Isaac)
Date: Sun, 31 Oct 2004 23:59:43 -0500 (Eastern Standard Time)
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <Pine.LNX.4.61.0410310308450.31648@scipy.org>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu><Pine.LNX.4.61.0410310308450.31648@scipy.org>
Message-ID: <Mahogany-0.66.0-1548-20041101-014251.00@american.edu>

On Sun, 31 Oct 2004, Pearu Peterson apparently wrote:
>  ReST has LaTeX capabilities but only for its LaTeX output.

Could you please point to (or provide) a detailed sample use?
I did not realize things had gotten beyond an agreement on
desirability:
 http://docutils.sourceforge.net/docs/dev/todo.html#math-markup

Thanks,
Alan Isaac