AP Test's Recursion Examples: An Exercise In Awkwardness 252
theodp writes "Yet another example of how AP exams are loaded with poor coding practices," quipped Alfred Thompson, referring to a recursive code example that prints the numbers 0 to 6, which was posted to the (closed) AP Computer Science Facebook group. "We are often forced to use code examples that are not ideal coding practice," Thompson notes. "We do that to make things clear and to demonstrate specific concepts in a sort of isolation that we might not normally use. We seem to do that a lot with recursion because the examples that require recursion tend to be fairly complex." So, while asking students to use recursion instead of a loop to print '0123456' serves the purpose of teaching recursion, Thompson opines that it's also a poor example of code practice. "Someone raised on functional programming where recursion is a pretty standard way of doing looping might disagree of course," he adds. "There is a saying that when all you have is a hammer all your problems look like nails. This seems, in a way, to be the case with recursion and loops. If your first tool of choice (or what you have learned first) for iteration is loops you tend not to think of recursion as a solution. Similarly if you start with recursion (as is common with functional programming) you are a lot more likely to look at recursion as a tool for iteration." So, do you tend to embrace or eschew recursion in your programming?
What do you expect? (Score:5, Insightful)
A legitimate use of recursion would probably be something a lot more complicated, and a lot harder to grasp, than a contrived use that teaches the concept in isolation. It's like teaching a kid long division using 6000 / 10, and disparaging the example saying, "yeah, but you would never use long division for that." Well, no shit, Sherlock. You're teaching mechanics. Application is for another lesson. Maybe even another class.
Re:What do you expect? (Score:5, Interesting)
It's like teaching a kid long division using 6000 / 10, and disparaging the example saying, "yeah, but you would never use long division for that." Well, no shit, Sherlock. You're teaching mechanics.
But the mechanics of long division in that example are reduced to trivial busywork. That not a complicated enough example to even really see the mechanics properly.
It'd be like using Newton's method on a sample problem that converges to an absolute final answer after a single iteration, or teaching someone how to calculate the area of a trapezoid and using a square as the example problem to solve. Sure the formula works on a square but its not really instructive.
Application is for another lesson. Maybe even another class.
I'd argue that the solution to a problem is a lot easier to understand if you're given a context where the solution is needed FIRST. Starting with a degenerate problem that reduces to a trivial application serves to obscure the 'point' of the solution method.
Re:What do you expect? (Score:5, Insightful)
I'd argue that the solution to a problem is a lot easier to understand if you're given a context where the solution is needed FIRST. Starting with a degenerate problem that reduces to a trivial application serves to obscure the 'point' of the solution method.
This isn't the teaching materials. This is a test question. Yes, the teacher should teach the concept with a better example and explain it fully - but the question is enough to show if the student understands the concept and can apply it correctly. It's also quick to explain and short to answer, both good things for a test question.
This isn't the starting point - this is an ending point. (The end of the class.) The question is enough for that.
Re:What do you expect? (Score:5, Insightful)
This isn't the teaching materials. This is a test question.
Exactly. This question is not asking for an implementation. It is just testing whether recursion is understood well enough to predict the result. This is a good question. Someone with a basic understanding of syntax and recursion would be able to answer the question correctly. Someone without that understanding would not.
Complaining that recursion was used instead of iteration is just silly, since that is not what is being tested. A proper implementation would use neither. If I was tasked with writing a program to list the digits from zero to six, I would write this:
#!/bin/sh
echo "0123456"
Re: (Score:3)
If I was tasked with writing a program to list the digits from zero to six, I would write this:
Sorry, that's an F. You've got a horizontal list there, the end-user wanted a normal-style vertical list instead. Can't you interpret standard specifications correctly???
Off to the short bus!
Re: (Score:2)
This isn't the teaching materials. This is a test question.
You are addressing the original article, and you are right on a test its a perfectly fine question. I agree with your argument.
My post was really just addressing the post I responded too, rather than the original article though, and that was in the context of teaching rather than testing.
Yes, but... (Score:4, Interesting)
Yes, it is a test question. Yes, if you understand recursion, you can answer the question. However, it is poor code, because the recursion is not tail-recursive; anyone who uses recursion with unknown values ('n' in this case) will write a tail-recursive function.
Since it's a totally artificial question, there is no reason that they couldn't have used a tail-recursive function. Lots of students won't know the difference, but crappy code like this is a stumbling block exactly for the students who really do understand what's going on.
Re: (Score:2)
If you have an embedded system that does not have a spare register for couinting but has built-ins for jumps, recursion is faster than iteration. If on the other hand you have built-ins for counting iterations, with a JPNZ, loops are more efficient.
That's really more of a compiler optimization issue.
Re: (Score:2)
Not really. Factorial practically begs for a recursive implementation and it's very simple.
Then there's fibonacci, qsort, etc.
Re: (Score:2)
Re: (Score:2, Insightful)
let fib n = fib_aux n 0 1 where fib_aux n a b | n >= 1 = fib_aux (n-1) b (a+b) | otherwise = b
There you go, linear time, constant space.
And if you'd actually need Fibonaccis, you'd either use a lookup table for limited precision (~50 entries for 32 bit, ~100 for 64) or something like unfolded version of matrix exponentiation for arbitrary precision.
Re: (Score:3)
Not really. Factorial practically begs for a recursive implementation and it's very simple.
Then there's fibonacci, qsort, etc.
Well, they can be done recursively, but their usual definitions imply the simpler iterative approach. Using them leads to the problem that you often see, not just with young students, but even with experienced "professional" programmers: They learn that recursion is just a complex, obscure way to do iteration.
If you actually want to get across why recursion is important, you really should use examples in which recursion gives a simpler solution than iteration. One of my favorites, partly because peopl
Re: (Score:3)
Likewise, whenever anyone brings up design patterns, the go-to pattern is inevitably singleton. Want to find a good design patterns book? Look in the index under
Re: (Score:2)
You can say bad examples are just for teaching materials, but if all students are ever exposed to are bad examples, it's going to be a lot harder for them become good programmers.
Sometimes you start out with a trivial example so students can grasp the concept more quickly, then you increase complexity.
Re: (Score:2)
I myself was taught FORTRAN when I was 14 in a one year high school course. The first grading period we solved problems, wrote algorithms, learne
Re: (Score:3)
Re: (Score:2)
Ah, Ackermann's function, the trusted test of "Do the students understand recursion?" of 1st year university courses everywhere.
Never used recursion (Score:2)
I don't think I've ever user recursion in my professional career. Sure, if I ever need to code a BNF grammar I might, but it's just never come up in the real world.
Re: (Score:2)
Re: (Score:2)
It's ALWAYS a Really Bad Thing "if you can't promise not to wipe out your stack." It's just fine otherwise even for embedded and device drivers as the environment is irrelevant to the issue.
Re: (Score:2, Interesting)
I use recursion in VHDL quite a lot, since functions in that language are completely pure, it is often the right thing to do.
Also when creating hardware there is a step called elaboration, where function are executed (optimised away) before a hardware netlist is created.
Re: (Score:3)
I make a bold claim: all modern compilers have tail recursion optimization implemented
Wow ... that felt good!
Re: (Score:3)
Re: (Score:2)
Is this in fact (reasonably) true? I've shied away from tail recursion, but I'd be pleased to find out that that is no longer necessary.
Re: (Score:2)
I don't agree fully with the post but:
http://c2.com/cgi/wiki?TailRec... [c2.com] gcc does it, LLVM does it. But you certainly can find an obscure not gcc based compiler for a niche processor, OS, that not does it.
Re: (Score:2)
Last I heard (quite some years ago) the JVM didn't do it by default, as it was considered more important to keep stack traces intact. This might have changed now.
Re: (Score:2)
Most of my work is in either embedded systems or Linux device drivers. In both cases recursion is a Really Bad Thing (tm) if you can't promise not to wipe out your stack.
That's on the high-level side of "embedded". When your code is on PROMs, you generally want to favor saving program space over data space.
And not all recursive programming relies on stack either. In low-level programming, you seldom call your recursive function as a self-calling subroutine you have to return through all the layers to get back out of, but one that calls itself using a hard jump. The return will thus always return you to the original caller. Recursive functions then become more like iter
Re: (Score:2)
Re: (Score:3)
I use recursion fairly often for traversing unconstrained trees. Though I'm lazy and never really looked if there was a better way to do it.
"Better" - maybe. Easier - not so much. Recursion is a good way to investigate an issue from a higher perspective w/o having to deal with implementation details, just to get something working. I use it all the time for rapid-prototyping, problem evaluation and double-checking my non-recursive solutions.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
We all use recursion (Score:2)
I don't think I've ever user recursion in my professional career. Sure, if I ever need to code a BNF grammar I might, but it's just never come up in the real world.
Whether you use it or not, recursion plays an increasing role [youtube.com] in our daily lives.
If it weren't for recursion, you wouldn't have that computer! Or that chair you're sitting on. Or that coffee...
Re: (Score:2)
Every time you search a filesystem, it's probably recursion underneath.
There's a reason filesystems have directory nesting limits.
Re: (Score:2)
Never had to walk a tree? Recursion is usually the best solution, unless you're just walking down 1 branch. It's not a frequently used technique, but it's definitely used.
Re: (Score:2)
Re: (Score:3)
That's the real world and real jobs in most cases. Unless you are doing something really high end most jobs are boring straightforward imperative programming. Something like "Scrape a web form on click, put objects into a container, contact the database via a library, do a transaction, get a response, manipulate the response, present the response to the user. Most programmers do not do parallel processing, high end graphics, tool smithing, or predictive analytics.
Most programmers do not use functional langu
Re: (Score:2)
That's the real world and real jobs in most cases. Unless you are doing something really high end most jobs are boring straightforward imperative programming. Something like "Scrape a web form on click, put objects into a container, contact the database via a library, do a transaction, get a response, manipulate the response, present the response to the user. Most programmers do not do parallel processing, high end graphics, tool smithing, or predictive analytics.
Most programmers do not use functional languages either.
I would love to escape that kind of career.
Recursion practicalities (Score:2)
For most stack machines recursion is bad because the stack cannot grow without bounds and you have no idea where that boundary is. That's the practical problem with recursion.
Re: (Score:2)
Re: (Score:2)
(define (showNumbers x output)
(if (zero? x)
ouput
(showNumbers (sub1 x) (concatenate x output ))))
Poor choice for recursion (Score:2)
If something is super fast, the overhead from all the subroutine calls (specifically, the stack manipulation) will make it shit compared to a loop. I think the idea that everything is magical happenings (like idealized math) until late in CS is a definite issue.
Still, for a simple recursive demonstration, that's fine. It would be better to then show which should be looped and which should be recursive. But the fact that you can loop billions of times but I doubt you could recursively call a billion deep
A functional programmer (Score:2)
"Some one raised in functional programming"
Would a) not have combined a recursion with a side-effect, b) we have been sure to make a tail call and c) probably used higher-order functions anyway.
None of which is relevant. This is poor coding style because this is Java which isn't functional and has no tail call optimisation. But, this is a standard problem with assessment; it can be very hard to come up with good and realistic examples, while limited to the knowledge that the students have at the current tim
Re: (Score:2)
Of course Java has tail call/recursion optimization. (*facepalm*)
Re: (Score:2)
Java has facilities that could be used for tail recursion optimization, but Java language implementations aren't required (maybe aren't allowed, due to the language specification) to use it. It's available, but not dependable.
Re: (Score:2)
Nope. It's just not there. I think you mean JVM, anyway, rather than "java language implementation" which is rather ambiguous.
It's not a surprise. Java was never functional. Why have an optimisation which essentially rewrites recursion as a form of iteration, when the programmer is going to use iteration anyway?
This is changing now, I think, that the JVM is becoming more important than Java.
Re: (Score:2)
Strictly, Java would never have TCO. It would have to be the JVM. And, no it doesn't have TCO, although, I do believe that there are plans for it. I don't remember where I read that, so don't quote me.
It is for this reason that, for instance, Scala and Clojure both implement their own limited form of TCO (the self-recursive tail-call), which they do by compiling to an iterative form.
It is easy to demonstrate this with a method that calls itself. In java, it will crash with a stack overflow error. With TCO,
Re: (Score:2)
Actually I'm not sure the compiler/jit knows what to do if the recursive call is unconditional.
This post clearly shows that TRO is pretty simple on JVM bytecode already, so I doubt the Java compiler or JIT does not implement this optimization: http://programmers.stackexchan... [stackexchange.com]
Re: (Score:2)
That TCO is implemented by both Scala and Clojure sort of demonstrates the point really. I mean, why would they bother if the Java Compiler did it already?
In fact, both Scala and Clojure implement it in the same way -- they remove the function (method) recursive call. In otherwords, you see a recursive call in Clojure/Scala but there is not one in the byte code. Method calls in Java consume stack. Try the answer that I gave you earlier. Otherwise, can you please show me the part of the JVM spec which descri
Re: (Score:2)
If you want to abbreviate it, it is TRO, and not TCO. At least the former is the term I learned in school 30 years ago.
I'm uncertain now if the Java compiler does it. However it has absolutely nothing to do with the JVM spec. How do you come to that idea?
I see, drdobbs also uses TCO ... perhaps we have now to cope with two names ;)
I'm pretty sure Java 5 and later Java 6 compilers where supposed to implement TCO. Perhaps it got dropped, did not check that, its a bit difficult on the iPad :) Your link claims
This is a Computer Science Test... (Score:2)
... not a programming test. Recursion is a key concept in CS and is the foundation of many techniques and principles. Sure, no one uses it in practice that often, but that doesn't mean you shouldn't know it if you're learning CS.
If you want to train people for job interviews, send them to a trade program. If you want them to understand the field, you have to teach them the fundamentals.
I never use the central limit theorem directly when doing stats, but knowing how it underlies the methods helps provide a
directory recursion simple example of WHY and how (Score:5, Insightful)
Recursing a directory/folder structure would be a much better example of not only HOW to use recursion, but when and why it actually makes sense.
TFS asks "do you use recursion?". When it makes sense, such a directory or category tree. That is, when the problem is inherently recursive. It's also good to know that all recursive algorithms can be trivially converted to iterative versions with an explicit stack or queue. This is useful for something that could recourse deeply, like following links to spider the web.
Re: (Score:2)
Also, there is an overlap where either iteration or recursion work equally well, and it comes down to preference (clearly the author does not prefer recursion, almost ever, but other people find recursion natural even for iteration. Certainly for mathematicians it is more intuitive than the bizarre syntax of the for() loop that we all had to learn).
except on Windows, Mac, Linux and FreeBSD (Score:3, Informative)
> You never know how deep a directory goes.
On Windows, no more than 130. MAX_PATH is 260, so if directory names are single characters you can have up to 130 of a\b\c\
On Linux, MAX_PATH is typically 4096, so directories can be 2048 deep.
If you're using 16 bytes per level, you know your program won't use more than 16X2048 = 32KB. A maximum 32KB of RAM usage is acceptable on any system running any of the major operating systems.
It wouldn't hurt to check PATH_MAX just to be sure, or put in your own recursi
Re: (Score:2)
... MAX_PATH is 260 ...
and
It wouldn't hurt to check PATH_MAX ...
Recursion error?
depends, symlinks are a file (Score:2)
You should of course decide how to handle symlinks. In most cases I've come across, a symlink is just a file - not something to be followed. Rsync's default behavior is an example of this - it by defaults copies the symlink, rather than recursing into wherever the symlink points. As I recall, tar is the same.
You need to handle symlinks and perhaps bind mounts based of application requirements.
I'm weary of recursion (Score:2)
Normal loops risk never ending.
Loops made by recursion risk ruining your stack to boot.
Recursion is mostly a hobby of mathematicians and in practice is a tool that should be used ultimately sparingly.
Re: (Score:2)
Languages that guarantee tail call optimization won't have a problem implementing an infinite loop using recursion.
Re: (Score:2)
Languages that guarantee tail call optimization won't have a problem implementing an infinite loop using recursion.
Yes but it's all to easy for the unwary to make a small change to the code and now it can't be tail optimized... I don't believe there's any compiler that warns you "hey this is close to being tail optimized but it's not currently".
Re: (Score:2)
Of course, in someplace like Haskell one can just use the "forever" function which loops some action forever rather than implementing an explicit tail-call loop and making sure to get it right. I'm just saying that recursion isn't guaranteed to blow up one's stack in all cases - it's all in the implementation.
Not all in the implementation (Score:3)
it's all in the implementation.
That's what I'm saying though, it's not all in the implementation, tail call recursion relies pretty heavily on the code being set up (and kept up) properly so that it is possible.
Even if the compiler will always tail-optimize calls (lots of languages it will try, but may not) you can always change code such that a method/function that was tail call optimized suddenly cannot be, and the way ALL compilers are right now you will not know such a potentially crucial change has bee
Re: (Score:2)
Writing code such that the last call in the function is always another call to itself isn't some deep mystery, though. The only question is whether the language is guaranteed to optimize that case.
Article misrepresents the test (Score:2)
The minor detail that the bad code uses recursion is irrelevant. And just like I don't learn bad practices from bad code that I see, I don't think anyone would learn bad programming style from this example. Anyone who can figure out what the code does
What's the problem here? (Score:2)
It's an exercise in determining the behavior of the function, not instruction for the right way to achieve what the function does. In the real world, you have to be able to follow sub-optimal code and know what it does. Anybody with the skills to follow this function will know one or more better ways to achieve the same result.
Re: (Score:3)
They're scoring students on their ability to interpret the code correctly, which has nothing to do with whether recursion is the right approach. This is the sort of thing people will see in job interviews: code that you'll never actually see in the real world, with the question what does this do?
Embracing or eschewing recursion (Score:2)
Most programming is mainaining somebody else's, usually poor, code.
Do not use recursion if it makes you feel clever, or if you're showing off your mastery of some programming language's syntax. Don't use recursion for efficiency. Writing efficient code rarely matters. By rarely I'm not saying never!
Use recursion if it results in the most understandable and easy to grasp code for someone, probably currently in junior high, 10-15 years from now.
In 15 years processors, IO, and storage will be many times faster
Re: (Score:2)
Don't use recursion for efficiency.
I don't think it's ever more efficient using recursion instead of loops, it's usually the opposite. With recursion there's an overhead of maintaining the stack, so converting it into a loop makes it more efficient.
Re: (Score:2)
Recursion makes stack handling magically work - with looping the programmer has to keep track of the resulting mess, usually involving arrays of a size not known until after the algorithm completes. Complicated code invites bugs.
Re: (Score:2)
Not someone else, everyone. If I could have a word with my younger self, I'd kick him in the ass.
Awkard? (Score:2)
...use recursion instead of a loop... (Score:2)
The Correct Answer (Score:3)
OutOfMemoryError
Actually in a functional language ... (Score:2)
... you would use a variation of a map function, for-each function or what ever and use a labda or a closure and _not_ recursion.
Re: (Score:2)
Cool. Now someone implemented the forEach function. How did they without imperative loop construct?
Re: (Score:2)
Who cares how it is implemented? As you know we have two options.
My point is: if the assignment is to print either 0...6 or 6..0 then you write something like:
[0..6].each {
print it
}
No one would write a loop here or try to put that away into a recursive function. So if the poster is concerned about 'bad programming habits/examples' he he should not make his claims.
Re: (Score:2)
If I go through college and replace all my assignment with libraries, I'm barely going to have to code. Writing a Chess AI? No one would bother, there's some already implemented. Learning how to write sorts? Pffft.... sort is built in virtually every collection type of all mainstream languages, or at least its in the mainstream libraries. .each is there even in most imperative languages, so you wouldn't be learning for loops either.
Obviously from the article's context, the assigment is to implement it, not
Re: (Score:2)
The original assignment was to use RECURSION! ... it is actually not that hard anyway.
The poster of the article said: this is bad practice! You should use a LOOP.
I say: the poster is an idiot. Especially with his claim regarding functional languages.
Of course in a test you program a recursive function if it is asked for
Recursion examples (Score:2)
Before looking at recursion examples, students should first learn recursion examples.
Re: (Score:2)
The question is actually excellent (Score:3)
This is obviously not an optimal solution to the problem it solves, but it is in fact a fairly compact example that can be used to test whether a student understands recursion and can follow code.
The question isn't whether there is bad code on the exam. This was a great question.
The question is, is there also a question relating to excessive or unbound recursion and what will happen if the number is too big.
What about Big-O notation and algorithmic complexity.
I had to implement a compiler and virtual machine last week because I couldn't find anyone else to do it that was available. This is because not enough people understand topics like recursion.
The teacher who posted the article made it very clear that his competence is limited and he himself is quite slow witted by stating the he found recursion hard to understand at first. Why is this even on Slashdot?
Reminds me of college :) (Score:3)
I was in an economics class with a good friend. The class was given an assignment in which they had to calculate some nonsense. The teacher said that any language code or pseudocode would be fine.
The friend and I were the only engineers in the class and apparently the only ones to use recursion to get to the answer. He used head recursion and I used tail recursion. Everyone else apparently solved it with itterative loops.
The TA knew my friend and I knew each other and threatened to report us for cheating. I told her to go ahead and show our code to the prof or even a CS prof. The logic that my friend and I were so different in the code that the fact that we both used recursion was the only similarity.
We hadn't cheated and kinda thought it was funny that it looked like we did.
Now, I wouldn't be surprised if we got our code scanned into some database and a computer said we cheated and we would have no recourse.
Embrace or avoid? (Score:3)
It's a fucking technology, not a moral decision. You use each when it's appropriate.
Recursion is a tool best used when (a) the design is made more clear by its use and (b) you can afford the stack overflow and/or issues in languages without proper tail call support. For instance, tree search can often be coded much more understandably and with fewer errors with a recursive solution. The same with factorial and other functions defined recursively. Others, not so much - want to dick about with an array? Use an iterative construct, preferably a high-level one, like map/foreach/etc.
I've not actually used recursion in a long time, mainly because most language designers are too fucking lazy these days to put proper tail recursion into their language designs, the higher level functional iteration constructs are becoming available in the languages I'm using, and data's becoming too big.
That question is actually a class of questions (Score:2)
Lack of compiler support !!! (Score:2)
I would use recursion a lot more frequently if compilers supported tail recursion. Not for simple iteration, perhaps, but there are plenty of cases where recursion is a better solution that a loop. For example, recursion is often be appropriate when working through some sort of data structure.
The problem is: The most common languages don't optimize for tail recursion. This means that even shallow recursion will eat memory. If the depth of the recursion is unknown, then the lack of optimization for tail-recu
Re: (Score:3)
For example, recursion is often be appropriate when working through some sort of data structure.
Yes, traversing or pretty-printing a Lua table (which may contain tables itself) is commonly needed and should be easy enough for a beginners’ class
Iff you use Lua of course.
Inherent Conflict in writing vs. reading (Score:4, Insightful)
In the real world it's best to write for a "lowish" common denominator because future staffing is unknown, but best to know HOW to figure out "clever" code if you encounter it. Thus, the best habits for writing code tend to conflict with learning to read any code you may encounter.
The solution is to point out early that writing code is similar to writing documentation: clarity to other readers matters above parsimony etc. Put that on the test.
Fibonaci (Score:2)
I thought it was the law of programming that recursion be introduced with a Fibonacci sequence generator. I believe this AP thing is breaking the law of programming.
umm... (Score:2)
covered already on /. (Score:2)
too many calls (Score:2)
wouldn't:
public void printNumbers (int n) { if (n > 0) printNumber(n-1); System.out.print(n); }
Have been better, ie. shorter, fewer loops (or stack frames if no TCO)
So strange! (Score:5, Insightful)
I mean, this guy really seems not to get that the excercise was not meant to demonstrate how to print 123456, but that printing 123456, as opposed to e.g. 654321 is a tool to demonstrate/show the order of the execution of command in a self-recursive function.
I mean, i have seen bad coding practices in courses (nervous handling of null pointers, and strong binding OOP comes to my mind), but this question has nothing to do with coding, but is purely the shortes way to test is the student understands what happens if the print comes after the call of the self recursive function.
It's a test of reading bad code, not writing it (Score:3)
It's not telling students to use recursion to output that number sequence, it's asking students to read and understand a bit of code that does it. Being able to read and understand other people's badly written code is absolutely essential in todays software industry...
Re: (Score:2)
Has there been a correction in the article? The code in the article now prints i, making it correct.
Re: (Score:2)
(Actually, I do a fair bit of template metaprogramming in C++. It can be handy for a certain class of problem.)
That "certain class of problem" wouldn't happen to be "how to guarantee my continued employment by ensuring that nobody else can understand the codebase", would it? ;^)
Re: (Score:2)
Nah. I often do "back of the envelope" arithmetic operations in my head in less time than it takes to pull out a phone with a calculator app, fire up a laptop, etc. I find it works well when comparing unit costs in the supermarket.
Re: (Score:3)
Re: (Score:2)
A very good point. More than once I have incidents in my career where I have thought to myself "I can be really clever about this." My follow up question is "SHOULD I really be clever ablout this?"
Re: (Score:2)
The integral of e^x^2 from -inf to +inf happens to just as solvable as e^-x^2. Kinda trivially obvious.
Although I could've sworn it's unbounded... need to think about it.