Bug 76245 - Other: Support IEEE 754-2008 (ISO/IEC/IEEE 60559:2011) binary128 quadruple precision
Summary: Other: Support IEEE 754-2008 (ISO/IEC/IEEE 60559:2011) binary128 quadruple pr...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.2.1.1 release
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: Number-Format
  Show dependency treegraph
 
Reported: 2014-03-17 03:34 UTC by mycalb
Modified: 2020-10-11 19:32 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description mycalb 2014-03-17 03:34:15 UTC
Problem description: 
Isn't it time someone stepped out from the 1985 pack and offered a spreadsheet package at the top of the IEEE 754 standard - quad precision? 
 
Steps to reproduce:
1. ....just type more than 15 digits into a cell
2. ....or multiple any 8 digit number by any 9 digit number
3. ....etc

Current behavior:
the answer always ends in zero
Expected behavior:
Either a warning that the answer is inaccurate, or better still, the correct answer.

              
Operating System: All
Version: 4.2.1.1 release
Comment 1 Owen Genat (retired) 2014-04-05 04:26:40 UTC
(In reply to comment #0)
> Isn't it time someone stepped out from the 1985 pack and offered a
> spreadsheet package at the top of the IEEE 754 standard - quad precision? 

This is presumably a reference to IEEE 754-2008 (ISO/IEC/IEEE 60559:2011) "binary128" quadruple precision floating point, over and above the original IEEE 754-1985 "binary64" double precision. Summary amended for clarity.

This would appear to be an enhancement request, thus Severity set to enhancement. Status set to NEW, so that Calc developers can comment of the feasibility of this request.

Bug 37923 is possibly also related.
Comment 2 b. 2020-10-11 19:32:02 UTC
enhancements would be good, 

but quad precision (128 bit) may be slow on - actually common - 64-bit machines, 

and would only move the rounding problems to other areas, black/white +/- right/left wrong decisions like 'integer or not', 'where to round to' or other 'fp-problems' would still occur since the principle of replacing discrete decimal values by approximated but not exact fitting discrete binary values would not change,

the common fail is financial calculations (or other calculations with human given values with rather few decimals) failing on machines with 53 bit precision and top level cpu's and fpu's regarding artefacts from rounding when converting from decimal to binary number system, 

while calc doesn't solve that we'll get irritated questions over and over again, solved it would be an advance over ex$el, 

it cannot be solved by standardized rounding (this hides some errors and produces new ones elsewhere), but either by IEEE 754-2008 (not by 'quad-precision' but by 'decimal' data types), or by intelligent rounding, 

both have performance disadvantages ... either you have to use a switch for precision / performance, or calc could calculate 'fast' preliminary results and 'refine' them in the background while waiting for user input, 

working with 'precision as shown' for rounding holds for plenty cases, but fails for corner cases like '=INT(MOD(24,09;1)*100)' ...