Testcase "[PASS] Integer values are checked using type casting 2 & 3/4"

[hesrah]

[PASS] Integer values are checked using type casting 2/4 [PASS] Integer values are checked using type casting 3/4 I prefer this to be FAIL. Type casting should only handle data types, not data content. So 42.0 is too "big" for an integer like 42.3 because it is a REAL and cannot be converted (implicitly) to an integer - regardless of the numerical/nominal situation. It should FAIL like [FAIL] Integer values are checked using type casting 4/4.

NB: (Nearly) the same for attribute testcases: [PASS] Integers follow the same rules as numbers 2/2 - I prefer FAIL, but in this case it's not so clear because there is no explicit type information.

[Moult]

@hesrah I think the intention here is that IDS is trying to cater more for non-computer geeks, and to them 42.0 == 42.

For attributes the IFC schema defines the type so there is no need for IDS to define the type.

I'd prefer to keep the current behaviour, but let's hear more feedback from others so we can collectively decide :)

[aothms]

@hesrah note that if you really want an IfcInteger or an IfcReal you can constrain the IFC type using the measure attribute.

For users I definitely would expect an ifc value of 42.0 to match an ids value of 42 if unconstrained by type.

The reverse is a bit more questionable maybe, but I think the symmetry makes sense.

Maybe we should add a test case [FAIL] IDS: IfcReal(42.0), IFC: IfcInteger(42) if it doesn't exist yet.

[hesrah]

Hm, I understand, but I'm not that happy with it. Maybe I'm too messed up with programming ... If 42. == 42.0 == INTEGER(42), so I would expect 42.3 == INTEGER(42) too, because I can convert real to integer then INTEGER(42) is 41.500000 ... 42.4999999. I understand the user (data content) perspective but wouldn't share this in the IDS file.

[aothms]

so I would expect 42.3 == INTEGER(42) too

I also thought of that bit. Or, given the other topic on rounding, howbout 42.00001?

We'd probably at the very least have to apply the same tolerance trick: 42.0 * (1. - 1.e-6) < 42 < 42.0 * (1. + 1.e-6)

But I agree @hesrah there is something a bit inelegant here.

But also, I'd say that actual value constraints are already a bit rare in IDS use cases, float value constraints very rare.

[hesrah]

I'm asking myself is this even a question for IDS or is it out of IDS scope? Aren't rounding problems for numeric data types a question of implementations and not a question of the standard (if it isn't a standard about rounding problems for numeric data types ;-) )? Does IDS really have to specify something about this?

[aothms]

I don't think we can leave this to the individual implementations. I think we agreed we want uniform behaviour among all applications. It's true though that XML/XSD is curiously silent about these kind of things, but I reckon it's because it's more a data modelling standard, we're in a different game and I think the "truthiness" of a facet should really be unambiguously defined.

[hesrah]

Ok, I agree. But how can we define that? I confess I don't have a good suggestion. And the testcase example is not entirely satisfactory and also not very conclusive. As discussed above. Any suggestions?

In #78 there is the idea with a tolerance element that could perhaps be used here as well. But it's also kind of ponderous.

[pasi-paasiala]

@pjanck suggested that this test case should fail the auditing. The test case should be removed or moved to a different folder, e.g. auditing.