From clemens at familie-novak.net  Thu Aug  1 07:42:39 2013
From: clemens at familie-novak.net (Clemens Novak)
Date: Thu, 01 Aug 2013 13:42:39 +0200
Subject: [SciPy-Dev] Contributing to the Documentation
Message-ID: <ea524ffb99045dce445537540920af12@scorpius.uberspace.de>

Hi,

i've been working with scipy for some time and am a great fan of the 
tutorial pages. I've found some spots where some additional information 
/ an example would be nice (at least in my opinion); e.g. the 
scipy.signal part explains a lot of concepts, but some examples would be 
helpful; scipy.fftpack would require some attention...

On the contribution page you encourage enhancements to scipy's 
documentation - is still so, and - if yes - do you prefer pull requests 
(via Github) or is it better to use the documentation wiki?

Regards - Clemens



From ralf.gommers at gmail.com  Thu Aug  1 13:56:21 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Thu, 1 Aug 2013 19:56:21 +0200
Subject: [SciPy-Dev] Contributing to the Documentation
In-Reply-To: <ea524ffb99045dce445537540920af12@scorpius.uberspace.de>
References: <ea524ffb99045dce445537540920af12@scorpius.uberspace.de>
Message-ID: <CABL7CQj-zFWAB+EF7TU6zUFgLttgSAE=SciYHUofbB2nEV4L0A@mail.gmail.com>

On Thu, Aug 1, 2013 at 1:42 PM, Clemens Novak <clemens at familie-novak.net>wrote:

> Hi,
>
> i've been working with scipy for some time and am a great fan of the
> tutorial pages. I've found some spots where some additional information
> / an example would be nice (at least in my opinion); e.g. the
> scipy.signal part explains a lot of concepts, but some examples would be
> helpful; scipy.fftpack would require some attention...
>

Hi Clemens, contributions to these tutorials would be very welcome!

On the contribution page you encourage enhancements to scipy's
> documentation - is still so, and - if yes - do you prefer pull requests
> (via Github) or is it better to use the documentation wiki?
>

We indeed prefer pull requests, those are quite a bit easier to review and
merge. We keep the documentation wiki for people who just want to make a
quick edit or are uncomfortable working with git.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130801/a72dd5a0/attachment.html>

From juanlu001 at gmail.com  Thu Aug  1 16:22:02 2013
From: juanlu001 at gmail.com (Juan Luis Cano)
Date: Thu, 01 Aug 2013 22:22:02 +0200
Subject: [SciPy-Dev] Contributing to the Documentation
In-Reply-To: <CABL7CQj-zFWAB+EF7TU6zUFgLttgSAE=SciYHUofbB2nEV4L0A@mail.gmail.com>
References: <ea524ffb99045dce445537540920af12@scorpius.uberspace.de>
	<CABL7CQj-zFWAB+EF7TU6zUFgLttgSAE=SciYHUofbB2nEV4L0A@mail.gmail.com>
Message-ID: <51FAC36A.1010001@gmail.com>

On 08/01/2013 07:56 PM, Ralf Gommers wrote:
>
>     On the contribution page you encourage enhancements to scipy's
>     documentation - is still so, and - if yes - do you prefer pull
>     requests
>     (via Github) or is it better to use the documentation wiki?
>
>
> We indeed prefer pull requests, those are quite a bit easier to review 
> and merge. We keep the documentation wiki for people who just want to 
> make a quick edit or are uncomfortable working with git.

What about the "Edit" button on GitHub?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130801/c0448115/attachment.html>

From lists at hilboll.de  Thu Aug  1 16:37:37 2013
From: lists at hilboll.de (Andreas Hilboll)
Date: Thu, 01 Aug 2013 22:37:37 +0200
Subject: [SciPy-Dev] Contributing to the Documentation
In-Reply-To: <51FAC36A.1010001@gmail.com>
References: <ea524ffb99045dce445537540920af12@scorpius.uberspace.de>
	<CABL7CQj-zFWAB+EF7TU6zUFgLttgSAE=SciYHUofbB2nEV4L0A@mail.gmail.com>
	<51FAC36A.1010001@gmail.com>
Message-ID: <51FAC711.7000804@hilboll.de>

Am Do 01 Aug 2013 22:22:02 CEST schrieb Juan Luis Cano:
> On 08/01/2013 07:56 PM, Ralf Gommers wrote:
>>
>>     On the contribution page you encourage enhancements to scipy's
>>     documentation - is still so, and - if yes - do you prefer pull
>>     requests
>>     (via Github) or is it better to use the documentation wiki?
>>
>>
>> We indeed prefer pull requests, those are quite a bit easier to
>> review and merge. We keep the documentation wiki for people who just
>> want to make a quick edit or are uncomfortable working with git.
>
> What about the "Edit" button on GitHub?

That just creates a fork and sends a pull request, all "under the hood".

-- Andreas.


From ralf.gommers at gmail.com  Thu Aug  1 16:41:33 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Thu, 1 Aug 2013 22:41:33 +0200
Subject: [SciPy-Dev] Contributing to the Documentation
In-Reply-To: <51FAC711.7000804@hilboll.de>
References: <ea524ffb99045dce445537540920af12@scorpius.uberspace.de>
	<CABL7CQj-zFWAB+EF7TU6zUFgLttgSAE=SciYHUofbB2nEV4L0A@mail.gmail.com>
	<51FAC36A.1010001@gmail.com> <51FAC711.7000804@hilboll.de>
Message-ID: <CABL7CQiqiBtQ+O=EvtQY1yTTr1XnDnxTWQxtq0MscNPBHD5cPg@mail.gmail.com>

On Thu, Aug 1, 2013 at 10:37 PM, Andreas Hilboll <lists at hilboll.de> wrote:

> Am Do 01 Aug 2013 22:22:02 CEST schrieb Juan Luis Cano:
> > On 08/01/2013 07:56 PM, Ralf Gommers wrote:
> >>
> >>     On the contribution page you encourage enhancements to scipy's
> >>     documentation - is still so, and - if yes - do you prefer pull
> >>     requests
> >>     (via Github) or is it better to use the documentation wiki?
> >>
> >>
> >> We indeed prefer pull requests, those are quite a bit easier to
> >> review and merge. We keep the documentation wiki for people who just
> >> want to make a quick edit or are uncomfortable working with git.
> >
> > What about the "Edit" button on GitHub?
>
> That just creates a fork and sends a pull request, all "under the hood".


I think Juan knows that, the question is whether we'd like people to use
that instead of the doc wiki. To be honest I don't know, haven't tried it
myself yet. If it works well then maybe yes, but probably only for small
edits (unless you can go back and add more commits to the same PR.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130801/1fa386c5/attachment.html>

From juanlu001 at gmail.com  Thu Aug  1 17:10:46 2013
From: juanlu001 at gmail.com (Juan Luis Cano)
Date: Thu, 01 Aug 2013 23:10:46 +0200
Subject: [SciPy-Dev] Contributing to the Documentation
In-Reply-To: <CABL7CQiqiBtQ+O=EvtQY1yTTr1XnDnxTWQxtq0MscNPBHD5cPg@mail.gmail.com>
References: <ea524ffb99045dce445537540920af12@scorpius.uberspace.de>
	<CABL7CQj-zFWAB+EF7TU6zUFgLttgSAE=SciYHUofbB2nEV4L0A@mail.gmail.com>
	<51FAC36A.1010001@gmail.com> <51FAC711.7000804@hilboll.de>
	<CABL7CQiqiBtQ+O=EvtQY1yTTr1XnDnxTWQxtq0MscNPBHD5cPg@mail.gmail.com>
Message-ID: <51FACED6.1080307@gmail.com>

On 08/01/2013 10:41 PM, Ralf Gommers wrote:
>
>
>
> On Thu, Aug 1, 2013 at 10:37 PM, Andreas Hilboll <lists at hilboll.de 
> <mailto:lists at hilboll.de>> wrote:
>
>     Am Do 01 Aug 2013 22:22:02 CEST schrieb Juan Luis Cano:
>     > On 08/01/2013 07:56 PM, Ralf Gommers wrote:
>     >>
>     >>     On the contribution page you encourage enhancements to scipy's
>     >>     documentation - is still so, and - if yes - do you prefer pull
>     >>     requests
>     >>     (via Github) or is it better to use the documentation wiki?
>     >>
>     >>
>     >> We indeed prefer pull requests, those are quite a bit easier to
>     >> review and merge. We keep the documentation wiki for people who
>     just
>     >> want to make a quick edit or are uncomfortable working with git.
>     >
>     > What about the "Edit" button on GitHub?
>
>     That just creates a fork and sends a pull request, all "under the
>     hood".
>
>
> I think Juan knows that, the question is whether we'd like people to 
> use that instead of the doc wiki. To be honest I don't know, haven't 
> tried it myself yet. If it works well then maybe yes, but probably 
> only for small edits (unless you can go back and add more commits to 
> the same PR.
>
> Ralf

Yes, I was thinking of using GitHub edition instead of the wiki for 
little changes. The good thing, as Ralf points out, is that you can add 
new commits.

Are there any numbers of editions submitted through the wiki lately? 
Because if people is not using it anyway, that system could be dropped 
in favor of GitHub. I don't think Edit + solving PR is more difficult 
than the wiki.

Juan Luis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130801/8007fade/attachment.html>

From ralf.gommers at gmail.com  Thu Aug  1 17:29:05 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Thu, 1 Aug 2013 23:29:05 +0200
Subject: [SciPy-Dev] Contributing to the Documentation
In-Reply-To: <51FACED6.1080307@gmail.com>
References: <ea524ffb99045dce445537540920af12@scorpius.uberspace.de>
	<CABL7CQj-zFWAB+EF7TU6zUFgLttgSAE=SciYHUofbB2nEV4L0A@mail.gmail.com>
	<51FAC36A.1010001@gmail.com> <51FAC711.7000804@hilboll.de>
	<CABL7CQiqiBtQ+O=EvtQY1yTTr1XnDnxTWQxtq0MscNPBHD5cPg@mail.gmail.com>
	<51FACED6.1080307@gmail.com>
Message-ID: <CABL7CQiS4YP8vrQ4sHKXhLebnMNfpMwAj9P6WBWj=acgZavTrQ@mail.gmail.com>

On Thu, Aug 1, 2013 at 11:10 PM, Juan Luis Cano <juanlu001 at gmail.com> wrote:

>  On 08/01/2013 10:41 PM, Ralf Gommers wrote:
>
>
>
>
> On Thu, Aug 1, 2013 at 10:37 PM, Andreas Hilboll <lists at hilboll.de> wrote:
>
>> Am Do 01 Aug 2013 22:22:02 CEST schrieb Juan Luis Cano:
>>  > On 08/01/2013 07:56 PM, Ralf Gommers wrote:
>> >>
>> >>     On the contribution page you encourage enhancements to scipy's
>> >>     documentation - is still so, and - if yes - do you prefer pull
>> >>     requests
>> >>     (via Github) or is it better to use the documentation wiki?
>> >>
>> >>
>> >> We indeed prefer pull requests, those are quite a bit easier to
>> >> review and merge. We keep the documentation wiki for people who just
>> >> want to make a quick edit or are uncomfortable working with git.
>> >
>> > What about the "Edit" button on GitHub?
>>
>>  That just creates a fork and sends a pull request, all "under the hood".
>
>
>  I think Juan knows that, the question is whether we'd like people to use
> that instead of the doc wiki. To be honest I don't know, haven't tried it
> myself yet. If it works well then maybe yes, but probably only for small
> edits (unless you can go back and add more commits to the same PR.
>
>  Ralf
>
>
> Yes, I was thinking of using GitHub edition instead of the wiki for little
> changes. The good thing, as Ralf points out, is that you can add new
> commits.
>
> Are there any numbers of editions submitted through the wiki lately?
> Because if people is not using it anyway, that system could be dropped in
> favor of GitHub. I don't think Edit + solving PR is more difficult than the
> wiki.
>

Not a huge amount, but still regular edits (thanks mainly to Tim Cera)
adding up to 1000s of words for every release. The wiki also has some
advantages if you'd want to edit larger amounts of docs, like a system to
indicate if a docstring is draft / for review / reviewed, and the option to
render a page (helps to fix formatting issues). But yes, overall I'd still
prefer PRs over wiki edits.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130801/28adb81b/attachment.html>

From juanlu001 at gmail.com  Fri Aug  2 08:38:33 2013
From: juanlu001 at gmail.com (Juan Luis Cano)
Date: Fri, 02 Aug 2013 14:38:33 +0200
Subject: [SciPy-Dev] labeling issues as easy-fix
In-Reply-To: <CABL7CQgoEgm=kvz7x=9RHoyAPVcwvjKgGk8c6H0Ck93XR_Y8uA@mail.gmail.com>
References: <CABL7CQgoEgm=kvz7x=9RHoyAPVcwvjKgGk8c6H0Ck93XR_Y8uA@mail.gmail.com>
Message-ID: <51FBA849.5020103@gmail.com>

On 07/29/2013 09:13 PM, Ralf Gommers wrote:
> Hi,
>
> At https://github.com/scipy/scipy/issues I've just added an easy-fix 
> label, to guide newcomers to issues that don't require too much scipy 
> background or hard debugging. I had planned to do that for a while, 
> and the upcoming EuroSciPy sprint is a good motivation to get it done.
>
> Any help would be much appreciated. Maybe module maintainers could go 
> through their module? Adding labels requires commit rights, but anyone 
> without those who wants to help out can either just leave a comment on 
> the ticket or send me the issue ID.
>
> Ralf

As a newcomer myself, I think this is indeed highly valuable. First 
thing I did when wondering how could I contribute to SciPy was looking 
for some sort of easy-fix label - probably because I had already seen it 
in Astropy.

Talking about maintainers, I just saw that each module's issues are 
linked in Trac. Is it desirable to replace the links with the new GitHub 
ones?

Juan Luis


From ralf.gommers at gmail.com  Fri Aug  2 08:52:42 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Fri, 2 Aug 2013 14:52:42 +0200
Subject: [SciPy-Dev] labeling issues as easy-fix
In-Reply-To: <51FBA849.5020103@gmail.com>
References: <CABL7CQgoEgm=kvz7x=9RHoyAPVcwvjKgGk8c6H0Ck93XR_Y8uA@mail.gmail.com>
	<51FBA849.5020103@gmail.com>
Message-ID: <CABL7CQi-d=Bpk2UBHFZg0-MbxoLpYa4FnM+2aMpa8krz3XnVaw@mail.gmail.com>

On Fri, Aug 2, 2013 at 2:38 PM, Juan Luis Cano <juanlu001 at gmail.com> wrote:

> On 07/29/2013 09:13 PM, Ralf Gommers wrote:
> > Hi,
> >
> > At https://github.com/scipy/scipy/issues I've just added an easy-fix
> > label, to guide newcomers to issues that don't require too much scipy
> > background or hard debugging. I had planned to do that for a while,
> > and the upcoming EuroSciPy sprint is a good motivation to get it done.
> >
> > Any help would be much appreciated. Maybe module maintainers could go
> > through their module? Adding labels requires commit rights, but anyone
> > without those who wants to help out can either just leave a comment on
> > the ticket or send me the issue ID.
> >
> > Ralf
>
> As a newcomer myself, I think this is indeed highly valuable. First
> thing I did when wondering how could I contribute to SciPy was looking
> for some sort of easy-fix label - probably because I had already seen it
> in Astropy.
>
> Talking about maintainers, I just saw that each module's issues are
> linked in Trac. Is it desirable to replace the links with the new GitHub
> ones?
>

Yes, a PR for that would be great.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130802/7f0a553b/attachment.html>

From juanlu001 at gmail.com  Fri Aug  2 11:30:35 2013
From: juanlu001 at gmail.com (Juan Luis Cano)
Date: Fri, 02 Aug 2013 17:30:35 +0200
Subject: [SciPy-Dev] labeling issues as easy-fix
In-Reply-To: <CABL7CQi-d=Bpk2UBHFZg0-MbxoLpYa4FnM+2aMpa8krz3XnVaw@mail.gmail.com>
References: <CABL7CQgoEgm=kvz7x=9RHoyAPVcwvjKgGk8c6H0Ck93XR_Y8uA@mail.gmail.com>
	<51FBA849.5020103@gmail.com>
	<CABL7CQi-d=Bpk2UBHFZg0-MbxoLpYa4FnM+2aMpa8krz3XnVaw@mail.gmail.com>
Message-ID: <51FBD09B.4070508@gmail.com>

On 08/02/2013 02:52 PM, Ralf Gommers wrote:
>
>     Talking about maintainers, I just saw that each module's issues are
>     linked in Trac. Is it desirable to replace the links with the new
>     GitHub
>     ones?
>
>
> Yes, a PR for that would be great.
>
> Ralf

Here it is!

https://github.com/scipy/scipy/pull/2679
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130802/9f7702e6/attachment.html>

From juanlu001 at gmail.com  Fri Aug  2 11:33:46 2013
From: juanlu001 at gmail.com (Juan Luis Cano)
Date: Fri, 02 Aug 2013 17:33:46 +0200
Subject: [SciPy-Dev] Contributing to the Documentation
In-Reply-To: <CABL7CQiS4YP8vrQ4sHKXhLebnMNfpMwAj9P6WBWj=acgZavTrQ@mail.gmail.com>
References: <ea524ffb99045dce445537540920af12@scorpius.uberspace.de>
	<CABL7CQj-zFWAB+EF7TU6zUFgLttgSAE=SciYHUofbB2nEV4L0A@mail.gmail.com>
	<51FAC36A.1010001@gmail.com> <51FAC711.7000804@hilboll.de>
	<CABL7CQiqiBtQ+O=EvtQY1yTTr1XnDnxTWQxtq0MscNPBHD5cPg@mail.gmail.com>
	<51FACED6.1080307@gmail.com>
	<CABL7CQiS4YP8vrQ4sHKXhLebnMNfpMwAj9P6WBWj=acgZavTrQ@mail.gmail.com>
Message-ID: <51FBD15A.5040902@gmail.com>

On 08/01/2013 11:29 PM, Ralf Gommers wrote:
> Not a huge amount, but still regular edits (thanks mainly to Tim Cera) 
> adding up to 1000s of words for every release. The wiki also has some 
> advantages if you'd want to edit larger amounts of docs, like a system 
> to indicate if a docstring is draft / for review / reviewed, and the 
> option to render a page (helps to fix formatting issues). But yes, 
> overall I'd still prefer PRs over wiki edits.

To try things out, I just edited a file with the GitHub interface. I 
copy here what I commented in the PR:

"""
I used the GitHub edition interface, and I can swear it's damn easy to 
use. I just:

 1. clicked "Edit",
 2. a nice text editor popped,
 3. I made my edits,
 4. created the commit message,
 5. clicked "propose file change",
 6. and finally "Click to create a pull request for this comparison"

"""

I suggest encouraging this method over the documentation wiki or, at 
least, keeping both. There might be people that won't create a GitHub 
account to contribute some little edits, but I don't know how the team 
would want to handle this in the long term.

Juan Luis


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130802/678683ab/attachment.html>

From charlesnwoods at gmail.com  Fri Aug  2 13:19:58 2013
From: charlesnwoods at gmail.com (Nathan Woods)
Date: Fri, 2 Aug 2013 11:19:58 -0600
Subject: [SciPy-Dev] Discussion on a new interface for multidimensional
	quadrature
Message-ID: <8A6B959D-DB30-400E-ACA3-3933912D4ED0@gmail.com>

I'm copying the most relevant parts over from a discussion on GitHub, having to do with a new n-dimensional integration tool. The discussion is whether or not to make nquad's new interface consistent with dbl-and tplquad, even though their precedent is arguably more confusing to users.

nquad is a recursively defined wrapper to scipy.integrate.quad that allows for n-dimensional integration with almost the entire list of arguments allowed by quad. It is therefore more general than either dbl- or tplquad, and encompasses their use cases, while allowing the user greater control over the integration. The interface is given: nquad( f(x0,x1,?xn,t0,?tm) ,[[x0_lo,x0_hi],?[xn_lo,xn_hi]],[t0,?tm],[opts0,?optsn]).
The ranges of integration are given in the same order as the arguments in the function to be integrated. This ordering is consistent with both Matlab and Octave, and it is similar to what is encountered in other SciPy packages such as fft. It is also what makes sense to new users. 

dbl- and tplquad, however, reverse the order of arguments in f. From the documentation for tplquad:

Return the triple integral of func(z, y, x) from x=a..b, y=gfun(x)..hfun(x), and z=qfun(x,y)..rfun(x,y)

This is confusing, and contrary to common practice.

It is proposed that nquad's calling sequence be left as is, and that the use of dbl- and tplquad be deprecated in some future version of SciPy, and that nquad be recommended for multidimensional integration in new code. dbl- and tplquad would of course be retained, though not recommended, in order to avoid breaking existing code.

Wow, that came out all legalistic. Anyway, what do you all think about this change? I have a horse in the race (I wrote most of nquad), but I really think that maintaining the backwards style from dbl- and tplquad and enshrining it in new code is a bad idea. This is a perfect time to get away from it, if that's what we want to do.

> Good question. I think this needs some discussion on the scipy-dev list, because it would be a fairly large change (dblquad/tplquad are old and widely used I think). Could you please bring it up there?
> 
>> Yeah, I remember wondering how to handle that. It's not a very difficult fix, and most of the work will be in changing over the examples and tests so they work with the new ordering. However, do we really want to stick with the old order? 
>> 
>> If we want to change it, then now is a perfect time, since nquad duplicates and extends the functionality of dbl- and tplquad. Those two could be deprecated and retained for compatibility, while nquad is recommended for new code. Since the calling sequence for nquad is so different, new users will have to adjust anyway.
>> 
>> The current argument list for tplquad is confusing. The order of arguments in the function does not match with the order of the range functions that must be provided, which is a source of confusion. The ordering was presumably chosen to make things look as much like quad as possible, but is that really important now?
>> 
>> As a reference, Matlab's integral3 and triplequad and GNU Octave's triple quad both order things (x,y,z). SciPy's fft2 also appears to do things the same way.
> 
>>> There's one thing that needs discussion: the integration order is reversed compared to dblquad and tplquad. Where you'd use def func3d(z, y, x) in tplquad you have to use def func3d(x, y, z) here. I was never a fan of the order in dbp/tplquad, but we're stuck with that and I thinknquad should use that same order for consistency.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130802/440fbd0c/attachment.html>

From ralf.gommers at gmail.com  Fri Aug  2 13:47:19 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Fri, 2 Aug 2013 19:47:19 +0200
Subject: [SciPy-Dev] welcome Alex Griffing to the scipy team
Message-ID: <CABL7CQi26Zdy7oFJ9k0Ha55Qt8R-A-sw4uy_pYx-KjK7_id46Q@mail.gmail.com>

Hi all,

I'd like to welcome Alex Griffing to the scipy development team. He was
effectively already a part of it as many of you may have noticed but we've
made it official by giving him commit rights. Alex has done quite some work
on linalg over the last months, and more maintenance work and PR reviewing
in other modules: see:
https://www.ohloh.net/p/scipy/contributors/21026012405206).

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130802/14a6cb1a/attachment.html>

From tim at cerazone.net  Fri Aug  2 14:12:10 2013
From: tim at cerazone.net (Cera, Tim)
Date: Fri, 2 Aug 2013 14:12:10 -0400
Subject: [SciPy-Dev] Contributing to the Documentation
In-Reply-To: <51FBD15A.5040902@gmail.com>
References: <ea524ffb99045dce445537540920af12@scorpius.uberspace.de>
	<CABL7CQj-zFWAB+EF7TU6zUFgLttgSAE=SciYHUofbB2nEV4L0A@mail.gmail.com>
	<51FAC36A.1010001@gmail.com> <51FAC711.7000804@hilboll.de>
	<CABL7CQiqiBtQ+O=EvtQY1yTTr1XnDnxTWQxtq0MscNPBHD5cPg@mail.gmail.com>
	<51FACED6.1080307@gmail.com>
	<CABL7CQiS4YP8vrQ4sHKXhLebnMNfpMwAj9P6WBWj=acgZavTrQ@mail.gmail.com>
	<51FBD15A.5040902@gmail.com>
Message-ID: <CAO5s+D-di=J9Q=17zWj4ZmS1k8ix+fu2TJGq3_EnJ9nHDa88hA@mail.gmail.com>

On Fri, Aug 2, 2013 at 11:33 AM, Juan Luis Cano <juanlu001 at gmail.com> wrote:

>  On 08/01/2013 11:29 PM, Ralf Gommers wrote:
>
> Not a huge amount, but still regular edits (thanks mainly to Tim Cera)
> adding up to 1000s of words for every release. The wiki also has some
> advantages if you'd want to edit larger amounts of docs, like a system to
> indicate if a docstring is draft / for review / reviewed, and the option to
> render a page (helps to fix formatting issues). But yes, overall I'd still
> prefer PRs over wiki edits.
>
>
I got used to the editor.  And I am now going to type a bit of heresy: I
use git, but I really don't like it.  The complexity/benefit ratio is too
high for my poor brain.

There is an overlooked advantage to the editor in that when edits are
previewed there are several tests that validate the docstring you are
working on.  Those tests could be made part of the test suite (and
expanded), but currently they are only in the on-line editor.

Also, there are bug fixes and additional features in the development
version of pydocweb that would be nice to see in the on-line doc editor.
 Actually, these might have been implemented, apologies if anyone has
already done this - haven't been on in awhile.

And in terms of editing the docstrings, there are many discussions,
comments, ...etc. about different format issues that are scattered across
the e-mail list, the discussion section of the on-line editor - but very
few decisions.  Really would be helpful to codify all of these discussions
into decisions, write them down, AND implement them as tests.

Kindest regards,
Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130802/076bafa9/attachment.html>

From warren.weckesser at gmail.com  Fri Aug  2 14:28:41 2013
From: warren.weckesser at gmail.com (Warren Weckesser)
Date: Fri, 2 Aug 2013 14:28:41 -0400
Subject: [SciPy-Dev] welcome Alex Griffing to the scipy team
In-Reply-To: <CABL7CQi26Zdy7oFJ9k0Ha55Qt8R-A-sw4uy_pYx-KjK7_id46Q@mail.gmail.com>
References: <CABL7CQi26Zdy7oFJ9k0Ha55Qt8R-A-sw4uy_pYx-KjK7_id46Q@mail.gmail.com>
Message-ID: <CAGzF1udE=K+3gtTD3jo-39ocaS3xJFZvyaQfVx5_i07FUt2VFw@mail.gmail.com>

Welcome, Alex.  Thanks for all the great work so far, and keep it coming!

Warren



On Fri, Aug 2, 2013 at 1:47 PM, Ralf Gommers <ralf.gommers at gmail.com> wrote:

> Hi all,
>
> I'd like to welcome Alex Griffing to the scipy development team. He was
> effectively already a part of it as many of you may have noticed but we've
> made it official by giving him commit rights. Alex has done quite some work
> on linalg over the last months, and more maintenance work and PR reviewing
> in other modules: see:
> https://www.ohloh.net/p/scipy/contributors/21026012405206).
>
> Cheers,
> Ralf
>
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130802/c161026b/attachment.html>

From scopatz at gmail.com  Fri Aug  2 16:34:14 2013
From: scopatz at gmail.com (Anthony Scopatz)
Date: Fri, 2 Aug 2013 15:34:14 -0500
Subject: [SciPy-Dev] welcome Alex Griffing to the scipy team
In-Reply-To: <CAGzF1udE=K+3gtTD3jo-39ocaS3xJFZvyaQfVx5_i07FUt2VFw@mail.gmail.com>
References: <CABL7CQi26Zdy7oFJ9k0Ha55Qt8R-A-sw4uy_pYx-KjK7_id46Q@mail.gmail.com>
	<CAGzF1udE=K+3gtTD3jo-39ocaS3xJFZvyaQfVx5_i07FUt2VFw@mail.gmail.com>
Message-ID: <CAPk-6T7vHCk3zEgZP955Tx6MzAw9joJg=ejbwpgRiFujUT6jaA@mail.gmail.com>

Welcome Alex!


On Fri, Aug 2, 2013 at 1:28 PM, Warren Weckesser <warren.weckesser at gmail.com
> wrote:

> Welcome, Alex.  Thanks for all the great work so far, and keep it coming!
>
> Warren
>
>
>
> On Fri, Aug 2, 2013 at 1:47 PM, Ralf Gommers <ralf.gommers at gmail.com>wrote:
>
>> Hi all,
>>
>> I'd like to welcome Alex Griffing to the scipy development team. He was
>> effectively already a part of it as many of you may have noticed but we've
>> made it official by giving him commit rights. Alex has done quite some work
>> on linalg over the last months, and more maintenance work and PR reviewing
>> in other modules: see:
>> https://www.ohloh.net/p/scipy/contributors/21026012405206).
>>
>> Cheers,
>> Ralf
>>
>>
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130802/5024086b/attachment.html>

From blake.a.griffith at gmail.com  Fri Aug  2 19:55:24 2013
From: blake.a.griffith at gmail.com (Blake Griffith)
Date: Fri, 2 Aug 2013 18:55:24 -0500
Subject: [SciPy-Dev] labeling issues as easy-fix
In-Reply-To: <51FBD09B.4070508@gmail.com>
References: <CABL7CQgoEgm=kvz7x=9RHoyAPVcwvjKgGk8c6H0Ck93XR_Y8uA@mail.gmail.com>
	<51FBA849.5020103@gmail.com>
	<CABL7CQi-d=Bpk2UBHFZg0-MbxoLpYa4FnM+2aMpa8krz3XnVaw@mail.gmail.com>
	<51FBD09B.4070508@gmail.com>
Message-ID: <CAOiFMpz9ZwFmjOsaNtu8_RggZt+dcGOO-t5tCU-R2RDMC+vYxQ@mail.gmail.com>

On a related note, do you need to have commit rights to label issues? Is
there a way to allow the person who created the issue to label it?


On Fri, Aug 2, 2013 at 10:30 AM, Juan Luis Cano <juanlu001 at gmail.com> wrote:

>  On 08/02/2013 02:52 PM, Ralf Gommers wrote:
>
>
>   Talking about maintainers, I just saw that each module's issues are
>> linked in Trac. Is it desirable to replace the links with the new GitHub
>> ones?
>>
>
>  Yes, a PR for that would be great.
>
> Ralf
>
>
> Here it is!
>
> https://github.com/scipy/scipy/pull/2679
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130802/fdcbd9d6/attachment.html>

From juanlu001 at gmail.com  Sat Aug  3 09:18:42 2013
From: juanlu001 at gmail.com (Juan Luis Cano)
Date: Sat, 03 Aug 2013 15:18:42 +0200
Subject: [SciPy-Dev] More updates on MAINTAINERS.rst.txt (was: labeling
 issues as easy-fix)
In-Reply-To: <51FBD09B.4070508@gmail.com>
References: <CABL7CQgoEgm=kvz7x=9RHoyAPVcwvjKgGk8c6H0Ck93XR_Y8uA@mail.gmail.com>
	<51FBA849.5020103@gmail.com>
	<CABL7CQi-d=Bpk2UBHFZg0-MbxoLpYa4FnM+2aMpa8krz3XnVaw@mail.gmail.com>
	<51FBD09B.4070508@gmail.com>
Message-ID: <51FD0332.7060407@gmail.com>

On 08/02/2013 05:30 PM, Juan Luis Cano wrote:
> On 08/02/2013 02:52 PM, Ralf Gommers wrote:
>>
>>     Talking about maintainers, I just saw that each module's issues are
>>     linked in Trac. Is it desirable to replace the links with the new
>>     GitHub
>>     ones?
>>
>>
>> Yes, a PR for that would be great.
>>
>> Ralf
>
> Here it is!
>
> https://github.com/scipy/scipy/pull/2679

I saw that these two links to RSS feeds:

http://new.scipy.org/scipy-chatter.xml
http://new.scipy.org/scipy-pull.xml

are broken, and I could not locate any old version of those files 
digging into the repositories. These could be remade, and the RSS feeds 
for the individual modules could be replaced by ones using the GitHub 
API. The latter are easy, but I don't know exactly what the former 
contained.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130803/d2b0295b/attachment.html>

From juanlu001 at gmail.com  Sat Aug  3 11:46:21 2013
From: juanlu001 at gmail.com (Juan Luis Cano)
Date: Sat, 03 Aug 2013 17:46:21 +0200
Subject: [SciPy-Dev] More updates on MAINTAINERS.rst.txt
In-Reply-To: <51FD0332.7060407@gmail.com>
References: <CABL7CQgoEgm=kvz7x=9RHoyAPVcwvjKgGk8c6H0Ck93XR_Y8uA@mail.gmail.com>
	<51FBA849.5020103@gmail.com>
	<CABL7CQi-d=Bpk2UBHFZg0-MbxoLpYa4FnM+2aMpa8krz3XnVaw@mail.gmail.com>
	<51FBD09B.4070508@gmail.com> <51FD0332.7060407@gmail.com>
Message-ID: <51FD25CD.1060103@gmail.com>

On 08/03/2013 03:18 PM, Juan Luis Cano wrote:
> I saw that these two links to RSS feeds:
>
> http://new.scipy.org/scipy-chatter.xml
> http://new.scipy.org/scipy-pull.xml
>
> are broken, and I could not locate any old version of those files 
> digging into the repositories. These could be remade, and the RSS 
> feeds for the individual modules could be replaced by ones using the 
> GitHub API. The latter are easy, but I don't know exactly what the 
> former contained.

Well, proof it was easy is that I already did it, being clueless:

https://github.com/Juanlu001/scipy-feeds
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130803/110b6c33/attachment.html>

From ralf.gommers at gmail.com  Sun Aug  4 05:36:05 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sun, 4 Aug 2013 11:36:05 +0200
Subject: [SciPy-Dev] labeling issues as easy-fix
In-Reply-To: <CAOiFMpz9ZwFmjOsaNtu8_RggZt+dcGOO-t5tCU-R2RDMC+vYxQ@mail.gmail.com>
References: <CABL7CQgoEgm=kvz7x=9RHoyAPVcwvjKgGk8c6H0Ck93XR_Y8uA@mail.gmail.com>
	<51FBA849.5020103@gmail.com>
	<CABL7CQi-d=Bpk2UBHFZg0-MbxoLpYa4FnM+2aMpa8krz3XnVaw@mail.gmail.com>
	<51FBD09B.4070508@gmail.com>
	<CAOiFMpz9ZwFmjOsaNtu8_RggZt+dcGOO-t5tCU-R2RDMC+vYxQ@mail.gmail.com>
Message-ID: <CABL7CQjR90p+FP+A8-A9LsWG-TbTp2mO+QdMyxGcxZE-SjMUUg@mail.gmail.com>

On Sat, Aug 3, 2013 at 1:55 AM, Blake Griffith
<blake.a.griffith at gmail.com>wrote:

> On a related note, do you need to have commit rights to label issues? Is
> there a way to allow the person who created the issue to label it?
>

There isn't, and I think that's a feature not a limitation. It makes the
labels more accurate and consistent. On Trac it was possible for users to
set labels, and there it was common that issue submitters would set
priorities and milestones (usually prio high and next release of course)
which was unhelpful and had to be undone most of the time. On Github this
would be worse, since it's not possible to see who labeled an issue.

Ralf


>
> On Fri, Aug 2, 2013 at 10:30 AM, Juan Luis Cano <juanlu001 at gmail.com>wrote:
>
>>  On 08/02/2013 02:52 PM, Ralf Gommers wrote:
>>
>>
>>   Talking about maintainers, I just saw that each module's issues are
>>> linked in Trac. Is it desirable to replace the links with the new GitHub
>>> ones?
>>>
>>
>>  Yes, a PR for that would be great.
>>
>> Ralf
>>
>>
>> Here it is!
>>
>> https://github.com/scipy/scipy/pull/2679
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130804/ae9ee6c5/attachment.html>

From joris.vankerschaver at gmail.com  Sun Aug  4 06:54:45 2013
From: joris.vankerschaver at gmail.com (Joris Vankerschaver)
Date: Sun, 4 Aug 2013 11:54:45 +0100
Subject: [SciPy-Dev] Multivariate normal distribution in scipy.stats
Message-ID: <92BAF77A-873D-4CF5-8E11-AC36B2ED96B3@gmail.com>

Dear all, 

I was wondering if there's any interest to have the multivariate normal distribution integrated into scipy.stats. Its PDF is easily calculated, for instance by something like 

def multinormal_pdf(r, mean, cov):
    """ Probability density function for a multidimensional Gaussian distribution."""
    dim  = r.shape[-1]
    dev  = r - mean
    maha = np.einsum('...k,...kl,...l->...', dev, np.linalg.pinv(cov), dev)
    return (2 * np.pi)**(-0.5 * dim) * np.linalg.det(cov)**(0.5) * np.exp(-0.5 * maha)

Here, r is an array-like of position vectors, with the last axis labeling the components. 

While all of this would be useful and not too hard to code up, it doesn't seem to fit within the scipy.stats.rv_continuous framework, which seems to be explicitly geared to 1D random variables. Is there a natural place where this code could be fitted in, or is this functionality already somewhere else in SciPy?

With best wishes,
Joris 



From ralf.gommers at gmail.com  Sun Aug  4 07:09:41 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sun, 4 Aug 2013 13:09:41 +0200
Subject: [SciPy-Dev] Contributing to the Documentation
In-Reply-To: <CAO5s+D-di=J9Q=17zWj4ZmS1k8ix+fu2TJGq3_EnJ9nHDa88hA@mail.gmail.com>
References: <ea524ffb99045dce445537540920af12@scorpius.uberspace.de>
	<CABL7CQj-zFWAB+EF7TU6zUFgLttgSAE=SciYHUofbB2nEV4L0A@mail.gmail.com>
	<51FAC36A.1010001@gmail.com> <51FAC711.7000804@hilboll.de>
	<CABL7CQiqiBtQ+O=EvtQY1yTTr1XnDnxTWQxtq0MscNPBHD5cPg@mail.gmail.com>
	<51FACED6.1080307@gmail.com>
	<CABL7CQiS4YP8vrQ4sHKXhLebnMNfpMwAj9P6WBWj=acgZavTrQ@mail.gmail.com>
	<51FBD15A.5040902@gmail.com>
	<CAO5s+D-di=J9Q=17zWj4ZmS1k8ix+fu2TJGq3_EnJ9nHDa88hA@mail.gmail.com>
Message-ID: <CABL7CQiwyUo+1zm8rfXqFOavzOS4xuZtKVXupObkkS5SDH8PPQ@mail.gmail.com>

On Fri, Aug 2, 2013 at 8:12 PM, Cera, Tim <tim at cerazone.net> wrote:

> On Fri, Aug 2, 2013 at 11:33 AM, Juan Luis Cano <juanlu001 at gmail.com>wrote:
>
>>  On 08/01/2013 11:29 PM, Ralf Gommers wrote:
>>
>> Not a huge amount, but still regular edits (thanks mainly to Tim Cera)
>> adding up to 1000s of words for every release. The wiki also has some
>> advantages if you'd want to edit larger amounts of docs, like a system to
>> indicate if a docstring is draft / for review / reviewed, and the option to
>> render a page (helps to fix formatting issues). But yes, overall I'd still
>> prefer PRs over wiki edits.
>>
>>
> I got used to the editor.  And I am now going to type a bit of heresy: I
> use git, but I really don't like it.  The complexity/benefit ratio is too
> high for my poor brain.
>
> There is an overlooked advantage to the editor in that when edits are
> previewed there are several tests that validate the docstring you are
> working on.  Those tests could be made part of the test suite (and
> expanded), but currently they are only in the on-line editor.
>

We could only do that after fixing all current formatting issues in the
complete code base (and there will be a lot). After that's done, such a
test would indeed be useful.


> Also, there are bug fixes and additional features in the development
> version of pydocweb that would be nice to see in the on-line doc editor.
>  Actually, these might have been implemented, apologies if anyone has
> already done this - haven't been on in awhile.
>
> And in terms of editing the docstrings, there are many discussions,
> comments, ...etc. about different format issues that are scattered across
> the e-mail list, the discussion section of the on-line editor - but very
> few decisions.  Really would be helpful to codify all of these discussions
> into decisions, write them down, AND implement them as tests.
>

I've tried to keep
https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt up to
date with any decisions made on formatting. If you see gaps in that
document, please open an issue for those (or edit the text in the Github
editor interface:) ).

Ralf



>
> Kindest regards,
> Tim
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130804/ba296cdb/attachment.html>

From ralf.gommers at gmail.com  Sun Aug  4 10:13:34 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sun, 4 Aug 2013 16:13:34 +0200
Subject: [SciPy-Dev] 0.13.0 release schedule
Message-ID: <CABL7CQinRHJnJSgfX66_oxm++46kxzfeEwmnsLG7KT6eH8=bow@mail.gmail.com>

Hi all,

It's time to start thinking about the 0.13.0 release. I have just submitted
an update to the release notes (https://github.com/scipy/scipy/pull/2685),
it would be great if you could check that and suggest more things that
should be mentioned.

My proposal for the release schedule is:
Aug 17 (just before EuroScipy): beta 1
Aug 31: rc 1
Sep 12: rc 2 (if needed)
Sep 22: final release

Does that work for everyone? If there are critical issues for this release
that are not listed at
https://github.com/scipy/scipy/issues?milestone=9&state=open please add
them, or add a comment to the issue.

Of course I'd like to see as many PRs as possible merged before branching
0.13.x, but these in particular should make it in:
  - 2684: Arpack fix
  - 2658: linalg.interpolate update
  - 2588: allow kwargs in stats.distributions
  - 2510: N-dimensional integration routine
Help in merging PRs before the 17th will be much appreciated.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130804/73ccdcb4/attachment.html>

From robert.kern at gmail.com  Sun Aug  4 14:35:37 2013
From: robert.kern at gmail.com (Robert Kern)
Date: Sun, 4 Aug 2013 19:35:37 +0100
Subject: [SciPy-Dev] Multivariate normal distribution in scipy.stats
In-Reply-To: <92BAF77A-873D-4CF5-8E11-AC36B2ED96B3@gmail.com>
References: <92BAF77A-873D-4CF5-8E11-AC36B2ED96B3@gmail.com>
Message-ID: <CAF6FJiuvHbRnF-oE2+m+zq6mSSBFKWOn0hdUT6V8mJaRj4q_hw@mail.gmail.com>

On Sun, Aug 4, 2013 at 11:54 AM, Joris Vankerschaver <
joris.vankerschaver at gmail.com> wrote:
>
> Dear all,
>
> I was wondering if there's any interest to have the multivariate normal
distribution integrated into scipy.stats. Its PDF is easily calculated, for
instance by something like
>
> def multinormal_pdf(r, mean, cov):
>     """ Probability density function for a multidimensional Gaussian
distribution."""
>     dim  = r.shape[-1]
>     dev  = r - mean
>     maha = np.einsum('...k,...kl,...l->...', dev, np.linalg.pinv(cov),
dev)
>     return (2 * np.pi)**(-0.5 * dim) * np.linalg.det(cov)**(0.5) *
np.exp(-0.5 * maha)
>
> Here, r is an array-like of position vectors, with the last axis labeling
the components.
>
> While all of this would be useful and not too hard to code up, it doesn't
seem to fit within the scipy.stats.rv_continuous framework, which seems to
be explicitly geared to 1D random variables. Is there a natural place where
this code could be fitted in, or is this functionality already somewhere
else in SciPy?

A new scipy.stats.multivariate module would be a fine place for it. This is
common enough that it doesn't need to wait for a full-fledged framework for
multivariate distributions, in my opinion. I'm not sure what such a
framework would really do except collect the various PDFs and log-PDFs.

--
Robert Kern
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130804/8944be00/attachment.html>

From josef.pktd at gmail.com  Sun Aug  4 17:24:29 2013
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Sun, 4 Aug 2013 17:24:29 -0400
Subject: [SciPy-Dev] 0.13.0 release schedule
In-Reply-To: <CABL7CQinRHJnJSgfX66_oxm++46kxzfeEwmnsLG7KT6eH8=bow@mail.gmail.com>
References: <CABL7CQinRHJnJSgfX66_oxm++46kxzfeEwmnsLG7KT6eH8=bow@mail.gmail.com>
Message-ID: <CAMMTP+CzwR8R3c-CfqqGn80SzKa8ZxyNQ=evs+UhRSQmJnrhog@mail.gmail.com>

On Sun, Aug 4, 2013 at 10:13 AM, Ralf Gommers <ralf.gommers at gmail.com> wrote:
> Hi all,
>
> It's time to start thinking about the 0.13.0 release. I have just submitted
> an update to the release notes (https://github.com/scipy/scipy/pull/2685),
> it would be great if you could check that and suggest more things that
> should be mentioned.
>
> My proposal for the release schedule is:
> Aug 17 (just before EuroScipy): beta 1
> Aug 31: rc 1
> Sep 12: rc 2 (if needed)
> Sep 22: final release
>
> Does that work for everyone? If there are critical issues for this release
> that are not listed at
> https://github.com/scipy/scipy/issues?milestone=9&state=open please add
> them, or add a comment to the issue.
>
> Of course I'd like to see as many PRs as possible merged before branching
> 0.13.x, but these in particular should make it in:
>   - 2684: Arpack fix
>   - 2658: linalg.interpolate update
>   - 2588: allow kwargs in stats.distributions
>   - 2510: N-dimensional integration routine
> Help in merging PRs before the 17th will be much appreciated.

What's the status with fmin_slsqp in scipy master?
During the last round of statsmodels testing it looked like it got
pretty broken in master, at least for our application.

(I don't have a scipy master build to test against.)

Josef

>
> Cheers,
> Ralf
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From pav at iki.fi  Sun Aug  4 18:03:36 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Mon, 05 Aug 2013 01:03:36 +0300
Subject: [SciPy-Dev] 0.13.0 release schedule
In-Reply-To: <CAMMTP+CzwR8R3c-CfqqGn80SzKa8ZxyNQ=evs+UhRSQmJnrhog@mail.gmail.com>
References: <CABL7CQinRHJnJSgfX66_oxm++46kxzfeEwmnsLG7KT6eH8=bow@mail.gmail.com>
	<CAMMTP+CzwR8R3c-CfqqGn80SzKa8ZxyNQ=evs+UhRSQmJnrhog@mail.gmail.com>
Message-ID: <ktmj3g$re7$1@ger.gmane.org>

05.08.2013 00:24, josef.pktd at gmail.com kirjoitti:
[clip]
> What's the status with fmin_slsqp in scipy master?
> During the last round of statsmodels testing it looked like it got
> pretty broken in master, at least for our application.

It should be working.

More details would be needed to say anything.

-- 
Pauli Virtanen



From matthew.brett at gmail.com  Sun Aug  4 18:12:48 2013
From: matthew.brett at gmail.com (Matthew Brett)
Date: Sun, 4 Aug 2013 15:12:48 -0700
Subject: [SciPy-Dev] 0.13.0 release schedule
In-Reply-To: <CAMMTP+CzwR8R3c-CfqqGn80SzKa8ZxyNQ=evs+UhRSQmJnrhog@mail.gmail.com>
References: <CABL7CQinRHJnJSgfX66_oxm++46kxzfeEwmnsLG7KT6eH8=bow@mail.gmail.com>
	<CAMMTP+CzwR8R3c-CfqqGn80SzKa8ZxyNQ=evs+UhRSQmJnrhog@mail.gmail.com>
Message-ID: <CAH6Pt5q1H18yN24vyqSKjW=HiAfAcQ1p_aK2fuBTcE+S_QD-fw@mail.gmail.com>

Hi,

On Sun, Aug 4, 2013 at 2:24 PM,  <josef.pktd at gmail.com> wrote:
> On Sun, Aug 4, 2013 at 10:13 AM, Ralf Gommers <ralf.gommers at gmail.com> wrote:
>> Hi all,
>>
>> It's time to start thinking about the 0.13.0 release. I have just submitted
>> an update to the release notes (https://github.com/scipy/scipy/pull/2685),
>> it would be great if you could check that and suggest more things that
>> should be mentioned.
>>
>> My proposal for the release schedule is:
>> Aug 17 (just before EuroScipy): beta 1
>> Aug 31: rc 1
>> Sep 12: rc 2 (if needed)
>> Sep 22: final release
>>
>> Does that work for everyone? If there are critical issues for this release
>> that are not listed at
>> https://github.com/scipy/scipy/issues?milestone=9&state=open please add
>> them, or add a comment to the issue.

I'd like to finally make the threatened API changes in io.matlab.  These are:

1) No longer search python system path for mat files.
``loadmat('somefile.mat')`` will now fail if the file is not in your
current directory, and we won't search the python path for
``somefile.mat``:
https://github.com/scipy/scipy/blob/master/scipy/io/matlab/mio.py#L37.
 We threatened this would go away in the next version of scipy in
commit 08cfc9 May 29 2010, and put in a FutureWarning in e7be18e Nov
2008

2) Change default saved 1D shape from column vector to row vector:
https://github.com/scipy/scipy/blob/master/scipy/io/matlab/mio5.py#L817

Threatened with FutureWarning in f7d9b150 Feb 2009 . Mat4 already
saves 1D vectors as rows.

3) Raise an error when trying to save arrays with > 2 dimensions to mat4 format:
https://github.com/scipy/scipy/blob/master/scipy/io/matlab/mio4.py#L448

DeprecationWarning since 54ae37d2b Jan 2010

Is this acceptable to everyone?  If not, do y'all have suggestions
about how to proceed with these?

Cheers,

Matthew


From josef.pktd at gmail.com  Sun Aug  4 18:22:25 2013
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Sun, 4 Aug 2013 18:22:25 -0400
Subject: [SciPy-Dev] 0.13.0 release schedule
In-Reply-To: <ktmj3g$re7$1@ger.gmane.org>
References: <CABL7CQinRHJnJSgfX66_oxm++46kxzfeEwmnsLG7KT6eH8=bow@mail.gmail.com>
	<CAMMTP+CzwR8R3c-CfqqGn80SzKa8ZxyNQ=evs+UhRSQmJnrhog@mail.gmail.com>
	<ktmj3g$re7$1@ger.gmane.org>
Message-ID: <CAMMTP+B82F9jN4TOEJEjBUebv-1UZZOuoXrTfVuu2FfNpLNhqw@mail.gmail.com>

On Sun, Aug 4, 2013 at 6:03 PM, Pauli Virtanen <pav at iki.fi> wrote:
> 05.08.2013 00:24, josef.pktd at gmail.com kirjoitti:
> [clip]
>> What's the status with fmin_slsqp in scipy master?
>> During the last round of statsmodels testing it looked like it got
>> pretty broken in master, at least for our application.
>
> It should be working.
>
> More details would be needed to say anything.

I'm just the middle man, since I cannot test this myself.

https://groups.google.com/d/msg/pystatsmodels/wQeYzFVjql4/S3bDFQSSAWcJ
test errors
https://groups.google.com/d/msg/pystatsmodels/wQeYzFVjql4/S3bDFQSSAWcJ
There are no failures with any released scipy (versions >=0.9) in these tests.

Josef
>
> --
> Pauli Virtanen
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev


From ralf.gommers at gmail.com  Mon Aug  5 01:39:24 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Mon, 5 Aug 2013 07:39:24 +0200
Subject: [SciPy-Dev] 0.13.0 release schedule
In-Reply-To: <CAH6Pt5q1H18yN24vyqSKjW=HiAfAcQ1p_aK2fuBTcE+S_QD-fw@mail.gmail.com>
References: <CABL7CQinRHJnJSgfX66_oxm++46kxzfeEwmnsLG7KT6eH8=bow@mail.gmail.com>
	<CAMMTP+CzwR8R3c-CfqqGn80SzKa8ZxyNQ=evs+UhRSQmJnrhog@mail.gmail.com>
	<CAH6Pt5q1H18yN24vyqSKjW=HiAfAcQ1p_aK2fuBTcE+S_QD-fw@mail.gmail.com>
Message-ID: <CABL7CQjoUd_URMoUeC05L3BO8RTZdL1GvGxFf7iPpDC6nzVHmw@mail.gmail.com>

On Mon, Aug 5, 2013 at 12:12 AM, Matthew Brett <matthew.brett at gmail.com>wrote:

> Hi,
>
> On Sun, Aug 4, 2013 at 2:24 PM,  <josef.pktd at gmail.com> wrote:
> > On Sun, Aug 4, 2013 at 10:13 AM, Ralf Gommers <ralf.gommers at gmail.com>
> wrote:
> >> Hi all,
> >>
> >> It's time to start thinking about the 0.13.0 release. I have just
> submitted
> >> an update to the release notes (
> https://github.com/scipy/scipy/pull/2685),
> >> it would be great if you could check that and suggest more things that
> >> should be mentioned.
> >>
> >> My proposal for the release schedule is:
> >> Aug 17 (just before EuroScipy): beta 1
> >> Aug 31: rc 1
> >> Sep 12: rc 2 (if needed)
> >> Sep 22: final release
> >>
> >> Does that work for everyone? If there are critical issues for this
> release
> >> that are not listed at
> >> https://github.com/scipy/scipy/issues?milestone=9&state=open please add
> >> them, or add a comment to the issue.
>
> I'd like to finally make the threatened API changes in io.matlab.  These
> are:
>
> 1) No longer search python system path for mat files.
> ``loadmat('somefile.mat')`` will now fail if the file is not in your
> current directory, and we won't search the python path for
> ``somefile.mat``:
> https://github.com/scipy/scipy/blob/master/scipy/io/matlab/mio.py#L37.
>  We threatened this would go away in the next version of scipy in
> commit 08cfc9 May 29 2010, and put in a FutureWarning in e7be18e Nov
> 2008
>
> 2) Change default saved 1D shape from column vector to row vector:
> https://github.com/scipy/scipy/blob/master/scipy/io/matlab/mio5.py#L817
>
> Threatened with FutureWarning in f7d9b150 Feb 2009 . Mat4 already
> saves 1D vectors as rows.
>
> 3) Raise an error when trying to save arrays with > 2 dimensions to mat4
> format:
> https://github.com/scipy/scipy/blob/master/scipy/io/matlab/mio4.py#L448
>
> DeprecationWarning since 54ae37d2b Jan 2010
>
> Is this acceptable to everyone?  If not, do y'all have suggestions
> about how to proceed with these?
>

These changed look fine to me. 3 years is more than enough advance warning.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130805/18466f63/attachment.html>

From ralf.gommers at gmail.com  Mon Aug  5 16:24:03 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Mon, 5 Aug 2013 22:24:03 +0200
Subject: [SciPy-Dev] Discussion on a new interface for multidimensional
	quadrature
In-Reply-To: <8A6B959D-DB30-400E-ACA3-3933912D4ED0@gmail.com>
References: <8A6B959D-DB30-400E-ACA3-3933912D4ED0@gmail.com>
Message-ID: <CABL7CQhSxSpuR64AfMZYyeCywWnBsX_YO1HCTq9vGFQFjivyQw@mail.gmail.com>

On Fri, Aug 2, 2013 at 7:19 PM, Nathan Woods <charlesnwoods at gmail.com>wrote:

> I'm copying the most relevant parts over from a discussion on GitHub,
> having to do with a new n-dimensional integration tool. The discussion is
> whether or not to make nquad's new interface consistent with dbl-and
> tplquad, even though their precedent is arguably more confusing to users.
>
> nquad is a recursively defined wrapper to scipy.integrate.quad that allows
> for n-dimensional integration with almost the entire list of arguments
> allowed by quad. It is therefore more general than either dbl- or tplquad,
> and encompasses their use cases, while allowing the user greater control
> over the integration. The interface is given: nquad( f(x0,x1,?xn,t0,?tm)
> ,[[x0_lo,x0_hi],?[xn_lo,xn_hi]],[t0,?tm],[opts0,?optsn]).
> The ranges of integration are given in the same order as the arguments in
> the function to be integrated. This ordering is consistent with both Matlab
> and Octave, and it is similar to what is encountered in other SciPy
> packages such as fft. It is also what makes sense to new users.
>
> dbl- and tplquad, however, reverse the order of arguments in f. From the
> documentation for tplquad:
>
> Return the triple integral of func(z, y, x) from x=a..b,
> y=gfun(x)..hfun(x), and z=qfun(x,y)..rfun(x,y)
>
> This is confusing, and contrary to common practice.
>
> It is proposed that nquad's calling sequence be left as is, and that the
> use of dbl- and tplquad be deprecated in some future version of SciPy, and
> that nquad be recommended for multidimensional integration in new code.
> dbl- and tplquad would of course be retained, though not recommended, in
> order to avoid breaking existing code.
>
> Wow, that came out all legalistic. Anyway, what do you all think about
> this change? I have a horse in the race (I wrote most of nquad), but I
> really think that maintaining the backwards style from dbl- and tplquad and
> enshrining it in new code is a bad idea. This is a perfect time to get away
> from it, if that's what we want to do.
>

My first instinct was that nquad should match what's already there in
scipy.integrate, but I've changed my mind. I always have to look at the
dblquad/tplquad documentation to get it right, so those functions don't
have a good API imho. Therefore just making nquad do the logical thing
(i.e. ``f(x, y ,z)``) makes sense to me.

Let's not use the word "deprecate" for dblquad/tplquad, since they
shouldn't be removed. Instead just recommend `nquad` as the function to use
in the docs.

Any other opinions?

Ralf


Good question. I think this needs some discussion on the scipy-dev list,
> because it would be a fairly large change (dblquad/tplquad are old and
> widely used I think). Could you please bring it up there?
>
> Yeah, I remember wondering how to handle that. It's not a very difficult
> fix, and most of the work will be in changing over the examples and tests
> so they work with the new ordering. However, do we really want to stick
> with the old order?
>
> If we want to change it, then now is a perfect time, since nquad
> duplicates and extends the functionality of dbl- and tplquad. Those two
> could be deprecated and retained for compatibility, while nquad is
> recommended for new code. Since the calling sequence for nquad is so
> different, new users will have to adjust anyway.
>
> The current argument list for tplquad is confusing. The order of arguments
> in the function does not match with the order of the range functions that
> must be provided, which is a source of confusion. The ordering was
> presumably chosen to make things look as much like quad as possible, but is
> that really important now?
>
> As a reference, Matlab's integral3 and triplequad and GNU Octave's triple
> quad both order things (x,y,z). SciPy's fft2 also appears to do things the
> same way.
>
>
> There's one thing that needs discussion: the integration order is reversed
> compared to dblquad and tplquad. Where you'd use def func3d(z, y, x) in
> tplquad you have to use def func3d(x, y, z) here. I was never a fan of
> the order in dbp/tplquad, but we're stuck with that and I thinknquad should
> use that same order for consistency.
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130805/0b44f007/attachment.html>

From ralf.gommers at gmail.com  Mon Aug  5 16:42:04 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Mon, 5 Aug 2013 22:42:04 +0200
Subject: [SciPy-Dev] Multivariate normal distribution in scipy.stats
In-Reply-To: <CAF6FJiuvHbRnF-oE2+m+zq6mSSBFKWOn0hdUT6V8mJaRj4q_hw@mail.gmail.com>
References: <92BAF77A-873D-4CF5-8E11-AC36B2ED96B3@gmail.com>
	<CAF6FJiuvHbRnF-oE2+m+zq6mSSBFKWOn0hdUT6V8mJaRj4q_hw@mail.gmail.com>
Message-ID: <CABL7CQjmB0v-weUZfC7vSW6pVHxKo=HUjZ8V08ACyy2Ydi3xUA@mail.gmail.com>

On Sun, Aug 4, 2013 at 8:35 PM, Robert Kern <robert.kern at gmail.com> wrote:

> On Sun, Aug 4, 2013 at 11:54 AM, Joris Vankerschaver <
> joris.vankerschaver at gmail.com> wrote:
> >
> > Dear all,
> >
> > I was wondering if there's any interest to have the multivariate normal
> distribution integrated into scipy.stats. Its PDF is easily calculated, for
> instance by something like
> >
> > def multinormal_pdf(r, mean, cov):
> >     """ Probability density function for a multidimensional Gaussian
> distribution."""
> >     dim  = r.shape[-1]
> >     dev  = r - mean
> >     maha = np.einsum('...k,...kl,...l->...', dev, np.linalg.pinv(cov),
> dev)
> >     return (2 * np.pi)**(-0.5 * dim) * np.linalg.det(cov)**(0.5) *
> np.exp(-0.5 * maha)
> >
> > Here, r is an array-like of position vectors, with the last axis
> labeling the components.
> >
> > While all of this would be useful and not too hard to code up, it
> doesn't seem to fit within the scipy.stats.rv_continuous framework, which
> seems to be explicitly geared to 1D random variables. Is there a natural
> place where this code could be fitted in, or is this functionality already
> somewhere else in SciPy?
>
> A new scipy.stats.multivariate module would be a fine place for it. This
> is common enough that it doesn't need to wait for a full-fledged framework
> for multivariate distributions, in my opinion. I'm not sure what such a
> framework would really do except collect the various PDFs and log-PDFs.
>

+1 to add it without a framework. Can be either a new module or in the
scipy.stats namespace - there aren't that many multivariate distributions
that it would necessarily warrant a new submodule.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130805/35190325/attachment.html>

From robert.kern at gmail.com  Mon Aug  5 16:54:27 2013
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 5 Aug 2013 21:54:27 +0100
Subject: [SciPy-Dev] Multivariate normal distribution in scipy.stats
In-Reply-To: <CABL7CQjmB0v-weUZfC7vSW6pVHxKo=HUjZ8V08ACyy2Ydi3xUA@mail.gmail.com>
References: <92BAF77A-873D-4CF5-8E11-AC36B2ED96B3@gmail.com>
	<CAF6FJiuvHbRnF-oE2+m+zq6mSSBFKWOn0hdUT6V8mJaRj4q_hw@mail.gmail.com>
	<CABL7CQjmB0v-weUZfC7vSW6pVHxKo=HUjZ8V08ACyy2Ydi3xUA@mail.gmail.com>
Message-ID: <CAF6FJisoNxF0gb1KGUsNONcZjc43XyG2dJRm6-CP=oAZW9RpMg@mail.gmail.com>

On Mon, Aug 5, 2013 at 9:42 PM, Ralf Gommers <ralf.gommers at gmail.com> wrote:
>
> On Sun, Aug 4, 2013 at 8:35 PM, Robert Kern <robert.kern at gmail.com> wrote:

>> A new scipy.stats.multivariate module would be a fine place for it. This
is common enough that it doesn't need to wait for a full-fledged framework
for multivariate distributions, in my opinion. I'm not sure what such a
framework would really do except collect the various PDFs and log-PDFs.
>
> +1 to add it without a framework. Can be either a new module or in the
scipy.stats namespace - there aren't that many multivariate distributions
that it would necessarily warrant a new submodule.

I only meant implementation-wise. I think we should have a new
scipy/stats/multivariate.py file and import its public names into the
scipy.stats namespace. distributions.py is ... crowded and is (rightfully,
IMO) dedicated to the rv_continuous/rv_discrete framework.

--
Robert Kern
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130805/6e72a188/attachment.html>

From ralf.gommers at gmail.com  Mon Aug  5 17:10:58 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Mon, 5 Aug 2013 23:10:58 +0200
Subject: [SciPy-Dev] Multivariate normal distribution in scipy.stats
In-Reply-To: <CAF6FJisoNxF0gb1KGUsNONcZjc43XyG2dJRm6-CP=oAZW9RpMg@mail.gmail.com>
References: <92BAF77A-873D-4CF5-8E11-AC36B2ED96B3@gmail.com>
	<CAF6FJiuvHbRnF-oE2+m+zq6mSSBFKWOn0hdUT6V8mJaRj4q_hw@mail.gmail.com>
	<CABL7CQjmB0v-weUZfC7vSW6pVHxKo=HUjZ8V08ACyy2Ydi3xUA@mail.gmail.com>
	<CAF6FJisoNxF0gb1KGUsNONcZjc43XyG2dJRm6-CP=oAZW9RpMg@mail.gmail.com>
Message-ID: <CABL7CQgF6gMue0w+3sxsC37O6v-9ZTzxAP=kJyiW_wHRJe_JNg@mail.gmail.com>

On Mon, Aug 5, 2013 at 10:54 PM, Robert Kern <robert.kern at gmail.com> wrote:

> On Mon, Aug 5, 2013 at 9:42 PM, Ralf Gommers <ralf.gommers at gmail.com>
> wrote:
> >
> > On Sun, Aug 4, 2013 at 8:35 PM, Robert Kern <robert.kern at gmail.com>
> wrote:
>
> >> A new scipy.stats.multivariate module would be a fine place for it.
> This is common enough that it doesn't need to wait for a full-fledged
> framework for multivariate distributions, in my opinion. I'm not sure what
> such a framework would really do except collect the various PDFs and
> log-PDFs.
> >
> > +1 to add it without a framework. Can be either a new module or in the
> scipy.stats namespace - there aren't that many multivariate distributions
> that it would necessarily warrant a new submodule.
>
> I only meant implementation-wise. I think we should have a new
> scipy/stats/multivariate.py file and import its public names into the
> scipy.stats namespace. distributions.py is ... crowded and is (rightfully,
> IMO) dedicated to the rv_continuous/rv_discrete framework.
>

Ah OK. I fully agree then (except name it _multivariate.py).

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130805/edcf31c3/attachment.html>

From josef.pktd at gmail.com  Tue Aug  6 01:35:45 2013
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Tue, 6 Aug 2013 01:35:45 -0400
Subject: [SciPy-Dev] Discussion on a new interface for multidimensional
	quadrature
In-Reply-To: <CABL7CQhSxSpuR64AfMZYyeCywWnBsX_YO1HCTq9vGFQFjivyQw@mail.gmail.com>
References: <8A6B959D-DB30-400E-ACA3-3933912D4ED0@gmail.com>
	<CABL7CQhSxSpuR64AfMZYyeCywWnBsX_YO1HCTq9vGFQFjivyQw@mail.gmail.com>
Message-ID: <CAMMTP+BST9i-hpdm+D_c5tNna1zXVJZr3_Be=chU0rCiiMqrUQ@mail.gmail.com>

On Mon, Aug 5, 2013 at 4:24 PM, Ralf Gommers <ralf.gommers at gmail.com> wrote:
>
>
>
> On Fri, Aug 2, 2013 at 7:19 PM, Nathan Woods <charlesnwoods at gmail.com>
> wrote:
>>
>> I'm copying the most relevant parts over from a discussion on GitHub,
>> having to do with a new n-dimensional integration tool. The discussion is
>> whether or not to make nquad's new interface consistent with dbl-and
>> tplquad, even though their precedent is arguably more confusing to users.
>>
>> nquad is a recursively defined wrapper to scipy.integrate.quad that allows
>> for n-dimensional integration with almost the entire list of arguments
>> allowed by quad. It is therefore more general than either dbl- or tplquad,
>> and encompasses their use cases, while allowing the user greater control
>> over the integration. The interface is given: nquad( f(x0,x1,?xn,t0,?tm)
>> ,[[x0_lo,x0_hi],?[xn_lo,xn_hi]],[t0,?tm],[opts0,?optsn]).
>> The ranges of integration are given in the same order as the arguments in
>> the function to be integrated. This ordering is consistent with both Matlab
>> and Octave, and it is similar to what is encountered in other SciPy packages
>> such as fft. It is also what makes sense to new users.
>>
>> dbl- and tplquad, however, reverse the order of arguments in f. From the
>> documentation for tplquad:
>>
>> Return the triple integral of func(z, y, x) from x=a..b,
>> y=gfun(x)..hfun(x), and z=qfun(x,y)..rfun(x,y)
>>
>> This is confusing, and contrary to common practice.
>>
>> It is proposed that nquad's calling sequence be left as is, and that the
>> use of dbl- and tplquad be deprecated in some future version of SciPy, and
>> that nquad be recommended for multidimensional integration in new code. dbl-
>> and tplquad would of course be retained, though not recommended, in order to
>> avoid breaking existing code.
>>
>> Wow, that came out all legalistic. Anyway, what do you all think about
>> this change? I have a horse in the race (I wrote most of nquad), but I
>> really think that maintaining the backwards style from dbl- and tplquad and
>> enshrining it in new code is a bad idea. This is a perfect time to get away
>> from it, if that's what we want to do.
>
>
> My first instinct was that nquad should match what's already there in
> scipy.integrate, but I've changed my mind. I always have to look at the
> dblquad/tplquad documentation to get it right, so those functions don't have
> a good API imho. Therefore just making nquad do the logical thing (i.e.
> ``f(x, y ,z)``) makes sense to me.
>
> Let's not use the word "deprecate" for dblquad/tplquad, since they shouldn't
> be removed. Instead just recommend `nquad` as the function to use in the
> docs.
>
> Any other opinions?

How do you know the integration order in the new interface?

The current dblquad, tplquad looks to me like writing an integral

integral_x integral_y integral_z  func3d(z, y,x)  dz dy dz
where integration limits are x=a..b, y=gfun(x)..hfun(x), and
z=qfun(x,y)..rfun(x,y)

based on reading of the docstrings for tplquad. So this doesn't look
very strange to me.

The suggested description
``
The interface is given: nquad( f(x0,x1,?xn,t0,?tm)
,[[x0_lo,x0_hi],?[xn_lo,xn_hi]],[t0,?tm],[opts0,?optsn]).
The ranges of integration are given in the same order as the arguments
in the function to be integrated.
```

Does this mean we integrate over x0 first (innermost integral) or last
(outermost integral) ?

But I never used either function, so I could get used to both if the
docstring is clear.

Josef


>
> Ralf
>
>
>> Good question. I think this needs some discussion on the scipy-dev list,
>> because it would be a fairly large change (dblquad/tplquad are old and
>> widely used I think). Could you please bring it up there?
>>
>> Yeah, I remember wondering how to handle that. It's not a very difficult
>> fix, and most of the work will be in changing over the examples and tests so
>> they work with the new ordering. However, do we really want to stick with
>> the old order?
>>
>> If we want to change it, then now is a perfect time, since nquad
>> duplicates and extends the functionality of dbl- and tplquad. Those two
>> could be deprecated and retained for compatibility, while nquad is
>> recommended for new code. Since the calling sequence for nquad is so
>> different, new users will have to adjust anyway.
>>
>> The current argument list for tplquad is confusing. The order of arguments
>> in the function does not match with the order of the range functions that
>> must be provided, which is a source of confusion. The ordering was
>> presumably chosen to make things look as much like quad as possible, but is
>> that really important now?
>>
>> As a reference, Matlab's integral3 and triplequad and GNU Octave's triple
>> quad both order things (x,y,z). SciPy's fft2 also appears to do things the
>> same way.
>>
>>
>> There's one thing that needs discussion: the integration order is reversed
>> compared to dblquad and tplquad. Where you'd use def func3d(z, y, x) in
>> tplquad you have to use def func3d(x, y, z) here. I was never a fan of the
>> order in dbp/tplquad, but we're stuck with that and I thinknquad should use
>> that same order for consistency.
>>
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From joris.vankerschaver at gmail.com  Tue Aug  6 06:25:13 2013
From: joris.vankerschaver at gmail.com (J Vankerschaver)
Date: Tue, 6 Aug 2013 11:25:13 +0100
Subject: [SciPy-Dev] Multivariate normal distribution in scipy.stats
Message-ID: <CAFytq+nLQifNXQk1OQnPW49fVyLm=5CzcwfCz84VZ1GY_=2pOA@mail.gmail.com>

Hi Ralf and Robert,

Thanks for your suggestions. This makes the task a lot more manageable;
I'll start right away.

With best wishes,
Joris


> > > +1 to add it without a framework. Can be either a new module or in the
> > scipy.stats namespace - there aren't that many multivariate distributions
> > that it would necessarily warrant a new submodule.
> >
> > I only meant implementation-wise. I think we should have a new
> > scipy/stats/multivariate.py file and import its public names into the
> > scipy.stats namespace. distributions.py is ... crowded and is
> (rightfully,
> > IMO) dedicated to the rv_continuous/rv_discrete framework.
> >
>
> Ah OK. I fully agree then (except name it _multivariate.py).
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130806/1a658660/attachment.html>

From ralf.gommers at gmail.com  Tue Aug  6 17:24:01 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Tue, 6 Aug 2013 23:24:01 +0200
Subject: [SciPy-Dev] 0.13.0 release schedule
In-Reply-To: <CAMMTP+B82F9jN4TOEJEjBUebv-1UZZOuoXrTfVuu2FfNpLNhqw@mail.gmail.com>
References: <CABL7CQinRHJnJSgfX66_oxm++46kxzfeEwmnsLG7KT6eH8=bow@mail.gmail.com>
	<CAMMTP+CzwR8R3c-CfqqGn80SzKa8ZxyNQ=evs+UhRSQmJnrhog@mail.gmail.com>
	<ktmj3g$re7$1@ger.gmane.org>
	<CAMMTP+B82F9jN4TOEJEjBUebv-1UZZOuoXrTfVuu2FfNpLNhqw@mail.gmail.com>
Message-ID: <CABL7CQgiGVeHAJOYN_MqEBDnWuW0pg9t3ad_1bY6UoVY9xW-uw@mail.gmail.com>

On Mon, Aug 5, 2013 at 12:22 AM, <josef.pktd at gmail.com> wrote:

> On Sun, Aug 4, 2013 at 6:03 PM, Pauli Virtanen <pav at iki.fi> wrote:
> > 05.08.2013 00:24, josef.pktd at gmail.com kirjoitti:
> > [clip]
> >> What's the status with fmin_slsqp in scipy master?
> >> During the last round of statsmodels testing it looked like it got
> >> pretty broken in master, at least for our application.
> >
> > It should be working.
> >
> > More details would be needed to say anything.
>
> I'm just the middle man, since I cannot test this myself.
>
> https://groups.google.com/d/msg/pystatsmodels/wQeYzFVjql4/S3bDFQSSAWcJ
> test errors
> https://groups.google.com/d/msg/pystatsmodels/wQeYzFVjql4/S3bDFQSSAWcJ
> There are no failures with any released scipy (versions >=0.9) in these
> tests.


Since it only shows up with the Bento build (which doesn't work correctly
on 64-bit anyway), I don't think this is critical for the release.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130806/fd79aaa6/attachment.html>

From fperez.net at gmail.com  Thu Aug  8 21:36:53 2013
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 8 Aug 2013 18:36:53 -0700
Subject: [SciPy-Dev] [ANN] IPython 1.0 is finally released,
	nearly 12 years in the making!
Message-ID: <CAHAreOpCpBVC4oBf_G_K4ZZ_Ni42zsZ-L2GMF0Af7tm_ChXNLw@mail.gmail.com>

Hi all,

I am incredibly thrilled, on behalf of the amazing IPython Dev Team,
to announce the official release of IPython 1.0 today, an effort
nearly 12 years in the making.  The previous version (0.13) was
released on June 30, 2012, and in this development cycle we had:

~12 months of work.
~700 pull requests merged.
~600 issues closed (non-pull requests).
contributions from ~150 authors.
~4000 commits.


# A little context

What does "1.0" mean for IPython? Obviously IPython has been a staple
of the scientific Python community for years, and we've made every
effort to make it a robust and production ready tool for a long time,
so what exactly do we mean by tagging this particular release as 1.0?
Basically, we feel that the core design of IPython, and the scope of
the project, is where we want it to be.

What we have today is what we consider a reasonably complete, design-
and scope-wise, IPython 1.0: an architecture for interactive
computing, that can drive kernels in a number of ways using a
well-defined protocol, and rich and powerful clients that let users
control those kernels effectively. Our different clients serve
different needs, with the old workhorse of the terminal still being
very useful, but much of our current development energy going into the
Notebook, obviously.  The Notebook enables interactive exploration to
become Literate Computing, bridging the gaps from individual work to
collaboration and publication, all with an open file format that is a
direct record of the underlying communication protocol.

There are obviously plenty of open issues (many of them very
important) that need fixing, and large and ambitious new lines of
development for the years to come.  But the work of the last four
years, since the summer of 2009 when Brian Granger was able to devote
a summer (thanks to funding from the NiPy project - nipy.org) to
refactoring the old IPython core code, finally opened up or
infrastructure for real innovation. By disentangling what was a useful
but impenetrable codebase, it became possible for us to start building
a flexible, modern system for interactive computing that abstracted
the old REPL model into a generic protocol that kernels could use to
talk to clients. This led at first to the creation of the Qt console,
and then to the Notebook and out-of-process terminal client.  It also
allowed us to (finally!) unify our parallel computing machinery with
the rest of the interactive system, which Min Ragan-Kelley pulled off
in a development tour de force that involved rewriting in a few weeks
a huge and complex Twisted-based system.

We are very happy with how the Notebook work has turned out, and it
seems the entire community agrees with us, as the uptake has been
phenomenal.  Back from the very first "IPython 0.0.1" that I started
in 2001:

https://gist.github.com/fperez/1579699

there were already hints of tools like Mathematica: it was my everyday
workhorse as a theoretical physicist and I found its Notebook
environment invaluable. But as a grad student trying out "just an
afternoon hack" (IPython was my very first Python program as I was
learning the language), I didn't have the resources, skills or vision
to attempt building an entire notebook system, and to be honest the
tools of the day would have made that enterprise a miserable one.  But
those ideas were always driving our efforts, and as IPython started
becoming a project with a team, we made multiple attempts to get a
good Notebook built around IPython.  Those interested can read an old
blog post of mine with the history
(http://blog.fperez.org/2012/01/ipython-notebook-historical.html).
The short story is that in 2011, on our sixth attempt, Brian was again
able to devote a focused summer into using our client-server
architecture and, with the stack of the modern web (Javascript, CSS,
websockets, Tornado, ...), finally build a robust system for Literate
Computing across programming languages.

Today, thanks to the generous support and vision of Josh Greenberg at
the Alfred P. Sloan Foundation, we are working very hard on building
the notebook infrastructure, and this release contains major advances
on that front.  We have high hopes for what we'll do next; as a
glimpse of the future that this enables, now there is a native Julia
kernel that speaks to our clients, notebook included:
https://github.com/JuliaLang/IJulia.jl.


# Team

I can't stress enough how impressed I am with the work people are
doing in IPython, and what a privilege it is to work with colleagues
like these.  Brian Granger and Min Ragan-Kelley joined IPython around
2005, initially working on the parallel machinery, but since ~ 2009
they have become the heart of the project. Today Min is our top
committer and knows our codebase better than anyone else, and I can't
imagine better partners for an effort like this.

And from regulars in our core team like Thomas Kluyver, Matthias
Bussonnier, Brad Froehle and Paul Ivanov to newcomers like Jonathan
Frederic and Zach Sailer, in addition to the many more whose names are
in our logs, we have a crazy amount of energy being poured into
IPython.  I hope we'll continue to harness it productively!

The full list of contributors to this release can be seen here:

http://ipython.org/ipython-doc/rel-1.0.0/whatsnew/github-stats-1.0.html


# Release highlights

* nbconvert: this is the major piece of new functionality in this
cycle, and was an explicit part of our roadmap
(https://github.com/ipython/ipython/wiki/Roadmap:-IPython). nbconvert
is now an IPython subcommand to convert notebooks into other formats
such as HTML or LaTeX, but more importantly, it's a very flexible
system that lets you write custom templates to generate new output
with arbitrary control over the formatting and transformations that
are applied to the input.

We want to stress that despite the fact that a huge amount of work
went into nbconvert, this should be considered a *tech preview*
release. We've come to realize how complex this problem is, and while
we'll make every effort to keep the high-level command-line syntax and
APIs as stable as possible, it is quite likely that the internals will
continue to evolve, possibly in backwards-incompatible ways.  So if
you start building services and libraries that make heavy use of the
nbconvert internals, please be prepared for some turmoil in the months
to come, and ping us on the dev list with questions or concerns.

* Notebook improvements: there has been a ton of polish work in the
notebook at many levels, though the file format remains unchanged from
0.13, so you shouldn't have any problems sharing notebooks with
colleagues still using 0.13.

  - Autosave: probably the most oft-requested feature, the notebook
server now autosaves your files!  You can still hit Ctrl-S to force a
manual save (which also creates a special 'checkpoint' you can come
back to).

  - The notebook supports raw_input(), and thus also %debug. This was
probably the main deficiency of the notebook as a client compared to
the terminal/qtconsole, and it has been finally fixed.

  - Add %%html, %%svg, %%javascript, and %%latex cell magics for
writing raw output in notebook cells.
  - Fix an issue parsing LaTeX in markdown cells, which required users
to type \\\, instead of \\.
  -Images support width and height metadata, and thereby 2x scaling
(retina support).
  - %%file has been renamed %%writefile (%%file) is deprecated.

* The input transofrmation code has been updated and rationalized.
This is a somewhat specialized part of IPython, but of importance to
projects that build upon it for custom environments, like Sympy and
Sage.

Our full release notes are here:

http://ipython.org/ipython-doc/rel-1.0.0/whatsnew/version1.0.html

and the gory details are here:

http://ipython.org/ipython-doc/rel-1.0.0/whatsnew/github-stats-1.0.html


# Installation

Installation links and instructions are at: http://ipython.org/install.html
And IPython is also on PyPI: http://pypi.python.org/pypi/ipython


# Requirements

IPython 1.0 requires Python ? 2.6.5 or ? 3.2.1. It does not support
Python 3.0, 3.1, or 2.5.


# Acknowledgments

Last but not least, we'd like to acknowledge the generous support of
those who make it possible for us to spend our time working on
IPython.  In particular, the Alfred P. Sloan Foundation today lets us
have a solid team working full-time on the project, and without the
support of Enthought Inc at multiple points in our history, we
wouldn't be where we are today.

The full list of our support is here:

http://ipython.org/index.html#support


Thanks to everyone! Please enjoy IPython 1.0, and report all bugs as usual!

Fernando, on behalf of the IPython Dev Team.

-- 
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail


From charlesnwoods at gmail.com  Thu Aug  8 23:34:56 2013
From: charlesnwoods at gmail.com (Nathan Woods)
Date: Thu, 8 Aug 2013 21:34:56 -0600
Subject: [SciPy-Dev] Discussion on a new interface for multidimensional
	quadrature
In-Reply-To: <CAMMTP+BST9i-hpdm+D_c5tNna1zXVJZr3_Be=chU0rCiiMqrUQ@mail.gmail.com>
References: <8A6B959D-DB30-400E-ACA3-3933912D4ED0@gmail.com>
	<CABL7CQhSxSpuR64AfMZYyeCywWnBsX_YO1HCTq9vGFQFjivyQw@mail.gmail.com>
	<CAMMTP+BST9i-hpdm+D_c5tNna1zXVJZr3_Be=chU0rCiiMqrUQ@mail.gmail.com>
Message-ID: <020F0119-5ED4-48A2-B799-3F317859C3CF@gmail.com>

Clear documentation is always important, so I don't think there will be any problems there. Does anyone else have thoughts they'd like to share?

Nate

On Aug 5, 2013, at 11:35 PM, josef.pktd at gmail.com wrote:

> On Mon, Aug 5, 2013 at 4:24 PM, Ralf Gommers <ralf.gommers at gmail.com> wrote:
>> 
>> 
>> 
>> On Fri, Aug 2, 2013 at 7:19 PM, Nathan Woods <charlesnwoods at gmail.com>
>> wrote:
>>> 
>>> I'm copying the most relevant parts over from a discussion on GitHub,
>>> having to do with a new n-dimensional integration tool. The discussion is
>>> whether or not to make nquad's new interface consistent with dbl-and
>>> tplquad, even though their precedent is arguably more confusing to users.
>>> 
>>> nquad is a recursively defined wrapper to scipy.integrate.quad that allows
>>> for n-dimensional integration with almost the entire list of arguments
>>> allowed by quad. It is therefore more general than either dbl- or tplquad,
>>> and encompasses their use cases, while allowing the user greater control
>>> over the integration. The interface is given: nquad( f(x0,x1,?xn,t0,?tm)
>>> ,[[x0_lo,x0_hi],?[xn_lo,xn_hi]],[t0,?tm],[opts0,?optsn]).
>>> The ranges of integration are given in the same order as the arguments in
>>> the function to be integrated. This ordering is consistent with both Matlab
>>> and Octave, and it is similar to what is encountered in other SciPy packages
>>> such as fft. It is also what makes sense to new users.
>>> 
>>> dbl- and tplquad, however, reverse the order of arguments in f. From the
>>> documentation for tplquad:
>>> 
>>> Return the triple integral of func(z, y, x) from x=a..b,
>>> y=gfun(x)..hfun(x), and z=qfun(x,y)..rfun(x,y)
>>> 
>>> This is confusing, and contrary to common practice.
>>> 
>>> It is proposed that nquad's calling sequence be left as is, and that the
>>> use of dbl- and tplquad be deprecated in some future version of SciPy, and
>>> that nquad be recommended for multidimensional integration in new code. dbl-
>>> and tplquad would of course be retained, though not recommended, in order to
>>> avoid breaking existing code.
>>> 
>>> Wow, that came out all legalistic. Anyway, what do you all think about
>>> this change? I have a horse in the race (I wrote most of nquad), but I
>>> really think that maintaining the backwards style from dbl- and tplquad and
>>> enshrining it in new code is a bad idea. This is a perfect time to get away
>>> from it, if that's what we want to do.
>> 
>> 
>> My first instinct was that nquad should match what's already there in
>> scipy.integrate, but I've changed my mind. I always have to look at the
>> dblquad/tplquad documentation to get it right, so those functions don't have
>> a good API imho. Therefore just making nquad do the logical thing (i.e.
>> ``f(x, y ,z)``) makes sense to me.
>> 
>> Let's not use the word "deprecate" for dblquad/tplquad, since they shouldn't
>> be removed. Instead just recommend `nquad` as the function to use in the
>> docs.
>> 
>> Any other opinions?
> 
> How do you know the integration order in the new interface?
> 
> The current dblquad, tplquad looks to me like writing an integral
> 
> integral_x integral_y integral_z  func3d(z, y,x)  dz dy dz
> where integration limits are x=a..b, y=gfun(x)..hfun(x), and
> z=qfun(x,y)..rfun(x,y)
> 
> based on reading of the docstrings for tplquad. So this doesn't look
> very strange to me.
> 
> The suggested description
> ``
> The interface is given: nquad( f(x0,x1,?xn,t0,?tm)
> ,[[x0_lo,x0_hi],?[xn_lo,xn_hi]],[t0,?tm],[opts0,?optsn]).
> The ranges of integration are given in the same order as the arguments
> in the function to be integrated.
> ```
> 
> Does this mean we integrate over x0 first (innermost integral) or last
> (outermost integral) ?
> 
> But I never used either function, so I could get used to both if the
> docstring is clear.
> 
> Josef
> 
> 
>> 
>> Ralf
>> 
>> 
>>> Good question. I think this needs some discussion on the scipy-dev list,
>>> because it would be a fairly large change (dblquad/tplquad are old and
>>> widely used I think). Could you please bring it up there?
>>> 
>>> Yeah, I remember wondering how to handle that. It's not a very difficult
>>> fix, and most of the work will be in changing over the examples and tests so
>>> they work with the new ordering. However, do we really want to stick with
>>> the old order?
>>> 
>>> If we want to change it, then now is a perfect time, since nquad
>>> duplicates and extends the functionality of dbl- and tplquad. Those two
>>> could be deprecated and retained for compatibility, while nquad is
>>> recommended for new code. Since the calling sequence for nquad is so
>>> different, new users will have to adjust anyway.
>>> 
>>> The current argument list for tplquad is confusing. The order of arguments
>>> in the function does not match with the order of the range functions that
>>> must be provided, which is a source of confusion. The ordering was
>>> presumably chosen to make things look as much like quad as possible, but is
>>> that really important now?
>>> 
>>> As a reference, Matlab's integral3 and triplequad and GNU Octave's triple
>>> quad both order things (x,y,z). SciPy's fft2 also appears to do things the
>>> same way.
>>> 
>>> 
>>> There's one thing that needs discussion: the integration order is reversed
>>> compared to dblquad and tplquad. Where you'd use def func3d(z, y, x) in
>>> tplquad you have to use def func3d(x, y, z) here. I was never a fan of the
>>> order in dbp/tplquad, but we're stuck with that and I thinknquad should use
>>> that same order for consistency.
>>> 
>>> 
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>> 
>> 
>> 
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>> 
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev



From evgeny.burovskiy at gmail.com  Thu Aug  8 23:55:20 2013
From: evgeny.burovskiy at gmail.com (Evgeni Burovski)
Date: Fri, 9 Aug 2013 04:55:20 +0100
Subject: [SciPy-Dev] Discussion on a new interface for multidimensional
	quadrature
In-Reply-To: <020F0119-5ED4-48A2-B799-3F317859C3CF@gmail.com>
References: <8A6B959D-DB30-400E-ACA3-3933912D4ED0@gmail.com>
	<CABL7CQhSxSpuR64AfMZYyeCywWnBsX_YO1HCTq9vGFQFjivyQw@mail.gmail.com>
	<CAMMTP+BST9i-hpdm+D_c5tNna1zXVJZr3_Be=chU0rCiiMqrUQ@mail.gmail.com>
	<020F0119-5ED4-48A2-B799-3F317859C3CF@gmail.com>
Message-ID: <CAMRo0iuJmxKyvWvxPgA7=7DAdDceC3KbsrDVJx+ocaUMKonwUA@mail.gmail.com>

How about adding an optional argument to nquad, specifying the order of
integration limits? Defaulting to the 'forward' order. Something like

nquad(f(x,y), [a, b], [g(x), h(x)])
being the default, and

nquad(f(x,y), [a, b], [g(y), h(y)], integration_order='reversed')
interpreting the limits the way dblquad/tplquad do.

Evgeni
On Aug 9, 2013 11:35 AM, "Nathan Woods" <charlesnwoods at gmail.com> wrote:

> Clear documentation is always important, so I don't think there will be
> any problems there. Does anyone else have thoughts they'd like to share?
>
> Nate
>
> On Aug 5, 2013, at 11:35 PM, josef.pktd at gmail.com wrote:
>
> > On Mon, Aug 5, 2013 at 4:24 PM, Ralf Gommers <ralf.gommers at gmail.com>
> wrote:
> >>
> >>
> >>
> >> On Fri, Aug 2, 2013 at 7:19 PM, Nathan Woods <charlesnwoods at gmail.com>
> >> wrote:
> >>>
> >>> I'm copying the most relevant parts over from a discussion on GitHub,
> >>> having to do with a new n-dimensional integration tool. The discussion
> is
> >>> whether or not to make nquad's new interface consistent with dbl-and
> >>> tplquad, even though their precedent is arguably more confusing to
> users.
> >>>
> >>> nquad is a recursively defined wrapper to scipy.integrate.quad that
> allows
> >>> for n-dimensional integration with almost the entire list of arguments
> >>> allowed by quad. It is therefore more general than either dbl- or
> tplquad,
> >>> and encompasses their use cases, while allowing the user greater
> control
> >>> over the integration. The interface is given: nquad(
> f(x0,x1,?xn,t0,?tm)
> >>> ,[[x0_lo,x0_hi],?[xn_lo,xn_hi]],[t0,?tm],[opts0,?optsn]).
> >>> The ranges of integration are given in the same order as the arguments
> in
> >>> the function to be integrated. This ordering is consistent with both
> Matlab
> >>> and Octave, and it is similar to what is encountered in other SciPy
> packages
> >>> such as fft. It is also what makes sense to new users.
> >>>
> >>> dbl- and tplquad, however, reverse the order of arguments in f. From
> the
> >>> documentation for tplquad:
> >>>
> >>> Return the triple integral of func(z, y, x) from x=a..b,
> >>> y=gfun(x)..hfun(x), and z=qfun(x,y)..rfun(x,y)
> >>>
> >>> This is confusing, and contrary to common practice.
> >>>
> >>> It is proposed that nquad's calling sequence be left as is, and that
> the
> >>> use of dbl- and tplquad be deprecated in some future version of SciPy,
> and
> >>> that nquad be recommended for multidimensional integration in new
> code. dbl-
> >>> and tplquad would of course be retained, though not recommended, in
> order to
> >>> avoid breaking existing code.
> >>>
> >>> Wow, that came out all legalistic. Anyway, what do you all think about
> >>> this change? I have a horse in the race (I wrote most of nquad), but I
> >>> really think that maintaining the backwards style from dbl- and
> tplquad and
> >>> enshrining it in new code is a bad idea. This is a perfect time to get
> away
> >>> from it, if that's what we want to do.
> >>
> >>
> >> My first instinct was that nquad should match what's already there in
> >> scipy.integrate, but I've changed my mind. I always have to look at the
> >> dblquad/tplquad documentation to get it right, so those functions don't
> have
> >> a good API imho. Therefore just making nquad do the logical thing (i.e.
> >> ``f(x, y ,z)``) makes sense to me.
> >>
> >> Let's not use the word "deprecate" for dblquad/tplquad, since they
> shouldn't
> >> be removed. Instead just recommend `nquad` as the function to use in the
> >> docs.
> >>
> >> Any other opinions?
> >
> > How do you know the integration order in the new interface?
> >
> > The current dblquad, tplquad looks to me like writing an integral
> >
> > integral_x integral_y integral_z  func3d(z, y,x)  dz dy dz
> > where integration limits are x=a..b, y=gfun(x)..hfun(x), and
> > z=qfun(x,y)..rfun(x,y)
> >
> > based on reading of the docstrings for tplquad. So this doesn't look
> > very strange to me.
> >
> > The suggested description
> > ``
> > The interface is given: nquad( f(x0,x1,?xn,t0,?tm)
> > ,[[x0_lo,x0_hi],?[xn_lo,xn_hi]],[t0,?tm],[opts0,?optsn]).
> > The ranges of integration are given in the same order as the arguments
> > in the function to be integrated.
> > ```
> >
> > Does this mean we integrate over x0 first (innermost integral) or last
> > (outermost integral) ?
> >
> > But I never used either function, so I could get used to both if the
> > docstring is clear.
> >
> > Josef
> >
> >
> >>
> >> Ralf
> >>
> >>
> >>> Good question. I think this needs some discussion on the scipy-dev
> list,
> >>> because it would be a fairly large change (dblquad/tplquad are old and
> >>> widely used I think). Could you please bring it up there?
> >>>
> >>> Yeah, I remember wondering how to handle that. It's not a very
> difficult
> >>> fix, and most of the work will be in changing over the examples and
> tests so
> >>> they work with the new ordering. However, do we really want to stick
> with
> >>> the old order?
> >>>
> >>> If we want to change it, then now is a perfect time, since nquad
> >>> duplicates and extends the functionality of dbl- and tplquad. Those two
> >>> could be deprecated and retained for compatibility, while nquad is
> >>> recommended for new code. Since the calling sequence for nquad is so
> >>> different, new users will have to adjust anyway.
> >>>
> >>> The current argument list for tplquad is confusing. The order of
> arguments
> >>> in the function does not match with the order of the range functions
> that
> >>> must be provided, which is a source of confusion. The ordering was
> >>> presumably chosen to make things look as much like quad as possible,
> but is
> >>> that really important now?
> >>>
> >>> As a reference, Matlab's integral3 and triplequad and GNU Octave's
> triple
> >>> quad both order things (x,y,z). SciPy's fft2 also appears to do things
> the
> >>> same way.
> >>>
> >>>
> >>> There's one thing that needs discussion: the integration order is
> reversed
> >>> compared to dblquad and tplquad. Where you'd use def func3d(z, y, x) in
> >>> tplquad you have to use def func3d(x, y, z) here. I was never a fan of
> the
> >>> order in dbp/tplquad, but we're stuck with that and I thinknquad
> should use
> >>> that same order for consistency.
> >>>
> >>>
> >>> _______________________________________________
> >>> SciPy-Dev mailing list
> >>> SciPy-Dev at scipy.org
> >>> http://mail.scipy.org/mailman/listinfo/scipy-dev
> >>>
> >>
> >>
> >> _______________________________________________
> >> SciPy-Dev mailing list
> >> SciPy-Dev at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
> >>
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130809/016e1c88/attachment.html>

From ralf.gommers at gmail.com  Sat Aug 10 10:48:51 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sat, 10 Aug 2013 16:48:51 +0200
Subject: [SciPy-Dev] Discussion on a new interface for multidimensional
	quadrature
In-Reply-To: <CAMRo0iuJmxKyvWvxPgA7=7DAdDceC3KbsrDVJx+ocaUMKonwUA@mail.gmail.com>
References: <8A6B959D-DB30-400E-ACA3-3933912D4ED0@gmail.com>
	<CABL7CQhSxSpuR64AfMZYyeCywWnBsX_YO1HCTq9vGFQFjivyQw@mail.gmail.com>
	<CAMMTP+BST9i-hpdm+D_c5tNna1zXVJZr3_Be=chU0rCiiMqrUQ@mail.gmail.com>
	<020F0119-5ED4-48A2-B799-3F317859C3CF@gmail.com>
	<CAMRo0iuJmxKyvWvxPgA7=7DAdDceC3KbsrDVJx+ocaUMKonwUA@mail.gmail.com>
Message-ID: <CABL7CQjsO_7i4BOFnfFrx9kT20kzCBcOMCatqyx1=9JDA1ug6Q@mail.gmail.com>

On Fri, Aug 9, 2013 at 5:55 AM, Evgeni Burovski
<evgeny.burovskiy at gmail.com>wrote:

> How about adding an optional argument to nquad, specifying the order of
> integration limits? Defaulting to the 'forward' order. Something like
>
> nquad(f(x,y), [a, b], [g(x), h(x)])
> being the default, and
>
> nquad(f(x,y), [a, b], [g(y), h(y)], integration_order='reversed')
> interpreting the limits the way dblquad/tplquad do.
>

That makes sense to me, both to make it easier to map to dblquad/tplquad
and to avoid writing an argument-reversing wrapper when you want to
integrate an existing function.


> Evgeni
> On Aug 9, 2013 11:35 AM, "Nathan Woods" <charlesnwoods at gmail.com> wrote:
>
>> Clear documentation is always important, so I don't think there will be
>> any problems there. Does anyone else have thoughts they'd like to share?
>>
>> Nate
>>
>> On Aug 5, 2013, at 11:35 PM, josef.pktd at gmail.com wrote:
>>
>> > On Mon, Aug 5, 2013 at 4:24 PM, Ralf Gommers <ralf.gommers at gmail.com>
>> wrote:
>> >>
>> >>
>> >>
>> >> On Fri, Aug 2, 2013 at 7:19 PM, Nathan Woods <charlesnwoods at gmail.com>
>> >> wrote:
>> >>>
>> >>> I'm copying the most relevant parts over from a discussion on GitHub,
>> >>> having to do with a new n-dimensional integration tool. The
>> discussion is
>> >>> whether or not to make nquad's new interface consistent with dbl-and
>> >>> tplquad, even though their precedent is arguably more confusing to
>> users.
>> >>>
>> >>> nquad is a recursively defined wrapper to scipy.integrate.quad that
>> allows
>> >>> for n-dimensional integration with almost the entire list of arguments
>> >>> allowed by quad. It is therefore more general than either dbl- or
>> tplquad,
>> >>> and encompasses their use cases, while allowing the user greater
>> control
>> >>> over the integration. The interface is given: nquad(
>> f(x0,x1,?xn,t0,?tm)
>> >>> ,[[x0_lo,x0_hi],?[xn_lo,xn_hi]],[t0,?tm],[opts0,?optsn]).
>> >>> The ranges of integration are given in the same order as the
>> arguments in
>> >>> the function to be integrated. This ordering is consistent with both
>> Matlab
>> >>> and Octave, and it is similar to what is encountered in other SciPy
>> packages
>> >>> such as fft. It is also what makes sense to new users.
>> >>>
>> >>> dbl- and tplquad, however, reverse the order of arguments in f. From
>> the
>> >>> documentation for tplquad:
>> >>>
>> >>> Return the triple integral of func(z, y, x) from x=a..b,
>> >>> y=gfun(x)..hfun(x), and z=qfun(x,y)..rfun(x,y)
>> >>>
>> >>> This is confusing, and contrary to common practice.
>> >>>
>> >>> It is proposed that nquad's calling sequence be left as is, and that
>> the
>> >>> use of dbl- and tplquad be deprecated in some future version of
>> SciPy, and
>> >>> that nquad be recommended for multidimensional integration in new
>> code. dbl-
>> >>> and tplquad would of course be retained, though not recommended, in
>> order to
>> >>> avoid breaking existing code.
>> >>>
>> >>> Wow, that came out all legalistic. Anyway, what do you all think about
>> >>> this change? I have a horse in the race (I wrote most of nquad), but I
>> >>> really think that maintaining the backwards style from dbl- and
>> tplquad and
>> >>> enshrining it in new code is a bad idea. This is a perfect time to
>> get away
>> >>> from it, if that's what we want to do.
>> >>
>> >>
>> >> My first instinct was that nquad should match what's already there in
>> >> scipy.integrate, but I've changed my mind. I always have to look at the
>> >> dblquad/tplquad documentation to get it right, so those functions
>> don't have
>> >> a good API imho. Therefore just making nquad do the logical thing (i.e.
>> >> ``f(x, y ,z)``) makes sense to me.
>> >>
>> >> Let's not use the word "deprecate" for dblquad/tplquad, since they
>> shouldn't
>> >> be removed. Instead just recommend `nquad` as the function to use in
>> the
>> >> docs.
>> >>
>> >> Any other opinions?
>> >
>> > How do you know the integration order in the new interface?
>> >
>> > The current dblquad, tplquad looks to me like writing an integral
>> >
>> > integral_x integral_y integral_z  func3d(z, y,x)  dz dy dz
>> > where integration limits are x=a..b, y=gfun(x)..hfun(x), and
>> > z=qfun(x,y)..rfun(x,y)
>> >
>> > based on reading of the docstrings for tplquad. So this doesn't look
>> > very strange to me.
>>
>
I guess that was the reason why dblquad/tplquad are implemented the way
they are. The problem with that is that no one writes functions like f(z,
y, x), everyone writes f(x, y, z). So it's plain unnatural.


> >
>> > The suggested description
>> > ``
>> > The interface is given: nquad( f(x0,x1,?xn,t0,?tm)
>> > ,[[x0_lo,x0_hi],?[xn_lo,xn_hi]],[t0,?tm],[opts0,?optsn]).
>> > The ranges of integration are given in the same order as the arguments
>> > in the function to be integrated.
>
> > ```
>> >
>> > Does this mean we integrate over x0 first (innermost integral) or last
>> > (outermost integral) ?
>>
>
x0 first, that should be made clearer in the docstring.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130810/35b62706/attachment.html>

From blake.a.griffith at gmail.com  Sun Aug 11 14:13:01 2013
From: blake.a.griffith at gmail.com (Blake Griffith)
Date: Sun, 11 Aug 2013 13:13:01 -0500
Subject: [SciPy-Dev] Testing SciPy against NumPy master.
Message-ID: <CAOiFMpx8a4v-odLcQvDWX01BSB_Zcq0bGAj8BNaN3tWjRKtPhQ@mail.gmail.com>

Would it be possible to have TravisCI test against NumPy master? Currently
it only tests against the latest stable version of NumPy, 1.7.x with
various versions of python. If this is possible, it would probably only
need to be done with Python 3.3.

When I test SciPy with NumPy master it seems like something new always
broken.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130811/4c5e5cb8/attachment.html>

From ralf.gommers at gmail.com  Sun Aug 11 14:51:40 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sun, 11 Aug 2013 20:51:40 +0200
Subject: [SciPy-Dev] Testing SciPy against NumPy master.
In-Reply-To: <CAOiFMpx8a4v-odLcQvDWX01BSB_Zcq0bGAj8BNaN3tWjRKtPhQ@mail.gmail.com>
References: <CAOiFMpx8a4v-odLcQvDWX01BSB_Zcq0bGAj8BNaN3tWjRKtPhQ@mail.gmail.com>
Message-ID: <CABL7CQhQzR81JDErsRh-PPFOic5144fQLsBf-+-=3xwS+GBt5w@mail.gmail.com>

On Sun, Aug 11, 2013 at 8:13 PM, Blake Griffith
<blake.a.griffith at gmail.com>wrote:

> Would it be possible to have TravisCI test against NumPy master? Currently
> it only tests against the latest stable version of NumPy, 1.7.x with
> various versions of python. If this is possible, it would probably only
> need to be done with Python 3.3.
>
> When I test SciPy with NumPy master it seems like something new always
> broken.
>

That's a good idea; it requires someone to figure out how to change the
.travis.yml config file to do the right thing here. Do you want to have a
go at that?

I think we'd want to change the build matrix to something like:

    python 2.6, numpy 1.5.1, testmode=full
    python 2.7, numpy 1.5.1, testmode=fast + pep8  # requires change to
runtests.py to do pep8 as well
    python 3.3, numpy master, testmode=fast

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130811/71cd475e/attachment.html>

From njs at pobox.com  Sun Aug 11 14:54:00 2013
From: njs at pobox.com (Nathaniel Smith)
Date: Sun, 11 Aug 2013 19:54:00 +0100
Subject: [SciPy-Dev] Testing SciPy against NumPy master.
In-Reply-To: <CABL7CQhQzR81JDErsRh-PPFOic5144fQLsBf-+-=3xwS+GBt5w@mail.gmail.com>
References: <CAOiFMpx8a4v-odLcQvDWX01BSB_Zcq0bGAj8BNaN3tWjRKtPhQ@mail.gmail.com>
	<CABL7CQhQzR81JDErsRh-PPFOic5144fQLsBf-+-=3xwS+GBt5w@mail.gmail.com>
Message-ID: <CAPJVwBkbx_kuQNmhVUCwk5O2kyqWuZoarVjkVhzwnrXQptZJvw@mail.gmail.com>

Should scipy test against numpy master, or should numpy test latest scipy
against numpy master? Arguably any time numpy master breaks scipy it's a
bug in numpy, so maybe this should be part of numpy's .travis.yml instead?
On 11 Aug 2013 19:51, "Ralf Gommers" <ralf.gommers at gmail.com> wrote:

>
>
>
> On Sun, Aug 11, 2013 at 8:13 PM, Blake Griffith <
> blake.a.griffith at gmail.com> wrote:
>
>> Would it be possible to have TravisCI test against NumPy master?
>> Currently it only tests against the latest stable version of NumPy, 1.7.x
>> with various versions of python. If this is possible, it would probably
>> only need to be done with Python 3.3.
>>
>> When I test SciPy with NumPy master it seems like something new always
>> broken.
>>
>
> That's a good idea; it requires someone to figure out how to change the
> .travis.yml config file to do the right thing here. Do you want to have a
> go at that?
>
> I think we'd want to change the build matrix to something like:
>
>     python 2.6, numpy 1.5.1, testmode=full
>     python 2.7, numpy 1.5.1, testmode=fast + pep8  # requires change to
> runtests.py to do pep8 as well
>     python 3.3, numpy master, testmode=fast
>
> Ralf
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130811/424d1c05/attachment.html>

From ralf.gommers at gmail.com  Sun Aug 11 15:02:17 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sun, 11 Aug 2013 21:02:17 +0200
Subject: [SciPy-Dev] Testing SciPy against NumPy master.
In-Reply-To: <CAPJVwBkbx_kuQNmhVUCwk5O2kyqWuZoarVjkVhzwnrXQptZJvw@mail.gmail.com>
References: <CAOiFMpx8a4v-odLcQvDWX01BSB_Zcq0bGAj8BNaN3tWjRKtPhQ@mail.gmail.com>
	<CABL7CQhQzR81JDErsRh-PPFOic5144fQLsBf-+-=3xwS+GBt5w@mail.gmail.com>
	<CAPJVwBkbx_kuQNmhVUCwk5O2kyqWuZoarVjkVhzwnrXQptZJvw@mail.gmail.com>
Message-ID: <CABL7CQj666wPrkerVsg7pEDTz9=3gKWFe8MSge0FO-R9Z+-Bcw@mail.gmail.com>

On Sun, Aug 11, 2013 at 8:54 PM, Nathaniel Smith <njs at pobox.com> wrote:

> Should scipy test against numpy master, or should numpy test latest scipy
> against numpy master? Arguably any time numpy master breaks scipy it's a
> bug in numpy, so maybe this should be part of numpy's .travis.yml instead?
>
Mostly failures are because of the changed test mode for numpy master
('develop' instead of 'release', turning warnings into errors), so I think
Blake's proposal makes sense.

Testing numpy master against a set of the latest releases of other packages
(scipy, scikit-xxx) would also be useful though.

Ralf



> On 11 Aug 2013 19:51, "Ralf Gommers" <ralf.gommers at gmail.com> wrote:
>
>>
>>
>>
>> On Sun, Aug 11, 2013 at 8:13 PM, Blake Griffith <
>> blake.a.griffith at gmail.com> wrote:
>>
>>> Would it be possible to have TravisCI test against NumPy master?
>>> Currently it only tests against the latest stable version of NumPy, 1.7.x
>>> with various versions of python. If this is possible, it would probably
>>> only need to be done with Python 3.3.
>>>
>>> When I test SciPy with NumPy master it seems like something new always
>>> broken.
>>>
>>
>> That's a good idea; it requires someone to figure out how to change the
>> .travis.yml config file to do the right thing here. Do you want to have a
>> go at that?
>>
>> I think we'd want to change the build matrix to something like:
>>
>>     python 2.6, numpy 1.5.1, testmode=full
>>     python 2.7, numpy 1.5.1, testmode=fast + pep8  # requires change to
>> runtests.py to do pep8 as well
>>     python 3.3, numpy master, testmode=fast
>>
>> Ralf
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130811/ce58f378/attachment.html>

From charlesnwoods at gmail.com  Sun Aug 11 23:00:05 2013
From: charlesnwoods at gmail.com (Nathan Woods)
Date: Sun, 11 Aug 2013 21:00:05 -0600
Subject: [SciPy-Dev] Discussion on a new interface for multidimensional
	quadrature
In-Reply-To: <CABL7CQjsO_7i4BOFnfFrx9kT20kzCBcOMCatqyx1=9JDA1ug6Q@mail.gmail.com>
References: <8A6B959D-DB30-400E-ACA3-3933912D4ED0@gmail.com>
	<CABL7CQhSxSpuR64AfMZYyeCywWnBsX_YO1HCTq9vGFQFjivyQw@mail.gmail.com>
	<CAMMTP+BST9i-hpdm+D_c5tNna1zXVJZr3_Be=chU0rCiiMqrUQ@mail.gmail.com>
	<020F0119-5ED4-48A2-B799-3F317859C3CF@gmail.com>
	<CAMRo0iuJmxKyvWvxPgA7=7DAdDceC3KbsrDVJx+ocaUMKonwUA@mail.gmail.com>
	<CABL7CQjsO_7i4BOFnfFrx9kT20kzCBcOMCatqyx1=9JDA1ug6Q@mail.gmail.com>
Message-ID: <56B370B5-C158-4B43-8A00-0905C0925DFF@gmail.com>

I like the optional argument idea. I think it gives a good balance between a clean interface and legacy support. It's also not too difficult to implement. 

Nate

On Aug 10, 2013, at 8:48 AM, Ralf Gommers <ralf.gommers at gmail.com> wrote:

> 
> 
> 
> On Fri, Aug 9, 2013 at 5:55 AM, Evgeni Burovski <evgeny.burovskiy at gmail.com> wrote:
> How about adding an optional argument to nquad, specifying the order of integration limits? Defaulting to the 'forward' order. Something like
> 
> nquad(f(x,y), [a, b], [g(x), h(x)])
> being the default, and
> 
> nquad(f(x,y), [a, b], [g(y), h(y)], integration_order='reversed')
> interpreting the limits the way dblquad/tplquad do.
> 
> 
> That makes sense to me, both to make it easier to map to dblquad/tplquad and to avoid writing an argument-reversing wrapper when you want to integrate an existing function.
>  
> Evgeni
> 
> On Aug 9, 2013 11:35 AM, "Nathan Woods" <charlesnwoods at gmail.com> wrote:
> Clear documentation is always important, so I don't think there will be any problems there. Does anyone else have thoughts they'd like to share?
> 
> Nate
> 
> On Aug 5, 2013, at 11:35 PM, josef.pktd at gmail.com wrote:
> 
> > On Mon, Aug 5, 2013 at 4:24 PM, Ralf Gommers <ralf.gommers at gmail.com> wrote:
> >>
> >>
> >>
> >> On Fri, Aug 2, 2013 at 7:19 PM, Nathan Woods <charlesnwoods at gmail.com>
> >> wrote:
> >>>
> >>> I'm copying the most relevant parts over from a discussion on GitHub,
> >>> having to do with a new n-dimensional integration tool. The discussion is
> >>> whether or not to make nquad's new interface consistent with dbl-and
> >>> tplquad, even though their precedent is arguably more confusing to users.
> >>>
> >>> nquad is a recursively defined wrapper to scipy.integrate.quad that allows
> >>> for n-dimensional integration with almost the entire list of arguments
> >>> allowed by quad. It is therefore more general than either dbl- or tplquad,
> >>> and encompasses their use cases, while allowing the user greater control
> >>> over the integration. The interface is given: nquad( f(x0,x1,?xn,t0,?tm)
> >>> ,[[x0_lo,x0_hi],?[xn_lo,xn_hi]],[t0,?tm],[opts0,?optsn]).
> >>> The ranges of integration are given in the same order as the arguments in
> >>> the function to be integrated. This ordering is consistent with both Matlab
> >>> and Octave, and it is similar to what is encountered in other SciPy packages
> >>> such as fft. It is also what makes sense to new users.
> >>>
> >>> dbl- and tplquad, however, reverse the order of arguments in f. From the
> >>> documentation for tplquad:
> >>>
> >>> Return the triple integral of func(z, y, x) from x=a..b,
> >>> y=gfun(x)..hfun(x), and z=qfun(x,y)..rfun(x,y)
> >>>
> >>> This is confusing, and contrary to common practice.
> >>>
> >>> It is proposed that nquad's calling sequence be left as is, and that the
> >>> use of dbl- and tplquad be deprecated in some future version of SciPy, and
> >>> that nquad be recommended for multidimensional integration in new code. dbl-
> >>> and tplquad would of course be retained, though not recommended, in order to
> >>> avoid breaking existing code.
> >>>
> >>> Wow, that came out all legalistic. Anyway, what do you all think about
> >>> this change? I have a horse in the race (I wrote most of nquad), but I
> >>> really think that maintaining the backwards style from dbl- and tplquad and
> >>> enshrining it in new code is a bad idea. This is a perfect time to get away
> >>> from it, if that's what we want to do.
> >>
> >>
> >> My first instinct was that nquad should match what's already there in
> >> scipy.integrate, but I've changed my mind. I always have to look at the
> >> dblquad/tplquad documentation to get it right, so those functions don't have
> >> a good API imho. Therefore just making nquad do the logical thing (i.e.
> >> ``f(x, y ,z)``) makes sense to me.
> >>
> >> Let's not use the word "deprecate" for dblquad/tplquad, since they shouldn't
> >> be removed. Instead just recommend `nquad` as the function to use in the
> >> docs.
> >>
> >> Any other opinions?
> >
> > How do you know the integration order in the new interface?
> >
> > The current dblquad, tplquad looks to me like writing an integral
> >
> > integral_x integral_y integral_z  func3d(z, y,x)  dz dy dz
> > where integration limits are x=a..b, y=gfun(x)..hfun(x), and
> > z=qfun(x,y)..rfun(x,y)
> >
> > based on reading of the docstrings for tplquad. So this doesn't look
> > very strange to me.
> 
> I guess that was the reason why dblquad/tplquad are implemented the way they are. The problem with that is that no one writes functions like f(z, y, x), everyone writes f(x, y, z). So it's plain unnatural.
>  
> >
> > The suggested description
> > ``
> > The interface is given: nquad( f(x0,x1,?xn,t0,?tm)
> > ,[[x0_lo,x0_hi],?[xn_lo,xn_hi]],[t0,?tm],[opts0,?optsn]).
> > The ranges of integration are given in the same order as the arguments
> > in the function to be integrated. 
> > ```
> >
> > Does this mean we integrate over x0 first (innermost integral) or last
> > (outermost integral) ?
> 
> x0 first, that should be made clearer in the docstring.
> 
> Ralf
> 
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130811/53bd0879/attachment.html>

From blake.a.griffith at gmail.com  Mon Aug 12 11:09:02 2013
From: blake.a.griffith at gmail.com (Blake Griffith)
Date: Mon, 12 Aug 2013 10:09:02 -0500
Subject: [SciPy-Dev] Testing SciPy against NumPy master.
In-Reply-To: <CABL7CQj666wPrkerVsg7pEDTz9=3gKWFe8MSge0FO-R9Z+-Bcw@mail.gmail.com>
References: <CAOiFMpx8a4v-odLcQvDWX01BSB_Zcq0bGAj8BNaN3tWjRKtPhQ@mail.gmail.com>
	<CABL7CQhQzR81JDErsRh-PPFOic5144fQLsBf-+-=3xwS+GBt5w@mail.gmail.com>
	<CAPJVwBkbx_kuQNmhVUCwk5O2kyqWuZoarVjkVhzwnrXQptZJvw@mail.gmail.com>
	<CABL7CQj666wPrkerVsg7pEDTz9=3gKWFe8MSge0FO-R9Z+-Bcw@mail.gmail.com>
Message-ID: <CAOiFMpwhR0-rXvPmDLsoxOJZgHrD0o0Mn_p9nzw0uEvunJmKwA@mail.gmail.com>

On Sun, Aug 11, 2013 at 2:02 PM, Ralf Gommers <ralf.gommers at gmail.com>wrote:

>
>
>
> On Sun, Aug 11, 2013 at 8:54 PM, Nathaniel Smith <njs at pobox.com> wrote:
>
>> Should scipy test against numpy master, or should numpy test latest scipy
>> against numpy master? Arguably any time numpy master breaks scipy it's a
>> bug in numpy, so maybe this should be part of numpy's .travis.yml instead?
>>
> Mostly failures are because of the changed test mode for numpy master
> ('develop' instead of 'release', turning warnings into errors), so I think
> Blake's proposal makes sense.
>
> Testing numpy master against a set of the latest releases of other
> packages (scipy, scikit-xxx) would also be useful though.
>
> Ralf
>
>
>
>> On 11 Aug 2013 19:51, "Ralf Gommers" <ralf.gommers at gmail.com> wrote:
>>
>>>
>>>
>>>
>>> On Sun, Aug 11, 2013 at 8:13 PM, Blake Griffith <
>>> blake.a.griffith at gmail.com> wrote:
>>>
>>>> Would it be possible to have TravisCI test against NumPy master?
>>>> Currently it only tests against the latest stable version of NumPy, 1.7.x
>>>> with various versions of python. If this is possible, it would probably
>>>> only need to be done with Python 3.3.
>>>>
>>>> When I test SciPy with NumPy master it seems like something new always
>>>> broken.
>>>>
>>>
>>> That's a good idea; it requires someone to figure out how to change the
>>> .travis.yml config file to do the right thing here. Do you want to have a
>>> go at that?
>>>
>>> I think we'd want to change the build matrix to something like:
>>>
>>>     python 2.6, numpy 1.5.1, testmode=full
>>>     python 2.7, numpy 1.5.1, testmode=fast + pep8  # requires change to
>>> runtests.py to do pep8 as well
>>>     python 3.3, numpy master, testmode=fast
>>>
>>> Ralf
>>>
>>
Changing the .travis.yml file doesn't seem too difficult. I'll try it out
on one of Travis' free trials asap.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130812/05e90fe9/attachment.html>

From charlesnwoods at gmail.com  Mon Aug 12 17:39:32 2013
From: charlesnwoods at gmail.com (Nathan Woods)
Date: Mon, 12 Aug 2013 15:39:32 -0600
Subject: [SciPy-Dev] Discussion on a new interface for multidimensional
	quadrature
In-Reply-To: <56B370B5-C158-4B43-8A00-0905C0925DFF@gmail.com>
References: <8A6B959D-DB30-400E-ACA3-3933912D4ED0@gmail.com>
	<CABL7CQhSxSpuR64AfMZYyeCywWnBsX_YO1HCTq9vGFQFjivyQw@mail.gmail.com>
	<CAMMTP+BST9i-hpdm+D_c5tNna1zXVJZr3_Be=chU0rCiiMqrUQ@mail.gmail.com>
	<020F0119-5ED4-48A2-B799-3F317859C3CF@gmail.com>
	<CAMRo0iuJmxKyvWvxPgA7=7DAdDceC3KbsrDVJx+ocaUMKonwUA@mail.gmail.com>
	<CABL7CQjsO_7i4BOFnfFrx9kT20kzCBcOMCatqyx1=9JDA1ug6Q@mail.gmail.com>
	<56B370B5-C158-4B43-8A00-0905C0925DFF@gmail.com>
Message-ID: <9029AF2D-E33D-4BAB-9973-DDD36E0482F4@gmail.com>

In the process of implementing the optional argument, I noticed something that I had missed before.

tplquad(f(z,y,x),x0,x1,y0,y1,z0,z1) gives the same answer, implemented in the same way (nesting order) as 

nquad(f(z,y,x),[[z0,z1],[y0,y1],[x0,x1]]).

That means that the only change here is in the calling sequence. The actual nesting order of integration remains the same (first argument to last). This means that there would be no need to wrap an existing function to reverse arguments, for instance.

I'm not entirely sure what was meant by mapping to dblquad/tplquad, though. Does that mean something like having dblquad/tplquad become wrappers for nquad? It seems like that would be something more easily done in the wrappers, rather than complicating the underlying function. Thoughts?

Nate


On Aug 11, 2013, at 9:00 PM, Nathan Woods <charlesnwoods at gmail.com> wrote:

> I like the optional argument idea. I think it gives a good balance between a clean interface and legacy support. It's also not too difficult to implement. 
> 
> Nate
> 
> On Aug 10, 2013, at 8:48 AM, Ralf Gommers <ralf.gommers at gmail.com> wrote:
> 
>> 
>> 
>> 
>> On Fri, Aug 9, 2013 at 5:55 AM, Evgeni Burovski <evgeny.burovskiy at gmail.com> wrote:
>> How about adding an optional argument to nquad, specifying the order of integration limits? Defaulting to the 'forward' order. Something like
>> 
>> nquad(f(x,y), [a, b], [g(x), h(x)])
>> being the default, and
>> 
>> nquad(f(x,y), [a, b], [g(y), h(y)], integration_order='reversed')
>> interpreting the limits the way dblquad/tplquad do.
>> 
>> 
>> That makes sense to me, both to make it easier to map to dblquad/tplquad and to avoid writing an argument-reversing wrapper when you want to integrate an existing function.
>>  
>> Evgeni
>> 
>> On Aug 9, 2013 11:35 AM, "Nathan Woods" <charlesnwoods at gmail.com> wrote:
>> Clear documentation is always important, so I don't think there will be any problems there. Does anyone else have thoughts they'd like to share?
>> 
>> Nate
>> 
>> On Aug 5, 2013, at 11:35 PM, josef.pktd at gmail.com wrote:
>> 
>> > On Mon, Aug 5, 2013 at 4:24 PM, Ralf Gommers <ralf.gommers at gmail.com> wrote:
>> >>
>> >>
>> >>
>> >> On Fri, Aug 2, 2013 at 7:19 PM, Nathan Woods <charlesnwoods at gmail.com>
>> >> wrote:
>> >>>
>> >>> I'm copying the most relevant parts over from a discussion on GitHub,
>> >>> having to do with a new n-dimensional integration tool. The discussion is
>> >>> whether or not to make nquad's new interface consistent with dbl-and
>> >>> tplquad, even though their precedent is arguably more confusing to users.
>> >>>
>> >>> nquad is a recursively defined wrapper to scipy.integrate.quad that allows
>> >>> for n-dimensional integration with almost the entire list of arguments
>> >>> allowed by quad. It is therefore more general than either dbl- or tplquad,
>> >>> and encompasses their use cases, while allowing the user greater control
>> >>> over the integration. The interface is given: nquad( f(x0,x1,?xn,t0,?tm)
>> >>> ,[[x0_lo,x0_hi],?[xn_lo,xn_hi]],[t0,?tm],[opts0,?optsn]).
>> >>> The ranges of integration are given in the same order as the arguments in
>> >>> the function to be integrated. This ordering is consistent with both Matlab
>> >>> and Octave, and it is similar to what is encountered in other SciPy packages
>> >>> such as fft. It is also what makes sense to new users.
>> >>>
>> >>> dbl- and tplquad, however, reverse the order of arguments in f. From the
>> >>> documentation for tplquad:
>> >>>
>> >>> Return the triple integral of func(z, y, x) from x=a..b,
>> >>> y=gfun(x)..hfun(x), and z=qfun(x,y)..rfun(x,y)
>> >>>
>> >>> This is confusing, and contrary to common practice.
>> >>>
>> >>> It is proposed that nquad's calling sequence be left as is, and that the
>> >>> use of dbl- and tplquad be deprecated in some future version of SciPy, and
>> >>> that nquad be recommended for multidimensional integration in new code. dbl-
>> >>> and tplquad would of course be retained, though not recommended, in order to
>> >>> avoid breaking existing code.
>> >>>
>> >>> Wow, that came out all legalistic. Anyway, what do you all think about
>> >>> this change? I have a horse in the race (I wrote most of nquad), but I
>> >>> really think that maintaining the backwards style from dbl- and tplquad and
>> >>> enshrining it in new code is a bad idea. This is a perfect time to get away
>> >>> from it, if that's what we want to do.
>> >>
>> >>
>> >> My first instinct was that nquad should match what's already there in
>> >> scipy.integrate, but I've changed my mind. I always have to look at the
>> >> dblquad/tplquad documentation to get it right, so those functions don't have
>> >> a good API imho. Therefore just making nquad do the logical thing (i.e.
>> >> ``f(x, y ,z)``) makes sense to me.
>> >>
>> >> Let's not use the word "deprecate" for dblquad/tplquad, since they shouldn't
>> >> be removed. Instead just recommend `nquad` as the function to use in the
>> >> docs.
>> >>
>> >> Any other opinions?
>> >
>> > How do you know the integration order in the new interface?
>> >
>> > The current dblquad, tplquad looks to me like writing an integral
>> >
>> > integral_x integral_y integral_z  func3d(z, y,x)  dz dy dz
>> > where integration limits are x=a..b, y=gfun(x)..hfun(x), and
>> > z=qfun(x,y)..rfun(x,y)
>> >
>> > based on reading of the docstrings for tplquad. So this doesn't look
>> > very strange to me.
>> 
>> I guess that was the reason why dblquad/tplquad are implemented the way they are. The problem with that is that no one writes functions like f(z, y, x), everyone writes f(x, y, z). So it's plain unnatural.
>>  
>> >
>> > The suggested description
>> > ``
>> > The interface is given: nquad( f(x0,x1,?xn,t0,?tm)
>> > ,[[x0_lo,x0_hi],?[xn_lo,xn_hi]],[t0,?tm],[opts0,?optsn]).
>> > The ranges of integration are given in the same order as the arguments
>> > in the function to be integrated. 
>> > ```
>> >
>> > Does this mean we integrate over x0 first (innermost integral) or last
>> > (outermost integral) ?
>> 
>> x0 first, that should be made clearer in the docstring.
>> 
>> Ralf
>> 
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130812/50bac52f/attachment.html>

From charlesnwoods at gmail.com  Tue Aug 13 12:38:13 2013
From: charlesnwoods at gmail.com (Nathan Woods)
Date: Tue, 13 Aug 2013 10:38:13 -0600
Subject: [SciPy-Dev] Discussion on a new interface for multidimensional
	quadrature
In-Reply-To: <9029AF2D-E33D-4BAB-9973-DDD36E0482F4@gmail.com>
References: <8A6B959D-DB30-400E-ACA3-3933912D4ED0@gmail.com>
	<CABL7CQhSxSpuR64AfMZYyeCywWnBsX_YO1HCTq9vGFQFjivyQw@mail.gmail.com>
	<CAMMTP+BST9i-hpdm+D_c5tNna1zXVJZr3_Be=chU0rCiiMqrUQ@mail.gmail.com>
	<020F0119-5ED4-48A2-B799-3F317859C3CF@gmail.com>
	<CAMRo0iuJmxKyvWvxPgA7=7DAdDceC3KbsrDVJx+ocaUMKonwUA@mail.gmail.com>
	<CABL7CQjsO_7i4BOFnfFrx9kT20kzCBcOMCatqyx1=9JDA1ug6Q@mail.gmail.com>
	<56B370B5-C158-4B43-8A00-0905C0925DFF@gmail.com>
	<9029AF2D-E33D-4BAB-9973-DDD36E0482F4@gmail.com>
Message-ID: <09F86485-FDFD-41A0-B4D8-EE38B883F57A@gmail.com>

Since I didn't hear from anyone, I went ahead and implemented the 'reversed' argument as requested. As expected, it was pretty simple. However, I really don't think it adds anything of value to the routine, and it does provide another avenue for error. My personal preference is to roll back the change and leave nquad as forward integration only. I'd appreciate anyone's thoughts on the matter.

N

On Aug 12, 2013, at 3:39 PM, Nathan Woods <charlesnwoods at gmail.com> wrote:

> In the process of implementing the optional argument, I noticed something that I had missed before.
> 
> tplquad(f(z,y,x),x0,x1,y0,y1,z0,z1) gives the same answer, implemented in the same way (nesting order) as 
> 
> nquad(f(z,y,x),[[z0,z1],[y0,y1],[x0,x1]]).
> 
> That means that the only change here is in the calling sequence. The actual nesting order of integration remains the same (first argument to last). This means that there would be no need to wrap an existing function to reverse arguments, for instance.
> 
> I'm not entirely sure what was meant by mapping to dblquad/tplquad, though. Does that mean something like having dblquad/tplquad become wrappers for nquad? It seems like that would be something more easily done in the wrappers, rather than complicating the underlying function. Thoughts?
> 
> Nate
> 
> 
> On Aug 11, 2013, at 9:00 PM, Nathan Woods <charlesnwoods at gmail.com> wrote:
> 
>> I like the optional argument idea. I think it gives a good balance between a clean interface and legacy support. It's also not too difficult to implement. 
>> 
>> Nate
>> 
>> On Aug 10, 2013, at 8:48 AM, Ralf Gommers <ralf.gommers at gmail.com> wrote:
>> 
>>> 
>>> 
>>> 
>>> On Fri, Aug 9, 2013 at 5:55 AM, Evgeni Burovski <evgeny.burovskiy at gmail.com> wrote:
>>> How about adding an optional argument to nquad, specifying the order of integration limits? Defaulting to the 'forward' order. Something like
>>> 
>>> nquad(f(x,y), [a, b], [g(x), h(x)])
>>> being the default, and
>>> 
>>> nquad(f(x,y), [a, b], [g(y), h(y)], integration_order='reversed')
>>> interpreting the limits the way dblquad/tplquad do.
>>> 
>>> 
>>> That makes sense to me, both to make it easier to map to dblquad/tplquad and to avoid writing an argument-reversing wrapper when you want to integrate an existing function.
>>>  
>>> Evgeni
>>> 
>>> On Aug 9, 2013 11:35 AM, "Nathan Woods" <charlesnwoods at gmail.com> wrote:
>>> Clear documentation is always important, so I don't think there will be any problems there. Does anyone else have thoughts they'd like to share?
>>> 
>>> Nate
>>> 
>>> On Aug 5, 2013, at 11:35 PM, josef.pktd at gmail.com wrote:
>>> 
>>> > On Mon, Aug 5, 2013 at 4:24 PM, Ralf Gommers <ralf.gommers at gmail.com> wrote:
>>> >>
>>> >>
>>> >>
>>> >> On Fri, Aug 2, 2013 at 7:19 PM, Nathan Woods <charlesnwoods at gmail.com>
>>> >> wrote:
>>> >>>
>>> >>> I'm copying the most relevant parts over from a discussion on GitHub,
>>> >>> having to do with a new n-dimensional integration tool. The discussion is
>>> >>> whether or not to make nquad's new interface consistent with dbl-and
>>> >>> tplquad, even though their precedent is arguably more confusing to users.
>>> >>>
>>> >>> nquad is a recursively defined wrapper to scipy.integrate.quad that allows
>>> >>> for n-dimensional integration with almost the entire list of arguments
>>> >>> allowed by quad. It is therefore more general than either dbl- or tplquad,
>>> >>> and encompasses their use cases, while allowing the user greater control
>>> >>> over the integration. The interface is given: nquad( f(x0,x1,?xn,t0,?tm)
>>> >>> ,[[x0_lo,x0_hi],?[xn_lo,xn_hi]],[t0,?tm],[opts0,?optsn]).
>>> >>> The ranges of integration are given in the same order as the arguments in
>>> >>> the function to be integrated. This ordering is consistent with both Matlab
>>> >>> and Octave, and it is similar to what is encountered in other SciPy packages
>>> >>> such as fft. It is also what makes sense to new users.
>>> >>>
>>> >>> dbl- and tplquad, however, reverse the order of arguments in f. From the
>>> >>> documentation for tplquad:
>>> >>>
>>> >>> Return the triple integral of func(z, y, x) from x=a..b,
>>> >>> y=gfun(x)..hfun(x), and z=qfun(x,y)..rfun(x,y)
>>> >>>
>>> >>> This is confusing, and contrary to common practice.
>>> >>>
>>> >>> It is proposed that nquad's calling sequence be left as is, and that the
>>> >>> use of dbl- and tplquad be deprecated in some future version of SciPy, and
>>> >>> that nquad be recommended for multidimensional integration in new code. dbl-
>>> >>> and tplquad would of course be retained, though not recommended, in order to
>>> >>> avoid breaking existing code.
>>> >>>
>>> >>> Wow, that came out all legalistic. Anyway, what do you all think about
>>> >>> this change? I have a horse in the race (I wrote most of nquad), but I
>>> >>> really think that maintaining the backwards style from dbl- and tplquad and
>>> >>> enshrining it in new code is a bad idea. This is a perfect time to get away
>>> >>> from it, if that's what we want to do.
>>> >>
>>> >>
>>> >> My first instinct was that nquad should match what's already there in
>>> >> scipy.integrate, but I've changed my mind. I always have to look at the
>>> >> dblquad/tplquad documentation to get it right, so those functions don't have
>>> >> a good API imho. Therefore just making nquad do the logical thing (i.e.
>>> >> ``f(x, y ,z)``) makes sense to me.
>>> >>
>>> >> Let's not use the word "deprecate" for dblquad/tplquad, since they shouldn't
>>> >> be removed. Instead just recommend `nquad` as the function to use in the
>>> >> docs.
>>> >>
>>> >> Any other opinions?
>>> >
>>> > How do you know the integration order in the new interface?
>>> >
>>> > The current dblquad, tplquad looks to me like writing an integral
>>> >
>>> > integral_x integral_y integral_z  func3d(z, y,x)  dz dy dz
>>> > where integration limits are x=a..b, y=gfun(x)..hfun(x), and
>>> > z=qfun(x,y)..rfun(x,y)
>>> >
>>> > based on reading of the docstrings for tplquad. So this doesn't look
>>> > very strange to me.
>>> 
>>> I guess that was the reason why dblquad/tplquad are implemented the way they are. The problem with that is that no one writes functions like f(z, y, x), everyone writes f(x, y, z). So it's plain unnatural.
>>>  
>>> >
>>> > The suggested description
>>> > ``
>>> > The interface is given: nquad( f(x0,x1,?xn,t0,?tm)
>>> > ,[[x0_lo,x0_hi],?[xn_lo,xn_hi]],[t0,?tm],[opts0,?optsn]).
>>> > The ranges of integration are given in the same order as the arguments
>>> > in the function to be integrated. 
>>> > ```
>>> >
>>> > Does this mean we integrate over x0 first (innermost integral) or last
>>> > (outermost integral) ?
>>> 
>>> x0 first, that should be made clearer in the docstring.
>>> 
>>> Ralf
>>> 
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130813/2ddb1f59/attachment.html>

From ralf.gommers at gmail.com  Tue Aug 13 13:20:17 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Tue, 13 Aug 2013 19:20:17 +0200
Subject: [SciPy-Dev] Discussion on a new interface for multidimensional
	quadrature
In-Reply-To: <09F86485-FDFD-41A0-B4D8-EE38B883F57A@gmail.com>
References: <8A6B959D-DB30-400E-ACA3-3933912D4ED0@gmail.com>
	<CABL7CQhSxSpuR64AfMZYyeCywWnBsX_YO1HCTq9vGFQFjivyQw@mail.gmail.com>
	<CAMMTP+BST9i-hpdm+D_c5tNna1zXVJZr3_Be=chU0rCiiMqrUQ@mail.gmail.com>
	<020F0119-5ED4-48A2-B799-3F317859C3CF@gmail.com>
	<CAMRo0iuJmxKyvWvxPgA7=7DAdDceC3KbsrDVJx+ocaUMKonwUA@mail.gmail.com>
	<CABL7CQjsO_7i4BOFnfFrx9kT20kzCBcOMCatqyx1=9JDA1ug6Q@mail.gmail.com>
	<56B370B5-C158-4B43-8A00-0905C0925DFF@gmail.com>
	<9029AF2D-E33D-4BAB-9973-DDD36E0482F4@gmail.com>
	<09F86485-FDFD-41A0-B4D8-EE38B883F57A@gmail.com>
Message-ID: <CABL7CQjQ8XW0adJRZxBAwq7DK=83U_PJsQ0PNrZNRP2UiAZTzw@mail.gmail.com>

On Tue, Aug 13, 2013 at 6:38 PM, Nathan Woods <charlesnwoods at gmail.com>wrote:

> Since I didn't hear from anyone, I went ahead and implemented the
> 'reversed' argument as requested. As expected, it was pretty simple.
> However, I really don't think it adds anything of value to the routine, and
> it does provide another avenue for error. My personal preference is to roll
> back the change and leave nquad as forward integration only. I'd appreciate
> anyone's thoughts on the matter.
>
> N
>
> On Aug 12, 2013, at 3:39 PM, Nathan Woods <charlesnwoods at gmail.com> wrote:
>
> In the process of implementing the optional argument, I noticed something
> that I had missed before.
>
> tplquad(f(z,y,x),x0,x1,y0,y1,z0,z1) gives the same answer, implemented in
> the same way (nesting order) as
>
> nquad(f(z,y,x),[[z0,z1],[y0,y1],[x0,x1]]).
>
>
This only helps if the integration limits are constants, so I think
'reversed' still helps.

Ralf


> That means that the only change here is in the calling sequence. The
> actual nesting order of integration remains the same (first argument to
> last). This means that there would be no need to wrap an existing function
> to reverse arguments, for instance.
>
> I'm not entirely sure what was meant by mapping to dblquad/tplquad,
> though. Does that mean something like having dblquad/tplquad become
> wrappers for nquad? It seems like that would be something more easily done
> in the wrappers, rather than complicating the underlying function. Thoughts?
>
> Nate
>
>
> On Aug 11, 2013, at 9:00 PM, Nathan Woods <charlesnwoods at gmail.com> wrote:
>
> I like the optional argument idea. I think it gives a good balance between
> a clean interface and legacy support. It's also not too difficult to
> implement.
>
> Nate
>
> On Aug 10, 2013, at 8:48 AM, Ralf Gommers <ralf.gommers at gmail.com> wrote:
>
>
>
>
> On Fri, Aug 9, 2013 at 5:55 AM, Evgeni Burovski <
> evgeny.burovskiy at gmail.com> wrote:
>
>> How about adding an optional argument to nquad, specifying the order of
>> integration limits? Defaulting to the 'forward' order. Something like
>>
>> nquad(f(x,y), [a, b], [g(x), h(x)])
>> being the default, and
>>
>> nquad(f(x,y), [a, b], [g(y), h(y)], integration_order='reversed')
>> interpreting the limits the way dblquad/tplquad do.
>>
>
> That makes sense to me, both to make it easier to map to dblquad/tplquad
> and to avoid writing an argument-reversing wrapper when you want to
> integrate an existing function.
>
>
>> Evgeni
>> On Aug 9, 2013 11:35 AM, "Nathan Woods" <charlesnwoods at gmail.com> wrote:
>>
>>> Clear documentation is always important, so I don't think there will be
>>> any problems there. Does anyone else have thoughts they'd like to share?
>>>
>>> Nate
>>>
>>> On Aug 5, 2013, at 11:35 PM, josef.pktd at gmail.com wrote:
>>>
>>> > On Mon, Aug 5, 2013 at 4:24 PM, Ralf Gommers <ralf.gommers at gmail.com>
>>> wrote:
>>> >>
>>> >>
>>> >>
>>> >> On Fri, Aug 2, 2013 at 7:19 PM, Nathan Woods <charlesnwoods at gmail.com
>>> >
>>> >> wrote:
>>> >>>
>>> >>> I'm copying the most relevant parts over from a discussion on GitHub,
>>> >>> having to do with a new n-dimensional integration tool. The
>>> discussion is
>>> >>> whether or not to make nquad's new interface consistent with dbl-and
>>> >>> tplquad, even though their precedent is arguably more confusing to
>>> users.
>>> >>>
>>> >>> nquad is a recursively defined wrapper to scipy.integrate.quad that
>>> allows
>>> >>> for n-dimensional integration with almost the entire list of
>>> arguments
>>> >>> allowed by quad. It is therefore more general than either dbl- or
>>> tplquad,
>>> >>> and encompasses their use cases, while allowing the user greater
>>> control
>>> >>> over the integration. The interface is given: nquad(
>>> f(x0,x1,?xn,t0,?tm)
>>> >>> ,[[x0_lo,x0_hi],?[xn_lo,xn_hi]],[t0,?tm],[opts0,?optsn]).
>>> >>> The ranges of integration are given in the same order as the
>>> arguments in
>>> >>> the function to be integrated. This ordering is consistent with both
>>> Matlab
>>> >>> and Octave, and it is similar to what is encountered in other SciPy
>>> packages
>>> >>> such as fft. It is also what makes sense to new users.
>>> >>>
>>> >>> dbl- and tplquad, however, reverse the order of arguments in f. From
>>> the
>>> >>> documentation for tplquad:
>>> >>>
>>> >>> Return the triple integral of func(z, y, x) from x=a..b,
>>> >>> y=gfun(x)..hfun(x), and z=qfun(x,y)..rfun(x,y)
>>> >>>
>>> >>> This is confusing, and contrary to common practice.
>>> >>>
>>> >>> It is proposed that nquad's calling sequence be left as is, and that
>>> the
>>> >>> use of dbl- and tplquad be deprecated in some future version of
>>> SciPy, and
>>> >>> that nquad be recommended for multidimensional integration in new
>>> code. dbl-
>>> >>> and tplquad would of course be retained, though not recommended, in
>>> order to
>>> >>> avoid breaking existing code.
>>> >>>
>>> >>> Wow, that came out all legalistic. Anyway, what do you all think
>>> about
>>> >>> this change? I have a horse in the race (I wrote most of nquad), but
>>> I
>>> >>> really think that maintaining the backwards style from dbl- and
>>> tplquad and
>>> >>> enshrining it in new code is a bad idea. This is a perfect time to
>>> get away
>>> >>> from it, if that's what we want to do.
>>> >>
>>> >>
>>> >> My first instinct was that nquad should match what's already there in
>>> >> scipy.integrate, but I've changed my mind. I always have to look at
>>> the
>>> >> dblquad/tplquad documentation to get it right, so those functions
>>> don't have
>>> >> a good API imho. Therefore just making nquad do the logical thing
>>> (i.e.
>>> >> ``f(x, y ,z)``) makes sense to me.
>>> >>
>>> >> Let's not use the word "deprecate" for dblquad/tplquad, since they
>>> shouldn't
>>> >> be removed. Instead just recommend `nquad` as the function to use in
>>> the
>>> >> docs.
>>> >>
>>> >> Any other opinions?
>>> >
>>> > How do you know the integration order in the new interface?
>>> >
>>> > The current dblquad, tplquad looks to me like writing an integral
>>> >
>>> > integral_x integral_y integral_z  func3d(z, y,x)  dz dy dz
>>> > where integration limits are x=a..b, y=gfun(x)..hfun(x), and
>>> > z=qfun(x,y)..rfun(x,y)
>>> >
>>> > based on reading of the docstrings for tplquad. So this doesn't look
>>> > very strange to me.
>>>
>>
> I guess that was the reason why dblquad/tplquad are implemented the way
> they are. The problem with that is that no one writes functions like f(z,
> y, x), everyone writes f(x, y, z). So it's plain unnatural.
>
>
>> >
>>> > The suggested description
>>> > ``
>>> > The interface is given: nquad( f(x0,x1,?xn,t0,?tm)
>>> > ,[[x0_lo,x0_hi],?[xn_lo,xn_hi]],[t0,?tm],[opts0,?optsn]).
>>> > The ranges of integration are given in the same order as the arguments
>>> > in the function to be integrated.
>>
>>  > ```
>>> >
>>> > Does this mean we integrate over x0 first (innermost integral) or last
>>> > (outermost integral) ?
>>>
>>
> x0 first, that should be made clearer in the docstring.
>
> Ralf
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
>
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130813/4b97def6/attachment.html>

From ralf.gommers at gmail.com  Tue Aug 13 15:42:16 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Tue, 13 Aug 2013 21:42:16 +0200
Subject: [SciPy-Dev] Discussion on a new interface for multidimensional
	quadrature
In-Reply-To: <CABL7CQjQ8XW0adJRZxBAwq7DK=83U_PJsQ0PNrZNRP2UiAZTzw@mail.gmail.com>
References: <8A6B959D-DB30-400E-ACA3-3933912D4ED0@gmail.com>
	<CABL7CQhSxSpuR64AfMZYyeCywWnBsX_YO1HCTq9vGFQFjivyQw@mail.gmail.com>
	<CAMMTP+BST9i-hpdm+D_c5tNna1zXVJZr3_Be=chU0rCiiMqrUQ@mail.gmail.com>
	<020F0119-5ED4-48A2-B799-3F317859C3CF@gmail.com>
	<CAMRo0iuJmxKyvWvxPgA7=7DAdDceC3KbsrDVJx+ocaUMKonwUA@mail.gmail.com>
	<CABL7CQjsO_7i4BOFnfFrx9kT20kzCBcOMCatqyx1=9JDA1ug6Q@mail.gmail.com>
	<56B370B5-C158-4B43-8A00-0905C0925DFF@gmail.com>
	<9029AF2D-E33D-4BAB-9973-DDD36E0482F4@gmail.com>
	<09F86485-FDFD-41A0-B4D8-EE38B883F57A@gmail.com>
	<CABL7CQjQ8XW0adJRZxBAwq7DK=83U_PJsQ0PNrZNRP2UiAZTzw@mail.gmail.com>
Message-ID: <CABL7CQjWsHjNLuQ=43gx=ozJ+jtyhOCkk05c3GHOmhR5YbwiSA@mail.gmail.com>

On Tue, Aug 13, 2013 at 7:20 PM, Ralf Gommers <ralf.gommers at gmail.com>wrote:

>
>
>
> On Tue, Aug 13, 2013 at 6:38 PM, Nathan Woods <charlesnwoods at gmail.com>wrote:
>
>> Since I didn't hear from anyone, I went ahead and implemented the
>> 'reversed' argument as requested. As expected, it was pretty simple.
>> However, I really don't think it adds anything of value to the routine, and
>> it does provide another avenue for error. My personal preference is to roll
>> back the change and leave nquad as forward integration only. I'd appreciate
>> anyone's thoughts on the matter.
>>
>> N
>>
>> On Aug 12, 2013, at 3:39 PM, Nathan Woods <charlesnwoods at gmail.com>
>> wrote:
>>
>> In the process of implementing the optional argument, I noticed something
>> that I had missed before.
>>
>> tplquad(f(z,y,x),x0,x1,y0,y1,z0,z1) gives the same answer, implemented in
>> the same way (nesting order) as
>>
>> nquad(f(z,y,x),[[z0,z1],[y0,y1],[x0,x1]]).
>>
>>
> This only helps if the integration limits are constants, so I think
> 'reversed' still helps.
>

Now that I looked at how you implemented this, indeed that doesn't help
much. What I was thinking is that 'reversed' would reverse the order of
integration, so first over y instead of first over x for a function f(x,
y). I suspect that's also what Evgeni meant.

Ralf


>> That means that the only change here is in the calling sequence. The
>> actual nesting order of integration remains the same (first argument to
>> last). This means that there would be no need to wrap an existing function
>> to reverse arguments, for instance.
>>
>> I'm not entirely sure what was meant by mapping to dblquad/tplquad,
>> though. Does that mean something like having dblquad/tplquad become
>> wrappers for nquad? It seems like that would be something more easily done
>> in the wrappers, rather than complicating the underlying function. Thoughts?
>>
>> Nate
>>
>>
>> On Aug 11, 2013, at 9:00 PM, Nathan Woods <charlesnwoods at gmail.com>
>> wrote:
>>
>> I like the optional argument idea. I think it gives a good balance
>> between a clean interface and legacy support. It's also not too difficult
>> to implement.
>>
>> Nate
>>
>> On Aug 10, 2013, at 8:48 AM, Ralf Gommers <ralf.gommers at gmail.com> wrote:
>>
>>
>>
>>
>> On Fri, Aug 9, 2013 at 5:55 AM, Evgeni Burovski <
>> evgeny.burovskiy at gmail.com> wrote:
>>
>>> How about adding an optional argument to nquad, specifying the order of
>>> integration limits? Defaulting to the 'forward' order. Something like
>>>
>>> nquad(f(x,y), [a, b], [g(x), h(x)])
>>> being the default, and
>>>
>>> nquad(f(x,y), [a, b], [g(y), h(y)], integration_order='reversed')
>>> interpreting the limits the way dblquad/tplquad do.
>>>
>>
>> That makes sense to me, both to make it easier to map to dblquad/tplquad
>> and to avoid writing an argument-reversing wrapper when you want to
>> integrate an existing function.
>>
>>
>>> Evgeni
>>> On Aug 9, 2013 11:35 AM, "Nathan Woods" <charlesnwoods at gmail.com> wrote:
>>>
>>>> Clear documentation is always important, so I don't think there will be
>>>> any problems there. Does anyone else have thoughts they'd like to share?
>>>>
>>>> Nate
>>>>
>>>> On Aug 5, 2013, at 11:35 PM, josef.pktd at gmail.com wrote:
>>>>
>>>> > On Mon, Aug 5, 2013 at 4:24 PM, Ralf Gommers <ralf.gommers at gmail.com>
>>>> wrote:
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Fri, Aug 2, 2013 at 7:19 PM, Nathan Woods <
>>>> charlesnwoods at gmail.com>
>>>> >> wrote:
>>>> >>>
>>>> >>> I'm copying the most relevant parts over from a discussion on
>>>> GitHub,
>>>> >>> having to do with a new n-dimensional integration tool. The
>>>> discussion is
>>>> >>> whether or not to make nquad's new interface consistent with dbl-and
>>>> >>> tplquad, even though their precedent is arguably more confusing to
>>>> users.
>>>> >>>
>>>> >>> nquad is a recursively defined wrapper to scipy.integrate.quad that
>>>> allows
>>>> >>> for n-dimensional integration with almost the entire list of
>>>> arguments
>>>> >>> allowed by quad. It is therefore more general than either dbl- or
>>>> tplquad,
>>>> >>> and encompasses their use cases, while allowing the user greater
>>>> control
>>>> >>> over the integration. The interface is given: nquad(
>>>> f(x0,x1,?xn,t0,?tm)
>>>> >>> ,[[x0_lo,x0_hi],?[xn_lo,xn_hi]],[t0,?tm],[opts0,?optsn]).
>>>> >>> The ranges of integration are given in the same order as the
>>>> arguments in
>>>> >>> the function to be integrated. This ordering is consistent with
>>>> both Matlab
>>>> >>> and Octave, and it is similar to what is encountered in other SciPy
>>>> packages
>>>> >>> such as fft. It is also what makes sense to new users.
>>>> >>>
>>>> >>> dbl- and tplquad, however, reverse the order of arguments in f.
>>>> From the
>>>> >>> documentation for tplquad:
>>>> >>>
>>>> >>> Return the triple integral of func(z, y, x) from x=a..b,
>>>> >>> y=gfun(x)..hfun(x), and z=qfun(x,y)..rfun(x,y)
>>>> >>>
>>>> >>> This is confusing, and contrary to common practice.
>>>> >>>
>>>> >>> It is proposed that nquad's calling sequence be left as is, and
>>>> that the
>>>> >>> use of dbl- and tplquad be deprecated in some future version of
>>>> SciPy, and
>>>> >>> that nquad be recommended for multidimensional integration in new
>>>> code. dbl-
>>>> >>> and tplquad would of course be retained, though not recommended, in
>>>> order to
>>>> >>> avoid breaking existing code.
>>>> >>>
>>>> >>> Wow, that came out all legalistic. Anyway, what do you all think
>>>> about
>>>> >>> this change? I have a horse in the race (I wrote most of nquad),
>>>> but I
>>>> >>> really think that maintaining the backwards style from dbl- and
>>>> tplquad and
>>>> >>> enshrining it in new code is a bad idea. This is a perfect time to
>>>> get away
>>>> >>> from it, if that's what we want to do.
>>>> >>
>>>> >>
>>>> >> My first instinct was that nquad should match what's already there in
>>>> >> scipy.integrate, but I've changed my mind. I always have to look at
>>>> the
>>>> >> dblquad/tplquad documentation to get it right, so those functions
>>>> don't have
>>>> >> a good API imho. Therefore just making nquad do the logical thing
>>>> (i.e.
>>>> >> ``f(x, y ,z)``) makes sense to me.
>>>> >>
>>>> >> Let's not use the word "deprecate" for dblquad/tplquad, since they
>>>> shouldn't
>>>> >> be removed. Instead just recommend `nquad` as the function to use in
>>>> the
>>>> >> docs.
>>>> >>
>>>> >> Any other opinions?
>>>> >
>>>> > How do you know the integration order in the new interface?
>>>> >
>>>> > The current dblquad, tplquad looks to me like writing an integral
>>>> >
>>>> > integral_x integral_y integral_z  func3d(z, y,x)  dz dy dz
>>>> > where integration limits are x=a..b, y=gfun(x)..hfun(x), and
>>>> > z=qfun(x,y)..rfun(x,y)
>>>> >
>>>> > based on reading of the docstrings for tplquad. So this doesn't look
>>>> > very strange to me.
>>>>
>>>
>> I guess that was the reason why dblquad/tplquad are implemented the way
>> they are. The problem with that is that no one writes functions like f(z,
>> y, x), everyone writes f(x, y, z). So it's plain unnatural.
>>
>>
>>> >
>>>> > The suggested description
>>>> > ``
>>>> > The interface is given: nquad( f(x0,x1,?xn,t0,?tm)
>>>> > ,[[x0_lo,x0_hi],?[xn_lo,xn_hi]],[t0,?tm],[opts0,?optsn]).
>>>> > The ranges of integration are given in the same order as the arguments
>>>> > in the function to be integrated.
>>>
>>>  > ```
>>>> >
>>>> > Does this mean we integrate over x0 first (innermost integral) or last
>>>> > (outermost integral) ?
>>>>
>>>
>> x0 first, that should be made clearer in the docstring.
>>
>> Ralf
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
>>
>>
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130813/ebaba880/attachment.html>

From charlesnwoods at gmail.com  Tue Aug 13 15:49:13 2013
From: charlesnwoods at gmail.com (Nathan Woods)
Date: Tue, 13 Aug 2013 13:49:13 -0600
Subject: [SciPy-Dev] Discussion on a new interface for multidimensional
	quadrature
In-Reply-To: <CABL7CQjWsHjNLuQ=43gx=ozJ+jtyhOCkk05c3GHOmhR5YbwiSA@mail.gmail.com>
References: <8A6B959D-DB30-400E-ACA3-3933912D4ED0@gmail.com>
	<CABL7CQhSxSpuR64AfMZYyeCywWnBsX_YO1HCTq9vGFQFjivyQw@mail.gmail.com>
	<CAMMTP+BST9i-hpdm+D_c5tNna1zXVJZr3_Be=chU0rCiiMqrUQ@mail.gmail.com>
	<020F0119-5ED4-48A2-B799-3F317859C3CF@gmail.com>
	<CAMRo0iuJmxKyvWvxPgA7=7DAdDceC3KbsrDVJx+ocaUMKonwUA@mail.gmail.com>
	<CABL7CQjsO_7i4BOFnfFrx9kT20kzCBcOMCatqyx1=9JDA1ug6Q@mail.gmail.com>
	<56B370B5-C158-4B43-8A00-0905C0925DFF@gmail.com>
	<9029AF2D-E33D-4BAB-9973-DDD36E0482F4@gmail.com>
	<09F86485-FDFD-41A0-B4D8-EE38B883F57A@gmail.com>
	<CABL7CQjQ8XW0adJRZxBAwq7DK=83U_PJsQ0PNrZNRP2UiAZTzw@mail.gmail.com>
	<CABL7CQjWsHjNLuQ=43gx=ozJ+jtyhOCkk05c3GHOmhR5YbwiSA@mail.gmail.com>
Message-ID: <664B81D9-DFD0-4B3A-A097-18968C4AE723@gmail.com>

Right, that's what I thought, too. The thing is that dbl- and tplquad DON'T do that. If you carefully at the calling sequence for tplquad, 
-----------
scipy.integrate.tplquad(func, a, b, gfun, hfun, qfun, rfun, args=(), epsabs=1.49e-08, epsrel=1.49e-08)[source]?

Return the triple integral of func(z, y, x) from x=a..b, y=gfun(x)..hfun(x), and z=qfun(x,y)..rfun(x,y)
------------

The only way that the underlying quad routine can accept qfun(x,y) and rfun(x,y) as limits is if they are evaluated to be constants. That is, integration over z must be the innermost loop of integration, with fund(z,y,z), qfun(x,y), and rfun(x,y) receiving (x,y) passed in as arguments from the outer loops. 

I agree that the changes I just put in are kind of ridiculous, but (as far as I can tell) they exactly duplicate what is done in dbl- and tplquad.


If we really want to put in some kind of integration order, then that's also not too hard, though a bit more than just reversing the lists. It's just something that I don't see a real, compelling reason to do. 

N


On Aug 13, 2013, at 1:42 PM, Ralf Gommers <ralf.gommers at gmail.com> wrote:

> 
> 
> 
> On Tue, Aug 13, 2013 at 7:20 PM, Ralf Gommers <ralf.gommers at gmail.com> wrote:
> 
> 
> 
> On Tue, Aug 13, 2013 at 6:38 PM, Nathan Woods <charlesnwoods at gmail.com> wrote:
> Since I didn't hear from anyone, I went ahead and implemented the 'reversed' argument as requested. As expected, it was pretty simple. However, I really don't think it adds anything of value to the routine, and it does provide another avenue for error. My personal preference is to roll back the change and leave nquad as forward integration only. I'd appreciate anyone's thoughts on the matter.
> 
> N
> 
> On Aug 12, 2013, at 3:39 PM, Nathan Woods <charlesnwoods at gmail.com> wrote:
> 
>> In the process of implementing the optional argument, I noticed something that I had missed before.
>> 
>> tplquad(f(z,y,x),x0,x1,y0,y1,z0,z1) gives the same answer, implemented in the same way (nesting order) as 
>> 
>> nquad(f(z,y,x),[[z0,z1],[y0,y1],[x0,x1]]).
> 
> 
> This only helps if the integration limits are constants, so I think 'reversed' still helps.
> 
> Now that I looked at how you implemented this, indeed that doesn't help much. What I was thinking is that 'reversed' would reverse the order of integration, so first over y instead of first over x for a function f(x, y). I suspect that's also what Evgeni meant.
> 
> Ralf
> 
>> 
>> That means that the only change here is in the calling sequence. The actual nesting order of integration remains the same (first argument to last). This means that there would be no need to wrap an existing function to reverse arguments, for instance.
>> 
>> I'm not entirely sure what was meant by mapping to dblquad/tplquad, though. Does that mean something like having dblquad/tplquad become wrappers for nquad? It seems like that would be something more easily done in the wrappers, rather than complicating the underlying function. Thoughts?
>> 
>> Nate
>> 
>> 
>> On Aug 11, 2013, at 9:00 PM, Nathan Woods <charlesnwoods at gmail.com> wrote:
>> 
>>> I like the optional argument idea. I think it gives a good balance between a clean interface and legacy support. It's also not too difficult to implement. 
>>> 
>>> Nate
>>> 
>>> On Aug 10, 2013, at 8:48 AM, Ralf Gommers <ralf.gommers at gmail.com> wrote:
>>> 
>>>> 
>>>> 
>>>> 
>>>> On Fri, Aug 9, 2013 at 5:55 AM, Evgeni Burovski <evgeny.burovskiy at gmail.com> wrote:
>>>> How about adding an optional argument to nquad, specifying the order of integration limits? Defaulting to the 'forward' order. Something like
>>>> 
>>>> nquad(f(x,y), [a, b], [g(x), h(x)])
>>>> being the default, and
>>>> 
>>>> nquad(f(x,y), [a, b], [g(y), h(y)], integration_order='reversed')
>>>> interpreting the limits the way dblquad/tplquad do.
>>>> 
>>>> 
>>>> That makes sense to me, both to make it easier to map to dblquad/tplquad and to avoid writing an argument-reversing wrapper when you want to integrate an existing function.
>>>>  
>>>> Evgeni
>>>> 
>>>> On Aug 9, 2013 11:35 AM, "Nathan Woods" <charlesnwoods at gmail.com> wrote:
>>>> Clear documentation is always important, so I don't think there will be any problems there. Does anyone else have thoughts they'd like to share?
>>>> 
>>>> Nate
>>>> 
>>>> On Aug 5, 2013, at 11:35 PM, josef.pktd at gmail.com wrote:
>>>> 
>>>> > On Mon, Aug 5, 2013 at 4:24 PM, Ralf Gommers <ralf.gommers at gmail.com> wrote:
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Fri, Aug 2, 2013 at 7:19 PM, Nathan Woods <charlesnwoods at gmail.com>
>>>> >> wrote:
>>>> >>>
>>>> >>> I'm copying the most relevant parts over from a discussion on GitHub,
>>>> >>> having to do with a new n-dimensional integration tool. The discussion is
>>>> >>> whether or not to make nquad's new interface consistent with dbl-and
>>>> >>> tplquad, even though their precedent is arguably more confusing to users.
>>>> >>>
>>>> >>> nquad is a recursively defined wrapper to scipy.integrate.quad that allows
>>>> >>> for n-dimensional integration with almost the entire list of arguments
>>>> >>> allowed by quad. It is therefore more general than either dbl- or tplquad,
>>>> >>> and encompasses their use cases, while allowing the user greater control
>>>> >>> over the integration. The interface is given: nquad( f(x0,x1,?xn,t0,?tm)
>>>> >>> ,[[x0_lo,x0_hi],?[xn_lo,xn_hi]],[t0,?tm],[opts0,?optsn]).
>>>> >>> The ranges of integration are given in the same order as the arguments in
>>>> >>> the function to be integrated. This ordering is consistent with both Matlab
>>>> >>> and Octave, and it is similar to what is encountered in other SciPy packages
>>>> >>> such as fft. It is also what makes sense to new users.
>>>> >>>
>>>> >>> dbl- and tplquad, however, reverse the order of arguments in f. From the
>>>> >>> documentation for tplquad:
>>>> >>>
>>>> >>> Return the triple integral of func(z, y, x) from x=a..b,
>>>> >>> y=gfun(x)..hfun(x), and z=qfun(x,y)..rfun(x,y)
>>>> >>>
>>>> >>> This is confusing, and contrary to common practice.
>>>> >>>
>>>> >>> It is proposed that nquad's calling sequence be left as is, and that the
>>>> >>> use of dbl- and tplquad be deprecated in some future version of SciPy, and
>>>> >>> that nquad be recommended for multidimensional integration in new code. dbl-
>>>> >>> and tplquad would of course be retained, though not recommended, in order to
>>>> >>> avoid breaking existing code.
>>>> >>>
>>>> >>> Wow, that came out all legalistic. Anyway, what do you all think about
>>>> >>> this change? I have a horse in the race (I wrote most of nquad), but I
>>>> >>> really think that maintaining the backwards style from dbl- and tplquad and
>>>> >>> enshrining it in new code is a bad idea. This is a perfect time to get away
>>>> >>> from it, if that's what we want to do.
>>>> >>
>>>> >>
>>>> >> My first instinct was that nquad should match what's already there in
>>>> >> scipy.integrate, but I've changed my mind. I always have to look at the
>>>> >> dblquad/tplquad documentation to get it right, so those functions don't have
>>>> >> a good API imho. Therefore just making nquad do the logical thing (i.e.
>>>> >> ``f(x, y ,z)``) makes sense to me.
>>>> >>
>>>> >> Let's not use the word "deprecate" for dblquad/tplquad, since they shouldn't
>>>> >> be removed. Instead just recommend `nquad` as the function to use in the
>>>> >> docs.
>>>> >>
>>>> >> Any other opinions?
>>>> >
>>>> > How do you know the integration order in the new interface?
>>>> >
>>>> > The current dblquad, tplquad looks to me like writing an integral
>>>> >
>>>> > integral_x integral_y integral_z  func3d(z, y,x)  dz dy dz
>>>> > where integration limits are x=a..b, y=gfun(x)..hfun(x), and
>>>> > z=qfun(x,y)..rfun(x,y)
>>>> >
>>>> > based on reading of the docstrings for tplquad. So this doesn't look
>>>> > very strange to me.
>>>> 
>>>> I guess that was the reason why dblquad/tplquad are implemented the way they are. The problem with that is that no one writes functions like f(z, y, x), everyone writes f(x, y, z). So it's plain unnatural.
>>>>  
>>>> >
>>>> > The suggested description
>>>> > ``
>>>> > The interface is given: nquad( f(x0,x1,?xn,t0,?tm)
>>>> > ,[[x0_lo,x0_hi],?[xn_lo,xn_hi]],[t0,?tm],[opts0,?optsn]).
>>>> > The ranges of integration are given in the same order as the arguments
>>>> > in the function to be integrated. 
>>>> > ```
>>>> >
>>>> > Does this mean we integrate over x0 first (innermost integral) or last
>>>> > (outermost integral) ?
>>>> 
>>>> x0 first, that should be made clearer in the docstring.
>>>> 
>>>> Ralf
>>>> 
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>> 
>> 
> 
> 
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 
> 
> 
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130813/12903175/attachment.html>

From ralf.gommers at gmail.com  Tue Aug 13 16:07:57 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Tue, 13 Aug 2013 22:07:57 +0200
Subject: [SciPy-Dev] Discussion on a new interface for multidimensional
	quadrature
In-Reply-To: <664B81D9-DFD0-4B3A-A097-18968C4AE723@gmail.com>
References: <8A6B959D-DB30-400E-ACA3-3933912D4ED0@gmail.com>
	<CABL7CQhSxSpuR64AfMZYyeCywWnBsX_YO1HCTq9vGFQFjivyQw@mail.gmail.com>
	<CAMMTP+BST9i-hpdm+D_c5tNna1zXVJZr3_Be=chU0rCiiMqrUQ@mail.gmail.com>
	<020F0119-5ED4-48A2-B799-3F317859C3CF@gmail.com>
	<CAMRo0iuJmxKyvWvxPgA7=7DAdDceC3KbsrDVJx+ocaUMKonwUA@mail.gmail.com>
	<CABL7CQjsO_7i4BOFnfFrx9kT20kzCBcOMCatqyx1=9JDA1ug6Q@mail.gmail.com>
	<56B370B5-C158-4B43-8A00-0905C0925DFF@gmail.com>
	<9029AF2D-E33D-4BAB-9973-DDD36E0482F4@gmail.com>
	<09F86485-FDFD-41A0-B4D8-EE38B883F57A@gmail.com>
	<CABL7CQjQ8XW0adJRZxBAwq7DK=83U_PJsQ0PNrZNRP2UiAZTzw@mail.gmail.com>
	<CABL7CQjWsHjNLuQ=43gx=ozJ+jtyhOCkk05c3GHOmhR5YbwiSA@mail.gmail.com>
	<664B81D9-DFD0-4B3A-A097-18968C4AE723@gmail.com>
Message-ID: <CABL7CQhK9nvH-BoqQKvrv0wqDHwK5DtE6cF5BVKrRA1ykcLhhg@mail.gmail.com>

On Tue, Aug 13, 2013 at 9:49 PM, Nathan Woods <charlesnwoods at gmail.com>wrote:

> Right, that's what I thought, too. The thing is that dbl- and tplquad
> DON'T do that. If you carefully at the calling sequence for tplquad,
> -----------
>
>
scipy.integrate.tplquad(*func*, *a*, *b*, *gfun*, *hfun*, *qfun*, *rfun*, *
> args=()*, *epsabs=1.49e-08*, *epsrel=1.49e-08*)[source]<http://github.com/scipy/scipy/blob/v0.12.0/scipy/integrate/quadpack.py#L434>
> ?<http://docs.scipy.org/doc/scipy/reference/generated/scipy.integrate.tplquad.html#scipy.integrate.tplquad>
>
> Return the triple integral of func(z, y, x) from x=a..b,
> y=gfun(x)..hfun(x), and z=qfun(x,y)..rfun(x,y)
> ------------
>
> The only way that the underlying quad routine can accept qfun(x,y) and
> rfun(x,y) as limits is if they are evaluated to be constants. That is,
> integration over z must be the innermost loop of integration, with
> fund(z,y,z), qfun(x,y), and rfun(x,y) receiving (x,y) passed in as
> arguments from the outer loops.
>
> I agree that the changes I just put in are kind of ridiculous, but (as far
> as I can tell) they exactly duplicate what is done in dbl- and tplquad.
>
>
> If we really want to put in some kind of integration order, then that's
> also not too hard, though a bit more than just reversing the lists. It's
> just something that I don't see a real, compelling reason to do.
>

Agreed, no very compelling reason. What's required would be not that much
more, basically ``lambda x, y, z: func(z, y, x)``, plus *args. I have
written little function wrappers like that before for use with
dblquad/tplquad.

Maybe better to leave it out and merge as it was.

Ralf

P.S. would you mind bottom posting
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130813/942ef056/attachment.html>

From evgeny.burovskiy at gmail.com  Wed Aug 14 07:54:12 2013
From: evgeny.burovskiy at gmail.com (Evgeni Burovski)
Date: Wed, 14 Aug 2013 12:54:12 +0100
Subject: [SciPy-Dev] Discussion on a new interface for multidimensional
	quadrature
In-Reply-To: <CABL7CQhK9nvH-BoqQKvrv0wqDHwK5DtE6cF5BVKrRA1ykcLhhg@mail.gmail.com>
References: <8A6B959D-DB30-400E-ACA3-3933912D4ED0@gmail.com>
	<CABL7CQhSxSpuR64AfMZYyeCywWnBsX_YO1HCTq9vGFQFjivyQw@mail.gmail.com>
	<CAMMTP+BST9i-hpdm+D_c5tNna1zXVJZr3_Be=chU0rCiiMqrUQ@mail.gmail.com>
	<020F0119-5ED4-48A2-B799-3F317859C3CF@gmail.com>
	<CAMRo0iuJmxKyvWvxPgA7=7DAdDceC3KbsrDVJx+ocaUMKonwUA@mail.gmail.com>
	<CABL7CQjsO_7i4BOFnfFrx9kT20kzCBcOMCatqyx1=9JDA1ug6Q@mail.gmail.com>
	<56B370B5-C158-4B43-8A00-0905C0925DFF@gmail.com>
	<9029AF2D-E33D-4BAB-9973-DDD36E0482F4@gmail.com>
	<09F86485-FDFD-41A0-B4D8-EE38B883F57A@gmail.com>
	<CABL7CQjQ8XW0adJRZxBAwq7DK=83U_PJsQ0PNrZNRP2UiAZTzw@mail.gmail.com>
	<CABL7CQjWsHjNLuQ=43gx=ozJ+jtyhOCkk05c3GHOmhR5YbwiSA@mail.gmail.com>
	<664B81D9-DFD0-4B3A-A097-18968C4AE723@gmail.com>
	<CABL7CQhK9nvH-BoqQKvrv0wqDHwK5DtE6cF5BVKrRA1ykcLhhg@mail.gmail.com>
Message-ID: <CAMRo0ivaZo05=7SWZzhrXKHbWyPv_ME0HM7AhwtR5Wb6Ue4-kQ@mail.gmail.com>

On Aug 13, 2013 9:08 PM, "Ralf Gommers" <ralf.gommers at gmail.com> wrote:
>
>
>
>
> On Tue, Aug 13, 2013 at 9:49 PM, Nathan Woods <charlesnwoods at gmail.com>
wrote:
>>
>> Right, that's what I thought, too. The thing is that dbl- and tplquad
DON'T do that. If you carefully at the calling sequence for tplquad,
>> -----------
>>
>>
>> scipy.integrate.tplquad(func, a, b, gfun, hfun, qfun, rfun, args=(),
epsabs=1.49e-08, epsrel=1.49e-08)[source]?
>>
>> Return the triple integral of func(z, y, x) from x=a..b,
y=gfun(x)..hfun(x), and z=qfun(x,y)..rfun(x,y)
>> ------------
>>
>> The only way that the underlying quad routine can accept qfun(x,y) and
rfun(x,y) as limits is if they are evaluated to be constants. That is,
integration over z must be the innermost loop of integration, with
fund(z,y,z), qfun(x,y), and rfun(x,y) receiving (x,y) passed in as
arguments from the outer loops.
>>
>> I agree that the changes I just put in are kind of ridiculous, but (as
far as I can tell) they exactly duplicate what is done in dbl- and tplquad.
>>
>>
>> If we really want to put in some kind of integration order, then that's
also not too hard, though a bit more than just reversing the lists. It's
just something that I don't see a real, compelling reason to do.
>
>
> Agreed, no very compelling reason. What's required would be not that much
more, basically ``lambda x, y, z: func(z, y, x)``, plus *args. I have
written little function wrappers like that before for use with
dblquad/tplquad.
>
> Maybe better to leave it out and merge as it was.
>
> Ralf
>

Well, my first thought was to allow a user to change, say,
tplquad(...whatever...)
to
nquad(...whatever..., reversed=True),
and that would just work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130814/4a237504/attachment.html>

From joris.vankerschaver at gmail.com  Wed Aug 14 07:57:49 2013
From: joris.vankerschaver at gmail.com (Joris Vankerschaver)
Date: Wed, 14 Aug 2013 12:57:49 +0100
Subject: [SciPy-Dev] Multivariate normal distribution in scipy.stats
In-Reply-To: <mailman.3.1375808401.25782.scipy-dev@scipy.org>
References: <mailman.3.1375808401.25782.scipy-dev@scipy.org>
Message-ID: <5C09566E-58B9-4F1C-B2DB-ACEEBDCEC3DF@gmail.com>

Hi all, 

I've made a PR for this; see 

 https://github.com/scipy/scipy/pull/2726

I used the design of stats.rv_continuous as my inspiration, so that the calling conventions agree with the 1D case. It should also be relatively straightforward to extend this setup with other methods or incorporate other multivariate random variables.

This is my first contribution to scipy! This was fun, but please let me know what needs to be improved.

With best wishes,
Joris


>>>> +1 to add it without a framework. Can be either a new module or in the
>>> scipy.stats namespace - there aren't that many multivariate distributions
>>> that it would necessarily warrant a new submodule.
>>> 
>>> I only meant implementation-wise. I think we should have a new
>>> scipy/stats/multivariate.py file and import its public names into the
>>> scipy.stats namespace. distributions.py is ... crowded and is
>> (rightfully,
>>> IMO) dedicated to the rv_continuous/rv_discrete framework.
>>> 
>> 
>> Ah OK. I fully agree then (except name it _multivariate.py).



From juanlu001 at gmail.com  Wed Aug 14 14:23:52 2013
From: juanlu001 at gmail.com (Juan Luis Cano)
Date: Wed, 14 Aug 2013 20:23:52 +0200
Subject: [SciPy-Dev] Confused about scipy.interpolate
Message-ID: <520BCB38.8090304@gmail.com>

Hello all, I was doing some experiments for the first time with 
scipy.interpolate today with the purpose of writing a brief 
article/tutorial on the matter and, as a user, I got a bit confused with 
the current state of the package and the "best practices". Let me explain.

The most straight-forward way I found to make a polynomial interpolation 
was the funcion interp1d. It worked well, and I could even specify a 
higher polynomial order so I could replicate and explain the Runge 
phenomenon. Except for the fact that it refuses to work outside of the 
boundaries. I had imagined that interp1d would give me some sort of 
polynomial representation that could be naturally extended outside of 
the domain specified by the interpolation points. Moreover, it seems to 
use some "older" functions (see below).

So I read "a more recent wrapper of the FITPACK routines", and I tried 
UnivariateSpline. Which naturally works inside of the domain, but cannot 
have a degree higher than 5, probably because it's geared to create 
splines (as the name points out). So still not valid (I wanted a 10th 
degree polynomial to show the oscillations).

splmake and company are advertised as an "older" wrapping, so I felt 
like not using them (for the sake of using the newer things). For 
example, splmake was gone from docs 
(http://mail.scipy.org/pipermail/scipy-user/2010-March/024489.html) and 
besides it has an issue pending, with the word "confusing" in the title 
(https://github.com/scipy/scipy/issues/1408).

And finally I found barycentric_interpolate and krogh_interpolate, which 
gave me the same results but it seems one is useful if I'm adding new 
points and the other is useful if I want the derivatives. But now I 
wonder which one is better.

And this leads me to a question - what if I just want a simple, 
arbitrary degree polynomial interpolation?

I thought that maybe something could be done similar to what was 
introduced in 0.11.0 with minimize and minimize_scalar, which I think it 
was a great improvement because the user usually doesn't have to worry 
about the method used, unless they want to specify a certain one (even 
if the naming was IMHO a bit unfortunate regarding the latter, but 
that's another story). So is there a way an `interpolate` function can 
be created, with a string argument specifying the method (with default 
"barycentric", for example)?

Sorry for the long email, but I tried to explain in detail what was my 
"path" as a user trying to figure out what to do. Hope it is useful for 
the devs.

Regards

Juan Luis Cano


From charlesnwoods at gmail.com  Wed Aug 14 14:53:59 2013
From: charlesnwoods at gmail.com (Nathan Woods)
Date: Wed, 14 Aug 2013 12:53:59 -0600
Subject: [SciPy-Dev] Discussion on a new interface for multidimensional
	quadrature
In-Reply-To: <CAMRo0ivaZo05=7SWZzhrXKHbWyPv_ME0HM7AhwtR5Wb6Ue4-kQ@mail.gmail.com>
References: <8A6B959D-DB30-400E-ACA3-3933912D4ED0@gmail.com>
	<CABL7CQhSxSpuR64AfMZYyeCywWnBsX_YO1HCTq9vGFQFjivyQw@mail.gmail.com>
	<CAMMTP+BST9i-hpdm+D_c5tNna1zXVJZr3_Be=chU0rCiiMqrUQ@mail.gmail.com>
	<020F0119-5ED4-48A2-B799-3F317859C3CF@gmail.com>
	<CAMRo0iuJmxKyvWvxPgA7=7DAdDceC3KbsrDVJx+ocaUMKonwUA@mail.gmail.com>
	<CABL7CQjsO_7i4BOFnfFrx9kT20kzCBcOMCatqyx1=9JDA1ug6Q@mail.gmail.com>
	<56B370B5-C158-4B43-8A00-0905C0925DFF@gmail.com>
	<9029AF2D-E33D-4BAB-9973-DDD36E0482F4@gmail.com>
	<09F86485-FDFD-41A0-B4D8-EE38B883F57A@gmail.com>
	<CABL7CQjQ8XW0adJRZxBAwq7DK=83U_PJsQ0PNrZNRP2UiAZTzw@mail.gmail.com>
	<CABL7CQjWsHjNLuQ=43gx=ozJ+jtyhOCkk05c3GHOmhR5YbwiSA@mail.gmail.com>
	<664B81D9-DFD0-4B3A-A097-18968C4AE723@gmail.com>
	<CABL7CQhK9nvH-BoqQKvrv0wqDHwK5DtE6cF5BVKrRA1ykcLhhg@mail.gmail.com>
	<CAMRo0ivaZo05=7SWZzhrXKHbWyPv_ME0HM7AhwtR5Wb6Ue4-kQ@mail.gmail.com>
Message-ID: <B6705388-0F3A-456D-8D82-1984BB659B67@gmail.com>

On Aug 14, 2013, at 5:54 AM, Evgeni Burovski <evgeny.burovskiy at gmail.com> wrote:

> 
> On Aug 13, 2013 9:08 PM, "Ralf Gommers" <ralf.gommers at gmail.com> wrote:
> >
> >
> >
> >
> > On Tue, Aug 13, 2013 at 9:49 PM, Nathan Woods <charlesnwoods at gmail.com> wrote:
> >>
> >> Right, that's what I thought, too. The thing is that dbl- and tplquad DON'T do that. If you carefully at the calling sequence for tplquad, 
> >> -----------
> >>  
> >>
> >> scipy.integrate.tplquad(func, a, b, gfun, hfun, qfun, rfun, args=(), epsabs=1.49e-08, epsrel=1.49e-08)[source]?
> >>
> >> Return the triple integral of func(z, y, x) from x=a..b, y=gfun(x)..hfun(x), and z=qfun(x,y)..rfun(x,y)
> >> ------------
> >>
> >> The only way that the underlying quad routine can accept qfun(x,y) and rfun(x,y) as limits is if they are evaluated to be constants. That is, integration over z must be the innermost loop of integration, with fund(z,y,z), qfun(x,y), and rfun(x,y) receiving (x,y) passed in as arguments from the outer loops. 
> >>
> >> I agree that the changes I just put in are kind of ridiculous, but (as far as I can tell) they exactly duplicate what is done in dbl- and tplquad.
> >>
> >>
> >> If we really want to put in some kind of integration order, then that's also not too hard, though a bit more than just reversing the lists. It's just something that I don't see a real, compelling reason to do. 
> >
> >
> > Agreed, no very compelling reason. What's required would be not that much more, basically ``lambda x, y, z: func(z, y, x)``, plus *args. I have written little function wrappers like that before for use with dblquad/tplquad.
> >
> > Maybe better to leave it out and merge as it was.
> >
> > Ralf
> >
> 
> Well, my first thought was to allow a user to change, say,
> tplquad(...whatever...)
> to
> nquad(...whatever..., reversed=True),
> and that would just work.
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev

Unfortunately, the interfaces are different enough that a simple flag wouldn't be enough. nquad wraps all of the range arguments into nested lists, where tplquad keeps them all out in the argument list. You would have to write either some kind of wrapper, or else allow for different calling sequences with some creative use of *args and **kwargs. Not to mention, keeping all of the ordering for everything straight would be a nightmare. Take a look at the function "nquad", if you want to see what I mean. https://github.com/thezealite/scipy/blob/master/scipy/integrate/quadpack.py

Mostly, I think that's a bad idea, since it pretty much explodes the number of ways things can go wrong. I think it's much better to keep things simple, and just have users learn the new interface if they want the new functionality (more dimensions, more option control).

N
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130814/a7b74cee/attachment.html>

From npkuin at gmail.com  Wed Aug 14 15:04:32 2013
From: npkuin at gmail.com (Paul Kuin)
Date: Wed, 14 Aug 2013 20:04:32 +0100
Subject: [SciPy-Dev] Confused about scipy.interpolate
In-Reply-To: <520BCB38.8090304@gmail.com>
References: <520BCB38.8090304@gmail.com>
Message-ID: <CANoQ6N3qDCbO3DNi_rnJy1jN8QDYVDUeLORdqy-gJgZgUb3_rQ@mail.gmail.com>

Hi Juan, all,

Let me add some thoughts to that. I have been using interp1d, and some
other methods, but the main problem with extending a polynomial outide its
domain is that it tends to swerve off into nowhere land.  I found that a
much better method for extending the domain is rational functions. So I
would in principle be against making an extension of the solution of
polynomials outside their domain easy. Rational functions are just better
there.

I must admit that I just code up my own interpolations when I need
something else. Sorry.

Cheers,

   Paul


On Wed, Aug 14, 2013 at 7:23 PM, Juan Luis Cano <juanlu001 at gmail.com> wrote:

> Hello all, I was doing some experiments for the first time with
> scipy.interpolate today with the purpose of writing a brief
> article/tutorial on the matter and, as a user, I got a bit confused with
> the current state of the package and the "best practices". Let me explain.
>
> The most straight-forward way I found to make a polynomial interpolation
> was the funcion interp1d. It worked well, and I could even specify a
> higher polynomial order so I could replicate and explain the Runge
> phenomenon. Except for the fact that it refuses to work outside of the
> boundaries. I had imagined that interp1d would give me some sort of
> polynomial representation that could be naturally extended outside of
> the domain specified by the interpolation points. Moreover, it seems to
> use some "older" functions (see below).
>
> So I read "a more recent wrapper of the FITPACK routines", and I tried
> UnivariateSpline. Which naturally works inside of the domain, but cannot
> have a degree higher than 5, probably because it's geared to create
> splines (as the name points out). So still not valid (I wanted a 10th
> degree polynomial to show the oscillations).
>
> splmake and company are advertised as an "older" wrapping, so I felt
> like not using them (for the sake of using the newer things). For
> example, splmake was gone from docs
> (http://mail.scipy.org/pipermail/scipy-user/2010-March/024489.html) and
> besides it has an issue pending, with the word "confusing" in the title
> (https://github.com/scipy/scipy/issues/1408).
>
> And finally I found barycentric_interpolate and krogh_interpolate, which
> gave me the same results but it seems one is useful if I'm adding new
> points and the other is useful if I want the derivatives. But now I
> wonder which one is better.
>
> And this leads me to a question - what if I just want a simple,
> arbitrary degree polynomial interpolation?
>
> I thought that maybe something could be done similar to what was
> introduced in 0.11.0 with minimize and minimize_scalar, which I think it
> was a great improvement because the user usually doesn't have to worry
> about the method used, unless they want to specify a certain one (even
> if the naming was IMHO a bit unfortunate regarding the latter, but
> that's another story). So is there a way an `interpolate` function can
> be created, with a string argument specifying the method (with default
> "barycentric", for example)?
>
> Sorry for the long email, but I tried to explain in detail what was my
> "path" as a user trying to figure out what to do. Hope it is useful for
> the devs.
>
> Regards
>
> Juan Luis Cano
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>



-- 

* * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * *
Dr. N.P.M. Kuin      (n.kuin at ucl.ac.uk)
phone +44-(0)1483 (prefix) -204927 (work) -276110 (home)
mobile +44(0)7806985366  skype ID: npkuin
Mullard Space Science Laboratory  ? University College London  ?
Holmbury St Mary ? Dorking ? Surrey RH5 6NT?  U.K.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130814/bfc332dd/attachment.html>

From wbuckner at beatsmusic.com  Wed Aug 14 15:52:33 2013
From: wbuckner at beatsmusic.com (Will Buckner)
Date: Wed, 14 Aug 2013 12:52:33 -0700
Subject: [SciPy-Dev] Many Problems Building w/ MKL 11, ifort, icc;
 scipy.test() Fails w/ Undefined Symbols
Message-ID: <CAL_nGS5gb-U2v3N6QwMHWZ70NNzuk_OS1ciFE0r8fLRK+NeHvA@mail.gmail.com>

I've tried this about 6 different ways now, and all successful builds
result in the same error during scipy.test() (note that NumPy builds fine
with same site.cfg):

======================================================================
ERROR: Failure: ImportError
(/opt/intel/composer_xe_2013.5.192/mkl/lib/intel64/libmkl_intel_thread.so:
undefined symbol: mkl_blas_dgemm_blk_info_bdz)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/nose/loader.py", line 413,
in loadTestsFromName
    addr.filename, addr.module)
  File "/usr/local/lib/python2.7/dist-packages/nose/importer.py", line 47,
in importFromPath
    return self.importFromDir(dir_path, fqname)
  File "/usr/local/lib/python2.7/dist-packages/nose/importer.py", line 94,
in importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File "/usr/local/lib/python2.7/dist-packages/scipy/stats/__init__.py",
line 320, in <module>
    from .stats import *
  File "/usr/local/lib/python2.7/dist-packages/scipy/stats/stats.py", line
242, in <module>
    import scipy.linalg as linalg
  File "/usr/local/lib/python2.7/dist-packages/scipy/linalg/__init__.py",
line 147, in <module>
    from .misc import *
  File "/usr/local/lib/python2.7/dist-packages/scipy/linalg/misc.py", line
5, in <module>
    from . import blas
  File "/usr/local/lib/python2.7/dist-packages/scipy/linalg/blas.py", line
113, in <module>
    from scipy.linalg import _fblas
ImportError:
/opt/intel/composer_xe_2013.5.192/mkl/lib/intel64/libmkl_intel_thread.so:
undefined symbol: mkl_blas_dgemm_blk_info_bdz


Here's some info on my environment:

Intel Composer XE 2013.5.192, ifort+icc
icc flags: -fPIC -DMKL_ILP64 -m64 -fp-model', 'strict',
'-fomit-frame-pointer', '-openmp', '-xhost', '-parallel'
ifort flags: -fPIC -i8 -xhost -openmp -fp-model strict
OS: Ubuntu 12.04
24 Cores Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz
Intel LibMKL 11.0.5

site.cfg:

[mkl]
library_dirs = /opt/intel/mkl/lib/intel64:/opt/intel/lib/intel64
include_dirs = /opt/intel/mkl/include:/opt/intel/include
lapack_libs = mkl_lapack95_lp64
mkl_libs = mkl_def, mkl_intel_lp64, mkl_intel_thread, mkl_core, mkl_mc

[fftw]
library_dirs = /opt/intel/mkl/lib/intel64
include_dirs = /opt/intel/mkl/include
libraries = fftw3

[amd]
amd_libs = amd
library_dirs = /usr/lib
include_dirs = /usr/include/suitesparse/

[umfpack]
umfpack_libs = umfpack
library_dirs = /usr/lib
include_dirs = /usr/include/suitesparse/

Built with:
python setup.py clean
python setup.py  -v config --compiler=intelem --fcompiler=intelem
build_clib --compiler=intelem --fcompiler=intelem build_ext
 --compiler=intelem --fcompiler=intelem install

  FOUND:
    libraries = ['mkl_def', 'mkl_intel_lp64', 'mkl_intel_thread',
'mkl_core', 'mkl_mc', 'pthread']
    library_dirs = ['/opt/intel/mkl/lib/intel64']
    define_macros = [('SCIPY_MKL_H', None)]
    include_dirs = ['/opt/intel/mkl/include', '/opt/intel/include']

  FOUND:
    libraries = ['mkl_def', 'mkl_intel_lp64', 'mkl_intel_thread',
'mkl_core', 'mkl_mc', 'pthread']
    library_dirs = ['/opt/intel/mkl/lib/intel64']
    define_macros = [('SCIPY_MKL_H', None)]
    include_dirs = ['/opt/intel/mkl/include', '/opt/intel/include']

  FOUND:
    libraries = ['mkl_lapack95_lp64', 'mkl_def', 'mkl_intel_lp64',
'mkl_intel_thread', 'mkl_core', 'mkl_mc', 'pthread']
    library_dirs = ['/opt/intel/mkl/lib/intel64']
    define_macros = [('SCIPY_MKL_H', None)]
    include_dirs = ['/opt/intel/mkl/include', '/opt/intel/include']

( library_dirs = /usr/local/lib:/usr/lib:/usr/lib/x86_64-linux-gnu )
  FOUND:
    libraries = ['mkl_lapack95_lp64', 'mkl_def', 'mkl_intel_lp64',
'mkl_intel_thread', 'mkl_core', 'mkl_mc', 'pthread']
    library_dirs = ['/opt/intel/mkl/lib/intel64']
    define_macros = [('SCIPY_MKL_H', None)]
    include_dirs = ['/opt/intel/mkl/include', '/opt/intel/include']


**The problem is here:**

======================================================================
ERROR: Failure: ImportError
(/opt/intel/composer_xe_2013.5.192/mkl/lib/intel64/libmkl_intel_thread.so:
undefined symbol: mkl_blas_dgemm_blk_info_bdz)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/nose/loader.py", line 413,
in loadTestsFromName
    addr.filename, addr.module)
  File "/usr/local/lib/python2.7/dist-packages/nose/importer.py", line 47,
in importFromPath
    return self.importFromDir(dir_path, fqname)
  File "/usr/local/lib/python2.7/dist-packages/nose/importer.py", line 94,
in importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File "/usr/local/lib/python2.7/dist-packages/scipy/stats/__init__.py",
line 320, in <module>
    from .stats import *
  File "/usr/local/lib/python2.7/dist-packages/scipy/stats/stats.py", line
242, in <module>
    import scipy.linalg as linalg
  File "/usr/local/lib/python2.7/dist-packages/scipy/linalg/__init__.py",
line 147, in <module>
    from .misc import *
  File "/usr/local/lib/python2.7/dist-packages/scipy/linalg/misc.py", line
5, in <module>
    from . import blas
  File "/usr/local/lib/python2.7/dist-packages/scipy/linalg/blas.py", line
113, in <module>
    from scipy.linalg import _fblas
ImportError:
/opt/intel/composer_xe_2013.5.192/mkl/lib/intel64/libmkl_intel_thread.so:
undefined symbol: mkl_blas_dgemm_blk_info_bdz


Now, where is mkl_blas_dgemm_blk_info_bdz defined?

daisy at speedballcompute01:/opt/intel/mkl/lib/intel64$ nm libmkl_core.so |
grep mkl_blas_dgemm_blk_info_bdz
00000000000c59f0 T mkl_blas_dgemm_blk_info_bdz
daisy at speedballcompute01:/opt/intel/mkl/lib/intel64$

Right there ^.

I included mkl_core in site.cfg and it seems to be linking it, so I'm not
sure why this symbol is still undefined. Note that it *is* undefined in
libmkl_intel_thread.so:

daisy at speedballcompute01:/opt/intel/mkl/lib/intel64$ nm
libmkl_intel_thread.so | grep mkl_blas_dgemm_blk_info_bdz
                 U mkl_blas_dgemm_blk_info_bdz
daisy at speedballcompute01:/opt/intel/mkl/lib/intel64$


I also tried the instructions provided by intel at
http://software.intel.com/en-us/articles/numpyscipy-with-intel-mkl, using
just mkl_rt. This had the same result, and seems incorrect, as it's not
providing any lapack libraries (I'm assuming it would just fall back to "no
lapack" and it seems to). This is highly confusing, as all of the MKL
numpy/scipy instructions seem to be for older MKLs, before mkl_rt.

Could anyone help me debug this? I'm hopelessly frustrated with it at this
point and willing to do whatever to help you guys debug.

Thanks! What additional info is needed?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130814/47820391/attachment.html>

From ralf.gommers at gmail.com  Wed Aug 14 17:19:12 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Wed, 14 Aug 2013 23:19:12 +0200
Subject: [SciPy-Dev] Many Problems Building w/ MKL 11, ifort, icc;
 scipy.test() Fails w/ Undefined Symbols
In-Reply-To: <CAL_nGS5gb-U2v3N6QwMHWZ70NNzuk_OS1ciFE0r8fLRK+NeHvA@mail.gmail.com>
References: <CAL_nGS5gb-U2v3N6QwMHWZ70NNzuk_OS1ciFE0r8fLRK+NeHvA@mail.gmail.com>
Message-ID: <CABL7CQgihY5_yGmsxzO_UqWa78WE-z-R-7_MEONsvmt=XZ9_RA@mail.gmail.com>

On Wed, Aug 14, 2013 at 9:52 PM, Will Buckner <wbuckner at beatsmusic.com>wrote:

> I've tried this about 6 different ways now, and all successful builds
> result in the same error during scipy.test() (note that NumPy builds fine
> with same site.cfg):
>
> ======================================================================
> ERROR: Failure: ImportError
> (/opt/intel/composer_xe_2013.5.192/mkl/lib/intel64/libmkl_intel_thread.so:
> undefined symbol: mkl_blas_dgemm_blk_info_bdz)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/usr/local/lib/python2.7/dist-packages/nose/loader.py", line 413,
> in loadTestsFromName
>     addr.filename, addr.module)
>   File "/usr/local/lib/python2.7/dist-packages/nose/importer.py", line 47,
> in importFromPath
>     return self.importFromDir(dir_path, fqname)
>   File "/usr/local/lib/python2.7/dist-packages/nose/importer.py", line 94,
> in importFromDir
>     mod = load_module(part_fqname, fh, filename, desc)
>   File "/usr/local/lib/python2.7/dist-packages/scipy/stats/__init__.py",
> line 320, in <module>
>     from .stats import *
>   File "/usr/local/lib/python2.7/dist-packages/scipy/stats/stats.py", line
> 242, in <module>
>     import scipy.linalg as linalg
>   File "/usr/local/lib/python2.7/dist-packages/scipy/linalg/__init__.py",
> line 147, in <module>
>     from .misc import *
>   File "/usr/local/lib/python2.7/dist-packages/scipy/linalg/misc.py", line
> 5, in <module>
>     from . import blas
>   File "/usr/local/lib/python2.7/dist-packages/scipy/linalg/blas.py", line
> 113, in <module>
>     from scipy.linalg import _fblas
> ImportError:
> /opt/intel/composer_xe_2013.5.192/mkl/lib/intel64/libmkl_intel_thread.so:
> undefined symbol: mkl_blas_dgemm_blk_info_bdz
>
>
> Here's some info on my environment:
>
> Intel Composer XE 2013.5.192, ifort+icc
> icc flags: -fPIC -DMKL_ILP64 -m64 -fp-model', 'strict',
> '-fomit-frame-pointer', '-openmp', '-xhost', '-parallel'
> ifort flags: -fPIC -i8 -xhost -openmp -fp-model strict
> OS: Ubuntu 12.04
> 24 Cores Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz
> Intel LibMKL 11.0.5
>
> site.cfg:
>
> [mkl]
> library_dirs = /opt/intel/mkl/lib/intel64:/opt/intel/lib/intel64
> include_dirs = /opt/intel/mkl/include:/opt/intel/include
> lapack_libs = mkl_lapack95_lp64
> mkl_libs = mkl_def, mkl_intel_lp64, mkl_intel_thread, mkl_core, mkl_mc
>
> [fftw]
> library_dirs = /opt/intel/mkl/lib/intel64
> include_dirs = /opt/intel/mkl/include
> libraries = fftw3
>
> [amd]
> amd_libs = amd
> library_dirs = /usr/lib
> include_dirs = /usr/include/suitesparse/
>
> [umfpack]
> umfpack_libs = umfpack
> library_dirs = /usr/lib
> include_dirs = /usr/include/suitesparse/
>
> Built with:
> python setup.py clean
> python setup.py  -v config --compiler=intelem --fcompiler=intelem
> build_clib --compiler=intelem --fcompiler=intelem build_ext
>  --compiler=intelem --fcompiler=intelem install
>
>   FOUND:
>     libraries = ['mkl_def', 'mkl_intel_lp64', 'mkl_intel_thread',
> 'mkl_core', 'mkl_mc', 'pthread']
>     library_dirs = ['/opt/intel/mkl/lib/intel64']
>     define_macros = [('SCIPY_MKL_H', None)]
>     include_dirs = ['/opt/intel/mkl/include', '/opt/intel/include']
>
>   FOUND:
>     libraries = ['mkl_def', 'mkl_intel_lp64', 'mkl_intel_thread',
> 'mkl_core', 'mkl_mc', 'pthread']
>     library_dirs = ['/opt/intel/mkl/lib/intel64']
>     define_macros = [('SCIPY_MKL_H', None)]
>     include_dirs = ['/opt/intel/mkl/include', '/opt/intel/include']
>
>   FOUND:
>     libraries = ['mkl_lapack95_lp64', 'mkl_def', 'mkl_intel_lp64',
> 'mkl_intel_thread', 'mkl_core', 'mkl_mc', 'pthread']
>     library_dirs = ['/opt/intel/mkl/lib/intel64']
>     define_macros = [('SCIPY_MKL_H', None)]
>     include_dirs = ['/opt/intel/mkl/include', '/opt/intel/include']
>
> ( library_dirs = /usr/local/lib:/usr/lib:/usr/lib/x86_64-linux-gnu )
>   FOUND:
>     libraries = ['mkl_lapack95_lp64', 'mkl_def', 'mkl_intel_lp64',
> 'mkl_intel_thread', 'mkl_core', 'mkl_mc', 'pthread']
>     library_dirs = ['/opt/intel/mkl/lib/intel64']
>     define_macros = [('SCIPY_MKL_H', None)]
>     include_dirs = ['/opt/intel/mkl/include', '/opt/intel/include']
>
>
> **The problem is here:**
>
> ======================================================================
> ERROR: Failure: ImportError
> (/opt/intel/composer_xe_2013.5.192/mkl/lib/intel64/libmkl_intel_thread.so:
> undefined symbol: mkl_blas_dgemm_blk_info_bdz)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/usr/local/lib/python2.7/dist-packages/nose/loader.py", line 413,
> in loadTestsFromName
>     addr.filename, addr.module)
>   File "/usr/local/lib/python2.7/dist-packages/nose/importer.py", line 47,
> in importFromPath
>     return self.importFromDir(dir_path, fqname)
>   File "/usr/local/lib/python2.7/dist-packages/nose/importer.py", line 94,
> in importFromDir
>     mod = load_module(part_fqname, fh, filename, desc)
>   File "/usr/local/lib/python2.7/dist-packages/scipy/stats/__init__.py",
> line 320, in <module>
>     from .stats import *
>   File "/usr/local/lib/python2.7/dist-packages/scipy/stats/stats.py", line
> 242, in <module>
>     import scipy.linalg as linalg
>   File "/usr/local/lib/python2.7/dist-packages/scipy/linalg/__init__.py",
> line 147, in <module>
>     from .misc import *
>   File "/usr/local/lib/python2.7/dist-packages/scipy/linalg/misc.py", line
> 5, in <module>
>     from . import blas
>   File "/usr/local/lib/python2.7/dist-packages/scipy/linalg/blas.py", line
> 113, in <module>
>     from scipy.linalg import _fblas
> ImportError:
> /opt/intel/composer_xe_2013.5.192/mkl/lib/intel64/libmkl_intel_thread.so:
> undefined symbol: mkl_blas_dgemm_blk_info_bdz
>
>
> Now, where is mkl_blas_dgemm_blk_info_bdz defined?
>
> daisy at speedballcompute01:/opt/intel/mkl/lib/intel64$ nm libmkl_core.so |
> grep mkl_blas_dgemm_blk_info_bdz
> 00000000000c59f0 T mkl_blas_dgemm_blk_info_bdz
> daisy at speedballcompute01:/opt/intel/mkl/lib/intel64$
>
> Right there ^.
>
> I included mkl_core in site.cfg and it seems to be linking it, so I'm not
> sure why this symbol is still undefined. Note that it *is* undefined in
> libmkl_intel_thread.so:
>
> daisy at speedballcompute01:/opt/intel/mkl/lib/intel64$ nm
> libmkl_intel_thread.so | grep mkl_blas_dgemm_blk_info_bdz
>                  U mkl_blas_dgemm_blk_info_bdz
> daisy at speedballcompute01:/opt/intel/mkl/lib/intel64$
>
>
> I also tried the instructions provided by intel at
> http://software.intel.com/en-us/articles/numpyscipy-with-intel-mkl, using
> just mkl_rt. This had the same result, and seems incorrect, as it's not
> providing any lapack libraries (I'm assuming it would just fall back to "no
> lapack" and it seems to). This is highly confusing, as all of the MKL
> numpy/scipy instructions seem to be for older MKLs, before mkl_rt.
>

These are fairly recent and mention mkl_rt:
http://scipy.org/scipylib/building/linux.html#any-distribution-with-intel-c-compiler-and-mkl.
Did you find those?

Ralf



>
> Could anyone help me debug this? I'm hopelessly frustrated with it at this
> point and willing to do whatever to help you guys debug.
>
> Thanks! What additional info is needed?
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130814/c58278b3/attachment.html>

From evgeny.burovskiy at gmail.com  Thu Aug 15 01:16:44 2013
From: evgeny.burovskiy at gmail.com (Evgeni Burovski)
Date: Thu, 15 Aug 2013 06:16:44 +0100
Subject: [SciPy-Dev] Discussion on a new interface for multidimensional
	quadrature
In-Reply-To: <B6705388-0F3A-456D-8D82-1984BB659B67@gmail.com>
References: <8A6B959D-DB30-400E-ACA3-3933912D4ED0@gmail.com>
	<CABL7CQhSxSpuR64AfMZYyeCywWnBsX_YO1HCTq9vGFQFjivyQw@mail.gmail.com>
	<CAMMTP+BST9i-hpdm+D_c5tNna1zXVJZr3_Be=chU0rCiiMqrUQ@mail.gmail.com>
	<020F0119-5ED4-48A2-B799-3F317859C3CF@gmail.com>
	<CAMRo0iuJmxKyvWvxPgA7=7DAdDceC3KbsrDVJx+ocaUMKonwUA@mail.gmail.com>
	<CABL7CQjsO_7i4BOFnfFrx9kT20kzCBcOMCatqyx1=9JDA1ug6Q@mail.gmail.com>
	<56B370B5-C158-4B43-8A00-0905C0925DFF@gmail.com>
	<9029AF2D-E33D-4BAB-9973-DDD36E0482F4@gmail.com>
	<09F86485-FDFD-41A0-B4D8-EE38B883F57A@gmail.com>
	<CABL7CQjQ8XW0adJRZxBAwq7DK=83U_PJsQ0PNrZNRP2UiAZTzw@mail.gmail.com>
	<CABL7CQjWsHjNLuQ=43gx=ozJ+jtyhOCkk05c3GHOmhR5YbwiSA@mail.gmail.com>
	<664B81D9-DFD0-4B3A-A097-18968C4AE723@gmail.com>
	<CABL7CQhK9nvH-BoqQKvrv0wqDHwK5DtE6cF5BVKrRA1ykcLhhg@mail.gmail.com>
	<CAMRo0ivaZo05=7SWZzhrXKHbWyPv_ME0HM7AhwtR5Wb6Ue4-kQ@mail.gmail.com>
	<B6705388-0F3A-456D-8D82-1984BB659B67@gmail.com>
Message-ID: <CAMRo0itkqt6nggOZV4hv1UTK_rMjLMiy4ARB1jNOMe=Ce0aO5Q@mail.gmail.com>

On Aug 15, 2013 2:54 AM, "Nathan Woods" <charlesnwoods at gmail.com> wrote:
>
> On Aug 14, 2013, at 5:54 AM, Evgeni Burovski <evgeny.burovskiy at gmail.com>
wrote:
>
>>
>> On Aug 13, 2013 9:08 PM, "Ralf Gommers" <ralf.gommers at gmail.com> wrote:
>> >
>> >
>> >
>> >
>> > On Tue, Aug 13, 2013 at 9:49 PM, Nathan Woods <charlesnwoods at gmail.com>
wrote:
>> >>
>> >> Right, that's what I thought, too. The thing is that dbl- and tplquad
DON'T do that. If you carefully at the calling sequence for tplquad,
>> >> -----------
>> >>
>> >>
>> >> scipy.integrate.tplquad(func, a, b, gfun, hfun, qfun, rfun, args=(),
epsabs=1.49e-08, epsrel=1.49e-08)[source]?
>> >>
>> >> Return the triple integral of func(z, y, x) from x=a..b,
y=gfun(x)..hfun(x), and z=qfun(x,y)..rfun(x,y)
>> >> ------------
>> >>
>> >> The only way that the underlying quad routine can accept qfun(x,y)
and rfun(x,y) as limits is if they are evaluated to be constants. That is,
integration over z must be the innermost loop of integration, with
fund(z,y,z), qfun(x,y), and rfun(x,y) receiving (x,y) passed in as
arguments from the outer loops.
>> >>
>> >> I agree that the changes I just put in are kind of ridiculous, but
(as far as I can tell) they exactly duplicate what is done in dbl- and
tplquad.
>> >>
>> >>
>> >> If we really want to put in some kind of integration order, then
that's also not too hard, though a bit more than just reversing the lists.
It's just something that I don't see a real, compelling reason to do.
>> >
>> >
>> > Agreed, no very compelling reason. What's required would be not that
much more, basically ``lambda x, y, z: func(z, y, x)``, plus *args. I have
written little function wrappers like that before for use with
dblquad/tplquad.
>> >
>> > Maybe better to leave it out and merge as it was.
>> >
>> > Ralf
>> >
>>
>> Well, my first thought was to allow a user to change, say,
>> tplquad(...whatever...)
>> to
>> nquad(...whatever..., reversed=True),
>> and that would just work.
>>
>> _______________________________________________
>>
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
> Unfortunately, the interfaces are different enough that a simple flag
wouldn't be enough. nquad wraps all of the range arguments into nested
lists, where tplquad keeps them all out in the argument list. You would
have to write either some kind of wrapper, or else allow for different
calling sequences with some creative use of *args and **kwargs. Not to
mention, keeping all of the ordering for everything straight would be a
nightmare. Take a look at the function "nquad", if you want to see what I
mean.
https://github.com/thezealite/scipy/blob/master/scipy/integrate/quadpack.py
>
> Mostly, I think that's a bad idea, since it pretty much explodes the
number of ways things can go wrong. I think it's much better to keep things
simple, and just have users learn the new interface if they want the new
functionality (more dimensions, more option control).

Makes perfect sense --- my suggestion is useless.

It might be helpful to users then to have an entry in a tutorial, showing
how to do things both ways. For example, a function of two or three
arguments, integrated over some reasonably simple limits first by
dblquad/tplquad, and then by nquad.

Zhenya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130815/040347e0/attachment.html>

From clemens at familie-novak.net  Fri Aug 16 06:36:51 2013
From: clemens at familie-novak.net (Clemens Novak)
Date: Fri, 16 Aug 2013 12:36:51 +0200
Subject: [SciPy-Dev] fftpack.convolve.convolve
Message-ID: <68515d0d5b89edc18360cc0df135885c@scorpius.uberspace.de>

Hi,

I've been working on extending the fftpack tutorial page (you can see 
the current status here: 
https://github.com/ClemensFMN/scipy/blob/tut_fft/doc/source/tutorial/fftpack.rst 
) and I stumbled across the function fftpack.convolve.convolve .

Sorry the blunt question, but what does this function do? From the name 
I'd assume that it calculates the convolution of two sequences (as 
convolve in scipy.signal does) using the fft (since it is part of 
fftpack), but appearently it doesn't:

import numpy as np
import scipy.fftpack.convolve as conv
import scipy as sp
import scipy.signal as sig


x = np.array([1.0, 0.0, 0.0])
h = np.array([1.0, 2.0, 3.0])

y1 = conv.convolve(x, h)
[ 5. -1. -1.]

y2 = sig.convolve(x, h)
[ 1.  2.  3.  0.  0.]

y3 = sp.ifft(sp.fft(x) * sp.fft(h))
[ 1.+0.j  2.+0.j  3.+0.j]

Does the function extend its first and/or second argument to a periodic 
sequence and perform then the convolution (I tried some ideas but that 
didn'twork either)? It would be great if someone could please provide 
some insight...

Regards - Clemens


From ralf.gommers at gmail.com  Sat Aug 17 14:17:22 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sat, 17 Aug 2013 20:17:22 +0200
Subject: [SciPy-Dev] deprecating stats.oneway and stats.glm
Message-ID: <CABL7CQjxFq--Lmt=bksZU_HOpgPaOP6g4pGpEVZ+KE3Og7JZVQ@mail.gmail.com>

Hi all,

We're planning to deprecate oneway and glm for the 0.13.0 release:
https://github.com/scipy/scipy/pull/2733. `oneway` is broken and duplicate
with f_oneway. `glm` is a duplicate with ttest_ind, undocumented and
untested. Better alternatives exist in statsmodels as well.

If you see any problem with these deprecations, please speak up.

Regards,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130817/9e13186c/attachment.html>

From ralf.gommers at gmail.com  Sat Aug 17 14:21:19 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sat, 17 Aug 2013 20:21:19 +0200
Subject: [SciPy-Dev] 0.13.0 release schedule
In-Reply-To: <CABL7CQinRHJnJSgfX66_oxm++46kxzfeEwmnsLG7KT6eH8=bow@mail.gmail.com>
References: <CABL7CQinRHJnJSgfX66_oxm++46kxzfeEwmnsLG7KT6eH8=bow@mail.gmail.com>
Message-ID: <CABL7CQhFS4hnsNkypHv24GWw-SqExOsfimoEi79LJzWEZ9CObg@mail.gmail.com>

On Sun, Aug 4, 2013 at 4:13 PM, Ralf Gommers <ralf.gommers at gmail.com> wrote:

> Hi all,
>
> It's time to start thinking about the 0.13.0 release. I have just
> submitted an update to the release notes (
> https://github.com/scipy/scipy/pull/2685), it would be great if you could
> check that and suggest more things that should be mentioned.
>
> My proposal for the release schedule is:
> Aug 17 (just before EuroScipy): beta 1
> Aug 31: rc 1
> Sep 12: rc 2 (if needed)
> Sep 22: final release
>

Hi all, we're in pretty good shape for the first beta, but it won't happen
today. There's still one critical issue that should be fixed first (Windows
MinGW build broken, issue 2709). I've run out of time for today and will be
offline for the next two days, so 0.13.x will probably be branched on
Tuesday.

Cheers,
Ralf



>
> Does that work for everyone? If there are critical issues for this release
> that are not listed at
> https://github.com/scipy/scipy/issues?milestone=9&state=open please add
> them, or add a comment to the issue.
>
> Of course I'd like to see as many PRs as possible merged before branching
> 0.13.x, but these in particular should make it in:
>   - 2684: Arpack fix
>   - 2658: linalg.interpolate update
>   - 2588: allow kwargs in stats.distributions
>   - 2510: N-dimensional integration routine
> Help in merging PRs before the 17th will be much appreciated.
>
> Cheers,
> Ralf
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130817/8131e116/attachment.html>

From josef.pktd at gmail.com  Sun Aug 18 09:48:30 2013
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Sun, 18 Aug 2013 09:48:30 -0400
Subject: [SciPy-Dev] github labels for pull requests
Message-ID: <CAMMTP+CJT=LC0hhf=HqVk6ED=88ZumUBzW_48D66po+2=Dkk2A@mail.gmail.com>

I added the `stats` label to some pull requests

https://github.com/scipy/scipy/issues?direction=desc&milestone=9&sort=created&state=open

It works for the list of issues but not for the list of pull requests.

Is there a policy on this?

Josef


From juanlu001 at gmail.com  Sun Aug 18 09:54:08 2013
From: juanlu001 at gmail.com (Juan Luis Cano)
Date: Sun, 18 Aug 2013 15:54:08 +0200
Subject: [SciPy-Dev] github labels for pull requests
In-Reply-To: <CAMMTP+CJT=LC0hhf=HqVk6ED=88ZumUBzW_48D66po+2=Dkk2A@mail.gmail.com>
References: <CAMMTP+CJT=LC0hhf=HqVk6ED=88ZumUBzW_48D66po+2=Dkk2A@mail.gmail.com>
Message-ID: <5210D200.8000104@gmail.com>

On 08/18/2013 03:48 PM, josef.pktd at gmail.com wrote:
> I added the `stats` label to some pull requests
>
> https://github.com/scipy/scipy/issues?direction=desc&milestone=9&sort=created&state=open
>
> It works for the list of issues but not for the list of pull requests.
>
> Is there a policy on this?
>
> Josef

I'm seeing the open pull requests on the issues page. They get mixed up 
with the issues but as far as I know pull requests cannot be tagged.


From josef.pktd at gmail.com  Sun Aug 18 10:03:57 2013
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Sun, 18 Aug 2013 10:03:57 -0400
Subject: [SciPy-Dev] github labels for pull requests
In-Reply-To: <5210D200.8000104@gmail.com>
References: <CAMMTP+CJT=LC0hhf=HqVk6ED=88ZumUBzW_48D66po+2=Dkk2A@mail.gmail.com>
	<5210D200.8000104@gmail.com>
Message-ID: <CAMMTP+DJGGuMY-Jwk+Gy0SJGw07iF-2h60+YQYthC0=6o=uPCQ@mail.gmail.com>

On Sun, Aug 18, 2013 at 9:54 AM, Juan Luis Cano <juanlu001 at gmail.com> wrote:
> On 08/18/2013 03:48 PM, josef.pktd at gmail.com wrote:
>> I added the `stats` label to some pull requests
>>
>> https://github.com/scipy/scipy/issues?direction=desc&milestone=9&sort=created&state=open
>>
>> It works for the list of issues but not for the list of pull requests.
>>
>> Is there a policy on this?
>>
>> Josef
>
> I'm seeing the open pull requests on the issues page.

That's always the case on github, if no labels are selected
But I would also like to see the open PRs when I want only the issues
and PRs for some labels.

> They get mixed up
> with the issues but as far as I know pull requests cannot be tagged.

We can tag them on the issues list. select them in the small square
and change label.
tagging requires being a member of the organisation or repository, AFAIK

(I used it sometimes for statsmodels to get some order in issues and PRs.)

Josef


> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev


From josef.pktd at gmail.com  Sun Aug 18 11:11:54 2013
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Sun, 18 Aug 2013 11:11:54 -0400
Subject: [SciPy-Dev] deprecating stats.oneway and stats.glm
In-Reply-To: <CABL7CQjxFq--Lmt=bksZU_HOpgPaOP6g4pGpEVZ+KE3Og7JZVQ@mail.gmail.com>
References: <CABL7CQjxFq--Lmt=bksZU_HOpgPaOP6g4pGpEVZ+KE3Og7JZVQ@mail.gmail.com>
Message-ID: <CAMMTP+CGOxiLbH+OKjk3B4Q82rmo4sZRYP_yh-VaLuGegftgig@mail.gmail.com>

On Sat, Aug 17, 2013 at 2:17 PM, Ralf Gommers <ralf.gommers at gmail.com> wrote:
> Hi all,
>
> We're planning to deprecate oneway and glm for the 0.13.0 release:
> https://github.com/scipy/scipy/pull/2733. `oneway` is broken and duplicate
> with f_oneway. `glm` is a duplicate with ttest_ind, undocumented and
> untested. Better alternatives exist in statsmodels as well.
>
> If you see any problem with these deprecations, please speak up.

another candidate for deprecation and removal

stats.cmedian
the default looks strange
I don't see much reason for the binning
np.median is in all (?) cases better  (and will be a lot more
efficient in the next numpy release)
https://github.com/scipy/scipy/issues/580

>>> stats.cmedian(np.arange(10))
4.0045045045045047
>>> stats.cmedian(np.arange(10), numbins=10)
4.5
>>> np.median(np.arange(10))
4.5

>>> stats.cmedian(np.arange(11))
5.005005005005005
>>> stats.cmedian(np.arange(11), numbins=11)
5.0
>>> np.median(np.arange(11))
5.0

Josef


>
> Regards,
> Ralf
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From josef.pktd at gmail.com  Sun Aug 18 13:50:29 2013
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Sun, 18 Aug 2013 13:50:29 -0400
Subject: [SciPy-Dev] github closed issues show up as open in issue list
Message-ID: <CAMMTP+DO64jcsQu400R3BnnJu5_e3bp-7Bym7v61Lez-SXFm7A@mail.gmail.com>

two closed issues

https://github.com/scipy/scipy/issues/652
https://github.com/scipy/scipy/issues/647

but when I search for issues, then they show up as open
https://github.com/scipy/scipy/search?q=anova&state=open&type=Issues

When I saw this in another case earlier today, I managed to change it
to closed in the issue list by reopening and closing the issue.

Is there a better way for this or is there some other problem?


I was reviewing some ancient tickets and closing some outdated ones.
scipy.stats is still the leader in the open issue count by a large margin :(
(and in the closed issue count)

Josef


From pav at iki.fi  Sun Aug 18 14:28:51 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Sun, 18 Aug 2013 21:28:51 +0300
Subject: [SciPy-Dev] github closed issues show up as open in issue list
In-Reply-To: <CAMMTP+DO64jcsQu400R3BnnJu5_e3bp-7Bym7v61Lez-SXFm7A@mail.gmail.com>
References: <CAMMTP+DO64jcsQu400R3BnnJu5_e3bp-7Bym7v61Lez-SXFm7A@mail.gmail.com>
Message-ID: <kur3os$2h3$1@ger.gmane.org>

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

Hi,

18.08.2013 20:50, josef.pktd at gmail.com kirjoitti:
> two closed issues
> 
> https://github.com/scipy/scipy/issues/652 
> https://github.com/scipy/scipy/issues/647
> 
> but when I search for issues, then they show up as open 
> https://github.com/scipy/scipy/search?q=anova&state=open&type=Issues

I
> 
think it'd be best to report this to the Github support people, see
the Contact link at the bottom of the page.

	Pauli

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlIRElsACgkQ6BQxb7O0pWArewCdE13alk0XJ6z4Y8umXtFyaOkA
5N4An1y72o2O7sJKVUu1+NjMK55y4MvJ
=w3Oy
-----END PGP SIGNATURE-----



From josef.pktd at gmail.com  Sun Aug 18 20:56:01 2013
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Sun, 18 Aug 2013 20:56:01 -0400
Subject: [SciPy-Dev] github closed issues show up as open in issue list
In-Reply-To: <kur3os$2h3$1@ger.gmane.org>
References: <CAMMTP+DO64jcsQu400R3BnnJu5_e3bp-7Bym7v61Lez-SXFm7A@mail.gmail.com>
	<kur3os$2h3$1@ger.gmane.org>
Message-ID: <CAMMTP+BV6b71aYE6CdtJAk2yZYUTku63JYaa8ROex7XmyWxgFQ@mail.gmail.com>

On Sun, Aug 18, 2013 at 2:28 PM, Pauli Virtanen <pav at iki.fi> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> 18.08.2013 20:50, josef.pktd at gmail.com kirjoitti:
>> two closed issues
>>
>> https://github.com/scipy/scipy/issues/652
>> https://github.com/scipy/scipy/issues/647
>>
>> but when I search for issues, then they show up as open
>> https://github.com/scipy/scipy/search?q=anova&state=open&type=Issues
>
> I
>>
> think it'd be best to report this to the Github support people, see
> the Contact link at the bottom of the page.

I did that (after your message) and the problem is fixed.

The response from github support:
"The state of an issue in the search index can get out of sync with
the database. I've reindexed the issues for the scipy repository, and
that has taken care of the problem."

good service

Josef

>
>         Pauli
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iEYEARECAAYFAlIRElsACgkQ6BQxb7O0pWArewCdE13alk0XJ6z4Y8umXtFyaOkA
> 5N4An1y72o2O7sJKVUu1+NjMK55y4MvJ
> =w3Oy
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev


From ralf.gommers at gmail.com  Mon Aug 19 15:36:39 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Mon, 19 Aug 2013 21:36:39 +0200
Subject: [SciPy-Dev] deprecating stats.oneway and stats.glm
In-Reply-To: <CAMMTP+CGOxiLbH+OKjk3B4Q82rmo4sZRYP_yh-VaLuGegftgig@mail.gmail.com>
References: <CABL7CQjxFq--Lmt=bksZU_HOpgPaOP6g4pGpEVZ+KE3Og7JZVQ@mail.gmail.com>
	<CAMMTP+CGOxiLbH+OKjk3B4Q82rmo4sZRYP_yh-VaLuGegftgig@mail.gmail.com>
Message-ID: <CABL7CQjNnaKM+zk1Kg=7jXEbNzOJPwZ5+ZKN1g-ek9c9g147_w@mail.gmail.com>

On Sun, Aug 18, 2013 at 5:11 PM, <josef.pktd at gmail.com> wrote:

> On Sat, Aug 17, 2013 at 2:17 PM, Ralf Gommers <ralf.gommers at gmail.com>
> wrote:
> > Hi all,
> >
> > We're planning to deprecate oneway and glm for the 0.13.0 release:
> > https://github.com/scipy/scipy/pull/2733. `oneway` is broken and
> duplicate
> > with f_oneway. `glm` is a duplicate with ttest_ind, undocumented and
> > untested. Better alternatives exist in statsmodels as well.
> >
> > If you see any problem with these deprecations, please speak up.
>
> another candidate for deprecation and removal
>
> stats.cmedian
>

Agreed, it makes no sense to keep that. I'll add it to the PR.

Ralf


the default looks strange
> I don't see much reason for the binning
> np.median is in all (?) cases better  (and will be a lot more
> efficient in the next numpy release)
> https://github.com/scipy/scipy/issues/580
>
> >>> stats.cmedian(np.arange(10))
> 4.0045045045045047
> >>> stats.cmedian(np.arange(10), numbins=10)
> 4.5
> >>> np.median(np.arange(10))
> 4.5
>
> >>> stats.cmedian(np.arange(11))
> 5.005005005005005
> >>> stats.cmedian(np.arange(11), numbins=11)
> 5.0
> >>> np.median(np.arange(11))
> 5.0
>
> Josef
>
>
> >
> > Regards,
> > Ralf
> >
> >
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130819/0a880a41/attachment.html>

From josef.pktd at gmail.com  Wed Aug 21 07:55:03 2013
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Wed, 21 Aug 2013 07:55:03 -0400
Subject: [SciPy-Dev] github labels for pull requests
In-Reply-To: <CAMMTP+DJGGuMY-Jwk+Gy0SJGw07iF-2h60+YQYthC0=6o=uPCQ@mail.gmail.com>
References: <CAMMTP+CJT=LC0hhf=HqVk6ED=88ZumUBzW_48D66po+2=Dkk2A@mail.gmail.com>
	<5210D200.8000104@gmail.com>
	<CAMMTP+DJGGuMY-Jwk+Gy0SJGw07iF-2h60+YQYthC0=6o=uPCQ@mail.gmail.com>
Message-ID: <CAMMTP+C-Q6bT6r4LhADUN5iHS7y1Gy_f+40_Vr+t30Mm38_vSQ@mail.gmail.com>

On Sun, Aug 18, 2013 at 10:03 AM,  <josef.pktd at gmail.com> wrote:
> On Sun, Aug 18, 2013 at 9:54 AM, Juan Luis Cano <juanlu001 at gmail.com> wrote:
>> On 08/18/2013 03:48 PM, josef.pktd at gmail.com wrote:
>>> I added the `stats` label to some pull requests
>>>
>>> https://github.com/scipy/scipy/issues?direction=desc&milestone=9&sort=created&state=open
>>>
>>> It works for the list of issues but not for the list of pull requests.
>>>
>>> Is there a policy on this?
>>>
>>> Josef
>>
>> I'm seeing the open pull requests on the issues page.
>
> That's always the case on github, if no labels are selected
> But I would also like to see the open PRs when I want only the issues
> and PRs for some labels.
>
>> They get mixed up
>> with the issues but as far as I know pull requests cannot be tagged.
>
> We can tag them on the issues list. select them in the small square
> and change label.
> tagging requires being a member of the organisation or repository, AFAIK
>
> (I used it sometimes for statsmodels to get some order in issues and PRs.)


Related question:

Can we add a tag for "invalid" ?

I'm trying to get more order into open and closed issues on github.
For example adding milestones to recent commits.

It's a bit annoying to browse and read through tickets that are
labeled as "defect" when they were actually closed as "invalid" (or
the other Trac alternatives like "works for me".)

Josef
only 159 issues left

>
> Josef
>
>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev


From ralf.gommers at gmail.com  Wed Aug 21 07:57:49 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Wed, 21 Aug 2013 13:57:49 +0200
Subject: [SciPy-Dev] github labels for pull requests
In-Reply-To: <CAMMTP+C-Q6bT6r4LhADUN5iHS7y1Gy_f+40_Vr+t30Mm38_vSQ@mail.gmail.com>
References: <CAMMTP+CJT=LC0hhf=HqVk6ED=88ZumUBzW_48D66po+2=Dkk2A@mail.gmail.com>
	<5210D200.8000104@gmail.com>
	<CAMMTP+DJGGuMY-Jwk+Gy0SJGw07iF-2h60+YQYthC0=6o=uPCQ@mail.gmail.com>
	<CAMMTP+C-Q6bT6r4LhADUN5iHS7y1Gy_f+40_Vr+t30Mm38_vSQ@mail.gmail.com>
Message-ID: <CABL7CQgY9WyPVz-h5gonjmv5GHRtrtfh212N0X7J3ONFiZ7Q4Q@mail.gmail.com>

On Wed, Aug 21, 2013 at 1:55 PM, <josef.pktd at gmail.com> wrote:

> On Sun, Aug 18, 2013 at 10:03 AM,  <josef.pktd at gmail.com> wrote:
> > On Sun, Aug 18, 2013 at 9:54 AM, Juan Luis Cano <juanlu001 at gmail.com>
> wrote:
> >> On 08/18/2013 03:48 PM, josef.pktd at gmail.com wrote:
> >>> I added the `stats` label to some pull requests
> >>>
> >>>
> https://github.com/scipy/scipy/issues?direction=desc&milestone=9&sort=created&state=open
> >>>
> >>> It works for the list of issues but not for the list of pull requests.
> >>>
> >>> Is there a policy on this?
> >>>
> >>> Josef
> >>
> >> I'm seeing the open pull requests on the issues page.
> >
> > That's always the case on github, if no labels are selected
> > But I would also like to see the open PRs when I want only the issues
> > and PRs for some labels.
> >
> >> They get mixed up
> >> with the issues but as far as I know pull requests cannot be tagged.
> >
> > We can tag them on the issues list. select them in the small square
> > and change label.
> > tagging requires being a member of the organisation or repository, AFAIK
> >
> > (I used it sometimes for statsmodels to get some order in issues and
> PRs.)
>
>
> Related question:
>
> Can we add a tag for "invalid" ?
>

+1


> I'm trying to get more order into open and closed issues on github.
> For example adding milestones to recent commits.
>

Thanks for doing that.

Ralf


> It's a bit annoying to browse and read through tickets that are
> labeled as "defect" when they were actually closed as "invalid" (or
> the other Trac alternatives like "works for me".)
>
> Josef
> only 159 issues left
>
> >
> > Josef
> >
> >
> >> _______________________________________________
> >> SciPy-Dev mailing list
> >> SciPy-Dev at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130821/360cda21/attachment.html>

From josef.pktd at gmail.com  Wed Aug 21 08:15:37 2013
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Wed, 21 Aug 2013 08:15:37 -0400
Subject: [SciPy-Dev] github labels for pull requests
In-Reply-To: <CABL7CQgY9WyPVz-h5gonjmv5GHRtrtfh212N0X7J3ONFiZ7Q4Q@mail.gmail.com>
References: <CAMMTP+CJT=LC0hhf=HqVk6ED=88ZumUBzW_48D66po+2=Dkk2A@mail.gmail.com>
	<5210D200.8000104@gmail.com>
	<CAMMTP+DJGGuMY-Jwk+Gy0SJGw07iF-2h60+YQYthC0=6o=uPCQ@mail.gmail.com>
	<CAMMTP+C-Q6bT6r4LhADUN5iHS7y1Gy_f+40_Vr+t30Mm38_vSQ@mail.gmail.com>
	<CABL7CQgY9WyPVz-h5gonjmv5GHRtrtfh212N0X7J3ONFiZ7Q4Q@mail.gmail.com>
Message-ID: <CAMMTP+CrZYgEU3J5AS7ObiWH+WLmRMYnRWp_Kex3FsfTqf4ANA@mail.gmail.com>

On Wed, Aug 21, 2013 at 7:57 AM, Ralf Gommers <ralf.gommers at gmail.com> wrote:
>
>
>
> On Wed, Aug 21, 2013 at 1:55 PM, <josef.pktd at gmail.com> wrote:
>>
>> On Sun, Aug 18, 2013 at 10:03 AM,  <josef.pktd at gmail.com> wrote:
>> > On Sun, Aug 18, 2013 at 9:54 AM, Juan Luis Cano <juanlu001 at gmail.com>
>> > wrote:
>> >> On 08/18/2013 03:48 PM, josef.pktd at gmail.com wrote:
>> >>> I added the `stats` label to some pull requests
>> >>>
>> >>>
>> >>> https://github.com/scipy/scipy/issues?direction=desc&milestone=9&sort=created&state=open
>> >>>
>> >>> It works for the list of issues but not for the list of pull requests.
>> >>>
>> >>> Is there a policy on this?
>> >>>
>> >>> Josef
>> >>
>> >> I'm seeing the open pull requests on the issues page.
>> >
>> > That's always the case on github, if no labels are selected
>> > But I would also like to see the open PRs when I want only the issues
>> > and PRs for some labels.
>> >
>> >> They get mixed up
>> >> with the issues but as far as I know pull requests cannot be tagged.
>> >
>> > We can tag them on the issues list. select them in the small square
>> > and change label.
>> > tagging requires being a member of the organisation or repository, AFAIK
>> >
>> > (I used it sometimes for statsmodels to get some order in issues and
>> > PRs.)
>>
>>
>> Related question:
>>
>> Can we add a tag for "invalid" ?
>
>
> +1

done
do you want to change the color? example
https://github.com/scipy/scipy/issues/2371
my taste (statsmodels) differs from scipy

>
>>
>> I'm trying to get more order into open and closed issues on github.
>> For example adding milestones to recent commits.
>
>
> Thanks for doing that.

are we adding milestones to merged PRs for all subpackages?
I (accidentally) looked at some non-stats PRs

Josef

>
> Ralf
>
>>
>> It's a bit annoying to browse and read through tickets that are
>> labeled as "defect" when they were actually closed as "invalid" (or
>> the other Trac alternatives like "works for me".)
>>
>> Josef
>> only 159 issues left
>>
>> >
>> > Josef
>> >
>> >
>> >> _______________________________________________
>> >> SciPy-Dev mailing list
>> >> SciPy-Dev at scipy.org
>> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From ralf.gommers at gmail.com  Wed Aug 21 08:26:25 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Wed, 21 Aug 2013 14:26:25 +0200
Subject: [SciPy-Dev] github labels for pull requests
In-Reply-To: <CAMMTP+CrZYgEU3J5AS7ObiWH+WLmRMYnRWp_Kex3FsfTqf4ANA@mail.gmail.com>
References: <CAMMTP+CJT=LC0hhf=HqVk6ED=88ZumUBzW_48D66po+2=Dkk2A@mail.gmail.com>
	<5210D200.8000104@gmail.com>
	<CAMMTP+DJGGuMY-Jwk+Gy0SJGw07iF-2h60+YQYthC0=6o=uPCQ@mail.gmail.com>
	<CAMMTP+C-Q6bT6r4LhADUN5iHS7y1Gy_f+40_Vr+t30Mm38_vSQ@mail.gmail.com>
	<CABL7CQgY9WyPVz-h5gonjmv5GHRtrtfh212N0X7J3ONFiZ7Q4Q@mail.gmail.com>
	<CAMMTP+CrZYgEU3J5AS7ObiWH+WLmRMYnRWp_Kex3FsfTqf4ANA@mail.gmail.com>
Message-ID: <CABL7CQjnXHzzkSzxHEcdwpX=PXsdzV8c_BF7_RCmj8Dd246p4Q@mail.gmail.com>

On Wed, Aug 21, 2013 at 2:15 PM, <josef.pktd at gmail.com> wrote:

> On Wed, Aug 21, 2013 at 7:57 AM, Ralf Gommers <ralf.gommers at gmail.com>
> wrote:
> >
> >
> >
> > On Wed, Aug 21, 2013 at 1:55 PM, <josef.pktd at gmail.com> wrote:
> >>
> >>
> >> Related question:
> >>
> >> Can we add a tag for "invalid" ?
> >
> >
> > +1
>
> done
> do you want to change the color? example
> https://github.com/scipy/scipy/issues/2371
> my taste (statsmodels) differs from scipy
>

Nice bikeshedding topic - but no, looks good to me.

>>
> >> I'm trying to get more order into open and closed issues on github.
> >> For example adding milestones to recent commits.
> >
> >
> > Thanks for doing that.
>
> are we adding milestones to merged PRs for all subpackages?
> I (accidentally) looked at some non-stats PRs
>

That would be good and I've tried to do this recently, but we haven't been
doing this before. If everyone could make this a habit, that would be
useful.

Note: if PRs are not yet merged, only add a milestone if it's important
that the PR goes into a particular release.

Ralf



> Josef
>
> >
> > Ralf
> >
> >>
> >> It's a bit annoying to browse and read through tickets that are
> >> labeled as "defect" when they were actually closed as "invalid" (or
> >> the other Trac alternatives like "works for me".)
> >>
> >> Josef
> >> only 159 issues left
> >>
> >> >
> >> > Josef
> >> >
> >> >
> >> >> _______________________________________________
> >> >> SciPy-Dev mailing list
> >> >> SciPy-Dev at scipy.org
> >> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
> >> _______________________________________________
> >> SciPy-Dev mailing list
> >> SciPy-Dev at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> >
> >
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130821/e3f34772/attachment.html>

From josef.pktd at gmail.com  Wed Aug 21 08:33:06 2013
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Wed, 21 Aug 2013 08:33:06 -0400
Subject: [SciPy-Dev] github labels for pull requests
In-Reply-To: <CABL7CQjnXHzzkSzxHEcdwpX=PXsdzV8c_BF7_RCmj8Dd246p4Q@mail.gmail.com>
References: <CAMMTP+CJT=LC0hhf=HqVk6ED=88ZumUBzW_48D66po+2=Dkk2A@mail.gmail.com>
	<5210D200.8000104@gmail.com>
	<CAMMTP+DJGGuMY-Jwk+Gy0SJGw07iF-2h60+YQYthC0=6o=uPCQ@mail.gmail.com>
	<CAMMTP+C-Q6bT6r4LhADUN5iHS7y1Gy_f+40_Vr+t30Mm38_vSQ@mail.gmail.com>
	<CABL7CQgY9WyPVz-h5gonjmv5GHRtrtfh212N0X7J3ONFiZ7Q4Q@mail.gmail.com>
	<CAMMTP+CrZYgEU3J5AS7ObiWH+WLmRMYnRWp_Kex3FsfTqf4ANA@mail.gmail.com>
	<CABL7CQjnXHzzkSzxHEcdwpX=PXsdzV8c_BF7_RCmj8Dd246p4Q@mail.gmail.com>
Message-ID: <CAMMTP+CBFCX2HwiBJFNbU-9R5OGForf-Jk_76Hdrwo7GwJydoQ@mail.gmail.com>

On Wed, Aug 21, 2013 at 8:26 AM, Ralf Gommers <ralf.gommers at gmail.com> wrote:
>
>
>
> On Wed, Aug 21, 2013 at 2:15 PM, <josef.pktd at gmail.com> wrote:
>>
>> On Wed, Aug 21, 2013 at 7:57 AM, Ralf Gommers <ralf.gommers at gmail.com>
>> wrote:
>> >
>> >
>> >
>> > On Wed, Aug 21, 2013 at 1:55 PM, <josef.pktd at gmail.com> wrote:
>> >>
>> >>
>> >> Related question:
>> >>
>> >> Can we add a tag for "invalid" ?
>> >
>> >
>> > +1
>>
>> done
>> do you want to change the color? example
>> https://github.com/scipy/scipy/issues/2371
>> my taste (statsmodels) differs from scipy
>
>
> Nice bikeshedding topic - but no, looks good to me.

no bikesheds allowed, this has to be a dictatorial (or executive
committee) decision
(I only care enough about the colors in statsmodels.)

>
>> >>
>> >> I'm trying to get more order into open and closed issues on github.
>> >> For example adding milestones to recent commits.
>> >
>> >
>> > Thanks for doing that.
>>
>> are we adding milestones to merged PRs for all subpackages?
>> I (accidentally) looked at some non-stats PRs
>
>
> That would be good and I've tried to do this recently, but we haven't been
> doing this before. If everyone could make this a habit, that would be
> useful.
>
> Note: if PRs are not yet merged, only add a milestone if it's important that
> the PR goes into a particular release.

Thanks, will do.

Do you have an opinion about the original question: adding labels to PRs?

Josef

>
> Ralf
>
>
>>
>> Josef
>>
>> >
>> > Ralf
>> >
>> >>
>> >> It's a bit annoying to browse and read through tickets that are
>> >> labeled as "defect" when they were actually closed as "invalid" (or
>> >> the other Trac alternatives like "works for me".)
>> >>
>> >> Josef
>> >> only 159 issues left
>> >>
>> >> >
>> >> > Josef
>> >> >
>> >> >
>> >> >> _______________________________________________
>> >> >> SciPy-Dev mailing list
>> >> >> SciPy-Dev at scipy.org
>> >> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
>> >> _______________________________________________
>> >> SciPy-Dev mailing list
>> >> SciPy-Dev at scipy.org
>> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
>> >
>> >
>> >
>> > _______________________________________________
>> > SciPy-Dev mailing list
>> > SciPy-Dev at scipy.org
>> > http://mail.scipy.org/mailman/listinfo/scipy-dev
>> >
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From ralf.gommers at gmail.com  Wed Aug 21 08:56:01 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Wed, 21 Aug 2013 14:56:01 +0200
Subject: [SciPy-Dev] github labels for pull requests
In-Reply-To: <CAMMTP+CBFCX2HwiBJFNbU-9R5OGForf-Jk_76Hdrwo7GwJydoQ@mail.gmail.com>
References: <CAMMTP+CJT=LC0hhf=HqVk6ED=88ZumUBzW_48D66po+2=Dkk2A@mail.gmail.com>
	<5210D200.8000104@gmail.com>
	<CAMMTP+DJGGuMY-Jwk+Gy0SJGw07iF-2h60+YQYthC0=6o=uPCQ@mail.gmail.com>
	<CAMMTP+C-Q6bT6r4LhADUN5iHS7y1Gy_f+40_Vr+t30Mm38_vSQ@mail.gmail.com>
	<CABL7CQgY9WyPVz-h5gonjmv5GHRtrtfh212N0X7J3ONFiZ7Q4Q@mail.gmail.com>
	<CAMMTP+CrZYgEU3J5AS7ObiWH+WLmRMYnRWp_Kex3FsfTqf4ANA@mail.gmail.com>
	<CABL7CQjnXHzzkSzxHEcdwpX=PXsdzV8c_BF7_RCmj8Dd246p4Q@mail.gmail.com>
	<CAMMTP+CBFCX2HwiBJFNbU-9R5OGForf-Jk_76Hdrwo7GwJydoQ@mail.gmail.com>
Message-ID: <CABL7CQg+huRPAaHrWC6VXh289AHUxb7zACPdgfWR-Zu=y+9jFA@mail.gmail.com>

On Wed, Aug 21, 2013 at 2:33 PM, <josef.pktd at gmail.com> wrote:

> >>
> >> are we adding milestones to merged PRs for all subpackages?
> >> I (accidentally) looked at some non-stats PRs
> >
> >
> > That would be good and I've tried to do this recently, but we haven't
> been
> > doing this before. If everyone could make this a habit, that would be
> > useful.
> >
> > Note: if PRs are not yet merged, only add a milestone if it's important
> that
> > the PR goes into a particular release.
>
> Thanks, will do.
>
> Do you have an opinion about the original question: adding labels to PRs?
>

Is useful, so let's do that consistently as well.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130821/919251d6/attachment.html>

From ewm at redtetrahedron.org  Wed Aug 21 11:50:34 2013
From: ewm at redtetrahedron.org (Eric Moore)
Date: Wed, 21 Aug 2013 11:50:34 -0400
Subject: [SciPy-Dev] fftpack.convolve.convolve
In-Reply-To: <68515d0d5b89edc18360cc0df135885c@scorpius.uberspace.de>
References: <68515d0d5b89edc18360cc0df135885c@scorpius.uberspace.de>
Message-ID: <5214E1CA.3050200@redtetrahedron.org>

Clemens Novak wrote:
> Hi,
>
> I've been working on extending the fftpack tutorial page (you can see
> the current status here:
> https://github.com/ClemensFMN/scipy/blob/tut_fft/doc/source/tutorial/fftpack.rst
> ) and I stumbled across the function fftpack.convolve.convolve .
>
> Sorry the blunt question, but what does this function do? From the name
> I'd assume that it calculates the convolution of two sequences (as
> convolve in scipy.signal does) using the fft (since it is part of
> fftpack), but appearently it doesn't:
>
> import numpy as np
> import scipy.fftpack.convolve as conv
> import scipy as sp
> import scipy.signal as sig
>
>
> x = np.array([1.0, 0.0, 0.0])
> h = np.array([1.0, 2.0, 3.0])
>
> y1 = conv.convolve(x, h)
> [ 5. -1. -1.]
>
> y2 = sig.convolve(x, h)
> [ 1.  2.  3.  0.  0.]
>
> y3 = sp.ifft(sp.fft(x) * sp.fft(h))
> [ 1.+0.j  2.+0.j  3.+0.j]
>
> Does the function extend its first and/or second argument to a periodic
> sequence and perform then the convolution (I tried some ideas but that
> didn'twork either)? It would be great if someone could please provide
> some insight...
>
> Regards - Clemens
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev

AFAICT, fftpack.convolve exists in support of pseudo_diffs.py.  Look 
there to see some examples.

-Eric



From ralf.gommers at gmail.com  Wed Aug 21 17:52:21 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Wed, 21 Aug 2013 23:52:21 +0200
Subject: [SciPy-Dev] 0.13.x branch created
Message-ID: <CABL7CQg9K3YXLfm93Av=4F0ZfoytHoy3VW2jocKnifrMKGoy1g@mail.gmail.com>

Hi all,

The maintenance/0.13.x branch has been created, a beta release will follow
shortly. Thanks to everyone that helped merge PRs and fix last-minute
issues before branching!

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130821/323372cb/attachment.html>

From juanlu001 at gmail.com  Thu Aug 22 04:47:54 2013
From: juanlu001 at gmail.com (Juan Luis Cano)
Date: Thu, 22 Aug 2013 10:47:54 +0200
Subject: [SciPy-Dev] 0.13.x branch created
In-Reply-To: <CABL7CQg9K3YXLfm93Av=4F0ZfoytHoy3VW2jocKnifrMKGoy1g@mail.gmail.com>
References: <CABL7CQg9K3YXLfm93Av=4F0ZfoytHoy3VW2jocKnifrMKGoy1g@mail.gmail.com>
Message-ID: <5215D03A.60508@gmail.com>

On 08/21/2013 11:52 PM, Ralf Gommers wrote:
> Hi all,
>
> The maintenance/0.13.x branch has been created, a beta release will 
> follow shortly. Thanks to everyone that helped merge PRs and fix 
> last-minute issues before branching!
>
> Cheers,
> Ralf

At this point, and when the beta is tagged - what is the criteria for 
including code? The beta is considered a sort of feature freeze, and 
only bug fixes are applied? The rest of PRs must be made against master? 
Is the plan still releasing roughly every six months? Can we start 
thinking of the features of 0.14? :)


From ralf.gommers at gmail.com  Thu Aug 22 08:09:26 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Thu, 22 Aug 2013 14:09:26 +0200
Subject: [SciPy-Dev] 0.13.x branch created
In-Reply-To: <5215D03A.60508@gmail.com>
References: <CABL7CQg9K3YXLfm93Av=4F0ZfoytHoy3VW2jocKnifrMKGoy1g@mail.gmail.com>
	<5215D03A.60508@gmail.com>
Message-ID: <CABL7CQiqZqcSBkEk6cEybSNHi4rqWrkGDr4GXSWSTBJJx6PMgA@mail.gmail.com>

On Thu, Aug 22, 2013 at 10:47 AM, Juan Luis Cano <juanlu001 at gmail.com>wrote:

> On 08/21/2013 11:52 PM, Ralf Gommers wrote:
> > Hi all,
> >
> > The maintenance/0.13.x branch has been created, a beta release will
> > follow shortly. Thanks to everyone that helped merge PRs and fix
> > last-minute issues before branching!
> >
> > Cheers,
> > Ralf
>
> At this point, and when the beta is tagged - what is the criteria for
> including code? The beta is considered a sort of feature freeze, and
> only bug fixes are applied? The rest of PRs must be made against master?
>

PRs (new feature and bugfix) must always be made against master, from where
bug fixes (and maybe some other things, like documentation improvements)
will be backported to 0.13.x as needed.

Is the plan still releasing roughly every six months?


Yes


> Can we start
> thinking of the features of 0.14? :)
>

Sure. There's always a flow of new features - all open PRs with new
features are for 0.14.0 now. Other new features welcome; we don't really
have a fixed roadmap, things that fit in scipy and are implemented well
will go in.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130822/e79978c8/attachment.html>

From ralf.gommers at gmail.com  Thu Aug 22 08:26:08 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Thu, 22 Aug 2013 14:26:08 +0200
Subject: [SciPy-Dev] Numpy/Scipy sprint this Sunday
Message-ID: <CABL7CQgJvgoW86zttVGjh74K0TJC=o1Ak6BArZHUkpQqnBFaLw@mail.gmail.com>

Hi all,

Here's a reminder that we have a sprint this Sunday (Aug 25) at EuroScipy.
There are already 12 people who indicated they'd join; even more would be
even better.

Location: https://www.euroscipy.org/venue/ (room K3.601)
Time: 9am - 7pm
More details:
https://github.com/rgommers/scipy/wiki/EuroSciPy%2713-numpy-scipy-sprint
No previous experience contributing to numpy and scipy required (although
you should know how to use python/numpy/scipy/git to a reasonable extent).
Please try to get your development environment set up beforehand - see
developer guides at http://docs.scipy.org/doc/ for explanation of how to do
that.

If you can't join in Brussels, we'll also be on IRC and mailing lists. Hope
to see a large turnout!

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130822/9acc0851/attachment.html>

From ralf.gommers at gmail.com  Thu Aug 22 09:12:21 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Thu, 22 Aug 2013 15:12:21 +0200
Subject: [SciPy-Dev] ANN: Scipy 0.13.0 beta 1 release
Message-ID: <CABL7CQga-Qkq8_hG1E+_KfpmVjSE-duyRePVcZw_-s-PXay75w@mail.gmail.com>

Hi all,

I'm happy to announce the availability of the first beta release of Scipy
0.13.0. Please try this beta and report any issues on the scipy-dev mailing
list.

Source tarballs and release notes can be found at
https://sourceforge.net/projects/scipy/files/scipy/0.13.0b1/. Windows and
OS X installers will follow later (we have a minor infrastructure issue to
solve, and I'm at EuroScipy now).

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130822/60ea1dc9/attachment.html>

From wbuckner at beatsmusic.com  Thu Aug 22 17:40:11 2013
From: wbuckner at beatsmusic.com (Will Buckner)
Date: Thu, 22 Aug 2013 14:40:11 -0700
Subject: [SciPy-Dev] Many Problems Building w/ MKL 11, ifort, icc;
 scipy.test() Fails w/ Undefined Symbols
In-Reply-To: <CABL7CQgihY5_yGmsxzO_UqWa78WE-z-R-7_MEONsvmt=XZ9_RA@mail.gmail.com>
References: <CAL_nGS5gb-U2v3N6QwMHWZ70NNzuk_OS1ciFE0r8fLRK+NeHvA@mail.gmail.com>
	<CABL7CQgihY5_yGmsxzO_UqWa78WE-z-R-7_MEONsvmt=XZ9_RA@mail.gmail.com>
Message-ID: <CAL_nGS4bA6QxhNxKKVddAc=HRZDTYUeNodDryCuPn8kSBJZH5Q@mail.gmail.com>

Hadn't found them until you told me, but I've now carefully reviewed and
followed instructions from that doc. It's still not linking mkl_core
properly before intel_thread. Using mkl_rt doesn't help at all--and, I'm
unclear why that
's not just the default directions if mkl_rt works properly. When using
mkl_rt, I still must
use LD_PRELOAD=/opt/intel/mkl/lib/intel64/libmkl_core.so:/opt/intel/lib/intel64/libiomp5.so
or I get undefined symbol errors when running python. It's as if these two
libraries just aren't linked, and LD_PRELOAD is a bandaid. Is there a way
to manually edit the link line anywhere? Or where's it being built? If I
control+f my terminal output from a verbose build, I see no "-lanything"
being passed anywhere.

Thanks,
Will


On Wed, Aug 14, 2013 at 2:19 PM, Ralf Gommers <ralf.gommers at gmail.com>wrote:

>
>
>
> On Wed, Aug 14, 2013 at 9:52 PM, Will Buckner <wbuckner at beatsmusic.com>wrote:
>
>> I've tried this about 6 different ways now, and all successful builds
>> result in the same error during scipy.test() (note that NumPy builds fine
>> with same site.cfg):
>>
>> ======================================================================
>> ERROR: Failure: ImportError
>> (/opt/intel/composer_xe_2013.5.192/mkl/lib/intel64/libmkl_intel_thread.so:
>> undefined symbol: mkl_blas_dgemm_blk_info_bdz)
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>>   File "/usr/local/lib/python2.7/dist-packages/nose/loader.py", line 413,
>> in loadTestsFromName
>>     addr.filename, addr.module)
>>   File "/usr/local/lib/python2.7/dist-packages/nose/importer.py", line
>> 47, in importFromPath
>>     return self.importFromDir(dir_path, fqname)
>>   File "/usr/local/lib/python2.7/dist-packages/nose/importer.py", line
>> 94, in importFromDir
>>     mod = load_module(part_fqname, fh, filename, desc)
>>   File "/usr/local/lib/python2.7/dist-packages/scipy/stats/__init__.py",
>> line 320, in <module>
>>     from .stats import *
>>   File "/usr/local/lib/python2.7/dist-packages/scipy/stats/stats.py",
>> line 242, in <module>
>>     import scipy.linalg as linalg
>>   File "/usr/local/lib/python2.7/dist-packages/scipy/linalg/__init__.py",
>> line 147, in <module>
>>     from .misc import *
>>   File "/usr/local/lib/python2.7/dist-packages/scipy/linalg/misc.py",
>> line 5, in <module>
>>     from . import blas
>>   File "/usr/local/lib/python2.7/dist-packages/scipy/linalg/blas.py",
>> line 113, in <module>
>>     from scipy.linalg import _fblas
>> ImportError:
>> /opt/intel/composer_xe_2013.5.192/mkl/lib/intel64/libmkl_intel_thread.so:
>> undefined symbol: mkl_blas_dgemm_blk_info_bdz
>>
>>
>> Here's some info on my environment:
>>
>> Intel Composer XE 2013.5.192, ifort+icc
>> icc flags: -fPIC -DMKL_ILP64 -m64 -fp-model', 'strict',
>> '-fomit-frame-pointer', '-openmp', '-xhost', '-parallel'
>> ifort flags: -fPIC -i8 -xhost -openmp -fp-model strict
>> OS: Ubuntu 12.04
>> 24 Cores Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz
>> Intel LibMKL 11.0.5
>>
>> site.cfg:
>>
>> [mkl]
>> library_dirs = /opt/intel/mkl/lib/intel64:/opt/intel/lib/intel64
>> include_dirs = /opt/intel/mkl/include:/opt/intel/include
>> lapack_libs = mkl_lapack95_lp64
>> mkl_libs = mkl_def, mkl_intel_lp64, mkl_intel_thread, mkl_core, mkl_mc
>>
>> [fftw]
>> library_dirs = /opt/intel/mkl/lib/intel64
>> include_dirs = /opt/intel/mkl/include
>> libraries = fftw3
>>
>> [amd]
>> amd_libs = amd
>> library_dirs = /usr/lib
>> include_dirs = /usr/include/suitesparse/
>>
>> [umfpack]
>> umfpack_libs = umfpack
>> library_dirs = /usr/lib
>> include_dirs = /usr/include/suitesparse/
>>
>> Built with:
>> python setup.py clean
>> python setup.py  -v config --compiler=intelem --fcompiler=intelem
>> build_clib --compiler=intelem --fcompiler=intelem build_ext
>>  --compiler=intelem --fcompiler=intelem install
>>
>>   FOUND:
>>     libraries = ['mkl_def', 'mkl_intel_lp64', 'mkl_intel_thread',
>> 'mkl_core', 'mkl_mc', 'pthread']
>>     library_dirs = ['/opt/intel/mkl/lib/intel64']
>>     define_macros = [('SCIPY_MKL_H', None)]
>>     include_dirs = ['/opt/intel/mkl/include', '/opt/intel/include']
>>
>>   FOUND:
>>     libraries = ['mkl_def', 'mkl_intel_lp64', 'mkl_intel_thread',
>> 'mkl_core', 'mkl_mc', 'pthread']
>>     library_dirs = ['/opt/intel/mkl/lib/intel64']
>>     define_macros = [('SCIPY_MKL_H', None)]
>>     include_dirs = ['/opt/intel/mkl/include', '/opt/intel/include']
>>
>>   FOUND:
>>     libraries = ['mkl_lapack95_lp64', 'mkl_def', 'mkl_intel_lp64',
>> 'mkl_intel_thread', 'mkl_core', 'mkl_mc', 'pthread']
>>     library_dirs = ['/opt/intel/mkl/lib/intel64']
>>     define_macros = [('SCIPY_MKL_H', None)]
>>     include_dirs = ['/opt/intel/mkl/include', '/opt/intel/include']
>>
>> ( library_dirs = /usr/local/lib:/usr/lib:/usr/lib/x86_64-linux-gnu )
>>   FOUND:
>>     libraries = ['mkl_lapack95_lp64', 'mkl_def', 'mkl_intel_lp64',
>> 'mkl_intel_thread', 'mkl_core', 'mkl_mc', 'pthread']
>>     library_dirs = ['/opt/intel/mkl/lib/intel64']
>>     define_macros = [('SCIPY_MKL_H', None)]
>>     include_dirs = ['/opt/intel/mkl/include', '/opt/intel/include']
>>
>>
>> **The problem is here:**
>>
>> ======================================================================
>> ERROR: Failure: ImportError
>> (/opt/intel/composer_xe_2013.5.192/mkl/lib/intel64/libmkl_intel_thread.so:
>> undefined symbol: mkl_blas_dgemm_blk_info_bdz)
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>>   File "/usr/local/lib/python2.7/dist-packages/nose/loader.py", line 413,
>> in loadTestsFromName
>>     addr.filename, addr.module)
>>   File "/usr/local/lib/python2.7/dist-packages/nose/importer.py", line
>> 47, in importFromPath
>>     return self.importFromDir(dir_path, fqname)
>>   File "/usr/local/lib/python2.7/dist-packages/nose/importer.py", line
>> 94, in importFromDir
>>     mod = load_module(part_fqname, fh, filename, desc)
>>   File "/usr/local/lib/python2.7/dist-packages/scipy/stats/__init__.py",
>> line 320, in <module>
>>     from .stats import *
>>   File "/usr/local/lib/python2.7/dist-packages/scipy/stats/stats.py",
>> line 242, in <module>
>>     import scipy.linalg as linalg
>>   File "/usr/local/lib/python2.7/dist-packages/scipy/linalg/__init__.py",
>> line 147, in <module>
>>     from .misc import *
>>   File "/usr/local/lib/python2.7/dist-packages/scipy/linalg/misc.py",
>> line 5, in <module>
>>     from . import blas
>>   File "/usr/local/lib/python2.7/dist-packages/scipy/linalg/blas.py",
>> line 113, in <module>
>>     from scipy.linalg import _fblas
>> ImportError:
>> /opt/intel/composer_xe_2013.5.192/mkl/lib/intel64/libmkl_intel_thread.so:
>> undefined symbol: mkl_blas_dgemm_blk_info_bdz
>>
>>
>> Now, where is mkl_blas_dgemm_blk_info_bdz defined?
>>
>> daisy at speedballcompute01:/opt/intel/mkl/lib/intel64$ nm libmkl_core.so |
>> grep mkl_blas_dgemm_blk_info_bdz
>> 00000000000c59f0 T mkl_blas_dgemm_blk_info_bdz
>> daisy at speedballcompute01:/opt/intel/mkl/lib/intel64$
>>
>> Right there ^.
>>
>> I included mkl_core in site.cfg and it seems to be linking it, so I'm not
>> sure why this symbol is still undefined. Note that it *is* undefined in
>> libmkl_intel_thread.so:
>>
>> daisy at speedballcompute01:/opt/intel/mkl/lib/intel64$ nm
>> libmkl_intel_thread.so | grep mkl_blas_dgemm_blk_info_bdz
>>                  U mkl_blas_dgemm_blk_info_bdz
>> daisy at speedballcompute01:/opt/intel/mkl/lib/intel64$
>>
>>
>> I also tried the instructions provided by intel at
>> http://software.intel.com/en-us/articles/numpyscipy-with-intel-mkl,
>> using just mkl_rt. This had the same result, and seems incorrect, as it's
>> not providing any lapack libraries (I'm assuming it would just fall back to
>> "no lapack" and it seems to). This is highly confusing, as all of the MKL
>> numpy/scipy instructions seem to be for older MKLs, before mkl_rt.
>>
>
> These are fairly recent and mention mkl_rt:
> http://scipy.org/scipylib/building/linux.html#any-distribution-with-intel-c-compiler-and-mkl.
> Did you find those?
>
> Ralf
>
>
>
>>
>> Could anyone help me debug this? I'm hopelessly frustrated with it at
>> this point and willing to do whatever to help you guys debug.
>>
>> Thanks! What additional info is needed?
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


-- 


*Will Buckner*
Machine Learning & Data Architect
(408) 637-8466 (m)
wbuckner at beatsmusic.com
*
*
*Beats Music*
*
*

The information contained in or attached to this transmission may contain
privileged and confidential information.  It is intended only for the use
of the person(s) named above. If you are not the intended recipient, you
are hereby notified that any review, dissemination, distribution or
duplication of this communication is strictly prohibited. If you are not
the intended recipient, please contact the sender by reply email and delete
all copies of the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130822/6537591a/attachment.html>

From beamesleach at gmail.com  Thu Aug 22 18:40:28 2013
From: beamesleach at gmail.com (Alex Leach)
Date: Thu, 22 Aug 2013 23:40:28 +0100
Subject: [SciPy-Dev] Many Problems Building w/ MKL 11, ifort, icc;
 scipy.test() Fails w/ Undefined Symbols
In-Reply-To: <CAL_nGS4bA6QxhNxKKVddAc=HRZDTYUeNodDryCuPn8kSBJZH5Q@mail.gmail.com>
References: <CAL_nGS5gb-U2v3N6QwMHWZ70NNzuk_OS1ciFE0r8fLRK+NeHvA@mail.gmail.com>
	<CABL7CQgihY5_yGmsxzO_UqWa78WE-z-R-7_MEONsvmt=XZ9_RA@mail.gmail.com>
	<CAL_nGS4bA6QxhNxKKVddAc=HRZDTYUeNodDryCuPn8kSBJZH5Q@mail.gmail.com>
Message-ID: <CABOfY3Cbc0zCyfO=43RwtU55RjqB9=PDXpKdCduG3R25o-xyqw@mail.gmail.com>

Looks to me like you need to update your system's ldconfig files. Without
an -rpath / -R linker flag, the lib. directories will need to be known by
the dynamic linker during run time, as well as during compile-time linking
(which appears to complete successfully).

This is accomplished by creating a file in /etc/ldconfig.d/ and putting
each of Intel's lib directories on a separate line. Finally, run ldconfig
as root.

Also, isn't libmkl_mc specific to the mic architecture? I don't think it's
necessary to explicitly link against it. Instead, libiomp5, libimf and
libirc are libraries I often find are required.

KR, and good luck!
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130822/ebb12eb6/attachment.html>

From cgohlke at uci.edu  Thu Aug 22 19:45:12 2013
From: cgohlke at uci.edu (Christoph Gohlke)
Date: Thu, 22 Aug 2013 16:45:12 -0700
Subject: [SciPy-Dev] ANN: Scipy 0.13.0 beta 1 release
In-Reply-To: <CABL7CQga-Qkq8_hG1E+_KfpmVjSE-duyRePVcZw_-s-PXay75w@mail.gmail.com>
References: <CABL7CQga-Qkq8_hG1E+_KfpmVjSE-duyRePVcZw_-s-PXay75w@mail.gmail.com>
Message-ID: <5216A288.4060108@uci.edu>

On 8/22/2013 6:12 AM, Ralf Gommers wrote:
> Hi all,
>
> I'm happy to announce the availability of the first beta release of
> Scipy 0.13.0. Please try this beta and report any issues on the
> scipy-dev mailing list.
>
> Source tarballs and release notes can be found at
> https://sourceforge.net/projects/scipy/files/scipy/0.13.0b1/. Windows
> and OS X installers will follow later (we have a minor infrastructure
> issue to solve, and I'm at EuroScipy now).
>
> Cheers,
> Ralf
>
>


Hi Ralf,

I built and tested scipy 0.13.0b1 on Windows 8 with Visual Studio 2008 & 
2010, Intel Studio XE 2013 Fortran and MKL, Python 2.7 & 3.3 (32 & 64 
bit), and numpy 1.7.1.

The `scipy.ndimage._ni_label` extension fails to compile 
<https://github.com/scipy/scipy/pull/2770>.

The win-amd64-py2.7 build passes all tests.

On Python 3 there are 12 errors in `test_wavfile.test_write_roundtrip` 
of the following kind:
```
======================================================================
ERROR: test_wavfile.test_write_roundtrip(False, 8000, dtype('>i8'), 1)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "X:\Python33\lib\site-packages\nose\case.py", line 198, in runTest
     self.test(*self.arg)
   File "X:\Python33\lib\site-packages\scipy\io\tests\test_wavfile.py", 
line 73, in _check_roundtrip
     rate2, data2 = wavfile.read(tmpfile, mmap=mmap)
   File "X:\Python33\lib\site-packages\scipy\io\wavfile.py", line 166, 
in read
     data = _read_data_chunk(fid, comp, noc, bits, mmap=mmap)
   File "X:\Python33\lib\site-packages\scipy\io\wavfile.py", line 71, in 
_read_data_chunk
     data = numpy.fromstring(fid.read(size), dtype=dtype)
ValueError: cannot expose native-only dtype 'q' in non-native byte order 
'>' via buffer interface
```

On 32 bit Python `test_distributions.TestFitMethod.test_fix_fit_beta` 
fails with an error:

```
======================================================================
ERROR: test_distributions.TestFitMethod.test_fix_fit_beta
----------------------------------------------------------------------
Traceback (most recent call last):
   File "X:\Python33-x32\lib\site-packages\nose\case.py", line 198, in 
runTest
     self.test(*self.arg)
   File 
"X:\Python33-x32\lib\site-packages\scipy\stats\tests\test_distributions.py", 
line 928, in test_fix_fit_beta
     assert_raises(ValueError, stats.beta.fit, x, floc=0.5, fscale=1)
   File "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py", line 
1019, in assert_raises
     return nose.tools.assert_raises(*args,**kwargs)
   File "X:\Python33-x32\lib\unittest\case.py", line 570, in assertRaises
     return context.handle('assertRaises', callableObj, args, kwargs)
   File "X:\Python33-x32\lib\unittest\case.py", line 135, in handle
     callable_obj(*args, **kwargs)
   File 
"X:\Python33-x32\lib\site-packages\scipy\stats\distributions.py", line 
2533, in fit
     raise FitSolverError(mesg=mesg)
scipy.stats.distributions.FitSolverError: Solver for the MLE equations 
failed to converge: The iteration is not making good progress, as 
measured by the   improvement from the last ten iterations.
```


Also on 32 bit Python, `test_windows.test_windowfunc_basics` and 
`test_decomp.TestEig.test_singular` sometimes fail:
```
======================================================================
FAIL: test_windows.test_windowfunc_basics
----------------------------------------------------------------------
Traceback (most recent call last):
   File "X:\Python33-x32\lib\site-packages\nose\case.py", line 198, in 
runTest
     self.test(*self.arg)
   File 
"X:\Python33-x32\lib\site-packages\scipy\signal\tests\test_windows.py", 
line 100, in test_windowfunc_basics
     assert_array_almost_equal(w1, w2)
   File "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py", line 
812, in assert_array_almost_equal
     header=('Arrays are not almost equal to %d decimals' % decimal))
   File "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py", line 
645, in assert_array_compare
     raise AssertionError(msg)
AssertionError:
Arrays are not almost equal to 6 decimals

(mismatch 85.71428571428571%)
  x: array([ 0.02221406,  1.        ,  0.32944607,  0.16207939,  0.18485882,
         0.36183308,  0.02298899])
  y: array([ 0.01910267,  1.        ,  0.34644519,  0.09150573,  0.09150573,
         0.17127567,  0.12123497])
		
======================================================================
FAIL: test_decomp.TestEig.test_singular
----------------------------------------------------------------------
Traceback (most recent call last):
   File "X:\Python33-x32\lib\site-packages\nose\case.py", line 198, in 
runTest
     self.test(*self.arg)
   File 
"X:\Python33-x32\lib\site-packages\scipy\linalg\tests\test_decomp.py", 
line 219, in test_singular
     self._check_gen_eig(A, B)
   File 
"X:\Python33-x32\lib\site-packages\scipy\linalg\tests\test_decomp.py", 
line 206, in _check_gen_eig
     err_msg=msg)
   File "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py", line 
812, in assert_array_almost_equal
     header=('Arrays are not almost equal to %d decimals' % decimal))
   File "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py", line 
645, in assert_array_compare
     raise AssertionError(msg)
AssertionError:
Arrays are not almost equal to 6 decimals

array([[22, 34, 31, 31, 17],
        [45, 45, 42, 19, 29],
        [39, 47, 49, 26, 34],
        [27, 31, 26, 21, 15],
        [38, 44, 44, 24, 30]])
array([[13, 26, 25, 17, 24],
        [31, 46, 40, 26, 37],
        [26, 40, 19, 25, 25],
        [16, 25, 27, 14, 23],
        [24, 35, 18, 21, 22]])
(mismatch 50.0%)
  x: array([ -5.90370943e-01+0.j,  -1.54128768e-07+0.j, 
1.54128748e-07+0.j,
          2.00000000e+00+0.j])
  y: array([ -1.32014829e-08+0.j,   1.32014809e-08+0.j, 
1.33224503e+00+0.j,
          2.00000000e+00+0.j])
```

Christoph		


From juanlu001 at gmail.com  Thu Aug 22 20:15:34 2013
From: juanlu001 at gmail.com (Juan Luis Cano)
Date: Fri, 23 Aug 2013 02:15:34 +0200
Subject: [SciPy-Dev] Loss of precision using lsoda f2py interface or ode
	class
Message-ID: <5216A9A6.2030402@gmail.com>

I've been interested in solving some of the bugs of 
scipy.integrate.odeint, and there was some discussion about how to do it 
here

https://github.com/scipy/scipy/issues/2570

However, I've been trying to wrap my head around lsoda.f and its f2py 
interface and things are being very difficult. In lsoda.f there is a 
sample program with the expected output, and I tried to replicate it to 
begin with.

I'm working on this branch:

https://github.com/Juanlu001/scipy/tree/integrate2/scipy/integrate

These tests were added as three files in tests/: a Fortran program, a 
Python program using lsoda.pyf directly and another Python program using 
the ode class. See below for the outputs.

For some reason the three programs show different outputs. The 
difference becomes bigger and bigger with each step.

I'm asking for some advice on how to debug this effectively, because 
lsoda.f is a hell of GO TO and, to be honest, I'm not smart enough to 
stay sane while trying to follow the logic. I already tried f2py 
--debug-capi but I see too much noise and nothing useful. I also tried 
changing the dtypes of the arrays to float, or even dtype('f8') to make 
sure I'm using double precision everywhere, and though the results 
change there are still large errors.

There may be also errors in translating the original from Fortran to 
Python, but I am not able to spot them.

I fear odeint/ode bugs are starting to pile up (gh-1567, gh-1801, 
gh-1976, gh-2515, gh-2570), and as many have suggested in the past a 
rewrite or redesign would be quite helpful.

Maybe someone wants to take this and work a little during the upcoming 
sprint.

Thank you in advance

Juan Luis Cano

--

This is the output of the Fortran program (good):

$ ./test_lsoda
  at t =  4.0000E-01   y =  9.851712E-01  3.386380E-05  1.479493E-02
  at t =  4.0000E+00   y =  9.055333E-01  2.240655E-05  9.444430E-02
  at t =  4.0000E+01   y =  7.158403E-01  9.186334E-06  2.841505E-01
  at t =  4.0000E+02   y =  4.505250E-01  3.222964E-06  5.494717E-01
  at t =  4.0000E+03   y =  1.831976E-01  8.941773E-07  8.168015E-01
  at t =  4.0000E+04   y =  3.898729E-02  1.621940E-07  9.610125E-01
  at t =  4.0000E+05   y =  4.936362E-03  1.984221E-08  9.950636E-01
  at t =  4.0000E+06   y =  5.161833E-04  2.065787E-09  9.994838E-01
  at t =  4.0000E+07   y =  5.179804E-05  2.072027E-10  9.999482E-01
  at t =  4.0000E+08   y =  5.283679E-06  2.113483E-11  9.999947E-01
  at t =  4.0000E+09   y =  4.658659E-07  1.863464E-12  9.999995E-01
  at t =  4.0000E+10   y =  1.431333E-08  5.725337E-14  1.000000E+00

  no. steps = 361  no. f-s = 693  no. j-s =  64
  method last used = 2   last switch was at t =  6.0092E-03

This is the output of the Python program using the Fortran interface 
directly:

$ python test_lsoda.py
At t = 4.0000e-01   y = [  9.84128935e-01   3.62239836e-05 1.58348410e-02]
At t = 4.0000e+00   y = [  8.52155561e-01   3.37055417e-05 1.47810734e-01]
At t = 4.0000e+01   y = [  2.02104281e-01   1.64041139e-05 7.97879315e-01]
At t = 4.0000e+02   y = [  1.06122917e-06   2.44976665e-08 9.99998914e-01]
At t = 4.0000e+03   y = [  6.31790031e-09   2.50796401e-10 9.99999993e-01]
At t = 4.0000e+04   y = [  6.31740542e-10   2.52488308e-11 9.99999999e-01]
At t = 4.0000e+05   y = [  4.98669737e-10   1.99540660e-11 9.99999999e-01]
At t = 4.0000e+06   y = [ -7.52067881e-10  -3.00837491e-11 1.00000000e+00]
At t = 4.0000e+07   y = [ -5.25052749e-10  -2.10020683e-11 1.00000000e+00]
At t = 4.0000e+08   y = [  5.77160490e-10   2.30864142e-11 9.99999999e-01]
At t = 4.0000e+09   y = [ -3.33188378e-09  -1.33275352e-10 1.00000000e+00]
At t = 4.0000e+10   y = [ -2.20370350e-09  -8.81481397e-11 1.00000000e+00]
No. steps = 251, no. f-s = 614, no. j-s = 72
method last used = 2, last switch at t = 6.0089e-03

(note: the last two lines are garbage with current SciPy master - see 
https://github.com/Juanlu001/scipy/commit/e11e978232c14b65f800922e7390b08bd8298734)

And this is the output of the program using the ode class in 
scipy.integrate:

$ python test_lsoda2.py
At t = 4.0000e-01   y = [  9.84127434e-01   3.62239556e-05 1.58363421e-02]
At t = 4.0000e+00   y = [  8.52153740e-01   3.37055100e-05 1.47812555e-01]
At t = 4.0000e+01   y = [  2.02145824e-01   1.64042718e-05 7.97837771e-01]
At t = 4.0000e+02   y = [  1.05528994e-06   2.44971521e-08 9.99998920e-01]
At t = 4.0000e+03   y = [  6.39513550e-09   2.53944135e-10 9.99999993e-01]
At t = 4.0000e+04   y = [  5.53276503e-10   2.21169099e-11 9.99999999e-01]
At t = 4.0000e+05   y = [  5.47740551e-11   2.19082310e-12 1.00000000e+00]
At t = 4.0000e+06   y = [  6.03428535e-12   2.41369408e-13 1.00000000e+00]
At t = 4.0000e+07   y = [  7.15628192e-13   2.86251003e-14 1.00000000e+00]
["Excess work done" errors"]




From warren.weckesser at gmail.com  Thu Aug 22 20:55:39 2013
From: warren.weckesser at gmail.com (Warren Weckesser)
Date: Thu, 22 Aug 2013 20:55:39 -0400
Subject: [SciPy-Dev] ANN: Scipy 0.13.0 beta 1 release
In-Reply-To: <5216A288.4060108@uci.edu>
References: <CABL7CQga-Qkq8_hG1E+_KfpmVjSE-duyRePVcZw_-s-PXay75w@mail.gmail.com>
	<5216A288.4060108@uci.edu>
Message-ID: <CAGzF1udbdSRONHAETtg0e+Wz2YHtprbkGFu=foHX8WLm=Ew5GQ@mail.gmail.com>

On 8/22/13, Christoph Gohlke <cgohlke at uci.edu> wrote:
> On 8/22/2013 6:12 AM, Ralf Gommers wrote:
>> Hi all,
>>
>> I'm happy to announce the availability of the first beta release of
>> Scipy 0.13.0. Please try this beta and report any issues on the
>> scipy-dev mailing list.
>>
>> Source tarballs and release notes can be found at
>> https://sourceforge.net/projects/scipy/files/scipy/0.13.0b1/. Windows
>> and OS X installers will follow later (we have a minor infrastructure
>> issue to solve, and I'm at EuroScipy now).
>>
>> Cheers,
>> Ralf
>>
>>
>
>
> Hi Ralf,
>
> I built and tested scipy 0.13.0b1 on Windows 8 with Visual Studio 2008 &
> 2010, Intel Studio XE 2013 Fortran and MKL, Python 2.7 & 3.3 (32 & 64
> bit), and numpy 1.7.1.
>
> The `scipy.ndimage._ni_label` extension fails to compile
> <https://github.com/scipy/scipy/pull/2770>.
>
> The win-amd64-py2.7 build passes all tests.
>
> On Python 3 there are 12 errors in `test_wavfile.test_write_roundtrip`
> of the following kind:
> ```
> ======================================================================
> ERROR: test_wavfile.test_write_roundtrip(False, 8000, dtype('>i8'), 1)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>    File "X:\Python33\lib\site-packages\nose\case.py", line 198, in runTest
>      self.test(*self.arg)
>    File "X:\Python33\lib\site-packages\scipy\io\tests\test_wavfile.py",
> line 73, in _check_roundtrip
>      rate2, data2 = wavfile.read(tmpfile, mmap=mmap)
>    File "X:\Python33\lib\site-packages\scipy\io\wavfile.py", line 166,
> in read
>      data = _read_data_chunk(fid, comp, noc, bits, mmap=mmap)
>    File "X:\Python33\lib\site-packages\scipy\io\wavfile.py", line 71, in
> _read_data_chunk
>      data = numpy.fromstring(fid.read(size), dtype=dtype)
> ValueError: cannot expose native-only dtype 'q' in non-native byte order
> '>' via buffer interface
> ```
>
> On 32 bit Python `test_distributions.TestFitMethod.test_fix_fit_beta`
> fails with an error:
>
> ```
> ======================================================================
> ERROR: test_distributions.TestFitMethod.test_fix_fit_beta
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>    File "X:\Python33-x32\lib\site-packages\nose\case.py", line 198, in
> runTest
>      self.test(*self.arg)
>    File
> "X:\Python33-x32\lib\site-packages\scipy\stats\tests\test_distributions.py",
>
> line 928, in test_fix_fit_beta
>      assert_raises(ValueError, stats.beta.fit, x, floc=0.5, fscale=1)
>    File "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py", line
> 1019, in assert_raises
>      return nose.tools.assert_raises(*args,**kwargs)
>    File "X:\Python33-x32\lib\unittest\case.py", line 570, in assertRaises
>      return context.handle('assertRaises', callableObj, args, kwargs)
>    File "X:\Python33-x32\lib\unittest\case.py", line 135, in handle
>      callable_obj(*args, **kwargs)
>    File
> "X:\Python33-x32\lib\site-packages\scipy\stats\distributions.py", line
> 2533, in fit
>      raise FitSolverError(mesg=mesg)
> scipy.stats.distributions.FitSolverError: Solver for the MLE equations
> failed to converge: The iteration is not making good progress, as
> measured by the   improvement from the last ten iterations.
> ```
>


Thanks, Christoph.

I'll look into this one.  I created an issue for it here:
https://github.com/scipy/scipy/issues/2771

Warren


>
> Also on 32 bit Python, `test_windows.test_windowfunc_basics` and
> `test_decomp.TestEig.test_singular` sometimes fail:
> ```
> ======================================================================
> FAIL: test_windows.test_windowfunc_basics
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>    File "X:\Python33-x32\lib\site-packages\nose\case.py", line 198, in
> runTest
>      self.test(*self.arg)
>    File
> "X:\Python33-x32\lib\site-packages\scipy\signal\tests\test_windows.py",
> line 100, in test_windowfunc_basics
>      assert_array_almost_equal(w1, w2)
>    File "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py", line
> 812, in assert_array_almost_equal
>      header=('Arrays are not almost equal to %d decimals' % decimal))
>    File "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py", line
> 645, in assert_array_compare
>      raise AssertionError(msg)
> AssertionError:
> Arrays are not almost equal to 6 decimals
>
> (mismatch 85.71428571428571%)
>   x: array([ 0.02221406,  1.        ,  0.32944607,  0.16207939,
> 0.18485882,
>          0.36183308,  0.02298899])
>   y: array([ 0.01910267,  1.        ,  0.34644519,  0.09150573,
> 0.09150573,
>          0.17127567,  0.12123497])
> 		
> ======================================================================
> FAIL: test_decomp.TestEig.test_singular
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>    File "X:\Python33-x32\lib\site-packages\nose\case.py", line 198, in
> runTest
>      self.test(*self.arg)
>    File
> "X:\Python33-x32\lib\site-packages\scipy\linalg\tests\test_decomp.py",
> line 219, in test_singular
>      self._check_gen_eig(A, B)
>    File
> "X:\Python33-x32\lib\site-packages\scipy\linalg\tests\test_decomp.py",
> line 206, in _check_gen_eig
>      err_msg=msg)
>    File "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py", line
> 812, in assert_array_almost_equal
>      header=('Arrays are not almost equal to %d decimals' % decimal))
>    File "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py", line
> 645, in assert_array_compare
>      raise AssertionError(msg)
> AssertionError:
> Arrays are not almost equal to 6 decimals
>
> array([[22, 34, 31, 31, 17],
>         [45, 45, 42, 19, 29],
>         [39, 47, 49, 26, 34],
>         [27, 31, 26, 21, 15],
>         [38, 44, 44, 24, 30]])
> array([[13, 26, 25, 17, 24],
>         [31, 46, 40, 26, 37],
>         [26, 40, 19, 25, 25],
>         [16, 25, 27, 14, 23],
>         [24, 35, 18, 21, 22]])
> (mismatch 50.0%)
>   x: array([ -5.90370943e-01+0.j,  -1.54128768e-07+0.j,
> 1.54128748e-07+0.j,
>           2.00000000e+00+0.j])
>   y: array([ -1.32014829e-08+0.j,   1.32014809e-08+0.j,
> 1.33224503e+00+0.j,
>           2.00000000e+00+0.j])
> ```
>
> Christoph		
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From warren.weckesser at gmail.com  Thu Aug 22 21:03:06 2013
From: warren.weckesser at gmail.com (Warren Weckesser)
Date: Thu, 22 Aug 2013 21:03:06 -0400
Subject: [SciPy-Dev] Loss of precision using lsoda f2py interface or ode
	class
In-Reply-To: <5216A9A6.2030402@gmail.com>
References: <5216A9A6.2030402@gmail.com>
Message-ID: <CAGzF1ucA6E+ciav05fH+8mAyC5un9PutrEK2ipL+kiVLO9QyhA@mail.gmail.com>

On 8/22/13, Juan Luis Cano <juanlu001 at gmail.com> wrote:
> I've been interested in solving some of the bugs of
> scipy.integrate.odeint, and there was some discussion about how to do it
> here
>
> https://github.com/scipy/scipy/issues/2570
>
> However, I've been trying to wrap my head around lsoda.f and its f2py
> interface and things are being very difficult. In lsoda.f there is a
> sample program with the expected output, and I tried to replicate it to
> begin with.
>
> I'm working on this branch:
>
> https://github.com/Juanlu001/scipy/tree/integrate2/scipy/integrate
>

Luis, thanks for working on this.

In this line:
    https://github.com/Juanlu001/scipy/blob/integrate2/scipy/integrate/tests/test_lsoda2.py#L6
the coefficient of `y[1]*y[2]` should be `1.0e4` (not `1.0`).

Warren


> These tests were added as three files in tests/: a Fortran program, a
> Python program using lsoda.pyf directly and another Python program using
> the ode class. See below for the outputs.
>
> For some reason the three programs show different outputs. The
> difference becomes bigger and bigger with each step.
>
> I'm asking for some advice on how to debug this effectively, because
> lsoda.f is a hell of GO TO and, to be honest, I'm not smart enough to
> stay sane while trying to follow the logic. I already tried f2py
> --debug-capi but I see too much noise and nothing useful. I also tried
> changing the dtypes of the arrays to float, or even dtype('f8') to make
> sure I'm using double precision everywhere, and though the results
> change there are still large errors.
>
> There may be also errors in translating the original from Fortran to
> Python, but I am not able to spot them.
>
> I fear odeint/ode bugs are starting to pile up (gh-1567, gh-1801,
> gh-1976, gh-2515, gh-2570), and as many have suggested in the past a
> rewrite or redesign would be quite helpful.
>
> Maybe someone wants to take this and work a little during the upcoming
> sprint.
>
> Thank you in advance
>
> Juan Luis Cano
>
> --
>
> This is the output of the Fortran program (good):
>
> $ ./test_lsoda
>   at t =  4.0000E-01   y =  9.851712E-01  3.386380E-05  1.479493E-02
>   at t =  4.0000E+00   y =  9.055333E-01  2.240655E-05  9.444430E-02
>   at t =  4.0000E+01   y =  7.158403E-01  9.186334E-06  2.841505E-01
>   at t =  4.0000E+02   y =  4.505250E-01  3.222964E-06  5.494717E-01
>   at t =  4.0000E+03   y =  1.831976E-01  8.941773E-07  8.168015E-01
>   at t =  4.0000E+04   y =  3.898729E-02  1.621940E-07  9.610125E-01
>   at t =  4.0000E+05   y =  4.936362E-03  1.984221E-08  9.950636E-01
>   at t =  4.0000E+06   y =  5.161833E-04  2.065787E-09  9.994838E-01
>   at t =  4.0000E+07   y =  5.179804E-05  2.072027E-10  9.999482E-01
>   at t =  4.0000E+08   y =  5.283679E-06  2.113483E-11  9.999947E-01
>   at t =  4.0000E+09   y =  4.658659E-07  1.863464E-12  9.999995E-01
>   at t =  4.0000E+10   y =  1.431333E-08  5.725337E-14  1.000000E+00
>
>   no. steps = 361  no. f-s = 693  no. j-s =  64
>   method last used = 2   last switch was at t =  6.0092E-03
>
> This is the output of the Python program using the Fortran interface
> directly:
>
> $ python test_lsoda.py
> At t = 4.0000e-01   y = [  9.84128935e-01   3.62239836e-05 1.58348410e-02]
> At t = 4.0000e+00   y = [  8.52155561e-01   3.37055417e-05 1.47810734e-01]
> At t = 4.0000e+01   y = [  2.02104281e-01   1.64041139e-05 7.97879315e-01]
> At t = 4.0000e+02   y = [  1.06122917e-06   2.44976665e-08 9.99998914e-01]
> At t = 4.0000e+03   y = [  6.31790031e-09   2.50796401e-10 9.99999993e-01]
> At t = 4.0000e+04   y = [  6.31740542e-10   2.52488308e-11 9.99999999e-01]
> At t = 4.0000e+05   y = [  4.98669737e-10   1.99540660e-11 9.99999999e-01]
> At t = 4.0000e+06   y = [ -7.52067881e-10  -3.00837491e-11 1.00000000e+00]
> At t = 4.0000e+07   y = [ -5.25052749e-10  -2.10020683e-11 1.00000000e+00]
> At t = 4.0000e+08   y = [  5.77160490e-10   2.30864142e-11 9.99999999e-01]
> At t = 4.0000e+09   y = [ -3.33188378e-09  -1.33275352e-10 1.00000000e+00]
> At t = 4.0000e+10   y = [ -2.20370350e-09  -8.81481397e-11 1.00000000e+00]
> No. steps = 251, no. f-s = 614, no. j-s = 72
> method last used = 2, last switch at t = 6.0089e-03
>
> (note: the last two lines are garbage with current SciPy master - see
> https://github.com/Juanlu001/scipy/commit/e11e978232c14b65f800922e7390b08bd8298734)
>
> And this is the output of the program using the ode class in
> scipy.integrate:
>
> $ python test_lsoda2.py
> At t = 4.0000e-01   y = [  9.84127434e-01   3.62239556e-05 1.58363421e-02]
> At t = 4.0000e+00   y = [  8.52153740e-01   3.37055100e-05 1.47812555e-01]
> At t = 4.0000e+01   y = [  2.02145824e-01   1.64042718e-05 7.97837771e-01]
> At t = 4.0000e+02   y = [  1.05528994e-06   2.44971521e-08 9.99998920e-01]
> At t = 4.0000e+03   y = [  6.39513550e-09   2.53944135e-10 9.99999993e-01]
> At t = 4.0000e+04   y = [  5.53276503e-10   2.21169099e-11 9.99999999e-01]
> At t = 4.0000e+05   y = [  5.47740551e-11   2.19082310e-12 1.00000000e+00]
> At t = 4.0000e+06   y = [  6.03428535e-12   2.41369408e-13 1.00000000e+00]
> At t = 4.0000e+07   y = [  7.15628192e-13   2.86251003e-14 1.00000000e+00]
> ["Excess work done" errors"]
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From warren.weckesser at gmail.com  Thu Aug 22 21:10:41 2013
From: warren.weckesser at gmail.com (Warren Weckesser)
Date: Thu, 22 Aug 2013 21:10:41 -0400
Subject: [SciPy-Dev] Loss of precision using lsoda f2py interface or ode
	class
In-Reply-To: <CAGzF1ucA6E+ciav05fH+8mAyC5un9PutrEK2ipL+kiVLO9QyhA@mail.gmail.com>
References: <5216A9A6.2030402@gmail.com>
	<CAGzF1ucA6E+ciav05fH+8mAyC5un9PutrEK2ipL+kiVLO9QyhA@mail.gmail.com>
Message-ID: <CAGzF1uf1pRBK+eZa5rwTGGmVQCBiu_UA+Jk67vgjEk2RB_3+_A@mail.gmail.com>

On 8/22/13, Warren Weckesser <warren.weckesser at gmail.com> wrote:
> On 8/22/13, Juan Luis Cano <juanlu001 at gmail.com> wrote:
>> I've been interested in solving some of the bugs of
>> scipy.integrate.odeint, and there was some discussion about how to do it
>> here
>>
>> https://github.com/scipy/scipy/issues/2570
>>
>> However, I've been trying to wrap my head around lsoda.f and its f2py
>> interface and things are being very difficult. In lsoda.f there is a
>> sample program with the expected output, and I tried to replicate it to
>> begin with.
>>
>> I'm working on this branch:
>>
>> https://github.com/Juanlu001/scipy/tree/integrate2/scipy/integrate
>>
>
> Luis, thanks for working on this.
>

*Juan*, that is--sorry.

The other python file (test_lsoda.py) also needs the correction to the
coefficient.

Warren

> In this line:
>
> https://github.com/Juanlu001/scipy/blob/integrate2/scipy/integrate/tests/test_lsoda2.py#L6
> the coefficient of `y[1]*y[2]` should be `1.0e4` (not `1.0`).
>
> Warren
>
>
>> These tests were added as three files in tests/: a Fortran program, a
>> Python program using lsoda.pyf directly and another Python program using
>> the ode class. See below for the outputs.
>>
>> For some reason the three programs show different outputs. The
>> difference becomes bigger and bigger with each step.
>>
>> I'm asking for some advice on how to debug this effectively, because
>> lsoda.f is a hell of GO TO and, to be honest, I'm not smart enough to
>> stay sane while trying to follow the logic. I already tried f2py
>> --debug-capi but I see too much noise and nothing useful. I also tried
>> changing the dtypes of the arrays to float, or even dtype('f8') to make
>> sure I'm using double precision everywhere, and though the results
>> change there are still large errors.
>>
>> There may be also errors in translating the original from Fortran to
>> Python, but I am not able to spot them.
>>
>> I fear odeint/ode bugs are starting to pile up (gh-1567, gh-1801,
>> gh-1976, gh-2515, gh-2570), and as many have suggested in the past a
>> rewrite or redesign would be quite helpful.
>>
>> Maybe someone wants to take this and work a little during the upcoming
>> sprint.
>>
>> Thank you in advance
>>
>> Juan Luis Cano
>>
>> --
>>
>> This is the output of the Fortran program (good):
>>
>> $ ./test_lsoda
>>   at t =  4.0000E-01   y =  9.851712E-01  3.386380E-05  1.479493E-02
>>   at t =  4.0000E+00   y =  9.055333E-01  2.240655E-05  9.444430E-02
>>   at t =  4.0000E+01   y =  7.158403E-01  9.186334E-06  2.841505E-01
>>   at t =  4.0000E+02   y =  4.505250E-01  3.222964E-06  5.494717E-01
>>   at t =  4.0000E+03   y =  1.831976E-01  8.941773E-07  8.168015E-01
>>   at t =  4.0000E+04   y =  3.898729E-02  1.621940E-07  9.610125E-01
>>   at t =  4.0000E+05   y =  4.936362E-03  1.984221E-08  9.950636E-01
>>   at t =  4.0000E+06   y =  5.161833E-04  2.065787E-09  9.994838E-01
>>   at t =  4.0000E+07   y =  5.179804E-05  2.072027E-10  9.999482E-01
>>   at t =  4.0000E+08   y =  5.283679E-06  2.113483E-11  9.999947E-01
>>   at t =  4.0000E+09   y =  4.658659E-07  1.863464E-12  9.999995E-01
>>   at t =  4.0000E+10   y =  1.431333E-08  5.725337E-14  1.000000E+00
>>
>>   no. steps = 361  no. f-s = 693  no. j-s =  64
>>   method last used = 2   last switch was at t =  6.0092E-03
>>
>> This is the output of the Python program using the Fortran interface
>> directly:
>>
>> $ python test_lsoda.py
>> At t = 4.0000e-01   y = [  9.84128935e-01   3.62239836e-05
>> 1.58348410e-02]
>> At t = 4.0000e+00   y = [  8.52155561e-01   3.37055417e-05
>> 1.47810734e-01]
>> At t = 4.0000e+01   y = [  2.02104281e-01   1.64041139e-05
>> 7.97879315e-01]
>> At t = 4.0000e+02   y = [  1.06122917e-06   2.44976665e-08
>> 9.99998914e-01]
>> At t = 4.0000e+03   y = [  6.31790031e-09   2.50796401e-10
>> 9.99999993e-01]
>> At t = 4.0000e+04   y = [  6.31740542e-10   2.52488308e-11
>> 9.99999999e-01]
>> At t = 4.0000e+05   y = [  4.98669737e-10   1.99540660e-11
>> 9.99999999e-01]
>> At t = 4.0000e+06   y = [ -7.52067881e-10  -3.00837491e-11
>> 1.00000000e+00]
>> At t = 4.0000e+07   y = [ -5.25052749e-10  -2.10020683e-11
>> 1.00000000e+00]
>> At t = 4.0000e+08   y = [  5.77160490e-10   2.30864142e-11
>> 9.99999999e-01]
>> At t = 4.0000e+09   y = [ -3.33188378e-09  -1.33275352e-10
>> 1.00000000e+00]
>> At t = 4.0000e+10   y = [ -2.20370350e-09  -8.81481397e-11
>> 1.00000000e+00]
>> No. steps = 251, no. f-s = 614, no. j-s = 72
>> method last used = 2, last switch at t = 6.0089e-03
>>
>> (note: the last two lines are garbage with current SciPy master - see
>> https://github.com/Juanlu001/scipy/commit/e11e978232c14b65f800922e7390b08bd8298734)
>>
>> And this is the output of the program using the ode class in
>> scipy.integrate:
>>
>> $ python test_lsoda2.py
>> At t = 4.0000e-01   y = [  9.84127434e-01   3.62239556e-05
>> 1.58363421e-02]
>> At t = 4.0000e+00   y = [  8.52153740e-01   3.37055100e-05
>> 1.47812555e-01]
>> At t = 4.0000e+01   y = [  2.02145824e-01   1.64042718e-05
>> 7.97837771e-01]
>> At t = 4.0000e+02   y = [  1.05528994e-06   2.44971521e-08
>> 9.99998920e-01]
>> At t = 4.0000e+03   y = [  6.39513550e-09   2.53944135e-10
>> 9.99999993e-01]
>> At t = 4.0000e+04   y = [  5.53276503e-10   2.21169099e-11
>> 9.99999999e-01]
>> At t = 4.0000e+05   y = [  5.47740551e-11   2.19082310e-12
>> 1.00000000e+00]
>> At t = 4.0000e+06   y = [  6.03428535e-12   2.41369408e-13
>> 1.00000000e+00]
>> At t = 4.0000e+07   y = [  7.15628192e-13   2.86251003e-14
>> 1.00000000e+00]
>> ["Excess work done" errors"]
>>
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>


From juanlu001 at gmail.com  Fri Aug 23 02:42:20 2013
From: juanlu001 at gmail.com (Juan Luis Cano)
Date: Fri, 23 Aug 2013 08:42:20 +0200
Subject: [SciPy-Dev] Loss of precision using lsoda f2py interface or ode
 class
In-Reply-To: <CAGzF1uf1pRBK+eZa5rwTGGmVQCBiu_UA+Jk67vgjEk2RB_3+_A@mail.gmail.com>
References: <5216A9A6.2030402@gmail.com>
	<CAGzF1ucA6E+ciav05fH+8mAyC5un9PutrEK2ipL+kiVLO9QyhA@mail.gmail.com>
	<CAGzF1uf1pRBK+eZa5rwTGGmVQCBiu_UA+Jk67vgjEk2RB_3+_A@mail.gmail.com>
Message-ID: <5217044C.5070906@gmail.com>

On 08/23/2013 03:10 AM, Warren Weckesser wrote:
> On 8/22/13, Warren Weckesser <warren.weckesser at gmail.com> wrote:
>> On 8/22/13, Juan Luis Cano <juanlu001 at gmail.com> wrote:
>>> I've been interested in solving some of the bugs of
>>> scipy.integrate.odeint, and there was some discussion about how to do it
>>> here
>>>
>>> https://github.com/scipy/scipy/issues/2570
>>>
>>> However, I've been trying to wrap my head around lsoda.f and its f2py
>>> interface and things are being very difficult. In lsoda.f there is a
>>> sample program with the expected output, and I tried to replicate it to
>>> begin with.
>>>
>>> I'm working on this branch:
>>>
>>> https://github.com/Juanlu001/scipy/tree/integrate2/scipy/integrate
>>>
>> Luis, thanks for working on this.
>>
> *Juan*, that is--sorry.
>
> The other python file (test_lsoda.py) also needs the correction to the
> coefficient.
>
> Warren

Warren, thank you so much for pointing that out - I should never code at 
2 AM. Now test_lsoda.py produces the correct output, which suggests I 
have to tune the relative and absolute error in test_lsoda2.py.

-- Juan Luis, Juanlu or Juan is perfect :)

Regards

Juan Luis


From juanlu001 at gmail.com  Fri Aug 23 03:10:29 2013
From: juanlu001 at gmail.com (Juan Luis Cano)
Date: Fri, 23 Aug 2013 09:10:29 +0200
Subject: [SciPy-Dev] working on integrate.odeint (was: Loss of precision
 using lsoda...)
In-Reply-To: <5217044C.5070906@gmail.com>
References: <5216A9A6.2030402@gmail.com>
	<CAGzF1ucA6E+ciav05fH+8mAyC5un9PutrEK2ipL+kiVLO9QyhA@mail.gmail.com>
	<CAGzF1uf1pRBK+eZa5rwTGGmVQCBiu_UA+Jk67vgjEk2RB_3+_A@mail.gmail.com>
	<5217044C.5070906@gmail.com>
Message-ID: <52170AE5.3040707@gmail.com>

On 08/23/2013 08:42 AM, Juan Luis Cano wrote:
> On 08/23/2013 03:10 AM, Warren Weckesser wrote:
>> The other python file (test_lsoda.py) also needs the correction to the
>> coefficient.
>>
>> Warren
>
> Warren, thank you so much for pointing that out - I should never code 
> at 2 AM. Now test_lsoda.py produces the correct output, which suggests 
> I have to tune the relative and absolute error in test_lsoda2.py.

Right, this was exactly the problem. Now the three tests produce the 
same output and I understand much better the interface. In the branch I 
pointed out before I wrote some issues as a to-do list and I plan 
working on fixing some integrate.odeint problems in the following 
months, when time and circumstances allow for that.

Juan Luis


From benny.malengier at gmail.com  Fri Aug 23 03:32:30 2013
From: benny.malengier at gmail.com (Benny Malengier)
Date: Fri, 23 Aug 2013 09:32:30 +0200
Subject: [SciPy-Dev] working on integrate.odeint (was: Loss of precision
 using lsoda...)
In-Reply-To: <52170AE5.3040707@gmail.com>
References: <5216A9A6.2030402@gmail.com>
	<CAGzF1ucA6E+ciav05fH+8mAyC5un9PutrEK2ipL+kiVLO9QyhA@mail.gmail.com>
	<CAGzF1uf1pRBK+eZa5rwTGGmVQCBiu_UA+Jk67vgjEk2RB_3+_A@mail.gmail.com>
	<5217044C.5070906@gmail.com> <52170AE5.3040707@gmail.com>
Message-ID: <CAOyNq8oR95u092NhN4bdR+MFP1PtV2xvD6gatHFqLgqG98BZew@mail.gmail.com>

2013/8/23 Juan Luis Cano <juanlu001 at gmail.com>

> On 08/23/2013 08:42 AM, Juan Luis Cano wrote:
> > On 08/23/2013 03:10 AM, Warren Weckesser wrote:
> >> The other python file (test_lsoda.py) also needs the correction to the
> >> coefficient.
> >>
> >> Warren
> >
> > Warren, thank you so much for pointing that out - I should never code
> > at 2 AM. Now test_lsoda.py produces the correct output, which suggests
> > I have to tune the relative and absolute error in test_lsoda2.py.
>
> Right, this was exactly the problem. Now the three tests produce the
> same output and I understand much better the interface. In the branch I
> pointed out before I wrote some issues as a to-do list and I plan
> working on fixing some integrate.odeint problems in the following
> months, when time and circumstances allow for that.
>

It is nice to clean up odeint or lsoda, but those are really deprecated
functions, replaced by sundials many years ago by Alan Hindmarsh (
http://history.siam.org/oralhistories/hindmarsh.htm). As I mentioned before
on this list, best would be to deprecate and replace by the modern version
which still sees bug fixes (
http://computation.llnl.gov/casc/sundials/main.html).

There are 3 python interfaces to sundials, one of which by me and a
collaborator: https://github.com/bmcage/odes
The other 2 are readily found on the internet, and expose even more of the
functionality.

Benny


>
> Juan Luis
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130823/84166fde/attachment.html>

From juanlu001 at gmail.com  Fri Aug 23 05:00:43 2013
From: juanlu001 at gmail.com (Juan Luis Cano)
Date: Fri, 23 Aug 2013 11:00:43 +0200
Subject: [SciPy-Dev] working on integrate.odeint
In-Reply-To: <CAOyNq8oR95u092NhN4bdR+MFP1PtV2xvD6gatHFqLgqG98BZew@mail.gmail.com>
References: <5216A9A6.2030402@gmail.com>
	<CAGzF1ucA6E+ciav05fH+8mAyC5un9PutrEK2ipL+kiVLO9QyhA@mail.gmail.com>
	<CAGzF1uf1pRBK+eZa5rwTGGmVQCBiu_UA+Jk67vgjEk2RB_3+_A@mail.gmail.com>
	<5217044C.5070906@gmail.com> <52170AE5.3040707@gmail.com>
	<CAOyNq8oR95u092NhN4bdR+MFP1PtV2xvD6gatHFqLgqG98BZew@mail.gmail.com>
Message-ID: <521724BB.5000808@gmail.com>

On 08/23/2013 09:32 AM, Benny Malengier wrote:
>
>
>
> 2013/8/23 Juan Luis Cano <juanlu001 at gmail.com 
> <mailto:juanlu001 at gmail.com>>
>
>     On 08/23/2013 08:42 AM, Juan Luis Cano wrote:
>     > On 08/23/2013 03:10 AM, Warren Weckesser wrote:
>     >> The other python file (test_lsoda.py) also needs the correction
>     to the
>     >> coefficient.
>     >>
>     >> Warren
>     >
>     > Warren, thank you so much for pointing that out - I should never
>     code
>     > at 2 AM. Now test_lsoda.py produces the correct output, which
>     suggests
>     > I have to tune the relative and absolute error in test_lsoda2.py.
>
>     Right, this was exactly the problem. Now the three tests produce the
>     same output and I understand much better the interface. In the
>     branch I
>     pointed out before I wrote some issues as a to-do list and I plan
>     working on fixing some integrate.odeint problems in the following
>     months, when time and circumstances allow for that.
>
>
> It is nice to clean up odeint or lsoda, but those are really 
> deprecated functions, replaced by sundials many years ago by Alan 
> Hindmarsh (http://history.siam.org/oralhistories/hindmarsh.htm). As I 
> mentioned before on this list, best would be to deprecate and replace 
> by the modern version which still sees bug fixes 
> (http://computation.llnl.gov/casc/sundials/main.html).
>
> There are 3 python interfaces to sundials, one of which by me and a 
> collaborator: https://github.com/bmcage/odes
> The other 2 are readily found on the internet, and expose even more of 
> the functionality.

Well, I am farily new to contributing to SciPy so I missed those past 
conversations, but I did some googling and found that you created 
scikits.odes. I don't know if there were some conclusions about 
ode/odeint in SciPy, and though I find value in replacing old code with 
new one, I cannot tell if odepack is deprecated or not (deprecated for 
who?) and at least with these little steps I can fix the existing 
problems without disturbing much while trying to find a new 
ground-breaking solution. Unless a new discussion raises and it's 
decided that we can, say, incorporate scikits.odes into SciPy, or any 
other Python interface to some modern DE solvers. I don't have a strong 
opinion on this, I just know that odeint has some flaws right now and 
want to scratch my itch.

Juan Luis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130823/13122662/attachment.html>

From benny.malengier at gmail.com  Fri Aug 23 06:11:11 2013
From: benny.malengier at gmail.com (Benny Malengier)
Date: Fri, 23 Aug 2013 12:11:11 +0200
Subject: [SciPy-Dev] working on integrate.odeint
In-Reply-To: <521724BB.5000808@gmail.com>
References: <5216A9A6.2030402@gmail.com>
	<CAGzF1ucA6E+ciav05fH+8mAyC5un9PutrEK2ipL+kiVLO9QyhA@mail.gmail.com>
	<CAGzF1uf1pRBK+eZa5rwTGGmVQCBiu_UA+Jk67vgjEk2RB_3+_A@mail.gmail.com>
	<5217044C.5070906@gmail.com> <52170AE5.3040707@gmail.com>
	<CAOyNq8oR95u092NhN4bdR+MFP1PtV2xvD6gatHFqLgqG98BZew@mail.gmail.com>
	<521724BB.5000808@gmail.com>
Message-ID: <CAOyNq8rjHBvGNdhZBCtN1HVvqPUq4hfT6Umq9EjzBsLcHjNisw@mail.gmail.com>

2013/8/23 Juan Luis Cano <juanlu001 at gmail.com>

>  On 08/23/2013 09:32 AM, Benny Malengier wrote:
>
>
>
>
> 2013/8/23 Juan Luis Cano <juanlu001 at gmail.com>
>
>> On 08/23/2013 08:42 AM, Juan Luis Cano wrote:
>> > On 08/23/2013 03:10 AM, Warren Weckesser wrote:
>> >> The other python file (test_lsoda.py) also needs the correction to the
>> >> coefficient.
>> >>
>> >> Warren
>> >
>> > Warren, thank you so much for pointing that out - I should never code
>> > at 2 AM. Now test_lsoda.py produces the correct output, which suggests
>> > I have to tune the relative and absolute error in test_lsoda2.py.
>>
>> Right, this was exactly the problem. Now the three tests produce the
>> same output and I understand much better the interface. In the branch I
>> pointed out before I wrote some issues as a to-do list and I plan
>> working on fixing some integrate.odeint problems in the following
>> months, when time and circumstances allow for that.
>>
>
>  It is nice to clean up odeint or lsoda, but those are really deprecated
> functions, replaced by sundials many years ago by Alan Hindmarsh (
> http://history.siam.org/oralhistories/hindmarsh.htm). As I mentioned
> before on this list, best would be to deprecate and replace by the modern
> version which still sees bug fixes (
> http://computation.llnl.gov/casc/sundials/main.html).
>
>  There are 3 python interfaces to sundials, one of which by me and a
> collaborator: https://github.com/bmcage/odes
>  The other 2 are readily found on the internet, and expose even more of
> the functionality.
>
>
> Well, I am farily new to contributing to SciPy so I missed those past
> conversations, but I did some googling and found that you created
> scikits.odes. I don't know if there were some conclusions about ode/odeint
> in SciPy, and though I find value in replacing old code with new one, I
> cannot tell if odepack is deprecated or not (deprecated for who?) and at
> least with these little steps I can fix the existing problems without
> disturbing much while trying to find a new ground-breaking solution. Unless
> a new discussion raises and it's decided that we can, say, incorporate
> scikits.odes into SciPy, or any other Python interface to some modern DE
> solvers. I don't have a strong opinion on this, I just know that odeint has
> some flaws right now and want to scratch my itch.
>

Well, I'm ok with that.

odepack, lsoda, vode, ... are deprecated in the sense that the authors
created the sundials package with more versatile and more tuned code. I'm
aware of yearly bug fixes to sundials, but not to the netlib stored old
fortran methods.

The old methods will off course work good in many cases. The point is, they
will not work ok in _some_ cases, that sundials will solve correctly. I
think the documentation should indicate the methods scipy uses are no
longer supported, and have been replaced by the sundials package of which
different python interfaces exist.

Sundials is used a lot in commercial and open source programs, just a short
list here: http://sundials.wikidot.com/projects





> Juan Luis
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130823/0f0465ab/attachment.html>

From saullogiovani at gmail.com  Fri Aug 23 07:35:01 2013
From: saullogiovani at gmail.com (Saullo Castro)
Date: Fri, 23 Aug 2013 13:35:01 +0200
Subject: [SciPy-Dev] Need some help to wrap the cubature package in
	scipy/integrate
Message-ID: <CAHbwRz7RO_w3VDJBYhc9sPkmR8LzE55kO0pB1JO18RO_Pn9aJg@mail.gmail.com>

I am wrapping the Cubature package for multi-dimensional integration that
supports vector-valued functions and offers both fixed and adaptive
integration schemes.

Please, see more details here:
http://ab-initio.mit.edu/wiki/index.php/Cubature

I've forked the scipy repository and my current attempt can be directly
accessed here:

https://github.com/saullocastro/scipy/blob/master/scipy/integrate/_cubature.pyx

When compiling the cython code I am getting the error:

_cubature.obj : error LNK2019: unresolved external symbol hcubature
referenced in function __pyx_pf_9_cubature_fhcubature
C:\usr\scipy\scipy\integrate\_cubature.pyd : fatal error LNK1120: 1
unresolved externals
error: command 'link.exe' failed with exit status 1120

Could you please have a look?

Thank you very much!
Saullo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130823/2a48a6d5/attachment.html>

From jvankers at gmail.com  Fri Aug 23 08:56:49 2013
From: jvankers at gmail.com (Joris Vankerschaver)
Date: Fri, 23 Aug 2013 14:56:49 +0200
Subject: [SciPy-Dev] Loss of precision using lsoda f2py interface or ode
	class
In-Reply-To: <5216A9A6.2030402@gmail.com>
References: <5216A9A6.2030402@gmail.com>
Message-ID: <504DC808-6E3E-436B-A936-696B51834882@gmail.com>

On 23-aug-2013, at 02:15, Juan Luis Cano wrote:
> I fear odeint/ode bugs are starting to pile up (gh-1567, gh-1801, 
> gh-1976, gh-2515, gh-2570), and as many have suggested in the past a 
> rewrite or redesign would be quite helpful.

This may have been pointed out before, but one inconsistency that should be fixed in an eventual redesign is that scipy.integrate.ode expects an RHS of the form `f(t, y0, ...)` whereas odeint expects an RHS with the first two parameters reversed, i.e. of the form `f(y0, t, ...)`. The former convention is the standard in Matlab and Sage.

All the best,
Joris





From charlesnwoods at gmail.com  Fri Aug 23 12:22:01 2013
From: charlesnwoods at gmail.com (Nathan Woods)
Date: Fri, 23 Aug 2013 10:22:01 -0600
Subject: [SciPy-Dev] Need some help to wrap the cubature package in
	scipy/integrate
In-Reply-To: <CAHbwRz7RO_w3VDJBYhc9sPkmR8LzE55kO0pB1JO18RO_Pn9aJg@mail.gmail.com>
References: <CAHbwRz7RO_w3VDJBYhc9sPkmR8LzE55kO0pB1JO18RO_Pn9aJg@mail.gmail.com>
Message-ID: <-1837672449859755872@unknownmsgid>

We just had a multidimensional integrator (nquad) wrapped into the latest
beta version of scipy. How does cubature compare? I've been kicking around
the idea of improving the speed of nquad by moving more of the code to a
compiled language. How would that compare?

Nate


On Aug 23, 2013, at 5:35 AM, Saullo Castro <saullogiovani at gmail.com> wrote:

I am wrapping the Cubature package for multi-dimensional integration that
supports vector-valued functions and offers both fixed and adaptive
integration schemes.

Please, see more details here:
http://ab-initio.mit.edu/wiki/index.php/Cubature

I've forked the scipy repository and my current attempt can be directly
accessed here:

https://github.com/saullocastro/scipy/blob/master/scipy/integrate/_cubature.pyx

When compiling the cython code I am getting the error:

_cubature.obj : error LNK2019: unresolved external symbol hcubature
referenced in function __pyx_pf_9_cubature_fhcubature
C:\usr\scipy\scipy\integrate\_cubature.pyd : fatal error LNK1120: 1
unresolved externals
error: command 'link.exe' failed with exit status 1120

Could you please have a look?

Thank you very much!
Saullo

_______________________________________________
SciPy-Dev mailing list
SciPy-Dev at scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130823/70c59ad6/attachment.html>

From argriffi at ncsu.edu  Fri Aug 23 13:20:19 2013
From: argriffi at ncsu.edu (alex)
Date: Fri, 23 Aug 2013 13:20:19 -0400
Subject: [SciPy-Dev] cubature license
Message-ID: <CAE5GFc+F+gxTctEcJLxO_wRadVLOE=o0XGDEVNy0hb0qu0ip0g@mail.gmail.com>

I noticed on the mailing list that someone wants to put cubature into
scipy.  You will need to ask Steven Johnson before this can happen
because scipy is licensed in a way that does not allow it to accept
GPL code.  Actually now that I read more, this will probably not
happen anyway because cubature itself depends on multiple GPL-licensed
codes.
http://mail.scipy.org/pipermail/scipy-dev/2013-August/thread.html
http://ab-initio.mit.edu/wiki/index.php/Cubature

Alex


From mrdmnd at mit.edu  Fri Aug 23 14:18:09 2013
From: mrdmnd at mit.edu (Matt Redmond)
Date: Fri, 23 Aug 2013 11:18:09 -0700
Subject: [SciPy-Dev] cubature license
In-Reply-To: <CABTWFhHbCsKpfz_NVDGKFDAW6jHndeAqTgMXW0Or77HC+sQMSw@mail.gmail.com>
References: <CAE5GFc+F+gxTctEcJLxO_wRadVLOE=o0XGDEVNy0hb0qu0ip0g@mail.gmail.com>
	<CABTWFhHbCsKpfz_NVDGKFDAW6jHndeAqTgMXW0Or77HC+sQMSw@mail.gmail.com>
Message-ID: <CABTWFhGzjRPgDRmc5Q3csTAiN3yLMk8H6qP_Rvxo15RPRNo0Mg@mail.gmail.com>

I took a number of his classes at MIT, and I'm fairly sure he'd be on board
with this usage. He seemed pretty supportive of SciPy.


On Fri, Aug 23, 2013 at 10:28 AM, Matt Redmond <mttrdmnd at gmail.com> wrote:

> I'll ask him - I took his classes at MIT and I'm fairly sure he'd be okay
> with this.
>
>
> On Fri, Aug 23, 2013 at 10:20 AM, alex <argriffi at ncsu.edu> wrote:
>
>> I noticed on the mailing list that someone wants to put cubature into
>> scipy.  You will need to ask Steven Johnson before this can happen
>> because scipy is licensed in a way that does not allow it to accept
>> GPL code.  Actually now that I read more, this will probably not
>> happen anyway because cubature itself depends on multiple GPL-licensed
>> codes.
>> http://mail.scipy.org/pipermail/scipy-dev/2013-August/thread.html
>> http://ab-initio.mit.edu/wiki/index.php/Cubature
>>
>> Alex
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>
>
>
> --
> Matthew Redmond
> Massachusetts Institute of Technology
> Department of Mathematics, Course 18C
> Class of 2013
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130823/c51a46f9/attachment.html>

From argriffi at ncsu.edu  Fri Aug 23 14:27:45 2013
From: argriffi at ncsu.edu (alex)
Date: Fri, 23 Aug 2013 14:27:45 -0400
Subject: [SciPy-Dev] cubature license
In-Reply-To: <CABTWFhGzjRPgDRmc5Q3csTAiN3yLMk8H6qP_Rvxo15RPRNo0Mg@mail.gmail.com>
References: <CAE5GFc+F+gxTctEcJLxO_wRadVLOE=o0XGDEVNy0hb0qu0ip0g@mail.gmail.com>
	<CABTWFhHbCsKpfz_NVDGKFDAW6jHndeAqTgMXW0Or77HC+sQMSw@mail.gmail.com>
	<CABTWFhGzjRPgDRmc5Q3csTAiN3yLMk8H6qP_Rvxo15RPRNo0Mg@mail.gmail.com>
Message-ID: <CAE5GFcJdW_4iW5Fbqe+7uAhGO2nMmN2+aDxTJSsz9DubFDeAeA@mail.gmail.com>

On Fri, Aug 23, 2013 at 2:18 PM, Matt Redmond <mrdmnd at mit.edu> wrote:
> I took a number of his classes at MIT, and I'm fairly sure he'd be on board
> with this usage. He seemed pretty supportive of SciPy.
>
>
> On Fri, Aug 23, 2013 at 10:28 AM, Matt Redmond <mttrdmnd at gmail.com> wrote:
>>
>> I'll ask him - I took his classes at MIT and I'm fairly sure he'd be okay
>> with this.
>>
>>
>> On Fri, Aug 23, 2013 at 10:20 AM, alex <argriffi at ncsu.edu> wrote:
>>>
>>> I noticed on the mailing list that someone wants to put cubature into
>>> scipy.  You will need to ask Steven Johnson before this can happen
>>> because scipy is licensed in a way that does not allow it to accept
>>> GPL code.  Actually now that I read more, this will probably not
>>> happen anyway because cubature itself depends on multiple GPL-licensed
>>> codes.
>>> http://mail.scipy.org/pipermail/scipy-dev/2013-August/thread.html
>>> http://ab-initio.mit.edu/wiki/index.php/Cubature
>>>
>>> Alex
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
>>
>>
>> --
>> Matthew Redmond
>> Massachusetts Institute of Technology
>> Department of Mathematics, Course 18C
>> Class of 2013
>
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>

Even if he would personally be on board with this usage, the following
bit makes it complicated.

"Our code is based in part on code borrowed from the HIntLib
numeric-integration library by Rudolf Sch?rer and from code for
Gauss-Kronrod quadrature (for 1d integrals) from the GNU Scientific
Library, both of which are free software under the GNU GPL."

Alex


From charlesr.harris at gmail.com  Fri Aug 23 15:09:15 2013
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Fri, 23 Aug 2013 13:09:15 -0600
Subject: [SciPy-Dev] cubature license
In-Reply-To: <CAE5GFcJdW_4iW5Fbqe+7uAhGO2nMmN2+aDxTJSsz9DubFDeAeA@mail.gmail.com>
References: <CAE5GFc+F+gxTctEcJLxO_wRadVLOE=o0XGDEVNy0hb0qu0ip0g@mail.gmail.com>
	<CABTWFhHbCsKpfz_NVDGKFDAW6jHndeAqTgMXW0Or77HC+sQMSw@mail.gmail.com>
	<CABTWFhGzjRPgDRmc5Q3csTAiN3yLMk8H6qP_Rvxo15RPRNo0Mg@mail.gmail.com>
	<CAE5GFcJdW_4iW5Fbqe+7uAhGO2nMmN2+aDxTJSsz9DubFDeAeA@mail.gmail.com>
Message-ID: <CAB6mnxKaknribvOT7U8qGLnt_sfXpXkvVZKbviksqHH1U=NFQA@mail.gmail.com>

Ah, memories. It might not be too hard to replace the Gauss-Kronrad
quadrature, it was the first algorithm I implemented on a 80186 3MHz PC
back in the days when Microsoft offered a Fortran compiler ;) I don't know
about the rest of the dependencies.


On Fri, Aug 23, 2013 at 12:27 PM, alex <argriffi at ncsu.edu> wrote:

> On Fri, Aug 23, 2013 at 2:18 PM, Matt Redmond <mrdmnd at mit.edu> wrote:
> > I took a number of his classes at MIT, and I'm fairly sure he'd be on
> board
> > with this usage. He seemed pretty supportive of SciPy.
> >
> >
> > On Fri, Aug 23, 2013 at 10:28 AM, Matt Redmond <mttrdmnd at gmail.com>
> wrote:
> >>
> >> I'll ask him - I took his classes at MIT and I'm fairly sure he'd be
> okay
> >> with this.
> >>
> >>
> >> On Fri, Aug 23, 2013 at 10:20 AM, alex <argriffi at ncsu.edu> wrote:
> >>>
> >>> I noticed on the mailing list that someone wants to put cubature into
> >>> scipy.  You will need to ask Steven Johnson before this can happen
> >>> because scipy is licensed in a way that does not allow it to accept
> >>> GPL code.  Actually now that I read more, this will probably not
> >>> happen anyway because cubature itself depends on multiple GPL-licensed
> >>> codes.
> >>> http://mail.scipy.org/pipermail/scipy-dev/2013-August/thread.html
> >>> http://ab-initio.mit.edu/wiki/index.php/Cubature
> >>>
> >>> Alex
> >>> _______________________________________________
> >>> SciPy-Dev mailing list
> >>> SciPy-Dev at scipy.org
> >>> http://mail.scipy.org/mailman/listinfo/scipy-dev
> >>
> >>
> >>
> >>
> >> --
> >> Matthew Redmond
> >> Massachusetts Institute of Technology
> >> Department of Mathematics, Course 18C
> >> Class of 2013
> >
> >
> >
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
>
> Even if he would personally be on board with this usage, the following
> bit makes it complicated.
>
> "Our code is based in part on code borrowed from the HIntLib
> numeric-integration library by Rudolf Sch?rer and from code for
> Gauss-Kronrod quadrature (for 1d integrals) from the GNU Scientific
> Library, both of which are free software under the GNU GPL."
>
> Alex
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130823/efc1ee20/attachment.html>

From howarth at bromo.med.uc.edu  Fri Aug 23 19:58:31 2013
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Fri, 23 Aug 2013 19:58:31 -0400
Subject: [SciPy-Dev] ANN: Scipy 0.13.0 beta 1 release
In-Reply-To: <CABL7CQga-Qkq8_hG1E+_KfpmVjSE-duyRePVcZw_-s-PXay75w@mail.gmail.com>
References: <CABL7CQga-Qkq8_hG1E+_KfpmVjSE-duyRePVcZw_-s-PXay75w@mail.gmail.com>
Message-ID: <20130823235831.GA6527@bromo.med.uc.edu>

On Thu, Aug 22, 2013 at 03:12:21PM +0200, Ralf Gommers wrote:
> Hi all,
> 
> I'm happy to announce the availability of the first beta release of Scipy
> 0.13.0. Please try this beta and report any issues on the scipy-dev mailing
> list.
> 
> Source tarballs and release notes can be found at
> https://sourceforge.net/projects/scipy/files/scipy/0.13.0b1/. Windows and
> OS X installers will follow later (we have a minor infrastructure issue to
> solve, and I'm at EuroScipy now).
> 
> Cheers,
> Ralf

Ralf,
   FYI, if the proposed elimination of support for the Accelerate framework on
darwin was implemented in scipy 0.13, you will definietely want to consider reverting that
change. It appears that the issues in the Accelerate framework (at least as
tested with scipy 0.12.0) are resolved in the next darwin release...

Ran 6134 tests in 88.016s

OK (KNOWNFAIL=15, SKIP=36)

compared to darwin12...

Ran 6134 tests in 96.886s

FAILED (KNOWNFAIL=15, SKIP=36, failures=63)

and darwin11...

Ran 6134 tests in 118.346s

FAILED (KNOWNFAIL=15, SKIP=36, failures=65)

             Jack
ps I have looked at the proposed replacement of using openblas and it is rather suboptimal. Please
don't inflict that on us.

> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev



From saullogiovani at gmail.com  Sat Aug 24 04:29:12 2013
From: saullogiovani at gmail.com (Saullo Castro)
Date: Sat, 24 Aug 2013 10:29:12 +0200
Subject: [SciPy-Dev] SciPy-Dev Digest, Vol 118, Issue 31
In-Reply-To: <mailman.3.1377277202.12372.scipy-dev@scipy.org>
References: <mailman.3.1377277202.12372.scipy-dev@scipy.org>
Message-ID: <CAHbwRz4ihS6YzevgPdDZ131=QgOrSRjJBjRn1t8saN4L0sq-JA@mail.gmail.com>

@Nate,

I don't know all the details about this algorithm, but based on the tests
I've performed here it requires much fewer function evaluations than
dblquad or tplquad, since it is NOT a recursive call of 1D-integrands.

It offers two refinement options:

h-cubature which refines by including more integration points
p-cubature which refines by increasing the approximation order (better for
smooth functions)

I will keep working on that and I hope to give you a better feedback very
soon. Please, see more details here:
http://ab-initio.mit.edu/wiki/index.php/Cubature

Greetings,
Saullo


2013/8/23 <scipy-dev-request at scipy.org>

> Send SciPy-Dev mailing list submissions to
>         scipy-dev at scipy.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://mail.scipy.org/mailman/listinfo/scipy-dev
> or, via email, send a message with subject or body 'help' to
>         scipy-dev-request at scipy.org
>
> You can reach the person managing the list at
>         scipy-dev-owner at scipy.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of SciPy-Dev digest..."
>
>
> Today's Topics:
>
>    1. Re: Loss of precision using lsoda f2py interface or ode   class
>       (Joris Vankerschaver)
>    2. Re: Need some help to wrap the cubature package in
>       scipy/integrate (Nathan Woods)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 23 Aug 2013 14:56:49 +0200
> From: Joris Vankerschaver <jvankers at gmail.com>
> Subject: Re: [SciPy-Dev] Loss of precision using lsoda f2py interface
>         or ode  class
> To: SciPy Developers List <scipy-dev at scipy.org>
> Message-ID: <504DC808-6E3E-436B-A936-696B51834882 at gmail.com>
> Content-Type: text/plain; charset=us-ascii
>
> On 23-aug-2013, at 02:15, Juan Luis Cano wrote:
> > I fear odeint/ode bugs are starting to pile up (gh-1567, gh-1801,
> > gh-1976, gh-2515, gh-2570), and as many have suggested in the past a
> > rewrite or redesign would be quite helpful.
>
> This may have been pointed out before, but one inconsistency that should
> be fixed in an eventual redesign is that scipy.integrate.ode expects an RHS
> of the form `f(t, y0, ...)` whereas odeint expects an RHS with the first
> two parameters reversed, i.e. of the form `f(y0, t, ...)`. The former
> convention is the standard in Matlab and Sage.
>
> All the best,
> Joris
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 23 Aug 2013 10:22:01 -0600
> From: Nathan Woods <charlesnwoods at gmail.com>
> Subject: Re: [SciPy-Dev] Need some help to wrap the cubature package
>         in      scipy/integrate
> To: SciPy Developers List <scipy-dev at scipy.org>
> Message-ID: <-1837672449859755872 at unknownmsgid>
> Content-Type: text/plain; charset="iso-8859-1"
>
> We just had a multidimensional integrator (nquad) wrapped into the latest
> beta version of scipy. How does cubature compare? I've been kicking around
> the idea of improving the speed of nquad by moving more of the code to a
> compiled language. How would that compare?
>
> Nate
>
>
> On Aug 23, 2013, at 5:35 AM, Saullo Castro <saullogiovani at gmail.com>
> wrote:
>
> I am wrapping the Cubature package for multi-dimensional integration that
> supports vector-valued functions and offers both fixed and adaptive
> integration schemes.
>
> Please, see more details here:
> http://ab-initio.mit.edu/wiki/index.php/Cubature
>
> I've forked the scipy repository and my current attempt can be directly
> accessed here:
>
>
> https://github.com/saullocastro/scipy/blob/master/scipy/integrate/_cubature.pyx
>
> When compiling the cython code I am getting the error:
>
> _cubature.obj : error LNK2019: unresolved external symbol hcubature
> referenced in function __pyx_pf_9_cubature_fhcubature
> C:\usr\scipy\scipy\integrate\_cubature.pyd : fatal error LNK1120: 1
> unresolved externals
> error: command 'link.exe' failed with exit status 1120
>
> Could you please have a look?
>
> Thank you very much!
> Saullo
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mail.scipy.org/pipermail/scipy-dev/attachments/20130823/70c59ad6/attachment-0001.html
>
> ------------------------------
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
> End of SciPy-Dev Digest, Vol 118, Issue 31
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130824/dbbdbb26/attachment.html>

From saullogiovani at gmail.com  Sat Aug 24 04:39:03 2013
From: saullogiovani at gmail.com (Saullo Castro)
Date: Sat, 24 Aug 2013 10:39:03 +0200
Subject: [SciPy-Dev] SciPy-Dev Digest, Vol 118, Issue 32
In-Reply-To: <mailman.169.1377332631.971.scipy-dev@scipy.org>
References: <mailman.169.1377332631.971.scipy-dev@scipy.org>
Message-ID: <CAHbwRz50dGBAp50xPXvcG+HV=XQotXJFdU0YqQQdbTMNLru8_Q@mail.gmail.com>

Dear all,

I already contacted Steven Johnson about this matter and he told me
that "relicensing
the Cubature code is not feasible", but he agrees on including this in
SciPy if the SciPy community agrees to include a GNU GPL licensed software
there.

Otherwise I will probably create a separate Python package for it, ideally
with a pip installer, as suggested by him.

Greetings,
Saullo


2013/8/24 <scipy-dev-request at scipy.org>

> Send SciPy-Dev mailing list submissions to
>         scipy-dev at scipy.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://mail.scipy.org/mailman/listinfo/scipy-dev
> or, via email, send a message with subject or body 'help' to
>         scipy-dev-request at scipy.org
>
> You can reach the person managing the list at
>         scipy-dev-owner at scipy.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of SciPy-Dev digest..."
>
>
> Today's Topics:
>
>    1. cubature license (alex)
>    2. Re: cubature license (Matt Redmond)
>    3. Re: cubature license (alex)
>    4. Re: cubature license (Charles R Harris)
>    5. Re: ANN: Scipy 0.13.0 beta 1 release (Jack Howarth)
>    6. Re: SciPy-Dev Digest, Vol 118, Issue 31 (Saullo Castro)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 23 Aug 2013 13:20:19 -0400
> From: alex <argriffi at ncsu.edu>
> Subject: [SciPy-Dev] cubature license
> To: scipy-dev at scipy.org
> Message-ID:
>         <CAE5GFc+F+gxTctEcJLxO_wRadVLOE=
> o0XGDEVNy0hb0qu0ip0g at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> I noticed on the mailing list that someone wants to put cubature into
> scipy.  You will need to ask Steven Johnson before this can happen
> because scipy is licensed in a way that does not allow it to accept
> GPL code.  Actually now that I read more, this will probably not
> happen anyway because cubature itself depends on multiple GPL-licensed
> codes.
> http://mail.scipy.org/pipermail/scipy-dev/2013-August/thread.html
> http://ab-initio.mit.edu/wiki/index.php/Cubature
>
> Alex
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 23 Aug 2013 11:18:09 -0700
> From: Matt Redmond <mrdmnd at mit.edu>
> Subject: Re: [SciPy-Dev] cubature license
> To: SciPy Developers List <scipy-dev at scipy.org>
> Message-ID:
>         <
> CABTWFhGzjRPgDRmc5Q3csTAiN3yLMk8H6qP_Rvxo15RPRNo0Mg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I took a number of his classes at MIT, and I'm fairly sure he'd be on board
> with this usage. He seemed pretty supportive of SciPy.
>
>
> On Fri, Aug 23, 2013 at 10:28 AM, Matt Redmond <mttrdmnd at gmail.com> wrote:
>
> > I'll ask him - I took his classes at MIT and I'm fairly sure he'd be okay
> > with this.
> >
> >
> > On Fri, Aug 23, 2013 at 10:20 AM, alex <argriffi at ncsu.edu> wrote:
> >
> >> I noticed on the mailing list that someone wants to put cubature into
> >> scipy.  You will need to ask Steven Johnson before this can happen
> >> because scipy is licensed in a way that does not allow it to accept
> >> GPL code.  Actually now that I read more, this will probably not
> >> happen anyway because cubature itself depends on multiple GPL-licensed
> >> codes.
> >> http://mail.scipy.org/pipermail/scipy-dev/2013-August/thread.html
> >> http://ab-initio.mit.edu/wiki/index.php/Cubature
> >>
> >> Alex
> >> _______________________________________________
> >> SciPy-Dev mailing list
> >> SciPy-Dev at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
> >>
> >
> >
> >
> > --
> > Matthew Redmond
> > Massachusetts Institute of Technology
> > Department of Mathematics, Course 18C
> > Class of 2013
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mail.scipy.org/pipermail/scipy-dev/attachments/20130823/c51a46f9/attachment-0001.html
>
> ------------------------------
>
> Message: 3
> Date: Fri, 23 Aug 2013 14:27:45 -0400
> From: alex <argriffi at ncsu.edu>
> Subject: Re: [SciPy-Dev] cubature license
> To: SciPy Developers List <scipy-dev at scipy.org>
> Message-ID:
>         <
> CAE5GFcJdW_4iW5Fbqe+7uAhGO2nMmN2+aDxTJSsz9DubFDeAeA at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Fri, Aug 23, 2013 at 2:18 PM, Matt Redmond <mrdmnd at mit.edu> wrote:
> > I took a number of his classes at MIT, and I'm fairly sure he'd be on
> board
> > with this usage. He seemed pretty supportive of SciPy.
> >
> >
> > On Fri, Aug 23, 2013 at 10:28 AM, Matt Redmond <mttrdmnd at gmail.com>
> wrote:
> >>
> >> I'll ask him - I took his classes at MIT and I'm fairly sure he'd be
> okay
> >> with this.
> >>
> >>
> >> On Fri, Aug 23, 2013 at 10:20 AM, alex <argriffi at ncsu.edu> wrote:
> >>>
> >>> I noticed on the mailing list that someone wants to put cubature into
> >>> scipy.  You will need to ask Steven Johnson before this can happen
> >>> because scipy is licensed in a way that does not allow it to accept
> >>> GPL code.  Actually now that I read more, this will probably not
> >>> happen anyway because cubature itself depends on multiple GPL-licensed
> >>> codes.
> >>> http://mail.scipy.org/pipermail/scipy-dev/2013-August/thread.html
> >>> http://ab-initio.mit.edu/wiki/index.php/Cubature
> >>>
> >>> Alex
> >>> _______________________________________________
> >>> SciPy-Dev mailing list
> >>> SciPy-Dev at scipy.org
> >>> http://mail.scipy.org/mailman/listinfo/scipy-dev
> >>
> >>
> >>
> >>
> >> --
> >> Matthew Redmond
> >> Massachusetts Institute of Technology
> >> Department of Mathematics, Course 18C
> >> Class of 2013
> >
> >
> >
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
>
> Even if he would personally be on board with this usage, the following
> bit makes it complicated.
>
> "Our code is based in part on code borrowed from the HIntLib
> numeric-integration library by Rudolf Sch?rer and from code for
> Gauss-Kronrod quadrature (for 1d integrals) from the GNU Scientific
> Library, both of which are free software under the GNU GPL."
>
> Alex
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 23 Aug 2013 13:09:15 -0600
> From: Charles R Harris <charlesr.harris at gmail.com>
> Subject: Re: [SciPy-Dev] cubature license
> To: SciPy Developers List <scipy-dev at scipy.org>
> Message-ID:
>         <CAB6mnxKaknribvOT7U8qGLnt_sfXpXkvVZKbviksqHH1U=
> NFQA at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Ah, memories. It might not be too hard to replace the Gauss-Kronrad
> quadrature, it was the first algorithm I implemented on a 80186 3MHz PC
> back in the days when Microsoft offered a Fortran compiler ;) I don't know
> about the rest of the dependencies.
>
>
> On Fri, Aug 23, 2013 at 12:27 PM, alex <argriffi at ncsu.edu> wrote:
>
> > On Fri, Aug 23, 2013 at 2:18 PM, Matt Redmond <mrdmnd at mit.edu> wrote:
> > > I took a number of his classes at MIT, and I'm fairly sure he'd be on
> > board
> > > with this usage. He seemed pretty supportive of SciPy.
> > >
> > >
> > > On Fri, Aug 23, 2013 at 10:28 AM, Matt Redmond <mttrdmnd at gmail.com>
> > wrote:
> > >>
> > >> I'll ask him - I took his classes at MIT and I'm fairly sure he'd be
> > okay
> > >> with this.
> > >>
> > >>
> > >> On Fri, Aug 23, 2013 at 10:20 AM, alex <argriffi at ncsu.edu> wrote:
> > >>>
> > >>> I noticed on the mailing list that someone wants to put cubature into
> > >>> scipy.  You will need to ask Steven Johnson before this can happen
> > >>> because scipy is licensed in a way that does not allow it to accept
> > >>> GPL code.  Actually now that I read more, this will probably not
> > >>> happen anyway because cubature itself depends on multiple
> GPL-licensed
> > >>> codes.
> > >>> http://mail.scipy.org/pipermail/scipy-dev/2013-August/thread.html
> > >>> http://ab-initio.mit.edu/wiki/index.php/Cubature
> > >>>
> > >>> Alex
> > >>> _______________________________________________
> > >>> SciPy-Dev mailing list
> > >>> SciPy-Dev at scipy.org
> > >>> http://mail.scipy.org/mailman/listinfo/scipy-dev
> > >>
> > >>
> > >>
> > >>
> > >> --
> > >> Matthew Redmond
> > >> Massachusetts Institute of Technology
> > >> Department of Mathematics, Course 18C
> > >> Class of 2013
> > >
> > >
> > >
> > > _______________________________________________
> > > SciPy-Dev mailing list
> > > SciPy-Dev at scipy.org
> > > http://mail.scipy.org/mailman/listinfo/scipy-dev
> > >
> >
> > Even if he would personally be on board with this usage, the following
> > bit makes it complicated.
> >
> > "Our code is based in part on code borrowed from the HIntLib
> > numeric-integration library by Rudolf Sch?rer and from code for
> > Gauss-Kronrod quadrature (for 1d integrals) from the GNU Scientific
> > Library, both of which are free software under the GNU GPL."
> >
> > Alex
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mail.scipy.org/pipermail/scipy-dev/attachments/20130823/efc1ee20/attachment-0001.html
>
> ------------------------------
>
> Message: 5
> Date: Fri, 23 Aug 2013 19:58:31 -0400
> From: Jack Howarth <howarth at bromo.med.uc.edu>
> Subject: Re: [SciPy-Dev] ANN: Scipy 0.13.0 beta 1 release
> To: SciPy Developers List <scipy-dev at scipy.org>
> Message-ID: <20130823235831.GA6527 at bromo.med.uc.edu>
> Content-Type: text/plain; charset=us-ascii
>
> On Thu, Aug 22, 2013 at 03:12:21PM +0200, Ralf Gommers wrote:
> > Hi all,
> >
> > I'm happy to announce the availability of the first beta release of Scipy
> > 0.13.0. Please try this beta and report any issues on the scipy-dev
> mailing
> > list.
> >
> > Source tarballs and release notes can be found at
> > https://sourceforge.net/projects/scipy/files/scipy/0.13.0b1/. Windows
> and
> > OS X installers will follow later (we have a minor infrastructure issue
> to
> > solve, and I'm at EuroScipy now).
> >
> > Cheers,
> > Ralf
>
> Ralf,
>    FYI, if the proposed elimination of support for the Accelerate
> framework on
> darwin was implemented in scipy 0.13, you will definietely want to
> consider reverting that
> change. It appears that the issues in the Accelerate framework (at least as
> tested with scipy 0.12.0) are resolved in the next darwin release...
>
> Ran 6134 tests in 88.016s
>
> OK (KNOWNFAIL=15, SKIP=36)
>
> compared to darwin12...
>
> Ran 6134 tests in 96.886s
>
> FAILED (KNOWNFAIL=15, SKIP=36, failures=63)
>
> and darwin11...
>
> Ran 6134 tests in 118.346s
>
> FAILED (KNOWNFAIL=15, SKIP=36, failures=65)
>
>              Jack
> ps I have looked at the proposed replacement of using openblas and it is
> rather suboptimal. Please
> don't inflict that on us.
>
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
>
> ------------------------------
>
> Message: 6
> Date: Sat, 24 Aug 2013 10:29:12 +0200
> From: Saullo Castro <saullogiovani at gmail.com>
> Subject: Re: [SciPy-Dev] SciPy-Dev Digest, Vol 118, Issue 31
> To: Scipy-Dev <scipy-dev at scipy.org>
> Message-ID:
>         <CAHbwRz4ihS6YzevgPdDZ131=
> QgOrSRjJBjRn1t8saN4L0sq-JA at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> @Nate,
>
> I don't know all the details about this algorithm, but based on the tests
> I've performed here it requires much fewer function evaluations than
> dblquad or tplquad, since it is NOT a recursive call of 1D-integrands.
>
> It offers two refinement options:
>
> h-cubature which refines by including more integration points
> p-cubature which refines by increasing the approximation order (better for
> smooth functions)
>
> I will keep working on that and I hope to give you a better feedback very
> soon. Please, see more details here:
> http://ab-initio.mit.edu/wiki/index.php/Cubature
>
> Greetings,
> Saullo
>
>
> 2013/8/23 <scipy-dev-request at scipy.org>
>
> > Send SciPy-Dev mailing list submissions to
> >         scipy-dev at scipy.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >         http://mail.scipy.org/mailman/listinfo/scipy-dev
> > or, via email, send a message with subject or body 'help' to
> >         scipy-dev-request at scipy.org
> >
> > You can reach the person managing the list at
> >         scipy-dev-owner at scipy.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of SciPy-Dev digest..."
> >
> >
> > Today's Topics:
> >
> >    1. Re: Loss of precision using lsoda f2py interface or ode   class
> >       (Joris Vankerschaver)
> >    2. Re: Need some help to wrap the cubature package in
> >       scipy/integrate (Nathan Woods)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Fri, 23 Aug 2013 14:56:49 +0200
> > From: Joris Vankerschaver <jvankers at gmail.com>
> > Subject: Re: [SciPy-Dev] Loss of precision using lsoda f2py interface
> >         or ode  class
> > To: SciPy Developers List <scipy-dev at scipy.org>
> > Message-ID: <504DC808-6E3E-436B-A936-696B51834882 at gmail.com>
> > Content-Type: text/plain; charset=us-ascii
> >
> > On 23-aug-2013, at 02:15, Juan Luis Cano wrote:
> > > I fear odeint/ode bugs are starting to pile up (gh-1567, gh-1801,
> > > gh-1976, gh-2515, gh-2570), and as many have suggested in the past a
> > > rewrite or redesign would be quite helpful.
> >
> > This may have been pointed out before, but one inconsistency that should
> > be fixed in an eventual redesign is that scipy.integrate.ode expects an
> RHS
> > of the form `f(t, y0, ...)` whereas odeint expects an RHS with the first
> > two parameters reversed, i.e. of the form `f(y0, t, ...)`. The former
> > convention is the standard in Matlab and Sage.
> >
> > All the best,
> > Joris
> >
> >
> >
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Fri, 23 Aug 2013 10:22:01 -0600
> > From: Nathan Woods <charlesnwoods at gmail.com>
> > Subject: Re: [SciPy-Dev] Need some help to wrap the cubature package
> >         in      scipy/integrate
> > To: SciPy Developers List <scipy-dev at scipy.org>
> > Message-ID: <-1837672449859755872 at unknownmsgid>
> > Content-Type: text/plain; charset="iso-8859-1"
> >
> > We just had a multidimensional integrator (nquad) wrapped into the latest
> > beta version of scipy. How does cubature compare? I've been kicking
> around
> > the idea of improving the speed of nquad by moving more of the code to a
> > compiled language. How would that compare?
> >
> > Nate
> >
> >
> > On Aug 23, 2013, at 5:35 AM, Saullo Castro <saullogiovani at gmail.com>
> > wrote:
> >
> > I am wrapping the Cubature package for multi-dimensional integration that
> > supports vector-valued functions and offers both fixed and adaptive
> > integration schemes.
> >
> > Please, see more details here:
> > http://ab-initio.mit.edu/wiki/index.php/Cubature
> >
> > I've forked the scipy repository and my current attempt can be directly
> > accessed here:
> >
> >
> >
> https://github.com/saullocastro/scipy/blob/master/scipy/integrate/_cubature.pyx
> >
> > When compiling the cython code I am getting the error:
> >
> > _cubature.obj : error LNK2019: unresolved external symbol hcubature
> > referenced in function __pyx_pf_9_cubature_fhcubature
> > C:\usr\scipy\scipy\integrate\_cubature.pyd : fatal error LNK1120: 1
> > unresolved externals
> > error: command 'link.exe' failed with exit status 1120
> >
> > Could you please have a look?
> >
> > Thank you very much!
> > Saullo
> >
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL:
> >
> http://mail.scipy.org/pipermail/scipy-dev/attachments/20130823/70c59ad6/attachment-0001.html
> >
> > ------------------------------
> >
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> >
> > End of SciPy-Dev Digest, Vol 118, Issue 31
> > ******************************************
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mail.scipy.org/pipermail/scipy-dev/attachments/20130824/dbbdbb26/attachment.html
>
> ------------------------------
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
> End of SciPy-Dev Digest, Vol 118, Issue 32
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130824/2f02c5bb/attachment.html>

From saullogiovani at gmail.com  Sat Aug 24 04:43:45 2013
From: saullogiovani at gmail.com (Saullo Castro)
Date: Sat, 24 Aug 2013 10:43:45 +0200
Subject: [SciPy-Dev] cubature license
Message-ID: <CAHbwRz71bNbcFOLq95Dq3UsaF-r-18e_obw1Y6295PSk5E-tnA@mail.gmail.com>

@Alex,

you are right, "it uses some GPL code from other projects (Hintlib and GSL).
"

But is it really impossible to include it in SciPy because of that?

Saullo

2013/8/24 <scipy-dev-request at scipy.org>

> Send SciPy-Dev mailing list submissions to
>         scipy-dev at scipy.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://mail.scipy.org/mailman/listinfo/scipy-dev
> or, via email, send a message with subject or body 'help' to
>         scipy-dev-request at scipy.org
>
> You can reach the person managing the list at
>         scipy-dev-owner at scipy.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of SciPy-Dev digest..."
>
>
> Today's Topics:
>
>    1. Re: SciPy-Dev Digest, Vol 118, Issue 32 (Saullo Castro)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 24 Aug 2013 10:39:03 +0200
> From: Saullo Castro <saullogiovani at gmail.com>
> Subject: Re: [SciPy-Dev] SciPy-Dev Digest, Vol 118, Issue 32
> To: Scipy-Dev <scipy-dev at scipy.org>
> Message-ID:
>         <CAHbwRz50dGBAp50xPXvcG+HV=
> XQotXJFdU0YqQQdbTMNLru8_Q at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Dear all,
>
> I already contacted Steven Johnson about this matter and he told me
> that "relicensing
> the Cubature code is not feasible", but he agrees on including this in
> SciPy if the SciPy community agrees to include a GNU GPL licensed software
> there.
>
> Otherwise I will probably create a separate Python package for it, ideally
> with a pip installer, as suggested by him.
>
> Greetings,
> Saullo
>
>
> 2013/8/24 <scipy-dev-request at scipy.org>
>
> > Send SciPy-Dev mailing list submissions to
> >         scipy-dev at scipy.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >         http://mail.scipy.org/mailman/listinfo/scipy-dev
> > or, via email, send a message with subject or body 'help' to
> >         scipy-dev-request at scipy.org
> >
> > You can reach the person managing the list at
> >         scipy-dev-owner at scipy.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of SciPy-Dev digest..."
> >
> >
> > Today's Topics:
> >
> >    1. cubature license (alex)
> >    2. Re: cubature license (Matt Redmond)
> >    3. Re: cubature license (alex)
> >    4. Re: cubature license (Charles R Harris)
> >    5. Re: ANN: Scipy 0.13.0 beta 1 release (Jack Howarth)
> >    6. Re: SciPy-Dev Digest, Vol 118, Issue 31 (Saullo Castro)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Fri, 23 Aug 2013 13:20:19 -0400
> > From: alex <argriffi at ncsu.edu>
> > Subject: [SciPy-Dev] cubature license
> > To: scipy-dev at scipy.org
> > Message-ID:
> >         <CAE5GFc+F+gxTctEcJLxO_wRadVLOE=
> > o0XGDEVNy0hb0qu0ip0g at mail.gmail.com>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > I noticed on the mailing list that someone wants to put cubature into
> > scipy.  You will need to ask Steven Johnson before this can happen
> > because scipy is licensed in a way that does not allow it to accept
> > GPL code.  Actually now that I read more, this will probably not
> > happen anyway because cubature itself depends on multiple GPL-licensed
> > codes.
> > http://mail.scipy.org/pipermail/scipy-dev/2013-August/thread.html
> > http://ab-initio.mit.edu/wiki/index.php/Cubature
> >
> > Alex
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Fri, 23 Aug 2013 11:18:09 -0700
> > From: Matt Redmond <mrdmnd at mit.edu>
> > Subject: Re: [SciPy-Dev] cubature license
> > To: SciPy Developers List <scipy-dev at scipy.org>
> > Message-ID:
> >         <
> > CABTWFhGzjRPgDRmc5Q3csTAiN3yLMk8H6qP_Rvxo15RPRNo0Mg at mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > I took a number of his classes at MIT, and I'm fairly sure he'd be on
> board
> > with this usage. He seemed pretty supportive of SciPy.
> >
> >
> > On Fri, Aug 23, 2013 at 10:28 AM, Matt Redmond <mttrdmnd at gmail.com>
> wrote:
> >
> > > I'll ask him - I took his classes at MIT and I'm fairly sure he'd be
> okay
> > > with this.
> > >
> > >
> > > On Fri, Aug 23, 2013 at 10:20 AM, alex <argriffi at ncsu.edu> wrote:
> > >
> > >> I noticed on the mailing list that someone wants to put cubature into
> > >> scipy.  You will need to ask Steven Johnson before this can happen
> > >> because scipy is licensed in a way that does not allow it to accept
> > >> GPL code.  Actually now that I read more, this will probably not
> > >> happen anyway because cubature itself depends on multiple GPL-licensed
> > >> codes.
> > >> http://mail.scipy.org/pipermail/scipy-dev/2013-August/thread.html
> > >> http://ab-initio.mit.edu/wiki/index.php/Cubature
> > >>
> > >> Alex
> > >> _______________________________________________
> > >> SciPy-Dev mailing list
> > >> SciPy-Dev at scipy.org
> > >> http://mail.scipy.org/mailman/listinfo/scipy-dev
> > >>
> > >
> > >
> > >
> > > --
> > > Matthew Redmond
> > > Massachusetts Institute of Technology
> > > Department of Mathematics, Course 18C
> > > Class of 2013
> > >
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL:
> >
> http://mail.scipy.org/pipermail/scipy-dev/attachments/20130823/c51a46f9/attachment-0001.html
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Fri, 23 Aug 2013 14:27:45 -0400
> > From: alex <argriffi at ncsu.edu>
> > Subject: Re: [SciPy-Dev] cubature license
> > To: SciPy Developers List <scipy-dev at scipy.org>
> > Message-ID:
> >         <
> > CAE5GFcJdW_4iW5Fbqe+7uAhGO2nMmN2+aDxTJSsz9DubFDeAeA at mail.gmail.com>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > On Fri, Aug 23, 2013 at 2:18 PM, Matt Redmond <mrdmnd at mit.edu> wrote:
> > > I took a number of his classes at MIT, and I'm fairly sure he'd be on
> > board
> > > with this usage. He seemed pretty supportive of SciPy.
> > >
> > >
> > > On Fri, Aug 23, 2013 at 10:28 AM, Matt Redmond <mttrdmnd at gmail.com>
> > wrote:
> > >>
> > >> I'll ask him - I took his classes at MIT and I'm fairly sure he'd be
> > okay
> > >> with this.
> > >>
> > >>
> > >> On Fri, Aug 23, 2013 at 10:20 AM, alex <argriffi at ncsu.edu> wrote:
> > >>>
> > >>> I noticed on the mailing list that someone wants to put cubature into
> > >>> scipy.  You will need to ask Steven Johnson before this can happen
> > >>> because scipy is licensed in a way that does not allow it to accept
> > >>> GPL code.  Actually now that I read more, this will probably not
> > >>> happen anyway because cubature itself depends on multiple
> GPL-licensed
> > >>> codes.
> > >>> http://mail.scipy.org/pipermail/scipy-dev/2013-August/thread.html
> > >>> http://ab-initio.mit.edu/wiki/index.php/Cubature
> > >>>
> > >>> Alex
> > >>> _______________________________________________
> > >>> SciPy-Dev mailing list
> > >>> SciPy-Dev at scipy.org
> > >>> http://mail.scipy.org/mailman/listinfo/scipy-dev
> > >>
> > >>
> > >>
> > >>
> > >> --
> > >> Matthew Redmond
> > >> Massachusetts Institute of Technology
> > >> Department of Mathematics, Course 18C
> > >> Class of 2013
> > >
> > >
> > >
> > > _______________________________________________
> > > SciPy-Dev mailing list
> > > SciPy-Dev at scipy.org
> > > http://mail.scipy.org/mailman/listinfo/scipy-dev
> > >
> >
> > Even if he would personally be on board with this usage, the following
> > bit makes it complicated.
> >
> > "Our code is based in part on code borrowed from the HIntLib
> > numeric-integration library by Rudolf Sch?rer and from code for
> > Gauss-Kronrod quadrature (for 1d integrals) from the GNU Scientific
> > Library, both of which are free software under the GNU GPL."
> >
> > Alex
> >
> >
> > ------------------------------
> >
> > Message: 4
> > Date: Fri, 23 Aug 2013 13:09:15 -0600
> > From: Charles R Harris <charlesr.harris at gmail.com>
> > Subject: Re: [SciPy-Dev] cubature license
> > To: SciPy Developers List <scipy-dev at scipy.org>
> > Message-ID:
> >         <CAB6mnxKaknribvOT7U8qGLnt_sfXpXkvVZKbviksqHH1U=
> > NFQA at mail.gmail.com>
> > Content-Type: text/plain; charset="iso-8859-1"
> >
> > Ah, memories. It might not be too hard to replace the Gauss-Kronrad
> > quadrature, it was the first algorithm I implemented on a 80186 3MHz PC
> > back in the days when Microsoft offered a Fortran compiler ;) I don't
> know
> > about the rest of the dependencies.
> >
> >
> > On Fri, Aug 23, 2013 at 12:27 PM, alex <argriffi at ncsu.edu> wrote:
> >
> > > On Fri, Aug 23, 2013 at 2:18 PM, Matt Redmond <mrdmnd at mit.edu> wrote:
> > > > I took a number of his classes at MIT, and I'm fairly sure he'd be on
> > > board
> > > > with this usage. He seemed pretty supportive of SciPy.
> > > >
> > > >
> > > > On Fri, Aug 23, 2013 at 10:28 AM, Matt Redmond <mttrdmnd at gmail.com>
> > > wrote:
> > > >>
> > > >> I'll ask him - I took his classes at MIT and I'm fairly sure he'd be
> > > okay
> > > >> with this.
> > > >>
> > > >>
> > > >> On Fri, Aug 23, 2013 at 10:20 AM, alex <argriffi at ncsu.edu> wrote:
> > > >>>
> > > >>> I noticed on the mailing list that someone wants to put cubature
> into
> > > >>> scipy.  You will need to ask Steven Johnson before this can happen
> > > >>> because scipy is licensed in a way that does not allow it to accept
> > > >>> GPL code.  Actually now that I read more, this will probably not
> > > >>> happen anyway because cubature itself depends on multiple
> > GPL-licensed
> > > >>> codes.
> > > >>> http://mail.scipy.org/pipermail/scipy-dev/2013-August/thread.html
> > > >>> http://ab-initio.mit.edu/wiki/index.php/Cubature
> > > >>>
> > > >>> Alex
> > > >>> _______________________________________________
> > > >>> SciPy-Dev mailing list
> > > >>> SciPy-Dev at scipy.org
> > > >>> http://mail.scipy.org/mailman/listinfo/scipy-dev
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Matthew Redmond
> > > >> Massachusetts Institute of Technology
> > > >> Department of Mathematics, Course 18C
> > > >> Class of 2013
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > SciPy-Dev mailing list
> > > > SciPy-Dev at scipy.org
> > > > http://mail.scipy.org/mailman/listinfo/scipy-dev
> > > >
> > >
> > > Even if he would personally be on board with this usage, the following
> > > bit makes it complicated.
> > >
> > > "Our code is based in part on code borrowed from the HIntLib
> > > numeric-integration library by Rudolf Sch?rer and from code for
> > > Gauss-Kronrod quadrature (for 1d integrals) from the GNU Scientific
> > > Library, both of which are free software under the GNU GPL."
> > >
> > > Alex
> > > _______________________________________________
> > > SciPy-Dev mailing list
> > > SciPy-Dev at scipy.org
> > > http://mail.scipy.org/mailman/listinfo/scipy-dev
> > >
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL:
> >
> http://mail.scipy.org/pipermail/scipy-dev/attachments/20130823/efc1ee20/attachment-0001.html
> >
> > ------------------------------
> >
> > Message: 5
> > Date: Fri, 23 Aug 2013 19:58:31 -0400
> > From: Jack Howarth <howarth at bromo.med.uc.edu>
> > Subject: Re: [SciPy-Dev] ANN: Scipy 0.13.0 beta 1 release
> > To: SciPy Developers List <scipy-dev at scipy.org>
> > Message-ID: <20130823235831.GA6527 at bromo.med.uc.edu>
> > Content-Type: text/plain; charset=us-ascii
> >
> > On Thu, Aug 22, 2013 at 03:12:21PM +0200, Ralf Gommers wrote:
> > > Hi all,
> > >
> > > I'm happy to announce the availability of the first beta release of
> Scipy
> > > 0.13.0. Please try this beta and report any issues on the scipy-dev
> > mailing
> > > list.
> > >
> > > Source tarballs and release notes can be found at
> > > https://sourceforge.net/projects/scipy/files/scipy/0.13.0b1/. Windows
> > and
> > > OS X installers will follow later (we have a minor infrastructure issue
> > to
> > > solve, and I'm at EuroScipy now).
> > >
> > > Cheers,
> > > Ralf
> >
> > Ralf,
> >    FYI, if the proposed elimination of support for the Accelerate
> > framework on
> > darwin was implemented in scipy 0.13, you will definietely want to
> > consider reverting that
> > change. It appears that the issues in the Accelerate framework (at least
> as
> > tested with scipy 0.12.0) are resolved in the next darwin release...
> >
> > Ran 6134 tests in 88.016s
> >
> > OK (KNOWNFAIL=15, SKIP=36)
> >
> > compared to darwin12...
> >
> > Ran 6134 tests in 96.886s
> >
> > FAILED (KNOWNFAIL=15, SKIP=36, failures=63)
> >
> > and darwin11...
> >
> > Ran 6134 tests in 118.346s
> >
> > FAILED (KNOWNFAIL=15, SKIP=36, failures=65)
> >
> >              Jack
> > ps I have looked at the proposed replacement of using openblas and it is
> > rather suboptimal. Please
> > don't inflict that on us.
> >
> > > _______________________________________________
> > > SciPy-Dev mailing list
> > > SciPy-Dev at scipy.org
> > > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> >
> >
> > ------------------------------
> >
> > Message: 6
> > Date: Sat, 24 Aug 2013 10:29:12 +0200
> > From: Saullo Castro <saullogiovani at gmail.com>
> > Subject: Re: [SciPy-Dev] SciPy-Dev Digest, Vol 118, Issue 31
> > To: Scipy-Dev <scipy-dev at scipy.org>
> > Message-ID:
> >         <CAHbwRz4ihS6YzevgPdDZ131=
> > QgOrSRjJBjRn1t8saN4L0sq-JA at mail.gmail.com>
> > Content-Type: text/plain; charset="iso-8859-1"
> >
> > @Nate,
> >
> > I don't know all the details about this algorithm, but based on the tests
> > I've performed here it requires much fewer function evaluations than
> > dblquad or tplquad, since it is NOT a recursive call of 1D-integrands.
> >
> > It offers two refinement options:
> >
> > h-cubature which refines by including more integration points
> > p-cubature which refines by increasing the approximation order (better
> for
> > smooth functions)
> >
> > I will keep working on that and I hope to give you a better feedback very
> > soon. Please, see more details here:
> > http://ab-initio.mit.edu/wiki/index.php/Cubature
> >
> > Greetings,
> > Saullo
> >
> >
> > 2013/8/23 <scipy-dev-request at scipy.org>
> >
> > > Send SciPy-Dev mailing list submissions to
> > >         scipy-dev at scipy.org
> > >
> > > To subscribe or unsubscribe via the World Wide Web, visit
> > >         http://mail.scipy.org/mailman/listinfo/scipy-dev
> > > or, via email, send a message with subject or body 'help' to
> > >         scipy-dev-request at scipy.org
> > >
> > > You can reach the person managing the list at
> > >         scipy-dev-owner at scipy.org
> > >
> > > When replying, please edit your Subject line so it is more specific
> > > than "Re: Contents of SciPy-Dev digest..."
> > >
> > >
> > > Today's Topics:
> > >
> > >    1. Re: Loss of precision using lsoda f2py interface or ode   class
> > >       (Joris Vankerschaver)
> > >    2. Re: Need some help to wrap the cubature package in
> > >       scipy/integrate (Nathan Woods)
> > >
> > >
> > > ----------------------------------------------------------------------
> > >
> > > Message: 1
> > > Date: Fri, 23 Aug 2013 14:56:49 +0200
> > > From: Joris Vankerschaver <jvankers at gmail.com>
> > > Subject: Re: [SciPy-Dev] Loss of precision using lsoda f2py interface
> > >         or ode  class
> > > To: SciPy Developers List <scipy-dev at scipy.org>
> > > Message-ID: <504DC808-6E3E-436B-A936-696B51834882 at gmail.com>
> > > Content-Type: text/plain; charset=us-ascii
> > >
> > > On 23-aug-2013, at 02:15, Juan Luis Cano wrote:
> > > > I fear odeint/ode bugs are starting to pile up (gh-1567, gh-1801,
> > > > gh-1976, gh-2515, gh-2570), and as many have suggested in the past a
> > > > rewrite or redesign would be quite helpful.
> > >
> > > This may have been pointed out before, but one inconsistency that
> should
> > > be fixed in an eventual redesign is that scipy.integrate.ode expects an
> > RHS
> > > of the form `f(t, y0, ...)` whereas odeint expects an RHS with the
> first
> > > two parameters reversed, i.e. of the form `f(y0, t, ...)`. The former
> > > convention is the standard in Matlab and Sage.
> > >
> > > All the best,
> > > Joris
> > >
> > >
> > >
> > >
> > >
> > > ------------------------------
> > >
> > > Message: 2
> > > Date: Fri, 23 Aug 2013 10:22:01 -0600
> > > From: Nathan Woods <charlesnwoods at gmail.com>
> > > Subject: Re: [SciPy-Dev] Need some help to wrap the cubature package
> > >         in      scipy/integrate
> > > To: SciPy Developers List <scipy-dev at scipy.org>
> > > Message-ID: <-1837672449859755872 at unknownmsgid>
> > > Content-Type: text/plain; charset="iso-8859-1"
> > >
> > > We just had a multidimensional integrator (nquad) wrapped into the
> latest
> > > beta version of scipy. How does cubature compare? I've been kicking
> > around
> > > the idea of improving the speed of nquad by moving more of the code to
> a
> > > compiled language. How would that compare?
> > >
> > > Nate
> > >
> > >
> > > On Aug 23, 2013, at 5:35 AM, Saullo Castro <saullogiovani at gmail.com>
> > > wrote:
> > >
> > > I am wrapping the Cubature package for multi-dimensional integration
> that
> > > supports vector-valued functions and offers both fixed and adaptive
> > > integration schemes.
> > >
> > > Please, see more details here:
> > > http://ab-initio.mit.edu/wiki/index.php/Cubature
> > >
> > > I've forked the scipy repository and my current attempt can be directly
> > > accessed here:
> > >
> > >
> > >
> >
> https://github.com/saullocastro/scipy/blob/master/scipy/integrate/_cubature.pyx
> > >
> > > When compiling the cython code I am getting the error:
> > >
> > > _cubature.obj : error LNK2019: unresolved external symbol hcubature
> > > referenced in function __pyx_pf_9_cubature_fhcubature
> > > C:\usr\scipy\scipy\integrate\_cubature.pyd : fatal error LNK1120: 1
> > > unresolved externals
> > > error: command 'link.exe' failed with exit status 1120
> > >
> > > Could you please have a look?
> > >
> > > Thank you very much!
> > > Saullo
> > >
> > > _______________________________________________
> > > SciPy-Dev mailing list
> > > SciPy-Dev at scipy.org
> > > http://mail.scipy.org/mailman/listinfo/scipy-dev
> > > -------------- next part --------------
> > > An HTML attachment was scrubbed...
> > > URL:
> > >
> >
> http://mail.scipy.org/pipermail/scipy-dev/attachments/20130823/70c59ad6/attachment-0001.html
> > >
> > > ------------------------------
> > >
> > > _______________________________________________
> > > SciPy-Dev mailing list
> > > SciPy-Dev at scipy.org
> > > http://mail.scipy.org/mailman/listinfo/scipy-dev
> > >
> > >
> > > End of SciPy-Dev Digest, Vol 118, Issue 31
> > > ******************************************
> > >
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL:
> >
> http://mail.scipy.org/pipermail/scipy-dev/attachments/20130824/dbbdbb26/attachment.html
> >
> > ------------------------------
> >
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> >
> > End of SciPy-Dev Digest, Vol 118, Issue 32
> > ******************************************
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mail.scipy.org/pipermail/scipy-dev/attachments/20130824/2f02c5bb/attachment.html
>
> ------------------------------
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
> End of SciPy-Dev Digest, Vol 118, Issue 33
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130824/f94bc05e/attachment.html>

From ralf.gommers at gmail.com  Sat Aug 24 05:01:39 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sat, 24 Aug 2013 11:01:39 +0200
Subject: [SciPy-Dev] SciPy-Dev Digest, Vol 118, Issue 32
In-Reply-To: <CAHbwRz50dGBAp50xPXvcG+HV=XQotXJFdU0YqQQdbTMNLru8_Q@mail.gmail.com>
References: <mailman.169.1377332631.971.scipy-dev@scipy.org>
	<CAHbwRz50dGBAp50xPXvcG+HV=XQotXJFdU0YqQQdbTMNLru8_Q@mail.gmail.com>
Message-ID: <CABL7CQiOYMv37UF3krg=hKxeNnYgqbCrKmFaeinixm-MnvH=ww@mail.gmail.com>

On Sat, Aug 24, 2013 at 10:39 AM, Saullo Castro <saullogiovani at gmail.com>wrote:

> Dear all,
>
> I already contacted Steven Johnson about this matter and he told me that "relicensing
> the Cubature code is not feasible", but he agrees on including this in
> SciPy if the SciPy community agrees to include a GNU GPL licensed software
> there.
>

Unfortunately it's not possible for us to include any GPL'd code.

>
> Otherwise I will probably create a separate Python package for it,
> ideally with a pip installer, as suggested by him.
>

That sounds like the way to go.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130824/9533b8fe/attachment.html>

From ralf.gommers at gmail.com  Sat Aug 24 05:11:36 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sat, 24 Aug 2013 11:11:36 +0200
Subject: [SciPy-Dev] ANN: Scipy 0.13.0 beta 1 release
In-Reply-To: <20130823235831.GA6527@bromo.med.uc.edu>
References: <CABL7CQga-Qkq8_hG1E+_KfpmVjSE-duyRePVcZw_-s-PXay75w@mail.gmail.com>
	<20130823235831.GA6527@bromo.med.uc.edu>
Message-ID: <CABL7CQhRQdzjedXid_B0VDc55-AiMnCbaryrPHwTjKSPsBvqyQ@mail.gmail.com>

On Sat, Aug 24, 2013 at 1:58 AM, Jack Howarth <howarth at bromo.med.uc.edu>wrote:

> On Thu, Aug 22, 2013 at 03:12:21PM +0200, Ralf Gommers wrote:
> > Hi all,
> >
> > I'm happy to announce the availability of the first beta release of Scipy
> > 0.13.0. Please try this beta and report any issues on the scipy-dev
> mailing
> > list.
> >
> > Source tarballs and release notes can be found at
> > https://sourceforge.net/projects/scipy/files/scipy/0.13.0b1/. Windows
> and
> > OS X installers will follow later (we have a minor infrastructure issue
> to
> > solve, and I'm at EuroScipy now).
> >
> > Cheers,
> > Ralf
>
> Ralf,
>    FYI, if the proposed elimination of support for the Accelerate
> framework on
> darwin was implemented in scipy 0.13, you will definietely want to
> consider reverting that
> change. It appears that the issues in the Accelerate framework (at least as
> tested with scipy 0.12.0) are resolved in the next darwin release...
>

Hi Jack, the issues appear to have been resolved completely (thanks to
Michael Wimmer and Pauli), so we didn't drop support or used OpenBLAS for
the binaries.

Ralf



> Ran 6134 tests in 88.016s
>
> OK (KNOWNFAIL=15, SKIP=36)
>
> compared to darwin12...
>
> Ran 6134 tests in 96.886s
>
> FAILED (KNOWNFAIL=15, SKIP=36, failures=63)
>
> and darwin11...
>
> Ran 6134 tests in 118.346s
>
> FAILED (KNOWNFAIL=15, SKIP=36, failures=65)
>
>              Jack
> ps I have looked at the proposed replacement of using openblas and it is
> rather suboptimal. Please
> don't inflict that on us.
>
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130824/e5034b20/attachment.html>

From saullogiovani at gmail.com  Sat Aug 24 09:51:45 2013
From: saullogiovani at gmail.com (Saullo Castro)
Date: Sat, 24 Aug 2013 15:51:45 +0200
Subject: [SciPy-Dev] Need some help to wrap the cubature package in
	scipy/integrate
Message-ID: <CAHbwRz7vbB+KKi9u7MzHMEtje5sM_Si2xLmKVMdAVzvrLYkOtQ@mail.gmail.com>

Just to update you guys,

since the matter regarding the Cubature license incompatility is not
closed, I decided to move the wrapper development from my scipy forked
repository to a new one. Here is the link:

https://github.com/saullocastro/cubature

if you wish to keep track of it. The wrapper is working so far and now I
will start writing all the testing functions, some scripts for benchmarking
and the documentation.

Please, let's try to include it in scipy/integrate.


Greetings,
Saullo


2013/8/23 <scipy-dev-request at scipy.org>

> Send SciPy-Dev mailing list submissions to
>         scipy-dev at scipy.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://mail.scipy.org/mailman/listinfo/scipy-dev
> or, via email, send a message with subject or body 'help' to
>         scipy-dev-request at scipy.org
>
> You can reach the person managing the list at
>         scipy-dev-owner at scipy.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of SciPy-Dev digest..."
>
>
> Today's Topics:
>
>    1. Re: Loss of precision using lsoda f2py interface or ode   class
>       (Joris Vankerschaver)
>    2. Re: Need some help to wrap the cubature package in
>       scipy/integrate (Nathan Woods)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 23 Aug 2013 14:56:49 +0200
> From: Joris Vankerschaver <jvankers at gmail.com>
> Subject: Re: [SciPy-Dev] Loss of precision using lsoda f2py interface
>         or ode  class
> To: SciPy Developers List <scipy-dev at scipy.org>
> Message-ID: <504DC808-6E3E-436B-A936-696B51834882 at gmail.com>
> Content-Type: text/plain; charset=us-ascii
>
> On 23-aug-2013, at 02:15, Juan Luis Cano wrote:
> > I fear odeint/ode bugs are starting to pile up (gh-1567, gh-1801,
> > gh-1976, gh-2515, gh-2570), and as many have suggested in the past a
> > rewrite or redesign would be quite helpful.
>
> This may have been pointed out before, but one inconsistency that should
> be fixed in an eventual redesign is that scipy.integrate.ode expects an RHS
> of the form `f(t, y0, ...)` whereas odeint expects an RHS with the first
> two parameters reversed, i.e. of the form `f(y0, t, ...)`. The former
> convention is the standard in Matlab and Sage.
>
> All the best,
> Joris
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 23 Aug 2013 10:22:01 -0600
> From: Nathan Woods <charlesnwoods at gmail.com>
> Subject: Re: [SciPy-Dev] Need some help to wrap the cubature package
>         in      scipy/integrate
> To: SciPy Developers List <scipy-dev at scipy.org>
> Message-ID: <-1837672449859755872 at unknownmsgid>
> Content-Type: text/plain; charset="iso-8859-1"
>
> We just had a multidimensional integrator (nquad) wrapped into the latest
> beta version of scipy. How does cubature compare? I've been kicking around
> the idea of improving the speed of nquad by moving more of the code to a
> compiled language. How would that compare?
>
> Nate
>
>
> On Aug 23, 2013, at 5:35 AM, Saullo Castro <saullogiovani at gmail.com>
> wrote:
>
> I am wrapping the Cubature package for multi-dimensional integration that
> supports vector-valued functions and offers both fixed and adaptive
> integration schemes.
>
> Please, see more details here:
> http://ab-initio.mit.edu/wiki/index.php/Cubature
>
> I've forked the scipy repository and my current attempt can be directly
> accessed here:
>
>
> https://github.com/saullocastro/scipy/blob/master/scipy/integrate/_cubature.pyx
>
> When compiling the cython code I am getting the error:
>
> _cubature.obj : error LNK2019: unresolved external symbol hcubature
> referenced in function __pyx_pf_9_cubature_fhcubature
> C:\usr\scipy\scipy\integrate\_cubature.pyd : fatal error LNK1120: 1
> unresolved externals
> error: command 'link.exe' failed with exit status 1120
>
> Could you please have a look?
>
> Thank you very much!
> Saullo
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mail.scipy.org/pipermail/scipy-dev/attachments/20130823/70c59ad6/attachment-0001.html
>
> ------------------------------
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
> End of SciPy-Dev Digest, Vol 118, Issue 31
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130824/fbf6b9e8/attachment.html>

From warren.weckesser at gmail.com  Sat Aug 24 10:47:01 2013
From: warren.weckesser at gmail.com (Warren Weckesser)
Date: Sat, 24 Aug 2013 10:47:01 -0400
Subject: [SciPy-Dev] cubature license
In-Reply-To: <CAHbwRz71bNbcFOLq95Dq3UsaF-r-18e_obw1Y6295PSk5E-tnA@mail.gmail.com>
References: <CAHbwRz71bNbcFOLq95Dq3UsaF-r-18e_obw1Y6295PSk5E-tnA@mail.gmail.com>
Message-ID: <CAGzF1ucoGXjQe7d65wfecUBV86EMMxL8J52LdFXqmR-=G4TpCQ@mail.gmail.com>

On 8/24/13, Saullo Castro <saullogiovani at gmail.com> wrote:
> @Alex,
>
> you are right, "it uses some GPL code from other projects (Hintlib and
> GSL).
> "
>
> But is it really impossible to include it in SciPy because of that?


Yes.  We do not include GPL-licensed code in SciPy.  I haven't looked
at the Cubature code, so I don't know the extent to which it uses
HIntLib and GSL, but based on the comment on the web page, it is
unlikely that Steven Johnson can re-license his code with a license
that is compatible with SciPy.  The GPL is viral that way (insert the
usual "I am not a lawyer" disclaimer here).

But don't let that stop you from creating a python wrapper as a
separate project.  That's a great idea, and I'm sure a lot of folks
will appreciate it.

Warren


>
> Saullo
>
> 2013/8/24 <scipy-dev-request at scipy.org>
>
>> Send SciPy-Dev mailing list submissions to
>>         scipy-dev at scipy.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         http://mail.scipy.org/mailman/listinfo/scipy-dev
>> or, via email, send a message with subject or body 'help' to
>>         scipy-dev-request at scipy.org
>>
>> You can reach the person managing the list at
>>         scipy-dev-owner at scipy.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of SciPy-Dev digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Re: SciPy-Dev Digest, Vol 118, Issue 32 (Saullo Castro)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Sat, 24 Aug 2013 10:39:03 +0200
>> From: Saullo Castro <saullogiovani at gmail.com>
>> Subject: Re: [SciPy-Dev] SciPy-Dev Digest, Vol 118, Issue 32
>> To: Scipy-Dev <scipy-dev at scipy.org>
>> Message-ID:
>>         <CAHbwRz50dGBAp50xPXvcG+HV=
>> XQotXJFdU0YqQQdbTMNLru8_Q at mail.gmail.com>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Dear all,
>>
>> I already contacted Steven Johnson about this matter and he told me
>> that "relicensing
>> the Cubature code is not feasible", but he agrees on including this in
>> SciPy if the SciPy community agrees to include a GNU GPL licensed
>> software
>> there.
>>
>> Otherwise I will probably create a separate Python package for it,
>> ideally
>> with a pip installer, as suggested by him.
>>
>> Greetings,
>> Saullo
>>
>>
>> 2013/8/24 <scipy-dev-request at scipy.org>
>>
>> > Send SciPy-Dev mailing list submissions to
>> >         scipy-dev at scipy.org
>> >
>> > To subscribe or unsubscribe via the World Wide Web, visit
>> >         http://mail.scipy.org/mailman/listinfo/scipy-dev
>> > or, via email, send a message with subject or body 'help' to
>> >         scipy-dev-request at scipy.org
>> >
>> > You can reach the person managing the list at
>> >         scipy-dev-owner at scipy.org
>> >
>> > When replying, please edit your Subject line so it is more specific
>> > than "Re: Contents of SciPy-Dev digest..."
>> >
>> >
>> > Today's Topics:
>> >
>> >    1. cubature license (alex)
>> >    2. Re: cubature license (Matt Redmond)
>> >    3. Re: cubature license (alex)
>> >    4. Re: cubature license (Charles R Harris)
>> >    5. Re: ANN: Scipy 0.13.0 beta 1 release (Jack Howarth)
>> >    6. Re: SciPy-Dev Digest, Vol 118, Issue 31 (Saullo Castro)
>> >
>> >
>> > ----------------------------------------------------------------------
>> >
>> > Message: 1
>> > Date: Fri, 23 Aug 2013 13:20:19 -0400
>> > From: alex <argriffi at ncsu.edu>
>> > Subject: [SciPy-Dev] cubature license
>> > To: scipy-dev at scipy.org
>> > Message-ID:
>> >         <CAE5GFc+F+gxTctEcJLxO_wRadVLOE=
>> > o0XGDEVNy0hb0qu0ip0g at mail.gmail.com>
>> > Content-Type: text/plain; charset=ISO-8859-1
>> >
>> > I noticed on the mailing list that someone wants to put cubature into
>> > scipy.  You will need to ask Steven Johnson before this can happen
>> > because scipy is licensed in a way that does not allow it to accept
>> > GPL code.  Actually now that I read more, this will probably not
>> > happen anyway because cubature itself depends on multiple GPL-licensed
>> > codes.
>> > http://mail.scipy.org/pipermail/scipy-dev/2013-August/thread.html
>> > http://ab-initio.mit.edu/wiki/index.php/Cubature
>> >
>> > Alex
>> >
>> >
>> > ------------------------------
>> >
>> > Message: 2
>> > Date: Fri, 23 Aug 2013 11:18:09 -0700
>> > From: Matt Redmond <mrdmnd at mit.edu>
>> > Subject: Re: [SciPy-Dev] cubature license
>> > To: SciPy Developers List <scipy-dev at scipy.org>
>> > Message-ID:
>> >         <
>> > CABTWFhGzjRPgDRmc5Q3csTAiN3yLMk8H6qP_Rvxo15RPRNo0Mg at mail.gmail.com>
>> > Content-Type: text/plain; charset="utf-8"
>> >
>> > I took a number of his classes at MIT, and I'm fairly sure he'd be on
>> board
>> > with this usage. He seemed pretty supportive of SciPy.
>> >
>> >
>> > On Fri, Aug 23, 2013 at 10:28 AM, Matt Redmond <mttrdmnd at gmail.com>
>> wrote:
>> >
>> > > I'll ask him - I took his classes at MIT and I'm fairly sure he'd be
>> okay
>> > > with this.
>> > >
>> > >
>> > > On Fri, Aug 23, 2013 at 10:20 AM, alex <argriffi at ncsu.edu> wrote:
>> > >
>> > >> I noticed on the mailing list that someone wants to put cubature
>> > >> into
>> > >> scipy.  You will need to ask Steven Johnson before this can happen
>> > >> because scipy is licensed in a way that does not allow it to accept
>> > >> GPL code.  Actually now that I read more, this will probably not
>> > >> happen anyway because cubature itself depends on multiple
>> > >> GPL-licensed
>> > >> codes.
>> > >> http://mail.scipy.org/pipermail/scipy-dev/2013-August/thread.html
>> > >> http://ab-initio.mit.edu/wiki/index.php/Cubature
>> > >>
>> > >> Alex
>> > >> _______________________________________________
>> > >> SciPy-Dev mailing list
>> > >> SciPy-Dev at scipy.org
>> > >> http://mail.scipy.org/mailman/listinfo/scipy-dev
>> > >>
>> > >
>> > >
>> > >
>> > > --
>> > > Matthew Redmond
>> > > Massachusetts Institute of Technology
>> > > Department of Mathematics, Course 18C
>> > > Class of 2013
>> > >
>> > -------------- next part --------------
>> > An HTML attachment was scrubbed...
>> > URL:
>> >
>> http://mail.scipy.org/pipermail/scipy-dev/attachments/20130823/c51a46f9/attachment-0001.html
>> >
>> > ------------------------------
>> >
>> > Message: 3
>> > Date: Fri, 23 Aug 2013 14:27:45 -0400
>> > From: alex <argriffi at ncsu.edu>
>> > Subject: Re: [SciPy-Dev] cubature license
>> > To: SciPy Developers List <scipy-dev at scipy.org>
>> > Message-ID:
>> >         <
>> > CAE5GFcJdW_4iW5Fbqe+7uAhGO2nMmN2+aDxTJSsz9DubFDeAeA at mail.gmail.com>
>> > Content-Type: text/plain; charset=ISO-8859-1
>> >
>> > On Fri, Aug 23, 2013 at 2:18 PM, Matt Redmond <mrdmnd at mit.edu> wrote:
>> > > I took a number of his classes at MIT, and I'm fairly sure he'd be on
>> > board
>> > > with this usage. He seemed pretty supportive of SciPy.
>> > >
>> > >
>> > > On Fri, Aug 23, 2013 at 10:28 AM, Matt Redmond <mttrdmnd at gmail.com>
>> > wrote:
>> > >>
>> > >> I'll ask him - I took his classes at MIT and I'm fairly sure he'd be
>> > okay
>> > >> with this.
>> > >>
>> > >>
>> > >> On Fri, Aug 23, 2013 at 10:20 AM, alex <argriffi at ncsu.edu> wrote:
>> > >>>
>> > >>> I noticed on the mailing list that someone wants to put cubature
>> > >>> into
>> > >>> scipy.  You will need to ask Steven Johnson before this can happen
>> > >>> because scipy is licensed in a way that does not allow it to accept
>> > >>> GPL code.  Actually now that I read more, this will probably not
>> > >>> happen anyway because cubature itself depends on multiple
>> GPL-licensed
>> > >>> codes.
>> > >>> http://mail.scipy.org/pipermail/scipy-dev/2013-August/thread.html
>> > >>> http://ab-initio.mit.edu/wiki/index.php/Cubature
>> > >>>
>> > >>> Alex
>> > >>> _______________________________________________
>> > >>> SciPy-Dev mailing list
>> > >>> SciPy-Dev at scipy.org
>> > >>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> --
>> > >> Matthew Redmond
>> > >> Massachusetts Institute of Technology
>> > >> Department of Mathematics, Course 18C
>> > >> Class of 2013
>> > >
>> > >
>> > >
>> > > _______________________________________________
>> > > SciPy-Dev mailing list
>> > > SciPy-Dev at scipy.org
>> > > http://mail.scipy.org/mailman/listinfo/scipy-dev
>> > >
>> >
>> > Even if he would personally be on board with this usage, the following
>> > bit makes it complicated.
>> >
>> > "Our code is based in part on code borrowed from the HIntLib
>> > numeric-integration library by Rudolf Sch?rer and from code for
>> > Gauss-Kronrod quadrature (for 1d integrals) from the GNU Scientific
>> > Library, both of which are free software under the GNU GPL."
>> >
>> > Alex
>> >
>> >
>> > ------------------------------
>> >
>> > Message: 4
>> > Date: Fri, 23 Aug 2013 13:09:15 -0600
>> > From: Charles R Harris <charlesr.harris at gmail.com>
>> > Subject: Re: [SciPy-Dev] cubature license
>> > To: SciPy Developers List <scipy-dev at scipy.org>
>> > Message-ID:
>> >         <CAB6mnxKaknribvOT7U8qGLnt_sfXpXkvVZKbviksqHH1U=
>> > NFQA at mail.gmail.com>
>> > Content-Type: text/plain; charset="iso-8859-1"
>> >
>> > Ah, memories. It might not be too hard to replace the Gauss-Kronrad
>> > quadrature, it was the first algorithm I implemented on a 80186 3MHz PC
>> > back in the days when Microsoft offered a Fortran compiler ;) I don't
>> know
>> > about the rest of the dependencies.
>> >
>> >
>> > On Fri, Aug 23, 2013 at 12:27 PM, alex <argriffi at ncsu.edu> wrote:
>> >
>> > > On Fri, Aug 23, 2013 at 2:18 PM, Matt Redmond <mrdmnd at mit.edu> wrote:
>> > > > I took a number of his classes at MIT, and I'm fairly sure he'd be
>> > > > on
>> > > board
>> > > > with this usage. He seemed pretty supportive of SciPy.
>> > > >
>> > > >
>> > > > On Fri, Aug 23, 2013 at 10:28 AM, Matt Redmond <mttrdmnd at gmail.com>
>> > > wrote:
>> > > >>
>> > > >> I'll ask him - I took his classes at MIT and I'm fairly sure he'd
>> > > >> be
>> > > okay
>> > > >> with this.
>> > > >>
>> > > >>
>> > > >> On Fri, Aug 23, 2013 at 10:20 AM, alex <argriffi at ncsu.edu> wrote:
>> > > >>>
>> > > >>> I noticed on the mailing list that someone wants to put cubature
>> into
>> > > >>> scipy.  You will need to ask Steven Johnson before this can
>> > > >>> happen
>> > > >>> because scipy is licensed in a way that does not allow it to
>> > > >>> accept
>> > > >>> GPL code.  Actually now that I read more, this will probably not
>> > > >>> happen anyway because cubature itself depends on multiple
>> > GPL-licensed
>> > > >>> codes.
>> > > >>> http://mail.scipy.org/pipermail/scipy-dev/2013-August/thread.html
>> > > >>> http://ab-initio.mit.edu/wiki/index.php/Cubature
>> > > >>>
>> > > >>> Alex
>> > > >>> _______________________________________________
>> > > >>> SciPy-Dev mailing list
>> > > >>> SciPy-Dev at scipy.org
>> > > >>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >> --
>> > > >> Matthew Redmond
>> > > >> Massachusetts Institute of Technology
>> > > >> Department of Mathematics, Course 18C
>> > > >> Class of 2013
>> > > >
>> > > >
>> > > >
>> > > > _______________________________________________
>> > > > SciPy-Dev mailing list
>> > > > SciPy-Dev at scipy.org
>> > > > http://mail.scipy.org/mailman/listinfo/scipy-dev
>> > > >
>> > >
>> > > Even if he would personally be on board with this usage, the
>> > > following
>> > > bit makes it complicated.
>> > >
>> > > "Our code is based in part on code borrowed from the HIntLib
>> > > numeric-integration library by Rudolf Sch?rer and from code for
>> > > Gauss-Kronrod quadrature (for 1d integrals) from the GNU Scientific
>> > > Library, both of which are free software under the GNU GPL."
>> > >
>> > > Alex
>> > > _______________________________________________
>> > > SciPy-Dev mailing list
>> > > SciPy-Dev at scipy.org
>> > > http://mail.scipy.org/mailman/listinfo/scipy-dev
>> > >
>> > -------------- next part --------------
>> > An HTML attachment was scrubbed...
>> > URL:
>> >
>> http://mail.scipy.org/pipermail/scipy-dev/attachments/20130823/efc1ee20/attachment-0001.html
>> >
>> > ------------------------------
>> >
>> > Message: 5
>> > Date: Fri, 23 Aug 2013 19:58:31 -0400
>> > From: Jack Howarth <howarth at bromo.med.uc.edu>
>> > Subject: Re: [SciPy-Dev] ANN: Scipy 0.13.0 beta 1 release
>> > To: SciPy Developers List <scipy-dev at scipy.org>
>> > Message-ID: <20130823235831.GA6527 at bromo.med.uc.edu>
>> > Content-Type: text/plain; charset=us-ascii
>> >
>> > On Thu, Aug 22, 2013 at 03:12:21PM +0200, Ralf Gommers wrote:
>> > > Hi all,
>> > >
>> > > I'm happy to announce the availability of the first beta release of
>> Scipy
>> > > 0.13.0. Please try this beta and report any issues on the scipy-dev
>> > mailing
>> > > list.
>> > >
>> > > Source tarballs and release notes can be found at
>> > > https://sourceforge.net/projects/scipy/files/scipy/0.13.0b1/. Windows
>> > and
>> > > OS X installers will follow later (we have a minor infrastructure
>> > > issue
>> > to
>> > > solve, and I'm at EuroScipy now).
>> > >
>> > > Cheers,
>> > > Ralf
>> >
>> > Ralf,
>> >    FYI, if the proposed elimination of support for the Accelerate
>> > framework on
>> > darwin was implemented in scipy 0.13, you will definietely want to
>> > consider reverting that
>> > change. It appears that the issues in the Accelerate framework (at
>> > least
>> as
>> > tested with scipy 0.12.0) are resolved in the next darwin release...
>> >
>> > Ran 6134 tests in 88.016s
>> >
>> > OK (KNOWNFAIL=15, SKIP=36)
>> >
>> > compared to darwin12...
>> >
>> > Ran 6134 tests in 96.886s
>> >
>> > FAILED (KNOWNFAIL=15, SKIP=36, failures=63)
>> >
>> > and darwin11...
>> >
>> > Ran 6134 tests in 118.346s
>> >
>> > FAILED (KNOWNFAIL=15, SKIP=36, failures=65)
>> >
>> >              Jack
>> > ps I have looked at the proposed replacement of using openblas and it
>> > is
>> > rather suboptimal. Please
>> > don't inflict that on us.
>> >
>> > > _______________________________________________
>> > > SciPy-Dev mailing list
>> > > SciPy-Dev at scipy.org
>> > > http://mail.scipy.org/mailman/listinfo/scipy-dev
>> >
>> >
>> >
>> > ------------------------------
>> >
>> > Message: 6
>> > Date: Sat, 24 Aug 2013 10:29:12 +0200
>> > From: Saullo Castro <saullogiovani at gmail.com>
>> > Subject: Re: [SciPy-Dev] SciPy-Dev Digest, Vol 118, Issue 31
>> > To: Scipy-Dev <scipy-dev at scipy.org>
>> > Message-ID:
>> >         <CAHbwRz4ihS6YzevgPdDZ131=
>> > QgOrSRjJBjRn1t8saN4L0sq-JA at mail.gmail.com>
>> > Content-Type: text/plain; charset="iso-8859-1"
>> >
>> > @Nate,
>> >
>> > I don't know all the details about this algorithm, but based on the
>> > tests
>> > I've performed here it requires much fewer function evaluations than
>> > dblquad or tplquad, since it is NOT a recursive call of 1D-integrands.
>> >
>> > It offers two refinement options:
>> >
>> > h-cubature which refines by including more integration points
>> > p-cubature which refines by increasing the approximation order (better
>> for
>> > smooth functions)
>> >
>> > I will keep working on that and I hope to give you a better feedback
>> > very
>> > soon. Please, see more details here:
>> > http://ab-initio.mit.edu/wiki/index.php/Cubature
>> >
>> > Greetings,
>> > Saullo
>> >
>> >
>> > 2013/8/23 <scipy-dev-request at scipy.org>
>> >
>> > > Send SciPy-Dev mailing list submissions to
>> > >         scipy-dev at scipy.org
>> > >
>> > > To subscribe or unsubscribe via the World Wide Web, visit
>> > >         http://mail.scipy.org/mailman/listinfo/scipy-dev
>> > > or, via email, send a message with subject or body 'help' to
>> > >         scipy-dev-request at scipy.org
>> > >
>> > > You can reach the person managing the list at
>> > >         scipy-dev-owner at scipy.org
>> > >
>> > > When replying, please edit your Subject line so it is more specific
>> > > than "Re: Contents of SciPy-Dev digest..."
>> > >
>> > >
>> > > Today's Topics:
>> > >
>> > >    1. Re: Loss of precision using lsoda f2py interface or ode   class
>> > >       (Joris Vankerschaver)
>> > >    2. Re: Need some help to wrap the cubature package in
>> > >       scipy/integrate (Nathan Woods)
>> > >
>> > >
>> > > ----------------------------------------------------------------------
>> > >
>> > > Message: 1
>> > > Date: Fri, 23 Aug 2013 14:56:49 +0200
>> > > From: Joris Vankerschaver <jvankers at gmail.com>
>> > > Subject: Re: [SciPy-Dev] Loss of precision using lsoda f2py interface
>> > >         or ode  class
>> > > To: SciPy Developers List <scipy-dev at scipy.org>
>> > > Message-ID: <504DC808-6E3E-436B-A936-696B51834882 at gmail.com>
>> > > Content-Type: text/plain; charset=us-ascii
>> > >
>> > > On 23-aug-2013, at 02:15, Juan Luis Cano wrote:
>> > > > I fear odeint/ode bugs are starting to pile up (gh-1567, gh-1801,
>> > > > gh-1976, gh-2515, gh-2570), and as many have suggested in the past
>> > > > a
>> > > > rewrite or redesign would be quite helpful.
>> > >
>> > > This may have been pointed out before, but one inconsistency that
>> should
>> > > be fixed in an eventual redesign is that scipy.integrate.ode expects
>> > > an
>> > RHS
>> > > of the form `f(t, y0, ...)` whereas odeint expects an RHS with the
>> first
>> > > two parameters reversed, i.e. of the form `f(y0, t, ...)`. The former
>> > > convention is the standard in Matlab and Sage.
>> > >
>> > > All the best,
>> > > Joris
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > ------------------------------
>> > >
>> > > Message: 2
>> > > Date: Fri, 23 Aug 2013 10:22:01 -0600
>> > > From: Nathan Woods <charlesnwoods at gmail.com>
>> > > Subject: Re: [SciPy-Dev] Need some help to wrap the cubature package
>> > >         in      scipy/integrate
>> > > To: SciPy Developers List <scipy-dev at scipy.org>
>> > > Message-ID: <-1837672449859755872 at unknownmsgid>
>> > > Content-Type: text/plain; charset="iso-8859-1"
>> > >
>> > > We just had a multidimensional integrator (nquad) wrapped into the
>> latest
>> > > beta version of scipy. How does cubature compare? I've been kicking
>> > around
>> > > the idea of improving the speed of nquad by moving more of the code
>> > > to
>> a
>> > > compiled language. How would that compare?
>> > >
>> > > Nate
>> > >
>> > >
>> > > On Aug 23, 2013, at 5:35 AM, Saullo Castro <saullogiovani at gmail.com>
>> > > wrote:
>> > >
>> > > I am wrapping the Cubature package for multi-dimensional integration
>> that
>> > > supports vector-valued functions and offers both fixed and adaptive
>> > > integration schemes.
>> > >
>> > > Please, see more details here:
>> > > http://ab-initio.mit.edu/wiki/index.php/Cubature
>> > >
>> > > I've forked the scipy repository and my current attempt can be
>> > > directly
>> > > accessed here:
>> > >
>> > >
>> > >
>> >
>> https://github.com/saullocastro/scipy/blob/master/scipy/integrate/_cubature.pyx
>> > >
>> > > When compiling the cython code I am getting the error:
>> > >
>> > > _cubature.obj : error LNK2019: unresolved external symbol hcubature
>> > > referenced in function __pyx_pf_9_cubature_fhcubature
>> > > C:\usr\scipy\scipy\integrate\_cubature.pyd : fatal error LNK1120: 1
>> > > unresolved externals
>> > > error: command 'link.exe' failed with exit status 1120
>> > >
>> > > Could you please have a look?
>> > >
>> > > Thank you very much!
>> > > Saullo
>> > >
>> > > _______________________________________________
>> > > SciPy-Dev mailing list
>> > > SciPy-Dev at scipy.org
>> > > http://mail.scipy.org/mailman/listinfo/scipy-dev
>> > > -------------- next part --------------
>> > > An HTML attachment was scrubbed...
>> > > URL:
>> > >
>> >
>> http://mail.scipy.org/pipermail/scipy-dev/attachments/20130823/70c59ad6/attachment-0001.html
>> > >
>> > > ------------------------------
>> > >
>> > > _______________________________________________
>> > > SciPy-Dev mailing list
>> > > SciPy-Dev at scipy.org
>> > > http://mail.scipy.org/mailman/listinfo/scipy-dev
>> > >
>> > >
>> > > End of SciPy-Dev Digest, Vol 118, Issue 31
>> > > ******************************************
>> > >
>> > -------------- next part --------------
>> > An HTML attachment was scrubbed...
>> > URL:
>> >
>> http://mail.scipy.org/pipermail/scipy-dev/attachments/20130824/dbbdbb26/attachment.html
>> >
>> > ------------------------------
>> >
>> > _______________________________________________
>> > SciPy-Dev mailing list
>> > SciPy-Dev at scipy.org
>> > http://mail.scipy.org/mailman/listinfo/scipy-dev
>> >
>> >
>> > End of SciPy-Dev Digest, Vol 118, Issue 32
>> > ******************************************
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> http://mail.scipy.org/pipermail/scipy-dev/attachments/20130824/2f02c5bb/attachment.html
>>
>> ------------------------------
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
>> End of SciPy-Dev Digest, Vol 118, Issue 33
>> ******************************************
>>
>


From robert.kern at gmail.com  Sat Aug 24 10:53:10 2013
From: robert.kern at gmail.com (Robert Kern)
Date: Sat, 24 Aug 2013 16:53:10 +0200
Subject: [SciPy-Dev] cubature license
In-Reply-To: <CAGzF1ucoGXjQe7d65wfecUBV86EMMxL8J52LdFXqmR-=G4TpCQ@mail.gmail.com>
References: <CAHbwRz71bNbcFOLq95Dq3UsaF-r-18e_obw1Y6295PSk5E-tnA@mail.gmail.com>
	<CAGzF1ucoGXjQe7d65wfecUBV86EMMxL8J52LdFXqmR-=G4TpCQ@mail.gmail.com>
Message-ID: <CAF6FJivScnjqnAZO8OJ0XZpJ48+KsC5rdOmE+5z-EWWJn7iH_g@mail.gmail.com>

On Sat, Aug 24, 2013 at 4:47 PM, Warren Weckesser <
warren.weckesser at gmail.com> wrote:
>
> On 8/24/13, Saullo Castro <saullogiovani at gmail.com> wrote:
> > @Alex,
> >
> > you are right, "it uses some GPL code from other projects (Hintlib and
> > GSL).
> > "
> >
> > But is it really impossible to include it in SciPy because of that?
>
> Yes.  We do not include GPL-licensed code in SciPy.  I haven't looked
> at the Cubature code, so I don't know the extent to which it uses
> HIntLib and GSL, but based on the comment on the web page, it is
> unlikely that Steven Johnson can re-license his code with a license
> that is compatible with SciPy.  The GPL is viral that way (insert the
> usual "I am not a lawyer" disclaimer here).

It's not quite as viral as that. He can license the code that he himself
wrote under whatever license he likes as long as it is compatible with the
GPL license of the other libraries that he is combining his code with. If
the code that he wrote is separable from HIntLib and GSL by rewriting that
functionality, he can distribute his code under the BSD license for
inclusion in SciPy.

--
Robert Kern
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130824/e75eadc8/attachment.html>

From warren.weckesser at gmail.com  Sat Aug 24 11:04:51 2013
From: warren.weckesser at gmail.com (Warren Weckesser)
Date: Sat, 24 Aug 2013 11:04:51 -0400
Subject: [SciPy-Dev] cubature license
In-Reply-To: <CAF6FJivScnjqnAZO8OJ0XZpJ48+KsC5rdOmE+5z-EWWJn7iH_g@mail.gmail.com>
References: <CAHbwRz71bNbcFOLq95Dq3UsaF-r-18e_obw1Y6295PSk5E-tnA@mail.gmail.com>
	<CAGzF1ucoGXjQe7d65wfecUBV86EMMxL8J52LdFXqmR-=G4TpCQ@mail.gmail.com>
	<CAF6FJivScnjqnAZO8OJ0XZpJ48+KsC5rdOmE+5z-EWWJn7iH_g@mail.gmail.com>
Message-ID: <CAGzF1ufwXi4UoGeCwvBN1HCJbigGKtpYisM8KFEc9n5NAhyNtA@mail.gmail.com>

On 8/24/13, Robert Kern <robert.kern at gmail.com> wrote:
> On Sat, Aug 24, 2013 at 4:47 PM, Warren Weckesser <
> warren.weckesser at gmail.com> wrote:
>>
>> On 8/24/13, Saullo Castro <saullogiovani at gmail.com> wrote:
>> > @Alex,
>> >
>> > you are right, "it uses some GPL code from other projects (Hintlib and
>> > GSL).
>> > "
>> >
>> > But is it really impossible to include it in SciPy because of that?
>>
>> Yes.  We do not include GPL-licensed code in SciPy.  I haven't looked
>> at the Cubature code, so I don't know the extent to which it uses
>> HIntLib and GSL, but based on the comment on the web page, it is
>> unlikely that Steven Johnson can re-license his code with a license
>> that is compatible with SciPy.  The GPL is viral that way (insert the
>> usual "I am not a lawyer" disclaimer here).
>
> It's not quite as viral as that. He can license the code that he himself
> wrote under whatever license he likes as long as it is compatible with the
> GPL license of the other libraries that he is combining his code with. If
> the code that he wrote is separable from HIntLib and GSL by rewriting that
> functionality, he can distribute his code under the BSD license for
> inclusion in SciPy.


Yes--thanks for the clarification.

Warren


>
> --
> Robert Kern
>


From warren.weckesser at gmail.com  Sat Aug 24 11:16:16 2013
From: warren.weckesser at gmail.com (Warren Weckesser)
Date: Sat, 24 Aug 2013 11:16:16 -0400
Subject: [SciPy-Dev] cubature license
In-Reply-To: <CAGzF1ufwXi4UoGeCwvBN1HCJbigGKtpYisM8KFEc9n5NAhyNtA@mail.gmail.com>
References: <CAHbwRz71bNbcFOLq95Dq3UsaF-r-18e_obw1Y6295PSk5E-tnA@mail.gmail.com>
	<CAGzF1ucoGXjQe7d65wfecUBV86EMMxL8J52LdFXqmR-=G4TpCQ@mail.gmail.com>
	<CAF6FJivScnjqnAZO8OJ0XZpJ48+KsC5rdOmE+5z-EWWJn7iH_g@mail.gmail.com>
	<CAGzF1ufwXi4UoGeCwvBN1HCJbigGKtpYisM8KFEc9n5NAhyNtA@mail.gmail.com>
Message-ID: <CAGzF1uezSbAmsWNwSyfRug5tz08UA1pe7pUeeBYVE1tmykSWrw@mail.gmail.com>

On 8/24/13, Warren Weckesser <warren.weckesser at gmail.com> wrote:
> On 8/24/13, Robert Kern <robert.kern at gmail.com> wrote:
>> On Sat, Aug 24, 2013 at 4:47 PM, Warren Weckesser <
>> warren.weckesser at gmail.com> wrote:
>>>
>>> On 8/24/13, Saullo Castro <saullogiovani at gmail.com> wrote:
>>> > @Alex,
>>> >
>>> > you are right, "it uses some GPL code from other projects (Hintlib and
>>> > GSL).
>>> > "
>>> >
>>> > But is it really impossible to include it in SciPy because of that?
>>>
>>> Yes.  We do not include GPL-licensed code in SciPy.  I haven't looked
>>> at the Cubature code, so I don't know the extent to which it uses
>>> HIntLib and GSL, but based on the comment on the web page, it is
>>> unlikely that Steven Johnson can re-license his code with a license
>>> that is compatible with SciPy.  The GPL is viral that way (insert the
>>> usual "I am not a lawyer" disclaimer here).
>>
>> It's not quite as viral as that. He can license the code that he himself
>> wrote under whatever license he likes as long as it is compatible with
>> the
>> GPL license of the other libraries that he is combining his code with. If
>> the code that he wrote is separable from HIntLib and GSL by rewriting
>> that
>> functionality, he can distribute his code under the BSD license for
>> inclusion in SciPy.
>
>
> Yes--thanks for the clarification.
>
> Warren
>


P.S.:  Saullo, here are a couple links to more information about
compatible licenses:
http://wiki.scipy.org/License_Compatibility
http://matplotlib.org/devel/license.html#license-discussion (the
discussion of the matplotlib license is applicable to scipy)

Warren

>
>>
>> --
>> Robert Kern
>>
>


From saullogiovani at gmail.com  Sun Aug 25 02:40:09 2013
From: saullogiovani at gmail.com (Saullo Castro)
Date: Sun, 25 Aug 2013 08:40:09 +0200
Subject: [SciPy-Dev] cubature license
Message-ID: <CAHbwRz7Uy_=5o3Dvk=_M-3oKCAFuckZBHwBd+D6sKx4bTBP5OA@mail.gmail.com>

@Warren

from the good disccusion here (
http://matplotlib.org/devel/license.html#license-discussion)
it seems that the biggest difference between the GPL and the BSD is that
the former requires you to distribute your source code, and the BSD allows
you to do whatever you want...

I don't see the problem to include it in SciPy, since the source code is
always distributed. Even if third part companies like Enthought are using
it, it is more like a module, isn't it? and the core code behind it can
still be BSD  based.

Anyway, the software has a `clencurt_gen.c` stand-alone program which does
not have to be used unless the user whant a `p-adaptive` cubature with more
than 8193 points per dimension, this type of cubature applies
"p-refinement" (increase of interpolation function order) instead of
"h-refinement" (splitting the interval). I don't see a need to include this
program in the SciPy cubature. We can implement this restriction in the
wrapper.

I will ask Steven Johnson about this, if removing this part could make
cubature re-licensable to BSD.

Greetings!
Saullo


2013/8/24 <scipy-dev-request at scipy.org>

> Send SciPy-Dev mailing list submissions to
>         scipy-dev at scipy.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://mail.scipy.org/mailman/listinfo/scipy-dev
> or, via email, send a message with subject or body 'help' to
>         scipy-dev-request at scipy.org
>
> You can reach the person managing the list at
>         scipy-dev-owner at scipy.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of SciPy-Dev digest..."
>
>
> Today's Topics:
>
>    1. Re: cubature license (Robert Kern)
>    2. Re: cubature license (Warren Weckesser)
>    3. Re: cubature license (Warren Weckesser)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 24 Aug 2013 16:53:10 +0200
> From: Robert Kern <robert.kern at gmail.com>
> Subject: Re: [SciPy-Dev] cubature license
> To: SciPy Developers List <scipy-dev at scipy.org>
> Message-ID:
>         <
> CAF6FJivScnjqnAZO8OJ0XZpJ48+KsC5rdOmE+5z-EWWJn7iH_g at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Sat, Aug 24, 2013 at 4:47 PM, Warren Weckesser <
> warren.weckesser at gmail.com> wrote:
> >
> > On 8/24/13, Saullo Castro <saullogiovani at gmail.com> wrote:
> > > @Alex,
> > >
> > > you are right, "it uses some GPL code from other projects (Hintlib and
> > > GSL).
> > > "
> > >
> > > But is it really impossible to include it in SciPy because of that?
> >
> > Yes.  We do not include GPL-licensed code in SciPy.  I haven't looked
> > at the Cubature code, so I don't know the extent to which it uses
> > HIntLib and GSL, but based on the comment on the web page, it is
> > unlikely that Steven Johnson can re-license his code with a license
> > that is compatible with SciPy.  The GPL is viral that way (insert the
> > usual "I am not a lawyer" disclaimer here).
>
> It's not quite as viral as that. He can license the code that he himself
> wrote under whatever license he likes as long as it is compatible with the
> GPL license of the other libraries that he is combining his code with. If
> the code that he wrote is separable from HIntLib and GSL by rewriting that
> functionality, he can distribute his code under the BSD license for
> inclusion in SciPy.
>
> --
> Robert Kern
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mail.scipy.org/pipermail/scipy-dev/attachments/20130824/e75eadc8/attachment-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Sat, 24 Aug 2013 11:04:51 -0400
> From: Warren Weckesser <warren.weckesser at gmail.com>
> Subject: Re: [SciPy-Dev] cubature license
> To: SciPy Developers List <scipy-dev at scipy.org>
> Message-ID:
>         <
> CAGzF1ufwXi4UoGeCwvBN1HCJbigGKtpYisM8KFEc9n5NAhyNtA at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 8/24/13, Robert Kern <robert.kern at gmail.com> wrote:
> > On Sat, Aug 24, 2013 at 4:47 PM, Warren Weckesser <
> > warren.weckesser at gmail.com> wrote:
> >>
> >> On 8/24/13, Saullo Castro <saullogiovani at gmail.com> wrote:
> >> > @Alex,
> >> >
> >> > you are right, "it uses some GPL code from other projects (Hintlib and
> >> > GSL).
> >> > "
> >> >
> >> > But is it really impossible to include it in SciPy because of that?
> >>
> >> Yes.  We do not include GPL-licensed code in SciPy.  I haven't looked
> >> at the Cubature code, so I don't know the extent to which it uses
> >> HIntLib and GSL, but based on the comment on the web page, it is
> >> unlikely that Steven Johnson can re-license his code with a license
> >> that is compatible with SciPy.  The GPL is viral that way (insert the
> >> usual "I am not a lawyer" disclaimer here).
> >
> > It's not quite as viral as that. He can license the code that he himself
> > wrote under whatever license he likes as long as it is compatible with
> the
> > GPL license of the other libraries that he is combining his code with. If
> > the code that he wrote is separable from HIntLib and GSL by rewriting
> that
> > functionality, he can distribute his code under the BSD license for
> > inclusion in SciPy.
>
>
> Yes--thanks for the clarification.
>
> Warren
>
>
> >
> > --
> > Robert Kern
> >
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 24 Aug 2013 11:16:16 -0400
> From: Warren Weckesser <warren.weckesser at gmail.com>
> Subject: Re: [SciPy-Dev] cubature license
> To: SciPy Developers List <scipy-dev at scipy.org>
> Message-ID:
>         <
> CAGzF1uezSbAmsWNwSyfRug5tz08UA1pe7pUeeBYVE1tmykSWrw at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 8/24/13, Warren Weckesser <warren.weckesser at gmail.com> wrote:
> > On 8/24/13, Robert Kern <robert.kern at gmail.com> wrote:
> >> On Sat, Aug 24, 2013 at 4:47 PM, Warren Weckesser <
> >> warren.weckesser at gmail.com> wrote:
> >>>
> >>> On 8/24/13, Saullo Castro <saullogiovani at gmail.com> wrote:
> >>> > @Alex,
> >>> >
> >>> > you are right, "it uses some GPL code from other projects (Hintlib
> and
> >>> > GSL).
> >>> > "
> >>> >
> >>> > But is it really impossible to include it in SciPy because of that?
> >>>
> >>> Yes.  We do not include GPL-licensed code in SciPy.  I haven't looked
> >>> at the Cubature code, so I don't know the extent to which it uses
> >>> HIntLib and GSL, but based on the comment on the web page, it is
> >>> unlikely that Steven Johnson can re-license his code with a license
> >>> that is compatible with SciPy.  The GPL is viral that way (insert the
> >>> usual "I am not a lawyer" disclaimer here).
> >>
> >> It's not quite as viral as that. He can license the code that he himself
> >> wrote under whatever license he likes as long as it is compatible with
> >> the
> >> GPL license of the other libraries that he is combining his code with.
> If
> >> the code that he wrote is separable from HIntLib and GSL by rewriting
> >> that
> >> functionality, he can distribute his code under the BSD license for
> >> inclusion in SciPy.
> >
> >
> > Yes--thanks for the clarification.
> >
> > Warren
> >
>
>
> P.S.:  Saullo, here are a couple links to more information about
> compatible licenses:
> http://wiki.scipy.org/License_Compatibility
> http://matplotlib.org/devel/license.html#license-discussion (the
> discussion of the matplotlib license is applicable to scipy)
>
> Warren
>
> >
> >>
> >> --
> >> Robert Kern
> >>
> >
>
>
> ------------------------------
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
> End of SciPy-Dev Digest, Vol 118, Issue 36
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130825/ad359215/attachment.html>

From saullogiovani at gmail.com  Sun Aug 25 03:00:43 2013
From: saullogiovani at gmail.com (Saullo Castro)
Date: Sun, 25 Aug 2013 09:00:43 +0200
Subject: [SciPy-Dev] License compatibility SciPy -> MIT -> GPL
Message-ID: <CAHbwRz6xbrkErFK+X7KM0E+YwDA0FNWM+fq8jyk3PVqyPA6Pxw@mail.gmail.com>

Well, we've been discussion the license combatility for the cubature module.

>From the links @Warren gave me:
http://wiki.scipy.org/License_Compatibility
http://matplotlib.org/devel/license.html#license-discussion

it states that the MIT license is compatible with SciPy, and in the MIT
description in Wikipedia (http://en.wikipedia.org/wiki/MIT_License) it
states that this license is compatible with the GPL. So... is there a crack
here where we could place a GPL software in SciPy?

Thank you,
Saullo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130825/120d6050/attachment.html>

From matthieu.brucher at gmail.com  Sun Aug 25 03:11:40 2013
From: matthieu.brucher at gmail.com (Matthieu Brucher)
Date: Sun, 25 Aug 2013 08:11:40 +0100
Subject: [SciPy-Dev] License compatibility SciPy -> MIT -> GPL
In-Reply-To: <CAHbwRz6xbrkErFK+X7KM0E+YwDA0FNWM+fq8jyk3PVqyPA6Pxw@mail.gmail.com>
References: <CAHbwRz6xbrkErFK+X7KM0E+YwDA0FNWM+fq8jyk3PVqyPA6Pxw@mail.gmail.com>
Message-ID: <CAHCaCkKLLZSNYq+XHXt6xmAThWvA2wYeSBycp1LVvRNHxPGe2A@mail.gmail.com>

Hi
Unfortunately, it is the other way around: you can put bsd code in gpl
code, but if you put gpl code into bsd code, the latter has to be
relicensed. Btw, if you put gpl code indide mit code, the same has to be
done.

Cheers
Le 25 ao?t 2013 08:00, "Saullo Castro" <saullogiovani at gmail.com> a ?crit :

> Well, we've been discussion the license combatility for the cubature
> module.
>
> From the links @Warren gave me:
> http://wiki.scipy.org/License_Compatibility
> http://matplotlib.org/devel/license.html#license-discussion
>
> it states that the MIT license is compatible with SciPy, and in the MIT
> description in Wikipedia (http://en.wikipedia.org/wiki/MIT_License) it
> states that this license is compatible with the GPL. So... is there a crack
> here where we could place a GPL software in SciPy?
>
> Thank you,
> Saullo
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130825/a503d34c/attachment.html>

From robert.kern at gmail.com  Sun Aug 25 03:46:00 2013
From: robert.kern at gmail.com (Robert Kern)
Date: Sun, 25 Aug 2013 09:46:00 +0200
Subject: [SciPy-Dev] License compatibility SciPy -> MIT -> GPL
In-Reply-To: <CAHbwRz6xbrkErFK+X7KM0E+YwDA0FNWM+fq8jyk3PVqyPA6Pxw@mail.gmail.com>
References: <CAHbwRz6xbrkErFK+X7KM0E+YwDA0FNWM+fq8jyk3PVqyPA6Pxw@mail.gmail.com>
Message-ID: <CAF6FJiuYLvcOhDMnfHzhdgEq3fpVWnQER1aEj4Q-8S46NTCUyA@mail.gmail.com>

On Sun, Aug 25, 2013 at 9:00 AM, Saullo Castro <saullogiovani at gmail.com>
wrote:
>
> Well, we've been discussion the license combatility for the cubature
module.
>
> From the links @Warren gave me:
> http://wiki.scipy.org/License_Compatibility
> http://matplotlib.org/devel/license.html#license-discussion
>
> it states that the MIT license is compatible with SciPy, and in the MIT
description in Wikipedia (http://en.wikipedia.org/wiki/MIT_License) it
states that this license is compatible with the GPL. So... is there a crack
here where we could place a GPL software in SciPy?

No. License compatibility is not commutative. A license is GPL-compatible
if it adds no restrictions above those in the GPL. A license is
BSD-compatible (and thus scipy-compatible) if it adds no restrictions above
those in the BSD license. The GPL adds restrictions above those in the BSD
license.

We have decided as a matter of policy for the scipy project to only include
code that does not add more restrictions than roughly that of the BSD
license. This isn't really an issue of license compatibility. You can
combine BSD scipy code and GPL code just fine, but we have a policy against
including GPL code into scipy because we want to keep the licensing
situation simple and understandable and not copylefted. If some scipy
packages were BSD-licensed and some were GPL-licensed, everyone will have
to pay close attention to which ones they were using to be sure that they
are obeying the terms of the GPL license. That's really annoying. It is
much easier for everyone involved to keep the GPL code in an entirely
separate package.

I appreciate your effort in learning about these issues, but please
consider it an exercise in personal education rather than trying to find a
workaround to include GPL code in scipy. There isn't one.

--
Robert Kern
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130825/8f6481f0/attachment.html>

From saullogiovani at gmail.com  Sun Aug 25 04:04:28 2013
From: saullogiovani at gmail.com (Saullo Castro)
Date: Sun, 25 Aug 2013 10:04:28 +0200
Subject: [SciPy-Dev] License compatibility SciPy -> MIT -> GPL
Message-ID: <CAHbwRz6jt3Bry2-fXYnK1FoZpN7=dADLD=Lwo8dVvfxs4H531A@mail.gmail.com>

@Robert Kern

maybe you misunderstood me, I am not trying to find a workaround to include
GPL code in scipy, actually I just found it interesting that SciPy is
compatible to MIT and MIT to GPL, but not Scipy to GPL. Your answer has
clarified it so far...
I will keep in touch with the cubature author (Steven Johnson) to see if
relicensing is an alternative, and moving on with the wrapper (testing and
documentation now).

Thank you!
Saullo


2013/8/25 <scipy-dev-request at scipy.org>

> Send SciPy-Dev mailing list submissions to
>         scipy-dev at scipy.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://mail.scipy.org/mailman/listinfo/scipy-dev
> or, via email, send a message with subject or body 'help' to
>         scipy-dev-request at scipy.org
>
> You can reach the person managing the list at
>         scipy-dev-owner at scipy.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of SciPy-Dev digest..."
>
>
> Today's Topics:
>
>    1. Re: cubature license (Saullo Castro)
>    2. License compatibility SciPy -> MIT -> GPL (Saullo Castro)
>    3. Re: License compatibility SciPy -> MIT -> GPL (Matthieu Brucher)
>    4. Re: License compatibility SciPy -> MIT -> GPL (Robert Kern)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 25 Aug 2013 08:40:09 +0200
> From: Saullo Castro <saullogiovani at gmail.com>
> Subject: Re: [SciPy-Dev] cubature license
> To: Scipy-Dev <scipy-dev at scipy.org>
> Message-ID:
>         <CAHbwRz7Uy_=5o3Dvk=_
> M-3oKCAFuckZBHwBd+D6sKx4bTBP5OA at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> @Warren
>
> from the good disccusion here (
> http://matplotlib.org/devel/license.html#license-discussion)
> it seems that the biggest difference between the GPL and the BSD is that
> the former requires you to distribute your source code, and the BSD allows
> you to do whatever you want...
>
> I don't see the problem to include it in SciPy, since the source code is
> always distributed. Even if third part companies like Enthought are using
> it, it is more like a module, isn't it? and the core code behind it can
> still be BSD  based.
>
> Anyway, the software has a `clencurt_gen.c` stand-alone program which does
> not have to be used unless the user whant a `p-adaptive` cubature with more
> than 8193 points per dimension, this type of cubature applies
> "p-refinement" (increase of interpolation function order) instead of
> "h-refinement" (splitting the interval). I don't see a need to include this
> program in the SciPy cubature. We can implement this restriction in the
> wrapper.
>
> I will ask Steven Johnson about this, if removing this part could make
> cubature re-licensable to BSD.
>
> Greetings!
> Saullo
>
>
> 2013/8/24 <scipy-dev-request at scipy.org>
>
> > Send SciPy-Dev mailing list submissions to
> >         scipy-dev at scipy.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >         http://mail.scipy.org/mailman/listinfo/scipy-dev
> > or, via email, send a message with subject or body 'help' to
> >         scipy-dev-request at scipy.org
> >
> > You can reach the person managing the list at
> >         scipy-dev-owner at scipy.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of SciPy-Dev digest..."
> >
> >
> > Today's Topics:
> >
> >    1. Re: cubature license (Robert Kern)
> >    2. Re: cubature license (Warren Weckesser)
> >    3. Re: cubature license (Warren Weckesser)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Sat, 24 Aug 2013 16:53:10 +0200
> > From: Robert Kern <robert.kern at gmail.com>
> > Subject: Re: [SciPy-Dev] cubature license
> > To: SciPy Developers List <scipy-dev at scipy.org>
> > Message-ID:
> >         <
> > CAF6FJivScnjqnAZO8OJ0XZpJ48+KsC5rdOmE+5z-EWWJn7iH_g at mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > On Sat, Aug 24, 2013 at 4:47 PM, Warren Weckesser <
> > warren.weckesser at gmail.com> wrote:
> > >
> > > On 8/24/13, Saullo Castro <saullogiovani at gmail.com> wrote:
> > > > @Alex,
> > > >
> > > > you are right, "it uses some GPL code from other projects (Hintlib
> and
> > > > GSL).
> > > > "
> > > >
> > > > But is it really impossible to include it in SciPy because of that?
> > >
> > > Yes.  We do not include GPL-licensed code in SciPy.  I haven't looked
> > > at the Cubature code, so I don't know the extent to which it uses
> > > HIntLib and GSL, but based on the comment on the web page, it is
> > > unlikely that Steven Johnson can re-license his code with a license
> > > that is compatible with SciPy.  The GPL is viral that way (insert the
> > > usual "I am not a lawyer" disclaimer here).
> >
> > It's not quite as viral as that. He can license the code that he himself
> > wrote under whatever license he likes as long as it is compatible with
> the
> > GPL license of the other libraries that he is combining his code with. If
> > the code that he wrote is separable from HIntLib and GSL by rewriting
> that
> > functionality, he can distribute his code under the BSD license for
> > inclusion in SciPy.
> >
> > --
> > Robert Kern
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL:
> >
> http://mail.scipy.org/pipermail/scipy-dev/attachments/20130824/e75eadc8/attachment-0001.html
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Sat, 24 Aug 2013 11:04:51 -0400
> > From: Warren Weckesser <warren.weckesser at gmail.com>
> > Subject: Re: [SciPy-Dev] cubature license
> > To: SciPy Developers List <scipy-dev at scipy.org>
> > Message-ID:
> >         <
> > CAGzF1ufwXi4UoGeCwvBN1HCJbigGKtpYisM8KFEc9n5NAhyNtA at mail.gmail.com>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > On 8/24/13, Robert Kern <robert.kern at gmail.com> wrote:
> > > On Sat, Aug 24, 2013 at 4:47 PM, Warren Weckesser <
> > > warren.weckesser at gmail.com> wrote:
> > >>
> > >> On 8/24/13, Saullo Castro <saullogiovani at gmail.com> wrote:
> > >> > @Alex,
> > >> >
> > >> > you are right, "it uses some GPL code from other projects (Hintlib
> and
> > >> > GSL).
> > >> > "
> > >> >
> > >> > But is it really impossible to include it in SciPy because of that?
> > >>
> > >> Yes.  We do not include GPL-licensed code in SciPy.  I haven't looked
> > >> at the Cubature code, so I don't know the extent to which it uses
> > >> HIntLib and GSL, but based on the comment on the web page, it is
> > >> unlikely that Steven Johnson can re-license his code with a license
> > >> that is compatible with SciPy.  The GPL is viral that way (insert the
> > >> usual "I am not a lawyer" disclaimer here).
> > >
> > > It's not quite as viral as that. He can license the code that he
> himself
> > > wrote under whatever license he likes as long as it is compatible with
> > the
> > > GPL license of the other libraries that he is combining his code with.
> If
> > > the code that he wrote is separable from HIntLib and GSL by rewriting
> > that
> > > functionality, he can distribute his code under the BSD license for
> > > inclusion in SciPy.
> >
> >
> > Yes--thanks for the clarification.
> >
> > Warren
> >
> >
> > >
> > > --
> > > Robert Kern
> > >
> >
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Sat, 24 Aug 2013 11:16:16 -0400
> > From: Warren Weckesser <warren.weckesser at gmail.com>
> > Subject: Re: [SciPy-Dev] cubature license
> > To: SciPy Developers List <scipy-dev at scipy.org>
> > Message-ID:
> >         <
> > CAGzF1uezSbAmsWNwSyfRug5tz08UA1pe7pUeeBYVE1tmykSWrw at mail.gmail.com>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > On 8/24/13, Warren Weckesser <warren.weckesser at gmail.com> wrote:
> > > On 8/24/13, Robert Kern <robert.kern at gmail.com> wrote:
> > >> On Sat, Aug 24, 2013 at 4:47 PM, Warren Weckesser <
> > >> warren.weckesser at gmail.com> wrote:
> > >>>
> > >>> On 8/24/13, Saullo Castro <saullogiovani at gmail.com> wrote:
> > >>> > @Alex,
> > >>> >
> > >>> > you are right, "it uses some GPL code from other projects (Hintlib
> > and
> > >>> > GSL).
> > >>> > "
> > >>> >
> > >>> > But is it really impossible to include it in SciPy because of that?
> > >>>
> > >>> Yes.  We do not include GPL-licensed code in SciPy.  I haven't looked
> > >>> at the Cubature code, so I don't know the extent to which it uses
> > >>> HIntLib and GSL, but based on the comment on the web page, it is
> > >>> unlikely that Steven Johnson can re-license his code with a license
> > >>> that is compatible with SciPy.  The GPL is viral that way (insert the
> > >>> usual "I am not a lawyer" disclaimer here).
> > >>
> > >> It's not quite as viral as that. He can license the code that he
> himself
> > >> wrote under whatever license he likes as long as it is compatible with
> > >> the
> > >> GPL license of the other libraries that he is combining his code with.
> > If
> > >> the code that he wrote is separable from HIntLib and GSL by rewriting
> > >> that
> > >> functionality, he can distribute his code under the BSD license for
> > >> inclusion in SciPy.
> > >
> > >
> > > Yes--thanks for the clarification.
> > >
> > > Warren
> > >
> >
> >
> > P.S.:  Saullo, here are a couple links to more information about
> > compatible licenses:
> > http://wiki.scipy.org/License_Compatibility
> > http://matplotlib.org/devel/license.html#license-discussion (the
> > discussion of the matplotlib license is applicable to scipy)
> >
> > Warren
> >
> > >
> > >>
> > >> --
> > >> Robert Kern
> > >>
> > >
> >
> >
> > ------------------------------
> >
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> >
> > End of SciPy-Dev Digest, Vol 118, Issue 36
> > ******************************************
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mail.scipy.org/pipermail/scipy-dev/attachments/20130825/ad359215/attachment-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Sun, 25 Aug 2013 09:00:43 +0200
> From: Saullo Castro <saullogiovani at gmail.com>
> Subject: [SciPy-Dev] License compatibility SciPy -> MIT -> GPL
> To: Scipy-Dev <scipy-dev at scipy.org>
> Message-ID:
>         <
> CAHbwRz6xbrkErFK+X7KM0E+YwDA0FNWM+fq8jyk3PVqyPA6Pxw at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Well, we've been discussion the license combatility for the cubature
> module.
>
> >From the links @Warren gave me:
> http://wiki.scipy.org/License_Compatibility
> http://matplotlib.org/devel/license.html#license-discussion
>
> it states that the MIT license is compatible with SciPy, and in the MIT
> description in Wikipedia (http://en.wikipedia.org/wiki/MIT_License) it
> states that this license is compatible with the GPL. So... is there a crack
> here where we could place a GPL software in SciPy?
>
> Thank you,
> Saullo
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mail.scipy.org/pipermail/scipy-dev/attachments/20130825/120d6050/attachment-0001.html
>
> ------------------------------
>
> Message: 3
> Date: Sun, 25 Aug 2013 08:11:40 +0100
> From: Matthieu Brucher <matthieu.brucher at gmail.com>
> Subject: Re: [SciPy-Dev] License compatibility SciPy -> MIT -> GPL
> To: SciPy Developers List <scipy-dev at scipy.org>
> Message-ID:
>         <
> CAHCaCkKLLZSNYq+XHXt6xmAThWvA2wYeSBycp1LVvRNHxPGe2A at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi
> Unfortunately, it is the other way around: you can put bsd code in gpl
> code, but if you put gpl code into bsd code, the latter has to be
> relicensed. Btw, if you put gpl code indide mit code, the same has to be
> done.
>
> Cheers
> Le 25 ao?t 2013 08:00, "Saullo Castro" <saullogiovani at gmail.com> a ?crit :
>
> > Well, we've been discussion the license combatility for the cubature
> > module.
> >
> > From the links @Warren gave me:
> > http://wiki.scipy.org/License_Compatibility
> > http://matplotlib.org/devel/license.html#license-discussion
> >
> > it states that the MIT license is compatible with SciPy, and in the MIT
> > description in Wikipedia (http://en.wikipedia.org/wiki/MIT_License) it
> > states that this license is compatible with the GPL. So... is there a
> crack
> > here where we could place a GPL software in SciPy?
> >
> > Thank you,
> > Saullo
> >
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mail.scipy.org/pipermail/scipy-dev/attachments/20130825/a503d34c/attachment-0001.html
>
> ------------------------------
>
> Message: 4
> Date: Sun, 25 Aug 2013 09:46:00 +0200
> From: Robert Kern <robert.kern at gmail.com>
> Subject: Re: [SciPy-Dev] License compatibility SciPy -> MIT -> GPL
> To: SciPy Developers List <scipy-dev at scipy.org>
> Message-ID:
>         <
> CAF6FJiuYLvcOhDMnfHzhdgEq3fpVWnQER1aEj4Q-8S46NTCUyA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Sun, Aug 25, 2013 at 9:00 AM, Saullo Castro <saullogiovani at gmail.com>
> wrote:
> >
> > Well, we've been discussion the license combatility for the cubature
> module.
> >
> > From the links @Warren gave me:
> > http://wiki.scipy.org/License_Compatibility
> > http://matplotlib.org/devel/license.html#license-discussion
> >
> > it states that the MIT license is compatible with SciPy, and in the MIT
> description in Wikipedia (http://en.wikipedia.org/wiki/MIT_License) it
> states that this license is compatible with the GPL. So... is there a crack
> here where we could place a GPL software in SciPy?
>
> No. License compatibility is not commutative. A license is GPL-compatible
> if it adds no restrictions above those in the GPL. A license is
> BSD-compatible (and thus scipy-compatible) if it adds no restrictions above
> those in the BSD license. The GPL adds restrictions above those in the BSD
> license.
>
> We have decided as a matter of policy for the scipy project to only include
> code that does not add more restrictions than roughly that of the BSD
> license. This isn't really an issue of license compatibility. You can
> combine BSD scipy code and GPL code just fine, but we have a policy against
> including GPL code into scipy because we want to keep the licensing
> situation simple and understandable and not copylefted. If some scipy
> packages were BSD-licensed and some were GPL-licensed, everyone will have
> to pay close attention to which ones they were using to be sure that they
> are obeying the terms of the GPL license. That's really annoying. It is
> much easier for everyone involved to keep the GPL code in an entirely
> separate package.
>
> I appreciate your effort in learning about these issues, but please
> consider it an exercise in personal education rather than trying to find a
> workaround to include GPL code in scipy. There isn't one.
>
> --
> Robert Kern
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mail.scipy.org/pipermail/scipy-dev/attachments/20130825/8f6481f0/attachment.html
>
> ------------------------------
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
> End of SciPy-Dev Digest, Vol 118, Issue 37
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130825/7fc9ec4c/attachment.html>

From warren.weckesser at gmail.com  Sun Aug 25 08:01:32 2013
From: warren.weckesser at gmail.com (Warren Weckesser)
Date: Sun, 25 Aug 2013 08:01:32 -0400
Subject: [SciPy-Dev] cubature license
In-Reply-To: <CAHbwRz7Uy_=5o3Dvk=_M-3oKCAFuckZBHwBd+D6sKx4bTBP5OA@mail.gmail.com>
References: <CAHbwRz7Uy_=5o3Dvk=_M-3oKCAFuckZBHwBd+D6sKx4bTBP5OA@mail.gmail.com>
Message-ID: <CAGzF1udYnngzyzjS2ezp2h3joYkzLib9jXiZSKpjSZSPz3RHhw@mail.gmail.com>

On 8/25/13, Saullo Castro <saullogiovani at gmail.com> wrote:
> @Warren
>
> from the good disccusion here (
> http://matplotlib.org/devel/license.html#license-discussion)
> it seems that the biggest difference between the GPL and the BSD is that
> the former requires you to distribute your source code, and the BSD allows
> you to do whatever you want...
>
> I don't see the problem to include it in SciPy, since the source code is
> always distributed.


The issue is the restriction placed on anyone who wants to
*redistribute* software that uses scipy.  For example, currently a
third party could build and sell a commercial application that uses
scipy without having to distribute the source code for the application
or their modified version of scipy.   That would not be possible with
a GPL license.

More reading: http://www.freebsd.org/doc/en/articles/bsdl-gpl/article.html

Warren


> Even if third part companies like Enthought are using
> it, it is more like a module, isn't it? and the core code behind it can
> still be BSD  based.
>
> Anyway, the software has a `clencurt_gen.c` stand-alone program which does
> not have to be used unless the user whant a `p-adaptive` cubature with more
> than 8193 points per dimension, this type of cubature applies
> "p-refinement" (increase of interpolation function order) instead of
> "h-refinement" (splitting the interval). I don't see a need to include this
> program in the SciPy cubature. We can implement this restriction in the
> wrapper.
>
> I will ask Steven Johnson about this, if removing this part could make
> cubature re-licensable to BSD.
>
> Greetings!
> Saullo
>
>
> 2013/8/24 <scipy-dev-request at scipy.org>
>
>> Send SciPy-Dev mailing list submissions to
>>         scipy-dev at scipy.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         http://mail.scipy.org/mailman/listinfo/scipy-dev
>> or, via email, send a message with subject or body 'help' to
>>         scipy-dev-request at scipy.org
>>
>> You can reach the person managing the list at
>>         scipy-dev-owner at scipy.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of SciPy-Dev digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Re: cubature license (Robert Kern)
>>    2. Re: cubature license (Warren Weckesser)
>>    3. Re: cubature license (Warren Weckesser)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Sat, 24 Aug 2013 16:53:10 +0200
>> From: Robert Kern <robert.kern at gmail.com>
>> Subject: Re: [SciPy-Dev] cubature license
>> To: SciPy Developers List <scipy-dev at scipy.org>
>> Message-ID:
>>         <
>> CAF6FJivScnjqnAZO8OJ0XZpJ48+KsC5rdOmE+5z-EWWJn7iH_g at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> On Sat, Aug 24, 2013 at 4:47 PM, Warren Weckesser <
>> warren.weckesser at gmail.com> wrote:
>> >
>> > On 8/24/13, Saullo Castro <saullogiovani at gmail.com> wrote:
>> > > @Alex,
>> > >
>> > > you are right, "it uses some GPL code from other projects (Hintlib
>> > > and
>> > > GSL).
>> > > "
>> > >
>> > > But is it really impossible to include it in SciPy because of that?
>> >
>> > Yes.  We do not include GPL-licensed code in SciPy.  I haven't looked
>> > at the Cubature code, so I don't know the extent to which it uses
>> > HIntLib and GSL, but based on the comment on the web page, it is
>> > unlikely that Steven Johnson can re-license his code with a license
>> > that is compatible with SciPy.  The GPL is viral that way (insert the
>> > usual "I am not a lawyer" disclaimer here).
>>
>> It's not quite as viral as that. He can license the code that he himself
>> wrote under whatever license he likes as long as it is compatible with
>> the
>> GPL license of the other libraries that he is combining his code with. If
>> the code that he wrote is separable from HIntLib and GSL by rewriting
>> that
>> functionality, he can distribute his code under the BSD license for
>> inclusion in SciPy.
>>
>> --
>> Robert Kern
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> http://mail.scipy.org/pipermail/scipy-dev/attachments/20130824/e75eadc8/attachment-0001.html
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Sat, 24 Aug 2013 11:04:51 -0400
>> From: Warren Weckesser <warren.weckesser at gmail.com>
>> Subject: Re: [SciPy-Dev] cubature license
>> To: SciPy Developers List <scipy-dev at scipy.org>
>> Message-ID:
>>         <
>> CAGzF1ufwXi4UoGeCwvBN1HCJbigGKtpYisM8KFEc9n5NAhyNtA at mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> On 8/24/13, Robert Kern <robert.kern at gmail.com> wrote:
>> > On Sat, Aug 24, 2013 at 4:47 PM, Warren Weckesser <
>> > warren.weckesser at gmail.com> wrote:
>> >>
>> >> On 8/24/13, Saullo Castro <saullogiovani at gmail.com> wrote:
>> >> > @Alex,
>> >> >
>> >> > you are right, "it uses some GPL code from other projects (Hintlib
>> >> > and
>> >> > GSL).
>> >> > "
>> >> >
>> >> > But is it really impossible to include it in SciPy because of that?
>> >>
>> >> Yes.  We do not include GPL-licensed code in SciPy.  I haven't looked
>> >> at the Cubature code, so I don't know the extent to which it uses
>> >> HIntLib and GSL, but based on the comment on the web page, it is
>> >> unlikely that Steven Johnson can re-license his code with a license
>> >> that is compatible with SciPy.  The GPL is viral that way (insert the
>> >> usual "I am not a lawyer" disclaimer here).
>> >
>> > It's not quite as viral as that. He can license the code that he
>> > himself
>> > wrote under whatever license he likes as long as it is compatible with
>> the
>> > GPL license of the other libraries that he is combining his code with.
>> > If
>> > the code that he wrote is separable from HIntLib and GSL by rewriting
>> that
>> > functionality, he can distribute his code under the BSD license for
>> > inclusion in SciPy.
>>
>>
>> Yes--thanks for the clarification.
>>
>> Warren
>>
>>
>> >
>> > --
>> > Robert Kern
>> >
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Sat, 24 Aug 2013 11:16:16 -0400
>> From: Warren Weckesser <warren.weckesser at gmail.com>
>> Subject: Re: [SciPy-Dev] cubature license
>> To: SciPy Developers List <scipy-dev at scipy.org>
>> Message-ID:
>>         <
>> CAGzF1uezSbAmsWNwSyfRug5tz08UA1pe7pUeeBYVE1tmykSWrw at mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> On 8/24/13, Warren Weckesser <warren.weckesser at gmail.com> wrote:
>> > On 8/24/13, Robert Kern <robert.kern at gmail.com> wrote:
>> >> On Sat, Aug 24, 2013 at 4:47 PM, Warren Weckesser <
>> >> warren.weckesser at gmail.com> wrote:
>> >>>
>> >>> On 8/24/13, Saullo Castro <saullogiovani at gmail.com> wrote:
>> >>> > @Alex,
>> >>> >
>> >>> > you are right, "it uses some GPL code from other projects (Hintlib
>> and
>> >>> > GSL).
>> >>> > "
>> >>> >
>> >>> > But is it really impossible to include it in SciPy because of that?
>> >>>
>> >>> Yes.  We do not include GPL-licensed code in SciPy.  I haven't looked
>> >>> at the Cubature code, so I don't know the extent to which it uses
>> >>> HIntLib and GSL, but based on the comment on the web page, it is
>> >>> unlikely that Steven Johnson can re-license his code with a license
>> >>> that is compatible with SciPy.  The GPL is viral that way (insert the
>> >>> usual "I am not a lawyer" disclaimer here).
>> >>
>> >> It's not quite as viral as that. He can license the code that he
>> >> himself
>> >> wrote under whatever license he likes as long as it is compatible with
>> >> the
>> >> GPL license of the other libraries that he is combining his code with.
>> If
>> >> the code that he wrote is separable from HIntLib and GSL by rewriting
>> >> that
>> >> functionality, he can distribute his code under the BSD license for
>> >> inclusion in SciPy.
>> >
>> >
>> > Yes--thanks for the clarification.
>> >
>> > Warren
>> >
>>
>>
>> P.S.:  Saullo, here are a couple links to more information about
>> compatible licenses:
>> http://wiki.scipy.org/License_Compatibility
>> http://matplotlib.org/devel/license.html#license-discussion (the
>> discussion of the matplotlib license is applicable to scipy)
>>
>> Warren
>>
>> >
>> >>
>> >> --
>> >> Robert Kern
>> >>
>> >
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
>> End of SciPy-Dev Digest, Vol 118, Issue 36
>> ******************************************
>>
>


From ralf.gommers at gmail.com  Sun Aug 25 16:11:29 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sun, 25 Aug 2013 22:11:29 +0200
Subject: [SciPy-Dev] sprint mini-report
Message-ID: <CABL7CQgPvOhFK9_SAH0py+=EczLRE_W3G1=GmzPe=bLa2oartw@mail.gmail.com>

Hi all,

Today we had 18 people in the room at the EuroScipy sprint - many of which
made their first contribution to scipy today - plus Josef joining remotely
and David C hiding out in the scikit-learn room. Some statistics on what we
managed to do:
- 21 scipy PRs
- 9 scipy PRs merged
- 5 scipy issues closed, and many more discussed
- 2 numpy commits
- 2 scipy.org PRs

Thanks everyone for joining (keep those PRs coming...:) ), and Pierre for
the coffee runs and pizza!

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130825/daa45f1c/attachment.html>

From clemens at familie-novak.net  Mon Aug 26 07:07:40 2013
From: clemens at familie-novak.net (Clemens Novak)
Date: Mon, 26 Aug 2013 13:07:40 +0200
Subject: [SciPy-Dev] fftpack.convolve.convolve
In-Reply-To: <5214E1CA.3050200@redtetrahedron.org>
References: <68515d0d5b89edc18360cc0df135885c@scorpius.uberspace.de>
	<5214E1CA.3050200@redtetrahedron.org>
Message-ID: <537102c9838a53dc1e1cb99c536a77ec@scorpius.uberspace.de>

On 2013-08-21 17:50, Eric Moore wrote:
> Clemens Novak wrote:
>> Hi,
>> 
>> I've been working on extending the fftpack tutorial page (you can see
>> the current status here:
>> https://github.com/ClemensFMN/scipy/blob/tut_fft/doc/source/tutorial/fftpack.rst
>> ) and I stumbled across the function fftpack.convolve.convolve .
>> 
>> Sorry the blunt question, but what does this function do? From the 
>> name
>> I'd assume that it calculates the convolution of two sequences (as
>> convolve in scipy.signal does) using the fft (since it is part of
>> fftpack), but appearently it doesn't:
>> 
>> import numpy as np
>> import scipy.fftpack.convolve as conv
>> import scipy as sp
>> import scipy.signal as sig
>> 
>> 
>> x = np.array([1.0, 0.0, 0.0])
>> h = np.array([1.0, 2.0, 3.0])
>> 
>> y1 = conv.convolve(x, h)
>> [ 5. -1. -1.]
>> 
>> y2 = sig.convolve(x, h)
>> [ 1.  2.  3.  0.  0.]
>> 
>> y3 = sp.ifft(sp.fft(x) * sp.fft(h))
>> [ 1.+0.j  2.+0.j  3.+0.j]
>> 
>> Does the function extend its first and/or second argument to a 
>> periodic
>> sequence and perform then the convolution (I tried some ideas but 
>> that
>> didn'twork either)? It would be great if someone could please provide
>> some insight...
>> 
>> Regards - Clemens
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
> 
> AFAICT, fftpack.convolve exists in support of pseudo_diffs.py.  Look
> there to see some examples.
> 
> -Eric
> 
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev

Thanks for the input; I will have a look at the file.

Clemens


From lists at hilboll.de  Mon Aug 26 16:46:15 2013
From: lists at hilboll.de (Andreas Hilboll)
Date: Mon, 26 Aug 2013 22:46:15 +0200
Subject: [SciPy-Dev] Triangulation on sphere surface with qhull(-wrapper)
Message-ID: <521BBE97.2070506@hilboll.de>

Hi,

I was wondering if qhull supports Delaunay triangulation of data on the
unit sphere? If so, I'd like to implement an appropriate wrapper to have
an alternative to the FITPACK-based interpolation on spheres. Otherwise,
there's STRIPACK as an alternative, and it would probably be easy to
wrap it (if license is compatible; so far I couldn't find any license
info on STRIPACK). But I have a feeling qhull should be able to do this
as well; I just couldn't figure out how ...

-- Andreas.


From saullogiovani at gmail.com  Tue Aug 27 05:18:11 2013
From: saullogiovani at gmail.com (Saullo Castro)
Date: Tue, 27 Aug 2013 11:18:11 +0200
Subject: [SciPy-Dev] cubature license (Warren Weckesser)
Message-ID: <CAHbwRz7Qbr1cH2hiaQu6naanKEV5H3A=_5+nmxQvDMKtu1QTqg@mail.gmail.com>

Dear all,

due to the BSD and GPL licenses incompatibilities the cubature package
 will not be included in SciPy.

Steven Johnson replied explaining that the code is directly derived from
Hintlib, and GNU GSL libraries, both of which are GPL.

The wrapper is already available in GitHub and soon I will include one link
in PyPI.

https://github.com/saullocastro/cubature

if anyone is interested.

Greetings,
Saullo



2013/8/25 <scipy-dev-request at scipy.org>

> Send SciPy-Dev mailing list submissions to
>         scipy-dev at scipy.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://mail.scipy.org/mailman/listinfo/scipy-dev
> or, via email, send a message with subject or body 'help' to
>         scipy-dev-request at scipy.org
>
> You can reach the person managing the list at
>         scipy-dev-owner at scipy.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of SciPy-Dev digest..."
>
>
> Today's Topics:
>
>    1. Re: cubature license (Warren Weckesser)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 25 Aug 2013 08:01:32 -0400
> From: Warren Weckesser <warren.weckesser at gmail.com>
> Subject: Re: [SciPy-Dev] cubature license
> To: SciPy Developers List <scipy-dev at scipy.org>
> Message-ID:
>         <
> CAGzF1udYnngzyzjS2ezp2h3joYkzLib9jXiZSKpjSZSPz3RHhw at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 8/25/13, Saullo Castro <saullogiovani at gmail.com> wrote:
> > @Warren
> >
> > from the good disccusion here (
> > http://matplotlib.org/devel/license.html#license-discussion)
> > it seems that the biggest difference between the GPL and the BSD is that
> > the former requires you to distribute your source code, and the BSD
> allows
> > you to do whatever you want...
> >
> > I don't see the problem to include it in SciPy, since the source code is
> > always distributed.
>
>
> The issue is the restriction placed on anyone who wants to
> *redistribute* software that uses scipy.  For example, currently a
> third party could build and sell a commercial application that uses
> scipy without having to distribute the source code for the application
> or their modified version of scipy.   That would not be possible with
> a GPL license.
>
> More reading: http://www.freebsd.org/doc/en/articles/bsdl-gpl/article.html
>
> Warren
>
>
> > Even if third part companies like Enthought are using
> > it, it is more like a module, isn't it? and the core code behind it can
> > still be BSD  based.
> >
> > Anyway, the software has a `clencurt_gen.c` stand-alone program which
> does
> > not have to be used unless the user whant a `p-adaptive` cubature with
> more
> > than 8193 points per dimension, this type of cubature applies
> > "p-refinement" (increase of interpolation function order) instead of
> > "h-refinement" (splitting the interval). I don't see a need to include
> this
> > program in the SciPy cubature. We can implement this restriction in the
> > wrapper.
> >
> > I will ask Steven Johnson about this, if removing this part could make
> > cubature re-licensable to BSD.
> >
> > Greetings!
> > Saullo
> >
> >
> > 2013/8/24 <scipy-dev-request at scipy.org>
> >
> >> Send SciPy-Dev mailing list submissions to
> >>         scipy-dev at scipy.org
> >>
> >> To subscribe or unsubscribe via the World Wide Web, visit
> >>         http://mail.scipy.org/mailman/listinfo/scipy-dev
> >> or, via email, send a message with subject or body 'help' to
> >>         scipy-dev-request at scipy.org
> >>
> >> You can reach the person managing the list at
> >>         scipy-dev-owner at scipy.org
> >>
> >> When replying, please edit your Subject line so it is more specific
> >> than "Re: Contents of SciPy-Dev digest..."
> >>
> >>
> >> Today's Topics:
> >>
> >>    1. Re: cubature license (Robert Kern)
> >>    2. Re: cubature license (Warren Weckesser)
> >>    3. Re: cubature license (Warren Weckesser)
> >>
> >>
> >> ----------------------------------------------------------------------
> >>
> >> Message: 1
> >> Date: Sat, 24 Aug 2013 16:53:10 +0200
> >> From: Robert Kern <robert.kern at gmail.com>
> >> Subject: Re: [SciPy-Dev] cubature license
> >> To: SciPy Developers List <scipy-dev at scipy.org>
> >> Message-ID:
> >>         <
> >> CAF6FJivScnjqnAZO8OJ0XZpJ48+KsC5rdOmE+5z-EWWJn7iH_g at mail.gmail.com>
> >> Content-Type: text/plain; charset="utf-8"
> >>
> >> On Sat, Aug 24, 2013 at 4:47 PM, Warren Weckesser <
> >> warren.weckesser at gmail.com> wrote:
> >> >
> >> > On 8/24/13, Saullo Castro <saullogiovani at gmail.com> wrote:
> >> > > @Alex,
> >> > >
> >> > > you are right, "it uses some GPL code from other projects (Hintlib
> >> > > and
> >> > > GSL).
> >> > > "
> >> > >
> >> > > But is it really impossible to include it in SciPy because of that?
> >> >
> >> > Yes.  We do not include GPL-licensed code in SciPy.  I haven't looked
> >> > at the Cubature code, so I don't know the extent to which it uses
> >> > HIntLib and GSL, but based on the comment on the web page, it is
> >> > unlikely that Steven Johnson can re-license his code with a license
> >> > that is compatible with SciPy.  The GPL is viral that way (insert the
> >> > usual "I am not a lawyer" disclaimer here).
> >>
> >> It's not quite as viral as that. He can license the code that he himself
> >> wrote under whatever license he likes as long as it is compatible with
> >> the
> >> GPL license of the other libraries that he is combining his code with.
> If
> >> the code that he wrote is separable from HIntLib and GSL by rewriting
> >> that
> >> functionality, he can distribute his code under the BSD license for
> >> inclusion in SciPy.
> >>
> >> --
> >> Robert Kern
> >> -------------- next part --------------
> >> An HTML attachment was scrubbed...
> >> URL:
> >>
> http://mail.scipy.org/pipermail/scipy-dev/attachments/20130824/e75eadc8/attachment-0001.html
> >>
> >> ------------------------------
> >>
> >> Message: 2
> >> Date: Sat, 24 Aug 2013 11:04:51 -0400
> >> From: Warren Weckesser <warren.weckesser at gmail.com>
> >> Subject: Re: [SciPy-Dev] cubature license
> >> To: SciPy Developers List <scipy-dev at scipy.org>
> >> Message-ID:
> >>         <
> >> CAGzF1ufwXi4UoGeCwvBN1HCJbigGKtpYisM8KFEc9n5NAhyNtA at mail.gmail.com>
> >> Content-Type: text/plain; charset=ISO-8859-1
> >>
> >> On 8/24/13, Robert Kern <robert.kern at gmail.com> wrote:
> >> > On Sat, Aug 24, 2013 at 4:47 PM, Warren Weckesser <
> >> > warren.weckesser at gmail.com> wrote:
> >> >>
> >> >> On 8/24/13, Saullo Castro <saullogiovani at gmail.com> wrote:
> >> >> > @Alex,
> >> >> >
> >> >> > you are right, "it uses some GPL code from other projects (Hintlib
> >> >> > and
> >> >> > GSL).
> >> >> > "
> >> >> >
> >> >> > But is it really impossible to include it in SciPy because of that?
> >> >>
> >> >> Yes.  We do not include GPL-licensed code in SciPy.  I haven't looked
> >> >> at the Cubature code, so I don't know the extent to which it uses
> >> >> HIntLib and GSL, but based on the comment on the web page, it is
> >> >> unlikely that Steven Johnson can re-license his code with a license
> >> >> that is compatible with SciPy.  The GPL is viral that way (insert the
> >> >> usual "I am not a lawyer" disclaimer here).
> >> >
> >> > It's not quite as viral as that. He can license the code that he
> >> > himself
> >> > wrote under whatever license he likes as long as it is compatible with
> >> the
> >> > GPL license of the other libraries that he is combining his code with.
> >> > If
> >> > the code that he wrote is separable from HIntLib and GSL by rewriting
> >> that
> >> > functionality, he can distribute his code under the BSD license for
> >> > inclusion in SciPy.
> >>
> >>
> >> Yes--thanks for the clarification.
> >>
> >> Warren
> >>
> >>
> >> >
> >> > --
> >> > Robert Kern
> >> >
> >>
> >>
> >> ------------------------------
> >>
> >> Message: 3
> >> Date: Sat, 24 Aug 2013 11:16:16 -0400
> >> From: Warren Weckesser <warren.weckesser at gmail.com>
> >> Subject: Re: [SciPy-Dev] cubature license
> >> To: SciPy Developers List <scipy-dev at scipy.org>
> >> Message-ID:
> >>         <
> >> CAGzF1uezSbAmsWNwSyfRug5tz08UA1pe7pUeeBYVE1tmykSWrw at mail.gmail.com>
> >> Content-Type: text/plain; charset=ISO-8859-1
> >>
> >> On 8/24/13, Warren Weckesser <warren.weckesser at gmail.com> wrote:
> >> > On 8/24/13, Robert Kern <robert.kern at gmail.com> wrote:
> >> >> On Sat, Aug 24, 2013 at 4:47 PM, Warren Weckesser <
> >> >> warren.weckesser at gmail.com> wrote:
> >> >>>
> >> >>> On 8/24/13, Saullo Castro <saullogiovani at gmail.com> wrote:
> >> >>> > @Alex,
> >> >>> >
> >> >>> > you are right, "it uses some GPL code from other projects (Hintlib
> >> and
> >> >>> > GSL).
> >> >>> > "
> >> >>> >
> >> >>> > But is it really impossible to include it in SciPy because of
> that?
> >> >>>
> >> >>> Yes.  We do not include GPL-licensed code in SciPy.  I haven't
> looked
> >> >>> at the Cubature code, so I don't know the extent to which it uses
> >> >>> HIntLib and GSL, but based on the comment on the web page, it is
> >> >>> unlikely that Steven Johnson can re-license his code with a license
> >> >>> that is compatible with SciPy.  The GPL is viral that way (insert
> the
> >> >>> usual "I am not a lawyer" disclaimer here).
> >> >>
> >> >> It's not quite as viral as that. He can license the code that he
> >> >> himself
> >> >> wrote under whatever license he likes as long as it is compatible
> with
> >> >> the
> >> >> GPL license of the other libraries that he is combining his code
> with.
> >> If
> >> >> the code that he wrote is separable from HIntLib and GSL by rewriting
> >> >> that
> >> >> functionality, he can distribute his code under the BSD license for
> >> >> inclusion in SciPy.
> >> >
> >> >
> >> > Yes--thanks for the clarification.
> >> >
> >> > Warren
> >> >
> >>
> >>
> >> P.S.:  Saullo, here are a couple links to more information about
> >> compatible licenses:
> >> http://wiki.scipy.org/License_Compatibility
> >> http://matplotlib.org/devel/license.html#license-discussion (the
> >> discussion of the matplotlib license is applicable to scipy)
> >>
> >> Warren
> >>
> >> >
> >> >>
> >> >> --
> >> >> Robert Kern
> >> >>
> >> >
> >>
> >>
> >> ------------------------------
> >>
> >> _______________________________________________
> >> SciPy-Dev mailing list
> >> SciPy-Dev at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
> >>
> >>
> >> End of SciPy-Dev Digest, Vol 118, Issue 36
> >> ******************************************
> >>
> >
>
>
> ------------------------------
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
> End of SciPy-Dev Digest, Vol 118, Issue 39
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130827/aa5207a7/attachment.html>

From pav at iki.fi  Tue Aug 27 13:06:35 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Tue, 27 Aug 2013 20:06:35 +0300
Subject: [SciPy-Dev] Triangulation on sphere surface with qhull(-wrapper)
In-Reply-To: <521BBE97.2070506@hilboll.de>
References: <521BBE97.2070506@hilboll.de>
Message-ID: <kvimaj$tal$1@ger.gmane.org>

Hi,

26.08.2013 23:46, Andreas Hilboll kirjoitti:
> I was wondering if qhull supports Delaunay triangulation of data on
> the unit sphere? If so, I'd like to implement an appropriate
> wrapper to have an alternative to the FITPACK-based interpolation
> on spheres. Otherwise, there's STRIPACK as an alternative, and it
> would probably be easy to wrap it (if license is compatible; so far
> I couldn't find any license info on STRIPACK). But I have a feeling
> qhull should be able to do this as well; I just couldn't figure out
> how ...

Yes (see qhull manual or for example [1]): the facets of the convex
hull of points on the N-d unit sphere correspond to the Delaunay
triangulation on the sphere in N-1 dimensions.

	Pauli

[1] http://www.sciencedirect.com/science/article/pii/S0925772102000779




From wbuckner at beatsmusic.com  Thu Aug 29 02:47:21 2013
From: wbuckner at beatsmusic.com (Will Buckner)
Date: Wed, 28 Aug 2013 23:47:21 -0700
Subject: [SciPy-Dev] Many Problems Building w/ MKL 11, ifort, icc;
 scipy.test() Fails w/ Undefined Symbols
In-Reply-To: <CABOfY3Cbc0zCyfO=43RwtU55RjqB9=PDXpKdCduG3R25o-xyqw@mail.gmail.com>
References: <CAL_nGS5gb-U2v3N6QwMHWZ70NNzuk_OS1ciFE0r8fLRK+NeHvA@mail.gmail.com>
	<CABL7CQgihY5_yGmsxzO_UqWa78WE-z-R-7_MEONsvmt=XZ9_RA@mail.gmail.com>
	<CAL_nGS4bA6QxhNxKKVddAc=HRZDTYUeNodDryCuPn8kSBJZH5Q@mail.gmail.com>
	<CABOfY3Cbc0zCyfO=43RwtU55RjqB9=PDXpKdCduG3R25o-xyqw@mail.gmail.com>
Message-ID: <CAL_nGS4YDenB8rQLzwqFDztqb4ApPvR-fY_LpAQUvn8VON07Tw@mail.gmail.com>

Thanks, but, I had already added them to ld.so.conf.d/ and ran ldconfig. I
eventually got it to run without LD_RUN_PATH somehow by removing everything
in build/ (had previously been running python setup.py clean) and finally
got everything to work fairly sanely with:

[mkl]
library_dirs = /opt/intel/mkl/lib/intel64:/opt/intel/lib/intel64
include_dirs = /opt/intel/mkl/include:/opt/intel/include
mkl_libs =  mkl_def, mkl_intel_lp64, mkl_intel_thread, mkl_core, mkl_mc,
iomp5
lapack_libs =

> Also, isn't libmkl_mc specific to the mic architecture? I don't think
it's necessary to explicitly link against it. Instead, libiomp5, libimf and
libirc are libraries I often find are required.

So I know nothing about the MKL stack, or BLAS for that matter. Intel docs
say "Kernel library for processors based on the Intel(R) Core(TM)
microarchitecture". My CPUs are "Intel(R) Xeon(R) CPU E7- 4860  @ 2.27GHz".
Also keep in mind, this is MKL 11 and a lot has changed since
9x, apparently, and it seems most everyone writing docs on MKL w/
SciPy/NumPy is using older MKL. What I really want to figure out is how to
get "mkl_rt" working properly.

Should I have something in lapack_libs?

Thanks!

On Thu, Aug 22, 2013 at 3:40 PM, Alex Leach <beamesleach at gmail.com> wrote:

> Looks to me like you need to update your system's ldconfig files. Without
> an -rpath / -R linker flag, the lib. directories will need to be known by
> the dynamic linker during run time, as well as during compile-time linking
> (which appears to complete successfully).
>
> This is accomplished by creating a file in /etc/ldconfig.d/ and putting
> each of Intel's lib directories on a separate line. Finally, run ldconfig
> as root.
>
> Also, isn't libmkl_mc specific to the mic architecture? I don't think it's
> necessary to explicitly link against it. Instead, libiomp5, libimf and
> libirc are libraries I often find are required.
>
> KR, and good luck!
> Alex
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130828/772c484b/attachment.html>

From xabart at gmail.com  Thu Aug 29 03:03:55 2013
From: xabart at gmail.com (Xavier Barthelemy)
Date: Thu, 29 Aug 2013 17:03:55 +1000
Subject: [SciPy-Dev] Many Problems Building w/ MKL 11, ifort, icc;
 scipy.test() Fails w/ Undefined Symbols
In-Reply-To: <CAL_nGS4YDenB8rQLzwqFDztqb4ApPvR-fY_LpAQUvn8VON07Tw@mail.gmail.com>
References: <CAL_nGS5gb-U2v3N6QwMHWZ70NNzuk_OS1ciFE0r8fLRK+NeHvA@mail.gmail.com>
	<CABL7CQgihY5_yGmsxzO_UqWa78WE-z-R-7_MEONsvmt=XZ9_RA@mail.gmail.com>
	<CAL_nGS4bA6QxhNxKKVddAc=HRZDTYUeNodDryCuPn8kSBJZH5Q@mail.gmail.com>
	<CABOfY3Cbc0zCyfO=43RwtU55RjqB9=PDXpKdCduG3R25o-xyqw@mail.gmail.com>
	<CAL_nGS4YDenB8rQLzwqFDztqb4ApPvR-fY_LpAQUvn8VON07Tw@mail.gmail.com>
Message-ID: <CAHmOPjv6epkPcZnUV5Xc6oqu1v73Vvv17M89JD7sSr5+7F6Aqw@mail.gmail.com>

mkl_rt are working well for me,
here are my options:

site.cfg:


[mkl]
#Vversion=composer_xe_2011_sp1.7.256
#Vversion=composer_xe_2011_sp1.8.273
#Vversion=composer_xe_2011_sp1.9.293
#Vversion=composer_xe_2011_sp1.10.319
#Vversion=composer_xe_2011_sp1.11.339
#Vversion=composer_xe_2013.1.117
Vversion=composer_xe_2013.3.163

library_dirs =
 /opt/intel/%(Vversion)s/mkl/lib/intel64:/opt/intel/%(Vversion)s/compiler/lib/intel64
include_dirs =
 /opt/intel/%(Vversion)s/mkl/include:/opt/intel/%(Vversion)s/mkl/include/intel64/lp64
lapack_libs =  mkl_blas95_lp64, mkl_lapack95_lp64
mkl_libs =   mkl_rt

in numpy/distutils/intelccompiler.py:



class IntelCCompiler(UnixCCompiler):
    """ A modified Intel compiler compatible with an gcc built Python."""
    compiler_type = 'intel'
    cc_exe = 'icc'
    cc_args = 'fPIC'

    def __init__ (self, verbose=0, dry_run=0, force=0):
        UnixCCompiler.__init__ (self, verbose,dry_run, force)
        self.cc_exe = 'icc -fPIC'
        compiler = self.cc_exe
        self.set_executables(compiler=compiler,
                             compiler_so=compiler,
                             compiler_cxx=compiler,
                             linker_exe=compiler,
                             linker_so=compiler + ' -shared')

class IntelItaniumCCompiler(IntelCCompiler):
    compiler_type = 'intele'

    # On Itanium, the Intel Compiler used to be called ecc, let's search for
    # it (now it's also icc, so ecc is last in the search).
    for cc_exe in map(find_executable,['icc','ecc']):
        if cc_exe:
            break

class IntelEM64TCCompiler(UnixCCompiler):
    """ A modified Intel x86_64 compiler compatible with a 64bit gcc built
Python.
    """
    Vversion='composer_xe_2011_sp1.9.293'
    Vversion='composer_xe_2011_sp1.10.319'
    Vversion='composer_xe_2011_sp1.11.339'
    Vversion='composer_xe_2013.1.117'
    Vversion='composer_xe_2013.3.163'
    LDir='-L/opt/intel/'+Vversion+'/mkl/lib/intel64
'+'-L/opt/intel/'+Vversion+'/compiler/lib/intel64 '
    IDir='-I/opt/intel/'+Vversion+'/mkl/include/intel64/lp64
'+'-I/opt/intel/'+Vversion+'/mkl/include '
    compiler_type = 'intelem'
    cc_exe = 'icc -m64 -O3 -g -fPIC -fp-model strict -fomit-frame-pointer
-openmp -xHost -lpthread '+IDir+LDir
    cc_args = '-m64 -O3 -g -fPIC -fp-model strict -fomit-frame-pointer
-openmp -xHost -lpthread '+IDir+LDir
    def __init__ (self, verbose=0, dry_run=0, force=0):
        UnixCCompiler.__init__ (self, verbose,dry_run, force)
        Vversion='composer_xe_2011_sp1.9.293'
        Vversion='composer_xe_2011_sp1.10.319'
        Vversion='composer_xe_2011_sp1.11.339'
        Vversion='composer_xe_2013.1.117'
        Vversion='composer_xe_2013.3.163'
        LDir='-L/opt/intel/'+Vversion+'/mkl/lib/intel64
'+'-L/opt/intel/'+Vversion+'/compiler/lib/intel64 '
        IDir='-I/opt/intel/'+Vversion+'/mkl/include/intel64/lp64
'+'-I/opt/intel/'+Vversion+'/mkl/include '
        self.cc_exe = 'icc -m64 -O3 -g -fPIC -fp-model strict
-fomit-frame-pointer -openmp -xHost -lpthread '+IDir+LDir
        compiler = self.cc_exe
        self.set_executables(compiler=compiler,
                             compiler_so=compiler,
                             compiler_cxx=compiler,
                             linker_exe=compiler,
                             linker_so=compiler + ' -shared')


and  in  numpy/distutils/fcompiler/intel.py:

    def get_flags_opt(self):
        return ['-xhost -m64 -openmp -fp-model strict']


My script to compile everything is:
python setup.py config --compiler=intelem --fcompiler=intelem config_fc
--fcompiler=intelem build_clib --compiler=intelem --fcompiler=intelem
build_ext --compiler=intelem --fcompiler=intelem install
--prefix=/opt/Python/Numpy-1.7.1-intel


I hope it helps

Xavier


2013/8/29 Will Buckner <wbuckner at beatsmusic.com>

>
> Thanks, but, I had already added them to ld.so.conf.d/ and ran ldconfig. I
> eventually got it to run without LD_RUN_PATH somehow by removing everything
> in build/ (had previously been running python setup.py clean) and finally
> got everything to work fairly sanely with:
>
> [mkl]
> library_dirs = /opt/intel/mkl/lib/intel64:/opt/intel/lib/intel64
> include_dirs = /opt/intel/mkl/include:/opt/intel/include
> mkl_libs =  mkl_def, mkl_intel_lp64, mkl_intel_thread, mkl_core, mkl_mc,
> iomp5
> lapack_libs =
>
> > Also, isn't libmkl_mc specific to the mic architecture? I don't think
> it's necessary to explicitly link against it. Instead, libiomp5, libimf and
> libirc are libraries I often find are required.
>
> So I know nothing about the MKL stack, or BLAS for that matter. Intel docs
> say "Kernel library for processors based on the Intel(R) Core(TM)
> microarchitecture". My CPUs are "Intel(R) Xeon(R) CPU E7- 4860  @
> 2.27GHz". Also keep in mind, this is MKL 11 and a lot has changed since
> 9x, apparently, and it seems most everyone writing docs on MKL w/
> SciPy/NumPy is using older MKL. What I really want to figure out is how to
> get "mkl_rt" working properly.
>
> Should I have something in lapack_libs?
>
> Thanks!
>
> On Thu, Aug 22, 2013 at 3:40 PM, Alex Leach <beamesleach at gmail.com> wrote:
>
>> Looks to me like you need to update your system's ldconfig files. Without
>> an -rpath / -R linker flag, the lib. directories will need to be known by
>> the dynamic linker during run time, as well as during compile-time linking
>> (which appears to complete successfully).
>>
>> This is accomplished by creating a file in /etc/ldconfig.d/ and putting
>> each of Intel's lib directories on a separate line. Finally, run ldconfig
>> as root.
>>
>> Also, isn't libmkl_mc specific to the mic architecture? I don't think
>> it's necessary to explicitly link against it. Instead, libiomp5, libimf and
>> libirc are libraries I often find are required.
>>
>> KR, and good luck!
>> Alex
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


-- 
 ? Quand le gouvernement viole les droits du peuple, l'insurrection est,
pour le peuple et pour chaque portion du peuple, le plus sacr? des droits
et le plus indispensable des devoirs ?

D?claration des droits de l'homme et du citoyen, article 35, 1793
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130829/8c9919cd/attachment.html>

From saullogiovani at gmail.com  Thu Aug 29 03:53:47 2013
From: saullogiovani at gmail.com (Saullo Castro)
Date: Thu, 29 Aug 2013 09:53:47 +0200
Subject: [SciPy-Dev] Integration module for N-D array-valued functions
Message-ID: <CAHbwRz6xH7gheka0YQw=huxk0B8E9YiPzS6UtSQ7+8xHwV12Ag@mail.gmail.com>

I would like to know if there is an interest to add into SciPy some
integrators for vector valued functions that I've been working on:

- trapzv
- trapz2dv
- simpsv
- simps2dv
- polyv (1-D vector-valued functions integration using many nth order
polynoms)

Only polyv is for 1-D vector-valued functions, while the others are for any
N-D array-valued function.

If there is an interest, I have a suggestion to include all these function
into a integratev.pyx file (since they are programmed in Cython), inside
scipy/integrate.

What do you think?

Greetings,
Saullo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130829/fde8a156/attachment.html>

From lists at hilboll.de  Thu Aug 29 12:01:21 2013
From: lists at hilboll.de (Andreas Hilboll)
Date: Thu, 29 Aug 2013 18:01:21 +0200
Subject: [SciPy-Dev] Akima Interpolation
Message-ID: <521F7051.7090102@hilboll.de>

I'd like to have Akima interpolation in scipy.interpolate, as I couldn't
find any.

1.) Did I miss something and there actually *is* an Akima interpolation
    in scipy?
2.) Is there interest in having Akima interpolation in Scipy?
3.) Does anyone have a good recommendation which implementation I
    should consider for pulling into Scipy?

-- Andreas.


From orion at cora.nwra.com  Thu Aug 29 15:41:36 2013
From: orion at cora.nwra.com (Orion Poplawski)
Date: Thu, 29 Aug 2013 13:41:36 -0600
Subject: [SciPy-Dev] ANN: Scipy 0.13.0 beta 1 release
In-Reply-To: <CABL7CQga-Qkq8_hG1E+_KfpmVjSE-duyRePVcZw_-s-PXay75w@mail.gmail.com>
References: <CABL7CQga-Qkq8_hG1E+_KfpmVjSE-duyRePVcZw_-s-PXay75w@mail.gmail.com>
Message-ID: <521FA3F0.6070508@cora.nwra.com>

On 08/22/2013 07:12 AM, Ralf Gommers wrote:
> Hi all,
>
> I'm happy to announce the availability of the first beta release of Scipy
> 0.13.0. Please try this beta and report any issues on the scipy-dev mailing list.

With Fedora Rawhide (but not Fedora 19) I'm seeing:

ERROR: test_fitpack.TestSplder.test_kink
----------------------------------------------------------------------
Traceback (most recent call last):
   File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
     self.test(*self.arg)
   File 
"/builddir/build/BUILDROOT/scipy-0.13.0-0.1.b1.fc21.x86_64/usr/lib64/python2.7/site-packages/scipy/interpolate/tests/test_fitpack.py", 
line 326, in test_kink
     splder(spl2, 2)  # Should work
   File 
"/builddir/build/BUILDROOT/scipy-0.13.0-0.1.b1.fc21.x86_64/usr/lib64/python2.7/site-packages/scipy/interpolate/fitpack.py", 
line 1186, in splder
     "and is not differentiable %d times") % n)
ValueError: The spline has internal repeated knots and is not differentiable 2 
times

and the same with python3.


-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion at nwra.com
Boulder, CO 80301                   http://www.nwra.com


From cournape at gmail.com  Fri Aug 30 06:43:16 2013
From: cournape at gmail.com (David Cournapeau)
Date: Fri, 30 Aug 2013 11:43:16 +0100
Subject: [SciPy-Dev] Purpose of commit 359cf0 ?
Message-ID: <CAGY4rcXOXEX52e_7md49SeCEUmEbw6ZSbgbTjoXr2sso=FU3JA@mail.gmail.com>

Hi there,

I see that this fix broke visual studio build in a non trivial manner (a
few cephes functions are declared in VS math.h, with incompatible linkage).

I don't understand the fix: which platform did it fix, and why not having
isfinite matter since we're using npy_ macro in struve.c ?

thanks,

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130830/30c93a6e/attachment.html>

From cournape at gmail.com  Fri Aug 30 07:21:23 2013
From: cournape at gmail.com (David Cournapeau)
Date: Fri, 30 Aug 2013 12:21:23 +0100
Subject: [SciPy-Dev] ANN: Scipy 0.13.0 beta 1 release
In-Reply-To: <5216A288.4060108@uci.edu>
References: <CABL7CQga-Qkq8_hG1E+_KfpmVjSE-duyRePVcZw_-s-PXay75w@mail.gmail.com>
	<5216A288.4060108@uci.edu>
Message-ID: <CAGY4rcWMe2ANSP+nT4S+6hkruw9dhgn6gNgxfGhOYD8tv8h8nQ@mail.gmail.com>

Christoph, didn't you have any issues with too many files open failures ? I
am using windows 7 and not 8, and I always have to restart the build
several times to get it finished.

David


On Fri, Aug 23, 2013 at 12:45 AM, Christoph Gohlke <cgohlke at uci.edu> wrote:

> On 8/22/2013 6:12 AM, Ralf Gommers wrote:
> > Hi all,
> >
> > I'm happy to announce the availability of the first beta release of
> > Scipy 0.13.0. Please try this beta and report any issues on the
> > scipy-dev mailing list.
> >
> > Source tarballs and release notes can be found at
> > https://sourceforge.net/projects/scipy/files/scipy/0.13.0b1/. Windows
> > and OS X installers will follow later (we have a minor infrastructure
> > issue to solve, and I'm at EuroScipy now).
> >
> > Cheers,
> > Ralf
> >
> >
>
>
> Hi Ralf,
>
> I built and tested scipy 0.13.0b1 on Windows 8 with Visual Studio 2008 &
> 2010, Intel Studio XE 2013 Fortran and MKL, Python 2.7 & 3.3 (32 & 64
> bit), and numpy 1.7.1.
>
> The `scipy.ndimage._ni_label` extension fails to compile
> <https://github.com/scipy/scipy/pull/2770>.
>
> The win-amd64-py2.7 build passes all tests.
>
> On Python 3 there are 12 errors in `test_wavfile.test_write_roundtrip`
> of the following kind:
> ```
> ======================================================================
> ERROR: test_wavfile.test_write_roundtrip(False, 8000, dtype('>i8'), 1)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>    File "X:\Python33\lib\site-packages\nose\case.py", line 198, in runTest
>      self.test(*self.arg)
>    File "X:\Python33\lib\site-packages\scipy\io\tests\test_wavfile.py",
> line 73, in _check_roundtrip
>      rate2, data2 = wavfile.read(tmpfile, mmap=mmap)
>    File "X:\Python33\lib\site-packages\scipy\io\wavfile.py", line 166,
> in read
>      data = _read_data_chunk(fid, comp, noc, bits, mmap=mmap)
>    File "X:\Python33\lib\site-packages\scipy\io\wavfile.py", line 71, in
> _read_data_chunk
>      data = numpy.fromstring(fid.read(size), dtype=dtype)
> ValueError: cannot expose native-only dtype 'q' in non-native byte order
> '>' via buffer interface
> ```
>
> On 32 bit Python `test_distributions.TestFitMethod.test_fix_fit_beta`
> fails with an error:
>
> ```
> ======================================================================
> ERROR: test_distributions.TestFitMethod.test_fix_fit_beta
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>    File "X:\Python33-x32\lib\site-packages\nose\case.py", line 198, in
> runTest
>      self.test(*self.arg)
>    File
>
> "X:\Python33-x32\lib\site-packages\scipy\stats\tests\test_distributions.py",
> line 928, in test_fix_fit_beta
>      assert_raises(ValueError, stats.beta.fit, x, floc=0.5, fscale=1)
>    File "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py", line
> 1019, in assert_raises
>      return nose.tools.assert_raises(*args,**kwargs)
>    File "X:\Python33-x32\lib\unittest\case.py", line 570, in assertRaises
>      return context.handle('assertRaises', callableObj, args, kwargs)
>    File "X:\Python33-x32\lib\unittest\case.py", line 135, in handle
>      callable_obj(*args, **kwargs)
>    File
> "X:\Python33-x32\lib\site-packages\scipy\stats\distributions.py", line
> 2533, in fit
>      raise FitSolverError(mesg=mesg)
> scipy.stats.distributions.FitSolverError: Solver for the MLE equations
> failed to converge: The iteration is not making good progress, as
> measured by the   improvement from the last ten iterations.
> ```
>
>
> Also on 32 bit Python, `test_windows.test_windowfunc_basics` and
> `test_decomp.TestEig.test_singular` sometimes fail:
> ```
> ======================================================================
> FAIL: test_windows.test_windowfunc_basics
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>    File "X:\Python33-x32\lib\site-packages\nose\case.py", line 198, in
> runTest
>      self.test(*self.arg)
>    File
> "X:\Python33-x32\lib\site-packages\scipy\signal\tests\test_windows.py",
> line 100, in test_windowfunc_basics
>      assert_array_almost_equal(w1, w2)
>    File "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py", line
> 812, in assert_array_almost_equal
>      header=('Arrays are not almost equal to %d decimals' % decimal))
>    File "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py", line
> 645, in assert_array_compare
>      raise AssertionError(msg)
> AssertionError:
> Arrays are not almost equal to 6 decimals
>
> (mismatch 85.71428571428571%)
>   x: array([ 0.02221406,  1.        ,  0.32944607,  0.16207939,
>  0.18485882,
>          0.36183308,  0.02298899])
>   y: array([ 0.01910267,  1.        ,  0.34644519,  0.09150573,
>  0.09150573,
>          0.17127567,  0.12123497])
>
> ======================================================================
> FAIL: test_decomp.TestEig.test_singular
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>    File "X:\Python33-x32\lib\site-packages\nose\case.py", line 198, in
> runTest
>      self.test(*self.arg)
>    File
> "X:\Python33-x32\lib\site-packages\scipy\linalg\tests\test_decomp.py",
> line 219, in test_singular
>      self._check_gen_eig(A, B)
>    File
> "X:\Python33-x32\lib\site-packages\scipy\linalg\tests\test_decomp.py",
> line 206, in _check_gen_eig
>      err_msg=msg)
>    File "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py", line
> 812, in assert_array_almost_equal
>      header=('Arrays are not almost equal to %d decimals' % decimal))
>    File "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py", line
> 645, in assert_array_compare
>      raise AssertionError(msg)
> AssertionError:
> Arrays are not almost equal to 6 decimals
>
> array([[22, 34, 31, 31, 17],
>         [45, 45, 42, 19, 29],
>         [39, 47, 49, 26, 34],
>         [27, 31, 26, 21, 15],
>         [38, 44, 44, 24, 30]])
> array([[13, 26, 25, 17, 24],
>         [31, 46, 40, 26, 37],
>         [26, 40, 19, 25, 25],
>         [16, 25, 27, 14, 23],
>         [24, 35, 18, 21, 22]])
> (mismatch 50.0%)
>   x: array([ -5.90370943e-01+0.j,  -1.54128768e-07+0.j,
> 1.54128748e-07+0.j,
>           2.00000000e+00+0.j])
>   y: array([ -1.32014829e-08+0.j,   1.32014809e-08+0.j,
> 1.33224503e+00+0.j,
>           2.00000000e+00+0.j])
> ```
>
> Christoph
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130830/7b5f4549/attachment.html>

From warren.weckesser at gmail.com  Fri Aug 30 07:31:39 2013
From: warren.weckesser at gmail.com (Warren Weckesser)
Date: Fri, 30 Aug 2013 07:31:39 -0400
Subject: [SciPy-Dev] Akima Interpolation
In-Reply-To: <521F7051.7090102@hilboll.de>
References: <521F7051.7090102@hilboll.de>
Message-ID: <CAGzF1udD4NezobxA1CFq=8sPsd8Q5-0peT59p1d8NXAk44Nxpg@mail.gmail.com>

On 8/29/13, Andreas Hilboll <lists at hilboll.de> wrote:
> I'd like to have Akima interpolation in scipy.interpolate, as I couldn't
> find any.
>
> 1.) Did I miss something and there actually *is* an Akima interpolation
>     in scipy?


I don't see it anywhere in scipy.


> 2.) Is there interest in having Akima interpolation in Scipy?


Yes, it would be a good addition to scipy.


> 3.) Does anyone have a good recommendation which implementation I
>     should consider for pulling into Scipy?


A search for "python akima" turns up Christoph Gohlke's
implementation: http://www.lfd.uci.edu/~gohlke/code/akima.py.html

The comments say it is based on a Matlab version by N. Shamsundar,
which is here: http://www.mathworks.com/matlabcentral/fileexchange/1814-akima-interpolation


Warren


>
> -- Andreas.
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From howarth at bromo.med.uc.edu  Fri Aug 30 10:27:23 2013
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Fri, 30 Aug 2013 10:27:23 -0400
Subject: [SciPy-Dev] ANN: Scipy 0.13.0 beta 1 release
In-Reply-To: <CABL7CQhRQdzjedXid_B0VDc55-AiMnCbaryrPHwTjKSPsBvqyQ@mail.gmail.com>
References: <CABL7CQga-Qkq8_hG1E+_KfpmVjSE-duyRePVcZw_-s-PXay75w@mail.gmail.com>
	<20130823235831.GA6527@bromo.med.uc.edu>
	<CABL7CQhRQdzjedXid_B0VDc55-AiMnCbaryrPHwTjKSPsBvqyQ@mail.gmail.com>
Message-ID: <20130830142723.GA10981@bromo.med.uc.edu>

On Sat, Aug 24, 2013 at 11:11:36AM +0200, Ralf Gommers wrote:
> On Sat, Aug 24, 2013 at 1:58 AM, Jack Howarth <howarth at bromo.med.uc.edu>wrote:
> 
> > On Thu, Aug 22, 2013 at 03:12:21PM +0200, Ralf Gommers wrote:
> > > Hi all,
> > >
> > > I'm happy to announce the availability of the first beta release of Scipy
> > > 0.13.0. Please try this beta and report any issues on the scipy-dev
> > mailing
> > > list.
> > >
> > > Source tarballs and release notes can be found at
> > > https://sourceforge.net/projects/scipy/files/scipy/0.13.0b1/. Windows
> > and
> > > OS X installers will follow later (we have a minor infrastructure issue
> > to
> > > solve, and I'm at EuroScipy now).
> > >
> > > Cheers,
> > > Ralf
> >
> > Ralf,
> >    FYI, if the proposed elimination of support for the Accelerate
> > framework on
> > darwin was implemented in scipy 0.13, you will definietely want to
> > consider reverting that
> > change. It appears that the issues in the Accelerate framework (at least as
> > tested with scipy 0.12.0) are resolved in the next darwin release...
> >
> 
> Hi Jack, the issues appear to have been resolved completely (thanks to
> Michael Wimmer and Pauli), so we didn't drop support or used OpenBLAS for
> the binaries.
> 
> Ralf

Ralf,
   Unfortunately, I am seeing a linkage failure in 0.13.0 beta1 on darwin13 using
the same build recipe that we use in fink for 0.12.0...

/sw/bin/gfortran -Wall -L/sw/lib build/temp.macosx-10.9-x86_64-2.7/build/src.macosx-10.9-x86_64-2.7/scipy/linalg/_interpolativemodule.o build/temp.macosx-10.9-x86_64-2.7/build/src.macosx-10.9-x86_64-2.7/fortranobject.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_2.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_3.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_4.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_5.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_6.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_7.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_8.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_9.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_10.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_11.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_12.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_13.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_14.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_15.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_16.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_17.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_18.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_19.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_20.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_21.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_22.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_23.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_24.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_25.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_26.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_27.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_28.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_29.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_30.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_31.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_32.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_33.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_34.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_35.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_36.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_37.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_38.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_39.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_40.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_41.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_42.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_43.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_44.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_45.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_46.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_47.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/dfft_subr_48.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/id_rand_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/id_rand_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/id_rand_subr_2.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/id_rtrans_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/id_rtrans_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/id_rtrans_subr_2.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/id_rtrans_subr_3.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/id_rtrans_subr_4.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/id_rtrans_subr_5.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/id_rtrans_subr_6.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/id_rtrans_subr_7.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/id_rtrans_subr_8.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/id_rtrans_subr_9.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/id_rtrans_subr_10.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/id_rtrans_subr_11.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/id_rtrans_subr_12.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/id_rtrans_subr_13.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/id_rtrans_subr_14.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/id_rtrans_subr_15.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/id_rtrans_subr_16.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/id_rtrans_subr_17.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_frm_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_frm_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_frm_subr_2.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_frm_subr_3.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_frm_subr_4.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_frm_subr_5.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_frm_subr_6.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_frm_subr_7.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_frm_subr_8.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_house_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_house_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_house_subr_2.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_id_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_id_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_id_subr_2.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_id_subr_3.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_id_subr_4.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_id_subr_5.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_id_subr_6.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_id_subr_7.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_id2svd_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_id2svd_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_id2svd_subr_2.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_id2svd_subr_3.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_id2svd_subr_4.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_id2svd_subr_5.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_qrpiv_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_qrpiv_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_qrpiv_subr_2.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_qrpiv_subr_3.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_qrpiv_subr_4.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_qrpiv_subr_5.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_sfft_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_sfft_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_sfft_subr_2.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_sfft_subr_3.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_sfft_subr_4.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_sfft_subr_5.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_sfft_subr_6.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_snorm_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_snorm_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_snorm_subr_2.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_snorm_subr_3.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_svd_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_svd_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_svd_subr_2.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_svd_subr_3.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idd_svd_subr_4.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/iddp_aid_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/iddp_aid_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/iddp_aid_subr_2.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/iddp_aid_subr_3.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/iddp_aid_subr_4.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/iddp_aid_subr_5.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/iddp_asvd_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/iddp_asvd_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/iddp_rid_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/iddp_rid_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/iddp_rid_subr_2.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/iddp_rid_subr_3.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/iddp_rid_subr_4.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/iddp_rsvd_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/iddp_rsvd_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/iddr_aid_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/iddr_aid_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/iddr_aid_subr_2.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/iddr_aid_subr_3.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/iddr_asvd_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/iddr_asvd_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/iddr_rid_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/iddr_rid_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/iddr_rsvd_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/iddr_rsvd_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_frm_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_frm_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_frm_subr_2.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_frm_subr_3.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_frm_subr_4.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_frm_subr_5.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_frm_subr_6.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_house_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_house_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_house_subr_2.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_id_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_id_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_id_subr_2.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_id_subr_3.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_id_subr_4.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_id_subr_5.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_id_subr_6.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_id_subr_7.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_id2svd_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_id2svd_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_id2svd_subr_2.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_id2svd_subr_3.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_id2svd_subr_4.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_id2svd_subr_5.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_qrpiv_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_qrpiv_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_qrpiv_subr_2.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_qrpiv_subr_3.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_qrpiv_subr_4.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_qrpiv_subr_5.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_sfft_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_sfft_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_sfft_subr_2.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_snorm_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_snorm_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_snorm_subr_2.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_snorm_subr_3.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_svd_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_svd_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_svd_subr_2.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_svd_subr_3.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_svd_subr_4.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idz_svd_subr_5.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idzp_aid_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idzp_aid_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idzp_aid_subr_2.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idzp_aid_subr_3.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idzp_aid_subr_4.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idzp_aid_subr_5.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idzp_asvd_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idzp_asvd_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idzp_asvd_subr_2.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idzp_rid_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idzp_rid_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idzp_rid_subr_2.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idzp_rid_subr_3.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idzp_rid_subr_4.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idzp_rsvd_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idzp_rsvd_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idzp_rsvd_subr_2.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idzr_aid_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idzr_aid_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idzr_aid_subr_2.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idzr_aid_subr_3.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idzr_asvd_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idzr_asvd_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idzr_rid_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idzr_rid_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idzr_rsvd_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/idzr_rsvd_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/prini_subr_0.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/prini_subr_1.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/prini_subr_2.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/prini_subr_3.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/prini_subr_4.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/prini_subr_5.o build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/prini_subr_6.o -L/sw/lib/gcc4.8/lib/gcc/x86_64-apple-darwin13.0.0/4.8.1 -Lbuild/temp.macosx-10.9-x86_64-2.7 -lgfortran -o build/lib.macosx-10.9-x86_64-2.7/scipy/linalg/_interpolative.so -Wl,-framework -Wl,Accelerate
Undefined symbols for architecture x86_64:
  "_PyArg_ParseTupleAndKeywords", referenced from:
      _f2py_rout__interpolative_id_srand in _interpolativemodule.o
      _f2py_rout__interpolative_id_srandi in _interpolativemodule.o
      _f2py_rout__interpolative_id_srando in _interpolativemodule.o
      _f2py_rout__interpolative_idd_frm in _interpolativemodule.o
      _f2py_rout__interpolative_idd_sfrm in _interpolativemodule.o
      _f2py_rout__interpolative_idd_frmi in _interpolativemodule.o
      _f2py_rout__interpolative_idd_sfrmi in _interpolativemodule.o
      ...

etc. This is using...

a site.cfg with...

[amd]
library_dirs = /sw/lib
include_dirs = /sw/include/suitesparse
amd_libs = amd

[umfpack]
library_dirs = /sw/lib
include_dirs = /sw/include/suitesparse
umfpack_libs = umfpack

and

   export CC=clang
   export CXX=clang++
   export FFLAGS=-ff2c
   export FC=/sw/bin/gfortran

   unset LDFLAGS
   /sw/bin/python2.7 setup.py build --fcompiler gnu95

with a build against suitesparse 4.0.2 and numpy 1.7.1.
      Jack

 
> 
> 
> > Ran 6134 tests in 88.016s
> >
> > OK (KNOWNFAIL=15, SKIP=36)
> >
> > compared to darwin12...
> >
> > Ran 6134 tests in 96.886s
> >
> > FAILED (KNOWNFAIL=15, SKIP=36, failures=63)
> >
> > and darwin11...
> >
> > Ran 6134 tests in 118.346s
> >
> > FAILED (KNOWNFAIL=15, SKIP=36, failures=65)
> >
> >              Jack
> > ps I have looked at the proposed replacement of using openblas and it is
> > rather suboptimal. Please
> > don't inflict that on us.
> >
> > > _______________________________________________
> > > SciPy-Dev mailing list
> > > SciPy-Dev at scipy.org
> > > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >

> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev



From pav at iki.fi  Fri Aug 30 12:08:15 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Fri, 30 Aug 2013 19:08:15 +0300
Subject: [SciPy-Dev] Purpose of commit 359cf0 ?
In-Reply-To: <CAGY4rcXOXEX52e_7md49SeCEUmEbw6ZSbgbTjoXr2sso=FU3JA@mail.gmail.com>
References: <CAGY4rcXOXEX52e_7md49SeCEUmEbw6ZSbgbTjoXr2sso=FU3JA@mail.gmail.com>
Message-ID: <kvqg17$u7g$1@ger.gmane.org>

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

Hi,

30.08.2013 13:43, David Cournapeau kirjoitti:
> I see that this fix broke visual studio build in a non trivial
> manner (a few cephes functions are declared in VS math.h, with
> incompatible linkage).
> 
> I don't understand the fix: which platform did it fix, and why not
> having isfinite matter since we're using npy_ macro in struve.c ?

The platform it fixed was Centos 5 + epd-7.0-2-rh5-x86_64 (with Numpy
1.5.1 and Python 2.7.1).

There is a weird interaction between the header files, which causes
import to fail with

	./_ufuncs.so: undefined symbol: isfinite

if <math.h> is included before <Python.h> (which is included from
amos_wrappers.h). So perhaps the Python setup is just broken there.

Other ideas how to fix it? (NB: You can ask Ognen for account on
docs.scipy.org if you want to debug it yourself.)

    ***

This seems to show that no matter how trivial the change is, do it via
PR rather than just pushing it...

	Pauli

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlIgw2oACgkQ6BQxb7O0pWDZPgCggOiJZ4bUaWpAOQetqwyTWaMq
aGQAniF9zI+ssNErWxb2Vsh6GpiNJ2Cb
=Bt9Q
-----END PGP SIGNATURE-----



From pav at iki.fi  Fri Aug 30 12:15:10 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Fri, 30 Aug 2013 19:15:10 +0300
Subject: [SciPy-Dev] Akima Interpolation
In-Reply-To: <521F7051.7090102@hilboll.de>
References: <521F7051.7090102@hilboll.de>
Message-ID: <kvqge6$3gd$1@ger.gmane.org>

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

29.08.2013 19:01, Andreas Hilboll kirjoitti:
> I'd like to have Akima interpolation in scipy.interpolate, as I
> couldn't find any.
> 
> 1.) Did I miss something and there actually *is* an Akima
> interpolation in scipy? 2.) Is there interest in having Akima
> interpolation in Scipy? 3.) Does anyone have a good recommendation
> which implementation I should consider for pulling into Scipy?

1) I don't think so, unless pchip is related.

2) Perhaps. Is it useful?

3) No idea.

One thing to look out: based on a quick look, Akima interpolation is a
form of spline interpolation, so it is probably possible to represent
the result as a B-spline. If so, FITPACK's spline representation
should be used, i.e., the same (t, c, k) format as in splrep.

This allows reusing `splev` for evaluating the spline values, which
will make life easier later on when we clean up scipy.interpolate.

	Pauli
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlIgxQ0ACgkQ6BQxb7O0pWDtqACguWczQGk+t/77wvE563iCpoaQ
bkQAn3mhFX+RWCdNXTpze8dVNAoE3Hl8
=T78D
-----END PGP SIGNATURE-----



From cournape at gmail.com  Fri Aug 30 14:16:05 2013
From: cournape at gmail.com (David Cournapeau)
Date: Fri, 30 Aug 2013 19:16:05 +0100
Subject: [SciPy-Dev] [Numpy-discussion] ANN: Scipy 0.13.0 beta 1 release
In-Reply-To: <CABL7CQga-Qkq8_hG1E+_KfpmVjSE-duyRePVcZw_-s-PXay75w@mail.gmail.com>
References: <CABL7CQga-Qkq8_hG1E+_KfpmVjSE-duyRePVcZw_-s-PXay75w@mail.gmail.com>
Message-ID: <CAGY4rcW0svTy_WH9GR2C_JTcAea5gBj0G3uD7sEnVOLqozKMRA@mail.gmail.com>

It looks like it broke the build with MKL as well (in, surprised, ARPACK).
I will investigate this further this WE


On Thu, Aug 22, 2013 at 2:12 PM, Ralf Gommers <ralf.gommers at gmail.com>wrote:

> Hi all,
>
> I'm happy to announce the availability of the first beta release of Scipy
> 0.13.0. Please try this beta and report any issues on the scipy-dev mailing
> list.
>
> Source tarballs and release notes can be found at
> https://sourceforge.net/projects/scipy/files/scipy/0.13.0b1/. Windows and
> OS X installers will follow later (we have a minor infrastructure issue to
> solve, and I'm at EuroScipy now).
>
> Cheers,
> Ralf
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130830/6b53c0f1/attachment.html>

From cgohlke at uci.edu  Fri Aug 30 14:56:51 2013
From: cgohlke at uci.edu (Christoph Gohlke)
Date: Fri, 30 Aug 2013 11:56:51 -0700
Subject: [SciPy-Dev] ANN: Scipy 0.13.0 beta 1 release
In-Reply-To: <CAGY4rcWMe2ANSP+nT4S+6hkruw9dhgn6gNgxfGhOYD8tv8h8nQ@mail.gmail.com>
References: <CABL7CQga-Qkq8_hG1E+_KfpmVjSE-duyRePVcZw_-s-PXay75w@mail.gmail.com>
	<5216A288.4060108@uci.edu>
	<CAGY4rcWMe2ANSP+nT4S+6hkruw9dhgn6gNgxfGhOYD8tv8h8nQ@mail.gmail.com>
Message-ID: <5220EAF3.4040600@uci.edu>

Yes, I have to restart the build once because of too many (~2000) open 
files. Could be that numpy.distutils.exec_command does not close all 
handles? My build script does `setup.py build` before `setup.py 
bdist_wininst` so I usually don't notice.

Christoph


On 8/30/2013 4:21 AM, David Cournapeau wrote:
> Christoph, didn't you have any issues with too many files open failures
> ? I am using windows 7 and not 8, and I always have to restart the build
> several times to get it finished.
>
> David
>
>
> On Fri, Aug 23, 2013 at 12:45 AM, Christoph Gohlke <cgohlke at uci.edu
> <mailto:cgohlke at uci.edu>> wrote:
>
>     On 8/22/2013 6:12 AM, Ralf Gommers wrote:
>     > Hi all,
>     >
>     > I'm happy to announce the availability of the first beta release of
>     > Scipy 0.13.0. Please try this beta and report any issues on the
>     > scipy-dev mailing list.
>     >
>     > Source tarballs and release notes can be found at
>     >https://sourceforge.net/projects/scipy/files/scipy/0.13.0b1/. Windows
>     > and OS X installers will follow later (we have a minor infrastructure
>     > issue to solve, and I'm at EuroScipy now).
>     >
>     > Cheers,
>     > Ralf
>     >
>     >
>
>
>     Hi Ralf,
>
>     I built and tested scipy 0.13.0b1 on Windows 8 with Visual Studio 2008 &
>     2010, Intel Studio XE 2013 Fortran and MKL, Python 2.7 & 3.3 (32 & 64
>     bit), and numpy 1.7.1.
>
>     The `scipy.ndimage._ni_label` extension fails to compile
>     <https://github.com/scipy/scipy/pull/2770>.
>
>     The win-amd64-py2.7 build passes all tests.
>
>     On Python 3 there are 12 errors in `test_wavfile.test_write_roundtrip`
>     of the following kind:
>     ```
>     ======================================================================
>     ERROR: test_wavfile.test_write_roundtrip(False, 8000, dtype('>i8'), 1)
>     ----------------------------------------------------------------------
>     Traceback (most recent call last):
>         File "X:\Python33\lib\site-packages\nose\case.py", line 198, in
>     runTest
>           self.test(*self.arg)
>         File "X:\Python33\lib\site-packages\scipy\io\tests\test_wavfile.py",
>     line 73, in _check_roundtrip
>           rate2, data2 = wavfile.read(tmpfile, mmap=mmap)
>         File "X:\Python33\lib\site-packages\scipy\io\wavfile.py", line 166,
>     in read
>           data = _read_data_chunk(fid, comp, noc, bits, mmap=mmap)
>         File "X:\Python33\lib\site-packages\scipy\io\wavfile.py", line
>     71, in
>     _read_data_chunk
>           data = numpy.fromstring(fid.read(size), dtype=dtype)
>     ValueError: cannot expose native-only dtype 'q' in non-native byte order
>     '>' via buffer interface
>     ```
>
>     On 32 bit Python `test_distributions.TestFitMethod.test_fix_fit_beta`
>     fails with an error:
>
>     ```
>     ======================================================================
>     ERROR: test_distributions.TestFitMethod.test_fix_fit_beta
>     ----------------------------------------------------------------------
>     Traceback (most recent call last):
>         File "X:\Python33-x32\lib\site-packages\nose\case.py", line 198, in
>     runTest
>           self.test(*self.arg)
>         File
>     "X:\Python33-x32\lib\site-packages\scipy\stats\tests\test_distributions.py",
>     line 928, in test_fix_fit_beta
>           assert_raises(ValueError, stats.beta.fit, x, floc=0.5, fscale=1)
>         File "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py",
>     line
>     1019, in assert_raises
>           return nose.tools.assert_raises(*args,**kwargs)
>         File "X:\Python33-x32\lib\unittest\case.py", line 570, in
>     assertRaises
>           return context.handle('assertRaises', callableObj, args, kwargs)
>         File "X:\Python33-x32\lib\unittest\case.py", line 135, in handle
>           callable_obj(*args, **kwargs)
>         File
>     "X:\Python33-x32\lib\site-packages\scipy\stats\distributions.py", line
>     2533, in fit
>           raise FitSolverError(mesg=mesg)
>     scipy.stats.distributions.FitSolverError: Solver for the MLE equations
>     failed to converge: The iteration is not making good progress, as
>     measured by the   improvement from the last ten iterations.
>     ```
>
>
>     Also on 32 bit Python, `test_windows.test_windowfunc_basics` and
>     `test_decomp.TestEig.test_singular` sometimes fail:
>     ```
>     ======================================================================
>     FAIL: test_windows.test_windowfunc_basics
>     ----------------------------------------------------------------------
>     Traceback (most recent call last):
>         File "X:\Python33-x32\lib\site-packages\nose\case.py", line 198, in
>     runTest
>           self.test(*self.arg)
>         File
>     "X:\Python33-x32\lib\site-packages\scipy\signal\tests\test_windows.py",
>     line 100, in test_windowfunc_basics
>           assert_array_almost_equal(w1, w2)
>         File "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py",
>     line
>     812, in assert_array_almost_equal
>           header=('Arrays are not almost equal to %d decimals' % decimal))
>         File "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py",
>     line
>     645, in assert_array_compare
>           raise AssertionError(msg)
>     AssertionError:
>     Arrays are not almost equal to 6 decimals
>
>     (mismatch 85.71428571428571%)
>        x: array([ 0.02221406,  1.        ,  0.32944607,  0.16207939,
>       0.18485882,
>               0.36183308,  0.02298899])
>        y: array([ 0.01910267,  1.        ,  0.34644519,  0.09150573,
>       0.09150573,
>               0.17127567,  0.12123497])
>
>     ======================================================================
>     FAIL: test_decomp.TestEig.test_singular
>     ----------------------------------------------------------------------
>     Traceback (most recent call last):
>         File "X:\Python33-x32\lib\site-packages\nose\case.py", line 198, in
>     runTest
>           self.test(*self.arg)
>         File
>     "X:\Python33-x32\lib\site-packages\scipy\linalg\tests\test_decomp.py",
>     line 219, in test_singular
>           self._check_gen_eig(A, B)
>         File
>     "X:\Python33-x32\lib\site-packages\scipy\linalg\tests\test_decomp.py",
>     line 206, in _check_gen_eig
>           err_msg=msg)
>         File "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py",
>     line
>     812, in assert_array_almost_equal
>           header=('Arrays are not almost equal to %d decimals' % decimal))
>         File "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py",
>     line
>     645, in assert_array_compare
>           raise AssertionError(msg)
>     AssertionError:
>     Arrays are not almost equal to 6 decimals
>
>     array([[22, 34, 31, 31, 17],
>              [45, 45, 42, 19, 29],
>              [39, 47, 49, 26, 34],
>              [27, 31, 26, 21, 15],
>              [38, 44, 44, 24, 30]])
>     array([[13, 26, 25, 17, 24],
>              [31, 46, 40, 26, 37],
>              [26, 40, 19, 25, 25],
>              [16, 25, 27, 14, 23],
>              [24, 35, 18, 21, 22]])
>     (mismatch 50.0%)
>        x: array([ -5.90370943e-01+0.j,  -1.54128768e-07+0.j,
>     1.54128748e-07+0.j,
>                2.00000000e+00+0.j])
>        y: array([ -1.32014829e-08+0.j,   1.32014809e-08+0.j,
>     1.33224503e+00+0.j,
>                2.00000000e+00+0.j])
>     ```
>
>     Christoph
>     _______________________________________________
>     SciPy-Dev mailing list
>     SciPy-Dev at scipy.org <mailto:SciPy-Dev at scipy.org>
>     http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From ralf.gommers at gmail.com  Sat Aug 31 06:36:41 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sat, 31 Aug 2013 10:36:41 +0000
Subject: [SciPy-Dev] ANN: Scipy 0.13.0 beta 1 release
In-Reply-To: <20130830142723.GA10981@bromo.med.uc.edu>
References: <CABL7CQga-Qkq8_hG1E+_KfpmVjSE-duyRePVcZw_-s-PXay75w@mail.gmail.com>
	<20130823235831.GA6527@bromo.med.uc.edu>
	<CABL7CQhRQdzjedXid_B0VDc55-AiMnCbaryrPHwTjKSPsBvqyQ@mail.gmail.com>
	<20130830142723.GA10981@bromo.med.uc.edu>
Message-ID: <CABL7CQhn+gc_LxFg_bk5+p7kw99rY-W_iRp8in_jsE+07tRKXw@mail.gmail.com>

On Fri, Aug 30, 2013 at 2:27 PM, Jack Howarth <howarth at bromo.med.uc.edu>wrote:

> On Sat, Aug 24, 2013 at 11:11:36AM +0200, Ralf Gommers wrote:
> > On Sat, Aug 24, 2013 at 1:58 AM, Jack Howarth <howarth at bromo.med.uc.edu
> >wrote:
> >
> > > On Thu, Aug 22, 2013 at 03:12:21PM +0200, Ralf Gommers wrote:
> > > > Hi all,
> > > >
> > > > I'm happy to announce the availability of the first beta release of
> Scipy
> > > > 0.13.0. Please try this beta and report any issues on the scipy-dev
> > > mailing
> > > > list.
> > > >
> > > > Source tarballs and release notes can be found at
> > > > https://sourceforge.net/projects/scipy/files/scipy/0.13.0b1/.
> Windows
> > > and
> > > > OS X installers will follow later (we have a minor infrastructure
> issue
> > > to
> > > > solve, and I'm at EuroScipy now).
> > > >
> > > > Cheers,
> > > > Ralf
> > >
> > > Ralf,
> > >    FYI, if the proposed elimination of support for the Accelerate
> > > framework on
> > > darwin was implemented in scipy 0.13, you will definietely want to
> > > consider reverting that
> > > change. It appears that the issues in the Accelerate framework (at
> least as
> > > tested with scipy 0.12.0) are resolved in the next darwin release...
> > >
> >
> > Hi Jack, the issues appear to have been resolved completely (thanks to
> > Michael Wimmer and Pauli), so we didn't drop support or used OpenBLAS for
> > the binaries.
> >
> > Ralf
>
> Ralf,
>    Unfortunately, I am seeing a linkage failure in 0.13.0 beta1 on
> darwin13 using
> the same build recipe that we use in fink for 0.12.0...
>

Hi Jack, does the same recipe work on OS X 10.8 with 0.13.0b1? And could
you try building 050ac31c6e5? That's before some build changes to split all
the Fortran files, so it will help to figure out if those build changes
introduced the issue.

Thanks,
Ralf

<note to self: darwin13 is the not yet released OS X 10.9>


> ...<snip>.....
> p.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/prini_subr_2.o
> build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/prini_subr_3.o
> build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/prini_subr_4.o
> build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/pri
>  ni_subr_5.o
> build/temp.macosx-10.9-x86_64-2.7/scipy/linalg/src/id_dist/src/prini_subr_6.o
> -L/sw/lib/gcc4.8/lib/gcc/x86_64-apple-darwin13.0.0/4.8.1
> -Lbuild/temp.macosx-10.9-x86_64-2.7 -lgfortran -o
> build/lib.macosx-10.9-x86_64-2.7/scipy/linalg/_interpolative.so
> -Wl,-framework -Wl,Accelerate
> Undefined symbols for architecture x86_64:
>   "_PyArg_ParseTupleAndKeywords", referenced from:
>       _f2py_rout__interpolative_id_srand in _interpolativemodule.o
>       _f2py_rout__interpolative_id_srandi in _interpolativemodule.o
>       _f2py_rout__interpolative_id_srando in _interpolativemodule.o
>       _f2py_rout__interpolative_idd_frm in _interpolativemodule.o
>       _f2py_rout__interpolative_idd_sfrm in _interpolativemodule.o
>       _f2py_rout__interpolative_idd_frmi in _interpolativemodule.o
>       _f2py_rout__interpolative_idd_sfrmi in _interpolativemodule.o
>       ...
>
> etc. This is using...
>
> a site.cfg with...
>
> [amd]
> library_dirs = /sw/lib
> include_dirs = /sw/include/suitesparse
> amd_libs = amd
>
> [umfpack]
> library_dirs = /sw/lib
> include_dirs = /sw/include/suitesparse
> umfpack_libs = umfpack
>
> and
>
>    export CC=clang
>    export CXX=clang++
>    export FFLAGS=-ff2c
>    export FC=/sw/bin/gfortran
>
>    unset LDFLAGS
>    /sw/bin/python2.7 setup.py build --fcompiler gnu95
>
> with a build against suitesparse 4.0.2 and numpy 1.7.1.
>       Jack
>
>
> >
> >
> > > Ran 6134 tests in 88.016s
> > >
> > > OK (KNOWNFAIL=15, SKIP=36)
> > >
> > > compared to darwin12...
> > >
> > > Ran 6134 tests in 96.886s
> > >
> > > FAILED (KNOWNFAIL=15, SKIP=36, failures=63)
> > >
> > > and darwin11...
> > >
> > > Ran 6134 tests in 118.346s
> > >
> > > FAILED (KNOWNFAIL=15, SKIP=36, failures=65)
> > >
> > >              Jack
> > > ps I have looked at the proposed replacement of using openblas and it
> is
> > > rather suboptimal. Please
> > > don't inflict that on us.
> > >
> > > > _______________________________________________
> > > > SciPy-Dev mailing list
> > > > SciPy-Dev at scipy.org
> > > > http://mail.scipy.org/mailman/listinfo/scipy-dev
> > >
> > > _______________________________________________
> > > SciPy-Dev mailing list
> > > SciPy-Dev at scipy.org
> > > http://mail.scipy.org/mailman/listinfo/scipy-dev
> > >
>
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130831/714febf6/attachment.html>

From cournape at gmail.com  Sat Aug 31 06:47:36 2013
From: cournape at gmail.com (David Cournapeau)
Date: Sat, 31 Aug 2013 11:47:36 +0100
Subject: [SciPy-Dev] ANN: Scipy 0.13.0 beta 1 release
In-Reply-To: <5220EAF3.4040600@uci.edu>
References: <CABL7CQga-Qkq8_hG1E+_KfpmVjSE-duyRePVcZw_-s-PXay75w@mail.gmail.com>
	<5216A288.4060108@uci.edu>
	<CAGY4rcWMe2ANSP+nT4S+6hkruw9dhgn6gNgxfGhOYD8tv8h8nQ@mail.gmail.com>
	<5220EAF3.4040600@uci.edu>
Message-ID: <CAGY4rcXboxOD7wcn-3gp8QJVa-JdnzTU6bNd4onCtBLBVqp4eg@mail.gmail.com>

On Fri, Aug 30, 2013 at 7:56 PM, Christoph Gohlke <cgohlke at uci.edu> wrote:

> Yes, I have to restart the build once because of too many (~2000) open
> files. Could be that numpy.distutils.exec_command does not close all
> handles? My build script does `setup.py build` before `setup.py
> bdist_wininst` so I usually don't notice.
>

I did even finer-grained separation between build_clib and build_ext, to no
avail. I have to restart the build 2/3 times.

Regarding exec_command, the code uses old os.system and co, but the code is
so messy that I would not dare touch it at this point.

David

>
> Christoph
>
>
> On 8/30/2013 4:21 AM, David Cournapeau wrote:
> > Christoph, didn't you have any issues with too many files open failures
> > ? I am using windows 7 and not 8, and I always have to restart the build
> > several times to get it finished.
> >
> > David
> >
> >
> > On Fri, Aug 23, 2013 at 12:45 AM, Christoph Gohlke <cgohlke at uci.edu
> > <mailto:cgohlke at uci.edu>> wrote:
> >
> >     On 8/22/2013 6:12 AM, Ralf Gommers wrote:
> >     > Hi all,
> >     >
> >     > I'm happy to announce the availability of the first beta release of
> >     > Scipy 0.13.0. Please try this beta and report any issues on the
> >     > scipy-dev mailing list.
> >     >
> >     > Source tarballs and release notes can be found at
> >     >https://sourceforge.net/projects/scipy/files/scipy/0.13.0b1/.
> Windows
> >     > and OS X installers will follow later (we have a minor
> infrastructure
> >     > issue to solve, and I'm at EuroScipy now).
> >     >
> >     > Cheers,
> >     > Ralf
> >     >
> >     >
> >
> >
> >     Hi Ralf,
> >
> >     I built and tested scipy 0.13.0b1 on Windows 8 with Visual Studio
> 2008 &
> >     2010, Intel Studio XE 2013 Fortran and MKL, Python 2.7 & 3.3 (32 & 64
> >     bit), and numpy 1.7.1.
> >
> >     The `scipy.ndimage._ni_label` extension fails to compile
> >     <https://github.com/scipy/scipy/pull/2770>.
> >
> >     The win-amd64-py2.7 build passes all tests.
> >
> >     On Python 3 there are 12 errors in
> `test_wavfile.test_write_roundtrip`
> >     of the following kind:
> >     ```
> >
> ======================================================================
> >     ERROR: test_wavfile.test_write_roundtrip(False, 8000, dtype('>i8'),
> 1)
> >
> ----------------------------------------------------------------------
> >     Traceback (most recent call last):
> >         File "X:\Python33\lib\site-packages\nose\case.py", line 198, in
> >     runTest
> >           self.test(*self.arg)
> >         File
> "X:\Python33\lib\site-packages\scipy\io\tests\test_wavfile.py",
> >     line 73, in _check_roundtrip
> >           rate2, data2 = wavfile.read(tmpfile, mmap=mmap)
> >         File "X:\Python33\lib\site-packages\scipy\io\wavfile.py", line
> 166,
> >     in read
> >           data = _read_data_chunk(fid, comp, noc, bits, mmap=mmap)
> >         File "X:\Python33\lib\site-packages\scipy\io\wavfile.py", line
> >     71, in
> >     _read_data_chunk
> >           data = numpy.fromstring(fid.read(size), dtype=dtype)
> >     ValueError: cannot expose native-only dtype 'q' in non-native byte
> order
> >     '>' via buffer interface
> >     ```
> >
> >     On 32 bit Python `test_distributions.TestFitMethod.test_fix_fit_beta`
> >     fails with an error:
> >
> >     ```
> >
> ======================================================================
> >     ERROR: test_distributions.TestFitMethod.test_fix_fit_beta
> >
> ----------------------------------------------------------------------
> >     Traceback (most recent call last):
> >         File "X:\Python33-x32\lib\site-packages\nose\case.py", line 198,
> in
> >     runTest
> >           self.test(*self.arg)
> >         File
> >
> "X:\Python33-x32\lib\site-packages\scipy\stats\tests\test_distributions.py",
> >     line 928, in test_fix_fit_beta
> >           assert_raises(ValueError, stats.beta.fit, x, floc=0.5,
> fscale=1)
> >         File "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py",
> >     line
> >     1019, in assert_raises
> >           return nose.tools.assert_raises(*args,**kwargs)
> >         File "X:\Python33-x32\lib\unittest\case.py", line 570, in
> >     assertRaises
> >           return context.handle('assertRaises', callableObj, args,
> kwargs)
> >         File "X:\Python33-x32\lib\unittest\case.py", line 135, in handle
> >           callable_obj(*args, **kwargs)
> >         File
> >     "X:\Python33-x32\lib\site-packages\scipy\stats\distributions.py",
> line
> >     2533, in fit
> >           raise FitSolverError(mesg=mesg)
> >     scipy.stats.distributions.FitSolverError: Solver for the MLE
> equations
> >     failed to converge: The iteration is not making good progress, as
> >     measured by the   improvement from the last ten iterations.
> >     ```
> >
> >
> >     Also on 32 bit Python, `test_windows.test_windowfunc_basics` and
> >     `test_decomp.TestEig.test_singular` sometimes fail:
> >     ```
> >
> ======================================================================
> >     FAIL: test_windows.test_windowfunc_basics
> >
> ----------------------------------------------------------------------
> >     Traceback (most recent call last):
> >         File "X:\Python33-x32\lib\site-packages\nose\case.py", line 198,
> in
> >     runTest
> >           self.test(*self.arg)
> >         File
> >
> "X:\Python33-x32\lib\site-packages\scipy\signal\tests\test_windows.py",
> >     line 100, in test_windowfunc_basics
> >           assert_array_almost_equal(w1, w2)
> >         File "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py",
> >     line
> >     812, in assert_array_almost_equal
> >           header=('Arrays are not almost equal to %d decimals' %
> decimal))
> >         File "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py",
> >     line
> >     645, in assert_array_compare
> >           raise AssertionError(msg)
> >     AssertionError:
> >     Arrays are not almost equal to 6 decimals
> >
> >     (mismatch 85.71428571428571%)
> >        x: array([ 0.02221406,  1.        ,  0.32944607,  0.16207939,
> >       0.18485882,
> >               0.36183308,  0.02298899])
> >        y: array([ 0.01910267,  1.        ,  0.34644519,  0.09150573,
> >       0.09150573,
> >               0.17127567,  0.12123497])
> >
> >
> ======================================================================
> >     FAIL: test_decomp.TestEig.test_singular
> >
> ----------------------------------------------------------------------
> >     Traceback (most recent call last):
> >         File "X:\Python33-x32\lib\site-packages\nose\case.py", line 198,
> in
> >     runTest
> >           self.test(*self.arg)
> >         File
> >
> "X:\Python33-x32\lib\site-packages\scipy\linalg\tests\test_decomp.py",
> >     line 219, in test_singular
> >           self._check_gen_eig(A, B)
> >         File
> >
> "X:\Python33-x32\lib\site-packages\scipy\linalg\tests\test_decomp.py",
> >     line 206, in _check_gen_eig
> >           err_msg=msg)
> >         File "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py",
> >     line
> >     812, in assert_array_almost_equal
> >           header=('Arrays are not almost equal to %d decimals' %
> decimal))
> >         File "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py",
> >     line
> >     645, in assert_array_compare
> >           raise AssertionError(msg)
> >     AssertionError:
> >     Arrays are not almost equal to 6 decimals
> >
> >     array([[22, 34, 31, 31, 17],
> >              [45, 45, 42, 19, 29],
> >              [39, 47, 49, 26, 34],
> >              [27, 31, 26, 21, 15],
> >              [38, 44, 44, 24, 30]])
> >     array([[13, 26, 25, 17, 24],
> >              [31, 46, 40, 26, 37],
> >              [26, 40, 19, 25, 25],
> >              [16, 25, 27, 14, 23],
> >              [24, 35, 18, 21, 22]])
> >     (mismatch 50.0%)
> >        x: array([ -5.90370943e-01+0.j,  -1.54128768e-07+0.j,
> >     1.54128748e-07+0.j,
> >                2.00000000e+00+0.j])
> >        y: array([ -1.32014829e-08+0.j,   1.32014809e-08+0.j,
> >     1.33224503e+00+0.j,
> >                2.00000000e+00+0.j])
> >     ```
> >
> >     Christoph
> >     _______________________________________________
> >     SciPy-Dev mailing list
> >     SciPy-Dev at scipy.org <mailto:SciPy-Dev at scipy.org>
> >     http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> >
> >
> >
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130831/0e0c4860/attachment.html>

From cournape at gmail.com  Sat Aug 31 06:55:37 2013
From: cournape at gmail.com (David Cournapeau)
Date: Sat, 31 Aug 2013 11:55:37 +0100
Subject: [SciPy-Dev] Purpose of commit 359cf0 ?
In-Reply-To: <kvqg17$u7g$1@ger.gmane.org>
References: <CAGY4rcXOXEX52e_7md49SeCEUmEbw6ZSbgbTjoXr2sso=FU3JA@mail.gmail.com>
	<kvqg17$u7g$1@ger.gmane.org>
Message-ID: <CAGY4rcWAZb=NWNuBSZaLj7J87xZQevcbXPYJ1C-y9-MHVBfetQ@mail.gmail.com>

On Fri, Aug 30, 2013 at 5:08 PM, Pauli Virtanen <pav at iki.fi> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> 30.08.2013 13:43, David Cournapeau kirjoitti:
> > I see that this fix broke visual studio build in a non trivial
> > manner (a few cephes functions are declared in VS math.h, with
> > incompatible linkage).
> >
> > I don't understand the fix: which platform did it fix, and why not
> > having isfinite matter since we're using npy_ macro in struve.c ?
>
> The platform it fixed was Centos 5 + epd-7.0-2-rh5-x86_64 (with Numpy
> 1.5.1 and Python 2.7.1).
>
> There is a weird interaction between the header files, which causes
> import to fail with
>
>         ./_ufuncs.so: undefined symbol: isfinite
>
> if <math.h> is included before <Python.h> (which is included from
> amos_wrappers.h). So perhaps the Python setup is just broken there.
>

I can reproduce the error with numpy 1.7.1 on Centos 5, most likely some
centos5-specific python header bugs.

I would suggest reverting your change + include Python.h first: it makes
the bug disappear on Centos 5 at least. I will prepare a PR once I have
tested this on all our supported platforms @ Enthought.

David

> Other ideas how to fix it? (NB: You can ask Ognen for account on
> docs.scipy.org if you want to debug it yourself.)
>
>     ***
>
> This seems to show that no matter how trivial the change is, do it via
> PR rather than just pushing it...
>
>         Pauli
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iEYEARECAAYFAlIgw2oACgkQ6BQxb7O0pWDZPgCggOiJZ4bUaWpAOQetqwyTWaMq
> aGQAniF9zI+ssNErWxb2Vsh6GpiNJ2Cb
> =Bt9Q
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130831/16d1cec5/attachment.html>

From ralf.gommers at gmail.com  Sat Aug 31 07:13:43 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sat, 31 Aug 2013 11:13:43 +0000
Subject: [SciPy-Dev] ANN: Scipy 0.13.0 beta 1 release
In-Reply-To: <CAGY4rcXboxOD7wcn-3gp8QJVa-JdnzTU6bNd4onCtBLBVqp4eg@mail.gmail.com>
References: <CABL7CQga-Qkq8_hG1E+_KfpmVjSE-duyRePVcZw_-s-PXay75w@mail.gmail.com>
	<5216A288.4060108@uci.edu>
	<CAGY4rcWMe2ANSP+nT4S+6hkruw9dhgn6gNgxfGhOYD8tv8h8nQ@mail.gmail.com>
	<5220EAF3.4040600@uci.edu>
	<CAGY4rcXboxOD7wcn-3gp8QJVa-JdnzTU6bNd4onCtBLBVqp4eg@mail.gmail.com>
Message-ID: <CABL7CQgZbOUHPHm55a8DKE=P1Xtd4snJmuKzTNCUFX7ke=drPw@mail.gmail.com>

On Sat, Aug 31, 2013 at 10:47 AM, David Cournapeau <cournape at gmail.com>wrote:

>
>
>
> On Fri, Aug 30, 2013 at 7:56 PM, Christoph Gohlke <cgohlke at uci.edu> wrote:
>
>> Yes, I have to restart the build once because of too many (~2000) open
>> files. Could be that numpy.distutils.exec_command does not close all
>> handles? My build script does `setup.py build` before `setup.py
>> bdist_wininst` so I usually don't notice.
>>
>
> I did even finer-grained separation between build_clib and build_ext, to
> no avail. I have to restart the build 2/3 times.
>
> Regarding exec_command, the code uses old os.system and co, but the code
> is so messy that I would not dare touch it at this point.
>

It looks like even if we'd revert https://github.com/scipy/scipy/pull/2761,
if scipy grows any more we can't build it with distutils. So if this is due
to exec_command, it needs to be fixed. Unless we want to take a leap and go
Bento-only....

Note also that this is not a new issue, here's some build instructions from
2010 with a remark on this:
https://code.google.com/p/iocbio/wiki/BuildWindowsInstallersOnLinux

Ralf



> David
>
>>
>> Christoph
>>
>>
>> On 8/30/2013 4:21 AM, David Cournapeau wrote:
>> > Christoph, didn't you have any issues with too many files open failures
>> > ? I am using windows 7 and not 8, and I always have to restart the build
>> > several times to get it finished.
>> >
>> > David
>> >
>> >
>> > On Fri, Aug 23, 2013 at 12:45 AM, Christoph Gohlke <cgohlke at uci.edu
>> > <mailto:cgohlke at uci.edu>> wrote:
>> >
>> >     On 8/22/2013 6:12 AM, Ralf Gommers wrote:
>> >     > Hi all,
>> >     >
>> >     > I'm happy to announce the availability of the first beta release
>> of
>> >     > Scipy 0.13.0. Please try this beta and report any issues on the
>> >     > scipy-dev mailing list.
>> >     >
>> >     > Source tarballs and release notes can be found at
>> >     >https://sourceforge.net/projects/scipy/files/scipy/0.13.0b1/.
>> Windows
>> >     > and OS X installers will follow later (we have a minor
>> infrastructure
>> >     > issue to solve, and I'm at EuroScipy now).
>> >     >
>> >     > Cheers,
>> >     > Ralf
>> >     >
>> >     >
>> >
>> >
>> >     Hi Ralf,
>> >
>> >     I built and tested scipy 0.13.0b1 on Windows 8 with Visual Studio
>> 2008 &
>> >     2010, Intel Studio XE 2013 Fortran and MKL, Python 2.7 & 3.3 (32 &
>> 64
>> >     bit), and numpy 1.7.1.
>> >
>> >     The `scipy.ndimage._ni_label` extension fails to compile
>> >     <https://github.com/scipy/scipy/pull/2770>.
>> >
>> >     The win-amd64-py2.7 build passes all tests.
>> >
>> >     On Python 3 there are 12 errors in
>> `test_wavfile.test_write_roundtrip`
>> >     of the following kind:
>> >     ```
>> >
>> ======================================================================
>> >     ERROR: test_wavfile.test_write_roundtrip(False, 8000, dtype('>i8'),
>> 1)
>> >
>> ----------------------------------------------------------------------
>> >     Traceback (most recent call last):
>> >         File "X:\Python33\lib\site-packages\nose\case.py", line 198, in
>> >     runTest
>> >           self.test(*self.arg)
>> >         File
>> "X:\Python33\lib\site-packages\scipy\io\tests\test_wavfile.py",
>> >     line 73, in _check_roundtrip
>> >           rate2, data2 = wavfile.read(tmpfile, mmap=mmap)
>> >         File "X:\Python33\lib\site-packages\scipy\io\wavfile.py", line
>> 166,
>> >     in read
>> >           data = _read_data_chunk(fid, comp, noc, bits, mmap=mmap)
>> >         File "X:\Python33\lib\site-packages\scipy\io\wavfile.py", line
>> >     71, in
>> >     _read_data_chunk
>> >           data = numpy.fromstring(fid.read(size), dtype=dtype)
>> >     ValueError: cannot expose native-only dtype 'q' in non-native byte
>> order
>> >     '>' via buffer interface
>> >     ```
>> >
>> >     On 32 bit Python
>> `test_distributions.TestFitMethod.test_fix_fit_beta`
>> >     fails with an error:
>> >
>> >     ```
>> >
>> ======================================================================
>> >     ERROR: test_distributions.TestFitMethod.test_fix_fit_beta
>> >
>> ----------------------------------------------------------------------
>> >     Traceback (most recent call last):
>> >         File "X:\Python33-x32\lib\site-packages\nose\case.py", line
>> 198, in
>> >     runTest
>> >           self.test(*self.arg)
>> >         File
>> >
>> "X:\Python33-x32\lib\site-packages\scipy\stats\tests\test_distributions.py",
>> >     line 928, in test_fix_fit_beta
>> >           assert_raises(ValueError, stats.beta.fit, x, floc=0.5,
>> fscale=1)
>> >         File "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py",
>> >     line
>> >     1019, in assert_raises
>> >           return nose.tools.assert_raises(*args,**kwargs)
>> >         File "X:\Python33-x32\lib\unittest\case.py", line 570, in
>> >     assertRaises
>> >           return context.handle('assertRaises', callableObj, args,
>> kwargs)
>> >         File "X:\Python33-x32\lib\unittest\case.py", line 135, in handle
>> >           callable_obj(*args, **kwargs)
>> >         File
>> >     "X:\Python33-x32\lib\site-packages\scipy\stats\distributions.py",
>> line
>> >     2533, in fit
>> >           raise FitSolverError(mesg=mesg)
>> >     scipy.stats.distributions.FitSolverError: Solver for the MLE
>> equations
>> >     failed to converge: The iteration is not making good progress, as
>> >     measured by the   improvement from the last ten iterations.
>> >     ```
>> >
>> >
>> >     Also on 32 bit Python, `test_windows.test_windowfunc_basics` and
>> >     `test_decomp.TestEig.test_singular` sometimes fail:
>> >     ```
>> >
>> ======================================================================
>> >     FAIL: test_windows.test_windowfunc_basics
>> >
>> ----------------------------------------------------------------------
>> >     Traceback (most recent call last):
>> >         File "X:\Python33-x32\lib\site-packages\nose\case.py", line
>> 198, in
>> >     runTest
>> >           self.test(*self.arg)
>> >         File
>> >
>> "X:\Python33-x32\lib\site-packages\scipy\signal\tests\test_windows.py",
>> >     line 100, in test_windowfunc_basics
>> >           assert_array_almost_equal(w1, w2)
>> >         File "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py",
>> >     line
>> >     812, in assert_array_almost_equal
>> >           header=('Arrays are not almost equal to %d decimals' %
>> decimal))
>> >         File "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py",
>> >     line
>> >     645, in assert_array_compare
>> >           raise AssertionError(msg)
>> >     AssertionError:
>> >     Arrays are not almost equal to 6 decimals
>> >
>> >     (mismatch 85.71428571428571%)
>> >        x: array([ 0.02221406,  1.        ,  0.32944607,  0.16207939,
>> >       0.18485882,
>> >               0.36183308,  0.02298899])
>> >        y: array([ 0.01910267,  1.        ,  0.34644519,  0.09150573,
>> >       0.09150573,
>> >               0.17127567,  0.12123497])
>> >
>> >
>> ======================================================================
>> >     FAIL: test_decomp.TestEig.test_singular
>> >
>> ----------------------------------------------------------------------
>> >     Traceback (most recent call last):
>> >         File "X:\Python33-x32\lib\site-packages\nose\case.py", line
>> 198, in
>> >     runTest
>> >           self.test(*self.arg)
>> >         File
>> >
>> "X:\Python33-x32\lib\site-packages\scipy\linalg\tests\test_decomp.py",
>> >     line 219, in test_singular
>> >           self._check_gen_eig(A, B)
>> >         File
>> >
>> "X:\Python33-x32\lib\site-packages\scipy\linalg\tests\test_decomp.py",
>> >     line 206, in _check_gen_eig
>> >           err_msg=msg)
>> >         File "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py",
>> >     line
>> >     812, in assert_array_almost_equal
>> >           header=('Arrays are not almost equal to %d decimals' %
>> decimal))
>> >         File "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py",
>> >     line
>> >     645, in assert_array_compare
>> >           raise AssertionError(msg)
>> >     AssertionError:
>> >     Arrays are not almost equal to 6 decimals
>> >
>> >     array([[22, 34, 31, 31, 17],
>> >              [45, 45, 42, 19, 29],
>> >              [39, 47, 49, 26, 34],
>> >              [27, 31, 26, 21, 15],
>> >              [38, 44, 44, 24, 30]])
>> >     array([[13, 26, 25, 17, 24],
>> >              [31, 46, 40, 26, 37],
>> >              [26, 40, 19, 25, 25],
>> >              [16, 25, 27, 14, 23],
>> >              [24, 35, 18, 21, 22]])
>> >     (mismatch 50.0%)
>> >        x: array([ -5.90370943e-01+0.j,  -1.54128768e-07+0.j,
>> >     1.54128748e-07+0.j,
>> >                2.00000000e+00+0.j])
>> >        y: array([ -1.32014829e-08+0.j,   1.32014809e-08+0.j,
>> >     1.33224503e+00+0.j,
>> >                2.00000000e+00+0.j])
>> >     ```
>> >
>> >     Christoph
>> >     _______________________________________________
>> >     SciPy-Dev mailing list
>> >     SciPy-Dev at scipy.org <mailto:SciPy-Dev at scipy.org>
>> >     http://mail.scipy.org/mailman/listinfo/scipy-dev
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > SciPy-Dev mailing list
>> > SciPy-Dev at scipy.org
>> > http://mail.scipy.org/mailman/listinfo/scipy-dev
>> >
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130831/2eef8a2a/attachment.html>

From cournape at gmail.com  Sat Aug 31 11:00:19 2013
From: cournape at gmail.com (David Cournapeau)
Date: Sat, 31 Aug 2013 16:00:19 +0100
Subject: [SciPy-Dev] ANN: Scipy 0.13.0 beta 1 release
In-Reply-To: <CABL7CQgZbOUHPHm55a8DKE=P1Xtd4snJmuKzTNCUFX7ke=drPw@mail.gmail.com>
References: <CABL7CQga-Qkq8_hG1E+_KfpmVjSE-duyRePVcZw_-s-PXay75w@mail.gmail.com>
	<5216A288.4060108@uci.edu>
	<CAGY4rcWMe2ANSP+nT4S+6hkruw9dhgn6gNgxfGhOYD8tv8h8nQ@mail.gmail.com>
	<5220EAF3.4040600@uci.edu>
	<CAGY4rcXboxOD7wcn-3gp8QJVa-JdnzTU6bNd4onCtBLBVqp4eg@mail.gmail.com>
	<CABL7CQgZbOUHPHm55a8DKE=P1Xtd4snJmuKzTNCUFX7ke=drPw@mail.gmail.com>
Message-ID: <CAGY4rcWPd8UfN89uDwXKz+NJL4ObSSMSURHT7a1poS2+LsxdLg@mail.gmail.com>

On Sat, Aug 31, 2013 at 12:13 PM, Ralf Gommers <ralf.gommers at gmail.com>wrote:

>
>
>
> On Sat, Aug 31, 2013 at 10:47 AM, David Cournapeau <cournape at gmail.com>wrote:
>
>>
>>
>>
>> On Fri, Aug 30, 2013 at 7:56 PM, Christoph Gohlke <cgohlke at uci.edu>wrote:
>>
>>> Yes, I have to restart the build once because of too many (~2000) open
>>> files. Could be that numpy.distutils.exec_command does not close all
>>> handles? My build script does `setup.py build` before `setup.py
>>> bdist_wininst` so I usually don't notice.
>>>
>>
>> I did even finer-grained separation between build_clib and build_ext, to
>> no avail. I have to restart the build 2/3 times.
>>
>> Regarding exec_command, the code uses old os.system and co, but the code
>> is so messy that I would not dare touch it at this point.
>>
>
> It looks like even if we'd revert https://github.com/scipy/scipy/pull/2761,
> if scipy grows any more we can't build it with distutils.
>

I saw those issues before (for 0.10 even), but not consistantly, so I agree
reverting is not really a fix.

I am not sure it is even due to distutils, TBH. I have noticed those issues
in other (non python) packages, it may be a hard limitation of the DOS
subsystem, in which case we're clearly in trouble :)

I will try to make some experiments next week with dumy project having
thousand of files to reproduce the issue easily.

David

> So if this is due to exec_command, it needs to be fixed. Unless we want to
> take a leap and go Bento-only....
>
> Note also that this is not a new issue, here's some build instructions
> from 2010 with a remark on this:
> https://code.google.com/p/iocbio/wiki/BuildWindowsInstallersOnLinux
>
> Ralf
>
>
>
>> David
>>
>>>
>>> Christoph
>>>
>>>
>>> On 8/30/2013 4:21 AM, David Cournapeau wrote:
>>> > Christoph, didn't you have any issues with too many files open failures
>>> > ? I am using windows 7 and not 8, and I always have to restart the
>>> build
>>> > several times to get it finished.
>>> >
>>> > David
>>> >
>>> >
>>> > On Fri, Aug 23, 2013 at 12:45 AM, Christoph Gohlke <cgohlke at uci.edu
>>> > <mailto:cgohlke at uci.edu>> wrote:
>>> >
>>> >     On 8/22/2013 6:12 AM, Ralf Gommers wrote:
>>> >     > Hi all,
>>> >     >
>>> >     > I'm happy to announce the availability of the first beta release
>>> of
>>> >     > Scipy 0.13.0. Please try this beta and report any issues on the
>>> >     > scipy-dev mailing list.
>>> >     >
>>> >     > Source tarballs and release notes can be found at
>>> >     >https://sourceforge.net/projects/scipy/files/scipy/0.13.0b1/.
>>> Windows
>>> >     > and OS X installers will follow later (we have a minor
>>> infrastructure
>>> >     > issue to solve, and I'm at EuroScipy now).
>>> >     >
>>> >     > Cheers,
>>> >     > Ralf
>>> >     >
>>> >     >
>>> >
>>> >
>>> >     Hi Ralf,
>>> >
>>> >     I built and tested scipy 0.13.0b1 on Windows 8 with Visual Studio
>>> 2008 &
>>> >     2010, Intel Studio XE 2013 Fortran and MKL, Python 2.7 & 3.3 (32 &
>>> 64
>>> >     bit), and numpy 1.7.1.
>>> >
>>> >     The `scipy.ndimage._ni_label` extension fails to compile
>>> >     <https://github.com/scipy/scipy/pull/2770>.
>>> >
>>> >     The win-amd64-py2.7 build passes all tests.
>>> >
>>> >     On Python 3 there are 12 errors in
>>> `test_wavfile.test_write_roundtrip`
>>> >     of the following kind:
>>> >     ```
>>> >
>>> ======================================================================
>>> >     ERROR: test_wavfile.test_write_roundtrip(False, 8000,
>>> dtype('>i8'), 1)
>>> >
>>> ----------------------------------------------------------------------
>>> >     Traceback (most recent call last):
>>> >         File "X:\Python33\lib\site-packages\nose\case.py", line 198, in
>>> >     runTest
>>> >           self.test(*self.arg)
>>> >         File
>>> "X:\Python33\lib\site-packages\scipy\io\tests\test_wavfile.py",
>>> >     line 73, in _check_roundtrip
>>> >           rate2, data2 = wavfile.read(tmpfile, mmap=mmap)
>>> >         File "X:\Python33\lib\site-packages\scipy\io\wavfile.py", line
>>> 166,
>>> >     in read
>>> >           data = _read_data_chunk(fid, comp, noc, bits, mmap=mmap)
>>> >         File "X:\Python33\lib\site-packages\scipy\io\wavfile.py", line
>>> >     71, in
>>> >     _read_data_chunk
>>> >           data = numpy.fromstring(fid.read(size), dtype=dtype)
>>> >     ValueError: cannot expose native-only dtype 'q' in non-native byte
>>> order
>>> >     '>' via buffer interface
>>> >     ```
>>> >
>>> >     On 32 bit Python
>>> `test_distributions.TestFitMethod.test_fix_fit_beta`
>>> >     fails with an error:
>>> >
>>> >     ```
>>> >
>>> ======================================================================
>>> >     ERROR: test_distributions.TestFitMethod.test_fix_fit_beta
>>> >
>>> ----------------------------------------------------------------------
>>> >     Traceback (most recent call last):
>>> >         File "X:\Python33-x32\lib\site-packages\nose\case.py", line
>>> 198, in
>>> >     runTest
>>> >           self.test(*self.arg)
>>> >         File
>>> >
>>> "X:\Python33-x32\lib\site-packages\scipy\stats\tests\test_distributions.py",
>>> >     line 928, in test_fix_fit_beta
>>> >           assert_raises(ValueError, stats.beta.fit, x, floc=0.5,
>>> fscale=1)
>>> >         File
>>> "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py",
>>> >     line
>>> >     1019, in assert_raises
>>> >           return nose.tools.assert_raises(*args,**kwargs)
>>> >         File "X:\Python33-x32\lib\unittest\case.py", line 570, in
>>> >     assertRaises
>>> >           return context.handle('assertRaises', callableObj, args,
>>> kwargs)
>>> >         File "X:\Python33-x32\lib\unittest\case.py", line 135, in
>>> handle
>>> >           callable_obj(*args, **kwargs)
>>> >         File
>>> >     "X:\Python33-x32\lib\site-packages\scipy\stats\distributions.py",
>>> line
>>> >     2533, in fit
>>> >           raise FitSolverError(mesg=mesg)
>>> >     scipy.stats.distributions.FitSolverError: Solver for the MLE
>>> equations
>>> >     failed to converge: The iteration is not making good progress, as
>>> >     measured by the   improvement from the last ten iterations.
>>> >     ```
>>> >
>>> >
>>> >     Also on 32 bit Python, `test_windows.test_windowfunc_basics` and
>>> >     `test_decomp.TestEig.test_singular` sometimes fail:
>>> >     ```
>>> >
>>> ======================================================================
>>> >     FAIL: test_windows.test_windowfunc_basics
>>> >
>>> ----------------------------------------------------------------------
>>> >     Traceback (most recent call last):
>>> >         File "X:\Python33-x32\lib\site-packages\nose\case.py", line
>>> 198, in
>>> >     runTest
>>> >           self.test(*self.arg)
>>> >         File
>>> >
>>> "X:\Python33-x32\lib\site-packages\scipy\signal\tests\test_windows.py",
>>> >     line 100, in test_windowfunc_basics
>>> >           assert_array_almost_equal(w1, w2)
>>> >         File
>>> "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py",
>>> >     line
>>> >     812, in assert_array_almost_equal
>>> >           header=('Arrays are not almost equal to %d decimals' %
>>> decimal))
>>> >         File
>>> "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py",
>>> >     line
>>> >     645, in assert_array_compare
>>> >           raise AssertionError(msg)
>>> >     AssertionError:
>>> >     Arrays are not almost equal to 6 decimals
>>> >
>>> >     (mismatch 85.71428571428571%)
>>> >        x: array([ 0.02221406,  1.        ,  0.32944607,  0.16207939,
>>> >       0.18485882,
>>> >               0.36183308,  0.02298899])
>>> >        y: array([ 0.01910267,  1.        ,  0.34644519,  0.09150573,
>>> >       0.09150573,
>>> >               0.17127567,  0.12123497])
>>> >
>>> >
>>> ======================================================================
>>> >     FAIL: test_decomp.TestEig.test_singular
>>> >
>>> ----------------------------------------------------------------------
>>> >     Traceback (most recent call last):
>>> >         File "X:\Python33-x32\lib\site-packages\nose\case.py", line
>>> 198, in
>>> >     runTest
>>> >           self.test(*self.arg)
>>> >         File
>>> >
>>> "X:\Python33-x32\lib\site-packages\scipy\linalg\tests\test_decomp.py",
>>> >     line 219, in test_singular
>>> >           self._check_gen_eig(A, B)
>>> >         File
>>> >
>>> "X:\Python33-x32\lib\site-packages\scipy\linalg\tests\test_decomp.py",
>>> >     line 206, in _check_gen_eig
>>> >           err_msg=msg)
>>> >         File
>>> "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py",
>>> >     line
>>> >     812, in assert_array_almost_equal
>>> >           header=('Arrays are not almost equal to %d decimals' %
>>> decimal))
>>> >         File
>>> "X:\Python33-x32\lib\site-packages\numpy\testing\utils.py",
>>> >     line
>>> >     645, in assert_array_compare
>>> >           raise AssertionError(msg)
>>> >     AssertionError:
>>> >     Arrays are not almost equal to 6 decimals
>>> >
>>> >     array([[22, 34, 31, 31, 17],
>>> >              [45, 45, 42, 19, 29],
>>> >              [39, 47, 49, 26, 34],
>>> >              [27, 31, 26, 21, 15],
>>> >              [38, 44, 44, 24, 30]])
>>> >     array([[13, 26, 25, 17, 24],
>>> >              [31, 46, 40, 26, 37],
>>> >              [26, 40, 19, 25, 25],
>>> >              [16, 25, 27, 14, 23],
>>> >              [24, 35, 18, 21, 22]])
>>> >     (mismatch 50.0%)
>>> >        x: array([ -5.90370943e-01+0.j,  -1.54128768e-07+0.j,
>>> >     1.54128748e-07+0.j,
>>> >                2.00000000e+00+0.j])
>>> >        y: array([ -1.32014829e-08+0.j,   1.32014809e-08+0.j,
>>> >     1.33224503e+00+0.j,
>>> >                2.00000000e+00+0.j])
>>> >     ```
>>> >
>>> >     Christoph
>>> >     _______________________________________________
>>> >     SciPy-Dev mailing list
>>> >     SciPy-Dev at scipy.org <mailto:SciPy-Dev at scipy.org>
>>> >     http://mail.scipy.org/mailman/listinfo/scipy-dev
>>> >
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > SciPy-Dev mailing list
>>> > SciPy-Dev at scipy.org
>>> > http://mail.scipy.org/mailman/listinfo/scipy-dev
>>> >
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>>
>>
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20130831/9089ec6f/attachment.html>