Show arrows, even erroneous arrows
Suggestion: allow users to draw influences between nodes A and B even if the arrow would introduce a circularity. When a circularity is implied, the arrow could be fuzzy, dashed, or otherwise indicative of error.
Reasoning: it should be possible to construct the influence diagram as intended before working out details of the definitions. Seeing the intended influence diagram is an important step in design. Not being able to add an intended influence because of temporary technical glitches should not preclude seeing the intent.
A compromise might be to add to the error message that pops up when attempting to add an invalid arrow "Show arrow anyway (but with fuzziness to indicate error".
Thank you so much for your suggestions! These notes have been shared with our developers and this will be taken into consideration for future updates to Analytica.
We loving hearing this kind of feedback from users. Please keep it coming!
> it should be possible to construct the influence diagram as intended before working out details of the definitions.
I totally agree. Analytica does in fact allow you to do this while you are constructing your influence diagram prior to filling the details of your definitions, which I think is indeed what you want. And yes, that is something I do all the time -- I very often draw the diagram first, and will sometimes have illogical loops (temporarily) as I'm working out the design.
The trick here is that you should be drawing your influence diagram first, before you fill in the Definitions. During that stage, feedback loops are totally fine.
The limitation (in which it doesn't allow you to draw back arrows that are inconsistent with your actual definitions) arises later once you've filled in the definitions. As you enter definitions, it will remove or add arrows you drew in order to reflect the actual definition as it is entered. Once it has these details, it has a couple special features that kick in the ensure consistency and prevent disallowed loops. This is where it isn't allowing you to draw a back arrow that would cause a cyclic dependency. At this point, it has enough information to catch you making a mistake early, at the moment you are making the mistake (rather than having to wait until much later during evaluation, when you're focus of attention has gone on to other things). So by flagging your attempt to create a cyclic dependency early, it is trying to be helpful.
When you attempt to create a loop with a back-arrow, and your definitions are all filled in, the error message says "To create ... a feedback loop, use the Dynamic() function." This is in fact providing the clue about how you could override the loop detection and tell it that you want it to allow a back-arrow. You would need to edit the definition of the upstream variable and change it to e.g.,
Dynamic( DownstreamVar[Time=0] ; «orig definition of upstream var» )
That will in fact draw a gray arrow in the backward direction. The result of DownstreamVar[Time=0] is ignored here, it is serving as a dummy just to create the appearance of a dependency. The use of Dynamic indicates that you want to allow a feedback loop. Of course, eventually you'll want your upstream variable to actually use the (time-shifted) result of the downstream variable in some meaningful way, otherwise you wouldn't be creating the arrow in the first place. But this trick with the semi-colon can serve as a temporary placeholder until you return to it to fill in your eventual logic. Just be careful to remember that you need to return to it, so you don't forget to fill in your desired logic.
Another option is to temporarily comment out some of the upstream variables, so that the Definitions aren't really filled in. This has the advantage that it cross-hatches the nodes, so you won't forget to return to them to uncomment later. The downside of this option is that you may need to comment multiple definitions so as to "break" all the cycles -- like if there are two paths from X to Y, you may need to comment something on each pathway.
Lonnie, I understand the rationale and had identified workarounds, although not the one you mention. However, model building is an iterative process. After one has a working model with all nodes defined, one thinks of embellishments or corrections. These might be simple and localized or somewhat of a re-design. Implementing the changes includes the usual false steps of typos, syntax errors, etc. Fixing a particular one may be a diversion at the moment. Thus, I would still recommend allowing erroneous arrows to be shown, but with something like fuzziness to highlight them. The semicolon trick wouldn't indicate that a problem exists. The commenting-out-of-definitions option would show that a problem exists but would take more work and introduce the opportunity for more typo-type errors. You may not be convinced, but ponder it as you confront the long list of to-do's. In the meantime, I'll try the semicolon trick.