🚀 go-pugleaf

In article <SMITH.93Feb21175110@minerva.harvard.edu>, smith@minerva.harvard.edu (Steven Smith) writes:
|> I wrote a conjugate gradient algorithm to compute the extrema of a
|> certain function defined on the compact Stiefel manifold V(n,k)
|> (n-by-k matrices with orthonormal columns).  This algorithm is mostly
|> QR decompositions and matrix-vector multiplications.
|> 
|> The algorithm converges as predicted, but for moderately sized n and
|> small k (n = 100, k = 3), I noticed that after about 80 steps or so,
|> the algorithm slowed down considerably -- from about 0.01 seconds per
|> step to over 1 second per step.  This was very perplexing because the
|> steps (should) have a constant flop count.

You probably have generated arithmetic underflows or overflows, which
are handled for you by the OS, albeit very slowly.

If you are doing this on a Sun, I'd recommend adding something like
the following to your programs:

	ieee_handler("set","common",SIGFPE_ABORT);

In general, you should print out values and use a debugger when
you are testing code. Problems like this would become obvious 
quickly.

|> After some puzzling, he suggested that I use SUN's cc compiler instead
|> of GNU's gcc compiler (v. 2.2.2).  The problem vanished immediately
|> after recompiling.  Ironically, using gcc's optimization flag -O made
|> the program run even slower.
|> 
|> I am left wondering if I can trust gcc's reliability for numerical
|> work.

I have experienced unpleasant bugs in both GNU C and Sun cc. You 
always have to double check your results against compiler bugs.
I'm not sure why you would get different behavior in the two cases,
though; did you perhaps eliminate prototypes when going from GNU C
to Sun C?

In my experience, GNU C has been a reliable and efficient compiler 
for numerical work (I haven't used 2.2.2 much, so I can't comment on how
well that particular version works).

					Thomas.