Because you can't tell if an object has hit the ground under it unless you check for a collision between it and the ground, and it doesn't matter if the ground is moving up or the object is moving down. You have to calculate it regardless.
For sure - you'll have to run collision detection just as many times. However, motion itself is vastly simplified - you either update the co-ordinates of
everything per tick, or just the co-ordinates of
the Earth per tick. I would argue that the
for loop in
fall_flat() becomes redundant once you design your simulation with efficiency in mind - you don't need to manually raise every part of the Earth (I get why it was
convenient for you to do so, especially since you wanted to display your visualisation directly in the console - a neat approach - and that has its own value, but it's neither here nor there when we're discussing potential efficiency), you could treat it as a single object (particularly easily if you chose an OOP language instead of C). Every object maintains a set of co-ordinates, but only the Earth needs to be updated every tick.
You could argue that the time complexity will be O(n) in either case, I guess, but given how large n might be (when it could be 1 instead in optimistic cases), it's still a worthwhile consideration.
In short - it's certainly possible to create a simulation in which both models will be equally inefficient. In your case, this inefficiency came from how you chose to deal with your visualisation. I would consider this the worst-case scenario, in which case the two approaches are indeed nearly equal. Any other case will start winning UA some favour.
EDIT: Actually, why the hell is
earth_height an array at all? I do apologise if I'm missing something here, but couldn't you just do
https://onlinegdb.com/uJ_6XVm0T? It seems to me that even with your implementation of
display(), UA can be made to trivially win - the motion becomes O(1) rather than O(n), while collision detection remains identical. By the same token, UA is now significantly winning on space complexity (but that
could be fixed for RET in a different context)