I hate Electrical Engineering courses i have 2 left, need guidance

[mr_coffee]

Hello everyone.

I'm currently a Jr. Computer Engineering student. Its funny, you don't really know what a computer engineer really does until your a Jr. and you've already put 2 years. Ever since I was young I loved to program. I always wanted to be a Software Engineer. So when I graduated Highschool I went to a school that offered Software Engineering.

I'm now at a school that doesn't offer software engineering but offers computer science. They are very similar but software engineering also has some business that CS doesn't have. For some reason I never wanted to be a Computer Scientist becuase it was a lot of algorithm analsysi, and doing math proofs, it seems like a math major to me.

So I took up computer engineering because they can take the exact same courses as a CS but also can do hardware courses where a CS isn't allowed to take them or they can but it won't count towards anything but a general education credit, and they also have to take different maths/physics in order to do this.

So it seems like a CS is like a water downed version of a Computer Engineer. I took a circuit analysis class, with just linear devices and I did alright in it, just took a ton of studying.

But when I got to EE 310, which delt with diods, and non-linear devices i was completely lost. The people in the class were EE's and CE's and they loved it and it was so easy to them while I spent hours and hours trying to figure out 1 problem and failed to get it right. I soon found out I couldn't handle taking that class because i spent all day on it and got no where. So i dropped that class as well as EE317, signals and transforms and systems.

I also have tons of trouble with building a circuit and finding its voltage/current/etc, i have no hands on skills it seems.

But I do enjoy programming as long as it isn't recursion, which is another problem. I suck at recursion. If it isn't recursive I can do great, but i know to be a CS you must be good at all aspects, not just some. Thats another reason I went into Computer ENgineering.

If I understood circuits and how to analyzie a circuit (physically) not on paper, i can do it on paper fine, i would enjoy circuits and CE would really interest me. Because then I could get into robotics.

If I'm really terriable at circuit design, should I not be a Computer ENgineer?
Should I be a CS instead even though i suck at recursion and fall alseep when hearing about how many miliseconds this algorithm is faster than the other, blah.

Thanks!

 

[berkeman]

Have you written a compiler yet? That is one of the more challenging, hands-on programming classes, and it is a good test of whether you can handle and enjoy advanced programming. It sounds like you are headed towards pretty much a straight software career, which is fine. But if you also don't enjoy your compiler class, that may mean that the more complex programming assignments that you could get in the future may be too much for you. If you aced your class where you write a C compiler or whatever language compiler, then you are headed down the right path, IMO.

 

[mr_coffee]

Thats the problem Berkeman, very little CS majors or CE majors will take that Compiler class because it is so advanced and complex. So they just don't take it. Its also not offered until your Senior year, which is alittle late if your going to change a major suddenly.

Thats what scares me, I got straight A's all the way up until now, well i have like a 3.9gpa. But that was all basic programming, like data structures etc. Now we are hitting the core classes and it seems like I can't cut it.

