开云体育

Hi All,

There is a topic on this subject from 2016.? It just doesn't seem to add up.

I tried to place a bracket Sell Order for NIO thru the API.? This is the output from my logs:
BKT Entry order??? STPLMT Shr:290 Limit:38.96 Aux:38.96
BKT Profit order?? LMT??? Shr:290 Limit:35.16
BKT StopLoss order STPLMT Shr:290 Limit:45.40 Aux:41.40

and received the error on the BKT StopLoss order STPLMT Shr:290 Limit:45.40 Aux:41.40
Error 110. The price does not conform to the minimum price variation for this contract

The Entry and Profit order both went thru just fine.

I received this simultaneously on the test and production systems.

Thanks and be well,
Lou Dudka

You can check the api log to see what was actually sent to IB.

Depending on the language and how floating point numbers are converted to text their may be differences in rounding from what you show in your logs.

The api log should help you track down the issue (either sending an invalid price or an issue on IB's end).

That was my first reaction as well. The ? say:

An entered price field has more digits of precision than is allowed for this particular contract. Minimum increment information can be found on the IB Contracts and Securities Search page.

闯ü谤驳别苍

On Fri, Oct 22, 2021 at 06:09 PM, Nick wrote:

...

Depending on the language and how floating point numbers are converted
to text their may be differences in rounding from what you show in your
logs.

...

Nick/闯ü谤驳别苍,

You guys are good!

Sure as anything prices of 41.3999 and 44.3999 were sent!

I'll have to check my code b/c I always round up/down to the correct amount before submitting an order, except, obviously, this time.

Thanks, as always, and be well,
Lou Dudka

Thank you, Lou. Glad we pointed you in the right direction.

You won;t be able to "round yourself" out of the problem completely. Even double precision floating point math can be pretty tricky and randomly generates very imprecise results in certain cases. Take the 35.16, for example (one of your prices). Here a couple example with Java double values:

35.16 + 0.01 = 35.169999999999995

35.16 * 1.01 = 35.511599999999994

It is common practice in financial software to use a Decimal or fixed point data type instead of? float and double. In fact IBKR introduced a Decimal data type in TWS API 10.10 and changed the size fields for many objects from double to Decimal (probably for crypto support). Interesting though that they left all price fields unchanged as double. Here the results with a Java decimal type:

35.16 + 0.01 = 35.17

35.16 * 1.01 = 35.5116

Internally, we use a Decimal type for all our applications as well. Makes calculations a little more cumbersome to code but makes for much better and controlled outcomes.

闯ü谤驳别苍

Hi 闯ü谤驳别苍,

Yes, I run into that all the time.? I use Excel (aarggh!) and I think it's even worse.

So I round at the very last step in an order right before I'm done.? I had to do this when trading Forex on IB and it drove me nuts.

As always, thanks again and be well,
Lou Dudka