From cimrman3 at ntc.zcu.cz  Fri Feb  1 05:48:49 2008
From: cimrman3 at ntc.zcu.cz (Robert Cimrman)
Date: Fri, 01 Feb 2008 11:48:49 +0100
Subject: [SciPy-dev] scipy.splinalg or bust
In-Reply-To: <d05265cb0801310929q3fd1a67aoa76bf9fae58470dc@mail.gmail.com>
References: <d05265cb0801251230p1228b608w6618198f16468be8@mail.gmail.com>	<479DAFB2.8070200@ntc.zcu.cz>	<d05265cb0801301906o1f3cb72fl1cc518efa628f5e1@mail.gmail.com>	<47A1E796.5040607@ntc.zcu.cz>
	<d05265cb0801310929q3fd1a67aoa76bf9fae58470dc@mail.gmail.com>
Message-ID: <47A2F911.3010003@ntc.zcu.cz>

Nathan Bell wrote:
> On Jan 31, 2008 9:21 AM, Robert Cimrman <cimrman3 at ntc.zcu.cz> wrote:
>> Great! what about allowing the LinearOperator.__init__() to take care of
>> the cases that aslinearoperator() takes care of? Or
>> LinearOperator.fromany()/fromAny() static/class method?
> 
> I considered that approach but decided against it.  I like keeping
> LinearOperator dead simple since it's what end users will have to
> understand if they want to hook up their matrix-like objects to scipy
> solvers.  Currently aslinearoperator() is the part that "knows" about
> scipy/numpy while LinearOperator is just an abstract interface.
> 
> Another practical issue is that LinearOperator needs to be initialized
> with at least two arguments (shape and matvec) while
> aslinearoperator() only accepts one.  The classmethod approach avoids
> this, but I have a (possibly irrational) dislike for classmethods :)
> 
> Scipy users should understand asarray(), so I think aslinearoperator()
> is a fairly natural extension.

Ok, I have nothing against :)

r.


From nwagner at iam.uni-stuttgart.de  Fri Feb  1 13:46:58 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Fri, 01 Feb 2008 19:46:58 +0100
Subject: [SciPy-dev] Status of minres
Message-ID: <web-95716303@uni-stuttgart.de>

Hi Nathan,

I just tried to run minres.

from scipy.splinalg.isolve import minres

y = minres.minres(A,b)

Traceback (most recent call last):
   File "test_minres.py", line 9, in ?
     y = minres.minres(A,b)
   File 
"/usr/lib/python2.4/site-packages/scipy/splinalg/isolve/minres.py", 
line 43, in minres
     b = asarray(b).ravel()
NameError: global name 'asarray' is not defined

Nils



From nwagner at iam.uni-stuttgart.de  Fri Feb  1 14:40:12 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Fri, 01 Feb 2008 20:40:12 +0100
Subject: [SciPy-dev] Status of minres
In-Reply-To: <web-95716303@uni-stuttgart.de>
References: <web-95716303@uni-stuttgart.de>
Message-ID: <web-95717963@uni-stuttgart.de>

On Fri, 01 Feb 2008 19:46:58 +0100
  "Nils Wagner" <nwagner at iam.uni-stuttgart.de> wrote:
> Hi Nathan,
> 
> I just tried to run minres.
> 
> from scipy.splinalg.isolve import minres
> 
> y = minres.minres(A,b)
> 
> Traceback (most recent call last):
>   File "test_minres.py", line 9, in ?
>     y = minres.minres(A,b)
>   File 
> "/usr/lib/python2.4/site-packages/scipy/splinalg/isolve/minres.py", 
> line 43, in minres
>     b = asarray(b).ravel()
> NameError: global name 'asarray' is not defined
> 
> Nils
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev


Please find attached a patch for minres.py

Nils
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minres.py.patch
Type: text/x-patch
Size: 102 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080201/667385c0/attachment.bin>

From wnbell at gmail.com  Fri Feb  1 14:54:11 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Fri, 1 Feb 2008 13:54:11 -0600
Subject: [SciPy-dev] Status of minres
In-Reply-To: <web-95717963@uni-stuttgart.de>
References: <web-95716303@uni-stuttgart.de> <web-95717963@uni-stuttgart.de>
Message-ID: <d05265cb0802011154re362823u49c8a963f5279c02@mail.gmail.com>

On Feb 1, 2008 1:40 PM, Nils Wagner <nwagner at iam.uni-stuttgart.de> wrote:
> Please find attached a patch for minres.py

Merged.

You're welcome to test the code, but it's not completely finished yet.
 It should work for sparse matrices, but preconditioning is not yet
implemented and the tol parameter is currently handled differently
than other iterative solvers.


-- 
Nathan Bell wnbell at gmail.com
http://graphics.cs.uiuc.edu/~wnbell/


From nwagner at iam.uni-stuttgart.de  Fri Feb  1 15:06:32 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Fri, 01 Feb 2008 21:06:32 +0100
Subject: [SciPy-dev] Status of minres
In-Reply-To: <d05265cb0802011154re362823u49c8a963f5279c02@mail.gmail.com>
References: <web-95716303@uni-stuttgart.de> <web-95717963@uni-stuttgart.de>
	<d05265cb0802011154re362823u49c8a963f5279c02@mail.gmail.com>
Message-ID: <web-95718731@uni-stuttgart.de>

On Fri, 1 Feb 2008 13:54:11 -0600
  "Nathan Bell" <wnbell at gmail.com> wrote:
> On Feb 1, 2008 1:40 PM, Nils Wagner 
><nwagner at iam.uni-stuttgart.de> wrote:
>> Please find attached a patch for minres.py
> 
> Merged.
> 
> You're welcome to test the code, but it's not completely 
>finished yet.
> It should work for sparse matrices, but preconditioning 
>is not yet
> implemented and the tol parameter is currently handled 
>differently
> than other iterative solvers.
> 
  
Thank you very much for your prompt reply !
Is it planned to add support for dense matrices ?
AFAIK, gmres, cg, bicg, etc. can handle dense matrices.

Cheers,

             Nils
  


From wnbell at gmail.com  Fri Feb  1 15:11:22 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Fri, 1 Feb 2008 14:11:22 -0600
Subject: [SciPy-dev] Status of minres
In-Reply-To: <web-95718731@uni-stuttgart.de>
References: <web-95716303@uni-stuttgart.de> <web-95717963@uni-stuttgart.de>
	<d05265cb0802011154re362823u49c8a963f5279c02@mail.gmail.com>
	<web-95718731@uni-stuttgart.de>
Message-ID: <d05265cb0802011211l3a58b722m240be8c7bdd80165@mail.gmail.com>

On Feb 1, 2008 2:06 PM, Nils Wagner <nwagner at iam.uni-stuttgart.de> wrote:

> Is it planned to add support for dense matrices ?
> AFAIK, gmres, cg, bicg, etc. can handle dense matrices.

Yep, we created LinearOperator/aslinearoperator() to simplify this part.

-- 
Nathan Bell wnbell at gmail.com
http://graphics.cs.uiuc.edu/~wnbell/


From nwagner at iam.uni-stuttgart.de  Fri Feb  1 15:47:42 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Fri, 01 Feb 2008 21:47:42 +0100
Subject: [SciPy-dev] Status of minres
In-Reply-To: <d05265cb0802011211l3a58b722m240be8c7bdd80165@mail.gmail.com>
References: <web-95716303@uni-stuttgart.de> <web-95717963@uni-stuttgart.de>
	<d05265cb0802011154re362823u49c8a963f5279c02@mail.gmail.com>
	<web-95718731@uni-stuttgart.de>
	<d05265cb0802011211l3a58b722m240be8c7bdd80165@mail.gmail.com>
Message-ID: <web-95719901@uni-stuttgart.de>

On Fri, 1 Feb 2008 14:11:22 -0600
  "Nathan Bell" <wnbell at gmail.com> wrote:
> On Feb 1, 2008 2:06 PM, Nils Wagner 
><nwagner at iam.uni-stuttgart.de> wrote:
> 
>> Is it planned to add support for dense matrices ?
>> AFAIK, gmres, cg, bicg, etc. can handle dense matrices.
> 
> Yep, we created LinearOperator/aslinearoperator() to 
>simplify this part.
> 
  
Please can you provide a small example illustrating the 
new functionality ?

Thank you in advance.

  Nils


From nwagner at iam.uni-stuttgart.de  Sat Feb  2 11:54:26 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Sat, 02 Feb 2008 17:54:26 +0100
Subject: [SciPy-dev] openopt example  mmp_1.py
Message-ID: <web-95749909@uni-stuttgart.de>

Hi Dmitrey,

the example mmp_1.py is broken.

/usr/bin/python 
svn/openopt/scikits/openopt/examples/mmp_1.py
starting solver nsmm (license: BSD)  with problem  unnamed
incorrect func index type!
Traceback (most recent call last):
   File "svn/openopt/scikits/openopt/examples/mmp_1.py", 
line 22, in ?
     r = p.solve('nsmm')
   File 
"/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/BaseProblem.py", 
line 207, in solve
     return runProbSolver(self, solvers, *args, **kwargs)
   File 
"/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/runProbSolver.py", 
line 156, in runProbSolver
     solver(p)
   File 
"/usr/lib/python2.4/site-packages/scikits/openopt/solvers/UkrOpt/nsmm.py", 
line 54, in __solver__
     r2 = p2.solve('ralg')
   File 
"/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/BaseProblem.py", 
line 207, in solve
     return runProbSolver(self, solvers, *args, **kwargs)
   File 
"/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/runProbSolver.py", 
line 156, in runProbSolver
     solver(p)
   File 
"/usr/lib/python2.4/site-packages/scikits/openopt/solvers/UkrOpt/ralg.py", 
line 62, in __solver__
     g,  fname,  ind = self.getRalgDirection(x, p)
   File 
"/usr/lib/python2.4/site-packages/scikits/openopt/solvers/UkrOpt/ralg.py", 
line 230, in getRalgDirection
     d = p.df(x)
   File 
"/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/objFunRelated.py", 
line 138, in user_df
     df = user_df_func(*(x,) + p.args.f)
   File 
"/usr/lib/python2.4/site-packages/scikits/openopt/solvers/UkrOpt/nsmm.py", 
line 31, in df
     return p.df(x, ind)
   File 
"/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/objFunRelated.py", 
line 105, in user_df
     if IND is not None: ind = p.getCorrectInd(IND)
   File 
"/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/objFunRelated.py", 
line 358, in getCorrectInd
     p.err('incorrect func index type!')
   File 
"/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/oologfcn.py", 
line 12, in ooerr
     raise OpenOptException(msg)
oologfcn.OpenOptException: <oologfcn.OpenOptException 
instance at 0x42cc0bcc>

Cheers

             Nils


From wnbell at gmail.com  Sat Feb  2 13:20:21 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Sat, 2 Feb 2008 12:20:21 -0600
Subject: [SciPy-dev] Status of minres
In-Reply-To: <web-95719901@uni-stuttgart.de>
References: <web-95716303@uni-stuttgart.de> <web-95717963@uni-stuttgart.de>
	<d05265cb0802011154re362823u49c8a963f5279c02@mail.gmail.com>
	<web-95718731@uni-stuttgart.de>
	<d05265cb0802011211l3a58b722m240be8c7bdd80165@mail.gmail.com>
	<web-95719901@uni-stuttgart.de>
Message-ID: <d05265cb0802021020j45ead2f3y5086688ccd30654b@mail.gmail.com>

On Feb 1, 2008 2:47 PM, Nils Wagner <nwagner at iam.uni-stuttgart.de> wrote:
>
> Please can you provide a small example illustrating the
> new functionality ?
>

I've updated the docstrings:
http://projects.scipy.org/scipy/scipy/browser/trunk/scipy/splinalg/interface.py

-- 
Nathan Bell wnbell at gmail.com
http://graphics.cs.uiuc.edu/~wnbell/


From nwagner at iam.uni-stuttgart.de  Sat Feb  2 13:41:22 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Sat, 02 Feb 2008 19:41:22 +0100
Subject: [SciPy-dev] Status of minres
In-Reply-To: <d05265cb0802021020j45ead2f3y5086688ccd30654b@mail.gmail.com>
References: <web-95716303@uni-stuttgart.de> <web-95717963@uni-stuttgart.de>
	<d05265cb0802011154re362823u49c8a963f5279c02@mail.gmail.com>
	<web-95718731@uni-stuttgart.de>
	<d05265cb0802011211l3a58b722m240be8c7bdd80165@mail.gmail.com>
	<web-95719901@uni-stuttgart.de>
	<d05265cb0802021020j45ead2f3y5086688ccd30654b@mail.gmail.com>
Message-ID: <web-95752350@uni-stuttgart.de>

On Sat, 2 Feb 2008 12:20:21 -0600
  "Nathan Bell" <wnbell at gmail.com> wrote:
> On Feb 1, 2008 2:47 PM, Nils Wagner 
><nwagner at iam.uni-stuttgart.de> wrote:
>>
>> Please can you provide a small example illustrating the
>> new functionality ?
>>
> 
> I've updated the docstrings:
> http://projects.scipy.org/scipy/scipy/browser/trunk/scipy/splinalg/interface.py
> 
  
Great ! Thank you very much !
Can you also add an example for using a preconditioner ?

Cheers,

          Nils

  


From wnbell at gmail.com  Sat Feb  2 14:07:48 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Sat, 2 Feb 2008 13:07:48 -0600
Subject: [SciPy-dev] status of splinalg
Message-ID: <d05265cb0802021107y4ab1bb6ds32847ab24994b809@mail.gmail.com>

For those keeping score, here's the current status of scipy.splinalg.


Completed tasks:

     (1) linalg.iterative -> splinalg.isolve
          http://projects.scipy.org/scipy/scipy/changeset/3861

          For backwards compatibility scipy.linalg imports all the
          iterative solvers from  splinalg.isolve .  This is needed to
          avoid breaking things like  'from scipy.linalg import cg'
          These functions are wrapped with deprecation warnings.

          The new iterative solvers have an argument M for an optional
          preconditioner.  The old A.psolve() method is still supported.

      (4) scipy.linsolve -> splinalg.dsolve
            http://projects.scipy.org/scipy/scipy/changeset/3862

            Importing from scipy.linsolve generates a warning

      (6) create LinearOperator wrapper class and document it
            http://projects.scipy.org/scipy/scipy/changeset/3890

            Iterative solvers now use aslinearoperator() to handle
            matrix-like input arguments.  I will update the iterative
            solver docstrings to reflect the change.


Remaining tasks with owners:

      (1) sandbox.lobpcg -> splinalg.eigen.lobpcg
      (2) sandbox.arpack -> splinalg.eigen.arpack
      (3) create splinalg.eigen.speigs
      (5) scipy.linsolve.umfpack -> scikit

Remaining tasks:

      (7) document splinalg.dsolve
      (8) document splinalg.isolve
      (9) document splinalg.eigen


-- 
Nathan Bell wnbell at gmail.com
http://graphics.cs.uiuc.edu/~wnbell/


From dmitrey.kroshko at scipy.org  Sat Feb  2 17:21:45 2008
From: dmitrey.kroshko at scipy.org (dmitrey)
Date: Sun, 03 Feb 2008 00:21:45 +0200
Subject: [SciPy-dev] openopt example  mmp_1.py
In-Reply-To: <web-95749909@uni-stuttgart.de>
References: <web-95749909@uni-stuttgart.de>
Message-ID: <47A4ECF9.2090309@scipy.org>

I don't know what's the matter, everything works well for me, including 
latest revision checked out from svn into separate dir & python setup.py 
install + python mmp_1.py.

Could anyone else check the example?

Nils, could you add line "print type(ind)" before objFunRelated.py line 
358, run "python setup.py install" and run "python mmp_1.py"? Maybe it 
will help to fix the bug.
However, I guess it could be solved via simple cleanup and checkout OO 
from svn repository.

Regards, D.

------------------------------
starting solver nsmm (license: BSD)  with problem  unnamed
Niter   F
    0       6.47e+03
   42       1.45e+03
nsmm has finished solving the problem unnamed
istop:  4 (|| F[k] - F[k-1] || < ftol)
Solver:   Time Elapsed = 0.24   CPU Time Elapsed = 0.25
Plotting: Time Elapsed = 1.01   CPU Time Elapsed = 0.86
objFunValue: 1449.79080254 (feasible, max constraint =  0)
MMP result: 1449.79080254
------------------------------


Nils Wagner wrote:
> Hi Dmitrey,
>
> the example mmp_1.py is broken.
>
> /usr/bin/python 
> svn/openopt/scikits/openopt/examples/mmp_1.py
> starting solver nsmm (license: BSD)  with problem  unnamed
> incorrect func index type!
> Traceback (most recent call last):
>    File "svn/openopt/scikits/openopt/examples/mmp_1.py", 
> line 22, in ?
>      r = p.solve('nsmm')
>    File 
> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/BaseProblem.py", 
> line 207, in solve
>      return runProbSolver(self, solvers, *args, **kwargs)
>    File 
> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/runProbSolver.py", 
> line 156, in runProbSolver
>      solver(p)
>    File 
> "/usr/lib/python2.4/site-packages/scikits/openopt/solvers/UkrOpt/nsmm.py", 
> line 54, in __solver__
>      r2 = p2.solve('ralg')
>    File 
> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/BaseProblem.py", 
> line 207, in solve
>      return runProbSolver(self, solvers, *args, **kwargs)
>    File 
> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/runProbSolver.py", 
> line 156, in runProbSolver
>      solver(p)
>    File 
> "/usr/lib/python2.4/site-packages/scikits/openopt/solvers/UkrOpt/ralg.py", 
> line 62, in __solver__
>      g,  fname,  ind = self.getRalgDirection(x, p)
>    File 
> "/usr/lib/python2.4/site-packages/scikits/openopt/solvers/UkrOpt/ralg.py", 
> line 230, in getRalgDirection
>      d = p.df(x)
>    File 
> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/objFunRelated.py", 
> line 138, in user_df
>      df = user_df_func(*(x,) + p.args.f)
>    File 
> "/usr/lib/python2.4/site-packages/scikits/openopt/solvers/UkrOpt/nsmm.py", 
> line 31, in df
>      return p.df(x, ind)
>    File 
> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/objFunRelated.py", 
> line 105, in user_df
>      if IND is not None: ind = p.getCorrectInd(IND)
>    File 
> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/objFunRelated.py", 
> line 358, in getCorrectInd
>      p.err('incorrect func index type!')
>    File 
> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/oologfcn.py", 
> line 12, in ooerr
>      raise OpenOptException(msg)
> oologfcn.OpenOptException: <oologfcn.OpenOptException 
> instance at 0x42cc0bcc>
>
> Cheers
>
>              Nils
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
>
>
>   



From nwagner at iam.uni-stuttgart.de  Sun Feb  3 03:37:25 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Sun, 03 Feb 2008 09:37:25 +0100
Subject: [SciPy-dev] openopt example  mmp_1.py
In-Reply-To: <47A4ECF9.2090309@scipy.org>
References: <web-95749909@uni-stuttgart.de>
 <47A4ECF9.2090309@scipy.org>
Message-ID: <web-95766984@uni-stuttgart.de>

On Sun, 03 Feb 2008 00:21:45 +0200
  dmitrey <dmitrey.kroshko at scipy.org> wrote:
> I don't know what's the matter, everything works well 
>for me, including 
> latest revision checked out from svn into separate dir & 
>python setup.py 
> install + python mmp_1.py.
> 
> Could anyone else check the example?
> 
> Nils, could you add line "print type(ind)" before 
>objFunRelated.py line 
> 358, run "python setup.py install" and run "python 
>mmp_1.py"? Maybe it 
> will help to fix the bug.
> However, I guess it could be solved via simple cleanup 
>and checkout OO 
> from svn repository.
> 
> Regards, D.
> 
> ------------------------------
> starting solver nsmm (license: BSD)  with problem 
> unnamed
> Niter   F
>    0       6.47e+03
>   42       1.45e+03
> nsmm has finished solving the problem unnamed
> istop:  4 (|| F[k] - F[k-1] || < ftol)
> Solver:   Time Elapsed = 0.24   CPU Time Elapsed = 0.25
> Plotting: Time Elapsed = 1.01   CPU Time Elapsed = 0.86
> objFunValue: 1449.79080254 (feasible, max constraint = 
> 0)
> MMP result: 1449.79080254
> ------------------------------
> 
> 
> Nils Wagner wrote:
>> Hi Dmitrey,
>>
>> the example mmp_1.py is broken.
>>
>> /usr/bin/python 
>> svn/openopt/scikits/openopt/examples/mmp_1.py
>> starting solver nsmm (license: BSD)  with problem 
>> unnamed
>> incorrect func index type!
>> Traceback (most recent call last):
>>    File "svn/openopt/scikits/openopt/examples/mmp_1.py", 
>> line 22, in ?
>>      r = p.solve('nsmm')
>>    File 
>> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/BaseProblem.py", 
>> line 207, in solve
>>      return runProbSolver(self, solvers, *args, 
>>**kwargs)
>>    File 
>> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/runProbSolver.py", 
>> line 156, in runProbSolver
>>      solver(p)
>>    File 
>> "/usr/lib/python2.4/site-packages/scikits/openopt/solvers/UkrOpt/nsmm.py", 
>> line 54, in __solver__
>>      r2 = p2.solve('ralg')
>>    File 
>> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/BaseProblem.py", 
>> line 207, in solve
>>      return runProbSolver(self, solvers, *args, 
>>**kwargs)
>>    File 
>> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/runProbSolver.py", 
>> line 156, in runProbSolver
>>      solver(p)
>>    File 
>> "/usr/lib/python2.4/site-packages/scikits/openopt/solvers/UkrOpt/ralg.py", 
>> line 62, in __solver__
>>      g,  fname,  ind = self.getRalgDirection(x, p)
>>    File 
>> "/usr/lib/python2.4/site-packages/scikits/openopt/solvers/UkrOpt/ralg.py", 
>> line 230, in getRalgDirection
>>      d = p.df(x)
>>    File 
>> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/objFunRelated.py", 
>> line 138, in user_df
>>      df = user_df_func(*(x,) + p.args.f)
>>    File 
>> "/usr/lib/python2.4/site-packages/scikits/openopt/solvers/UkrOpt/nsmm.py", 
>> line 31, in df
>>      return p.df(x, ind)
>>    File 
>> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/objFunRelated.py", 
>> line 105, in user_df
>>      if IND is not None: ind = p.getCorrectInd(IND)
>>    File 
>> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/objFunRelated.py", 
>> line 358, in getCorrectInd
>>      p.err('incorrect func index type!')
>>    File 
>> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/oologfcn.py", 
>> line 12, in ooerr
>>      raise OpenOptException(msg)
>> oologfcn.OpenOptException: <oologfcn.OpenOptException 
>> instance at 0x42cc0bcc>
>>
>> Cheers
>>
>>              Nils
>> _______________________________________________
>> Scipy-dev mailing list
>> Scipy-dev at scipy.org
>> http://projects.scipy.org/mailman/listinfo/scipy-dev
>>
>>
>>
>>   
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev

Hi Dmitrey,

I have installed openopt from scratch. However the problem
persists.
The output of print type(ind) is

<type 'numpy.int32'>

Nils


From dmitrey.kroshko at scipy.org  Sun Feb  3 03:53:02 2008
From: dmitrey.kroshko at scipy.org (dmitrey)
Date: Sun, 03 Feb 2008 10:53:02 +0200
Subject: [SciPy-dev] openopt example  mmp_1.py
In-Reply-To: <web-95766984@uni-stuttgart.de>
References: <web-95749909@uni-stuttgart.de> <47A4ECF9.2090309@scipy.org>
	<web-95766984@uni-stuttgart.de>
Message-ID: <47A580EE.5060902@scipy.org>

Then I guess something have been changed in numpy (I have 1.0.3)
here's full getCorrectInd() code:

from numpy import *
....
def getCorrectInd(p, ind):
    if ind is not None:
        if type(ind) in [int, int32, int64]: return [ind]
        elif type(ind) == ndarray: return atleast_1d(ind).tolist()
        elif type(ind) not in (list, tuple):
            p.err('incorrect func index type!')
        else: return ind
    else: return None   
So I can't understand why line "if type(ind) in [int, int32, int64]"

Maybe ind32 is no longer available in recent numpy?
Could you check

from numpy import *
a = int32(15)

Regardds, D.


> Hi Dmitrey,
>
> I have installed openopt from scratch. However the problem
> persists.
> The output of print type(ind) is
>
> <type 'numpy.int32'>
>
> Nils
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
>
>
>   



From nwagner at iam.uni-stuttgart.de  Sun Feb  3 04:04:57 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Sun, 03 Feb 2008 10:04:57 +0100
Subject: [SciPy-dev] openopt example  mmp_1.py
In-Reply-To: <47A580EE.5060902@scipy.org>
References: <web-95749909@uni-stuttgart.de> <47A4ECF9.2090309@scipy.org>
	<web-95766984@uni-stuttgart.de> <47A580EE.5060902@scipy.org>
Message-ID: <web-95767502@uni-stuttgart.de>

On Sun, 03 Feb 2008 10:53:02 +0200
  dmitrey <dmitrey.kroshko at scipy.org> wrote:
> Then I guess something have been changed in numpy (I 
>have 1.0.3)
> here's full getCorrectInd() code:
> 
> from numpy import *
> ....
> def getCorrectInd(p, ind):
>    if ind is not None:
>        if type(ind) in [int, int32, int64]: return [ind]
>        elif type(ind) == ndarray: return 
>atleast_1d(ind).tolist()
>        elif type(ind) not in (list, tuple):
>            p.err('incorrect func index type!')
>        else: return ind
>    else: return None   
> So I can't understand why line "if type(ind) in [int, 
>int32, int64]"
> 
> Maybe ind32 is no longer available in recent numpy?
> Could you check
> 
> from numpy import *
> a = int32(15)
>

  
>>> from numpy import *
>>> a = int32(15)
>>> a
15
>>> numpy.__version__
'1.0.5.dev4766'
  

Nils


From dmitrey.kroshko at scipy.org  Sun Feb  3 04:39:02 2008
From: dmitrey.kroshko at scipy.org (dmitrey)
Date: Sun, 03 Feb 2008 11:39:02 +0200
Subject: [SciPy-dev] openopt example  mmp_1.py
In-Reply-To: <web-95767502@uni-stuttgart.de>
References: <web-95749909@uni-stuttgart.de>
	<47A4ECF9.2090309@scipy.org>	<web-95766984@uni-stuttgart.de>
	<47A580EE.5060902@scipy.org> <web-95767502@uni-stuttgart.de>
Message-ID: <47A58BB6.1030809@scipy.org>

Nils, I have updated numpy from svn (1.0.5.dev4767) , and all still works ok
Could you check via debugger or somehow else, why the case "numpy.int32" 
is not handled by the line 355 from objFunRelated.py:

"if type(ind) in [int, int32, int64]: return [ind]"
as far as I understand from the stack data you have attached, it goes to 
line 358 instead:
p.err('incorrect func index type!')

And/or, could anyone else update openopt from svn and run 
/examples/mmp_1.py ?

Regards, D.


Nils Wagner wrote:
> On Sun, 03 Feb 2008 10:53:02 +0200
>   dmitrey <dmitrey.kroshko at scipy.org> wrote:
>   
>> Then I guess something have been changed in numpy (I 
>> have 1.0.3)
>> here's full getCorrectInd() code:
>>
>> from numpy import *
>> ....
>> def getCorrectInd(p, ind):
>>    if ind is not None:
>>        if type(ind) in [int, int32, int64]: return [ind]
>>        elif type(ind) == ndarray: return 
>> atleast_1d(ind).tolist()
>>        elif type(ind) not in (list, tuple):
>>            p.err('incorrect func index type!')
>>        else: return ind
>>    else: return None   
>>     
>>>> numpy.__version__
>>>>         
> '1.0.5.dev4766'
>   
>
> Nils
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
>
>
>   



From nwagner at iam.uni-stuttgart.de  Sun Feb  3 05:13:08 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Sun, 03 Feb 2008 11:13:08 +0100
Subject: [SciPy-dev] openopt example  mmp_1.py
In-Reply-To: <47A58BB6.1030809@scipy.org>
References: <web-95749909@uni-stuttgart.de> <47A4ECF9.2090309@scipy.org>
	<web-95766984@uni-stuttgart.de> <47A580EE.5060902@scipy.org>
	<web-95767502@uni-stuttgart.de> <47A58BB6.1030809@scipy.org>
Message-ID: <web-95768800@uni-stuttgart.de>

On Sun, 03 Feb 2008 11:39:02 +0200
  dmitrey <dmitrey.kroshko at scipy.org> wrote:
> Nils, I have updated numpy from svn (1.0.5.dev4767) , 
>and all still works ok
> Could you check via debugger or somehow else, why the 
>case "numpy.int32" 
> is not handled by the line 355 from objFunRelated.py:
> 
> "if type(ind) in [int, int32, int64]: return [ind]"
> as far as I understand from the stack data you have 
>attached, it goes to 
> line 358 instead:
> p.err('incorrect func index type!')
> 
> And/or, could anyone else update openopt from svn and 
>run 
> /examples/mmp_1.py ?
> 
> Regards, .
> 

Hi Dmitrey,

I have no idea. If I run

from numpy import *
a=0
b = int32(15)
print type(a), type(b)

L = [int, int32, int64]

if type(a) in L:

     print 'works for me'

if type(b) in L:

     print 'works for me'

I get
/usr/bin/python test_liste.py
<type 'int'> <type 'numpy.int32'>
works for me
works for me



Nils


From matthieu.brucher at gmail.com  Sun Feb  3 05:27:00 2008
From: matthieu.brucher at gmail.com (Matthieu Brucher)
Date: Sun, 3 Feb 2008 11:27:00 +0100
Subject: [SciPy-dev] openopt example mmp_1.py
In-Reply-To: <47A580EE.5060902@scipy.org>
References: <web-95749909@uni-stuttgart.de> <47A4ECF9.2090309@scipy.org>
	<web-95766984@uni-stuttgart.de> <47A580EE.5060902@scipy.org>
Message-ID: <e76aa17f0802030227o6663123r12aeb1d2e0c46726@mail.gmail.com>

There might a problem with this line as well :

from numpy import *
>

Try not using this or importing exactly what you need/want.

Matthieu
-- 
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080203/d792e124/attachment.html>

From dmitrey.kroshko at scipy.org  Sun Feb  3 06:28:55 2008
From: dmitrey.kroshko at scipy.org (dmitrey)
Date: Sun, 03 Feb 2008 13:28:55 +0200
Subject: [SciPy-dev] openopt example mmp_1.py
In-Reply-To: <e76aa17f0802030227o6663123r12aeb1d2e0c46726@mail.gmail.com>
References: <web-95749909@uni-stuttgart.de>
	<47A4ECF9.2090309@scipy.org>	<web-95766984@uni-stuttgart.de>
	<47A580EE.5060902@scipy.org>
	<e76aa17f0802030227o6663123r12aeb1d2e0c46726@mail.gmail.com>
Message-ID: <47A5A577.1080109@scipy.org>

Matthieu, do you have encountered the bug (i.e. as well as Nils)?

As for "from numpy import *", I use it when there are either more than a 
dozen of params to be imported or for examples, where I try to use as 
little code as possible, and those dozens of imported params look uglier 
than MATLAB style, so possible Python/openopt newbies will not be fond 
of those imports.

Regards, D.

Matthieu Brucher wrote:
> There might a problem with this line as well :
>
>     from numpy import *
>
>
> Try not using this or importing exactly what you need/want.
>
> Matthieu
> -- 
> French PhD student
> Website : http://matthieu-brucher.developpez.com/
> Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
> LinkedIn : http://www.linkedin.com/in/matthieubrucher



From matthieu.brucher at gmail.com  Sun Feb  3 06:35:50 2008
From: matthieu.brucher at gmail.com (Matthieu Brucher)
Date: Sun, 3 Feb 2008 12:35:50 +0100
Subject: [SciPy-dev] openopt example mmp_1.py
In-Reply-To: <47A5A577.1080109@scipy.org>
References: <web-95749909@uni-stuttgart.de> <47A4ECF9.2090309@scipy.org>
	<web-95766984@uni-stuttgart.de> <47A580EE.5060902@scipy.org>
	<e76aa17f0802030227o6663123r12aeb1d2e0c46726@mail.gmail.com>
	<47A5A577.1080109@scipy.org>
Message-ID: <e76aa17f0802030335ub1351e4ud93b7880b5542f79@mail.gmail.com>

2008/2/3, dmitrey <dmitrey.kroshko at scipy.org>:
>
> Matthieu, do you have encountered the bug (i.e. as well as Nils)?
>

I did not have the time right now (writting my PhD thesis), I just wanted to
add some possible hint so that you and Nils could find the answer (strange
that on some systems, it works, on other it does not :|)

Matthieu
-- 
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080203/570702a7/attachment.html>

From dmitrey.kroshko at scipy.org  Sun Feb  3 06:44:35 2008
From: dmitrey.kroshko at scipy.org (dmitrey)
Date: Sun, 03 Feb 2008 13:44:35 +0200
Subject: [SciPy-dev] openopt example mmp_1.py
In-Reply-To: <e76aa17f0802030335ub1351e4ud93b7880b5542f79@mail.gmail.com>
References: <web-95749909@uni-stuttgart.de>
	<47A4ECF9.2090309@scipy.org>	<web-95766984@uni-stuttgart.de>
	<47A580EE.5060902@scipy.org>	<e76aa17f0802030227o6663123r12aeb1d2e0c46726@mail.gmail.com>	<47A5A577.1080109@scipy.org>
	<e76aa17f0802030335ub1351e4ud93b7880b5542f79@mail.gmail.com>