But my friend got an internship (he's a year ahead of me) he was worse at programming than me and he is doing great at his job, programming in java/C/ and somtimes assembly. He doesn't do any hardware at all becuase he didn't like the classses either but he got through them.

 

[0rthodontist]

But I do enjoy programming as long as it isn't recursion, which is another problem. I suck at recursion. If it isn't recursive I can do great, but i know to be a CS you must be good at all aspects, not just some. Thats another reason I went into Computer ENgineering.

It's harder (in my opinion) to write recursively in a functional manner than iteratively, but it can be much neater and in the end once you figure out how to do something right you're more sure that you're correct. I don't think it's something you can decide that you "suck at." It's just a matter of learning. You can get by without thinking recursively in many courses and for many purposes, though it can help a lot especially in algorithms or related courses.

 

[FrogPad]

Sounds like your study habits worked fine until now. Maybe instead of questioning your major, you should look at how the people that are doing well are studying. I know that when I changed to EE from CS, I began to rely on other people much much more. I go to study groups, or start study groups, and try as hard as I can to always stay on the ball. I'm not saying that my study habits are amazing or anything, just that I had to change.

 

[mr_coffee]

Thanks guys. I think I want to be a Computer Scientist...if I switch i will have to pick up a forgien language, take a 2nd part of calc III, and take 2 more stat classes ugh. But I might also loose a lot of scholarship money...I also was accepted into a lot of Engineering Honor societies. If I switch, computer science isn't considered engineering is it? And yet they have a major Software Engineering at a branch campus at Penn State but not at main campus.

FrogPad, I think I would like EE more if I knew how to build a circuit and use like a voltameter and osclascope to analzyise the voltage/current waves.

I got kind of screwed in the introduction to this course EE210, becuase I was the only person in the class, the lab was very weak and I really didn't learn anything hands on, but I got an A- in the class becuase i can analzyie the circuits fine on paper. What did you do to help you make that transitition from CS to EE?Does anyone know how important it is to analzye a circuit and build ciruits like EE's do if your a CE? Do CE's mainly focus on digital design, rather than circuit design? Like more work with VHDL and Verilog rather than the hands on, testing voltage, etc?

I found it odd that they are only offered 3 EE coursees in the whole major, so if the case is I don't have to be super good in those EE courses and just get by then I would pursue the CE degree. But I don't want to get in trouble in upper division classes, as well as out in the job market.

Ortho,

I also got this mind set that recursion is not used in the industry, because its so memory intensive and tons of overhead so it makes me want to not learn it even more but I know i have too becuase I found out a lot of these classes invovle algortihms that invovle recursion, hopefully i can find a good book that explains it rather than giving a few examples using the factorial function and power function.

 

[0rthodontist]

I don't know about use in industry, but it doesn't involve that much overhead. If you're programming in a functional language, i.e. one designed to use recursion, the compiler optimizes away a lot of the function call overhead (in fact a function using tail recursion will be turned into a simple loop). Also, efficiency is not always or even usually a primary concern--more often the problem is first getting the program to work at all, then later optimizing the 10% of code that actually does need to be fast. By the way, some functions might be very slow to calculate using a certain kind of recursion--you may have seen a program involving the fibonacci numbers, for example, that couldn't seem to calculate the 100th one. Don't let that fool you; it's not overhead, just inefficient recursion, and you can get around it.

Why do you need a book on recursion? Do you not understand the basic concept, or do you just want to try more examples until you're more comfortable with it? Have you had a course in functional programming (lisp/haskell/etc)?

 

[Chipset]

If you want to code: go to CS. On job interview they won't ask you whether you can or cannot connect circuit, they will ask (at kewl places like MS or Google) to write simple but algorithmic code and I'm positive that you will meet recursion there.

I also got this mind set that recursion is not used in the industry, because its so memory intensive and tons of overhead so it makes me want to not learn it even more but I know i have too becuase I found out a lot of these classes invovle algortihms that invovle recursion, hopefully i can find a good book that explains it rather than giving a few examples using the factorial function and power function.

This depends on what area you want to go.

What I can say as programmer is that yes, recursion is used. Once you get to more complex concepts and tricks of C++ (like those in Alexandresku), recursion will be like a walk in the park -- you'll be doing template recursion (lottuva fun but mindblowing). But I doubt it is teached in any uni :)

 

[Tony11235]

If you suck at recursion and hate it, how can you possibly be a programmer? How can you possibly program at all? Sorry but it just sounds weird hearing "i don't like recursion" coming from something who wants program and possibly be a computer scientist. Have you not had any functional programming before? Recursion is close to (if not) the heart of computer science IMO.

 

[mr_coffee]

Ortho, I haven’t taken any type of those courses. We had a C++ course, 2 semesters and I’m a jr. and that’s all the programming we had until jr. year which i find odd. They are now changing the curriculum and are doing the following:
C++ for 2 semesters
Java for 1 (UML/OOP)
C for 1 (Systems programming)
before your jr. year.

Which i think is a nice track I think. I'm thinking about retaking C++ (intermediate programming course) on data structures/recursion because i haven’t had this course in almost 3 years. Then take the Java class and C class. I realize this is going to set me back a lot but I'm also minoring in business so perhaps I can work them out.

I had to take a year off of school due to a car wreck which paralyzed me from the chest down. I'm learning to walk again at the same time as doing school so this is also affecting my ability to concentrate on my subjects. It makes school not seem as important as it did before, but the longer I stay out of school the harder its going to be to come back.

The reason I hate recursion is because I don't understand it. Its like anything, if you don't understand it you get frustrated and it makes you dislike the subject (for me anyways). But I enjoy programming still, I like debugging code and getting the program to work and looking at the finished product.

That’s why I have to figure out recursion. I'm not the only student who has had this problem, they wrote a book on how to think recursively to help people like me. Now i just have to e-mail the professor and ask him what it is.

I have troubles figuring out the base case, and then I also have problems even tracing through recursive code. I'm not sure when the function returns the value of itself or in what order it does. I probably just need a detailed trace of a function to help me visual this but I can't seem to find any in the books I’ve read.


Anyone know of any good websites that review recursion in C++? I feel the most comfortable with reading that code but any will do.

thanks!

 

[Chipset]

You came to the right place. I've always wanted to practice my recursion explaining skills on someone.

You do know what function is in C++? Imagine it consists of three parts:

1. Stack -- where function plays with its own things that are allocated locally.
2. Body -- where all the calls are located.
3. Some place to store return and incoming values -- might be in stack but let's imagine it as a different place.

Now let's observe what happens at simple function like this:

int f(void)
{
return someFunc(3);
//basically two pseudo-assembler commands
//move_and_start someFunc(3) ;pseudo1
//grab_return_value_put_it_into_some_place_and_return_to_caller_function ;pseudo2
}

1. Place where someFunc is located is being found.
2. Constant "3" is placed into some predefined place where someFunc's body will understand it.
3. Place to return value is supplied.
4. Place to return led of processor is supplied.
5. Processor is led to beginning of the body of someFunc.
6. Processor returns to pseudo2

Now, what you should grasp is that specific predefined places where function store input/output values are created new for any new instance of program. So running instance of function is determined by location of it's stack.

Let's see what happens in recursive function for goodness' sake already!
Take any recursive function:

//increases any <10 value up to 10
void increaser(int x)
{
//x is copied to specific stack of, hmm, let's call it rb1
//I repeat again that code differs, body does not
if(x<10)
{
x++;
return increaser(x); //key moment
//pseudo1: call of increaser
//pseudo2: returning what came
}
return x;
}

It would be best thing to draw this but since we're in the WWW here, let's go with English sprache.
Let's say increaser was called with value of 8:

increaser(8);

This is what happens (watch carefully each step):

1. Specific stack of increaser is created and 8 is put there: increaser8
2. increaser8 observes 8 and sees that it less than 10.
3.1. increaser8 increases 8 on 1: running value becomes 9
3. increaser9 gives to new stack of increaser two values:
a) analogy of address of pseudo2 in first example, basically returning commands.
b) constant "9" to place where new stacks usually accept input values.

4. increaser9 is accepting two variables.
5. increaser9 checks that 9<10 and increases running value to 10.
6. increaser9 calls increaser10 with value of 10.
7. increaser10 checks 10<10 and finds out that it is false -- WATCH!
8. increaser10 puts 10 to some place where increaser9 would get it out.
9. increaser10 leads processor to increaser9:pseudo2
10.increaser9:pseudo2 does 8-9 to increaser8.
11.increaser8 (as was originally called by main()) returns 10 to main();
12. main returns some value to operating.

What you should understand is how functions pass and return values, once you grasped it, recursion becomes easy. Pass/return was hardest part for me when I learned about recursion.

And some common advice as a programmer. I thought that at least US unis teach practical programming but seems
like they do not. Before you graduate:

a) Find GOOD books on C++, STL and various libraries: Straustrup will go.
b) Choose some good open-source project on sourceforge.net or tigris.org and join it. I was running one but
don't have time now.
c) GET EXPERIENCE.

 

[nikola-tesla]

mr coffee, as you can see as above from chipset there are good people who are willing to help .

I understand you very well, I am a girl in EE and the program is very hard. But, do not give up, you will be fine in your CS major, and do not worry if you are behind just to let you know that in Yugoslavia it takes about 7 yrs to graduate from EE or CS program. And, think of students who came from another countries with no money, poor english language and they start their studies in their 30s and "one day" they (we) will be aOK.

