Comments on: Quicksort For SQR

By: administrator

administrator — Mon, 04 Apr 2011 18:32:35 +0000

John, thank you for discovering and fixing this. I guess we can take three approaches;

(1) use #_from in the quicksort procedure
(2) pass #from as a parameter to the save_pivot procedure
(3) make quicksort a non-local procedure (I made it local so I could assign variable names freely)

I should change the code, but I need to think about these alternatives.

By: John

John — Wed, 30 Mar 2011 21:37:25 +0000

There is a problem with the “#from” variable. In the quicksort procedure, this is a local variable. When the save_pivot procedure tries to reference it, it’s not available. I change this to the global variable “#_from” in the quicksort procedure and it seems to be working now.

By: administrator

administrator — Thu, 26 Feb 2009 22:30:32 +0000

This is better than what I had in mind; you’ve basically written a specialized, three element insertion sort. The advantage of this is that you could extend it to four elements more easily than extending a mathematical solution. The next step would be to try a three element bubble sort.

By: Nathan

Nathan — Thu, 26 Feb 2009 20:04:12 +0000

Well, the thing about using the mathematical method is that I’m always slightly nervous that some math-implementation issue ( e.g. rounding errors ) might show up at some point in the life of the application. Given a choice, I’d lean toward straight MOVEs rather than relying on floating-point arithmetic, even though I know that most applications where SQR is used don’t involve numbers that push any implementation limits.

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)….

By: administrator

administrator — Thu, 26 Feb 2009 17:06:17 +0000

I think you’ve found the simplest approach, maybe even simpler than using IF statements. I’ve tried to sketch out the code with IF statements in my head and it was surprisingly complicated.

By: Nathan

Nathan — Thu, 26 Feb 2009 05:26:22 +0000

Okay, I was thinking you might be trying to go down the “algebra” road….

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 )

By: administrator

administrator — Tue, 24 Feb 2009 22:15:25 +0000

I wanted to avoid IF because the solution with IF isn’t much of a brain teaser. COND() and RANGE() are good solutions, although they merely move the IF operation into the function. There are ways to get MIN and MAX without comparing the inputs. Note that the puzzle uses numeric variables, not string variables.

By: Nathan

Nathan — Tue, 24 Feb 2009 21:45:46 +0000

Regarding the brain teaser:

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()?

By: AdvandyBainia

AdvandyBainia — Tue, 24 Feb 2009 06:48:58 +0000

Thank you!

By: administrator

administrator — Mon, 09 Feb 2009 21:41:15 +0000

You’re right on both counts.

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.