¿Puede responder honestamente cuáles son las razones para utilizar OHLC Bid + Spread, frente a OHLC Bid + OHLC Ask? ¿Guardar 8 números en lugar de 5 (el formato de barra e historial es difícil de cambiar)? ¿Tendrá un impacto significativo en la cantidad de historia proporcionada? ¿O tal vez no tiene un historial de precios Ask? ¿Se complica la lógica del probador? Pues bien, en el segundo caso es aún más sencillo: no existe el concepto de dispersión en absoluto. Qué es lo que lo impide, sea sincero.
Eltamaño de la estructura de barras es la característica más significativa que afecta proporcionalmente a la cantidad de recursos consumidos por el terminal.
Siempre nos enfrentamos a la tarea de ahorrar recursos, por lo que la expansión de esta forma no es apropiada.
structMqlRates
{
datetime time; // время начала периодаdouble open; // цена открытияdouble high; // наивысшая цена за периодdouble low; // наименьшая цена за периодdouble close; // цена закрытияlong tick_volume; // тиковый объемint spread; // спредlong real_volume; // биржевой объем
};
Equivale (si no me equivoco) a 46 bytes.
El tamaño de la estructura alternativa:
structMqlRates
{
datetime time; // время начала периодаdouble openBid; // цена открытия Biddouble highBid; // наивысшая цена за период Biddouble lowBid; // наименьшая цена за период Biddouble closeBid // цена закрытия Biddouble openAsk; // цена открытия Askdouble highAsk; // наивысшая цена за период Askdouble lowAsk; // наименьшая цена за период Askdouble closeAsk // цена закрытия Asklong tick_volume; // тиковый объемlong real_volume; // биржевой объем
};
Equivale a 76 bytes.
Es decir, estamos hablando de un aumento del 65% del tráfico durante la descarga del historial y del consumo de memoria del terminal y del probador (incluyendo los agentes) en el peor de los casos. Evidentemente, sólo un 65% no puede detenerte. Las razones son claramente diferentes.
Es decir, estamos hablando de un aumento del 65% del tráfico durante la descarga del historial y del consumo de memoria por parte del terminal y del probador (incluidos los agentes) en el peor de los casos. Evidentemente, sólo un 65% no puede detenerte. Las razones son claramente diferentes.
Tengo 48 bytes:
structMqlRates
{
datetime time; // время начала периодаdouble Base; // базовая цена бара. Все остальные цены отсчитываются от базы в пипсах short openBid; // цена открытия Bidshort highBid; // наивысшая цена за период Bidshort lowBid; // наименьшая цена за период Bidshort closeBid // цена закрытия Bidshort openAsk; // цена открытия Askshort highAsk; // наивысшая цена за период Askshort lowAsk; // наименьшая цена за период Askshort closeAsk // цена закрытия Asklong tick_volume; // тиковый объемlong real_volume; // биржевой объем
};
Quien diga que no basta con ponerse en corto, que sea el primero en lanzarme al menos un ejemplo (de la bolsa o del forex en todo caso).
Eltamaño de la estructura de barras es la característica más significativa que afecta proporcionalmente a la cantidad de recursos consumidos por el terminal.
Siempre nos enfrentamos a la tarea de ahorrar recursos, por lo que una prórroga de esta forma no es apropiada.
Renat, ¿se ha intentado optimizar la estructura deMqlRates? Por ejemplo, ¿por qué necesitamos valores de doble precisión (8 bytes) de OLHC, si la precisión está ahora limitada a un máximo de cinco decimales? ¿Por qué no almacenar estos valores como int normalizados a 3 o 5 dígitos, que ocupan la mitad de memoria?
El valor máximo que se puede escribir con este enfoque es 42949,67295.
¿Existe algún dato de OLHC forex que supere este límite?
Quien diga que el cortocircuito no es suficiente, que sea el primero en lanzarme al menos un ejemplo (de bolsa o forex en todo caso).
hrenfx:
Es decir, estamos hablando de un aumento del 65% en el tráfico de descarga del historial y del consumo de memoria del terminal y del probador (incluidos los agentes) en el peor de los casos.
Está claro que los desarrolladores utilizan una transformación similar de la estructura original antes de comprimir los datos para transferir el historial, lo que da lugar a un enorme ratio de compresión. Pero el hecho es que aunque no hagas nada, nada en absoluto, lo peor que puedes conseguir es un 65% más.
¿Puede responder honestamente cuáles son las razones para utilizar OHLC Bid + Spread, frente a OHLC Bid + OHLC Ask? ¿Guardar 8 números en lugar de 5 (el formato de barra e historial es difícil de cambiar)? ¿Tendrá un impacto significativo en la cantidad de historia proporcionada? ¿O tal vez no tiene un historial de precios Ask? ¿Se complica la lógica del probador? Pues bien, en el segundo caso es aún más sencillo: no existe el concepto de dispersión en absoluto. Qué es lo que lo impide, sea sincero.
Eltamaño de la estructura de barras es la característica más significativa que afecta proporcionalmente a la cantidad de recursos consumidos por el terminal.
Siempre nos enfrentamos a la tarea de ahorrar recursos, por lo que la expansión de esta forma no es apropiada.
El tamaño de MqlRates:
Equivale (si no me equivoco) a 46 bytes.
El tamaño de la estructura alternativa:
Equivale a 76 bytes.
Es decir, estamos hablando de un aumento del 65% del tráfico durante la descarga del historial y del consumo de memoria del terminal y del probador (incluyendo los agentes) en el peor de los casos. Evidentemente, sólo un 65% no puede detenerte. Las razones son claramente diferentes.
Si no crees en las palabras de tu oponente, ¿qué sentido tiene hablar?
El tamaño de MqlRates:
Equivale (si no me equivoco) a 46 bytes.
El tamaño de la estructura alternativa:
Equivale a 76 bytes.
Es decir, estamos hablando de un aumento del 65% del tráfico durante la descarga del historial y del consumo de memoria por parte del terminal y del probador (incluidos los agentes) en el peor de los casos. Evidentemente, sólo un 65% no puede detenerte. Las razones son claramente diferentes.
Tengo 48 bytes:
Quien diga que no basta con ponerse en corto, que sea el primero en lanzarme al menos un ejemplo (de la bolsa o del forex en todo caso).Eltamaño de la estructura de barras es la característica más significativa que afecta proporcionalmente a la cantidad de recursos consumidos por el terminal.
Siempre nos enfrentamos a la tarea de ahorrar recursos, por lo que una prórroga de esta forma no es apropiada.
Renat, ¿se ha intentado optimizar la estructura deMqlRates? Por ejemplo, ¿por qué necesitamos valores de doble precisión (8 bytes) de OLHC, si la precisión está ahora limitada a un máximo de cinco decimales? ¿Por qué no almacenar estos valores como int normalizados a 3 o 5 dígitos, que ocupan la mitad de memoria?
El valor máximo que se puede escribir con este enfoque es 42949,67295.
¿Existe algún dato de OLHC forex que supere este límite?
¿Existen datos de la OLHC sobre el mercado de divisas que vayan más allá de este límite?
Tengo 48 bytes:
Quien diga que el cortocircuito no es suficiente, que sea el primero en lanzarme al menos un ejemplo (de bolsa o forex en todo caso).Es decir, estamos hablando de un aumento del 65% en el tráfico de descarga del historial y del consumo de memoria del terminal y del probador (incluidos los agentes) en el peor de los casos.
Vladix:
Por ejemplo, ¿por qué se necesita una precisión doble (8 bytes) para los valores OLHC si .....................
Por cierto, eso es SÍ.
podría muy bien ser sustituido pory no habrá NADIE afectado. entonces el tamaño vuelve a ser mágicamente de 46 bytes. bonito, no es así :)
Tengo 48 bytes:
Quien diga que el cortocircuito no es suficiente, que sea el primero en lanzarme al menos un ejemplo (de bolsa o forex en todo caso).