Re: ScInterpreter::ScGCD and ScInterpreter::ScLCM

Hey,

On Fri, Dec 30, 2016 at 12:56 PM, Filippo giacchè <filippo.giacche@gmail.com
> wrote:

> Hi to everyone,
> I m trying to optimize ScInterpreter::ScGCD and ScInterpreter::ScLCM (in /
> core <http://opengrok.libreoffice.org/xref/core>/sc
> <http://opengrok.libreoffice.org/xref/core/sc>/source
> <http://opengrok.libreoffice.org/xref/core/sc/source>/core
> <http://opengrok.libreoffice.org/xref/core/sc/source/core>/tool
> <http://opengrok.libreoffice.org/xref/core/sc/source/core/tool>/
> interpr5.cxx
> <http://opengrok.libreoffice.org/xref/core/sc/source/core/tool/interpr5.cxx>)
> as mentioned in bug tdf#89387..
> From what I understood , these function are not optimal in the matrix case
> (evenif the algorithms look good in my opinion) and need to be changed. So
> my question is how can I do it? If I create function in
> /core/sc/source/core/tool/ScMatrix.cxx that take as input a matrix and
> retuns the GCD(or LCM) I'll do ok?or is not the right way to proceed?
> thanks ,I welcome any advice that you can give me.
The task is not about changing the algorithm. The new matrix backend does
not have O(1) index based access any more so stuff like:

for (int i = 0; i < n; ++i)
{
    matrix.set(i, y, value);
}

is not a O(n) algorithm anymore.

However the new matrix backend provides some alternatives that allow to
write more efficient implementations (that are even faster -- by a constant
factor) than the old one. For that we need to use some of the constructs
written as part of this bug by . As an example for such a change look at
https://cgit.freedesktop.org/libreoffice/core/commit/?id=9a7959cd63be7b2f36da8af25e7673a525c4d66c
and try to understand how ApplyOperation and the operator play together.
All of this should make sense if you realize that we have no O(n) index
access but that iterator access is in O(1).

If you need a bit more details after looking at some of the commits in the
bug report you can ping me again.

Regards,
Markus