Comments for Psyche http://www.disinformatics.com/blog The opposite of opposite Sat, 18 Dec 2010 02:00:21 +0000 hourly 1 http://wordpress.org/?v=3.0.4 Comment on A Google Internship Interview Question in Scala by Farhan Mannan http://www.disinformatics.com/blog/2010/12/14/a-google-internship-interview-question-in-scala/#comment-320 Farhan Mannan Sat, 18 Dec 2010 02:00:21 +0000 http://www.disinformatics.com/blog/?p=670#comment-320 And there I was thinking "I really need to learn Python!!" And there I was thinking “I really need to learn Python!!”

]]> Comment on A Google Internship Interview Question in Scala by Xiang Long http://www.disinformatics.com/blog/2010/12/14/a-google-internship-interview-question-in-scala/#comment-315 Xiang Long Thu, 16 Dec 2010 11:47:09 +0000 http://www.disinformatics.com/blog/?p=670#comment-315 Correct me if I'm wrong but, I think there's a problem with that Python solution. It is not breaking out of the loop unless two numbers that sums to the target are found. It's not dealing with the fact that if no such numbers exist then the pointers will cross over. So either it will address the array out of bounds, or give an incorrect solution such as 11, 11 in the numbers [1, 2, 7, 11, 16, 17, 18] when the target is 22 because left will equal right, even though there is only one occurrence of 11. Correct me if I’m wrong but, I think there’s a problem with that Python solution. It is not breaking out of the loop unless two numbers that sums to the target are found. It’s not dealing with the fact that if no such numbers exist then the pointers will cross over. So either it will address the array out of bounds, or give an incorrect solution such as 11, 11 in the numbers [1, 2, 7, 11, 16, 17, 18] when the target is 22 because left will equal right, even though there is only one occurrence of 11.

]]> Comment on A Google Internship Interview Question in Scala by mtrn http://www.disinformatics.com/blog/2010/12/14/a-google-internship-interview-question-in-scala/#comment-313 mtrn Wed, 15 Dec 2010 02:13:38 +0000 http://www.disinformatics.com/blog/?p=670#comment-313 Nice question. Here's a python version: http://gist.github.com/741526 Nice question. Here’s a python version: http://gist.github.com/741526

]]> Comment on A Google Internship Interview Question in Scala by Xiang Long http://www.disinformatics.com/blog/2010/12/14/a-google-internship-interview-question-in-scala/#comment-312 Xiang Long Wed, 15 Dec 2010 01:58:14 +0000 http://www.disinformatics.com/blog/?p=670#comment-312 I think the "structured approach" you are referring to is analysing what specific problem the algorithm needs to solve and adapting to solve them, along with identifying and targeting the bottlenecks but trading-off performance in areas that may not be important. A lot of algorithm design is about striking a compromise between different criteria of performance (like special cases of input) with the hope that when the algorithm is used, the performance you gained will vastly outweigh the performance you traded away, or that the specific bad-behaving/unsolvable cases will infrequently/never occur. It seems that once satisfactory algorithms have been developed for a problem, it is very difficult to come up with an improved algorithm which beats everything else in every case, although often you can come up with a variation which performs better in some (more useful) cases. I think the “structured approach” you are referring to is analysing what specific problem the algorithm needs to solve and adapting to solve them, along with identifying and targeting the bottlenecks but trading-off performance in areas that may not be important. A lot of algorithm design is about striking a compromise between different criteria of performance (like special cases of input) with the hope that when the algorithm is used, the performance you gained will vastly outweigh the performance you traded away, or that the specific bad-behaving/unsolvable cases will infrequently/never occur. It seems that once satisfactory algorithms have been developed for a problem, it is very difficult to come up with an improved algorithm which beats everything else in every case, although often you can come up with a variation which performs better in some (more useful) cases.

]]> Comment on A Google Internship Interview Question in Scala by Xiang Long http://www.disinformatics.com/blog/2010/12/14/a-google-internship-interview-question-in-scala/#comment-311 Xiang Long Wed, 15 Dec 2010 01:44:57 +0000 http://www.disinformatics.com/blog/?p=670#comment-311 Yes there's quite a lot of different properties and assumptions you can take advantage of on data sets which you can exploit to make algorithms faster. You can assume something about the distribution of the data, for example interpolation search performs in O(lg lgn) by guessing the input is uniformly distributed. I'd imagine this would be quite useful in probabilistic algorithms as well. Minimax with ab-pruning makes the assumption that the expected player and opponent actions will always be rational, which it uses to cut away branches of the search tree. Assumptions on the expected order/frequency of operations could also lead to optimisations at least in amortised analysis, such as choosing the correct data structure to use if you expect a specific operation is going to be especially frequent (Djikstra's + Fibonacci heap is a classic example, along with splay trees + frequent access of a small subset of nodes). There should be lots more which either I couldn't recall off-hand right now or is too advanced for me yet :) Yes there’s quite a lot of different properties and assumptions you can take advantage of on data sets which you can exploit to make algorithms faster. You can assume something about the distribution of the data, for example interpolation search performs in O(lg lgn) by guessing the input is uniformly distributed. I’d imagine this would be quite useful in probabilistic algorithms as well. Minimax with ab-pruning makes the assumption that the expected player and opponent actions will always be rational, which it uses to cut away branches of the search tree. Assumptions on the expected order/frequency of operations could also lead to optimisations at least in amortised analysis, such as choosing the correct data structure to use if you expect a specific operation is going to be especially frequent (Djikstra’s + Fibonacci heap is a classic example, along with splay trees + frequent access of a small subset of nodes).

