I need the answers to the following questions on my final exam:
1.) What will be the value of the variable intTotalCount when the following code is executed?
For intOuterCount = 1 to 5
For intInnercount = 1 to 4
intTotalCount +=1
Next
Next
2.) How many times will the following loop execute?
For intCount = 10 to 1 Step -2
'Body of loop
Next
3.) A For...Next loop with a beginning value of 1, an eding value of 25, and a Step value of 3 will execute how many times?
4.) A loop's ___________ variable is a numeric variable that keeps track of the number of iterations the loop completes.
And no, I'm not cheating. I'm trying to figure out my score. I already took the exam. :P
Kids these days asking adults to do their homework. :rolleyes:
:P
Quote from: mongers on May 13, 2013, 05:48:24 PM
Kids these days asking adults to do their homework. :rolleyes:
:P
Does it count if I'm just verifying my answers? :unsure:
1) 20
2) 5
3) 9
4) counter?
1) The inner loop statement will execute 20 times, so 20 + the value of intTotalCount before the nested loops.
2) 5 (intCount = [10, 8, 6, 4, 2])
3) 9 (intCount = [1, 4, 7, 10, 13, 16, 19, 22, 25])
4) iteration (There really isn't a single term for this. Iteration, index, and loop variable are the three most common.)
Okay, so I got the first three right. The fourth one is either compound, accumulated, matrix, or control.
Quote from: merithyn on May 13, 2013, 05:59:28 PM
Okay, so I got the first three right. The fourth one is either compound, accumulated, matrix, or control.
Yeah, you should've given us the choices if this was a multiple choice test. There are many right answers to that question. Out of these 4 options, control variable is the answer (though I would argue that it's not really the correct answer to the question given).
I put accumulated, but I think you're right, and it's control. :(
Quote from: DGuller on May 13, 2013, 06:03:07 PM
Quote from: merithyn on May 13, 2013, 05:59:28 PM
Okay, so I got the first three right. The fourth one is either compound, accumulated, matrix, or control.
Yeah, you should've given us the choices if this was a multiple choice test. There are many right answers to that question. Out of these 4 options, control variable is the answer (though I would argue that it's not really the correct answer to the question given).
Agreed. I have seen or heard it referred to as the loop control variable before, but usually by non-programmers.
It's a BS question. Way too much focus in this course on memorizing the correct terminology. If you can get the first 3 questions right and it is clear what you mean it doesn't matter what you call it.
Quote from: Baron von Schtinkenbutt on May 13, 2013, 06:07:04 PM
Quote from: DGuller on May 13, 2013, 06:03:07 PM
Quote from: merithyn on May 13, 2013, 05:59:28 PM
Okay, so I got the first three right. The fourth one is either compound, accumulated, matrix, or control.
Yeah, you should've given us the choices if this was a multiple choice test. There are many right answers to that question. Out of these 4 options, control variable is the answer (though I would argue that it's not really the correct answer to the question given).
Agreed. I have seen or heard it referred to as the loop control variable before, but usually by non-programmers.
Yes, well, I'm not convinced my teacher is a programmer, so it stands to reason. ;)
It's Visual Basic, too, which has odd answers to things. Once I knew what to look up, I was able to find the exact sentence in the book which says that yes, a loop's control variable... etc.
Thanks, guys! I did crap on my exam. :(
Quote from: Maximus on May 13, 2013, 06:10:22 PM
It's a BS question. Way too much focus in this course on memorizing the correct terminology. If you can get the first 3 questions right and it is clear what you mean it doesn't matter what you call it.
It's an Intro to Programming class. Of course it's focusing on getting the terminology right. Even you spend a lot of time correcting my "lingo". I don't begrudge the question, except that I got it wrong. :(
I've used a fair bit of vb before and this inner/outer count stuff is new to me, how odd.
Ah VB...so nice but so useless, which is sad,
Quote from: Tyr on May 13, 2013, 07:07:34 PM
I've used a fair bit of vb before and this inner/outer count stuff is new to me, how odd.
Ah VB...so nice but so useless, which is sad,
Oh? I can see plenty of uses for it.
Quote from: merithyn on May 13, 2013, 06:12:48 PM
It's an Intro to Programming class. Of course it's focusing on getting the terminology right.
Meh.
There's a great deal of lingo defining key concepts shared across pretty much all languages (inheritance, polymorphism, encapsulation, static/dynamic typing, lazy/eager evaluation, lock, exception, actor, object, instance, tail-recursion, heap, stack, lifo, fifo and a million more).
However the one in question is certainly not one of them. Everyone knows what an 'i' is for when they read your code. Nobody will ever give a crap about how you call it.
Quote from: Tyr on May 13, 2013, 07:07:34 PM
Ah VB...so nice but so useless ...
Heh. I've earned my salary writing VB and I can vouch for it being neither nice nor useless.
Quote from: Iormlund on May 13, 2013, 07:34:23 PM
Quote from: Tyr on May 13, 2013, 07:07:34 PM
Ah VB...so nice but so useless ...
Heh. I've earned my salary writing VB and I can vouch for it being neither nice nor useless.
What doing?
I really like VB but have never really gotten much practical usage out of it. I've done some good things with VBA and excel, which I suppose could be useful for heavy duty business work (not really IT), and then there's VB.net which apparently has utility though is a bit platform specific; I was studying that though have decided to give up and transfer over to trying to build up my more mundane web skills.
Quote from: Iormlund on May 13, 2013, 07:34:23 PM
Quote from: Tyr on May 13, 2013, 07:07:34 PM
Ah VB...so nice but so useless ...
Heh. I've earned my salary writing VB and I can vouch for it being neither nice nor useless.
I don't think I've encountered anyone who actually used it before but I agree about it being a horrible language.
Number one seems like a very, very poorly phrased question.
In several languages, "+=" is a shorthand for "var = var + [increment]." However, to use that shorthand, the variable needs to already be initialized.
And yeah, 10, 5, 9, and dunno what to tell you for the fourth- there's a lot of heavy local preference in the jargon: in my program, we almost always referred to that variable as the accumulator. You're more likely to need to know that the process of using those variables is "flow control."
Quote from: Tyr on May 13, 2013, 07:48:56 PM
What doing?
It is used widely as a scripting language for HMI/SCADA platforms - for example in Siemens WinCC/WinCC Flexible range.
My employer also used it in its previous in-house SCADA (which is only now being migrated to VB.NET). We've also used it in the past to develop graphic interfaces to DBs, though we migrated a while ago to Web apps on that front (it's a lot easier when it comes to patching).
I've also used VBA for Excel macros, usually to deliver automated production metrics to customers according to a legacy format.
Quote from: Maximus on May 13, 2013, 07:59:39 PM
I don't think I've encountered anyone who actually used it before but I agree about it being a horrible language.
Never professionally, but it was the second programming language I learned. Having focused heavily on Java in school, I tend to prefer C# for when I need a Microsoft programming language.
Quote from: DontSayBanana on May 13, 2013, 08:23:52 PM
Number one seems like a very, very poorly phrased question.
In several languages, "+=" is a shorthand for "var = var + [increment]." However, to use that shorthand, the variable needs to already be initialized.
That was a different question (which I got right). This was an application question.
Quote from: Tyr on May 13, 2013, 07:07:34 PM
I've used a fair bit of vb before and this inner/outer count stuff is new to me, how odd.
:hmm: You've used a fair bit of vb, and the concept of nested loops is new to you? What exactly did you use it for? :huh:
Hehe.
You know what is funny?
One of the things in software engineering I loved the most in college was the concept of recursion. Just thought it was the coolest thing ever. Yeah, that is pretty geeky. Whatever.
Now, in the real world, I think if I tried to pull some recursion in actual code, most of my peers would have me drowned in a bathtub.
Quote from: DGuller on May 14, 2013, 12:47:06 AM
Quote from: Tyr on May 13, 2013, 07:07:34 PM
I've used a fair bit of vb before and this inner/outer count stuff is new to me, how odd.
:hmm: You've used a fair bit of vb, and the concept of nested loops is new to you? What exactly did you use it for? :huh:
Ack, thought it was a seperate thing ,not just integers with those names (don't you need spaces between int and the names in VB? Its been a while). I've done nested loops of course.
Quote from: Berkut on May 14, 2013, 01:26:35 AM
Hehe.
You know what is funny?
One of the things in software engineering I loved the most in college was the concept of recursion. Just thought it was the coolest thing ever. Yeah, that is pretty geeky. Whatever.
Now, in the real world, I think if I tried to pull some recursion in actual code, most of my peers would have me drowned in a bathtub.
That's my experience as well. In computer science classes, it's cool to make the code as clever and compact as possible, until it's denser than a black hole. In real world, simple is almost always better, especially in my field, where most of the programmers aren't really programmers, but rather applied statisticians that program occasionally.
Quote from: DGuller on May 14, 2013, 02:28:29 AM
Quote from: Berkut on May 14, 2013, 01:26:35 AM
Hehe.
You know what is funny?
One of the things in software engineering I loved the most in college was the concept of recursion. Just thought it was the coolest thing ever. Yeah, that is pretty geeky. Whatever.
Now, in the real world, I think if I tried to pull some recursion in actual code, most of my peers would have me drowned in a bathtub.
That's my experience as well. In computer science classes, it's cool to make the code as clever and compact as possible, until it's denser than a black hole. In real world, simple is almost always better, especially in my field, where most of the programmers aren't really programmers, but rather applied statisticians that program occasionally.
Unless you are trying to get a job at Google or one of the other SV darlings, in which case you need to whip all this shit out again. :P
Quote from: Berkut on May 14, 2013, 01:26:35 AM
Hehe.
You know what is funny?
One of the things in software engineering I loved the most in college was the concept of recursion. Just thought it was the coolest thing ever. Yeah, that is pretty geeky. Whatever.
Now, in the real world, I think if I tried to pull some recursion in actual code, most of my peers would have me drowned in a bathtub.
Recursion's a great way for handling sequences with a known stopping case, but that seems to be the sticking point- most often, programmers are looking for sequential operations where the stopping case is unknown. I suppose it could be a good way to handle parse trees- I'll just have to play with it.
That said, there's a mythical camp out there of people who are very pro-recursion; I have yet to meet one of them.
I use recursion when I need to. It's definitely a case where there are good applications for it and bad, and the wisdom is knowing the difference.
I think the issue is that there really aren't cases where one "needs to" use recursion. You go over the canonical examples in CS classes, but mostly anything you can do with recursion you can do with a iterative loop, and for real world applications, most of the time the iterative loop is going to be a lot clearer to code/debug/understand. Recursion is easy to understand if the problem is simple, but extremely difficult to understand when the problem is complex and it is someone else's solution, and since code maintainability is generally vastly more important than code elegance in almost every typical application, there is generally very little reason to use recursion outside very fundamental examples that are well understood (like sorting algorithms and such).
Quote from: Berkut on May 14, 2013, 10:38:13 AM
I think the issue is that there really aren't cases where one "needs to" use recursion. You go over the canonical examples in CS classes, but mostly anything you can do with recursion you can do with a iterative loop
Not "mostly." Anything.
http://stackoverflow.com/questions/931762/can-every-recursion-be-converted-into-iteration
Quote from: Berkut on May 14, 2013, 10:38:13 AM
most of the time the iterative loop is going to be a lot clearer to code/debug/understand. Recursion is easy to understand if the problem is simple, but extremely difficult to understand when the problem is complex and it is someone else's solution
Nail on the head. Recursion's so unfamiliar to many developers that even ones who can eyeball what an iteration loop is doing need to manually trace recursive calls.
Also, seconded to what Ulmont said. By definition, when you've got a stopping case, there is a finite number of iterations of repeat. Unending loops can be a problem, but an iteration loop can generally be given a much vaguer stopping case.
Biggest problem I see with most developers shying away from recursion is that newer developers end up making way too many of their functions void-typed in strongly-typed languages. Forcing a strict return type makes code a lot more predictable and really discourages the developer from sloppy, over-connected functions.
In general I don't find recursive code difficult to understand, and I'm surprised that that's considered generally true. Well written recursion isn't any more difficult to understand than an iterative loop.
Quote from: frunk on May 14, 2013, 11:10:08 AM
In general I don't find recursive code difficult to understand, and I'm surprised that that's considered generally true. Well written recursion isn't any more difficult to understand than an iterative loop.
Man it was like voodoo the first couple times. I get it now but iterative loops were alot more intuitive.
Recursion becomes difficult to debug and undertand when it is tied into complex code. Throw in persistent object refreshes, maybe some data dumps out to integration sources, even some asynchronous data manipulation and recursion can become nightmarishly difficult to debug.
And lets not even begin talk about mixing recursion with multi-threaded applications.
There is a good reason it is simply not done in most real environments. It simply is not worth it - the cost/benefit is just not there.
Quote from: Berkut on May 14, 2013, 11:45:13 AM
Recursion becomes difficult to debug and undertand when it is tied into complex code. Throw in persistent object refreshes, maybe some data dumps out to integration sources, even some asynchronous data manipulation and recursion can become nightmarishly difficult to debug.
And lets not even begin talk about mixing recursion with multi-threaded applications.
There is a good reason it is simply not done in most real environments. It simply is not worth it - the cost/benefit is just not there.
Those are situations where an iterative loop or recursion are going to be difficult to debug. In both cases you have state changing outside the process and unless you can step through it (or have plenty of debug statements) you don't know what is going on exactly at each iteration/recursion.
Recursion has its place in the real world. It's called a functional language.
It is one of the things that makes Erlang my favorite language. Everything is done via map/fold and recursion. I've got apps thousands of lines long without a single while/for loop. Also, concurrency follows the actor-message model, which makes it a breeze to deal with.
And no, it's not hard to read at all. Once you make the switch, it's just another way of programming.