From pierre.debuyl at kuleuven.be Fri May 3 10:12:18 2019 From: pierre.debuyl at kuleuven.be (Pierre de Buyl) Date: Fri, 3 May 2019 16:12:18 +0200 Subject: [SciPy-User] EuroSciPy 2019 - extension of deadline Message-ID: <20190503141218.GA25510@pi-x230> Hi all, The call for proposals for EuroSciPy 2019 is extended to 12 may 2019. https://pretalx.com/euroscipy-2019/cfp EuroSciPy 2019 takes place 2-6 September 2019 in Bilbao, Spain. There will be two days of tutorials, two days of conference, and one day of sprints! Find us on the web https://www.euroscipy.org/2019/ and on twitter https://twitter.com/EuroSciPy Regards, The EuroSciPy 2019 team 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-User] Schumaker quadratic spline Message-ID: 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: From mikofski at berkeley.edu Fri May 17 02:01:17 2019 From: mikofski at berkeley.edu (Mark Mikofski) Date: Thu, 16 May 2019 23:01:17 -0700 Subject: [SciPy-User] [ANN] pvlib-python v0.6.3: predicting power for solar energy Message-ID: pvlib-0.6.3 has been released What's New: https://pvlib-python.readthedocs.io/en/stable/whatsnew.html#v0-6-3-may-15-2019 PyPI: https://pypi.org/project/pvlib/ Read the Docs: https://pvlib-python.readthedocs.io/en/latest/ GitHub: https://github.com/pvlib/pvlib-python -- Mark Mikofski, PhD (2005) *Fiat Lux* -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikofski at berkeley.edu Fri May 17 02:36:09 2019 From: mikofski at berkeley.edu (Mark Mikofski) Date: Thu, 16 May 2019 23:36:09 -0700 Subject: [SciPy-User] [ANN] PVMismatch v4.1: Python tools for photovoltaic IV curve modeling Message-ID: PVMismatch-4.1 has been released Release Notes: https://github.com/SunPower/PVMismatch/releases/tag/v4.1 PyPI: https://pypi.org/project/pvmismatch/ Docs: https://sunpower.github.io/PVMismatch/ GitHub: https://github.com/SunPower/PVMismatch -- Mark Mikofski, PhD (2005) *Fiat Lux* -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Sat May 18 10:40:50 2019 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sat, 18 May 2019 16:40:50 +0200 Subject: [SciPy-User] GSoD - Technical Writter In-Reply-To: References:

