Bruce,

Other than thinking for sometime that a Matrix/Vector element would be
useful, we have only just begun to think of how it could be implemented
within DaveML. I intend to experiment with some different techniques and
will keep you posted - I think it may take some iterations to get a
suitable working solution that keeps the current dtd clean and
efficient, and all agree with.

Not sure what may be going on with the dsto mailing addresses but will
ask around.

Cheers
Geoff

-----Original Message-----
From: Bruce Jackson [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, 12 March 2008 11:20 PM
To: Brian, Geoff
Cc: Aerospace Sim Standard discussion group
Subject: Re: Matrix and Vector definitions for DaveML 

Geoff,

This is a needed improvement to DAVE-ML.

My first thought is the arrayDef attribute should be something like
'dimensions="3"' and then a (set) of subelements that define the actual
dimensions:

   <arrayDef name="myDataMatrixr_m" varID="myDataMatrix" units="m"  
dimensions="3">
     <dim>2</dim>
     <dim>6</dim>
     <dim>3</dim>
     <description>My Data Matrix is a 2x6x3 matrix; the last dimension
changes most rapidly</description>
     <initialValues>
        111 112 113  <!-- the actual order is important, not the way the
data is formatted -->
        121 122 123
        131 132 133
        141 142 143
        151 152 153
        161 162 163
        <!-- second plane shows another valid way of listing a 6x3
matrix -->
        211 212 213 221 222 223 231 232 233 241 242 243 251 252
          253     261   262       263  <!-- whitespace is unimportant  
-->
     </initialValues>
   </arrayDef>

I also need to think through a way to mux and demux from scalars, and
how well this fits into MathML matrix operations.

Have you guys been using this extension in any useful way?

Incidentally, the mailing list is getting rejections from several
dsto.defence.gov.au addresses, including yours:

> A message addressed to [EMAIL PROTECTED] in distribution

> list "simstds" has been rejected.


I'm working on a new revision to the 2.0 release that will hopefully  
accompany the initial AIAA/ANSI Standard, but I don't think we'll be  
able to get arrays defined by then.

-- Bruce

On Mar 11, 2008, at 11:00 PM, Brian, Geoff wrote:

> Hi all,
>
> I am gauging for interest in adding the ability to define a data  
> array element (such as a vector or n dimensional matrix) within the  
> Dave-ML dtd. First thoughts would be to include an element like the  
> "variableDef" maybe called "arrayDef" with attributes similar to  
> the variableDef, but with additional attributes defining the  
> dimensions for the array of data.
>
> For example:
>
> For a vector of size (4x1):
> <arrayDef name="myDataVector_m" varID="myDataVector" units="m"  
> dim1="4">
>
> For a 2-D matrix of size (4x6):
> <arrayDef name="myDataVector_m" varID="myDataVector" units="m"  
> dim1="4" dim2="6">
>
> For a n-D matrix of size (4x6x3x...):
> <arrayDef name="myDataVector_m" varID="myDataVector" units="m"  
> dim1="4" dim2="6" dim3="3" ...>
>
>
> The data associated with the array would need to be either stored  
> as a data table or computed using Math-ML expressions. It would  
> also be useful if an element of an array could refer to a  
> variableDef or another arrayDef (depending on the dimension of the  
> array). I would expect that if arrays were manipulated using Math- 
> ML then the interpreter (such as Janus) would need to manage the  
> compatibility checking  - that is outside the XML file.
>
> One of the significant advantages of having an array element within  
> Dave-ML would be the ability to encode matrix mathematics within  
> the XML file - via Math-ML. I would find this particularly useful  
> when processing axes transformation operations - eliminating the  
> requirement for addressing the components individually. Another use  
> would be the encoding of Inertia tensors and cg vectors as a single  
> variable instead of having a variableDef for each component. I am  
> sure there are many other uses.
>
> I await in anticipations for comments on this proposal.
>
> Geoff Brian
>
> Aircraft Performance and Flight Dynamics
> Air Vehicles Division
> Defence Science and Technology Organisation
>
> Ph: +61 (0) 3 9626 7318
>
> IMPORTANT: This email remains the property of the Australian  
> Defence Organisation and is subject to the jurisdiction of section  
> 70 of the CRIMES ACT 1914. If you have received this email in  
> error, you are requested to contact the sender and delete the email.
>
>
>

Reply via email to