Hi @Chris.Wang

Please use toFloat() instead of toDouble() if you have a mixture of fraction and non-fractional values to decode

((OMMNumeric)data).toFloat();

e.g.

FIELD_ENTRY 3629/LOW_2: ;51.2204
toDouble : 51.220400000000005
toFloat : 51.2204

FIELD_ENTRY 3404/VWAP: ;369 5/8
toDouble : 369.625
toFloat : 369.625

Please note the following comment in the RFA Java Developers Guide

10.3.2.3 OMMNumeric Interface Methods OMM preserves the precision of encoded numeric values. Developers should note that some conversions from OMM numeric types to primitive types (e.g. REAL to Java’s long) may result in a loss of precision; this is an example of a narrowing precision conversion (as defined in The Java™ Language Specification). Also note that because the IEEE Standard for Floating-Point Arithmetic (IEEE 754) (implemented as the float and double types in Java) cannot represent some values exactly, rounding (per the IEEE 754 spec) may occur when converting from the OMM representation of numeric values to other data types manually, or via the provided utility methods.

Hi @Chris.Wang

Can you please confirm which example / application they are using to generate the above output?

First thing to note is that fractional value is most likely as it was contributed / published by the original contributor / publisher of the data.

The previous RFA v5 application is probably just using the TibField class (or other) to convert the underlying fractional value to a decimal floating point value - ignoring any fractional information.

Whereas the RFA v8 application is most likely applying the fractional information when displaying the values.

e.g. If I modify the RFAv8 Java StarterConsumer example with the following changes in the GenericOMMParser.parseData method

 ps.println(";" + data); 
 if (data.getType()== com.reuters.rfa.omm.OMMTypes.REAL)
 {
      ps.println("Double : " + ((OMMNumeric)data).toDouble());
 }

would output something like:

FIELD_ENTRY 21/HST_CLOSE: ;359 2/8
Double : 359.25
FIELD_ENTRY 22/BID: ;364 2/8
Double : 364.25
FIELD_ENTRY 25/ASK: ;364 4/8 
Double : 364.5

The ps.println(";" + data) is using the OMMData.toString() conversion methods to respect the fractional values and output them to the console in their original format.

For the ps.println("Double : " + ((OMMNumeric)data).toDouble()) , I am actually converting the underlying fractional value to a Double.

Hi Nalla,

Thank you for your reply. @Umer Nalla

Based on your suggestion, the client use ((OMMNumeric) ommData).toDouble() method to convert double. But they will get double like 2568.7200000000003.

Is this correct? and they're using Double.parseDouble(ommData.toString()), then they can get the double with long decimal number.

Could you tell me if Double.parseDouble method is better to solve this issue?

Thank you

BR

Chris Wang

Hi @Umer Nalla,

The client said they use use ((OMMNumeric) ommData).toDouble() first, but they got the value with long decimal number. However, they use Double.parseDouble(ommData.toString() and the issue solved.

So they want to know what's difference between those two.

Hi @Chris.Wang

The first one they are using the RFA methods to convert the OMMNumeric to a double, the second they are converting the field to a String and then using standard Java methods to convert.

The puzzling thing is how are they even getting .72 from a from a fractional value - as the nearest fraction I can find is 18/25. The encoding system for OmmType of REAL only supports divisors of 1,2,4,8,16,32,64,128 and 256?

What was the actual fractionally represented field value they received which then converted to 2568.7200000000003? And which Field where they decoding?

They should look at the RFA Reference manual entry for the OMMNumeric Interface which describes how a REAL value is encoded with examples of fractional and floating point values.

I consumed the CU8 RIC for several minutes with code converting and dumping REAL fields using (OMMNumeric)data).toDouble()

And I did not see any weird values as described...

Hi @Umer Nalla,

I just confirmed with client.

And he said there are two possible scenarios to use ((OMMNumeric) ommData).toDouble().

1. the data which included fractional value. He will use this method to convert to decimal number.

2. the data which not included fractional value, he will also use this method to parse data into double.

Here are result from his environment (GMT +8)

2018-08-06 14:17:28,533[INFO][ReutersLog]路透远期(FORWARD)路透报价更新元素115433： param->SGDCNY5M=R ask->107.94 bid->71.07000000000001 2018-08-06 14:17:28,533[INFO][ReutersLog]路透远期(FORWARD)路透报价更新元素112355： param->GBP6M= ask->110.85000000000001 bid->109.95 2018-08-06 14:17:28,533[INFO][ReutersLog]路透即期(SPOT)路透报价更新元素113690： param->CNH= ask->6.8505 bid->6.850300000000001 2018-08-06 14:17:28,533[INFO][ReutersLog]路透即期(SPOT)路透报价更新元素111022： param->DKK= ask->6.4523 bid->6.451300000000001 2018-08-06 14:17:28,659[INFO][ReutersLog]路透即期(SPOT)路透EBS报价更新元素161007： param->NZD=EBS ask->0.6737000000000001 bid->0.6734000000000001 2018-08-06 14:17:28,659[INFO][ReutersLog]路透即期(SPOT)路透EBS报价更新元素161006： param->CHF=EBS ask->0.9960500000000001 bid->0.9959500000000001

Hence, please also use this method to parse OMMData to double, even the number is not included fractional number.

Thank you

Chris Wang