From ilhanpolat at gmail.com  Wed May  1 07:04:12 2019
From: ilhanpolat at gmail.com (Ilhan Polat)
Date: Wed, 1 May 2019 13:04:12 +0200
Subject: [SciPy-Dev] scipy.org logo original?
In-Reply-To: <CABL7CQgwo5ewG3g4eJ-oRT6JXb6EAqFGDLcrdXchHxTF0fAbaA@mail.gmail.com>
References: <CABL7CQi6FjoR=ekZDd+z7GoWZKJNEr3+Dh3FfTGSTh2CviyNqQ@mail.gmail.com>
 <20190429172600.tykgkl325xdygw74@carbo>
 <20190429174103.7xbkfyndweuv24ts@carbo>
 <CAEBuzr_jC9wnQKiyeojRp3C=ZcLaa9LTDHzwuS7GcitdoTbGdA@mail.gmail.com>
 <CAEBuzr9e32JUCkLii0Gu+B1+exzTsN_RAc9rKJUNn0siZaJfdA@mail.gmail.com>
 <CABL7CQgwo5ewG3g4eJ-oRT6JXb6EAqFGDLcrdXchHxTF0fAbaA@mail.gmail.com>
Message-ID: <CAEBuzr-Ck=AxsuK+TtVAQ+NMjHGje0oxFCjDE8wYK6T9fHVXMQ@mail.gmail.com>

> Would you be able to make a web-sized image and add it to
scipy-sphinx-theme?
Yes that's not a problem thanks to the vector graphics. The main concern
here is the legibility of the font. I now think that the original font was
ITC franklin medium though.

Anyways, I have searched for some open source fonts in the meantime and
many curation pages are available online; to give two results from a quick
Google search

https://medium.com/sketch-app-sources/30-free-and-open-source-typefaces-released-recently-best-collections-5b46f9d89f65
https://www.forbes.com/sites/allbusiness/2014/03/06/10-best-sans-serif-web-fonts-from-google-fonts-library/#21da8027431b

I am no designer by any means hence take these as availability stats but we
might be better off if we switch to a font with suitable license in place
for a commercial font. Also all feedback and help are welcome.

Best,



On Tue, Apr 30, 2019 at 3:10 PM Ralf Gommers <ralf.gommers at gmail.com> wrote:

> Thanks Stefan & Ilhan!
>
> Scikit-image has the right idea I think with a separate branding repo.
> Shall we create one for SciPy as well?
>
> Ilhan, that looks really good! Would you be able to make a web-sized image
> and add it to scipy-sphinx-theme? The current image is a 2.4kb gif, I think
> it can be larger but as small as possible while still looking good would be
> nice. Because it gets downloaded millions of times a month, and also
> directly adds to the size of the numpy and scipy sdists.
>
> Cheers,
> Ralf
>
>
> On Mon, Apr 29, 2019 at 10:44 PM Ilhan Polat <ilhanpolat at gmail.com> wrote:
>
>> By the way does anyone know what the font logo is? Just by eyeballing it
>> looks like Franklin Gothic but I am not sure. However, if there is a more
>> able typography connoisseur among us, here is the logo ready to be compiled
>> by Xe/LuaLatex.
>>
>> \documentclass[tikz]{standalone}
>> \usepackage{fontspec}
>> \setsansfont{Franklin Gothic Medium}
>> \usetikzlibrary{svg.path}
>> \definecolor{scipylogo}{HTML}{8CAAE6}
>>
>> \begin{document}
>> \begin{tikzpicture}[x=1pt, y=-1pt]
>>
>> \fill[scipylogo] (-50,-75) rectangle (1825, 575)
>> svg[yscale=-1] {
>> M348.369,282.469c-17.398-23.797-43.984-33.719-81.984-41.719
>>
>> l-35.334-8.332l-26.656-11.432c-14.01-9.902-25.947-36.26-22.559-59.502c5.264-36.006,38.896-61.104,75.127-56.045
>>
>> c18.094,2.559,33.438,12.139,43.555,25.625l40.117,52.705c22.93,29.531,48.711,38.32,76.758,24.375l14.141-6.016
>>
>> c1.133-0.527,2.461-0.576,3.75-0.107c1.055,0.41,1.914,1.162,2.422,2.051l2.813,4.238c0.781,1.279,1.953,2.314,3.477,2.891
>>
>> c2.578,0.977,5.352,0.391,7.305-1.289l32.578-30.723c5.703-4.883,4.023-9.365,4.023-9.365l-7.852-17.881
>>
>> c0,0-2.148-4.287-9.57-3.301l-43.672,4.014c-2.539,0.361-4.805,2.051-5.781,4.629c-0.586,1.504-0.625,3.076-0.195,4.502
>>
>> l1.563,5.029c0.313,1.045,0.313,2.217-0.117,3.291c-0.508,1.328-1.523,2.266-2.734,2.764l-12.344,5.225
>>
>> c-12.93,7.568-27.617,2.734-37.422-9.258l-11.211-14.893l-31.914-42.354c-15.156-20.098-38.008-34.434-65-38.203
>>
>> c-54.043-7.568-104.199,29.854-112.051,83.584c-3.965,27.08,4.152,52.703,18.965,73.281
>>
>> c10.762,14.953,30.486,23.496,41.154,26.164l28,8l26.814,6.145c3.688,0.875,14.063,3.438,20.203,5.656
>>
>> c5.676,2.055,18.75,6.875,29.375,15.57l0,0c12.695,12.906,19.414,31.344,16.563,50.68c-4.805,32.969-35.586,55.938-68.75,51.289
>>
>> c-16.611-2.305-30.635-11.109-39.922-23.438l-38.32-50.859c-7.813-10.367-19.629-17.773-33.594-19.766
>>
>> c-13.945-1.953-27.441,1.914-37.9,9.75l-80.615,60.156C11.455,333.914,0,292.898,0,249.266C0,111.621,113.926,0,254.443,0
>>
>> c104.629,0,194.434,61.855,233.535,150.254l12.891-5.996l8.711-23.809l9.141,3.203l-7.852,21.289l21.758,7.5l-3.281,8.916
>>
>> l-24.297-8.486l-13.398,6.162c11.094,27.998,17.266,58.398,17.266,90.232c0,137.656-113.945,249.258-254.473,249.258
>>
>> c-84.414,0-159.229-40.289-205.508-102.281l82.578-61.898c3.779-2.578,8.467-3.75,13.33-3.086
>>
>> c5.176,0.742,9.58,3.461,12.471,7.305l40.537,54.477c14.277,17.516,35.02,29.922,59.307,33.336
>>
>> c51.094,7.148,98.516-28.242,105.938-79.063C366.533,323.664,360.752,300.828,348.369,282.469};
>>
>> \node[anchor=east,
>>       text=white,
>>       font=\sffamily,
>>       scale=30,
>>       outer sep=0pt,
>>       inner sep=0pt] (scipyorg) at (1750,250) {SciPy.org};
>> \end{tikzpicture}
>> \end{document}
>>
>> This code gives on my system
>>
>> [image: image.png]
>>
>> "i" and "P" needs a slight nudge to each other but that means the font is
>> correct. Hence my question. Also you can play around and enjoy some TeX
>> kerning/positioning/scaling bonanza yourself. I'll let Ralf to be the judge
>> :)
>>
>> Best,
>> ilhan
>>
>> On Mon, Apr 29, 2019 at 8:09 PM Ilhan Polat <ilhanpolat at gmail.com> wrote:
>>
>>> Perfect! Thanks.
>>>
>>> On Mon, Apr 29, 2019 at 7:44 PM Stefan van der Walt <
>>> stefanv at berkeley.edu> wrote:
>>>
>>>> Found it and uploaded to GitHub:
>>>>
>>>>
>>>> https://github.com/scikit-image/skimage-branding/blob/master/logo/scipy.svg
>>>>
>>>> On Mon, 29 Apr 2019 10:26:00 -0700, Stefan van der Walt wrote:
>>>> > On Sat, 27 Apr 2019 23:49:03 +0200, Ralf Gommers wrote:
>>>> > > Does anyone have the original files from which the current logo on
>>>> scipy.org
>>>> > > (it has the scipy symbol, white letter scipy.org and "sponsored by
>>>> > > Enthough") was created? The quality is not great, and editing a
>>>> tiny gif
>>>> > > doesn't make it better ....
>>>> >
>>>> > I don't have the vector art, but I have a higher resolution render:
>>>> >
>>>> https://github.com/scikit-image/skimage-branding/blob/master/logo/data/scipy.png
>>>> >
>>>> > St?fan
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at python.org
>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>
>>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190501/8cc0dd44/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 32300 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190501/8cc0dd44/attachment-0001.png>

From chrissie.c.l at gmail.com  Wed May  1 08:49:52 2019
From: chrissie.c.l at gmail.com (Christina Lee)
Date: Wed, 1 May 2019 13:49:52 +0100
Subject: [SciPy-Dev] scipy.org logo original?
In-Reply-To: <CAEBuzr-Ck=AxsuK+TtVAQ+NMjHGje0oxFCjDE8wYK6T9fHVXMQ@mail.gmail.com>
References: <CABL7CQi6FjoR=ekZDd+z7GoWZKJNEr3+Dh3FfTGSTh2CviyNqQ@mail.gmail.com>
 <20190429172600.tykgkl325xdygw74@carbo>
 <20190429174103.7xbkfyndweuv24ts@carbo>
 <CAEBuzr_jC9wnQKiyeojRp3C=ZcLaa9LTDHzwuS7GcitdoTbGdA@mail.gmail.com>
 <CAEBuzr9e32JUCkLii0Gu+B1+exzTsN_RAc9rKJUNn0siZaJfdA@mail.gmail.com>
 <CABL7CQgwo5ewG3g4eJ-oRT6JXb6EAqFGDLcrdXchHxTF0fAbaA@mail.gmail.com>
 <CAEBuzr-Ck=AxsuK+TtVAQ+NMjHGje0oxFCjDE8wYK6T9fHVXMQ@mail.gmail.com>
Message-ID: <CAKkGBSYJ1a5vQym5Hh375jfgG+6FqcefNSMuFkEghZxSCw6LXQ@mail.gmail.com>

Quick question, why does it include ".org"?   Can't the logo just say
"SciPy"?

A good rule of websites is to use svg whenever reasonable.  The main logo
isn't the only image where doing this could bump up cleanliness.  Several
other logos on the main page could also use an update.  For example, just
traced over the download graphic as attached. No more resolution problems,
and smaller.

Christina




On Wed, May 1, 2019 at 12:05 PM Ilhan Polat <ilhanpolat at gmail.com> wrote:

> > Would you be able to make a web-sized image and add it to
> scipy-sphinx-theme?
> Yes that's not a problem thanks to the vector graphics. The main concern
> here is the legibility of the font. I now think that the original font was
> ITC franklin medium though.
>
> Anyways, I have searched for some open source fonts in the meantime and
> many curation pages are available online; to give two results from a quick
> Google search
>
>
> https://medium.com/sketch-app-sources/30-free-and-open-source-typefaces-released-recently-best-collections-5b46f9d89f65
>
> https://www.forbes.com/sites/allbusiness/2014/03/06/10-best-sans-serif-web-fonts-from-google-fonts-library/#21da8027431b
>
> I am no designer by any means hence take these as availability stats but
> we might be better off if we switch to a font with suitable license in
> place for a commercial font. Also all feedback and help are welcome.
>
> Best,
>
>
>
> On Tue, Apr 30, 2019 at 3:10 PM Ralf Gommers <ralf.gommers at gmail.com>
> wrote:
>
>> Thanks Stefan & Ilhan!
>>
>> Scikit-image has the right idea I think with a separate branding repo.
>> Shall we create one for SciPy as well?
>>
>> Ilhan, that looks really good! Would you be able to make a web-sized
>> image and add it to scipy-sphinx-theme? The current image is a 2.4kb gif, I
>> think it can be larger but as small as possible while still looking good
>> would be nice. Because it gets downloaded millions of times a month, and
>> also directly adds to the size of the numpy and scipy sdists.
>>
>> Cheers,
>> Ralf
>>
>>
>> On Mon, Apr 29, 2019 at 10:44 PM Ilhan Polat <ilhanpolat at gmail.com>
>> wrote:
>>
>>> By the way does anyone know what the font logo is? Just by eyeballing it
>>> looks like Franklin Gothic but I am not sure. However, if there is a more
>>> able typography connoisseur among us, here is the logo ready to be compiled
>>> by Xe/LuaLatex.
>>>
>>> \documentclass[tikz]{standalone}
>>> \usepackage{fontspec}
>>> \setsansfont{Franklin Gothic Medium}
>>> \usetikzlibrary{svg.path}
>>> \definecolor{scipylogo}{HTML}{8CAAE6}
>>>
>>> \begin{document}
>>> \begin{tikzpicture}[x=1pt, y=-1pt]
>>>
>>> \fill[scipylogo] (-50,-75) rectangle (1825, 575)
>>> svg[yscale=-1] {
>>> M348.369,282.469c-17.398-23.797-43.984-33.719-81.984-41.719
>>>
>>> l-35.334-8.332l-26.656-11.432c-14.01-9.902-25.947-36.26-22.559-59.502c5.264-36.006,38.896-61.104,75.127-56.045
>>>
>>> c18.094,2.559,33.438,12.139,43.555,25.625l40.117,52.705c22.93,29.531,48.711,38.32,76.758,24.375l14.141-6.016
>>>
>>> c1.133-0.527,2.461-0.576,3.75-0.107c1.055,0.41,1.914,1.162,2.422,2.051l2.813,4.238c0.781,1.279,1.953,2.314,3.477,2.891
>>>
>>> c2.578,0.977,5.352,0.391,7.305-1.289l32.578-30.723c5.703-4.883,4.023-9.365,4.023-9.365l-7.852-17.881
>>>
>>> c0,0-2.148-4.287-9.57-3.301l-43.672,4.014c-2.539,0.361-4.805,2.051-5.781,4.629c-0.586,1.504-0.625,3.076-0.195,4.502
>>>
>>> l1.563,5.029c0.313,1.045,0.313,2.217-0.117,3.291c-0.508,1.328-1.523,2.266-2.734,2.764l-12.344,5.225
>>>
>>> c-12.93,7.568-27.617,2.734-37.422-9.258l-11.211-14.893l-31.914-42.354c-15.156-20.098-38.008-34.434-65-38.203
>>>
>>> c-54.043-7.568-104.199,29.854-112.051,83.584c-3.965,27.08,4.152,52.703,18.965,73.281
>>>
>>> c10.762,14.953,30.486,23.496,41.154,26.164l28,8l26.814,6.145c3.688,0.875,14.063,3.438,20.203,5.656
>>>
>>> c5.676,2.055,18.75,6.875,29.375,15.57l0,0c12.695,12.906,19.414,31.344,16.563,50.68c-4.805,32.969-35.586,55.938-68.75,51.289
>>>
>>> c-16.611-2.305-30.635-11.109-39.922-23.438l-38.32-50.859c-7.813-10.367-19.629-17.773-33.594-19.766
>>>
>>> c-13.945-1.953-27.441,1.914-37.9,9.75l-80.615,60.156C11.455,333.914,0,292.898,0,249.266C0,111.621,113.926,0,254.443,0
>>>
>>> c104.629,0,194.434,61.855,233.535,150.254l12.891-5.996l8.711-23.809l9.141,3.203l-7.852,21.289l21.758,7.5l-3.281,8.916
>>>
>>> l-24.297-8.486l-13.398,6.162c11.094,27.998,17.266,58.398,17.266,90.232c0,137.656-113.945,249.258-254.473,249.258
>>>
>>> c-84.414,0-159.229-40.289-205.508-102.281l82.578-61.898c3.779-2.578,8.467-3.75,13.33-3.086
>>>
>>> c5.176,0.742,9.58,3.461,12.471,7.305l40.537,54.477c14.277,17.516,35.02,29.922,59.307,33.336
>>>
>>> c51.094,7.148,98.516-28.242,105.938-79.063C366.533,323.664,360.752,300.828,348.369,282.469};
>>>
>>> \node[anchor=east,
>>>       text=white,
>>>       font=\sffamily,
>>>       scale=30,
>>>       outer sep=0pt,
>>>       inner sep=0pt] (scipyorg) at (1750,250) {SciPy.org};
>>> \end{tikzpicture}
>>> \end{document}
>>>
>>> This code gives on my system
>>>
>>> [image: image.png]
>>>
>>> "i" and "P" needs a slight nudge to each other but that means the font
>>> is correct. Hence my question. Also you can play around and enjoy some TeX
>>> kerning/positioning/scaling bonanza yourself. I'll let Ralf to be the judge
>>> :)
>>>
>>> Best,
>>> ilhan
>>>
>>> On Mon, Apr 29, 2019 at 8:09 PM Ilhan Polat <ilhanpolat at gmail.com>
>>> wrote:
>>>
>>>> Perfect! Thanks.
>>>>
>>>> On Mon, Apr 29, 2019 at 7:44 PM Stefan van der Walt <
>>>> stefanv at berkeley.edu> wrote:
>>>>
>>>>> Found it and uploaded to GitHub:
>>>>>
>>>>>
>>>>> https://github.com/scikit-image/skimage-branding/blob/master/logo/scipy.svg
>>>>>
>>>>> On Mon, 29 Apr 2019 10:26:00 -0700, Stefan van der Walt wrote:
>>>>> > On Sat, 27 Apr 2019 23:49:03 +0200, Ralf Gommers wrote:
>>>>> > > Does anyone have the original files from which the current logo on
>>>>> scipy.org
>>>>> > > (it has the scipy symbol, white letter scipy.org and "sponsored by
>>>>> > > Enthough") was created? The quality is not great, and editing a
>>>>> tiny gif
>>>>> > > doesn't make it better ....
>>>>> >
>>>>> > I don't have the vector art, but I have a higher resolution render:
>>>>> >
>>>>> https://github.com/scikit-image/skimage-branding/blob/master/logo/data/scipy.png
>>>>> >
>>>>> > St?fan
>>>>> _______________________________________________
>>>>> SciPy-Dev mailing list
>>>>> SciPy-Dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>
>>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190501/0066641d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 32300 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190501/0066641d/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: download.svg
Type: image/svg+xml
Size: 7149 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190501/0066641d/attachment-0001.svg>

From ralf.gommers at gmail.com  Wed May  1 09:34:18 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Wed, 1 May 2019 15:34:18 +0200
Subject: [SciPy-Dev] scipy.org logo original?
In-Reply-To: <CAKkGBSYJ1a5vQym5Hh375jfgG+6FqcefNSMuFkEghZxSCw6LXQ@mail.gmail.com>
References: <CABL7CQi6FjoR=ekZDd+z7GoWZKJNEr3+Dh3FfTGSTh2CviyNqQ@mail.gmail.com>
 <20190429172600.tykgkl325xdygw74@carbo>
 <20190429174103.7xbkfyndweuv24ts@carbo>
 <CAEBuzr_jC9wnQKiyeojRp3C=ZcLaa9LTDHzwuS7GcitdoTbGdA@mail.gmail.com>
 <CAEBuzr9e32JUCkLii0Gu+B1+exzTsN_RAc9rKJUNn0siZaJfdA@mail.gmail.com>
 <CABL7CQgwo5ewG3g4eJ-oRT6JXb6EAqFGDLcrdXchHxTF0fAbaA@mail.gmail.com>
 <CAEBuzr-Ck=AxsuK+TtVAQ+NMjHGje0oxFCjDE8wYK6T9fHVXMQ@mail.gmail.com>
 <CAKkGBSYJ1a5vQym5Hh375jfgG+6FqcefNSMuFkEghZxSCw6LXQ@mail.gmail.com>
Message-ID: <CABL7CQh-Qa7hz9UY_PCJoVdG9VQBdTd0jQOXDrdzD95L+NNUsA@mail.gmail.com>

On Wed, May 1, 2019 at 2:50 PM Christina Lee <chrissie.c.l at gmail.com> wrote:

> Quick question, why does it include ".org"?   Can't the logo just say
> "SciPy"?
>

Thanks Christina, that's a great question. I can't think of a reason, just
"SciPy" seems better. Perhaps we've been staring at it for so long that
it's not noticeable anymore. Let's change it now.


> A good rule of websites is to use svg whenever reasonable.  The main logo
> isn't the only image where doing this could bump up cleanliness.  Several
> other logos on the main page could also use an update.  For example, just
> traced over the download graphic as attached. No more resolution problems,
> and smaller.
>

That's great, thank you! Yes, you're right ... and it's not just the logos
that could use a makeover, the whole site needs attention.

Cheers,
Ralf


>
> On Wed, May 1, 2019 at 12:05 PM Ilhan Polat <ilhanpolat at gmail.com> wrote:
>
>> > Would you be able to make a web-sized image and add it to
>> scipy-sphinx-theme?
>> Yes that's not a problem thanks to the vector graphics. The main concern
>> here is the legibility of the font. I now think that the original font was
>> ITC franklin medium though.
>>
>> Anyways, I have searched for some open source fonts in the meantime and
>> many curation pages are available online; to give two results from a quick
>> Google search
>>
>>
>> https://medium.com/sketch-app-sources/30-free-and-open-source-typefaces-released-recently-best-collections-5b46f9d89f65
>>
>> https://www.forbes.com/sites/allbusiness/2014/03/06/10-best-sans-serif-web-fonts-from-google-fonts-library/#21da8027431b
>>
>> I am no designer by any means hence take these as availability stats but
>> we might be better off if we switch to a font with suitable license in
>> place for a commercial font. Also all feedback and help are welcome.
>>
>> Best,
>>
>>
>>
>> On Tue, Apr 30, 2019 at 3:10 PM Ralf Gommers <ralf.gommers at gmail.com>
>> wrote:
>>
>>> Thanks Stefan & Ilhan!
>>>
>>> Scikit-image has the right idea I think with a separate branding repo.
>>> Shall we create one for SciPy as well?
>>>
>>> Ilhan, that looks really good! Would you be able to make a web-sized
>>> image and add it to scipy-sphinx-theme? The current image is a 2.4kb gif, I
>>> think it can be larger but as small as possible while still looking good
>>> would be nice. Because it gets downloaded millions of times a month, and
>>> also directly adds to the size of the numpy and scipy sdists.
>>>
>>> Cheers,
>>> Ralf
>>>
>>>
>>> On Mon, Apr 29, 2019 at 10:44 PM Ilhan Polat <ilhanpolat at gmail.com>
>>> wrote:
>>>
>>>> By the way does anyone know what the font logo is? Just by eyeballing
>>>> it looks like Franklin Gothic but I am not sure. However, if there is a
>>>> more able typography connoisseur among us, here is the logo ready to be
>>>> compiled by Xe/LuaLatex.
>>>>
>>>> \documentclass[tikz]{standalone}
>>>> \usepackage{fontspec}
>>>> \setsansfont{Franklin Gothic Medium}
>>>> \usetikzlibrary{svg.path}
>>>> \definecolor{scipylogo}{HTML}{8CAAE6}
>>>>
>>>> \begin{document}
>>>> \begin{tikzpicture}[x=1pt, y=-1pt]
>>>>
>>>> \fill[scipylogo] (-50,-75) rectangle (1825, 575)
>>>> svg[yscale=-1] {
>>>> M348.369,282.469c-17.398-23.797-43.984-33.719-81.984-41.719
>>>>
>>>> l-35.334-8.332l-26.656-11.432c-14.01-9.902-25.947-36.26-22.559-59.502c5.264-36.006,38.896-61.104,75.127-56.045
>>>>
>>>> c18.094,2.559,33.438,12.139,43.555,25.625l40.117,52.705c22.93,29.531,48.711,38.32,76.758,24.375l14.141-6.016
>>>>
>>>> c1.133-0.527,2.461-0.576,3.75-0.107c1.055,0.41,1.914,1.162,2.422,2.051l2.813,4.238c0.781,1.279,1.953,2.314,3.477,2.891
>>>>
>>>> c2.578,0.977,5.352,0.391,7.305-1.289l32.578-30.723c5.703-4.883,4.023-9.365,4.023-9.365l-7.852-17.881
>>>>
>>>> c0,0-2.148-4.287-9.57-3.301l-43.672,4.014c-2.539,0.361-4.805,2.051-5.781,4.629c-0.586,1.504-0.625,3.076-0.195,4.502
>>>>
>>>> l1.563,5.029c0.313,1.045,0.313,2.217-0.117,3.291c-0.508,1.328-1.523,2.266-2.734,2.764l-12.344,5.225
>>>>
>>>> c-12.93,7.568-27.617,2.734-37.422-9.258l-11.211-14.893l-31.914-42.354c-15.156-20.098-38.008-34.434-65-38.203
>>>>
>>>> c-54.043-7.568-104.199,29.854-112.051,83.584c-3.965,27.08,4.152,52.703,18.965,73.281
>>>>
>>>> c10.762,14.953,30.486,23.496,41.154,26.164l28,8l26.814,6.145c3.688,0.875,14.063,3.438,20.203,5.656
>>>>
>>>> c5.676,2.055,18.75,6.875,29.375,15.57l0,0c12.695,12.906,19.414,31.344,16.563,50.68c-4.805,32.969-35.586,55.938-68.75,51.289
>>>>
>>>> c-16.611-2.305-30.635-11.109-39.922-23.438l-38.32-50.859c-7.813-10.367-19.629-17.773-33.594-19.766
>>>>
>>>> c-13.945-1.953-27.441,1.914-37.9,9.75l-80.615,60.156C11.455,333.914,0,292.898,0,249.266C0,111.621,113.926,0,254.443,0
>>>>
>>>> c104.629,0,194.434,61.855,233.535,150.254l12.891-5.996l8.711-23.809l9.141,3.203l-7.852,21.289l21.758,7.5l-3.281,8.916
>>>>
>>>> l-24.297-8.486l-13.398,6.162c11.094,27.998,17.266,58.398,17.266,90.232c0,137.656-113.945,249.258-254.473,249.258
>>>>
>>>> c-84.414,0-159.229-40.289-205.508-102.281l82.578-61.898c3.779-2.578,8.467-3.75,13.33-3.086
>>>>
>>>> c5.176,0.742,9.58,3.461,12.471,7.305l40.537,54.477c14.277,17.516,35.02,29.922,59.307,33.336
>>>>
>>>> c51.094,7.148,98.516-28.242,105.938-79.063C366.533,323.664,360.752,300.828,348.369,282.469};
>>>>
>>>> \node[anchor=east,
>>>>       text=white,
>>>>       font=\sffamily,
>>>>       scale=30,
>>>>       outer sep=0pt,
>>>>       inner sep=0pt] (scipyorg) at (1750,250) {SciPy.org};
>>>> \end{tikzpicture}
>>>> \end{document}
>>>>
>>>> This code gives on my system
>>>>
>>>> [image: image.png]
>>>>
>>>> "i" and "P" needs a slight nudge to each other but that means the font
>>>> is correct. Hence my question. Also you can play around and enjoy some TeX
>>>> kerning/positioning/scaling bonanza yourself. I'll let Ralf to be the judge
>>>> :)
>>>>
>>>> Best,
>>>> ilhan
>>>>
>>>> On Mon, Apr 29, 2019 at 8:09 PM Ilhan Polat <ilhanpolat at gmail.com>
>>>> wrote:
>>>>
>>>>> Perfect! Thanks.
>>>>>
>>>>> On Mon, Apr 29, 2019 at 7:44 PM Stefan van der Walt <
>>>>> stefanv at berkeley.edu> wrote:
>>>>>
>>>>>> Found it and uploaded to GitHub:
>>>>>>
>>>>>>
>>>>>> https://github.com/scikit-image/skimage-branding/blob/master/logo/scipy.svg
>>>>>>
>>>>>> On Mon, 29 Apr 2019 10:26:00 -0700, Stefan van der Walt wrote:
>>>>>> > On Sat, 27 Apr 2019 23:49:03 +0200, Ralf Gommers wrote:
>>>>>> > > Does anyone have the original files from which the current logo
>>>>>> on scipy.org
>>>>>> > > (it has the scipy symbol, white letter scipy.org and "sponsored
>>>>>> by
>>>>>> > > Enthough") was created? The quality is not great, and editing a
>>>>>> tiny gif
>>>>>> > > doesn't make it better ....
>>>>>> >
>>>>>> > I don't have the vector art, but I have a higher resolution render:
>>>>>> >
>>>>>> https://github.com/scikit-image/skimage-branding/blob/master/logo/data/scipy.png
>>>>>> >
>>>>>> > St?fan
>>>>>> _______________________________________________
>>>>>> SciPy-Dev mailing list
>>>>>> SciPy-Dev at python.org
>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>
>>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at python.org
>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190501/4d423e8a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 32300 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190501/4d423e8a/attachment-0001.png>

From tyler.je.reddy at gmail.com  Wed May  1 14:12:59 2019
From: tyler.je.reddy at gmail.com (Tyler Reddy)
Date: Wed, 1 May 2019 11:12:59 -0700
Subject: [SciPy-Dev] ANN: SciPy 1.3.0rc1 -- please test
In-Reply-To: <CAHPuU_Y5wAntg1FnpR1fowzN7J1e+WD7P1RMRh-A3bVBJsb3qQ@mail.gmail.com>
References: <CAHPuU_Y5wAntg1FnpR1fowzN7J1e+WD7P1RMRh-A3bVBJsb3qQ@mail.gmail.com>
Message-ID: <CAHPuU_bZgDNUZTUFN9G71de2PWvGWe+wXJzd+pRbtvchNCLWqQ@mail.gmail.com>

I'd very much appreciate if someone with access to Skylake architecture can
confirm linear algebra-related failures / issues
for SciPy 1.2.1 and SciPy 1.3.0rc1:

for a simple example:
https://github.com/numpy/numpy/issues/13401#issuecomment-486690487

There's some credible concern that both of those releases have effectively
broken linear algebra behavior for wheels
with the OpenBLAS versions they are distributed with, but I want to be sure
before investing time in updating two
release branches obviously!

On Fri, 26 Apr 2019 at 18:25, Tyler Reddy <tyler.je.reddy at gmail.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi all,
>
> On behalf of the SciPy development team I'm pleased to announce
> the release candidate SciPy 1.3.0rc1. Please help us test this pre-release.
>
> Sources and binary wheels can be found at:https://pypi.org/project/scipy/
> and at:https://github.com/scipy/scipy/releases/tag/v1.3.0rc1
> One of a few ways to install the release candidate with pip:
> pip install scipy==1.3.0rc1
>
> ==========================
> SciPy 1.3.0 Release Notes
> ==========================
>
> Note: Scipy 1.3.0 is not released yet!
>
> SciPy 1.3.0 is the culmination of 5 months of hard work. It contains
> many new features, numerous bug-fixes, improved test coverage and better
> documentation. There have been some API changes
> in this release, which are documented below. All users are encouraged to
> upgrade to this release, as there are a large number of bug-fixes and
> optimizations. Before upgrading, we recommend that users check that
> their own code does not use deprecated SciPy functionality (to do so,
> run your code with ``python -Wd`` and check for ``DeprecationWarning`` s).
> Our development attention will now shift to bug-fix releases on the
> 1.3.x branch, and on adding new features on the master branch.
>
> This release requires Python 3.5+ and NumPy 1.13.3 or greater.
>
> For running on PyPy, PyPy3 6.0+ and NumPy 1.15.0 are required.
>
> Highlights of this release
> --------------------------
>
> - Three new ``stats`` functions, a rewrite of ``pearsonr``, and an exact
>   computation of the Kolmogorov-Smirnov two-sample test
> - A new Cython API for bounded scalar-function root-finders in `scipy.optimize`
> - Substantial ``CSR`` and ``CSC`` sparse matrix indexing performance
>   improvements
> - Added support for interpolation of rotations with continuous angular
>   rate and acceleration in ``RotationSpline``
>
>
> New features
> ============
>
> `scipy.interpolate` improvements
> --------------------------------
>
> A new class ``CubicHermiteSpline`` is introduced. It is a piecewise-cubic
> interpolator which matches observed values and first derivatives. Existing
> cubic interpolators ``CubicSpline``, ``PchipInterpolator`` and
> ``Akima1DInterpolator`` were made subclasses of ``CubicHermiteSpline``.
>
> `scipy.io` improvements
> -----------------------
>
> For the Attribute-Relation File Format (ARFF) `scipy.io.arff.loadarff`
> now supports relational attributes.
>
> `scipy.io.mmread` can now parse Matrix Market format files with empty lines.
>
> `scipy.linalg` improvements
> ---------------------------
>
> Added wrappers for ``?syconv`` routines, which convert a symmetric matrix
> given by a triangular matrix factorization into two matrices and vice versa.
>
> `scipy.linalg.clarkson_woodruff_transform` now uses an algorithm that leverages
> sparsity. This may provide a 60-90 percent speedup for dense input matrices.
> Truly sparse input matrices should also benefit from the improved sketch
> algorithm, which now correctly runs in ``O(nnz(A))`` time.
>
> Added new functions to calculate symmetric Fiedler matrices and
> Fiedler companion matrices, named `scipy.linalg.fiedler` and
> `scipy.linalg.fiedler_companion`, respectively. These may be used
> for root finding.
>
> `scipy.ndimage` improvements
> ----------------------------
>
> Gaussian filter performances may improve by an order of magnitude in
> some cases, thanks to removal of a dependence on ``np.polynomial``. This
> may impact `scipy.ndimage.gaussian_filter` for example.
>
> `scipy.optimize` improvements
> -----------------------------
>
> The `scipy.optimize.brute` minimizer obtained a new keyword ``workers``, which
> can be used to parallelize computation.
>
> A Cython API for bounded scalar-function root-finders in `scipy.optimize`
> is available in a new module `scipy.optimize.cython_optimize` via ``cimport``.
> This API may be used with ``nogil`` and ``prange`` to loop
> over an array of function arguments to solve for an array of roots more
> quickly than with pure Python.
>
> ``'interior-point'`` is now the default method for ``linprog``, and
> ``'interior-point'`` now uses SuiteSparse for sparse problems when the
> required scikits  (scikit-umfpack and scikit-sparse) are available.
> On benchmark problems (gh-10026), execution time reductions by factors of 2-3
> were typical. Also, a new ``method='revised simplex'`` has been added.
> It is not as fast or robust as ``method='interior-point'``, but it is a faster,
> more robust, and equally accurate substitute for the legacy
> ``method='simplex'``.
>
> ``differential_evolution`` can now use a ``Bounds`` class to specify the
> bounds for the optimizing argument of a function.
>
> `scipy.optimize.dual_annealing` performance improvements related to
> vectorisation of some internal code.
>
> `scipy.signal` improvements
> ---------------------------
>
> Two additional methods of discretization are now supported by
> `scipy.signal.cont2discrete`: ``impulse`` and ``foh``.
>
> `scipy.signal.firls` now uses faster solvers
>
> `scipy.signal.detrend` now has a lower physical memory footprint in some
> cases, which may be leveraged using the new ``overwrite_data`` keyword argument
>
> `scipy.signal.firwin` ``pass_zero`` argument now accepts new string arguments
> that allow specification of the desired filter type: ``'bandpass'``,
> ``'lowpass'``, ``'highpass'``, and ``'bandstop'``
>
> `scipy.signal.sosfilt` may have improved performance due to lower retention
> of the global interpreter lock (GIL) in algorithm
>
> `scipy.sparse` improvements
> ---------------------------
>
> A new keyword was added to ``csgraph.dijsktra`` that
> allows users to query the shortest path to ANY of the passed in indices,
> as opposed to the shortest path to EVERY passed index.
>
> `scipy.sparse.linalg.lsmr` performance has been improved by roughly 10 percent
> on large problems
>
> Improved performance and reduced physical memory footprint of the algorithm
> used by `scipy.sparse.linalg.lobpcg`
>
> ``CSR`` and ``CSC`` sparse matrix fancy indexing performance has been
> improved substantially
>
> `scipy.spatial` improvements
> ----------------------------
>
> `scipy.spatial.ConvexHull` now has a ``good`` attribute that can be used
> alongsize the ``QGn`` Qhull options to determine which external facets of a
> convex hull are visible from an external query point.
>
> `scipy.spatial.cKDTree.query_ball_point` has been modernized to use some newer
> Cython features, including GIL handling and exception translation. An issue
> with ``return_sorted=True`` and scalar queries was fixed, and a new mode named
> ``return_length`` was added. ``return_length`` only computes the length of the
> returned indices list instead of allocating the array every time.
>
> `scipy.spatial.transform.RotationSpline` has been added to enable interpolation
> of rotations with continuous angular rates and acceleration
>
> `scipy.stats` improvements
> --------------------------
>
> Added a new function to compute the Epps-Singleton test statistic,
> `scipy.stats.epps_singleton_2samp`, which can be applied to continuous and
> discrete distributions.
>
> New functions `scipy.stats.median_absolute_deviation` and `scipy.stats.gstd`
> (geometric standard deviation) were added. The `scipy.stats.combine_pvalues`
> method now supports ``pearson``,  ``tippett`` and ``mudholkar_george`` pvalue
> combination methods.
>
> The `scipy.stats.ortho_group` and `scipy.stats.special_ortho_group`
> ``rvs(dim)`` functions' algorithms were updated from a ``O(dim^4)``
> implementation to a ``O(dim^3)`` which gives large speed improvements
> for ``dim>100``.
>
> A rewrite of `scipy.stats.pearsonr` to use a more robust algorithm,
> provide meaningful exceptions and warnings on potentially pathological input,
> and fix at least five separate reported issues in the original implementation.
>
> Improved the precision of ``hypergeom.logcdf`` and ``hypergeom.logsf``.
>
> Added exact computation for Kolmogorov-Smirnov (KS) two-sample test, replacing
> the previously approximate computation for the two-sided test `stats.ks_2samp`.
> Also added a one-sided, two-sample KS test, and a keyword ``alternative`` to
> `stats.ks_2samp`.
>
> Backwards incompatible changes
> ==============================
>
> `scipy.interpolate` changes
> ---------------------------
>
> Functions from ``scipy.interpolate`` (``spleval``, ``spline``, ``splmake``,
> and ``spltopp``) and functions from ``scipy.misc`` (``bytescale``,
> ``fromimage``, ``imfilter``, ``imread``, ``imresize``, ``imrotate``,
> ``imsave``, ``imshow``, ``toimage``) have been removed. The former set has
> been deprecated since v0.19.0 and the latter has been deprecated since v1.0.0.
> Similarly, aliases from ``scipy.misc`` (``comb``, ``factorial``,
> ``factorial2``, ``factorialk``, ``logsumexp``, ``pade``, ``info``, ``source``,
> ``who``) which have been deprecated since v1.0.0 are removed.
> `SciPy documentation for
> v1.1.0 <https://docs.scipy.org/doc/scipy-1.1.0/reference/misc.html>`__
> can be used to track the new import locations for the relocated functions.
>
> `scipy.linalg` changes
> ----------------------
>
> For ``pinv``, ``pinv2``, and ``pinvh``, the default cutoff values are changed
> for consistency (see the docs for the actual values).
>
> `scipy.stats` changes
> ---------------------
>
> Previously, ``ks_2samp(data1, data2)`` would run a two-sided test and return
> the approximated p-value. The new signature, ``ks_2samp(data1, data2,
> alternative="two-sided", method="auto")``, still runs the two-sided test by
> default but returns the exact p-value for small samples and the approximated
> value for large samples. ``method="asymp"`` would be equivalent to the
> old version but ``auto`` is the better choice.
>
> Other changes
> =============
>
> Our tutorial has been expanded with a new section on global optimizers
>
> There has been a rework of the ``stats.distributions`` tutorials.
>
> `scipy.optimize` now correctly sets the convergence flag of the result to
> ``CONVERR``, a convergence error, for bounded scalar-function root-finders
> if the maximum iterations has been exceeded, ``disp`` is false, and
> ``full_output`` is true.
>
> `scipy.optimize.curve_fit` no longer fails if ``xdata`` and ``ydata`` dtypes
> differ; they are both now automatically cast to ``float64``.
>
> `scipy.ndimage` functions including ``binary_erosion``, ``binary_closing``, and
> ``binary_dilation`` now require an integer value for the number of iterations,
> which alleviates a number of reported issues.
>
> Fixed normal approximation in case ``zero_method == "pratt"`` in
> `scipy.stats.wilcoxon`.
>
> Fixes for incorrect probabilities, broadcasting issues and thread-safety
> related to stats distributions setting member variables inside ``_argcheck()``.
>
> `scipy.optimize.newton` now correctly raises a ``RuntimeError``, when default
> arguments are used, in the case that a derivative of value zero is obtained,
> which is a special case of failing to converge.
>
> A draft toolchain roadmap is now available, laying out a compatibility plan
> including Python versions, C standards, and NumPy versions.
>
>
> Authors
> =======
>
> * ananyashreyjain +
> * ApamNapat +
> * Scott Calabrese Barton +
> * Christoph Baumgarten
> * Peter Bell +
> * Jacob Blomgren +
> * Doctor Bob +
> * Mana Borwornpadungkitti +
> * Matthew Brett
> * Evgeni Burovski
> * CJ Carey
> * Vega Theil Carstensen +
> * Robert Cimrman
> * Forrest Collman +
> * Pietro Cottone +
> * David +
> * Idan David +
> * Christoph Deil
> * Dieter Werthm?ller
> * Conner DiPaolo +
> * Dowon
> * Michael Dunphy +
> * Peter Andreas Entschev +
> * G?k?en Eraslan +
> * Johann Faouzi +
> * Yu Feng
> * Piotr Figiel +
> * Matthew H Flamm
> * Franz Forstmayr +
> * Christoph Gohlke
> * Richard Janis Goldschmidt +
> * Ralf Gommers
> * Lars Grueter
> * Sylvain Gubian
> * Matt Haberland
> * Yaroslav Halchenko
> * Charles Harris
> * Lindsey Hiltner
> * JakobStruye +
> * He Jia +
> * Jwink3101 +
> * Greg Kiar +
> * Julius Bier Kirkegaard
> * John Kirkham +
> * Thomas Kluyver
> * Vladimir Korolev +
> * Joseph Kuo +
> * Michael Lamparski +
> * Eric Larson
> * Denis Laxalde
> * Katrin Leinweber
> * Jesse Livezey
> * ludcila +
> * Dhruv Madeka +
> * Magnus +
> * Nikolay Mayorov
> * Mark Mikofski
> * Jarrod Millman
> * Markus Mohrhard +
> * Eric Moore
> * Andrew Nelson
> * Aki Nishimura +
> * OGordon100 +
> * Petar Mlinari? +
> * Stefan Peterson
> * Matti Picus +
> * Ilhan Polat
> * Aaron Pries +
> * Matteo Ravasi +
> * Tyler Reddy
> * Ashton Reimer +
> * Joscha Reimer
> * rfezzani +
> * Riadh +
> * Lucas Roberts
> * Heshy Roskes +
> * Mirko Scholz +
> * Taylor D. Scott +
> * Srikrishna Sekhar +
> * Kevin Sheppard +
> * Sourav Singh
> * skjerns +
> * Kai Striega
> * SyedSaifAliAlvi +
> * Gopi Manohar T +
> * Albert Thomas +
> * Timon +
> * Paul van Mulbregt
> * Jacob Vanderplas
> * Daniel Vargas +
> * Pauli Virtanen
> * VNMabus +
> * Stefan van der Walt
> * Warren Weckesser
> * Josh Wilson
> * Nate Yoder +
> * Roman Yurchak
>
> A total of 97 people contributed to this release.
> People with a "+" by their names contributed a patch for the first time.
> This list of names is automatically generated, and may not be fully complete.
>
> Issues closed for 1.3.0
> -----------------------
>
> * `#1320 <https://github.com/scipy/scipy/issues/1320>`__: scipy.stats.distribution: problem with self.a, self.b if they...
> * `#2002 <https://github.com/scipy/scipy/issues/2002>`__: members set in scipy.stats.distributions.##._argcheck (Trac #1477)
> * `#2823 <https://github.com/scipy/scipy/issues/2823>`__: distribution methods add tmp
> * `#3220 <https://github.com/scipy/scipy/issues/3220>`__: Scipy.opimize.fmin_powell direc argument syntax unclear
> * `#3728 <https://github.com/scipy/scipy/issues/3728>`__: scipy.stats.pearsonr: possible bug with zero variance input
> * `#6805 <https://github.com/scipy/scipy/issues/6805>`__: error-in-scipy-wilcoxon-signed-rank-test-for-equal-series
> * `#6873 <https://github.com/scipy/scipy/issues/6873>`__: 'stats.boxcox' return all same values
> * `#7117 <https://github.com/scipy/scipy/issues/7117>`__: Warn users when using float32 input data to curve_fit and friends
> * `#7632 <https://github.com/scipy/scipy/issues/7632>`__: it's not possible to tell the \`optimize.least_squares\` solver...
> * `#7730 <https://github.com/scipy/scipy/issues/7730>`__: stats.pearsonr: Potential division by zero for dataset of length...
> * `#7933 <https://github.com/scipy/scipy/issues/7933>`__: stats.truncnorm fails when providing values outside truncation...
> * `#8033 <https://github.com/scipy/scipy/issues/8033>`__: Add standard filter types to firwin to set pass_zero intuitively...
> * `#8600 <https://github.com/scipy/scipy/issues/8600>`__: lfilter.c.src zfill has erroneous header
> * `#8692 <https://github.com/scipy/scipy/issues/8692>`__: Non-negative values of \`stats.hypergeom.logcdf\`
> * `#8734 <https://github.com/scipy/scipy/issues/8734>`__: Enable pip build isolation
> * `#8861 <https://github.com/scipy/scipy/issues/8861>`__: scipy.linalg.pinv gives wrong result while scipy.linalg.pinv2...
> * `#8915 <https://github.com/scipy/scipy/issues/8915>`__: need to fix macOS build against older numpy versions
> * `#8980 <https://github.com/scipy/scipy/issues/8980>`__: scipy.stats.pearsonr overflows with high values of x and y
> * `#9226 <https://github.com/scipy/scipy/issues/9226>`__: BUG: signal: SystemError: <built-in function _linear_filter>...
> * `#9254 <https://github.com/scipy/scipy/issues/9254>`__: BUG: root finders brentq, etc, flag says "converged" even if...
> * `#9308 <https://github.com/scipy/scipy/issues/9308>`__: Test failure - test_initial_constraints_as_canonical
> * `#9353 <https://github.com/scipy/scipy/issues/9353>`__: scipy.stats.pearsonr returns r=1 if r_num/r_den = inf
> * `#9359 <https://github.com/scipy/scipy/issues/9359>`__: Planck distribution is a geometric distribution
> * `#9381 <https://github.com/scipy/scipy/issues/9381>`__: linregress should warn user in 2x2 array case
> * `#9406 <https://github.com/scipy/scipy/issues/9406>`__: BUG: stats: In pearsonr, when r is nan, the p-value must also...
> * `#9437 <https://github.com/scipy/scipy/issues/9437>`__: Cannot create sparse matrix from size_t indexes
> * `#9518 <https://github.com/scipy/scipy/issues/9518>`__: Relational attributes in loadarff
> * `#9551 <https://github.com/scipy/scipy/issues/9551>`__: BUG: scipy.optimize.newton says the root of x^2+1 is zero.
> * `#9564 <https://github.com/scipy/scipy/issues/9564>`__: rv_sample accepts invalid input in scipy.stats
> * `#9565 <https://github.com/scipy/scipy/issues/9565>`__: improper handling of multidimensional input in stats.rv_sample
> * `#9581 <https://github.com/scipy/scipy/issues/9581>`__: Least-squares minimization fails silently when x and y data are...
> * `#9587 <https://github.com/scipy/scipy/issues/9587>`__: Outdated value for scipy.constants.au
> * `#9611 <https://github.com/scipy/scipy/issues/9611>`__: Overflow error with new way of p-value calculation in kendall...
> * `#9645 <https://github.com/scipy/scipy/issues/9645>`__: \`scipy.stats.mode\` crashes with variable length arrays (\`dtype=object\`)
> * `#9734 <https://github.com/scipy/scipy/issues/9734>`__: PendingDeprecationWarning for np.matrix with pytest
> * `#9786 <https://github.com/scipy/scipy/issues/9786>`__: stats.ks_2samp() misleading for small data sets.
> * `#9790 <https://github.com/scipy/scipy/issues/9790>`__: Excessive memory usage on detrend
> * `#9801 <https://github.com/scipy/scipy/issues/9801>`__: dual_annealing does not set the success attribute in OptimizeResult
> * `#9833 <https://github.com/scipy/scipy/issues/9833>`__: IntegrationWarning from mielke.stats() during build of html doc.
> * `#9835 <https://github.com/scipy/scipy/issues/9835>`__: scipy.signal.firls seems to be inefficient versus MATLAB firls
> * `#9864 <https://github.com/scipy/scipy/issues/9864>`__: Curve_fit does not check for empty input data if called with...
> * `#9869 <https://github.com/scipy/scipy/issues/9869>`__: scipy.ndimage.label: Minor documentation issue
> * `#9882 <https://github.com/scipy/scipy/issues/9882>`__: format at the wrong paranthesis in scipy.spatial.transform
> * `#9889 <https://github.com/scipy/scipy/issues/9889>`__: scipy.signal.find_peaks minor documentation issue
> * `#9890 <https://github.com/scipy/scipy/issues/9890>`__: Minkowski p-norm Issues in cKDTree For Values Other Than 2 Or...
> * `#9896 <https://github.com/scipy/scipy/issues/9896>`__: scipy.stats._argcheck sets (not just checks) values
> * `#9905 <https://github.com/scipy/scipy/issues/9905>`__: Memory error in ndimage.binary_erosion
> * `#9909 <https://github.com/scipy/scipy/issues/9909>`__: binary_dilation/erosion/closing crashes when iterations is float
> * `#9919 <https://github.com/scipy/scipy/issues/9919>`__: BUG: \`coo_matrix\` does not validate the \`shape\` argument.
> * `#9982 <https://github.com/scipy/scipy/issues/9982>`__: lsq_linear hangs/infinite loop with 'trf' method
> * `#10003 <https://github.com/scipy/scipy/issues/10003>`__: exponnorm.pdf returns NAN for small K
> * `#10011 <https://github.com/scipy/scipy/issues/10011>`__: Incorrect check for invalid rotation plane in scipy.ndimage.rotate
> * `#10024 <https://github.com/scipy/scipy/issues/10024>`__: Fails to build from git
> * `#10048 <https://github.com/scipy/scipy/issues/10048>`__: DOC: scipy.optimize.root_scalar
> * `#10068 <https://github.com/scipy/scipy/issues/10068>`__: DOC: scipy.interpolate.splev
> * `#10074 <https://github.com/scipy/scipy/issues/10074>`__: BUG: \`expm\` calculates the wrong coefficients in the backward...
>
>
> Pull requests for 1.3.0
> -----------------------
>
> * `#7827 <https://github.com/scipy/scipy/pull/7827>`__: ENH: sparse: overhaul of sparse matrix indexing
> * `#8431 <https://github.com/scipy/scipy/pull/8431>`__: ENH: Cython optimize zeros api
> * `#8743 <https://github.com/scipy/scipy/pull/8743>`__: DOC: Updated linalg.pinv, .pinv2, .pinvh docstrings
> * `#8744 <https://github.com/scipy/scipy/pull/8744>`__: DOC: added examples to remez docstring
> * `#9227 <https://github.com/scipy/scipy/pull/9227>`__: DOC: update description of "direc" parameter of "fmin_powell"
> * `#9263 <https://github.com/scipy/scipy/pull/9263>`__: ENH: optimize: added "revised simplex" for scipy.optimize.linprog
> * `#9325 <https://github.com/scipy/scipy/pull/9325>`__: DEP: Remove deprecated functions for 1.3.0
> * `#9330 <https://github.com/scipy/scipy/pull/9330>`__: Add note on push and pull affine transformations
> * `#9423 <https://github.com/scipy/scipy/pull/9423>`__: DOC: Clearly state how 2x2 input arrays are handled in stats.linregress
> * `#9428 <https://github.com/scipy/scipy/pull/9428>`__: ENH: parallelised brute
> * `#9438 <https://github.com/scipy/scipy/pull/9438>`__: BUG: Initialize coo matrix with size_t indexes
> * `#9455 <https://github.com/scipy/scipy/pull/9455>`__: MAINT: Speed up get_(lapack,blas)_func
> * `#9465 <https://github.com/scipy/scipy/pull/9465>`__: MAINT: Clean up optimize.zeros C solvers interfaces/code.
> * `#9477 <https://github.com/scipy/scipy/pull/9477>`__: DOC: linalg: fix lstsq docstring on residues shape
> * `#9478 <https://github.com/scipy/scipy/pull/9478>`__: DOC: Add docstring examples for rosen functions
> * `#9479 <https://github.com/scipy/scipy/pull/9479>`__: DOC: Add docstring example for ai_zeros and bi_zeros
> * `#9480 <https://github.com/scipy/scipy/pull/9480>`__: MAINT: linalg: lstsq clean up
> * `#9489 <https://github.com/scipy/scipy/pull/9489>`__: DOC: roadmap update for changes over the last year.
> * `#9492 <https://github.com/scipy/scipy/pull/9492>`__: MAINT: stats: Improve implementation of chi2 ppf method.
> * `#9497 <https://github.com/scipy/scipy/pull/9497>`__: DOC: Improve docstrings sparse.linalg.isolve
> * `#9499 <https://github.com/scipy/scipy/pull/9499>`__: DOC: Replace "Scipy" with "SciPy" in the .rst doc files for consistency.
> * `#9500 <https://github.com/scipy/scipy/pull/9500>`__: DOC: Document the toolchain and its roadmap.
> * `#9505 <https://github.com/scipy/scipy/pull/9505>`__: DOC: specify which definition of skewness is used
> * `#9511 <https://github.com/scipy/scipy/pull/9511>`__: DEP: interpolate: remove deprecated interpolate_wrapper
> * `#9517 <https://github.com/scipy/scipy/pull/9517>`__: BUG: improve error handling in stats.iqr
> * `#9522 <https://github.com/scipy/scipy/pull/9522>`__: ENH: Add Fiedler and fiedler companion to special matrices
> * `#9526 <https://github.com/scipy/scipy/pull/9526>`__: TST: relax precision requirements in signal.correlate tests
> * `#9529 <https://github.com/scipy/scipy/pull/9529>`__: DOC: fix missing random seed in optimize.newton example
> * `#9533 <https://github.com/scipy/scipy/pull/9533>`__: MAINT: Use list comprehension when possible
> * `#9537 <https://github.com/scipy/scipy/pull/9537>`__: DOC: add a "big picture" roadmap
> * `#9538 <https://github.com/scipy/scipy/pull/9538>`__: DOC: Replace "Numpy" with "NumPy" in .py, .rst and .txt doc files...
> * `#9539 <https://github.com/scipy/scipy/pull/9539>`__: ENH: add two-sample test (Epps-Singleton) to scipy.stats
> * `#9559 <https://github.com/scipy/scipy/pull/9559>`__: DOC: add section on global optimizers to tutorial
> * `#9561 <https://github.com/scipy/scipy/pull/9561>`__: ENH: remove noprefix.h, change code appropriately
> * `#9562 <https://github.com/scipy/scipy/pull/9562>`__: MAINT: stats: Rewrite pearsonr.
> * `#9563 <https://github.com/scipy/scipy/pull/9563>`__: BUG: Minor bug fix Callback in linprog(method='simplex')
> * `#9568 <https://github.com/scipy/scipy/pull/9568>`__: MAINT: raise runtime error for newton with zeroder if disp true,...
> * `#9570 <https://github.com/scipy/scipy/pull/9570>`__: Correct docstring in show_options in optimize. Fixes #9407
> * `#9573 <https://github.com/scipy/scipy/pull/9573>`__: BUG fixes range of pk variable pre-check
> * `#9577 <https://github.com/scipy/scipy/pull/9577>`__: TST: fix minor issue in a signal.stft test.
> * `#9580 <https://github.com/scipy/scipy/pull/9580>`__: Included blank line before list - Fixes #8658
> * `#9582 <https://github.com/scipy/scipy/pull/9582>`__: MAINT: drop Python 2.7 and 3.4
> * `#9588 <https://github.com/scipy/scipy/pull/9588>`__: MAINT: update \`constants.astronomical_unit\` to new 2012 value.
> * `#9592 <https://github.com/scipy/scipy/pull/9592>`__: TST: Add 32-bit testing to CI
> * `#9593 <https://github.com/scipy/scipy/pull/9593>`__: DOC: Replace cumulative density with cumulative distribution
> * `#9596 <https://github.com/scipy/scipy/pull/9596>`__: TST: remove VC 9.0 from Azure CI
> * `#9599 <https://github.com/scipy/scipy/pull/9599>`__: Hyperlink DOI to preferred resolver
> * `#9601 <https://github.com/scipy/scipy/pull/9601>`__: DEV: try to limit GC memory use on PyPy
> * `#9603 <https://github.com/scipy/scipy/pull/9603>`__: MAINT: improve logcdf and logsf of hypergeometric distribution
> * `#9605 <https://github.com/scipy/scipy/pull/9605>`__: Reference to pylops in LinearOperator notes and ARPACK example
> * `#9617 <https://github.com/scipy/scipy/pull/9617>`__: TST: reduce max memory usage for sparse.linalg.lgmres test
> * `#9619 <https://github.com/scipy/scipy/pull/9619>`__: FIX: Sparse matrix addition/subtraction eliminates explicit zeros
> * `#9621 <https://github.com/scipy/scipy/pull/9621>`__: bugfix in rv_sample in scipy.stats
> * `#9622 <https://github.com/scipy/scipy/pull/9622>`__: MAINT: Raise error in directed_hausdorff distance
> * `#9623 <https://github.com/scipy/scipy/pull/9623>`__: DOC: Build docs with warnings as errors
> * `#9625 <https://github.com/scipy/scipy/pull/9625>`__: Return the number of calls to 'hessp' (not just 'hess') in trust...
> * `#9627 <https://github.com/scipy/scipy/pull/9627>`__: BUG: ignore empty lines in mmio
> * `#9637 <https://github.com/scipy/scipy/pull/9637>`__: Function to calculate the MAD of an array
> * `#9646 <https://github.com/scipy/scipy/pull/9646>`__: BUG: stats: mode for objects w/ndim > 1
> * `#9648 <https://github.com/scipy/scipy/pull/9648>`__: Add \`stats.contingency\` to refguide-check
> * `#9650 <https://github.com/scipy/scipy/pull/9650>`__: ENH: many lobpcg() algorithm improvements
> * `#9652 <https://github.com/scipy/scipy/pull/9652>`__: Move misc.doccer to _lib.doccer
> * `#9660 <https://github.com/scipy/scipy/pull/9660>`__: ENH: add pearson, tippett, and mudholkar-george to combine_pvalues
> * `#9661 <https://github.com/scipy/scipy/pull/9661>`__: BUG: Fix ksone right-hand endpoint, documentation and tests.
> * `#9664 <https://github.com/scipy/scipy/pull/9664>`__: ENH: adding multi-target dijsktra performance enhancement
> * `#9670 <https://github.com/scipy/scipy/pull/9670>`__: MAINT: link planck and geometric distribution in scipy.stats
> * `#9676 <https://github.com/scipy/scipy/pull/9676>`__: ENH: optimize: change default linprog method to interior-point
> * `#9685 <https://github.com/scipy/scipy/pull/9685>`__: Added reference to ndimage.filters.median_filter
> * `#9705 <https://github.com/scipy/scipy/pull/9705>`__: Fix coefficients in expm helper function
> * `#9711 <https://github.com/scipy/scipy/pull/9711>`__: Release the GIL during sosfilt processing for simple types
> * `#9721 <https://github.com/scipy/scipy/pull/9721>`__: ENH: Convexhull visiblefacets
> * `#9723 <https://github.com/scipy/scipy/pull/9723>`__: BLD: Modify rv_generic._construct_doc to print out failing distribution...
> * `#9726 <https://github.com/scipy/scipy/pull/9726>`__: BUG: Fix small issues with \`signal.lfilter'
> * `#9729 <https://github.com/scipy/scipy/pull/9729>`__: BUG: Typecheck iterations for binary image operations
> * `#9730 <https://github.com/scipy/scipy/pull/9730>`__: ENH: reduce sizeof(NI_WatershedElement) by 20%
> * `#9731 <https://github.com/scipy/scipy/pull/9731>`__: ENH: remove suspicious sequence of type castings
> * `#9739 <https://github.com/scipy/scipy/pull/9739>`__: BUG: qr_updates fails if u is exactly in span Q
> * `#9749 <https://github.com/scipy/scipy/pull/9749>`__: BUG: MapWrapper.__exit__ should terminate
> * `#9753 <https://github.com/scipy/scipy/pull/9753>`__: ENH: Added exact computation for Kolmogorov-Smirnov two-sample...
> * `#9755 <https://github.com/scipy/scipy/pull/9755>`__: DOC: Added example for signal.impulse, copied from impulse2
> * `#9756 <https://github.com/scipy/scipy/pull/9756>`__: DOC: Added docstring example for iirdesign
> * `#9757 <https://github.com/scipy/scipy/pull/9757>`__: DOC: Added examples for step functions
> * `#9759 <https://github.com/scipy/scipy/pull/9759>`__: ENH: Allow pass_zero to act like btype
> * `#9760 <https://github.com/scipy/scipy/pull/9760>`__: DOC: Added docstring for lp2bs
> * `#9761 <https://github.com/scipy/scipy/pull/9761>`__: DOC: Added docstring and example for lp2bp
> * `#9764 <https://github.com/scipy/scipy/pull/9764>`__: BUG: Catch internal warnings for matrix
> * `#9766 <https://github.com/scipy/scipy/pull/9766>`__: ENH: Speed up _gaussian_kernel1d by removing dependence on np.polynomial
> * `#9769 <https://github.com/scipy/scipy/pull/9769>`__: BUG: Fix Cubic Spline Read Only issues
> * `#9773 <https://github.com/scipy/scipy/pull/9773>`__: DOC: Several docstrings
> * `#9774 <https://github.com/scipy/scipy/pull/9774>`__: TST: bump Azure CI OpenBLAS version to match wheels
> * `#9775 <https://github.com/scipy/scipy/pull/9775>`__: DOC: Improve clarity of cov_x documentation for scipy.optimize.leastsq
> * `#9779 <https://github.com/scipy/scipy/pull/9779>`__: ENH: dual_annealing vectorise visit_fn
> * `#9788 <https://github.com/scipy/scipy/pull/9788>`__: TST, BUG: f2py-related issues with NumPy < 1.14.0
> * `#9791 <https://github.com/scipy/scipy/pull/9791>`__: BUG: fix amax constraint not enforced in scalar_search_wolfe2
> * `#9792 <https://github.com/scipy/scipy/pull/9792>`__: ENH: Allow inplace copying in place in "detrend" function
> * `#9795 <https://github.com/scipy/scipy/pull/9795>`__: DOC: Fix/update docstring for dstn and dst
> * `#9796 <https://github.com/scipy/scipy/pull/9796>`__: MAINT: Allow None tolerances in least_squares
> * `#9798 <https://github.com/scipy/scipy/pull/9798>`__: BUG: fixes abort trap 6 error in scipy issue 9785 in unit tests
> * `#9807 <https://github.com/scipy/scipy/pull/9807>`__: MAINT: improve doc and add alternative keyword to wilcoxon in...
> * `#9808 <https://github.com/scipy/scipy/pull/9808>`__: Fix PPoly integrate and test for CubicSpline
> * `#9810 <https://github.com/scipy/scipy/pull/9810>`__: ENH: Add the geometric standard deviation function
> * `#9811 <https://github.com/scipy/scipy/pull/9811>`__: MAINT: remove invalid derphi default None value in scalar_search_wolfe2
> * `#9813 <https://github.com/scipy/scipy/pull/9813>`__: Adapt hamming distance in C to support weights
> * `#9817 <https://github.com/scipy/scipy/pull/9817>`__: DOC: Copy solver description to solver modules
> * `#9829 <https://github.com/scipy/scipy/pull/9829>`__: ENH: Add FOH and equivalent impulse response discretizations...
> * `#9831 <https://github.com/scipy/scipy/pull/9831>`__: ENH: Implement RotationSpline
> * `#9834 <https://github.com/scipy/scipy/pull/9834>`__: DOC: Change mielke distribution default parameters to ensure...
> * `#9838 <https://github.com/scipy/scipy/pull/9838>`__: ENH: Use faster solvers for firls
> * `#9854 <https://github.com/scipy/scipy/pull/9854>`__: ENH: loadarff now supports relational attributes.
> * `#9856 <https://github.com/scipy/scipy/pull/9856>`__: integrate.bvp - improve handling of nonlinear boundary conditions
> * `#9862 <https://github.com/scipy/scipy/pull/9862>`__: TST: reduce Appveyor CI load
> * `#9874 <https://github.com/scipy/scipy/pull/9874>`__: DOC: Update requirements in release notes
> * `#9883 <https://github.com/scipy/scipy/pull/9883>`__: BUG: fixed parenthesis in spatial.rotation
> * `#9884 <https://github.com/scipy/scipy/pull/9884>`__: ENH: Use Sparsity in Clarkson-Woodruff Sketch
> * `#9888 <https://github.com/scipy/scipy/pull/9888>`__: MAINT: Replace NumPy aliased functions
> * `#9892 <https://github.com/scipy/scipy/pull/9892>`__: BUG: Fix 9890 query_ball_point returns wrong result when p is...
> * `#9893 <https://github.com/scipy/scipy/pull/9893>`__: BUG: curve_fit doesn't check for empty input if called with bounds
> * `#9894 <https://github.com/scipy/scipy/pull/9894>`__: scipy.signal.find_peaks documentation error
> * `#9898 <https://github.com/scipy/scipy/pull/9898>`__: BUG: Set success attribute in OptimizeResult. See #9801
> * `#9900 <https://github.com/scipy/scipy/pull/9900>`__: BUG: Restrict rv_generic._argcheck() and its overrides from setting...
> * `#9906 <https://github.com/scipy/scipy/pull/9906>`__: fixed a bug in kde logpdf
> * `#9911 <https://github.com/scipy/scipy/pull/9911>`__: DOC: replace example for "np.select" with the one from numpy...
> * `#9912 <https://github.com/scipy/scipy/pull/9912>`__: BF(DOC): point to numpy.select instead of plain (python) .select
> * `#9914 <https://github.com/scipy/scipy/pull/9914>`__: DOC: change ValueError message in _validate_pad of signaltools.
> * `#9915 <https://github.com/scipy/scipy/pull/9915>`__: cKDTree query_ball_point improvements
> * `#9918 <https://github.com/scipy/scipy/pull/9918>`__: Update ckdtree.pyx with boxsize argument in docstring
> * `#9920 <https://github.com/scipy/scipy/pull/9920>`__: BUG: sparse: Validate explicit shape if given with dense argument...
> * `#9924 <https://github.com/scipy/scipy/pull/9924>`__: BLD: add back pyproject.toml
> * `#9931 <https://github.com/scipy/scipy/pull/9931>`__: Fix empty constraint
> * `#9935 <https://github.com/scipy/scipy/pull/9935>`__: DOC: fix references for stats.f_oneway
> * `#9936 <https://github.com/scipy/scipy/pull/9936>`__: Revert gh-9619: "FIX: Sparse matrix addition/subtraction eliminates...
> * `#9937 <https://github.com/scipy/scipy/pull/9937>`__: MAINT: fix PEP8 issues and update to pycodestyle 2.5.0
> * `#9939 <https://github.com/scipy/scipy/pull/9939>`__: DOC: correct \`structure\` description in \`ndimage.label\` docstring
> * `#9940 <https://github.com/scipy/scipy/pull/9940>`__: MAINT: remove extraneous distutils copies
> * `#9945 <https://github.com/scipy/scipy/pull/9945>`__: ENH: differential_evolution can use Bounds object
> * `#9949 <https://github.com/scipy/scipy/pull/9949>`__: Added 'std' to add doctstrings since it is a \`known_stats\`...
> * `#9953 <https://github.com/scipy/scipy/pull/9953>`__: DOC: Documentation cleanup for stats tutorials.
> * `#9962 <https://github.com/scipy/scipy/pull/9962>`__: __repr__ for Bounds
> * `#9971 <https://github.com/scipy/scipy/pull/9971>`__: ENH: Improve performance of lsmr
> * `#9987 <https://github.com/scipy/scipy/pull/9987>`__: CI: pin Sphinx version to 1.8.5
> * `#9990 <https://github.com/scipy/scipy/pull/9990>`__: ENH: constraint violation
> * `#9991 <https://github.com/scipy/scipy/pull/9991>`__: BUG: Avoid inplace modification of input array in newton
> * `#9995 <https://github.com/scipy/scipy/pull/9995>`__: MAINT: sparse.csgraph: Add cdef to stop build warning.
> * `#9996 <https://github.com/scipy/scipy/pull/9996>`__: BUG: Make minimize_quadratic_1d work with infinite bounds correctly
> * `#10004 <https://github.com/scipy/scipy/pull/10004>`__: BUG: Fix unbound local error in linprog - simplex.
> * `#10007 <https://github.com/scipy/scipy/pull/10007>`__: BLD: fix Python 3.7 build with build isolation
> * `#10009 <https://github.com/scipy/scipy/pull/10009>`__: BUG: Make sure that _binary_erosion only accepts an integer number...
> * `#10016 <https://github.com/scipy/scipy/pull/10016>`__: Update link to airspeed-velocity
> * `#10017 <https://github.com/scipy/scipy/pull/10017>`__: DOC: Update \`interpolate.LSQSphereBivariateSpline\` to include...
> * `#10018 <https://github.com/scipy/scipy/pull/10018>`__: MAINT: special: Fix a few warnings that occur when compiling...
> * `#10019 <https://github.com/scipy/scipy/pull/10019>`__: TST: Azure summarizes test failures
> * `#10021 <https://github.com/scipy/scipy/pull/10021>`__: ENH: Introduce CubicHermiteSpline
> * `#10022 <https://github.com/scipy/scipy/pull/10022>`__: BENCH: Increase cython version in asv to fix benchmark builds
> * `#10023 <https://github.com/scipy/scipy/pull/10023>`__: BUG: Avoid exponnorm producing nan for small K values.
> * `#10025 <https://github.com/scipy/scipy/pull/10025>`__: BUG: optimize: tweaked linprog status 4 error message
> * `#10026 <https://github.com/scipy/scipy/pull/10026>`__: ENH: optimize: use SuiteSparse in linprog interior-point when...
> * `#10027 <https://github.com/scipy/scipy/pull/10027>`__: MAINT: cluster: clean up the use of malloc() in the function...
> * `#10028 <https://github.com/scipy/scipy/pull/10028>`__: Fix rotate invalid plane check
> * `#10040 <https://github.com/scipy/scipy/pull/10040>`__: MAINT: fix pratt method of wilcox test in scipy.stats
> * `#10041 <https://github.com/scipy/scipy/pull/10041>`__: MAINT: special: Fix a warning generated when building the AMOS...
> * `#10044 <https://github.com/scipy/scipy/pull/10044>`__: DOC: fix up spatial.transform.Rotation docstrings
> * `#10047 <https://github.com/scipy/scipy/pull/10047>`__: MAINT: interpolate: Fix a few build warnings.
> * `#10051 <https://github.com/scipy/scipy/pull/10051>`__: Add project_urls to setup
> * `#10052 <https://github.com/scipy/scipy/pull/10052>`__: don't set flag to "converged" if max iter exceeded
> * `#10054 <https://github.com/scipy/scipy/pull/10054>`__: MAINT: signal: Fix a few build warnings and modernize some C...
> * `#10056 <https://github.com/scipy/scipy/pull/10056>`__: BUG: Ensure factorial is not too large in kendaltau
> * `#10058 <https://github.com/scipy/scipy/pull/10058>`__: Small speedup in samping from ortho and special_ortho groups
> * `#10059 <https://github.com/scipy/scipy/pull/10059>`__: BUG: optimize: fix #10038 by increasing tol
> * `#10061 <https://github.com/scipy/scipy/pull/10061>`__: BLD: DOC: make building docs easier by parsing python version.
> * `#10064 <https://github.com/scipy/scipy/pull/10064>`__: ENH: Significant speedup for ortho and special ortho group
> * `#10065 <https://github.com/scipy/scipy/pull/10065>`__: DOC: Reword parameter descriptions in \`optimize.root_scalar\`
> * `#10066 <https://github.com/scipy/scipy/pull/10066>`__: BUG: signal: Fix error raised by savgol_coeffs when deriv > polyorder.
> * `#10067 <https://github.com/scipy/scipy/pull/10067>`__: MAINT: Fix the cutoff value inconsistency for pinv2 and pinvh
> * `#10072 <https://github.com/scipy/scipy/pull/10072>`__: BUG: stats: Fix boxcox_llf to avoid loss of precision.
> * `#10075 <https://github.com/scipy/scipy/pull/10075>`__: ENH: Add wrappers for ?syconv routines
> * `#10076 <https://github.com/scipy/scipy/pull/10076>`__: BUG: optimize: fix curve_fit for mixed float32/float64 input
> * `#10077 <https://github.com/scipy/scipy/pull/10077>`__: DOC: Replace undefined \`k\` in \`interpolate.splev\` docstring
> * `#10079 <https://github.com/scipy/scipy/pull/10079>`__: DOC: Fixed typo, rearranged some doc of stats.morestats.wilcoxon.
> * `#10080 <https://github.com/scipy/scipy/pull/10080>`__: TST: install scikit-sparse for full TravisCI tests
> * `#10083 <https://github.com/scipy/scipy/pull/10083>`__: Clean \`\`_clean_inputs\`\` in optimize.linprog
> * `#10088 <https://github.com/scipy/scipy/pull/10088>`__: ENH: optimize: linprog test CHOLMOD/UMFPACK solvers when available
> * `#10090 <https://github.com/scipy/scipy/pull/10090>`__: MAINT: Fix CubicSplinerInterpolator for pandas
> * `#10091 <https://github.com/scipy/scipy/pull/10091>`__: MAINT: improve logcdf and logsf of hypergeometric distribution
> * `#10095 <https://github.com/scipy/scipy/pull/10095>`__: MAINT: Clean \`\`_clean_inputs\`\` in linprog
>
> Checksums
> =========
>
> MD5
> ~~~
>
> 5a71a217fa4ff372097f501daf816f3b  scipy-1.3.0rc1-cp35-cp35m-macosx_10_6_intel.macosx_10_9_int
> el.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
> c154ca8eee9ebafe04575b316e41ed85  scipy-1.3.0rc1-cp35-cp35m-manylinux1_i686.whl
> 36a91fa4ae6eeceeb79bf97b9bd013eb  scipy-1.3.0rc1-cp35-cp35m-manylinux1_x86_64.whl
> f1f4259b373332d6edc6bef123b0dc7c  scipy-1.3.0rc1-cp35-cp35m-win32.whl
> c81d78bed8e2176cf0168785b7e1b692  scipy-1.3.0rc1-cp35-cp35m-win_amd64.whl
> c43dd24f349c9d37a6c996e7c0674141  scipy-1.3.0rc1-cp36-cp36m-macosx_10_6_intel.macosx_10_9_int
> el.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
> 8188210e0fd710f4544f314306b76313  scipy-1.3.0rc1-cp36-cp36m-manylinux1_i686.whl
> 0cf317ee185a8f5736b479d1c8b5f415  scipy-1.3.0rc1-cp36-cp36m-manylinux1_x86_64.whl
> e46e5b38288d79321d8d6ffa15a8f54e  scipy-1.3.0rc1-cp36-cp36m-win32.whl
> 85a79e9be408de72056c6efc1eef7d46  scipy-1.3.0rc1-cp36-cp36m-win_amd64.whl
> 2436169658f74e03b4037142e51a8f86  scipy-1.3.0rc1-cp37-cp37m-macosx_10_6_intel.macosx_10_9_int
> el.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
> 1b9e2caa5994ee227b4ad8e46b45ad7e  scipy-1.3.0rc1-cp37-cp37m-manylinux1_i686.whl
> 05a51b40471abdf4e9020183ad449bf2  scipy-1.3.0rc1-cp37-cp37m-manylinux1_x86_64.whl
> debecbc0e54fe4e737971b0a6d9f24f5  scipy-1.3.0rc1-cp37-cp37m-win32.whl
> 79c725144fa59566d8ebd3bf556533aa  scipy-1.3.0rc1-cp37-cp37m-win_amd64.whl
> 0b9fa3583bcf2c8190b277cddb287132  scipy-1.3.0rc1.tar.gz
> d22a40e138ecd6bb26990e22d4a1ac1b  scipy-1.3.0rc1.tar.xz
> 9cc12f26980587900befabafaac2078b  scipy-1.3.0rc1.zip
>
>
> SHA256                                                                                       ~~~~~~                                                                                                                                                                                    3491e5453acec48ff8bc1e96980a9ca225bf653eb8e2fad2efe44ca54fd61230  scipy-1.3.0rc1-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl                                                                                          b04fed432d0d2b7aa52fb83c87390f22e34407baa404385e6c804c6d2f9fe3dc  scipy-1.3.0rc1-cp35-cp35m-manylinux1_i686.whl                                                                           71c236d8b036caa84a018b056c6ced101bcb3efb160fab18957daf5a41c7319c  scipy-1.3.0rc1-cp35-cp35m-manylinux1_x86_64.whl                                                                         6fa6a341ab6920f9233ce5da16572e3e403540f90c17269e27a7a7451e05d40e  scipy-1.3.0rc1-cp35-cp35m-win32.whl                                                                                     7ec09797276d26c74234c056415234a7168e536011767af984b1700410806699  scipy-1.3.0rc1-cp35-cp35m-win_amd64.whl                                                                                 55fcdd1ea9bb3d5461477391d924e24c56c8fa3cb3aba98c2ee2c47e3ccd6ce2  scipy-1.3.0rc1-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl                                                                                          b149d330d0a8219b68d2839cc49a37df163b0ec0b56194f8f0aa6878c1e7c2a4  scipy-1.3.0rc1-cp36-cp36m-manylinux1_i686.whl                                                                           9fed021210077c2e183f621d84bef428762b0b226f8f6da2b03a7d93628e3089  scipy-1.3.0rc1-cp36-cp36m-manylinux1_x86_64.whl                                                                         5c9c9a47e914fbf8edc9a1da1e10a9f5204b3dfc89c93b721b658290884bfe45  scipy-1.3.0rc1-cp36-cp36m-win32.whl                                                                                     09b2c3e099b6274b142e7e05132e79efbbe4daa9dd593a226a3bc9820adf966a  scipy-1.3.0rc1-cp36-cp36m-win_amd64.whl                                                                                 4e93edc6d4c1296ac39ae4be2e8d9336a37a3e5c6e104801a288db0f18d5dbd1  scipy-1.3.0rc1-cp37-cp37m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl                                                                                          1edafef721c859848b8575e7313fba062903f3c256661304f488b96fff4f759d  scipy-1.3.0rc1-cp37-cp37m-manylinux1_i686.whl                                                                           2fe186fff442d3f54f8e6950e809c571ea29db8333ed30608c4074a843d5cdf1  scipy-1.3.0rc1-cp37-cp37m-manylinux1_x86_64.whl                                                                         7c59ec7d5148538978da6c66059c9e3240ae9cf17b803b15354fffc8d3320961  scipy-1.3.0rc1-cp37-cp37m-win32.whl
> 2ab6d6f940b6b09cbee6d7cb2de5914a50f459cbc612b4328b033f67452fd1d6  scipy-1.3.0rc1-cp37-cp37m-win_amd64.whl
> d09e6fae7434aa9e1422d95bbee28f0b66ba97ab770fec24f31c75a873823cd6  scipy-1.3.0rc1.tar.gz
> ba49645a693f6e70e690cf6e2175865b7bf0182cf59bdce872968f47546f4269  scipy-1.3.0rc1.tar.xz
> f1cdb4651f3d150f5c145dc930a627f09aa2afc5275c6c5da97a9a5df274c531  scipy-1.3.0rc1.zip
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQIcBAEBAgAGBQJcw54gAAoJELD/41ZX0J71zbEQAKaapoUb0gbLvljeLL+FZmaZ
> Ha8OecYf7Fsdgj9kiGk2kKgrvz5nkoRyJDpxi4BOzPua+HBUhECoH3DBL5kA6sbv
> VsMAhTb5HFPiKmC78LHEUNSY1fPJrdK7s99pIgedjQFR5diODHqqtB54awbRsTOs
> Vdq45I7JoCd+DUMqQWIA3TZyjrZzw2V1KBFS8mHFdcop71Q1RqRNf3rVw7Rpydob
> uegbae42cJ2Hej4+viU8hsCM+JIgkCuZaQEN2wp4W9pmHsDCzJcoyQjulTjZQAeG
> W3L/F5O1p9A9nHIPk+wvS3D2ageKOhYmVSgB6dznXnFRsjwIKH4O4k0TCzYAamsd
> HvcKnncGAzc+95o2k+v46575O3pBPRYCmOKz6LlFfFGNr/PWkxPYuG49nGIwQZU+
> /w0RYvu2NIPyd05gQQfwyEAATmwbYQfCelbQtHtPehDrtwMINZF4ZCqVg8D7d2ns
> c2mUUC72Iq62R17CdQOjp/zkvU4Xo6KGm0TPQY7xuJwXOaiM5cJ49iY+/Z6eBfBM
> JS0MoIZ8PRzhzQ6gKTPt4exil75ybNpCeL/Ny/LY5dgkfaOdTuplmxwxgngxaECG
> W4SaGw4P0SiATwyz7hMprv/Xkq59iK6IsF6Ki7uxPuMps+nbYhvVIUXqh8Y5iVxx
> piFfF2ct8rgxkVm3qBmN
> =KK2K
> -----END PGP SIGNATURE-----
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190501/79479d7d/attachment-0001.html>

From davidmenhur at gmail.com  Thu May  2 05:02:44 2019
From: davidmenhur at gmail.com (=?UTF-8?B?RGHPgGlk?=)
Date: Thu, 2 May 2019 11:02:44 +0200
Subject: [SciPy-Dev] scipy.org logo original?
In-Reply-To: <CAEBuzr-Ck=AxsuK+TtVAQ+NMjHGje0oxFCjDE8wYK6T9fHVXMQ@mail.gmail.com>
References: <CABL7CQi6FjoR=ekZDd+z7GoWZKJNEr3+Dh3FfTGSTh2CviyNqQ@mail.gmail.com>
 <20190429172600.tykgkl325xdygw74@carbo>
 <20190429174103.7xbkfyndweuv24ts@carbo>
 <CAEBuzr_jC9wnQKiyeojRp3C=ZcLaa9LTDHzwuS7GcitdoTbGdA@mail.gmail.com>
 <CAEBuzr9e32JUCkLii0Gu+B1+exzTsN_RAc9rKJUNn0siZaJfdA@mail.gmail.com>
 <CABL7CQgwo5ewG3g4eJ-oRT6JXb6EAqFGDLcrdXchHxTF0fAbaA@mail.gmail.com>
 <CAEBuzr-Ck=AxsuK+TtVAQ+NMjHGje0oxFCjDE8wYK6T9fHVXMQ@mail.gmail.com>
Message-ID: <CAJhcF=1ri-z78pqNRx09ox+XUFmJufx6gskEP8-Haa64113A4Q@mail.gmail.com>

On Wed, 1 May 2019 at 13:04, Ilhan Polat <ilhanpolat at gmail.com> wrote:

> > Would you be able to make a web-sized image and add it to
> scipy-sphinx-theme?
> Yes that's not a problem thanks to the vector graphics. The main concern
> here is the legibility of the font. I now think that the original font was
> ITC franklin medium though.
>

I can confirm that. Both https://www.myfonts.com/WhatTheFont and
https://www.fontsquirrel.com/matcherator conclude that. They are good
resources to identify fonts. Unfortunately, I don't know of any that can
restrict search to free fonts.


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

From ilhanpolat at gmail.com  Sat May  4 04:24:48 2019
From: ilhanpolat at gmail.com (Ilhan Polat)
Date: Sat, 4 May 2019 10:24:48 +0200
Subject: [SciPy-Dev] scipy.org logo original?
In-Reply-To: <CABL7CQh-Qa7hz9UY_PCJoVdG9VQBdTd0jQOXDrdzD95L+NNUsA@mail.gmail.com>
References: <CABL7CQi6FjoR=ekZDd+z7GoWZKJNEr3+Dh3FfTGSTh2CviyNqQ@mail.gmail.com>
 <20190429172600.tykgkl325xdygw74@carbo>
 <20190429174103.7xbkfyndweuv24ts@carbo>
 <CAEBuzr_jC9wnQKiyeojRp3C=ZcLaa9LTDHzwuS7GcitdoTbGdA@mail.gmail.com>
 <CAEBuzr9e32JUCkLii0Gu+B1+exzTsN_RAc9rKJUNn0siZaJfdA@mail.gmail.com>
 <CABL7CQgwo5ewG3g4eJ-oRT6JXb6EAqFGDLcrdXchHxTF0fAbaA@mail.gmail.com>
 <CAEBuzr-Ck=AxsuK+TtVAQ+NMjHGje0oxFCjDE8wYK6T9fHVXMQ@mail.gmail.com>
 <CAKkGBSYJ1a5vQym5Hh375jfgG+6FqcefNSMuFkEghZxSCw6LXQ@mail.gmail.com>
 <CABL7CQh-Qa7hz9UY_PCJoVdG9VQBdTd0jQOXDrdzD95L+NNUsA@mail.gmail.com>
Message-ID: <CAEBuzr_crXgp+zV1SxfpphtQunGUCdOcU5wa1G_+o=izK_Ynvw@mail.gmail.com>

OK, before I go pixel frenzy, I'd like to ask if the following is
acceptable until we perform a substantial overhaul. This is the current
logo

[image: image.png]

Keeping Christina's .org remark in mind, I've selected a sane approximation
to our current setup and used the open source (SIL OFL 1.1) font Inter
https://rsms.me/inter/ and the semibold weight variant of it. It has a
really nice x-height hence still legible in small sizes. Also as you can
see it does not suffer from the kerning issues we now have. You can also
notice that the Logo snake has a bit less hand-drawnness to it.

[image: image.png]

It's the 3.4 kb version but can be reduced/optimized further. This mail is
just for to get feedback. Here is the draft code in case you want to play
around with it
https://gist.github.com/ilayn/d121ec7deb009a9a257b4813c80dff27 just install
the fonts and run it via Xe- or Lua-LaTeX.

Please let me know if there are any
objections/corrections/suggestions/design crimes I might have committed.

Best,
ilhan


On Wed, May 1, 2019 at 3:34 PM Ralf Gommers <ralf.gommers at gmail.com> wrote:

>
>
> On Wed, May 1, 2019 at 2:50 PM Christina Lee <chrissie.c.l at gmail.com>
> wrote:
>
>> Quick question, why does it include ".org"?   Can't the logo just say
>> "SciPy"?
>>
>
> Thanks Christina, that's a great question. I can't think of a reason, just
> "SciPy" seems better. Perhaps we've been staring at it for so long that
> it's not noticeable anymore. Let's change it now.
>
>
>> A good rule of websites is to use svg whenever reasonable.  The main logo
>> isn't the only image where doing this could bump up cleanliness.  Several
>> other logos on the main page could also use an update.  For example, just
>> traced over the download graphic as attached. No more resolution problems,
>> and smaller.
>>
>
> That's great, thank you! Yes, you're right ... and it's not just the logos
> that could use a makeover, the whole site needs attention.
>
> Cheers,
> Ralf
>
>
>>
>> On Wed, May 1, 2019 at 12:05 PM Ilhan Polat <ilhanpolat at gmail.com> wrote:
>>
>>> > Would you be able to make a web-sized image and add it to
>>> scipy-sphinx-theme?
>>> Yes that's not a problem thanks to the vector graphics. The main concern
>>> here is the legibility of the font. I now think that the original font was
>>> ITC franklin medium though.
>>>
>>> Anyways, I have searched for some open source fonts in the meantime and
>>> many curation pages are available online; to give two results from a quick
>>> Google search
>>>
>>>
>>> https://medium.com/sketch-app-sources/30-free-and-open-source-typefaces-released-recently-best-collections-5b46f9d89f65
>>>
>>> https://www.forbes.com/sites/allbusiness/2014/03/06/10-best-sans-serif-web-fonts-from-google-fonts-library/#21da8027431b
>>>
>>> I am no designer by any means hence take these as availability stats but
>>> we might be better off if we switch to a font with suitable license in
>>> place for a commercial font. Also all feedback and help are welcome.
>>>
>>> Best,
>>>
>>>
>>>
>>> On Tue, Apr 30, 2019 at 3:10 PM Ralf Gommers <ralf.gommers at gmail.com>
>>> wrote:
>>>
>>>> Thanks Stefan & Ilhan!
>>>>
>>>> Scikit-image has the right idea I think with a separate branding repo.
>>>> Shall we create one for SciPy as well?
>>>>
>>>> Ilhan, that looks really good! Would you be able to make a web-sized
>>>> image and add it to scipy-sphinx-theme? The current image is a 2.4kb gif, I
>>>> think it can be larger but as small as possible while still looking good
>>>> would be nice. Because it gets downloaded millions of times a month, and
>>>> also directly adds to the size of the numpy and scipy sdists.
>>>>
>>>> Cheers,
>>>> Ralf
>>>>
>>>>
>>>> On Mon, Apr 29, 2019 at 10:44 PM Ilhan Polat <ilhanpolat at gmail.com>
>>>> wrote:
>>>>
>>>>> By the way does anyone know what the font logo is? Just by eyeballing
>>>>> it looks like Franklin Gothic but I am not sure. However, if there is a
>>>>> more able typography connoisseur among us, here is the logo ready to be
>>>>> compiled by Xe/LuaLatex.
>>>>>
>>>>> \documentclass[tikz]{standalone}
>>>>> \usepackage{fontspec}
>>>>> \setsansfont{Franklin Gothic Medium}
>>>>> \usetikzlibrary{svg.path}
>>>>> \definecolor{scipylogo}{HTML}{8CAAE6}
>>>>>
>>>>> \begin{document}
>>>>> \begin{tikzpicture}[x=1pt, y=-1pt]
>>>>>
>>>>> \fill[scipylogo] (-50,-75) rectangle (1825, 575)
>>>>> svg[yscale=-1] {
>>>>> M348.369,282.469c-17.398-23.797-43.984-33.719-81.984-41.719
>>>>>
>>>>> l-35.334-8.332l-26.656-11.432c-14.01-9.902-25.947-36.26-22.559-59.502c5.264-36.006,38.896-61.104,75.127-56.045
>>>>>
>>>>> c18.094,2.559,33.438,12.139,43.555,25.625l40.117,52.705c22.93,29.531,48.711,38.32,76.758,24.375l14.141-6.016
>>>>>
>>>>> c1.133-0.527,2.461-0.576,3.75-0.107c1.055,0.41,1.914,1.162,2.422,2.051l2.813,4.238c0.781,1.279,1.953,2.314,3.477,2.891
>>>>>
>>>>> c2.578,0.977,5.352,0.391,7.305-1.289l32.578-30.723c5.703-4.883,4.023-9.365,4.023-9.365l-7.852-17.881
>>>>>
>>>>> c0,0-2.148-4.287-9.57-3.301l-43.672,4.014c-2.539,0.361-4.805,2.051-5.781,4.629c-0.586,1.504-0.625,3.076-0.195,4.502
>>>>>
>>>>> l1.563,5.029c0.313,1.045,0.313,2.217-0.117,3.291c-0.508,1.328-1.523,2.266-2.734,2.764l-12.344,5.225
>>>>>
>>>>> c-12.93,7.568-27.617,2.734-37.422-9.258l-11.211-14.893l-31.914-42.354c-15.156-20.098-38.008-34.434-65-38.203
>>>>>
>>>>> c-54.043-7.568-104.199,29.854-112.051,83.584c-3.965,27.08,4.152,52.703,18.965,73.281
>>>>>
>>>>> c10.762,14.953,30.486,23.496,41.154,26.164l28,8l26.814,6.145c3.688,0.875,14.063,3.438,20.203,5.656
>>>>>
>>>>> c5.676,2.055,18.75,6.875,29.375,15.57l0,0c12.695,12.906,19.414,31.344,16.563,50.68c-4.805,32.969-35.586,55.938-68.75,51.289
>>>>>
>>>>> c-16.611-2.305-30.635-11.109-39.922-23.438l-38.32-50.859c-7.813-10.367-19.629-17.773-33.594-19.766
>>>>>
>>>>> c-13.945-1.953-27.441,1.914-37.9,9.75l-80.615,60.156C11.455,333.914,0,292.898,0,249.266C0,111.621,113.926,0,254.443,0
>>>>>
>>>>> c104.629,0,194.434,61.855,233.535,150.254l12.891-5.996l8.711-23.809l9.141,3.203l-7.852,21.289l21.758,7.5l-3.281,8.916
>>>>>
>>>>> l-24.297-8.486l-13.398,6.162c11.094,27.998,17.266,58.398,17.266,90.232c0,137.656-113.945,249.258-254.473,249.258
>>>>>
>>>>> c-84.414,0-159.229-40.289-205.508-102.281l82.578-61.898c3.779-2.578,8.467-3.75,13.33-3.086
>>>>>
>>>>> c5.176,0.742,9.58,3.461,12.471,7.305l40.537,54.477c14.277,17.516,35.02,29.922,59.307,33.336
>>>>>
>>>>> c51.094,7.148,98.516-28.242,105.938-79.063C366.533,323.664,360.752,300.828,348.369,282.469};
>>>>>
>>>>> \node[anchor=east,
>>>>>       text=white,
>>>>>       font=\sffamily,
>>>>>       scale=30,
>>>>>       outer sep=0pt,
>>>>>       inner sep=0pt] (scipyorg) at (1750,250) {SciPy.org};
>>>>> \end{tikzpicture}
>>>>> \end{document}
>>>>>
>>>>> This code gives on my system
>>>>>
>>>>> [image: image.png]
>>>>>
>>>>> "i" and "P" needs a slight nudge to each other but that means the font
>>>>> is correct. Hence my question. Also you can play around and enjoy some TeX
>>>>> kerning/positioning/scaling bonanza yourself. I'll let Ralf to be the judge
>>>>> :)
>>>>>
>>>>> Best,
>>>>> ilhan
>>>>>
>>>>> On Mon, Apr 29, 2019 at 8:09 PM Ilhan Polat <ilhanpolat at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Perfect! Thanks.
>>>>>>
>>>>>> On Mon, Apr 29, 2019 at 7:44 PM Stefan van der Walt <
>>>>>> stefanv at berkeley.edu> wrote:
>>>>>>
>>>>>>> Found it and uploaded to GitHub:
>>>>>>>
>>>>>>>
>>>>>>> https://github.com/scikit-image/skimage-branding/blob/master/logo/scipy.svg
>>>>>>>
>>>>>>> On Mon, 29 Apr 2019 10:26:00 -0700, Stefan van der Walt wrote:
>>>>>>> > On Sat, 27 Apr 2019 23:49:03 +0200, Ralf Gommers wrote:
>>>>>>> > > Does anyone have the original files from which the current logo
>>>>>>> on scipy.org
>>>>>>> > > (it has the scipy symbol, white letter scipy.org and "sponsored
>>>>>>> by
>>>>>>> > > Enthough") was created? The quality is not great, and editing a
>>>>>>> tiny gif
>>>>>>> > > doesn't make it better ....
>>>>>>> >
>>>>>>> > I don't have the vector art, but I have a higher resolution render:
>>>>>>> >
>>>>>>> https://github.com/scikit-image/skimage-branding/blob/master/logo/data/scipy.png
>>>>>>> >
>>>>>>> > St?fan
>>>>>>> _______________________________________________
>>>>>>> SciPy-Dev mailing list
>>>>>>> SciPy-Dev at python.org
>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>
>>>>>> _______________________________________________
>>>>> SciPy-Dev mailing list
>>>>> SciPy-Dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at python.org
>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190504/512a19cc/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 32300 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190504/512a19cc/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 3475 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190504/512a19cc/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 2590 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190504/512a19cc/attachment-0005.png>

From ralf.gommers at gmail.com  Sat May  4 05:07:56 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sat, 4 May 2019 11:07:56 +0200
Subject: [SciPy-Dev] scipy.org logo original?
In-Reply-To: <CAEBuzr_crXgp+zV1SxfpphtQunGUCdOcU5wa1G_+o=izK_Ynvw@mail.gmail.com>
References: <CABL7CQi6FjoR=ekZDd+z7GoWZKJNEr3+Dh3FfTGSTh2CviyNqQ@mail.gmail.com>
 <20190429172600.tykgkl325xdygw74@carbo>
 <20190429174103.7xbkfyndweuv24ts@carbo>
 <CAEBuzr_jC9wnQKiyeojRp3C=ZcLaa9LTDHzwuS7GcitdoTbGdA@mail.gmail.com>
 <CAEBuzr9e32JUCkLii0Gu+B1+exzTsN_RAc9rKJUNn0siZaJfdA@mail.gmail.com>
 <CABL7CQgwo5ewG3g4eJ-oRT6JXb6EAqFGDLcrdXchHxTF0fAbaA@mail.gmail.com>
 <CAEBuzr-Ck=AxsuK+TtVAQ+NMjHGje0oxFCjDE8wYK6T9fHVXMQ@mail.gmail.com>
 <CAKkGBSYJ1a5vQym5Hh375jfgG+6FqcefNSMuFkEghZxSCw6LXQ@mail.gmail.com>
 <CABL7CQh-Qa7hz9UY_PCJoVdG9VQBdTd0jQOXDrdzD95L+NNUsA@mail.gmail.com>
 <CAEBuzr_crXgp+zV1SxfpphtQunGUCdOcU5wa1G_+o=izK_Ynvw@mail.gmail.com>
Message-ID: <CABL7CQjUrgk8j-1r+B0m+_58jpVhLrg5c7EdhWLwEwONdJQ3nA@mail.gmail.com>

On Sat, May 4, 2019 at 10:25 AM Ilhan Polat <ilhanpolat at gmail.com> wrote:

> OK, before I go pixel frenzy, I'd like to ask if the following is
> acceptable until we perform a substantial overhaul. This is the current
> logo
>
> [image: image.png]
>
> Keeping Christina's .org remark in mind, I've selected a sane
> approximation to our current setup and used the open source (SIL OFL 1.1)
> font Inter https://rsms.me/inter/ and the semibold weight variant of it.
> It has a really nice x-height hence still legible in small sizes. Also as
> you can see it does not suffer from the kerning issues we now have. You can
> also notice that the Logo snake has a bit less hand-drawnness to it.
>
> [image: image.png]
>
> It's the 3.4 kb version but can be reduced/optimized further. This mail is
> just for to get feedback. Here is the draft code in case you want to play
> around with it
> https://gist.github.com/ilayn/d121ec7deb009a9a257b4813c80dff27 just
> install the fonts and run it via Xe- or Lua-LaTeX.
>
> Please let me know if there are any
> objections/corrections/suggestions/design crimes I might have committed.
>

Looks great, thanks for working on this! The one change I notice that may
be a regression is how thin the snake is. A line width closer to the
original may work a little better perhaps.

Cheers,
Ralf




> Best,
> ilhan
>
>
> On Wed, May 1, 2019 at 3:34 PM Ralf Gommers <ralf.gommers at gmail.com>
> wrote:
>
>>
>>
>> On Wed, May 1, 2019 at 2:50 PM Christina Lee <chrissie.c.l at gmail.com>
>> wrote:
>>
>>> Quick question, why does it include ".org"?   Can't the logo just say
>>> "SciPy"?
>>>
>>
>> Thanks Christina, that's a great question. I can't think of a reason,
>> just "SciPy" seems better. Perhaps we've been staring at it for so long
>> that it's not noticeable anymore. Let's change it now.
>>
>>
>>> A good rule of websites is to use svg whenever reasonable.  The main
>>> logo isn't the only image where doing this could bump up cleanliness.
>>> Several other logos on the main page could also use an update.  For
>>> example, just traced over the download graphic as attached. No more
>>> resolution problems, and smaller.
>>>
>>
>> That's great, thank you! Yes, you're right ... and it's not just the
>> logos that could use a makeover, the whole site needs attention.
>>
>> Cheers,
>> Ralf
>>
>>
>>>
>>> On Wed, May 1, 2019 at 12:05 PM Ilhan Polat <ilhanpolat at gmail.com>
>>> wrote:
>>>
>>>> > Would you be able to make a web-sized image and add it to
>>>> scipy-sphinx-theme?
>>>> Yes that's not a problem thanks to the vector graphics. The main
>>>> concern here is the legibility of the font. I now think that the original
>>>> font was ITC franklin medium though.
>>>>
>>>> Anyways, I have searched for some open source fonts in the meantime and
>>>> many curation pages are available online; to give two results from a quick
>>>> Google search
>>>>
>>>>
>>>> https://medium.com/sketch-app-sources/30-free-and-open-source-typefaces-released-recently-best-collections-5b46f9d89f65
>>>>
>>>> https://www.forbes.com/sites/allbusiness/2014/03/06/10-best-sans-serif-web-fonts-from-google-fonts-library/#21da8027431b
>>>>
>>>> I am no designer by any means hence take these as availability stats
>>>> but we might be better off if we switch to a font with suitable license in
>>>> place for a commercial font. Also all feedback and help are welcome.
>>>>
>>>> Best,
>>>>
>>>>
>>>>
>>>> On Tue, Apr 30, 2019 at 3:10 PM Ralf Gommers <ralf.gommers at gmail.com>
>>>> wrote:
>>>>
>>>>> Thanks Stefan & Ilhan!
>>>>>
>>>>> Scikit-image has the right idea I think with a separate branding repo.
>>>>> Shall we create one for SciPy as well?
>>>>>
>>>>> Ilhan, that looks really good! Would you be able to make a web-sized
>>>>> image and add it to scipy-sphinx-theme? The current image is a 2.4kb gif, I
>>>>> think it can be larger but as small as possible while still looking good
>>>>> would be nice. Because it gets downloaded millions of times a month, and
>>>>> also directly adds to the size of the numpy and scipy sdists.
>>>>>
>>>>> Cheers,
>>>>> Ralf
>>>>>
>>>>>
>>>>> On Mon, Apr 29, 2019 at 10:44 PM Ilhan Polat <ilhanpolat at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> By the way does anyone know what the font logo is? Just by eyeballing
>>>>>> it looks like Franklin Gothic but I am not sure. However, if there is a
>>>>>> more able typography connoisseur among us, here is the logo ready to be
>>>>>> compiled by Xe/LuaLatex.
>>>>>>
>>>>>> \documentclass[tikz]{standalone}
>>>>>> \usepackage{fontspec}
>>>>>> \setsansfont{Franklin Gothic Medium}
>>>>>> \usetikzlibrary{svg.path}
>>>>>> \definecolor{scipylogo}{HTML}{8CAAE6}
>>>>>>
>>>>>> \begin{document}
>>>>>> \begin{tikzpicture}[x=1pt, y=-1pt]
>>>>>>
>>>>>> \fill[scipylogo] (-50,-75) rectangle (1825, 575)
>>>>>> svg[yscale=-1] {
>>>>>> M348.369,282.469c-17.398-23.797-43.984-33.719-81.984-41.719
>>>>>>
>>>>>> l-35.334-8.332l-26.656-11.432c-14.01-9.902-25.947-36.26-22.559-59.502c5.264-36.006,38.896-61.104,75.127-56.045
>>>>>>
>>>>>> c18.094,2.559,33.438,12.139,43.555,25.625l40.117,52.705c22.93,29.531,48.711,38.32,76.758,24.375l14.141-6.016
>>>>>>
>>>>>> c1.133-0.527,2.461-0.576,3.75-0.107c1.055,0.41,1.914,1.162,2.422,2.051l2.813,4.238c0.781,1.279,1.953,2.314,3.477,2.891
>>>>>>
>>>>>> c2.578,0.977,5.352,0.391,7.305-1.289l32.578-30.723c5.703-4.883,4.023-9.365,4.023-9.365l-7.852-17.881
>>>>>>
>>>>>> c0,0-2.148-4.287-9.57-3.301l-43.672,4.014c-2.539,0.361-4.805,2.051-5.781,4.629c-0.586,1.504-0.625,3.076-0.195,4.502
>>>>>>
>>>>>> l1.563,5.029c0.313,1.045,0.313,2.217-0.117,3.291c-0.508,1.328-1.523,2.266-2.734,2.764l-12.344,5.225
>>>>>>
>>>>>> c-12.93,7.568-27.617,2.734-37.422-9.258l-11.211-14.893l-31.914-42.354c-15.156-20.098-38.008-34.434-65-38.203
>>>>>>
>>>>>> c-54.043-7.568-104.199,29.854-112.051,83.584c-3.965,27.08,4.152,52.703,18.965,73.281
>>>>>>
>>>>>> c10.762,14.953,30.486,23.496,41.154,26.164l28,8l26.814,6.145c3.688,0.875,14.063,3.438,20.203,5.656
>>>>>>
>>>>>> c5.676,2.055,18.75,6.875,29.375,15.57l0,0c12.695,12.906,19.414,31.344,16.563,50.68c-4.805,32.969-35.586,55.938-68.75,51.289
>>>>>>
>>>>>> c-16.611-2.305-30.635-11.109-39.922-23.438l-38.32-50.859c-7.813-10.367-19.629-17.773-33.594-19.766
>>>>>>
>>>>>> c-13.945-1.953-27.441,1.914-37.9,9.75l-80.615,60.156C11.455,333.914,0,292.898,0,249.266C0,111.621,113.926,0,254.443,0
>>>>>>
>>>>>> c104.629,0,194.434,61.855,233.535,150.254l12.891-5.996l8.711-23.809l9.141,3.203l-7.852,21.289l21.758,7.5l-3.281,8.916
>>>>>>
>>>>>> l-24.297-8.486l-13.398,6.162c11.094,27.998,17.266,58.398,17.266,90.232c0,137.656-113.945,249.258-254.473,249.258
>>>>>>
>>>>>> c-84.414,0-159.229-40.289-205.508-102.281l82.578-61.898c3.779-2.578,8.467-3.75,13.33-3.086
>>>>>>
>>>>>> c5.176,0.742,9.58,3.461,12.471,7.305l40.537,54.477c14.277,17.516,35.02,29.922,59.307,33.336
>>>>>>
>>>>>> c51.094,7.148,98.516-28.242,105.938-79.063C366.533,323.664,360.752,300.828,348.369,282.469};
>>>>>>
>>>>>> \node[anchor=east,
>>>>>>       text=white,
>>>>>>       font=\sffamily,
>>>>>>       scale=30,
>>>>>>       outer sep=0pt,
>>>>>>       inner sep=0pt] (scipyorg) at (1750,250) {SciPy.org};
>>>>>> \end{tikzpicture}
>>>>>> \end{document}
>>>>>>
>>>>>> This code gives on my system
>>>>>>
>>>>>> [image: image.png]
>>>>>>
>>>>>> "i" and "P" needs a slight nudge to each other but that means the
>>>>>> font is correct. Hence my question. Also you can play around and enjoy some
>>>>>> TeX kerning/positioning/scaling bonanza yourself. I'll let Ralf to be the
>>>>>> judge :)
>>>>>>
>>>>>> Best,
>>>>>> ilhan
>>>>>>
>>>>>> On Mon, Apr 29, 2019 at 8:09 PM Ilhan Polat <ilhanpolat at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Perfect! Thanks.
>>>>>>>
>>>>>>> On Mon, Apr 29, 2019 at 7:44 PM Stefan van der Walt <
>>>>>>> stefanv at berkeley.edu> wrote:
>>>>>>>
>>>>>>>> Found it and uploaded to GitHub:
>>>>>>>>
>>>>>>>>
>>>>>>>> https://github.com/scikit-image/skimage-branding/blob/master/logo/scipy.svg
>>>>>>>>
>>>>>>>> On Mon, 29 Apr 2019 10:26:00 -0700, Stefan van der Walt wrote:
>>>>>>>> > On Sat, 27 Apr 2019 23:49:03 +0200, Ralf Gommers wrote:
>>>>>>>> > > Does anyone have the original files from which the current logo
>>>>>>>> on scipy.org
>>>>>>>> > > (it has the scipy symbol, white letter scipy.org and
>>>>>>>> "sponsored by
>>>>>>>> > > Enthough") was created? The quality is not great, and editing a
>>>>>>>> tiny gif
>>>>>>>> > > doesn't make it better ....
>>>>>>>> >
>>>>>>>> > I don't have the vector art, but I have a higher resolution
>>>>>>>> render:
>>>>>>>> >
>>>>>>>> https://github.com/scikit-image/skimage-branding/blob/master/logo/data/scipy.png
>>>>>>>> >
>>>>>>>> > St?fan
>>>>>>>> _______________________________________________
>>>>>>>> SciPy-Dev mailing list
>>>>>>>> SciPy-Dev at python.org
>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>> SciPy-Dev mailing list
>>>>>> SciPy-Dev at python.org
>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>
>>>>> _______________________________________________
>>>>> SciPy-Dev mailing list
>>>>> SciPy-Dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at python.org
>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190504/80544898/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 32300 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190504/80544898/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 3475 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190504/80544898/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 2590 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190504/80544898/attachment-0005.png>

From ilhanpolat at gmail.com  Sat May  4 06:00:01 2019
From: ilhanpolat at gmail.com (Ilhan Polat)
Date: Sat, 4 May 2019 12:00:01 +0200
Subject: [SciPy-Dev] scipy.org logo original?
In-Reply-To: <CABL7CQjUrgk8j-1r+B0m+_58jpVhLrg5c7EdhWLwEwONdJQ3nA@mail.gmail.com>
References: <CABL7CQi6FjoR=ekZDd+z7GoWZKJNEr3+Dh3FfTGSTh2CviyNqQ@mail.gmail.com>
 <20190429172600.tykgkl325xdygw74@carbo>
 <20190429174103.7xbkfyndweuv24ts@carbo>
 <CAEBuzr_jC9wnQKiyeojRp3C=ZcLaa9LTDHzwuS7GcitdoTbGdA@mail.gmail.com>
 <CAEBuzr9e32JUCkLii0Gu+B1+exzTsN_RAc9rKJUNn0siZaJfdA@mail.gmail.com>
 <CABL7CQgwo5ewG3g4eJ-oRT6JXb6EAqFGDLcrdXchHxTF0fAbaA@mail.gmail.com>
 <CAEBuzr-Ck=AxsuK+TtVAQ+NMjHGje0oxFCjDE8wYK6T9fHVXMQ@mail.gmail.com>
 <CAKkGBSYJ1a5vQym5Hh375jfgG+6FqcefNSMuFkEghZxSCw6LXQ@mail.gmail.com>
 <CABL7CQh-Qa7hz9UY_PCJoVdG9VQBdTd0jQOXDrdzD95L+NNUsA@mail.gmail.com>
 <CAEBuzr_crXgp+zV1SxfpphtQunGUCdOcU5wa1G_+o=izK_Ynvw@mail.gmail.com>
 <CABL7CQjUrgk8j-1r+B0m+_58jpVhLrg5c7EdhWLwEwONdJQ3nA@mail.gmail.com>
Message-ID: <CAEBuzr-_45=YY81BqjoOk7341sCLxKVuvXuCh5EhtOoQ2qFt8w@mail.gmail.com>

Indeed I noticed that too but it seems like the original logo that Stefan
linked to is also thin. So there is an alternative somewhere I guess. But
I'll try to modify the curve coordinates to make it slightly thicker.

On Sat, May 4, 2019 at 11:09 AM Ralf Gommers <ralf.gommers at gmail.com> wrote:

>
>
> On Sat, May 4, 2019 at 10:25 AM Ilhan Polat <ilhanpolat at gmail.com> wrote:
>
>> OK, before I go pixel frenzy, I'd like to ask if the following is
>> acceptable until we perform a substantial overhaul. This is the current
>> logo
>>
>> [image: image.png]
>>
>> Keeping Christina's .org remark in mind, I've selected a sane
>> approximation to our current setup and used the open source (SIL OFL 1.1)
>> font Inter https://rsms.me/inter/ and the semibold weight variant of it.
>> It has a really nice x-height hence still legible in small sizes. Also as
>> you can see it does not suffer from the kerning issues we now have. You can
>> also notice that the Logo snake has a bit less hand-drawnness to it.
>>
>> [image: image.png]
>>
>> It's the 3.4 kb version but can be reduced/optimized further. This mail
>> is just for to get feedback. Here is the draft code in case you want to
>> play around with it
>> https://gist.github.com/ilayn/d121ec7deb009a9a257b4813c80dff27 just
>> install the fonts and run it via Xe- or Lua-LaTeX.
>>
>> Please let me know if there are any
>> objections/corrections/suggestions/design crimes I might have committed.
>>
>
> Looks great, thanks for working on this! The one change I notice that may
> be a regression is how thin the snake is. A line width closer to the
> original may work a little better perhaps.
>
> Cheers,
> Ralf
>
>
>
>
>> Best,
>> ilhan
>>
>>
>> On Wed, May 1, 2019 at 3:34 PM Ralf Gommers <ralf.gommers at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Wed, May 1, 2019 at 2:50 PM Christina Lee <chrissie.c.l at gmail.com>
>>> wrote:
>>>
>>>> Quick question, why does it include ".org"?   Can't the logo just say
>>>> "SciPy"?
>>>>
>>>
>>> Thanks Christina, that's a great question. I can't think of a reason,
>>> just "SciPy" seems better. Perhaps we've been staring at it for so long
>>> that it's not noticeable anymore. Let's change it now.
>>>
>>>
>>>> A good rule of websites is to use svg whenever reasonable.  The main
>>>> logo isn't the only image where doing this could bump up cleanliness.
>>>> Several other logos on the main page could also use an update.  For
>>>> example, just traced over the download graphic as attached. No more
>>>> resolution problems, and smaller.
>>>>
>>>
>>> That's great, thank you! Yes, you're right ... and it's not just the
>>> logos that could use a makeover, the whole site needs attention.
>>>
>>> Cheers,
>>> Ralf
>>>
>>>
>>>>
>>>> On Wed, May 1, 2019 at 12:05 PM Ilhan Polat <ilhanpolat at gmail.com>
>>>> wrote:
>>>>
>>>>> > Would you be able to make a web-sized image and add it to
>>>>> scipy-sphinx-theme?
>>>>> Yes that's not a problem thanks to the vector graphics. The main
>>>>> concern here is the legibility of the font. I now think that the original
>>>>> font was ITC franklin medium though.
>>>>>
>>>>> Anyways, I have searched for some open source fonts in the meantime
>>>>> and many curation pages are available online; to give two results from a
>>>>> quick Google search
>>>>>
>>>>>
>>>>> https://medium.com/sketch-app-sources/30-free-and-open-source-typefaces-released-recently-best-collections-5b46f9d89f65
>>>>>
>>>>> https://www.forbes.com/sites/allbusiness/2014/03/06/10-best-sans-serif-web-fonts-from-google-fonts-library/#21da8027431b
>>>>>
>>>>> I am no designer by any means hence take these as availability stats
>>>>> but we might be better off if we switch to a font with suitable license in
>>>>> place for a commercial font. Also all feedback and help are welcome.
>>>>>
>>>>> Best,
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Apr 30, 2019 at 3:10 PM Ralf Gommers <ralf.gommers at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Thanks Stefan & Ilhan!
>>>>>>
>>>>>> Scikit-image has the right idea I think with a separate branding
>>>>>> repo. Shall we create one for SciPy as well?
>>>>>>
>>>>>> Ilhan, that looks really good! Would you be able to make a web-sized
>>>>>> image and add it to scipy-sphinx-theme? The current image is a 2.4kb gif, I
>>>>>> think it can be larger but as small as possible while still looking good
>>>>>> would be nice. Because it gets downloaded millions of times a month, and
>>>>>> also directly adds to the size of the numpy and scipy sdists.
>>>>>>
>>>>>> Cheers,
>>>>>> Ralf
>>>>>>
>>>>>>
>>>>>> On Mon, Apr 29, 2019 at 10:44 PM Ilhan Polat <ilhanpolat at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> By the way does anyone know what the font logo is? Just by
>>>>>>> eyeballing it looks like Franklin Gothic but I am not sure. However, if
>>>>>>> there is a more able typography connoisseur among us, here is the logo
>>>>>>> ready to be compiled by Xe/LuaLatex.
>>>>>>>
>>>>>>> \documentclass[tikz]{standalone}
>>>>>>> \usepackage{fontspec}
>>>>>>> \setsansfont{Franklin Gothic Medium}
>>>>>>> \usetikzlibrary{svg.path}
>>>>>>> \definecolor{scipylogo}{HTML}{8CAAE6}
>>>>>>>
>>>>>>> \begin{document}
>>>>>>> \begin{tikzpicture}[x=1pt, y=-1pt]
>>>>>>>
>>>>>>> \fill[scipylogo] (-50,-75) rectangle (1825, 575)
>>>>>>> svg[yscale=-1] {
>>>>>>> M348.369,282.469c-17.398-23.797-43.984-33.719-81.984-41.719
>>>>>>>
>>>>>>> l-35.334-8.332l-26.656-11.432c-14.01-9.902-25.947-36.26-22.559-59.502c5.264-36.006,38.896-61.104,75.127-56.045
>>>>>>>
>>>>>>> c18.094,2.559,33.438,12.139,43.555,25.625l40.117,52.705c22.93,29.531,48.711,38.32,76.758,24.375l14.141-6.016
>>>>>>>
>>>>>>> c1.133-0.527,2.461-0.576,3.75-0.107c1.055,0.41,1.914,1.162,2.422,2.051l2.813,4.238c0.781,1.279,1.953,2.314,3.477,2.891
>>>>>>>
>>>>>>> c2.578,0.977,5.352,0.391,7.305-1.289l32.578-30.723c5.703-4.883,4.023-9.365,4.023-9.365l-7.852-17.881
>>>>>>>
>>>>>>> c0,0-2.148-4.287-9.57-3.301l-43.672,4.014c-2.539,0.361-4.805,2.051-5.781,4.629c-0.586,1.504-0.625,3.076-0.195,4.502
>>>>>>>
>>>>>>> l1.563,5.029c0.313,1.045,0.313,2.217-0.117,3.291c-0.508,1.328-1.523,2.266-2.734,2.764l-12.344,5.225
>>>>>>>
>>>>>>> c-12.93,7.568-27.617,2.734-37.422-9.258l-11.211-14.893l-31.914-42.354c-15.156-20.098-38.008-34.434-65-38.203
>>>>>>>
>>>>>>> c-54.043-7.568-104.199,29.854-112.051,83.584c-3.965,27.08,4.152,52.703,18.965,73.281
>>>>>>>
>>>>>>> c10.762,14.953,30.486,23.496,41.154,26.164l28,8l26.814,6.145c3.688,0.875,14.063,3.438,20.203,5.656
>>>>>>>
>>>>>>> c5.676,2.055,18.75,6.875,29.375,15.57l0,0c12.695,12.906,19.414,31.344,16.563,50.68c-4.805,32.969-35.586,55.938-68.75,51.289
>>>>>>>
>>>>>>> c-16.611-2.305-30.635-11.109-39.922-23.438l-38.32-50.859c-7.813-10.367-19.629-17.773-33.594-19.766
>>>>>>>
>>>>>>> c-13.945-1.953-27.441,1.914-37.9,9.75l-80.615,60.156C11.455,333.914,0,292.898,0,249.266C0,111.621,113.926,0,254.443,0
>>>>>>>
>>>>>>> c104.629,0,194.434,61.855,233.535,150.254l12.891-5.996l8.711-23.809l9.141,3.203l-7.852,21.289l21.758,7.5l-3.281,8.916
>>>>>>>
>>>>>>> l-24.297-8.486l-13.398,6.162c11.094,27.998,17.266,58.398,17.266,90.232c0,137.656-113.945,249.258-254.473,249.258
>>>>>>>
>>>>>>> c-84.414,0-159.229-40.289-205.508-102.281l82.578-61.898c3.779-2.578,8.467-3.75,13.33-3.086
>>>>>>>
>>>>>>> c5.176,0.742,9.58,3.461,12.471,7.305l40.537,54.477c14.277,17.516,35.02,29.922,59.307,33.336
>>>>>>>
>>>>>>> c51.094,7.148,98.516-28.242,105.938-79.063C366.533,323.664,360.752,300.828,348.369,282.469};
>>>>>>>
>>>>>>> \node[anchor=east,
>>>>>>>       text=white,
>>>>>>>       font=\sffamily,
>>>>>>>       scale=30,
>>>>>>>       outer sep=0pt,
>>>>>>>       inner sep=0pt] (scipyorg) at (1750,250) {SciPy.org};
>>>>>>> \end{tikzpicture}
>>>>>>> \end{document}
>>>>>>>
>>>>>>> This code gives on my system
>>>>>>>
>>>>>>> [image: image.png]
>>>>>>>
>>>>>>> "i" and "P" needs a slight nudge to each other but that means the
>>>>>>> font is correct. Hence my question. Also you can play around and enjoy some
>>>>>>> TeX kerning/positioning/scaling bonanza yourself. I'll let Ralf to be the
>>>>>>> judge :)
>>>>>>>
>>>>>>> Best,
>>>>>>> ilhan
>>>>>>>
>>>>>>> On Mon, Apr 29, 2019 at 8:09 PM Ilhan Polat <ilhanpolat at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Perfect! Thanks.
>>>>>>>>
>>>>>>>> On Mon, Apr 29, 2019 at 7:44 PM Stefan van der Walt <
>>>>>>>> stefanv at berkeley.edu> wrote:
>>>>>>>>
>>>>>>>>> Found it and uploaded to GitHub:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://github.com/scikit-image/skimage-branding/blob/master/logo/scipy.svg
>>>>>>>>>
>>>>>>>>> On Mon, 29 Apr 2019 10:26:00 -0700, Stefan van der Walt wrote:
>>>>>>>>> > On Sat, 27 Apr 2019 23:49:03 +0200, Ralf Gommers wrote:
>>>>>>>>> > > Does anyone have the original files from which the current
>>>>>>>>> logo on scipy.org
>>>>>>>>> > > (it has the scipy symbol, white letter scipy.org and
>>>>>>>>> "sponsored by
>>>>>>>>> > > Enthough") was created? The quality is not great, and editing
>>>>>>>>> a tiny gif
>>>>>>>>> > > doesn't make it better ....
>>>>>>>>> >
>>>>>>>>> > I don't have the vector art, but I have a higher resolution
>>>>>>>>> render:
>>>>>>>>> >
>>>>>>>>> https://github.com/scikit-image/skimage-branding/blob/master/logo/data/scipy.png
>>>>>>>>> >
>>>>>>>>> > St?fan
>>>>>>>>> _______________________________________________
>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>> SciPy-Dev mailing list
>>>>>>> SciPy-Dev at python.org
>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>
>>>>>> _______________________________________________
>>>>>> SciPy-Dev mailing list
>>>>>> SciPy-Dev at python.org
>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>
>>>>> _______________________________________________
>>>>> SciPy-Dev mailing list
>>>>> SciPy-Dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at python.org
>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190504/0a4d2688/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 32300 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190504/0a4d2688/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 3475 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190504/0a4d2688/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 2590 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190504/0a4d2688/attachment-0005.png>

From chrissie.c.l at gmail.com  Sat May  4 08:38:09 2019
From: chrissie.c.l at gmail.com (Christina Lee)
Date: Sat, 4 May 2019 13:38:09 +0100
Subject: [SciPy-Dev] scipy.org logo original?
In-Reply-To: <CAEBuzr-_45=YY81BqjoOk7341sCLxKVuvXuCh5EhtOoQ2qFt8w@mail.gmail.com>
References: <CABL7CQi6FjoR=ekZDd+z7GoWZKJNEr3+Dh3FfTGSTh2CviyNqQ@mail.gmail.com>
 <20190429172600.tykgkl325xdygw74@carbo>
 <20190429174103.7xbkfyndweuv24ts@carbo>
 <CAEBuzr_jC9wnQKiyeojRp3C=ZcLaa9LTDHzwuS7GcitdoTbGdA@mail.gmail.com>
 <CAEBuzr9e32JUCkLii0Gu+B1+exzTsN_RAc9rKJUNn0siZaJfdA@mail.gmail.com>
 <CABL7CQgwo5ewG3g4eJ-oRT6JXb6EAqFGDLcrdXchHxTF0fAbaA@mail.gmail.com>
 <CAEBuzr-Ck=AxsuK+TtVAQ+NMjHGje0oxFCjDE8wYK6T9fHVXMQ@mail.gmail.com>
 <CAKkGBSYJ1a5vQym5Hh375jfgG+6FqcefNSMuFkEghZxSCw6LXQ@mail.gmail.com>
 <CABL7CQh-Qa7hz9UY_PCJoVdG9VQBdTd0jQOXDrdzD95L+NNUsA@mail.gmail.com>
 <CAEBuzr_crXgp+zV1SxfpphtQunGUCdOcU5wa1G_+o=izK_Ynvw@mail.gmail.com>
 <CABL7CQjUrgk8j-1r+B0m+_58jpVhLrg5c7EdhWLwEwONdJQ3nA@mail.gmail.com>
 <CAEBuzr-_45=YY81BqjoOk7341sCLxKVuvXuCh5EhtOoQ2qFt8w@mail.gmail.com>
Message-ID: <CAKkGBSYQFJo5+L92xPQCoeB_OZRqDTNhXeH2-KxXLnZsxedNig@mail.gmail.com>

As for the font, this also seems like a good moment to take a step back and
ask "Why that font?" "What are we trying to achieve with that font?" and
"Is there a better one?"

Instead of just choosing a font that is an approximation of the one that
has been there forever, this might be a good opportunity to choose
something better.  I can take a look later on.

Also, we don't need to shrink to a zero size file at the cost of something
pixelated that won't make a good impression.

Christina

On Sat, May 4, 2019 at 11:01 AM Ilhan Polat <ilhanpolat at gmail.com> wrote:

> Indeed I noticed that too but it seems like the original logo that Stefan
> linked to is also thin. So there is an alternative somewhere I guess. But
> I'll try to modify the curve coordinates to make it slightly thicker.
>
> On Sat, May 4, 2019 at 11:09 AM Ralf Gommers <ralf.gommers at gmail.com>
> wrote:
>
>>
>>
>> On Sat, May 4, 2019 at 10:25 AM Ilhan Polat <ilhanpolat at gmail.com> wrote:
>>
>>> OK, before I go pixel frenzy, I'd like to ask if the following is
>>> acceptable until we perform a substantial overhaul. This is the current
>>> logo
>>>
>>> [image: image.png]
>>>
>>> Keeping Christina's .org remark in mind, I've selected a sane
>>> approximation to our current setup and used the open source (SIL OFL 1.1)
>>> font Inter https://rsms.me/inter/ and the semibold weight variant of
>>> it. It has a really nice x-height hence still legible in small sizes. Also
>>> as you can see it does not suffer from the kerning issues we now have. You
>>> can also notice that the Logo snake has a bit less hand-drawnness to it.
>>>
>>> [image: image.png]
>>>
>>> It's the 3.4 kb version but can be reduced/optimized further. This mail
>>> is just for to get feedback. Here is the draft code in case you want to
>>> play around with it
>>> https://gist.github.com/ilayn/d121ec7deb009a9a257b4813c80dff27 just
>>> install the fonts and run it via Xe- or Lua-LaTeX.
>>>
>>> Please let me know if there are any
>>> objections/corrections/suggestions/design crimes I might have committed.
>>>
>>
>> Looks great, thanks for working on this! The one change I notice that may
>> be a regression is how thin the snake is. A line width closer to the
>> original may work a little better perhaps.
>>
>> Cheers,
>> Ralf
>>
>>
>>
>>
>>> Best,
>>> ilhan
>>>
>>>
>>> On Wed, May 1, 2019 at 3:34 PM Ralf Gommers <ralf.gommers at gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, May 1, 2019 at 2:50 PM Christina Lee <chrissie.c.l at gmail.com>
>>>> wrote:
>>>>
>>>>> Quick question, why does it include ".org"?   Can't the logo just say
>>>>> "SciPy"?
>>>>>
>>>>
>>>> Thanks Christina, that's a great question. I can't think of a reason,
>>>> just "SciPy" seems better. Perhaps we've been staring at it for so long
>>>> that it's not noticeable anymore. Let's change it now.
>>>>
>>>>
>>>>> A good rule of websites is to use svg whenever reasonable.  The main
>>>>> logo isn't the only image where doing this could bump up cleanliness.
>>>>> Several other logos on the main page could also use an update.  For
>>>>> example, just traced over the download graphic as attached. No more
>>>>> resolution problems, and smaller.
>>>>>
>>>>
>>>> That's great, thank you! Yes, you're right ... and it's not just the
>>>> logos that could use a makeover, the whole site needs attention.
>>>>
>>>> Cheers,
>>>> Ralf
>>>>
>>>>
>>>>>
>>>>> On Wed, May 1, 2019 at 12:05 PM Ilhan Polat <ilhanpolat at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> > Would you be able to make a web-sized image and add it to
>>>>>> scipy-sphinx-theme?
>>>>>> Yes that's not a problem thanks to the vector graphics. The main
>>>>>> concern here is the legibility of the font. I now think that the original
>>>>>> font was ITC franklin medium though.
>>>>>>
>>>>>> Anyways, I have searched for some open source fonts in the meantime
>>>>>> and many curation pages are available online; to give two results from a
>>>>>> quick Google search
>>>>>>
>>>>>>
>>>>>> https://medium.com/sketch-app-sources/30-free-and-open-source-typefaces-released-recently-best-collections-5b46f9d89f65
>>>>>>
>>>>>> https://www.forbes.com/sites/allbusiness/2014/03/06/10-best-sans-serif-web-fonts-from-google-fonts-library/#21da8027431b
>>>>>>
>>>>>> I am no designer by any means hence take these as availability stats
>>>>>> but we might be better off if we switch to a font with suitable license in
>>>>>> place for a commercial font. Also all feedback and help are welcome.
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Apr 30, 2019 at 3:10 PM Ralf Gommers <ralf.gommers at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Thanks Stefan & Ilhan!
>>>>>>>
>>>>>>> Scikit-image has the right idea I think with a separate branding
>>>>>>> repo. Shall we create one for SciPy as well?
>>>>>>>
>>>>>>> Ilhan, that looks really good! Would you be able to make a web-sized
>>>>>>> image and add it to scipy-sphinx-theme? The current image is a 2.4kb gif, I
>>>>>>> think it can be larger but as small as possible while still looking good
>>>>>>> would be nice. Because it gets downloaded millions of times a month, and
>>>>>>> also directly adds to the size of the numpy and scipy sdists.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Ralf
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Apr 29, 2019 at 10:44 PM Ilhan Polat <ilhanpolat at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> By the way does anyone know what the font logo is? Just by
>>>>>>>> eyeballing it looks like Franklin Gothic but I am not sure. However, if
>>>>>>>> there is a more able typography connoisseur among us, here is the logo
>>>>>>>> ready to be compiled by Xe/LuaLatex.
>>>>>>>>
>>>>>>>> \documentclass[tikz]{standalone}
>>>>>>>> \usepackage{fontspec}
>>>>>>>> \setsansfont{Franklin Gothic Medium}
>>>>>>>> \usetikzlibrary{svg.path}
>>>>>>>> \definecolor{scipylogo}{HTML}{8CAAE6}
>>>>>>>>
>>>>>>>> \begin{document}
>>>>>>>> \begin{tikzpicture}[x=1pt, y=-1pt]
>>>>>>>>
>>>>>>>> \fill[scipylogo] (-50,-75) rectangle (1825, 575)
>>>>>>>> svg[yscale=-1] {
>>>>>>>> M348.369,282.469c-17.398-23.797-43.984-33.719-81.984-41.719
>>>>>>>>
>>>>>>>> l-35.334-8.332l-26.656-11.432c-14.01-9.902-25.947-36.26-22.559-59.502c5.264-36.006,38.896-61.104,75.127-56.045
>>>>>>>>
>>>>>>>> c18.094,2.559,33.438,12.139,43.555,25.625l40.117,52.705c22.93,29.531,48.711,38.32,76.758,24.375l14.141-6.016
>>>>>>>>
>>>>>>>> c1.133-0.527,2.461-0.576,3.75-0.107c1.055,0.41,1.914,1.162,2.422,2.051l2.813,4.238c0.781,1.279,1.953,2.314,3.477,2.891
>>>>>>>>
>>>>>>>> c2.578,0.977,5.352,0.391,7.305-1.289l32.578-30.723c5.703-4.883,4.023-9.365,4.023-9.365l-7.852-17.881
>>>>>>>>
>>>>>>>> c0,0-2.148-4.287-9.57-3.301l-43.672,4.014c-2.539,0.361-4.805,2.051-5.781,4.629c-0.586,1.504-0.625,3.076-0.195,4.502
>>>>>>>>
>>>>>>>> l1.563,5.029c0.313,1.045,0.313,2.217-0.117,3.291c-0.508,1.328-1.523,2.266-2.734,2.764l-12.344,5.225
>>>>>>>>
>>>>>>>> c-12.93,7.568-27.617,2.734-37.422-9.258l-11.211-14.893l-31.914-42.354c-15.156-20.098-38.008-34.434-65-38.203
>>>>>>>>
>>>>>>>> c-54.043-7.568-104.199,29.854-112.051,83.584c-3.965,27.08,4.152,52.703,18.965,73.281
>>>>>>>>
>>>>>>>> c10.762,14.953,30.486,23.496,41.154,26.164l28,8l26.814,6.145c3.688,0.875,14.063,3.438,20.203,5.656
>>>>>>>>
>>>>>>>> c5.676,2.055,18.75,6.875,29.375,15.57l0,0c12.695,12.906,19.414,31.344,16.563,50.68c-4.805,32.969-35.586,55.938-68.75,51.289
>>>>>>>>
>>>>>>>> c-16.611-2.305-30.635-11.109-39.922-23.438l-38.32-50.859c-7.813-10.367-19.629-17.773-33.594-19.766
>>>>>>>>
>>>>>>>> c-13.945-1.953-27.441,1.914-37.9,9.75l-80.615,60.156C11.455,333.914,0,292.898,0,249.266C0,111.621,113.926,0,254.443,0
>>>>>>>>
>>>>>>>> c104.629,0,194.434,61.855,233.535,150.254l12.891-5.996l8.711-23.809l9.141,3.203l-7.852,21.289l21.758,7.5l-3.281,8.916
>>>>>>>>
>>>>>>>> l-24.297-8.486l-13.398,6.162c11.094,27.998,17.266,58.398,17.266,90.232c0,137.656-113.945,249.258-254.473,249.258
>>>>>>>>
>>>>>>>> c-84.414,0-159.229-40.289-205.508-102.281l82.578-61.898c3.779-2.578,8.467-3.75,13.33-3.086
>>>>>>>>
>>>>>>>> c5.176,0.742,9.58,3.461,12.471,7.305l40.537,54.477c14.277,17.516,35.02,29.922,59.307,33.336
>>>>>>>>
>>>>>>>> c51.094,7.148,98.516-28.242,105.938-79.063C366.533,323.664,360.752,300.828,348.369,282.469};
>>>>>>>>
>>>>>>>> \node[anchor=east,
>>>>>>>>       text=white,
>>>>>>>>       font=\sffamily,
>>>>>>>>       scale=30,
>>>>>>>>       outer sep=0pt,
>>>>>>>>       inner sep=0pt] (scipyorg) at (1750,250) {SciPy.org};
>>>>>>>> \end{tikzpicture}
>>>>>>>> \end{document}
>>>>>>>>
>>>>>>>> This code gives on my system
>>>>>>>>
>>>>>>>> [image: image.png]
>>>>>>>>
>>>>>>>> "i" and "P" needs a slight nudge to each other but that means the
>>>>>>>> font is correct. Hence my question. Also you can play around and enjoy some
>>>>>>>> TeX kerning/positioning/scaling bonanza yourself. I'll let Ralf to be the
>>>>>>>> judge :)
>>>>>>>>
>>>>>>>> Best,
>>>>>>>> ilhan
>>>>>>>>
>>>>>>>> On Mon, Apr 29, 2019 at 8:09 PM Ilhan Polat <ilhanpolat at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Perfect! Thanks.
>>>>>>>>>
>>>>>>>>> On Mon, Apr 29, 2019 at 7:44 PM Stefan van der Walt <
>>>>>>>>> stefanv at berkeley.edu> wrote:
>>>>>>>>>
>>>>>>>>>> Found it and uploaded to GitHub:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://github.com/scikit-image/skimage-branding/blob/master/logo/scipy.svg
>>>>>>>>>>
>>>>>>>>>> On Mon, 29 Apr 2019 10:26:00 -0700, Stefan van der Walt wrote:
>>>>>>>>>> > On Sat, 27 Apr 2019 23:49:03 +0200, Ralf Gommers wrote:
>>>>>>>>>> > > Does anyone have the original files from which the current
>>>>>>>>>> logo on scipy.org
>>>>>>>>>> > > (it has the scipy symbol, white letter scipy.org and
>>>>>>>>>> "sponsored by
>>>>>>>>>> > > Enthough") was created? The quality is not great, and editing
>>>>>>>>>> a tiny gif
>>>>>>>>>> > > doesn't make it better ....
>>>>>>>>>> >
>>>>>>>>>> > I don't have the vector art, but I have a higher resolution
>>>>>>>>>> render:
>>>>>>>>>> >
>>>>>>>>>> https://github.com/scikit-image/skimage-branding/blob/master/logo/data/scipy.png
>>>>>>>>>> >
>>>>>>>>>> > St?fan
>>>>>>>>>> _______________________________________________
>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>> SciPy-Dev mailing list
>>>>>>>> SciPy-Dev at python.org
>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> SciPy-Dev mailing list
>>>>>>> SciPy-Dev at python.org
>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>
>>>>>> _______________________________________________
>>>>>> SciPy-Dev mailing list
>>>>>> SciPy-Dev at python.org
>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>
>>>>> _______________________________________________
>>>>> SciPy-Dev mailing list
>>>>> SciPy-Dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at python.org
>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190504/6a4d593c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 32300 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190504/6a4d593c/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 3475 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190504/6a4d593c/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 2590 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190504/6a4d593c/attachment-0005.png>

From ilhanpolat at gmail.com  Sat May  4 11:37:55 2019
From: ilhanpolat at gmail.com (Ilhan Polat)
Date: Sat, 4 May 2019 17:37:55 +0200
Subject: [SciPy-Dev] scipy.org logo original?
In-Reply-To: <CAKkGBSYQFJo5+L92xPQCoeB_OZRqDTNhXeH2-KxXLnZsxedNig@mail.gmail.com>
References: <CABL7CQi6FjoR=ekZDd+z7GoWZKJNEr3+Dh3FfTGSTh2CviyNqQ@mail.gmail.com>
 <20190429172600.tykgkl325xdygw74@carbo>
 <20190429174103.7xbkfyndweuv24ts@carbo>
 <CAEBuzr_jC9wnQKiyeojRp3C=ZcLaa9LTDHzwuS7GcitdoTbGdA@mail.gmail.com>
 <CAEBuzr9e32JUCkLii0Gu+B1+exzTsN_RAc9rKJUNn0siZaJfdA@mail.gmail.com>
 <CABL7CQgwo5ewG3g4eJ-oRT6JXb6EAqFGDLcrdXchHxTF0fAbaA@mail.gmail.com>
 <CAEBuzr-Ck=AxsuK+TtVAQ+NMjHGje0oxFCjDE8wYK6T9fHVXMQ@mail.gmail.com>
 <CAKkGBSYJ1a5vQym5Hh375jfgG+6FqcefNSMuFkEghZxSCw6LXQ@mail.gmail.com>
 <CABL7CQh-Qa7hz9UY_PCJoVdG9VQBdTd0jQOXDrdzD95L+NNUsA@mail.gmail.com>
 <CAEBuzr_crXgp+zV1SxfpphtQunGUCdOcU5wa1G_+o=izK_Ynvw@mail.gmail.com>
 <CABL7CQjUrgk8j-1r+B0m+_58jpVhLrg5c7EdhWLwEwONdJQ3nA@mail.gmail.com>
 <CAEBuzr-_45=YY81BqjoOk7341sCLxKVuvXuCh5EhtOoQ2qFt8w@mail.gmail.com>
 <CAKkGBSYQFJo5+L92xPQCoeB_OZRqDTNhXeH2-KxXLnZsxedNig@mail.gmail.com>
Message-ID: <CAEBuzr-9LEDBAou=e4o+FTVdrP9YximDQtbiea-=_DZX_6R2WQ@mail.gmail.com>

Very good suggestion. My intention was to get to a point where we are ready
with the recent advances with sponsorships and grant applications etc.
happening in the project. I think it is important to update the commercial
details to signal a proper message to nonPython users who would probably
notice these tiny details way better than we do.
Then we would be done with the bare essentials and can take our time with
the new design should we decide to do so. Hence I see this as a preparation
for the long term overhaul and hence the approximation. Other than that you
are absolutely right that this is yet another stab without a coherent
design brief.

On Sat, May 4, 2019 at 2:39 PM Christina Lee <chrissie.c.l at gmail.com> wrote:

> As for the font, this also seems like a good moment to take a step back
> and ask "Why that font?" "What are we trying to achieve with that font?"
> and "Is there a better one?"
>
> Instead of just choosing a font that is an approximation of the one that
> has been there forever, this might be a good opportunity to choose
> something better.  I can take a look later on.
>
> Also, we don't need to shrink to a zero size file at the cost of something
> pixelated that won't make a good impression.
>
> Christina
>
> On Sat, May 4, 2019 at 11:01 AM Ilhan Polat <ilhanpolat at gmail.com> wrote:
>
>> Indeed I noticed that too but it seems like the original logo that Stefan
>> linked to is also thin. So there is an alternative somewhere I guess. But
>> I'll try to modify the curve coordinates to make it slightly thicker.
>>
>> On Sat, May 4, 2019 at 11:09 AM Ralf Gommers <ralf.gommers at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Sat, May 4, 2019 at 10:25 AM Ilhan Polat <ilhanpolat at gmail.com>
>>> wrote:
>>>
>>>> OK, before I go pixel frenzy, I'd like to ask if the following is
>>>> acceptable until we perform a substantial overhaul. This is the current
>>>> logo
>>>>
>>>> [image: image.png]
>>>>
>>>> Keeping Christina's .org remark in mind, I've selected a sane
>>>> approximation to our current setup and used the open source (SIL OFL 1.1)
>>>> font Inter https://rsms.me/inter/ and the semibold weight variant of
>>>> it. It has a really nice x-height hence still legible in small sizes. Also
>>>> as you can see it does not suffer from the kerning issues we now have. You
>>>> can also notice that the Logo snake has a bit less hand-drawnness to it.
>>>>
>>>> [image: image.png]
>>>>
>>>> It's the 3.4 kb version but can be reduced/optimized further. This mail
>>>> is just for to get feedback. Here is the draft code in case you want to
>>>> play around with it
>>>> https://gist.github.com/ilayn/d121ec7deb009a9a257b4813c80dff27 just
>>>> install the fonts and run it via Xe- or Lua-LaTeX.
>>>>
>>>> Please let me know if there are any
>>>> objections/corrections/suggestions/design crimes I might have committed.
>>>>
>>>
>>> Looks great, thanks for working on this! The one change I notice that
>>> may be a regression is how thin the snake is. A line width closer to the
>>> original may work a little better perhaps.
>>>
>>> Cheers,
>>> Ralf
>>>
>>>
>>>
>>>
>>>> Best,
>>>> ilhan
>>>>
>>>>
>>>> On Wed, May 1, 2019 at 3:34 PM Ralf Gommers <ralf.gommers at gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, May 1, 2019 at 2:50 PM Christina Lee <chrissie.c.l at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Quick question, why does it include ".org"?   Can't the logo just say
>>>>>> "SciPy"?
>>>>>>
>>>>>
>>>>> Thanks Christina, that's a great question. I can't think of a reason,
>>>>> just "SciPy" seems better. Perhaps we've been staring at it for so long
>>>>> that it's not noticeable anymore. Let's change it now.
>>>>>
>>>>>
>>>>>> A good rule of websites is to use svg whenever reasonable.  The main
>>>>>> logo isn't the only image where doing this could bump up cleanliness.
>>>>>> Several other logos on the main page could also use an update.  For
>>>>>> example, just traced over the download graphic as attached. No more
>>>>>> resolution problems, and smaller.
>>>>>>
>>>>>
>>>>> That's great, thank you! Yes, you're right ... and it's not just the
>>>>> logos that could use a makeover, the whole site needs attention.
>>>>>
>>>>> Cheers,
>>>>> Ralf
>>>>>
>>>>>
>>>>>>
>>>>>> On Wed, May 1, 2019 at 12:05 PM Ilhan Polat <ilhanpolat at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> > Would you be able to make a web-sized image and add it to
>>>>>>> scipy-sphinx-theme?
>>>>>>> Yes that's not a problem thanks to the vector graphics. The main
>>>>>>> concern here is the legibility of the font. I now think that the original
>>>>>>> font was ITC franklin medium though.
>>>>>>>
>>>>>>> Anyways, I have searched for some open source fonts in the meantime
>>>>>>> and many curation pages are available online; to give two results from a
>>>>>>> quick Google search
>>>>>>>
>>>>>>>
>>>>>>> https://medium.com/sketch-app-sources/30-free-and-open-source-typefaces-released-recently-best-collections-5b46f9d89f65
>>>>>>>
>>>>>>> https://www.forbes.com/sites/allbusiness/2014/03/06/10-best-sans-serif-web-fonts-from-google-fonts-library/#21da8027431b
>>>>>>>
>>>>>>> I am no designer by any means hence take these as availability stats
>>>>>>> but we might be better off if we switch to a font with suitable license in
>>>>>>> place for a commercial font. Also all feedback and help are welcome.
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Apr 30, 2019 at 3:10 PM Ralf Gommers <ralf.gommers at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Thanks Stefan & Ilhan!
>>>>>>>>
>>>>>>>> Scikit-image has the right idea I think with a separate branding
>>>>>>>> repo. Shall we create one for SciPy as well?
>>>>>>>>
>>>>>>>> Ilhan, that looks really good! Would you be able to make a
>>>>>>>> web-sized image and add it to scipy-sphinx-theme? The current image is a
>>>>>>>> 2.4kb gif, I think it can be larger but as small as possible while still
>>>>>>>> looking good would be nice. Because it gets downloaded millions of times a
>>>>>>>> month, and also directly adds to the size of the numpy and scipy sdists.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Ralf
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Apr 29, 2019 at 10:44 PM Ilhan Polat <ilhanpolat at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> By the way does anyone know what the font logo is? Just by
>>>>>>>>> eyeballing it looks like Franklin Gothic but I am not sure. However, if
>>>>>>>>> there is a more able typography connoisseur among us, here is the logo
>>>>>>>>> ready to be compiled by Xe/LuaLatex.
>>>>>>>>>
>>>>>>>>> \documentclass[tikz]{standalone}
>>>>>>>>> \usepackage{fontspec}
>>>>>>>>> \setsansfont{Franklin Gothic Medium}
>>>>>>>>> \usetikzlibrary{svg.path}
>>>>>>>>> \definecolor{scipylogo}{HTML}{8CAAE6}
>>>>>>>>>
>>>>>>>>> \begin{document}
>>>>>>>>> \begin{tikzpicture}[x=1pt, y=-1pt]
>>>>>>>>>
>>>>>>>>> \fill[scipylogo] (-50,-75) rectangle (1825, 575)
>>>>>>>>> svg[yscale=-1] {
>>>>>>>>> M348.369,282.469c-17.398-23.797-43.984-33.719-81.984-41.719
>>>>>>>>>
>>>>>>>>> l-35.334-8.332l-26.656-11.432c-14.01-9.902-25.947-36.26-22.559-59.502c5.264-36.006,38.896-61.104,75.127-56.045
>>>>>>>>>
>>>>>>>>> c18.094,2.559,33.438,12.139,43.555,25.625l40.117,52.705c22.93,29.531,48.711,38.32,76.758,24.375l14.141-6.016
>>>>>>>>>
>>>>>>>>> c1.133-0.527,2.461-0.576,3.75-0.107c1.055,0.41,1.914,1.162,2.422,2.051l2.813,4.238c0.781,1.279,1.953,2.314,3.477,2.891
>>>>>>>>>
>>>>>>>>> c2.578,0.977,5.352,0.391,7.305-1.289l32.578-30.723c5.703-4.883,4.023-9.365,4.023-9.365l-7.852-17.881
>>>>>>>>>
>>>>>>>>> c0,0-2.148-4.287-9.57-3.301l-43.672,4.014c-2.539,0.361-4.805,2.051-5.781,4.629c-0.586,1.504-0.625,3.076-0.195,4.502
>>>>>>>>>
>>>>>>>>> l1.563,5.029c0.313,1.045,0.313,2.217-0.117,3.291c-0.508,1.328-1.523,2.266-2.734,2.764l-12.344,5.225
>>>>>>>>>
>>>>>>>>> c-12.93,7.568-27.617,2.734-37.422-9.258l-11.211-14.893l-31.914-42.354c-15.156-20.098-38.008-34.434-65-38.203
>>>>>>>>>
>>>>>>>>> c-54.043-7.568-104.199,29.854-112.051,83.584c-3.965,27.08,4.152,52.703,18.965,73.281
>>>>>>>>>
>>>>>>>>> c10.762,14.953,30.486,23.496,41.154,26.164l28,8l26.814,6.145c3.688,0.875,14.063,3.438,20.203,5.656
>>>>>>>>>
>>>>>>>>> c5.676,2.055,18.75,6.875,29.375,15.57l0,0c12.695,12.906,19.414,31.344,16.563,50.68c-4.805,32.969-35.586,55.938-68.75,51.289
>>>>>>>>>
>>>>>>>>> c-16.611-2.305-30.635-11.109-39.922-23.438l-38.32-50.859c-7.813-10.367-19.629-17.773-33.594-19.766
>>>>>>>>>
>>>>>>>>> c-13.945-1.953-27.441,1.914-37.9,9.75l-80.615,60.156C11.455,333.914,0,292.898,0,249.266C0,111.621,113.926,0,254.443,0
>>>>>>>>>
>>>>>>>>> c104.629,0,194.434,61.855,233.535,150.254l12.891-5.996l8.711-23.809l9.141,3.203l-7.852,21.289l21.758,7.5l-3.281,8.916
>>>>>>>>>
>>>>>>>>> l-24.297-8.486l-13.398,6.162c11.094,27.998,17.266,58.398,17.266,90.232c0,137.656-113.945,249.258-254.473,249.258
>>>>>>>>>
>>>>>>>>> c-84.414,0-159.229-40.289-205.508-102.281l82.578-61.898c3.779-2.578,8.467-3.75,13.33-3.086
>>>>>>>>>
>>>>>>>>> c5.176,0.742,9.58,3.461,12.471,7.305l40.537,54.477c14.277,17.516,35.02,29.922,59.307,33.336
>>>>>>>>>
>>>>>>>>> c51.094,7.148,98.516-28.242,105.938-79.063C366.533,323.664,360.752,300.828,348.369,282.469};
>>>>>>>>>
>>>>>>>>> \node[anchor=east,
>>>>>>>>>       text=white,
>>>>>>>>>       font=\sffamily,
>>>>>>>>>       scale=30,
>>>>>>>>>       outer sep=0pt,
>>>>>>>>>       inner sep=0pt] (scipyorg) at (1750,250) {SciPy.org};
>>>>>>>>> \end{tikzpicture}
>>>>>>>>> \end{document}
>>>>>>>>>
>>>>>>>>> This code gives on my system
>>>>>>>>>
>>>>>>>>> [image: image.png]
>>>>>>>>>
>>>>>>>>> "i" and "P" needs a slight nudge to each other but that means the
>>>>>>>>> font is correct. Hence my question. Also you can play around and enjoy some
>>>>>>>>> TeX kerning/positioning/scaling bonanza yourself. I'll let Ralf to be the
>>>>>>>>> judge :)
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>> ilhan
>>>>>>>>>
>>>>>>>>> On Mon, Apr 29, 2019 at 8:09 PM Ilhan Polat <ilhanpolat at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Perfect! Thanks.
>>>>>>>>>>
>>>>>>>>>> On Mon, Apr 29, 2019 at 7:44 PM Stefan van der Walt <
>>>>>>>>>> stefanv at berkeley.edu> wrote:
>>>>>>>>>>
>>>>>>>>>>> Found it and uploaded to GitHub:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> https://github.com/scikit-image/skimage-branding/blob/master/logo/scipy.svg
>>>>>>>>>>>
>>>>>>>>>>> On Mon, 29 Apr 2019 10:26:00 -0700, Stefan van der Walt wrote:
>>>>>>>>>>> > On Sat, 27 Apr 2019 23:49:03 +0200, Ralf Gommers wrote:
>>>>>>>>>>> > > Does anyone have the original files from which the current
>>>>>>>>>>> logo on scipy.org
>>>>>>>>>>> > > (it has the scipy symbol, white letter scipy.org and
>>>>>>>>>>> "sponsored by
>>>>>>>>>>> > > Enthough") was created? The quality is not great, and
>>>>>>>>>>> editing a tiny gif
>>>>>>>>>>> > > doesn't make it better ....
>>>>>>>>>>> >
>>>>>>>>>>> > I don't have the vector art, but I have a higher resolution
>>>>>>>>>>> render:
>>>>>>>>>>> >
>>>>>>>>>>> https://github.com/scikit-image/skimage-branding/blob/master/logo/data/scipy.png
>>>>>>>>>>> >
>>>>>>>>>>> > St?fan
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> SciPy-Dev mailing list
>>>>>>>> SciPy-Dev at python.org
>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> SciPy-Dev mailing list
>>>>>>> SciPy-Dev at python.org
>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>
>>>>>> _______________________________________________
>>>>>> SciPy-Dev mailing list
>>>>>> SciPy-Dev at python.org
>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>
>>>>> _______________________________________________
>>>>> SciPy-Dev mailing list
>>>>> SciPy-Dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at python.org
>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190504/f79e3d4c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 32300 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190504/f79e3d4c/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 3475 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190504/f79e3d4c/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 2590 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190504/f79e3d4c/attachment-0005.png>

From bennet at umich.edu  Sat May  4 11:58:48 2019
From: bennet at umich.edu (Bennet Fauber)
Date: Sat, 4 May 2019 11:58:48 -0400
Subject: [SciPy-Dev] scipy.org logo original?
In-Reply-To: <CAEBuzr-9LEDBAou=e4o+FTVdrP9YximDQtbiea-=_DZX_6R2WQ@mail.gmail.com>
References: <CABL7CQi6FjoR=ekZDd+z7GoWZKJNEr3+Dh3FfTGSTh2CviyNqQ@mail.gmail.com>
 <20190429172600.tykgkl325xdygw74@carbo>
 <20190429174103.7xbkfyndweuv24ts@carbo>
 <CAEBuzr_jC9wnQKiyeojRp3C=ZcLaa9LTDHzwuS7GcitdoTbGdA@mail.gmail.com>
 <CAEBuzr9e32JUCkLii0Gu+B1+exzTsN_RAc9rKJUNn0siZaJfdA@mail.gmail.com>
 <CABL7CQgwo5ewG3g4eJ-oRT6JXb6EAqFGDLcrdXchHxTF0fAbaA@mail.gmail.com>
 <CAEBuzr-Ck=AxsuK+TtVAQ+NMjHGje0oxFCjDE8wYK6T9fHVXMQ@mail.gmail.com>
 <CAKkGBSYJ1a5vQym5Hh375jfgG+6FqcefNSMuFkEghZxSCw6LXQ@mail.gmail.com>
 <CABL7CQh-Qa7hz9UY_PCJoVdG9VQBdTd0jQOXDrdzD95L+NNUsA@mail.gmail.com>
 <CAEBuzr_crXgp+zV1SxfpphtQunGUCdOcU5wa1G_+o=izK_Ynvw@mail.gmail.com>
 <CABL7CQjUrgk8j-1r+B0m+_58jpVhLrg5c7EdhWLwEwONdJQ3nA@mail.gmail.com>
 <CAEBuzr-_45=YY81BqjoOk7341sCLxKVuvXuCh5EhtOoQ2qFt8w@mail.gmail.com>
 <CAKkGBSYQFJo5+L92xPQCoeB_OZRqDTNhXeH2-KxXLnZsxedNig@mail.gmail.com>
 <CAEBuzr-9LEDBAou=e4o+FTVdrP9YximDQtbiea-=_DZX_6R2WQ@mail.gmail.com>
Message-ID: <CAB2ovovUfkv4iooQ-BWxdEuA18bmcHWof5Awzno5zDKMdcK7TQ@mail.gmail.com>

Ilhan,

I think the font and snake look fine.  Perhaps a larger margin at the
beginning and end?  It looks to be less than an inter-word space, which is
about what it appears to be in the SciPy.org version.



On Sat, May 4, 2019 at 11:41 AM Ilhan Polat <ilhanpolat at gmail.com> wrote:

> Very good suggestion. My intention was to get to a point where we are
> ready with the recent advances with sponsorships and grant applications
> etc. happening in the project. I think it is important to update the
> commercial details to signal a proper message to nonPython users who would
> probably notice these tiny details way better than we do.
> Then we would be done with the bare essentials and can take our time with
> the new design should we decide to do so. Hence I see this as a preparation
> for the long term overhaul and hence the approximation. Other than that you
> are absolutely right that this is yet another stab without a coherent
> design brief.
>
> On Sat, May 4, 2019 at 2:39 PM Christina Lee <chrissie.c.l at gmail.com>
> wrote:
>
>> As for the font, this also seems like a good moment to take a step back
>> and ask "Why that font?" "What are we trying to achieve with that font?"
>> and "Is there a better one?"
>>
>> Instead of just choosing a font that is an approximation of the one that
>> has been there forever, this might be a good opportunity to choose
>> something better.  I can take a look later on.
>>
>> Also, we don't need to shrink to a zero size file at the cost of
>> something pixelated that won't make a good impression.
>>
>> Christina
>>
>> On Sat, May 4, 2019 at 11:01 AM Ilhan Polat <ilhanpolat at gmail.com> wrote:
>>
>>> Indeed I noticed that too but it seems like the original logo that
>>> Stefan linked to is also thin. So there is an alternative somewhere I
>>> guess. But I'll try to modify the curve coordinates to make it slightly
>>> thicker.
>>>
>>> On Sat, May 4, 2019 at 11:09 AM Ralf Gommers <ralf.gommers at gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Sat, May 4, 2019 at 10:25 AM Ilhan Polat <ilhanpolat at gmail.com>
>>>> wrote:
>>>>
>>>>> OK, before I go pixel frenzy, I'd like to ask if the following is
>>>>> acceptable until we perform a substantial overhaul. This is the current
>>>>> logo
>>>>>
>>>>> [image: image.png]
>>>>>
>>>>> Keeping Christina's .org remark in mind, I've selected a sane
>>>>> approximation to our current setup and used the open source (SIL OFL 1.1)
>>>>> font Inter https://rsms.me/inter/ and the semibold weight variant of
>>>>> it. It has a really nice x-height hence still legible in small sizes. Also
>>>>> as you can see it does not suffer from the kerning issues we now have. You
>>>>> can also notice that the Logo snake has a bit less hand-drawnness to it.
>>>>>
>>>>> [image: image.png]
>>>>>
>>>>> It's the 3.4 kb version but can be reduced/optimized further. This
>>>>> mail is just for to get feedback. Here is the draft code in case you want
>>>>> to play around with it
>>>>> https://gist.github.com/ilayn/d121ec7deb009a9a257b4813c80dff27 just
>>>>> install the fonts and run it via Xe- or Lua-LaTeX.
>>>>>
>>>>> Please let me know if there are any
>>>>> objections/corrections/suggestions/design crimes I might have committed.
>>>>>
>>>>
>>>> Looks great, thanks for working on this! The one change I notice that
>>>> may be a regression is how thin the snake is. A line width closer to the
>>>> original may work a little better perhaps.
>>>>
>>>> Cheers,
>>>> Ralf
>>>>
>>>>
>>>>
>>>>
>>>>> Best,
>>>>> ilhan
>>>>>
>>>>>
>>>>> On Wed, May 1, 2019 at 3:34 PM Ralf Gommers <ralf.gommers at gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, May 1, 2019 at 2:50 PM Christina Lee <chrissie.c.l at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Quick question, why does it include ".org"?   Can't the logo just
>>>>>>> say "SciPy"?
>>>>>>>
>>>>>>
>>>>>> Thanks Christina, that's a great question. I can't think of a reason,
>>>>>> just "SciPy" seems better. Perhaps we've been staring at it for so long
>>>>>> that it's not noticeable anymore. Let's change it now.
>>>>>>
>>>>>>
>>>>>>> A good rule of websites is to use svg whenever reasonable.  The main
>>>>>>> logo isn't the only image where doing this could bump up cleanliness.
>>>>>>> Several other logos on the main page could also use an update.  For
>>>>>>> example, just traced over the download graphic as attached. No more
>>>>>>> resolution problems, and smaller.
>>>>>>>
>>>>>>
>>>>>> That's great, thank you! Yes, you're right ... and it's not just the
>>>>>> logos that could use a makeover, the whole site needs attention.
>>>>>>
>>>>>> Cheers,
>>>>>> Ralf
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Wed, May 1, 2019 at 12:05 PM Ilhan Polat <ilhanpolat at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> > Would you be able to make a web-sized image and add it to
>>>>>>>> scipy-sphinx-theme?
>>>>>>>> Yes that's not a problem thanks to the vector graphics. The main
>>>>>>>> concern here is the legibility of the font. I now think that the original
>>>>>>>> font was ITC franklin medium though.
>>>>>>>>
>>>>>>>> Anyways, I have searched for some open source fonts in the meantime
>>>>>>>> and many curation pages are available online; to give two results from a
>>>>>>>> quick Google search
>>>>>>>>
>>>>>>>>
>>>>>>>> https://medium.com/sketch-app-sources/30-free-and-open-source-typefaces-released-recently-best-collections-5b46f9d89f65
>>>>>>>>
>>>>>>>> https://www.forbes.com/sites/allbusiness/2014/03/06/10-best-sans-serif-web-fonts-from-google-fonts-library/#21da8027431b
>>>>>>>>
>>>>>>>> I am no designer by any means hence take these as availability
>>>>>>>> stats but we might be better off if we switch to a font with suitable
>>>>>>>> license in place for a commercial font. Also all feedback and help are
>>>>>>>> welcome.
>>>>>>>>
>>>>>>>> Best,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Apr 30, 2019 at 3:10 PM Ralf Gommers <
>>>>>>>> ralf.gommers at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Thanks Stefan & Ilhan!
>>>>>>>>>
>>>>>>>>> Scikit-image has the right idea I think with a separate branding
>>>>>>>>> repo. Shall we create one for SciPy as well?
>>>>>>>>>
>>>>>>>>> Ilhan, that looks really good! Would you be able to make a
>>>>>>>>> web-sized image and add it to scipy-sphinx-theme? The current image is a
>>>>>>>>> 2.4kb gif, I think it can be larger but as small as possible while still
>>>>>>>>> looking good would be nice. Because it gets downloaded millions of times a
>>>>>>>>> month, and also directly adds to the size of the numpy and scipy sdists.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Ralf
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Apr 29, 2019 at 10:44 PM Ilhan Polat <ilhanpolat at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> By the way does anyone know what the font logo is? Just by
>>>>>>>>>> eyeballing it looks like Franklin Gothic but I am not sure. However, if
>>>>>>>>>> there is a more able typography connoisseur among us, here is the logo
>>>>>>>>>> ready to be compiled by Xe/LuaLatex.
>>>>>>>>>>
>>>>>>>>>> \documentclass[tikz]{standalone}
>>>>>>>>>> \usepackage{fontspec}
>>>>>>>>>> \setsansfont{Franklin Gothic Medium}
>>>>>>>>>> \usetikzlibrary{svg.path}
>>>>>>>>>> \definecolor{scipylogo}{HTML}{8CAAE6}
>>>>>>>>>>
>>>>>>>>>> \begin{document}
>>>>>>>>>> \begin{tikzpicture}[x=1pt, y=-1pt]
>>>>>>>>>>
>>>>>>>>>> \fill[scipylogo] (-50,-75) rectangle (1825, 575)
>>>>>>>>>> svg[yscale=-1] {
>>>>>>>>>> M348.369,282.469c-17.398-23.797-43.984-33.719-81.984-41.719
>>>>>>>>>>
>>>>>>>>>> l-35.334-8.332l-26.656-11.432c-14.01-9.902-25.947-36.26-22.559-59.502c5.264-36.006,38.896-61.104,75.127-56.045
>>>>>>>>>>
>>>>>>>>>> c18.094,2.559,33.438,12.139,43.555,25.625l40.117,52.705c22.93,29.531,48.711,38.32,76.758,24.375l14.141-6.016
>>>>>>>>>>
>>>>>>>>>> c1.133-0.527,2.461-0.576,3.75-0.107c1.055,0.41,1.914,1.162,2.422,2.051l2.813,4.238c0.781,1.279,1.953,2.314,3.477,2.891
>>>>>>>>>>
>>>>>>>>>> c2.578,0.977,5.352,0.391,7.305-1.289l32.578-30.723c5.703-4.883,4.023-9.365,4.023-9.365l-7.852-17.881
>>>>>>>>>>
>>>>>>>>>> c0,0-2.148-4.287-9.57-3.301l-43.672,4.014c-2.539,0.361-4.805,2.051-5.781,4.629c-0.586,1.504-0.625,3.076-0.195,4.502
>>>>>>>>>>
>>>>>>>>>> l1.563,5.029c0.313,1.045,0.313,2.217-0.117,3.291c-0.508,1.328-1.523,2.266-2.734,2.764l-12.344,5.225
>>>>>>>>>>
>>>>>>>>>> c-12.93,7.568-27.617,2.734-37.422-9.258l-11.211-14.893l-31.914-42.354c-15.156-20.098-38.008-34.434-65-38.203
>>>>>>>>>>
>>>>>>>>>> c-54.043-7.568-104.199,29.854-112.051,83.584c-3.965,27.08,4.152,52.703,18.965,73.281
>>>>>>>>>>
>>>>>>>>>> c10.762,14.953,30.486,23.496,41.154,26.164l28,8l26.814,6.145c3.688,0.875,14.063,3.438,20.203,5.656
>>>>>>>>>>
>>>>>>>>>> c5.676,2.055,18.75,6.875,29.375,15.57l0,0c12.695,12.906,19.414,31.344,16.563,50.68c-4.805,32.969-35.586,55.938-68.75,51.289
>>>>>>>>>>
>>>>>>>>>> c-16.611-2.305-30.635-11.109-39.922-23.438l-38.32-50.859c-7.813-10.367-19.629-17.773-33.594-19.766
>>>>>>>>>>
>>>>>>>>>> c-13.945-1.953-27.441,1.914-37.9,9.75l-80.615,60.156C11.455,333.914,0,292.898,0,249.266C0,111.621,113.926,0,254.443,0
>>>>>>>>>>
>>>>>>>>>> c104.629,0,194.434,61.855,233.535,150.254l12.891-5.996l8.711-23.809l9.141,3.203l-7.852,21.289l21.758,7.5l-3.281,8.916
>>>>>>>>>>
>>>>>>>>>> l-24.297-8.486l-13.398,6.162c11.094,27.998,17.266,58.398,17.266,90.232c0,137.656-113.945,249.258-254.473,249.258
>>>>>>>>>>
>>>>>>>>>> c-84.414,0-159.229-40.289-205.508-102.281l82.578-61.898c3.779-2.578,8.467-3.75,13.33-3.086
>>>>>>>>>>
>>>>>>>>>> c5.176,0.742,9.58,3.461,12.471,7.305l40.537,54.477c14.277,17.516,35.02,29.922,59.307,33.336
>>>>>>>>>>
>>>>>>>>>> c51.094,7.148,98.516-28.242,105.938-79.063C366.533,323.664,360.752,300.828,348.369,282.469};
>>>>>>>>>>
>>>>>>>>>> \node[anchor=east,
>>>>>>>>>>       text=white,
>>>>>>>>>>       font=\sffamily,
>>>>>>>>>>       scale=30,
>>>>>>>>>>       outer sep=0pt,
>>>>>>>>>>       inner sep=0pt] (scipyorg) at (1750,250) {SciPy.org};
>>>>>>>>>> \end{tikzpicture}
>>>>>>>>>> \end{document}
>>>>>>>>>>
>>>>>>>>>> This code gives on my system
>>>>>>>>>>
>>>>>>>>>> [image: image.png]
>>>>>>>>>>
>>>>>>>>>> "i" and "P" needs a slight nudge to each other but that means the
>>>>>>>>>> font is correct. Hence my question. Also you can play around and enjoy some
>>>>>>>>>> TeX kerning/positioning/scaling bonanza yourself. I'll let Ralf to be the
>>>>>>>>>> judge :)
>>>>>>>>>>
>>>>>>>>>> Best,
>>>>>>>>>> ilhan
>>>>>>>>>>
>>>>>>>>>> On Mon, Apr 29, 2019 at 8:09 PM Ilhan Polat <ilhanpolat at gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Perfect! Thanks.
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Apr 29, 2019 at 7:44 PM Stefan van der Walt <
>>>>>>>>>>> stefanv at berkeley.edu> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Found it and uploaded to GitHub:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> https://github.com/scikit-image/skimage-branding/blob/master/logo/scipy.svg
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, 29 Apr 2019 10:26:00 -0700, Stefan van der Walt wrote:
>>>>>>>>>>>> > On Sat, 27 Apr 2019 23:49:03 +0200, Ralf Gommers wrote:
>>>>>>>>>>>> > > Does anyone have the original files from which the current
>>>>>>>>>>>> logo on scipy.org
>>>>>>>>>>>> > > (it has the scipy symbol, white letter scipy.org and
>>>>>>>>>>>> "sponsored by
>>>>>>>>>>>> > > Enthough") was created? The quality is not great, and
>>>>>>>>>>>> editing a tiny gif
>>>>>>>>>>>> > > doesn't make it better ....
>>>>>>>>>>>> >
>>>>>>>>>>>> > I don't have the vector art, but I have a higher resolution
>>>>>>>>>>>> render:
>>>>>>>>>>>> >
>>>>>>>>>>>> https://github.com/scikit-image/skimage-branding/blob/master/logo/data/scipy.png
>>>>>>>>>>>> >
>>>>>>>>>>>> > St?fan
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> SciPy-Dev mailing list
>>>>>>>> SciPy-Dev at python.org
>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> SciPy-Dev mailing list
>>>>>>> SciPy-Dev at python.org
>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>
>>>>>> _______________________________________________
>>>>>> SciPy-Dev mailing list
>>>>>> SciPy-Dev at python.org
>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>
>>>>> _______________________________________________
>>>>> SciPy-Dev mailing list
>>>>> SciPy-Dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at python.org
>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190504/113ab782/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 32300 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190504/113ab782/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 3475 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190504/113ab782/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 2590 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190504/113ab782/attachment-0005.png>

From chrissie.c.l at gmail.com  Sat May  4 18:16:40 2019
From: chrissie.c.l at gmail.com (Christina Lee)
Date: Sat, 4 May 2019 23:16:40 +0100
Subject: [SciPy-Dev] scipy.org logo original?
In-Reply-To: <CAB2ovovUfkv4iooQ-BWxdEuA18bmcHWof5Awzno5zDKMdcK7TQ@mail.gmail.com>
References: <CABL7CQi6FjoR=ekZDd+z7GoWZKJNEr3+Dh3FfTGSTh2CviyNqQ@mail.gmail.com>
 <20190429172600.tykgkl325xdygw74@carbo>
 <20190429174103.7xbkfyndweuv24ts@carbo>
 <CAEBuzr_jC9wnQKiyeojRp3C=ZcLaa9LTDHzwuS7GcitdoTbGdA@mail.gmail.com>
 <CAEBuzr9e32JUCkLii0Gu+B1+exzTsN_RAc9rKJUNn0siZaJfdA@mail.gmail.com>
 <CABL7CQgwo5ewG3g4eJ-oRT6JXb6EAqFGDLcrdXchHxTF0fAbaA@mail.gmail.com>
 <CAEBuzr-Ck=AxsuK+TtVAQ+NMjHGje0oxFCjDE8wYK6T9fHVXMQ@mail.gmail.com>
 <CAKkGBSYJ1a5vQym5Hh375jfgG+6FqcefNSMuFkEghZxSCw6LXQ@mail.gmail.com>
 <CABL7CQh-Qa7hz9UY_PCJoVdG9VQBdTd0jQOXDrdzD95L+NNUsA@mail.gmail.com>
 <CAEBuzr_crXgp+zV1SxfpphtQunGUCdOcU5wa1G_+o=izK_Ynvw@mail.gmail.com>
 <CABL7CQjUrgk8j-1r+B0m+_58jpVhLrg5c7EdhWLwEwONdJQ3nA@mail.gmail.com>
 <CAEBuzr-_45=YY81BqjoOk7341sCLxKVuvXuCh5EhtOoQ2qFt8w@mail.gmail.com>
 <CAKkGBSYQFJo5+L92xPQCoeB_OZRqDTNhXeH2-KxXLnZsxedNig@mail.gmail.com>
 <CAEBuzr-9LEDBAou=e4o+FTVdrP9YximDQtbiea-=_DZX_6R2WQ@mail.gmail.com>
 <CAB2ovovUfkv4iooQ-BWxdEuA18bmcHWof5Awzno5zDKMdcK7TQ@mail.gmail.com>
Message-ID: <CAKkGBSavyBOkZ7ZoOUXMY3nWUzecfiiL71+caUTQ9fsRC5ZKdQ@mail.gmail.com>

Attached the logo with the Google font Montserrat:
https://fonts.google.com/specimen/Montserrat?selection.family=Montserrat .
A clean, no nonsense font with thin lines (sleek and efficient) and no
slant (definitive, reliable).  A very popular font, but I guess it's
popular for a reason.

Also, I might recommend changing the color to something darker, like
#31397e , to achieve greater contrast with the white and make it more
readable.  I also have that version attached.

I hope to help in that full overhaul, hence being fairly gung-ho about the
logo right now.  It's something that could be upgraded now, then carried
over into a revamp.

Christina

On Sat, May 4, 2019 at 4:59 PM Bennet Fauber <bennet at umich.edu> wrote:

> Ilhan,
>
> I think the font and snake look fine.  Perhaps a larger margin at the
> beginning and end?  It looks to be less than an inter-word space, which is
> about what it appears to be in the SciPy.org version.
>
>
>
> On Sat, May 4, 2019 at 11:41 AM Ilhan Polat <ilhanpolat at gmail.com> wrote:
>
>> Very good suggestion. My intention was to get to a point where we are
>> ready with the recent advances with sponsorships and grant applications
>> etc. happening in the project. I think it is important to update the
>> commercial details to signal a proper message to nonPython users who would
>> probably notice these tiny details way better than we do.
>> Then we would be done with the bare essentials and can take our time with
>> the new design should we decide to do so. Hence I see this as a preparation
>> for the long term overhaul and hence the approximation. Other than that you
>> are absolutely right that this is yet another stab without a coherent
>> design brief.
>>
>> On Sat, May 4, 2019 at 2:39 PM Christina Lee <chrissie.c.l at gmail.com>
>> wrote:
>>
>>> As for the font, this also seems like a good moment to take a step back
>>> and ask "Why that font?" "What are we trying to achieve with that font?"
>>> and "Is there a better one?"
>>>
>>> Instead of just choosing a font that is an approximation of the one that
>>> has been there forever, this might be a good opportunity to choose
>>> something better.  I can take a look later on.
>>>
>>> Also, we don't need to shrink to a zero size file at the cost of
>>> something pixelated that won't make a good impression.
>>>
>>> Christina
>>>
>>> On Sat, May 4, 2019 at 11:01 AM Ilhan Polat <ilhanpolat at gmail.com>
>>> wrote:
>>>
>>>> Indeed I noticed that too but it seems like the original logo that
>>>> Stefan linked to is also thin. So there is an alternative somewhere I
>>>> guess. But I'll try to modify the curve coordinates to make it slightly
>>>> thicker.
>>>>
>>>> On Sat, May 4, 2019 at 11:09 AM Ralf Gommers <ralf.gommers at gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sat, May 4, 2019 at 10:25 AM Ilhan Polat <ilhanpolat at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> OK, before I go pixel frenzy, I'd like to ask if the following is
>>>>>> acceptable until we perform a substantial overhaul. This is the current
>>>>>> logo
>>>>>>
>>>>>> [image: image.png]
>>>>>>
>>>>>> Keeping Christina's .org remark in mind, I've selected a sane
>>>>>> approximation to our current setup and used the open source (SIL OFL 1.1)
>>>>>> font Inter https://rsms.me/inter/ and the semibold weight variant of
>>>>>> it. It has a really nice x-height hence still legible in small sizes. Also
>>>>>> as you can see it does not suffer from the kerning issues we now have. You
>>>>>> can also notice that the Logo snake has a bit less hand-drawnness to it.
>>>>>>
>>>>>> [image: image.png]
>>>>>>
>>>>>> It's the 3.4 kb version but can be reduced/optimized further. This
>>>>>> mail is just for to get feedback. Here is the draft code in case you want
>>>>>> to play around with it
>>>>>> https://gist.github.com/ilayn/d121ec7deb009a9a257b4813c80dff27 just
>>>>>> install the fonts and run it via Xe- or Lua-LaTeX.
>>>>>>
>>>>>> Please let me know if there are any
>>>>>> objections/corrections/suggestions/design crimes I might have committed.
>>>>>>
>>>>>
>>>>> Looks great, thanks for working on this! The one change I notice that
>>>>> may be a regression is how thin the snake is. A line width closer to the
>>>>> original may work a little better perhaps.
>>>>>
>>>>> Cheers,
>>>>> Ralf
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Best,
>>>>>> ilhan
>>>>>>
>>>>>>
>>>>>> On Wed, May 1, 2019 at 3:34 PM Ralf Gommers <ralf.gommers at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, May 1, 2019 at 2:50 PM Christina Lee <chrissie.c.l at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Quick question, why does it include ".org"?   Can't the logo just
>>>>>>>> say "SciPy"?
>>>>>>>>
>>>>>>>
>>>>>>> Thanks Christina, that's a great question. I can't think of a
>>>>>>> reason, just "SciPy" seems better. Perhaps we've been staring at it for so
>>>>>>> long that it's not noticeable anymore. Let's change it now.
>>>>>>>
>>>>>>>
>>>>>>>> A good rule of websites is to use svg whenever reasonable.  The
>>>>>>>> main logo isn't the only image where doing this could bump up cleanliness.
>>>>>>>> Several other logos on the main page could also use an update.  For
>>>>>>>> example, just traced over the download graphic as attached. No more
>>>>>>>> resolution problems, and smaller.
>>>>>>>>
>>>>>>>
>>>>>>> That's great, thank you! Yes, you're right ... and it's not just the
>>>>>>> logos that could use a makeover, the whole site needs attention.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Ralf
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, May 1, 2019 at 12:05 PM Ilhan Polat <ilhanpolat at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> > Would you be able to make a web-sized image and add it to
>>>>>>>>> scipy-sphinx-theme?
>>>>>>>>> Yes that's not a problem thanks to the vector graphics. The main
>>>>>>>>> concern here is the legibility of the font. I now think that the original
>>>>>>>>> font was ITC franklin medium though.
>>>>>>>>>
>>>>>>>>> Anyways, I have searched for some open source fonts in the
>>>>>>>>> meantime and many curation pages are available online; to give two results
>>>>>>>>> from a quick Google search
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://medium.com/sketch-app-sources/30-free-and-open-source-typefaces-released-recently-best-collections-5b46f9d89f65
>>>>>>>>>
>>>>>>>>> https://www.forbes.com/sites/allbusiness/2014/03/06/10-best-sans-serif-web-fonts-from-google-fonts-library/#21da8027431b
>>>>>>>>>
>>>>>>>>> I am no designer by any means hence take these as availability
>>>>>>>>> stats but we might be better off if we switch to a font with suitable
>>>>>>>>> license in place for a commercial font. Also all feedback and help are
>>>>>>>>> welcome.
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Apr 30, 2019 at 3:10 PM Ralf Gommers <
>>>>>>>>> ralf.gommers at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Thanks Stefan & Ilhan!
>>>>>>>>>>
>>>>>>>>>> Scikit-image has the right idea I think with a separate branding
>>>>>>>>>> repo. Shall we create one for SciPy as well?
>>>>>>>>>>
>>>>>>>>>> Ilhan, that looks really good! Would you be able to make a
>>>>>>>>>> web-sized image and add it to scipy-sphinx-theme? The current image is a
>>>>>>>>>> 2.4kb gif, I think it can be larger but as small as possible while still
>>>>>>>>>> looking good would be nice. Because it gets downloaded millions of times a
>>>>>>>>>> month, and also directly adds to the size of the numpy and scipy sdists.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Ralf
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Apr 29, 2019 at 10:44 PM Ilhan Polat <
>>>>>>>>>> ilhanpolat at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> By the way does anyone know what the font logo is? Just by
>>>>>>>>>>> eyeballing it looks like Franklin Gothic but I am not sure. However, if
>>>>>>>>>>> there is a more able typography connoisseur among us, here is the logo
>>>>>>>>>>> ready to be compiled by Xe/LuaLatex.
>>>>>>>>>>>
>>>>>>>>>>> \documentclass[tikz]{standalone}
>>>>>>>>>>> \usepackage{fontspec}
>>>>>>>>>>> \setsansfont{Franklin Gothic Medium}
>>>>>>>>>>> \usetikzlibrary{svg.path}
>>>>>>>>>>> \definecolor{scipylogo}{HTML}{8CAAE6}
>>>>>>>>>>>
>>>>>>>>>>> \begin{document}
>>>>>>>>>>> \begin{tikzpicture}[x=1pt, y=-1pt]
>>>>>>>>>>>
>>>>>>>>>>> \fill[scipylogo] (-50,-75) rectangle (1825, 575)
>>>>>>>>>>> svg[yscale=-1] {
>>>>>>>>>>> M348.369,282.469c-17.398-23.797-43.984-33.719-81.984-41.719
>>>>>>>>>>>
>>>>>>>>>>> l-35.334-8.332l-26.656-11.432c-14.01-9.902-25.947-36.26-22.559-59.502c5.264-36.006,38.896-61.104,75.127-56.045
>>>>>>>>>>>
>>>>>>>>>>> c18.094,2.559,33.438,12.139,43.555,25.625l40.117,52.705c22.93,29.531,48.711,38.32,76.758,24.375l14.141-6.016
>>>>>>>>>>>
>>>>>>>>>>> c1.133-0.527,2.461-0.576,3.75-0.107c1.055,0.41,1.914,1.162,2.422,2.051l2.813,4.238c0.781,1.279,1.953,2.314,3.477,2.891
>>>>>>>>>>>
>>>>>>>>>>> c2.578,0.977,5.352,0.391,7.305-1.289l32.578-30.723c5.703-4.883,4.023-9.365,4.023-9.365l-7.852-17.881
>>>>>>>>>>>
>>>>>>>>>>> c0,0-2.148-4.287-9.57-3.301l-43.672,4.014c-2.539,0.361-4.805,2.051-5.781,4.629c-0.586,1.504-0.625,3.076-0.195,4.502
>>>>>>>>>>>
>>>>>>>>>>> l1.563,5.029c0.313,1.045,0.313,2.217-0.117,3.291c-0.508,1.328-1.523,2.266-2.734,2.764l-12.344,5.225
>>>>>>>>>>>
>>>>>>>>>>> c-12.93,7.568-27.617,2.734-37.422-9.258l-11.211-14.893l-31.914-42.354c-15.156-20.098-38.008-34.434-65-38.203
>>>>>>>>>>>
>>>>>>>>>>> c-54.043-7.568-104.199,29.854-112.051,83.584c-3.965,27.08,4.152,52.703,18.965,73.281
>>>>>>>>>>>
>>>>>>>>>>> c10.762,14.953,30.486,23.496,41.154,26.164l28,8l26.814,6.145c3.688,0.875,14.063,3.438,20.203,5.656
>>>>>>>>>>>
>>>>>>>>>>> c5.676,2.055,18.75,6.875,29.375,15.57l0,0c12.695,12.906,19.414,31.344,16.563,50.68c-4.805,32.969-35.586,55.938-68.75,51.289
>>>>>>>>>>>
>>>>>>>>>>> c-16.611-2.305-30.635-11.109-39.922-23.438l-38.32-50.859c-7.813-10.367-19.629-17.773-33.594-19.766
>>>>>>>>>>>
>>>>>>>>>>> c-13.945-1.953-27.441,1.914-37.9,9.75l-80.615,60.156C11.455,333.914,0,292.898,0,249.266C0,111.621,113.926,0,254.443,0
>>>>>>>>>>>
>>>>>>>>>>> c104.629,0,194.434,61.855,233.535,150.254l12.891-5.996l8.711-23.809l9.141,3.203l-7.852,21.289l21.758,7.5l-3.281,8.916
>>>>>>>>>>>
>>>>>>>>>>> l-24.297-8.486l-13.398,6.162c11.094,27.998,17.266,58.398,17.266,90.232c0,137.656-113.945,249.258-254.473,249.258
>>>>>>>>>>>
>>>>>>>>>>> c-84.414,0-159.229-40.289-205.508-102.281l82.578-61.898c3.779-2.578,8.467-3.75,13.33-3.086
>>>>>>>>>>>
>>>>>>>>>>> c5.176,0.742,9.58,3.461,12.471,7.305l40.537,54.477c14.277,17.516,35.02,29.922,59.307,33.336
>>>>>>>>>>>
>>>>>>>>>>> c51.094,7.148,98.516-28.242,105.938-79.063C366.533,323.664,360.752,300.828,348.369,282.469};
>>>>>>>>>>>
>>>>>>>>>>> \node[anchor=east,
>>>>>>>>>>>       text=white,
>>>>>>>>>>>       font=\sffamily,
>>>>>>>>>>>       scale=30,
>>>>>>>>>>>       outer sep=0pt,
>>>>>>>>>>>       inner sep=0pt] (scipyorg) at (1750,250) {SciPy.org};
>>>>>>>>>>> \end{tikzpicture}
>>>>>>>>>>> \end{document}
>>>>>>>>>>>
>>>>>>>>>>> This code gives on my system
>>>>>>>>>>>
>>>>>>>>>>> [image: image.png]
>>>>>>>>>>>
>>>>>>>>>>> "i" and "P" needs a slight nudge to each other but that means
>>>>>>>>>>> the font is correct. Hence my question. Also you can play around and enjoy
>>>>>>>>>>> some TeX kerning/positioning/scaling bonanza yourself. I'll let Ralf to be
>>>>>>>>>>> the judge :)
>>>>>>>>>>>
>>>>>>>>>>> Best,
>>>>>>>>>>> ilhan
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Apr 29, 2019 at 8:09 PM Ilhan Polat <
>>>>>>>>>>> ilhanpolat at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Perfect! Thanks.
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Apr 29, 2019 at 7:44 PM Stefan van der Walt <
>>>>>>>>>>>> stefanv at berkeley.edu> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Found it and uploaded to GitHub:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://github.com/scikit-image/skimage-branding/blob/master/logo/scipy.svg
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, 29 Apr 2019 10:26:00 -0700, Stefan van der Walt wrote:
>>>>>>>>>>>>> > On Sat, 27 Apr 2019 23:49:03 +0200, Ralf Gommers wrote:
>>>>>>>>>>>>> > > Does anyone have the original files from which the current
>>>>>>>>>>>>> logo on scipy.org
>>>>>>>>>>>>> > > (it has the scipy symbol, white letter scipy.org and
>>>>>>>>>>>>> "sponsored by
>>>>>>>>>>>>> > > Enthough") was created? The quality is not great, and
>>>>>>>>>>>>> editing a tiny gif
>>>>>>>>>>>>> > > doesn't make it better ....
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > I don't have the vector art, but I have a higher resolution
>>>>>>>>>>>>> render:
>>>>>>>>>>>>> >
>>>>>>>>>>>>> https://github.com/scikit-image/skimage-branding/blob/master/logo/data/scipy.png
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > St?fan
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> SciPy-Dev mailing list
>>>>>>>> SciPy-Dev at python.org
>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> SciPy-Dev mailing list
>>>>>>> SciPy-Dev at python.org
>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>
>>>>>> _______________________________________________
>>>>>> SciPy-Dev mailing list
>>>>>> SciPy-Dev at python.org
>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>
>>>>> _______________________________________________
>>>>> SciPy-Dev mailing list
>>>>> SciPy-Dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at python.org
>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190504/158221c4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 32300 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190504/158221c4/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 3475 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190504/158221c4/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 2590 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190504/158221c4/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo_2.svg
Type: image/svg+xml
Size: 4921 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190504/158221c4/attachment-0002.svg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo_2_darker.svg
Type: image/svg+xml
Size: 4921 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190504/158221c4/attachment-0003.svg>

From ilhanpolat at gmail.com  Sat May  4 19:28:56 2019
From: ilhanpolat at gmail.com (Ilhan Polat)
Date: Sun, 5 May 2019 01:28:56 +0200
Subject: [SciPy-Dev] scipy.org logo original?
In-Reply-To: <CAKkGBSavyBOkZ7ZoOUXMY3nWUzecfiiL71+caUTQ9fsRC5ZKdQ@mail.gmail.com>
References: <CABL7CQi6FjoR=ekZDd+z7GoWZKJNEr3+Dh3FfTGSTh2CviyNqQ@mail.gmail.com>
 <20190429172600.tykgkl325xdygw74@carbo>
 <20190429174103.7xbkfyndweuv24ts@carbo>
 <CAEBuzr_jC9wnQKiyeojRp3C=ZcLaa9LTDHzwuS7GcitdoTbGdA@mail.gmail.com>
 <CAEBuzr9e32JUCkLii0Gu+B1+exzTsN_RAc9rKJUNn0siZaJfdA@mail.gmail.com>
 <CABL7CQgwo5ewG3g4eJ-oRT6JXb6EAqFGDLcrdXchHxTF0fAbaA@mail.gmail.com>
 <CAEBuzr-Ck=AxsuK+TtVAQ+NMjHGje0oxFCjDE8wYK6T9fHVXMQ@mail.gmail.com>
 <CAKkGBSYJ1a5vQym5Hh375jfgG+6FqcefNSMuFkEghZxSCw6LXQ@mail.gmail.com>
 <CABL7CQh-Qa7hz9UY_PCJoVdG9VQBdTd0jQOXDrdzD95L+NNUsA@mail.gmail.com>
 <CAEBuzr_crXgp+zV1SxfpphtQunGUCdOcU5wa1G_+o=izK_Ynvw@mail.gmail.com>
 <CABL7CQjUrgk8j-1r+B0m+_58jpVhLrg5c7EdhWLwEwONdJQ3nA@mail.gmail.com>
 <CAEBuzr-_45=YY81BqjoOk7341sCLxKVuvXuCh5EhtOoQ2qFt8w@mail.gmail.com>
 <CAKkGBSYQFJo5+L92xPQCoeB_OZRqDTNhXeH2-KxXLnZsxedNig@mail.gmail.com>
 <CAEBuzr-9LEDBAou=e4o+FTVdrP9YximDQtbiea-=_DZX_6R2WQ@mail.gmail.com>
 <CAB2ovovUfkv4iooQ-BWxdEuA18bmcHWof5Awzno5zDKMdcK7TQ@mail.gmail.com>
 <CAKkGBSavyBOkZ7ZoOUXMY3nWUzecfiiL71+caUTQ9fsRC5ZKdQ@mail.gmail.com>
Message-ID: <CAEBuzr_xm14P4Dq-TrB4XJQOyGiaWKQRJdRBJ-Kjm8ozjGkjkg@mail.gmail.com>

Thanks for these. Two minor points The font is indeed nice but m-width is a
bit too wide for the rest of the site. It has to fit well with the rest in
https://docs.scipy.org/doc/ hence a bit of condensation needed for
Montserrat (a bit more Maison Neue-ish) which is why I went for Inter. Also
for the color we need to again perform some surgery to the top bar as it
would sit on that bar and color change would leak to other parts of the
page to be fixed.

It is indeed popular and there are many options to choose from
https://fonts.google.com/?category=Sans+Serif&sort=popularity

But I think it's best if we survive this phase with as little modifications
as possible. That doesn't mean we need to stop working on it of course. By
all means, all contributions are highly appreciated.


On Sun, May 5, 2019 at 12:17 AM Christina Lee <chrissie.c.l at gmail.com>
wrote:

> Attached the logo with the Google font Montserrat:
> https://fonts.google.com/specimen/Montserrat?selection.family=Montserrat
> .
> A clean, no nonsense font with thin lines (sleek and efficient) and no
> slant (definitive, reliable).  A very popular font, but I guess it's
> popular for a reason.
>
> Also, I might recommend changing the color to something darker, like
> #31397e , to achieve greater contrast with the white and make it more
> readable.  I also have that version attached.
>
> I hope to help in that full overhaul, hence being fairly gung-ho about the
> logo right now.  It's something that could be upgraded now, then carried
> over into a revamp.
>
> Christina
>
> On Sat, May 4, 2019 at 4:59 PM Bennet Fauber <bennet at umich.edu> wrote:
>
>> Ilhan,
>>
>> I think the font and snake look fine.  Perhaps a larger margin at the
>> beginning and end?  It looks to be less than an inter-word space, which is
>> about what it appears to be in the SciPy.org version.
>>
>>
>>
>> On Sat, May 4, 2019 at 11:41 AM Ilhan Polat <ilhanpolat at gmail.com> wrote:
>>
>>> Very good suggestion. My intention was to get to a point where we are
>>> ready with the recent advances with sponsorships and grant applications
>>> etc. happening in the project. I think it is important to update the
>>> commercial details to signal a proper message to nonPython users who would
>>> probably notice these tiny details way better than we do.
>>> Then we would be done with the bare essentials and can take our time
>>> with the new design should we decide to do so. Hence I see this as a
>>> preparation for the long term overhaul and hence the approximation. Other
>>> than that you are absolutely right that this is yet another stab without a
>>> coherent design brief.
>>>
>>> On Sat, May 4, 2019 at 2:39 PM Christina Lee <chrissie.c.l at gmail.com>
>>> wrote:
>>>
>>>> As for the font, this also seems like a good moment to take a step back
>>>> and ask "Why that font?" "What are we trying to achieve with that font?"
>>>> and "Is there a better one?"
>>>>
>>>> Instead of just choosing a font that is an approximation of the one
>>>> that has been there forever, this might be a good opportunity to choose
>>>> something better.  I can take a look later on.
>>>>
>>>> Also, we don't need to shrink to a zero size file at the cost of
>>>> something pixelated that won't make a good impression.
>>>>
>>>> Christina
>>>>
>>>> On Sat, May 4, 2019 at 11:01 AM Ilhan Polat <ilhanpolat at gmail.com>
>>>> wrote:
>>>>
>>>>> Indeed I noticed that too but it seems like the original logo that
>>>>> Stefan linked to is also thin. So there is an alternative somewhere I
>>>>> guess. But I'll try to modify the curve coordinates to make it slightly
>>>>> thicker.
>>>>>
>>>>> On Sat, May 4, 2019 at 11:09 AM Ralf Gommers <ralf.gommers at gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, May 4, 2019 at 10:25 AM Ilhan Polat <ilhanpolat at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> OK, before I go pixel frenzy, I'd like to ask if the following is
>>>>>>> acceptable until we perform a substantial overhaul. This is the current
>>>>>>> logo
>>>>>>>
>>>>>>> [image: image.png]
>>>>>>>
>>>>>>> Keeping Christina's .org remark in mind, I've selected a sane
>>>>>>> approximation to our current setup and used the open source (SIL OFL 1.1)
>>>>>>> font Inter https://rsms.me/inter/ and the semibold weight variant
>>>>>>> of it. It has a really nice x-height hence still legible in small sizes.
>>>>>>> Also as you can see it does not suffer from the kerning issues we now have.
>>>>>>> You can also notice that the Logo snake has a bit less hand-drawnness to
>>>>>>> it.
>>>>>>>
>>>>>>> [image: image.png]
>>>>>>>
>>>>>>> It's the 3.4 kb version but can be reduced/optimized further. This
>>>>>>> mail is just for to get feedback. Here is the draft code in case you want
>>>>>>> to play around with it
>>>>>>> https://gist.github.com/ilayn/d121ec7deb009a9a257b4813c80dff27 just
>>>>>>> install the fonts and run it via Xe- or Lua-LaTeX.
>>>>>>>
>>>>>>> Please let me know if there are any
>>>>>>> objections/corrections/suggestions/design crimes I might have committed.
>>>>>>>
>>>>>>
>>>>>> Looks great, thanks for working on this! The one change I notice that
>>>>>> may be a regression is how thin the snake is. A line width closer to the
>>>>>> original may work a little better perhaps.
>>>>>>
>>>>>> Cheers,
>>>>>> Ralf
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Best,
>>>>>>> ilhan
>>>>>>>
>>>>>>>
>>>>>>> On Wed, May 1, 2019 at 3:34 PM Ralf Gommers <ralf.gommers at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, May 1, 2019 at 2:50 PM Christina Lee <
>>>>>>>> chrissie.c.l at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Quick question, why does it include ".org"?   Can't the logo just
>>>>>>>>> say "SciPy"?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks Christina, that's a great question. I can't think of a
>>>>>>>> reason, just "SciPy" seems better. Perhaps we've been staring at it for so
>>>>>>>> long that it's not noticeable anymore. Let's change it now.
>>>>>>>>
>>>>>>>>
>>>>>>>>> A good rule of websites is to use svg whenever reasonable.  The
>>>>>>>>> main logo isn't the only image where doing this could bump up cleanliness.
>>>>>>>>> Several other logos on the main page could also use an update.  For
>>>>>>>>> example, just traced over the download graphic as attached. No more
>>>>>>>>> resolution problems, and smaller.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That's great, thank you! Yes, you're right ... and it's not just
>>>>>>>> the logos that could use a makeover, the whole site needs attention.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Ralf
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, May 1, 2019 at 12:05 PM Ilhan Polat <ilhanpolat at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> > Would you be able to make a web-sized image and add it to
>>>>>>>>>> scipy-sphinx-theme?
>>>>>>>>>> Yes that's not a problem thanks to the vector graphics. The main
>>>>>>>>>> concern here is the legibility of the font. I now think that the original
>>>>>>>>>> font was ITC franklin medium though.
>>>>>>>>>>
>>>>>>>>>> Anyways, I have searched for some open source fonts in the
>>>>>>>>>> meantime and many curation pages are available online; to give two results
>>>>>>>>>> from a quick Google search
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://medium.com/sketch-app-sources/30-free-and-open-source-typefaces-released-recently-best-collections-5b46f9d89f65
>>>>>>>>>>
>>>>>>>>>> https://www.forbes.com/sites/allbusiness/2014/03/06/10-best-sans-serif-web-fonts-from-google-fonts-library/#21da8027431b
>>>>>>>>>>
>>>>>>>>>> I am no designer by any means hence take these as availability
>>>>>>>>>> stats but we might be better off if we switch to a font with suitable
>>>>>>>>>> license in place for a commercial font. Also all feedback and help are
>>>>>>>>>> welcome.
>>>>>>>>>>
>>>>>>>>>> Best,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Apr 30, 2019 at 3:10 PM Ralf Gommers <
>>>>>>>>>> ralf.gommers at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Thanks Stefan & Ilhan!
>>>>>>>>>>>
>>>>>>>>>>> Scikit-image has the right idea I think with a separate branding
>>>>>>>>>>> repo. Shall we create one for SciPy as well?
>>>>>>>>>>>
>>>>>>>>>>> Ilhan, that looks really good! Would you be able to make a
>>>>>>>>>>> web-sized image and add it to scipy-sphinx-theme? The current image is a
>>>>>>>>>>> 2.4kb gif, I think it can be larger but as small as possible while still
>>>>>>>>>>> looking good would be nice. Because it gets downloaded millions of times a
>>>>>>>>>>> month, and also directly adds to the size of the numpy and scipy sdists.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Ralf
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Apr 29, 2019 at 10:44 PM Ilhan Polat <
>>>>>>>>>>> ilhanpolat at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> By the way does anyone know what the font logo is? Just by
>>>>>>>>>>>> eyeballing it looks like Franklin Gothic but I am not sure. However, if
>>>>>>>>>>>> there is a more able typography connoisseur among us, here is the logo
>>>>>>>>>>>> ready to be compiled by Xe/LuaLatex.
>>>>>>>>>>>>
>>>>>>>>>>>> \documentclass[tikz]{standalone}
>>>>>>>>>>>> \usepackage{fontspec}
>>>>>>>>>>>> \setsansfont{Franklin Gothic Medium}
>>>>>>>>>>>> \usetikzlibrary{svg.path}
>>>>>>>>>>>> \definecolor{scipylogo}{HTML}{8CAAE6}
>>>>>>>>>>>>
>>>>>>>>>>>> \begin{document}
>>>>>>>>>>>> \begin{tikzpicture}[x=1pt, y=-1pt]
>>>>>>>>>>>>
>>>>>>>>>>>> \fill[scipylogo] (-50,-75) rectangle (1825, 575)
>>>>>>>>>>>> svg[yscale=-1] {
>>>>>>>>>>>> M348.369,282.469c-17.398-23.797-43.984-33.719-81.984-41.719
>>>>>>>>>>>>
>>>>>>>>>>>> l-35.334-8.332l-26.656-11.432c-14.01-9.902-25.947-36.26-22.559-59.502c5.264-36.006,38.896-61.104,75.127-56.045
>>>>>>>>>>>>
>>>>>>>>>>>> c18.094,2.559,33.438,12.139,43.555,25.625l40.117,52.705c22.93,29.531,48.711,38.32,76.758,24.375l14.141-6.016
>>>>>>>>>>>>
>>>>>>>>>>>> c1.133-0.527,2.461-0.576,3.75-0.107c1.055,0.41,1.914,1.162,2.422,2.051l2.813,4.238c0.781,1.279,1.953,2.314,3.477,2.891
>>>>>>>>>>>>
>>>>>>>>>>>> c2.578,0.977,5.352,0.391,7.305-1.289l32.578-30.723c5.703-4.883,4.023-9.365,4.023-9.365l-7.852-17.881
>>>>>>>>>>>>
>>>>>>>>>>>> c0,0-2.148-4.287-9.57-3.301l-43.672,4.014c-2.539,0.361-4.805,2.051-5.781,4.629c-0.586,1.504-0.625,3.076-0.195,4.502
>>>>>>>>>>>>
>>>>>>>>>>>> l1.563,5.029c0.313,1.045,0.313,2.217-0.117,3.291c-0.508,1.328-1.523,2.266-2.734,2.764l-12.344,5.225
>>>>>>>>>>>>
>>>>>>>>>>>> c-12.93,7.568-27.617,2.734-37.422-9.258l-11.211-14.893l-31.914-42.354c-15.156-20.098-38.008-34.434-65-38.203
>>>>>>>>>>>>
>>>>>>>>>>>> c-54.043-7.568-104.199,29.854-112.051,83.584c-3.965,27.08,4.152,52.703,18.965,73.281
>>>>>>>>>>>>
>>>>>>>>>>>> c10.762,14.953,30.486,23.496,41.154,26.164l28,8l26.814,6.145c3.688,0.875,14.063,3.438,20.203,5.656
>>>>>>>>>>>>
>>>>>>>>>>>> c5.676,2.055,18.75,6.875,29.375,15.57l0,0c12.695,12.906,19.414,31.344,16.563,50.68c-4.805,32.969-35.586,55.938-68.75,51.289
>>>>>>>>>>>>
>>>>>>>>>>>> c-16.611-2.305-30.635-11.109-39.922-23.438l-38.32-50.859c-7.813-10.367-19.629-17.773-33.594-19.766
>>>>>>>>>>>>
>>>>>>>>>>>> c-13.945-1.953-27.441,1.914-37.9,9.75l-80.615,60.156C11.455,333.914,0,292.898,0,249.266C0,111.621,113.926,0,254.443,0
>>>>>>>>>>>>
>>>>>>>>>>>> c104.629,0,194.434,61.855,233.535,150.254l12.891-5.996l8.711-23.809l9.141,3.203l-7.852,21.289l21.758,7.5l-3.281,8.916
>>>>>>>>>>>>
>>>>>>>>>>>> l-24.297-8.486l-13.398,6.162c11.094,27.998,17.266,58.398,17.266,90.232c0,137.656-113.945,249.258-254.473,249.258
>>>>>>>>>>>>
>>>>>>>>>>>> c-84.414,0-159.229-40.289-205.508-102.281l82.578-61.898c3.779-2.578,8.467-3.75,13.33-3.086
>>>>>>>>>>>>
>>>>>>>>>>>> c5.176,0.742,9.58,3.461,12.471,7.305l40.537,54.477c14.277,17.516,35.02,29.922,59.307,33.336
>>>>>>>>>>>>
>>>>>>>>>>>> c51.094,7.148,98.516-28.242,105.938-79.063C366.533,323.664,360.752,300.828,348.369,282.469};
>>>>>>>>>>>>
>>>>>>>>>>>> \node[anchor=east,
>>>>>>>>>>>>       text=white,
>>>>>>>>>>>>       font=\sffamily,
>>>>>>>>>>>>       scale=30,
>>>>>>>>>>>>       outer sep=0pt,
>>>>>>>>>>>>       inner sep=0pt] (scipyorg) at (1750,250) {SciPy.org};
>>>>>>>>>>>> \end{tikzpicture}
>>>>>>>>>>>> \end{document}
>>>>>>>>>>>>
>>>>>>>>>>>> This code gives on my system
>>>>>>>>>>>>
>>>>>>>>>>>> [image: image.png]
>>>>>>>>>>>>
>>>>>>>>>>>> "i" and "P" needs a slight nudge to each other but that means
>>>>>>>>>>>> the font is correct. Hence my question. Also you can play around and enjoy
>>>>>>>>>>>> some TeX kerning/positioning/scaling bonanza yourself. I'll let Ralf to be
>>>>>>>>>>>> the judge :)
>>>>>>>>>>>>
>>>>>>>>>>>> Best,
>>>>>>>>>>>> ilhan
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Apr 29, 2019 at 8:09 PM Ilhan Polat <
>>>>>>>>>>>> ilhanpolat at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Perfect! Thanks.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Apr 29, 2019 at 7:44 PM Stefan van der Walt <
>>>>>>>>>>>>> stefanv at berkeley.edu> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Found it and uploaded to GitHub:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://github.com/scikit-image/skimage-branding/blob/master/logo/scipy.svg
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, 29 Apr 2019 10:26:00 -0700, Stefan van der Walt wrote:
>>>>>>>>>>>>>> > On Sat, 27 Apr 2019 23:49:03 +0200, Ralf Gommers wrote:
>>>>>>>>>>>>>> > > Does anyone have the original files from which the
>>>>>>>>>>>>>> current logo on scipy.org
>>>>>>>>>>>>>> > > (it has the scipy symbol, white letter scipy.org and
>>>>>>>>>>>>>> "sponsored by
>>>>>>>>>>>>>> > > Enthough") was created? The quality is not great, and
>>>>>>>>>>>>>> editing a tiny gif
>>>>>>>>>>>>>> > > doesn't make it better ....
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> > I don't have the vector art, but I have a higher resolution
>>>>>>>>>>>>>> render:
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> https://github.com/scikit-image/skimage-branding/blob/master/logo/data/scipy.png
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> > St?fan
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> SciPy-Dev mailing list
>>>>>>>> SciPy-Dev at python.org
>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> SciPy-Dev mailing list
>>>>>>> SciPy-Dev at python.org
>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>
>>>>>> _______________________________________________
>>>>>> SciPy-Dev mailing list
>>>>>> SciPy-Dev at python.org
>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>
>>>>> _______________________________________________
>>>>> SciPy-Dev mailing list
>>>>> SciPy-Dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at python.org
>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190505/0de213ab/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 32300 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190505/0de213ab/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 3475 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190505/0de213ab/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 2590 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190505/0de213ab/attachment-0005.png>

From h.klemm at gmx.de  Sun May  5 04:48:07 2019
From: h.klemm at gmx.de (Hanno Klemm)
Date: Sun, 5 May 2019 10:48:07 +0200
Subject: [SciPy-Dev] scipy.org logo original?
In-Reply-To: <CAKkGBSavyBOkZ7ZoOUXMY3nWUzecfiiL71+caUTQ9fsRC5ZKdQ@mail.gmail.com>
References: <CABL7CQi6FjoR=ekZDd+z7GoWZKJNEr3+Dh3FfTGSTh2CviyNqQ@mail.gmail.com>
 <20190429172600.tykgkl325xdygw74@carbo>
 <20190429174103.7xbkfyndweuv24ts@carbo>
 <CAEBuzr_jC9wnQKiyeojRp3C=ZcLaa9LTDHzwuS7GcitdoTbGdA@mail.gmail.com>
 <CAEBuzr9e32JUCkLii0Gu+B1+exzTsN_RAc9rKJUNn0siZaJfdA@mail.gmail.com>
 <CABL7CQgwo5ewG3g4eJ-oRT6JXb6EAqFGDLcrdXchHxTF0fAbaA@mail.gmail.com>
 <CAEBuzr-Ck=AxsuK+TtVAQ+NMjHGje0oxFCjDE8wYK6T9fHVXMQ@mail.gmail.com>
 <CAKkGBSYJ1a5vQym5Hh375jfgG+6FqcefNSMuFkEghZxSCw6LXQ@mail.gmail.com>
 <CABL7CQh-Qa7hz9UY_PCJoVdG9VQBdTd0jQOXDrdzD95L+NNUsA@mail.gmail.com>
 <CAEBuzr_crXgp+zV1SxfpphtQunGUCdOcU5wa1G_+o=izK_Ynvw@mail.gmail.com>
 <CABL7CQjUrgk8j-1r+B0m+_58jpVhLrg5c7EdhWLwEwONdJQ3nA@mail.gmail.com>
 <CAEBuzr-_45=YY81BqjoOk7341sCLxKVuvXuCh5EhtOoQ2qFt8w@mail.gmail.com>
 <CAKkGBSYQFJo5+L92xPQCoeB_OZRqDTNhXeH2-KxXLnZsxedNig@mail.gmail.com>
 <CAEBuzr-9LEDBAou=e4o+FTVdrP9YximDQtbiea-=_DZX_6R2WQ@mail.gmail.com>
 <CAB2ovovUfkv4iooQ-BWxdEuA18bmcHWof5Awzno5zDKMdcK7TQ@mail.gmail.com>
 <CAKkGBSavyBOkZ7ZoOUXMY3nWUzecfiiL71+caUTQ9fsRC5ZKdQ@mail.gmail.com>
Message-ID: <58E45BA1-0BA9-4635-989F-D9DAA0725447@gmx.de>

Just a somewhat random remark on the topic:

At least on my mobile device, the attached pictures render with some generic serif font. I don?t assume that this is expected, but it might point to a problem, if the font is not very common and we consider using some formats that are vector graphics.

Hanno



> On 5. May 2019, at 00:16, Christina Lee <chrissie.c.l at gmail.com> wrote:
> 
> Attached the logo with the Google font Montserrat:  https://fonts.google.com/specimen/Montserrat?selection.family=Montserrat . 
> A clean, no nonsense font with thin lines (sleek and efficient) and no slant (definitive, reliable).  A very popular font, but I guess it's popular for a reason.
> 
> Also, I might recommend changing the color to something darker, like #31397e , to achieve greater contrast with the white and make it more readable.  I also have that version attached.
> 
> I hope to help in that full overhaul, hence being fairly gung-ho about the logo right now.  It's something that could be upgraded now, then carried over into a revamp.
> 
> Christina
> 
>> On Sat, May 4, 2019 at 4:59 PM Bennet Fauber <bennet at umich.edu> wrote:
>> Ilhan,
>> 
>> I think the font and snake look fine.  Perhaps a larger margin at the beginning and end?  It looks to be less than an inter-word space, which is about what it appears to be in the SciPy.org version.
>> 
>> 
>> 
>>> On Sat, May 4, 2019 at 11:41 AM Ilhan Polat <ilhanpolat at gmail.com> wrote:
>>> Very good suggestion. My intention was to get to a point where we are ready with the recent advances with sponsorships and grant applications etc. happening in the project. I think it is important to update the commercial details to signal a proper message to nonPython users who would probably notice these tiny details way better than we do.
>>> Then we would be done with the bare essentials and can take our time with the new design should we decide to do so. Hence I see this as a preparation for the long term overhaul and hence the approximation. Other than that you are absolutely right that this is yet another stab without a coherent design brief.
>>> 
>>>> On Sat, May 4, 2019 at 2:39 PM Christina Lee <chrissie.c.l at gmail.com> wrote:
>>>> As for the font, this also seems like a good moment to take a step back and ask "Why that font?" "What are we trying to achieve with that font?" and "Is there a better one?"
>>>> 
>>>> Instead of just choosing a font that is an approximation of the one that has been there forever, this might be a good opportunity to choose something better.  I can take a look later on.
>>>> 
>>>> Also, we don't need to shrink to a zero size file at the cost of something pixelated that won't make a good impression.
>>>> 
>>>> Christina
>>>> 
>>>>> On Sat, May 4, 2019 at 11:01 AM Ilhan Polat <ilhanpolat at gmail.com> wrote:
>>>>> Indeed I noticed that too but it seems like the original logo that Stefan linked to is also thin. So there is an alternative somewhere I guess. But I'll try to modify the curve coordinates to make it slightly thicker.
>>>>> 
>>>>>> On Sat, May 4, 2019 at 11:09 AM Ralf Gommers <ralf.gommers at gmail.com> wrote:
>>>>>> 
>>>>>> 
>>>>>>> On Sat, May 4, 2019 at 10:25 AM Ilhan Polat <ilhanpolat at gmail.com> wrote:
>>>>>>> OK, before I go pixel frenzy, I'd like to ask if the following is acceptable until we perform a substantial overhaul. This is the current logo 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Keeping Christina's .org remark in mind, I've selected a sane approximation to our current setup and used the open source (SIL OFL 1.1) font Inter https://rsms.me/inter/ and the semibold weight variant of it. It has a really nice x-height hence still legible in small sizes. Also as you can see it does not suffer from the kerning issues we now have. You can also notice that the Logo snake has a bit less hand-drawnness to it. 
>>>>>>> 
>>>>>>> <image.png>
>>>>>>> 
>>>>>>> It's the 3.4 kb version but can be reduced/optimized further. This mail is just for to get feedback. Here is the draft code in case you want to play around with it https://gist.github.com/ilayn/d121ec7deb009a9a257b4813c80dff27 just install the fonts and run it via Xe- or Lua-LaTeX. 
>>>>>>> 
>>>>>>> Please let me know if there are any objections/corrections/suggestions/design crimes I might have committed. 
>>>>>> 
>>>>>> Looks great, thanks for working on this! The one change I notice that may be a regression is how thin the snake is. A line width closer to the original may work a little better perhaps.
>>>>>> 
>>>>>> Cheers,
>>>>>> Ralf
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> Best,
>>>>>>> ilhan
>>>>>>> 
>>>>>>> 
>>>>>>>> On Wed, May 1, 2019 at 3:34 PM Ralf Gommers <ralf.gommers at gmail.com> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Wed, May 1, 2019 at 2:50 PM Christina Lee <chrissie.c.l at gmail.com> wrote:
>>>>>>>>> Quick question, why does it include ".org"?   Can't the logo just say "SciPy"?
>>>>>>>> 
>>>>>>>> Thanks Christina, that's a great question. I can't think of a reason, just "SciPy" seems better. Perhaps we've been staring at it for so long that it's not noticeable anymore. Let's change it now.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> A good rule of websites is to use svg whenever reasonable.  The main logo isn't the only image where doing this could bump up cleanliness.  Several other logos on the main page could also use an update.  For example, just traced over the download graphic as attached. No more resolution problems, and smaller.
>>>>>>>> 
>>>>>>>> That's great, thank you! Yes, you're right ... and it's not just the logos that could use a makeover, the whole site needs attention. 
>>>>>>>> 
>>>>>>>> Cheers,
>>>>>>>> Ralf
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On Wed, May 1, 2019 at 12:05 PM Ilhan Polat <ilhanpolat at gmail.com> wrote:
>>>>>>>>>> > Would you be able to make a web-sized image and add it to scipy-sphinx-theme? 
>>>>>>>>>> Yes that's not a problem thanks to the vector graphics. The main concern here is the legibility of the font. I now think that the original font was ITC franklin medium though. 
>>>>>>>>>> 
>>>>>>>>>> Anyways, I have searched for some open source fonts in the meantime and many curation pages are available online; to give two results from a quick Google search 
>>>>>>>>>> 
>>>>>>>>>> https://medium.com/sketch-app-sources/30-free-and-open-source-typefaces-released-recently-best-collections-5b46f9d89f65
>>>>>>>>>> https://www.forbes.com/sites/allbusiness/2014/03/06/10-best-sans-serif-web-fonts-from-google-fonts-library/#21da8027431b
>>>>>>>>>> 
>>>>>>>>>> I am no designer by any means hence take these as availability stats but we might be better off if we switch to a font with suitable license in place for a commercial font. Also all feedback and help are welcome. 
>>>>>>>>>> 
>>>>>>>>>> Best,
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> On Tue, Apr 30, 2019 at 3:10 PM Ralf Gommers <ralf.gommers at gmail.com> wrote:
>>>>>>>>>>> Thanks Stefan & Ilhan!
>>>>>>>>>>> 
>>>>>>>>>>> Scikit-image has the right idea I think with a separate branding repo. Shall we create one for SciPy as well?
>>>>>>>>>>> 
>>>>>>>>>>> Ilhan, that looks really good! Would you be able to make a web-sized image and add it to scipy-sphinx-theme? The current image is a 2.4kb gif, I think it can be larger but as small as possible while still looking good would be nice. Because it gets downloaded millions of times a month, and also directly adds to the size of the numpy and scipy sdists.
>>>>>>>>>>> 
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Ralf
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> On Mon, Apr 29, 2019 at 10:44 PM Ilhan Polat <ilhanpolat at gmail.com> wrote:
>>>>>>>>>>>> By the way does anyone know what the font logo is? Just by eyeballing it looks like Franklin Gothic but I am not sure. However, if there is a more able typography connoisseur among us, here is the logo ready to be compiled by Xe/LuaLatex. 
>>>>>>>>>>>> 
>>>>>>>>>>>> \documentclass[tikz]{standalone}
>>>>>>>>>>>> \usepackage{fontspec}
>>>>>>>>>>>> \setsansfont{Franklin Gothic Medium}
>>>>>>>>>>>> \usetikzlibrary{svg.path}
>>>>>>>>>>>> \definecolor{scipylogo}{HTML}{8CAAE6}
>>>>>>>>>>>> 
>>>>>>>>>>>> \begin{document}
>>>>>>>>>>>> \begin{tikzpicture}[x=1pt, y=-1pt]
>>>>>>>>>>>> 
>>>>>>>>>>>> \fill[scipylogo] (-50,-75) rectangle (1825, 575)
>>>>>>>>>>>> svg[yscale=-1] {
>>>>>>>>>>>> M348.369,282.469c-17.398-23.797-43.984-33.719-81.984-41.719
>>>>>>>>>>>> l-35.334-8.332l-26.656-11.432c-14.01-9.902-25.947-36.26-22.559-59.502c5.264-36.006,38.896-61.104,75.127-56.045
>>>>>>>>>>>> c18.094,2.559,33.438,12.139,43.555,25.625l40.117,52.705c22.93,29.531,48.711,38.32,76.758,24.375l14.141-6.016
>>>>>>>>>>>> c1.133-0.527,2.461-0.576,3.75-0.107c1.055,0.41,1.914,1.162,2.422,2.051l2.813,4.238c0.781,1.279,1.953,2.314,3.477,2.891
>>>>>>>>>>>> c2.578,0.977,5.352,0.391,7.305-1.289l32.578-30.723c5.703-4.883,4.023-9.365,4.023-9.365l-7.852-17.881
>>>>>>>>>>>> c0,0-2.148-4.287-9.57-3.301l-43.672,4.014c-2.539,0.361-4.805,2.051-5.781,4.629c-0.586,1.504-0.625,3.076-0.195,4.502
>>>>>>>>>>>> l1.563,5.029c0.313,1.045,0.313,2.217-0.117,3.291c-0.508,1.328-1.523,2.266-2.734,2.764l-12.344,5.225
>>>>>>>>>>>> c-12.93,7.568-27.617,2.734-37.422-9.258l-11.211-14.893l-31.914-42.354c-15.156-20.098-38.008-34.434-65-38.203
>>>>>>>>>>>> c-54.043-7.568-104.199,29.854-112.051,83.584c-3.965,27.08,4.152,52.703,18.965,73.281
>>>>>>>>>>>> c10.762,14.953,30.486,23.496,41.154,26.164l28,8l26.814,6.145c3.688,0.875,14.063,3.438,20.203,5.656
>>>>>>>>>>>> c5.676,2.055,18.75,6.875,29.375,15.57l0,0c12.695,12.906,19.414,31.344,16.563,50.68c-4.805,32.969-35.586,55.938-68.75,51.289
>>>>>>>>>>>> c-16.611-2.305-30.635-11.109-39.922-23.438l-38.32-50.859c-7.813-10.367-19.629-17.773-33.594-19.766
>>>>>>>>>>>> c-13.945-1.953-27.441,1.914-37.9,9.75l-80.615,60.156C11.455,333.914,0,292.898,0,249.266C0,111.621,113.926,0,254.443,0
>>>>>>>>>>>> c104.629,0,194.434,61.855,233.535,150.254l12.891-5.996l8.711-23.809l9.141,3.203l-7.852,21.289l21.758,7.5l-3.281,8.916
>>>>>>>>>>>> l-24.297-8.486l-13.398,6.162c11.094,27.998,17.266,58.398,17.266,90.232c0,137.656-113.945,249.258-254.473,249.258
>>>>>>>>>>>> c-84.414,0-159.229-40.289-205.508-102.281l82.578-61.898c3.779-2.578,8.467-3.75,13.33-3.086
>>>>>>>>>>>> c5.176,0.742,9.58,3.461,12.471,7.305l40.537,54.477c14.277,17.516,35.02,29.922,59.307,33.336
>>>>>>>>>>>> c51.094,7.148,98.516-28.242,105.938-79.063C366.533,323.664,360.752,300.828,348.369,282.469};
>>>>>>>>>>>> 
>>>>>>>>>>>> \node[anchor=east,
>>>>>>>>>>>>       text=white,
>>>>>>>>>>>>       font=\sffamily,
>>>>>>>>>>>>       scale=30,
>>>>>>>>>>>>       outer sep=0pt,
>>>>>>>>>>>>       inner sep=0pt] (scipyorg) at (1750,250) {SciPy.org};
>>>>>>>>>>>> \end{tikzpicture}
>>>>>>>>>>>> \end{document}
>>>>>>>>>>>> 
>>>>>>>>>>>> This code gives on my system 
>>>>>>>>>>>> 
>>>>>>>>>>>> <image.png>
>>>>>>>>>>>> 
>>>>>>>>>>>> "i" and "P" needs a slight nudge to each other but that means the font is correct. Hence my question. Also you can play around and enjoy some TeX kerning/positioning/scaling bonanza yourself. I'll let Ralf to be the judge :) 
>>>>>>>>>>>> 
>>>>>>>>>>>> Best,
>>>>>>>>>>>> ilhan
>>>>>>>>>>>> 
>>>>>>>>>>>>> On Mon, Apr 29, 2019 at 8:09 PM Ilhan Polat <ilhanpolat at gmail.com> wrote:
>>>>>>>>>>>>> Perfect! Thanks.
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Mon, Apr 29, 2019 at 7:44 PM Stefan van der Walt <stefanv at berkeley.edu> wrote:
>>>>>>>>>>>>>> Found it and uploaded to GitHub:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> https://github.com/scikit-image/skimage-branding/blob/master/logo/scipy.svg
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Mon, 29 Apr 2019 10:26:00 -0700, Stefan van der Walt wrote:
>>>>>>>>>>>>>> > On Sat, 27 Apr 2019 23:49:03 +0200, Ralf Gommers wrote:
>>>>>>>>>>>>>> > > Does anyone have the original files from which the current logo on scipy.org
>>>>>>>>>>>>>> > > (it has the scipy symbol, white letter scipy.org and "sponsored by
>>>>>>>>>>>>>> > > Enthough") was created? The quality is not great, and editing a tiny gif
>>>>>>>>>>>>>> > > doesn't make it better ....
>>>>>>>>>>>>>> > 
>>>>>>>>>>>>>> > I don't have the vector art, but I have a higher resolution render:
>>>>>>>>>>>>>> > https://github.com/scikit-image/skimage-branding/blob/master/logo/data/scipy.png
>>>>>>>>>>>>>> > 
>>>>>>>>>>>>>> > St?fan
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>> _______________________________________________
>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>> _______________________________________________
>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>> _______________________________________________
>>>>>>>> SciPy-Dev mailing list
>>>>>>>> SciPy-Dev at python.org
>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>> _______________________________________________
>>>>>>> SciPy-Dev mailing list
>>>>>>> SciPy-Dev at python.org
>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>> _______________________________________________
>>>>>> SciPy-Dev mailing list
>>>>>> SciPy-Dev at python.org
>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>> _______________________________________________
>>>>> SciPy-Dev mailing list
>>>>> SciPy-Dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at python.org
>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
> <logo_2.svg>
> <logo_2_darker.svg>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190505/c0698dae/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 2590 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190505/c0698dae/attachment-0001.png>

From ilhanpolat at gmail.com  Sun May  5 05:58:44 2019
From: ilhanpolat at gmail.com (Ilhan Polat)
Date: Sun, 5 May 2019 11:58:44 +0200
Subject: [SciPy-Dev] scipy.org logo original?
In-Reply-To: <58E45BA1-0BA9-4635-989F-D9DAA0725447@gmx.de>
References: <CABL7CQi6FjoR=ekZDd+z7GoWZKJNEr3+Dh3FfTGSTh2CviyNqQ@mail.gmail.com>
 <20190429172600.tykgkl325xdygw74@carbo>
 <20190429174103.7xbkfyndweuv24ts@carbo>
 <CAEBuzr_jC9wnQKiyeojRp3C=ZcLaa9LTDHzwuS7GcitdoTbGdA@mail.gmail.com>
 <CAEBuzr9e32JUCkLii0Gu+B1+exzTsN_RAc9rKJUNn0siZaJfdA@mail.gmail.com>
 <CABL7CQgwo5ewG3g4eJ-oRT6JXb6EAqFGDLcrdXchHxTF0fAbaA@mail.gmail.com>
 <CAEBuzr-Ck=AxsuK+TtVAQ+NMjHGje0oxFCjDE8wYK6T9fHVXMQ@mail.gmail.com>
 <CAKkGBSYJ1a5vQym5Hh375jfgG+6FqcefNSMuFkEghZxSCw6LXQ@mail.gmail.com>
 <CABL7CQh-Qa7hz9UY_PCJoVdG9VQBdTd0jQOXDrdzD95L+NNUsA@mail.gmail.com>
 <CAEBuzr_crXgp+zV1SxfpphtQunGUCdOcU5wa1G_+o=izK_Ynvw@mail.gmail.com>
 <CABL7CQjUrgk8j-1r+B0m+_58jpVhLrg5c7EdhWLwEwONdJQ3nA@mail.gmail.com>
 <CAEBuzr-_45=YY81BqjoOk7341sCLxKVuvXuCh5EhtOoQ2qFt8w@mail.gmail.com>
 <CAKkGBSYQFJo5+L92xPQCoeB_OZRqDTNhXeH2-KxXLnZsxedNig@mail.gmail.com>
 <CAEBuzr-9LEDBAou=e4o+FTVdrP9YximDQtbiea-=_DZX_6R2WQ@mail.gmail.com>
 <CAB2ovovUfkv4iooQ-BWxdEuA18bmcHWof5Awzno5zDKMdcK7TQ@mail.gmail.com>
 <CAKkGBSavyBOkZ7ZoOUXMY3nWUzecfiiL71+caUTQ9fsRC5ZKdQ@mail.gmail.com>
 <58E45BA1-0BA9-4635-989F-D9DAA0725447@gmx.de>
Message-ID: <CAEBuzr_-7jS+b0QxnB-XUn60j9s43RpdmM-hg8StKrSK_V07uA@mail.gmail.com>

Ah yes, that's because they are SVG files with assumed-to-be-installed font
specifications. That's a simple font embedding issue and the renderer
defaults to the most common font (the times new romanish font) when it
cannot find the font. When converted to png it won't be an issue.

On Sun, May 5, 2019 at 10:49 AM Hanno Klemm <h.klemm at gmx.de> wrote:

> Just a somewhat random remark on the topic:
>
> At least on my mobile device, the attached pictures render with some
> generic serif font. I don?t assume that this is expected, but it might
> point to a problem, if the font is not very common and we consider using
> some formats that are vector graphics.
>
> Hanno
>
>
>
> On 5. May 2019, at 00:16, Christina Lee <chrissie.c.l at gmail.com> wrote:
>
> Attached the logo with the Google font Montserrat:
> https://fonts.google.com/specimen/Montserrat?selection.family=Montserrat
> .
> A clean, no nonsense font with thin lines (sleek and efficient) and no
> slant (definitive, reliable).  A very popular font, but I guess it's
> popular for a reason.
>
> Also, I might recommend changing the color to something darker, like
> #31397e , to achieve greater contrast with the white and make it more
> readable.  I also have that version attached.
>
> I hope to help in that full overhaul, hence being fairly gung-ho about the
> logo right now.  It's something that could be upgraded now, then carried
> over into a revamp.
>
> Christina
>
> On Sat, May 4, 2019 at 4:59 PM Bennet Fauber <bennet at umich.edu> wrote:
>
>> Ilhan,
>>
>> I think the font and snake look fine.  Perhaps a larger margin at the
>> beginning and end?  It looks to be less than an inter-word space, which is
>> about what it appears to be in the SciPy.org version.
>>
>>
>>
>> On Sat, May 4, 2019 at 11:41 AM Ilhan Polat <ilhanpolat at gmail.com> wrote:
>>
>>> Very good suggestion. My intention was to get to a point where we are
>>> ready with the recent advances with sponsorships and grant applications
>>> etc. happening in the project. I think it is important to update the
>>> commercial details to signal a proper message to nonPython users who would
>>> probably notice these tiny details way better than we do.
>>> Then we would be done with the bare essentials and can take our time
>>> with the new design should we decide to do so. Hence I see this as a
>>> preparation for the long term overhaul and hence the approximation. Other
>>> than that you are absolutely right that this is yet another stab without a
>>> coherent design brief.
>>>
>>> On Sat, May 4, 2019 at 2:39 PM Christina Lee <chrissie.c.l at gmail.com>
>>> wrote:
>>>
>>>> As for the font, this also seems like a good moment to take a step back
>>>> and ask "Why that font?" "What are we trying to achieve with that font?"
>>>> and "Is there a better one?"
>>>>
>>>> Instead of just choosing a font that is an approximation of the one
>>>> that has been there forever, this might be a good opportunity to choose
>>>> something better.  I can take a look later on.
>>>>
>>>> Also, we don't need to shrink to a zero size file at the cost of
>>>> something pixelated that won't make a good impression.
>>>>
>>>> Christina
>>>>
>>>> On Sat, May 4, 2019 at 11:01 AM Ilhan Polat <ilhanpolat at gmail.com>
>>>> wrote:
>>>>
>>>>> Indeed I noticed that too but it seems like the original logo that
>>>>> Stefan linked to is also thin. So there is an alternative somewhere I
>>>>> guess. But I'll try to modify the curve coordinates to make it slightly
>>>>> thicker.
>>>>>
>>>>> On Sat, May 4, 2019 at 11:09 AM Ralf Gommers <ralf.gommers at gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, May 4, 2019 at 10:25 AM Ilhan Polat <ilhanpolat at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> OK, before I go pixel frenzy, I'd like to ask if the following is
>>>>>>> acceptable until we perform a substantial overhaul. This is the current
>>>>>>> logo
>>>>>>>
>>>>>>> [image: image.png]
>>>>>>>
>>>>>>> Keeping Christina's .org remark in mind, I've selected a sane
>>>>>>> approximation to our current setup and used the open source (SIL OFL 1.1)
>>>>>>> font Inter https://rsms.me/inter/ and the semibold weight variant
>>>>>>> of it. It has a really nice x-height hence still legible in small sizes.
>>>>>>> Also as you can see it does not suffer from the kerning issues we now have.
>>>>>>> You can also notice that the Logo snake has a bit less hand-drawnness to
>>>>>>> it.
>>>>>>>
>>>>>>> <image.png>
>>>>>>>
>>>>>>> It's the 3.4 kb version but can be reduced/optimized further. This
>>>>>>> mail is just for to get feedback. Here is the draft code in case you want
>>>>>>> to play around with it
>>>>>>> https://gist.github.com/ilayn/d121ec7deb009a9a257b4813c80dff27 just
>>>>>>> install the fonts and run it via Xe- or Lua-LaTeX.
>>>>>>>
>>>>>>> Please let me know if there are any
>>>>>>> objections/corrections/suggestions/design crimes I might have committed.
>>>>>>>
>>>>>>
>>>>>> Looks great, thanks for working on this! The one change I notice that
>>>>>> may be a regression is how thin the snake is. A line width closer to the
>>>>>> original may work a little better perhaps.
>>>>>>
>>>>>> Cheers,
>>>>>> Ralf
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Best,
>>>>>>> ilhan
>>>>>>>
>>>>>>>
>>>>>>> On Wed, May 1, 2019 at 3:34 PM Ralf Gommers <ralf.gommers at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, May 1, 2019 at 2:50 PM Christina Lee <
>>>>>>>> chrissie.c.l at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Quick question, why does it include ".org"?   Can't the logo just
>>>>>>>>> say "SciPy"?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks Christina, that's a great question. I can't think of a
>>>>>>>> reason, just "SciPy" seems better. Perhaps we've been staring at it for so
>>>>>>>> long that it's not noticeable anymore. Let's change it now.
>>>>>>>>
>>>>>>>>
>>>>>>>>> A good rule of websites is to use svg whenever reasonable.  The
>>>>>>>>> main logo isn't the only image where doing this could bump up cleanliness.
>>>>>>>>> Several other logos on the main page could also use an update.  For
>>>>>>>>> example, just traced over the download graphic as attached. No more
>>>>>>>>> resolution problems, and smaller.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That's great, thank you! Yes, you're right ... and it's not just
>>>>>>>> the logos that could use a makeover, the whole site needs attention.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Ralf
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, May 1, 2019 at 12:05 PM Ilhan Polat <ilhanpolat at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> > Would you be able to make a web-sized image and add it to
>>>>>>>>>> scipy-sphinx-theme?
>>>>>>>>>> Yes that's not a problem thanks to the vector graphics. The main
>>>>>>>>>> concern here is the legibility of the font. I now think that the original
>>>>>>>>>> font was ITC franklin medium though.
>>>>>>>>>>
>>>>>>>>>> Anyways, I have searched for some open source fonts in the
>>>>>>>>>> meantime and many curation pages are available online; to give two results
>>>>>>>>>> from a quick Google search
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://medium.com/sketch-app-sources/30-free-and-open-source-typefaces-released-recently-best-collections-5b46f9d89f65
>>>>>>>>>>
>>>>>>>>>> https://www.forbes.com/sites/allbusiness/2014/03/06/10-best-sans-serif-web-fonts-from-google-fonts-library/#21da8027431b
>>>>>>>>>>
>>>>>>>>>> I am no designer by any means hence take these as availability
>>>>>>>>>> stats but we might be better off if we switch to a font with suitable
>>>>>>>>>> license in place for a commercial font. Also all feedback and help are
>>>>>>>>>> welcome.
>>>>>>>>>>
>>>>>>>>>> Best,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Apr 30, 2019 at 3:10 PM Ralf Gommers <
>>>>>>>>>> ralf.gommers at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Thanks Stefan & Ilhan!
>>>>>>>>>>>
>>>>>>>>>>> Scikit-image has the right idea I think with a separate branding
>>>>>>>>>>> repo. Shall we create one for SciPy as well?
>>>>>>>>>>>
>>>>>>>>>>> Ilhan, that looks really good! Would you be able to make a
>>>>>>>>>>> web-sized image and add it to scipy-sphinx-theme? The current image is a
>>>>>>>>>>> 2.4kb gif, I think it can be larger but as small as possible while still
>>>>>>>>>>> looking good would be nice. Because it gets downloaded millions of times a
>>>>>>>>>>> month, and also directly adds to the size of the numpy and scipy sdists.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Ralf
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Apr 29, 2019 at 10:44 PM Ilhan Polat <
>>>>>>>>>>> ilhanpolat at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> By the way does anyone know what the font logo is? Just by
>>>>>>>>>>>> eyeballing it looks like Franklin Gothic but I am not sure. However, if
>>>>>>>>>>>> there is a more able typography connoisseur among us, here is the logo
>>>>>>>>>>>> ready to be compiled by Xe/LuaLatex.
>>>>>>>>>>>>
>>>>>>>>>>>> \documentclass[tikz]{standalone}
>>>>>>>>>>>> \usepackage{fontspec}
>>>>>>>>>>>> \setsansfont{Franklin Gothic Medium}
>>>>>>>>>>>> \usetikzlibrary{svg.path}
>>>>>>>>>>>> \definecolor{scipylogo}{HTML}{8CAAE6}
>>>>>>>>>>>>
>>>>>>>>>>>> \begin{document}
>>>>>>>>>>>> \begin{tikzpicture}[x=1pt, y=-1pt]
>>>>>>>>>>>>
>>>>>>>>>>>> \fill[scipylogo] (-50,-75) rectangle (1825, 575)
>>>>>>>>>>>> svg[yscale=-1] {
>>>>>>>>>>>> M348.369,282.469c-17.398-23.797-43.984-33.719-81.984-41.719
>>>>>>>>>>>>
>>>>>>>>>>>> l-35.334-8.332l-26.656-11.432c-14.01-9.902-25.947-36.26-22.559-59.502c5.264-36.006,38.896-61.104,75.127-56.045
>>>>>>>>>>>>
>>>>>>>>>>>> c18.094,2.559,33.438,12.139,43.555,25.625l40.117,52.705c22.93,29.531,48.711,38.32,76.758,24.375l14.141-6.016
>>>>>>>>>>>>
>>>>>>>>>>>> c1.133-0.527,2.461-0.576,3.75-0.107c1.055,0.41,1.914,1.162,2.422,2.051l2.813,4.238c0.781,1.279,1.953,2.314,3.477,2.891
>>>>>>>>>>>>
>>>>>>>>>>>> c2.578,0.977,5.352,0.391,7.305-1.289l32.578-30.723c5.703-4.883,4.023-9.365,4.023-9.365l-7.852-17.881
>>>>>>>>>>>>
>>>>>>>>>>>> c0,0-2.148-4.287-9.57-3.301l-43.672,4.014c-2.539,0.361-4.805,2.051-5.781,4.629c-0.586,1.504-0.625,3.076-0.195,4.502
>>>>>>>>>>>>
>>>>>>>>>>>> l1.563,5.029c0.313,1.045,0.313,2.217-0.117,3.291c-0.508,1.328-1.523,2.266-2.734,2.764l-12.344,5.225
>>>>>>>>>>>>
>>>>>>>>>>>> c-12.93,7.568-27.617,2.734-37.422-9.258l-11.211-14.893l-31.914-42.354c-15.156-20.098-38.008-34.434-65-38.203
>>>>>>>>>>>>
>>>>>>>>>>>> c-54.043-7.568-104.199,29.854-112.051,83.584c-3.965,27.08,4.152,52.703,18.965,73.281
>>>>>>>>>>>>
>>>>>>>>>>>> c10.762,14.953,30.486,23.496,41.154,26.164l28,8l26.814,6.145c3.688,0.875,14.063,3.438,20.203,5.656
>>>>>>>>>>>>
>>>>>>>>>>>> c5.676,2.055,18.75,6.875,29.375,15.57l0,0c12.695,12.906,19.414,31.344,16.563,50.68c-4.805,32.969-35.586,55.938-68.75,51.289
>>>>>>>>>>>>
>>>>>>>>>>>> c-16.611-2.305-30.635-11.109-39.922-23.438l-38.32-50.859c-7.813-10.367-19.629-17.773-33.594-19.766
>>>>>>>>>>>>
>>>>>>>>>>>> c-13.945-1.953-27.441,1.914-37.9,9.75l-80.615,60.156C11.455,333.914,0,292.898,0,249.266C0,111.621,113.926,0,254.443,0
>>>>>>>>>>>>
>>>>>>>>>>>> c104.629,0,194.434,61.855,233.535,150.254l12.891-5.996l8.711-23.809l9.141,3.203l-7.852,21.289l21.758,7.5l-3.281,8.916
>>>>>>>>>>>>
>>>>>>>>>>>> l-24.297-8.486l-13.398,6.162c11.094,27.998,17.266,58.398,17.266,90.232c0,137.656-113.945,249.258-254.473,249.258
>>>>>>>>>>>>
>>>>>>>>>>>> c-84.414,0-159.229-40.289-205.508-102.281l82.578-61.898c3.779-2.578,8.467-3.75,13.33-3.086
>>>>>>>>>>>>
>>>>>>>>>>>> c5.176,0.742,9.58,3.461,12.471,7.305l40.537,54.477c14.277,17.516,35.02,29.922,59.307,33.336
>>>>>>>>>>>>
>>>>>>>>>>>> c51.094,7.148,98.516-28.242,105.938-79.063C366.533,323.664,360.752,300.828,348.369,282.469};
>>>>>>>>>>>>
>>>>>>>>>>>> \node[anchor=east,
>>>>>>>>>>>>       text=white,
>>>>>>>>>>>>       font=\sffamily,
>>>>>>>>>>>>       scale=30,
>>>>>>>>>>>>       outer sep=0pt,
>>>>>>>>>>>>       inner sep=0pt] (scipyorg) at (1750,250) {SciPy.org};
>>>>>>>>>>>> \end{tikzpicture}
>>>>>>>>>>>> \end{document}
>>>>>>>>>>>>
>>>>>>>>>>>> This code gives on my system
>>>>>>>>>>>>
>>>>>>>>>>>> <image.png>
>>>>>>>>>>>>
>>>>>>>>>>>> "i" and "P" needs a slight nudge to each other but that means
>>>>>>>>>>>> the font is correct. Hence my question. Also you can play around and enjoy
>>>>>>>>>>>> some TeX kerning/positioning/scaling bonanza yourself. I'll let Ralf to be
>>>>>>>>>>>> the judge :)
>>>>>>>>>>>>
>>>>>>>>>>>> Best,
>>>>>>>>>>>> ilhan
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Apr 29, 2019 at 8:09 PM Ilhan Polat <
>>>>>>>>>>>> ilhanpolat at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Perfect! Thanks.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Apr 29, 2019 at 7:44 PM Stefan van der Walt <
>>>>>>>>>>>>> stefanv at berkeley.edu> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Found it and uploaded to GitHub:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://github.com/scikit-image/skimage-branding/blob/master/logo/scipy.svg
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, 29 Apr 2019 10:26:00 -0700, Stefan van der Walt wrote:
>>>>>>>>>>>>>> > On Sat, 27 Apr 2019 23:49:03 +0200, Ralf Gommers wrote:
>>>>>>>>>>>>>> > > Does anyone have the original files from which the
>>>>>>>>>>>>>> current logo on scipy.org
>>>>>>>>>>>>>> > > (it has the scipy symbol, white letter scipy.org and
>>>>>>>>>>>>>> "sponsored by
>>>>>>>>>>>>>> > > Enthough") was created? The quality is not great, and
>>>>>>>>>>>>>> editing a tiny gif
>>>>>>>>>>>>>> > > doesn't make it better ....
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> > I don't have the vector art, but I have a higher resolution
>>>>>>>>>>>>>> render:
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> https://github.com/scikit-image/skimage-branding/blob/master/logo/data/scipy.png
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> > St?fan
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> SciPy-Dev mailing list
>>>>>>>>> SciPy-Dev at python.org
>>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> SciPy-Dev mailing list
>>>>>>>> SciPy-Dev at python.org
>>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> SciPy-Dev mailing list
>>>>>>> SciPy-Dev at python.org
>>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>>
>>>>>> _______________________________________________
>>>>>> SciPy-Dev mailing list
>>>>>> SciPy-Dev at python.org
>>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>>
>>>>> _______________________________________________
>>>>> SciPy-Dev mailing list
>>>>> SciPy-Dev at python.org
>>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>>
>>>> _______________________________________________
>>>> SciPy-Dev mailing list
>>>> SciPy-Dev at python.org
>>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> <logo_2.svg>
>
> <logo_2_darker.svg>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190505/2a3fdf1d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 2590 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190505/2a3fdf1d/attachment-0001.png>

From serge.guelton at telecom-bretagne.eu  Sun May  5 16:00:17 2019
From: serge.guelton at telecom-bretagne.eu (Serge Guelton)
Date: Sun, 5 May 2019 22:00:17 +0200
Subject: [SciPy-Dev] Pythran 0.9.2 - koailh
Message-ID: <20190505200017.GA11791@sguelton.remote.csb>

Hi folks, and sorry for the double posting if any.

It's my great pleasure to announce the release of Pythran 0.9.2, codenamed koailh.

Pythran is an ahead of time compiler for scientific kernels written in Python. It is
backward-compatible with Python (no language extension) and can take advantage of
OpenMP annotations and automatic SIMD instruction generation.

It's been more than four months since last release, so there's quite a lot of changes.
The detailed changelog is available online:

    https://pythran.readthedocs.io/en/latest/
    
Notable Changes
===============

In addition to bugfixes and new function support, the most significant changes are the
support of a special notation to describe optional argument in Pythran annotations:

    #pythran export foo(int, int?)

This notation is equivalent to:

    #pythran export foo(int)
    #pythran export foo(int, int)
    
This release also introduces a new dependency on the beniget package that provides use-def
chains construction for Python code:

    https://github.com/serge-sans-paille/beniget

A significant memory leak when converting extended slice from pythran to python has been
spoted and fixed.

In total, a great deal of 43 issues have been closed!

    https://github.com/serge-sans-paille/pythran/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aclosed+closed%3A%3E2019-01-20+

Sample Code
===========

As usual, I like to demonstrate Pythran through a small benchmark that used to be unsupported
and now provides a nice x6 speedup (without xsimd) up to (with xsimd, non-strided version) over
Python reference:

    import numpy as np
    #pythran export f_dist(float64[:,:], float64[:,:])
    #pythran export f_dist(float64[::,::], float64[::,::])
    def f_dist(X1, X2):
        return np.sum(np.abs(X1[:, None, :] - X2), axis=-1)

(from https://stackoverflow.com/questions/55854611/efficient-way-of-vectorizing-distance-calculation/)

Download
========

You can retrieve the package through PyPI:

    https://pypi.org/project/pythran/

Download the source on GitHub:

    https://github.com/serge-sans-paille/pythran

Or using the conda package, now available for Windows in addition to Linux and OSX through conda-forge

    https://anaconda.org/conda-forge/pythran

Thanks
======

The following people have contributed to this version, through bug reports or commits, in no
particular order:

- Yann Diorcet
- Neal Becker
- Ashwin Vishnu 
- David Men?ndez Hurtado
- Jean Laroche
- Anubhab Haldar
- Thierry Dumont
- "keke ge-smile"
- "garanews"
- Said Hadjout
- Rodrigo Iga
- Pierrick Brunet
- Franck Cornevaux-Juignet

Special thoughts to these last two, they reported bugs in 2013 and 2014, and the associated
fixes only happened in 2019 ^^!

Contribute
==========

If you've been brave enough to read this whole mail, the next step is to support Pythran!
You can donate your time through bug reports and fixes, give a small motivation boost through
a gentle email, or just use it and share the joy.

If you need important development in Pythran, you can drive the roadmap! Send an email to the
mailing list (or to my personnal email if you're too shy).

++
Serge



From PeterBell10 at live.co.uk  Wed May  8 11:50:07 2019
From: PeterBell10 at live.co.uk (Peter Bell)
Date: Wed, 8 May 2019 15:50:07 +0000
Subject: [SciPy-Dev] Backend support for fftpack - GSoC 2019
Message-ID: <DB6PR04MB320650B383909FE340B38EEF8E320@DB6PR04MB3206.eurprd04.prod.outlook.com>

Hello all,

I'm happy to say my GSoC proposal was accepted, so I'll be working over the summer to add support for multiple fftpack backends. For those interested, I've extracted the main discussion from my proposal which you can read here:
https://docs.google.com/document/d/1hGMc6ZrsmSi_LSixI5oFbo5cZkPUo92sfmnVthg1u6Y/edit

There are a several design decisions I raise in the proposal and any comments would be appreciated. Of particular note:
* Should backends be allowed to add functionality or should they be completely interchangeable. E.g. unlike fftpack, FFTW has support for long doubles; should this be exposed to SciPy users?
* Is there any interest in adding a SciPy config file? For just one option it's probably not worthwhile but if there is interest in more config options then it starts to make more sense.

Ideally a clear set of design goals can be agreed upon now, before it gets too far into the coding period which begins at the end of the month.

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

From ralf.gommers at gmail.com  Wed May  8 18:59:14 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Thu, 9 May 2019 00:59:14 +0200
Subject: [SciPy-Dev] Backend support for fftpack - GSoC 2019
In-Reply-To: <DB6PR04MB320650B383909FE340B38EEF8E320@DB6PR04MB3206.eurprd04.prod.outlook.com>
References: <DB6PR04MB320650B383909FE340B38EEF8E320@DB6PR04MB3206.eurprd04.prod.outlook.com>
Message-ID: <CABL7CQhuH_N=fJBG8mUVfjTELZfup=xunNGrjuNWohjkfBoPOg@mail.gmail.com>

On Wed, May 8, 2019 at 5:50 PM Peter Bell <PeterBell10 at live.co.uk> wrote:

> Hello all,
>
>
>
> I?m happy to say my GSoC proposal was accepted,
>

Hey Peter, congratulations! We're happy to have you on board!

so I?ll be working over the summer to add support for multiple fftpack
> backends. For those interested, I?ve extracted the main discussion from my
> proposal which you can read here:
>
>
> https://docs.google.com/document/d/1hGMc6ZrsmSi_LSixI5oFbo5cZkPUo92sfmnVthg1u6Y/edit
>

Thanks, interesting. Will take a little while to process. I just give some
very initial thoughts below (so take with a grain of salt).


>
> There are a several design decisions I raise in the proposal and any
> comments would be appreciated. Of particular note:
>
> * Should backends be allowed to add functionality or should they be
> completely interchangeable. E.g. unlike fftpack, FFTW has support for long
> doubles; should this be exposed to SciPy users?
>

If a user writes backend-specific code, then they may just as well bypass
the backend right, and call the other library directly? Although for long
double things will work out of the box perhaps, because the dtype of an
input array doesn't come back in the API. So the array can be passed
straight to the backend.


> * Is there any interest in adding a SciPy config file? For just one option
> it?s probably not worthwhile but if there is interest in more config
> options then it starts to make more sense.
>

My sense is no. Something like a context manager (`with
backend('pyfftw'):`) is lightweight enough probably.

This is probably also a good time to point out http://uarray.readthedocs.io/.
It can provide a complete backend system without too much work, it was
designed exactly for the type of problem you're trying to solve here. Would
be good to have your thoughts on that.


>
> Ideally a clear set of design goals can be agreed upon now, before it gets
> too far into the coding period which begins at the end of the month.
>

Yes great idea.

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

From warren.weckesser at gmail.com  Wed May  8 21:38:55 2019
From: warren.weckesser at gmail.com (Warren Weckesser)
Date: Wed, 8 May 2019 21:38:55 -0400
Subject: [SciPy-Dev] mpsci: a repository of mpmath-based functions
Message-ID: <CAGzF1uds27Ch8wkMebXBvwEh4gtQoUbhBMdSZY6084XWC+5WsQ@mail.gmail.com>

Hey all,

When testing SciPy code, I often reimplement a function using mpmath
for the calculations as a way to find accurate "true" values to use in
SciPy unit tests.  I've taken my collection of mpmath-based functions
and put them together into a repository called 'mpsci'.  The github
repository is

    https://github.com/WarrenWeckesser/mpsci

and the rendered documentation is at

    https://warrenweckesser.github.io/mpsci/

Given the motivation for this project, the collection is somewhat
random and sparse.  I'm certainly not planning on attempting to
replicate all of SciPy.  But as I work on new functions or improve old
ones, it is likely that an mpmath-based version of the function will
end up in mpsci.

Comments, critiques, and contributions are welcome.

Warren

From PeterBell10 at live.co.uk  Thu May  9 08:25:43 2019
From: PeterBell10 at live.co.uk (Peter Bell)
Date: Thu, 9 May 2019 12:25:43 +0000
Subject: [SciPy-Dev] Backend support for fftpack - GSoC 2019
In-Reply-To: <CABL7CQhuH_N=fJBG8mUVfjTELZfup=xunNGrjuNWohjkfBoPOg@mail.gmail.com>
References: <DB6PR04MB320650B383909FE340B38EEF8E320@DB6PR04MB3206.eurprd04.prod.outlook.com>
 <CABL7CQhuH_N=fJBG8mUVfjTELZfup=xunNGrjuNWohjkfBoPOg@mail.gmail.com>
Message-ID: <DB6PR04MB32067A2161BCDE87FA64EECE8E330@DB6PR04MB3206.eurprd04.prod.outlook.com>

>> Should backends be allowed to add functionality or should they be completely
>> interchangeable. E.g. unlike fftpack, FFTW has support for long doubles;
>> should this be exposed to SciPy users?
>
> If a user writes backend-specific code, then they may just as well bypass the
> backend right, and call the other library directly?

I agree, in fact I quote you in the proposal saying something similar.

> Although for long double things will work out of the box perhaps, because the
> dtype of an input array doesn't come back in the API. So the array can be
> passed straight to the backend.

This was why I picked it as an example. It doesn't add any new parameters or
change the function signature at all, but it does change the result of a
particular call to the API. So it's a very minimal change yet it still breaks
the interchangeability of backends.
> This is probably also a good time to point out http://uarray.readthedocs.io/.
> It can provide a complete backend system without too much work

After reading through the docs it does seem to cover this and more. However, it
also seems to be unstable at this point so I?m not sure it?s wise to rely on it just
yet.

> it was designed exactly for the type of problem you're trying to solve here.

Unless I'm misunderstanding it seems to be more focused on supporting different
types of array, rather than different implementations for NumPy arrays. I can't
see any utility in having a complicated dispatch mechanism when we really only
want to have a single backend at a time for any given function.

I would assume that because of this, uarray would come with a greater
performance overhead. Whereas I think the overhead of an fftpack backend should
just be some argument validation and a single function call. I could always
implement it both ways and benchmark it if there's interest.

Peter

From: SciPy-Dev <scipy-dev-bounces+peterbell10=live.co.uk at python.org> On Behalf Of Ralf Gommers
Sent: 08 May 2019 23:59
To: SciPy Developers List <scipy-dev at python.org>
Subject: Re: [SciPy-Dev] Backend support for fftpack - GSoC 2019



On Wed, May 8, 2019 at 5:50 PM Peter Bell <PeterBell10 at live.co.uk<mailto:PeterBell10 at live.co.uk>> wrote:
Hello all,

I?m happy to say my GSoC proposal was accepted,

Hey Peter, congratulations! We're happy to have you on board!

so I?ll be working over the summer to add support for multiple fftpack backends. For those interested, I?ve extracted the main discussion from my proposal which you can read here:
https://docs.google.com/document/d/1hGMc6ZrsmSi_LSixI5oFbo5cZkPUo92sfmnVthg1u6Y/edit

Thanks, interesting. Will take a little while to process. I just give some very initial thoughts below (so take with a grain of salt).


There are a several design decisions I raise in the proposal and any comments would be appreciated. Of particular note:
* Should backends be allowed to add functionality or should they be completely interchangeable. E.g. unlike fftpack, FFTW has support for long doubles; should this be exposed to SciPy users?

If a user writes backend-specific code, then they may just as well bypass the backend right, and call the other library directly? Although for long double things will work out of the box perhaps, because the dtype of an input array doesn't come back in the API. So the array can be passed straight to the backend.

* Is there any interest in adding a SciPy config file? For just one option it?s probably not worthwhile but if there is interest in more config options then it starts to make more sense.

My sense is no. Something like a context manager (`with backend('pyfftw'):`) is lightweight enough probably.

This is probably also a good time to point out http://uarray.readthedocs.io/. It can provide a complete backend system without too much work, it was designed exactly for the type of problem you're trying to solve here. Would be good to have your thoughts on that.


Ideally a clear set of design goals can be agreed upon now, before it gets too far into the coding period which begins at the end of the month.

Yes great idea.

Cheers,
Ralf

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

From einstein.edison at gmail.com  Thu May  9 08:38:55 2019
From: einstein.edison at gmail.com (Hameer Abbasi)
Date: Thu, 9 May 2019 08:38:55 -0400
Subject: [SciPy-Dev] Backend support for fftpack - GSoC 2019
In-Reply-To: <DB6PR04MB32067A2161BCDE87FA64EECE8E330@DB6PR04MB3206.eurprd04.prod.outlook.com>
References: <DB6PR04MB320650B383909FE340B38EEF8E320@DB6PR04MB3206.eurprd04.prod.outlook.com>
 <CABL7CQhuH_N=fJBG8mUVfjTELZfup=xunNGrjuNWohjkfBoPOg@mail.gmail.com>
 <DB6PR04MB32067A2161BCDE87FA64EECE8E330@DB6PR04MB3206.eurprd04.prod.outlook.com>
Message-ID: <d43d568d-1813-41f8-8360-9a27abd325ed@Canary>

Hi,

Since uarray came up: I?m the author. Yes, performance is slow (since it?s pure python) but the API is stable at this point (the docs are a bit out of date, I should update them).

We?re welcoming any kind of contributions as I, myself, am not familiar enough with the CPython API to do it. However, I?d love to learn!

It does have a focus on array computing but it is meant to be fairly general, and you shouldn?t have any problems with the interface.

Best Regards,
Hameer Abbasi

> On Thursday, May 09, 2019 at 8:25 AM, Peter Bell <PeterBell10 at live.co.uk (mailto:PeterBell10 at live.co.uk)> wrote:
>
> >> Should backends be allowed to add functionality or should they be completely
>
>
> >> interchangeable. E.g. unlike fftpack, FFTW has support for long doubles;
>
>
> >> should this be exposed to SciPy users?
>
>
> >
>
>
> > If a user writes backend-specific code, then they may just as well bypass the
>
>
> > backend right, and call the other library directly?
>
>
>
>
>
> I agree, in fact I quote you in the proposal saying something similar.
>
>
>
>
>
> > Although for long double things will work out of the box perhaps, because the
>
>
> > dtype of an input array doesn't come back in the API. So the array can be
>
>
> > passed straight to the backend.
>
>
>
>
>
> This was why I picked it as an example. It doesn't add any new parameters or
>
>
> change the function signature at all, but it does change the result of a
>
>
> particular call to the API. So it's a very minimal change yet it still breaks
>
>
> the interchangeability of backends.
>
>
>
>
>
> > This is probably also a good time to point out http://uarray.readthedocs.io/.
>
>
> > It can provide a complete backend system without too much work
>
>
>
>
>
> After reading through the docs it does seem to cover this and more. However, it
>
>
> also seems to be unstable at this point so I?m not sure it?s wise to rely on it just
>
>
> yet.
>
>
>
>
>
> > it was designed exactly for the type of problem you're trying to solve here.
>
>
>
>
>
> Unless I'm misunderstanding it seems to be more focused on supporting different
>
>
> types of array, rather than different implementations for NumPy arrays. I can't
>
>
> see any utility in having a complicated dispatch mechanism when we really only
>
>
> want to have a single backend at a time for any given function.
>
>
>
>
>
> I would assume that because of this, uarray would come with a greater
>
>
> performance overhead. Whereas I think the overhead of an fftpack backend should
>
>
> just be some argument validation and a single function call. I could always
>
>
> implement it both ways and benchmark it if there's interest.
>
>
>
>
>
> Peter
>
>
>
>
>
> From: SciPy-Dev <scipy-dev-bounces+peterbell10=live.co.uk at python.org> On Behalf Of Ralf Gommers
> Sent: 08 May 2019 23:59
> To: SciPy Developers List <scipy-dev at python.org>
> Subject: Re: [SciPy-Dev] Backend support for fftpack - GSoC 2019
>
>
>
>
>
>
>
>
>
>
>
>
> On Wed, May 8, 2019 at 5:50 PM Peter Bell <PeterBell10 at live.co.uk (mailto:PeterBell10 at live.co.uk)> wrote:
>
>
> >
> > Hello all,
> >
> >
> >
> >
> >
> > I?m happy to say my GSoC proposal was accepted,
> >
> >
> >
>
>
>
>
>
>
> Hey Peter, congratulations! We're happy to have you on board!
>
>
>
>
>
>
> >
> > so I?ll be working over the summer to add support for multiple fftpack backends. For those interested, I?ve extracted the main discussion from my proposal which you can read here:
> >
> >
> > https://docs.google.com/document/d/1hGMc6ZrsmSi_LSixI5oFbo5cZkPUo92sfmnVthg1u6Y/edit
> >
> >
> >
>
>
>
>
>
>
> Thanks, interesting. Will take a little while to process. I just give some very initial thoughts below (so take with a grain of salt).
>
>
>
>
>
>
> >
> >
> >
> >
> > There are a several design decisions I raise in the proposal and any comments would be appreciated. Of particular note:
> >
> >
> > * Should backends be allowed to add functionality or should they be completely interchangeable. E.g. unlike fftpack, FFTW has support for long doubles; should this be exposed to SciPy users?
> >
> >
> >
>
>
>
>
>
>
> If a user writes backend-specific code, then they may just as well bypass the backend right, and call the other library directly? Although for long double things will work out of the box perhaps, because the dtype of an input array doesn't come back in the API. So the array can be passed straight to the backend.
>
>
>
>
>
>
> >
> > * Is there any interest in adding a SciPy config file? For just one option it?s probably not worthwhile but if there is interest in more config options then it starts to make more sense.
> >
> >
> >
>
>
>
>
>
>
> My sense is no. Something like a context manager (`with backend('pyfftw'):`) is lightweight enough probably.
>
>
>
>
>
>
>
> This is probably also a good time to point out http://uarray.readthedocs.io/. It can provide a complete backend system without too much work, it was designed exactly for the type of problem you're trying to solve here. Would be good to have your thoughts on that.
>
>
>
>
>
>
> >
> >
> >
> >
> > Ideally a clear set of design goals can be agreed upon now, before it gets too far into the coding period which begins at the end of the month.
> >
> >
> >
>
>
>
>
>
>
> Yes great idea.
>
>
>
>
>
>
>
> Cheers,
>
>
>
> Ralf
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190509/564ff887/attachment.html>

From toddrjen at gmail.com  Thu May  9 09:54:35 2019
From: toddrjen at gmail.com (Todd)
Date: Thu, 9 May 2019 09:54:35 -0400
Subject: [SciPy-Dev] Backend support for fftpack - GSoC 2019
In-Reply-To: <DB6PR04MB320650B383909FE340B38EEF8E320@DB6PR04MB3206.eurprd04.prod.outlook.com>
References: <DB6PR04MB320650B383909FE340B38EEF8E320@DB6PR04MB3206.eurprd04.prod.outlook.com>
Message-ID: <CAFpSVp+k1db-k_3oXQSvDKuW60Vj+V5maB7y0ygjbC0hnon8xw@mail.gmail.com>

On Wed, May 8, 2019, 11:50 Peter Bell <PeterBell10 at live.co.uk> wrote:

> Hello all,
>
>
>
> I?m happy to say my GSoC proposal was accepted, so I?ll be working over
> the summer to add support for multiple fftpack backends. For those
> interested, I?ve extracted the main discussion from my proposal which you
> can read here:
>
>
> https://docs.google.com/document/d/1hGMc6ZrsmSi_LSixI5oFbo5cZkPUo92sfmnVthg1u6Y/edit
>
>
>
> There are a several design decisions I raise in the proposal and any
> comments would be appreciated. Of particular note:
>
> * Should backends be allowed to add functionality or should they be
> completely interchangeable. E.g. unlike fftpack, FFTW has support for long
> doubles; should this be exposed to SciPy users?
>
> * Is there any interest in adding a SciPy config file? For just one option
> it?s probably not worthwhile but if there is interest in more config
> options then it starts to make more sense.
>
>
>
> Ideally a clear set of design goals can be agreed upon now, before it gets
> too far into the coding period which begins at the end of the month.
>
>
>
> Peter
>

This would be a bit more extreme, but might this be better in numpy?

As I understand it, at least traditionally, numpy has been easier to
install due to not needing a Fortran compiler, but scipy has a generally
faster FFT implementation.

However, looking at some of the code that uses FFTs in scipy, it falls back
on numpy's FFT because it supports data types scipy doesn't at least for
some implementations. This code will either silently do the wrong thing or
will have to have more complicated run-time checks for data types if we get
backend support in scipy.

However, if the backend support were implemented in numpy we could simplify
all this code.  numpy could be in charge of handling fall-backs if the
requested operation doesn't support the given date type.

Specifically, numpy would have its own FFT back-end.  If scipy is available
it will be used as the default back-end, otherwise the numpy back-end will
be used.  The user can choose a different backend (including the numpy
backend if they want).  The user-facing scipy functions would use the numpy
functions behind-the-scenes.  If the requested operation is not supported
by the requested backend, numpy will emit a warning and fall back on the
numpy version.

This has a few other advantages besides allowing us to simplify the scipy
code-base. First, it will remove the existing confusion regarding whether
to use the numpy or scipy version of FFT functions.  Second, with the new
rng work there is already stuff in numpy that would benefit from a config
file (the fallback warning above could also be configurable).

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

From PeterBell10 at live.co.uk  Thu May  9 10:54:44 2019
From: PeterBell10 at live.co.uk (Peter Bell)
Date: Thu, 9 May 2019 14:54:44 +0000
Subject: [SciPy-Dev] Backend support for fftpack - GSoC 2019
In-Reply-To: <CAFpSVp+k1db-k_3oXQSvDKuW60Vj+V5maB7y0ygjbC0hnon8xw@mail.gmail.com>
References: <DB6PR04MB320650B383909FE340B38EEF8E320@DB6PR04MB3206.eurprd04.prod.outlook.com>
 <CAFpSVp+k1db-k_3oXQSvDKuW60Vj+V5maB7y0ygjbC0hnon8xw@mail.gmail.com>
Message-ID: <DB6PR04MB320690032D268C73C2622F048E330@DB6PR04MB3206.eurprd04.prod.outlook.com>

> This would be a bit more extreme, but might this be better in numpy?



AFAIK the main issue here is that NumPy and SciPy have incompatible APIs and

SciPy also has more types of transforms like DCT and DST. It also seems that the

scipy functions are generally intended to be preferred over numpy. I think

keeping it in scipy is also consistent with modules like linalg where there is

some duplication but generally more functionality in scipy.



See:

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

https://scipy.github.io/devdocs/roadmap-detailed.html#fftpack



> As I understand it, at least traditionally, numpy has been easier to install

> due to not needing a Fortran compiler



It should be easy enough to say `pip install scipy` pretty much anywhere, right?

And for those going out of their way to compile themself, I'm not sure that a

fortran compiler is that much more of a burden.



> However, looking at some of the code that uses FFTs in scipy, it falls back on

> numpy's FFT because it supports data types scipy doesn't



Could you give some examples of this? I thought scipy generally supported a

wider variety of both transforms and dtypes.



Peter


From: SciPy-Dev <scipy-dev-bounces+peterbell10=live.co.uk at python.org> On Behalf Of Todd
Sent: 09 May 2019 14:55
To: SciPy Developers List <scipy-dev at python.org>
Subject: Re: [SciPy-Dev] Backend support for fftpack - GSoC 2019

On Wed, May 8, 2019, 11:50 Peter Bell <PeterBell10 at live.co.uk<mailto:PeterBell10 at live.co.uk>> wrote:
Hello all,

I?m happy to say my GSoC proposal was accepted, so I?ll be working over the summer to add support for multiple fftpack backends. For those interested, I?ve extracted the main discussion from my proposal which you can read here:
https://docs.google.com/document/d/1hGMc6ZrsmSi_LSixI5oFbo5cZkPUo92sfmnVthg1u6Y/edit

There are a several design decisions I raise in the proposal and any comments would be appreciated. Of particular note:
* Should backends be allowed to add functionality or should they be completely interchangeable. E.g. unlike fftpack, FFTW has support for long doubles; should this be exposed to SciPy users?
* Is there any interest in adding a SciPy config file? For just one option it?s probably not worthwhile but if there is interest in more config options then it starts to make more sense.

Ideally a clear set of design goals can be agreed upon now, before it gets too far into the coding period which begins at the end of the month.

Peter

This would be a bit more extreme, but might this be better in numpy?

As I understand it, at least traditionally, numpy has been easier to install due to not needing a Fortran compiler, but scipy has a generally faster FFT implementation.

However, looking at some of the code that uses FFTs in scipy, it falls back on numpy's FFT because it supports data types scipy doesn't at least for some implementations. This code will either silently do the wrong thing or will have to have more complicated run-time checks for data types if we get backend support in scipy.

However, if the backend support were implemented in numpy we could simplify all this code.  numpy could be in charge of handling fall-backs if the requested operation doesn't support the given date type.

Specifically, numpy would have its own FFT back-end.  If scipy is available it will be used as the default back-end, otherwise the numpy back-end will be used.  The user can choose a different backend (including the numpy backend if they want).  The user-facing scipy functions would use the numpy functions behind-the-scenes.  If the requested operation is not supported by the requested backend, numpy will emit a warning and fall back on the numpy version.

This has a few other advantages besides allowing us to simplify the scipy code-base. First, it will remove the existing confusion regarding whether to use the numpy or scipy version of FFT functions.  Second, with the new rng work there is already stuff in numpy that would benefit from a config file (the fallback warning above could also be configurable).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190509/ba46048e/attachment.html>

From toddrjen at gmail.com  Thu May  9 12:03:58 2019
From: toddrjen at gmail.com (Todd)
Date: Thu, 9 May 2019 12:03:58 -0400
Subject: [SciPy-Dev] Backend support for fftpack - GSoC 2019
In-Reply-To: <DB6PR04MB320690032D268C73C2622F048E330@DB6PR04MB3206.eurprd04.prod.outlook.com>
References: <DB6PR04MB320650B383909FE340B38EEF8E320@DB6PR04MB3206.eurprd04.prod.outlook.com>
 <CAFpSVp+k1db-k_3oXQSvDKuW60Vj+V5maB7y0ygjbC0hnon8xw@mail.gmail.com>
 <DB6PR04MB320690032D268C73C2622F048E330@DB6PR04MB3206.eurprd04.prod.outlook.com>
Message-ID: <CAFpSVpKB1WBOtC6Q3FME8XASbRSJNQWW+9OtNTMkx2inb2miDg@mail.gmail.com>

On Thu, May 9, 2019 at 10:55 AM Peter Bell <PeterBell10 at live.co.uk> wrote:

> > This would be a bit more extreme, but might this be better in numpy?
>
>
>
> AFAIK the main issue here is that NumPy and SciPy have incompatible APIs
> and
>
> SciPy also has more types of transforms like DCT and DST. It also seems
> that the
>
> scipy functions are generally intended to be preferred over numpy. I think
>
> keeping it in scipy is also consistent with modules like linalg where
> there is
>
> some duplication but generally more functionality in scipy.
>
>
>
> See:
>
> https://github.com/scipy/scipy/issues/2487
>
> https://scipy.github.io/devdocs/roadmap-detailed.html#fftpack
>

Yes, these are the sorts of issues this idea would fix.  However, adding
backend support to scipy wouldn't fix these issues, since the duplication
these discuss would still exist in numpy.


> > As I understand it, at least traditionally, numpy has been easier to
> install
>
> > due to not needing a Fortran compiler
>
>
>
> It should be easy enough to say `pip install scipy` pretty much anywhere,
> right?
>
> And for those going out of their way to compile themself, I'm not sure
> that a
>
> fortran compiler is that much more of a burden.
>

As I said, this was a problem traditionally, before wheels and openblas.


> > However, looking at some of the code that uses FFTs in scipy, it falls
> back on
>
> > numpy's FFT because it supports data types scipy doesn't
>
>
>
> Could you give some examples of this? I thought scipy generally supported a
>
> wider variety of both transforms and dtypes.
>
I had the problem backwards.  scipy supports more dtypes, but is slower, at
least according to comments in fftconvolve:

https://github.com/scipy/scipy/blob/master/scipy/signal/signaltools.py#L409

Peter
>
>
>
>
>
> *From:* SciPy-Dev <scipy-dev-bounces+peterbell10=live.co.uk at python.org> *On
> Behalf Of *Todd
> *Sent:* 09 May 2019 14:55
> *To:* SciPy Developers List <scipy-dev at python.org>
> *Subject:* Re: [SciPy-Dev] Backend support for fftpack - GSoC 2019
>
>
>
> On Wed, May 8, 2019, 11:50 Peter Bell <PeterBell10 at live.co.uk> wrote:
>
> Hello all,
>
>
>
> I?m happy to say my GSoC proposal was accepted, so I?ll be working over
> the summer to add support for multiple fftpack backends. For those
> interested, I?ve extracted the main discussion from my proposal which you
> can read here:
>
>
> https://docs.google.com/document/d/1hGMc6ZrsmSi_LSixI5oFbo5cZkPUo92sfmnVthg1u6Y/edit
>
>
>
> There are a several design decisions I raise in the proposal and any
> comments would be appreciated. Of particular note:
>
> * Should backends be allowed to add functionality or should they be
> completely interchangeable. E.g. unlike fftpack, FFTW has support for long
> doubles; should this be exposed to SciPy users?
>
> * Is there any interest in adding a SciPy config file? For just one option
> it?s probably not worthwhile but if there is interest in more config
> options then it starts to make more sense.
>
>
>
> Ideally a clear set of design goals can be agreed upon now, before it gets
> too far into the coding period which begins at the end of the month.
>
>
>
> Peter
>
>
>
> This would be a bit more extreme, but might this be better in numpy?
>
>
>
> As I understand it, at least traditionally, numpy has been easier to
> install due to not needing a Fortran compiler, but scipy has a generally
> faster FFT implementation.
>
>
>
> However, looking at some of the code that uses FFTs in scipy, it falls
> back on numpy's FFT because it supports data types scipy doesn't at least
> for some implementations. This code will either silently do the wrong thing
> or will have to have more complicated run-time checks for data types if we
> get backend support in scipy.
>
>
>
> However, if the backend support were implemented in numpy we could
> simplify all this code.  numpy could be in charge of handling fall-backs if
> the requested operation doesn't support the given date type.
>
>
>
> Specifically, numpy would have its own FFT back-end.  If scipy is
> available it will be used as the default back-end, otherwise the numpy
> back-end will be used.  The user can choose a different backend (including
> the numpy backend if they want).  The user-facing scipy functions would use
> the numpy functions behind-the-scenes.  If the requested operation is not
> supported by the requested backend, numpy will emit a warning and fall back
> on the numpy version.
>
>
>
> This has a few other advantages besides allowing us to simplify the scipy
> code-base. First, it will remove the existing confusion regarding whether
> to use the numpy or scipy version of FFT functions.  Second, with the new
> rng work there is already stuff in numpy that would benefit from a config
> file (the fallback warning above could also be configurable).
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190509/e60d94f2/attachment.html>

From tyler.je.reddy at gmail.com  Thu May  9 14:40:41 2019
From: tyler.je.reddy at gmail.com (Tyler Reddy)
Date: Thu, 9 May 2019 11:40:41 -0700
Subject: [SciPy-Dev] ANN: SciPy 1.3.0rc2 -- please test
Message-ID: <CAHPuU_ZUdkmTQHVv4q_34T=ocR8iQR0Z+Btx9d=L8q4+aYqLKA@mail.gmail.com>

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

Hi all,

On behalf of the SciPy development team I'm pleased to announce
the release candidate SciPy 1.3.0rc2. Please help us test this pre-release.

The primary motivation for the second release candidate to is to update
wheels to use a more recent OpenBLAS with fixes for SkylakeX AVX
kernel problems.

Sources and binary wheels can be found at:
https://pypi.org/project/scipy/
and at:
https://github.com/scipy/scipy/releases/tag/v1.3.0rc2

One of a few ways to install the release candidate with pip:

pip install scipy==1.3.0rc2

==========================
SciPy 1.3.0 Release Notes
==========================

Note: Scipy 1.3.0 is not released yet!

SciPy 1.3.0 is the culmination of 5 months of hard work. It contains
many new features, numerous bug-fixes, improved test coverage and better
documentation. There have been some API changes
in this release, which are documented below. All users are encouraged to
upgrade to this release, as there are a large number of bug-fixes and
optimizations. Before upgrading, we recommend that users check that
their own code does not use deprecated SciPy functionality (to do so,
run your code with ``python -Wd`` and check for ``DeprecationWarning`` s).
Our development attention will now shift to bug-fix releases on the
1.3.x branch, and on adding new features on the master branch.

This release requires Python 3.5+ and NumPy 1.13.3 or greater.

For running on PyPy, PyPy3 6.0+ and NumPy 1.15.0 are required.

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

- - Three new ``stats`` functions, a rewrite of ``pearsonr``, and an exact
  computation of the Kolmogorov-Smirnov two-sample test
- - A new Cython API for bounded scalar-function root-finders in
`scipy.optimize`
- - Substantial ``CSR`` and ``CSC`` sparse matrix indexing performance
  improvements
- - Added support for interpolation of rotations with continuous angular
  rate and acceleration in ``RotationSpline``


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

`scipy.interpolate` improvements
- --------------------------------

A new class ``CubicHermiteSpline`` is introduced. It is a piecewise-cubic
interpolator which matches observed values and first derivatives. Existing
cubic interpolators ``CubicSpline``, ``PchipInterpolator`` and
``Akima1DInterpolator`` were made subclasses of ``CubicHermiteSpline``.

`scipy.io` improvements
- -----------------------

For the Attribute-Relation File Format (ARFF) `scipy.io.arff.loadarff`
now supports relational attributes.

`scipy.io.mmread` can now parse Matrix Market format files with empty lines.

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

Added wrappers for ``?syconv`` routines, which convert a symmetric matrix
given by a triangular matrix factorization into two matrices and vice versa.

`scipy.linalg.clarkson_woodruff_transform` now uses an algorithm that
leverages
sparsity. This may provide a 60-90 percent speedup for dense input matrices.
Truly sparse input matrices should also benefit from the improved sketch
algorithm, which now correctly runs in ``O(nnz(A))`` time.

Added new functions to calculate symmetric Fiedler matrices and
Fiedler companion matrices, named `scipy.linalg.fiedler` and
`scipy.linalg.fiedler_companion`, respectively. These may be used
for root finding.

`scipy.ndimage` improvements
- ----------------------------

Gaussian filter performances may improve by an order of magnitude in
some cases, thanks to removal of a dependence on ``np.polynomial``. This
may impact `scipy.ndimage.gaussian_filter` for example.

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

The `scipy.optimize.brute` minimizer obtained a new keyword ``workers``,
which
can be used to parallelize computation.

A Cython API for bounded scalar-function root-finders in `scipy.optimize`
is available in a new module `scipy.optimize.cython_optimize` via
``cimport``.
This API may be used with ``nogil`` and ``prange`` to loop
over an array of function arguments to solve for an array of roots more
quickly than with pure Python.

``'interior-point'`` is now the default method for ``linprog``, and
``'interior-point'`` now uses SuiteSparse for sparse problems when the
required scikits  (scikit-umfpack and scikit-sparse) are available.
On benchmark problems (gh-10026), execution time reductions by factors of
2-3
were typical. Also, a new ``method='revised simplex'`` has been added.
It is not as fast or robust as ``method='interior-point'``, but it is a
faster,
more robust, and equally accurate substitute for the legacy
``method='simplex'``.

``differential_evolution`` can now use a ``Bounds`` class to specify the
bounds for the optimizing argument of a function.

`scipy.optimize.dual_annealing` performance improvements related to
vectorisation of some internal code.

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

Two additional methods of discretization are now supported by
`scipy.signal.cont2discrete`: ``impulse`` and ``foh``.

`scipy.signal.firls` now uses faster solvers

`scipy.signal.detrend` now has a lower physical memory footprint in some
cases, which may be leveraged using the new ``overwrite_data`` keyword
argument

`scipy.signal.firwin` ``pass_zero`` argument now accepts new string
arguments
that allow specification of the desired filter type: ``'bandpass'``,
``'lowpass'``, ``'highpass'``, and ``'bandstop'``

`scipy.signal.sosfilt` may have improved performance due to lower retention
of the global interpreter lock (GIL) in algorithm

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

A new keyword was added to ``csgraph.dijsktra`` that
allows users to query the shortest path to ANY of the passed in indices,
as opposed to the shortest path to EVERY passed index.

`scipy.sparse.linalg.lsmr` performance has been improved by roughly 10
percent
on large problems

Improved performance and reduced physical memory footprint of the algorithm
used by `scipy.sparse.linalg.lobpcg`

``CSR`` and ``CSC`` sparse matrix fancy indexing performance has been
improved substantially

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

`scipy.spatial.ConvexHull` now has a ``good`` attribute that can be used
alongsize the ``QGn`` Qhull options to determine which external facets of a
convex hull are visible from an external query point.

`scipy.spatial.cKDTree.query_ball_point` has been modernized to use some
newer
Cython features, including GIL handling and exception translation. An issue
with ``return_sorted=True`` and scalar queries was fixed, and a new mode
named
``return_length`` was added. ``return_length`` only computes the length of
the
returned indices list instead of allocating the array every time.

`scipy.spatial.transform.RotationSpline` has been added to enable
interpolation
of rotations with continuous angular rates and acceleration

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

Added a new function to compute the Epps-Singleton test statistic,
`scipy.stats.epps_singleton_2samp`, which can be applied to continuous and
discrete distributions.

New functions `scipy.stats.median_absolute_deviation` and `scipy.stats.gstd`
(geometric standard deviation) were added. The
`scipy.stats.combine_pvalues`
method now supports ``pearson``,  ``tippett`` and ``mudholkar_george``
pvalue
combination methods.

The `scipy.stats.ortho_group` and `scipy.stats.special_ortho_group`
``rvs(dim)`` functions' algorithms were updated from a ``O(dim^4)``
implementation to a ``O(dim^3)`` which gives large speed improvements
for ``dim>100``.

A rewrite of `scipy.stats.pearsonr` to use a more robust algorithm,
provide meaningful exceptions and warnings on potentially pathological
input,
and fix at least five separate reported issues in the original
implementation.

Improved the precision of ``hypergeom.logcdf`` and ``hypergeom.logsf``.

Added exact computation for Kolmogorov-Smirnov (KS) two-sample test,
replacing
the previously approximate computation for the two-sided test
`stats.ks_2samp`.
Also added a one-sided, two-sample KS test, and a keyword ``alternative``
to
`stats.ks_2samp`.

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

`scipy.interpolate` changes
- ---------------------------

Functions from ``scipy.interpolate`` (``spleval``, ``spline``, ``splmake``,
and ``spltopp``) and functions from ``scipy.misc`` (``bytescale``,
``fromimage``, ``imfilter``, ``imread``, ``imresize``, ``imrotate``,
``imsave``, ``imshow``, ``toimage``) have been removed. The former set has
been deprecated since v0.19.0 and the latter has been deprecated since
v1.0.0.
Similarly, aliases from ``scipy.misc`` (``comb``, ``factorial``,
``factorial2``, ``factorialk``, ``logsumexp``, ``pade``, ``info``,
``source``,
``who``) which have been deprecated since v1.0.0 are removed.
`SciPy documentation for
v1.1.0 <https://docs.scipy.org/doc/scipy-1.1.0/reference/misc.html>`__
can be used to track the new import locations for the relocated functions.

`scipy.linalg` changes
- ----------------------

For ``pinv``, ``pinv2``, and ``pinvh``, the default cutoff values are
changed
for consistency (see the docs for the actual values).

`scipy.stats` changes
- ---------------------

Previously, ``ks_2samp(data1, data2)`` would run a two-sided test and
return
the approximated p-value. The new signature, ``ks_2samp(data1, data2,
alternative="two-sided", method="auto")``, still runs the two-sided test by
default but returns the exact p-value for small samples and the approximated
value for large samples. ``method="asymp"`` would be equivalent to the
old version but ``auto`` is the better choice.

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

Our tutorial has been expanded with a new section on global optimizers

There has been a rework of the ``stats.distributions`` tutorials.

`scipy.optimize` now correctly sets the convergence flag of the result to
``CONVERR``, a convergence error, for bounded scalar-function root-finders
if the maximum iterations has been exceeded, ``disp`` is false, and
``full_output`` is true.

`scipy.optimize.curve_fit` no longer fails if ``xdata`` and ``ydata``
dtypes
differ; they are both now automatically cast to ``float64``.

`scipy.ndimage` functions including ``binary_erosion``, ``binary_closing``,
and
``binary_dilation`` now require an integer value for the number of
iterations,
which alleviates a number of reported issues.

Fixed normal approximation in case ``zero_method == "pratt"`` in
`scipy.stats.wilcoxon`.

Fixes for incorrect probabilities, broadcasting issues and thread-safety
related to stats distributions setting member variables inside
``_argcheck()``.

`scipy.optimize.newton` now correctly raises a ``RuntimeError``, when
default
arguments are used, in the case that a derivative of value zero is obtained,
which is a special case of failing to converge.

A draft toolchain roadmap is now available, laying out a compatibility plan
including Python versions, C standards, and NumPy versions.


Authors
=======

* ananyashreyjain +
* ApamNapat +
* Scott Calabrese Barton +
* Christoph Baumgarten
* Peter Bell +
* Jacob Blomgren +
* Doctor Bob +
* Mana Borwornpadungkitti +
* Matthew Brett
* Evgeni Burovski
* CJ Carey
* Vega Theil Carstensen +
* Robert Cimrman
* Forrest Collman +
* Pietro Cottone +
* David +
* Idan David +
* Christoph Deil
* Dieter Werthm?ller
* Conner DiPaolo +
* Dowon
* Michael Dunphy +
* Peter Andreas Entschev +
* G?k?en Eraslan +
* Johann Faouzi +
* Yu Feng
* Piotr Figiel +
* Matthew H Flamm
* Franz Forstmayr +
* Christoph Gohlke
* Richard Janis Goldschmidt +
* Ralf Gommers
* Lars Grueter
* Sylvain Gubian
* Matt Haberland
* Yaroslav Halchenko
* Charles Harris
* Lindsey Hiltner
* JakobStruye +
* He Jia +
* Jwink3101 +
* Greg Kiar +
* Julius Bier Kirkegaard
* John Kirkham +
* Thomas Kluyver
* Vladimir Korolev +
* Joseph Kuo +
* Michael Lamparski +
* Eric Larson
* Denis Laxalde
* Katrin Leinweber
* Jesse Livezey
* ludcila +
* Dhruv Madeka +
* Magnus +
* Nikolay Mayorov
* Mark Mikofski
* Jarrod Millman
* Markus Mohrhard +
* Eric Moore
* Andrew Nelson
* Aki Nishimura +
* OGordon100 +
* Petar Mlinari? +
* Stefan Peterson
* Matti Picus +
* Ilhan Polat
* Aaron Pries +
* Matteo Ravasi +
* Tyler Reddy
* Ashton Reimer +
* Joscha Reimer
* rfezzani +
* Riadh +
* Lucas Roberts
* Heshy Roskes +
* Mirko Scholz +
* Taylor D. Scott +
* Srikrishna Sekhar +
* Kevin Sheppard +
* Sourav Singh
* skjerns +
* Kai Striega
* SyedSaifAliAlvi +
* Gopi Manohar T +
* Albert Thomas +
* Timon +
* Paul van Mulbregt
* Jacob Vanderplas
* Daniel Vargas +
* Pauli Virtanen
* VNMabus +
* Stefan van der Walt
* Warren Weckesser
* Josh Wilson
* Nate Yoder +
* Roman Yurchak

A total of 97 people contributed to this release.
People with a "+" by their names contributed a patch for the first time.
This list of names is automatically generated, and may not be fully
complete.

Issues closed for 1.3.0
- -----------------------

* `#1320 <https://github.com/scipy/scipy/issues/1320>`__:
scipy.stats.distribution: problem with self.a, self.b if they...
* `#2002 <https://github.com/scipy/scipy/issues/2002>`__: members set in
scipy.stats.distributions.##._argcheck (Trac #1477)
* `#2823 <https://github.com/scipy/scipy/issues/2823>`__: distribution
methods add tmp
* `#3220 <https://github.com/scipy/scipy/issues/3220>`__:
Scipy.opimize.fmin_powell direc argument syntax unclear
* `#3728 <https://github.com/scipy/scipy/issues/3728>`__:
scipy.stats.pearsonr: possible bug with zero variance input
* `#6805 <https://github.com/scipy/scipy/issues/6805>`__:
error-in-scipy-wilcoxon-signed-rank-test-for-equal-series
* `#6873 <https://github.com/scipy/scipy/issues/6873>`__: 'stats.boxcox'
return all same values
* `#7117 <https://github.com/scipy/scipy/issues/7117>`__: Warn users when
using float32 input data to curve_fit and friends
* `#7632 <https://github.com/scipy/scipy/issues/7632>`__: it's not possible
to tell the \`optimize.least_squares\` solver...
* `#7730 <https://github.com/scipy/scipy/issues/7730>`__: stats.pearsonr:
Potential division by zero for dataset of length...
* `#7933 <https://github.com/scipy/scipy/issues/7933>`__: stats.truncnorm
fails when providing values outside truncation...
* `#8033 <https://github.com/scipy/scipy/issues/8033>`__: Add standard
filter types to firwin to set pass_zero intuitively...
* `#8600 <https://github.com/scipy/scipy/issues/8600>`__: lfilter.c.src
zfill has erroneous header
* `#8692 <https://github.com/scipy/scipy/issues/8692>`__: Non-negative
values of \`stats.hypergeom.logcdf\`
* `#8734 <https://github.com/scipy/scipy/issues/8734>`__: Enable pip build
isolation
* `#8861 <https://github.com/scipy/scipy/issues/8861>`__: scipy.linalg.pinv
gives wrong result while scipy.linalg.pinv2...
* `#8915 <https://github.com/scipy/scipy/issues/8915>`__: need to fix macOS
build against older numpy versions
* `#8980 <https://github.com/scipy/scipy/issues/8980>`__:
scipy.stats.pearsonr overflows with high values of x and y
* `#9226 <https://github.com/scipy/scipy/issues/9226>`__: BUG: signal:
SystemError: <built-in function _linear_filter>...
* `#9254 <https://github.com/scipy/scipy/issues/9254>`__: BUG: root finders
brentq, etc, flag says "converged" even if...
* `#9308 <https://github.com/scipy/scipy/issues/9308>`__: Test failure -
test_initial_constraints_as_canonical
* `#9353 <https://github.com/scipy/scipy/issues/9353>`__:
scipy.stats.pearsonr returns r=1 if r_num/r_den = inf
* `#9359 <https://github.com/scipy/scipy/issues/9359>`__: Planck
distribution is a geometric distribution
* `#9381 <https://github.com/scipy/scipy/issues/9381>`__: linregress should
warn user in 2x2 array case
* `#9406 <https://github.com/scipy/scipy/issues/9406>`__: BUG: stats: In
pearsonr, when r is nan, the p-value must also...
* `#9437 <https://github.com/scipy/scipy/issues/9437>`__: Cannot create
sparse matrix from size_t indexes
* `#9518 <https://github.com/scipy/scipy/issues/9518>`__: Relational
attributes in loadarff
* `#9551 <https://github.com/scipy/scipy/issues/9551>`__: BUG:
scipy.optimize.newton says the root of x^2+1 is zero.
* `#9564 <https://github.com/scipy/scipy/issues/9564>`__: rv_sample accepts
invalid input in scipy.stats
* `#9565 <https://github.com/scipy/scipy/issues/9565>`__: improper handling
of multidimensional input in stats.rv_sample
* `#9581 <https://github.com/scipy/scipy/issues/9581>`__: Least-squares
minimization fails silently when x and y data are...
* `#9587 <https://github.com/scipy/scipy/issues/9587>`__: Outdated value
for scipy.constants.au
* `#9611 <https://github.com/scipy/scipy/issues/9611>`__: Overflow error
with new way of p-value calculation in kendall...
* `#9645 <https://github.com/scipy/scipy/issues/9645>`__:
\`scipy.stats.mode\` crashes with variable length arrays (\`dtype=object\`)
* `#9734 <https://github.com/scipy/scipy/issues/9734>`__:
PendingDeprecationWarning for np.matrix with pytest
* `#9786 <https://github.com/scipy/scipy/issues/9786>`__: stats.ks_2samp()
misleading for small data sets.
* `#9790 <https://github.com/scipy/scipy/issues/9790>`__: Excessive memory
usage on detrend
* `#9801 <https://github.com/scipy/scipy/issues/9801>`__: dual_annealing
does not set the success attribute in OptimizeResult
* `#9833 <https://github.com/scipy/scipy/issues/9833>`__:
IntegrationWarning from mielke.stats() during build of html doc.
* `#9835 <https://github.com/scipy/scipy/issues/9835>`__:
scipy.signal.firls seems to be inefficient versus MATLAB firls
* `#9864 <https://github.com/scipy/scipy/issues/9864>`__: Curve_fit does
not check for empty input data if called with...
* `#9869 <https://github.com/scipy/scipy/issues/9869>`__:
scipy.ndimage.label: Minor documentation issue
* `#9882 <https://github.com/scipy/scipy/issues/9882>`__: format at the
wrong paranthesis in scipy.spatial.transform
* `#9889 <https://github.com/scipy/scipy/issues/9889>`__:
scipy.signal.find_peaks minor documentation issue
* `#9890 <https://github.com/scipy/scipy/issues/9890>`__: Minkowski p-norm
Issues in cKDTree For Values Other Than 2 Or...
* `#9896 <https://github.com/scipy/scipy/issues/9896>`__:
scipy.stats._argcheck sets (not just checks) values
* `#9905 <https://github.com/scipy/scipy/issues/9905>`__: Memory error in
ndimage.binary_erosion
* `#9909 <https://github.com/scipy/scipy/issues/9909>`__:
binary_dilation/erosion/closing crashes when iterations is float
* `#9919 <https://github.com/scipy/scipy/issues/9919>`__: BUG:
\`coo_matrix\` does not validate the \`shape\` argument.
* `#9982 <https://github.com/scipy/scipy/issues/9982>`__: lsq_linear
hangs/infinite loop with 'trf' method
* `#10003 <https://github.com/scipy/scipy/issues/10003>`__: exponnorm.pdf
returns NAN for small K
* `#10011 <https://github.com/scipy/scipy/issues/10011>`__: Incorrect check
for invalid rotation plane in scipy.ndimage.rotate
* `#10024 <https://github.com/scipy/scipy/issues/10024>`__: Fails to build
from git
* `#10048 <https://github.com/scipy/scipy/issues/10048>`__: DOC:
scipy.optimize.root_scalar
* `#10068 <https://github.com/scipy/scipy/issues/10068>`__: DOC:
scipy.interpolate.splev
* `#10074 <https://github.com/scipy/scipy/issues/10074>`__: BUG: \`expm\`
calculates the wrong coefficients in the backward...


Pull requests for 1.3.0
- -----------------------

* `#7827 <https://github.com/scipy/scipy/pull/7827>`__: ENH: sparse:
overhaul of sparse matrix indexing
* `#8431 <https://github.com/scipy/scipy/pull/8431>`__: ENH: Cython
optimize zeros api
* `#8743 <https://github.com/scipy/scipy/pull/8743>`__: DOC: Updated
linalg.pinv, .pinv2, .pinvh docstrings
* `#8744 <https://github.com/scipy/scipy/pull/8744>`__: DOC: added examples
to remez docstring
* `#9227 <https://github.com/scipy/scipy/pull/9227>`__: DOC: update
description of "direc" parameter of "fmin_powell"
* `#9263 <https://github.com/scipy/scipy/pull/9263>`__: ENH: optimize:
added "revised simplex" for scipy.optimize.linprog
* `#9325 <https://github.com/scipy/scipy/pull/9325>`__: DEP: Remove
deprecated functions for 1.3.0
* `#9330 <https://github.com/scipy/scipy/pull/9330>`__: Add note on push
and pull affine transformations
* `#9423 <https://github.com/scipy/scipy/pull/9423>`__: DOC: Clearly state
how 2x2 input arrays are handled in stats.linregress
* `#9428 <https://github.com/scipy/scipy/pull/9428>`__: ENH: parallelised
brute
* `#9438 <https://github.com/scipy/scipy/pull/9438>`__: BUG: Initialize coo
matrix with size_t indexes
* `#9455 <https://github.com/scipy/scipy/pull/9455>`__: MAINT: Speed up
get_(lapack,blas)_func
* `#9465 <https://github.com/scipy/scipy/pull/9465>`__: MAINT: Clean up
optimize.zeros C solvers interfaces/code.
* `#9477 <https://github.com/scipy/scipy/pull/9477>`__: DOC: linalg: fix
lstsq docstring on residues shape
* `#9478 <https://github.com/scipy/scipy/pull/9478>`__: DOC: Add docstring
examples for rosen functions
* `#9479 <https://github.com/scipy/scipy/pull/9479>`__: DOC: Add docstring
example for ai_zeros and bi_zeros
* `#9480 <https://github.com/scipy/scipy/pull/9480>`__: MAINT: linalg:
lstsq clean up
* `#9489 <https://github.com/scipy/scipy/pull/9489>`__: DOC: roadmap update
for changes over the last year.
* `#9492 <https://github.com/scipy/scipy/pull/9492>`__: MAINT: stats:
Improve implementation of chi2 ppf method.
* `#9497 <https://github.com/scipy/scipy/pull/9497>`__: DOC: Improve
docstrings sparse.linalg.isolve
* `#9499 <https://github.com/scipy/scipy/pull/9499>`__: DOC: Replace
"Scipy" with "SciPy" in the .rst doc files for consistency.
* `#9500 <https://github.com/scipy/scipy/pull/9500>`__: DOC: Document the
toolchain and its roadmap.
* `#9505 <https://github.com/scipy/scipy/pull/9505>`__: DOC: specify which
definition of skewness is used
* `#9511 <https://github.com/scipy/scipy/pull/9511>`__: DEP: interpolate:
remove deprecated interpolate_wrapper
* `#9517 <https://github.com/scipy/scipy/pull/9517>`__: BUG: improve error
handling in stats.iqr
* `#9522 <https://github.com/scipy/scipy/pull/9522>`__: ENH: Add Fiedler
and fiedler companion to special matrices
* `#9526 <https://github.com/scipy/scipy/pull/9526>`__: TST: relax
precision requirements in signal.correlate tests
* `#9529 <https://github.com/scipy/scipy/pull/9529>`__: DOC: fix missing
random seed in optimize.newton example
* `#9533 <https://github.com/scipy/scipy/pull/9533>`__: MAINT: Use list
comprehension when possible
* `#9537 <https://github.com/scipy/scipy/pull/9537>`__: DOC: add a "big
picture" roadmap
* `#9538 <https://github.com/scipy/scipy/pull/9538>`__: DOC: Replace
"Numpy" with "NumPy" in .py, .rst and .txt doc files...
* `#9539 <https://github.com/scipy/scipy/pull/9539>`__: ENH: add two-sample
test (Epps-Singleton) to scipy.stats
* `#9559 <https://github.com/scipy/scipy/pull/9559>`__: DOC: add section on
global optimizers to tutorial
* `#9561 <https://github.com/scipy/scipy/pull/9561>`__: ENH: remove
noprefix.h, change code appropriately
* `#9562 <https://github.com/scipy/scipy/pull/9562>`__: MAINT: stats:
Rewrite pearsonr.
* `#9563 <https://github.com/scipy/scipy/pull/9563>`__: BUG: Minor bug fix
Callback in linprog(method='simplex')
* `#9568 <https://github.com/scipy/scipy/pull/9568>`__: MAINT: raise
runtime error for newton with zeroder if disp true,...
* `#9570 <https://github.com/scipy/scipy/pull/9570>`__: Correct docstring
in show_options in optimize. Fixes #9407
* `#9573 <https://github.com/scipy/scipy/pull/9573>`__: BUG fixes range of
pk variable pre-check
* `#9577 <https://github.com/scipy/scipy/pull/9577>`__: TST: fix minor
issue in a signal.stft test.
* `#9580 <https://github.com/scipy/scipy/pull/9580>`__: Included blank line
before list - Fixes #8658
* `#9582 <https://github.com/scipy/scipy/pull/9582>`__: MAINT: drop Python
2.7 and 3.4
* `#9588 <https://github.com/scipy/scipy/pull/9588>`__: MAINT: update
\`constants.astronomical_unit\` to new 2012 value.
* `#9592 <https://github.com/scipy/scipy/pull/9592>`__: TST: Add 32-bit
testing to CI
* `#9593 <https://github.com/scipy/scipy/pull/9593>`__: DOC: Replace
cumulative density with cumulative distribution
* `#9596 <https://github.com/scipy/scipy/pull/9596>`__: TST: remove VC 9.0
from Azure CI
* `#9599 <https://github.com/scipy/scipy/pull/9599>`__: Hyperlink DOI to
preferred resolver
* `#9601 <https://github.com/scipy/scipy/pull/9601>`__: DEV: try to limit
GC memory use on PyPy
* `#9603 <https://github.com/scipy/scipy/pull/9603>`__: MAINT: improve
logcdf and logsf of hypergeometric distribution
* `#9605 <https://github.com/scipy/scipy/pull/9605>`__: Reference to pylops
in LinearOperator notes and ARPACK example
* `#9617 <https://github.com/scipy/scipy/pull/9617>`__: TST: reduce max
memory usage for sparse.linalg.lgmres test
* `#9619 <https://github.com/scipy/scipy/pull/9619>`__: FIX: Sparse matrix
addition/subtraction eliminates explicit zeros
* `#9621 <https://github.com/scipy/scipy/pull/9621>`__: bugfix in rv_sample
in scipy.stats
* `#9622 <https://github.com/scipy/scipy/pull/9622>`__: MAINT: Raise error
in directed_hausdorff distance
* `#9623 <https://github.com/scipy/scipy/pull/9623>`__: DOC: Build docs
with warnings as errors
* `#9625 <https://github.com/scipy/scipy/pull/9625>`__: Return the number
of calls to 'hessp' (not just 'hess') in trust...
* `#9627 <https://github.com/scipy/scipy/pull/9627>`__: BUG: ignore empty
lines in mmio
* `#9637 <https://github.com/scipy/scipy/pull/9637>`__: Function to
calculate the MAD of an array
* `#9646 <https://github.com/scipy/scipy/pull/9646>`__: BUG: stats: mode
for objects w/ndim > 1
* `#9648 <https://github.com/scipy/scipy/pull/9648>`__: Add
\`stats.contingency\` to refguide-check
* `#9650 <https://github.com/scipy/scipy/pull/9650>`__: ENH: many lobpcg()
algorithm improvements
* `#9652 <https://github.com/scipy/scipy/pull/9652>`__: Move misc.doccer to
_lib.doccer
* `#9660 <https://github.com/scipy/scipy/pull/9660>`__: ENH: add pearson,
tippett, and mudholkar-george to combine_pvalues
* `#9661 <https://github.com/scipy/scipy/pull/9661>`__: BUG: Fix ksone
right-hand endpoint, documentation and tests.
* `#9664 <https://github.com/scipy/scipy/pull/9664>`__: ENH: adding
multi-target dijsktra performance enhancement
* `#9670 <https://github.com/scipy/scipy/pull/9670>`__: MAINT: link planck
and geometric distribution in scipy.stats
* `#9676 <https://github.com/scipy/scipy/pull/9676>`__: ENH: optimize:
change default linprog method to interior-point
* `#9685 <https://github.com/scipy/scipy/pull/9685>`__: Added reference to
ndimage.filters.median_filter
* `#9705 <https://github.com/scipy/scipy/pull/9705>`__: Fix coefficients in
expm helper function
* `#9711 <https://github.com/scipy/scipy/pull/9711>`__: Release the GIL
during sosfilt processing for simple types
* `#9721 <https://github.com/scipy/scipy/pull/9721>`__: ENH: Convexhull
visiblefacets
* `#9723 <https://github.com/scipy/scipy/pull/9723>`__: BLD: Modify
rv_generic._construct_doc to print out failing distribution...
* `#9726 <https://github.com/scipy/scipy/pull/9726>`__: BUG: Fix small
issues with \`signal.lfilter'
* `#9729 <https://github.com/scipy/scipy/pull/9729>`__: BUG: Typecheck
iterations for binary image operations
* `#9730 <https://github.com/scipy/scipy/pull/9730>`__: ENH: reduce
sizeof(NI_WatershedElement) by 20%
* `#9731 <https://github.com/scipy/scipy/pull/9731>`__: ENH: remove
suspicious sequence of type castings
* `#9739 <https://github.com/scipy/scipy/pull/9739>`__: BUG: qr_updates
fails if u is exactly in span Q
* `#9749 <https://github.com/scipy/scipy/pull/9749>`__: BUG:
MapWrapper.__exit__ should terminate
* `#9753 <https://github.com/scipy/scipy/pull/9753>`__: ENH: Added exact
computation for Kolmogorov-Smirnov two-sample...
* `#9755 <https://github.com/scipy/scipy/pull/9755>`__: DOC: Added example
for signal.impulse, copied from impulse2
* `#9756 <https://github.com/scipy/scipy/pull/9756>`__: DOC: Added
docstring example for iirdesign
* `#9757 <https://github.com/scipy/scipy/pull/9757>`__: DOC: Added examples
for step functions
* `#9759 <https://github.com/scipy/scipy/pull/9759>`__: ENH: Allow
pass_zero to act like btype
* `#9760 <https://github.com/scipy/scipy/pull/9760>`__: DOC: Added
docstring for lp2bs
* `#9761 <https://github.com/scipy/scipy/pull/9761>`__: DOC: Added
docstring and example for lp2bp
* `#9764 <https://github.com/scipy/scipy/pull/9764>`__: BUG: Catch internal
warnings for matrix
* `#9766 <https://github.com/scipy/scipy/pull/9766>`__: ENH: Speed up
_gaussian_kernel1d by removing dependence on np.polynomial
* `#9769 <https://github.com/scipy/scipy/pull/9769>`__: BUG: Fix Cubic
Spline Read Only issues
* `#9773 <https://github.com/scipy/scipy/pull/9773>`__: DOC: Several
docstrings
* `#9774 <https://github.com/scipy/scipy/pull/9774>`__: TST: bump Azure CI
OpenBLAS version to match wheels
* `#9775 <https://github.com/scipy/scipy/pull/9775>`__: DOC: Improve
clarity of cov_x documentation for scipy.optimize.leastsq
* `#9779 <https://github.com/scipy/scipy/pull/9779>`__: ENH: dual_annealing
vectorise visit_fn
* `#9788 <https://github.com/scipy/scipy/pull/9788>`__: TST, BUG:
f2py-related issues with NumPy < 1.14.0
* `#9791 <https://github.com/scipy/scipy/pull/9791>`__: BUG: fix amax
constraint not enforced in scalar_search_wolfe2
* `#9792 <https://github.com/scipy/scipy/pull/9792>`__: ENH: Allow inplace
copying in place in "detrend" function
* `#9795 <https://github.com/scipy/scipy/pull/9795>`__: DOC: Fix/update
docstring for dstn and dst
* `#9796 <https://github.com/scipy/scipy/pull/9796>`__: MAINT: Allow None
tolerances in least_squares
* `#9798 <https://github.com/scipy/scipy/pull/9798>`__: BUG: fixes abort
trap 6 error in scipy issue 9785 in unit tests
* `#9807 <https://github.com/scipy/scipy/pull/9807>`__: MAINT: improve doc
and add alternative keyword to wilcoxon in...
* `#9808 <https://github.com/scipy/scipy/pull/9808>`__: Fix PPoly integrate
and test for CubicSpline
* `#9810 <https://github.com/scipy/scipy/pull/9810>`__: ENH: Add the
geometric standard deviation function
* `#9811 <https://github.com/scipy/scipy/pull/9811>`__: MAINT: remove
invalid derphi default None value in scalar_search_wolfe2
* `#9813 <https://github.com/scipy/scipy/pull/9813>`__: Adapt hamming
distance in C to support weights
* `#9817 <https://github.com/scipy/scipy/pull/9817>`__: DOC: Copy solver
description to solver modules
* `#9829 <https://github.com/scipy/scipy/pull/9829>`__: ENH: Add FOH and
equivalent impulse response discretizations...
* `#9831 <https://github.com/scipy/scipy/pull/9831>`__: ENH: Implement
RotationSpline
* `#9834 <https://github.com/scipy/scipy/pull/9834>`__: DOC: Change mielke
distribution default parameters to ensure...
* `#9838 <https://github.com/scipy/scipy/pull/9838>`__: ENH: Use faster
solvers for firls
* `#9854 <https://github.com/scipy/scipy/pull/9854>`__: ENH: loadarff now
supports relational attributes.
* `#9856 <https://github.com/scipy/scipy/pull/9856>`__: integrate.bvp -
improve handling of nonlinear boundary conditions
* `#9862 <https://github.com/scipy/scipy/pull/9862>`__: TST: reduce
Appveyor CI load
* `#9874 <https://github.com/scipy/scipy/pull/9874>`__: DOC: Update
requirements in release notes
* `#9883 <https://github.com/scipy/scipy/pull/9883>`__: BUG: fixed
parenthesis in spatial.rotation
* `#9884 <https://github.com/scipy/scipy/pull/9884>`__: ENH: Use Sparsity
in Clarkson-Woodruff Sketch
* `#9888 <https://github.com/scipy/scipy/pull/9888>`__: MAINT: Replace
NumPy aliased functions
* `#9892 <https://github.com/scipy/scipy/pull/9892>`__: BUG: Fix 9890
query_ball_point returns wrong result when p is...
* `#9893 <https://github.com/scipy/scipy/pull/9893>`__: BUG: curve_fit
doesn't check for empty input if called with bounds
* `#9894 <https://github.com/scipy/scipy/pull/9894>`__:
scipy.signal.find_peaks documentation error
* `#9898 <https://github.com/scipy/scipy/pull/9898>`__: BUG: Set success
attribute in OptimizeResult. See #9801
* `#9900 <https://github.com/scipy/scipy/pull/9900>`__: BUG: Restrict
rv_generic._argcheck() and its overrides from setting...
* `#9906 <https://github.com/scipy/scipy/pull/9906>`__: fixed a bug in kde
logpdf
* `#9911 <https://github.com/scipy/scipy/pull/9911>`__: DOC: replace
example for "np.select" with the one from numpy...
* `#9912 <https://github.com/scipy/scipy/pull/9912>`__: BF(DOC): point to
numpy.select instead of plain (python) .select
* `#9914 <https://github.com/scipy/scipy/pull/9914>`__: DOC: change
ValueError message in _validate_pad of signaltools.
* `#9915 <https://github.com/scipy/scipy/pull/9915>`__: cKDTree
query_ball_point improvements
* `#9918 <https://github.com/scipy/scipy/pull/9918>`__: Update ckdtree.pyx
with boxsize argument in docstring
* `#9920 <https://github.com/scipy/scipy/pull/9920>`__: BUG: sparse:
Validate explicit shape if given with dense argument...
* `#9924 <https://github.com/scipy/scipy/pull/9924>`__: BLD: add back
pyproject.toml
* `#9931 <https://github.com/scipy/scipy/pull/9931>`__: Fix empty constraint
* `#9935 <https://github.com/scipy/scipy/pull/9935>`__: DOC: fix references
for stats.f_oneway
* `#9936 <https://github.com/scipy/scipy/pull/9936>`__: Revert gh-9619:
"FIX: Sparse matrix addition/subtraction eliminates...
* `#9937 <https://github.com/scipy/scipy/pull/9937>`__: MAINT: fix PEP8
issues and update to pycodestyle 2.5.0
* `#9939 <https://github.com/scipy/scipy/pull/9939>`__: DOC: correct
\`structure\` description in \`ndimage.label\` docstring
* `#9940 <https://github.com/scipy/scipy/pull/9940>`__: MAINT: remove
extraneous distutils copies
* `#9945 <https://github.com/scipy/scipy/pull/9945>`__: ENH:
differential_evolution can use Bounds object
* `#9949 <https://github.com/scipy/scipy/pull/9949>`__: Added 'std' to add
doctstrings since it is a \`known_stats\`...
* `#9953 <https://github.com/scipy/scipy/pull/9953>`__: DOC: Documentation
cleanup for stats tutorials.
* `#9962 <https://github.com/scipy/scipy/pull/9962>`__: __repr__ for Bounds
* `#9971 <https://github.com/scipy/scipy/pull/9971>`__: ENH: Improve
performance of lsmr
* `#9987 <https://github.com/scipy/scipy/pull/9987>`__: CI: pin Sphinx
version to 1.8.5
* `#9990 <https://github.com/scipy/scipy/pull/9990>`__: ENH: constraint
violation
* `#9991 <https://github.com/scipy/scipy/pull/9991>`__: BUG: Avoid inplace
modification of input array in newton
* `#9995 <https://github.com/scipy/scipy/pull/9995>`__: MAINT:
sparse.csgraph: Add cdef to stop build warning.
* `#9996 <https://github.com/scipy/scipy/pull/9996>`__: BUG: Make
minimize_quadratic_1d work with infinite bounds correctly
* `#10004 <https://github.com/scipy/scipy/pull/10004>`__: BUG: Fix unbound
local error in linprog - simplex.
* `#10007 <https://github.com/scipy/scipy/pull/10007>`__: BLD: fix Python
3.7 build with build isolation
* `#10009 <https://github.com/scipy/scipy/pull/10009>`__: BUG: Make sure
that _binary_erosion only accepts an integer number...
* `#10016 <https://github.com/scipy/scipy/pull/10016>`__: Update link to
airspeed-velocity
* `#10017 <https://github.com/scipy/scipy/pull/10017>`__: DOC: Update
\`interpolate.LSQSphereBivariateSpline\` to include...
* `#10018 <https://github.com/scipy/scipy/pull/10018>`__: MAINT: special:
Fix a few warnings that occur when compiling...
* `#10019 <https://github.com/scipy/scipy/pull/10019>`__: TST: Azure
summarizes test failures
* `#10021 <https://github.com/scipy/scipy/pull/10021>`__: ENH: Introduce
CubicHermiteSpline
* `#10022 <https://github.com/scipy/scipy/pull/10022>`__: BENCH: Increase
cython version in asv to fix benchmark builds
* `#10023 <https://github.com/scipy/scipy/pull/10023>`__: BUG: Avoid
exponnorm producing nan for small K values.
* `#10025 <https://github.com/scipy/scipy/pull/10025>`__: BUG: optimize:
tweaked linprog status 4 error message
* `#10026 <https://github.com/scipy/scipy/pull/10026>`__: ENH: optimize:
use SuiteSparse in linprog interior-point when...
* `#10027 <https://github.com/scipy/scipy/pull/10027>`__: MAINT: cluster:
clean up the use of malloc() in the function...
* `#10028 <https://github.com/scipy/scipy/pull/10028>`__: Fix rotate
invalid plane check
* `#10040 <https://github.com/scipy/scipy/pull/10040>`__: MAINT: fix pratt
method of wilcox test in scipy.stats
* `#10041 <https://github.com/scipy/scipy/pull/10041>`__: MAINT: special:
Fix a warning generated when building the AMOS...
* `#10044 <https://github.com/scipy/scipy/pull/10044>`__: DOC: fix up
spatial.transform.Rotation docstrings
* `#10047 <https://github.com/scipy/scipy/pull/10047>`__: MAINT:
interpolate: Fix a few build warnings.
* `#10051 <https://github.com/scipy/scipy/pull/10051>`__: Add project_urls
to setup
* `#10052 <https://github.com/scipy/scipy/pull/10052>`__: don't set flag to
"converged" if max iter exceeded
* `#10054 <https://github.com/scipy/scipy/pull/10054>`__: MAINT: signal:
Fix a few build warnings and modernize some C...
* `#10056 <https://github.com/scipy/scipy/pull/10056>`__: BUG: Ensure
factorial is not too large in kendaltau
* `#10058 <https://github.com/scipy/scipy/pull/10058>`__: Small speedup in
samping from ortho and special_ortho groups
* `#10059 <https://github.com/scipy/scipy/pull/10059>`__: BUG: optimize:
fix #10038 by increasing tol
* `#10061 <https://github.com/scipy/scipy/pull/10061>`__: BLD: DOC: make
building docs easier by parsing python version.
* `#10064 <https://github.com/scipy/scipy/pull/10064>`__: ENH: Significant
speedup for ortho and special ortho group
* `#10065 <https://github.com/scipy/scipy/pull/10065>`__: DOC: Reword
parameter descriptions in \`optimize.root_scalar\`
* `#10066 <https://github.com/scipy/scipy/pull/10066>`__: BUG: signal: Fix
error raised by savgol_coeffs when deriv > polyorder.
* `#10067 <https://github.com/scipy/scipy/pull/10067>`__: MAINT: Fix the
cutoff value inconsistency for pinv2 and pinvh
* `#10072 <https://github.com/scipy/scipy/pull/10072>`__: BUG: stats: Fix
boxcox_llf to avoid loss of precision.
* `#10075 <https://github.com/scipy/scipy/pull/10075>`__: ENH: Add wrappers
for ?syconv routines
* `#10076 <https://github.com/scipy/scipy/pull/10076>`__: BUG: optimize:
fix curve_fit for mixed float32/float64 input
* `#10077 <https://github.com/scipy/scipy/pull/10077>`__: DOC: Replace
undefined \`k\` in \`interpolate.splev\` docstring
* `#10079 <https://github.com/scipy/scipy/pull/10079>`__: DOC: Fixed typo,
rearranged some doc of stats.morestats.wilcoxon.
* `#10080 <https://github.com/scipy/scipy/pull/10080>`__: TST: install
scikit-sparse for full TravisCI tests
* `#10083 <https://github.com/scipy/scipy/pull/10083>`__: Clean
\`\`_clean_inputs\`\` in optimize.linprog
* `#10088 <https://github.com/scipy/scipy/pull/10088>`__: ENH: optimize:
linprog test CHOLMOD/UMFPACK solvers when available
* `#10090 <https://github.com/scipy/scipy/pull/10090>`__: MAINT: Fix
CubicSplinerInterpolator for pandas
* `#10091 <https://github.com/scipy/scipy/pull/10091>`__: MAINT: improve
logcdf and logsf of hypergeometric distribution
* `#10095 <https://github.com/scipy/scipy/pull/10095>`__: MAINT: Clean
\`\`_clean_inputs\`\` in linprog
* `#10116 <https://github.com/scipy/scipy/pull/10116>`__: MAINT: update
scipy-sphinx-theme
* `#10135 <https://github.com/scipy/scipy/pull/10135>`__: BUG: fix linprog
revised simplex docstring problem failure

Checksums
=========

MD5
~~~

11305bc9940ca76568a1c7e46ea0ff05
scipy-1.3.0rc2-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
7cef904e09aff64d5207064bb61e1a6b
scipy-1.3.0rc2-cp35-cp35m-manylinux1_i686.whl
63ba156855e33b971dc94206ecbdd7f3
scipy-1.3.0rc2-cp35-cp35m-manylinux1_x86_64.whl
00e48cb29dbb88e56730a59285c463ec  scipy-1.3.0rc2-cp35-cp35m-win32.whl
232eb3104f19d1559e30e749a92707cd  scipy-1.3.0rc2-cp35-cp35m-win_amd64.whl
559b152a8b438825ba0352a3303e2651
scipy-1.3.0rc2-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
3b663db47752b092a53179d10f3716ea
scipy-1.3.0rc2-cp36-cp36m-manylinux1_i686.whl
87615391c5020fe1533cc2bac524ea04
scipy-1.3.0rc2-cp36-cp36m-manylinux1_x86_64.whl
900d5b9893bf105d9df219cbcd3f3dab  scipy-1.3.0rc2-cp36-cp36m-win32.whl
5a4bae8f02e87602d710977923490b8b  scipy-1.3.0rc2-cp36-cp36m-win_amd64.whl
3a14e70a42d5fd813b43c587314aae7c
scipy-1.3.0rc2-cp37-cp37m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
56b643dc91bb72d926bd80c844643274
scipy-1.3.0rc2-cp37-cp37m-manylinux1_i686.whl
992832ed9a5431c1ba45aa543f2e7e99
scipy-1.3.0rc2-cp37-cp37m-manylinux1_x86_64.whl
bb78702fc1aaaf425bafc424303a15cc  scipy-1.3.0rc2-cp37-cp37m-win32.whl
e14f12154170624262607c0c30390bc2  scipy-1.3.0rc2-cp37-cp37m-win_amd64.whl
62de7f94825d5b6b99ed44955c3e1965  scipy-1.3.0rc2.tar.gz
461dc0660a84538954a41d3dd91dde71  scipy-1.3.0rc2.tar.xz
6fda886c9976a16fc01a9b639ffbfd8c  scipy-1.3.0rc2.zip

SHA256
~~~~~~

8b860d29b4d0d8d3781bc1d51eaa4fc47a903633d545eba074f5e2bc2cbafaa1
scipy-1.3.0rc2-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
0ba6d287862065eb65c7f3f1ed6285a8abf6dec78e3b7c62f203961ba1eae12e
scipy-1.3.0rc2-cp35-cp35m-manylinux1_i686.whl
0c29f55c00eae36199733a8c214a8a8493bc47dbb822ffe3847cf58150a06f3d
scipy-1.3.0rc2-cp35-cp35m-manylinux1_x86_64.whl
b8744f4505a6674eb3e21f779e90ed8efc0d9ee68e6ea8f0f993433dde2e3aee
scipy-1.3.0rc2-cp35-cp35m-win32.whl
573c1088ed3daf56c52710e28f11baed8b4cdcabc4411f10d1fb9f61221c539b
scipy-1.3.0rc2-cp35-cp35m-win_amd64.whl
134d6969b8025006f7231dfaba611a2314e978cdefa1e0c1b73f7e3010ef807a
scipy-1.3.0rc2-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
13d309d9ddf56601afbe8f66bfb44ec374df912203e98d8ddc4e7433925db488
scipy-1.3.0rc2-cp36-cp36m-manylinux1_i686.whl
c100badbbacf175e2a0122f59575905d092c8080cb2fa40cade0b9c0a0ae1f8c
scipy-1.3.0rc2-cp36-cp36m-manylinux1_x86_64.whl
87b5f5990b4d580fb6b7eaaeb01e756f5aa9ebedc514dece67a2f79e33c7528e
scipy-1.3.0rc2-cp36-cp36m-win32.whl
51a7d7b15cd44af1221d5d6c54bf8da470f7de6117bc525f8e8e75ef65a23ccc
scipy-1.3.0rc2-cp36-cp36m-win_amd64.whl
e4d90d5cc4e3896816d1c31952017bbe4e26a0222702eef046c4a5d2b7f4c9b6
scipy-1.3.0rc2-cp37-cp37m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
2799e2c07a9600a21e73756578cde0a8426009b525572ae32f3acb6246642d37
scipy-1.3.0rc2-cp37-cp37m-manylinux1_i686.whl
ecacc8e4aa91ee90c5499b97c517a61d447da25774c65d3938f2c5916fd2981d
scipy-1.3.0rc2-cp37-cp37m-manylinux1_x86_64.whl
e8890f4407db3395873973a416a92ddd496e369b01f4273dd85d187bd9ab2b65
scipy-1.3.0rc2-cp37-cp37m-win32.whl
3c913244a1b34b83ec2a2ba3fc168210db13529a15706c0242499975caf59e61
scipy-1.3.0rc2-cp37-cp37m-win_amd64.whl
c7299e4eb2420cfdedd8b090fce549d29fb06c09f5046251f7aa48f7d55fe1c2
scipy-1.3.0rc2.tar.gz
950b6a4cffba2cc25e655489f9a883d6ae8ea97708e5f0a2af9b624c57a27e59
scipy-1.3.0rc2.tar.xz
d69f331044d9214dc6a117d4e090d6a1240ccc0c4faaaa6dc49402ecf087dea4
scipy-1.3.0rc2.zip
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJc1FGzAAoJELD/41ZX0J715p0P+wfhJw/hSdZPnh+kIt40rGlO
UsiAycApbmWSmHCjlyb3EdLJPW7WC9MoF1JUXfX2X6YFnJ9LF4TUhiFlmf3mgpJC
3nklRqZYaF5GPkm+akThOvTYEoxLwobuPEa9vEeYjDMCxrOdrf9bAsHXoeotspFL
NWCvEAbTfghHWjNT1Ug6/oZBBlKrjzlcPYAgzhnL9eQudGdOkvY9NW8DCLoXcuA9
FMQqMnE8SbqSYIvM6udXWbZUHbySwITLFC5h/dIXjDWNbTznb5TyCvhzfKl3GHjp
sdrkyZrNhkYPp5W3mr1PV42gIci/Nd7NGhfTMlEWCON3/P+jgR1COE+aMUO5VkTH
+620ukPBd/SI0gFG03JctJT2X+6OgqnwXfVkOKbnCI7XWM3I+P0xfLAfHEIaS6+M
OrExq9tfDiX9p+CcyGFqZvrkDifq0fglFxQ5cExCQ4+lNVjGci3pC6OJLktR1h2W
JJPONQH3YqJIfCUNhfSt2X873dcLNwQiI7rTm76cvxhAqAYK5ZwMoNG2nqpQdB+Z
DnOAMQGLwntwm55gi4JQW7Yrx72avsJNrH5s4q6Qt1sKJ/vzZabB5gW61e6r5rYH
lqro/09hvnn/7t1J+Snpb1ZlUkp0F/oS4Uh/PSPXONDzE5LprimJ3pCFCObMNdu2
rQKhjhgPhJMzI2+U0gHN
=7jl+
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190509/145f5cea/attachment-0001.html>

From ralf.gommers at gmail.com  Thu May  9 15:47:18 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Thu, 9 May 2019 21:47:18 +0200
Subject: [SciPy-Dev] Backend support for fftpack - GSoC 2019
In-Reply-To: <CAFpSVpKB1WBOtC6Q3FME8XASbRSJNQWW+9OtNTMkx2inb2miDg@mail.gmail.com>
References: <DB6PR04MB320650B383909FE340B38EEF8E320@DB6PR04MB3206.eurprd04.prod.outlook.com>
 <CAFpSVp+k1db-k_3oXQSvDKuW60Vj+V5maB7y0ygjbC0hnon8xw@mail.gmail.com>
 <DB6PR04MB320690032D268C73C2622F048E330@DB6PR04MB3206.eurprd04.prod.outlook.com>
 <CAFpSVpKB1WBOtC6Q3FME8XASbRSJNQWW+9OtNTMkx2inb2miDg@mail.gmail.com>
Message-ID: <CABL7CQjBbV7C99tP8XqW9ERx5oBHa29FR8AksurFrCLXGBEqMg@mail.gmail.com>

On Thu, May 9, 2019 at 6:04 PM Todd <toddrjen at gmail.com> wrote:

> On Thu, May 9, 2019 at 10:55 AM Peter Bell <PeterBell10 at live.co.uk> wrote:
>
>> > This would be a bit more extreme, but might this be better in numpy?
>>
>>
>>
>> AFAIK the main issue here is that NumPy and SciPy have incompatible APIs
>> and
>>
>> SciPy also has more types of transforms like DCT and DST. It also seems
>> that the
>>
>> scipy functions are generally intended to be preferred over numpy. I think
>>
>> keeping it in scipy is also consistent with modules like linalg where
>> there is
>>
>> some duplication but generally more functionality in scipy.
>>
>>
>>
>> See:
>>
>> https://github.com/scipy/scipy/issues/2487
>>
>> https://scipy.github.io/devdocs/roadmap-detailed.html#fftpack
>>
>
> Yes, these are the sorts of issues this idea would fix.  However, adding
> backend support to scipy wouldn't fix these issues, since the duplication
> these discuss would still exist in numpy.
>

The problem is simply orthogonal to the backend feature. We have two very
similar but slightly incompatible APIs in NumPy and SciPy, and evolving
those to match is tricky. We do want to get them to match, but no one has
sat down to create a good plan for how to achieve that. Once they match,
the implementation of the SciPy functions that also exist in NumPy could
indeed be removed and those functions could simply be aliased to the NumPy
ones instead.

Also note that NumPy just switched to Pocketfft, and for SciPy we want to
do that too. So at that point the implementations really are duplicate.


>
>> > As I understand it, at least traditionally, numpy has been easier to
>> install
>>
>> > due to not needing a Fortran compiler
>>
>>
>>
>> It should be easy enough to say `pip install scipy` pretty much anywhere,
>> right?
>>
>> And for those going out of their way to compile themself, I'm not sure
>> that a
>>
>> fortran compiler is that much more of a burden.
>>
>
> As I said, this was a problem traditionally, before wheels and openblas.
>
>
>> > However, looking at some of the code that uses FFTs in scipy, it falls
>> back on
>>
>> > numpy's FFT because it supports data types scipy doesn't
>>
>>
>>
>> Could you give some examples of this? I thought scipy generally supported
>> a
>>
>> wider variety of both transforms and dtypes.
>>
> I had the problem backwards.  scipy supports more dtypes, but is slower,
> at least according to comments in fftconvolve:
>
> https://github.com/scipy/scipy/blob/master/scipy/signal/signaltools.py#L409
>

"Pre-1.9 NumPy FFT routines are not threadsafe." --> that can be ripped out
now. I don't see where it says it's slower, it shouldn't be. Anyway, not
worth looking at if we replace fftpack with Pocketfft anyway.

Cheers,
Ralf


>
> Peter
>>
>>
>>
>>
>>
>> *From:* SciPy-Dev <scipy-dev-bounces+peterbell10=live.co.uk at python.org> *On
>> Behalf Of *Todd
>> *Sent:* 09 May 2019 14:55
>> *To:* SciPy Developers List <scipy-dev at python.org>
>> *Subject:* Re: [SciPy-Dev] Backend support for fftpack - GSoC 2019
>>
>>
>>
>> On Wed, May 8, 2019, 11:50 Peter Bell <PeterBell10 at live.co.uk> wrote:
>>
>> Hello all,
>>
>>
>>
>> I?m happy to say my GSoC proposal was accepted, so I?ll be working over
>> the summer to add support for multiple fftpack backends. For those
>> interested, I?ve extracted the main discussion from my proposal which you
>> can read here:
>>
>>
>> https://docs.google.com/document/d/1hGMc6ZrsmSi_LSixI5oFbo5cZkPUo92sfmnVthg1u6Y/edit
>>
>>
>>
>> There are a several design decisions I raise in the proposal and any
>> comments would be appreciated. Of particular note:
>>
>> * Should backends be allowed to add functionality or should they be
>> completely interchangeable. E.g. unlike fftpack, FFTW has support for long
>> doubles; should this be exposed to SciPy users?
>>
>> * Is there any interest in adding a SciPy config file? For just one
>> option it?s probably not worthwhile but if there is interest in more config
>> options then it starts to make more sense.
>>
>>
>>
>> Ideally a clear set of design goals can be agreed upon now, before it
>> gets too far into the coding period which begins at the end of the month.
>>
>>
>>
>> Peter
>>
>>
>>
>> This would be a bit more extreme, but might this be better in numpy?
>>
>>
>>
>> As I understand it, at least traditionally, numpy has been easier to
>> install due to not needing a Fortran compiler, but scipy has a generally
>> faster FFT implementation.
>>
>>
>>
>> However, looking at some of the code that uses FFTs in scipy, it falls
>> back on numpy's FFT because it supports data types scipy doesn't at least
>> for some implementations. This code will either silently do the wrong thing
>> or will have to have more complicated run-time checks for data types if we
>> get backend support in scipy.
>>
>>
>>
>> However, if the backend support were implemented in numpy we could
>> simplify all this code.  numpy could be in charge of handling fall-backs if
>> the requested operation doesn't support the given date type.
>>
>>
>>
>> Specifically, numpy would have its own FFT back-end.  If scipy is
>> available it will be used as the default back-end, otherwise the numpy
>> back-end will be used.  The user can choose a different backend (including
>> the numpy backend if they want).  The user-facing scipy functions would use
>> the numpy functions behind-the-scenes.  If the requested operation is not
>> supported by the requested backend, numpy will emit a warning and fall back
>> on the numpy version.
>>
>>
>>
>> This has a few other advantages besides allowing us to simplify the scipy
>> code-base. First, it will remove the existing confusion regarding whether
>> to use the numpy or scipy version of FFT functions.  Second, with the new
>> rng work there is already stuff in numpy that would benefit from a config
>> file (the fallback warning above could also be configurable).
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190509/44a7ad8d/attachment.html>

From mikofski at berkeley.edu  Fri May 10 02:44:54 2019
From: mikofski at berkeley.edu (Mark Mikofski)
Date: Thu, 9 May 2019 23:44:54 -0700
Subject: [SciPy-Dev] Schumaker quadratic spline
Message-ID: <CAEqRcW3d97DBXqdO5hSQ9aGr740Hi01FC8Ss5EavzT2-7Bf-CA@mail.gmail.com>

Hi All,

Sorry for this unresearched and inexperienced question.

Does anyone have any experience with the "Schumaker quadratic spline" for
1-D interpolation? Is it similar enough to the BSpline already in SciPy?

I have some source code that I can contribute if there's interest.

As far as references, a google search turned up an R function:
*
https://cran.r-project.org/web/packages/schumaker/vignettes/schumaker.html

-- 
Mark Mikofski, PhD (2005)
*Fiat Lux*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190509/b10bde76/attachment-0001.html>

From evgeny.burovskiy at gmail.com  Fri May 10 03:26:18 2019
From: evgeny.burovskiy at gmail.com (Evgeni Burovski)
Date: Fri, 10 May 2019 10:26:18 +0300
Subject: [SciPy-Dev] Schumaker quadratic spline
In-Reply-To: <CAEqRcW3d97DBXqdO5hSQ9aGr740Hi01FC8Ss5EavzT2-7Bf-CA@mail.gmail.com>
References: <CAEqRcW3d97DBXqdO5hSQ9aGr740Hi01FC8Ss5EavzT2-7Bf-CA@mail.gmail.com>
Message-ID: <CAMRo0ivbGJBfXF=WJaY_ZxkiymA9DPDWVFjEuN3y5pU5ZgbU0g@mail.gmail.com>

Hi Mark,

The docs you linked reference https://epubs.siam.org/doi/10.1137/0720057
which is gated, so only an impression: this seems to construct a
shape-preserving piecewise quadratic interpolant. We have two
shape-preserving cubic interpolants, PCHIP and Akima. Do you have an
overview of how this one compares to them?

Off the cuff, I guess we can add a shape-preserving quadratic, too. This
should be based on either BSpline or PPoly, depending on the basis the
construction is in.
(My impression is that it's the latter in the R package).
The API should mirror that of Akima1DInterpolator.




??, 10 ??? 2019 ?., 9:45 Mark Mikofski <mikofski at berkeley.edu>:

> Hi All,
>
> Sorry for this unresearched and inexperienced question.
>
> Does anyone have any experience with the "Schumaker quadratic spline" for
> 1-D interpolation? Is it similar enough to the BSpline already in SciPy?
>
> I have some source code that I can contribute if there's interest.
>
> As far as references, a google search turned up an R function:
> *
> https://cran.r-project.org/web/packages/schumaker/vignettes/schumaker.html
>
>
> --
> Mark Mikofski, PhD (2005)
> *Fiat Lux*
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190510/87e4986c/attachment.html>

From larson.eric.d at gmail.com  Fri May 10 11:28:15 2019
From: larson.eric.d at gmail.com (Eric Larson)
Date: Fri, 10 May 2019 11:28:15 -0400
Subject: [SciPy-Dev] Backend support for fftpack - GSoC 2019
In-Reply-To: <CABL7CQjBbV7C99tP8XqW9ERx5oBHa29FR8AksurFrCLXGBEqMg@mail.gmail.com>
References: <DB6PR04MB320650B383909FE340B38EEF8E320@DB6PR04MB3206.eurprd04.prod.outlook.com>
 <CAFpSVp+k1db-k_3oXQSvDKuW60Vj+V5maB7y0ygjbC0hnon8xw@mail.gmail.com>
 <DB6PR04MB320690032D268C73C2622F048E330@DB6PR04MB3206.eurprd04.prod.outlook.com>
 <CAFpSVpKB1WBOtC6Q3FME8XASbRSJNQWW+9OtNTMkx2inb2miDg@mail.gmail.com>
 <CABL7CQjBbV7C99tP8XqW9ERx5oBHa29FR8AksurFrCLXGBEqMg@mail.gmail.com>
Message-ID: <CAGu2niVFM2F6ObS3-Hi0cnLF5Lb0tdO5vQbfNrqJ-=0_dBcLsQ@mail.gmail.com>

>
> I had the problem backwards.  scipy supports more dtypes, but is slower,
>> at least according to comments in fftconvolve:
>>
>>
>> https://github.com/scipy/scipy/blob/master/scipy/signal/signaltools.py#L409
>>
>
> "Pre-1.9 NumPy FFT routines are not threadsafe." --> that can be ripped
> out now. I don't see where it says it's slower, it shouldn't be. Anyway,
> not worth looking at if we replace fftpack with Pocketfft anyway.
>

This part at least is done already in
https://github.com/scipy/scipy/pull/9876.

Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190510/9534eec9/attachment.html>

From jonathanconroy14 at gmail.com  Mon May 13 19:15:06 2019
From: jonathanconroy14 at gmail.com (Jonathan Conroy)
Date: Mon, 13 May 2019 19:15:06 -0400
Subject: [SciPy-Dev] Prerequisites for contributing?
Message-ID: <38862AD5-A2AA-4225-B758-AD9DD9B90349@gmail.com>

Hi all,

I'm Jonathan, a rising sophomore studying math and computer science. I'm hoping to start contributing to open source software over the summer and SciPy seems like a really interesting library, but I'm worried I don't have the experience to make meaningful contributions. I'm looking for advice on whether or not I have the background to contribute.

In terms of coursework, I've taken Data Structures & Algorithms and Machine Architecture, and I've had calculus, linear algebra, and a bit of real analysis. I'll be taking a few machine learning courses next year (and will be using SciPy in them), but as of right now I haven't used SciPy in any large projects. That being said, I have a bunch of time on my hands and would be eager to spend it learning the codebase this summer.

Do you think contributing to SciPy would be doable/worthwhile for me, or would you recommend looking for other projects and returning to SciPy later on? Are there any specific SciPy modules that would be more accessable than others? Any advice is appreciated!

Thanks for your time,
Jonathan Conroy

From ralf.gommers at gmail.com  Tue May 14 06:01:27 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Tue, 14 May 2019 12:01:27 +0200
Subject: [SciPy-Dev] Backend support for fftpack - GSoC 2019
In-Reply-To: <DB6PR04MB320690032D268C73C2622F048E330@DB6PR04MB3206.eurprd04.prod.outlook.com>
References: <DB6PR04MB320650B383909FE340B38EEF8E320@DB6PR04MB3206.eurprd04.prod.outlook.com>
 <CAFpSVp+k1db-k_3oXQSvDKuW60Vj+V5maB7y0ygjbC0hnon8xw@mail.gmail.com>
 <DB6PR04MB320690032D268C73C2622F048E330@DB6PR04MB3206.eurprd04.prod.outlook.com>
Message-ID: <CABL7CQgOA-4W_x+S4aw3=Pwe0TCg5x7mquQbgiJY14jSHP6fKw@mail.gmail.com>

On Thu, May 9, 2019 at 4:54 PM Peter Bell <PeterBell10 at live.co.uk> wrote:

> > This would be a bit more extreme, but might this be better in numpy?
>
>
>
> AFAIK the main issue here is that NumPy and SciPy have incompatible APIs
> and
>
> SciPy also has more types of transforms like DCT and DST. It also seems
> that the
>
> scipy functions are generally intended to be preferred over numpy. I think
>
> keeping it in scipy is also consistent with modules like linalg where
> there is
>
> some duplication but generally more functionality in scipy.
>

For who is interested in these, please read
https://github.com/scipy/scipy/issues/10175. That started as "hey there's a
new C++ PyPocketfft" (which looks cool), and evolved into "let's create a
scipy.fft module with an API that mirrors numpy.fft and gets the backend
system".

Peter, I now read your whole document more carefully, really interesting. I
tried to comment on some of the smaller things to not mix those up with the
discussion on the GitHub issue, but the doc is view-only. Perhaps you can
switch it to "suggest edits" mode to let people insert comments?

Cheers,
Ralf


>
> See:
>
> https://github.com/scipy/scipy/issues/2487
>
> https://scipy.github.io/devdocs/roadmap-detailed.html#fftpack
>
>
>
> > As I understand it, at least traditionally, numpy has been easier to
> install
>
> > due to not needing a Fortran compiler
>
>
>
> It should be easy enough to say `pip install scipy` pretty much anywhere,
> right?
>
> And for those going out of their way to compile themself, I'm not sure
> that a
>
> fortran compiler is that much more of a burden.
>
>
>
> > However, looking at some of the code that uses FFTs in scipy, it falls
> back on
>
> > numpy's FFT because it supports data types scipy doesn't
>
>
>
> Could you give some examples of this? I thought scipy generally supported a
>
> wider variety of both transforms and dtypes.
>
>
>
> Peter
>
>
>
>
>
> *From:* SciPy-Dev <scipy-dev-bounces+peterbell10=live.co.uk at python.org> *On
> Behalf Of *Todd
> *Sent:* 09 May 2019 14:55
> *To:* SciPy Developers List <scipy-dev at python.org>
> *Subject:* Re: [SciPy-Dev] Backend support for fftpack - GSoC 2019
>
>
>
> On Wed, May 8, 2019, 11:50 Peter Bell <PeterBell10 at live.co.uk> wrote:
>
> Hello all,
>
>
>
> I?m happy to say my GSoC proposal was accepted, so I?ll be working over
> the summer to add support for multiple fftpack backends. For those
> interested, I?ve extracted the main discussion from my proposal which you
> can read here:
>
>
> https://docs.google.com/document/d/1hGMc6ZrsmSi_LSixI5oFbo5cZkPUo92sfmnVthg1u6Y/edit
>
>
>
> There are a several design decisions I raise in the proposal and any
> comments would be appreciated. Of particular note:
>
> * Should backends be allowed to add functionality or should they be
> completely interchangeable. E.g. unlike fftpack, FFTW has support for long
> doubles; should this be exposed to SciPy users?
>
> * Is there any interest in adding a SciPy config file? For just one option
> it?s probably not worthwhile but if there is interest in more config
> options then it starts to make more sense.
>
>
>
> Ideally a clear set of design goals can be agreed upon now, before it gets
> too far into the coding period which begins at the end of the month.
>
>
>
> Peter
>
>
>
> This would be a bit more extreme, but might this be better in numpy?
>
>
>
> As I understand it, at least traditionally, numpy has been easier to
> install due to not needing a Fortran compiler, but scipy has a generally
> faster FFT implementation.
>
>
>
> However, looking at some of the code that uses FFTs in scipy, it falls
> back on numpy's FFT because it supports data types scipy doesn't at least
> for some implementations. This code will either silently do the wrong thing
> or will have to have more complicated run-time checks for data types if we
> get backend support in scipy.
>
>
>
> However, if the backend support were implemented in numpy we could
> simplify all this code.  numpy could be in charge of handling fall-backs if
> the requested operation doesn't support the given date type.
>
>
>
> Specifically, numpy would have its own FFT back-end.  If scipy is
> available it will be used as the default back-end, otherwise the numpy
> back-end will be used.  The user can choose a different backend (including
> the numpy backend if they want).  The user-facing scipy functions would use
> the numpy functions behind-the-scenes.  If the requested operation is not
> supported by the requested backend, numpy will emit a warning and fall back
> on the numpy version.
>
>
>
> This has a few other advantages besides allowing us to simplify the scipy
> code-base. First, it will remove the existing confusion regarding whether
> to use the numpy or scipy version of FFT functions.  Second, with the new
> rng work there is already stuff in numpy that would benefit from a config
> file (the fallback warning above could also be configurable).
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190514/81c1e7a1/attachment.html>

From PeterBell10 at live.co.uk  Tue May 14 06:10:17 2019
From: PeterBell10 at live.co.uk (Peter Bell)
Date: Tue, 14 May 2019 10:10:17 +0000
Subject: [SciPy-Dev] Backend support for fftpack - GSoC 2019
In-Reply-To: <CABL7CQgOA-4W_x+S4aw3=Pwe0TCg5x7mquQbgiJY14jSHP6fKw@mail.gmail.com>
References: <DB6PR04MB320650B383909FE340B38EEF8E320@DB6PR04MB3206.eurprd04.prod.outlook.com>
 <CAFpSVp+k1db-k_3oXQSvDKuW60Vj+V5maB7y0ygjbC0hnon8xw@mail.gmail.com>
 <DB6PR04MB320690032D268C73C2622F048E330@DB6PR04MB3206.eurprd04.prod.outlook.com>
 <CABL7CQgOA-4W_x+S4aw3=Pwe0TCg5x7mquQbgiJY14jSHP6fKw@mail.gmail.com>
Message-ID: <DB6PR04MB320638C79AB4950FDE2FD4218E080@DB6PR04MB3206.eurprd04.prod.outlook.com>

> Peter, I now read your whole document more carefully, really interesting. I tried to comment on some of the smaller things to not mix those up with the discussion on the GitHub issue, but the doc is view-only. Perhaps you can switch it to "suggest edits" mode to let people insert comments?

Ralf, I?ve updated the permissions so you should now be able to comment from what I think is the same link as before:
https://docs.google.com/document/d/1hGMc6ZrsmSi_LSixI5oFbo5cZkPUo92sfmnVthg1u6Y/edit?usp=sharing

Peter

From: SciPy-Dev <scipy-dev-bounces+peterbell10=live.co.uk at python.org> On Behalf Of Ralf Gommers
Sent: 14 May 2019 11:01
To: SciPy Developers List <scipy-dev at python.org>
Subject: Re: [SciPy-Dev] Backend support for fftpack - GSoC 2019



On Thu, May 9, 2019 at 4:54 PM Peter Bell <PeterBell10 at live.co.uk<mailto:PeterBell10 at live.co.uk>> wrote:

> This would be a bit more extreme, but might this be better in numpy?



AFAIK the main issue here is that NumPy and SciPy have incompatible APIs and

SciPy also has more types of transforms like DCT and DST. It also seems that the

scipy functions are generally intended to be preferred over numpy. I think

keeping it in scipy is also consistent with modules like linalg where there is

some duplication but generally more functionality in scipy.

For who is interested in these, please read https://github.com/scipy/scipy/issues/10175. That started as "hey there's a new C++ PyPocketfft" (which looks cool), and evolved into "let's create a scipy.fft module with an API that mirrors numpy.fft and gets the backend system".

Peter, I now read your whole document more carefully, really interesting. I tried to comment on some of the smaller things to not mix those up with the discussion on the GitHub issue, but the doc is view-only. Perhaps you can switch it to "suggest edits" mode to let people insert comments?

Cheers,
Ralf




See:

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

https://scipy.github.io/devdocs/roadmap-detailed.html#fftpack



> As I understand it, at least traditionally, numpy has been easier to install

> due to not needing a Fortran compiler



It should be easy enough to say `pip install scipy` pretty much anywhere, right?

And for those going out of their way to compile themself, I'm not sure that a

fortran compiler is that much more of a burden.



> However, looking at some of the code that uses FFTs in scipy, it falls back on

> numpy's FFT because it supports data types scipy doesn't



Could you give some examples of this? I thought scipy generally supported a

wider variety of both transforms and dtypes.



Peter


From: SciPy-Dev <scipy-dev-bounces+peterbell10=live.co.uk at python.org<mailto:live.co.uk at python.org>> On Behalf Of Todd
Sent: 09 May 2019 14:55
To: SciPy Developers List <scipy-dev at python.org<mailto:scipy-dev at python.org>>
Subject: Re: [SciPy-Dev] Backend support for fftpack - GSoC 2019

On Wed, May 8, 2019, 11:50 Peter Bell <PeterBell10 at live.co.uk<mailto:PeterBell10 at live.co.uk>> wrote:
Hello all,

I?m happy to say my GSoC proposal was accepted, so I?ll be working over the summer to add support for multiple fftpack backends. For those interested, I?ve extracted the main discussion from my proposal which you can read here:
https://docs.google.com/document/d/1hGMc6ZrsmSi_LSixI5oFbo5cZkPUo92sfmnVthg1u6Y/edit

There are a several design decisions I raise in the proposal and any comments would be appreciated. Of particular note:
* Should backends be allowed to add functionality or should they be completely interchangeable. E.g. unlike fftpack, FFTW has support for long doubles; should this be exposed to SciPy users?
* Is there any interest in adding a SciPy config file? For just one option it?s probably not worthwhile but if there is interest in more config options then it starts to make more sense.

Ideally a clear set of design goals can be agreed upon now, before it gets too far into the coding period which begins at the end of the month.

Peter

This would be a bit more extreme, but might this be better in numpy?

As I understand it, at least traditionally, numpy has been easier to install due to not needing a Fortran compiler, but scipy has a generally faster FFT implementation.

However, looking at some of the code that uses FFTs in scipy, it falls back on numpy's FFT because it supports data types scipy doesn't at least for some implementations. This code will either silently do the wrong thing or will have to have more complicated run-time checks for data types if we get backend support in scipy.

However, if the backend support were implemented in numpy we could simplify all this code.  numpy could be in charge of handling fall-backs if the requested operation doesn't support the given date type.

Specifically, numpy would have its own FFT back-end.  If scipy is available it will be used as the default back-end, otherwise the numpy back-end will be used.  The user can choose a different backend (including the numpy backend if they want).  The user-facing scipy functions would use the numpy functions behind-the-scenes.  If the requested operation is not supported by the requested backend, numpy will emit a warning and fall back on the numpy version.

This has a few other advantages besides allowing us to simplify the scipy code-base. First, it will remove the existing confusion regarding whether to use the numpy or scipy version of FFT functions.  Second, with the new rng work there is already stuff in numpy that would benefit from a config file (the fallback warning above could also be configurable).
_______________________________________________
SciPy-Dev mailing list
SciPy-Dev at python.org<mailto:SciPy-Dev at python.org>
https://mail.python.org/mailman/listinfo/scipy-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190514/b49ff24c/attachment-0001.html>

From haberland at ucla.edu  Tue May 14 12:49:47 2019
From: haberland at ucla.edu (Matt Haberland)
Date: Tue, 14 May 2019 09:49:47 -0700
Subject: [SciPy-Dev] Prerequisites for contributing?
In-Reply-To: <38862AD5-A2AA-4225-B758-AD9DD9B90349@gmail.com>
References: <38862AD5-A2AA-4225-B758-AD9DD9B90349@gmail.com>
Message-ID: <CADuxUiwbXgeoDF2GUMnWQAJAMsLJb7qLoaQF28yjbRgQ5rzckw@mail.gmail.com>

Hi Jonathan,

There's plenty of relatively low-hanging fruit for you to get started with.
Take a look at the list of issues marked "good first issue" for something
you'd like to try.
https://github.com/scipy/scipy/labels/good%20first%20issue

This document <http://scipy.github.io/devdocs/hacking.html> has been the
traditional starting point for new contributors, but you might take a look
at this recently drafted table of contents
<https://github.com/scipy/scipy/wiki/SciPy-Development-Table-of-Contents>,
too. If you go through it, please let me know how it can be improved.

Matt Haberland

On Mon, May 13, 2019 at 4:15 PM Jonathan Conroy <jonathanconroy14 at gmail.com>
wrote:

> Hi all,
>
> I'm Jonathan, a rising sophomore studying math and computer science. I'm
> hoping to start contributing to open source software over the summer and
> SciPy seems like a really interesting library, but I'm worried I don't have
> the experience to make meaningful contributions. I'm looking for advice on
> whether or not I have the background to contribute.
>
> In terms of coursework, I've taken Data Structures & Algorithms and
> Machine Architecture, and I've had calculus, linear algebra, and a bit of
> real analysis. I'll be taking a few machine learning courses next year (and
> will be using SciPy in them), but as of right now I haven't used SciPy in
> any large projects. That being said, I have a bunch of time on my hands and
> would be eager to spend it learning the codebase this summer.
>
> Do you think contributing to SciPy would be doable/worthwhile for me, or
> would you recommend looking for other projects and returning to SciPy later
> on? Are there any specific SciPy modules that would be more accessable than
> others? Any advice is appreciated!
>
> Thanks for your time,
> Jonathan Conroy
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>


-- 
Matt Haberland
Assistant Adjunct Professor in the Program in Computing
Department of Mathematics
6617A Math Sciences Building, UCLA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190514/458dd61f/attachment.html>

From ralf.gommers at gmail.com  Tue May 14 17:19:56 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Tue, 14 May 2019 23:19:56 +0200
Subject: [SciPy-Dev] Prerequisites for contributing?
In-Reply-To: <CADuxUiwbXgeoDF2GUMnWQAJAMsLJb7qLoaQF28yjbRgQ5rzckw@mail.gmail.com>
References: <38862AD5-A2AA-4225-B758-AD9DD9B90349@gmail.com>
 <CADuxUiwbXgeoDF2GUMnWQAJAMsLJb7qLoaQF28yjbRgQ5rzckw@mail.gmail.com>
Message-ID: <CABL7CQiVoOWJSmbHu=__UPxV3T6hPrOs1CoGUJiz3QxxF9pAeQ@mail.gmail.com>

On Tue, May 14, 2019 at 6:50 PM Matt Haberland <haberland at ucla.edu> wrote:

> Hi Jonathan,
>
> There's plenty of relatively low-hanging fruit for you to get started
> with. Take a look at the list of issues marked "good first issue" for
> something you'd like to try.
> https://github.com/scipy/scipy/labels/good%20first%20issue
>
> This document <http://scipy.github.io/devdocs/hacking.html> has been the
> traditional starting point for new contributors, but you might take a look
> at this recently drafted table of contents
> <https://github.com/scipy/scipy/wiki/SciPy-Development-Table-of-Contents>,
> too. If you go through it, please let me know how it can be improved.
>
> Matt Haberland
>
> On Mon, May 13, 2019 at 4:15 PM Jonathan Conroy <
> jonathanconroy14 at gmail.com> wrote:
>
>> Hi all,
>>
>> I'm Jonathan, a rising sophomore studying math and computer science. I'm
>> hoping to start contributing to open source software over the summer and
>> SciPy seems like a really interesting library, but I'm worried I don't have
>> the experience to make meaningful contributions. I'm looking for advice on
>> whether or not I have the background to contribute.
>>
>
Hi Jonathan, welcome! In addition to Matt's practical pointers, I just want
to encourage you - I'm sure there are meaningful contributions you can make.


>> In terms of coursework, I've taken Data Structures & Algorithms and
>> Machine Architecture, and I've had calculus, linear algebra, and a bit of
>> real analysis. I'll be taking a few machine learning courses next year (and
>> will be using SciPy in them), but as of right now I haven't used SciPy in
>> any large projects. That being said, I have a bunch of time on my hands and
>> would be eager to spend it learning the codebase this summer.
>>
>> Do you think contributing to SciPy would be doable/worthwhile for me, or
>> would you recommend looking for other projects and returning to SciPy later
>> on? Are there any specific SciPy modules that would be more accessable than
>> others? Any advice is appreciated!
>>
>
There's differences between modules. I would suggest to pick one that
interests you, and that has a good amount of activity (so you get feedback
quickly on PRs and questions). Stats, optimize, interpolate, linalg, are
some good ones for example.

Maybe as a way to get started, https://github.com/scipy/scipy/issues/7168
(adding examples) is a nice one.

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

From jonathanconroy14 at gmail.com  Wed May 15 14:32:06 2019
From: jonathanconroy14 at gmail.com (Jonathan Conroy)
Date: Wed, 15 May 2019 14:32:06 -0400
Subject: [SciPy-Dev] Prerequisites for contributing?
In-Reply-To: <CABL7CQiVoOWJSmbHu=__UPxV3T6hPrOs1CoGUJiz3QxxF9pAeQ@mail.gmail.com>
References: <38862AD5-A2AA-4225-B758-AD9DD9B90349@gmail.com>
 <CADuxUiwbXgeoDF2GUMnWQAJAMsLJb7qLoaQF28yjbRgQ5rzckw@mail.gmail.com>
 <CABL7CQiVoOWJSmbHu=__UPxV3T6hPrOs1CoGUJiz3QxxF9pAeQ@mail.gmail.com>
Message-ID: <BBB61263-8115-4E19-B7D4-7A90B2E499E4@gmail.com>

Thank you both for your help!

> On May 14, 2019, at 5:19 PM, Ralf Gommers <ralf.gommers at gmail.com> wrote:
> 
> On Tue, May 14, 2019 at 6:50 PM Matt Haberland <haberland at ucla.edu <mailto:haberland at ucla.edu>> wrote:
> Hi Jonathan,
> 
> There's plenty of relatively low-hanging fruit for you to get started with. Take a look at the list of issues marked "good first issue" for something you'd like to try.
> https://github.com/scipy/scipy/labels/good%20first%20issue <https://github.com/scipy/scipy/labels/good%20first%20issue> 
> 
> This document <http://scipy.github.io/devdocs/hacking.html> has been the traditional starting point for new contributors, but you might take a look at this recently drafted table of conteThnts <https://github.com/scipy/scipy/wiki/SciPy-Development-Table-of-Contents>, too. If you go through it, please let me know how it can be improved.
> 
> Matt Haberland 
> 

The table of contents is very helpful - I was getting a bit lost among all the different information pages before. Its great to know which ones to prioritize.

> On Mon, May 13, 2019 at 4:15 PM Jonathan Conroy <jonathanconroy14 at gmail.com <mailto:jonathanconroy14 at gmail.com>> wrote:
> Hi all,
> 
> I'm Jonathan, a rising sophomore studying math and computer science. I'm hoping to start contributing to open source software over the summer and SciPy seems like a really interesting library, but I'm worried I don't have the experience to make meaningful contributions. I'm looking for advice on whether or not I have the background to contribute.
> 
> Hi Jonathan, welcome! In addition to Matt's practical pointers, I just want to encourage you - I'm sure there are meaningful contributions you can make.
> 
> 
> In terms of coursework, I've taken Data Structures & Algorithms and Machine Architecture, and I've had calculus, linear algebra, and a bit of real analysis. I'll be taking a few machine learning courses next year (and will be using SciPy in them), but as of right now I haven't used SciPy in any large projects. That being said, I have a bunch of time on my hands and would be eager to spend it learning the codebase this summer.
> 
> Do you think contributing to SciPy would be doable/worthwhile for me, or would you recommend looking for other projects and returning to SciPy later on? Are there any specific SciPy modules that would be more accessable than others? Any advice is appreciated!
> 
> There's differences between modules. I would suggest to pick one that interests you, and that has a good amount of activity (so you get feedback quickly on PRs and questions). Stats, optimize, interpolate, linalg, are some good ones for example. 
> 
> Maybe as a way to get started, https://github.com/scipy/scipy/issues/7168 <https://github.com/scipy/scipy/issues/7168> (adding examples) is a nice one.
> 
> Cheers,
> Ralf
> 
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org <mailto:SciPy-Dev at python.org>
> https://mail.python.org/mailman/listinfo/scipy-dev <https://mail.python.org/mailman/listinfo/scipy-dev>

Thanks for the encouragement! I?ll look into adding examples over the next week.

Best,
Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190515/3bdb2be8/attachment.html>

From mikofski at berkeley.edu  Fri May 17 02:55:39 2019
From: mikofski at berkeley.edu (Mark Mikofski)
Date: Thu, 16 May 2019 23:55:39 -0700
Subject: [SciPy-Dev] Schumaker quadratic spline
In-Reply-To: <CAMRo0ivbGJBfXF=WJaY_ZxkiymA9DPDWVFjEuN3y5pU5ZgbU0g@mail.gmail.com>
References: <CAEqRcW3d97DBXqdO5hSQ9aGr740Hi01FC8Ss5EavzT2-7Bf-CA@mail.gmail.com>
 <CAMRo0ivbGJBfXF=WJaY_ZxkiymA9DPDWVFjEuN3y5pU5ZgbU0g@mail.gmail.com>
Message-ID: <CAEqRcW1obxRcxq6F2eY5Afg8U_77nOu7au4BWbEO6xNyfgUTAg@mail.gmail.com>

Hi Evgeni,

Thank you for your response! Sorry to bother you again, but do you know if
the BSpline can constrain the spline to be convex down, using a negative
quadratic coefficient? (see:
https://github.com/pvlib/pvlib-python/pull/708#issuecomment-491312490)

Regarding contributing, when you say "based on ppoly or bspline" do you
mean that the Schumaker could be created using BSpline, as a specific
instance? Is there a way to enforce the Bspline to be convex down?

Sorry for all the questions. I will try to do some research on this topic
separately. If you have good references for beginners, I would greatly
appreciate it.

Best Regards,
Mark


On Fri, May 10, 2019 at 12:27 AM Evgeni Burovski <evgeny.burovskiy at gmail.com>
wrote:

> Hi Mark,
>
> The docs you linked reference https://epubs.siam.org/doi/10.1137/0720057
> which is gated, so only an impression: this seems to construct a
> shape-preserving piecewise quadratic interpolant. We have two
> shape-preserving cubic interpolants, PCHIP and Akima. Do you have an
> overview of how this one compares to them?
>
> Off the cuff, I guess we can add a shape-preserving quadratic, too. This
> should be based on either BSpline or PPoly, depending on the basis the
> construction is in.
> (My impression is that it's the latter in the R package).
> The API should mirror that of Akima1DInterpolator.
>
>
>
>
> ??, 10 ??? 2019 ?., 9:45 Mark Mikofski <mikofski at berkeley.edu>:
>
>> Hi All,
>>
>> Sorry for this unresearched and inexperienced question.
>>
>> Does anyone have any experience with the "Schumaker quadratic spline" for
>> 1-D interpolation? Is it similar enough to the BSpline already in SciPy?
>>
>> I have some source code that I can contribute if there's interest.
>>
>> As far as references, a google search turned up an R function:
>> *
>> https://cran.r-project.org/web/packages/schumaker/vignettes/schumaker.html
>>
>>
>> --
>> Mark Mikofski, PhD (2005)
>> *Fiat Lux*
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>


-- 
Mark Mikofski, PhD (2005)
*Fiat Lux*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190516/f2b8c0c0/attachment.html>

From ralf.gommers at gmail.com  Fri May 17 03:09:45 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Fri, 17 May 2019 09:09:45 +0200
Subject: [SciPy-Dev] Backend support for fftpack - GSoC 2019
In-Reply-To: <DB6PR04MB32067A2161BCDE87FA64EECE8E330@DB6PR04MB3206.eurprd04.prod.outlook.com>
References: <DB6PR04MB320650B383909FE340B38EEF8E320@DB6PR04MB3206.eurprd04.prod.outlook.com>
 <CABL7CQhuH_N=fJBG8mUVfjTELZfup=xunNGrjuNWohjkfBoPOg@mail.gmail.com>
 <DB6PR04MB32067A2161BCDE87FA64EECE8E330@DB6PR04MB3206.eurprd04.prod.outlook.com>
Message-ID: <CABL7CQg7n0wFtJqD_yuV3JiA-bvY=FD5t814x8s3R35HsHS2qQ@mail.gmail.com>

On Thu, May 9, 2019 at 2:25 PM Peter Bell <PeterBell10 at live.co.uk> wrote:

> >> Should backends be allowed to add functionality or should they be
> completely
>
> >> interchangeable. E.g. unlike fftpack, FFTW has support for long doubles;
>
> >> should this be exposed to SciPy users?
>
> >
>
> > If a user writes backend-specific code, then they may just as well
> bypass the
>
> > backend right, and call the other library directly?
>

After some thought/discussion I'm going to disagree with myself here.


>
> I agree, in fact I quote you in the proposal saying something similar.
>
>
>
> > Although for long double things will work out of the box perhaps,
> because the
>
> > dtype of an input array doesn't come back in the API. So the array can be
>
> > passed straight to the backend.
>
>
>
> This was why I picked it as an example. It doesn't add any new parameters
> or
>
> change the function signature at all, but it does change the result of a
>
> particular call to the API. So it's a very minimal change yet it still
> breaks
>
> the interchangeability of backends.
>

Peter and I had a very interesting discussion in comments on his Google
doc. It relates to the design question about what a backend is allowed to
do (and even higher level, what is a backend for). I'm now relatively sure
I can summarize it well, so I'll give it a try.

"completely interchangeable", as Peter uses above, implies that both API
and semantics of the backend are matching 100% with what SciPy does.
Peter's example from the doc (where _dct_func is the backend-provided
function) may help to illustrate that:

   def dct(x, type=2, n=None, axis=-1, norm=None, overwrite_x=False):

       # From current implementation, also converts float16 to float32

       x = _asfarray(x)
       if x.dtype not in (np.float32, np.float64,

                          np.complex64, np.complex128):
           raise ValueError("type {} is not supported".format(x.dtype))
        return _dct_func(x, type, n, axis, norm, overwrite_x)

So that will do for example array coercion and upcasting the same way as
the SciPy implementation. As a consequence, what a backend offers will then
be different performance - speed and/or accuracy. Let's call this *model 1*.

What my mental model was when I started commenting on the above example is:
a backend has to have a compatible API, but replaces the implementation of
a function completely. Hence can offer different behavior. The downside is
that a user can't blindly switch backends, reading the docs may be
required. The upside is that it allows for more use cases, like:
1. Simple differences, like providing a longdouble implementation
2. Another input type, e.g. cupy arrays that live on a GPU and executing
the fft on the GPU. With the "completely interchangeable model" this may
still work,  but there will be a conversion to-from ndarray on every
function call.
3. Another example of another input type that otherwise won't work at all:
using things that don't fit in memory, like a large Dask array.
Let's call this *model 2*.

I would either way not require _completely_ identical behavior, even if
we'd go with model 1. For example the overwrite_x keyword is an
implementation detail, I think it's fine for any backend to raise an error
if that's True.

Model 2, which I have a preference for, is very similar to the numpy
__array_function__ and __array_ufunc__ protocols (in spirit, not
implementation). I've tried to illustrate that in slides 10-11 of [1].

Both models 1 and 2 allow faster implementations, like mkl-fft and pyfftw,
to cleanly integrate with SciPy (instead of monkeypatching like pyfftw does
now). Model 2 in addition allows writing code that is generic for (for
example) GPU and distributed implementations, at the cost of a little less
uniformity in behavior.

I hope this made sense. Are there other models of a backend than the above
two? Thoughts on what to prefer?

Cheers,
Ralf

[1]
https://www.slideshare.net/RalfGommers/the-evolution-of-array-computing-in-python
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190517/17661679/attachment-0001.html>

From evgeny.burovskiy at gmail.com  Fri May 17 03:33:00 2019
From: evgeny.burovskiy at gmail.com (Evgeni Burovski)
Date: Fri, 17 May 2019 10:33:00 +0300
Subject: [SciPy-Dev] Backend support for fftpack - GSoC 2019
In-Reply-To: <CABL7CQg7n0wFtJqD_yuV3JiA-bvY=FD5t814x8s3R35HsHS2qQ@mail.gmail.com>
References: <DB6PR04MB320650B383909FE340B38EEF8E320@DB6PR04MB3206.eurprd04.prod.outlook.com>
 <CABL7CQhuH_N=fJBG8mUVfjTELZfup=xunNGrjuNWohjkfBoPOg@mail.gmail.com>
 <DB6PR04MB32067A2161BCDE87FA64EECE8E330@DB6PR04MB3206.eurprd04.prod.outlook.com>
 <CABL7CQg7n0wFtJqD_yuV3JiA-bvY=FD5t814x8s3R35HsHS2qQ@mail.gmail.com>
Message-ID: <CAMRo0itBh51yg4yPfuGBhaL5m8UjKYtvvWO5Wq7tTUbZ+44OOA@mail.gmail.com>

>From 10000 feet your model 2 sounds preferable. "Completely
interchangeable" feels
- not very realistic,
- a lot of work for ensuring identical behavior, and
- potentially limiting advanced users.

Overall, the contract along the lines of " backends have a mostly identical
core functionality, but may offer additional backend-specific features,
and/or have small differences in behavior. Read the docs and do some
verification when switching backends" sounds reasonable.

??, 17 ??? 2019 ?., 10:10 Ralf Gommers <ralf.gommers at gmail.com>:

>
>
> On Thu, May 9, 2019 at 2:25 PM Peter Bell <PeterBell10 at live.co.uk> wrote:
>
>> >> Should backends be allowed to add functionality or should they be
>> completely
>>
>> >> interchangeable. E.g. unlike fftpack, FFTW has support for long
>> doubles;
>>
>> >> should this be exposed to SciPy users?
>>
>> >
>>
>> > If a user writes backend-specific code, then they may just as well
>> bypass the
>>
>> > backend right, and call the other library directly?
>>
>
> After some thought/discussion I'm going to disagree with myself here.
>
>
>>
>> I agree, in fact I quote you in the proposal saying something similar.
>>
>>
>>
>> > Although for long double things will work out of the box perhaps,
>> because the
>>
>> > dtype of an input array doesn't come back in the API. So the array can
>> be
>>
>> > passed straight to the backend.
>>
>>
>>
>> This was why I picked it as an example. It doesn't add any new parameters
>> or
>>
>> change the function signature at all, but it does change the result of a
>>
>> particular call to the API. So it's a very minimal change yet it still
>> breaks
>>
>> the interchangeability of backends.
>>
>
> Peter and I had a very interesting discussion in comments on his Google
> doc. It relates to the design question about what a backend is allowed to
> do (and even higher level, what is a backend for). I'm now relatively sure
> I can summarize it well, so I'll give it a try.
>
> "completely interchangeable", as Peter uses above, implies that both API
> and semantics of the backend are matching 100% with what SciPy does.
> Peter's example from the doc (where _dct_func is the backend-provided
> function) may help to illustrate that:
>
>    def dct(x, type=2, n=None, axis=-1, norm=None, overwrite_x=False):
>
>        # From current implementation, also converts float16 to float32
>
>        x = _asfarray(x)
>        if x.dtype not in (np.float32, np.float64,
>
>                           np.complex64, np.complex128):
>            raise ValueError("type {} is not supported".format(x.dtype))
>         return _dct_func(x, type, n, axis, norm, overwrite_x)
>
> So that will do for example array coercion and upcasting the same way as
> the SciPy implementation. As a consequence, what a backend offers will then
> be different performance - speed and/or accuracy. Let's call this *model 1*.
>
> What my mental model was when I started commenting on the above example
> is: a backend has to have a compatible API, but replaces the implementation
> of a function completely. Hence can offer different behavior. The downside
> is that a user can't blindly switch backends, reading the docs may be
> required. The upside is that it allows for more use cases, like:
> 1. Simple differences, like providing a longdouble implementation
> 2. Another input type, e.g. cupy arrays that live on a GPU and executing
> the fft on the GPU. With the "completely interchangeable model" this may
> still work,  but there will be a conversion to-from ndarray on every
> function call.
> 3. Another example of another input type that otherwise won't work at all:
> using things that don't fit in memory, like a large Dask array.
> Let's call this *model 2*.
>
> I would either way not require _completely_ identical behavior, even if
> we'd go with model 1. For example the overwrite_x keyword is an
> implementation detail, I think it's fine for any backend to raise an error
> if that's True.
>
> Model 2, which I have a preference for, is very similar to the numpy
> __array_function__ and __array_ufunc__ protocols (in spirit, not
> implementation). I've tried to illustrate that in slides 10-11 of [1].
>
> Both models 1 and 2 allow faster implementations, like mkl-fft and pyfftw,
> to cleanly integrate with SciPy (instead of monkeypatching like pyfftw does
> now). Model 2 in addition allows writing code that is generic for (for
> example) GPU and distributed implementations, at the cost of a little less
> uniformity in behavior.
>
> I hope this made sense. Are there other models of a backend than the above
> two? Thoughts on what to prefer?
>
> Cheers,
> Ralf
>
> [1]
> https://www.slideshare.net/RalfGommers/the-evolution-of-array-computing-in-python
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190517/a23c7448/attachment.html>

From evgeny.burovskiy at gmail.com  Fri May 17 03:53:04 2019
From: evgeny.burovskiy at gmail.com (Evgeni Burovski)
Date: Fri, 17 May 2019 10:53:04 +0300
Subject: [SciPy-Dev] Schumaker quadratic spline
In-Reply-To: <CAEqRcW1obxRcxq6F2eY5Afg8U_77nOu7au4BWbEO6xNyfgUTAg@mail.gmail.com>
References: <CAEqRcW3d97DBXqdO5hSQ9aGr740Hi01FC8Ss5EavzT2-7Bf-CA@mail.gmail.com>
 <CAMRo0ivbGJBfXF=WJaY_ZxkiymA9DPDWVFjEuN3y5pU5ZgbU0g@mail.gmail.com>
 <CAEqRcW1obxRcxq6F2eY5Afg8U_77nOu7au4BWbEO6xNyfgUTAg@mail.gmail.com>
Message-ID: <CAMRo0itjmOqwkWQZM0Jeo=gLx1r4=hyUqCf+fwox-8_-D-Uycw@mail.gmail.com>

Hi Mark,

A BSpline object is simply a linear combination of certain basis functions,
much like a usual polynomial is a linear combination of 1, x, x^2, x^3, ....

You can certainly construct a convex piecewise quadratic function, as
either  a BSpline or PPoly instance, whichever is more convenient.

Re references, I liked Lyche/Morken lecture notes (referenced in the
BSpline docstring). Was suggested to me by Pauli IIRC.


??, 17 ??? 2019 ?., 9:56 Mark Mikofski <mikofski at berkeley.edu>:

> Hi Evgeni,
>
> Thank you for your response! Sorry to bother you again, but do you know if
> the BSpline can constrain the spline to be convex down, using a negative
> quadratic coefficient? (see:
> https://github.com/pvlib/pvlib-python/pull/708#issuecomment-491312490)
>
> Regarding contributing, when you say "based on ppoly or bspline" do you
> mean that the Schumaker could be created using BSpline, as a specific
> instance? Is there a way to enforce the Bspline to be convex down?
>
> Sorry for all the questions. I will try to do some research on this topic
> separately. If you have good references for beginners, I would greatly
> appreciate it.
>
> Best Regards,
> Mark
>
>
> On Fri, May 10, 2019 at 12:27 AM Evgeni Burovski <
> evgeny.burovskiy at gmail.com> wrote:
>
>> Hi Mark,
>>
>> The docs you linked reference https://epubs.siam.org/doi/10.1137/0720057
>> which is gated, so only an impression: this seems to construct a
>> shape-preserving piecewise quadratic interpolant. We have two
>> shape-preserving cubic interpolants, PCHIP and Akima. Do you have an
>> overview of how this one compares to them?
>>
>> Off the cuff, I guess we can add a shape-preserving quadratic, too. This
>> should be based on either BSpline or PPoly, depending on the basis the
>> construction is in.
>> (My impression is that it's the latter in the R package).
>> The API should mirror that of Akima1DInterpolator.
>>
>>
>>
>>
>> ??, 10 ??? 2019 ?., 9:45 Mark Mikofski <mikofski at berkeley.edu>:
>>
>>> Hi All,
>>>
>>> Sorry for this unresearched and inexperienced question.
>>>
>>> Does anyone have any experience with the "Schumaker quadratic spline"
>>> for 1-D interpolation? Is it similar enough to the BSpline already in SciPy?
>>>
>>> I have some source code that I can contribute if there's interest.
>>>
>>> As far as references, a google search turned up an R function:
>>> *
>>> https://cran.r-project.org/web/packages/schumaker/vignettes/schumaker.html
>>>
>>>
>>> --
>>> Mark Mikofski, PhD (2005)
>>> *Fiat Lux*
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
>
>
> --
> Mark Mikofski, PhD (2005)
> *Fiat Lux*
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190517/70df9490/attachment-0001.html>

From tyler.je.reddy at gmail.com  Fri May 17 18:36:14 2019
From: tyler.je.reddy at gmail.com (Tyler Reddy)
Date: Fri, 17 May 2019 15:36:14 -0700
Subject: [SciPy-Dev] ANN: SciPy 1.3.0
Message-ID: <CAHPuU_YDgsq_Pt8iAsWL-6qhRyFdAd=BU0SLaHU3U0n-ypvG8g@mail.gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi all,

On behalf of the SciPy development team I'm pleased to announce
the release of SciPy 1.3.0.

Sources and binary wheels can be found at:
https://pypi.org/project/scipy/
and at:
https://github.com/scipy/scipy/releases/tag/v1.3.0

One of a few ways to install this release with pip:

pip install scipy==1.3.0

==========================
SciPy 1.3.0 Release Notes
==========================

SciPy 1.3.0 is the culmination of 5 months of hard work. It contains
many new features, numerous bug-fixes, improved test coverage and better
documentation. There have been some API changes
in this release, which are documented below. All users are encouraged to
upgrade to this release, as there are a large number of bug-fixes and
optimizations. Before upgrading, we recommend that users check that
their own code does not use deprecated SciPy functionality (to do so,
run your code with ``python -Wd`` and check for ``DeprecationWarning`` s).
Our development attention will now shift to bug-fix releases on the
1.3.x branch, and on adding new features on the master branch.

This release requires Python 3.5+ and NumPy 1.13.3 or greater.

For running on PyPy, PyPy3 6.0+ and NumPy 1.15.0 are required.

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

- - Three new ``stats`` functions, a rewrite of ``pearsonr``, and an exact
  computation of the Kolmogorov-Smirnov two-sample test
- - A new Cython API for bounded scalar-function root-finders in
`scipy.optimize`
- - Substantial ``CSR`` and ``CSC`` sparse matrix indexing performance
  improvements
- - Added support for interpolation of rotations with continuous angular
  rate and acceleration in ``RotationSpline``


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

`scipy.interpolate` improvements
-------------------------------------------

A new class ``CubicHermiteSpline`` is introduced. It is a piecewise-cubic
interpolator which matches observed values and first derivatives. Existing
cubic interpolators ``CubicSpline``, ``PchipInterpolator`` and
``Akima1DInterpolator`` were made subclasses of ``CubicHermiteSpline``.

`scipy.io` improvements
--------------------------------

For the Attribute-Relation File Format (ARFF) `scipy.io.arff.loadarff`
now supports relational attributes.

`scipy.io.mmread` can now parse Matrix Market format files with empty lines.

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

Added wrappers for ``?syconv`` routines, which convert a symmetric matrix
given by a triangular matrix factorization into two matrices and vice versa.

`scipy.linalg.clarkson_woodruff_transform` now uses an algorithm that
leverages
sparsity. This may provide a 60-90 percent speedup for dense input matrices.
Truly sparse input matrices should also benefit from the improved sketch
algorithm, which now correctly runs in ``O(nnz(A))`` time.

Added new functions to calculate symmetric Fiedler matrices and
Fiedler companion matrices, named `scipy.linalg.fiedler` and
`scipy.linalg.fiedler_companion`, respectively. These may be used
for root finding.

`scipy.ndimage` improvements
----------------------------------------

Gaussian filter performances may improve by an order of magnitude in
some cases, thanks to removal of a dependence on ``np.polynomial``. This
may impact `scipy.ndimage.gaussian_filter` for example.

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

The `scipy.optimize.brute` minimizer obtained a new keyword ``workers``,
which
can be used to parallelize computation.

A Cython API for bounded scalar-function root-finders in `scipy.optimize`
is available in a new module `scipy.optimize.cython_optimize` via
``cimport``.
This API may be used with ``nogil`` and ``prange`` to loop
over an array of function arguments to solve for an array of roots more
quickly than with pure Python.

``'interior-point'`` is now the default method for ``linprog``, and
``'interior-point'`` now uses SuiteSparse for sparse problems when the
required scikits  (scikit-umfpack and scikit-sparse) are available.
On benchmark problems (gh-10026), execution time reductions by factors of
2-3
were typical. Also, a new ``method='revised simplex'`` has been added.
It is not as fast or robust as ``method='interior-point'``, but it is a
faster,
more robust, and equally accurate substitute for the legacy
``method='simplex'``.

``differential_evolution`` can now use a ``Bounds`` class to specify the
bounds for the optimizing argument of a function.

`scipy.optimize.dual_annealing` performance improvements related to
vectorisation of some internal code.

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

Two additional methods of discretization are now supported by
`scipy.signal.cont2discrete`: ``impulse`` and ``foh``.

`scipy.signal.firls` now uses faster solvers

`scipy.signal.detrend` now has a lower physical memory footprint in some
cases, which may be leveraged using the new ``overwrite_data`` keyword
argument

`scipy.signal.firwin` ``pass_zero`` argument now accepts new string
arguments
that allow specification of the desired filter type: ``'bandpass'``,
``'lowpass'``, ``'highpass'``, and ``'bandstop'``

`scipy.signal.sosfilt` may have improved performance due to lower retention
of the global interpreter lock (GIL) in algorithm

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

A new keyword was added to ``csgraph.dijsktra`` that
allows users to query the shortest path to ANY of the passed in indices,
as opposed to the shortest path to EVERY passed index.

`scipy.sparse.linalg.lsmr` performance has been improved by roughly 10
percent
on large problems

Improved performance and reduced physical memory footprint of the algorithm
used by `scipy.sparse.linalg.lobpcg`

``CSR`` and ``CSC`` sparse matrix fancy indexing performance has been
improved substantially

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

`scipy.spatial.ConvexHull` now has a ``good`` attribute that can be used
alongsize the ``QGn`` Qhull options to determine which external facets of a
convex hull are visible from an external query point.

`scipy.spatial.cKDTree.query_ball_point` has been modernized to use some
newer
Cython features, including GIL handling and exception translation. An issue
with ``return_sorted=True`` and scalar queries was fixed, and a new mode
named
``return_length`` was added. ``return_length`` only computes the length of
the
returned indices list instead of allocating the array every time.

`scipy.spatial.transform.RotationSpline` has been added to enable
interpolation
of rotations with continuous angular rates and acceleration

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

Added a new function to compute the Epps-Singleton test statistic,
`scipy.stats.epps_singleton_2samp`, which can be applied to continuous and
discrete distributions.

New functions `scipy.stats.median_absolute_deviation` and `scipy.stats.gstd`
(geometric standard deviation) were added. The
`scipy.stats.combine_pvalues`
method now supports ``pearson``,  ``tippett`` and ``mudholkar_george``
pvalue
combination methods.

The `scipy.stats.ortho_group` and `scipy.stats.special_ortho_group`
``rvs(dim)`` functions' algorithms were updated from a ``O(dim^4)``
implementation to a ``O(dim^3)`` which gives large speed improvements
for ``dim>100``.

A rewrite of `scipy.stats.pearsonr` to use a more robust algorithm,
provide meaningful exceptions and warnings on potentially pathological
input,
and fix at least five separate reported issues in the original
implementation.

Improved the precision of ``hypergeom.logcdf`` and ``hypergeom.logsf``.

Added exact computation for Kolmogorov-Smirnov (KS) two-sample test,
replacing
the previously approximate computation for the two-sided test
`stats.ks_2samp`.
Also added a one-sided, two-sample KS test, and a keyword ``alternative``
to
`stats.ks_2samp`.

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

`scipy.interpolate` changes
------------------------------------

Functions from ``scipy.interpolate`` (``spleval``, ``spline``, ``splmake``,
and ``spltopp``) and functions from ``scipy.misc`` (``bytescale``,
``fromimage``, ``imfilter``, ``imread``, ``imresize``, ``imrotate``,
``imsave``, ``imshow``, ``toimage``) have been removed. The former set has
been deprecated since v0.19.0 and the latter has been deprecated since
v1.0.0.
Similarly, aliases from ``scipy.misc`` (``comb``, ``factorial``,
``factorial2``, ``factorialk``, ``logsumexp``, ``pade``, ``info``,
``source``,
``who``) which have been deprecated since v1.0.0 are removed.
`SciPy documentation for
v1.1.0 <https://docs.scipy.org/doc/scipy-1.1.0/reference/misc.html>`__
can be used to track the new import locations for the relocated functions.

`scipy.linalg` changes
-----------------------------

For ``pinv``, ``pinv2``, and ``pinvh``, the default cutoff values are
changed
for consistency (see the docs for the actual values).

`scipy.optimize` changes
---------------------------------

The default method for ``linprog`` is now ``'interior-point'``. The method's
robustness and speed come at a cost: solutions may not be accurate to
machine precision or correspond with a vertex of the polytope defined
by the constraints. To revert to the original simplex method,
include the argument ``method='simplex'``.

`scipy.stats` changes
----------------------------

Previously, ``ks_2samp(data1, data2)`` would run a two-sided test and
return
the approximated p-value. The new signature, ``ks_2samp(data1, data2,
alternative="two-sided", method="auto")``, still runs the two-sided test by
default but returns the exact p-value for small samples and the approximated
value for large samples. ``method="asymp"`` would be equivalent to the
old version but ``auto`` is the better choice.

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

Our tutorial has been expanded with a new section on global optimizers

There has been a rework of the ``stats.distributions`` tutorials.

`scipy.optimize` now correctly sets the convergence flag of the result to
``CONVERR``, a convergence error, for bounded scalar-function root-finders
if the maximum iterations has been exceeded, ``disp`` is false, and
``full_output`` is true.

`scipy.optimize.curve_fit` no longer fails if ``xdata`` and ``ydata``
dtypes
differ; they are both now automatically cast to ``float64``.

`scipy.ndimage` functions including ``binary_erosion``, ``binary_closing``,
and
``binary_dilation`` now require an integer value for the number of
iterations,
which alleviates a number of reported issues.

Fixed normal approximation in case ``zero_method == "pratt"`` in
`scipy.stats.wilcoxon`.

Fixes for incorrect probabilities, broadcasting issues and thread-safety
related to stats distributions setting member variables inside
``_argcheck()``.

`scipy.optimize.newton` now correctly raises a ``RuntimeError``, when
default
arguments are used, in the case that a derivative of value zero is obtained,
which is a special case of failing to converge.

A draft toolchain roadmap is now available, laying out a compatibility plan
including Python versions, C standards, and NumPy versions.


Authors
=======

* ananyashreyjain +
* ApamNapat +
* Scott Calabrese Barton +
* Christoph Baumgarten
* Peter Bell +
* Jacob Blomgren +
* Doctor Bob +
* Mana Borwornpadungkitti +
* Matthew Brett
* Evgeni Burovski
* CJ Carey
* Vega Theil Carstensen +
* Robert Cimrman
* Forrest Collman +
* Pietro Cottone +
* David +
* Idan David +
* Christoph Deil
* Dieter Werthm?ller
* Conner DiPaolo +
* Dowon
* Michael Dunphy +
* Peter Andreas Entschev +
* G?k?en Eraslan +
* Johann Faouzi +
* Yu Feng
* Piotr Figiel +
* Matthew H Flamm
* Franz Forstmayr +
* Christoph Gohlke
* Richard Janis Goldschmidt +
* Ralf Gommers
* Lars Grueter
* Sylvain Gubian
* Matt Haberland
* Yaroslav Halchenko
* Charles Harris
* Lindsey Hiltner
* JakobStruye +
* He Jia +
* Jwink3101 +
* Greg Kiar +
* Julius Bier Kirkegaard
* John Kirkham +
* Thomas Kluyver
* Vladimir Korolev +
* Joseph Kuo +
* Michael Lamparski +
* Eric Larson
* Denis Laxalde
* Katrin Leinweber
* Jesse Livezey
* ludcila +
* Dhruv Madeka +
* Magnus +
* Nikolay Mayorov
* Mark Mikofski
* Jarrod Millman
* Markus Mohrhard +
* Eric Moore
* Andrew Nelson
* Aki Nishimura +
* OGordon100 +
* Petar Mlinari? +
* Stefan Peterson
* Matti Picus +
* Ilhan Polat
* Aaron Pries +
* Matteo Ravasi +
* Tyler Reddy
* Ashton Reimer +
* Joscha Reimer
* rfezzani +
* Riadh +
* Lucas Roberts
* Heshy Roskes +
* Mirko Scholz +
* Taylor D. Scott +
* Srikrishna Sekhar +
* Kevin Sheppard +
* Sourav Singh
* skjerns +
* Kai Striega
* SyedSaifAliAlvi +
* Gopi Manohar T +
* Albert Thomas +
* Timon +
* Paul van Mulbregt
* Jacob Vanderplas
* Daniel Vargas +
* Pauli Virtanen
* VNMabus +
* Stefan van der Walt
* Warren Weckesser
* Josh Wilson
* Nate Yoder +
* Roman Yurchak

A total of 97 people contributed to this release.
People with a "+" by their names contributed a patch for the first time.
This list of names is automatically generated, and may not be fully
complete.

Issues closed for 1.3.0
-------------------------------

* `#1320 <https://github.com/scipy/scipy/issues/1320>`__:
scipy.stats.distribution: problem with self.a, self.b if they...
* `#2002 <https://github.com/scipy/scipy/issues/2002>`__: members set in
scipy.stats.distributions.##._argcheck (Trac #1477)
* `#2823 <https://github.com/scipy/scipy/issues/2823>`__: distribution
methods add tmp
* `#3220 <https://github.com/scipy/scipy/issues/3220>`__:
Scipy.opimize.fmin_powell direc argument syntax unclear
* `#3728 <https://github.com/scipy/scipy/issues/3728>`__:
scipy.stats.pearsonr: possible bug with zero variance input
* `#6805 <https://github.com/scipy/scipy/issues/6805>`__:
error-in-scipy-wilcoxon-signed-rank-test-for-equal-series
* `#6873 <https://github.com/scipy/scipy/issues/6873>`__: 'stats.boxcox'
return all same values
* `#7117 <https://github.com/scipy/scipy/issues/7117>`__: Warn users when
using float32 input data to curve_fit and friends
* `#7632 <https://github.com/scipy/scipy/issues/7632>`__: it's not possible
to tell the \`optimize.least_squares\` solver...
* `#7730 <https://github.com/scipy/scipy/issues/7730>`__: stats.pearsonr:
Potential division by zero for dataset of length...
* `#7933 <https://github.com/scipy/scipy/issues/7933>`__: stats.truncnorm
fails when providing values outside truncation...
* `#8033 <https://github.com/scipy/scipy/issues/8033>`__: Add standard
filter types to firwin to set pass_zero intuitively...
* `#8600 <https://github.com/scipy/scipy/issues/8600>`__: lfilter.c.src
zfill has erroneous header
* `#8692 <https://github.com/scipy/scipy/issues/8692>`__: Non-negative
values of \`stats.hypergeom.logcdf\`
* `#8734 <https://github.com/scipy/scipy/issues/8734>`__: Enable pip build
isolation
* `#8861 <https://github.com/scipy/scipy/issues/8861>`__: scipy.linalg.pinv
gives wrong result while scipy.linalg.pinv2...
* `#8915 <https://github.com/scipy/scipy/issues/8915>`__: need to fix macOS
build against older numpy versions
* `#8980 <https://github.com/scipy/scipy/issues/8980>`__:
scipy.stats.pearsonr overflows with high values of x and y
* `#9226 <https://github.com/scipy/scipy/issues/9226>`__: BUG: signal:
SystemError: <built-in function _linear_filter>...
* `#9254 <https://github.com/scipy/scipy/issues/9254>`__: BUG: root finders
brentq, etc, flag says "converged" even if...
* `#9308 <https://github.com/scipy/scipy/issues/9308>`__: Test failure -
test_initial_constraints_as_canonical
* `#9353 <https://github.com/scipy/scipy/issues/9353>`__:
scipy.stats.pearsonr returns r=1 if r_num/r_den = inf
* `#9359 <https://github.com/scipy/scipy/issues/9359>`__: Planck
distribution is a geometric distribution
* `#9381 <https://github.com/scipy/scipy/issues/9381>`__: linregress should
warn user in 2x2 array case
* `#9406 <https://github.com/scipy/scipy/issues/9406>`__: BUG: stats: In
pearsonr, when r is nan, the p-value must also...
* `#9437 <https://github.com/scipy/scipy/issues/9437>`__: Cannot create
sparse matrix from size_t indexes
* `#9518 <https://github.com/scipy/scipy/issues/9518>`__: Relational
attributes in loadarff
* `#9551 <https://github.com/scipy/scipy/issues/9551>`__: BUG:
scipy.optimize.newton says the root of x^2+1 is zero.
* `#9564 <https://github.com/scipy/scipy/issues/9564>`__: rv_sample accepts
invalid input in scipy.stats
* `#9565 <https://github.com/scipy/scipy/issues/9565>`__: improper handling
of multidimensional input in stats.rv_sample
* `#9581 <https://github.com/scipy/scipy/issues/9581>`__: Least-squares
minimization fails silently when x and y data are...
* `#9587 <https://github.com/scipy/scipy/issues/9587>`__: Outdated value
for scipy.constants.au
* `#9611 <https://github.com/scipy/scipy/issues/9611>`__: Overflow error
with new way of p-value calculation in kendall...
* `#9645 <https://github.com/scipy/scipy/issues/9645>`__:
\`scipy.stats.mode\` crashes with variable length arrays (\`dtype=object\`)
* `#9734 <https://github.com/scipy/scipy/issues/9734>`__:
PendingDeprecationWarning for np.matrix with pytest
* `#9786 <https://github.com/scipy/scipy/issues/9786>`__: stats.ks_2samp()
misleading for small data sets.
* `#9790 <https://github.com/scipy/scipy/issues/9790>`__: Excessive memory
usage on detrend
* `#9801 <https://github.com/scipy/scipy/issues/9801>`__: dual_annealing
does not set the success attribute in OptimizeResult
* `#9833 <https://github.com/scipy/scipy/issues/9833>`__:
IntegrationWarning from mielke.stats() during build of html doc.
* `#9835 <https://github.com/scipy/scipy/issues/9835>`__:
scipy.signal.firls seems to be inefficient versus MATLAB firls
* `#9864 <https://github.com/scipy/scipy/issues/9864>`__: Curve_fit does
not check for empty input data if called with...
* `#9869 <https://github.com/scipy/scipy/issues/9869>`__:
scipy.ndimage.label: Minor documentation issue
* `#9882 <https://github.com/scipy/scipy/issues/9882>`__: format at the
wrong paranthesis in scipy.spatial.transform
* `#9889 <https://github.com/scipy/scipy/issues/9889>`__:
scipy.signal.find_peaks minor documentation issue
* `#9890 <https://github.com/scipy/scipy/issues/9890>`__: Minkowski p-norm
Issues in cKDTree For Values Other Than 2 Or...
* `#9896 <https://github.com/scipy/scipy/issues/9896>`__:
scipy.stats._argcheck sets (not just checks) values
* `#9905 <https://github.com/scipy/scipy/issues/9905>`__: Memory error in
ndimage.binary_erosion
* `#9909 <https://github.com/scipy/scipy/issues/9909>`__:
binary_dilation/erosion/closing crashes when iterations is float
* `#9919 <https://github.com/scipy/scipy/issues/9919>`__: BUG:
\`coo_matrix\` does not validate the \`shape\` argument.
* `#9982 <https://github.com/scipy/scipy/issues/9982>`__: lsq_linear
hangs/infinite loop with 'trf' method
* `#10003 <https://github.com/scipy/scipy/issues/10003>`__: exponnorm.pdf
returns NAN for small K
* `#10011 <https://github.com/scipy/scipy/issues/10011>`__: Incorrect check
for invalid rotation plane in scipy.ndimage.rotate
* `#10024 <https://github.com/scipy/scipy/issues/10024>`__: Fails to build
from git
* `#10048 <https://github.com/scipy/scipy/issues/10048>`__: DOC:
scipy.optimize.root_scalar
* `#10068 <https://github.com/scipy/scipy/issues/10068>`__: DOC:
scipy.interpolate.splev
* `#10074 <https://github.com/scipy/scipy/issues/10074>`__: BUG: \`expm\`
calculates the wrong coefficients in the backward...


Pull requests for 1.3.0
------------------------------

* `#7827 <https://github.com/scipy/scipy/pull/7827>`__: ENH: sparse:
overhaul of sparse matrix indexing
* `#8431 <https://github.com/scipy/scipy/pull/8431>`__: ENH: Cython
optimize zeros api
* `#8743 <https://github.com/scipy/scipy/pull/8743>`__: DOC: Updated
linalg.pinv, .pinv2, .pinvh docstrings
* `#8744 <https://github.com/scipy/scipy/pull/8744>`__: DOC: added examples
to remez docstring
* `#9227 <https://github.com/scipy/scipy/pull/9227>`__: DOC: update
description of "direc" parameter of "fmin_powell"
* `#9263 <https://github.com/scipy/scipy/pull/9263>`__: ENH: optimize:
added "revised simplex" for scipy.optimize.linprog
* `#9325 <https://github.com/scipy/scipy/pull/9325>`__: DEP: Remove
deprecated functions for 1.3.0
* `#9330 <https://github.com/scipy/scipy/pull/9330>`__: Add note on push
and pull affine transformations
* `#9423 <https://github.com/scipy/scipy/pull/9423>`__: DOC: Clearly state
how 2x2 input arrays are handled in stats.linregress
* `#9428 <https://github.com/scipy/scipy/pull/9428>`__: ENH: parallelised
brute
* `#9438 <https://github.com/scipy/scipy/pull/9438>`__: BUG: Initialize coo
matrix with size_t indexes
* `#9455 <https://github.com/scipy/scipy/pull/9455>`__: MAINT: Speed up
get_(lapack,blas)_func
* `#9465 <https://github.com/scipy/scipy/pull/9465>`__: MAINT: Clean up
optimize.zeros C solvers interfaces/code.
* `#9477 <https://github.com/scipy/scipy/pull/9477>`__: DOC: linalg: fix
lstsq docstring on residues shape
* `#9478 <https://github.com/scipy/scipy/pull/9478>`__: DOC: Add docstring
examples for rosen functions
* `#9479 <https://github.com/scipy/scipy/pull/9479>`__: DOC: Add docstring
example for ai_zeros and bi_zeros
* `#9480 <https://github.com/scipy/scipy/pull/9480>`__: MAINT: linalg:
lstsq clean up
* `#9489 <https://github.com/scipy/scipy/pull/9489>`__: DOC: roadmap update
for changes over the last year.
* `#9492 <https://github.com/scipy/scipy/pull/9492>`__: MAINT: stats:
Improve implementation of chi2 ppf method.
* `#9497 <https://github.com/scipy/scipy/pull/9497>`__: DOC: Improve
docstrings sparse.linalg.isolve
* `#9499 <https://github.com/scipy/scipy/pull/9499>`__: DOC: Replace
"Scipy" with "SciPy" in the .rst doc files for consistency.
* `#9500 <https://github.com/scipy/scipy/pull/9500>`__: DOC: Document the
toolchain and its roadmap.
* `#9505 <https://github.com/scipy/scipy/pull/9505>`__: DOC: specify which
definition of skewness is used
* `#9511 <https://github.com/scipy/scipy/pull/9511>`__: DEP: interpolate:
remove deprecated interpolate_wrapper
* `#9517 <https://github.com/scipy/scipy/pull/9517>`__: BUG: improve error
handling in stats.iqr
* `#9522 <https://github.com/scipy/scipy/pull/9522>`__: ENH: Add Fiedler
and fiedler companion to special matrices
* `#9526 <https://github.com/scipy/scipy/pull/9526>`__: TST: relax
precision requirements in signal.correlate tests
* `#9529 <https://github.com/scipy/scipy/pull/9529>`__: DOC: fix missing
random seed in optimize.newton example
* `#9533 <https://github.com/scipy/scipy/pull/9533>`__: MAINT: Use list
comprehension when possible
* `#9537 <https://github.com/scipy/scipy/pull/9537>`__: DOC: add a "big
picture" roadmap
* `#9538 <https://github.com/scipy/scipy/pull/9538>`__: DOC: Replace
"Numpy" with "NumPy" in .py, .rst and .txt doc files...
* `#9539 <https://github.com/scipy/scipy/pull/9539>`__: ENH: add two-sample
test (Epps-Singleton) to scipy.stats
* `#9559 <https://github.com/scipy/scipy/pull/9559>`__: DOC: add section on
global optimizers to tutorial
* `#9561 <https://github.com/scipy/scipy/pull/9561>`__: ENH: remove
noprefix.h, change code appropriately
* `#9562 <https://github.com/scipy/scipy/pull/9562>`__: MAINT: stats:
Rewrite pearsonr.
* `#9563 <https://github.com/scipy/scipy/pull/9563>`__: BUG: Minor bug fix
Callback in linprog(method='simplex')
* `#9568 <https://github.com/scipy/scipy/pull/9568>`__: MAINT: raise
runtime error for newton with zeroder if disp true,...
* `#9570 <https://github.com/scipy/scipy/pull/9570>`__: Correct docstring
in show_options in optimize. Fixes #9407
* `#9573 <https://github.com/scipy/scipy/pull/9573>`__: BUG fixes range of
pk variable pre-check
* `#9577 <https://github.com/scipy/scipy/pull/9577>`__: TST: fix minor
issue in a signal.stft test.
* `#9580 <https://github.com/scipy/scipy/pull/9580>`__: Included blank line
before list - Fixes #8658
* `#9582 <https://github.com/scipy/scipy/pull/9582>`__: MAINT: drop Python
2.7 and 3.4
* `#9588 <https://github.com/scipy/scipy/pull/9588>`__: MAINT: update
\`constants.astronomical_unit\` to new 2012 value.
* `#9592 <https://github.com/scipy/scipy/pull/9592>`__: TST: Add 32-bit
testing to CI
* `#9593 <https://github.com/scipy/scipy/pull/9593>`__: DOC: Replace
cumulative density with cumulative distribution
* `#9596 <https://github.com/scipy/scipy/pull/9596>`__: TST: remove VC 9.0
from Azure CI
* `#9599 <https://github.com/scipy/scipy/pull/9599>`__: Hyperlink DOI to
preferred resolver
* `#9601 <https://github.com/scipy/scipy/pull/9601>`__: DEV: try to limit
GC memory use on PyPy
* `#9603 <https://github.com/scipy/scipy/pull/9603>`__: MAINT: improve
logcdf and logsf of hypergeometric distribution
* `#9605 <https://github.com/scipy/scipy/pull/9605>`__: Reference to pylops
in LinearOperator notes and ARPACK example
* `#9617 <https://github.com/scipy/scipy/pull/9617>`__: TST: reduce max
memory usage for sparse.linalg.lgmres test
* `#9619 <https://github.com/scipy/scipy/pull/9619>`__: FIX: Sparse matrix
addition/subtraction eliminates explicit zeros
* `#9621 <https://github.com/scipy/scipy/pull/9621>`__: bugfix in rv_sample
in scipy.stats
* `#9622 <https://github.com/scipy/scipy/pull/9622>`__: MAINT: Raise error
in directed_hausdorff distance
* `#9623 <https://github.com/scipy/scipy/pull/9623>`__: DOC: Build docs
with warnings as errors
* `#9625 <https://github.com/scipy/scipy/pull/9625>`__: Return the number
of calls to 'hessp' (not just 'hess') in trust...
* `#9627 <https://github.com/scipy/scipy/pull/9627>`__: BUG: ignore empty
lines in mmio
* `#9637 <https://github.com/scipy/scipy/pull/9637>`__: Function to
calculate the MAD of an array
* `#9646 <https://github.com/scipy/scipy/pull/9646>`__: BUG: stats: mode
for objects w/ndim > 1
* `#9648 <https://github.com/scipy/scipy/pull/9648>`__: Add
\`stats.contingency\` to refguide-check
* `#9650 <https://github.com/scipy/scipy/pull/9650>`__: ENH: many lobpcg()
algorithm improvements
* `#9652 <https://github.com/scipy/scipy/pull/9652>`__: Move misc.doccer to
_lib.doccer
* `#9660 <https://github.com/scipy/scipy/pull/9660>`__: ENH: add pearson,
tippett, and mudholkar-george to combine_pvalues
* `#9661 <https://github.com/scipy/scipy/pull/9661>`__: BUG: Fix ksone
right-hand endpoint, documentation and tests.
* `#9664 <https://github.com/scipy/scipy/pull/9664>`__: ENH: adding
multi-target dijsktra performance enhancement
* `#9670 <https://github.com/scipy/scipy/pull/9670>`__: MAINT: link planck
and geometric distribution in scipy.stats
* `#9676 <https://github.com/scipy/scipy/pull/9676>`__: ENH: optimize:
change default linprog method to interior-point
* `#9685 <https://github.com/scipy/scipy/pull/9685>`__: Added reference to
ndimage.filters.median_filter
* `#9705 <https://github.com/scipy/scipy/pull/9705>`__: Fix coefficients in
expm helper function
* `#9711 <https://github.com/scipy/scipy/pull/9711>`__: Release the GIL
during sosfilt processing for simple types
* `#9721 <https://github.com/scipy/scipy/pull/9721>`__: ENH: Convexhull
visiblefacets
* `#9723 <https://github.com/scipy/scipy/pull/9723>`__: BLD: Modify
rv_generic._construct_doc to print out failing distribution...
* `#9726 <https://github.com/scipy/scipy/pull/9726>`__: BUG: Fix small
issues with \`signal.lfilter'
* `#9729 <https://github.com/scipy/scipy/pull/9729>`__: BUG: Typecheck
iterations for binary image operations
* `#9730 <https://github.com/scipy/scipy/pull/9730>`__: ENH: reduce
sizeof(NI_WatershedElement) by 20%
* `#9731 <https://github.com/scipy/scipy/pull/9731>`__: ENH: remove
suspicious sequence of type castings
* `#9739 <https://github.com/scipy/scipy/pull/9739>`__: BUG: qr_updates
fails if u is exactly in span Q
* `#9749 <https://github.com/scipy/scipy/pull/9749>`__: BUG:
MapWrapper.__exit__ should terminate
* `#9753 <https://github.com/scipy/scipy/pull/9753>`__: ENH: Added exact
computation for Kolmogorov-Smirnov two-sample...
* `#9755 <https://github.com/scipy/scipy/pull/9755>`__: DOC: Added example
for signal.impulse, copied from impulse2
* `#9756 <https://github.com/scipy/scipy/pull/9756>`__: DOC: Added
docstring example for iirdesign
* `#9757 <https://github.com/scipy/scipy/pull/9757>`__: DOC: Added examples
for step functions
* `#9759 <https://github.com/scipy/scipy/pull/9759>`__: ENH: Allow
pass_zero to act like btype
* `#9760 <https://github.com/scipy/scipy/pull/9760>`__: DOC: Added
docstring for lp2bs
* `#9761 <https://github.com/scipy/scipy/pull/9761>`__: DOC: Added
docstring and example for lp2bp
* `#9764 <https://github.com/scipy/scipy/pull/9764>`__: BUG: Catch internal
warnings for matrix
* `#9766 <https://github.com/scipy/scipy/pull/9766>`__: ENH: Speed up
_gaussian_kernel1d by removing dependence on np.polynomial
* `#9769 <https://github.com/scipy/scipy/pull/9769>`__: BUG: Fix Cubic
Spline Read Only issues
* `#9773 <https://github.com/scipy/scipy/pull/9773>`__: DOC: Several
docstrings
* `#9774 <https://github.com/scipy/scipy/pull/9774>`__: TST: bump Azure CI
OpenBLAS version to match wheels
* `#9775 <https://github.com/scipy/scipy/pull/9775>`__: DOC: Improve
clarity of cov_x documentation for scipy.optimize.leastsq
* `#9779 <https://github.com/scipy/scipy/pull/9779>`__: ENH: dual_annealing
vectorise visit_fn
* `#9788 <https://github.com/scipy/scipy/pull/9788>`__: TST, BUG:
f2py-related issues with NumPy < 1.14.0
* `#9791 <https://github.com/scipy/scipy/pull/9791>`__: BUG: fix amax
constraint not enforced in scalar_search_wolfe2
* `#9792 <https://github.com/scipy/scipy/pull/9792>`__: ENH: Allow inplace
copying in place in "detrend" function
* `#9795 <https://github.com/scipy/scipy/pull/9795>`__: DOC: Fix/update
docstring for dstn and dst
* `#9796 <https://github.com/scipy/scipy/pull/9796>`__: MAINT: Allow None
tolerances in least_squares
* `#9798 <https://github.com/scipy/scipy/pull/9798>`__: BUG: fixes abort
trap 6 error in scipy issue 9785 in unit tests
* `#9807 <https://github.com/scipy/scipy/pull/9807>`__: MAINT: improve doc
and add alternative keyword to wilcoxon in...
* `#9808 <https://github.com/scipy/scipy/pull/9808>`__: Fix PPoly integrate
and test for CubicSpline
* `#9810 <https://github.com/scipy/scipy/pull/9810>`__: ENH: Add the
geometric standard deviation function
* `#9811 <https://github.com/scipy/scipy/pull/9811>`__: MAINT: remove
invalid derphi default None value in scalar_search_wolfe2
* `#9813 <https://github.com/scipy/scipy/pull/9813>`__: Adapt hamming
distance in C to support weights
* `#9817 <https://github.com/scipy/scipy/pull/9817>`__: DOC: Copy solver
description to solver modules
* `#9829 <https://github.com/scipy/scipy/pull/9829>`__: ENH: Add FOH and
equivalent impulse response discretizations...
* `#9831 <https://github.com/scipy/scipy/pull/9831>`__: ENH: Implement
RotationSpline
* `#9834 <https://github.com/scipy/scipy/pull/9834>`__: DOC: Change mielke
distribution default parameters to ensure...
* `#9838 <https://github.com/scipy/scipy/pull/9838>`__: ENH: Use faster
solvers for firls
* `#9854 <https://github.com/scipy/scipy/pull/9854>`__: ENH: loadarff now
supports relational attributes.
* `#9856 <https://github.com/scipy/scipy/pull/9856>`__: integrate.bvp -
improve handling of nonlinear boundary conditions
* `#9862 <https://github.com/scipy/scipy/pull/9862>`__: TST: reduce
Appveyor CI load
* `#9874 <https://github.com/scipy/scipy/pull/9874>`__: DOC: Update
requirements in release notes
* `#9883 <https://github.com/scipy/scipy/pull/9883>`__: BUG: fixed
parenthesis in spatial.rotation
* `#9884 <https://github.com/scipy/scipy/pull/9884>`__: ENH: Use Sparsity
in Clarkson-Woodruff Sketch
* `#9888 <https://github.com/scipy/scipy/pull/9888>`__: MAINT: Replace
NumPy aliased functions
* `#9892 <https://github.com/scipy/scipy/pull/9892>`__: BUG: Fix 9890
query_ball_point returns wrong result when p is...
* `#9893 <https://github.com/scipy/scipy/pull/9893>`__: BUG: curve_fit
doesn't check for empty input if called with bounds
* `#9894 <https://github.com/scipy/scipy/pull/9894>`__:
scipy.signal.find_peaks documentation error
* `#9898 <https://github.com/scipy/scipy/pull/9898>`__: BUG: Set success
attribute in OptimizeResult. See #9801
* `#9900 <https://github.com/scipy/scipy/pull/9900>`__: BUG: Restrict
rv_generic._argcheck() and its overrides from setting...
* `#9906 <https://github.com/scipy/scipy/pull/9906>`__: fixed a bug in kde
logpdf
* `#9911 <https://github.com/scipy/scipy/pull/9911>`__: DOC: replace
example for "np.select" with the one from numpy...
* `#9912 <https://github.com/scipy/scipy/pull/9912>`__: BF(DOC): point to
numpy.select instead of plain (python) .select
* `#9914 <https://github.com/scipy/scipy/pull/9914>`__: DOC: change
ValueError message in _validate_pad of signaltools.
* `#9915 <https://github.com/scipy/scipy/pull/9915>`__: cKDTree
query_ball_point improvements
* `#9918 <https://github.com/scipy/scipy/pull/9918>`__: Update ckdtree.pyx
with boxsize argument in docstring
* `#9920 <https://github.com/scipy/scipy/pull/9920>`__: BUG: sparse:
Validate explicit shape if given with dense argument...
* `#9924 <https://github.com/scipy/scipy/pull/9924>`__: BLD: add back
pyproject.toml
* `#9931 <https://github.com/scipy/scipy/pull/9931>`__: Fix empty constraint
* `#9935 <https://github.com/scipy/scipy/pull/9935>`__: DOC: fix references
for stats.f_oneway
* `#9936 <https://github.com/scipy/scipy/pull/9936>`__: Revert gh-9619:
"FIX: Sparse matrix addition/subtraction eliminates...
* `#9937 <https://github.com/scipy/scipy/pull/9937>`__: MAINT: fix PEP8
issues and update to pycodestyle 2.5.0
* `#9939 <https://github.com/scipy/scipy/pull/9939>`__: DOC: correct
\`structure\` description in \`ndimage.label\` docstring
* `#9940 <https://github.com/scipy/scipy/pull/9940>`__: MAINT: remove
extraneous distutils copies
* `#9945 <https://github.com/scipy/scipy/pull/9945>`__: ENH:
differential_evolution can use Bounds object
* `#9949 <https://github.com/scipy/scipy/pull/9949>`__: Added 'std' to add
doctstrings since it is a \`known_stats\`...
* `#9953 <https://github.com/scipy/scipy/pull/9953>`__: DOC: Documentation
cleanup for stats tutorials.
* `#9962 <https://github.com/scipy/scipy/pull/9962>`__: __repr__ for Bounds
* `#9971 <https://github.com/scipy/scipy/pull/9971>`__: ENH: Improve
performance of lsmr
* `#9987 <https://github.com/scipy/scipy/pull/9987>`__: CI: pin Sphinx
version to 1.8.5
* `#9990 <https://github.com/scipy/scipy/pull/9990>`__: ENH: constraint
violation
* `#9991 <https://github.com/scipy/scipy/pull/9991>`__: BUG: Avoid inplace
modification of input array in newton
* `#9995 <https://github.com/scipy/scipy/pull/9995>`__: MAINT:
sparse.csgraph: Add cdef to stop build warning.
* `#9996 <https://github.com/scipy/scipy/pull/9996>`__: BUG: Make
minimize_quadratic_1d work with infinite bounds correctly
* `#10004 <https://github.com/scipy/scipy/pull/10004>`__: BUG: Fix unbound
local error in linprog - simplex.
* `#10007 <https://github.com/scipy/scipy/pull/10007>`__: BLD: fix Python
3.7 build with build isolation
* `#10009 <https://github.com/scipy/scipy/pull/10009>`__: BUG: Make sure
that _binary_erosion only accepts an integer number...
* `#10016 <https://github.com/scipy/scipy/pull/10016>`__: Update link to
airspeed-velocity
* `#10017 <https://github.com/scipy/scipy/pull/10017>`__: DOC: Update
\`interpolate.LSQSphereBivariateSpline\` to include...
* `#10018 <https://github.com/scipy/scipy/pull/10018>`__: MAINT: special:
Fix a few warnings that occur when compiling...
* `#10019 <https://github.com/scipy/scipy/pull/10019>`__: TST: Azure
summarizes test failures
* `#10021 <https://github.com/scipy/scipy/pull/10021>`__: ENH: Introduce
CubicHermiteSpline
* `#10022 <https://github.com/scipy/scipy/pull/10022>`__: BENCH: Increase
cython version in asv to fix benchmark builds
* `#10023 <https://github.com/scipy/scipy/pull/10023>`__: BUG: Avoid
exponnorm producing nan for small K values.
* `#10025 <https://github.com/scipy/scipy/pull/10025>`__: BUG: optimize:
tweaked linprog status 4 error message
* `#10026 <https://github.com/scipy/scipy/pull/10026>`__: ENH: optimize:
use SuiteSparse in linprog interior-point when...
* `#10027 <https://github.com/scipy/scipy/pull/10027>`__: MAINT: cluster:
clean up the use of malloc() in the function...
* `#10028 <https://github.com/scipy/scipy/pull/10028>`__: Fix rotate
invalid plane check
* `#10040 <https://github.com/scipy/scipy/pull/10040>`__: MAINT: fix pratt
method of wilcox test in scipy.stats
* `#10041 <https://github.com/scipy/scipy/pull/10041>`__: MAINT: special:
Fix a warning generated when building the AMOS...
* `#10044 <https://github.com/scipy/scipy/pull/10044>`__: DOC: fix up
spatial.transform.Rotation docstrings
* `#10047 <https://github.com/scipy/scipy/pull/10047>`__: MAINT:
interpolate: Fix a few build warnings.
* `#10051 <https://github.com/scipy/scipy/pull/10051>`__: Add project_urls
to setup
* `#10052 <https://github.com/scipy/scipy/pull/10052>`__: don't set flag to
"converged" if max iter exceeded
* `#10054 <https://github.com/scipy/scipy/pull/10054>`__: MAINT: signal:
Fix a few build warnings and modernize some C...
* `#10056 <https://github.com/scipy/scipy/pull/10056>`__: BUG: Ensure
factorial is not too large in kendaltau
* `#10058 <https://github.com/scipy/scipy/pull/10058>`__: Small speedup in
samping from ortho and special_ortho groups
* `#10059 <https://github.com/scipy/scipy/pull/10059>`__: BUG: optimize:
fix #10038 by increasing tol
* `#10061 <https://github.com/scipy/scipy/pull/10061>`__: BLD: DOC: make
building docs easier by parsing python version.
* `#10064 <https://github.com/scipy/scipy/pull/10064>`__: ENH: Significant
speedup for ortho and special ortho group
* `#10065 <https://github.com/scipy/scipy/pull/10065>`__: DOC: Reword
parameter descriptions in \`optimize.root_scalar\`
* `#10066 <https://github.com/scipy/scipy/pull/10066>`__: BUG: signal: Fix
error raised by savgol_coeffs when deriv > polyorder.
* `#10067 <https://github.com/scipy/scipy/pull/10067>`__: MAINT: Fix the
cutoff value inconsistency for pinv2 and pinvh
* `#10072 <https://github.com/scipy/scipy/pull/10072>`__: BUG: stats: Fix
boxcox_llf to avoid loss of precision.
* `#10075 <https://github.com/scipy/scipy/pull/10075>`__: ENH: Add wrappers
for ?syconv routines
* `#10076 <https://github.com/scipy/scipy/pull/10076>`__: BUG: optimize:
fix curve_fit for mixed float32/float64 input
* `#10077 <https://github.com/scipy/scipy/pull/10077>`__: DOC: Replace
undefined \`k\` in \`interpolate.splev\` docstring
* `#10079 <https://github.com/scipy/scipy/pull/10079>`__: DOC: Fixed typo,
rearranged some doc of stats.morestats.wilcoxon.
* `#10080 <https://github.com/scipy/scipy/pull/10080>`__: TST: install
scikit-sparse for full TravisCI tests
* `#10083 <https://github.com/scipy/scipy/pull/10083>`__: Clean
\`\`_clean_inputs\`\` in optimize.linprog
* `#10088 <https://github.com/scipy/scipy/pull/10088>`__: ENH: optimize:
linprog test CHOLMOD/UMFPACK solvers when available
* `#10090 <https://github.com/scipy/scipy/pull/10090>`__: MAINT: Fix
CubicSplinerInterpolator for pandas
* `#10091 <https://github.com/scipy/scipy/pull/10091>`__: MAINT: improve
logcdf and logsf of hypergeometric distribution
* `#10095 <https://github.com/scipy/scipy/pull/10095>`__: MAINT: Clean
\`\`_clean_inputs\`\` in linprog
* `#10116 <https://github.com/scipy/scipy/pull/10116>`__: MAINT: update
scipy-sphinx-theme
* `#10135 <https://github.com/scipy/scipy/pull/10135>`__: BUG: fix linprog
revised simplex docstring problem failure

Checksums
=========

MD5
~~~

209c50a628a624fc82535299f5913d65
 scipy-1.3.0-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
54e6fdb6aacbcaeff6dc86fc736cf39a  scipy-1.3.0-cp35-cp35m-manylinux1_i686.whl
752f9cae504e7ea06cd818fc74b829c0
 scipy-1.3.0-cp35-cp35m-manylinux1_x86_64.whl
c7a0ff2b530570feefa8102813fc6dd1  scipy-1.3.0-cp35-cp35m-win32.whl
1c53ccff157fe23b165e53fba87c37e0  scipy-1.3.0-cp35-cp35m-win_amd64.whl
6762dc85ef6fe357e5710c32451b29a2
 scipy-1.3.0-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
03d9c756b5bc836194cd5d13cd73e3fe  scipy-1.3.0-cp36-cp36m-manylinux1_i686.whl
1e5af3fade676e5a588d40d785e7ee4d
 scipy-1.3.0-cp36-cp36m-manylinux1_x86_64.whl
fe130e4cb77078c6a886795bcf1fa66d  scipy-1.3.0-cp36-cp36m-win32.whl
f62f60ea0397b7aa9a90fb610fc54d33  scipy-1.3.0-cp36-cp36m-win_amd64.whl
a1ec52b1b162bb7ae0d0ea76438e35ce
 scipy-1.3.0-cp37-cp37m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
260d182114edaed177c64d60776ceee6  scipy-1.3.0-cp37-cp37m-manylinux1_i686.whl
38c5a038504e03b503f7674b30218068
 scipy-1.3.0-cp37-cp37m-manylinux1_x86_64.whl
2390fdb5a4330c54c2a5308afe959bb9  scipy-1.3.0-cp37-cp37m-win32.whl
452157882a9f180914906df9bbf9d7bf  scipy-1.3.0-cp37-cp37m-win_amd64.whl
c6876673adf7e9e6c0307beaca784ad2  scipy-1.3.0.tar.gz
e7153c2eb276bc303699b75858db6276  scipy-1.3.0.tar.xz
16b9e6a0ea8bdcf2ea72fda5975a252c  scipy-1.3.0.zip

SHA256
~~~~~~

4907040f62b91c2e170359c3d36c000af783f0fa1516a83d6c1517cde0af5340
 scipy-1.3.0-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
1db9f964ed9c52dc5bd6127f0dd90ac89791daa690a5665cc01eae185912e1ba
 scipy-1.3.0-cp35-cp35m-manylinux1_i686.whl
adadeeae5500de0da2b9e8dd478520d0a9945b577b2198f2462555e68f58e7ef
 scipy-1.3.0-cp35-cp35m-manylinux1_x86_64.whl
03b1e0775edbe6a4c64effb05fff2ce1429b76d29d754aa5ee2d848b60033351
 scipy-1.3.0-cp35-cp35m-win32.whl
a7695a378c2ce402405ea37b12c7a338a8755e081869bd6b95858893ceb617ae
 scipy-1.3.0-cp35-cp35m-win_amd64.whl
826b9f5fbb7f908a13aa1efd4b7321e36992f5868d5d8311c7b40cf9b11ca0e7
 scipy-1.3.0-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
b283a76a83fe463c9587a2c88003f800e08c3929dfbeba833b78260f9c209785
 scipy-1.3.0-cp36-cp36m-manylinux1_i686.whl
db61a640ca20f237317d27bc658c1fc54c7581ff7f6502d112922dc285bdabee
 scipy-1.3.0-cp36-cp36m-manylinux1_x86_64.whl
409846be9d6bdcbd78b9e5afe2f64b2da5a923dd7c1cd0615ce589489533fdbb
 scipy-1.3.0-cp36-cp36m-win32.whl
c19a7389ab3cd712058a8c3c9ffd8d27a57f3d84b9c91a931f542682bb3d269d
 scipy-1.3.0-cp36-cp36m-win_amd64.whl
09d008237baabf52a5d4f5a6fcf9b3c03408f3f61a69c404472a16861a73917e
 scipy-1.3.0-cp37-cp37m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
a84c31e8409b420c3ca57fd30c7589378d6fdc8d155d866a7f8e6e80dec6fd06
 scipy-1.3.0-cp37-cp37m-manylinux1_i686.whl
c5ea60ece0c0c1c849025bfc541b60a6751b491b6f11dd9ef37ab5b8c9041921
 scipy-1.3.0-cp37-cp37m-manylinux1_x86_64.whl
6c0543f2fdd38dee631fb023c0f31c284a532d205590b393d72009c14847f5b1
 scipy-1.3.0-cp37-cp37m-win32.whl
10325f0ffac2400b1ec09537b7e403419dcd25d9fee602a44e8a32119af9079e
 scipy-1.3.0-cp37-cp37m-win_amd64.whl
c3bb4bd2aca82fb498247deeac12265921fe231502a6bc6edea3ee7fe6c40a7a
 scipy-1.3.0.tar.gz
ae105c28c1fdb480bf22fd1b1392eeb8679f3c0c8917c87fca8aabf323918455
 scipy-1.3.0.tar.xz
b711ec1567439a1abfac59321b73a40de70a93ace4a33be26001eb4b12206356
 scipy-1.3.0.zip
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJc3vVHAAoJELD/41ZX0J71Dz4P+QFv7E3OIWcrTm6qjt9X4Mgi
6heershUpVhZATGj7Kpl+lPEBGthsnkT8MeS0/YW3ZKiDWnQoSWSIxBRnqoXup2D
CwjeXn4eKw7Z4G2A6MpKcdJe1xV1lY2Wi3MyfmkYnkO0be+NLMStrTS/1+JdM/Xg
fGt5KqE+QXqB3sEGGf3SXP8tnSS2ULbKNPAxSTL1twS0bEprOVspCtCQJd3Xm1Oi
g2+vWcIwH80KpphvZLl7F22FOI+birxn19CwNupMaN8IyW0RADUKOvYlWMamUA3K
iW6KUyHXolyjixAh4RDZUKg0hNUIbDpMBKslqY+Faz92RCCbxCx+TZGT6y+0chrp
ujE+jRfuXcSk5eykBIzYx3aLPkMH1aQ4ERCi1hxODkTlV22btlSam5diNAOmQeZz
MhQEmbtx5C9xEEHIrGpsuMHVGZfMm0/QaN23Wn/oRq4e7BsICHfZIoNMjW7/ohSv
cT0jKFHjzvS3gigT1c8EkzwtFweLp5gYGGUD4IiLOI898pvmns+DcW9coGkwrQ0E
0OqTjpIIEPCDpHNrgRqWK8RhvqvkiDTs3HbCaxsMOMkWzlPOnrM37frqUO53SVQH
SKwe1ic13dKh332CMPcqB5EslBKEx2juexwmqPhG3Wnsy2+dL40yi7TGJYh9Vytn
ByYnyWurPkhp4WJTN1OD
=xiYy
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190517/7f9b1edf/attachment-0001.html>

From warren.weckesser at gmail.com  Sat May 18 00:53:45 2019
From: warren.weckesser at gmail.com (Warren Weckesser)
Date: Sat, 18 May 2019 00:53:45 -0400
Subject: [SciPy-Dev] [Numpy-discussion] ANN: SciPy 1.3.0
In-Reply-To: <CAHPuU_YDgsq_Pt8iAsWL-6qhRyFdAd=BU0SLaHU3U0n-ypvG8g@mail.gmail.com>
References: <CAHPuU_YDgsq_Pt8iAsWL-6qhRyFdAd=BU0SLaHU3U0n-ypvG8g@mail.gmail.com>
Message-ID: <CAGzF1ucrT1hvQfgQP2fekv=2GkzAHd_LgkgVacD6iWuhozY7Wg@mail.gmail.com>

On 5/17/19, Tyler Reddy <tyler.je.reddy at gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi all,
>
> On behalf of the SciPy development team I'm pleased to announce
> the release of SciPy 1.3.0.


A big "thank you" to everyone who contributed to 1.3.0, and especially
to Tyler for managing the release so well.  Congatulations!

Warren


>
> Sources and binary wheels can be found at:
> https://pypi.org/project/scipy/
> and at:
> https://github.com/scipy/scipy/releases/tag/v1.3.0
>
> One of a few ways to install this release with pip:
>
> pip install scipy==1.3.0
>
> ==========================
> SciPy 1.3.0 Release Notes
> ==========================
>
> SciPy 1.3.0 is the culmination of 5 months of hard work. It contains
> many new features, numerous bug-fixes, improved test coverage and better
> documentation. There have been some API changes
> in this release, which are documented below. All users are encouraged to
> upgrade to this release, as there are a large number of bug-fixes and
> optimizations. Before upgrading, we recommend that users check that
> their own code does not use deprecated SciPy functionality (to do so,
> run your code with ``python -Wd`` and check for ``DeprecationWarning`` s).
> Our development attention will now shift to bug-fix releases on the
> 1.3.x branch, and on adding new features on the master branch.
>
> This release requires Python 3.5+ and NumPy 1.13.3 or greater.
>
> For running on PyPy, PyPy3 6.0+ and NumPy 1.15.0 are required.
>
> Highlights of this release
> ---------------------------------
>
> - - Three new ``stats`` functions, a rewrite of ``pearsonr``, and an exact
>   computation of the Kolmogorov-Smirnov two-sample test
> - - A new Cython API for bounded scalar-function root-finders in
> `scipy.optimize`
> - - Substantial ``CSR`` and ``CSC`` sparse matrix indexing performance
>   improvements
> - - Added support for interpolation of rotations with continuous angular
>   rate and acceleration in ``RotationSpline``
>
>
> New features
> ============
>
> `scipy.interpolate` improvements
> -------------------------------------------
>
> A new class ``CubicHermiteSpline`` is introduced. It is a piecewise-cubic
> interpolator which matches observed values and first derivatives. Existing
> cubic interpolators ``CubicSpline``, ``PchipInterpolator`` and
> ``Akima1DInterpolator`` were made subclasses of ``CubicHermiteSpline``.
>
> `scipy.io` improvements
> --------------------------------
>
> For the Attribute-Relation File Format (ARFF) `scipy.io.arff.loadarff`
> now supports relational attributes.
>
> `scipy.io.mmread` can now parse Matrix Market format files with empty
> lines.
>
> `scipy.linalg` improvements
> ------------------------------------
>
> Added wrappers for ``?syconv`` routines, which convert a symmetric matrix
> given by a triangular matrix factorization into two matrices and vice
> versa.
>
> `scipy.linalg.clarkson_woodruff_transform` now uses an algorithm that
> leverages
> sparsity. This may provide a 60-90 percent speedup for dense input
> matrices.
> Truly sparse input matrices should also benefit from the improved sketch
> algorithm, which now correctly runs in ``O(nnz(A))`` time.
>
> Added new functions to calculate symmetric Fiedler matrices and
> Fiedler companion matrices, named `scipy.linalg.fiedler` and
> `scipy.linalg.fiedler_companion`, respectively. These may be used
> for root finding.
>
> `scipy.ndimage` improvements
> ----------------------------------------
>
> Gaussian filter performances may improve by an order of magnitude in
> some cases, thanks to removal of a dependence on ``np.polynomial``. This
> may impact `scipy.ndimage.gaussian_filter` for example.
>
> `scipy.optimize` improvements
> ----------------------------------------
>
> The `scipy.optimize.brute` minimizer obtained a new keyword ``workers``,
> which
> can be used to parallelize computation.
>
> A Cython API for bounded scalar-function root-finders in `scipy.optimize`
> is available in a new module `scipy.optimize.cython_optimize` via
> ``cimport``.
> This API may be used with ``nogil`` and ``prange`` to loop
> over an array of function arguments to solve for an array of roots more
> quickly than with pure Python.
>
> ``'interior-point'`` is now the default method for ``linprog``, and
> ``'interior-point'`` now uses SuiteSparse for sparse problems when the
> required scikits  (scikit-umfpack and scikit-sparse) are available.
> On benchmark problems (gh-10026), execution time reductions by factors of
> 2-3
> were typical. Also, a new ``method='revised simplex'`` has been added.
> It is not as fast or robust as ``method='interior-point'``, but it is a
> faster,
> more robust, and equally accurate substitute for the legacy
> ``method='simplex'``.
>
> ``differential_evolution`` can now use a ``Bounds`` class to specify the
> bounds for the optimizing argument of a function.
>
> `scipy.optimize.dual_annealing` performance improvements related to
> vectorisation of some internal code.
>
> `scipy.signal` improvements
> -------------------------------------
>
> Two additional methods of discretization are now supported by
> `scipy.signal.cont2discrete`: ``impulse`` and ``foh``.
>
> `scipy.signal.firls` now uses faster solvers
>
> `scipy.signal.detrend` now has a lower physical memory footprint in some
> cases, which may be leveraged using the new ``overwrite_data`` keyword
> argument
>
> `scipy.signal.firwin` ``pass_zero`` argument now accepts new string
> arguments
> that allow specification of the desired filter type: ``'bandpass'``,
> ``'lowpass'``, ``'highpass'``, and ``'bandstop'``
>
> `scipy.signal.sosfilt` may have improved performance due to lower retention
> of the global interpreter lock (GIL) in algorithm
>
> `scipy.sparse` improvements
> --------------------------------------
>
> A new keyword was added to ``csgraph.dijsktra`` that
> allows users to query the shortest path to ANY of the passed in indices,
> as opposed to the shortest path to EVERY passed index.
>
> `scipy.sparse.linalg.lsmr` performance has been improved by roughly 10
> percent
> on large problems
>
> Improved performance and reduced physical memory footprint of the algorithm
> used by `scipy.sparse.linalg.lobpcg`
>
> ``CSR`` and ``CSC`` sparse matrix fancy indexing performance has been
> improved substantially
>
> `scipy.spatial` improvements
> --------------------------------------
>
> `scipy.spatial.ConvexHull` now has a ``good`` attribute that can be used
> alongsize the ``QGn`` Qhull options to determine which external facets of a
> convex hull are visible from an external query point.
>
> `scipy.spatial.cKDTree.query_ball_point` has been modernized to use some
> newer
> Cython features, including GIL handling and exception translation. An issue
> with ``return_sorted=True`` and scalar queries was fixed, and a new mode
> named
> ``return_length`` was added. ``return_length`` only computes the length of
> the
> returned indices list instead of allocating the array every time.
>
> `scipy.spatial.transform.RotationSpline` has been added to enable
> interpolation
> of rotations with continuous angular rates and acceleration
>
> `scipy.stats` improvements
> ------------------------------------
>
> Added a new function to compute the Epps-Singleton test statistic,
> `scipy.stats.epps_singleton_2samp`, which can be applied to continuous and
> discrete distributions.
>
> New functions `scipy.stats.median_absolute_deviation` and
> `scipy.stats.gstd`
> (geometric standard deviation) were added. The
> `scipy.stats.combine_pvalues`
> method now supports ``pearson``,  ``tippett`` and ``mudholkar_george``
> pvalue
> combination methods.
>
> The `scipy.stats.ortho_group` and `scipy.stats.special_ortho_group`
> ``rvs(dim)`` functions' algorithms were updated from a ``O(dim^4)``
> implementation to a ``O(dim^3)`` which gives large speed improvements
> for ``dim>100``.
>
> A rewrite of `scipy.stats.pearsonr` to use a more robust algorithm,
> provide meaningful exceptions and warnings on potentially pathological
> input,
> and fix at least five separate reported issues in the original
> implementation.
>
> Improved the precision of ``hypergeom.logcdf`` and ``hypergeom.logsf``.
>
> Added exact computation for Kolmogorov-Smirnov (KS) two-sample test,
> replacing
> the previously approximate computation for the two-sided test
> `stats.ks_2samp`.
> Also added a one-sided, two-sample KS test, and a keyword ``alternative``
> to
> `stats.ks_2samp`.
>
> Backwards incompatible changes
> ==========================
>
> `scipy.interpolate` changes
> ------------------------------------
>
> Functions from ``scipy.interpolate`` (``spleval``, ``spline``, ``splmake``,
> and ``spltopp``) and functions from ``scipy.misc`` (``bytescale``,
> ``fromimage``, ``imfilter``, ``imread``, ``imresize``, ``imrotate``,
> ``imsave``, ``imshow``, ``toimage``) have been removed. The former set has
> been deprecated since v0.19.0 and the latter has been deprecated since
> v1.0.0.
> Similarly, aliases from ``scipy.misc`` (``comb``, ``factorial``,
> ``factorial2``, ``factorialk``, ``logsumexp``, ``pade``, ``info``,
> ``source``,
> ``who``) which have been deprecated since v1.0.0 are removed.
> `SciPy documentation for
> v1.1.0 <https://docs.scipy.org/doc/scipy-1.1.0/reference/misc.html>`__
> can be used to track the new import locations for the relocated functions.
>
> `scipy.linalg` changes
> -----------------------------
>
> For ``pinv``, ``pinv2``, and ``pinvh``, the default cutoff values are
> changed
> for consistency (see the docs for the actual values).
>
> `scipy.optimize` changes
> ---------------------------------
>
> The default method for ``linprog`` is now ``'interior-point'``. The
> method's
> robustness and speed come at a cost: solutions may not be accurate to
> machine precision or correspond with a vertex of the polytope defined
> by the constraints. To revert to the original simplex method,
> include the argument ``method='simplex'``.
>
> `scipy.stats` changes
> ----------------------------
>
> Previously, ``ks_2samp(data1, data2)`` would run a two-sided test and
> return
> the approximated p-value. The new signature, ``ks_2samp(data1, data2,
> alternative="two-sided", method="auto")``, still runs the two-sided test by
> default but returns the exact p-value for small samples and the
> approximated
> value for large samples. ``method="asymp"`` would be equivalent to the
> old version but ``auto`` is the better choice.
>
> Other changes
> =============
>
> Our tutorial has been expanded with a new section on global optimizers
>
> There has been a rework of the ``stats.distributions`` tutorials.
>
> `scipy.optimize` now correctly sets the convergence flag of the result to
> ``CONVERR``, a convergence error, for bounded scalar-function root-finders
> if the maximum iterations has been exceeded, ``disp`` is false, and
> ``full_output`` is true.
>
> `scipy.optimize.curve_fit` no longer fails if ``xdata`` and ``ydata``
> dtypes
> differ; they are both now automatically cast to ``float64``.
>
> `scipy.ndimage` functions including ``binary_erosion``, ``binary_closing``,
> and
> ``binary_dilation`` now require an integer value for the number of
> iterations,
> which alleviates a number of reported issues.
>
> Fixed normal approximation in case ``zero_method == "pratt"`` in
> `scipy.stats.wilcoxon`.
>
> Fixes for incorrect probabilities, broadcasting issues and thread-safety
> related to stats distributions setting member variables inside
> ``_argcheck()``.
>
> `scipy.optimize.newton` now correctly raises a ``RuntimeError``, when
> default
> arguments are used, in the case that a derivative of value zero is
> obtained,
> which is a special case of failing to converge.
>
> A draft toolchain roadmap is now available, laying out a compatibility plan
> including Python versions, C standards, and NumPy versions.
>
>
> Authors
> =======
>
> * ananyashreyjain +
> * ApamNapat +
> * Scott Calabrese Barton +
> * Christoph Baumgarten
> * Peter Bell +
> * Jacob Blomgren +
> * Doctor Bob +
> * Mana Borwornpadungkitti +
> * Matthew Brett
> * Evgeni Burovski
> * CJ Carey
> * Vega Theil Carstensen +
> * Robert Cimrman
> * Forrest Collman +
> * Pietro Cottone +
> * David +
> * Idan David +
> * Christoph Deil
> * Dieter Werthm?ller
> * Conner DiPaolo +
> * Dowon
> * Michael Dunphy +
> * Peter Andreas Entschev +
> * G?k?en Eraslan +
> * Johann Faouzi +
> * Yu Feng
> * Piotr Figiel +
> * Matthew H Flamm
> * Franz Forstmayr +
> * Christoph Gohlke
> * Richard Janis Goldschmidt +
> * Ralf Gommers
> * Lars Grueter
> * Sylvain Gubian
> * Matt Haberland
> * Yaroslav Halchenko
> * Charles Harris
> * Lindsey Hiltner
> * JakobStruye +
> * He Jia +
> * Jwink3101 +
> * Greg Kiar +
> * Julius Bier Kirkegaard
> * John Kirkham +
> * Thomas Kluyver
> * Vladimir Korolev +
> * Joseph Kuo +
> * Michael Lamparski +
> * Eric Larson
> * Denis Laxalde
> * Katrin Leinweber
> * Jesse Livezey
> * ludcila +
> * Dhruv Madeka +
> * Magnus +
> * Nikolay Mayorov
> * Mark Mikofski
> * Jarrod Millman
> * Markus Mohrhard +
> * Eric Moore
> * Andrew Nelson
> * Aki Nishimura +
> * OGordon100 +
> * Petar Mlinari? +
> * Stefan Peterson
> * Matti Picus +
> * Ilhan Polat
> * Aaron Pries +
> * Matteo Ravasi +
> * Tyler Reddy
> * Ashton Reimer +
> * Joscha Reimer
> * rfezzani +
> * Riadh +
> * Lucas Roberts
> * Heshy Roskes +
> * Mirko Scholz +
> * Taylor D. Scott +
> * Srikrishna Sekhar +
> * Kevin Sheppard +
> * Sourav Singh
> * skjerns +
> * Kai Striega
> * SyedSaifAliAlvi +
> * Gopi Manohar T +
> * Albert Thomas +
> * Timon +
> * Paul van Mulbregt
> * Jacob Vanderplas
> * Daniel Vargas +
> * Pauli Virtanen
> * VNMabus +
> * Stefan van der Walt
> * Warren Weckesser
> * Josh Wilson
> * Nate Yoder +
> * Roman Yurchak
>
> A total of 97 people contributed to this release.
> People with a "+" by their names contributed a patch for the first time.
> This list of names is automatically generated, and may not be fully
> complete.
>
> Issues closed for 1.3.0
> -------------------------------
>
> * `#1320 <https://github.com/scipy/scipy/issues/1320>`__:
> scipy.stats.distribution: problem with self.a, self.b if they...
> * `#2002 <https://github.com/scipy/scipy/issues/2002>`__: members set in
> scipy.stats.distributions.##._argcheck (Trac #1477)
> * `#2823 <https://github.com/scipy/scipy/issues/2823>`__: distribution
> methods add tmp
> * `#3220 <https://github.com/scipy/scipy/issues/3220>`__:
> Scipy.opimize.fmin_powell direc argument syntax unclear
> * `#3728 <https://github.com/scipy/scipy/issues/3728>`__:
> scipy.stats.pearsonr: possible bug with zero variance input
> * `#6805 <https://github.com/scipy/scipy/issues/6805>`__:
> error-in-scipy-wilcoxon-signed-rank-test-for-equal-series
> * `#6873 <https://github.com/scipy/scipy/issues/6873>`__: 'stats.boxcox'
> return all same values
> * `#7117 <https://github.com/scipy/scipy/issues/7117>`__: Warn users when
> using float32 input data to curve_fit and friends
> * `#7632 <https://github.com/scipy/scipy/issues/7632>`__: it's not possible
> to tell the \`optimize.least_squares\` solver...
> * `#7730 <https://github.com/scipy/scipy/issues/7730>`__: stats.pearsonr:
> Potential division by zero for dataset of length...
> * `#7933 <https://github.com/scipy/scipy/issues/7933>`__: stats.truncnorm
> fails when providing values outside truncation...
> * `#8033 <https://github.com/scipy/scipy/issues/8033>`__: Add standard
> filter types to firwin to set pass_zero intuitively...
> * `#8600 <https://github.com/scipy/scipy/issues/8600>`__: lfilter.c.src
> zfill has erroneous header
> * `#8692 <https://github.com/scipy/scipy/issues/8692>`__: Non-negative
> values of \`stats.hypergeom.logcdf\`
> * `#8734 <https://github.com/scipy/scipy/issues/8734>`__: Enable pip build
> isolation
> * `#8861 <https://github.com/scipy/scipy/issues/8861>`__: scipy.linalg.pinv
> gives wrong result while scipy.linalg.pinv2...
> * `#8915 <https://github.com/scipy/scipy/issues/8915>`__: need to fix macOS
> build against older numpy versions
> * `#8980 <https://github.com/scipy/scipy/issues/8980>`__:
> scipy.stats.pearsonr overflows with high values of x and y
> * `#9226 <https://github.com/scipy/scipy/issues/9226>`__: BUG: signal:
> SystemError: <built-in function _linear_filter>...
> * `#9254 <https://github.com/scipy/scipy/issues/9254>`__: BUG: root finders
> brentq, etc, flag says "converged" even if...
> * `#9308 <https://github.com/scipy/scipy/issues/9308>`__: Test failure -
> test_initial_constraints_as_canonical
> * `#9353 <https://github.com/scipy/scipy/issues/9353>`__:
> scipy.stats.pearsonr returns r=1 if r_num/r_den = inf
> * `#9359 <https://github.com/scipy/scipy/issues/9359>`__: Planck
> distribution is a geometric distribution
> * `#9381 <https://github.com/scipy/scipy/issues/9381>`__: linregress should
> warn user in 2x2 array case
> * `#9406 <https://github.com/scipy/scipy/issues/9406>`__: BUG: stats: In
> pearsonr, when r is nan, the p-value must also...
> * `#9437 <https://github.com/scipy/scipy/issues/9437>`__: Cannot create
> sparse matrix from size_t indexes
> * `#9518 <https://github.com/scipy/scipy/issues/9518>`__: Relational
> attributes in loadarff
> * `#9551 <https://github.com/scipy/scipy/issues/9551>`__: BUG:
> scipy.optimize.newton says the root of x^2+1 is zero.
> * `#9564 <https://github.com/scipy/scipy/issues/9564>`__: rv_sample accepts
> invalid input in scipy.stats
> * `#9565 <https://github.com/scipy/scipy/issues/9565>`__: improper handling
> of multidimensional input in stats.rv_sample
> * `#9581 <https://github.com/scipy/scipy/issues/9581>`__: Least-squares
> minimization fails silently when x and y data are...
> * `#9587 <https://github.com/scipy/scipy/issues/9587>`__: Outdated value
> for scipy.constants.au
> * `#9611 <https://github.com/scipy/scipy/issues/9611>`__: Overflow error
> with new way of p-value calculation in kendall...
> * `#9645 <https://github.com/scipy/scipy/issues/9645>`__:
> \`scipy.stats.mode\` crashes with variable length arrays (\`dtype=object\`)
> * `#9734 <https://github.com/scipy/scipy/issues/9734>`__:
> PendingDeprecationWarning for np.matrix with pytest
> * `#9786 <https://github.com/scipy/scipy/issues/9786>`__: stats.ks_2samp()
> misleading for small data sets.
> * `#9790 <https://github.com/scipy/scipy/issues/9790>`__: Excessive memory
> usage on detrend
> * `#9801 <https://github.com/scipy/scipy/issues/9801>`__: dual_annealing
> does not set the success attribute in OptimizeResult
> * `#9833 <https://github.com/scipy/scipy/issues/9833>`__:
> IntegrationWarning from mielke.stats() during build of html doc.
> * `#9835 <https://github.com/scipy/scipy/issues/9835>`__:
> scipy.signal.firls seems to be inefficient versus MATLAB firls
> * `#9864 <https://github.com/scipy/scipy/issues/9864>`__: Curve_fit does
> not check for empty input data if called with...
> * `#9869 <https://github.com/scipy/scipy/issues/9869>`__:
> scipy.ndimage.label: Minor documentation issue
> * `#9882 <https://github.com/scipy/scipy/issues/9882>`__: format at the
> wrong paranthesis in scipy.spatial.transform
> * `#9889 <https://github.com/scipy/scipy/issues/9889>`__:
> scipy.signal.find_peaks minor documentation issue
> * `#9890 <https://github.com/scipy/scipy/issues/9890>`__: Minkowski p-norm
> Issues in cKDTree For Values Other Than 2 Or...
> * `#9896 <https://github.com/scipy/scipy/issues/9896>`__:
> scipy.stats._argcheck sets (not just checks) values
> * `#9905 <https://github.com/scipy/scipy/issues/9905>`__: Memory error in
> ndimage.binary_erosion
> * `#9909 <https://github.com/scipy/scipy/issues/9909>`__:
> binary_dilation/erosion/closing crashes when iterations is float
> * `#9919 <https://github.com/scipy/scipy/issues/9919>`__: BUG:
> \`coo_matrix\` does not validate the \`shape\` argument.
> * `#9982 <https://github.com/scipy/scipy/issues/9982>`__: lsq_linear
> hangs/infinite loop with 'trf' method
> * `#10003 <https://github.com/scipy/scipy/issues/10003>`__: exponnorm.pdf
> returns NAN for small K
> * `#10011 <https://github.com/scipy/scipy/issues/10011>`__: Incorrect check
> for invalid rotation plane in scipy.ndimage.rotate
> * `#10024 <https://github.com/scipy/scipy/issues/10024>`__: Fails to build
> from git
> * `#10048 <https://github.com/scipy/scipy/issues/10048>`__: DOC:
> scipy.optimize.root_scalar
> * `#10068 <https://github.com/scipy/scipy/issues/10068>`__: DOC:
> scipy.interpolate.splev
> * `#10074 <https://github.com/scipy/scipy/issues/10074>`__: BUG: \`expm\`
> calculates the wrong coefficients in the backward...
>
>
> Pull requests for 1.3.0
> ------------------------------
>
> * `#7827 <https://github.com/scipy/scipy/pull/7827>`__: ENH: sparse:
> overhaul of sparse matrix indexing
> * `#8431 <https://github.com/scipy/scipy/pull/8431>`__: ENH: Cython
> optimize zeros api
> * `#8743 <https://github.com/scipy/scipy/pull/8743>`__: DOC: Updated
> linalg.pinv, .pinv2, .pinvh docstrings
> * `#8744 <https://github.com/scipy/scipy/pull/8744>`__: DOC: added examples
> to remez docstring
> * `#9227 <https://github.com/scipy/scipy/pull/9227>`__: DOC: update
> description of "direc" parameter of "fmin_powell"
> * `#9263 <https://github.com/scipy/scipy/pull/9263>`__: ENH: optimize:
> added "revised simplex" for scipy.optimize.linprog
> * `#9325 <https://github.com/scipy/scipy/pull/9325>`__: DEP: Remove
> deprecated functions for 1.3.0
> * `#9330 <https://github.com/scipy/scipy/pull/9330>`__: Add note on push
> and pull affine transformations
> * `#9423 <https://github.com/scipy/scipy/pull/9423>`__: DOC: Clearly state
> how 2x2 input arrays are handled in stats.linregress
> * `#9428 <https://github.com/scipy/scipy/pull/9428>`__: ENH: parallelised
> brute
> * `#9438 <https://github.com/scipy/scipy/pull/9438>`__: BUG: Initialize coo
> matrix with size_t indexes
> * `#9455 <https://github.com/scipy/scipy/pull/9455>`__: MAINT: Speed up
> get_(lapack,blas)_func
> * `#9465 <https://github.com/scipy/scipy/pull/9465>`__: MAINT: Clean up
> optimize.zeros C solvers interfaces/code.
> * `#9477 <https://github.com/scipy/scipy/pull/9477>`__: DOC: linalg: fix
> lstsq docstring on residues shape
> * `#9478 <https://github.com/scipy/scipy/pull/9478>`__: DOC: Add docstring
> examples for rosen functions
> * `#9479 <https://github.com/scipy/scipy/pull/9479>`__: DOC: Add docstring
> example for ai_zeros and bi_zeros
> * `#9480 <https://github.com/scipy/scipy/pull/9480>`__: MAINT: linalg:
> lstsq clean up
> * `#9489 <https://github.com/scipy/scipy/pull/9489>`__: DOC: roadmap update
> for changes over the last year.
> * `#9492 <https://github.com/scipy/scipy/pull/9492>`__: MAINT: stats:
> Improve implementation of chi2 ppf method.
> * `#9497 <https://github.com/scipy/scipy/pull/9497>`__: DOC: Improve
> docstrings sparse.linalg.isolve
> * `#9499 <https://github.com/scipy/scipy/pull/9499>`__: DOC: Replace
> "Scipy" with "SciPy" in the .rst doc files for consistency.
> * `#9500 <https://github.com/scipy/scipy/pull/9500>`__: DOC: Document the
> toolchain and its roadmap.
> * `#9505 <https://github.com/scipy/scipy/pull/9505>`__: DOC: specify which
> definition of skewness is used
> * `#9511 <https://github.com/scipy/scipy/pull/9511>`__: DEP: interpolate:
> remove deprecated interpolate_wrapper
> * `#9517 <https://github.com/scipy/scipy/pull/9517>`__: BUG: improve error
> handling in stats.iqr
> * `#9522 <https://github.com/scipy/scipy/pull/9522>`__: ENH: Add Fiedler
> and fiedler companion to special matrices
> * `#9526 <https://github.com/scipy/scipy/pull/9526>`__: TST: relax
> precision requirements in signal.correlate tests
> * `#9529 <https://github.com/scipy/scipy/pull/9529>`__: DOC: fix missing
> random seed in optimize.newton example
> * `#9533 <https://github.com/scipy/scipy/pull/9533>`__: MAINT: Use list
> comprehension when possible
> * `#9537 <https://github.com/scipy/scipy/pull/9537>`__: DOC: add a "big
> picture" roadmap
> * `#9538 <https://github.com/scipy/scipy/pull/9538>`__: DOC: Replace
> "Numpy" with "NumPy" in .py, .rst and .txt doc files...
> * `#9539 <https://github.com/scipy/scipy/pull/9539>`__: ENH: add two-sample
> test (Epps-Singleton) to scipy.stats
> * `#9559 <https://github.com/scipy/scipy/pull/9559>`__: DOC: add section on
> global optimizers to tutorial
> * `#9561 <https://github.com/scipy/scipy/pull/9561>`__: ENH: remove
> noprefix.h, change code appropriately
> * `#9562 <https://github.com/scipy/scipy/pull/9562>`__: MAINT: stats:
> Rewrite pearsonr.
> * `#9563 <https://github.com/scipy/scipy/pull/9563>`__: BUG: Minor bug fix
> Callback in linprog(method='simplex')
> * `#9568 <https://github.com/scipy/scipy/pull/9568>`__: MAINT: raise
> runtime error for newton with zeroder if disp true,...
> * `#9570 <https://github.com/scipy/scipy/pull/9570>`__: Correct docstring
> in show_options in optimize. Fixes #9407
> * `#9573 <https://github.com/scipy/scipy/pull/9573>`__: BUG fixes range of
> pk variable pre-check
> * `#9577 <https://github.com/scipy/scipy/pull/9577>`__: TST: fix minor
> issue in a signal.stft test.
> * `#9580 <https://github.com/scipy/scipy/pull/9580>`__: Included blank line
> before list - Fixes #8658
> * `#9582 <https://github.com/scipy/scipy/pull/9582>`__: MAINT: drop Python
> 2.7 and 3.4
> * `#9588 <https://github.com/scipy/scipy/pull/9588>`__: MAINT: update
> \`constants.astronomical_unit\` to new 2012 value.
> * `#9592 <https://github.com/scipy/scipy/pull/9592>`__: TST: Add 32-bit
> testing to CI
> * `#9593 <https://github.com/scipy/scipy/pull/9593>`__: DOC: Replace
> cumulative density with cumulative distribution
> * `#9596 <https://github.com/scipy/scipy/pull/9596>`__: TST: remove VC 9.0
> from Azure CI
> * `#9599 <https://github.com/scipy/scipy/pull/9599>`__: Hyperlink DOI to
> preferred resolver
> * `#9601 <https://github.com/scipy/scipy/pull/9601>`__: DEV: try to limit
> GC memory use on PyPy
> * `#9603 <https://github.com/scipy/scipy/pull/9603>`__: MAINT: improve
> logcdf and logsf of hypergeometric distribution
> * `#9605 <https://github.com/scipy/scipy/pull/9605>`__: Reference to pylops
> in LinearOperator notes and ARPACK example
> * `#9617 <https://github.com/scipy/scipy/pull/9617>`__: TST: reduce max
> memory usage for sparse.linalg.lgmres test
> * `#9619 <https://github.com/scipy/scipy/pull/9619>`__: FIX: Sparse matrix
> addition/subtraction eliminates explicit zeros
> * `#9621 <https://github.com/scipy/scipy/pull/9621>`__: bugfix in rv_sample
> in scipy.stats
> * `#9622 <https://github.com/scipy/scipy/pull/9622>`__: MAINT: Raise error
> in directed_hausdorff distance
> * `#9623 <https://github.com/scipy/scipy/pull/9623>`__: DOC: Build docs
> with warnings as errors
> * `#9625 <https://github.com/scipy/scipy/pull/9625>`__: Return the number
> of calls to 'hessp' (not just 'hess') in trust...
> * `#9627 <https://github.com/scipy/scipy/pull/9627>`__: BUG: ignore empty
> lines in mmio
> * `#9637 <https://github.com/scipy/scipy/pull/9637>`__: Function to
> calculate the MAD of an array
> * `#9646 <https://github.com/scipy/scipy/pull/9646>`__: BUG: stats: mode
> for objects w/ndim > 1
> * `#9648 <https://github.com/scipy/scipy/pull/9648>`__: Add
> \`stats.contingency\` to refguide-check
> * `#9650 <https://github.com/scipy/scipy/pull/9650>`__: ENH: many lobpcg()
> algorithm improvements
> * `#9652 <https://github.com/scipy/scipy/pull/9652>`__: Move misc.doccer to
> _lib.doccer
> * `#9660 <https://github.com/scipy/scipy/pull/9660>`__: ENH: add pearson,
> tippett, and mudholkar-george to combine_pvalues
> * `#9661 <https://github.com/scipy/scipy/pull/9661>`__: BUG: Fix ksone
> right-hand endpoint, documentation and tests.
> * `#9664 <https://github.com/scipy/scipy/pull/9664>`__: ENH: adding
> multi-target dijsktra performance enhancement
> * `#9670 <https://github.com/scipy/scipy/pull/9670>`__: MAINT: link planck
> and geometric distribution in scipy.stats
> * `#9676 <https://github.com/scipy/scipy/pull/9676>`__: ENH: optimize:
> change default linprog method to interior-point
> * `#9685 <https://github.com/scipy/scipy/pull/9685>`__: Added reference to
> ndimage.filters.median_filter
> * `#9705 <https://github.com/scipy/scipy/pull/9705>`__: Fix coefficients in
> expm helper function
> * `#9711 <https://github.com/scipy/scipy/pull/9711>`__: Release the GIL
> during sosfilt processing for simple types
> * `#9721 <https://github.com/scipy/scipy/pull/9721>`__: ENH: Convexhull
> visiblefacets
> * `#9723 <https://github.com/scipy/scipy/pull/9723>`__: BLD: Modify
> rv_generic._construct_doc to print out failing distribution...
> * `#9726 <https://github.com/scipy/scipy/pull/9726>`__: BUG: Fix small
> issues with \`signal.lfilter'
> * `#9729 <https://github.com/scipy/scipy/pull/9729>`__: BUG: Typecheck
> iterations for binary image operations
> * `#9730 <https://github.com/scipy/scipy/pull/9730>`__: ENH: reduce
> sizeof(NI_WatershedElement) by 20%
> * `#9731 <https://github.com/scipy/scipy/pull/9731>`__: ENH: remove
> suspicious sequence of type castings
> * `#9739 <https://github.com/scipy/scipy/pull/9739>`__: BUG: qr_updates
> fails if u is exactly in span Q
> * `#9749 <https://github.com/scipy/scipy/pull/9749>`__: BUG:
> MapWrapper.__exit__ should terminate
> * `#9753 <https://github.com/scipy/scipy/pull/9753>`__: ENH: Added exact
> computation for Kolmogorov-Smirnov two-sample...
> * `#9755 <https://github.com/scipy/scipy/pull/9755>`__: DOC: Added example
> for signal.impulse, copied from impulse2
> * `#9756 <https://github.com/scipy/scipy/pull/9756>`__: DOC: Added
> docstring example for iirdesign
> * `#9757 <https://github.com/scipy/scipy/pull/9757>`__: DOC: Added examples
> for step functions
> * `#9759 <https://github.com/scipy/scipy/pull/9759>`__: ENH: Allow
> pass_zero to act like btype
> * `#9760 <https://github.com/scipy/scipy/pull/9760>`__: DOC: Added
> docstring for lp2bs
> * `#9761 <https://github.com/scipy/scipy/pull/9761>`__: DOC: Added
> docstring and example for lp2bp
> * `#9764 <https://github.com/scipy/scipy/pull/9764>`__: BUG: Catch internal
> warnings for matrix
> * `#9766 <https://github.com/scipy/scipy/pull/9766>`__: ENH: Speed up
> _gaussian_kernel1d by removing dependence on np.polynomial
> * `#9769 <https://github.com/scipy/scipy/pull/9769>`__: BUG: Fix Cubic
> Spline Read Only issues
> * `#9773 <https://github.com/scipy/scipy/pull/9773>`__: DOC: Several
> docstrings
> * `#9774 <https://github.com/scipy/scipy/pull/9774>`__: TST: bump Azure CI
> OpenBLAS version to match wheels
> * `#9775 <https://github.com/scipy/scipy/pull/9775>`__: DOC: Improve
> clarity of cov_x documentation for scipy.optimize.leastsq
> * `#9779 <https://github.com/scipy/scipy/pull/9779>`__: ENH: dual_annealing
> vectorise visit_fn
> * `#9788 <https://github.com/scipy/scipy/pull/9788>`__: TST, BUG:
> f2py-related issues with NumPy < 1.14.0
> * `#9791 <https://github.com/scipy/scipy/pull/9791>`__: BUG: fix amax
> constraint not enforced in scalar_search_wolfe2
> * `#9792 <https://github.com/scipy/scipy/pull/9792>`__: ENH: Allow inplace
> copying in place in "detrend" function
> * `#9795 <https://github.com/scipy/scipy/pull/9795>`__: DOC: Fix/update
> docstring for dstn and dst
> * `#9796 <https://github.com/scipy/scipy/pull/9796>`__: MAINT: Allow None
> tolerances in least_squares
> * `#9798 <https://github.com/scipy/scipy/pull/9798>`__: BUG: fixes abort
> trap 6 error in scipy issue 9785 in unit tests
> * `#9807 <https://github.com/scipy/scipy/pull/9807>`__: MAINT: improve doc
> and add alternative keyword to wilcoxon in...
> * `#9808 <https://github.com/scipy/scipy/pull/9808>`__: Fix PPoly integrate
> and test for CubicSpline
> * `#9810 <https://github.com/scipy/scipy/pull/9810>`__: ENH: Add the
> geometric standard deviation function
> * `#9811 <https://github.com/scipy/scipy/pull/9811>`__: MAINT: remove
> invalid derphi default None value in scalar_search_wolfe2
> * `#9813 <https://github.com/scipy/scipy/pull/9813>`__: Adapt hamming
> distance in C to support weights
> * `#9817 <https://github.com/scipy/scipy/pull/9817>`__: DOC: Copy solver
> description to solver modules
> * `#9829 <https://github.com/scipy/scipy/pull/9829>`__: ENH: Add FOH and
> equivalent impulse response discretizations...
> * `#9831 <https://github.com/scipy/scipy/pull/9831>`__: ENH: Implement
> RotationSpline
> * `#9834 <https://github.com/scipy/scipy/pull/9834>`__: DOC: Change mielke
> distribution default parameters to ensure...
> * `#9838 <https://github.com/scipy/scipy/pull/9838>`__: ENH: Use faster
> solvers for firls
> * `#9854 <https://github.com/scipy/scipy/pull/9854>`__: ENH: loadarff now
> supports relational attributes.
> * `#9856 <https://github.com/scipy/scipy/pull/9856>`__: integrate.bvp -
> improve handling of nonlinear boundary conditions
> * `#9862 <https://github.com/scipy/scipy/pull/9862>`__: TST: reduce
> Appveyor CI load
> * `#9874 <https://github.com/scipy/scipy/pull/9874>`__: DOC: Update
> requirements in release notes
> * `#9883 <https://github.com/scipy/scipy/pull/9883>`__: BUG: fixed
> parenthesis in spatial.rotation
> * `#9884 <https://github.com/scipy/scipy/pull/9884>`__: ENH: Use Sparsity
> in Clarkson-Woodruff Sketch
> * `#9888 <https://github.com/scipy/scipy/pull/9888>`__: MAINT: Replace
> NumPy aliased functions
> * `#9892 <https://github.com/scipy/scipy/pull/9892>`__: BUG: Fix 9890
> query_ball_point returns wrong result when p is...
> * `#9893 <https://github.com/scipy/scipy/pull/9893>`__: BUG: curve_fit
> doesn't check for empty input if called with bounds
> * `#9894 <https://github.com/scipy/scipy/pull/9894>`__:
> scipy.signal.find_peaks documentation error
> * `#9898 <https://github.com/scipy/scipy/pull/9898>`__: BUG: Set success
> attribute in OptimizeResult. See #9801
> * `#9900 <https://github.com/scipy/scipy/pull/9900>`__: BUG: Restrict
> rv_generic._argcheck() and its overrides from setting...
> * `#9906 <https://github.com/scipy/scipy/pull/9906>`__: fixed a bug in kde
> logpdf
> * `#9911 <https://github.com/scipy/scipy/pull/9911>`__: DOC: replace
> example for "np.select" with the one from numpy...
> * `#9912 <https://github.com/scipy/scipy/pull/9912>`__: BF(DOC): point to
> numpy.select instead of plain (python) .select
> * `#9914 <https://github.com/scipy/scipy/pull/9914>`__: DOC: change
> ValueError message in _validate_pad of signaltools.
> * `#9915 <https://github.com/scipy/scipy/pull/9915>`__: cKDTree
> query_ball_point improvements
> * `#9918 <https://github.com/scipy/scipy/pull/9918>`__: Update ckdtree.pyx
> with boxsize argument in docstring
> * `#9920 <https://github.com/scipy/scipy/pull/9920>`__: BUG: sparse:
> Validate explicit shape if given with dense argument...
> * `#9924 <https://github.com/scipy/scipy/pull/9924>`__: BLD: add back
> pyproject.toml
> * `#9931 <https://github.com/scipy/scipy/pull/9931>`__: Fix empty
> constraint
> * `#9935 <https://github.com/scipy/scipy/pull/9935>`__: DOC: fix references
> for stats.f_oneway
> * `#9936 <https://github.com/scipy/scipy/pull/9936>`__: Revert gh-9619:
> "FIX: Sparse matrix addition/subtraction eliminates...
> * `#9937 <https://github.com/scipy/scipy/pull/9937>`__: MAINT: fix PEP8
> issues and update to pycodestyle 2.5.0
> * `#9939 <https://github.com/scipy/scipy/pull/9939>`__: DOC: correct
> \`structure\` description in \`ndimage.label\` docstring
> * `#9940 <https://github.com/scipy/scipy/pull/9940>`__: MAINT: remove
> extraneous distutils copies
> * `#9945 <https://github.com/scipy/scipy/pull/9945>`__: ENH:
> differential_evolution can use Bounds object
> * `#9949 <https://github.com/scipy/scipy/pull/9949>`__: Added 'std' to add
> doctstrings since it is a \`known_stats\`...
> * `#9953 <https://github.com/scipy/scipy/pull/9953>`__: DOC: Documentation
> cleanup for stats tutorials.
> * `#9962 <https://github.com/scipy/scipy/pull/9962>`__: __repr__ for Bounds
> * `#9971 <https://github.com/scipy/scipy/pull/9971>`__: ENH: Improve
> performance of lsmr
> * `#9987 <https://github.com/scipy/scipy/pull/9987>`__: CI: pin Sphinx
> version to 1.8.5
> * `#9990 <https://github.com/scipy/scipy/pull/9990>`__: ENH: constraint
> violation
> * `#9991 <https://github.com/scipy/scipy/pull/9991>`__: BUG: Avoid inplace
> modification of input array in newton
> * `#9995 <https://github.com/scipy/scipy/pull/9995>`__: MAINT:
> sparse.csgraph: Add cdef to stop build warning.
> * `#9996 <https://github.com/scipy/scipy/pull/9996>`__: BUG: Make
> minimize_quadratic_1d work with infinite bounds correctly
> * `#10004 <https://github.com/scipy/scipy/pull/10004>`__: BUG: Fix unbound
> local error in linprog - simplex.
> * `#10007 <https://github.com/scipy/scipy/pull/10007>`__: BLD: fix Python
> 3.7 build with build isolation
> * `#10009 <https://github.com/scipy/scipy/pull/10009>`__: BUG: Make sure
> that _binary_erosion only accepts an integer number...
> * `#10016 <https://github.com/scipy/scipy/pull/10016>`__: Update link to
> airspeed-velocity
> * `#10017 <https://github.com/scipy/scipy/pull/10017>`__: DOC: Update
> \`interpolate.LSQSphereBivariateSpline\` to include...
> * `#10018 <https://github.com/scipy/scipy/pull/10018>`__: MAINT: special:
> Fix a few warnings that occur when compiling...
> * `#10019 <https://github.com/scipy/scipy/pull/10019>`__: TST: Azure
> summarizes test failures
> * `#10021 <https://github.com/scipy/scipy/pull/10021>`__: ENH: Introduce
> CubicHermiteSpline
> * `#10022 <https://github.com/scipy/scipy/pull/10022>`__: BENCH: Increase
> cython version in asv to fix benchmark builds
> * `#10023 <https://github.com/scipy/scipy/pull/10023>`__: BUG: Avoid
> exponnorm producing nan for small K values.
> * `#10025 <https://github.com/scipy/scipy/pull/10025>`__: BUG: optimize:
> tweaked linprog status 4 error message
> * `#10026 <https://github.com/scipy/scipy/pull/10026>`__: ENH: optimize:
> use SuiteSparse in linprog interior-point when...
> * `#10027 <https://github.com/scipy/scipy/pull/10027>`__: MAINT: cluster:
> clean up the use of malloc() in the function...
> * `#10028 <https://github.com/scipy/scipy/pull/10028>`__: Fix rotate
> invalid plane check
> * `#10040 <https://github.com/scipy/scipy/pull/10040>`__: MAINT: fix pratt
> method of wilcox test in scipy.stats
> * `#10041 <https://github.com/scipy/scipy/pull/10041>`__: MAINT: special:
> Fix a warning generated when building the AMOS...
> * `#10044 <https://github.com/scipy/scipy/pull/10044>`__: DOC: fix up
> spatial.transform.Rotation docstrings
> * `#10047 <https://github.com/scipy/scipy/pull/10047>`__: MAINT:
> interpolate: Fix a few build warnings.
> * `#10051 <https://github.com/scipy/scipy/pull/10051>`__: Add project_urls
> to setup
> * `#10052 <https://github.com/scipy/scipy/pull/10052>`__: don't set flag to
> "converged" if max iter exceeded
> * `#10054 <https://github.com/scipy/scipy/pull/10054>`__: MAINT: signal:
> Fix a few build warnings and modernize some C...
> * `#10056 <https://github.com/scipy/scipy/pull/10056>`__: BUG: Ensure
> factorial is not too large in kendaltau
> * `#10058 <https://github.com/scipy/scipy/pull/10058>`__: Small speedup in
> samping from ortho and special_ortho groups
> * `#10059 <https://github.com/scipy/scipy/pull/10059>`__: BUG: optimize:
> fix #10038 by increasing tol
> * `#10061 <https://github.com/scipy/scipy/pull/10061>`__: BLD: DOC: make
> building docs easier by parsing python version.
> * `#10064 <https://github.com/scipy/scipy/pull/10064>`__: ENH: Significant
> speedup for ortho and special ortho group
> * `#10065 <https://github.com/scipy/scipy/pull/10065>`__: DOC: Reword
> parameter descriptions in \`optimize.root_scalar\`
> * `#10066 <https://github.com/scipy/scipy/pull/10066>`__: BUG: signal: Fix
> error raised by savgol_coeffs when deriv > polyorder.
> * `#10067 <https://github.com/scipy/scipy/pull/10067>`__: MAINT: Fix the
> cutoff value inconsistency for pinv2 and pinvh
> * `#10072 <https://github.com/scipy/scipy/pull/10072>`__: BUG: stats: Fix
> boxcox_llf to avoid loss of precision.
> * `#10075 <https://github.com/scipy/scipy/pull/10075>`__: ENH: Add wrappers
> for ?syconv routines
> * `#10076 <https://github.com/scipy/scipy/pull/10076>`__: BUG: optimize:
> fix curve_fit for mixed float32/float64 input
> * `#10077 <https://github.com/scipy/scipy/pull/10077>`__: DOC: Replace
> undefined \`k\` in \`interpolate.splev\` docstring
> * `#10079 <https://github.com/scipy/scipy/pull/10079>`__: DOC: Fixed typo,
> rearranged some doc of stats.morestats.wilcoxon.
> * `#10080 <https://github.com/scipy/scipy/pull/10080>`__: TST: install
> scikit-sparse for full TravisCI tests
> * `#10083 <https://github.com/scipy/scipy/pull/10083>`__: Clean
> \`\`_clean_inputs\`\` in optimize.linprog
> * `#10088 <https://github.com/scipy/scipy/pull/10088>`__: ENH: optimize:
> linprog test CHOLMOD/UMFPACK solvers when available
> * `#10090 <https://github.com/scipy/scipy/pull/10090>`__: MAINT: Fix
> CubicSplinerInterpolator for pandas
> * `#10091 <https://github.com/scipy/scipy/pull/10091>`__: MAINT: improve
> logcdf and logsf of hypergeometric distribution
> * `#10095 <https://github.com/scipy/scipy/pull/10095>`__: MAINT: Clean
> \`\`_clean_inputs\`\` in linprog
> * `#10116 <https://github.com/scipy/scipy/pull/10116>`__: MAINT: update
> scipy-sphinx-theme
> * `#10135 <https://github.com/scipy/scipy/pull/10135>`__: BUG: fix linprog
> revised simplex docstring problem failure
>
> Checksums
> =========
>
> MD5
> ~~~
>
> 209c50a628a624fc82535299f5913d65
> scipy-1.3.0-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
> 54e6fdb6aacbcaeff6dc86fc736cf39a
> scipy-1.3.0-cp35-cp35m-manylinux1_i686.whl
> 752f9cae504e7ea06cd818fc74b829c0
>  scipy-1.3.0-cp35-cp35m-manylinux1_x86_64.whl
> c7a0ff2b530570feefa8102813fc6dd1  scipy-1.3.0-cp35-cp35m-win32.whl
> 1c53ccff157fe23b165e53fba87c37e0  scipy-1.3.0-cp35-cp35m-win_amd64.whl
> 6762dc85ef6fe357e5710c32451b29a2
> scipy-1.3.0-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
> 03d9c756b5bc836194cd5d13cd73e3fe
> scipy-1.3.0-cp36-cp36m-manylinux1_i686.whl
> 1e5af3fade676e5a588d40d785e7ee4d
>  scipy-1.3.0-cp36-cp36m-manylinux1_x86_64.whl
> fe130e4cb77078c6a886795bcf1fa66d  scipy-1.3.0-cp36-cp36m-win32.whl
> f62f60ea0397b7aa9a90fb610fc54d33  scipy-1.3.0-cp36-cp36m-win_amd64.whl
> a1ec52b1b162bb7ae0d0ea76438e35ce
> scipy-1.3.0-cp37-cp37m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
> 260d182114edaed177c64d60776ceee6
> scipy-1.3.0-cp37-cp37m-manylinux1_i686.whl
> 38c5a038504e03b503f7674b30218068
>  scipy-1.3.0-cp37-cp37m-manylinux1_x86_64.whl
> 2390fdb5a4330c54c2a5308afe959bb9  scipy-1.3.0-cp37-cp37m-win32.whl
> 452157882a9f180914906df9bbf9d7bf  scipy-1.3.0-cp37-cp37m-win_amd64.whl
> c6876673adf7e9e6c0307beaca784ad2  scipy-1.3.0.tar.gz
> e7153c2eb276bc303699b75858db6276  scipy-1.3.0.tar.xz
> 16b9e6a0ea8bdcf2ea72fda5975a252c  scipy-1.3.0.zip
>
> SHA256
> ~~~~~~
>
> 4907040f62b91c2e170359c3d36c000af783f0fa1516a83d6c1517cde0af5340
> scipy-1.3.0-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
> 1db9f964ed9c52dc5bd6127f0dd90ac89791daa690a5665cc01eae185912e1ba
>  scipy-1.3.0-cp35-cp35m-manylinux1_i686.whl
> adadeeae5500de0da2b9e8dd478520d0a9945b577b2198f2462555e68f58e7ef
>  scipy-1.3.0-cp35-cp35m-manylinux1_x86_64.whl
> 03b1e0775edbe6a4c64effb05fff2ce1429b76d29d754aa5ee2d848b60033351
>  scipy-1.3.0-cp35-cp35m-win32.whl
> a7695a378c2ce402405ea37b12c7a338a8755e081869bd6b95858893ceb617ae
>  scipy-1.3.0-cp35-cp35m-win_amd64.whl
> 826b9f5fbb7f908a13aa1efd4b7321e36992f5868d5d8311c7b40cf9b11ca0e7
> scipy-1.3.0-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
> b283a76a83fe463c9587a2c88003f800e08c3929dfbeba833b78260f9c209785
>  scipy-1.3.0-cp36-cp36m-manylinux1_i686.whl
> db61a640ca20f237317d27bc658c1fc54c7581ff7f6502d112922dc285bdabee
>  scipy-1.3.0-cp36-cp36m-manylinux1_x86_64.whl
> 409846be9d6bdcbd78b9e5afe2f64b2da5a923dd7c1cd0615ce589489533fdbb
>  scipy-1.3.0-cp36-cp36m-win32.whl
> c19a7389ab3cd712058a8c3c9ffd8d27a57f3d84b9c91a931f542682bb3d269d
>  scipy-1.3.0-cp36-cp36m-win_amd64.whl
> 09d008237baabf52a5d4f5a6fcf9b3c03408f3f61a69c404472a16861a73917e
> scipy-1.3.0-cp37-cp37m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
> a84c31e8409b420c3ca57fd30c7589378d6fdc8d155d866a7f8e6e80dec6fd06
>  scipy-1.3.0-cp37-cp37m-manylinux1_i686.whl
> c5ea60ece0c0c1c849025bfc541b60a6751b491b6f11dd9ef37ab5b8c9041921
>  scipy-1.3.0-cp37-cp37m-manylinux1_x86_64.whl
> 6c0543f2fdd38dee631fb023c0f31c284a532d205590b393d72009c14847f5b1
>  scipy-1.3.0-cp37-cp37m-win32.whl
> 10325f0ffac2400b1ec09537b7e403419dcd25d9fee602a44e8a32119af9079e
>  scipy-1.3.0-cp37-cp37m-win_amd64.whl
> c3bb4bd2aca82fb498247deeac12265921fe231502a6bc6edea3ee7fe6c40a7a
>  scipy-1.3.0.tar.gz
> ae105c28c1fdb480bf22fd1b1392eeb8679f3c0c8917c87fca8aabf323918455
>  scipy-1.3.0.tar.xz
> b711ec1567439a1abfac59321b73a40de70a93ace4a33be26001eb4b12206356
>  scipy-1.3.0.zip
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJc3vVHAAoJELD/41ZX0J71Dz4P+QFv7E3OIWcrTm6qjt9X4Mgi
> 6heershUpVhZATGj7Kpl+lPEBGthsnkT8MeS0/YW3ZKiDWnQoSWSIxBRnqoXup2D
> CwjeXn4eKw7Z4G2A6MpKcdJe1xV1lY2Wi3MyfmkYnkO0be+NLMStrTS/1+JdM/Xg
> fGt5KqE+QXqB3sEGGf3SXP8tnSS2ULbKNPAxSTL1twS0bEprOVspCtCQJd3Xm1Oi
> g2+vWcIwH80KpphvZLl7F22FOI+birxn19CwNupMaN8IyW0RADUKOvYlWMamUA3K
> iW6KUyHXolyjixAh4RDZUKg0hNUIbDpMBKslqY+Faz92RCCbxCx+TZGT6y+0chrp
> ujE+jRfuXcSk5eykBIzYx3aLPkMH1aQ4ERCi1hxODkTlV22btlSam5diNAOmQeZz
> MhQEmbtx5C9xEEHIrGpsuMHVGZfMm0/QaN23Wn/oRq4e7BsICHfZIoNMjW7/ohSv
> cT0jKFHjzvS3gigT1c8EkzwtFweLp5gYGGUD4IiLOI898pvmns+DcW9coGkwrQ0E
> 0OqTjpIIEPCDpHNrgRqWK8RhvqvkiDTs3HbCaxsMOMkWzlPOnrM37frqUO53SVQH
> SKwe1ic13dKh332CMPcqB5EslBKEx2juexwmqPhG3Wnsy2+dL40yi7TGJYh9Vytn
> ByYnyWurPkhp4WJTN1OD
> =xiYy
> -----END PGP SIGNATURE-----
>

From ralf.gommers at gmail.com  Sat May 18 05:11:08 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sat, 18 May 2019 11:11:08 +0200
Subject: [SciPy-Dev] [Numpy-discussion] ANN: SciPy 1.3.0
In-Reply-To: <CAGzF1ucrT1hvQfgQP2fekv=2GkzAHd_LgkgVacD6iWuhozY7Wg@mail.gmail.com>
References: <CAHPuU_YDgsq_Pt8iAsWL-6qhRyFdAd=BU0SLaHU3U0n-ypvG8g@mail.gmail.com>
 <CAGzF1ucrT1hvQfgQP2fekv=2GkzAHd_LgkgVacD6iWuhozY7Wg@mail.gmail.com>
Message-ID: <CABL7CQhtppHd1yN8AuVyNiSRRWPr8vCjf1tfVWLO_j9QYyW4dA@mail.gmail.com>

On Sat, May 18, 2019 at 6:54 AM Warren Weckesser <warren.weckesser at gmail.com>
wrote:

> On 5/17/19, Tyler Reddy <tyler.je.reddy at gmail.com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> > Hi all,
> >
> > On behalf of the SciPy development team I'm pleased to announce
> > the release of SciPy 1.3.0.
>
>
> A big "thank you" to everyone who contributed to 1.3.0, and especially
> to Tyler for managing the release so well.  Congatulations!
>

A big thank you to in particular Tyler from me as well!

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

From evgeny.burovskiy at gmail.com  Sat May 18 05:19:54 2019
From: evgeny.burovskiy at gmail.com (Evgeni Burovski)
Date: Sat, 18 May 2019 12:19:54 +0300
Subject: [SciPy-Dev] [Numpy-discussion] ANN: SciPy 1.3.0
In-Reply-To: <CABL7CQhtppHd1yN8AuVyNiSRRWPr8vCjf1tfVWLO_j9QYyW4dA@mail.gmail.com>
References: <CAHPuU_YDgsq_Pt8iAsWL-6qhRyFdAd=BU0SLaHU3U0n-ypvG8g@mail.gmail.com>
 <CAGzF1ucrT1hvQfgQP2fekv=2GkzAHd_LgkgVacD6iWuhozY7Wg@mail.gmail.com>
 <CABL7CQhtppHd1yN8AuVyNiSRRWPr8vCjf1tfVWLO_j9QYyW4dA@mail.gmail.com>
Message-ID: <CAMRo0ityaVapnMA_RBuuJYgSajRixfVsHuqurqDOXUUFQduBRg@mail.gmail.com>

Seconded (or thirded?), thank you Tyler!

??, 18 ??? 2019 ?., 12:11 Ralf Gommers <ralf.gommers at gmail.com>:

>
>
> On Sat, May 18, 2019 at 6:54 AM Warren Weckesser <
> warren.weckesser at gmail.com> wrote:
>
>> On 5/17/19, Tyler Reddy <tyler.je.reddy at gmail.com> wrote:
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA256
>> >
>> > Hi all,
>> >
>> > On behalf of the SciPy development team I'm pleased to announce
>> > the release of SciPy 1.3.0.
>>
>>
>> A big "thank you" to everyone who contributed to 1.3.0, and especially
>> to Tyler for managing the release so well.  Congatulations!
>>
>
> A big thank you to in particular Tyler from me as well!
>
> Ralf
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190518/c7561fe6/attachment.html>

From ilhanpolat at gmail.com  Mon May 20 02:39:38 2019
From: ilhanpolat at gmail.com (Ilhan Polat)
Date: Mon, 20 May 2019 08:39:38 +0200
Subject: [SciPy-Dev] [Numpy-discussion] ANN: SciPy 1.3.0
In-Reply-To: <CAMRo0ityaVapnMA_RBuuJYgSajRixfVsHuqurqDOXUUFQduBRg@mail.gmail.com>
References: <CAHPuU_YDgsq_Pt8iAsWL-6qhRyFdAd=BU0SLaHU3U0n-ypvG8g@mail.gmail.com>
 <CAGzF1ucrT1hvQfgQP2fekv=2GkzAHd_LgkgVacD6iWuhozY7Wg@mail.gmail.com>
 <CABL7CQhtppHd1yN8AuVyNiSRRWPr8vCjf1tfVWLO_j9QYyW4dA@mail.gmail.com>
 <CAMRo0ityaVapnMA_RBuuJYgSajRixfVsHuqurqDOXUUFQduBRg@mail.gmail.com>
Message-ID: <CAEBuzr_frrs6DYyaHVncv6uKsE02w8O7VrGivVGsVjP3n9Y26w@mail.gmail.com>

+4 :)

On Sat, May 18, 2019 at 11:21 AM Evgeni Burovski <evgeny.burovskiy at gmail.com>
wrote:

> Seconded (or thirded?), thank you Tyler!
>
> ??, 18 ??? 2019 ?., 12:11 Ralf Gommers <ralf.gommers at gmail.com>:
>
>>
>>
>> On Sat, May 18, 2019 at 6:54 AM Warren Weckesser <
>> warren.weckesser at gmail.com> wrote:
>>
>>> On 5/17/19, Tyler Reddy <tyler.je.reddy at gmail.com> wrote:
>>> > -----BEGIN PGP SIGNED MESSAGE-----
>>> > Hash: SHA256
>>> >
>>> > Hi all,
>>> >
>>> > On behalf of the SciPy development team I'm pleased to announce
>>> > the release of SciPy 1.3.0.
>>>
>>>
>>> A big "thank you" to everyone who contributed to 1.3.0, and especially
>>> to Tyler for managing the release so well.  Congatulations!
>>>
>>
>> A big thank you to in particular Tyler from me as well!
>>
>> Ralf
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190520/f9ac6b9e/attachment.html>

From shivampathak339 at gmail.com  Wed May 22 17:11:16 2019
From: shivampathak339 at gmail.com (shivam pathak)
Date: Thu, 23 May 2019 02:41:16 +0530
Subject: [SciPy-Dev] Idea discussion for GSOD'19
Message-ID: <CA+9Me66eh9au-AzzP0NP9jiLYg9z+V5WfF3V38vPcq+vajdfMw@mail.gmail.com>

Hi sir, I am Shivam Pathak, Computer Science Undergrad at AIT Pune, India.
I am interested in contributing to Scipy's Documentation and has read the
idea page. Where can I start now to get involved?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190523/53fb859e/attachment.html>

From ralf.gommers at gmail.com  Thu May 23 05:44:40 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Thu, 23 May 2019 11:44:40 +0200
Subject: [SciPy-Dev] Idea discussion for GSOD'19
In-Reply-To: <CA+9Me66eh9au-AzzP0NP9jiLYg9z+V5WfF3V38vPcq+vajdfMw@mail.gmail.com>
References: <CA+9Me66eh9au-AzzP0NP9jiLYg9z+V5WfF3V38vPcq+vajdfMw@mail.gmail.com>
Message-ID: <CABL7CQj+u-qFZVbbvZaiiLy7oZMHdQ3DV6mdMwiFecP44jbZOw@mail.gmail.com>

On Wed, May 22, 2019 at 11:13 PM shivam pathak <shivampathak339 at gmail.com>
wrote:

> Hi sir, I am Shivam Pathak, Computer Science Undergrad at AIT Pune,
> India. I am interested in contributing to Scipy's Documentation and has
> read the idea page. Where can I start now to get involved?
>

Hi Shivam,  thank you for your interest in SciPy. Please note that Season
of Docs is a program for professional writers with previous experience to
show for the application. As a student you are unfortunately not eligible -
GSoC is the program for students.

We always value PRs on GitHub outside of any program. You can also find a
contributing guide our GitHub repo.

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

From cwhanse at sandia.gov  Fri May 24 16:29:52 2019
From: cwhanse at sandia.gov (Hansen, Clifford W)
Date: Fri, 24 May 2019 20:29:52 +0000
Subject: [SciPy-Dev] Schumaker quadratic spline
Message-ID: <7aecd299714e4e74a4a74dd1fbfba738@ES04AMSNLNT.srn.sandia.gov>

Jumping in the middle of this discussion: I wrote the original code (Matlab) that Mark is working to merge into our python library pvlib-python. I'd rather see the spline function find a home in scipy if that's appropriate; the functions that use the spline are specific to a photovoltaic model.

The Schumaker spline preserves both local monotonicity and convexity, and so it's different than the shape-preserving cubic spline in Pchip or Akima (it appears those splines preserve monotonicity but not convexity).  The knot selection in Schumaker is different from that typically used for B-splines.  I can look at BSpline and PPoly to see if those functions can be leveraged in Schumaker's algorithm.

Didn't know about the R package, which should be an excellent guide for the python implementation.

Cliff


> On Fri, May 10, 2019 at 12:27 AM Evgeni Burovski <
> evgeny.burovskiy at gmail.com> wrote:
>
>> Hi Mark,
>>
>> The docs you linked reference https://epubs.siam.org/doi/10.1137/0720057
>> which is gated, so only an impression: this seems to construct a
>> shape-preserving piecewise quadratic interpolant. We have two
>> shape-preserving cubic interpolants, PCHIP and Akima. Do you have an
>> overview of how this one compares to them?
>>
>> Off the cuff, I guess we can add a shape-preserving quadratic, too. This
>> should be based on either BSpline or PPoly, depending on the basis the
>> construction is in.
>> (My impression is that it's the latter in the R package).
>> The API should mirror that of Akima1DInterpolator.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190524/6814a565/attachment.html>

From Dieter at Werthmuller.org  Fri May 24 16:14:29 2019
From: Dieter at Werthmuller.org (=?UTF-8?Q?Dieter_Werthm=c3=bcller?=)
Date: Fri, 24 May 2019 22:14:29 +0200
Subject: [SciPy-Dev] scipy.interpolate - other use cases
Message-ID: <5a1663bf-5231-d145-2bc9-e9efcb1a4d0b@Werthmuller.org>

Dear Devs,

I have a particular issue with scipy.interpolate for which I would like 
to know:

- Is there already a better way to do it which I miss?
- Is there interest to add this functionality to SciPy? or
- Is there interest to extend the functionality of the existing fct?
- None of the above or other ideas/comments?

My example deals with scipy.interpolate.RegularGridInterpolator; 
however, it probably is the same for many of the interpolators.

The usage of it in, e.g., 2D is

     func = RegularGridInterpolator((x, y), data)
     func(pts)

where `x` and `y` define the regular grid on which `data` is defined, 
and we interpolate it at `pts`-coordinates. This is ideal if you want to 
interpolate the same data for different points again and again.

However, there are other use cases. Imagine you have a coarse grid, 
defined by `x`, `y`, and a fine grid, defined by the `pts`-coordinates. 
Both grids are regular grids, but not equidistant. Now we want to 
interpolate a changing `data` from the coarse grid to the fine grid. The 
current implementation is not good for that, as you have to create a new 
RegularGridInterpolator-instance for each new data-set, which involves 
the calculation of the indices and weights every time, even though they 
remain the same. So in this case, the implementation should instead look 
like:

     func = RegularGridInterpolator((x, y), pts)
     func(data)

hence, `pts` and `data` interchanged. In this way, the required indices 
and weights can all be calculated during the initiation, which will 
significantly speed-up the interpolation. And `func` can subsequently be 
called relatively cheaply in, for instance, a loop which changes the 
data every time, but not the coordinates.

This behaviour can be obtained by simply moving things between the 
`__init__` and `__call__` functions in `RegularGridInterpolator`, which 
could probably be done as a switch triggered by a new parameter.

Any thoughts?
Dieter





From ralf.gommers at gmail.com  Mon May 27 16:26:08 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Mon, 27 May 2019 22:26:08 +0200
Subject: [SciPy-Dev] scipy.interpolate - other use cases
In-Reply-To: <5a1663bf-5231-d145-2bc9-e9efcb1a4d0b@Werthmuller.org>
References: <5a1663bf-5231-d145-2bc9-e9efcb1a4d0b@Werthmuller.org>
Message-ID: <CABL7CQjSpw9-YuK_cQL=_CaVhy1mdeEKkxh=dVRM7K2iReK=GA@mail.gmail.com>

On Fri, May 24, 2019 at 10:51 PM Dieter Werthm?ller <Dieter at werthmuller.org>
wrote:

> Dear Devs,
>
> I have a particular issue with scipy.interpolate for which I would like
> to know:
>
> - Is there already a better way to do it which I miss?
> - Is there interest to add this functionality to SciPy? or
> - Is there interest to extend the functionality of the existing fct?
> - None of the above or other ideas/comments?
>
> My example deals with scipy.interpolate.RegularGridInterpolator;
> however, it probably is the same for many of the interpolators.
>
> The usage of it in, e.g., 2D is
>
>      func = RegularGridInterpolator((x, y), data)
>      func(pts)
>
> where `x` and `y` define the regular grid on which `data` is defined,
> and we interpolate it at `pts`-coordinates. This is ideal if you want to
> interpolate the same data for different points again and again.
>
> However, there are other use cases. Imagine you have a coarse grid,
> defined by `x`, `y`, and a fine grid, defined by the `pts`-coordinates.
> Both grids are regular grids, but not equidistant. Now we want to
> interpolate a changing `data` from the coarse grid to the fine grid. The
> current implementation is not good for that, as you have to create a new
> RegularGridInterpolator-instance for each new data-set, which involves
> the calculation of the indices and weights every time, even though they
> remain the same. So in this case, the implementation should instead look
> like:
>
>      func = RegularGridInterpolator((x, y), pts)
>      func(data)
>
> hence, `pts` and `data` interchanged. In this way, the required indices
> and weights can all be calculated during the initiation, which will
> significantly speed-up the interpolation. And `func` can subsequently be
> called relatively cheaply in, for instance, a loop which changes the
> data every time, but not the coordinates.
>

Did you profile this? What's the relative time saved here for your use case?


> This behaviour can be obtained by simply moving things between the
> `__init__` and `__call__` functions in `RegularGridInterpolator`, which
> could probably be done as a switch triggered by a new parameter.
>
> Any thoughts?
>

This hasn't come up before AFAIK, so doing this in scipy.interpolate may
not be justified.

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

From Dieter at Werthmuller.org  Tue May 28 01:12:18 2019
From: Dieter at Werthmuller.org (=?UTF-8?Q?Dieter_Werthm=c3=bcller?=)
Date: Tue, 28 May 2019 07:12:18 +0200
Subject: [SciPy-Dev] scipy.interpolate - other use cases
In-Reply-To: <CABL7CQjSpw9-YuK_cQL=_CaVhy1mdeEKkxh=dVRM7K2iReK=GA@mail.gmail.com>
References: <5a1663bf-5231-d145-2bc9-e9efcb1a4d0b@Werthmuller.org>
 <CABL7CQjSpw9-YuK_cQL=_CaVhy1mdeEKkxh=dVRM7K2iReK=GA@mail.gmail.com>
Message-ID: <c52e0a4c-c7ed-73bb-df54-95fbb6fc4eba@Werthmuller.org>

 > Did you profile this? What's the relative time saved here for your 
use case?

I did profile it. The speed-up factor in my tests is between 1.8 and 3, 
depending on problem size. Interestingly, for bigger problem sizes the 
factor is decreasing.

- Factor 3 was for interpolating y-z slices from a 16x16x16 to a 
32x32x32 grid by looping over x. In absolute values: 1.62 ms instead of 
4.91 ms.

- Factor 1.8 was for interpolating y-z slices from a 128x128x128 to a 
256x256x256 grid by looping over x. In absolute values: 1.03 s instead 
of 1.67 s.

I put the notebook here:
https://github.com/prisae/tmp-share/blob/master/Time_RegGridProlongator_vs_scipyRegGridInterpolator.ipynb

 > This hasn't come up before AFAIK, so doing this in scipy.interpolate 
may not be justified.

Fair enough. It thought I'd ask. If it comes up again in the future we 
can still think about it. (I am working with a multigrid solver, so 
jumping a lot between different grid sizes, and these times add up, so 
it was worth exploring it for me.)

Dieter


On 27/05/2019 22:26, Ralf Gommers wrote:
> 
> 
> On Fri, May 24, 2019 at 10:51 PM Dieter Werthm?ller 
> <Dieter at werthmuller.org <mailto:Dieter at werthmuller.org>> wrote:
> 
>     Dear Devs,
> 
>     I have a particular issue with scipy.interpolate for which I would like
>     to know:
> 
>     - Is there already a better way to do it which I miss?
>     - Is there interest to add this functionality to SciPy? or
>     - Is there interest to extend the functionality of the existing fct?
>     - None of the above or other ideas/comments?
> 
>     My example deals with scipy.interpolate.RegularGridInterpolator;
>     however, it probably is the same for many of the interpolators.
> 
>     The usage of it in, e.g., 2D is
> 
>      ? ? ?func = RegularGridInterpolator((x, y), data)
>      ? ? ?func(pts)
> 
>     where `x` and `y` define the regular grid on which `data` is defined,
>     and we interpolate it at `pts`-coordinates. This is ideal if you
>     want to
>     interpolate the same data for different points again and again.
> 
>     However, there are other use cases. Imagine you have a coarse grid,
>     defined by `x`, `y`, and a fine grid, defined by the `pts`-coordinates.
>     Both grids are regular grids, but not equidistant. Now we want to
>     interpolate a changing `data` from the coarse grid to the fine grid.
>     The
>     current implementation is not good for that, as you have to create a
>     new
>     RegularGridInterpolator-instance for each new data-set, which involves
>     the calculation of the indices and weights every time, even though they
>     remain the same. So in this case, the implementation should instead
>     look
>     like:
> 
>      ? ? ?func = RegularGridInterpolator((x, y), pts)
>      ? ? ?func(data)
> 
>     hence, `pts` and `data` interchanged. In this way, the required indices
>     and weights can all be calculated during the initiation, which will
>     significantly speed-up the interpolation. And `func` can
>     subsequently be
>     called relatively cheaply in, for instance, a loop which changes the
>     data every time, but not the coordinates.
> 
> 
> Did you profile this? What's the relative time saved here for your use case?
> 
> 
>     This behaviour can be obtained by simply moving things between the
>     `__init__` and `__call__` functions in `RegularGridInterpolator`, which
>     could probably be done as a switch triggered by a new parameter.
> 
>     Any thoughts?
> 
> 
> This hasn't come up before AFAIK, so doing this in scipy.interpolate may 
> not be justified.
> 
> Cheers,
> Ralf
> 
> 
> 
> 
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
> 

From ssclift at gmail.com  Tue May 28 08:01:03 2019
From: ssclift at gmail.com (Simon S. Clift)
Date: Tue, 28 May 2019 08:01:03 -0400
Subject: [SciPy-Dev] scipy.interpolate - other use cases
In-Reply-To: <c52e0a4c-c7ed-73bb-df54-95fbb6fc4eba@Werthmuller.org>
References: <5a1663bf-5231-d145-2bc9-e9efcb1a4d0b@Werthmuller.org>
 <CABL7CQjSpw9-YuK_cQL=_CaVhy1mdeEKkxh=dVRM7K2iReK=GA@mail.gmail.com>
 <c52e0a4c-c7ed-73bb-df54-95fbb6fc4eba@Werthmuller.org>
Message-ID: <CA+drSsfueDYOixMGxBjaL_-fCFN7WyHyn8yD4-K4hjFMU-BVMA@mail.gmail.com>

Hi Sci-Py Devs,

I actually had this use case during my Ph.D. thesis, and have had variants
on it many times since.  Back then I needed interpolation between two sets
of 2D, regularly structured but skewed, grids.  The data changed but the
grid layout did not.  I also hit this one when computing with
semi-Lagrangian methods where I have a fixed advective term and time step;
not a particularly difficult case but one that chews up a lot of CPU in my
work.

I find saving the interpolant as an [ia,ja,a], (row index, column number,
value) sparse matrix works well, however, that means writing the whole
interpolant myself, since digging out coefficients is often as much work as
coding from scratch.  The matrix representation also means that a parabolic
solution step over the interpolation ends up looking like $L \cdot M^{-1}
\cdot K$ where L and K are interpolation matrices, so I get to use
carefully optimized matrix-vector operations once the interpolant is
computed.  I've done this for both regular and barycentric co-ordinates on
an underlying triangular/tetrahedral grid.  The resulting speed-up over
dynamically computing the interpolation weights is striking (can't tell you
exactly how much, off the top of my head).

This has been on my wish list for a while; I'll see if I can dig out some
code for it.

Best regards
-- Simon


On Tue, May 28, 2019 at 1:12 AM Dieter Werthm?ller <Dieter at werthmuller.org>
wrote:

>  > Did you profile this? What's the relative time saved here for your
> use case?
>
> I did profile it. The speed-up factor in my tests is between 1.8 and 3,
> depending on problem size. Interestingly, for bigger problem sizes the
> factor is decreasing.
>
> - Factor 3 was for interpolating y-z slices from a 16x16x16 to a
> 32x32x32 grid by looping over x. In absolute values: 1.62 ms instead of
> 4.91 ms.
>
> - Factor 1.8 was for interpolating y-z slices from a 128x128x128 to a
> 256x256x256 grid by looping over x. In absolute values: 1.03 s instead
> of 1.67 s.
>
> I put the notebook here:
>
> https://github.com/prisae/tmp-share/blob/master/Time_RegGridProlongator_vs_scipyRegGridInterpolator.ipynb
>
>  > This hasn't come up before AFAIK, so doing this in scipy.interpolate
> may not be justified.
>
> Fair enough. It thought I'd ask. If it comes up again in the future we
> can still think about it. (I am working with a multigrid solver, so
> jumping a lot between different grid sizes, and these times add up, so
> it was worth exploring it for me.)
>
> Dieter
>
>
> On 27/05/2019 22:26, Ralf Gommers wrote:
> >
> >
> > On Fri, May 24, 2019 at 10:51 PM Dieter Werthm?ller
> > <Dieter at werthmuller.org <mailto:Dieter at werthmuller.org>> wrote:
> >
> >     Dear Devs,
> >
> >     I have a particular issue with scipy.interpolate for which I would
> like
> >     to know:
> >
> >     - Is there already a better way to do it which I miss?
> >     - Is there interest to add this functionality to SciPy? or
> >     - Is there interest to extend the functionality of the existing fct?
> >     - None of the above or other ideas/comments?
> >
> >     My example deals with scipy.interpolate.RegularGridInterpolator;
> >     however, it probably is the same for many of the interpolators.
> >
> >     The usage of it in, e.g., 2D is
> >
> >           func = RegularGridInterpolator((x, y), data)
> >           func(pts)
> >
> >     where `x` and `y` define the regular grid on which `data` is defined,
> >     and we interpolate it at `pts`-coordinates. This is ideal if you
> >     want to
> >     interpolate the same data for different points again and again.
> >
> >     However, there are other use cases. Imagine you have a coarse grid,
> >     defined by `x`, `y`, and a fine grid, defined by the
> `pts`-coordinates.
> >     Both grids are regular grids, but not equidistant. Now we want to
> >     interpolate a changing `data` from the coarse grid to the fine grid.
> >     The
> >     current implementation is not good for that, as you have to create a
> >     new
> >     RegularGridInterpolator-instance for each new data-set, which
> involves
> >     the calculation of the indices and weights every time, even though
> they
> >     remain the same. So in this case, the implementation should instead
> >     look
> >     like:
> >
> >           func = RegularGridInterpolator((x, y), pts)
> >           func(data)
> >
> >     hence, `pts` and `data` interchanged. In this way, the required
> indices
> >     and weights can all be calculated during the initiation, which will
> >     significantly speed-up the interpolation. And `func` can
> >     subsequently be
> >     called relatively cheaply in, for instance, a loop which changes the
> >     data every time, but not the coordinates.
> >
> >
> > Did you profile this? What's the relative time saved here for your use
> case?
> >
> >
> >     This behaviour can be obtained by simply moving things between the
> >     `__init__` and `__call__` functions in `RegularGridInterpolator`,
> which
> >     could probably be done as a switch triggered by a new parameter.
> >
> >     Any thoughts?
> >
> >
> > This hasn't come up before AFAIK, so doing this in scipy.interpolate may
> > not be justified.
> >
> > Cheers,
> > Ralf
> >
> >
> >
> >
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at python.org
> > https://mail.python.org/mailman/listinfo/scipy-dev
> >
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>


-- 
1129 Ibbetson Lane
Mississauga, Ontario
L5C 1K9       Canada
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190528/f8173d45/attachment-0001.html>

From charlesr.harris at gmail.com  Tue May 28 15:39:48 2019
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Tue, 28 May 2019 13:39:48 -0600
Subject: [SciPy-Dev] NumPy 1.16.4 released.
Message-ID: <CAB6mnxKw62D4DLO7PAfBUgcKOci4i1YyUwd-5wYvcVSwnVZ5Yg@mail.gmail.com>

Charles R Harris <charlesr.harris at gmail.com>
Apr 21, 2019, 8:39 PM
to numpy-discussion, SciPy, SciPy-User, bcc: python-announce-list
Hi All,

On behalf of the NumPy team I am pleased to announce the release of NumPy
1.16.4 which contains several fixes for newly reported bugs.  The Python
versions supported in this release are 2.7 and 3.5-3.7.

Downstream developers building this release should use Cython >= 0.29.2
and, if using OpenBLAS, OpenBLAS > v0.3.7.  Wheels for this release can be
downloaded from PyPI <https://pypi.org/project/numpy/1.16.4/>, source
archives and release notes are available from Github
<https://github.com/numpy/numpy/releases/tag/v1.16.4>.

If you are installing using pip, you may encounter a problem with older
installed versions of NumPy that pip did not delete becoming mixed with the
current version, resulting in an ``ImportError``. That problem is
particularly
common on Debian derived distributions due to a modified pip.  The fix is
to make sure all previous NumPy versions installed by pip have been
removed. See #12736 <https://github.com/numpy/numpy/issues/12736> for
discussion of the issue.

*Contributors*

A total of 10 people contributed to this release.  People with a "+" by
their
names contributed a patch for the first time.

   - Charles Harris
   - Eric Wieser
   - Dennis Zollo +
   - Hunter Damron +
   - Jingbei Li +
   - Kevin Sheppard
   - Matti Picus
   - Nicola Soranzo +
   - Sebastian Berg
   - Tyler Reddy

*Pull requests merged*

A total of 16 pull requests were merged for this release.

   - gh-13392: BUG: Some PyPy versions lack PyStructSequence_InitType2.
   - gh-13394: MAINT, DEP: Fix deprecated ``assertEquals()``
   - gh-13396: BUG: Fix structured_to_unstructured on single-field types
   (backport)
   - gh-13549: BLD: Make CI pass again with pytest 4.5
   - gh-13552: TST: Register markers in conftest.py.
   - gh-13559: BUG: Removes ValueError for empty kwargs in arraymultiter_new
   - gh-13560: BUG: Add TypeError to accepted exceptions in crackfortran.
   - gh-13561: BUG: Handle subarrays in descr_to_dtype
   - gh-13562: BUG: Protect generators from log(0.0)
   - gh-13563: BUG: Always return views from structured_to_unstructured
   when...
   - gh-13564: BUG: Catch stderr when checking compiler version
   - gh-13565: BUG: longdouble(int) does not work
   - gh-13587: BUG: distutils/system_info.py fix missing subprocess import
   (#13523)
   - gh-13620: BUG,DEP: Fix writeable flag setting for arrays without base
   - gh-13641: MAINT: Prepare for the 1.16.4 release.
   - gh-13644: BUG: special case object arrays when printing rel-, abs-error

Cheers,

Charles Harris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190528/6b3b6d06/attachment.html>

From ralf.gommers at gmail.com  Wed May 29 06:20:26 2019
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Wed, 29 May 2019 12:20:26 +0200
Subject: [SciPy-Dev] Tidelift agreement for SciPy
Message-ID: <CABL7CQi_uc3eorLVFXahJdWLgTSSGXt4i1sONHL58srtmaKFBg@mail.gmail.com>

Hi all,

On behalf of the SciPy Steering Council I'm happy to announce that we (the
SciPy project) now have signed up to the agreement between Tidelift and
NumFOCUS. The summary of the agreement is: Tidelift will pay SciPy a
minimum of $2500/month until Oct 2020, and SciPy will do the following:
- provide a documented way to disclose security vulnerabilities, and
respond to disclosures in a timely manner
- deal with any licensing issues in a timely manner
- write good release notes, and clarify our advice to users on what
releases to use
- some one-time things like getting our metadata into the Tidelift system,
and acknowledging Tidelift as one of our funders on the website

This blog gives a nice overview:
https://blog.tidelift.com/how-to-start-earning-money-for-your-open-source-project-with-tidelift
.

Note that it seems to us that this is a quite modest amount of work that we
will be able to do with volunteer resources. A lot of it we do anyway -
this is a nice feature of Tidelift's business model, in a way they promise
their customers that we will keep doing what we're doing, add some valuable
things like unified dependency reporting around it, and pass on some of the
benefits to the projects (or to individual maintainers for other projects).

We haven't determined what to do with the funds yet, but there's lots of
things that could be done (organize in-person dev meetings, perhaps fund
some work on hairy problems that no one seems to want to solve for free,
etc.) - to be determined in the future.

The Tidelift model was discussed on th numpy-discussion list back in
September (
https://mail.python.org/pipermail/numpy-discussion/2018-September/078736.html)
but at that point there was no "project wide" solution and the "pay some
individuals" model had some issues. Letting all the funding flow into the
SciPy account at NumFOCUS nicely solves this.

Some PRs that address licensing and vulnerability disclosure issues will
follow shortly.

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

From warren.weckesser at gmail.com  Wed May 29 16:50:56 2019
From: warren.weckesser at gmail.com (Warren Weckesser)
Date: Wed, 29 May 2019 16:50:56 -0400
Subject: [SciPy-Dev] Please don't squeeze!
Message-ID: <CAGzF1ue=WKHNP7LwOQejyxLga7pVnneLVQccvST5KRs2vuUx2Q@mail.gmail.com>

Hey fellow SciPy developers,

I was just looking into this question on stackoverflow:

    https://stackoverflow.com/questions/56366443/how-to-let-stats-multivariate-normal-rvs-return-an-array-instead-of-scalar

The question doesn't show a concrete example of the issue, but, as I
say in a comment there, I think I know what the problem is.  The
problem was also reported in an issue on github:

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

Here's an example:

    In [28]: from scipy.stats import multivariate_normal

    In [29]: mean = [0]

    In [30]: cov = [[1]]

    In [31]: multivariate_normal.rvs(mean, cov, size=3)  # Result has
shape (3,)
    Out[31]: array([ 0.98481295, -0.64502293,  2.4408484 ])

    In [32]: multivariate_normal.rvs(mean, cov, size=2)  # Result has
shape (2,)
    Out[32]: array([ 0.48435016, -0.295663  ])

    In [33]: multivariate_normal.rvs(mean, cov, size=1)  # Result is a scalar!
    Out[33]: 1.9722388696940718

    In [34]: type(_)
    Out[34]: numpy.float64

When we use `size=N` and `N > 1`, the result has shape (N,).  But when
we use `size=1`,
the result is a scalar with shape ().  For consistency, the result in
that case should be an array with shape (1,).

The problem is the *indiscriminate squeeze* applied to the result
before returning.  This use of squeeze is almost always the wrong
thing to do (IMHO, IME, etc.).  And in this case, it is inconsistent
with `numpy.random.multvariate_normal`, which, when an explicit `size`
is requested, always returns an array.  If `mean` has shape (D,) and
`cov` has shape (D, D), and size is N,
`numpy.random.multivariate_normal` returns an array with shape (D, N),
even if D or N is 1.  (If `size` is None, the return value has shape
(D,).  This handling of `size=None` is also consistent throughout
`numpy.random`.)  This is how `scipy.stats.multivariate_normal` (along
with the other multivariate distributions) should behave.

I understand the motivation behind the use of `squeeze`.  It seems
that, if the mean and covariance matrix arguments indicate that the
distribution is actually univariate, the caller probably doesn't need
the trivial dimension to be included in the output arrays, so let's do
the user a favor and remove it.  But this creates an issue for the
user that *wants* the output shape to remain consistent with the input
shapes.

I don't recall exactly where, but I know we've had issues with
indiscriminate squeezing in the past.  So if you've written code that
does it, you're not alone, and from a certain perspective it can seem
like the right thing to do.  But in fact, the problems that it causes
far outweigh the few times where the attempt at convenience pays off
(IMHO, IME, etc.).

We already have an issue for this on github, which is where we should
discuss how to fix the multivariate distributions.  I'm sending this
email to the scipy-dev mailing list in an attempt to raise awareness
of this occasionally recurring problem.   `squeeze` is almost never
the right thing to do (IMHO, IME, etc.), so please, don't squeeze!


Warren