RE: arrayDef & draft simstd comments
Hi Bruce, Thanks for taking the time to look at this. I've been trying to follow R-004 (and ISO 1151) also, but I've found it's primarily focussed on flat-Earth, steady atmosphere models. So, we follow it where we can and try to extend it in a consistent manner. My biggest remaining concern is that we need to separate the coordinate system definition from the reference frame. To quote Peter Zipfel: "Coordinate systems have no origins" - they are three orthogonal directions "floating" in space. eg, a geocentric coordinate system might have one axis direction defined by a line from the Earth's centre through the North pole, but that doesn't mean the coordinate system has its origin at the Earth's centre - all the matters is the direction. Thus, we can (and commonly do) refer to the velocity vector of a missile WRT an aircraft, expressed in, say, the geodetic (alternatively FE) coordinate system. The origin and magnitude of the vector are expressed by velocityMissileBody (following vector subscript notation, so this is read Velocity of Missile WRT Body (aircraft)). The direction is expressed using a coordinate system, which may have nothing to do with the aircraft or missile. In this example, the coordinate system is fixed to the Earth frame, but it has no origin. The only origin that matters is that of the velocity vector, ie, a point on the missile frame. Your mention of BodyWRTI is another good example. In fact, this is exactly what we use in our high fidelity 6-DOF model equations of motion. Since Newton's laws are only valid in an inertial reference frame, the force equations are vdotBodyInertial = R/m + g. The coordinate system doesn't really matter. To simplify the equations, we solve most of them in the inertial coordinate system, eg, vdotBodyInertial_Inertial = ... However, for the rotational ones its convenient to express it in body coordinates: omegadotBodyInertial_Body = ... The states then go through a series of coordinate transformations and vector sums to get values wrt the Earth in various coordinates. Since we are only concerned with atmospheric flight, we choose the J2000 geocentric inertial frame as being close enough to a real inertial reference. For flat, non-rotating Earth equations of motion, we substitute the "Earth" frame for the "Inertial" frame, and substitute "Geographic" (FE) coordinates for "Inertial" coordinates. Some more examples of parameters we actually use are: velocityBodyInertial_Inertial, velocityBodyEarth_Geocentric, velocityBodyEarth_Geodetic, velocityBodyEarth_Body, velocityBodyEarth_Geographic, velocityBodyAirpath_Airpath, velocityBodyAirpath_Body, velocityBodyAirpath_Geodetic, velocityBodyAirpath_Geographic, velocityWindEarth_Geodetic, velocityTurbulenceAirpath_Body, angularVelocityEarthInertial_Inertial, angularVelocityBodyInertial_Body, angularVelocityBodyEarth_Body, angularVelocityAirpathEarth_Airpath It's hard explaining this via e-mail, so I hope it makes sense. With regards ms_1... Apart from dropping milli, I don't know, but I'll have a talk about it here and see if there are any more ideas. Cheers, Rob Rob Curtin QinetiQ Consulting Level 3, 210 Kings Way South Melbourne, VIC 3205 Tel: +61 3 9694 1000 Fax: +61 3 9694 1001 Email: [EMAIL PROTECTED] Web: www.QinetiQ.com.au -Original Message- From: Hildreth, Bruce [mailto:[EMAIL PROTECTED] Sent: Friday, 23 May 2008 4:35 AM To: Bruce Jackson; Curtin, Robert (Contractor) Cc: Aerospace Sim Standard discussion group Subject: RE: arrayDef & draft simstd comments Hi Bob Curtin: Am extremely sorry it has taken so long to respond, but I have thought long and hard on this (and have been busy on other things too). Thanks for your suggestions regarding axis system. I have some discussion on your thoughts and will tell you what I plan to change in the standard to help clarify things. You have brought up a few issues that must be clarified in the standard, both in naming and in axis systems. You have opened an area in the standard that must have some correction/clarification, but is hard to cover all aspects of the issue. You have also brought to light an error that must be correct in the axis naming convention. First, "ANSI/AIAA R-004-1992, Recommended Practice - Atmospheric and Space Flight Vehicle Coordinate Systems" is the normative standard for axis systems, and we are trying not to deviate from this standard. In some cases that document provides more insight as to your question of "velocity of what wrt what? [in your email below]" in R-004's figures. I think R-004 uses the underlying (and correct) foundation concept that all motion is inertially referenced unless specified otherwise. R-004 is just not abundandtly clear on this. So, the general answer to the question of "velocity of what wrt what?"
RE: arrayDef & draft simstd comments
Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Jackson Sent: Thursday, March 13, 2008 8:17 AM To: Curtin, Robert (Contractor) Cc: Aerospace Sim Standard discussion group Subject: Re: arrayDef & draft simstd comments Rob, I need to find some time to review your wonderfully rich suggestions in depth, but I had a rationale for adding a "dimensions" attribute: without it, a parser will have to count the number of elements to determine how many dimensions are required. Plus, it serves as a check to make sure the two counts match. Also, I am trying to avoid names like dim1, dim2, dim3, etc... This implies a parser would be limited in how many dimensions it is required to look for (up to dim199?). Good catch on the naming for the initialValue - it does need to be consistent with the current element definition. And it may be a good idea to reuse variableDef in place of a new arrayDef element. In this case, the presence of a "dimensions" attribute (with a value other than 1) would clue the parser that the variable is not scalar. I'm passing the comments about coordinate frames along to Bruce Hildreth for his consideration, and I expect we'll be getting back to you; I think you have some very valid points from the perspective of an implementer. Thanks again, and enjoy your Fall (as we are enjoying Spring), -- Bruce On Mar 12, 2008, at 6:40 PM, Curtin, Robert (Contractor) wrote: > Hi Bruce, > > You suggestion looks good. The "dimensions" attribute would be > unnecessary, as it's defined by the number of elements, in the > same way that a gridded table's dimensional size is specified by the > number of (and also ) elements. > > I'd keep singular to avoid confusion. I'd also carry > across the optional "axisSystem" attribute, for use with arrays that > define cartesian vectors/tensors. In fact, could we do all this using > the existing element, by adding the appropriate > subelements & rules? > > > This leads to some other comments on the draft standard I had for your > consideration - more to do with coding than DaveML: > > > I think the standard needs to be more rigorous wrt identifying > points/frames and coordinate systems in variable names/varIDs. > > An an example, our (ie, DSTO-AVD) simulations use the variable name > "velocityBodyEarth_Body" to indicate the velocity vector of the Body > (reference point on the body frame) wrt the Earth (ditto), expressed > in the Body coordinate system (coordinate systems after the > underscore). > Similary, "positionBodyEarth_Geocentric" is the position vector of the > Body reference point wrt the Earth reference point, expressed in the > Geocentic coordinate system. We also use the convention that in the > vector "velocityDerivBodyEarth_Body", the derivative is taken in the > Body coordinate system. This is different to > "accelerationBodyEarth_Body", where the velocity derivative would be > taken in an Earth-fixed coordinate system. Our direction cosine > matrices take the form "transform_BodyEarth" (DCM of Body axes from > Earth axes). > > We use a lot of vector math in our code, but if you don't, you then > have to add in the specific axis to the above vector names, eg, > "xPositionBodyEarth_Geocentric". > > The current draft Standard is not very clear in distinguishing the > coordinate system and reference frames/points. Actually, it often > omits the frames/points, eg, their "EGEVelocity_ms_1". Yes, it's the > East (or > Y) component in the GE coordinate system, but velocity of what wrt > what? > This becomes important when you have inertial, earth, air (with > turbulence), body and landing gear frames. > > A few examples in the list at Annex A.1 do define the reference frame, > eg, "GEVelocityYRelativeToEarth", though in this case its breaking its > own convention about where to put the "Y". As best as I can figure > out, the correct Standard variable name should be > "EGEVelocityRelativeToEarth_ms_1". This still doesn't declare that > it's the velocity of the body (ie, vehicle), but we could fix it thus: > "EGEVelocityBodyRelativeToEarth_ms_1". Personally, I think the > "RelativeTo" is a bit cumbersome, but it works. However, this > convention is not explicit in the guidance at 5.2.3: > > (prefix)_(variable source domain) )(Specific axis or reference) ( Axis > or reference system)(Core name)_(units) > > We had to fix it by adding conventions to (Core name). > > As for units (groan now)... We've not been including units in coded > variable names (since we force consi
RE: arrayDef & draft simstd comments
Geoff, et al., I have the following comments on this excellent proposal: 1) I still don't see the need for a "typeArray" attribute. The presence (or absence) of "dimensionDef" is sufficient for any parser to determine the size of any array that may be present. 2) As far as using "typeArray" to help if there is a MathML calculation (since MathML uses vector, matrix type attributes), I don't think this solves anything because what if the typeArray said "vector" but there were two in the ? Or what happens if it is a 3 (or more) dimensional array? Also, the MathML has the whole ... syntax that we don't want to get into here... 3) As far as "typeData", I would suggest adding an explicit "boolean" type in addition to the real and integer. While nominally covered by "typeData" with a "base" of 2, it is (or could be) such a common item that it would be useful to be more explicit. I'm not as sure whether to use something separate, or use the MathML and for the values. 4.0) I hope that this section from your example: 3.0 doesn't mean that there are non-integer dimensions! It's been too long since I studied fractals, but I don't recall anything that would be too useful in DAVEML-type simulations. :-) http://en.wikipedia.org/wiki/Fractal http://en.wikipedia.org/wiki/Fractal_dimension Dennis --- Dennis J. Linse, Aerospace Engineer Science Applications International Corporation +1-703-294-4449 <mailto:[EMAIL PROTECTED]> -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian, Geoff Sent: Thursday, March 27, 2008 2:01 AM To: Aerospace Sim Standard discussion group Subject: FW: arrayDef & draft simstd comments Hi all, The following is an experimental scheme I have come up with that makes minimal change to the dtd to add a capability for vector/matrices. The major change is to the definition of the variableDef element. I have added to following in the element definition: "dimensionDef?, (calculation | array)?" Also I have added to following in the attribute list: typeData (real | integer) #IMPLIED base CDATA #IMPLIED typeArray (scalar | vector | matrix) #IMPLIED" The "dimensionDef" is used when listing the dimensions of the vector/matrix. The "array" is used to represent the associated data table for the vector/matrix. The "typeData" and "base" have been included to address Giovanni's wish to have data types for each variable. This concept I have taken from that used by MathML for the definition of "cn" and "ci" elements. The "typeData" is a subset of that defined in MathML (having the possibilities of integer | rational | complex-cartesian | complex-polar | real | e-notation [Default : real]). The "base" has an integer value of between 2 and 36, with a default of 10. The "typeArray" attribute is used to define whether the variableDef represents a scalar value, or vector/matrix values. This is again similar to the convention used by MathML for the "ci" element. To support this, the following is also required. My syntax may not be totally correct. I have attached a sample file on how vector/matrices might look in XML using this scheme. Supporting whatever scheme is agreed on through Janus will be the next challenge. Geoff 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.
FW: arrayDef & draft simstd comments
Hi all, The following is an experimental scheme I have come up with that makes minimal change to the dtd to add a capability for vector/matrices. The major change is to the definition of the variableDef element. I have added to following in the element definition: "dimensionDef?, (calculation | array)?" Also I have added to following in the attribute list: typeData (real | integer) #IMPLIED base CDATA #IMPLIED typeArray (scalar | vector | matrix) #IMPLIED" The "dimensionDef" is used when listing the dimensions of the vector/matrix. The "array" is used to represent the associated data table for the vector/matrix. The "typeData" and "base" have been included to address Giovanni's wish to have data types for each variable. This concept I have taken from that used by MathML for the definition of "cn" and "ci" elements. The "typeData" is a subset of that defined in MathML (having the possibilities of integer | rational | complex-cartesian | complex-polar | real | e-notation [Default : real]). The "base" has an integer value of between 2 and 36, with a default of 10. The "typeArray" attribute is used to define whether the variableDef represents a scalar value, or vector/matrix values. This is again similar to the convention used by MathML for the "ci" element. To support this, the following is also required. My syntax may not be totally correct. I have attached a sample file on how vector/matrices might look in XML using this scheme. Supporting whatever scheme is agreed on through Janus will be the next challenge. Geoff 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. $Revision: 1.0$ This file is a test file for Vector and Matrix enhancements to DAVE-ML. $Revision: 1.0 $ UNCLASSIFIED Data Quality between 1 and 10 Assume nothing. This is a test input vector 3.0 This is a test input vector 3.0 3.0 4.0 3.0 1.0, dataQuality, 2.0, 1.0, dataQuality, 3.0, 1.0, dataQuality, 4.0, 1.0, dataQuality, 5.0, 4.0 matrix2D inputMatrix_ inputVector_ 2.0
RE: arrayDef & draft simstd comments
Bruce, I'm with Rob. Any (good) XML parser automatically counts the number of subelements of a particular type and returns that number when requested (e.g. getLength() in Xerces-C used by Janus) or allows you to iterate through the list without (e.g. "for i in vars:" in various XML modules in Python). The dimensions attribute would only add redundancy that isn't helpful if it is correct and causes errors if it is wrong (or maybe just confusion: if "dimensions" is 3 and there are only two elements, should the third dimension be assumed to be length 1?). I do agree that and not dim1, etc. is the way to go. An alternative that makes it look a little closer (in style) to how / is used in would be 2 6 3 ... Although I don't know if that really adds anything useful. Again, the parser will easily know the number of elements, so it will easily figure out whether it is a scalar or a vector/array. Note that the parser already has to count such things in the / system. Of course the real fun of the vector/array will be the mux/demux, subreferencing, and MathML connections. Examples: 1) Can an initialValue of an array be one or more previously defined variables? (scalars, vectors or arrays) 2) Can elements of an array be referenced by scalar variables? array: eulerAngle_d(3) scalars: rollEulerAngle_d, pitchEulerAngle_d, yawEulerAngle_d 3) Just for fun: 0-based (C) or 1-based (Fortran) indices? Dennis --- Dennis J. Linse, Aerospace Engineer Science Applications International Corporation +1-703-294-4449 <mailto:[EMAIL PROTECTED]> -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Jackson Sent: Thursday, March 13, 2008 8:17 AM To: Curtin, Robert (Contractor) Cc: Aerospace Sim Standard discussion group Subject: Re: arrayDef & draft simstd comments Rob, I need to find some time to review your wonderfully rich suggestions in depth, but I had a rationale for adding a "dimensions" attribute: without it, a parser will have to count the number of elements to determine how many dimensions are required. Plus, it serves as a check to make sure the two counts match. Also, I am trying to avoid names like dim1, dim2, dim3, etc... This implies a parser would be limited in how many dimensions it is required to look for (up to dim199?). Good catch on the naming for the initialValue - it does need to be consistent with the current element definition. And it may be a good idea to reuse variableDef in place of a new arrayDef element. In this case, the presence of a "dimensions" attribute (with a value other than 1) would clue the parser that the variable is not scalar. I'm passing the comments about coordinate frames along to Bruce Hildreth for his consideration, and I expect we'll be getting back to you; I think you have some very valid points from the perspective of an implementer. Thanks again, and enjoy your Fall (as we are enjoying Spring), -- Bruce On Mar 12, 2008, at 6:40 PM, Curtin, Robert (Contractor) wrote: > Hi Bruce, > > You suggestion looks good. The "dimensions" attribute would be > unnecessary, as it's defined by the number of elements, in the > same way that a gridded table's dimensional size is specified by the > number of (and also ) elements. > > I'd keep singular to avoid confusion. I'd also carry > across the optional "axisSystem" attribute, for use with arrays that > define cartesian vectors/tensors. In fact, could we do all this using > the existing element, by adding the appropriate > subelements & rules? > > [...] > > Cheers, Rob > > > Rob Curtin > QinetiQ Consulting > on contract to Air Vehicles Division, > Defence Science & Technology Organisation > Tel: +61 (0)3 9626 7730 > > > -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: > > dimensions="3"> > 2 > 6 > 3 > My Data Matrix is a 2x6x3 matrix; the last dimension > changes most rapidly > > 111 112 113 > 121 122 123 > 131 132 133 > 141 142 143 > 151 152 153 > 161 162 163 > > 211 212 213 221 222 223 231 232 233 241 242 243 251 252 > 253 261 262 263 > > >
Re: arrayDef & draft simstd comments
Rob, I need to find some time to review your wonderfully rich suggestions in depth, but I had a rationale for adding a "dimensions" attribute: without it, a parser will have to count the number of elements to determine how many dimensions are required. Plus, it serves as a check to make sure the two counts match. Also, I am trying to avoid names like dim1, dim2, dim3, etc... This implies a parser would be limited in how many dimensions it is required to look for (up to dim199?). Good catch on the naming for the initialValue - it does need to be consistent with the current element definition. And it may be a good idea to reuse variableDef in place of a new arrayDef element. In this case, the presence of a "dimensions" attribute (with a value other than 1) would clue the parser that the variable is not scalar. I'm passing the comments about coordinate frames along to Bruce Hildreth for his consideration, and I expect we'll be getting back to you; I think you have some very valid points from the perspective of an implementer. Thanks again, and enjoy your Fall (as we are enjoying Spring), -- Bruce On Mar 12, 2008, at 6:40 PM, Curtin, Robert (Contractor) wrote: Hi Bruce, You suggestion looks good. The "dimensions" attribute would be unnecessary, as it's defined by the number of elements, in the same way that a gridded table's dimensional size is specified by the number of (and also ) elements. I'd keep singular to avoid confusion. I'd also carry across the optional "axisSystem" attribute, for use with arrays that define cartesian vectors/tensors. In fact, could we do all this using the existing element, by adding the appropriate subelements & rules? This leads to some other comments on the draft standard I had for your consideration - more to do with coding than DaveML: I think the standard needs to be more rigorous wrt identifying points/frames and coordinate systems in variable names/varIDs. An an example, our (ie, DSTO-AVD) simulations use the variable name "velocityBodyEarth_Body" to indicate the velocity vector of the Body (reference point on the body frame) wrt the Earth (ditto), expressed in the Body coordinate system (coordinate systems after the underscore). Similary, "positionBodyEarth_Geocentric" is the position vector of the Body reference point wrt the Earth reference point, expressed in the Geocentic coordinate system. We also use the convention that in the vector "velocityDerivBodyEarth_Body", the derivative is taken in the Body coordinate system. This is different to "accelerationBodyEarth_Body", where the velocity derivative would be taken in an Earth-fixed coordinate system. Our direction cosine matrices take the form "transform_BodyEarth" (DCM of Body axes from Earth axes). We use a lot of vector math in our code, but if you don't, you then have to add in the specific axis to the above vector names, eg, "xPositionBodyEarth_Geocentric". The current draft Standard is not very clear in distinguishing the coordinate system and reference frames/points. Actually, it often omits the frames/points, eg, their "EGEVelocity_ms_1". Yes, it's the East (or Y) component in the GE coordinate system, but velocity of what wrt what? This becomes important when you have inertial, earth, air (with turbulence), body and landing gear frames. A few examples in the list at Annex A.1 do define the reference frame, eg, "GEVelocityYRelativeToEarth", though in this case its breaking its own convention about where to put the "Y". As best as I can figure out, the correct Standard variable name should be "EGEVelocityRelativeToEarth_ms_1". This still doesn't declare that it's the velocity of the body (ie, vehicle), but we could fix it thus: "EGEVelocityBodyRelativeToEarth_ms_1". Personally, I think the "RelativeTo" is a bit cumbersome, but it works. However, this convention is not explicit in the guidance at 5.2.3: (prefix)_(variable source domain) )(Specific axis or reference) ( Axis or reference system)(Core name)_(units) We had to fix it by adding conventions to (Core name). As for units (groan now)... We've not been including units in coded variable names (since we force consistency and can switch computational units). However, we do convert to and from computational units when interacting with DaveML files. One minor error I spotted in the draft Std is that "ms_1" has two interpretations: "meters per second" or "per millisecond". Trivial, but enough to miss Mars. Cheers, Rob Rob Curtin QinetiQ Consulting on contract to Air Vehicles Division, Defence Science & Technology Organisation Tel: +61 (0)3 9626 7730 -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 sh
arrayDef & draft simstd comments
Hi Bruce, You suggestion looks good. The "dimensions" attribute would be unnecessary, as it's defined by the number of elements, in the same way that a gridded table's dimensional size is specified by the number of (and also ) elements. I'd keep singular to avoid confusion. I'd also carry across the optional "axisSystem" attribute, for use with arrays that define cartesian vectors/tensors. In fact, could we do all this using the existing element, by adding the appropriate subelements & rules? This leads to some other comments on the draft standard I had for your consideration - more to do with coding than DaveML: I think the standard needs to be more rigorous wrt identifying points/frames and coordinate systems in variable names/varIDs. An an example, our (ie, DSTO-AVD) simulations use the variable name "velocityBodyEarth_Body" to indicate the velocity vector of the Body (reference point on the body frame) wrt the Earth (ditto), expressed in the Body coordinate system (coordinate systems after the underscore). Similary, "positionBodyEarth_Geocentric" is the position vector of the Body reference point wrt the Earth reference point, expressed in the Geocentic coordinate system. We also use the convention that in the vector "velocityDerivBodyEarth_Body", the derivative is taken in the Body coordinate system. This is different to "accelerationBodyEarth_Body", where the velocity derivative would be taken in an Earth-fixed coordinate system. Our direction cosine matrices take the form "transform_BodyEarth" (DCM of Body axes from Earth axes). We use a lot of vector math in our code, but if you don't, you then have to add in the specific axis to the above vector names, eg, "xPositionBodyEarth_Geocentric". The current draft Standard is not very clear in distinguishing the coordinate system and reference frames/points. Actually, it often omits the frames/points, eg, their "EGEVelocity_ms_1". Yes, it's the East (or Y) component in the GE coordinate system, but velocity of what wrt what? This becomes important when you have inertial, earth, air (with turbulence), body and landing gear frames. A few examples in the list at Annex A.1 do define the reference frame, eg, "GEVelocityYRelativeToEarth", though in this case its breaking its own convention about where to put the "Y". As best as I can figure out, the correct Standard variable name should be "EGEVelocityRelativeToEarth_ms_1". This still doesn't declare that it's the velocity of the body (ie, vehicle), but we could fix it thus: "EGEVelocityBodyRelativeToEarth_ms_1". Personally, I think the "RelativeTo" is a bit cumbersome, but it works. However, this convention is not explicit in the guidance at 5.2.3: (prefix)_(variable source domain) )(Specific axis or reference) ( Axis or reference system)(Core name)_(units) We had to fix it by adding conventions to (Core name). As for units (groan now)... We've not been including units in coded variable names (since we force consistency and can switch computational units). However, we do convert to and from computational units when interacting with DaveML files. One minor error I spotted in the draft Std is that "ms_1" has two interpretations: "meters per second" or "per millisecond". Trivial, but enough to miss Mars. Cheers, Rob Rob Curtin QinetiQ Consulting on contract to Air Vehicles Division, Defence Science & Technology Organisation Tel: +61 (0)3 9626 7730 -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: 2 6 3 My Data Matrix is a 2x6x3 matrix; the last dimension changes most rapidly 111 112 113 121 122 123 131 132 133 141 142 143 151 152 153 161 162 163 211 212 213 221 222 223 231 232 233 241 242 243 251 252 253 261 262 263 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
