From charlesr.harris at gmail.com  Sun Aug  2 01:08:10 2015
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Sat, 1 Aug 2015 23:08:10 -0600
Subject: [SciPy-Dev] mailmap update
Message-ID: <CAB6mnx+PYxyUxdOdUnpX2VV2S9vR5m49WcaJ789=rnjc2S8oQw@mail.gmail.com>

Hi All,

I'm trying to update the .mailmap file on github and could use some help.
The current version seems common to both numpy and scipy, hence the
crosspost.  Here is what I've got so far.

Alex Griffing <argriffi <at> ncsu.edu> alex <argriffi <at> ncsu.edu>
Alex Griffing <argriffi <at> ncsu.edu> argriffing <argriffi <at> ncsu.edu>
Alex Griffing <argriffi <at> ncsu.edu> argriffing <argriffing <at>
users.noreply.github.com>
Behzad Nouri <behzadnouri <at> gmail.com> behzad nouri <behzadnouri <at>
gmail.com>
Carl Kleffner <cmkleffner <at> gmail.com> carlkl <cmkleffner <at> gmail.com>
Christoph Gohlke <cgohlke <at> uci.edu> Christolph Gohlke <cgohlke <at>
uci.edu>
Christoph Gohlke <cgohlke <at> uci.edu> cgholke <? <at> ?>
Christoph Gohlke <cgohlke <at> uci.edu> cgohlke <cgohlke <at> uci.edu>
Han Genuit <hangenuit <at> gmail.com> Han <hangenuit <at> gmail.com>
Jaime Fernandez <jaime.frio <at> gmail.com> Jaime <jaime.frio <at> gmail.com
>
Jaime Fernandez <jaime.frio <at> gmail.com> jaimefrio <jaime.frio <at>
gmail.com>
Mark Wiebe <mwwiebe <at> gmail.com> Mark <mwwiebe <at> gmail.com>
Mark Wiebe <mwwiebe <at> gmail.com> Mark Wiebe <mwiebe <at> enthought.com>
Mark Wiebe <mwwiebe <at> gmail.com> Mark Wiebe <mwiebe <at> georg.(none)>
Nathaniel J. Smith <njs <at> pobox.com> njsmith <njs <at> pobox.com>
Ond?ej ?ert?k <ondrej.certik <at> gmail.com> Ondrej Certik <ondrej.certik
<at> gmail.com>
Ralf Gommers <ralf.gommers <at> googlemail.com> rgommers <ralf.gommers <at>
googlemail.com>
Saullo Giovani <saullogiovani <at> gmail.com> saullogiovani <saullogiovani
<at> gmail.com>
Sebastian Berg <sebastian <at> sipsolutions.net> seberg <sebastian <at>
sipsolutions.net>

Anon <anon at gmail.com> abdulmuneer <abdulmuneer <at> gmail.com>
Anon <anon at gmail.com> amir <ladsgroup <at> gmail.com>
Anon <anon at gmail.com> cel <cel.gentoo <at> gmail.com>
Anon <anon at gmail.com> chebee7i <chebee7i <at> gmail.com>
Anon <anon at gmail.com> empeeu <empeeu <at> yahoo.com>
Anon <anon at gmail.com> endolith <endolith <at> gmail.com>
Anon <anon at gmail.com> hannaro <hroehling <at> gmx.net>
Anon <anon at gmail.com> hpaulj <hpj3 <at> myuw.net>
Anon <anon at gmail.com> immerrr <immerrr <at> gmail.com>
Anon <anon at gmail.com> jmrosen155 <Jordan <at> Jordans-MacBook-Pro.local>
Anon <anon at gmail.com> jnothman <jnothman <at> student.usyd.edu.au>
Anon <anon at gmail.com> kanhua <kanhwa <at> gmail.com>
Anon <anon at gmail.com> mamikony <ernest.mamikonyan <at> sig.com>
Anon <anon at gmail.com> mbyt <random.seed <at> web.de>
Anon <anon at gmail.com> mlai <mlai <at> begws92.beg.utexas.edu>
Anon <anon at gmail.com> ryanblak <rbtnet <at> gmail.com>
Anon <anon at gmail.com> styr <styr.py <at> gmail.com>
Anon <anon at gmail.com> tdihp <tdihp <at> hotmail.com>
Anon <anon at gmail.com> tpoole <t.b.poole <at> gmail.com>
Anon <anon at gmail.com> wim glenn <wim.glenn <at> melbourneit.com.au>

The Anon author is just a standing in for unknown author. I can make a
guess at some of those, but would prefer it if the people in question could
supply their proper name and address.

TIA,

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

From tyler.je.reddy at gmail.com  Sun Aug  2 11:33:29 2015
From: tyler.je.reddy at gmail.com (Tyler Reddy)
Date: Sun, 2 Aug 2015 16:33:29 +0100
Subject: [SciPy-Dev] Proposal: Spherical Voronoi Diagrams
Message-ID: <CAHPuU_YosNSu18_WZnBmnePvjLJYeFaRn3KEV6DfCtOSvS27Aw@mail.gmail.com>

*Basic idea*: Implement spherical Voronoi diagram code in scipy.spatial,
which is where current computational geometry algorithms reside, including
Voronoi, ConvexHull, and Delaunay. Spherical Voronoi diagrams are extremely
useful for parsing spherical objects in biology (i.e., viruses), planetary
physics, search and rescue, airspace territory assignment, network
coverage, etc. The current planar Voronoi diagram code is not capable of
handling this.

