Rounding issue ?!?

[Dierk Droth]

Hi,

My app is implemented in C#. I just experienced a rounding issue: Requesting quote data for "EC Z4" I got a BasicQuote.dLast value of 1.2750000000000001. Obviously this price is not rounded properly.

Here are my questions:
- Is data sent by eSignal properly rounded ?
- Is this an issue of the MS .NET <-> COM interop ?
- Do I have to care on proper rounding on any (!) floating point value returned by the ActiveX API ?

I know this issue can be resolved by doing rounding on my end. Nevertheless, in case this is an issue on eSignal app's end, it should be fixed.

Regards

[Guest]

There are many explanations why this could occur, but it is a relatively insignificant issue.

[Dierk Droth]

Robi,

You probably should leave it to your customers to judge what "issue" is significant to them or not.

The question is:
- Does eSignal send out the not correctly rounded values ? -> Please fix that.
- Is this introduced by some issues eSignal can't do anything about it ? -> I somehow have to take care.

On a sidenote:
It's hard to round e.g. historical split-adjusted stock data correctly, since the rounding base (=ticksize) is variant for splitadjusted data.

Regards

[redblue]

Hi Robi,

Having a value such as 1.2750000000000001 might seem insignificant, but I can assure you that it is not. These find of values cause all kinds of subtle issues further down the line as this value is processed. In any financial application, input and output values should *always* be rounded to the correct level of precision. Either we have to round the value, or you do.

It might sound extreme, but in my view this value isn't correct - ok it's almost correct Putting it another way, this value didn't come from the exchange did it?

Cheers,

Red.

[GenSpoo]

Just a comment, as I know nothing of how eSignal transmits data on the raw level. I do know how another company does though, and this might be similar. In order to conserve bandwidth, what is sent is not the 8 byte double, but instead a base and a multiplier. Since one part is essentially constant for any given symbol, they only have to send the other part, thus saving bandwidth. When the data gets to the client, a numerical operation is performed to recreate the price from the base and multiplier. That numerical operation, like any on floating point numbers, can generate a little bit of noise (such as your 0.000000001).

Not sure this is where it is coming from in your case. But it could be.

Cheers... George

[Dierk Droth]

Hi,

I had a conversation this morning giving me the same picture.

The issue is: If this rounding error is produced on eSignal's end - by performing calculations on the exchanges raw data - then eSignal should take care of that problem.

Regards

[sthornington]

This is a limitation of IEEE floating point numbers. If the most insignificant digit is off, it's because a precise representation of the rational number is impossible in a floating point representation.

Cheers,

Simon.

[Dierk Droth]

Simon,

Thanks for reply. That's how these values are "created", right ?

The question remains: Shouldn't that be remedied on eSignal ends, since the exchange did not mean to send out 1.2750000000000001, did it ?

Regards

[Dierk Droth]

Simon,

I just tested with some lines of C# code: 1.275 != 1.2750000000000001.

Since double in C# and COM are IEEE values, this can not be an issue of .NET/COM interop. Most likely that's something on eSignal's end.

Could you please check Simon ?

Thanks

[redblue]

Originally posted by sthornington
This is a limitation of IEEE floating point numbers. If the most insignificant digit is off, it's because a precise representation of the rational number is impossible in a floating point representation.

Hi Simon,

Got you - except that 1.275 as a double (C x86) is 1.2749999999999999 and not 1.2750000000000001?

Cheers,

Red.

[Guest]

There are numerous conversions that take place from the 180 feeds and 1 million symbols that we collect. When moving from multipliers and bases as Genspoo suggested, there are technical reasons whey the conversions are not COMPLETELY accurate.

The price you mentioned is accurate to the trillionth decimal place! That's twelve zeros! And only 1 of 80,000 quotes on EC Z4 each day!

We are more concerned with scrubbing bad ticks (about 2% of all ticks) we receive from the exchanges and have won awards for over a decade on how well we do so.

While we continue to investigate this specific issue, which could occur during the telecom transfer, there is a very simple workaround to this problem. Round to the thousands of a penny - that should not surely not through off any algorithm or trading model.

[Dierk Droth]

Robi,

Thanks for confirming, that the issue is on eSignal's end.

Since you stated that it's simple to fix this issue, why not just doing it within the eSignal app, where the problem arises?

On some sidenotes:
1) Winning awards does not prevent you from improving your services and fixing issues analysed by your customers.
2) I did not check on 80.000 quotes but just gave it a quick try ( < 1 minute). Thus, the likelyhood, that this problem arises is far from zero.
3) The whole issue was not about wrong data or data srubbing, but on in-correctly rounded data.

Please let me know if you have any problems on publically discussing issues on your product.

Will this issue be fixed by the next eSignal release ?
Does this issue also exist for historical data or just for realtime data ?

Regards

[jvalimaa]

Hi,

What the heck is this rounding issue???

Why don´t I get just the correct data?


I tried this API first time today and almost all my symbols had
this issue.


Best regards,

JV

[Guest]

The precision of the prices being discussed in this link are well beyond the number of significant digits provided by the exchanges I believe. Here are a couple of links discussing accuracy, precision and significant digits. They are interesting reading IMHO.

http://www.cs.princeton.edu/introcs/91float/

http://www.andrews.edu/~calkins/math...xts/numb09.htm

And finally, an interesting book which IMHO puts it all in perspective.

http://www.amazon.com/gp/cdp/member-...17586-4042521?

Personally, I would recommend rounding the prices as Robi recommended. This should be performed locally within your application regardless of the rounding performed by eSignal. This rounding should be roughly at the number of significant digits of the data being transmitted from the exchanges. Only then can you be assured that the numbers will be truly accurate at all times.

[redblue]

Originally posted by eSignal Robi
The price you mentioned is accurate to the trillionth decimal place! That's twelve zeros! And only 1 of 80,000 quotes on EC Z4 each day!

...

While we continue to investigate this specific issue, which could occur during the telecom transfer, there is a very simple workaround to this problem. Round to the thousands of a penny - that should not surely not through off any algorithm or trading model.

Morning all,

To put things into perspective, imagine this code was being run:

If (CurrentPrice==1.275) {
BuyMarket;
}

Where CurrentPrice returns the latest price from the esignal feed. Since your "1.275" isn't actually 1.275, the condition is never met, and the market order never placed. So much for being a trillionth decimal place out eh?

Ok - In reality, we should never do any kind of equality testing on doubles, but unfortunately this kind of thing happens all the time (even in production code).

In my view, the user has the expectation that the value you provide is correct one and not merely 0.0000000001 out.

Cheers,

Red.