Qbasicnews.com
November 12, 2019, 03:19:19 PM *
Welcome, Guest. Please login or register.

Login with username, password and session length
News: Back to Qbasicnews.com | QB Online Help | FAQ | Chat | All Basic Code | QB Knowledge Base
 
   Home   Help Search Login Register  
Pages: [1] 2
  Print  
Author Topic: Absolute need of goto 4 correct functioning of loop routine.  (Read 12301 times)
Nemesis
Forum Regular
**
Posts: 118



« on: February 02, 2005, 09:54:11 AM »

Common sense programming knowledge tells me this would not be possible, you can always, if you plan it out use an alternative to GOTO to exit or complete a correct funtioning looped routine.
(The term, Correct functioning here means to complete the intended task of the written routine). Now, if nobody can come up with any validated entries, in QB ofcourse... then maybe post a routine which GOTO is the absolute most efficient command to use
in a looping type routine. One thught of GOTO being the most efficient way was na_th_an's post, (I believe it was in the projects section of this forum), about using it to exit a nested loop, instead of perhaps using multiple exit loop commands.
I'll post my entry but, I'll need to dig it up first....

Let the challenge begin!
Logged
Meg
Ancient QBer
****
Posts: 483


« Reply #1 on: February 02, 2005, 11:19:51 AM »

I'm going to go crazy with this GOTO argument.  The fact that people have to try this hard to come up with an example of when GOTO makes sense to use--and then inevitably come up with the same example--speaks volumes to the utility of this command.

Proper code-planning negates the necessity for this command.  GOTO is a logical nightmare to the program-flow; it sections off parts of your flowchart plan from the rest of it by interrupting the program flow and redirecting it to another part of code.

GOTO can be used by a careful coder in very specific instances to replace the logic that can be achieved by other commands whose purpose is to do exactly that, to save you a comparison or two in code segments that are unduly complex, such as a multiple-nested FOR loop with commands immediately following each NEXT statement, so that stacked NEXT isn't possible.  Wow, that was a run-on sentence.  Shocked

So if you write a complex bit of code like this, just to prove to people that GOTO is a "necessary evil", you can do it.  But the code that you'll end up writing is something that is likely unnecessarily complex, and just invented to show off the use of GOTO.

Na_th_an brought up an interesting point in his last post on this subject: use of GOTO to optimize the speed inside a calculation-heavy loop.  I do feel that in most instances, a nested loop structure built around use of GOTO at the exit condition would be better off scrapped, re-planned, and re-written.  But then, I've not written many programs to the levels of complexity that Na_th_an has, so I think his opinions on this topic are likely more valid than my own.

This example, which I keep seeing:

[syntax="QBASIC"]
FOR x1% = 1 TO BigNumber1%
 FOR x2% = 1 TO BigNumber2%
  FOR x3% = 1 TO BigNumber3%
   FOR x4% = 1 TO BigNumber4%
    IF (exitcondition) THEN EXIT FOR
   NEXT x4%
   IF (exitcondition) THEN EXIT FOR
  NEXT x3%
  IF (exitcondition) THEN EXIT FOR
 NEXT x2%
 IF (exitcondition) THEN EXIT FOR
NEXT x1%
[/syntax]

can be simplified to:

[syntax="QBASIC"]
FOR x1% = 1 to BigNumber1%
 FOR x2% = 1 to BigNumber2%
  FOR x3% = 1 to BigNumber3%
   FOR x4% = 1 to BigNumber4%
    IF (exitcondition) THEN EXIT FOR
NEXT x4%, x3%, x2%, x1%
[/syntax]

You can further complicate the already-intimidating structure by throwing in commands between the NEXT list, which renders them unable to stack.  In this case I either: 1. don't use FOR loops, 2. am already using SUBS to block off pieces of logically relevant code (as, at this point, the code is already being rather horrendous) which makes the whole argument a moot point, or 3. trip the exit condition by adjusting the comparison variables inside the inner-most loop.  In fact, I typically prefer these methods to EXIT FOR itself.