Message-ID: On Fri, May 17, 2019 at 6:57 PM Dashamir Hoxha wrote: > On Fri, May 17, 2019 at 2:54 PM Ralf Gommers > wrote: > >> Hi Dashamir, >> >> Thank you for your email and interest in NumPy and SciPy. I'm excited >> about this program and opportunity to work with a technical writer. Please >> rest assured that we do not assume or expect you to be familiar with the >> project already. The scipy.stats idea we included in case someone would be >> familiar with it and wanted to work at the individual module level. >> Personally I think the most important and impactful thing though is to >> shape the structure of our documentation content. For that it's not >> necessarily an advantage to know numpy or scipy well - fresh eyes can be >> helpful. And in general, I'd say we have lots of people that can provide >> pieces of content; the ability to create the right framework/structure to >> effectively place and solicit that content is what we habe been missing. >> > >> If you look at the NumPy and SciPy documentation, you will see that the >> reference guides (which are aimed at experienced users) are very large. The >> user guides (for beginning users) and the overall structuring could really >> benefit from a good technical writer. >> > > Thanks for your encouraging message, Ralf. > > Something that I can notice immediately is that the interface of the docs > looks a bit outdated and maybe it can benefit from an update (or replacing > it with another template), in order to make it a bit more responsive. It is > true that when you program you usually work on a big screen, so a > responsive web page may not be an absolute requirement, but still it may be > nice to be able to read the docs from a tablet or smartphone. > Unfortunately I am not familiar yet with Sphinx, but I hope that it can be > integrated with Jekyll or Hugo, and then one of their templates can be used. > You're right, the interface is a little outdated. Docs will have to stay in Sphinx (that's really the only choice for reST docs for a large Python package), however the top level websites (scipy.org, docs.scipy.org) could be moved to Jekyll or Hugo for a more modern look - this will actually be beneficial. > About the content of the User Guide etc. I don't see any obvious > improvement that is needed (maybe because I have not read them yet). One > thing that may help is making the code examples interactive, so that the > readers can play with them and see how the results change. For example this > may be useful: https://github.com/RunestoneInteractive/RunestoneComponents > I'd really like to stay with a static site, so that's unfortunately not the best option. It looks cool, but RunestoneServer requires a server - maintenance cost wise that's a showstopper. > The two changes that I have suggested above seem more like engineering > work (for improving the documentation infrastructure), than documentation > work. For making a content that can be easily grasped by the beginners, I > think that it should be presented as a series of problems and their > solutions. In other words don't show the users the features and their > details, but ask them to solve a simple problem, and then show them how to > solve it with NumPy/SciPy and its features. This would make it more > attractive because people usually don't like to read manuals from beginning > to the end. This is a job that can be done by the teachers for their > students, having in mind the level of their students and what they actually > want them to learn. I have noticed that there are already some lectures, or > books, or tutorials like this. This is a creative work, with a specific > target audience in mind, so I can't pretend that I can possibly do > something useful about this in a short time (2-3 months). But of course the > links to the existing resources can be made more visible and reachable from > the main page of the website. > Yes, there's https://scipy-lectures.org/ for example. Guiding users effectively to all existing resources will be a major step forward. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From gael.varoquaux at normalesup.org Sat May 18 10:51:29 2019 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Sat, 18 May 2019 16:51:29 +0200 Subject: [SciPy-User] GSoD - Technical Writter In-Reply-To: References:

Message-ID: <20190518145129.l66oofvceuccdp6g@phare.normalesup.org> On Sat, May 18, 2019 at 04:40:50PM +0200, Ralf Gommers wrote: > You're right, the interface is a little outdated. Docs will have to stay in > Sphinx (that's really the only choice for reST docs for a large Python > package), however the top level websites (scipy.org, docs.scipy.org) could be > moved to Jekyll or Hugo for a more modern look - this will actually be > beneficial. Sphinx uses standard web tools as outputs (the jinja templating engine, for instance). This problem, to me, is a theming problem: templating + CSS. In scipy-lectures, I had done some work to build a theme that is mobile friendly. More generally, I think that there would be value in maintaining these themes in a way that can be shared across project. Sphinx does have modern themes, such as https://alabaster.readthedocs.io/en/latest/ > Yes, there's https://scipy-lectures.org/ for example. Guiding users effectively > to all existing resources will be a major step forward. Glad to see some synergy here! Cheers, Ga?l From ralf.gommers at gmail.com Sat May 18 11:13:30 2019 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sat, 18 May 2019 17:13:30 +0200 Subject: [SciPy-User] GSoD - Technical Writter In-Reply-To: <20190518145129.l66oofvceuccdp6g@phare.normalesup.org> References:

<20190518145129.l66oofvceuccdp6g@phare.normalesup.org> Message-ID: On Sat, May 18, 2019 at 4:52 PM Gael Varoquaux < gael.varoquaux at normalesup.org> wrote: > On Sat, May 18, 2019 at 04:40:50PM +0200, Ralf Gommers wrote: > > You're right, the interface is a little outdated. Docs will have to stay > in > > Sphinx (that's really the only choice for reST docs for a large Python > > package), however the top level websites (scipy.org, docs.scipy.org) > could be > > moved to Jekyll or Hugo for a more modern look - this will actually be > > beneficial. > > Sphinx uses standard web tools as outputs (the jinja templating engine, > for instance). This problem, to me, is a theming problem: templating + > CSS. In scipy-lectures, I had done some work to build a theme that is > mobile friendly. More generally, I think that there would be value in > maintaining these themes in a way that can be shared across project. > Sphinx does have modern themes, such as > https://alabaster.readthedocs.io/en/latest/ Hey Gael, I think you're mostly right that it's about theming, but not completely. Alabaster isn't really the kind of theme that helps. It's still for docs. For a modern website, Sphinx is just not a great tool. I'd love something like https://jupyter.org/ or https://julialang.org/, and then a Sphinx site under it for user and reference guides. I don't think Sphinx is the right tool for the job of building a modern top-level site. > > > > > Yes, there's https://scipy-lectures.org/ for example. Guiding users > effectively > > to all existing resources will be a major step forward. > > Glad to see some synergy here! > Perhaps there should be even more synergy. Scipy-lectures and http://scipy.github.io/devdocs/tutorial/index.html partly overlap in content and scope, separating them better could help users and get us more good-quality material with less effort. I just don't know what the split should be. Any thoughts? Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From gael.varoquaux at normalesup.org Sat May 18 11:24:07 2019 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Sat, 18 May 2019 17:24:07 +0200 Subject: [SciPy-User] GSoD - Technical Writter In-Reply-To: References:

<20190518145129.l66oofvceuccdp6g@phare.normalesup.org> Message-ID: <20190518152407.gaqfqoaquyvjtqw3@phare.normalesup.org> On Sat, May 18, 2019 at 05:13:30PM +0200, Ralf Gommers wrote: > Hey Gael, I think you're mostly right that it's about theming, but not > completely. Alabaster isn't really the kind of theme that helps. It's still for > docs. For a modern website, Sphinx is just not a great tool. I'd love something > like https://jupyter.org/ or https://julialang.org/, and then a Sphinx site > under it for user and reference guides. Sure, for the few landing pages (or for a blog), Sphinx isn't great. But landing and summary pages can be done in a separate jinja template. By a vast majority, the pages on a site like like of scipy are documentation pages. > I don't think Sphinx is the right tool for the job of building a modern > top-level site. ? It does lack some nice features of a CMS, and the templating is clunky. > > Yes, there's https://scipy-lectures.org/ for example. Guiding > > users effectively to all existing resources will be a major step > > forward. > Glad to see some synergy here! > Perhaps there should be even more synergy. Scipy-lectures and http:// > scipy.github.io/devdocs/tutorial/index.html partly overlap in content and > scope, separating them better could help users and get us more good-quality > material with less effort. I just don't know what the split should be. Any > thoughts? In a sense, there is bound to be some redundancy. Scipy must have a getting started tutorial, because it is easier to maintain, link, and update within scipy. But scipy-lectures brings the benefit of being able to develop jointly multiple chapters that discuss various packages and try to be didactic across chapters (which is does in a quite imperfect way, I must say). So I believe that both are needed. What should be important is to mix the community of developers (aka doc writer), to benefit from the various efforts. That said, I must say that I personally struggle to find time to work on scipy-lectures. When I do, it's because I am teaching a course and badly need an improvement. I have no brilliant idea to solve this. On the positive side, scipy-lectures keeps getting nice improvements from community members. Cheers, Ga?l From chris.barker at noaa.gov Sun May 19 16:35:35 2019 From: chris.barker at noaa.gov (Chris Barker - NOAA Federal) Date: Sun, 19 May 2019 13:35:35 -0700 Subject: [SciPy-User] [Numpy-discussion] GSoD - Technical Writter In-Reply-To: References:

Message-ID: > a responsive web page may not be an absolute requirement, but still it may be nice to be able to read the docs from a tablet or smartphone. Unfortunately I am not familiar yet with Sphinx, but I hope that it can be integrated with Jekyll or Hugo, and then one of their templates can be used. Sphinx is powerful, featurefull, and the standard doc system for Python. Let?s just stick with that. But there are a LOT of themes available for Sphinx? I?m sure there are responsive ones out there that could be used or adapted. http://www.sphinx-doc.org/en/stable/theming.html You might check out the bootstrap theme: https://github.com/ryan-roemer/sphinx-bootstrap-theme -CHB About the content of the User Guide etc. I don't see any obvious improvement that is needed (maybe because I have not read them yet). One thing that may help is making the code examples interactive, so that the readers can play with them and see how the results change. For example this may be useful: https://github.com/RunestoneInteractive/RunestoneComponents The two changes that I have suggested above seem more like engineering work (for improving the documentation infrastructure), than documentation work. For making a content that can be easily grasped by the beginners, I think that it should be presented as a series of problems and their solutions. In other words don't show the users the features and their details, but ask them to solve a simple problem, and then show them how to solve it with NumPy/SciPy and its features. This would make it more attractive because people usually don't like to read manuals from beginning to the end. This is a job that can be done by the teachers for their students, having in mind the level of their students and what they actually want them to learn. I have noticed that there are already some lectures, or books, or tutorials like this. This is a creative work, with a specific target audience in mind, so I can't pretend that I can possibly do something useful about this in a short time (2-3 months). But of course the links to the existing resources can be made more visible and reachable from the main page of the website. Best regards, Dashamir _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion at python.org https://mail.python.org/mailman/listinfo/numpy-discussion -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrissie.c.l at gmail.com Sun May 19 22:12:05 2019 From: chrissie.c.l at gmail.com (Christina Lee) Date: Sun, 19 May 2019 19:12:05 -0700 Subject: [SciPy-User] Main Site Design Questions Message-ID: As both people are realizing scipy.org needs a design overhaul and discussing doing so, I'd like to start a discussion clarifying aspects of SciPy that would drive design choices. These might seem like annoying and weird questions to someone used to a different type of thinking, but this is still problem-solving. The code itself gets more useful if there is a lower barrier to entry. * How should the typical user* feel* about SciPy? What gut-level impression should the website leave? How do you* feel* about SciPy? For example: reliable, dependable, cutting-edge, fast, novel, exciting, ... These will influence aspects like colors, fonts, images, spacings, etc. * What is the most important thing for a user to do? Fairly certain the answer to this question is "Install". * What is the most important thing for someone to learn about SciPy? Assume they know absolutely nothing and you have 10 seconds to catch their interest. * You have more than 10 seconds: Anything really cool about SciPy? Done anything amazing with it? Any cool plots? * Do we have information about both the typical SciPy user, and the typical person visiting the website? If most people have barely touched Python the first time the come across SciPy.org, that changes presentation and wording. Happy Sunday, Christina Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Mon May 20 04:53:38 2019 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Mon, 20 May 2019 10:53:38 +0200 Subject: [SciPy-User] Main Site Design Questions In-Reply-To: References: Message-ID: On Mon, May 20, 2019 at 4:13 AM Christina Lee wrote: > As both people are realizing scipy.org needs a design overhaul and > discussing doing so, I'd like to start a discussion clarifying aspects of > SciPy that would drive design choices. > > These might seem like annoying and weird questions to someone used to a > different type of thinking, but this is still problem-solving. The code > itself gets more useful if there is a lower barrier to entry. > Hi Christina, thanks for the questions - they're not weird and annoying (at least to me), I can see how answering them well can lead to a better design and information layout. You already triggered me to think about changing the scope of the site (last question). > * How should the typical user* feel* about SciPy? What gut-level > impression should the website leave? How do you* feel* about SciPy? > For example: reliable, dependable, cutting-edge, fast, novel, > exciting, ... These will influence aspects like colors, fonts, images, > spacings, etc. > Reliably, dependable, fast: yes. Exciting: for parts of SciPy yes, I hope. Cutting-edge, novel: no. When new features are proposed for inclusion in SciPy, one of the things we look at is whether the feature will be widely applicable (>1 science domain) and that it's "proven" to some extent (by use, citations, etc.). If it's cutting-edge research, we encourage creating a new package for it or finding some other more suitable package. > > * What is the most important thing for a user to do? > Fairly certain the answer to this question is "Install". > Install, although that's a one-time (or few-times) action. Then use. Unlike NumPy, there's not a couple of key concepts to grasp. What would be good is for the user to understand what is in SciPy and how the package is laid out. > * What is the most important thing for someone to learn about SciPy? > Assume they know absolutely nothing and you have 10 seconds to catch > their interest. > That's always hard:) I'd say that it's a "standard library" of high-quality fundamental numerical algorithms - whether they need statistics, linear algebra, special functions or optimizers, SciPy is the first thing they should look at. > * You have more than 10 seconds: Anything really cool about SciPy? Done > anything amazing with it? Any cool plots? > The recent black hole image and the discovery of gravitational waves would be high on my list. Would be cool to get some high-impact examples from a broader range of fields, like biology, economics, engineering, etc. > > * Do we have information about both the typical SciPy user, and the > typical person visiting the website? If most people have barely touched > Python the first time the come across SciPy.org, that changes presentation > and wording. > I think slightly more advanced than "barely touched Python". NumPy, Jupyter and Matplotlib are probably things beginners would look at before SciPy. There's indeed still mostly scientists and engineers, and students in those fields. People who do not consider themselves programmers, and are just needing to get their task or experiment done. Regarding the website, there's of course the complication that scipy.org is about the "SciPy ecosystem" and scipy.org/scipylib about "SciPy the library". And then there's SciPy the conference as well. I actually think that today it would be an improvement to make the focus narrower. Disambiguate the name, point people to other places for the conference and ecosystem, and then focus on the library. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From jni.soma at gmail.com Mon May 20 05:21:24 2019 From: jni.soma at gmail.com (Juan Nunez-Iglesias) Date: Mon, 20 May 2019 19:21:24 +1000 Subject: [SciPy-User] Main Site Design Questions In-Reply-To: References: Message-ID: <53213fe6-6997-4803-98b0-50f607bd485c@www.fastmail.com> On Mon, 20 May 2019, at 6:55 PM, Ralf Gommers wrote: > Regarding the website, there's of course the complication that scipy.org is about the "SciPy ecosystem" and scipy.org/scipylib about "SciPy the library". And then there's SciPy the conference as well. > > I actually think that today it would be an improvement to make the focus narrower. Disambiguate the name, point people to other places for the conference and ecosystem, and then focus on the library. On this I agree strongly: scipy.org should be about the scipy library, scipy.org/community (or similar) about the broader ecosystem. That matches the rest of the ecosystem (dask.org, scikit-image.org, numpy.org, matplotlib.org...). Anything else is confusing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Mon May 20 06:00:45 2019 From: takowl at gmail.com (Thomas Kluyver) Date: Mon, 20 May 2019 11:00:45 +0100 Subject: [SciPy-User] Main Site Design Questions In-Reply-To: <53213fe6-6997-4803-98b0-50f607bd485c@www.fastmail.com> References: <53213fe6-6997-4803-98b0-50f607bd485c@www.fastmail.com> Message-ID: On Mon, 20 May 2019 at 10:21, Juan Nunez-Iglesias wrote: > On this I agree strongly: scipy.org should be about the scipy library, > scipy.org/community (or similar) about the broader ecosystem. That > matches the rest of the ecosystem (dask.org, scikit-image.org, numpy.org, > matplotlib.org...). Anything else is confusing. > The confusion comes because the name SciPy is used for a much broader meaning, including conferences with SciPy in the name. None of the other names have this kind of broad use. I think the landing page probably needs to accommodate that somehow. The current homepage is like it is because we pushed a few years ago to present a more unified front to the scientific Python world. This was before Anaconda took off, and Enthought's free offering at the time didn't even include pandas, so pushing the notion of a 'Scipy stack' of key packages seemed more important than it does today. My impression is that usage of 'SciPy' to refer to the ecosystem is on the decline as 'data' is more trendy. But I think you'll still have to deal with a significant fraction of people looking for 'SciPy' who are interested in the conferences or the ecosystem, not necessarily in the SciPy package itself. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guillaume at damcb.com Mon May 20 06:05:57 2019 From: guillaume at damcb.com (Guillaume Gay) Date: Mon, 20 May 2019 12:05:57 +0200 Subject: [SciPy-User] Main Site Design Questions In-Reply-To: References: Message-ID: <3101ed2f-b739-05f1-2168-2bbe76e549e4@damcb.com> Hi, I'll give it a shot, Le 20/05/2019 ? 04:12, Christina Lee a ?crit?: > As both people are realizing?scipy.org needs a > design overhaul and discussing doing so, I'd like to start a > discussion clarifying aspects of SciPy that would drive design choices.? > > These might seem like annoying and weird questions to someone used to > a different type of thinking, but this is still problem-solving. The > code itself gets more useful if there is a lower barrier to entry. > > * How should the typical user/feel/ about SciPy?? What gut-level > impression should the website leave?? How do you/feel/ about SciPy? > ? ? ? ?? For example: reliable, dependable, cutting-edge, fast, novel, > exciting, ... These will influence aspects like colors, fonts, images, > spacings, etc.? > reliable and dependable yes, I'll add rich or complete, a sense that what I would classically need for scientific computing will be provided here. Scipy is the _reference_ library. As pointing by Ralf, cutting edge no. Exciting yes, as in "Sam entering the Citadel library" exciting. > * What is the most important thing for a user to do? > ? ? ?? Fairly certain the answer to this question is "Install". > Find documentation (at least for me). Installing can go through other channels nowadays (anaconda in particular). I go through scipy.org to land on the docs 99 % of the time. > * What is the most important thing for someone to learn about SciPy? > ? ? ? Assume they know absolutely nothing and you have 10 seconds to > catch their interest. You can do all the maths, in a coherent, integrated (& interoperable) framework > ? > > * You have more than 10 seconds: Anything really cool about SciPy?? > Done anything amazing with it? Any cool plots? As Ralf said, really cool physics. I saw a post about matplotlib being used in 13 % of papers on ArXiv, scipy must be used in a good fraction of those. > > * Do we have information about both the typical SciPy user, and the > typical person visiting the website? If most people have barely > touched Python the first time the come across SciPy.org, that changes > presentation and wording. I think academy and applied research, so technical but not necessarily trained programmers. > > Happy Sunday, > Christina Lee > > _______________________________________________ > SciPy-User mailing list > SciPy-User at python.org > https://mail.python.org/mailman/listinfo/scipy-user -- Guillaume Gay, PhD Morphog?nie Logiciels SAS http://morphogenie.fr 12 rue Camoin Jeune 13004 Marseille +336 51 95 94 00 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dashohoxha at gmail.com Tue May 21 17:55:19 2019 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Tue, 21 May 2019 23:55:19 +0200 Subject: [SciPy-User] [Numpy-discussion] GSoD - Technical Writter In-Reply-To: References:

Message-ID: On Sun, May 19, 2019 at 10:36 PM Chris Barker - NOAA Federal < chris.barker at noaa.gov> wrote: > > > a responsive web page may not be an absolute requirement, but still it > may be nice to be able to read the docs from a tablet or smartphone. > > Sphinx is powerful, featurefull, and the standard doc system for Python. > Let?s just stick with that. > > But there are a LOT of themes available for Sphinx? I?m sure there are > responsive ones out there that could be used or adapted. > > http://www.sphinx-doc.org/en/stable/theming.html > > You might check out the bootstrap theme: > > https://github.com/ryan-roemer/sphinx-bootstrap-theme > You are right, there are a lot of sphinx themes available: https://sphinx-themes.org/ and some of them are responsive. If such a theme takes care of everything this is great. But it may also be possible to use a jekyll theme for the homepage, and sphinx for the docs pages. Regards, Dashamir P.s. I had a small confusion. I was subscribed to scipy-dev, but I posted by mistake to scipy-user, so I didn't read the replies there. Now I am subscribed to scipy-user as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Wed May 22 02:28:05 2019 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 22 May 2019 08:28:05 +0200 Subject: [SciPy-User] [Numpy-discussion] GSoD - Technical Writter In-Reply-To: References:

Message-ID: On Tue, May 21, 2019 at 11:56 PM Dashamir Hoxha wrote: > On Sun, May 19, 2019 at 10:36 PM Chris Barker - NOAA Federal < > chris.barker at noaa.gov> wrote: > >> >> > a responsive web page may not be an absolute requirement, but still it >> may be nice to be able to read the docs from a tablet or smartphone. >> >> Sphinx is powerful, featurefull, and the standard doc system for Python. >> Let?s just stick with that. >> >> But there are a LOT of themes available for Sphinx? I?m sure there are >> responsive ones out there that could be used or adapted. >> >> http://www.sphinx-doc.org/en/stable/theming.html >> >> You might check out the bootstrap theme: >> >> https://github.com/ryan-roemer/sphinx-bootstrap-theme >> > > You are right, there are a lot of sphinx themes available: > https://sphinx-themes.org/ and some of them are responsive. If such a > theme takes care of everything this is great. But it may also be possible > to use a jekyll theme for the homepage, and sphinx for the docs pages. > > Regards, > Dashamir > > P.s. I had a small confusion. I was subscribed to scipy-dev, but I posted > by mistake to scipy-user, so I didn't read the replies there. Now I am > subscribed to scipy-user as well. > No worries. We can continue here with this conversation (if needed), but for new threads scipy-dev is the right place. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikofski at berkeley.edu Thu May 23 03:19:49 2019 From: mikofski at berkeley.edu (Mark Mikofski) Date: Thu, 23 May 2019 00:19:49 -0700 Subject: [SciPy-User] [ANN] SolarUtils-0.3 released - wrappers for NREL SOLPOS and SPECTRL2 algorithms Message-ID: This update adds two convenience functions: 1. get_solposAM(location, datetimes, weather) - returns solar positions and airmass for arbitrary sequence of datetime vectors [year, month, day, hour, minute second]. 2. get_solpos8760(location, year, weather) - returns 8760 annyual hourly solar position and airmass for given year. For example: >>> location = [35.56836, -119.2022, -8.0]>>> datetimes = [... (datetime.datetime(2013, 1, 1, 0, 0, 0)... + datetime.timedelta(hours=h)).timetuple()[:6]... for h in range(1000)]>>> weather = [1015.62055, 40.0]>>> angles, airmass = get_solposAM(location, datetimes, weather) For more info, please see: - docs: https://sunpower.github.io/SolarUtils/ - repo: https://github.com/SunPower/SolarUtils - pypi: https://pypi.org/project/SolarUtils/ Thanks! -- Mark Mikofski, PhD (2005) *Fiat Lux* -------------- next part -------------- An HTML attachment was scrubbed... URL: 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-User] NumPy 1.16.4 released. Message-ID: Charles R Harris 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 , source archives and release notes are available from Github . 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 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: From sepand.haghighi at yahoo.com Fri May 31 04:19:51 2019 From: sepand.haghighi at yahoo.com (Sepand Haghighi) Date: Fri, 31 May 2019 08:19:51 +0000 (UTC) Subject: [SciPy-User] PyCM 2.2 released : A general benchmark based comparison of classification models References: <2060093326.1687382.1559290791660.ref@mail.yahoo.com> Message-ID: <2060093326.1687382.1559290791660@mail.yahoo.com> Hi folks Recently we have released new version of PyCM,?library for confusion matrix statistical analysis. I thought you might find it interesting. http://www.pycm.ir https://github.com/sepandhaghighi/pycm Changelog : - Negative likelihood ratio interpretation (NLRI) added - Cramer's benchmark (SOA5) added - Matthews correlation coefficient interpretation (MCCI) added?#204 - Matthews's benchmark (SOA6) added?#204 - F1 macro added - F1 micro added - Accuracy macro added?#205 - Compare class score calculation modified - Parameters recommendation for multi-class dataset modified - Parameters recommendation for imbalance dataset modified - README.md?modified - Document modified - Logo updated Best RegardsSepand Haghighi -------------- next part -------------- An HTML attachment was scrubbed... URL: