Closed itsmathtime closed 4 years ago
Apologies for the delay. I've confirmed the issue and will try to fix it soon.
After a closer look, I found the problem. In you code you should write:
cstrs = [og.constraints.NoConstraints(),
og.constraints.NoConstraints(),
og.constraints.Ball2(None, 1.5),
og.constraints.NoConstraints(),
og.constraints.NoConstraints()]
You had omitted the parentheses. The difference is that og.constraints.NoConstraints()
is an object of type og.constraints.NoConstraints
, whereas og.constraints.NoConstraints
is the corresponding class.
In your example you might want to rethink your segment ids. You can also combine the sets of type NoConstraints
into a single instance of NoConstraints
if you like. You may find more information about it here.
I will update the documentation with some additional examples.
Describe the bug When I combine CartesianProduct with NoConstraint in a certain way I am able to generate code that triggers the assert at
src/constraints/cartesian_product.rs:139
. Even though all inputs and constraints are well formed. To me it looks like there is an assumption that NoConstraint is not used with CartesianProduct, which is a bug.To Reproduce
Steps to reproduce the behavior:
Expected behavior
As far as I understand, the problem is well posed, and the code-generation should not generate code that triggers the assertion at
src/constraints/cartesian_product.rs:139
System information:
System/Platform: Laptop
OS: [e.g. Ubuntu, iOS, Windows, Raspbian, etc] Ubuntu 19.04
What is the output of
rustup show
?nightly-x86_64-unknown-linux-gnu (default) rustc 1.43.0-nightly (7cdbc87a4 2020-03-14)