It's not recursion. Using the same method name but different parameter types is overloading.
The Builder abstract class just sets up the friendlier append methods (that accept full strings or arbitrary objects instead of just a character) just leaving you to implement what append(char) means. In this case, it's to add to a StringBuffer in a particular way.
0
Options
VerboseThat one guy over there. That guy.Registered Userregular
That problem isn't the issue anymore. Now I and my classmate whom I am discussing it with, are pretty much clueless on the other problem I posted, for a variety of reasons.
I wasn't addressing the problem but your misunderstanding of what recursion is.
That would bite you in the ass big time soon enough.
0
Options
VerboseThat one guy over there. That guy.Registered Userregular
I do get recursion although I would be entirely unsurprised to learn I used a bad example. I'm kind of all over the place right now trying to understand this.
Does the pw.println somehow pass the input through the write method or something?
Yes. The PrintWriter is really handy for this: It breaks down the input string, then runs the writer's write method on the resultant bytes (the default is internally a loop over the array calling the single-byte version - you can find implementations in OpenJDK if you're interested, but it's not needed).
For this problem, concern yourself with overriding the behavior of OutputStream#write(int), with general contract
wrote:
Writes the specified byte to this output stream. The general contract for write is that one byte is written to the output stream. The byte to be written is the eight low-order bits of the argument b. The 24 high-order bits of b are ignored.
Other refs:
PrintWriter#print(String)
Prints a string. If the argument is null then the string "null" is printed. Otherwise, the string's characters are converted into bytes according to the platform's default character encoding, and these bytes are written in exactly the manner of the write(int) method.
OutputStream#(byte[], int, int)
The write method of OutputStream calls the write method of one argument on each of the bytes to be written out. Subclasses are encouraged to override this method and provide a more efficient implementation.
I thought I had a good handle on how to use recursion and what it can do after Programming Foundations II, then I was introduced to Scheme in Programming Paradigms and dynamic programming in Algorithms. Now it just hurts my brain even more.
Recursion is a war crime. Also animal abuse. If the call stack was an animal.
"All men dream, but not equally. Those who dream by night in the dusty recesses of their minds wake in the day to find that it was vanity; but the dreamers of the day are dangerous men, for they may act their dream with open eyes to make it possible." - T.E. Lawrence
need to brush up on algorithms / be able to write some basic pseudocode for an interview
won't need to know in depth technical stuff as it's not a programming position, but technical knowledge is needed
haven't looked at this stuff in a few years, since data structures... where is a good place / what is a good way to review
Assuming you've got some time, this book is just about regarded as the bible for algorithms. For all the algorithms they go over in the book, they give a pseudocode implementation. However, it's a very technical book. And it's like 1300 pages. But, if this is material you've already studied before, it could be a good refresher to skim through to the relevant parts you don't really remember/understand. I say relevant parts, because it's very comprehensive.
It's also a good book just to keep around for referencing.
Thanks for the info guys, I'll see what kind of monstrosity I can hack up. As GnomeTank mentioned, writing a MOBA backend in Javascript will be pretty disgusting. The concept is interesting to me because it allows the use of Javascript on both server and client. Also, I'm curious about the actual performance of Google's V8 engine. I'd better go read that Eloquent Javascript book first, though.
Thanks for the info guys, I'll see what kind of monstrosity I can hack up. As GnomeTank mentioned, writing a MOBA backend in Javascript will be pretty disgusting. The concept is interesting to me because it allows the use of Javascript on both server and client. Also, I'm curious about the actual performance of Google's V8 engine. I'd better go read that Eloquent Javascript book first, though.
Javascript and V8 are very reasonable.
They're not C fast but hey, they are powerful and fast still.
Is anyone familiar with generating PCM sound in Xcode using C? I ask because I've been looking over the api for an hour and feel like I don't know what the hell is going on.
[SIGPIC][/SIGPIC]
0
Options
The AnonymousUh, uh, uhhhhhh...Uh, uh.Registered Userregular
edited February 2012
Today I got to experience the...endless joy...of getting MySQL-python to work on Windows. Since I'm now in a "good" mood, I'm just going to leave these instructions here so nobody else has to waste hours of their time on this shit.
Install MySQL < 6.0. If you get the dreaded error 2003, check your my.ini and make sure the following line is present under [mysqld]:
bind-address = 127.0.0.1
Download the MySQL Connector for C source code, and compile it. You'll need CMake for this. Set it to spit out MSVC projects, because I cannot for the life of me get it to work with MSYS or MinGW; every single platform test will fail if you try.
Manually download and extract MySQL-python, and make the following edits to its build system:
In _mysql.c, comment out the following line:
#include <config-win.h>
In setup_windows.py, set up library_dirs to point to the zlib and libmysql binaries (these were built as part of MySQL Connector). Add msvcrt, zlib and libmysql to libraries.
In site.cfg, make sure that registry_key matches your MySQL major & minor version.
run setup.py --build. If you don't have some flavour of VS2008 installed, the build will break; in that case, either get a hold of it somehow or use --compiler=mingw32 instead. Note that if you use MinGW, recent versions of GCC dropped the --mno-cygwin flag, so you may need to edit cygwinccompiler.py in distutils to remove it.
As GnomeTank mentioned, writing a MOBA backend in Javascript will be pretty disgusting
If it is, it won't be Javascript's fault.
Also, I'm curious about the actual performance of Google's V8 engine. I'd better go read that Eloquent Javascript book first, though.
I'm not familiar with Eloquent Javascript, so it's entirely possible that it's actually a better book, but my recommended reading will (again) be Crockford - Javascript: The Good Parts. It's brief, to the point, for programmers and it does well to introduce some current common practices of writing JS code. It may be about to start getting dated, but I found it exactly what I needed at the time. Very fast, very easy read.
zeeny on
0
Options
jackalFuck Yes. That is an orderly anal warehouse.Registered Userregular
I'm not even sure what node.js is, but if I have gleaned correct information from the context...why on earth would you want to write anything complex and computation heavy like a MOBA backend in JavaScript?
I mean, it looks like it's really just a model...couldn't you make it gobs more efficient with C++, or even a JIT'ed language like C#? Following the same basic model I mean.
Javascript running in Node.js is, as far as I've read, effectively JIT'ed into C++ code
That's what V8 is all about
0
Options
Monkey Ball WarriorA collection of mediocre hatsSeattle, WARegistered Userregular
edited February 2012
Recursion is beautiful, like how math can be sometimes, and anything that can be solved iteratively can also be solved recursively (and vice versa), but iterative code is almost always at least a bit faster than recursive code. You can fake the performance of iteration with tail recursion though. That being said, 95% of the time, if something would be more elegant with recursion, its worth a bit of performance.
edit: Zeeny, after reading half through the first chapter I picked that book up and, yes, this is good stuff. It makes javascript's weirdness make a bit more sense.
Monkey Ball Warrior on
"I resent the entire notion of a body as an ante and then raise you a generalized dissatisfaction with physicality itself" -- Tycho
Recursion is beautiful, like how math can be sometimes, and anything that can be solved iteratively can also be solved recursively (and vice versa), but iterative code is almost always at least a bit faster than recursive code. You can fake the performance of iteration with tail recursion though. That being said, 95% of the time, if something would be more elegant with recursion, its worth a bit of performance.
edit: Zeeny, after reading half through the first chapter I picked that book up and, yes, this is good stuff. It makes javascript's weirdness make a bit more sense.
Depends on the language. For example, in OCaml I often recur over a set of jobs, consuming them until empty. While I could do this with a while loop, doing it with a recursive call lets me use a list instead of a list reference. Mutable data structures are costly, so the recursive approach has a slight edge in that case.
Recursion is beautiful, like how math can be sometimes, and anything that can be solved iteratively can also be solved recursively (and vice versa), but iterative code is almost always at least a bit faster than recursive code. You can fake the performance of iteration with tail recursion though. That being said, 95% of the time, if something would be more elegant with recursion, its worth a bit of performance.
edit: Zeeny, after reading half through the first chapter I picked that book up and, yes, this is good stuff. It makes javascript's weirdness make a bit more sense.
I was on an interview with a company that absolutely hated recursion because it's stack intensive. I think they used fibonacci as an example.
When people unite together, they become stronger than the sum of their parts.
Don't assume bad intentions over neglect and misunderstanding.
0
Options
jackalFuck Yes. That is an orderly anal warehouse.Registered Userregular
That would make me nerd rage so hard. Fibonacci isn't a bad idea because it is hard on stack space (in fact it is linear on stack space). It is bad because it has exponential run time.
0
Options
Monkey Ball WarriorA collection of mediocre hatsSeattle, WARegistered Userregular
edited February 2012
The nieve fibonnaci and factorial recursion are sort of the poster children of why memoization is a good thing. (to be fair, I only remember that term because I'm reading this js book).
Monkey Ball Warrior on
"I resent the entire notion of a body as an ante and then raise you a generalized dissatisfaction with physicality itself" -- Tycho
I'm not even sure what node.js is, but if I have gleaned correct information from the context...why on earth would you want to write anything complex and computation heavy like a MOBA backend in JavaScript?
I mean, it looks like it's really just a model...couldn't you make it gobs more efficient with C++, or even a JIT'ed language like C#? Following the same basic model I mean.
Javascript running in Node.js is, as far as I've read, effectively JIT'ed into C++ code
That's what V8 is all about
The benchmarks I have seen place v8 performance behind pure C++. The issue is how to benchmark a compiled a language to one that does run time optimizations. I expect v8 performance to be really good on heavy branching code that has runtime branch trends.
Monkey Ball WarriorA collection of mediocre hatsSeattle, WARegistered Userregular
Speaking of memoization and javascript, I wrote a node.js program that counts the number of prime factors of a number (duplicates included). This calculation is the core part that ulam spiral genearator I wrote last year in Go.
"I resent the entire notion of a body as an ante and then raise you a generalized dissatisfaction with physicality itself" -- Tycho
That would make me nerd rage so hard. Fibonacci isn't a bad idea because it is hard on stack space (in fact it is linear on stack space). It is bad because it has exponential run time.
Just remember, there is a constant-time approximation of Fibonacci. I hate the example of Fibonacci as a dynamic programming problem, so I memorized the closed form approximation of the function just for interviews.
Just remember, there is a constant-time approximation of Fibonacci. I hate the example of Fibonacci as a dynamic programming problem, so I memorized the closed form approximation of the function just for interviews.
Questions and discussions about Fibonacci are, invariably, not about Fibonacci. Learning closed form approximations is a waste of time. Worse than, in fact, because by giving a sophisticated answer, you're almost certainly missing the point.
Fibonacci is the standard question the interviewer asks where I work, and he laments that nobody, ever, has given what he considers the "right" answer. Which is "well, first I'd write a test". Tests supporting naive recursive Fibonacci are arguably better in the real world than clever closed form approximations - at least then you have a solid base to optimize on, and are only likely to do so when the need becomes apparent.
But because everyone knows Fibonacci so well as an example, they start reeling off how to program it: the question shifts their brain into "Fibonacci mode" instead of "software development" mode. If the question was "How would you program <function you've never seen before>", you'd likely get a much more methodical answer.
Outside of an interview context, is there an application for fast, high-value, accurate Fibonacci numbers? Or is it, as I suspect, just an example?
Just remember, there is a constant-time approximation of Fibonacci. I hate the example of Fibonacci as a dynamic programming problem, so I memorized the closed form approximation of the function just for interviews.
Questions and discussions about Fibonacci are, invariably, not about Fibonacci. Learning closed form approximations is a waste of time. Worse than, in fact, because by giving a sophisticated answer, you're almost certainly missing the point.
Fibonacci is the standard question the interviewer asks where I work, and he laments that nobody, ever, has given what he considers the "right" answer. Which is "well, first I'd write a test". Tests supporting naive recursive Fibonacci are arguably better in the real world than clever closed form approximations - at least then you have a solid base to optimize on, and are only likely to do so when the need becomes apparent.
But because everyone knows Fibonacci so well as an example, they start reeling off how to program it: the question shifts their brain into "Fibonacci mode" instead of "software development" mode. If the question was "How would you program <function you've never seen before>", you'd likely get a much more methodical answer.
Memorizing the closed form approximation is certainly a waste. Even knowing how to derive it is sort of a waste. I just like to have a glib answer to that particular question.
I always thought the best answer to such questions was to say something like, well, it's a dynamic programming problem, so you fill out a table containing answers to the smaller problems, working your way up to the problem you wanted to solve. Generally, any problem which has independent subproblems can be solved this way.
"First I'd write a test" seems like an odd answer to a programming question. You might as well expect someone to say "First I'd open up a buffer" or "First I'd jot down the problem definition on a piece of paper" or "I'd start by turning on the PC". It's so fundamental to the process that it seems like it doesn't need saying.
"First I'd write a test" seems like an odd answer to a programming question. You might as well expect someone to say "First I'd open up a buffer" or "First I'd jot down the problem definition on a piece of paper" or "I'd start by turning on the PC". It's so fundamental to the process that it seems like it doesn't need saying.
Well, it's not a free-form talk about how you'd solve it, it's give you a piece of paper and ask you to implement Fibonacci - and nobody ever writes a test, it's always just the implementation.
And you might say it's so fundamental to the process that is shouldn't need saying - for a lot of people, that's not true.
Then I'd double check to make sure that I was wearing trousers.
You see, by taking the deep breath before the check, I am now able to handle the situation where I am not wearing suitable work attire by just sprinting out of the office and into my car. Without the deep breath, I would be unable to do this as efficiently.
I think this shows that I am capable of forward planning, and also shows respect for the workplace.
jackalFuck Yes. That is an orderly anal warehouse.Registered Userregular
Knowing how to derive fibonacci just means you know college level linear algebra.
Is fibonacci even a good question? Maybe it tells a lot about the programmer.
Recursion: Warning. Just graduated college.
Memoized Recursion: Warning. Functional Programmer.
Iterative: Warning. Either very experienced or completely inexperienced.
Precomputed Lookup Table: Warning. Watch your back. This guy is sneaky.
Posts
The Builder abstract class just sets up the friendlier append methods (that accept full strings or arbitrary objects instead of just a character) just leaving you to implement what append(char) means. In this case, it's to add to a StringBuffer in a particular way.
That would bite you in the ass big time soon enough.
the days before recursion
blew my mind away
Yes. The PrintWriter is really handy for this: It breaks down the input string, then runs the writer's write method on the resultant bytes (the default is internally a loop over the array calling the single-byte version - you can find implementations in OpenJDK if you're interested, but it's not needed).
For this problem, concern yourself with overriding the behavior of OutputStream#write(int), with general contract
Other refs:
E: goddamn automatic quote linking
I'm really liking the new UX/chrome in VS'11.
need to brush up on algorithms / be able to write some basic pseudocode for an interview
won't need to know in depth technical stuff as it's not a programming position, but technical knowledge is needed
haven't looked at this stuff in a few years, since data structures... where is a good place / what is a good way to review
public static MethodInfo[] GetInterfaceMethods (this Type iface, BindingFlags flags) { if (!iface.IsInterface) { throw new ArgumentException ("Type must be an interface", "iface"); } var methods = new List<MethodInfo> (); Action<Type> getInterfaceMethods = null; getInterfaceMethods = t => { methods.AddRange (t.GetMethods (flags)); foreach (var childIface in t.GetInterfaces ()) { getInterfaceMethods (childIface); } }; getInterfaceMethods (iface); return methods.Distinct ().ToArray (); }Assuming you've got some time, this book is just about regarded as the bible for algorithms. For all the algorithms they go over in the book, they give a pseudocode implementation. However, it's a very technical book. And it's like 1300 pages. But, if this is material you've already studied before, it could be a good refresher to skim through to the relevant parts you don't really remember/understand. I say relevant parts, because it's very comprehensive.
It's also a good book just to keep around for referencing.
Thanks for the info guys, I'll see what kind of monstrosity I can hack up. As GnomeTank mentioned, writing a MOBA backend in Javascript will be pretty disgusting. The concept is interesting to me because it allows the use of Javascript on both server and client. Also, I'm curious about the actual performance of Google's V8 engine. I'd better go read that Eloquent Javascript book first, though.
Javascript and V8 are very reasonable.
They're not C fast but hey, they are powerful and fast still.
Give it a go and let us know how it goes!
If it is, it won't be Javascript's fault.
I'm not familiar with Eloquent Javascript, so it's entirely possible that it's actually a better book, but my recommended reading will (again) be Crockford - Javascript: The Good Parts. It's brief, to the point, for programmers and it does well to introduce some current common practices of writing JS code. It may be about to start getting dated, but I found it exactly what I needed at the time. Very fast, very easy read.
Recursion is the best for problems that involve self similar data structures.
For more information read this comment.
Javascript running in Node.js is, as far as I've read, effectively JIT'ed into C++ code
That's what V8 is all about
edit: Zeeny, after reading half through the first chapter I picked that book up and, yes, this is good stuff. It makes javascript's weirdness make a bit more sense.
Depends on the language. For example, in OCaml I often recur over a set of jobs, consuming them until empty. While I could do this with a while loop, doing it with a recursive call lets me use a list instead of a list reference. Mutable data structures are costly, so the recursive approach has a slight edge in that case.
Algorithms by S. Dasgupta, C.H. Papadimitriou, and U.V. Vazirani is the book I used in college and the entire book is online for free at http://www.cs.berkeley.edu/~vazirani/algorithms.html.
I was on an interview with a company that absolutely hated recursion because it's stack intensive. I think they used fibonacci as an example.
Don't assume bad intentions over neglect and misunderstanding.
The benchmarks I have seen place v8 performance behind pure C++. The issue is how to benchmark a compiled a language to one that does run time optimizations. I expect v8 performance to be really good on heavy branching code that has runtime branch trends.
It doesn't have to be amazing. It just has to be better than average.
IMO the computational exhaustion of enforcing game rules for a MOBA game are NOT the problem
The problem is writing javascript on the client that will ferry that data back and forth to the server in a responsible way.
WebSockets is a great tool but it certainly doesn't write the net code for you.
It will demand a brutal crash course in client side prediction
Just remember, there is a constant-time approximation of Fibonacci. I hate the example of Fibonacci as a dynamic programming problem, so I memorized the closed form approximation of the function just for interviews.
Fibonacci is the standard question the interviewer asks where I work, and he laments that nobody, ever, has given what he considers the "right" answer. Which is "well, first I'd write a test". Tests supporting naive recursive Fibonacci are arguably better in the real world than clever closed form approximations - at least then you have a solid base to optimize on, and are only likely to do so when the need becomes apparent.
But because everyone knows Fibonacci so well as an example, they start reeling off how to program it: the question shifts their brain into "Fibonacci mode" instead of "software development" mode. If the question was "How would you program <function you've never seen before>", you'd likely get a much more methodical answer.
Outside of an interview context, is there an application for fast, high-value, accurate Fibonacci numbers? Or is it, as I suspect, just an example?
Memorizing the closed form approximation is certainly a waste. Even knowing how to derive it is sort of a waste. I just like to have a glib answer to that particular question.
I always thought the best answer to such questions was to say something like, well, it's a dynamic programming problem, so you fill out a table containing answers to the smaller problems, working your way up to the problem you wanted to solve. Generally, any problem which has independent subproblems can be solved this way.
"First I'd write a test" seems like an odd answer to a programming question. You might as well expect someone to say "First I'd open up a buffer" or "First I'd jot down the problem definition on a piece of paper" or "I'd start by turning on the PC". It's so fundamental to the process that it seems like it doesn't need saying.
And you might say it's so fundamental to the process that is shouldn't need saying - for a lot of people, that's not true.
How would you perform an interview?
Well first I would take a breath...
You see, by taking the deep breath before the check, I am now able to handle the situation where I am not wearing suitable work attire by just sprinting out of the office and into my car. Without the deep breath, I would be unable to do this as efficiently.
I think this shows that I am capable of forward planning, and also shows respect for the workplace.
Is fibonacci even a good question? Maybe it tells a lot about the programmer.
Recursion: Warning. Just graduated college.
Memoized Recursion: Warning. Functional Programmer.
Iterative: Warning. Either very experienced or completely inexperienced.
Precomputed Lookup Table: Warning. Watch your back. This guy is sneaky.