Greetings!
The chat log from our meeting today is attached below!
Hope everyone is at the start of a great week!
Patrick
Chat log - 11 December 2017
anonymous morphed into Thorsten
Jos van den Oever: Addition to the agenda: the holiday schedule.
Jos van den Oever: Patrick: dec 25 and jan 1 are both holidays so will not have meetings.
Please change your name from 'anonymous' using the Settings button
anonymous morphed into Patrick1
Jos van den Oever: Regina: one place in the spec uses the term ForceArray. When the function expects a single value and input is not a single value.
Jos van den Oever: Regina: this gives two behaviors: intersection and post-array evaluation
Regina Henschel: LOOKUP, FTEST, MODE
Jos van den Oever: Regina: in these functions it makes sense that an array should be used.
Regina Henschel: LOOKUP ForceArray Reference
Regina Henschel: FTEST, MODE: ForceArray NumberSequence
Jos van den Oever: LOOKUP may get a reference and this reference should be evaluated to the referenced array
Jos van den Oever: In FTEST it makes sense that the number sequence is an array.
Jos van den Oever: Regina: In other cases, the ForceArray is linked an actual array and hence makes no sense.
Jos van den Oever: Regina: proposal is to remove all the ForceArray that is not in LOOKUP, FTEST, MODE
Jos van den Oever: Regina: in FTEST there should be an explanation of how to use the number sequence as an array
Jos van den Oever: Patrick: I found an example of using ForceArray as a function
Jos van den Oever: Patrick: when ForceArray is invokde, the values are passed as an array
Jos van den Oever: Regina: what you see when you enter ForceArray as a formula, is not the same as ForceArray in the parameter description
Jos van den Oever: Jos: is there a function called FORCEARRAY?
Jos van den Oever: Andreas: No
Jos van den Oever: Patrick: here's a reference to what i mean
Jos van den Oever: Patrick: 6.3.4Force to array context (ForceArray)
Jos van den Oever: Regina: that description does not fit the use
Jos van den Oever: Andreas: Regina is write. The ForceArray makes sense when you have a reference to a single cell that should be an array
Jos van den Oever: Patrick: so if it already says 'Array' then 'ForceArray' is redundant
Jos van den Oever: Regina: in the three mentioned cases, there should be an explanation of what is done with the array
Jos van den Oever: Patrick: so it's a fair amount of redundancies that need to be taken out
Jos van den Oever: Patrick: we'll need a separate issue to get rid of the redundant ForceArray instances
Jos van den Oever: Regina: I count 17 functions that need adapting
Jos van den Oever: Regina: I'll create an issue and put the the function names in there
Jos van den Oever: Patrick: will we need separate issues for LOOKUP, FTEST and MODE
Jos van den Oever: Regina: at least for LOOKUP because it's not clear what to do with the '3d' reference (that goes over several sheets)
Jos van den Oever: Patrick: next thing: FTEST needs improvements
Jos van den Oever: Patrick will create separate issues for LOOKUP, FTEST and MODE
Jos van den Oever: Patrick: I'm assuming we're resolving 3905 by saying that we're not going to add ForceArray to it
Jos van den Oever: Regina: yes
Jos van den Oever: Patrick: We are resolving 3905 by saying that we're not going to add ForceArray to it
Jos van den Oever: Michael: can we close 3902 in the same way?
Jos van den Oever: Patrick: I don't know
Jos van den Oever: Regina: there are some more: COLUMNS, ROWS and INDEX on my list
Jos van den Oever: e.g. COLUMNS Syntax: COLUMNS( Reference|Array R )
Regina Henschel: Functions with Reference but without ForceArray are: COLUMNS ROWS HLOOKUP INDEX MATCH VLOOKUP. Where INDEX has ReferenceList.
Jos van den Oever: Regina: those functions need ForceArray because the type is Reference|Array
Jos van den Oever: Adding ForceArray would force the reference to be used as an Array
Jos van den Oever: Regina: If there explanation talks about how the reference is used, then ForceArray might not be needed because the description might be explicit on how to interpret each type
Patrick1: Semantics: Returns the number of columns in the range or array specified. The result is not
dependent on the cell content in the range.
Jos van den Oever: Patrick: In that case there may not be anything to do
Jos van den Oever: Regina: the word 'Range' does not fit 'Reference'
Jos van den Oever: Jos: Can't a reference be to a range?
Jos van den Oever: Regina: I'm not sure where a range is defined, but it's just a rectangle.
Jos van den Oever: Andreas: A reference is always a range because it's a cuboid of all referenced cells
Jos van den Oever: The word 'cuboid' is used because a reference can be 3d
Jos van den Oever: Regina: in such cases, perhaps ForceArray is not needed
Jos van den Oever: Andreas: yes because the function can work with reference as well
Jos van den Oever: Regina: This means that the issue about 3902 does not need ForceArray because it already has array as type
Jos van den Oever: Regina: so 3902 can be closed too
Regina Henschel: FTEST_Problems_and_Improvements.odt from the mail contains a proposal.
Jos van den Oever: Patrick: should we defer until next time so people can read that proposal?
Jos van den Oever: Andreas: the proposal in that document is fine with me
Regina Henschel: hypothese -> hypothesis
Jos van den Oever: Patrick: so we close that issue with that solution (which is already linked indirectly via the mail)
Jos van den Oever: Patrick: with one minute left we will not take on another issue
Jos van den Oever: Patrick: anything else?
--
Patrick Durusau
patrick@durusau.net
Technical Advisory Board, OASIS (TAB)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau