ScInterpreter::ScGCD and ScInterpreter::ScLCM

[Filippo giacchè]

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 at googlemail.com>:

> Hey,
>
> On Fri, Dec 30, 2016 at 12:56 PM, Filippo giacchè <
> filippo.giacche at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20170102/c6186bbd/attachment.html>