[xsd-users] Double trouble

[Jeroen N. Witmond [Bahco]]

Greetings, all!

What seems to me to be a nice project is to write a custom integer type
for xsd that is a wrapper for the GNU Multiple Precision Arithmetic
Library[1]. It also has C++ bindings. Unfortunately, it may very well be
years before I get to actually do something about it. :)

Jeroen.

[1] http://gmplib.org/ Related Debian packages are libgmp3c2 and libgmpxx4.

Esben Skovenborg wrote:

> 	Hi Boris,
>
> Thanks for your quick reply.
>
> Although my operator<< hack does solve my immediate problem, I would
> prefer not to have to patch the libxml runtime.
> I think it would be most natural to map xsd:double to C++ double, as in
> your "even better solution", below. What would I need to do?
>
> A related issue is the handling of +/-INF and NaN 'special values' of
> xsd:double elements (http://www.w3.org/TR/xmlschema-2/#double). Will
> these values be supported by the XSD 3.1 serializer? and by the parser?
>
>
> Cheers,
>
> 	Esben
>
>
> -----Original Message-----
> From: Boris Kolpackov [mailto:boris at codesynthesis.com]
> Sent: Wednesday, January 16, 2008 10:01 AM
> To: Esben Skovenborg
> Cc: xsd-users at codesynthesis.com
> Subject: Re: [xsd-users] Double trouble
>
> Hi Esben,
>
> Esben Skovenborg <EsbenS at tcelectronic.com> writes:
>
>> Now, I'm not sure if there's a better way of achieving this, or how to
>
>> have different << operators for the xsd:double and xsd:decimal.
>> Perhaps the long double solution in XSD 2.3 was a pretty good idea
> after all?
>
> The problem with long double is that its support and size varies from
> compiler to compiler and from platform to platform. As a result, several
> compilers issued warning in that regard.
>
> One way to solve the problem you've mentioned above without changing the
> libxsd runtime would be to re-map (using type customization) xsd:double
> to some other type, for example long double and to provide custom
> parsing/serialization code which will use scientific notation.
> I can elaborate on how to do this if you are interested in this
> approach.
>
> An even better solution would be to re-map xsd:decimal to long double
> and somehow change parsing and serialization code for xsd:double to use
> scientific notation. This is not possible right now because the
> parsing/serialization code for fundamental types is always included into
> the generated code even if the type was customized. This can be fixed by
> splitting the parsing/serialization code into separate files for each
> fundamental type and including them individually only when the
> corresponding type is not customized. This way you will be able to
> re-map xsd:double to double and xsd:decimal to long double and to
> provide your own parsing and serialization code for these types. If you
> are interested, we can implement this and build you a pre-release
> binary.
>
> Boris
>
>
>
>