Robert G. Brown wrote:
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
Its actually not that painful. I was able to walk through it in one
session, explaining what the symbols mean, how to read them, and then
showing them in use for a heat diffusion problem in 2D (breaking up a
large array into panels).
Indeed, if you combine pointers with a "here's how the computer REALLY
works, kids" lecture so that you help them visualize memory and maybe
My first two lectures were on that. Bytes? We don't need no steenkeen
bytes! Cache lines is where its at, yessiree.
One of my favorite examples of showing them that memory is not a "big
honking chunk O ram" is creating an array, and using two loops to walk
through it, then interchanging the order of the loops. Same memory
access, one just takes, well, a little bit longer than the other.
I sort of hid the pointer stuff in the matrix setup anyway, and then I
roll it out. It's not too painful, and as long as you talk about it
carefully, they seem to get it (or at least not struggle with it).
give them a simplified overview of "assembloid" -- a ten instruction
assember that does nothing but load, store,
add/subtract/multiply/divide, compare (x3), and branch that helps them
understand what compilers are actually doing in there, it will doubtless
help them with both why pointers are astoundingly useful and how/when to
use them.
I preferred the "pragmatic" examples: those focused upon a particular
problem, and used that problem as the template to discuss how to access
particular things. Once you get them mentally breaking down the
problem, they naturally ask the "how do I" questions, which are a bit
easier to answer than the "why" questions.
Sum reductions look the same in all languages. And they can be done
incorrectly in all languages :(
Which is the one reason that they DO need at least the first couple of
chapters of real numerical methods somewhere in there. Fortran
encourages you to think that there is a standard FORmula TRANslation for
any equation based algorithm, and of course in once sense there is. If
you fail to ever learn the risks of summing e.g. alternativing series
with terms that mostly cancel, one day you are bound to e.g. sum up your
own spherical bessel functions from the ascending recursion relation and
wonder why all your answers end up wrong... especially when it WORKS for
the first three or four values of \ell.
The example I showed in the MPI class was this:
program sum
real*4 sum_x,sum_y
integer i,N
N=100000000
sum_x=0.0
do i=1,N
sum_x = sum_x + 1.0/float(i)
enddo
print *,' sum = ',sum_x
sum_y=0.0
do i=N,1,-1
sum_y = sum_y + 1.0/float(i)
enddo
print *,' sum = ',sum_y
print *,' difference = ',sum_x-sum_y
end
Compiling and running this usually gets people's attention
[EMAIL PROTECTED]:~$ gfortran sumfs.f
[EMAIL PROTECTED]:~$ ./a.out
sum = 15.40368
sum = 18.80792
difference = -3.404236
Same sum, just done in different orders. Yes it is a divergent series
in general, but that isn't the reason why you get this difference. Its
all about the roundoff error accumulation. You see this in every
language.
The issue is that even good languages can "hide" bad algorithms. Its
the algorithms that matter. FWIW: the second sum is much closer to what
the double precision version will report.
rgb
--
Joseph Landman, Ph.D
Founder and CEO
Scalable Informatics LLC,
email: [EMAIL PROTECTED]
web : http://www.scalableinformatics.com
http://jackrabbit.scalableinformatics.com
phone: +1 734 786 8423
fax : +1 866 888 3112
cell : +1 734 612 4615
_______________________________________________
Beowulf mailing list, [email protected]
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf
