-
Notifications
You must be signed in to change notification settings - Fork 3
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
Should assign_based_on assignments be "weak"? #337
Comments
I think that the current order of operations makes more sense. If you do |
Yes, of course. The question is, should the semantics of
Correct, and speaking of complexity, there's gymnastics in the code to ensure this, which would fall away if the |
I guess what I'm trying to get at, would not redefining of the meaning of |
Got some test code on the branch for this, but may abandon this following our discussions. Kicking the can down the road for now. |
Again from TRON etc. If we have:
we end up with
stokes=[I]
, since theband
section is evaluated after theobs
section. This prevents us from making per-observation tweaks that override the per-band assignments. Arguably, this is the wrong way around!A simple solution would be to define
assign_based_on
as being a "weak" assignment, i.e. have the assignment take effect only if not already assigned to previously. Thoughts?The text was updated successfully, but these errors were encountered: