Subject: [netmod] Y59 action

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 04 Dec 2014 10:18:10 +0100

Hi,

as per discussion during yesterday's virtual interim, I updated Solution
Y59-01. This is the new text proposed for sec. 6.4 (before subsection
6.4.1):

   Numbers in XPath 1.0 are IEEE 754 double-precision floating-point
   values, see Section 3.5 in [XPATH]. This means that some values of
   uint64, int64 and decimal64 types (Section 9.2 and 9.3) cannot be
   exactly represented in XPath expressions. Therefore, due caution should
   be exercised when using nodes with 64-bit numeric values in XPath
   expressions. In particular, numerical comparisons involving equality
   may yield unexpected results.

   For example, consider the following definition:

     leaf lxiv {
         type decimal64 {
             fraction-digits 18;
         }
         must ". <= 10";
     }

   An instance of the "lxiv" leaf having the value of
   10.0000000000000001 will then successfully pass validation.

Please comment.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Thu, 4 Dec 2014 11:11:10 -0500

I'm assuming the reader's reaction to this will be the same as mine:
it sounds crazy.  I understand the need, but without talking about
type conversion and rounding, it will be confusing.  And talking
about those topics will also be confusing.  Is there a more complete
discussion of this topic we can refer to?

Thanks,
 Phil

Ladislav Lhotka writes:
>_______________________________________________
>netmod mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 04 Dec 2014 17:21:45 +0100 (CET)

> discussion of this topic we can refer to?

How about adding this to the guidelines document instead?

/martin

---

From: Phil Shafer <[email-masked]>
Date: Thu, 4 Dec 2014 11:28:23 -0500

>How about adding this to the guidelines document instead?

Fine w/ me.  It's a stinky, ugly concept, sort of the dirty underbelly
of IEEE math.  I had to explain it to my son a couple weeks ago,
how his AP-Programming task wasn't working right because it turns
out computers don't really like floating point numbers that much.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 4 Dec 2014 17:41:52 +0100

> On 04 Dec 2014, at 17:21, Martin Bjorklund <[email-masked]> wrote:
> 

It is a potential security issue so IMO it needs to be mentioned in the YANG spec. I think that everybody who has ever worked with floats must be familiar with this problem.

Of course, it may be considered a PR problem but I don’t think that papering over it helps.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Dec 2014 16:36:41 +0100

> discussion of this topic we can refer to?

Floating point numbers are a great source of fun. If you really want
to know the details:

  http://dx.doi.org/10.1145%2F1353445.1353446

While uint64, int64 and decimal64 types obviously have issues, there
can also be subtle rounding errors with numbers that look less
suspicious. This one seems to work 'well' with xsltproc...

  http://stackoverflow.com/questions/1845998/sum-diff-problem-bug-in-xslt-1-0

As someone said:

  You'll want to be really careful with equality tests with floats and
  doubles, in whatever language you are in.

Perhaps we should add a reference to this one:

  http://www.xkcd.com/217/

/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/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 8 Dec 2014 17:15:21 +0100

> On 08 Dec 2014, at 16:36, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Right, and for YANG it’s perhaps twice as important because a part of a data tree may be suddenly deleted by the server based on the evaluation of an XPath expression in a “when” statement.

> Perhaps we should add a reference to this one:

:-)))

Lada