question

Upvotes
Accepted
Paul.Wuethrich2 avatar image
20 ●6 ●6 ●9

ETA/UPA guidance on using Real w/RealHints

I'm looking for some guidance on using RealHints with Real type in the ETA/UPA Java API (v3.3.0 of the jars)

1) Use case is for publishing to external consumers

2) Storing bid/ask values as Java double types

3) We were initially mapping the double values to Real types using a default RealHints value of EXPONENT_4 resulting in some inadvertent rounding (e.g. 0.12349 -> would result in 0.1235 on the receiving client side):

// ASK

fieldEntry.clear();

dictionaryEntry = dictionary.entry(MarketPriceItem.ASK_FID);

if (dictionaryEntry != null) {

fieldEntry.fieldId(MarketPriceItem.ASK_FID);

fieldEntry.dataType(dictionaryEntry.rwfType());

tempReal.clear();

// Set blank for empty book and wipes

if(mpItem.ASK == -0.0) {

tempReal.blank();

}

else {

tempReal.value(mpItem.ASK, RealHints.EXPONENT_4);

}

ret = fieldEntry.encode(encodeIter, tempReal);

if (ret < CodecReturnCodes.SUCCESS) {

return ret;

}

}

4) We modified the above to use the max value of EXPONENT_14 thinking that this would give provide a margin of safety for variable precision of decimal values. We then began seeing inconsistent & apparently random behavior for instrument bid/ask values that would either be 0 or something along these lines:


a) EXPONENT_14:

DOMAIN: MARKET_PRICE

UPDATE TYPE: UNSPECIFIED

3/DSPLY_NAME: <instrument name>

22/BID: 92233.72036854776

25/ASK: 92233.72036854776

134/MID_PRICE: <blank data>

30/BIDSIZE: <blank data>

31/ASKSIZE: <blank data>

436/BEST_BID1: <blank data>

441/BEST_ASK1: <blank data>

3814/UNDERLYING: <blank data>

16/TRADE_DATE: 8 APR 2020

5/TIMACT: 17:40:23:000:000:000


b) EXPONENT_4 or EXPONENT_8 which is the expected output value


DOMAIN: MARKET_PRICE

State: Open/Ok/None - text: "Item Refresh Completed"

2/RDNDISPLAY: 0

4/RDN_EXCHID: (0)

3/DSPLY_NAME: <instrument name>

22/BID: 192220.0

25/ASK: 197220.0

134/MID_PRICE: <blank data>

30/BIDSIZE: <blank data>

31/ASKSIZE: <blank data>

436/BEST_BID1: <blank data>

441/BEST_ASK1: <blank data>

3814/UNDERLYING: <blank data>

16/TRADE_DATE: 8 APR 2020

5/TIMACT: 15:56:03:000:000:000


5) Switching to EXPONENT_8 has resolved this behavior as of now

6) Feels like our original interpretation of using RealHints was incorrect given the API documentation on the Real type and underlying RealHints table of values. So can someone provide some guidance on using RealHints? Also note, that we could conceivable switch to using Real.value(String) instead of Real.value(double, hint)

thx

elektronrefinitiv-realtimeelektron-sdkrrtjavaeta-apielektron-transport-api
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.

3 Answers

Upvotes
Accepted
Jirapongse avatar image
47.2k ●110 ●44 ●60

@Paul.Wuethrich2

The code used to convert double to Real is available in GitHub.

           _hint = hint;
            if (value > 0)
                _value = (long)(value * powHintsExp[hint] + 0.5);
            else
                _value = (long)(value * powHintsExp[hint] - 0.5);

When using Real.value(double value, int hint), you need to know the hint. For 0.12349, the hint should be RealHints.EXPONENT_5.

When you see this value (92233.72036854776), it should indicate the calculated value exceeds the max long used in Java (-9,223,372,036,854,775,807 and 9,223,372,036,854,775,808).

Therefore, another option is using Real.value(String value) to convert string to Real.

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
pimchaya.wongrukun01 avatar image
9.5k ●10 ●5 ●7

Hello @Paul.Wuethrich2

For more details of Real and RealHints, please refer to section 11.2.1 Real in ETA Java Developers Guide

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
Paul.Wuethrich2 avatar image
20 ●6 ●6 ●9
Apologies - forgot to reply to this - I was looking for guidance on whether we could 'safely' pick one hint value given the following:


1) We arbitrarily used 4 and then realized we had some scenarios where values were being rounded up.

2) We increased the hint to the max of 14 assuming that it would cover more than adequate precision and this worked for +90% of values until we discovered that some values were way off even though there was no reason for an overflow condition

3) We've since changed the default to 8 and we're no longer seeing any issues


No reply necessary as we will likely just migrate to using string-based interface


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.