Need an extra decimal point

[asfbhero]

I think the fair value is getting rounded up. should be 0.000006355

[asfbhero]

Looks like bitmex provides support for getting bots to work with their API, the link to their support is here, https://www.bitmex.com/app/automatedTradingEngines

[ctubio]

that is not support, that is language-specific implementations (that they published instead of properly documenting the meaning of each attribute)

i have seen useless documentation pages, but https://www.bitmex.com/app/wsAPI is the most useless one; just listing channel names

[ctubio]

about the rounding decimals, these are the same as the displayed decimals, so for TBP the rounding is of 8 decimals; cannot have moar

[asfbhero]

Is there any way we can get the Fair Value to be in between the bid and the ask, instead of setting FV at the ask?

[ctubio]

umm let me investigate this situation of the fair value

[ctubio]

here you have exemplified the issue http://cpp.sh/3ppc6

happens at:

Krypto-trading-bot/src/lib/Krypto.ninja-user.h

Lines 980 to 981 in d2e0830

	fairValue = (asks.cbegin()->price
	+ bids.cbegin()->price) / 2;

and can be set to match the bid value if instear of round() you call floor() at:

Krypto-trading-bot/src/lib/Krypto.ninja-user.h

Line 997 in d2e0830

fairValue = K.gateway->decimal.price.round(fairValue);

recompile and enjoy!

[asfbhero]

I'm a bit new to compiling things in linux, I tried just editing the source file then running make, but it seems to not make any sort of difference. I'm sure I'm doing something wrong.

[ctubio]

before make works, you need to build the distributed dependencies, that is make dist

once you have the dependencies, no need to run make dist anymore unless you remove them manually with rm -rf build-*

[ctubio]

see https://github.com/ctubio/Krypto-trading-bot#build-notes

[asfbhero]

Thanks, not sure if this change is doing exactly what I want, but now that I know where to look and hot to get it to compile I can play with the math a bit mroe and see what I can come up with.

Thanks again!

[Camille92]

Yes, stream precision needs to be 9 instead of 8 in that particular example.

Yes, the general stream precision for this pair should be 8 (for minimal increment etc), however, FV needs to be in between the two values at 0.000006355.

Hope it helps,
Camille

[ctubio]

i would say there is no need to limit precision (most of the time while doing calculations)

precision only needs to be limiterd to 8 when displaying values to the final user

[asfbhero]

Is this value hard coded somewhere, I can find the variable, but I don't see where it's pulling it's value from.

[ctubio]

🐨 i think you are looking for:

Krypto-trading-bot/src/lib/Krypto.ninja-apis.h

Lines 315 to 318 in 9fe9cdb

	decimal.funds.precision(1e-8);
	decimal.price.precision(tickPrice);
	decimal.amount.precision(tickSize);
	decimal.percent.precision(1e-2);

^this sets the precision for each type of decimals

fairvalue uses price type:

Krypto-trading-bot/src/lib/Krypto.ninja-user.h

Line 997 in d2e0830

fairValue = K.gateway->decimal.price.round(fairValue);

[asfbhero]

Perfect! Thanks!
Now I can start trying to shoehorn KAMA into EWMAPrice. That should allow profitable trading on more volatile, and also more liquid pairs like XBT/USD.

[ctubio]

hope for this issue to be fixed at #984