A) To Bob's suggestion about stop using
SMILE:
A language - such as a modelling language - is an abstract
phenomenon, which requires a representation to become
useful. The human-centric equations syntax, and the
corresponding graphical syntax, are two representation of a
system dynamics language, while a computer-centric XML-based
document format is another representation.
This supports Bob's suggestion to work with just one name
for the language.
My opinion is - for what it is worth - that the core system
dynamics language (the standard) should be called something
like SDL or SDCML (System Dynamics Community Model
Language), while extensions to that language should be named
by the respective vendors.
Since XMILE de facto is a isee language, given its elaborate
definition of non-standard extensions to core SD, it should
either be reserved for isee, or otherwise XMILE must be
scaled down to the bone, and isee asked to pick a new name
for their extended version, for example The isee modelling
language, or the iThink language.
In general, it makes no sense that a vendor's language and
the standard language for a community are one and the same.
One way to see why, is to notice that the first extension or
change this vendor makes to the language, will introduce a
conflict between the standard language and the vendor's
language.
(The naming and scope of XMILE belongs to a larger
discussion of potentially good and bad consequences of
different ways to set the standard).
B) To Bob's suggestions for layout of our discussion: I
agree that we need to structure our exchange. But in my
view, schemas (DTD
and XSD) belong to the syntax level of the document
representation of a language, i.e., quite far down in the
language levels, as I described in http://www.systemdynamics.org/forum/viewtopic.php?f=21&t=350.
A DTD can, if people learn how to read it, serve as a
high-level definition of objects, object properties, and
object relationships at the conceptual level of a model. However,
it is better to use simple class diagrams or drawings at
this level. (XSD is quite unreadable, and useful only at the
final stages of specification, as a help for developers to
create and test their implementation of the standard).
Therefore, I think we can postpone schema definitions to
quite late in the process.
Best regards from sunny Norway,
Magne
Re: SMILE and XMILE
by Magne
Myrtveit » Thu Aug 08, 2013 4:18 pm
- Magne Myrtveit
- Posts: 51
- Joined: Mon Jan 12, 2009 6:52 am
Re: SMILE and XMILE
by Magne
Myrtveit » Fri Aug 09, 2013 3:42 am
Regarding naming of the SD standard core
language, it is a pity that "J" is already occupied for
another computer language. It would have been great to
honour the founder of the field by naming the language after
him. However, "JF" too, is a nice name for a language -- not
to mention JFK 
- Magne Myrtveit
- Posts: 51
- Joined: Mon Jan 12, 2009 6:52 am
Re: SMILE and XMILE
by Robert
Eberlein » Fri Aug 09, 2013 8:44 am
Magne,
Thanks for the comments on this and your excellent writeup on data flow modeling frameworks.
I believe that you have ultimately argued in favor of distinction between the name by which the computational language is called and that for its encoding (not to mention the encoding for visual representations and control features). It would indeed have been cool to use a moniker like J for a common computational language, but perhaps something more mundane such a SDCL for System Dynamics Computational Language would work. I guess my biggest objection to SMILE is that is always getting mixed up with XMILE.
Leaving naming aside for a moment, there is a more fundamental question of what is the clearest way of representing the underlying computational language. Dynamo and Vensim use the very traditional ordinary text representation with = for assignment as in:
A=B
In Dynamo that representation was exactly what there was, and users changed it by editing the text. In the modern SD languages, however, people rarely deal with such text. The XMILE encoding which would be
<aux name="A">
<eqn>B</eqn>
</aux>
This is probably closer to what most users see (replacing the markup with a dialog of some sort). So the question I am struggling with is whether it is best to specify the entire language in a more traditional format, then specify the encoding which is necessarily a partially parsed version of that language, or specify the language in such a way that the encoding adds only tag formality and does not require any parsing relative to the specification.
Originally I was leaning toward the former, which is not surprising given that this is exactly how Vensim works. Now, however, I am leaning somewhat more toward the latter, as it simplifies a number of issues. Two exemplars are subscripts and non-negative levels.
Using the traditional assignment representation when a variable appears with subscripts it is necessary to try to determine what those subscripts mean. Encountering "Population[1]" in an equation simply tells us that the variable "Population" has a single subscript, nothing about what the subscript is. If, however, the variable Population shows up with something like:
Level: Population
Subscripts: AgeGroup
Units: Person
and so on then "Population[1]" is perfectly well defined.
Similarly, for a non negative level we ,might have something like
Level: WorkInProcess
Outflows: Rejects, Completions
Nonnegative: Completions, Rejects
and so on. (Two important comments. 1. I completely reject the use of nonnegative level constructs because the explicitly mask the feedback that must be in place to make them come true. 2. I do not think we should restrict Level formulations to only have explicitly named input and outputs as this is too constraining especially for people (like me) who never use SMOOTH/SMTH1).
I think the current computational description (the SMILE draft) should reflect these structures more clearly. I recognize that there is a bit of a chicken and egg problem here (that the XML definition depends on the spec which is created with the XML definition in mind). And that there are some programmatic overtones (what data structures are necessary to implement will partly drive the definitions). Still, I think we can achieve clarity and have the computational specification as readable by a typical modeler as it would be with the more traditional assignment notation.
I would very much like to hear the thoughts of others on this.
Thanks for the comments on this and your excellent writeup on data flow modeling frameworks.
I believe that you have ultimately argued in favor of distinction between the name by which the computational language is called and that for its encoding (not to mention the encoding for visual representations and control features). It would indeed have been cool to use a moniker like J for a common computational language, but perhaps something more mundane such a SDCL for System Dynamics Computational Language would work. I guess my biggest objection to SMILE is that is always getting mixed up with XMILE.
Leaving naming aside for a moment, there is a more fundamental question of what is the clearest way of representing the underlying computational language. Dynamo and Vensim use the very traditional ordinary text representation with = for assignment as in:
A=B
In Dynamo that representation was exactly what there was, and users changed it by editing the text. In the modern SD languages, however, people rarely deal with such text. The XMILE encoding which would be
<aux name="A">
<eqn>B</eqn>
</aux>
This is probably closer to what most users see (replacing the markup with a dialog of some sort). So the question I am struggling with is whether it is best to specify the entire language in a more traditional format, then specify the encoding which is necessarily a partially parsed version of that language, or specify the language in such a way that the encoding adds only tag formality and does not require any parsing relative to the specification.
Originally I was leaning toward the former, which is not surprising given that this is exactly how Vensim works. Now, however, I am leaning somewhat more toward the latter, as it simplifies a number of issues. Two exemplars are subscripts and non-negative levels.
Using the traditional assignment representation when a variable appears with subscripts it is necessary to try to determine what those subscripts mean. Encountering "Population[1]" in an equation simply tells us that the variable "Population" has a single subscript, nothing about what the subscript is. If, however, the variable Population shows up with something like:
Level: Population
Subscripts: AgeGroup
Units: Person
and so on then "Population[1]" is perfectly well defined.
Similarly, for a non negative level we ,might have something like
Level: WorkInProcess
Outflows: Rejects, Completions
Nonnegative: Completions, Rejects
and so on. (Two important comments. 1. I completely reject the use of nonnegative level constructs because the explicitly mask the feedback that must be in place to make them come true. 2. I do not think we should restrict Level formulations to only have explicitly named input and outputs as this is too constraining especially for people (like me) who never use SMOOTH/SMTH1).
I think the current computational description (the SMILE draft) should reflect these structures more clearly. I recognize that there is a bit of a chicken and egg problem here (that the XML definition depends on the spec which is created with the XML definition in mind). And that there are some programmatic overtones (what data structures are necessary to implement will partly drive the definitions). Still, I think we can achieve clarity and have the computational specification as readable by a typical modeler as it would be with the more traditional assignment notation.
I would very much like to hear the thoughts of others on this.
- Robert Eberlein
- Site Admin
- Posts: 157
- Joined: Sat Dec 27, 2008 8:09 pm
Re: SMILE and XMILE
by Magne
Myrtveit » Sat Aug 10, 2013 4:47 pm
Hi Bob,
It would be great to have more people involved in this thread. Hopefully we will get company soon. Below are some comments to your recent post. (Page numbers refer to "A framework for dataflow models").
Naming
Agree. If used for the SD Core Language (SDCL) the X in XMILE is also misleading, since XML is a computer-centric representation of structured contents.
Equation format
A language should be defined in terms of its abstract concepts, and represented in different ways, depending on the purpose or situation. Here are some examples:
Example 1: When listing model equations as part of a document (an article, a book, or similar), the conventional mathematical equation is the preferred form:
Example 2: Modern software typically provide access to individual object properties via widgets that are part of the GUI. When this is the case, name will be edited in one widget, and definition in another. (There is no need for the software to parse the equation to separate the name part from the definition part).
Example 3: Internally, the software represents a variable as an object, with multiple properties. When saving the object to file, a structured representation has many advantages over plain text. XML is one possible framework to use. In my definition of the dataflowml framework, I have specified that the definition property is plan text. The reason for that, is that different vendors use significantly different syntax for the right-hand-side of equations. Vendors can provide extra XML elements for the right-hand side in addition to the text. One possibility is to store the definition as mathml, and as a collection of other XML elements, the way XMILE does it. Following dataflowml, the XML representation for an equation is like this (page 38):
The XML format (like the example above) can obviously not be used for publishing equations for humans to read. We do need an equations syntax, that is clear.
Example 4: A DTD can be used to represent the structure of the XML representation of a model (see page 39). It is an "almost human-readable" format, that can be used by programmers to define language structure. (I used it when writing the XML specification of Smia models. Smia documents still contain a complete DTD and XSD defining the document format. The DTD and XSD is auto-generated by Smia's code, so they are always up-to-date when a new Smia release is made).
Structure of expressions
For the text-based representation of equations, it would be nice of we could come up with a framework (a set of keywords) that can be recommended to use. As an example, here is an example of what I suggest for stock definitions:
Subscripts
The equation where population is defined, will contain the necessary information about the dimensions of Population. When the variable is used on the right-hand-side of some equation, subscripts will be checked against the definition of the subscribed variable. This will be the case no matter how the variables are represented, assuming that the equations-based representation contains as much information as any structured representation that might be used instead. To be specific, let us look at your example:
A single equation can capture exactly the same information, like this:
Here I make use of my suggestion to use braces {...} for arrays and "as ..." for giving the type and/or unit of a variable. Note that "as Person" is needed only if the _expression_ defining the variable does not implicitly determine the data type and unit of the variable.
A problem with representing the definition of a variable, say, as a structured text, is that this would require a very elaborate structure definition, if we are going to support many vendor's dialects (and extensions) of the grammar (syntax as well as semantics) of equations.
Non-negative stocks
Agree 100%
Flow expressions
Agree 100%. In Smia, any mathematical _expression_ can be used in the position of a flow. As mentioned on p 49 in my dataflow PDF, it is conceptually wrong to define a separate variable type for flows. It is up to each vendor, of course, to break concepts, but it should not be permitted in a standard for SD.
Best regards,
Magne
It would be great to have more people involved in this thread. Hopefully we will get company soon. Below are some comments to your recent post. (Page numbers refer to "A framework for dataflow models").
Naming
I guess my biggest objection to SMILE is that is always getting mixed up with XMILE.
Agree. If used for the SD Core Language (SDCL) the X in XMILE is also misleading, since XML is a computer-centric representation of structured contents.
Equation format
So the question I am struggling with is whether it is best to specify the entire language in a more traditional format, then specify the encoding which is necessarily a partially parsed version of that language, or specify the language in such a way that the encoding adds only tag formality and does not require any parsing relative to the specification.
A language should be defined in terms of its abstract concepts, and represented in different ways, depending on the purpose or situation. Here are some examples:
Example 1: When listing model equations as part of a document (an article, a book, or similar), the conventional mathematical equation is the preferred form:
- Code: Select all
name=definition
Example 2: Modern software typically provide access to individual object properties via widgets that are part of the GUI. When this is the case, name will be edited in one widget, and definition in another. (There is no need for the software to parse the equation to separate the name part from the definition part).
- Code: Select all
Name: <Enter name here>
Definition: <Enter definition here>
Example 3: Internally, the software represents a variable as an object, with multiple properties. When saving the object to file, a structured representation has many advantages over plain text. XML is one possible framework to use. In my definition of the dataflowml framework, I have specified that the definition property is plan text. The reason for that, is that different vendors use significantly different syntax for the right-hand-side of equations. Vendors can provide extra XML elements for the right-hand side in addition to the text. One possibility is to store the definition as mathml, and as a collection of other XML elements, the way XMILE does it. Following dataflowml, the XML representation for an equation is like this (page 38):
- Code: Select all
<m:Variable Id="..." Definition="...">
<m:Names>
<m:Name>...</m:Name>
</m:Names>
<m:Description/>
<variable/>
The XML format (like the example above) can obviously not be used for publishing equations for humans to read. We do need an equations syntax, that is clear.
Example 4: A DTD can be used to represent the structure of the XML representation of a model (see page 39). It is an "almost human-readable" format, that can be used by programmers to define language structure. (I used it when writing the XML specification of Smia models. Smia documents still contain a complete DTD and XSD defining the document format. The DTD and XSD is auto-generated by Smia's code, so they are always up-to-date when a new Smia release is made).
Structure of expressions
For the text-based representation of equations, it would be nice of we could come up with a framework (a set of keywords) that can be recommended to use. As an example, here is an example of what I suggest for stock definitions:
- Code: Select all
account = stock 1000USD inflow interest inflow deposits outflow withdrawals
Subscripts
Encountering "Population[1]" in an equation simply tells us that the variable "Population" has a single subscript, nothing about what the subscript is.
The equation where population is defined, will contain the necessary information about the dimensions of Population. When the variable is used on the right-hand-side of some equation, subscripts will be checked against the definition of the subscribed variable. This will be the case no matter how the variables are represented, assuming that the equations-based representation contains as much information as any structured representation that might be used instead. To be specific, let us look at your example:
- Code: Select all
Level: Population
Subscripts: AgeGroup
Units: Person
A single equation can capture exactly the same information, like this:
- Code: Select all
Population = stock {AgeGroup | ... } as Person
Here I make use of my suggestion to use braces {...} for arrays and "as ..." for giving the type and/or unit of a variable. Note that "as Person" is needed only if the _expression_ defining the variable does not implicitly determine the data type and unit of the variable.
A problem with representing the definition of a variable, say, as a structured text, is that this would require a very elaborate structure definition, if we are going to support many vendor's dialects (and extensions) of the grammar (syntax as well as semantics) of equations.
Non-negative stocks
I completely reject the use of nonnegative level constructs
Agree 100%
Flow expressions
I do not think we should restrict Level formulations to only have explicitly named input and outputs as this is too constraining
Agree 100%. In Smia, any mathematical _expression_ can be used in the position of a flow. As mentioned on p 49 in my dataflow PDF, it is conceptually wrong to define a separate variable type for flows. It is up to each vendor, of course, to break concepts, but it should not be permitted in a standard for SD.
Best regards,
Magne
- Magne Myrtveit
- Posts: 51
- Joined: Mon Jan 12, 2009 6:52 am
Re: SMILE and XMILE
by Robert
Eberlein » Sun Aug 11, 2013 5:47 am
Hi Magne,
Just one comment on this. A pretty standard equation for population in Vensim is:
Population [gender, AG00]= INTEG (
+ births[gender]- deaths[gender,AG00] + net migrating[gender,AG00],
init pop[gender,AG00]) ~~|
Population[gender,AG01andOver]= INTEG (
-deaths[gender,AG01andOver] + net migrating[gender,AG01andOver],
init pop[gender,AG01andOver])
~ person
~ |
or, if you are not using a cohort control function
Population[gender,A0]= INTEG (
births[gender]-deaths[gender,A0]-aging[gender,A0],
initial population[gender,A0]) ~~|
Population[gender,AR1To99]= INTEG (
aging[gender,AR0To98]-deaths[gender,AR1To99]-aging[gender,AR1To99],
initial population[gender,AR1To99]) ~~|
Population[gender,A100P]= INTEG (
aging[gender,A99]-deaths[gender,A100P],
initial population[gender,A100P])
~ Person
~ |
In both cases, and others like this, the subscripts on population can only be determined by knowing that the subscript elements and subranges used are part of the subscript Age. In Vensim this works because no numbers are allowed and all subscript element names must be unique names. Without that (or tagging) the models would become indeterminant in some cases.
Just one comment on this. A pretty standard equation for population in Vensim is:
Population [gender, AG00]= INTEG (
+ births[gender]- deaths[gender,AG00] + net migrating[gender,AG00],
init pop[gender,AG00]) ~~|
Population[gender,AG01andOver]= INTEG (
-deaths[gender,AG01andOver] + net migrating[gender,AG01andOver],
init pop[gender,AG01andOver])
~ person
~ |
or, if you are not using a cohort control function
Population[gender,A0]= INTEG (
births[gender]-deaths[gender,A0]-aging[gender,A0],
initial population[gender,A0]) ~~|
Population[gender,AR1To99]= INTEG (
aging[gender,AR0To98]-deaths[gender,AR1To99]-aging[gender,AR1To99],
initial population[gender,AR1To99]) ~~|
Population[gender,A100P]= INTEG (
aging[gender,A99]-deaths[gender,A100P],
initial population[gender,A100P])
~ Person
~ |
In both cases, and others like this, the subscripts on population can only be determined by knowing that the subscript elements and subranges used are part of the subscript Age. In Vensim this works because no numbers are allowed and all subscript element names must be unique names. Without that (or tagging) the models would become indeterminant in some cases.
- Robert Eberlein
- Site Admin
- Posts: 157
- Joined: Sat Dec 27, 2008 8:09 pm
Re: SMILE and XMILE
by Magne
Myrtveit » Mon Aug 12, 2013 4:32 am
Hi Bob,
First, allow me to correct something in my previous posting. My Example 4 does actually not belong together with the other tree examples, as DTD is a representation of a language, rather than a model. (DTD is similar to BNF in may ways). Example 4 can be replaced by stock-and-flow or causal-loop representations of models.
Also, I don't know if the point I meant to make about equations language disappeared inside my lengthy text. Restating it here: Model equations are needed when writing about models (in forums like this, for example). Equations should be complete in the sense that it must be possible for humans, and computers as well, to reconstruct and evaluate the model from its equations. It is up to each vendor to determine if the equations syntax will be used by their software also when writing models to file (the MDL (Vensim) way), or if model files use a structured representation of models (the SIP (Powersim), DPA (Dynaplan), Excel, and XMILE way). Smia has a File | Save as feature, that allows the user to store a model in binary format, XML format, or equations format (plain text or HTML).
To your statement in our most recent post:
There is another solution to this problem, which is to make the full dimensions available at the right-hand side of Population's equation, and to merge multiple equations into one, using the approach shown in Figure 66, page 48, in "A framework for dataflow models". This also opens up for using any data type for dimensions; not only lists of named elements.
Let me demonstrate with the basis in your first code example, which looks like this:
A single-equation version would look something like this:
Line-by-line explanation:
The tricks are located in line 1 and 2, which defines full dimensions (line 1) and multiple expressions (line 2).
Smia has many ways to express equations like the one above. One alternative syntax for line 2, makes use of index variables and dimension operators (==) and (:=):
The operator == says that all elements of the dimension share the same _expression_, while := says that the first element has one _expression_, and the rest another one.
Best regards,
Magne
First, allow me to correct something in my previous posting. My Example 4 does actually not belong together with the other tree examples, as DTD is a representation of a language, rather than a model. (DTD is similar to BNF in may ways). Example 4 can be replaced by stock-and-flow or causal-loop representations of models.
Also, I don't know if the point I meant to make about equations language disappeared inside my lengthy text. Restating it here: Model equations are needed when writing about models (in forums like this, for example). Equations should be complete in the sense that it must be possible for humans, and computers as well, to reconstruct and evaluate the model from its equations. It is up to each vendor to determine if the equations syntax will be used by their software also when writing models to file (the MDL (Vensim) way), or if model files use a structured representation of models (the SIP (Powersim), DPA (Dynaplan), Excel, and XMILE way). Smia has a File | Save as feature, that allows the user to store a model in binary format, XML format, or equations format (plain text or HTML).
To your statement in our most recent post:
The subscripts on population can only be determined by knowing that the subscript elements and subranges used are part of the subscript Age. In Vensim this works because no numbers are allowed and all subscript element names must be unique names. Without that (or tagging) the models would become indeterminant in some cases.
There is another solution to this problem, which is to make the full dimensions available at the right-hand side of Population's equation, and to merge multiple equations into one, using the approach shown in Figure 66, page 48, in "A framework for dataflow models". This also opens up for using any data type for dimensions; not only lists of named elements.
Let me demonstrate with the basis in your first code example, which looks like this:
- Code: Select all
Population [gender, AG00]= INTEG (
+ births[gender]- deaths[gender,AG00] + net migrating[gender,AG00],
init pop[gender,AG00]) ~~|
Population[gender,AG01andOver]= INTEG (
-deaths[gender,AG01andOver] + net migrating[gender,AG01andOver],
init pop[gender,AG01andOver])
~ person
~ |
A single-equation version would look something like this:
- Code: Select all
Population = stock {gender, Age | 'init pop' }
inflow { gender, AG00 => births(gender) }
outflow deaths
inflow 'net migrating'
Line-by-line explanation:
- Population is defined as a stock with dimensions gender and Age and initial value init pop.
- Births is defined as an inflow, capturing the information that Vensim puts into multiple equations for Population.
- Deaths is defined as an outflow. Since all elements of Pop can use the same _expression_, no array syntax is needed here.
- Net migration is defined as an inflow.
The tricks are located in line 1 and 2, which defines full dimensions (line 1) and multiple expressions (line 2).
Smia has many ways to express equations like the one above. One alternative syntax for line 2, makes use of index variables and dimension operators (==) and (:=):
- Code: Select all
Population = stock {g==gender, a==Age | 'init pop' }
inflow { g==*, a:=* | births(gender), 0 }
outflow deaths
inflow 'net migrating'
The operator == says that all elements of the dimension share the same _expression_, while := says that the first element has one _expression_, and the rest another one.
Best regards,
Magne
- Magne Myrtveit
- Posts: 51
- Joined: Mon Jan 12, 2009 6:52 am
Re: SMILE and XMILE
by Robert
Eberlein » Mon Aug 12, 2013 7:31 am
Hi Magne,
I am with you on equations. I am just thinking in the specifications we write how we distinguish these from the encoding. I will ask Ignacio Martinez to jump in with comments as well as I know he has spent some time thinking about this.
You picked the easy subscript example, and I unfortunately can't see how the more complex one fits this pattern. If you could reconstruct the following it would be helpful to me:
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 ~|
in this case StageMid is Stage2...Stage21 and StagePriod is Stage1...Stage20 with a map to StageMid to make the second equation sensible.
Bob Eberlein
I am with you on equations. I am just thinking in the specifications we write how we distinguish these from the encoding. I will ask Ignacio Martinez to jump in with comments as well as I know he has spent some time thinking about this.
You picked the easy subscript example, and I unfortunately can't see how the more complex one fits this pattern. If you could reconstruct the following it would be helpful to me:
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 ~|
in this case StageMid is Stage2...Stage21 and StagePriod is Stage1...Stage20 with a map to StageMid to make the second equation sensible.
Bob Eberlein
- Robert Eberlein
- Site Admin
- Posts: 157
- Joined: Sat Dec 27, 2008 8:09 pm
Re: SMILE and XMILE
by Travis
Franck » Tue Aug 13, 2013 8:32 am
Apologies in advance if I missed a subtly
in the discussion -- it appears you both have thought about
all this for a long time. But you did ask for company! ;)
In my head, there is the file format and what is printed in journals (i.e., the human readable form). The discussion appears to be whether the human-readable (say, SMILE) needs to be defined separate from the file format (XMILE) as a spec/standard.
Isn't the human-readable form pretty much defined already by standard mathematics? Right-hand side equals left-hand side? I guess I don't know how else you would write human-readable equations in a journal. I know there many fields, e.g., economics, that code a model in a programming language, but then use standard math formatting when publishing and discussing. I did the same in my SD work.
So, this would lead me to think that defining the XML format is most important. That is, we might be able to get by having XMILE without SMILE.
And when it comes to model documentation, people would archive the XMILE, use XMILE in their dissertation appendix, use 'math' formatting in their papers and dissertation discussion, and use a XMILE-to-HTML converters for cool documentation tools like Ignacio makes.
I write this acknowledging that I didn't fully follow the above thread about subscripts, but maybe this is a moment to pause and bring more of us up to speed.
~Travis
In my head, there is the file format and what is printed in journals (i.e., the human readable form). The discussion appears to be whether the human-readable (say, SMILE) needs to be defined separate from the file format (XMILE) as a spec/standard.
Isn't the human-readable form pretty much defined already by standard mathematics? Right-hand side equals left-hand side? I guess I don't know how else you would write human-readable equations in a journal. I know there many fields, e.g., economics, that code a model in a programming language, but then use standard math formatting when publishing and discussing. I did the same in my SD work.
So, this would lead me to think that defining the XML format is most important. That is, we might be able to get by having XMILE without SMILE.
And when it comes to model documentation, people would archive the XMILE, use XMILE in their dissertation appendix, use 'math' formatting in their papers and dissertation discussion, and use a XMILE-to-HTML converters for cool documentation tools like Ignacio makes.
I write this acknowledging that I didn't fully follow the above thread about subscripts, but maybe this is a moment to pause and bring more of us up to speed.
~Travis
- Travis Franck
- Posts: 21
- Joined: Sun Jan 11, 2009 7:48 pm
Re: SMILE and XMILE
by Thomas
Fiddaman » Tue Aug 13, 2013 2:18 pm
My possibly naive impression was that the
purpose of SMILE is to define the constructs that constitute the
equations and ancillary bits of a model, with XMILE as a file
format for storing SMILE. But on reflection there seems to be
quite a bit of overlap - both SMILE and XMILE define stocks and
flows, for example, whereas an alternate approach would be to have
a SMILE-like spec for what constitutes an equation, and then an
XMILE spec for storing an equation that's agnostic about what kind
of equation it is.
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>.
Regarding naming, I don't mind the current options, but in the spirit of Travis' comment, we could use .J or .JK, with a nod to the dynamo integration syntax.
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>.
Regarding naming, I don't mind the current options, but in the spirit of Travis' comment, we could use .J or .JK, with a nod to the dynamo integration syntax.