RFA 8.0 fields format

Chris.Wang

Hi,

I am assisting client to upgrade their TREP 2.x to TREP 3.x, so they will upgrade their RFA 5.x to RFA 8. However, when they started to test their program, they said they received fraction in some of fields, instead of decimal. But in the previous system, they always received decimal. Hence, the client wants to know if there any possible way to set parameter in system, so they can continue to receive decimal.

Here are some sample for fraction

MESSAGE

Msg Type: MsgType.REFRESH_RESP

Msg Model Type: MARKET_PRICE

Indication Flags: REFRESH_COMPLETE | CLEAR_CACHE

Hint Flags: HAS_ATTRIB_INFO | HAS_ITEM_GROUP |
HAS_PERMISSION_DATA | HAS_QOS | HAS_RESP_TYPE_NUM | HAS_SEQ_NUM | HAS_STATE

State: OPEN, OK, NONE, "All is well"

Qos: (RT, TbT)

Group: 00010017207921c4

PermissionData: 03001791c0 ( 0x03,0x00,0x17,0x91,0xc0
)

SeqNum: 20560

RespTypeNum: 0 (RespType.SOLICITED)

AttribInfo

ServiceName:
icbcIDN_SELECTFEED

ServiceId: 23

Name: CU8

NameType: 1 (RIC)

Payload: 1315 bytes

FIELD_LIST


FIELD_ENTRY 1/PROD_PERM: 91


FIELD_ENTRY 2/RDNDISPLAY: 77


FIELD_ENTRY 3/DSPLY_NAME: CORN SEP8


FIELD_ENTRY 4/RDN_EXCHID: CBT (23)


FIELD_ENTRY 5/TIMACT: 08:18


FIELD_ENTRY 6/TRDPRC_1: 354


FIELD_ENTRY 7/TRDPRC_2: 354


FIELD_ENTRY 8/TRDPRC_3: 354


FIELD_ENTRY 9/TRDPRC_4: 354


FIELD_ENTRY 10/TRDPRC_5: 354


FIELD_ENTRY 11/NETCHNG_1: -3 2/8


FIELD_ENTRY 12/HIGH_1: 355 4/8


FIELD_ENTRY 13/LOW_1: 353 2/8


FIELD_ENTRY 14/PRCTCK_1: (0)


FIELD_ENTRY 15/CURRENCY: USc (2009)


FIELD_ENTRY 16/TRADE_DATE: 24 JUL 2018


FIELD_ENTRY 17/ACTIV_DATE: 24 JUL 2018


FIELD_ENTRY 18/TRDTIM_1: 08:18


FIELD_ENTRY 19/OPEN_PRC: 355 2/8


FIELD_ENTRY 21/HST_CLOSE: 357 2/8


FIELD_ENTRY 22/BID: 354


FIELD_ENTRY 25/ASK: 354 2/8


FIELD_ENTRY 28/NEWS: YYYY


FIELD_ENTRY 29/NEWS_TIME: 07:25


FIELD_ENTRY 30/BIDSIZE: 27


FIELD_ENTRY 31/ASKSIZE: 92


FIELD_ENTRY 32/ACVOL_1: 6196


FIELD_ENTRY 41/CONTR_MNTH: SEP8


FIELD_ENTRY 42/BLKCOUNT:


FIELD_ENTRY 43/BLKVOLUM:


FIELD_ENTRY 47/OPEN1: 355 2/8


FIELD_ENTRY 48/OPEN2:


FIELD_ENTRY 49/OPNRNGTP: T (1)


FIELD_ENTRY 50/CLOSE1:


FIELD_ENTRY 51/CLOSE2:


FIELD_ENTRY 52/CLSRNGTP: (3)


FIELD_ENTRY 53/TRD_UNITS: 1/8 (13)


FIELD_ENTRY 54/LOTSZUNITS: BSH (21)


FIELD_ENTRY 55/LOT_SIZE: 5000


FIELD_ENTRY 56/PCTCHNG: -0.91


FIELD_ENTRY 60/CLOSE_BID: 356 4/8


FIELD_ENTRY 61/CLOSE_ASK: 356 4/8

umer.nalla

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.

umer.nalla

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.

Chris.Wang

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

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.

umer.nalla

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

Chris.Wang

Hi @Umer Nalla,

I asked client to tried again.

Here is the result he tried,

HKD1M= ask->-62.800000000000004 bid->-64.8

QAR= ask->3.6425 bid->3.6405000000000003

AUD= ask->0.7394000000000001 bid->0.7389

XPD= ask->918.5200000000001 bid->912.97

CNYMYR=R ask->0.59706
bid->0.5960000000000001

could you tell me what kind of data you may need for this issue?

Should I ask him to provide partial code for this topic? is that help?

Thank you

Chris Wang

Chris.Wang

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