From stefan at sun.ac.za  Sun Jun  1 17:39:53 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 1 Jun 2008 23:39:53 +0200
Subject: [SciPy-dev] Namespaces in documentation (was: ANN: NumPy/SciPy
	Documentation Marathon 2008)
In-Reply-To: <1212281702.8410.56.camel@localhost.localdomain>
References: <1211159457.5853.84.camel@glup.physics.ucf.edu>
	<88e473830805190949s44bac124j6e94f91b517c5f20@mail.gmail.com>
	<4831B0D7.5010206@slac.stanford.edu>
	<9457e7c80805191020m5171e209ja4e8018638d1006b@mail.gmail.com>
	<1212281702.8410.56.camel@localhost.localdomain>
Message-ID: <9457e7c80806011439h1925ab46y2e2597a98d660288@mail.gmail.com>

Hi Pauli, all

I postponed this discussion for a while, so that we could write some
documentation and get a feeling for what works and what doesn't.  We
now have enough experience to make an informed decision.

When a person codes, and you find yourself repeating certain
constructs over and over, what do you do?  You create a function or a
short-cut.  We have a similar situation here.  In the documentation,
we're seeing

"import numpy as np"
"import matplotlib.pyplot as plt"

all too often.  We could easily replace the calls to "np" with calls
to "numpy", but it feels clumsy.

"import numpy as np"

is a community standard.  I'd like to repeat that this does *not* mean
that we want to force anyone to use it in their own code; but it *is*
a standard inside numpy, scipy and matplotlib.  As such, I think it is
fair that we encourage our users to make use of it.

I propose we adopt it for the documentation.  I know that the first
argument against it would be that users cannot "cut-and-paste" code
directly into a Python session.  On that front, I have good news.  A
patch has been accepted into IPython that allows *directly* pasting
docstrings, i.e., strings like ">>> x + 3", and executing them.  This
is achieved using the "cpaste" (or %cpaste) command.  Fernando Perez
has committed to providing "np", "sp" and "plt" in the pylab profile,
obtained by running "ipython -pylab".  This should put to rest any
concerns for new users not being able to execute the examples.

The other concern is that some (seasoned) users prefer different
contractions: N, npy, etc.   I'm afraid we cannot accommodate every
taste, and we cannot afford to compromise the documentation because we
cannot agree on a short form of `numpy`.

So, in short, I propose:

1) Using the standard contractions: np for numpy, sp for scipy, plt for pylab
2) When writing examples for functions in a sub-module, make no
further assumptions.  A docstring from fft would therefore use

import numpy.fft      # numpy.fft is not imported by default
z = np.fft.fft2(x)

in an example.

3) See Also sections may refer to sections in the current module
without any prefix, like Pauli suggested.  Therefore, modules in fft
can have a See Also item "fft2", "rfft".  If you want to refer across
modules, provide a prefix, e.g., "linalg.inv" (which translates to
numpy.linalg.inv).  If we can't find the function you are referring to
in the current scope,
we search upwards: file, sub-module, module.   Methods of ndarray are
referred to as `ndarray.ravel`.

The documentation is the public face of NumPy.  I ask that, if you
were one of the people involved in this discussion at the sprint, or
otherwise feel strongly about the topic, you raise your opinion now.
I'd like to settle this issue so that we can grind out many more
docstrings before the week is over.

For those of you who haven't started editing, please register at

http://sd-2116.dedibox.fr/pydocweb

The web framework is fantastic, and makes contributing a cinch.  Every
person on this list has something to contribute, and every five
minutes you donate saves another thirty.

Regards
St?fan

2008/6/1 Pauli Virtanen <pav at iki.fi>:
> ma, 2008-05-19 kello 19:20 +0200, St?fan van der Walt kirjoitti:
>> Hi Johann
>>
>> 2008/5/19 Johann Cohen-Tanugi <cohen at slac.stanford.edu>:
>> > yesterday when I started to modify the doctest I used import numpy. It
>> > is easy enough to change to import numpy as np, but please let's get
>> > that out of the way once and for all. I have no preference between the 2.
>>
>> Keep using numpy.func for now.  When this thread comes to a
>> conclusion, I shall do a search and replace if necessary.
>
> I took the liberty of changing this in
> http://projects.scipy.org/scipy/numpy/wiki/CodingStyleGuidelines
> as I think this issue should be settled sometime soon as changing the
> examples later is not very productive work.
>
> It now says:
>
> - Docstring examples may assume ``import numpy`` in numpy
>  and ``import scipy`` in scipy.
>
> - ``See Also`` sections should use the full namespaced name.
>  For targets in the same module as the documented one, omitting
>  all namespace prefixes is OK, though.
>
> These choices seemed simple, understandable without knowing the
> consensus about "good import abbreviations", and avoiding the
> "from foo import *" practice.
>
> If you have objections, let's restart the discussion.
>
>        Pauli


From alan at ajackson.org  Sun Jun  1 21:27:34 2008
From: alan at ajackson.org (Alan Jackson)
Date: Sun, 1 Jun 2008 20:27:34 -0500
Subject: [SciPy-dev] docstring sd-2116.dedibox.fr problem
Message-ID: <20080601202734.6f52cc8b@ajackson.org>

I can view the docstrings, but I can no longer preview or save them.

I eventually get a timeout.

-- 
-----------------------------------------------------------------------
| Alan K. Jackson            | To see a World in a Grain of Sand      |
| alan at ajackson.org          | And a Heaven in a Wild Flower,         |
| www.ajackson.org           | Hold Infinity in the palm of your hand |
| Houston, Texas             | And Eternity in an hour. - Blake       |
-----------------------------------------------------------------------


From cohen at slac.stanford.edu  Mon Jun  2 04:23:28 2008
From: cohen at slac.stanford.edu (Johann Cohen-Tanugi)
Date: Mon, 02 Jun 2008 10:23:28 +0200
Subject: [SciPy-dev] Namespaces in documentation
In-Reply-To: <9457e7c80806011439h1925ab46y2e2597a98d660288@mail.gmail.com>
References: <1211159457.5853.84.camel@glup.physics.ucf.edu>	<88e473830805190949s44bac124j6e94f91b517c5f20@mail.gmail.com>	<4831B0D7.5010206@slac.stanford.edu>	<9457e7c80805191020m5171e209ja4e8018638d1006b@mail.gmail.com>	<1212281702.8410.56.camel@localhost.localdomain>
	<9457e7c80806011439h1925ab46y2e2597a98d660288@mail.gmail.com>
Message-ID: <4843AE00.7050208@slac.stanford.edu>

hi there,

St?fan van der Walt wrote:
> Hi Pauli, all
>
> I postponed this discussion for a while, so that we could write some
> documentation and get a feeling for what works and what doesn't.  We
> now have enough experience to make an informed decision.
>
> When a person codes, and you find yourself repeating certain
> constructs over and over, what do you do?  You create a function or a
> short-cut.  We have a similar situation here.  In the documentation,
> we're seeing
>
> "import numpy as np"
> "import matplotlib.pyplot as plt"
>
> all too often.  We could easily replace the calls to "np" with calls
> to "numpy", but it feels clumsy.
>
> "import numpy as np"
>
> is a community standard.  I'd like to repeat that this does *not* mean
> that we want to force anyone to use it in their own code; but it *is*
> a standard inside numpy, scipy and matplotlib.  As such, I think it is
> fair that we encourage our users to make use of it.
>
> I propose we adopt it for the documentation.  I know that the first
> argument against it would be that users cannot "cut-and-paste" code
> directly into a Python session.  On that front, I have good news.  A
> patch has been accepted into IPython that allows *directly* pasting
> docstrings, i.e., strings like ">>> x + 3", and executing them.  This
> is achieved using the "cpaste" (or %cpaste) command.  Fernando Perez
> has committed to providing "np", "sp" and "plt" in the pylab profile,
> obtained by running "ipython -pylab".  This should put to rest any
> concerns for new users not being able to execute the examples.
>
>   
1) I think that I would also prefer np to the full numpy. I have been 
editing some docstrings and sometimes I feel that "numpy." clutters the 
easy reading of the example a bit too much
2) On the other hand, I must have missed something about the ipython 
patch : using the -pylab profile isn't going to mean that people must 
have matplotlib installed in order to cut-and-paste the docstring 
examples? That would seem counter-intuitive at best! As a matter of 
fact, why does it have to live in the pylab profile?

best,
JCT

> The other concern is that some (seasoned) users prefer different
> contractions: N, npy, etc.   I'm afraid we cannot accommodate every
> taste, and we cannot afford to compromise the documentation because we
> cannot agree on a short form of `numpy`.
>
> So, in short, I propose:
>
> 1) Using the standard contractions: np for numpy, sp for scipy, plt for pylab
> 2) When writing examples for functions in a sub-module, make no
> further assumptions.  A docstring from fft would therefore use
>
> import numpy.fft      # numpy.fft is not imported by default
> z = np.fft.fft2(x)
>
> in an example.
>
> 3) See Also sections may refer to sections in the current module
> without any prefix, like Pauli suggested.  Therefore, modules in fft
> can have a See Also item "fft2", "rfft".  If you want to refer across
> modules, provide a prefix, e.g., "linalg.inv" (which translates to
> numpy.linalg.inv).  If we can't find the function you are referring to
> in the current scope,
> we search upwards: file, sub-module, module.   Methods of ndarray are
> referred to as `ndarray.ravel`.
>
> The documentation is the public face of NumPy.  I ask that, if you
> were one of the people involved in this discussion at the sprint, or
> otherwise feel strongly about the topic, you raise your opinion now.
> I'd like to settle this issue so that we can grind out many more
> docstrings before the week is over.
>
> For those of you who haven't started editing, please register at
>
> http://sd-2116.dedibox.fr/pydocweb
>
> The web framework is fantastic, and makes contributing a cinch.  Every
> person on this list has something to contribute, and every five
> minutes you donate saves another thirty.
>
> Regards
> St?fan
>
> 2008/6/1 Pauli Virtanen <pav at iki.fi>:
>   
>> ma, 2008-05-19 kello 19:20 +0200, St?fan van der Walt kirjoitti:
>>     
>>> Hi Johann
>>>
>>> 2008/5/19 Johann Cohen-Tanugi <cohen at slac.stanford.edu>:
>>>       
>>>> yesterday when I started to modify the doctest I used import numpy. It
>>>> is easy enough to change to import numpy as np, but please let's get
>>>> that out of the way once and for all. I have no preference between the 2.
>>>>         
>>> Keep using numpy.func for now.  When this thread comes to a
>>> conclusion, I shall do a search and replace if necessary.
>>>       
>> I took the liberty of changing this in
>> http://projects.scipy.org/scipy/numpy/wiki/CodingStyleGuidelines
>> as I think this issue should be settled sometime soon as changing the
>> examples later is not very productive work.
>>
>> It now says:
>>
>> - Docstring examples may assume ``import numpy`` in numpy
>>  and ``import scipy`` in scipy.
>>
>> - ``See Also`` sections should use the full namespaced name.
>>  For targets in the same module as the documented one, omitting
>>  all namespace prefixes is OK, though.
>>
>> These choices seemed simple, understandable without knowing the
>> consensus about "good import abbreviations", and avoiding the
>> "from foo import *" practice.
>>
>> If you have objections, let's restart the discussion.
>>
>>        Pauli
>>     
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>   


From stefan at sun.ac.za  Mon Jun  2 04:33:29 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 2 Jun 2008 10:33:29 +0200
Subject: [SciPy-dev] docstring sd-2116.dedibox.fr problem
In-Reply-To: <20080601202734.6f52cc8b@ajackson.org>
References: <20080601202734.6f52cc8b@ajackson.org>
Message-ID: <9457e7c80806020133k347bb284h6d4d924ac4c8c755@mail.gmail.com>

Hi Alan

Thank you for bringing this to our attention.  We should have the
problem sorted out by this afternoon.

Sorry for any inconvenience caused!

Regards
St?fan

2008/6/2 Alan Jackson <alan at ajackson.org>:
> I can view the docstrings, but I can no longer preview or save them.
>
> I eventually get a timeout.


From stefan at sun.ac.za  Mon Jun  2 04:53:13 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 2 Jun 2008 10:53:13 +0200
Subject: [SciPy-dev] Namespaces in documentation
In-Reply-To: <4843AE00.7050208@slac.stanford.edu>
References: <1211159457.5853.84.camel@glup.physics.ucf.edu>
	<88e473830805190949s44bac124j6e94f91b517c5f20@mail.gmail.com>
	<4831B0D7.5010206@slac.stanford.edu>
	<9457e7c80805191020m5171e209ja4e8018638d1006b@mail.gmail.com>
	<1212281702.8410.56.camel@localhost.localdomain>
	<9457e7c80806011439h1925ab46y2e2597a98d660288@mail.gmail.com>
	<4843AE00.7050208@slac.stanford.edu>
Message-ID: <9457e7c80806020153g3f2f016ds42322eeeccf9d3c3@mail.gmail.com>

Hi Johann

2008/6/2 Johann Cohen-Tanugi <cohen at slac.stanford.edu>:
> 2) On the other hand, I must have missed something about the ipython
> patch : using the -pylab profile isn't going to mean that people must
> have matplotlib installed in order to cut-and-paste the docstring
> examples? That would seem counter-intuitive at best! As a matter of
> fact, why does it have to live in the pylab profile?

I should rephrase: under the pylab profile, which many people use,
numpy and pyplot will now be available as np and plt.  In addition, we
will also provide a "numpy" profile, that  provides numpy as np.

So a new user will

a) Install IPython, numpy and optionally matplotlib
b) Run "ipython -p numpy" or "ipython -pylab" (if they want to plot things)
c) Type "cpaste" and paste in an example from the docstrings

Regards
St?fan


From cohen at slac.stanford.edu  Mon Jun  2 04:47:11 2008
From: cohen at slac.stanford.edu (Johann Cohen-Tanugi)
Date: Mon, 02 Jun 2008 10:47:11 +0200
Subject: [SciPy-dev] Namespaces in documentation
In-Reply-To: <9457e7c80806020153g3f2f016ds42322eeeccf9d3c3@mail.gmail.com>
References: <1211159457.5853.84.camel@glup.physics.ucf.edu>	<88e473830805190949s44bac124j6e94f91b517c5f20@mail.gmail.com>	<4831B0D7.5010206@slac.stanford.edu>	<9457e7c80805191020m5171e209ja4e8018638d1006b@mail.gmail.com>	<1212281702.8410.56.camel@localhost.localdomain>	<9457e7c80806011439h1925ab46y2e2597a98d660288@mail.gmail.com>	<4843AE00.7050208@slac.stanford.edu>
	<9457e7c80806020153g3f2f016ds42322eeeccf9d3c3@mail.gmail.com>
Message-ID: <4843B38F.3070401@slac.stanford.edu>

ok, the new numpy profile was the missing piece of info :)
Anyway, +1 for np/sp in docstrings.
Johann

St?fan van der Walt wrote:
> Hi Johann
>
> 2008/6/2 Johann Cohen-Tanugi <cohen at slac.stanford.edu>:
>   
>> 2) On the other hand, I must have missed something about the ipython
>> patch : using the -pylab profile isn't going to mean that people must
>> have matplotlib installed in order to cut-and-paste the docstring
>> examples? That would seem counter-intuitive at best! As a matter of
>> fact, why does it have to live in the pylab profile?
>>     
>
> I should rephrase: under the pylab profile, which many people use,
> numpy and pyplot will now be available as np and plt.  In addition, we
> will also provide a "numpy" profile, that  provides numpy as np.
>
> So a new user will
>
> a) Install IPython, numpy and optionally matplotlib
> b) Run "ipython -p numpy" or "ipython -pylab" (if they want to plot things)
> c) Type "cpaste" and paste in an example from the docstrings
>
> Regards
> St?fan
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>   


From bsouthey at gmail.com  Mon Jun  2 09:51:33 2008
From: bsouthey at gmail.com (Bruce Southey)
Date: Mon, 02 Jun 2008 08:51:33 -0500
Subject: [SciPy-dev] Namespaces in documentation
In-Reply-To: <9457e7c80806020153g3f2f016ds42322eeeccf9d3c3@mail.gmail.com>
References: <1211159457.5853.84.camel@glup.physics.ucf.edu>	<88e473830805190949s44bac124j6e94f91b517c5f20@mail.gmail.com>	<4831B0D7.5010206@slac.stanford.edu>	<9457e7c80805191020m5171e209ja4e8018638d1006b@mail.gmail.com>	<1212281702.8410.56.camel@localhost.localdomain>	<9457e7c80806011439h1925ab46y2e2597a98d660288@mail.gmail.com>	<4843AE00.7050208@slac.stanford.edu>
	<9457e7c80806020153g3f2f016ds42322eeeccf9d3c3@mail.gmail.com>
Message-ID: <4843FAE5.8030507@gmail.com>

St?fan van der Walt wrote:
> Hi Johann
>
> 2008/6/2 Johann Cohen-Tanugi <cohen at slac.stanford.edu>:
>   
>> 2) On the other hand, I must have missed something about the ipython
>> patch : using the -pylab profile isn't going to mean that people must
>> have matplotlib installed in order to cut-and-paste the docstring
>> examples? That would seem counter-intuitive at best! As a matter of
>> fact, why does it have to live in the pylab profile?
>>     
>
> I should rephrase: under the pylab profile, which many people use,
> numpy and pyplot will now be available as np and plt.  In addition, we
> will also provide a "numpy" profile, that  provides numpy as np.
>
> So a new user will
>
> a) Install IPython, numpy and optionally matplotlib
> b) Run "ipython -p numpy" or "ipython -pylab" (if they want to plot things)
> c) Type "cpaste" and paste in an example from the docstrings
>
> Regards
> St?fan
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
>   
Hi,
Why do you say '... and optionally matplotlib'?
I do not use or even known IPython but in the example Nathan provided 
you have:

>>> import numpy as np
>>> import matplotlib.pyplot as plt

So if it is optional, the second import will fail and so will all the rest of the code that uses 'plt'. But a user may not understand why especially if pasted in as a block of code in an shell or interactive environment (assuming that the environment does not crash). Further step 2 indicates that the import is inappropriate for IPython. 

This really illustrates the need for simple NumPy only and SciPy only self-contained examples plus these more elaborate self-contained
examples. This also ignore the issue that this is documentation about NumPy and SciPy not matplotlib and about having an graphical environment to see the plot.

Bruce







From cohen at slac.stanford.edu  Mon Jun  2 10:05:19 2008
From: cohen at slac.stanford.edu (Johann Cohen-Tanugi)
Date: Mon, 02 Jun 2008 16:05:19 +0200
Subject: [SciPy-dev] Namespaces in documentation
In-Reply-To: <4843FAE5.8030507@gmail.com>
References: <1211159457.5853.84.camel@glup.physics.ucf.edu>	<88e473830805190949s44bac124j6e94f91b517c5f20@mail.gmail.com>	<4831B0D7.5010206@slac.stanford.edu>	<9457e7c80805191020m5171e209ja4e8018638d1006b@mail.gmail.com>	<1212281702.8410.56.camel@localhost.localdomain>	<9457e7c80806011439h1925ab46y2e2597a98d660288@mail.gmail.com>	<4843AE00.7050208@slac.stanford.edu>	<9457e7c80806020153g3f2f016ds42322eeeccf9d3c3@mail.gmail.com>
	<4843FAE5.8030507@gmail.com>
Message-ID: <4843FE1F.9000209@slac.stanford.edu>

I think that what Stefan meant is either
1) you have ipython/numpy and then you would run ipython -numpy
2) or optionally you also have matplotlib and then you would run ipython 
-pylab

and in *both* cases the cpaste of the docstrings exemple will work.
hth,
Johann

Bruce Southey wrote:
> St?fan van der Walt wrote:
>   
>> Hi Johann
>>
>> 2008/6/2 Johann Cohen-Tanugi <cohen at slac.stanford.edu>:
>>   
>>     
>>> 2) On the other hand, I must have missed something about the ipython
>>> patch : using the -pylab profile isn't going to mean that people must
>>> have matplotlib installed in order to cut-and-paste the docstring
>>> examples? That would seem counter-intuitive at best! As a matter of
>>> fact, why does it have to live in the pylab profile?
>>>     
>>>       
>> I should rephrase: under the pylab profile, which many people use,
>> numpy and pyplot will now be available as np and plt.  In addition, we
>> will also provide a "numpy" profile, that  provides numpy as np.
>>
>> So a new user will
>>
>> a) Install IPython, numpy and optionally matplotlib
>> b) Run "ipython -p numpy" or "ipython -pylab" (if they want to plot things)
>> c) Type "cpaste" and paste in an example from the docstrings
>>
>> Regards
>> St?fan
>> _______________________________________________
>> Scipy-dev mailing list
>> Scipy-dev at scipy.org
>> http://projects.scipy.org/mailman/listinfo/scipy-dev
>>
>>   
>>     
> Hi,
> Why do you say '... and optionally matplotlib'?
> I do not use or even known IPython but in the example Nathan provided 
> you have:
>
>   
>>>> import numpy as np
>>>> import matplotlib.pyplot as plt
>>>>         
>
> So if it is optional, the second import will fail and so will all the rest of the code that uses 'plt'. But a user may not understand why especially if pasted in as a block of code in an shell or interactive environment (assuming that the environment does not crash). Further step 2 indicates that the import is inappropriate for IPython. 
>
> This really illustrates the need for simple NumPy only and SciPy only self-contained examples plus these more elaborate self-contained
> examples. This also ignore the issue that this is documentation about NumPy and SciPy not matplotlib and about having an graphical environment to see the plot.
>
> Bruce
>
>
>
>
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>   


From stefan at sun.ac.za  Mon Jun  2 11:09:01 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 2 Jun 2008 17:09:01 +0200
Subject: [SciPy-dev] Namespaces in documentation
In-Reply-To: <4843FAE5.8030507@gmail.com>
References: <1211159457.5853.84.camel@glup.physics.ucf.edu>
	<88e473830805190949s44bac124j6e94f91b517c5f20@mail.gmail.com>
	<4831B0D7.5010206@slac.stanford.edu>
	<9457e7c80805191020m5171e209ja4e8018638d1006b@mail.gmail.com>
	<1212281702.8410.56.camel@localhost.localdomain>
	<9457e7c80806011439h1925ab46y2e2597a98d660288@mail.gmail.com>
	<4843AE00.7050208@slac.stanford.edu>
	<9457e7c80806020153g3f2f016ds42322eeeccf9d3c3@mail.gmail.com>
	<4843FAE5.8030507@gmail.com>
Message-ID: <9457e7c80806020809g383c927dmac5f18e3fde3bf25@mail.gmail.com>

Hi Bruce

2008/6/2 Bruce Southey <bsouthey at gmail.com>:
> This really illustrates the need for simple NumPy only and SciPy only self-contained examples plus these more elaborate self-contained
> examples. This also ignore the issue that this is documentation about NumPy and SciPy not matplotlib and about having an graphical environment to see the plot.

Each function has examples that do not require matplotlib.  The
plotted examples are used in addition to illuminate its working.

Regards
St?fan


From pav at iki.fi  Mon Jun  2 11:20:44 2008
From: pav at iki.fi (Pauli Virtanen)
Date: Mon, 02 Jun 2008 18:20:44 +0300
Subject: [SciPy-dev] docstring sd-2116.dedibox.fr problem
In-Reply-To: <20080601202734.6f52cc8b@ajackson.org>
References: <20080601202734.6f52cc8b@ajackson.org>
Message-ID: <1212420044.10027.0.camel@localhost.localdomain>

su, 2008-06-01 kello 20:27 -0500, Alan Jackson kirjoitti:
> I can view the docstrings, but I can no longer preview or save them.
> 
> I eventually get a timeout.

I restarted the service; it should be functional again now.

Sorry for the inconvenience.

	Pauli

-------------- 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/20080602/94e0e24b/attachment.sig>

From bsouthey at gmail.com  Mon Jun  2 12:14:04 2008
From: bsouthey at gmail.com (Bruce Southey)
Date: Mon, 02 Jun 2008 11:14:04 -0500
Subject: [SciPy-dev] Namespaces in documentation
In-Reply-To: <9457e7c80806020809g383c927dmac5f18e3fde3bf25@mail.gmail.com>
References: <1211159457.5853.84.camel@glup.physics.ucf.edu>	<88e473830805190949s44bac124j6e94f91b517c5f20@mail.gmail.com>	<4831B0D7.5010206@slac.stanford.edu>	<9457e7c80805191020m5171e209ja4e8018638d1006b@mail.gmail.com>	<1212281702.8410.56.camel@localhost.localdomain>	<9457e7c80806011439h1925ab46y2e2597a98d660288@mail.gmail.com>	<4843AE00.7050208@slac.stanford.edu>	<9457e7c80806020153g3f2f016ds42322eeeccf9d3c3@mail.gmail.com>	<4843FAE5.8030507@gmail.com>
	<9457e7c80806020809g383c927dmac5f18e3fde3bf25@mail.gmail.com>
Message-ID: <48441C4C.1080509@gmail.com>

St?fan van der Walt wrote:
> Hi Bruce
>
> 2008/6/2 Bruce Southey <bsouthey at gmail.com>:
>   
>> This really illustrates the need for simple NumPy only and SciPy only self-contained examples plus these more elaborate self-contained
>> examples. This also ignore the issue that this is documentation about NumPy and SciPy not matplotlib and about having an graphical environment to see the plot.
>>     
>
> Each function has examples that do not require matplotlib.  The
> plotted examples are used in addition to illuminate its working.
>
> Regards
> St?fan
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
>   
Hi,
I never said otherwise and the issues still remain.

Bruce


From stefan at sun.ac.za  Mon Jun  2 14:46:54 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 2 Jun 2008 20:46:54 +0200
Subject: [SciPy-dev] Namespaces in documentation
In-Reply-To: <48441C4C.1080509@gmail.com>
References: <1211159457.5853.84.camel@glup.physics.ucf.edu>
	<4831B0D7.5010206@slac.stanford.edu>
	<9457e7c80805191020m5171e209ja4e8018638d1006b@mail.gmail.com>
	<1212281702.8410.56.camel@localhost.localdomain>
	<9457e7c80806011439h1925ab46y2e2597a98d660288@mail.gmail.com>
	<4843AE00.7050208@slac.stanford.edu>
	<9457e7c80806020153g3f2f016ds42322eeeccf9d3c3@mail.gmail.com>
	<4843FAE5.8030507@gmail.com>
	<9457e7c80806020809g383c927dmac5f18e3fde3bf25@mail.gmail.com>
	<48441C4C.1080509@gmail.com>
Message-ID: <9457e7c80806021146o7cd04d4bj4382102e4f8e78b5@mail.gmail.com>

Bruce,

2008/6/2 Bruce Southey <bsouthey at gmail.com>:
> I never said otherwise and the issues still remain.

I don't see what issue you are referring to.

We have

a) Basic examples that require numpy only and
b) Extended examples that require matplotlib.

In order to use matplotlib-based examples, you must have matplotlib installed.

Regards
St?fan


From kwgoodman at gmail.com  Mon Jun  2 17:59:51 2008
From: kwgoodman at gmail.com (Keith Goodman)
Date: Mon, 2 Jun 2008 14:59:51 -0700
Subject: [SciPy-dev] Docstring convention
Message-ID: <f4f93d420806021459j73693b5au9fe119ea658e0da9@mail.gmail.com>

What's preferred for documentation? I've seen all of these:

1d or 1D or 1-d
array or ndarray, as in out : array
int or integer, as in out : int (class name is int)
bool or boolean (class name is bool)
shape : tuple    or...
shape : tuple of integers


From kwgoodman at gmail.com  Mon Jun  2 18:15:37 2008
From: kwgoodman at gmail.com (Keith Goodman)
Date: Mon, 2 Jun 2008 15:15:37 -0700
Subject: [SciPy-dev] Docstring convention
In-Reply-To: <f4f93d420806021459j73693b5au9fe119ea658e0da9@mail.gmail.com>
References: <f4f93d420806021459j73693b5au9fe119ea658e0da9@mail.gmail.com>
Message-ID: <f4f93d420806021515v1ce328bdl1f5df4c4bb6e6332@mail.gmail.com>

On Mon, Jun 2, 2008 at 2:59 PM, Keith Goodman <kwgoodman at gmail.com> wrote:
> What's preferred for documentation? I've seen all of these:
>
> 1d or 1D or 1-d

I also found "A rank 1 or 2 array" in corrcoef.


From stefan at sun.ac.za  Mon Jun  2 19:10:06 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 3 Jun 2008 01:10:06 +0200
Subject: [SciPy-dev] Docstring convention
In-Reply-To: <f4f93d420806021459j73693b5au9fe119ea658e0da9@mail.gmail.com>
References: <f4f93d420806021459j73693b5au9fe119ea658e0da9@mail.gmail.com>
Message-ID: <9457e7c80806021610p7c63a5ds14f779df0c72ccc4@mail.gmail.com>

Hi Keith

2008/6/2 Keith Goodman <kwgoodman at gmail.com>:
> What's preferred for documentation? I've seen all of these:
>
> 1d or 1D or 1-d

I think the correct form is "1-D" with a capital D.  I'd prefer not to
use the "3d" form, since that could also refer to "third".

> array or ndarray, as in out : array

`ndarray` is the numpy array type, `array` is the python array type.
We'll be using `ndarray` mostly.

> int or integer, as in out : int (class name is int)

`int` for the type name.

> bool or boolean (class name is bool)

The class name.

> shape : tuple    or...
> shape : tuple of integers

tuple or, if it is restricted, tuple of ints.

The type descriptions aren't parsed, so we don't need to be overly
strict.  The important thing is that the reader must be able to figure
out what we mean.

Regards
St?fan


From twaite at berkeley.edu  Tue Jun  3 00:59:02 2008
From: twaite at berkeley.edu (Tom Waite)
Date: Mon, 2 Jun 2008 21:59:02 -0700
Subject: [SciPy-dev]  problem with import scipy.sparse
Message-ID: <fe702a7c0806022159i46afd432ob5c153699bc274e9@mail.gmail.com>

I get the following error when I try to import the latest version of scipy
sparse. This is the first I have seen of this and I use sparse w/o any
problems prior to this.

In [3]: import scipy.sparse
---------------------------------------------------------------------------
<type 'exceptions.TypeError'>             Traceback (most recent call last)

c:\python25\lib\site-packages\scipy\sparse\__init__.py in <module>()
      3 from info import __doc__
      4
----> 5 from base import *
      6 from csr import *
      7 from csc import *

c:\python25\Lib\site-packages\scipy\sparse\base.py in <module>()
     43 MAXPRINT = 50
     44
---> 45 class spmatrix(object):
     46     """ This class provides a base class for all sparse matrices.
It
     47     cannot be instantiated.  Most of the work is provided by
subclasses.


c:\python25\Lib\site-packages\scipy\sparse\base.py in spmatrix()
    137         return format
    138
--> 139     @deprecate
    140     def rowcol(self, num):
    141         return (None, None)

<type 'exceptions.TypeError'>: deprecate() takes exactly 3 arguments (1
given)

In [4]: scipy.__version__
Out[4]: '0.7.0.dev4402'




any ideas?

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080602/25095cd1/attachment.html>

From twaite at berkeley.edu  Tue Jun  3 02:01:48 2008
From: twaite at berkeley.edu (Tom Waite)
Date: Mon, 2 Jun 2008 23:01:48 -0700
Subject: [SciPy-dev] importing scipy.stats generates exception on
	deprecate decorator
In-Reply-To: <e76aa17f0805030617n77d351a5w99154b90801ad02b@mail.gmail.com>
References: <481C5868.9070402@soe.ucsc.edu>
	<e76aa17f0805030617n77d351a5w99154b90801ad02b@mail.gmail.com>
Message-ID: <fe702a7c0806022301w24d9f267r9404bb2c82111646@mail.gmail.com>

Damian

I just downloaded the latest scipy and I use the sparse matrix routines and
get the same problem you reported. I am running on XP 32. What was your
resolution?

Tom

In [3]: import scipy.sparse
---------------------------------------------------------------------------
<type 'exceptions.TypeError'>             Traceback (most recent call last)

c:\python25\lib\site-packages\scipy\sparse\__init__.py in <module>()
      3 from info import __doc__
      4
----> 5 from base import *
      6 from csr import *
      7 from csc import *

c:\python25\Lib\site-packages\scipy\sparse\base.py in <module>()
     43 MAXPRINT = 50
     44
---> 45 class spmatrix(object):
     46     """ This class provides a base class for all sparse matrices.
It
     47     cannot be instantiated.  Most of the work is provided by
subclasses.


c:\python25\Lib\site-packages\scipy\sparse\base.py in spmatrix()
    137         return format
    138
--> 139     @deprecate
    140     def rowcol(self, num):
    141         return (None, None)

<type 'exceptions.TypeError'>: deprecate() takes exactly 3 arguments (1
given)

In [4]: scipy.__version__
Out[4]: '0.7.0.dev4402'
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080602/59ebb732/attachment.html>

From robert.kern at gmail.com  Tue Jun  3 02:05:01 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 3 Jun 2008 01:05:01 -0500
Subject: [SciPy-dev] importing scipy.stats generates exception on
	deprecate decorator
In-Reply-To: <fe702a7c0806022301w24d9f267r9404bb2c82111646@mail.gmail.com>
References: <481C5868.9070402@soe.ucsc.edu>
	<e76aa17f0805030617n77d351a5w99154b90801ad02b@mail.gmail.com>
	<fe702a7c0806022301w24d9f267r9404bb2c82111646@mail.gmail.com>
Message-ID: <3d375d730806022305w5fb760b8q5a1116a2f0244b8@mail.gmail.com>

On Tue, Jun 3, 2008 at 1:01 AM, Tom Waite <twaite at berkeley.edu> wrote:
> Damian
>
> I just downloaded the latest scipy and I use the sparse matrix routines and
> get the same problem you reported. I am running on XP 32. What was your
> resolution?

numpy 1.1.0

-- 
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  Tue Jun  3 02:09:19 2008
From: matthieu.brucher at gmail.com (Matthieu Brucher)
Date: Tue, 3 Jun 2008 08:09:19 +0200
Subject: [SciPy-dev] importing scipy.stats generates exception on
	deprecate decorator
In-Reply-To: <fe702a7c0806022301w24d9f267r9404bb2c82111646@mail.gmail.com>
References: <481C5868.9070402@soe.ucsc.edu>
	<e76aa17f0805030617n77d351a5w99154b90801ad02b@mail.gmail.com>
	<fe702a7c0806022301w24d9f267r9404bb2c82111646@mail.gmail.com>
Message-ID: <e76aa17f0806022309i2603f6e4x200f697696348fb9@mail.gmail.com>

What numpy version do you use ?

Matthieu

2008/6/3 Tom Waite <twaite at berkeley.edu>:

> Damian
>
> I just downloaded the latest scipy and I use the sparse matrix routines and
> get the same problem you reported. I am running on XP 32. What was your
> resolution?
>
> Tom
>
> In [3]: import scipy.sparse
> ------------------------------
> ---------------------------------------------
> <type 'exceptions.TypeError'>             Traceback (most recent call last)
>
> c:\python25\lib\site-packages\scipy\sparse\__init__.py in <module>()
>       3 from info import __doc__
>       4
> ----> 5 from base import *
>       6 from csr import *
>       7 from csc import *
>
> c:\python25\Lib\site-packages\scipy\sparse\base.py in <module>()
>      43 MAXPRINT = 50
>      44
> ---> 45 class spmatrix(object):
>      46     """ This class provides a base class for all sparse matrices.
> It
>      47     cannot be instantiated.  Most of the work is provided by
> subclasses.
>
>
> c:\python25\Lib\site-packages\scipy\sparse\base.py in spmatrix()
>     137         return format
>     138
> --> 139     @deprecate
>     140     def rowcol(self, num):
>     141         return (None, None)
>
> <type 'exceptions.TypeError'>: deprecate() takes exactly 3 arguments (1
> given)
>
> In [4]: scipy.__version__
> Out[4]: '0.7.0.dev4402'
>
>
>
>
> _______________________________________________
> 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/20080603/b2ee33c5/attachment.html>

From nwagner at iam.uni-stuttgart.de  Tue Jun  3 02:10:54 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Tue, 03 Jun 2008 08:10:54 +0200
Subject: [SciPy-dev] Recent bug reports
Message-ID: <web-102655422@uni-stuttgart.de>

Hi there,

I didn't receive any bug report during the last weeks.
How can I fix that problem ?

Nils


From robert.kern at gmail.com  Tue Jun  3 02:20:32 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 3 Jun 2008 01:20:32 -0500
Subject: [SciPy-dev] Recent bug reports
In-Reply-To: <web-102655422@uni-stuttgart.de>
References: <web-102655422@uni-stuttgart.de>
Message-ID: <3d375d730806022320m241d4c38jde63497b785ed598@mail.gmail.com>

On Tue, Jun 3, 2008 at 1:10 AM, Nils Wagner
<nwagner at iam.uni-stuttgart.de> wrote:
> Hi there,
>
> I didn't receive any bug report during the last weeks.
> How can I fix that problem ?

You can't. We're working on it.

-- 
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 ctw at cogsci.info  Tue Jun  3 07:29:17 2008
From: ctw at cogsci.info (Christoph T. Weidemann)
Date: Tue, 3 Jun 2008 07:29:17 -0400
Subject: [SciPy-dev] Bug 791 not completely fixed
Message-ID: <c78dc03d0806030429k3754524amdad3cd3bf9a36207@mail.gmail.com>

Hi!

The following bug was marked as fixed, but I believe the current fix
is incomplete:
http://scipy.org/scipy/numpy/ticket/791

This issue seemed to not only affect std and var, but also clip and
imag. For the example code given at the link the following code gives
the wrong results:

dat.clip(2,7).info # produces ''
dat.imag.info # produces ''

Let me know if I can provide any additional info that may help fixing this bug!

Best,
Christoph Weidemann


From jh at physics.ucf.edu  Tue Jun  3 10:11:35 2008
From: jh at physics.ucf.edu (Joe Harrington)
Date: Tue, 03 Jun 2008 10:11:35 -0400
Subject: [SciPy-dev] Namespaces in documentation
In-Reply-To: <mailman.11.1212426052.9219.scipy-dev@scipy.org>
	(scipy-dev-request@scipy.org)
References: <mailman.11.1212426052.9219.scipy-dev@scipy.org>
Message-ID: <wl8zlq2ehgo.fsf@glup.physics.ucf.edu>

I object to any abbreviations *at all* in the docs.  This post lays
out my argument against abbreviations, gives two alternatives, and
proposes a poll to resolve the issue.  There is a comment on numpy API
maturity at the end.  I'm sorry that it's long.  I think we're making
an important step with this decision.  We need to make sure that it's
the right one, and that the community buys that it's the right one so
that the issue stays resolved.

What we are writing is the formal documentation to a software package,
not a bunch of informal recipes.  How we code the doc examples is
correctly perceived as how we recommend everyone write their own code.
Is there any other place in Python (or indeed in computer science)
where a package advocates referring to itself by something other than
its own name, and documents itself that way?  Certainly such cases are
few.  Doing so is a loud community declaration that the package
authors made a serious mistake in calling it something the community
can't actually tolerate using, even in writing formal documentation,
where a few extra characters are not a big fraction of the effort.  I
don't like to think that this is the case, but more on that later.

Aside from the embarrassment of declaring a mistake on every page of
documentation, the proposed path makes the documentation not work for
several classes of users who should by all rights have it work for
them.  These alienated users have more primary rights than those for
whom abbreviations are conveniences, which admittedly is most of us
(including me).  They include:

1. Those who were using np or sp or plt as variables.  These are *not*
reserved words, and we have seen that a substantial number of people
use them.  It is their legal *right* to do so, and to expect that
everything, including the examples in the docs, will work for them
when they do!  The alias import would wipe out their legitimate
variables.

2. Those not using iPython, for whatever reason.  Numpy and scipy are
python packages, not iPython packages (I don't think there are any
pure iPython packages).  We must always support using the packages,
and their docs, in native and unpolluted python sessions, because all
code is compiled and run by python.  Someone using python natively
because they want to be as close to the metal as possible should not
have to sacrifice access to any part of the docs to do that.  If they
need to import numpy some other way because their code depends on it,
they can't run the doc examples.  (Don't get me wrong, iPython is
great, and I use it).

There is a third problem that could come later.  Currently, it is
likely the case that no other Python package is called "np" or "sp".
Certainly no future package will be called "numpy", but can we be sure
no package will call itself "np"?  I don't think we can guarrantee
that if it's just a convenient abbreviation for us.  If they do, the
abbreviation we choose now will conflict with that package in the
future, and the other package would win because convenience
abbreviations are distant second-class citizens to package names (and
likely because numpy is a rather niche use and has a correspondingly
small representation among all Python users).  We'd then have to
change the docs, and retrain the entire community from our entrenched
use habit to something else (and reopen the debate as to what that
name would be).  Whoever in our community needed the new np package
would have to rewrite old code to get it to work, if they followed the
suggested convention.

The behavior we are engaging in is arranging a convenience for the
majority without regard for the minority.  Producers do this all the
time and it invariably ends up having negative repercussions for
some.  Consider how little different these sound:
"run in ipython"
"use these abbreviations"
"only use xxx browser"
"no support for Linux/Mac/whatever"
"the only supported client is Outlook"
Each of these decisions loses only a small minority, but do it enough
times and our remaining "majority" looks small indeed.  These
expedience decisions invariably restrict flexibility and alienate
users, most of whom will never be known to us.  We must therefore
avoid making such decisions wherever possible, and it *is* possible in
this case.

That we are nonetheless doing it so that a dozen people writing docs
don't have to type just three more characters per function call is
baffling to me.  These are not lazy people.  So, I'm being driven to
accept something deeper, that a substantial fraction of the community
*is* saying that typing "numpy." is unacceptable, even in the formal
documentation, even in the numpy code itself, not out of laziness but
because it pollutes the code, or their thinking about the code as they
write it.  If this is true, it is a declaration that the package is
either misnamed or that our use recommendation is drastically wrong,
and we need to change accordingly.  So here are some possibilities:


1. Let's take the simpler case first, the idea that typing "numpy." is
unacceptable, but that "np." might be ok.  Then, the package really
*should* have been called "np" and not "numpy".  If this is really the
case, then we should recognize that the project is still in its
infancy, and that we should fix the problem in release 2.0 by calling
the package "np" (still NumPy when written in text), and by its 1.0
release call SciPy "sp".  For backward compatibility, we should
reserve the words "numpy" and "scipy", which nobody now uses as
variables, so that people can do

import np as numpy
import sp as scipy

at the top of their old code.  This is a radical suggestion; see below
for a coment on radical API changes.  I do not advocate this
suggestion, but I think you must accept it (or a variant) if you are
simply unwilling to type "numpy.".  Call it the "modest proposal",
with apologies to Jonathan Swift.


2. Alternatively, we may accept that typing *anything* before the
function call name is at best pollution and possibly also obfuscation.
In what other programming language do you say

y = weij.sin(x)

instead of

y = sin(x)

?  None I can think of, and many people find it particularly onerous
in interactive mode.  So, why not be linguists, and recognize that how
people actually want to use a language *is* its grammar?  We should
thus encourage

from numpy import xxx yyy zzz

for all functions in a given chunk of code.  This would allow direct
references to the function calls without a name in front of them.  For
the docs, that would mean putting that line at the top of the examples
section of each docstring (to combat the disdained "import *").  This
would make the code in the examples look a lot cleaner and clearer.
It would simplify our personal code, too.  This is the solution I
favor.


N1. I am absolutely opposed to any solution that *implies* a peculiar
import, such as that if numpy.fft.fft is in the top-level namespace,
then so is numpy.fft.rfft.  New users will be lost with this
assumption since importing and namespaces (especially with
abbreviations in scope) are not familiar to them.  They will then not
be able to run the doc examples they need in order to learn the
package.


N2. I also oppose any solution that encourages one usage interactively
and another in code.  While anyone may choose such a path for
themselves, and there may be good reasons for doing so, it is an
unacceptable extra layer of complication for new users for us to be
advocating such an approach.


The decision we are making in this debate is a big one.  The examples
in the doc *are how we recommend people code*.  Since that affects
everyone and not just code in numpy itself, the decision should be
made by the community as a whole.  I propose the following:

We discuss this through Wednesday 4 June.  On Thursday we put up a
poll, keep it open through Wednesday 11 June, and stick with the
results.  The poll should declare the project's recommendation for how
people code, and that recommendation should be reflected in the docs.
Since there is a group that might need protection, and since I know
many of us are comfortable with more than one solution, I propose this
poll:

Q1: True or False:

I have a significant code investment in the variable(s) 'np', 'sp', or
'plt'; use of one or more of these as an abbreviation or package name
would hurt my work seriously.

Q2: Distribute points among the following.  These will be normalized
per person and tallied per option.  The option with the most
cumulative points wins.  Entries not consisting solely of numbers are
treated as 0:

1. Keep the names "numpy" and "scipy", use no abbreviations, recommend
full names, as in:

import numpy
y = numpy.sin(x)

2. Keep the names "numpy" and "scipy", use "np" and "sp"
abbreviations, as in:

import numpy as np
y = np.sin(x)

3. Keep the names "numpy" and "scipy", use no abbreviations, recommend
explicit imports, as in:

from numpy import sin
y = sin(x)

4. Change the names "numpy" and "scipy" to "np" and "sp" in their next
major releases, protect the words "numpy" and "scipy" for backward
compatibility, as in:

import np
y = np.sin(x)

5. Change the names "numpy" and "scipy" to "np" and "sp" in their next
major releases, protect the words "numpy" and "scipy" for backward
compatibility, AND recomend explicit imports, as in:

from np import sin
y = sin(x)

6. Keep the names "numpy" and "scipy", use no abbreviations, recommend
import into the top-level namespace, as in:

from numpy import *
y = sin(x)

As a final note, I do recognize that the idea of renaming numpy and
scipy permanently is a radical API break.  *I am not endorsing this
idea.* However, a number of other API breaks have been proposed
recently, including the sensible change to the behavior of median(),
the de-facto proposal to make 'np', 'sp', and 'plt' retroactively
reserved words in the top-level Python namespace,
matrix/ufunc/boolean/ma behavior, etc.  This indicates to me that
numpy and scipy are not close to maturity.  The lack of reference and
user documentation is another indicator that we are not close to
maturity.

We need to reach that mature stage soon, so that people can depend on
their code investments in numpy.  This will require a full community
review that has not yet occurred, an agreement on the final API, and
then a hard commitment against incompatible changes.

Our commercial competitors have gained their large followings in large
part because of their API stability over several decades.  If we are
to compete, we will need to shake out the needed changes, freeze the
API, and formally commit against incompatible change to the extent
humanly possible.  I think we start that with numpy and I can see it
completing about 2-3 years from now (including getting a real user
manual written).  How we do it with scipy is a different story but I
can see it happening piecemeal easier than all at once.

--jh--


From wnbell at gmail.com  Tue Jun  3 10:13:42 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Tue, 3 Jun 2008 09:13:42 -0500
Subject: [SciPy-dev] problem with import scipy.sparse
In-Reply-To: <fe702a7c0806022159i46afd432ob5c153699bc274e9@mail.gmail.com>
References: <fe702a7c0806022159i46afd432ob5c153699bc274e9@mail.gmail.com>
Message-ID: <d05265cb0806030713w1807820cp4828be6be5b464c1@mail.gmail.com>

On Mon, Jun 2, 2008 at 11:59 PM, Tom Waite <twaite at berkeley.edu> wrote:
> I get the following error when I try to import the latest version of scipy
> sparse. This is the first I have seen of this and I use sparse w/o any
> problems prior to this.
>
> In [3]: import scipy.sparse
> --> 139     @deprecate
>     140     def rowcol(self, num):
>     141         return (None, None)
>
> <type 'exceptions.TypeError'>: deprecate() takes exactly 3 arguments (1
> given)
>
> In [4]: scipy.__version__
> Out[4]: '0.7.0.dev4402'

Which version of numpy are you using? IIRC you need a something newer than 1.0.


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


From jdh2358 at gmail.com  Tue Jun  3 11:08:19 2008
From: jdh2358 at gmail.com (John Hunter)
Date: Tue, 3 Jun 2008 10:08:19 -0500
Subject: [SciPy-dev] Namespaces in documentation
In-Reply-To: <wl8zlq2ehgo.fsf@glup.physics.ucf.edu>
References: <mailman.11.1212426052.9219.scipy-dev@scipy.org>
	<wl8zlq2ehgo.fsf@glup.physics.ucf.edu>
Message-ID: <88e473830806030808w3d7f9913je541053abddbcd02@mail.gmail.com>

On Tue, Jun 3, 2008 at 9:11 AM, Joe Harrington <jh at physics.ucf.edu> wrote:

> Aside from the embarrassment of declaring a mistake on every page of
> documentation, the proposed path makes the documentation not work for
> several classes of users who should by all rights have it work for
> them.  These alienated users have more primary rights than those for
> whom abbreviations are conveniences, which admittedly is most of us
> (including me).  They include:

This is not an issue of having made a mistake that we are trying to
hide by using an alias.  It is an issue of trying to strike the right
balance between readability and usability.  Many of us write a lot of
code in three different environments: scripts, production libraries,
and interactively from the python shell, and find that the recommended
import semantics strike the right balance.  Ideally, we would like one
solution that works pretty well in all three context  so we don't have
to do the mental context switching: "I'm scripting now so I should do
this, I'm at the python shell now so I should do that, I'm working on
mpl src now so do something else"

Interactively from the python shell, it is easiest to type

    >>>  sin(2*pi*t)*exp(-t)

so it is nice to first do

    >>> from numpy import sin, pi, exp

But this idiom doesn't work very well for large pieces of production
code.  We did this in matplotlib for years, and were constantly moving
back and forth from the import section to the code section to find out
if a symbol is already imported.   It is very nice when writing large
pieces of code to know that some name is available, so we can do

   x = numpy.arange(10.)
   y = numpy.sin(2*numpy.pi*x) * numpy.exp(x)

w/o having to go looking at the import layer.  That is manageable, but
a bit ugly, which is why most people prefer an alias, and these
aliases are *widely* used throughout the entire code base of numpy,
scipy and matplotlib.  This is not an embarrassment or an admission of
a mistake, it is taking advantage of a language feature benevolently
bestowed upon us by Guido.

The nice thing about the

  import numpy as np

alias is that it is sufficiently short that you can use it in scripts
and interactive sessions, and sufficiently mnemonic that you can use
it in production code.  It is also easy to type, as are the other
recommended aliases.

Of course you are right that we run the risk of clashes with other
people who will be using np as a variable name or another package (a
little unlikely on the latter since it would be pretty foolish to name
a package with two letters for precisely the reason that it is likely
to clash).  Recognizing that aliases are a good thing, and any alias
will clash sometimes, several of us got together (including lead
developers of ipython, numpy, scipy and matplotlib) and decided to
recommend a usage, precisely to lower the risk of clashes.  If we are
consistent in the usage in the docs and code, and publicly recommend
it, then clashes are less likely.

As for those worried about an ipython requirement, there isn't one.
plain-ol-python  supports import configuration as well, so a python
shell properly configured for numpy/scipy will support pasting from
the docs anyhow.
http://docs.python.org/tut/node4.html#SECTION004240000000000000000

Finally, whatever standard you adopt for the docs, a decision has
already been made by the ipython, numpy, scipy and matplotlib
developers to use this alias convention in their source code.  Since
many users eventually become developers, it is nice to have a
consistent approach between what is advocated the user documentation
and the source code, where feasible.

JDH


From twaite at berkeley.edu  Tue Jun  3 11:18:08 2008
From: twaite at berkeley.edu (Tom Waite)
Date: Tue, 3 Jun 2008 08:18:08 -0700
Subject: [SciPy-dev] problem with import scipy.sparse
In-Reply-To: <d05265cb0806030713w1807820cp4828be6be5b464c1@mail.gmail.com>
References: <fe702a7c0806022159i46afd432ob5c153699bc274e9@mail.gmail.com>
	<d05265cb0806030713w1807820cp4828be6be5b464c1@mail.gmail.com>
Message-ID: <fe702a7c0806030818l3454857fx375d7ea4b6585a76@mail.gmail.com>

numpy 1.0.3.1




On 6/3/08, Nathan Bell <wnbell at gmail.com> wrote:
>
> On Mon, Jun 2, 2008 at 11:59 PM, Tom Waite <twaite at berkeley.edu> wrote:
> > I get the following error when I try to import the latest version of
> scipy
> > sparse. This is the first I have seen of this and I use sparse w/o any
> > problems prior to this.
> >
> > In [3]: import scipy.sparse
> > --> 139     @deprecate
> >     140     def rowcol(self, num):
> >     141         return (None, None)
> >
> > <type 'exceptions.TypeError'>: deprecate() takes exactly 3 arguments (1
> > given)
> >
> > In [4]: scipy.__version__
> > Out[4]: '0.7.0.dev4402'
>
> Which version of numpy are you using? IIRC you need a something newer than
> 1.0.
>
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080603/de511dcc/attachment.html>

From wnbell at gmail.com  Tue Jun  3 11:27:22 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Tue, 3 Jun 2008 10:27:22 -0500
Subject: [SciPy-dev] problem with import scipy.sparse
In-Reply-To: <fe702a7c0806030818l3454857fx375d7ea4b6585a76@mail.gmail.com>
References: <fe702a7c0806022159i46afd432ob5c153699bc274e9@mail.gmail.com>
	<d05265cb0806030713w1807820cp4828be6be5b464c1@mail.gmail.com>
	<fe702a7c0806030818l3454857fx375d7ea4b6585a76@mail.gmail.com>
Message-ID: <d05265cb0806030827g4656cf0cjd19974e4016b6fa7@mail.gmail.com>

On Tue, Jun 3, 2008 at 10:18 AM, Tom Waite <twaite at berkeley.edu> wrote:
> numpy 1.0.3.1
>

I just tested it against numpy SVN and it works.  It should work with
numpy 1.1 as well.

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


From millman at berkeley.edu  Tue Jun  3 11:52:32 2008
From: millman at berkeley.edu (Jarrod Millman)
Date: Tue, 3 Jun 2008 08:52:32 -0700
Subject: [SciPy-dev] Namespaces in documentation
In-Reply-To: <4843B38F.3070401@slac.stanford.edu>
References: <1211159457.5853.84.camel@glup.physics.ucf.edu>
	<88e473830805190949s44bac124j6e94f91b517c5f20@mail.gmail.com>
	<4831B0D7.5010206@slac.stanford.edu>
	<9457e7c80805191020m5171e209ja4e8018638d1006b@mail.gmail.com>
	<1212281702.8410.56.camel@localhost.localdomain>
	<9457e7c80806011439h1925ab46y2e2597a98d660288@mail.gmail.com>
	<4843AE00.7050208@slac.stanford.edu>
	<9457e7c80806020153g3f2f016ds42322eeeccf9d3c3@mail.gmail.com>
	<4843B38F.3070401@slac.stanford.edu>
Message-ID: <c7009a550806030852q7af78dbcv6bf76fe13d7e43f9@mail.gmail.com>

On Mon, Jun 2, 2008 at 1:47 AM, Johann Cohen-Tanugi
<cohen at slac.stanford.edu> wrote:
> Anyway, +1 for np/sp in docstrings.

+1

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


From millman at berkeley.edu  Tue Jun  3 11:57:43 2008
From: millman at berkeley.edu (Jarrod Millman)
Date: Tue, 3 Jun 2008 08:57:43 -0700
Subject: [SciPy-dev] problem with import scipy.sparse
In-Reply-To: <fe702a7c0806030818l3454857fx375d7ea4b6585a76@mail.gmail.com>
References: <fe702a7c0806022159i46afd432ob5c153699bc274e9@mail.gmail.com>
	<d05265cb0806030713w1807820cp4828be6be5b464c1@mail.gmail.com>
	<fe702a7c0806030818l3454857fx375d7ea4b6585a76@mail.gmail.com>
Message-ID: <c7009a550806030857g484a1941r6a8940eb2fac07eb@mail.gmail.com>

On Tue, Jun 3, 2008 at 8:18 AM, Tom Waite <twaite at berkeley.edu> wrote:
> numpy 1.0.3.1

The SciPy trunk requires Python 2.4 or greater and NumPy 1.1.0 or greater.

I noticed that I never updated the install instructions when we
renamed 1.0.5 to 1.1.0, which I just fixed:
http://projects.scipy.org/scipy/scipy/changeset/4409

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


From bsouthey at gmail.com  Tue Jun  3 12:06:03 2008
From: bsouthey at gmail.com (Bruce Southey)
Date: Tue, 03 Jun 2008 11:06:03 -0500
Subject: [SciPy-dev] Namespaces in documentation
In-Reply-To: <c7009a550806030852q7af78dbcv6bf76fe13d7e43f9@mail.gmail.com>
References: <1211159457.5853.84.camel@glup.physics.ucf.edu>	<88e473830805190949s44bac124j6e94f91b517c5f20@mail.gmail.com>	<4831B0D7.5010206@slac.stanford.edu>	<9457e7c80805191020m5171e209ja4e8018638d1006b@mail.gmail.com>	<1212281702.8410.56.camel@localhost.localdomain>	<9457e7c80806011439h1925ab46y2e2597a98d660288@mail.gmail.com>	<4843AE00.7050208@slac.stanford.edu>	<9457e7c80806020153g3f2f016ds42322eeeccf9d3c3@mail.gmail.com>	<4843B38F.3070401@slac.stanford.edu>
	<c7009a550806030852q7af78dbcv6bf76fe13d7e43f9@mail.gmail.com>
Message-ID: <48456BEB.4020000@gmail.com>

Jarrod Millman wrote:
> On Mon, Jun 2, 2008 at 1:47 AM, Johann Cohen-Tanugi
> <cohen at slac.stanford.edu> wrote:
>   
>> Anyway, +1 for np/sp in docstrings.
>>     
>
> +1
>
>   
-1
It is inappropriate for beginners, see for example the official Python 
tutorial (http://docs.python.org/tut/) and documentation. Both of these 
make heavy use of 'import module' syntax except to extract submodules.

Bruce


From matthew.brett at gmail.com  Tue Jun  3 12:23:18 2008
From: matthew.brett at gmail.com (Matthew Brett)
Date: Tue, 3 Jun 2008 17:23:18 +0100
Subject: [SciPy-dev] Namespaces in documentation
In-Reply-To: <48456BEB.4020000@gmail.com>
References: <1211159457.5853.84.camel@glup.physics.ucf.edu>
	<4831B0D7.5010206@slac.stanford.edu>
	<9457e7c80805191020m5171e209ja4e8018638d1006b@mail.gmail.com>
	<1212281702.8410.56.camel@localhost.localdomain>
	<9457e7c80806011439h1925ab46y2e2597a98d660288@mail.gmail.com>
	<4843AE00.7050208@slac.stanford.edu>
	<9457e7c80806020153g3f2f016ds42322eeeccf9d3c3@mail.gmail.com>
	<4843B38F.3070401@slac.stanford.edu>
	<c7009a550806030852q7af78dbcv6bf76fe13d7e43f9@mail.gmail.com>
	<48456BEB.4020000@gmail.com>
Message-ID: <1e2af89e0806030923p144ffeaen51e0a6e1a1e94b5f@mail.gmail.com>

>>> Anyway, +1 for np/sp in docstrings

Isn't there quite a strong majority view in favor of np, sp, among
those working most on the code?

Best,

Matthew


From jdh2358 at gmail.com  Tue Jun  3 12:39:15 2008
From: jdh2358 at gmail.com (John Hunter)
Date: Tue, 3 Jun 2008 11:39:15 -0500
Subject: [SciPy-dev] Namespaces in documentation
In-Reply-To: <wl8zlq2ehgo.fsf@glup.physics.ucf.edu>
References: <mailman.11.1212426052.9219.scipy-dev@scipy.org>
	<wl8zlq2ehgo.fsf@glup.physics.ucf.edu>
Message-ID: <88e473830806030939r3df872devf2d1cda4896acff8@mail.gmail.com>

On Tue, Jun 3, 2008 at 9:11 AM, Joe Harrington <jh at physics.ucf.edu> wrote:

> Is there any other place in Python (or indeed in computer science)
> where a package advocates referring to itself by something other than

>From Bjarne Stroustrup "Programming Language C++, 3rd edition" Section 8,2
"Namespaces"::

  If users give their namespaces short names, the names of different
  namespaces will clash:

    namespace A { //short name, will clash (eventually)

  However, long namespaces can be impractical in real code:

    namespace American_Telephone_and_Telegraph { //too long

  This dilemma can be resolved by providing a short alias for a longer
  namespace name

    //use namespace alias to shorten names:
    namespace ATT = American_Telephone_and_Telegraph;
    ATT:String s3 = "Grieg";

  Namespace aliases allow a user to refer to "the library" and have a
  single declaration defining what library that really is.  For example:

  namespace Lib = Foundation_library_v2r11;


Well said.  Because they are so handy, most languages provide
facilities for aliases::

    python  : import something as somethingelse
    C++     : namespace new_name = current_name;
    Bash    : alias ls='ls -F'
    C       : # DEFINE
    C#      : using colAlias = System.Collections;
    Texinfo : @alias new=existing'
    Perl    : use perl Alias

And we needn't look too far beyond our own doors, since there is broad
agreement here on the usefulness of namespace aliases.

JDH


From bsouthey at gmail.com  Tue Jun  3 13:48:44 2008
From: bsouthey at gmail.com (Bruce Southey)
Date: Tue, 03 Jun 2008 12:48:44 -0500
Subject: [SciPy-dev] Namespaces in documentation
In-Reply-To: <1e2af89e0806030923p144ffeaen51e0a6e1a1e94b5f@mail.gmail.com>
References: <1211159457.5853.84.camel@glup.physics.ucf.edu>	<4831B0D7.5010206@slac.stanford.edu>	<9457e7c80805191020m5171e209ja4e8018638d1006b@mail.gmail.com>	<1212281702.8410.56.camel@localhost.localdomain>	<9457e7c80806011439h1925ab46y2e2597a98d660288@mail.gmail.com>	<4843AE00.7050208@slac.stanford.edu>	<9457e7c80806020153g3f2f016ds42322eeeccf9d3c3@mail.gmail.com>	<4843B38F.3070401@slac.stanford.edu>	<c7009a550806030852q7af78dbcv6bf76fe13d7e43f9@mail.gmail.com>	<48456BEB.4020000@gmail.com>
	<1e2af89e0806030923p144ffeaen51e0a6e1a1e94b5f@mail.gmail.com>
Message-ID: <484583FC.4040305@gmail.com>

Matthew Brett wrote:
>>>> Anyway, +1 for np/sp in docstrings
>>>>         
>
> Isn't there quite a strong majority view in favor of np, sp, among
> those working most on the code?
>
> Best,
>
> Matthew
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
>   
That is largely irrelevant because documentation is orientated to people 
not working on the code as those that work on the code already know the 
code. An important aspect of documentation is to reach out to people who 
are don't have the depth of the knowledge so they can use NumPy in any 
way that they want to (in accordance to the licensing).

Bruce


From jdh2358 at gmail.com  Tue Jun  3 14:40:27 2008
From: jdh2358 at gmail.com (John Hunter)
Date: Tue, 3 Jun 2008 13:40:27 -0500
Subject: [SciPy-dev] Namespaces in documentation
In-Reply-To: <484583FC.4040305@gmail.com>
References: <1211159457.5853.84.camel@glup.physics.ucf.edu>
	<1212281702.8410.56.camel@localhost.localdomain>
	<9457e7c80806011439h1925ab46y2e2597a98d660288@mail.gmail.com>
	<4843AE00.7050208@slac.stanford.edu>
	<9457e7c80806020153g3f2f016ds42322eeeccf9d3c3@mail.gmail.com>
	<4843B38F.3070401@slac.stanford.edu>
	<c7009a550806030852q7af78dbcv6bf76fe13d7e43f9@mail.gmail.com>
	<48456BEB.4020000@gmail.com>
	<1e2af89e0806030923p144ffeaen51e0a6e1a1e94b5f@mail.gmail.com>
	<484583FC.4040305@gmail.com>
Message-ID: <88e473830806031140p564d4541v5c7148caa0b67b98@mail.gmail.com>

On Tue, Jun 3, 2008 at 12:48 PM, Bruce Southey <bsouthey at gmail.com> wrote:

> That is largely irrelevant because documentation is orientated to people
> not working on the code as those that work on the code already know the
> code. An important aspect of documentation is to reach out to people who
> are don't have the depth of the knowledge so they can use NumPy in any
> way that they want to (in accordance to the licensing).

There is some truth to this: seasoned veterans often do not make good
documentation writers because they forget how much they are assuming.
But it is not irrelevant: part of the goal of documentation is to help
new users acquire the depth of hard won knowledge the experts have,
and many of the experts here have learned that the recommended coding
practice solves many common problems and strikes the right balance
between usability and readability.    So their view is not irrelevant
-- they are trying to help users avoid mistakes they have made in
their own code and adopt coding practices that are realistic, healthy,
and scalable.

In all the original pylab examples, I wrote at the top of every example:

   from pylab import *

then I could write nice little scripts like

   x = randn(10000)
   hist(x, 100)
   title('a normal distribution')

I did this to reach out to the large community of users who are
familiar with matlab (or other command languages for numerics) since
the resultant scripts were small, easy and unencumbered with a
syntactic cruft.  I got a lot of flack for it at the time and no
longer promote this usage; I find that students respond favorably to
the clarity of namespaces.

Most of the developers here who are advocating this import scheme are
not so far removed from the needs of the user community.  Most of us
are not professional programmers -- we are trained as scientists.
Many of us have been working a long time to write code that is usable
by students and scientists who are not programmers, and have taught
scientific computing courses in python on many occassions, where we
get to see first hand the confusion and struggles that students and
new users trying to use this suite encounter.   In fact, my opionions
on the subject have come directly from my experiences teaching python,
ipython, numpy, scipy, matplotlib and enthought in these seminars.

JDH


From robert.kern at gmail.com  Tue Jun  3 14:40:58 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 3 Jun 2008 13:40:58 -0500
Subject: [SciPy-dev] Namespaces in documentation
In-Reply-To: <c7009a550806030852q7af78dbcv6bf76fe13d7e43f9@mail.gmail.com>
References: <1211159457.5853.84.camel@glup.physics.ucf.edu>
	<88e473830805190949s44bac124j6e94f91b517c5f20@mail.gmail.com>
	<4831B0D7.5010206@slac.stanford.edu>
	<9457e7c80805191020m5171e209ja4e8018638d1006b@mail.gmail.com>
	<1212281702.8410.56.camel@localhost.localdomain>
	<9457e7c80806011439h1925ab46y2e2597a98d660288@mail.gmail.com>
	<4843AE00.7050208@slac.stanford.edu>
	<9457e7c80806020153g3f2f016ds42322eeeccf9d3c3@mail.gmail.com>
	<4843B38F.3070401@slac.stanford.edu>
	<c7009a550806030852q7af78dbcv6bf76fe13d7e43f9@mail.gmail.com>
Message-ID: <3d375d730806031140n6549d9a0nef2a9830b17683a0@mail.gmail.com>

St?fan, Pauli,

Make a decision on what you want. Stick with it. Don't let it be
brought up for discussion. This is pointless bikeshedding that doesn't
help improve the documentation effort in the slightest.

Everybody else, please just drop it. If you feel like worked up enough
to write more emails, *write a docstring instead*.

-- 
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 twaite at berkeley.edu  Tue Jun  3 15:09:31 2008
From: twaite at berkeley.edu (Tom Waite)
Date: Tue, 3 Jun 2008 12:09:31 -0700
Subject: [SciPy-dev] importing scipy.stats generates exception on
	deprecate decorator
In-Reply-To: <e76aa17f0806022309i2603f6e4x200f697696348fb9@mail.gmail.com>
References: <481C5868.9070402@soe.ucsc.edu>
	<e76aa17f0805030617n77d351a5w99154b90801ad02b@mail.gmail.com>
	<fe702a7c0806022301w24d9f267r9404bb2c82111646@mail.gmail.com>
	<e76aa17f0806022309i2603f6e4x200f697696348fb9@mail.gmail.com>
Message-ID: <fe702a7c0806031209l1cc336dfi632ef2809680b6f6@mail.gmail.com>

Problem goes away with numpy 1.2. Thanks.

On Mon, Jun 2, 2008 at 11:09 PM, Matthieu Brucher <
matthieu.brucher at gmail.com> wrote:

> What numpy version do you use ?
>
> Matthieu
>
> 2008/6/3 Tom Waite <twaite at berkeley.edu>:
>
>> Damian
>>
>> I just downloaded the latest scipy and I use the sparse matrix routines
>> and get the same problem you reported. I am running on XP 32. What was your
>> resolution?
>>
>> Tom
>>
>> In [3]: import scipy.sparse
>> ------------------------------
>> ---------------------------------------------
>> <type 'exceptions.TypeError'>             Traceback (most recent call
>> last)
>>
>> c:\python25\lib\site-packages\scipy\sparse\__init__.py in <module>()
>>       3 from info import __doc__
>>       4
>> ----> 5 from base import *
>>       6 from csr import *
>>       7 from csc import *
>>
>> c:\python25\Lib\site-packages\scipy\sparse\base.py in <module>()
>>      43 MAXPRINT = 50
>>      44
>> ---> 45 class spmatrix(object):
>>      46     """ This class provides a base class for all sparse matrices.
>> It
>>      47     cannot be instantiated.  Most of the work is provided by
>> subclasses.
>>
>>
>> c:\python25\Lib\site-packages\scipy\sparse\base.py in spmatrix()
>>     137         return format
>>     138
>> --> 139     @deprecate
>>     140     def rowcol(self, num):
>>     141         return (None, None)
>>
>> <type 'exceptions.TypeError'>: deprecate() takes exactly 3 arguments (1
>> given)
>>
>> In [4]: scipy.__version__
>> Out[4]: '0.7.0.dev4402'
>>
>>
>>
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080603/5c6a0157/attachment.html>

From fperez.net at gmail.com  Tue Jun  3 16:52:47 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 3 Jun 2008 13:52:47 -0700
Subject: [SciPy-dev] Namespaces in documentation
In-Reply-To: <3d375d730806031140n6549d9a0nef2a9830b17683a0@mail.gmail.com>
References: <1211159457.5853.84.camel@glup.physics.ucf.edu>
	<4831B0D7.5010206@slac.stanford.edu>
	<9457e7c80805191020m5171e209ja4e8018638d1006b@mail.gmail.com>
	<1212281702.8410.56.camel@localhost.localdomain>
	<9457e7c80806011439h1925ab46y2e2597a98d660288@mail.gmail.com>
	<4843AE00.7050208@slac.stanford.edu>
	<9457e7c80806020153g3f2f016ds42322eeeccf9d3c3@mail.gmail.com>
	<4843B38F.3070401@slac.stanford.edu>
	<c7009a550806030852q7af78dbcv6bf76fe13d7e43f9@mail.gmail.com>
	<3d375d730806031140n6549d9a0nef2a9830b17683a0@mail.gmail.com>
Message-ID: <db6b5ecc0806031352h1b0bf401s986c303127434ace@mail.gmail.com>

On Tue, Jun 3, 2008 at 11:40 AM, Robert Kern <robert.kern at gmail.com> wrote:
> St?fan, Pauli,
>
> Make a decision on what you want. Stick with it. Don't let it be
> brought up for discussion. This is pointless bikeshedding that doesn't
> help improve the documentation effort in the slightest.
>
> Everybody else, please just drop it. If you feel like worked up enough
> to write more emails, *write a docstring instead*.

For the record, I've just added to the trunk of ipython a 'numpy'
profile that exposes np, the 'scipy' one now exposes np/sp, and the
-pylab option exposes np/plt (but *not* scipy, since many matplotlib
users do not have/want scipy all the time).  I'm sorry I did it
without voting, but I'm fed up with this discussion.

People who use ipython are free to benefit from this
convention/standard/edict or free to ignore it.  The changes should be
visible a bit later today when I push my private tree upstream.


Cheers,

f

ps - The unqualified names are also always available
(numpy/scipy/pylab/pyplot are always imported anyway).


From stefan at sun.ac.za  Tue Jun  3 19:44:33 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 4 Jun 2008 01:44:33 +0200
Subject: [SciPy-dev] Namespaces in documentation
In-Reply-To: <db6b5ecc0806031352h1b0bf401s986c303127434ace@mail.gmail.com>
References: <1211159457.5853.84.camel@glup.physics.ucf.edu>
	<9457e7c80805191020m5171e209ja4e8018638d1006b@mail.gmail.com>
	<1212281702.8410.56.camel@localhost.localdomain>
	<9457e7c80806011439h1925ab46y2e2597a98d660288@mail.gmail.com>
	<4843AE00.7050208@slac.stanford.edu>
	<9457e7c80806020153g3f2f016ds42322eeeccf9d3c3@mail.gmail.com>
	<4843B38F.3070401@slac.stanford.edu>
	<c7009a550806030852q7af78dbcv6bf76fe13d7e43f9@mail.gmail.com>
	<3d375d730806031140n6549d9a0nef2a9830b17683a0@mail.gmail.com>
	<db6b5ecc0806031352h1b0bf401s986c303127434ace@mail.gmail.com>
Message-ID: <9457e7c80806031644r56ff0983j73ea3311d5f511e8@mail.gmail.com>

Thanks for your feedback, everyone.  I have updated the documentation
standard to reflect the way we'll be using the shorthand forms from
now on.

Bruce: I have added a section to the numpy main docstring to address
your concerns.

Joe: N1 is not a concern, since we still explicitly import modules
like fft.  As for N2: we encourage that users use ``np`` both in
interactive and scripting modes.

Fernando: thank you for the profile.  I refer to it in the main docstring.

Robert: sorry for annoying you, but it's over now.

We've sorted out the problem that kept us from editing for the past
two days: all systems go!

Cheers
St?fan

2008/6/3 Fernando Perez <fperez.net at gmail.com>:
> On Tue, Jun 3, 2008 at 11:40 AM, Robert Kern <robert.kern at gmail.com> wrote:
>> St?fan, Pauli,
>>
>> Make a decision on what you want. Stick with it. Don't let it be
>> brought up for discussion. This is pointless bikeshedding that doesn't
>> help improve the documentation effort in the slightest.
>>
>> Everybody else, please just drop it. If you feel like worked up enough
>> to write more emails, *write a docstring instead*.
>
> For the record, I've just added to the trunk of ipython a 'numpy'
> profile that exposes np, the 'scipy' one now exposes np/sp, and the
> -pylab option exposes np/plt (but *not* scipy, since many matplotlib
> users do not have/want scipy all the time).  I'm sorry I did it
> without voting, but I'm fed up with this discussion.
>
> People who use ipython are free to benefit from this
> convention/standard/edict or free to ignore it.  The changes should be
> visible a bit later today when I push my private tree upstream.
>
>
> Cheers,
>
> f
>
> ps - The unqualified names are also always available
> (numpy/scipy/pylab/pyplot are always imported anyway).


From chanley at stsci.edu  Tue Jun  3 22:58:23 2008
From: chanley at stsci.edu (Christopher Hanley)
Date: Tue, 03 Jun 2008 22:58:23 -0400
Subject: [SciPy-dev] Error building from svn on Intel Macs.
In-Reply-To: <3d375d730805311355rc61eb06k964be661f844ffa5@mail.gmail.com>
References: <mailman.9.1212253204.30437.scipy-dev@scipy.org>	<1D24F3A0-AEA9-4D1C-90E5-E6FAA59A78F3@interactivesupercomputing.com>
	<3d375d730805311355rc61eb06k964be661f844ffa5@mail.gmail.com>
Message-ID: <484604CF.50904@stsci.edu>

I am also having difficulty building scipy now from SVN.  I haven't done 
it in about 10 days so I don't know when the problem began.  However, 
from the build log it looks like I'm having some swig issues.  Comments, 
suggestions?

Thanks,
Chris


--

Failure message:

swig: scipy/sparse/linalg/dsolve/umfpack/umfpack.i
swig -python -o 
build/src.macosx-10.3-i386-2.5/scipy/sparse/linalg/dsolve/umfpac
k/_umfpack_wrap.c -outdir 
build/src.macosx-10.3-i386-2.5/scipy/sparse/linalg/dso
lve/umfpack scipy/sparse/linalg/dsolve/umfpack/umfpack.i
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:192: Error: Unable to find 
'umfpack
.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:193: Error: Unable to find 
'umfpack
_solve.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:194: Error: Unable to find 
'umfpack
_defaults.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:195: Error: Unable to find 
'umfpack
_triplet_to_col.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:196: Error: Unable to find 
'umfpack
_col_to_triplet.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:197: Error: Unable to find 
'umfpack
_transpose.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:198: Error: Unable to find 
'umfpack
_scale.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:200: Error: Unable to find 
'umfpack
_report_symbolic.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:201: Error: Unable to find 
'umfpack
_report_numeric.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:202: Error: Unable to find 
'umfpack
_report_info.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:203: Error: Unable to find 
'umfpack
_report_control.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:215: Error: Unable to find 
'umfpack
_symbolic.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:216: Error: Unable to find 
'umfpack
_numeric.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:225: Error: Unable to find 
'umfpack
_free_symbolic.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:226: Error: Unable to find 
'umfpack
_free_numeric.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:248: Error: Unable to find 
'umfpack
_get_lunz.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:272: Error: Unable to find 
'umfpack
_get_numeric.h'
error: command 'swig' failed with exit status 1


-- 
Christopher Hanley
Systems Software Engineer
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21218
(410) 338-4338


From david at ar.media.kyoto-u.ac.jp  Tue Jun  3 22:51:24 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Wed, 04 Jun 2008 11:51:24 +0900
Subject: [SciPy-dev] Error building from svn on Intel Macs.
In-Reply-To: <484604CF.50904@stsci.edu>
References: <mailman.9.1212253204.30437.scipy-dev@scipy.org>	<1D24F3A0-AEA9-4D1C-90E5-E6FAA59A78F3@interactivesupercomputing.com>	<3d375d730805311355rc61eb06k964be661f844ffa5@mail.gmail.com>
	<484604CF.50904@stsci.edu>
Message-ID: <4846032C.3020408@ar.media.kyoto-u.ac.jp>

Christopher Hanley wrote:
> I am also having difficulty building scipy now from SVN.  I haven't done 
> it in about 10 days so I don't know when the problem began.  However, 
> from the build log it looks like I'm having some swig issues.  Comments, 
> suggestions?
>   

It does not look like a swig problem per se. From the limited log, I 
have the impression that scipy is trying to build umfpack solver, 
whereas the (optional) umfpack dependencies are not met.

Could you give us the full log (at least the configuration step, where 
it is looking for umfpack ?)

thanks,

David


From chanley at stsci.edu  Tue Jun  3 23:33:30 2008
From: chanley at stsci.edu (Christopher Hanley)
Date: Tue, 03 Jun 2008 23:33:30 -0400
Subject: [SciPy-dev] Error building from svn on Intel Macs.
In-Reply-To: <4846032C.3020408@ar.media.kyoto-u.ac.jp>
References: <mailman.9.1212253204.30437.scipy-dev@scipy.org>	<1D24F3A0-AEA9-4D1C-90E5-E6FAA59A78F3@interactivesupercomputing.com>	<3d375d730805311355rc61eb06k964be661f844ffa5@mail.gmail.com>	<484604CF.50904@stsci.edu>
	<4846032C.3020408@ar.media.kyoto-u.ac.jp>
Message-ID: <48460D0A.10505@stsci.edu>

David Cournapeau wrote:
> It does not look like a swig problem per se. From the limited log, I 
> have the impression that scipy is trying to build umfpack solver, 
> whereas the (optional) umfpack dependencies are not met.
> 
> Could you give us the full log (at least the configuration step, where 
> it is looking for umfpack ?)
> 
> thanks,
> 
> David
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev

Sure thing, thanks!  I do not use a site.cfg file and am doing a simple 
"python setup.py install".

Here is some compiler info as well in case it is needed:

[redcedar:~/dev/scipy] chanley% gcc -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5465~16/src/configure 
--disable-checking -enable-werror --prefix=/usr --mandir=/share/man 
--enable-languages=c,objc,c++,obj-c++ 
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ 
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib 
--build=i686-apple-darwin9 --with-arch=apple --with-tune=generic 
--host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5465)

Using built-in specs.
Target: i686-apple-darwin9
Configured with: ../gcc-4.2.2/configure --prefix=/sw 
--prefix=/sw/lib/gcc4.2 --mandir=/sw/share/man --infodir=/sw/share/info 
--enable-languages=c,c++,fortran,objc,java --with-arch=nocona 
--with-tune=generic --host=i686-apple-darwin9 --with-gmp=/sw 
--with-libiconv-prefix=/sw --with-system-zlib 
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
Thread model: posix
gcc version 4.2.2

--

Build log:

Warning: No configuration returned, assuming unavailable.
mkl_info:
   libraries mkl,vml,guide not found in /usr/stsci/pyssgdev/Python-2.5.1/lib
   libraries mkl,vml,guide not found in /usr/local/lib
   libraries mkl,vml,guide not found in /usr/lib
   libraries mkl,vml,guide not found in /sw/lib
   NOT AVAILABLE

fftw3_info:
   libraries fftw3 not found in /usr/stsci/pyssgdev/Python-2.5.1/lib
   libraries fftw3 not found in /usr/local/lib
   libraries fftw3 not found in /usr/lib
   FOUND:
     libraries = ['fftw3']
     library_dirs = ['/sw/lib']
     define_macros = [('SCIPY_FFTW3_H', None)]
     include_dirs = ['/sw/include']

djbfft_info:
   FOUND:
     extra_objects = ['/sw/lib/djbfft.a']
     define_macros = [('SCIPY_DJBFFT_H', None)]
     include_dirs = ['/sw/include']

blas_opt_info:
   FOUND:
     extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
     define_macros = [('NO_ATLAS_INFO', 3)]
     extra_compile_args = ['-msse3', 
'-I/System/Library/Frameworks/vecLib.framework/Headers']

lapack_opt_info:
   FOUND:
     extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
     define_macros = [('NO_ATLAS_INFO', 3)]
     extra_compile_args = ['-msse3']

umfpack_info:
   libraries umfpack not found in /usr/stsci/pyssgdev/Python-2.5.1/lib
   libraries umfpack not found in /usr/local/lib
   libraries umfpack not found in /usr/lib
amd_info:
   libraries amd not found in /usr/stsci/pyssgdev/Python-2.5.1/lib
   libraries amd not found in /usr/local/lib
   libraries amd not found in /usr/lib
   FOUND:
     libraries = ['amd']
     library_dirs = ['/sw/lib']

   FOUND:
     libraries = ['umfpack', 'amd']
     library_dirs = ['/sw/lib']

running install
running build
running scons
customize UnixCCompiler
Found executable /usr/bin/cc
customize NAGFCompiler
Could not locate executable f95
Found executable /sw/bin/gfortran
nag: no Fortran 90 compiler found
Found executable /usr/bin/ranlib
nag: no Fortran 90 compiler found
nag: no Fortran 90 compiler found
customize AbsoftFCompiler
Could not locate executable f90
absoft: no Fortran 90 compiler found
absoft: no Fortran 90 compiler found
absoft: no Fortran 90 compiler found
absoft: no Fortran 90 compiler found
absoft: no Fortran 90 compiler found
absoft: no Fortran 90 compiler found
customize IBMFCompiler
Could not locate executable xlf90
ibm: no Fortran 90 compiler found
Could not locate executable xlf95
ibm: no Fortran 90 compiler found
customize IntelFCompiler
Could not locate executable ifort
Could not locate executable ifc
intel: no Fortran 90 compiler found
intel: no Fortran 90 compiler found
customize GnuFCompiler
gnu: no Fortran 90 compiler found
Found executable /sw/bin/g77
gnu: no Fortran 90 compiler found
customize Gnu95FCompiler
Found executable /sw/bin/gfortran
customize Gnu95FCompiler
customize UnixCCompiler
customize UnixCCompiler using scons
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 py_modules sources
creating build
creating build/src.macosx-10.3-i386-2.5
creating build/src.macosx-10.3-i386-2.5/scipy
building library "dfftpack" sources
building library "linpack_lite" sources
building library "mach" sources
building library "quadpack" sources
building library "odepack" sources
building library "fitpack" sources
building library "odrpack" sources
building library "minpack" sources
building library "rootfind" sources
building library "superlu_src" sources
building library "arpack" sources
building library "c_misc" sources
building library "cephes" sources
building library "mach" sources
building library "toms" sources
building library "amos" sources
building library "cdf" sources
building library "specfun" sources
building library "statlib" sources
building extension "scipy.cluster._vq" sources
building extension "scipy.cluster._hierarchy_wrap" sources
building extension "scipy.fftpack._fftpack" sources


...


"build/src.macosx-10.3-i386-2.5/build/src.macosx-10.3-i386-2.5/scipy/sparse/linalg/isolve/iterative/_iterativemodule.c"
   adding 'build/src.macosx-10.3-i386-2.5/fortranobject.c' to sources.
   adding 'build/src.macosx-10.3-i386-2.5' to include_dirs.
building extension "scipy.sparse.linalg.dsolve._zsuperlu" sources
building extension "scipy.sparse.linalg.dsolve._dsuperlu" sources
building extension "scipy.sparse.linalg.dsolve._csuperlu" sources
building extension "scipy.sparse.linalg.dsolve._ssuperlu" sources
building extension "scipy.sparse.linalg.dsolve.umfpack.__umfpack" sources
creating build/src.macosx-10.3-i386-2.5/scipy/sparse/linalg/dsolve
creating build/src.macosx-10.3-i386-2.5/scipy/sparse/linalg/dsolve/umfpack
   adding 'scipy/sparse/linalg/dsolve/umfpack/umfpack.i' to sources.
swig: scipy/sparse/linalg/dsolve/umfpack/umfpack.i
swig -python -o 
build/src.macosx-10.3-i386-2.5/scipy/sparse/linalg/dsolve/umfpack/_umfpack_wrap.c 
-outdir 
build/src.macosx-10.3-i386-2.5/scipy/sparse/linalg/dsolve/umfpack 
scipy/sparse/linalg/dsolve/umfpack/umfpack.i
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:192: Error: Unable to find 
'umfpack.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:193: Error: Unable to find 
'umfpack_solve.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:194: Error: Unable to find 
'umfpack_defaults.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:195: Error: Unable to find 
'umfpack_triplet_to_col.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:196: Error: Unable to find 
'umfpack_col_to_triplet.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:197: Error: Unable to find 
'umfpack_transpose.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:198: Error: Unable to find 
'umfpack_scale.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:200: Error: Unable to find 
'umfpack_report_symbolic.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:201: Error: Unable to find 
'umfpack_report_numeric.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:202: Error: Unable to find 
'umfpack_report_info.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:203: Error: Unable to find 
'umfpack_report_control.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:215: Error: Unable to find 
'umfpack_symbolic.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:216: Error: Unable to find 
'umfpack_numeric.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:225: Error: Unable to find 
'umfpack_free_symbolic.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:226: Error: Unable to find 
'umfpack_free_numeric.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:248: Error: Unable to find 
'umfpack_get_lunz.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:272: Error: Unable to find 
'umfpack_get_numeric.h'
error: command 'swig' failed with exit status 1


There is a full build log waiting for the scipy list moderator for 
approval.  Unfortunately the full log is too big for the list.

Thanks,
Chris



-- 
Christopher Hanley
Systems Software Engineer
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21218
(410) 338-4338


From eads at soe.ucsc.edu  Wed Jun  4 02:41:35 2008
From: eads at soe.ucsc.edu (Damian Eads)
Date: Tue, 03 Jun 2008 23:41:35 -0700
Subject: [SciPy-dev] Error building from svn on Intel Macs.
In-Reply-To: <48460D0A.10505@stsci.edu>
References: <mailman.9.1212253204.30437.scipy-dev@scipy.org>	<1D24F3A0-AEA9-4D1C-90E5-E6FAA59A78F3@interactivesupercomputing.com>	<3d375d730805311355rc61eb06k964be661f844ffa5@mail.gmail.com>	<484604CF.50904@stsci.edu>	<4846032C.3020408@ar.media.kyoto-u.ac.jp>
	<48460D0A.10505@stsci.edu>
Message-ID: <4846391F.6050807@soe.ucsc.edu>

Christopher Hanley wrote:
> David Cournapeau wrote:
>> It does not look like a swig problem per se. From the limited log, I 
>> have the impression that scipy is trying to build umfpack solver, 
>> whereas the (optional) umfpack dependencies are not met.
>>
>> Could you give us the full log (at least the configuration step, where 
>> it is looking for umfpack ?)
>>
>> thanks,
>>
>> David
>> _______________________________________________
>> Scipy-dev mailing list
>> Scipy-dev at scipy.org
>> http://projects.scipy.org/mailman/listinfo/scipy-dev
> 
> Sure thing, thanks!  I do not use a site.cfg file and am doing a simple 
> "python setup.py install".

There is an example file in the Scipy source tree, site.cfg.example that 
you can modify and save as site.cfg. site.cfg is necessary so the Scipy 
build script can properly locate dependencies. AFAK, UMFPACK is required 
to build scipy.stats, which depends on scipy.sparse. I followed the 
instructions here, http://www.scipy.org/Installing_SciPy/Linux .

Damian


From nwagner at iam.uni-stuttgart.de  Wed Jun  4 02:42:31 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Wed, 04 Jun 2008 08:42:31 +0200
Subject: [SciPy-dev] ERROR: Tests pdist(X, 'cosine') on the Iris data set.
Message-ID: <web-102785084@uni-stuttgart.de>

Hi All,

Can someone reproduce the following error with
>>> scipy.__version__
'0.7.0.dev4411'
>>> numpy.__version__
'1.2.0.dev5252'

======================================================================
ERROR: Tests pdist(X, 'cosine') on the Iris data set.
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/scipy/cluster/tests/test_hierarchy.py", 
line 264, in test_pdist_cosine_iris
     Y_test1 = pdist(X, 'cosine')
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/scipy/cluster/hierarchy.py", 
line 1478, in pdist
     dm = squareform(dm)
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/scipy/cluster/hierarchy.py", 
line 766, in squareform
     raise ValueError('The distance matrix array must be 
symmetrical.')
ValueError: The distance matrix array must be symmetrical.

Nils


From eads at soe.ucsc.edu  Wed Jun  4 04:12:55 2008
From: eads at soe.ucsc.edu (Damian Eads)
Date: Wed, 04 Jun 2008 01:12:55 -0700
Subject: [SciPy-dev] ERROR: Tests pdist(X,
 'cosine') on the Iris data set.
In-Reply-To: <web-102785084@uni-stuttgart.de>
References: <web-102785084@uni-stuttgart.de>
Message-ID: <48464E87.4070305@soe.ucsc.edu>

Nils Wagner wrote:
> Hi All,
> 
> Can someone reproduce the following error with
>>>> scipy.__version__
> '0.7.0.dev4411'
>>>> numpy.__version__
> '1.2.0.dev5252'
> 
> ======================================================================
> ERROR: Tests pdist(X, 'cosine') on the Iris data set.
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>    File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/scipy/cluster/tests/test_hierarchy.py", 
> line 264, in test_pdist_cosine_iris
>      Y_test1 = pdist(X, 'cosine')
>    File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/scipy/cluster/hierarchy.py", 
> line 1478, in pdist
>      dm = squareform(dm)
>    File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/scipy/cluster/hierarchy.py", 
> line 766, in squareform
>      raise ValueError('The distance matrix array must be 
> symmetrical.')
> ValueError: The distance matrix array must be symmetrical.
> 
> Nils

Sorry about that. This is a fairly new test in a new module so I'm still 
ironing out numerical differences between architectures. Although, I was 
not able to reproduce the error, I believe reverting back to the C 
implementation of pdist(*, 'cosine') instead of the vectorized version 
might fix the problem. I just committed the change (4412).

Damian


From david at ar.media.kyoto-u.ac.jp  Wed Jun  4 04:06:27 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Wed, 04 Jun 2008 17:06:27 +0900
Subject: [SciPy-dev] Error building from svn on Intel Macs.
In-Reply-To: <4846391F.6050807@soe.ucsc.edu>
References: <mailman.9.1212253204.30437.scipy-dev@scipy.org>	<1D24F3A0-AEA9-4D1C-90E5-E6FAA59A78F3@interactivesupercomputing.com>	<3d375d730805311355rc61eb06k964be661f844ffa5@mail.gmail.com>	<484604CF.50904@stsci.edu>	<4846032C.3020408@ar.media.kyoto-u.ac.jp>	<48460D0A.10505@stsci.edu>
	<4846391F.6050807@soe.ucsc.edu>
Message-ID: <48464D03.2020508@ar.media.kyoto-u.ac.jp>

Damian Eads wrote:
>
> There is an example file in the Scipy source tree, site.cfg.example that 
> you can modify and save as site.cfg. site.cfg is necessary so the Scipy 
> build script can properly locate dependencies. AFAK, UMFPACK is required 
> to build scipy.stats, which depends on scipy.sparse.

I would be surprised if this were true (umfpack is only available under 
the GPL, and numpy/scipy have a policy to not depend on non BSD code). I 
don't have umfpack, and up to recently, I could build scipy from the trunk.

cheers,

David


From eads at soe.ucsc.edu  Wed Jun  4 04:52:43 2008
From: eads at soe.ucsc.edu (Damian Eads)
Date: Wed, 04 Jun 2008 01:52:43 -0700
Subject: [SciPy-dev] Error building from svn on Intel Macs.
In-Reply-To: <48464D03.2020508@ar.media.kyoto-u.ac.jp>
References: <mailman.9.1212253204.30437.scipy-dev@scipy.org>	<1D24F3A0-AEA9-4D1C-90E5-E6FAA59A78F3@interactivesupercomputing.com>	<3d375d730805311355rc61eb06k964be661f844ffa5@mail.gmail.com>	<484604CF.50904@stsci.edu>	<4846032C.3020408@ar.media.kyoto-u.ac.jp>	<48460D0A.10505@stsci.edu>	<4846391F.6050807@soe.ucsc.edu>
	<48464D03.2020508@ar.media.kyoto-u.ac.jp>
Message-ID: <484657DB.50705@soe.ucsc.edu>

David Cournapeau wrote:
> Damian Eads wrote:
>> There is an example file in the Scipy source tree, site.cfg.example that 
>> you can modify and save as site.cfg. site.cfg is necessary so the Scipy 
>> build script can properly locate dependencies. AFAK, UMFPACK is required 
>> to build scipy.stats, which depends on scipy.sparse.
> 
> I would be surprised if this were true (umfpack is only available under 
> the GPL, and numpy/scipy have a policy to not depend on non BSD code). I 
> don't have umfpack, and up to recently, I could build scipy from the trunk.

Hi David,

You are the build expert here so I will defer to you.

Recalling from personal experience, the only way I could get Scipy to 
build properly with support for scipy.stats is by building UMFPACK.

I just checked out a fresh copy, did not edit the site.cfg.example file 
to prevent setup.py from finding UMFPACK, and got the same errors as 
Christopher.

[eads at pumpkin trunk]
creating build/src.linux-i686-2.5/scipy/sparse/linalg/dsolve
creating build/src.linux-i686-2.5/scipy/sparse/linalg/dsolve/umfpack
   adding 'scipy/sparse/linalg/dsolve/umfpack/umfpack.i' to sources.
swig: scipy/sparse/linalg/dsolve/umfpack/umfpack.i
swig -python -I/usr/include/atlas -o 
build/src.linux-i686-2.5/scipy/sparse/linalg/dsolve/umfpack/_umfpack_wrap.c 
-outdir build/src.linux-i686-2.5/scipy/sparse/linalg/dsolve/umfpack 
scipy/sparse/linalg/dsolve/umfpack/umfpack.i
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:192: Error: Unable to find 
'umfpack.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:193: Error: Unable to find 
'umfpack_solve.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:194: Error: Unable to find 
'umfpack_defaults.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:195: Error: Unable to find 
'umfpack_triplet_to_col.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:196: Error: Unable to find 
'umfpack_col_to_triplet.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:197: Error: Unable to find 
'umfpack_transpose.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:198: Error: Unable to find 
'umfpack_scale.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:200: Error: Unable to find 
'umfpack_report_symbolic.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:201: Error: Unable to find 
'umfpack_report_numeric.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:202: Error: Unable to find 
'umfpack_report_info.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:203: Error: Unable to find 
'umfpack_report_control.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:215: Error: Unable to find 
'umfpack_symbolic.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:216: Error: Unable to find 
'umfpack_numeric.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:225: Error: Unable to find 
'umfpack_free_symbolic.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:226: Error: Unable to find 
'umfpack_free_numeric.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:248: Error: Unable to find 
'umfpack_get_lunz.h'
scipy/sparse/linalg/dsolve/umfpack/umfpack.i:272: Error: Unable to find 
'umfpack_get_numeric.h'
error: command 'swig' failed with exit status 1
[eads at pumpkin trunk]$

If I comment out the code

     #config.add_subpackage('umfpack')

in scipy/sparse/linalg/dsolve/setup.py, I get the following import error 
when importing scipy.stats.

In [2]: import scipy.stats
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)

/home/eads/work/tst/<ipython console> in <module>()

/tmp/qt/lib/python2.5/site-packages/scipy/stats/__init__.py in <module>()
       5 from info import __doc__
       6
----> 7 from stats import *
       8 from distributions import *
       9 from rv import *

/tmp/qt/lib/python2.5/site-packages/scipy/stats/stats.py in <module>()
     190 from numpy import array, asarray, dot, ma, zeros, sum
     191 import scipy.special as special
--> 192 import scipy.linalg as linalg
     193 import numpy as np
     194

/tmp/qt/lib/python2.5/site-packages/scipy/linalg/__init__.py in <module>()
      11 from blas import *
      12
---> 13 from iterative import *
      14
      15

/tmp/qt/lib/python2.5/site-packages/scipy/linalg/iterative.py in <module>()
       3 # Deprecated on January 26, 2008
       4
----> 5 from scipy.sparse.linalg import isolve
       6 from numpy import deprecate
       7

/tmp/qt/lib/python2.5/site-packages/scipy/sparse/linalg/__init__.py in 
<module>()
       4
       5 from isolve import *
----> 6 from dsolve import *
       7 from interface import *
       8 from eigen import *

/tmp/qt/lib/python2.5/site-packages/scipy/sparse/linalg/dsolve/__init__.py 
in <module>()
       3 from info import __doc__
       4
----> 5 import umfpack
       6 #__doc__ = '\n\n'.join( (__doc__,  umfpack.__doc__) )
       7 del umfpack

ImportError: No module named umfpack

In [3]:

So, I guess, in a nutshell, it was this cursory experience that led me 
to assume UMFPACK was an essential dependency.

Good point about licensing -- I suppose UMFPACK being released under the 
GPL would preclude it from being a mandatory dependency.

Damian


From david at ar.media.kyoto-u.ac.jp  Wed Jun  4 05:07:54 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Wed, 04 Jun 2008 18:07:54 +0900
Subject: [SciPy-dev] Error building from svn on Intel Macs.
In-Reply-To: <484657DB.50705@soe.ucsc.edu>
References: <mailman.9.1212253204.30437.scipy-dev@scipy.org>	<1D24F3A0-AEA9-4D1C-90E5-E6FAA59A78F3@interactivesupercomputing.com>	<3d375d730805311355rc61eb06k964be661f844ffa5@mail.gmail.com>	<484604CF.50904@stsci.edu>	<4846032C.3020408@ar.media.kyoto-u.ac.jp>	<48460D0A.10505@stsci.edu>	<4846391F.6050807@soe.ucsc.edu>	<48464D03.2020508@ar.media.kyoto-u.ac.jp>
	<484657DB.50705@soe.ucsc.edu>
Message-ID: <48465B6A.9020302@ar.media.kyoto-u.ac.jp>

Damian Eads wrote:
>
> Hi David,
>
> You are the build expert here so I will defer to you.
>   

No expertise here, I don't know this code. Can you give me the 
configuration step of building scipy. To avoidhaving long logs, pasting 
only python setup.py config output in scipy/sparse/linalg.dsolve/umfpack 
may be enough.

I would not be surprised if distutils thinks you have umfpack, but 
actually, you have not.

cheers,

David


From nwagner at iam.uni-stuttgart.de  Wed Jun  4 05:46:33 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Wed, 04 Jun 2008 11:46:33 +0200
Subject: [SciPy-dev] ERROR: Tests pdist(X,
 'cosine') on the Iris data set.
In-Reply-To: <48464E87.4070305@soe.ucsc.edu>
References: <web-102785084@uni-stuttgart.de>
 <48464E87.4070305@soe.ucsc.edu>
Message-ID: <web-102797013@uni-stuttgart.de>

On Wed, 04 Jun 2008 01:12:55 -0700
  Damian Eads <eads at soe.ucsc.edu> wrote:
> Nils Wagner wrote:
>> Hi All,
>> 
>> Can someone reproduce the following error with
>>>>> scipy.__version__
>> '0.7.0.dev4411'
>>>>> numpy.__version__
>> '1.2.0.dev5252'
>> 
>> ======================================================================
>> ERROR: Tests pdist(X, 'cosine') on the Iris data set.
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>>    File 
>> "/data/home/nwagner/local/lib/python2.5/site-packages/scipy/cluster/tests/test_hierarchy.py", 
>> line 264, in test_pdist_cosine_iris
>>      Y_test1 = pdist(X, 'cosine')
>>    File 
>> "/data/home/nwagner/local/lib/python2.5/site-packages/scipy/cluster/hierarchy.py", 
>> line 1478, in pdist
>>      dm = squareform(dm)
>>    File 
>> "/data/home/nwagner/local/lib/python2.5/site-packages/scipy/cluster/hierarchy.py", 
>> line 766, in squareform
>>      raise ValueError('The distance matrix array must be 
>> symmetrical.')
>> ValueError: The distance matrix array must be 
>>symmetrical.
>> 
>> Nils
> 
> Sorry about that. This is a fairly new test in a new 
>module so I'm still 
> ironing out numerical differences between architectures. 
>Although, I was 
> not able to reproduce the error, I believe reverting 
>back to the C 
> implementation of pdist(*, 'cosine') instead of the 
>vectorized version 
> might fix the problem. I just committed the change 
>(4412).
> 
> Damian
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev

Damian,

Thank you. Works fine for me now.

Cheers,
           Nils


From nwagner at iam.uni-stuttgart.de  Wed Jun  4 06:11:32 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Wed, 04 Jun 2008 12:11:32 +0200
Subject: [SciPy-dev] Error building from svn on Intel Macs.
In-Reply-To: <484657DB.50705@soe.ucsc.edu>
References: <mailman.9.1212253204.30437.scipy-dev@scipy.org>
	<1D24F3A0-AEA9-4D1C-90E5-E6FAA59A78F3@interactivesupercomputing.com>
	<3d375d730805311355rc61eb06k964be661f844ffa5@mail.gmail.com>
	<484604CF.50904@stsci.edu>
	<4846032C.3020408@ar.media.kyoto-u.ac.jp>
	<48460D0A.10505@stsci.edu> <4846391F.6050807@soe.ucsc.edu>
	<48464D03.2020508@ar.media.kyoto-u.ac.jp>
	<484657DB.50705@soe.ucsc.edu>
Message-ID: <web-102798723@uni-stuttgart.de>

On Wed, 04 Jun 2008 01:52:43 -0700
  Damian Eads <eads at soe.ucsc.edu> wrote:
> David Cournapeau wrote:
>> Damian Eads wrote:
>>> There is an example file in the Scipy source tree, 
>>>site.cfg.example that 
>>> you can modify and save as site.cfg. site.cfg is 
>>>necessary so the Scipy 
>>> build script can properly locate dependencies. AFAK, 
>>>UMFPACK is required 
>>> to build scipy.stats, which depends on scipy.sparse.
>> 
>> I would be surprised if this were true (umfpack is only 
>>available under 
>> the GPL, and numpy/scipy have a policy to not depend on 
>>non BSD code). I 
>> don't have umfpack, and up to recently, I could build 
>>scipy from the trunk.
> 
> Hi David,
> 
> You are the build expert here so I will defer to you.
> 
> Recalling from personal experience, the only way I could 
>get Scipy to 
> build properly with support for scipy.stats is by 
>building UMFPACK.
> 
> I just checked out a fresh copy, did not edit the 
>site.cfg.example file 
> to prevent setup.py from finding UMFPACK, and got the 
>same errors as 
> Christopher.
> 
> [eads at pumpkin trunk]
> creating 
>build/src.linux-i686-2.5/scipy/sparse/linalg/dsolve
> creating 
>build/src.linux-i686-2.5/scipy/sparse/linalg/dsolve/umfpack
>   adding 'scipy/sparse/linalg/dsolve/umfpack/umfpack.i' 
>to sources.
> swig: scipy/sparse/linalg/dsolve/umfpack/umfpack.i
> swig -python -I/usr/include/atlas -o 
> build/src.linux-i686-2.5/scipy/sparse/linalg/dsolve/umfpack/_umfpack_wrap.c 
> -outdir 
>build/src.linux-i686-2.5/scipy/sparse/linalg/dsolve/umfpack 
> scipy/sparse/linalg/dsolve/umfpack/umfpack.i
> scipy/sparse/linalg/dsolve/umfpack/umfpack.i:192: Error: 
>Unable to find 
> 'umfpack.h'
> scipy/sparse/linalg/dsolve/umfpack/umfpack.i:193: Error: 
>Unable to find 
> 'umfpack_solve.h'
> scipy/sparse/linalg/dsolve/umfpack/umfpack.i:194: Error: 
>Unable to find 
> 'umfpack_defaults.h'
> scipy/sparse/linalg/dsolve/umfpack/umfpack.i:195: Error: 
>Unable to find 
> 'umfpack_triplet_to_col.h'
> scipy/sparse/linalg/dsolve/umfpack/umfpack.i:196: Error: 
>Unable to find 
> 'umfpack_col_to_triplet.h'
> scipy/sparse/linalg/dsolve/umfpack/umfpack.i:197: Error: 
>Unable to find 
> 'umfpack_transpose.h'
> scipy/sparse/linalg/dsolve/umfpack/umfpack.i:198: Error: 
>Unable to find 
> 'umfpack_scale.h'
> scipy/sparse/linalg/dsolve/umfpack/umfpack.i:200: Error: 
>Unable to find 
> 'umfpack_report_symbolic.h'
> scipy/sparse/linalg/dsolve/umfpack/umfpack.i:201: Error: 
>Unable to find 
> 'umfpack_report_numeric.h'
> scipy/sparse/linalg/dsolve/umfpack/umfpack.i:202: Error: 
>Unable to find 
> 'umfpack_report_info.h'
> scipy/sparse/linalg/dsolve/umfpack/umfpack.i:203: Error: 
>Unable to find 
> 'umfpack_report_control.h'
> scipy/sparse/linalg/dsolve/umfpack/umfpack.i:215: Error: 
>Unable to find 
> 'umfpack_symbolic.h'
> scipy/sparse/linalg/dsolve/umfpack/umfpack.i:216: Error: 
>Unable to find 
> 'umfpack_numeric.h'
> scipy/sparse/linalg/dsolve/umfpack/umfpack.i:225: Error: 
>Unable to find 
> 'umfpack_free_symbolic.h'
> scipy/sparse/linalg/dsolve/umfpack/umfpack.i:226: Error: 
>Unable to find 
> 'umfpack_free_numeric.h'
> scipy/sparse/linalg/dsolve/umfpack/umfpack.i:248: Error: 
>Unable to find 
> 'umfpack_get_lunz.h'
> scipy/sparse/linalg/dsolve/umfpack/umfpack.i:272: Error: 
>Unable to find 
> 'umfpack_get_numeric.h'
> error: command 'swig' failed with exit status 1
> [eads at pumpkin trunk]$
> 
> If I comment out the code
> 
>     #config.add_subpackage('umfpack')
> 
> in scipy/sparse/linalg/dsolve/setup.py, I get the 
>following import error 
> when importing scipy.stats.
> 
> In [2]: import scipy.stats
> ---------------------------------------------------------------------------
> ImportError                               Traceback 
>(most recent call last)
> 
> /home/eads/work/tst/<ipython console> in <module>()
> 
> /tmp/qt/lib/python2.5/site-packages/scipy/stats/__init__.py 
>in <module>()
>       5 from info import __doc__
>       6
> ----> 7 from stats import *
>       8 from distributions import *
>       9 from rv import *
> 
> /tmp/qt/lib/python2.5/site-packages/scipy/stats/stats.py 
>in <module>()
>     190 from numpy import array, asarray, dot, ma, 
>zeros, sum
>     191 import scipy.special as special
> --> 192 import scipy.linalg as linalg
>     193 import numpy as np
>     194
> 
> /tmp/qt/lib/python2.5/site-packages/scipy/linalg/__init__.py 
>in <module>()
>      11 from blas import *
>      12
> ---> 13 from iterative import *
>      14
>      15
> 
> /tmp/qt/lib/python2.5/site-packages/scipy/linalg/iterative.py 
>in <module>()
>       3 # Deprecated on January 26, 2008
>       4
> ----> 5 from scipy.sparse.linalg import isolve
>       6 from numpy import deprecate
>       7
> 
> /tmp/qt/lib/python2.5/site-packages/scipy/sparse/linalg/__init__.py 
>in 
> <module>()
>       4
>       5 from isolve import *
> ----> 6 from dsolve import *
>       7 from interface import *
>       8 from eigen import *
> 
> /tmp/qt/lib/python2.5/site-packages/scipy/sparse/linalg/dsolve/__init__.py 
> in <module>()
>       3 from info import __doc__
>       4
> ----> 5 import umfpack
>       6 #__doc__ = '\n\n'.join( (__doc__, 
> umfpack.__doc__) )
>       7 del umfpack
> 
> ImportError: No module named umfpack
> 
> In [3]:
> 
> So, I guess, in a nutshell, it was this cursory 
>experience that led me 
> to assume UMFPACK was an essential dependency.
> 
> Good point about licensing -- I suppose UMFPACK being 
>released under the 
> GPL would preclude it from being a mandatory dependency.
> 
> Damian
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev

AFAIK,
you need something like

[amd]
library_dirs= /data/home/nwagner/src/UMFPACKv4.4/AMD/Lib
include_dirs= 
/data/home/nwagner/src/UMFPACKv4.4/AMD/Include
#
[umfpack]
library_dirs= 
/data/home/nwagner/src/UMFPACKv4.4/UMFPACK/Lib
include_dirs= 
/data/home/nwagner/src/UMFPACKv4.4/UMFPACK/Include

in your site.cfg

I have installed UMFPACK version 4.4. It works fine here.

And there is a new possibility to install UMFPACK as a 
scikit

svn co http://svn.scipy.org/svn/scikits/trunk/umfpack 
umfpack

but I am not familiar with that.

Robert C. might help you in this context.

BTW, which versions of UMFPACK are currently supported by
scipy ?

The current version is 5.2.0

http://www.cise.ufl.edu/research/sparse/umfpack/

Cheers,
           Nils



  


From nwagner at iam.uni-stuttgart.de  Wed Jun  4 06:42:02 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Wed, 04 Jun 2008 12:42:02 +0200
Subject: [SciPy-dev] Error building from svn on Intel Macs.
In-Reply-To: <48464D03.2020508@ar.media.kyoto-u.ac.jp>
References: <mailman.9.1212253204.30437.scipy-dev@scipy.org>
	<1D24F3A0-AEA9-4D1C-90E5-E6FAA59A78F3@interactivesupercomputing.com>
	<3d375d730805311355rc61eb06k964be661f844ffa5@mail.gmail.com>
	<484604CF.50904@stsci.edu>
	<4846032C.3020408@ar.media.kyoto-u.ac.jp>
	<48460D0A.10505@stsci.edu> <4846391F.6050807@soe.ucsc.edu>
	<48464D03.2020508@ar.media.kyoto-u.ac.jp>
Message-ID: <web-102800520@uni-stuttgart.de>

On Wed, 04 Jun 2008 17:06:27 +0900
  David Cournapeau <david at ar.media.kyoto-u.ac.jp> wrote:
> Damian Eads wrote:
>>
>> There is an example file in the Scipy source tree, 
>>site.cfg.example that 
>> you can modify and save as site.cfg. site.cfg is 
>>necessary so the Scipy 
>> build script can properly locate dependencies. AFAK, 
>>UMFPACK is required 
>> to build scipy.stats, which depends on scipy.sparse.
> 
> I would be surprised if this were true (umfpack is only 
>available under 
> the GPL, and numpy/scipy have a policy to not depend on 
>non BSD code). I 
> don't have umfpack, and up to recently, I could build 
>scipy from the trunk.
> 
> cheers,
> 
> David

>>> import scipy.stats
/data/home/nwagner/local/lib/python2.5/site-packages/scipy/sparse/linalg/dsolve/linsolve.py:20: 
DeprecationWarning: scipy.sparse.linalg.dsolve.umfpack 
will be removed, install scikits.umfpack instead
   ' install scikits.umfpack instead', DeprecationWarning 
)

AFAIK SuperLU will be used instead of UMFPACK if it is not 
available. Is that correct ?

Nils
  


From ctw at cogsci.info  Thu Jun  5 18:08:42 2008
From: ctw at cogsci.info (Christoph T. Weidemann)
Date: Thu, 5 Jun 2008 18:08:42 -0400
Subject: [SciPy-dev] Bug 791 not completely fixed
In-Reply-To: <c78dc03d0806030429k3754524amdad3cd3bf9a36207@mail.gmail.com>
References: <c78dc03d0806030429k3754524amdad3cd3bf9a36207@mail.gmail.com>
Message-ID: <c78dc03d0806051508t2ff37eden319b8247892c4bba@mail.gmail.com>

Hello again!

I re-opened the ticket for the original bug at:
http://scipy.org/scipy/numpy/ticket/791

Travis Oliphant fixed the bug for std and var in this changeset:
http://scipy.org/scipy/numpy/changeset/5160

I'm hoping the same fix can be applied to clip and imag. Could
somebody who knows this part of the code please take a look?

Thanks!
CTW


On Tue, Jun 3, 2008 at 7:29 AM, I  wrote:
> Hi!
>
> The following bug was marked as fixed, but I believe the current fix
> is incomplete:
> http://scipy.org/scipy/numpy/ticket/791
>
> This issue seemed to not only affect std and var, but also clip and
> imag. For the example code given at the link the following code gives
> the wrong results:
>
> dat.clip(2,7).info # produces ''
> dat.imag.info # produces ''
>
> Let me know if I can provide any additional info that may help fixing this bug!
>
> Best,
> Christoph Weidemann
>


From oliphant at enthought.com  Thu Jun  5 19:31:54 2008
From: oliphant at enthought.com (Travis E. Oliphant)
Date: Thu, 05 Jun 2008 18:31:54 -0500
Subject: [SciPy-dev] Bug 791 not completely fixed
In-Reply-To: <c78dc03d0806051508t2ff37eden319b8247892c4bba@mail.gmail.com>
References: <c78dc03d0806030429k3754524amdad3cd3bf9a36207@mail.gmail.com>
	<c78dc03d0806051508t2ff37eden319b8247892c4bba@mail.gmail.com>
Message-ID: <4848776A.4060700@enthought.com>

Christoph T. Weidemann wrote:
> Hello again!
>
> I re-opened the ticket for the original bug at:
> http://scipy.org/scipy/numpy/ticket/791
>
> Travis Oliphant fixed the bug for std and var in this changeset:
> http://scipy.org/scipy/numpy/changeset/5160
>
> I'm hoping the same fix can be applied to clip and imag. Could
> somebody who knows this part of the code please take a look?
>
>   
Try it now.   It should be fixed in SVN.   There are probably other 
attributes that have this kind of failure as well.  If you could isolate 
them all that would be great.

-Travis




From wnbell at gmail.com  Fri Jun  6 03:01:53 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Fri, 6 Jun 2008 02:01:53 -0500
Subject: [SciPy-dev] changes to lobpcg()
Message-ID: <d05265cb0806060001m4917dfat26b26b3f08ca6e75@mail.gmail.com>

I've rearranged and renamed the parameters to the lobpcg eigensolver.
Ideally, the interface to lobpcg would mimic, as much as possible, the
interface to ARPACK in eigen().

For now, I've just addressed those parameters which have direct analogs.

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


From ctw at cogsci.info  Sat Jun  7 01:20:41 2008
From: ctw at cogsci.info (Christoph T. Weidemann)
Date: Sat, 7 Jun 2008 01:20:41 -0400
Subject: [SciPy-dev] Bug 791 not completely fixed
Message-ID: <c78dc03d0806062220t74561303p483d893bc9b63c05@mail.gmail.com>

On Fri, Jun 6, 2008 at 13:01,  <scipy-dev-request at scipy.org> wrote:
>> Hello again!
>>
>> I re-opened the ticket for the original bug at:
>> http://scipy.org/scipy/numpy/ticket/791
>>
>> Travis Oliphant fixed the bug for std and var in this changeset:
>> http://scipy.org/scipy/numpy/changeset/5160
>>
>> I'm hoping the same fix can be applied to clip and imag. Could
>> somebody who knows this part of the code please take a look?
>>
>>
> Try it now.   It should be fixed in SVN.   There are probably other
> attributes that have this kind of failure as well.  If you could isolate
> them all that would be great.

I committed test cases for every applicable method/attribute/property
that I could find:
http://scipy.org/scipy/numpy/changeset/5257

It works fine for all these cases, so I believe the bug is completely
fixed now (I left a comment on the ticket, but don't seem to be able
to close it again).


From ctw at cogsci.info  Sat Jun  7 01:46:28 2008
From: ctw at cogsci.info (Christoph T. Weidemann)
Date: Sat, 7 Jun 2008 01:46:28 -0400
Subject: [SciPy-dev] unit test failures
Message-ID: <c78dc03d0806062246m3bf53b43w58f68b2ed3d32d21@mail.gmail.com>

Hi!

When running the latest svn versions 5256/5257, I get 3 unit test
failures on my desktop machine, but not on my laptop and one different
failure on my laptop (both Intel running Kubuntu Hardy). I've attached
the error messages below. Does anybody know what's going on here?

CTW


Desktop error messages:

======================================================================
FAIL: Ticket #588
----------------------------------------------------------------------
Traceback (most recent call last):
  File "numpy/core/tests/test_regression.py", line 751, in
check_dot_negative_stride
    assert_equal(np.dot(x,z),np.dot(x,y2))
  File "/home/ctw/src/numpy-trunk/numpy_local_install//lib/python/numpy/testing/utils.py",
line 143, in assert_equal
    return assert_array_equal(actual, desired, err_msg, verbose)
  File "/home/ctw/src/numpy-trunk/numpy_local_install//lib/python/numpy/testing/utils.py",
line 248, in assert_array_equal
    verbose=verbose, header='Arrays are not equal')
  File "/home/ctw/src/numpy-trunk/numpy_local_install//lib/python/numpy/testing/utils.py",
line 240, in assert_array_compare
    assert cond, msg
AssertionError:
Arrays are not equal

(mismatch 100.0%)
 x: array([[ 55924.]])
 y: array([[ 2038100.]])

======================================================================
FAIL: Ticket #588
----------------------------------------------------------------------
Traceback (most recent call last):
  File "numpy/core/tests/test_regression.py", line 751, in
check_dot_negative_stride
    assert_equal(np.dot(x,z),np.dot(x,y2))
  File "/home/ctw/src/numpy-trunk/numpy_local_install//lib/python/numpy/testing/utils.py",
line 143, in assert_equal
    return assert_array_equal(actual, desired, err_msg, verbose)
  File "/home/ctw/src/numpy-trunk/numpy_local_install//lib/python/numpy/testing/utils.py",
line 248, in assert_array_equal
    verbose=verbose, header='Arrays are not equal')
  File "/home/ctw/src/numpy-trunk/numpy_local_install//lib/python/numpy/testing/utils.py",
line 240, in assert_array_compare
    assert cond, msg
AssertionError:
Arrays are not equal

(mismatch 100.0%)
 x: array([[ 55924.]])
 y: array([[ 640000.]])

======================================================================
FAIL: Tests mask_rowcols.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "numpy/ma/tests/test_extras.py", line 211, in check_mask_rowcols
    assert(mask_rowcols(x).all())
AssertionError

----------------------------------------------------------------------
Ran 1306 tests in 5.773s

FAILED (failures=3)
<unittest._TextTestResult run=1306 errors=0 failures=3>
>>> numpy.__version__
'1.2.0.dev5257'




Laptop error message:

FAIL: Tests mask_rowcols.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ctw/src/numpy/numpy_local_install/lib/python/numpy/ma/tests/test_extras.py",
line 211, in check_mask_rowcols
    assert(mask_rowcols(x).all())
AssertionError

----------------------------------------------------------------------
Ran 1306 tests in 1.415s

FAILED (failures=1)
<unittest._TextTestResult run=1306 errors=0 failures=1>
>>> numpy.__version__
'1.2.0.dev5257'


From scipy at SamuelJohn.de  Mon Jun  9 08:30:00 2008
From: scipy at SamuelJohn.de (Samuel John)
Date: Mon, 9 Jun 2008 14:30:00 +0200
Subject: [SciPy-dev] Numpy example for arctan2 perhaps
	wrong/misleading/confusing?
Message-ID: <d5c6595c0806090530i788d6a50j29cc811983baf6f@mail.gmail.com>

Hi all,

the page

http://www.scipy.org/Numpy_Example_List_With_Doc#head-ad8dc60988f26f59ebe565e4af24dc95fcb8a7e9

describes the numpy.arctan2 function and gives an example:

> arctan2(array([0, 1]), array([1, 0]))

However in the example there are used two arrays as arguments to
arctan2, where it should probably be the x and y component of a single
2D vector. What arctan2(x,y) returns is the angle between the 2D
vector (x,y) and the x axis. The example made me assume that it can
compute the angle between two vectors, which it does obviously not.

Wikipedia has a nice article on atan2. I think arctan2 works the same, or?
http://en.wikipedia.org/wiki/Atan2

What could be the reason of using arrays in arctan2? Could someone
update the documentation?
Also help(numpy.arctan2) is not very helpful, to be honest.

cheers,
 Samuel


From stefan at sun.ac.za  Mon Jun  9 09:38:42 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 9 Jun 2008 15:38:42 +0200
Subject: [SciPy-dev] Numpy example for arctan2 perhaps
	wrong/misleading/confusing?
In-Reply-To: <d5c6595c0806090530i788d6a50j29cc811983baf6f@mail.gmail.com>
References: <d5c6595c0806090530i788d6a50j29cc811983baf6f@mail.gmail.com>
Message-ID: <9457e7c80806090638g63c930d7vbbab58f89015092f@mail.gmail.com>

Hi Samuel

2008/6/9 Samuel John <scipy at samueljohn.de>:
> Hi all,
>
> the page
>
> http://www.scipy.org/Numpy_Example_List_With_Doc#head-ad8dc60988f26f59ebe565e4af24dc95fcb8a7e9
>
> describes the numpy.arctan2 function and gives an example:
>
>> arctan2(array([0, 1]), array([1, 0]))
>
> However in the example there are used two arrays as arguments to
> arctan2, where it should probably be the x and y component of a single
> 2D vector. What arctan2(x,y) returns is the angle between the 2D
> vector (x,y) and the x axis. The example made me assume that it can
> compute the angle between two vectors, which it does obviously not.
>
> Wikipedia has a nice article on atan2. I think arctan2 works the same, or?
> http://en.wikipedia.org/wiki/Atan2
>
> What could be the reason of using arrays in arctan2? Could someone
> update the documentation?
> Also help(numpy.arctan2) is not very helpful, to be honest.

You're right, it is not.  Would you like to improve it?

Please register an account for yourself on our documentation wiki:

http://sd-2116.dedibox.fr/pydocweb/doc/numpy.core.umath.arctan2/

I'll then give you permission to edit docstrings.

Regards
St?fan


From david.huard at gmail.com  Mon Jun  9 09:56:02 2008
From: david.huard at gmail.com (David Huard)
Date: Mon, 9 Jun 2008 09:56:02 -0400
Subject: [SciPy-dev] Numpy example for arctan2 perhaps
	wrong/misleading/confusing?
In-Reply-To: <d5c6595c0806090530i788d6a50j29cc811983baf6f@mail.gmail.com>
References: <d5c6595c0806090530i788d6a50j29cc811983baf6f@mail.gmail.com>
Message-ID: <91cf711d0806090656w32a5d48dkbd692ce462d83c3a@mail.gmail.com>

Hi Samuel,

One thing that you should know is that all "ufunc" (universal functions) are
defined as functions operating on scalars. Numpy then wraps these functions
such that they can process ndarrays of any shape element by element. This is
what is explained in the help(arctan2) documentation.

As for the example, maybe a way to avoid confusion would be to give an
example with scalar arguments first to show the basic behavior, and then an
example using ndarray broadcasting.

HTH,

David




2008/6/9 Samuel John <scipy at samueljohn.de>:

> Hi all,
>
> the page
>
>
> http://www.scipy.org/Numpy_Example_List_With_Doc#head-ad8dc60988f26f59ebe565e4af24dc95fcb8a7e9
>
> describes the numpy.arctan2 function and gives an example:
>
> > arctan2(array([0, 1]), array([1, 0]))
>
> However in the example there are used two arrays as arguments to
> arctan2, where it should probably be the x and y component of a single
> 2D vector. What arctan2(x,y) returns is the angle between the 2D
> vector (x,y) and the x axis. The example made me assume that it can
> compute the angle between two vectors, which it does obviously not.
>
> Wikipedia has a nice article on atan2. I think arctan2 works the same, or?
> http://en.wikipedia.org/wiki/Atan2
>
> What could be the reason of using arrays in arctan2? Could someone
> update the documentation?
> Also help(numpy.arctan2) is not very helpful, to be honest.
>
> cheers,
>  Samuel
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080609/c7f37fc8/attachment.html>

From scipy at SamuelJohn.de  Mon Jun  9 10:56:39 2008
From: scipy at SamuelJohn.de (Samuel John)
Date: Mon, 9 Jun 2008 16:56:39 +0200
Subject: [SciPy-dev] Numpy example for arctan2 perhaps
	wrong/misleading/confusing?
In-Reply-To: <91cf711d0806090656w32a5d48dkbd692ce462d83c3a@mail.gmail.com>
References: <d5c6595c0806090530i788d6a50j29cc811983baf6f@mail.gmail.com>
	<91cf711d0806090656w32a5d48dkbd692ce462d83c3a@mail.gmail.com>
Message-ID: <d5c6595c0806090756t2b064b3cmd73102188b441a74@mail.gmail.com>

Hi David!

On Mon, Jun 9, 2008 at 3:56 PM, David Huard <david.huard at gmail.com> wrote:
> One thing that you should know is that all "ufunc" (universal functions) are
> defined as functions operating on scalars. Numpy then wraps these functions
> such that they can process ndarrays of any shape element by element. This is
> what is explained in the help(arctan2) documentation.

I see the point for arctan and other functions with a single argument, but not
for arctan2, especially. It needs two arguments and if I want to
compute the result of the vectors a=array([a1,a2]) and b=array([b1,b2]) like

arctan2(a,b)

what I get is are the two results as if I would have written:

array([ artcan2(a1,b1), arctan2(a2,b2) ])  #Note, this is NOT (a1,a2)
or (b1,b2) !!

If you know this and distribute your vector entries over two arrays, the
broadcasting may be very useful. (As it is for many other functions!)

It would be perhaps nice to call arctan2 with just ONE array argument
and have a broadcasting like this:
 arctan2( array([[a1,a2],[b1,b2],[c1,c2]]) )
 --> array([arctan2(a1,a2), arctan2(b1,b2), arctan2(c1,c2) ] )

and arctan2( array([x,y]) ) --> arctan2(x,y)

> As for the example, maybe a way to avoid confusion would be to give an
> example with scalar arguments first to show the basic behavior, and then an
> example using ndarray broadcasting.

I would argue to show just the scalar version in the example and leave out
the broadcasting version, because it makes less sense here, doesn't it?
Is there any fancy matrix-or-whatever notation, that really makes up a
good example for broadcasting with arctan2?

cheers,
 Samuel

PS: I am not against the current broadcasting scheme. It is perfectly ok.


From robert.kern at gmail.com  Mon Jun  9 11:27:08 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 9 Jun 2008 10:27:08 -0500
Subject: [SciPy-dev] Numpy example for arctan2 perhaps
	wrong/misleading/confusing?
In-Reply-To: <d5c6595c0806090756t2b064b3cmd73102188b441a74@mail.gmail.com>
References: <d5c6595c0806090530i788d6a50j29cc811983baf6f@mail.gmail.com>
	<91cf711d0806090656w32a5d48dkbd692ce462d83c3a@mail.gmail.com>
	<d5c6595c0806090756t2b064b3cmd73102188b441a74@mail.gmail.com>
Message-ID: <3d375d730806090827o25e2984eh770697bbafc7d9fb@mail.gmail.com>

On Mon, Jun 9, 2008 at 09:56, Samuel John <scipy at samueljohn.de> wrote:
> Hi David!
>
> On Mon, Jun 9, 2008 at 3:56 PM, David Huard <david.huard at gmail.com> wrote:
>> One thing that you should know is that all "ufunc" (universal functions) are
>> defined as functions operating on scalars. Numpy then wraps these functions
>> such that they can process ndarrays of any shape element by element. This is
>> what is explained in the help(arctan2) documentation.
>
> I see the point for arctan and other functions with a single argument, but not
> for arctan2, especially. It needs two arguments and if I want to
> compute the result of the vectors a=array([a1,a2]) and b=array([b1,b2]) like
>
> arctan2(a,b)
>
> what I get is are the two results as if I would have written:
>
> array([ artcan2(a1,b1), arctan2(a2,b2) ])  #Note, this is NOT (a1,a2)
> or (b1,b2) !!
>
> If you know this and distribute your vector entries over two arrays, the
> broadcasting may be very useful. (As it is for many other functions!)

This is just something you have to know about ufuncs. Ufuncs simply
don't do (a1,a2). Note also, that this is not actually broadcasting
(which describes what happens when you have arrays that don't have the
same dimensions).

> It would be perhaps nice to call arctan2 with just ONE array argument
> and have a broadcasting like this:
>  arctan2( array([[a1,a2],[b1,b2],[c1,c2]]) )
>  --> array([arctan2(a1,a2), arctan2(b1,b2), arctan2(c1,c2) ] )
>
> and arctan2( array([x,y]) ) --> arctan2(x,y)

No, sorry, that's not going to happen.

>> As for the example, maybe a way to avoid confusion would be to give an
>> example with scalar arguments first to show the basic behavior, and then an
>> example using ndarray broadcasting.
>
> I would argue to show just the scalar version in the example and leave out
> the broadcasting version, because it makes less sense here, doesn't it?

There is no difference between this ufunc and any other.

> Is there any fancy matrix-or-whatever notation, that really makes up a
> good example for broadcasting with arctan2?

I think an array example showing the results for each of the four
quadrants would be ideal in order to show why you would use this over
arctan().

-- 
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 david.huard at gmail.com  Mon Jun  9 11:33:04 2008
From: david.huard at gmail.com (David Huard)
Date: Mon, 9 Jun 2008 11:33:04 -0400
Subject: [SciPy-dev] Numpy example for arctan2 perhaps
	wrong/misleading/confusing?
In-Reply-To: <d5c6595c0806090756t2b064b3cmd73102188b441a74@mail.gmail.com>
References: <d5c6595c0806090530i788d6a50j29cc811983baf6f@mail.gmail.com>
	<91cf711d0806090656w32a5d48dkbd692ce462d83c3a@mail.gmail.com>
	<d5c6595c0806090756t2b064b3cmd73102188b441a74@mail.gmail.com>
Message-ID: <91cf711d0806090833p61900c98vc4d1793cdb9dca8d@mail.gmail.com>

Samuel,

What you want is this :

> [4]: def arctan2(vectors):
   ...:     """Return the angle between the x axis and each vector in
vectors."""
   ...:     v = np.atleast_2d(vectors)
   ...:     return np.arctan2(v[:,0], v[:,1])
   ...:

> [5]: arctan2(([0,0], [1,0]))
< [5]: array([ 0.        ,  1.57079633])


You could also use the numpy.angle function which returns the angle of a
complex argument.

> [15]: np.angle([0, 1j])
 <[15]: array([ 0.        ,  1.57079633])


David


2008/6/9 Samuel John <scipy at samueljohn.de>:

> Hi David!
>
> On Mon, Jun 9, 2008 at 3:56 PM, David Huard <david.huard at gmail.com> wrote:
> > One thing that you should know is that all "ufunc" (universal functions)
> are
> > defined as functions operating on scalars. Numpy then wraps these
> functions
> > such that they can process ndarrays of any shape element by element. This
> is
> > what is explained in the help(arctan2) documentation.
>
> I see the point for arctan and other functions with a single argument, but
> not
> for arctan2, especially. It needs two arguments and if I want to
> compute the result of the vectors a=array([a1,a2]) and b=array([b1,b2])
> like
>
> arctan2(a,b)
>
> what I get is are the two results as if I would have written:
>
> array([ artcan2(a1,b1), arctan2(a2,b2) ])  #Note, this is NOT (a1,a2)
> or (b1,b2) !!
>
> If you know this and distribute your vector entries over two arrays, the
> broadcasting may be very useful. (As it is for many other functions!)
>
> It would be perhaps nice to call arctan2 with just ONE array argument
> and have a broadcasting like this:
>  arctan2( array([[a1,a2],[b1,b2],[c1,c2]]) )
>  --> array([arctan2(a1,a2), arctan2(b1,b2), arctan2(c1,c2) ] )
>
> and arctan2( array([x,y]) ) --> arctan2(x,y)
>
> > As for the example, maybe a way to avoid confusion would be to give an
> > example with scalar arguments first to show the basic behavior, and then
> an
> > example using ndarray broadcasting.
>
> I would argue to show just the scalar version in the example and leave out
> the broadcasting version, because it makes less sense here, doesn't it?
> Is there any fancy matrix-or-whatever notation, that really makes up a
> good example for broadcasting with arctan2?
>
> cheers,
>  Samuel
>
> PS: I am not against the current broadcasting scheme. It is perfectly ok.
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080609/3d015a69/attachment.html>

From guyer at nist.gov  Mon Jun  9 11:47:44 2008
From: guyer at nist.gov (Jonathan Guyer)
Date: Mon, 9 Jun 2008 11:47:44 -0400
Subject: [SciPy-dev] Numpy example for arctan2 perhaps
	wrong/misleading/confusing?
In-Reply-To: <d5c6595c0806090756t2b064b3cmd73102188b441a74@mail.gmail.com>
References: <d5c6595c0806090530i788d6a50j29cc811983baf6f@mail.gmail.com>
	<91cf711d0806090656w32a5d48dkbd692ce462d83c3a@mail.gmail.com>
	<d5c6595c0806090756t2b064b3cmd73102188b441a74@mail.gmail.com>
Message-ID: <CC9E15B8-7BD0-42BB-AEED-AC5B401DA9E0@nist.gov>


On Jun 9, 2008, at 10:56 AM, Samuel John wrote:

> I would argue to show just the scalar version in the example and  
> leave out
> the broadcasting version, because it makes less sense here, doesn't  
> it?

No. Perhaps, though, the example should not use two-element arrays, to  
avoid any ambiguity in interpretation.


> Is there any fancy matrix-or-whatever notation, that really makes up a
> good example for broadcasting with arctan2?

We use this all the time to calculate fields of angles from fields of  
vector components. It's not a matrix thing. It's a field thing. It  
makes just as much (or as little) sense as sin(array([a1, a2,  
a3, ...])).

It works like everything else. Please leave it alone.




From scipy at SamuelJohn.de  Mon Jun  9 11:53:05 2008
From: scipy at SamuelJohn.de (Samuel John)
Date: Mon, 9 Jun 2008 17:53:05 +0200
Subject: [SciPy-dev] Numpy example for arctan2 perhaps
	wrong/misleading/confusing?
In-Reply-To: <3d375d730806090827o25e2984eh770697bbafc7d9fb@mail.gmail.com>
References: <d5c6595c0806090530i788d6a50j29cc811983baf6f@mail.gmail.com>
	<91cf711d0806090656w32a5d48dkbd692ce462d83c3a@mail.gmail.com>
	<d5c6595c0806090756t2b064b3cmd73102188b441a74@mail.gmail.com>
	<3d375d730806090827o25e2984eh770697bbafc7d9fb@mail.gmail.com>
Message-ID: <d5c6595c0806090853u6fc3eff1md6c693b17f8133d4@mail.gmail.com>

Hi Robert!

On Mon, Jun 9, 2008 at 5:27 PM, Robert Kern <robert.kern at gmail.com> wrote:
> This is just something you have to know about ufuncs. Ufuncs simply
> don't do (a1,a2).

I agree, ufuncs are fine the way they are right now. Its just the example
for arctan2 that confused me.

>> It would be perhaps nice to call arctan2 with just ONE array argument
>> and have a broadcasting like this:
>>  arctan2( array([[a1,a2],[b1,b2],[c1,c2]]) )
>>  --> array([arctan2(a1,a2), arctan2(b1,b2), arctan2(c1,c2) ] )
>>
>> and arctan2( array([x,y]) ) --> arctan2(x,y)
>
> No, sorry, that's not going to happen.

I know :-)


> There is no difference between this ufunc and any other.

Hopefully not!


> I think an array example showing the results for each of the four
> quadrants would be ideal in order to show why you would use this over
> arctan().

Yes, this would be best! But I can't think of a vectorized version with arrays.


greetings,
 Samuel


From scipy at SamuelJohn.de  Mon Jun  9 11:59:34 2008
From: scipy at SamuelJohn.de (Samuel John)
Date: Mon, 9 Jun 2008 17:59:34 +0200
Subject: [SciPy-dev] Numpy example for arctan2 perhaps
	wrong/misleading/confusing?
In-Reply-To: <91cf711d0806090833p61900c98vc4d1793cdb9dca8d@mail.gmail.com>
References: <d5c6595c0806090530i788d6a50j29cc811983baf6f@mail.gmail.com>
	<91cf711d0806090656w32a5d48dkbd692ce462d83c3a@mail.gmail.com>
	<d5c6595c0806090756t2b064b3cmd73102188b441a74@mail.gmail.com>
	<91cf711d0806090833p61900c98vc4d1793cdb9dca8d@mail.gmail.com>
Message-ID: <d5c6595c0806090859x28562893y53c0bdbb3deea5c6@mail.gmail.com>

Hi!

> What you want is this :
>
>> [4]: def arctan2(vectors):
>    ...:     """Return the angle between the x axis and each vector in
> vectors."""
>    ...:     v = np.atleast_2d(vectors)
>    ...:     return np.arctan2(v[:,0], v[:,1])
>    ...:
>
>> [5]: arctan2(([0,0], [1,0]))
> < [5]: array([ 0.        ,  1.57079633])

Indeed, very nice.


> You could also use the numpy.angle function which returns the angle of a
> complex argument.
>
>> [15]: np.angle([0, 1j])
>  <[15]: array([ 0.        ,  1.57079633])

Cool, I was not aware of this function. Perfect.
Unfortunately there is no docstring *g*...


-- 
 Samuel


From scipy at SamuelJohn.de  Mon Jun  9 12:06:16 2008
From: scipy at SamuelJohn.de (Samuel John)
Date: Mon, 9 Jun 2008 18:06:16 +0200
Subject: [SciPy-dev] Numpy example for arctan2 perhaps
	wrong/misleading/confusing?
In-Reply-To: <CC9E15B8-7BD0-42BB-AEED-AC5B401DA9E0@nist.gov>
References: <d5c6595c0806090530i788d6a50j29cc811983baf6f@mail.gmail.com>
	<91cf711d0806090656w32a5d48dkbd692ce462d83c3a@mail.gmail.com>
	<d5c6595c0806090756t2b064b3cmd73102188b441a74@mail.gmail.com>
	<CC9E15B8-7BD0-42BB-AEED-AC5B401DA9E0@nist.gov>
Message-ID: <d5c6595c0806090906t46b99e92nc682677b8dfe7862@mail.gmail.com>

Hi there!

On Mon, Jun 9, 2008 at 5:47 PM, Jonathan Guyer <guyer at nist.gov> wrote:
>
> On Jun 9, 2008, at 10:56 AM, Samuel John wrote:
>> I would argue to show just the scalar version in the example and
>> leave out
>> the broadcasting version, because it makes less sense here, doesn't
>> it?
>
> No. Perhaps, though, the example should not use two-element arrays, to
> avoid any ambiguity in interpretation.

However, I would prefer an example with scalars (first) but only for
arctan2... not the other examples.


>> Is there any fancy matrix-or-whatever notation, that really makes up a
>> good example for broadcasting with arctan2?
>

> We use this all the time to calculate fields of angles from fields of
> vector components. It's not a matrix thing. It's a field thing. It
> makes just as much (or as little) sense as sin(array([a1, a2,
> a3, ...])).

ok, fine ...


> It works like everything else. Please leave it alone.

No one want to change anything here :-)
Perhaps just one example :-P


cheers,
 Samuel


From oliphant at enthought.com  Mon Jun  9 13:23:25 2008
From: oliphant at enthought.com (Travis E. Oliphant)
Date: Mon, 09 Jun 2008 12:23:25 -0500
Subject: [SciPy-dev] Numpy example for arctan2
	perhaps	wrong/misleading/confusing?
In-Reply-To: <3d375d730806090827o25e2984eh770697bbafc7d9fb@mail.gmail.com>
References: <d5c6595c0806090530i788d6a50j29cc811983baf6f@mail.gmail.com>	<91cf711d0806090656w32a5d48dkbd692ce462d83c3a@mail.gmail.com>	<d5c6595c0806090756t2b064b3cmd73102188b441a74@mail.gmail.com>
	<3d375d730806090827o25e2984eh770697bbafc7d9fb@mail.gmail.com>
Message-ID: <484D670D.40407@enthought.com>


>> and arctan2( array([x,y]) ) --> arctan2(x,y)
>>     
>
> No, sorry, that's not going to happen.
>   
Another way to put that is that we are not going to do anything special 
to remove the need for a '*'

arctan2(*array([x,y])) is already equivalent to arctan2(x,y)

-Travis



From david.huard at gmail.com  Mon Jun  9 14:08:27 2008
From: david.huard at gmail.com (David Huard)
Date: Mon, 9 Jun 2008 14:08:27 -0400
Subject: [SciPy-dev] Numpy example for arctan2 perhaps
	wrong/misleading/confusing?
In-Reply-To: <d5c6595c0806090859x28562893y53c0bdbb3deea5c6@mail.gmail.com>
References: <d5c6595c0806090530i788d6a50j29cc811983baf6f@mail.gmail.com>
	<91cf711d0806090656w32a5d48dkbd692ce462d83c3a@mail.gmail.com>
	<d5c6595c0806090756t2b064b3cmd73102188b441a74@mail.gmail.com>
	<91cf711d0806090833p61900c98vc4d1793cdb9dca8d@mail.gmail.com>
	<d5c6595c0806090859x28562893y53c0bdbb3deea5c6@mail.gmail.com>
Message-ID: <91cf711d0806091108t3a5fe9a9o3935c4c06e97b806@mail.gmail.com>

2008/6/9 Samuel John <scipy at samueljohn.de>:

> Hi!
>
> > What you want is this :
> >
> >> [4]: def arctan2(vectors):
> >    ...:     """Return the angle between the x axis and each vector in
> > vectors."""
> >    ...:     v = np.atleast_2d(vectors)
> >    ...:     return np.arctan2(v[:,0], v[:,1])
> >    ...:
> >
> >> [5]: arctan2(([0,0], [1,0]))
> > < [5]: array([ 0.        ,  1.57079633])
>
> Indeed, very nice.
>
>
> > You could also use the numpy.angle function which returns the angle of a
> > complex argument.
> >
> >> [15]: np.angle([0, 1j])
> >  <[15]: array([ 0.        ,  1.57079633])
>
> Cool, I was not aware of this function. Perfect.
> Unfortunately there is no docstring *g*...
>

What version of Numpy are you using ? Here is what I have:


    Return the angle of the complex argument z.

    Examples
    --------
    >>> numpy.angle(1+1j)          # in radians
    0.78539816339744828
    >>> numpy.angle(1+1j,deg=True) # in degrees
    45.0






>
>
> --
>  Samuel
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080609/0fa61c26/attachment.html>

From nwagner at iam.uni-stuttgart.de  Tue Jun 10 02:21:04 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Tue, 10 Jun 2008 08:21:04 +0200
Subject: [SciPy-dev] ndimage/_registration.py
Message-ID: <web-103066111@uni-stuttgart.de>

Hi all,

The recent modification in svn raises a syntax error

byte-compiling 
/data/home/nwagner/local/lib/python2.5/site-packages/scipy/ndimage/_registration.py 
to _registration.pyc
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/scipy/ndimage/_registration.py", 
line 1145
     ave_fMRI_volume = 
np.zeros([fmri_desc['layers']*fmri_desc['rows']*fmri_desc['cols']].dtype=np.float64)
SyntaxError: keyword can't be an expression

Nils


From scipy at SamuelJohn.de  Tue Jun 10 02:27:40 2008
From: scipy at SamuelJohn.de (Samuel John)
Date: Tue, 10 Jun 2008 08:27:40 +0200
Subject: [SciPy-dev] Numpy example for arctan2 perhaps
	wrong/misleading/confusing?
In-Reply-To: <484D670D.40407@enthought.com>
References: <d5c6595c0806090530i788d6a50j29cc811983baf6f@mail.gmail.com>
	<91cf711d0806090656w32a5d48dkbd692ce462d83c3a@mail.gmail.com>
	<d5c6595c0806090756t2b064b3cmd73102188b441a74@mail.gmail.com>
	<3d375d730806090827o25e2984eh770697bbafc7d9fb@mail.gmail.com>
	<484D670D.40407@enthought.com>
Message-ID: <d5c6595c0806092327g546e716bwb12c585dd8016d6f@mail.gmail.com>

Hi Travis!

> Another way to put that is that we are not going to do anything special
> to remove the need for a '*'
> arctan2(*array([x,y])) is already equivalent to arctan2(x,y)

I was not aware of the '*' operator in front of the array, since I am
new to python/scipy/numpy.
Indeed, this is a good thing to have!


David,

On Mon, Jun 9, 2008 at 8:08 PM, David Huard <david.huard at gmail.com> wrote:
>What version of Numpy are you using ?

I am using the lates svn version from 2 weeks ago or so. I installed
it with the ScipySuperPack installer on a Mac.



Best Regards,
 Samuel


From robert.kern at gmail.com  Tue Jun 10 02:35:48 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 10 Jun 2008 01:35:48 -0500
Subject: [SciPy-dev] ndimage/_registration.py
In-Reply-To: <web-103066111@uni-stuttgart.de>
References: <web-103066111@uni-stuttgart.de>
Message-ID: <3d375d730806092335n6f14f59rf8379c367dfaac80@mail.gmail.com>

On Tue, Jun 10, 2008 at 01:21, Nils Wagner <nwagner at iam.uni-stuttgart.de> wrote:
> Hi all,
>
> The recent modification in svn raises a syntax error

Fixed in SVN.

-- 
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 peridot.faceted at gmail.com  Tue Jun 10 04:32:44 2008
From: peridot.faceted at gmail.com (Anne Archibald)
Date: Tue, 10 Jun 2008 02:32:44 -0600
Subject: [SciPy-dev] Numpy example for arctan2 perhaps
	wrong/misleading/confusing?
In-Reply-To: <91cf711d0806090833p61900c98vc4d1793cdb9dca8d@mail.gmail.com>
References: <d5c6595c0806090530i788d6a50j29cc811983baf6f@mail.gmail.com>
	<91cf711d0806090656w32a5d48dkbd692ce462d83c3a@mail.gmail.com>
	<d5c6595c0806090756t2b064b3cmd73102188b441a74@mail.gmail.com>
	<91cf711d0806090833p61900c98vc4d1793cdb9dca8d@mail.gmail.com>
Message-ID: <ce557a360806100132r29967682ke9928de5aebdadfd@mail.gmail.com>

2008/6/9 David Huard <david.huard at gmail.com>:
> Samuel,
>
> What you want is this :
>
>> [4]: def arctan2(vectors):
>    ...:     """Return the angle between the x axis and each vector in
> vectors."""
>    ...:     v = np.atleast_2d(vectors)
>    ...:     return np.arctan2(v[:,0], v[:,1])
>    ...:
>
>> [5]: arctan2(([0,0], [1,0]))
> < [5]: array([ 0.        ,  1.57079633])
>
>
> You could also use the numpy.angle function which returns the angle of a
> complex argument.
>
>> [15]: np.angle([0, 1j])
>  <[15]: array([ 0.        ,  1.57079633])

Just a detail, but it would probably be better to write
np.arctan2(v[...,0], v[...,1]) (and then drop the atleast_2d). This
then works for arbitrarily-dimensioned arrays.

Anne


From david.huard at gmail.com  Tue Jun 10 08:42:23 2008
From: david.huard at gmail.com (David Huard)
Date: Tue, 10 Jun 2008 08:42:23 -0400
Subject: [SciPy-dev] Numpy example for arctan2 perhaps
	wrong/misleading/confusing?
In-Reply-To: <ce557a360806100132r29967682ke9928de5aebdadfd@mail.gmail.com>
References: <d5c6595c0806090530i788d6a50j29cc811983baf6f@mail.gmail.com>
	<91cf711d0806090656w32a5d48dkbd692ce462d83c3a@mail.gmail.com>
	<d5c6595c0806090756t2b064b3cmd73102188b441a74@mail.gmail.com>
	<91cf711d0806090833p61900c98vc4d1793cdb9dca8d@mail.gmail.com>
	<ce557a360806100132r29967682ke9928de5aebdadfd@mail.gmail.com>
Message-ID: <91cf711d0806100542m33ab9b21kcc75210a00eca62@mail.gmail.com>

2008/6/10 Anne Archibald <peridot.faceted at gmail.com>:

> 2008/6/9 David Huard <david.huard at gmail.com>:
> > Samuel,
> >
> > What you want is this :
> >
> >> [4]: def arctan2(vectors):
> >    ...:     """Return the angle between the x axis and each vector in
> > vectors."""
> >    ...:     v = np.atleast_2d(vectors)
> >    ...:     return np.arctan2(v[:,0], v[:,1])
> >    ...:
> >
> >> [5]: arctan2(([0,0], [1,0]))
> > < [5]: array([ 0.        ,  1.57079633])
> >
> >
> > You could also use the numpy.angle function which returns the angle of a
> > complex argument.
> >
> >> [15]: np.angle([0, 1j])
> >  <[15]: array([ 0.        ,  1.57079633])
>
> Just a detail, but it would probably be better to write
> np.arctan2(v[...,0], v[...,1]) (and then drop the atleast_2d). This
> then works for arbitrarily-dimensioned arrays.
>

Nice.

Thanks for the pointer,

David


>
> Anne
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080610/9a93abb2/attachment.html>

From millman at berkeley.edu  Tue Jun 10 17:07:29 2008
From: millman at berkeley.edu (Jarrod Millman)
Date: Tue, 10 Jun 2008 14:07:29 -0700
Subject: [SciPy-dev] ANN: SciPy 2008 Conference
Message-ID: <c7009a550806101407w1b0fe427r6ed789e34340a2f2@mail.gmail.com>

Greetings,

The SciPy 2008 Conference website is now open:  http://conference.scipy.org

This year's conference will be at Caltech from August 19-24:

Tutorials:        August 19-20 (Tuesday and Wednesday)
Conference:  August 21-22 (Thursday and Friday)
Sprints:           August 23-24 (Saturday and Sunday)

Exciting things are happening in the Python community, and the SciPy
2008 Conference is an excellent opportunity to exchange ideas, learn
techniques, contribute code and affect the direction of scientific
computing (or just to learn what all the fuss is about).  We'll be
announcing the Keynote Speaker and providing a detailed schedule in
the coming weeks.

This year we are asking presenters to submit short papers to be included
in the conference proceedings:  http://conference.scipy.org/call_for_papers

Cheers,

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


From cohen at slac.stanford.edu  Tue Jun 10 18:40:58 2008
From: cohen at slac.stanford.edu (Johann Cohen-Tanugi)
Date: Wed, 11 Jun 2008 00:40:58 +0200
Subject: [SciPy-dev] [SciPy-user] ANN: NumPy/SciPy Documentation
 Marathon 2008
In-Reply-To: <483000B9.7000602@slac.stanford.edu>
References: <483000B9.7000602@slac.stanford.edu>
Message-ID: <484F02FA.6070403@slac.stanford.edu>

I seem to have lost the permissions to edit 
inhttp://sd-2116.dedibox.fr/pydocweb/wiki/Front%20Page/, which has 
changed in look'n'feel since last I logged in. Anyway, can someone 
reinstate my permissions?
thanks,
Johann

Johann Cohen-Tanugi wrote:
> Great! I am onboard : wiki username JohannCohenTanugi
> - review docstrings
> - test examples
> - write some? I have not developed any core numpy/scipy functions, but I 
> use python extensively at work.
> - I am not a native English speaker, but I lived a good 6 years in the 
> U.S.A, so I can make do if needed. ;)
> Sunday is perfect to start diving in... See you all "there".
> best,
> Johann
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>   


From ulrik at 42degreesoffreedom.com  Wed Jun 11 12:33:38 2008
From: ulrik at 42degreesoffreedom.com (=?ISO-8859-1?Q?Ulrik_G=FCnther?=)
Date: Wed, 11 Jun 2008 18:33:38 +0200
Subject: [SciPy-dev] {Num,Sci}Py on 64bit Intel Macs with icc, ifort, mkl
Message-ID: <F6531E65-B5B2-4E59-92B9-CBF7E07C1FEE@42degreesoffreedom.com>

Hi list,

some time ago, I build a version of NumPy and Scipy for 64bit Intel  
Macs with the Intel C++/Fortran Compiler, which has been
a bit hackish.

I noticed that this causes some problems in the build process, but at  
least compiler detection seems to work now with
the current SVN version. I'd like to ask if there is any help needed  
in making NumPy and SciPy work better on Mac OS X,
specifically when targeting the 64bit part of the Intel Macs.

Glitches I've noticed were, for example, that the MKL is not
detected properly, as the Accelerate Framework is checked before and  
there seems to be no option to tell the distutils that
one wants to use the Intel MKL. Additionally, some libraries fail to  
link, mostly due to the Python framework not being linked
in or due to the fact that the linker is not told to use dynamic  
symbol lookup.

If there my help is needed, can somebody point me to anyone who is  
more familiar with the distutils (say: who knows where
in the source code which check for this and that library is and who  
can give me a short overview of the build system - I already
got a, well, tentative one, but I want to avoid mistakes ;) ), so I  
can fix these things up?

Thanks in advance,

ulrik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080611/70937fec/attachment.sig>

From david at ar.media.kyoto-u.ac.jp  Wed Jun 11 12:29:45 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Thu, 12 Jun 2008 01:29:45 +0900
Subject: [SciPy-dev] {Num, Sci}Py on 64bit Intel Macs with icc, ifort,
 mkl
In-Reply-To: <F6531E65-B5B2-4E59-92B9-CBF7E07C1FEE@42degreesoffreedom.com>
References: <F6531E65-B5B2-4E59-92B9-CBF7E07C1FEE@42degreesoffreedom.com>
Message-ID: <484FFD79.6030309@ar.media.kyoto-u.ac.jp>

Ulrik G?nther wrote:
>
> Glitches I've noticed were, for example, that the MKL is not
> detected properly, as the Accelerate Framework is checked before and 
> there seems to be no option to tell the distutils that
> one wants to use the Intel MKL. 

Yes, normally you can disable one lib with an environment variable (such 
as MKL=None will disable MKL even if detected), but this is not 
implemented for the Accelerate framework, from quickly looking at the 
sources.

>
> If there my help is needed, can somebody point me to anyone who is 
> more familiar with the distutils (say: who knows where
> in the source code which check for this and that library is and who 
> can give me a short overview of the build system - I already
> got a, well, tentative one, but I want to avoid mistakes ;) ),

Solving the Accelerate framework problem should be relatively easy: look 
at numpy/distutils/system_info.py.  The link problems, I don't know, 
since you have not given enough details for them. The numpy build 
process is based on the python package distutils: distutils is a really 
badly designed piece of code, and extremely fragile to changes (it is 
one more proof that you can write Fortran in any language) and jumping 
in is not easy.

I personally would be interested in supporting this configuration with 
my own project numscons, which is a tentative to circumvent distutils 
limitations to build numpy and scipy.

cheers,

David


From ulrik at 42degreesoffreedom.com  Wed Jun 11 13:01:33 2008
From: ulrik at 42degreesoffreedom.com (=?ISO-8859-1?Q?Ulrik_G=FCnther?=)
Date: Wed, 11 Jun 2008 19:01:33 +0200
Subject: [SciPy-dev] {Num, Sci}Py on 64bit Intel Macs with icc, ifort,
	mkl
In-Reply-To: <484FFD79.6030309@ar.media.kyoto-u.ac.jp>
References: <F6531E65-B5B2-4E59-92B9-CBF7E07C1FEE@42degreesoffreedom.com>
	<484FFD79.6030309@ar.media.kyoto-u.ac.jp>
Message-ID: <253BDE06-5C61-4B6B-BBDD-31A4491A692C@42degreesoffreedom.com>

Hi David,

first, thanks for your fast reply.
> Yes, normally you can disable one lib with an environment variable  
> (such
> as MKL=None will disable MKL even if detected), but this is not
> implemented for the Accelerate framework, from quickly looking at the
> sources.
Yeah, noticed that also. Accelerate is checked first with no option to  
disable it :/

> Solving the Accelerate framework problem should be relatively easy:  
> look
> at numpy/distutils/system_info.py.  The link problems, I don't know,
> since you have not given enough details for them.
The problem is, when compiling/linking, for example, multiarray.so,  
the compiler spits
out many not found symbols, primarily due to not appending -framework  
Python to the
compiling options. The problem can be solved be manually compiling the  
file, while appending
the respective option (along with -undefined dynamic_lookup, as _main  
is not found else, which
may also be a Fortran-compiler related problem, so maybe -no-formain  
for the ifort is more
appropriate than using dynamic lookups...)

> The numpy build
> process is based on the python package distutils: distutils is a  
> really
> badly designed piece of code,
I noticed that on several occasions ;)

> and extremely fragile to changes (it is
> one more proof that you can write Fortran in any language) and jumping
> in is not easy.
>
> I personally would be interested in supporting this configuration with
> my own project numscons, which is a tentative to circumvent distutils
> limitations to build numpy and scipy.
I already looked into the SCons version, but I was not sure about its  
state in the project, as
there is no really information on the website. In fact, my currently  
running version of 64bit
{Num,Sci}py was built using the SCons branch, with a bit of patching  
around.

Could you please tell me what I need now for using the SCons branch?  
Updating my old version
via svn up didn't work, so the first thing I thought was that it has  
been discontinued. I'm very
glad to hear that this is not the case. If I manage to get a working  
build on my configuration,
may I direct to patches to you?

Thanks,

ulrik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080611/f0ff4353/attachment.sig>

From david at ar.media.kyoto-u.ac.jp  Wed Jun 11 13:16:13 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Thu, 12 Jun 2008 02:16:13 +0900
Subject: [SciPy-dev] {Num, Sci}Py on 64bit Intel Macs with icc, ifort,
 mkl
In-Reply-To: <253BDE06-5C61-4B6B-BBDD-31A4491A692C@42degreesoffreedom.com>
References: <F6531E65-B5B2-4E59-92B9-CBF7E07C1FEE@42degreesoffreedom.com>	<484FFD79.6030309@ar.media.kyoto-u.ac.jp>
	<253BDE06-5C61-4B6B-BBDD-31A4491A692C@42degreesoffreedom.com>
Message-ID: <4850085D.6000600@ar.media.kyoto-u.ac.jp>

Ulrik G?nther wrote:
> The problem is, when compiling/linking, for example, multiarray.so, 
> the compiler spits
> out many not found symbols, primarily due to not appending -framework 
> Python to the
> compiling options. The problem can be solved be manually compiling the 
> file, while appending
> the respective option (along with -undefined dynamic_lookup, as _main 
> is not found else, which
> may also be a Fortran-compiler related problem, so maybe -no-formain 
> for the ifort is more
> appropriate than using dynamic lookups...)

-undefined dynamic_lookup tells the apple linker to succeed even if some 
symbols are missing. But that should be handled by distutils, actually 
(or maybe distutils does not know about icc on the mac ?)

> Could you please tell me what I need now for using the SCons branch? 
> Updating my old version
> via svn up didn't work, so the first thing I thought was that it has 
> been discontinued. I'm very
> glad to hear that this is not the case. If I manage to get a working 
> build on my configuration,
> may I direct to patches to you?

Before, scons support was a separate branch, but now, it is integrated 
in both numpy and scipy trunk (even in the source tarball for numpy 
starting at 1.1.0).

scons support has two sides:
    - numpy/scipy side: just some hooks to call scons, as well as the 
scons scripts themselves.
    - numscons: it implements everything to build python extensions, 
check for blas/lapack/co, fortran capabilities, etc...

So you need sources (from the trunk for scipy), and numscons, which 
development happens on launchpad (code, bugs, patches, and co):

https://code.launchpad.net/numpy.scons.support

If you want to look at the code, and hack on it, I would suggest to get 
the sources with bzr:

bzr branch lp:numpy.scons.support/trunk

You can then send your changes to launchpad, which will handle the merge 
requests (for review).

Unfortunately, I have to confess the code for performance libraries 
checkers is still pretty bad (it is clearly over-designed, and the 
simple concepts are still struggling to get out: there are way too many 
classes over there). There are some things which are better than 
distutils IMHO; in particular, all the checkers use the same code (which 
is one reason why the actual code is so convoluted for now), and the 
basic options for each library are in configuration files, not in code 
(numscons/checkers/perflig.cfg).

That's a part of the code which definitely needs some cleaning and 
refactoring,

cheers,

David


From charlesr.harris at gmail.com  Wed Jun 11 15:12:22 2008
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Wed, 11 Jun 2008 13:12:22 -0600
Subject: [SciPy-dev] unit test failures
In-Reply-To: <c78dc03d0806062246m3bf53b43w58f68b2ed3d32d21@mail.gmail.com>
References: <c78dc03d0806062246m3bf53b43w58f68b2ed3d32d21@mail.gmail.com>
Message-ID: <e06186140806111212m92e8321yffda37e092380df9@mail.gmail.com>

On Fri, Jun 6, 2008 at 11:46 PM, Christoph T. Weidemann <ctw at cogsci.info>
wrote:

> Hi!
>
> When running the latest svn versions 5256/5257, I get 3 unit test
> failures on my desktop machine, but not on my laptop and one different
> failure on my laptop (both Intel running Kubuntu Hardy). I've attached
> the error messages below. Does anybody know what's going on here?
>
> CTW
>
>
> Desktop error messages:
>
> ======================================================================
> FAIL: Ticket #588
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File "numpy/core/tests/test_regression.py", line 751, in
> check_dot_negative_stride
>    assert_equal(np.dot(x,z),np.dot(x,y2))
>  File
> "/home/ctw/src/numpy-trunk/numpy_local_install//lib/python/numpy/testing/utils.py",
> line 143, in assert_equal
>    return assert_array_equal(actual, desired, err_msg, verbose)
>  File
> "/home/ctw/src/numpy-trunk/numpy_local_install//lib/python/numpy/testing/utils.py",
> line 248, in assert_array_equal
>    verbose=verbose, header='Arrays are not equal')
>  File
> "/home/ctw/src/numpy-trunk/numpy_local_install//lib/python/numpy/testing/utils.py",
> line 240, in assert_array_compare
>    assert cond, msg
> AssertionError:
> Arrays are not equal
>
> (mismatch 100.0%)
>  x: array([[ 55924.]])
>  y: array([[ 2038100.]])
>
> ======================================================================
> FAIL: Ticket #588
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File "numpy/core/tests/test_regression.py", line 751, in
> check_dot_negative_stride
>    assert_equal(np.dot(x,z),np.dot(x,y2))
>  File
> "/home/ctw/src/numpy-trunk/numpy_local_install//lib/python/numpy/testing/utils.py",
> line 143, in assert_equal
>    return assert_array_equal(actual, desired, err_msg, verbose)
>  File
> "/home/ctw/src/numpy-trunk/numpy_local_install//lib/python/numpy/testing/utils.py",
> line 248, in assert_array_equal
>    verbose=verbose, header='Arrays are not equal')
>  File
> "/home/ctw/src/numpy-trunk/numpy_local_install//lib/python/numpy/testing/utils.py",
> line 240, in assert_array_compare
>    assert cond, msg
> AssertionError:
> Arrays are not equal
>
> (mismatch 100.0%)
>  x: array([[ 55924.]])
>  y: array([[ 640000.]])
>

I haven't seen these before. Can you check if they are still present? Also,
try deleting the numpy package in site-packages before the install.


> ======================================================================
> FAIL: Tests mask_rowcols.
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File "numpy/ma/tests/test_extras.py", line 211, in check_mask_rowcols
>    assert(mask_rowcols(x).all())
> AssertionError
>
> ----------------------------------------------------------------------
> Ran 1306 tests in 5.773s
>
> FAILED (failures=3)
> <unittest._TextTestResult run=1306 errors=0 failures=3>
> >>> numpy.__version__
> '1.2.0.dev5257'
>
>
>
>
> Laptop error message:
>
> FAIL: Tests mask_rowcols.
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File
> "/home/ctw/src/numpy/numpy_local_install/lib/python/numpy/ma/tests/test_extras.py",
> line 211, in check_mask_rowcols
>    assert(mask_rowcols(x).all())
> AssertionError
>
> ----------------------------------------------------------------------
> Ran 1306 tests in 1.415s
>
> FAILED (failures=1)
> <unittest._TextTestResult run=1306 errors=0 failures=1>
> >>> numpy.__version__
> '1.2.0.dev5257'
> __


This one has been fixed.

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

From robert.kern at gmail.com  Wed Jun 11 15:42:06 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 11 Jun 2008 14:42:06 -0500
Subject: [SciPy-dev] {Num, Sci}Py on 64bit Intel Macs with icc, ifort,
	mkl
In-Reply-To: <4850085D.6000600@ar.media.kyoto-u.ac.jp>
References: <F6531E65-B5B2-4E59-92B9-CBF7E07C1FEE@42degreesoffreedom.com>
	<484FFD79.6030309@ar.media.kyoto-u.ac.jp>
	<253BDE06-5C61-4B6B-BBDD-31A4491A692C@42degreesoffreedom.com>
	<4850085D.6000600@ar.media.kyoto-u.ac.jp>
Message-ID: <3d375d730806111242w15101a2w56184e916ffff4f@mail.gmail.com>

On Wed, Jun 11, 2008 at 12:16, David Cournapeau
<david at ar.media.kyoto-u.ac.jp> wrote:
> Ulrik G?nther wrote:
>> The problem is, when compiling/linking, for example, multiarray.so,
>> the compiler spits
>> out many not found symbols, primarily due to not appending -framework
>> Python to the
>> compiling options. The problem can be solved be manually compiling the
>> file, while appending
>> the respective option (along with -undefined dynamic_lookup, as _main
>> is not found else, which
>> may also be a Fortran-compiler related problem, so maybe -no-formain
>> for the ifort is more
>> appropriate than using dynamic lookups...)
>
> -undefined dynamic_lookup tells the apple linker to succeed even if some
> symbols are missing. But that should be handled by distutils, actually
> (or maybe distutils does not know about icc on the mac ?)

Correct, it does not. It needs to be taught. I believe that just
"-undefined dynamic_lookup" is necessary; "-framework Python" is
redundant since it will be available to the dynamic_lookup as soon as
the extension module is loaded.

And the hard-coding of Accelerate is my fault, oh so many years ago.

-- 
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 rmay31 at gmail.com  Wed Jun 11 22:13:21 2008
From: rmay31 at gmail.com (Ryan May)
Date: Wed, 11 Jun 2008 22:13:21 -0400
Subject: [SciPy-dev] ANN: SciPy 2008 Conference
In-Reply-To: <c7009a550806101407w1b0fe427r6ed789e34340a2f2@mail.gmail.com>
References: <c7009a550806101407w1b0fe427r6ed789e34340a2f2@mail.gmail.com>
Message-ID: <48508641.3060806@gmail.com>

Jarrod Millman wrote:
> Greetings,
> 
> The SciPy 2008 Conference website is now open:  http://conference.scipy.org
> 
> This year's conference will be at Caltech from August 19-24:
> 
> Tutorials:        August 19-20 (Tuesday and Wednesday)
> Conference:  August 21-22 (Thursday and Friday)
> Sprints:           August 23-24 (Saturday and Sunday)
> 
> Exciting things are happening in the Python community, and the SciPy
> 2008 Conference is an excellent opportunity to exchange ideas, learn
> techniques, contribute code and affect the direction of scientific
> computing (or just to learn what all the fuss is about).  We'll be
> announcing the Keynote Speaker and providing a detailed schedule in
> the coming weeks.
> 
> This year we are asking presenters to submit short papers to be included
> in the conference proceedings:  http://conference.scipy.org/call_for_papers
> 

Is food being provided like it was last year?

Also, one might want to mention the registration fee(s) upfront 
somewhere easily visible.  I had to actually register for the conference 
before I could find out how much it would cost.

Thanks

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma


From travis at enthought.com  Wed Jun 11 23:52:16 2008
From: travis at enthought.com (Travis Vaught)
Date: Wed, 11 Jun 2008 22:52:16 -0500
Subject: [SciPy-dev] ANN: SciPy 2008 Conference
In-Reply-To: <48508641.3060806@gmail.com>
References: <c7009a550806101407w1b0fe427r6ed789e34340a2f2@mail.gmail.com>
	<48508641.3060806@gmail.com>
Message-ID: <DEEDA196-8FB7-41B7-BFE2-5D70A6911A6B@enthought.com>

>>
> Is food being provided like it was last year?
>

Yes! I've added a note to the conference front page.

> Also, one might want to mention the registration fee(s) upfront
> somewhere easily visible.  I had to actually register for the  
> conference
> before I could find out how much it would cost.

Right.  I've added this as well.  Thanks for pointing this out.

>
>
> Thanks
>
> Ryan
>
> -- 
> Ryan May
> Graduate Research Assistant
> School of Meteorology
> University of Oklahoma
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>



From travis at enthought.com  Fri Jun 13 08:35:39 2008
From: travis at enthought.com (Travis Vaught)
Date: Fri, 13 Jun 2008 07:35:39 -0500
Subject: [SciPy-dev] EuroSciPy Early Registration Reminder
Message-ID: <BB14B827-D312-4C06-8521-1D26A13A96A0@enthought.com>

Greetings,

This is a friendly reminder that the Early Registration deadline for  
the EuroSciPy Conference is June 15th.  If you're interested in  
attending, but have not yet registered, please visit:

http://www.scipy.org/EuroSciPy2008

The talks schedule is also now available there.

Also, the keynote speaker this year will be Travis Oliphant, the  
primary author of the recent NumPy rewrite.  For those doing  
scientific computing using Python, this is a conference you'll not  
want to miss.

See you there.

Travis


From ulrik at 42degreesoffreedom.com  Sat Jun 14 10:44:22 2008
From: ulrik at 42degreesoffreedom.com (=?ISO-8859-1?Q?Ulrik_G=FCnther?=)
Date: Sat, 14 Jun 2008 16:44:22 +0200
Subject: [SciPy-dev] {Num, Sci}Py on 64bit Intel Macs with icc, ifort,
	mkl
In-Reply-To: <3d375d730806111242w15101a2w56184e916ffff4f@mail.gmail.com>
References: <F6531E65-B5B2-4E59-92B9-CBF7E07C1FEE@42degreesoffreedom.com>
	<484FFD79.6030309@ar.media.kyoto-u.ac.jp>
	<253BDE06-5C61-4B6B-BBDD-31A4491A692C@42degreesoffreedom.com>
	<4850085D.6000600@ar.media.kyoto-u.ac.jp>
	<3d375d730806111242w15101a2w56184e916ffff4f@mail.gmail.com>
Message-ID: <0032C278-D9BB-4133-9026-218C93665D71@42degreesoffreedom.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi everyone,

I have a little patch here for numpy/distutils/fcompiler/gnu.py, which  
seems to relieve the dynamic_lookup problem
when linking a .so :

@@ -100,8 +100,8 @@
                      'MACOSX_DEPLOYMENT_TARGET reset to %s.%s' %  
(major, minor))
              os.environ['MACOSX_DEPLOYMENT_TARGET'] = '%s.%s' % (major,
                  minor)
- -
- -            opt.extend(['-undefined', 'dynamic_lookup', '-bundle'])
+
+            self.linker_so.extend(['-undefined', 'dynamic_lookup', '- 
bundle'])
          else:
              opt.append("-shared")
          if sys.platform.startswith('sunos'):
@@ -189,6 +189,9 @@
                      opt.append('-mcpu='+a)
                      opt.append('-mtune='+a)
                      break
+
+            opt.append('-framework Python')
+            opt.append('-undefined dynamic_lookup')
              return opt

          # default march options in case we find nothing better
@@ -374,9 +377,12 @@
  if __name__ == '__main__':
      from distutils import log
      log.set_verbosity(2)
- -    compiler = GnuFCompiler()
- -    compiler.customize()
- -    print compiler.get_version()
+    try:
+        compiler = GnuFCompiler()
+        compiler.customize()
+        print compiler.get_version()
+    except Exception, msg:
+        print msg
      raw_input('Press ENTER to continue...')
      try:
          compiler = Gnu95FCompiler()

My problem with this solution is the following:

in the function get_flags_linker_so(), there is a line of code in the  
beginning:

 >> opt = self.linker_so[1:]

where the opt array is modified in the following, then returned. What  
I noticed is that
whatever is put into that array is not passed on. So my solution here  
is to directly modify the
self.linker_so array with the corresponding options. I do not think  
that this is a clean solution,
but it works for the moment. I'd be glad if you could comment a bit on  
the patch (if it is okay, if
the problem should be solved elsewhere, etc.).

Thanks,

ulrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFIU9lGy06DkvPH780RAivhAJ0eVOhOWDhy38YzJCOo3lQeJVEQiACeJGFj
sJpSQ+3cnaBeteeA0eOTGK0=
=xhkn
-----END PGP SIGNATURE-----


From robert.kern at gmail.com  Sat Jun 14 18:31:15 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Sat, 14 Jun 2008 17:31:15 -0500
Subject: [SciPy-dev] {Num, Sci}Py on 64bit Intel Macs with icc, ifort,
	mkl
In-Reply-To: <0032C278-D9BB-4133-9026-218C93665D71@42degreesoffreedom.com>
References: <F6531E65-B5B2-4E59-92B9-CBF7E07C1FEE@42degreesoffreedom.com>
	<484FFD79.6030309@ar.media.kyoto-u.ac.jp>
	<253BDE06-5C61-4B6B-BBDD-31A4491A692C@42degreesoffreedom.com>
	<4850085D.6000600@ar.media.kyoto-u.ac.jp>
	<3d375d730806111242w15101a2w56184e916ffff4f@mail.gmail.com>
	<0032C278-D9BB-4133-9026-218C93665D71@42degreesoffreedom.com>
Message-ID: <3d375d730806141531s7b01bf36m6b90422238e56309@mail.gmail.com>

On Sat, Jun 14, 2008 at 09:44, Ulrik G?nther
<ulrik at 42degreesoffreedom.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi everyone,
>
> I have a little patch here for numpy/distutils/fcompiler/gnu.py, which
> seems to relieve the dynamic_lookup problem
> when linking a .so :
>
> @@ -100,8 +100,8 @@
>                      'MACOSX_DEPLOYMENT_TARGET reset to %s.%s' %
> (major, minor))
>              os.environ['MACOSX_DEPLOYMENT_TARGET'] = '%s.%s' % (major,
>                  minor)
> - -
> - -            opt.extend(['-undefined', 'dynamic_lookup', '-bundle'])
> +
> +            self.linker_so.extend(['-undefined', 'dynamic_lookup', '-
> bundle'])
>          else:
>              opt.append("-shared")
>          if sys.platform.startswith('sunos'):
> @@ -189,6 +189,9 @@
>                      opt.append('-mcpu='+a)
>                      opt.append('-mtune='+a)
>                      break
> +
> +            opt.append('-framework Python')
> +            opt.append('-undefined dynamic_lookup')
>              return opt
>
>          # default march options in case we find nothing better
> @@ -374,9 +377,12 @@
>  if __name__ == '__main__':
>      from distutils import log
>      log.set_verbosity(2)
> - -    compiler = GnuFCompiler()
> - -    compiler.customize()
> - -    print compiler.get_version()
> +    try:
> +        compiler = GnuFCompiler()
> +        compiler.customize()
> +        print compiler.get_version()
> +    except Exception, msg:
> +        print msg
>      raw_input('Press ENTER to continue...')
>      try:
>          compiler = Gnu95FCompiler()
>
> My problem with this solution is the following:
>
> in the function get_flags_linker_so(), there is a line of code in the
> beginning:
>
>  >> opt = self.linker_so[1:]
>
> where the opt array is modified in the following, then returned. What
> I noticed is that
> whatever is put into that array is not passed on. So my solution here
> is to directly modify the
> self.linker_so array with the corresponding options. I do not think
> that this is a clean solution,
> but it works for the moment. I'd be glad if you could comment a bit on
> the patch (if it is okay, if
> the problem should be solved elsewhere, etc.).

It needs to be solved elsewhere. Why does modifying
.../fcompiler/gnu.py affect compiling C modules with Intel C
compilers?

-- 
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 ulrik at 42degreesoffreedom.com  Sun Jun 15 06:34:05 2008
From: ulrik at 42degreesoffreedom.com (=?ISO-8859-1?Q?Ulrik_G=FCnther?=)
Date: Sun, 15 Jun 2008 12:34:05 +0200
Subject: [SciPy-dev] {Num, Sci}Py on 64bit Intel Macs with icc, ifort,
	mkl
In-Reply-To: <3d375d730806141531s7b01bf36m6b90422238e56309@mail.gmail.com>
References: <F6531E65-B5B2-4E59-92B9-CBF7E07C1FEE@42degreesoffreedom.com>
	<484FFD79.6030309@ar.media.kyoto-u.ac.jp>
	<253BDE06-5C61-4B6B-BBDD-31A4491A692C@42degreesoffreedom.com>
	<4850085D.6000600@ar.media.kyoto-u.ac.jp>
	<3d375d730806111242w15101a2w56184e916ffff4f@mail.gmail.com>
	<0032C278-D9BB-4133-9026-218C93665D71@42degreesoffreedom.com>
	<3d375d730806141531s7b01bf36m6b90422238e56309@mail.gmail.com>
Message-ID: <A855E714-8E37-4ED4-9B51-990452A605CE@42degreesoffreedom.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

On Jun 15, 2008, at 12:31 AM, Robert Kern wrote:
> It needs to be solved elsewhere. Why does modifying
> .../fcompiler/gnu.py affect compiling C modules with Intel C
> compilers?
You're of course right, that's what I forgot to write in my mail: The  
patch fixes the same problem I have with the Intel
compiler on my PPC notebook. There, the .so also don't get the - 
undefined dynamic_lookup flag. So is that patch okay
for this case? Sorry for being a bit off-topic in this case :/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFIVPAdy06DkvPH780RAgq+AJ4y8WBdMMMaUopIM48d6TZkV48ANgCgin5P
ZPkpi7tVZxpoM1d/9glXdYQ=
=4Vma
-----END PGP SIGNATURE-----


From robert.kern at gmail.com  Sun Jun 15 23:26:36 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Sun, 15 Jun 2008 22:26:36 -0500
Subject: [SciPy-dev] {Num, Sci}Py on 64bit Intel Macs with icc, ifort,
	mkl
In-Reply-To: <A855E714-8E37-4ED4-9B51-990452A605CE@42degreesoffreedom.com>
References: <F6531E65-B5B2-4E59-92B9-CBF7E07C1FEE@42degreesoffreedom.com>
	<484FFD79.6030309@ar.media.kyoto-u.ac.jp>
	<253BDE06-5C61-4B6B-BBDD-31A4491A692C@42degreesoffreedom.com>
	<4850085D.6000600@ar.media.kyoto-u.ac.jp>
	<3d375d730806111242w15101a2w56184e916ffff4f@mail.gmail.com>
	<0032C278-D9BB-4133-9026-218C93665D71@42degreesoffreedom.com>
	<3d375d730806141531s7b01bf36m6b90422238e56309@mail.gmail.com>
	<A855E714-8E37-4ED4-9B51-990452A605CE@42degreesoffreedom.com>
Message-ID: <3d375d730806152026p41b4daffv9b15da23c59886de@mail.gmail.com>

On Sun, Jun 15, 2008 at 05:34, Ulrik G?nther
<ulrik at 42degreesoffreedom.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> On Jun 15, 2008, at 12:31 AM, Robert Kern wrote:
>> It needs to be solved elsewhere. Why does modifying
>> .../fcompiler/gnu.py affect compiling C modules with Intel C
>> compilers?
> You're of course right, that's what I forgot to write in my mail: The
> patch fixes the same problem I have with the Intel
> compiler on my PPC notebook. There, the .so also don't get the -
> undefined dynamic_lookup flag. So is that patch okay
> for this case?

I don't know because you haven't described the problem at all.

 1. What package are you trying to compile that fails? Include the
version number or SVN revision.
 2. What part of that failed? Please copy-and-paste the build log
along with the command-line that started the build as well as the
contents of any setup.cfg or ~/.pydistutils.cfg files that you are
using.
 3. What version of numpy are you using?
 4. What (relevant) compilers are you using?
   a. What are their version numbers?
   b. Where did you get the compiler binaries from?
 5. Which version of OS X are you using?
 6. Which version of Python are you using?
   a. Where did you get the Python binary from? E.g. www.python.org,
Apple's builtin Python, MacPorts, Fink, built-it-yourself.

-- 
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 joel.schaerer at insa-lyon.fr  Mon Jun 16 10:47:27 2008
From: joel.schaerer at insa-lyon.fr (Joel Schaerer)
Date: Mon, 16 Jun 2008 14:47:27 +0000 (UTC)
Subject: [SciPy-dev] scipy.signal.convolve2d significantly slower than matlab
Message-ID: <loom.20080616T143804-199@post.gmane.org>

Hi all,

I've found that the 2D convolution code in scipy is significantly slower than
matlab's. The following code:

--------------------------------------------------------------------
#!/usr/bin/python

import scipy.io as io
import scipy.signal

aa=io.loadmat('input.mat')
seq=aa["seq"]

seq_f=[]

kernel=scipy.randn(21,21)
for k in xrange(seq.shape[2]):
    seq_f.append(scipy.signal.convolve2d(seq[:,:,k],kernel,'same'))
--------------------------------------------------------------------

Executes about 8 times slower than the following matlab code (executed with
matlab7 on 32bit linux):

--------------------------------------------------------------------
clear all
close all
clc

load input.mat

g=randn(21,21);

seq_f=zeros(size(seq));
for p=1:size(seq,3),
    seq_f(:,:,p)=conv2(seq(:,:,p),g,'same');
end
--------------------------------------------------------------------

I've traced the convolve code in scipy to the pylab_convolve2D function in
firfilter.c. It contains the nice following warning:

/* This could definitely be more optimized... */

...

Anyways, convolution is crucial for some applications, 
so I wanted to report this. I also tried to look for 
some good open source convolution code so that it
might be incorporated into scipy, but couldn't find any.
Would anyone know of one?

Totally unrelated question to the scipy devs: do you plan
 to add a hierarchical data structure such as kd-trees to
 scipy? With a nice API, it would be a great feature.





From ulrik at 42degreesoffreedom.com  Mon Jun 16 11:00:48 2008
From: ulrik at 42degreesoffreedom.com (=?ISO-8859-1?Q?Ulrik_G=FCnther?=)
Date: Mon, 16 Jun 2008 17:00:48 +0200
Subject: [SciPy-dev] {Num, Sci}Py on 64bit Intel Macs with icc, ifort,
	mkl
In-Reply-To: <3d375d730806152026p41b4daffv9b15da23c59886de@mail.gmail.com>
References: <F6531E65-B5B2-4E59-92B9-CBF7E07C1FEE@42degreesoffreedom.com>
	<484FFD79.6030309@ar.media.kyoto-u.ac.jp>
	<253BDE06-5C61-4B6B-BBDD-31A4491A692C@42degreesoffreedom.com>
	<4850085D.6000600@ar.media.kyoto-u.ac.jp>
	<3d375d730806111242w15101a2w56184e916ffff4f@mail.gmail.com>
	<0032C278-D9BB-4133-9026-218C93665D71@42degreesoffreedom.com>
	<3d375d730806141531s7b01bf36m6b90422238e56309@mail.gmail.com>
	<A855E714-8E37-4ED4-9B51-990452A605CE@42degreesoffreedom.com>
	<3d375d730806152026p41b4daffv9b15da23c59886de@mail.gmail.com>
Message-ID: <421B1FF2-5BBB-4230-AF0F-21F7BDAEEC0C@42degreesoffreedom.com>

Hi,

at first, the problem is mostly the same which I already described in  
combination with the
Intel compilers: For .so's, the -undefined dynamic_lookup flag is  
missing (which the patch
adds), therefore linking fails.

On Jun 16, 2008, at 5:26 AM, Robert Kern wrote:

> 1. What package are you trying to compile that fails? Include the
> version number or SVN revision.
The problem happends with every package that tries to build an .so,  
fftpack, etc.

> 2. What part of that failed? Please copy-and-paste the build log
The only thing that fails is the linking at the end, because the flag - 
undefined
dynamic_lookup is missing/Python.framework is not linked in. Do you  
still need the
build log?

> along with the command-line that started the build as well as the
> contents of any setup.cfg or ~/.pydistutils.cfg files that you are
> using.
The command line is the one recommended by http://www.scipy.org/Installing_SciPy/Mac_OS_X 
:
 >> python setup.py build_src build_clib --fcompiler=gnu95 build_ext -- 
fcompiler=gnu95 build
> 3. What version of numpy are you using?
% cd numpy && svn info | grep Rev
Revision: 5264
Last Changed Rev: 5264

% cd scipy && svn info | grep Rev
Revision: 4426
Last Changed Rev: 4426

> 4. What (relevant) compilers are you using?
>   a. What are their version numbers?

>   b. Where did you get the compiler binaries from?
GCC: gcc version 4.0.1 (Apple Inc. build 5465) (Apple-supplied)
GFortran: gcc version 4.2.1 (Apple Inc. build build 5531) (from  
macresearch.org)

> 5. Which version of OS X are you using?
10.5.3 along with current (stable, XCode 3.0) Developer tools.

> 6. Which version of Python are you using?
>   a. Where did you get the Python binary from? E.g. www.python.org,
> Apple's builtin Python, MacPorts, Fink, built-it-yourself.
I'm using...
% python
Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
...the Apple-supplied version, was last changed with 10.5.2, as far as  
I remember.

If you need anything else, please let me know :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080616/38f235b0/attachment.sig>

From robert.kern at gmail.com  Mon Jun 16 11:51:48 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 16 Jun 2008 10:51:48 -0500
Subject: [SciPy-dev] {Num, Sci}Py on 64bit Intel Macs with icc, ifort,
	mkl
In-Reply-To: <421B1FF2-5BBB-4230-AF0F-21F7BDAEEC0C@42degreesoffreedom.com>
References: <F6531E65-B5B2-4E59-92B9-CBF7E07C1FEE@42degreesoffreedom.com>
	<484FFD79.6030309@ar.media.kyoto-u.ac.jp>
	<253BDE06-5C61-4B6B-BBDD-31A4491A692C@42degreesoffreedom.com>
	<4850085D.6000600@ar.media.kyoto-u.ac.jp>
	<3d375d730806111242w15101a2w56184e916ffff4f@mail.gmail.com>
	<0032C278-D9BB-4133-9026-218C93665D71@42degreesoffreedom.com>
	<3d375d730806141531s7b01bf36m6b90422238e56309@mail.gmail.com>
	<A855E714-8E37-4ED4-9B51-990452A605CE@42degreesoffreedom.com>
	<3d375d730806152026p41b4daffv9b15da23c59886de@mail.gmail.com>
	<421B1FF2-5BBB-4230-AF0F-21F7BDAEEC0C@42degreesoffreedom.com>
Message-ID: <3d375d730806160851s76070221u21cc7baec600a2fc@mail.gmail.com>

On Mon, Jun 16, 2008 at 10:00, Ulrik G?nther
<ulrik at 42degreesoffreedom.com> wrote:
> Hi,
>
> at first, the problem is mostly the same which I already described in
> combination with the
> Intel compilers: For .so's, the -undefined dynamic_lookup flag is missing
> (which the patch
> adds), therefore linking fails.
>
> On Jun 16, 2008, at 5:26 AM, Robert Kern wrote:
>
>> 1. What package are you trying to compile that fails? Include the
>> version number or SVN revision.
>
> The problem happends with every package that tries to build an .so, fftpack,
> etc.

*Every* package? Even non-numpy or non-FORTRAN ones which patching
gnu.py can't affect?

Do you perchance have the environment variable LDFLAGS set somewhere?

>> 2. What part of that failed? Please copy-and-paste the build log
>
> The only thing that fails is the linking at the end, because the flag
> -undefined
> dynamic_lookup is missing/Python.framework is not linked in. Do you still
> need the
> build log?

Yes. Note that "-framework Python" is *not* supposed to be there.
"-undefined dynamic_lookup" takes care of that.

-- 
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 ulrik at 42degreesoffreedom.com  Mon Jun 16 11:55:50 2008
From: ulrik at 42degreesoffreedom.com (=?ISO-8859-1?Q?Ulrik_G=FCnther?=)
Date: Mon, 16 Jun 2008 17:55:50 +0200
Subject: [SciPy-dev] {Num, Sci}Py on 64bit Intel Macs with icc, ifort,
	mkl
In-Reply-To: <3d375d730806160851s76070221u21cc7baec600a2fc@mail.gmail.com>
References: <F6531E65-B5B2-4E59-92B9-CBF7E07C1FEE@42degreesoffreedom.com>
	<484FFD79.6030309@ar.media.kyoto-u.ac.jp>
	<253BDE06-5C61-4B6B-BBDD-31A4491A692C@42degreesoffreedom.com>
	<4850085D.6000600@ar.media.kyoto-u.ac.jp>
	<3d375d730806111242w15101a2w56184e916ffff4f@mail.gmail.com>
	<0032C278-D9BB-4133-9026-218C93665D71@42degreesoffreedom.com>
	<3d375d730806141531s7b01bf36m6b90422238e56309@mail.gmail.com>
	<A855E714-8E37-4ED4-9B51-990452A605CE@42degreesoffreedom.com>
	<3d375d730806152026p41b4daffv9b15da23c59886de@mail.gmail.com>
	<421B1FF2-5BBB-4230-AF0F-21F7BDAEEC0C@42degreesoffreedom.com>
	<3d375d730806160851s76070221u21cc7baec600a2fc@mail.gmail.com>
Message-ID: <1DFB4D6C-5DFD-4536-86A8-76C39F001129@42degreesoffreedom.com>


On Jun 16, 2008, at 5:51 PM, Robert Kern wrote:

> *Every* package? Even non-numpy or non-FORTRAN ones which patching
> gnu.py can't affect?
With 'every package' I meant every package which is affected by this,  
so: every Fortran-related
package.

> Do you perchance have the environment variable LDFLAGS set somewhere?
LDFLAGS just contains some additional library directories.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080616/b2618e23/attachment.sig>

From david at ar.media.kyoto-u.ac.jp  Mon Jun 16 12:00:11 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Tue, 17 Jun 2008 01:00:11 +0900
Subject: [SciPy-dev] {Num, Sci}Py on 64bit Intel Macs with icc, ifort,
 mkl
In-Reply-To: <1DFB4D6C-5DFD-4536-86A8-76C39F001129@42degreesoffreedom.com>
References: <F6531E65-B5B2-4E59-92B9-CBF7E07C1FEE@42degreesoffreedom.com>	<484FFD79.6030309@ar.media.kyoto-u.ac.jp>	<253BDE06-5C61-4B6B-BBDD-31A4491A692C@42degreesoffreedom.com>	<4850085D.6000600@ar.media.kyoto-u.ac.jp>	<3d375d730806111242w15101a2w56184e916ffff4f@mail.gmail.com>	<0032C278-D9BB-4133-9026-218C93665D71@42degreesoffreedom.com>	<3d375d730806141531s7b01bf36m6b90422238e56309@mail.gmail.com>	<A855E714-8E37-4ED4-9B51-990452A605CE@42degreesoffreedom.com>	<3d375d730806152026p41b4daffv9b15da23c59886de@mail.gmail.com>	<421B1FF2-5BBB-4230-AF0F-21F7BDAEEC0C@42degreesoffreedom.com>	<3d375d730806160851s76070221u21cc7baec600a2fc@mail.gmail.com>
	<1DFB4D6C-5DFD-4536-86A8-76C39F001129@42degreesoffreedom.com>
Message-ID: <48568E0B.5080601@ar.media.kyoto-u.ac.jp>

Ulrik G?nther wrote:
> LDFLAGS just contains some additional library directories.

Yes, but it breaks distutils : it does not do what you think it does 
(unfortunately). LDFLAGS *overwrites* the flags used by distutils, and 
are not prepended.

cheers,

David


From ulrik at 42degreesoffreedom.com  Mon Jun 16 13:32:44 2008
From: ulrik at 42degreesoffreedom.com (=?ISO-8859-1?Q?Ulrik_G=FCnther?=)
Date: Mon, 16 Jun 2008 19:32:44 +0200
Subject: [SciPy-dev] {Num, Sci}Py on 64bit Intel Macs with icc, ifort,
	mkl
In-Reply-To: <48568E0B.5080601@ar.media.kyoto-u.ac.jp>
References: <F6531E65-B5B2-4E59-92B9-CBF7E07C1FEE@42degreesoffreedom.com>	<484FFD79.6030309@ar.media.kyoto-u.ac.jp>	<253BDE06-5C61-4B6B-BBDD-31A4491A692C@42degreesoffreedom.com>	<4850085D.6000600@ar.media.kyoto-u.ac.jp>	<3d375d730806111242w15101a2w56184e916ffff4f@mail.gmail.com>	<0032C278-D9BB-4133-9026-218C93665D71@42degreesoffreedom.com>	<3d375d730806141531s7b01bf36m6b90422238e56309@mail.gmail.com>	<A855E714-8E37-4ED4-9B51-990452A605CE@42degreesoffreedom.com>	<3d375d730806152026p41b4daffv9b15da23c59886de@mail.gmail.com>	<421B1FF2-5BBB-4230-AF0F-21F7BDAEEC0C@42degreesoffreedom.com>	<3d375d730806160851s76070221u21cc7baec600a2fc@mail.gmail.com>
	<1DFB4D6C-5DFD-4536-86A8-76C39F001129@42degreesoffreedom.com>
	<48568E0B.5080601@ar.media.kyoto-u.ac.jp>
Message-ID: <C0BB97DA-E74A-4DCD-BC8D-86519DBB24D4@42degreesoffreedom.com>


On Jun 16, 2008, at 6:00 PM, David Cournapeau wrote:

> Yes, but it breaks distutils : it does not do what you think it does
> (unfortunately). LDFLAGS *overwrites* the flags used by distutils, and
> are not prepended.
Okay, it's interesting to hear that. I think I've read that nowhere,  
is this behaviour documented anywhere?
I just have these params in my zshrc, as I find myself often compiling  
*nix sourcecode. I'll try without.

Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080616/b1b941ed/attachment.sig>

From pgmdevlist at gmail.com  Mon Jun 16 13:51:48 2008
From: pgmdevlist at gmail.com (Pierre GM)
Date: Mon, 16 Jun 2008 13:51:48 -0400
Subject: [SciPy-dev] Documenting classes
Message-ID: <200806161351.48729.pgmdevlist@gmail.com>

All,
Is there some kind of official template for the documentation of numpy-related 
classes ? In particular, what is the syntax for documenting special 
attributes/properties ?
Thanks a lot in advance
P.


From robert.kern at gmail.com  Mon Jun 16 15:18:31 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 16 Jun 2008 14:18:31 -0500
Subject: [SciPy-dev] Documenting classes
In-Reply-To: <200806161351.48729.pgmdevlist@gmail.com>
References: <200806161351.48729.pgmdevlist@gmail.com>
Message-ID: <3d375d730806161218p10981d01tbb3c380b112f0ed5@mail.gmail.com>

On Mon, Jun 16, 2008 at 12:51, Pierre GM <pgmdevlist at gmail.com> wrote:
> All,
> Is there some kind of official template for the documentation of numpy-related
> classes ?

Not per se, but most of the general outline of the function template
applies. Ignore Returns. I think I like having the __init__
constructor Parameters in the class docstring, but I will defer to
St?fan's proclamation.

> In particular, what is the syntax for documenting special
> attributes/properties ?

I recommend adding a section like Parameters.

  Attributes
  ----------
  x : float
      The X coordinate.
  y : float
      The Y coordinate.

-- 
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 pearu at cens.ioc.ee  Mon Jun 16 15:27:19 2008
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Mon, 16 Jun 2008 22:27:19 +0300 (EEST)
Subject: [SciPy-dev] Documenting classes
In-Reply-To: <3d375d730806161218p10981d01tbb3c380b112f0ed5@mail.gmail.com>
References: <200806161351.48729.pgmdevlist@gmail.com>
	<3d375d730806161218p10981d01tbb3c380b112f0ed5@mail.gmail.com>
Message-ID: <64275.85.164.145.1.1213644439.squirrel@cens.ioc.ee>


Hi,

There is a numpy ticket for a similar issue:

  http://projects.scipy.org/scipy/numpy/ticket/795

Pearu

On Mon, June 16, 2008 10:18 pm, Robert Kern wrote:
> On Mon, Jun 16, 2008 at 12:51, Pierre GM <pgmdevlist at gmail.com> wrote:
>> All,
>> Is there some kind of official template for the documentation of
>> numpy-related
>> classes ?
>
> Not per se, but most of the general outline of the function template
> applies. Ignore Returns. I think I like having the __init__
> constructor Parameters in the class docstring, but I will defer to
> St??fan's proclamation.
>
>> In particular, what is the syntax for documenting special
>> attributes/properties ?
>
> I recommend adding a section like Parameters.
>
>   Attributes
>   ----------
>   x : float
>       The X coordinate.
>   y : float
>       The Y coordinate.
>
> --
> 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
>




From twaite at berkeley.edu  Mon Jun 16 18:40:43 2008
From: twaite at berkeley.edu (Tom Waite)
Date: Mon, 16 Jun 2008 15:40:43 -0700
Subject: [SciPy-dev] scipy.signal.convolve2d significantly slower than
	matlab
In-Reply-To: <loom.20080616T143804-199@post.gmane.org>
References: <loom.20080616T143804-199@post.gmane.org>
Message-ID: <fe702a7c0806161540w2ca23b79l2ffce268380eb75a@mail.gmail.com>

Do you require the filter kernel to be non-separable for your application?


On Mon, Jun 16, 2008 at 7:47 AM, Joel Schaerer <joel.schaerer at insa-lyon.fr>
wrote:

> Hi all,
>
> I've found that the 2D convolution code in scipy is significantly slower
> than
> matlab's. The following code:
>
> --------------------------------------------------------------------
> #!/usr/bin/python
>
> import scipy.io as io
> import scipy.signal
>
> aa=io.loadmat('input.mat')
> seq=aa["seq"]
>
> seq_f=[]
>
> kernel=scipy.randn(21,21)
> for k in xrange(seq.shape[2]):
>    seq_f.append(scipy.signal.convolve2d(seq[:,:,k],kernel,'same'))
> --------------------------------------------------------------------
>
> Executes about 8 times slower than the following matlab code (executed with
> matlab7 on 32bit linux):
>
> --------------------------------------------------------------------
> clear all
> close all
> clc
>
> load input.mat
>
> g=randn(21,21);
>
> seq_f=zeros(size(seq));
> for p=1:size(seq,3),
>    seq_f(:,:,p)=conv2(seq(:,:,p),g,'same');
> end
> --------------------------------------------------------------------
>
> I've traced the convolve code in scipy to the pylab_convolve2D function in
> firfilter.c. It contains the nice following warning:
>
> /* This could definitely be more optimized... */
>
> ...
>
> Anyways, convolution is crucial for some applications,
> so I wanted to report this. I also tried to look for
> some good open source convolution code so that it
> might be incorporated into scipy, but couldn't find any.
> Would anyone know of one?
>
> Totally unrelated question to the scipy devs: do you plan
>  to add a hierarchical data structure such as kd-trees to
>  scipy? With a nice API, it would be a great feature.
>
>
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080616/aaf0a2d9/attachment.html>

From strawman at astraw.com  Mon Jun 16 20:45:58 2008
From: strawman at astraw.com (Andrew Straw)
Date: Mon, 16 Jun 2008 17:45:58 -0700
Subject: [SciPy-dev] request permission to edit scipy documentation
Message-ID: <48570946.8070102@astraw.com>

Hi,

I'd like to edit the scipy documentation at
http://sd-2116.dedibox.fr/pydocweb/ . My username is AndrewStraw. Please
give me permission.

Thanks,
Andrew


From strawman at astraw.com  Mon Jun 16 20:48:55 2008
From: strawman at astraw.com (Andrew Straw)
Date: Mon, 16 Jun 2008 17:48:55 -0700
Subject: [SciPy-dev] numpy doc wiki question -- where is numpy.ma?
Message-ID: <485709F7.9040903@astraw.com>

Sorry if I'm missing something, but where are the docstrings for
numpy.ma at the scipy documentation editor? I don't see any reference to
them at
http://sd-2116.dedibox.fr/pydocweb/doc/numpy/

Thanks,
Andrew


From wnbell at gmail.com  Mon Jun 16 20:49:10 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Mon, 16 Jun 2008 19:49:10 -0500
Subject: [SciPy-dev] request permission to edit scipy documentation
In-Reply-To: <48570946.8070102@astraw.com>
References: <48570946.8070102@astraw.com>
Message-ID: <d05265cb0806161749m139ca71aie75e3110edb7c770@mail.gmail.com>

On Mon, Jun 16, 2008 at 7:45 PM, Andrew Straw <strawman at astraw.com> wrote:
> Hi,
>
> I'd like to edit the scipy documentation at
> http://sd-2116.dedibox.fr/pydocweb/ . My username is AndrewStraw. Please
> give me permission.
>

Please give permission to "wnbell" as well.  Thanks


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


From pgmdevlist at gmail.com  Mon Jun 16 21:15:43 2008
From: pgmdevlist at gmail.com (Pierre GM)
Date: Mon, 16 Jun 2008 21:15:43 -0400
Subject: [SciPy-dev] numpy doc wiki question -- where is numpy.ma?
In-Reply-To: <485709F7.9040903@astraw.com>
References: <485709F7.9040903@astraw.com>
Message-ID: <200806162115.44075.pgmdevlist@gmail.com>

On Monday 16 June 2008 20:48:55 Andrew Straw wrote:
> Sorry if I'm missing something, but where are the docstrings for
> numpy.ma at the scipy documentation editor?

I'm afraid there aren't any yet. Guess I should register as well: could 
anybody register me as PierreGM ? Thx in advance.


From pgmdevlist at gmail.com  Mon Jun 16 21:18:17 2008
From: pgmdevlist at gmail.com (Pierre GM)
Date: Mon, 16 Jun 2008 21:18:17 -0400
Subject: [SciPy-dev] Scikits version system
Message-ID: <200806162118.17953.pgmdevlist@gmail.com>

Folks, 
I'm trying to add some version number to our package (timeseries), following 
the example in http://scipy.org/scipy/scikits/wiki/ScikitsForDevelopers
However, something must be going wrong, as the only __version__ number I get 
is 0.5, no matter the version number I try to set.
Could anybody help me ? This is really becoming frustrating by the hour.
Thanks a lot in advance
P.


From robert.kern at gmail.com  Mon Jun 16 21:31:44 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 16 Jun 2008 20:31:44 -0500
Subject: [SciPy-dev] Scikits version system
In-Reply-To: <200806162118.17953.pgmdevlist@gmail.com>
References: <200806162118.17953.pgmdevlist@gmail.com>
Message-ID: <3d375d730806161831r12c77348x708b9a21d67da277@mail.gmail.com>

On Mon, Jun 16, 2008 at 20:18, Pierre GM <pgmdevlist at gmail.com> wrote:
> Folks,
> I'm trying to add some version number to our package (timeseries), following
> the example in http://scipy.org/scipy/scikits/wiki/ScikitsForDevelopers
> However, something must be going wrong, as the only __version__ number I get
> is 0.5, no matter the version number I try to set.

Do you have an old egg or .egg-info directory lying around?

-- 
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 robert.kern at gmail.com  Mon Jun 16 21:40:44 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 16 Jun 2008 20:40:44 -0500
Subject: [SciPy-dev] Scikits version system
In-Reply-To: <200806162118.17953.pgmdevlist@gmail.com>
References: <200806162118.17953.pgmdevlist@gmail.com>
Message-ID: <3d375d730806161840i68b41e2er863d3062031830d8@mail.gmail.com>

On Mon, Jun 16, 2008 at 20:18, Pierre GM <pgmdevlist at gmail.com> wrote:
> Folks,
> I'm trying to add some version number to our package (timeseries), following
> the example in http://scipy.org/scipy/scikits/wiki/ScikitsForDevelopers
> However, something must be going wrong, as the only __version__ number I get
> is 0.5, no matter the version number I try to set.

Well, the current trunk doesn't build into an egg for me: you have
tag_svn_revision set to an invalid value in setup.cfg. You also have
the name of the package wrong in the setup() call, so it makes and egg
called "timeseries" rather than "scikits.timeseries" which is what it
should be. Fixing these, and uncommenting out the implementation of
the scheme described on the wiki works for me.

Attached is the patch against SVN trunk.

In doing this, I found a few places where there are mixed line
endings. Please take a look at normalizing these. Also please go
through the commented-out blocks of obsolete code and delete any of it
that you can. SVN remembers so the file doesn't have to.

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scikits.timeseries-version.patch
Type: application/octet-stream
Size: 1679 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080616/38de1b11/attachment.obj>

From pgmdevlist at gmail.com  Mon Jun 16 22:46:27 2008
From: pgmdevlist at gmail.com (Pierre GM)
Date: Mon, 16 Jun 2008 22:46:27 -0400
Subject: [SciPy-dev] Scikits version system
In-Reply-To: <3d375d730806161840i68b41e2er863d3062031830d8@mail.gmail.com>
References: <200806162118.17953.pgmdevlist@gmail.com>
	<3d375d730806161840i68b41e2er863d3062031830d8@mail.gmail.com>
Message-ID: <200806162246.28100.pgmdevlist@gmail.com>

Robert, 
First of all, thanks an awful lot again for your help.

On Monday 16 June 2008 21:40:44 Robert Kern wrote:
> Well, the current trunk doesn't build into an egg for me: you have
> tag_svn_revision set to an invalid value in setup.cfg. You also have
> the name of the package wrong in the setup() call, so it makes and egg
> called "timeseries" rather than "scikits.timeseries" which is what it
> should be. Fixing these, and uncommenting out the implementation of
> the scheme described on the wiki works for me.

I had figured that the 1 was in fact a truth value, but thanks for pointing 
out the error in the base setup.py.

> In doing this, I found a few places where there are mixed line
> endings. Please take a look at normalizing these. 

Mmh, I'm not sure what you mean about the line endings...

> Also please go 
> through the commented-out blocks of obsolete code and delete any of it
> that you can. SVN remembers so the file doesn't have to.

You're quite right, sorry about that.
After getting rid of rotten eggs and performing a clean install, I get the 
proper results, at last. 
Thanks again !


From robert.kern at gmail.com  Mon Jun 16 23:20:03 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 16 Jun 2008 22:20:03 -0500
Subject: [SciPy-dev] Scikits version system
In-Reply-To: <200806162246.28100.pgmdevlist@gmail.com>
References: <200806162118.17953.pgmdevlist@gmail.com>
	<3d375d730806161840i68b41e2er863d3062031830d8@mail.gmail.com>
	<200806162246.28100.pgmdevlist@gmail.com>
Message-ID: <3d375d730806162020j2ac13a0gae38b27c2830c849@mail.gmail.com>

On Mon, Jun 16, 2008 at 21:46, Pierre GM <pgmdevlist at gmail.com> wrote:
> On Monday 16 June 2008 21:40:44 Robert Kern wrote:
>> In doing this, I found a few places where there are mixed line
>> endings. Please take a look at normalizing these.
>
> Mmh, I'm not sure what you mean about the line endings...

For example, scikits/timeseries/__init__.py. The non-empty lines end
in \r\n; the blank lines end in \n.

-- 
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 pgmdevlist at gmail.com  Mon Jun 16 23:16:31 2008
From: pgmdevlist at gmail.com (Pierre GM)
Date: Mon, 16 Jun 2008 23:16:31 -0400
Subject: [SciPy-dev] Scikits version system
In-Reply-To: <3d375d730806162020j2ac13a0gae38b27c2830c849@mail.gmail.com>
References: <200806162118.17953.pgmdevlist@gmail.com>
	<200806162246.28100.pgmdevlist@gmail.com>
	<3d375d730806162020j2ac13a0gae38b27c2830c849@mail.gmail.com>
Message-ID: <200806162316.31715.pgmdevlist@gmail.com>

On Monday 16 June 2008 23:20:03 Robert Kern wrote:
> On Mon, Jun 16, 2008 at 21:46, Pierre GM <pgmdevlist at gmail.com> wrote:
> > On Monday 16 June 2008 21:40:44 Robert Kern wrote:
> >> In doing this, I found a few places where there are mixed line
> >> endings. Please take a look at normalizing these.
> >
> > Mmh, I'm not sure what you mean about the line endings...
>
> For example, scikits/timeseries/__init__.py. The non-empty lines end
> in \r\n; the blank lines end in \n.

Ah OK, indeed. Guess we'll have to decide of a format with Matt.
Thanks again.


From david at ar.media.kyoto-u.ac.jp  Tue Jun 17 02:06:25 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Tue, 17 Jun 2008 15:06:25 +0900
Subject: [SciPy-dev] {Num, Sci}Py on 64bit Intel Macs with icc, ifort,
 mkl
In-Reply-To: <C0BB97DA-E74A-4DCD-BC8D-86519DBB24D4@42degreesoffreedom.com>
References: <F6531E65-B5B2-4E59-92B9-CBF7E07C1FEE@42degreesoffreedom.com>	<484FFD79.6030309@ar.media.kyoto-u.ac.jp>	<253BDE06-5C61-4B6B-BBDD-31A4491A692C@42degreesoffreedom.com>	<4850085D.6000600@ar.media.kyoto-u.ac.jp>	<3d375d730806111242w15101a2w56184e916ffff4f@mail.gmail.com>	<0032C278-D9BB-4133-9026-218C93665D71@42degreesoffreedom.com>	<3d375d730806141531s7b01bf36m6b90422238e56309@mail.gmail.com>	<A855E714-8E37-4ED4-9B51-990452A605CE@42degreesoffreedom.com>	<3d375d730806152026p41b4daffv9b15da23c59886de@mail.gmail.com>	<421B1FF2-5BBB-4230-AF0F-21F7BDAEEC0C@42degreesoffreedom.com>	<3d375d730806160851s76070221u21cc7baec600a2fc@mail.gmail.com>	<1DFB4D6C-5DFD-4536-86A8-76C39F001129@42degreesoffreedom.com>	<48568E0B.5080601@ar.media.kyoto-u.ac.jp>
	<C0BB97DA-E74A-4DCD-BC8D-86519DBB24D4@42degreesoffreedom.com>
Message-ID: <48575461.8000602@ar.media.kyoto-u.ac.jp>

Ulrik G?nther wrote:
> Okay, it's interesting to hear that. I think I've read that nowhere, 
> is this behaviour documented anywhere?

Not that I am aware of. Note that if you try it out, numscons does not 
have this behavior (I try to be more compatible to autotools convention 
here; the overriding option will be handled by a different flag).

cheers,

David


From stefan at sun.ac.za  Tue Jun 17 05:27:39 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 17 Jun 2008 11:27:39 +0200
Subject: [SciPy-dev] scipy.signal.convolve2d significantly slower than
	matlab
In-Reply-To: <loom.20080616T143804-199@post.gmane.org>
References: <loom.20080616T143804-199@post.gmane.org>
Message-ID: <9457e7c80806170227v5486fbdwf91f2bb8dc579337@mail.gmail.com>

Hi Joel

2008/6/16 Joel Schaerer <joel.schaerer at insa-lyon.fr>:
> I've found that the 2D convolution code in scipy is significantly slower than
> matlab's. The following code:

Also take a look at fftconvolve.

Regards
St?fan


From stefan at sun.ac.za  Tue Jun 17 09:10:50 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 17 Jun 2008 15:10:50 +0200
Subject: [SciPy-dev] Documenting classes
In-Reply-To: <3d375d730806161218p10981d01tbb3c380b112f0ed5@mail.gmail.com>
References: <200806161351.48729.pgmdevlist@gmail.com>
	<3d375d730806161218p10981d01tbb3c380b112f0ed5@mail.gmail.com>
Message-ID: <9457e7c80806170610q77182843v9feb579fbb3bba4a@mail.gmail.com>

2008/6/16 Robert Kern <robert.kern at gmail.com>:
> Not per se, but most of the general outline of the function template
> applies. Ignore Returns. I think I like having the __init__
> constructor Parameters in the class docstring, but I will defer to
> St?fan's proclamation.

I do, too.  `__init__` is exposed to users as ClassName(), so that is
where they will look for the docstring.   We are not bound religiously
to PEP-257, which suggests:

"""
The class constructor should be documented in the docstring for its
__init__ method. Individual methods should be documented by their own
docstring.
"""

> I recommend adding a section like Parameters.
>
>  Attributes
>  ----------
>  x : float
>      The X coordinate.
>  y : float
>      The Y coordinate.

Let's do that.  Unfortunately, Python does not pick up docstrings of the form:

"""My variable description."""
my_var = 3

so we'll have to go with an Attributes section.  On the other hand,
methods can be inspected (i.e. TAB-completion in IPython, 'help' or
'dir' in the raw shell), so we don't need to list the methods, as
suggested in the PEP:

"The docstring for a class should summarize its behavior and list the
public methods and instance variables."

I have updated the documentation guidelines:

http://projects.scipy.org/scipy/numpy/wiki/CodingStyleGuidelines#documenting-classes

Cheers
St?fan


From twaite at berkeley.edu  Tue Jun 17 10:53:42 2008
From: twaite at berkeley.edu (Tom Waite)
Date: Tue, 17 Jun 2008 07:53:42 -0700
Subject: [SciPy-dev] scipy.signal.convolve2d significantly slower than
	matlab
In-Reply-To: <9457e7c80806170227v5486fbdwf91f2bb8dc579337@mail.gmail.com>
References: <loom.20080616T143804-199@post.gmane.org>
	<9457e7c80806170227v5486fbdwf91f2bb8dc579337@mail.gmail.com>
Message-ID: <fe702a7c0806170753w39dbc8cfydce1e57a65be7d70@mail.gmail.com>

In addition to fftconvole, if the filter kernel is separable (Gaussian,
Sinc, difference-of-sinc), you can use the scipy.ndimage correlate1d.
Correlate1D is very fast and checks for kernel symmetry so can reduce the
number of mults. In your application script you are building a stack of
filtered images. I wrote a registration package in ndimage that has a 3D
separable filter for volume filtering prior to registration. I am about to
check in changes to the code that will include a test that shows how to get
both 3D and a stack of 2D filtered slices (which is an intermediate result
of the 3D). I typically do 3D filtering of 256x256x90 volumes and it is
under 1 second. I agree the convole2D needs to be improved for speed.

On Tue, Jun 17, 2008 at 2:27 AM, St?fan van der Walt <stefan at sun.ac.za>
wrote:

> Hi Joel
>
> 2008/6/16 Joel Schaerer <joel.schaerer at insa-lyon.fr>:
> > I've found that the 2D convolution code in scipy is significantly slower
> than
> > matlab's. The following code:
>
> Also take a look at fftconvolve.
>
> Regards
> St?fan
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080617/eaa3e8a5/attachment.html>

From robert.kern at gmail.com  Tue Jun 17 14:22:11 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 17 Jun 2008 13:22:11 -0500
Subject: [SciPy-dev] Documenting classes
In-Reply-To: <9457e7c80806170610q77182843v9feb579fbb3bba4a@mail.gmail.com>
References: <200806161351.48729.pgmdevlist@gmail.com>
	<3d375d730806161218p10981d01tbb3c380b112f0ed5@mail.gmail.com>
	<9457e7c80806170610q77182843v9feb579fbb3bba4a@mail.gmail.com>
Message-ID: <3d375d730806171122r79c13f36t1ef2a586572fa0e4@mail.gmail.com>

On Tue, Jun 17, 2008 at 08:10, St?fan van der Walt <stefan at sun.ac.za> wrote:
> On the other hand,
> methods can be inspected (i.e. TAB-completion in IPython, 'help' or
> 'dir' in the raw shell), so we don't need to list the methods, as
> suggested in the PEP:
>
> "The docstring for a class should summarize its behavior and list the
> public methods and instance variables."

That said, it can be difficult to pick out which methods are public
and important, and which aren't.

-- 
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 stefan at sun.ac.za  Tue Jun 17 15:59:55 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 17 Jun 2008 21:59:55 +0200
Subject: [SciPy-dev] Documenting classes
In-Reply-To: <3d375d730806171122r79c13f36t1ef2a586572fa0e4@mail.gmail.com>
References: <200806161351.48729.pgmdevlist@gmail.com>
	<3d375d730806161218p10981d01tbb3c380b112f0ed5@mail.gmail.com>
	<9457e7c80806170610q77182843v9feb579fbb3bba4a@mail.gmail.com>
	<3d375d730806171122r79c13f36t1ef2a586572fa0e4@mail.gmail.com>
Message-ID: <9457e7c80806171259r2577ec5dse63827f767d228d7@mail.gmail.com>

2008/6/17 Robert Kern <robert.kern at gmail.com>:
> On Tue, Jun 17, 2008 at 08:10, St?fan van der Walt <stefan at sun.ac.za> wrote:
>> On the other hand,
>> methods can be inspected (i.e. TAB-completion in IPython, 'help' or
>> 'dir' in the raw shell), so we don't need to list the methods, as
>> suggested in the PEP:
>>
>> "The docstring for a class should summarize its behavior and list the
>> public methods and instance variables."
>
> That said, it can be difficult to pick out which methods are public
> and important, and which aren't.

Maybe it's a good idea to make this implicit in the naming: start the
function name with an underscore if it is not part of the public API.

Regards
St?fan


From robert.kern at gmail.com  Tue Jun 17 16:59:38 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 17 Jun 2008 15:59:38 -0500
Subject: [SciPy-dev] Documenting classes
In-Reply-To: <9457e7c80806171259r2577ec5dse63827f767d228d7@mail.gmail.com>
References: <200806161351.48729.pgmdevlist@gmail.com>
	<3d375d730806161218p10981d01tbb3c380b112f0ed5@mail.gmail.com>
	<9457e7c80806170610q77182843v9feb579fbb3bba4a@mail.gmail.com>
	<3d375d730806171122r79c13f36t1ef2a586572fa0e4@mail.gmail.com>
	<9457e7c80806171259r2577ec5dse63827f767d228d7@mail.gmail.com>
Message-ID: <3d375d730806171359k78676ce3sd2435e496af0d531@mail.gmail.com>

On Tue, Jun 17, 2008 at 14:59, St?fan van der Walt <stefan at sun.ac.za> wrote:
> 2008/6/17 Robert Kern <robert.kern at gmail.com>:
>> On Tue, Jun 17, 2008 at 08:10, St?fan van der Walt <stefan at sun.ac.za> wrote:
>>> On the other hand,
>>> methods can be inspected (i.e. TAB-completion in IPython, 'help' or
>>> 'dir' in the raw shell), so we don't need to list the methods, as
>>> suggested in the PEP:
>>>
>>> "The docstring for a class should summarize its behavior and list the
>>> public methods and instance variables."
>>
>> That said, it can be difficult to pick out which methods are public
>> and important, and which aren't.
>
> Maybe it's a good idea to make this implicit in the naming: start the
> function name with an underscore if it is not part of the public API.

Even then, there is a difference between a public API and the
interesting subset. For example, memmap subclasses ndarray. The
interesting additional method is flush() which should be mentioned in
the docstring because a user would never discover it without reading
the source.

-- 
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 stefan at sun.ac.za  Tue Jun 17 17:36:06 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 17 Jun 2008 23:36:06 +0200
Subject: [SciPy-dev] Documenting classes
In-Reply-To: <3d375d730806171359k78676ce3sd2435e496af0d531@mail.gmail.com>
References: <200806161351.48729.pgmdevlist@gmail.com>
	<3d375d730806161218p10981d01tbb3c380b112f0ed5@mail.gmail.com>
	<9457e7c80806170610q77182843v9feb579fbb3bba4a@mail.gmail.com>
	<3d375d730806171122r79c13f36t1ef2a586572fa0e4@mail.gmail.com>
	<9457e7c80806171259r2577ec5dse63827f767d228d7@mail.gmail.com>
	<3d375d730806171359k78676ce3sd2435e496af0d531@mail.gmail.com>
Message-ID: <9457e7c80806171436o31a5a87ct2bf4da3c2999340b@mail.gmail.com>

2008/6/17 Robert Kern <robert.kern at gmail.com>:
>> Maybe it's a good idea to make this implicit in the naming: start the
>> function name with an underscore if it is not part of the public API.
>
> Even then, there is a difference between a public API and the
> interesting subset. For example, memmap subclasses ndarray. The
> interesting additional method is flush() which should be mentioned in
> the docstring because a user would never discover it without reading
> the source.

That is a very good point;  I'll add a Methods section.  I don't think
we'll need it too frequently, but it is good to cover all bases.

Regards
St?fan


From pav at iki.fi  Wed Jun 18 14:19:22 2008
From: pav at iki.fi (Pauli Virtanen)
Date: Wed, 18 Jun 2008 18:19:22 +0000 (UTC)
Subject: [SciPy-dev] numpy doc wiki question -- where is numpy.ma?
References: <485709F7.9040903@astraw.com>
Message-ID: <g3bjja$9ir$1@ger.gmane.org>

Hi,

Mon, 16 Jun 2008 17:48:55 -0700, Andrew Straw wrote:
> Sorry if I'm missing something, but where are the docstrings for
> numpy.ma at the scipy documentation editor? I don't see any reference to
> them at
> http://sd-2116.dedibox.fr/pydocweb/doc/numpy/

It's here:

    http://sd-2116.dedibox.fr/pydocweb/doc/numpy.ma/

It's was hidden from the numpy page, as numpy.ma is not in numpy.__all__. 
(Right now I'm not sure whether this is sensible behavior...)

-- 
Pauli Virtanen



From strawman at astraw.com  Wed Jun 18 15:11:22 2008
From: strawman at astraw.com (Andrew Straw)
Date: Wed, 18 Jun 2008 12:11:22 -0700
Subject: [SciPy-dev] numpy doc wiki question -- where is numpy.ma?
In-Reply-To: <g3bjja$9ir$1@ger.gmane.org>
References: <485709F7.9040903@astraw.com> <g3bjja$9ir$1@ger.gmane.org>
Message-ID: <48595DDA.3000702@astraw.com>

Pauli Virtanen wrote:
> Hi,
>
> Mon, 16 Jun 2008 17:48:55 -0700, Andrew Straw wrote:
>   
>> Sorry if I'm missing something, but where are the docstrings for
>> numpy.ma at the scipy documentation editor? I don't see any reference to
>> them at
>> http://sd-2116.dedibox.fr/pydocweb/doc/numpy/
>>     
>
> It's here:
>
>     http://sd-2116.dedibox.fr/pydocweb/doc/numpy.ma/
>
> It's was hidden from the numpy page, as numpy.ma is not in numpy.__all__. 
> (Right now I'm not sure whether this is sensible behavior...)
>
>   

Well, I don't have an opinion about whether it should be in __all__ (I
never use from numpy import *), but it is certainly an "available
subpackage" of numpy, so it should at least go in the list on that page.
Since that page is a view of the top-level docstring for numpy, I think
this is all the more important. Are there other subpackages in this
netherworld?

-Andrew


From wnbell at gmail.com  Thu Jun 19 20:25:34 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Thu, 19 Jun 2008 19:25:34 -0500
Subject: [SciPy-dev] 0.7 release schedule
Message-ID: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>

Is there a plan to get SciPy 0.7 out the door?  Numerous improvements
have been made since the release of 0.6, which was 9 months ago.
Whatever the faults of the current SVN (e.g. unittest that have been
broken for over a month), are they not now preferable to those in 0.6?

A release now would be helpful to those who want to use SciPy in the
classroom this fall.

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


From david at ar.media.kyoto-u.ac.jp  Thu Jun 19 23:15:03 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Fri, 20 Jun 2008 12:15:03 +0900
Subject: [SciPy-dev] 0.7 release schedule
In-Reply-To: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>
References: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>
Message-ID: <485B20B7.9040002@ar.media.kyoto-u.ac.jp>

Nathan Bell wrote:
> Is there a plan to get SciPy 0.7 out the door?  Numerous improvements
> have been made since the release of 0.6, which was 9 months ago.
> Whatever the faults of the current SVN (e.g. unittest that have been
> broken for over a month), are they not now preferable to those in 0.6?
>
> A release now would be helpful to those who want to use SciPy in the
> classroom this fall.
>
>   

My understanding is that a new scipy is released shortly after numpy. 
But no discussion has happened, and the bug list is long (180 bugs). I 
would say, but that's only my opinion, that unless scipy 0.6 cannot work 
with current numpy (1.1), it should not happen without more work (at 
least some bug triaging to see blockers).

cheers,

David


From robert.kern at gmail.com  Thu Jun 19 23:48:09 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 19 Jun 2008 22:48:09 -0500
Subject: [SciPy-dev] 0.7 release schedule
In-Reply-To: <485B20B7.9040002@ar.media.kyoto-u.ac.jp>
References: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>
	<485B20B7.9040002@ar.media.kyoto-u.ac.jp>
Message-ID: <3d375d730806192048i74d150eeje38b89f44bc6e0b9@mail.gmail.com>

On Thu, Jun 19, 2008 at 22:15, David Cournapeau
<david at ar.media.kyoto-u.ac.jp> wrote:
> Nathan Bell wrote:
>> Is there a plan to get SciPy 0.7 out the door?  Numerous improvements
>> have been made since the release of 0.6, which was 9 months ago.
>> Whatever the faults of the current SVN (e.g. unittest that have been
>> broken for over a month), are they not now preferable to those in 0.6?
>>
>> A release now would be helpful to those who want to use SciPy in the
>> classroom this fall.
>
> My understanding is that a new scipy is released shortly after numpy.

Not without a release manager, it doesn't!

-- 
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 david at ar.media.kyoto-u.ac.jp  Thu Jun 19 23:41:18 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Fri, 20 Jun 2008 12:41:18 +0900
Subject: [SciPy-dev] 0.7 release schedule
In-Reply-To: <3d375d730806192048i74d150eeje38b89f44bc6e0b9@mail.gmail.com>
References: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>	<485B20B7.9040002@ar.media.kyoto-u.ac.jp>
	<3d375d730806192048i74d150eeje38b89f44bc6e0b9@mail.gmail.com>
Message-ID: <485B26DE.7050901@ar.media.kyoto-u.ac.jp>

Robert Kern wrote:
>
> Not without a release manager, it doesn't!
>
>   

It was more or less implied when I mention the 180 bugs list and bug 
triaging :) So to be clearer: who wants to be a release manager ? It 
won't brings you millions, but will bring you fame and recognition.

cheers,

David


From wnbell at gmail.com  Fri Jun 20 00:19:14 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Thu, 19 Jun 2008 23:19:14 -0500
Subject: [SciPy-dev] 0.7 release schedule
In-Reply-To: <485B20B7.9040002@ar.media.kyoto-u.ac.jp>
References: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>
	<485B20B7.9040002@ar.media.kyoto-u.ac.jp>
Message-ID: <d05265cb0806192119k2ba5f40bw982f10840722b5f4@mail.gmail.com>

On Thu, Jun 19, 2008 at 10:15 PM, David Cournapeau
<david at ar.media.kyoto-u.ac.jp> wrote:
>
> My understanding is that a new scipy is released shortly after numpy.
> But no discussion has happened, and the bug list is long (180 bugs). I
> would say, but that's only my opinion, that unless scipy 0.6 cannot work
> with current numpy (1.1), it should not happen without more work (at
> least some bug triaging to see blockers).
>

Well, 180 tickets sounds like a lot until you consider that most if
not all of them probably exist in 0.6 as well.  Not to mention the 86
tickets that have been fixed in 0.7 and the fact that perhaps 50 of
the remaining tickets are enhancements and tasks.

IMO we should address the any blockers now and get 0.7 out ASAP.  Nine
months is too long to wait for new features/fixes to appear.

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


From david at ar.media.kyoto-u.ac.jp  Fri Jun 20 00:09:12 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Fri, 20 Jun 2008 13:09:12 +0900
Subject: [SciPy-dev] 0.7 release schedule
In-Reply-To: <d05265cb0806192119k2ba5f40bw982f10840722b5f4@mail.gmail.com>
References: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>	<485B20B7.9040002@ar.media.kyoto-u.ac.jp>
	<d05265cb0806192119k2ba5f40bw982f10840722b5f4@mail.gmail.com>
Message-ID: <485B2D68.1020708@ar.media.kyoto-u.ac.jp>

Nathan Bell wrote:
>
> Well, 180 tickets sounds like a lot until you consider that most if
> not all of them probably exist in 0.6 as well.

That sounds more as an argument against it than for it: having been 
sloppy before is not a justification to continue on a sloppy road.

> IMO we should address the any blockers now and get 0.7 out ASAP.

Yes: that's basically what a release manager is supposed to do :) 
Someone else has to step in (I can't do it ATM).

cheers

David


From pgmdevlist at gmail.com  Fri Jun 20 01:03:32 2008
From: pgmdevlist at gmail.com (Pierre GM)
Date: Fri, 20 Jun 2008 01:03:32 -0400
Subject: [SciPy-dev] Confused over site.cfg
Message-ID: <200806200103.32830.pgmdevlist@gmail.com>

Folks,
I just spent the last 6 hours trying to compile scipy from the SVN, with 
various success. Note that in each of the following examples, I had removed 
any previous scipy installation and build directory.

* Running setup.py install without creating a site.cfg resulted in an 
apparently successful compilation. However, import scipy.stats failed because 
of z_abs being undefined in scipy/linalg/fblas.so. Turned out that c_abs 
wasn't defined either.
ImportError: /usr/lib64/python2.4/site-packages/scipy/linalg/fblas.so: 
undefined symbol: z_abs

* Uncommented the lapack_opt, blas_opt and DEFAULT sections in 
site.cfg.example and renaming the file to site.cfg gave the same results.

* Defining a [atlas] section, with `atlas_libs=lapack, blas, f77blas, cblas, 
atlas` eventually worked (I was able to import scipy.stats).

What bothers me is that the use of [atlas] seems to be deprecated (as stated 
in site.cfg.example). So what's happening ? In the three cases, my atlas 
version was properly recognized (you'll find the info below).

Any hint would be welcomed (and I'm not modifying my site.cfg any more...)

Thanks
P.

#----------------------------------------
ATLAS version 3.8.2 built by root on Thu Jun 19 14:40:27 EDT 2008:
   UNAME    : Linux back2tux 2.6.22-suspend2-r1 #8 Fri Feb 15 17:00:17 EST 
2008 x86_64 Mobile AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD GNU/Linux
   INSTFLG  : -1 0 -a 1
   
ARCHDEFS : -DATL_OS_Linux -DATL_ARCH_HAMMER -DATL_CPUMHZ=2205 -DATL_SSE2 -DATL_SSE1 -DATL_3DNow -DATL_USE64BITS -DATL_GAS_x8664
   F2CDEFS  : -DAdd_ -DF77_INTEGER=int -DStringSunStyle
   CACHEEDGE: 262144
   F77      : gfortran, version GNU Fortran 95 (GCC) 4.1.2 (Gentoo 4.1.2 
p1.0.1)
   F77FLAGS : -O2 -m64
   SMC      : x86_64-pc-linux-gnu-gcc, version x86_64-pc-linux-gnu-gcc (GCC) 
4.1.2 (Gentoo 4.1.2 p1.0.1)
   SMCFLAGS : -march=k8 -O2 -pipe -m64
   SKC      : x86_64-pc-linux-gnu-gcc, version x86_64-pc-linux-gnu-gcc (GCC) 
4.1.2 (Gentoo 4.1.2 p1.0.1)
   SKCFLAGS : -march=k8 -O2 -pipe -m64



From david at ar.media.kyoto-u.ac.jp  Fri Jun 20 01:15:18 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Fri, 20 Jun 2008 14:15:18 +0900
Subject: [SciPy-dev] Deprecating current scipy.stats.var API for 0.7 ?
Message-ID: <485B3CE6.9080704@ar.media.kyoto-u.ac.jp>

Hi,

   This issue keeps coming up, and I would like to start solving it. 
scipy.stats.var, mean and other basic functions do not have the same API 
as numpy (axis = 0 vs None, etc...). What about keeping them for now, 
but deprecating them in 0.7 + putting funcs which are the same as numpy 
with a different name, and removing the old ones in 0.8 ?

cheers,

David


From peridot.faceted at gmail.com  Fri Jun 20 01:36:16 2008
From: peridot.faceted at gmail.com (Anne Archibald)
Date: Fri, 20 Jun 2008 01:36:16 -0400
Subject: [SciPy-dev] Deprecating current scipy.stats.var API for 0.7 ?
In-Reply-To: <485B3CE6.9080704@ar.media.kyoto-u.ac.jp>
References: <485B3CE6.9080704@ar.media.kyoto-u.ac.jp>
Message-ID: <ce557a360806192236w40459286pf16604aca80a976@mail.gmail.com>

2008/6/20 David Cournapeau <david at ar.media.kyoto-u.ac.jp>:

>   This issue keeps coming up, and I would like to start solving it.
> scipy.stats.var, mean and other basic functions do not have the same API
> as numpy (axis = 0 vs None, etc...). What about keeping them for now,
> but deprecating them in 0.7 + putting funcs which are the same as numpy
> with a different name, and removing the old ones in 0.8 ?

Consistency sounds like a good idea to me - though having the same
functions under different names is not much more consistent than
different functions under the same name. But if the functions in
scipy.stats are the same as the functions in numpy, why have them at
all? It seems like they should present some increase in functionality.
We have had a number of requests for versions of mean, std, and var
that are more numerically stable; perhaps these should be the new
ones?

Anne


From david at ar.media.kyoto-u.ac.jp  Fri Jun 20 01:35:46 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Fri, 20 Jun 2008 14:35:46 +0900
Subject: [SciPy-dev] Deprecating current scipy.stats.var API for 0.7 ?
In-Reply-To: <ce557a360806192236w40459286pf16604aca80a976@mail.gmail.com>
References: <485B3CE6.9080704@ar.media.kyoto-u.ac.jp>
	<ce557a360806192236w40459286pf16604aca80a976@mail.gmail.com>
Message-ID: <485B41B2.9010704@ar.media.kyoto-u.ac.jp>

Anne Archibald wrote:
> Consistency sounds like a good idea to me - though having the same
> functions under different names is not much more consistent than
> different functions under the same name.

I disagree on this particular case at least: the axis difference is 
annoying. I would not mind removing the function at all if we can 
provide all the wanted behavior in numpy.

>  But if the functions in
> scipy.stats are the same as the functions in numpy, why have them at
> all? It seems like they should present some increase in functionality.
> We have had a number of requests for versions of mean, std, and var
> that are more numerically stable; perhaps these should be the new
> ones?
>   

Is there any reason why the numerically stable cannot be put into numpy 
proper ?

cheers,

David


From fperez.net at gmail.com  Fri Jun 20 02:47:36 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 19 Jun 2008 23:47:36 -0700
Subject: [SciPy-dev] 0.7 release schedule
In-Reply-To: <d05265cb0806192119k2ba5f40bw982f10840722b5f4@mail.gmail.com>
References: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>
	<485B20B7.9040002@ar.media.kyoto-u.ac.jp>
	<d05265cb0806192119k2ba5f40bw982f10840722b5f4@mail.gmail.com>
Message-ID: <db6b5ecc0806192347n390ac481o421408bf8313126f@mail.gmail.com>

On Thu, Jun 19, 2008 at 9:19 PM, Nathan Bell <wnbell at gmail.com> wrote:

> IMO we should address the any blockers now and get 0.7 out ASAP.  Nine
> months is too long to wait for new features/fixes to appear.

Just a note: Jarrod,  who is our fearless numpy release manager and I
know also keeps a close eye on Scipy, is currently traveling quite a
bit.  I don't know his exact schedule, but he may actually be flying
right now, and since it's a very long international flight, he might
not pitch in for this discussion for a while.

Cheers,

f


From nwagner at iam.uni-stuttgart.de  Fri Jun 20 12:46:23 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Fri, 20 Jun 2008 18:46:23 +0200
Subject: [SciPy-dev] 0.7 release schedule
In-Reply-To: <485B2D68.1020708@ar.media.kyoto-u.ac.jp>
References: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>
	<485B20B7.9040002@ar.media.kyoto-u.ac.jp>
	<d05265cb0806192119k2ba5f40bw982f10840722b5f4@mail.gmail.com>
	<485B2D68.1020708@ar.media.kyoto-u.ac.jp>
Message-ID: <web-103617420@uni-stuttgart.de>

On Fri, 20 Jun 2008 13:09:12 +0900
  David Cournapeau <david at ar.media.kyoto-u.ac.jp> wrote:
> Nathan Bell wrote:
>>
>> Well, 180 tickets sounds like a lot until you consider 
>>that most if
>> not all of them probably exist in 0.6 as well.
> 
> That sounds more as an argument against it than for it: 
>having been 
> sloppy before is not a justification to continue on a 
>sloppy road.
> 
>> IMO we should address the any blockers now and get 0.7 
>>out ASAP.
> 
> Yes: that's basically what a release manager is supposed 
>to do :) 
> Someone else has to step in (I can't do it ATM).
> 
> cheers
> 
> David


There are lots of duplicate tickets, e.g.
http://projects.scipy.org/scipy/scipy/ticket/672

IIRC, some tickets can be closed already since they have 
been fixed in svn.

Unfortunately, I can't close tickets so far.

Nils
  


From pav at iki.fi  Fri Jun 20 12:47:38 2008
From: pav at iki.fi (Pauli Virtanen)
Date: Fri, 20 Jun 2008 16:47:38 +0000 (UTC)
Subject: [SciPy-dev] numpy doc wiki question -- where is numpy.ma?
References: <485709F7.9040903@astraw.com> <g3bjja$9ir$1@ger.gmane.org>
	<48595DDA.3000702@astraw.com>
Message-ID: <g3gmva$aec$1@ger.gmane.org>

Wed, 18 Jun 2008 12:11:22 -0700, Andrew Straw wrote:
> Pauli Virtanen wrote:
[clip]
>> It's here:
>>
>>     http://sd-2116.dedibox.fr/pydocweb/doc/numpy.ma/
>>
>> It's was hidden from the numpy page, as numpy.ma is not in
>> numpy.__all__. (Right now I'm not sure whether this is sensible
>> behavior...)
>
> Well, I don't have an opinion about whether it should be in __all__ (I
> never use from numpy import *), but it is certainly an "available
> subpackage" of numpy, so it should at least go in the list on that page.
> Since that page is a view of the top-level docstring for numpy, I think
> this is all the more important. 

Fixed.

> Are there other subpackages in this netherworld?

I doubt that anything important apart from numpy.ma was missing.

-- 
Pauli Virtanen



From david at ar.media.kyoto-u.ac.jp  Sat Jun 21 03:13:29 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Sat, 21 Jun 2008 16:13:29 +0900
Subject: [SciPy-dev] 0.7 release schedule
In-Reply-To: <web-103617420@uni-stuttgart.de>
References: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>	<485B20B7.9040002@ar.media.kyoto-u.ac.jp>	<d05265cb0806192119k2ba5f40bw982f10840722b5f4@mail.gmail.com>	<485B2D68.1020708@ar.media.kyoto-u.ac.jp>
	<web-103617420@uni-stuttgart.de>
Message-ID: <485CAA19.8050504@ar.media.kyoto-u.ac.jp>

Nils Wagner wrote:
>
> There are lots of duplicate tickets, e.g.
> http://projects.scipy.org/scipy/scipy/ticket/672
>
> IIRC, some tickets can be closed already since they have 
> been fixed in svn.
>
> Unfortunately, I can't close tickets so far.
>   

If you give the ticket numbers, most of the job would be done, and 
someone (me) could triage and close them accordingly.

thanks,

David


From nwagner at iam.uni-stuttgart.de  Sat Jun 21 04:16:09 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Sat, 21 Jun 2008 10:16:09 +0200
Subject: [SciPy-dev] 0.7 release schedule
In-Reply-To: <485CAA19.8050504@ar.media.kyoto-u.ac.jp>
References: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>
	<485B20B7.9040002@ar.media.kyoto-u.ac.jp>
	<d05265cb0806192119k2ba5f40bw982f10840722b5f4@mail.gmail.com>
	<485B2D68.1020708@ar.media.kyoto-u.ac.jp>
	<web-103617420@uni-stuttgart.de>
	<485CAA19.8050504@ar.media.kyoto-u.ac.jp>
Message-ID: <web-103635529@uni-stuttgart.de>

On Sat, 21 Jun 2008 16:13:29 +0900
  David Cournapeau <david at ar.media.kyoto-u.ac.jp> wrote:
> Nils Wagner wrote:
>>
>> There are lots of duplicate tickets, e.g.
>> http://projects.scipy.org/scipy/scipy/ticket/672
>>
>> IIRC, some tickets can be closed already since they have 
>> been fixed in svn.
>>
>> Unfortunately, I can't close tickets so far.
>>   
> 
> If you give the ticket numbers, most of the job would be 
>done, and 
> someone (me) could triage and close them accordingly.
> 
> thanks,
> 
> David

David,

Okay, here are some pending tickets.

http://projects.scipy.org/scipy/scipy/ticket/591
can be closed. It is fixed in svn.

The patch attached to

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

works for me. IMHO the ticket #593 can be closed, when
the patch is applied in the trunk. However a test would
be nice.

Duplicate of ticket #641
http://projects.scipy.org/scipy/scipy/ticket/642

#647 and #648 can be combined.

#662, #663, #664, #665 are duplicates

#672, #673, #674 are duplicates

Cheers,

          Nils

P.S. There are still some annoying test errors/failures in 
current svn

http://projects.scipy.org/scipy/scipy/ticket/611
http://projects.scipy.org/scipy/scipy/ticket/584
http://projects.scipy.org/scipy/scipy/ticket/586
http://projects.scipy.org/scipy/scipy/ticket/587



From david at ar.media.kyoto-u.ac.jp  Sat Jun 21 04:58:57 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Sat, 21 Jun 2008 17:58:57 +0900
Subject: [SciPy-dev] 0.7 release schedule
In-Reply-To: <web-103635529@uni-stuttgart.de>
References: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>	<485B20B7.9040002@ar.media.kyoto-u.ac.jp>	<d05265cb0806192119k2ba5f40bw982f10840722b5f4@mail.gmail.com>	<485B2D68.1020708@ar.media.kyoto-u.ac.jp>	<web-103617420@uni-stuttgart.de>	<485CAA19.8050504@ar.media.kyoto-u.ac.jp>
	<web-103635529@uni-stuttgart.de>
Message-ID: <485CC2D1.4030300@ar.media.kyoto-u.ac.jp>

Nils Wagner wrote:
>
> David,
>
> Okay, here are some pending tickets.
>
> http://projects.scipy.org/scipy/scipy/ticket/591
> can be closed. It is fixed in svn.
>
> The patch attached to
>
> http://projects.scipy.org/scipy/scipy/ticket/593
>
> works for me. IMHO the ticket #593 can be closed, when
> the patch is applied in the trunk. However a test would
> be nice.
>
> Duplicate of ticket #641
> http://projects.scipy.org/scipy/scipy/ticket/642
>
> #647 and #648 can be combined.
>
> #662, #663, #664, #665 are duplicates
>
> #672, #673, #674 are duplicates
>   

Thanks, I closed the dup, and also added a report on scipy trac to track
open tickets with attachments (I have not taken a look at 593).

> P.S. There are still some annoying test errors/failures in 
> current svn
>   

Yes. I may take a look at some of those later today,

cheers,

David



From wnbell at gmail.com  Sat Jun 21 05:39:26 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Sat, 21 Jun 2008 04:39:26 -0500
Subject: [SciPy-dev] 0.7 release schedule
In-Reply-To: <web-103635529@uni-stuttgart.de>
References: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>
	<485B20B7.9040002@ar.media.kyoto-u.ac.jp>
	<d05265cb0806192119k2ba5f40bw982f10840722b5f4@mail.gmail.com>
	<485B2D68.1020708@ar.media.kyoto-u.ac.jp>
	<web-103617420@uni-stuttgart.de>
	<485CAA19.8050504@ar.media.kyoto-u.ac.jp>
	<web-103635529@uni-stuttgart.de>
Message-ID: <d05265cb0806210239p37b201f7k2fcb2de39348bcde@mail.gmail.com>

On Sat, Jun 21, 2008 at 3:16 AM, Nils Wagner
<nwagner at iam.uni-stuttgart.de> wrote:
>
> P.S. There are still some annoying test errors/failures in
> current svn
>
> http://projects.scipy.org/scipy/scipy/ticket/611

Should be fixed in r4455

> http://projects.scipy.org/scipy/scipy/ticket/584

I have no idea how to solve this one

> http://projects.scipy.org/scipy/scipy/ticket/586

It appears that the _bspline extension module is being built (or
rather not being built) with weave in a fairly convoluted manner.

> http://projects.scipy.org/scipy/scipy/ticket/587

I suspect the self.axis = ..... on line 100 is the source of the
error.  It sets axis to an array of floats, which is certainly wrong.

I tried replacing self.axis with 'mu' but that failed too.  I have no
idea what the code is doing.


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


From nwagner at iam.uni-stuttgart.de  Sat Jun 21 05:54:17 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Sat, 21 Jun 2008 11:54:17 +0200
Subject: [SciPy-dev] 0.7 release schedule
In-Reply-To: <485CC2D1.4030300@ar.media.kyoto-u.ac.jp>
References: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>
	<485B20B7.9040002@ar.media.kyoto-u.ac.jp>
	<d05265cb0806192119k2ba5f40bw982f10840722b5f4@mail.gmail.com>
	<485B2D68.1020708@ar.media.kyoto-u.ac.jp>
	<web-103617420@uni-stuttgart.de>
	<485CAA19.8050504@ar.media.kyoto-u.ac.jp>
	<web-103635529@uni-stuttgart.de>
	<485CC2D1.4030300@ar.media.kyoto-u.ac.jp>
Message-ID: <web-103637994@uni-stuttgart.de>

On Sat, 21 Jun 2008 17:58:57 +0900
  David Cournapeau <david at ar.media.kyoto-u.ac.jp> wrote:
> Nils Wagner wrote:
>>
>> David,
>>
>> Okay, here are some pending tickets.
>>
>> http://projects.scipy.org/scipy/scipy/ticket/591
>> can be closed. It is fixed in svn.
>>
>> The patch attached to
>>
>> http://projects.scipy.org/scipy/scipy/ticket/593
>>
>> works for me. IMHO the ticket #593 can be closed, when
>> the patch is applied in the trunk. However a test would
>> be nice.
>>
>> Duplicate of ticket #641
>> http://projects.scipy.org/scipy/scipy/ticket/642
>>
>> #647 and #648 can be combined.
>>
>> #662, #663, #664, #665 are duplicates
>>
>> #672, #673, #674 are duplicates
>>   
> 
> Thanks, I closed the dup, and also added a report on 
>scipy trac to track
> open tickets with attachments (I have not taken a look 
>at 593).
> 
>> P.S. There are still some annoying test errors/failures 
>>in 
>> current svn
>>   
> 
> Yes. I may take a look at some of those later today,
> 
> cheers,
> 
> David
> 
  
Hi David,

Please can you also check the status of ticket
http://scipy.org/scipy/scipy/ticket/413

I cannot reproduce the defect.

The same holds for

http://scipy.org/scipy/scipy/ticket/561
http://scipy.org/scipy/scipy/ticket/567

Nils


From nwagner at iam.uni-stuttgart.de  Sat Jun 21 06:06:45 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Sat, 21 Jun 2008 12:06:45 +0200
Subject: [SciPy-dev] 0.7 release schedule
In-Reply-To: <d05265cb0806210239p37b201f7k2fcb2de39348bcde@mail.gmail.com>
References: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>
	<485B20B7.9040002@ar.media.kyoto-u.ac.jp>
	<d05265cb0806192119k2ba5f40bw982f10840722b5f4@mail.gmail.com>
	<485B2D68.1020708@ar.media.kyoto-u.ac.jp>
	<web-103617420@uni-stuttgart.de>
	<485CAA19.8050504@ar.media.kyoto-u.ac.jp>
	<web-103635529@uni-stuttgart.de>
	<d05265cb0806210239p37b201f7k2fcb2de39348bcde@mail.gmail.com>
Message-ID: <web-103638296@uni-stuttgart.de>

On Sat, 21 Jun 2008 04:39:26 -0500
  "Nathan Bell" <wnbell at gmail.com> wrote:
> On Sat, Jun 21, 2008 at 3:16 AM, Nils Wagner
> <nwagner at iam.uni-stuttgart.de> wrote:
>>
>> P.S. There are still some annoying test errors/failures 
>>in
>> current svn
>>
>> http://projects.scipy.org/scipy/scipy/ticket/611
> 
> Should be fixed in r4455
> 
>> http://projects.scipy.org/scipy/scipy/ticket/584
> 
> I have no idea how to solve this one
> 
>> http://projects.scipy.org/scipy/scipy/ticket/586
> 
> It appears that the _bspline extension module is being 
>built (or
> rather not being built) with weave in a fairly 
>convoluted manner.
> 
>> http://projects.scipy.org/scipy/scipy/ticket/587
> 
> I suspect the self.axis = ..... on line 100 is the 
>source of the
> error.  It sets axis to an array of floats, which is 
>certainly wrong.
> 
> I tried replacing self.axis with 'mu' but that failed 
>too.  I have no
> idea what the code is doing.
> 
> 
> -- 
> Nathan Bell wnbell at gmail.com
> http://graphics.cs.uiuc.edu/~wnbell/
  
Hi Nathan,

Here comes the output of scipy.test() '0.7.0.dev4455'

======================================================================
ERROR: test_mio.test_gzip_simple
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"/usr/lib/python2.4/site-packages/nose-0.10.3-py2.4.egg/nose/case.py", 
line 182, in runTest
     self.test(*self.arg)
   File 
"/usr/lib/python2.4/site-packages/scipy/io/matlab/tests/test_mio.py", 
line 263, in test_gzip_simple
     actual = loadmat(mat_stream)
   File 
"/usr/lib/python2.4/site-packages/scipy/io/matlab/mio.py", 
line 96, in loadmat
     matfile_dict = MR.get_variables()
   File 
"/usr/lib/python2.4/site-packages/scipy/io/matlab/miobase.py", 
line 270, in get_variables
     getter = self.matrix_getter_factory()
   File 
"/usr/lib/python2.4/site-packages/scipy/io/matlab/mio4.py", 
line 199, in matrix_getter_factory
     return self._array_reader.matrix_getter_factory()
   File 
"/usr/lib/python2.4/site-packages/scipy/io/matlab/mio4.py", 
line 66, in matrix_getter_factory
     header['name'] = self.read_ztstring(data['namlen'])
   File 
"/usr/lib/python2.4/site-packages/scipy/io/matlab/miobase.py", 
line 81, in read_ztstring
     return self.mat_stream.read(num_bytes).strip('\x00')
   File "/usr/lib/python2.4/gzip.py", line 230, in read
     chunk = self.extrabuf[:size]
TypeError: slice indices must be integers

======================================================================
ERROR: Failure: ImportError (cannot import name _bspline)
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"/usr/lib/python2.4/site-packages/nose-0.10.3-py2.4.egg/nose/loader.py", 
line 363, in loadTestsFromName
     module = self.importer.importFromPath(
   File 
"/usr/lib/python2.4/site-packages/nose-0.10.3-py2.4.egg/nose/importer.py", 
line 39, in importFromPath
     return self.importFromDir(dir_path, fqname)
   File 
"/usr/lib/python2.4/site-packages/nose-0.10.3-py2.4.egg/nose/importer.py", 
line 84, in importFromDir
     mod = load_module(part_fqname, fh, filename, desc)
   File 
"/usr/lib/python2.4/site-packages/scipy/stats/models/tests/test_bspline.py", 
line 9, in ?
     import scipy.stats.models.bspline as B
   File 
"/usr/lib/python2.4/site-packages/scipy/stats/models/bspline.py", 
line 23, in ?
     from scipy.stats.models import _bspline
ImportError: cannot import name _bspline

======================================================================
ERROR: test_huber (test_scale.TestScale)
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"/usr/lib/python2.4/site-packages/scipy/stats/models/tests/test_scale.py", 
line 35, in test_huber
     m = scale.huber(X)
   File 
"/usr/lib/python2.4/site-packages/scipy/stats/models/robust/scale.py", 
line 82, in __call__
     for donothing in self:
   File 
"/usr/lib/python2.4/site-packages/scipy/stats/models/robust/scale.py", 
line 102, in next
     scale = N.sum(subset * (a - mu)**2, axis=self.axis) / 
(self.n * Huber.gamma - N.sum(1. - subset, axis=self.axis) 
* Huber.c**2)
   File 
"/usr/lib/python2.4/site-packages/numpy/core/fromnumeric.py", 
line 994, in sum
     return sum(axis, dtype, out)
TypeError: only length-1 arrays can be converted to Python 
scalars

======================================================================
ERROR: test_huberaxes (test_scale.TestScale)
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"/usr/lib/python2.4/site-packages/scipy/stats/models/tests/test_scale.py", 
line 40, in test_huberaxes
     m = scale.huber(X, axis=0)
   File 
"/usr/lib/python2.4/site-packages/scipy/stats/models/robust/scale.py", 
line 82, in __call__
     for donothing in self:
   File 
"/usr/lib/python2.4/site-packages/scipy/stats/models/robust/scale.py", 
line 102, in next
     scale = N.sum(subset * (a - mu)**2, axis=self.axis) / 
(self.n * Huber.gamma - N.sum(1. - subset, axis=self.axis) 
* Huber.c**2)
   File 
"/usr/lib/python2.4/site-packages/numpy/core/fromnumeric.py", 
line 994, in sum
     return sum(axis, dtype, out)
TypeError: only length-1 arrays can be converted to Python 
scalars

======================================================================
FAIL: test_imresize (test_pilutil.TestPILUtil)
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"/usr/lib/python2.4/site-packages/scipy/testing/decorators.py", 
line 81, in skipper
     return f(*args, **kwargs)
   File 
"/usr/lib/python2.4/site-packages/scipy/misc/tests/test_pilutil.py", 
line 25, in test_imresize
     assert_equal(im1.shape,(11,22))
   File 
"/usr/lib/python2.4/site-packages/numpy/testing/utils.py", 
line 137, in assert_equal
     assert_equal(len(actual),len(desired),err_msg,verbose)
   File 
"/usr/lib/python2.4/site-packages/numpy/testing/utils.py", 
line 145, in assert_equal
     assert desired == actual, msg
AssertionError:
Items are not equal:
  ACTUAL: 0
  DESIRED: 2

======================================================================
FAIL: test_autoalign_nmi_value_2
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"/usr/lib/python2.4/site-packages/scipy/ndimage/tests/test_registration.py", 
line 176, in test_autoalign_nmi_value_2
     assert_almost_equal(cost, -1.7973048186515352, 
decimal=6)
   File 
"/usr/lib/python2.4/site-packages/numpy/testing/utils.py", 
line 158, in assert_almost_equal
     assert round(abs(desired - actual),decimal) == 0, msg
AssertionError:
Items are not equal:
  ACTUAL: -1.797321600138216
  DESIRED: -1.7973048186515352

======================================================================
FAIL: test_namespace (test_formula.TestFormula)
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"/usr/lib/python2.4/site-packages/scipy/stats/models/tests/test_formula.py", 
line 119, in test_namespace
     self.assertEqual(xx.namespace, Y.namespace)
AssertionError: {} != {'Y': array([ 0,  2,  4,  6,  8, 10, 
12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 
40,
        42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 64, 
66, 68, 70, 72, 74, 76, 78, 80, 82,
        84, 86, 88, 90, 92, 94, 96, 98]), 'X': array([ 0, 
 1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11, 12, 13, 14, 
15, 16, 17, 18, 19, 20,
        21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 
33, 34, 35, 36, 37, 38, 39, 40, 41,
        42, 43, 44, 45, 46, 47, 48, 49])}

----------------------------------------------------------------------
Ran 2259 tests in 178.150s

FAILED (errors=4, failures=3)
>>>
>>>
>>> scipy.__version__
'0.7.0.dev4455'


From nwagner at iam.uni-stuttgart.de  Sat Jun 21 06:30:13 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Sat, 21 Jun 2008 12:30:13 +0200
Subject: [SciPy-dev] 0.7 release schedule
In-Reply-To: <485CC2D1.4030300@ar.media.kyoto-u.ac.jp>
References: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>
	<485B20B7.9040002@ar.media.kyoto-u.ac.jp>
	<d05265cb0806192119k2ba5f40bw982f10840722b5f4@mail.gmail.com>
	<485B2D68.1020708@ar.media.kyoto-u.ac.jp>
	<web-103617420@uni-stuttgart.de>
	<485CAA19.8050504@ar.media.kyoto-u.ac.jp>
	<web-103635529@uni-stuttgart.de>
	<485CC2D1.4030300@ar.media.kyoto-u.ac.jp>
Message-ID: <web-103638904@uni-stuttgart.de>

On Sat, 21 Jun 2008 17:58:57 +0900
  David Cournapeau <david at ar.media.kyoto-u.ac.jp> wrote:
> Nils Wagner wrote:
>>
>> David,
>>
>> Okay, here are some pending tickets.
>>
>> http://projects.scipy.org/scipy/scipy/ticket/591
>> can be closed. It is fixed in svn.
>>
>> The patch attached to
>>
>> http://projects.scipy.org/scipy/scipy/ticket/593
>>
>> works for me. IMHO the ticket #593 can be closed, when
>> the patch is applied in the trunk. However a test would
>> be nice.
>>
>> Duplicate of ticket #641
>> http://projects.scipy.org/scipy/scipy/ticket/642
>>
>> #647 and #648 can be combined.
>>
>> #662, #663, #664, #665 are duplicates
>>
>> #672, #673, #674 are duplicates
>>   
> 
> Thanks, I closed the dup, and also added a report on 
>scipy trac to track
> open tickets with attachments (I have not taken a look 
>at 593).
> 
>> P.S. There are still some annoying test errors/failures 
>>in 
>> current svn
>>   
> 
> Yes. I may take a look at some of those later today,
> 
> cheers,
> 
> David
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
  
David,

Tickets #499 and #525 seem to be correlated as well.
See
http://scipy.org/scipy/scipy/ticket/525
http://scipy.org/scipy/scipy/ticket/499

IMHO
http://scipy.org/scipy/scipy/ticket/308
can be closed. numexpr is now a stand-alone project.

Ticket 591
http://scipy.org/scipy/scipy/ticket/591
can be closed.

Nils


From nwagner at iam.uni-stuttgart.de  Sat Jun 21 07:46:34 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Sat, 21 Jun 2008 13:46:34 +0200
Subject: [SciPy-dev] Enhancements was Re:  0.7 release schedule
In-Reply-To: <web-103638904@uni-stuttgart.de>
References: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>
	<485B20B7.9040002@ar.media.kyoto-u.ac.jp>
	<d05265cb0806192119k2ba5f40bw982f10840722b5f4@mail.gmail.com>
	<485B2D68.1020708@ar.media.kyoto-u.ac.jp>
	<web-103617420@uni-stuttgart.de>
	<485CAA19.8050504@ar.media.kyoto-u.ac.jp>
	<web-103635529@uni-stuttgart.de>
	<485CC2D1.4030300@ar.media.kyoto-u.ac.jp>
	<web-103638904@uni-stuttgart.de>
Message-ID: <web-103640589@uni-stuttgart.de>

On Sat, 21 Jun 2008 12:30:13 +0200
  "Nils Wagner" <nwagner at iam.uni-stuttgart.de> wrote:
> On Sat, 21 Jun 2008 17:58:57 +0900
>  David Cournapeau <david at ar.media.kyoto-u.ac.jp> wrote:
>> Nils Wagner wrote:
>>>
>>> David,
>>>
>>> Okay, here are some pending tickets.
>>>
>>> http://projects.scipy.org/scipy/scipy/ticket/591
>>> can be closed. It is fixed in svn.
>>>
>>> The patch attached to
>>>
>>> http://projects.scipy.org/scipy/scipy/ticket/593
>>>
>>> works for me. IMHO the ticket #593 can be closed, when
>>> the patch is applied in the trunk. However a test would
>>> be nice.
>>>
>>> Duplicate of ticket #641
>>> http://projects.scipy.org/scipy/scipy/ticket/642
>>>
>>> #647 and #648 can be combined.
>>>
>>> #662, #663, #664, #665 are duplicates
>>>
>>> #672, #673, #674 are duplicates
>>>   
>> 
>> Thanks, I closed the dup, and also added a report on 
>>scipy trac to track
>> open tickets with attachments (I have not taken a look 
>>at 593).
>> 
>>> P.S. There are still some annoying test errors/failures 
>>>in 
>>> current svn
>>>   
>> 
>> Yes. I may take a look at some of those later today,
>> 
>> cheers,
>> 
>> David
>> 
>> _______________________________________________
>> Scipy-dev mailing list
>> Scipy-dev at scipy.org
>> http://projects.scipy.org/mailman/listinfo/scipy-dev
>  
> David,
> 
> Tickets #499 and #525 seem to be correlated as well.
> See
> http://scipy.org/scipy/scipy/ticket/525
> http://scipy.org/scipy/scipy/ticket/499
> 
> IMHO
> http://scipy.org/scipy/scipy/ticket/308
> can be closed. numexpr is now a stand-alone project.
> 
> Ticket 591
> http://scipy.org/scipy/scipy/ticket/591
> can be closed.
> 
> Nils
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev

IMHO, ticket 670 is invalid. 
http://scipy.org/scipy/scipy/ticket/670

And there are many enhancements (see the list below)

Other
http://scipy.org/scipy/scipy/ticket/674
http://scipy.org/scipy/scipy/ticket/669
http://scipy.org/scipy/scipy/ticket/651
http://scipy.org/scipy/scipy/ticket/635
http://scipy.org/scipy/scipy/ticket/634
http://scipy.org/scipy/scipy/ticket/628
http://scipy.org/scipy/scipy/ticket/608
http://scipy.org/scipy/scipy/ticket/562
http://scipy.org/scipy/scipy/ticket/448
http://scipy.org/scipy/scipy/ticket/330

scipy.cluster
http://scipy.org/scipy/scipy/ticket/612
http://scipy.org/scipy/scipy/ticket/426

scipy.fftpack
http://scipy.org/scipy/scipy/ticket/474
http://scipy.org/scipy/scipy/ticket/268

scipy.integrate
http://scipy.org/scipy/scipy/ticket/615
http://scipy.org/scipy/scipy/ticket/597
http://scipy.org/scipy/scipy/ticket/478
http://scipy.org/scipy/scipy/ticket/291

scipy.interpolate
http://scipy.org/scipy/scipy/ticket/206
http://scipy.org/scipy/scipy/ticket/286
http://scipy.org/scipy/scipy/ticket/305
http://scipy.org/scipy/scipy/ticket/687

scipy.io
http://scipy.org/scipy/scipy/ticket/354

scipy.linalg
http://scipy.org/scipy/scipy/ticket/354
http://scipy.org/scipy/scipy/ticket/456
http://scipy.org/scipy/scipy/ticket/632

scipy.misc
http://scipy.org/scipy/scipy/ticket/564
http://scipy.org/scipy/scipy/ticket/675

scipy.optimize
http://scipy.org/scipy/scipy/ticket/285

scipy.signal
http://scipy.org/scipy/scipy/ticket/386
http://scipy.org/scipy/scipy/ticket/457
http://scipy.org/scipy/scipy/ticket/475
http://scipy.org/scipy/scipy/ticket/648
http://scipy.org/scipy/scipy/ticket/650

scipy.sparse
http://scipy.org/scipy/scipy/ticket/226
http://scipy.org/scipy/scipy/ticket/639
http://scipy.org/scipy/scipy/ticket/658
http://scipy.org/scipy/scipy/ticket/668

scipy.sparse.linalg
http://scipy.org/scipy/scipy/ticket/18
http://scipy.org/scipy/scipy/ticket/231
http://scipy.org/scipy/scipy/ticket/261
http://scipy.org/scipy/scipy/ticket/358
http://scipy.org/scipy/scipy/ticket/418
http://scipy.org/scipy/scipy/ticket/452

scipy.special
http://scipy.org/scipy/scipy/ticket/582
http://scipy.org/scipy/scipy/ticket/610

Nils



  


From nwagner at iam.uni-stuttgart.de  Sat Jun 21 08:07:59 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Sat, 21 Jun 2008 14:07:59 +0200
Subject: [SciPy-dev] Status of numexpr
Message-ID: <web-103640952@uni-stuttgart.de>

Hi David,

there are still some tickets related to numexpr.
However numexpr moved to 
 http://code.google.com/p/numexpr/
Am I missing something ?

Nils




From stefan at sun.ac.za  Sun Jun 22 17:55:49 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 22 Jun 2008 23:55:49 +0200
Subject: [SciPy-dev] Tickets list is working again
Message-ID: <9457e7c80806221455p4131e5edo41e8fec1c750e974@mail.gmail.com>

Changes to tickets and the SciPy/NumPy source are available on mailing
lists, to which you may subscribe here:

http://www.scipy.org/Mailing_Lists

To whomever fixed it, a great big thank you!

Regards
St?fan


From helias at bccn.uni-freiburg.de  Mon Jun 23 04:19:59 2008
From: helias at bccn.uni-freiburg.de (Moritz Helias)
Date: Mon, 23 Jun 2008 10:19:59 +0200
Subject: [SciPy-dev] Enhancements was Re:  0.7 release schedule
In-Reply-To: <web-103640589@uni-stuttgart.de>
References: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>
	<485B20B7.9040002@ar.media.kyoto-u.ac.jp>
	<d05265cb0806192119k2ba5f40bw982f10840722b5f4@mail.gmail.com>
	<485B2D68.1020708@ar.media.kyoto-u.ac.jp>
	<web-103617420@uni-stuttgart.de>
	<485CAA19.8050504@ar.media.kyoto-u.ac.jp>
	<web-103635529@uni-stuttgart.de>
	<485CC2D1.4030300@ar.media.kyoto-u.ac.jp>
	<web-103638904@uni-stuttgart.de> <web-103640589@uni-stuttgart.de>
Message-ID: <F92262F6-56A4-4997-A230-AF64F7B12DB6@bccn.uni-freiburg.de>

Hi,

could you please also consider ticket #659?
The attached patch solves the problem. You may also use the attached  
test script hyp1f1_test.py to verify the patch.
Thank you!

Best,

Moritz


On Jun 21, 2008, at 1:46 PM, Nils Wagner wrote:

> On Sat, 21 Jun 2008 12:30:13 +0200
>  "Nils Wagner" <nwagner at iam.uni-stuttgart.de> wrote:
>> On Sat, 21 Jun 2008 17:58:57 +0900
>> David Cournapeau <david at ar.media.kyoto-u.ac.jp> wrote:
>>> Nils Wagner wrote:
>>>>
>>>> David,
>>>>
>>>> Okay, here are some pending tickets.
>>>>
>>>> http://projects.scipy.org/scipy/scipy/ticket/591
>>>> can be closed. It is fixed in svn.
>>>>
>>>> The patch attached to
>>>>
>>>> http://projects.scipy.org/scipy/scipy/ticket/593
>>>>
>>>> works for me. IMHO the ticket #593 can be closed, when
>>>> the patch is applied in the trunk. However a test would
>>>> be nice.
>>>>
>>>> Duplicate of ticket #641
>>>> http://projects.scipy.org/scipy/scipy/ticket/642
>>>>
>>>> #647 and #648 can be combined.
>>>>
>>>> #662, #663, #664, #665 are duplicates
>>>>
>>>> #672, #673, #674 are duplicates
>>>>
>>>
>>> Thanks, I closed the dup, and also added a report on
>>> scipy trac to track
>>> open tickets with attachments (I have not taken a look
>>> at 593).
>>>
>>>> P.S. There are still some annoying test errors/failures
>>>> in
>>>> current svn
>>>>
>>>
>>> Yes. I may take a look at some of those later today,
>>>
>>> cheers,
>>>
>>> David
>>>
>>> _______________________________________________
>>> Scipy-dev mailing list
>>> Scipy-dev at scipy.org
>>> http://projects.scipy.org/mailman/listinfo/scipy-dev
>>
>> David,
>>
>> Tickets #499 and #525 seem to be correlated as well.
>> See
>> http://scipy.org/scipy/scipy/ticket/525
>> http://scipy.org/scipy/scipy/ticket/499
>>
>> IMHO
>> http://scipy.org/scipy/scipy/ticket/308
>> can be closed. numexpr is now a stand-alone project.
>>
>> Ticket 591
>> http://scipy.org/scipy/scipy/ticket/591
>> can be closed.
>>
>> Nils
>> _______________________________________________
>> Scipy-dev mailing list
>> Scipy-dev at scipy.org
>> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
> IMHO, ticket 670 is invalid.
> http://scipy.org/scipy/scipy/ticket/670
>
> And there are many enhancements (see the list below)
>
> Other
> http://scipy.org/scipy/scipy/ticket/674
> http://scipy.org/scipy/scipy/ticket/669
> http://scipy.org/scipy/scipy/ticket/651
> http://scipy.org/scipy/scipy/ticket/635
> http://scipy.org/scipy/scipy/ticket/634
> http://scipy.org/scipy/scipy/ticket/628
> http://scipy.org/scipy/scipy/ticket/608
> http://scipy.org/scipy/scipy/ticket/562
> http://scipy.org/scipy/scipy/ticket/448
> http://scipy.org/scipy/scipy/ticket/330
>
> scipy.cluster
> http://scipy.org/scipy/scipy/ticket/612
> http://scipy.org/scipy/scipy/ticket/426
>
> scipy.fftpack
> http://scipy.org/scipy/scipy/ticket/474
> http://scipy.org/scipy/scipy/ticket/268
>
> scipy.integrate
> http://scipy.org/scipy/scipy/ticket/615
> http://scipy.org/scipy/scipy/ticket/597
> http://scipy.org/scipy/scipy/ticket/478
> http://scipy.org/scipy/scipy/ticket/291
>
> scipy.interpolate
> http://scipy.org/scipy/scipy/ticket/206
> http://scipy.org/scipy/scipy/ticket/286
> http://scipy.org/scipy/scipy/ticket/305
> http://scipy.org/scipy/scipy/ticket/687
>
> scipy.io
> http://scipy.org/scipy/scipy/ticket/354
>
> scipy.linalg
> http://scipy.org/scipy/scipy/ticket/354
> http://scipy.org/scipy/scipy/ticket/456
> http://scipy.org/scipy/scipy/ticket/632
>
> scipy.misc
> http://scipy.org/scipy/scipy/ticket/564
> http://scipy.org/scipy/scipy/ticket/675
>
> scipy.optimize
> http://scipy.org/scipy/scipy/ticket/285
>
> scipy.signal
> http://scipy.org/scipy/scipy/ticket/386
> http://scipy.org/scipy/scipy/ticket/457
> http://scipy.org/scipy/scipy/ticket/475
> http://scipy.org/scipy/scipy/ticket/648
> http://scipy.org/scipy/scipy/ticket/650
>
> scipy.sparse
> http://scipy.org/scipy/scipy/ticket/226
> http://scipy.org/scipy/scipy/ticket/639
> http://scipy.org/scipy/scipy/ticket/658
> http://scipy.org/scipy/scipy/ticket/668
>
> scipy.sparse.linalg
> http://scipy.org/scipy/scipy/ticket/18
> http://scipy.org/scipy/scipy/ticket/231
> http://scipy.org/scipy/scipy/ticket/261
> http://scipy.org/scipy/scipy/ticket/358
> http://scipy.org/scipy/scipy/ticket/418
> http://scipy.org/scipy/scipy/ticket/452
>
> scipy.special
> http://scipy.org/scipy/scipy/ticket/582
> http://scipy.org/scipy/scipy/ticket/610
>
> Nils
>
>
>
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev



From alexandre.fayolle at logilab.fr  Mon Jun 23 06:51:15 2008
From: alexandre.fayolle at logilab.fr (Alexandre Fayolle)
Date: Mon, 23 Jun 2008 12:51:15 +0200
Subject: [SciPy-dev] mpi4py page defaced by spambots
Message-ID: <20080623105115.GP11355@logilab.fr>

Hi,

I've just noticed http://mpi4py.scipy.org/ has been defaced by spammers.
The recent changes link show that other pages have suffered too over the
past few days. 

It looks like setting up a catcha or something could improve the
situation. 

-- 
Alexandre Fayolle                              LOGILAB, Paris (France)
Formations Python, Zope, Plone, Debian:  http://www.logilab.fr/formations
D?veloppement logiciel sur mesure:       http://www.logilab.fr/services
Informatique scientifique:               http://www.logilab.fr/science
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 481 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080623/177e6e24/attachment.sig>

From david at ar.media.kyoto-u.ac.jp  Mon Jun 23 09:30:50 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Mon, 23 Jun 2008 22:30:50 +0900
Subject: [SciPy-dev] Tickets list is working again
In-Reply-To: <9457e7c80806221455p4131e5edo41e8fec1c750e974@mail.gmail.com>
References: <9457e7c80806221455p4131e5edo41e8fec1c750e974@mail.gmail.com>
Message-ID: <485FA58A.1010505@ar.media.kyoto-u.ac.jp>

St?fan van der Walt wrote:
> Changes to tickets and the SciPy/NumPy source are available on mailing
> lists, to which you may subscribe here:
>
> http://www.scipy.org/Mailing_Lists
>
> To whomever fixed it, a great big thank you!
>   

Where do you see it working, Stefan ? It still does not work for me, and
the ML archive for scipy at least is empty for June....

cheers,

David


From david at ar.media.kyoto-u.ac.jp  Mon Jun 23 11:08:26 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Tue, 24 Jun 2008 00:08:26 +0900
Subject: [SciPy-dev] 0.7 release schedule
In-Reply-To: <web-103638904@uni-stuttgart.de>
References: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>	<485B20B7.9040002@ar.media.kyoto-u.ac.jp>	<d05265cb0806192119k2ba5f40bw982f10840722b5f4@mail.gmail.com>	<485B2D68.1020708@ar.media.kyoto-u.ac.jp>	<web-103617420@uni-stuttgart.de>	<485CAA19.8050504@ar.media.kyoto-u.ac.jp>	<web-103635529@uni-stuttgart.de>	<485CC2D1.4030300@ar.media.kyoto-u.ac.jp>
	<web-103638904@uni-stuttgart.de>
Message-ID: <485FBC6A.604@ar.media.kyoto-u.ac.jp>

Nils Wagner wrote:
>   
> David,
>
> Tickets #499 and #525 seem to be correlated as well.
> See
> http://scipy.org/scipy/scipy/ticket/525
> http://scipy.org/scipy/scipy/ticket/499
>
> IMHO
> http://scipy.org/scipy/scipy/ticket/308
> can be closed. numexpr is now a stand-alone project.
>
> Ticket 591
> http://scipy.org/scipy/scipy/ticket/591
> can be closed.
>
>   

Ok, thanks for all this, Nils, this is really helpful. I have also
pushed some non trivial enhancement to 0.8, we are down to 144.
Unfortunately, scipy trac is not really responsive ATM, and trac is not
convenient to triage bugs (there is no way to filter/set up bugs wo
writing some SQL, what a pain).

Time to go to bed for me, but if other people could spend some more time
to triage 0.7 bugs, this would be helpful.

cheers,

David


From mhearne at usgs.gov  Mon Jun 23 11:23:50 2008
From: mhearne at usgs.gov (Michael Hearne)
Date: Mon, 23 Jun 2008 09:23:50 -0600
Subject: [SciPy-dev] Building numpy/scipy on RHEL5 OR CentOS5
Message-ID: <485FC006.609@usgs.gov>

I've been wrestling with installing scipy (in any form - binary, source, 
egg, rpm) on some RHEL5 machines that I am compelled to work with, and 
have failed miserably.   I noticed a thread a few months back about 
building scipy on CentOS 5, and noticed that at least one of the 
respondents indicated he'd had success.  As I understand it, CentOS 
strives for binary compatibility with RHEL, so I'm hopeful that CentOS 
solutions will work for me.

Does anyone have (in order of preference):
1) A CentOS/RHEL5 yum repository for scipy/numpy/(optionally matplotlib)
2) CentOS/RHEL5 RPM's for scipy/numpy/(optionally matplotlib)
3) A set of instructions for building scipy from source on either of 
these platforms?

I'm getting a little desperate here - this is likely one of the  most 
difficult installs I've ever had to deal with.

Thanks,

Mike

-- 
------------------------------------------------------
Michael Hearne
mhearne at usgs.gov
(303) 273-8620
USGS National Earthquake Information Center
1711 Illinois St. Golden CO 80401
Senior Software Engineer
Synergetics, Inc.
------------------------------------------------------



From robert.kern at gmail.com  Mon Jun 23 11:24:52 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 23 Jun 2008 10:24:52 -0500
Subject: [SciPy-dev] mpi4py page defaced by spambots
In-Reply-To: <20080623105115.GP11355@logilab.fr>
References: <20080623105115.GP11355@logilab.fr>
Message-ID: <3d375d730806230824p53a423ddmfb2d1167cf3e5a75@mail.gmail.com>

On Mon, Jun 23, 2008 at 05:51, Alexandre Fayolle
<alexandre.fayolle at logilab.fr> wrote:
> Hi,
>
> I've just noticed http://mpi4py.scipy.org/ has been defaced by spammers.
> The recent changes link show that other pages have suffered too over the
> past few days.
>
> It looks like setting up a catcha or something could improve the
> situation.

The antispam situation for MoinMoin is unfortunately pretty bleak. On
www.scipy.org, I've been manually removing spam as it comes up with a
custom banned user regex list to help out.

-- 
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 phaustin at gmail.com  Mon Jun 23 12:50:37 2008
From: phaustin at gmail.com (Phil Austin)
Date: Mon, 23 Jun 2008 09:50:37 -0700
Subject: [SciPy-dev] Building numpy/scipy on RHEL5 OR CentOS5
In-Reply-To: <485FC006.609@usgs.gov>
References: <485FC006.609@usgs.gov>
Message-ID: <485FD45D.1040101@gmail.com>

Michael Hearne wrote:
> I've been wrestling with installing scipy (in any form - binary, source, 
> egg, rpm) on some RHEL5 machines that I am compelled to work with, and 
> have failed miserably.   I noticed a thread a few months back about 
> building scipy on CentOS 5, and noticed that at least one of the 
> respondents indicated he'd had success.  As I understand it, CentOS 
> strives for binary compatibility with RHEL, so I'm hopeful that CentOS 
> solutions will work for me.
> 

I do this pretty regularly with numpy/scipy/matplotlib from svn
for Centos 5.1 on x86_64.  I build ATLAS and lapack from scratch
but use the fftw3 rpms

~ phil at owl% rpm -qa | grep fftw3
fftw3-3.1.1-1.el5.rf
fftw3-devel-3.1.1-1.el5.rf

The major problem I encountered compared to earlier builds with
Mandrake was the fact that 'fPIC' needs to be explicitly passed
to every fortran, C and C++ compiler call.  There is a bug in
the lapack makefile, for example, that drops 'fPIC' from 4 lapack
compile statements (out of hundreds) and these have to
recompiled by hand  (See step 3 below).

The following is a cut and paste from a fairly disorganized set
of notes.

1) build python

export CPPFLAGS='-fPIC'
export CFLAGS='-fPIC'
export FFLAGS='-fPIC'

./configure --prefix=/users/user-soft/usr251_Centos

make install

2) build ATLAS

mkdir build
cd build
/home/datatmp/phil/install/ATLAS/mybuild phil at owl% \
../configure --prefix=/home/phil/usr251_Centos \
        --cflags='-fPIC'  -Fa alg -fPIC

make install

3) build LAPACK

for lapack: cp INSTALL/make.inc.LINUX  ~/install/lapack-3.1.1/make.inc
and edit:

FORTRAN  = gfortran
OPTS     = -funroll-all-loops -O3 -fPIC
DRVOPTS  = $(OPTS)
NOOPT    =
LOADER   = gfortran
LOADOPTS =

BLASLIB      = /home/phil/usr251_Centos/lib/libcblas.a
LAPACKLIB    = lapack$(PLAT).a
TMGLIB       = tmglib$(PLAT).a
EIGSRCLIB    = eigsrc$(PLAT).a
LINSRCLIB    = linsrc$(PLAT).a

!!and then rebuild these individual routines with fPIC -- recompile!

~/install/transport/lapack-3.1.1/SRC
gfortran  -fPIC  -c slaruv.f -o slaruv.o
gfortran -fPIC -c dlaruv.f -o dlaruv.o

~/install/transport/lapack-3.1.1/INSTALL

gfortran -fPIC -c slamch.f -o slamch.o
gfortran  -fPIC -c dlamch.f -o dlamch.o
gfortran  -fPIC -o testieee tstiee.o

make liblapack
make libblas  then
make all  -- to build vanilla blas and testing
make lapack_install -- to get statistics

Now merge ATLAS and lapack:

cd /home/datatmp/phil/install/ATLAS/mybuild/lib

     cp liblapack.a liblapack_orig.a
     mkdir tmp; cd tmp
     ar x ../liblapack.a
     cp ~/install/transport/lapack-3.1.1/lapack_LINUX.a ../liblapack.a
     ar r ../liblapack.a *.o
     cd ..; rm -rf tmp
     cp liblapack.a /home/phil/usr251_Centos/lib/


and

cp lapack_LINUX.a /home/phil/usr251_Centos/lib/liblapack.a
cp blas_LINUX.a /home/phil/usr251_Centos/lib/libblas.a

the edit numpy site.cfg and add the library locations:

[atlas]
# system_info.py searches atlas and lapack from the following paths
#   library_dir:DEFAULT/atlas*:DEFAULT/ATLAS*:DEFAULT
# where DEFAULT refers to library_dir defined in [DEFAULT] section and
#library_dirs = /usr/lib/3dnow      # Debian Sid
library_dirs = /home/phil/usr251_Centos/lib

# For overriding the names of the atlas libraries:
# atlas_libs = lapack, f77blas, cblas, atlas

[lapack]
library_dirs = /home/phil/usr251_Centos/lib

[lapack_src]
src_dirs = /home/phil/install/transport/lapack-3.1.1/SRC

[blas]
library_dirs = /home/phil/usr251_Centos/lib

[blas_src]
src_dirs = /home/datatmp/phil/install/ATLAS/src/blas

[fftw3]
library_dirs = /usr/lib64/
fftw_libs = fftw3
#fftw_opt_libs = fftw_threaded, rfftw_threaded
# if the above aren't found, look for {s,d}fftw_libs and {s,d}fftw_opt_libs



4) build numpy

python setup.py build --fcompiler=gnu95
python setup.py install --fcompiler=gnu95  install

make sure site.cfg has been copied to

/home/phil/usr251_Centos/lib/python2.5/site-packages\
   /numpy/distutils/site.cfg


5) build scipy

python setup.py build --fcompiler=gnu95
python setup.py install --fcompiler=gnu95  install




From nwagner at iam.uni-stuttgart.de  Mon Jun 23 13:06:05 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Mon, 23 Jun 2008 19:06:05 +0200
Subject: [SciPy-dev] 0.7 release schedule
In-Reply-To: <485FBC6A.604@ar.media.kyoto-u.ac.jp>
References: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>
	<485B20B7.9040002@ar.media.kyoto-u.ac.jp>
	<d05265cb0806192119k2ba5f40bw982f10840722b5f4@mail.gmail.com>
	<485B2D68.1020708@ar.media.kyoto-u.ac.jp>
	<web-103617420@uni-stuttgart.de>
	<485CAA19.8050504@ar.media.kyoto-u.ac.jp>
	<web-103635529@uni-stuttgart.de>
	<485CC2D1.4030300@ar.media.kyoto-u.ac.jp>
	<web-103638904@uni-stuttgart.de>
	<485FBC6A.604@ar.media.kyoto-u.ac.jp>
Message-ID: <web-103723597@uni-stuttgart.de>

On Tue, 24 Jun 2008 00:08:26 +0900
  David Cournapeau <david at ar.media.kyoto-u.ac.jp> wrote:
> Nils Wagner wrote:
>>   
>> David,
>>
>> Tickets #499 and #525 seem to be correlated as well.
>> See
>> http://scipy.org/scipy/scipy/ticket/525
>> http://scipy.org/scipy/scipy/ticket/499
>>
>> IMHO
>> http://scipy.org/scipy/scipy/ticket/308
>> can be closed. numexpr is now a stand-alone project.
>>
>> Ticket 591
>> http://scipy.org/scipy/scipy/ticket/591
>> can be closed.
>>
>>   
> 
> Ok, thanks for all this, Nils, this is really helpful. I 
>have also
> pushed some non trivial enhancement to 0.8, we are down 
>to 144.
> Unfortunately, scipy trac is not really responsive ATM, 
>and trac is not
> convenient to triage bugs (there is no way to filter/set 
>up bugs wo
> writing some SQL, what a pain).
> 
> Time to go to bed for me, but if other people could 
>spend some more time
> to triage 0.7 bugs, this would be helpful.
> 
> cheers,
> 
> David 

Hi David,

Just now I installed scipy '0.7.0.dev4465'

There is a new error

======================================================================
ERROR: test_mio.test_gzip_simple
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"/usr/lib/python2.4/site-packages/nose-0.10.3-py2.4.egg/nose/case.py", 
line 182, in runTest
     self.test(*self.arg)
   File 
"/usr/lib/python2.4/site-packages/scipy/io/matlab/tests/test_mio.py", 
line 263, in test_gzip_simple
     actual = loadmat(mat_stream)
   File 
"/usr/lib/python2.4/site-packages/scipy/io/matlab/mio.py", 
line 96, in loadmat
     matfile_dict = MR.get_variables()
   File 
"/usr/lib/python2.4/site-packages/scipy/io/matlab/miobase.py", 
line 270, in get_variables
     getter = self.matrix_getter_factory()
   File 
"/usr/lib/python2.4/site-packages/scipy/io/matlab/mio4.py", 
line 199, in matrix_getter_factory
     return self._array_reader.matrix_getter_factory()
   File 
"/usr/lib/python2.4/site-packages/scipy/io/matlab/mio4.py", 
line 66, in matrix_getter_factory
     header['name'] = self.read_ztstring(data['namlen'])
   File 
"/usr/lib/python2.4/site-packages/scipy/io/matlab/miobase.py", 
line 81, in read_ztstring
     return self.mat_stream.read(num_bytes).strip('\x00')
   File "/usr/lib/python2.4/gzip.py", line 230, in read
     chunk = self.extrabuf[:size]
TypeError: slice indices must be integers

beside the well known eror(s)

======================================================================
ERROR: test_huber (test_scale.TestScale)
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"/usr/lib/python2.4/site-packages/scipy/stats/models/tests/test_scale.py", 
line 35, in test_huber
     m = scale.huber(X)
   File 
"/usr/lib/python2.4/site-packages/scipy/stats/models/robust/scale.py", 
line 82, in __call__
     for donothing in self:
   File 
"/usr/lib/python2.4/site-packages/scipy/stats/models/robust/scale.py", 
line 102, in next
     scale = N.sum(subset * (a - mu)**2, axis=self.axis) / 
(self.n * Huber.gamma - N.sum(1. - subset, axis=self.axis) 
* Huber.c**2)
   File 
"/usr/lib/python2.4/site-packages/numpy/core/fromnumeric.py", 
line 1007, in sum
     return sum(axis, dtype, out)
TypeError: only length-1 arrays can be converted to Python 
scalars

Two failures are still present

======================================================================
FAIL: test_imresize (test_pilutil.TestPILUtil)
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"/usr/lib/python2.4/site-packages/scipy/testing/decorators.py", 
line 81, in skipper
     return f(*args, **kwargs)
   File 
"/usr/lib/python2.4/site-packages/scipy/misc/tests/test_pilutil.py", 
line 25, in test_imresize
     assert_equal(im1.shape,(11,22))
   File 
"/usr/lib/python2.4/site-packages/numpy/testing/utils.py", 
line 137, in assert_equal
     assert_equal(len(actual),len(desired),err_msg,verbose)
   File 
"/usr/lib/python2.4/site-packages/numpy/testing/utils.py", 
line 145, in assert_equal
     assert desired == actual, msg
AssertionError:
Items are not equal:
  ACTUAL: 0
  DESIRED: 2

======================================================================
FAIL: test_namespace (test_formula.TestFormula)
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"/usr/lib/python2.4/site-packages/scipy/stats/models/tests/test_formula.py", 
line 119, in test_namespace
     self.assertEqual(xx.namespace, Y.namespace)
AssertionError: {} != {'Y': array([ 0,  2,  4,  6,  8, 10, 
12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 
40,
        42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 64, 
66, 68, 70, 72, 74, 76, 78, 80, 82,
        84, 86, 88, 90, 92, 94, 96, 98]), 'X': array([ 0, 
 1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11, 12, 13, 14, 
15, 16, 17, 18, 19, 20,
        21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 
33, 34, 35, 36, 37, 38, 39, 40, 41,
        42, 43, 44, 45, 46, 47, 48, 49])}

----------------------------------------------------------------------

I am looking forward to a new scipy release.

http://projects.scipy.org/scipy/scipy/query?status=new&status=assigned&status=reopened&milestone=0.7

Nils



From pav at iki.fi  Mon Jun 23 13:47:48 2008
From: pav at iki.fi (Pauli Virtanen)
Date: Mon, 23 Jun 2008 17:47:48 +0000 (UTC)
Subject: [SciPy-dev] mpi4py page defaced by spambots
References: <20080623105115.GP11355@logilab.fr>
	<3d375d730806230824p53a423ddmfb2d1167cf3e5a75@mail.gmail.com>
Message-ID: <g3onk4$q9h$1@ger.gmane.org>

Mon, 23 Jun 2008 10:24:52 -0500, Robert Kern wrote:

> On Mon, Jun 23, 2008 at 05:51, Alexandre Fayolle
> <alexandre.fayolle at logilab.fr> wrote:
>> Hi,
>>
>> I've just noticed http://mpi4py.scipy.org/ has been defaced by
>> spammers. The recent changes link show that other pages have suffered
>> too over the past few days.
>>
>> It looks like setting up a catcha or something could improve the
>> situation.
> 
> The antispam situation for MoinMoin is unfortunately pretty bleak. On
> www.scipy.org, I've been manually removing spam as it comes up with a
> custom banned user regex list to help out.

Moin 1.6 has a captcha ("textcha") system [1], which might help here.

[1] http://moinmo.in/HelpOnTextChas

-- 
Pauli Virtanen



From nwagner at iam.uni-stuttgart.de  Mon Jun 23 13:57:53 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Mon, 23 Jun 2008 19:57:53 +0200
Subject: [SciPy-dev] 0.7 release schedule
In-Reply-To: <485FBC6A.604@ar.media.kyoto-u.ac.jp>
References: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>
	<485B20B7.9040002@ar.media.kyoto-u.ac.jp>
	<d05265cb0806192119k2ba5f40bw982f10840722b5f4@mail.gmail.com>
	<485B2D68.1020708@ar.media.kyoto-u.ac.jp>
	<web-103617420@uni-stuttgart.de>
	<485CAA19.8050504@ar.media.kyoto-u.ac.jp>
	<web-103635529@uni-stuttgart.de>
	<485CC2D1.4030300@ar.media.kyoto-u.ac.jp>
	<web-103638904@uni-stuttgart.de>
	<485FBC6A.604@ar.media.kyoto-u.ac.jp>
Message-ID: <web-103725579@uni-stuttgart.de>

On Tue, 24 Jun 2008 00:08:26 +0900
  David Cournapeau <david at ar.media.kyoto-u.ac.jp> wrote:
> Nils Wagner wrote:
>>   
>> David,
>>
>> Tickets #499 and #525 seem to be correlated as well.
>> See
>> http://scipy.org/scipy/scipy/ticket/525
>> http://scipy.org/scipy/scipy/ticket/499
>>
>> IMHO
>> http://scipy.org/scipy/scipy/ticket/308
>> can be closed. numexpr is now a stand-alone project.
>>
>> Ticket 591
>> http://scipy.org/scipy/scipy/ticket/591
>> can be closed.
>>
>>   
> 
> Ok, thanks for all this, Nils, this is really helpful. I 
>have also
> pushed some non trivial enhancement to 0.8, we are down 
>to 144.
> Unfortunately, scipy trac is not really responsive ATM, 
>and trac is not
> convenient to triage bugs (there is no way to filter/set 
>up bugs wo
> writing some SQL, what a pain).
> 
> Time to go to bed for me, but if other people could 
>spend some more time
> to triage 0.7 bugs, this would be helpful.
> 
> cheers,
> 
> David
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
  
David,

I looked through the remaining tickets

http://scipy.org/scipy/scipy/ticket/308 can be closed.
Invalid.
http://scipy.org/scipy/scipy/ticket/414 can be closed.
Invalid.

http://scipy.org/scipy/scipy/ticket/653 belongs to 
scipy.io

http://scipy.org/scipy/scipy/ticket/641 belongs to 
scipy.optimize

http://scipy.org/scipy/scipy/ticket/628 belongs to 
scipy.signal
http://scipy.org/scipy/scipy/ticket/651 belongs to
scipy.signal
http://scipy.org/scipy/scipy/ticket/577 belongs to 
scipy.signal

http://scipy.org/scipy/scipy/ticket/497 belongs to 
scipy.stats

Cheers,
            Nils



From nwagner at iam.uni-stuttgart.de  Mon Jun 23 14:22:36 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Mon, 23 Jun 2008 20:22:36 +0200
Subject: [SciPy-dev] More tickets
Message-ID: <web-103726369@uni-stuttgart.de>

Hi all,

who can report/comment on the status of the following 
tickets ?

http://scipy.org/scipy/scipy/ticket/484
http://scipy.org/scipy/scipy/ticket/500
http://scipy.org/scipy/scipy/ticket/448
http://scipy.org/scipy/scipy/ticket/353


Nils

http://scipy.org/scipy/scipy/ticket/376 is invalid.
delaunay is a scikits package.









From stefan at sun.ac.za  Mon Jun 23 15:37:00 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 23 Jun 2008 21:37:00 +0200
Subject: [SciPy-dev] Tickets list is working again
In-Reply-To: <485FA58A.1010505@ar.media.kyoto-u.ac.jp>
References: <9457e7c80806221455p4131e5edo41e8fec1c750e974@mail.gmail.com>
	<485FA58A.1010505@ar.media.kyoto-u.ac.jp>
Message-ID: <9457e7c80806231237k18a1ec5bped906d5193902c9@mail.gmail.com>

2008/6/23 David Cournapeau <david at ar.media.kyoto-u.ac.jp>:
> St?fan van der Walt wrote:
>> Changes to tickets and the SciPy/NumPy source are available on mailing
>> lists, to which you may subscribe here:
>>
>> http://www.scipy.org/Mailing_Lists
>>
>> To whomever fixed it, a great big thank you!
>>
>
> Where do you see it working, Stefan ? It still does not work for me, and
> the ML archive for scipy at least is empty for June....

Where is the archive for the June archive?  I have received a number
of e-mails, but it could be that I was subscribed to those tickets
specifically.

Regards
St?fan


From abhikshah at gmail.com  Mon Jun 23 17:08:38 2008
From: abhikshah at gmail.com (Abhik Shah)
Date: Mon, 23 Jun 2008 17:08:38 -0400
Subject: [SciPy-dev] BayesNet SciKit?
Message-ID: <823e60360806231408m5e556c3cj198f6cf5c258d214@mail.gmail.com>

Hi,
   I'm the author of pebl [http://pebl-project.googlecode.com] a Bayes
net structure learning package. I see that pebl is already listed on
the BayesNet SciKit page on Trac as related software. I am interested
in integrating pebl into SciPy and can offer some development time
(with the usual caveats about needing to work on dissertation, etc).
Is there a separate list for the BayesNet SciKit development?

As I see it, OpenBayes and pbnt are primarily focused on parameter
learning and inference while pebl focuses solely on structure
learning... so their aims are nicely orthogonal and integrating them
shouldn't be too difficult.

Thanks,
Abhik.


From pav at iki.fi  Mon Jun 23 17:26:02 2008
From: pav at iki.fi (Pauli Virtanen)
Date: Mon, 23 Jun 2008 21:26:02 +0000 (UTC)
Subject: [SciPy-dev] Enhancements was Re:  0.7 release schedule
References: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>
	<485B20B7.9040002@ar.media.kyoto-u.ac.jp>
	<d05265cb0806192119k2ba5f40bw982f10840722b5f4@mail.gmail.com>
	<485B2D68.1020708@ar.media.kyoto-u.ac.jp>
	<web-103617420@uni-stuttgart.de>
	<485CAA19.8050504@ar.media.kyoto-u.ac.jp>
	<web-103635529@uni-stuttgart.de>
	<485CC2D1.4030300@ar.media.kyoto-u.ac.jp>
	<web-103638904@uni-stuttgart.de> <web-103640589@uni-stuttgart.de>
Message-ID: <g3p4da$q9h$5@ger.gmane.org>

Sat, 21 Jun 2008 13:46:34 +0200, Nils Wagner wrote:
[clip]
> scipy.integrate
> http://scipy.org/scipy/scipy/ticket/597

This is a documentation fix. I committed now the patch I had submitted. 
The ticket can be closed.

> scipy.interpolate
> http://scipy.org/scipy/scipy/ticket/206

This adds a wrapper for dblint from Dierckx's fitpack. I committed the 
patch I had submitted (including testcases). I think this ticket can be 
closed.

-- 
Pauli Virtanen



From pav at iki.fi  Mon Jun 23 18:17:23 2008
From: pav at iki.fi (Pauli Virtanen)
Date: Mon, 23 Jun 2008 22:17:23 +0000 (UTC)
Subject: [SciPy-dev] 0.7 release schedule
References: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>
	<485B20B7.9040002@ar.media.kyoto-u.ac.jp>
	<d05265cb0806192119k2ba5f40bw982f10840722b5f4@mail.gmail.com>
	<485B2D68.1020708@ar.media.kyoto-u.ac.jp>
	<web-103617420@uni-stuttgart.de>
	<485CAA19.8050504@ar.media.kyoto-u.ac.jp>
Message-ID: <g3p7dj$q9i$1@ger.gmane.org>

Sat, 21 Jun 2008 16:13:29 +0900, David Cournapeau wrote:

> Nils Wagner wrote:
>>
>> There are lots of duplicate tickets, e.g.
>> http://projects.scipy.org/scipy/scipy/ticket/672
>>
>> IIRC, some tickets can be closed already since they have been fixed in
>> svn.
>>
>> Unfortunately, I can't close tickets so far.
>>   
>>   
> If you give the ticket numbers, most of the job would be done, and
> someone (me) could triage and close them accordingly.

Still more:

http://scipy.org/scipy/scipy/ticket/376
	Can be closed: bug/feature in scikits.delaunay
        (Now #61 in scikits trac)

-- 
Pauli Virtanen



From wnbell at gmail.com  Mon Jun 23 20:05:47 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Mon, 23 Jun 2008 19:05:47 -0500
Subject: [SciPy-dev] 0.7 release schedule
In-Reply-To: <web-103725579@uni-stuttgart.de>
References: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>
	<d05265cb0806192119k2ba5f40bw982f10840722b5f4@mail.gmail.com>
	<485B2D68.1020708@ar.media.kyoto-u.ac.jp>
	<web-103617420@uni-stuttgart.de>
	<485CAA19.8050504@ar.media.kyoto-u.ac.jp>
	<web-103635529@uni-stuttgart.de>
	<485CC2D1.4030300@ar.media.kyoto-u.ac.jp>
	<web-103638904@uni-stuttgart.de> <485FBC6A.604@ar.media.kyoto-u.ac.jp>
	<web-103725579@uni-stuttgart.de>
Message-ID: <d05265cb0806231705q388b6534i33258f41a649d82c@mail.gmail.com>

On Mon, Jun 23, 2008 at 12:57 PM, Nils Wagner
<nwagner at iam.uni-stuttgart.de> wrote:
>
> I looked through the remaining tickets
>
> http://scipy.org/scipy/scipy/ticket/308 can be closed.
> Invalid.
> http://scipy.org/scipy/scipy/ticket/414 can be closed.
> Invalid.
>
> http://scipy.org/scipy/scipy/ticket/653 belongs to
> scipy.io
>
> http://scipy.org/scipy/scipy/ticket/641 belongs to
> scipy.optimize
>
> http://scipy.org/scipy/scipy/ticket/628 belongs to
> scipy.signal
> http://scipy.org/scipy/scipy/ticket/651 belongs to
> scipy.signal
> http://scipy.org/scipy/scipy/ticket/577 belongs to
> scipy.signal
>
> http://scipy.org/scipy/scipy/ticket/497 belongs to
> scipy.stats
>

Thanks for figuring these out Nils. I've updated the tickets.

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


From wnbell at gmail.com  Mon Jun 23 20:07:03 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Mon, 23 Jun 2008 19:07:03 -0500
Subject: [SciPy-dev] 0.7 release schedule
In-Reply-To: <g3p7dj$q9i$1@ger.gmane.org>
References: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>
	<485B20B7.9040002@ar.media.kyoto-u.ac.jp>
	<d05265cb0806192119k2ba5f40bw982f10840722b5f4@mail.gmail.com>
	<485B2D68.1020708@ar.media.kyoto-u.ac.jp>
	<web-103617420@uni-stuttgart.de>
	<485CAA19.8050504@ar.media.kyoto-u.ac.jp> <g3p7dj$q9i$1@ger.gmane.org>
Message-ID: <d05265cb0806231707r5ab66742j3bd9adc19aacd9@mail.gmail.com>

On Mon, Jun 23, 2008 at 5:17 PM, Pauli Virtanen <pav at iki.fi> wrote:
>
> Still more:
>
> http://scipy.org/scipy/scipy/ticket/376
>        Can be closed: bug/feature in scikits.delaunay
>        (Now #61 in scikits trac)
>

Done

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


From wnbell at gmail.com  Mon Jun 23 20:14:27 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Mon, 23 Jun 2008 19:14:27 -0500
Subject: [SciPy-dev] Enhancements was Re: 0.7 release schedule
In-Reply-To: <g3p4da$q9h$5@ger.gmane.org>
References: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>
	<d05265cb0806192119k2ba5f40bw982f10840722b5f4@mail.gmail.com>
	<485B2D68.1020708@ar.media.kyoto-u.ac.jp>
	<web-103617420@uni-stuttgart.de>
	<485CAA19.8050504@ar.media.kyoto-u.ac.jp>
	<web-103635529@uni-stuttgart.de>
	<485CC2D1.4030300@ar.media.kyoto-u.ac.jp>
	<web-103638904@uni-stuttgart.de> <web-103640589@uni-stuttgart.de>
	<g3p4da$q9h$5@ger.gmane.org>
Message-ID: <d05265cb0806231714n4b5a4405qb258369bd0b97c31@mail.gmail.com>

On Mon, Jun 23, 2008 at 4:26 PM, Pauli Virtanen <pav at iki.fi> wrote:
>> scipy.integrate
>> http://scipy.org/scipy/scipy/ticket/597
>
> This is a documentation fix. I committed now the patch I had submitted.
> The ticket can be closed.
>
>> scipy.interpolate
>> http://scipy.org/scipy/scipy/ticket/206
>
> This adds a wrapper for dblint from Dierckx's fitpack. I committed the
> patch I had submitted (including testcases). I think this ticket can be
> closed.
>

Done


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


From wnbell at gmail.com  Mon Jun 23 20:58:35 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Mon, 23 Jun 2008 19:58:35 -0500
Subject: [SciPy-dev] Enhancements was Re: 0.7 release schedule
In-Reply-To: <F92262F6-56A4-4997-A230-AF64F7B12DB6@bccn.uni-freiburg.de>
References: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>
	<d05265cb0806192119k2ba5f40bw982f10840722b5f4@mail.gmail.com>
	<485B2D68.1020708@ar.media.kyoto-u.ac.jp>
	<web-103617420@uni-stuttgart.de>
	<485CAA19.8050504@ar.media.kyoto-u.ac.jp>
	<web-103635529@uni-stuttgart.de>
	<485CC2D1.4030300@ar.media.kyoto-u.ac.jp>
	<web-103638904@uni-stuttgart.de> <web-103640589@uni-stuttgart.de>
	<F92262F6-56A4-4997-A230-AF64F7B12DB6@bccn.uni-freiburg.de>
Message-ID: <d05265cb0806231758u97a0c1aq3ce3cffd188e10e@mail.gmail.com>

On Mon, Jun 23, 2008 at 3:19 AM, Moritz Helias
<helias at bccn.uni-freiburg.de> wrote:
> Hi,
>
> could you please also consider ticket #659?
> The attached patch solves the problem. You may also use the attached
> test script hyp1f1_test.py to verify the patch.
> Thank you!
>

Added in r4468

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


From david at ar.media.kyoto-u.ac.jp  Mon Jun 23 22:43:50 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Tue, 24 Jun 2008 11:43:50 +0900
Subject: [SciPy-dev] Building numpy/scipy on RHEL5 OR CentOS5
In-Reply-To: <485FC006.609@usgs.gov>
References: <485FC006.609@usgs.gov>
Message-ID: <48605F66.1090508@ar.media.kyoto-u.ac.jp>

Michael Hearne wrote:
> I've been wrestling with installing scipy (in any form - binary, source, 
> egg, rpm) on some RHEL5 machines that I am compelled to work with, and 
> have failed miserably.   I noticed a thread a few months back about 
> building scipy on CentOS 5, and noticed that at least one of the 
> respondents indicated he'd had success.  As I understand it, CentOS 
> strives for binary compatibility with RHEL, so I'm hopeful that CentOS 
> solutions will work for me.
>
> Does anyone have (in order of preference):
> 1) A CentOS/RHEL5 yum repository for scipy/numpy/(optionally matplotlib)
> 2) CentOS/RHEL5 RPM's for scipy/numpy/(optionally matplotlib)
> 3) A set of instructions for building scipy from source on either of 
> these platforms?
>
> I'm getting a little desperate here - this is likely one of the  most 
> difficult installs I've ever had to deal with.
>   
Hi Michael,

If you don't tell us more, we won't be able to help you much. Installing
numpy/scipy themselves is easy; their dependencies (BLAS/LAPACK) are
not. One problem I have with CENTOS/RHEL, contrary to most other
distributions, is the difficult to get an up-to-date list of available
packages. Would you know where to find it ?

Your two options are building from sources or binary packages:
    - from sources: you need BLAS/LAPACK, and make sure the same fortran
compiler is used for everything (g77 or gfortran; gfortran is best for
RHEL5, because that's the default one I believe).
    - from rpm: you could try ashigabou repositories

http://download.opensuse.org/repositories/home:/ashigabou/CentOS_5/

If it does not work, please let me know (I am the one who build the
packages, and will fix any problems with them).

cheers,

David


From david at ar.media.kyoto-u.ac.jp  Mon Jun 23 22:45:18 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Tue, 24 Jun 2008 11:45:18 +0900
Subject: [SciPy-dev] Building numpy/scipy on RHEL5 OR CentOS5
In-Reply-To: <485FD45D.1040101@gmail.com>
References: <485FC006.609@usgs.gov> <485FD45D.1040101@gmail.com>
Message-ID: <48605FBE.5090904@ar.media.kyoto-u.ac.jp>

Phil Austin wrote:
> 3) build LAPACK
>
> for lapack: cp INSTALL/make.inc.LINUX  ~/install/lapack-3.1.1/make.inc
> and edit:
>
> FORTRAN  = gfortran
> OPTS     = -funroll-all-loops -O3 -fPIC
> DRVOPTS  = $(OPTS)
> NOOPT    =
> LOADER   = gfortran
> LOADOPTS =
>
> BLASLIB      = /home/phil/usr251_Centos/lib/libcblas.a
> LAPACKLIB    = lapack$(PLAT).a
> TMGLIB       = tmglib$(PLAT).a
> EIGSRCLIB    = eigsrc$(PLAT).a
> LINSRCLIB    = linsrc$(PLAT).a
>
> !!and then rebuild these individual routines with fPIC -- recompile!
>   

You should put -fPIC to NOOPT and LOADOPTS instead: this will be more
reliable, as this way, -fPIC will be used for every source file

cheers,

David


From david at ar.media.kyoto-u.ac.jp  Mon Jun 23 22:49:42 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Tue, 24 Jun 2008 11:49:42 +0900
Subject: [SciPy-dev] Tickets list is working again
In-Reply-To: <9457e7c80806231237k18a1ec5bped906d5193902c9@mail.gmail.com>
References: <9457e7c80806221455p4131e5edo41e8fec1c750e974@mail.gmail.com>	<485FA58A.1010505@ar.media.kyoto-u.ac.jp>
	<9457e7c80806231237k18a1ec5bped906d5193902c9@mail.gmail.com>
Message-ID: <486060C6.1030906@ar.media.kyoto-u.ac.jp>

St?fan van der Walt wrote:
> Where is the archive for the June archive?  
>   

Well, that's what I meant: there is no June entry

cheers,

David



From david at ar.media.kyoto-u.ac.jp  Mon Jun 23 22:56:48 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Tue, 24 Jun 2008 11:56:48 +0900
Subject: [SciPy-dev] Enhancements was Re: 0.7 release schedule
In-Reply-To: <d05265cb0806231714n4b5a4405qb258369bd0b97c31@mail.gmail.com>
References: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>	<d05265cb0806192119k2ba5f40bw982f10840722b5f4@mail.gmail.com>	<485B2D68.1020708@ar.media.kyoto-u.ac.jp>	<web-103617420@uni-stuttgart.de>	<485CAA19.8050504@ar.media.kyoto-u.ac.jp>	<web-103635529@uni-stuttgart.de>	<485CC2D1.4030300@ar.media.kyoto-u.ac.jp>	<web-103638904@uni-stuttgart.de>
	<web-103640589@uni-stuttgart.de>	<g3p4da$q9h$5@ger.gmane.org>
	<d05265cb0806231714n4b5a4405qb258369bd0b97c31@mail.gmail.com>
Message-ID: <48606270.4090806@ar.media.kyoto-u.ac.jp>

Nathan Bell wrote:
>
> Done
>   

Hi Nathan,

    Would you mind taking a look at all bugs for 0.7 milestone related
to scipy.sparse; in particular, if you can't work quickly on
enhancements, I think pushing them for 0.8 should be fine. Since scipy
has not seen a release for a long time, I think we should focus primary
on bug fixes, specially for scipy.sparse which has seen so much
development since 0.6 thanks to you and others,

cheers,

David



From wnbell at gmail.com  Tue Jun 24 00:06:14 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Mon, 23 Jun 2008 23:06:14 -0500
Subject: [SciPy-dev] Enhancements was Re: 0.7 release schedule
In-Reply-To: <48606270.4090806@ar.media.kyoto-u.ac.jp>
References: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>
	<web-103617420@uni-stuttgart.de>
	<485CAA19.8050504@ar.media.kyoto-u.ac.jp>
	<web-103635529@uni-stuttgart.de>
	<485CC2D1.4030300@ar.media.kyoto-u.ac.jp>
	<web-103638904@uni-stuttgart.de> <web-103640589@uni-stuttgart.de>
	<g3p4da$q9h$5@ger.gmane.org>
	<d05265cb0806231714n4b5a4405qb258369bd0b97c31@mail.gmail.com>
	<48606270.4090806@ar.media.kyoto-u.ac.jp>
Message-ID: <d05265cb0806232106l1417262pb604d5f96ad839e1@mail.gmail.com>

On Mon, Jun 23, 2008 at 9:56 PM, David Cournapeau
<david at ar.media.kyoto-u.ac.jp> wrote:
>
>    Would you mind taking a look at all bugs for 0.7 milestone related
> to scipy.sparse; in particular, if you can't work quickly on
> enhancements, I think pushing them for 0.8 should be fine. Since scipy
> has not seen a release for a long time, I think we should focus primary
> on bug fixes, specially for scipy.sparse which has seen so much
> development since 0.6 thanks to you and others,
>

I've pushed the enhancements forward to the 0.8 milestone.

I don't know if/when I'll have time to resolve the remaining tickets
in sparse.linalg, but I would feel comfortable releasing it in its
current state.

Before attacking ticket #553 we should probably update our SuperLU
code in sparse.linalg.dsolve.  The version we have [2] is older than
but the most recent SuperLU 3.0 release [3].

[1] http://scipy.org/scipy/scipy/ticket/553
[2] http://scipy.org/scipy/scipy/browser/trunk/scipy/sparse/linalg/dsolve/SuperLU/README
[3] http://crd.lbl.gov/~xiaoye/SuperLU/

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


From robert.kern at gmail.com  Tue Jun 24 00:11:25 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 23 Jun 2008 23:11:25 -0500
Subject: [SciPy-dev] Enhancements was Re: 0.7 release schedule
In-Reply-To: <d05265cb0806232106l1417262pb604d5f96ad839e1@mail.gmail.com>
References: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>
	<485CAA19.8050504@ar.media.kyoto-u.ac.jp>
	<web-103635529@uni-stuttgart.de>
	<485CC2D1.4030300@ar.media.kyoto-u.ac.jp>
	<web-103638904@uni-stuttgart.de> <web-103640589@uni-stuttgart.de>
	<g3p4da$q9h$5@ger.gmane.org>
	<d05265cb0806231714n4b5a4405qb258369bd0b97c31@mail.gmail.com>
	<48606270.4090806@ar.media.kyoto-u.ac.jp>
	<d05265cb0806232106l1417262pb604d5f96ad839e1@mail.gmail.com>
Message-ID: <3d375d730806232111p56f1bcb3o981948f0c96fb845@mail.gmail.com>

On Mon, Jun 23, 2008 at 23:06, Nathan Bell <wnbell at gmail.com> wrote:
> On Mon, Jun 23, 2008 at 9:56 PM, David Cournapeau
> <david at ar.media.kyoto-u.ac.jp> wrote:
>>
>>    Would you mind taking a look at all bugs for 0.7 milestone related
>> to scipy.sparse; in particular, if you can't work quickly on
>> enhancements, I think pushing them for 0.8 should be fine. Since scipy
>> has not seen a release for a long time, I think we should focus primary
>> on bug fixes, specially for scipy.sparse which has seen so much
>> development since 0.6 thanks to you and others,
>>
>
> I've pushed the enhancements forward to the 0.8 milestone.

I've added an "Unscheduled" milestone. Enhancement tickets that have
no one working on them should probably have this milestone instead of
bumping up to the next versioned milestone every time we roll around
to a new release.

-- 
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 14366037 at sun.ac.za  Tue Jun 24 04:48:14 2008
From: 14366037 at sun.ac.za (Gouws, Almero <14366037@sun.ac.za>)
Date: Tue, 24 Jun 2008 10:48:14 +0200
Subject: [SciPy-dev] BayesNet SciKit
Message-ID: <C1E9B7C58242FE44A069F7F0BB5212D47D46A9@STBEVS02.stb.sun.ac.za>


Hi,

I am a masters student currently working on a port of Kevin P. Murphy's
Matlab toolbox, FullBNT, to Python. The code is not yet available in a
public repository, because I would like it to match or surpass 
the functionality of the openbayes toolbox before making it available.

Here's a list of what is currently working:

-Static Bayesian Networks:
 -Nodes:
  - Mutinomial nodes:
   - (Sequential) Bayesian parameter updating from complete data.
   - Maximum liklihood parameter estimation from complete data.
   - Maximum likelihood parameter estimation with missing values (EM)
   - Greedy K2 structure learning.

  - Gaussian nodes:
   - Maximum liklihood parameter estimation from complete data.

 - Inference Engines:
  - Junction tree inference engine
    - Works for Multinomial and Guassian nodes.

Thanks
Almero Gouws



From ed at lamedomain.net  Tue Jun 24 06:06:50 2008
From: ed at lamedomain.net (Ed Rahn)
Date: Tue, 24 Jun 2008 03:06:50 -0700
Subject: [SciPy-dev] BayesNet SciKit
In-Reply-To: <C1E9B7C58242FE44A069F7F0BB5212D47D46A9@STBEVS02.stb.sun.ac.za>
References: <C1E9B7C58242FE44A069F7F0BB5212D47D46A9@STBEVS02.stb.sun.ac.za>
Message-ID: <4860C73A.5040609@lamedomain.net>

What's the reasoning for starting from scratch on a port instead of 
using preexisting code that has the same exact objective?

- Ed

Gouws, Almero <14366037 at sun.ac.za> wrote:
> Hi,
> 
> I am a masters student currently working on a port of Kevin P. Murphy's
> Matlab toolbox, FullBNT, to Python. The code is not yet available in a
> public repository, because I would like it to match or surpass 
> the functionality of the openbayes toolbox before making it available.
> 
> Here's a list of what is currently working:
> 
> -Static Bayesian Networks:
>  -Nodes:
>   - Mutinomial nodes:
>    - (Sequential) Bayesian parameter updating from complete data.
>    - Maximum liklihood parameter estimation from complete data.
>    - Maximum likelihood parameter estimation with missing values (EM)
>    - Greedy K2 structure learning.
> 
>   - Gaussian nodes:
>    - Maximum liklihood parameter estimation from complete data.
> 
>  - Inference Engines:
>   - Junction tree inference engine
>     - Works for Multinomial and Guassian nodes.
> 
> Thanks
> Almero Gouws
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
> 


From 14366037 at sun.ac.za  Tue Jun 24 06:57:19 2008
From: 14366037 at sun.ac.za (Gouws, Almero <14366037@sun.ac.za>)
Date: Tue, 24 Jun 2008 12:57:19 +0200
Subject: [SciPy-dev] BayesNet SciKit
References: <C1E9B7C58242FE44A069F7F0BB5212D47D46A9@STBEVS02.stb.sun.ac.za>
	<4860C73A.5040609@lamedomain.net>
Message-ID: <C1E9B7C58242FE44A069F7F0BB5212D47D46AB@STBEVS02.stb.sun.ac.za>

By starting from scratch we can guarantee comprehensive documentation and
tests. Similar projects such as OpenBayes weren't very well documented and
had very few tests. Looking at the functionality of OpenBayes when it was
abondoned (http://www.openbayes.org/features), the current project is basically 
at that point, plus we have a proper set of unit tests.

-Almero


-----Original Message-----
From: scipy-dev-bounces at scipy.org on behalf of Ed Rahn
Sent: Tue 24/06/2008 12:06
To: SciPy Developers List
Subject: Re: [SciPy-dev] BayesNet SciKit
 
What's the reasoning for starting from scratch on a port instead of 
using preexisting code that has the same exact objective?

- Ed

Gouws, Almero <14366037 at sun.ac.za> wrote:
> Hi,
> 
> I am a masters student currently working on a port of Kevin P. Murphy's
> Matlab toolbox, FullBNT, to Python. The code is not yet available in a
> public repository, because I would like it to match or surpass 
> the functionality of the openbayes toolbox before making it available.
> 
> Here's a list of what is currently working:
> 
> -Static Bayesian Networks:
>  -Nodes:
>   - Mutinomial nodes:
>    - (Sequential) Bayesian parameter updating from complete data.
>    - Maximum liklihood parameter estimation from complete data.
>    - Maximum likelihood parameter estimation with missing values (EM)
>    - Greedy K2 structure learning.
> 
>   - Gaussian nodes:
>    - Maximum liklihood parameter estimation from complete data.
> 
>  - Inference Engines:
>   - Junction tree inference engine
>     - Works for Multinomial and Guassian nodes.
> 
> Thanks
> Almero Gouws
> 
> _______________________________________________
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 3448 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080624/834e72f5/attachment.bin>

From mhearne at usgs.gov  Tue Jun 24 08:29:48 2008
From: mhearne at usgs.gov (Michael Hearne)
Date: Tue, 24 Jun 2008 06:29:48 -0600
Subject: [SciPy-dev] Building numpy/scipy on RHEL5 OR CentOS5
In-Reply-To: <48605F66.1090508@ar.media.kyoto-u.ac.jp>
References: <485FC006.609@usgs.gov> <48605F66.1090508@ar.media.kyoto-u.ac.jp>
Message-ID: <4860E8BC.1070408@usgs.gov>

David - You are correct - my problems _were_ with BLAS and LAPACK.  I 
didn't know about your repository  - I'll try those on another machine 
once I've worked through Phil's instructions.  I agree with you about 
RHEL and the up to date list of packages... as far as I can tell, you 
have to have your machine registered with RedHat to get the most 
up-to-date list of the "official" versions of the software.

My biggest problems with RHEL are:
1) that everything is several versions behind the latest and greatest, 
because Redhat intends this for an enterprise audience who wants 
guarantees of stable software
2) Because you have to pay to get RHEL, there isn't as large a community 
of volunteer users.  The FC stuff isn't very helpful, because most of it 
is a couple of generations ahead.

You can guess that RHEL was not my choice...

Thanks for the suggestions!

--Mike

David Cournapeau wrote:
> Michael Hearne wrote:
>   
>> I've been wrestling with installing scipy (in any form - binary, source, 
>> egg, rpm) on some RHEL5 machines that I am compelled to work with, and 
>> have failed miserably.   I noticed a thread a few months back about 
>> building scipy on CentOS 5, and noticed that at least one of the 
>> respondents indicated he'd had success.  As I understand it, CentOS 
>> strives for binary compatibility with RHEL, so I'm hopeful that CentOS 
>> solutions will work for me.
>>
>> Does anyone have (in order of preference):
>> 1) A CentOS/RHEL5 yum repository for scipy/numpy/(optionally matplotlib)
>> 2) CentOS/RHEL5 RPM's for scipy/numpy/(optionally matplotlib)
>> 3) A set of instructions for building scipy from source on either of 
>> these platforms?
>>
>> I'm getting a little desperate here - this is likely one of the  most 
>> difficult installs I've ever had to deal with.
>>   
>>     
> Hi Michael,
>
> If you don't tell us more, we won't be able to help you much. Installing
> numpy/scipy themselves is easy; their dependencies (BLAS/LAPACK) are
> not. One problem I have with CENTOS/RHEL, contrary to most other
> distributions, is the difficult to get an up-to-date list of available
> packages. Would you know where to find it ?
>
> Your two options are building from sources or binary packages:
>     - from sources: you need BLAS/LAPACK, and make sure the same fortran
> compiler is used for everything (g77 or gfortran; gfortran is best for
> RHEL5, because that's the default one I believe).
>     - from rpm: you could try ashigabou repositories
>
> http://download.opensuse.org/repositories/home:/ashigabou/CentOS_5/
>
> If it does not work, please let me know (I am the one who build the
> packages, and will fix any problems with them).
>
> cheers,
>
> David
>   

-- 
------------------------------------------------------
Michael Hearne
mhearne at usgs.gov
(303) 273-8620
USGS National Earthquake Information Center
1711 Illinois St. Golden CO 80401
Senior Software Engineer
Synergetics, Inc.
------------------------------------------------------



From mellerf at netvision.net.il  Tue Jun 24 12:27:38 2008
From: mellerf at netvision.net.il (Yosef Meller)
Date: Tue, 24 Jun 2008 19:27:38 +0300
Subject: [SciPy-dev] 0.7 release schedule
In-Reply-To: <d05265cb0806232106l1417262pb604d5f96ad839e1@mail.gmail.com>
References: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>
	<web-103617420@uni-stuttgart.de>
	<485CAA19.8050504@ar.media.kyoto-u.ac.jp>
	<web-103635529@uni-stuttgart.de>
	<485CC2D1.4030300@ar.media.kyoto-u.ac.jp>
	<web-103638904@uni-stuttgart.de> <web-103640589@uni-stuttgart.de>
	<g3p4da$q9h$5@ger.gmane.org>
	<d05265cb0806231714n4b5a4405qb258369bd0b97c31@mail.gmail.com>
	<48606270.4090806@ar.media.kyoto-u.ac.jp>
	<d05265cb0806232106l1417262pb604d5f96ad839e1@mail.gmail.com>
Message-ID: <4861207A.2080301@netvision.net.il>


While we're at it, ticket #681 is pretty trivial, and there's a fix in 
the ticket (by me).

http://www.scipy.org/scipy/scipy/ticket/681

Oh, and hi everyone, that's my first participation in SciPy dev, and 
hopefully not the last. It's a great piece of software to use.

-- 
http://yosefm.imagekind.com/Eclectic


From nwagner at iam.uni-stuttgart.de  Tue Jun 24 12:28:33 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Tue, 24 Jun 2008 18:28:33 +0200
Subject: [SciPy-dev] Genetic algorithms in scipy/scikits
Message-ID: <web-103778248@uni-stuttgart.de>

Hi David,

Only 89 tickets are left. Maybe 88 when you
had a look at

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

AFAIK, ga moved to scikits.learn.

However, I failed to install learn from scikits.
Therefore I have filed a ticket

http://scipy.org/scipy/scikits/ticket/60

Cheers

           Nils



From matthieu.brucher at gmail.com  Tue Jun 24 12:38:14 2008
From: matthieu.brucher at gmail.com (Matthieu Brucher)
Date: Tue, 24 Jun 2008 18:38:14 +0200
Subject: [SciPy-dev] Genetic algorithms in scipy/scikits
In-Reply-To: <web-103778248@uni-stuttgart.de>
References: <web-103778248@uni-stuttgart.de>
Message-ID: <e76aa17f0806240938k165653ccse8ee331368bc67ae@mail.gmail.com>

Hi,

That would be my task to find the solution, as this matrix library
(and the manifold learning submodule) is taken from my work.

Just a guess, are you using (the stupidly-non-standard) gcc 4.0.x ? If
it is the case, I know how to solve it. In fact the SNIFAE
construction does not work with gcc 4.0, which I use to check if I can
use iterator copy or a for loop.

Matthieu


2008/6/24 Nils Wagner <nwagner at iam.uni-stuttgart.de>:
> Hi David,
>
> Only 89 tickets are left. Maybe 88 when you
> had a look at
>
> http://projects.scipy.org/scipy/scipy/ticket/484
>
> AFAIK, ga moved to scikits.learn.
>
> However, I failed to install learn from scikits.
> Therefore I have filed a ticket
>
> http://scipy.org/scipy/scikits/ticket/60
>
> Cheers
>
>           Nils
>
> _______________________________________________
> 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


From matthieu.brucher at gmail.com  Tue Jun 24 12:44:37 2008
From: matthieu.brucher at gmail.com (Matthieu Brucher)
Date: Tue, 24 Jun 2008 18:44:37 +0200
Subject: [SciPy-dev] BayesNet SciKit
In-Reply-To: <C1E9B7C58242FE44A069F7F0BB5212D47D46A9@STBEVS02.stb.sun.ac.za>
References: <C1E9B7C58242FE44A069F7F0BB5212D47D46A9@STBEVS02.stb.sun.ac.za>
Message-ID: <e76aa17f0806240944v5d78b6ceke2c691d01c09d0df@mail.gmail.com>

Hi,

The fact that the functionalities are not higher than OpenBayes is not
relevant (for me) to the fact that the repository is not public.
You could make the repository available and still go on implementing
the basic functionalities. This would help you with additional test
results ;) See also this blog ticket:
http://blog.red-bean.com/sussman/?p=96

But thanks for the mail indicating you're working on it ;)

Matthieu

2008/6/24 Gouws, Almero <14366037 at sun.ac.za> <14366037 at sun.ac.za>:
>
> Hi,
>
> I am a masters student currently working on a port of Kevin P. Murphy's
> Matlab toolbox, FullBNT, to Python. The code is not yet available in a
> public repository, because I would like it to match or surpass
> the functionality of the openbayes toolbox before making it available.
>
> Here's a list of what is currently working:
>
> -Static Bayesian Networks:
>  -Nodes:
>  - Mutinomial nodes:
>   - (Sequential) Bayesian parameter updating from complete data.
>   - Maximum liklihood parameter estimation from complete data.
>   - Maximum likelihood parameter estimation with missing values (EM)
>   - Greedy K2 structure learning.
>
>  - Gaussian nodes:
>   - Maximum liklihood parameter estimation from complete data.
>
>  - Inference Engines:
>  - Junction tree inference engine
>    - Works for Multinomial and Guassian nodes.
>
> Thanks
> Almero Gouws
>
> _______________________________________________
> 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


From nwagner at iam.uni-stuttgart.de  Tue Jun 24 12:46:04 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Tue, 24 Jun 2008 18:46:04 +0200
Subject: [SciPy-dev] Genetic algorithms in scipy/scikits
In-Reply-To: <e76aa17f0806240938k165653ccse8ee331368bc67ae@mail.gmail.com>
References: <web-103778248@uni-stuttgart.de>
	<e76aa17f0806240938k165653ccse8ee331368bc67ae@mail.gmail.com>
Message-ID: <web-103778898@uni-stuttgart.de>

On Tue, 24 Jun 2008 18:38:14 +0200
  "Matthieu Brucher" <matthieu.brucher at gmail.com> wrote:
> Hi,
> 
> That would be my task to find the solution, as this 
>matrix library
> (and the manifold learning submodule) is taken from my 
>work.
> 
> Just a guess, are you using (the stupidly-non-standard) 
>gcc 4.0.x ? If
> it is the case, I know how to solve it. In fact the 
>SNIFAE
> construction does not work with gcc 4.0, which I use to 
>check if I can
> use iterator copy or a for loop.
> 
> Matthieu
> 
  
Hi Matthieu,

I wasn't aware of that.
Actually the ticket was assigned to David.

I am using
  gcc --version
gcc (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying 
conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A 
PARTICULAR PURPOSE.

Nils



From matthieu.brucher at gmail.com  Tue Jun 24 12:53:30 2008
From: matthieu.brucher at gmail.com (Matthieu Brucher)
Date: Tue, 24 Jun 2008 18:53:30 +0200
Subject: [SciPy-dev] Genetic algorithms in scipy/scikits
In-Reply-To: <web-103778898@uni-stuttgart.de>
References: <web-103778248@uni-stuttgart.de>
	<e76aa17f0806240938k165653ccse8ee331368bc67ae@mail.gmail.com>
	<web-103778898@uni-stuttgart.de>
Message-ID: <e76aa17f0806240953t2033679tb7272e6c98c71582@mail.gmail.com>

> I wasn't aware of that.
> Actually the ticket was assigned to David.
>
> I am using
>  gcc --version
> gcc (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux)
> Copyright (C) 2003 Free Software Foundation, Inc.
> This is free software; see the source for copying
> conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.

OK, thanks, I'll try to get a hand on this compiler to make it work
(but not today, I'm just back from vacations ;))

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 robert.kern at gmail.com  Tue Jun 24 13:49:38 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 24 Jun 2008 12:49:38 -0500
Subject: [SciPy-dev] 0.7 release schedule
In-Reply-To: <4861207A.2080301@netvision.net.il>
References: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>
	<web-103635529@uni-stuttgart.de>
	<485CC2D1.4030300@ar.media.kyoto-u.ac.jp>
	<web-103638904@uni-stuttgart.de> <web-103640589@uni-stuttgart.de>
	<g3p4da$q9h$5@ger.gmane.org>
	<d05265cb0806231714n4b5a4405qb258369bd0b97c31@mail.gmail.com>
	<48606270.4090806@ar.media.kyoto-u.ac.jp>
	<d05265cb0806232106l1417262pb604d5f96ad839e1@mail.gmail.com>
	<4861207A.2080301@netvision.net.il>
Message-ID: <3d375d730806241049j664681fck36ede8656253c80b@mail.gmail.com>

On Tue, Jun 24, 2008 at 11:27, Yosef Meller <mellerf at netvision.net.il> wrote:
>
> While we're at it, ticket #681 is pretty trivial, and there's a fix in
> the ticket (by me).
>
> http://www.scipy.org/scipy/scipy/ticket/681

Thank you. Fixed in r4478.

> Oh, and hi everyone, that's my first participation in SciPy dev, and
> hopefully not the last. It's a great piece of software to use.

Welcome! Glad to have you here.

-- 
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 mhearne at usgs.gov  Tue Jun 24 15:25:48 2008
From: mhearne at usgs.gov (Michael Hearne)
Date: Tue, 24 Jun 2008 13:25:48 -0600
Subject: [SciPy-dev] Building numpy/scipy on RHEL5 OR CentOS5
In-Reply-To: <48605FBE.5090904@ar.media.kyoto-u.ac.jp>
References: <485FC006.609@usgs.gov> <485FD45D.1040101@gmail.com>
	<48605FBE.5090904@ar.media.kyoto-u.ac.jp>
Message-ID: <48614A3C.10604@usgs.gov>

I've now passed the BLAS/Lapack stage, and am trying to build scipy.  
However, I get the following sorts of errors from swig:

scipy/linsolve/umfpack/umfpack.i:192: Error: Unable to find 'umfpack.h'
scipy/linsolve/umfpack/umfpack.i:193: Error: Unable to find 
'umfpack_solve.h'
...

I found something from the Scipy-User mailing list (from two years ago!):
http://projects.scipy.org/pipermail/scipy-user/2006-July/008661.html

That indicates I should do this:

 >>export UMFPACK = "None"

in the shell.

I couldn't find any umf*.h files anywhere in scipy or any of the other 
supporting packages.  Is this another external dependency, or something 
I can ignore using the method above?

--Mike

David Cournapeau wrote:
> Phil Austin wrote:
>   
>> 3) build LAPACK
>>
>> for lapack: cp INSTALL/make.inc.LINUX  ~/install/lapack-3.1.1/make.inc
>> and edit:
>>
>> FORTRAN  = gfortran
>> OPTS     = -funroll-all-loops -O3 -fPIC
>> DRVOPTS  = $(OPTS)
>> NOOPT    =
>> LOADER   = gfortran
>> LOADOPTS =
>>
>> BLASLIB      = /home/phil/usr251_Centos/lib/libcblas.a
>> LAPACKLIB    = lapack$(PLAT).a
>> TMGLIB       = tmglib$(PLAT).a
>> EIGSRCLIB    = eigsrc$(PLAT).a
>> LINSRCLIB    = linsrc$(PLAT).a
>>
>> !!and then rebuild these individual routines with fPIC -- recompile!
>>   
>>     
>
> You should put -fPIC to NOOPT and LOADOPTS instead: this will be more
> reliable, as this way, -fPIC will be used for every source file
>
> cheers,
>
> David
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>   

-- 
------------------------------------------------------
Michael Hearne
mhearne at usgs.gov
(303) 273-8620
USGS National Earthquake Information Center
1711 Illinois St. Golden CO 80401
Senior Software Engineer
Synergetics, Inc.
------------------------------------------------------



From robert.kern at gmail.com  Tue Jun 24 15:43:45 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 24 Jun 2008 14:43:45 -0500
Subject: [SciPy-dev] Building numpy/scipy on RHEL5 OR CentOS5
In-Reply-To: <48614A3C.10604@usgs.gov>
References: <485FC006.609@usgs.gov> <485FD45D.1040101@gmail.com>
	<48605FBE.5090904@ar.media.kyoto-u.ac.jp> <48614A3C.10604@usgs.gov>
Message-ID: <3d375d730806241243u1e4d2b9fh35fdcdacad3aa1fd@mail.gmail.com>

On Tue, Jun 24, 2008 at 14:25, Michael Hearne <mhearne at usgs.gov> wrote:
> I've now passed the BLAS/Lapack stage, and am trying to build scipy.
> However, I get the following sorts of errors from swig:
>
> scipy/linsolve/umfpack/umfpack.i:192: Error: Unable to find 'umfpack.h'
> scipy/linsolve/umfpack/umfpack.i:193: Error: Unable to find
> 'umfpack_solve.h'
> ...
>
> I found something from the Scipy-User mailing list (from two years ago!):
> http://projects.scipy.org/pipermail/scipy-user/2006-July/008661.html
>
> That indicates I should do this:
>
>  >>export UMFPACK = "None"
>
> in the shell.
>
> I couldn't find any umf*.h files anywhere in scipy or any of the other
> supporting packages.  Is this another external dependency, or something
> I can ignore using the method above?

It is an optional external dependency. If you don't need to use the
UMFPACK functions, you can set UMFPACK=None. It shouldn't be
necessary, though, so it's concerning that it stops the build when you
didn't request it.

-- 
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 stefan at sun.ac.za  Tue Jun 24 16:12:18 2008
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 24 Jun 2008 22:12:18 +0200
Subject: [SciPy-dev] BayesNet SciKit
In-Reply-To: <e76aa17f0806240944v5d78b6ceke2c691d01c09d0df@mail.gmail.com>
References: <C1E9B7C58242FE44A069F7F0BB5212D47D46A9@STBEVS02.stb.sun.ac.za>
	<e76aa17f0806240944v5d78b6ceke2c691d01c09d0df@mail.gmail.com>
Message-ID: <9457e7c80806241312j62c3c641m8b911d87aa09243c@mail.gmail.com>

Hi Matthieu

2008/6/24 Matthieu Brucher <matthieu.brucher at gmail.com>:
> The fact that the functionalities are not higher than OpenBayes is not
> relevant (for me) to the fact that the repository is not public.

The plan is to have the source code available in a couple of weeks'
time.  We have a scikits account, and will proceed with the upload as
soon as the university term starts over here in South Africa.  I asked
Almero to post an update on his work so long, so that we can
coordinate collaborations, rather than duplicate efforts.

Regards
St?fan


From robert.kern at gmail.com  Tue Jun 24 16:19:21 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 24 Jun 2008 15:19:21 -0500
Subject: [SciPy-dev] BayesNet SciKit
In-Reply-To: <9457e7c80806241312j62c3c641m8b911d87aa09243c@mail.gmail.com>
References: <C1E9B7C58242FE44A069F7F0BB5212D47D46A9@STBEVS02.stb.sun.ac.za>
	<e76aa17f0806240944v5d78b6ceke2c691d01c09d0df@mail.gmail.com>
	<9457e7c80806241312j62c3c641m8b911d87aa09243c@mail.gmail.com>
Message-ID: <3d375d730806241319x24a2af5cxece2aa98906da5a4@mail.gmail.com>

On Tue, Jun 24, 2008 at 15:12, St?fan van der Walt <stefan at sun.ac.za> wrote:
> Hi Matthieu
>
> 2008/6/24 Matthieu Brucher <matthieu.brucher at gmail.com>:
>> The fact that the functionalities are not higher than OpenBayes is not
>> relevant (for me) to the fact that the repository is not public.
>
> The plan is to have the source code available in a couple of weeks'
> time.  We have a scikits account, and will proceed with the upload as
> soon as the university term starts over here in South Africa.  I asked
> Almero to post an update on his work so long, so that we can
> coordinate collaborations, rather than duplicate efforts.

You may want to talk to Abhik Shah, the author of PEBL:

  http://code.google.com/p/pebl-project/

-- 
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 abhikshah at gmail.com  Tue Jun 24 16:44:31 2008
From: abhikshah at gmail.com (Abhik Shah)
Date: Tue, 24 Jun 2008 16:44:31 -0400
Subject: [SciPy-dev] BayesNet SciKit
In-Reply-To: <3d375d730806241319x24a2af5cxece2aa98906da5a4@mail.gmail.com>
References: <C1E9B7C58242FE44A069F7F0BB5212D47D46A9@STBEVS02.stb.sun.ac.za>
	<e76aa17f0806240944v5d78b6ceke2c691d01c09d0df@mail.gmail.com>
	<9457e7c80806241312j62c3c641m8b911d87aa09243c@mail.gmail.com>
	<3d375d730806241319x24a2af5cxece2aa98906da5a4@mail.gmail.com>
Message-ID: <823e60360806241344t59c765a9h645448d902885928@mail.gmail.com>

Hi All,
   Almero has gotten in touch with me and will be emailing some code
this weekend.  I will try to look at that (and BNT) code next week to
get an idea of how to best integrate the structure learning with the
parm learning and inference code.

Thanks,
Abhik.

On Tue, Jun 24, 2008 at 4:19 PM, Robert Kern <robert.kern at gmail.com> wrote:
> On Tue, Jun 24, 2008 at 15:12, St?fan van der Walt <stefan at sun.ac.za> wrote:
>> Hi Matthieu
>>
>> 2008/6/24 Matthieu Brucher <matthieu.brucher at gmail.com>:
>>> The fact that the functionalities are not higher than OpenBayes is not
>>> relevant (for me) to the fact that the repository is not public.
>>
>> The plan is to have the source code available in a couple of weeks'
>> time.  We have a scikits account, and will proceed with the upload as
>> soon as the university term starts over here in South Africa.  I asked
>> Almero to post an update on his work so long, so that we can
>> coordinate collaborations, rather than duplicate efforts.
>
> You may want to talk to Abhik Shah, the author of PEBL:
>
>  http://code.google.com/p/pebl-project/
>
> --
> 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
>



-- 
Abhik Shah - http://umich.edu/~shahad
Systems Biology Lab, University of Michigan


From mhearne at usgs.gov  Tue Jun 24 17:08:28 2008
From: mhearne at usgs.gov (Michael Hearne)
Date: Tue, 24 Jun 2008 15:08:28 -0600
Subject: [SciPy-dev] Building numpy/scipy on RHEL5 OR CentOS5
In-Reply-To: <3d375d730806241243u1e4d2b9fh35fdcdacad3aa1fd@mail.gmail.com>
References: <485FC006.609@usgs.gov> <485FD45D.1040101@gmail.com>	
	<48605FBE.5090904@ar.media.kyoto-u.ac.jp> <48614A3C.10604@usgs.gov>
	<3d375d730806241243u1e4d2b9fh35fdcdacad3aa1fd@mail.gmail.com>
Message-ID: <4861624C.5080101@usgs.gov>

Actually, I discovered that it's stopping the _install_, as well, even 
after I set UMFPACK="None".  Anyone have tips for dealing with that?

Steps:
(Assuming I've built LAPACK, BLAS, and numpy correctly):
1) export UMFPACK="None"
1) /usr/local/bin/python setup.py --fcompiler=gnu95 build
2) sudo /usr/local/bin/python setup.py install

results in:
...
building extension "scipy.linsolve.umfpack.__umfpack" sources
  adding 'scipy/linsolve/umfpack/umfpack.i' to sources.
swig: scipy/linsolve/umfpack/umfpack.i
swig -python -I/usr/local/include -o 
build/src.linux-x86_64-2.5/scipy/linsolve/umfpack/_umfpack_wrap.c 
-outdir build/src.linux-x86_64-2.5/scipy/linsolve/umfpack 
scipy/linsolve/umfpack/umfpack.i
scipy/linsolve/umfpack/umfpack.i:192: Error: Unable to find 'umfpack.h'
...

Is there some way to turn off UMFPACK in setup.py?

--Mike Hearne

Robert Kern wrote:
> On Tue, Jun 24, 2008 at 14:25, Michael Hearne <mhearne at usgs.gov> wrote:
>   
>> I've now passed the BLAS/Lapack stage, and am trying to build scipy.
>> However, I get the following sorts of errors from swig:
>>
>> scipy/linsolve/umfpack/umfpack.i:192: Error: Unable to find 'umfpack.h'
>> scipy/linsolve/umfpack/umfpack.i:193: Error: Unable to find
>> 'umfpack_solve.h'
>> ...
>>
>> I found something from the Scipy-User mailing list (from two years ago!):
>> http://projects.scipy.org/pipermail/scipy-user/2006-July/008661.html
>>
>> That indicates I should do this:
>>
>>  >>export UMFPACK = "None"
>>
>> in the shell.
>>
>> I couldn't find any umf*.h files anywhere in scipy or any of the other
>> supporting packages.  Is this another external dependency, or something
>> I can ignore using the method above?
>>     
>
> It is an optional external dependency. If you don't need to use the
> UMFPACK functions, you can set UMFPACK=None. It shouldn't be
> necessary, though, so it's concerning that it stops the build when you
> didn't request it.
>
>   

-- 
------------------------------------------------------
Michael Hearne
mhearne at usgs.gov
(303) 273-8620
USGS National Earthquake Information Center
1711 Illinois St. Golden CO 80401
Senior Software Engineer
Synergetics, Inc.
------------------------------------------------------



From phaustin at gmail.com  Tue Jun 24 17:29:03 2008
From: phaustin at gmail.com (Phil Austin)
Date: Tue, 24 Jun 2008 14:29:03 -0700
Subject: [SciPy-dev] Building numpy/scipy on RHEL5 OR CentOS5
In-Reply-To: <4861624C.5080101@usgs.gov>
References: <485FC006.609@usgs.gov> <485FD45D.1040101@gmail.com>
	<48605FBE.5090904@ar.media.kyoto-u.ac.jp> <48614A3C.10604@usgs.gov>
	<3d375d730806241243u1e4d2b9fh35fdcdacad3aa1fd@mail.gmail.com>
	<4861624C.5080101@usgs.gov>
Message-ID: <4861671F.6080203@gmail.com>

Michael Hearne wrote:
> Actually, I discovered that it's stopping the _install_, as well, even 
> after I set UMFPACK="None".  Anyone have tips for dealing with that?

Mike -- I don't set the UMFPACK environmental variable, and setup.py
is still able to detect that umfpack isn't available.  I've just
done an svn update to revision 4478 and rebuilt scipy from
scratch.  The output from the build is at:

http://clouds.eos.ubc.ca/~phil/pubdocs/scipy/build_output.txt

where at line 153 I've got:

umfpack_info:
   libraries umfpack not found in /home/phil/usr251_Centos/lib
   libraries umfpack not found in /usr/local/lib
   libraries umfpack not found in /usr/lib
/home/phil/usr251_Centos/lib/python2.5/site-packages/numpy/distutils/system_info.py:414: 
UserWarning:
     UMFPACK sparse solver 
(http://www.cise.ufl.edu/research/sparse/umfpack/)
     not found. Directories to search for the libraries can be specified 
in the
     numpy/distutils/site.cfg file (section [umfpack]) or by setting
     the UMFPACK environment variable.
   warnings.warn(self.notfounderror.__doc__)
   NOT AVAILABLE

I've also copied the results from

~ phil at owl% python -c 'import scipy; scipy.test("fast")'

to

http://clouds.eos.ubc.ca/~phil/pubdocs/scipy/test_output.txt

________________________________

While we're on this topic, does anyone know why build_output.txt
reports (line 41)  a failure to find an F90 compiler

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 config
compiling '_configtest.c':


but setup.py later finds one (line 3163)?

running build_clib
customize UnixCCompiler
customize UnixCCompiler using build_clib
customize Gnu95FCompiler
Found executable /usr/bin/gfortran
customize Gnu95FCompiler using build_clib
building 'dfftpack' library
compiling Fortran sources
Fortran f77 compiler: /usr/bin/gfortran -Wall -ffixed-form 
-fno-second-underscore -fPIC -O3 -funroll-loops -march=athlon64 -mmmx 
-m3dnow -msse2 -msse
Fortran f90 compiler: /usr/bin/gfortran -Wall -fno-second-underscore 
-fPIC -O3 -funroll-loops -march=athlon64 -mmmx -m3dnow -msse2 -msse
Fortran fix compiler: /usr/bin/gfortran -Wall -ffixed-form 
-fno-second-underscore -Wall -fno-second-underscore -fPIC -O3 
-funroll-loops -march=athlon64 -mmmx -m3dnow -msse2 -msse




From mhearne at usgs.gov  Tue Jun 24 21:57:35 2008
From: mhearne at usgs.gov (Michael Hearne)
Date: Tue, 24 Jun 2008 19:57:35 -0600
Subject: [SciPy-dev] Building numpy/scipy on RHEL5 OR CentOS5
In-Reply-To: <4861671F.6080203@gmail.com>
References: <485FC006.609@usgs.gov> <485FD45D.1040101@gmail.com>
	<48605FBE.5090904@ar.media.kyoto-u.ac.jp> <48614A3C.10604@usgs.gov>
	<3d375d730806241243u1e4d2b9fh35fdcdacad3aa1fd@mail.gmail.com>
	<4861624C.5080101@usgs.gov> <4861671F.6080203@gmail.com>
Message-ID: <4861A60F.7080607@usgs.gov>

Phil et. al. - I believe that you and probably others do not have this 
problem, but I continue to have it.  I just downloaded the most recent 
svn version of scipy and re-attempted the build and install.  The build 
was successful, but the install complained about ufmpack.

I ask again - is there a way to _force_ the scipy build to ignore ufmpack?

I suppose I could just download the damn thing (whatever it is), and 
compile that too...

--Mike

Phil Austin wrote:
> Michael Hearne wrote:
>> Actually, I discovered that it's stopping the _install_, as well, 
>> even after I set UMFPACK="None".  Anyone have tips for dealing with 
>> that?
>
> Mike -- I don't set the UMFPACK environmental variable, and setup.py
> is still able to detect that umfpack isn't available.  I've just
> done an svn update to revision 4478 and rebuilt scipy from
> scratch.  The output from the build is at:
>
> http://clouds.eos.ubc.ca/~phil/pubdocs/scipy/build_output.txt
>
> where at line 153 I've got:
>
> umfpack_info:
>   libraries umfpack not found in /home/phil/usr251_Centos/lib
>   libraries umfpack not found in /usr/local/lib
>   libraries umfpack not found in /usr/lib
> /home/phil/usr251_Centos/lib/python2.5/site-packages/numpy/distutils/system_info.py:414: 
> UserWarning:
>     UMFPACK sparse solver 
> (http://www.cise.ufl.edu/research/sparse/umfpack/)
>     not found. Directories to search for the libraries can be 
> specified in the
>     numpy/distutils/site.cfg file (section [umfpack]) or by setting
>     the UMFPACK environment variable.
>   warnings.warn(self.notfounderror.__doc__)
>   NOT AVAILABLE
>
> I've also copied the results from
>
> ~ phil at owl% python -c 'import scipy; scipy.test("fast")'
>
> to
>
> http://clouds.eos.ubc.ca/~phil/pubdocs/scipy/test_output.txt
>
> ________________________________
>
> While we're on this topic, does anyone know why build_output.txt
> reports (line 41)  a failure to find an F90 compiler
>
> 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 config
> compiling '_configtest.c':
>
>
> but setup.py later finds one (line 3163)?
>
> running build_clib
> customize UnixCCompiler
> customize UnixCCompiler using build_clib
> customize Gnu95FCompiler
> Found executable /usr/bin/gfortran
> customize Gnu95FCompiler using build_clib
> building 'dfftpack' library
> compiling Fortran sources
> Fortran f77 compiler: /usr/bin/gfortran -Wall -ffixed-form 
> -fno-second-underscore -fPIC -O3 -funroll-loops -march=athlon64 -mmmx 
> -m3dnow -msse2 -msse
> Fortran f90 compiler: /usr/bin/gfortran -Wall -fno-second-underscore 
> -fPIC -O3 -funroll-loops -march=athlon64 -mmmx -m3dnow -msse2 -msse
> Fortran fix compiler: /usr/bin/gfortran -Wall -ffixed-form 
> -fno-second-underscore -Wall -fno-second-underscore -fPIC -O3 
> -funroll-loops -march=athlon64 -mmmx -m3dnow -msse2 -msse
>

-- 
------------------------------------------------------
Michael Hearne
mhearne at usgs.gov
(303) 273-8620
USGS National Earthquake Information Center
1711 Illinois St. Golden CO 80401
Senior Software Engineer
Synergetics, Inc.
------------------------------------------------------



From vshah at interactivesupercomputing.com  Tue Jun 24 22:45:41 2008
From: vshah at interactivesupercomputing.com (Viral Shah)
Date: Tue, 24 Jun 2008 19:45:41 -0700
Subject: [SciPy-dev] Sparse cholesky from the TAUCS library.
Message-ID: <BBA4A1B7-AFCC-4D2C-B66C-505E6D3AC7AA@interactivesupercomputing.com>

I was wondering if anyone has plugged in TAUCS into scipy.

http://www.tau.ac.il/~stoledo/taucs/

It includes a sparse direct solver that can give us Cholesky. It also  
has incomplete factorizations and conjugate gradient. The sparse  
direct solver is used in Mathematica.

I believe the license also meets the requirements - but I could be  
wrong.

One route to get these solvers among others could be to integrate some  
of pytrilinos into scipy.

-viral





From robert.kern at gmail.com  Tue Jun 24 23:06:08 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 24 Jun 2008 22:06:08 -0500
Subject: [SciPy-dev] Sparse cholesky from the TAUCS library.
In-Reply-To: <BBA4A1B7-AFCC-4D2C-B66C-505E6D3AC7AA@interactivesupercomputing.com>
References: <BBA4A1B7-AFCC-4D2C-B66C-505E6D3AC7AA@interactivesupercomputing.com>
Message-ID: <3d375d730806242006r35228213xbdfb315e4eeaefd7@mail.gmail.com>

On Tue, Jun 24, 2008 at 21:45, Viral Shah
<vshah at interactivesupercomputing.com> wrote:
> I was wondering if anyone has plugged in TAUCS into scipy.
>
> http://www.tau.ac.il/~stoledo/taucs/
>
> It includes a sparse direct solver that can give us Cholesky. It also
> has incomplete factorizations and conjugate gradient. The sparse
> direct solver is used in Mathematica.
>
> I believe the license also meets the requirements - but I could be
> wrong.

Some of its dependencies may be problematic. For example, from
external/src/amdtru.c:

/* NOTICE:  "The AMD routines (AMDEXA, AMDBAR, AMDHAF, AMDHAT, AMDTRU, */
/* and AMDATR) may be used SOLELY for educational, research, and */
/* benchmarking purposes by non-profit organizations and the U.S. */
/* government.  Commercial and other organizations may make use of the */
/* AMD routines SOLELY for benchmarking purposes only.  The AMD */
/* routines may be modified by or on behalf of the User for such */
/* use but at no time shall the AMD routines or any such modified */
/* version of them become the property of the User.  The AMD routines */
/* are provided without warranty of any kind, either expressed or */
/* implied.  Neither the Authors nor their employers shall be liable */
/* for any direct or consequential loss or damage whatsoever arising */
/* out of the use or misuse of the AMD routines by the User.  The AMD */
/* routines must not be sold.  You may make copies of the AMD routines, */
/* but this NOTICE and the Copyright notice must appear in all copies. */
/* Any other use of the AMD routines requires written permission. */
/* Your use of the AMD routines is an implicit agreement to these */
/* conditions." */

I'm not sure how much these files are required.

-- 
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 wnbell at gmail.com  Tue Jun 24 23:17:32 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Tue, 24 Jun 2008 22:17:32 -0500
Subject: [SciPy-dev] Sparse cholesky from the TAUCS library.
In-Reply-To: <BBA4A1B7-AFCC-4D2C-B66C-505E6D3AC7AA@interactivesupercomputing.com>
References: <BBA4A1B7-AFCC-4D2C-B66C-505E6D3AC7AA@interactivesupercomputing.com>
Message-ID: <d05265cb0806242017p1863e5f4h80285a5be42f8133@mail.gmail.com>

On Tue, Jun 24, 2008 at 9:45 PM, Viral Shah
<vshah at interactivesupercomputing.com> wrote:
> I was wondering if anyone has plugged in TAUCS into scipy.
>
> http://www.tau.ac.il/~stoledo/taucs/
>

Here's the ticket:
http://projects.scipy.org/scipy/scipy/ticket/261

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


From david at ar.media.kyoto-u.ac.jp  Tue Jun 24 23:08:14 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Wed, 25 Jun 2008 12:08:14 +0900
Subject: [SciPy-dev] Building numpy/scipy on RHEL5 OR CentOS5
In-Reply-To: <4861A60F.7080607@usgs.gov>
References: <485FC006.609@usgs.gov>
	<485FD45D.1040101@gmail.com>	<48605FBE.5090904@ar.media.kyoto-u.ac.jp>
	<48614A3C.10604@usgs.gov>	<3d375d730806241243u1e4d2b9fh35fdcdacad3aa1fd@mail.gmail.com>	<4861624C.5080101@usgs.gov>
	<4861671F.6080203@gmail.com> <4861A60F.7080607@usgs.gov>
Message-ID: <4861B69E.5060607@ar.media.kyoto-u.ac.jp>

Michael Hearne wrote:
> Phil et. al. - I believe that you and probably others do not have this 
> problem, but I continue to have it.  I just downloaded the most recent 
> svn version of scipy and re-attempted the build and install.  The build 
> was successful, but the install complained about ufmpack.
>   

Could you give us the whole build log (after removing the build
directory, i.e. from scratch) ? It looks like you found a bug in the
configuration system at some point.

Also, did you try the ashigabou repository ? It should be easy to try,
and if it works, it should right away (also, if this one works for you,
it should work for everybody, since binary install, once working, are
much easier to do).

cheers,

David


From phaustin at gmail.com  Tue Jun 24 23:32:10 2008
From: phaustin at gmail.com (Phil Austin)
Date: Tue, 24 Jun 2008 20:32:10 -0700
Subject: [SciPy-dev] Building numpy/scipy on RHEL5 OR CentOS5
In-Reply-To: <4861A60F.7080607@usgs.gov>
References: <485FC006.609@usgs.gov> <485FD45D.1040101@gmail.com>
	<48605FBE.5090904@ar.media.kyoto-u.ac.jp> <48614A3C.10604@usgs.gov>
	<3d375d730806241243u1e4d2b9fh35fdcdacad3aa1fd@mail.gmail.com>
	<4861624C.5080101@usgs.gov> <4861671F.6080203@gmail.com>
	<4861A60F.7080607@usgs.gov>
Message-ID: <4861BC3A.3020401@gmail.com>

Michael Hearne wrote:
> Phil et. al. - I believe that you and probably others do not have this 
> problem, but I continue to have it.  I just downloaded the most recent 
> svn version of scipy and re-attempted the build and install.  The build 
> was successful, but the install complained about ufmpack.
> 

Just to be sure I understand -- when you say the build was successful,
does that mean that during the build you see:

>> UserWarning:
>>     UMFPACK sparse solver 
>> (http://www.cise.ufl.edu/research/sparse/umfpack/)
>>     not found. Directories to search for the libraries can be 
>> specified in the
>>     numpy/distutils/site.cfg file (section [umfpack]) or by setting
>>     the UMFPACK environment variable.
>>   warnings.warn(self.notfounderror.__doc__)
>>   NOT AVAILABLE




From david at ar.media.kyoto-u.ac.jp  Wed Jun 25 02:24:54 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Wed, 25 Jun 2008 15:24:54 +0900
Subject: [SciPy-dev] Genetic algorithms in scipy/scikits
In-Reply-To: <e76aa17f0806240953t2033679tb7272e6c98c71582@mail.gmail.com>
References: <web-103778248@uni-stuttgart.de>	<e76aa17f0806240938k165653ccse8ee331368bc67ae@mail.gmail.com>	<web-103778898@uni-stuttgart.de>
	<e76aa17f0806240953t2033679tb7272e6c98c71582@mail.gmail.com>
Message-ID: <4861E4B6.5030306@ar.media.kyoto-u.ac.jp>

Matthieu Brucher wrote:
>> I wasn't aware of that.
>> Actually the ticket was assigned to David.
>>     

Yes, because I am the owner of scikits.learn. It should be possible to
create a subcomponent, though, so that the manifold parts automatically
goes to Matthieu.

cheers,

David


From david at ar.media.kyoto-u.ac.jp  Wed Jun 25 02:43:18 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Wed, 25 Jun 2008 15:43:18 +0900
Subject: [SciPy-dev] Scipy trac problems
Message-ID: <4861E906.7010403@ar.media.kyoto-u.ac.jp>

Hi,

    Just to say that the internal errors when accessing scipy trac are
more and more frequent.

cheers,

David


From gnurser at googlemail.com  Wed Jun 25 07:40:37 2008
From: gnurser at googlemail.com (George Nurser)
Date: Wed, 25 Jun 2008 12:40:37 +0100
Subject: [SciPy-dev] scipy test failures
Message-ID: <1d1e6ea70806250440w7a96d6ecv46188c44f88c0cac@mail.gmail.com>

I am running svn v 4478 both on a
macBook Pro: 10.5.3, gcc4.0.1, gfortran 4.3.0
numpy is 1.2.0.dev5308
Standard Apple Accelerate framework
scipy compiled as:
python setup.py build_src build_clib config_fc --fcompiler=gnu95
--f77flags=" -O3 -march=core2" build_ext config_fc --fcompiler=gnu95
--f77flags=" -O3 -march=core2" build >& inst.log &

 and a
Sun linux Opteron box: 64 bit, SUSE v 10.1, gcc 4.1.2, ifort v9.1
numpy is 1.2.0.dev5302
cblas + ACML for lapack,fblas

On the MBP scipy.test('10') produces 4 failures:

FAIL: test_x_stride (test_fblas.TestCgemv)
FAIL: test_autoalign_nmi_value_2
FAIL: test_autoalign_nmi_value_2
FAIL: test_namespace (test_formula.TestFormula)

and 4 errors

ERROR: test_huber (test_scale.TestScale)
ERROR: test_huberaxes (test_scale.TestScale)
ERROR: no_test_no_check_return (test_wx_spec.TestWxConverter)
ERROR: test_var_in (test_wx_spec.TestWxConverter)

wx_return.cpp and wx_var_in.cpp also seem to have declaration errors
and wx_var_in.cpp fails looking for a nonexistent gdk/gdk.h

On the 64-bit Opteron 6 failures:
FAIL: test_autoalign_nmi_value_2
FAIL: test_texture2 (test_segment.TestSegment)
FAIL: test_lorentz (test_odr.TestODR)
FAIL: test_multi (test_odr.TestODR)
FAIL: test_pearson (test_odr.TestODR)
FAIL: test_namespace (test_formula.TestFormula)

and the same 4 errors as on the MBP

ERROR: test_huber (test_scale.TestScale)
ERROR: test_huberaxes (test_scale.TestScale)
ERROR: no_test_no_check_return (test_wx_spec.TestWxConverter)
ERROR: test_var_in (test_wx_spec.TestWxConverter)

There seems to be a problem in that
/noc/users/agn/src/python/scipy/scipy/weave/wx_spec.py *only* searches
for the wx base directory in /usr/lib/wx*. Should it also include e.g.
os.environ['WXDIR'] in searched_locations?

-George Nurser
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MBP_scipy.test
Type: application/octet-stream
Size: 12428 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080625/8a5e1d9b/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Sun_scipy.test
Type: application/octet-stream
Size: 14110 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080625/8a5e1d9b/attachment-0001.obj>

From mhearne at usgs.gov  Wed Jun 25 09:34:05 2008
From: mhearne at usgs.gov (Michael Hearne)
Date: Wed, 25 Jun 2008 07:34:05 -0600
Subject: [SciPy-dev] Building numpy/scipy on RHEL5 OR CentOS5
In-Reply-To: <4861BC3A.3020401@gmail.com>
References: <485FC006.609@usgs.gov> <485FD45D.1040101@gmail.com>
	<48605FBE.5090904@ar.media.kyoto-u.ac.jp> <48614A3C.10604@usgs.gov>
	<3d375d730806241243u1e4d2b9fh35fdcdacad3aa1fd@mail.gmail.com>
	<4861624C.5080101@usgs.gov> <4861671F.6080203@gmail.com>
	<4861A60F.7080607@usgs.gov> <4861BC3A.3020401@gmail.com>
Message-ID: <4862494D.4010207@usgs.gov>

My apologies to everyone - I figured out the problem.  I was performing 
the build procedure as myself, after setting UMFPACK="None", but using 
sudo to install.  It didn't occur to me until just now that running as 
root meant that my environment variable wouldn't be visible in the root 
shell.  Duh.

That being said, can I make a suggestion that setup.py for scipy take an 
option that can turn UMFPACK off, instead of the user having to remember 
to do it in the shell, and causing him or herself the same sort of 
confusion I just caused?

It would also be great to have a less convoluted build procedure for 
BLAS/LAPACK, but I'll take one thing at a time.

Also, since Phil seems not to have to set this variable, is there 
something I can provide developers that would help them understand why 
my RHEL5 system seems to require that I set it?

Thanks for everyone's help,

Mike Hearne

Phil Austin wrote:
> Michael Hearne wrote:
>> Phil et. al. - I believe that you and probably others do not have 
>> this problem, but I continue to have it.  I just downloaded the most 
>> recent svn version of scipy and re-attempted the build and install.  
>> The build was successful, but the install complained about ufmpack.
>>
>
> Just to be sure I understand -- when you say the build was successful,
> does that mean that during the build you see:
>
>>> UserWarning:
>>>     UMFPACK sparse solver 
>>> (http://www.cise.ufl.edu/research/sparse/umfpack/)
>>>     not found. Directories to search for the libraries can be 
>>> specified in the
>>>     numpy/distutils/site.cfg file (section [umfpack]) or by setting
>>>     the UMFPACK environment variable.
>>>   warnings.warn(self.notfounderror.__doc__)
>>>   NOT AVAILABLE
>

-- 
------------------------------------------------------
Michael Hearne
mhearne at usgs.gov
(303) 273-8620
USGS National Earthquake Information Center
1711 Illinois St. Golden CO 80401
Senior Software Engineer
Synergetics, Inc.
------------------------------------------------------



From wnbell at gmail.com  Wed Jun 25 09:52:55 2008
From: wnbell at gmail.com (Nathan Bell)
Date: Wed, 25 Jun 2008 08:52:55 -0500
Subject: [SciPy-dev] Building numpy/scipy on RHEL5 OR CentOS5
In-Reply-To: <4862494D.4010207@usgs.gov>
References: <485FC006.609@usgs.gov> <485FD45D.1040101@gmail.com>
	<48605FBE.5090904@ar.media.kyoto-u.ac.jp> <48614A3C.10604@usgs.gov>
	<3d375d730806241243u1e4d2b9fh35fdcdacad3aa1fd@mail.gmail.com>
	<4861624C.5080101@usgs.gov> <4861671F.6080203@gmail.com>
	<4861A60F.7080607@usgs.gov> <4861BC3A.3020401@gmail.com>
	<4862494D.4010207@usgs.gov>
Message-ID: <d05265cb0806250652p84ad52yd45c1a7ad954c90f@mail.gmail.com>

On Wed, Jun 25, 2008 at 8:34 AM, Michael Hearne <mhearne at usgs.gov> wrote:
>
> That being said, can I make a suggestion that setup.py for scipy take an
> option that can turn UMFPACK off, instead of the user having to remember
> to do it in the shell, and causing him or herself the same sort of
> confusion I just caused?
>

UMFPACK support is being removed after SciPy 0.7, so it won't be an
issue for long anyway.

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


From mhearne at usgs.gov  Wed Jun 25 10:02:24 2008
From: mhearne at usgs.gov (Michael Hearne)
Date: Wed, 25 Jun 2008 08:02:24 -0600
Subject: [SciPy-dev] Building numpy/scipy on RHEL5 OR CentOS5
In-Reply-To: <4861B69E.5060607@ar.media.kyoto-u.ac.jp>
References: <485FC006.609@usgs.gov>
	<485FD45D.1040101@gmail.com>	<48605FBE.5090904@ar.media.kyoto-u.ac.jp>
	<48614A3C.10604@usgs.gov>	<3d375d730806241243u1e4d2b9fh35fdcdacad3aa1fd@mail.gmail.com>	<4861624C.5080101@usgs.gov>
	<4861671F.6080203@gmail.com> <4861A60F.7080607@usgs.gov>
	<4861B69E.5060607@ar.media.kyoto-u.ac.jp>
Message-ID: <48624FF0.6070601@usgs.gov>

David - _Now_ I'm ready to try the repository :)  Is there a way to 
ensure that the numpy/scipy RPMs get installed with a /usr/local/bin 
version of python, instead of the outdated /usr/bin/python that comes 
with RHEL?

--Mike

David Cournapeau wrote:
> Michael Hearne wrote:
>   
>> Phil et. al. - I believe that you and probably others do not have this 
>> problem, but I continue to have it.  I just downloaded the most recent 
>> svn version of scipy and re-attempted the build and install.  The build 
>> was successful, but the install complained about ufmpack.
>>   
>>     
>
> Could you give us the whole build log (after removing the build
> directory, i.e. from scratch) ? It looks like you found a bug in the
> configuration system at some point.
>
> Also, did you try the ashigabou repository ? It should be easy to try,
> and if it works, it should right away (also, if this one works for you,
> it should work for everybody, since binary install, once working, are
> much easier to do).
>
> cheers,
>
> David
>   

-- 
------------------------------------------------------
Michael Hearne
mhearne at usgs.gov
(303) 273-8620
USGS National Earthquake Information Center
1711 Illinois St. Golden CO 80401
Senior Software Engineer
Synergetics, Inc.
------------------------------------------------------



From mellerf at netvision.net.il  Wed Jun 25 12:06:27 2008
From: mellerf at netvision.net.il (Yosef Meller)
Date: Wed, 25 Jun 2008 19:06:27 +0300
Subject: [SciPy-dev] Removing globals from minpack wrapper
Message-ID: <48626D03.7030001@netvision.net.il>


I was having my fun with optimize.fsolve() at work, when I realized that 
both the Python side and the C/FORTRAN side allocate work spaces, and 
then copy between them, which seemed wasteful. I started playing around 
with the code to try and create a version that allows the same buffer to 
move around between Python and minpack.

I couldn't do that (and I doubt now that it's possible), but on the way 
I found a method to remove the global variables that are used to store 
the data needed by the multipack functions but not passed in by the 
FORTRAN code which doesn't even know about it.

The trick was to allocate extra space on the work buffers and use it as 
a pointer to a structure that contains the information. This may seem 
just as ugly, but it has all the advantages of not using globals, 
including the prospects of someday making it thread-safe.

The attached patch implements the trick in minpack_hybrj, and the Python 
code tests that it works.

Do you think it's worth doing to the rest of the minpack functions?

-- 
http://yosefm.imagekind.com/Eclectic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nuke_globals.patch
Type: text/x-diff
Size: 6132 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080625/6f13e577/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_globals_nuke.py
Type: text/x-python
Size: 284 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080625/6f13e577/attachment.py>

From nwagner at iam.uni-stuttgart.de  Wed Jun 25 12:17:23 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Wed, 25 Jun 2008 18:17:23 +0200
Subject: [SciPy-dev] Building numpy/scipy on RHEL5 OR CentOS5
In-Reply-To: <d05265cb0806250652p84ad52yd45c1a7ad954c90f@mail.gmail.com>
References: <485FC006.609@usgs.gov> <485FD45D.1040101@gmail.com>
	<48605FBE.5090904@ar.media.kyoto-u.ac.jp> <48614A3C.10604@usgs.gov>
	<3d375d730806241243u1e4d2b9fh35fdcdacad3aa1fd@mail.gmail.com>
	<4861624C.5080101@usgs.gov> <4861671F.6080203@gmail.com>
	<4861A60F.7080607@usgs.gov> <4861BC3A.3020401@gmail.com>
	<4862494D.4010207@usgs.gov>
	<d05265cb0806250652p84ad52yd45c1a7ad954c90f@mail.gmail.com>
Message-ID: <web-103830439@uni-stuttgart.de>

On Wed, 25 Jun 2008 08:52:55 -0500
  "Nathan Bell" <wnbell at gmail.com> wrote:
> On Wed, Jun 25, 2008 at 8:34 AM, Michael Hearne 
><mhearne at usgs.gov> wrote:
>>
>> That being said, can I make a suggestion that setup.py 
>>for scipy take an
>> option that can turn UMFPACK off, instead of the user 
>>having to remember
>> to do it in the shell, and causing him or herself the 
>>same sort of
>> confusion I just caused?
>>
> 
> UMFPACK support is being removed after SciPy 0.7, so it 
  
Just curious. Is UMFPACK support guaranteed by its scikits 
entry ?
Is there any surrogate for UMFPACK in scipy ?
I mean the delopment of SuperLU is finished (AFAIK).

Nils


From nwagner at iam.uni-stuttgart.de  Wed Jun 25 14:01:10 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Wed, 25 Jun 2008 20:01:10 +0200
Subject: [SciPy-dev] Ticket #243
Message-ID: <web-103833774@uni-stuttgart.de>

Hi David,

It should be fairly easy to close

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

A unique interface to QR in numpy/scipy would be fine.

BTW, do you see a possibility for a rank revealing feature
in this context ?

Nils




From matthieu.brucher at gmail.com  Thu Jun 26 04:01:36 2008
From: matthieu.brucher at gmail.com (Matthieu Brucher)
Date: Thu, 26 Jun 2008 10:01:36 +0200
Subject: [SciPy-dev] Genetic algorithms in scipy/scikits
In-Reply-To: <web-103778898@uni-stuttgart.de>
References: <web-103778248@uni-stuttgart.de>
	<e76aa17f0806240938k165653ccse8ee331368bc67ae@mail.gmail.com>
	<web-103778898@uni-stuttgart.de>
Message-ID: <e76aa17f0806260101l6e0db094s6dd6494729e0d207@mail.gmail.com>

Hi Nils,

I've committed a patch that deactivates the SFINAE stuff for gcc <
4.1. I couldn't get my hand on a gcc 3.3, so could you check if it is
working now ?

Thanks,
Matthieu

2008/6/24 Nils Wagner <nwagner at iam.uni-stuttgart.de>:
> On Tue, 24 Jun 2008 18:38:14 +0200
>  "Matthieu Brucher" <matthieu.brucher at gmail.com> wrote:
>> Hi,
>>
>> That would be my task to find the solution, as this
>>matrix library
>> (and the manifold learning submodule) is taken from my
>>work.
>>
>> Just a guess, are you using (the stupidly-non-standard)
>>gcc 4.0.x ? If
>> it is the case, I know how to solve it. In fact the
>>SNIFAE
>> construction does not work with gcc 4.0, which I use to
>>check if I can
>> use iterator copy or a for loop.
>>
>> Matthieu
>>
>
> Hi Matthieu,
>
> I wasn't aware of that.
> Actually the ticket was assigned to David.
>
> I am using
>  gcc --version
> gcc (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux)
> Copyright (C) 2003 Free Software Foundation, Inc.
> This is free software; see the source for copying
> conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
>
> Nils
>
> _______________________________________________
> 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


From oliphant at enthought.com  Thu Jun 26 04:15:41 2008
From: oliphant at enthought.com (Travis E. Oliphant)
Date: Thu, 26 Jun 2008 03:15:41 -0500
Subject: [SciPy-dev] Removing globals from minpack wrapper
In-Reply-To: <48626D03.7030001@netvision.net.il>
References: <48626D03.7030001@netvision.net.il>
Message-ID: <4863502D.3020507@enthought.com>

Yosef Meller wrote:
>
> I was having my fun with optimize.fsolve() at work, when I realized 
> that both the Python side and the C/FORTRAN side allocate work spaces, 
> and then copy between them, which seemed wasteful. I started playing 
> around with the code to try and create a version that allows the same 
> buffer to move around between Python and minpack.
>
> I couldn't do that (and I doubt now that it's possible), but on the 
> way I found a method to remove the global variables that are used to 
> store the data needed by the multipack functions but not passed in by 
> the FORTRAN code which doesn't even know about it.
>
> The trick was to allocate extra space on the work buffers and use it 
> as a pointer to a structure that contains the information. This may 
> seem just as ugly, but it has all the advantages of not using globals, 
> including the prospects of someday making it thread-safe.
>
> The attached patch implements the trick in minpack_hybrj, and the 
> Python code tests that it works.
>
> Do you think it's worth doing to the rest of the minpack functions?

That is pretty clever.   Amy I correct that the only time cost is an 
extra array allocation (for ap_fvec) per complete calla?

I think it is worth it.    Using globals requires a bit of rigging to 
support re-entrance of the optimizers (so you could have a python 
function that itself calls optimize).  

Thanks for looking at the code.

-Travis



From nwagner at iam.uni-stuttgart.de  Thu Jun 26 04:16:37 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Thu, 26 Jun 2008 10:16:37 +0200
Subject: [SciPy-dev] Genetic algorithms in scipy/scikits
In-Reply-To: <e76aa17f0806260101l6e0db094s6dd6494729e0d207@mail.gmail.com>
References: <web-103778248@uni-stuttgart.de>
	<e76aa17f0806240938k165653ccse8ee331368bc67ae@mail.gmail.com>
	<web-103778898@uni-stuttgart.de>
	<e76aa17f0806260101l6e0db094s6dd6494729e0d207@mail.gmail.com>
Message-ID: <web-103852611@uni-stuttgart.de>

On Thu, 26 Jun 2008 10:01:36 +0200
  "Matthieu Brucher" <matthieu.brucher at gmail.com> wrote:
> Hi Nils,
> 
> I've committed a patch that deactivates the SFINAE stuff 
>for gcc <
> 4.1. I couldn't get my hand on a gcc 3.3, so could you 
>check if it is
> working now ?
> 
> Thanks,
> Matthieu
>  
Hi Matthieu,

Works for me. Thank you very much !

I can't use ga and ann.

>>> from scikits.learn.machine import svm
/data/home/nwagner/local/lib/python2.5/site-packages/scikits/learn/machine/svm/__init__.py:70: 
DeprecationWarning: NumpyTest will be removed in the next 
release; please update your code to use nose or unittest
   test = NumpyTest().test
>>> from scikits.learn.machine import ga
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
ImportError: cannot import name ga
>>> from scikits.learn.machine import em
/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/__init__.py:370: 
UserWarning: matplotlibrc text.usetex can not be used with 
*Agg backend unless dvipng-1.5 or later is installed on 
your system
   warnings.warn( 'matplotlibrc text.usetex can not be 
used with *Agg '
/data/home/nwagner/local/lib/python2.5/site-packages/scikits/learn/machine/em/__init__.py:13: 
DeprecationWarning: NumpyTest will be removed in the next 
release; please update your code to use nose or unittest
   test = NumpyTest().test
>>> from scikits.learn.machine import manifold_learning
>>> from scikits.learn.machine import ann
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
ImportError: cannot import name ann

Nils


From matthieu.brucher at gmail.com  Thu Jun 26 04:37:38 2008
From: matthieu.brucher at gmail.com (Matthieu Brucher)
Date: Thu, 26 Jun 2008 10:37:38 +0200
Subject: [SciPy-dev] Genetic algorithms in scipy/scikits
In-Reply-To: <web-103852611@uni-stuttgart.de>
References: <web-103778248@uni-stuttgart.de>
	<e76aa17f0806240938k165653ccse8ee331368bc67ae@mail.gmail.com>
	<web-103778898@uni-stuttgart.de>
	<e76aa17f0806260101l6e0db094s6dd6494729e0d207@mail.gmail.com>
	<web-103852611@uni-stuttgart.de>
Message-ID: <e76aa17f0806260137x5ff85066hd91537924e986091@mail.gmail.com>

2008/6/26 Nils Wagner <nwagner at iam.uni-stuttgart.de>:
> On Thu, 26 Jun 2008 10:01:36 +0200
>  "Matthieu Brucher" <matthieu.brucher at gmail.com> wrote:
>> Hi Nils,
>>
>> I've committed a patch that deactivates the SFINAE stuff
>>for gcc <
>> 4.1. I couldn't get my hand on a gcc 3.3, so could you
>>check if it is
>> working now ?
>>
>> Thanks,
>> Matthieu
>>
> Hi Matthieu,
>
> Works for me. Thank you very much !

Thank you for the feedback :D I'll close the associated ticket.
I don't know what's happening with ga or ann though.

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 nwagner at iam.uni-stuttgart.de  Thu Jun 26 12:32:55 2008
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Thu, 26 Jun 2008 18:32:55 +0200
Subject: [SciPy-dev] Genetic algorithms in scipy/scikits
In-Reply-To: <e76aa17f0806260137x5ff85066hd91537924e986091@mail.gmail.com>
References: <web-103778248@uni-stuttgart.de>
	<e76aa17f0806240938k165653ccse8ee331368bc67ae@mail.gmail.com>
	<web-103778898@uni-stuttgart.de>
	<e76aa17f0806260101l6e0db094s6dd6494729e0d207@mail.gmail.com>
	<web-103852611@uni-stuttgart.de>
	<e76aa17f0806260137x5ff85066hd91537924e986091@mail.gmail.com>
Message-ID: <web-103881397@uni-stuttgart.de>

On Thu, 26 Jun 2008 10:37:38 +0200
  "Matthieu Brucher" <matthieu.brucher at gmail.com> wrote:
> 2008/6/26 Nils Wagner <nwagner at iam.uni-stuttgart.de>:
>> On Thu, 26 Jun 2008 10:01:36 +0200
>>  "Matthieu Brucher" <matthieu.brucher at gmail.com> wrote:
>>> Hi Nils,
>>>
>>> I've committed a patch that deactivates the SFINAE stuff
>>>for gcc <
>>> 4.1. I couldn't get my hand on a gcc 3.3, so could you
>>>check if it is
>>> working now ?
>>>
>>> Thanks,
>>> Matthieu
>>>
>> Hi Matthieu,
>>
>> Works for me. Thank you very much !
> 
> Thank you for the feedback :D I'll close the associated 
>ticket.
> I don't know what's happening with ga or ann though.
> 
> Matthieu
  
Who is responsible for ga and ann ?
Is it advisable to file a ticket ?

Nils


From mellerf at netvision.net.il  Thu Jun 26 13:07:47 2008
From: mellerf at netvision.net.il (Yosef Meller)
Date: Thu, 26 Jun 2008 20:07:47 +0300
Subject: [SciPy-dev] Removing globals from minpack wrapper
In-Reply-To: <4863502D.3020507@enthought.com>
References: <48626D03.7030001@netvision.net.il>
	<4863502D.3020507@enthought.com>
Message-ID: <4863CCE3.6090609@netvision.net.il>

Travis E. Oliphant wrote:
> Yosef Meller wrote:
[snip]
>> The attached patch implements the trick in minpack_hybrj, and the 
>> Python code tests that it works.
>>
>> Do you think it's worth doing to the rest of the minpack functions?
> 
> That is pretty clever.   Amy I correct that the only time cost is an 
> extra array allocation (for ap_fvec) per complete calla?

That's about right. Maybe there's extra O(evals) pointer retrievals, but 
that's much smaller than O(n) if I understand this correctly.

> I think it is worth it.    Using globals requires a bit of rigging to 
> support re-entrance of the optimizers (so you could have a python 
> function that itself calls optimize).  

I'll try to keep the patches coming.

-- 
http://yosefm.imagekind.com/Eclectic


From rmay31 at gmail.com  Fri Jun 27 16:44:46 2008
From: rmay31 at gmail.com (Ryan May)
Date: Fri, 27 Jun 2008 16:44:46 -0400
Subject: [SciPy-dev] 0.7 release schedule
In-Reply-To: <web-103638904@uni-stuttgart.de>
References: <d05265cb0806191725x3b1da1caq72083cb7d734dce4@mail.gmail.com>	<485B20B7.9040002@ar.media.kyoto-u.ac.jp>	<d05265cb0806192119k2ba5f40bw982f10840722b5f4@mail.gmail.com>	<485B2D68.1020708@ar.media.kyoto-u.ac.jp>	<web-103617420@uni-stuttgart.de>	<485CAA19.8050504@ar.media.kyoto-u.ac.jp>	<web-103635529@uni-stuttgart.de>	<485CC2D1.4030300@ar.media.kyoto-u.ac.jp>
	<web-103638904@uni-stuttgart.de>
Message-ID: <4865513E.8090807@gmail.com>

Hi,

Can I get someone to look at this #581 for 0.7 as well? I've put up a 
patch that fixes it for me.

http://scipy.org/scipy/scipy/ticket/581

Thanks,

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma


From travis at enthought.com  Fri Jun 27 19:05:03 2008
From: travis at enthought.com (Travis Vaught)
Date: Fri, 27 Jun 2008 18:05:03 -0500
Subject: [SciPy-dev] SciPy Conference Updates
Message-ID: <ABD929C5-6605-4D70-8EA3-224F9543301C@enthought.com>

Greetings,

The SciPy Conference is not too far away.  I thought I'd summarize  
some recent news about the conference in case some of you missed it:


- Accommodations (news!): We've negotiated a group rate with a nearby  
Marriott hotel, for those that would like to take advantage of it.   
The hotel has set up a web site for our event here:

http://cwp.marriott.com/laxot/scipyworkshop/

- Student Sponsorship: As you may have seen, the Python Software  
Foundation has agreed to partner with Enthought to sponsor 10  
students' travel, registration, and accommodation for the tutorials,  
conference and (most importantly) sprints.  If you're in college or a  
graduate program, please check out the details here:

http://conference.scipy.org/sponsoring

- Abstracts Submission Deadline Extended:  The review committee is  
extending the deadline to Monday, June 30th.  Please see the Call for  
Papers for instructions on abstract submission here:

http://conference.scipy.org/call_for_papers


Please drop me an email if you have any questions or comments.

Best,

Travis


From david at ar.media.kyoto-u.ac.jp  Sat Jun 28 00:25:32 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Sat, 28 Jun 2008 13:25:32 +0900
Subject: [SciPy-dev] Building numpy/scipy on RHEL5 OR CentOS5
In-Reply-To: <web-103830439@uni-stuttgart.de>
References: <485FC006.609@usgs.gov>
	<485FD45D.1040101@gmail.com>	<48605FBE.5090904@ar.media.kyoto-u.ac.jp>
	<48614A3C.10604@usgs.gov>	<3d375d730806241243u1e4d2b9fh35fdcdacad3aa1fd@mail.gmail.com>	<4861624C.5080101@usgs.gov>
	<4861671F.6080203@gmail.com>	<4861A60F.7080607@usgs.gov>
	<4861BC3A.3020401@gmail.com>	<4862494D.4010207@usgs.gov>	<d05265cb0806250652p84ad52yd45c1a7ad954c90f@mail.gmail.com>
	<web-103830439@uni-stuttgart.de>
Message-ID: <4865BD3C.4080209@ar.media.kyoto-u.ac.jp>

Nils Wagner wrote:
>   
> Just curious. Is UMFPACK support guaranteed by its scikits 
> entry ?
> Is there any surrogate for UMFPACK in scipy ?
> I mean the delopment of SuperLU is finished (AFAIK).
>   

As always, license issue: UMFPACK is GPL, hence not distributable in scipy.

cheers,

David


From mellerf at netvision.net.il  Sat Jun 28 08:07:25 2008
From: mellerf at netvision.net.il (Yosef Meller)
Date: Sat, 28 Jun 2008 15:07:25 +0300
Subject: [SciPy-dev] Removing globals from minpack wrapper, v2
Message-ID: <4866297D.8080506@netvision.net.il>


My continued worl on removing globals from the minpack wrapper, for your 
testing pleasure.

Changes:
  * Applied the same strategy to minpack_hybrd (mostly, but not fully, a 
copy-paste job from minpack_hybrj)
  * polished the previous code a bit.
  * Now with multithreading! in minpack_hybrj and 
jac_multipack_calling_function the GIL is released and reacquired as 
necessary. Works on my machine, and you can test it with the attached 
python program. I still haven't had the chance to test it on a dual core 
system, though, and it might be a while before I do.

-- 
http://yosefm.imagekind.com/Eclectic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_globals_nuke.py
Type: text/x-python
Size: 516 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080628/14b12096/attachment.py>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nuke_globals-v2.patch
Type: text/x-diff
Size: 10659 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20080628/14b12096/attachment.patch>

From mellerf at netvision.net.il  Mon Jun 30 11:53:53 2008
From: mellerf at netvision.net.il (Yosef Meller)
Date: Mon, 30 Jun 2008 18:53:53 +0300
Subject: [SciPy-dev] Possibly one more easy bug
Message-ID: <48690191.5000605@netvision.net.il>

http://www.scipy.org/scipy/scipy/ticket/598

in optimize/anneal.py. I posted two patches, I'm not sure which one is 
more appropriate.

-- 
http://yosefm.imagekind.com/Eclectic


From mhearne at usgs.gov  Mon Jun 30 12:10:24 2008
From: mhearne at usgs.gov (Michael Hearne)
Date: Mon, 30 Jun 2008 10:10:24 -0600
Subject: [SciPy-dev] Install error on RHEL5
Message-ID: <48690570.30109@usgs.gov>

I just finished an install of numpy/scipy/matplotlib on a 64-bit RHEL5 
system, and am now trying to replicate that on a 32-bit system.  So far, 
there are two differences:

1) fftw3 is not available through yum on the 32-bit system, so I built 
it from source.
2) Attempting to build scipy results in the error below.

Attached is a PDF with the notes (most of which came from Phil Austin) I 
compiled after installing on the 64-bit system.

I'm currently recompiling ATLAS (which takes an amazingly long time), 
and then will try to rebuild LAPACK, BLAS, etc.  Before I get there, 
does anyone have any idea what the root of the below error might be?

 usr/local/bin/python setup.py build
Traceback (most recent call last):
  File "setup.py", line 53, in <module>
    setup_package()
  File "setup.py", line 28, in setup_package
    from numpy.distutils.core import setup
  File "/usr/local/lib/python2.5/site-packages/numpy/__init__.py", line 
103, in <module>
    import linalg
  File 
"/usr/local/lib/python2.5/site-packages/numpy/linalg/__init__.py", line 
4, in <module>
    from linalg import *
  File "/usr/local/lib/python2.5/site-packages/numpy/linalg/linalg.py", 
line 29, in <module>
    from numpy.linalg import lapack_lite
ImportError: 
/usr/local/lib/python2.5/site-packages/numpy/linalg/lapack_lite.so: 
undefined symbol: cblas_zgemm


Thanks,

Mike

-- 
------------------------------------------------------
Michael Hearne
mhearne at usgs.gov
(303) 273-8620
USGS National Earthquake Information Center
1711 Illinois St. Golden CO 80401
Senior Software Engineer
Synergetics, Inc.
------------------------------------------------------



From robert.kern at gmail.com  Mon Jun 30 12:21:59 2008
From: robert.kern at gmail.com (robert.kern at gmail.com)
Date: Mon, 30 Jun 2008 11:21:59 -0500
Subject: [SciPy-dev] Possibly one more easy bug
In-Reply-To: <48690191.5000605@netvision.net.il>
References: <48690191.5000605@netvision.net.il>
Message-ID: <3d375d730806300921y689d387t4d980a715029a55@mail.gmail.com>

On 2008-06-30, Yosef Meller <mellerf at netvision.net.il> wrote:
> http://www.scipy.org/scipy/scipy/ticket/598
>
> in optimize/anneal.py. I posted two patches, I'm not sure which one is
> more appropriate.

Fixed in r4505. Thank you.

-- 
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 fperez.net at gmail.com  Mon Jun 30 18:12:40 2008
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 30 Jun 2008 15:12:40 -0700
Subject: [SciPy-dev] Python/Sage minisymposium at SIAM Annual meeting July
	9/10 2008
Message-ID: <db6b5ecc0806301512j4fff0558u45f635fc7ed524e2@mail.gmail.com>

Hi all,

this is just a reminder, in case you'll be attending the SIAM 2008
annual meeting next week in San Diego, that there will be a 3-part
minisymposium focusing on the uses of Python and Sage in scientific
computing:

http://meetings.siam.org/sess/dsp_programsess.cfm?SESSIONCODE=7369
http://meetings.siam.org/sess/dsp_programsess.cfm?SESSIONCODE=7370
http://meetings.siam.org/sess/dsp_programsess.cfm?SESSIONCODE=7447

We hope to see many of you there!

Regards,

Fernando and Randy


From david at ar.media.kyoto-u.ac.jp  Mon Jun 30 23:31:37 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Tue, 01 Jul 2008 12:31:37 +0900
Subject: [SciPy-dev] Install error on RHEL5
In-Reply-To: <48690570.30109@usgs.gov>
References: <48690570.30109@usgs.gov>
Message-ID: <4869A519.7020301@ar.media.kyoto-u.ac.jp>

Michael Hearne wrote:
> I just finished an install of numpy/scipy/matplotlib on a 64-bit RHEL5 
> system, and am now trying to replicate that on a 32-bit system.  So far, 
> there are two differences:
>
> 1) fftw3 is not available through yum on the 32-bit system, so I built 
> it from source.
>   

That's strange. I doubt that any software available on 64 bits are not
available on 32 bits.

> 2) Attempting to build scipy results in the error below.
>
> Attached is a PDF with the notes (most of which came from Phil Austin) I 
> compiled after installing on the 64-bit system.
>
> I'm currently recompiling ATLAS (which takes an amazingly long time), 
> and then will try to rebuild LAPACK, BLAS, etc.  Before I get there, 
> does anyone have any idea what the root of the below error might be?
>
>  usr/local/bin/python setup.py build
> Traceback (most recent call last):
>   File "setup.py", line 53, in <module>
>     setup_package()
>   File "setup.py", line 28, in setup_package
>     from numpy.distutils.core import setup
>   File "/usr/local/lib/python2.5/site-packages/numpy/__init__.py", line 
> 103, in <module>
>     import linalg
>   File 
> "/usr/local/lib/python2.5/site-packages/numpy/linalg/__init__.py", line 
> 4, in <module>
>     from linalg import *
>   File "/usr/local/lib/python2.5/site-packages/numpy/linalg/linalg.py", 
> line 29, in <module>
>     from numpy.linalg import lapack_lite
> ImportError: 
> /usr/local/lib/python2.5/site-packages/numpy/linalg/lapack_lite.so: 
> undefined symbol: cblas_zgemm
>
>   

Again, without the full build log, we can't really help you. I would
guess that your blas/lapack is not built correctly. Are you using
blas/lapack from netlib ?

You should really use packages first, and only if it does not work, try
to build from sources.

cheers,

David