Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NAN, +INF, -INF, MaxDouble, MinDouble, MaxInteger, MinInteger, etc #644

Open
jph-tavella opened this issue Oct 2, 2019 · 7 comments

Comments

@jph-tavella
Copy link

commented Oct 2, 2019

In FMI 2.0, it is stated the following sentence in page 29:
"The special values NAN, +INF, -INF for variables values are not allowed in the FMI xml files."
But there is no more mention about the use of these special values in the API that is generated in the FMU. These special values are in different libraries depending on different systems and from different languages (C++, Java, Python, ...) and the terminology of these symbols is not unified. For instance, NaN symbol is textually expressed in Java as NaN and in C++ as nan. Generally speaking, NaN can be textually expressed in different manners and differently codified between languages too.

So there should be a higher specification in this sense. Here are some questions that we thing should be answered:

  1. Are these special values to be used in the API?
  2. If so, what would be the convention? What is the convention in text? What is the convention in codification?
  3. If so, what happens with other special values like MaxDouble, MinDouble, MaxInteger, MinInteger?
  4. If so, why is not it possible to use them in XML? We think it should be possible to use them also in the XML IN CASE it is to be used in the API.
    Our understanding according to the sentence in page 29 of the previous FMI 2.0 specification is that the spirit of the standard is to avoid the use of the special values. We are on the same line and we think that it should be also mentioned that these symbols should not be used in the API.
@chrbertsch chrbertsch added this to the v3.0 milestone Oct 18, 2019
@chrbertsch

This comment has been minimized.

Copy link
Collaborator

commented Oct 18, 2019

Regular Design Meeting:

Can someone explain where the restriction in FMI 2.0 came from?

"The special values NAN, +INF, -INF for variables values are not allowed in the FMI xml files."

@andreas-junghanns

This comment has been minimized.

Copy link
Contributor

commented Oct 18, 2019

Regular Design Meeting:

Can someone explain where the restriction in FMI 2.0 came from?

"The special values NAN, +INF, -INF for variables values are not allowed in the FMI xml files."

If I remember correctly: Parsing these back into floating point number formats is not standardized. So we cannot assume that a scanf-like parser knows how to translate this into the proper double representation, for instance.

@t-sommer

This comment has been minimized.

Copy link
Collaborator

commented Oct 18, 2019

Parsing these back into floating point number formats is not standardized.

The bit-representation is well defined by IEEE 745. You could e.g. add an if-clause for these 3 special values.

@jph-tavella

This comment has been minimized.

Copy link
Author

commented Oct 19, 2019

To answer Christian, the restriction comes from a comment done on Feb 17th 2013 as a final answer to the issue #115 titled "Clarification of xs:double special values".
This issue is closed and was reported by Andreas Nicolai on Dec 2012.
For me this clarification is helpful but not suffisant.

@andreas-junghanns

This comment has been minimized.

Copy link
Contributor

commented Oct 19, 2019

Even the old ticket/discussion did not report the point of the discussion that decided the issue then:
The textual representations of NAN and +-inf is as varied as C standard libs and other languages. We would have to define exactly which NAN we mean with NAN (IEEE 745 has several NANs and if you really want to represent them all to get the exact same bit representation back we would have to solve quite a hard problem; similar, albeit not as complicated: +-INF.
Second part of the discussion was, that infinity is useless for float computation anyway, MAXDOUBLE and MAXFLOAT in numeric representation is just as good and this we decided not to bother with special non-numeric representations.

@jph-tavella

This comment has been minimized.

Copy link
Author

commented Oct 20, 2019

I agree, the representations of NAN and +-INF are as varied as C standard libs and other languages.
For this reason my proposal is very simple:

  • keep the sentence: "The special values NAN, +INF, -INF for variables values are not allowed in the FMI XML files."
  • add a complementary sentence: "The special values NAN, +INF, -INF for variables values are not allowed in the APIs of FMUs."
    This proposal is simple and in conformance with the spirit of the standard that is to avoid the use of these special values.
@pmai

This comment has been minimized.

Copy link
Collaborator

commented Oct 20, 2019

While there are some pragmatic reasons for not allowing the special values in the XML representation (where they'd only be used as initial default values or values of constants, so that the restriction is not of much relevance), I see no proper reasons for disallowing them in the C API, where they'd (for all practical purposes) be specified very clearly in IEEE754. Should we disallow denormals at the API level as well? Specify our own floating point arithmetic, to supplant IEEE754?

What are we guarding against here? If code dealing with IEEE754 floating point code is written without proper handling of all of IEEE754, then just disallowing special values is not going to make it any better, just differently wrong.

Unless someone can point to specific problems that this would help solve, I do not see the need to change anything here.

PS: I'd strongly urge any implementations to never rely on C stdlib functionality for reading/writing FP numbers, since many of those are completely broken in the IEEE754 sense, and there are completely correct, efficient and user-friendly alternatives around...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.