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

Lazy creation of variables #1086

Open
cprudhom opened this issue Feb 15, 2024 · 0 comments
Open

Lazy creation of variables #1086

cprudhom opened this issue Feb 15, 2024 · 0 comments

Comments

@cprudhom
Copy link
Member

It would seem appropriate to me to be able to delay the actual creation of variables as long as possible, or at least their domain, so as to be in a better position to determine the most appropriate format.This is particularly true when creating models using modelling languages (such as MiniZinc or XCSP3) or when using non-experts. See for instance minizinc/2029/liner-sf-repositioning/fm3_0.mzn.

With the use of LCGs, the question also arises because the behaviour of enumerated and bounded variables is different. In particular, bounded variables do not allow you to designate an instantiation literal. This poses a problem when this type of variable is used in table constraints, for example.

Ideally, it should be possible to "promote" a variable. In practice, it should be possible to replace a variable with a more suitable one. In Java, this is not natively possible (unlike SmallTalk or C++ and pointer swapping). It requires the implementation of a wrapper around the variable.

In early version of choco-solver, a distinction was made between variables and their domain (as an object). The variable itself was a wrapper around its domain. Maybe that should be considered anew.

From a software engineering point of view, this doesn't change much. From a performance point of view, however, this introduces an extra layer in the call stack. As in choco-solver, failures are handled by raising an exception, this additional layer can ultimately have an impact on performance, as the distance between the exception and the catcher is greater (https://shipilev.net/blog/2014/exceptional-performance/ or https://www.baeldung.com/java-exceptions-performance).

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

1 participant