https://bugs.documentfoundation.org/show_bug.cgi?id=154557

ady <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|1                           |0
             Status|NEEDINFO                    |UNCONFIRMED

--- Comment #3 from ady <[email protected]> ---
(In reply to Buovjaga from comment #2)
> Possibly each of the issues would deserve its own report, but let's go like
> this for now.

The function needs to be reviewed, probably as a whole. Splitting the issues
would make it more difficult, IMHO.

> 
> Please provide explanations for each of the issues as they are reflected in
> your example file. Testers should not need to think.

I wished every reporter would take the same approach. Unfortunately for this
case, we need someone that understands what RANK() is supposed to do, in order
to understand why I marked some cells with yellow.

> 
> Testing with 3.5, I see all the cells with yellow background colour have
> either #VALUE! (L-P) or #NAME? (S-W).

If you test with LO 4.0 or with any current version (7.4 or 7.5), you will see
the difference. If you can also test equivalent formulas in some other
spreadsheet tool, the difference is even more clear.


A_ Columns B:C use RANK() on Data, with the respective Values taken directly
from the same Data range. Besides valid values within Data, there are also "a",
"1" (potential valid value, but not within the range of values in Data) and an
empty cell.

B_ Columns F:G use RANK.AVG().

C_ Column K is a set of possible values for the Value argument for RANK().

D_ Columns L:M use column K as Value for RANK(), with Data being A3:A7.

E_ Columns O:P use RANK.AVG().

F_ Columns S:T is similar to "D_" but with duplicate values in Data, A3:A10.

G_ Columns V:W use RANK.AVG().


Now I'll try with each relevant item from comment 0. Let's hope its enough
explanation.

0.n > self explanatory.

1. For Values 1 and 10 in attachment 186403, the result should be #N/A.

2. In attachment 186403, when Type is 1 and Value is between 1 and 10 (but not
them), the result (since LO 4.0) is "-1". It should had been #N/A. This is
different than with any other spreadsheet tool, and different than L0 < 4.0. I
couldn't find any reference to this change in the Release Notes. This
(distinct) behavior can affect additional calculations, so I would had expected
some documentation (including the reasoning, especially when it is different
than other spreadsheet tools).

3. Similar case as point 2, but with Type = 0. The result (positive numbers) is
simply incorrect, and worse than point 2. This should had been #N/A.

4. Embarrassing "Oops!" for me. I apologize for describing this incorrectly in
comment 0. It should had been "RANK.AVG" instead of "RANK.EQ" in this point –
the latter is equivalent to RANK(). I used RANK.AVG() instead of RANK() as used
in prior points, and the result was even worse than with RANK(). In attachment
186403, see columns V:W (in addition to some others). The maximum rank should
had been 7. Here we not only have incorrect positive results where there
shouldn't be (as in point 3) but the results can be greater than 7.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to