RE: [office-formula] Non-Scalar Evaluation and References

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

This doesn't work.

The problem is that different functions can interpret their parameter forms
differently.  

This can only be figured out top-down (which is where the bottom-up
evaluation model breaks down).   We need to specify a top-down model so that
the interpretations of parameter forms and other special forms work
properly.  Whatever is produced by an evaluator, it is equivalent to that
whether or not the actual calculations are done bottom up or in some sort of
multi-pass combination.  The variability is also influenced by how "eager"
the processing model is required to be and where it can be lazy (and what
the specific triggers for recalculation are).

 - Dennis

SOME THOUGHT EXPERIMENTS:

Suppose I see these function reference forms, where [.M3] resolves to
current value -3 and [.P6] resolves to current value 6 in all cases:  

  x(-3)

  x(-3;6)

  x({-3})
  
  x({-3;6})

  x([.M3]:[.P6])

  x([.M3];[.P6])

  x([.M3]~[.P6])

  x([.P6:.M3])

  x([.M3:.P6]![.3]![.M])

  x([.M]![.6])

  x( INDIRECT(ADDRESS(13,-[.M3]) & ":" & ADDRESS(17,[.P6])) )

what happens here depends on what x is.  Some cases may be invalid for x
(though that doesn't prevent their being found in a formula, especially
because there are dynamic cases such as the last example, above) and others
will be valid for more than one x but have quite different interpretations.


Try this for x being ABS, COMPLEX, SUM, AREAS, COLUMN, COLUMNS, COUNT,
ISFORMULA, and MINVERSE.

I am sure there are more interesting anomalous cases, such as CHOOSE which
one hopes is lazy and other oddities like INDEX and INDIRECT.

Also, I can imagine implementations that vary considerably in what happens
for cases that are not defined for OpenFormula du jour, yet they might be
consistent in some systematic way.

[These convince me that there have to be Reference data types after all, and
that gets even more confusing since a Reference type value can designate
more complex structures than cuboids and whether Reference type values (as
opposed to the syntactic forms) are ever other than absolutely-located
structures is also an issue.]

[Then we need to consider structured types (arrays and matrices, plus
homogenous and non-homogenous lists/enumerations of various flavors and what
the implicit conversions among them, Reference types, and scalar types are).
It is also apparent from the definition of certain functions that some
implicit conversions are not intended even though they would be applicable.
Oh boy.]   

  

-----Original Message-----
From: Patrick Durusau [mailto:patrick@durusau.net] 
Sent: Tuesday, February 09, 2010 07:05
To: office-formula@lists.oasis-open.org
Subject: [office-formula] Non-Scalar Evaluation and References

Greetings!

OK, to continue with non-scalar evaluations and references.

A reminder, we start off with:

>   1.
>
>       Evaluation as an implicit intersection of the argument with the
>       expression's evaluation position.
>
Actually that's a lie, we start with:

> Non-scalar values passed as arguments to functions are evaluated by 
> intersection or iteration.
>
Which isn't true either. Non-scalar values are either evaluated as 
matrices or not. No reason to invent terms.

Anyway, back to non-scalar evaluation and references.

Let me say the principle and see if I get that right:

An expression occurs in some particular cell and that expression is a 
function that has a reference as its input. (OK so far?)

The value returned to the function is the "intersection" of the 
reference with the cell where the reference occurs.

If the cells specified by the reference don't intersect with the cell 
where the reference occurs, the value #VALUE is returned.

Yes?

The nature of the reference, whether row-vector or column-vector, isn't 
relevant.

Unless the intent was to limit those references to column and row 
vectors but then we would have to say that wouldn't we?

So I would restate References to read:

***
If a reference is passed to a function and not evaluated as a matrix, 
the value at the intersection of the cell where the reference occurs 
with a cell in the reference, if any, is returned to the function.

If there is no intersection between the cell where the reference occurs 
with a cell in the reference, the value #VALUE is returned. (full stop)
***

Shorter and to my way of thinking much clearer than what we have now. 
For one thing it doesn't have all the undefined references ("evaluation 
position's row" for example).

BTW, looking ahead, we can drop the reference to ODF 8.13 
table:number-matrix-column-spanned for the more general:

2) Matrix evaluation

Which makes it more general to all OpenFormula evaluators.

I have to re-write the next section to not use display as the basis for 
the operations but that comes next.

Hope everyone is having a great day!

Patrick

-- 
Patrick Durusau
patrick@durusau.net
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)


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php