Subject: [netmod] floating point math

From: Andy Bierman <[email-masked]>
Date: Tue, 25 Nov 2008 19:27:09 -0800

Hi,

I am somewhat surprised that nobody has complained that
must-stmt expression syntax requires agents to support
IEEE 754 floating point numbers for basic math operations,
not just storage and retrieval.

Maybe this is a sign that vendors have really advanced
since floating point numbers were forcefully rejected
by the EOS and SMIng WGs several years ago.

Andy

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 26 Nov 2008 07:25:50 +0100

> by the EOS and SMIng WGs several years ago.

Supporting floating point numbers in a data modeling language does not
imply all data models have to use floating point numbers. I can write
perfect C code that never uses floating point numbers.

What I think has changed is that the old approach of "lets design CLRs
for a data modeling language that help data model writers to not shoot
themself into the foot" is not followed anymore and this is goodness
because many of these CLRs did fire back badly. Data model writers
should enjoy the freedom to decide whether they need floats or not.

/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: Andy Bierman <[email-masked]>
Date: Tue, 25 Nov 2008 23:01:42 -0800

> should enjoy the freedom to decide whether they need floats or not.

That would only work for a vendor if they never need to implement
a standard DM with float32 or float64 objects.

But actually, all numbers in XPath expressions are floating point,
and functions like round, floor, ceiling, and especially the 'div'
operator are mandatory to support in the agent.  The vendor
would need to avoid any data model with a must-stmt or when-stmt
that used any of these constructs.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 26 Nov 2008 08:14:47 +0100 (CET)

> not just storage and retrieval.

We should point out that this requirement comes from XPath 1.0, and
our design decision to use XPath 1.0 as-is.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 26 Nov 2008 08:47:21 +0100

> that used any of these constructs.

If the data model designer uses these functions and in addition I
think Yang says that the implementation of the condition checks does
not necessarily require to use a full XPath implementation on the
device as long as the device does the right thing. In other words, I
do not think that floating point functions are mandatory to implement
as you suggest above.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 26 Nov 2008 08:57:10 +0100 (CET)

> do not think that floating point functions are mandatory to implement

It does not require an XPath implementation, but if the must
expression is: "round(.) = '1'" the device must implement the round()
function (somehow).

But as you stated, YANG provides the means for writing such data
models.  It does not mean that modellers MUST use everything
available, and it definitely does not mean that devices that can't do
floating point arithmetic will implement data models that require
them to do just that.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Nov 2008 07:03:32 -0800

> expression is: "round(.) = '1'" the device must implement the round()

There really isn't any way to fake the 'div' operator.

Perhaps a warning to DM designers about the
use of floating point in XPath would help.
Don't use it unless it is the 'natural' thing to do.
Even so, MIB developers usually use hacks to avoid needing
real FP math in SNMP agents.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 26 Nov 2008 17:53:22 -0500

>expression is: "round(.) = '1'" the device must implement the round()

Sort of, but not really.  If "." is an int, the device-side coder
that implements this can read the YANG, realize that rounding an
int is meaningless and ignore it completely.

There's no requirement that the device implement a generic YANG
modeling engine.  Only that it abide by the rules in the model.

Thanks,
 Phil