Message-ID: <47A5A923.4030505@scipy.org>

I guess we should wait - will other users report the bug or not.
As for import from numpy, since python doesn't fails with "undefined 
variable int32" in line 355, hence int32 is imported successfully from 
numpy
Nils, do you have encountered the bug in another example from /examples?
Is the problem urgent for you?

Regards, D.


Matthieu Brucher wrote:
>
>
> 2008/2/3, dmitrey <dmitrey.kroshko at scipy.org 
> <mailto:dmitrey.kroshko at scipy.org>>:
>
>     Matthieu, do you have encountered the bug (i.e. as well as Nils)?
>
>
> I did not have the time right now (writting my PhD thesis), I just 
> wanted to add some possible hint so that you and Nils could find the 
> answer (strange that on some systems, it works, on other it does not :|)
>
> Matthieu
> -- 
> French PhD student
> Website : http://matthieu-brucher.developpez.com/
> Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
> LinkedIn : http://www.linkedin.com/in/matthieubrucher
> ------------------------------------------------------------------------
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>   



From nwagner at iam.uni-stuttgart.de  Sun Feb  3 07:19:30 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Sun, 03 Feb 2008 13:19:30 +0100
Subject: [SciPy-dev] openopt example mmp_1.py
In-Reply-To: <47A5A923.4030505@scipy.org>
References: <web-95749909@uni-stuttgart.de> <47A4ECF9.2090309@scipy.org>
	<web-95766984@uni-stuttgart.de> <47A580EE.5060902@scipy.org>
	<e76aa17f0802030227o6663123r12aeb1d2e0c46726@mail.gmail.com>
	<47A5A577.1080109@scipy.org>
	<e76aa17f0802030335ub1351e4ud93b7880b5542f79@mail.gmail.com>
	<47A5A923.4030505@scipy.org>
Message-ID: <web-95772623@uni-stuttgart.de>

On Sun, 03 Feb 2008 13:44:35 +0200
  dmitrey <dmitrey.kroshko at scipy.org> wrote:
> I guess we should wait - will other users report the bug 
>or not.
> As for import from numpy, since python doesn't fails 
>with "undefined 
> variable int32" in line 355, hence int32 is imported 
>successfully from 
> numpy
> Nils, do you have encountered the bug in another example 
>from /examples?
> Is the problem urgent for you?
> 
No, not at all. BTW, it works with python2.5 on a 64 bit 
machine.

Nils
  


From dave.hirschfeld at gmail.com  Sun Feb  3 08:19:19 2008
From: dave.hirschfeld at gmail.com (Dave)
Date: Sun, 3 Feb 2008 13:19:19 +0000 (UTC)
Subject: [SciPy-dev] =?utf-8?q?openopt_example_mmp=5F1=2Epy?=
References: <web-95749909@uni-stuttgart.de>
	<47A4ECF9.2090309@scipy.org>	<web-95766984@uni-stuttgart.de>
	<47A580EE.5060902@scipy.org>	<e76aa17f0802030227o6663123r12aeb1d2e0c46726@mail.gmail.com>	<47A5A577.1080109@scipy.org>
	<e76aa17f0802030335ub1351e4ud93b7880b5542f79@mail.gmail.com>
	<47A5A923.4030505@scipy.org>
Message-ID: <loom.20080203T131644-498@post.gmane.org>

dmitrey <dmitrey.kroshko <at> scipy.org> writes:

> I guess we should wait - will other users report the bug or not.
> As for import from numpy, since python doesn't fails with "undefined 
> variable int32" in line 355, hence int32 is imported successfully from 
> numpy

I appear to get the same bug from a just updated svn checkout:

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)]
IPython 0.8.2.svn.r2848 -- An enhanced Interactive Python.

In [1]: cd C:\src\openopt\scikits\openopt\examples
C:\src\openopt\scikits\openopt\examples

In [2]: run -i mmp_1.py
starting solver nsmm (license: BSD)  with problem  unnamed
incorrect func index type!
---------------------------------------------------------------------------
OpenOptException                          Traceback (most recent call last)

C:\src\openopt\scikits\openopt\examples\mmp_1.py in <module>()
     20 # optional, matplotlib is required:
     21 p.plot=1
---> 22 r = p.solve('nsmm')
     23 print 'MMP result:',  r.ff
     24

c:\python25\lib\site-packages\scikits\openopt\Kernel\BaseProblem.py in solve(sel
f, solvers, *args, **kwargs)
    205
    206     def solve(self, solvers, *args, **kwargs):
--> 207         return runProbSolver(self, solvers, *args, **kwargs)
    208
    209     def auxFunc(self, x, *args, **kwargs):

c:\python25\lib\site-packages\scikits\openopt\Kernel\runProbSolver.py in runProb
Solver(p_, solver_str, *args, **kwargs)
    154     if p.iprint >= 0: print 'starting solver',  p.solverName,  '(license
: ' +  p.solverLicense + ')', ' with problem ', p.name
    155     try:
--> 156         solver(p)
    157     except isSolved:
    158         p.xf = p.xk

c:\python25\lib\site-packages\scikits\openopt\solvers\UkrOpt\nsmm.py in __solver
__(self, p)
     52         p2.primalIterFcn,  p2.iterfcn = p2.iterfcn, iterfcn
     53
---> 54         r2 = p2.solve('ralg')
     55         #xf = fsolve(p.f, p.x0, fprime=p.df, xtol = p.xtol, maxfev = p.m
axFunEvals)
     56         xf = r2.xf

c:\python25\lib\site-packages\scikits\openopt\Kernel\BaseProblem.py in solve(sel
f, solvers, *args, **kwargs)
    205
    206     def solve(self, solvers, *args, **kwargs):
--> 207         return runProbSolver(self, solvers, *args, **kwargs)
    208
    209     def auxFunc(self, x, *args, **kwargs):

c:\python25\lib\site-packages\scikits\openopt\Kernel\runProbSolver.py in runProb
Solver(p_, solver_str, *args, **kwargs)
    154     if p.iprint >= 0: print 'starting solver',  p.solverName,  '(license
: ' +  p.solverLicense + ')', ' with problem ', p.name
    155     try:
--> 156         solver(p)
    157     except isSolved:
    158         p.xf = p.xk

c:\python25\lib\site-packages\scikits\openopt\solvers\UkrOpt\ralg.py in __solver
__(self, p)
     60         p.fk = fk
     61
---> 62         g,  fname,  ind = self.getRalgDirection(x, p)
     63         p._df = copy(g)
     64

c:\python25\lib\site-packages\scikits\openopt\solvers\UkrOpt\ralg.py in getRalgD
irection(self, x, p)
    228             d = p.getMaxConstrGradient(x)
    229         else:
--> 230             d = p.df(x)
    231         return d, fname, ind
    232

c:\python25\lib\site-packages\scikits\openopt\Kernel\objFunRelated.py in user_df
(p, x, IND, ignorePrev)
    136                 return DF
    137
--> 138         df = user_df_func(*(x,) + p.args.f)
    139         if ind is not None: df = df[ind]
    140         if p.useScaling:

c:\python25\lib\site-packages\scikits\openopt\solvers\UkrOpt\nsmm.py in df(x)
     29             F = p.f(x)
     30             ind = argmax(F)
---> 31             return p.df(x, ind)
     32
     33         def iterfcn(*args,  **kwargs):

c:\python25\lib\site-packages\scikits\openopt\Kernel\objFunRelated.py in user_df
(p, x, IND, ignorePrev)
    103
    104     def user_df(p, x, IND = None, ignorePrev=False):
--> 105         if IND is not None: ind = p.getCorrectInd(IND)
    106         else: ind = None
    107         if hasattr(p, 'xPrevDF') and all(x == p.xPrevDF) and not ignoreP
rev and ind is None:

c:\python25\lib\site-packages\scikits\openopt\Kernel\objFunRelated.py in getCorr
ectInd(p, ind)
    356             elif type(ind) == ndarray: return atleast_1d(ind).tolist()
    357             elif type(ind) not in (list, tuple):
--> 358                 p.err('incorrect func index type!')
    359             else: return ind
    360         else: return None

c:\python25\lib\site-packages\scikits\openopt\Kernel\oologfcn.py in ooerr(msg)
     10
     11 def ooerr(msg):
---> 12     raise OpenOptException(msg)
     13
     14 def ooPWarn(msg):

OpenOptException: <oologfcn.OpenOptException instance at 0x01CE9D28>
WARNING: Failure executing file: <mmp_1.py>

In [3]: from scikits import openopt; openopt.__version__
Out[3]: '0.15'

In [4]: import numpy; numpy.__version__
Out[4]: '1.0.3.1'

In [5]: from numpy import *

In [6]: a=0

In [7]: b = int32(15)

In [8]: print type(a), type(b)
<type 'int'> <type 'numpy.int32'>

In [9]:

In [10]: L = [int, int32, int64]

In [11]:

In [12]: if type(a) in L:
   ....:
   ....:          print 'works for me'
   ....:
works for me

In [13]: if type(b) in L:
   ....:
   ....:          print 'works for me'
   ....:
works for me

In [14]:




From aisaac at american.edu  Sun Feb  3 08:35:31 2008
From: aisaac at american.edu (Alan G Isaac)
Date: Sun, 3 Feb 2008 08:35:31 -0500
Subject: [SciPy-dev] openopt example  mmp_1.py
In-Reply-To: <47A580EE.5060902@scipy.org>
References: <web-95749909@uni-stuttgart.de>
	<47A4ECF9.2090309@scipy.org><web-95766984@uni-stuttgart.de><47A580EE.5060902@scipy.org>
Message-ID: <Mahogany-0.67.0-1544-20080203-083531.00@american.edu>

On Sun, 03 Feb 2008, dmitrey apparently wrote:
> p.err('incorrect func index type!')

Change this to:
p.err('%s is an unknown func index type!'%type(ind))

Stylistically, I'd prefer something with less type checking.  
Perhaps something along the lines of the following.  (Untested.)

Cheers,
Alan Isaac


def getCorrectInd(p, ind):
    if type(ind) in [NoneType, list, tuple]:
        result = ind
    else:
        try:
            result = atleast_1d(ind).tolist()
        except:
            raise ValueError('%s is an unknown func index type!'%type(ind))
    return result




From dave.hirschfeld at gmail.com  Sun Feb  3 09:00:30 2008
From: dave.hirschfeld at gmail.com (Dave)
Date: Sun, 3 Feb 2008 14:00:30 +0000 (UTC)
Subject: [SciPy-dev] =?utf-8?q?openopt_example_mmp=5F1=2Epy?=
References: <web-95749909@uni-stuttgart.de>
	<47A4ECF9.2090309@scipy.org><web-95766984@uni-stuttgart.de><47A580EE.5060902@scipy.org>
	<Mahogany-0.67.0-1544-20080203-083531.00@american.edu>
Message-ID: <loom.20080203T135655-408@post.gmane.org>

Very strange:

In [3]: debug
> c:\python25\lib\site-packages\scikits\openopt\kernel\oologfcn.py(12)ooerr()
     11 def ooerr(msg):
---> 12     raise OpenOptException(msg)
     13

ipdb> up
> c:\python25\lib\site-packages\scikits\openopt\kernel\objfunrelated.py(358)getC
orrectInd()
    357             elif type(ind) not in (list, tuple):
--> 358                 p.err('incorrect func index type!')
    359             else: return ind

ipdb> ind
0
ipdb> type(ind)
<type 'numpy.int32'>
ipdb> type(ind) not in (list, tuple)
True
ipdb> type(ind) in [int, int32, int64]
False
ipdb> int32
<type 'numpy.int32'>
ipdb> int64
<type 'numpy.int64'>
ipdb> type(ind) is int
False
ipdb> type(ind) is int32
False

Works with Alan's code (after importing NoneType):

Alan G Isaac <aisaac <at> american.edu> writes:

> 
> def getCorrectInd(p, ind):
      from types import NoneType
>     if type(ind) in [NoneType, list, tuple]:
>         result = ind
>     else:
>         try:
>             result = atleast_1d(ind).tolist()
>         except:
>             raise ValueError('%s is an unknown func index type!'%type(ind))
>     return result
> 



In [3]: run -i mmp_1.py
starting solver nsmm (license: BSD)  with problem  unnamed
Niter   F
    0       6.47e+003
   44       1.45e+003
nsmm has finished solving the problem unnamed
istop:  4 (|| F[k] - F[k-1] || < ftol)
Solver:   Time Elapsed = 0.26   CPU Time Elapsed = 0.248339942646
Plotting: Time Elapsed = 2.55   CPU Time Elapsed = 2.55752253429
objFunValue: 1449.79080685 (feasible, max constraint =  0)
MMP result: 1449.79080685

In [4]:



From aisaac at american.edu  Sun Feb  3 09:28:01 2008
From: aisaac at american.edu (Alan G Isaac)
Date: Sun, 3 Feb 2008 09:28:01 -0500
Subject: [SciPy-dev] openopt example mmp_1.py
In-Reply-To: <loom.20080203T135655-408@post.gmane.org>
References: <web-95749909@uni-stuttgart.de><47A4ECF9.2090309@scipy.org><web-95766984@uni-stuttgart.de><47A580EE.5060902@scipy.org><Mahogany-0.67.0-1544-20080203-083531.00@american.edu><loom.20080203T135655-408@post.gmane.org>
Message-ID: <Mahogany-0.67.0-1544-20080203-092801.00@american.edu>

On Sun, 3 Feb 2008, (UTC) Dave apparently wrote:
> Works with Alan's code 


Then it appears to be  a type checking problem in the original code.
Just print out type(ind) to check.

Cheers,
Alan Isaac





From dmitrey.kroshko at scipy.org  Sun Feb  3 09:35:54 2008
From: dmitrey.kroshko at scipy.org (dmitrey)
Date: Sun, 03 Feb 2008 16:35:54 +0200
Subject: [SciPy-dev] openopt example mmp_1.py
In-Reply-To: <Mahogany-0.67.0-1544-20080203-092801.00@american.edu>
References: <web-95749909@uni-stuttgart.de><47A4ECF9.2090309@scipy.org><web-95766984@uni-stuttgart.de><47A580EE.5060902@scipy.org><Mahogany-0.67.0-1544-20080203-083531.00@american.edu><loom.20080203T135655-408@post.gmane.org>
	<Mahogany-0.67.0-1544-20080203-092801.00@american.edu>
Message-ID: <47A5D14A.2050107@scipy.org>

Dave has already attached the debug info:

ipdb> type(ind)
<type 'numpy.int32'>
ipdb> type(ind) not in (list, tuple)
True
ipdb> type(ind) in [int, int32, int64]
False
ipdb> int32
<type 'numpy.int32'>

Ok, so now I'll commit the proposed changes.

However, one more problem has appeared: ALGENCAN fails with
StdErr: *** glibc detected *** /usr/bin/python: free(): invalid pointer: 
0x00000000008362f0 ***

IIRC I have accepted a proposition of updating glibc from software channel.

D.

Alan G Isaac wrote:
> On Sun, 3 Feb 2008, (UTC) Dave apparently wrote:
>   
>> Works with Alan's code 
>>     
>
>
> Then it appears to be  a type checking problem in the original code.
> Just print out type(ind) to check.
>
> Cheers,
> Alan Isaac
>
>
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
>
>
>   



From aisaac at american.edu  Sun Feb  3 10:18:35 2008
From: aisaac at american.edu (Alan G Isaac)
Date: Sun, 3 Feb 2008 10:18:35 -0500
Subject: [SciPy-dev] openopt example mmp_1.py
In-Reply-To: <47A5D14A.2050107@scipy.org>
References: <web-95749909@uni-stuttgart.de><47A4ECF9.2090309@scipy.org><web-95766984@uni-stuttgart.de><47A580EE.5060902@scipy.org><Mahogany-0.67.0-1544-20080203-083531.00@american.edu><loom.20080203T135655-408@post.gmane.org>
	<Mahogany-0.67.0-1544-20080203-092801.00@american.edu><47A5D14A.2050107@scipy.org>
Message-ID: <Mahogany-0.67.0-1544-20080203-101835.00@american.edu>

On Sun, 03 Feb 2008, dmitrey apparently wrote:
> Dave has already attached the debug info: 
> ipdb> type(ind)
> <type 'numpy.int32'> 
> ipdb> type(ind) not in (list, tuple)
> True 
> ipdb> type(ind) in [int, int32, int64] 
> False 
> ipdb> int32 
> <type 'numpy.int32'> 


Odd.
What about
id(type(ind))
id(int32)
?

Cheers,
Alan Isaac





From dave.hirschfeld at gmail.com  Sun Feb  3 10:32:14 2008
From: dave.hirschfeld at gmail.com (Dave)
Date: Sun, 3 Feb 2008 15:32:14 +0000 (UTC)
Subject: [SciPy-dev] =?utf-8?q?openopt_example_mmp=5F1=2Epy?=
References: <web-95749909@uni-stuttgart.de><47A4ECF9.2090309@scipy.org><web-95766984@uni-stuttgart.de><47A580EE.5060902@scipy.org><Mahogany-0.67.0-1544-20080203-083531.00@american.edu><loom.20080203T135655-408@post.gmane.org>
	<Mahogany-0.67.0-1544-20080203-092801.00@american.edu><47A5D14A.2050107@scipy.org>
	<Mahogany-0.67.0-1544-20080203-101835.00@american.edu>
Message-ID: <loom.20080203T152857-794@post.gmane.org>

Alan G Isaac <aisaac <at> american.edu> writes:

> 
> Odd.
> What about
> id(type(ind))
> id(int32)
> ?
> 
> Cheers,
> Alan Isaac
> 

ipdb> ind
0
ipdb> type(ind)
<type 'numpy.int32'>
ipdb> int32
<type 'numpy.int32'>
ipdb> type(ind) is int32
False
ipdb> id(type(ind))
1810415712
ipdb> id(int32)
1810415520
ipdb> import numpy
ipdb> numpy.int32
<type 'numpy.int32'>
ipdb> id(numpy.int32)
1810415520
ipdb>

-Dave



From aisaac at american.edu  Sun Feb  3 11:32:55 2008
From: aisaac at american.edu (Alan G Isaac)
Date: Sun, 3 Feb 2008 11:32:55 -0500
Subject: [SciPy-dev] openopt example mmp_1.py
In-Reply-To: <loom.20080203T152857-794@post.gmane.org>
References: <web-95749909@uni-stuttgart.de><47A4ECF9.2090309@scipy.org><web-95766984@uni-stuttgart.de><47A580EE.5060902@scipy.org><Mahogany-0.67.0-1544-20080203-083531.00@american.edu><loom.20080203T135655-408@post.gmane.org><Mahogany-0.67.0-1544-20080203-092801.00@american.edu><47A5D14A.2050107@scipy.org><Mahogany-0.67.0-1544-20080203-101835.00@american.edu><loom.20080203T152857-794@post.gmane.org>
Message-ID: <Mahogany-0.67.0-1544-20080203-113255.00@american.edu>

On Sun, 3 Feb 2008, (UTC) Dave apparently wrote:
> ipdb> ind 
> 0
> ipdb> type(ind)
> <type 'numpy.int32'> 
> ipdb> int32 
> <type 'numpy.int32'> 
> ipdb> type(ind) is int32 
> False 
> ipdb> id(type(ind))
> 1810415712 
> ipdb> id(int32)
> 1810415520 
> ipdb> import numpy 
> ipdb> numpy.int32 
> <type 'numpy.int32'> 
> ipdb> id(numpy.int32)
> 1810415520 
> ipdb> 


Well that explains the comparison failure.
But I do not know the circumstances under
which two difference types will represent
themselves as the same type.  Except for
redefinition, of course.

In this example, how was ``ind`` created?

Cheers,
Alan Isaac





From dave.hirschfeld at gmail.com  Sun Feb  3 12:09:48 2008
From: dave.hirschfeld at gmail.com (Dave)
Date: Sun, 3 Feb 2008 17:09:48 +0000 (UTC)
Subject: [SciPy-dev] =?utf-8?q?openopt_example_mmp=5F1=2Epy?=
References: <web-95749909@uni-stuttgart.de><47A4ECF9.2090309@scipy.org><web-95766984@uni-stuttgart.de><47A580EE.5060902@scipy.org><Mahogany-0.67.0-1544-20080203-083531.00@american.edu><loom.20080203T135655-408@post.gmane.org><Mahogany-0.67.0-1544-20080203-092801.00@american.edu><47A5D14A.2050107@scipy.org><Mahogany-0.67.0-1544-20080203-101835.00@american.edu><loom.20080203T152857-794@post.gmane.org>
	<Mahogany-0.67.0-1544-20080203-113255.00@american.edu>
Message-ID: <loom.20080203T170058-690@post.gmane.org>

Alan G Isaac <aisaac <at> american.edu> writes:
> 
> In this example, how was ``ind`` created?
> 

It's created with the numpy.argmax function:

In [4]: debug
> c:\python25\lib\site-packages\scikits\openopt\solvers\ukropt\nsmm.py(31)df()
     30             ind = argmax(F)
---> 31             1/0
     32             return p.df(x, ind)

ipdb> F.argmax()
0
ipdb> type(F.argmax())
<type 'numpy.int32'>
ipdb> id(type(F.argmax()))
1810415712
ipdb> import numpy
ipdb> id(numpy.int32)
1810415520

That's certainly not what I would expect!

A minimal test case to demonstrate this behaviour is:

>>> import numpy
>>> x = numpy.random.random(100)
>>> ind = numpy.argmax(x)
>>> type(ind)
<type 'numpy.int32'>
>>> type(ind) is type(numpy.int32)
False
>>> id(type(ind))
1810415712
>>> id(type(numpy.int32))
505314840

The solution I guess is to eliminate the explicit type checking as per Alan's
previously posted code.

-Dave



From aisaac at american.edu  Sun Feb  3 13:23:30 2008
From: aisaac at american.edu (Alan G Isaac)
Date: Sun, 3 Feb 2008 13:23:30 -0500
Subject: [SciPy-dev] bug in argmax?
In-Reply-To: <loom.20080203T170058-690@post.gmane.org>
References: <web-95749909@uni-stuttgart.de><47A4ECF9.2090309@scipy.org><web-95766984@uni-stuttgart.de><47A580EE.5060902@scipy.org><Mahogany-0.67.0-1544-20080203-083531.00@american.edu><loom.20080203T135655-408@post.gmane.org><Mahogany-0.67.0-1544-20080203-092801.00@american.edu><47A5D14A.2050107@scipy.org><Mahogany-0.67.0-1544-20080203-101835.00@american.edu><loom.20080203T152857-794@post.gmane.org><Mahogany-0.67.0-1544-20080203-113255.00@american.edu><loom.20080203T170058-690@post.gmane.org>
Message-ID: <Mahogany-0.67.0-1544-20080203-132330.00@american.edu>

Thanks Dave.
Looks like a bug to me.
Alan Isaac

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as N
>>> N.__version__
'1.0.4'
>>> test1=N.int32(32)
>>> type(test1)
<type 'numpy.int32'>
>>> type(test1) is N.int32
True
>>> id(type(test1))
1810419616
>>> test2 = N.array([3,2,1]).argmax()
>>> type(test2)
<type 'numpy.int32'>
>>> type(test2) is N.int32
False
>>> id(type(test2))
1810419808




From nwagner at iam.uni-stuttgart.de  Sun Feb  3 14:21:25 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Sun, 03 Feb 2008 20:21:25 +0100
Subject: [SciPy-dev] openopt example  mmp_1.py
In-Reply-To: <47A4ECF9.2090309@scipy.org>
References: <web-95749909@uni-stuttgart.de>
 <47A4ECF9.2090309@scipy.org>
Message-ID: <web-95785699@uni-stuttgart.de>

On Sun, 03 Feb 2008 00:21:45 +0200
  dmitrey <dmitrey.kroshko at scipy.org> wrote:
> I don't know what's the matter, everything works well 
>for me, including 
> latest revision checked out from svn into separate dir & 
>python setup.py 
> install + python mmp_1.py.
> 
> Could anyone else check the example?
> 
> Nils, could you add line "print type(ind)" before 
>objFunRelated.py line 
> 358, run "python setup.py install" and run "python 
>mmp_1.py"? Maybe it 
> will help to fix the bug.
> However, I guess it could be solved via simple cleanup 
>and checkout OO 
> from svn repository.
> 
> Regards, D.
>  

Hi Dmitrey,

A fresh install works for me. Thank you very much.

The next problem comes with nlp_d2f.py

/usr/bin/python -i 
svn/openopt/scikits/openopt/examples/nlp_d2f.py
incorrect solver is called, maybe the solver "scipy_ncg" 
is not installed
Traceback (most recent call last):
   File "svn/openopt/scikits/openopt/examples/nlp_d2f.py", 
line 21, in ?
     r = p.solve('scipy_ncg')
   File 
"/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/BaseProblem.py", 
line 207, in solve
     return runProbSolver(self, solvers, *args, **kwargs)
   File 
"/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/runProbSolver.py", 
line 24, in runProbSolver
     p.err('incorrect solver is called, maybe the solver 
"' + solver_str +'" is not installed')
   File 
"/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/oologfcn.py", 
line 12, in ooerr
     raise OpenOptException(msg)
oologfcn.OpenOptException: <oologfcn.OpenOptException 
instance at 0x42f2808c>

Nils


From dmitrey.kroshko at scipy.org  Sun Feb  3 15:25:11 2008
From: dmitrey.kroshko at scipy.org (dmitrey)
Date: Sun, 03 Feb 2008 22:25:11 +0200
Subject: [SciPy-dev] openopt example  mmp_1.py
In-Reply-To: <web-95785699@uni-stuttgart.de>
References: <web-95749909@uni-stuttgart.de> <47A4ECF9.2090309@scipy.org>
	<web-95785699@uni-stuttgart.de>
Message-ID: <47A62327.4020506@scipy.org>

Thank you for the bugreport, please try now again
Regards, D.

Nils Wagner wrote:
> Hi Dmitrey,
>
> A fresh install works for me. Thank you very much.
>
> The next problem comes with nlp_d2f.py
>
> /usr/bin/python -i 
> svn/openopt/scikits/openopt/examples/nlp_d2f.py
> incorrect solver is called, maybe the solver "scipy_ncg" 
> is not installed
> Traceback (most recent call last):
>    File "svn/openopt/scikits/openopt/examples/nlp_d2f.py", 
> line 21, in ?
>      r = p.solve('scipy_ncg')
>    File 
> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/BaseProblem.py", 
> line 207, in solve
>      return runProbSolver(self, solvers, *args, **kwargs)
>    File 
> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/runProbSolver.py", 
> line 24, in runProbSolver
>      p.err('incorrect solver is called, maybe the solver 
> "' + solver_str +'" is not installed')
>    File 
> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/oologfcn.py", 
> line 12, in ooerr
>      raise OpenOptException(msg)
> oologfcn.OpenOptException: <oologfcn.OpenOptException 
> instance at 0x42f2808c>
>
> Nils
> ______________



From dmitrey.kroshko at scipy.org  Sun Feb  3 15:27:21 2008
From: dmitrey.kroshko at scipy.org (dmitrey)
Date: Sun, 03 Feb 2008 22:27:21 +0200
Subject: [SciPy-dev] openopt example  mmp_1.py
In-Reply-To: <47A62327.4020506@scipy.org>
References: <web-95749909@uni-stuttgart.de>
	<47A4ECF9.2090309@scipy.org>	<web-95785699@uni-stuttgart.de>
	<47A62327.4020506@scipy.org>
Message-ID: <47A623A9.5010804@scipy.org>

I have some troubles with commiting to svn, check that my svn changes 
really have been  committed
D.

dmitrey wrote:
> Thank you for the bugreport, please try now again
> Regards, D.
>
> Nils Wagner wrote:
>   
>> Hi Dmitrey,
>>
>> A fresh install works for me. Thank you very much.
>>
>> The next problem comes with nlp_d2f.py
>>
>> /usr/bin/python -i 
>> svn/openopt/scikits/openopt/examples/nlp_d2f.py
>> incorrect solver is called, maybe the solver "scipy_ncg" 
>> is not installed
>> Traceback (most recent call last):
>>    File "svn/openopt/scikits/openopt/examples/nlp_d2f.py", 
>> line 21, in ?
>>      r = p.solve('scipy_ncg')
>>    File 
>> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/BaseProblem.py", 
>> line 207, in solve
>>      return runProbSolver(self, solvers, *args, **kwargs)
>>    File 
>> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/runProbSolver.py", 
>> line 24, in runProbSolver
>>      p.err('incorrect solver is called, maybe the solver 
>> "' + solver_str +'" is not installed')
>>    File 
>> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/oologfcn.py", 
>> line 12, in ooerr
>>      raise OpenOptException(msg)
>> oologfcn.OpenOptException: <oologfcn.OpenOptException 
>> instance at 0x42f2808c>
>>
>> Nils
>> ______________
>>     
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
>
>
>   



From nwagner at iam.uni-stuttgart.de  Sun Feb  3 15:48:50 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Sun, 03 Feb 2008 21:48:50 +0100
Subject: [SciPy-dev] openopt example  mmp_1.py
In-Reply-To: <47A62327.4020506@scipy.org>
References: <web-95749909@uni-stuttgart.de> <47A4ECF9.2090309@scipy.org>
	<web-95785699@uni-stuttgart.de> <47A62327.4020506@scipy.org>
Message-ID: <web-95787988@uni-stuttgart.de>

On Sun, 03 Feb 2008 22:25:11 +0200
  dmitrey <dmitrey.kroshko at scipy.org> wrote:
> Thank you for the bugreport, please try now again
> Regards, D.
> 
  
Thank you. Works for me.

Cheers,
              Nils


From wnbell at gmail.com  Sun Feb  3 18:07:18 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Sun, 3 Feb 2008 17:07:18 -0600
Subject: [SciPy-dev] [SciPy-user] scipy.sparse.lil_matrix and fancy
	indexing
In-Reply-To: <ce557a360802031429v2a47e2aah3f29f93c25f48012@mail.gmail.com>
References: <ce557a360802031429v2a47e2aah3f29f93c25f48012@mail.gmail.com>
Message-ID: <d05265cb0802031507y2bd0383ai995e34a77855dfda@mail.gmail.com>

On Feb 3, 2008 4:29 PM, Anne Archibald <peridot.faceted at gmail.com> wrote:
> Is this intended behaviour? Failure to raise an exception on bad
> input? Just a bug?

That's unlikely to be the intended behaviour.

The lil_matrix. __setitem__ code is fairly ugly, is anyone actively
maintaining it?
http://projects.scipy.org/scipy/scipy/browser/trunk/scipy/sparse/lil.py#L273

-- 
Nathan Bell wnbell at gmail.com
http://graphics.cs.uiuc.edu/~wnbell/


From stefan at sun.ac.za  Mon Feb  4 01:18:54 2008
From: stefan at sun.ac.za (Stefan van der Walt)
Date: Mon, 4 Feb 2008 08:18:54 +0200
Subject: [SciPy-dev] openopt example  mmp_1.py
In-Reply-To: <47A58BB6.1030809@scipy.org>
References: <web-95749909@uni-stuttgart.de> <47A4ECF9.2090309@scipy.org>
	<web-95766984@uni-stuttgart.de> <47A580EE.5060902@scipy.org>
	<web-95767502@uni-stuttgart.de> <47A58BB6.1030809@scipy.org>
Message-ID: <20080204061851.GA21372@mentat.za.net>

Hi Dmitrey

On Sun, Feb 03, 2008 at 11:39:02AM +0200, dmitrey wrote:
> "if type(ind) in [int, int32, int64]: return [ind]"

'issubdtype' does the checking you require:

import numpy as np
np.issubdtype(ind,int)

Regards
St?fan


From aisaac at american.edu  Mon Feb  4 08:05:00 2008
From: aisaac at american.edu (Alan G Isaac)
Date: Mon, 4 Feb 2008 08:05:00 -0500
Subject: [SciPy-dev] openopt example  mmp_1.py
In-Reply-To: <20080204061851.GA21372@mentat.za.net>
References: <web-95749909@uni-stuttgart.de>
	<47A4ECF9.2090309@scipy.org><web-95766984@uni-stuttgart.de>
	<47A580EE.5060902@scipy.org><web-95767502@uni-stuttgart.de>
	<47A58BB6.1030809@scipy.org><20080204061851.GA21372@mentat.za.net>
Message-ID: <Mahogany-0.67.0-908-20080204-080500.00@american.edu>

> On Sun, Feb 03, 2008 at 11:39:02AM +0200, dmitrey wrote:
>> "if type(ind) in [int, int32, int64]: return [ind]"


On Mon, 4 Feb 2008, Stefan van der Walt apparently wrote:
> 'issubdtype' does the checking you require:
> import numpy as np 
> np.issubdtype(ind,int)


If one wanted to do such type checking,
what would be the advantage in this case
over isinstance(ind,int)?

Cheers,
Alan Isaac





From stefan at sun.ac.za  Mon Feb  4 15:34:52 2008
From: stefan at sun.ac.za (Stefan van der Walt)
Date: Mon, 4 Feb 2008 22:34:52 +0200
Subject: [SciPy-dev] openopt example  mmp_1.py
In-Reply-To: <Mahogany-0.67.0-908-20080204-080500.00@american.edu>
References: <web-95749909@uni-stuttgart.de>
	<Mahogany-0.67.0-908-20080204-080500.00@american.edu>
Message-ID: <20080204203452.GH21372@mentat.za.net>

On Mon, Feb 04, 2008 at 08:05:00AM -0500, Alan G Isaac wrote:
> > On Sun, Feb 03, 2008 at 11:39:02AM +0200, dmitrey wrote:
> >> "if type(ind) in [int, int32, int64]: return [ind]"
> 
> 
> On Mon, 4 Feb 2008, Stefan van der Walt apparently wrote:
> > 'issubdtype' does the checking you require:
> > import numpy as np 
> > np.issubdtype(ind,int)
> 
> 
> If one wanted to do such type checking,
> what would be the advantage in this case
> over isinstance(ind,int)?

Well, mainly this

In [1]: isinstance(np.int64,int)
Out[1]: False

In [2]: np.issubdtype(np.int64,int)
Out[2]: True

:)

Cheers
St?fan


From aisaac at american.edu  Mon Feb  4 17:07:18 2008
From: aisaac at american.edu (Alan G Isaac)
Date: Mon, 4 Feb 2008 17:07:18 -0500
Subject: [SciPy-dev] openopt example  mmp_1.py
In-Reply-To: <20080204203452.GH21372@mentat.za.net>
References: <web-95749909@uni-stuttgart.de>
	<Mahogany-0.67.0-908-20080204-080500.00@american.edu><20080204203452.GH21372@mentat.za.net>
Message-ID: <Mahogany-0.67.0-784-20080204-170718.00@american.edu>

On Mon, 4 Feb 2008, Stefan van der Walt apparently wrote:
> In [1]: isinstance(np.int64,int)
> Out[1]: False 

Well that is not too surprising.  ;-)

>>> isinstance(N.int32,int)
False

But the following was surprising to me,
which is surely what you meant to explain:

>>> isinstance(N.int32(0),int)
True
>>> isinstance(N.int64(0),int)
False

So, why the difference here?
Does it go away when Python's difference
between int and long goes away?

Thanks,
Alan





From oliphant at enthought.com  Mon Feb  4 17:43:16 2008
From: oliphant at enthought.com (Travis E. Oliphant)
Date: Mon, 04 Feb 2008 16:43:16 -0600
Subject: [SciPy-dev] openopt example  mmp_1.py
In-Reply-To: <Mahogany-0.67.0-784-20080204-170718.00@american.edu>
References: <web-95749909@uni-stuttgart.de>	<Mahogany-0.67.0-908-20080204-080500.00@american.edu><20080204203452.GH21372@mentat.za.net>
	<Mahogany-0.67.0-784-20080204-170718.00@american.edu>
Message-ID: <47A79504.8040308@enthought.com>

Alan G Isaac wrote:
> On Mon, 4 Feb 2008, Stefan van der Walt apparently wrote:
>   
>> In [1]: isinstance(np.int64,int)
>> Out[1]: False 
>>     
>
> Well that is not too surprising.  ;-)
>
>   
>>>> isinstance(N.int32,int)
>>>>         
> False
>
> But the following was surprising to me,
> which is surely what you meant to explain:
>
>   
>>>> isinstance(N.int32(0),int)
>>>>         
> True
>   
>>>> isinstance(N.int64(0),int)
>>>>         
> False
>
> So, why the difference here?
> Does it go away when Python's difference
> between int and long goes away?
>   

