Repository navigation
formulation constants can be set by an inflow? #38
Description
for instance, given a1->b a2->b a possible formulation for b might be b = a1_c_a1, where c_a1 is a2 (ie b = a1_a2)... instead of the expected b = a1_c_a1 + a2_c_a2
This is just semantic, but perhaps building formulas like this would be more intuitive than defining an additional functional form (multiplicative to replace linear-combination in this case). However, this also has the drawback of making the selected functional forms less meaningful. Perhaps it is worthwhile to ensure that particular functional forms are adhered to as they should be.
Activity
7yl4r commentedon Oct 16, 2014
It seems like this may only make sense for personality variables. This is their purpose, I think. Constants which are common across the population can be hard-coded, but "personality variables" are different for different individuals, thus they are specified using a distribution and then connected into their place as desired.
This usage also necessitates that personality variables cannot behave as typical node inflows I think. Perhaps a different edge style should even be used to denote this.
7yl4r commentedon Oct 16, 2014
personality nodes are also useful in the case that a model has several different functions with the same constant value piped in. Today I am thinking that the difference between personality nodes and context/state is significant enough that the node style as well as the edge style should be changed. Additionally, an expanded view of the infoflow graph could also be shown with all constant nodes broken out as personality nodes.