Subscripts

This forum is for discussion of the System Dynamics model representation standard XMILE. Discussion here will be monitored by the Society's technical standards committee with ideas and concerns conveyed to the OASIS Technical Committee responsible for defining the standard.
Forum rules
Please note: By posting here you grant permission to the Society Technical Committee members to repost with attribution on the OASIS discussion forum. If you have material for which you wish to maintain copyright control please post a link to the copyrighted work.
Post Reply
Robert Eberlein
Site Admin
Posts: 179
Joined: Sat Dec 27, 2008 8:09 pm

Subscripts

Post by Robert Eberlein » Mon Aug 05, 2013 6:27 pm

Subscripts can be complicated, and unfortunately most models that make use of subscripts make use of some of the complications. The draft Spec simply does not have the flexibility to accommodate the majority of models written in Vensim that use subscripts. I would propose the following:

1. Subscript names need to be unique as with any model variable (same as spec)

2. Subscript names define a new namespace within which elements and subranges can be uniquely named (or elements can be left unnamed and referred to by number). (For example if City is a subscript then City.Boston,City.NYC and City.LA would be elements and City.BigCity could be defined as City.NYC and City.LA. Also City.NYC and City.2 would be synonymous in this case).

3. Equations using subscripted variables always use them in their fully verbose form and there can be one or many equations for a subscripted variable. (For example suppose the subscript VehicleType takes on values Small,Medium,Large,Pickup,Van, VehicleType.Car takes on values Small,Medium,Large and VehicleType.Truck takes on Pickup,Van we might have

Disposals[VehicleType]=Vehicles_in_use[VehicleType]/Average_lifetime[VehicleType]

and

Recertifications[VehicleType.Car] = Vehicles_in_use[VehicleType.Car]/CarRenewalTime
Recertifications[VehicleType.Truck] = Vehicles_in_use[VehicleType.Truck]/TruckRenewalTime

and

Average_lifetime[VehicleType.Small]=16
and so on.)

4. Reduction in the number of subscripts for a variable should be reserved for the equivalent of function overloading in a future XMILE Spec. For example Population[Gender] might be the sum across AgeGroup of Population[Gender,AgeGroup].

5. Sums, inner products and the like be specified using functions in the form
SUM([vectorrange],expression)
where
vectorrange is a comma delimited list of either Subscripts, subscript subranges or numerical element ranges as in
[Age.1-Age.25,Gender]
or equivalently
[Age.Youngsters,Gender]

I can certainly expand on these if they are unclear, and the notation could be adjusted if there are better alternatives. Though verbose, the above suggestions are clear, and closer to being complete. The biggest things missing relative to Vensim's capabilities are exception equations and subscript mapping. I can't speak to Powersim or Stella but hopefully someone else can chime in on those.

Magne Myrtveit
Posts: 57
Joined: Mon Jan 12, 2009 6:52 am

Re: Subscripts

Post by Magne Myrtveit » Fri Aug 16, 2013 9:06 am

Hi Bob,

Below are a few comments to your subscript posting.

To most people, the term subscript means "index of an array variable". The dimension of a variable and the subscripts used to access elements inside the variable, are different things. In Vensim the term "subscript" refers both to a variable dimension and to a variable subscript. Furthermore, Vensim restricts dimensions to be defined by named elements, belonging to a "subscript". Looking forward, it might be worth introducing the concept of a type, and say that dimensions are defined in terms of (countable) types, and variables are indexed using subscript expressions that compile to a value or type that is compatible with, and a subset of, the type defining the corresponding array dimensions. A separate list type is introduced, and serves as the basis for Vensim-style "subscript" objects, i.e., an ordered list of named elements.
Robert Eberlein wrote: 1. Subscript names need to be unique as with any model variable (same as spec)
Agree
Robert Eberlein wrote: 2. Subscript names define a new namespace within which elements and subranges can be uniquely named
Agree.
Robert Eberlein wrote: ... (or elements can be left unnamed and referred to by number). (For example if City is a subscript then City.Boston,City.NYC and City.LA would be elements and City.BigCity could be defined as City.NYC and City.LA. Also City.NYC and City.2 would be synonymous in this case).
If you allow elements and integers to be interchangeable, the list type (Vensim "subscript") behaves just as an enumeration in C++, i.e., a way to define constants (i.e., named values) that can be used instead of numbers to enhance readability (among other things).