Good luck!

 

[FrogPad]

FrogPad, I think I would like EE more if I knew how to build a circuit and use like a voltameter and osclascope to analzyise the voltage/current waves.

I got kind of screwed in the introduction to this course EE210, becuase I was the only person in the class, the lab was very weak and I really didn't learn anything hands on, but I got an A- in the class becuase i can analzyie the circuits fine on paper. What did you do to help you make that transitition from CS to EE?

Well when I was CS I would spend a LOT of time alone working on coding projects. Part of our CS curriculum was an introductory class to logic design. The class was a weeder course, and was really designed to cut the people who couldn’t hack it out of the curriculum. It also happened to be an EE course.

So I took this class, and was like **** I don’t know if I can make it through this. I had a horrible math background, and the amount of effort that went into writing up the labs was just out of control. So I passed the class and moved back to the CS curriculum, data structures, programming languages, assembly, etc… I did fine in all those classes except for assembly. It was again an EE course that was just killing me with labs, and theory that I would understand, but it just took me friggen FOREVER to actually understand it. I just didn’t understand how people (after seeing exam distributions) would get 98’s or 96’s.

So I did the unthinkable for a CS student, I started asking people if they wanted to get together to study. Well, the people I asked happened to be two brothers that both got high 90’s on their exams. I began to work together with them, and we would just pound through the material together. It worked nicely because we all had our strengths and weaknesses. I was good with the code part of the material, and they were good with relating the material to the hardware, and electrical aspects.

I just realized that I’m writing a short novel here, because I’m really not even close to finishing what I was originally intending to say. Actually I’ll stop here and make another point. Use a checkup device on yourself. See how I just stopped myself from writing a book response to you. This is something I started doing now that I’ve progressed over to EE. I’ll constantly stop myself and be like, “is this a good use of my time?”, “is what I’m doing necessary?”

Anyways…. Back to my original thoughts. I just began to realize, that the people who did consistently well across all their courses, were the ones who were forming study groups, talking with the professors, and/or asking questions in class to clarify something in their notes. And typically those people were usually engineering students.

When I was CS, instead of simply asking someone for help, I would sit there for hours upon hours and try and figure something out. I would eventually get it, but it would take me a long time. If you simply go talk to your professor you can cut out those fruitless hours. It really does all come back to the interjection I made above. If you ask yourself, “is this a good use of my time?” after spending an hour trying to figure something out (that may or may not be in an exam), and the answer is no, then it might be time to ask a person in your class, get on PF, talk to the professor, etc..

So to answer your question, the main thing that changed from CS to EE was this inward to outward progression.

 

[leright]

Well when I was CS I would spend a LOT of time alone working on coding projects. Part of our CS curriculum was an introductory class to logic design. The class was a weeder course, and was really designed to cut the people who couldn’t hack it out of the curriculum. It also happened to be an EE course.

So I took this class, and was like **** I don’t know if I can make it through this. I had a horrible math background, and the amount of effort that went into writing up the labs was just out of control. So I passed the class and moved back to the CS curriculum, data structures, programming languages, assembly, etc… I did fine in all those classes except for assembly. It was again an EE course that was just killing me with labs, and theory that I would understand, but it just took me friggen FOREVER to actually understand it. I just didn’t understand how people (after seeing exam distributions) would get 98’s or 96’s.

So I did the unthinkable for a CS student, I started asking people if they wanted to get together to study. Well, the people I asked happened to be two brothers that both got high 90’s on their exams. I began to work together with them, and we would just pound through the material together. It worked nicely because we all had our strengths and weaknesses. I was good with the code part of the material, and they were good with relating the material to the hardware, and electrical aspects.