Why?  Because when you start a FOR loop, you are writing a looping structure that has a built-in exit condition.  That's what the FOR loop is there for: To execute a piece of code an exact number of times.  When I look at something that says:

Code:
FOR i% = 1 TO 10


I expect the loop to run 10 times, and for i% to equal 11 when it's done.  If you're kicking out of the structure before this exit condition is met--either via GOTO, EXIT, etc--maybe you shouldn't be using a FOR...NEXT loop in the first place.  Personally, I like to see the exit condition of a loop met to make it stop running, if at all possible.

In my experience, I've never encountered a situation where use of GOTO made the most sense.  I've always been able to refactor the program in a more logical way which didn't necessitate use of GOTO.

I find this interesting reading: http://c2.com/cgi/wiki?GotoConsideredHarmful

That example looks familiar. >.>

*peace*

Meg.
Logged
Z!re
*/-\*
*****
Posts: 4599


« Reply #2 on: February 02, 2005, 11:31:09 AM »

Theres some book or whatever, called "Goto considered harmful"

There's also a counter book:
"'Goto considered harmful' considered harmful"

Or something.



1) No matter how you do it, you'll always use GOTO
2) It's not your code
3) You and him are not in some coding group togheter


If your code is only to be viewed by yourself, and perhaps a few others for help, then use whatever you want.

If you are part of a larger group, then code clean, so the other persons can easily get into the code and figure it out.

This whole argument is stupid.

Goto is as valid as using Let, it's just a coding style.
Don't like it, don't bother with it, I don't bother with GOTO code unless it's on a topic that really interesst me (and bowling isnt one of those)

And:
Code:
PRlNT = 100
Code:
LET PRlNT = 100
Code:
PRINT PRlNT
Logged
na_th_an
*/-\*
*****
Posts: 8244



WWW
« Reply #3 on: February 02, 2005, 12:05:08 PM »

Meg, you are still losing my point: optimization. GOTO may be faster. It depends on the kind of coding you are doing.

It looks like I use 20,000 gotos per program, but in fact you can't hardly see more than 1 or 2 per 3,000 lines of code.

It's just that: when you need speed, you can lose a lil' bit of readability.

Plus, seriously, I just didn't know that EXIT FOR exitted all the nested FORs. I thought that it just exited one.

Quote
I expect the loop to run 10 times, and for i% to equal 11 when it's done. If you're kicking out of the structure before this exit condition is met--either via GOTO, EXIT, etc--maybe you shouldn't be using a FOR...NEXT loop in the first place. Personally, I like to see the exit condition of a loop met to make it stop running, if at all possible.


Exactly what I posted in the other post. The correct construction, if you need to exit a FOR loop, is to make a DO:LOOP or a WHILE:WEND with a correct exit condition. My point back there was that breaking from an apparently "closed" structure (a FOR:NEXT is supposed to loop a fixed number of times) with a GOTO or with an EXIT FOR is just the same: bad. The EXIT FOR/WHILE/DO/FUNCTION/SUB/FN stuff is there 'cause some funky thinker in the microsoft team. My point is that breaking from a for loop, sub, function, while... etc is "bad practice" by itself, exactly as bad as using GOTO. Notice that the EXIT blah stuff looks cleaner, but in fact it's the same: you are suddenly breaking from a loop. That's why I didn't understand why you defended EXIT and dismissed GOTO. If you tell me "it's just for cosmetic coding" I have to agree, but logically it's the same.

Why do you want to exit suddenly from inside a loop? for speed. Can it be overcame using structural programming? of course. Is it always slower? not at all, sometimes it will be slower, sometimes it won't. But it may look less readable at times.

For example, you can avoid EXIT FUNCTION using IFs intelligently in your FUNCTION. But it may look bloated. Sometimes placing an EXIT FUNCTION may help you having less code. Sometimes it will look better, sometimes it won't. See what I mean? Readability and cosmetic coding is awesome when you are teaching someone, and I already stated that I'm with you when it comes to show newbies how to code, and that I understand that you may feel with some kind of "responsability" over them, 'cause I've also felt that way sometimes that people have suggested to use GOSUB, inter-module globals or something like that. But when you are coding for yourself, a little bit of dirty optimization can gain you a few more fps Wink

