I just realized that the original text provides the sizes of free space. No need to count blocks of space available in the structure created in part 1, just subtract free space by the file size and you're left with the remaining free space. That's probably key to getting a more efficient solution.
I got part one and alllllmost part two before work (starting at 5:30) although stupidly left the blocks as strings initially (there's a reason the example only goes up to 9!). At least I remembered to use int64 instead of integer. I didn't realise you had to manually allocate space in Python - or is that just for gigantic structures like we have here?
I just realized that the original text provides the sizes of free space. No need to count blocks of space available in the structure created in part 1, just subtract free space by the file size and you're left with the remaining free space. That's probably key to getting a more efficient solution.
I got part one and alllllmost part two before work (starting at 5:30) although stupidly left the blocks as strings initially (there's a reason the example only goes up to 9!). At least I remembered to use int64 instead of integer. I didn't realise you had to manually allocate space in Python - or is that just for gigantic structures like we have here?
you do have to manually allocate space in python, though it's pretty simple with list multiplication
my part 2 code works for the example input but doesn't for the real input, welp
Are you accounting for the scenario where FileID (867) takes 4 blocks resulting in 867867867867 on the disk?
same :( Debuged it for hours, tried to rewrite it and stuck
Samee. I'm so sure it's quite right but it's stuck for the real input.