Malcolm McLean said:
Maybe. I tried to be exhaustive, but I might have missed something
important.
Types. B is typeless, C has types. They not included in your list of
"all you really need" so it's for you to say if you really need them
i.e. that you missed something important, or, alternatively, that C has
*more* than you need.
Obviously not essential, B was presumably usable, but not as nice as
C.
Obviously Euclid didn't have a C compiler.
The algorithm is
Start with a pair of positive integers, a and b.
while the two integers are unequal
set a to the minimum of a and b
set b to the absolute difference between a and b
repeat
The answer is the value.
In Euclid, the procedure is presented twice to determine two separate
things. What you've written is the abstraction of the common part into
a single procedure. Euclid never did that (it was presumably not
important to him; he surely knew that there was something important in
common between the two). Furthermore, you have taken his wording of
"measures" (remainders) and lengths and turned it into a notation of
variables and loops. That all comes from you.
Someone familiar with, say, Haskell would have written this algorithm in
a different pseudo-code.
That maps pretty well to C thinking,
I think you agree with me. I said:
"the trick is to think in terms of programs that map into C"
That's exactly what you are doing. You've abstracted the algorithm from
one form (the rather ill-specified wording in the original) but you've
been careful to do that in a way that maps to into C. People with other
perspectives will see it differently.
you've got a while loop in there,
and comparison operators. Also a and b are variables you keep track
of, not parameters. I can't read Greek so I can't read Euclid's
original text, and in my summary the fact that a is corrupted by the
first step is glossed over - Euclid may or may not have done that,
it's a normal thing to do when describing an algorithm in natural
rather than formal language.
Are you looking at proposition I or II? Proposition II (the GCD one)
starts (and I too must rely on translation):
Let AB and CD be the two given numbers not relatively prime.
I don't see that in your algorithm. Could it be that you (or th editor
of your edition) abstracted
something out that was not there in the original?
So yes, we're thinking of it in C terms - while loops, comparisons, a
sub-function which takes the minimum.
Who's "we"? You and Euclid? I don't see how you can say that. If you
are trying to be inclusive, let me quote Samuel Goldwyn: include me out.
Not in pure assembler terms,
where you might only have x, y and a registers and not be able to
devote one to a and one to b. Not in object-oriented terms where a and
b are anything that supports the < and - operators. Not in Lisp terms
whereby each step is a recursive call to the previous one. C terms are
the natural ones that most people use when thinking about algorithms.
But you are avoiding the main question: if what you say is true, how do
people who don't know C, or, if you are backing down form that, a C-like
language, think about algorithms? How did Church think about his
effective procedures? Not in terms of C or anything like it, that's for
sure.