How to divide a number into several, unequal, yet increasing numbers [ for sending a PlaceOrder( OP_BUY, lots ) contract XTO ]

External question — Stack Overflow Stack Exchange Author: olu mide Original post: https://stackoverflow.com/questions/58825820 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. I try to create an MQL4-script (an almost C++ related language, MQL4) where I want to divide a double value into 9 parts , where the fractions would be unequal, yet increasing My current code attempts to do it this way (pseudo-code) : Lots1 = 0.1; Lots2 = (Lots1 / 100) * 120;//120% of Lot1 Lots3 = (Lots2 / 100) * 130;//130% of Lot2 Lots4 = (Lots3 / 100) * 140;//140% of Lot3 Lots5 = (Lots4 / 100) * 140;//140% of Lot4 Lots6 = (Lots5 / 100) * 160;//160% of Lot5 Lots7 = (Lots6 / 100) * 170;//170% of Lot6 Lots8 = (Lots7 / 100) * 180;//180% of Lot7 Lots9 = (Lots8 / 100) * 190;//190% of Lot8 ... or better : double Lots = 0.1; // a Lot Size double lot = Lots; ... /* Here is the array with percentages of lots' increments in order */ int AllZoneLots[8] = { 120, 130, 140, 140, 160, 170, 180, 190 }; // 120%, 130%,... /* Here, the lot sizes are used by looping the array and increasing the lot size by the count */ for( int i = 0; i < ArraySize( AllZoneLots ); i++ ) { lots = AllZoneLots[i] * ( lots / 100 ) *; // PlaceOrder( OP_BUY, lots ); } But, what I want is to just have a fixed value of 6.7 split into 9 parts, like these codes do, yet to have the value increasing, rather than being same... e.g, 6.7 split into : double lots = { 0.10, 0.12, 0.16, 0.22, 0.31, 0.50, 0.85, 1.53, 2.91 }; /* This is just an example of how to divide a value of 6.7 into 9, growing parts

External answer — Stack Overflow Stack Exchange Author: Anatoliy R Original post: https://stackoverflow.com/a/58825980 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. Not sure I understood right, but probably you need total of 3.5 shared between all lots. And I can see only 8 lots not counting initial one. totalPercentage = 0; for(int i = 0; i < ArraySize(AllZoneLots); i++) { totalPercentage += AllZoneLots[i]; } double totalValue = 3.5; // total value is total percentage, Lots1 - 100%, so: Lots1 = totalValue / totalPercentage * 100.00; Then you continue with your code. If you want to include Lots1, you just add 100 to the total and do the same.

External answer — Stack Overflow Stack Exchange Author: Weather Vane Original post: https://stackoverflow.com/a/58827546 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. This can be done so as to make equal steps in the values. If there are 9 steps, divide the value by 45 to get the first value, and the equal step x . Why? Because the sum of 1..9 is 45. x = 6.7 / 45 which is 0.148889 The first term is x , the second term is 2 * x , the third term is 3 * x etc. They add up to 45 * x which is 6.7, but it's better to divide last . So the second term, say, would be 6.7 * 2 / 45; Here is code which shows how it can be done in C, since MQL4 works with C Syntax: #include <stdio.h> int main(void) { double val = 6.7; double term; double sum = 0; for(int i = 1; i <= 9; i++) { term = val * i / 45; printf("%.3f ", term); sum += term; } printf("\nsum = %.3f\n", sum); } Program output: 0.149 0.298 0.447 0.596 0.744 0.893 1.042 1.191 1.340 sum = 6.700

External answer — Stack Overflow Stack Exchange Author: user3666197 Original post: https://stackoverflow.com/a/58839688 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. How to divide a number into several, unequal, yet increasing numbers [ for sending a PlaceOrder( OP_BUY, lots ) contract XTO ]? The problem is not as free as it might look for a first sight. In metatrader Terminal ecosystem, the problem formulation has also to obey the externally decided factors ( that are mandatory for any XTO with an ambition not to get rejected, as being principally incompatible with the XTO Terms & Conditions set, and to get filled ~ "placed" At Market ). These factors are reportable via a call to: MarketInfo( <_a_SymbolToReportSTRING>, MODE_MINLOT ); // a minimum permitted size MarketInfo( <_a_SymbolToReportSTRING>, MODE_LOTSTEP ); // a mandatory size-stepping MarketInfo( <_a_SymbolToReportSTRING>, MODE_MAXLOT ); // a maximum permitted size Additionally, any such lot-size has to be prior of submitting an XTO also "normalised" for given number of decimal places, so as to successfully placed / accepted by the Trading-Server on the Broker's side. A failure to do so results in remotely rejected XTO-s ( which obviously come at a remarkable blocking / immense code-execution latency penalty one would always want to prevent from ever happening in real trading ). Last, but not least, any such XTO sizing has to be covered by a safe amount of leveraged equity ( checking the free-margin availability first, before ever sending any such XTO for reasons just mentioned above ). The code: While the initial pseudo-code above, does a progressive ( Martingale-alike ) lot-size scaling: >>> aListOfFACTORs = [ 100, 120, 130, 140, 140, 160, 170, 180, 190 ] >>> for endPoint in range( len( aListOfFACTORs ) ): ... product = 1. ... for item in aListOfFACTORs[:1+endPoint]: ... product *= item / 100. ... print( "Lots{0:} ~ ought be about {1:} times the amount of Lots1".format( 1 + endPoint, product ) ) ... Lots1 ~ ought be about 1.0 times the amount of Lots1 Lots2 ~ ought be about 1.2 times the amount of Lots1 Lots3 ~ ought be about 1.56 times the amount of Lots1 Lots4 ~ ought be about 2.184 times the amount of Lots1 Lots5 ~ ought be about 3.0576 times the amount of Lots1 Lots6 ~ ought be about 4.89216 times the amount of Lots1 Lots7 ~ ought be about 8.316672 times the amount of Lots1 Lots8 ~ ought be about 14.9700096 times the amount of Lots1 Lots9 ~ ought be about 28.44301824 times the amount of Lots1 the _MINLOT , _LOTSTEP and _MAXLOT put the game into a new light. Any successful strategy is not free to chose the sizes. Given the said 9-steps and a fixed amount of the total-amount ~ 6.7 lots , the process can obey the stepping and total, plus, it must obey the MarketInfo()-reported sizing algebra Given 9-steps are mandatory, each one has to be at least _MINLOT -sized: double total_amount_to_split = aSizeToSPLIT; total_amount_to_split = Min( aSizeToSPLIT, // a wished-to-have-sizing FreeMargin/LotInBaseCurr*sFty // a FreeMargin-covered size ); int next = 0; while ( total_amount_to_split >= _MINLOT ) { total_amount_to_split -= _MINLOT; lot_size[next++] = _MINLOT; } /* ################################################################################### ------------------------------------------------- HERE, WE HAVE 0:next lot_sizes next NEED NOT == 9 If there is anything yet to split: there is an integer amount of _LOTSTEP-s to distribute among them HERE, and ONLY here, you have a freedom to decide about split/mapping of the integer amount of _LOTSTEP-sized additions to the _MINLOT "pre"-sets in lot_size[]-s YET, still no more than _MAXLOT is permissible for the above explained reasons ------------------------------------------------- CODE has to obey this, if XTO-s are to get a chance ################################################################################### */