Errors, bugs, questions - page 2875

New comment
 
Denis Rodionov:

Here's how it shows. The settings are in Russian.

my terminal looked like yours on english windows, so i told you to look at the settings

Your default language is Russian? - If so, then I do not know why the terminal does not see the settings

 
Igor Makanu:

I have the same terminal look as you have on English WinDin, so I advised to look at the settings

Your default language is Russian? - If so, then I do not know why the terminal does not see the settings

The language is yes, it is Russian. And all terminals such a thing.

I figured it out)))

The terminal settings somehow had Arabic as the default language.

 

Contradiction:

struct A {
        int i[1]; //(*)
        void f1() const {        i[  0 ] = 1;   } //(1) Error: 'i' - member of the constant object cannot be modified
        void f2() const { ArrayFill( 0, 1, 1 ); } //(2) Error: 'ArrayFill' - wrong parameters count
};
struct B {
        int i[ ]; //(**)
        void f3() const {        i[  0 ] = 1;   } //(3) нормально ???
        void f4() const { ArrayFill( 0, 1, 1 ); } //(4) Error: 'ArrayFill' - wrong parameters count
};

Suppose there is a fundamental difference between (*) and (**) - allowing to compile (3) without error, but then what is the fundamental difference between (3) and (4) ?

Expected: Same compiler behaviour in (1) and (3) and\or in (3) and (4)

 

Forum on trading, automated trading systems and trading strategy testing

Bugs, bugs, questions

A100, 2020.08.31 15:55

On a chart (particularly EURUSD) with monthly and weekly timeframes, the crosshair moves very slowly following the cursor - to play it back, just move the cursor smoothly along the diagonal...


Play as follows:

On the EURUSD daily chart (MetaQuotes-Demo) through the Calendar tab add events for the previous, current and next month (there are about 1400 objects). After the specified addition the chart begins to slow down so much that it is difficult to move the crosshair and move the trend lines.

If one removes all OBJ_EVENT objects, the lag disappears

 
A100:

Contradiction:

Suppose there is a fundamental difference between (*) and (**) - allowing to compile (3) without error, but then what is the fundamental difference between (3) and (4) ?

Expected: the same compiler behaviour in (1) and (3) and\or in (3) and (4)

Yes, there is a contradiction for ArrayResize, we will solve this in the next language syntax upgrade.

(1) and (3) are different cases, in the first - the memory for the array is part of the constant object, in the second not, the array object itself is constant, but its elements are not.

 
A100:

Critical error during execution

Result: EX5 loading failed

Thank you for your message. Corrected.

 

Why is it impossible to perform optimisation in the tester

input int      inData        = -1;

from -2147483648 to 2147483647 in increments of 1 ?


ZS: in general I'm not interested in why, but how to do genetic optimization for 32 bit value, in EA code bit by bit input parameters I use, i.e. I want to be able to optimize from -2147483648 to 2147483647 in increments of 1 ?

 
Igor Makanu:

ZS: in general the interesting question is not why, but how to do genetic optimization for 32 bit value, in EA code bit by bit input parameters are used, i.e. I want to be able to optimize from -2147483648 to 2147483647 in steps of 1 ?

input ushort inNum1 = USHORT_MAX;
input ushort inNum2 = USHORT_MAX;

const uint Num = (uint)inNum1 << (sizeof(inNum1) * 8) | inNum2;

void OnInit() {}


 
fxsaber:


I know how many passes it is to optimise

the question is not the number of passes ( - I do not hope to pass all passes someday )

the question is, I limit my algorithm to the tester constraints - I set step 2 - then yes, everything works ( minor parameters ( the last bits ) can also be run with such a step in GA )

UPD:

strange how the restriction in the input parameters works:

I put from -2147483648 to 0 with step 2 - OK

set from -2147483648 to 0 in steps of 1 - does not let me optimize

set from -2147483648 to 2147483645 in steps of 2 - OK

going from -2147483648 to 2147483645 in increments of 1 - does not optimize

 
Igor Makanu:

I know how many optimisation passes it is

Variable Num in the source.

1...286828692870287128722873287428752876287728782879288028812882...3190
New comment