Re: [office-comment] Integer Overflow and number Types in ODF

["David A. Wheeler" <dwheeler@dwheeler.com>]

Leonard Mada:
> while examining recently an OOo Calc issue, I came across a major 
> ODF-shortcoming.

This isn't major.  For nearly all uses, this is irrelevant, and it
would be foolish for a user to depend on these kinds of precisions
when exchanging documents among spreadsheets because NO
spreadsheet implements what you're requesting.
In engineering, you're lucky to have two significant digits.
In budgeting, I know of no one that uses spreadsheets for
such a truly large range and actually cares; generally they
get rounded to "human-readable" results and again these
extreme precisions are unneeded.

I strongly encourage experimentation and improvement;
innovation is a wonderful thing.  But this is a standards committee.
We are defining standards for what already exists.  We want to know
about innovations so that we can avoid accidentally forbidding them,
but standards bodies are simply not the right forum to add
brand-new untested requirements to an established market.
Create a spreadsheet implementation with these great new
precisions, and if enough people use it, perhaps we could
define a niche extension for that group.

> A recent bug posted on the OOo Bugzila documenting a miscalculation in 
> OOo Calc (as well as in MS Excel and probably other spreadsheet 
> programs, see: http://www.openoffice.org/issues/show_bug.cgi?id=91358), 
> prompted me to revisit old notes and articles on floating point 
> calculations.
> 
> BUG DESCRIPTION
> ================
> Basically, the bug goes like this:
> =29513736*92842033 yields: 2740115251665290.
> This is plainly wrong.

No, that's not a bug.  That is obviously acceptable behavior,
and the spec even makes it clear that this is acceptable.

All existing spreadsheet implementations use 32 or 64 bit
binary floating-point numbers; in certain cases some MAY
use another (80-bit) but predicting when that occurs is
quite tricky.  An implementation is free to
do better, and we've carefully spec'ed it to permit better,
but it would be unwise to expect better.

The specification does not forbid implementing exact integers,
so the specification does not limit future improvements.

> However, the user does NOT get any notification 
> that an integer overflow did occur.

That is by design.  Users of scientific calculators don't get any
such notifications either, but most scientific calculators
do integer overflow too.

> The IEEE Standard for Binary Floating-Point Arithmetic (ANSI/IEEE Std 
> 754-1985) implements various formats for representing floating-point 
> values. ODF seems to omit any clear specification in this regard, and 
> also seems to imply that only one format should be used.

If you can point to a place where it _requires_ one format, let me know;
that should be removed.

We can't reasonably reference the binary format; at no time do we
use a binary format.  And I don't think we can actually mandate the
exact IEEE rules for floating-point operations, either.
IIRC, Intel chips cannot follow the rules exactly
without a severe performance penalty, so I believe all actual
spreadsheet implementations intentionally do NOT follow them.
So there is nothing left to mandate.

There is no point in creating a beautiful specification that will not
be used.

--- David A. Wheeler