[office-formula] Test Cases

[Eric Patterson <ericpa@exchange.microsoft.com>]

I'm starting to go through the open JIRA issues related to test cases.  My goal is to ensure that the normative text accounts for any issues that have been reported against the related test cases.  Many of the test cases include an Epsilon value showing the acceptable range of return values.  Before dismissing this aspect of the test cases, we should make sure that we are all in agreement that this is adequately covered in the written spec.  

I believe that the below part from section 3.3.1 (In Patrick's latest upload) covers the precision issue.  If this can be added to the agenda for tomorrow's meeting we can see if we have consensus.

Thanks,
Eric


Number
General
A number is simply a numeric value such as 0, -4.5, or $1000. Numbers shall be able to represent fractional values (they shall not be limited to only integers). The "number" type may be displayed in many different formats, including date, time, percentage, and currency.
Typical implementations implement numbers as 64-bit IEEE floating point values and use the CPU's floating-point instructions where available (so intermediate values may be represented using more than 64 bits). However, implementations have great freedom in how they implement Number, and may use representations with a fixed bit length or a variable bit length. A cell with a constant numeric value has the number type.
Note that many formula creators are not sophisticated in their understanding of how computers determine their results. Many users, for example, do not understand computer floating point arithmetic models, and have no idea that many implementations use a base other than 10 (or what that would mean). In particular, many implementations use base 2 representations, with the result that value 0.1 can only be represented imprecisely (just as 1/3 can only imprecisely represented in a base 10 decimal representation). This problem applies to all uses of typical computing equipment, including nearly all programming languages, and this specification does not attempt to fully resolve the problem of unsophisticated users.
Rationale: Originally some efforts were expended to try to make formulas produce the "expected answer" for unsophisticated users. In particular, the equal-to operator for numbers matches imprecisely in many applications, because many users do not understand that (1/3)*3 on most implementations will produce a value close to one but not precisely equal to one. Originally there was a test to ensure that (1/3)*3 was equal to 1. The Gnumeric developers objected, on the grounds that requiring that equality be "sloppy" made it very difficult for sophisticated users to use spreadsheets to their full capabilities. In contrast, the function INT still requires that INT((1/3)*3) is 1, because if INT does not do so, many user's spreadsheets will not work as they expect. The expected answers of INT may not make numerical analysts happy, but users will get what appears (to them) to be wrong answers otherwise.