Also, what you say about calling SUBs to isolate logics looks good and organized, but everytime you call a SUB you waste time and memory.

Which such kind of optimization we made our last project from college process a sound signal with a simulated ADSP21 microprocessor take half of the time it took without it. The simolator core is horrid, absolutely ugly, but when you need speed you notice that unrolling loops or replicating code works.

What I mean is that many times we say "GOTO is bad" without stopping a little to think that many of the "alternative features" of QB are as bad... or as good.
Logged

SCUMM (the band) on Myspace!
ComputerEmuzone Games Studio
underBASIC, homegrown musicians
[img]http://www.ojodepez-fanzine.net/almacen/yoghourtslover.png[/i
Meg
Ancient QBer
****
Posts: 483


« Reply #4 on: February 02, 2005, 12:18:15 PM »

I did make note of your optimization argument, above.  Fortunately, I've never had the headache of writing a program that suffered from speed issues to the point that including a GOTO statement would significantly improve speed (but no other refactoring technique could).  But then, I haven't written very many compound/nested loop/command-heavy programs.  I've always found another way.  So I'm not really qualified to comment on using GOTO for optimization.

As far as EXIT FOR: Technically, it transfers program flow ahead to the line immediately following the first NEXT command it encounters.  So if you can stack your NEXT statements, you can EXIT FOR them as a block.

If you are processing commands in between your NEXT statements, then you obviously can't stack them, and therefore you can't EXIT them as a block.  In this instance, I'd either:

1. Set the conditional variable in the inner-most loop, and have it calculate its way out, or

