<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - FILEOPEN: XSLX - MODE results in wrong calculation" href="https://bugs.documentfoundation.org/show_bug.cgi?id=97977#c26">Comment # 26</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - FILEOPEN: XSLX - MODE results in wrong calculation" href="https://bugs.documentfoundation.org/show_bug.cgi?id=97977">bug 97977</a> from <a class="email" href="mailto:winfrieddonkers@libreoffice.org" title="Winfried Donkers <winfrieddonkers@libreoffice.org>"> Winfried Donkers</a> <pre>(In reply to Dennis Roczek from <a href="show_bug.cgi?id=97977#c23">comment #23</a>) [...] > > Upon exporting to > > OOXML, it ought to be renamed to MODE.SNGL of MODE.MULT (haven't time to > > figure out which, right now). Currently it isn't, it's saved as MODE in > > OOXML. > Well then we do have another problem. :-( > > I just tested with Excel 2016 O365 (desktop app) version: all three variants > of Mode (with the following numbers (9;1;5;1;9;5;6;6)) give as a result 9 > back. > > LibreOffice Calc does calculate a 1 (as stated in our help). > Currently, MODE and MODE.SNGL are identical in Calc. I can change that so that MODE.SNGL and MODE.MULT return 9 with MODE.XX(9;1;5;1;9;5;6;6), i.e. the first value with the maximum occurences. That way the OOXML-functions are fully compatible with Excel. (Not assigning myself to this bug report as the fix for MODE.SNGL and MODE.MULT are no fix for MODE.) Mapping MODE to MODE.SNGL when exporting to OOXML has no effect; the results in Calc stay different from those in Excel. The difference for these special cases will probably remain unless either OOXML specs of ODFF standard is changed.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>