Editorial for Baltic OI '12 P5 - Melody
Submitting an official solution before solving the problem yourself is a bannable offence.
In all methods the generation of a valid tune can be achieved by backtracking, so we will focus here only on finding the minimum number of mistakes.
Subtask 1
Let's define as the maximal amount of notes Linas could have played correctly after playing the first
notes such that the
note was note
(
in the list of notes). Then you can easily compute all
using the following relation:
where denotes that it is possible to play note
after note
.
In the worst case (you can play note after any other note) you will need to check
notes to calculate each
, and you need
operations to check if you can play one note after another as well. This leads to a dynamic programming solution with time complexity
. The answer is
.
Subtask 2
Instead of comparing two notes every time you need to whether one note can be played after another, this information can be pre-computed. Make a graph with vertices corresponding to different notes, draw edges between pairs of notes if they can be played successively (i.e. the strings that to these notes are different in at most
positions), and save the graph as an adjacency matrix to enable checking if there is an edge between a particular pair of notes in
time. The time complexity of this is
. Combining this with the earlier algorithm we obtain a solution that runs in
time.
Subtask 2 Alternative Solution
To get to a point solution you need to think differently. Let's take the graph described earlier and use Floyd-Warshall algorithm to compute distances between all pairs of vertices in the graph (distance here corresponds to the minimal time we need to play one note after another (i.e., if the distance between notes
and
is
, we can play
after
only after playing
or more notes between them). Alternatively, you can run BFS algorithm
times from each vertex; as all the edges in the graph have length
you will get the same result. Complexity of this part is
.
Now let's define as the maximal amount of notes Linas could have played correctly after playing the first
notes such that the
note was correct. You can now compute all
using the following relation:
where denotes the distance between two notes:
and
.
The answer is . The overall complexity of this algorithm is
.
Full Solution
There are two approaches to get to a full solution, but the main idea is the same – to compute you don't need to look back at all previous values
.
Imagine the graph is connected. It is then sufficient to look only at the previous notes (or, in fact,
notes, where
is the diameter of the graph). At first note that all shortest paths between notes are at most
. Now, if we pick an arbitrary note from the interval
it is guaranteed that we can transition to some note in the interval
and play it correctly. Furthermore, we are guaranteed to be able to transition to the note at position
. All this means that if we check all notes in the interval
, it is useless to check earlier notes, i.e., from the interval
.
But by doing this we are assuming that the graph is connected. Otherwise it wouldn't be sufficient to look only at the previous notes, and we would have to consider each connected component of the graph separately, looking at
(where
is the size of the particular component) previous notes in that component (which would not change the time complexity of the solution but would make it slightly more difficult to implement). This gives a solution with overall complexity
.
Another approach is the idea that you need to check only one note of each type. The suggestion is that for each type of note you should select the last occurrence of this note after which you can still manage to make a transition to the current note. You can do so using a binary search, which leads to a solution with overall complexity . This is fast enough to score
points, however, it is easier to compute the array
, where
is the location of the last note of type
before the position
in the given tune. We get:
This also gives us a solution with overall complexity .
Comments