OHLC Bid + OHLC Ask에 대해 OHLC Bid + Spread를 사용하는 것에 찬성하는 주장이 무엇인지 솔직히 대답할 수 있습니까? 5개 대신 8개의 숫자를 저장하시겠습니까(막대 및 기록 형식을 변경하기 어려움)? 이것이 제공되는 기록의 양에 상당한 영향을 줍니까? 아니면 Ask price history가 없을 수도 있습니다. 테스터의 논리가 더 복잡해지나요? 따라서 두 번째 경우에는 훨씬 더 간단합니다. 스프레드라는 개념이 전혀 없습니다. 솔직히 말해서 당신을 막는 것은 무엇입니까?
막대 구조의 크기 는 단말이 소비하는 자원의 양에 비례하여 영향을 미치는 가장 중요한 특성입니다.
저것들. 우리는 히스토리를 다운로드 할 때 트래픽 양이 증가하고 최악의 경우 터미널과 테스터 (에이전트 포함)가 소비하는 메모리를 65 %까지 증가시키는 것에 대해 이야기하고 있습니다. 약 65%만이 당신을 막을 수 없다는 것이 분명합니다. 이유는 분명히 다릅니다.
나는 48바이트를 얻었다:
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; // биржевой объем
};
공매도가 충분하지 않다고 말하는 사람은 먼저 나에게 적어도 한 가지 예를 들도록 하십시오(증권 거래소나 외환은 중요하지 않습니다).
막대 구조의 크기 는 단말이 소비하는 자원의 양에 비례하여 영향을 미치는 가장 중요한 특성입니다.
우리는 항상 자원을 절약하는 작업에 직면해 있으므로 이 형식의 확장은 적합하지 않습니다.
Renat, MqlRates 구조를 최적화하려는 시도가 있었습니까? 예를 들어 현재 정밀도가 소수점 이하 다섯 자리까지로 제한되어 있는 경우 OLHC 값에 대해 이중(8바이트) 정밀도가 필요한 이유는 무엇입니까? 이 값을 메모리의 절반을 차지하는 3 또는 5 int 비트로 정규화하여 저장하지 않는 이유는 무엇입니까?
OHLC Bid + OHLC Ask에 대해 OHLC Bid + Spread를 사용하는 것에 찬성하는 주장이 무엇인지 솔직히 대답할 수 있습니까? 5개 대신 8개의 숫자를 저장하시겠습니까(막대 및 기록 형식을 변경하기 어려움)? 이것이 제공되는 기록의 양에 상당한 영향을 줍니까? 아니면 Ask price history가 없을 수도 있습니다. 테스터의 논리가 더 복잡해지나요? 따라서 두 번째 경우에는 훨씬 더 간단합니다. 스프레드라는 개념이 전혀 없습니다. 솔직히 말해서 당신을 막는 것은 무엇입니까?
막대 구조의 크기 는 단말이 소비하는 자원의 양에 비례하여 영향을 미치는 가장 중요한 특성입니다.
우리는 항상 자원을 절약하는 작업에 직면해 있으므로 이 형식의 확장은 적합하지 않습니다.
MqlRates의 크기:
46바이트와 같습니다(오해가 아니라면).
대체 구조 크기:
76바이트입니다.
저것들. 우리는 히스토리를 다운로드 할 때 트래픽 양이 증가하고 최악의 경우 터미널과 테스터 (에이전트 포함)가 소비하는 메모리를 65 %까지 증가시키는 것에 대해 이야기하고 있습니다. 약 65%만이 당신을 막을 수 없다는 것이 분명합니다. 이유는 분명히 다릅니다.
상대방의 말을 못 믿으면 무슨 말을 하는 겁니까?
MqlRates의 크기:
(오해가 아니라면) 46바이트와 같습니다.
대체 구조 크기:
76바이트입니다.
저것들. 우리는 히스토리를 다운로드 할 때 트래픽 양이 증가하고 최악의 경우 터미널과 테스터 (에이전트 포함)가 소비하는 메모리를 65 %까지 증가시키는 것에 대해 이야기하고 있습니다. 약 65%만이 당신을 막을 수 없다는 것이 분명합니다. 이유는 분명히 다릅니다.
나는 48바이트를 얻었다:
공매도가 충분하지 않다고 말하는 사람은 먼저 나에게 적어도 한 가지 예를 들도록 하십시오(증권 거래소나 외환은 중요하지 않습니다).막대 구조의 크기 는 단말이 소비하는 자원의 양에 비례하여 영향을 미치는 가장 중요한 특성입니다.
우리는 항상 자원을 절약하는 작업에 직면해 있으므로 이 형식의 확장은 적합하지 않습니다.
Renat, MqlRates 구조를 최적화하려는 시도가 있었습니까? 예를 들어 현재 정밀도가 소수점 이하 다섯 자리까지로 제한되어 있는 경우 OLHC 값에 대해 이중(8바이트) 정밀도가 필요한 이유는 무엇입니까? 이 값을 메모리의 절반을 차지하는 3 또는 5 int 비트로 정규화하여 저장하지 않는 이유는 무엇입니까?
이 방법을 사용하여 쓸 수 있는 최대값은 42949.67295입니다.
이 경계를 넘어 갈 forex OLHC 데이터가 있습니까?
이 경계를 넘어 갈 forex OLHC 데이터가 있습니까?
나는 48바이트를 얻었다:
공매도가 충분하지 않다고 말하는 사람은 먼저 나에게 최소한 한 가지 예를 들도록 하십시오(증권 거래소나 외환은 중요하지 않습니다).저것들. 우리는 히스토리 다운로드시 트래픽 양이 증가 하고 최악의 경우 터미널과 테스터 (에이전트 포함)가 소비하는 메모리를 65 %까지 증가시키는 것에 대해 이야기하고 있습니다.
Vladix :
예를 들어 OLHC 값에 대해 이중(8바이트) 정밀도가 필요한 이유는 .....................................
여기 있습니다, 예.
로 대체될 수 있습니다.인명 피해는 없을 것입니다. 그런 다음 크기는 마술처럼 46바이트로 되돌아갑니다. 대단해, 그렇지? :)
나는 48바이트를 얻었다:
공매도가 충분하지 않다고 말하는 사람은 먼저 나에게 최소한 한 가지 예를 들도록 하십시오(증권 거래소나 외환은 중요하지 않습니다).