-2

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
user3666197
  • 1
  • 6
  • 50
  • 92
olu mide
  • 307
  • 3
  • 11
  • Although I am not quite sure what you really trying to do, how about replace percentages 120 ,...,190 to 10 ,..., 90? – DimChtz Nov 12 '19 at 20:04
  • You mean replace the percentage with direct values? like 0.1 * 120? lemme try it out in a moment. I'm not just good at maths – olu mide Nov 12 '19 at 20:07
  • No I mean just the percentages, For example (0.1/100)*10 – DimChtz Nov 12 '19 at 20:09
  • Divide `6.7 / 45` (the sum of 1..9). First term is that. Add again for the second term, etc. Sum of terms (`0.149 0.298 0.447 0.596 0.744 0.893 1.042 1.191 1.340`) is `6.7`. – Weather Vane Nov 12 '19 at 20:17
  • @olumide -- `Lots1 = 0.1;` -- Please note that this is not precise. You may come across [this issue](https://stackoverflow.com/questions/588004/is-floating-point-math-broken). You would be better off if you worked in integer, and only during calculations you divide to get the decimal fractions. – PaulMcKenzie Nov 12 '19 at 20:21
  • Hi @WeatherVane My maths is poor to know "add second term"... If i see tw examples, i might be able to follow-up myself – olu mide Nov 12 '19 at 20:23
  • Thanks, @PaulMcKenzie. I normalize before usage... – olu mide Nov 12 '19 at 20:24
  • Have you normalised the total of your fractions? (I see you did just now.) – Neil Nov 12 '19 at 20:26
  • `x = 6.7 / 45` is `0.148889`. The first term is `x`, the second term is `2 * x`, the third term is `3 * x` etc. They added 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` – Weather Vane Nov 12 '19 at 20:28
  • Thanks, @WeatherVane. I wasn't expecting to get this maths programming problem solved... Yours as well is worth an answer – olu mide Nov 12 '19 at 21:32

3 Answers3

0

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.

Anatoliy R
  • 1,749
  • 2
  • 14
  • 20
  • Do you mean totalPercentage += AllZoneLots[i]; ? – olu mide Nov 12 '19 at 20:11
  • Please, give the Lots2 example, so i can guess the rest in my test... My test from Lots1 = 0.28; – olu mide Nov 12 '19 at 20:17
  • @olumide you just continue you code: Lots2 = (Lots1 / 100.00) * AllZoneLots[0], Lots3 = (Lots1 / 100.00) * AllZoneLots[1], etc. Total for Lots2 to Lots9 must be 3.5. If you want to include Lots1 into 3.5, you have to add 100 to the totalPercentage – Anatoliy R Nov 12 '19 at 20:20
  • Your answer is fine, even nice to work with... I had to select the answer from @weathervane coz it looks more closer to the implementation i need - which doesn't deal with my actual example implementation – olu mide Nov 12 '19 at 22:28
0

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
olu mide
  • 307
  • 3
  • 11
Weather Vane
  • 33,872
  • 7
  • 36
  • 56
  • This is just that which i need... Increment by step... Thanks – olu mide Nov 12 '19 at 22:29
  • With all due respect ( respecting also chances the MQL4-domain is not your primary domain of expertise ), **this algorithm is principally wrong and does not solve the O/P in the domain of application**: The next instruction: **PlaceOrder( OP_BUY, lots ); confirms that the quantities are not free to compute**, but also have to meet all the legally set constraints from conditions of valid MINLOTS, MAXLOTS and MINLOTSTEP values from MarketInfo() context. – user3666197 Nov 13 '19 at 00:05
  • 1
    @user3666197 thank you for your advice. I posted this as a comment originally, just to show how increasing values can be evenly distributed, which is what the question asks. OP [asked me](https://stackoverflow.com/questions/58825820/divide-a-digit-into-several-unequal-yet-increasing-digits/58827546?noredirect=1#comment103930505_58825820) to convert it to an answer, which I did in C because of the tag C, and because the posted code looks like C. `PlaceOrder` is commented out. If you feel this answer is wrong **in principal**, please post what you believe to be the correct answer. – Weather Vane Nov 13 '19 at 08:44
  • IMHO it was not necessary to explain the history @WeatherVane as it was since the very beginning of the text noted above, the comment was not an objection ( of any form or fashion ) but was rather a warning to the Community Members and general public, that the presented algorithm, as-is, does not solve the O/P's problem in her/his domain of application ( which was understood as most probably not being at the same time a domain of your primary expertise, which was also expressed above ). The principally correct, context-aware solution demo was posted below. – user3666197 Nov 13 '19 at 15:01
  • There was a code I removed for brevity which checks for MINLOT, MAXLOT, etc. – olu mide Nov 14 '19 at 08:01
0

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

A : The problem is not as free as it might look for a first sight :

In 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 'em

   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
###################################################################################
                                                  */
user3666197
  • 1
  • 6
  • 50
  • 92
  • range and len also doesn't exist in MQL4, looks like python pseudo-code? – olu mide Nov 14 '19 at 08:08
  • **Obviously.** The purpose was to immediately show the progression of the above requested sizing ( rolling sum was not added as one can sum by heart, reaching more than **~ 64+ LOTs** ) Btw. **whoever can trade XTO-s with volumes above 64+ LOTs, there are way more problems to face** ( and due measures have to get implemented and operated ) in the production-grade code for live-trading on real markets. – user3666197 Nov 14 '19 at 08:30