[jira] [Closed] (DAFFODIL-2353) long to double function - for preserving binary data floating point precision

["Dave Thompson (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DAFFODIL-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dave Thompson closed DAFFODIL-2353.
-----------------------------------

Verified the specified commit (commit 098bb66fc44da51e7fabbc0eff178e1a7cafc8df) is included in the latest pull from the daffodil repository.

Verified changes identified in commit comment were implemented.

Verified all affected daffodil sub-project sbt test suites execute successfully, including the added tests.

Verified the nightly test schemas compile and save successfully.

Verified the nightly test suite executes successfully.

> long to double function - for preserving binary data floating point precision
> -----------------------------------------------------------------------------
>
>                 Key: DAFFODIL-2353
>                 URL: https://issues.apache.org/jira/browse/DAFFODIL-2353
>             Project: Daffodil
>          Issue Type: Bug
>          Components: Back End
>    Affects Versions: 2.6.0
>            Reporter: Mike Beckerle
>            Assignee: Min Phyo Aung
>            Priority: Major
>              Labels: beginner
>             Fix For: 3.2.0
>
>
>  Conversion to base 10 is required for XML, and that means floating point numbers converted from binary to base 10 are going to lose information sometimes vs. their binary IEEE 754 or other representation.
> But.... We or a user via UDF could provide a conversion function hexBinaryToDouble, then you could get something like this:
> <myValue>
>      <ieeeHex>40FE208000000000</ieeeHex>
>      <value>1.234e5</value>
> </myValue>
> The <value> element is there to exhibit the value in a human-understandable way, but the parsing would actually unparse from the raw ieeeHex element which is a hex dump of the actual value bits.
> On unparsing, if the base 10 value has been modified, and no longer matches the base-10 equivalent of the raw value, then the binary data could be recomputed from the new base 10 value.
> Due to big/little endian issues, we probably want to do this from 64-bit integers, not hexBinary. That way the conversion functions are byte order independent. 
> Note about EXI (DAFFODIL-1959) - if we are converting data from binary to EXI representation or back for unparsing, it would be great if no conversion to base 10 text was required. This raises an issue however, of a different DFDL schema being appropriate when using EXI vs. when using XML text (or any other base-10 text representation). 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)