ScInterpreter::ScGCD and ScInterpreter::ScLCM

Filippo giacchè filippo.giacche at
Mon Jan 2 17:46:51 UTC 2017

I have another question:
What are commit like this ?

Kind regards,
filippo giacchè

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

> Hey,
> On Fri, Dec 30, 2016 at 12:56 PM, Filippo giacchè <
> filippo.giacche at> wrote:
>> Hi to everyone,
>> I m trying to optimize ScInterpreter::ScGCD and ScInterpreter::ScLCM (in
>> /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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the LibreOffice mailing list