Re: [Phys-L] The Art of Computational Science

[John Denker <jsd@av8n.com>]

On 09/17/2014 11:18 AM, Bernard Cleyet wrote:

> The Art of Computational Science series will provide a student with a
> hands-on guide to building a computational laboratory, and doing
> state-of-the-art research with it. The series will be self-contained:
> a high-school student should be able to start at page 1, and work her
> way through the series.”
> 
> The Art of Computational Science
> 
> http://www.artcompsci.org/msa/web/vol_1/v1_web/node2.html

Wow, thanks for the pointer.

I like the colloquial style of presentation.

I like the emphasis on doing warm-up exercises.  That is,
write something that works, even if it is a verrrry small
subset of the main problem.  Then extend it.  Learn from
it.  Throw it out and start over a few times.

The idea of writing good code the first time is out of
the question for students, and indeed for 99.99% of the
professionals.  Every so often you get somebody analogous
to J.S. Bach, somebody whose improvisations are better 
than everybody else's compositions, but the rest of us 
need to iterate a few times.  I once rewrote the same
100 lines of code six times over a two-week period.  It
got a lot better each time.

I agree about 93% with the story in the preface about
the value of starting from scratch.  On the other side
of the argument, it is necessary for students to learn 
to /read/ code.  You can't just programming ab_initio
and re-invent all the wheels.  You need good role
models.

========

The artcompsci code re-raises the fundamental question
about guided inquiry:  How much guidance?

The code on the site could not have been written by
students without a lot of guidance.  It's too polished.
On the other hand, one could argue that it's not
polished enough, and the students would have learned
more if they had gotten /more/ guidance.

  I don't think I'm being inconsistent there.  I'm
  pointing out a longstanding dilemma.  Please 
  don't shoot the messenger.

In particular, somebody needs to give them a clue
about /commenting/ the code.  The site has a lot of
"dialog" discussing the code, which is fine as far
as it goes ... but they need to learn to capture
the high points of the dialog and write them into
the source file.  Yeah, I know this requires an
investment of time, but it pays off down the road.

Again, this illustrates one fundamental limitation
of inquiry methods:  Students cannot possibly guess
what will pay off in the long run and what won't.

Also:  At some early point in the story, it would
have been good for the fairy godmother to tell them 
about symplectic integrators.  For this kind of 
problem, that's an incredibly huge win.  Even the 
earliest first-order Euler code could have been
made symplectic with zero increase in complexity.
Besides, if these students are wannabe astronomers 
or dynamicists, they ought to know about phase 
space anyway.
  https://www.av8n.com/physics/symplectic-integrator.htm

As another example of the same thing:  An observer
might ask, why did the students write in C++?
Everything they have done so far could have been
done just as easily in plain C.  The answer is
that they got some very heavy guidance.  It was
IMHO good guidance, insofar as a few years down
the road they will learn to use the real power
of the language.  In the meantime, it isn't
better, but it isn't worse, so the guidance is
clearly correct.  Again, the students have no
clue about how or even whether this will be
useful in the long run.

  Hint:  If these students are so smart, at some
  point one of them is going to google for
    https://www.google.com/search?q=c%2B%2B+vector+math+library
  and discover ways of making the code very
  much easier to write, easier to read, easier
  to debug, easier to maintain......

This illustrates why it's hard to learn anything
by reading about "guided inquiry" in the PER
literature.  The idea has been around for 2500
years.  It can produce any result you can imagine,
good or bad, depending on the amount and quality 
of the guidance.