<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Filling cells with incremental numbers – wrong numbers" href="https://bugs.documentfoundation.org/show_bug.cgi?id=55960#c18">Comment # 18</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Filling cells with incremental numbers – wrong numbers" href="https://bugs.documentfoundation.org/show_bug.cgi?id=55960">bug 55960</a> from <a class="email" href="mailto:newbie-02@gmx.de" title="b. <newbie-02@gmx.de>"> b.</a> <pre>just an idea ... intelligent rounding may lead to intelligent faults? the user expects a value / number fitting his input and his idea what to calculate, A) would it work to round to the number of digits the user formatted the cells to ... ??? B) or just bring 'precision as shown' to work, A: the format of the input cells is applied to the targets on dragfill? either from them being formatted as 'two decimal places' or from having input of that length it would be legitim to round the dragfill results to that frame? (i know that @Mike doesn't like the format affecting the result ...) B: i tried dragfill with 'tools - options - libreoffice calc - calculate - precision as shown' activated, and expected the artefacts to go away ... they didn't ... :-( even calculating a series of "=x+,05" starting from -2 with cells formatted to two decimals and precision as shown activated produces 'artefacted values', you can see that by replacing the formulas with their results (strg-c - shift-strg-v with 'formulas' deactivated) while still formatted to two decimals, and then observing the input line or reformat the cells for more decimal places ... maybe i misunderstood the idea, concept or power of 'precision as shown'??? but it was once recommended to me as a solution against fp rounding errors tested with 6.2.8.2 winx64 unpar. reg. b.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>