Subject: [netmod] canonical form of floats

From: Martin Bjorklund <[email-masked]>
Date: Tue, 30 Dec 2008 14:39:06 +0100 (CET)

Hi,

There's an open issue in -02 about the canonical form of floats.

My preference has been to follow what XSD does, but when I looked at
what they do, it turns out that it's not compatible with the normal C
fprintf() function.  When I then looked at how libxml2 handles this,
it turns out that their function xmlSchemaGetCanonValue() doesn't
generate conformant strings - it uses snprintf().

Since we state that servers MUST send data in the canonical form, this
has some impact on implementations.

An alternative could be to try to standardize what printf() does.

Comments?

/martin
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Tue, 30 Dec 2008 08:41:35 -0800

> An alternative could be to try to standardize what printf() does.

float32:  sprintf(buff, "%f", num.f);

float64: sprintf(buff, "%lf", num.d);

That's from my code. If sprintf does the wrong thing,
the chance I will re-write sprintf myself just to comply
with YANG are about 1 in a billion.  Your odds may vary.

I have an open bug to figure out why sprintf is
generating extra trailing zeros, like 1.3 --> 1.300000
for float and double.  All FP numbers seem
to be printed with at least 6 digits of precision.
Is this expected behavior or not?

Standardizing what printf does is fine,
but it does different things depending on how it is called.
Let's pick some standard psuedo-code instead of
mandating custom software nobody will write.

> /martin

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 30 Dec 2008 09:28:07 -0800

> An alternative could be to try to standardize what printf() does.

See section 12.12.5, para 4 of the glibc manual:

http://www.gnu.org/software/libc/manual/html_node/Floating_002dPoint-Conversions.html#Floating_002dPoint-Conversions

It seems I should be using the '%a' or '%A' conversion,
not the '%f' conversion, which is fixed point.

The '%a' format is complicated, but here is the key sentence:

    The `%a' and `%A' conversions are meant for representing floating-point
    numbers exactly in textual form so that they can be exchanged as texts
    between different programs and/or machines.

Great!  But the very next sentence:

    The numbers are represented is the form [-]0xh.hhhp[+|-]dd.

That is not IEEE754 format of course.
XPath parsers will not accept the "+/- exponent" part,
and will (incorrectly) accept an AdditiveExpr [rule 25] instead.

Since that won't work, even though it exactly meets
the real needs of the NETCONF community, setting
the precision manually for the %f option seems
the obvious next choice. The values to set manually
are not so obvious.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Dec 2008 18:34:49 +0100

> float64: sprintf(buff, "%lf", num.d);

[...]

> Is this expected behavior or not?

This is consistent with my manual page:

  f   The argument is printed in the style [-]ddd.ddd where the
      number of d's after the decimal point is equal to the preci-
      sion specification for the argument.  If the precision is
      missing, 6 digits are given; if the precision is explicitly
      0, no digits and no decimal point are printed.

And this is consistent with C99 says, which should be the definitive
reference for this.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: "tom.petch" <[email-masked]>
Date: Wed, 31 Dec 2008 11:43:44 +0100

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "Martin Bjorklund" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, December 30, 2008 6:28 PM
Subject: Re: [netmod] canonical form of floats

> See section 12.12.5, para 4 of the glibc manual:
http://www.gnu.org/software/libc/manual/html_node/Floating_002dPoint-Conversions
.html#Floating_002dPoint-Conversions
> and will (incorrectly) accept an AdditiveExpr [rule 25] instead.

XPath 1.0 only allows integer and decimal, no float (nor octal, nor
hexadecimal:-)

Tom Petch