Skip to content
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

Ignore initially deterministic modules #30

Open
janper opened this issue Oct 4, 2022 · 2 comments
Open

Ignore initially deterministic modules #30

janper opened this issue Oct 4, 2022 · 2 comments

Comments

@janper
Copy link
Contributor

janper commented Oct 4, 2022

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.
@janper janper changed the title Ignore deterministic modules Ignore initially deterministic modules Oct 4, 2022
@yanchith
Copy link
Member

yanchith commented Oct 6, 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.

I'll think about how to best do this.

@janper
Copy link
Contributor Author

janper commented Oct 29, 2022

Right, your update is the actual issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants