OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Non-Scalar Evaluation


I have read this particular section more than once, ;-) , and must admit 
that I am still puzzled at its purpose.

I suppose part of what I am missing is what "evaluation" is being defined.

Talk for example 2.1) Storing a non-scalar result in a matrix is 
controlled by a few rules. (NB, we need a better section title here.)

 It doesn't appear to be defining any evaluation at all. Simply the 
addressing of a matrix, which I think is defined elsewhere.

Then 2.2 Calculations with non-scalar inputs are generalizations of 
(2.1). (title issue)

Shouldn't requirements for matrix functions be defined at those 
functions? Or perhaps for those functions as a group, but then that 
would be in one of the subsections of chapter 6 and not here.

BTW, I am sure that "unexpected non-scalar argument" is meaningful to 
someone but not me. ;-)

Not to mention:

> Unary/Binary operators other than range and union can be considered 
> functions taking scalar arguments for the purposes of this discussion. 
> Similarly inline arrays and references are interchangeable.

I think it would be much clearer to define the inputs accepted by 
functions and then it would be possible (not necessarily advisable) to 
make references to all the functions that accept X as input.

I have no idea what it means to say: "Similarly inline arrays and 
references are interchangeable." If that is true, then why have both? If 
it isn't true, under what circumstances is it not true?

What would be helpful for me at this point would be:

1) A clear statement of what was intended to be accomplished by this 
section. That is, what as a person reading this part of the standard 
would I learn and where would I apply what I learned?

2) A defining of things like "unexpected non-scalar argument" and when 
would I encounter such a thing.

3) Does range = ":" and union = "~"? (It is hard to tell when I am 
seeing keywords versus just words.)

4) In what way are (or are not) inline arrays and references 

5) Are functions returning arrays eligible for *explicit* iteration?

6) BTW, I don't recall seeing a definition for terms like "singleton 
array," "column vector," "row vector," etc. It isn't necessary to define 
everything but I think we do have to define things that then are used to 
express limits or requirements on the format.

Generally speaking I would like to do the following with this section:

A. Definitions as appropriate and in the right places.

B. Cast out all the example material. If we can't say it clearly then we 
shouldn't be saying it at all.

C. Define the result of the evaluation of an argument based on its type. 
That is if the argument is of type "matrix," then define what evaluation 
of that means. Different functions may give different results but those 
should be defined at those functions. Yes?

D. Shouldn't result matrices be defined by the functions that return 
them? (Or is the argument here that all result matrices share some 
common characteristics?)

Hope everyone is having a great day!


Patrick Durusau
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]