# Bottom-up dynamic programming

If you try to think in depth about the top-down DP solution, you might notice
that the *core* of it stands on caching the calculations that have been already
done on the lower “levels” of the pyramid. Our bottom-up implementation will be
using this fact!

As I have said in the *top-down DP* section, it is the easiest way to implement
DP (unless the cached function has complicated parameters, in that case it might
get messy).

Bottom-up dynamic programming can be more effective, but may be more complicated to implement right from the beginning.

Let's see how we can implement it:

`public static int longestSlideDown(int[][] pyramid) {`

// In the beginning we declare new array. At this point it is easier to just

// work with the one dimension, i.e. just allocating the space for the rows.

int[][] slideDowns = new int[pyramid.length][];

// Bottom row gets just copied, there's nothing else to do… It's the base

// case.

slideDowns[pyramid.length - 1] = Arrays.copyOf(pyramid[pyramid.length - 1],

pyramid[pyramid.length - 1].length);

// Then we need to propagate the found slide downs for each of the levels

// above.

for (int y = pyramid.length - 2; y >= 0; --y) {

// We start by copying the values lying in the row we're processing.

// They get included in the final sum and we need to allocate the space

// for the precalculated slide downs anyways.

int[] row = Arrays.copyOf(pyramid[y], pyramid[y].length);

// At this we just need to “fetch” the partial results from “neighbours”

for (int x = 0; x < row.length; ++x) {

// We look under our position, since we expect the rows to get

// shorter, we can safely assume such position exists.

int under = slideDowns[y + 1][x];

// Then we have a look to the right, such position doesn't have to

// exist, e.g. on the right edge, so we validate the index, and if

// it doesn't exist, we just assign minimum of the ‹int› which makes

// sure that it doesn't get picked in the ‹Math.max()› call.

int toRight = x + 1 < slideDowns[y + 1].length

? slideDowns[y + 1][x + 1]

: Integer.MIN_VALUE;

// Finally we add the best choice at this point.

row[x] += Math.max(under, toRight);

}

// And save the row we've just calculated partial results for to the

// “table”.

slideDowns[y] = row;

}

// At the end we can find our seeked slide down at the top cell.

return slideDowns[0][0];

}

I've tried to explain the code as much as possible within the comments, since it might be more beneficial to see right next to the “offending” lines.

As you can see, in this approach we go from the other side^{1}, the bottom of
the pyramid and propagate the partial results up.

*greedy*solution???

If you try to compare them, you might find a very noticable difference. The
greedy approach is going from the top to the bottom without **any** knowledge of
what's going on below. On the other hand, bottom-up DP is going from the bottom
(*DUH…*) and **propagates** the partial results to the top. The propagation is
what makes sure that at the top I don't choose the best **local** choice, but
the best **overall** result I can achieve.

## Time complexity

Time complexity of this solution is rather simple. We allocate an array for the rows and then for each row, we copy it and adjust the partial results. Doing this we get:

$\mathcal{O}(rows + 2n)$Of course, this is an upper bound, since we iterate through the bottom row only once.

## Memory complexity

We're allocating an array for the pyramid **again** for our partial results, so
we get:

If we were writing this in C++ or Rust, we could've avoided that, but not really.

C++ would allow us to **copy** the pyramid rightaway into the parameter, so we
would be able to directly change it. However it's still a copy, even though we
don't need to allocate anything ourselves. It's just implicitly done for us.

Rust is more funny in this case. If the pyramids weren't used after the call of
`longest_slide_down`

, it would simply **move** them into the functions. If they
were used afterwards, the compiler would force you to either borrow it, or
*clone-and-move* for the function.

Since we're doing it in Java, we get a reference to the *original* array and we
can't do whatever we want with it.

# Summary

And we've finally reached the end. We have seen 4 different “solutions”^{2} of
the same problem using different approaches. Different approaches follow the
order in which you might come up with them, each approach influences its
successor and represents the way we can enhance the existing implementation.

You can find source code referenced in the text here.