STEP Exponential Number format

Developers Serializations
1

Does STEP serialization support numbers formated to an exponential format (eg -1E-04 )?
I see several toolkits writing this, but when validating on the buildingSMART website an error is suggested when this is used. ie
#1739= IFCPOLYNOMIALCURVE(#219,(0.0,1.0),(0.0,0.0,-1E-04),$);

Thanks,

Jon

2

What’s the error?

3

Nominates a syntax error :

On line 1750 column 53:
Unexpected __anon_3 (‘E’)
Expecting one of COMMA RPAR
01750 | #1739= IFCPOLYNOMIALCURVE(#219,(0.0,1.0),(0.0,0.0,-1E-04),$);

5

This is one of those things where the express grammar deviates from conventional number formatting. (So you can’t rely on your normal language number formatting routine to write reals to ifc.)

The definition is

REAL              = [ SIGN ] DIGIT { DIGIT } "." { DIGIT }
                    [ "E" [ SIGN ] DIGIT { DIGIT } ] .

This means the dot/period is manditory. This applies regardless of whether an exponent notation is used. An integer literal is not a valid representation for a real (but that would trigger a schema error, not a syntax error).

-1E-04 invalid
-1.E-04 valid

1 Like
6

Thanks Thomas, that’s very helpful.

8

@aothms, @Evandro is that in the IFC html documentation? If so, where? If not, shouldn’t it be and where?

9

Occasionally there are questions like this that are really about the 10303-21. (We had a similar question some month ago about the encoding of boolean values in 10303-21.) I don’t know what’s the proper way to, at the same time: provide a comprehensive specification for ifc + don’t violate iso copyrights + don’t spend a lot of time editing specs already defined elsewhere.

10

Purely as an editorial comment, it seems odd that was have an open standard that is based on a definition that is behind a paywall. Not sure what to do about that, but that does seem an implementation issue.

1 Like
11

a REAL in EXPRESS has to have a “.”, independed of being a “normal” or “exponential” notation. So to expand the example from Thomas K.

-1E-04 invalid
-1.E-04 valid
-1 invalid
-1. valid
-1.0 valid

@angel.velez - yes, it is an annoyance that ISO 10303-11 / 10303-21 is copyright by ISO and only available by purchase - but it is out of our control.

12

@TLiebich in light of the copyright issues, would it still be ok for bSI to include the REAL descriptions/examples in the IFC documentation? IS there someone on the ISO side you could ask for clarification? It’s kinda tricky because IFC is a direct derivative of STEP.

It may not just be this case, either. Are there other instances where the documentation can directly reflect needed descriptions/examples of such basic/core concepts from the STEP docs in the IFC docs to better enable understanding and execution?

I’m not suggesting copy/paste of everything, just some of the aspects needing clarification like how real numbers can/should be encoded.