Thanks for your help Steve and Mike.  This is great info.

On 7/19/21, 2:20 PM, "Steve Lawrence" <[email protected]> wrote:

    CAUTION: This email originated from outside of the organization. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe.


    According to the JavaDocs, both Float.toString [1] and Double.toString
    [2] use the same logic for determining when to switch to what it calls
    "computerized scientific notation". Any float or double with magnitude
    less than 10^-3 or greater than 10^7 uses scientific notation. So the
    floatingPointValue/decimalValue trick likely won't make a difference.

    [1]
    
https://docs.oracle.com/javase/7/docs/api/java/lang/Float.html#toString(float)
    [2]
    
https://docs.oracle.com/javase/7/docs/api/java/lang/Double.html#toString%28double%29

    On 7/19/21 2:02 PM, Steve Lawrence wrote:
    > Note that we just use Float/Double toString, so it will only switch to
    > scientific notation when Java thinks it makes sense. I don't know
    > exactly when that is, and I'm pretty sure it's not configurable. So if
    > the double trick still switches to sceitnfic notation, there's not much
    > that can be done with only schema changes.
    >
    > Note that this toString logic happens in the dataValueAsString function
    > [1], which is what all the built-in InfosetOutputters use, so there's no
    > way around this if using one of those.
    >
    > But that means another option would be to create and use a custom
    > InfosetOutputter, which could be a copy of whatever InfosetOutputter
    > you're already using except instead of using dataValueAsString, you
    > could implement some other logic that won't use scientific notation.
    >
    > Or another alternative, though not that great, is if your data is
    > already text you could just model your numbers as an xs:string, though
    > you lose of validations, handling of group separators, etc., so this
    > probably isn't ideal.
    >
    > Ideally, we probably want to add a tunable or some other configuration
    > so that users could decide the maximum number of decimal places allowed
    > in the infoset for doubles/flats before switching to scientific
    > notation, or just disable it altogether.
    >
    > [1]
    > 
https://github.com/apache/daffodil/blob/master/daffodil-runtime1/src/main/scala/org/apache/daffodil/infoset/InfosetImpl.scala#L1345
    >
    >
    >
    > On 7/19/21 1:49 PM, Beckerle, Mike wrote:
    >> DFDL will only use scientific notation for types xs:float and xs:double.
    >>
    >> Perhaps this will work: If you create an additional element of type 
xs:decimal,
    >> that gets its value from the floating-point number using 
dfdl:inputValueCalc,
    >> then that decimal number will not show up in the infoset with scientific 
notation.
    >>
    >> Like this:
    >>
    >> <xs:element name="floatingPointValue" type="xs:double"
    >>        dfdl:outputValueCalc='{ xs:double(../decimalValue) }'/>
    >> <xs:element name="decimalValue" type="xs:decimal"
    >>        dfdl:inputValueCalc='{ xs:decimal(../floatingPointValue) }' />
    >>
    >> If that works and you don't want the floating point in the infoset at 
all, it
    >> can be tucked away in a DFDL hidden group.
    >>
    >>
    >>
    >>
    >>
    >>
    >>
    >> 
--------------------------------------------------------------------------------
    >> *From:* Marshall Miller <[email protected]>
    >> *Sent:* Monday, July 19, 2021 1:29 PM
    >> *To:* [email protected] <[email protected]>
    >> *Subject:* Scientific notation
    >>
    >> Hello,
    >>
    >> We recently came across a problem with a library that does not support 
the use
    >> of numbers that are represented in scientific notation.  We have several 
options
    >> to work around the problem but the easiest solution would be to ensure 
that
    >> parsed datasets do not include scientific notation.  Is there a way to 
prevent
    >> Daffodil from representing numbers with scientific notation?
    >>
    >> Marshall Miller
    >>
    >


Reply via email to