First I build an SS-tree of the topics set, allowing at most 16 points for each leaf and splitting nodes along x or y directiong according to which one presents the highest variance.
	
	The topic queries are simply k-nearest neighbours search on the topics tree, where all the topics encountered are pushed in a bounded max-heap which holds at most n_res distances
    (the n_res smallest ones) so that, once the heap is full, its first element is the kth distance discovered so far, and this value can be used to prune the search on the SS-tree.
   
	For question queries, instead, starts a k-nearest neighbours search for the query point, but for each topics encounterd checks the queries for which the topic is relevant and for each of this queries checks if other closer relevant topics have been already found or not.
	When at list k different questions have been met, starts comparing the distance from the query point of farthest one to the distances (from the query point) of the SS-tree nodes' borders, pruning the search on the nodes too far away.

b)	Original approach (file nearby.py and nearby_fast.py for the optimized version, twice as fast but not as readable)

	I decided to use an approach where I create a sorted list of the best topics for every query, because it looked more efficient:
	Suppose we have T topics, Q questions, and N queries;
	If the query is about a topic (t-type query), and we were to compute the distance of each topic's point from the query's center, and then sort the
	topics based on this distance and take the first k (where k is the second parameter of the query), then it would require time
	proportional to O(T + T*log T + k) = O(T*log T), since k<=T and provided we can compute the distance in constant time.
	If, instead, we keep a list of the best k topics, and insert each topic we examine in this ordered list, each step is bounded by
	O(log(k) + k) where O(log k) is needed to find the place to insert the new element and O(k) is a (large!) bound for the elements shift
	needed to insert an element in the middle of a sorted array of size k; for each query it is then required time proportional to O(T*k);
	If k<<T, being k constant, the total amount of time needed is O(T), while if k is close to T, the bound becomes O(T**2).
	Since by definition of the problem k<=10, the bound becomes O(10*T) = O(T) < O(T*log T), so the latter solution is to prefer.

	For q-type queries, the function to compute the distance requires to compute the distances of all the topics related to a question, 
	and then take the min value; for a question with Qn topic references then, supposing the distance can be computed in constant time O(c),
	it is required time O(Qn*c) < O(max{Qn}*c) < O(10*c) by definition of the problem, so it is still required constant time to compute the
	distance of a question from the query center and so the bound for each q-type query is analougous to the t-type query's ones.

	Therefore, since we can expect Q<T (max{Q}=max{T}/10), a pessimistic bound for the whole proximity search algorithm is O(N*T)

b) 	Original approach (file Typeahead.java)
	Here an approach similar to the one developed for the nearby (b version) is used, and if a query or wquery specifies a maximum number of results, let's say M, the item matching the query are temporarily stored in a sorted list that will hold at most M elements.
	To restrain the solution in a single file and avoid creating a package, accessory classes have been implemented as static inner classes.

a) 	Backtracking + heuristic pruning (Completely solves the challenge - file stepladder_fast.py)
	For each word in the dictionary is computed an upperbound on the possible score (since the scores on each ladder's element must be lower than its predecessor score, the max score is twice the sum of the integers between 1 and the score of the central ladder minus one); if the upperbound is lower than the best score found so far, backtracking is performed.
	The same heuristic may be applied after each step in which the ladder is grown by adding two elements to its sides.

b)	Simulated annealing (file stepladder_annealing.py)
	The second approach uses simulated annealing: while it cannot guarantee an optimal result, since the problem space has several local maxima, in practice it always find the optimal solution in a very short amount of time. I made a variant with respect to classic randomized-restart simulated annealing so that a single annealing cycle stops, as usual, when a critically low temperature is reached, but the number of cycles isn't specified as a parameter: the routine keeps performing annealing cycles until the allotted amount of time (passed as a parameter) is consumed. This way, if one needs an answer in a shorter amount of time than the backtracking procedure execution time (that in particular for huge dictionaries can be relevant), it is possible to have a semi-optimal solution in a few seconds, or a minute, or however long we can wait. 
	The heuristic pruning could be used here as well to better channel the evolutionary algorithms torwards global maximum.

The problem is an instance of 0-1 Knapsack problem, and that problem is NP-Hard.

a)	Exact solution (Horowitz-Sahni, Martello-Toth algorithms - Solves 8 out of 10 test cases - file feed_optimizer.py)
	The Horowitz-Sahni algorithm works quite well even for large inputs. The main cycle of the algorithm tries further optimization using the structure of the problem, i.e. the incremental construction of the set of items: when a new item is added, for example, first it is checked if it can added to the current solution, otherwise it is checked whether a solution containing the new item would lead to a higher aggregate value.
	To speed up the algorithm, elements from the Martello Toth algorithm are used as well especially to improve the upperbound estimate used in the pruning and to avoid backtracking on useless solutions.
	
b)	Simulated Annealing / Genetic Algorithms (file feed_optimizer_annealing, feed_optimizer_GA)
	For smaller inputs, two randomized solutions, a simulated annealing and a genetic algorithm, are also provided, although they are clearly outperformed by the exact backtracking algorithm.
	 

	From command line, a few parameters can be passed:

		-f filename: Reads input from a file [by default it reads input from stdin]
		-o filename: Writes output to a file [by default it writes output on stdout]
		-l filename: Logs debug info, like intermediate results, on a log file
						NOTE: for -o option only, it is possible to specify 'stdout' explicitly as the output stream;
		-tl time_limit: Set a (approximate) time limit in seconds for the global execution [Default is 4.5 seconds]
							The mechanism used is very simple and far from giving high resolution control on the execution time, but should ensure an execution time reasonably close to the limit provided, without degrading the global performance.
		-ps population_size: Set the dimension of the population evolved by the GA [Default is 25];
								Larger population means getting to the optimal result in fewer generations,
								but also allows fewer generation to be trained in a fixed time.

	The program accepts a parameter from command line that specifies an approximate execution time limit (by default is set to 4.5 seconds, in order to contain the total running time within the 5 seconds mentioned in the description of the challenge). Different values can be specified using the '-tl time_limit' option (See the sketched manual inside the Python module); although the algorithm appears to converge very quickly to the optimal solution, an estimate of the required execution time of the genetic algorithm to always get the optimal solution requires a real-size test case.