There should be lots more which either I couldn’t recall off-hand right now or is too advanced for me yet :)

]]> Comment on A Google Internship Interview Question in Scala by Farhan Mannan http://www.disinformatics.com/blog/2010/12/14/a-google-internship-interview-question-in-scala/#comment-310 Farhan Mannan Wed, 15 Dec 2010 01:16:02 +0000 http://www.disinformatics.com/blog/?p=670#comment-310 Thanks Xiang. There's sortedness (as in this case, or Graham scan), range (like the sorts you mention)... ... are there other powerful properties that are applicable to many data sets (you can sort data to make it sorted, you can partition data to make it into disjoint sets with new ranges attached - quicksort?) or am I barking up the wrong tree? It must be an algorithm design pattern to look for preprocessing steps, or data structure considerations, that fundamentally alter asymptotic costs. There must be a more structured approach - I think that's what I'm looking for. Thanks Xiang.

There’s sortedness (as in this case, or Graham scan), range (like the sorts you mention)…

… are there other powerful properties that are applicable to many data sets (you can sort data to make it sorted, you can partition data to make it into disjoint sets with new ranges attached – quicksort?) or am I barking up the wrong tree?

It must be an algorithm design pattern to look for preprocessing steps, or data structure considerations, that fundamentally alter asymptotic costs. There must be a more structured approach – I think that’s what I’m looking for.

]]> Comment on A Google Internship Interview Question in Scala by Xiang Long http://www.disinformatics.com/blog/2010/12/14/a-google-internship-interview-question-in-scala/#comment-309 Xiang Long Wed, 15 Dec 2010 01:08:55 +0000 http://www.disinformatics.com/blog/?p=670#comment-309 Sorting the data set allows you to make an assumption about the data (i.e. it's sorted) that can lead to an optimisation that is asymptotically better than if you can't make that assumption. This is the "transformation" you are talking about. In general an assumption about the data reduces the domain of the input into a subset which satisfies that assumption, allowing you to use a method which wouldn't work with more general data. This is quite common in algorithms. Binary search for example makes the assumption that the input is sorted and therefore never has to examine every element. Bucket sort or radix sort makes the assumption that the input is within a certain range or finite domain and sorts in linear time. Of course you are just making a trade-off that either restricts your inputs or makes the algorithm at least as complex as remodelling/sorting the data, which could actually be asymptotically more expensive than the "real" work. Sorting the data set allows you to make an assumption about the data (i.e. it’s sorted) that can lead to an optimisation that is asymptotically better than if you can’t make that assumption. This is the “transformation” you are talking about. In general an assumption about the data reduces the domain of the input into a subset which satisfies that assumption, allowing you to use a method which wouldn’t work with more general data. This is quite common in algorithms. Binary search for example makes the assumption that the input is sorted and therefore never has to examine every element. Bucket sort or radix sort makes the assumption that the input is within a certain range or finite domain and sorts in linear time. Of course you are just making a trade-off that either restricts your inputs or makes the algorithm at least as complex as remodelling/sorting the data, which could actually be asymptotically more expensive than the “real” work.

]]>