Just got a Github Education account today for my lab, which led me to look a bit more at their site. This video is relevant: https://education.github.com/stories#UCBerkeley
> If extra eyes were all that were necessary, there would be no long-standing mathematical conjectures. What is needed is both extra eyes and a community welcoming of new ideas. That's what the polymath projects do, and they have been quite successful so far, proving results that had vexed Fields medalists. Paul Paul-Olivier Dehaye SNF Assistant Professor of Mathematics University of Zurich skype: lokami_lokami (preferred) phone: +41 76 407 57 96 chat: [email protected] twitter: podehaye freenode irc: pdehaye On Thu, May 29, 2014 at 11:34 AM, Paul-Olivier Dehaye < [email protected]> wrote: > Thanks for the thoughtful replies. It's a fine line between being critical > of the idea and dismissive of the students. Please everyone limit > yourselves to criticizing the idea, as students might come to this thread > later. > I don't think one should dismiss the students. Look at the Mathworks > competition (another thing MATLAB does!), as it is described in Nielsen's > book "Reinventing Dicovery". There is a history there of microcontributions > on code leading to optimised code. > There is also two assumptions in your emails: > 1) that they will all have just learned python: the course might be just > the right blend of mathematics and CS so that some participants actually a > background in python. On top, one can modulate the difficulty progressively > to make sure to attract some students who actually have a strong python > background already (in MOOCs, there are always some experts lurking) > 2) that I would let them choose the topic. Not so. For the specifics of > how the course will be run, I need to bring the discussion out of the > mailing list. > > As William points out, small contributions are important (example in > docstring) and the process is currently suboptimal. > I would add that other small contributions could be important, such as > semantic information coming from professional mathematicians who have just > learned utter basics of python, to have a mere sense of how the decorator > they have just added will affect the method itself. For this, existing > annotation tools suffice. > > Paul > > Paul-Olivier Dehaye > SNF Professor of Mathematics > University of Zurich > skype: lokami_lokami (preferred) > phone: +41 76 407 57 96 > chat: [email protected] > twitter: podehaye > freenode irc: pdehaye > > > On Thu, May 29, 2014 at 3:40 AM, rjf <[email protected]> wrote: > >> >> >> On Wednesday, May 28, 2014 3:31:08 PM UTC-7, Paul-Olivier Dehaye wrote: >>> >>> Again, in the big wave of emails, this one also got misdirected: >>> >>> Hi everyone, >>> >>> I am looking for people who want to help me, in one way or another, bring >>> hundreds of new first time contributors to sage. If I do not find enough >>> partners, I will look for other more suitable python-based projects. >>> >>> The idea would be quite simple: teach python programming around some >>> mathematics (such as combinatorics) and simultaneously produce code that >>> would be useful for research and worth including in sage. Two catches: >>> students are given individual problems to work on, and the course is >>> taught >>> on Coursera. Motivation for the students would come in various ways: >>> internships, for instance. Quality of the code would be ensured by >>> peer-testing the programs. >>> >> >> William Stein has already responded to the major issues regarding the >> Sage development process, but I would just like to comment on this >> particular aspect of peer-testing. Having two or more people who have >> just learned python and do not know much mathematics "peer review" >> code does not lead to much of an ensured level of quality. >> Certainly there are other clumps of python aggregating code that are not >> as daunting as Sage. Numpy and Sympy come to mind, but I doubt >> that they would really relish a MOOC's-worth of naive contributions, when >> it is pretty much guaranteed that a very high percentage would, under >> careful scrutiny, be duplicative, erroneous, poorly coded, or all three. >> >> It's a nice thought to get many hands to write code free. But >> impractical, >> in spite of Eric Raymond's "Cathedral and Bazaar" essay. "All bugs are >> shallow >> with enough eyes" (or whatever the wording is...) is perhaps plausible >> if the system >> is itself shallow (like linux). >> Where I differ with Raymond is I think there are not enough eyes on the >> planet to make some >> bugs shallow in a "deep" system-- one that does (say) sophisticated >> symbolic mathematics. >> If extra eyes were all that were necessary, there would be no >> long-standing mathematical >> conjectures. >> >> >> >> >>> If you do not know what Coursera or MOOCs are, you are welcome to take my >>> upcoming course >>> https://class.coursera.org/massiveteaching-001 >>> >>> If you are interested to play with a MOOC platform yourself, you might >>> want >>> first to watch the videostream of the 2pm-3pm slot of this conference I >>> am >>> co-organising on Tuesday: >>> tinyurl.com/openedx-zurich >>> as it will help you assess the technical challenges. >>> >>> I am looking at a start date for the course of around October-November, >>> and >>> to bring the discussion off the mailing list (to private) so as to keep >>> an >>> element of surprise for the students. >>> >>> Let me know! >>> >>> Paul >>> >>> Paul-Olivier Dehaye >>> SNF Professor of Mathematics >>> University of Zurich >>> skype: lokami_lokami (preferred) >>> phone: +41 76 407 57 96 >>> chat: [email protected] >>> twitter: podehaye >>> freenode irc: pdehaye >>> >> > -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