*The current state of the code*: With plenty of helpful feedback after my
talk at PyData London 2015 presenting some of the challenges (
https://www.slideshare.net/slideshow/embed_code/key/1bKCEyHa789nBe), I've
been able to refine the code (
https://github.com/tylerjereddy/py_sphere_Voronoi). The algorithm and usage
examples are presented in the documentation (
http://py-sphere-voronoi.readthedocs.org/en/latest/voronoi_utility.html).
Empirical testing indicates that the algorithm exhibits quadratic time
complexity, while the best theoretical results in the literature are
loglinear. For several computational geometry calculations it is relatively
common to use a lower-performing algorithm if it is easier to implement.

The minimum number of input points (generators) tolerated is 4 and maximum
on a modern laptop is ~ 70,000 with 16 GB of physical memory. There are
probably a lot of opportunities to improve the code. I have some plots of
the current performance profiles, if needed. In many cases, the
reconstitution of spherical surface area achieved by summing the spherical
polygon (Voronoi region) surface areas is > 99 %. Nearly-degenerate Voronoi
regions (with vertices almost on top of each other) could perhaps be
handled more gracefully--they currently return areas of approximately 0.
The integrity of the code is currently maintained by a number of unit
tests.

*Question*: Is this perhaps of interest for integration into scipy? I
suspect the standards are pretty high to get the pull request for a whole
new functionality into the package, so I thought it best to inquire this
way first before the potentially substantial time investment of converting
the code to scipy standards from my current in-house layout. I know there
are guidelines I can follow for the pull request as well, but if there are
any basic suggestions from glancing at the current state of the code that
might be helpful as well.


Thanks,

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

From evgeny.burovskiy at gmail.com  Sun Aug  2 14:11:35 2015
From: evgeny.burovskiy at gmail.com (Evgeni Burovski)
Date: Sun, 2 Aug 2015 19:11:35 +0100
Subject: [SciPy-Dev] RFC: non-linear least squares
Message-ID: <CAMRo0it-yU59W-TkiWfrFMGB_7QJyTmMppEtki_yUL5qv6YL6A@mail.gmail.com>

Hi,

I'd like to draw attention to the great work Nikolay Mayorov is doing
for his GSoC on improving non-linear least squares functionality in
scipy.

So far he single-handedly implemented two trust-region type algorithms
for nonlinear LSQ: rectangular trust region dogleg ('dogbox') and
trust region reflective algorithm ('trf', this one is similar to what
MATLAB is using as its default NLSQ method).

Both of these algorithms natively handle box constraints on fit
parameters. Both are implemented to work with dense or sparse
Jacobians, so that they are suitable for large-scale problems (up to
and in excess of 10k variables).

One other feature of the implementation is modified loss functions for
robust LSQ. Several useful loss functions are available out of the
box, and there is flexibility for using custom user-supplied loss
functions.

Several examples are available in Nikolay's GSoC blog at
<https://nmayorov.wordpress.com/>, along with narrative discussion of
the mathematical content, and results of benchmarking his algorithms
against general-purpose optimizers (L-BFGS-B in particular) and
MINUIT-type constrained LSQ optimizer (specifically, leastsqbound ---
which is equivalent to LMFIT).

The relevant PR is under review at <https://github.com/scipy/scipy/pull/5044>.

We plan on merging this PR in some reasonably near future, and we'd
like to ask for help:
* If you are an expert on mathematical optimization, we'd be grateful
if you help reviewing the code;
* If you are a user of nonlinear least squares, we'd be grateful if
you test drive the new functionality and let us know how it works on
your problems.
* We'd welcome comments on the user interface.

Cheers,

Evgeni


From aeklant at gmail.com  Mon Aug  3 03:02:08 2015
From: aeklant at gmail.com (Abraham Escalante)
Date: Mon, 3 Aug 2015 02:02:08 -0500
Subject: [SciPy-Dev] `scipy.stats` NaN handling policy
Message-ID: <CAJJ-iFn56CemQkSK2VaC1xuLFQFos0rj9pxg30L3iTOz0jbC8w@mail.gmail.com>

Hello all,

As some of you may know, for the last two months or so we have been trying
to get the community to converge on a policy to handle NaN values in
`scipy.stats`. I will not go into details because it would take too long,
but you can follow the discussion in gh-571
<https://github.com/scipy/scipy/issues/571> or the PR in gh-5007
<https://github.com/scipy/scipy/pull/5007>.

The implementation details are all but complete at this point but I would
like to ask for opinions on the API naming.

In summary, I added a keyword called "nan_policy", with options
"propagate", "raise" and "omit", where "propagate" returns a NaN value,
"raise" throws a ValueError and "omit" delegates to the equivalent masked
array function, omitting the NaN values.

Alternate names proposed:

   - "nan_policy" --> "nan_check", "on_nan", "nan_action"
   - "propagate" --> "undefined"
   - "omit" --> "ignore", "missing"

We are still open for naming suggestions as long as the community agrees.
If people seem happy with the choices we have already made, this PR will be
merged soonish (two or three days maybe).

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

From pmhobson at gmail.com  Mon Aug  3 12:58:15 2015
From: pmhobson at gmail.com (Paul Hobson)
Date: Mon, 3 Aug 2015 09:58:15 -0700
Subject: [SciPy-Dev] `scipy.stats` NaN handling policy
In-Reply-To: <CAJJ-iFn56CemQkSK2VaC1xuLFQFos0rj9pxg30L3iTOz0jbC8w@mail.gmail.com>
References: <CAJJ-iFn56CemQkSK2VaC1xuLFQFos0rj9pxg30L3iTOz0jbC8w@mail.gmail.com>
Message-ID: <CADT3MED=8vSP19ojOUzwp+pfd=AXCFm2BWjWxFxO_4LNFJtDAQ@mail.gmail.com>

On Mon, Aug 3, 2015 at 12:02 AM, Abraham Escalante <aeklant at gmail.com>
wrote:

> Hello all,
>
> As some of you may know, for the last two months or so we have been trying
> to get the community to converge on a policy to handle NaN values in
> `scipy.stats`. I will not go into details because it would take too long,
> but you can follow the discussion in gh-571
> <https://github.com/scipy/scipy/issues/571> or the PR in gh-5007
> <https://github.com/scipy/scipy/pull/5007>.
>
> The implementation details are all but complete at this point but I would
> like to ask for opinions on the API naming.
>
> In summary, I added a keyword called "nan_policy", with options
> "propagate", "raise" and "omit", where "propagate" returns a NaN value,
> "raise" throws a ValueError and "omit" delegates to the equivalent masked
> array function, omitting the NaN values.
>
> Alternate names proposed:
>
>    - "nan_policy" --> "nan_check", "on_nan", "nan_action"
>    - "propagate" --> "undefined"
>    - "omit" --> "ignore", "missing"
>
> We are still open for naming suggestions as long as the community agrees.
> If people seem happy with the choices we have already made, this PR will be
> merged soonish (two or three days maybe).
>

 I preferences are:

 - "nan_policy"
 - "propagate"
 - "raise"
 - "ignore"

Though I can how perhaps "omit" (or even "drop") would be better
communicate the intent.
-paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150803/8c3fc58c/attachment.html>

From lists at hilboll.de  Tue Aug  4 11:34:30 2015
From: lists at hilboll.de (Andreas Hilboll)
Date: Tue, 04 Aug 2015 17:34:30 +0200
Subject: [SciPy-Dev] backwards-incompatible change in Akima1DInterpolator?
Message-ID: <55C0DB86.2040503@hilboll.de>

Currently, interpolate.Akima1DInterpolator does not use Ppoly's
``extrapolate`` kwarg, but always sets ``extrapolate=False``.

I would like to expose the extrapolation feature in the API of
Akima1DInterpolator.  However, Ppoly's default value for extrapolate is
True.

So there are two choices:

a. Make Akima1DInterpolator's extrapolate default to False.  This is
backward-compatible, but inconsistent with the usual Ppoly behaviour.

b. Make Akima1DInterpolator's extrapolate default to True.  This is
consistent with Ppoly, but is not backwards-compatible.

One way to go could be add a DeprecationWarning or similar now for 0.17,
and then only expose the extrapolate kwarg in 0.18.

Any opinions on how to attack this issue?

-- Andreas.


From aeklant at gmail.com  Wed Aug  5 17:38:10 2015
From: aeklant at gmail.com (Abraham Escalante)
Date: Wed, 5 Aug 2015 16:38:10 -0500
Subject: [SciPy-Dev] Weekly Summary 2015/08/05
Message-ID: <CAJJ-iFnA0J6AQ0cYHCbDOs1cNu04dCY42MRXu2hsGZe2YY+pqg@mail.gmail.com>

Hello all,

Here is last last week's progress and this week's plan for `scipy.stats`
improvements.

*Week 9 topics:*

   - NaN policy implementation details done. The PR is now in bikeshedding
   phase (agreeing on keyword and option names).
   - `bayes_mvs` has been merged.
   - `f_oneway` now passes NIST test cases. Some details still remain to be
   addressed (like addition of examples).

*Week 10 topics:*

   - Reach a NaN policy naming consensus and merge.
   - `mstats` consistency with `stats` will be resumed once NaN policy PR
   is merged.
   - Finish details on `f_oneway` and merge.
   - Once `f_oneway` is merged, `linregress` will be dealt with, using the
   same treatment.
   - `kstat` and `kstatvar` still have some documentation details to add.


For your reference:

   - Open Pull Requests <https://github.com/scipy/scipy/pulls/aeklant>
   - Open StatisticsCleanup issues
   <https://github.com/scipy/scipy/issues?q=is%3Aopen+is%3Aissue+milestone%3AStatisticsCleanup>


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

From freddyrietdijk at fridh.nl  Thu Aug  6 05:11:42 2015
From: freddyrietdijk at fridh.nl (Freddy Rietdijk)
Date: Thu, 6 Aug 2015 11:11:42 +0200
Subject: [SciPy-Dev] `scipy.signal` feedback for PR #4881,
	ltid for discrete-time systems
Message-ID: <CAOQtOH06JB=NBMVJ5UXf_nBcBca+shm13q+uRFjfc7PcC0OGtg@mail.gmail.com>

Hi everyone,

This is a call for feedback on a PR.

A while ago PR #4881 <https://github.com/scipy/scipy/pull/4881>was opened
to add the class `ltid` for linear discrete-time systems. Before the PR,
there was a discussion on this topic in #2912
<https://github.com/scipy/scipy/issues/2912>. So far, the PR hasn't had
much feedback. If you have any, please add it. It would be nice to get this
feature in as soon as possible, because that clears the way for adding more
system specific methods for filtering and such.

Frederik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150806/347309bb/attachment.html>

From atfabbri at gmail.com  Thu Aug  6 10:09:27 2015
From: atfabbri at gmail.com (Tommaso Fabbri)
Date: Thu, 6 Aug 2015 16:09:27 +0200
Subject: [SciPy-Dev] signal.dlsim cannot handle complex input #4964
Message-ID: <CAMmJPwH3veRmErkXv4080R9J4KWbWj80jEjoaNsexFBLAqeuSw@mail.gmail.com>

Hi All,

I would like to have to some feedback about the issue #4964.

I think it can be easily solved with the superposition principle (first
applying it on the real part of the input and then on the imaginary one).
What do you think about it?
Can I proceed with this change?

Thank you so much.


-- 
Tommaso Fabbri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150806/7b1c94b6/attachment.html>

From evgeny.burovskiy at gmail.com  Thu Aug  6 12:24:15 2015
From: evgeny.burovskiy at gmail.com (Evgeni Burovski)
Date: Thu, 6 Aug 2015 17:24:15 +0100
Subject: [SciPy-Dev] backwards-incompatible change in
	Akima1DInterpolator?
In-Reply-To: <55C0DB86.2040503@hilboll.de>
References: <55C0DB86.2040503@hilboll.de>
Message-ID: <CAMRo0it9Kxnr9uPMUpB+c4tTXuMUzZF-ZGTqtqOLPZd8NdrsAA@mail.gmail.com>

On Tue, Aug 4, 2015 at 4:34 PM, Andreas Hilboll <lists at hilboll.de> wrote:
> Currently, interpolate.Akima1DInterpolator does not use Ppoly's
> ``extrapolate`` kwarg, but always sets ``extrapolate=False``.
>
> I would like to expose the extrapolation feature in the API of
> Akima1DInterpolator.  However, Ppoly's default value for extrapolate is
> True.
>
> So there are two choices:
>
> a. Make Akima1DInterpolator's extrapolate default to False.  This is
> backward-compatible, but inconsistent with the usual Ppoly behaviour.
>
> b. Make Akima1DInterpolator's extrapolate default to True.  This is
> consistent with Ppoly, but is not backwards-compatible.
>
> One way to go could be add a DeprecationWarning or similar now for 0.17,
> and then only expose the extrapolate kwarg in 0.18.
>
> Any opinions on how to attack this issue?
>
> -- Andreas.


I think we can go with option b. --- break the backwards compat and
mention it in the release notes.
[yes, I am known to be on a trigger-happy side for backcompat]

Evgeni


From ryan at kinnear.ca  Fri Aug  7 16:25:44 2015
From: ryan at kinnear.ca (Ryan J. Kinnear)
Date: Fri, 07 Aug 2015 14:25:44 -0600
Subject: [SciPy-Dev] Optimization success threshold?
Message-ID: <55C51448.5030707@kinnear.ca>

Dear list,

I'm using some of the optimization routines in scipy to help design high 
frequency electronic filters, it takes a very long time to evaluate the 
cost function just once (order of seconds).  It's also not necessary to 
get a "perfect" design, it can quit as soon as it reaches a value that 
is good enough.

As far as I can tell, there isn't really a straightforward way to tell 
the optimizer to quit once it gets below some threshold.  This can be 
hacked in with exceptions or the callback, but is that the best way to 
do it?  Would it be valuable to add a "success threshold" to the 
optimization routines?

-RK


From andrea.gavana at gmail.com  Sat Aug  8 04:16:11 2015
From: andrea.gavana at gmail.com (Andrea Gavana)
Date: Sat, 8 Aug 2015 10:16:11 +0200
Subject: [SciPy-Dev] Optimization success threshold?
In-Reply-To: <55C51448.5030707@kinnear.ca>
References: <55C51448.5030707@kinnear.ca>
Message-ID: <CAEf70bzMa=24ac3zV-3MTgoR=nRDyGGS1PoZiYHXonQqe-o0fA@mail.gmail.com>

Hi Ryan,

    Some of the optimizers in Scipy do accept a parameter called "ftol",
which specifies A tolerance for termination on the objective function. Is
this what you're looking for?

If you're thinking about stopping the optimization when the parameters are
varying very little, then as far as I can see there is no option for that
in Scipy optimize. However, unless your objective function is rapidly
changing even for very small variation of the parameters (I.e., it's very
irregular), then if the parameters vary very little from one iteration to
the other also your objective function changes very little and the "ftol"
input argument should do the trick.

Or maybe I have misunderstood the question?

Andrea.


On Friday, August 7, 2015, Ryan J. Kinnear <ryan at kinnear.ca> wrote:

> Dear list,
>
> I'm using some of the optimization routines in scipy to help design high
> frequency electronic filters, it takes a very long time to evaluate the
> cost function just once (order of seconds).  It's also not necessary to
> get a "perfect" design, it can quit as soon as it reaches a value that
> is good enough.
>
> As far as I can tell, there isn't really a straightforward way to tell
> the optimizer to quit once it gets below some threshold.  This can be
> hacked in with exceptions or the callback, but is that the best way to
> do it?  Would it be valuable to add a "success threshold" to the
> optimization routines?
>
> -RK
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org <javascript:;>
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


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

From ryan at kinnear.ca  Mon Aug 10 00:31:16 2015
From: ryan at kinnear.ca (ryan)
Date: Sun, 09 Aug 2015 21:31:16 -0700
Subject: [SciPy-Dev] Optimization success threshold?
In-Reply-To: <CAEf70bzMa=24ac3zV-3MTgoR=nRDyGGS1PoZiYHXonQqe-o0fA@mail.gmail.com>
References: <55C51448.5030707@kinnear.ca>
	<CAEf70bzMa=24ac3zV-3MTgoR=nRDyGGS1PoZiYHXonQqe-o0fA@mail.gmail.com>
Message-ID: <web-33855797@mail2.webnames.ca>

I actually think it was misunderstood yes, I will try to improve my explanation.

The ftol and xtol parameters halt the optimizer when the objective isn't changing very much (it thinks it has converged).  But for my application (microwave filter design), cost function evaluations are very expensive, up to a couple seconds on simple models, and up to even 10 min + for electromagnetic simulations.  We have some notion of what a "good enough" objective function value is (e.g. reflected power below -20dB) and we want the optimizer to stop as soon as it finds some parameters that satisfy this criteria so that it doesn't keep running long simulations for no reason.  I would call it something like a success threshold option.

This seems like a reasonable feature, especially for expensive cost functions or non convex problems - which is why I'm posting in scipy-dev.  Although even though there is no explicit option for specifying a success threshold, there may be a reasonable idiom for doing this that I am just unaware of.

-RK


On Sat, 8 Aug 2015 10:16:11 +0200
 Andrea Gavana <andrea.gavana at gmail.com> wrote:
>Hi Ryan,
>
>    Some of the optimizers in Scipy do accept a parameter called "ftol",
>which specifies A tolerance for termination on the objective function. Is
>this what you're looking for?
>
>If you're thinking about stopping the optimization when the parameters are
>varying very little, then as far as I can see there is no option for that
>in Scipy optimize. However, unless your objective function is rapidly
>changing even for very small variation of the parameters (I.e., it's very
>irregular), then if the parameters vary very little from one iteration to
>the other also your objective function changes very little and the "ftol"
>input argument should do the trick.
>
>Or maybe I have misunderstood the question?
>
>Andrea.
>
>
>On Friday, August 7, 2015, Ryan J. Kinnear <ryan at kinnear.ca> wrote:
>
>> Dear list,
>>
>> I'm using some of the optimization routines in scipy to help design high
>> frequency electronic filters, it takes a very long time to evaluate the
>> cost function just once (order of seconds).  It's also not necessary to
>> get a "perfect" design, it can quit as soon as it reaches a value that
>> is good enough.
>>
>> As far as I can tell, there isn't really a straightforward way to tell
>> the optimizer to quit once it gets below some threshold.  This can be
>> hacked in with exceptions or the callback, but is that the best way to
>> do it?  Would it be valuable to add a "success threshold" to the
>> optimization routines?
>>
>> -RK
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org <javascript:;>
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>
>
>--

Ryan


From andyfaff at gmail.com  Mon Aug 10 00:35:23 2015
From: andyfaff at gmail.com (Andrew Nelson)
Date: Mon, 10 Aug 2015 14:35:23 +1000
Subject: [SciPy-Dev] Optimization success threshold?
In-Reply-To: <web-33855797@mail2.webnames.ca>
References: <55C51448.5030707@kinnear.ca>
	<CAEf70bzMa=24ac3zV-3MTgoR=nRDyGGS1PoZiYHXonQqe-o0fA@mail.gmail.com>
	<web-33855797@mail2.webnames.ca>
Message-ID: <CAAbtOZc_QAAXK_Xq_xRrz5Kft8_hjXkG5jyG7kiDdiFg-LJ5DA@mail.gmail.com>

I wonder if this request to halt would be satisfied by:
https://github.com/scipy/scipy/pull/4384?

On 10 August 2015 at 14:31, ryan <ryan at kinnear.ca> wrote:

> I actually think it was misunderstood yes, I will try to improve my
> explanation.
>
> The ftol and xtol parameters halt the optimizer when the objective isn't
> changing very much (it thinks it has converged).  But for my application
> (microwave filter design), cost function evaluations are very expensive, up
> to a couple seconds on simple models, and up to even 10 min + for
> electromagnetic simulations.  We have some notion of what a "good enough"
> objective function value is (e.g. reflected power below -20dB) and we want
> the optimizer to stop as soon as it finds some parameters that satisfy this
> criteria so that it doesn't keep running long simulations for no reason.  I
> would call it something like a success threshold option.
>
> This seems like a reasonable feature, especially for expensive cost
> functions or non convex problems - which is why I'm posting in scipy-dev.
> Although even though there is no explicit option for specifying a success
> threshold, there may be a reasonable idiom for doing this that I am just
> unaware of.
>
> -RK
>
>
> On Sat, 8 Aug 2015 10:16:11 +0200
>  Andrea Gavana <andrea.gavana at gmail.com> wrote:
> >Hi Ryan,
> >
> >    Some of the optimizers in Scipy do accept a parameter called "ftol",
> >which specifies A tolerance for termination on the objective function. Is
> >this what you're looking for?
> >
> >If you're thinking about stopping the optimization when the parameters are
> >varying very little, then as far as I can see there is no option for that
> >in Scipy optimize. However, unless your objective function is rapidly
> >changing even for very small variation of the parameters (I.e., it's very
> >irregular), then if the parameters vary very little from one iteration to
> >the other also your objective function changes very little and the "ftol"
> >input argument should do the trick.
> >
> >Or maybe I have misunderstood the question?
> >
> >Andrea.
> >
> >
> >On Friday, August 7, 2015, Ryan J. Kinnear <ryan at kinnear.ca> wrote:
> >
> >> Dear list,
> >>
> >> I'm using some of the optimization routines in scipy to help design high
> >> frequency electronic filters, it takes a very long time to evaluate the
> >> cost function just once (order of seconds).  It's also not necessary to
> >> get a "perfect" design, it can quit as soon as it reaches a value that
> >> is good enough.
> >>
> >> As far as I can tell, there isn't really a straightforward way to tell
> >> the optimizer to quit once it gets below some threshold.  This can be
> >> hacked in with exceptions or the callback, but is that the best way to
> >> do it?  Would it be valuable to add a "success threshold" to the
> >> optimization routines?
> >>
> >> -RK
> >> _______________________________________________
> >> SciPy-Dev mailing list
> >> SciPy-Dev at scipy.org <javascript:;>
> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
> >>
> >
> >
> >--
>
> Ryan
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>



-- 
_____________________________________
Dr. Andrew Nelson


_____________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150810/90c2de2d/attachment.html>

From gyromagnetic at gmail.com  Mon Aug 10 12:39:53 2015
From: gyromagnetic at gmail.com (Gyro Funch)
Date: Mon, 10 Aug 2015 10:39:53 -0600
Subject: [SciPy-Dev] Optimization success threshold?
In-Reply-To: <web-33855797@mail2.webnames.ca>
References: <55C51448.5030707@kinnear.ca>
	<CAEf70bzMa=24ac3zV-3MTgoR=nRDyGGS1PoZiYHXonQqe-o0fA@mail.gmail.com>
	<web-33855797@mail2.webnames.ca>
Message-ID: <mqak4p$ah3$1@ger.gmane.org>

On 8/9/2015 10:31 PM, ryan wrote:
> I actually think it was misunderstood yes, I will try to improve my explanation.
> 
> The ftol and xtol parameters halt the optimizer when the objective isn't changing very much (it thinks it has converged).  But for my application (microwave filter design), cost function evaluations are very expensive, up to a couple seconds on simple models, and up to even 10 min + for electromagnetic simulations.  We have some notion of what a "good enough" objective function value is (e.g. reflected power below -20dB) and we want the optimizer to stop as soon as it finds some parameters that satisfy this criteria so that it doesn't keep running long simulations for no reason.  I would call it something like a success threshold option.
> 
> This seems like a reasonable feature, especially for expensive cost functions or non convex problems - which is why I'm posting in scipy-dev.  Although even though there is no explicit option for specifying a success threshold, there may be a reasonable idiom for doing this that I am just unaware of.
> 
> -RK
> 
> 


I may be misunderstanding, but can't the objective function be
recast to take into account this threshold?

For instance, instead of

f(x) = 0,

use something like

f(x) - threshold = 0.

-gyro







From ryan at kinnear.ca  Mon Aug 10 12:47:19 2015
From: ryan at kinnear.ca (Ryan J. Kinnear)
Date: Mon, 10 Aug 2015 10:47:19 -0600
Subject: [SciPy-Dev] Optimization success threshold?
In-Reply-To: <mqak4p$ah3$1@ger.gmane.org>
References: <55C51448.5030707@kinnear.ca>	<CAEf70bzMa=24ac3zV-3MTgoR=nRDyGGS1PoZiYHXonQqe-o0fA@mail.gmail.com>	<web-33855797@mail2.webnames.ca>
	<mqak4p$ah3$1@ger.gmane.org>
Message-ID: <55C8D597.608@kinnear.ca>

Gyro,

The objective function returning 0 does not halt the optimizer, it will 
keep trying to find objective function values below 0.

Using

cost = f(x)
if cost < threshold:
     return 0
else:
     return cost

Will cause it to halt shortly after finding a cost below the threshold 
because of the ftol parameter.  But it still does a few more expensive 
cost function evaluations before returning.  Another downside is that it 
won't tell you what the actual cost was, it may be exactly "threshold", 
or it may be significantly less.

-RK

On 08/10/2015 10:39 AM, Gyro Funch wrote:
> On 8/9/2015 10:31 PM, ryan wrote:
>> I actually think it was misunderstood yes, I will try to improve my explanation.
>>
>> The ftol and xtol parameters halt the optimizer when the objective isn't changing very much (it thinks it has converged).  But for my application (microwave filter design), cost function evaluations are very expensive, up to a couple seconds on simple models, and up to even 10 min + for electromagnetic simulations.  We have some notion of what a "good enough" objective function value is (e.g. reflected power below -20dB) and we want the optimizer to stop as soon as it finds some parameters that satisfy this criteria so that it doesn't keep running long simulations for no reason.  I would call it something like a success threshold option.
>>
>> This seems like a reasonable feature, especially for expensive cost functions or non convex problems - which is why I'm posting in scipy-dev.  Although even though there is no explicit option for specifying a success threshold, there may be a reasonable idiom for doing this that I am just unaware of.
>>
>> -RK
>>
>>
>
> I may be misunderstanding, but can't the objective function be
> recast to take into account this threshold?
>
> For instance, instead of
>
> f(x) = 0,
>
> use something like
>
> f(x) - threshold = 0.
>
> -gyro
>
>
>
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev



From ryan at kinnear.ca  Mon Aug 10 13:00:43 2015
From: ryan at kinnear.ca (Ryan J. Kinnear)
Date: Mon, 10 Aug 2015 11:00:43 -0600
Subject: [SciPy-Dev] Optimization success threshold?
In-Reply-To: <CAAbtOZc_QAAXK_Xq_xRrz5Kft8_hjXkG5jyG7kiDdiFg-LJ5DA@mail.gmail.com>
References: <55C51448.5030707@kinnear.ca>	<CAEf70bzMa=24ac3zV-3MTgoR=nRDyGGS1PoZiYHXonQqe-o0fA@mail.gmail.com>	<web-33855797@mail2.webnames.ca>
	<CAAbtOZc_QAAXK_Xq_xRrz5Kft8_hjXkG5jyG7kiDdiFg-LJ5DA@mail.gmail.com>
Message-ID: <55C8D8BB.9030205@kinnear.ca>

I think this is essentially what I'm looking for yeah, thanks I'll look 
into this more.

-RK

On 08/09/2015 10:35 PM, Andrew Nelson wrote:
> I wonder if this request to halt would be satisfied by: 
> https://github.com/scipy/scipy/pull/4384?
>
> On 10 August 2015 at 14:31, ryan <ryan at kinnear.ca 
> <mailto:ryan at kinnear.ca>> wrote:
>
>     I actually think it was misunderstood yes, I will try to improve
>     my explanation.
>
>     The ftol and xtol parameters halt the optimizer when the objective
>     isn't changing very much (it thinks it has converged).  But for my
>     application (microwave filter design), cost function evaluations
>     are very expensive, up to a couple seconds on simple models, and
>     up to even 10 min + for electromagnetic simulations.  We have some
>     notion of what a "good enough" objective function value is (e.g.
>     reflected power below -20dB) and we want the optimizer to stop as
>     soon as it finds some parameters that satisfy this criteria so
>     that it doesn't keep running long simulations for no reason.  I
>     would call it something like a success threshold option.
>
>     This seems like a reasonable feature, especially for expensive
>     cost functions or non convex problems - which is why I'm posting
>     in scipy-dev.  Although even though there is no explicit option
>     for specifying a success threshold, there may be a reasonable
>     idiom for doing this that I am just unaware of.
>
>     -RK
>
>
>     On Sat, 8 Aug 2015 10:16:11 +0200
>      Andrea Gavana <andrea.gavana at gmail.com
>     <mailto:andrea.gavana at gmail.com>> wrote:
>     >Hi Ryan,
>     >
>     >    Some of the optimizers in Scipy do accept a parameter called
>     "ftol",
>     >which specifies A tolerance for termination on the objective
>     function. Is
>     >this what you're looking for?
>     >
>     >If you're thinking about stopping the optimization when the
>     parameters are
>     >varying very little, then as far as I can see there is no option
>     for that
>     >in Scipy optimize. However, unless your objective function is rapidly
>     >changing even for very small variation of the parameters (I.e.,
>     it's very
>     >irregular), then if the parameters vary very little from one
>     iteration to
>     >the other also your objective function changes very little and
>     the "ftol"
>     >input argument should do the trick.
>     >
>     >Or maybe I have misunderstood the question?
>     >
>     >Andrea.
>     >
>     >
>     >On Friday, August 7, 2015, Ryan J. Kinnear <ryan at kinnear.ca
>     <mailto:ryan at kinnear.ca>> wrote:
>     >
>     >> Dear list,
>     >>
>     >> I'm using some of the optimization routines in scipy to help
>     design high
>     >> frequency electronic filters, it takes a very long time to
>     evaluate the
>     >> cost function just once (order of seconds). It's also not
>     necessary to
>     >> get a "perfect" design, it can quit as soon as it reaches a
>     value that
>     >> is good enough.
>     >>
>     >> As far as I can tell, there isn't really a straightforward way
>     to tell
>     >> the optimizer to quit once it gets below some threshold.  This
>     can be
>     >> hacked in with exceptions or the callback, but is that the best
>     way to
>     >> do it?  Would it be valuable to add a "success threshold" to the
>     >> optimization routines?
>     >>
>     >> -RK
>     >> _______________________________________________
>     >> SciPy-Dev mailing list
>     >> SciPy-Dev at scipy.org <mailto:SciPy-Dev at scipy.org> <javascript:;>
>     >> http://mail.scipy.org/mailman/listinfo/scipy-dev
>     >>
>     >
>     >
>     >--
>
>     Ryan
>     _______________________________________________
>     SciPy-Dev mailing list
>     SciPy-Dev at scipy.org <mailto:SciPy-Dev at scipy.org>
>     http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
>
>
> -- 
> _____________________________________
> Dr. Andrew Nelson
>
>
> _____________________________________
>
>
> _______________________________________________
> 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/20150810/1f07ca78/attachment.html>

From newville at cars.uchicago.edu  Mon Aug 10 13:46:16 2015
From: newville at cars.uchicago.edu (Matt Newville)
Date: Mon, 10 Aug 2015 12:46:16 -0500
Subject: [SciPy-Dev] SciPy-Dev Digest, Vol 142, Issue 6
In-Reply-To: <mailman.1.1439226001.30114.scipy-dev@scipy.org>
References: <mailman.1.1439226001.30114.scipy-dev@scipy.org>
Message-ID: <CA+7ESbrJ977kO=tAjZM2Hz_jn_=zAfC1_8OV+ARiKjL7o6DCww@mail.gmail.com>

Hi Ryan,

Hi Ryan,

Date: Sun, 09 Aug 2015 21:31:16 -0700
> From: "ryan" <ryan at kinnear.ca>
> Subject: Re: [SciPy-Dev] Optimization success threshold?
> To: "SciPy Developers List" <scipy-dev at scipy.org>
> Message-ID: <web-33855797 at mail2.webnames.ca>
> Content-Type: text/plain;charset=utf-8
>
> I actually think it was misunderstood yes, I will try to improve my
> explanation.
>
> The ftol and xtol parameters halt the optimizer when the objective isn't
> changing very much (it thinks it has converged).  But for my application
> (microwave filter design), cost function evaluations are very expensive, up
> to a couple seconds on simple models, and up to even 10 min + for
> electromagnetic simulations.  We have some notion of what a "good enough"
> objective function value is (e.g. reflected power below -20dB) and we want
> the optimizer to stop as soon as it finds some parameters that satisfy this
> criteria so that it doesn't keep running long simulations for no reason.  I
> would call it something like a success threshold option.
>
> This seems like a reasonable feature, especially for expensive cost
> functions or non convex problems - which is why I'm posting in scipy-dev.
> Although even though there is no explicit option for specifying a success
> threshold, there may be a reasonable idiom for doing this that I am just
> unaware of.
>
> -RK
>
>
I'm not sure whether it would be of interest to you, but we just merged-in
the ability for a per-iteration callback function halt fitting in lmfit (
https://github.com/lmfit/lmfit-py/pull/245).

This is currently in the master branch at github, and works in a manner
very similar to Andrew Nelson's suggestion and PR: if the
per-iteration-callback function returns True, the fit is halted
immediately.   See
http://cars9.uchicago.edu/software/python/lmfit/fitting.html#fit-itercb-label
for "development docs".

I do agree that having this ability generally available in scipy.optimize
would be useful.  I think it's somewhat easier to do within lmfit because
we already have a wrapper to the users objective / cost function to convert
between "current variable values" and "Parameters".  As a side-effect, we
can easily (and uniformly for all supported minimization methods) inject
running and checking the return value of such a callback function there.

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

From gyromagnetic at gmail.com  Mon Aug 10 14:30:27 2015
From: gyromagnetic at gmail.com (Gyro Funch)
Date: Mon, 10 Aug 2015 12:30:27 -0600
Subject: [SciPy-Dev] Optimization success threshold?
In-Reply-To: <55C8D597.608@kinnear.ca>
References: <55C51448.5030707@kinnear.ca>
	<CAEf70bzMa=24ac3zV-3MTgoR=nRDyGGS1PoZiYHXonQqe-o0fA@mail.gmail.com>
	<web-33855797@mail2.webnames.ca> <mqak4p$ah3$1@ger.gmane.org>
	<55C8D597.608@kinnear.ca>
Message-ID: <mqaqk4$l7v$1@ger.gmane.org>

On 8/10/2015 10:47 AM, Ryan J. Kinnear wrote:
> Gyro,
> 
> The objective function returning 0 does not halt the optimizer, it will 
> keep trying to find objective function values below 0.
> 
> Using
> 
> cost = f(x)
> if cost < threshold:
>      return 0
> else:
>      return cost
> 
> Will cause it to halt shortly after finding a cost below the threshold 
> because of the ftol parameter.  But it still does a few more expensive 
> cost function evaluations before returning.  Another downside is that it 
> won't tell you what the actual cost was, it may be exactly "threshold", 
> or it may be significantly less.
> 
> -RK
> 


Sorry, I was thinking about a root finding problem.

cost = (f(x) - threshold) ** 2

might be more appropriate here, but the extra evaluations would
still be a problem.

-gyro





From charlesr.harris at gmail.com  Tue Aug 11 17:23:08 2015
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Tue, 11 Aug 2015 15:23:08 -0600
Subject: [SciPy-Dev] ANN: Numpy 1.10.0b1 release
Message-ID: <CAB6mnxJekRA0Ct-bpqHCkTc-Uf3Wp75z6roju1APXo3-jYPAyw@mail.gmail.com>

Hi All,

give this release a whirl and report any problems either on the
numpy-discussion list or by opening an issue on github.
I'm pleased to announce the first beta release of Numpy 1.10.0. There is
over a year's worth of enhancements and bug fixes in the 1.10.0 release, so
please give this release a whirl and report any problems either on the
numpy-discussion list or by opening an issue on github. Tarballs,
installers, and release notes may be found in the usual place at Sourceforge
<https://sourceforge.net/projects/numpy/files/NumPy/1.10.0b1/>.

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

From aeklant at gmail.com  Thu Aug 13 01:11:40 2015
From: aeklant at gmail.com (Abraham Escalante)
Date: Thu, 13 Aug 2015 00:11:40 -0500
Subject: [SciPy-Dev] Weekly Summary 2015/08/12
Message-ID: <CAJJ-iFmd2vH0gt8itMm3UuCczVy3ehGJP2m-zNFSw_HwWWZ-hg@mail.gmail.com>

Hello all,

Here is last last week's progress and this week's plan for `scipy.stats`
improvements.

*Week 10 topics:*

   - NaN policy ready to be merged.
   - `f_oneway` NIST test cases ready to be merged.

*Week 11 topics:*

   - `mstats` consistency with `stats`: WIP.
   - `linregress`: same treatment as `f_oneway`.
   - `shapiro`: WIP
   - `kendalltau`: standby
   - `pointbiserialr`: standby

For your reference:

   - Open Pull Requests <https://github.com/scipy/scipy/pulls/aeklant>
   - Open StatisticsCleanup issues
   <https://github.com/scipy/scipy/issues?q=is%3Aopen+is%3Aissue+milestone%3AStatisticsCleanup>


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

From m.oliver at jacobs-university.de  Fri Aug 14 12:45:40 2015
From: m.oliver at jacobs-university.de (Marcel Oliver)
Date: Sat, 15 Aug 2015 00:45:40 +0800
Subject: [SciPy-Dev] solve_banded is very slow as a tridiagonal solver
Message-ID: <21966.6964.665041.674262@localhost.localdomain>

Hello,

I noticed that using solve_banded to solve a tridiagonal linear system
is at least an order of magnitude slower than it should be based on a
straightforward operation count of the Thomas algorithm.

In the python source code, solve_banded is pretty much a
straightforward call into gbsv from lapack, but I did not dare to
follow up on what is going on in there.  Maybe it's doing pivoting, or
there is some inefficiency due to being coded for more general
band-diagonal problems.

In any event, in a lot of textbook applications of tridiagonal
solvers, pivoting is not necessary (see, e.g., Higham, Accuracy and
Stability of Numerical Algorithms, SIAM 1996, Section 9.5) and the
Thomas algorithm does not vectorize efficiently.

So it would be very good if either solve_banded could be fixed if it
does something stupid, or otherwise if a plain Thomas algorithm
tridiagonal solver could be added as this would cover a lot of
run-off-the-mill problems while solve_banded could handle the rest.

In any event, just to demonstrate that the performance gap is really
there, I coded up a Thomas algorithm in cython and here is the output
for a tridiagonal system of size 10^6:

CPU time Thomas algorithm in python: 3.47022
CPU time solve_banded: 0.428928
CPU time Thomas algorithm in cython: 0.032048

Speedup python/cython: 108.281952072
Speedup solve_banded/cython: 13.3839241138

The code is attached, but it's quickly put together and I am not
claiming that it's well.  In fact, it's the first time I try cython
which was easy enough, except that @cython.boundscheck(False) makes
the code run slower, not faster...

Regards,
Marcel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tridiag.pyx
Type: application/octet-stream
Size: 1457 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150815/1b552dc4/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tridiag_test.py
Type: application/octet-stream
Size: 1585 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150815/1b552dc4/attachment-0001.obj>

From ewm at redtetrahedron.org  Fri Aug 14 13:12:19 2015
From: ewm at redtetrahedron.org (Eric Moore)
Date: Fri, 14 Aug 2015 13:12:19 -0400
Subject: [SciPy-Dev] solve_banded is very slow as a tridiagonal solver
In-Reply-To: <21966.6964.665041.674262@localhost.localdomain>
References: <21966.6964.665041.674262@localhost.localdomain>
Message-ID: <CAGeA38keSRwmNuLbu0csJYjsms+aQczJXmqk9FRL440vOoSXfg@mail.gmail.com>

First I would try updating to version 0.16.  Solve_banded was updated to
use dgtsv when given a tridiagonal system.  Dgtsv does do partial pivoting,
but it should be much faster than dgbsv for this case.  For a system of
1e6, it is about 6 times faster for me ( 39.1 ms vs 270 ms).

Eric

On Fri, Aug 14, 2015 at 12:45 PM, Marcel Oliver <
m.oliver at jacobs-university.de> wrote:

> Hello,
>
> I noticed that using solve_banded to solve a tridiagonal linear system
> is at least an order of magnitude slower than it should be based on a
> straightforward operation count of the Thomas algorithm.
>
> In the python source code, solve_banded is pretty much a
> straightforward call into gbsv from lapack, but I did not dare to
> follow up on what is going on in there.  Maybe it's doing pivoting, or
> there is some inefficiency due to being coded for more general
> band-diagonal problems.
>
> In any event, in a lot of textbook applications of tridiagonal
> solvers, pivoting is not necessary (see, e.g., Higham, Accuracy and
> Stability of Numerical Algorithms, SIAM 1996, Section 9.5) and the
> Thomas algorithm does not vectorize efficiently.
>
> So it would be very good if either solve_banded could be fixed if it
> does something stupid, or otherwise if a plain Thomas algorithm
> tridiagonal solver could be added as this would cover a lot of
> run-off-the-mill problems while solve_banded could handle the rest.
>
> In any event, just to demonstrate that the performance gap is really
> there, I coded up a Thomas algorithm in cython and here is the output
> for a tridiagonal system of size 10^6:
>
> CPU time Thomas algorithm in python: 3.47022
> CPU time solve_banded: 0.428928
> CPU time Thomas algorithm in cython: 0.032048
>
> Speedup python/cython: 108.281952072
> Speedup solve_banded/cython: 13.3839241138
>
> The code is attached, but it's quickly put together and I am not
> claiming that it's well.  In fact, it's the first time I try cython
> which was easy enough, except that @cython.boundscheck(False) makes
> the code run slower, not faster...
>
> Regards,
> Marcel
>
>
> _______________________________________________
> 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/20150814/f75dcf6a/attachment.html>

From m.oliver at jacobs-university.de  Fri Aug 14 22:56:18 2015
From: m.oliver at jacobs-university.de (Marcel Oliver)
Date: Sat, 15 Aug 2015 10:56:18 +0800
Subject: [SciPy-Dev] solve_banded is very slow as a tridiagonal solver
In-Reply-To: <CAGeA38keSRwmNuLbu0csJYjsms+aQczJXmqk9FRL440vOoSXfg@mail.gmail.com>
References: <21966.6964.665041.674262@localhost.localdomain>
	<CAGeA38keSRwmNuLbu0csJYjsms+aQczJXmqk9FRL440vOoSXfg@mail.gmail.com>
Message-ID: <21966.43602.684974.291896@localhost.localdomain>

Eric Moore writes:
 > First I would try updating to version 0.16.  Solve_banded was
 > updated to use dgtsv when given a tridiagonal system.  Dgtsv does
 > do partial pivoting, but it should be much faster than dgbsv for
 > this case.  For a system of 1e6, it is about 6 times faster for me
 > ( 39.1 ms vs 270 ms).
 > 
 > Eric

Dear Eric,

thank you very much for the quick reply.  I'll follow this issue and,
if necessary, report back.  For now, we'll probably just go with my
cython hack as it's unreasonable to expect my collaborators to
hand-update scipy.  But the tridiagonal issue comes up often enough
that it's worth some thought and optimization.  Even if it's only a
factor two in the end (I'll check once I get to update), a plain
Thomas tridiagonal solver would probably be worth it.

With best regards,
Marcel



From ralf.gommers at gmail.com  Sat Aug 15 04:43:12 2015
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sat, 15 Aug 2015 10:43:12 +0200
Subject: [SciPy-Dev] removing the Lena image
Message-ID: <CABL7CQi1Ka13jxKrptPFf8WtW9rfuemSdtRHRo4pBABKo2uyGA@mail.gmail.com>

Hi all,

The Lena image that we ship is a standard image in the image processing
literature, however it's also controversial (see
https://en.wikipedia.org/wiki/Lenna). That was the reason for:
- adding 2 new images in scipy 0.12.0 (
https://github.com/scipy/scipy/pull/351)
- recommending to not using Lena in the documentation in scipy 0.16.0 (
https://github.com/scipy/scipy/pull/4785)

Now it looks like Debian was decided that the licensing of this image is
NOK and that it needs to be removed from all of Debian. Which hasn't
affected Scipy yet but has affected scikit-image (it's "marked for
auto-removal"):
https://groups.google.com/forum/#!topic/scikit-image/q36bajdvWew
https://groups.google.com/forum/#!topic/scikit-image/8d15Egg7qAY

I know opinions on the image itself and on Debian's action will vary, but
I'd like to be pragmatic here and prevent issues with Scipy packaging in
Debian. Therefore I propose to do the same as what scikit-image will do:
remove Lena for the next release and raise an error from the
scipy.misc.lena() function.

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

From njs at pobox.com  Sat Aug 15 05:02:03 2015
From: njs at pobox.com (Nathaniel Smith)
Date: Sat, 15 Aug 2015 02:02:03 -0700
Subject: [SciPy-Dev] removing the Lena image
In-Reply-To: <CABL7CQi1Ka13jxKrptPFf8WtW9rfuemSdtRHRo4pBABKo2uyGA@mail.gmail.com>
References: <CABL7CQi1Ka13jxKrptPFf8WtW9rfuemSdtRHRo4pBABKo2uyGA@mail.gmail.com>
Message-ID: <CAPJVwBkoyHXvstgMdaCTZ-nTgzziOG2r380YgiYfKPJm1ysUMA@mail.gmail.com>

+1

The arguments against the image are compelling in their own right, but
even if they weren't it doesn't matter -- we shouldn't be shipping an
image that we don't have any legal right to ship!

On Sat, Aug 15, 2015 at 1:43 AM, Ralf Gommers <ralf.gommers at gmail.com> wrote:
> Hi all,
>
> The Lena image that we ship is a standard image in the image processing
> literature, however it's also controversial (see
> https://en.wikipedia.org/wiki/Lenna). That was the reason for:
> - adding 2 new images in scipy 0.12.0
> (https://github.com/scipy/scipy/pull/351)
> - recommending to not using Lena in the documentation in scipy 0.16.0
> (https://github.com/scipy/scipy/pull/4785)
>
> Now it looks like Debian was decided that the licensing of this image is NOK
> and that it needs to be removed from all of Debian. Which hasn't affected
> Scipy yet but has affected scikit-image (it's "marked for auto-removal"):
> https://groups.google.com/forum/#!topic/scikit-image/q36bajdvWew
> https://groups.google.com/forum/#!topic/scikit-image/8d15Egg7qAY
>
> I know opinions on the image itself and on Debian's action will vary, but
> I'd like to be pragmatic here and prevent issues with Scipy packaging in
> Debian. Therefore I propose to do the same as what scikit-image will do:
> remove Lena for the next release and raise an error from the
> scipy.misc.lena() function.
>
> Ralf
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>



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


From matthew.brett at gmail.com  Sat Aug 15 08:10:43 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Sat, 15 Aug 2015 13:10:43 +0100
Subject: [SciPy-Dev] removing the Lena image
In-Reply-To: <CAPJVwBkoyHXvstgMdaCTZ-nTgzziOG2r380YgiYfKPJm1ysUMA@mail.gmail.com>
References: <CABL7CQi1Ka13jxKrptPFf8WtW9rfuemSdtRHRo4pBABKo2uyGA@mail.gmail.com>
	<CAPJVwBkoyHXvstgMdaCTZ-nTgzziOG2r380YgiYfKPJm1ysUMA@mail.gmail.com>
Message-ID: <CAH6Pt5qawD1=AFzDTB7Fg2v_sAMTBA6ML3jViC5rycN04GyW_g@mail.gmail.com>

On Sat, Aug 15, 2015 at 10:02 AM, Nathaniel Smith <njs at pobox.com> wrote:
> +1
>
> The arguments against the image are compelling in their own right, but
> even if they weren't it doesn't matter -- we shouldn't be shipping an
> image that we don't have any legal right to ship!
>
> On Sat, Aug 15, 2015 at 1:43 AM, Ralf Gommers <ralf.gommers at gmail.com> wrote:
>> Hi all,
>>
>> The Lena image that we ship is a standard image in the image processing
>> literature, however it's also controversial (see
>> https://en.wikipedia.org/wiki/Lenna). That was the reason for:
>> - adding 2 new images in scipy 0.12.0
>> (https://github.com/scipy/scipy/pull/351)
>> - recommending to not using Lena in the documentation in scipy 0.16.0
>> (https://github.com/scipy/scipy/pull/4785)
>>
>> Now it looks like Debian was decided that the licensing of this image is NOK
>> and that it needs to be removed from all of Debian. Which hasn't affected
>> Scipy yet but has affected scikit-image (it's "marked for auto-removal"):
>> https://groups.google.com/forum/#!topic/scikit-image/q36bajdvWew
>> https://groups.google.com/forum/#!topic/scikit-image/8d15Egg7qAY
>>
>> I know opinions on the image itself and on Debian's action will vary, but
>> I'd like to be pragmatic here and prevent issues with Scipy packaging in
>> Debian. Therefore I propose to do the same as what scikit-image will do:
>> remove Lena for the next release and raise an error from the
>> scipy.misc.lena() function.

I agree, I would be glad to see Lena fully retired.  If anyone needs
the image, it's easy for them to find it, and an error seems like the
right outcome from `scipy.misc.lena`.

Cheers,

Matthew


From sturla.molden at gmail.com  Sat Aug 15 08:25:00 2015
From: sturla.molden at gmail.com (Sturla Molden)
Date: Sat, 15 Aug 2015 12:25:00 +0000 (UTC)
Subject: [SciPy-Dev] removing the Lena image
References: <CABL7CQi1Ka13jxKrptPFf8WtW9rfuemSdtRHRo4pBABKo2uyGA@mail.gmail.com>
Message-ID: <1734402398461333719.198043sturla.molden-gmail.com@news.gmane.org>

Ralf Gommers <ralf.gommers at gmail.com> wrote:

> The Lena image that we ship is a standard image in the image processing
> literature, however it's also controversial

Even though Playboy is a source of adult material, the Lena image in itself
is not sexist.

We know who owns the copyright. Why not ask Playboy for permission?


Sturla



From pav at iki.fi  Sat Aug 15 08:35:00 2015
From: pav at iki.fi (Pauli Virtanen)
Date: Sat, 15 Aug 2015 15:35:00 +0300
Subject: [SciPy-Dev] removing the Lena image
In-Reply-To: <1734402398461333719.198043sturla.molden-gmail.com@news.gmane.org>
References: <CABL7CQi1Ka13jxKrptPFf8WtW9rfuemSdtRHRo4pBABKo2uyGA@mail.gmail.com>
	<1734402398461333719.198043sturla.molden-gmail.com@news.gmane.org>
Message-ID: <mqnblk$ln5$1@ger.gmane.org>

15.08.2015, 15:25, Sturla Molden kirjoitti:
[clip]

Maybe you're not serious, but there's really nothing to be gained from
the image.




From matthew.brett at gmail.com  Sat Aug 15 08:40:05 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Sat, 15 Aug 2015 13:40:05 +0100
Subject: [SciPy-Dev] removing the Lena image
In-Reply-To: <1734402398461333719.198043sturla.molden-gmail.com@news.gmane.org>
References: <CABL7CQi1Ka13jxKrptPFf8WtW9rfuemSdtRHRo4pBABKo2uyGA@mail.gmail.com>
	<1734402398461333719.198043sturla.molden-gmail.com@news.gmane.org>
Message-ID: <CAH6Pt5oUb7pynjQ1o2i=1_OawhXhRexyJLPgLxqP5YvrgC2+8A@mail.gmail.com>

On Sat, Aug 15, 2015 at 1:25 PM, Sturla Molden <sturla.molden at gmail.com> wrote:
> Ralf Gommers <ralf.gommers at gmail.com> wrote:
>
>> The Lena image that we ship is a standard image in the image processing
>> literature, however it's also controversial
>
> Even though Playboy is a source of adult material, the Lena image in itself
> is not sexist.

It's a detail from a pornographic image, and a throwback to a
mysterious age when it was completely ordinary for this to happen in
an image processing lab:

"""
They wanted something glossy to ensure good output dynamic range, and
they wanted a human face. Just then, somebody happened to walk in with
a recent issue of Playboy.
"""

https://en.wikipedia.org/wiki/Lenna

Thank God, that isn't ordinary any more.

As Pauli says - there's no need to keep Lena any more.

Matthew


From scopatz at gmail.com  Sat Aug 15 10:36:25 2015
From: scopatz at gmail.com (Anthony Scopatz)
Date: Sat, 15 Aug 2015 14:36:25 +0000
Subject: [SciPy-Dev] removing the Lena image
In-Reply-To: <CAH6Pt5oUb7pynjQ1o2i=1_OawhXhRexyJLPgLxqP5YvrgC2+8A@mail.gmail.com>
References: <CABL7CQi1Ka13jxKrptPFf8WtW9rfuemSdtRHRo4pBABKo2uyGA@mail.gmail.com>
	<1734402398461333719.198043sturla.molden-gmail.com@news.gmane.org>
	<CAH6Pt5oUb7pynjQ1o2i=1_OawhXhRexyJLPgLxqP5YvrgC2+8A@mail.gmail.com>
Message-ID: <CAPk-6T7ZgmOKeY0Xv=JDPWCinHnw_U5UtG6UCWb+7HP3JNBNLg@mail.gmail.com>

+1 for the removal. I think getting rid of it is long overdue.

On Sat, Aug 15, 2015, 08:40 Matthew Brett <matthew.brett at gmail.com> wrote:

> On Sat, Aug 15, 2015 at 1:25 PM, Sturla Molden <sturla.molden at gmail.com>
> wrote:
> > Ralf Gommers <ralf.gommers at gmail.com> wrote:
> >
> >> The Lena image that we ship is a standard image in the image processing
> >> literature, however it's also controversial
> >
> > Even though Playboy is a source of adult material, the Lena image in
> itself
> > is not sexist.
>
> It's a detail from a pornographic image, and a throwback to a
> mysterious age when it was completely ordinary for this to happen in
> an image processing lab:
>
> """
> They wanted something glossy to ensure good output dynamic range, and
> they wanted a human face. Just then, somebody happened to walk in with
> a recent issue of Playboy.
> """
>
> https://en.wikipedia.org/wiki/Lenna
>
> Thank God, that isn't ordinary any more.
>
> As Pauli says - there's no need to keep Lena any more.
>
> Matthew
> _______________________________________________
> 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/20150815/6b7b8e8f/attachment.html>

From carsonc at gmail.com  Sat Aug 15 11:03:36 2015
From: carsonc at gmail.com (Cantwell Carson)
Date: Sat, 15 Aug 2015 11:03:36 -0400
Subject: [SciPy-Dev] removing the Lena image
Message-ID: <CAKM1Ckr46BF2ZKEwieZHaAzpFzsYTjAFhNpdL3kO+kxsMwzzpg@mail.gmail.com>

My only concern is that existing code might rely on being able to invoke an
image with this command. Then, rather than depreciate and remove, why don't
we replace the image. After some discussion here, I think the best
candidate would be an image of a cat. There are enough pictures of cats
available to select one with identical dimensions and similar color
characteristics.
On Aug 15, 2015 8:40 AM, "Matthew Brett" <matthew.brett at gmail.com> wrote:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150815/8f2792f1/attachment.html>

From alan.isaac at gmail.com  Sat Aug 15 11:12:25 2015
From: alan.isaac at gmail.com (Alan G Isaac)
Date: Sat, 15 Aug 2015 11:12:25 -0400
Subject: [SciPy-Dev] removing the Lena image
In-Reply-To: <CAH6Pt5oUb7pynjQ1o2i=1_OawhXhRexyJLPgLxqP5YvrgC2+8A@mail.gmail.com>
References: <CABL7CQi1Ka13jxKrptPFf8WtW9rfuemSdtRHRo4pBABKo2uyGA@mail.gmail.com>
	<1734402398461333719.198043sturla.molden-gmail.com@news.gmane.org>
	<CAH6Pt5oUb7pynjQ1o2i=1_OawhXhRexyJLPgLxqP5YvrgC2+8A@mail.gmail.com>
Message-ID: <55CF56D9.3090007@gmail.com>

On 8/15/2015 8:40 AM, Matthew Brett wrote:
> It's a detail from a pornographic image


One may oppose the image without exaggerating:
the original photo was merely erotic, not pornographic.
And as for the cropped image that has become a reference
standard, it is unobjectionable if culturally archaic.

An excess of political correctness is difficult
to distinguish from censorship.

Just to be clear, I am not trying to make a case
for including the image.  There may be some case
for skimage.data.lena() to fetch the image from
the USC-SIPI Image Database
http://sipi.usc.edu/database/download.php?vol=misc&img=4.2.04
but I am not trying to make that case either.
I am merely addressing an issue of the debasement
of language.

Cheers,
Alan Isaac



From archibald at astron.nl  Sat Aug 15 12:10:07 2015
From: archibald at astron.nl (Anne Archibald)
Date: Sat, 15 Aug 2015 16:10:07 +0000
Subject: [SciPy-Dev] removing the Lena image
In-Reply-To: <55CF56D9.3090007@gmail.com>
References: <CABL7CQi1Ka13jxKrptPFf8WtW9rfuemSdtRHRo4pBABKo2uyGA@mail.gmail.com>
	<1734402398461333719.198043sturla.molden-gmail.com@news.gmane.org>
	<CAH6Pt5oUb7pynjQ1o2i=1_OawhXhRexyJLPgLxqP5YvrgC2+8A@mail.gmail.com>
	<55CF56D9.3090007@gmail.com>
Message-ID: <CANm_+ZoX-0goBJr3pD5bPKUAOQyqmUZ+QJZ0Vr+HuYSUgGF5rg@mail.gmail.com>

On Sat, Aug 15, 2015 at 5:12 PM Alan G Isaac <alan.isaac at gmail.com> wrote:

> On 8/15/2015 8:40 AM, Matthew Brett wrote:
> > It's a detail from a pornographic image
>
>
> One may oppose the image without exaggerating:
> the original photo was merely erotic, not pornographic.
> And as for the cropped image that has become a reference
> standard, it is unobjectionable if culturally archaic.
>

If we're being precise about language, this image is not unobjectionable:
there are indeed people who have objections to it:
http://www.cmc.edu/news/every-picture-tells-a-story
https://www.cs.umd.edu/users/oleary/faculty/node8.html
https://www.washingtonpost.com/opinions/a-playboy-centerfold-does-not-belong-in-tj-classrooms/2015/04/24/76e87fa4-e47a-11e4-81ea-0649268f729e_story.html

An excess of political correctness is difficult
> to distinguish from censorship.
>

We could have a discussion about culture, feminism, microaggressions, and
the potential for widespread small choices to do harm. Such discussions are
often ugly and divisive, perhaps because the harms under discussion are not
apparent to some people. But this image is not being proposed for removal
for feminist reasons. It is being proposed for removal because the license
is a problem.

For my part, I think the license problem is real and reason enough for
removal. The feminist issues with the image are part of why I have no
motivation to attempt to obtain permission. (Perhaps one could obtain
permission to include the image but only with a Playboy-bunny watermark?)

Just to be clear, I am not trying to make a case
> for including the image.  There may be some case
> for skimage.data.lena() to fetch the image from
> the USC-SIPI Image Database
> http://sipi.usc.edu/database/download.php?vol=misc&img=4.2.04
> but I am not trying to make that case either.
> I am merely addressing an issue of the debasement
> of language.
>

Please don't play devil's advocate or language-lawyer with social-justice
issues. It makes the discussions more stressful and unpleasant without
actually raising substantive points.

Thanks,
Anne
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150815/7d74676a/attachment.html>

From jaime.frio at gmail.com  Sat Aug 15 13:09:21 2015
From: jaime.frio at gmail.com (=?UTF-8?Q?Jaime_Fern=C3=A1ndez_del_R=C3=ADo?=)
Date: Sat, 15 Aug 2015 10:09:21 -0700
Subject: [SciPy-Dev] removing the Lena image
In-Reply-To: <CANm_+ZoX-0goBJr3pD5bPKUAOQyqmUZ+QJZ0Vr+HuYSUgGF5rg@mail.gmail.com>
References: <CABL7CQi1Ka13jxKrptPFf8WtW9rfuemSdtRHRo4pBABKo2uyGA@mail.gmail.com>
	<1734402398461333719.198043sturla.molden-gmail.com@news.gmane.org>
	<CAH6Pt5oUb7pynjQ1o2i=1_OawhXhRexyJLPgLxqP5YvrgC2+8A@mail.gmail.com>
	<55CF56D9.3090007@gmail.com>
	<CANm_+ZoX-0goBJr3pD5bPKUAOQyqmUZ+QJZ0Vr+HuYSUgGF5rg@mail.gmail.com>
Message-ID: <CAPOWHW=t4G9Wt3v70t=k6+xbdsQobpN8Bwt-TuaNCv+b1bHt3w@mail.gmail.com>

On Sat, Aug 15, 2015 at 9:10 AM, Anne Archibald <archibald at astron.nl> wrote:

>
> On Sat, Aug 15, 2015 at 5:12 PM Alan G Isaac <alan.isaac at gmail.com> wrote:
>
>> On 8/15/2015 8:40 AM, Matthew Brett wrote:
>> > It's a detail from a pornographic image
>>
>>
>> One may oppose the image without exaggerating:
>> the original photo was merely erotic, not pornographic.
>> And as for the cropped image that has become a reference
>> standard, it is unobjectionable if culturally archaic.
>>
>
> If we're being precise about language, this image is not unobjectionable:
> there are indeed people who have objections to it:
> http://www.cmc.edu/news/every-picture-tells-a-story
> https://www.cs.umd.edu/users/oleary/faculty/node8.html
>
> https://www.washingtonpost.com/opinions/a-playboy-centerfold-does-not-belong-in-tj-classrooms/2015/04/24/76e87fa4-e47a-11e4-81ea-0649268f729e_story.html
>
> An excess of political correctness is difficult
>> to distinguish from censorship.
>>
>
> We could have a discussion about culture, feminism, microaggressions, and
> the potential for widespread small choices to do harm. Such discussions are
> often ugly and divisive, perhaps because the harms under discussion are not
> apparent to some people. But this image is not being proposed for removal
> for feminist reasons. It is being proposed for removal because the license
> is a problem.
>
> For my part, I think the license problem is real and reason enough for
> removal. The feminist issues with the image are part of why I have no
> motivation to attempt to obtain permission. (Perhaps one could obtain
> permission to include the image but only with a Playboy-bunny watermark?)
>
> Just to be clear, I am not trying to make a case
>> for including the image.  There may be some case
>> for skimage.data.lena() to fetch the image from
>> the USC-SIPI Image Database
>> http://sipi.usc.edu/database/download.php?vol=misc&img=4.2.04
>> but I am not trying to make that case either.
>> I am merely addressing an issue of the debasement
>> of language.
>>
>
> Please don't play devil's advocate or language-lawyer with social-justice
> issues. It makes the discussions more stressful and unpleasant without
> actually raising substantive points.
>

+1 for removal.

Josep Tarradellas, upon returning to Barcelona after 42 years of exile
during Franco's dictatorship, is quoted as saying a local version of Ben
Parker's power and responsibility phrase: "We can do anything, except
embarrass ourselves."

That an all-white-male committee were to determine that there is nothing
objectionable with the Lena image, aside from the copyright, and thus send
a representation to the Playboy mansion to discuss licensing, would
certainly not pass the embarrassment test for me.

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/20150815/7dc6976b/attachment.html>

From alan.isaac at gmail.com  Sat Aug 15 13:45:26 2015
From: alan.isaac at gmail.com (Alan G Isaac)
Date: Sat, 15 Aug 2015 13:45:26 -0400
Subject: [SciPy-Dev] removing the Lena image
In-Reply-To: <CANm_+ZoX-0goBJr3pD5bPKUAOQyqmUZ+QJZ0Vr+HuYSUgGF5rg@mail.gmail.com>
References: <CABL7CQi1Ka13jxKrptPFf8WtW9rfuemSdtRHRo4pBABKo2uyGA@mail.gmail.com>
	<1734402398461333719.198043sturla.molden-gmail.com@news.gmane.org>
	<CAH6Pt5oUb7pynjQ1o2i=1_OawhXhRexyJLPgLxqP5YvrgC2+8A@mail.gmail.com>
	<55CF56D9.3090007@gmail.com>
	<CANm_+ZoX-0goBJr3pD5bPKUAOQyqmUZ+QJZ0Vr+HuYSUgGF5rg@mail.gmail.com>
Message-ID: <55CF7AB6.2080906@gmail.com>

On 8/15/2015 12:10 PM, Anne Archibald wrote:
> If we're being precise about language, this image is not unobjectionable: there are indeed people who have objections to it:

You misunderstand: I was *asserting* that it is unobjectionable.
Merely noting that some people object is the wrong measure,
and that is the path to censorship.   For a recent discussion, I recommend
http://www.theatlantic.com/magazine/archive/2015/09/the-coddling-of-the-american-mind/399356/


> this image is not being proposed for removal
> for feminist reasons. It is being proposed for removal because the license is a problem.

As you know, I made no case against removing it.
Someone else mentioned the possibility of code breaking.
If code breaking is a concern, it would be possible
for skimage.data.lena() to fetch the image from the USC-SIPI Image Database
http://sipi.usc.edu/database/download.php?vol=misc&img=4.2.04


> Please don't play devil's advocate or language-lawyer with social-justice issues.

I did neither.
I do claim that there is no social justice issue involved
beyond the risk that the vagaries of popular opinion can be
advanced as justifications for censorship and cultural destruction.
For a recent discussion, I recommend
http://laurakipnis.com/wp-content/uploads/2010/08/My-Title-IX-Inquisition-The-Chronicle-Review-.pdf

Don't worry; I'll say nothing further about this.

Cheers,
Alan Isaac



From ralf.gommers at gmail.com  Sat Aug 15 14:14:06 2015
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sat, 15 Aug 2015 20:14:06 +0200
Subject: [SciPy-Dev] removing the Lena image
In-Reply-To: <CAKM1Ckr46BF2ZKEwieZHaAzpFzsYTjAFhNpdL3kO+kxsMwzzpg@mail.gmail.com>
References: <CAKM1Ckr46BF2ZKEwieZHaAzpFzsYTjAFhNpdL3kO+kxsMwzzpg@mail.gmail.com>
Message-ID: <CABL7CQi=F-JvLo7VSLtFxGiLVsSLES0frQ71tEkVFWt7BpSqGg@mail.gmail.com>

On Sat, Aug 15, 2015 at 5:03 PM, Cantwell Carson <carsonc at gmail.com> wrote:

> My only concern is that existing code might rely on being able to invoke
> an image with this command.
>
That will be the case. Example:
http://scipy-lectures.github.io/advanced/image_processing/index.html

> Then, rather than depreciate and remove, why don't we replace the image.
>
I think that's worse than an exception. An exception will be visible and
people can fix their code. Silently returning a different image may go
undetected.

Ideally we'd have a release with a deprecation warning and then remove the
function in the release after that, however in this case the extra 6-8
months may become an issue. Given that the impact will probably not be very
large (it's mostly examples and not people's production/research code that
will break), I'm in favor of removing it straight away.

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

From sturla.molden at gmail.com  Sat Aug 15 17:02:39 2015
From: sturla.molden at gmail.com (Sturla Molden)
Date: Sat, 15 Aug 2015 21:02:39 +0000 (UTC)
Subject: [SciPy-Dev] removing the Lena image
References: <CAKM1Ckr46BF2ZKEwieZHaAzpFzsYTjAFhNpdL3kO+kxsMwzzpg@mail.gmail.com>
	<CABL7CQi=F-JvLo7VSLtFxGiLVsSLES0frQ71tEkVFWt7BpSqGg@mail.gmail.com>
Message-ID: <732448899461365275.223017sturla.molden-gmail.com@news.gmane.org>

Ralf Gommers <ralf.gommers at gmail.com> wrote:

> I think that's worse than an exception. An exception will be visible and
> people can fix their code. Silently returning a different image may go
> undetected.

Yes, returning an image of a cat is certainly unacceptable. It should
return the IEEE Lena test image or raise an error.

Sturla



From carsonc at gmail.com  Sat Aug 15 17:19:55 2015
From: carsonc at gmail.com (Cantwell Carson)
Date: Sat, 15 Aug 2015 17:19:55 -0400
Subject: [SciPy-Dev] removing the Lena image
In-Reply-To: <732448899461365275.223017sturla.molden-gmail.com@news.gmane.org>
References: <CAKM1Ckr46BF2ZKEwieZHaAzpFzsYTjAFhNpdL3kO+kxsMwzzpg@mail.gmail.com>
	<CABL7CQi=F-JvLo7VSLtFxGiLVsSLES0frQ71tEkVFWt7BpSqGg@mail.gmail.com>
	<732448899461365275.223017sturla.molden-gmail.com@news.gmane.org>
Message-ID: <CAKM1CkqmN9T55008VqfK9J7VM-B_UQkpjQu3gbJcDwz+bhem1g@mail.gmail.com>

On Sat, Aug 15, 2015 at 5:02 PM, Sturla Molden <sturla.molden at gmail.com>
wrote:

> Ralf Gommers <ralf.gommers at gmail.com> wrote:
>
> > I think that's worse than an exception. An exception will be visible and
> > people can fix their code. Silently returning a different image may go
> > undetected.
>
> Yes, returning an image of a cat is certainly unacceptable. It should
> return the IEEE Lena test image or raise an error.
>

Although I think that would be humorous, I can see why it would not be a
good idea. My suggestion then is to remove Lena and provide an exception
suggesting an alternative command, perhaps scipy.misc.cat. I will even go
so far as to suggest a specific image of a cat, as used in the zhanxw's cat
project <https://github.com/zhanxw/cat/blob/master/cat.jpg>. This returns
the desired error, but retains the convenience that the previous image
provided.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150815/507b9a28/attachment.html>

From sturla.molden at gmail.com  Sat Aug 15 17:20:01 2015
From: sturla.molden at gmail.com (Sturla Molden)
Date: Sat, 15 Aug 2015 21:20:01 +0000 (UTC)
Subject: [SciPy-Dev] removing the Lena image
References: <CABL7CQi1Ka13jxKrptPFf8WtW9rfuemSdtRHRo4pBABKo2uyGA@mail.gmail.com>
	<1734402398461333719.198043sturla.molden-gmail.com@news.gmane.org>
	<CAH6Pt5oUb7pynjQ1o2i=1_OawhXhRexyJLPgLxqP5YvrgC2+8A@mail.gmail.com>
	<55CF56D9.3090007@gmail.com>
	<CANm_+ZoX-0goBJr3pD5bPKUAOQyqmUZ+QJZ0Vr+HuYSUgGF5rg@mail.gmail.com>
Message-ID: <1994947888461365387.489666sturla.molden-gmail.com@news.gmane.org>

Anne Archibald <archibald at astron.nl> wrote:

> For my part, I think the license problem is real and reason enough for
> removal. 

I think it is clear who owns the copyright. But legality is also a matter
of what is fair use.

> The feminist issues with the image are part of why I have no
> motivation to attempt to obtain permission. (Perhaps one could obtain
> permission to include the image but only with a Playboy-bunny watermark?)

Perhaps they would allow us to ship the uncropped original as well, with
bunnies of course. Or we could add a "sponsored by Playboy Magazine" notice
on the website. :D

(I am just being silly.)



Sturla



From robert.kern at gmail.com  Sat Aug 15 17:43:39 2015
From: robert.kern at gmail.com (Robert Kern)
Date: Sat, 15 Aug 2015 22:43:39 +0100
Subject: [SciPy-Dev] removing the Lena image
In-Reply-To: <1994947888461365387.489666sturla.molden-gmail.com@news.gmane.org>
References: <CABL7CQi1Ka13jxKrptPFf8WtW9rfuemSdtRHRo4pBABKo2uyGA@mail.gmail.com>
	<1734402398461333719.198043sturla.molden-gmail.com@news.gmane.org>
	<CAH6Pt5oUb7pynjQ1o2i=1_OawhXhRexyJLPgLxqP5YvrgC2+8A@mail.gmail.com>
	<55CF56D9.3090007@gmail.com>
	<CANm_+ZoX-0goBJr3pD5bPKUAOQyqmUZ+QJZ0Vr+HuYSUgGF5rg@mail.gmail.com>
	<1994947888461365387.489666sturla.molden-gmail.com@news.gmane.org>
Message-ID: <CAF6FJiuSoBX-QvSDP7cLio5cNpGN94hCov3p2LJpD4kEVckXHQ@mail.gmail.com>

On Sat, Aug 15, 2015 at 10:20 PM, Sturla Molden <sturla.molden at gmail.com>
wrote:
>
> Anne Archibald <archibald at astron.nl> wrote:
>
> > For my part, I think the license problem is real and reason enough for
> > removal.
>
> I think it is clear who owns the copyright.

Exactly: someone who has not given us permission to redistribute their
copyrighted image. That is the license problem that Anne was referencing.

> But legality is also a matter
> of what is fair use.

Our redistribution of that image is categorically not fair use in any
jurisdiction I am familiar with, much less all jurisdictions.

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

From gclenaghan at gmail.com  Sat Aug 15 17:56:37 2015
From: gclenaghan at gmail.com (Graham Clenaghan)
Date: Sat, 15 Aug 2015 21:56:37 +0000
Subject: [SciPy-Dev] Fit method for discrete distributions in scipy.stats?
Message-ID: <CAKbVQdxOhNeghCMpnoVfz8rtL+oYunzNGOFYvzVxg62iVLShUA@mail.gmail.com>

Hi all,

Recently I needed to fit a Zipf distribution to some data for an
application and noticed that while scipy has a fit method for the
continuous distributions, it has none for any discrete distributions.

Is there any reason for this, or has it just not been done yet? There
aren't that many discrete distributions and I'd be happy to try to put
together a PR to add this, but I'd just like to make sure that there is no
specific reason it's not already there before I start writing any code.

One possible issue I can think of is that some distributions have discrete
shape parameters (i.e. binomial and the number of trials): an MLE estimate
would probably return a non-integer (the distributions accept non-integers
just fine).

Thoughts?

Thanks,
Graham Clenaghan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150815/076e76c5/attachment.html>

From josef.pktd at gmail.com  Sat Aug 15 18:27:10 2015
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Sat, 15 Aug 2015 18:27:10 -0400
Subject: [SciPy-Dev] Fit method for discrete distributions in
	scipy.stats?
In-Reply-To: <CAKbVQdxOhNeghCMpnoVfz8rtL+oYunzNGOFYvzVxg62iVLShUA@mail.gmail.com>
References: <CAKbVQdxOhNeghCMpnoVfz8rtL+oYunzNGOFYvzVxg62iVLShUA@mail.gmail.com>
Message-ID: <CAMMTP+BGTo_aCRSgDdt_dut0nWk7twoObcn-pv4Df-=5-XNLzA@mail.gmail.com>

On Sat, Aug 15, 2015 at 5:56 PM, Graham Clenaghan <gclenaghan at gmail.com>
wrote:

> Hi all,
>
> Recently I needed to fit a Zipf distribution to some data for an
> application and noticed that while scipy has a fit method for the
> continuous distributions, it has none for any discrete distributions.
>
> Is there any reason for this, or has it just not been done yet? There
> aren't that many discrete distributions and I'd be happy to try to put
> together a PR to add this, but I'd just like to make sure that there is no
> specific reason it's not already there before I start writing any code.
>
> One possible issue I can think of is that some distributions have discrete
> shape parameters (i.e. binomial and the number of trials): an MLE estimate
> would probably return a non-integer (the distributions accept non-integers
> just fine).
>


That and that many parameters also have strong interval restrictions are
the main reason.

The main reason I guess is that nobody went over these cases. My guess is
that a generic setup will not work very well, and it might be better to add
fit methods on a case by case basis.

statsmodels is fitting binomial (fixed n), Poisson and Negative Binomial
models. All of them have loc fixed at zero. The parameter restrictions are
imposed by nonlinear transformations (link functions in GLM). Some like
Negative Binomial are also reparameterized, which is pretty common of there
is no parameter for the mean.


I think we could add fit methods for restricted usage, e.g. Poisson fit
with loc=0 is just the mean of the data, IIRC. Binomial with fixed n and
fixed loc is just the proportion, IIRC. I don't know about estimating Zipf.

Estimating parameters where the support of the distribution depends on the
parameters, e.g. hypergeom, might be difficult, I never tried.

Also, I is not clear whether the distributions generalize to real numbers
if the parameters are supposed to be int. Some do, some don't, or some
generalize for some methods but not for others, AFAIR.

If loc is estimated as in the continuous distribution, it would have to be
restricted to integers.


The alternative would be to get the limited cases where it makes sense
(fixed loc, fixed n) into statsmodels, or one of the powerlaw packages for
zipf.

(Evgenyi is now the main maintainer for stats.distributions, with support
by several others.)

Josef






>
> Thoughts?
>
> Thanks,
> Graham Clenaghan
>
> _______________________________________________
> 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/20150815/b6792a14/attachment.html>

From charlesr.harris at gmail.com  Sat Aug 15 18:31:36 2015
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Sat, 15 Aug 2015 16:31:36 -0600
Subject: [SciPy-Dev] removing the Lena image
In-Reply-To: <CABL7CQi1Ka13jxKrptPFf8WtW9rfuemSdtRHRo4pBABKo2uyGA@mail.gmail.com>
References: <CABL7CQi1Ka13jxKrptPFf8WtW9rfuemSdtRHRo4pBABKo2uyGA@mail.gmail.com>
Message-ID: <CAB6mnx+pxacWxV8WFUOmiqaebtQKODpaWRp8iuvL1n3_K8wdZw@mail.gmail.com>

On Sat, Aug 15, 2015 at 2:43 AM, Ralf Gommers <ralf.gommers at gmail.com>
wrote:

> Hi all,
>
> The Lena image that we ship is a standard image in the image processing
> literature, however it's also controversial (see
> https://en.wikipedia.org/wiki/Lenna). That was the reason for:
> - adding 2 new images in scipy 0.12.0 (
> https://github.com/scipy/scipy/pull/351)
> - recommending to not using Lena in the documentation in scipy 0.16.0 (
> https://github.com/scipy/scipy/pull/4785)
>
> Now it looks like Debian was decided that the licensing of this image is
> NOK and that it needs to be removed from all of Debian. Which hasn't
> affected Scipy yet but has affected scikit-image (it's "marked for
> auto-removal"):
> https://groups.google.com/forum/#!topic/scikit-image/q36bajdvWew
> https://groups.google.com/forum/#!topic/scikit-image/8d15Egg7qAY
>
> I know opinions on the image itself and on Debian's action will vary, but
> I'd like to be pragmatic here and prevent issues with Scipy packaging in
> Debian. Therefore I propose to do the same as what scikit-image will do:
> remove Lena for the next release and raise an error from the
> scipy.misc.lena() function.
>
>
I don't have a problem with removing the image for the reasons given,
although I suspect the underlying motivation is not based on legality. The
main danger I see is bringing politics into the project, and if this
settles that issue, so much the better.  Unfortunately compromise, rather
than bringing peace in our time, often serves to encourage further
incursions. Now may be a good time to think hard about how to keep numpy
and scipy focused on technical issues and out of the political mud pits.

Once upon a time Playboy was considered progressive by some, mostly on
account of its attack on traditional sexual morality. It is funny how that
has played out.

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

From larson.eric.d at gmail.com  Sat Aug 15 20:12:45 2015
From: larson.eric.d at gmail.com (Eric Larson)
Date: Sat, 15 Aug 2015 20:12:45 -0400
Subject: [SciPy-Dev] removing the Lena image
In-Reply-To: <CABL7CQi1Ka13jxKrptPFf8WtW9rfuemSdtRHRo4pBABKo2uyGA@mail.gmail.com>
References: <CABL7CQi1Ka13jxKrptPFf8WtW9rfuemSdtRHRo4pBABKo2uyGA@mail.gmail.com>
Message-ID: <CAGu2niVD10NeX+5ZKeNbsYQwwpmLbVe-m=t+yrxCegML_j3GxA@mail.gmail.com>

+1 for removal.

It sounds to me like we've reached sufficient convergence on the issue of
removing the image. I'm happy to open a PR with an error suggesting the
existing `ascent` and `face` (https://github.com/scipy/scipy/pull/351/files)
instead, unless someone else is already on it.

Eric


On Sat, Aug 15, 2015 at 4:43 AM, Ralf Gommers <ralf.gommers at gmail.com>
wrote:

> Hi all,
>
> The Lena image that we ship is a standard image in the image processing
> literature, however it's also controversial (see
> https://en.wikipedia.org/wiki/Lenna). That was the reason for:
> - adding 2 new images in scipy 0.12.0 (
> https://github.com/scipy/scipy/pull/351)
> - recommending to not using Lena in the documentation in scipy 0.16.0 (
> https://github.com/scipy/scipy/pull/4785)
>
> Now it looks like Debian was decided that the licensing of this image is
> NOK and that it needs to be removed from all of Debian. Which hasn't
> affected Scipy yet but has affected scikit-image (it's "marked for
> auto-removal"):
> https://groups.google.com/forum/#!topic/scikit-image/q36bajdvWew
> https://groups.google.com/forum/#!topic/scikit-image/8d15Egg7qAY
>
> I know opinions on the image itself and on Debian's action will vary, but
> I'd like to be pragmatic here and prevent issues with Scipy packaging in
> Debian. Therefore I propose to do the same as what scikit-image will do:
> remove Lena for the next release and raise an error from the
> scipy.misc.lena() function.
>
> 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/20150815/60b668db/attachment.html>

From ralf.gommers at gmail.com  Sun Aug 16 02:25:32 2015
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sun, 16 Aug 2015 08:25:32 +0200
Subject: [SciPy-Dev] removing the Lena image
In-Reply-To: <CAGu2niVD10NeX+5ZKeNbsYQwwpmLbVe-m=t+yrxCegML_j3GxA@mail.gmail.com>
References: <CABL7CQi1Ka13jxKrptPFf8WtW9rfuemSdtRHRo4pBABKo2uyGA@mail.gmail.com>
	<CAGu2niVD10NeX+5ZKeNbsYQwwpmLbVe-m=t+yrxCegML_j3GxA@mail.gmail.com>
Message-ID: <CABL7CQjgeKn5qHieCk0JVoFBQ-f+go1fTifnZu=av2LosU5H3g@mail.gmail.com>

On Sun, Aug 16, 2015 at 2:12 AM, Eric Larson <larson.eric.d at gmail.com>
wrote:

> +1 for removal.
>
> It sounds to me like we've reached sufficient convergence on the issue of
> removing the image. I'm happy to open a PR with an error suggesting the
> existing `ascent` and `face` (
> https://github.com/scipy/scipy/pull/351/files) instead, unless someone
> else is already on it.
>

Thanks Eric, a PR would be great.

Ralf



>
> Eric
>
>
> On Sat, Aug 15, 2015 at 4:43 AM, Ralf Gommers <ralf.gommers at gmail.com>
> wrote:
>
>> Hi all,
>>
>> The Lena image that we ship is a standard image in the image processing
>> literature, however it's also controversial (see
>> https://en.wikipedia.org/wiki/Lenna). That was the reason for:
>> - adding 2 new images in scipy 0.12.0 (
>> https://github.com/scipy/scipy/pull/351)
>> - recommending to not using Lena in the documentation in scipy 0.16.0 (
>> https://github.com/scipy/scipy/pull/4785)
>>
>> Now it looks like Debian was decided that the licensing of this image is
>> NOK and that it needs to be removed from all of Debian. Which hasn't
>> affected Scipy yet but has affected scikit-image (it's "marked for
>> auto-removal"):
>> https://groups.google.com/forum/#!topic/scikit-image/q36bajdvWew
>> https://groups.google.com/forum/#!topic/scikit-image/8d15Egg7qAY
>>
>> I know opinions on the image itself and on Debian's action will vary, but
>> I'd like to be pragmatic here and prevent issues with Scipy packaging in
>> Debian. Therefore I propose to do the same as what scikit-image will do:
>> remove Lena for the next release and raise an error from the
>> scipy.misc.lena() function.
>>
>> 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/20150816/3b3e8613/attachment.html>

From kasturi.surya at gmail.com  Mon Aug 17 12:45:13 2015
From: kasturi.surya at gmail.com (Surya)
Date: Mon, 17 Aug 2015 22:15:13 +0530
Subject: [SciPy-Dev] Need help on scipy central header + logo
Message-ID: <CAArdDCoopJXigm1OqAO_CSxQyU3JhiG+m43cNyXNxWARru7V6A@mail.gmail.com>

?Hello,

I'm finalizing on scipy central logo now. Thus, looking forward for any
suggestions/opinions.

I found the theme described in https://github.com/tonysyu/SciPy-Central-Logo
interesting, and used it partially.

The below are the two variants (I'd prefer the latter - for the reason that
the green part isn't visible anyway).

Thanks
Surya


[image: Inline image 1]
[image: Inline image 2]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150817/96095018/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scipycentral_logo.png
Type: image/png
Size: 25628 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150817/96095018/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scipycentral_logo.png
Type: image/png
Size: 21865 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150817/96095018/attachment-0001.png>

From ralf.gommers at gmail.com  Mon Aug 17 16:03:11 2015
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Mon, 17 Aug 2015 22:03:11 +0200
Subject: [SciPy-Dev] Need help on scipy central header + logo
In-Reply-To: <CAArdDCoopJXigm1OqAO_CSxQyU3JhiG+m43cNyXNxWARru7V6A@mail.gmail.com>
References: <CAArdDCoopJXigm1OqAO_CSxQyU3JhiG+m43cNyXNxWARru7V6A@mail.gmail.com>
Message-ID: <CABL7CQhNmmN5p=daun0HZaFmsrvNAyWtX_6p7km8fjb=pv11nA@mail.gmail.com>

On Mon, Aug 17, 2015 at 6:45 PM, Surya <kasturi.surya at gmail.com> wrote:

> ?Hello,
>
> I'm finalizing on scipy central logo now. Thus, looking forward for any
> suggestions/opinions.
>
> I found the theme described in
> https://github.com/tonysyu/SciPy-Central-Logo interesting, and used it
> partially.
>
> The below are the two variants (I'd prefer the latter - for the reason
> that the green part isn't visible anyway).
>

I also prefer the all blue variant. A major improvement on the logo (if one
can call it that) that's on scipy-central.org now.

Cheers,
Ralf



> Thanks
> Surya
>
>
> [image: Inline image 1]
> [image: Inline image 2]
>
> _______________________________________________
> 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/20150817/adbb2cd3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scipycentral_logo.png
Type: image/png
Size: 21865 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150817/adbb2cd3/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scipycentral_logo.png
Type: image/png
Size: 25628 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150817/adbb2cd3/attachment-0001.png>

From hodge at stsci.edu  Mon Aug 17 16:10:52 2015
From: hodge at stsci.edu (Phil Hodge)
Date: Mon, 17 Aug 2015 16:10:52 -0400
Subject: [SciPy-Dev] Need help on scipy central header + logo
In-Reply-To: <CAArdDCoopJXigm1OqAO_CSxQyU3JhiG+m43cNyXNxWARru7V6A@mail.gmail.com>
References: <CAArdDCoopJXigm1OqAO_CSxQyU3JhiG+m43cNyXNxWARru7V6A@mail.gmail.com>
Message-ID: <55D23FCC.20607@stsci.edu>

I also prefer the version that does not include the green.  I would 
suggest, however, that the radial lines would look better if the one on 
the upper right were higher and the one on the lower left were lower.  
That is, the ends of the S appear to be too extended.  I'm not sure 
whether I'm expressing myself clearly, but you can compare the S in the 
logo with the S in "SciPy"; the latter looks better to me.

Phil

On 08/17/2015 12:45 PM, Surya wrote:
> ? Hello,
>
> I'm finalizing on scipy central logo now. Thus, looking forward for 
> any suggestions/opinions.
>
> I found the theme described in 
> https://github.com/tonysyu/SciPy-Central-Logo interesting, and used it 
> partially.
>
> The below are the two variants (I'd prefer the latter - for the reason 
> that the green part isn't visible anyway).
>
> Thanks
> Surya
>
>
> Inline image 1
> Inline image 2
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev



From cell at michaelclerx.com  Mon Aug 17 16:29:35 2015
From: cell at michaelclerx.com (Michael Clerx)
Date: Mon, 17 Aug 2015 22:29:35 +0200
Subject: [SciPy-Dev] Need help on scipy central header + logo
In-Reply-To: <55D23FCC.20607@stsci.edu>
References: <CAArdDCoopJXigm1OqAO_CSxQyU3JhiG+m43cNyXNxWARru7V6A@mail.gmail.com>
	<55D23FCC.20607@stsci.edu>
Message-ID: <55D2442F.4080007@michaelclerx.com>

Maybe the radial lines could just be less pronounced, and perhaps 
decrease the difference between the two words? Of course it's great to 
accentuate the "central".

Either way: Looking great!



On 08/17/2015 10:10 PM, Phil Hodge wrote:
> I also prefer the version that does not include the green.  I would
> suggest, however, that the radial lines would look better if the one on
> the upper right were higher and the one on the lower left were lower.
> That is, the ends of the S appear to be too extended.  I'm not sure
> whether I'm expressing myself clearly, but you can compare the S in the
> logo with the S in "SciPy"; the latter looks better to me.
>
> Phil
>
> On 08/17/2015 12:45 PM, Surya wrote:
>> ? Hello,
>>
>> I'm finalizing on scipy central logo now. Thus, looking forward for
>> any suggestions/opinions.
>>
>> I found the theme described in
>> https://github.com/tonysyu/SciPy-Central-Logo interesting, and used it
>> partially.
>>
>> The below are the two variants (I'd prefer the latter - for the reason
>> that the green part isn't visible anyway).
>>
>> Thanks
>> Surya
>>
>>
>> Inline image 1
>> Inline image 2
>>
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev



From ralf.gommers at gmail.com  Tue Aug 18 17:26:07 2015
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Tue, 18 Aug 2015 23:26:07 +0200
Subject: [SciPy-Dev] offline for ~6 weeks
Message-ID: <CABL7CQgm3hO09znvj2hS-+pxxmzkJiTkLMCqJyA4DPBsws=O-w@mail.gmail.com>

Hi all,

Just a quick note to say that I'll be offline for pretty much the whole
period 25 Aug - 9 Oct.

Regarding a possible 0.16.1 release: I don't see a reason to cut a release
right now, but if a quick release is required for whatever reason then
please go ahead without me.

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

From tsyu80 at gmail.com  Wed Aug 19 01:34:41 2015
From: tsyu80 at gmail.com (Tony Yu)
Date: Wed, 19 Aug 2015 00:34:41 -0500
Subject: [SciPy-Dev] Need help on scipy central header + logo
In-Reply-To: <55D2442F.4080007@michaelclerx.com>
References: <CAArdDCoopJXigm1OqAO_CSxQyU3JhiG+m43cNyXNxWARru7V6A@mail.gmail.com>
	<55D23FCC.20607@stsci.edu> <55D2442F.4080007@michaelclerx.com>
Message-ID: <CAEym_Hp87LhW_fWKcqh9j2zxm0LmyEX3+zg7eCOGpndadnbzjQ@mail.gmail.com>

On Mon, Aug 17, 2015 at 3:29 PM, Michael Clerx <cell at michaelclerx.com>
wrote:

> Maybe the radial lines could just be less pronounced, and perhaps
> decrease the difference between the two words? Of course it's great to
> accentuate the "central".
>
> Either way: Looking great!
>
>
>
> On 08/17/2015 10:10 PM, Phil Hodge wrote:
> > I also prefer the version that does not include the green.  I would
> > suggest, however, that the radial lines would look better if the one on
> > the upper right were higher and the one on the lower left were lower.
> > That is, the ends of the S appear to be too extended.  I'm not sure
> > whether I'm expressing myself clearly, but you can compare the S in the
> > logo with the S in "SciPy"; the latter looks better to me.
> >
> > Phil
> >
> > On 08/17/2015 12:45 PM, Surya wrote:
> >> ? Hello,
> >>
> >> I'm finalizing on scipy central logo now. Thus, looking forward for
> >> any suggestions/opinions.
> >>
> >> I found the theme described in
> >> https://github.com/tonysyu/SciPy-Central-Logo interesting, and used it
> >> partially.
>

Wow, it's been a long time since I've looked at this old script. I've
updated the code in that repo to create a banner based on my personal
preferences. It's a bit finicky to reproduce, since I'm using a
non-standard font (Google's Roboto-Light
<https://www.google.com/fonts#UsePlace:use/Collection:Roboto>), but I like
the look of it. Here's what it looks like now:

[image: Inline image 1]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150819/41af24a9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scipy_central_logo_atlantic.png
Type: image/png
Size: 24644 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150819/41af24a9/attachment.png>

From fperez.net at gmail.com  Wed Aug 26 01:24:21 2015
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 25 Aug 2015 22:24:21 -0700
Subject: [SciPy-Dev] Python extensions for Python 3.5 - useful info...
Message-ID: <CAHAreOrBN7svj14gfb69+fU=aYQLi2LKNv_gVQkm+HEUX7PGPw@mail.gmail.com>

Just an FYI for the upcoming Python release, a very detailed post from
Steve Dower, the Microsoft developer who is now in charge of the Windows
releases for Python, on how the build process will change in 3.5 regarding
extensions:

http://stevedower.id.au/blog/building-for-python-3-5/

Cheers,

f
-- 
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150825/1304be9b/attachment.html>

From manuel.munoz at correounivalle.edu.co  Wed Aug 26 10:14:13 2015
From: manuel.munoz at correounivalle.edu.co (MANUEL HUMBERTO MUNOZ ARIAS)
Date: Wed, 26 Aug 2015 09:14:13 -0500
Subject: [SciPy-Dev] scipy.sparse.linalg.eigsh routine crashing for negative
	values of the parameter.
Message-ID: <CAOvzSQ_esn0W-Ppyt1Aog7PcLvRLJMJ4=evbTWUuvDpDj+245w@mail.gmail.com>

Good Day scipy-dev members,

Recently I have been working with the diagonalization routines of scipy, I
am doing an study if the eigenvalues of a certain matrix, in particular I
have interest in the differences between these eigenvalues. In order to do
that I am doing the diagonalization process of each of the values of a
parameter in a linespace, the diagonalization it has been carried out with
the scipy.sparse.linalg.eigsh routine for few eigenvalues, however it seems
to crash for negative values of the parameter. Why is this happening? In
order to make my point more clear I have attached a plot of the difference
between the first two eigenvalues.

Thanks in advance,

Manuel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150826/5f901249/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gap_e1-e0.png
Type: image/png
Size: 14189 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150826/5f901249/attachment.png>

From arokem at gmail.com  Wed Aug 26 20:11:05 2015
From: arokem at gmail.com (Ariel Rokem)
Date: Wed, 26 Aug 2015 17:11:05 -0700
Subject: [SciPy-Dev] RBF epsilon (changes 0.15 => 0.16)
Message-ID: <CA+X4w0xw1896_jeD=Kwcju1a=H-+3-orN3CwcAHAf6kyxB_40g@mail.gmail.com>

Hi everyone,

In our work on dipy, we've run into a small issue moving from 0.15 to 0.16:

https://github.com/nipy/dipy/issues/688

The gist of this is that we are using RBF to interpolate a signal measured
on the unit sphere. To do this, we have designed a custom 'norm' function
based on the angle between measurements (rather than the default
Euclidean). Code is here:

https://github.com/nipy/dipy/blob/master/dipy/core/sphere.py#L500

This seemed to work fine with 0.15, but the changes to the default epsilon
introduced here: https://github.com/scipy/scipy/pull/4643 seem to be
throwing us off.

I've taken a look at the discussion on that PR and the issue that led to
this work, and it does make sense, but I wanted to get some feedback to see
how we should proceed. Setting a larger default epsilon in our code
(effectively undoing this change) would be one way to go, but I want to
make sure that it wouldn't be an obvious blunder, and that there isn't some
issue on scipy that we should be thinking about.

Thanks!

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

From kasturi.surya at gmail.com  Fri Aug 28 10:09:56 2015
From: kasturi.surya at gmail.com (Surya)
Date: Fri, 28 Aug 2015 19:39:56 +0530
Subject: [SciPy-Dev] Need help on scipy central header + logo
In-Reply-To: <CAEym_Hp87LhW_fWKcqh9j2zxm0LmyEX3+zg7eCOGpndadnbzjQ@mail.gmail.com>
References: <CAArdDCoopJXigm1OqAO_CSxQyU3JhiG+m43cNyXNxWARru7V6A@mail.gmail.com>
	<55D23FCC.20607@stsci.edu> <55D2442F.4080007@michaelclerx.com>
	<CAEym_Hp87LhW_fWKcqh9j2zxm0LmyEX3+zg7eCOGpndadnbzjQ@mail.gmail.com>
Message-ID: <CAArdDCo3XsqH12u_dLUuDsq=GcRTEhEFwBsJQASkH-DZmm1VoQ@mail.gmail.com>

Thanks all for your inputs.

I will a tab on all these suggests for the next version of the logo!

On Wed, Aug 19, 2015 at 11:04 AM, Tony Yu <tsyu80 at gmail.com> wrote:

>
> On Mon, Aug 17, 2015 at 3:29 PM, Michael Clerx <cell at michaelclerx.com>
> wrote:
>
>> Maybe the radial lines could just be less pronounced, and perhaps
>> decrease the difference between the two words? Of course it's great to
>> accentuate the "central".
>>
>> Either way: Looking great!
>>
>>
>>
>> On 08/17/2015 10:10 PM, Phil Hodge wrote:
>> > I also prefer the version that does not include the green.  I would
>> > suggest, however, that the radial lines would look better if the one on
>> > the upper right were higher and the one on the lower left were lower.
>> > That is, the ends of the S appear to be too extended.  I'm not sure
>> > whether I'm expressing myself clearly, but you can compare the S in the
>> > logo with the S in "SciPy"; the latter looks better to me.
>> >
>> > Phil
>> >
>> > On 08/17/2015 12:45 PM, Surya wrote:
>> >> ? Hello,
>> >>
>> >> I'm finalizing on scipy central logo now. Thus, looking forward for
>> >> any suggestions/opinions.
>> >>
>> >> I found the theme described in
>> >> https://github.com/tonysyu/SciPy-Central-Logo interesting, and used it
>> >> partially.
>>
>
> Wow, it's been a long time since I've looked at this old script. I've
> updated the code in that repo to create a banner based on my personal
> preferences. It's a bit finicky to reproduce, since I'm using a
> non-standard font (Google's Roboto-Light
> <https://www.google.com/fonts#UsePlace:use/Collection:Roboto>), but I
> like the look of it. Here's what it looks like now:
>
> [image: Inline image 1]
>
>
>
> _______________________________________________
> 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/20150828/b1bbbac1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scipy_central_logo_atlantic.png
Type: image/png
Size: 24644 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150828/b1bbbac1/attachment.png>

From evgeny.burovskiy at gmail.com  Fri Aug 28 14:33:51 2015
From: evgeny.burovskiy at gmail.com (Evgeni Burovski)
Date: Fri, 28 Aug 2015 19:33:51 +0100
Subject: [SciPy-Dev] RBF epsilon (changes 0.15 => 0.16)
In-Reply-To: <CA+X4w0xw1896_jeD=Kwcju1a=H-+3-orN3CwcAHAf6kyxB_40g@mail.gmail.com>
References: <CA+X4w0xw1896_jeD=Kwcju1a=H-+3-orN3CwcAHAf6kyxB_40g@mail.gmail.com>
Message-ID: <CAMRo0iufMwPV2Bbaq0tbYWFJLnX4wpMVje+i9goa6aSqT_Nxfg@mail.gmail.com>

Hi Ariel,

Off-the-cuff, I'd think that the value of epsilon is best managed on
the user side.
[I can't say anything intelligent about the issue in dipy, so I'd
rather say nothing about it].

In general, it seems that scipy's rbf implementation could use some
work, and here's one issue which summarizes some suggestions for it:

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

There is also a PR,

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

which was closed by the author, and I'm not sure what's the status of it.

As things stand, chances are that we'll be tempted to break backwards
compat for scipy.interpolate.Rbf. Since you're using it, your
suggestions are most welcome (and patches are even more so!)

Cheers,

Evgeni



On Thu, Aug 27, 2015 at 1:11 AM, Ariel Rokem <arokem at gmail.com> wrote:
> Hi everyone,
>
> In our work on dipy, we've run into a small issue moving from 0.15 to 0.16:
>
> https://github.com/nipy/dipy/issues/688
>
> The gist of this is that we are using RBF to interpolate a signal measured
> on the unit sphere. To do this, we have designed a custom 'norm' function
> based on the angle between measurements (rather than the default Euclidean).
> Code is here:
>
> https://github.com/nipy/dipy/blob/master/dipy/core/sphere.py#L500
>
> This seemed to work fine with 0.15, but the changes to the default epsilon
> introduced here: https://github.com/scipy/scipy/pull/4643 seem to be
> throwing us off.
>
> I've taken a look at the discussion on that PR and the issue that led to
> this work, and it does make sense, but I wanted to get some feedback to see
> how we should proceed. Setting a larger default epsilon in our code
> (effectively undoing this change) would be one way to go, but I want to make
> sure that it wouldn't be an obvious blunder, and that there isn't some issue
> on scipy that we should be thinking about.
>
> Thanks!
>
> Ariel
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From thomas.haslwanter at gmail.com  Sat Aug 29 15:21:43 2015
From: thomas.haslwanter at gmail.com (Thomas Haslwanter)
Date: Sat, 29 Aug 2015 21:21:43 +0200
Subject: [SciPy-Dev] Need help on scipy central header + logo
In-Reply-To: <CAEym_Hp87LhW_fWKcqh9j2zxm0LmyEX3+zg7eCOGpndadnbzjQ@mail.gmail.com>
References: <CAArdDCoopJXigm1OqAO_CSxQyU3JhiG+m43cNyXNxWARru7V6A@mail.gmail.com>
	<55D23FCC.20607@stsci.edu> <55D2442F.4080007@michaelclerx.com>
	<CAEym_Hp87LhW_fWKcqh9j2zxm0LmyEX3+zg7eCOGpndadnbzjQ@mail.gmail.com>
Message-ID: <CAD0YMynJTuu5z6YtUrhg5N2QSMrLVgw9yuFNtTLbSrMwSaXXnw@mail.gmail.com>

I think the light/dark blue one is really pretty. Don't like the green/blue
combo very much.

On Wed, Aug 19, 2015 at 7:34 AM, Tony Yu <tsyu80 at gmail.com> wrote:

>
> On Mon, Aug 17, 2015 at 3:29 PM, Michael Clerx <cell at michaelclerx.com>
> wrote:
>
>> Maybe the radial lines could just be less pronounced, and perhaps
>> decrease the difference between the two words? Of course it's great to
>> accentuate the "central".
>>
>> Either way: Looking great!
>>
>>
>>
>> On 08/17/2015 10:10 PM, Phil Hodge wrote:
>> > I also prefer the version that does not include the green.  I would
>> > suggest, however, that the radial lines would look better if the one on
>> > the upper right were higher and the one on the lower left were lower.
>> > That is, the ends of the S appear to be too extended.  I'm not sure
>> > whether I'm expressing myself clearly, but you can compare the S in the
>> > logo with the S in "SciPy"; the latter looks better to me.
>> >
>> > Phil
>> >
>> > On 08/17/2015 12:45 PM, Surya wrote:
>> >> ? Hello,
>> >>
>> >> I'm finalizing on scipy central logo now. Thus, looking forward for
>> >> any suggestions/opinions.
>> >>
>> >> I found the theme described in
>> >> https://github.com/tonysyu/SciPy-Central-Logo interesting, and used it
>> >> partially.
>>
>
> Wow, it's been a long time since I've looked at this old script. I've
> updated the code in that repo to create a banner based on my personal
> preferences. It's a bit finicky to reproduce, since I'm using a
> non-standard font (Google's Roboto-Light
> <https://www.google.com/fonts#UsePlace:use/Collection:Roboto>), but I
> like the look of it. Here's what it looks like now:
>
> [image: Inline image 1]
>
>
>
> _______________________________________________
> 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/20150829/5e246c51/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scipy_central_logo_atlantic.png
Type: image/png
Size: 24644 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150829/5e246c51/attachment.png>

From arokem at gmail.com  Sun Aug 30 23:46:32 2015
From: arokem at gmail.com (Ariel Rokem)
Date: Sun, 30 Aug 2015 20:46:32 -0700
Subject: [SciPy-Dev] RBF epsilon (changes 0.15 => 0.16)
In-Reply-To: <CAMRo0iufMwPV2Bbaq0tbYWFJLnX4wpMVje+i9goa6aSqT_Nxfg@mail.gmail.com>
References: <CA+X4w0xw1896_jeD=Kwcju1a=H-+3-orN3CwcAHAf6kyxB_40g@mail.gmail.com>
	<CAMRo0iufMwPV2Bbaq0tbYWFJLnX4wpMVje+i9goa6aSqT_Nxfg@mail.gmail.com>
Message-ID: <CA+X4w0ybznQnBoCOBxgF89UROFii9SbLJorfKn4D8tiWFK39Tw@mail.gmail.com>

Hi Evgeni - thanks for the feedback!

On Fri, Aug 28, 2015 at 11:33 AM, Evgeni Burovski <
evgeny.burovskiy at gmail.com> wrote:

> Hi Ariel,
>
> Off-the-cuff, I'd think that the value of epsilon is best managed on
> the user side.
> [I can't say anything intelligent about the issue in dipy, so I'd
> rather say nothing about it].
>

That was my intuition. Just wanted to make sure we're not doing anything
crazy.

In general, it seems that scipy's rbf implementation could use some
> work, and here's one issue which summarizes some suggestions for it:
>
> https://github.com/scipy/scipy/issues/4790
>
> There is also a PR,
>
> https://github.com/scipy/scipy/pull/5070
>
> which was closed by the author, and I'm not sure what's the status of it.
>
> As things stand, chances are that we'll be tempted to break backwards
> compat for scipy.interpolate.Rbf. Since you're using it, your
> suggestions are most welcome (and patches are even more so!)
>
> OK - I will read up on this topic (I see there are some suggestions on
that issue), and try to see whether I can be helpful.

Thanks again,

Ariel


> Cheers,
>
> Evgeni
>
>
>
> On Thu, Aug 27, 2015 at 1:11 AM, Ariel Rokem <arokem at gmail.com> wrote:
> > Hi everyone,
> >
> > In our work on dipy, we've run into a small issue moving from 0.15 to
> 0.16:
> >
> > https://github.com/nipy/dipy/issues/688
> >
> > The gist of this is that we are using RBF to interpolate a signal
> measured
> > on the unit sphere. To do this, we have designed a custom 'norm' function
> > based on the angle between measurements (rather than the default
> Euclidean).
> > Code is here:
> >
> > https://github.com/nipy/dipy/blob/master/dipy/core/sphere.py#L500
> >
> > This seemed to work fine with 0.15, but the changes to the default
> epsilon
> > introduced here: https://github.com/scipy/scipy/pull/4643 seem to be
> > throwing us off.
> >
> > I've taken a look at the discussion on that PR and the issue that led to
> > this work, and it does make sense, but I wanted to get some feedback to
> see
> > how we should proceed. Setting a larger default epsilon in our code
> > (effectively undoing this change) would be one way to go, but I want to
> make
> > sure that it wouldn't be an obvious blunder, and that there isn't some
> issue
> > on scipy that we should be thinking about.
> >
> > Thanks!
> >
> > Ariel
> >
> > _______________________________________________
> > 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/20150830/f5de7f67/attachment.html>