What if you are not a person, but a computer, converting a string into an integer? In that case, having a simpler and faster algorithm is important, having to start with only the beginning of a string (what the user has typed so far) is plausible, and knowing the number’s approximate value is useless. So in this case the little-endian algorithm is much better than the big-endian one.
For the most part this is irrelevant. If you are a computer with only partial input, recieving the rest of the input is so much slower than parsing it that it literally does not matter which algorithm you use. If you have all the input, either is equally fast. Also, most of the complexity is going to be validating the input and handling edge cases (e.g commas Vs decimal points), not keeping track of the total.
There could be some weird edge cases, where you’re reading a huge number, for some reason stored as a string, in a known format, don’t require validation, from an extremely fast storage mechanism, e.g. RAM or an SSD. In that case you might care about performance of keeping track of the running total, but weird edge cases shouldn’t decide which format to use (and in practice I guess they’d both be essentially identically fast here too).
Computers also need to decide whether to use big Indian or little Indian for their native representation of numbers. But either way they’ll be using specialized hardware to operate on them, and both will be equally fast (and for the most part invisible to the user).
For the most part this is irrelevant. If you are a computer with only partial input, recieving the rest of the input is so much slower than parsing it that it literally does not matter which algorithm you use. If you have all the input, either is equally fast. Also, most of the complexity is going to be validating the input and handling edge cases (e.g commas Vs decimal points), not keeping track of the total.
There could be some weird edge cases, where you’re reading a huge number, for some reason stored as a string, in a known format, don’t require validation, from an extremely fast storage mechanism, e.g. RAM or an SSD. In that case you might care about performance of keeping track of the running total, but weird edge cases shouldn’t decide which format to use (and in practice I guess they’d both be essentially identically fast here too).
Computers also need to decide whether to use big Indian or little Indian for their native representation of numbers. But either way they’ll be using specialized hardware to operate on them, and both will be equally fast (and for the most part invisible to the user).