[xsd-users] no reaction on XSD_CXX_TREE_DECIMAL_PRECISION

[Rizzuto, Raymond]

Boris,

Thanks for the suggestions.  Let me see if I understand.

Let's say I have a message with two instances of the type (for example, a type of temperature, one instance for internal, one for external).   Each of the two temperatures might have different precision, maybe based on the accuracy of the respective temperature sensor.  If I understand you, my overridden type (for temperature) would need an accessor function to allow setting the precision, and the serialization logic would use the precision attribute.

I asked the author of the schema about specifying fractionDigits in the schema, but he was not in favor of that idea.  I know I could create a modified version of his schema, but that would be a maintenance nightmare since the schema has been in flux.  The flux has been bad enough.

Ray

________________________________________
From: Boris Kolpackov [boris at codesynthesis.com]
Sent: Monday, September 15, 2008 3:21 AM
To: Rizzuto, Raymond
Cc: Gennady Khokhorin; xsd-users at codesynthesis.com
Subject: Re: [xsd-users] no reaction on XSD_CXX_TREE_DECIMAL_PRECISION

Hi Ray,

Rizzuto, Raymond <Raymond.Rizzuto at sig.com> writes:

> One thing, however, that I don't like about the macros is that they
> apply globally.  I would really like to be able to specify the
> precision dynamically based on the input precision I read in.
> I.e., if I read in 25.99 as a string, and note that there are
> 2 digits of precision, I would want to somehow specify that
> detail for the XML double that I create from it.

You can do this with type customization. That is, you would define
a type in XML Schema that derives from the built-in double type.
You can then customize it in the generated code and override it's
parsing and serialization code to implement this logic (you will
also probably want to allow the user to specify precision manually
in case an instance of this type is not read from XML).

In case the precision for your type is fixed then there is even an
easier method which is supported in 3.2.0. You can use the
fractionDigits XML Schema facet which will then be honored during
serialization:

  <simpleType name="Timestamp">
    <restriction base="double">
      <fractionDigits value="6"/>
    </restriction>
  </simpleType>


> Also, I recall seeing an earlier posting where a small float,
> say 0.357E-30 is truncated to 0 on output.

This will happen if the format is set to fixed and the precision
is not enough to represent this value. In 3.2.0 float and double
are saved in the automatic mode (fixed or scientific representation
if automatically selected depending on which one is more efficient)
so this rounding won't happen. The decimal type, on the other hand,
is always in the fixed format per the spec.


> I think the issue here is the way precision is defined. I would prefer
> somethin more akin to the engineering definition of significant digits.
> I.e. 0.357E-30 has 3 significant digits. If I request the precision to
> be 2 digits, then I'd expect 0.36E-30 on output.

That's exactly what you will get if you set the precision to 2:

#include <iostream>

using namespace std;

int main ()
{
  double d = 0.357E-30;
  cerr << d << endl;
  cerr.precision (2);
  cerr << d << endl;
}

Output:

3.57e-31
3.6e-31

Boris

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.