[Libreoffice-commits] core.git: sc/source

[Tor Lillqvist]

 sc/source/core/opencl/op_spreadsheet.cxx |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

New commits:
commit 32b35d9d8a21091b987d94fc2ad24d69e9d8a6f3
Author: Tor Lillqvist <tml at collabora.com>
Date:   Tue Aug 25 18:25:47 2015 +0300

    Return correct value from the OpenCL VLOOKUP implementation
    
    The commit c3383aafa18ef9d03b04b2a4719e71fdfabc14eb was missing an !
    operator in two places where it checks whether a cell is a numeric or
    string one, resulting in it always using the string value, which for
    NULL (the case I was looking at, only numeric cells in the array)
    meant zero was returned.
    
    As such I am not sure if it is entirely correct to do the check
    whether a cell is a numeric or string value in the order the generated
    OpenCL code does here (and all over the place perhaps). The
    documentation in <formula/vectortoken.hxx> says:
    
     * Single unit of vector reference consists of two physical arrays.
     *
     * If the whole data array consists of only numeric values, mpStringArray
     * will be NULL, and NaN values in the numeric array represent empty
     * cells.
     *
     * If the whole data array consists of only string values, mpNumericArray
     * will be NULL, and NULL values in the string array represent empty
     * cells.
     *
     * If the data array consists of numeric and string values, then both
     * mpNumericArray and mpStringArray will be non-NULL, and a string cell will
     * be represented by a non-NULL pointer value in the string array.  If the
     * string value is NULL, check the corresponding value in the numeric array.
     * If the value in the numeric array is NaN, it's an empty cell, otherwise
     * it's a numeric cell.
    
    Note how that implies one should first check whether the value in the
    string array is NULL or not, and only if it is NULL, look at the vale
    in the numeric array. The code in the generated OpenCL VLOOKUP
    implementation does it backwards. Scary. But probably equivalent for
    the subset of cases we actually handle in OpenCL, which (I think) are
    those where no string cells are involved.
    
    More bug fixes for the OpenCL VLOOKUP will follow.
    
    Change-Id: Id567c245a0700267584be6032320863a4a66df83

diff --git a/sc/source/core/opencl/op_spreadsheet.cxx b/sc/source/core/opencl/op_spreadsheet.cxx
index c005d2a..6ade850 100644
--- a/sc/source/core/opencl/op_spreadsheet.cxx
+++ b/sc/source/core/opencl/op_spreadsheet.cxx
@@ -174,7 +174,7 @@ void OpVLookup::GenSlidingWindowFunction(std::stringstream &ss,
                 else
                 {
                     ss << "        {\n";
-                    ss << "            tmp = isNan(";
+                    ss << "            tmp = !isNan(";
                     vSubArguments[1+j]->GenNumDeclRef(ss);
                     ss << "[rowNum])?";
                     vSubArguments[1+j]->GenNumDeclRef(ss);
@@ -259,7 +259,7 @@ void OpVLookup::GenSlidingWindowFunction(std::stringstream &ss,
                 }
                 else
                 {
-                    ss << "            tmp = isNan(";
+                    ss << "            tmp = !isNan(";
                     vSubArguments[1+j]->GenNumDeclRef(ss);
                     ss << "[rowNum])?";
                     vSubArguments[1+j]->GenNumDeclRef(ss);