Questions about fitness and simulated orders

[askmike]

First of all thanks for this awesome project!

I am looking into using this project to come up with strategies for cryptocurrency markets, and for that I have a few questions:

• fitness (with fees): we have to pay fees per trade, I could calculate that here, but then the "best" proposed algorithm might not be the most profitable at all since fees were not taken into consideration on the genetic selection level. Fees are the same for every trade (assuming all trades are either limit "maker" or market "taker" orders). This only changes if the trade size is different, which I guess is never, right? (fees are percentage based on order size.)
• spread and simulated order type: cryptocurrency markets are not that liquid and can sometimes have big spreads. When looking at the code it seems that buy orders assume the buy price is equal to the high of that candle, is there any reasoning behind this (I guess worst case scenario)?

Thanks!

Mike

[mkmarek]

Hi, thanks, I appreciate that you like this project.

About the first point: There is a spread option which I added to this project some time ago. Perhaps that could deliver the functionality you want. You can have a look on the development branch to see more details. But basically there are two new parameters required for the config object in the findStrategy function.

• pipInDecimals which contains a decimal value of one pip e.g. 0.0001 for EURUSD
• spread which is the fee for each trade.When It calculates the pure revenue it does it like this:

double spreadValue = args.pipInDecimals * args.spread;
double revenue = trades->at(i).getRevenue() - spreadValue;

You can find the actual code here.

I can by the end of today make a merge with the master branch and put it on npm so it's available through normal channels. I also fiddled around with the fitness function a bit and after that the solution didn't really work that well. But I'm guessing you'll have to do some trial and error as well to get a decent results.

About the second one: Yes the reason was exactly to cover the worst case scenario. But the fitness function can also use the getRevenue method from a specific trade. In the latest changes here I left this approach and just compared the close values with the getRevenue method.

Also the code you had a look on was calculating something called maximumPotentialLoss and profit which are boundaries in which the price oscilated during a specific trade. Quite interesting data for considering SL and TP strategy.

But in the end due to high liquidity of the currency pairs I'm aiming for right now I haven't really considered including this into the algorithm.

Also just a little disclaimer. This library is a result of quite limited knowledge about genetic programming and C++ as well I have to admit. :smiley: but since I've learned a lot more since then I'm preparing a new version which should hopefully be publishable soon and should give more flexibility and more variations when it comes to defining trees, data normalization, selection algorithms, etc.. and most of all it shouldn't rely so much on mutations. that's why I haven't touched this project for quite some time.

Happy trading!

Marek

[askmike]

Marek,

Thanks for your explanation. I think I can definitely use this project (just to play around). The main thing I need to overcome before I can use it myself:

Because of high fees and spreads placing orders is very expensive. So instead of going long when an uptrend is identified and selling the long position as soon as there is some profit (to minimize risk), most people (in cryptocurrency trading) stay long until their indicators tell them that the trend is going down instead of up.

If I would like to mimic behaviour in your simulation, I probably need to change some stuff deep inside the simulation logic.

Regards,

Mike

[xhad]

wow. mkmark's genetic forex module is fascinating.