Length of Mantissa portion of rate value

Hi Umer/ Refinitiv team,

Is the Mantissa always byte multiple length ? e.g. 0297AC is 3 bytes/24 bits, this also represents the same value as 297AC which is 20 bits. Wanted to confirm.

0x0001, 0x001, 0x01, 0x1 all represent the same number (decimal 1)

Similarly 0xfff1, 0xff1, 0xf1 represent the same number (considering 2's complement, i.e. decimal -15)

Wanted to check whether FID 393, Mantissa component would always be in multiple of bytes.

Regards,

Rohit

Find more posts tagged with

FID

Accepted answers

umer.nalla

Hi @rohit.gajare

Firstly, I must point out that log fille output is designed for diagnostic purposes and NOT for data collection/extraction and I cannot recommend such an approach.

For other customers I have worked with who need to capture and store tick data, they actually consume the data using the API and either

programmatically create their own capture files from the data payloads received (which they process later)
OR write the data directly to their database as and when received.

Using the above approach means you would be using the API as designed - to parse the data (and not have to be concerned with the log file data formats).

Certainly, it does not make much sense to be extracting this data from a diagnostic log file - when the API is already able to provide you with the correct means to decode the data.

In terms of the output format of the log files, I am not aware of any documentation in terms of guaranteed output format to the log file - i.e. if the log file could ever contain truncated nibbles of data as the type you describe e.g. 0xf. Certainly, it would not make much sense for the API to do such a thing.

I can try and reach out to the Dev team to see if they can confirm.

All comments

umer.nalla

Hi @rohit.gajare

I am not sure I entirely understand the question...

Looking at the RFA Developers guide (section 6.3.5.1 Data and DataBuffer Type Classification) described the Real type as:

An 8-byte precision10 (19-20 decimal places) fixed-placed representation of a numeric having a fractional or exponential part. The range of the fractional part is from 1/2 to 1/256. The range of the exponential part is from 10-14 to 107. Uses rfa::data::Real64. (See note following this table).

The rfa::data::Real also supports infinity, negative infinity, and Not a Number (NaN) values. The application can use rfa::data::MagnitudeType::Infinity, rfa::data::MagnitudeType::NegInfinity and rfa::data::MagnitudeType::NotANumber to set these values.

Also, looking at section 9.2 Encoding a DataBuffer, when encoding a Real64 field, the setValue only takes an Integer value.

Likewise with the RT-SDK documentation, when setting values for Real type fields we use longs etc.

There are no mentions of nibbles anywhere in the RFA or RT-SDK Documentation - only bytes or multibyte primitives such as int, long etc.

rohit.gajare

@umer.nalla Thanks for your response.

Just to clarify, we are implementing a solution which reads interest rates from RFA.LOG file and stores the data - interest rate information in our tables ..

We are working on the decoding (hex to decimal) logic for the interest rate reported.

Since the interpretation is based on 2s complement, wanted to understand the length of the Mantissa component ..

e.g.

0x1, is decimal1

0x01, is decimal 1, on the other hand...

0x0F, is decimal 15

0xFF, is decimal -1

how should 0xF be interpreted ? as 0x0F i.e. 15 or 0xFF i.e. -1

Based on the rates provided in RFA.LOG files , the Mantissa appears as a byte or multiple of bytes 0xHH, or 0xHH HH HH , wanted to know whether Refinitiv may publish a rate with Mantissa as 0xH HH , or 0xH HH HH, which are not even set of bytes.

Regards,

Rohit

umer.nalla

Hi @rohit.gajare

Firstly, I must point out that log fille output is designed for diagnostic purposes and NOT for data collection/extraction and I cannot recommend such an approach.

For other customers I have worked with who need to capture and store tick data, they actually consume the data using the API and either

programmatically create their own capture files from the data payloads received (which they process later)
OR write the data directly to their database as and when received.

Using the above approach means you would be using the API as designed - to parse the data (and not have to be concerned with the log file data formats).

Certainly, it does not make much sense to be extracting this data from a diagnostic log file - when the API is already able to provide you with the correct means to decode the data.

I can try and reach out to the Dev team to see if they can confirm.

umer.nalla

Hi @rohit.gajare

I have received the following reply from the dev team 'XML data tracing is used for debugging purposes only and applications should extract RWF data by using RFA decoders in their applications only. RFA does not support this (i.e. extracting data from the log file) usage' .

wasin.w

Hello @rohit.gajare

My colleague @umer.nalla already provided a clear detail for you. Additionally, you can find more information about how to the price data programmatically from the RFA C++ API from the following resources:

RFA C++: Tutorial 7 - MarketPrice Refinitiv Data Model (RDM), Part 2
RFA C++ example: StarterConsumer

Please note that the API just receives incoming data from Refinitiv Real-Time and then passes it to the application "as is".

EXPLORE OUR SITES