Part 3
Re:
SMILE and XMILE
by Karim
Chichakly » Tue Aug 13, 2013 5:31 pm
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.
Karim
Chichakly
Posts: 20
Joined: Fri Apr 10, 2009 11:52 am
Top
Re:
SMILE and XMILE
by Magne
Myrtveit » Wed Aug 14, 2013 1:39 am
Thanks, Travis, for joining 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
Top
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:
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
Top
Re:
SMILE and XMILE
by Magne
Myrtveit » Wed Aug 14, 2013 2:54 am
Thanks for joining, in, Thomas. I agree
with your statement:
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.
SMILE is just another dialect of SD, expressing one set of
concepts and a particular semantics of these concepts. If we
limit SMILE to the "inner core concepts", it is possible to
define something that every SD software can represent. Any
extension beyond that, will have to be vendor-specific, and
not part of the standard.
-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
Top
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?
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
Top
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.
Robert
Eberlein
Site Admin
Posts: 157
Joined: Sat Dec 27, 2008 8:09 pm
Top
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
Karim
Chichakly
Posts: 20
Joined: Fri Apr 10, 2009 11:52 am
Top
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:
= -- 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_
Cases 1, 3 and 4 are used in the WIP example.
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
Top
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.
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
Top
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.
