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
chocosolver chokes on #property * a statement? #24
Comments
I'd forgotten about this issue. It turns out the issue was actually due to the Fourier-Motzkin elimination optimization. Long story short, it was spinning in an infinite loop because it couldn't detect a fixed-point due to the way linear equations were being eliminated. The problem is now fixed in the latest chocosolver develop branch (commit 8af6d24). Thanks for the bug report! |
I've added a feature in commit a432d8d that can be used to have this same effect. The feature is very new, so you will have to do a bit of manual work to take advantage of it right now. For this specific example, you would add the following line to your .js file: branchingPriority([[c0_hwComponents, c0_platforms, c0_CAN, c0_DO, c0_D1, c0_price, c1_price]]); Couple of notes.
|
You can use Choco escapes to add that piece directly into your Clafer model:
the contents of choco escapes are added at the end of the compiler's output for choco. If a name is unique in the whole model, then it'll always have the c0_ prefix. But because two different clafers have the name |
Seriously, it's time for a new release :-)
Thx for this! |
Note: Resubmission of gsdlab/ClaferChocoIG#7. I just checked with 0.4.2.1 (binary distribution), and the problem is exactly the same. As it's friday evening, it's a perfect moment to do these kinds of things :-)
Consider the following clafer model
Whereas claferIG seems to be able to succesfully generate instances from this model, it seems like the chocoIG fails to do the same. Removing the
#platforms * 10
clause seems to "solve" the issueand then the the solver seems to get stuck in an endless loop...
Add-on questions from a follow-up comment on my side:
On the other hand, would there (in this particular case) be a possibility to somehow declare that the price attribute of the Deployment variable is "derived" (in the UML sense), such that the backend knows it should actually not branch on this variable for instance?
The text was updated successfully, but these errors were encountered: