201–210 of 218 posts
Earlier quoted context omitted.
The OP blog-post doesn't really represent it succinctly in C#. This is the most succinct way I could think of: var top = (from w in text.Split(' ') group w by w into g orderby g.Count() descending select g.Key).Take(10);
Though that will result in a lot more calls to Count(). A let would fix that.
Earlier quoted context omitted.
The need for the dictionary shows up when your text gets significantly large. Each call to `words.count` is going to re-examine each word of the text to count 'em up, so, if n is the number of words in the text, and m is the number of distinct words in the text, then this solution is at least O(mn + n log(n)) whereas the dictionary-based solution is O(n log(n)). That is, we're re-reading the word list over and over,…
Isn't the difference between O(mn + nlog(n)) vs O(nlog(n)) running time going to get less significant as the value of n gets larger? I thought the whole point of Big O / asymptotic analysis is that you can ignore lower-order terms and constant factors because they are insignificant for any appreciably large input size. And also because the lower order terms and constant factors vary too much depending on the programm…
At any rate, I wanted to test this out, so I made a naive benchmark for running these functions. The dict solution was ten times faster (0.0011s vs 0.015s) than the list version with ~1350 words. The dict solution ran in 0.13s at ~162,000 words, while I waited a couple minutes before killing the list version on that input.
Earlier quoted context omitted.
For a sys-admin job: tr 'a-z' 'A-Z' | sed 's/[^A-Z][^A-Z]*/\ /g' | grep -v '^$' | sort | uniq -c | sort -nrk1 | head -10 edit: I don't know enough about HN,there should be a newline after the backslash in the sed command.
You can use tr instead of sed and grep, too. Also -k1 and -n 10 are default for sort and head: $ I have a `bins` script that is just `sort | uniq -c | sort -nr`, so that reduces to `tr -cs a-zA-Z '\n' | bins | head`. Unix for Poets, man. It's the shit.
Earlier quoted context omitted.
but seriously, if you're writing c# and not using LINQ all the time You don't sound arrogant, but rather sound naive. I agree that someone who recruits surely should have known about and have experienced LINQ significantly by now, but the notion that you should be using it "all the time" is absolute nonsense. I avoid LINQ. I encourage others to avoid LINQ. It is almost always a sign of bad code. LINQ is syntactical s…
I get what you're saying, I understand it, and I agree with the pitfalls. But I really really really don't agree that one should avoid LINQ. Sure if you don't understand how it works, and how it impact the performance, you should use it less. But don't try and drag the language down because you find it difficult. LINQ is easily one of the best things that have happened to a mainstream language in a long time, and if…
Oh give me a break. My exact complaint about LINQ is the opposite -- that it makes expensive operations seem simple, which with all innovations in language means that mediocre programmers will start abusing it in all codebases.
LINQ has a place. To say that one should be using it "all the time", however, is exactly as I said -- a canary in a coal mine. The only time I've ever come across the extensive use of LINQ it has been in horrific code.
Earlier quoted context omitted.
What are the "concepts I'm criticizing"? I suspect that you have absolutely no idea what the context of my comment was, because your diversion on the topic of functional programming is just grossly out of place. LINQ encourages the belief that set operations are free , such that you no longer have to concern yourself with concepts like memoization or appropriate structures. This has nothing to do with functional prog…
You've actually been pretty vague about the concepts you're criticizing, except for "LINQ". Now I can see you were alluding to just the deferred execution part (the "lack of memoization"). Basically, you're saying it's too easy to accidentally perform a computation twice by iterating through a sequence twice. Recurse on that problem and you get an exponential blowup. That is actually a problem mostly unique to LINQ a…
Earlier quoted context omitted.
What are the "concepts I'm criticizing"? I suspect that you have absolutely no idea what the context of my comment was, because your diversion on the topic of functional programming is just grossly out of place. LINQ encourages the belief that set operations are free , such that you no longer have to concern yourself with concepts like memoization or appropriate structures. This has nothing to do with functional prog…
You've actually been pretty vague about the concepts you're criticizing, except for "LINQ". Now I can see you were alluding to just the deferred execution part (the "lack of memoization"). Basically, you're saying it's too easy to accidentally perform a computation twice by iterating through a sequence twice. Recurse on that problem and you get an exponential blowup. That is actually a problem mostly unique to LINQ a…
Earlier quoted context omitted.
Isn't the difference between O(mn + nlog(n)) vs O(nlog(n)) running time going to get less significant as the value of n gets larger? I thought the whole point of Big O / asymptotic analysis is that you can ignore lower-order terms and constant factors because they are insignificant for any appreciably large input size. And also because the lower order terms and constant factors vary too much depending on the programm…
I'd never heard of Big O until this thread, but from what I can tell it'll only be when a solution is in the O(logn) that "running time will get less significant as n gets larger". This is simply the way you describe logarithmic growth, so maybe that's where you got confused. Also, wouldn't it be fair to say that a logarithm (nlogn) is a lower order term than mn? In which case your definition stands. At any rate, I w…
So, aside from the Clojure, Mathematica, Python, Ruby, Bourne Shell, Haskell, and Scala solutions posted in the other comments, all of which are simpler than the C++, C#, and JS solutions, presented here with some minor cleanups: (take 10 (reverse (sort-by (comp first rest) (frequencies (string/split ... #"\+s")))) ; llambda Clojure // haakon Scala s.split(' ').groupBy(identity).mapValues(_.size).toList.sortBy(-_._2)…
Here's one.
perl -0777 -nE '$w{$_}++ for split; say for (sort {$w{$b} $w{$a}} keys %w)[0..9]'
perl -0777 -nE '$w{$_}++ for split; $, = $"; say((sort {$w{$b} $w{$a}} keys %w)[0..9])'So, aside from the Clojure, Mathematica, Python, Ruby, Bourne Shell, Haskell, and Scala solutions posted in the other comments, all of which are simpler than the C++, C#, and JS solutions, presented here with some minor cleanups: (take 10 (reverse (sort-by (comp first rest) (frequencies (string/split ... #"\+s")))) ; llambda Clojure // haakon Scala s.split(' ').groupBy(identity).mapValues(_.size).toList.sortBy(-_._2)…
So, aside from the Clojure, Mathematica, Python, Ruby, Bourne Shell, Haskell, and Scala solutions posted in the other comments, all of which are simpler than the C++, C#, and JS solutions, presented here with some minor cleanups: (take 10 (reverse (sort-by (comp first rest) (frequencies (string/split ... #"\+s")))) ; llambda Clojure // haakon Scala s.split(' ').groupBy(identity).mapValues(_.size).toList.sortBy(-_._2)…