TIB: Re: gotos & loops
[Prev][Next][Index][Thread]
TIB: Re: gotos & loops
----- Original Message -----
From: Nuno Sao Joao <nmasj@camoes.rnl.ist.utl.pt>
To: Keller <sandia@rocler.qc.ca>
Sent: 22 May 1999 19:56
Subject: gotos & loops
>
> Hi there!
>
> I'm mailing you personally because I'm not on the list.
>
> >
> > Well, I'm pretty sure you could use a loop but this would really
be
> > one of the rare cases where a 'Goto' is the best way to go. There
is
> > no need for speed, and anyone can figure the code out...
> >
> > How to implement a loop
> >
> > Repeat FlagVar
> > ..
> > ..
> > ..
> > Ask player if he wants to play again
> > If answer is no, FlagVar = 1
> > End
>
> Or slightly better a Repeat-Until, which I think it's
> what you meant
I have a TI-82 and a TI-86, they don't have "Repeat-Until", the
command is "Repeat-End", where it breaks out of the loop when the
argument to "Repeat" evaluates to a non-zero value. All the loops on
the 82,83,85,86 use "End", I'm guessing you use a '92 or an '89.
> repeat
> ...
> ask player and set FlagVar
> until FlagVar = FALSE
>
> This way the test gets nearer to the code where FlagVar is set.
> In the other way you would have to initialize FlagVar before
> the loop, or else it could not do the loop not even once.
Yeah, great principle, but you can't do that with the calcs I have
-( This is how I, and most other people I talked about it to, think
the calculators (82-86) work for loops:
1.The calc reaches the "Repeat <arg>" : <arg> is evaluated. If <arg>
is zero, the calc jumps to the "End" and continues execution after
that. If <arg> is non-zero, the calc goes to the next line.
2. The calc executes whatever is inside the loop
3. End is reached, the calc jumps to the part of the program (memory
address) on the top of the stack, in this case that's #1 again. Then
it all starts again.
> > Simple, but a goto is better... for once!
>
> No it's not. How would you do it with a goto?
>
> labl Again
> ...
> ask player and set FlagVar
> if FlagVar = FALSE then goto NoMore
> goto Again
> labl NoMore
> ...
>
> Isn't this more complicated?
I would do it like this:
Lbl Start:
...
...
On 85 or 86:
Disp "Again?"
Menu(1,"Yes",Start,5,"No",End)
Or 82/83:
Menu("Again?", "Yes", Start,"No",End)
Lbl End
That doesn't really use a Goto, but a Menu command is like jumping to
a label with a goto depending on the user's choice. With a Goto:
Lbl Start:
...
...
do whatever you want to do to set flagvar
If flagvar (If flagvar is not zero)
Goto Start
That's it, and pretty simple, but whatever code you use to set the
flagvar is probably longer than the "Menu" commands (Unless you just
use an "input", but that's ugly...)
BTW: The TI-82 doesn't support multiple character labels or vars, you
must use just one letter or a number. The TI-82 through 86 don't
support boolean data types.
> >
> > The problem with gotos is that people tend to use them for loops
> > instead of For,While, Repeat or they jump from one spot to
another,
> > doing maybe 10 lines at a time, wich slows everything down and
makes
> > the prog impossible to understand
>
> Generally a program with gotos isn't slower than with control
> structures like repeat, etc. In some cases the speed can be
> very slightly better with gotos, never the other way around.
I hate to say it, but you are dead wrong if you're talking about the
82 through 86 calcs. When a goto is reached in a program, the calc
will start searching from the next line for the specified label. If
the end of the program is reached, it starts at the beginning. If the
label isn't found when it returns to the original goto, you get an
error. This causes no problems if you only jump a few lines (it can be
faster, so you're not dead wrong after all. This is because the calc
doesn't have to evaluate any expressions like for a Repeat loop), but
can make a huge difference in speed if you have a large prog. Of
course, in a compiled program (I'm talking about a 'jp' in Z80
assembler, or C on a computer, for example), a goto would be a jump to
a different address, wich is faster than having to evaluate
expressions...
> The only case I know where a goto is better, because of
> readability is where you need to get out of 2 or more nested
> loops, like
>
> repeat
> ...
> for (c....)
> ...
> if .... then
> need to get out of the repeat
> endfor
> until ...
>
> In this case (it's possible to do it without gotos) the best
> solution is to use a goto:
>
> repeat
> ...
> for (c....)
> ...
> if .... then
> goto Out
> endfor
> until ...
> labl Out
On the calcs, this causes a memory leak, worse a double memory
leak!!!!!!
> When we have only a loop, generally the actual programming
> languages offer a statment to get out of a loop. In C it's
> 'break'. So the problem generally only arises when dealing
> with 2 or more nested loops.
The 82-86 calcs don't have a "break" command, so you pretty much would
be forced to use a goto, but you can get around it (to avoid memory
errors) by useing loops with flag vars and if/then/end statements or a
technique I already described more than once on the list wich i would
be glad to explain if you' like.
In Java, you can "break" to labels. There is no "Goto" command (Except
in MS Java, wich I wouldn't touch with a ten-foot pole), so the debate
doesn't arise, to get out of a nested loop, you give the "outside"
loop a label, so that you can break out of it. Now there's a good
solution!!! I don't know C (C++ is next on my list of languages to
learn) but I've heard that using Gotos is discouraged. Here's a Java
example:
first_loop:
for(x=1 ; x < 100 ; x++ )
{
...
Do
{
...
if (condition)
break first_loop;
}
...
} while (condition);
}
You have to remember that TI-Basic is a very limited language, it
isn't always possible to make things as pretty as in Java (or C).
There are very few commands, and subroutines aren't even implemented
(but you can call another program).
> NSJ
A good day to you,
Philipp Keller
NB: All the stuff I said here is about the TI-82 and TI-86
calculators, there a probably some differences for the 89/92, but
untill I buy one of those models, I don't even want to know about
them....
References: