RE: On the performances of decimal and float encoding conversion

Hello Antoine,

Please see our comments, below...

>We have some concerns about the relative compression and
>encoding/decoding performances of EXI and "standard" binary
>representations for decimal and floating point numbers. While the
>formats currently proposed in EXI seem optimal for compression and
>well-adapted when converting from EXI to string (or decimal)
>representations and back, there is a significant performance penalty
>when converting from EXI to "standard" binary representations used in
>the C language:
>
>- In cases where large integers are represented as an array of native
>ints, the proposed EXI integer representation is easily converted to the
>internal representation. However, when using decimals (with a native
>representation adding a scale factor), the EXI representation must first
>be converted to the decimal representation to reverse the digits before
>being converted to the internal representation. This intermediate
>conversion is expensive.
>- For floating point number, the proposed EXI format must always be
>converted to its decimal representation before being converted to its
>native (often IEEE 754) representation.

There has been a recent posting to the public comments list concerning the performance of EXI and IEEE floating point representations (http://lists.w3.org/Archives/Public/public-exi-comments/2009Oct/0000.html).  We believe this post addresses your comments above, but we wanted to make sure.  Please let us know whether there should be more discussion within this email thread concerning this.

>
>So we join our voice to the existing concerns regarding the EXI
>representation of decimal and floating point numbers. We would prefer to
>at least have an option to support decimals using a scale factor and
>IEEE 754 float representation.

The current spec does provide an option for supporting the IEEE floating point
representation of float numbers as well as the scaled value representation
of decimal numbers. These would be handled using the Datatype Representation
Map feature.

>
>Best regards
>
>Antoine Mensch

Thanks much,

--mike


Mike Cokus
The MITRE Corporation
757-896-8553; 757-826-8316 (fax)
903 Enterprise Parkway, Hampton, VA

Received on Monday, 2 November 2009 15:23:52 UTC