I just realized that I’m writing a short novel here, because I’m really not even close to finishing what I was originally intending to say. Actually I’ll stop here and make another point. Use a checkup device on yourself. See how I just stopped myself from writing a book response to you. This is something I started doing now that I’ve progressed over to EE. I’ll constantly stop myself and be like, “is this a good use of my time?”, “is what I’m doing necessary?”

Anyways…. Back to my original thoughts. I just began to realize, that the people who did consistently well across all their courses, were the ones who were forming study groups, talking with the professors, and/or asking questions in class to clarify something in their notes. And typically those people were usually engineering students.

When I was CS, instead of simply asking someone for help, I would sit there for hours upon hours and try and figure something out. I would eventually get it, but it would take me a long time. If you simply go talk to your professor you can cut out those fruitless hours. It really does all come back to the interjection I made above. If you ask yourself, “is this a good use of my time?” after spending an hour trying to figure something out (that may or may not be in an exam), and the answer is no, then it might be time to ask a person in your class, get on PF, talk to the professor, etc..

So to answer your question, the main thing that changed from CS to EE was this inward to outward progression.

I agree with this. While it is great to figure things out on your own (good exercise for your brain) if you're spending 4 or more hours on a single problem or concept then you just need to go get help.

 

[0rthodontist]

I agree with this. While it is great to figure things out on your own (good exercise for your brain) if you're spending 4 or more hours on a single problem or concept then you just need to go get help.

Not in my opinion! The problems that you spend 4 hours or more on are the best ones, and solving these will teach you problem solving skills the best. If you go to the professor for a hint then you lose that. This week I spent 2 days on a single problem, probably 8 hours all told, and I'm glad I did!

 

[leright]

Not in my opinion! The problems that you spend 4 hours or more on are the best ones, and solving these will teach you problem solving skills the best. If you go to the professor for a hint then you lose that. This week I spent 2 days on a single problem, probably 8 hours all told, and I'm glad I did!

There's often too much work to do and you can't waste too much time. Spending 4 hours is long enough on a challenging problem. 8 is way too many. Staring at a piece of paper for 8 hours trying to solve a problem means there's something simple you need to solve the problem that you don't understand.

 

[Corneo]

There's often too much work to do and you can't waste too much time. Spending 4 hours is long enough on a challenging problem. 8 is way too many. Staring at a piece of paper for 8 hours trying to solve a problem means there's something simple you need to solve the problem that you don't understand.

I agree. If it was for only one class that is a different story. But most engineering students are taking several classes so obviously you can't do this for all classes.

 

[0rthodontist]

There's often too much work to do and you can't waste too much time. Spending 4 hours is long enough on a challenging problem. 8 is way too many. Staring at a piece of paper for 8 hours trying to solve a problem means there's something simple you need to solve the problem that you don't understand.

No, it may mean that the problem is just tricky. This particular problem was to show that in an abelian group with cyclic subgroups of order 14 and 10, there is a cyclic subgroup of order 70. I was tired, which may have something to do with it, but in the end the way I solved it was experimenting with Z₇₀ using haskell to find possible generators. It turns out that if a and b are the generators of the subgroups of order 10 and 14, you don't want ab, or a^-1b, you want a²b. Not a problem of not understanding something, as writing the proof once I got a²b only took me a short time, just a matter of doing it the right way. And now, if I had a problem anything like that again, I'd know exactly what to look for. Frequently I get problems that take me a few hours and they are the ones I enjoy and learn the most from.

It's not the only class I'm taking--in fact I had a test in another class the day the problem was due, as well as a troublesome hardware installation that took a few hours--but you can always make time. It's just a matter of being motivated. Challenging homework problems should be motivating.

 

[leright]

