EXCEL,EDATE和EOMONTH到底能不能返回数组 _EXCEL

今天和大家来分享高级篇，高级篇嘛，当然是以烧脑为主，介绍一些在论坛和QQ群困扰了很多人的公式错误原因。
1，EDATE和EOMONTH到底能不能返回数组？

文章插图

有些时候需要引用数据源返回相关的数组结果，但很多小盆友引用了区域后发现EOMONTH这些函数结果是报错的。
因此得出一个结论，这批函数在引用区域后是不能返回数组的。
但是，这只是因为这批函数性质特殊而已，稍微加点料就可以返回数组了。

文章插图

数据源区域只要*1，- -等把直接引用转化为内存数组，就可以使这批函数在引用区域后成功返回数组结果。
这是个很偏门的性质，具有这种性质的函数有EDATE，EOMONTH，WEEKNUM，QUOTIENT/DELTA等等。共同点是，这批函数在2003版需要加载工具库才能使用，这或许就是这批函数具有这个奇葩性质的原因。

2)高精度浮点
这个性质也是坑过无数老司机的：

文章插图

文章插图

这个性质在于，这种浮点数在目前函数阶段，F9，公式求值，格式小数位数，等号比较等等多种方法都无法检测出来，但就是会造成MATCH，VLOOKUP，RANK，MODE，FREQUENCY等函数的结果异常。
因为这种浮点超过了Excel的15位精度，所以无法显示，但部分函数还是会识别这种差异，重点是影响上面几个函数的结果(这种精度差异可以使用DELTA函数检查) 。
解决方法是使用ROUND等修正这类数值的实际精度，或者换成不识别这种精度的函数或判断式(等号比较不识别这种差异) 。

文章插图

3)真伪内存数组和365动态数组性质差异
365前的版本VLOOKUP和INDEX等函数有一类性质。如果VLOOKUP的第1参数和INDEX的第2/3参数，直接使用数组，并不能使整个VLOOKUP或INDEX返回内存数组。
虽然可以以区域数组方式录入多个单元格返回对应的多个结果，但并不能作为真内存数组用于后续计算，因此这个性质被称为伪内存数组。

文章插图

如果要把INDEX的结果变成真内存数组，必须加N/T+IF结构来进行转化。

文章插图

而自从出现了365版本，真伪内存数组性质发生了变化：

文章插图

文章插图

即365下部分公式使用三键和不使用三键，结果是会有区别的，
即通常在不使用三键环境下，365版本会把早期版本的伪内存结构直接形成真内存数组，但如果使用三键，还是早期版本的伪内存数组性质，这个性质主要在早期版本的伪内存数组和多维引用两种公式结构下存在。

4) 1和{1}的区别
这类性质，通常出现在涉及INDIRECT或OFFSET的动态引用问题内，INDIRECT或OFFSET函数配合ROW或COLUMN函数时容易出现。
很多人会被这个错误困扰不知道如何解决，其实这个公式之所以错误，根源在于ROW函数，因为ROW(A1)的结果为{1}，注意这是1个单元素的数组。
而INDIRECT和OFFSET都是容易构造多维引用的，所以目前的观点上面公式错误和这两个函数的多维引用下的降维理论有关。
解决方法也很简单，1是在ROW外面套个聚合函数，SUM/MAX/MIN等等均可，目的是把{1}变成常量1，就不会出现类似错误了。

5)时间精度
Excel里的时间精度到千分之一毫秒，即YYYY/MM/DDHH:MM:SS.000
到了时间阶段，Excel里的日期函数会出现两大阵营。部分日期函数对日期的识别仅到日期部分，不考虑时间范围。
但还有部分日期函数，对日期的识别精度达到了这个毫秒级，时间不大于23:59:59.499的日期识别为当天，但23:59:59.500-23:59:59.999的范围会被识别为第2天。