don't most people compute the mean iteratively when they need to do this? Sure, it goes unseen, but programmers on systems like this are expected to understand the math model and write tests.
Systems like what? My expectation is no, most people make mistakes.
I mean, in C and other low-level languages unlike python, it's generally assumed you have a basic understanding of the machine model and the consequences of arithmetic in limited types.
If most people make mistakes, they should self-select to languages which have properties that protect them from their ignorance. for example, I mostly program in Python using longs so I don't have to worry about overflow.
What kind of "long" are you referring to? Most programmers would think of a C long, int64, not a Python long, bigint.
Maybe people ought to self-select, but that would mean they'd need the training or experience to recognize what they don't know. It's often the most ignorant people that believe they have the most expertise.
Re:Go 2, here we come
by quickthrower2 on Thursday November 29, 2018 @04:14PM
(#18564084)
I get you point. I'd probably go float/double precision for that task.
Then you can lose precision that you might actually need - a bug that's even more annoying to track down than straight overflow.
Re:Go 2, here we come
by quickthrower2 on Thursday November 29, 2018 @07:09PM
(#18565420)
Yes indeed! But what is the alternative, especially if you are using approximations to transcendental constants?
Take averaging as a very simple example. Doing (a + b) / 2 will overflow if a and b are sufficiently large, even if the average will always fit in 32 bits. Things like this go unseen for years.