[Libreoffice-bugs] [Bug 125580] Wrong value when adding two dates

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=125580

b. <newbie-02 at gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|regression                  |

--- Comment #14 from b. <newbie-02 at gmx.de> ---
(In reply to Eike Rathke from comment #13)
> (In reply to b. from comment #12)
... 
> And that is completely unrelated and thus off-topic because this bug here is
> not about any fill series but explicit user supplied formula expressions
> accumulating an error. 

yes, SIR!, YES!, 

but with all due respect, and i politely apologize that i have to try to
clarify three things: 

1. it's less the 'user defined formula' accumulating deviations, but 'fp-math'
and how calc displays timestamps, in three steps: 
   a. the IEEE 754 double value for 5 minutes is already short by ~
2.22222222E-19 because it's an endless fraction truncated after 53 bits, 
   b. this value looses it's last 24 bits (011100011100011100011100) accounting
for appr. 3.2337587468900253E-12 in the addition to a value in the range of
today() by crossing 24 bin ranges from -9 to +15, and that without compensation
by rounding because the chopped off string starts with a '0', 
   c. thus the really added portion accounts for only ~ 0.0034722222189885,
corresponding to a time value of ~00:04:59,9999997206 [hh:mm:ss,0000000000] 
   d. as calc's display for date and time values doesn't round minutes the
deviation becomes visible already at very small portions and looks 'boosted' in
strings formatted to show minutes but not seconds, 

2. what the OP was talking about is not! his formula being erroneous, but he
asks for explanation why it fails in 'dragfill' (which imho is just another
interface to construct a fill series), 

3. despite this situation which would also justify other proposals ... what i'd
propose is! exactly that: a replacement for the user defined formula avoiding
accumulation of errors (exactly it is / needs two combined formulas), 
   a. despite similar could - and imho should - be realized in code it also
can! be used in user space as formula in sheet or similar implemented as a
macro, it's an exactly targetted solution for the OP problem, imho the
simpliest covering the full complexity ... 

thus sorry SIR!, imho you'd shoot fast but a little bit off, please reactivate
the suppressed comments. 

@Alexandre Rio: 'but doesn't work with only =NOW() function in first cell.'
results from 'now' mostly! not being a value with 0,00000 seconds, thus there
is some 'buffer' to compensate the too small represented increment, and thus
the problem will show up later after plenty additions, but will ... despite the
buffer bridges to a range where the increment get's chopped before a 1 and will
be rounded up, then the fail will run in the other direction ... 

removing 'regression' as the change in time stamp handling is intentional,

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20210410/33963801/attachment.htm>