That is mostly what I intended, Tom. The
original purpose of SMILE by itself was to define the
functionality of the language we wanted to encode, which
also includes equation syntax to make it consistent in all
encodings of the SD language. Bob's and Magne's discussion
seems to be leaking into whether the same equation syntax
should be used in all encodings, but the technical committee
is only concerned with the XML encoding.
To clarify again, Magne, the basic part of SMILE (up to
section 6) is based on DYNAMO and was intended to define the
intersection of vendor's products. I discussed the optional
parts in section 6 with a number of people in the community
before putting them into the spec, but they clearly need
additional review.
Re: SMILE and XMILE
by Karim
Chichakly » Tue Aug 13, 2013 5:31 pm
- Karim Chichakly
- Posts: 20
- Joined: Fri Apr 10, 2009 11:52 am
Re: SMILE and XMILE
by Magne
Myrtveit » Wed Aug 14, 2013 1:39 am
Thanks, Travis, for joining 
To your questions:
The answer is "yes". However, math does not specify all we need. Examples include hierarchy (objects inside objects), stock-and-flow formulations (unless we use the syntax of integrals), and arrays.
- Magne
To your questions:Isn't the human-readable form pretty much defined already by standard mathematics? Right-hand side equals left-hand side?
The answer is "yes". However, math does not specify all we need. Examples include hierarchy (objects inside objects), stock-and-flow formulations (unless we use the syntax of integrals), and arrays.
- Magne
- Magne Myrtveit
- Posts: 51
- Joined: Mon Jan 12, 2009 6:52 am
Re: SMILE and XMILE
by Magne
Myrtveit » Wed Aug 14, 2013 2:29 am
Hi Karim, and thanks again for your
enormous effort in this area. Thanks also for your
clarification:
Since XML is an encoding of an SD model, it must be clearly specified what an SD model is. (SMILE is another encoding of the same thing).
I am trying to lift focus to the conceptual level, so we can agree on what an SD model is, identify its objects, object properties, and relationships among object. Only then does it make any sense to define the textual and graphical representations. There is, of course, a hidden mental model of the concepts behind your work with SMILE/XMILE. This model should be made explicit.
Jumping back to the XML encoding: In my view, we should allow vendors to maintain their uniqueness when it comes to concepts, syntax, semantics and tokens. An easy way to do this, is to let every object (variable, say), be defined with a left-hand-side (the name of the variable), and a right-hand-side (the definition of the variable). What the right-hand-side looks like, must be vendor specific. See http://www.myrtveit.com/papers/A_framework_for_dataflow_models.pdf figure 59, page 38-29.
The current XML specification, does not follow the above principle, since the definition (right-hand-side) is split up into XML elements that fits for some vendors, but certainly not for all (current or future). It would be Ok that vendors use their own, non-standard elements, or optional extra elements (such as, mathml) in their files. But the definition property should in my opinion be a text attribute of the variable object. To be concrete, I recommend that the XML encoding for a variable Y=F(X) should look like this:
The exchange between Bob and myself concerns how to map Vensim's multi-equation syntax into a single right-hand-side.
Can you clarify the following, please?
I am uncertain if SMILE/XMILE is intended to be an intersection or a union of vendor products. When looking at the specification, it seems to contain stuff outside the common core of SD. (See chapter 6, page 43ff, of the dataflow document for my understanding of core system dynamics, and how it can be extended). Is it possible to define the core of XMILE, and show how it can be extended to accommodate concepts, features, syntax etc. offered by current vendors?
Best regards,
Magne
Karim Chichakly wrote:...the technical committee is only concerned with the XML encoding.
Since XML is an encoding of an SD model, it must be clearly specified what an SD model is. (SMILE is another encoding of the same thing).
I am trying to lift focus to the conceptual level, so we can agree on what an SD model is, identify its objects, object properties, and relationships among object. Only then does it make any sense to define the textual and graphical representations. There is, of course, a hidden mental model of the concepts behind your work with SMILE/XMILE. This model should be made explicit.
Jumping back to the XML encoding: In my view, we should allow vendors to maintain their uniqueness when it comes to concepts, syntax, semantics and tokens. An easy way to do this, is to let every object (variable, say), be defined with a left-hand-side (the name of the variable), and a right-hand-side (the definition of the variable). What the right-hand-side looks like, must be vendor specific. See http://www.myrtveit.com/papers/A_framework_for_dataflow_models.pdf figure 59, page 38-29.
The current XML specification, does not follow the above principle, since the definition (right-hand-side) is split up into XML elements that fits for some vendors, but certainly not for all (current or future). It would be Ok that vendors use their own, non-standard elements, or optional extra elements (such as, mathml) in their files. But the definition property should in my opinion be a text attribute of the variable object. To be concrete, I recommend that the XML encoding for a variable Y=F(X) should look like this:
- Code: Select all
<Variable Definition="F(X)">
<Names>
<Name>Y</Name>
<Names/>
</Variable>
The exchange between Bob and myself concerns how to map Vensim's multi-equation syntax into a single right-hand-side.
Can you clarify the following, please?
Karim Chichakly wrote:the basic part of SMILE (up to section 6) is based on DYNAMO and was intended to define the intersection of vendor's products.
I am uncertain if SMILE/XMILE is intended to be an intersection or a union of vendor products. When looking at the specification, it seems to contain stuff outside the common core of SD. (See chapter 6, page 43ff, of the dataflow document for my understanding of core system dynamics, and how it can be extended). Is it possible to define the core of XMILE, and show how it can be extended to accommodate concepts, features, syntax etc. offered by current vendors?
Best regards,
Magne
- Magne Myrtveit
- Posts: 51
- Joined: Mon Jan 12, 2009 6:52 am
Re: SMILE and XMILE
by Magne
Myrtveit » Wed Aug 14, 2013 2:54 am
Thanks for joining, in, Thomas. I agree
with your statement:
The details of _expression_ syntax varies significantly among vendors. We can like it or we can dislike it, but it is a fact. The syntactical differences fall into tow groups:
-Magne
PS: Note that not even IF-THEN-ELSE is semantically the same among vendors. Software with support for three- or four-state logic, have a branch for the case when the condition is undetermined, as illustrated by Dynaplan Smia's IF statement: IF a THEN b ELSE c EXCEPT d ENDIF
Thomas Fiddaman wrote:As long as XMILE defines an <eqn> field without caring what's in it, it seems that SMILE is needed in order to specify the operators, functions, naming etc. needed to interpret the RHS of the <eqn>.
The details of _expression_ syntax varies significantly among vendors. We can like it or we can dislike it, but it is a fact. The syntactical differences fall into tow groups:
- Syntax representing alternative ways to express the same concept. Example: IF(A,B,C) versus IF A THEN B ELSE C ENDIF
- Syntax expressing different concepts or different semantics. Examples: Arrays, components, co-models, macros, units, types, dimensions.
-Magne
PS: Note that not even IF-THEN-ELSE is semantically the same among vendors. Software with support for three- or four-state logic, have a branch for the case when the condition is undetermined, as illustrated by Dynaplan Smia's IF statement: IF a THEN b ELSE c EXCEPT d ENDIF
- Magne Myrtveit
- Posts: 51
- Joined: Mon Jan 12, 2009 6:52 am
Re: SMILE and XMILE
by Magne
Myrtveit » Wed Aug 14, 2013 3:19 am
Hi Bob,
When mapping Vensim's multiple equations into one equation, would you like to maintain as much as possible of the existing language definition used by Vensim, or do you consider to redefine Vensim's language to match SMILE or something else?
Assuming that you want to maintain Vensim's current language definition at the conceptual, syntactical, semantic, and lexical level as much as possible, how can the following be mapped into one equation?
My suggestion is something like this:
The changes I made to your existing syntax, are:
I don't remember of bar and double arrow are already occupied by your grammar. If they are, just find some other character combinations that are free.
If you are in the process of change your modelling language (grammar), you have more degrees of freedom. Here are some examples I could think of:
If you introduce a minus operator on your subscripts, with the semantics to shift subscripts a given number of position to the left, there is no need for mapping, and the equation becomes:
If you allow for index variables and intervals (a to b), the equation can be like this:
As a comparison, here is the Smia syntax I would use:
Best regards,
Magne
When mapping Vensim's multiple equations into one equation, would you like to maintain as much as possible of the existing language definition used by Vensim, or do you consider to redefine Vensim's language to match SMILE or something else?
Assuming that you want to maintain Vensim's current language definition at the conceptual, syntactical, semantic, and lexical level as much as possible, how can the following be mapped into one equation?
Robert Eberlein wrote:WIP[Stage1]= INTEG (ProductionStarts-WIP[Stage1]/ProdTime[Stage1], 0) ~~|
WIP[StageMid]= INTEG (WIP[StagePrior]/ProdTime[StagePrior]-WIP[StageMid]/ProdTime[StageMid],0) ~~|
WIP[Stage22]= INTEG (WIP[Stage21]/ProdTime[Stage21]-shipments,0) ~ Widget ~|
My suggestion is something like this:
- Code: Select all
WIP = Stage1 => INTEG (ProductionStarts-WIP[Stage1]/ProdTime[Stage1], 0)
| StageMid => INTEG(WIP[StagePrior]/ProdTime[StagePrior]-WIP[StageMid]/ProdTime[StageMid],0)
| Stage22 => INTEG (WIP[Stage21]/ProdTime[Stage21]-shipments,0)
~Widget~|
The changes I made to your existing syntax, are:
- Only the name, without subscripts, is given to the left of the equal operator (=)
- Subscripts and the corresponding _expression_ are separated by a double arrow (=>), like this: "subscript => _expression_"
- A bar (|) is used to separate "keys=>_expression_" pairs on the right-hand-side of an equation
I don't remember of bar and double arrow are already occupied by your grammar. If they are, just find some other character combinations that are free.
If you are in the process of change your modelling language (grammar), you have more degrees of freedom. Here are some examples I could think of:
- Code: Select all
WIP = stock {s==stages | 0} as Widget
inflow
{ Stage1 => ProductionStarts
| StageMid => WIP(StagePrior)/ProdTime(StagePrior)
| Stage22 => WIP(Stage21)/ProdTime(Stage21)
}
outflow
{ Stage1 => WIP(Stage1)/ProdTime(Stage1)
| StageMid => WIP(StageMid)/ProdTime(StageMid)
| Stage22 => Shipments
}
If you introduce a minus operator on your subscripts, with the semantics to shift subscripts a given number of position to the left, there is no need for mapping, and the equation becomes:
- Code: Select all
WIP = stock {s==stages | 0} as Widget
inflow
{ Stage1 => ProductionStarts
| StageMid => WIP(StageMid-1)/ProdTime(StageMid-1)
| Stage22 => WIP(Stage21)/ProdTime(Stage21)
}
outflow
{ Stage1 => WIP(Stage1)/ProdTime(Stage1)
| StageMid => WIP(StageMid)/ProdTime(StageMid)
| Stage22 => Shipments
}
If you allow for index variables and intervals (a to b), the equation can be like this:
- Code: Select all
WIP = stock {s==stages | 0} as Widget
inflow
{ Stage1 => ProductionStarts
| Stage2 to Stage22 => WIP(s-1)/ProdTime(s-1)
}
outflow
{ Stage1 to Stage21 => WIP(s)/ProdTime(s)
| Stage22 => Shipments
}
As a comparison, here is the Smia syntax I would use:
- Code: Select all
WIP = stock {s==stages | 0} as Widget
inflow {s:=* | ProductionStarts, WIP(s-1)/ProdTime(s-1) }
outflow {s=:* | WIP(s)/ProdTime(S), Shipments }
Best regards,
Magne
- Magne Myrtveit
- Posts: 51
- Joined: Mon Jan 12, 2009 6:52 am
Re: SMILE and XMILE
by Robert
Eberlein » Wed Aug 14, 2013 5:24 am
Hi Magne,
Thanks for all the replies. The Smia is very compact, but I have to admit it is also baffling.
But, you have given a pretty good answer to the original question, because even in this case you have defined the attributes of the variable separately from its equation. So I think you have made a pretty good case for bringing in descriptive elements to the underlying computational language definition in addition to the raw equations.
As a side question, is it possible to have different units for different subscript elements in Smia? This is a possibility that is older than all our current languages (Jay was mixing units in subscripted equations in Dynamo), and perhaps not much of an issue for XMILE since optional element by element attributes would be easy to add.
Thanks for all the replies. The Smia is very compact, but I have to admit it is also baffling.
But, you have given a pretty good answer to the original question, because even in this case you have defined the attributes of the variable separately from its equation. So I think you have made a pretty good case for bringing in descriptive elements to the underlying computational language definition in addition to the raw equations.
As a side question, is it possible to have different units for different subscript elements in Smia? This is a possibility that is older than all our current languages (Jay was mixing units in subscripted equations in Dynamo), and perhaps not much of an issue for XMILE since optional element by element attributes would be easy to add.
- Robert Eberlein
- Site Admin
- Posts: 157
- Joined: Sat Dec 27, 2008 8:09 pm
Re: SMILE and XMILE
by Karim
Chichakly » Thu Aug 15, 2013 1:20 pm
Hi Magne,
The case you are talking about is represented in SMILE within the inflow and outflow equations as follows:
inflow: IF Stage = Stage1 THEN ProductionStarts ELSE WIP[Stage - 1]/ProdTime[Stage - 1]
outflow: IF Stage = Stage22 THEN Shipments ELSE WIP[Stage]/ProdTime[Stage]
I normally would not use Stage1 and Stage22 explicitly, as Stage1 has the alias "1" and Stage22 has the alias "SIZE(SELF)" which allows me to change the size of the array without then having to change my equations.
The SMILE form is also compact, but I think clearly points out the different approaches. Your formulation is declarative whereas the SMILE formulation is procedural. That is a fundamental difference and maybe herein lies the root of some of the philosophical differences coming out in this discussion.
With regards to the SMILE spec up to section 6, which I based on DYNAMO, if you compare the features there to the features you listed earlier in this thread as the basic set needed for all the models in Business Dynamics, you will see those two feature sets match almost exactly. While I did not call out that feature list at a high level (the hidden mental model you refer to), that was the intention from the beginning.
I firmly believe we need a common equation syntax for this standard to succeed. We are defining a standard for a computer-based language and a well-defined syntax and semantics is a fundamental requirement for any such language to succeed. Bob expressed it more elegantly in the XMILE webinar, where he pointed out that we used to have a common language, DYNAMO, but the vendors have all gone in different directions since then; XMILE is an effort to bring us back to a common core language. If we have different equation syntaxes, we do not have a common language.
Best regards,
Karim
The case you are talking about is represented in SMILE within the inflow and outflow equations as follows:
inflow: IF Stage = Stage1 THEN ProductionStarts ELSE WIP[Stage - 1]/ProdTime[Stage - 1]
outflow: IF Stage = Stage22 THEN Shipments ELSE WIP[Stage]/ProdTime[Stage]
I normally would not use Stage1 and Stage22 explicitly, as Stage1 has the alias "1" and Stage22 has the alias "SIZE(SELF)" which allows me to change the size of the array without then having to change my equations.
The SMILE form is also compact, but I think clearly points out the different approaches. Your formulation is declarative whereas the SMILE formulation is procedural. That is a fundamental difference and maybe herein lies the root of some of the philosophical differences coming out in this discussion.
With regards to the SMILE spec up to section 6, which I based on DYNAMO, if you compare the features there to the features you listed earlier in this thread as the basic set needed for all the models in Business Dynamics, you will see those two feature sets match almost exactly. While I did not call out that feature list at a high level (the hidden mental model you refer to), that was the intention from the beginning.
I firmly believe we need a common equation syntax for this standard to succeed. We are defining a standard for a computer-based language and a well-defined syntax and semantics is a fundamental requirement for any such language to succeed. Bob expressed it more elegantly in the XMILE webinar, where he pointed out that we used to have a common language, DYNAMO, but the vendors have all gone in different directions since then; XMILE is an effort to bring us back to a common core language. If we have different equation syntaxes, we do not have a common language.
Best regards,
Karim
- Karim Chichakly
- Posts: 20
- Joined: Fri Apr 10, 2009 11:52 am
Re: SMILE and XMILE
by Magne
Myrtveit » Fri Aug 16, 2013 1:28 am
Hi Bob,
Array syntax
I admit that the Smia syntax is "buffling" until it has been explained the first time. It is compact (expressive) and easy to use, once learned. The idea behind it is that the situation where there is one equation for the first or last element, and another for the rest, is very common in models. The list of index definition operators includes:
Units
The answer to your questions about different units for different array elements, is that Smia supports a mixed data type (sometimes called variant in other systems). If a variable is defined with mixed type, every element can have its own type and unit. (This is how Smia is able to represent spreadsheets containing text, numbers, logicals, and what not). See http://www.myrtveit.com/papers/A_framework_for_dataflow_models.pdf, figure 9, page 6 for an example how elements with different units are defined. The important thing, is that the right-hand-side as well as individual array elements (even literals) have an explicit or implicit type and unit in Smia. This approach has several advantages (and no drawbacks) over associating units with the variables.
XML for arrays
You write that "optional element by element attributes would be easy to add.". Agree, it is easy to add, but is it the right approach? I think that array elements should not be represented as separate XML elements, but rather as part of the right-hand-side Definition attribute of the <Variable> element. This way we can maintain the name=definition pattern for equations, and we can also prepare the language for "big data". My experience is that it is not uncommon with arrays holding several million elements. If each array element is stored as a separate XML element, the XML representation would become many times larger (and slower) than a corresponding compact attribute form.
Best regards,
Magne
Array syntax
I admit that the Smia syntax is "buffling" until it has been explained the first time. It is compact (expressive) and easy to use, once learned. The idea behind it is that the situation where there is one equation for the first or last element, and another for the rest, is very common in models. The list of index definition operators includes:
- = -- Every element has its own _expression_
- == -- All elements use the same _expression_
- := -- Separate _expression_ for the first element
- =: -- Separate _expression_ for the last element
- <= -- Elements defined as associative (key/value) array, i.e., subscripts => _expression_
Units
The answer to your questions about different units for different array elements, is that Smia supports a mixed data type (sometimes called variant in other systems). If a variable is defined with mixed type, every element can have its own type and unit. (This is how Smia is able to represent spreadsheets containing text, numbers, logicals, and what not). See http://www.myrtveit.com/papers/A_framework_for_dataflow_models.pdf, figure 9, page 6 for an example how elements with different units are defined. The important thing, is that the right-hand-side as well as individual array elements (even literals) have an explicit or implicit type and unit in Smia. This approach has several advantages (and no drawbacks) over associating units with the variables.
XML for arrays
You write that "optional element by element attributes would be easy to add.". Agree, it is easy to add, but is it the right approach? I think that array elements should not be represented as separate XML elements, but rather as part of the right-hand-side Definition attribute of the <Variable> element. This way we can maintain the name=definition pattern for equations, and we can also prepare the language for "big data". My experience is that it is not uncommon with arrays holding several million elements. If each array element is stored as a separate XML element, the XML representation would become many times larger (and slower) than a corresponding compact attribute form.
Best regards,
Magne
- Magne Myrtveit
- Posts: 51
- Joined: Mon Jan 12, 2009 6:52 am
Re: SMILE and XMILE
by Magne
Myrtveit » Fri Aug 16, 2013 2:16 am
Hi Karim,
WIP example
Your alternative definition of the WIP variable (quoted below) is definitely one way to do it.
The solution, however, means that the model is transformed, not just translated, into another syntax. By this I mean that different concepts are used to reproduce the same behaviour in two systems.
Your solution is an example of the only generic approach for transferring models from one system to the other, and it is the one I use when transforming Vensim models when opening them inside Smia.
Common syntax?
I can understand your desire to come up with a common syntax for the standard. Is it realistic? To answer the questions myself: Before we can define a common syntax, we need to define common semantics and common concepts. This can be accomplished if we limit ourselves to the "Core SD", as defined almost identically by our two independent works on XMILE and dataflomwl, respectively.
The minute we leave the core, we run into partly overlapping and partly conflicting solutions for language features, as demonstrated by the WIP example. Here it is no longer a matter of agreeing on one syntax of the other, but on selecting among competing approaches. Who is to tell which approach to use? What about the other approaches, that are left out of the standard?
Operations on subscripts
Your WIP equation makes use of expressions involving subscripts, such as Stage-1 and SIZE(SELF). It seems to me that 1 is a synonym for Stage1, which is quite similar to the way C++ treats enumeration types, where each named element is essentially a named integer literal.
This solution is in big contract to the approaches used by Powersim and Dynaplan, where a list defines a new domain which has nothing in common with the domain of integers. The semantics of a list type is very different from the semantics of integers. Below is an example that illustrates:
The array concept of SMILE would produce different results for the variables z, w, and c. I am unsure if SMILE supports the equation for g. (I am also unsure about the semantics of your SELF function).
Note for programmers: The semantics of Smia's list elements has much in common with the semantics of pointers in programming languages. You cannot add pointers, but you can subtract them. You can add an integer to a pointer, producing a pointer, but you cannot multiply pointers, etc.
My main point of showing this, is not to point out the advantages with the Studio/Smia solution, but to highlight the huge conceptual differences between apparently similar solutions in SMILE and other systems. These differences cannot be resolved through syntax agreements, unfortunately.
The number of such differences is quite large, and growing, among the SD technologies. Do you have a suggestion for how to handle them?
Best regards,
Magne
WIP example
Your alternative definition of the WIP variable (quoted below) is definitely one way to do it.
Karim Chichakly wrote:inflow: IF Stage = Stage1 THEN ProductionStarts ELSE WIP[Stage - 1]/ProdTime[Stage - 1]
outflow: IF Stage = Stage22 THEN Shipments ELSE WIP[Stage]/ProdTime[Stage]
The solution, however, means that the model is transformed, not just translated, into another syntax. By this I mean that different concepts are used to reproduce the same behaviour in two systems.
Your solution is an example of the only generic approach for transferring models from one system to the other, and it is the one I use when transforming Vensim models when opening them inside Smia.
Common syntax?
I can understand your desire to come up with a common syntax for the standard. Is it realistic? To answer the questions myself: Before we can define a common syntax, we need to define common semantics and common concepts. This can be accomplished if we limit ourselves to the "Core SD", as defined almost identically by our two independent works on XMILE and dataflomwl, respectively.
The minute we leave the core, we run into partly overlapping and partly conflicting solutions for language features, as demonstrated by the WIP example. Here it is no longer a matter of agreeing on one syntax of the other, but on selecting among competing approaches. Who is to tell which approach to use? What about the other approaches, that are left out of the standard?
Operations on subscripts
Your WIP equation makes use of expressions involving subscripts, such as Stage-1 and SIZE(SELF). It seems to me that 1 is a synonym for Stage1, which is quite similar to the way C++ treats enumeration types, where each named element is essentially a named integer literal.
This solution is in big contract to the approaches used by Powersim and Dynaplan, where a list defines a new domain which has nothing in common with the domain of integers. The semantics of a list type is very different from the semantics of integers. Below is an example that illustrates:
- Code: Select all
list = [apple, orange, banana]
x = apple
y = apple+1 (* Result: orange *)
z = apple+orange (* Error: Cannot add list elements *)
v = banana-apple (* Result: 2 *)
w = if apple = 2 then true else false (* Type/unit error: Cannot compare list element apple to integer 2 *)
a = {list | 2, 4, 3} (* Creates array with list as dimension and elements 2, 4 and 3 *)
b = a(apple) (* Result: 2 *)
c = a(1) (* Subscript error: Integer 1 cannot be used to index list dimension *)
d = first(list) (* Result: apple *)
e = last(list) (* Result: banana *)
f = count(list) (* Result: 3 *)
g = list(3) (* Result: banana *)
The array concept of SMILE would produce different results for the variables z, w, and c. I am unsure if SMILE supports the equation for g. (I am also unsure about the semantics of your SELF function).
Note for programmers: The semantics of Smia's list elements has much in common with the semantics of pointers in programming languages. You cannot add pointers, but you can subtract them. You can add an integer to a pointer, producing a pointer, but you cannot multiply pointers, etc.
My main point of showing this, is not to point out the advantages with the Studio/Smia solution, but to highlight the huge conceptual differences between apparently similar solutions in SMILE and other systems. These differences cannot be resolved through syntax agreements, unfortunately.
The number of such differences is quite large, and growing, among the SD technologies. Do you have a suggestion for how to handle them?
Best regards,
Magne
- Magne Myrtveit
- Posts: 51
- Joined: Mon Jan 12, 2009 6:52 am
Re: SMILE and XMILE
by Robert
Eberlein » Sun Aug 18, 2013 6:13 am
Hi Magne,
Thanks for the notes on this. I want to comment on this idea of a common syntax. There is no goal to define a global syntax, but rather to define semantics and a syntax rich enough to capture the majority of things people do with the functionality in different packages. We would like to keep this close to what is in use, but since things are different it can't be identical to all of them. Thus mapping these equations back to the syntax in a particular package may require some effort. The same is true with things like function names and format, but the mapping is likely to be more complex.
A note on storing equations in general - storing both the XMILE form of the equation and the native form in the same spot would be one way to make a XMILE encoded model open in its original form in the software from which it was saved.
Thanks for the notes on this. I want to comment on this idea of a common syntax. There is no goal to define a global syntax, but rather to define semantics and a syntax rich enough to capture the majority of things people do with the functionality in different packages. We would like to keep this close to what is in use, but since things are different it can't be identical to all of them. Thus mapping these equations back to the syntax in a particular package may require some effort. The same is true with things like function names and format, but the mapping is likely to be more complex.
A note on storing equations in general - storing both the XMILE form of the equation and the native form in the same spot would be one way to make a XMILE encoded model open in its original form in the software from which it was saved.