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: RE: [office-formula] More conflict - array and its subtypes


The square condition on MDETERM and MINVERSE is a special case (and one can
have MINVERSE for non-square matrices but that is more complicated).  There
is no square matrix requirement for the operands of MMULT and TRANSPOSE, and
the results need not be square.  In general, 2-dimensional matrices need
only be rectangular and ditto for arrays and the 2-dimensional cell "areas".

 - Dennis

MORE POTENTIAL JIRA FODDER:

TRANSPOSE: The diagram in in 5.5.6 doesn't work.  If the operand has m rows
and n columns, the result will have n rows and n columns.  If a[i,j] is a
cell of the operand and b[j,i] is a cell of the result, b[j,i]=a[i,j]. 

 

MMULT: I have never seen matrix multiplication defined the way it is for
MMULT in 5.5.4.  I thought it was because spreadsheets might have some
convention for viewing matrices via their transposes (that is, stating
column coordinates and dimensions before row coordinates and dimensions).
On closer examination, I think it is just a bug.

The constraint and the semantic definition are contradictory. Generally, the
result of matrix multiplication A*B will have the same number of rows as A
and the same number of columns as B.  

For this to work, the result cell in row i and column j must be the sum of
the products of the corresponding elements of a[i,*] and b[*,j].  That means
the * must range over the same number of elements in both A and B.  (This
notation, using "." instead of "*", is attributed to Albert Einstein and
makes it very easy to see what must match up with what.]

I am assuming that c[i,j] is the cell in row i and column j of the result,
and that for M x N, M is the number of rows and N is the number of columns.
This is consistent with the definitions found elsewhere in draft20.

   With that understanding, it should be that MMULT returns the matrix
product

     C(M x N) = A(M x K) * B(K x N) 

where indeed COLUMNS(A) = ROWS(B)

and C[i, j] = summation(k = 1 to K)(a[i,k]*b[k,j])

RELATED OBSERVATIONS

If A is N x N and it is the inverse of B, it is the case that MMULT(A,B) =
MMULT(B,A) = MUNIT(N).  The inverse of an arbitrary square matrix is not
assured to exist. (The anology is with 1/A being the inverse of Number value
A for A nonzero such that A*(1/A) = (1/A)*A = 1.)

Non-square matrices have inverses too, but there are two, a left one and a
right one.  We don't have to deal with that in OpenFormula because they can
be obtained, when they exist, by transformation.

Likewise, we probably don't want to deal with matrices having Complex
elements.

-----Original Message-----
From: Patrick Durusau [mailto:patrick@durusau.net] 
Sent: Thursday, February 11, 2010 14:16
To: dennis.hamilton@acm.org
Cc: office-formula@lists.oasis-open.org
Subject: Re: [office-formula] More conflict - array and its subtypes

Dennis,

On 2/11/2010 3:12 PM, Dennis E. Hamilton wrote:
> I notice that the expression "An array is a set of rows and the same
number
> of columns" is ambiguous and "that contain one or more values" is even
more
> so.
>
> I think it is meant to say that every row of an array has the same number
of
> columns, not necessarily the same number as the number of rows.  The array
> element at a particular row and column location presumably has at most one
> value.  (I will not here attempt to deal with the case where a table cell
> holds an array/matrix that is more than an 1 x 1.)
>
>    
Could be, but then I was being influenced by the explicit constraint of 
"square matrices" for 5.5.2 MDETERM, and 5.5.3 MINVERSE.
> A row vector is equivalent to an array with only one row, and a column
> vector is equivalent to an array with only one column in this regard.  One
> could consider either of row vector and column vector to be simply
> equivalent to a list or enumeration as well (and, as we have also seen, we
> can do so when taking elements of arrays in row-major or column-major
order
> too).
>
>    
True.

Hope you are having a great day!

Patrick

>   - Dennis
>
> -----Original Message-----
> From: Patrick Durusau [mailto:patrick@durusau.net]
> Sent: Thursday, February 11, 2010 11:55
> To: office-formula@lists.oasis-open.org
> Subject: [office-formula] More conflict - array and its subtypes
>
> Greetings,
>
> Reading "array" at 3.9:
>
>
>
>
>
> 	An array is a set of rows and the same number of columns that
> contain one or more values. There is a maximum of one value per
intersection
> of row and column. The intersection of a row and column may contain no
> value.
>
>
> But, back at 2.3 Non-Scalar Evaluation, we rather clearly describe "inline
> arrays" as being both that sort of array as well as only holding row or
> column vectors, which is excluded by the definition of array in 3.9.
>
> Is the term "inline" meaningful for some reason?
>
> Thinking that we have:
>
> Arrays - see 3.9
>
> SubType - one row array
>
> SubType - one column array
>
> SubType - singleton array
>
> And we need to untangle the "equivalence" of array and reference.
> Particularly since a reference obviously does *not* have to be to a square
> of columns and rows. That shoots any "equivalence" of arrays and
references
> rather squarely in the head.
>
> Thinking one way around this is to say that a reference may return an
array,
> or any of its subtypes (as listed above, subject to expansion). But
> returning an array (or its subtypes) and equivalence are different
concepts.
>
>
> Any subtypes of array that I am missing? (Noting that one column
non-scalar
> result is the same thing as one column array, etc.)
>
> This really does have the potential to make the draft shorter, more
concise
> and clearer.
>
> 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 



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