ModelicaStandardLibrary
ModelicaStandardLibrary copied to clipboard
modelica
Implemented and tested MultiAnd / MultiOr
Comparing more than 2 Boolean signals with logical blocks {and, or} quickly gets tedious. For these cases I've implemented Modelica.Blocks.Logical.{MultiAnd, MulitOr}, using Modelica.Math.BooleanVectors.allTrue and Modelica.Math.BooleanVectors.anyTrue.
Related to this, but not to be handled in this PR, isn't it a mistake that allTrue and anyTrue are implemented using an algorithm with iteration rather than using min and max array reductions?
@henrikt-ma: To be honest, I don't know. Maybe because OM has troubles with vectorized function calls: see Modelica.Electrical.PolyPhase.Basic.{Star, Delta} and some more. Feel free to propose a PR. - Thanks for the PR. Also strange: allTrue and andTrue are (nearly) the same.
@henrikt-ma: To be honest, I don't know. Feel free to propose a PR.
OK, I'll do it for the sake of demonstrating the power of the language.
Also strange: allTrue and andTrue are (nearly) the same.
Good point, I turned that into a suggestion.
When introducing MultiAnd and MultiOr, I would also have expected a MultiNand, a MultiNor and a MultiXor. The latter should be based on oneTrue, and yes, the name MultiXor might be a bit controversial, but then OneTrue could be a less controversial name. (For completeness, one could also imagine having an OddTrue corresponding to the alternative definition of variadic exclusive disjunction.)
Also strange: allTrue and andTrue are (nearly) the same.
The normal would be to have allTrue(arr) be min(arr). But for some reason it wasn't. It's actually allTrueAndArrayNotEmpty(arr)... So there is a second function there. It's really confusing :)
Maybe because OM has troubles with vectorized function calls: see Modelica.Electrical.PolyPkase.Basic.{Star, Delta} and some more.
I don't see any vectorized calls in those. Also, reductions are not vectorized calls. min(arr) is not treated as a reduction in OpenModelica (it simply has its own implementation). Vectorized calls in OpenModelica are transformed into reduction expressions: f(arr) = {f(i) for i in arr}.
@HansOlsson don't forget the case when you want to connect more than one vector. I feel somehow uncomfortabel with "solve that with the GUI". Any sound solution?
@henrikt-ma I have to admit I was too busy to consider Nand, Nor, and Xor. And yes you are right, MultiXor is somehow confusing. How would you define it? And we shouldn't forget MultiNot.
@henrikt-ma I have to admit I was too busy to consider Nand, Nor, and Xor. And yes you are right, MultiXor is somehow confusing. How would you define it? And we shouldn't forget MultiNot.
I think we shouldn't add MultiXor yet because there are multiple possibilities (parity seems more common) and we don't have users demanding it yet.
I don't see a need for MultiNot - the normal Not work, and if you want to negate a vector you just make a vector of Nots
@henrikt-ma I have to admit I was too busy to consider Nand, Nor, and Xor. And yes you are right, MultiXor is somehow confusing. How would you define it?
For me, defining it in terms of oneTrue would be the natural choice, but because of the risk of confusion, it might be better to instead make two variants (neither of them called MultiXor): OneTrue and OddTrue
And we shouldn't forget MultiNot.
Yes, let's forget MultiNot.
Regarding multi-xor: https://electronics.stackexchange.com/questions/93713/how-is-an-xor-with-more-than-2-inputs-supposed-to-work But as stated before I don't think we should add it until needed.
@HansOlsson you're right, MultiNot is not necessary. And I'd avoid MultiXor - for me it's extermely confusing ;-) Ok we should add MultiNand and MulitNor after clarifying the input (vector of automaticSizing).
don't forget the case when you want to connect more than one vector.
@AHaumer Would in that case Modelica.Blocks.Routing.Multiplex2 work?
@tobolar I'll try that - I think that'll work, you're right! Not it doesn't work since we don't have a BooleanMulitplex2 ... And no, I'm not going to implement the BooleanMultiplex{2,3,4,...}
@HansOlsson don't forget the case when you want to connect more than one vector. I feel somehow uncomfortabel with "solve that with the GUI". Any sound solution?
To me there are two cases, and I see neither as a blocker: either you write textually and then connectorSizing is a non-issue, or you use the GUI and then it's a matter of improving the GUIs to handle this.
@HansOlsson sigh ... ok let's do it that way you suggest. Although it's not very intuitive for newbies until the GUI is improved.
Regarding multi-xor: https://electronics.stackexchange.com/questions/93713/how-is-an-xor-with-more-than-2-inputs-supposed-to-work But as stated before I don't think we should add it until needed.
Right, all the evidence suggests that at least the name MultiXor should be avoided. Better to have both OneTrue and OddTrue, and in my opinion it would make sense to define them along with MultiAnd and MultiOr so that the MSL provides one canonical block for performing each of the operations.
The documentation needs to be written more carefully, specially due to the weird semantics of
allTrue.
But it has been changed to use andTrue instead as far as I can tell.
The documentation needs to be written more carefully, specially due to the weird semantics of
allTrue.But it has been changed to use andTrue instead as far as I can tell.
No, allTrue is used in MultiAnd.