Talk:Documentation/Calc Functions/XLOOKUP

    From The Document Foundation Wiki

    "Array and Return must have the same amount of elements."
    We have discussed the use of "amount" vs. "count" in the ODF TC. I was told, that "count" (or "number") is used for things that can be count and "amount" for things that cannot be count. So I think "Array and Return must have the same count of elements." was correct. --Regina (talk) 09:06, 14 July 2024 (UTC)

    The alternative nouns should convey the same quantity of elements.
    • Count is not convenient. Besides being a (Calc) function itself, count as a noun is used for a sum (as a total), among other things.
    • Number could be potentially used, but it can generate misunderstandings, so I tend to avoid it in these cases. The confusion (for readers/users) arises when the "first element" is not numbered as "one". For example, with a table that starts in Row number 10 in Calc, does "row (number) 10" imply unambiguously the same "first row of the table"? Or, instead, does "row (number) 10" mean "Row 20 in Calc" (since the table starts at Row 10). Another source of confusion is when the counting of the number starts with zero instead of starting with one (as in binary base). In order to avoid potential confusion of the meaning of number of elements (e.g. in examples, and in broader explanations), I try to avoid using this noun when talking about Calc functions.
    • It is true that count and number are not supposed to be used with uncountable nouns, and thus we use amount instead (e.g. amount of chocolate). But IMHO it should be OK to use "amount of elements" in the context of the phrase we are discussing. For example, it is acceptable to say "I'll never be able to pay that amount", because it is about money. IOW, does the fact that count and number are not used for uncountable nouns mean that amount cannot be used for some semi-countable situations?
    • Another alternative term is quantity itself. IMHO, it is a term I would use in a more abstract/generic context.
    • I was tempted to use a different wording. Instead of "same count/number/quantity/amount of elements", perhaps "same size" would be adequate.
    I hope I am being clear. --Ady (talk) 10:38, 14 July 2024 (UTC)
    Using "same size" would be good. It has the advantage, that it covers at the same time, that the orientation of the arrays need to be the same. The proposal for the upcoming standard has the constrain "The Lookup_array shall be an 1-dimensional array in either a row or a column. If Lookup_array is in a row, the number of its columns shall be the same as in Return_array. If Lookup_array is in a column, the number of its rows shall be the same as in Return_array."--Regina (talk) 12:20, 14 July 2024 (UTC)
    As a side note:
    • "An 1-dimensional" should be "a 1-dimensional".
    • Questions: Is a "1-dimensional array" the same as "a Vector"? Is there a case in which these are not equivalent terms? Is the term/expression "a 1-dimensional array" more generic than "a vector"?
    I need to discuss it in the ODF TC, whether 'vector' would be better/possible. 'vector' is used in some describing texts and has no formal definition, whereas 'array' is a specified data type.--Regina (talk) 13:35, 15 July 2024 (UTC)
    • Since we are mentioning the upcoming Standard, I am not completely sure that both Lookup_Array and Return_Array (or however these arguments will be named) must be equal in size, strictly speaking:
      • If Return_Array is "larger" (or "bigger"?) than Lookup_Array, whichever the index values that were a match in Lookup_Array they are still achievable in Return_Array. Sure, Return_Array has a "useless tail", but, strictly speaking, is there a potential problem?
      • If Return_Array is "shorter" (or "smaller"?) than Lookup_Array, then _some_ index values in Lookup_Array cannot find a match in Return_Array (as the index does not exist). Wouldn't that just be a #N/A error, but only for those non-achievable cases? If the index values that are a match happen to be achievable in Return_Array, is there any reason for the result not to be returned? Why fail beforehand? Why add a strict constraint/limitation beforehand?
      • These 2 cases/questions might be relevant for non-CSE situations. Regarding the respective sizes of these arguments, I don't know whether there would be a different treatment when CSE is used, or what would happen when/if "dynamic arrays" were to be supported by Calc (and/or by the Standard).
    To be clear, other than the "an" vs "a" grammar matter, these are only innocent questions. People with much more knowledge and understanding of these issues should be much better equipped to "answer" them, in order to make the Standard as clear as possible (while also as flexible and/or as strict as really needed and convenient).
    --Ady (talk) 19:00, 14 July 2024 (UTC)
    The current proposal follows the actual implementation in Excel and LibreOffice. Changing it to rules similar to those that exist for LOOKUP would make the function XLOOKUP incompatible to Excel. That would contradict the purpose of implementing XLOOKUP in LibreOffice.--Regina (talk) 13:35, 15 July 2024 (UTC)
    Retrieved from "https://wiki.documentfoundation.org/index.php?title=Talk:Documentation/Calc_Functions/XLOOKUP&oldid=761194"