No, it may mean that the problem is just tricky. This particular problem was to show that in an abelian group with cyclic subgroups of order 14 and 10, there is a cyclic subgroup of order 70. I was tired, which may have something to do with it, but in the end the way I solved it was experimenting with Z₇₀ using haskell to find possible generators. It turns out that if a and b are the generators of the subgroups of order 10 and 14, you don't want ab, or a^-1b, you want a²b. Not a problem of not understanding something, as writing the proof once I got a²b only took me a short time, just a matter of doing it the right way. And now, if I had a problem anything like that again, I'd know exactly what to look for. Frequently I get problems that take me a few hours and they are the ones I enjoy and learn the most from.

It's not the only class I'm taking--in fact I had a test in another class the day the problem was due, as well as a troublesome hardware installation that took a few hours--but you can always make time. It's just a matter of being motivated. Challenging homework problems should be motivating.

Well, fair enough. For me, if I have to think about a problem for more than 4 hours and can't think of how to do it then I just go to someone for help. 4 hours is a very long period of time. Maybe this is just because of the differences in the nature of the engineering curriculum and the math curriculum...in engineering, there's a large amount of work to do (lab reports, design projects, etc) and there's not enough time to spend 8 hours thinking about a single problem. I don't see anything wrong with asking for some help after spending 4 hours on something. I have an ego, but not THAT much of an ego.

And yes, chellenging problems are motivating, but if it takes you 4 hours to work one problem then your thought process or understanding is lacking and you should get some help.

Now, it's great to think about concepts and whatnot for more than 4 hours, to spend over 4 hours on a single problem seems excessive if it's just a textbook problem. However, if it's a complicated engineering project or something then it isn't out of the ordinary to spend weeks or months on a project.

 

[0rthodontist]

Ortho, I haven’t taken any type of those courses. We had a C++ course, 2 semesters and I’m a jr. and that’s all the programming we had until jr. year which i find odd. They are now changing the curriculum and are doing the following:
C++ for 2 semesters
Java for 1 (UML/OOP)
C for 1 (Systems programming)
before your jr. year.

Which i think is a nice track I think. I'm thinking about retaking C++ (intermediate programming course) on data structures/recursion because i haven’t had this course in almost 3 years. Then take the Java class and C class. I realize this is going to set me back a lot but I'm also minoring in business so perhaps I can work them out.

I had to take a year off of school due to a car wreck which paralyzed me from the chest down. I'm learning to walk again at the same time as doing school so this is also affecting my ability to concentrate on my subjects. It makes school not seem as important as it did before, but the longer I stay out of school the harder its going to be to come back.

The reason I hate recursion is because I don't understand it. Its like anything, if you don't understand it you get frustrated and it makes you dislike the subject (for me anyways). But I enjoy programming still, I like debugging code and getting the program to work and looking at the finished product.

That’s why I have to figure out recursion. I'm not the only student who has had this problem, they wrote a book on how to think recursively to help people like me. Now i just have to e-mail the professor and ask him what it is.

I have troubles figuring out the base case, and then I also have problems even tracing through recursive code. I'm not sure when the function returns the value of itself or in what order it does. I probably just need a detailed trace of a function to help me visual this but I can't seem to find any in the books I’ve read.


Anyone know of any good websites that review recursion in C++? I feel the most comfortable with reading that code but any will do.

thanks!

Well, Chipset has given you one explanation of it from a hardware perspective. I've read that a hardware view can help some people understand recursion, though it's never done much for me (but I learned about recursion before I learned about hardware).

Loosely speaking, recursion allows you to calculate the value of some function, based on some other values of the function. For example you could say
f(n) = f(n-1) + f(n-2)
Here you want to calculate the value of f(n) based on the values of f(n-1) and f(n-2). If you knew f(n-1) and f(n-2), you could easily calculate f(n). Think of them as mathematical functions rather than as program snippets--f takes in a value n, and it returns a value, and does nothing else. f(n) is just a piece of data, as is f(n-1) and f(n-2).

