where-rule may return indeterminate value for a valid model
I-Sokolov opened this issue · 10 comments
Some of functions can return indeterminate (?) value explicitly
- IfcCorrectLocalPlacement
- IfcCrossProduct
- IfcCurveDim
- IfcFirstProjAxis
- IfcListToArray
- IfcMakeArrayOfArray
- ...
At least one of them is where rule.
Even ISO allows this, the semantic for where rules is not clear "it shall be neither violated nor asserted when the expression evaluates to a indeterminate".
Does it mean model valid or not?
I am tending to think "neither violated nor asserted" includes "not asserted" and model is not valid, in other words - invalid:)
For example, it can happen when an expected value missed.
However, IfcCorrectLocalPlacement explicitly returns (?) in valid cases.
I'm suggesting
- Assume where rule that returns indeterminate fails (in general)
- Rework IfcCorrentLocalPlacement (related issue #615 )
- Inspect that other rules does not return indeterminate for valid cases.
Even ISO allows this, the semantic for where rules is not clear "it shall be neither violated nor asserted when the expression evaluates to a indeterminate".
Does it mean model valid or not?
I also had this question for the implementation in the validation service and we never discussed this explicitly so it's good that you bring this up.
Assume where rule that returns indeterminate fails (in general)
As you say given some of the current rules, most notably e.g IfcCorrectLocalPlacement, it seems to me that we cannot say this. indeterminate is returned for e.g a grid placement automatically. So I made the choice that indeterminate means "not invalid" .
We can of course review this and try to fix IFC4.4. If you're interested in contributing to your suggested "point 3" I'm sure we can make great steps towards this. In general it would be good if we have some sort of static code analysis for our where rules and functions.
indeterminate is returned for e.g a grid placement automatically. So I made the choice that indeterminate means "not invalid" .
However, using grids is absolutely valid.
And grids are not common case but every linear placement will be invalidated, so the rule makes impossible to use any alignment.
Maybe where rules should follow "presumption of innocence"?
If it can not say something is wrong, do not blame!
In general it would be good if we have some sort of static code analysis for our where rules and functions
After my experiences with EXPRESS functions my feelings this is very obsolete path of the EXPRESS ISO standard.
This is not reasonable to create full infrastructure for this very limited usage language.
For me it is more promising to rewrite all the rules in any commonly used language, for example in C#/++.
Even C would be big step forward and we already have SDAI standard to do it.
I have another similar example.
We got a dataset with IFCDIRECTION(0.,0.,0.);. Of course it fails MagnitudeGreaterZero. But AxisToRefDirPosition on the IfcAxis2Placement3D calls IfcCrossProduct which calls IfcNormalize that returns ? on that kind of an IfcDirection. The IfcCrossProduct then constructs a new IfcDirection:
with an indeterminate values which is not allowed.
IMO, IfcNormalise should not return '?' for input 0,0,0.
EDIT: Retracting the proposal. Forgot that we are not just calculating the length but also normalising, dividing by the calculated length. The initialization is still a problem though, what is IfcDirection([?.?,?])? Another '?' or IfcDirection.DirectionRatios=(?,?,?)?
For me it is more promising to rewrite all the rules in any commonly used language, for example in C#/++.
I already generate all EXPRESS functions in c# for Reactor. So the functions are available in c#.
After my experiences with EXPRESS functions my feelings this is very obsolete path of the EXPRESS ISO standard.
Agreed.
For me it is more promising to rewrite all the rules in any commonly used language, for example in C#/++.
Yes, that's also what I consider as the most likely way to have static analysis.
The initialization is still a problem though, what is IfcDirection([?.?,?])? Another '?' or IfcDirection.DirectionRatios=(?,?,?)?
But indeed, the exact semantics of the handling of inderminate are unlikely to be found in any other host language.
But maybe, given the title of this issue, that should also be the aim. Eliminate usage of indeterminate in our rules so that we can confidently map our imperative rules to other languages with exact matching semantics and at the same time use a mapping to a more conventional language to statically test for indeterminate usage.
If I get fully academic, instead of C# we could also look into something like the research brother of F# called https://www.fstar-lang.org/ We can do proofs, but also compile the code to C / C# / WASM. It seems that would give us some sort of migration path for IFC5 as well (whatever that may be).
I am not so sure about functions in EXPRESS being an obsolete part. I grew fond of them. Especially, if we imagine the intent of schema extensions which are so feared in the bSI community (for whatever reason). It makes the schema extremely flexible and usable in many different settings. Take the resource layer, the kernel and product extension, a couple of the domain schemas and extend them to IfcArchitecturalDomainUS/Sweeden/ etc. 😄
It is tedious to handle indeterminate, but mostly manageable. Especially on value types 👀 I still do not understand what it is supposed to mean. Probably because it can mean many things?
The F#/F* does have a flare and elegance to it. For (but not only) documentation purposes it looks amazing. I would not see it as a replacement for EXPRESS though. Definitely vote for keeping EXPRESS. Once a / any language (not just computer) is learned, it gives a different perspective to the thought process and ideas can be considered that would otherwise never make it through.
I am not so sure about functions in EXPRESS being an obsolete part
Not functions itself but EXPRESS functions language.
Even opposite, commonly known language with rich ecosystem I believe will make usage of function wider, easier and much more effective.
It includes not only constrains but also features like derived values and seamless MVDs implementations.
C# is a good choice except (as I know) there is no ISO standard and poor cross-platform ability.
But possible your compiler can be relatively easy changed to same family language like C++ or Java.
I was not viewing EXPRESS from the perspective of language features but mostly as an agnostic representation i. e. documentation purposes. Of course, I agree there are better languages, but as I said, I was not focusing on that. I think the documentation part is seriously underrated. Before we start talking about how readable EXPRESS is and thereby suitable for documentation, I am not saying it is! 😃 But it is there. The WRs are typically quite easy to understand.
c# ISO: https://www.iso.org/standard/75178.html. Cross platform I can confirm that with .NET I was able to use anything (apart from the WinForms and WPF libs) on Mac and Linux (using it for development as a matter of fact). Just addressing concerns.
But I still think something like F#/* is better from the pure "correctness" of usage point of view. Let alone the coolness factor. It's not like we are the coolest community around and couldn't use an upgrade there.
I think the documentation part is seriously underrated
I agree. They're great for documenting intention.
The WRs are typically quite easy to understand.
But I think you might be overestimating the ability of the general IFC audience to understand these rules. In general, people are lazy and and quick to dismiss something they are not familiar with. But it doesn't apply to everybody!
I am not so sure about functions in EXPRESS being an obsolete part. I grew fond of them. Especially, if we imagine the intent of schema extensions which are so feared in the bSI community (for whatever reason)
I don't know. Maybe I'm misunderstanding you, but you hear similar arguments in the semantic web world, where people claim that reasoning engines somehow allow some sort of interoperability by establishing equivalents. In my view/experience this has never really worked in a more open-ended context. Although I don't have really clear reasons/arguments here.
But I still think something like F#/* is better from the pure "correctness" of usage point of view
Yes ideally we have something more of a rule language and not a general purpose imperative language, but then again the procedural part of express is also quite imperative (but at least it wouldn't allow you to open a web request or something or delete your local files).
I was not viewing EXPRESS from the perspective of language features but mostly as an agnostic representation i. e. documentation
Sorry I would disagree. EXPRESS functions are not documentation but code to execute.
Good EXPRESS tool should be able to load new express schema without code modification.
Thus, it should interprète and execute functions for derived values and WR.
For example, good IFC toolkit should proper support sdaiGetAttr for derived attributes.
The WRs are typically quite easy to understand.
I feel myself stupid after reading this-)
Maybe I'm misunderstanding you,
I am trying to summarize my point: EXPRESS functions are very powerful and can be used more widely and effectively but only 3-4 persons know this language, and developing looks like a trip back to 1980x but it should use all contemporary achievements