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
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.
Hello @Paul.Wuethrich2
For more details of Real and RealHints, please refer to section 11.2.1 Real in ETA Java Developers Guide
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 issuesNo reply necessary as we will likely just migrate to using string-based interface