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

[Sheldon Britton <sab_orion@verizon.net>]

Hi All,

With reference to all the below attached; and, with particular reference 
to the two stated examples... from personal, business and professional 
standpoints.... I will tend to agree with Leonard's observations; and, 
while I cannot quote any figures at this time I would wish to make 
reference to three scenarios that were not mentioned by Leonard and 
there are as follows;

(1) Consider the possibilities of the military forces of the United 
States of America or that of the Russian Federation having to respond to 
the the threat of a falling satellite or an asteroid impacting Earth. 
(Most certainly the authorities would not wish to experience a repeat of 
a "*complete loss of guidance and attitude information*".
(2) and (3) The total figures with regards to the total global spending 
on energy per annum and the total amounts involved in global military 
spending respectively (not to mention the amount involved in the United 
States of America's housing crises).

Thus, if history serves as any measurement for "defining standards for 
what already exists" then the above examples and those referred to by 
Leonard ought to be considered as examples why "support for the 
double-extended data type" should be considered in a positive way/light.

Sincerely,

Sheldon A.Britton

David A. Wheeler wrote:
> 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
>
>