Description: Moving Average Trend Line doesn't conform to any "smoothing" criteria imposed on the underlying "smoothed" line chart. As a comparison, the Polynomial line is "smoothed" See attached .ods with the resulting chart line and two trend lines. As a side line, is there a rationale for having version history extending all the way back to 3.3.0 release? Steps to Reproduce: See attached sheet SmoothLine.ods If desired, clear and recreate the green & red trend lines Green is a 3 event moving average & red is a 6 Deg Polynomial or simply right click and edit the parameters There only exists a setting to "smooth" the base chart line One might infer from the lack of setting for the trend lines that the waveform for all the trend lines would correspond to the baseline. It appears that the more complex formulaic trend lines follow the defined smoothness of the baseline whereas that for the 3 event moving average trend line does not. Actual Results: 3 event moving average trend line is not "smoothed" Expected Results: I would have assumed a smooth line Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: Version: 7.0.4.2 (x64) Build ID: dcf040e67528d9187c66b2379df5ea4407429775 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: sv-SE (en_GB); UI: en-GB Calc: threaded
Created attachment 169105 [details] simple ,ods with chart & trend line function
Actually none of the trend lines are smoothed but they look smooth because they are transformed into an approximated function, which is then sampled for drawing. That's not the case for moving average, which is different kind of transform, which results in averages of input values, not a function. So the question is if we should allow to also "smooth" that line or not. For example Excel doesn't - you can smooth a data line, but not a trend line.
> > So the question is if we should allow to also "smooth" that line or not. For > example Excel doesn't - you can smooth a data line, but not a trend line. If asked, I would observe that not smoothing the line gives a slightly less professional look. No, I don't line all my fish sticks up on the plate 😉
(In reply to Colin from comment #3) > > > > So the question is if we should allow to also "smooth" that line or not. For > > example Excel doesn't - you can smooth a data line, but not a trend line. > > If asked, I would observe that not smoothing the line gives a slightly less > professional look. > > No, I don't line all my fish sticks up on the plate 😉 I would also observe that we do lots of things better than Excel - try sorting an auto filtered array with non-array cells referencing that array. Sometimes you're lucky. If we can be better and still not shoot ourselves in the foot when it comes to exporting to xlsx I would argue that it's worth the effort if it's not too onerous a task and we have the resources.
Here is a workaround: Add a column D to your spreadsheet which calculates a running average of column C and add it as to the plot separately as a smoothed line.
(In reply to Louis Steinberg from comment #5) > Here is a workaround: Add a column D to your spreadsheet which calculates a > running average of column C and add it as to the plot separately as a > smoothed line. Hi Louis and thanks for your endeavours: I have already added columns for 3,7,10&14 event moving averages - 5664 "surplus" cells with a daily "growth" rate of +20 for the four new data elements. 400% overhead for smooth lines :(. As the columns are autofiltered and the charts can react to any filtering or sorting, that predicates quite an overhead when each new data element is appended and a new "snapshot" taken. It's almost as if one can see the cogs turning ;). Thanks again.
Dear Colin, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Version: 25.8.2.2 (X86_64) Build ID: d401f2107ccab8f924a8e2df40f573aab7605b6f CPU threads: 4; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Raster; VCL: win Locale: sv-SE (en_SE); UI: en-GB Calc: threaded Still the originally reported result