Subject: [Megaco] RE: floating point numbers; RE: H.248.1v4 Living List

From: "Schwarz Albrecht" <[email-masked]>
Date: Thu, 5 Jul 2007 14:39:46 +0200

[move this discussion to the list]

Thanks Elad for categorization!
I think that this structure is very helpful as decision tree.

I'm personally don't care about readability, which shouldn't be at all a requirement for protocols for machine-to-machine communication in my opionion.
[Actually I would support the requirement § 6.1 from C-130 concerning message encoding for "H.325" ..., but this is not (yet?) H.248 related.]
That's why I'm tending to (1) ...

Perhaps we could resume this discussion at next Q.3/16 meeting.

-Albrecht

-----Original Message-----
From: Elad Chomsky [mailto:[email-masked]] 
Sent: Mittwoch, 4. Juli 2007 18:55
To: Schwarz Albrecht; Christian Groves
Cc: Arturo Martin De Nicolas (AC/EDD); Miri Epstein; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: floating point numbers;RE: H.248.1v4 Living List

Hi Albrecht,

If I understand you correctly, at the highest level we have two options for text-encoding floats:

1/ Use OctetString to directly represent the number in the IEEE 754 format.
This encoding is fast, compact and accurate. However it is not very readable.

2/ Encode the floating-point number in a readable fashion. This encoding is slower and less compact.

If we go with option (2), we have further two sub-options:

2.a/ Encode the number using the standard decimal representation (e.g.
+3.739E-19 - similar to the output of the %E printf flag).
This encoding is the most common one (for example, in the RFC reference you provided). However it is the slowest and least compact. It also enables encoding values with no equivalent IEEE 754 float (e.g. 0.1).

2.b/ Encode the number using some readable representation, more aligned with the binary nature of IEEE 754. My mapping suggestion was such a representation (though, in retrospect, not a very good one).

Thinking about it now, it seems that (2.b) is probably not that more readable than (1). So we should probably choose between (1) and (2.a) only.

Thanks,
Elad

-----Original Message-----
From: Schwarz Albrecht [mailto:[email-masked]]
Sent: Wednesday, July 04, 2007 6:49 PM
To: Elad Chomsky; Christian Groves
Cc: Arturo Martin De Nicolas (AC/EDD); Miri Epstein; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: floating point numbers;RE: H.248.1v4 Living List

Hi Elad,

try to summarize:

The two new proposed H.248 data types should be encoded according IEEE 754, i.e. as 32 or 64 bit values respectively. Right? Because the whole idea is
a) to minimize conversion effort between other instances (e.g. served application of H.248) using that values, and
b) to avoid loss of accuracy (due to different float formats, or a conversion between float and fix-frac) apart from
c) the requirement for a native data type for application requiring floating-point numbers.

Now, I may agree that the textual representation must not be identical to the machine format, thus I may follow your "mapping" concept. Guess that you are using at least two mapping aspects:

1) denormalization
2) decimal representation of <frac> and <exp> another one might be:
3) basis 10 instead 2
 
May you agree, or do you want to consider e.g. also a decimal-based encoding of <frac> and/or <exp>?

Regards,
Albrecht

PS
Concerning protocol syntax for H.248 text encoding, we may use this
reference:
Appendix B/RFC 3780 provides ABNF grammar rules for IEEE 754 floating numbers See also D-227.

-----Original Message-----
From: Elad Chomsky [mailto:[email-masked]]
Sent: Montag, 2. Juli 2007 15:46
To: Schwarz Albrecht; Christian Groves
Cc: Arturo Martin De Nicolas (AC/EDD); Miri Epstein; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: floating point numbers;RE: H.248.1v4 Living List

Hi Albrecht,

I actually thought my example maps to IEEE 754 in a simple way. My knowledge of IEEE 754 is rather limited (based on Wikipedia:
http://en.wikipedia.org/wiki/IEEE_754). But this is what I understand:

A Float32 normalized number is of the form:
	+/- 1.<frac> * 2^<exp>
Where <frac> is a 23-bit binary fraction and <exp> lies between -126 &
+127. Such a number can easily be converted to a printable notation,
using a decimal fraction. For example, something like:
	-1.125*2^97

There are however drawbacks to using decimal fractions. One is that binary fractions are quite cumbersome to express as decimal fractions (the decimal representation requires the same number of digits as the binary). For example, the binary fraction:
	1.10000000000000000000001 (binary)
Translates to:
	1.50000011920928955078125 (decimal)
Another is that decimal fractions can represent numbers that have no finite binary representation (e.g. 0.1).

So we can instead multiply 1.<frac> by 2^23 and deduct 23 from <exp>.
The above fraction then becomes:
	4194305*2^-23
which is more compact.

Thanks,
Elad

-----Original Message-----
From: Schwarz Albrecht [mailto:[email-masked]]
Sent: Monday, July 02, 2007 12:18 PM
To: Christian Groves; Elad Chomsky
Cc: Arturo Martin De Nicolas (AC/EDD); Miri Epstein; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: floating point numbers;RE: H.248.1v4 Living List

Elad,
your example is not compliant against IEEE 754 formats. Right?

The real benefit of IEEE 754 floating point numbers is their direct support by CPU HW, correspondent data types in programming languages and compilers. This format should minimize the effort for conversions between different formats.
Thus, I wouldn't start the definition of generic floating point formats.

Do you see a specific requirement, which couldn't be covered by IEEE 754?

-Albrecht 

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Montag, 2. Juli 2007 09:15
To: Elad Chomsky
Cc: Arturo Martin De Nicolas (AC/EDD); Schwarz Albrecht; Miri Epstein; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: H.248.1v4 Living List

Hello Elad,

I've mention this possibility in the editor's note and have invited further contribution on the issue.

Regards, Christian

Elad Chomsky wrote:
> Hi Christian,
>
> In the possible text encoding of the Float parameters, I suggest to 
> add some sort of exponential notation.
> Such a notation could be as explicit as: +2097*2^-103. It has the 
> advantage of being readable, compact & accurate.
>
> Thanks,
> Elad
>
> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Sunday, July 01, 2007 4:48 PM
> To: Elad Chomsky; Arturo Martin De Nicolas (AC/EDD); Schwarz Albrecht;

> Miri Epstein
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: H.248.1v4 Living List
>
> Hello all,
>
> Please find attached the H.248.1v4 Living list. Any comments before I 
> upload it?
>
>
> Regards, Christian
>
>
>   

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco