[Beowulf] Teaching Scientific Computation (looking for theperfect text)

Michael Will mwill at penguincomputing.com
Tue Nov 20 12:42:17 PST 2007


Yeah K+R is fun. Look up 'recursion' in the index...

Sent from my GoodLink synchronized handheld (www.good.com)


 -----Original Message-----
From: 	Nathan Moore [mailto:ntmoore at gmail.com]
Sent:	Tuesday, November 20, 2007 12:41 PM Pacific Standard Time
To:	Peter St. John; beowulf at beowulf.org
Subject:	Re: [Beowulf] Teaching Scientific Computation (looking for theperfect text)

Thanks for the message Peter.  I agree with you about the lucidity of K&R,
although I think the Landau-Lifshitz series of texts eclipses it in overall
greatness.

Regarding demographics, I'm thinking mainly about the device driver/embedded
systems/EE track, in which a fortran interface seems to be unheard of.  The
only field I know of in which Fortran is common and vital is numerical
weather modeling.  Maybe others on the list can disabuse me of this notion.

Also, the truck full of gravel analogy is great, thanks!

On Nov 20, 2007 1:30 PM, Peter St. John <peter.st.john at gmail.com> wrote:

> Nathan,
> I'm sure you'll get lots of very experienced responses but if I may:
> 1. Book. K&RC is the best book ever, on any subject.
> 2. Demographics. It looked to me that engineers were typically
> learning and using C (C++, C with Classes, sometimes Java) more than
> Fortran. I would have expected similar among physicists, but I
> understand that a lot of Fortan is still extant and vital. Also there
> is some convergence, ultimately it won't matter much.
> 3. Pedagogy. When computational efficiency is important, the
> distinctions bettween sending data, and sending references to data, is
> real important. I think it can be made vivid, early; what's the
> difference between my handing you a card with the shipping address of
> the warehouse that has the gravel you need for your construction
> business, and handing you one thousand wheelbarrows full of gravel?
> Either way can be right in the circumstances, but the difference is
> obviously very relevant and should be taught even if you use a
> language that hides the distinctions.
> 4. You might let them choose, but that might make more sense with
> graduate students, than undergrads, and you may not like grading
> papers in multiple languages. So you might ask about departmental
> guidelines, what languages they will be exprected to learn anyway. I'd
> advocate presenting some of the shorter but fundamental algorithms in
> two languages, if you have time, but time is scarce and it's a physics
> course, not a programming course.
> 5. Choose C because there is no real choice, but I don't have time to
> explain that in the margin of my email :-)
> Peter
>
>
> On Nov 20, 2007 1:33 PM, Nathan Moore <ntmoore at gmail.com> wrote:
> > I regularly teach a college course in a physics department that deals
> with
> > scientific computation.  After students take the course, I expect that
> > they'll be able to write simple "c-tran" style programs for data
> analysis,
> > write basic MD or MC simulations, and be fairly fluent in Mathematica.
> >
> > In the past, I figured that with the breadth of topics included in the
> > course, Fortran, specifically the basic, simple, and reliable F77
> dialect
> > (w/ some F90 conveniences) was the language to teach.  In my own head,
> my
> > rationale was:
> > - Most students can grasp the basics of fortran in half a day's reading,
> so
> > I can spend more class time on science and math (probably because there
> are
> > no pointers - I think that C is much harder for students and sometimes
> > "seems" less like mathematical syntax than f77)
> > - "Classical Fortran" is a great text and is readable for self-study (I
> know
> > of no such text for C/C++)
> > - several free compilers exist (g95 seems ok so far)
> > - Netlib, lapack, and numerical recipes cover the math library
> adequately
> > - F77 is compiled (Perl/python are too slow for an MD/MC sim and I
> figure
> > that students should know at least on compiled language and one
> scripting
> > language to be competent)
> > - MPI is a relatively basic addition to the language (again, no
> pointers,
> > allocation, or addressing)
> >
> > After reflection though, I've started to wonder about the wisdom of my
> > choice.  Specifically (like RGB), I love the GSL library, and extending
> GSL
> > to fortran in an intro class is non-trivial.  Additionally, most vendors
> > supply "fast" hardware libraries in C (I may be ignorant, but if a
> student
> > wants to call an AMD ACML fast-math function(
> > http://developer.amd.com/acml.jsp), or write a linear algebra function
> to
> > run on a graphics card(http://developer.nvidia.com/object/cuda.html ),
> the
> > vendors seem to assume that you'll write the code in C).
> >
> > Also, and more relevant, I assume that most employers word-associate
> > "Fortran is to backwards as C is to competence".
> >
> > So, I'm thinking about reworking the class to favor C, and fearing 3
> weeks
> > of pointer and addressing hell.  For those of you who teach scientific
> > computation (and also those of you who hire undergrads), I'd be grateful
> for
> > your thoughts.  One specific question I have is what text covers
> scientific
> > programming and touches on MPI using the C language.
> >
> > regards,
> >
> > Nathan Moore
> >
> >
> > --
> > - - - - - - -   - - - - - - -   - - - - - - -
> > Nathan Moore
> > Assistant Professor, Physics
> > Winona State University
> > AIM: nmoorewsu
> > - - - - - - -   - - - - - - -   - - - - - - -
> > _______________________________________________
> > Beowulf mailing list, Beowulf at beowulf.org
> > To change your subscription (digest mode or unsubscribe) visit
> > http://www.beowulf.org/mailman/listinfo/beowulf
> >
> >
>



-- 
- - - - - - -   - - - - - - -   - - - - - - -
Nathan Moore
Assistant Professor, Physics
Winona State University
AIM: nmoorewsu
- - - - - - -   - - - - - - -   - - - - - - -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.beowulf.org/pipermail/beowulf/attachments/20071120/80672b81/attachment.html>


More information about the Beowulf mailing list