완료되었습니다. 그러나 바인딩 기능에는 어떤 직접적인 효과가 있으며, 이는 때때로 부작용으로 작용합니다(단어의 나쁜 의미에서). CopyBuffer (ind_handle,0,0, amount ,FractalsBuffer)를 통해 버퍼는 전체 타임프레임 히스토리 길이가 아니라 부분적으로만 채워집니다. 그러나 ArraySize (FractalsBuffer)는 버퍼의 크기(즉, 점유된 물리적 메모리)가 전체 기록의 막대 수에 해당할 것임을 분명히 확신합니다. 즉, 비효율적인 부분을 포함하여 결국 완전히 활용될 것입니다. 물론 루프에서 버퍼 값으로 작업하는 경우 전체 버퍼를 빗질할 필요가 전혀 없으며 필요한 경계를 설정하고 그 안에서 작업하는 것으로 충분합니다. 그러나 첫째, 이것은 엄청난 메모리 재할당 을 취소하지 않으며 둘째, 코드에서 불가피한 ArrayInitialize 함수는 필요한 값으로 버퍼의 부분 초기화를 허용하지 않으므로완료 하는 데 시간과 와트를 소비해야 합니다 . 재초기화. 이로 인해 표시기가 눈에 띄게 느려집니다 . 그리고 세 번째로 ArrayResize 함수에 대한 설명에서 인용 및 참조: "SetIndexBuffer() 함수에 의해 표시기 버퍼로 할당된 동적 배열의 크기를 변경할 수 없다는 점을 염두에 두어야 합니다."ArrayResize를사용하여 버퍼 크기를 수동으로 조작하면 표시기 그래픽 자체가 축소됩니다.
회복 비법을 알려주세요. 또는 이것을 언어 자체의 주어진 문제를 해결하기 위한 요청으로 간주하십시오.
1. 실제로: 아이디어 수준에서 이 작업을 한 번만 수행하는 것이 합리적이지만 실제로는 모든 것이 그렇게 간단하지 않고 모든 것이 실제로 실행되고 있습니다. 방금 표준 표시기에서 복사하여 붙여넣었습니다: C:\Program Files\MetaTrader 5\MQL5\Indicators\Examples\Fractals.mq5 . 새롭고 더 효율적인 방법으로 새 계산 전에 버퍼를 지우는 방법을 모르겠습니다.
2. 아직 이 가능성에 익숙해질 시간이 없었지만 불필요한 영역에 표시기를 미리 그리지 않은 것처럼 보이지만 표시기 버퍼 자체의 크기를 제한하지는 않습니다. 또한 여유 여백 없이 유용한 데이터로 연속적으로 채워진 버퍼로 작업하는 것이 근본적으로 더 편리합니다. 그렇지 않으면 경계를 도입해야 합니다(이전 게시물에서 언급함) 일반적인 아늑한 Orthodox 알고리즘에 맞지 않음: 4개의 버퍼 중 3개는 동일한 경계를 가진 하나의 주기로 빗질될 것이며, 하나는 과시하고 다른 경계를 가진 별도의 곡선 주기를 만들어야 합니다. 또 다른. 예, 목발로 기어 다닐 수도 있습니다 ...
3. 명시적으로 무엇을 의미합니까? 나는 내가 명시적으로 할당하지 않은 것을 절대 보증하지 않습니다. 명시적으로 할당하는 것이 좋습니다. 설명하다? 새로운 값만 불러오는 것 - 당연히 사용하는데 여기서는 검소한 알고리즘이라고 합니다.
4. 나는 이전 포스트를 쓰기 전에도 이 아이디어를 기각했습니다. 지표에는 역사의 마지막(새) 막대가 몇 개 필요하고 개인적으로(시각적 측면) 모든 막대 또는 거의 모든 막대가 필요하기 때문입니다. 역사에서 막대기에 대한 나의 인간적 관심은 그것들에 대한 기술적 지표의 관심보다 더 넓습니다. 막대에 감탄하고 같은 차트 내에서 지표를 그리고 싶습니다. 변덕? 평범한 필요.
1. 실제로: 아이디어 수준에서 이 작업을 한 번만 수행하는 것이 합리적이지만 실제로는 모든 것이 그렇게 간단하지 않고 모든 것이 실제로 실행되고 있습니다. 방금 표준 표시기에서 복사하여 붙여넣었습니다: C:\Program Files\MetaTrader 5\MQL5\Indicators\Examples\Fractals.mq5 . 새롭고 더 효율적인 방법으로 새 계산 전에 버퍼를 지우는 방법을 모르겠습니다.
if (prev_calculated< 7 )// if (prev_calculated==0)// if (prev_calculated<1)// вопщем одинаково)
//Initialize только при первом запуске. нуу или при случае какогнить ахтунга)
{
limit= 2 ;//цикл начинается со второго элемента индикаторного массива
//--- clean up arrays //в принципе здесь не очистка массива,
//а значения EMPTY_VALUE присваивается 0 и 1 элементу массивов, мм.. и на последних трёх барах)
//остальные определяются далее в цикле..
ArrayInitialize (ExtUpperBuffer, EMPTY_VALUE );
ArrayInitialize (ExtLowerBuffer, EMPTY_VALUE );
}
else limit=rates_total- 5 ;//иначе - в цикле пересчитываются только два последних значения
//зы: при появлении нового бара - новый элемент массива вроде как не определен, насколько мне известно не гарантируется, что он будет == EMPTY_VALUE
2. 아직 이 가능성에 익숙해질 시간이 없었지만 불필요한 영역에 표시기를 미리 그리지 않은 것처럼 보이지만 표시기 버퍼 자체의 크기를 제한하지 않습니다. 또한 여유 여백 없이 유용한 데이터로 연속적으로 채워진 버퍼로 작업하는 것이 근본적으로 더 편리합니다. 그렇지 않으면 경계를 도입해야 합니다(이전 게시물에서 언급함) 일반적인 아늑한 Orthodox 알고리즘에 맞지 않음: 4개의 버퍼 중 3개는 동일한 경계를 가진 하나의 주기로 빗질될 것이며, 하나는 과시하고 다른 경계를 가진 별도의 곡선 주기를 만들어야 합니다. 또 다른. 예, 목발로 기어 다닐 수도 있습니다 ...
네, 맞습니다.
표시기 버퍼의 크기는 막대 수에 의해서만 결정됩니다.
하나의 fi, 어떤 크기는 설정해야 합니다.. 같은 경계로 직선으로 할 수 있는데 왜 다른 경계와 함께 곡선 주기를 만드나요?)
주기의 크기를 설정하고 배열의 크기에 춤을 추지 않는 것이 정통입니다. 그렇지 않으면 표시기가 목발을 기준으로 합니다.
3. 명시적으로 무엇을 의미합니까? 나는 내가 명시적으로 할당하지 않은 것을 절대 보증하지 않습니다. 명시적으로 할당하는 것이 좋습니다. 설명하다? 새로운 값만 불러오는 것 - 당연히 사용하는데 여기서는 검소한 알고리즘이라고 합니다.
//---- Upper Fractalif (High[i]>High[i+ 1 ] && High[i]>High[i+ 2 ] && High[i]>=High[i- 1 ] && High[i]>=High[i- 2 ])
ExtUpperBuffer[i]=High[i];//условие выполняется - присваиваем значение
else ExtUpperBuffer[i]= EMPTY_VALUE ;//не выполняется - таки тоже присваиваем значение)
//нет зависимости от Initialize, всем элементам в цикле явно присваивается значение.
경제적인 알고리즘에 관해서 - 나는 당신이 무엇을 사용하고 있는지 잘 모르겠습니다.
모든 막대에 대해 표시기는 한 번 계산됩니다. 거대한 역사를 시작할 때 약간 느려질 수 있습니다.
당신은 더 넓게 볼 필요가 있습니다 (c)
클라우드를 통해 별도의 실행을 시작하는 데 금기 사항은 없습니다(아마도 가격 제외).
클라우드에서 단일 실행은 많은 경우 로컬 커널에서보다 느립니다.
문제가 있었습니다.
OnCalculate() 의 표시기 코드에는 다음 줄이 포함됩니다(더 정확하게는 몇 가지 유사한 줄).
FractalsBuffer는 보조 계산이 아니지만 그래픽 구성 을 직접 담당하는 주 버퍼이므로 연결해야 합니다.완료되었습니다. 그러나 바인딩 기능에는 어떤 직접적인 효과가 있으며, 이는 때때로 부작용으로 작용합니다(단어의 나쁜 의미에서). CopyBuffer (ind_handle,0,0, amount ,FractalsBuffer)를 통해 버퍼는 전체 타임프레임 히스토리 길이가 아니라 부분적으로만 채워집니다. 그러나 ArraySize (FractalsBuffer)는 버퍼의 크기(즉, 점유된 물리적 메모리)가 전체 기록의 막대 수에 해당할 것임을 분명히 확신합니다. 즉, 비효율적인 부분을 포함하여 결국 완전히 활용될 것입니다. 물론 루프에서 버퍼 값으로 작업하는 경우 전체 버퍼를 빗질할 필요가 전혀 없으며 필요한 경계를 설정하고 그 안에서 작업하는 것으로 충분합니다. 그러나 첫째, 이것은 엄청난 메모리 재할당 을 취소하지 않으며 둘째, 코드에서 불가피한 ArrayInitialize 함수는 필요한 값으로 버퍼의 부분 초기화를 허용하지 않으므로 완료 하는 데 시간과 와트를 소비해야 합니다 . 재초기화. 이로 인해 표시기가 눈에 띄게 느려집니다 . 그리고 세 번째로 ArrayResize 함수에 대한 설명에서 인용 및 참조: " SetIndexBuffer () 함수에 의해 표시기 버퍼로 할당된 동적 배열의 크기를 변경할 수 없다는 점을 염두에 두어야 합니다 . " ArrayResize 를 사용하여 버퍼 크기를 수동으로 조작하면 표시기 그래픽 자체가 축소됩니다.
회복 비법을 알려주세요. 또는 이것을 언어 자체의 주어진 문제를 해결하기 위한 요청으로 간주하십시오.왠지 FSE가 실행되고 있습니다..
1. 시작 시 버퍼를 한 번 초기화하는 것이 합리적입니다. if(prev_calculated==0)
2. 다음과 같이 데이터를 그릴 막대를 설정할 수 있습니다. PlotIndexSetInteger(0,PLOT_DRAW_BEGIN,rates_total-amount-1);
3. 히스토리 전체에 걸쳐 명시적으로 모든 버퍼 값을 지정하고 새 값만 지정하면 초기화가 필요하지 않습니다.
4. 터미널 설정 에서 창의 바 수를 줄여주세요 :)
왠지 FSE가 실행되고 있습니다..
1. 시작 시 버퍼를 한 번 초기화하는 것이 합리적입니다. if(prev_calculated==0)
2. 다음과 같이 데이터를 그릴 막대를 설정할 수 있습니다. PlotIndexSetInteger(0,PLOT_DRAW_BEGIN,rates_total-amount-1);
3. 히스토리 전체에 걸쳐 명시적으로 모든 버퍼 값을 지정하고 새 값만 지정하면 초기화가 필요하지 않습니다.
4. 터미널 설정 에서 창의 바 수를 줄여주세요 :)
1. 실제로: 아이디어 수준에서 이 작업을 한 번만 수행하는 것이 합리적이지만 실제로는 모든 것이 그렇게 간단하지 않고 모든 것이 실제로 실행되고 있습니다. 방금 표준 표시기에서 복사하여 붙여넣었습니다: C:\Program Files\MetaTrader 5\MQL5\Indicators\Examples\Fractals.mq5 . 새롭고 더 효율적인 방법으로 새 계산 전에 버퍼를 지우는 방법을 모르겠습니다.
2. 아직 이 가능성에 익숙해질 시간이 없었지만 불필요한 영역에 표시기를 미리 그리지 않은 것처럼 보이지만 표시기 버퍼 자체의 크기를 제한하지는 않습니다. 또한 여유 여백 없이 유용한 데이터로 연속적으로 채워진 버퍼로 작업하는 것이 근본적으로 더 편리합니다. 그렇지 않으면 경계를 도입해야 합니다(이전 게시물에서 언급함) 일반적인 아늑한 Orthodox 알고리즘에 맞지 않음: 4개의 버퍼 중 3개는 동일한 경계를 가진 하나의 주기로 빗질될 것이며, 하나는 과시하고 다른 경계를 가진 별도의 곡선 주기를 만들어야 합니다. 또 다른. 예, 목발로 기어 다닐 수도 있습니다 ...
3. 명시적으로 무엇을 의미합니까? 나는 내가 명시적으로 할당하지 않은 것을 절대 보증하지 않습니다. 명시적으로 할당하는 것이 좋습니다. 설명하다? 새로운 값만 불러오는 것 - 당연히 사용하는데 여기서는 검소한 알고리즘이라고 합니다.
4. 나는 이전 포스트를 쓰기 전에도 이 아이디어를 기각했습니다. 지표에는 역사의 마지막(새) 막대가 몇 개 필요하고 개인적으로(시각적 측면) 모든 막대 또는 거의 모든 막대가 필요하기 때문입니다. 역사에서 막대기에 대한 나의 인간적 관심은 그것들에 대한 기술적 지표의 관심보다 더 넓습니다. 막대에 감탄하고 같은 차트 내에서 지표를 그리고 싶습니다. 변덕? 평범한 필요.
1. 실제로: 아이디어 수준에서 이 작업을 한 번만 수행하는 것이 합리적이지만 실제로는 모든 것이 그렇게 간단하지 않고 모든 것이 실제로 실행되고 있습니다. 방금 표준 표시기에서 복사하여 붙여넣었습니다: C:\Program Files\MetaTrader 5\MQL5\Indicators\Examples\Fractals.mq5 . 새롭고 더 효율적인 방법으로 새 계산 전에 버퍼를 지우는 방법을 모르겠습니다.
네, 맞습니다.
표시기 버퍼의 크기는 막대 수에 의해서만 결정됩니다.
하나의 fi, 어떤 크기는 설정해야 합니다.. 같은 경계로 직선으로 할 수 있는데 왜 다른 경계와 함께 곡선 주기를 만드나요?)
주기의 크기를 설정하고 배열의 크기에 춤을 추지 않는 것이 정통입니다. 그렇지 않으면 표시기가 목발을 기준으로 합니다.
경제적인 알고리즘에 관해서 - 나는 당신이 무엇을 사용하고 있는지 잘 모르겠습니다.
모든 막대에 대해 표시기는 한 번 계산됩니다. 거대한 역사를 시작할 때 약간 느려질 수 있습니다.
앞으로 몇 가지 값이 다시 계산됩니다.
표시기의 버그는 무엇입니까??? 그들은 나타났다가 사라집니다. 그리고 별도의 창에 있는 분들만!!!
다음은 표시기가 사라진 순간의 스크린샷입니다. 그들은 사라지고 무작위로 나타납니다. 영상도 있고..
주의, 기본 지표가 사라지고 있습니다!! 이것은 버그가 중요하다는 것을 의미합니다. 사용자는 동일한 문제가 있습니다.
개발자 여러분, 이 버그를 수정하세요 plz, 그렇지 않으면 어떻게든 견고하지 않습니다.
아쉽게도 화면에는 보이지 않습니다.
어떤 서버? 액세스 서버는 무엇입니까? 날짜/시간은? 그 당시에 히스토리 스왑이 있었나요?
지금 반복되는 건가요? 이 날짜에 대한 터미널 로그를 첨부할 수 있습니까?
~에게 개발자는 MQL 5 컴파일러에서 불쾌한 버그(결함)를 발견했습니다.
조건의 건축물을 사용하는 경우 다음 친절한
만약 (상태) ;
{ operator_1
......
연산자_N }
즉, 코드를 컴파일할 때 오류나 경고가 발생하지 않습니다.
하지만 동시에 존재하기 때문에 기호 "; » (공백이 있거나 없는) 조건 직후 그러면 {operator_1…operator_ N }이 항상 실행됩니다.
MQL 4에서는 이 경우 경고가 발생하는데 MQL 5에서도 오류나 경고를 보고 싶습니다! (그렇지 않으면 내 코드에 오류가 무엇인지 알아내는 동안 반나절을 잃었습니다)
관심을 가져 주셔서 감사합니다!
~에게 개발자는 MQL 5 컴파일러에서 불쾌한 버그(결함)를 발견했습니다.
조건의 건축물을 사용하는 경우 다음 친절한
만약 (상태) ;
{ operator_1
......
연산자_N }
즉, 코드를 컴파일할 때 오류나 경고가 발생하지 않습니다.
하지만 동시에 존재하기 때문에 기호 "; » (공백이 있거나 없는) 조건 직후 그러면 {operator_1…operator_ N }이 항상 실행됩니다.
MQL 4에서는 이 경우 경고가 발생하는데 MQL 5에서도 오류나 경고를 보고 싶습니다! (그렇지 않으면 내 코드에 오류가 무엇인지 알아내는 동안 반나절을 잃었습니다)
관심을 가져 주셔서 감사합니다!
이 경우 모든 것이 유효합니다. ; 빈 연산자 입니다.
우리는 귀하의 제안(경고 발령)에 대해 생각할 것이지만, 현재로서는 이것이 최우선 과제가 아닙니다.
이 경우 모든 것이 유효합니다. ; 빈 연산자 입니다.
우리는 귀하의 제안(경고 발령)에 대해 생각할 것이지만, 현재로서는 이것이 최우선 과제가 아닙니다.
MQL4에서와 같이 하는 것을 잊지 않기를 바랍니다. 결국 논리적으로 수행된 것입니다.
잠시만 기다려 주세요. 두 개의 대기 중인 주문이 있습니다(가격, 유형 및 설정 볼륨이 동일함).
가격에 도달하면 둘 다 작동합니다. 이 경우 OnTrade() 이벤트는 어떻게 작동합니까?
특히, 실행된 보류 주문은 하나의 OnTrade() 이벤트에서 기록으로 이동합니까 아니면 두 번의 호출을 깨울 것입니까? (로그에 따르면 어쩐지 전화가 온다)
당신의 답변에 감사드립니다!