https://bugs.documentfoundation.org/show_bug.cgi?id=77834
--- Comment #16 from b. <[email protected]> --- brainstorming: - it's not likely that IEEE 754 will change 'normalized' handling for binary datatypes, - it's not likely that Excel, and following suit Calc, will switch to another math engine, - IEEE provides 'decimals saving' for the decimalxxx datatypes, it comes with it's own set of issues and isn't yet well matured, - you can get them in 'gnumeric', as experimental, but AFAIK they stripped trailing zero conservation, - if ... it's really relevant to you there already is an option, enter your input as string, e.g. '0.200 with! the leading apostrophe, you can format that right aligned then looking like a number, and Calc will convert it to 'value' and happily calculate with it when addressed in formulas. - be aware to check for evtl. traps / unexpected behaviour, e.g. low level supporters analysing sheets from others and identifying 'text' by 'left aligned' will like to fail. - be aware that the workaround provides 'input conservation', but no effect on calculation results, - which IEEE 754 decimals try to provide, with very questionable results, e.g. adding 0.200 ( relatively imprecise ) and 0.10000000000 ( higher precision ) results in 0.30000000000, faking a precision which is not! provided by the first operand ( but faking is fashionable since Trump? ). Think we can close this report if the OP is satisfied with the workaround. -- You are receiving this mail because: You are the assignee for the bug.
