Created attachment 52898 [details] Sample for Linear Trend Line Equation Bug When adding a linear trend line with it equation displayed, the equation shown is sometimes incorrect and does not match the correct trend line displayed. Sample small and simple .ods data file included.
Reproduced with LO 3.4.4 Ubuntu 10.04.3 x86 Linux 2.6.32-34-generic Russian UI
Reproduced in 3.5.0.
Still reproducible on LO 4.0.4.2 (Win7 32bit). Wrong equation shown on attached file, also if reproducing with new spreadsheet. Rechanging: Version to: 3.4.3 -> oldest release been reported Platform : All -> also affect Windows (should be all platform bug) I think it is a major/critical problem because wrong data (equation) displayed
Not sure this is a bug : Help says : "If you insert a trend line to a chart type that uses categories, like Line or Column, then the numbers 1, 2, 3, … are used as x-values to calculate the trend line." see https://help.libreoffice.org/schart/.uno:InsertMenuTrendlines?Language=en-US&System=WIN&Version=4.3#bm_id2001709 With X/Y (scatter) chart I get expected result: f(x) = 0.9x + 0.5
(In reply to comment #4) > Not sure this is a bug : > Help says : > "If you insert a trend line to a chart type that uses categories, like Line > or Column, then the numbers 1, 2, 3, … are used as x-values to calculate the > trend line." > see > https://help.libreoffice.org/schart/.uno:InsertMenuTrendlines?Language=en- > US&System=WIN&Version=4.3#bm_id2001709 > > With X/Y (scatter) chart I get expected result: f(x) = 0.9x + 0.5 GerardF, it seems that you are quite right about the help. However: 1. In the example given in the file, the trend line and the equation differ. Indeed the equation is in sync with the text of the help. The trend line is "more in sync" with the user expectations. 2. There is a bug one way or the other as the trend line and the equation disagree. 3. I vote to fix the help and the equation since it will better reflect the user expectations. Furthermore, I believe (I seem to recall this although I have not checked) it is more in line and compatible with Excel (which I think is an important consideration).
Reproduced in 4.1.3.2
(In reply to comment #5) > (In reply to comment #4) > > Not sure this is a bug : > > Help says : > > "If you insert a trend line to a chart type that uses categories, like Line > > or Column, then the numbers 1, 2, 3, … are used as x-values to calculate the > > trend line." > > see > > https://help.libreoffice.org/schart/.uno:InsertMenuTrendlines?Language=en- > > US&System=WIN&Version=4.3#bm_id2001709 > > > > With X/Y (scatter) chart I get expected result: f(x) = 0.9x + 0.5 > > GerardF, it seems that you are quite right about the help. > > However: > > 1. In the example given in the file, the trend line and the equation differ. > Indeed the equation is in sync with the text of the help. The trend line is > "more in sync" with the user expectations. > > 2. There is a bug one way or the other as the trend line and the equation > disagree. > > 3. I vote to fix the help and the equation since it will better reflect the > user expectations. Furthermore, I believe (I seem to recall this although I > have not checked) it is more in line and compatible with Excel (which I > think is an important consideration). I am standing corrected. From Excel docs @ https://office.microsoft.com/en-us/excel-help/add-change-or-remove-a-trendline-in-a-chart-HP010007461.aspx "If you add a trendline to a line, column, area, or bar chart, the trendline is calculated based on the assumption that the x values are 1, 2, 3, 4, 5, 6, etc.. This assumption is made whether the x-values are numeric or text. To base a trendline on numeric x values, you should use an xy (scatter) chart." So it seems that LibreOffice is consistent with MS-Office. As for the disagreement between the line and the equation - it is only seemingly so since the line cannot be interpreted based on the labels. This is somewhat unfortunately, but for the purpose of controlling the x values, indeed only scatter chart can be used.
*** Bug 129398 has been marked as a duplicate of this bug. ***