2. Block logically-related inner loops (ones with identical exitcondition) into a SUB, and call the SUB from the outer loop (which we don't want to kick out of).  Then you can terminate the SUB to cease internal loops, and program flow will continue on with the outer loop.

*peace*

Meg.
Logged
na_th_an
*/-\*
*****
Posts: 8244



WWW
« Reply #5 on: February 02, 2005, 12:23:03 PM »

Sorry, Meg, I was editing my post to add some stuff I forgot while you posted yours. Please, I beg you to read the added parts Smiley

The saying isn't false: everyday you go to bed having learnt something new Smiley I didn't know the for stuff at all. Now allowing multiple variables in a NEXT makes sense.
Logged

SCUMM (the band) on Myspace!
ComputerEmuzone Games Studio
underBASIC, homegrown musicians
[img]http://www.ojodepez-fanzine.net/almacen/yoghourtslover.png[/i
Nemesis
Forum Regular
**
Posts: 118



« Reply #6 on: February 02, 2005, 12:57:44 PM »

Quote from: "Meg"
I'm going to go crazy with this GOTO argument.
  The fact that people have to try this hard to come up with an example of when GOTO makes sense to use


Ummm, read the challenge topic again Meg, I said come up with an example of when GOTO is absolutely necessary to use, not when GOTO makes better sense, (a big difference).

Quote


Proper code-planning negates the necessity for this command.  GOTO is a logical nightmare to the program-flow; it sections off parts of your flowchart plan from the rest of it by interrupting the program flow and redirecting it to another part of code.



I'm going to go crazy myself now  Tongue We've all been through this before, hence the reason I proposed this challenge... to maybe prove that GOTO actually has its spot among the legitamite
commands. (Besides the ones which actually aren't legit, eg..LET)


Quote

GOTO can be used by a careful coder in very specific instances to replace the logic that can be achieved by other commands whose purpose is to do exactly that, to save you a comparison or two in code segments that are unduly complex, such as a multiple-nested FOR loop with commands immediately following each NEXT statement, so that stacked NEXT isn't possible.  Wow, that was a run-on sentence.  Shocked


GOTO EXAM #10101001.AAC4...

Get your #2 lead pencils ready...

#1: T or F, goto should never, ever, be used or even discussed?
#2: T or F, goto should only be used in certain coding situations?
#3: T or F, goto should be used as much as any other command?

Too many people with too many contradicting views is what I see :-?

Quote

So if you write a complex bit of code like this, just to prove to people that GOTO is a "necessary evil", you can do it.


Really?
Then lets see your necessary GOTO submission  Cheesy

Quote

 But the code that you'll end up writing is something that is likely unnecessarily complex, and just invented to show off the use of GOTO.


It can be complex, as long as it's less complex than using the supposed innovative, modern, non-spaghetti, clearer, structured
style commands that have made GOTO supposably obsolete in modern programming practices.  :rotfl:

Quote

Na_th_an brought up an interesting point in his last post on this subject: use of GOTO to optimize the speed inside a calculation-heavy loop.  I do feel that in most instances, a nested loop structure built around use of GOTO at the exit condition would be better off scrapped, re-planned, and re-written.  But then, I've not written many programs to the levels of complexity that Na_th_an has, so I think his opinions on this topic are likely more valid than my own.


Yeah but, again it's something that's  been discussed throughly, and a program to that effect wouldn't fit the challenge but, would work for the alternative challenge I mentioned.
(We all could come up with clever code for the second one though.)

Quote


When I look at something that says:

Code:
FOR i% = 1 TO 10


I expect the loop to run 10 times, and for i% to equal 11 when it's done.  If you're kicking out of the structure before this exit condition is met--either via GOTO, EXIT, etc--maybe you shouldn't be using a FOR...NEXT loop in the first place.


Sure, me too, although that's irrelevant...
See that's why I said a looped routine as apposed to a FOR NEXT looped routine. (I wasn't specific because, if you want to try a FOR NEXT loop, then by all means go right ahead  Smiley )


Quote

Personally, I like to see the exit condition of a loop met to make it stop running, if at all possible.


Lost you there...
Don't know if that's what you actually mean but,  I could think of many. (Conventional methods, and must I say, even... GOTO  :lol:)

 
Quote

In my experience, I've never encountered a situation where use of GOTO made the most sense.


You've posted situations, and even are encountering these situations while reading this post  :Huh:
Now you are even contradicting yourself.
You sure you haven't already gone crazy, Meg?

Quote

 I've always been able to refactor the program in a more logical way which didn't necessitate use of GOTO.


Great, then you might be of some use after all for this particular challenge...
When a submission is entered you can see if a more logical or valid way exists, using a method other than GOTO  :bounce:

Quote

I find this interesting reading: http://c2.com/cgi/wiki?GotoConsideredHarmful


I didn't really... just more contradictions.

Anyways, hope I wasn't sounding like a smart-arse, if I did sorry, don't take it personally.

Laters.

Nemesis
Logged
Nemesis
Forum Regular
**
Posts: 118



« Reply #7 on: February 02, 2005, 01:12:15 PM »

Quote from: "na_th_an"
Plus, seriously, I just didn't know that EXIT FOR exitted all the nested FORs. I thought that it just exited one.


Heh, I actually knew that but, somehow forgot about it when I mentioned about na_th_an's example.

Heh, yes I even sometimes find myself... re-learning things.

Good point to mention that Meg  :king:

Cya!


Nemesis
Logged
Meg
Ancient QBer
****
Posts: 483


« Reply #8 on: February 02, 2005, 01:18:39 PM »

<joke>Now, see, Na_th_an and I were having a good discussion about GOTO and you had to go and get all snippy with me.  :D </joke>

I'll be the first one to offer my opinion:  This challenge cannot be done.  Heck, I'll go one step further: I postulate that *NO* command in QB is "necessary" to do a task.
Logged
adosorken
*/-\*
*****
Posts: 3655



WWW
« Reply #9 on: February 02, 2005, 01:21:27 PM »

Oh pulease people...sheesh why didn't I see this post earlier...stop arguing over GOTO already. It's like arguing over religion. :roll:
Logged

I'd knock on wood, but my desk is particle board.
Nemesis
Forum Regular
**
Posts: 118



« Reply #10 on: February 02, 2005, 01:59:14 PM »

Quote from: "adosorken"
Oh pulease people...sheesh why didn't I see this post earlier...stop arguing over GOTO already. It's like arguing over religion. :roll:


Yes, my evil master  :evil:

Please do not punish us  :cry:

Nemesis
Logged
Meg
Ancient QBer
****
Posts: 483


« Reply #11 on: February 02, 2005, 02:29:51 PM »

I thought that Na_th_an and I were doing pretty good at not arguing, honestly.  We were discussing, and considering each others' points--which is a lot more than I can say for most "conversations" I've had about religion.  :barf:

Kudos (M&M ones, in this case) for Na_th_an for approaching this topic with a point of view that is both rational and considerate.  Very mature.

Bah humbug to those that discount the discussion simply because it's on a topic that's been beaten do death by a dead horse with a stick.  Or whatever.

I'm not a big fan of "agreeing to disagree."  I like discussing things that make people reevaluate their stances and opinions; sometimes, it results in advancement.  Sometimes it's the other person's.  Sometimes it's mine.  Often it's both.

In this instance, Na_th_an gets to consider the use of stacking NEXT statements and refactoring code blocks.  I get to consider using GOTO (which I never would have done before) to optimize complex, command-heavy programs for speed.

So, yes, the topic's been covered.  But please don't blow it off unless you see people blindly shouting opinions at each other as facts.  It doesn't advance us.  Cheesy

*peace*

Meg.

edit:  damn, I'm kind of bitchy today.  Shocked   I gotta stop posting.  I don't usually..like..make an issue out of stuff.
Logged
Z!re
*/-\*
*****
Posts: 4599


« Reply #12 on: February 02, 2005, 02:54:50 PM »

Meg, just so you know, I'm gonna quote you forever with:
"been beaten do death by a dead horse with a stick. Or whatever."
 :lol:
Logged
Mac
Senior Member
**
Posts: 243


WWW
« Reply #13 on: February 02, 2005, 04:50:24 PM »

Hi, Meg,

Although I avoid GOTO like the plague, I sometimes find them useful and am not afraid to use them.

Below is a more fair presentation of your code that appears to argue that a single EXIT FOR is the same as a GOTO. Note that it produces
1234444434443434342343434343423...(blah-blah many)...3434

Now substitute GOTO for EXIT FOR and get only 123444443444.

A big difference. So to really exit, you would need three more EXIT FOR statements. Right?

Mac

Code:

PRINT : PRINT
FOR x1% = 1 TO 5
  PRINT "1";
  FOR x2% = 1 TO 5
    PRINT "2";
    FOR x3% = 1 TO 5
      PRINT "3";
      FOR x4% = 1 TO 5
        PRINT "4";
        q = q + 1
        IF q > 7 THEN EXIT FOR
NEXT x4%, x3%, x2%, x1%
Adios:
Logged
Meg
Ancient QBer
****
Posts: 483


« Reply #14 on: February 02, 2005, 05:34:50 PM »

Wow.  You are so right.  I hate to admit it, but I must have made a very bad logical error while testing my stacked NEXT sample.  I've gone back and attempted to duplicate my previous findings, and can not do so.  I'm not sure what was different about my original code.  :oops:

I will add this to my reasons for not wanting to exit prematurely out of FOR / NEXT loops.  I typically don't use EXIT within nested loops (I use EXIT almost exclusively for functions, and within loops, I will alter the conditional variable to set the exitcondition to true).

That being said, if EXIT cannot kick out of nested loops, that does leave GOTO as the only command I can think of that can forward-jump out of nested loops without checking for an exitcondition once per nested loop.  Why you'd want to do this (other than Na_th_an's use for optimizing a program for speed once you've already got it logically coded and working properly), I'm not sure.  After all, you can always set the exitconditions true to exit loops.

It is something to consider though, and I thank you for pointing out my error.  This enlightenment makes my thoughts a lot more similar to Na_th_an's.

*peace*

Meg.
Logged
Pages: [1] 2
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!