Bug 37424 - Calc number autofill with decimal places
Summary: Calc number autofill with decimal places
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected)
3.3.2 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Markus Mohrhard
Whiteboard: target:3.6.0 target:7.2.0
Depends on:
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:

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

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 

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":


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":


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:

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