question

Upvote
Accepted
16 0 2 2

IDS vs ADS number format for some rics

When calling RIC AULZ2 in the IDS restful interface I get back results like:

"TRDPRC_1": "144 10/32",

"ASK": "144 11/32",

"BID": "144 9/32",

"PRIMACT_1": "144 10/32"

When calling though our ADS service I get back results like:

"TRDPRC_1": "144.09375",

"ASK": "144.125",

"BID": "144.09375",

"PRIMACT_1": "144.09375"

Most RICS return the decimal version in both IDS and ADS. Is there a reason the IDS is returning a fraction as the result or some RICS? Is there a way to configure the IDS not to return like this? It is causing an issue because we are using IDS currently but switching to ADS version soon and would like things to be consistent.

If we there is not a way to change how does 10/32 become the decimal part .09375?

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

Upvote
Accepted
24.8k 64 15 21

Hi @stephen_sweeney,

IDS is delivering all the data as Strings, whereas ADS will deliver the data as an underlying data type. So on the wire, Real data is being delivered as mantissa and exponent. When you decode this Real field in EMA, it gets you a double precision value. In case you are interested in getting a String fractional representation, then your application will have to format it in code.

Try something along these lines in your decode method:

if((fieldEntry.code() != Data.DataCode.BLANK) && (fieldEntry.loadType() == DataTypes.REAL))
  System.out.println("=====> " + decodeFraction(fieldEntry.real()));


String decodeFraction(OmmReal rlVal) {
  int divisor = 0;
  long mantissa = rlVal.mantissa();
  
  switch(rlVal.magnitudeType()){
    case OmmReal.MagnitudeType.DIVISOR_2: divisor = 2; break;
    case OmmReal.MagnitudeType.DIVISOR_4: divisor = 4; break;
    case OmmReal.MagnitudeType.DIVISOR_8: divisor = 8; break;
    case OmmReal.MagnitudeType.DIVISOR_16: divisor = 16; break;
    case OmmReal.MagnitudeType.DIVISOR_32: divisor = 32; break;
    case OmmReal.MagnitudeType.DIVISOR_64: divisor = 64; break;
    case OmmReal.MagnitudeType.DIVISOR_128: divisor = 128; break;
    case OmmReal.MagnitudeType.DIVISOR_256: divisor = 256; break;
    default:
      return Double.toString(rlVal.asDouble());
  }
  
  long a = mantissa / divisor;
  long b = mantissa % divisor;
  return a + " " + b + "/" + divisor;
}


Also 10/32 did not become .09375. You are comparing two different update messages.

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.

Upvote
32.2k 41 11 20

Hello @stephen_sweeney,

This forum can be of help with questions about API usage. Our IDS support experts can be of help with IDS configuration.

I have opened a support ticket #11579958 to try to confirm if decimal prices IDS config is available, please expect our support expert to reach out to you via email shortly.

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.

Hi @zoya faberov , how can we get EMA to display the fractions instead?

Hi @art.brzezinski1 ,

EMA- no, it is intended to convey the content, not to transform.

A consumer can implement the custom conversion, if required, for instance see this related external discussion.

Unless there is no way to proceed without this at the moment, I would strive to convey the content to the user as it is received, without the conversion.

@zoya faberov,

The challenge here is that Eikon and tools like testclient display this content as fractions which is why the same is being expected from EMA. If this can't be done in EMA, how about ETA?

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.