Related
If you've implemented the Hungarian Method exactly as given in Figure 11-2 of Combinatorial Optimization: Algorithms and Complexity, did you succeed without altering the pseudo-code in any [significant] way? To be specific, I'm referring to the corrected 1998 Dover edition, which is up-to-date with respect to the errata file dated October 2000 given on Steiglitz's website.
An acceptable answer would be along the lines of, "I implemented it, and it works perfectly." Or, "I implemented it, but it needed such-and-such on line so-and-so." In the former case, I'd know to continue the already-extensive delving and debugging of my code. (I'm going to do that anyway, though.) In the latter case, I'd have a bit of insight that might make my own implementation work correctly.
If you've implemented the Hungarian Method, but did not use CO:AaC or did not use C without third-party libraries, you are still more than welcome to offer an answer. In fact, if you're a super-genius who can just examine Figure 11-2 and point out an error of omission or commission by P&S, I'd like to hear from you, and I bet they would, too :-)
Edit: Here's the book on Google Books. For the Hungarian Method, see pages 251-252. For the pseudo-code for the augment() procedure, see page 224. For the explanation of the data structures, see the surrounding pages. Ideally you have the physical book, as the Google Books version is predictably partial.
Update:
After more thorough testing of my implementation and more thorough examination of the book's pseudo-code and text, I think I've resolved some issues with the pseudo-code itself. There were a couple of new errata. I've been in touch with Prof. Steiglitz, who maintains the errata file at his Princeton homepage, and he has said that he will review my notes when he has more time at the end of the semester in December January. (Sorry to anyone who'd been expecting resolution by year's end. I had assumed December was end-of-semester for Princeton, but it's actually January.)
Update:
Prof. Steiglitz has posted my code-&-documentation package to his Princeton webspace. See my answer below for a link.
It's been quite a while since I opened this question, and I haven't heard back from Prof. Steiglitz (which is totally understandable, as I'm sure he's busy virtually 24/7, if not with work then with happier things than verifying some stranger's alleged bugfixes :-) ), so I'm going to go ahead and post my alleged errata that, when accounted for, allow the P&S Figure 11-2 pseudo-code to be implemented to produce correct output.
[...]
And finally, for anyone interested, I've just posted a code-&-documentation package of my own implementation here on share1t.com. (Fair warning: It'll only be up there for 15 days without a download. After that, they take down submitted files.) This package includes a much more readable PDF version (readably and properly typeset with pdflatex) of the errata addendum I give above.
And... I guess that's all. I hope this is useful.
Update:
Prof. Steiglitz has posted my code-&-documentation package at his Publications webpage.
I am reading 'The Little Schemer' in an effort to better understand some of the core elements of programming (namely recursion) and to get more of an idea how to think like a programmer.
The book comes recommended as an entry-level book and the introduction states that all I need to know are English, numbers and counting (which I do).
I am kind of confused though as the first section and questions start off by asking "Is it true that this is an atom?"
Am I missing something? Am I supposed to know what an atom is? I am confused as I thought it was meant to be in more plain English.
Thanks in advance,
Tim
It can be a hard book to get into; it took me two tries separated by about a year. The way you to read it is that you are figuring out these concepts for yourself by listening in on a dialogue between two other people. The first question about a concept will lose you, but the hope is that you say, "Aha! I've figured out the concept they must be talking about" before the end of the questions on a given topic. By the end of the section you'll be answering the questions yourself before reading the answers in the book.
If you hit the end of a section and haven't gotten to that point, start over again but try to give the answers yourself without reading them. When you can supply the answers yourself, you've either figured out the concept in your own terms or memorized the answers in the book. Later sections will refer back to these concepts, though, and will reinforce your understanding.
Think of the student in the book as a proxy for you who seems to begin each section smarter than you, but who you outpace by the end of the section.
The book uses a sort of "constructivist" learning model. It asks you to figure things out before you know the formal definitions. The idea is to develop an intuition before formality (I believe, although that may not be the intention of the authors). You may find this annoying at first, but when you get to the higher-level concepts, you will find yourself understanding things way better than you would from reading R5RS, for example. Continuations had me completely baffled until I read all the way through this book. Stick with it and you'll get why the authors take this approach.
On the left of the page:
"Is it true that this is an atom?
atom"
On the right of the page, 2cm away:
"Yes, because atom is a string of
characters beginning with the letter
a".
And similar questions and answers about atoms in the same format for the remainder of the page. I don't think it takes a genius to work out what is going on here.
An atom in Scheme is like in english, something that you can't divide.
Here are some atoms:
'foo 'bar 'baz 123 '() '+
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I am final year college student. I am trying to figure out how much time i should spend on coding and learning.
while (true) {
learn;
code;
}
I have two friends in my university, both studying media informatics, and both were absolute beginners in programming.
The first one reads a lot at home if he has to learn new languages for a project but has never had a private programming project.
The second one reads a bit but has his own python project. A web application for his friends, where you can bet on soccer results.
Both in comparison:The first guy is slow in programming and always stumble upon simple things and his code can be optimized (in line numbers and comments) at least by 5. And in two days he will stumble upon the same issue again...
The second guy is much faster, can easily read foreign code and languages and stumble upon one problem at most two times, the third time he used what he has learned....
So imho, doing your own project, where you code because you love it, where you work until morning to fix a bug or to finish an implementation, is the very best way to learn!
Surely you've realized that putting a finite measurement on the amount of time you should spend coding, is futile and hugely irrelevant.
Do what you want, but always try and keep up to date.
When I first started programming, it seems that I learn new things by leaps and bounds. Functions, classes, inheritance and etc. But after a while, I realize that you learn by coding. I load myself up with tonnes of reading material - Effective C++, Modern C++, but nothing beats them when I actually sat down and code.
Of course, writing your code the same way over and over again does not make you a better programmer. You have to learn to think - how do I make it reusable? less error prone? portable? immune to changes in other areas of the application? easier to maintain? Is there a better way to do this?
Eventually, the learning peaks, and what you learn are what I like to term as multipliers. It's like knowing that dirname(__FILE__) in PHP returns the current directory which an include file is in. It's like finding out what's a ORM and how by abstracting away the DB you can focus more on the code logic rather than an endless routines of writing INSERTS and UPDATEs SQL statements. It's like learning smart pointers and effective use of STL in C++, using Firebug effectively when doing JavaScript/CSS/HTML...and lots more.
So code; once you get frustrated about something ("There must be a better way to do this than now!"), search for a better way - this is how I learn, anyway.
When I was young:
Monday to Friday, 10am to 7pm, programming in office
Saturday afternoon, reading in Chapters
Monday to Saturday, 9pm to 1am, programming at home
Sunday, drive to downtown and pick up a few books from the bookstore
those were the days when Google was know as nntp
These days:
Monday to Friday, 10am to 7pm, coding in office (too bad I am on web now ;-)
9pm to 1am, coding on my MacBook Air on a few iPhone projects
Saturday and Sunday, coding for another 16 hours
too bad, Google interrupts me too much and I cannot count how many hours are spent on reading blog and pdf books ...
You have to decide that yourself. If you're constantly feeling like you should spend more time coding, then you're probably right. You should never force yourself to the point where the sight of a curly bracket makes you want to puke either. If you're sufficiently interested in programming then the amount of time you spend naturally without slacking off/burning out, will be just fine. (And if you're not, you should cut your losses as soon as possible.)
Be sure that this kind of approach does not make you less valuable of a programmer than the angry nerd in your class who spends every waking hour coding as a part of his masterplan to get back at the world.
the simple answer: do not create some sort of a schedule
why?
you never can know ahead what situation you're in during a certain time, so let's say you set it at everyday at 10am, then suddenly your dog died today at 10am, your family called you to mourn over poor Snuffel...for hours; schedule's all ruined
so what do you do?
code up; if you get tired grab a book or read an article (articles today are really juicy), if you get tired of reading and coding, play games that rattle your brain (yet entertaining, something like Civilizations IV). if you're all rested, fire up your IDE and apply what you just read about. Don't worry if you get it all messy the first time (unless you're a mad genius who certainly will kill himself if he doesn't get something right on his first try).
Note: you should probably set a time for how long you play the game, though:)
My suggestion would be to discover your strengths and if learning is among them, then you may enjoy spending a lot of time learning so do what you want here. Of course one shouldn't go so overboard that things like hygiene get sacrificed, so do try to maintain some basic standard of existing which includes the basics of cleaning your place, yourself, and that kind of thing.
For myself, I'd say that I'm almost always trying to learn something, somewhere. Maybe it is learning about how much patience I have in traffic or how well can I handle this curveball that life has thrown me by my having to do things like income taxes and discover what has changed in the software or tax laws from the previous year. If you look at life as a series of opportunities, you may learn a lot in the world.
In my humble opinion most of the time you are programming. While you program you are learning from experience. This is one type of learning. Another type of learning comes from reading books and other resources (courses, internet, Development conventions). I use books to keep up with technology and to better understand what I am doing. I read almost every day from 0.5-1.0 hour. It depends on your free time and the type of person you are.
Please take into account that there are more ways to learn: code reviews, reading other people's code and I am sure that there are more that I didn't mention here.
Anyway, good luck.
I am guessing the 'learning' here means, acquiring new tips and tricks, grapsing new technology in the market and stay up to date with the trends in technology.
From my experience it is taking around 20% time for learning, and it is mainly because I work on all latest technologies from Microsoft like WPF/Silverlight/Surface. But this % of time will really depends on your personal interest/ organizational interest and the type of career growth you are looking forward to.
And if your job is merely converting domain/business logic to the code which doesn't involve critical technology roadblocks then it might be close to 0% time you need to spend on learning.
Since you didn't present any constraints or conditions in your question then the simplest answer I can give is:
Spend as much as you want.
The very fact you have to ask, might mean you are not ideally matched to writing code. First and foremost you should love coding, and finding out how things work.
This is not a profession where you ever stand still. Totally agree with another poster, in that you should always be looking for a better way, and recognising when there is no better way.
The best software workers - the rockstars if you will - are always on. Any situation can be a teaching. For instance, consider Gregor Hohpe's article Starbucks Does Not Use Two-Phase Commit, in which he analyses how the coffee vendor uses asynchronous processing to maximize throughput of customers' orders.
Coding == Learning
In my opinion.
I started reading Intro to Algorithms by Cormen et al like 3 weeks ago on my free time. I finished the second chapter and have been trying out the exercises for quite a while. I find them a bit difficult.
Is this normal? Should I finish all the exercises before moving on? Or is it alright if I solve the ones I can and move on to the next chapters, possibly coming back to the exercises I can't figure out right now?
If anyone out there has had experience with this book, can you tell me how it was for you? I'm a bit discouraged on not being able to solve quite a few of the exercises here.
That book was hard for me too. We used it at the university I attended and I often had to refer to other sources to get simpler explanations when I found CLRS a little over my head. Once I got the Wikipedia explanation straight in my head, and a code sample working (which CLRS often lacks), I found that I was able to go back to the text and make sense of it.
Don't worry about doing all of the exercises. Even the super-elite MIT students don't have to do them all. Do what you can do and move on. If you need a concept in the next chapter that you had glossed over, it will still be there for you to backtrack to.
MIT OpenCourseWare has also made available the old lectures for Introduction to Algorithms (SMA 5503).
Good for you for diving into CLRS by yourself. You're a braver man than me. I used the book for a grad algorithms course I took last semester, and I had a hard time just finishing the problem sets assigned for the course. Completing all of the exercises would be a truly Herculean effort.
I'd recommend tackling the chapters that interest you most and those that you don't find to difficult. The beginning of the book, if I remember correctly, is one of the harder parts, diving into the mathematical background of a lot of different areas of algorithms. Chapter 5 is especially difficult unless you know a fair bit of probability theory. Also, starred sections and problems are significantly more challenging than the surrounding material (like 21.4, which contains material our professor confessed to being unable to prove in class). Finally at the end of the book, there is just a survey of miscellaneous topics; you can just look at those that interest you, since there are entire books written about each of those topics if you want to learn more about them.
I hope this helps, and most importantly, don't get too discouraged! This is the seminal book on algorithms for a reason.
It's a difficult book, used by one of the pre-eminent technical universities in the world. It's no surprise that it's challenging. There are a LOT of exercises of varying difficulty. It's a noble goal to attempt all of them.
Aren't the course materials on-line? It'd be interesting to see if students taking the course for credit do all the exercises.
I wouldn't be discouraged. Keep plugging, even if you have to pass on some of the exercises. There's nothing saying that you have to master it in one pass, either. Go through, take in what you can, and re-do if necessary. You might find that the extra context helps.
The lectures are available on iTunes if you find that helps.
The important thing is to set a deadline and make steady progress. Good luck.
The problem with not doing all the problems is that when you are self-studying, you really don't have a good gage for how much you should be able to answer.
You can look at the course assignments online, I would recommend that for figuring out problem sets to get done.
I am learning Algorithms on my own from the CLRS book in 2020. Regardless of what people tell you about solutions manuals in general, it is advisable to get "good" solutions manuals if you are self studying with the book.
The two sets of solutions I recommend are (1) The official instructor manual and (2) solutions by Rutger's university students Michelle Bodnar and Andrew Lohr. When one of those solutions is unclear, I simply refer to the other one. If you get stuck at a problem, then give yourself a few minutes to solve it. If you don't get the answer, then use the solutions manuals. You can always test yourself on the problems from other text books or leetcode to see how much you can do on your own vs just following a solutions manual.
I won't post the solutions manuals here. I suggest that you search for them online. The Rutgers one is easily available and is legal. The official one is restricted to instructors only and is hard to get. You might be able to pay obscure online sellers/hackers to get the official one for you. Use a preloaded visa or master card gift card to make that purchase. Make sure that the card is accepted in the sellers country.
Chapter 2 was doable because I used Youtube to understand algorithms and time complexity when it was not clearly explained in the CLRS book, which is quite often. The solutions manuals also helped a little bit.
Chapter 3 is hard and I don't know if I will be able to get past this one. I might have to switch to another book, perhaps the one by Tamassia. I had studied elementary algebra, set theory, functions, probability, mathematical series and calculus a few years ago. But, I remember only a few of those things. So, it is difficult to understand Chapter 3 and move ahead.
In general, it is a comprehensive and rigorous book. However, it is bad because of these:
One-based array indexing (instead of the usual 0-based) - so everytime you translate the algorithm present in the book into code you have to either +1 or -1 and / or use < instead of <= or the other way around and so on.
Bad variable naming in pseudocode - instead of lo, hi or left, right you get p and q.
The fact that is is very rigorous may get you confused in the little details and usually you can miss the overall idea of an algorithm.
It is a famous book because many scientific papers refer to this book in their references.
Otherwise, it is ok.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
One of the companies required from its prospective employee to give the number of lines of code written in the life time in a certain programming language like Java, or C#. Since, most of us have a number of years of experience in different projects in multiple languages and we hardly keep record of this, what would be the best approach to calculate this metrics. I am sure the smart members of stackoverlow.com will have some ideas.
This is a very respected company in its domain and I am sure they have some very good reason to ask this question. But what makes it also difficult to answer is the type of code to consider. Should I only include the difficult algorithm that I implemented or any code I wrote for e.g. a POJO that had 300 properties and whose getters/setters were generated using IDEs!
The best response to such a question is one of the following:
Why do you want to know?
What meaning would you attribute to such a number?
Is it OK if I just up and leave just about now?
I would seriously question the motives behind anyone asking such a question either of current or prospective employees. It is most likely the same type of company that would start doing code reviews focusing on the number of lines of code you type.
Now, if they argue that the number of lines of code is a measure of the experience of a programmer, then I would definitely leave the interview at that point.
Simple solutions can be found for complex problems, and are typically better than just throw enough lines of code at the problem and it'll sort itself out. Since the number of bugs produced scales linearly and above with the number of statements, I would say that the inverse is probably better, combined with the number of problems they've tackled.
As a test-response, I would ask this:
If in a program I am able to solve problem A, B and C in 1000 lines of code, and another programmer solves the same problems in 500 lines of code, which of us is the best (and the answer would be: not enough information to judge)
Now, if you still want to estimate the number of lines, I would simply start thinking about the projects the person has written, and compare their size with a known quantity. For instance, I have a class library that currently ranges about 130K lines of code, and I've written similar things in Delphi and other languages, plus some sizable application projects, so I would estimate that I have a good 10 million lines of code on my own at least. Is the number meaningful? Not in the slightest.
Sounds like this is D E Shaw's questionnaire?
This seems like one of those questions like 'How many ping-pong balls could you fit in a Boeing 747?' In that case, the questioner wants to see you demonstrate your problem solving skills more than know how many lines of code you've actually written. I would be careful not to respond with any criticism of the question, and instead honestly try to solve the problem ; )
Take a look at ohloh. The site shows metrics from open source projects.
The site estimates that 107,187 lines of code corresponds to an effort of 27 Person Years (4000 lines of code per year).
An example of the silliness of such a metric is that the number is from a project I've been toying with outside work during 2 years.
There are basically three ways of dealing with ridiculous requests for meaningless metrics.
Refuse to answer, challenging the questioner for their reasons and explaining why those reasons are silly.
Spending time gathering all the information you can, and calculating the answer to the best of your ability.
Making up a plausible answer, and moving on with as little emotional involvement possible in the stupidity as possible.
The first answers I see seem to be taking the first line. Think about whether you still want the job despite the stupidity of their demands. If the answer is still Yes, avoid number 1.
The second method would involve looking at your old code repositories from old projects.
In this case, I would go with the third way.
Multiply the number of years you have worked on a language by 200 work days per year, by 20 lines of code a day, and use that.
If you are claiming more than one language per year, apportion it out between them.
If you have been working more on analysis, design or management, drop the figure by three quarters.
If you have been working in a high-ceremony environment (defence, medicine), drop the figure by an order of magnitude.
If you have been working on an environment with particularly low ceremony, increase it by an order of magnitude.
Then put the stupidity behind you and get on with your life as quickly as possible
Depending on what they do with the answer, I don't think this is a bad question. For example, if a candidate puts JavaScript on their resume, I want to know how much JavaScript have they actually written. I may ask, for example, for the number of lines in the largest JavaScript project they've written. But I'm only looking for a sense of scale, not an actual number. Is it 10, 100, 1000, or 10,000 lines?
When I ask, I'll make very clear that I'm just looking for a crude number to gauge the size of the project. I hope the employer in the questioner's case is after the same.
It is an interesting metric to ask for considering you could write many many lines of bad code instead of writing just a few smart ones.
I can only assume they are considering more lines to be better than fewer. Would it be better to not plan at all and just start writing code, That would be a great way to write more lines of code, since at least if I do that I usually end up writing everything at least twice.
Smart of stack overflowers would generally avoid organization that ask this kind of question. Unless the correct answer is "huh, wtf??"
If you were to be truly honest then you'd say that you don't know because you have never viewed it as a valid metric. If the interviewer is a reasonable/rational person, then this is the answer they are looking for.
The only other option to saying you don't know is to guess, and that really isn't demonstrating problem solving skills.
Why bother calculating this metric without a good reason? And some random company asking for the metric really isn't a good reason.
If the company's question is actually serious, and you think the interview might lead to something interesting, then I would just pick a random number in order to see where that leads :-)
Ha, reminds me when I took over a C based testing framework, which started out as 20K+
lines that I ended up collapsing into 1K LOC by factoring down to a subroutine instead
of the 20K lines of diarrea code originally written by the original author. Unfortunately,
I got spanked harder for any errors in the code as my KLOC's written actually went
negative... I would think long and hard about shrinking the code base in a metrics driven organization....
Even if I agree with the majority in saying that this is not a really good metric, if it's a serious compmany, as you say, they may have their reasons to ask this.. This is what I would probably do:
Take one of your existing project, get the number of lines and divide it by the time it took you to code it. This will give you a kind of lines per hour metric. Then, try to estimate how many time you have worked with that specific language and multiply it with your already calculated metric. I honestly don't think it's a great way.. but honest, this isn't a great question neither.. I would also tell the company the strategy I used to come up with this number.. maybe, MAYBE, this is what they want.. to know your opinion about this question and how you would answered it? :p
Or, they just want to know if you have some experiences.. so, guess an impressive number and write it down :D
"This is a very respected company in its domain and I am sure they have some very good reason to ask this question"
And I am very sure they don't, because "being respected" does not mean "they do everything right", because this is certainly not right, or if it is, then it's at least dumb in my opinion.
What does count as "Lines of Code"? I estimate that I have written around 250.000 Lines of C# Code, possibly a lot more. The Problem? 95% was throwaway code, and not all was for learning. I still find myself writing a small 3-line program for the tenth time simply because it's easier to write those three lines again (and change a parameter) than go search for the existing ones.
Also, the lines of code means nothing. So I have two guys, one has written 20% more Lines that the other one, but those 20% more were unnecessary complicated lines, "loop-unrolling" and otherwise useless stuff that could have been refactored out.
So sorry, respected company or not: Asking for Lines of Code is a sure sign that they have no clue about measuring the efficiency of their programmers, which means they have to rely on stone-age techniques like measuring the LoC that are about as accurate as calendars in stone-age. Which means it's possibly a good place to work in if you like to slack off and inflate your Numbers every once in a while.
Okay, that was more a rant than an answer, but I really see absolutely no good reason for this number whatsoever.
And nobody has yet cited the Bill Atkinson -2000 lines story...
In my Friday afternoon (well, about one Friday per month) self-development exercises at work over the past year, tests, prototypes and infrastructure included, I've probably written about 5 kloc. However one project took an existing 25kloc C/C++ application and reimplemented it as 1100 lines of Erlang, and another took 15kloc of an existing C library and turned it into 1kloc of C++, so the net is severely negative. And the only reason I have those numbers was that I was looking to see how negative.
I know this is an old post, but this might be useful to someone anyway...
I recently moved on from a company I worked at for roughly 9.5 years as a Java developer. All our code was in CVS, then SVN, with Atlassian Fisheye providing a view into it.
When I left, Fisheye was reporting my personal, total LOC as +- 250,000. Here's the Fisheye description of its LOC metric, including the discussion on how each SVN user's personal LOC is calculated. Note the issues with branching and merging in SVN, and that LOC should usually only be based on TRUNK.