question

Upvotes
Accepted
Albert Piers avatar image
2 ●0 ●1 ●2

Additional digits seen on price fields with RFA build app

Hi fellow developers,

We have build a RFA application and sometimes it generates prices for fields like BID or TRDPRC_1 with additional unexpected digits for equity instruments, for example 20.299999 or 20.290001 while the tic size is fixed at 0.005 by the exchange so we should never expect these additional digits that look like roundings somewhere in the RFA application. We are only not aware of any rounding being done in the coding itself.

Other test apps like example or Eikon does not show these additional digits, so the data coming from exchange / Thomson Reuters does definitely not contain these additions.

Does anyone have an idea in which part of the RFA decoding this could occur?

Or has anyone else seen this before and know what can be done to correct this?

Regards

Albert

treprfarfa-apiapp
icon clock
10 |1500

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

1 Answer

Upvotes
Accepted
Jirapongse avatar image
38.1k ●71 ●35 ●53

This could be a limitation of IEEE 754 of floating-point arithmetic. In computing, floating point is a method of representing an approximation of a real number in a way that can support a trade-off between range and precision. For example, if we directly assign 9605.4 to a double variable, the value in memory of that variable is 9605.3999999999996.

This is also mentioned in RFA C++ Developer Guide.

Note:

OMM preserves the precision of encoded numeric values. Note that some conversions from OMM numeric types to primitive types (e.g., Real to Float) may result in a loss of precision. This is a case of a narrowing precision conversion. Also note that because the IEEE Standard for Floating-Point Arithmetic (IEEE 754) cannot represent some values exactly, rounding may occur when manually converting from the OMM representation to other data types, or converting via the provided utility methods.

In cases where precision may be lost, converting to a string or using provided string conversion helper as an intermediate point can help avoid the rounding precision loss.

Moreover, the application must verify if the value of data is blank (isBlank()) before accessing the data.

If you have any further question, please let us know the following information.

  1. The version of RFA used by the application, such as RFA C++ 8.0.0.L1
  2. The RFA interface that the application is using MD or OMM interface
  3. The RIC that cause this issue
  4. The snippet code that the application uses to retrieve the price data


ex.png (18.2 KiB)
icon clock
10 |1500

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

Albert Piers avatar image Albert Piers

Thanks Jirapongse, it was exactly where the issue was appearing in the conversion from real64 to double / float, just like you mention. Your answer helped our developer to change his code so no rounding does happen any more.

Click below to post an Idea Post Idea