So, I’d want to at least implement my “min_max” routine above with a simple IF statement (no nesting would be required for a two-variable min/max) instead of using calculations. (That would still leave the LET expression that calculats #mid, but I trust addition more than division. )

But really I’d probably want to replace both min_max and min_mid_max with the following:

begin-procedure min_mid_max_if(#x, #y, #z, :#min, :#mid, :#max)

move #x to #min

if #y < #min
  move #min to #mid
  move #y to #min
else
  move #y to #mid
end-if

if #z < #min
  move #mid to #max
  move #min to #mid
  move #z to #min
else
  if #z < #mid
    move #mid to #max
    move #z to #mid
  else
    move #z to #max
  end-if
end-if

end-procedure ! min_mid_max_if

Although this routine involves more lines of code than the min_max/min_mid_max combo, I think it is somewhat easier to understand what each line is trying to accomplish (and it involves no arithmetic calculations at all)….

For the two-variable case, I remembered from years ago the trick that relies on the fact that the average of two numbers is half-way between them, so if you start at the average and then move one-half of the difference between the two numbers you end back at one of the original two numbers — and by controling which direction you move, you will arrive at either the smaller or the larger of the two.

So, simplifying the formula and converting it into SQR code produces:

begin-procedure min_max(#x, #y, :#min, :#max)
let #min= ( #x + #y - abs(#x - #y) )/2
let #max= ( #x + #y + abs(#x - #y) )/2
end-procedure

For the three-variable case, I wasn’t able to convince myself that any code would be “simpler” than breaking down the problem into pairs and invoking the two-variable procedure on each pair:

begin-procedure min_mid_max(#x, #y, #z, :#min, :#mid, :#max)
do min_max(#x, #y, #lower, #higher)
do min_max(#lower, #z, #min, #dummy1)
do min_max(#higher, #z, #dummy2, #max)
let #mid= #x + #y + #z - #min - #max
end-procedure

(We know that at least one of #dummy1 or #dummy2 is going to be #mid, but we don’t know which one, so as long as we are avoiding IF commands we just use addition/subtraction to calculate #mid.)

Did you find anything simpler than that? (Well, other than just using IF, which would clearly be much simpler )

Why are we avoiding IF? Can we use the cond() function? How about range()? Or are you trying to stick with “math” functions like sign()?

First, FORTRAN, the IBM FORmula TRANslating System, had integer variables and floating point variables. Fortran variable names that started with I through N were integers.

Second, Fortran allowed variables with up to five or six character names (I forget which). I don’t know whether that was in the first version; my earliest experience was with Fortran II and most of my experience was with Fortran IV. In Fortran IV, any variable could be declared as an integer.

So ‘I’ was just the first and shortest legal choice for an integer loop counter.

Now, I don’t have encyclopedic knowledge of features introduced in each version of FORTRAN, but at some point it allowed programmers to explicitly declare variables with any name to have any type. Is that what you’re referring to as the solution introduced in FORTRAN II?

(Of course, I was being facetious in the first place about the problem with nested loop variables. Even the original FORTRAN allowed variables with multi-character names. As for the ancient Romans, they used APL, thus causing Servilius Casca to famously complain “it was Greek to me.”)

As for recursion not being necessary: sure, you can, with varying degrees of difficulty, survive without it. But the same is true of the EVALUATE statement, and you were keeping score for that. I detect blatant pro-SQR bias!!

I stopped keeping score between SQR and C because I demonstrated that recursion is completely unnecessary. Next week, I will debunk pointers (smirk).