You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What if the solver (optionally) ignores rules between the slots that were deterministic at the beginning?
Such slots would affect non-deterministic slots around them, but will not be evaluated themselves - could never be removed even if no rule allowed them to be next to each other.
Why?
if a boundary layer of slots is added to control what should be happening on the boundary of the envelope and such slots are deterministic & containing an "empty" module, then rules need to exist to allow such "empty" module to be next to itself. If the initially deterministic slots were fixed, no such rules would be needed.
if the user sets a fixed composition of slots before the solver starts, currently such slots must comply with the global rules. but what if the user intentionally breaks the rules there? or doesn't want to allow such pattern to appear anywhere else and therefore intentionally doesn't want to define the rules holding the deterministic pattern together. if the initially deterministic slots were fixed / untouchable, then this wouldn't be necessary.
The text was updated successfully, but these errors were encountered:
janper
changed the title
Ignore deterministic modules
Ignore initially deterministic modules
Oct 4, 2022
Your suggestion makes sense and looks useful, but there are some subtleties involved.
I wonder if what you describe isn't the same as masking everything except the surface layer of the initially deterministic parts. You keep the surface layer unmasked, because you want it to interact with the nondeterministic slots around it when propagating constraints - either during canonicalization or observation.
If we determine it is the same thing, I'd rather we use the mechanism we already have. We can still make this an option to generate these masks automatically instead of setting them from client code, if we want to.
UPDATE:
Ah. Nope, this won't be enough, because you also need to suppress interactions within the surface layer itself. And you can't mask the surface layer, because that would suppress interactions between it and the surrounding nondeterministic slots.
What if the solver (optionally) ignores rules between the slots that were deterministic at the beginning?
Such slots would affect non-deterministic slots around them, but will not be evaluated themselves - could never be removed even if no rule allowed them to be next to each other.
Why?
The text was updated successfully, but these errors were encountered: