Closed balacij closed 2 weeks ago
As a reminder, this ticket is about building constraints on quantities, specifically 'this quantity must be one of these values' constraints.
@NoahCardoso To re-iterate our intended work:
As of right now, we decided that this should involve sets in the generated code, but we can come back to it later to make sure.
As such,
*Expr
. We will need to bridge this gap in all Expr
s and in drasil-gool
(@B-rando1 can assist with GOOL :slightly_smiling_face:).x \in {... , values, ...}
.Finally,
nomThick
, which currently describes this constraint in the description of the nominal thickness
quantity and which is not actually used in code generation (see #3818 for more details).Here are the prototyped examples in Python and Java and how I think they should look like
It all looks good - except that enumerated floats are a bad idea. Once in a while, things will go wrong. I would much rather use integers (i.e. multiply everything by 10) for the internal storage of these numbers.
This is what I have so far. I'm currently just working on making sure it is displayed properly. How should I go about creating sets in GOOL? I have been able to get the Python example working with sets as a constraint but I have not yet added to GOOL. I assume I would need an isIn
operation as well as defining Set
s
I have a WIP branch open #3846. It's pretty rough currently but I will clean it up once I can get things working.
I have got set
s and the in
operation working in Python. Within the next day or so I should be able to get it working in the other languages.
This is what I have for the C++ example however I am not sure if we should use set
s in C++. @balacij mentioned that the set
API seems to be discouraged. https://lafstern.org/matt/col1.pdf
This is looking good. My C++ is too rusty for me to offer advice on which API to use. I'd have to use the same tools you have to investigate (i.e. SE, google, chatGPT, etc)
FWIW, if a language has some missing features, and we can polyfill them with our own generated code, I see no reason why we shouldn't do that. For example (and I'm not saying we should strive for perfection in this PR, but this is a hypothetical follow-up), we can define our own contains
operation in a drasil_polyfill
shared library.
template <typename E>
bool set_contains(const std::set<E>& set, const E& element) {
return set.find(element) != set.end();
}
At least for now, I think you're making the right choice in looking to move the set into a variable.
Reading that file I sent now, I think we should prefer a std::set
over a vector at least, for readability. The performance considerations of set v vector would be preemptive. So, I'd call set the correct data type to use now. I just wanted to make sure because I found the set API to be quite lacking (no contains
seems quite odd to me).
Related to: https://github.com/JacquesCarette/Drasil/issues/2646#issuecomment-871564379 , https://github.com/JacquesCarette/Drasil/issues/2646#issuecomment-873109412 , and #2118
Originally posted by @JacquesCarette in https://github.com/JacquesCarette/Drasil/issues/2646#issuecomment-873109412