Another way to interpret lists, is to let the names themselves to be members of the list type. This changes the list type from a numeric interval (1 to N) to an ordered collection of names. This approach is closer to the users' view of lists (unless the user is a programmer or used to software that uses programmer's view on things), and it also provides many advantages when it comes to quality assurance of models as well as communication / readability of models and their input/output.
Robert Eberlein wrote: 3. Equations using subscripted variables always use them in their fully verbose form and there can be one or many equations for a subscripted variable.
Another approach is to use path notation, and only specify as much as necessary in order to make the reference unambiguous. See http://www.myrtveit.com/papers/A_framew ... models.pdf page 31.
Robert Eberlein wrote: 4. Reduction in the number of subscripts for a variable should be reserved for the equivalent of function overloading in a future XMILE Spec. For example Population[Gender] might be the sum across AgeGroup of Population[Gender,AgeGroup].
I'd prefer to use an asterisk (*) or the full name of the type defining the dimension, when all elements of the dimension are passed on. The exception is when the entire variable is passed, for example to sum.

Code: Select all

x=sum(Population) (* Ok *)
y=sum(Population(*, *)) (* Same as above *)
z=sum(Populatoin(Gender)) (* Error: Too few subscripts *)
If case z is passed as Ok, there is a significant risk of introducing bugs in models when variable dimensions are added, moved, or removed.
Robert Eberlein wrote: 5. Sums, inner products and the like be specified using functions in the form
SUM([vectorrange],expression)
where
vectorrange is a comma delimited list of either Subscripts, subscript subranges or numerical element ranges as in
[Age.1-Age.25,Gender]
or equivalently
[Age.Youngsters,Gender]
A much more elegant solution is to specify the vector range in the position of the subscript, like this:

Code: Select all

Total population = sum(Population(Age(1) to Age(25), Gender))
or (if dimensions can be real numbers, and not only lists) simply:

Code: Select all

Total population = sum(Population(1year to 25years, *))
Best regards,
Magne

Robert Eberlein
Site Admin
Posts: 179
Joined: Sat Dec 27, 2008 8:09 pm

Re: Subscripts

Post by Robert Eberlein » Sun Aug 18, 2013 5:42 am

Hi Magne,

Just a couple of notes. Namespaces and paths work essentially the same in order to make something unique. If the first dimension of a variable is something like age then anything appearing in that position is unambiguous, though it might not appear to be so looking at the equation in isolation. I kind of like forcing the use of the dimension when it is used as it makes the equations much more readable for people, but it is also annoying to have to enter so there are tradeoffs.

When I talked about equation overloading I was speaking of not using SUM functions simply saying Population for the total across all dimensions. This is likely to be most useful in output but is fundamentally just a shortcut and I can see staying away from it.

The use of * in any position is an old dynamo trick, something I find really confusing as there is not even a hint of the dimension anymore.

Your range specification format is more elegant when there is one variable in the expression, but gets a bit cumbersome when there are three of four - so it is a tradeoff with respect to equation complexity.

Magne Myrtveit
Posts: 57
Joined: Mon Jan 12, 2009 6:52 am

Re: Subscripts

Post by Magne Myrtveit » Sun Aug 18, 2013 8:25 am

Hi Bob,
Robert Eberlein wrote: When I talked about equation overloading I was speaking of not using SUM functions simply saying Population for the total across all dimensions.
I agree that modellers must be able to write sum(Population), no matter how many dimensions Population has.
Robert Eberlein wrote: The use of * in any position is an old dynamo trick, something I find really confusing as there is not even a hint of the dimension anymore.
Asterisk (*) is used as a wildcard in many cases. It is not precise, but it is compact :-)
Robert Eberlein wrote: Your range specification format is more elegant when there is one variable in the expression, but gets a bit cumbersome when there are three of four.
I see your point in the context of Vensim's grammar. However, if variable subscripts (on the right-hand-side) of equations can be expressions (and not only named dimensions), the Vensim grammar lacks the flexibility we need (since it requires the same subscripts for all variables in the expression).

Again: The syntax is the smallest problem. We need to lift our eyes to the conceptual level: What is an array, how is it defined, and how is it used?

Best regards,
Magne

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest