EMA Giving scientific notation for certain fields

Moving from RFA to EMA I noticed one of the difference is when it decides to convert the number to scientific notation.

1656440458814.png


Any possibility to default all fields away from using scientific notation?

Another odd behavior is for volume fields like askSize EMA gives it as 0.0 while rfa gives it as a 0


I know you can use:

EmaFactory.createFieldEntry().real( 6, 11, OmmReal.MagnitudeType.EXPONENT_NEG_2) ;

but we require a lot of fids and would need to declare for each one.


Any help would be appreciated


Using java with ema version 3.6.5.0

Tagged:

Best Answer

  • Jirapongse
    Answer ✓

    @carl_miller

    I checked the code if the power of zero, it will use Double.toString(toDouble()); to convert a double to a string.

       if (_value != 0)
                {
                    /* Handles number of decimal places according to the hint value. */
                    if(RealHints.EXPONENT_14 <= _hint && _hint <= RealHints.EXPONENT_1)
                    {
                        return String.format(decimalStringFormat[_hint],toDouble());
                    }
                    else
                    {
                        return Double.toString(toDouble());
                    }
                }

    If you would like to change this behavior in the API and you have an RDC contact (Premium Support), you can raise this issue to the API Support team via Contact Premium Support.

    1656566953841.png

    Otherwise, you can submit this issue via GitHub.

Answers

  • Hi @carl_miller

    Are you ensuring the value is not blank prior to processing?

    ...
    if (Data.DataCode.BLANK == fieldEntry.code())
    System.out.println(" blank");
    else
    switch (fieldEntry.loadType())
    {
    case DataTypes.REAL :
    System.out.println(fieldEntry.real().asDouble());
    break;
    ...
    }
    ...
  • Yes I return blank if its blank 1656447666805.png

  • I have also seen this behavior with an actual value

    1656447841839.png

  • I tested ACVOL_1 for index .DJI to recreate the scientific notation for that fid during market hours

  • @carl_miller

    I think this is how Java displays a double value.

    I found an answer on StackOverflow. To print a double value without scientific notation, you can use real.asBigDecimal().toPlainString().

            FieldEntry fieldEntry;
            while (iter.hasNext())
            {
                fieldEntry = iter.next();
                System.out.println("Fid: " + fieldEntry.fieldId() + " Name: " + fieldEntry.name() + " value: " + fieldEntry.load());
                if(fieldEntry.fieldId()==32) {            
                    OmmReal real = fieldEntry.real();                
                    System.out.println("mantissa: "+real.mantissa());
                    System.out.println("magnitude type: "+real.magnitudeTypeAsString());
                    System.out.println("asDouble: "+real.asDouble());
                    System.out.println("asBigDecimal.toPlainString: "+real.asBigDecimal().toPlainString());        
                    
                }
            }

    The output is:

    Fid: 32 Name: ACVOL_1 value: 3.53773301E8
    mantissa: 353773301
    magnitude type: Power of 0
    asDouble: 3.53773301E8
    asBigDecimal.toPlainString: 353773301

    I hope this can be of help.

  • One side effect of making every real processed through this way would be getting rid of the leading zeros for price fields. Any way to determine if its a price fields vs volume? I could hardcode a fid check, but I would like something a bit more dynamic if possible

    1656513517966.png


    1656513599639.png

  • In rfa we just gave the string to the consumer and it was never converted to double. I suppose ema behind the scenes must convert it?

  • Hi @carl_miller

    Looking at the data dictionary and pulling up a few examples of price fields vs volume, I see this:

    ACRONYM   DDE ACRONYM     FID  RIPPLES TO  FIELD TYPE  LENGTH  RWF TYPE  RWF LEN
    ------- ----------- --- ---------- ---------- ------ -------- -------
    ACVOL_1 "VOL ACCUM..." 32 NULL INTEGER 15 REAL64 9
    TRDPRC_1 "LAST" 6 TRDPRC_2 PRICE 17 REAL64 9
    BID "BID" 22 BID_1 PRICE 17 REAL64 9
    BIDSIZE "BID SIZE" 30 NULL INTEGER 15 REAL64 9

    Using the "Field Type" or "Length" might be a suitable way to distinguish.

  • Any easy way to check field type inside refreshmsg. It has data type which is giving real. I can grab the data dictionary in a separate flow and use that, but wondering if any prebuilt checks might exist.

  • Hi @carl_miller

    I was looking at the real() (OmmReal) interface, and it offers a number of other attributes/representations of the data. I'm not sure if you have looked deeper into this, but things I noticed:

    fieldEntry.real().asBigDecimal()

    Through preliminary tests, I did not notice scientific notation.

  • Hi @carl_miller

    The only other thing that I noticed that could potentially distinguish price and volume fields is the values coming out of fieldEntry.real().magnitudeType(). I noticed, based on some tests, this value is OmmReal.MagnitudeType.EXPONENT_0 (14) for volume fields. However, this would require deeper investigation.

    The other option is to interrogate the data dictionary, based on the field ID, to pull out the "FIELD TYPE" or "LENGTH" properties for the FID. I would have to determine if/how this is possible.