Re: [xmile] macros + filters

[Karim Chichakly <kchichakly@iseesystems.com>]

Hi Bobby,

We have talked about macros at TC meetings and decided to leave them in.  They were not just added, but carried over from the draft as we discussed.

You seem to have a large number of issues with the spec.  The appropriate forum - since you are on the committee - is to come to the meeting on Friday and bring them up.  This level of technical detail - and this level of raising entirely new issues from a TC member - should be handled in the TC meeting not through lots of e-mails that only a few people answer.  We meet often enough to address these issues as a group.

Thank you,

Karim

On Mon, Jun 9, 2014 at 3:16 PM, Bobby Powers <bobbypowers@gmail.com> wrote:

Hi Will,

So I agree about the level of effort/prioritization.  I guess my
question is can we create a v1 XMILE spec that supports 90% of SD
models without macros?  I think the answer is yes.  If others feel
differently - what do we specifically need from macros to support
80-90% of SD models?

yours,
Bobby

On Mon, Jun 9, 2014 at 2:58 PM, Will Glass-Husain <wglass@forio.com> wrote:
> 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
>

---------------------------------------------------------------------
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