Un subtaller para completar las FAQ (preguntas frecuentes). ¡Ayudemos a los compañeros! - página 14

[---]

TheXpert:
Y lo correcto, en mi opinión, es pedir siempre al terminal la información más actualizada.

El estado de los pedidos (array) se consulta precisamente cuando hay que gestionarlos.

No sostengo que podamos prescindir de ella, ni que necesitemos una masiew de antemano. Y analizar inmediatamente el estado de los pedidos a la carta después de OrderSelect y filtrar los no deseados por mago, símbolo, etc.

Pero usted sostiene que la matriz de billetes es una UG. Justifique por qué.

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

Taras sugirió la opción "ultra" cuando toda la información sobre el pedido se escribe en el array. Sólo puedo estar de acuerdo con esto en la posición de que toda esta información no es necesaria. Y en la versión simplificada, en su mayor parte, sólo se necesitan billetes.

[TarasBY]

TheXpert:
Yo no lo sugeriría. En la mayoría de los casos, no se necesita una serie de entradas. Y lo correcto, en mi opinión, es pedir siempre al terminal la información más actualizada posible.

En un array se obtiene información, viviendo condicionalmente 1 tick. ¿Qué más información "fresca" necesitas? Yo uso mi propia práctica, cuando tengo 2-4 cuentas multidivisas (me refiero a la demo) que no permiten "molestar al servidor" por cosas innecesarias.

Y en general, este es su punto de vista personal y el mío. Y siempre hay que dar al usuario el derecho a elegir, cuyos argumentos son más sensatos. ;)

P.D. Y sólo he dado MI respuesta a la pregunta planteada en las FAQ. :)

[TheXpert]

OK, IMHO UG porque IMHO es correcto tener la información más actualizada del pedido. Y, en mi opinión, se puede prescindir de una serie de órdenes el 95% de las veces.

Quieres... añadir algo, yo sólo estaba dando mi opinión.

[---]

Digámoslo así:

- En términos de conveniencia y abstracción del modelo, es mejor usar arrays.
- Para acelerar el trabajo - sin matrices.

La relevancia de la información no tiene nada que ver. En ambas variantes -con o sin matrices- la relevancia es 100% fresca

[TarasBY]

sergeev:

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

Taras sugirió la opción "ultra", en la que toda la información sobre el pedido se escribe en el array. Puedo estar de acuerdo con esto sólo en la posición de que toda esta información no es necesaria. Y en la variante simplificada, la mayoría de las veces sólo se necesitan billetes.

Alexey! Estoy lejos de pensar que al introducir esta pregunta en las FAQ (Obtención de una matriz de tickets de órdenes "propias"), te referías a "la posición de que toda esta información no es necesaria" - como para jugar?
¿O he entendido algo mal?

[---]

TarasBY:
Alexey! Estoy lejos de pensar que al introducir esta pregunta en las FAQ (Obtención de un conjunto de tickets de órdenes "propias"), te referías a la "posición de que toda esta información no es necesaria" - ¡como para jugar!
¿O he entendido algo mal?

Por alguna razón, ha incluido todas las propiedades en el concepto de "su billete" además del billete.

Pero definitivamente he hecho tu sugerencia como una extensión de la función "sólo un billete".

También se necesita con frecuencia, sobre todo cuando se analizan y comparan los datos históricos de los pedidos.

[TarasBY]

sergeev:

Digámoslo así:

- En términos de conveniencia y abstracción del modelo, es mejor usar arrays.
- Para acelerar el trabajo - sin matrices.

La relevancia de la información no tiene nada que ver. En ambas variantes -con o sin matrices- la relevancia es 100% fresca

Sobre la segunda ("acelerar el trabajo - sin arrays"), yo no me precipitaría.
La simple lógica sugiere que el acceso extra al servidor para obtener "información fresca" es un tiempo extra. Y no puede competir en tiempo con la obtención de la misma información de la matriz.
Hay un experto en la velocidad del código - Victor (Vinin), ¡su opinión sería interesante!

[---]

TarasBY:
Sobre lo segundo ("no hay matrices para agilizar el trabajo"), no me apresuraría a ser categórico.
La simple lógica sugiere que el acceso extra al servidor para obtener "información fresca" es un tiempo extra. Y no puede competir en tiempo con la obtención de la misma información de la matriz.
Hay un experto en rendimiento del código, Victor (Vinin), ¡su opinión sería interesante!

Una vez más, al trabajar con las propiedades de los pedidos, no hay ningún servidor con el que contactar.

En el comercio, la regla más importante es la relevancia (para no convertirse en el UG del que escribió TheXpert).
Por lo tanto, si se remite a la lista de órdenes en cada función y se crea un array de nuevo, definitivamente causará una ralentización. Causará el llenado de la matriz.

Así, podemos ahorrar dinero en la actualización de arrays y en la repetición de OrdeSelect (ya en el billete).

Si tienes 1-2 órdenes de trabajo, el conjunto no es crítico, pero si tienes 50-100, ya es significativo.

[TarasBY]

Diré más: basándome en mi concepto anterior de "Reducción de la carga del servidor" (yo lo llamaría más precisamente "Optimización de la velocidad del código"), obtengo todos los precios en un array separado (si lo necesito para varias herramientas) al principio de Start(). Y si necesito hacer una operación comercial, hago RefreshRates().

No estoy imponiendo este enfoque a nadie, simplemente veo la lógica que hay detrás y utilizo este principio en mis diseños.

P.D. Esto no es para iniciar una disputa sobre este tema, es simplemente un argumento a lo anterior.

[TarasBY]

sergeev:

Por lo tanto, si se consulta la lista de pedidos en cada función y se vuelve a crear la matriz, se producirá definitivamente una ralentización. Por el llenado de la matriz.

¿He dicho eso? El array de ticks se rellena una vez por tick si el EA está trabajando en cada tick. Y entonces, en lugar del muestreo habitual:

    for (int li_int = li_total - 1; li_int >= 0; li_int--)
    {
        if (OrderSelect (li_int, SELECT_BY_POS))
        {
        .......
        }
    }

Selecciono en

for (int li_TIC = 0; li_TIC < gi_cnt_Tickets; li_TIC++)
{

}

o:

    for (int li_SMB = 0; li_SMB < ArraySize (gsa_Symbols); li_SMB++)
    {
    }

dependiendo de cómo me sienta más cómodo con una u otra función.
Estoy de acuerdo en que la racionalidad de este planteamiento se nota más en los sistemas multidivisa, que son una minoría.