Errors, bugs, questions - page 2157

[fxsaber]

Andrey Khatimlianskii:

After selecting "Save Version", the current settings are saved to the built-in MT list, which can be used from the "Load Version" menu. The list is different for each EA.

Is the list temporary?

[Andrey Khatimlianskii]

fxsaber:

Is the list temporary?

In theory, it isn't. But you can delete unwanted versions from the "Delete Version" menu.

[fxsaber]

Andrey Khatimlianskii:

In theory, no. But you can remove unwanted versions from the "Delete Version" menu.

Thank you! Haven't figured out a convenient scenario for using this feature yet.

[Andrey Khatimlianskii]

fxsaber:

Thank you! Haven't yet come up with a convenient scenario to use this feature.

Save promising sets after a test run after optimisation and quickly return to them, for example.

Or just compare 2 sets under different conditions without having to go into the download menu every time.

[fxsaber]

Andrey Khatimlianskii:

Save promising sets after a test run after optimisation and quickly return to them, for example.

Or just compare 2 sets under different conditions without having to go into the download menu every time.

There is no data anywhere about which version is currently loaded. The versions themselves do not contain anything other than the save time in the name. All in all, raw for use.

[Andrey Khatimlianskii]

fxsaber:

There is no indication anywhere of which version is currently loaded. The versions themselves do not contain anything other than the save time in the name. All in all, raw for use.

We take 1 set, save it. We test it and see the results.

Setup 2nd set, save it. Remember that the second one was saved later than the first one (makes sense, doesn't it?). Test it, observe results.

Change instrument/tool/mode/broker. Load the first saved version, test, load the second, test.

I use it this way.

Raw - I agree. But better than nothing.

[A100]

fxsaber:

So it's not justified either.

Unreasonable is when the result is asymmetrical:

typedef void (*fn)();
           void g() { Print( 2 ); }
struct A {
    static void f() { Print( 1 ); } //(1)
};
struct B : A {
    B() { A::f(); B::f(); }
    static fn f;                    //(2)
};
fn B::f = g;                        //(3)
void OnStart() { B b; }

Result:1\2

Now if we swap lines (1) and (2,3), the result is asymmetrical: 2\2

And in C++ the symmetry will be preserved:2\1

Now if lines (2,3) are replaced by

    static void f() { Print( 1 ); } //(4)

then the result in MQL will also be symmetric:2\1

while the last substitution should not in fact have affected the result

[fxsaber]

A100:

Unreasonable is when the result is asymmetrical:

When f=f; can be interpreted ambiguously.

[A100]

fxsaber:

When f=f; can be interpreted ambiguously.

When it is ambiguous(as here), C++ generates a compile-time error rather than solving it for the user

[Konstantin]

fxsaber:

No one seems to be testing on custom tick history. Once you don't test for a few hours, the story disappears. Creepy bug. How people still record something from crypto exchanges to test, I don't understand.

I tried to test as soon as they introduced custom history and faced the same problem and others, but found no feedback, so i gave up ))