blocks|key|1763435|text|我假设我们在这里讨论的是浮点算术(否则“更好”的平均值将是可怕的)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1763436|在第二种方法中，中间结果(sum)将趋于无限增长，这意味着您最终将失去低端精度。在第一种方法中，中间结果应该与您的输入数据保持大致相似的大小(假设您的输入没有巨大的动态范围)。这意味着它将更好地保持精度。|offset|length|style|CODE|1763437|然而，我可以想象，随着i变得越来越大，(x+-+avg)+/+i的值(相对)将变得越来越不准确。所以它也有它的缺点。|1763438|entityMap^0|0|D|3|0|B|1|J|D|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@$D|Q|E|R|F|G]|$D|S|E|T|F|G]]|9|@]|A|$]]|$1|J|3|-4|5|6|7|U|8|@]|9|@]|A|$]]]|K|$]]

I'm assuming we're talking about floating-point arithmetic here (otherwise the "better" average will be terrible).

In the second method, the intermediate result (<code>sum</code>) will tend to grow without bound, which means you'll eventually lose low-end precision. In the first method, the intermediate result should stay of a roughly similar magnitude to your input data (assuming your input doesn't have an enormous dynamic range). which means that it will retain precision better.

However, I can imagine that as <code>i</code> gets bigger and bigger, the value of <code>(x - avg) / i</code> will get less and less accurate (relatively). So it also has its disadvantages.

blocks|key|1976460|text|从它计算运行平均值的意义上来说，它更好，也就是说，你不需要提前得到所有的数字。您可以根据实际情况进行计算，也可以根据可用的数据进行计算。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1976461|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

It is better in the sense that it computes a running average, i.e. you don't need to have all your numbers in advance. You can calculate that as you go, or as numbers become available.

blocks|key|1763277|text|后一种算法比前一种算法更快，因为您必须执行n个操作(实际上，后者需要执行2*n个操作)。但是，第一个确实可以防止溢出。例如，如果您有这样一组1000个数字:+4000000*250、1500000*500、2000000*500，那么所有整数的总和将是2'750.000.000，但是c%2B%2B+int数据类型的上限是2,147,483,647。因此，在这种情况下，我们处理的是溢出问题。但是如果你执行第一个算法，那么你就能够处理这个问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1763278|因此，我建议您使用第一种算法，如果它很可能发生溢出，否则它只会增加额外的操作。如果您决定使用第一种类型，那么我建议您使用范围更大的类型。|1763279|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The latter algorithm is faster than the former, because you have to perform n operations (actually, the latter requires performing 2*n operations). But it is true that the first prevents overflow. For example, if you have this set of 1000 numbers: 4000000*250, 1500000*500, 2000000*500, the total sum of all of the integers will be 2'750.000.000, but the upper bound of a c++ int data type is a 2,147,483,647. So, we are dealing iin this case with an overflow problem. But if you perform the first algorithm, then you are able to deal with this problem. 

So I recommend that you use the first algorithm if it is likely to occur the overflow, otherwise it only will add extra operations. If you decide to use the first anyways, then I reccomend that you use a type with a larger range.

blocks|key|1977102|text|我更喜欢第二种方法(循环求和，末尾除法)，并且识别第二种方法比第一种方法快得多。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1977103|性能差异(如果有的话)是不相关的。|1977104|而且，如果一个值的和溢出了一个足够大的数据类型，那么您可能会遇到比计算平均值更多的问题。|1977105|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I like the second method (summing in a loop and dividing at the end) better, and can identify the second method much faster than the first.

The performance differences, if any, are irrelevant.

And, if a sum of values overflows a big enough data type, you'll probably have more problems than calculating an average.

