FYI, the long term fix is probably a change to Daffodil to make this
configurable--I don't think this is the first time this has come up.

I've created DAFFODIL-2546 to track this feature.

https://issues.apache.org/jira/browse/DAFFODIL-2546


On 7/19/21 2:23 PM, Marshall Miller wrote:
> 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