OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xmile message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xmile] macros + filters


Hi Bobby,

Good points.    My take is that the primary benefit of implementing macros is to add new functions required by a mdeol that aren't supported.  A simpler macro functionality could meet that need.

From an implementation point of view, there's 4 levels of macros
1.  simple macros (no variables, no recursion).  This could be implemented by text substitution when importing a model.
2.  macros with internal variables, no recursion.  This could be implemented by adding new variables when importing a model
3.  macros specifying custom building blocks.   Seems more complex to implement.
4.  macros with recursion.  For  most software would need to implement new features to the core computation engine to make this work.

I'm fine with implementing 1-2 and possibly #3.  But #4 above is a lot more work.  I'd be ok with prohibiting recursion.  (the simplest way to limit this would be to prohibit the use of macros in other macros).  

WILL


On Mon, Jun 9, 2014 at 9:58 AM, Bobby Powers <bobbypowers@gmail.com> wrote:
Hello fellow TC members,

I missed the last meeting, so I apologize if this was addressed
(although I don't see it in the minutes), but I'm just looking at the
Macro + filters that was recently added to the OASIS spec, and have
some concerns.

Part of it is that AFAIK we haven't discussed macros at all.  There
are a lot of hairy cases with macros, especially around recursion and
separate sim-specs, and I'm not sure if parts of this have been
implemented.  I added the "FACT" example to a STELLA model, and it was
unable to simulate.  I think part of the rationale behind macros is
for Vensim compatibility, but I had thought Bob mentioned at one point
there were extensions needed for that.  So I'm wary of having
complicated parts of the spec that currently have no implementation
when we don't even know if they will meet Ventana's needs.

I have similar concerns about the "modifying stock and flow behavior"
section.  It is quite complicated to me, hard to follow, and adds a
LOT of overhead for people wanting to implement the spec.  Can we get
a clarification - does isee currently support everything listed in
that section?  If not, let us please remove it from v1 of the spec.
An example of the problem: "The existence of such a macro does not
rule out another macro that operates on the stock instead of its
outflows. Such a macro would not have the applyto option. In fact, any
stock or flow option can implement three filters: one for the stock or
flow itself and one for each of the two applyto options".  I think
that is confusing at best - but is also unspecified behavior.  In what
order to multiple filters run is my first question.

yours,
Bobby

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




--
William Glass-Husain   /forio  |  +1 (415) 440 7500 x89  |  forio.com



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]