From andyfaff at gmail.com  Fri Apr  1 00:56:52 2016
From: andyfaff at gmail.com (Andrew Nelson)
Date: Fri, 1 Apr 2016 15:56:52 +1100
Subject: [SciPy-Dev] Sampling from arbitrary distributions
Message-ID: <CAAbtOZeX7ds7yNU_f=VQ+g1t5R3KRTEWLs4c0FFKhA+fLm-A_g@mail.gmail.com>

Hi all,
I have a need to take samples from an arbitrary continuous statistical
distribution. By arbitrary I mean it doesn't have an exact functional form.
Rather, the distribution was created by sampling a physical process and
then histogramming.
I then wish to randomly sample from this distribution for a monte carlo
simulation. Whilst I could (in this circumstance) sample with replacement
from my original measurement I thought it might be quite cool to subclass
scipy.stats.rv_continuous to do it, see the gist for further info.

https://gist.github.com/andyfaff/9a7930f3d93a99f478cdadae4d1bb3b2

This way one gets lots of other benefits for free (e.g. the CDF, PPF,
calculation of statistical moments, etc). I was wondering if this might be
a useful thing to add to scipy.stats. I'm not overly familiar with the
stats module so I thought I'd ask this again on the dev list (I asked this
question on the user list a couple of days ago).

The class does store state because it needs to do interpolation, etc. It
was suggested that the "Histogram distribution would be the continuous
analog to the arbitrary finite number of points discrete distribution, so
might fit as well."
Don't get too caught up by it working on histogrammed data, it should be
straightforward to modify it to act for a distribution that has no analytic
functional form, but where PDF(x) is known for many x.

A.

-- 
_____________________________________
Dr. Andrew Nelson


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

From evgeny.burovskiy at gmail.com  Fri Apr  1 06:34:35 2016
From: evgeny.burovskiy at gmail.com (Evgeni Burovski)
Date: Fri, 1 Apr 2016 11:34:35 +0100
Subject: [SciPy-Dev] Sampling from arbitrary distributions
In-Reply-To: <CAAbtOZeX7ds7yNU_f=VQ+g1t5R3KRTEWLs4c0FFKhA+fLm-A_g@mail.gmail.com>
References: <CAAbtOZeX7ds7yNU_f=VQ+g1t5R3KRTEWLs4c0FFKhA+fLm-A_g@mail.gmail.com>
Message-ID: <CAMRo0ivdL2w3K5n=OGUvNd_WjhqwLk=9c9Rtbu59e4yZOiCSdA@mail.gmail.com>

+1

This wheel gets reinvented often (FWIW, I certainly did, several times,
when doing MC simulations).

One thing to spell out is *what* is this object you're adding. If, as you
say, it's a discrete distribution (your "sample with replacement" comment),
it's served by rv_discrete already. Otherwise, it boils down to if this is
a histogram --- then the PDF is piecewise constant and cdf is piecewise
linear, or you interpret the points as a result of some sort of tabulation
--- then some non-linear interpolation can be more appropriate.

Cheers,

Evgeni
On Apr 1, 2016 7:56 AM, "Andrew Nelson" <andyfaff at gmail.com> wrote:

> Hi all,
> I have a need to take samples from an arbitrary continuous statistical
> distribution. By arbitrary I mean it doesn't have an exact functional form.
> Rather, the distribution was created by sampling a physical process and
> then histogramming.
> I then wish to randomly sample from this distribution for a monte carlo
> simulation. Whilst I could (in this circumstance) sample with replacement
> from my original measurement I thought it might be quite cool to subclass
> scipy.stats.rv_continuous to do it, see the gist for further info.
>
> https://gist.github.com/andyfaff/9a7930f3d93a99f478cdadae4d1bb3b2
>
> This way one gets lots of other benefits for free (e.g. the CDF, PPF,
> calculation of statistical moments, etc). I was wondering if this might be
> a useful thing to add to scipy.stats. I'm not overly familiar with the
> stats module so I thought I'd ask this again on the dev list (I asked this
> question on the user list a couple of days ago).
>
> The class does store state because it needs to do interpolation, etc. It
> was suggested that the "Histogram distribution would be the continuous
> analog to the arbitrary finite number of points discrete distribution, so
> might fit as well."
> Don't get too caught up by it working on histogrammed data, it should be
> straightforward to modify it to act for a distribution that has no analytic
> functional form, but where PDF(x) is known for many x.
>
> A.
>
> --
> _____________________________________
> Dr. Andrew Nelson
>
>
> _____________________________________
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> https://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20160401/fe7268e9/attachment.html>

From andyfaff at gmail.com  Sun Apr  3 19:28:48 2016
From: andyfaff at gmail.com (Andrew Nelson)
Date: Mon, 4 Apr 2016 09:28:48 +1000
Subject: [SciPy-Dev] Sampling from arbitrary distributions
In-Reply-To: <CAMRo0ivdL2w3K5n=OGUvNd_WjhqwLk=9c9Rtbu59e4yZOiCSdA@mail.gmail.com>
References: <CAAbtOZeX7ds7yNU_f=VQ+g1t5R3KRTEWLs4c0FFKhA+fLm-A_g@mail.gmail.com>
 <CAMRo0ivdL2w3K5n=OGUvNd_WjhqwLk=9c9Rtbu59e4yZOiCSdA@mail.gmail.com>
Message-ID: <CAAbtOZdPyUwFT99=U2swKbTjBQCSKUpYZVxVmDJv1fC4CrkomQ@mail.gmail.com>

Sorry, to be crystal clear it's an arbitrary distribution for continuous
variables whose functional form isn't known, there is only empirical
evidence. In the following examples I've used a Gaussian distribution, but
it doesn't have to be:

from scipy.stats import arbitrary
import numpy as np

# where the empirical distribution is known from a histogram
arb = arbitrary(*np.histogram(np.random.randn(10000), bins=101,
density=True))

# where the empirical distribution is known from known y(x),
non-histogrammed
gau = lambda x, mu, sigma: np.exp(-0.5 * ((x - mu) / sigma)**2)
x = np.linspace(-4, 4, 100)
y = gau(x, 0, 1)
arb = arbitrary(y, x)

I think there would need to be different "modes". As Evgeni pointed out if
it's a histogram then the PDF is piecewise constant and the CDF is
piecewise linear. But one might want to specify different interpolation
methods for calculating PDF/CDF. I'm not sure what the best approach for
that is.

A.





On 1 April 2016 at 21:34, Evgeni Burovski <evgeny.burovskiy at gmail.com>
wrote:

> +1
>
> This wheel gets reinvented often (FWIW, I certainly did, several times,
> when doing MC simulations).
>
> One thing to spell out is *what* is this object you're adding. If, as you
> say, it's a discrete distribution (your "sample with replacement" comment),
> it's served by rv_discrete already. Otherwise, it boils down to if this is
> a histogram --- then the PDF is piecewise constant and cdf is piecewise
> linear, or you interpret the points as a result of some sort of tabulation
> --- then some non-linear interpolation can be more appropriate.
>
> Cheers,
>
> Evgeni
> On Apr 1, 2016 7:56 AM, "Andrew Nelson" <andyfaff at gmail.com> wrote:
>
>> Hi all,
>> I have a need to take samples from an arbitrary continuous statistical
>> distribution. By arbitrary I mean it doesn't have an exact functional form.
>> Rather, the distribution was created by sampling a physical process and
>> then histogramming.
>> I then wish to randomly sample from this distribution for a monte carlo
>> simulation. Whilst I could (in this circumstance) sample with replacement
>> from my original measurement I thought it might be quite cool to subclass
>> scipy.stats.rv_continuous to do it, see the gist for further info.
>>
>> https://gist.github.com/andyfaff/9a7930f3d93a99f478cdadae4d1bb3b2
>>
>> This way one gets lots of other benefits for free (e.g. the CDF, PPF,
>> calculation of statistical moments, etc). I was wondering if this might be
>> a useful thing to add to scipy.stats. I'm not overly familiar with the
>> stats module so I thought I'd ask this again on the dev list (I asked this
>> question on the user list a couple of days ago).
>>
>> The class does store state because it needs to do interpolation, etc. It
>> was suggested that the "Histogram distribution would be the continuous
>> analog to the arbitrary finite number of points discrete distribution,
>> so might fit as well."
>> Don't get too caught up by it working on histogrammed data, it should be
>> straightforward to modify it to act for a distribution that has no analytic
>> functional form, but where PDF(x) is known for many x.
>>
>> A.
>>
>> --
>> _____________________________________
>> Dr. Andrew Nelson
>>
>>
>> _____________________________________
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> https://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> https://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/20160404/61ac3ccd/attachment.html>

From stefan.c.endres at gmail.com  Mon Apr  4 10:54:35 2016
From: stefan.c.endres at gmail.com (Stefan Endres)
Date: Mon, 4 Apr 2016 16:54:35 +0200
Subject: [SciPy-Dev] Introducing scipy.optimization.tgo;
	a global optimization routine.
Message-ID: <CALhqKPCgUSGwrgpjWnAdiwSGS1Vjjn_MFMvfWm7a4tBR66eFog@mail.gmail.com>

Hello all,

I?d like to present this implementation of the Topographical Global
Optimisation (TGO) method, a powerfull global optimisation method first
proposed by T?rn (1990) [1]. The implementation is written entirely in
python using mostly boolean numpy arrays to implement the core algorithm
and using scipy.optimize.minimize to find local minima.

https://github.com/Stefan-Endres/tgo

TGO is a clustering method that uses graph theory to generate good starting
points for local search methods from points distributed uniformly in the
interior of the feasible set. These points are currently generated using
the Sobol (1967) [3] sequence. The semi-empirical correlation by Hendorson
et. al. (2015) [2] for k integer defining the k-t matrix. The latter
publication used an (unpublished as far as I can tell) C/C++ implementation
which was comparatively succesful against commercial software (MIDACO 4.0).

More details can be found in the docstrings in
https://github.com/Stefan-Endres/tgo

Some features in brief.

   - Global optimisation of multivariate functions with
      - Bounded or unbounded variables.
      - Optional non-linear constraints.
   - Returns an ordered list of all local minima with the res.xl attribute
   and corresponding function values res.fun (this is something that I?ve
   found very useful in my own research).
   - Highly customisable to increase performance on difficult optimisation
   problems.
   - The functions were written entirely in python based on algorithms
   available in open literature [2]

As a quick visual illustration of the algorithm?s capabilities, a few
results for common optimisation problems and their results:
http://imgur.com/a/'ll MS0hG <http://imgur.com/a/MS0hG>

I?ve also run a comparison of tgo with the other two global optimisation
currently available.

http://pastebin.com/8K72Xve8

Note in all cases tgo found the correct answer, details on my system can be
found at the end of the pastebin (it?s a terminal session dump). Also I
apologise I?m not very familiar with the basinhopping algorithm so I didn?t
know how many iterations where optimal for the problems and stuck with the
default.

Details on the functions used and their references can be found in the
docstrings in the unittest script:
https://github.com/Stefan-Endres/tgo/blob/master/test__tgo.py
Potential issues

The most important barrier I forsee is the large file size of the direction
numbers used in generating the Sobol sampling points (new-joe-kuo-6.21201
<https://github.com/Stefan-Endres/tgo/blob/master/new-joe-kuo-6.21201>) at
1.8MiB. The code to generate the Sobol points itself is not an issue, it?s
a small script that was translated to Python by one of my advisers for the
project (repository: https://bitbucket.org/alchemyst/sobol/src) from the
original C++ code under a scipy compatible BSD style liscence (
http://web.maths.unsw.edu.au/~fkuo/sobol/).

I suggest the following solutions to this:

   - Use latin hypercube sampling (LHS) to generate the initial points
   instead. LHS is already used in _differentialevolution.py (I?ve tried to
   do this, but I?m not sure how without initiating the entire
   DifferentialEvolutionSolver object).
   - Trim the data file to only including Sobol sequence sampling for
   problems of up to 1000 dimensions. It?s easy to write something to download
   higher dimensional data when a user specifies problems higher than 1000
   dimensions.

I think the sobol_points function is more appropriate numpy.random in the
first from where it can be imported to tgo, but I'm not sure if it's wanted
there.

Everything else was written from scratch so there shouldn?t be any
licensing issues.

I?ve tried to follow the guidelines given in
http://docs.scipy.org/doc/scipy/reference/hacking.html as close as possible
with this repository:
https://github.com/Stefan-Endres/scipy/branches

It?s almost ready for a PR, in particular I don?t really know where/how to
do the following checklists.

   - Is the new functionality tagged with .. versionadded:: X.Y.Z (with
   X.Y.Z the version number of the next release - can be found in setup.py)?
   - Is the new functionality mentioned in the release notes of the next
   release?
   - Is the new functionality added to the reference guide?

References

   1. T?rn, A (1990) ?Topographical global optimization?, Reports on
   Computer Science and Mathematics Ser. A, No 199, 8p. Abo Akademi
   University, Sweden)
   2. Henderson, N et. al (2015) ?A new look at the topographical global
   optimization method and its application to the phase stability analysis of
   mixtures?, Chemical Engineering Science, 127, 151-174
   3. Sobol, IM (1967) ?The distribution of points in a cube and the
   approximate evaluation of integrals. USSR Comput. Math. Math. Phys. 7,
   86-112




If you wish to learn more about the method I highly recommend Hendorson et.
al.?s (2015) article which presents the material in an introductory fashion.

Please let me know what you guys think! I will keep working on this if you
think it?s something that could be included in scipy.

Thank you for reading.

Regards,
-
Stefan Endres
Postgraduate Student: Institute of Applied Materials
Department of Chemical Engineering, University of Pretoria
Cell: +27 (0) 82 972 42 89
E-mail: Stefan.C.Endres at gmail.com
St. Number: 11004968
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20160404/928055b6/attachment.html>

From andrea.gavana at gmail.com  Mon Apr  4 11:45:40 2016
From: andrea.gavana at gmail.com (Andrea Gavana)
Date: Mon, 4 Apr 2016 17:45:40 +0200
Subject: [SciPy-Dev] Introducing scipy.optimization.tgo;
 a global optimization routine.
In-Reply-To: <CALhqKPCgUSGwrgpjWnAdiwSGS1Vjjn_MFMvfWm7a4tBR66eFog@mail.gmail.com>
References: <CALhqKPCgUSGwrgpjWnAdiwSGS1Vjjn_MFMvfWm7a4tBR66eFog@mail.gmail.com>
Message-ID: <CAEf70bw23Uroxjfpe_gcgeQ=8aL7O+Of4mXSh4mWi2xh4xOYUw@mail.gmail.com>

Hi Stefan,

    The algorithm seems very interesting. I haven't gone through the papers
(mostly because I don't have access to those journals ?), so I can't
really say I understand the theoretical basis of it...

However, I believe it would be nice to put TGO through the grinder as I did
in the past with many other algorithms:

http://infinity77.net/global_optimization/multidimensional.html

And take a look to the overall performances. I'm always on the lookout for
GO algorithms available in Python (and actually running on Windows as
well...), so I'll try to find some time soon enough to put TGO as well on
the tables and pictures.

Thank you for sharing!

Andrea.


On Monday, 4 April 2016, Stefan Endres <stefan.c.endres at gmail.com> wrote:

> Hello all,
>
> I?d like to present this implementation of the Topographical Global
> Optimisation (TGO) method, a powerfull global optimisation method first
> proposed by T?rn (1990) [1]. The implementation is written entirely in
> python using mostly boolean numpy arrays to implement the core algorithm
> and using scipy.optimize.minimize to find local minima.
>
> https://github.com/Stefan-Endres/tgo
>
> TGO is a clustering method that uses graph theory to generate good
> starting points for local search methods from points distributed uniformly
> in the interior of the feasible set. These points are currently generated
> using the Sobol (1967) [3] sequence. The semi-empirical correlation by
> Hendorson et. al. (2015) [2] for k integer defining the k-t matrix. The
> latter publication used an (unpublished as far as I can tell) C/C++
> implementation which was comparatively succesful against commercial
> software (MIDACO 4.0).
>
> More details can be found in the docstrings in
> https://github.com/Stefan-Endres/tgo
>
> Some features in brief.
>
>    - Global optimisation of multivariate functions with
>       - Bounded or unbounded variables.
>       - Optional non-linear constraints.
>    - Returns an ordered list of all local minima with the res.xl
>    attribute and corresponding function values res.fun (this is something
>    that I?ve found very useful in my own research).
>    - Highly customisable to increase performance on difficult
>    optimisation problems.
>    - The functions were written entirely in python based on algorithms
>    available in open literature [2]
>
> As a quick visual illustration of the algorithm?s capabilities, a few
> results for common optimisation problems and their results:
> http://imgur.com/a/'ll MS0hG <http://imgur.com/a/MS0hG>
>
> I?ve also run a comparison of tgo with the other two global optimisation
> currently available.
>
> http://pastebin.com/8K72Xve8
>
> Note in all cases tgo found the correct answer, details on my system can
> be found at the end of the pastebin (it?s a terminal session dump). Also I
> apologise I?m not very familiar with the basinhopping algorithm so I didn?t
> know how many iterations where optimal for the problems and stuck with the
> default.
>
> Details on the functions used and their references can be found in the
> docstrings in the unittest script:
> https://github.com/Stefan-Endres/tgo/blob/master/test__tgo.py
> Potential issues
>
> The most important barrier I forsee is the large file size of the
> direction numbers used in generating the Sobol sampling points (
> new-joe-kuo-6.21201
> <https://github.com/Stefan-Endres/tgo/blob/master/new-joe-kuo-6.21201>)
> at 1.8MiB. The code to generate the Sobol points itself is not an issue,
> it?s a small script that was translated to Python by one of my advisers for
> the project (repository: https://bitbucket.org/alchemyst/sobol/src) from
> the original C++ code under a scipy compatible BSD style liscence (
> http://web.maths.unsw.edu.au/~fkuo/sobol/).
>
> I suggest the following solutions to this:
>
>    - Use latin hypercube sampling (LHS) to generate the initial points
>    instead. LHS is already used in _differentialevolution.py (I?ve tried
>    to do this, but I?m not sure how without initiating the entire
>    DifferentialEvolutionSolver object).
>    - Trim the data file to only including Sobol sequence sampling for
>    problems of up to 1000 dimensions. It?s easy to write something to download
>    higher dimensional data when a user specifies problems higher than 1000
>    dimensions.
>
> I think the sobol_points function is more appropriate numpy.random in the
> first from where it can be imported to tgo, but I'm not sure if it's wanted
> there.
>
> Everything else was written from scratch so there shouldn?t be any
> licensing issues.
>
> I?ve tried to follow the guidelines given in
> http://docs.scipy.org/doc/scipy/reference/hacking.html as close as
> possible with this repository:
> https://github.com/Stefan-Endres/scipy/branches
>
> It?s almost ready for a PR, in particular I don?t really know where/how to
> do the following checklists.
>
>    - Is the new functionality tagged with .. versionadded:: X.Y.Z (with
>    X.Y.Z the version number of the next release - can be found in setup.py)?
>    - Is the new functionality mentioned in the release notes of the next
>    release?
>    - Is the new functionality added to the reference guide?
>
> References
>
>    1. T?rn, A (1990) ?Topographical global optimization?, Reports on
>    Computer Science and Mathematics Ser. A, No 199, 8p. Abo Akademi
>    University, Sweden)
>    2. Henderson, N et. al (2015) ?A new look at the topographical global
>    optimization method and its application to the phase stability analysis of
>    mixtures?, Chemical Engineering Science, 127, 151-174
>    3. Sobol, IM (1967) ?The distribution of points in a cube and the
>    approximate evaluation of integrals. USSR Comput. Math. Math. Phys. 7,
>    86-112
>
>
>
>
> If you wish to learn more about the method I highly recommend Hendorson
> et. al.?s (2015) article which presents the material in an introductory
> fashion.
>
> Please let me know what you guys think! I will keep working on this if you
> think it?s something that could be included in scipy.
>
> Thank you for reading.
>
> Regards,
> -
> Stefan Endres
> Postgraduate Student: Institute of Applied Materials
> Department of Chemical Engineering, University of Pretoria
> Cell: +27 (0) 82 972 42 89
> E-mail: Stefan.C.Endres at gmail.com
> <javascript:_e(%7B%7D,'cvml','Stefan.C.Endres at gmail.com');>
> St. Number: 11004968
> ?
>


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

From jstevenson131 at gmail.com  Mon Apr  4 13:21:09 2016
From: jstevenson131 at gmail.com (Jacob Stevenson)
Date: Mon, 04 Apr 2016 17:21:09 +0000
Subject: [SciPy-Dev] Introducing scipy.optimization.tgo;
 a global optimization routine.
In-Reply-To: <CAEf70bw23Uroxjfpe_gcgeQ=8aL7O+Of4mXSh4mWi2xh4xOYUw@mail.gmail.com>
References: <CALhqKPCgUSGwrgpjWnAdiwSGS1Vjjn_MFMvfWm7a4tBR66eFog@mail.gmail.com>
 <CAEf70bw23Uroxjfpe_gcgeQ=8aL7O+Of4mXSh4mWi2xh4xOYUw@mail.gmail.com>
Message-ID: <CAEEL3uxfJMJWtU7UD-K80BQO_cS-NV0R0FxVDoHXbq30=2mtgQ@mail.gmail.com>

I agree that the algorithm looks promising (though I also don't have access
to the papers).  If I understand correctly, a high level summary is

1. sample points from all possible solutions (e.g. sobol points or a simple
grid)
2. discard points that don't look promising
3. perform local optimization on the remaining points.

And I guess the graph theoretic / clustering cleverness comes in step 2.
 (Something along the lines of "keep only points where the K nearest
neighbors all have larger function values", if i'm not mistaken.)

Here are a few thoughts I have, please chime in if I'm making bad
assumptions.

It starts with a grid-like search, and as such probably doesn't scale to
very high dimensions.  But I think that's fine, it would still be
applicable to many (most?) applications.

It's nice that the bounds implementation seems to be fairly robust.  That
is currently a weakness of basinhopping.

I'm curious how the automatic selection of hyper parameters works.  I guess
we'll find out in Andrea's benchmarks.

People would probably find it useful to have a standalone implementation of
sobal sequences.  Maybe it would fit in scipy.spatial?

In general, I think the approach is nicely complementary with basinhopping
and differential evolution.  I think it could be a good fit for scipy.

Thanks for the contribution!
Jacob


On Mon, 4 Apr 2016 at 16:45 Andrea Gavana <andrea.gavana at gmail.com> wrote:

> Hi Stefan,
>
>     The algorithm seems very interesting. I haven't gone through the
> papers (mostly because I don't have access to those journals ?), so I
> can't really say I understand the theoretical basis of it...
>
> However, I believe it would be nice to put TGO through the grinder as I
> did in the past with many other algorithms:
>
> http://infinity77.net/global_optimization/multidimensional.html
>
> And take a look to the overall performances. I'm always on the lookout for
> GO algorithms available in Python (and actually running on Windows as
> well...), so I'll try to find some time soon enough to put TGO as well on
> the tables and pictures.
>
> Thank you for sharing!
>
> Andrea.
>
>
> On Monday, 4 April 2016, Stefan Endres <stefan.c.endres at gmail.com> wrote:
>
>> Hello all,
>>
>> I?d like to present this implementation of the Topographical Global
>> Optimisation (TGO) method, a powerfull global optimisation method first
>> proposed by T?rn (1990) [1]. The implementation is written entirely in
>> python using mostly boolean numpy arrays to implement the core algorithm
>> and using scipy.optimize.minimize to find local minima.
>>
>> https://github.com/Stefan-Endres/tgo
>>
>> TGO is a clustering method that uses graph theory to generate good
>> starting points for local search methods from points distributed uniformly
>> in the interior of the feasible set. These points are currently generated
>> using the Sobol (1967) [3] sequence. The semi-empirical correlation by
>> Hendorson et. al. (2015) [2] for k integer defining the k-t matrix. The
>> latter publication used an (unpublished as far as I can tell) C/C++
>> implementation which was comparatively succesful against commercial
>> software (MIDACO 4.0).
>>
>> More details can be found in the docstrings in
>> https://github.com/Stefan-Endres/tgo
>>
>> Some features in brief.
>>
>>    - Global optimisation of multivariate functions with
>>       - Bounded or unbounded variables.
>>       - Optional non-linear constraints.
>>    - Returns an ordered list of all local minima with the res.xl
>>    attribute and corresponding function values res.fun (this is
>>    something that I?ve found very useful in my own research).
>>    - Highly customisable to increase performance on difficult
>>    optimisation problems.
>>    - The functions were written entirely in python based on algorithms
>>    available in open literature [2]
>>
>> As a quick visual illustration of the algorithm?s capabilities, a few
>> results for common optimisation problems and their results:
>> http://imgur.com/a/'ll MS0hG <http://imgur.com/a/MS0hG>
>>
>> I?ve also run a comparison of tgo with the other two global optimisation
>> currently available.
>>
>> http://pastebin.com/8K72Xve8
>>
>> Note in all cases tgo found the correct answer, details on my system can
>> be found at the end of the pastebin (it?s a terminal session dump). Also I
>> apologise I?m not very familiar with the basinhopping algorithm so I didn?t
>> know how many iterations where optimal for the problems and stuck with the
>> default.
>>
>> Details on the functions used and their references can be found in the
>> docstrings in the unittest script:
>> https://github.com/Stefan-Endres/tgo/blob/master/test__tgo.py
>> Potential issues
>>
>> The most important barrier I forsee is the large file size of the
>> direction numbers used in generating the Sobol sampling points (
>> new-joe-kuo-6.21201
>> <https://github.com/Stefan-Endres/tgo/blob/master/new-joe-kuo-6.21201>)
>> at 1.8MiB. The code to generate the Sobol points itself is not an issue,
>> it?s a small script that was translated to Python by one of my advisers for
>> the project (repository: https://bitbucket.org/alchemyst/sobol/src) from
>> the original C++ code under a scipy compatible BSD style liscence (
>> http://web.maths.unsw.edu.au/~fkuo/sobol/).
>>
>> I suggest the following solutions to this:
>>
>>    - Use latin hypercube sampling (LHS) to generate the initial points
>>    instead. LHS is already used in _differentialevolution.py (I?ve tried
>>    to do this, but I?m not sure how without initiating the entire
>>    DifferentialEvolutionSolver object).
>>    - Trim the data file to only including Sobol sequence sampling for
>>    problems of up to 1000 dimensions. It?s easy to write something to download
>>    higher dimensional data when a user specifies problems higher than 1000
>>    dimensions.
>>
>> I think the sobol_points function is more appropriate numpy.random in
>> the first from where it can be imported to tgo, but I'm not sure if it's
>> wanted there.
>>
>> Everything else was written from scratch so there shouldn?t be any
>> licensing issues.
>>
>> I?ve tried to follow the guidelines given in
>> http://docs.scipy.org/doc/scipy/reference/hacking.html as close as
>> possible with this repository:
>> https://github.com/Stefan-Endres/scipy/branches
>>
>> It?s almost ready for a PR, in particular I don?t really know where/how
>> to do the following checklists.
>>
>>    - Is the new functionality tagged with .. versionadded:: X.Y.Z (with
>>    X.Y.Z the version number of the next release - can be found in setup.py)?
>>    - Is the new functionality mentioned in the release notes of the next
>>    release?
>>    - Is the new functionality added to the reference guide?
>>
>> References
>>
>>    1. T?rn, A (1990) ?Topographical global optimization?, Reports on
>>    Computer Science and Mathematics Ser. A, No 199, 8p. Abo Akademi
>>    University, Sweden)
>>    2. Henderson, N et. al (2015) ?A new look at the topographical global
>>    optimization method and its application to the phase stability analysis of
>>    mixtures?, Chemical Engineering Science, 127, 151-174
>>    3. Sobol, IM (1967) ?The distribution of points in a cube and the
>>    approximate evaluation of integrals. USSR Comput. Math. Math. Phys. 7,
>>    86-112
>>
>>
>>
>>
>> If you wish to learn more about the method I highly recommend Hendorson
>> et. al.?s (2015) article which presents the material in an introductory
>> fashion.
>>
>> Please let me know what you guys think! I will keep working on this if
>> you think it?s something that could be included in scipy.
>>
>> Thank you for reading.
>>
>> Regards,
>> -
>> Stefan Endres
>> Postgraduate Student: Institute of Applied Materials
>> Department of Chemical Engineering, University of Pretoria
>> Cell: +27 (0) 82 972 42 89
>> E-mail: Stefan.C.Endres at gmail.com
>> St. Number: 11004968
>> ?
>>
>
>
> --
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> https://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20160404/d2266c0b/attachment.html>

From stefan.c.endres at gmail.com  Mon Apr  4 14:47:18 2016
From: stefan.c.endres at gmail.com (Stefan Endres)
Date: Mon, 4 Apr 2016 20:47:18 +0200
Subject: [SciPy-Dev] SciPy-Dev Digest, Vol 150, Issue 4
In-Reply-To: <mailman.59845.1459790484.2321.scipy-dev@scipy.org>
References: <mailman.59845.1459790484.2321.scipy-dev@scipy.org>
Message-ID: <CALhqKPDgSeMhCCwSA9B5Q4hhBE6VKy0Jjd=Z8i-_BUe3SPq-Rg@mail.gmail.com>

>1. sample points from all possible solutions (e.g. sobol points or a simple
grid)
>2. discard points that don't look promising
>3. perform local optimization on the remaining points.

>And I guess the graph theoretic / clustering cleverness comes in step 2.
> (Something along the lines of "keep only points where the K nearest
neighbors all have larger function values", if i'm not mistaken.)

Exactly right, in brief the topograph is constructed from an ordered list
based on the euclidean distance between the points, the algorithm compares
the function values of each point and assigns either a positive or negative
sign depending on whether or not the it's higher or lower than the first
point (implemented here as True booleans for positive signs and False
boolean for negative flags). "Minimiser" points are now defined as any row
in the topograph with all positive entries (ie all other points relatively
"near" that point is above it).

Of course, because the sampling is (pseudo-)random you don't want to
compare all the points and have only one minimser, since that might not be
near the actual global minima unless the objective function is convex.
That's where the importance of the k_t integer comes in since it
essentially determines the number points you compare and the number of
minimisers you find (which are ideally not near each other).

I've attached a brief presentation which outlines this construction more
formally for those who are interested (this is cut from a phase equilibrium
lit. review of please ignore the irrelevant references the material balance
constraints etc.).

>probably doesn't scale to very high dimensions.
I don't believe so no, using a very high amount of sampling points would
involve N x N distance calculations organised into an array of the same
dimensions. The highest I've tested is unittest test_t910 which is only 7
dimensions. The highest dimensional problem tested in Henderson's article
is only 20 dimensions.

>It's nice that the bounds implementation seems to be fairly robust.
It does seem to work very well with `SLSQP` so far, I've been using it in
my work for a while and have never had any issues, lets hope it holds for
more complex problems. In the future I'd also like to add equality
constraints to the tgo routine itself (currently it's only used in the
local minimisation step) which would adapt the sampling in a similar way to
the inequality adaption (see the also the figures in the attached
presentation as a visual illustration; I believe there is room for
improvement here by somehow shifting the points uniformly into the feasible
set rather than just discarding them)).

>People would probably find it useful to have a standalone implementation
of sobal sequences.  Maybe it would fit in scipy.spatial?
I agree, it should definitely not be embedded in tgo in any case, my
adviser said he is still planning to do a few code optimisations (this
repository: https://bitbucket.org/alchemyst/sobol/src), I will speak to him
about it once he's finished.

>In general, I think the approach is nicely complementary with basinhopping
and differential evolution.  I think it could be a good fit for scipy.
Excellent! I will start cleaning the branch in the meantime then untill we
figure out where to put the Sobol function.


On 4 April 2016 at 19:21, <scipy-dev-request at scipy.org> wrote:

> Send SciPy-Dev mailing list submissions to
>         scipy-dev at scipy.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.scipy.org/mailman/listinfo/scipy-dev
> or, via email, send a message with subject or body 'help' to
>         scipy-dev-request at scipy.org
>
> You can reach the person managing the list at
>         scipy-dev-owner at scipy.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of SciPy-Dev digest..."
>
>
> Today's Topics:
>
>    1. Re: Introducing scipy.optimization.tgo; a global optimization
>       routine. (Jacob Stevenson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 04 Apr 2016 17:21:09 +0000
> From: Jacob Stevenson <jstevenson131 at gmail.com>
> To: SciPy Developers List <scipy-dev at scipy.org>
> Subject: Re: [SciPy-Dev] Introducing scipy.optimization.tgo; a global
>         optimization routine.
> Message-ID:
>         <CAEEL3uxfJMJWtU7UD-K80BQO_cS-NV0R0FxVDoHXbq30=
> 2mtgQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I agree that the algorithm looks promising (though I also don't have access
> to the papers).  If I understand correctly, a high level summary is
>
> 1. sample points from all possible solutions (e.g. sobol points or a simple
> grid)
> 2. discard points that don't look promising
> 3. perform local optimization on the remaining points.
>
> And I guess the graph theoretic / clustering cleverness comes in step 2.
>  (Something along the lines of "keep only points where the K nearest
> neighbors all have larger function values", if i'm not mistaken.)
>
> Here are a few thoughts I have, please chime in if I'm making bad
> assumptions.
>
> It starts with a grid-like search, and as such probably doesn't scale to
> very high dimensions.  But I think that's fine, it would still be
> applicable to many (most?) applications.
>
> It's nice that the bounds implementation seems to be fairly robust.  That
> is currently a weakness of basinhopping.
>
> I'm curious how the automatic selection of hyper parameters works.  I guess
> we'll find out in Andrea's benchmarks.
>
> People would probably find it useful to have a standalone implementation of
> sobal sequences.  Maybe it would fit in scipy.spatial?
>
> In general, I think the approach is nicely complementary with basinhopping
> and differential evolution.  I think it could be a good fit for scipy.
>
> Thanks for the contribution!
> Jacob
>
>
> On Mon, 4 Apr 2016 at 16:45 Andrea Gavana <andrea.gavana at gmail.com> wrote:
>
> > Hi Stefan,
> >
> >     The algorithm seems very interesting. I haven't gone through the
> > papers (mostly because I don't have access to those journals ?), so I
> > can't really say I understand the theoretical basis of it...
> >
> > However, I believe it would be nice to put TGO through the grinder as I
> > did in the past with many other algorithms:
> >
> > http://infinity77.net/global_optimization/multidimensional.html
> >
> > And take a look to the overall performances. I'm always on the lookout
> for
> > GO algorithms available in Python (and actually running on Windows as
> > well...), so I'll try to find some time soon enough to put TGO as well on
> > the tables and pictures.
> >
> > Thank you for sharing!
> >
> > Andrea.
> >
> >
> > On Monday, 4 April 2016, Stefan Endres <stefan.c.endres at gmail.com>
> wrote:
> >
> >> Hello all,
> >>
> >> I?d like to present this implementation of the Topographical Global
> >> Optimisation (TGO) method, a powerfull global optimisation method first
> >> proposed by T?rn (1990) [1]. The implementation is written entirely in
> >> python using mostly boolean numpy arrays to implement the core algorithm
> >> and using scipy.optimize.minimize to find local minima.
> >>
> >> https://github.com/Stefan-Endres/tgo
> >>
> >> TGO is a clustering method that uses graph theory to generate good
> >> starting points for local search methods from points distributed
> uniformly
> >> in the interior of the feasible set. These points are currently
> generated
> >> using the Sobol (1967) [3] sequence. The semi-empirical correlation by
> >> Hendorson et. al. (2015) [2] for k integer defining the k-t matrix. The
> >> latter publication used an (unpublished as far as I can tell) C/C++
> >> implementation which was comparatively succesful against commercial
> >> software (MIDACO 4.0).
> >>
> >> More details can be found in the docstrings in
> >> https://github.com/Stefan-Endres/tgo
> >>
> >> Some features in brief.
> >>
> >>    - Global optimisation of multivariate functions with
> >>       - Bounded or unbounded variables.
> >>       - Optional non-linear constraints.
> >>    - Returns an ordered list of all local minima with the res.xl
> >>    attribute and corresponding function values res.fun (this is
> >>    something that I?ve found very useful in my own research).
> >>    - Highly customisable to increase performance on difficult
> >>    optimisation problems.
> >>    - The functions were written entirely in python based on algorithms
> >>    available in open literature [2]
> >>
> >> As a quick visual illustration of the algorithm?s capabilities, a few
> >> results for common optimisation problems and their results:
> >> http://imgur.com/a/'ll MS0hG <http://imgur.com/a/MS0hG>
> >>
> >> I?ve also run a comparison of tgo with the other two global optimisation
> >> currently available.
> >>
> >> http://pastebin.com/8K72Xve8
> >>
> >> Note in all cases tgo found the correct answer, details on my system can
> >> be found at the end of the pastebin (it?s a terminal session dump).
> Also I
> >> apologise I?m not very familiar with the basinhopping algorithm so I
> didn?t
> >> know how many iterations where optimal for the problems and stuck with
> the
> >> default.
> >>
> >> Details on the functions used and their references can be found in the
> >> docstrings in the unittest script:
> >> https://github.com/Stefan-Endres/tgo/blob/master/test__tgo.py
> >> Potential issues
> >>
> >> The most important barrier I forsee is the large file size of the
> >> direction numbers used in generating the Sobol sampling points (
> >> new-joe-kuo-6.21201
> >> <https://github.com/Stefan-Endres/tgo/blob/master/new-joe-kuo-6.21201>)
> >> at 1.8MiB. The code to generate the Sobol points itself is not an issue,
> >> it?s a small script that was translated to Python by one of my advisers
> for
> >> the project (repository: https://bitbucket.org/alchemyst/sobol/src)
> from
> >> the original C++ code under a scipy compatible BSD style liscence (
> >> http://web.maths.unsw.edu.au/~fkuo/sobol/).
> >>
> >> I suggest the following solutions to this:
> >>
> >>    - Use latin hypercube sampling (LHS) to generate the initial points
> >>    instead. LHS is already used in _differentialevolution.py (I?ve tried
> >>    to do this, but I?m not sure how without initiating the entire
> >>    DifferentialEvolutionSolver object).
> >>    - Trim the data file to only including Sobol sequence sampling for
> >>    problems of up to 1000 dimensions. It?s easy to write something to
> download
> >>    higher dimensional data when a user specifies problems higher than
> 1000
> >>    dimensions.
> >>
> >> I think the sobol_points function is more appropriate numpy.random in
> >> the first from where it can be imported to tgo, but I'm not sure if it's
> >> wanted there.
> >>
> >> Everything else was written from scratch so there shouldn?t be any
> >> licensing issues.
> >>
> >> I?ve tried to follow the guidelines given in
> >> http://docs.scipy.org/doc/scipy/reference/hacking.html as close as
> >> possible with this repository:
> >> https://github.com/Stefan-Endres/scipy/branches
> >>
> >> It?s almost ready for a PR, in particular I don?t really know where/how
> >> to do the following checklists.
> >>
> >>    - Is the new functionality tagged with .. versionadded:: X.Y.Z (with
> >>    X.Y.Z the version number of the next release - can be found in
> setup.py)?
> >>    - Is the new functionality mentioned in the release notes of the next
> >>    release?
> >>    - Is the new functionality added to the reference guide?
> >>
> >> References
> >>
> >>    1. T?rn, A (1990) ?Topographical global optimization?, Reports on
> >>    Computer Science and Mathematics Ser. A, No 199, 8p. Abo Akademi
> >>    University, Sweden)
> >>    2. Henderson, N et. al (2015) ?A new look at the topographical global
> >>    optimization method and its application to the phase stability
> analysis of
> >>    mixtures?, Chemical Engineering Science, 127, 151-174
> >>    3. Sobol, IM (1967) ?The distribution of points in a cube and the
> >>    approximate evaluation of integrals. USSR Comput. Math. Math. Phys.
> 7,
> >>    86-112
> >>
> >>
> >>
> >>
> >> If you wish to learn more about the method I highly recommend Hendorson
> >> et. al.?s (2015) article which presents the material in an introductory
> >> fashion.
> >>
> >> Please let me know what you guys think! I will keep working on this if
> >> you think it?s something that could be included in scipy.
> >>
> >> Thank you for reading.
> >>
> >> Regards,
> >> -
> >> Stefan Endres
> >> Postgraduate Student: Institute of Applied Materials
> >> Department of Chemical Engineering, University of Pretoria
> >> Cell: +27 (0) 82 972 42 89
> >> E-mail: Stefan.C.Endres at gmail.com
> >> St. Number: 11004968
> >> ?
> >>
> >
> >
> > --
> >
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at scipy.org
> > https://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mail.scipy.org/pipermail/scipy-dev/attachments/20160404/d2266c0b/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> https://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
> ------------------------------
>
> End of SciPy-Dev Digest, Vol 150, Issue 4
> *****************************************
>



-- 
Stefan Endres
Postgraduate Student: Institute of Applied Materials
Department of Chemical Engineering, University of Pretoria
Cell: +27 (0) 82 972 42 89
E-mail: Stefan.C.Endres at gmail.com
St. Number: 11004968
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20160404/abe11fc5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tgo-presentation.pdf
Type: application/pdf
Size: 148157 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20160404/abe11fc5/attachment.pdf>

From alain.batailly at gmail.com  Mon Apr  4 22:00:53 2016
From: alain.batailly at gmail.com (Alain Batailly)
Date: Mon, 4 Apr 2016 22:00:53 -0400
Subject: [SciPy-Dev] scipy.sparse.linalg.spsolve surprising behaviour for
 large sparse matrices on Linux systems
Message-ID: <CABn6Z0sQL-Manr8Cm5=zeMA1eJ1Cy7sHOwORzw_EVYz-04APqg@mail.gmail.com>

Hello,

I am computing the solution of a linear system Ax=b with A a large
(typically 200,000 lines and columns for the associated dense matrix)
sparse matrix and b a sparse matrix of about 100 columns.

When I run my code on Windows systems (Python *2.7*, scipy *0.14.0*), the
following command

from scipy.sparse.linalg import spsolve...Temp = spsolve(A.tocsc(),b.tocsc())

runs smoothly and requires about 7 GB of ram memory.

Running the *exact same code* with the *exact same matrices* on Linux
systems (same CPU, same amount of RAM memory: 64 GB, Linux Mint *17.3*,
python *2.7*, scipy *0.13.3*) requires more than 20 GB of ram memory and it
crashes with the following error message:

<function umfpack_di_numeric at ...> failed with UMFPACK_ERROR_out_of_memory
(see 1 <http://i.stack.imgur.com/ezdPi.png>)

Because this error is os dependent, I ruled out any issue regarding the
matrices *A* and *b*, and I am trying to find a fix specific to Linux...
But I do not know where to start... Does anyone would have any idea of what
is going on ? And why would such a problem be specific to Linux systems ?

After further investigations, it seems that the latest version of BLAS on
Linux Mint is quite old: 1.8.2. On Windows, I use BLAS 1.9.1. When using
the test_numpy.py file available here:
https://gist.github.com/osdf/3842524#file-test_numpy-py I notice very
significant differences between Linux and Windows: *Linux* : version 1.8.2,
maxint 9223372036854775807, dot: 0.76 s - *Windows* : version 1.9.1, maxint
2147483647, dot: 0,037 s.

I realized that the problem may be hardware related. Indeed, an older PC,
with the exact same libraries on the same Linux Mint distribution (Rosa
17.3) provides much more satisfying results. The benchmark mentioned in the
first update gives on this old PC: *Linux* : version 1.8.2, maxint
9223372036854775807, dot: 0,054 s.

Would anybody have observed such behaviour ?

Thank you.

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

From andyfaff at gmail.com  Mon Apr  4 23:35:28 2016
From: andyfaff at gmail.com (Andrew Nelson)
Date: Tue, 5 Apr 2016 13:35:28 +1000
Subject: [SciPy-Dev] Edge case bug in stats.triang?
Message-ID: <CAAbtOZfofKu8p+t61uiWem3-N+UrhvBpeBuejXq38FB+ShzOqg@mail.gmail.com>

I've been investigating the stats.triang.pdf over it's domain with
different modes:

>>> from scipy.stats import triang
>>> triang.pdf(0, 0)
2.0
>>> triang.pdf(1, 1)
nan

Shouldn't the last value be 2?

-- 
_____________________________________
Dr. Andrew Nelson


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

From brianjscannell at gmail.com  Tue Apr  5 16:35:10 2016
From: brianjscannell at gmail.com (Brian Scannell)
Date: Tue, 05 Apr 2016 20:35:10 +0000
Subject: [SciPy-Dev] Introducing scipy.optimization.tgo;
 a global optimization routine.
In-Reply-To: <CAEEL3uxfJMJWtU7UD-K80BQO_cS-NV0R0FxVDoHXbq30=2mtgQ@mail.gmail.com>
References: <CALhqKPCgUSGwrgpjWnAdiwSGS1Vjjn_MFMvfWm7a4tBR66eFog@mail.gmail.com>
 <CAEf70bw23Uroxjfpe_gcgeQ=8aL7O+Of4mXSh4mWi2xh4xOYUw@mail.gmail.com>
 <CAEEL3uxfJMJWtU7UD-K80BQO_cS-NV0R0FxVDoHXbq30=2mtgQ@mail.gmail.com>
Message-ID: <CAOaN92F_wYe-u0yHO0GohKmcz_LHKt-L0rVdJ9Rj2iB-P3GUFg@mail.gmail.com>

Regardless of TGO, it seems like Sobol sequences could be a good
contribution. Josef Perktold was asking about low discrepancy sequences a
few years back on this list:
https://mail.scipy.org/pipermail/scipy-user/2013-June/034744.html and wrote
a blog post talking about them:
http://jpktd.blogspot.com/2013/06/quasi-random-numbers-with-halton.html

How do people feel about something like scipy.stats.lowdiscrepancy(samples,
dimensions, method='sobol') or similar approach? I have code for the Halton
and Hammersley sequences written in Cython that I'd like to contribute to
SciPy as well.

Thanks,
Brian


On Mon, Apr 4, 2016 at 1:21 PM Jacob Stevenson <jstevenson131 at gmail.com>
wrote:

> I agree that the algorithm looks promising (though I also don't have
> access to the papers).  If I understand correctly, a high level summary is
>
> 1. sample points from all possible solutions (e.g. sobol points or a
> simple grid)
> 2. discard points that don't look promising
> 3. perform local optimization on the remaining points.
>
> And I guess the graph theoretic / clustering cleverness comes in step 2.
>  (Something along the lines of "keep only points where the K nearest
> neighbors all have larger function values", if i'm not mistaken.)
>
> Here are a few thoughts I have, please chime in if I'm making bad
> assumptions.
>
> It starts with a grid-like search, and as such probably doesn't scale to
> very high dimensions.  But I think that's fine, it would still be
> applicable to many (most?) applications.
>
> It's nice that the bounds implementation seems to be fairly robust.  That
> is currently a weakness of basinhopping.
>
> I'm curious how the automatic selection of hyper parameters works.  I
> guess we'll find out in Andrea's benchmarks.
>
> People would probably find it useful to have a standalone implementation
> of sobal sequences.  Maybe it would fit in scipy.spatial?
>
> In general, I think the approach is nicely complementary with basinhopping
> and differential evolution.  I think it could be a good fit for scipy.
>
> Thanks for the contribution!
> Jacob
>
>
> On Mon, 4 Apr 2016 at 16:45 Andrea Gavana <andrea.gavana at gmail.com> wrote:
>
>> Hi Stefan,
>>
>>     The algorithm seems very interesting. I haven't gone through the
>> papers (mostly because I don't have access to those journals ?), so I
>> can't really say I understand the theoretical basis of it...
>>
>> However, I believe it would be nice to put TGO through the grinder as I
>> did in the past with many other algorithms:
>>
>> http://infinity77.net/global_optimization/multidimensional.html
>>
>> And take a look to the overall performances. I'm always on the lookout
>> for GO algorithms available in Python (and actually running on Windows as
>> well...), so I'll try to find some time soon enough to put TGO as well on
>> the tables and pictures.
>>
>> Thank you for sharing!
>>
>> Andrea.
>>
>>
>> On Monday, 4 April 2016, Stefan Endres <stefan.c.endres at gmail.com> wrote:
>>
>>> Hello all,
>>>
>>> I?d like to present this implementation of the Topographical Global
>>> Optimisation (TGO) method, a powerfull global optimisation method first
>>> proposed by T?rn (1990) [1]. The implementation is written entirely in
>>> python using mostly boolean numpy arrays to implement the core algorithm
>>> and using scipy.optimize.minimize to find local minima.
>>>
>>> https://github.com/Stefan-Endres/tgo
>>>
>>> TGO is a clustering method that uses graph theory to generate good
>>> starting points for local search methods from points distributed uniformly
>>> in the interior of the feasible set. These points are currently generated
>>> using the Sobol (1967) [3] sequence. The semi-empirical correlation by
>>> Hendorson et. al. (2015) [2] for k integer defining the k-t matrix. The
>>> latter publication used an (unpublished as far as I can tell) C/C++
>>> implementation which was comparatively succesful against commercial
>>> software (MIDACO 4.0).
>>>
>>> More details can be found in the docstrings in
>>> https://github.com/Stefan-Endres/tgo
>>>
>>> Some features in brief.
>>>
>>>    - Global optimisation of multivariate functions with
>>>       - Bounded or unbounded variables.
>>>       - Optional non-linear constraints.
>>>    - Returns an ordered list of all local minima with the res.xl
>>>    attribute and corresponding function values res.fun (this is
>>>    something that I?ve found very useful in my own research).
>>>    - Highly customisable to increase performance on difficult
>>>    optimisation problems.
>>>    - The functions were written entirely in python based on algorithms
>>>    available in open literature [2]
>>>
>>> As a quick visual illustration of the algorithm?s capabilities, a few
>>> results for common optimisation problems and their results:
>>> http://imgur.com/a/'ll MS0hG <http://imgur.com/a/MS0hG>
>>>
>>> I?ve also run a comparison of tgo with the other two global optimisation
>>> currently available.
>>>
>>> http://pastebin.com/8K72Xve8
>>>
>>> Note in all cases tgo found the correct answer, details on my system can
>>> be found at the end of the pastebin (it?s a terminal session dump). Also I
>>> apologise I?m not very familiar with the basinhopping algorithm so I didn?t
>>> know how many iterations where optimal for the problems and stuck with the
>>> default.
>>>
>>> Details on the functions used and their references can be found in the
>>> docstrings in the unittest script:
>>> https://github.com/Stefan-Endres/tgo/blob/master/test__tgo.py
>>> Potential issues
>>>
>>> The most important barrier I forsee is the large file size of the
>>> direction numbers used in generating the Sobol sampling points (
>>> new-joe-kuo-6.21201
>>> <https://github.com/Stefan-Endres/tgo/blob/master/new-joe-kuo-6.21201>)
>>> at 1.8MiB. The code to generate the Sobol points itself is not an issue,
>>> it?s a small script that was translated to Python by one of my advisers for
>>> the project (repository: https://bitbucket.org/alchemyst/sobol/src)
>>> from the original C++ code under a scipy compatible BSD style liscence (
>>> http://web.maths.unsw.edu.au/~fkuo/sobol/).
>>>
>>> I suggest the following solutions to this:
>>>
>>>    - Use latin hypercube sampling (LHS) to generate the initial points
>>>    instead. LHS is already used in _differentialevolution.py (I?ve
>>>    tried to do this, but I?m not sure how without initiating the entire
>>>    DifferentialEvolutionSolver object).
>>>    - Trim the data file to only including Sobol sequence sampling for
>>>    problems of up to 1000 dimensions. It?s easy to write something to download
>>>    higher dimensional data when a user specifies problems higher than 1000
>>>    dimensions.
>>>
>>> I think the sobol_points function is more appropriate numpy.random in
>>> the first from where it can be imported to tgo, but I'm not sure if it's
>>> wanted there.
>>>
>>> Everything else was written from scratch so there shouldn?t be any
>>> licensing issues.
>>>
>>> I?ve tried to follow the guidelines given in
>>> http://docs.scipy.org/doc/scipy/reference/hacking.html as close as
>>> possible with this repository:
>>> https://github.com/Stefan-Endres/scipy/branches
>>>
>>> It?s almost ready for a PR, in particular I don?t really know where/how
>>> to do the following checklists.
>>>
>>>    - Is the new functionality tagged with .. versionadded:: X.Y.Z (with
>>>    X.Y.Z the version number of the next release - can be found in setup.py)?
>>>    - Is the new functionality mentioned in the release notes of the
>>>    next release?
>>>    - Is the new functionality added to the reference guide?
>>>
>>> References
>>>
>>>    1. T?rn, A (1990) ?Topographical global optimization?, Reports on
>>>    Computer Science and Mathematics Ser. A, No 199, 8p. Abo Akademi
>>>    University, Sweden)
>>>    2. Henderson, N et. al (2015) ?A new look at the topographical
>>>    global optimization method and its application to the phase stability
>>>    analysis of mixtures?, Chemical Engineering Science, 127, 151-174
>>>    3. Sobol, IM (1967) ?The distribution of points in a cube and the
>>>    approximate evaluation of integrals. USSR Comput. Math. Math. Phys. 7,
>>>    86-112
>>>
>>>
>>>
>>>
>>> If you wish to learn more about the method I highly recommend Hendorson
>>> et. al.?s (2015) article which presents the material in an introductory
>>> fashion.
>>>
>>> Please let me know what you guys think! I will keep working on this if
>>> you think it?s something that could be included in scipy.
>>>
>>> Thank you for reading.
>>>
>>> Regards,
>>> -
>>> Stefan Endres
>>> Postgraduate Student: Institute of Applied Materials
>>> Department of Chemical Engineering, University of Pretoria
>>> Cell: +27 (0) 82 972 42 89
>>> E-mail: Stefan.C.Endres at gmail.com
>>> St. Number: 11004968
>>> ?
>>>
>>
>>
>> --
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> https://mail.scipy.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> https://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20160405/2a7f35db/attachment.html>

From robert.kern at gmail.com  Tue Apr  5 16:45:46 2016
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 5 Apr 2016 21:45:46 +0100
Subject: [SciPy-Dev] Introducing scipy.optimization.tgo;
 a global optimization routine.
In-Reply-To: <CAOaN92F_wYe-u0yHO0GohKmcz_LHKt-L0rVdJ9Rj2iB-P3GUFg@mail.gmail.com>
References: <CALhqKPCgUSGwrgpjWnAdiwSGS1Vjjn_MFMvfWm7a4tBR66eFog@mail.gmail.com>
 <CAEf70bw23Uroxjfpe_gcgeQ=8aL7O+Of4mXSh4mWi2xh4xOYUw@mail.gmail.com>
 <CAEEL3uxfJMJWtU7UD-K80BQO_cS-NV0R0FxVDoHXbq30=2mtgQ@mail.gmail.com>
 <CAOaN92F_wYe-u0yHO0GohKmcz_LHKt-L0rVdJ9Rj2iB-P3GUFg@mail.gmail.com>
Message-ID: <CAF6FJisx_5bvy6GPg-LP2WH=yrTeDU2=msCRS-jzE9Xps+O+rA@mail.gmail.com>

On Tue, Apr 5, 2016 at 9:35 PM, Brian Scannell <brianjscannell at gmail.com>
wrote:
>
> Regardless of TGO, it seems like Sobol sequences could be a good
contribution. Josef Perktold was asking about low discrepancy sequences a
few years back on this list:
https://mail.scipy.org/pipermail/scipy-user/2013-June/034744.html and wrote
a blog post talking about them:
http://jpktd.blogspot.com/2013/06/quasi-random-numbers-with-halton.html
>
> How do people feel about something like
scipy.stats.lowdiscrepancy(samples, dimensions, method='sobol') or similar
approach? I have code for the Halton and Hammersley sequences written in
Cython that I'd like to contribute to SciPy as well.

I have quibbles about that API, but yes, I approve of adding
low-discrepancy sequences to scipy.stats.

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

From andyfaff at gmail.com  Wed Apr  6 02:46:38 2016
From: andyfaff at gmail.com (Andrew Nelson)
Date: Wed, 6 Apr 2016 16:46:38 +1000
Subject: [SciPy-Dev] Introducing scipy.optimization.tgo;
 a global optimization routine.
In-Reply-To: <CAF6FJisx_5bvy6GPg-LP2WH=yrTeDU2=msCRS-jzE9Xps+O+rA@mail.gmail.com>
References: <CALhqKPCgUSGwrgpjWnAdiwSGS1Vjjn_MFMvfWm7a4tBR66eFog@mail.gmail.com>
 <CAEf70bw23Uroxjfpe_gcgeQ=8aL7O+Of4mXSh4mWi2xh4xOYUw@mail.gmail.com>
 <CAEEL3uxfJMJWtU7UD-K80BQO_cS-NV0R0FxVDoHXbq30=2mtgQ@mail.gmail.com>
 <CAOaN92F_wYe-u0yHO0GohKmcz_LHKt-L0rVdJ9Rj2iB-P3GUFg@mail.gmail.com>
 <CAF6FJisx_5bvy6GPg-LP2WH=yrTeDU2=msCRS-jzE9Xps+O+rA@mail.gmail.com>
Message-ID: <CAAbtOZfTwVQ+YZ_VuPF54tzbDaKD7srMsQp_gdE3oWqdO08_VQ@mail.gmail.com>

Stefan, thanks for your willingness to contribute to Scipy.

There is collection of global minimization problems (>130) in the scipy
benchmarking suite. In large part they are based on the Andrea's excellent
work.
I'd like to see the algorithm run against that collection of problems to
check that its performance is good.
Unfortunately when I tried to run the BenchGlobal class today I found a few
issues (which may be related to use of python3) which need to be looked
into.

Needless to say, all added functionality needs to have a comprehensive set
of tests (not just successful use on benchmarking problems).

A.

_____________________________________
Dr. Andrew Nelson


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

From andrea.gavana at gmail.com  Wed Apr  6 03:11:49 2016
From: andrea.gavana at gmail.com (Andrea Gavana)
Date: Wed, 6 Apr 2016 09:11:49 +0200
Subject: [SciPy-Dev] Introducing scipy.optimization.tgo;
 a global optimization routine.
In-Reply-To: <CAAbtOZfTwVQ+YZ_VuPF54tzbDaKD7srMsQp_gdE3oWqdO08_VQ@mail.gmail.com>
References: <CALhqKPCgUSGwrgpjWnAdiwSGS1Vjjn_MFMvfWm7a4tBR66eFog@mail.gmail.com>
 <CAEf70bw23Uroxjfpe_gcgeQ=8aL7O+Of4mXSh4mWi2xh4xOYUw@mail.gmail.com>
 <CAEEL3uxfJMJWtU7UD-K80BQO_cS-NV0R0FxVDoHXbq30=2mtgQ@mail.gmail.com>
 <CAOaN92F_wYe-u0yHO0GohKmcz_LHKt-L0rVdJ9Rj2iB-P3GUFg@mail.gmail.com>
 <CAF6FJisx_5bvy6GPg-LP2WH=yrTeDU2=msCRS-jzE9Xps+O+rA@mail.gmail.com>
 <CAAbtOZfTwVQ+YZ_VuPF54tzbDaKD7srMsQp_gdE3oWqdO08_VQ@mail.gmail.com>
Message-ID: <CAEf70bwh032JpeNNdm_VjGhpLtGcMz0BW8tvGSn94wAvUVyH4g@mail.gmail.com>

Hi,

On Wednesday, 6 April 2016, Andrew Nelson wrote:

> Stefan, thanks for your willingness to contribute to Scipy.
>
> There is collection of global minimization problems (>130) in the scipy
> benchmarking suite. In large part they are based on the Andrea's excellent
> work.
> I'd like to see the algorithm run against that collection of problems to
> check that its performance is good.
> Unfortunately when I tried to run the BenchGlobal class today I found a
> few issues (which may be related to use of python3) which need to be looked
> into.
>
> Needless to say, all added functionality needs to have a comprehensive set
> of tests (not just successful use on benchmarking problems).
>
> A.
>
> _____________________________________
> Dr. Andrew Nelson
>
>
> _____________________________________
>


In addition to Andrew's comments,  it would be nice to have some
termination criteria in TGO: all the algorithms I have tested had (or I
hacked them to support) a maximum number of function evaluations and a
convergence test against a known global minimum - i.e., by passing a known
global minimum as an input argument to the global optimization algorithm,
the algorithm would stop if the current function value is close enough to
the input global minimum.

If you take a look at The Rules here:

http://infinity77.net/global_optimization/

You can see why it's so important sometimes to have more than one
termination criteria...

I am absolutely not familiar with the Python code of TGO, so I am a bit
reluctant to hack it to add these termination criteria... Any chance we can
get them in somehow? ?

Andrea.



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

From stefan.c.endres at gmail.com  Wed Apr  6 03:25:44 2016
From: stefan.c.endres at gmail.com (Stefan Endres)
Date: Wed, 6 Apr 2016 09:25:44 +0200
Subject: [SciPy-Dev] Introducing scipy.optimization.tgo;
 a global optimization routine.
In-Reply-To: <CAEf70bwh032JpeNNdm_VjGhpLtGcMz0BW8tvGSn94wAvUVyH4g@mail.gmail.com>
References: <CALhqKPCgUSGwrgpjWnAdiwSGS1Vjjn_MFMvfWm7a4tBR66eFog@mail.gmail.com>
 <CAEf70bw23Uroxjfpe_gcgeQ=8aL7O+Of4mXSh4mWi2xh4xOYUw@mail.gmail.com>
 <CAEEL3uxfJMJWtU7UD-K80BQO_cS-NV0R0FxVDoHXbq30=2mtgQ@mail.gmail.com>
 <CAOaN92F_wYe-u0yHO0GohKmcz_LHKt-L0rVdJ9Rj2iB-P3GUFg@mail.gmail.com>
 <CAF6FJisx_5bvy6GPg-LP2WH=yrTeDU2=msCRS-jzE9Xps+O+rA@mail.gmail.com>
 <CAAbtOZfTwVQ+YZ_VuPF54tzbDaKD7srMsQp_gdE3oWqdO08_VQ@mail.gmail.com>
 <CAEf70bwh032JpeNNdm_VjGhpLtGcMz0BW8tvGSn94wAvUVyH4g@mail.gmail.com>
Message-ID: <CALhqKPCDkkTo-O3qBojJ8Kma8Pu6kCgxQdS0PBBwhcB7yMLg5g@mail.gmail.com>

>Unfortunately when I tried to run the BenchGlobal class today I found a
few issues (which may be related to use of python3) which need to be looked
into.
The unittests in ( test__tgo.py
<https://github.com/Stefan-Endres/tgo/blob/master/test__tgo.py>) are at
least working in both Python 2 and 3, but I can imagine there would be
quite a few issues, is there any way _ to try and fix it?



> a maximum number of function evaluations and a convergence test against a
known global minimum - i.e., by passing a known global minimum as an input
argument to the global optimization algorithm, the algorithm would stop if
the current function value is close enough to the input global minimum.
This should be easy enough to do at least once it's over 2000 since the
local if we only need to evaluate after each local scipy.optimize.minimize
return since those function evaulations , but I'm not sure how to terminate
exactly at 2000 if scipy.optimize.minimize



On 6 April 2016 at 09:11, Andrea Gavana <andrea.gavana at gmail.com> wrote:

> Hi,
>
>
> On Wednesday, 6 April 2016, Andrew Nelson wrote:
>
>> Stefan, thanks for your willingness to contribute to Scipy.
>>
>> There is collection of global minimization problems (>130) in the scipy
>> benchmarking suite. In large part they are based on the Andrea's excellent
>> work.
>> I'd like to see the algorithm run against that collection of problems to
>> check that its performance is good.
>> Unfortunately when I tried to run the BenchGlobal class today I found a
>> few issues (which may be related to use of python3) which need to be looked
>> into.
>>
>> Needless to say, all added functionality needs to have a comprehensive
>> set of tests (not just successful use on benchmarking problems).
>>
>> A.
>>
>> _____________________________________
>> Dr. Andrew Nelson
>>
>>
>> _____________________________________
>>
>
>
> In addition to Andrew's comments,  it would be nice to have some
> termination criteria in TGO: all the algorithms I have tested had (or I
> hacked them to support) a maximum number of function evaluations and a
> convergence test against a known global minimum - i.e., by passing a known
> global minimum as an input argument to the global optimization algorithm,
> the algorithm would stop if the current function value is close enough to
> the input global minimum.
>
> If you take a look at The Rules here:
>
> http://infinity77.net/global_optimization/
>
> You can see why it's so important sometimes to have more than one
> termination criteria...
>
> I am absolutely not familiar with the Python code of TGO, so I am a bit
> reluctant to hack it to add these termination criteria... Any chance we can
> get them in somehow? ?
>
> Andrea.
>
>
>
> --
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> https://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


-- 
Stefan Endres
Postgraduate Student: Institute of Applied Materials
Department of Chemical Engineering, University of Pretoria
Cell: +27 (0) 82 972 42 89
E-mail: Stefan.C.Endres at gmail.com
St. Number: 11004968
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20160406/138d2bb2/attachment.html>

From stefan.c.endres at gmail.com  Wed Apr  6 03:28:44 2016
From: stefan.c.endres at gmail.com (Stefan Endres)
Date: Wed, 6 Apr 2016 09:28:44 +0200
Subject: [SciPy-Dev] Introducing scipy.optimization.tgo;
 a global optimization routine.
In-Reply-To: <CALhqKPCDkkTo-O3qBojJ8Kma8Pu6kCgxQdS0PBBwhcB7yMLg5g@mail.gmail.com>
References: <CALhqKPCgUSGwrgpjWnAdiwSGS1Vjjn_MFMvfWm7a4tBR66eFog@mail.gmail.com>
 <CAEf70bw23Uroxjfpe_gcgeQ=8aL7O+Of4mXSh4mWi2xh4xOYUw@mail.gmail.com>
 <CAEEL3uxfJMJWtU7UD-K80BQO_cS-NV0R0FxVDoHXbq30=2mtgQ@mail.gmail.com>
 <CAOaN92F_wYe-u0yHO0GohKmcz_LHKt-L0rVdJ9Rj2iB-P3GUFg@mail.gmail.com>
 <CAF6FJisx_5bvy6GPg-LP2WH=yrTeDU2=msCRS-jzE9Xps+O+rA@mail.gmail.com>
 <CAAbtOZfTwVQ+YZ_VuPF54tzbDaKD7srMsQp_gdE3oWqdO08_VQ@mail.gmail.com>
 <CAEf70bwh032JpeNNdm_VjGhpLtGcMz0BW8tvGSn94wAvUVyH4g@mail.gmail.com>
 <CALhqKPCDkkTo-O3qBojJ8Kma8Pu6kCgxQdS0PBBwhcB7yMLg5g@mail.gmail.com>
Message-ID: <CALhqKPAXeQDifd7bBx+9UgRgHcOcmqc6MyLrJtXqCPe9iH0SLA@mail.gmail.com>

Sorry about that I accidently sent before I was finished typing.

>Unfortunately when I tried to run the BenchGlobal class today I found a
few issues (which may be related to use of python3) which need to be looked
into.
The unittests in ( test__tgo.py
<https://github.com/Stefan-Endres/tgo/blob/master/test__tgo.py>) are at
least working in both Python 2 and 3, but I can imagine there would be
quite a few issues, is there any way *I can run the benchmark code* to try
and fix it?


> a maximum number of function evaluations and a convergence test against a
known global minimum - i.e., by passing a known global minimum as an input
argument to the global optimization algorithm, the algorithm would stop if
the current function value is close enough to the input global minimum.
This should be easy enough to do at least once it's over 2000 since the
local if we only need to evaluate after each local scipy.optimize.minimize
return since those function evaulations (see this line
https://github.com/Stefan-Endres/tgo/blob/master/_tgo.py#L553), but I'm not
sure how to terminate exactly at 2000, I think I'd need to write an input
function evaluations for scipy.optimize.minimize so the local routine can
terminate.

On 6 April 2016 at 09:25, Stefan Endres <stefan.c.endres at gmail.com> wrote:

> >Unfortunately when I tried to run the BenchGlobal class today I found a
> few issues (which may be related to use of python3) which need to be looked
> into.
> The unittests in ( test__tgo.py
> <https://github.com/Stefan-Endres/tgo/blob/master/test__tgo.py>) are at
> least working in both Python 2 and 3, but I can imagine there would be
> quite a few issues, is there any way _ to try and fix it?
>
>
>
> > a maximum number of function evaluations and a convergence test against
> a known global minimum - i.e., by passing a known global minimum as an
> input argument to the global optimization algorithm, the algorithm would
> stop if the current function value is close enough to the input global
> minimum.
> This should be easy enough to do at least once it's over 2000 since the
> local if we only need to evaluate after each local scipy.optimize.minimize
> return since those function evaulations , but I'm not sure how to terminate
> exactly at 2000 if scipy.optimize.minimize
>
>
>
> On 6 April 2016 at 09:11, Andrea Gavana <andrea.gavana at gmail.com> wrote:
>
>> Hi,
>>
>>
>> On Wednesday, 6 April 2016, Andrew Nelson wrote:
>>
>>> Stefan, thanks for your willingness to contribute to Scipy.
>>>
>>> There is collection of global minimization problems (>130) in the scipy
>>> benchmarking suite. In large part they are based on the Andrea's excellent
>>> work.
>>> I'd like to see the algorithm run against that collection of problems to
>>> check that its performance is good.
>>> Unfortunately when I tried to run the BenchGlobal class today I found a
>>> few issues (which may be related to use of python3) which need to be looked
>>> into.
>>>
>>> Needless to say, all added functionality needs to have a comprehensive
>>> set of tests (not just successful use on benchmarking problems).
>>>
>>> A.
>>>
>>> _____________________________________
>>> Dr. Andrew Nelson
>>>
>>>
>>> _____________________________________
>>>
>>
>>
>> In addition to Andrew's comments,  it would be nice to have some
>> termination criteria in TGO: all the algorithms I have tested had (or I
>> hacked them to support) a maximum number of function evaluations and a
>> convergence test against a known global minimum - i.e., by passing a known
>> global minimum as an input argument to the global optimization algorithm,
>> the algorithm would stop if the current function value is close enough to
>> the input global minimum.
>>
>> If you take a look at The Rules here:
>>
>> http://infinity77.net/global_optimization/
>>
>> You can see why it's so important sometimes to have more than one
>> termination criteria...
>>
>> I am absolutely not familiar with the Python code of TGO, so I am a bit
>> reluctant to hack it to add these termination criteria... Any chance we can
>> get them in somehow? ?
>>
>> Andrea.
>>
>>
>>
>> --
>>
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> https://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
>
>
> --
> Stefan Endres
> Postgraduate Student: Institute of Applied Materials
> Department of Chemical Engineering, University of Pretoria
> Cell: +27 (0) 82 972 42 89
> E-mail: Stefan.C.Endres at gmail.com
> St. Number: 11004968
>



-- 
Stefan Endres
Postgraduate Student: Institute of Applied Materials
Department of Chemical Engineering, University of Pretoria
Cell: +27 (0) 82 972 42 89
E-mail: Stefan.C.Endres at gmail.com
St. Number: 11004968
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20160406/31889b14/attachment.html>

From andyfaff at gmail.com  Wed Apr  6 03:35:46 2016
From: andyfaff at gmail.com (Andrew Nelson)
Date: Wed, 6 Apr 2016 17:35:46 +1000
Subject: [SciPy-Dev] Introducing scipy.optimization.tgo;
 a global optimization routine.
In-Reply-To: <CALhqKPCDkkTo-O3qBojJ8Kma8Pu6kCgxQdS0PBBwhcB7yMLg5g@mail.gmail.com>
References: <CALhqKPCgUSGwrgpjWnAdiwSGS1Vjjn_MFMvfWm7a4tBR66eFog@mail.gmail.com>
 <CAEf70bw23Uroxjfpe_gcgeQ=8aL7O+Of4mXSh4mWi2xh4xOYUw@mail.gmail.com>
 <CAEEL3uxfJMJWtU7UD-K80BQO_cS-NV0R0FxVDoHXbq30=2mtgQ@mail.gmail.com>
 <CAOaN92F_wYe-u0yHO0GohKmcz_LHKt-L0rVdJ9Rj2iB-P3GUFg@mail.gmail.com>
 <CAF6FJisx_5bvy6GPg-LP2WH=yrTeDU2=msCRS-jzE9Xps+O+rA@mail.gmail.com>
 <CAAbtOZfTwVQ+YZ_VuPF54tzbDaKD7srMsQp_gdE3oWqdO08_VQ@mail.gmail.com>
 <CAEf70bwh032JpeNNdm_VjGhpLtGcMz0BW8tvGSn94wAvUVyH4g@mail.gmail.com>
 <CALhqKPCDkkTo-O3qBojJ8Kma8Pu6kCgxQdS0PBBwhcB7yMLg5g@mail.gmail.com>
Message-ID: <CAAbtOZejFxgK0VodB6ai+Bv=EySNo6cfhp8Fbjsmt0BPvEfz-Q@mail.gmail.com>

The tests in test__tgo.py mostly look like benchmarks. For an example of
the kind of tests that are required see test__differentialevolution.py in
the scipy.optimize module.
On 6 Apr 2016 5:25 pm, "Stefan Endres" <stefan.c.endres at gmail.com> wrote:

> >Unfortunately when I tried to run the BenchGlobal class today I found a
> few issues (which may be related to use of python3) which need to be looked
> into.
> The unittests in ( test__tgo.py
> <https://github.com/Stefan-Endres/tgo/blob/master/test__tgo.py>) are at
> least working in both Python 2 and 3, but I can imagine there would be
> quite a few issues, is there any way _ to try and fix it?
>
>
>
> > a maximum number of function evaluations and a convergence test against
> a known global minimum - i.e., by passing a known global minimum as an
> input argument to the global optimization algorithm, the algorithm would
> stop if the current function value is close enough to the input global
> minimum.
> This should be easy enough to do at least once it's over 2000 since the
> local if we only need to evaluate after each local scipy.optimize.minimize
> return since those function evaulations , but I'm not sure how to terminate
> exactly at 2000 if scipy.optimize.minimize
>
>
>
> On 6 April 2016 at 09:11, Andrea Gavana <andrea.gavana at gmail.com> wrote:
>
>> Hi,
>>
>>
>> On Wednesday, 6 April 2016, Andrew Nelson wrote:
>>
>>> Stefan, thanks for your willingness to contribute to Scipy.
>>>
>>> There is collection of global minimization problems (>130) in the scipy
>>> benchmarking suite. In large part they are based on the Andrea's excellent
>>> work.
>>> I'd like to see the algorithm run against that collection of problems to
>>> check that its performance is good.
>>> Unfortunately when I tried to run the BenchGlobal class today I found a
>>> few issues (which may be related to use of python3) which need to be looked
>>> into.
>>>
>>> Needless to say, all added functionality needs to have a comprehensive
>>> set of tests (not just successful use on benchmarking problems).
>>>
>>> A.
>>>
>>> _____________________________________
>>> Dr. Andrew Nelson
>>>
>>>
>>> _____________________________________
>>>
>>
>>
>> In addition to Andrew's comments,  it would be nice to have some
>> termination criteria in TGO: all the algorithms I have tested had (or I
>> hacked them to support) a maximum number of function evaluations and a
>> convergence test against a known global minimum - i.e., by passing a known
>> global minimum as an input argument to the global optimization algorithm,
>> the algorithm would stop if the current function value is close enough to
>> the input global minimum.
>>
>> If you take a look at The Rules here:
>>
>> http://infinity77.net/global_optimization/
>>
>> You can see why it's so important sometimes to have more than one
>> termination criteria...
>>
>> I am absolutely not familiar with the Python code of TGO, so I am a bit
>> reluctant to hack it to add these termination criteria... Any chance we can
>> get them in somehow? ?
>>
>> Andrea.
>>
>>
>>
>> --
>>
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> https://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
>
>
> --
> Stefan Endres
> Postgraduate Student: Institute of Applied Materials
> Department of Chemical Engineering, University of Pretoria
> Cell: +27 (0) 82 972 42 89
> E-mail: Stefan.C.Endres at gmail.com
> St. Number: 11004968
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> https://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20160406/738750f1/attachment.html>

From andrea.gavana at gmail.com  Wed Apr  6 03:36:21 2016
From: andrea.gavana at gmail.com (Andrea Gavana)
Date: Wed, 6 Apr 2016 09:36:21 +0200
Subject: [SciPy-Dev] Introducing scipy.optimization.tgo;
 a global optimization routine.
In-Reply-To: <CALhqKPAXeQDifd7bBx+9UgRgHcOcmqc6MyLrJtXqCPe9iH0SLA@mail.gmail.com>
References: <CALhqKPCgUSGwrgpjWnAdiwSGS1Vjjn_MFMvfWm7a4tBR66eFog@mail.gmail.com>
 <CAEf70bw23Uroxjfpe_gcgeQ=8aL7O+Of4mXSh4mWi2xh4xOYUw@mail.gmail.com>
 <CAEEL3uxfJMJWtU7UD-K80BQO_cS-NV0R0FxVDoHXbq30=2mtgQ@mail.gmail.com>
 <CAOaN92F_wYe-u0yHO0GohKmcz_LHKt-L0rVdJ9Rj2iB-P3GUFg@mail.gmail.com>
 <CAF6FJisx_5bvy6GPg-LP2WH=yrTeDU2=msCRS-jzE9Xps+O+rA@mail.gmail.com>
 <CAAbtOZfTwVQ+YZ_VuPF54tzbDaKD7srMsQp_gdE3oWqdO08_VQ@mail.gmail.com>
 <CAEf70bwh032JpeNNdm_VjGhpLtGcMz0BW8tvGSn94wAvUVyH4g@mail.gmail.com>
 <CALhqKPCDkkTo-O3qBojJ8Kma8Pu6kCgxQdS0PBBwhcB7yMLg5g@mail.gmail.com>
 <CALhqKPAXeQDifd7bBx+9UgRgHcOcmqc6MyLrJtXqCPe9iH0SLA@mail.gmail.com>
Message-ID: <CAEf70bxdRppeEtPAHFYMjH2JvBiZtN1jV_c8wt3cXtDmjc9H_A@mail.gmail.com>

Hi Stefan,

On 6 April 2016 at 09:28, Stefan Endres <stefan.c.endres at gmail.com> wrote:

> Sorry about that I accidently sent before I was finished typing.
>
> >Unfortunately when I tried to run the BenchGlobal class today I found a
> few issues (which may be related to use of python3) which need to be looked
> into.
> The unittests in ( test__tgo.py
> <https://github.com/Stefan-Endres/tgo/blob/master/test__tgo.py>) are at
> least working in both Python 2 and 3, but I can imagine there would be
> quite a few issues, is there any way *I can run the benchmark code* to try
> and fix it?
>
>
> > a maximum number of function evaluations and a convergence test against
> a known global minimum - i.e., by passing a known global minimum as an
> input argument to the global optimization algorithm, the algorithm would
> stop if the current function value is close enough to the input global
> minimum.
> This should be easy enough to do at least once it's over 2000 since the
> local if we only need to evaluate after each local scipy.optimize.minimize
> return since those function evaulations (see this line
> https://github.com/Stefan-Endres/tgo/blob/master/_tgo.py#L553), but I'm
> not sure how to terminate exactly at 2000, I think I'd need to write an
> input function evaluations for scipy.optimize.minimize so the local routine
> can terminate.
>


More than the actual maximum number of function evaluations, it would be
nice to have the termination criteria against a know global optimum. If the
algorithm goes beyond 2000 function evaluations (or any other pre-specified
number), it doesn't really matter - what matters is to get close enough to
a know global optimum inside the pre-specified number of function
evaluations.

Andrea.



>
> On 6 April 2016 at 09:25, Stefan Endres <stefan.c.endres at gmail.com> wrote:
>
>> >Unfortunately when I tried to run the BenchGlobal class today I found a
>> few issues (which may be related to use of python3) which need to be looked
>> into.
>> The unittests in ( test__tgo.py
>> <https://github.com/Stefan-Endres/tgo/blob/master/test__tgo.py>) are at
>> least working in both Python 2 and 3, but I can imagine there would be
>> quite a few issues, is there any way _ to try and fix it?
>>
>>
>>
>> > a maximum number of function evaluations and a convergence test against
>> a known global minimum - i.e., by passing a known global minimum as an
>> input argument to the global optimization algorithm, the algorithm would
>> stop if the current function value is close enough to the input global
>> minimum.
>> This should be easy enough to do at least once it's over 2000 since the
>> local if we only need to evaluate after each local scipy.optimize.minimize
>> return since those function evaulations , but I'm not sure how to terminate
>> exactly at 2000 if scipy.optimize.minimize
>>
>>
>>
>> On 6 April 2016 at 09:11, Andrea Gavana <andrea.gavana at gmail.com> wrote:
>>
>>> Hi,
>>>
>>>
>>> On Wednesday, 6 April 2016, Andrew Nelson wrote:
>>>
>>>> Stefan, thanks for your willingness to contribute to Scipy.
>>>>
>>>> There is collection of global minimization problems (>130) in the scipy
>>>> benchmarking suite. In large part they are based on the Andrea's excellent
>>>> work.
>>>> I'd like to see the algorithm run against that collection of problems
>>>> to check that its performance is good.
>>>> Unfortunately when I tried to run the BenchGlobal class today I found a
>>>> few issues (which may be related to use of python3) which need to be looked
>>>> into.
>>>>
>>>> Needless to say, all added functionality needs to have a comprehensive
>>>> set of tests (not just successful use on benchmarking problems).
>>>>
>>>> A.
>>>>
>>>> _____________________________________
>>>> Dr. Andrew Nelson
>>>>
>>>>
>>>> _____________________________________
>>>>
>>>
>>>
>>> In addition to Andrew's comments,  it would be nice to have some
>>> termination criteria in TGO: all the algorithms I have tested had (or I
>>> hacked them to support) a maximum number of function evaluations and a
>>> convergence test against a known global minimum - i.e., by passing a known
>>> global minimum as an input argument to the global optimization algorithm,
>>> the algorithm would stop if the current function value is close enough to
>>> the input global minimum.
>>>
>>> If you take a look at The Rules here:
>>>
>>> http://infinity77.net/global_optimization/
>>>
>>> You can see why it's so important sometimes to have more than one
>>> termination criteria...
>>>
>>> I am absolutely not familiar with the Python code of TGO, so I am a bit
>>> reluctant to hack it to add these termination criteria... Any chance we can
>>> get them in somehow? ?
>>>
>>> Andrea.
>>>
>>>
>>>
>>> --
>>>
>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at scipy.org
>>> https://mail.scipy.org/mailman/listinfo/scipy-dev
>>>
>>>
>>
>>
>> --
>> Stefan Endres
>> Postgraduate Student: Institute of Applied Materials
>> Department of Chemical Engineering, University of Pretoria
>> Cell: +27 (0) 82 972 42 89
>> E-mail: Stefan.C.Endres at gmail.com
>> St. Number: 11004968
>>
>
>
>
> --
> Stefan Endres
> Postgraduate Student: Institute of Applied Materials
> Department of Chemical Engineering, University of Pretoria
> Cell: +27 (0) 82 972 42 89
> E-mail: Stefan.C.Endres at gmail.com
> St. Number: 11004968
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> https://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20160406/d9340f55/attachment.html>

From stefan.c.endres at gmail.com  Wed Apr  6 03:45:42 2016
From: stefan.c.endres at gmail.com (Stefan Endres)
Date: Wed, 6 Apr 2016 09:45:42 +0200
Subject: [SciPy-Dev] Introducing scipy.optimization.tgo;
 a global optimization routine.
In-Reply-To: <CAEf70bxdRppeEtPAHFYMjH2JvBiZtN1jV_c8wt3cXtDmjc9H_A@mail.gmail.com>
References: <CALhqKPCgUSGwrgpjWnAdiwSGS1Vjjn_MFMvfWm7a4tBR66eFog@mail.gmail.com>
 <CAEf70bw23Uroxjfpe_gcgeQ=8aL7O+Of4mXSh4mWi2xh4xOYUw@mail.gmail.com>
 <CAEEL3uxfJMJWtU7UD-K80BQO_cS-NV0R0FxVDoHXbq30=2mtgQ@mail.gmail.com>
 <CAOaN92F_wYe-u0yHO0GohKmcz_LHKt-L0rVdJ9Rj2iB-P3GUFg@mail.gmail.com>
 <CAF6FJisx_5bvy6GPg-LP2WH=yrTeDU2=msCRS-jzE9Xps+O+rA@mail.gmail.com>
 <CAAbtOZfTwVQ+YZ_VuPF54tzbDaKD7srMsQp_gdE3oWqdO08_VQ@mail.gmail.com>
 <CAEf70bwh032JpeNNdm_VjGhpLtGcMz0BW8tvGSn94wAvUVyH4g@mail.gmail.com>
 <CALhqKPCDkkTo-O3qBojJ8Kma8Pu6kCgxQdS0PBBwhcB7yMLg5g@mail.gmail.com>
 <CALhqKPAXeQDifd7bBx+9UgRgHcOcmqc6MyLrJtXqCPe9iH0SLA@mail.gmail.com>
 <CAEf70bxdRppeEtPAHFYMjH2JvBiZtN1jV_c8wt3cXtDmjc9H_A@mail.gmail.com>
Message-ID: <CALhqKPCQie7BH=4P_uih371vfa98C=tjf3+tRytDOu2jOS04zQ@mail.gmail.com>

Alright thanks I will take a look and work on these.

On 6 April 2016 at 09:36, Andrea Gavana <andrea.gavana at gmail.com> wrote:

> Hi Stefan,
>
> On 6 April 2016 at 09:28, Stefan Endres <stefan.c.endres at gmail.com> wrote:
>
>> Sorry about that I accidently sent before I was finished typing.
>>
>> >Unfortunately when I tried to run the BenchGlobal class today I found a
>> few issues (which may be related to use of python3) which need to be looked
>> into.
>> The unittests in ( test__tgo.py
>> <https://github.com/Stefan-Endres/tgo/blob/master/test__tgo.py>) are at
>> least working in both Python 2 and 3, but I can imagine there would be
>> quite a few issues, is there any way *I can run the benchmark code* to try
>> and fix it?
>>
>>
>> > a maximum number of function evaluations and a convergence test against
>> a known global minimum - i.e., by passing a known global minimum as an
>> input argument to the global optimization algorithm, the algorithm would
>> stop if the current function value is close enough to the input global
>> minimum.
>> This should be easy enough to do at least once it's over 2000 since the
>> local if we only need to evaluate after each local scipy.optimize.minimize
>> return since those function evaulations (see this line
>> https://github.com/Stefan-Endres/tgo/blob/master/_tgo.py#L553), but I'm
>> not sure how to terminate exactly at 2000, I think I'd need to write an
>> input function evaluations for scipy.optimize.minimize so the local routine
>> can terminate.
>>
>
>
> More than the actual maximum number of function evaluations, it would be
> nice to have the termination criteria against a know global optimum. If the
> algorithm goes beyond 2000 function evaluations (or any other pre-specified
> number), it doesn't really matter - what matters is to get close enough to
> a know global optimum inside the pre-specified number of function
> evaluations.
>
> Andrea.
>
>
>
>>
>> On 6 April 2016 at 09:25, Stefan Endres <stefan.c.endres at gmail.com>
>> wrote:
>>
>>> >Unfortunately when I tried to run the BenchGlobal class today I found a
>>> few issues (which may be related to use of python3) which need to be looked
>>> into.
>>> The unittests in ( test__tgo.py
>>> <https://github.com/Stefan-Endres/tgo/blob/master/test__tgo.py>) are at
>>> least working in both Python 2 and 3, but I can imagine there would be
>>> quite a few issues, is there any way _ to try and fix it?
>>>
>>>
>>>
>>> > a maximum number of function evaluations and a convergence test
>>> against a known global minimum - i.e., by passing a known global minimum as
>>> an input argument to the global optimization algorithm, the algorithm would
>>> stop if the current function value is close enough to the input global
>>> minimum.
>>> This should be easy enough to do at least once it's over 2000 since the
>>> local if we only need to evaluate after each local scipy.optimize.minimize
>>> return since those function evaulations , but I'm not sure how to terminate
>>> exactly at 2000 if scipy.optimize.minimize
>>>
>>>
>>>
>>> On 6 April 2016 at 09:11, Andrea Gavana <andrea.gavana at gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>> On Wednesday, 6 April 2016, Andrew Nelson wrote:
>>>>
>>>>> Stefan, thanks for your willingness to contribute to Scipy.
>>>>>
>>>>> There is collection of global minimization problems (>130) in the
>>>>> scipy benchmarking suite. In large part they are based on the Andrea's
>>>>> excellent work.
>>>>> I'd like to see the algorithm run against that collection of problems
>>>>> to check that its performance is good.
>>>>> Unfortunately when I tried to run the BenchGlobal class today I found
>>>>> a few issues (which may be related to use of python3) which need to be
>>>>> looked into.
>>>>>
>>>>> Needless to say, all added functionality needs to have a comprehensive
>>>>> set of tests (not just successful use on benchmarking problems).
>>>>>
>>>>> A.
>>>>>
>>>>> _____________________________________
>>>>> Dr. Andrew Nelson
>>>>>
>>>>>
>>>>> _____________________________________
>>>>>
>>>>
>>>>
>>>> In addition to Andrew's comments,  it would be nice to have some
>>>> termination criteria in TGO: all the algorithms I have tested had (or I
>>>> hacked them to support) a maximum number of function evaluations and a
>>>> convergence test against a known global minimum - i.e., by passing a known
>>>> global minimum as an input argument to the global optimization algorithm,
>>>> the algorithm would stop if the current function value is close enough to
>>>> the input global minimum.
>>>>
>>>> If you take a look at The Rules here:
>>>>
>>>> http://infinity77.net/global_optimization/
>>>>
>>>> You can see why it's so important sometimes to have more than one
>>>> termination criteria...
>>>>
>>>> I am absolutely not familiar with the Python code of TGO, so I am a bit
>>>> reluctant to hack it to add these termination criteria... Any chance we can
>>>> get them in somehow? ?
>>>>
>>>> Andrea.
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at scipy.org
>>>> https://mail.scipy.org/mailman/listinfo/scipy-dev
>>>>
>>>>
>>>
>>>
>>> --
>>> Stefan Endres
>>> Postgraduate Student: Institute of Applied Materials
>>> Department of Chemical Engineering, University of Pretoria
>>> Cell: +27 (0) 82 972 42 89
>>> E-mail: Stefan.C.Endres at gmail.com
>>> St. Number: 11004968
>>>
>>
>>
>>
>> --
>> Stefan Endres
>> Postgraduate Student: Institute of Applied Materials
>> Department of Chemical Engineering, University of Pretoria
>> Cell: +27 (0) 82 972 42 89
>> E-mail: Stefan.C.Endres at gmail.com
>> St. Number: 11004968
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> https://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> https://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


-- 
Stefan Endres
Postgraduate Student: Institute of Applied Materials
Department of Chemical Engineering, University of Pretoria
Cell: +27 (0) 82 972 42 89
E-mail: Stefan.C.Endres at gmail.com
St. Number: 11004968
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20160406/adb96059/attachment.html>

From tpudlik at gmail.com  Wed Apr  6 13:47:02 2016
From: tpudlik at gmail.com (Ted Pudlik)
Date: Wed, 06 Apr 2016 17:47:02 +0000
Subject: [SciPy-Dev] Edge case bug in stats.triang?
In-Reply-To: <CAAbtOZfofKu8p+t61uiWem3-N+UrhvBpeBuejXq38FB+ShzOqg@mail.gmail.com>
References: <CAAbtOZfofKu8p+t61uiWem3-N+UrhvBpeBuejXq38FB+ShzOqg@mail.gmail.com>
Message-ID: <CAOD95Jg0Vc5SYbcLghLUxsgr0kZYKaYnAJNCXv0+X1XQQc=w6Q@mail.gmail.com>

I think this is indeed incorrect: the formula used to compute the pdf,
2*(1-x)/(1-c), produces nan because of a division by zero when x = c = 1.
I submitted an issue, https://github.com/scipy/scipy/issues/6036.

On Mon, Apr 4, 2016 at 11:35 PM Andrew Nelson <andyfaff at gmail.com> wrote:

> I've been investigating the stats.triang.pdf over it's domain with
> different modes:
>
> >>> from scipy.stats import triang
> >>> triang.pdf(0, 0)
> 2.0
> >>> triang.pdf(1, 1)
> nan
>
> Shouldn't the last value be 2?
>
> --
> _____________________________________
> Dr. Andrew Nelson
>
>
> _____________________________________
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> https://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20160406/e46be673/attachment.html>

From thomas.haslwanter at gmail.com  Wed Apr  6 17:02:25 2016
From: thomas.haslwanter at gmail.com (Thomas Haslwanter)
Date: Wed, 6 Apr 2016 23:02:25 +0200
Subject: [SciPy-Dev] thLib - 3D Kinematics and Signal Processing
Message-ID: <CAD0YMynT87z0NVMJ_DGWBntntfdTJEmPq-b173c4PopMKrpR8w@mail.gmail.com>

Hi,
over the last few years I have developed a Python library, primarily aimed
at 3D kinematics, signal processing, and miscellaneous small items that I
use regularly, like a waitbar. It is currently available at
https://pypi.python.org/pypi?%3Aaction=pkg_edit&name=thLib

Somewhat to my surprise, it has become pretty popular (by my personal
standards), with almost 9'000 downloads last month. Since most parts of it
are by now quite stable, I am thinking about how best to continue. I can

   1. Make it a github-project, and see who is interested in contributing.
   2. Improve the testing, and release a 1.0 version on my own. (My main
   limitation is that I don't have a Mac, and testing compatability with Macs
   is difficult for me.)
   3. Turn it into a "scikit-kinematics" (or some other suitable
   "scikit"-name) and/or contribute the code to scipy, if others would find it
   suitable.

I would appreciate feedback and opinions.
Thanks, Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20160406/c228007d/attachment.html>

From benny.malengier at gmail.com  Thu Apr  7 03:34:45 2016
From: benny.malengier at gmail.com (Benny Malengier)
Date: Thu, 7 Apr 2016 09:34:45 +0200
Subject: [SciPy-Dev] thLib - 3D Kinematics and Signal Processing
In-Reply-To: <CAD0YMynT87z0NVMJ_DGWBntntfdTJEmPq-b173c4PopMKrpR8w@mail.gmail.com>
References: <CAD0YMynT87z0NVMJ_DGWBntntfdTJEmPq-b173c4PopMKrpR8w@mail.gmail.com>
Message-ID: <CAOyNq8rSeJ=uQJ_B5CrXf+N_s6TGoOt+mKUk_LXFzzrhVRF7xw@mail.gmail.com>

The link is not working (you send the edit link)
Also this link on pypi is broken for me at the moment:
https://pypi.python.org/pypi/thLib/0.11.3

Benny

2016-04-06 23:02 GMT+02:00 Thomas Haslwanter <thomas.haslwanter at gmail.com>:

> Hi,
> over the last few years I have developed a Python library, primarily aimed
> at 3D kinematics, signal processing, and miscellaneous small items that I
> use regularly, like a waitbar. It is currently available at
> https://pypi.python.org/pypi?%3Aaction=pkg_edit&name=thLib
>
> Somewhat to my surprise, it has become pretty popular (by my personal
> standards), with almost 9'000 downloads last month. Since most parts of it
> are by now quite stable, I am thinking about how best to continue. I can
>
>    1. Make it a github-project, and see who is interested in contributing.
>    2. Improve the testing, and release a 1.0 version on my own. (My main
>    limitation is that I don't have a Mac, and testing compatability with Macs
>    is difficult for me.)
>    3. Turn it into a "scikit-kinematics" (or some other suitable
>    "scikit"-name) and/or contribute the code to scipy, if others would find it
>    suitable.
>
> I would appreciate feedback and opinions.
> Thanks, Thomas
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> https://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20160407/cd07d328/attachment.html>

From thomas.haslwanter at gmail.com  Thu Apr  7 12:52:23 2016
From: thomas.haslwanter at gmail.com (Thomas Haslwanter)
Date: Thu, 7 Apr 2016 18:52:23 +0200
Subject: [SciPy-Dev] thLib - 3D Kinematics and Signal Processing
In-Reply-To: <CAOyNq8rSeJ=uQJ_B5CrXf+N_s6TGoOt+mKUk_LXFzzrhVRF7xw@mail.gmail.com>
References: <CAD0YMynT87z0NVMJ_DGWBntntfdTJEmPq-b173c4PopMKrpR8w@mail.gmail.com>
 <CAOyNq8rSeJ=uQJ_B5CrXf+N_s6TGoOt+mKUk_LXFzzrhVRF7xw@mail.gmail.com>
Message-ID: <CAD0YMymJuxs=3ujayUhUwTWmsybjrOHQNiNW0eTMB8UjnmuT+A@mail.gmail.com>

You are correct, I apologize. I tried to replace a submission with an
error, and inadvertently replaced the whole group :(
The correct link is
https://pypi.python.org/pypi/thLib/0.11.8

On Thu, Apr 7, 2016 at 9:34 AM, Benny Malengier <benny.malengier at gmail.com>
wrote:

> The link is not working (you send the edit link)
> Also this link on pypi is broken for me at the moment:
> https://pypi.python.org/pypi/thLib/0.11.3
>
> Benny
>
> 2016-04-06 23:02 GMT+02:00 Thomas Haslwanter <thomas.haslwanter at gmail.com>
> :
>
>> Hi,
>> over the last few years I have developed a Python library, primarily
>> aimed at 3D kinematics, signal processing, and miscellaneous small items
>> that I use regularly, like a waitbar. It is currently available at
>> https://pypi.python.org/pypi?%3Aaction=pkg_edit&name=thLib
>>
>> Somewhat to my surprise, it has become pretty popular (by my personal
>> standards), with almost 9'000 downloads last month. Since most parts of it
>> are by now quite stable, I am thinking about how best to continue. I can
>>
>>    1. Make it a github-project, and see who is interested in
>>    contributing.
>>    2. Improve the testing, and release a 1.0 version on my own. (My main
>>    limitation is that I don't have a Mac, and testing compatability with Macs
>>    is difficult for me.)
>>    3. Turn it into a "scikit-kinematics" (or some other suitable
>>    "scikit"-name) and/or contribute the code to scipy, if others would find it
>>    suitable.
>>
>> I would appreciate feedback and opinions.
>> Thanks, Thomas
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> https://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> https://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20160407/d9225c94/attachment.html>

From thomas.haslwanter at gmail.com  Sat Apr  9 12:25:16 2016
From: thomas.haslwanter at gmail.com (Thomas Haslwanter)
Date: Sat, 9 Apr 2016 18:25:16 +0200
Subject: [SciPy-Dev] scikit-kinematics
Message-ID: <CAD0YMy=hgz2Ee+CKEehtD2eerbn0dDJ8+g05RtmUFOwzW0KFDg@mail.gmail.com>

Hi,
I am thinking about taking all the kinematics-related modules from my
library thLib (http://work.thaslwanter.at/thLib/html/#modules), and release
it as a new scikit: "scikit-kinematics". Currently there are modules on:
- quaternions
- rotation matrices
- vector calculations
- IMU (inertial measurement units)
- markers (optical tracking systems)
- viewer (for interactively investigating time series)

Any opinion?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20160409/3223283c/attachment.html>

From wavexx at thregr.org  Sat Apr  9 15:47:26 2016
From: wavexx at thregr.org (Yuri D'Elia)
Date: Sat, 09 Apr 2016 21:47:26 +0200
Subject: [SciPy-Dev] PR for signal.planck (Planck-taper and Planck-Bessel
	window functions)
Message-ID: <87h9fa8sz5.fsf@wavexx.thregr.org>

Hi everyone,

I'd like to bring to your attention this PR:

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

which implements the Plack-taper window (http://arxiv.org/pdf/1003.2939)
along with tests and documentation.

It's a rarely-used window, with current citations only in the
gravitational-wave field of research. I can definitely see why there
might be reluctance in merging such a rarely used window.

Nevertheless, I'd like to know if there is actual interesting or not, as
I could furthermore provide the implementation of the Planck-Bessel and
Cosine-Hyperbolic windows as well.

Thanks!



From insertinterestingnamehere at gmail.com  Sun Apr 10 02:25:12 2016
From: insertinterestingnamehere at gmail.com (Ian Henriksen)
Date: Sun, 10 Apr 2016 06:25:12 +0000
Subject: [SciPy-Dev] Increasing Minimum Required LAPACK Version
Message-ID: <CAPWbfpREezuSF_DQQpy4LV1X0=as9TGP2mcMx_AOHDJwpwqgTA@mail.gmail.com>

Hi everyone,
I've opened a pull request (https://github.com/scipy/scipy/pull/6051) to
increase the
minimum required LAPACK version to 3.3.1 rather than 3.1.0.

Here's some context. 3.1.0 was released on November 12, 2006. 3.3.1 was
released on April 18 2011. 3.3.1 is also the LAPACK version available by
default on
the Travis CI build workers.

There are several advantages to doing this. It lets us avoid running into
bugs in
older LAPACK versions (one example is
https://github.com/scipy/scipy/issues/5039). It also allows us to add a
significant
number of LAPACK routines to the Cython LAPACK API. The Cython LAPACK API
consists of the routines common to all supported LAPACK versions.
Increasing the
minimum requirement all the way up to 3.3.1 gives us access to most of the
new
routines added between 3.1.0 and 3.3.1. A full list of the routines this
adds is
available in the pull request.

The main change I expect this to make for users is that people using systems
sufficiently old to not have LAPACK 3.3.1 available through the package
manager
will now have to build LAPACK from source rather than linking against the
LAPACK
provided by their operating system. Given that systems that old are
becoming less
common and that many people use more recent optimized implementations of
BLAS and LAPACK, I expect that this won't impact a huge number of people.

Is this a change that makes sense to everyone?

Best,
Ian Henriksen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20160410/27436fdd/attachment.html>

From evgeny.burovskiy at gmail.com  Sun Apr 10 13:53:36 2016
From: evgeny.burovskiy at gmail.com (Evgeni Burovski)
Date: Sun, 10 Apr 2016 18:53:36 +0100
Subject: [SciPy-Dev] scipy 0.17.1 release
Message-ID: <CAMRo0iuiyyJQeDDCwQdW2tGFtPQ3nn17hajupQGEQ_q78f5oVA@mail.gmail.com>

Hi,

I'm planning to cut the point release of scipy 0.17.1 by the end of this week.
Thoughts?

Regressions in 0.17.0 so far seem reasonably mild:
https://github.com/scipy/scipy/milestones/0.17.1
If there's anything else you think should be included in 0.17.1,
please mention it in this email thread or on Github.

Cheers,

Evgeni


From thomas.haslwanter at gmail.com  Mon Apr 11 12:25:05 2016
From: thomas.haslwanter at gmail.com (Thomas Haslwanter)
Date: Mon, 11 Apr 2016 18:25:05 +0200
Subject: [SciPy-Dev] scikit-kinematics released
Message-ID: <CAD0YMymZ=WGv_oEMo0N-8pVf=NiAgkVS7HLyHb=BE1i8COcUQg@mail.gmail.com>

I have gone ahead, and released my 3D kinematics routines (working with
rotation matrices and quaternions, analyzing data from IMUs and from
marker-based tracker systems, etc) as an open-source project.


   - The code can be found under
   https://github.com/thomas-haslwanter/scikit-kinematics
   - The documentation under http://work.thaslwanter.at/skinematics/html/

I still have one problem, where I would really appreciate assistance: the
documentation builds cleanly on my system, under Windows as well as under
Linux. However, when I build the documentation on https://readthedocs.org/,
the descriptions of the functions in the modules are not built. It looks as
if *readthedocs* ignores the sphinx-command "func". Check for example the
link  for *quat.quatmult*

on http://work.thaslwanter.at/skinematics/html/quat.html (correctly
working)

and on http://scikit-kinematics.readthedocs.org/en/latest/quat.html (link
not working)

If you have had any experience with *readthedocs* and have an idea what the
problem could be, please let me know.

Thanks, thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20160411/d632c329/attachment.html>

From sturla.molden at gmail.com  Wed Apr 13 06:39:46 2016
From: sturla.molden at gmail.com (Sturla Molden)
Date: Wed, 13 Apr 2016 12:39:46 +0200
Subject: [SciPy-Dev] Increasing Minimum Required LAPACK Version
In-Reply-To: <CAPWbfpREezuSF_DQQpy4LV1X0=as9TGP2mcMx_AOHDJwpwqgTA@mail.gmail.com>
References: <CAPWbfpREezuSF_DQQpy4LV1X0=as9TGP2mcMx_AOHDJwpwqgTA@mail.gmail.com>
Message-ID: <nel7km$f79$1@ger.gmane.org>

On 10/04/16 08:25, Ian Henriksen wrote:
> Hi everyone,
> I've opened a pull request (https://github.com/scipy/scipy/pull/6051) to
> increase the
> minimum required LAPACK version to 3.3.1 rather than 3.1.0.

Apple's Accerate Framework is only providing 3.2.1 (actually CLAPACK, 
not LAPACK).

Sturla




From evgeny.burovskiy at gmail.com  Thu Apr 14 16:14:00 2016
From: evgeny.burovskiy at gmail.com (Evgeni Burovski)
Date: Thu, 14 Apr 2016 21:14:00 +0100
Subject: [SciPy-Dev] RFC: sparse DOK array
In-Reply-To: <CAPJVwBm1kZfEiTU9fRthYDRr4gHDKfSB9mxDgoaSpoUaP5=5zw@mail.gmail.com>
References: <CAMRo0itr_0PqzZObL7niY70n3D1dc2Kyk88wRG3=OMfhRibgHA@mail.gmail.com>
 <CAPJVwBm1kZfEiTU9fRthYDRr4gHDKfSB9mxDgoaSpoUaP5=5zw@mail.gmail.com>
Message-ID: <CAMRo0itXt8-D+pACOSEn8PncuW8_-6O1E=xJ7PbsxWaR_6TMWQ@mail.gmail.com>

Hi Nathaniel,

> - For general operations on n-dimensional sparse arrays, COO format
> seems like the obvious thing to use. The strategy I've envisioned is
> storing the data as N arrays of indices + 1 array of values (or
> possibly you'd want to pack these together into a single array of
> (struct containing N+1 values)), plus a bit of metadata indicating the
> current sort order -- so sort_order=(0, 1) would mean that the items
> are sorted lexicographically by row and then by column (so like CSC),
> and sort_order=(1, 0) would mean the opposite. Then operations like
> sum(axis=1) would be "sort by axis 1 (if not already there); then sum
> over each contiguous chunk of the data"; sum(axis=(0, 2)) would be
> "sort to make sure axes 0 and 2 are in the front (but I don't care in
> which order)", etc. It may be useful to use a stable sort, so that if
> you have sort_order=(0, 1, 2) and then sort by axis 2, you get
> sort_order=(2, 0, 1). For binary operations, you ensure that the two
> arrays have the same sort order (possibly re-sorting the smaller one),
> and then do a parallel iteration over both of them finding matching
> indices.

> - Instead of proliferating data types for all kinds of different
> storage formats, I'd really prefer to see a single data type that
> "just works". So for example, instead of having one storage format
> that's optimized for building matrices and one that's optimized for
> operations on matrices, you could have a single object which has:
>
>   - COO format representation
>   - a DOK of "pending updates"
>
> and writes would go into the DOK part, and at the beginning of each
> non-trivial operation you'd call self._get_coo_arrays() or whatever,
> which would do
>
>   if self._pending_updates:
>       # do a single batch reallocation and incorporate all the pending updates
>   return self._real_coo_arrays
>
> There are a lot of potentially viable variants on this using different
> data structures for the various pieces, different detailed
> reallocation strategies, etc., but you get the idea.


Thanks for sharing your perspective!

I really like the idea of the DOK buffer of pending updates.
I'll note that what the COO structure you describe looks similar to
CJ's SpArray which he mentioned in a parallel thread, and my MapArray
can serve as a buffer. Tacking them together seems easy, so one can
fairly easily test-drive what you describe.

Looking a bit further though, I doubt that one-size-fits-all data data
format is realistic. For one, there's a balance to strike between a
optimized 2D structure (e.g., PySparse's ll_mat) and a general n-D
structure, and there will always be at least one application which
requires one or another. (My crude experiments so far give about a
factor of 2--5 for CPU and/or memory footprint depending on general
tradeoffs.)

Ultimately then, I think it makes sense to consider three separate
layers: a python frontend, a low-level data structure and a middle
layer which transforms, e.g., the logic required by python's
__setitem__ into iterators of the low-level data structure.
For shaping up this middle layer, an std::map is fine, esp because
it's already implemented :-).


> For interface with external C/C++/Fortran code that wants CSR or CSC,
> I'd just have get_csr() and get_csc() methods that return a tuple of
> (indptr, indices, data), and not even try to implement any actual
> operations on this representation.
>
>> * Data types and casting rules. For now, I basically piggy-back on
>> numpy's rules.
>> There are several slightly different ones (numba has one?), and there might be
>> an opportunity to simplify the rules. OTOH, inventing one more subtly different
>> set of rules might be a bad idea.
>
> It would be really nice if you could just use numpy's own dtype
> objects and ufuncs instead of implementing your own. I don't know how
> viable that is right now, but I think it's worth trying, and if you
> can't then I'd like to know what part broke :-). Happy to help if you
> need some tips / further explanation.

For ufuncs, it's simple: it does not work ATM  :-( . I tried simple
conbinations of __array__, __array_prepare__ and __array_finalize__,
and they fail for a reason or another. Some details are available in
https://github.com/ev-br/sparr/issues/35
In a nutshell, these can probably made to work with some rather simple
modifications of to __array_prepare__/__array_wrap__, but I guess it's
not very likely given that __numpy_ufunc__ is supposed to come to
town, which I'm looking forward to :-).

For dtypes, I currently just dispatch on numpy typecodes. Do you mean
that, or do you mean actual PyArray_Descr objects?
Those I'm not using, and I do not see how to use them, likely because
I simply do not understand what they actually are :-). In that
department, I'd really really appreciate an explanation!

Cheers,

Evgeni


From njs at pobox.com  Thu Apr 14 21:12:05 2016
From: njs at pobox.com (Nathaniel Smith)
Date: Thu, 14 Apr 2016 18:12:05 -0700
Subject: [SciPy-Dev] RFC: sparse DOK array
In-Reply-To: <CAMRo0itXt8-D+pACOSEn8PncuW8_-6O1E=xJ7PbsxWaR_6TMWQ@mail.gmail.com>
References: <CAMRo0itr_0PqzZObL7niY70n3D1dc2Kyk88wRG3=OMfhRibgHA@mail.gmail.com>
 <CAPJVwBm1kZfEiTU9fRthYDRr4gHDKfSB9mxDgoaSpoUaP5=5zw@mail.gmail.com>
 <CAMRo0itXt8-D+pACOSEn8PncuW8_-6O1E=xJ7PbsxWaR_6TMWQ@mail.gmail.com>
Message-ID: <CAPJVwB=cScGdF9+DGKN8wUDxyDVTgX9V48OTBnVaq7=a_Ls8Zg@mail.gmail.com>

On Thu, Apr 14, 2016 at 1:14 PM, Evgeni Burovski
<evgeny.burovskiy at gmail.com> wrote:
> Hi Nathaniel,
[...]
> I really like the idea of the DOK buffer of pending updates.
> I'll note that what the COO structure you describe looks similar to
> CJ's SpArray which he mentioned in a parallel thread, and my MapArray
> can serve as a buffer. Tacking them together seems easy, so one can
> fairly easily test-drive what you describe.

Cool :-)

> Looking a bit further though, I doubt that one-size-fits-all data data
> format is realistic. For one, there's a balance to strike between a
> optimized 2D structure (e.g., PySparse's ll_mat) and a general n-D
> structure, and there will always be at least one application which
> requires one or another. (My crude experiments so far give about a
> factor of 2--5 for CPU and/or memory footprint depending on general
> tradeoffs.)
>
> Ultimately then, I think it makes sense to consider three separate
> layers: a python frontend, a low-level data structure and a middle
> layer which transforms, e.g., the logic required by python's
> __setitem__ into iterators of the low-level data structure.
> For shaping up this middle layer, an std::map is fine, esp because
> it's already implemented :-).

I guess my tactical preference would be to start by implementing a
one-size-fits-all data format, make it as awesome as one can, and then
only add extra special-cases once (if) it becomes clear that there is
really a need. ll_mat is just a list-of-lists format, right? why would
we need that? And CSR/CSC are nice, but even for 2-d matrices the
savings compared to COO seem underwhelming. I guess CSR/CSC are at
most 30% smaller than COO, and if you need random access to
rows/columns then you can do that in O(1) instead of O(log log n)?
Obviously there will always be some specialized applications where
this matters, but...

>> For interface with external C/C++/Fortran code that wants CSR or CSC,
>> I'd just have get_csr() and get_csc() methods that return a tuple of
>> (indptr, indices, data), and not even try to implement any actual
>> operations on this representation.
>>
>>> * Data types and casting rules. For now, I basically piggy-back on
>>> numpy's rules.
>>> There are several slightly different ones (numba has one?), and there might be
>>> an opportunity to simplify the rules. OTOH, inventing one more subtly different
>>> set of rules might be a bad idea.
>>
>> It would be really nice if you could just use numpy's own dtype
>> objects and ufuncs instead of implementing your own. I don't know how
>> viable that is right now, but I think it's worth trying, and if you
>> can't then I'd like to know what part broke :-). Happy to help if you
>> need some tips / further explanation.
>
> For ufuncs, it's simple: it does not work ATM  :-( . I tried simple
> conbinations of __array__, __array_prepare__ and __array_finalize__,
> and they fail for a reason or another. Some details are available in
> https://github.com/ev-br/sparr/issues/35
> In a nutshell, these can probably made to work with some rather simple
> modifications of to __array_prepare__/__array_wrap__, but I guess it's
> not very likely given that __numpy_ufunc__ is supposed to come to
> town, which I'm looking forward to :-).

Yeah, you probably do need __numpy_ufunc__. But in the mean time you
could see about something like

def generic_ufunc_adapter(ufunc, *args, **kwargs):
    ... do something clever ...

def add(*args, **kwargs):
    return generic_ufunc_adapter(np.add, *args, **kwargs)

and then be prepared to switch over to __numpy_ufunc__ when available.

The big advantage of this approach is that you can hopefully handle
all ufuncs, including user-defined ufuncs (e.g. scipy.special, numba
@vectorize functions) without having to special case all of them.

> For dtypes, I currently just dispatch on numpy typecodes. Do you mean
> that, or do you mean actual PyArray_Descr objects?
> Those I'm not using, and I do not see how to use them, likely because
> I simply do not understand what they actually are :-). In that
> department, I'd really really appreciate an explanation!

I meant PyArray_Descr objects :-).

They're a Python object whose C layout looks like this:

    https://docs.scipy.org/doc/numpy/reference/c-api.types-and-structures.html#c.PyArray_Descr

The crucial bit is that PyArray_ArrFuncs pointer at the end. That
points to a table of function pointers:

    https://docs.scipy.org/doc/numpy/reference/c-api.types-and-structures.html#c.PyArray_ArrFuncs

and those function pointers implement generic operations like "copy
elements of this dtype from this strided array to that strided array",
"convert a Python object into a buffer using this dtype" (used by e.g.
arr[0] = some_object), etc.

They're not terribly well documented, and we need to rework that API
(but will have to preserve those entrypoints for backcompat purposes),
but this is how numpy.ndarray is able to work with arbitrary dtypes
without dispatching on typecodes.

-n

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


From tyler.je.reddy at gmail.com  Fri Apr 15 06:22:19 2016
From: tyler.je.reddy at gmail.com (Tyler Reddy)
Date: Fri, 15 Apr 2016 11:22:19 +0100
Subject: [SciPy-Dev] Adding surface area calculation for spherical polygons
Message-ID: <CAHPuU_bfCHneiD2W=_bFZeKLTrrVMnNTzrAnrLOkP7E=oY+HTg@mail.gmail.com>

Hi,

I've opened an issue (https://github.com/scipy/scipy/issues/6069) that
describes and demonstrates code for calculating the surface areas of
spherical polygons. It would be helpful to have some input--I've put sample
results there and linked to a github with Dockerfile, etc. for reproducing
the results / modifying code if needed.

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

From faleichik at gmail.com  Sun Apr 17 13:10:19 2016
From: faleichik at gmail.com (Boris Faleichik)
Date: Sun, 17 Apr 2016 20:10:19 +0300
Subject: [SciPy-Dev] On an example problem from optimize/nonlin.py
Message-ID: <CAMarX1U148D0NgfgOE6Z6cFgpLdzFK5osd71RisUHdxmC9Ypew@mail.gmail.com>

Dear all,

my question is addressed to the authors of
https://github.com/scipy/scipy/blob/master/scipy/optimize/nonlin.py.

I am looking for more detailed description of the nonlinear
integro-differential equation which is a test problem for Newton-Krylov
iteration in the documentation:

\nabla^2 P = 10 \left(\int_0^1\int_0^1\cosh(P)\,dx\,dy\right)^2

As a computational scientist I would like to know the origin of this
problem and possibly to get some references on related scientific papers.

Thank you very much!

Best,
Boris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20160417/26c15e48/attachment.html>

From pav at iki.fi  Sun Apr 17 13:15:50 2016
From: pav at iki.fi (Pauli Virtanen)
Date: Sun, 17 Apr 2016 17:15:50 +0000 (UTC)
Subject: [SciPy-Dev] On an example problem from optimize/nonlin.py
References: <CAMarX1U148D0NgfgOE6Z6cFgpLdzFK5osd71RisUHdxmC9Ypew@mail.gmail.com>
Message-ID: <nf0gc5$pjv$1@ger.gmane.org>

Hi,

Sun, 17 Apr 2016 20:10:19 +0300, Boris Faleichik kirjoitti:
> my question is addressed to the authors of
> https://github.com/scipy/scipy/blob/master/scipy/optimize/nonlin.py.
> 
> I am looking for more detailed description of the nonlinear
> integro-differential equation which is a test problem for Newton-Krylov
> iteration in the documentation:
> 
> \nabla^2 P = 10 \left(\int_0^1\int_0^1\cosh(P)\,dx\,dy\right)^2

This is just some random equation. There's no physical or otherwise 
background for it.

-- 
Pauli Virtanen



From wesleywang1996 at berkeley.edu  Mon Apr 18 18:47:07 2016
From: wesleywang1996 at berkeley.edu (WESLEY WANG)
Date: Mon, 18 Apr 2016 15:47:07 -0700
Subject: [SciPy-Dev] coding project
Message-ID: <CABTfAMn7kTBxej=27LYs-RA98EaP5PwEDa1_hiBEi2VyAYL8vQ@mail.gmail.com>

Hi All!

My name is Wesley Wang and I am currently working on a project for our
class which involves helping contribute to a project. While I was looking
through a list of projects, I became very interested in SciPy, which
combines coding with math and science.

Is there anything which I can possibly contribute to in terms of code? (As
a chemistry major, I'm looking to maybe add or change some things in the
constants.py file involving constants commonly used in chemistry)

Any feedback would be nice!
Thanks and have a great day!

-Wesley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20160418/6af81a92/attachment.html>

From evgeny.burovskiy at gmail.com  Mon Apr 18 19:02:17 2016
From: evgeny.burovskiy at gmail.com (Evgeni Burovski)
Date: Tue, 19 Apr 2016 00:02:17 +0100
Subject: [SciPy-Dev] coding project
In-Reply-To: <CABTfAMn7kTBxej=27LYs-RA98EaP5PwEDa1_hiBEi2VyAYL8vQ@mail.gmail.com>
References: <CABTfAMn7kTBxej=27LYs-RA98EaP5PwEDa1_hiBEi2VyAYL8vQ@mail.gmail.com>
Message-ID: <CAMRo0isPcd3NaD1vpauo-Bb5dbsaoFeiFSk6JkxTkdx=6f5fig@mail.gmail.com>

On Mon, Apr 18, 2016 at 11:47 PM, WESLEY WANG
<wesleywang1996 at berkeley.edu> wrote:
> Hi All!
>
> My name is Wesley Wang and I am currently working on a project for our class
> which involves helping contribute to a project. While I was looking through
> a list of projects, I became very interested in SciPy, which combines coding
> with math and science.
>
> Is there anything which I can possibly contribute to in terms of code? (As a
> chemistry major, I'm looking to maybe add or change some things in the
> constants.py file involving constants commonly used in chemistry)
>
> Any feedback would be nice!
> Thanks and have a great day!
>
> -Wesley


Hi Wesley,

Welcome!

We have a bug tracker on Github, anything on it is a fair game :-).
Depending on your skill set, you might want to start with issues
labeled as easy-fix:
https://github.com/scipy/scipy/issues?q=is%3Aopen+is%3Aissue+label%3Aeasy-fix
There is also a backlog of pull requests, some of which are in a need
of a finishing touch or two.

To a first approximation, anything listed on github is a fair game :-).

Contributions are definitely most welcome!

Cheers,

Evgeni


From pav at iki.fi  Sat Apr 23 11:54:47 2016
From: pav at iki.fi (Pauli Virtanen)
Date: Sat, 23 Apr 2016 15:54:47 +0000 (UTC)
Subject: [SciPy-Dev] scipy 0.17.1 release
References: <CAMRo0iuiyyJQeDDCwQdW2tGFtPQ3nn17hajupQGEQ_q78f5oVA@mail.gmail.com>
Message-ID: <nfg5s7$lk7$1@ger.gmane.org>

Sun, 10 Apr 2016 18:53:36 +0100, Evgeni Burovski kirjoitti:
> I'm planning to cut the point release of scipy 0.17.1 by the end of this
> week.
> Thoughts?

This could be backported:

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

Added the backport-candidate tag.



From pav at iki.fi  Sun Apr 24 16:38:12 2016
From: pav at iki.fi (Pauli Virtanen)
Date: Sun, 24 Apr 2016 20:38:12 +0000 (UTC)
Subject: [SciPy-Dev] PR adding boundary value problem solver in scipy
Message-ID: <nfjark$nd$1@ger.gmane.org>

Hi,

I'd like to draw attention to a PR from Nikolay adding a BVP problem 
solver to Scipy. If this is interesting to you, maybe try it out:

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

	Pauli



From evgeny.burovskiy at gmail.com  Tue Apr 26 08:21:30 2016
From: evgeny.burovskiy at gmail.com (Evgeni Burovski)
Date: Tue, 26 Apr 2016 13:21:30 +0100
Subject: [SciPy-Dev] scipy 0.17.1 release
In-Reply-To: <CAMRo0iuiyyJQeDDCwQdW2tGFtPQ3nn17hajupQGEQ_q78f5oVA@mail.gmail.com>
References: <CAMRo0iuiyyJQeDDCwQdW2tGFtPQ3nn17hajupQGEQ_q78f5oVA@mail.gmail.com>
Message-ID: <CAMRo0itRT_x_xDNv8k5UqbN-As3O3KSd2G1RjwomCsSAJOE6Ug@mail.gmail.com>

On Sun, Apr 10, 2016 at 6:53 PM, Evgeni Burovski
<evgeny.burovskiy at gmail.com> wrote:
> Hi,
>
> I'm planning to cut the point release of scipy 0.17.1 by the end of this week.
> Thoughts?
>
> Regressions in 0.17.0 so far seem reasonably mild:
> https://github.com/scipy/scipy/milestones/0.17.1
> If there's anything else you think should be included in 0.17.1,
> please mention it in this email thread or on Github.


Quite obviously, it did not happen by the end of the week before last :-).

At the moment though, the remaining blocker is the backwards
compatibility break in `stats.mannwhitneyu` where the default
hypothesis differ in 0.16.1 and 0.17.0.

The PR with the fix which restores the backwards compat is
https://github.com/scipy/scipy/pull/6100

My plan is to merge it and finalize 0.17.1 soon (tm). Please speak up
if you have comments about this fix and/or would like more time to
review it.

Cheers,

Evgeni


From wavexx at thregr.org  Fri Apr 29 13:28:36 2016
From: wavexx at thregr.org (Yuri D'Elia)
Date: Fri, 29 Apr 2016 19:28:36 +0200
Subject: [SciPy-Dev] PR for signal.planck (Planck-taper and
	Planck-Bessel window functions)
References: <87h9fa8sz5.fsf@wavexx.thregr.org>
Message-ID: <87a8kcqq7v.fsf@wavexx.thregr.org>

On Sat, Apr 09 2016, Yuri D'Elia wrote:
> I'd like to bring to your attention this PR:
>
>   https://github.com/scipy/scipy/pull/6012
>
> which implements the Plack-taper window (http://arxiv.org/pdf/1003.2939)
> along with tests and documentation.

Hrrrm, I should have said:

  Gravitational Research @ Home
  Drive the LIGO with Python?

or...

  All the windows you need!
  Pull one, get two!

But seriously, these are seldomly used windows yes. The only issue I see
is that sp.signal might not be the best namespace to put them in.

What about having a proper namespace for window generators
(sp.signal.window) instead, leaving the old ones as aliases for backward
compatibility?

We do have get_window(), which is the perfect generic entry point. If
the window has been used and cited in the literature, I'd personally
like to have it available.