In other news, Buggy Whip Owner Considers Cars Harmful (Possibly Evil).
Does anyone know of a way to just turn this off entirely? I already have things organized by directory/filename. From what I can tell, the current 'solution' is to manually go through each file and fix whatever stupid information was auto-detected. Which is backwards, because if someone's anal enough to deal with that, they've likely already got things meticulously organized how they want by directory/filename, so why not just go by that directly?
I get the strong impression that they didn't really make local media playback a priority.
They could work out a process for developers who want to contribute GPLed apps, but they've decided not to.
Let's say you've got two lists, named "A" and "B", which each have 1000 integers. You want to return a list of unique integers which are present in both lists (ie the intersection of two lists). These 'lists' could be arrays or linked lists.
The brute force method would be something like this:
Out = []
for a in A:
for b in B:
if a == b and !Out.contains(b)://O(n) list search
Out.append(b)
return Out
But this can be very slow, because you can end up in the territory of O(n^3) iterations across A, B, and Out (internally the language would generally be iterating across Out in order to complete that 'contains' call). In this specific example, that works out to be something along the lines of 1000x1000x1000 = 1000000000 iterations, vastly larger than the size of the original lists.---
A better way is to sort one or both of the lists then do the comparisons along each of them (this syntax assumes the lists are specifically arrays, but it'd effectively be the same for linked lists):
Out = []
sort(A)
sort(B)
b = 0
for a in xrange(len(A)):
vala = A[a]
valb = B[b]
if vala == valb:
Out.append(vala)
++a
++b
elif vala < valb:
++a
else://vala > valb
++b
return Out
This is definitely better than the above example. Now we're performing two sorts, each O(n log n), then we're doing a linear iteration across both of those lists in parallel, each O(n). So now we end up with an overall complexity of O(n log n) as a result of those initial sorts. Let's estimate the total number of iterations to be around, I dunno, 10000(sort)+2000(iterate/compare) = 12000? The exact number of comparisons in a sort can vary by algorithm used and how things were ordered in the lists to begin with.Not bad, definitely better than what we were doing before. But we might be able to go a little better...
---
Yet another way is to use some hash sets, which (generally) have O(1) insertions and retrievals, and only store unique values, such that if you insert the same value twice, the second insertion is effectively ignored. We can do something like this:
Out_set = set([])
A_set = set([a in A])
for b in B:
if A_set.contains(b)://O(1) set search
Out_set.append(b)
return list(Out_set)//optional, could return Out_set
Now we end up with an algorithm which is O(n), where we iterated over the items in A once to fill in A_set, then we iterated over the items in B once, and each "contains" call was an O(1) hash lookup inside of A_set. Then finally we iterated over Out_set once to create the output list. This final step is optional, we could also have just returned Out_set directly, but it doesn't effect algorithmic complexity in either case. Now we've got 2000-3000 iterations, depending on how whether we return a set or a list. And this additionally looks a bit simpler than the sort+iterate version I gave above.---
So just by using our knowledge of data structures, we've turned ~1000000000 iterations into ~2000-3000 iterations. This is on the order of reducing the distance to the moon to around a kilometer. And that's just with two lists that are limited to 1000 items each.
And this sort of thing is a pretty common scenario in any language, no matter how 'abstracted' it is.
I've done a fair amount of web development in PHP & Python (as well as introductory C++ & Java). I had to look up "linked list" on Google just to get some understanding of what that is.
Understanding algorithmic complexity and knowing which data structure(s) to use to solve a given problem are universal skills.
All that's missing is a smug logo, and it'll be a hit!
(also mentioned in the article)
We're not trying to get into Harvard, so not particularly relevant.
While you may be a lurker here, and so may not have it, many of us have a "flag" button. This will delete the article from the site if a pretty small number of us click it.
Therefore, I wish, in addition to this button, I also had a button that said "has some value, just get it out of the curated HN space, and transfers it to reddit".
So if it's interesting to hackers, it's via politics (which HN tends to be flag happy about), and about a stage in life where pretty much everyone here is past (college admissions), to an institution which isn't really that common for the startupy type of person to strive for (usually preferring Stanford or MIT).
I do think it's interesting, I just would prefer to see it on a site where the politics can be discussed without the stink of political opinion interfering with the startup community.
I view sticking stuff like this on HN is akin to having heated political discussions before interviewing for a job or partnership: a universally bad idea.
I wasn't being glib. It is an interesting article, just not one I want to see change my opinion of people I discuss technical things with all the time. People tend to be more blind to assumption about politics than many other topics, so it's a good way to make yourself think less of people.
Things close to this I would think on topic for HN:
A blog post going into how the hacker community isn't like this.
The ways that scions of tech are different than other parents when the second generation comes around.
Etc.
Arbitrary illustrative excerpt:
Whether American or Chinese, individuals who focus too much on ‘achievement,’ and who believe the illusion that they’ve achieved everything simply through their own honest hard work, often think very little of everyone else as a result.