ETA/UPA guidance on using Real w/RealHints

Options
Paul.Wuethrich2
Paul.Wuethrich2 Explorer
in ETA

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

Tagged:

Best Answer

  • Jirapongse
    Jirapongse ✭✭✭✭✭
    Answer ✓

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

Answers

  • pimchaya.wongrukun01
    pimchaya.wongrukun01 LSEG

    Hello @Paul.Wuethrich2

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

  • Paul.Wuethrich2
    Paul.Wuethrich2 Explorer
    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


Categories