1. The algorithm in question does not do any of the latter 'better' approaches.
2. The pursuit of all edge-cases is a form of hubris. Your first version is fine in many cases (it is the algorithm used by the package referenced [edit:] and by both the Python and .NET standard libraries) and can be written inline.
3. At the point you are concerned with specific edge-cases, and need the 'correct' algorithm, you need to have found that algorithm, understood it, and make sure that the package you're importing implements it. It's even worse for a builtin function: there's no guarantee that a language implementation of average does so, or that it has the correct tradeoffs for your code. You'd need to test it, code review it, and so on. Do you do that for every trivial function?
4. If you're really suggesting that you can't be trusted to calculate an average correctly, then how can you have the slightest confidence in anything you do that is more complex?
>It's even worse for a builtin function... You'd need to test it, code review it, and so on
If you can't trust built-in functions to do what they say on the standard library documentation, you're either paranoid or made a wrong choice of language. (Or you have some very compelling reason to be working in a language that's still rough, like the early days of Swift, which is an entirely different game).
>If you're really suggesting that you can't be trusted to calculate an average correctly
It's not about what you can be trusted to do, but what's worth spending your time on.
I don't care. I expect it to work for the simple case, and I expect not to spend time on it unless there is a good reason (like I have very large numbers and must be careful not to overflow).
2. The pursuit of all edge-cases is a form of hubris. Your first version is fine in many cases (it is the algorithm used by the package referenced [edit:] and by both the Python and .NET standard libraries) and can be written inline.
3. At the point you are concerned with specific edge-cases, and need the 'correct' algorithm, you need to have found that algorithm, understood it, and make sure that the package you're importing implements it. It's even worse for a builtin function: there's no guarantee that a language implementation of average does so, or that it has the correct tradeoffs for your code. You'd need to test it, code review it, and so on. Do you do that for every trivial function?
4. If you're really suggesting that you can't be trusted to calculate an average correctly, then how can you have the slightest confidence in anything you do that is more complex?