However, calculating f(n) by drawing on f(n-1) and f(n-2) doesn't quite work. When you start calculating f, you generate requests for other values of f--at first you generate f(n-1) and f(n-2), but these will generate requests for other values of the function. Your base cases must ensure that all of these requests eventually get answered definitively. In this case, each time you call the function at a value k you ask for the values of the function at the values k-1 and k-2. So if you tell the compiler what the function evaluates to at two consecutive values (that are less than n), the recursion can't "jump past" them; it has to stop there. Whereas if you told it what the function evaluates to at just one value, say you tell it f(1) = 1, then when it tries to calculate f(2) it will ask for f(1) and also f(0). But it won't know f(0) and your program will run forever looking at f(-1), f(-2), etc. never getting an answer to work with. Your base cases have to act like a safety net or a wall that stops the recursion short and gives it a clear answer. One way to do it is

f(1) = 1
f(2) = 1
f(n) = f(n-1) + f(n-2)

This is valid haskell. Then in the haskell interpreter,
Prelude> f(7)
13

(this is actually pretty inefficient, a problem which can be solved with memoization)

You might look at
http://personal.vsnl.com/erwin/recursion.htm
http://www-128.ibm.com/developerworks/library/l-recurs.html?ca=dnt-624
http://www.cprogramming.com/tutorial/lesson16.html

 

[mr_coffee]

Thanks for the help guys!

Also thanks for taking the time fo wrtie out examples, they seem to make alittle more sense to me but I'm going to go over them agian after my exams are over this week.

 

[chroot]

mr_coffee,

While I can certainly appreciate that you enjoy the creative, free-wheeling side of computer programming -- like spending a couple of days dashing off a simple prototype in a high-level language like Python -- it is an unfortunate truth that most serious projects require a much deeper understanding.

For example, a general principle of computer programming is that 20% of your code consumes 80% of your CPU time. If you are unwilling or unable to sit through the deep, perhaps "painful" experience of optimizing that 20% to eke out every last millisecond of efficiency, you can only aspire to be an entry-level "code grunt" with no real responsibillity.

If the more thorough, theoretical (and imporant!) parts of CS seem very dull or painful to you now, I can only give you a piece of advice that has been proven true again and again in my life: subjects become exponentially more interesting once you really dig into them. I used to think certain fields -- say, computational fluid dynamics -- were just impossibly boring. And then I was "forced" to actually begin using it, and discovered that it's actually deep and fascinating.

You are perhaps just trying to avoid the small, difficult parts because they are difficult, but that attitude will prevent you from ever seeing an entirely different level of "beauty" that transcends the formatting of your source code. The difficult parts are where the real magic, wizardry, and elegance are to be found.

I suggest you take a look at the quicksort algorithm -- there is no more ubiquitous implementation of recursion -- and start working through example sorts with pen and paper until you really understand every single feature of the algorithm. It'll take you, at most, a couple of days, and it will probably ward off all the fears you have of the deep.

- Warren

 

[chroot]

I have to object to this statement:

Recursion is close to (if not) the heart of computer science IMO.

Recursion is best left for those situations where no other solution exists. The very fact that recursion is hard to follow and hard to get just right means an algorithm should not be coded recursively unless there's really just no better way to do it.

I have come across perhaps five situations in my entire programming experience (going on 15 years now) that demanded recursion. It's an interesting academic subject, but you'll want to use it very sparingly in industrial applications.

- Warren

 

[0rthodontist]

If you want to try quicksort, there's no simpler way to look at it than haskell:
quicksort (x:xs) = quicksort [a | a <- xs, a <= x] ++ [x] ++ quicksort [a | a <- xs, a > x]
quicksort [] = []
Read, "quicksort of the head of a list, x, followed by the rest of the list, xs, is the quicksorted list of all elements of xs that are less than or equal to x, followed by x, followed by the quicksorted list of all elements of xs that are greater than x. Also, quicksort of an empty list is the empty list."

Here's a couple of examples I wrote a few days ago when you were asking about powersets

pwrset [] = [[]]
pwrset (x:xs) = pwr ++ map (x:) pwr where
	pwr = pwrset xs
	
cartesianx (a:as) xs = map (\x -> (a, x)) xs ++ cartesianx as xs
cartesianx _ _ = []

