Bug 37424 - Calc number autofill with decimal places
Summary: Calc number autofill with decimal places
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.3.2 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Markus Mohrhard
URL:
Whiteboard: target:3.6.0 target:7.2.0
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-20 17:01 UTC by Vamsi Kodali
Modified: 2021-03-12 10:38 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample Document, see Comment 1 (9.54 KB, application/vnd.oasis.opendocument.spreadsheet)
2011-05-21 01:46 UTC, Rainer Bielefeld Retired
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vamsi Kodali 2011-05-20 17:01:14 UTC
To reproduce this bug: 

In a new spreadsheet, start the numbers in a column as follows: 1.0, 1.1, 1.2, 1.3 and then select all of them and drag so as to autofill the rows after the last number. As expected, Calc autofills them as 1.4, 1.5, 1.6, 1.7, etc.

Now, try the exact same thing but starting with a number other than 1. Say, 3.0, 3.1, 3.2, 3.3, etc. Calc does not autofill the column as 3.4, 3.5, 3.6, etc. Instead, it fills as 4.0, 4.1, 4.2, 4.3, 5.0, 5.1, 5.2, 5.3, 6.0, etc.
Comment 1 Rainer Bielefeld Retired 2011-05-21 00:48:04 UTC
[Reproducible] with "LibreOffice 3.4.0RC1  – WIN7  Home Premium  (64bit) German UI [OOO340m1 (Build:11)]"

Seems to be a very old bug, I also see it in OOo 1.1.4, 3.1.1, 3.4dev

I also see some curious side effects, pls. see attached spreadsheet. Numbers until row 10 are source, starting with 11 is result of auto fill using fill handle with all cells containing numbers marked when starting auto fill.

Blue numbers have been created by manual input (color added after autofill), black numbers in rows with row number smaller than 11 have been created by a calculation. 

Column A is expected behavior
Column B shows wrong behavior due to report

Column D: I typed 3.1, 3.2 into D7:D8, then I used autofill handle to fill 
          D9:D10. Now D7:D10 looks as B7:B10, but result is completely 
          different, here autofill works as expected with autofill D7:D10 using
          handle to fill to D11:D14 

@Kohei:
Please feel free to reassign if it's not your area!
Comment 2 Rainer Bielefeld Retired 2011-05-21 01:46:13 UTC
Created attachment 46969 [details]
Sample Document, see Comment 1
Comment 3 Markus Mohrhard 2012-04-14 12:51:20 UTC
Solved it by allowing the autofill increment calculation to have a bit more tolerance when checking that the increment between each cells is the same.

This has been a pure floating point problem.
Comment 4 Not Assigned 2012-04-14 16:29:34 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=cc94996d96ea8d8e3d136af66846707f9b838bbf

autofill increment needs a bit more tolerance, fdo#37424
Comment 5 Commit Notification 2021-03-12 10:38:00 UTC
Xisco Fauli committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/2fce798d70bb39fe1b1dc95e2661e5836026de1a

tdf#37424: sc_ucalc: Add unittest

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.