Opened 8 years ago

Last modified 5 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


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


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:


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 8 years ago by butler

  • Milestone changed from SasView 4.0.0 to SasView Next Release +1

comment:2 Changed 6 years ago by butler

  • Milestone changed from SasView Next Release +1 to SasView 4.3.0

comment:3 Changed 5 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

Moving to Beta Approximation Work Package whilst we consider constraints.

comment:4 Changed 5 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 5 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 5 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.]

Note: See TracTickets for help on using tickets.