The technical problem here is that to sub-class built-in types (i.e. 
those created in an extension module) in Python there must be binary 
compatibility on the C-level.

So, int32 can have binary compatibility (on  32-bit system anyway), 
while int64 can't.     When int's and long's are united, some 
unspecified adjustment will have to be made.  In a sense, NumPy's 
int-type splitting is opposite in intent of Python's integer 
unification.   Handling this well will require some thought.

Best regards,

-Travis O.




> Thanks,
> Alan
>
>
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
>   



From aisaac at american.edu  Mon Feb  4 21:31:16 2008
From: aisaac at american.edu (Alan G Isaac)
Date: Mon, 4 Feb 2008 21:31:16 -0500
Subject: [SciPy-dev] openopt example  mmp_1.py
In-Reply-To: <47A79504.8040308@enthought.com>
References: <web-95749909@uni-stuttgart.de>	<Mahogany-0.67.0-908-20080204-080500.00@american.edu><20080204203452.GH21372@mentat.za.net>
	<Mahogany-0.67.0-784-20080204-170718.00@american.edu><47A79504.8040308@enthought.com>
Message-ID: <Mahogany-0.67.0-784-20080204-213116.00@american.edu>

On Mon, 04 Feb 2008, "Travis E. Oliphant" apparently wrote:
> When int's and long's are united, some unspecified 
> adjustment will have to be made.  In a sense, NumPy's 
> int-type splitting is opposite in intent of Python's 
> integer unification.

Thanks!
Alan





From cimrman3 at ntc.zcu.cz  Tue Feb  5 08:28:41 2008
From: cimrman3 at ntc.zcu.cz (Robert Cimrman)
Date: Tue, 05 Feb 2008 14:28:41 +0100
Subject: [SciPy-dev] help with svn (umfpack scikit)
Message-ID: <47A86489.3040507@ntc.zcu.cz>

I would like to preserve the SVN history of umpfack.py and related files 
after I move them to the umfpack scikit. Is it possible somehow?

regards,
r.


From guyer at nist.gov  Tue Feb  5 11:34:45 2008
From: guyer at nist.gov (Jonathan Guyer)
Date: Tue, 5 Feb 2008 11:34:45 -0500
Subject: [SciPy-dev] help with svn (umfpack scikit)
In-Reply-To: <47A86489.3040507@ntc.zcu.cz>
References: <47A86489.3040507@ntc.zcu.cz>
Message-ID: <1803DF62-A3C5-45C6-96E8-BDEEE2C6AE50@nist.gov>


On Feb 5, 2008, at 8:28 AM, Robert Cimrman wrote:

> I would like to preserve the SVN history of umpfack.py and related  
> files
> after I move them to the umfpack scikit. Is it possible somehow?

Yes, although depending on the exact nature of the migration, it can  
be a bit tedious:

http://svnbook.red-bean.com/en/1.4/ 
svn.reposadmin.maint.html#svn.reposadmin.maint.migrate

I've done it a couple of times with pretty good sized projects,  
though, so it's certainly feasible.


From cimrman3 at ntc.zcu.cz  Tue Feb  5 12:39:54 2008
From: cimrman3 at ntc.zcu.cz (Robert Cimrman)
Date: Tue, 05 Feb 2008 18:39:54 +0100
Subject: [SciPy-dev] help with svn (umfpack scikit)
In-Reply-To: <1803DF62-A3C5-45C6-96E8-BDEEE2C6AE50@nist.gov>
References: <47A86489.3040507@ntc.zcu.cz>
	<1803DF62-A3C5-45C6-96E8-BDEEE2C6AE50@nist.gov>
Message-ID: <47A89F6A.2090103@ntc.zcu.cz>

Jonathan Guyer wrote:
> On Feb 5, 2008, at 8:28 AM, Robert Cimrman wrote:
> 
>> I would like to preserve the SVN history of umpfack.py and related  
>> files
>> after I move them to the umfpack scikit. Is it possible somehow?
> 
> Yes, although depending on the exact nature of the migration, it can  
> be a bit tedious:
> 
> http://svnbook.red-bean.com/en/1.4/ 
> svn.reposadmin.maint.html#svn.reposadmin.maint.migrate
> 
> I've done it a couple of times with pretty good sized projects,  
> though, so it's certainly feasible.

Thanks! I will try it.

r.


From ellisonbg.net at gmail.com  Tue Feb  5 17:09:59 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Tue, 5 Feb 2008 15:09:59 -0700
Subject: [SciPy-dev] scipy.org is down
Message-ID: <6ce0ac130802051409k3a87c035i450306e18f20b9b1@mail.gmail.com>

Hi,

It looks like scipy.org and friends are down right now.

Brian


From travis at enthought.com  Tue Feb  5 17:57:31 2008
From: travis at enthought.com (Travis Vaught)
Date: Tue, 5 Feb 2008 16:57:31 -0600
Subject: [SciPy-dev] scipy.org is down
In-Reply-To: <6ce0ac130802051409k3a87c035i450306e18f20b9b1@mail.gmail.com>
References: <6ce0ac130802051409k3a87c035i450306e18f20b9b1@mail.gmail.com>
Message-ID: <F3939D49-2752-4F99-BC27-9B3E59C4CE4B@enthought.com>

Up for me from San Antonio.  Still down for anyone?

Travis


On Feb 5, 2008, at 4:09 PM, Brian Granger wrote:

> Hi,
>
> It looks like scipy.org and friends are down right now.
>
> Brian
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>



From ellisonbg.net at gmail.com  Tue Feb  5 18:25:21 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Tue, 5 Feb 2008 16:25:21 -0700
Subject: [SciPy-dev] scipy.org is down
In-Reply-To: <F3939D49-2752-4F99-BC27-9B3E59C4CE4B@enthought.com>
References: <6ce0ac130802051409k3a87c035i450306e18f20b9b1@mail.gmail.com>
	<F3939D49-2752-4F99-BC27-9B3E59C4CE4B@enthought.com>
Message-ID: <6ce0ac130802051525w1cbf862bkcbe96937aee781c0@mail.gmail.com>

Back up for me now.

Brian

On Feb 5, 2008 3:57 PM, Travis Vaught <travis at enthought.com> wrote:
> Up for me from San Antonio.  Still down for anyone?
>
> Travis
>
>
>
> On Feb 5, 2008, at 4:09 PM, Brian Granger wrote:
>
> > Hi,
> >
> > It looks like scipy.org and friends are down right now.
> >
> > Brian
> > _______________________________________________
> > Scipy-dev mailing list
> > Scipy-dev at scipy.org
> > http://projects.scipy.org/mailman/listinfo/scipy-dev
> >
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>


From cimrman3 at ntc.zcu.cz  Wed Feb  6 09:19:02 2008
From: cimrman3 at ntc.zcu.cz (Robert Cimrman)
Date: Wed, 06 Feb 2008 15:19:02 +0100
Subject: [SciPy-dev] help with svn (umfpack scikit)
In-Reply-To: <1803DF62-A3C5-45C6-96E8-BDEEE2C6AE50@nist.gov>
References: <47A86489.3040507@ntc.zcu.cz>
	<1803DF62-A3C5-45C6-96E8-BDEEE2C6AE50@nist.gov>
Message-ID: <47A9C1D6.9080706@ntc.zcu.cz>

Hi Jonathan, and all,

I have encountered some problems (explanation below), so I would like to
ask:
- should I preserve the revision history at all? the easiest thing to do
is to start the umfpack scikit as a new project.
- did any of scikit authors preserved SVN revision history of their 
codes prior to making them scikits?

Jonathan Guyer wrote:
> On Feb 5, 2008, at 8:28 AM, Robert Cimrman wrote:
> 
>> I would like to preserve the SVN history of umpfack.py and related
>>  files after I move them to the umfpack scikit. Is it possible
>> somehow?
> 
> Yes, although depending on the exact nature of the migration, it can
>  be a bit tedious:
> 
> http://svnbook.red-bean.com/en/1.4/ 
> svn.reposadmin.maint.html#svn.reposadmin.maint.migrate
> 
> I've done it a couple of times with pretty good sized projects, 
> though, so it's certainly feasible.

As I understand the doc, the following must be done:

1. svnadmin dump scipy/.svn > scipy_dump
2. svndumpfilter include scipy/scipy/linsolve/umfpack < scipy_dump >
umfpack_dump
3. edit umfpack_dump, tweaking the Node-path and Node-copyfrom-path headers
4. something like: svnadmin create umfpack; svnadmin load umfpack < 
umfpack_dump (this step is not yet clear to me - how to add it into the 
scikits directory structure).

However, step 1, when done on my working copy, leads to:

$ svnadmin dump scipy/.svn > scipy_dump
svnadmin: Expected repository format '3' or '5'; found format '8'

I googled and found that the dump must be done on the primary 
repository. Can somebody make that dump for me, if it is worth the effort?

regards,
r.

ps: long live mercurial, where anybody has the full repository!


From matthieu.brucher at gmail.com  Wed Feb  6 09:28:46 2008
From: matthieu.brucher at gmail.com (Matthieu Brucher)
Date: Wed, 6 Feb 2008 15:28:46 +0100
Subject: [SciPy-dev] help with svn (umfpack scikit)
In-Reply-To: <47A9C1D6.9080706@ntc.zcu.cz>
References: <47A86489.3040507@ntc.zcu.cz>
	<1803DF62-A3C5-45C6-96E8-BDEEE2C6AE50@nist.gov>
	<47A9C1D6.9080706@ntc.zcu.cz>
Message-ID: <e76aa17f0802060628w18fd4341n3870869de8615e85@mail.gmail.com>

>
> I googled and found that the dump must be done on the primary
> repository. Can somebody make that dump for me, if it is worth the effort?
>

The load must be done on the repository as well. Besides there is a change
of structure, so if you manage to do it, it would have been very painful for
you and the one that will load it on the scikit SVN. I don't think it will
have been for much use, as you can go to the scipy repository to get
whatever information you might one day need.

Matthieu
-- 
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080206/16d844a5/attachment.html>

From cimrman3 at ntc.zcu.cz  Wed Feb  6 10:20:19 2008
From: cimrman3 at ntc.zcu.cz (Robert Cimrman)
Date: Wed, 06 Feb 2008 16:20:19 +0100
Subject: [SciPy-dev] help with svn (umfpack scikit)
In-Reply-To: <e76aa17f0802060628w18fd4341n3870869de8615e85@mail.gmail.com>
References: <47A86489.3040507@ntc.zcu.cz>	<1803DF62-A3C5-45C6-96E8-BDEEE2C6AE50@nist.gov>	<47A9C1D6.9080706@ntc.zcu.cz>
	<e76aa17f0802060628w18fd4341n3870869de8615e85@mail.gmail.com>
Message-ID: <47A9D033.9050103@ntc.zcu.cz>

Matthieu Brucher wrote:
>> I googled and found that the dump must be done on the primary
>> repository. Can somebody make that dump for me, if it is worth the effort?
>>
> 
> The load must be done on the repository as well. Besides there is a change
> of structure, so if you manage to do it, it would have been very painful for
> you and the one that will load it on the scikit SVN. I don't think it will
> have been for much use, as you can go to the scipy repository to get
> whatever information you might one day need.

True - I was beginning to think the same, but wanted some confirmation.

thanks,
r.


From millman at berkeley.edu  Wed Feb  6 10:55:49 2008
From: millman at berkeley.edu (Jarrod Millman)
Date: Wed, 6 Feb 2008 07:55:49 -0800
Subject: [SciPy-dev] help with svn (umfpack scikit)
In-Reply-To: <e76aa17f0802060628w18fd4341n3870869de8615e85@mail.gmail.com>
References: <47A86489.3040507@ntc.zcu.cz>
	<1803DF62-A3C5-45C6-96E8-BDEEE2C6AE50@nist.gov>
	<47A9C1D6.9080706@ntc.zcu.cz>
	<e76aa17f0802060628w18fd4341n3870869de8615e85@mail.gmail.com>
Message-ID: <c7009a550802060755o53513233kf36d32394fc85dd0@mail.gmail.com>

On Feb 6, 2008 6:28 AM, Matthieu Brucher <matthieu.brucher at gmail.com> wrote:
> The load must be done on the repository as well. Besides there is a change
> of structure, so if you manage to do it, it would have been very painful for
> you and the one that will load it on the scikit SVN. I don't think it will
> have been for much use, as you can go to the scipy repository to get
> whatever information you might one day need.

+1.  I wouldn't worry about the revision history too much.

Thanks,

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/


From hagberg at lanl.gov  Wed Feb  6 14:12:10 2008
From: hagberg at lanl.gov (Aric Hagberg)
Date: Wed, 6 Feb 2008 12:12:10 -0700
Subject: [SciPy-dev] status of splinalg
In-Reply-To: <d05265cb0802021107y4ab1bb6ds32847ab24994b809@mail.gmail.com>
References: <d05265cb0802021107y4ab1bb6ds32847ab24994b809@mail.gmail.com>
Message-ID: <20080206191210.GA12946@bigjim1.lanl.gov>

On Sat, Feb 02, 2008 at 01:07:48PM -0600, Nathan Bell wrote:
> Remaining tasks with owners:
> 
>       (1) sandbox.lobpcg -> splinalg.eigen.lobpcg
>       (2) sandbox.arpack -> splinalg.eigen.arpack
>       (3) create splinalg.eigen.speigs

I just checked in code for (2) and updated the arpack tickets:

I added a comment to the primary ticket explaining the details:
http://scipy.org/scipy/scipy/ticket/231#comment:21

These can be closed:
http://scipy.org/scipy/scipy/ticket/554
http://scipy.org/scipy/scipy/ticket/366

This one is an enhancement TBD:
http://scipy.org/scipy/scipy/ticket/418

(3) is not completed and needs some specifications for the interface.

