> So are assembly language instructions. Yet, I could think about
> some average instruction size for similarly written programs.
Do you mean `time' rather than `size'?
If you do, then you can get rather wrong results when considering
assembly language since the concept of timing an individual
instruction is almost meaningless on modern machines.
(And if you do manage to compute the cycle count of an instruction
sequence then caching can play very ugly tricks on you.)
But, still, it works rather well in assembly language and you
won't be off by more than a constant factor.
In the worst case you can be very wrong with reduction count in
Hugs since there is no upper bound on the execution time of
an individual reduction.
I'm not sure what you're trying to accomplish. If you want to
decide from a theoretical point of view which is the better
algorithm then you should do something more abstract.
If you're trying to decide which algorithm is better in a
certain situation then you should time it in that context.
Comparing reduction counts in Hugs will not help you much
if you ultimately want to run your code compiled with e.g. hbc.
Something which is better with one compiler can be worse
on another.
-- Lennart
