-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SSA/multiagent force initial state widgets to sum to 1 even if system size is not constant #318
Comments
N.B. since release 1.0.0 has already been deployed this will need to be a patch release (1.0.1) |
I can unlock the sum to 1. |
At the moment, SSA and multiagent allow the system to grow over time above the system size, however, the initial state was locked to sum 100% of S. |
I agree that sounds strange - can that not be changed? |
at the moment, the initial state sum is fixed to 1. |
So you're saying that actually it makes some sense to force the sum to 1 since it refers only to the initial conditions? Is there a branch I can checkout to see how it's working now? |
it is already working like this without change |
I'm working to make possible to have initial state >1 for other views (e.g. |
We need to decide if we want this possibility active also for SSA() and multiagent() |
Well now I'm not sure we should do so for either - |
Too late, I half implemented it... However, I may keep it locked to 1 when the user simply calls |
I changed my old |
Moving the discussion on warnings to #352 Not clear to me that the new functionality makes sense - SSA noise magnitude is determined by system size, no? Just because something has been implemented doesn't mean it should be merged... |
See also issue #317 - however in this case the user cannot correct the error, since the slider update logic inappropriately enforces this constraint.
Is it a feature of
SSA()
that non-constant system size models cannot be simulated? In which case SSA needs to check, and raise an exception if the model is not suitable for the method.multiagent()
with moving particles (which the method apparently defaults to for this class of model) exhibits the same problem.The text was updated successfully, but these errors were encountered: