Am 02/13/2013 06:43 PM, schrieb Rob Weir:
This topic seems to be of more general interest, given the discussions
we've been having regarding the evaluation of 0^0.
When we were writing up the specification of ODF 1.2's OpenFormula we
had the goal to describe how real-world spreadsheet applications
worked today. Where they worked the same then we wrote up in detail
how they worked. Where there was variance among implementations then
we tried to describe the bounds within which current applications
behaved. So our work was mainly descriptive. There is not a stick
big enough to force (at that time) Sun, Microsoft, IBM, Google as well
as Gnumeric and KSpread (now Calligra) to change their
implementations.
This lead to a series of behaviors which were specified to be
"implementation-defined", or in some case "locale-defined" or
"unspecified". These are subtly different, and express nuances common
in standards, what we refer to as "dimensions of variability". The
W3C has a note on the topic: http://www.w3.org/TR/spec-variability/
But essentially, standardizers try to strike a balance between
interoperability and cost to implement a standard. Even with physical
standards, say for a screw or a bolt, there are tolerances give. The
screw must have a length of 3cm +/- 0.1mm, for example. If the
tolerance were set much higher then the cost to conform would
skyrocket, but the incremental interop benefits would diminish. So
the art of standardization the art of finding the right balance. This
is political also, so it is also in the realm of the "art of the
possible" in any given time and place.
So.... when putting together OpenFormula I created a spreadsheet to
collect together the 61 implementation-defined or unspecified
behaviors in OpenFormula. If any is really interested in this area
I'd recommend reviewing this spreadsheet. It is a lot easier/faster
than reading the ODF 1.2 specification:
http://markmail.org/thread/iz2gggmwednmchqe
If we ever do go to a warning mode in Calc, where users are warned
about potential calculation issues, these would probably be ones that
we would check for.
Thanks a lot for showing us what else is not "written in stone" but
depends on the respective application how it is implemented. 61 is an
impressively high number.
Besides a feasible warning mode, maybe it's also possible to bring the
high number down and with the remaining stuff we could create a new
options tabpage, to leave it to the (power) user what result she/he
would like to have.
The default value (e.g., 1) and the other posibilities (e.g., 0, error)
could be described in help topics, so that the users can look by
themselves why AOO is showing this result / error.
Marcus
