[Numpy-discussion] Re: Please consider dropping Python 3.9 support for Numpy 2.0
On Tue, May 07, 2024 at 11:31:02AM +0200, Ralf Gommers wrote: > make `pip install scikit-image==0.22` work if that version of scikit-image > depends on an unconstrained numpy version. Would an option be for the scikit-image maintainers to release a version of scikit-image 0.22 (like 0.22.1) with a constraint numpy version? Gaël ___ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
[Numpy-discussion] Re: Please consider dropping Python 3.9 support for Numpy 2.0
On Fri, May 10, 2024 at 04:42:49PM +0200, Ralf Gommers wrote: > It gets ever-easier to install new Python versions, with pyenv/conda/etc. The > "my single Python install comes from python.org and I'm using the same one > because I am afraid to upgrade" is much less of an issue than it was 10 years > ago. And it's caused mostly by users having knowledge gaps. So yes it can be > a pain for them, but they'll have to learn at some point anyway. Same for "my > old HPC cluster uses ..." - it's often an even older Python anyway, and > you'll have tons of reasons why you don't want your cluster-installed stack - > learn to use Spack or Conda, and you'll be much happier in the long run. IMHO the view that its a tooling/knowledge gap problem is a bit disconnected of users. I meet many users who either 1. cannot control the Python version they run, or even the base environment, because of company culture (decisions at company level on these constraints). Maybe upper management in completely misguided here, but then upper management must be targeted, and it is not clear at all that constraints on packages is the right way to do it, as they typically never run any code. 2. have environments with many dependencies that get in gridlocks of dependencies that cannot be mutually satisfied. For my own work it becomes increasingly frequent for me to spawn multiple environments that then talk to each others (eg via files) to work around these problems. Problem 1 is probably something that user organizations should change, and we need to understand why they lock Python versions. It could be a QA issue, and this might reveal both a lack of good practices for QA (ie testing) but also the instability of the ecosystems that creates a fear of upgrade. We should not be too fast in dismissing these organizations as strife with bad practices that could easily be changed, as even tech-savy organizations (such as Google, I believe) run into these problems. Problem 2 is not a problem solvable by users: it comes from the fact that dependency version windows are too narrow. Without broad windows on dependencies, the more dependencies one has, the more one gets into an impossible situation. For this last reason, I strongly advocate that packages, in particular core packages, try hard to be as permissible as reasonably possible on dependencies. Cheers, Gaël ___ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
Re: [Numpy-discussion] Taking NumPy in Stride workshop at PyData Barcelona
+1 In my experience, there is a lack of deep understanding of numpy works, and people are happy to learn. Gaël On Thu, Jun 15, 2017 at 09:38:08AM +0200, Jaime Fernández del Río wrote: > I ended up going to the PyData event in Barcelona last month and running a > workshop there. The notebook I used can be found here: > https://github.com/jaimefrio/pydatabcn2017/tree/master/taking_numpy_in_stride > I was afraid that the content would be too technical, but all the feedback I > got from attendees was that they very much enjoyed it and want more of this > deep technical dives into the belly of the beast. > Of course IRL, contrary to the internet, it is easier to approach someone to > tell them you like what they presented, than to tell them they suck. So maybe > this is just a biased illusion, but until proven wrong I am encouraging anyone > with the knowledge and the opportunity to go ahead and organize a similar > workshop in any conference they go to. > Jaime > P.S. I also got a chance to catch up with Francesc Alted and Travis Oliphant, > which is always great! -- Gael Varoquaux Researcher, INRIA Parietal NeuroSpin/CEA Saclay , Bat 145, 91191 Gif-sur-Yvette France Phone: ++ 33-1-69-08-79-68 http://gael-varoquaux.infohttp://twitter.com/GaelVaroquaux ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] proposed changes to array printing in 1.14
Indeed, for scikit-learn, this would be a major problem.
Gaël
On Fri, Jun 30, 2017 at 05:55:52PM +1000, Juan Nunez-Iglesias wrote:
> To reiterate my point on a previous thread, I don't think this should happen
> until NumPy 2.0. This *will* break a massive number of doctests, and what's
> worse, it will do so in a way that makes it difficult to support doctesting
> for
> both 1.13 and 1.14. I don't see a big enough benefit to these changes to
> justify breaking everyone's tests before an API-breaking version bump.
> On 30 Jun 2017, 6:42 AM +1000, Marten van Kerkwijk
> ,
> wrote:
> To add to Allan's message: point (2), the printing of 0-d arrays, is
> the one that is the most important in the sense that it rectifies a
> really strange situation, where the printing cannot be logically
> controlled by the same mechanism that controls >=1-d arrays (see PR).
> While point 3 can also be considered a bug fix, 1 & 4 are at some
> level matters of taste; my own reason for supporting their
> implementation now is that the 0-d arrays already forces me (or,
> specifically, astropy) to rewrite quite a few doctests, and I'd rather
> have everything in one go -- in this respect, it is a pity that this
> is separate from the earlier change in printing for structured arrays
> (which was also much for the better, but broke a lot of doctests).
> -- Marten
> On Thu, Jun 29, 2017 at 3:38 PM, Allan Haldane
> wrote:
> Hello all,
> There are various updates to array printing in preparation for numpy
> 1.14. See https://github.com/numpy/numpy/pull/9139/
> Some are quite likely to break other projects' doc-tests which expect
> a
> particular str or repr of arrays, so I'd like to warn the list in case
> anyone has opinions.
> The current proposed changes, from most to least painful by my
> reckoning, are:
> 1.
> For float arrays, an extra space previously used for the sign position
> will now be omitted in many cases. Eg, `repr(arange(4.))` will now
> return 'array([0., 1., 2., 3.])' instead of 'array([ 0., 1., 2.,
> 3.])'.
> 2.
> The printing of 0d arrays is overhauled. This is a bit finicky to
> describe, please see the release note in the PR. As an example of the
> effect of this, the `repr(np.array(0.))` now prints as 'array(0.)`
> instead of 'array(0.0)'. Also the repr of 0d datetime arrays is now
> like
> "array('2005-04-04', dtype='datetime64[D]')" instead of
> "array(datetime.date(2005, 4, 4), dtype='datetime64[D]')".
> 3.
> User-defined dtypes which did not properly implement their `repr` (and
> `str`) should do so now. Otherwise it now falls back to
> `object.__repr__`, which will return something ugly like
> ``. (Previously you could depend on
> only implementing the `item` method and the repr of that would be
> printed. But no longer, because this risks infinite recursions.).
> 4.
> Bool arrays of size 1 with a 'True' value will now omit a space, so
> that
> `repr(array([True]))` is now 'array([True])' instead of
> 'array([ True])'.
> Allan
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
> _______
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
--
Gael Varoquaux
Researcher, INRIA Parietal
NeuroSpin/CEA Saclay , Bat 145, 91191 Gif-sur-Yvette France
Phone: ++ 33-1-69-08-79-68
http://gael-varoquaux.infohttp://twitter.com/GaelVaroquaux
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] proposed changes to array printing in 1.14
One problem is that it becomes hard (impossible?) for downstream packages
such as scikit-learn to doctest under multiple versions of the numpy.
Past experience has shown that it could be useful.
Gaël
On Fri, Jun 30, 2017 at 06:30:53PM -0400, Allan Haldane wrote:
> On 06/30/2017 09:17 AM, Gael Varoquaux wrote:
> > Indeed, for scikit-learn, this would be a major problem.
> > Gaël
> I just ran the scikit-learn tests.
> With the new behavior (removed whitespace), I do get 70 total failures:
> $ make test-doc
> Ran 39 tests in 39.503s
> FAILED (SKIP=3, failures=19)
> $ make test
> Ran 8122 tests in 387.650s
> FAILED (SKIP=58, failures=51)
> After setting `np.set_printoptions(pad_sign=True)` (see other email) I
> get only 1 failure in total, which is due to the presence of a 0d array
> in gaussian_process.rst.
> So it looks like the pad_sign option as currently implemented is good
> enough to avoid almost all doctest errors.
> Allan
> > On Fri, Jun 30, 2017 at 05:55:52PM +1000, Juan Nunez-Iglesias wrote:
> >> To reiterate my point on a previous thread, I don't think this should
> >> happen
> >> until NumPy 2.0. This *will* break a massive number of doctests, and what's
> >> worse, it will do so in a way that makes it difficult to support
> >> doctesting for
> >> both 1.13 and 1.14. I don't see a big enough benefit to these changes to
> >> justify breaking everyone's tests before an API-breaking version bump.
> >> On 30 Jun 2017, 6:42 AM +1000, Marten van Kerkwijk
> >> ,
> >> wrote:
> >> To add to Allan's message: point (2), the printing of 0-d arrays, is
> >> the one that is the most important in the sense that it rectifies a
> >> really strange situation, where the printing cannot be logically
> >> controlled by the same mechanism that controls >=1-d arrays (see PR).
> >> While point 3 can also be considered a bug fix, 1 & 4 are at some
> >> level matters of taste; my own reason for supporting their
> >> implementation now is that the 0-d arrays already forces me (or,
> >> specifically, astropy) to rewrite quite a few doctests, and I'd rather
> >> have everything in one go -- in this respect, it is a pity that this
> >> is separate from the earlier change in printing for structured arrays
> >> (which was also much for the better, but broke a lot of doctests).
> >> -- Marten
> >> On Thu, Jun 29, 2017 at 3:38 PM, Allan Haldane
> >> wrote:
> >> Hello all,
> >> There are various updates to array printing in preparation for
> >> numpy
> >> 1.14. See https://github.com/numpy/numpy/pull/9139/
> >> Some are quite likely to break other projects' doc-tests which
> >> expect a
> >> particular str or repr of arrays, so I'd like to warn the list in
> >> case
> >> anyone has opinions.
> >> The current proposed changes, from most to least painful by my
> >> reckoning, are:
> >> 1.
> >> For float arrays, an extra space previously used for the sign
> >> position
> >> will now be omitted in many cases. Eg, `repr(arange(4.))` will now
> >> return 'array([0., 1., 2., 3.])' instead of 'array([ 0., 1., 2.,
> >> 3.])'.
> >> 2.
> >> The printing of 0d arrays is overhauled. This is a bit finicky to
> >> describe, please see the release note in the PR. As an example of
> >> the
> >> effect of this, the `repr(np.array(0.))` now prints as 'array(0.)`
> >> instead of 'array(0.0)'. Also the repr of 0d datetime arrays is now
> >> like
> >> "array('2005-04-04', dtype='datetime64[D]')" instead of
> >> "array(datetime.date(2005, 4, 4), dtype='datetime64[D]')".
> >> 3.
> >> User-defined dtypes which did not properly implement their `repr`
> >> (and
> >> `str`) should do so now. Otherwise it now falls back to
> >> `object.__repr__`, which will return something ugly like
> >> ``. (Previously you could depend
> >> on
> >> only implementing the `item` method and the repr of that would be
> >> printed. But no longer, because this risks infinite recursions.).
> >> 4.
> >> B
Re: [Numpy-discussion] Vector stacks
My thoughts exactly. Gaël On Sun, Jul 02, 2017 at 10:31:33AM +1000, Juan Nunez-Iglesias wrote: > I’m with Nathaniel on this one. Subclasses make code harder to read and reason > about because you now have to be sure of the exact type of things that users > are passing you — which are array-like but subtly different. > On 2 Jul 2017, 9:46 AM +1000, Marten van Kerkwijk , > wrote: > I'm not sure there is *that* much against a class that basically just > passes through views of itself inside `__matmul__` and `__rmatmul__` > or calls new gufuncs, but I think the lower hurdle is to first get > those gufuncs implemented. > -- Marten > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion -- Gael Varoquaux Researcher, INRIA Parietal NeuroSpin/CEA Saclay , Bat 145, 91191 Gif-sur-Yvette France Phone: ++ 33-1-69-08-79-68 http://gael-varoquaux.infohttp://twitter.com/GaelVaroquaux ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] np.vstack vs. np.stack
Another point in defence of vstack vs stack/concatenate: last time I looked, it was faster on smallish arrays. Gaël ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal of timeline for dropping Python 2.7 support
On Mon, Nov 13, 2017 at 10:26:31AM -0800, Matthias Bussonnier wrote: > This behavior is "new" (Nov/Dec 2016). [snip] > It _does_ require to have a version of pip which is not decades old Just to check that I am not misunderstanding: the version of pip should not be more than a year old; "decades old" is just French hyperbola? Do I understand right? Gaël ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Deprecate matrices in 1.15 and remove in 1.17?
> - There are major projects like scikit-learn that simply have no > alternative to using np.matrix, because of scipy.sparse. Well, we have no love for np.matrix, we just use scipy.sparse and np.ndarray. > - After there's an alternative to scipy.sparse: +1 for alternative to scipy.sparse before transition. Gaël ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Direct GPU support on NumPy
> The other packages are nice but I would really love to just use scipy/ > sklearn and have decompositions, factorizations, etc for big matrices > go a little faster without recoding the algorithms. Thanks If you have very big matrices, scikit-learn's PCA already uses randomized linear algebra, which buys you more than GPUs. Gaël ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] A roadmap for NumPy - longer term planning
While we are in the crazy wish-list: having dtypes that are universal enough for pandas to use them and export their columns with them would be my crazy wish. I hope that it would help adding more uniform support for things like categorical variables in the pydata ecosystem. Gaël ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] PEP 574 - zero-copy pickling with out of band data
On Mon, Jul 02, 2018 at 05:31:05PM -0600, Charles R Harris wrote: > ISTR that some parallel processing applications sent pickled arrays around to > different processes, I don't know if that is still the case, but if so, no > copy > might be a big gain for them. Yes, most parallel code that's across processes or across computers use some form a pickle. I hope that this PEP would enable large speed ups. This would be a big deal for parallelism in numerical Python. ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] PEP 574 - zero-copy pickling with out of band data
On Tue, Jul 03, 2018 at 08:54:51AM +0200, Andrea Gavana wrote: > This sound so very powerful... it’s such a pity that these type of gems won’t > be backported to Python 2 - we have so many legacy applications smoothly > running in Python 2 and nowhere near the required resources to even start > porting to Python 3, I am a strong defender of stability and long-term support in scientific software. But what you are demanding is that developers who do free work do not benefit from their own work to have a more powerful environment. More recent versions of Python are improved compared to older ones and make it much easier to write certain idioms. Developers make these changes over years to ensure that codebases are always simpler and more robust. Backporting in effect means doing this work twice, but the second time with more constraints. I just allocated something like a man-year to have robust parallel-computing features work both on Python 2 and Python 3. With this man-year we could have done many other things. Did I make the correct decision? I am not sure, because this is just creating more technical dept. I understand that we all sit on piles of code that we wrote for a given application and one point, and that we will not be able to modernise it all. But the fact that we don't have the bandwidth to make it evolve probably means that we need to triage what's important and call a loss the rest. Just like if I have 5 old cars in my backyard, I won't be able to keep them all on the road unless I am very rich. People asking for infinite backport to Python 2 are just asking developers to write them a second free check, even larger than the one they just got by having the feature under Python 3. Gaël ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] PEP 574 - zero-copy pickling with out of band data
On Tue, Jul 03, 2018 at 09:42:08AM +0200, Andrea Gavana wrote: > I’m happy if you feel better after your tirade. Not really. I worry a lot that many users are going to be surprised when Python 2 stops being supported, which is in a couple of years. I wrote this tirade not to make me feel better, but to try to underlie that the switch is happening, and more and more of these exciting new things would pop up in Python 3. Soon, new releases of projects like numpy and scikit-learn won't support Python 2 anymore, which means that they will be getting exciting features too that don't benefit Python 2 users. It is a pity that some people find themselves left behind, because Python 3 is more and more exciting, with cool asynchronous features, more robust multiprocessing, better pickling, and many other great features. I found that, given a good test suite, porting from 2 to 3 wasn't very hard. The 2 key ingredients were a good test suite, and not hand-written C binding (Cython makes supporting both 2 and 3 really easy). My goal is not to shame, or create uneasy discussions, but more to encourage people to upgrade, at least for their core dependencies. Maybe I am not conveying the right message, or using the right tone. In which case, my apologies. I am genuinely excited about the Python3 future. Best, Gaël ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] we held an impromptu dtype brainstorming sesison at SciPy
Thank you so much to everybody involved; this is important for the ecosystem. Gaël On Sat, Jul 14, 2018 at 03:39:25PM -0500, Matti Picus wrote: > The stars all aligned properly and some of the steering committee suggested > we put together a quick brainstorming session over what to do with dtypes. > About 20 people joined in the discussion which was very productive. We began > with user stories and design requirements, and asked some present to spend 5 > minutes and create a straw-man implementation of what their dream dtype > implementation would contain. The resulting document > https://github.com/numpy/numpy/wiki/Dtype-Brainstorming will serve as the > basis for a future NEP and more work toward a better, user-extensible dtype. > More comments are welcome, the discussion is only at the beginning stages. > Matti > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion -- Gael Varoquaux Senior Researcher, INRIA Parietal NeuroSpin/CEA Saclay , Bat 145, 91191 Gif-sur-Yvette France Phone: ++ 33-1-69-08-79-68 http://gael-varoquaux.infohttp://twitter.com/GaelVaroquaux ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Roadmap proposal, v3
Looks great! Thank you for doing this! Gaël On Tue, Jul 24, 2018 at 12:04:49PM -0700, Stefan van der Walt wrote: > Hi everyone, > Please take a look at the latest roadmap proposal: > https://github.com/numpy/numpy/pull/11611 > This is a living document, so can easily be modified in the future, but > we'd like to get in place a document that corresponds fairly closely > with current community priorities. > Best regards, > Stéfan > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion -- Gael Varoquaux Senior Researcher, INRIA Parietal NeuroSpin/CEA Saclay , Bat 145, 91191 Gif-sur-Yvette France Phone: ++ 33-1-69-08-79-68 http://gael-varoquaux.infohttp://twitter.com/GaelVaroquaux ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] The http://planet.scipy.org/ site is down.
It used to be enthought. Sorry, I'm traveling for vacations, and I cannot take care of this right now. Gaël Sent from my phone. Please forgive typos and briefness. On Aug 18, 2018, 07:44, at 07:44, Charles R Harris wrote: >Hi All, > >Anyone know who hosts http://planet.scipy.org/? > >Chuck > > > > >___ >NumPy-Discussion mailing list >NumPy-Discussion@python.org >https://mail.python.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] acknowledging sponsorship and institutional partners
On Mon, May 20, 2019 at 11:01:15AM -0700, Nelle Varoquaux wrote: > I'm pretty sure not all funding is acknowledged on scikit-learn's frontpage. I > think the minimum amount to be acknowledge with a logo is funding for a full > time developer for at least a year, ie at least 100k€. These days, it's actually more: it should be several years. G ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Stricter numpydoc validation
> The one thing I worry about is maintenance burden, where numpydoc is already > spread a little bit thin -- would any of the Pandas developers be willing to > maintain it? Any reason that this is not done in sphinx, with the napoleon extension? https://www.sphinx-doc.org/en/master/usage/extensions/napoleon.html I would hope that this can increase the number of people likely to help maintaining. My 2 cents, Gaël ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] new absolute beginners tutorial merged
This is great!! Did someone tweet about this, so that I retweet? I'm happy crafting a tweet myself, but I'd rather shine light on someone who deserves the attention. Thanks a lot to all involved, in the name of the community, Gaël On Tue, Jan 21, 2020 at 03:20:06PM -0800, Anne Bonner wrote: > What an exciting day!!! Thank you! > ~Anne > On Tue, Jan 21, 2020 at 2:20 PM alexander baker > wrote: > This looks really helpful, thanks to all those whom took the time to > write. > Alex b. > On 21 Jan 2020, at 19:19, Ralf Gommers wrote: > Hi all, > I think this is worth announcing: we have a new tutorial in the user > guide titled "NumPy: the absolute basics for beginners". This was Anne > Bonner's Season of Docs project, and it is a big step in the right > direction for making are docs more accessible to new users. > Up at https://numpy.org/devdocs/user/absolute_beginners.html > Cheers, > Ralf > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion -- Gael Varoquaux Research Director, INRIA Visiting professor, McGill http://gael-varoquaux.infohttp://twitter.com/GaelVaroquaux ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] new absolute beginners tutorial merged
Thanks. Exactly what I needed. I don't know why I did not find it myself :). Cheers, Gaël On Wed, Jan 22, 2020 at 05:02:01PM +0100, Ralf Gommers wrote: > On Wed, Jan 22, 2020 at 1:13 AM Gael Varoquaux > wrote: > Did someone tweet about this, so that I retweet? I'm happy crafting a > tweet myself, but I'd rather shine light on someone who deserves the > attention. > Thanks Gael. Here is Anne's tweet: https://twitter.com/annebonnerdata/status/ > 1219778893537669121. > Cheers, > Ralf > Thanks a lot to all involved, in the name of the community, > Gaël > On Tue, Jan 21, 2020 at 03:20:06PM -0800, Anne Bonner wrote: > > What an exciting day!!! Thank you! > > ~Anne > > On Tue, Jan 21, 2020 at 2:20 PM alexander baker < > baker.alexan...@gmail.com> > > wrote: > > This looks really helpful, thanks to all those whom took the time to > write. > > Alex b. > > On 21 Jan 2020, at 19:19, Ralf Gommers > wrote: > > Hi all, > > I think this is worth announcing: we have a new tutorial in the > user > > guide titled "NumPy: the absolute basics for beginners". This > was > Anne > > Bonner's Season of Docs project, and it is a big step in the > right > > direction for making are docs more accessible to new users. > > Up at https://numpy.org/devdocs/user/absolute_beginners.html > > Cheers, > > Ralf > > ___ > > NumPy-Discussion mailing list > > NumPy-Discussion@python.org > > https://mail.python.org/mailman/listinfo/numpy-discussion > > ___ > > NumPy-Discussion mailing list > > NumPy-Discussion@python.org > > https://mail.python.org/mailman/listinfo/numpy-discussion -- Gael Varoquaux Research Director, INRIA Visiting professor, McGill http://gael-varoquaux.infohttp://twitter.com/GaelVaroquaux ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Upcoming: 2nd edition of "Machine learning with scikit-learn MOOC"
Hi everyone, The team at Inria, with the help of the Inria learning lab, will soon be opening the 2nd edition of the "Machine Learning with scikit-learn" MOOC: https://www.fun-mooc.fr/en/courses/machine-learning-python-scikit-learn/ The content of the MOOC is visible here (we are still polishing details, this is not final): https://inria.github.io/scikit-learn-mooc/ As you can see, it touches all the basics of machine learning, introduced with scikit-learn, teaching much more than the API of the library. We have put a lot of effort on being didactic. Anna Kondratenko, one of last year's participant, said of last year's edition: "I did a #ScikitLearnMooc course as part of a #100DaysOfCode challenge and I just loved it. Scikit-learn creators managed to make it practice-focused and entertaining at the same time. Also, it is perfect for beginners since it starts from the basics going to more advanced level." https://twitter.com/anacoding/status/1484949583629369344 This year's edition should be significantly more didactic! One of the values of participating to the MOOC, compared to just the material that we provide on the web, is that it is full of coding exercise, that are meant to teach understanding of machine-learning and coding skills. The MOOC is absolutely free, and all the materials are open (in the spirit of scikit-learn). While people on this list may already know the contents of this MOOC (though, we have inserted many useful reflections), you might know people who could benefit from this course to learn machine learning. Please help us spread the word. Pythonly yours, Gaël -- Gael Varoquaux Research Director, INRIA http://gael-varoquaux.infohttp://twitter.com/GaelVaroquaux ___ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
