[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xmile] macros + filters
Hi Bobby,I have been heads down on other things and have not had a chance to weigh in on most these topics.
There is a balancing act between simplicity and completeness that we have been trying to perform. Macros are important in that they allow for more flexibility of functionality without having to build it into the spec. in a curious way they are a simplification. I have a hard time seeing how we could do without them, so the only question is really what level of functionality it is reasonable to allow them. The turing complete notion may be overreach for many vendors, but it also really opens the door to interesting extensions of models and the problems they can be used to address.
More generally, we do want to have a framework in which both subtlety and complexity can be expressed, while maintaining an overall cleanliness of design. While I have no doubt we could create something more elegant and cleaner given time, I am really anxious to see something come together for publication and that, fundamentally, is the mandate of the TC.
As to submodels without modules - this is actually a pretty common conceptual frame for many people in the field who are putting together models from sectors - generally without any hierarchical depth (I'll do finance and you can do production). Having the of and to works to accomplish this, especially in cases where the models are never put together with any visual frame. It is very much like what the old Conductor tool from Los Alamos was trying to accomplish. Modules are a bit more complicated - but if they still get used in preference to the flat structure we can simply require them the next go around.
Implementation is a far more organic process then most of us seem to be articulating. Having someone read the spec and try to write software to support it is unlikely to be too common. More likely is that vendors will write stuff out more or less following the specs rules. Then people with models will try to read something, and do just enough to get the models they are interested in working. Some things will end up getting used very often, and lots of people will be able to handle them - others will be ignored and it will be as if they are not in the spec at all. Because of this I am not so worried that we will create something that only supports pockets of individual vendors that all own a little bit of the spec but never enough to make sharing useful. Even without the spec we have a lot of common ground in visual representation and language - the spec will enhance that. I am relatively optimistic on this front.
Bob Eberlein
On 6/9/2014 3:16 PM, Bobby Powers 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]