[Edu-sig] Sage, SciPy or continue with MatLab ???

Bill Punch punch at cse.msu.edu
Mon Feb 1 20:46:19 CET 2010


Regarding conformity. When we moved the introductory course (used by
both CS majors and non-majors) to Python, one of the criteria was to
ensure as little changes to the subsequent curricula as possible. This
obviously made the change much more palatable to the faculty. Thus the
following course, CS2, remained in C++.

What was the effect of throwing Python students into a C++ class? My
colleague Rich Enbody and I studied that question and reported on it
last year at SIGCSE and Pycon. Bottom line, those that took a CS1 course
in C++ and those that took a CS1 course in Python performed equally well
in a CS2 course in C++. Furthermore, very little (if any) changes were
required in topic coverage for the CS2 course.

Basically, we assume that learning the concepts in Python translated
well to C++, enabling those that carry on to learn C++ fairly easily.
For those that quit at the CS1 stage, they were taught a language that
was practical, useful, in their subsequent careers. We have ample
anecdotal evidence to that.  I can provide the paper(s) to those
interested.

        >>>bill<<<
	"The Practice of Computing Using Python", available 3/1/10, 		         Addison Wesley/Pearson




David MacQuigg wrote:
> kirby urner wrote:
>> On Sun, Jan 31, 2010 at 10:05 AM, michel paul <mpaul213 at gmail.com>
>> wrote:
>>
>>
>> << SNIP >>
>>
>>  
>>> Again, one of the things I truly love about Sage is that at its
>>> core, it is
>>> pure Python.  I was delighted with something one of my FST students
>>> said.  I
>>> had been using Sage as my blackboard in class, and then I started
>>> showing
>>> them pure Python.  My student said that he liked having to think things
>>> through in pure Python better than using Sage directly, because Sage
>>> seemed
>>> so overwhelming.  When I had them restricted to just the Python
>>> shell, he
>>> liked having to reason with just a small set of constructs.  I was
>>> glad to
>>> hear him say that, as it showed he was really getting the message
>>> about what
>>> I was saying 'computational thinking' was all about.
>>>
>>> - Michel
>>>     
>>
>> Thank you for sharing more about Sage, the above remark especially.
>>
>> Yes, like Mathematica, Sage may seem overwhelming given how the math
>> concepts come flooding in on top of Python.
>>
>> If Python is unfamiliar to begin with, then the learning curve may seem
>> vertical.
>>
>> If you read through parts of the tutorial below (as I've been doing),
>> you'll see that the introductory chapters read a lot like a standard
>> Python tutorial.
>>
>> This book is written (per introduction) for Sage users who have been
>> exposed to a computer language before, just maybe not Python....
>>
>> http://sage.math.washington.edu/home/tkosan/newbies_book/sage_for_newbies_v1.23.pdf
>>
>>   
>
> Nice tutorial.  I'm still having difficulty seeing an advantage of
> Sage over Python/SciPy, however.
>
> I'm putting together a proposal for a freshman-level course in CS. 
> Currently we have three courses - one for CS majors (Java), one for
> computer engineers (C), and one for physics and astronomy (C).  
> Matlab is also used in many of our science and engineering classes. 
> Here it is just a tool, not a subject of study in itself.
>
> The course I will propose could serve all departments, and will cover
> the fundamentals common to all.  It could also be an excellent high
> school preparation for college.  The language will almost certainly be
> Python, although we may get as far as introducing a little Java or C. 
> (This could perhaps be an option in the last three weeks - Java for CS
> majors, and C for engineers and scientists.)
>
> Graphics will be very important - everything from simple 2D plots to
> 3D animations.  The focus will be on computing fundamentals, however,
> not the details of how these packages work.  They are just tools to
> visualize an equation or process and aid in the understanding of
> concepts.
>
> Examples contributed by faculty in math, science and engineering will
> be an outstanding feature of this course.  Here is where we need more
> than the standard library in Python.  We need a Fourier transform that
> "just works" and produces beautiful spectra of various waveforms and
> images.  We need the functionality of MatLab, without its drawbacks.
>
> I've been leaning toward Python/SciPy/MatPlotLib, but recent
> discussions of Sage have me interested in looking at alternatives. 
> What are the factors we need to consider?
>
> 1) Features.  Does the package do everything we might want, now and in
> the future when students use it for later classes and on the job.
> 2) Simplicity.  Is it easy to set up and use on student computers
> (Windows, Mac or Linux)?  Is it easy to learn?  Is it open-source, so
> students can dig into it as deep as they like?   Is it available
> everywhere without legal complications, e.g. MatLab's license?
> 3) Universality.  This is more than just popularity (counting
> users).   We need a minimum level of community support (discussion
> groups, interest from employers, programs on SourceForge, books from
> Amazon, etc).  Availability of textbooks is a special consideration in
> this category.  Ruby, Prothon, Scala, etc. (one up from Python?) have
> nothing comparable to Litvin/Zelle/Goldwasser.
> 4) Conformity.  Does it fit in well with existing curricula?  Is there
> an easy transition to Java, C, MatLab, etc.  Can it be used as just a
> tool in a course that has nothing to do with programming?
>
> This last factor is especially difficult for us idealists.  We might
> like to toss out everything in the status quo, and start with a clean
> slate, but that approach will get us nowhere.  We need options all the
> way from a one-hour demo to a whole course centered on the use of
> these tools.
>
> Before comparing these packages, let's discuss the factors above. 
> Have I left out anything important?
>
> -- Dave
>
> ************************************************************     *
> * David MacQuigg, PhD    email: macquigg at ece.arizona.edu   *  *
> * Research Associate                phone: USA 520-721-4583   *  *  *
> * ECE Department, University of Arizona                       *  *  *
> *                                 9320 East Mikelyn Lane       * * *
> * http://purl.net/macquigg        Tucson, Arizona 85710          *
> ************************************************************     *
>
>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig


More information about the Edu-sig mailing list