FHIR Chat · Change to decimal format · implementers

Stream: implementers

Topic: Change to decimal format

Grahame Grieve (Jun 07 2018 at 11:58):

GF#16874 - we are going to allow the exponential form for decimals. For those of you who use the java reference implementation directly (as opposed to using HAPI), I am replacing the gson with my own JSON parser, since Gson doesn't preserve the number presentation properly in the corner cases. @James Agnew you will need to pay careful attention to this in HAPI)

Grahame Grieve (Jun 07 2018 at 20:22):

@James Agnew I am also making a change to DecimalType:

    protected String encode(BigDecimal theValue) {
        return getValue().toString();
    }

Grahame Grieve (Jun 07 2018 at 20:22):

instead of

    protected String encode(BigDecimal theValue) {
        return getValue().toPlainString();
    }

Grahame Grieve (Jun 08 2018 at 00:46):

ok I have committed the changes. @James Agnew @Brian Postlethwaite @Ewout Kramer @Pascal Pfiffner @Eric Haas @nicola (RIO/SS) + anyone else maintaining reference implementations etc, I found this a fairly long piece of string. It's fairly simple in concept:

decimal now allows exponential form as well as normal form e.g. 1.023e+3 is now valid where it wasn't

But it has a long tail:

• this will also apply to searching as well (e.g. search parameters that are numbers)
• the scale allowed is that allowed in the xsd schema for double. This is very large...
• special values like NaN and +INF and -INF are not allowed (no json form, not request, we have different ways of handling these)
• we still say that the presentation form must be maintained so e.g. 1.023e+3 should not be replaced by 1023. I had to do quite some work in the infrastructure to get this right. I think that reference implementations should get this right
• the schema type for decimal has changed to a union of decimal and double - this might be problematic for xml generators
• there's an example observation (observation-decimal.xml) that explores some of these issues. It's intended to support round -trip testing

Grahame Grieve (Jun 08 2018 at 04:27):

searching those ridiculous numbers in observation-decimal is fun. For me, once the number gets into imaginary number status (> 1e20 or closer to 0 than 1e-30) then I mash them all together into a special value and everything matches everything. I don't think we should make hard rules about functional behaviour at these limits

Grahame Grieve (Jun 08 2018 at 04:29):

btw, both those numbers are configurable; it people start challenging those numbers, I'll up them, and all that will happen is my database indexes will get bigger...

Richard Townley-O'Neill (Jun 11 2018 at 06:29):

Do you intend to menion those limits in the conformance statement?

Grahame Grieve (Jun 11 2018 at 07:42):

no

Ewout Kramer (Jun 12 2018 at 14:04):

"we still say that the presentation form must be maintained so e.g. 1.023e+3 should not be replaced by 1023. I had to do quite some work in the infrastructure to get this right. I think that reference implementations should get this right"

Mmmm...I have to check whether I can make the .NET Json parser do that.

Ewout Kramer (Jun 12 2018 at 14:07):

That seems to be doable. ok.

Last updated: Apr 12 2022 at 19:14 UTC