RFA 8 Java API MARKET_PRICE decimal precision

stefan.lechner

I've had to write a program using RFA 8 JAVA API that subscribes to serveral RICS to get BID/ASK values. The new program should replace a legacy application that receives the same RICS form the same servers and the same services.

Main difference, my java application get's only 3 decimal places while the legacy app delivers 6 decimal places for the same RIC.

I searched in the forum an documentation but could not find a clear statement or documentation about my issue.

Can any one give me a hint, what I'm probably doing wrong ?

Is this a restriction of RFA Java and OMM ?

Regards

Stefan

pimchaya.wongrukun01

Hello @stefan.lechner

Regarding “my java
application get's only 3 decimal places while the legacy app delivers 6 decimal
places for the same RIC.”, I
found the opposite results from the example application shipped with RFA7.6(MarketData
interfaces) and RFA8(OMM interfaces) as shown below:

The example data of RIC IBM.N
from MDSubDemo using MarketData(MD) interfaces:

The example data of RIC IBM.N
from StarterConsumer using OMM interfaces:

You can see that OMM
interfaces gets 6 decimal places while MarketData interfaces gets 2
decimal places. This was caused from MDSubDemo did not apply the hint
specifying the number of decimal places for this field so all zero(s) after
decimal were truncated. However, StarterConsumer uses com.reuters.rfa.omm.OMMData.toString() to print data.

You should try StarterConsumer
to check if the number of decimal is less than your legacy application. The
application is in

<RFA package>\Examples\com\reuters\rfa\example\omm\cons

The example command line
to subscribe RIC IBM.N from the service named ELEKTRON and run 5 minutes:

java  -cp ..\Libs\rfa.jar;..\Examples com.reuters.rfa.example.omm.cons.StarterConsumer -session myNamespace::consSession -user pimchaya -itemName IBM.N -serviceName ELEKTRON -attribInfoInUpdates true -enumType ..\etc\RDM\enumtype.def -rdmFieldDictionary ..\etc\RDM\RDMFieldDictionary -runTime 300

Please refer to package.html
in the application folder for each parameter of the application.

Lars-at-Addicticks

How do you know it is actually different on the wire and that is is not just something your application does?

In any case, in the following I'll assume you mean a difference in significant decimals.

You are not - incidentally - converting the price to a native floating point type are you? (i.e. type 'float' or 'double' in Java). I guess you can sense from my phrasing what I feel about floating point types. They are bad for your health and you almost never need them. :-)

Dealing with market data is almost always about either displaying data or transporting them to some other system. Perhaps your application may even compare prices. But do heavy algorithmic on them? I doubt it. For this reason, I believe floating point types (because of their unpredictability) should be avoided 99% of the cases when dealing with market data. Don't even get me started on blank values which cannot be expressed in native types.

Okay, moving on. Rant stops here. I don't know if use of floating point types is your case or not.

The important thing here is the wire format. I don't know what your legacy application is, but let's assume that it is consuming MarketFeed at the wire level?. In contrast an application made with the more modern APIs consume RWF (Reuters Wire Format) at the wire level. MarketFeed is a text-based protocol. So a price of 123.45 travels the wire as "123.45". RWF is a binary protocol. Here a price travels the wire as a integer value (12345) and a scale (2) which is a lot more compact way of expressing the same thing. At the extreme margins there are differences between what price values can be expressed in MarketFeed vs RWF, but a difference of 3 vs 6 decimals sounds to me like a difference in how the two applications treat the value (or presents it) rather than how it arrives to the application, i.e. how it is sent from the server.

From my experience there has never been a Thomson Reuters API where precision would somehow be lost within the client library itself, assuming of course you use the right methods from the API. There's always a method that will give you the full precision. For example in RFA Java the OMMNumeric.toBigDecimal() method doesn't loose any precision. Also the OMMNumeric.toString() method should be fine.

Hope this help.

stefan.lechner

Thanks for all the hints.

Regarding OMM and RFA I did everything right, BigDecimal not Float no rounding, but at the end, when writing a file with the ask/bid values, I used a NumberFormat.getInstance(locale) to format it according the customers need.

Using my developer account for testing, I used indeed only RICs with 2 or 3 decimal places.

I even debugged the OMM Messages, to be sure that I'm not shortening something.

But I never figured out, that the default NumberFormat has a MaximumFractionDigits of 3, which caused my problems.

@Pimchaya.Wongrukun:

Thanks for the hint with the OMM Cons demo, this showed me that I'll get more decimal places if there are any.

chris.xiao

https://community.developers.refinitiv.com/discussion/comment/27866#Comment_27866

@ Pimchaya.Wongrukun Can we assume the price precision is 6 decimals for RFA server? Our system assumes it is 4 decimal and store price as long by multiplying 10,000 to actual price. If we can assume 6 decimal, I will use a factor 1000,000 instead. Recently a trade update event FIELD_ENTRY 4109/OFFBK_PRC: 3.97786 breaks my program.

pimchaya.wongrukun01

https://community.developers.refinitiv.com/discussion/comment/59802#Comment_59802

Hello @chris.xiao

You cannot assume the price precision will be always 6 decimals. The number of decimals depends on the feed/exchange which publishes data. RFA passes data as it received from the feed to the application. REAL/REAL32/REAL64 field e.g. FID 4109 compose of an integer value and a hint which explains how to convert the integer to a floating point value. For the steps to apply a hint, please refer to How REAL, REAL32 and REAL64 hints work in Interface OMMNumeric of RFA Java Reference Manual