1
$\begingroup$

Say we have a function for estimating the fair price of a security. The function gives outputs rounded to the nearest 0.5 (that is, the raw output is not a rounded float, but can have a decimal part in between 0 and 0.99).

Now, a trading system takes this input and amends the price of a limit order if the price calculated by this function of ours does not match the price of our order in the orderbook.

The problem is, due to rounding off, the output has a tendency to hop around at times, such as at any given time t:

px(t0) = 100.0
px(t1) = 100.5
px(t2) = 100.0
px(t3) = 100.5
px(t4) = 100.0
px(t5) = 100.5

This causes the system to needlessly amend the limit order too frequently.

How does one get around this problem?

$\endgroup$
1
$\begingroup$

The root cause is surely that your fair price is quite unstable? Rounding can only serve to stabilise your output value, for example rounding to 0 decimal places would result in 100 for all values.

$\endgroup$
  • $\begingroup$ Yes the fair price calculation is a bit unstable. I did try rounding to an integer too. Then it would keep oscillating between say, 99 and 100 when the fair price was between say for example, 99.8 and 100.2. Rounding to the nearest integer works mostly ok if the price is oscillating between say, 100.25 and 100.75. I could apply a moving average to the final output and then round it perhaps $\endgroup$ – CaramelFix Apr 1 at 9:02
  • $\begingroup$ @AlP Rounding 99.8 and 100.2 to 0 decimal places results in 100 and 100? $\endgroup$ – wildbunny Apr 1 at 9:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.