The tests for complex and double complex matrices have been commented
out since they fail (Bus Error) on OSX/gfortran with the standard
vecLib framework.  They do work correctly with custom ATLAS libraries.
Perhaps this could be related to gfortran ABI issues
(e.g. http://scipy.org/scipy/scipy/ticket/238 ) or perhaps other
issues with the vecLib code.  I'd like some help trying to figure
that out - should I file a ticket?

Aric



From matthieu.brucher at gmail.com  Wed Feb  6 14:53:07 2008
From: matthieu.brucher at gmail.com (Matthieu Brucher)
Date: Wed, 6 Feb 2008 20:53:07 +0100
Subject: [SciPy-dev] status of splinalg
In-Reply-To: <20080206191210.GA12946@bigjim1.lanl.gov>
References: <d05265cb0802021107y4ab1bb6ds32847ab24994b809@mail.gmail.com>
	<20080206191210.GA12946@bigjim1.lanl.gov>
Message-ID: <e76aa17f0802061153p146b3432u3cf470a8dd07945e@mail.gmail.com>

Is it possible to remove the ARPACK before the name of the functions in the
package ? Perhaps it would be a good time to design a common interface
between arpack and lobcg ?

Thanks for the updates, I'll try to use tomorrow :)

Matthieu

2008/2/6, Aric Hagberg <hagberg at lanl.gov>:
>
> On Sat, Feb 02, 2008 at 01:07:48PM -0600, Nathan Bell wrote:
> > Remaining tasks with owners:
> >
> >       (1) sandbox.lobpcg -> splinalg.eigen.lobpcg
> >       (2) sandbox.arpack -> splinalg.eigen.arpack
> >       (3) create splinalg.eigen.speigs
>
>
> I just checked in code for (2) and updated the arpack tickets:
>
> I added a comment to the primary ticket explaining the details:
> http://scipy.org/scipy/scipy/ticket/231#comment:21
>
> These can be closed:
> http://scipy.org/scipy/scipy/ticket/554
> http://scipy.org/scipy/scipy/ticket/366
>
> This one is an enhancement TBD:
> http://scipy.org/scipy/scipy/ticket/418
>
> (3) is not completed and needs some specifications for the interface.
>
> The tests for complex and double complex matrices have been commented
> out since they fail (Bus Error) on OSX/gfortran with the standard
> vecLib framework.  They do work correctly with custom ATLAS libraries.
> Perhaps this could be related to gfortran ABI issues
> (e.g. http://scipy.org/scipy/scipy/ticket/238 ) or perhaps other
> issues with the vecLib code.  I'd like some help trying to figure
> that out - should I file a ticket?
>
>
> Aric
>
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>



-- 
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080206/8b28c13b/attachment.html>

From cimrman3 at ntc.zcu.cz  Thu Feb  7 08:34:19 2008
From: cimrman3 at ntc.zcu.cz (Robert Cimrman)
Date: Thu, 07 Feb 2008 14:34:19 +0100
Subject: [SciPy-dev] umfpack scikit
Message-ID: <47AB08DB.1080100@ntc.zcu.cz>

Hi,

I have the first version of the scikit ready but it seems I have not 
rights to commit (username 'rc'). Can somebody help please?

Concerning the umfpack files from scipy.splinalg.dsolve, I would let 
them in place for some transition period. I will add something like the 
code below to linsolve.py:

--
if isUmfpack and noScikit:
     warn( 'scipy.splinalg.dsolve.umfpack has moved, install 
scikits.umfpack instead', DeprecationWarning )
--

The scikit now contains the same code that was in 
scipy.splinalg.dsolve.umfpack, I did not include the GPL-ed umfpack 
sources. What is your opinion?

1. Let the wrappers BSD and install umfpack libraries separately as it 
is now,
2. or include everything and change the scikit license to GPL.

I am more for option 1., as on my system (Gentoo Linux) umfpack 
libraries exist as a standard package and the installation is trivial. 
This is IMHO true on other systems too. I also like BSD license more for 
my code.

r.


From millman at berkeley.edu  Fri Feb  8 05:31:43 2008
From: millman at berkeley.edu (Jarrod Millman)
Date: Fri, 8 Feb 2008 02:31:43 -0800
Subject: [SciPy-dev] David's build_with_scons branch merged!
Message-ID: <c7009a550802080231t2a507512qa9a03fccb0bf66f8@mail.gmail.com>

Hello,

In preparation for the upcoming NumPy 1.0.5 release, I just merged
David Cournapeau's build_with_scons branch:
http://projects.scipy.org/scipy/numpy/changeset/4773

The current build system using numpy.distutils is still the default.
NumPy does not include numscons; this merge adds scons support to
numpy.distutils, provides some scons scripts, and modifies the
configuration of numpy/core.  David has extensively tested these
changes and I did a very quick sanity check to make sure I didn't
completely break everything.

Obviously, we will need to push back the 1.0.5 release date again to
ensure that there is sufficient testing.  So please test these changes
and let us know if you have any problems (or successes).

David has been putting in a considerable effort over the last several
months in developing numscons.  If you are interested in the
advantages to Davids approach, please read the description here:
http://projects.scipy.org/scipy/numpy/wiki/NumpyScons

Thanks,

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/


From nwagner at iam.uni-stuttgart.de  Fri Feb  8 12:51:11 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Fri, 08 Feb 2008 18:51:11 +0100
Subject: [SciPy-dev] Trouble with installing scipy from svn
Message-ID: <web-96173094@uni-stuttgart.de>

Hi all,

I cannot install scipy from svn due to

In file included from 
/usr/local/lib64/python2.5/site-packages/numpy/core/include/numpy/arrayobject.h:14,
                  from scipy/cluster/src/vq.h:6,
                  from scipy/cluster/src/vq.c:11:
/usr/local/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:16:25: 
error: numpyconfig.h: No such file or directory
In file included from 
/usr/local/lib64/python2.5/site-packages/numpy/core/include/numpy/arrayobject.h:14,
                  from scipy/cluster/src/vq.h:6,
                  from scipy/cluster/src/vq.c:11:
/usr/local/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:16:25: 
error: numpyconfig.h: No such file or directory
error: Command "gcc -pthread -fno-strict-aliasing -DNDEBUG 
-O2 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -g -fPIC 
-I/usr/local/lib64/python2.5/site-packages/numpy/core/include 
-I/usr/local/lib64/python2.5/site-packages/numpy/core/include 
-I/usr/include/python2.5 -c scipy/cluster/src/vq.c -o 
build/temp.linux-x86_64-2.5/scipy/cluster/src/vq.o" failed 
with exit status 1

Nils
  


From cburns at berkeley.edu  Fri Feb  8 15:27:41 2008
From: cburns at berkeley.edu (Christopher Burns)
Date: Fri, 8 Feb 2008 12:27:41 -0800
Subject: [SciPy-dev] Trouble with installing scipy from svn
In-Reply-To: <web-96173094@uni-stuttgart.de>
References: <web-96173094@uni-stuttgart.de>
Message-ID: <764e38540802081227w4a9f20e0m9ba0143b7f2f2fa1@mail.gmail.com>

numpyconfig.h was not being installed.  I added this to numpy/core/setup.py.

This got me a bit further in the build before failing on the error
below.  UFUNC_NOFPE is defined in the source file ufuncobject.h, but
appears to be removed from this header when it's installed.  Anyone
have any insight on this?

scipy/special/_cephesmodule.c: In function 'init_cephes':
scipy/special/_cephesmodule.c:1084: error: 'UFUNC_NOFPE' undeclared
(first use in this function)
...
error: Command "gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g
-pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC
-fPIC -I/home/cburns/local/lib64/python2.5/site-packages/numpy/core/include
-I/usr/include/python2.5 -c scipy/special/_cephesmodule.c -o
build/temp.linux-x86_64-2.5/scipy/special/_cephesmodule.o" failed with
exit status 1

On Feb 8, 2008 9:51 AM, Nils Wagner <nwagner at iam.uni-stuttgart.de> wrote:
> Hi all,
>
> I cannot install scipy from svn due to
>
> In file included from
> /usr/local/lib64/python2.5/site-packages/numpy/core/include/numpy/arrayobject.h:14,
>                   from scipy/cluster/src/vq.h:6,
>                   from scipy/cluster/src/vq.c:11:
> /usr/local/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:16:25:
> error: numpyconfig.h: No such file or directory
> In file included from
> /usr/local/lib64/python2.5/site-packages/numpy/core/include/numpy/arrayobject.h:14,
>                   from scipy/cluster/src/vq.h:6,
>                   from scipy/cluster/src/vq.c:11:
> /usr/local/lib64/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:16:25:
> error: numpyconfig.h: No such file or directory
> error: Command "gcc -pthread -fno-strict-aliasing -DNDEBUG
> -O2 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -g -fPIC
> -I/usr/local/lib64/python2.5/site-packages/numpy/core/include
> -I/usr/local/lib64/python2.5/site-packages/numpy/core/include
> -I/usr/include/python2.5 -c scipy/cluster/src/vq.c -o
> build/temp.linux-x86_64-2.5/scipy/cluster/src/vq.o" failed
> with exit status 1
>
> Nils
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>



-- 
Christopher Burns, Software Engineer
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/


From david at ar.media.kyoto-u.ac.jp  Sat Feb  9 07:45:24 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Sat, 09 Feb 2008 21:45:24 +0900
Subject: [SciPy-dev] Trouble with installing scipy from svn
In-Reply-To: <764e38540802081227w4a9f20e0m9ba0143b7f2f2fa1@mail.gmail.com>
References: <web-96173094@uni-stuttgart.de>
	<764e38540802081227w4a9f20e0m9ba0143b7f2f2fa1@mail.gmail.com>
Message-ID: <47ADA064.9060600@ar.media.kyoto-u.ac.jp>

Christopher Burns wrote:
> numpyconfig.h was not being installed.  I added this to numpy/core/setup.py.
>
> This got me a bit further in the build before failing on the error
> below.  UFUNC_NOFPE is defined in the source file ufuncobject.h, but
> appears to be removed from this header when it's installed.  Anyone
> have any insight on this?
>
> scipy/special/_cephesmodule.c: In function 'init_cephes':
> scipy/special/_cephesmodule.c:1084: error: 'UFUNC_NOFPE' undeclared
> (first use in this function)
> ...
> error: Command "gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g
> -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
> --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC
> -fPIC -I/home/cburns/local/lib64/python2.5/site-packages/numpy/core/include
> -I/usr/include/python2.5 -c scipy/special/_cephesmodule.c -o
> build/temp.linux-x86_64-2.5/scipy/special/_cephesmodule.o" failed with
> exit status 1
>   
I cannot reproduce this. Did you remove formerly installed numpy/scipy 
before installing the new ones ?

cheers,

David


From nwagner at iam.uni-stuttgart.de  Sat Feb  9 13:21:01 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Sat, 09 Feb 2008 19:21:01 +0100
Subject: [SciPy-dev] Kronecker sum of sparse matrices
Message-ID: <web-96264751@uni-stuttgart.de>

Hi all,

I have written a function for the Kronecker sum
of sparse matrices. It is meant for
http://projects.scipy.org/scipy/scipy/ticket/313


def spkronsum(a,b):
     """kronecker sum of a and b

     Kronecker sum of two sparse matrices is a sum
     of two Kronecker products kron(I_m,a)+kron(b,I_n)

     Inputs:

       a -- An n x n sparse matrix.
       b -- An m x m sparse matrix
     """
     m,n = b.get_shape()
     p,q = a.get_shape()

     if p != q:
         raise ValueError, 'expected square matrix'

     if m != n:
         raise ValueError, 'expected square matrix'

     return spkron(speye(m,n),a)+spkron(b,speye(p,q))


Cheers,
           Nils


>>> B = coo_matrix([[1.+1j,2],[3,4-1j]])
>>> print B
   (0, 0)        (1.0+1.0j)
   (0, 1)        (2.0+0.0j)
   (1, 0)        (3.0+0.0j)
   (1, 1)        (4.0+-1.0j)


The last entry in B contains a typo "+-"




From wnbell at gmail.com  Sat Feb  9 16:12:18 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Sat, 9 Feb 2008 15:12:18 -0600
Subject: [SciPy-dev] Kronecker sum of sparse matrices
In-Reply-To: <web-96264751@uni-stuttgart.de>
References: <web-96264751@uni-stuttgart.de>
Message-ID: <d05265cb0802091312h574d049fo6361af9aab8aaa9a@mail.gmail.com>

On Feb 9, 2008 12:21 PM, Nils Wagner <nwagner at iam.uni-stuttgart.de> wrote:
> Hi all,
>
> I have written a function for the Kronecker sum
> of sparse matrices. It is meant for
> http://projects.scipy.org/scipy/scipy/ticket/313
>
>

scipy.sparse.kronsum added in r3910

-- 
Nathan Bell wnbell at gmail.com
http://graphics.cs.uiuc.edu/~wnbell/


From aisaac at american.edu  Sat Feb  9 18:50:11 2008
From: aisaac at american.edu (Alan G Isaac)
Date: Sat, 9 Feb 2008 18:50:11 -0500
Subject: [SciPy-dev] Fwd: bug in argmax?
Message-ID: <Mahogany-0.67.0-948-20080209-185011.00@american.edu>

Is the behavior below a bug, as I believe?
(Two different types claim to be numpy.int32.)
If so, I will open a ticket.

Thank you,
Alan Isaac



------ Forwarded message ------

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as N 
>>> N.__version__ 
'1.0.4'
>>> test1=N.int32(32)
>>> type(test1)
<type 'numpy.int32'>
>>> type(test1) is N.int32 
True
>>> id(type(test1))
1810419616
>>> test2 = N.array([3,2,1]).argmax()
>>> type(test2)
<type 'numpy.int32'>
>>> type(test2) is N.int32 
False
>>> id(type(test2))
1810419808

-------- End of message -------




From nwagner at iam.uni-stuttgart.de  Sun Feb 10 04:53:30 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Sun, 10 Feb 2008 10:53:30 +0100
Subject: [SciPy-dev] sparse kronsum
Message-ID: <web-96303868@uni-stuttgart.de>

Hi Nathan,

Thank you very much for implementing kronsum !

I just tried it out. print does not work
for matrices given in block sparse row format.
  
B = coo_matrix([[1.+1j,2],[3,4-1j]])
print B results in
   (0, 0)        (1.0+1.0j)
   (0, 1)        (2.0+0.0j)
   (1, 0)        (3.0+0.0j)
   (1, 1)        (4.0+-1.0j)

Please note that there are two signs in the last entry.
It should be 4.0-1.0j instead of 4.0+-1.0j.


/usr/bin/python -i test_spkronsum.py
   (0, 0)        (1.0+1.0j)
   (0, 1)        (2.0+0.0j)
   (1, 0)        (3.0+0.0j)
   (1, 1)        (4.0+0.0j)
   (0, 0)        (1.0+1.0j)
   (0, 1)        (2.0+0.0j)
   (1, 0)        (3.0+0.0j)
   (1, 1)        (4.0+-1.0j)
[[ 2.+2.j  2.+0.j  2.+0.j  0.+0.j]
  [ 3.+0.j  5.+1.j  0.+0.j  2.+0.j]
  [ 3.+0.j  0.+0.j  5.+0.j  2.+0.j]
  [ 0.+0.j  3.+0.j  3.+0.j  8.-1.j]]
Traceback (most recent call last):
   File "test_spkronsum.py", line 11, in ?
     print G
   File 
"/usr/lib/python2.4/site-packages/scipy/sparse/base.py", 
line 167, in __str__
     val = val + self.listprint(0, nnz)
   File 
"/usr/lib/python2.4/site-packages/scipy/sparse/base.py", 
line 148, in listprint
     return '\n'.join(['  %s\t%s' % (self.rowcol(ind), 
self.getdata(ind))
   File 
"/usr/lib/python2.4/site-packages/scipy/sparse/bsr.py", 
line 269, in getdata
     raise NotImplementedError
NotImplementedError
  

Cheers,
           Nils
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_spkronsum.py
Type: text/x-python
Size: 179 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080210/36d2b635/attachment.py>

From wnbell at gmail.com  Sun Feb 10 17:53:38 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Sun, 10 Feb 2008 16:53:38 -0600
Subject: [SciPy-dev] sparse kronsum
In-Reply-To: <web-96303868@uni-stuttgart.de>
References: <web-96303868@uni-stuttgart.de>
Message-ID: <d05265cb0802101453w3aad9e50m10407eeb98892e52@mail.gmail.com>

On Feb 10, 2008 3:53 AM, Nils Wagner <nwagner at iam.uni-stuttgart.de> wrote:

> I just tried it out. print does not work
> for matrices given in block sparse row format.
>
> B = coo_matrix([[1.+1j,2],[3,4-1j]])
> print B results in
>    (0, 0)        (1.0+1.0j)
>    (0, 1)        (2.0+0.0j)
>    (1, 0)        (3.0+0.0j)
>    (1, 1)        (4.0+-1.0j)

Fixed in r3912.  It should work for all sparse classes now.

> Please note that there are two signs in the last entry.
> It should be 4.0-1.0j instead of 4.0+-1.0j.

That appears to be a numpy oddity (bug?):

In [23]: str(array([1 - 3j]))
Out[23]: '[ 1.-3.j]'

In [24]: str(array([1 - 3j])[0])
Out[24]: '(1.0+-3.0j)'

In [55]: complex128(1 - 3j)
Out[55]: (1.0+-3.0j)


-- 
Nathan Bell wnbell at gmail.com
http://graphics.cs.uiuc.edu/~wnbell/


From cimrman3 at ntc.zcu.cz  Mon Feb 11 05:52:55 2008
From: cimrman3 at ntc.zcu.cz (Robert Cimrman)
Date: Mon, 11 Feb 2008 11:52:55 +0100
Subject: [SciPy-dev] [Fwd:  umfpack scikit]
Message-ID: <47B02907.4050704@ntc.zcu.cz>

Did the message below got in? I cannot commit to scikits using my usual 
username 'rc' and the password.

$ svn commit umfpack/

Adding         umfpack
Authentication realm: <http://svn.scipy.org:80> scipy.org
Password for 'rc':
Authentication realm: <http://svn.scipy.org:80> scipy.org
Username: rc
Password for 'rc':
Authentication realm: <http://svn.scipy.org:80> scipy.org
Username: rc
Password for 'rc':
svn: Commit failed (details follow):
svn: CHECKOUT of '/svn/scikits/!svn/ver/855/trunk': authorization failed 
(http://svn.scipy.org)

r.

-------- Original Message --------
Subject: [SciPy-dev] umfpack scikit
Date: Thu, 07 Feb 2008 14:34:19 +0100
From: Robert Cimrman <cimrman3 at ntc.zcu.cz>
Reply-To: SciPy Developers List <scipy-dev at scipy.org>
To: SciPy Developers List <scipy-dev at scipy.org>

Hi,

I have the first version of the scikit ready but it seems I have not
rights to commit (username 'rc'). Can somebody help please?

Concerning the umfpack files from scipy.splinalg.dsolve, I would let
them in place for some transition period. I will add something like the
code below to linsolve.py:

--
if isUmfpack and noScikit:
      warn( 'scipy.splinalg.dsolve.umfpack has moved, install
scikits.umfpack instead', DeprecationWarning )
--

The scikit now contains the same code that was in
scipy.splinalg.dsolve.umfpack, I did not include the GPL-ed umfpack
sources. What is your opinion?

1. Let the wrappers BSD and install umfpack libraries separately as it
is now,
2. or include everything and change the scikit license to GPL.

I am more for option 1., as on my system (Gentoo Linux) umfpack
libraries exist as a standard package and the installation is trivial.
This is IMHO true on other systems too. I also like BSD license more for
my code.

r.
_______________________________________________
Scipy-dev mailing list
Scipy-dev at scipy.org
http://projects.scipy.org/mailman/listinfo/scipy-dev



From nmarais at sun.ac.za  Mon Feb 11 11:50:33 2008
From: nmarais at sun.ac.za (Neilen Marais)
Date: Mon, 11 Feb 2008 16:50:33 +0000 (UTC)
Subject: [SciPy-dev] Sparse feature suggestion: zero-sized sparse matrices
Message-ID: <fopucp$1f8$1@ger.gmane.org>

Hi,

This kind of ties in to the sparse block matrix assembly I brought up 
last week. I build up the sparse blocks from different subsystems, but in 
some cases some of the subsystems fall away. It would be very convenient 
if I could represent the "null" systems simply as zero-sized sparse 
matrices that will then make no contribution to the global matrix. 

It seems normal numpy arrays support the idea of zero-dimension 2-D 
arrays. Would anyone object to this feature in sparse matrices? If not, I 
could try to cook up a patch.

Thanks
Neilen



From wnbell at gmail.com  Mon Feb 11 12:09:49 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Mon, 11 Feb 2008 11:09:49 -0600
Subject: [SciPy-dev] Sparse feature suggestion: zero-sized sparse
	matrices
In-Reply-To: <fopucp$1f8$1@ger.gmane.org>
References: <fopucp$1f8$1@ger.gmane.org>
Message-ID: <d05265cb0802110909o2f874d1fi2ad727e2d037af00@mail.gmail.com>

On Feb 11, 2008 10:50 AM, Neilen Marais <nmarais at sun.ac.za> wrote:
>
> This kind of ties in to the sparse block matrix assembly I brought up
> last week. I build up the sparse blocks from different subsystems, but in
> some cases some of the subsystems fall away. It would be very convenient
> if I could represent the "null" systems simply as zero-sized sparse
> matrices that will then make no contribution to the global matrix.
>
> It seems normal numpy arrays support the idea of zero-dimension 2-D
> arrays. Would anyone object to this feature in sparse matrices? If not, I
> could try to cook up a patch.

You're welcome to try, but I think it would be a nightmare to implement.

I would only object if the necessary changes introduced a large number
of statements of the form

  if shape[0] == 0:
     do strange thing
  else:
     do normal thing

because that sort of thing is difficult to maintain.

On the other hand, there may be a comprehensive solution that resolves
such matters in a simple and consistent way.

-- 
Nathan Bell wnbell at gmail.com
http://graphics.cs.uiuc.edu/~wnbell/


From nmarais at sun.ac.za  Mon Feb 11 13:13:05 2008
From: nmarais at sun.ac.za (Neilen Marais)
Date: Mon, 11 Feb 2008 18:13:05 +0000 (UTC)
Subject: [SciPy-dev] Sparse feature suggestion: zero-sized
	sparse	matrices
References: <fopucp$1f8$1@ger.gmane.org>
	<d05265cb0802110909o2f874d1fi2ad727e2d037af00@mail.gmail.com>
Message-ID: <foq37h$1f8$3@ger.gmane.org>

Hi,

On Mon, 11 Feb 2008 11:09:49 -0600, Nathan Bell wrote:

> On Feb 11, 2008 10:50 AM, Neilen Marais <nmarais at sun.ac.za> wrote:

>> It seems normal numpy arrays support the idea of zero-dimension 2-D
>> arrays. Would anyone object to this feature in sparse matrices? If not,
>> I could try to cook up a patch.
> 
> You're welcome to try, but I think it would be a nightmare to implement.
> 
> I would only object if the necessary changes introduced a large number
> of statements of the form
> 
>   if shape[0] == 0:
>      do strange thing
>   else:
>      do normal thing
> 
> because that sort of thing is difficult to maintain.
> 
> On the other hand, there may be a comprehensive solution that resolves
> such matters in a simple and consistent way.

I'll have a looksee soon. Thanks for the heads-up :)

Regards
Neilen



From millman at berkeley.edu  Tue Feb 12 04:38:45 2008
From: millman at berkeley.edu (Jarrod Millman)
Date: Tue, 12 Feb 2008 01:38:45 -0800
Subject: [SciPy-dev] umfpack scikit
In-Reply-To: <47AB08DB.1080100@ntc.zcu.cz>
References: <47AB08DB.1080100@ntc.zcu.cz>
Message-ID: <c7009a550802120138w6561fe30re737287dec0c120c@mail.gmail.com>

On Feb 7, 2008 5:34 AM, Robert Cimrman <cimrman3 at ntc.zcu.cz> wrote:
> I have the first version of the scikit ready but it seems I have not
> rights to commit (username 'rc'). Can somebody help please?

You should have access now.  Let me know if it doesn't work.

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/


From wnbell at gmail.com  Tue Feb 12 20:59:33 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Tue, 12 Feb 2008 19:59:33 -0600
Subject: [SciPy-dev] matlab.io squeezes by default
Message-ID: <d05265cb0802121759p2899e015p73c785c66e7c0e57@mail.gmail.com>

I noticed that scipy.io.loadmat() had squeeze_me=True set by default.
Was there a compelling reason for this default choice?  I would think
that most people expect (1,N) matrices and (N,1) matrices to retain
their shapes when loaded.  Here's a simple example that illustrates
the problem.

from scipy.testing import *
from scipy import array, matrix
from scipy.io import savemat, loadmat

A = matrix([[1,2,3]])
B = matrix([[1],[2],[3]])

X = {'A' : A, 'B' : B }

savemat('temp.mat', X )

#Y = loadmat('temp.mat', squeeze_me=False)  # preserves shape
Y = loadmat('temp.mat')  #does not preserve shape

assert_equal( Y['A'], A)
assert_equal( Y['B'], B)



For now, I have changed the default to squeeze_me=False.

-- 
Nathan Bell wnbell at gmail.com
http://graphics.cs.uiuc.edu/~wnbell/


From matthew.brett at gmail.com  Tue Feb 12 21:51:58 2008
From: matthew.brett at gmail.com (Matthew Brett)
Date: Wed, 13 Feb 2008 02:51:58 +0000
Subject: [SciPy-dev] matlab.io squeezes by default
In-Reply-To: <d05265cb0802121759p2899e015p73c785c66e7c0e57@mail.gmail.com>
References: <d05265cb0802121759p2899e015p73c785c66e7c0e57@mail.gmail.com>
Message-ID: <1e2af89e0802121851h715e9b45q2555831e270e2646@mail.gmail.com>

Hi,

The compelling reason was only that that was the behavior that we
inherited from the original scipy.io.loadmat

It's probably better for that not to happen, but I imagine the change
will break some code.

Matthew

On Feb 13, 2008 1:59 AM, Nathan Bell <wnbell at gmail.com> wrote:
> I noticed that scipy.io.loadmat() had squeeze_me=True set by default.
> Was there a compelling reason for this default choice?  I would think
> that most people expect (1,N) matrices and (N,1) matrices to retain
> their shapes when loaded.  Here's a simple example that illustrates
> the problem.
>
> from scipy.testing import *
> from scipy import array, matrix
> from scipy.io import savemat, loadmat
>
> A = matrix([[1,2,3]])
> B = matrix([[1],[2],[3]])
>
> X = {'A' : A, 'B' : B }
>
> savemat('temp.mat', X )
>
> #Y = loadmat('temp.mat', squeeze_me=False)  # preserves shape
> Y = loadmat('temp.mat')  #does not preserve shape
>
> assert_equal( Y['A'], A)
> assert_equal( Y['B'], B)
>
>
>
> For now, I have changed the default to squeeze_me=False.
>
> --
> Nathan Bell wnbell at gmail.com
> http://graphics.cs.uiuc.edu/~wnbell/
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>


From wnbell at gmail.com  Thu Feb 14 03:42:57 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Thu, 14 Feb 2008 02:42:57 -0600
Subject: [SciPy-dev] better sparse slicing
Message-ID: <d05265cb0802140042r242c845ft3feb6b3912641248@mail.gmail.com>

I've expanded on Robert C's earlier efforts in improving the state of
sparse slicing.

Previously you could do
A[1]
A[1:2]
A[1:2,1]
A[1:2,1:2]

Now you can do:
A[[1,2]]
A[1:2,[1,2]]
A[[1,2],1:2]
A[[1,2],[1,2]]

and the all important:
A[[1,2],:][:,[1,2]]


Currently this only works for csr_matrix (and not csc_matrix).  Once I
trust my csr_matrix implementation I'll make csc_matrix work also.
The above operations should mimic numpy.matrix exactly.

-- 
Nathan Bell wnbell at gmail.com
http://graphics.cs.uiuc.edu/~wnbell/


From cimrman3 at ntc.zcu.cz  Thu Feb 14 04:15:23 2008
From: cimrman3 at ntc.zcu.cz (Robert Cimrman)
Date: Thu, 14 Feb 2008 10:15:23 +0100
Subject: [SciPy-dev] better sparse slicing
In-Reply-To: <d05265cb0802140042r242c845ft3feb6b3912641248@mail.gmail.com>
References: <d05265cb0802140042r242c845ft3feb6b3912641248@mail.gmail.com>
Message-ID: <47B406AB.10302@ntc.zcu.cz>

Nathan Bell wrote:
> I've expanded on Robert C's earlier efforts in improving the state of
> sparse slicing.
> 
> Previously you could do
> A[1]
> A[1:2]
> A[1:2,1]
> A[1:2,1:2]
> 
> Now you can do:
> A[[1,2]]
> A[1:2,[1,2]]
> A[[1,2],1:2]
> A[[1,2],[1,2]]

Great!

> and the all important:
> A[[1,2],:][:,[1,2]]

This needs some more range checking...

In [3]: a = sp.csr_matrix( [[1,0,1,0],[0,1,2,3]] )
In [5]: print a
   (0, 0)        1
   (0, 2)        1
   (1, 1)        1
   (1, 2)        2
   (1, 3)        3
In [6]: a[[1,2],:][:,[1,2]]
Segmentation fault

> 
> Currently this only works for csr_matrix (and not csc_matrix).  Once I
> trust my csr_matrix implementation I'll make csc_matrix work also.
> The above operations should mimic numpy.matrix exactly.

Many thanks for this, Nathan.

r.


From lesommer at hmg.inpg.fr  Fri Feb 15 07:44:58 2008
From: lesommer at hmg.inpg.fr (Julien Le Sommer)
Date: Fri, 15 Feb 2008 13:44:58 +0100
Subject: [SciPy-dev] Probs with numpy/scipy on Itanium 64Bit with Intel
	Compilers with SCSL libs.
Message-ID: <ab93c7300802150444n3f151426v342f93c8d66fcdba@mail.gmail.com>

Hello,

We are working hard to compile scipy on our box. We have already sent
a post on this list but so far we haven't managed to install scipy yet, see
:
http://projects.scipy.org/pipermail/scipy-dev/2007-November/007998.html

here is the problem : we are trying to compile numpy/scipy with
intel compilers on a box of itanium processors with the SCSL library.

the problem is that both numpy and scipy seem to loose track of the
fortran compiler configuration during their build_ext phase even though
this configuration is recognized during the build_clib phase, giving this
log message.

customize IntelItaniumFCompiler

warning: build_ext: f77_compiler=intele is not available.


the prob is the same when python has been compiled with gcc or with intel c
compiler.

the prob doesn't seems to be related to scsl lib at all but only to the
handling of intel
compiler for Itanium .

some help would be much appreciated. In particular, is there a Intel/Itanium
implementation
of scipy/numpy somewhere that we could get some information about ?

thanks for your help


-- 
   Julien Le Sommer, LEGI/MEOM,
   BP53, 38041 Grenoble cedex 9, France
   Tel : +33 4 76 82 50 65
   Fax : +33 4 76 82 52 71
   http://www.legi.hmg.inpg.fr/~lesommer/<http://www.legi.hmg.inpg.fr/%7Elesommer/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080215/1d10c38b/attachment.html>

From david at ar.media.kyoto-u.ac.jp  Fri Feb 15 07:49:03 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Fri, 15 Feb 2008 21:49:03 +0900
Subject: [SciPy-dev] Probs with numpy/scipy on Itanium 64Bit with Intel
 Compilers with SCSL libs.
In-Reply-To: <ab93c7300802150444n3f151426v342f93c8d66fcdba@mail.gmail.com>
References: <ab93c7300802150444n3f151426v342f93c8d66fcdba@mail.gmail.com>
Message-ID: <47B58A3F.6050708@ar.media.kyoto-u.ac.jp>

Julien Le Sommer wrote:
> Hello,
>
> We are working hard to compile scipy on our box. We have already sent
> a post on this list but so far we haven't managed to install scipy 
> yet, see :
> http://projects.scipy.org/pipermail/scipy-dev/2007-November/007998.html 
> <http://projects.scipy.org/pipermail/scipy-dev/2007-November/007998.html>
>
> here is the problem : we are trying to compile numpy/scipy with
> intel compilers on a box of itanium processors with the SCSL library.
>
> the problem is that both numpy and scipy seem to loose track of the
> fortran compiler configuration during their build_ext phase even though
> this configuration is recognized during the build_clib phase, giving this
> log message.
>
>     customize IntelItaniumFCompiler
>
>     warning: build_ext: f77_compiler=intele is not available.
>
>
> the prob is the same when python has been compiled with gcc or with 
> intel c compiler.
>
> the prob doesn't seems to be related to scsl lib at all but only to 
> the handling of intel
> compiler for Itanium .
>
> some help would be much appreciated. In particular, is there a 
> Intel/Itanium implementation
> of scipy/numpy somewhere that we could get some information about ?
>

If you could give one of us a shell access to a computer where 
everything is installed to build numpy/scipy on an itanium, it would be 
much easier to solve the problem,

cheers,

David


From nwagner at iam.uni-stuttgart.de  Fri Feb 15 17:03:40 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Fri, 15 Feb 2008 23:03:40 +0100
Subject: [SciPy-dev] Complex sparse matrices
Message-ID: <web-96761464@uni-stuttgart.de>

Hi all,

How do I assign complex values to a sparse lil matrix

The following code doesn't work

from scipy import sparse
from scipy.splinalg import spsolve, use_solver
from numpy import linalg, ones
from numpy.random import rand
A = sparse.lil_matrix((3, 3),complex)
A.setdiag(ones(3)+1j*ones(3))
A = A.tocsr()
print A
print A.real()
print A.imag()


The imaginary part is missing

/usr/bin/python -i test_complex.py
   (0, 0)        1.0
   (1, 1)        1.0
   (2, 2)        1.0

and I get

Traceback (most recent call last):
   File "test_complex.py", line 9, in ?
     print A.real()
   File 
"/usr/lib/python2.4/site-packages/scipy/sparse/csr.py", 
line 99, in __getattr__
     return _cs_matrix.__getattr__(self, attr)
   File 
"/usr/lib/python2.4/site-packages/scipy/sparse/base.py", 
line 310, in __getattr__
     return self._real()
   File 
"/usr/lib/python2.4/site-packages/scipy/sparse/data.py", 
line 30, in _real
     return 
self._with_data(numpy.real(self.data),copy=False)
NameError: global name 'numpy' is not defined

I am using
>>> import scipy
>>> scipy.__version__
'0.7.0.dev3942'
>>> import numpy
>>> numpy.__version__
'1.0.5.dev4807'


From nwagner at iam.uni-stuttgart.de  Sat Feb 16 15:21:47 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Sat, 16 Feb 2008 21:21:47 +0100
Subject: [SciPy-dev] Difference between  A = sparse.lil_matrix((3, 3),
 dtype=complex) and A = sparse.lil_matrix((3, 3), complex)
Message-ID: <web-96807952@uni-stuttgart.de>

Hi all,

Can someone explain the difference between

A = sparse.lil_matrix((3, 3),dtype=complex) and

A = sparse.lil_matrix((3, 3),complex)

The first definition produces a complex matrix while
the second one results in a  r e a l  matrix.

This is counterintuitive.


In [1]: from scipy import sparse

In [2]: A = sparse.lil_matrix((3, 3),complex)

In [3]: A
Out[3]:
<3x3 sparse matrix of type '<type 'numpy.float64'>'
         with 0 stored elements in LInked List format>

In [4]: A = sparse.lil_matrix((3, 3),dtype=complex)

In [5]: A
Out[5]:
<3x3 sparse matrix of type '<type 'numpy.complex128'>'
         with 0 stored elements in LInked List format>


Cheers,
            Nils


From wnbell at gmail.com  Sat Feb 16 15:43:04 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Sat, 16 Feb 2008 14:43:04 -0600
Subject: [SciPy-dev] Difference between A = sparse.lil_matrix((3, 3),
	dtype=complex) and A = sparse.lil_matrix((3, 3), complex)
In-Reply-To: <web-96807952@uni-stuttgart.de>
References: <web-96807952@uni-stuttgart.de>
Message-ID: <d05265cb0802161243p33123b3fmffeee2bf6f56b7a6@mail.gmail.com>

On Feb 16, 2008 2:21 PM, Nils Wagner <nwagner at iam.uni-stuttgart.de> wrote:
> Hi all,
>
> Can someone explain the difference between
>
> A = sparse.lil_matrix((3, 3),dtype=complex) and
>
> A = sparse.lil_matrix((3, 3),complex)
>
> The first definition produces a complex matrix while
> the second one results in a  r e a l  matrix.
>
> This is counterintuitive.

The latter case, 'complex' is being assigned to the shape= argument
(which was ignored).  This usage now raises an exception.

You should always use keyword= for keyword arguments instead of
relying on their order.

-- 
Nathan Bell wnbell at gmail.com
http://graphics.cs.uiuc.edu/~wnbell/


From nwagner at iam.uni-stuttgart.de  Sat Feb 16 15:51:33 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Sat, 16 Feb 2008 21:51:33 +0100
Subject: [SciPy-dev] Difference between A = sparse.lil_matrix((3, 3) ,
 dtype=complex) and A = sparse.lil_matrix((3, 3), complex)
In-Reply-To: <d05265cb0802161243p33123b3fmffeee2bf6f56b7a6@mail.gmail.com>
References: <web-96807952@uni-stuttgart.de>
	<d05265cb0802161243p33123b3fmffeee2bf6f56b7a6@mail.gmail.com>
Message-ID: <web-96809750@uni-stuttgart.de>

On Sat, 16 Feb 2008 14:43:04 -0600
  "Nathan Bell" <wnbell at gmail.com> wrote:
> On Feb 16, 2008 2:21 PM, Nils Wagner 
><nwagner at iam.uni-stuttgart.de> wrote:
>> Hi all,
>>
>> Can someone explain the difference between
>>
>> A = sparse.lil_matrix((3, 3),dtype=complex) and
>>
>> A = sparse.lil_matrix((3, 3),complex)
>>
>> The first definition produces a complex matrix while
>> the second one results in a  r e a l  matrix.
>>
>> This is counterintuitive.
> 
> The latter case, 'complex' is being assigned to the 
>shape= argument
> (which was ignored).  This usage now raises an 
>exception.
> 
> You should always use keyword= for keyword arguments 
>instead of
> relying on their order.
> 
> -- 
> Nathan Bell wnbell at gmail.com
> http://graphics.cs.uiuc.edu/~wnbell/
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev

Hi Nathan,

Thank you very much for the explanation.

Nils



From pav at iki.fi  Mon Feb 18 18:12:06 2008
From: pav at iki.fi (Pauli Virtanen)
Date: Mon, 18 Feb 2008 23:12:06 +0000 (UTC)
Subject: [SciPy-dev] ZVODE, a Double Precision Complex ODE Solver
References: <457D0AFA.60203@iam.uni-stuttgart.de>
Message-ID: <fpd3c6$tl7$1@ger.gmane.org>

Hi,

Mon, 11 Dec 2006 08:38:34 +0100, Nils Wagner wrote:
> This might be of interest.
> 
[clip]
> From: Alan Hindmarsh <alanh at llnl.gov> Date: Wed, 6 Dec 2006 18:20:32
> -0500
> Subject: ZVODE, a Double Precision Complex ODE Solver
> 
> Of the many solvers freely available for ODE initial value problems,
> there seem to be very few, if any, for the case of double precision
> complex dependent variables, even though there have been occasional user
> calls for this functionality.  (Of course a complex system can be
> treated as a real system of twice the size, but direct treatment as a
> complex system is preferable.)  I have provided such a solver: ZVODE.

I wrote a wrapper for this some time ago along, including testcases. Is 
there interest in having this in scipy trunk?

The code is posted in scipy ticket #334, and I can easily re-diff it 
against current scipy trunk if needed.

-- 
Pauli Virtanen



From tisham at apogee.com.au  Mon Feb 18 19:11:43 2008
From: tisham at apogee.com.au (Tisham Dhar)
Date: Tue, 19 Feb 2008 10:41:43 +1030
Subject: [SciPy-dev] Extension to PilUtil for inverse radon
Message-ID: <7FE299E133F3104AA71E94D1850057891A4B52@APOGEESRV.ApogeeImaging.local>

Hi All,

We have added a small inverse radon transform to Pilutil(in scipy/misc),
it goes along with the forward radon transform already there. The file
is below.

# Functions which need the PIL

import types
import numpy

from numpy import amin, amax, ravel, asarray, cast, arange, \
     ones, newaxis, transpose, mgrid, iscomplexobj, sum, zeros, uint8

import math
import Image
import ImageFilter

__all__ = ['fromimage','toimage','imsave','imread','bytescale',
 
'imrotate','imresize','imshow','imfilter','radon','inv_radon']

# Returns a byte-scaled image
def bytescale(data, cmin=None, cmax=None, high=255, low=0):
    if data.dtype is uint8:
        return data
    high = high - low
    if cmin is None:
        cmin = amin(ravel(data))
    if cmax is None:
        cmax = amax(ravel(data))
    scale = high *1.0 / (cmax-cmin or 1)
    bytedata = ((data*1.0-cmin)*scale + 0.4999).astype(uint8)
    return bytedata + cast[uint8](low)

def imread(name,flatten=0):
    """Read an image file from a filename.

    Optional arguments:

     - flatten (0): if true, the image is flattened by calling
convert('F') on
     the resulting image object.  This flattens the color layers into a
single
     grayscale layer.
    """

    im = Image.open(name)
    return fromimage(im,flatten=flatten)

def imsave(name, arr):
    """Save an array to an image file.
    """
    im = toimage(arr)
    im.save(name)
    return

def fromimage(im, flatten=0):
    """Takes a PIL image and returns a copy of the image in a numpy
container.
    If the image is RGB returns a 3-dimensional array:  arr[:,:,n] is
each channel

    Optional arguments:

    - flatten (0): if true, the image is flattened by calling
convert('F') on
    the image object before extracting the numerical data.  This
flattens the
    color layers into a single grayscale layer.  Note that the supplied
image
    object is NOT modified.
    """
    assert Image.isImageType(im), "Not a PIL image."
    if flatten:
        im = im.convert('F')
    mode = im.mode
    adjust = 0
    if mode == '1':
        im = im.convert(mode='L')
        mode = 'L'
        adjust = 1
    str = im.tostring()
    type = uint8
    if mode == 'F':
        type = numpy.float32
    elif mode == 'I':
        type = numpy.uint32
    elif mode == 'I;16':
        type = numpy.uint16
    arr = numpy.fromstring(str,type)
    shape = list(im.size)
    shape.reverse()
    if mode == 'P':
        arr.shape = shape
        if im.palette.rawmode != 'RGB':
            print "Warning: Image has invalid palette."
            return arr
        pal = numpy.fromstring(im.palette.data,type)
        N = len(pal)
        pal.shape = (int(N/3.0),3)
        return arr, pal
    if mode in ['RGB','YCbCr']:
        shape += [3]
    elif mode in ['CMYK','RGBA']:
        shape += [4]
    arr.shape = shape
    if adjust:
        arr = (arr != 0)
    return arr

_errstr = "Mode is unknown or incompatible with input array shape."
def toimage(arr,high=255,low=0,cmin=None,cmax=None,pal=None,
            mode=None,channel_axis=None):
    """Takes a numpy array and returns a PIL image.  The mode of the
    PIL image depends on the array shape, the pal keyword, and the mode
    keyword.

    For 2-D arrays, if pal is a valid (N,3) byte-array giving the RGB
values
    (from 0 to 255) then mode='P', otherwise mode='L', unless mode is
given
    as 'F' or 'I' in which case a float and/or integer array is made

    For 3-D arrays, the channel_axis argument tells which dimension of
the
      array holds the channel data.
    For 3-D arrays if one of the dimensions is 3, the mode is 'RGB'
      by default or 'YCbCr' if selected.
    if the

    The numpy array must be either 2 dimensional or 3 dimensional.
    """
    data = asarray(arr)
    if iscomplexobj(data):
        raise ValueError, "Cannot convert a complex-valued array."
    shape = list(data.shape)
    valid = len(shape)==2 or ((len(shape)==3) and \
                              ((3 in shape) or (4 in shape)))
    assert valid, "Not a suitable array shape for any mode."
    if len(shape) == 2:
        shape = (shape[1],shape[0]) # columns show up first
        if mode == 'F':
            data32 = data.astype(numpy.float32)
            image = Image.fromstring(mode,shape,data32.tostring())
            return image
        if mode in [None, 'L', 'P']:
            bytedata =
bytescale(data,high=high,low=low,cmin=cmin,cmax=cmax)
            image = Image.fromstring('L',shape,bytedata.tostring())
            if pal is not None:
                image.putpalette(asarray(pal,dtype=uint8).tostring())
                # Becomes a mode='P' automagically.
            elif mode == 'P':  # default gray-scale
                pal = arange(0,256,1,dtype=uint8)[:,newaxis] * \
                      ones((3,),dtype=uint8)[newaxis,:]
                image.putpalette(asarray(pal,dtype=uint8).tostring())
            return image
        if mode == '1':  # high input gives threshold for 1
            bytedata = (data > high)
            image = Image.fromstring('1',shape,bytedata.tostring())
            return image
        if cmin is None:
            cmin = amin(ravel(data))
        if cmax is None:
            cmax = amax(ravel(data))
        data = (data*1.0 - cmin)*(high-low)/(cmax-cmin) + low
        if mode == 'I':
            data32 = data.astype(numpy.uint32)
            image = Image.fromstring(mode,shape,data32.tostring())
        else:
            raise ValueError, _errstr
        return image

    # if here then 3-d array with a 3 or a 4 in the shape length.
    # Check for 3 in datacube shape --- 'RGB' or 'YCbCr'
    if channel_axis is None:
        if (3 in shape):
            ca = numpy.flatnonzero(asarray(shape) == 3)[0]
        else:
            ca = numpy.flatnonzero(asarray(shape) == 4)
            if len(ca):
                ca = ca[0]
            else:
                raise ValueError, "Could not find channel dimension."
    else:
        ca = channel_axis

    numch = shape[ca]
    if numch not in [3,4]:
        raise ValueError, "Channel axis dimension is not valid."

    bytedata = bytescale(data,high=high,low=low,cmin=cmin,cmax=cmax)
    if ca == 2:
        strdata = bytedata.tostring()
        shape = (shape[1],shape[0])
    elif ca == 1:
        strdata = transpose(bytedata,(0,2,1)).tostring()
        shape = (shape[2],shape[0])
    elif ca == 0:
        strdata = transpose(bytedata,(1,2,0)).tostring()
        shape = (shape[2],shape[1])
    if mode is None:
        if numch == 3: mode = 'RGB'
        else: mode = 'RGBA'


    if mode not in ['RGB','RGBA','YCbCr','CMYK']:
        raise ValueError, _errstr

    if mode in ['RGB', 'YCbCr']:
        assert numch == 3, "Invalid array shape for mode."
    if mode in ['RGBA', 'CMYK']:
        assert numch == 4, "Invalid array shape for mode."

    # Here we know data and mode is coorect
    image = Image.fromstring(mode, shape, strdata)
    return image

def imrotate(arr,angle,interp='bilinear'):
    """Rotate an image counter-clockwise by angle degrees.

    Interpolation methods can be:
        'nearest' :  for nearest neighbor
        'bilinear' : for bilinear
        'cubic' or 'bicubic' : for bicubic
    """
    arr = asarray(arr)
    func = {'nearest':0,'bilinear':2,'bicubic':3,'cubic':3}
    im = toimage(arr)
    im = im.rotate(angle,resample=func[interp])
    return fromimage(im)

def imresize(arr,newsize,interp='bilinear',mode=None):
    newsize=list(newsize)
    newsize.reverse()
    newsize = tuple(newsize)
    arr = asarray(arr)
    func = {'nearest':0,'bilinear':2,'bicubic':3,'cubic':3}
    im = toimage(arr,mode=mode)
    im = im.resize(newsize,resample=func[interp])
    return fromimage(im)

def imshow(arr):
    """Simple showing of an image through an external viewer.
    """
    im = toimage(arr)
    if (len(arr.shape) == 3) and (arr.shape[2] == 4):
        try:
            import os
            im.save('/tmp/scipy_imshow.png')
            if os.system("(xv /tmp/scipy_imshow.png; rm -f
/tmp/scipy_imshow.png)&"):
                raise RuntimeError
            return
        except:
            print "Warning: Alpha channel may not be handled correctly."

    im.show()
    return

def imresize(arr,size):
    """Resize an image.

    If size is an integer it is a percentage of current size.
    If size is a float it is a fraction of current size.
    If size is a tuple it is the size of the output image.
    """
    im = toimage(arr)
    ts = type(size)
    if ts is types.IntType:
        size = size / 100.0
    if type(size) is types.FloatType:
        size = (im.size[0]*size,im.size[1]*size)
    else:
        size = (size[1],size[0])
    imnew = im.resize(size)
    return fromimage(imnew)


def imfilter(arr,ftype):
    """Simple filtering of an image.

    type can be:
            'blur', 'contour', 'detail', 'edge_enhance',
'edge_enhance_more',
            'emboss', 'find_edges', 'smooth', 'smooth_more', 'sharpen'
    """
    _tdict = {'blur':ImageFilter.BLUR,
              'contour':ImageFilter.CONTOUR,
              'detail':ImageFilter.DETAIL,
              'edge_enhance':ImageFilter.EDGE_ENHANCE,
              'edge_enhance_more':ImageFilter.EDGE_ENHANCE_MORE,
              'emboss':ImageFilter.EMBOSS,
              'find_edges':ImageFilter.FIND_EDGES,
              'smooth':ImageFilter.SMOOTH,
              'smooth_more':ImageFilter.SMOOTH_MORE,
              'sharpen':ImageFilter.SHARPEN
              }

    im = toimage(arr)
    if ftype not in _tdict.keys():
        raise ValueError, "Unknown filter type."
    return fromimage(im.filter(_tdict[ftype]))


def radon(arr,theta=None):
    if theta is None:
        theta = mgrid[0:180]
    s = zeros((arr.shape[1],len(theta)), float)
    k = 0
    for th in theta:
        im = imrotate(arr,-th)
        s[:,k] = sum(im,axis=0)
        k += 1
    return s

def inv_radon(arr):
    theta = mgrid[0:arr.shape[1]]
    th = (math.pi/180)*theta

    #set up the image
    m = arr.shape[1]
    n = arr.shape[0]-1
    inv = zeros( (n, n), int)
    
    #set up x and y matices
    midindex = (n+1)/2
    xy = mgrid[1:n+1,1:n+1]
    xpr = xy[1]-(n+1)/2
    ypr = xy[0]-(n+1)/2

    for l in theta:
        filtrindex = numpy.array(midindex +
xpr*math.sin(th[l])-ypr*math.cos(th[l])).round()
        inva=zeros((n,n))
        spota=numpy.where((filtrindex > 0) & (filtrindex <= n))
        newfiltindex=numpy.array(filtrindex[spota],int)   
        inva[spota]=arr[newfiltindex[:],l]
        inv=inv+inva
    return inv/m

Regards,

Tishampati Dhar

 Remote Sensing Software Developer

 APOGEE IMAGING INTERNATIONAL

 Building 12B

 1 Adelaide - Lobethal Road 

 Lobethal SA 5241 

  Telephone: +61 - 8 - 8389 5499

 Fax: +61 - 8 - 8389 5488

 Mobile: +61 - 406114165

Email: tisham at apogee.com.au mailto:tisham at apogee.com.au>

Web: www.apogee.com.au <http://www.apogee.com.au> 

 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

"The information in this e-mail may be confidential and/or commercially
privileged. It is intended solely for the addressee. Access to this
e-mail by anyone else is unauthorised. If you are not the
intendedrecipient, any disclosure, copying, distribution or action taken
or omitted to be taken in reliance on it, is prohibited and may be
unlawful."



From oliphant at enthought.com  Mon Feb 18 21:56:40 2008
From: oliphant at enthought.com (Travis E. Oliphant)
Date: Mon, 18 Feb 2008 20:56:40 -0600
Subject: [SciPy-dev] ZVODE, a Double Precision Complex ODE Solver
In-Reply-To: <fpd3c6$tl7$1@ger.gmane.org>
References: <457D0AFA.60203@iam.uni-stuttgart.de> <fpd3c6$tl7$1@ger.gmane.org>
Message-ID: <47BA4568.3040901@enthought.com>


> The code is posted in scipy ticket #334, and I can easily re-diff it 
> against current scipy trunk if needed.
>
>   

Could you do the re diff?   It would be great.   Sorry, the ticket did 
not get seen earlier.


-Travis O.





From ondrej at certik.cz  Mon Feb 18 21:59:22 2008
From: ondrej at certik.cz (Ondrej Certik)
Date: Tue, 19 Feb 2008 03:59:22 +0100
Subject: [SciPy-dev] ZVODE, a Double Precision Complex ODE Solver
In-Reply-To: <47BA4568.3040901@enthought.com>
References: <457D0AFA.60203@iam.uni-stuttgart.de> <fpd3c6$tl7$1@ger.gmane.org>
	<47BA4568.3040901@enthought.com>
Message-ID: <85b5c3130802181859h2d40d37w93a38187763a56dd@mail.gmail.com>

On Feb 19, 2008 3:56 AM, Travis E. Oliphant <oliphant at enthought.com> wrote:
>
> > The code is posted in scipy ticket #334, and I can easily re-diff it
> > against current scipy trunk if needed.
> >
> >
>
> Could you do the re diff?   It would be great.   Sorry, the ticket did
> not get seen earlier.

There definitely is a demand, see for example this recent wishlist in Debian:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466392

Ondrej


From anand.prabhakar.patil at gmail.com  Mon Feb 18 22:14:46 2008
From: anand.prabhakar.patil at gmail.com (Anand Patil)
Date: Mon, 18 Feb 2008 19:14:46 -0800
Subject: [SciPy-dev] Variogram code?
Message-ID: <2bc7a5a50802181914r1daa6cd9wee37120551dad03e@mail.gmail.com>

Hi all,

I have a small variogram module I'd like to make available. All it
does is compute directional variograms on the sphere. It has a little
bit of fortran code. Questions:

- Should I be making an effort to interface with any code in the stats module?

- The output is essentially a list of bar-graph components. On my
computer, I have a function that uses matplotlib to actually plot the
variograms. Should I wrap the function in a try block, so that it will
be available if 'from pylab import *' works, or get rid of it?

- When making directional variograms, the code bins by bearing angle
rather than by atan2(delta long, delta lat). Is this the best way to
do it? The bearing angle seems to make more sense but
  - bearing(a,b) isn't necesarily equal to pi + bearing(b,a), so the
same pair can go in two different bins, and
  - the bins tend to look strange on a cylindrical projection if the
points are far apart.
I haven't been able to find much guidance in the literature.

- How should I package the module, and how can I get it to someone who
can put it in the repository?

Thanks,
Anand


From stefan at sun.ac.za  Tue Feb 19 14:47:03 2008
From: stefan at sun.ac.za (Stefan van der Walt)
Date: Tue, 19 Feb 2008 21:47:03 +0200
Subject: [SciPy-dev] splinalg naming
Message-ID: <20080219194703.GL29099@mentat.za.net>

Hi all,

I see the sparse linear algebra module is called scipy.splinalg.  Is
this naming preferred above scipy.sparse.linalg?

Regards
St?fan


From pav at iki.fi  Tue Feb 19 16:06:59 2008
From: pav at iki.fi (Pauli Virtanen)
Date: Tue, 19 Feb 2008 23:06:59 +0200
Subject: [SciPy-dev] ZVODE, a Double Precision Complex ODE Solver
In-Reply-To: <47BA4568.3040901@enthought.com>
References: <457D0AFA.60203@iam.uni-stuttgart.de>
	<fpd3c6$tl7$1@ger.gmane.org>  <47BA4568.3040901@enthought.com>
Message-ID: <1203455219.7760.9.camel@localhost.localdomain>

Hi,

ma, 2008-02-18 kello 20:56 -0600, Travis E. Oliphant kirjoitti:
> > The code is posted in scipy ticket #334, and I can easily re-diff it 
> > against current scipy trunk if needed.
> >
> >   
> 
> Could you do the re diff?   It would be great.   Sorry, the ticket did 
> not get seen earlier.

Rediffed against r3946 now, and everything in a single patch:

http://scipy.org/scipy/scipy/attachment/ticket/334/zvode-patch-combined.patch

Also includes an &rtol -> rtol fix for DVODE in the .pyf callstatement:
rtol is declared as dimension(*) in the .pyf and already a double*

-- 
Pauli Virtanen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digitaalisesti allekirjoitettu viestin osa
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080219/a28b67f6/attachment.sig>

From wnbell at gmail.com  Tue Feb 19 16:17:27 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Tue, 19 Feb 2008 15:17:27 -0600
Subject: [SciPy-dev] splinalg naming
In-Reply-To: <20080219194703.GL29099@mentat.za.net>
References: <20080219194703.GL29099@mentat.za.net>
Message-ID: <d05265cb0802191317h45c00e9bx41a43ea6fc1e4655@mail.gmail.com>

On Feb 19, 2008 1:47 PM, Stefan van der Walt <stefan at sun.ac.za> wrote:
> Hi all,
>
> I see the sparse linear algebra module is called scipy.splinalg.  Is
> this naming preferred above scipy.sparse.linalg?

There was a lengthy discussion about restructuring the sparse
functionality here:
http://thread.gmane.org/gmane.comp.python.scientific.devel/7070/focus=7080

-- 
Nathan Bell wnbell at gmail.com
http://graphics.cs.uiuc.edu/~wnbell/


From stefan at sun.ac.za  Tue Feb 19 16:43:04 2008
From: stefan at sun.ac.za (Stefan van der Walt)
Date: Tue, 19 Feb 2008 23:43:04 +0200
Subject: [SciPy-dev] splinalg naming
In-Reply-To: <d05265cb0802191317h45c00e9bx41a43ea6fc1e4655@mail.gmail.com>
References: <20080219194703.GL29099@mentat.za.net>
	<d05265cb0802191317h45c00e9bx41a43ea6fc1e4655@mail.gmail.com>
Message-ID: <20080219214304.GN29099@mentat.za.net>

Hi Nathan

On Tue, Feb 19, 2008 at 03:17:27PM -0600, Nathan Bell wrote:
> On Feb 19, 2008 1:47 PM, Stefan van der Walt <stefan at sun.ac.za> wrote:
> > Hi all,
> >
> > I see the sparse linear algebra module is called scipy.splinalg.  Is
> > this naming preferred above scipy.sparse.linalg?
> 
> There was a lengthy discussion about restructuring the sparse
> functionality here:
>
> http://thread.gmane.org/gmane.comp.python.scientific.devel/7070/focus=7080

Thanks for the pointer.  I read the thread now, but it doesn't look as
if scipy.sparse.linalg was considered -- and I mention this in
relation to the recent post on scipy.sparse.eye etc.

I'm just curious as to the motivation behind the name (currently, it
looks like it is meant to distinguish between dense and sparse linear
algebra, but I suppose scipy.sparse.linalg would have done that as
well).

The new structure looks good -- thanks for all the effort you put it!

Regards
St?fan


From wnbell at gmail.com  Tue Feb 19 16:59:52 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Tue, 19 Feb 2008 15:59:52 -0600
Subject: [SciPy-dev] splinalg naming
In-Reply-To: <20080219214304.GN29099@mentat.za.net>
References: <20080219194703.GL29099@mentat.za.net>
	<d05265cb0802191317h45c00e9bx41a43ea6fc1e4655@mail.gmail.com>
	<20080219214304.GN29099@mentat.za.net>
Message-ID: <d05265cb0802191359q1dcf53c6w1777fc2e07d9131c@mail.gmail.com>

On Feb 19, 2008 3:43 PM, Stefan van der Walt <stefan at sun.ac.za> wrote:

> I'm just curious as to the motivation behind the name (currently, it
> looks like it is meant to distinguish between dense and sparse linear
> algebra, but I suppose scipy.sparse.linalg would have done that as
> well).

That's true.  I'm not married to the name splinalg, so I wouldn't
object to a change.

Where have you been for the last month? :)

-- 
Nathan Bell wnbell at gmail.com
http://graphics.cs.uiuc.edu/~wnbell/


From ondrej at certik.cz  Tue Feb 19 18:10:12 2008
From: ondrej at certik.cz (Ondrej Certik)
Date: Wed, 20 Feb 2008 00:10:12 +0100
Subject: [SciPy-dev] ZVODE, a Double Precision Complex ODE Solver
In-Reply-To: <1203455219.7760.9.camel@localhost.localdomain>
References: <457D0AFA.60203@iam.uni-stuttgart.de> <fpd3c6$tl7$1@ger.gmane.org>
	<47BA4568.3040901@enthought.com>
	<1203455219.7760.9.camel@localhost.localdomain>
Message-ID: <85b5c3130802191510m6b7a2cdel31c237733c1ce9a2@mail.gmail.com>

On Feb 19, 2008 10:06 PM, Pauli Virtanen <pav at iki.fi> wrote:
> Hi,
>
> ma, 2008-02-18 kello 20:56 -0600, Travis E. Oliphant kirjoitti:
> > > The code is posted in scipy ticket #334, and I can easily re-diff it
> > > against current scipy trunk if needed.
> > >
> > >
> >
> > Could you do the re diff?   It would be great.   Sorry, the ticket did
> > not get seen earlier.
>
> Rediffed against r3946 now, and everything in a single patch:
>
> http://scipy.org/scipy/scipy/attachment/ticket/334/zvode-patch-combined.patch
>
> Also includes an &rtol -> rtol fix for DVODE in the .pyf callstatement:
> rtol is declared as dimension(*) in the .pyf and already a double*

Thanks very much for doing this. I think similar patches with new
functionality are extremely important
for scipy.

Ondrej


From aisaac at american.edu  Wed Feb 20 00:43:26 2008
From: aisaac at american.edu (Alan G Isaac)
Date: Wed, 20 Feb 2008 00:43:26 -0500
Subject: [SciPy-dev] Variogram code?
In-Reply-To: <2bc7a5a50802181914r1daa6cd9wee37120551dad03e@mail.gmail.com>
References: <2bc7a5a50802181914r1daa6cd9wee37120551dad03e@mail.gmail.com>
Message-ID: <Mahogany-0.67.0-796-20080220-004326.00@american.edu>

On Mon, 18 Feb 2008, Anand Patil apparently wrote:
> - The output is essentially a list of bar-graph components. On my 
> computer, I have a function that uses matplotlib to actually plot the 
> variograms. Should I wrap the function in a try block, so that it will 
> be available if 'from pylab import *' works, or get rid of it? 

I do not see any reason not to provide that function.
Just do not call it; leave that to the user.
The try block should therefore be in the function body.
(Or you can try when the module is loaded and condition
the function on a global that is set at loading.)

> - How should I package the module, and how can I get it to someone who 
> can put it in the repository? 

Unfortunately, the procedure for this does not seem well 
established.

Do you have a way to provide easy download to would-be users 
and interested developers?

Alternatively, this might be good grist for the Cookbook 
mill:
<URL:http://www.scipy.org/Cookbook>

Cheers,
Alan Isaac





From dmitrey.kroshko at scipy.org  Wed Feb 20 03:16:08 2008
From: dmitrey.kroshko at scipy.org (dmitrey)
Date: Wed, 20 Feb 2008 10:16:08 +0200
Subject: [SciPy-dev] numpy upgrade for enthon next version
Message-ID: <47BBE1C8.2030305@scipy.org>

hi all,
does anyone know when numpy 0.9.x from latest enthon release will be 
updated to something more up-to-date?
I'm asking because scikits.openopt don't work with the numpy version 
mentioned, because it fails with "can't import abs from numpy". I think 
there's rather lot number of people who tried using openopt but turned 
away to something else because fail to install & run it with Windows + 
enthon. BTW, I had tried to install more recent numpy version by myself 
and some errors were obtained, so I guess an ordinary user will 
futhermore fail as well and switch to something else. (mb scons will 
simplify the process in future).
I guess it's valid not only for openopt but for lots of other 
numpy-related soft (at least, using numpy.abs()) as well.
Regards, D.



From kriehl at enthought.com  Wed Feb 20 13:54:03 2008
From: kriehl at enthought.com (Katrina Riehl)
Date: Wed, 20 Feb 2008 12:54:03 -0600
Subject: [SciPy-dev] numpy upgrade for enthon next version
In-Reply-To: <47BBE1C8.2030305@scipy.org>
References: <47BBE1C8.2030305@scipy.org>
Message-ID: <47BC774B.5070902@enthought.com>


We are updating to numpy 1.0.4.  Unfortunately, we don't have an exact 
timeline when everything will be available.  We are focusing a great 
deal of effort to update the ETPLib (Enthought Third Party Library, 
formerly enthon) right now.  We should have a release available soon.

Thanks,
Katrina

dmitrey wrote:
> hi all,
> does anyone know when numpy 0.9.x from latest enthon release will be 
> updated to something more up-to-date?
> I'm asking because scikits.openopt don't work with the numpy version 
> mentioned, because it fails with "can't import abs from numpy". I think 
> there's rather lot number of people who tried using openopt but turned 
> away to something else because fail to install & run it with Windows + 
> enthon. BTW, I had tried to install more recent numpy version by myself 
> and some errors were obtained, so I guess an ordinary user will 
> futhermore fail as well and switch to something else. (mb scons will 
> simplify the process in future).
> I guess it's valid not only for openopt but for lots of other 
> numpy-related soft (at least, using numpy.abs()) as well.
> Regards, D.
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
>   



From nwagner at iam.uni-stuttgart.de  Wed Feb 20 14:31:15 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Wed, 20 Feb 2008 20:31:15 +0100
Subject: [SciPy-dev] Tickets
Message-ID: <web-97081422@uni-stuttgart.de>

Hi all,

IMHO, the following tickets can be closed

http://projects.scipy.org/scipy/scipy/ticket/313
http://projects.scipy.org/scipy/scipy/ticket/513
http://projects.scipy.org/scipy/scipy/ticket/534
http://projects.scipy.org/scipy/scipy/ticket/556
http://projects.scipy.org/scipy/scipy/ticket/588


Nils


From nwagner at iam.uni-stuttgart.de  Wed Feb 20 15:23:23 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Wed, 20 Feb 2008 21:23:23 +0100
Subject: [SciPy-dev] More tickets
Message-ID: <web-97083639@uni-stuttgart.de>

Hi Nathan,
  
Thank you for closing the tickets.

How about

http://projects.scipy.org/scipy/scipy/ticket/314

IIRC, io.read_array is deprecated.

And
http://projects.scipy.org/scipy/scipy/ticket/525
No problem here.

Nils


From wnbell at gmail.com  Wed Feb 20 18:48:43 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Wed, 20 Feb 2008 17:48:43 -0600
Subject: [SciPy-dev] More tickets
In-Reply-To: <web-97083639@uni-stuttgart.de>
References: <web-97083639@uni-stuttgart.de>
Message-ID: <d05265cb0802201548h7f2f9f13l489d02dfa6a3ce2e@mail.gmail.com>

On Wed, Feb 20, 2008 at 2:23 PM, Nils Wagner
<nwagner at iam.uni-stuttgart.de> wrote:
>  And
>  http://projects.scipy.org/scipy/scipy/ticket/525
>  No problem here.

No one has followed up on this issue, so I think we should at least
wait until the release of 0.7.0 before closing the ticket.

-- 
Nathan Bell wnbell at gmail.com
http://graphics.cs.uiuc.edu/~wnbell/


From anand.prabhakar.patil at gmail.com  Wed Feb 20 22:51:37 2008
From: anand.prabhakar.patil at gmail.com (Anand Patil)
Date: Wed, 20 Feb 2008 19:51:37 -0800
Subject: [SciPy-dev] Variogram code?
In-Reply-To: <Mahogany-0.67.0-796-20080220-004326.00@american.edu>
References: <2bc7a5a50802181914r1daa6cd9wee37120551dad03e@mail.gmail.com>
	<Mahogany-0.67.0-796-20080220-004326.00@american.edu>
Message-ID: <2bc7a5a50802201951u636effdbra7e4fd2e129fdb77@mail.gmail.com>

Alan,

The cookbook looks like the right place for it, actually. I'll do that.

Anand


From dmitrey.kroshko at scipy.org  Thu Feb 21 13:36:01 2008
From: dmitrey.kroshko at scipy.org (dmitrey)
Date: Thu, 21 Feb 2008 20:36:01 +0200
Subject: [SciPy-dev] f2py + f90 file
Message-ID: <47BDC491.8010501@scipy.org>

hi all,
I have an .f90 file with a routine that I intend to connect to Python 
via f2py

(the file is http://users.bigpond.net.au/amiller/bvls.f90 )

I have gfortran and f95 installed (KUBUNTU 7.10), *no f90* (f90 is 
absent in KUBUNTU software update channel as well).

Both they work with the file correctly, so I can get both a.out and 
bvlc.o (however I don't know how to get *.so files)

So f2py -c -m bvls bvls.f90 yields:
...
Fortran f77 compiler: /usr/bin/g77 -g -Wall -fno-second-underscore -fPIC 
-O3 -funroll-loops -march=athlon64 -mmmx -m3dnow -msse2 -msse
compile options: '-I/tmp/tmpK2eM1Z/src.linux-x86_64-2.5 
-I/usr/lib/python2.5/site-packages/numpy/core/include 
-I/usr/include/python2.5 -c'
error: f90 not supported by GnuFCompiler needed for bvls.f90

if I rename the file extension to f95 I have the same problem:
error: f90 not supported by GnuFCompiler needed for bvls.f95

Any suggestions?
Thank you in advance, D.


From pearu at cens.ioc.ee  Thu Feb 21 13:43:20 2008
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Thu, 21 Feb 2008 20:43:20 +0200 (EET)
Subject: [SciPy-dev] f2py + f90 file
In-Reply-To: <47BDC491.8010501@scipy.org>
References: <47BDC491.8010501@scipy.org>
Message-ID: <62589.85.166.22.159.1203619400.squirrel@cens.ioc.ee>

On Thu, February 21, 2008 8:36 pm, dmitrey wrote:
> hi all,
> I have an .f90 file with a routine that I intend to connect to Python
> via f2py
>
> (the file is http://users.bigpond.net.au/amiller/bvls.f90 )
>
> I have gfortran and f95 installed (KUBUNTU 7.10), *no f90* (f90 is
> absent in KUBUNTU software update channel as well).
>
> Both they work with the file correctly, so I can get both a.out and
> bvlc.o (however I don't know how to get *.so files)
>
> So f2py -c -m bvls bvls.f90 yields:
> ...
> Fortran f77 compiler: /usr/bin/g77 -g -Wall -fno-second-underscore -fPIC
> -O3 -funroll-loops -march=athlon64 -mmmx -m3dnow -msse2 -msse
> compile options: '-I/tmp/tmpK2eM1Z/src.linux-x86_64-2.5
> -I/usr/lib/python2.5/site-packages/numpy/core/include
> -I/usr/include/python2.5 -c'
> error: f90 not supported by GnuFCompiler needed for bvls.f90
>
> if I rename the file extension to f95 I have the same problem:
> error: f90 not supported by GnuFCompiler needed for bvls.f95
>
> Any suggestions?

You need to specify F90 complier explicitly (default compiler
for f2py is g77):

  f2py -c -m bvls bvls.f90 --fcompiler=gnu95

HTH,
Pearu



From charlesr.harris at gmail.com  Thu Feb 21 15:32:42 2008
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Thu, 21 Feb 2008 13:32:42 -0700
Subject: [SciPy-dev] splinalg naming
In-Reply-To: <d05265cb0802191359q1dcf53c6w1777fc2e07d9131c@mail.gmail.com>
References: <20080219194703.GL29099@mentat.za.net>
	<d05265cb0802191317h45c00e9bx41a43ea6fc1e4655@mail.gmail.com>
	<20080219214304.GN29099@mentat.za.net>
	<d05265cb0802191359q1dcf53c6w1777fc2e07d9131c@mail.gmail.com>
Message-ID: <e06186140802211232t5eb579edmb69f6981d147de27@mail.gmail.com>

On Tue, Feb 19, 2008 at 2:59 PM, Nathan Bell <wnbell at gmail.com> wrote:

> On Feb 19, 2008 3:43 PM, Stefan van der Walt <stefan at sun.ac.za> wrote:
>
> > I'm just curious as to the motivation behind the name (currently, it
> > looks like it is meant to distinguish between dense and sparse linear
> > algebra, but I suppose scipy.sparse.linalg would have done that as
> > well).
>
> That's true.  I'm not married to the name splinalg, so I wouldn't
> object to a change.
>

It always takes me a moment to translate splin from "spline" to "sparse
linear". I think a more obvious name would be a good idea.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080221/8c362a26/attachment.html>

From wnbell at gmail.com  Thu Feb 21 15:53:13 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Thu, 21 Feb 2008 14:53:13 -0600
Subject: [SciPy-dev] splinalg naming
In-Reply-To: <e06186140802211232t5eb579edmb69f6981d147de27@mail.gmail.com>
References: <20080219194703.GL29099@mentat.za.net>
	<d05265cb0802191317h45c00e9bx41a43ea6fc1e4655@mail.gmail.com>
	<20080219214304.GN29099@mentat.za.net>
	<d05265cb0802191359q1dcf53c6w1777fc2e07d9131c@mail.gmail.com>
	<e06186140802211232t5eb579edmb69f6981d147de27@mail.gmail.com>
Message-ID: <d05265cb0802211253x64648cdg29873532f522c204@mail.gmail.com>

On Thu, Feb 21, 2008 at 2:32 PM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
> It always takes me a moment to translate splin from "spline" to "sparse
> linear". I think a more obvious name would be a good idea.

Fair enough.  Would anyone object to moving scipy.splinalg to
scipy.sparse.linalg?

If there are no objections I'll make the change within a few days.

-- 
Nathan Bell wnbell at gmail.com
http://graphics.cs.uiuc.edu/~wnbell/


From dmitrey.kroshko at scipy.org  Tue Feb 26 04:38:51 2008
From: dmitrey.kroshko at scipy.org (dmitrey)
Date: Tue, 26 Feb 2008 11:38:51 +0200
Subject: [SciPy-dev] f2py + f90 file
In-Reply-To: <62589.85.166.22.159.1203619400.squirrel@cens.ioc.ee>
References: <47BDC491.8010501@scipy.org>
	<62589.85.166.22.159.1203619400.squirrel@cens.ioc.ee>
Message-ID: <47C3DE2B.8000201@scipy.org>

Pearu, I have spent several days trying to connect bvls.f and/or 
bvls.f90 routines (linear least squares, box-bounded), but it still 
doesn't yield correct results: they are different according to input 
precision (float32, float64, float128) and noone yields correct solution 
- neither for finite nor for infinite bounds.

Could you take a look at the files?
http://www.box.net/shared/1gaauhrcoo

This problem is the one of big importance (and very urgent), because
1) lots of users are interested in constrained LLS problems (AFAIK there 
are no Python-connected solvers for the ones, at least, free solvers)
2) it could essentially enhance scikits.openopt lincher and ralg solvers.

The attached script yields:

using bvls.f
Type: float32 ; xf= [ 0.  0.] ; type(xf[0])= <type 'numpy.float32'>
Type: float64 ; xf= [  1. -Inf] ; type(xf[0])= <type 'numpy.float64'>
Type: float128 ; xf= [0.0 0.0] ; type(xf[0])= <type 'numpy.float128'>

using bvls.f90
Type: float32 ; xf= [ 0. -0.] ; type(xf[0])= <type 'numpy.float32'>
Type: float64 ; xf= [ 0. -0.] ; type(xf[0])= <type 'numpy.float32'>
Type: float128 ; xf= [ 0. -0.] ; type(xf[0])= <type 'numpy.float32'>

(while xf should be [15,15])

Thank you in advance,
D.

Pearu Peterson wrote:
> On Thu, February 21, 2008 8:36 pm, dmitrey wrote:
>   
>> hi all,
>> I have an .f90 file with a routine that I intend to connect to Python
>> via f2py
>>
>> (the file is http://users.bigpond.net.au/amiller/bvls.f90 )
>>
>> I have gfortran and f95 installed (KUBUNTU 7.10), *no f90* (f90 is
>> absent in KUBUNTU software update channel as well).
>>
>> Both they work with the file correctly, so I can get both a.out and
>> bvlc.o (however I don't know how to get *.so files)
>>
>> So f2py -c -m bvls bvls.f90 yields:
>> ...
>> Fortran f77 compiler: /usr/bin/g77 -g -Wall -fno-second-underscore -fPIC
>> -O3 -funroll-loops -march=athlon64 -mmmx -m3dnow -msse2 -msse
>> compile options: '-I/tmp/tmpK2eM1Z/src.linux-x86_64-2.5
>> -I/usr/lib/python2.5/site-packages/numpy/core/include
>> -I/usr/include/python2.5 -c'
>> error: f90 not supported by GnuFCompiler needed for bvls.f90
>>
>> if I rename the file extension to f95 I have the same problem:
>> error: f90 not supported by GnuFCompiler needed for bvls.f95
>>
>> Any suggestions?
>>     
>
> You need to specify F90 complier explicitly (default compiler
> for f2py is g77):
>
>   f2py -c -m bvls bvls.f90 --fcompiler=gnu95
>
> HTH,
> Pearu
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
>
>
>   



From pearu at cens.ioc.ee  Tue Feb 26 04:52:54 2008
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 26 Feb 2008 11:52:54 +0200 (EET)
Subject: [SciPy-dev] f2py + f90 file
In-Reply-To: <47C3DE2B.8000201@scipy.org>
References: <47BDC491.8010501@scipy.org>
	<62589.85.166.22.159.1203619400.squirrel@cens.ioc.ee>
	<47C3DE2B.8000201@scipy.org>
Message-ID: <56269.85.166.22.159.1204019574.squirrel@cens.ioc.ee>

On Tue, February 26, 2008 11:38 am, dmitrey wrote:
> Pearu, I have spent several days trying to connect bvls.f and/or
> bvls.f90 routines (linear least squares, box-bounded), but it still
> doesn't yield correct results: they are different according to input
> precision (float32, float64, float128) and noone yields correct solution
> - neither for finite nor for infinite bounds.
>
> Could you take a look at the files?
> http://www.box.net/shared/1gaauhrcoo

Sure. Could you send also the .pyf file of the bvls module or a f2py command
line that you are using to wrap bvls?

Pearu



From dmitrey.kroshko at scipy.org  Tue Feb 26 05:01:42 2008
From: dmitrey.kroshko at scipy.org (dmitrey)
Date: Tue, 26 Feb 2008 12:01:42 +0200
Subject: [SciPy-dev] f2py + f90 file
In-Reply-To: <56269.85.166.22.159.1204019574.squirrel@cens.ioc.ee>
References: <47BDC491.8010501@scipy.org>	<62589.85.166.22.159.1203619400.squirrel@cens.ioc.ee>	<47C3DE2B.8000201@scipy.org>
	<56269.85.166.22.159.1204019574.squirrel@cens.ioc.ee>
Message-ID: <47C3E386.2060209@scipy.org>

I have seen the pyf-files appearing from time to time, but now they are 
absent (in the directory where I have used f2py), and do not appear 
after f2py using.

As for commands, I have used
f2py -c -m bvls bvls.f
and
f2py -c -m bvls bvls.f90 --fcompiler=gnu95

I have tried Linux KUBUNTU 7.10 and UBUNTU 7.04
AFAIK compilers used were gfortran and f95
HTH, D.


Pearu Peterson wrote:
> On Tue, February 26, 2008 11:38 am, dmitrey wrote:
>   
>> Pearu, I have spent several days trying to connect bvls.f and/or
>> bvls.f90 routines (linear least squares, box-bounded), but it still
>> doesn't yield correct results: they are different according to input
>> precision (float32, float64, float128) and noone yields correct solution
>> - neither for finite nor for infinite bounds.
>>
>> Could you take a look at the files?
>> http://www.box.net/shared/1gaauhrcoo
>>     
>
> Sure. Could you send also the .pyf file of the bvls module or a f2py command
> line that you are using to wrap bvls?
>
> Pearu
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
>
>
>   



From pearu at cens.ioc.ee  Tue Feb 26 05:16:59 2008
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 26 Feb 2008 12:16:59 +0200 (EET)
Subject: [SciPy-dev] f2py + f90 file
In-Reply-To: <47C3E386.2060209@scipy.org>
References: <47BDC491.8010501@scipy.org>	<62589.85.166.22.159.1203619400.squirrel@cens.ioc.ee>	<47C3DE2B.8000201@scipy.org>
	<56269.85.166.22.159.1204019574.squirrel@cens.ioc.ee>
	<47C3E386.2060209@scipy.org>
Message-ID: <56697.85.166.22.159.1204021019.squirrel@cens.ioc.ee>

On Tue, February 26, 2008 12:01 pm, dmitrey wrote:
> I have seen the pyf-files appearing from time to time, but now they are
> absent (in the directory where I have used f2py), and do not appear
> after f2py using.
>
> As for commands, I have used
> f2py -c -m bvls bvls.f
> and
> f2py -c -m bvls bvls.f90 --fcompiler=gnu95

Ok, thanks for the info. In general, it is recommended to use
a modified .pyf when wrapping Fortran functions with longish
argument list that may contain output-type arguments.
See f2py users guide for more information.

Below follows the content of a .pyf file that I have modified to
meet the docs of bvls.f (there are some room for improvements).
Then I used the following command line

  f2py -c bvls.pyf bvls.f

to build the bvls extension module. In test_bvls.py file I changed
the bvls.bvls call to

  xf,w,istate,loopa = bvls.bvls(a,b,bl,bu)

And, most importantly, set inf=100. Now I get the correct results:

using bvls.f
Type: float32 ;
xf= [ 15.  15.] ; type(xf[0])= <type 'numpy.float64'>
Type: float64 ;
xf= [ 15.  15.] ; type(xf[0])= <type 'numpy.float64'>
Type: float128 ;
xf= [ 15.  15.] ; type(xf[0])= <type 'numpy.float64'>

Btw, I believe that your approach of not using .pyf file
would also worked when not using inf as an bound parameter
- obviosly the underlying Fortran code is not designed
to handle float infinities.

HTH,
Pearu


!    -*- f90 -*-
! Note: the context of this file is case sensitive.
!FILE: bvls.pyf

python module bvls ! in
    interface  ! in :bvls
        subroutine bvls(key,m,n,a,b,bl,bu,x,w,act,zz,istate,loopa) ! in
:bvls:bvls.f
            integer :: key = 0
            integer optional,check(shape(a,0)==m),depend(a) :: m=shape(a,0)
            integer optional,check(shape(a,1)==n),depend(a) :: n=shape(a,1)
            double precision dimension(m,n) :: a
            double precision dimension(m),depend(m) :: b
            double precision dimension(n),depend(n) :: bl
            double precision dimension(n),depend(n) :: bu
            double precision dimension(n),depend(n),intent(out) :: x
            double precision dimension(n),depend(n),intent(out) :: w
            double precision dimension(m,m + 2),depend(m), intent(cache),
optional :: act
            double precision dimension(m),depend(m), intent(cache),
optional :: zz
            integer dimension(n + 1),depend(n),intent(out) :: istate
            integer intent(out) :: loopa
        end subroutine bvls
    end interface
end python module bvls

! This file was auto-generated with f2py (version:2_3744).
! See http://cens.ioc.ee/projects/f2py2e/




From dmitrey.kroshko at scipy.org  Tue Feb 26 05:43:54 2008
From: dmitrey.kroshko at scipy.org (dmitrey)
Date: Tue, 26 Feb 2008 12:43:54 +0200
Subject: [SciPy-dev] f2py + f90 file
In-Reply-To: <56697.85.166.22.159.1204021019.squirrel@cens.ioc.ee>
References: <47BDC491.8010501@scipy.org>	<62589.85.166.22.159.1203619400.squirrel@cens.ioc.ee>	<47C3DE2B.8000201@scipy.org>	<56269.85.166.22.159.1204019574.squirrel@cens.ioc.ee>	<47C3E386.2060209@scipy.org>
	<56697.85.166.22.159.1204021019.squirrel@cens.ioc.ee>
Message-ID: <47C3ED6A.7000200@scipy.org>

So I have tried the pyf-file attached but unfortunately it yields text 
output
using bvls.f
Type: float32 ;
and then nothing (for all finite-box bounded as well)

Fortunately, all-finite box-bounds now work correctly, but only for 
f77-version (with f2py -c -m bvls bvls.f) and numpy.float64 type:

using bvls.f
Type: float32 ;
xf= [ 0.  0.] ; type(xf[0])= <type 'numpy.float32'>
Type: float64 ;
xf= [ 15.  15.] ; type(xf[0])= <type 'numpy.float64'>
Type: float128 ;
xf= [0.0 0.0] ; type(xf[0])= <type 'numpy.float128'>

using bvls.f90
Type: float32 ;
xf= [ 0. -0.] ; type(xf[0])= <type 'numpy.float32'>
Type: float64 ;
xf= [ 0. -0.] ; type(xf[0])= <type 'numpy.float32'>
Type: float128 ;
xf= [ 0. -0.] ; type(xf[0])= <type 'numpy.float32'>

Ok, let's not use f90 version anymore.
But is it possible to make somehow bvls.f working correctly with other 
types then numpy.float64, i.e. with float32 and float128?

Regards, D.


Pearu Peterson wrote:
> On Tue, February 26, 2008 12:01 pm, dmitrey wrote:
>   
>> I have seen the pyf-files appearing from time to time, but now they are
>> absent (in the directory where I have used f2py), and do not appear
>> after f2py using.
>>
>> As for commands, I have used
>> f2py -c -m bvls bvls.f
>> and
>> f2py -c -m bvls bvls.f90 --fcompiler=gnu95
>>     
>
> Ok, thanks for the info. In general, it is recommended to use
> a modified .pyf when wrapping Fortran functions with longish
> argument list that may contain output-type arguments.
> See f2py users guide for more information.
>
> Below follows the content of a .pyf file that I have modified to
> meet the docs of bvls.f (there are some room for improvements).
> Then I used the following command line
>
>   f2py -c bvls.pyf bvls.f
>
> to build the bvls extension module. In test_bvls.py file I changed
> the bvls.bvls call to
>
>   xf,w,istate,loopa = bvls.bvls(a,b,bl,bu)
>
> And, most importantly, set inf=100. Now I get the correct results:
>
> using bvls.f
> Type: float32 ;
> xf= [ 15.  15.] ; type(xf[0])= <type 'numpy.float64'>
> Type: float64 ;
> xf= [ 15.  15.] ; type(xf[0])= <type 'numpy.float64'>
> Type: float128 ;
> xf= [ 15.  15.] ; type(xf[0])= <type 'numpy.float64'>
>
> Btw, I believe that your approach of not using .pyf file
> would also worked when not using inf as an bound parameter
> - obviosly the underlying Fortran code is not designed
> to handle float infinities.
>
> HTH,
> Pearu
>
>
> !    -*- f90 -*-
> ! Note: the context of this file is case sensitive.
> !FILE: bvls.pyf
>
> python module bvls ! in
>     interface  ! in :bvls
>         subroutine bvls(key,m,n,a,b,bl,bu,x,w,act,zz,istate,loopa) ! in
> :bvls:bvls.f
>             integer :: key = 0
>             integer optional,check(shape(a,0)==m),depend(a) :: m=shape(a,0)
>             integer optional,check(shape(a,1)==n),depend(a) :: n=shape(a,1)
>             double precision dimension(m,n) :: a
>             double precision dimension(m),depend(m) :: b
>             double precision dimension(n),depend(n) :: bl
>             double precision dimension(n),depend(n) :: bu
>             double precision dimension(n),depend(n),intent(out) :: x
>             double precision dimension(n),depend(n),intent(out) :: w
>             double precision dimension(m,m + 2),depend(m), intent(cache),
> optional :: act
>             double precision dimension(m),depend(m), intent(cache),
> optional :: zz
>             integer dimension(n + 1),depend(n),intent(out) :: istate
>             integer intent(out) :: loopa
>         end subroutine bvls
>     end interface
> end python module bvls
>
> ! This file was auto-generated with f2py (version:2_3744).
> ! See http://cens.ioc.ee/projects/f2py2e/
>
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
>
>   



From pearu at cens.ioc.ee  Tue Feb 26 06:07:10 2008
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 26 Feb 2008 13:07:10 +0200 (EET)
Subject: [SciPy-dev] f2py + f90 file
In-Reply-To: <47C3ED6A.7000200@scipy.org>
References: <47BDC491.8010501@scipy.org>	<62589.85.166.22.159.1203619400.squirrel@cens.ioc.ee>	<47C3DE2B.8000201@scipy.org>	<56269.85.166.22.159.1204019574.squirrel@cens.ioc.ee>	<47C3E386.2060209@scipy.org>
	<56697.85.166.22.159.1204021019.squirrel@cens.ioc.ee>
	<47C3ED6A.7000200@scipy.org>
Message-ID: <57377.85.166.22.159.1204024030.squirrel@cens.ioc.ee>

On Tue, February 26, 2008 12:43 pm, dmitrey wrote:
> So I have tried the pyf-file attached but unfortunately it yields text
> output
> using bvls.f
> Type: float32 ;
> and then nothing (for all finite-box bounded as well)

You can use --debug-capi to see where the processing stops.
May be you should skip float32 and try float64 case first.

> Fortunately, all-finite box-bounds now work correctly, but only for
> f77-version (with f2py -c -m bvls bvls.f) and numpy.float64 type:
>
> using bvls.f
> Type: float32 ;
> xf= [ 0.  0.] ; type(xf[0])= <type 'numpy.float32'>
> Type: float64 ;
> xf= [ 15.  15.] ; type(xf[0])= <type 'numpy.float64'>
> Type: float128 ;
> xf= [0.0 0.0] ; type(xf[0])= <type 'numpy.float128'>

> But is it possible to make somehow bvls.f working correctly with other
> types then numpy.float64, i.e. with float32 and float128?

The above results are expected. Note that by default all array arguments
are intent(in) and when using f2py as you do, the float64 result
is correct by accident (in the meaning that only in this case numpy
array can be passed directly to Fortran, in other cases a copy
is made and you cannot expect f2py to copy the computed results
back to original arrays if the intent(in) is specified).

Sure it is possible to make bvls.f work correctly with other
precision types but note that this involves making copies to float64
that the fortran function expects. To make it work, you have to
use the .pyf file and design it to be robust to all types.
I am afraid, you should use the .pyf file anyway in order to
make the results unaccidental.

Regards,
Pearu



From wnbell at gmail.com  Wed Feb 27 01:25:32 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Wed, 27 Feb 2008 00:25:32 -0600
Subject: [SciPy-dev] splinalg naming
In-Reply-To: <d05265cb0802211253x64648cdg29873532f522c204@mail.gmail.com>
References: <20080219194703.GL29099@mentat.za.net>
	<d05265cb0802191317h45c00e9bx41a43ea6fc1e4655@mail.gmail.com>
	<20080219214304.GN29099@mentat.za.net>
	<d05265cb0802191359q1dcf53c6w1777fc2e07d9131c@mail.gmail.com>
	<e06186140802211232t5eb579edmb69f6981d147de27@mail.gmail.com>
	<d05265cb0802211253x64648cdg29873532f522c204@mail.gmail.com>
Message-ID: <d05265cb0802262225u684c654m8bdfd7495f333b22@mail.gmail.com>

On Thu, Feb 21, 2008 at 2:53 PM, Nathan Bell <wnbell at gmail.com> wrote:
>
>  Fair enough.  Would anyone object to moving scipy.splinalg to
>  scipy.sparse.linalg?
>
>  If there are no objections I'll make the change within a few days.

As of r3960 scipy.splinalg is now scipy.sparse.linalg

-- 
Nathan Bell wnbell at gmail.com
http://graphics.cs.uiuc.edu/~wnbell/


From nwagner at iam.uni-stuttgart.de  Wed Feb 27 03:32:50 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Wed, 27 Feb 2008 09:32:50 +0100
Subject: [SciPy-dev] Scipy, numpy and Abaqus
In-Reply-To: <web-94411595@uni-stuttgart.de>
References: <2B00361EE3107A4F88383EC1B041DC9A02D71466@VFOHMLAO01.Enterprise.afmc.ds.af.mil>
	<web-94411595@uni-stuttgart.de>
Message-ID: <web-97437018@uni-stuttgart.de>

On Tue, 08 Jan 2008 20:01:34 +0100
  "Nils Wagner" <nwagner at iam.uni-stuttgart.de> wrote:
> On Tue, 8 Jan 2008 13:57:07 -0500
>  "Gilbert, Linda M CTR USAF AFRL/RXOC" 
> <Linda.Gilbert at WPAFB.AF.MIL> wrote:
>> 
>> 
>>> _____________________________________________ 
>>> From: 	Gilbert, Linda M CTR USAF AFRL/MLOC  
>>> Sent:	Thursday, January 03, 2008 11:01 AM
>>> To:	'scipy-dev at scipy.org'; 'pearu at cens.ioc.ee'
>>> Subject:	Scipy, numpy and Abaqus
>>> 
>>> Hello,
>>> 
>>> Do you know how to get numpy and scipy to work from 
>>>within abaqus?
>>> 
>>> Thank you in advance,
>>> 
>>> Linda Gilbert
>>> AFRL/RXOC
>>> RCF Information Systems
>>> 937-904-7632
>>> 
>>> 
> 
> Interesting question. Let me add another question wrt
> Abaqus. I know that you can export element matrices in
> MatrixMarket (*.mtx) format. How about system matrices ?
> 
> Nils

You can generate matrices representing the following model
features:

stiffness
mass
viscous damping
structural damping, and
loads

In Abaqus 6.7 use the following option to generate the 
stiffness matrix, etc.

*MATRIX GENERATE, STIFFNESS
*MATRIX GENERATE, MASS
*MATRIX GENERATE, VISCOUS DAMPING
*MATRIX GENERATE, STRUCTURAL DAMPING
*MATRIX GENERATE, LOAD

For details see section 10.3.1 of Abaqus Analysis User's 
Manual Volume II: Analysis

Generated matrices are output to a text file.
The assembled sparse matrix operator data are written to 
the text file as a series of comma-separated lists. Each 
row in the file represents a single matrix entry; a row is 
written
with the following elements

1. Row node label
2. Degree of freedom for row node
3. Column node label
4. Degree of freedom for column node
5. Matrix entry

For load matrices, which represent right-hand side vector 
data, each row in the text file is written with the 
following elements:

1. Node label
2. Right-hand side vector entry.


Nils


From dmitrey.kroshko at scipy.org  Wed Feb 27 04:03:47 2008
From: dmitrey.kroshko at scipy.org (dmitrey)
Date: Wed, 27 Feb 2008 11:03:47 +0200
Subject: [SciPy-dev] could anyone propose University of California workers
 to change bvls license?
Message-ID: <47C52773.2000602@scipy.org>

hi all,
here's a fortran routine bvls, free for non-commercial purposes:
http://lib.stat.cmu.edu/general/bvls

Could anyone contact to the authors of the routine and propose them make 
it available in terms of GPL/LGPL or, moreover, BSD license?

I have already working Python interface (via f2py, thanks to Pearu 
Peterson for assist), so, if BSD - it could be connected to scipy.

In anyway, this routine would be of great interest in scikits.openopt 
users, because solvers ralg and lincher could be enhanced (in case of >1 
constraints), and, of course, mere bvls solver could be included to LLSP 
class.

Authors of the routine, as it is mentioned in the file header, are

Robert L. Parker                           Philip B. Stark
Scripps Institution of Oceanography        Department of Statistics
University of California, San Diego        University of California
La Jolla CA 92093                          Berkeley CA 94720-3860
rlparker at ucsd.edu                          stark at stat.berkeley.edu

I would contact the authors of the routine by myself, but IIRC some 
scipy developers work in this university and have better English 
language knowledge.

Regards, D.


From Laurence.Viry at imag.fr  Wed Feb 27 10:47:47 2008
From: Laurence.Viry at imag.fr (Laurence Viry)
Date: Wed, 27 Feb 2008 16:47:47 +0100
Subject: [SciPy-dev] Probs with numpy/scipy on Itanium 64Bit with Intel
 Compilers with SCSL libs.
In-Reply-To: <47B58A3F.6050708@ar.media.kyoto-u.ac.jp>
References: <ab93c7300802150444n3f151426v342f93c8d66fcdba@mail.gmail.com>
	<47B58A3F.6050708@ar.media.kyoto-u.ac.jp>
Message-ID: <47C58623.3040603@imag.fr>

Hello,

David Cournapeau a ?crit
> If you could give one of us a shell access to a computer where 
> everything is installed to build numpy/scipy on an itanium, it would be 
> much easier to solve the problem,
>
>   

I give you, one access to our computer. I am not in my office these two 
following days but you can contact me since monday. If you have a system 
problem, you can send a mail to Bruno.Bzeznik at imag.fr

login: cournapd
pass: IfTSMHfo

1. We have two versions of python installed to test scipy installation:
* *one compiled with gcc* (usr/local/stow/Python2.4.4)

* t*he other with the intel compiler* "icc" 
(usr/local/stow/Python2.4.4_INTEL)

You have acces on these two directories.

2. I put in your *.bashrc the environment to use the Intel compilers *

3. The *scsl library *(scientific library optimized on our cluster with intel compilers) is in */usr/lib (compiled with Intel Fortran compiler)
*(On Itanium, the install procedure of ATLAS want to use Intel compilers, we can forced it to use Gnu compilers but we obtain bad optimizations)*
*
4. I attached on my mail the file *'site.cfg*' used to install scipy and numpy

4. I attached on my mail a file named *"whatWeHaveDone.txt" *in which I give you again what we have done to install numpy and scipy.

remarks: It seem that it's a bug in the part of program which extract 
the intel version compiler. *An additional test is made in 
numpy/distutils/command/build_ext.py to test this version *(ifort -V), 
there is no version test in numpy/distutils/command/build_clib.py.

I tried to change this test in 
/usr/local/stow/Python-2.4.4/lib/python2.4/site-packages/numpy/distutils/fcompiler/intel.py...but 
it doesn't run.

thanks for your help

Laurence Viry


Julien Le Sommer wrote:

> Hello,
>
> We are working hard to compile scipy on our box. We have already sent
> a post on this list but so far we haven't managed to install scipy 
> yet, see :
> http://projects.scipy.org/pipermail/scipy-dev/2007-November/007998.html 
> <http://projects.scipy.org/pipermail/scipy-dev/2007-November/007998.html>
>
> here is the problem : we are trying to compile numpy/scipy with
> intel compilers on a box of itanium processors with the SCSL library.
>
> the problem is that both numpy and scipy seem to loose track of the
> fortran compiler configuration during their build_ext phase even though
> this configuration is recognized during the build_clib phase, giving this
> log message.
>
>     customize IntelItaniumFCompiler
>
>     warning: build_ext: f77_compiler=intele is not available.
>
>
> the prob is the same when python has been compiled with gcc or with 
> intel c compiler.
>
> the prob doesn't seems to be related to scsl lib at all but only to 
> the handling of intel
> compiler for Itanium .
>
> some help would be much appreciated. In particular, is there a 
> Intel/Itanium implementation
> of scipy/numpy somewhere that we could get some information about ?
>
>   


> cheers,
>
> David
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>   


-- 
Laurence Viry

CRIP UJF - Projet MIRAGE ( http://mirage.imag.fr )
Laboratoire de Mod?lisation et Calcul - IMAG

tel: 04 76 63 56 34
fax: 04 76 63 12 63
e-mail: Laurence.Viry at imag.fr

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: whatWeHaveDone.txt
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080227/dff8f3c8/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: site.cfg
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080227/dff8f3c8/attachment.ksh>

From robert.kern at gmail.com  Wed Feb 27 11:53:45 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 27 Feb 2008 10:53:45 -0600
Subject: [SciPy-dev] could anyone propose University of California
	workers to change bvls license?
In-Reply-To: <47C52773.2000602@scipy.org>
References: <47C52773.2000602@scipy.org>
Message-ID: <3d375d730802270853w6f446657i757c1f3907c1d6f@mail.gmail.com>

On Wed, Feb 27, 2008 at 3:03 AM, dmitrey <dmitrey.kroshko at scipy.org> wrote:
> hi all,
>  here's a fortran routine bvls, free for non-commercial purposes:
>  http://lib.stat.cmu.edu/general/bvls
>
>  Could anyone contact to the authors of the routine and propose them make
>  it available in terms of GPL/LGPL or, moreover, BSD license?
>
>  I have already working Python interface (via f2py, thanks to Pearu
>  Peterson for assist), so, if BSD - it could be connected to scipy.
>
>  In anyway, this routine would be of great interest in scikits.openopt
>  users, because solvers ralg and lincher could be enhanced (in case of >1
>  constraints), and, of course, mere bvls solver could be included to LLSP
>  class.
>
>  Authors of the routine, as it is mentioned in the file header, are
>
>  Robert L. Parker                           Philip B. Stark
>  Scripps Institution of Oceanography        Department of Statistics
>  University of California, San Diego        University of California
>  La Jolla CA 92093                          Berkeley CA 94720-3860
>  rlparker at ucsd.edu                          stark at stat.berkeley.edu
>
>  I would contact the authors of the routine by myself, but IIRC some
>  scipy developers work in this university and have better English
>  language knowledge.

I used to work there, but I really doubt that they will consider a
change of license. They really do want to restrict its use to
non-commercial purposes. Or rather, the Technology Transfer Department
of UCSD does.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From dalcinl at gmail.com  Wed Feb 27 14:25:10 2008
From: dalcinl at gmail.com (Lisandro Dalcin)
Date: Wed, 27 Feb 2008 16:25:10 -0300
Subject: [SciPy-dev] Scipy, numpy and Abaqus
In-Reply-To: <2B00361EE3107A4F88383EC1B041DC9A02D71466@VFOHMLAO01.Enterprise.afmc.ds.af.mil>
References: <AchOIcgQ1sGvqPWKR9GBsKh4uWmjTgEBnm5Q>
	<2B00361EE3107A4F88383EC1B041DC9A02D71466@VFOHMLAO01.Enterprise.afmc.ds.af.mil>
Message-ID: <e7ba66e40802271125n6eea7440q6495d38e880346a1@mail.gmail.com>

Coud you elaborate a bit more of what are you trying to do?


On 1/8/08, Gilbert, Linda M CTR USAF AFRL/RXOC
<Linda.Gilbert at wpafb.af.mil> wrote:
>
>
>
>
>
> _____________________________________________
> From:   Gilbert, Linda M CTR USAF AFRL/MLOC
> Sent:   Thursday, January 03, 2008 11:01 AM
> To:     'scipy-dev at scipy.org'; 'pearu at cens.ioc.ee'
> Subject:        Scipy, numpy and Abaqus
>
> Hello,
>
> Do you know how to get numpy and scipy to work from within abaqus?
>
> Thank you in advance,
>
> Linda Gilbert
> AFRL/RXOC
> RCF Information Systems
> 937-904-7632
>
> _______________________________________________
>  Scipy-dev mailing list
>  Scipy-dev at scipy.org
>  http://projects.scipy.org/mailman/listinfo/scipy-dev
>
>


-- 
Lisandro Dalc?n
---------------
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594


From nwagner at iam.uni-stuttgart.de  Wed Feb 27 15:13:25 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Wed, 27 Feb 2008 21:13:25 +0100
Subject: [SciPy-dev] Experience with Goto's BLAS
Message-ID: <web-97475677@uni-stuttgart.de>

Hi all,

Is there anyone who can report about the usage of Goto's 
BLAS with respect to numpy/scipy ?
What can be said about advantages of ACML, MKL, ATLAS and 
Goto's BLAS ?
Who can shed light on the differences between the 
different libraries ?


Cheers,

              Nils

References:

http://www.tacc.utexas.edu/resources/software/software.php
http://developer.amd.com/tools/acml/Pages/default.aspx
http://www.intel.com/cd/software/products/asmo-na/eng/307757.htm
http://math-atlas.sourceforge.net/


From travis at enthought.com  Wed Feb 27 22:13:20 2008
From: travis at enthought.com (Travis Vaught)
Date: Wed, 27 Feb 2008 21:13:20 -0600
Subject: [SciPy-dev] ANN: Enthought Python Distribution - Beta
Message-ID: <733AFCE4-50FA-4A79-B032-B0965F75E434@enthought.com>

Greetings,

Enthought is very excited about our pending wide-release of the  
Enthought Python Distribution (EPD).  After much effort, we finally  
think we're close to the first non-beta release.  As one more quality  
check, we'd love to impose on you guys one more time to try out a just- 
minted beta release for Windows (EPD 2.5.2001_beta1) and give us some  
feedback.  Any major problems will, of course, be fixed for the next  
release, but we're open to any suggestions for improvement for future  
releases as well.

http://www.enthought.com/epd

For those of you unfamiliar with EPD, it's a "kitchen-sink-included"  
distribution of Python with over 60 additional tools and libraries.   
It's bundled into a nice MSI installer on Windows and includes NumPy,  
SciPy, IPython, 2D and 3D visualization, database adapters and a lot  
of other tools right out of the box.  We'll have support for RedHat  
and Mac OS X in a general release very soon.

For academic, non-profit or hobbyist use, EPD is, and will remain,  
free.  We are charging an annual subscription for commercial and  
governmental access to downloads and updates of EPD.  Downloaded files  
may be used indefinitely past the subscription term.  You are welcome  
to try out the beta indefinitely, regardless of your commercial/non- 
commercial persuasion.  When the final (non-beta) version is released,  
commercial folks can try it for 30 days. You can check out the license  
terms (http://www.enthought.com/products/epdlicense.php) if you're  
interested in the details.

EPD is compelling because it solves a lingering packaging and  
distribution problem, but also because of the libraries which it  
includes. We owe many folks on this list a debt of gratitude for their  
work on some really great tools. So, thanks ... and enjoy!

Best Regards,

Travis N. Vaught






From ollinger at wisc.edu  Wed Feb 27 23:27:15 2008
From: ollinger at wisc.edu (John Ollinger)
Date: Wed, 27 Feb 2008 22:27:15 -0600
Subject: [SciPy-dev] ANN: Enthought Python Distribution - Beta
In-Reply-To: <733AFCE4-50FA-4A79-B032-B0965F75E434@enthought.com>
References: <733AFCE4-50FA-4A79-B032-B0965F75E434@enthought.com>
Message-ID: <5b9ba9310802272027u689d755by4af6ca07b4b20baa@mail.gmail.com>

What exactly is the relationship between Enthought and the scipy developers
and how will it affect future releases of scipy and numpy?  Will scipy
evolve to the point where the Enthought version is required for all
practical purposes?


John





On Wed, Feb 27, 2008 at 9:13 PM, Travis Vaught <travis at enthought.com> wrote:

> Greetings,
>
> Enthought is very excited about our pending wide-release of the
> Enthought Python Distribution (EPD).  After much effort, we finally
> think we're close to the first non-beta release.  As one more quality
> check, we'd love to impose on you guys one more time to try out a just-
> minted beta release for Windows (EPD 2.5.2001_beta1) and give us some
> feedback.  Any major problems will, of course, be fixed for the next
> release, but we're open to any suggestions for improvement for future
> releases as well.
>
> http://www.enthought.com/epd
>
> For those of you unfamiliar with EPD, it's a "kitchen-sink-included"
> distribution of Python with over 60 additional tools and libraries.
> It's bundled into a nice MSI installer on Windows and includes NumPy,
> SciPy, IPython, 2D and 3D visualization, database adapters and a lot
> of other tools right out of the box.  We'll have support for RedHat
> and Mac OS X in a general release very soon.
>
> For academic, non-profit or hobbyist use, EPD is, and will remain,
> free.  We are charging an annual subscription for commercial and
> governmental access to downloads and updates of EPD.  Downloaded files
> may be used indefinitely past the subscription term.  You are welcome
> to try out the beta indefinitely, regardless of your commercial/non-
> commercial persuasion.  When the final (non-beta) version is released,
> commercial folks can try it for 30 days. You can check out the license
> terms (http://www.enthought.com/products/epdlicense.php) if you're
> interested in the details.
>
> EPD is compelling because it solves a lingering packaging and
> distribution problem, but also because of the libraries which it
> includes. We owe many folks on this list a debt of gratitude for their
> work on some really great tools. So, thanks ... and enjoy!
>
> Best Regards,
>
> Travis N. Vaught
>
>
>
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>



-- 
John Ollinger
University of Wisconsin
Waisman Center, T233
1500 Highland Ave
Madison, WI 53711
http://brainimaging.waisman.wisc.edu/~jjo/<http://brainimaging.waisman.wisc.edu/%7Ejjo/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080227/2c9aa456/attachment.html>

From robert.kern at gmail.com  Thu Feb 28 00:18:29 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 27 Feb 2008 23:18:29 -0600
Subject: [SciPy-dev] ANN: Enthought Python Distribution - Beta
In-Reply-To: <5b9ba9310802272027u689d755by4af6ca07b4b20baa@mail.gmail.com>
References: <733AFCE4-50FA-4A79-B032-B0965F75E434@enthought.com>
	<5b9ba9310802272027u689d755by4af6ca07b4b20baa@mail.gmail.com>
Message-ID: <3d375d730802272118t26ea170cr8a63023d4a5243cb@mail.gmail.com>

On Wed, Feb 27, 2008 at 10:27 PM, John Ollinger <ollinger at wisc.edu> wrote:
> What exactly is the relationship between Enthought and the scipy developers

Enthought employs a few of them, namely Travis Oliphant and myself.
Enthought, Travis Oliphant, and Pearu Peterson made the initial
contributions that started the scipy project in the first place.
Enthought hosts scipy.org. Enthought contributes a fair amount of time
and money to numpy and scipy development, still.

> and how will it affect future releases of scipy and numpy?

Travis and I will be able to work on them, mostly. What are you
worried about happening?

> Will scipy
> evolve to the point where the Enthought version is required for all
> practical purposes?

No.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From matthieu.brucher at gmail.com  Thu Feb 28 08:35:50 2008
From: matthieu.brucher at gmail.com (Matthieu Brucher)
Date: Thu, 28 Feb 2008 14:35:50 +0100
Subject: [SciPy-dev] [arpack] eigen_symmetric and the sigma value
Message-ID: <e76aa17f0802280535r880eeaeq778d733de1a80293@mail.gmail.com>

Hi,

Is there any plan of adding the support of the sigma keyword, like it is
done in Matlab (http://www.mathworks.com/access/helpdesk/help/techdoc/ref/**
eigs.html) ?
It is needed for some algorithms, like the Locally Linear Embedding I'd like
to put it the learn scikit.

Matthieu
-- 
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080228/847ceabb/attachment.html>

From hagberg at lanl.gov  Thu Feb 28 08:48:07 2008
From: hagberg at lanl.gov (Aric Hagberg)
Date: Thu, 28 Feb 2008 06:48:07 -0700
Subject: [SciPy-dev] [arpack] eigen_symmetric and the sigma value
In-Reply-To: <e76aa17f0802280535r880eeaeq778d733de1a80293@mail.gmail.com>
References: <e76aa17f0802280535r880eeaeq778d733de1a80293@mail.gmail.com>
Message-ID: <20080228134807.GF15007@frappa.lanl.gov>

On Thu, Feb 28, 2008 at 02:35:50PM +0100, Matthieu Brucher wrote:
> Is there any plan of adding the support of the sigma keyword, like it is
> done in Matlab (http://www.mathworks.com/access/helpdesk/help/techdoc/ref/**
> eigs.html) ?

Yes, it's on my TODO list.  It would be good to implement most, if not
all, of the shift-invert spectral transform modes along with the
generalized eigenproblem modes.  The current tickets are
http://www.scipy.org/scipy/scipy/ticket/231
and 
http://www.scipy.org/scipy/scipy/ticket/418

Any help is welcome.

Aric


From matthieu.brucher at gmail.com  Thu Feb 28 09:01:25 2008
From: matthieu.brucher at gmail.com (Matthieu Brucher)
Date: Thu, 28 Feb 2008 15:01:25 +0100
Subject: [SciPy-dev] [arpack] eigen_symmetric and the sigma value
In-Reply-To: <20080228134807.GF15007@frappa.lanl.gov>
References: <e76aa17f0802280535r880eeaeq778d733de1a80293@mail.gmail.com>
	<20080228134807.GF15007@frappa.lanl.gov>
Message-ID: <e76aa17f0802280601k33897f43n10d803617c14d09a@mail.gmail.com>

According to the tickets, it seems that the shift are implemented for real
matrices, isn't it ?

Matthieu

2008/2/28, Aric Hagberg <hagberg at lanl.gov>:
>
> On Thu, Feb 28, 2008 at 02:35:50PM +0100, Matthieu Brucher wrote:
> > Is there any plan of adding the support of the sigma keyword, like it is
> > done in Matlab (
> http://www.mathworks.com/access/helpdesk/help/techdoc/ref/**
> > eigs.html) ?
>
>
> Yes, it's on my TODO list.  It would be good to implement most, if not
> all, of the shift-invert spectral transform modes along with the
> generalized eigenproblem modes.  The current tickets are
> http://www.scipy.org/scipy/scipy/ticket/231
> and
> http://www.scipy.org/scipy/scipy/ticket/418
>
> Any help is welcome.
>
> Aric
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>



-- 
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080228/f73c3780/attachment.html>

From hagberg at lanl.gov  Thu Feb 28 09:10:25 2008
From: hagberg at lanl.gov (Aric Hagberg)
Date: Thu, 28 Feb 2008 07:10:25 -0700
Subject: [SciPy-dev] [arpack] eigen_symmetric and the sigma value
In-Reply-To: <e76aa17f0802280601k33897f43n10d803617c14d09a@mail.gmail.com>
References: <e76aa17f0802280535r880eeaeq778d733de1a80293@mail.gmail.com>
	<20080228134807.GF15007@frappa.lanl.gov>
	<e76aa17f0802280601k33897f43n10d803617c14d09a@mail.gmail.com>
Message-ID: <20080228141025.GG15007@frappa.lanl.gov>

On Thu, Feb 28, 2008 at 03:01:25PM +0100, Matthieu Brucher wrote:
> According to the tickets, it seems that the shift are implemented for real
> matrices, isn't it ?

There is an alternate interface
http://www.scipy.org/scipy/scipy/browser/trunk/scipy/sparse/linalg/eigen/arpack/speigs.py
that should solve the shift-invert problem for real (double) matrices.
This functionality needs to be folded into the other (arpack.py) interface and
extended to work for all matrix types.  You might be able to make it
work for you until we get to that.

Aric


From matthieu.brucher at gmail.com  Thu Feb 28 09:16:44 2008
From: matthieu.brucher at gmail.com (Matthieu Brucher)
Date: Thu, 28 Feb 2008 15:16:44 +0100
Subject: [SciPy-dev] [arpack] eigen_symmetric and the sigma value
In-Reply-To: <20080228141025.GG15007@frappa.lanl.gov>
References: <e76aa17f0802280535r880eeaeq778d733de1a80293@mail.gmail.com>
	<20080228134807.GF15007@frappa.lanl.gov>
	<e76aa17f0802280601k33897f43n10d803617c14d09a@mail.gmail.com>
	<20080228141025.GG15007@frappa.lanl.gov>
Message-ID: <e76aa17f0802280616r26f18133jf27f85caca96f799@mail.gmail.com>

2008/2/28, Aric Hagberg <hagberg at lanl.gov>:
>
> On Thu, Feb 28, 2008 at 03:01:25PM +0100, Matthieu Brucher wrote:
> > According to the tickets, it seems that the shift are implemented for
> real
> > matrices, isn't it ?
>
>
> There is an alternate interface
>
> http://www.scipy.org/scipy/scipy/browser/trunk/scipy/sparse/linalg/eigen/arpack/speigs.py
> that should solve the shift-invert problem for real (double) matrices.
> This functionality needs to be folded into the other (arpack.py) interface
> and
> extended to work for all matrix types.  You might be able to make it
> work for you until we get to that.


OK, I'll try this, hoping that it behaves like MAtlab's version ;)
I'll keep the list informed !

Matthieu
-- 
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080228/251083bd/attachment.html>

From matthieu.brucher at gmail.com  Thu Feb 28 09:31:42 2008
From: matthieu.brucher at gmail.com (Matthieu Brucher)
Date: Thu, 28 Feb 2008 15:31:42 +0100
Subject: [SciPy-dev] [arpack] eigen_symmetric and the sigma value
In-Reply-To: <e76aa17f0802280616r26f18133jf27f85caca96f799@mail.gmail.com>
References: <e76aa17f0802280535r880eeaeq778d733de1a80293@mail.gmail.com>
	<20080228134807.GF15007@frappa.lanl.gov>
	<e76aa17f0802280601k33897f43n10d803617c14d09a@mail.gmail.com>
	<20080228141025.GG15007@frappa.lanl.gov>
	<e76aa17f0802280616r26f18133jf27f85caca96f799@mail.gmail.com>
Message-ID: <e76aa17f0802280631g2b86a1c0s67a9cd0f6374c48@mail.gmail.com>

>
> OK, I'll try this, hoping that it behaves like MAtlab's version ;)
> I'll keep the list informed !
>
> Matthieu


I tried to use it, but I don't get the same result as Matlab or a standard
eigen analysis.
I'd like to get the eigenvalues that are strictly greater than zero. Is it
possible with one of the speigs option ?

Is it planned to add the sigma keyword to the ARPACK_eigs function ? (that's
how my problem is solved by Matlab, that's why I'm asking)

Matthieu
-- 
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080228/91ad2f78/attachment.html>

From hagberg at lanl.gov  Thu Feb 28 09:58:54 2008
From: hagberg at lanl.gov (Aric Hagberg)
Date: Thu, 28 Feb 2008 07:58:54 -0700
Subject: [SciPy-dev] [arpack] eigen_symmetric and the sigma value
In-Reply-To: <e76aa17f0802280631g2b86a1c0s67a9cd0f6374c48@mail.gmail.com>
References: <e76aa17f0802280535r880eeaeq778d733de1a80293@mail.gmail.com>
	<20080228134807.GF15007@frappa.lanl.gov>
	<e76aa17f0802280601k33897f43n10d803617c14d09a@mail.gmail.com>
	<20080228141025.GG15007@frappa.lanl.gov>
	<e76aa17f0802280616r26f18133jf27f85caca96f799@mail.gmail.com>
	<e76aa17f0802280631g2b86a1c0s67a9cd0f6374c48@mail.gmail.com>
Message-ID: <20080228145854.GH15007@frappa.lanl.gov>

On Thu, Feb 28, 2008 at 03:31:42PM +0100, Matthieu Brucher wrote:
> I tried to use it, but I don't get the same result as Matlab or a standard
> eigen analysis.
> I'd like to get the eigenvalues that are strictly greater than zero. Is it
> possible with one of the speigs option ?
> 
> Is it planned to add the sigma keyword to the ARPACK_eigs function ? (that's
> how my problem is solved by Matlab, that's why I'm asking)

We'll add that functionality to the eigen_symmetric() and eigen()
functions.  

Aric


From ollinger at wisc.edu  Thu Feb 28 13:21:53 2008
From: ollinger at wisc.edu (John Ollinger)
Date: Thu, 28 Feb 2008 12:21:53 -0600
Subject: [SciPy-dev] ANN: Enthought Python Distribution - Beta
In-Reply-To: <3d375d730802272118t26ea170cr8a63023d4a5243cb@mail.gmail.com>
References: <733AFCE4-50FA-4A79-B032-B0965F75E434@enthought.com>
	<5b9ba9310802272027u689d755by4af6ca07b4b20baa@mail.gmail.com>
	<3d375d730802272118t26ea170cr8a63023d4a5243cb@mail.gmail.com>
Message-ID: <5b9ba9310802281021v2478dd59ycaabe21bb347c5ed@mail.gmail.com>

I apologize for the tone of my email  - it was the result of late-hours, a
migraine, and memories of past bad experiences.  I spent 3 years in the 80's
writing software for a scanner that was ostensibly developed for use at a
university.  Then the hardware guys formed a company and eventually made
tons of money while the two of us developing software got a one-time shot at
some consulting, $2000 in royalties, (which was exactly equal to the
university's share,) and lost our jobs.   A few years later I inadvertently
bought software that I had written during those three years.  Hence the
paranoia.

The combination of open-source software and for-profit companies do raise
some legitimate questions, so I don't think that it is entirely unreasonable
for people to wonder about this.


John

On Wed, Feb 27, 2008 at 11:18 PM, Robert Kern <robert.kern at gmail.com> wrote:

> On Wed, Feb 27, 2008 at 10:27 PM, John Ollinger <ollinger at wisc.edu> wrote:
> > What exactly is the relationship between Enthought and the scipy
> developers
>
> Enthought employs a few of them, namely Travis Oliphant and myself.
> Enthought, Travis Oliphant, and Pearu Peterson made the initial
> contributions that started the scipy project in the first place.
> Enthought hosts scipy.org. Enthought contributes a fair amount of time
> and money to numpy and scipy development, still.
>
> > and how will it affect future releases of scipy and numpy?
>
> Travis and I will be able to work on them, mostly. What are you
> worried about happening?
>
> > Will scipy
> > evolve to the point where the Enthought version is required for all
> > practical purposes?
>
> No.
>
> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless
> enigma that is made terrible by our own mad attempt to interpret it as
> though it had an underlying truth."
>  -- Umberto Eco
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>



-- 
John Ollinger
University of Wisconsin
Waisman Center, T233
1500 Highland Ave
Madison, WI 53711
http://brainimaging.waisman.wisc.edu/~jjo/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080228/1ab79373/attachment.html>

From robert.kern at gmail.com  Thu Feb 28 14:24:48 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 28 Feb 2008 13:24:48 -0600
Subject: [SciPy-dev] ANN: Enthought Python Distribution - Beta
In-Reply-To: <5b9ba9310802281021v2478dd59ycaabe21bb347c5ed@mail.gmail.com>
References: <733AFCE4-50FA-4A79-B032-B0965F75E434@enthought.com>
	<5b9ba9310802272027u689d755by4af6ca07b4b20baa@mail.gmail.com>
	<3d375d730802272118t26ea170cr8a63023d4a5243cb@mail.gmail.com>
	<5b9ba9310802281021v2478dd59ycaabe21bb347c5ed@mail.gmail.com>
Message-ID: <3d375d730802281124v4246fff7o7e6d02dd83d770f5@mail.gmail.com>

On Thu, Feb 28, 2008 at 12:21 PM, John Ollinger <ollinger at wisc.edu> wrote:
>
> I apologize for the tone of my email  - it was the result of late-hours, a
> migraine, and memories of past bad experiences.  I spent 3 years in the 80's
> writing software for a scanner that was ostensibly developed for use at a
> university.  Then the hardware guys formed a company and eventually made
> tons of money while the two of us developing software got a one-time shot at
> some consulting, $2000 in royalties, (which was exactly equal to the
> university's share,) and lost our jobs.   A few years later I inadvertently
> bought software that I had written during those three years.  Hence the
> paranoia.
>
> The combination of open-source software and for-profit companies do raise
> some legitimate questions, so I don't think that it is entirely unreasonable
> for people to wonder about this.

Fair enough. However, I think that our history of support for a free
and open scipy since (quite literally) the beginning should speak for
itself. Nothing has changed in that regard. scipy would be much less
useful to us were we to attempt to close it up, not that we could
succeed. A big difference between your situation (as far as I can
tell) and scipy's is that scipy's code is authentically open source
and freely available on the Internet. Even if we were to shut down
scipy.org and "take our ball and go home," there are any number of
people with the source already who can simply start up again on
code.google.com. We would inconvenience the community, but we couldn't
stop it from developing scipy in any way.

But all of that would be incredibly stupid of us. Our support of scipy
has been one of the most substantial advertisements for our consulting
services. For a long time, it was our *only* advertisement.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From matthew.brett at gmail.com  Thu Feb 28 15:03:36 2008
From: matthew.brett at gmail.com (Matthew Brett)
Date: Thu, 28 Feb 2008 20:03:36 +0000
Subject: [SciPy-dev] ANN: Enthought Python Distribution - Beta
In-Reply-To: <3d375d730802281124v4246fff7o7e6d02dd83d770f5@mail.gmail.com>
References: <733AFCE4-50FA-4A79-B032-B0965F75E434@enthought.com>
	<5b9ba9310802272027u689d755by4af6ca07b4b20baa@mail.gmail.com>
	<3d375d730802272118t26ea170cr8a63023d4a5243cb@mail.gmail.com>
	<5b9ba9310802281021v2478dd59ycaabe21bb347c5ed@mail.gmail.com>
	<3d375d730802281124v4246fff7o7e6d02dd83d770f5@mail.gmail.com>
Message-ID: <1e2af89e0802281203x32c3e2f8v5367bd1383dfbdcc@mail.gmail.com>

Hi,

>  But all of that would be incredibly stupid of us. Our support of scipy
>  has been one of the most substantial advertisements for our consulting
>  services. For a long time, it was our *only* advertisement.

All good reasonable points.  I guess the call here is whether charging
companies and government institutions for the bundle will have a small
enough deterrent effect on those trying out scientific python to be an
insignificant barrier to its uptake,

Matthew


From robert.kern at gmail.com  Thu Feb 28 15:10:55 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 28 Feb 2008 14:10:55 -0600
Subject: [SciPy-dev] ANN: Enthought Python Distribution - Beta
In-Reply-To: <1e2af89e0802281203x32c3e2f8v5367bd1383dfbdcc@mail.gmail.com>
References: <733AFCE4-50FA-4A79-B032-B0965F75E434@enthought.com>
	<5b9ba9310802272027u689d755by4af6ca07b4b20baa@mail.gmail.com>
	<3d375d730802272118t26ea170cr8a63023d4a5243cb@mail.gmail.com>
	<5b9ba9310802281021v2478dd59ycaabe21bb347c5ed@mail.gmail.com>
	<3d375d730802281124v4246fff7o7e6d02dd83d770f5@mail.gmail.com>
	<1e2af89e0802281203x32c3e2f8v5367bd1383dfbdcc@mail.gmail.com>
Message-ID: <3d375d730802281210l65138b4fi8f2c51915e56093c@mail.gmail.com>

On Thu, Feb 28, 2008 at 2:03 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
> Hi,
>
>
>  >  But all of that would be incredibly stupid of us. Our support of scipy
>  >  has been one of the most substantial advertisements for our consulting
>  >  services. For a long time, it was our *only* advertisement.
>
>  All good reasonable points.  I guess the call here is whether charging
>  companies and government institutions for the bundle will have a small
>  enough deterrent effect on those trying out scientific python to be an
>  insignificant barrier to its uptake,

To the contrary, we've found that it reduces the hesitation of these
institutions to adopt Python substantially. IT departments *hate*
deploying dozens of random things from various internet sources with
no support.

We are providing an *additional* service to what is currently
available. It's not like we're reducing what is currently freely
available.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From matthew.brett at gmail.com  Thu Feb 28 15:15:06 2008
From: matthew.brett at gmail.com (Matthew Brett)
Date: Thu, 28 Feb 2008 20:15:06 +0000
Subject: [SciPy-dev] ANN: Enthought Python Distribution - Beta
In-Reply-To: <3d375d730802281210l65138b4fi8f2c51915e56093c@mail.gmail.com>
References: <733AFCE4-50FA-4A79-B032-B0965F75E434@enthought.com>
	<5b9ba9310802272027u689d755by4af6ca07b4b20baa@mail.gmail.com>
	<3d375d730802272118t26ea170cr8a63023d4a5243cb@mail.gmail.com>
	<5b9ba9310802281021v2478dd59ycaabe21bb347c5ed@mail.gmail.com>
	<3d375d730802281124v4246fff7o7e6d02dd83d770f5@mail.gmail.com>
	<1e2af89e0802281203x32c3e2f8v5367bd1383dfbdcc@mail.gmail.com>
	<3d375d730802281210l65138b4fi8f2c51915e56093c@mail.gmail.com>
Message-ID: <1e2af89e0802281215n54ec1711ue7881257cb4159fe@mail.gmail.com>

Hi,

>  >  All good reasonable points.  I guess the call here is whether charging
>  >  companies and government institutions for the bundle will have a small
>  >  enough deterrent effect on those trying out scientific python to be an
>  >  insignificant barrier to its uptake,
>
>  To the contrary, we've found that it reduces the hesitation of these
>  institutions to adopt Python substantially. IT departments *hate*
>  deploying dozens of random things from various internet sources with
>  no support.

With the bundle - yes of course.  I mean, if the bundle becomes the
defacto standard for deploying python, numpy etc, and the charges
worry people, then they may be less likely to try it.  I've no idea
whether that will be a big factor - I guess it's difficult to say.

Matthew


From matthew.brett at gmail.com  Thu Feb 28 15:27:37 2008
From: matthew.brett at gmail.com (Matthew Brett)
Date: Thu, 28 Feb 2008 20:27:37 +0000
Subject: [SciPy-dev] ANN: Enthought Python Distribution - Beta
In-Reply-To: <1e2af89e0802281215n54ec1711ue7881257cb4159fe@mail.gmail.com>
References: <733AFCE4-50FA-4A79-B032-B0965F75E434@enthought.com>
	<5b9ba9310802272027u689d755by4af6ca07b4b20baa@mail.gmail.com>
	<3d375d730802272118t26ea170cr8a63023d4a5243cb@mail.gmail.com>
	<5b9ba9310802281021v2478dd59ycaabe21bb347c5ed@mail.gmail.com>
	<3d375d730802281124v4246fff7o7e6d02dd83d770f5@mail.gmail.com>
	<1e2af89e0802281203x32c3e2f8v5367bd1383dfbdcc@mail.gmail.com>
	<3d375d730802281210l65138b4fi8f2c51915e56093c@mail.gmail.com>
	<1e2af89e0802281215n54ec1711ue7881257cb4159fe@mail.gmail.com>
Message-ID: <1e2af89e0802281227t34edb062ub440c898604cb66f@mail.gmail.com>

>  With the bundle - yes of course.  I mean, if the bundle becomes the
>  defacto standard for deploying python, numpy etc, and the charges
>  worry people, then they may be less likely to try it.  I've no idea
>  whether that will be a big factor - I guess it's difficult to say.

For example - imagine the following scenario.  Someone moderately
junior has just joined a company or government institution.  They
become keen on python, start playing with python, VTK and so on, and
try and persuade others in the company to try it.  If they find they
have to ask the accounts people for money before they install the
bundle, or they have to build it all from scratch, they may not, which
means lost users.

Matthew


From robert.kern at gmail.com  Thu Feb 28 15:36:06 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 28 Feb 2008 14:36:06 -0600
Subject: [SciPy-dev] ANN: Enthought Python Distribution - Beta
In-Reply-To: <1e2af89e0802281227t34edb062ub440c898604cb66f@mail.gmail.com>
References: <733AFCE4-50FA-4A79-B032-B0965F75E434@enthought.com>
	<5b9ba9310802272027u689d755by4af6ca07b4b20baa@mail.gmail.com>
	<3d375d730802272118t26ea170cr8a63023d4a5243cb@mail.gmail.com>
	<5b9ba9310802281021v2478dd59ycaabe21bb347c5ed@mail.gmail.com>
	<3d375d730802281124v4246fff7o7e6d02dd83d770f5@mail.gmail.com>
	<1e2af89e0802281203x32c3e2f8v5367bd1383dfbdcc@mail.gmail.com>
	<3d375d730802281210l65138b4fi8f2c51915e56093c@mail.gmail.com>
	<1e2af89e0802281215n54ec1711ue7881257cb4159fe@mail.gmail.com>
	<1e2af89e0802281227t34edb062ub440c898604cb66f@mail.gmail.com>
Message-ID: <3d375d730802281236w30251caby9ee4637ff11601b8@mail.gmail.com>

On Thu, Feb 28, 2008 at 2:27 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
> >  With the bundle - yes of course.  I mean, if the bundle becomes the
>  >  defacto standard for deploying python, numpy etc, and the charges
>  >  worry people, then they may be less likely to try it.  I've no idea
>  >  whether that will be a big factor - I guess it's difficult to say.
>
>  For example - imagine the following scenario.  Someone moderately
>  junior has just joined a company or government institution.  They
>  become keen on python, start playing with python, VTK and so on, and
>  try and persuade others in the company to try it.  If they find they
>  have to ask the accounts people for money before they install the
>  bundle, or they have to build it all from scratch, they may not, which
>  means lost users.

Without EPD, they only have the latter alternative, so I'm not really
sure how the presence of EPD can harm anything.

Let me be clear on one thing which people may be fearing: we will not
stop making separate, freely available binary releases of numpy and
scipy. Nor will we stop anyone else from making such binaries.

We are interested in making money by *adding* services, not holding
them hostage.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From matthew.brett at gmail.com  Thu Feb 28 15:42:35 2008
From: matthew.brett at gmail.com (Matthew Brett)
Date: Thu, 28 Feb 2008 20:42:35 +0000
Subject: [SciPy-dev] ANN: Enthought Python Distribution - Beta
In-Reply-To: <3d375d730802281236w30251caby9ee4637ff11601b8@mail.gmail.com>
References: <733AFCE4-50FA-4A79-B032-B0965F75E434@enthought.com>
	<5b9ba9310802272027u689d755by4af6ca07b4b20baa@mail.gmail.com>
	<3d375d730802272118t26ea170cr8a63023d4a5243cb@mail.gmail.com>
	<5b9ba9310802281021v2478dd59ycaabe21bb347c5ed@mail.gmail.com>
	<3d375d730802281124v4246fff7o7e6d02dd83d770f5@mail.gmail.com>
	<1e2af89e0802281203x32c3e2f8v5367bd1383dfbdcc@mail.gmail.com>
	<3d375d730802281210l65138b4fi8f2c51915e56093c@mail.gmail.com>
	<1e2af89e0802281215n54ec1711ue7881257cb4159fe@mail.gmail.com>
	<1e2af89e0802281227t34edb062ub440c898604cb66f@mail.gmail.com>
	<3d375d730802281236w30251caby9ee4637ff11601b8@mail.gmail.com>
Message-ID: <1e2af89e0802281242i2117658fte0637ef2191b55bf@mail.gmail.com>

>  Without EPD, they only have the latter alternative, so I'm not really
>  sure how the presence of EPD can harm anything.

I'm not suggesting EPD is a bad idea, it is a very good idea, I'm just
saying, that charging for it may reduce the tendency for people to try
it, and therefore try python / numpy, compared to the option of making
it free.

Matthew


From aisaac at american.edu  Thu Feb 28 15:45:01 2008
From: aisaac at american.edu (Alan G Isaac)
Date: Thu, 28 Feb 2008 15:45:01 -0500
Subject: [SciPy-dev] ANN: Enthought Python Distribution - Beta
In-Reply-To: <1e2af89e0802281203x32c3e2f8v5367bd1383dfbdcc@mail.gmail.com>
References: <733AFCE4-50FA-4A79-B032-B0965F75E434@enthought.com><5b9ba9310802272027u689d755by4af6ca07b4b20baa@mail.gmail.com><3d375d730802272118t26ea170cr8a63023d4a5243cb@mail.gmail.com><5b9ba9310802281021v2478dd59ycaabe21bb347c5ed@mail.gmail.com><3d375d730802281124v4246fff7o7e6d02dd83d770f5@mail.gmail.com><1e2af89e0802281203x32c3e2f8v5367bd1383dfbdcc@mail.gmail.com>
Message-ID: <Mahogany-0.67.0-300-20080228-154501.00@american.edu>

On Thu, 28 Feb 2008, Matthew Brett apparently wrote:
> I guess the call here is whether charging companies and 
> government institutions for the bundle will have a small 
> enough deterrent effect on those trying out scientific 
> python to be an insignificant barrier to its uptake, 

In quite a few cases, this will probably *increase* 
interest.  It's an odd world...

But the most important things to stimulate interest
from government and large business is an established
reputation and the availability of paid support.

Cheers,
Alan Isaac





From Robin.K.Friedrich at usa-spaceops.com  Thu Feb 28 15:45:03 2008
From: Robin.K.Friedrich at usa-spaceops.com (Friedrich, Robin K)
Date: Thu, 28 Feb 2008 14:45:03 -0600
Subject: [SciPy-dev] ANN: Enthought Python Distribution - Beta
In-Reply-To: <1e2af89e0802281227t34edb062ub440c898604cb66f@mail.gmail.com>
References: <733AFCE4-50FA-4A79-B032-B0965F75E434@enthought.com><5b9ba9310802272027u689d755by4af6ca07b4b20baa@mail.gmail.com><3d375d730802272118t26ea170cr8a63023d4a5243cb@mail.gmail.com><5b9ba9310802281021v2478dd59ycaabe21bb347c5ed@mail.gmail.com><3d375d730802281124v4246fff7o7e6d02dd83d770f5@mail.gmail.com><1e2af89e0802281203x32c3e2f8v5367bd1383dfbdcc@mail.gmail.com><3d375d730802281210l65138b4fi8f2c51915e56093c@mail.gmail.com><1e2af89e0802281215n54ec1711ue7881257cb4159fe@mail.gmail.com>
	<1e2af89e0802281227t34edb062ub440c898604cb66f@mail.gmail.com>
Message-ID: <C9B674023BAA4C498DB6422BD8B8BB510B57EC7E@usatxcms08.tx.usa-spaceops.com>

That is indeed a valid scenario. On my Linux engineering systems we just built everything from scratch but on our institutional PC systems we like to have
an MSI ready to go and I have gone so far as to establish the EPD (prior version) as our company standard python installation for those Windows users who
need it. Of course now that decision puts us in a bind as we will in the future need to establish a contract with Enthought before continuing with this
standard. (Of course I would have had this same situation had I selected the ActiveState version...)
As this being a big deal? No, not really; just an annoyance. Governments and companies know how to license software and indeed prefer the warm fussy of paid
support to the FOSS model. People may just fall back to the python.org installer and never know the joy of the Enthought tool suite and scipy/numpy. I don't
know how often that may happen however. 

-Robin Friedrich

-----Original Message-----
From: scipy-dev-bounces at scipy.org [mailto:scipy-dev-bounces at scipy.org] On Behalf Of Matthew Brett
Sent: Thursday, February 28, 2008 2:28 PM
To: SciPy Developers List
Subject: Re: [SciPy-dev] ANN: Enthought Python Distribution - Beta

>  With the bundle - yes of course.  I mean, if the bundle becomes the  
> defacto standard for deploying python, numpy etc, and the charges  
> worry people, then they may be less likely to try it.  I've no idea  
> whether that will be a big factor - I guess it's difficult to say.

For example - imagine the following scenario.  Someone moderately junior has just joined a company or government institution.  They become keen on python,
start playing with python, VTK and so on, and try and persuade others in the company to try it.  If they find they have to ask the accounts people for money
before they install the bundle, or they have to build it all from scratch, they may not, which means lost users.

Matthew
_______________________________________________
Scipy-dev mailing list
Scipy-dev at scipy.org
http://projects.scipy.org/mailman/listinfo/scipy-dev


From ollinger at wisc.edu  Thu Feb 28 15:50:07 2008
From: ollinger at wisc.edu (John Ollinger)
Date: Thu, 28 Feb 2008 14:50:07 -0600
Subject: [SciPy-dev] ANN: Enthought Python Distribution - Beta
In-Reply-To: <3d375d730802281236w30251caby9ee4637ff11601b8@mail.gmail.com>
References: <733AFCE4-50FA-4A79-B032-B0965F75E434@enthought.com>
	<5b9ba9310802272027u689d755by4af6ca07b4b20baa@mail.gmail.com>
	<3d375d730802272118t26ea170cr8a63023d4a5243cb@mail.gmail.com>
	<5b9ba9310802281021v2478dd59ycaabe21bb347c5ed@mail.gmail.com>
	<3d375d730802281124v4246fff7o7e6d02dd83d770f5@mail.gmail.com>
	<1e2af89e0802281203x32c3e2f8v5367bd1383dfbdcc@mail.gmail.com>
	<3d375d730802281210l65138b4fi8f2c51915e56093c@mail.gmail.com>
	<1e2af89e0802281215n54ec1711ue7881257cb4159fe@mail.gmail.com>
	<1e2af89e0802281227t34edb062ub440c898604cb66f@mail.gmail.com>
	<3d375d730802281236w30251caby9ee4637ff11601b8@mail.gmail.com>
Message-ID: <5b9ba9310802281250q683aad80od54a0570c0fe9d9a@mail.gmail.com>

I absolutely agree with that.  Business are very suspicious of software that
they don't have specific rights to.  If money changes hands, an implied
contract exists even if no explicit contract is executed.  It is also much
easier for an IT manager to justify a low-cost option than a no-cost option
because it is not in the nature of business executives to trust something
that is free.

In fact, the $2000 I mentioned in my email above was forced on the
programmers.  This occurred two years after we left the university, and we
knew the university would take the money anyway, so we tried to give the
rights to the company for free.  They insisted on selling, so I suggested a
price of $1, but they said that wasn't enough.  So I said $2000 and that is
what they paid the university.

John

On Thu, Feb 28, 2008 at 2:36 PM, Robert Kern <robert.kern at gmail.com> wrote:

> On Thu, Feb 28, 2008 at 2:27 PM, Matthew Brett <matthew.brett at gmail.com>
> wrote:
> > >  With the bundle - yes of course.  I mean, if the bundle becomes the
> >  >  defacto standard for deploying python, numpy etc, and the charges
> >  >  worry people, then they may be less likely to try it.  I've no idea
> >  >  whether that will be a big factor - I guess it's difficult to say.
> >
> >  For example - imagine the following scenario.  Someone moderately
> >  junior has just joined a company or government institution.  They
> >  become keen on python, start playing with python, VTK and so on, and
> >  try and persuade others in the company to try it.  If they find they
> >  have to ask the accounts people for money before they install the
> >  bundle, or they have to build it all from scratch, they may not, which
> >  means lost users.
>
> Without EPD, they only have the latter alternative, so I'm not really
> sure how the presence of EPD can harm anything.
>
> Let me be clear on one thing which people may be fearing: we will not
> stop making separate, freely available binary releases of numpy and
> scipy. Nor will we stop anyone else from making such binaries.
>
> We are interested in making money by *adding* services, not holding
> them hostage.
>
> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless
> enigma that is made terrible by our own mad attempt to interpret it as
> though it had an underlying truth."
>  -- Umberto Eco
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>



-- 
John Ollinger
University of Wisconsin
Waisman Center, T233
1500 Highland Ave
Madison, WI 53711
http://brainimaging.waisman.wisc.edu/~jjo/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080228/8c6f16b8/attachment.html>

From matthew.brett at gmail.com  Thu Feb 28 15:50:26 2008
From: matthew.brett at gmail.com (Matthew Brett)
Date: Thu, 28 Feb 2008 20:50:26 +0000
Subject: [SciPy-dev] ANN: Enthought Python Distribution - Beta
In-Reply-To: <Mahogany-0.67.0-300-20080228-154501.00@american.edu>
References: <733AFCE4-50FA-4A79-B032-B0965F75E434@enthought.com>
	<5b9ba9310802272027u689d755by4af6ca07b4b20baa@mail.gmail.com>
	<3d375d730802272118t26ea170cr8a63023d4a5243cb@mail.gmail.com>
	<5b9ba9310802281021v2478dd59ycaabe21bb347c5ed@mail.gmail.com>
	<3d375d730802281124v4246fff7o7e6d02dd83d770f5@mail.gmail.com>
	<1e2af89e0802281203x32c3e2f8v5367bd1383dfbdcc@mail.gmail.com>
	<Mahogany-0.67.0-300-20080228-154501.00@american.edu>
Message-ID: <1e2af89e0802281250t45a2e498l5473f4941df731d7@mail.gmail.com>

>  But the most important things to stimulate interest
>  from government and large business is an established
>  reputation and the availability of paid support.

Yes, hence the Redhat / Fedora model, as compared to the original Suse
model.  But if Suse had been the only Linux distribution, and a first
timer had to install Suse linux from source, Linux would not be
popular.  I imagine that's why Suse went for the Redhat / Fedora model
in the end.   It seems to me that paid support is huge bonus and an
active encouragement for those who want it, but having to pay for the
original download before assessing it would be a deterrent.

Matthew


From david at ar.media.kyoto-u.ac.jp  Fri Feb 29 00:12:15 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Fri, 29 Feb 2008 14:12:15 +0900
Subject: [SciPy-dev] Experience with Goto's BLAS
In-Reply-To: <web-97475677@uni-stuttgart.de>
References: <web-97475677@uni-stuttgart.de>
Message-ID: <47C7942F.40303@ar.media.kyoto-u.ac.jp>

Nils Wagner wrote:
> Hi all,
>
> Is there anyone who can report about the usage of Goto's 
> BLAS with respect to numpy/scipy ?
> What can be said about advantages of ACML, MKL, ATLAS and 
> Goto's BLAS ?
> Who can shed light on the differences between the 
> different libraries ?
The big difference to me: one is open source and freely available 
(ATLAS), not the others. Goto BLAS is supposed to be faster than ATLAS, 
but is available only through registration, and is definitely not open 
source; it is based on another approach than ATLAS for optimization 
(ATLAS tries hard to optimize depending on the CPU cache, GOTO focused 
more on minimizing TLB misses: the principle is for example explained in 
"On Reducing TLB Misses in Matrix Multiplication" (2002) by Kazushige 
Goto et al.)

ACML and MKL are binary only, and available only on some platforms: MKL 
is faster than ATLAS on the platforms I have tested (windows and linux) 
for some test cases. Maybe ACML is, too.

cheers,

David


From oliphant at enthought.com  Fri Feb 29 01:49:38 2008
From: oliphant at enthought.com (Travis E. Oliphant)
Date: Fri, 29 Feb 2008 00:49:38 -0600
Subject: [SciPy-dev] ANN: Enthought Python Distribution - Beta
In-Reply-To: <1e2af89e0802281227t34edb062ub440c898604cb66f@mail.gmail.com>
References: <733AFCE4-50FA-4A79-B032-B0965F75E434@enthought.com>	<5b9ba9310802272027u689d755by4af6ca07b4b20baa@mail.gmail.com>	<3d375d730802272118t26ea170cr8a63023d4a5243cb@mail.gmail.com>	<5b9ba9310802281021v2478dd59ycaabe21bb347c5ed@mail.gmail.com>	<3d375d730802281124v4246fff7o7e6d02dd83d770f5@mail.gmail.com>	<1e2af89e0802281203x32c3e2f8v5367bd1383dfbdcc@mail.gmail.com>	<3d375d730802281210l65138b4fi8f2c51915e56093c@mail.gmail.com>	<1e2af89e0802281215n54ec1711ue7881257cb4159fe@mail.gmail.com>
	<1e2af89e0802281227t34edb062ub440c898604cb66f@mail.gmail.com>
Message-ID: <47C7AB02.1010107@enthought.com>

Matthew Brett wrote:
>>  With the bundle - yes of course.  I mean, if the bundle becomes the
>>  defacto standard for deploying python, numpy etc, and the charges
>>  worry people, then they may be less likely to try it.  I've no idea
>>  whether that will be a big factor - I guess it's difficult to say.
>>     
>
> For example - imagine the following scenario.  Someone moderately
> junior has just joined a company or government institution.  They
> become keen on python, start playing with python, VTK and so on, and
> try and persuade others in the company to try it.  If they find they
> have to ask the accounts people for money before they install the
> bundle, or they have to build it all from scratch, they may not, which
> means lost users.
>   

We try to advertise and make very clear that there is no charge at all 
even for commercial users to just try EPD.   That same moderately junior 
person could get EPD from the internet, install it and show all their 
friends. 

The only thing we ask is that if a company starts making substantial use 
of EPD, they help defer the costs of producing it.  We are really very 
keen on having as many people as possible use the tools.  

We have had requests for a supported binary installation for a long 
time.   So, we are responding. 

Best regards,


-Travis O.



From oliphant at enthought.com  Fri Feb 29 02:03:25 2008
From: oliphant at enthought.com (Travis E. Oliphant)
Date: Fri, 29 Feb 2008 01:03:25 -0600
Subject: [SciPy-dev] ANN: Enthought Python Distribution - Beta
In-Reply-To: <C9B674023BAA4C498DB6422BD8B8BB510B57EC7E@usatxcms08.tx.usa-spaceops.com>
References: <733AFCE4-50FA-4A79-B032-B0965F75E434@enthought.com><5b9ba9310802272027u689d755by4af6ca07b4b20baa@mail.gmail.com><3d375d730802272118t26ea170cr8a63023d4a5243cb@mail.gmail.com><5b9ba9310802281021v2478dd59ycaabe21bb347c5ed@mail.gmail.com><3d375d730802281124v4246fff7o7e6d02dd83d770f5@mail.gmail.com><1e2af89e0802281203x32c3e2f8v5367bd1383dfbdcc@mail.gmail.com><3d375d730802281210l65138b4fi8f2c51915e56093c@mail.gmail.com><1e2af89e0802281215n54ec1711ue7881257cb4159fe@mail.gmail.com>	<1e2af89e0802281227t34edb062ub440c898604cb66f@mail.gmail.com>
	<C9B674023BAA4C498DB6422BD8B8BB510B57EC7E@usatxcms08.tx.usa-spaceops.com>
Message-ID: <47C7AE3D.5060106@enthought.com>

Friedrich, Robin K wrote:
> That is indeed a valid scenario. On my Linux engineering systems we just built everything from scratch but on our institutional PC systems we like to have
> an MSI ready to go and I have gone so far as to establish the EPD (prior version) as our company standard python installation for those Windows users who
> need it. Of course now that decision puts us in a bind as we will in the future need to establish a contract with Enthought before continuing with this
> standard.
Remember that you can download EPD without paying anything and feel 
perfectly fine about it if you are just trying out the software and have 
not decided to use it in your work. 

Once you decide to make serious use of Python (assuming you will want 
multiple packages), and want the help maintaining binaries, you can 
manage this in many ways:

1) A site-wide yearly subscription that would let you install it on as 
many machines as you like
2) Purchasing individual subscriptions for the users that do rely on it.

We are really hoping that EPD will help more people than it hurts and 
trying to make the terms as agreeable as possible (while still enabling 
us to produce EPD).

Best regards,


-Travis Oliphant
Enthought, Inc.



From dmitrey.kroshko at scipy.org  Fri Feb 29 07:11:05 2008
From: dmitrey.kroshko at scipy.org (dmitrey)
Date: Fri, 29 Feb 2008 14:11:05 +0200
Subject: [SciPy-dev] f2py + f90 file
In-Reply-To: <57377.85.166.22.159.1204024030.squirrel@cens.ioc.ee>
References: <47BDC491.8010501@scipy.org>	<62589.85.166.22.159.1203619400.squirrel@cens.ioc.ee>	<47C3DE2B.8000201@scipy.org>	<56269.85.166.22.159.1204019574.squirrel@cens.ioc.ee>	<47C3E386.2060209@scipy.org>	<56697.85.166.22.159.1204021019.squirrel@cens.ioc.ee>	<47C3ED6A.7000200@scipy.org>
	<57377.85.166.22.159.1204024030.squirrel@cens.ioc.ee>
Message-ID: <47C7F659.1040804@scipy.org>

Pearu, could you take a look at the toms/587 routine (another one 
constrained LLS)?
I guess it could be connected to scipy.
f2py yields lots of bugs when I try to build .so-file.
(I have downloaded the one with option "include (unoptimized) BLAS 
routines" turned on, tgz file ~48 kb with a single file inside 587 that 
I have renamed to toms587.f).

http://netlib.org/cgi-bin/netlibfiles.pl?filename=/toms/587
Here's full output below. (Unfortunately I'm not skilled in Fortran)

Regards, D.


f2py -c -m toms587 toms587.f
running build
running config_cc
unifing config_cc, config, build_clib, build_ext, build commands 
--compiler options
running config_fc
unifing config_fc, config, build_clib, build_ext, build commands 
--fcompiler options
running build_src
building extension "toms587" sources
f2py options: []
f2py:> /tmp/tmphN_0T5/src.linux-x86_64-2.5/toms587module.c
creating /tmp/tmphN_0T5
creating /tmp/tmphN_0T5/src.linux-x86_64-2.5
Reading fortran codes...
        Reading file 'toms587.f' (format:fix,strict)
rmbadname1: Replacing "size" with "size_bn".
crackline: groupcounter=1 groupname={0: '', 1: 'module', 2: 'function', 
3: 'subroutine'}
crackline: Mismatch of blocks encountered. Trying to fix it by assuming 
"end" statement.
Post-processing...
        Block: toms587
                        Block: lsei
                        Block: lsi
                        Block: lpdp
                        Block: wnnls
                        Block: wnlsm
                        Block: wnlit
                        Block: hfti
                        Block: h12
                        Block: diff
                        Block: srotmg
                        Block: scopy
                        Block: sswap
                        Block: snrm2
                        Block: sasum
                        Block: sscal
                        Block: isamax
                        Block: sdot
                        Block: saxpy
                        Block: srotm
                        Block: drotmg
                        Block: dcopy
                        Block: dswap
                        Block: dnrm2
                        Block: dasum
                        Block: dscal
                        Block: idamax
                        Block: ddot
                        Block: daxpy
                        Block: drotm
                        Block: fdump
                        Block: xerabt
                        Block: j4save
                        Block: numxer
                        Block: s88fmt
                        Block: xerclr
                        Block: xerctl
                        Block: xerdmp
                        Block: xermax
                        Block: xerprt
                        Block: xerror
                        Block: xerrwv
                        Block: xersav
                        Block: xgetf
                        Block: xgetua
                        Block: xgetun
                        Block: xsetf
                        Block: xsetua
                        Block: xsetun
                        Block: i1mach
                        Block: clstp
                Block: ran
Post-processing (stage 2)...
Building modules...
        Building module "toms587"...
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "lsei"...
                  lsei(w,me,ma,mg,n,prgopt,x,rnorme,rnorml,mode,ws,ip,[mdw])
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "lsi"...
                  lsi(w,ma,mg,n,prgopt,x,rnorm,mode,ws,ip,[mdw])
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "lpdp"...
                  lpdp(a,m,n1,n2,prgopt,x,wnorm,mode,ws,is,[mda])
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "wnnls"...
                  wnnls(w,me,ma,n,l,prgopt,x,rnorm,mode,iwork,work,[mdw])
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "wnlsm"...
                  
wnlsm(w,mme,ma,n,l,prgopt,x,rnorm,mode,ipivot,itype,wd,h,scale,z,temp,d,[mdw])
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "wnlit"...
                  
wnlit(w,m,n,l,ipivot,itype,h,scale,rnorm,idope,dope,done,[mdw])
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "hfti"...
                  hfti(a,m,b,tau,krank,rnorm,h,g,ip,[mda,n,mdb,nb])
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "h12"...
                  h12(mode,lpivot,l1,u,up,c,ice,icv,ncv,[m,iue])
buildmodule: Expected interface block. Skipping.
                Creating wrapper for Fortran function "diff"("diff")...
                Constructing wrapper function "diff"...
                  diff = diff(x,y)
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "srotmg"...
                  srotmg(sd1,sd2,sx1,sy1,sparam)
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "scopy"...
                  scopy(n,sx,incx,sy,incy)
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "sswap"...
                  sswap(n,sx,incx,sy,incy)
buildmodule: Expected interface block. Skipping.
                Creating wrapper for Fortran function "snrm2"("snrm2")...
                Constructing wrapper function "snrm2"...
                  snrm2 = snrm2(n,sx,incx)
buildmodule: Expected interface block. Skipping.
                Creating wrapper for Fortran function "sasum"("sasum")...
                Constructing wrapper function "sasum"...
                  sasum = sasum(n,sx,incx)
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "sscal"...
                  sscal(n,sa,sx,incx)
buildmodule: Expected interface block. Skipping.
                Creating wrapper for Fortran function "isamax"("isamax")...
                Constructing wrapper function "isamax"...
                  isamax = isamax(n,sx,incx)
buildmodule: Expected interface block. Skipping.
                Creating wrapper for Fortran function "sdot"("sdot")...
                Constructing wrapper function "sdot"...
                  sdot = sdot(n,sx,incx,sy,incy)
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "saxpy"...
                  saxpy(n,sa,sx,incx,sy,incy)
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "srotm"...
                  srotm(n,sx,incx,sy,incy,sparam)
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "drotmg"...
                  drotmg(dd1,dd2,dx1,dy1,dparam)
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "dcopy"...
                  dcopy(n,dx,incx,dy,incy)
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "dswap"...
                  dswap(n,dx,incx,dy,incy)
buildmodule: Expected interface block. Skipping.
                Creating wrapper for Fortran function "dnrm2"("dnrm2")...
                Constructing wrapper function "dnrm2"...
                  dnrm2 = dnrm2(n,dx,incx)
buildmodule: Expected interface block. Skipping.
                Creating wrapper for Fortran function "dasum"("dasum")...
                Constructing wrapper function "dasum"...
                  dasum = dasum(n,dx,incx)
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "dscal"...
                  dscal(n,da,dx,incx)
buildmodule: Expected interface block. Skipping.
                Creating wrapper for Fortran function "idamax"("idamax")...
                Constructing wrapper function "idamax"...
                  idamax = idamax(n,dx,incx)
buildmodule: Expected interface block. Skipping.
                Creating wrapper for Fortran function "ddot"("ddot")...
                Constructing wrapper function "ddot"...
                  ddot = ddot(n,dx,incx,dy,incy)
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "daxpy"...
                  daxpy(n,da,dx,incx,dy,incy)
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "drotm"...
                  drotm(n,dx,incx,dy,incy,dparam)
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "fdump"...
                  fdump()
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "xerabt"...
                  xerabt(messg,[nmessg])
buildmodule: Expected interface block. Skipping.
                Creating wrapper for Fortran function "j4save"("j4save")...
                Constructing wrapper function "j4save"...
                  j4save = j4save(iwhich,ivalue,iset)
buildmodule: Expected interface block. Skipping.
                Creating wrapper for Fortran function "numxer"("numxer")...
                Constructing wrapper function "numxer"...
                  numxer = numxer(nerr)
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "s88fmt"...
                  s88fmt(ivalue,ifmt,[n])
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "xerclr"...
                  xerclr()
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "xerctl"...
                  xerctl(messg1,nmessg,nerr,level,kontrl)
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "xerdmp"...
                  xerdmp()
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "xermax"...
                  xermax(max)
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "xerprt"...
                  xerprt(messg,[nmessg])
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "xerror"...
                  xerror(messg,nerr,level,[nmessg])
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "xerrwv"...
                  xerrwv(messg,nerr,level,ni,i1,i2,nr,r1,r2,[nmessg])
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "xersav"...
                  xersav(messg,nmessg,nerr,level,icount)
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "xgetf"...
                  xgetf(kontrl)
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "xgetua"...
                  xgetua(iunit,n)
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "xgetun"...
                  xgetun(iunit)
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "xsetf"...
                  xsetf(kontrl)
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "xsetua"...
                  xsetua(iunit,n)
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "xsetun"...
                  xsetun(iunit)
buildmodule: Expected interface block. Skipping.
                Creating wrapper for Fortran function "i1mach"("i1mach")...
                Constructing wrapper function "i1mach"...
                  i1mach = i1mach(i)
buildmodule: Expected interface block. Skipping.
                Constructing wrapper function "clstp"...
                  clstp(klog,cond,istat)
        Wrote C/API module "toms587" to file 
"/tmp/tmphN_0T5/src.linux-x86_64-2.5/toms587module.c"
        Fortran 77 wrappers are saved to 
"/tmp/tmphN_0T5/src.linux-x86_64-2.5/toms587-f2pywrappers.f"
  adding '/tmp/tmphN_0T5/src.linux-x86_64-2.5/fortranobject.c' to sources.
  adding '/tmp/tmphN_0T5/src.linux-x86_64-2.5' to include_dirs.
copying /usr/lib/python2.5/site-packages/numpy/f2py/src/fortranobject.c 
-> /tmp/tmphN_0T5/src.linux-x86_64-2.5
copying /usr/lib/python2.5/site-packages/numpy/f2py/src/fortranobject.h 
-> /tmp/tmphN_0T5/src.linux-x86_64-2.5
  adding '/tmp/tmphN_0T5/src.linux-x86_64-2.5/toms587-f2pywrappers.f' to 
sources.
running build_ext
customize UnixCCompiler
customize UnixCCompiler using build_ext
customize GnuFCompiler
Found executable /usr/bin/g77
gnu: no Fortran 90 compiler found
gnu: no Fortran 90 compiler found
customize GnuFCompiler
gnu: no Fortran 90 compiler found
gnu: no Fortran 90 compiler found
customize GnuFCompiler using build_ext
building 'toms587' extension
compiling C sources
C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O2 -Wall 
-Wstrict-prototypes -fPIC

creating /tmp/tmphN_0T5/tmp
creating /tmp/tmphN_0T5/tmp/tmphN_0T5
creating /tmp/tmphN_0T5/tmp/tmphN_0T5/src.linux-x86_64-2.5
compile options: '-I/tmp/tmphN_0T5/src.linux-x86_64-2.5 
-I/usr/lib/python2.5/site-packages/numpy/core/include 
-I/usr/include/python2.5 -c'
gcc: /tmp/tmphN_0T5/src.linux-x86_64-2.5/toms587module.c
gcc: /tmp/tmphN_0T5/src.linux-x86_64-2.5/fortranobject.c
compiling Fortran sources
Fortran f77 compiler: /usr/bin/g77 -g -Wall -fno-second-underscore -fPIC 
-O3 -funroll-loops -march=athlon64 -mmmx -m3dnow -msse2 -msse
compile options: '-I/tmp/tmphN_0T5/src.linux-x86_64-2.5 
-I/usr/lib/python2.5/site-packages/numpy/core/include 
-I/usr/include/python2.5 -c'
g77:f77: toms587.f
toms587.f: In subroutine `lsei':
In file included from toms587.f:0:
toms587.f:463: warning: 'imax' might be used uninitialized in this function
toms587.f: In subroutine `lsi':
toms587.f:813: warning:
         IP(2) = N + MAX0(M,N) + (MG+2)*(N+7)
            ^
Array element value at (^) out of defined range
toms587.f: In subroutine `lpdp':
toms587.f:1149: warning:
         IS(2) = 0
            ^
Array element value at (^) out of defined range
toms587.f:1193: warning:
         IS(2) = 0
            ^
Array element value at (^) out of defined range
toms587.f: In subroutine `wnnls':
toms587.f:1496: warning:
      20 IF (.NOT.(IWORK(2).GT.0)) GO TO 40
                         ^
Array element value at (^) out of defined range
toms587.f:1498: warning:
         IF (.NOT.(IWORK(2).LT.LIW)) GO TO 30
                         ^
Array element value at (^) out of defined range
toms587.f: In subroutine `wnlsm':
toms587.f:1603: warning: 'alamda' might be used uninitialized in this 
function
toms587.f:1603: warning: 'alpha' might be used uninitialized in this 
function
toms587.f:1603: warning: 'alsq' might be used uninitialized in this function
toms587.f:1603: warning: 'bnorm' might be used uninitialized in this 
function
toms587.f:1603: warning: 'eanorm' might be used uninitialized in this 
function
toms587.f:1608: warning: 'hitcon' might be used uninitialized in this 
function
toms587.f:1608: warning: 'feasbl' might be used uninitialized in this 
function
toms587.f:1608: warning: 'pos' might be used uninitialized in this function
toms587.f:1637: warning: '__g77_ASSIGN_igo991' might be used 
uninitialized in this function
toms587.f:1643: warning: '__g77_ASSIGN_igo986' might be used 
uninitialized in this function
toms587.f:1649: warning: '__g77_ASSIGN_igo983' might be used 
uninitialized in this function
toms587.f:1657: warning: '__g77_ASSIGN_igo980' might be used 
uninitialized in this function
toms587.f:1749: warning: 'iter' might be used uninitialized in this function
toms587.f:1750: warning: 'itmax' might be used uninitialized in this 
function
toms587.f:1752: warning: 'lp1' might be used uninitialized in this function
toms587.f:1754: warning: 'nsp1' might be used uninitialized in this function
toms587.f:1756: warning: 'nm1' might be used uninitialized in this function
toms587.f:1757: warning: 'l1' might be used uninitialized in this function
toms587.f:1822: warning: 'krank' might be used uninitialized in this 
function
toms587.f:1826: warning: 'niv1' might be used uninitialized in this function
toms587.f:1859: warning: 'jcon' might be used uninitialized in this function
toms587.f: In subroutine `wnlit':
toms587.f:2237: warning: 'hbar' might be used uninitialized in this function
toms587.f:2242: warning: 'indep' might be used uninitialized in this 
function
toms587.f:2333: warning: 'max' might be used uninitialized in this function
toms587.f: In subroutine `srotmg':
toms587.f:3070: warning: 'sh21' might be used uninitialized in this function
toms587.f:3071: warning: 'sh12' might be used uninitialized in this function
toms587.f:3091: warning: 'sh11' might be used uninitialized in this function
toms587.f:3092: warning: 'sh22' might be used uninitialized in this function
toms587.f: In function `snrm2':
toms587.f:3328: warning: 'xmax' might be used uninitialized in this function
toms587.f: In subroutine `drotmg':
toms587.f:3817: warning: 'dh11' might be used uninitialized in this function
toms587.f:3817: warning: 'dh21' might be used uninitialized in this function
toms587.f:3818: warning: 'dh12' might be used uninitialized in this function
toms587.f:3818: warning: 'dh22' might be used uninitialized in this function
toms587.f: In function `dnrm2':
toms587.f:4219: warning: 'xmax' might be used uninitialized in this function
toms587.f: In subroutine `clstp':
toms587.f:6131: warning: 'bnorm' might be used uninitialized in this 
function
toms587.f:6408: warning: 'mepma' might be used uninitialized in this 
function
toms587.f: Outside of any program unit:
toms587.f:6667:
       3    1    2    0    2
       1    2
Label at (1) invalid with continuation line indicator at (2) [info -f 
g77 M LEX]
toms587.f:6667:
       3    1    2    0    2
            ^
Continuation indicator at (^) invalid on first non-comment line of file 
or following END or INCLUDE [info -f g77 M LEX]
toms587.f:6668:
      1.     1000.     1000.
       ^
Non-numeric character at (^) in label field [info -f g77 M LEX]
toms587.f:6669:
       3    1    2    1    2
       1    2
Label at (1) invalid with continuation line indicator at (2) [info -f 
g77 M LEX]
toms587.f:6669:
       3    1    2    1    2
            ^
Continuation indicator at (^) invalid on first non-comment line of file 
or following END or INCLUDE [info -f g77 M LEX]
toms587.f:6670:
      1.     1000.     1000.
       ^
Non-numeric character at (^) in label field [info -f g77 M LEX]
toms587.f:6671:
       3    1    2    2    2
       1    2
Label at (1) invalid with continuation line indicator at (2) [info -f 
g77 M LEX]
toms587.f:6671:
       3    1    2    2    2
            ^
Continuation indicator at (^) invalid on first non-comment line of file 
or following END or INCLUDE [info -f g77 M LEX]
toms587.f:6672:
   1000.     1000.     1000.
       ^
Non-numeric character at (^) in label field [info -f g77 M LEX]
toms587.f:6673:
       4    2    2    2    3
       1    2
Label at (1) invalid with continuation line indicator at (2) [info -f 
g77 M LEX]
toms587.f:6673:
       4    2    2    2    3
            ^
Continuation indicator at (^) invalid on first non-comment line of file 
or following END or INCLUDE [info -f g77 M LEX]
toms587.f:6674:
   1000.     1000.     1000.
       ^
Non-numeric character at (^) in label field [info -f g77 M LEX]
toms587.f:6675:
       5    3    2    2    4
       1    2
Label at (1) invalid with continuation line indicator at (2) [info -f 
g77 M LEX]
toms587.f:6675:
       5    3    2    2    4
            ^
Continuation indicator at (^) invalid on first non-comment line of file 
or following END or INCLUDE [info -f g77 M LEX]
toms587.f:6676:
   10000.    1000.     1000.
   1    2
Label at (1) invalid with continuation line indicator at (2) [info -f 
g77 M LEX]
toms587.f:6676:
   10000.    1000.     1000.
        ^
Continuation indicator at (^) invalid on first non-comment line of file 
or following END or INCLUDE [info -f g77 M LEX]
toms587.f:6677:
       0    0    0    0   -1
       1         2
Extra label definition 00 at (2) -- perhaps previous label definition 0 
at (1) should have CONTINUE statement?
toms587.f:6677:
       0    0    0    0   -1
                          ^
Statement at (^) begins with invalid token [info -f g77 M LEX]
toms587.f: In subroutine `lsei':
In file included from toms587.f:0:
toms587.f:463: warning: 'imax' might be used uninitialized in this function
toms587.f: In subroutine `lsi':
toms587.f:813: warning:
         IP(2) = N + MAX0(M,N) + (MG+2)*(N+7)
            ^
Array element value at (^) out of defined range
toms587.f: In subroutine `lpdp':
toms587.f:1149: warning:
         IS(2) = 0
            ^
Array element value at (^) out of defined range
toms587.f:1193: warning:
         IS(2) = 0
            ^
Array element value at (^) out of defined range
toms587.f: In subroutine `wnnls':
toms587.f:1496: warning:
      20 IF (.NOT.(IWORK(2).GT.0)) GO TO 40
                         ^
Array element value at (^) out of defined range
toms587.f:1498: warning:
         IF (.NOT.(IWORK(2).LT.LIW)) GO TO 30
                         ^
Array element value at (^) out of defined range
toms587.f: In subroutine `wnlsm':
toms587.f:1603: warning: 'alamda' might be used uninitialized in this 
function
toms587.f:1603: warning: 'alpha' might be used uninitialized in this 
function
toms587.f:1603: warning: 'alsq' might be used uninitialized in this function
toms587.f:1603: warning: 'bnorm' might be used uninitialized in this 
function
toms587.f:1603: warning: 'eanorm' might be used uninitialized in this 
function
toms587.f:1608: warning: 'hitcon' might be used uninitialized in this 
function
toms587.f:1608: warning: 'feasbl' might be used uninitialized in this 
function
toms587.f:1608: warning: 'pos' might be used uninitialized in this function
toms587.f:1637: warning: '__g77_ASSIGN_igo991' might be used 
uninitialized in this function
toms587.f:1643: warning: '__g77_ASSIGN_igo986' might be used 
uninitialized in this function
toms587.f:1649: warning: '__g77_ASSIGN_igo983' might be used 
uninitialized in this function
toms587.f:1657: warning: '__g77_ASSIGN_igo980' might be used 
uninitialized in this function
toms587.f:1749: warning: 'iter' might be used uninitialized in this function
toms587.f:1750: warning: 'itmax' might be used uninitialized in this 
function
toms587.f:1752: warning: 'lp1' might be used uninitialized in this function
toms587.f:1754: warning: 'nsp1' might be used uninitialized in this function
toms587.f:1756: warning: 'nm1' might be used uninitialized in this function
toms587.f:1757: warning: 'l1' might be used uninitialized in this function
toms587.f:1822: warning: 'krank' might be used uninitialized in this 
function
toms587.f:1826: warning: 'niv1' might be used uninitialized in this function
toms587.f:1859: warning: 'jcon' might be used uninitialized in this function
toms587.f: In subroutine `wnlit':
toms587.f:2237: warning: 'hbar' might be used uninitialized in this function
toms587.f:2242: warning: 'indep' might be used uninitialized in this 
function
toms587.f:2333: warning: 'max' might be used uninitialized in this function
toms587.f: In subroutine `srotmg':
toms587.f:3070: warning: 'sh21' might be used uninitialized in this function
toms587.f:3071: warning: 'sh12' might be used uninitialized in this function
toms587.f:3091: warning: 'sh11' might be used uninitialized in this function
toms587.f:3092: warning: 'sh22' might be used uninitialized in this function
toms587.f: In function `snrm2':
toms587.f:3328: warning: 'xmax' might be used uninitialized in this function
toms587.f: In subroutine `drotmg':
toms587.f:3817: warning: 'dh11' might be used uninitialized in this function
toms587.f:3817: warning: 'dh21' might be used uninitialized in this function
toms587.f:3818: warning: 'dh12' might be used uninitialized in this function
toms587.f:3818: warning: 'dh22' might be used uninitialized in this function
toms587.f: In function `dnrm2':
toms587.f:4219: warning: 'xmax' might be used uninitialized in this function
toms587.f: In subroutine `clstp':
toms587.f:6131: warning: 'bnorm' might be used uninitialized in this 
function
toms587.f:6408: warning: 'mepma' might be used uninitialized in this 
function
toms587.f: Outside of any program unit:
toms587.f:6667:
       3    1    2    0    2
       1    2
Label at (1) invalid with continuation line indicator at (2) [info -f 
g77 M LEX]
toms587.f:6667:
       3    1    2    0    2
            ^
Continuation indicator at (^) invalid on first non-comment line of file 
or following END or INCLUDE [info -f g77 M LEX]
toms587.f:6668:
      1.     1000.     1000.
       ^
Non-numeric character at (^) in label field [info -f g77 M LEX]
toms587.f:6669:
       3    1    2    1    2
       1    2
Label at (1) invalid with continuation line indicator at (2) [info -f 
g77 M LEX]
toms587.f:6669:
       3    1    2    1    2
            ^
Continuation indicator at (^) invalid on first non-comment line of file 
or following END or INCLUDE [info -f g77 M LEX]
toms587.f:6670:
      1.     1000.     1000.
       ^
Non-numeric character at (^) in label field [info -f g77 M LEX]
toms587.f:6671:
       3    1    2    2    2
       1    2
Label at (1) invalid with continuation line indicator at (2) [info -f 
g77 M LEX]
toms587.f:6671:
       3    1    2    2    2
            ^
Continuation indicator at (^) invalid on first non-comment line of file 
or following END or INCLUDE [info -f g77 M LEX]
toms587.f:6672:
   1000.     1000.     1000.
       ^
Non-numeric character at (^) in label field [info -f g77 M LEX]
toms587.f:6673:
       4    2    2    2    3
       1    2
Label at (1) invalid with continuation line indicator at (2) [info -f 
g77 M LEX]
toms587.f:6673:
       4    2    2    2    3
            ^
Continuation indicator at (^) invalid on first non-comment line of file 
or following END or INCLUDE [info -f g77 M LEX]
toms587.f:6674:
   1000.     1000.     1000.
       ^
Non-numeric character at (^) in label field [info -f g77 M LEX]
toms587.f:6675:
       5    3    2    2    4
       1    2
Label at (1) invalid with continuation line indicator at (2) [info -f 
g77 M LEX]
toms587.f:6675:
       5    3    2    2    4
            ^
Continuation indicator at (^) invalid on first non-comment line of file 
or following END or INCLUDE [info -f g77 M LEX]
toms587.f:6676:
   10000.    1000.     1000.
   1    2
Label at (1) invalid with continuation line indicator at (2) [info -f 
g77 M LEX]
toms587.f:6676:
   10000.    1000.     1000.
        ^
Continuation indicator at (^) invalid on first non-comment line of file 
or following END or INCLUDE [info -f g77 M LEX]
toms587.f:6677:
       0    0    0    0   -1
       1         2
Extra label definition 00 at (2) -- perhaps previous label definition 0 
at (1) should have CONTINUE statement?
toms587.f:6677:
       0    0    0    0   -1
                          ^
Statement at (^) begins with invalid token [info -f g77 M LEX]
error: Command "/usr/bin/g77 -g -Wall -fno-second-underscore -fPIC -O3 
-funroll-loops -march=athlon64 -mmmx -m3dnow -msse2 -msse 
-I/tmp/tmphN_0T5/src.linux-x86_64-2.5 
-I/usr/lib/python2.5/site-packages/numpy/core/include 
-I/usr/include/python2.5 -c -c toms587.f -o /tmp/tmphN_0T5/toms587.o" 
failed with exit status 1



From aisaac at american.edu  Fri Feb 29 13:27:26 2008
From: aisaac at american.edu (Alan G Isaac)
Date: Fri, 29 Feb 2008 13:27:26 -0500
Subject: [SciPy-dev] could anyone propose University of California
	workers to change bvls license?
In-Reply-To: <47C52773.2000602@scipy.org>
References: <47C52773.2000602@scipy.org>
Message-ID: <Mahogany-0.67.0-1632-20080229-132726.00@american.edu>

On Wed, 27 Feb 2008, dmitrey apparently wrote:
> Could anyone contact to the authors of the routine and 
> propose them make it available in terms of GPL/LGPL or, 
> moreover, BSD license? 

I asked Stark and Parker, and they agreed to release under 
GPL.  I have asked them to specify the GPL version number.
I also asked them to consider the LGPL, but I cannot say
whether they will.

Cheers,
Alan Isaac





From Robin.K.Friedrich at usa-spaceops.com  Fri Feb 29 14:52:30 2008
From: Robin.K.Friedrich at usa-spaceops.com (Friedrich, Robin K)
Date: Fri, 29 Feb 2008 13:52:30 -0600
Subject: [SciPy-dev] ANN: Enthought Python Distribution - Beta
In-Reply-To: <47C7AE3D.5060106@enthought.com>
References: <733AFCE4-50FA-4A79-B032-B0965F75E434@enthought.com><5b9ba9310802272027u689d755by4af6ca07b4b20baa@mail.gmail.com><3d375d730802272118t26ea170cr8a63023d4a5243cb@mail.gmail.com><5b9ba9310802281021v2478dd59ycaabe21bb347c5ed@mail.gmail.com><3d375d730802281124v4246fff7o7e6d02dd83d770f5@mail.gmail.com><1e2af89e0802281203x32c3e2f8v5367bd1383dfbdcc@mail.gmail.com><3d375d730802281210l65138b4fi8f2c51915e56093c@mail.gmail.com><1e2af89e0802281215n54ec1711ue7881257cb4159fe@mail.gmail.com>	<1e2af89e0802281227t34edb062ub440c898604cb66f@mail.gmail.com><C9B674023BAA4C498DB6422BD8B8BB510B57EC7E@usatxcms08.tx.usa-spaceops.com>
	<47C7AE3D.5060106@enthought.com>
Message-ID: <C9B674023BAA4C498DB6422BD8B8BB510B57EC87@usatxcms08.tx.usa-spaceops.com>

Understood. Yes this all sounds very reasonable.
Might I inquire about the availability of the Mac 10.5 EPD bundle? Will it be available prior to PyCon. I want to configure my MacBook with it. Installing
from scratch is not working right now due to VTK and VTK isn't building from source for me on Leopard.
Thanks,
Robin 

-----Original Message-----
From: scipy-dev-bounces at scipy.org [mailto:scipy-dev-bounces at scipy.org] On Behalf Of Travis E. Oliphant
Sent: Friday, February 29, 2008 1:03 AM
To: SciPy Developers List
Subject: Re: [SciPy-dev] ANN: Enthought Python Distribution - Beta

Remember that you can download EPD without paying anything and feel perfectly fine about it if you are just trying out the software and have not decided to
use it in your work. 

Once you decide to make serious use of Python (assuming you will want multiple packages), and want the help maintaining binaries, you can manage this in
many ways:

1) A site-wide yearly subscription that would let you install it on as many machines as you like
2) Purchasing individual subscriptions for the users that do rely on it.

We are really hoping that EPD will help more people than it hurts and trying to make the terms as agreeable as possible (while still enabling us to produce
EPD).

Best regards,


-Travis Oliphant
Enthought, Inc.

_______________________________________________
Scipy-dev mailing list
Scipy-dev at scipy.org
http://projects.scipy.org/mailman/listinfo/scipy-dev


From travis at enthought.com  Fri Feb 29 16:09:51 2008
From: travis at enthought.com (Travis Vaught)
Date: Fri, 29 Feb 2008 15:09:51 -0600
Subject: [SciPy-dev] ANN: Enthought Python Distribution - Beta
In-Reply-To: <C9B674023BAA4C498DB6422BD8B8BB510B57EC87@usatxcms08.tx.usa-spaceops.com>
References: <733AFCE4-50FA-4A79-B032-B0965F75E434@enthought.com><5b9ba9310802272027u689d755by4af6ca07b4b20baa@mail.gmail.com><3d375d730802272118t26ea170cr8a63023d4a5243cb@mail.gmail.com><5b9ba9310802281021v2478dd59ycaabe21bb347c5ed@mail.gmail.com><3d375d730802281124v4246fff7o7e6d02dd83d770f5@mail.gmail.com><1e2af89e0802281203x32c3e2f8v5367bd1383dfbdcc@mail.gmail.com><3d375d730802281210l65138b4fi8f2c51915e56093c@mail.gmail.com><1e2af89e0802281215n54ec1711ue7881257cb4159fe@mail.gmail.com>	<1e2af89e0802281227t34edb062ub440c898604cb66f@mail.gmail.com><C9B674023BAA4C498DB6422BD8B8BB510B57EC7E@usatxcms08.tx.usa-spaceops.com>
	<47C7AE3D.5060106@enthought.com>
	<C9B674023BAA4C498DB6422BD8B8BB510B57EC87@usatxcms08.tx.usa-spaceops.com>
Message-ID: <658D265F-837A-40C8-8135-DF2368DD5E12@enthought.com>


Hey Robin,

On Feb 29, 2008, at 1:52 PM, Friedrich, Robin K wrote:

> Understood. Yes this all sounds very reasonable.
> Might I inquire about the availability of the Mac 10.5 EPD bundle?  
> Will it be available prior to PyCon.

Actually a pre-PyCon release of the Mac OS X version was a 'stretch  
goal' for us.  It depends a bit on how quickly the RedHat version goes  
(we're very close!) and how much more work the 'unknown unknowns' are  
on the Mac.

Travis