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
Best Answer
-
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.
0
Answers
-
Hello @Paul.Wuethrich2
For more details of Real and RealHints, please refer to section 11.2.1 Real in ETA Java Developers Guide
0 -
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 issuesNo reply necessary as we will likely just migrate to using string-based interface
0
Categories
- All Categories
- 6 AHS
- 37 Alpha
- 161 App Studio
- 4 Block Chain
- 4 Bot Platform
- 16 Connected Risk APIs
- 47 Data Fusion
- 30 Data Model Discovery
- 608 Datastream
- 1.3K DSS
- 577 Eikon COM
- 4.9K Eikon Data APIs
- 7 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- Trading API
- 2.7K Elektron
- 1.3K EMA
- 236 ETA
- 519 WebSocket API
- 33 FX Venues
- 10 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 20 Messenger Bot
- 2 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 59 Open Calais
- 264 Open PermID
- 39 Entity Search
- 2 Org ID
- PAM
- PAM - Logging
- 8.4K Private Comments
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 20 RDMS
- 1.4K Refinitiv Data Platform
- 367 Refinitiv Data Platform Libraries
- 3 Refinitiv Due Diligence
- LSEG Due Diligence Portal API
- 3 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.1K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 10 World-Check Customer Risk Screener
- 990 World-Check One
- 44 World-Check One Zero Footprint
- 45 Side by Side Integration API
- Test Space
- 3 Thomson One Smart
- 1.2K TR Internal
- Global Hackathon 2015
- 2 Specialists Who Code
- 10 TR Knowledge Graph
- 150 Transactions
- 142 REDI API
- 1.7K TREP APIs
- 4 CAT
- 21 DACS Station
- 117 Open DACS
- 1.1K RFA
- 103 UPA
- 172 TREP Infrastructure
- 224 TRKD
- 886 TRTH
- 5 Velocity Analytics
- 5 Wealth Management Web Services
- 59 Workspace SDK
- 9 Element Framework
- 5 Grid
- 13 World-Check Data File
- Yield Book Analytics
- 46 中文论坛