question

Upvotes
Accepted
7 3 2 5

RFA 8.0 fields format

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

elektronrefinitiv-realtimetreprfainfrastructure
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
Accepted
24.9k 86 10 22

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.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
24.9k 86 10 22

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.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
7 3 2 5

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

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
7 3 2 5

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.


icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
24.9k 86 10 22

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

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
7 3 2 5

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

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.