Read, "the powerset of an empty list is a list containing the empty list. The powerset of the head of a list x followed by the rest of the list xs, is the powerset of xs followed by the list whose elements are the elements of the powerset of xs, each appended to x."
Read the second one as, "the cartesian product of the head of a list, a, and the rest of the list, as, with another list xs, is the list of all ordered pairs (a, x) where x is in xs, followed by the cartesian product of as with xs. The cartesian product of anything else with anything else is the empty list."

 

[mr_coffee]

Thanks guys i will take a look at those and thanks for the info chroot. I'm infact going to retake, Intermediate programming and data structures, then go onto java OOP programming and then hit up systems programming in C. Then come back to these higher level courses (compiler construction, operating systems, computer graphics, AI, etc) and I bet it will make a whole lot more sense and i'll be able to enjoy it more rather than rushing through college in hope to graduate in 4 years.

Taking that 2 year break really put me out of the mind set of programming, but i think its good in a way becuase now I know i will need to really focus and absorb recursion and not just hope it hits me one day.

Its true, I must embrace all of what CS has to offer and not just ignore somthing I don't understand and write it off.

Thanks for the advice everyone! ;)

 

[Chipset]

mr_coffee, what I'd really advice is to not rely on college courses but rather self-study and work in real projects. Please consider that if you want to be challenging in current conditions you'l have to learn a lot of new technologies by yourself.
College will (should) provide with you solid mathematical basis (something many people are lacking) but specifics you should be ready to tackle by yourself. Book is your best friend.

Recursion is best left for those situations where no other solution exists. The very fact that recursion is hard to follow and hard to get just right means an algorithm should not be coded recursively unless there's really just no better way to do it.

Still, everyone who considers himself some sort of programmer should know how to implement recursion. Beside, recursion looks REALLY KEWL in FOP such as LISP or (new bestseller of year!) Nemerle.

 

[interested_learner]

Get the EE degree

Coding is easy to learn. You don't need a CS degree to code. Get the EE degree. It will open the path to embedded work which is more interesting.

 

[0rthodontist]

Coding is easy to learn. You don't need a CS degree to code. Get the EE degree. It will open the path to embedded work which is more interesting.

Depends on your point of view. Coding is only one thing you learn in a CS degree. AI is far more interesting than embedded systems.

 

[Tony11235]

I have to object to this statement:

Recursion is best left for those situations where no other solution exists. The very fact that recursion is hard to follow and hard to get just right means an algorithm should not be coded recursively unless there's really just no better way to do it.

I have come across perhaps five situations in my entire programming experience (going on 15 years now) that demanded recursion. It's an interesting academic subject, but you'll want to use it very sparingly in industrial applications.

- Warren

I was referring to true computer science and not what people might encounter in industry.

 

[berkeman]

I was referring to true computer science and not what people might encounter in industry.

Fair enough, but I agree with chroot (but then again, we both are deeply embedded in very technical applications of programming and chip design in industry). Recursion is one of the top few causes of very-hard-to-debug stack overflows in embedded microcontroller applications, and I've spent many long late-night and weekend hours debugging problems related to intermittant stack overflows. When I have a choice, I'll avoid recursion. Yeah, it's somewhat of a knee-jerk reaction on my part, but the pain of some of those debug sessions is a pretty big motivation.

And then there's the customer support time us R&D folks have to put into help them debug their embedded application problems, which often are due to programming errors causing stack overflows, which can sometimes be traced to recursion...

Yes, recursion is a beautiful intellectual and academic subject. But in the real world, it's a liability in general IMO. Then again, my manager (whose specialty is in software but he's talented in hardware design) is a big fan of recursion and small code...

 

[0rthodontist]

That's funny, one of the most-touted advantages of functional programming is that it _reduces_ bugs. It's designed to be easier to prove correct. I've seen the claim more than once that once you get past Haskell's compiler type safety errors, you'll often get it right on the first try. It does seem easier to me.

Are the stack overflows you are talking about are specific to some very low-memory devices you are working with and not ordinary problems?