Opened 9 years ago
Last modified 6 years ago
#487 new defect
Constraints should be relational operator not assignment operators
Reported by: | butler | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | SasView Next Release +1 |
Component: | SasView | Keywords: | |
Cc: | Work Package: | Beta Approximation Project |
Description
currently the constraints/optimizer treats the constraint as an assignment rather than relational operator. The result is that for 3 models the following constraint set up
M1.parameter1=M2.paramter1 M1.parameter1=M3.paramter1
will result in ONLY the second constraint being implemented (the second assignment to M1.parameter1 overwrites the fist assignment). However if the constraints are set up as follows:
M2.parameter1=M1.parameter1 M3.parameter1=M1.parameter1
results in the expected behavior. This is both confusing to users and seems logically incorrect for a constraint which should always, I think, be a relational object.
Change History (6)
comment:1 Changed 9 years ago by butler
- Milestone changed from SasView 4.0.0 to SasView Next Release +1
comment:2 Changed 7 years ago by butler
- Milestone changed from SasView Next Release +1 to SasView 4.3.0
comment:3 Changed 6 years ago by smk78
- Milestone changed from SasView 4.3.0 to SasView Next Release +1
- Work Package changed from SasView Bug Fixing to Beta Approximation Project
comment:4 Changed 6 years ago by richardh
I would say that constraints have to be "assignments" as the second example, they are after all mathematical equations. The first example does what it should with the scond over-riding the first. Suggest this ticket is closed.
comment:5 Changed 6 years ago by butler
While I agree that in constructing a full language the assignment approach would make sense, in this case it does not make sense other than to punish users who are not a programmer:-) I can see absolutely no situation where overriding makes any sense in the context of the constraints setup. If m1.x=m3.x why every say m1.x=m2.x??
We have however found users who want m2.x, m3.x etc to all be the fixed to m1.x … and their natural behavior it appears is to write as example 1 above then don't understand why it doesn't work. I would argue that allowing overwriting adds unnecessary complexity to constraints since you have to now not only think about what relations you want but also worry about the order in which you provide them.
comment:6 Changed 6 years ago by richardh
We might perhaps introduce some new logic symbol such as M2.radius ~ M1.radius for something that has to work in both directions, but even then the details of how the fitting was done would have to be looked at very carefully. I suspect that sasview would still have to internally set up equivalent assignments. Still suggest we close this ticket as we have plenty more to be getting on with.
[Actually in FISH, I can and do nest constraints, then tie back the least squares partial derviatives by running backwards through the constraints list.]
Moving to Beta Approximation Work Package whilst we consider constraints.