Remove goto from procedure

[Thaddy]

goto: Spaghetti
Goto removed: structured.
The program flow is easier to digest.

@wp
I would not worry too much about the license:
This only hold for textual content, not for the sourcecode, because that is almost completely based on previous, prior knowledge, which makes such claims invalid.
Implementing the same algorithm in a different programming language doesn’t necessarily grant new copyright, because the algorithm itself can be copyrighted - but usually: Copyright primarily covers the expression, not the underlying idea or concept. Which ties it to implementing language, imnsho.

[Thaddy]

It's the FORTRAN legacy.

No it is a very low level substitution of an asm compare/jump instruction which is hardware and much older than even fortran.
In the case of goto removed, try examining the assembler for any compiled language and any CPU. Goto's (compare/jumps) all over the place.

[Curt Carpenter]

No it is a very low level substitution...

I'm afraid you miss the point.  All of the algorithms in my '86 edition are written in FORTRAN with Pascal translations (such as they are) packed into the last chapter. 

Otherwise yeah -- I sort of knew how goto works.

(BTW -- I wrote some of the code for the TI 3x - 4x - series calculators back in the '70s.  Mundane stuff (display, switch debounce and such).  There was a team of about four guys that did the serious math code and testing.)

[440bx]

Probably this one: https://en.wikipedia.org/wiki/Numerical_Recipes
https://books.google.de/books/about/Numerical_Recipes_in_Pascal.html?id=69uJzQEACAAJ&redir_esc=y

Acc. to a PDF for the C-Source-code, the Function "hqr" computes "eigenvalues of a Hessenberg matrix"

EDIT: FWIW, the C-Source-Code has no Goto's, so whoever ported that to Pascal.....

Thank you for providing that information.

Between what the Wikipedia article states and the rather poor Pascal code, I'm going to stay away from this one... <chuckle>

[Zvoni]

Well, without proper definitions for all the types, and without a functions definition for sign(), the code cannot compile, so it cannot be tested.

I looked at the C-Source again

Code: C  [Select][+][-]

1. /* in "nrutil.h" */
2. #define SIGN(a,b) ((b) >= 0.0 ? fabs(a) : -fabs(a))

Huh?
I was always under the impression, a SIGN-Function actually returns the "Sign" in the form of

Code: Pascal  [Select][+][-]

1. If arg>0 Then
2.    Result:=1
3. Else If arg=0 Then
4.    Result:=0
5. Else IF arg<0 Then
6.    Result:=-1;

Admittedly, THAT Sign-Function takes only one Argument as compared to the Sign-Function used in that Algorithm (2 Arguments), but boy, this looks weird to me.

EDIT: Noticed something else:
His first two loops (Line 8 and 9) looks "wrong" to me

Code: Pascal  [Select][+][-]

1. for i := 2 to n do
2.        for j := i-1 to n do

From C-Source

Code: C  [Select][+][-]

1. for (i=1;i<=n;i++)
2.    for (j=IMAX(i-1,1);j<=n;j++)
3.       anorm += fabs(a[i][j]);

His outer loop starts at 2, the C-Loop starts at 1, nevermind the IMAX in the second loop,
with IMAX being a simple MAX-Macro for Integers

Code: C  [Select][+][-]

1. static int imaxarg1,imaxarg2;
2. #define IMAX(a,b) (imaxarg1=(a),imaxarg2=(b),(imaxarg1) > (imaxarg2) ?\
3.         (imaxarg1) : (imaxarg2))

And his Line 5: What are "TElems"?
In the C-Source those are "Floats"

I'm probably going to take a stab at it porting it to Pascal if i'm not bogged down with other things

[Zvoni]

Right. I took a stab at it.
What i thought: No Goto's necessary. And if i see this correctly even clearly distinct differences to the code in Post 1.

It..... compiles..... No idea how to test it.

And no idea, if i'm allowed to post it here.
The legalese in that PDF just gives me headaches..... ;-)

[tetrastes]

Well, without proper definitions for all the types, and without a functions definition for sign(), the code cannot compile, so it cannot be tested.

I looked at the C-Source again

Code: C  [Select][+][-]

1. /* in "nrutil.h" */
2. #define SIGN(a,b) ((b) >= 0.0 ? fabs(a) : -fabs(a))

Huh?

This is port of standard FORTRAN function, see f.e. https://gcc.gnu.org/onlinedocs/gfortran/SIGN.html.
The "native" language of NR is FORTRAN, AFAIK.

[Nicole]

Sometimes the case syntax is useful.
Every time I need it, I forget how it has worked.
Therefore I save the syntax for it, see below:

assume the value of "eingabe" is 1 then the first line would to it fine.
You can define actions for each value and even group of values of eingabe.

(translation of the first line from German to English
1: output:= 'You keyed in 1' ; )

case eingabe of
 1: ausgabe := 'Sie haben 1 eingegeben';
 2: ausgabe := 'Sie haben 2 eingegeben';
 3: ausgabe := 'Sie haben 3 eingegeben';
 else ausgabe := 'Sie haben nicht 1, 2 oder 3 eingegeben';
end;


case eingabe of
 1,3,5,7,9: ausgabe := 'Sie haben eine ungerade Zahl kleiner als 10 eingegeben';
 2,4,6,8,0: ausgabe := 'Sie haben eine gerade Zahl kleiner als 10 eingegeben';
 10..20:    ausgabe := 'Sie haben eine Zahl zwischen 10 und 20 eingegeben';
end;

[Thaddy]

case with ordinals is always way more efficient then comparisons like if the else, especially if they are in natural order (which in our case the compiler optimizes for). Alas FPC supports it for strings too, which is a fallacy.

[Bart]

Alas FPC supports it for strings too, which is a fallacy.

No, it's a nice feature and makes for more readable code then multilpe if..then..else.
As long as you remember that the code actually just translates to that.
And you better not use ranges.

Bart

[Thaddy]

And you better not use ranges.

You mean overlapping ranges I guess? Because that will throw a duplicate case label.

[Zvoni]

How did we get from a badly ported code to a discussion about the case-operator?

[Чебурашка]

Despite in most cases (also in the case presented here) using goto is not recommended nor necessary, there are some situations where I personally found much more effective to use this construct, and obtaining the same logic without would have produced a much less intelligible code structure.

Moreover, there are important projects where usage of goto is not only allowed, but also recommended.

https://www.kernel.org/doc/html/v4.19/process/coding-style.html#centralized-exiting-of-functions

[Zvoni]

I‘m not denying there possibly being situations that justify Goto, but I haven’t come across them

That said: while porting C-Code to pascal, and encountering a Goto for premature exit (with Cleanup) i could always solve it with a nested boolean-function, doing cleanup, that always returns true.

That way i always could do in pascal

Code: Pascal  [Select][+][-]

1. If SomeErrorCondition Then If CleanUp(SomeArgument) Then Exit;

With „CleanUp“ being my nested boolean-function (Arguments optional)
No need for Goto, pretty easy to read source code

[dseligo]

That said: while porting C-Code to pascal, and encountering a Goto for premature exit (with Cleanup) i could always solve it with a nested boolean-function, doing cleanup, that always returns true.

Why do you use function that always returns true?

Why not like that (procedure instead of function):

Code: Pascal  [Select][+][-]

1. If SomeErrorCondition Then
2. begin
3.   CleanUp(SomeArgument);
4.   Exit;
5. end;