Re: ScInterpreter::ScGCD and ScInterpreter::ScLCM

hi,
I have another question:
What are commit like this ?
http://cgit.freedesktop.org/libreoffice/core/commit/?id=32950e9089aa323303154156c27f713ba3efdf85

Kind regards,
filippo giacchè

2016-12-30 12:41 GMT+00:00 Markus Mohrhard <markus.mohrhard@googlemail.com>:

> 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