TI Conditionals & Spaghetti Code

[Matt Agajanian]

Hi all.

Yes, the TI library of Solid State Modules, Magnetic Cards, hundreds of Users Groups have contributed massive amounts of programs built around the SR-52, SR-56, and the 58/59 using conditionals with the automatic Go To for line numbers and labels.

But, wouldn’t the automatic transfer of a Go To instruction result in a scramble of program locations and execution flow instead of a well organized code?

I thought using Go To would just create a confusing path of programming and execution.

[toml_12953]

(05-18-2024 10:25 PM)Matt Agajanian Wrote:  Hi all.

Yes, the TI library of Solid State Modules, Magnetic Cards, hundreds of Users Groups have contributed massive amounts of programs built around the SR-52, SR-56, and the 58/59 using conditionals with the automatic Go To for line numbers and labels.

But, wouldn’t the automatic transfer of a Go To instruction result in a scramble of program locations and execution flow instead of a well organized code?

I thought using Go To would just create a confusing path of programming and execution.

Don't believe everything Dijkstra says. Virtually every CPU eventually translates comparison instructions and loops into jumps. GOTO, like any programming instruction, can be misused but it can also be used to make the logic of a program clearer. Keep your code organized into one way in, one way out and GOTO doesn't get in the way at all.

Structured method:

Code:

DO
    <some code>
    x=x+1
LOOP UNTIL x>10

Using GOTO:

Code:

LBL A
    <some code>
    x=x+1
if x<=10 GOTO A

Sure, these are trivial examples but they illustrate they GOTO doesn't need to create spaghetti code. The meaning of both segments is pretty clear.

[Thomas Okken]

(05-18-2024 11:46 PM)toml_12953 Wrote:  Don't believe everything Dijkstra says. Virtually every CPU eventually translates comparison instructions and loops into jumps. GOTO, like any programming instruction, can be misused but it can also be used to make the logic of a program clearer. Keep your code organized into one way in, one way out and GOTO doesn't get in the way at all.

Hear, hear!

[Matt Agajanian]

(05-18-2024 11:46 PM)toml_12953 Wrote:  

(05-18-2024 10:25 PM)Matt Agajanian Wrote:  Hi all.

Yes, the TI library of Solid State Modules, Magnetic Cards, hundreds of Users Groups have contributed massive amounts of programs built around the SR-52, SR-56, and the 58/59 using conditionals with the automatic Go To for line numbers and labels.

But, wouldn’t the automatic transfer of a Go To instruction result in a scramble of program locations and execution flow instead of a well organized code?

I thought using Go To would just create a confusing path of programming and execution.

Don't believe everything Dijkstra says. Virtually every CPU eventually translates comparison instructions and loops into jumps. GOTO, like any programming instruction, can be misused but it can also be used to make the logic of a program clearer. Keep your code organized into one way in, one way out and GOTO doesn't get in the way at all.

Structured method:

Code:

DO
    <some code>
    x=x+1
LOOP UNTIL x>10

Using GOTO:

Code:

LBL A
    <some code>
    x=x+1
if x<=10 GOTO A

Sure, these are trivial examples but they illustrate they GOTO doesn't need to create spaghetti code. The meaning of both segments is pretty clear.

Yes, but these are structured loops. What about conditionals based on equations/formula results by themselves?

[toml_12953]

(05-19-2024 01:22 AM)Matt Agajanian Wrote:  

(05-18-2024 11:46 PM)toml_12953 Wrote:  Don't believe everything Dijkstra says. Virtually every CPU eventually translates comparison instructions and loops into jumps. GOTO, like any programming instruction, can be misused but it can also be used to make the logic of a program clearer. Keep your code organized into one way in, one way out and GOTO doesn't get in the way at all.

Structured method:

Code:

DO
    <some code>
    x=x+1
LOOP UNTIL x>10

Using GOTO:

Code:

LBL A
    <some code>
    x=x+1
if x<=10 GOTO A

Sure, these are trivial examples but they illustrate they GOTO doesn't need to create spaghetti code. The meaning of both segments is pretty clear.

Yes, but these are structured loops. What about conditionals based on equations/formula results by themselves?

Such as IF-THEN-ELSE? These, too, can be constructed using GOTO.

Structured:

Code:

IF b^2-4*a*c>=0 THEN
    PRINT "Roots are real"
ELSE
    PRINT"Roots are imaginary"
END IF

Using GOTO

Code:

IF b^2-4*a*c<0 GOTO A
   PRINT "Roots are real"
   GOTO B
LBL A
   PRINT "Roots are imaginary"
LBL B
   <code continues>

Again, I've over-simplified the example to illustrate my point. If you stick to established constructs,
using GOTO is no worse than structured programming. It's only when you skip around willy-nillly with
no self-discipline that you get into trouble.

