From johnnychan0302 at gmail.com  Thu May  7 10:24:30 2015
From: johnnychan0302 at gmail.com (Johnny Chan)
Date: Thu, 7 May 2015 15:24:30 +0100
Subject: [SciPy-Dev] (no subject)
Message-ID: <CAF+syrDySYEHhogBE2oyDm4P2sCiZOr-h=X4w8Ttfx875u5_Vg@mail.gmail.com>

Hello SciPy-Dev community,

Regarding the Tentative NumPy Tutorial (Array Creation)
<http://wiki.scipy.org/Tentative_NumPy_Tutorial#head-d3f8e5fe9b903f3c3b2a5c0dfceb60d71602cf93>,
I have noticed that there might have been a potential typo in one of the
code snippet. i.e.

I believe...

```
np.ones( (2,3,4), dtype = int16)
```

should be corrected to:

```
np.ones( (2,3,4), dtype = "int16")
```

(Note the double quotes around the int16.

Here is my console log to illustrate this:

```
np.ones( (2,3,4), dtype = int16)
---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)
<ipython-input-10-6606a1d2e14b> in <module>()
----> 1 np.ones( (2,3,4), dtype = int16)

NameError: name 'int16' is not defined

np.ones( (2,3,4), dtype = "int16")
Out[11]:
array([[[1, 1, 1, 1],
        [1, 1, 1, 1],
        [1, 1, 1, 1]],

       [[1, 1, 1, 1],
        [1, 1, 1, 1],
        [1, 1, 1, 1]]], dtype=int16)
```

If this makes sense please could we correct the tutorial documentation?

Thanks!
Johnny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150507/c45f4f39/attachment.html>

From sturla.molden at gmail.com  Thu May  7 13:33:10 2015
From: sturla.molden at gmail.com (Sturla Molden)
Date: Thu, 7 May 2015 17:33:10 +0000 (UTC)
Subject: [SciPy-Dev] (no subject)
References: <CAF+syrDySYEHhogBE2oyDm4P2sCiZOr-h=X4w8Ttfx875u5_Vg@mail.gmail.com>
Message-ID: <36483400452712670.489158sturla.molden-gmail.com@news.gmane.org>

Johnny Chan <johnnychan0302 at gmail.com> wrote:

> I believe...
> 
> ```
> np.ones( (2,3,4), dtype = int16)
> ```
> 
> should be corrected to:
> 
> ```
> np.ones( (2,3,4), dtype = "int16")

> If this makes sense please could we correct the tutorial documentation?

It should be

np.ones( (2,3,4), dtype = np.int16)


Sturla



From johnnychan0302 at gmail.com  Thu May  7 13:47:39 2015
From: johnnychan0302 at gmail.com (Johnny Chan)
Date: Thu, 7 May 2015 18:47:39 +0100
Subject: [SciPy-Dev] dtype int16
In-Reply-To: <CAF+syrC4WfnkffFmH-=ujgpWNAfHK=7VsQYt12RVdc8EAZE_2A@mail.gmail.com>
References: <CAE5GFcJ6oNbfBizMx8zdk9ugyPoGcksYnD+Uv7mrfKRX1L2sGQ@mail.gmail.com>
	<CAF+syrC4WfnkffFmH-=ujgpWNAfHK=7VsQYt12RVdc8EAZE_2A@mail.gmail.com>
Message-ID: <CAF+syrCVhLDcqN8h0X9nwz-gjmj87QQruTPQ55erRQiq4BZvkg@mail.gmail.com>

Thank you Alex and Sturla for replying. Mini-summary: the tutorial is
technically correct (no correction is required).

It turns out that there are multiple ways to do this - below list the 3
ways of doing it. (I got the error message the first time due to a syntax
error on my part - apologies).

Thank you all. I believe it is ok to close off this topic now :)

Johnny.
p.s. see below email trial for the 3 methods of performing the same
operation.

On Thu, May 7, 2015 at 3:54 PM, Johnny Chan <johnnychan0302 at gmail.com>
wrote:

> Thank you Alex! You are so right!
>
> I have just tried all 3 methods and everything works and makes sense to me
> now. Thank you so much!
>
>
> from numpy import *
>
> ones( (2,3,4), dtype=int16 )
> Out[2]:
> array([[[1, 1, 1, 1],
>         [1, 1, 1, 1],
>         [1, 1, 1, 1]],
>
>        [[1, 1, 1, 1],
>         [1, 1, 1, 1],
>         [1, 1, 1, 1]]], dtype=int16)
>
> Restarting kernel...
>
>
> import numpy as np
>
> np.ones( (2,3,4), dtype=np.int16 )
> Out[2]:
> array([[[1, 1, 1, 1],
>         [1, 1, 1, 1],
>         [1, 1, 1, 1]],
>
>        [[1, 1, 1, 1],
>         [1, 1, 1, 1],
>         [1, 1, 1, 1]]], dtype=int16)
>
> np.ones( (2,3,4), dtype="int16" )
> Out[3]:
> array([[[1, 1, 1, 1],
>         [1, 1, 1, 1],
>         [1, 1, 1, 1]],
>
>        [[1, 1, 1, 1],
>         [1, 1, 1, 1],
>         [1, 1, 1, 1]]], dtype=int16)
>
>
> Best regards,
> Johnny
>
>
> On Thu, May 7, 2015 at 3:47 PM, Alexander Griffing <argriffi at ncsu.edu>
> wrote:
>
>> The tutorial is not technically wrong, because it has
>> from numpy import *
>>
>> This lets you write
>> ones( (2,3,4), dtype=int16 )
>> as in the tutorial, instead of requiring
>> np.ones( (2,3,4), dtype=np.int16 )
>> or alternatively
>> np.ones( (2,3,4), dtype="int16" )
>>
>> It's confusing that there are so many ways to write this.  It doesn't
>> follow the principle of https://wiki.python.org/moin/TOOWTDI.
>>
>> Cheers,
>> Alex
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150507/1b04cc2f/attachment.html>

From charlesr.harris at gmail.com  Thu May  7 22:39:20 2015
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Thu, 7 May 2015 20:39:20 -0600
Subject: [SciPy-Dev] Compiler errors and segfaults with current scipy.
Message-ID: <CAB6mnxJOi64srZeNQqfWYzbQQ7qicMAYonj2PZxh920HQqGV9Q@mail.gmail.com>

I'm seeing things like

scipy/sparse/sparsetools/csr.cxx: In function ???void
csr_eliminate_zeros(I, I, I*, I*, T*) [with I = long int; T = long long
int]???:
scipy/sparse/sparsetools/csr.cxx:9:1: internal compiler error: Segmentation
fault

This is Redhat g++ 1.9.2. Anyone else seeing problems like this?

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

From ralf.gommers at gmail.com  Fri May  8 02:42:21 2015
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Fri, 8 May 2015 08:42:21 +0200
Subject: [SciPy-Dev] Compiler errors and segfaults with current scipy.
In-Reply-To: <CAB6mnxJOi64srZeNQqfWYzbQQ7qicMAYonj2PZxh920HQqGV9Q@mail.gmail.com>
References: <CAB6mnxJOi64srZeNQqfWYzbQQ7qicMAYonj2PZxh920HQqGV9Q@mail.gmail.com>
Message-ID: <CABL7CQjJUzYauh=Ku5VSh-U9Fnyq0jQX0cEWU7H9nB9KLmL5Ww@mail.gmail.com>

On Fri, May 8, 2015 at 4:39 AM, Charles R Harris <charlesr.harris at gmail.com>
wrote:

> I'm seeing things like
>
> scipy/sparse/sparsetools/csr.cxx: In function ???void
> csr_eliminate_zeros(I, I, I*, I*, T*) [with I = long int; T = long long
> int]???:
> scipy/sparse/sparsetools/csr.cxx:9:1: internal compiler error:
> Segmentation fault
>
> This is Redhat g++ 1.9.2. Anyone else seeing problems like this?
>

4.9.2 not 1.9.2 I assume?

Didn't see this one before and can't find similar reports anywhere.

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

From ralf.gommers at gmail.com  Sat May  9 11:00:55 2015
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sat, 9 May 2015 17:00:55 +0200
Subject: [SciPy-Dev] 0.16.0 release
In-Reply-To: <CABL7CQizf4e7xo04dQdvng+12ocDR+c7LGHEe9KvJ5CmFrCKyA@mail.gmail.com>
References: <CABL7CQh4E4ESabrJt6J91nAYwd9QN++p5kn3dq1xv+2bxK-gVA@mail.gmail.com>
	<CAJJ-iFmMWz_Oy+e+2rxxruaafd6c1D-q5JaB=g=dFW_p4SD4=A@mail.gmail.com>
	<CABL7CQizf4e7xo04dQdvng+12ocDR+c7LGHEe9KvJ5CmFrCKyA@mail.gmail.com>
Message-ID: <CABL7CQjL3qr9Yp4803eFE8tWMWx1Rg7pJc9yEDULK6K44tWhmg@mail.gmail.com>

On Sun, Apr 5, 2015 at 9:40 PM, Ralf Gommers <ralf.gommers at gmail.com> wrote:

>
> The release manager is the person that has the final responsibility for
> what does and does not go into a release, what are considered blocking
> issues, etc. This part really has to be done by a core developer. However,
> there's a lot of other things that the release manager also usually takes
> care of which could equally well be done by one or more contributors who
> are not core developers. Here's a list:
> - build/test Windows and OS X binaries (.exe, .dmg, .whl)
> - automate those binary builds/tests further
> - tackle some of the issues that need to be resolved before the alpha /
> beta / final release
>

One thing that I could use a hand with is cleaning up the noise in the test
suite. Basically, just run latest master and investigate the warnings and
other printed output. In most cases what's needed is just silencing the
warning. On Python 3.x there are also some ResourceWarnings that need
fixing, probably by opening test files like ``with open('this_test_file',
'rb') as f:`` so they get closed automatically.

The only output that doesn't need investigating (because it's not fixable)
looks like:

    0-th dimension must be fixed to 3 but got 15

Any takers?

Cheers,
Ralf



> - PRs to complete the release notes and contributor name mapping
> - a PR to the scipy.org repo to put the release in the News section
> - improve documentation of the release process itself (the less you know
> to start with, the better you can document it)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150509/fb3fae2e/attachment.html>

From larson.eric.d at gmail.com  Sat May  9 11:11:13 2015
From: larson.eric.d at gmail.com (Eric Larson)
Date: Sat, 9 May 2015 08:11:13 -0700
Subject: [SciPy-Dev] 0.16.0 release
In-Reply-To: <CABL7CQjL3qr9Yp4803eFE8tWMWx1Rg7pJc9yEDULK6K44tWhmg@mail.gmail.com>
References: <CABL7CQh4E4ESabrJt6J91nAYwd9QN++p5kn3dq1xv+2bxK-gVA@mail.gmail.com>
	<CAJJ-iFmMWz_Oy+e+2rxxruaafd6c1D-q5JaB=g=dFW_p4SD4=A@mail.gmail.com>
	<CABL7CQizf4e7xo04dQdvng+12ocDR+c7LGHEe9KvJ5CmFrCKyA@mail.gmail.com>
	<CABL7CQjL3qr9Yp4803eFE8tWMWx1Rg7pJc9yEDULK6K44tWhmg@mail.gmail.com>
Message-ID: <CAGu2niVd56GW9Ob0EExha7oMetMUUz-9fCwxDBVMf=0Kzf=_9g@mail.gmail.com>

I can do it Monday or Tuesday if that works.

Eric
 On May 9, 2015 8:01 AM, "Ralf Gommers" <ralf.gommers at gmail.com> wrote:

>
>
> On Sun, Apr 5, 2015 at 9:40 PM, Ralf Gommers <ralf.gommers at gmail.com>
> wrote:
>
>>
>> The release manager is the person that has the final responsibility for
>> what does and does not go into a release, what are considered blocking
>> issues, etc. This part really has to be done by a core developer. However,
>> there's a lot of other things that the release manager also usually takes
>> care of which could equally well be done by one or more contributors who
>> are not core developers. Here's a list:
>> - build/test Windows and OS X binaries (.exe, .dmg, .whl)
>> - automate those binary builds/tests further
>> - tackle some of the issues that need to be resolved before the alpha /
>> beta / final release
>>
>
> One thing that I could use a hand with is cleaning up the noise in the
> test suite. Basically, just run latest master and investigate the warnings
> and other printed output. In most cases what's needed is just silencing the
> warning. On Python 3.x there are also some ResourceWarnings that need
> fixing, probably by opening test files like ``with open('this_test_file',
> 'rb') as f:`` so they get closed automatically.
>
> The only output that doesn't need investigating (because it's not fixable)
> looks like:
>
>     0-th dimension must be fixed to 3 but got 15
>
> Any takers?
>
> Cheers,
> Ralf
>
>
>
>> - PRs to complete the release notes and contributor name mapping
>> - a PR to the scipy.org repo to put the release in the News section
>> - improve documentation of the release process itself (the less you know
>> to start with, the better you can document it)
>>
>
> _______________________________________________
> 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/20150509/28280c7a/attachment.html>

From ralf.gommers at gmail.com  Sat May  9 11:17:36 2015
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sat, 9 May 2015 17:17:36 +0200
Subject: [SciPy-Dev] 0.16.0 release
In-Reply-To: <CAGu2niVd56GW9Ob0EExha7oMetMUUz-9fCwxDBVMf=0Kzf=_9g@mail.gmail.com>
References: <CABL7CQh4E4ESabrJt6J91nAYwd9QN++p5kn3dq1xv+2bxK-gVA@mail.gmail.com>
	<CAJJ-iFmMWz_Oy+e+2rxxruaafd6c1D-q5JaB=g=dFW_p4SD4=A@mail.gmail.com>
	<CABL7CQizf4e7xo04dQdvng+12ocDR+c7LGHEe9KvJ5CmFrCKyA@mail.gmail.com>
	<CABL7CQjL3qr9Yp4803eFE8tWMWx1Rg7pJc9yEDULK6K44tWhmg@mail.gmail.com>
	<CAGu2niVd56GW9Ob0EExha7oMetMUUz-9fCwxDBVMf=0Kzf=_9g@mail.gmail.com>
Message-ID: <CABL7CQjvy+p7m3vNYMBs8w+vwYA_M1y2iEPVAuMmkBwMA7sPHw@mail.gmail.com>

On Sat, May 9, 2015 at 5:11 PM, Eric Larson <larson.eric.d at gmail.com> wrote:

> I can do it Monday or Tuesday if that works.
>

That works, thanks Eric.

Ralf


> Eric
>  On May 9, 2015 8:01 AM, "Ralf Gommers" <ralf.gommers at gmail.com> wrote:
>
>>
>>
>> On Sun, Apr 5, 2015 at 9:40 PM, Ralf Gommers <ralf.gommers at gmail.com>
>> wrote:
>>
>>>
>>> The release manager is the person that has the final responsibility for
>>> what does and does not go into a release, what are considered blocking
>>> issues, etc. This part really has to be done by a core developer. However,
>>> there's a lot of other things that the release manager also usually takes
>>> care of which could equally well be done by one or more contributors who
>>> are not core developers. Here's a list:
>>> - build/test Windows and OS X binaries (.exe, .dmg, .whl)
>>> - automate those binary builds/tests further
>>> - tackle some of the issues that need to be resolved before the alpha /
>>> beta / final release
>>>
>>
>> One thing that I could use a hand with is cleaning up the noise in the
>> test suite. Basically, just run latest master and investigate the warnings
>> and other printed output. In most cases what's needed is just silencing the
>> warning. On Python 3.x there are also some ResourceWarnings that need
>> fixing, probably by opening test files like ``with open('this_test_file',
>> 'rb') as f:`` so they get closed automatically.
>>
>> The only output that doesn't need investigating (because it's not
>> fixable) looks like:
>>
>>     0-th dimension must be fixed to 3 but got 15
>>
>> Any takers?
>>
>> Cheers,
>> Ralf
>>
>>
>>
>>> - PRs to complete the release notes and contributor name mapping
>>> - a PR to the scipy.org repo to put the release in the News section
>>> - improve documentation of the release process itself (the less you know
>>> to start with, the better you can document it)
>>>
>>
>> _______________________________________________
>> 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/20150509/48acd737/attachment.html>

From ralf.gommers at gmail.com  Sun May 10 12:02:23 2015
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sun, 10 May 2015 18:02:23 +0200
Subject: [SciPy-Dev] 0.16.0 release
In-Reply-To: <CABL7CQi_ufgMLrFA-U4T8Mpr9TY+z99pKKCiHqFZC2pBrMCw=w@mail.gmail.com>
References: <CABL7CQh4E4ESabrJt6J91nAYwd9QN++p5kn3dq1xv+2bxK-gVA@mail.gmail.com>
	<CAJJ-iFmMWz_Oy+e+2rxxruaafd6c1D-q5JaB=g=dFW_p4SD4=A@mail.gmail.com>
	<CABL7CQizf4e7xo04dQdvng+12ocDR+c7LGHEe9KvJ5CmFrCKyA@mail.gmail.com>
	<CABL7CQi_ufgMLrFA-U4T8Mpr9TY+z99pKKCiHqFZC2pBrMCw=w@mail.gmail.com>
Message-ID: <CABL7CQhmGq+7TJ9Npd0VyELf_h=ECbSRVaT7-kUYvAd5kcGm5Q@mail.gmail.com>

On Sun, Apr 26, 2015 at 4:22 PM, Ralf Gommers <ralf.gommers at gmail.com>
wrote:

>
>
> On Sun, Apr 5, 2015 at 9:40 PM, Ralf Gommers <ralf.gommers at gmail.com>
> wrote:
>
>> Hi Abraham, Andreas,
>>
>> Thanks for your interest to both of you!
>>
>> The release manager is the person that is responsible for a number of
>> actions to get from "now we start planning for the next release" to "this
>> release is done". This description should give a reasonable overview (some
>> details may be a bit outdated):
>> https://github.com/numpy/numpy/blob/master/doc/HOWTO_RELEASE.rst.txt
>>
>> The release manager is the person that has the final responsibility for
>> what does and does not go into a release, what are considered blocking
>> issues, etc. This part really has to be done by a core developer. However,
>> there's a lot of other things that the release manager also usually takes
>> care of which could equally well be done by one or more contributors who
>> are not core developers. Here's a list:
>> - build/test Windows and OS X binaries (.exe, .dmg, .whl)
>> - automate those binary builds/tests further
>> - tackle some of the issues that need to be resolved before the alpha /
>> beta / final release
>> - PRs to complete the release notes and contributor name mapping
>> - a PR to the scipy.org repo to put the release in the News section
>> - improve documentation of the release process itself (the less you know
>> to start with, the better you can document it)
>>
>> Things that the release manager should do himself:
>> - propose the release schedule (dates for alpha/beta/rc/final)
>> - create the maintenance/0.16.x branch
>> - tag the (pre-)releases
>> - send the release announcement emails
>> - upload binaries to PyPi and SourceForge
>> - propose/make decisions on blockers and content
>>
>> And what's always a team effort: merge as many PRs as possible before the
>> release split.
>>
>> I hope this gives a clear picture. A "release team" that jointly tackles
>> the above tasks would be great. Still would like to see a core dev
>> volunteer though:)
>>
>
> Okay, I'll volunteer to be the release manager for this release. Here's a
> proposal for the release schedule:
>
> - branching 0.16.x: 10 May
> - beta 1: 12 May
>

Looks like we're in good shape for branching and the first beta release. I
plan to create 0.16.x around 9pm GMT (so in about 5 hours). Anything you
want to merge should be in by then.

There's still one issue to sort out with the existing Windows BLAS/LAPACK
binaries in numpy-vendor missing some functions, but that shouldn't hold up
beta1 (it's probably fixable within two days, but worst-case it'll be a
source-only beta).

Cheers,
Ralf



> - release candidate 1: 24 May
> - release candidate 2: 31 May (if needed)
> - final release: 7 June
>
> There aren't many serious issues at the moment, the only nontrivial one is
> the QR updating issue. Here's what's marked to go in still:
> https://github.com/scipy/scipy/milestones/0.16.0. The above schedule
> gives us two weeks to merge PRs. Of the larger ones, I'd still like to see
> these go in:
> - 4682: signal.csd/coherence/welch
> - 4374: cKDTree rewrite
>
> If you see an issue that you consider a blocker or a PR that really should
> go in, please label it with the 0.16.0 milestone or mention it here.
>
> Cheers,
> Ralf
>
>
>
>
>>
>> Cheers,
>> Ralf
>>
>> P.S. I shouldn't forget to mention that for a long time Matthew Brett has
>> been building the OS X wheels and done extensive Scipy Stack testing. And
>> that for an even longer time Christoph Gohlke has been testing pre-releases
>> with MSVC on Windows and resolving issues that are invariable found on that
>> platform. I definitely consider them part of the "release team" (not that
>> we have ever used that name before).
>>
>>
>>
>>
>> On Sat, Apr 4, 2015 at 9:30 PM, Abraham Escalante <aeklant at gmail.com>
>> wrote:
>>
>>> Hi Ralf,
>>>
>>> This sounds interesting to me and I would like to contribute but I fear
>>> I may be still too new to the community to be of much help but maybe I
>>> could provide some assistance to learn.
>>>
>>> Is this a task for admins only? Is there a way I can contribute?
>>>
>>> Cheers,
>>> Abraham.
>>>
>>> 2015-04-04 2:54 GMT-06:00 Ralf Gommers <ralf.gommers at gmail.com>:
>>>
>>>> Hi all,
>>>>
>>>> It's about time to start preparing for the 0.16.0 release. Unusually,
>>>> there are zero blocking issues it looks like. A lot of PRs to merge of
>>>> course, but nothing very large that still needs a lot of work.
>>>>
>>>> Most important question: does anyone want to take the release manager
>>>> role for this release? It would be good to start rotating this role for
>>>> every minor release. This will help spread the knowledge on how to do
>>>> releases and also spread the workload (it's not that much for a single
>>>> release, but it adds up).
>>>>
>>>> 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/20150510/b9227fe5/attachment.html>

From ralf.gommers at gmail.com  Sun May 10 16:07:08 2015
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sun, 10 May 2015 22:07:08 +0200
Subject: [SciPy-Dev] question of scope wavelet code
Message-ID: <CABL7CQj0hqJif1pprqSzneu9EWjSKm=k_0OgHXCnfu1XiEvpag@mail.gmail.com>

Hi all,

As you may know, I forked PyWavelets a while ago and with the help of quite
a few people started bringing it up to the standards needed for inclusion
in scipy: https://github.com/rgommers/pywt. The last year I haven't had too
much time for it, but I'd like to get back to it. That's also triggered by
several PRs and proposed enhancements - there's quite a bit of interest for
a fork that never actually had a release. This proposal
https://github.com/rgommers/pywt/issues/58) to add contourlets triggered me
to bring up what the scope of a (discrete) wavelets module in scipy should
be.

What's there now is still mostly what's listed in
http://pywavelets.readthedocs.org/en/latest/. A few additions are/were
no-brainers, like n-D inverse DWT and inverse SWT (stationary wavelet
transform). But beyond that I realize that a bit of care is needed, because
there's a huge array of variations on wavelets. Here's a quick list of what
I'm aware of, ordered from most to least important in my perspective:

- curvelets (https://en.wikipedia.org/wiki/Curvelet)
- contourlets (http://en.wikipedia.org/wiki/Contourlet)
- shearlets (http://en.wikipedia.org/wiki/Shearlet http://shearlab.org GPL)
- chirplets (http://en.wikipedia.org/wiki/Chirplet_transform
http://tfd.sourceforge.net/ GPL)
- ridgelets (
http://rsta.royalsocietypublishing.org/content/357/1760/2495.short)
- wedgelets (http://projecteuclid.org/euclid.aos/1018031261)
- noiselets (http://en.wikipedia.org/wiki/Noiselet)
- surfacelets (http://dx.doi.org/10.1109/TIP.2007.891785)
- bandelets (http://en.wikipedia.org/wiki/Bandelet)

At least the first four items in this list seem to be quite widely used.
I'd like some opinions on which (if any) of these people think would fit in
scipy, and which ones should rather be kept in a wavelets-specific package.

Also, if anyone has experience using the contourlet toolbox under
discussion in issue 58, would be great to hear how it performed.

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

From gael.varoquaux at normalesup.org  Sun May 10 16:10:29 2015
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sun, 10 May 2015 22:10:29 +0200
Subject: [SciPy-Dev] question of scope wavelet code
In-Reply-To: <CABL7CQj0hqJif1pprqSzneu9EWjSKm=k_0OgHXCnfu1XiEvpag@mail.gmail.com>
References: <CABL7CQj0hqJif1pprqSzneu9EWjSKm=k_0OgHXCnfu1XiEvpag@mail.gmail.com>
Message-ID: <20150510201029.GC959311@phare.normalesup.org>

On Sun, May 10, 2015 at 10:07:08PM +0200, Ralf Gommers wrote:
> At least the first four items in this list seem to be quite widely used. I'd
> like some opinions on which (if any) of these people think would fit in scipy,
> and which ones should rather be kept in a wavelets-specific package.

To me, the most important thing is to get wavelets in scipy, the rest is
vastly less important.

Ga?l


From ralf.gommers at gmail.com  Sun May 10 17:24:08 2015
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sun, 10 May 2015 23:24:08 +0200
Subject: [SciPy-Dev] 0.16.0 release
In-Reply-To: <CABL7CQhmGq+7TJ9Npd0VyELf_h=ECbSRVaT7-kUYvAd5kcGm5Q@mail.gmail.com>
References: <CABL7CQh4E4ESabrJt6J91nAYwd9QN++p5kn3dq1xv+2bxK-gVA@mail.gmail.com>
	<CAJJ-iFmMWz_Oy+e+2rxxruaafd6c1D-q5JaB=g=dFW_p4SD4=A@mail.gmail.com>
	<CABL7CQizf4e7xo04dQdvng+12ocDR+c7LGHEe9KvJ5CmFrCKyA@mail.gmail.com>
	<CABL7CQi_ufgMLrFA-U4T8Mpr9TY+z99pKKCiHqFZC2pBrMCw=w@mail.gmail.com>
	<CABL7CQhmGq+7TJ9Npd0VyELf_h=ECbSRVaT7-kUYvAd5kcGm5Q@mail.gmail.com>
Message-ID: <CABL7CQgWbEo=aGsFSa4YHqXCJ_ZKa56JuaX3VKev=M6e7kLFMQ@mail.gmail.com>

On Sun, May 10, 2015 at 6:02 PM, Ralf Gommers <ralf.gommers at gmail.com>
wrote:

>
>
> On Sun, Apr 26, 2015 at 4:22 PM, Ralf Gommers <ralf.gommers at gmail.com>
> wrote:
>
>>
>>
>> On Sun, Apr 5, 2015 at 9:40 PM, Ralf Gommers <ralf.gommers at gmail.com>
>> wrote:
>>
>>> Hi Abraham, Andreas,
>>>
>>> Thanks for your interest to both of you!
>>>
>>> The release manager is the person that is responsible for a number of
>>> actions to get from "now we start planning for the next release" to "this
>>> release is done". This description should give a reasonable overview (some
>>> details may be a bit outdated):
>>> https://github.com/numpy/numpy/blob/master/doc/HOWTO_RELEASE.rst.txt
>>>
>>> The release manager is the person that has the final responsibility for
>>> what does and does not go into a release, what are considered blocking
>>> issues, etc. This part really has to be done by a core developer. However,
>>> there's a lot of other things that the release manager also usually takes
>>> care of which could equally well be done by one or more contributors who
>>> are not core developers. Here's a list:
>>> - build/test Windows and OS X binaries (.exe, .dmg, .whl)
>>> - automate those binary builds/tests further
>>> - tackle some of the issues that need to be resolved before the alpha /
>>> beta / final release
>>> - PRs to complete the release notes and contributor name mapping
>>> - a PR to the scipy.org repo to put the release in the News section
>>> - improve documentation of the release process itself (the less you know
>>> to start with, the better you can document it)
>>>
>>> Things that the release manager should do himself:
>>> - propose the release schedule (dates for alpha/beta/rc/final)
>>> - create the maintenance/0.16.x branch
>>> - tag the (pre-)releases
>>> - send the release announcement emails
>>> - upload binaries to PyPi and SourceForge
>>> - propose/make decisions on blockers and content
>>>
>>> And what's always a team effort: merge as many PRs as possible before
>>> the release split.
>>>
>>> I hope this gives a clear picture. A "release team" that jointly tackles
>>> the above tasks would be great. Still would like to see a core dev
>>> volunteer though:)
>>>
>>
>> Okay, I'll volunteer to be the release manager for this release. Here's a
>> proposal for the release schedule:
>>
>> - branching 0.16.x: 10 May
>> - beta 1: 12 May
>>
>
> Looks like we're in good shape for branching and the first beta release. I
> plan to create 0.16.x around 9pm GMT (so in about 5 hours). Anything you
> want to merge should be in by then.
>

maintenance/0.16.x is created, and master is at 0.17.0-dev now.

Ralf



> There's still one issue to sort out with the existing Windows BLAS/LAPACK
> binaries in numpy-vendor missing some functions, but that shouldn't hold up
> beta1 (it's probably fixable within two days, but worst-case it'll be a
> source-only beta).
>
> Cheers,
> Ralf
>
>
>
>> - release candidate 1: 24 May
>> - release candidate 2: 31 May (if needed)
>> - final release: 7 June
>>
>> There aren't many serious issues at the moment, the only nontrivial one
>> is the QR updating issue. Here's what's marked to go in still:
>> https://github.com/scipy/scipy/milestones/0.16.0. The above schedule
>> gives us two weeks to merge PRs. Of the larger ones, I'd still like to see
>> these go in:
>> - 4682: signal.csd/coherence/welch
>> - 4374: cKDTree rewrite
>>
>> If you see an issue that you consider a blocker or a PR that really
>> should go in, please label it with the 0.16.0 milestone or mention it here.
>>
>> Cheers,
>> Ralf
>>
>>
>>
>>
>>>
>>> Cheers,
>>> Ralf
>>>
>>> P.S. I shouldn't forget to mention that for a long time Matthew Brett
>>> has been building the OS X wheels and done extensive Scipy Stack testing.
>>> And that for an even longer time Christoph Gohlke has been testing
>>> pre-releases with MSVC on Windows and resolving issues that are invariable
>>> found on that platform. I definitely consider them part of the "release
>>> team" (not that we have ever used that name before).
>>>
>>>
>>>
>>>
>>> On Sat, Apr 4, 2015 at 9:30 PM, Abraham Escalante <aeklant at gmail.com>
>>> wrote:
>>>
>>>> Hi Ralf,
>>>>
>>>> This sounds interesting to me and I would like to contribute but I fear
>>>> I may be still too new to the community to be of much help but maybe I
>>>> could provide some assistance to learn.
>>>>
>>>> Is this a task for admins only? Is there a way I can contribute?
>>>>
>>>> Cheers,
>>>> Abraham.
>>>>
>>>> 2015-04-04 2:54 GMT-06:00 Ralf Gommers <ralf.gommers at gmail.com>:
>>>>
>>>>> Hi all,
>>>>>
>>>>> It's about time to start preparing for the 0.16.0 release. Unusually,
>>>>> there are zero blocking issues it looks like. A lot of PRs to merge of
>>>>> course, but nothing very large that still needs a lot of work.
>>>>>
>>>>> Most important question: does anyone want to take the release manager
>>>>> role for this release? It would be good to start rotating this role for
>>>>> every minor release. This will help spread the knowledge on how to do
>>>>> releases and also spread the workload (it's not that much for a single
>>>>> release, but it adds up).
>>>>>
>>>>> 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/20150510/15e1f158/attachment.html>

From sturla.molden at gmail.com  Sun May 10 17:48:35 2015
From: sturla.molden at gmail.com (Sturla Molden)
Date: Sun, 10 May 2015 21:48:35 +0000 (UTC)
Subject: [SciPy-Dev] question of scope wavelet code
References: <CABL7CQj0hqJif1pprqSzneu9EWjSKm=k_0OgHXCnfu1XiEvpag@mail.gmail.com>
Message-ID: <864249501452986615.911958sturla.molden-gmail.com@news.gmane.org>

PyWavelets have a lot of design problems. For example this:

https://github.com/rgommers/pywt/blob/master/pywt/src/wavelets_coeffs.h.src

There is no reason this should be in C. It is easier to add new wavelets if
the coefficients are in a Python file. ndarrays can be initialized with the
coefficients on module import.

If we get rid of all the unneccesary C in PyWavelets, I think we end up
with a tiny bit of Cython (eg. in the dwt and idwt functions) and the rest
can be Python. There is no reason to use C or Cython outside the
computationally expensive routines, by PyWavelets does that everywhere.

Sturla



Ralf Gommers <ralf.gommers at gmail.com> wrote:
> Hi all,
> 
> As you may know, I forked PyWavelets a while ago and with the help of quite
> a few people started bringing it up to the standards needed for inclusion
> in scipy: <a
> href="https://github.com/rgommers/pywt.">https://github.com/rgommers/pywt.</a> The last
> year I haven't had too
> much time for it, but I'd like to get back to it. That's also triggered by
> several PRs and proposed enhancements - there's quite a bit of interest for
> a fork that never actually had a release. This proposal
> <a
> href="https://github.com/rgommers/pywt/issues/58">https://github.com/rgommers/pywt/issues/58</a>)
> to add contourlets triggered me
> to bring up what the scope of a (discrete) wavelets module in scipy should
> be.
> 
> What's there now is still mostly what's listed in
> <a
> href="http://pywavelets.readthedocs.org/en/latest/.">http://pywavelets.readthedocs.org/en/latest/.</a>
> A few additions are/were
> no-brainers, like n-D inverse DWT and inverse SWT (stationary wavelet
> transform). But beyond that I realize that a bit of care is needed, because
> there's a huge array of variations on wavelets. Here's a quick list of what
> I'm aware of, ordered from most to least important in my perspective:
> 
> - curvelets (https://en.wikipedia.org/wiki/Curvelet)
> - contourlets (http://en.wikipedia.org/wiki/Contourlet)
> - shearlets (http://en.wikipedia.org/wiki/Shearlet <a
> href="http://shearlab.org">http://shearlab.org</a> GPL)
> - chirplets (http://en.wikipedia.org/wiki/Chirplet_transform
> <a href="http://tfd.sourceforge.net/">http://tfd.sourceforge.net/</a> GPL)
> - ridgelets (
> <a
> href="http://rsta.royalsocietypublishing.org/content/357/1760/2495.short">http://rsta.royalsocietypublishing.org/content/357/1760/2495.short</a>)
> - wedgelets (http://projecteuclid.org/euclid.aos/1018031261)
> - noiselets (http://en.wikipedia.org/wiki/Noiselet)
> - surfacelets (http://dx.doi.org/10.1109/TIP.2007.891785)
> - bandelets (http://en.wikipedia.org/wiki/Bandelet)
> 
> At least the first four items in this list seem to be quite widely used.
> I'd like some opinions on which (if any) of these people think would fit in
> scipy, and which ones should rather be kept in a wavelets-specific package.
> 
> Also, if anyone has experience using the contourlet toolbox under
> discussion in issue 58, would be great to hear how it performed.
> 
> Ralf
> 
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> <a
> href="http://mail.scipy.org/mailman/listinfo/scipy-dev">http://mail.scipy.org/mailman/listinfo/scipy-dev</a>



From ralf.gommers at gmail.com  Mon May 11 02:04:57 2015
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Mon, 11 May 2015 08:04:57 +0200
Subject: [SciPy-Dev] question of scope wavelet code
In-Reply-To: <20150510201029.GC959311@phare.normalesup.org>
References: <CABL7CQj0hqJif1pprqSzneu9EWjSKm=k_0OgHXCnfu1XiEvpag@mail.gmail.com>
	<20150510201029.GC959311@phare.normalesup.org>
Message-ID: <CABL7CQjRkGQ+j91Wb2tVOsFLMOUSF-7fnkZMU8OB4AhTjVjLig@mail.gmail.com>

On Sun, May 10, 2015 at 10:10 PM, Gael Varoquaux <
gael.varoquaux at normalesup.org> wrote:

> On Sun, May 10, 2015 at 10:07:08PM +0200, Ralf Gommers wrote:
> > At least the first four items in this list seem to be quite widely used.
> I'd
> > like some opinions on which (if any) of these people think would fit in
> scipy,
> > and which ones should rather be kept in a wavelets-specific package.
>
> To me, the most important thing is to get wavelets in scipy, the rest is
> vastly less important.
>

I agree. I guess what I'm asking about though is what do we consider nice
bonuses, and what do we definitely not want in Scipy because it's
applicability isn't wide enough. The former I can just merge when there's a
good PR to pywt now, the latter I need to keep out or keep separate.

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

From ralf.gommers at gmail.com  Mon May 11 02:08:27 2015
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Mon, 11 May 2015 08:08:27 +0200
Subject: [SciPy-Dev] question of scope wavelet code
In-Reply-To: <864249501452986615.911958sturla.molden-gmail.com@news.gmane.org>
References: <CABL7CQj0hqJif1pprqSzneu9EWjSKm=k_0OgHXCnfu1XiEvpag@mail.gmail.com>
	<864249501452986615.911958sturla.molden-gmail.com@news.gmane.org>
Message-ID: <CABL7CQi6MtrtxaV8z1TqVwKgFYNse=6M6HvkFozyHv-9D2sfsw@mail.gmail.com>

On Sun, May 10, 2015 at 11:48 PM, Sturla Molden <sturla.molden at gmail.com>
wrote:

> PyWavelets have a lot of design problems. For example this:
>
> https://github.com/rgommers/pywt/blob/master/pywt/src/wavelets_coeffs.h.src
>
> There is no reason this should be in C. It is easier to add new wavelets if
> the coefficients are in a Python file. ndarrays can be initialized with the
> coefficients on module import.
>
> If we get rid of all the unneccesary C in PyWavelets, I think we end up
> with a tiny bit of Cython (eg. in the dwt and idwt functions) and the rest
> can be Python. There is no reason to use C or Cython outside the
> computationally expensive routines, by PyWavelets does that everywhere.
>

Definitely, the original code is quite sub-optimal. I already got rid of
about half the C extensions and headers, and a homegrown templating
mechanism. Feel free to open an issue though and point out what needs
fixing in the current repo, that would help.

Cheers,
Ralf



>
> Sturla
>
>
>
> Ralf Gommers <ralf.gommers at gmail.com> wrote:
> > Hi all,
> >
> > As you may know, I forked PyWavelets a while ago and with the help of
> quite
> > a few people started bringing it up to the standards needed for inclusion
> > in scipy: <a
> > href="https://github.com/rgommers/pywt.">
> https://github.com/rgommers/pywt.</a> The last
> > year I haven't had too
> > much time for it, but I'd like to get back to it. That's also triggered
> by
> > several PRs and proposed enhancements - there's quite a bit of interest
> for
> > a fork that never actually had a release. This proposal
> > <a
> > href="https://github.com/rgommers/pywt/issues/58">
> https://github.com/rgommers/pywt/issues/58</a>)
> > to add contourlets triggered me
> > to bring up what the scope of a (discrete) wavelets module in scipy
> should
> > be.
> >
> > What's there now is still mostly what's listed in
> > <a
> > href="http://pywavelets.readthedocs.org/en/latest/.">
> http://pywavelets.readthedocs.org/en/latest/.</a>
> > A few additions are/were
> > no-brainers, like n-D inverse DWT and inverse SWT (stationary wavelet
> > transform). But beyond that I realize that a bit of care is needed,
> because
> > there's a huge array of variations on wavelets. Here's a quick list of
> what
> > I'm aware of, ordered from most to least important in my perspective:
> >
> > - curvelets (https://en.wikipedia.org/wiki/Curvelet)
> > - contourlets (http://en.wikipedia.org/wiki/Contourlet)
> > - shearlets (http://en.wikipedia.org/wiki/Shearlet <a
> > href="http://shearlab.org">http://shearlab.org</a> GPL)
> > - chirplets (http://en.wikipedia.org/wiki/Chirplet_transform
> > <a href="http://tfd.sourceforge.net/">http://tfd.sourceforge.net/</a>
> GPL)
> > - ridgelets (
> > <a
> > href="http://rsta.royalsocietypublishing.org/content/357/1760/2495.short
> ">http://rsta.royalsocietypublishing.org/content/357/1760/2495.short</a>)
> > - wedgelets (http://projecteuclid.org/euclid.aos/1018031261)
> > - noiselets (http://en.wikipedia.org/wiki/Noiselet)
> > - surfacelets (http://dx.doi.org/10.1109/TIP.2007.891785)
> > - bandelets (http://en.wikipedia.org/wiki/Bandelet)
> >
> > At least the first four items in this list seem to be quite widely used.
> > I'd like some opinions on which (if any) of these people think would fit
> in
> > scipy, and which ones should rather be kept in a wavelets-specific
> package.
> >
> > Also, if anyone has experience using the contourlet toolbox under
> > discussion in issue 58, would be great to hear how it performed.
> >
> > Ralf
> >
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at scipy.org
> > <a
> > href="http://mail.scipy.org/mailman/listinfo/scipy-dev">
> http://mail.scipy.org/mailman/listinfo/scipy-dev</a>
>
> _______________________________________________
> 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/20150511/f9e8556f/attachment.html>

From heldercro at gmail.com  Mon May 11 07:17:37 2015
From: heldercro at gmail.com (Helder)
Date: Mon, 11 May 2015 08:17:37 -0300
Subject: [SciPy-Dev] question of scope wavelet code
In-Reply-To: <CABL7CQj0hqJif1pprqSzneu9EWjSKm=k_0OgHXCnfu1XiEvpag@mail.gmail.com>
References: <CABL7CQj0hqJif1pprqSzneu9EWjSKm=k_0OgHXCnfu1XiEvpag@mail.gmail.com>
Message-ID: <CABLyCbJvOt3gfrBn=i+q6Nd-+oZNUNUfqG1c5sYWa3x7QOERNw@mail.gmail.com>

Hi. I'm not expert, so this is just an opinion.

I've been studing wavelets as a 'hobby' for about six months.
My intent is to perform denoising of mammographic images using them.

In my experience reading scientific papers I see be used: curvelets,
contourlets and ridgelets.
The other ones I never heard of.

Cheers.





Att,
*Helder C. R. de Oliveira*
EESC/Universidade de S?o Paulo
http://helderc.github.io


On Sun, May 10, 2015 at 5:07 PM, Ralf Gommers <ralf.gommers at gmail.com>
wrote:

> Hi all,
>
> As you may know, I forked PyWavelets a while ago and with the help of
> quite a few people started bringing it up to the standards needed for
> inclusion in scipy: https://github.com/rgommers/pywt. The last year I
> haven't had too much time for it, but I'd like to get back to it. That's
> also triggered by several PRs and proposed enhancements - there's quite a
> bit of interest for a fork that never actually had a release. This proposal
> https://github.com/rgommers/pywt/issues/58) to add contourlets triggered
> me to bring up what the scope of a (discrete) wavelets module in scipy
> should be.
>
> What's there now is still mostly what's listed in
> http://pywavelets.readthedocs.org/en/latest/. A few additions are/were
> no-brainers, like n-D inverse DWT and inverse SWT (stationary wavelet
> transform). But beyond that I realize that a bit of care is needed, because
> there's a huge array of variations on wavelets. Here's a quick list of what
> I'm aware of, ordered from most to least important in my perspective:
>
> - curvelets (https://en.wikipedia.org/wiki/Curvelet)
> - contourlets (http://en.wikipedia.org/wiki/Contourlet)
> - shearlets (http://en.wikipedia.org/wiki/Shearlet http://shearlab.org
> GPL)
> - chirplets (http://en.wikipedia.org/wiki/Chirplet_transform
> http://tfd.sourceforge.net/ GPL)
> - ridgelets (
> http://rsta.royalsocietypublishing.org/content/357/1760/2495.short)
> - wedgelets (http://projecteuclid.org/euclid.aos/1018031261)
> - noiselets (http://en.wikipedia.org/wiki/Noiselet)
> - surfacelets (http://dx.doi.org/10.1109/TIP.2007.891785)
> - bandelets (http://en.wikipedia.org/wiki/Bandelet)
>
> At least the first four items in this list seem to be quite widely used.
> I'd like some opinions on which (if any) of these people think would fit in
> scipy, and which ones should rather be kept in a wavelets-specific package.
>
> Also, if anyone has experience using the contourlet toolbox under
> discussion in issue 58, would be great to hear how it performed.
>
> 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/20150511/ee8eff6a/attachment.html>

From jbm139 at gmail.com  Mon May 11 10:21:46 2015
From: jbm139 at gmail.com (Jon Moody)
Date: Mon, 11 May 2015 10:21:46 -0400
Subject: [SciPy-Dev] question of scope wavelet code
In-Reply-To: <CABL7CQj0hqJif1pprqSzneu9EWjSKm=k_0OgHXCnfu1XiEvpag@mail.gmail.com>
References: <CABL7CQj0hqJif1pprqSzneu9EWjSKm=k_0OgHXCnfu1XiEvpag@mail.gmail.com>
Message-ID: <5550BAFA.8000507@gmail.com>



On 5/10/2015 4:07 PM, Ralf Gommers wrote:
>
> - curvelets (https://en.wikipedia.org/wiki/Curvelet)
> - contourlets (http://en.wikipedia.org/wiki/Contourlet)
> - shearlets (http://en.wikipedia.org/wiki/Shearlet http://shearlab.org 
> GPL)
> - chirplets (http://en.wikipedia.org/wiki/Chirplet_transform 
> http://tfd.sourceforge.net/ GPL)
> - ridgelets 
> (http://rsta.royalsocietypublishing.org/content/357/1760/2495.short)
> - wedgelets (http://projecteuclid.org/euclid.aos/1018031261)
> - noiselets (http://en.wikipedia.org/wiki/Noiselet)
> - surfacelets (http://dx.doi.org/10.1109/TIP.2007.891785)
> - bandelets (http://en.wikipedia.org/wiki/Bandelet)
>
> At least the first four items in this list seem to be quite widely 
> used. I'd like some opinions on which (if any) of these people think 
> would fit in scipy, and which ones should rather be kept in a 
> wavelets-specific package.
>
> Also, if anyone has experience using the contourlet toolbox under 
> discussion in issue 58, would be great to hear how it performed.

It's been a while (~7 years ago), but I used the contourlet toolbox for 
denoising in PET image reconstruction.  It seemed to work better than 
regular 2D DWT but if I remember right there was an improved version of 
the contourlet (ref. 10 on the contourlet wikipedia page) that wasn't 
ever incorporated into the original matlab toolbox. Another transform I 
ended up using more was the dual-tree complex WT 
(http://en.wikipedia.org/wiki/Complex_wavelet_transform) and matlab code 
from Nick Kingsbury's web site 
(http://www-sigproc.eng.cam.ac.uk/Main/NGK). This WT has approximate 
shift invariance 
(http://en.wikipedia.org/wiki/Complex_wavelet_transform#cite_ref-4) 
which is nice when working with images.
--
Jon



From sturla.molden at gmail.com  Mon May 11 11:19:13 2015
From: sturla.molden at gmail.com (Sturla Molden)
Date: Mon, 11 May 2015 17:19:13 +0200
Subject: [SciPy-Dev] Porting the rest of cKDTree query functions to C++
Message-ID: <miqh8l$jrq$1@ger.gmane.org>


I have started the tedious work of porting the rest of cKDTree to C++. 
The structure is similar to the query method that is in C++ in the 0.16 
branch.

The other methods have much more to gain from C++ than query due to 
substantially larger Python overhead. On my old laptop with AMD Phenom 
the new query method reduced the query time from 85 seconds to about 3 
seconds. The improvement in the other methods is likely to be much 
better than that.

Right now I have mostly just copied out code and made placeholders for 
the C++. But the main structure is already there.

It is now in this branch on Github:

https://github.com/sturlamolden/scipy/tree/cpp_ckdtree/scipy/spatial/ckdtree

(I am not sure if I should post a WIP PR or wait until it builds 
correctly so Travis does not have a heart attack.)


Sturla



From jsseabold at gmail.com  Tue May 12 09:10:04 2015
From: jsseabold at gmail.com (Skipper Seabold)
Date: Tue, 12 May 2015 08:10:04 -0500
Subject: [SciPy-Dev] adding cut tree function to scipy.cluster
Message-ID: <CAKF=DjtkWQ740kCa93F3fbhSHPA2zdvDOAoDKh97w7sgfJ+4rw@mail.gmail.com>

Hi,

I wanted to solicit feedback on adding a function similar to R's cutree [1]
to scipy.cluster. PR here [2]

It takes a linkage matrix and returns an array where each step is the group
to which each observation was merged at any given agglomeration step.

Example from the docstring:



>>> from scipy import cluster >>> np.random.seed(23) >>> X =
np.random.randn(50, 4) >>> Z = cluster.hierarchy.ward(X) >>> cutree =
cluster.hierarchy.cut_tree(Z, n_clusters=[5, 10]) >>> cutree[:10]
array([[0, 0], [1, 1], [2, 2], [3, 3], [3, 4], [2, 2], [0, 0], [1, 5], [3,
6], [4, 7]])


[1] https://stat.ethz.ch/R-manual/R-patched/library/stats/html/cutree.html
[2] https://github.com/scipy/scipy/pull/4796
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150512/ebc93d30/attachment.html>

From ocp at gatech.edu  Tue May 12 16:02:08 2015
From: ocp at gatech.edu (Oliver Pierson)
Date: Tue, 12 May 2015 16:02:08 -0400
Subject: [SciPy-Dev] Fwd: Integral Equation Solver
In-Reply-To: <CAKOy90YrbHdqRTvQ4Mv6CFtF1xL+w7NdHcxRZ5cz89PcCjsL9g@mail.gmail.com>
References: <CAKOy90YrbHdqRTvQ4Mv6CFtF1xL+w7NdHcxRZ5cz89PcCjsL9g@mail.gmail.com>
Message-ID: <CAKOy90Y2AW7Z5cVbP3Du969Qu4u77gW-iQNN64MrSf+FiQN3wg@mail.gmail.com>

Hi All,

  Awhile back I had written some code to solve Volterra integral equations
(integral equations where one of the integration bounds is a variable).
The code is available on Github (https://github.com/oliverpierson/volterra).
Just curious if there'd be any interest in adding this to Scipy?  I still
have some work to do on the code.  However, before I invest too much time,
I was trying to get a feel for the interest in this functionality.



Please let me know if you have any questions.



Thanks,

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

From ralf.gommers at gmail.com  Tue May 12 17:54:55 2015
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Tue, 12 May 2015 23:54:55 +0200
Subject: [SciPy-Dev] ANN: Scipy 0.16.0 beta 1 release
Message-ID: <CABL7CQjwediXQqn=1deGDRZJiXfhVsSKLmt1QoZr6HgENc1QWw@mail.gmail.com>

Hi all,

I'm pleased to announce the availability of the first beta release of Scipy
0.16.0. Please try this beta and report any issues on the Github issue
tracker or on the scipy-dev mailing list.

This first beta is a source-only release; binary installers will follow
(probably next week). Source tarballs and the full release notes can be
found at https://sourceforge.net/projects/scipy/files/scipy/0.16.0b1/. Part
of the release notes copied below.

Thanks to everyone who contributed to this release!

Ralf



==========================
SciPy 0.16.0 Release Notes
==========================

.. note:: Scipy 0.16.0 is not released yet!

SciPy 0.16.0 is the culmination of 6 months of hard work. It contains
many new features, numerous bug-fixes, improved test coverage and
better documentation.  There have been a number of deprecations and
API changes in this release, which are documented below.  All users
are encouraged to upgrade to this release, as there are a large number
of bug-fixes and optimizations.  Moreover, our development attention
will now shift to bug-fix releases on the 0.15.x branch, and on adding
new features on the master branch.

This release requires Python 2.6, 2.7 or 3.2-3.4 and NumPy 1.6.2 or greater.

Highlights of this release include:

- A Cython API for BLAS/LAPACK in `scipy.linalg`
- A new benchmark suite.  It's now straightforward to add new benchmarks,
and
  they're routinely included with performance enhancement PRs.
- Support for the second order sections (SOS) format in `scipy.signal`.


New features
============

Benchmark suite
---------------

The benchmark suite has switched to using `Airspeed Velocity
<http://spacetelescope.github.io/asv/>`__ for benchmarking. You can
run the suite locally via ``python runtests.py --bench``. For more
details, see ``benchmarks/README.rst``.

`scipy.linalg` improvements
---------------------------

A full set of Cython wrappers for BLAS and LAPACK has been added in the
modules `scipy.linalg.cython_blas` and `scipy.linalg.cython_lapack`.
In Cython, these wrappers can now be cimported from their corresponding
modules and used without linking directly against BLAS or LAPACK.

The functions `scipy.linalg.qr_delete`, `scipy.linalg.qr_insert` and
`scipy.linalg.qr_update` for updating QR decompositions were added.

The function `scipy.linalg.solve_circulant` solves a linear system with
a circulant coefficient matrix.

The function `scipy.linalg.invpascal` computes the inverse of a Pascal
matrix.

The function `scipy.linalg.solve_toeplitz`, a Levinson-Durbin Toeplitz
solver,
was added.

Added wrapper for potentially useful LAPACK function ``*lasd4``.  It
computes
the square root of the i-th updated eigenvalue of a positive symmetric
rank-one
modification to a positive diagonal matrix. See its LAPACK documentation and
unit tests for it to get more info.

Added two extra wrappers for LAPACK least-square solvers. Namely, they are
``*gelsd`` and ``*gelsy``.

Wrappers for the LAPACK ``*lange`` functions, which calculate various matrix
norms, were added.

Wrappers for ``*gtsv`` and ``*ptsv``, which solve ``A*X = B`` for
tri-diagonal
matrix ``A``, were added.

`scipy.signal` improvements
---------------------------

Support for second order sections (SOS) as a format for IIR filters
was added.  The new functions are:

* `scipy.signal.sosfilt`
* `scipy.signal.sosfilt_zi`,
* `scipy.signal.sos2tf`
* `scipy.signal.sos2zpk`
* `scipy.signal.tf2sos`
* `scipy.signal.zpk2sos`.

Additionally, the filter design functions `iirdesign`, `iirfilter`,
`butter`,
`cheby1`, `cheby2`, `ellip`, and `bessel` can return the filter in the SOS
format.

The function `scipy.signal.place_poles`, which provides two methods to place
poles for linear systems, was added.

The option to use Gustafsson's method for choosing the initial conditions
of the forward and backward passes was added to `scipy.signal.filtfilt`.

New classes ``TransferFunction``, ``StateSpace`` and ``ZerosPolesGain`` were
added.  These classes are now returned when instantiating
`scipy.signal.lti`.
Conversion between those classes can be done explicitly now.

An exponential (Poisson) window was added as `scipy.signal.exponential`,
and a
Tukey window was added as `scipy.signal.tukey`.

The function for computing digital filter group delay was added as
`scipy.signal.group_delay`.

The functionality for spectral analysis and spectral density estimation has
been significantly improved: `scipy.signal.welch` became ~8x faster and the
functions `scipy.signal.spectrogram`, `scipy.signal.coherence` and
`scipy.signal.csd` (cross-spectral density) were added.

`scipy.signal.lsim` was rewritten - all known issues are fixed, so this
function can now be used instead of ``lsim2``; ``lsim`` is orders of
magnitude
faster than ``lsim2`` in most cases.

`scipy.sparse` improvements
---------------------------

The function `scipy.sparse.norm`, which computes sparse matrix norms, was
added.

The function `scipy.sparse.random`, which allows to draw random variates
from
an arbitrary distribution, was added.

`scipy.spatial` improvements
----------------------------

`scipy.spatial.cKDTree` has seen a major rewrite, which improved the
performance of the ``query`` method significantly, added support for
parallel
queries, pickling, and options that affect the tree layout.  See pull
request
4374 for more details.

The function `scipy.spatial.procrustes` for Procrustes analysis (statistical
shape analysis) was added.

`scipy.stats` improvements
--------------------------

The Wishart distribution and its inverse have been added, as
`scipy.stats.wishart` and `scipy.stats.invwishart`.

The Exponentially Modified Normal distribution has been
added as `scipy.stats.exponnorm`.

The Generalized Normal distribution has been added as `scipy.stats.gennorm`.

All distributions now contain a ``random_state`` property and allow
specifying a
specific ``numpy.random.RandomState`` random number generator when
generating
random variates.

Many statistical tests and other `scipy.stats` functions that have multiple
return values now return ``namedtuples``.  See pull request 4709 for
details.

`scipy.optimize` improvements
-----------------------------

A new derivative-free method DF-SANE has been added to the nonlinear
equation
system solving function `scipy.optimize.root`.


Deprecated features
===================

``scipy.stats.pdf_fromgamma`` is deprecated.  This function was
undocumented,
untested and rarely used.  Statsmodels provides equivalent functionality
with ``statsmodels.distributions.ExpandedNormal``.

``scipy.stats.fastsort`` is deprecated.  This function is unnecessary,
``numpy.argsort`` can be used instead.

``scipy.stats.signaltonoise`` and ``scipy.stats.mstats.signaltonoise`` are
deprecated.  These functions did not belong in ``scipy.stats`` and are
rarely
used.  See issue #609 for details.

``scipy.stats.histogram2`` is deprecated. This function is unnecessary,
``numpy.histogram2d`` can be used instead.

Backwards incompatible changes
==============================

The deprecated global optimizer ``scipy.optimize.anneal`` was removed.

The following deprecated modules have been removed: ``scipy.lib.blas``,
``scipy.lib.lapack``, ``scipy.linalg.cblas``, ``scipy.linalg.fblas``,
``scipy.linalg.clapack``, ``scipy.linalg.flapack``.  They had been
deprecated
since Scipy 0.12.0, the functionality should be accessed as
`scipy.linalg.blas`
and `scipy.linalg.lapack`.

The deprecated function ``scipy.special.all_mat`` has been removed.

The deprecated functions ``fprob``, ``ksprob``, ``zprob``, ``randwcdf``
and ``randwppf`` have been removed from `scipy.stats`.


Other changes
=============

The version numbering for development builds has been updated to comply
with PEP 440.

Building with ``python setup.py develop`` is now supported.


Authors
=======

* @axiru +
* @endolith
* Elliott Sales de Andrade +
* Anne Archibald
* Yoshiki V?zquez Baeza +
* Sylvain Bellemare
* Felix Berkenkamp +
* Raoul Bourquin +
* Matthew Brett
* Per Brodtkorb
* Christian Brueffer
* Lars Buitinck
* Evgeni Burovski
* Steven Byrnes
* CJ Carey
* George Castillo +
* Alex Conley +
* Liam Damewood +
* Rupak Das +
* Abraham Escalante +
* Matthias Feurer +
* Eric Firing +
* Clark Fitzgerald
* Chad Fulton
* Andr? Gaul
* Andreea Georgescu +
* Christoph Gohlke
* Andrey Golovizin +
* Ralf Gommers
* J.J. Green +
* Alex Griffing
* Alexander Grigorievskiy +
* Hans Moritz Gunther +
* Jonas Hahnfeld +
* Charles Harris
* Ian Henriksen
* Andreas Hilboll
* ?smund Hjulstad +
* Jan Schl?ter +
* Janko Slavi? +
* Daniel Jensen +
* Johannes Ball? +
* Terry Jones +
* Amato Kasahara +
* Eric Larson
* Denis Laxalde
* Antony Lee
* Gregory R. Lee
* Perry Lee +
* Lo?c Est?ve
* Martin Manns +
* Eric Martin +
* Mat?j Koci?n +
* Andreas Mayer +
* Nikolay Mayorov +
* Robert McGibbon +
* Sturla Molden
* Nicola Montecchio +
* Eric Moore
* Jamie Morton +
* Nikolas Moya +
* Maniteja Nandana +
* Andrew Nelson
* Joel Nothman
* Aldrian Obaja
* Regina Ongowarsito +
* Paul Ortyl +
* Pedro L?pez-Adeva Fern?ndez-Layos +
* Stefan Peterson +
* Irvin Probst +
* Eric Quintero +
* John David Reaver +
* Juha Remes +
* Thomas Robitaille
* Clancy Rowley +
* Tobias Schmidt +
* Skipper Seabold
* Aman Singh +
* Eric Soroos
* Valentine Svensson +
* Julian Taylor
* Aman Thakral +
* Helmut Toplitzer +
* Fukumu Tsutsumi +
* Anastasiia Tsyplia +
* Jacob Vanderplas
* Pauli Virtanen
* Matteo Visconti +
* Warren Weckesser
* Florian Wilhelm +
* Nathan Woods
* Haochen Wu +
* Daan Wynen +

A total of 93 people contributed to this release.
People with a "+" by their names contributed a patch for the first time.
This list of names is automatically generated, and may not be fully
complete.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150512/3102f807/attachment.html>

From luke.pfister at gmail.com  Tue May 12 18:13:43 2015
From: luke.pfister at gmail.com (Luke Pfister)
Date: Tue, 12 May 2015 17:13:43 -0500
Subject: [SciPy-Dev] question of scope wavelet code
In-Reply-To: <5550BAFA.8000507@gmail.com>
References: <CABL7CQj0hqJif1pprqSzneu9EWjSKm=k_0OgHXCnfu1XiEvpag@mail.gmail.com>
	<5550BAFA.8000507@gmail.com>
Message-ID: <CANERkTMZ_-4XzCKqyWnYv-h6xuyF-yTwLpCPHbuGPbF2V2e6qw@mail.gmail.com>

On Mon, May 11, 2015 at 9:21 AM, Jon Moody <jbm139 at gmail.com> wrote:

>
>
> On 5/10/2015 4:07 PM, Ralf Gommers wrote:
> >
> > - curvelets (https://en.wikipedia.org/wiki/Curvelet)
> > - contourlets (http://en.wikipedia.org/wiki/Contourlet)
> > - shearlets (http://en.wikipedia.org/wiki/Shearlet http://shearlab.org
> > GPL)
> > - chirplets (http://en.wikipedia.org/wiki/Chirplet_transform
> > http://tfd.sourceforge.net/ GPL)
> > - ridgelets
> > (http://rsta.royalsocietypublishing.org/content/357/1760/2495.short)
> > - wedgelets (http://projecteuclid.org/euclid.aos/1018031261)
> > - noiselets (http://en.wikipedia.org/wiki/Noiselet)
> > - surfacelets (http://dx.doi.org/10.1109/TIP.2007.891785)
> > - bandelets (http://en.wikipedia.org/wiki/Bandelet)
> >
> > At least the first four items in this list seem to be quite widely
> > used. I'd like some opinions on which (if any) of these people think
> > would fit in scipy, and which ones should rather be kept in a
> > wavelets-specific package.
> >
> > Also, if anyone has experience using the contourlet toolbox under
> > discussion in issue 58, would be great to hear how it performed.
>
> It's been a while (~7 years ago), but I used the contourlet toolbox for
> denoising in PET image reconstruction.  It seemed to work better than
> regular 2D DWT but if I remember right there was an improved version of
> the contourlet (ref. 10 on the contourlet wikipedia page) that wasn't
> ever incorporated into the original matlab toolbox. Another transform I
> ended up using more was the dual-tree complex WT
> (http://en.wikipedia.org/wiki/Complex_wavelet_transform) and matlab code
> from Nick Kingsbury's web site
> (http://www-sigproc.eng.cam.ac.uk/Main/NGK). This WT has approximate
> shift invariance
> (http://en.wikipedia.org/wiki/Complex_wavelet_transform#cite_ref-4)
> which is nice when working with images.
> --
> Jon
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>

I originally proposed the inclusion of contourlets into PyWavelets,
primarily because (1) I need to use them for a project, and (2) I see the
toolbox author frequently.

I agree with Ralf's ordering.  The first three are by far the most common
in my experience with regularized image reconstruction.

I don't have much of an opinion on where the various *-let implementations
should go; only a desire to see them be ported to Python.  The lack of
advanced 2D multiscale transformations is one of the major reasons that
some of my colleagues haven't made the jump from Matlab to Python.

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

From aaron.oleary at gmail.com  Wed May 13 05:26:22 2015
From: aaron.oleary at gmail.com (Aaron O'Leary)
Date: Wed, 13 May 2015 10:26:22 +0100
Subject: [SciPy-Dev] question of scope wavelet code
In-Reply-To: <864249501452986615.911958sturla.molden-gmail.com@news.gmane.org>
References: <CABL7CQj0hqJif1pprqSzneu9EWjSKm=k_0OgHXCnfu1XiEvpag@mail.gmail.com>
	<864249501452986615.911958sturla.molden-gmail.com@news.gmane.org>
Message-ID: <20150513092622.GA6505@tk422.lan>

On Sun 10 May, Sturla Molden wrote:
> If we get rid of all the unneccesary C in PyWavelets, I think we end up
> with a tiny bit of Cython (eg. in the dwt and idwt functions) and the rest
> can be Python. There is no reason to use C or Cython outside the
> computationally expensive routines, by PyWavelets does that everywhere.

Does this actually need doing before including it in scipy though? As
long as we don't break the api, does this need to be a barrier? I think
it will get a lot more eyes on it once included in scipy.


From aaron.oleary at gmail.com  Wed May 13 05:50:04 2015
From: aaron.oleary at gmail.com (Aaron O'Leary)
Date: Wed, 13 May 2015 10:50:04 +0100
Subject: [SciPy-Dev] question of scope wavelet code
In-Reply-To: <CABL7CQj0hqJif1pprqSzneu9EWjSKm=k_0OgHXCnfu1XiEvpag@mail.gmail.com>
References: <CABL7CQj0hqJif1pprqSzneu9EWjSKm=k_0OgHXCnfu1XiEvpag@mail.gmail.com>
Message-ID: <20150513095004.GB6505@tk422.lan>

On Sun 10 May, Ralf Gommers wrote:
> I'd like some opinions on which (if any) of these people think would fit in
> scipy, and which ones should rather be kept in a wavelets-specific package.

Personally, I used ridgelets last month. It's not particularly complex -
just a combination of the radon and wavelet transforms.

> what the scope of a (discrete) wavelets module in scipy should be.

I've been thinking about this on and off. Whilst the easiest thing to do
would be to copy pywt to `scipy.wavelets`, I'd want there to be room for
more functionality. In particular I'd like a continuous wavelets
implementation in there, but maybe there is scope for more as well.

Maybe we could provide for the future implementation of all sorts of
things by having a `scipy.transform` module. This could contain discrete
wavelets (i.e. pywt), continuous, curvelets, ridgelets. It could also
contain e.g. the radon transform (currently in skimage).

This is maybe a bit bikesheddy but I think a bit of thought in the api
layout could save a lot of bother.

I was working on making the pywt api suitable for scipy
(https://github.com/rgommers/pywt/pull/55) but haven't had as much time
recently.

aaron


From pavel.v.ponomarev at gmail.com  Wed May 13 10:08:40 2015
From: pavel.v.ponomarev at gmail.com (Pavel Ponomarev)
Date: Wed, 13 May 2015 16:08:40 +0200
Subject: [SciPy-Dev] scipy.optimize enh: modified _differentialevolution.py
 to enable parallel evaluation of the objective function for the whole
 population
Message-ID: <CAK-VtCsDBuvzi1KJ0tQmSQTino=O4vor79Ky1d6fDuehMfQzrQ@mail.gmail.com>

Hello,

Here is the modified file which works for parallel execution of the
objective functions for the whole population:
https://gist.github.com/pavelponomarev/20ea37324b219c7ed461/revisions

The discussion started here:
https://github.com/scipy/scipy/issues/4864

The additional boolean parameter "parallel" basically changes the required
argument of the objective function from single set of parameters to a list
of sets of parameters for the whole population. This enables the execution
of DE in parallel.

def pareval(listcoords):
    listresults = joblib.Parallel(n_jobs=num_cores)(delayed(objfunc)(i) for
i in listcoords)
    return listresults

result = differential_evolution(pareval, LIMS, parallel=True, polish=False)



BR, Pavel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150513/1712fcde/attachment.html>

From grlee77 at gmail.com  Thu May 14 16:08:56 2015
From: grlee77 at gmail.com (Gregory Lee)
Date: Thu, 14 May 2015 16:08:56 -0400
Subject: [SciPy-Dev] question of scope wavelet code
In-Reply-To: <5550BAFA.8000507@gmail.com>
References: <CABL7CQj0hqJif1pprqSzneu9EWjSKm=k_0OgHXCnfu1XiEvpag@mail.gmail.com>
	<5550BAFA.8000507@gmail.com>
Message-ID: <CAJR3sXd0ETRh_QXGeufSpuOE86vtHV-vjZ5jRfpTXMPjJgQEqA@mail.gmail.com>

> It's been a while (~7 years ago), but I used the contourlet toolbox for
> denoising in PET image reconstruction.  It seemed to work better than
> regular 2D DWT but if I remember right there was an improved version of
> the contourlet (ref. 10 on the contourlet wikipedia page) that wasn't
> ever incorporated into the original matlab toolbox. Another transform I
> ended up using more was the dual-tree complex WT
> (http://en.wikipedia.org/wiki/Complex_wavelet_transform) and matlab code
> from Nick Kingsbury's web site
> (http://www-sigproc.eng.cam.ac.uk/Main/NGK). This WT has approximate
> shift invariance
> (http://en.wikipedia.org/wiki/Complex_wavelet_transform#cite_ref-4)
> which is nice when working with images.
> --
> Jon
>
>
Hi Jon,

I recently found that the Dual-Tree Complex Wavelet Toolbox has a python
port, but couldn't find the license info for it
https://github.com/rjw57/dtcwt.

- Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150514/79a31c43/attachment.html>

From cmcfarl2 at stanford.edu  Thu May 14 16:14:39 2015
From: cmcfarl2 at stanford.edu (Christopher McFarland)
Date: Thu, 14 May 2015 13:14:39 -0700
Subject: [SciPy-Dev] Fwd: Adding Biweight Mid-Correlation to scipy.stats
In-Reply-To: <CAPnVv0AEYJmOO5aCorLY033AVnDEy1r9PU2En5N2Nk4Q8ZxhDA@mail.gmail.com>
References: <CAPnVv0AEYJmOO5aCorLY033AVnDEy1r9PU2En5N2Nk4Q8ZxhDA@mail.gmail.com>
Message-ID: <CAPnVv0D3yNdm80cxrhU-n-hizLuZT6Kc=_ms=tF8gBwQZh7arA@mail.gmail.com>

Hi,

I have implemented a common "robust" correlation metric, the Biweight
Mid-Correlation [1], for myself and wonder if this would be welcomed
function for scipy.stats. This function in R is titled 'bicor' [2] and is
especially popular in the biology community.

If the addition is welcomed, I'd be happy to Unit Test/Document/properly
stylize the function. I also wonder if a unified correlation function (with
keyword argument method={'pearson', 'spearman', 'kendall', 'bicor'}) would
be welcomed. All these functions have a similar purpose, inputs, and
outputs, and are implemented in Pandas with simply one unified function.

Chris

[1] "Introduction to Robust Estimation and Hypothesis Testing", Rand
Wilcox, Academic Press, 1997.
[2] http://www.inside-r.org/packages/cran/WGCNA/docs/bicor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150514/65ffe8fe/attachment.html>

From shoyer at gmail.com  Thu May 14 16:22:36 2015
From: shoyer at gmail.com (Stephan Hoyer)
Date: Thu, 14 May 2015 13:22:36 -0700
Subject: [SciPy-Dev] Fwd: Adding Biweight Mid-Correlation to scipy.stats
In-Reply-To: <CAPnVv0D3yNdm80cxrhU-n-hizLuZT6Kc=_ms=tF8gBwQZh7arA@mail.gmail.com>
References: <CAPnVv0AEYJmOO5aCorLY033AVnDEy1r9PU2En5N2Nk4Q8ZxhDA@mail.gmail.com>
	<CAPnVv0D3yNdm80cxrhU-n-hizLuZT6Kc=_ms=tF8gBwQZh7arA@mail.gmail.com>
Message-ID: <CAEQ_Tvcvmt3ocCvEjd=dc6FvTkbq+5vDXeyoxPRoG9YbtT3MmA@mail.gmail.com>

Hi Chris,

Olga Botvinnik has an open PR for adding Biweight Mid-Correlation to pandas:
https://github.com/pydata/pandas/pull/9826

Perhaps you could work together on the best way to move forward?

Stephan

On Thu, May 14, 2015 at 1:14 PM, Christopher McFarland <
cmcfarl2 at stanford.edu> wrote:

> Hi,
>
> I have implemented a common "robust" correlation metric, the Biweight
> Mid-Correlation [1], for myself and wonder if this would be welcomed
> function for scipy.stats. This function in R is titled 'bicor' [2] and is
> especially popular in the biology community.
>
> If the addition is welcomed, I'd be happy to Unit Test/Document/properly
> stylize the function. I also wonder if a unified correlation function (with
> keyword argument method={'pearson', 'spearman', 'kendall', 'bicor'}) would
> be welcomed. All these functions have a similar purpose, inputs, and
> outputs, and are implemented in Pandas with simply one unified function.
>
> Chris
>
> [1] "Introduction to Robust Estimation and Hypothesis Testing", Rand
> Wilcox, Academic Press, 1997.
> [2] http://www.inside-r.org/packages/cran/WGCNA/docs/bicor
>
>
> _______________________________________________
> 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/20150514/3d74258d/attachment.html>

From davidmenhur at gmail.com  Fri May 15 07:39:14 2015
From: davidmenhur at gmail.com (=?UTF-8?B?RGHPgGlk?=)
Date: Fri, 15 May 2015 13:39:14 +0200
Subject: [SciPy-Dev] question of scope wavelet code
In-Reply-To: <CAJR3sXd0ETRh_QXGeufSpuOE86vtHV-vjZ5jRfpTXMPjJgQEqA@mail.gmail.com>
References: <CABL7CQj0hqJif1pprqSzneu9EWjSKm=k_0OgHXCnfu1XiEvpag@mail.gmail.com>
	<5550BAFA.8000507@gmail.com>
	<CAJR3sXd0ETRh_QXGeufSpuOE86vtHV-vjZ5jRfpTXMPjJgQEqA@mail.gmail.com>
Message-ID: <CAJhcF=3Rs7-Pe=XB4bVin5tVsspViwTFuc9gOGfz80vrt46o_A@mail.gmail.com>

On 14 May 2015 at 22:08, Gregory Lee <grlee77 at gmail.com> wrote:

> I recently found that the Dual-Tree Complex Wavelet Toolbox has a python
> port, but couldn't find the license info for it
> https://github.com/rjw57/dtcwt.
>

It is under COPYING.txt:

https://github.com/rjw57/dtcwt/blob/master/COPYING.txt

It looks like BSD two clauses, but applies to the new code only. The
original code has as license:

This code is copyright and is supplied free of charge for research
purposes only. In return for supplying the code, all I ask is that, if
you use the algorithms, you give due reference to this work in any
papers that you write and that you let me know if you find any good
applications for the DT CWT.

https://github.com/rjw57/dtcwt/blob/master/ORIGINAL_README.txt

I don't know how much of it would apply to the port, but we could always
ask the original author.


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

From kasturi.surya at gmail.com  Sat May 16 11:47:56 2015
From: kasturi.surya at gmail.com (Surya)
Date: Sat, 16 May 2015 21:17:56 +0530
Subject: [SciPy-Dev] Testing and taking forward scipy central
Message-ID: <CAArdDCqAG2iDCe9rKobErgY-=PXc0PmKjWbz=vPU_15qqL5xSQ@mail.gmail.com>

Hello everyone,

Looks like I haven't posted anything in the list for a long time! I hope to
be pretty much active as far as SciPy Central is concerned.

There have been quite a lot of changes in the scipy central source
? ?
in the past few years.
?We have majorly developed a new front-end design, added some features like
comments, feeds, and rewriting some pieces.

Thanks to Sebastian, Pauli for their
?help, and ?
contributions. ?

?Brief information fo
r newbies in the community:

Repo: https://github.com/scipy/SciPyCentral
?

?Development Environment: Python 2.7, Django 1.4.5;
Front-end is based on Twitter Bootstrap 2.3.2, jQuery 1.9

?
Development setup is written in `README`?


Docs (initial version I started a year ago):
https://github.com/scipy/SciPyCentral/wiki/Newbie


I've just started with manual testing to see if there are any critical bugs
still present. My other agendas in coming days are to write documentation,
identify bottlenecks - improve response times of pages.

So, it would be great to hear from anyone interested in contributing this
project.

One can start looking into issue tracker in the repo and try to address
them.
Issue Tracker: https://github.com/scipy/SciPyCentral/issues

Otherwise, one can try to finish up the voting feature (to vote
submissions) I started building (which couldn't be merged into master yet).
It is built on the top of `django.contrib.comments` module.

Branch:
https://github.com/ksurya/SciPyCentral/tree/thumbs/scipy_central/thumbs

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150516/4deaa57b/attachment.html>

From ralf.gommers at gmail.com  Sun May 17 11:53:35 2015
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sun, 17 May 2015 17:53:35 +0200
Subject: [SciPy-Dev] Fwd: Integral Equation Solver
In-Reply-To: <CAKOy90Y2AW7Z5cVbP3Du969Qu4u77gW-iQNN64MrSf+FiQN3wg@mail.gmail.com>
References: <CAKOy90YrbHdqRTvQ4Mv6CFtF1xL+w7NdHcxRZ5cz89PcCjsL9g@mail.gmail.com>
	<CAKOy90Y2AW7Z5cVbP3Du969Qu4u77gW-iQNN64MrSf+FiQN3wg@mail.gmail.com>
Message-ID: <CABL7CQjRb+e82QMmOts9Lam2BS+b03-QqFBTMi-zGFuEGemqGQ@mail.gmail.com>

Hi Oliver,

On Tue, May 12, 2015 at 10:02 PM, Oliver Pierson <ocp at gatech.edu> wrote:

> Hi All,
>
>
>   Awhile back I had written some code to solve Volterra integral equations
> (integral equations where one of the integration bounds is a variable).
> The code is available on Github (https://github.com/oliverpierson/volterra).
> Just curious if there'd be any interest in adding this to Scipy?  I still
> have some work to do on the code.  However, before I invest too much time,
> I was trying to get a feel for the interest in this functionality.
>

It feels to me like the applicability is a bit too narrow to consider
inclusion in Scipy. I could be wrong, but I find only one previous question
about Volterra integral equations in the scipy mailing list (from 2007), no
other Python implementation and few papers or implementations in other
languages. Maybe it would make more sense to release your code as a
separate package on Pypi for now?

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

From ralf.gommers at gmail.com  Sun May 17 14:28:14 2015
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sun, 17 May 2015 20:28:14 +0200
Subject: [SciPy-Dev] Fwd: Adding Biweight Mid-Correlation to scipy.stats
In-Reply-To: <CAEQ_Tvcvmt3ocCvEjd=dc6FvTkbq+5vDXeyoxPRoG9YbtT3MmA@mail.gmail.com>
References: <CAPnVv0AEYJmOO5aCorLY033AVnDEy1r9PU2En5N2Nk4Q8ZxhDA@mail.gmail.com>
	<CAPnVv0D3yNdm80cxrhU-n-hizLuZT6Kc=_ms=tF8gBwQZh7arA@mail.gmail.com>
	<CAEQ_Tvcvmt3ocCvEjd=dc6FvTkbq+5vDXeyoxPRoG9YbtT3MmA@mail.gmail.com>
Message-ID: <CABL7CQiAAZwCPrPHUoctFbwu9aszw+gGpqp9sHDDxyH3gmvBhg@mail.gmail.com>

On Thu, May 14, 2015 at 10:22 PM, Stephan Hoyer <shoyer at gmail.com> wrote:

> Hi Chris,
>
> Olga Botvinnik has an open PR for adding Biweight Mid-Correlation to
> pandas:
> https://github.com/pydata/pandas/pull/9826
>
> Perhaps you could work together on the best way to move forward?
>
> Stephan
>
> On Thu, May 14, 2015 at 1:14 PM, Christopher McFarland <
> cmcfarl2 at stanford.edu> wrote:
>
>> Hi,
>>
>> I have implemented a common "robust" correlation metric, the Biweight
>> Mid-Correlation [1], for myself and wonder if this would be welcomed
>> function for scipy.stats. This function in R is titled 'bicor' [2] and is
>> especially popular in the biology community.
>>
>> If the addition is welcomed, I'd be happy to Unit Test/Document/properly
>> stylize the function. I also wonder if a unified correlation function (with
>> keyword argument method={'pearson', 'spearman', 'kendall', 'bicor'}) would
>> be welcomed.
>>
>
Sounds fine to add. I wonder if it needs to be a separate function though;
if you add the unified interface below then the separate function may not
be needed.


> All these functions have a similar purpose, inputs, and outputs, and are
>> implemented in Pandas with simply one unified function.
>>
>
This would be useful I think. The differences between the wrapped functions
would need dealing with, for example spearmanr takes an axis keyword, while
kendalltau flattens its inputs.

pointbiserialr could possibly also be included - slightly different
purpose, but also a correlation metric and has the exact same parameters
and returns.

Ralf



>
>> Chris
>>
>> [1] "Introduction to Robust Estimation and Hypothesis Testing", Rand
>> Wilcox, Academic Press, 1997.
>> [2] http://www.inside-r.org/packages/cran/WGCNA/docs/bicor
>>
>>
>> _______________________________________________
>> 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/20150517/dc92c060/attachment.html>

From ralf.gommers at gmail.com  Sun May 17 14:48:42 2015
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sun, 17 May 2015 20:48:42 +0200
Subject: [SciPy-Dev] Testing and taking forward scipy central
In-Reply-To: <CAArdDCqAG2iDCe9rKobErgY-=PXc0PmKjWbz=vPU_15qqL5xSQ@mail.gmail.com>
References: <CAArdDCqAG2iDCe9rKobErgY-=PXc0PmKjWbz=vPU_15qqL5xSQ@mail.gmail.com>
Message-ID: <CABL7CQjKOVbZirF7YXv8sf07OL6--Ud1hwTX+HVHrFWNRHieWQ@mail.gmail.com>

Hi Surya,

Good to see you're picking up SPC development again!

On Sat, May 16, 2015 at 5:47 PM, Surya <kasturi.surya at gmail.com> wrote:

> Hello everyone,
>
> Looks like I haven't posted anything in the list for a long time! I hope
> to be pretty much active as far as SciPy Central is concerned.
>
> There have been quite a lot of changes in the scipy central source
> ? ?
> in the past few years.
> ?We have majorly developed a new front-end design, added some features
> like comments, feeds, and rewriting some pieces.
>
> Thanks to Sebastian, Pauli for their
> ?help, and ?
> contributions. ?
>
> ?Brief information fo
> r newbies in the community:
>
> Repo: https://github.com/scipy/SciPyCentral
> ?
>
> ?Development Environment: Python 2.7, Django 1.4.5;
> Front-end is based on Twitter Bootstrap 2.3.2, jQuery 1.9
>
> ?
> Development setup is written in `README`?
>
>
> Docs (initial version I started a year ago):
> https://github.com/scipy/SciPyCentral/wiki/Newbie
>
>
Renaming this page to Contributing or Hacking would make it more obvious
what it's for.

Other pieces of documentation that could use some work:
- http://scipy-central.org/about, adding a more extensive description of
what the site is and why one would want to use it (instead of for example
StackOverflow).
- https://github.com/scipy/SciPyCentral/wiki/Licensing the discussion
mentioned there could be linked. An explanation also needs to be easily
discoverable by users of scipy-central.org

Cheers,
Ralf

I've just started with manual testing to see if there are any critical bugs
> still present. My other agendas in coming days are to write documentation,
> identify bottlenecks - improve response times of pages.
>
> So, it would be great to hear from anyone interested in contributing this
> project.
>
> One can start looking into issue tracker in the repo and try to address
> them.
> Issue Tracker: https://github.com/scipy/SciPyCentral/issues
>
> Otherwise, one can try to finish up the voting feature (to vote
> submissions) I started building (which couldn't be merged into master yet).
> It is built on the top of `django.contrib.comments` module.
>
> Branch:
> https://github.com/ksurya/SciPyCentral/tree/thumbs/scipy_central/thumbs
>
> Thanks
>
> _______________________________________________
> 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/20150517/9c314c0c/attachment.html>

From ocp at gatech.edu  Sun May 17 21:10:35 2015
From: ocp at gatech.edu (Oliver Pierson)
Date: Sun, 17 May 2015 21:10:35 -0400
Subject: [SciPy-Dev] Fwd: Integral Equation Solver
In-Reply-To: <CABL7CQjRb+e82QMmOts9Lam2BS+b03-QqFBTMi-zGFuEGemqGQ@mail.gmail.com>
References: <CAKOy90YrbHdqRTvQ4Mv6CFtF1xL+w7NdHcxRZ5cz89PcCjsL9g@mail.gmail.com>
	<CAKOy90Y2AW7Z5cVbP3Du969Qu4u77gW-iQNN64MrSf+FiQN3wg@mail.gmail.com>
	<CABL7CQjRb+e82QMmOts9Lam2BS+b03-QqFBTMi-zGFuEGemqGQ@mail.gmail.com>
Message-ID: <CAKOy90a9Mk1cBBD7xwwhPj8UgatrE6vsU+a-wsv_vzHRqBV0_w@mail.gmail.com>

Hi Ralf,
  Thanks for your reply.  I believe that Volterra integral equations have
some applicability in stochastic processes.  For example, I used them for
the inference of a first passage time distribution of a process obeying a
Langevin equation. Wikipedia says they "find application in demography, the
study of viscoelastic materials, and in insurance mathematics through the
renewal equation."  However, I don't work in any of those fields and as
matter of experience, I agree that they seem to be used quite rarely since
I had never encountered them prior to the application I spoke of above.
Your suggestion of a PyPi package seems like a good one; I'll work towards
that for now.

Regards,
Oliver


On Sun, May 17, 2015 at 11:53 AM, Ralf Gommers <ralf.gommers at gmail.com>
wrote:

> Hi Oliver,
>
> On Tue, May 12, 2015 at 10:02 PM, Oliver Pierson <ocp at gatech.edu> wrote:
>
>> Hi All,
>>
>>
>>   Awhile back I had written some code to solve Volterra integral
>> equations (integral equations where one of the integration bounds is a
>> variable).  The code is available on Github (
>> https://github.com/oliverpierson/volterra).  Just curious if there'd be
>> any interest in adding this to Scipy?  I still have some work to do on the
>> code.  However, before I invest too much time, I was trying to get a feel
>> for the interest in this functionality.
>>
>
> It feels to me like the applicability is a bit too narrow to consider
> inclusion in Scipy. I could be wrong, but I find only one previous question
> about Volterra integral equations in the scipy mailing list (from 2007), no
> other Python implementation and few papers or implementations in other
> languages. Maybe it would make more sense to release your code as a
> separate package on Pypi for now?
>
> 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/20150517/c5b08006/attachment.html>

From ralf.gommers at gmail.com  Mon May 18 16:16:31 2015
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Mon, 18 May 2015 22:16:31 +0200
Subject: [SciPy-Dev] Porting the rest of cKDTree query functions to C++
In-Reply-To: <miqh8l$jrq$1@ger.gmane.org>
References: <miqh8l$jrq$1@ger.gmane.org>
Message-ID: <CABL7CQjTzayRL9Pc+PS1CCmoUZdg8c6Nk90bMQKaK5eDFL0LUA@mail.gmail.com>

On Mon, May 11, 2015 at 5:19 PM, Sturla Molden <sturla.molden at gmail.com>
wrote:

>
> I have started the tedious work of porting the rest of cKDTree to C++.
> The structure is similar to the query method that is in C++ in the 0.16
> branch.
>
> The other methods have much more to gain from C++ than query due to
> substantially larger Python overhead. On my old laptop with AMD Phenom
> the new query method reduced the query time from 85 seconds to about 3
> seconds. The improvement in the other methods is likely to be much
> better than that.
>

That sounds promising!


> Right now I have mostly just copied out code and made placeholders for
> the C++. But the main structure is already there.
>
> It is now in this branch on Github:
>
>
> https://github.com/sturlamolden/scipy/tree/cpp_ckdtree/scipy/spatial/ckdtree
>
> (I am not sure if I should post a WIP PR or wait until it builds
> correctly so Travis does not have a heart attack.)
>

For who wants to follow this more closely:
- Enhancement issue: https://github.com/scipy/scipy/issues/4855
- PR: https://github.com/scipy/scipy/pull/4860

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

From sturla.molden at gmail.com  Mon May 18 17:37:45 2015
From: sturla.molden at gmail.com (Sturla Molden)
Date: Mon, 18 May 2015 23:37:45 +0200
Subject: [SciPy-Dev] Porting the rest of cKDTree query functions to C++
In-Reply-To: <CABL7CQjTzayRL9Pc+PS1CCmoUZdg8c6Nk90bMQKaK5eDFL0LUA@mail.gmail.com>
References: <miqh8l$jrq$1@ger.gmane.org>
	<CABL7CQjTzayRL9Pc+PS1CCmoUZdg8c6Nk90bMQKaK5eDFL0LUA@mail.gmail.com>
Message-ID: <mjdm37$8oh$1@ger.gmane.org>

On 18/05/15 22:16, Ralf Gommers wrote:

> That sounds promising!

They have more Python overhead in the Cython code, e.g. extensive use of 
Python int, set and list. So I expect a better speedup with a single 
thread. Unfortunately they are more difficult to multithread because of 
the way the code is structured. I am porting them to C++ first, and then 
the parallel processing comes next.


Sturla




From sturla.molden at gmail.com  Wed May 20 15:04:35 2015
From: sturla.molden at gmail.com (Sturla Molden)
Date: Wed, 20 May 2015 21:04:35 +0200
Subject: [SciPy-Dev] Porting the rest of cKDTree query functions to C++
In-Reply-To: <CABL7CQjTzayRL9Pc+PS1CCmoUZdg8c6Nk90bMQKaK5eDFL0LUA@mail.gmail.com>
References: <miqh8l$jrq$1@ger.gmane.org>
	<CABL7CQjTzayRL9Pc+PS1CCmoUZdg8c6Nk90bMQKaK5eDFL0LUA@mail.gmail.com>
Message-ID: <mjils2$k3n$1@ger.gmane.org>

On 18/05/15 22:16, Ralf Gommers wrote:

> For who wants to follow this more closely:
> - Enhancement issue: https://github.com/scipy/scipy/issues/4855
> - PR: https://github.com/scipy/scipy/pull/4860


More or less done now, it was easier than I anticipated.

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


Sturla



From mpapin24 at gmail.com  Thu May 21 10:13:06 2015
From: mpapin24 at gmail.com (Amadou Coulibaly)
Date: Thu, 21 May 2015 14:13:06 +0000
Subject: [SciPy-Dev] SDG
Message-ID: <CAFAUDHv5nftvvr5dcZj5FL79VBqHMbyk=MKkJLZ2CZMc9G77kw@mail.gmail.com>

Dear all,

I'm new user of python. And I wanted to do the continuous wavelet analysis
of my data. But first of all, when I tried to run the following command:

In[1]: import numpy as np

In[2]: from scipy.signal import SDG, Morlet, cwt

I got the following error messages:

---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)
<ipython-input-43-e18eb7700f8b> in <module>()
----> 1 from scipy.signal import SDG, Morlet, cwt

ImportError: cannot import name SDG


?In[3]: ?from scipy.signal import Morlet, cwt
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)
<ipython-input-44-2cf611117e43> in <module>()
----> 1 from scipy.signal import Morlet, cwt

ImportError: cannot import name Morlet

?How can I solve this issues?

Best regards?

-- 
* COULIBALY   AMADOU   *
PhD  Student  on  West  African  Climate  System (WACS)
FUTA - Federal  University  of  Technology of Akure, Nigeria

*Visiting Student - *
*University of Cologne, Germany**Institute of Geophysics and Meteorology*
Pohligstr. 3 / Office 3.102
D-50969 K?ln

*Project*: WASCAL (West African Science Service Centre on Climate Change
and Adapted Land Use)
Phone:(+234) 810 795 2836 /(+223) 65 67 27 57 /(+226) 64 57 37 27 /+49
15218352574

E-mail: mpapin24 at gmail.com / coulibalya68 at yahoo.com

"*The time is always right to do right": Nelson Mandela*

*"Character is like a tree and reputation like a shadow.  The shadow is
what we think of it; the tree is the real thing" : Abraham Lincoln*

*"Do what you can, with what you have, where you are" Theodore Roosevelt*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150521/1b77a656/attachment.html>

From warren.weckesser at gmail.com  Thu May 21 10:50:05 2015
From: warren.weckesser at gmail.com (Warren Weckesser)
Date: Thu, 21 May 2015 10:50:05 -0400
Subject: [SciPy-Dev] SDG
In-Reply-To: <CAFAUDHv5nftvvr5dcZj5FL79VBqHMbyk=MKkJLZ2CZMc9G77kw@mail.gmail.com>
References: <CAFAUDHv5nftvvr5dcZj5FL79VBqHMbyk=MKkJLZ2CZMc9G77kw@mail.gmail.com>
Message-ID: <CAGzF1ue7F175a1nNOuSTLB5zi1jgP8sZVa+cA7XYcK6z0S=e6A@mail.gmail.com>

On Thu, May 21, 2015 at 10:13 AM, Amadou Coulibaly <mpapin24 at gmail.com>
wrote:

> Dear all,
>
> I'm new user of python. And I wanted to do the continuous wavelet analysis
> of my data. But first of all, when I tried to run the following command:
>
> In[1]: import numpy as np
>
> In[2]: from scipy.signal import SDG, Morlet, cwt
>
> I got the following error messages:
>
> ---------------------------------------------------------------------------
> ImportError                               Traceback (most recent call last)
> <ipython-input-43-e18eb7700f8b> in <module>()
> ----> 1 from scipy.signal import SDG, Morlet, cwt
>
> ImportError: cannot import name SDG
>
>
> ?In[3]: ?from scipy.signal import Morlet, cwt
> ---------------------------------------------------------------------------
> ImportError                               Traceback (most recent call last)
> <ipython-input-44-2cf611117e43> in <module>()
> ----> 1 from scipy.signal import Morlet, cwt
>
> ImportError: cannot import name Morlet
>
> ?How can I solve this issues?
>
>

It looks like you are trying to use code that was described here:

    http://mail.scipy.org/pipermail/scipy-dev/2009-March/011682.html

That email describes a proposed addition to scipy, but that is not the API
that we ended up with.  For the wavelet functions in scipy, see
http://docs.scipy.org/doc/scipy/reference/signal.html#wavelets

Warren



> Best regards?
>
> --
> * COULIBALY   AMADOU   *
> PhD  Student  on  West  African  Climate  System (WACS)
> FUTA - Federal  University  of  Technology of Akure, Nigeria
>
> *Visiting Student - *
> *University of Cologne, Germany**Institute of Geophysics and Meteorology*
> Pohligstr. 3 / Office 3.102
> D-50969 K?ln
>
> *Project*: WASCAL (West African Science Service Centre on Climate Change
> and Adapted Land Use)
> Phone:(+234) 810 795 2836 /(+223) 65 67 27 57 /(+226) 64 57 37 27 /+49
> 15218352574
>
> E-mail: mpapin24 at gmail.com / coulibalya68 at yahoo.com
>
> "*The time is always right to do right": Nelson Mandela*
>
> *"Character is like a tree and reputation like a shadow.  The shadow is
> what we think of it; the tree is the real thing" : Abraham Lincoln*
>
> *"Do what you can, with what you have, where you are" Theodore Roosevelt*
>
>
>
>
>
>
> _______________________________________________
> 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/20150521/33faaf68/attachment.html>

From ralf.gommers at gmail.com  Sat May 23 15:11:25 2015
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sat, 23 May 2015 21:11:25 +0200
Subject: [SciPy-Dev] 0.16.0 release
In-Reply-To: <CABL7CQi_ufgMLrFA-U4T8Mpr9TY+z99pKKCiHqFZC2pBrMCw=w@mail.gmail.com>
References: <CABL7CQh4E4ESabrJt6J91nAYwd9QN++p5kn3dq1xv+2bxK-gVA@mail.gmail.com>
	<CAJJ-iFmMWz_Oy+e+2rxxruaafd6c1D-q5JaB=g=dFW_p4SD4=A@mail.gmail.com>
	<CABL7CQizf4e7xo04dQdvng+12ocDR+c7LGHEe9KvJ5CmFrCKyA@mail.gmail.com>
	<CABL7CQi_ufgMLrFA-U4T8Mpr9TY+z99pKKCiHqFZC2pBrMCw=w@mail.gmail.com>
Message-ID: <CABL7CQih=kaBweRTh9ROnuVJawdcN2zySwSmQ_KnYiz3Lx0YXQ@mail.gmail.com>

On Sun, Apr 26, 2015 at 4:22 PM, Ralf Gommers <ralf.gommers at gmail.com>
wrote:

>
>
> - branching 0.16.x: 10 May
> - beta 1: 12 May
> - release candidate 1: 24 May
>

Because there are still a few issues open including one blocker (the qr
updating routines) and the first beta was source-only, I'd like to do a
second beta tomorrow instead. That should allow some more testing to make
sure that there aren't any other issues with the Windows and OS X
installers.

Ralf



> - release candidate 2: 31 May (if needed)
> - final release: 7 June
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150523/eaf68fe1/attachment.html>

From moscovich at gmail.com  Sat May 23 18:40:43 2015
From: moscovich at gmail.com (Amit Moscovich Eiger)
Date: Sun, 24 May 2015 01:40:43 +0300
Subject: [SciPy-Dev] scipy.sparse.csgraph.laplacian enhancement proposal
 (random-walk normalized Laplacian)
Message-ID: <CAN9EDjS8BdFL8N6AfkCks5RvjEuwoHSoaREP-qm7Ewk-+ErtZg@mail.gmail.com>

Hi,
This is a proposal to add the functionality of computing the random-walk
normalized Laplacian matrix to the scipy.sparse.csgraph.laplacian function.

Currently this function receives the optional boolean parameter 'normed'.
If normed==False it computes the plain Laplacian matrix and if normed==True
it computes the symmetric normalized Laplacian matrix. However the
random-walk normalized Laplacian is sorely missing here (*) and may be the
best choice in some contexts (**). I propose to add the random-walk
normalized Laplacian functionality by changing the 'normed' boolean
parameter to a 'normalization' parameter, which can be one of the
following: None (default), 'symmetric' or 'randomwalk'.

The problem with this suggestion is that it breaks the interface of the
laplacian() function, though it's easy to make a backwards-compatible
interface (e.g. add the optional 'normalization' parameter in addition to
the 'normed' boolean parameter).

Two questions:
1) I'm new here. Do I just implement the feature (and relevant unit test)
and send a pull request?
2) Is it considered OK to break the interface in such cases, or should I
make it backwards-compatible?

Thanks,
Amit Moscovich Eiger.

References:
(*) For the definition of the Laplacian, symmetric normalized Laplacian and
the random-walk normalized Laplacian, see
https://en.wikipedia.org/wiki/Laplacian_matrix
(**) See section 8.5 of "A Tutorial on Spectral Clustering"
http://arxiv.org/abs/0711.0189,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150524/977e6e71/attachment.html>

From ralf.gommers at gmail.com  Sun May 24 09:15:27 2015
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sun, 24 May 2015 15:15:27 +0200
Subject: [SciPy-Dev] dropping OS X dmg installers
Message-ID: <CABL7CQhLsFT2mU8gxK4CoG-rGg6MrgF9WJjkWkZtRaY7QseiWQ@mail.gmail.com>

Hi,

When updating the build scripts and release docs for 0.16.x I realized that:
- the DMG installers haven't been built for 0.14.1 and 0.15.x
- we didn't officially decide this AFAIK, but no one complained
- the wheels we now have on pip for OS X are more general than the DMG
installers; the latter only work with python.org Python.
- wheels are also easier to build [1] and test [2] (thanks Matthew!)

So shall we make it official that we won't build any more DMG installers
for releases?

Ralf


[1] https://github.com/MacPython/scipy-wheels
[2] https://github.com/MacPython/scipy-stack-osx-testing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150524/72264d48/attachment.html>

From boyfarrell at gmail.com  Sun May 24 09:24:46 2015
From: boyfarrell at gmail.com (Daniel Farrell)
Date: Sun, 24 May 2015 14:24:46 +0100
Subject: [SciPy-Dev] dropping OS X dmg installers
In-Reply-To: <CABL7CQhLsFT2mU8gxK4CoG-rGg6MrgF9WJjkWkZtRaY7QseiWQ@mail.gmail.com>
References: <CABL7CQhLsFT2mU8gxK4CoG-rGg6MrgF9WJjkWkZtRaY7QseiWQ@mail.gmail.com>
Message-ID: <6FDD5858-A46B-4C88-8DF0-6C41CDCEEE6B@gmail.com>

Hi,

Mailing list lurker here. 

In 6 years of using Scipy on OS X I have never used the DMGs. In my opinion most users will manage there own Python stack. Using brew for the installation and using pip to manage packages. This is trivial to do these days.

Best wishes,

Dan


> On 24 May 2015, at 14:15, Ralf Gommers <ralf.gommers at gmail.com> wrote:
> 
> Hi,
> 
> When updating the build scripts and release docs for 0.16.x I realized that:
> - the DMG installers haven't been built for 0.14.1 and 0.15.x
> - we didn't officially decide this AFAIK, but no one complained
> - the wheels we now have on pip for OS X are more general than the DMG installers; the latter only work with python.org Python.
> - wheels are also easier to build [1] and test [2] (thanks Matthew!)
> 
> So shall we make it official that we won't build any more DMG installers for releases?
> 
> Ralf
> 
> 
> [1] https://github.com/MacPython/scipy-wheels
> [2] https://github.com/MacPython/scipy-stack-osx-testing
> 
> _______________________________________________
> 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/20150524/05a363d8/attachment.html>

From sturla.molden at gmail.com  Sun May 24 10:10:51 2015
From: sturla.molden at gmail.com (Sturla Molden)
Date: Sun, 24 May 2015 14:10:51 +0000 (UTC)
Subject: [SciPy-Dev] dropping OS X dmg installers
References: <CABL7CQhLsFT2mU8gxK4CoG-rGg6MrgF9WJjkWkZtRaY7QseiWQ@mail.gmail.com>
Message-ID: <1040582156454168815.158684sturla.molden-gmail.com@news.gmane.org>

DMG ans MSI installers are nice for users who are afraid of the command
line. Usually that means the vast majority, but we cannot assume that NumPy
and SciPy programmers suffer from this condition. 

There are presumably still users who just need to install Python and
NumPy/SciPy to run a program that requires them to be installed. I am not
sure how common this group is, but I would not be surprised if many of them
have problems with installing from wheels and PyPI.

That said I don't really have a stron opinion on this, so my vote would be
+/- 0. 

:-)

Making a graphical installer app for Windows and Mac would also be a
possibility. It could download and install a minimal Scipy stack from PyPI.


Sturla



Ralf Gommers <ralf.gommers at gmail.com> wrote:
> Hi,
> 
> When updating the build scripts and release docs for 0.16.x I realized that:
> - the DMG installers haven't been built for 0.14.1 and 0.15.x
> - we didn't officially decide this AFAIK, but no one complained
> - the wheels we now have on pip for OS X are more general than the DMG
> installers; the latter only work with python.org Python.
> - wheels are also easier to build [1] and test [2] (thanks Matthew!)
> 
> So shall we make it official that we won't build any more DMG installers
> for releases?
> 
> Ralf
> 
> [1] <a
> href="https://github.com/MacPython/scipy-wheels">https://github.com/MacPython/scipy-wheels</a>
> [2] <a
> href="https://github.com/MacPython/scipy-stack-osx-testing">https://github.com/MacPython/scipy-stack-osx-testing</a>
> 
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> <a
> href="http://mail.scipy.org/mailman/listinfo/scipy-dev">http://mail.scipy.org/mailman/listinfo/scipy-dev</a>



From ralf.gommers at gmail.com  Sun May 24 10:55:31 2015
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sun, 24 May 2015 16:55:31 +0200
Subject: [SciPy-Dev] ANN: Scipy 0.16.0 beta release 2
Message-ID: <CABL7CQiOy3GUN2OCo5kdAQX-=dYGMgG7n=MRr2NZk_FUUvjvpA@mail.gmail.com>

Hi all,

The second beta for Scipy 0.16.0 is now available. After beta 1 a couple of
critical issues on Windows were solved, and there are now also 32-bit
Windows binaries (along with the sources and release notes) available on
https://sourceforge.net/projects/scipy/files/scipy/0.16.0b2/.

Please try this release and report any issues on the scipy-dev mailing list.

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

From ralf.gommers at gmail.com  Sun May 24 17:29:09 2015
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sun, 24 May 2015 23:29:09 +0200
Subject: [SciPy-Dev] GSoC'15 accepted students for Scipy/Numpy
In-Reply-To: <CABL7CQhEOQ3zyXHgx+1DPBZFTM5oB2Fy3n1QTvJ_JMDeROOiJw@mail.gmail.com>
References: <CABL7CQhEOQ3zyXHgx+1DPBZFTM5oB2Fy3n1QTvJ_JMDeROOiJw@mail.gmail.com>
Message-ID: <CABL7CQjdP-0Cohd4wr8axQQN5h_fcDZSsUE_3nu-O8W+p242tA@mail.gmail.com>

Hi all,

Just a heads up to everyone who's interested in these projects: tomorrow is
the official start of the coding period. Abraham and Nikolay have already
been sending PRs for their projects (so they're ahead!):
  https://github.com/scipy/scipy/pulls/aeklant
  https://github.com/scipy/scipy/pulls/nmayorov
The momentum should be further increasing soon.

Cheers,
Ralf


On Mon, Apr 27, 2015 at 10:32 PM, Ralf Gommers <ralf.gommers at gmail.com>
wrote:

> Hi all,
>
> Google has just announced which students got accepted for this year's
> GSoC. For Scipy these are:
> - Nikolay Mayorov, "Improve nonlinear least squares minimization
> functionality in SciPy"
>   mentors: Chuck & Evgeni
> - Abraham Escalante, "SciPy: scipy.stats improvements"
>   mentor: Ralf (Evgeni is backup mentor)
>
> Furthermore, this proposal was accepted for Scikit-image:
> - Aman Singh, "Scikit-Image: rewriting scipy.ndimage to cython"
>   mentors: Jaime, Ralf & the scikit-image devs
>
> Congratulations to all of you!
>
> We had a lot of interest this year, which is great to see. GSoC
> applications are competitive, and unfortunately there are students who
> didn't make it. To those students I would say: please stay involved, and
> you're very welcome to apply again next year!
>
> Today is also the start of the "community bonding period", where the
> students aren't yet expected to start working on their project but do get
> time to further figure out how things work, interact with the community and
> ensure that they can hit the ground running on day 1 of the coding period:
> http://googlesummerofcode.blogspot.nl/2007/04/so-what-is-this-community-bonding-all.html.
>
>
> It looks like it'll be an interesting and productive summer!
>
> Cheers,
> Ralf
>
> P.S. all proposals are linked on
> https://github.com/scipy/scipy/wiki/GSoC-project-ideas#student-applications-for-2015-to-scipy-and-numpy
> for who's interested in the details.
>
> P.P.S. some students have asked to get some feedback about why they
> were/weren't accepted, in order to learn from it for a next time. Until
> today we weren't allowed to say much, but now that Google has announced the
> results I'd be happy to give some feedback - please contact me in private
> if you want.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150524/c045779b/attachment.html>

From pierre.haessig at crans.org  Mon May 25 08:02:23 2015
From: pierre.haessig at crans.org (Pierre Haessig)
Date: Mon, 25 May 2015 14:02:23 +0200
Subject: [SciPy-Dev] clarity of linprog default bounds argument
Message-ID: <55630F4F.60603@crans.org>

Hi,

I'm looking at the new `linprog` routine that has just landed in Scipy
0.15. By coincidence, it just come on time for a new problem I have to
solve these days !

While studying the signature, I found that the default argument
bounds=None is a bit confusing. Indeed, if I got it right, bounds=None
actually implies non negative variables. Is that correct ? However,
bounds=None has a clear semantic meaning of "unbounded variables".

In order to make this default choice more obvious (note that I'm not
arguing for changing this default), wouldn't it be clearer to write
`bounds=(0, None)` in the signature ?
(maybe this was discussed already ? I didn't check Github...)

best,
Pierre


From matthew.brett at gmail.com  Mon May 25 10:42:52 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 25 May 2015 07:42:52 -0700
Subject: [SciPy-Dev] dropping OS X dmg installers
In-Reply-To: <1040582156454168815.158684sturla.molden-gmail.com@news.gmane.org>
References: <CABL7CQhLsFT2mU8gxK4CoG-rGg6MrgF9WJjkWkZtRaY7QseiWQ@mail.gmail.com>
	<1040582156454168815.158684sturla.molden-gmail.com@news.gmane.org>
Message-ID: <CAH6Pt5o6f8BjeKqwViREztrHovUHaVHQZ_qv20=cnZ0rzsJkPg@mail.gmail.com>

Ralf - yes, please let's drop the current dmg installers.  As built, they
unconditionally write over the scipy installation for the Python.org
Python, and as you point out, they only work for Python.org Python.

Sturla - I actually did write a DMG installer that uses wheels and pip -
see http://fullmonty.github.io/ and
https://github.com/matthew-brett/wheels2dmg . It installs the scipy stack.
I don't know whether it would really be worth doing that just for scipy
(just for numpy?  just for matplotlib?).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150525/b228a4a8/attachment.html>

From sturla.molden at gmail.com  Mon May 25 13:18:53 2015
From: sturla.molden at gmail.com (Sturla Molden)
Date: Mon, 25 May 2015 17:18:53 +0000 (UTC)
Subject: [SciPy-Dev] dropping OS X dmg installers
References: <CABL7CQhLsFT2mU8gxK4CoG-rGg6MrgF9WJjkWkZtRaY7QseiWQ@mail.gmail.com>
	<1040582156454168815.158684sturla.molden-gmail.com@news.gmane.org>
	<CAH6Pt5o6f8BjeKqwViREztrHovUHaVHQZ_qv20=cnZ0rzsJkPg@mail.gmail.com>
Message-ID: <534085700454266911.564115sturla.molden-gmail.com@news.gmane.org>

Matthew Brett <matthew.brett at gmail.com> wrote:

> Sturla - I actually did write a DMG installer that uses wheels and pip -
> see <a href="http://fullmonty.github.io/">http://fullmonty.github.io/</a> and
> <a
> href="https://github.com/matthew-brett/wheels2dmg">https://github.com/matthew-brett/wheels2dmg</a>
> . It installs the scipy stack.
> I don't know whether it would really be worth doing that just for scipy
> (just for numpy?  just for matplotlib?).

Probably not worth it for just SciPy, a Scipy stack would be is better.

Sturla



From jaime.frio at gmail.com  Mon May 25 15:37:29 2015
From: jaime.frio at gmail.com (=?UTF-8?Q?Jaime_Fern=C3=A1ndez_del_R=C3=ADo?=)
Date: Mon, 25 May 2015 12:37:29 -0700
Subject: [SciPy-Dev] Repository for GSoC project
Message-ID: <CAPOWHW=Sagi-f7NH=rBjbtnRHHs5Tjn+=OTMxt9DrgtMUzvH_Q@mail.gmail.com>

Hi all,

This year I am mentoring Aman for one of the GSoC projects we have
underway, "Rewriting ndimage in Cython." By its very nature it doesn't
conform very well to the "many small pull requests" model: from the point
of view of scipy, things are going to be broken up until almost the very
last commit. I am not sure what the best way to set up a collaborative code
development environment would be, and so am asking for the collective
wisdom to help guide us.

Aman could simply create one ginormous pull request that will grow, and
grow, and not be merged until everything was ready. I don't like this idea
too much, as it is going to eventually be a confusing mess, and I think it
would also make it difficult for others than Aman (that would mostly be me)
to contribute code.

I think we could also use a branch, either on my fork of scipy or on
Aman's, as the repository on which development would happen, and against
which PRs would be created, and once completed send a single PR to the main
scipy repo. This may work, but I don't like it much either.

What probably makes more sense is to create a new branch **in the main
scipy repository**, and have PRs sent and merged against that branch, which
would eventually be merged with master upon completion. NumPy seems to have
a couple such experimental branches ('with_maskna' and
'enable_separate_by_default'), although there is none in SciPy that I see.
This would also allow us to keep the project in a controlled environment,
even if by the end of the summer not every single bit of ndimage has been
ported.

If this third path is really the preferred way of doing things, I could
probably set things up myself (Ralf gave me commit rights when I became a
mentor for this project), but I'd like to hear what others think, before
abusing my powers.

Thanks!

Jaime

-- 
(\__/)
( O.o)
( > <) Este es Conejo. Copia a Conejo en tu firma y ay?dale en sus planes
de dominaci?n mundial.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150525/e125c357/attachment.html>

From josef.pktd at gmail.com  Mon May 25 16:10:21 2015
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Mon, 25 May 2015 16:10:21 -0400
Subject: [SciPy-Dev] Repository for GSoC project
In-Reply-To: <CAPOWHW=Sagi-f7NH=rBjbtnRHHs5Tjn+=OTMxt9DrgtMUzvH_Q@mail.gmail.com>
References: <CAPOWHW=Sagi-f7NH=rBjbtnRHHs5Tjn+=OTMxt9DrgtMUzvH_Q@mail.gmail.com>
Message-ID: <CAMMTP+C15ORxKAqsQMw6jVnZ8r1GHEm3eog+RSPE+6N7gJK6pg@mail.gmail.com>

On Mon, May 25, 2015 at 3:37 PM, Jaime Fern?ndez del R?o <
jaime.frio at gmail.com> wrote:

> Hi all,
>
> This year I am mentoring Aman for one of the GSoC projects we have
> underway, "Rewriting ndimage in Cython." By its very nature it doesn't
> conform very well to the "many small pull requests" model: from the point
> of view of scipy, things are going to be broken up until almost the very
> last commit. I am not sure what the best way to set up a collaborative code
> development environment would be, and so am asking for the collective
> wisdom to help guide us.
>
> Aman could simply create one ginormous pull request that will grow, and
> grow, and not be merged until everything was ready. I don't like this idea
> too much, as it is going to eventually be a confusing mess, and I think it
> would also make it difficult for others than Aman (that would mostly be me)
> to contribute code.
>
> I think we could also use a branch, either on my fork of scipy or on
> Aman's, as the repository on which development would happen, and against
> which PRs would be created, and once completed send a single PR to the main
> scipy repo. This may work, but I don't like it much either.
>
> What probably makes more sense is to create a new branch **in the main
> scipy repository**, and have PRs sent and merged against that branch, which
> would eventually be merged with master upon completion. NumPy seems to have
> a couple such experimental branches ('with_maskna' and
> 'enable_separate_by_default'), although there is none in SciPy that I see.
> This would also allow us to keep the project in a controlled environment,
> even if by the end of the summer not every single bit of ndimage has been
> ported.
>
> If this third path is really the preferred way of doing things, I could
> probably set things up myself (Ralf gave me commit rights when I became a
> mentor for this project), but I'd like to hear what others think, before
> abusing my powers.
>



I don't see much difference between options two and three for working with
github since it''s easy to create and merge pull requests across forks.

One consideration is whether you want to trigger the TravisCI runs, which I
guess would be automatic with a branch in the main scipy repo.

Another consideration is whether this triggers a large amount of
notifications for scipy developers that are subscribed to changes, PRs and
issues. (and if it's easy for me to filter those out visually in gmail)

In statsmodels all the extra branches in the main repo are stale or stalled
and are waiting for someone to pick up. Actual development is in developer
forks.

(I'm not involved enough in scipy development to have an opinion.)

Josef


>
> Thanks!
>
> Jaime
>
> --
> (\__/)
> ( O.o)
> ( > <) Este es Conejo. Copia a Conejo en tu firma y ay?dale en sus planes
> de dominaci?n mundial.
>
> _______________________________________________
> 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/20150525/36700b04/attachment.html>

From gael.varoquaux at normalesup.org  Mon May 25 16:15:57 2015
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Mon, 25 May 2015 22:15:57 +0200
Subject: [SciPy-Dev] Repository for GSoC project
In-Reply-To: <CAMMTP+C15ORxKAqsQMw6jVnZ8r1GHEm3eog+RSPE+6N7gJK6pg@mail.gmail.com>
References: <CAPOWHW=Sagi-f7NH=rBjbtnRHHs5Tjn+=OTMxt9DrgtMUzvH_Q@mail.gmail.com>
	<CAMMTP+C15ORxKAqsQMw6jVnZ8r1GHEm3eog+RSPE+6N7gJK6pg@mail.gmail.com>
Message-ID: <20150525201557.GJ3487255@phare.normalesup.org>

I would strongly advocate not waiting for a full rewrite to try to
integrate the code. I would strongly push to identify the easiest places
to rewrite and to try to get code merged for these ASAP.

In my experience of project management, this is just a better way of
doing things. It helps identifying problems early. It helps breaking down
the contribution into something reviewable. It helps making sure that
everybody is on the same page.

My 2 euro cents,

Ga?l

On Mon, May 25, 2015 at 04:10:21PM -0400, josef.pktd at gmail.com wrote:


> On Mon, May 25, 2015 at 3:37 PM, Jaime Fern?ndez del R?o <jaime.frio at gmail.com>
> wrote:

>     Hi all,

>     This year I am mentoring Aman for one of the GSoC projects we have
>     underway, "Rewriting ndimage in Cython." By its very nature it doesn't
>     conform very well to the "many small pull requests" model: from the point
>     of view of scipy, things are going to be broken up until almost the very
>     last commit. I am not sure what the best way to set up a collaborative code
>     development environment would be, and so am asking for the collective
>     wisdom to help guide us.

>     Aman could simply create one ginormous pull request that will grow, and
>     grow, and not be merged until everything was ready. I don't like this idea
>     too much, as it is going to eventually be a confusing mess, and I think it
>     would also make it difficult for others than Aman (that would mostly be me)
>     to contribute code.

>     I think we could also use a branch, either on my fork of scipy or on
>     Aman's, as the repository on which development would happen, and against
>     which PRs would be created, and once completed send a single PR to the main
>     scipy repo. This may work, but I don't like it much either.

>     What probably makes more sense is to create a new branch **in the main
>     scipy repository**, and have PRs sent and merged against that branch, which
>     would eventually be merged with master upon completion. NumPy seems to have
>     a couple such experimental branches ('with_maskna' and
>     'enable_separate_by_default'), although there is none in SciPy that I see.
>     This would also allow us to keep the project in a controlled environment,
>     even if by the end of the summer not every single bit of ndimage has been
>     ported.

>     If this third path is really the preferred way of doing things, I could
>     probably set things up myself (Ralf gave me commit rights when I became a
>     mentor for this project), but I'd like to hear what others think, before
>     abusing my powers.




> I don't see much difference between options two and three for working with
> github since it''s easy to create and merge pull requests across forks.

> One consideration is whether you want to trigger the TravisCI runs, which I
> guess would be automatic with a branch in the main scipy repo.

> Another consideration is whether this triggers a large amount of notifications
> for scipy developers that are subscribed to changes, PRs and issues. (and if
> it's easy for me to filter those out visually in gmail)

> In statsmodels all the extra branches in the main repo are stale or stalled and
> are waiting for someone to pick up. Actual development is in developer forks.

> (I'm not involved enough in scipy development to have an opinion.)

> Josef
> ?


>     Thanks!

>     Jaime
-- 
    Gael Varoquaux
    Researcher, INRIA Parietal
    NeuroSpin/CEA Saclay , Bat 145, 91191 Gif-sur-Yvette France
    Phone:  ++ 33-1-69-08-79-68
    http://gael-varoquaux.info            http://twitter.com/GaelVaroquaux


From gidden at wisc.edu  Mon May 25 16:21:55 2015
From: gidden at wisc.edu (Matthew Gidden)
Date: Mon, 25 May 2015 15:21:55 -0500
Subject: [SciPy-Dev] Repository for GSoC project
In-Reply-To: <CAMMTP+C15ORxKAqsQMw6jVnZ8r1GHEm3eog+RSPE+6N7gJK6pg@mail.gmail.com>
References: <CAPOWHW=Sagi-f7NH=rBjbtnRHHs5Tjn+=OTMxt9DrgtMUzvH_Q@mail.gmail.com>
	<CAMMTP+C15ORxKAqsQMw6jVnZ8r1GHEm3eog+RSPE+6N7gJK6pg@mail.gmail.com>
Message-ID: <CAHRdPFwxKUsFiq+iKd5_gaijUaqYkqQjan+3tEQV5iD0OiQvkQ@mail.gmail.com>

Hi all,

Long time list lurker, thought I might chime in on this topic quickly --

On Mon, May 25, 2015 at 3:10 PM, <josef.pktd at gmail.com> wrote:

>
>
> On Mon, May 25, 2015 at 3:37 PM, Jaime Fern?ndez del R?o <
> jaime.frio at gmail.com> wrote:
>
>> Hi all,
>>
>> This year I am mentoring Aman for one of the GSoC projects we have
>> underway, "Rewriting ndimage in Cython." By its very nature it doesn't
>> conform very well to the "many small pull requests" model: from the point
>> of view of scipy, things are going to be broken up until almost the very
>> last commit. I am not sure what the best way to set up a collaborative code
>> development environment would be, and so am asking for the collective
>> wisdom to help guide us.
>>
>> Aman could simply create one ginormous pull request that will grow, and
>> grow, and not be merged until everything was ready. I don't like this idea
>> too much, as it is going to eventually be a confusing mess, and I think it
>> would also make it difficult for others than Aman (that would mostly be me)
>> to contribute code.
>>
>> I think we could also use a branch, either on my fork of scipy or on
>> Aman's, as the repository on which development would happen, and against
>> which PRs would be created, and once completed send a single PR to the main
>> scipy repo. This may work, but I don't like it much either.
>>
>> What probably makes more sense is to create a new branch **in the main
>> scipy repository**, and have PRs sent and merged against that branch, which
>> would eventually be merged with master upon completion. NumPy seems to have
>> a couple such experimental branches ('with_maskna' and
>> 'enable_separate_by_default'), although there is none in SciPy that I see.
>> This would also allow us to keep the project in a controlled environment,
>> even if by the end of the summer not every single bit of ndimage has been
>> ported.
>>
>> If this third path is really the preferred way of doing things, I could
>> probably set things up myself (Ralf gave me commit rights when I became a
>> mentor for this project), but I'd like to hear what others think, before
>> abusing my powers.
>>
>
>
>
> I don't see much difference between options two and three for working with
> github since it''s easy to create and merge pull requests across forks.
>
> One consideration is whether you want to trigger the TravisCI runs, which
> I guess would be automatic with a branch in the main scipy repo.
>
I think involving CI is a nice (who doesn't love seeing the green check
mark?). Since scipy already has all of the Travis plumbing, Jaime or Aman
could develop on a branch and push to their respective fork after having
"turned on" (they use the term "flick on") that branch on Travis.

This strategy would remove scipy list notifications while leveraging the
usefulness of CI. The only issue is that if the work is restricted to
Aman/Jaime's forks, then PR reviewing would likely have fewer eyes until
the final PR into scipy.

Just a thought,
Matt

>
> Another consideration is whether this triggers a large amount of
> notifications for scipy developers that are subscribed to changes, PRs and
> issues. (and if it's easy for me to filter those out visually in gmail)
>
> In statsmodels all the extra branches in the main repo are stale or
> stalled and are waiting for someone to pick up. Actual development is in
> developer forks.
>
> (I'm not involved enough in scipy development to have an opinion.)
>
> Josef
>
>
>>
>> Thanks!
>>
>> Jaime
>>
>> --
>> (\__/)
>> ( O.o)
>> ( > <) Este es Conejo. Copia a Conejo en tu firma y ay?dale en sus planes
>> de dominaci?n mundial.
>>
>> _______________________________________________
>> 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
>
>


-- 
Matthew Gidden, Ph.D.
Postdoctoral Associate, Nuclear Engineering
The University of Wisconsin -- Madison
Ph. 225.892.3192
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150525/906fb719/attachment.html>

From jaime.frio at gmail.com  Mon May 25 16:58:24 2015
From: jaime.frio at gmail.com (=?UTF-8?Q?Jaime_Fern=C3=A1ndez_del_R=C3=ADo?=)
Date: Mon, 25 May 2015 13:58:24 -0700
Subject: [SciPy-Dev] Repository for GSoC project
In-Reply-To: <20150525201557.GJ3487255@phare.normalesup.org>
References: <CAPOWHW=Sagi-f7NH=rBjbtnRHHs5Tjn+=OTMxt9DrgtMUzvH_Q@mail.gmail.com>
	<CAMMTP+C15ORxKAqsQMw6jVnZ8r1GHEm3eog+RSPE+6N7gJK6pg@mail.gmail.com>
	<20150525201557.GJ3487255@phare.normalesup.org>
Message-ID: <CAPOWHW=m-6URrU9fb9kvWs8NVRzOdQhAiU7tmZuQXHm1DMO1Ww@mail.gmail.com>

On Mon, May 25, 2015 at 1:15 PM, Gael Varoquaux <
gael.varoquaux at normalesup.org> wrote:

> I would strongly advocate not waiting for a full rewrite to try to
> integrate the code. I would strongly push to identify the easiest places
> to rewrite and to try to get code merged for these ASAP.
>

That may be hard for ndimage, let me explain the rationale...

ndimage is arranged in three or four layers:

   1. there's a Python layer,
   2. which calls on Python functions written in C,
   3. which calls on C functions,
   4. which use a few low level C "objects", which also have some hierarchy
   among them.

We could simply start translating at level 2, and make our way down to
level 4. Once completed, the stated goal of rewriting ndimage in Cython
would have been achieved, but I am afraid that it wouldn't help at all with
the improving maintainability goal: levels 3 and 4 above are a mess of
poorly documented code, with little regard for separation of concerns, and
that is not going to be solved by translating the same code structure to
another language.

The plan we are trying to follow is:

   1. Start at level 4, rewriting the lowest of the lowest C "objects."
   This will include not just translating to Cython, but better encapsulation
   of internal functionality, and providing a cleaner API for upstream use.
   2. As soon as enough work has been done at level 4 that it can be
   bubbled all the way up to level 1, go ahead with the bubbling up, for 1 or
   2 level 1 functions at most.
   3. Validate that things are working correctly, benchmark against the
   current implementation, adapt as needed.
   4. Go back to step 1, and keep working on level 4 rewriting, until there
   is a new chance to bubble the changes up.
   5. Eventually, once level 4 has been completely rewritten, a more
   up-down approach can probably be followed.

So in a way we are indeed going to try to integrate things ASAP, only soon
is going to be later than one may otherwise expect.

Now that I have explained it in writing, I guess we could try to follow
this approach directly in the current ndimage repository, keeping the old
code path alive until it was no longer needed...

Jaime

-- 
(\__/)
( O.o)
( > <) Este es Conejo. Copia a Conejo en tu firma y ay?dale en sus planes
de dominaci?n mundial.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150525/635f08d5/attachment.html>

From jaime.frio at gmail.com  Mon May 25 17:10:46 2015
From: jaime.frio at gmail.com (=?UTF-8?Q?Jaime_Fern=C3=A1ndez_del_R=C3=ADo?=)
Date: Mon, 25 May 2015 14:10:46 -0700
Subject: [SciPy-Dev] Repository for GSoC project
In-Reply-To: <CAMMTP+C15ORxKAqsQMw6jVnZ8r1GHEm3eog+RSPE+6N7gJK6pg@mail.gmail.com>
References: <CAPOWHW=Sagi-f7NH=rBjbtnRHHs5Tjn+=OTMxt9DrgtMUzvH_Q@mail.gmail.com>
	<CAMMTP+C15ORxKAqsQMw6jVnZ8r1GHEm3eog+RSPE+6N7gJK6pg@mail.gmail.com>
Message-ID: <CAPOWHWk0VF2ey8_qc3p_-C-CCo9hCL23fumTcY5ZEbZ7wjxcpw@mail.gmail.com>

On Mon, May 25, 2015 at 1:10 PM, <josef.pktd at gmail.com> wrote:

>
>
> On Mon, May 25, 2015 at 3:37 PM, Jaime Fern?ndez del R?o <
> jaime.frio at gmail.com> wrote:
>
>> Hi all,
>>
>> This year I am mentoring Aman for one of the GSoC projects we have
>> underway, "Rewriting ndimage in Cython." By its very nature it doesn't
>> conform very well to the "many small pull requests" model: from the point
>> of view of scipy, things are going to be broken up until almost the very
>> last commit. I am not sure what the best way to set up a collaborative code
>> development environment would be, and so am asking for the collective
>> wisdom to help guide us.
>>
>> Aman could simply create one ginormous pull request that will grow, and
>> grow, and not be merged until everything was ready. I don't like this idea
>> too much, as it is going to eventually be a confusing mess, and I think it
>> would also make it difficult for others than Aman (that would mostly be me)
>> to contribute code.
>>
>> I think we could also use a branch, either on my fork of scipy or on
>> Aman's, as the repository on which development would happen, and against
>> which PRs would be created, and once completed send a single PR to the main
>> scipy repo. This may work, but I don't like it much either.
>>
>> What probably makes more sense is to create a new branch **in the main
>> scipy repository**, and have PRs sent and merged against that branch, which
>> would eventually be merged with master upon completion. NumPy seems to have
>> a couple such experimental branches ('with_maskna' and
>> 'enable_separate_by_default'), although there is none in SciPy that I see.
>> This would also allow us to keep the project in a controlled environment,
>> even if by the end of the summer not every single bit of ndimage has been
>> ported.
>>
>> If this third path is really the preferred way of doing things, I could
>> probably set things up myself (Ralf gave me commit rights when I became a
>> mentor for this project), but I'd like to hear what others think, before
>> abusing my powers.
>>
>
>
>
> I don't see much difference between options two and three for working with
> github since it''s easy to create and merge pull requests across forks.
>
> One consideration is whether you want to trigger the TravisCI runs, which
> I guess would be automatic with a branch in the main scipy repo.
>
> Another consideration is whether this triggers a large amount of
> notifications for scipy developers that are subscribed to changes, PRs and
> issues. (and if it's easy for me to filter those out visually in gmail)
>

I understand the concern: I am myself often baffled by the amount of e-mail
from the scipy repo that I delete without reading. That said, what you sign
up for when you sign up to the SciPy github repo is to receive all
notifications related to that repo, which does include ndimage... And I
don't think that the fact that these changes will be part of GSoC warrants
treating them in a special way. Also, given the volume of mail that SciPy
already generates, this will probably be lost like tears in the rain
anyway...

As a more general thing, it may make sense to come up with three letter
acronyms for each of the scipy submodules, and ask that PRs identify the
submodule(s) they affect as part of the title. I certainly have no problem
in requiring that every PR in this project has `[NDI]` for `ndimage` as
part of the description, e.g. "[NDI] ENH: blah, blah, blah..."

Jaime


>
> In statsmodels all the extra branches in the main repo are stale or
> stalled and are waiting for someone to pick up. Actual development is in
> developer forks.
>
> (I'm not involved enough in scipy development to have an opinion.)
>
> Josef
>
>
>>
>> Thanks!
>>
>> Jaime
>>
>> --
>> (\__/)
>> ( O.o)
>> ( > <) Este es Conejo. Copia a Conejo en tu firma y ay?dale en sus planes
>> de dominaci?n mundial.
>>
>> _______________________________________________
>> 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
>
>


-- 
(\__/)
( O.o)
( > <) Este es Conejo. Copia a Conejo en tu firma y ay?dale en sus planes
de dominaci?n mundial.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150525/f32e454e/attachment.html>

From ralf.gommers at gmail.com  Mon May 25 17:55:15 2015
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Mon, 25 May 2015 23:55:15 +0200
Subject: [SciPy-Dev] Repository for GSoC project
In-Reply-To: <CAPOWHWk0VF2ey8_qc3p_-C-CCo9hCL23fumTcY5ZEbZ7wjxcpw@mail.gmail.com>
References: <CAPOWHW=Sagi-f7NH=rBjbtnRHHs5Tjn+=OTMxt9DrgtMUzvH_Q@mail.gmail.com>
	<CAMMTP+C15ORxKAqsQMw6jVnZ8r1GHEm3eog+RSPE+6N7gJK6pg@mail.gmail.com>
	<CAPOWHWk0VF2ey8_qc3p_-C-CCo9hCL23fumTcY5ZEbZ7wjxcpw@mail.gmail.com>
Message-ID: <CABL7CQiMmNS=44Bk2r38dniFh+11FjAGQhOMoiMqudBQOTSVhg@mail.gmail.com>

On Mon, May 25, 2015 at 11:10 PM, Jaime Fern?ndez del R?o <
jaime.frio at gmail.com> wrote:

> On Mon, May 25, 2015 at 1:10 PM, <josef.pktd at gmail.com> wrote:
>
>>
>>
>> On Mon, May 25, 2015 at 3:37 PM, Jaime Fern?ndez del R?o <
>> jaime.frio at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> This year I am mentoring Aman for one of the GSoC projects we have
>>> underway, "Rewriting ndimage in Cython." By its very nature it doesn't
>>> conform very well to the "many small pull requests" model: from the point
>>> of view of scipy, things are going to be broken up until almost the very
>>> last commit. I am not sure what the best way to set up a collaborative code
>>> development environment would be, and so am asking for the collective
>>> wisdom to help guide us.
>>>
>>> Aman could simply create one ginormous pull request that will grow, and
>>> grow, and not be merged until everything was ready. I don't like this idea
>>> too much, as it is going to eventually be a confusing mess, and I think it
>>> would also make it difficult for others than Aman (that would mostly be me)
>>> to contribute code.
>>>
>>
This is the worst option I think; it's very hard to keep track of what's
already reviewed in an open PR.


>
>>> I think we could also use a branch, either on my fork of scipy or on
>>> Aman's, as the repository on which development would happen, and against
>>> which PRs would be created, and once completed send a single PR to the main
>>> scipy repo. This may work, but I don't like it much either.
>>>
>>> What probably makes more sense is to create a new branch **in the main
>>> scipy repository**, and have PRs sent and merged against that branch, which
>>> would eventually be merged with master upon completion. NumPy seems to have
>>> a couple such experimental branches ('with_maskna' and
>>> 'enable_separate_by_default'), although there is none in SciPy that I see.
>>> This would also allow us to keep the project in a controlled environment,
>>> even if by the end of the summer not every single bit of ndimage has been
>>> ported.
>>>
>>
I'm not a fan of topic branches in the scipy repo, but given the nature of
the rewrite it's probably the best alternative. So fine with me.


>>> If this third path is really the preferred way of doing things, I could
>>> probably set things up myself (Ralf gave me commit rights when I became a
>>> mentor for this project),
>>>
>>
That's what I get for forgetting to send the announcement in time:) Not
just me by the way - decided on by all active core devs.


> but I'd like to hear what others think, before abusing my powers.
>>>
>>
>>
>>
>> I don't see much difference between options two and three for working
>> with github since it''s easy to create and merge pull requests across forks.
>>
>> One consideration is whether you want to trigger the TravisCI runs, which
>> I guess would be automatic with a branch in the main scipy repo.
>>
>> Another consideration is whether this triggers a large amount of
>> notifications for scipy developers that are subscribed to changes, PRs and
>> issues. (and if it's easy for me to filter those out visually in gmail)
>>
>
> I understand the concern: I am myself often baffled by the amount of
> e-mail from the scipy repo that I delete without reading. That said, what
> you sign up for when you sign up to the SciPy github repo is to receive all
> notifications related to that repo, which does include ndimage... And I
> don't think that the fact that these changes will be part of GSoC warrants
> treating them in a special way. Also, given the volume of mail that SciPy
> already generates, this will probably be lost like tears in the rain
> anyway...
>
> As a more general thing, it may make sense to come up with three letter
> acronyms for each of the scipy submodules, and ask that PRs identify the
> submodule(s) they affect as part of the title. I certainly have no problem
> in requiring that every PR in this project has `[NDI]` for `ndimage` as
> part of the description, e.g. "[NDI] ENH: blah, blah, blah..."
>

No reason not to type the module name out in full, and I'd like to keep the
standard prefixes at the front. So I'd be more in favor of "ENH: ndimage:
...". I actually already do that sometimes.

Ralf



> Jaime
>
>
>>
>> In statsmodels all the extra branches in the main repo are stale or
>> stalled and are waiting for someone to pick up. Actual development is in
>> developer forks.
>>
>> (I'm not involved enough in scipy development to have an opinion.)
>>
>> Josef
>>
>>
>>>
>>> Thanks!
>>>
>>> Jaime
>>>
>>> --
>>> (\__/)
>>> ( O.o)
>>> ( > <) Este es Conejo. Copia a Conejo en tu firma y ay?dale en sus
>>> planes de dominaci?n mundial.
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
>
> --
> (\__/)
> ( O.o)
> ( > <) Este es Conejo. Copia a Conejo en tu firma y ay?dale en sus planes
> de dominaci?n mundial.
>
> _______________________________________________
> 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/20150525/d0f061f6/attachment.html>

From ralf.gommers at gmail.com  Mon May 25 18:11:42 2015
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Tue, 26 May 2015 00:11:42 +0200
Subject: [SciPy-Dev] welcome Jaime and Anne to the Scipy core team
Message-ID: <CABL7CQjr6PZ9TCxgJ7Shepcf_iF9NbO7AUvngoB6wVGV0kwRfA@mail.gmail.com>

Hi all,

On behalf of the Scipy developers I'd like to welcome Jaime Fernandez del
Rio and Anne Archibald as members of the Scipy core team. Jaime has been
making improvements to mainly ndimage over the last year and will be
mentoring Aman's GSoC project on ndimage. Anne used to have svn commit
rights and made lots of improvements in scipy.spatial and scipy.interpolate
in 2008/2009 - it's great to have her contributing again.

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

From ralf.gommers at gmail.com  Mon May 25 18:22:04 2015
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Tue, 26 May 2015 00:22:04 +0200
Subject: [SciPy-Dev] dropping OS X dmg installers
In-Reply-To: <CAH6Pt5o6f8BjeKqwViREztrHovUHaVHQZ_qv20=cnZ0rzsJkPg@mail.gmail.com>
References: <CABL7CQhLsFT2mU8gxK4CoG-rGg6MrgF9WJjkWkZtRaY7QseiWQ@mail.gmail.com>
	<1040582156454168815.158684sturla.molden-gmail.com@news.gmane.org>
	<CAH6Pt5o6f8BjeKqwViREztrHovUHaVHQZ_qv20=cnZ0rzsJkPg@mail.gmail.com>
Message-ID: <CABL7CQixJ-j-faXSXCAj1boDGAezo0f55dZ-3=cBtSGHMRBHXg@mail.gmail.com>

On Mon, May 25, 2015 at 4:42 PM, Matthew Brett <matthew.brett at gmail.com>
wrote:

> Ralf - yes, please let's drop the current dmg installers.  As built, they
> unconditionally write over the scipy installation for the Python.org
> Python, and as you point out, they only work for Python.org Python.
>

Okay, I'll keep the build scripts for now but won't build any for a release
and will update the HOWTO_RELEASE document to not mention them anymore.

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

From njs at pobox.com  Mon May 25 19:09:30 2015
From: njs at pobox.com (Nathaniel Smith)
Date: Mon, 25 May 2015 16:09:30 -0700
Subject: [SciPy-Dev] Repository for GSoC project
In-Reply-To: <CAPOWHW=Sagi-f7NH=rBjbtnRHHs5Tjn+=OTMxt9DrgtMUzvH_Q@mail.gmail.com>
References: <CAPOWHW=Sagi-f7NH=rBjbtnRHHs5Tjn+=OTMxt9DrgtMUzvH_Q@mail.gmail.com>
Message-ID: <CAPJVwBnvyEcR1QztpF7uV+Rbn2KtH_tZumd_Mh5YuDgYZ70Fig@mail.gmail.com>

On Mon, May 25, 2015 at 12:37 PM, Jaime Fern?ndez del R?o
<jaime.frio at gmail.com> wrote:
> Hi all,
>
> This year I am mentoring Aman for one of the GSoC projects we have underway,
> "Rewriting ndimage in Cython." By its very nature it doesn't conform very
> well to the "many small pull requests" model: from the point of view of
> scipy, things are going to be broken up until almost the very last commit.

If it isn't viable to incrementally replace the current module
in-place (which would normally be my suggestion if at all
possible...), then one alternative approach might be to create a
temporary module named _ndimage2 or something, with the idea that for
now it does not provide everything that ndimage does, but whatever it
does provide works. And that way one can review and merge complete,
tested feature-addition PRs into _ndimage2 until it reaches feature
parity with ndimage, at which point the last PR is just to swap the
names.

(Of course this is orthogonal to the question of where exactly the
branch lives.)

-n

-- 
Nathaniel J. Smith -- http://vorpus.org


From charlesr.harris at gmail.com  Mon May 25 21:26:33 2015
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Mon, 25 May 2015 19:26:33 -0600
Subject: [SciPy-Dev] welcome Jaime and Anne to the Scipy core team
In-Reply-To: <CABL7CQjr6PZ9TCxgJ7Shepcf_iF9NbO7AUvngoB6wVGV0kwRfA@mail.gmail.com>
References: <CABL7CQjr6PZ9TCxgJ7Shepcf_iF9NbO7AUvngoB6wVGV0kwRfA@mail.gmail.com>
Message-ID: <CAB6mnxKts49iYurroz5mHJmTV9fa=3s2LobNWJxG5wO1UgSWVg@mail.gmail.com>

On Mon, May 25, 2015 at 4:11 PM, Ralf Gommers <ralf.gommers at gmail.com>
wrote:

> Hi all,
>
> On behalf of the Scipy developers I'd like to welcome Jaime Fernandez del
> Rio and Anne Archibald as members of the Scipy core team. Jaime has been
> making improvements to mainly ndimage over the last year and will be
> mentoring Aman's GSoC project on ndimage. Anne used to have svn commit
> rights and made lots of improvements in scipy.spatial and scipy.interpolate
> in 2008/2009 - it's great to have her contributing again.
>

Anne founded scipy.spacial, so she did more than improve it :)
Congratulations to both, and it is good to see Anne back.

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

From jaime.frio at gmail.com  Tue May 26 12:00:12 2015
From: jaime.frio at gmail.com (=?UTF-8?Q?Jaime_Fern=C3=A1ndez_del_R=C3=ADo?=)
Date: Tue, 26 May 2015 09:00:12 -0700
Subject: [SciPy-Dev] Repository for GSoC project
In-Reply-To: <78b496db-c70c-4a16-97a8-fa9115716280@googlegroups.com>
References: <CAPOWHW=Sagi-f7NH=rBjbtnRHHs5Tjn+=OTMxt9DrgtMUzvH_Q@mail.gmail.com>
	<78b496db-c70c-4a16-97a8-fa9115716280@googlegroups.com>
Message-ID: <CAPOWHW=iZDNjBSGTMMPSfri36wSRXyiVf7SkfQBMmqdYG-h4Rw@mail.gmail.com>

Thanks everyone for the feedback. After some more thinking, I have asked
Aman to start sending PRs directly against the current master of scipy.

To differentiate new from old implementations, we'll probably just prepend
all file names with "ndi_" instead of the current "ni_". We will eventually
start removing old functionality that has been replaced, but for quite
sometime they will both coexist. This means that at some point in time,
e.g. calling `ndimage.filters.uniform_filter1d` may use the new Cython code
paths, while `ndimage.filters.minimum_filter1d` may still be using the old
C code paths.

We will not merge anything, answering Juan's question, until we have tests
that validate that functionality. That does not mean that the functionality
will be available to end users just yet, e.g. we may merge an iterator
before any top level function that uses it. But if it does not have tests,
it does not get merged.

If anyone has a very strong opinion against this approach, please speak up
now!

Jaime

-- 
(\__/)
( O.o)
( > <) Este es Conejo. Copia a Conejo en tu firma y ay?dale en sus planes
de dominaci?n mundial.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150526/c3cbbecd/attachment.html>

From archibald at astron.nl  Tue May 26 12:19:45 2015
From: archibald at astron.nl (Anne Archibald)
Date: Tue, 26 May 2015 16:19:45 +0000
Subject: [SciPy-Dev] welcome Jaime and Anne to the Scipy core team
In-Reply-To: <CAB6mnxKts49iYurroz5mHJmTV9fa=3s2LobNWJxG5wO1UgSWVg@mail.gmail.com>
References: <CABL7CQjr6PZ9TCxgJ7Shepcf_iF9NbO7AUvngoB6wVGV0kwRfA@mail.gmail.com>
	<CAB6mnxKts49iYurroz5mHJmTV9fa=3s2LobNWJxG5wO1UgSWVg@mail.gmail.com>
Message-ID: <CANm_+Zo=RSEdhjr4XihCj_KU2nggB5b1J+8jq2bfQ9i=1oDUOw@mail.gmail.com>

Thanks, everyone! I don't know how much time and energy I can contribute,
but I am claiming scipy contributions as "knowledge utilization" on a grant
proposal, so I guess if I get the grant it becomes part of my job
requirements. Not to mention I use scipy and need it to work well!

Anne

On Tue, May 26, 2015, 03:26 Charles R Harris <charlesr.harris at gmail.com>
wrote:

> On Mon, May 25, 2015 at 4:11 PM, Ralf Gommers <ralf.gommers at gmail.com>
> wrote:
>
>> Hi all,
>>
>> On behalf of the Scipy developers I'd like to welcome Jaime Fernandez
>> del Rio and Anne Archibald as members of the Scipy core team. Jaime has
>> been making improvements to mainly ndimage over the last year and will be
>> mentoring Aman's GSoC project on ndimage. Anne used to have svn commit
>> rights and made lots of improvements in scipy.spatial and scipy.interpolate
>> in 2008/2009 - it's great to have her contributing again.
>>
>
> Anne founded scipy.spacial, so she did more than improve it :)
> Congratulations to both, and it is good to see Anne back.
>
> Chuck
>
> _______________________________________________
> 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/20150526/c92a9823/attachment.html>

From aeklant at gmail.com  Tue May 26 17:46:57 2015
From: aeklant at gmail.com (Abraham Escalante)
Date: Tue, 26 May 2015 16:46:57 -0500
Subject: [SciPy-Dev] `ss` and `square_of_sums` deprecation from `scipy.stats`
Message-ID: <CAJJ-iFmLPZJqe3TM3=MmcW-HkcJ0kkYv0oNCh6qS-i-fmuz-ig@mail.gmail.com>

Hello all,

As part of StatisticsCleanup milestone `scipy.stats.ss` and
`scipy.stats.square_of_sums` are to be deprecated. These are helper
functions that were not meant to be exposed to users but we know for a fact
that they are being used by some people, therefore we cannot just remove
them from the API so we are going to put them through a normal deprecation
period.

If there are any objections to the deprecation of these functions, now
would be a good time to speak up.

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

From aeklant at gmail.com  Wed May 27 12:08:13 2015
From: aeklant at gmail.com (Abraham Escalante)
Date: Wed, 27 May 2015 11:08:13 -0500
Subject: [SciPy-Dev] `ss` and `square_of_sums` deprecation from
	`scipy.stats`
In-Reply-To: <CAJJ-iFmLPZJqe3TM3=MmcW-HkcJ0kkYv0oNCh6qS-i-fmuz-ig@mail.gmail.com>
References: <CAJJ-iFmLPZJqe3TM3=MmcW-HkcJ0kkYv0oNCh6qS-i-fmuz-ig@mail.gmail.com>
Message-ID: <CAJJ-iFm9Nu3uriVCeJjRro7q0rkeobL=v2eAOJcr2KHPVcFyRw@mail.gmail.com>

You can find the corresponding PR here:

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

Regards,
Abraham.

2015-05-26 16:46 GMT-05:00 Abraham Escalante <aeklant at gmail.com>:

> Hello all,
>
> As part of StatisticsCleanup milestone `scipy.stats.ss` and
> `scipy.stats.square_of_sums` are to be deprecated. These are helper
> functions that were not meant to be exposed to users but we know for a fact
> that they are being used by some people, therefore we cannot just remove
> them from the API so we are going to put them through a normal deprecation
> period.
>
> If there are any objections to the deprecation of these functions, now
> would be a good time to speak up.
>
> Cheers,
> Abraham.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150527/7077db7c/attachment.html>

From jaime.frio at gmail.com  Wed May 27 13:57:37 2015
From: jaime.frio at gmail.com (=?UTF-8?Q?Jaime_Fern=C3=A1ndez_del_R=C3=ADo?=)
Date: Wed, 27 May 2015 10:57:37 -0700
Subject: [SciPy-Dev] [ndimage-gsoc2015] Weekly Summary 2015/05/25
Message-ID: <CAPOWHWmPVkUsBoJf9vyoeY3w-u_URSkVromXQh0SQ_zLuhn6uw@mail.gmail.com>

Hi all,

Aman and I had our first weekly sync meeting yesterday. After each of these
weekly calls, I have asked Aman to publish a short summary, just like this
one, on progress to date and plans for the week. If you would like to
participate on one of these weekly meetings, just let us know.

*Design Choices*

   1. Use the NumPy iterator (numpy.flatiter in Python or PyArrayIterObject
   in C) for all basic array iteration, rather than a custom implementation as
   ndimage currently does.

*Plan for the week*

   1. Learn to use the NumPy iterator in Cython properly.
   2. Send a first pull request against ndimage that:
      1. Provides supporting Cython code for basic array iteration.
      2. Translates an ndimage function that only requires basic iteration,
      to Cython. This will probably be find_objects from the measurements
      submodule.
   3. Document the progress in a blog post.

*Deliverables from last week*

   1. None yet.

Best,

Jaime

-- 
(\__/)
( O.o)
( > <) Este es Conejo. Copia a Conejo en tu firma y ay?dale en sus planes
de dominaci?n mundial.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150527/1e136dbd/attachment.html>

From sturla.molden at gmail.com  Wed May 27 19:27:21 2015
From: sturla.molden at gmail.com (Sturla Molden)
Date: Wed, 27 May 2015 23:27:21 +0000 (UTC)
Subject: [SciPy-Dev] Repository for GSoC project
References: <CAPOWHW=Sagi-f7NH=rBjbtnRHHs5Tjn+=OTMxt9DrgtMUzvH_Q@mail.gmail.com>
	<CAMMTP+C15ORxKAqsQMw6jVnZ8r1GHEm3eog+RSPE+6N7gJK6pg@mail.gmail.com>
	<20150525201557.GJ3487255@phare.normalesup.org>
	<CAPOWHW=m-6URrU9fb9kvWs8NVRzOdQhAiU7tmZuQXHm1DMO1Ww@mail.gmail.com>
Message-ID: <119495510454461683.224376sturla.molden-gmail.com@news.gmane.org>

Jaime Fern?ndez del R?o <jaime.frio at gmail.com> wrote:
 
> ndimage is arranged in three or four layers:
> 
>    1. there's a Python layer,
>    2. which calls on Python functions written in C,
>    3. which calls on C functions,
>    4. which use a few low level C "objects", which also have some hierarchy
>    among them.
 
> The plan we are trying to follow is:
> 
>    1. Start at level 4, rewriting the lowest of the lowest C "objects."
>    This will include not just translating to Cython, but better encapsulation
>    of internal functionality, and providing a cleaner API for upstream use.

o_O 

How shall I say this in a polite way?

"If this was an exam, I would have brought down the hammer and failed you."

But that is not very polite, so perhaps this:

"Please reconsider?"



Sturla



From sturla.molden at gmail.com  Wed May 27 19:33:45 2015
From: sturla.molden at gmail.com (Sturla Molden)
Date: Wed, 27 May 2015 23:33:45 +0000 (UTC)
Subject: [SciPy-Dev] Repository for GSoC project
References: <CAPOWHW=Sagi-f7NH=rBjbtnRHHs5Tjn+=OTMxt9DrgtMUzvH_Q@mail.gmail.com>
	<CAMMTP+C15ORxKAqsQMw6jVnZ8r1GHEm3eog+RSPE+6N7gJK6pg@mail.gmail.com>
	<20150525201557.GJ3487255@phare.normalesup.org>
Message-ID: <225575716454462167.958824sturla.molden-gmail.com@news.gmane.org>

Gael Varoquaux <gael.varoquaux at normalesup.org> wrote:

> I would strongly advocate not waiting for a full rewrite to try to
> integrate the code. I would strongly push to identify the easiest places
> to rewrite and to try to get code merged for these ASAP.

Yes, this.

Code that will not build until the very last commit stands a chance of
never being completed. And even worse, there will be no feedback along the
way.

Sturla



From aidan at brightcloud.com  Wed May 27 20:48:43 2015
From: aidan at brightcloud.com (Aidan Macdonald)
Date: Wed, 27 May 2015 17:48:43 -0700
Subject: [SciPy-Dev] Out of Core Sparse Matrices
Message-ID: <CAJGH0fHu_3BZrZ=d3EN=TeCR81uki35-uACfdwzEGyBvBVn6Jw@mail.gmail.com>

Hi,

I work for Brightcloud and part of my work required me to write Out of Core
Sparse Matrices. I was thinking of submitting these to Scipy as it
currently has Sparse Matrices, but not out of core.

I was wondering if this code would be a desired addition to SciPy. Also,
currently it uses the Python Sqlite3 library. Is it okay to use the Sqlite3
package?

Could I also get documentation about writing test cases? I notice that you
use NOSE. It there any specification about integrating my test cases into
SciPy. I would only need a simple modification to the existing sparse test
cases.

Thank you,

Aidan Macdonald
aidan at brightcloud.com
aidan.plenert.macdonald at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150527/8d08048e/attachment.html>

From shoyer at gmail.com  Thu May 28 02:13:38 2015
From: shoyer at gmail.com (Stephan Hoyer)
Date: Wed, 27 May 2015 23:13:38 -0700
Subject: [SciPy-Dev] Out of Core Sparse Matrices
In-Reply-To: <CAJGH0fHu_3BZrZ=d3EN=TeCR81uki35-uACfdwzEGyBvBVn6Jw@mail.gmail.com>
References: <CAJGH0fHu_3BZrZ=d3EN=TeCR81uki35-uACfdwzEGyBvBVn6Jw@mail.gmail.com>
Message-ID: <CAEQ_TvfHHF-QxbY=VuC8mfYCch4brt_Lh_t0srXdU6W2bux0-A@mail.gmail.com>

Hi Aidan,

You should talk to Matthew Rocklin, author of dask. It's a very promising
project implementing out of core arrays compatible with the scientific
Python stack:
http://dask.pydata.org

It currently doesn't do sparse matrices, but that could be a pretty
straightforward extension (possibly building on your work):
https://github.com/ContinuumIO/dask/issues/174

Cheers,
Stephan




On Wed, May 27, 2015 at 5:48 PM, Aidan Macdonald <aidan at brightcloud.com>
wrote:

> Hi,
>
> I work for Brightcloud and part of my work required me to write Out of
> Core Sparse Matrices. I was thinking of submitting these to Scipy as it
> currently has Sparse Matrices, but not out of core.
>
> I was wondering if this code would be a desired addition to SciPy. Also,
> currently it uses the Python Sqlite3 library. Is it okay to use the Sqlite3
> package?
>
> Could I also get documentation about writing test cases? I notice that you
> use NOSE. It there any specification about integrating my test cases into
> SciPy. I would only need a simple modification to the existing sparse test
> cases.
>
> Thank you,
>
> Aidan Macdonald
> aidan at brightcloud.com
> aidan.plenert.macdonald at gmail.com
>
> _______________________________________________
> 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/20150527/3fe671af/attachment.html>

From ralf.gommers at gmail.com  Thu May 28 02:22:49 2015
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Thu, 28 May 2015 08:22:49 +0200
Subject: [SciPy-Dev] Out of Core Sparse Matrices
In-Reply-To: <CAJGH0fHu_3BZrZ=d3EN=TeCR81uki35-uACfdwzEGyBvBVn6Jw@mail.gmail.com>
References: <CAJGH0fHu_3BZrZ=d3EN=TeCR81uki35-uACfdwzEGyBvBVn6Jw@mail.gmail.com>
Message-ID: <CABL7CQhaibnVvrMxbnvABYare7ZwgS0ry_F1-+erwOwyayOagg@mail.gmail.com>

Hi Aidan,

On Thu, May 28, 2015 at 2:48 AM, Aidan Macdonald <aidan at brightcloud.com>
wrote:

> Hi,
>
> I work for Brightcloud and part of my work required me to write Out of
> Core Sparse Matrices. I was thinking of submitting these to Scipy as it
> currently has Sparse Matrices, but not out of core.
>

That's beyond the current scope of Scipy, so we'd have to seriously think
about it. Is the API built on or similar to scipy.sparse? Do you have your
code already somewhere public, so we can have a look at it.


> I was wondering if this code would be a desired addition to SciPy. Also,
> currently it uses the Python Sqlite3 library. Is it okay to use the Sqlite3
> package?
>

Anything in the Python stdlib is OK to use in Scipy from the point of view
of dependencies. So it depends on performance and other technical aspects
like maintainability/scalability only.


> Could I also get documentation about writing test cases? I notice that you
> use NOSE. It there any specification about integrating my test cases into
> SciPy. I would only need a simple modification to the existing sparse test
> cases.
>

The testing guidelines are at
https://github.com/numpy/numpy/blob/master/doc/TESTS.rst.txt.

Cheers,
Ralf



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

From njs at pobox.com  Thu May 28 02:25:12 2015
From: njs at pobox.com (Nathaniel Smith)
Date: Wed, 27 May 2015 23:25:12 -0700
Subject: [SciPy-Dev] Out of Core Sparse Matrices
In-Reply-To: <CAJGH0fHu_3BZrZ=d3EN=TeCR81uki35-uACfdwzEGyBvBVn6Jw@mail.gmail.com>
References: <CAJGH0fHu_3BZrZ=d3EN=TeCR81uki35-uACfdwzEGyBvBVn6Jw@mail.gmail.com>
Message-ID: <CAPJVwBnaHVzi0C_PYAbd34412joKBEEERxB7j2ErNFhLOXi1vA@mail.gmail.com>

On Wed, May 27, 2015 at 5:48 PM, Aidan Macdonald <aidan at brightcloud.com> wrote:
>
> Hi,
>
> I work for Brightcloud and part of my work required me to write Out of Core Sparse Matrices. I was thinking of submitting these to Scipy as it currently has Sparse Matrices, but not out of core.
>
> I was wondering if this code would be a desired addition to SciPy. Also, currently it uses the Python Sqlite3 library. Is it okay to use the Sqlite3 package?

Hi Aidan,

I think we'd be able to give you better advice/suggestions if you
could give us a pointer to the code and/or docs, to get a sense of
what kind of general approach, public API, dependencies, etc. that
you're talking about?

-n

-- 
Nathaniel J. Smith -- http://vorpus.org


From ralf.gommers at gmail.com  Thu May 28 02:28:04 2015
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Thu, 28 May 2015 08:28:04 +0200
Subject: [SciPy-Dev] Repository for GSoC project
In-Reply-To: <119495510454461683.224376sturla.molden-gmail.com@news.gmane.org>
References: <CAPOWHW=Sagi-f7NH=rBjbtnRHHs5Tjn+=OTMxt9DrgtMUzvH_Q@mail.gmail.com>
	<CAMMTP+C15ORxKAqsQMw6jVnZ8r1GHEm3eog+RSPE+6N7gJK6pg@mail.gmail.com>
	<20150525201557.GJ3487255@phare.normalesup.org>
	<CAPOWHW=m-6URrU9fb9kvWs8NVRzOdQhAiU7tmZuQXHm1DMO1Ww@mail.gmail.com>
	<119495510454461683.224376sturla.molden-gmail.com@news.gmane.org>
Message-ID: <CABL7CQihVig=9ZeY786bEZzg1L-GxhQoASOLo8K2ZqtjOaxwNw@mail.gmail.com>

On Thu, May 28, 2015 at 1:27 AM, Sturla Molden <sturla.molden at gmail.com>
wrote:

> Jaime Fern?ndez del R?o <jaime.frio at gmail.com> wrote:
>
> > ndimage is arranged in three or four layers:
> >
> >    1. there's a Python layer,
> >    2. which calls on Python functions written in C,
> >    3. which calls on C functions,
> >    4. which use a few low level C "objects", which also have some
> hierarchy
> >    among them.
>
> > The plan we are trying to follow is:
> >
> >    1. Start at level 4, rewriting the lowest of the lowest C "objects."
> >    This will include not just translating to Cython, but better
> encapsulation
> >    of internal functionality, and providing a cleaner API for upstream
> use.
>
> o_O
>
> How shall I say this in a polite way?
>
> "If this was an exam, I would have brought down the hammer and failed you."
>
> But that is not very polite, so perhaps this:
>
> "Please reconsider?"


You're only quoting part of the approach. The next sentence was "As soon as
enough work has been done at level 4 that it can be bubbled all the way up
to level 1, go ahead with the bubbling up, for 1 or 2 level 1 functions at
most."

Building some of the needed low-level infrastructure and then going
straight for re-implementing a first public function in Cython seems like
the right approach. It's not like you can do much in ndimage without any of
the existing iterators. So replacing those with usage of standard iterators
in numpy makes sense.

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

From ralf.gommers at gmail.com  Thu May 28 02:34:30 2015
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Thu, 28 May 2015 08:34:30 +0200
Subject: [SciPy-Dev] Repository for GSoC project
In-Reply-To: <CAPOWHW=iZDNjBSGTMMPSfri36wSRXyiVf7SkfQBMmqdYG-h4Rw@mail.gmail.com>
References: <CAPOWHW=Sagi-f7NH=rBjbtnRHHs5Tjn+=OTMxt9DrgtMUzvH_Q@mail.gmail.com>
	<78b496db-c70c-4a16-97a8-fa9115716280@googlegroups.com>
	<CAPOWHW=iZDNjBSGTMMPSfri36wSRXyiVf7SkfQBMmqdYG-h4Rw@mail.gmail.com>
Message-ID: <CABL7CQiqHHwqAraCrGhYTneVGBLQnZjhB35v54esNpR2A=7jQg@mail.gmail.com>

On Tue, May 26, 2015 at 6:00 PM, Jaime Fern?ndez del R?o <
jaime.frio at gmail.com> wrote:

>
> You received this message because you are subscribed to the Google Groups
> "scikit-image" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to scikit-image+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> Thanks everyone for the feedback. After some more thinking, I have asked
> Aman to start sending PRs directly against the current master of scipy.
>
> To differentiate new from old implementations, we'll probably just prepend
> all file names with "ndi_" instead of the current "ni_". We will eventually
> start removing old functionality that has been replaced, but for quite
> sometime they will both coexist. This means that at some point in time,
> e.g. calling `ndimage.filters.uniform_filter1d` may use the new Cython code
> paths, while `ndimage.filters.minimum_filter1d` may still be using the old
> C code paths.
>
> We will not merge anything, answering Juan's question, until we have tests
> that validate that functionality. That does not mean that the functionality
> will be available to end users just yet, e.g. we may merge an iterator
> before any top level function that uses it. But if it does not have tests,
> it does not get merged.
>
> If anyone has a very strong opinion against this approach, please speak up
> now!
>

I like this. If you can keep old and new implementations side by side, it
could even be a good idea to have an easy mechanism (clearly marked as
temporary and only for testing) for users to switch between the two so they
can test their own code with the new routines before those become the
default.

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

From jtaylor.debian at googlemail.com  Thu May 28 08:46:00 2015
From: jtaylor.debian at googlemail.com (Julian Taylor)
Date: Thu, 28 May 2015 14:46:00 +0200
Subject: [SciPy-Dev] Verify your sourceforge windows installer downloads
Message-ID: <CAK5FAtEJMj0ZhTRdG9aVHWM8KjpmYJNFDVVWHF4cbSHW7Gj=1g@mail.gmail.com>

hi,
It has been reported that sourceforge has taken over the gimp
unofficial windows downloader page and temporarily bundled the
installer with unauthorized adware:
https://plus.google.com/+gimp/posts/cxhB1PScFpe

As NumPy is also distributing windows installers via sourceforge I
recommend that when you download the files you verify the downloads
via the checksums in the README.txt before using them. The README.txt
is clearsigned with my gpg key so it should be safe from tampering.
Unfortunately as I don't use windows I cannot give any advice on how
to do the verifcation on these platforms. Maybe someone familar with
available tools can chime in.

I have checked the numpy downloads and they still match what I
uploaded, but as sourceforge does redirect based on OS and geolocation
this may not mean much.

Cheers,
Julian Taylor


From cournape at gmail.com  Thu May 28 09:35:55 2015
From: cournape at gmail.com (David Cournapeau)
Date: Thu, 28 May 2015 22:35:55 +0900
Subject: [SciPy-Dev] [Numpy-discussion] Verify your sourceforge windows
	installer downloads
In-Reply-To: <CAK5FAtEJMj0ZhTRdG9aVHWM8KjpmYJNFDVVWHF4cbSHW7Gj=1g@mail.gmail.com>
References: <CAK5FAtEJMj0ZhTRdG9aVHWM8KjpmYJNFDVVWHF4cbSHW7Gj=1g@mail.gmail.com>
Message-ID: <CAGY4rcX15Jn+JvmQghKWrVKXUYjDcp2A88k2QUfT36dc6=6n2w@mail.gmail.com>

IMO, this really begs the question on whether we still want to use
sourceforge at all. At this point I just don't trust the service at all
anymore.

Could we use some resources (e.g. rackspace ?) to host those files ? Do we
know how much traffic they get so estimate the cost ?

David

On Thu, May 28, 2015 at 9:46 PM, Julian Taylor <
jtaylor.debian at googlemail.com> wrote:

> hi,
> It has been reported that sourceforge has taken over the gimp
> unofficial windows downloader page and temporarily bundled the
> installer with unauthorized adware:
> https://plus.google.com/+gimp/posts/cxhB1PScFpe
>
> As NumPy is also distributing windows installers via sourceforge I
> recommend that when you download the files you verify the downloads
> via the checksums in the README.txt before using them. The README.txt
> is clearsigned with my gpg key so it should be safe from tampering.
> Unfortunately as I don't use windows I cannot give any advice on how
> to do the verifcation on these platforms. Maybe someone familar with
> available tools can chime in.
>
> I have checked the numpy downloads and they still match what I
> uploaded, but as sourceforge does redirect based on OS and geolocation
> this may not mean much.
>
> Cheers,
> Julian Taylor
> _______________________________________________
> 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/20150528/8d105745/attachment.html>

From aidan at brightcloud.com  Thu May 28 10:07:45 2015
From: aidan at brightcloud.com (Aidan Macdonald)
Date: Thu, 28 May 2015 07:07:45 -0700
Subject: [SciPy-Dev] Out of Core Sparse Matrices
In-Reply-To: <CAPJVwBnaHVzi0C_PYAbd34412joKBEEERxB7j2ErNFhLOXi1vA@mail.gmail.com>
References: <CAJGH0fHu_3BZrZ=d3EN=TeCR81uki35-uACfdwzEGyBvBVn6Jw@mail.gmail.com>
	<CAPJVwBnaHVzi0C_PYAbd34412joKBEEERxB7j2ErNFhLOXi1vA@mail.gmail.com>
Message-ID: <CAJGH0fGWdUCVUQyAJtAOFL5Ph3uPZeSF6UeSqkVOP_kEm9tdAQ@mail.gmail.com>

Hi,

I push one piece of the code here
<https://github.com/aidan-plenert-macdonald/scipy/tree/master/scipy/dsparse>.
It is the PYX file. Stephan Hoyer recommended that I push this into he Dask
project. I looked at their code and it looks like it is more of what my
work is. I think I will talk with him. My company is looking at building a
good distributed computing framework for big data machine learning
purposes. Most of the old code is in C++, but I am porting it over into
Python for better maintainability.

As seen in the code, I simply use the SciPy existing source for the
dok_matrix (easier than rewriting one) and provide an out of core
dictionary using Sqlite. I am looking into not using Sqlite and doing a
sort of memmap interface as that is what our C++ would do, but I am unsure
of the speed/complexity/maintainability benefit.

At the end of the day, all the SciPy sparse matrix tests should work with
minimal changes (adding file names). It is PYX because I was compiling with
Cython. There is currently minimal speed gain from compilation, but I was
going to go through and optimize later.

Thank you,

Aidan Macdonald
805 418 0174
aidan at brightcloud.com
aidan.plenert.macdonald at gmail.com

On Wed, May 27, 2015 at 11:25 PM, Nathaniel Smith <njs at pobox.com> wrote:

> On Wed, May 27, 2015 at 5:48 PM, Aidan Macdonald <aidan at brightcloud.com>
> wrote:
> >
> > Hi,
> >
> > I work for Brightcloud and part of my work required me to write Out of
> Core Sparse Matrices. I was thinking of submitting these to Scipy as it
> currently has Sparse Matrices, but not out of core.
> >
> > I was wondering if this code would be a desired addition to SciPy. Also,
> currently it uses the Python Sqlite3 library. Is it okay to use the Sqlite3
> package?
>
> Hi Aidan,
>
> I think we'd be able to give you better advice/suggestions if you
> could give us a pointer to the code and/or docs, to get a sense of
> what kind of general approach, public API, dependencies, etc. that
> you're talking about?
>
> -n
>
> --
> Nathaniel J. Smith -- http://vorpus.org
> _______________________________________________
> 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/20150528/feb03597/attachment.html>

From benny.malengier at gmail.com  Thu May 28 10:37:36 2015
From: benny.malengier at gmail.com (Benny Malengier)
Date: Thu, 28 May 2015 16:37:36 +0200
Subject: [SciPy-Dev] [Numpy-discussion] Verify your sourceforge windows
 installer downloads
In-Reply-To: <CAGY4rcX15Jn+JvmQghKWrVKXUYjDcp2A88k2QUfT36dc6=6n2w@mail.gmail.com>
References: <CAK5FAtEJMj0ZhTRdG9aVHWM8KjpmYJNFDVVWHF4cbSHW7Gj=1g@mail.gmail.com>
	<CAGY4rcX15Jn+JvmQghKWrVKXUYjDcp2A88k2QUfT36dc6=6n2w@mail.gmail.com>
Message-ID: <CAOyNq8qL1m3QqSk0GDt02B2_ska++yjTbAmUUshMs3aS0+fR1g@mail.gmail.com>

Actually,

they way I understand it, you should stay on SF, then they don't take
over your project so as to 'help your userbase'.

So, if you don't use SF anymore for your downloads, then they make an
SF mirror of your project, and add their wrapper installer. Which is
what happened to Gimp.
As long as you use SF yourself to keep your downloads current, they
don't interfere.

Benny

2015-05-28 15:35 GMT+02:00 David Cournapeau <cournape at gmail.com>:
> IMO, this really begs the question on whether we still want to use
> sourceforge at all. At this point I just don't trust the service at all
> anymore.
>
> Could we use some resources (e.g. rackspace ?) to host those files ? Do we
> know how much traffic they get so estimate the cost ?
>
> David
>
> On Thu, May 28, 2015 at 9:46 PM, Julian Taylor
> <jtaylor.debian at googlemail.com> wrote:
>>
>> hi,
>> It has been reported that sourceforge has taken over the gimp
>> unofficial windows downloader page and temporarily bundled the
>> installer with unauthorized adware:
>> https://plus.google.com/+gimp/posts/cxhB1PScFpe
>>
>> As NumPy is also distributing windows installers via sourceforge I
>> recommend that when you download the files you verify the downloads
>> via the checksums in the README.txt before using them. The README.txt
>> is clearsigned with my gpg key so it should be safe from tampering.
>> Unfortunately as I don't use windows I cannot give any advice on how
>> to do the verifcation on these platforms. Maybe someone familar with
>> available tools can chime in.
>>
>> I have checked the numpy downloads and they still match what I
>> uploaded, but as sourceforge does redirect based on OS and geolocation
>> this may not mean much.
>>
>> Cheers,
>> Julian Taylor
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From sturla.molden at gmail.com  Thu May 28 10:44:07 2015
From: sturla.molden at gmail.com (Sturla Molden)
Date: Thu, 28 May 2015 14:44:07 +0000 (UTC)
Subject: [SciPy-Dev] [Numpy-discussion] Verify your sourceforge windows
	installer downloads
References: <CAK5FAtEJMj0ZhTRdG9aVHWM8KjpmYJNFDVVWHF4cbSHW7Gj=1g@mail.gmail.com>
	<CAGY4rcX15Jn+JvmQghKWrVKXUYjDcp2A88k2QUfT36dc6=6n2w@mail.gmail.com>
	<CAOyNq8qL1m3QqSk0GDt02B2_ska++yjTbAmUUshMs3aS0+fR1g@mail.gmail.com>
Message-ID: <2052159189454516956.268392sturla.molden-gmail.com@news.gmane.org>

Benny Malengier <benny.malengier at gmail.com> wrote:
> Actually,
> 
> they way I understand it, you should stay on SF, then they don't take
> over your project so as to 'help your userbase'.
> 
> So, if you don't use SF anymore for your downloads, then they make an
> SF mirror of your project, and add their wrapper installer. Which is
> what happened to Gimp.
> As long as you use SF yourself to keep your downloads current, they
> don't interfere.

Please explain why this is not a covert protection scam, because I
cannot...


Sturla



From benny.malengier at gmail.com  Thu May 28 11:02:33 2015
From: benny.malengier at gmail.com (Benny Malengier)
Date: Thu, 28 May 2015 17:02:33 +0200
Subject: [SciPy-Dev] [Numpy-discussion] Verify your sourceforge windows
 installer downloads
In-Reply-To: <2052159189454516956.268392sturla.molden-gmail.com@news.gmane.org>
References: <CAK5FAtEJMj0ZhTRdG9aVHWM8KjpmYJNFDVVWHF4cbSHW7Gj=1g@mail.gmail.com>
	<CAGY4rcX15Jn+JvmQghKWrVKXUYjDcp2A88k2QUfT36dc6=6n2w@mail.gmail.com>
	<CAOyNq8qL1m3QqSk0GDt02B2_ska++yjTbAmUUshMs3aS0+fR1g@mail.gmail.com>
	<2052159189454516956.268392sturla.molden-gmail.com@news.gmane.org>
Message-ID: <CAOyNq8qBB99jaMX2MCD3v09+b4vG=WoYoskriSOcYmx-HvStKw@mail.gmail.com>

2015-05-28 16:44 GMT+02:00 Sturla Molden <sturla.molden at gmail.com>:
> Benny Malengier <benny.malengier at gmail.com> wrote:
>> Actually,
>>
>> they way I understand it, you should stay on SF, then they don't take
>> over your project so as to 'help your userbase'.
>>
>> So, if you don't use SF anymore for your downloads, then they make an
>> SF mirror of your project, and add their wrapper installer. Which is
>> what happened to Gimp.
>> As long as you use SF yourself to keep your downloads current, they
>> don't interfere.
>
> Please explain why this is not a covert protection scam, because I
> cannot...

It is of course a scam. I moved all my stuff to github for hosting 6
months ago when the writing was on the wall.

I just want to point out they do not take over your project if you
still use SF as a mirror. Gimp used their own mirror, so SF was only
for historical data (old downloads). So SF still had costs, but no
longer relevant traffic driving their webadvert income. There is a
business case to be made that somehow the servers must be paid.

What SF must do is allow to completely delete a project. And what OSS
must do is trademark their name, so that if SF makes a download
wrapper, you can sue them for using your name. Does that run with our
counter our licence?

The problem here is bad reputation for scipy/numpy due to SF. Our
license is badly equiped to fight that one way or the other. As admin
of the Gramps project, we have scammers just copying our software and
selling it or offering it with a wrapper installer. And that is GPL
licensed. Not much we can do, selling is allowed, and they don't
change the sourcecode. But it does not feel right because they use
your reputation to trick people. Trademark seems the only way out, but
even then you would need lawyers to enforce it, ... and Debian would
be protesting like with firefox.

Benny

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


From toddrjen at gmail.com  Thu May 28 11:10:26 2015
From: toddrjen at gmail.com (Todd)
Date: Thu, 28 May 2015 17:10:26 +0200
Subject: [SciPy-Dev] [Numpy-discussion] Verify your sourceforge windows
 installer downloads
In-Reply-To: <CAOyNq8qBB99jaMX2MCD3v09+b4vG=WoYoskriSOcYmx-HvStKw@mail.gmail.com>
References: <CAK5FAtEJMj0ZhTRdG9aVHWM8KjpmYJNFDVVWHF4cbSHW7Gj=1g@mail.gmail.com>
	<CAGY4rcX15Jn+JvmQghKWrVKXUYjDcp2A88k2QUfT36dc6=6n2w@mail.gmail.com>
	<CAOyNq8qL1m3QqSk0GDt02B2_ska++yjTbAmUUshMs3aS0+fR1g@mail.gmail.com>
	<2052159189454516956.268392sturla.molden-gmail.com@news.gmane.org>
	<CAOyNq8qBB99jaMX2MCD3v09+b4vG=WoYoskriSOcYmx-HvStKw@mail.gmail.com>
Message-ID: <CAFpSVpJPEGOGoT7DxCcTGeT1Bg2E27+PSznao_=Jn7QehkY7sg@mail.gmail.com>

On Thu, May 28, 2015 at 5:02 PM, Benny Malengier <benny.malengier at gmail.com>
wrote:

> 2015-05-28 16:44 GMT+02:00 Sturla Molden <sturla.molden at gmail.com>:
> > Benny Malengier <benny.malengier at gmail.com> wrote:
> >> Actually,
> >>
> >> they way I understand it, you should stay on SF, then they don't take
> >> over your project so as to 'help your userbase'.
> >>
> >> So, if you don't use SF anymore for your downloads, then they make an
> >> SF mirror of your project, and add their wrapper installer. Which is
> >> what happened to Gimp.
> >> As long as you use SF yourself to keep your downloads current, they
> >> don't interfere.
> >
> > Please explain why this is not a covert protection scam, because I
> > cannot...
>
> It is of course a scam. I moved all my stuff to github for hosting 6
> months ago when the writing was on the wall.
>
> I just want to point out they do not take over your project if you
> still use SF as a mirror. Gimp used their own mirror, so SF was only
> for historical data (old downloads). So SF still had costs, but no
> longer relevant traffic driving their webadvert income. There is a
> business case to be made that somehow the servers must be paid.
>
> What SF must do is allow to completely delete a project. And what OSS
> must do is trademark their name, so that if SF makes a download
> wrapper, you can sue them for using your name. Does that run with our
> counter our licence?
>
> The problem here is bad reputation for scipy/numpy due to SF. Our
> license is badly equiped to fight that one way or the other. As admin
> of the Gramps project, we have scammers just copying our software and
> selling it or offering it with a wrapper installer. And that is GPL
> licensed. Not much we can do, selling is allowed, and they don't
> change the sourcecode. But it does not feel right because they use
> your reputation to trick people. Trademark seems the only way out, but
> even then you would need lawyers to enforce it, ... and Debian would
> be protesting like with firefox.
>
>
The situation with debian and firefox is more complex than just having a
trademark.  Lots of open-source projects use trademark protection. But
Mozilla puts more conditions on the usage of its trademarks than, say, KDE,
Gnome or Python.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150528/1a45080b/attachment.html>

From cournape at gmail.com  Thu May 28 13:05:57 2015
From: cournape at gmail.com (David Cournapeau)
Date: Fri, 29 May 2015 02:05:57 +0900
Subject: [SciPy-Dev] [Numpy-discussion] Verify your sourceforge windows
	installer downloads
In-Reply-To: <CALmrCV3k1b3cGzOVCDdMFMy9bBHXMdbAR=SWxstsazTUHf6beQ@mail.gmail.com>
References: <CAK5FAtEJMj0ZhTRdG9aVHWM8KjpmYJNFDVVWHF4cbSHW7Gj=1g@mail.gmail.com>
	<CAGY4rcX15Jn+JvmQghKWrVKXUYjDcp2A88k2QUfT36dc6=6n2w@mail.gmail.com>
	<31698217454514411.075227sturla.molden-gmail.com@news.gmane.org>
	<CALmrCV3k1b3cGzOVCDdMFMy9bBHXMdbAR=SWxstsazTUHf6beQ@mail.gmail.com>
Message-ID: <CAGY4rcXuE_AbZsCLWsTnFv4=LrpUzoeVR=8dVz1+_Sh1sGNrPg@mail.gmail.com>

On Fri, May 29, 2015 at 2:00 AM, Andrew Collette <andrew.collette at gmail.com>
wrote:

> > Here is their lame excuse:
> >
> >
> https://sourceforge.net/blog/gimp-win-project-wasnt-hijacked-just-abandoned/
> >
> > It probably means this:
> >
> > If NumPy installers are moved away from Sourceforge, they will set up a
> > mirror and load the mirrored installers with all sorts of crapware. It is
> > some sort of racket the mob couldn't do better.
>
> I noticed that like most BSD-licensed software, NumPy's license
> includes this clause:
>
> "Neither the name of the NumPy Developers nor the names of any
> contributors may be used to endorse or promote products derived from
> this software without specific prior written permission."
>
> There's an argument to be made that SF isn't legally permitted to
> distribute poisoned installers under the name "NumPy" without
> permission.  I recall a similar dust-up a while ago about "Standard
> Markdown" using the name "Markdown"; the original author (John Gruber)
> took action and got them to change the name.
>
> In any case I've always been surprised that NumPy is distributed
> through SourceForge, which has been sketchy for years now. Could it
> simply be hosted on PyPI?
>

They don't accept arbitrary binaries like SF does, and some of our
installer formats can't be uploaded there.

David


>
> Andrew
> _______________________________________________
> 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/20150529/aba8656e/attachment.html>

From cimrman3 at ntc.zcu.cz  Fri May 29 11:24:22 2015
From: cimrman3 at ntc.zcu.cz (Robert Cimrman)
Date: Fri, 29 May 2015 17:24:22 +0200
Subject: [SciPy-Dev] ANN: SfePy 2015.2
Message-ID: <556884A6.1010600@ntc.zcu.cz>

I am pleased to announce release 2015.2 of SfePy.

Description
-----------

SfePy (simple finite elements in Python) is a software for solving systems of
coupled partial differential equations by the finite element method or by the
isogeometric analysis (preliminary support). It is distributed under the new
BSD license.

Home page: http://sfepy.org
Mailing list: http://groups.google.com/group/sfepy-devel
Git (source) repository, issue tracker, wiki: http://github.com/sfepy

Highlights of this release
--------------------------

- major code simplification (removed element groups)
- time stepping solvers updated for interactive use
- improved finding of reference element coordinates of physical points
- reorganized examples
- reorganized installation on POSIX systems (sfepy-run script)

For full release notes see http://docs.sfepy.org/doc/release_notes.html#id1
(rather long and technical).

Best regards,
Robert Cimrman and Contributors (*)

(*) Contributors to this release (alphabetical order):

Lubos Kejzlar, Vladimir Lukes, Anton Gladky, Matyas Novak


From saketkc at gmail.com  Fri May 29 13:52:26 2015
From: saketkc at gmail.com (Saket Choudhary)
Date: Fri, 29 May 2015 10:52:26 -0700
Subject: [SciPy-Dev] [Numpy-discussion] Verify your sourceforge windows
	installer downloads
In-Reply-To: <CAGY4rcXuE_AbZsCLWsTnFv4=LrpUzoeVR=8dVz1+_Sh1sGNrPg@mail.gmail.com>
References: <CAK5FAtEJMj0ZhTRdG9aVHWM8KjpmYJNFDVVWHF4cbSHW7Gj=1g@mail.gmail.com>
	<CAGY4rcX15Jn+JvmQghKWrVKXUYjDcp2A88k2QUfT36dc6=6n2w@mail.gmail.com>
	<31698217454514411.075227sturla.molden-gmail.com@news.gmane.org>
	<CALmrCV3k1b3cGzOVCDdMFMy9bBHXMdbAR=SWxstsazTUHf6beQ@mail.gmail.com>
	<CAGY4rcXuE_AbZsCLWsTnFv4=LrpUzoeVR=8dVz1+_Sh1sGNrPg@mail.gmail.com>
Message-ID: <CAEDHeiv8kJNPgfmuSQacbKy_yYNmaTz=nKFcS42WmQj1jqjCnA@mail.gmail.com>

On 28 May 2015 at 10:05, David Cournapeau <cournape at gmail.com> wrote:
>
>
> On Fri, May 29, 2015 at 2:00 AM, Andrew Collette <andrew.collette at gmail.com>
> wrote:
>>
>> > Here is their lame excuse:
>> >
>> >
>> > https://sourceforge.net/blog/gimp-win-project-wasnt-hijacked-just-abandoned/
>> >
>> > It probably means this:
>> >
>> > If NumPy installers are moved away from Sourceforge, they will set up a
>> > mirror and load the mirrored installers with all sorts of crapware. It
>> > is
>> > some sort of racket the mob couldn't do better.
>>
>> I noticed that like most BSD-licensed software, NumPy's license
>> includes this clause:
>>
>> "Neither the name of the NumPy Developers nor the names of any
>> contributors may be used to endorse or promote products derived from
>> this software without specific prior written permission."
>>
>> There's an argument to be made that SF isn't legally permitted to
>> distribute poisoned installers under the name "NumPy" without
>> permission.  I recall a similar dust-up a while ago about "Standard
>> Markdown" using the name "Markdown"; the original author (John Gruber)
>> took action and got them to change the name.
>>
>> In any case I've always been surprised that NumPy is distributed
>> through SourceForge, which has been sketchy for years now. Could it
>> simply be hosted on PyPI?
>
>
> They don't accept arbitrary binaries like SF does, and some of our installer
> formats can't be uploaded there.
>

Bintray [1] has been providing a free service for hosting
'bottles'(compiled binaries) for the Homebrew project [2].
Probably an option to look at.

[1] https://bintray.com/
[2] http://brew.sh/



> David
>
>>
>>
>> Andrew
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>


From aeklant at gmail.com  Sun May 31 22:22:21 2015
From: aeklant at gmail.com (Abraham Escalante)
Date: Sun, 31 May 2015 21:22:21 -0500
Subject: [SciPy-Dev] [scipy.stats improvements] Weekly Summary 2015/05/30
Message-ID: <CAJJ-iFmexJKHs7kVEk8HYTw5XBqgyBCuGZ0RcspwD7fh72QzCA@mail.gmail.com>

Hello all,

Today Ralf and I had our second weekly meeting and we decided to adopt (or
you know, shamelessly copy) the weekly status approach from Jaime and Aman.
Here is the first one:

*Week 1*

   - [closed] statistics review:  masked_var
   - [closed] statistics review: ss
   - [closed] statistics review: square_of_sums
   - [WIP] Add 'alternative' keyword to hypothesis tests in stats
   - [WIP] Trimmed statistics functions have inconsistent API

*Plan for week 2*

   - Trimmed statistics functions have inconsistent API
   - statistics review: trim_mean
   - statistics review: trim1
   - statistics review: trimboth
   - statistics review: ppcc_max
   - statistics review: find_repeats
   - statistics review: _chk_asarray

Since there's quite a few items, I will refrain from going into much
detail. If anyone is interested in knowing more, please feel free to
contact me and I will gladly provide more info.

Regards,
Abraham.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150531/040c8a6b/attachment.html>

From ralf.gommers at gmail.com  Sun May 31 09:17:35 2015
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sun, 31 May 2015 15:17:35 +0200
Subject: [SciPy-Dev] Out of Core Sparse Matrices
In-Reply-To: <CAJGH0fGWdUCVUQyAJtAOFL5Ph3uPZeSF6UeSqkVOP_kEm9tdAQ@mail.gmail.com>
References: <CAJGH0fHu_3BZrZ=d3EN=TeCR81uki35-uACfdwzEGyBvBVn6Jw@mail.gmail.com>
	<CAPJVwBnaHVzi0C_PYAbd34412joKBEEERxB7j2ErNFhLOXi1vA@mail.gmail.com>
	<CAJGH0fGWdUCVUQyAJtAOFL5Ph3uPZeSF6UeSqkVOP_kEm9tdAQ@mail.gmail.com>
Message-ID: <CABL7CQiqHy7ODpXS7A8V2d39Fu7sfTq-ofC68A-T-jVNGqkjLg@mail.gmail.com>

On Thu, May 28, 2015 at 4:07 PM, Aidan Macdonald <aidan at brightcloud.com>
wrote:

> Hi,
>
> I push one piece of the code here
> <https://github.com/aidan-plenert-macdonald/scipy/tree/master/scipy/dsparse>.
> It is the PYX file. Stephan Hoyer recommended that I push this into he Dask
> project. I looked at their code and it looks like it is more of what my
> work is. I think I will talk with him.
>

That sounds good, fits better there than in scipy.sparse it looks like.

Ralf


> My company is looking at building a good distributed computing framework
> for big data machine learning purposes. Most of the old code is in C++, but
> I am porting it over into Python for better maintainability.
>
> As seen in the code, I simply use the SciPy existing source for the
> dok_matrix (easier than rewriting one) and provide an out of core
> dictionary using Sqlite. I am looking into not using Sqlite and doing a
> sort of memmap interface as that is what our C++ would do, but I am unsure
> of the speed/complexity/maintainability benefit.
>
> At the end of the day, all the SciPy sparse matrix tests should work with
> minimal changes (adding file names). It is PYX because I was compiling with
> Cython. There is currently minimal speed gain from compilation, but I was
> going to go through and optimize later.
>
> Thank you,
>
> Aidan Macdonald
> 805 418 0174
> aidan at brightcloud.com
> aidan.plenert.macdonald at gmail.com
>
> On Wed, May 27, 2015 at 11:25 PM, Nathaniel Smith <njs at pobox.com> wrote:
>
>> On Wed, May 27, 2015 at 5:48 PM, Aidan Macdonald <aidan at brightcloud.com>
>> wrote:
>> >
>> > Hi,
>> >
>> > I work for Brightcloud and part of my work required me to write Out of
>> Core Sparse Matrices. I was thinking of submitting these to Scipy as it
>> currently has Sparse Matrices, but not out of core.
>> >
>> > I was wondering if this code would be a desired addition to SciPy.
>> Also, currently it uses the Python Sqlite3 library. Is it okay to use the
>> Sqlite3 package?
>>
>> Hi Aidan,
>>
>> I think we'd be able to give you better advice/suggestions if you
>> could give us a pointer to the code and/or docs, to get a sense of
>> what kind of general approach, public API, dependencies, etc. that
>> you're talking about?
>>
>> -n
>>
>> --
>> Nathaniel J. Smith -- http://vorpus.org
>> _______________________________________________
>> 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/20150531/388f4103/attachment.html>