Welcome to Forex-TSD!, one of the largest Forex forums worldwide, where you will be able to find the most complete and reliable Forex information imaginable.
From the list below, select the forum that you want to visit and register to post, as many times you want. It’s absolutely free. Click here for registering on Forex-TSD.
Exclusive Forum
The Exclusive Forum is the only paid section. Once you subscribe, you will get free access to real cutting-edge Trading Systems (automated and not), Indicators, Signals, Articles, etc., that will help and guide you, in ways that you could only imagine, with your Forex trading.
Elite Section
Get access to private discussions, specialized support, indicators and trading systems reported every week.
Advanced Elite Section
For professional traders, trading system developers and any other member who may need to use and/or convert, the most cutting-edge exclusive indicators and trading systems for MT4 and MT5.
The settings you mention do make sense. I had to think about it, but it is more logical than algorithmic. The logic is very sound, but I do request we round up the last trade to the minimum lot size. With a 1 lot trade to start, a 0.1 lotsize is a common minimum and 0.01 won't work at all.
The settings you mention do make sense. I had to think about it, but it is more logical than algorithmic. The logic is very sound, but I do request we round up the last trade to the minimum lot size. With a 1 lot trade to start, a 0.1 lotsize is a common minimum and 0.01 won't work at all.
Great, I will provide the code with 3 new variables soon. I would ask you to fix any lotsize issues, as this is not within my understanding yet, or send me a function to use. I actually used the following code where MinLot I believe comes from Dmitry_CH Add 5.7.1. Dmitry code to fix minlot/maxlot may do the job we need for this already.
if (losses==0){ lot=lot*100/100; }
if (losses==1){ lot=lot*80/100; }
if (losses==2){ lot=lot*20/100; }
if (losses>=3){ lot=U_MinLot ; }
after the lotsize is created, round up to the decimal place permitted. I'd prefer not adding any more variables to 5.7.x Phoenix if we can avoid it.
I would rather not change the externals also. Instead, I can optimize it for the 5 currencies and then, leave only U_DecreaseFactor as the switch and turn the others into regular variables. I will use the pref settings to set all three values for these regular variables. These 3 variables can always be re-optimized as a third step, by making them external temporarily. First being signal, Second everything else, then these. I can also create default factors, for the other 5 currencies.
Quote:
round up to the decimal place permitted.
How do you do that? lot = NormalizeDouble(lot,decimalPlaces);
question. I have 90% history for modeling quality and a test account set up.
but I can't get the default settings to backtest on firebird or the new setting. Any idea? i have the and allow live trading.
after the lotsize is created, round up to the decimal place permitted. I'd prefer not adding any more variables to 5.7.x Phoenix if we can avoid it.
Here is the code. I see other people have coded this and I wanted to have my code remain consistent. I put the new proposed lotsize fixing code in blue. I can't see what is wrong with doing it this way.
Quote:
//+------------------------------------------------------------------+
//| START MoneyManagement - Optimize lot size |
//+------------------------------------------------------------------+
double Y_MM_OptimizeLotSize()
{
if(U_MM==false) return(U_Lots);
//Dmitry_CH Modify 5.7.1 lotsize min/max and safe on more brokers
double lot =U_Lots;
int orders =HistoryTotal();
int i =0;
int trades =0;
int wins =0;
int losses =0;
int decimalPlaces=1;
if(MarketInfo(Symbol(),MODE_LOTSTEP)==1) decimalPlaces=0; //Dmitry_CH Add 5.7.1
if(U_AccIsMicro==true) decimalPlaces=2;
lot=NormalizeDouble(AccountFreeMargin()*U_MaxRisk/1000.0,decimalPlaces);
if(U_DecreaseFactor>0)
{
i =orders-1;
trades =0;
wins =0;
losses =0;
while (trades< 3 && i > 0)
{
if(OrderSelect(i,SELECT_BY_POS,MODE_HISTORY)==fals e) { Print("Error in history!"); break; }
if(OrderSymbol()==Symbol() && OrderType()<=OP_SELL)
{
trades++;
if(OrderProfit()<0) losses++;
if(OrderProfit()>0) wins++;
}
i--;
}
if (losses==0){ lot=lot*100/100; }
if (losses==1){ lot=lot*80/100; }
if (losses==2){ lot=lot*20/100; }
if (losses>=3){ lot=U_MinLot ; }
}
// if(lot<0.1 && U_AccIsMicro==false) lot=0.1;
// if(lot<0.01 && U_AccIsMicro==true) lot=0.01;
// if(lot>99) lot=99;
if(lot<U_MinLot) { lot=U_MinLot; Print("lots switched to min ",lot); } //Dmitry_CH Add 5.7.1
if(lot>U_MaxLot) { lot=U_MaxLot; Print("lots switched to max ",lot); } //Dmitry_CH Add 5.7.1
I just looked over the code a second time. It looks fine.
One thing i'm trying to do to optimize my code is never divide by a constant value, always multiply by a decimal. Floating point multiplication is much faster than even integer based division, and in many cases the cast is done anyway to a float. In order to get precision on some platforms for some division, a weird set of bit shifting needs to be done to avoid irrational numbers. I don't do this right now, it is only something that can be done in C/C++/D anyway if I recall.
Instead of *80/100 you probably want to do *0.8 (removes 5-12 cycles off of the CPU)
I just looked over the code a second time. It looks fine.
One thing i'm trying to do to optimize my code is never divide by a constant value, always multiply by a decimal. Floating point multiplication is much faster than even integer based division, and in many cases the cast is done anyway to a float. In order to get precision on some platforms for some division, a weird set of bit shifting needs to be done to avoid irrational numbers. I don't do this right now, it is only something that can be done in C/C++/D anyway if I recall.
Instead of *80/100 you probably want to do *0.8 (removes 5-12 cycles off of the CPU)
I'm not sure you are looking at the latest code. Although I didn't have this *80/100 in my code I have plenty of integer division. I change integer division to decimal multiplication in 5.7.2.b and 5.7.2.w. I must say the code is much more confusing to understand the new way. I wonder how much time would be saved now in a big optimization. When I read about trades not being made because of " too much time", I know this is worth it.
It is something I want to focus on for Phoenix 6, not so much Phoenix 5.7 We can testing and see what the difference is between optimization sets. It will probably be very small, but sometimes you get big changes from something you thought would only be a minor difference. One of the larger performance increases in semi-compiled languages is the reduction of boxing/unboxing that occurs.
I'm going to make some structure changes in Phoenix 6 in the template I sent over, so we can quit computing each tick as quickly as possible. One thing we should probably do is profile optimization with different signals as the "primary filter" and see which one optimizes the fastest.
and allow live trading.