As an aside, I'm retired now but I hired over two hundred people to work for me during my career.
I found that, for practical programming, Comp Sci majors make the WORST employees. It seems like their
professors ruined them with their parochial attitude that there's only one right way to do things. Programming
is still an art form no matter what the computer boffins say.
Believe it or not, the best programmers I found were candidates who majored in music!

[teenix]

(05-19-2024 02:38 AM)toml_12953 Wrote:  Believe it or not, the best programmers I found were candidates who majored in music!

Sing a Song of Hexpence

Been watching dads jokes on UTube too long ;-)

[Thomas Klemm]

(05-18-2024 10:25 PM)Matt Agajanian Wrote:  I thought using Go To would just create a confusing path of programming and execution.

We all know what happens to those who use it:

[C.Ret]

I'm worried to see no code and no spagetti although the title of this thread clearly indicates that it is about conditional tests on Ti calculators.

Have all the users of the SR-52, TI-59 and Ti58 been eaten by a Raptor?

[Maximilian Hohmann]

Hello!

(05-20-2024 10:10 AM)C.Ret Wrote:  Have all the users of the SR-52, TI-59 and Ti58 been eaten by a Raptor?

I am still here, although I was an intensive Ti user at that time :-) Honestly, I always considered the automatic renumbering of GOTO lines a very smart feature of Ti's keystroke programming paradigm. Something that I really missed using some implementations of BASIC where you had to manually adjust your GOTO target lines after renumbering. With Ti's calculators, basically every program line can be used as a label. Just like in FORTRAN where you can put a numeric label to any line.

I have worked a lot with legacy software written in FORTRAN that was full of GOTO instructions. Of course it was not as clear as a modern structured code, but I never had any major problem with it. The only feature that caused headaches sometimes were the infamous "computed GOTO" statements that were common in early FORTRAN code. I usually did not touch normal GOTO jumps, but replaced computed GOTOs with IF-THEN-ELSE structures.

By the way: Ti calculators had their own computed GOTO though indirect jumping. E.g. "GTO ind 18" would jump to the line number stored in memory register 18. How smart is that ;-) But I agree that the resulting code might get a little bit hard to understand...

Regards
Max

[Thomas Klemm]

(05-20-2024 10:10 AM)C.Ret Wrote:  Have all the users of the SR-52, TI-59 and Ti58 been eaten by a Raptor?

Not if they paid attention in Mr. Munroe's class:


Bonus points if they used their calculator to find the solutions.

[KeithB]

OTOH:
I got thrown into maintaining a GW-Basic program that's *first line* was a goto 999 or some such, and it got worse from there.

Comparing assembly programming with a high level language is comparing apples and oranges.

I have occasionally used goto in my programming, usually to short circuit something after an error.

I see no problem with local goto's *within* functions, which is all that C allows.

From K&R:
C provides the infinitely-abusable goto statement, and labels to branch to. Formally, the goto is never necessary, and in practice it is almost always easy to write code without it. We have not used goto in this book.

Nevertheless, there are a few situations where gotos may find a place...

[Thomas Okken]

(05-19-2024 02:38 AM)toml_12953 Wrote:  As an aside, I'm retired now but I hired over two hundred people to work for me during my career.
I found that, for practical programming, Comp Sci majors make the WORST employees. It seems like their
professors ruined them with their parochial attitude that there's only one right way to do things. Programming
is still an art form no matter what the computer boffins say.
Believe it or not, the best programmers I found were candidates who majored in music!

I can believe that. In my last job, the style-over-substance attitude ("separation of concerns", which is a type of brain damage invented by Microsoft; and hard-core Agile) was so bad, it made it impossible to write code that was performant enough to meet the users' requirements. The code I had to work on was structured in nine layers, where three would have been the obvious number (UI, business logic, database access), and this organization introduced tons of bugs, while also making it impossible to perform data access efficiently, so queries that could have taken seconds would take many minutes. I tried to explain the problems and their solutions but I couldn't get them to budge.

And I'll never forget the programming assignment in college, that involved writing a loop where a part of the loop body should be skipped on the first iteration. We were using Pascal, so the C-style 'continue' option wasn't available, and I ended up using a goto. When the TA wouldn't allow that, I changed it to use a flag and an 'if' statement. The TA didn't like that either, and it turned out that the reason for his objections was that neither of my solutions could be expressed in a "structure chart," which was the fad at the time (because flowcharts are soooo 1970's, I guess). When I protested that his requirements would force me to duplicate a sizable chunk of program code, and that was horrible in terms of program readability, he relented, but I think that was more because he wanted to get rid of me than me having convinced him.

(05-20-2024 03:54 PM)Maximilian Hohmann Wrote:  

(05-20-2024 10:10 AM)C.Ret Wrote:  Have all the users of the SR-52, TI-59 and Ti58 been eaten by a Raptor?

I am still here, although I was an intensive Ti user at that time :-) Honestly, I always considered the automatic renumbering of GOTO lines a very smart feature of Ti's keystroke programming paradigm. Something that I really missed using some implementations of BASIC where you had to manually adjust your GOTO target lines after renumbering. With Ti's calculators, basically every program line can be used as a label.

