Approved

Brackets signifies the difference between both results.

ok, good. Well... manner of speaking. ;)

Take a look at the question I posted at the top of the page, you'll see the reason of this. Depending on FArekkusu's next answer, maybe your current code will become efficient enough. But you can try to get the required algo already, if you're interested in a performant approach.

@FArekkusu:

But do we even need this if? The for loop is working while i < path.size() so we can just cost += t[x][y] on every iteration, can't we?

yes, ofc. I'll get rid of that useless thing.

@ekaruk: the internal solution and the tests should be ok, now. Maybe you did try just before I updated the code. If you still get some troubles, could you please try to get a smaller map so that it will be less painful to see what's happenning?

EDIT: actually, the way you compute your cost is wrong. It's not the java version that is incorrect anymore. Look precisely at what I detailed above about your first message.

explanation why you were wrong (REMOVED) ;)

Turns out I was right, it should have been if (i < path.size()) cost += t[x][y] instead of if (i < path.size() - 1) cost += t[x][y].

But do we even need this if? The for loop is working while i < path.size() so we can just cost += t[x][y] on every iteration, can't we?

Lol, I made shit, messing around with my brain with that rule, apprently... ;)

OK, easy fix. It should be good now. Sorry for the troubles.

Just launch several batches of random tests in python: my solution never failed.

@ekaruk:

{50,58,98,44,88,31,33,14,30,58,79,40,28,80,35,9,54,30,78,74,42,37,32,16,93,71,86,56,71,78,61,51,2,86,43,},
{19,87,95,18,59,17,25,14,86,98,4 ,93,20,64,8, 34,29,13,57,81,14,32,36,87,31,57,6,21,91,55,95,99,67,84,31,},
{68,46,93,17,69,75,89,33,0 ,33,57,72,23,15,22,11,85,67,63,57,29,38,81,57,41,83,40,40,22,9,80,88,27,7,99,},
{23,64,77,63,48,54,49,52,62,0 ,93,95,20,92,25,24,80,89,74,50,24,57,88,46,89,75,33,48,54,68,18,46,22,30,83,},
{37,4 ,41,76,85,63,2 ,47,69,44,19,23,25,11,58,66,98,8,49,86,24,34,7,94,46,37,53,59,58,58,88,23,3,7,15,},

start 1;17
finish 4;13

start at (1,17) means starting on 13 and going to the 29 on the left. So first cost computation (assuming my logic is correct) is 13, not 29.

your path: 
[left, left, left, down, left, left, down, down, right], cost=164
   13     29   34    8     22    15    23    20     25       = 189  (wtf...?! I'll check my compute function)
should be somehting like
[left, left, left, down, down, down, left], cost=131 expected: but was:
   13    29   34     8    22     25   58        =189

OK, so the problem isn't in the algo, but in the assertion. I'll sort that out.

republished without the zeroes in the random maps, as a beginning.

about the way I compute the cost, I feel like there is a misunderstanding about one rule: the total cost is increased after leaving the matrix coordinate, not entering it. I already talked about that below (message where I talked about the shift between our calculations). So it might need a better wording/explaination?

Hi,

I'll look into it. What did you identify on your side, FArekkusu?

What's weird is that I used the very same algo than in my python solution.

Unfortnately, @Blind4Basics translated the kata into Java, so I can't fix the problem (without probably messing up something). For some reason it doesn't add the last before finish coordinate's value to the sum, giving the result: got (189 - 25) 164 instead of (189 - 58) 131.
Moreover I noticed a problem which shouldn't be present - some coordinates have 0 value which may lead to incorrect behavior (at least it does in Python version).