Progressive trending EMA

[edwardcufaude]

Hi TobbeLino,

Great work on the bot!

What do you feel about adding a check to see that the EMA is progressive in the correct direction.

Basically for the tick counts adding in a check to make sure that the dif1, dif2, dif3 are continuous in trend. example...

(tickCount==2 && (dif2>MinBuyThreshold) && (parseFloat(dif2.toFixed(3))<=parseFloat(dif1.toFixed(3)))) || (tickCount==3 && (dif2>MinBuyThreshold) && (dif3>MinBuyThreshold) && parseFloat(dif2.toFixed(3))<=parseFloat(dif1.toFixed(3)) && parseFloat(dif3.toFixed(3))<=parseFloat(dif2.toFixed(3))))

Edward

[schuderer]

I kind of like this idea and find it worth investigating. As I understand it, the idea is to check whether the short EMA is still moving in the same direction when reaching the MinBuy/SellThreshold. As the whole idea of using the short EMA is to represent the "current" movement (wrt the long EMA), determining its direction could enable bot users to use a lower Threshold and have the bot react quicker without sacrificing the smoothing. Need to work out the math of this one. @educk Have you tried out your code in the bot?

[edwardcufaude]

Yes I've tried out this code and it works and a buy/sell won't go through if the last tick isn't progressive in trend and will wait till the next price to check,

Buy if statement

if ((tickCount==1) || (tickCount==2 && (dif2>MinBuyThreshold) && (parseFloat(dif2.toFixed(3))<=parseFloat(dif1.toFixed(3)))) || (tickCount==3 && (dif2>MinBuyThreshold) && (dif3>MinBuyThreshold) && parseFloat(dif2.toFixed(3))<=parseFloat(dif1.toFixed(3)))) {

Sell if statement

if ((tickCount==1) || (tickCount==2 && (dif2<-MinSellThreshold) && (parseFloat(dif2.toFixed(3))>=parseFloat(dif1.toFixed(3)))) || (tickCount==3 && (dif2<-MinSellThreshold) && (dif3<-MinSellThreshold) && (parseFloat(dif2.toFixed(3))>=parseFloat(dif1.toFixed(3))))) {

These are the two bits of code I have used and tested in v0.2.1.4, they only check the last tick. The only thing is the table needs to show somehow that a buy/sell was stopped and there needs to be an option to turn it off really as not all would like it. The parseFloats were needed for the sell statement as they were being changed to strings leaving comparing of the negatives a problem to compare correctly, this code could be cleaned up by putting the parseFloat into the getemadif() function.

[TobbeLino]

Sorry, but I think it's a bit weird! (sorry for being so grumpy! :) I'm thinking that the effect will be like adding a VERY short average indicator like EMA(1)/EMA(3) on top of the other one, and I think that's quite strange. It's like trying to catch a long trend at the same time as a very short one - both at once... (and you can't really read a trend out of only three values)

So I think a feature like this would have to go into the "highly experimental" section :) I get a lot of suggestions and proposals for all kinds of "home-made" strategies and indicators, and I don't quite know how to handle them all :) I think I'll have to be a bit strict and conservative before adding highly experimental strategies into the bot, and I'd like to understand them myself (and preferably see some proven theory behind them or simulation data that shows that they in fact will make the bot better and make better trades in the long run). But maybe in some kind of "experimental" section to use on your own risk... :)

[edwardcufaude]

I completely understand.

Thing is that this bot is playing with people's money, so every change has to be done correctly!

I'm using it, but then I am using 5 minute intervals and it does seem to work good with that, I don't think it will work very well with the 30 minute/1 hour intervals.

I think the main thing stopping from adding additional indicators is the fact that the price the bot gets is just a single price and this could have been a bid or ask price and so the difference price trend is not 100% indicative of the market and so yeah I probably agree that this should be left out for the moment until we can get a better price sampling method or simulation data.

[schuderer]

Ha-ha, don't worry TobbeLino, it's good to be conservative (and maybe a little grumpy) on this topic. After all, the original concept has been validated on months worth of real data. That's nothing to throw into the wind just because you get some wide-eyed suggestions.

That said, I am thinking about making the current threshold smarter by taking the (relative and/or absolute) slopes of the two EMAs into consideration. But I have to think about this some more before actually suggesting something. :)