blocks|key|1977255|text|好的，答案不在于溢出总和(因为这是被排除的)，而是正如Oli在“失去低端精度”中所说的那样。如果要求和的数字的平均值远远大于每个数字与平均值的距离，则第二种方法将丢失尾数位。由于第一种方法只查看相对值，因此它不会受到这个问题的影响。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1977256|因此，任何大于6000万(单精度浮点)的数字列表，但是值的变化不超过10左右，应该会向您显示该行为。|1977257|如果您使用双精度浮点数，则平均值应该要高得多。或者更低的差值。|1977258|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Ok, the answer lies not in overflowing the sum (since that is ruled out), but as Oli said in "losing the low-end precision". If the average of the numbers you are summing is much larger than the distance of each number from the average, the 2nd approach will lose mantissa bits. Since the first approach is only looking at the relative values, it doesn't suffer from that problem.

So any list of numbers that are greater than, say, 60 million (for single-precision floating point) but the values don't vary by more than 10 or so should show you the behavior.

If you are using double-precision floats, the average value should be much higher. Or the deltas much lower.

blocks|key|1976666|text|sum+%2B=+x;
avg+=+sum+/+i;|type|code-block|depth|inlineStyleRanges|entityRanges|data|syntax|javascript|1976667|在上面的代码中，假设我们有10000,20000的数字，..that是包含大量数字的数字，那么sum中的值可能会超过其最大值，这与I‘it中的情况不同，因为在存储之前，sum总是除以元素的数目。|unstyled|1976668|尽管由于编程语言中存在大型数据类型，但这可能不是problem.Thus，|1976669|专家说“根据您的应用程序和需求使用数据类型”。|1976670|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$B|C]]|$1|D|3|E|5|F|7|N|8|@]|9|@]|A|$]]|$1|G|3|H|5|F|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|F|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|F|7|Q|8|@]|9|@]|A|$]]]|L|$]]

<pre><code>sum += x;
avg = sum / i;
</code></pre>

In above code suppose we have numbers as 10000,20000 ,..that is numbers containing large number of digits then value in sum may exceed its MAX value,Which is not the case in I'st one as sum is always divided by no of elements prior to storing in it.

Although because of large data types present in programming language this may not be a problem.Thus what the 

Experts say "Use Data Type As Per Your Application and Requirement."

blocks|key|1977311|text|假设int在一个数组中，像这样计算怎么样？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1977312|sum+%2B=+x[i]+/+N;+rem+%2B=+x[i]+%25+N;
avg+=+sum+%2B+rem/N;|code-block|syntax|javascript|1977313|如果N很大(0xFFFFF)，而x[i]都很小，所以rem加起来等于0xFFFF+(最大整数)，那么可能会发生溢出。|offset|length|style|CODE|1977314|entityMap^0|0|0|2|1|G|4|Q|3|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@$I|R|J|S|K|L]|$I|T|J|U|K|L]|$I|V|J|W|K|L]]|9|@]|A|$]]|$1|M|3|-4|5|6|7|X|8|@]|9|@]|A|$]]]|N|$]]

How about calculating like this, assuming ints are in an array?:

<pre><code>sum += x[i] / N; rem += x[i] % N;
avg = sum + rem/N;
</code></pre>

If <code>N</code> is large (0xFFFFF) and <code>x[i]</code> are all small so <code>rem</code> adds up to 0xFFFF (largest int) then an overflow might happen.

I am doing an exercise of a programming book A Book on C . The exercise suggests that to find average of a group of numbers, algorithm: 

<pre><code>avg += (x - avg) / i;
</code></pre>

is better than:

<pre><code>sum += x;
avg = sum / i;
</code></pre>

'x' is a variable used to store the input numbers. It also suggests beside preventing overflow, the first algorithm do have some other benefits than the second algorthim, can anyone help me? Thanks!

Better algorithm to find average

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我正在做一本关于C语言的编程书籍的练习。该练习建议，要找出一组数字的平均值，算法：avg += (x - avg) / i;比：sum += x;avg = sum / i;'x‘是一个用来存储输入数字的变量。它还表明，除了防止溢出，第一种算法确实比第二种算法有一些其他的好处，有人能帮我吗？谢谢!

问求平均值的更好算法
EN

回答 7

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问求平均值的更好算法EN

回答 7

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问求平均值的更好算法
EN