[开_27] 条件求和问题[已总结] ★★

gdliyy

我这个人挺守旧的，普通公式的，速度还可以，给个解法吧！

同时也解答一些初学者的疑问，为何明明是数字，为什么求和结果不正确！

mdX0NAIt.zip (33.56 KB, 下载次数: 257)

2005-5-26 23:03 上传

点击文件名下载附件
测试题：条件求和问题

[此贴子已经被作者于2005-5-26 23:00:50编辑过]

布衣铁剑

最开始看到这个题目的时候就考虑使用SUMIF的通配符。可惜我从来没用过日期函数，在这里卡了壳。

不解了，我等答案。惭愧。

wangtx218

以下是引用gdliyy在2005-5-26 22:59:00的发言：

我这个人挺守旧的，普通公式的，速度还可以，给个解法吧！

同时也解答一些初学者的疑问，为何明明是数字，为什么求和结果不正确！

向大师学习,普通的好!!!

apolloh

以下是引用gdliyy在2005-5-26 22:59:00的发言：

我这个人挺守旧的，普通公式的，速度还可以，给个解法吧！

同时也解答一些初学者的疑问，为何明明是数字，为什么求和结果不正确！

[em17]，佩服！佩服！

ab007

华山论剑，各路高手绝招频出。这类问题很实用，我要得空研究学习下，谢谢诸位！

梧桐

=SUMIF(OFFSET($B$4,,,COUNTIF($C:$C,"<="&$F13)),"*"&J$12&"*",$D$4)-SUM(J$12:J12)

这个真简洁，原来偶做的时候，SUM(J$12:J12)总是等于31740，其实改成文本就行了，真傻。

不过，每次引用的范围还是较大啊，一次求和较大范围与多次计算然后确定一个较小范围求和，哪个效率较高呢？？比如这个方法，不减SUM(J$12:J12)，而是减少sumif的区域。

最后一个$D$4什么意思呢，不应该是一个区域吗？

apolloh

sumif的最后一个参数可以只写对应区域的第一单元格。

czzqb

zyiVXVrB.rar (4.92 KB, 下载次数: 76)

2005-5-27 20:02 上传

点击文件名下载附件
[函数18] 测试题：条件求和问题 ★★

我们试做了一个，献丑了。重在参与罢了。

当数据量比较大时，速度显得慢了些

关于将F11和F12合并单元格的建议不错，谢谢！：）——apolloh

[此贴子已经被apolloh于2005-6-3 17:41:30编辑过]

matsumi

以下是引用gdliyy在2005-5-26 22:59:00的发言：

我这个人挺守旧的，普通公式的，速度还可以，给个解法吧！

老大“推陈出新”！受益匪浅！

gdliyy

以下是引用wutong9988在2005-5-27 8:21:00的发言：

不过，每次引用的范围还是较大啊，一次求和较大范围与多次计算然后确定一个较小范围求和，哪个效率较高呢？？比如这个方法，不减SUM(J$12:J12)，而是减少sumif的区域。

最后一个$D$4什么意思呢，不应该是一个区域吗？

这点还是考虑到了的，但如果我们直接用Offset(,Match(),,Countif())来精确定位数据区域，那么在Sumif()的第3个参数中也必须用Match()来定位D列的起始位置，由于Match()、Countif()都是典型的易失函数，那么这样的函数在公式中越多，运算速度肯定会受影响的！这次我就不拿实例来做测试了，有兴趣的朋友可以做一下速度比较：）

另外，除了使用Countif()来求范围外，我还想过用Frequency()来解，这样也利用了该函数直接取<=指定日期的统计结果，而且使用普通公式，系统默认只取第1个值，结果和Countif()是一样的，待我测试后再将结果向大家汇报：）

如果速度更快的话，公式可以修改为：(呵呵~~~又短了几个字符。。。) =SUMIF(OFFSET($B$4,,,FREQUENCY($C:$C,$F13)),"*"&J$12&"*",$D$4)-SUM(J$12:J12)

其下补充： 哈哈。。。简单做了一个测试，结果如下：（原始数据仍然是3395行，但公式单元格增加至1200个） 原Countif()公式，重算一次需要7.70秒；而Frequency()公式，重算一次仅仅需要3.50秒，应该是快了近一倍喔！！！

[此贴子已经被作者于2005-5-27 22:02:53编辑过]