A sub-workshop to fill in the FAQ (frequently asked questions). Let's help comrades! - page 14

New comment
 
TheXpert:
And the right thing to do, imho, is always to ask the terminal for the most up-to-date information.

The state of the orders (array) is queried exactly when they need to be handled.

I'm not arguing that we can do without it, and we don't have to get a masiew beforehand. And immediately analyze the state of orders at the place of demand after OrderSelect and filtering out unwanted ones by magician, symbol, etc.

But you argue that the ticket array is a UG. Justify why.

-------------

Taras suggested "ultra" option when all info about order is written to array. I can only agree with this in the position that this all info is not needed. And in the simplified version, for the most part, only tickets are needed.

 
TheXpert:
I wouldn't suggest it. More often than not, an array of tickets is not needed at all. And the right thing to do, imho, is to always ask the terminal for the most up-to-date information possible.
In an array you get information, living conditionally 1 tick. What more "fresh" information do you need? I use my own practice, when I have 2-4 multicurrency accounts (I mean the demo) that don't allow to "disturb the server for unnecessary things".

And in general, this is your and my personal point of view. And the user must always be given the right to choose - whose arguments are more sensible. ;)

P.S. And I only gave MY answer to the question posed in the FAQ. :)

 

OK, IMHO UG because IMHO it is correct to have the most up to date order information. And IMHO you can do without an array of orders 95% of the time.

You want -- add to it, I was just giving my opinion.

 

Let's put it this way:

- In terms of convenience and model abstraction, it is better to use arrays.
- For speeding up the work - without arrays.

The relevance of information has nothing to do with it. In both variants - with or without arrays - the relevance is 100% fresh

 
sergeev:

-------------

Taras suggested the "ultra" option, where all the information about the order is written to the array. I can agree with this only in the position that all this information is not needed. And in the simplified variant mostly only tickets are needed.

Alexey! I'm far from thinking that by introducing this question in FAQ (Getting an array of tickets of "own" orders), you meant about "the position that all this information is not needed" - like to play around?!
Or did I misunderstand something?
 
TarasBY:
Alexey! I'm far from thinking that by introducing this question into FAQ (Getting an array of tickets of "own" orders), you meant the "position that all this information is not needed" - like to play with?!
Or did I misunderstand something?

For some reason, you have included all of the properties in the concept of "your ticket" in addition to the ticket.

But I have definitely made your suggestion as an extension of the "just a ticket" feature.

There is a frequent need for it too, especially when analysing and comparing historical order data.

 
sergeev:


Let's put it this way:

- In terms of convenience and model abstraction, it is better to use arrays.
- For speeding up the work - without arrays.

The relevance of information has nothing to do with it. In both variants - with or without arrays - the relevance is 100% fresh

I wouldn't be too hasty with the second one ("to speed up the work - without arrays").
Simple logic suggests that extra access to the server for "fresh information" is extra time. And it cannot compete in time with fetching the same information from the array.
There is an expert on code speed - Victor (Vinin), his opinion would be interesting!
 
TarasBY:
Regarding the second ("no arrays to speed up work"), I would not be too hasty to be categorical.
Simple logic suggests that extra access to the server for "fresh information" is extra time. And it cannot compete in time with fetching the same information from the array.
There is a code performance expert Victor (Vinin), his opinion would be interesting!

Once again, when working with order properties, there is no server to contact!

In trading, the most important rule is relevance (so as not to turn into the UG that TheXpert wrote about).
So, if you refer to order list at each function and create an array anew, it will definitely cause a slowdown. It will cause array filling.

So, you can only save money on array actualization and repeated OrdeSelect (already on the ticket).

If you have 1-2 working orders, the array is not critical, but if you have 50-100, it's already significant.

 
I will say more: based on my earlier voiced concept of "Reducing server load" (I would call it "Code Speed Optimization" more precisely), I get all prices in a separate array (if I need it for several tools) in the beginning of Start(). And if I need to make a trade operation, I do RefreshRates().

I am not imposing this approach on anyone, I just see the rationale behind it and use this principle in my designs.

P.S. This is not to initiate a dispute on this topic, it is simply an argument to the above.

 
sergeev:

So if you refer to the order list at each function and recreate the array anew, it will definitely lead to a slowdown. Because of the array filling.

Did I say that? The array of ticks is filled once per tick if the EA is working on every tick. And then instead of the usual sampling:
    for (int li_int = li_total - 1; li_int >= 0; li_int--)
    {
        if (OrderSelect (li_int, SELECT_BY_POS))
        {
        .......
        }
    }
I select from
for (int li_TIC = 0; li_TIC < gi_cnt_Tickets; li_TIC++)
{

}

or:
    for (int li_SMB = 0; li_SMB < ArraySize (gsa_Symbols); li_SMB++)
    {
    }
depending on how I feel more comfortable with this or that function.
I must agree that the rationality of this approach is more noticeable in multi-currency systems, which are a minority.
1...789101112131415161718192021...24
New comment