The TI's automatically renumbered absolute GTO lines? That is so cool, I never knew that! If I had, I would have felt slightly less smug about my HP-41C. :-D

[Maximilian Hohmann]

Hello,

(05-22-2024 08:29 AM)Thomas Okken Wrote:  The TI's automatically renumbered absolute GTO lines? That is so cool, I never knew that!

Yes, when you use the "Ins" and "Del" keys it adjusts all the GTO numbers :-)
I always preferred the program editing of Ti programs (on these calculators) over Hp because you edit the line visible in the display. You just type over the old contents and see the result immediately. Like with the fullscreen editor of the Commodore PET that was far superior to most line based editors common with computers of that era.

Regards
Max

[Gene]

What the TI models did was this:

Line. Instruction.
050. TAN
051. X>t?
052. GTO
053. 01
054. 00

Which would jump to step 100 if the result of the calculation is greater than the value of the test register.

That’s an absolute jump. If you insert a new step at line 080, the former step 100 is now 101 and the jump will not go to the instruction you want.

Makes absolute jumps difficult to use until your program is debugged,

[Thomas Okken]

(05-22-2024 11:00 AM)Maximilian Hohmann Wrote:  Yes, when you use the "Ins" and "Del" keys it adjusts all the GTO numbers :-)

I just tried it in ti5x, and I don't see GTOs being adjusted by Ins or Del.
Is that a flaw in the simulation?

(05-22-2024 11:00 AM)Maximilian Hohmann Wrote:  I always preferred the program editing of Ti programs (on these calculators) over Hp because you edit the line visible in the display. You just type over the old contents and see the result immediately.

That's not how I remember the TI-58/59. Yes, you do see the line you're about to overwrite; but no, you do not see the result immediately, since the calculator jumps to the next line immediately when you finish typing a command. If you want to visually verify what you just entered, you have to use BST to see it.

[Gene]

Correct Thomas. The TI paradigm was to show the next step rather than the one just entered.

GTO instructions to line numbers are not adjusted when steps are inserted / deleted.

[dm319]

(05-19-2024 02:38 AM)toml_12953 Wrote:  If you stick to established constructs,
using GOTO is no worse than structured programming.

Very true - lots of potential for trouble but it's under your control.

Even with good discipline I find the code on my DM42 somewhat claustrophobic. I suspect due to a lack of white space and indentation.

But even nicer than structured programming, I like the functional style used in R with pipes. Not suitable for everything of course, but great for dealing with lots of data.

[toml_12953]

(05-22-2024 12:47 PM)Thomas Okken Wrote:  

(05-22-2024 11:00 AM)Maximilian Hohmann Wrote:  Yes, when you use the "Ins" and "Del" keys it adjusts all the GTO numbers :-)

I just tried it in ti5x, and I don't see GTOs being adjusted by Ins or Del.
Is that a flaw in the simulation?

You have to use labels to avoid manual adjustment. Direct GTO a step number is faster than to a label. The manual recommends using labels when writing the program but follow each with NOP so that converting to a line number later won't change the size of the program or force recalculation of line numbers. Some calculators search for a label starting at the current position. Forward jumps are faster than backward jumps. Some search from the first step each time. Backward jumps are faster than forward.

[Pierre]

(05-22-2024 12:47 PM)Thomas Okken Wrote:  

(05-22-2024 11:00 AM)Maximilian Hohmann Wrote:  Yes, when you use the "Ins" and "Del" keys it adjusts all the GTO numbers :-)

I just tried it in ti5x, and I don't see GTOs being adjusted by Ins or Del.
Is that a flaw in the simulation?

For TI-58/58c/59 the Ins and Del commands do not recalculate direct addressing (GTO, GSB, DSZ, GE...)
It is therefore preferable to use labels and possibly when the program works it can be optimized by replacing direct addressing with references to labels.
Label analysis is always done from step 000.
For the emulators it is the same except my TI58C programs which recalculates the addresses in case of Ins or Del.
("You are never as well served as by yourself")

[Matt Agajanian]

Hi all.

So that I get the right idea, are you saying that NOP should follow the branching instruction or the Lbl* lnx code or both.

In other words,

x≥t*
ln x
Nop*
…
…
…
Lbl*
lnx
Nop*