도움말을 읽는 방법을 알고 있을 뿐만 아니라 이해하는 경우 정상화와 정상화의 적용 가능성에 대해 완고하게 계속 말하면서 의식적인 선동을 하고 있는 것입니다. 사용의 위험성에 대한 의식적인 선동을 포함합니다.
선동이 있었습니다. 정규화에 대한 반례는 없었다.
누군가가 올바르게 사용하지 않을 수 있다는 사실 외에도.
따라서 엡실론은 잘못 사용될 수 있습니다. 예, 이미 선동에 대해 언급했습니다.
반례가 있었습니다(어쨌든 여기에서 언급했듯이 정규화의 관점에서 차이점도 있습니다). 다시 한 번 반복합니다. 정규화는 복잡한 내용을 자세히 살펴보고 싶지 않은 사람들을 위한 가장 쉬운 방법입니다. 그는 문서를 읽고 이 모든 것을 굳게 믿습니다. 다시 말하지만, 계산 수학의 틀에서 프로그래밍 언어는 중요하지 않습니다. 이러한 권장 사항이 도움말에 작성되었다고 해서 이것이 사실인 것은 아닙니다(그렇지 않으면 그다지 좋아하지 않는 계산 수학 및 엡실론 문제가 없을 것입니다). 담장에도 많은 내용이 적혀 있지만 이것이 궁극의 진실이라는 뜻은 아니다. 귀하는 도움말 옵션에 만족하며 그렇게 할 수 있는 모든 권리가 있습니다. 그러나 이것은 개인의 선택입니다. 그리고 이것이 내가 여기서 전달하려고 했던 모든 문제를 해결한다는 의미는 아닙니다. 그리고 당신이 단순히 이해하고 싶지 않은 것을 선동이라고 생각하는 것(다시 말하지만 이것은 당신의 권리입니다)이 이것이 선동 그 자체라는 것을 의미하지는 않습니다. 나는 여기서 삶의 의미에 대한 수사학적 질문을 하는 것이 아닙니다(그 대답은 선동에 불과합니다). 저는 단지 제가 아직 만나지 못한 것을 알아 내려고 노력하고 있습니다. 반복합니다. 계산하지 않을 때 값이 항상 같으면 좋을 것입니다. 거기에서 동일한 계산 수학에서 무언가를 이끌어내는 것이 가능할 것입니다. 그러나 값도 다를 때(적어도 여기에서는 메가 전문가가 있어야 함) 보편적인 알고리즘을 상상할 수 없습니다.
또한 로봇이 진드기에 대해 작동하지 않으면 한 막대 안에 여러 교차점을 얻는 것이 기본적으로 불가능하다는 것을 이해하고 싶습니다. 이것은 이미 순전히 mql의 미묘함에 기인할 수 있습니다.
추신: 저는 누군가와 근거 없이 논쟁하려고 하는 것이 아닙니다. 저는 제가 항상 우익 천재라고 생각하지 않습니다. 영리하게 글도 제대로 읽지 않고 그냥 쓰려고 하는 게 싫다. 그것은 당신에게 개인적으로 전혀 적용되지 않습니다. 이 문제에 대한 귀하의 도움과 생각에 감사드립니다. 그러나 여전히, IMHO, 문서의 한 가지 관점(이를 확고하게 믿고 다른 의견과 예를 받아들이지 않음)만 고집하고 엡실론을 좋아하지 않을 때 인내에 대해 글을 쓰는 것은 잘못된 것입니다. 이전에 포스트스크립트에 썼던 내용을 Artyom이 이해해주기를 바랍니다. 답글 달아주신 분들 모두 감사드리고 어딘가에서 조금 화나셨다면 죄송합니다.
특정 소수 자릿수에 대한 PPS 정규화는 실제로 동일한 부호의 순서로 엡실론을 도입하는 것과 유사합니다.
PPPS 만약 우리가 그렇게 열띤 토론을 한다면 이 주제에 대한 귀하의 경험을 공유해 주시면 대단히 감사하겠습니다. 왜냐하면 제가 적절한 답변을 받지 못했기 때문입니다(특히 저와 관련된 2번과 3번 항목). 이미 많은 포럼을 거쳤지만 사실상 2번 항목은 불가능하다는 결론에 도달했습니다. 여기에서 mql 개발자는 매우 불편하기 때문에 이에 대해 생각하고 더 큰 유연성을 제공할 수 있었습니다(다른 프로그래밍 언어에서는 프로그램 인터페이스를 동적으로 변경할 수 있지만 여기서는 (()
반례가 있었습니다(어쨌든 여기에서 언급했듯이 정규화의 관점에서 차이점도 있습니다). 다시 한 번 반복합니다. 정규화는 복잡함을 파고들고 싶지 않은 사람들을 위한 가장 쉬운 방법입니다. 그는 문서를 읽고 이 모든 것을 굳게 믿습니다. 다시 말하지만, 계산 수학의 틀에서 프로그래밍 언어는 중요하지 않습니다. 이러한 권장 사항이 도움말에 작성되었다고 해서 이것이 사실인 것은 아닙니다(그렇지 않으면 그다지 좋아하지 않는 계산 수학 및 엡실론 문제가 없을 것입니다). 담장에도 많은 내용이 적혀있지만 이것이 궁극의 진실이라는 뜻은 아니다. 귀하는 도움말 옵션에 만족하며 그렇게 할 수 있는 모든 권리가 있습니다. 그러나 이것은 개인의 선택입니다. 그리고 이것이 내가 여기서 전달하려고 했던 모든 문제를 해결한다는 의미는 아닙니다. 그리고 당신이 단순히 이해하고 싶지 않은 것을 선동이라고 생각하는 것(다시 말하지만 이것은 당신의 권리입니다)이 이것이 선동 그 자체라는 것을 의미하지는 않습니다. 나는 여기서 삶의 의미에 대한 수사학적 질문을 하는 것이 아닙니다(그 대답은 선동에 불과합니다). 저는 단지 제가 아직 만나지 못한 것을 알아 내려고 노력하고 있습니다. 반복합니다. 계산하지 않을 때 값이 항상 같으면 좋을 것입니다. 거기에서 동일한 계산 수학에서 무언가를 이끌어내는 것이 가능할 것입니다. 그러나 값도 다를 때(적어도 여기에서는 메가 전문가가 있어야 함) 보편적인 알고리즘을 상상할 수 없습니다.
또한 로봇이 진드기에 대해 작동하지 않으면 한 막대 안에 여러 교차점을 얻는 것이 기본적으로 불가능하다는 것을 이해하고 싶습니다. 이것은 이미 순전히 mql의 미묘함에 기인할 수 있습니다.
추신: 저는 누군가와 근거 없이 논쟁하려고 하는 것이 아닙니다. 저는 제가 항상 우익 천재라고 생각하지 않습니다. 영리하게 글도 제대로 읽지 않고 그냥 쓰려고 하는 게 싫다. 그것은 당신에게 개인적으로 전혀 적용되지 않습니다. 이 문제에 대한 귀하의 도움과 생각에 감사드립니다. 그러나 여전히, IMHO, 문서의 한 가지 관점(이를 확고하게 믿고 다른 의견과 예를 받아들이지 않음)만 고집하고 엡실론을 좋아하지 않을 때 인내에 대해 글을 쓰는 것은 잘못된 것입니다. 이전에 포스트스크립트에 썼던 내용을 Artyom이 이해해주기를 바랍니다. 답글 달아주신 분들 모두 감사드리고 어딘가에서 조금 화나셨다면 죄송합니다.
특정 소수 자릿수에 대한 PPS 정규화는 실제로 동일한 부호의 순서로 엡실론을 도입하는 것과 유사합니다.
PPPS 만약 우리가 그렇게 열띤 토론을 한다면 이 주제에 대한 귀하의 경험을 공유해 주시면 대단히 감사하겠습니다. 왜냐하면 제가 적절한 답변을 받지 못했기 때문입니다(특히 저와 관련된 2번과 3번 항목). 이미 많은 포럼을 거쳤지만 사실상 2번 항목은 불가능하다는 결론에 도달했습니다. 여기에서 mql 개발자는 매우 불편하기 때문에 이에 대해 생각하고 더 큰 유연성을 제공할 수 있었습니다(다른 프로그래밍 언어에서는 프로그램 인터페이스를 동적으로 변경할 수 있지만 여기서는 그렇지 않습니다((()
저에게 Double 유형의 숫자를 비교할 때 NormalizeDouble 함수를 사용하여 데이터 변환을 사용하는 것은 코드의 특정 조건을 규정할 때 의도한 위치와 방식으로 프로그램 조건을 정확히 트리거하기 위해 문서에 지정된 두 가지 방법 중 하나입니다.제가 앞서 이야기한 내용입니다. 따라서 이것은 단순히 오류를 제거하는 것이 아닙니다. 모든 조건을 충족하기 위해 데이터를 변환하기 위한 이 옵션과 다양한 신중한 옵션.
나는 이것에 대해 이야기했고 이제 막 배우기 시작하는 프로그래밍 언어에 대한 개인적인 실제 경험을 바탕으로 이야기하는 것입니다. 이 때문에 이 스레드에서 반복적으로 제안하는 이 실용적인 방법 을 사용하십시오.
지나가면서 부분적으로 동의하며 이 함수를 사용하는 정규화가 실제 유형의 데이터를 변환하는 측면에서 모든 작업에 가장 쉬운 방법일 수 있다는 점에 이의를 제기하지 않을 것입니다.
그러나 실제 유형의 데이터를 변환할 때 문서에서 권장하는 두 가지 방법 중 어느 것을 적용할지 모두가 스스로 선택합니다.
그리고 이러한 방법 중 하나의 선택은 사람이 필요한 미묘함을 알아 내려고 노력하거나 시도하지 않는 사람 중 하나라는 사실에 대한 정의 기준에 적용되지 않습니다.
내가 엡실론을 좋아하지 않는다는 것은 내 말이 없었습니다. 어떤 방법도 사용하지 않는 것이 반드시 사랑은 아닙니다/사랑이 아닙니다. 예, 그리고 두 가지 중 두 번째 방법 만 사용하면 주장하지 않았습니다.
P./S.: 동시에 만일의 경우를 대비하여 여기에 나열된 두 가지 중 첫 번째 방법으로 실수를비교하는 것은 숫자의 차이를 작은 값과 비교하여 비교 수준을 조정해야 할 때 정규화를 사용하는 것보다 이름이 더 나쁩니다 (두 번째 방법이 나에게 더 편리한 것으로 판명되었으므로 첫 번째 방법은 실제 적용을 위해 더 자세히 고려하지 않았습니다).
즉, 더블 데이터를 변환 할 때 정규화의 관점에서 나는 단순히 첫 번째 방법이 필요하지 않았습니다. 다양한 문제를 해결할 때(비교할 때 뿐만 아니라) NormalizeDouble 기능을 사용하는 것이 편리하기 때문입니다.
이 사이트에는 방대한 지식 기반이 축적되어 있습니다.
사람들은 MQL4 언어를 사용하여 다양한 수준의 복잡성 문제를 해결하고 해결하고 있습니다.
MQL4 언어가 MQL5에 가까워진 후 전자의 가능성이 더욱 높아졌습니다.
이 프로그래밍 언어에 대해 더 잘 알고 여기 사이트에 축적된 지식 기반을 소홀히 해서는 안 된다고 생각합니다. 실제 적용 경험을 축적하십시오. 그래야만 이 프로그래밍 언어와 해당 기능의 모든 응용 프로그램 측면에서 자신 있게 선언할 수 있습니다.
gammaray : 사실 나는 다른 TK를 가지고 있습니다) 그리고 다시, 나는 이미 진드기에 어떤 문제가 있는지 썼습니다. 로봇이 차트에 교차점을 표시하지 않는 경우 로봇이 거래에 참여한 이유를 어떤 식으로든 고객에게 설명하지 않습니다.
각 틱의 0과 첫 번째 막대에서 MA 값을 취한 다음에만 0 막대에서 MA 크로스오버를 찾을 수 있습니다. 0 이 열리는 동안 첫 번째 막대에서 가져옵니다. 거기에서 MA의 값은 이미 첫 번째 막대를 닫을 때의 값이며 형성 순간이 아닌 값입니다. MA의 값을 늦게 읽었으므로 교차점이 보이지 않습니다. 정규화와 관련이 없습니다. 그리고 그건 그렇고, MA는 가격 값을 표시하기 때문에 값을 _Digits로 정규화해야하며 어떤 값 정규화가 필요한지 추측하지 않아야합니다 ...
여기에 있는 모든 것을 보지 못했기 때문에 주제의 틀 내에서 어떤 주장이 주어졌는지 모릅니다. 그러나 나는 우리가 이 게시물 (그리고 이 주제의 앞부분)에서 Artyom의 입장과 일치하는 내 입장 의 증거에 대해 이야기하고 있다고 믿기 때문에, 실수로 작업할 때 하나 또는 다른 방법으로 일반적으로 정규화를 적용하는 데 필요합니다.
스크린샷과 테스트 코드의 변형 포함.
Artyom은 위의 게시물에서 다음과 같이 썼습니다.
И, кстати, раз МА показывают значения цены, то и нормализовать значения нужно до _Digits, а не гадать до какого же значения нормализация нужна...
그리고 나는 또한 이것이 가장 일반적인 작업 영역에서 간단하고 효과적인 방법이라고 생각하기 때문에(많은 사람들처럼, 다른 사람들도 생각합니다), 나는 나 자신으로부터 다음과 같은 작은 추가 사항만 만들 것입니다.
MA 라인을 표시하기 위한 소수 자릿수 또는 소수 자릿수에 기반한 계산(동일한 비교), 소수 자릿수 및 정규화(특정 소수 자릿수로 반올림).
/* 일부 개별 작업의 경우 "예외"가 있을 수 있으며 원하는 결과를 얻기 위해 다양할 수 있습니다(예: 소수점 이하 값을 소수점 이하 값보다 높은 값과 비교). 그러나 이것이 작업을 해결하는 데 필요한 경우 내 관점에서 필요한 경우 위의 방법과 함께 결과 값을 인쇄하고 얻은 값을 시각적으로 비교하는 것이 좋습니다. 차트에 표시되는 렌더링 */
이중 값을 텍스트로 표시해야 하는 경우(Print, Comment, OBJ_LABEL 등을 통해) 숫자가 텍스트로 변환 되므로 DoubleToString 을 사용해야 합니다.
이제 소개 설명에서 명확성을 위해 다음을 수행합니다.
스크린샷:
표준 배송에서 터미널까지 두 개의 MA 라인이 차트에 표시됩니다.
동일한 설정을 가진 MA의 두 개의 작은 세그먼트, 그러나 차트의 소수점 이하 자릿수보다 한 자리 적은 소수점 이하 자릿수( iMA 기능이 적용되는 지표와 코드베이스 에 있는 경우 이 지표가 있는 경우)
이 표시기의 표: MA 값, MA 값과 MA 자체 간의 델타(MA 자체 간의 델타 - 표의 맨 아래 마지막 줄);
위에서 언급한 표준 세트 및 표시기의 MA 값이 있는 터미널의 "데이터 창";
거래 터미널의 "전문가" 로그에 테스트 스크립트의 데이터가 표시되는 것을 알 수 있으며, 그 코드는 아래에 첨부되어 있습니다.
테스트 스크립트 데이터는 iMA 기능을 사용하여 얻은 MA 값입니다(문서에서 실제 유형 작업에 대해 설명된 기능을 사용한 데이터 변환 및 변환 없음).
데이터 창과 차트에서 더 작은 소수점 기호가 있는 선이 현재 값을 세지 않고 차트의 세 번째 막대에 있는 값으로 균등화되었음을 알 수 있습니다. 또한 차트의 소수점 이하 자릿수로 그린 표준 세트에서 터미널까지의 MA 값이 동일하지 않고 차트에서 조금 더 일찍 시각적으로 균등화되었음을 알 수 있습니다.
즉, 첨부된 테스트 스크립트나 자체 코드를 사용하여 스크린샷을 확대하거나 실험을 수행하면 차트와 같은 소수점 이하 자릿수를 가진 MA 선이 조금 더 일찍 교차하는 것을 볼 수 있습니다.
그리고 이것은 이해할 수 있습니다. 유추를 그리면 소수점 이하 자릿수가 1 미만인 선은 두 자리 따옴표로 작성된 선입니다. 세 자리 따옴표가 있는 차트에 표시됩니다. 이를 통해 터미널의 3-5자리 따옴표가 아직 널리 보급되지 않은 "오래된" 시점에서 명확하게 볼 수 있으며 동시에 따옴표의 이점을 소수점 이하 자릿수까지 확장할 수 있습니다. 거래 작업(더 작은 스프레드 포함) .
즉, 소수점 이하 자릿수가 적은 값으로 작성된 라인은 "노이즈"가 적습니다.
그러나 값의 반올림이 적용되지 않으면(이 경우 정규화 함수 사용) 특정 소수점으로 명확하게 제한된 숫자를 얻는 것이 더 문제가 됩니다.
또는 숫자로만 표시되는 경우:
123.4561과 123.4556은 같지 않습니다. 그리고 그들의 차이는 0이 아닙니다.
그러나 반올림하면 첫 번째 숫자와 두 번째 숫자가 모두 123.456과 같게 됩니다. 따라서 그들 사이의 차이는 0과 같습니다.
결과 값을 반올림 할 소수점 이하 자릿수는 해결되는 작업에 따라 다릅니다.
그리고 스크린샷의 "Experts" 잡지에서 문서에 설명된 변환과 결과 값의 변환 없이 iMA를 사용하여 파생된 MA 값을 볼 수 있습니다. 테스트 스크립트의 MA 설정은 차트의 지표 설정과 동일합니다.
두 번째 화면은 변환이 있거나 없는 두 MA 값 사이의 델타를 보여줍니다.
아래는 언급한 대로 작은 테스트 코드입니다. 최적화되어 있지는 않지만 매개변수 변경을 포함하여 MA 값으로 몇 가지 다른 실험을 수행할 수 있습니다.
그 안에 있는 막대의 수는 다음 줄에 설정되어 있습니다.
#define ARRAY_SIZE 9
P./S.: 첨부된 테스트 스크립트를 교체했습니다. 그 옵션은 게시물에 대한 내 간행물에 포함되지 않았습니다. 한 사람이 아닙니다. 죄송합니다.
물론 조언에 감사하지만 스스로 도움을 읽을 수 있습니다. 그리고 다시 말하지만, 계산 수학은 특정 프로그래밍 언어에 얽매이지 않습니다. 여기에서 처리해야 하는 계산 오류가 있습니다.
도움말을 읽는 방법을 알고 있을 뿐만 아니라 이해하는 경우 정상화와 정상화의 적용 가능성에 대해 완고하게 계속 말하면서 의식적인 선동을 하고 있는 것입니다. 사용의 위험성에 대한 의식적인 선동을 포함합니다.
그리고 나는 영리하지 않지만 반례를 제시하고 있습니다(당신이 가장 좋아하는 정규화를 포함하여).
선동이 있었습니다. 정규화에 대한 반례는 없었다.
누군가가 그것을 올바르게 사용하지 않을 수 있다는 사실 외에도.
따라서 엡실론은 잘못 사용될 수 있습니다. 예, 이미 선동에 대해 언급했습니다.
P./S.: 이 게시물은 정규화에 관한 것이므로 이동 평균 은 언급하지 않습니다.
네, 그리고 MA를 사용하는 어드바이저에 따르면 Artyom이 어려운 순간에 저보다 더 잘 도와줄 수 있다고 생각합니다.
모든 눈금에서 교차점을 찾으십시오. 뭐가 문제 야?
두 개의 실수를 비교할 때 아무 것도 정규화할 필요가 없습니다.
숫자가 정말 같으면 같은 방식으로 메모리에 저장됩니다 . 컴퓨터의 존재가 가능한 것은 바로 이 속성 때문입니다.
if(a<b) 또는 if(a==b) 형식의 비교는 어떤 경우에도 정확하며 정규화가 필요하지 않습니다.
그럼에도 불구하고 연구원의 탐구심이 이 규칙에 모순되는 것을 발견하면 그의 기계가 작동하지 않거나 그의 마음이 작동하지 않는 것입니다. 둘 중 하나.
물론, 최소한 때때로 참조 및 문서를 읽어야 하지만(그들도 우리와 같은 휴머노이드에 의해 작성됨), 자신의 건전한 추론도 필요합니다.
도움말을 읽는 방법을 알고 있을 뿐만 아니라 이해하는 경우 정상화와 정상화의 적용 가능성에 대해 완고하게 계속 말하면서 의식적인 선동을 하고 있는 것입니다. 사용의 위험성에 대한 의식적인 선동을 포함합니다.
선동이 있었습니다. 정규화에 대한 반례는 없었다.
누군가가 올바르게 사용하지 않을 수 있다는 사실 외에도.
따라서 엡실론은 잘못 사용될 수 있습니다. 예, 이미 선동에 대해 언급했습니다.
반례가 있었습니다(어쨌든 여기에서 언급했듯이 정규화의 관점에서 차이점도 있습니다). 다시 한 번 반복합니다. 정규화는 복잡한 내용을 자세히 살펴보고 싶지 않은 사람들을 위한 가장 쉬운 방법입니다. 그는 문서를 읽고 이 모든 것을 굳게 믿습니다. 다시 말하지만, 계산 수학의 틀에서 프로그래밍 언어는 중요하지 않습니다. 이러한 권장 사항이 도움말에 작성되었다고 해서 이것이 사실인 것은 아닙니다(그렇지 않으면 그다지 좋아하지 않는 계산 수학 및 엡실론 문제가 없을 것입니다). 담장에도 많은 내용이 적혀 있지만 이것이 궁극의 진실이라는 뜻은 아니다. 귀하는 도움말 옵션에 만족하며 그렇게 할 수 있는 모든 권리가 있습니다. 그러나 이것은 개인의 선택입니다. 그리고 이것이 내가 여기서 전달하려고 했던 모든 문제를 해결한다는 의미는 아닙니다. 그리고 당신이 단순히 이해하고 싶지 않은 것을 선동이라고 생각하는 것(다시 말하지만 이것은 당신의 권리입니다)이 이것이 선동 그 자체라는 것을 의미하지는 않습니다. 나는 여기서 삶의 의미에 대한 수사학적 질문을 하는 것이 아닙니다(그 대답은 선동에 불과합니다). 저는 단지 제가 아직 만나지 못한 것을 알아 내려고 노력하고 있습니다. 반복합니다. 계산하지 않을 때 값이 항상 같으면 좋을 것입니다. 거기에서 동일한 계산 수학에서 무언가를 이끌어내는 것이 가능할 것입니다. 그러나 값도 다를 때(적어도 여기에서는 메가 전문가가 있어야 함) 보편적인 알고리즘을 상상할 수 없습니다.
또한 로봇이 진드기에 대해 작동하지 않으면 한 막대 안에 여러 교차점을 얻는 것이 기본적으로 불가능하다는 것을 이해하고 싶습니다. 이것은 이미 순전히 mql의 미묘함에 기인할 수 있습니다.
추신: 저는 누군가와 근거 없이 논쟁하려고 하는 것이 아닙니다. 저는 제가 항상 우익 천재라고 생각하지 않습니다. 영리하게 글도 제대로 읽지 않고 그냥 쓰려고 하는 게 싫다. 그것은 당신에게 개인적으로 전혀 적용되지 않습니다. 이 문제에 대한 귀하의 도움과 생각에 감사드립니다. 그러나 여전히, IMHO, 문서의 한 가지 관점(이를 확고하게 믿고 다른 의견과 예를 받아들이지 않음)만 고집하고 엡실론을 좋아하지 않을 때 인내에 대해 글을 쓰는 것은 잘못된 것입니다. 이전에 포스트스크립트에 썼던 내용을 Artyom이 이해해주기를 바랍니다. 답글 달아주신 분들 모두 감사드리고 어딘가에서 조금 화나셨다면 죄송합니다.
특정 소수 자릿수에 대한 PPS 정규화는 실제로 동일한 부호의 순서로 엡실론을 도입하는 것과 유사합니다.
PPPS 만약 우리가 그렇게 열띤 토론을 한다면 이 주제에 대한 귀하의 경험을 공유해 주시면 대단히 감사하겠습니다. 왜냐하면 제가 적절한 답변을 받지 못했기 때문입니다(특히 저와 관련된 2번과 3번 항목). 이미 많은 포럼을 거쳤지만 사실상 2번 항목은 불가능하다는 결론에 도달했습니다. 여기에서 mql 개발자는 매우 불편하기 때문에 이에 대해 생각하고 더 큰 유연성을 제공할 수 있었습니다(다른 프로그래밍 언어에서는 프로그램 인터페이스를 동적으로 변경할 수 있지만 여기서는 (()
반례가 있었습니다(어쨌든 여기에서 언급했듯이 정규화의 관점에서 차이점도 있습니다). 다시 한 번 반복합니다. 정규화는 복잡함을 파고들고 싶지 않은 사람들을 위한 가장 쉬운 방법입니다. 그는 문서를 읽고 이 모든 것을 굳게 믿습니다. 다시 말하지만, 계산 수학의 틀에서 프로그래밍 언어는 중요하지 않습니다. 이러한 권장 사항이 도움말에 작성되었다고 해서 이것이 사실인 것은 아닙니다(그렇지 않으면 그다지 좋아하지 않는 계산 수학 및 엡실론 문제가 없을 것입니다). 담장에도 많은 내용이 적혀있지만 이것이 궁극의 진실이라는 뜻은 아니다. 귀하는 도움말 옵션에 만족하며 그렇게 할 수 있는 모든 권리가 있습니다. 그러나 이것은 개인의 선택입니다. 그리고 이것이 내가 여기서 전달하려고 했던 모든 문제를 해결한다는 의미는 아닙니다. 그리고 당신이 단순히 이해하고 싶지 않은 것을 선동이라고 생각하는 것(다시 말하지만 이것은 당신의 권리입니다)이 이것이 선동 그 자체라는 것을 의미하지는 않습니다. 나는 여기서 삶의 의미에 대한 수사학적 질문을 하는 것이 아닙니다(그 대답은 선동에 불과합니다). 저는 단지 제가 아직 만나지 못한 것을 알아 내려고 노력하고 있습니다. 반복합니다. 계산하지 않을 때 값이 항상 같으면 좋을 것입니다. 거기에서 동일한 계산 수학에서 무언가를 이끌어내는 것이 가능할 것입니다. 그러나 값도 다를 때(적어도 여기에서는 메가 전문가가 있어야 함) 보편적인 알고리즘을 상상할 수 없습니다.
또한 로봇이 진드기에 대해 작동하지 않으면 한 막대 안에 여러 교차점을 얻는 것이 기본적으로 불가능하다는 것을 이해하고 싶습니다. 이것은 이미 순전히 mql의 미묘함에 기인할 수 있습니다.
추신: 저는 누군가와 근거 없이 논쟁하려고 하는 것이 아닙니다. 저는 제가 항상 우익 천재라고 생각하지 않습니다. 영리하게 글도 제대로 읽지 않고 그냥 쓰려고 하는 게 싫다. 그것은 당신에게 개인적으로 전혀 적용되지 않습니다. 이 문제에 대한 귀하의 도움과 생각에 감사드립니다. 그러나 여전히, IMHO, 문서의 한 가지 관점(이를 확고하게 믿고 다른 의견과 예를 받아들이지 않음)만 고집하고 엡실론을 좋아하지 않을 때 인내에 대해 글을 쓰는 것은 잘못된 것입니다. 이전에 포스트스크립트에 썼던 내용을 Artyom이 이해해주기를 바랍니다. 답글 달아주신 분들 모두 감사드리고 어딘가에서 조금 화나셨다면 죄송합니다.
특정 소수 자릿수에 대한 PPS 정규화는 실제로 동일한 부호의 순서로 엡실론을 도입하는 것과 유사합니다.
PPPS 만약 우리가 그렇게 열띤 토론을 한다면 이 주제에 대한 귀하의 경험을 공유해 주시면 대단히 감사하겠습니다. 왜냐하면 제가 적절한 답변을 받지 못했기 때문입니다(특히 저와 관련된 2번과 3번 항목). 이미 많은 포럼을 거쳤지만 사실상 2번 항목은 불가능하다는 결론에 도달했습니다. 여기에서 mql 개발자는 매우 불편하기 때문에 이에 대해 생각하고 더 큰 유연성을 제공할 수 있었습니다(다른 프로그래밍 언어에서는 프로그램 인터페이스를 동적으로 변경할 수 있지만 여기서는 그렇지 않습니다((()
저에게 Double 유형의 숫자를 비교할 때 NormalizeDouble 함수를 사용하여 데이터 변환을 사용하는 것은 코드의 특정 조건을 규정할 때 의도한 위치와 방식으로 프로그램 조건을 정확히 트리거하기 위해 문서에 지정된 두 가지 방법 중 하나입니다. 제가 앞서 이야기한 내용입니다. 따라서 이것은 단순히 오류를 제거하는 것이 아닙니다. 모든 조건을 충족하기 위해 데이터를 변환하기 위한 이 옵션과 다양한 신중한 옵션.
나는 이것에 대해 이야기했고 이제 막 배우기 시작하는 프로그래밍 언어에 대한 개인적인 실제 경험을 바탕으로 이야기하는 것입니다. 이 때문에 이 스레드에서 반복적으로 제안하는 이 실용적인 방법 을 사용하십시오.
지나가면서 부분적으로 동의하며 이 함수를 사용하는 정규화가 실제 유형의 데이터를 변환하는 측면에서 모든 작업에 가장 쉬운 방법일 수 있다는 점에 이의를 제기하지 않을 것입니다.
그러나 실제 유형의 데이터를 변환할 때 문서에서 권장하는 두 가지 방법 중 어느 것을 적용할지 모두가 스스로 선택합니다.
그리고 이러한 방법 중 하나의 선택은 사람이 필요한 미묘함을 알아 내려고 노력하거나 시도하지 않는 사람 중 하나라는 사실에 대한 정의 기준에 적용되지 않습니다.
내가 엡실론을 좋아하지 않는다는 것은 내 말이 없었습니다. 어떤 방법도 사용하지 않는 것이 반드시 사랑은 아닙니다/사랑이 아닙니다. 예, 그리고 두 가지 중 두 번째 방법 만 사용하면 주장하지 않았습니다.
이중 유형의 숫자로 작업하는 기능의 실제 적용 측면에서 내 말은 다음 과 같습니다.
P./S.: 문서의 첫 번째 방법은 원칙적으로 스스로 해결한 작업을 기반으로 하는 것을 포함하여 사용하기에 덜 편리한 것으로 판명되었습니다. 따라서 나는 첫 번째 방법에 대한 축적된 경험이 많지 않습니다.
그러나 두 번째 방법을 적용할 때(즉 , 조건 연산자의 표현에서 두 실수의 정규화된 차이를 0 값과 비교할 때) 어떤 문제도 명확하게 발생하지 않았습니다.
그러나 정규화되지 않은 숫자의 비교를 수행했다면(여기서는 첫 번째 방법을 사용하지 않고 포함함을 의미합니다.) 이중 숫자의 비교를 기반으로 한 조건의 잘못된 트리거링이 드러났습니다.
또한, 이 설명은 다음을 이끌었습니다 .
P./S.: 동시에 만일의 경우를 대비하여 여기에 나열된 두 가지 중 첫 번째 방법으로 실수를 비교하는 것은 숫자의 차이를 작은 값과 비교하여 비교 수준을 조정해야 할 때 정규화를 사용하는 것보다 이름이 더 나쁩니다 (두 번째 방법이 나에게 더 편리한 것으로 판명되었으므로 첫 번째 방법은 실제 적용을 위해 더 자세히 고려하지 않았습니다).
즉, 더블 데이터를 변환 할 때 정규화의 관점에서 나는 단순히 첫 번째 방법이 필요하지 않았습니다. 다양한 문제를 해결할 때(비교할 때 뿐만 아니라) NormalizeDouble 기능을 사용하는 것이 편리하기 때문입니다.
이 사이트에는 방대한 지식 기반이 축적되어 있습니다.
사람들은 MQL4 언어를 사용하여 다양한 수준의 복잡성 문제를 해결하고 해결하고 있습니다.
MQL4 언어가 MQL5에 가까워진 후 전자의 가능성이 더욱 높아졌습니다.
이 프로그래밍 언어에 대해 더 잘 알고 여기 사이트에 축적된 지식 기반을 소홀히 해서는 안 된다고 생각합니다. 실제 적용 경험을 축적하십시오. 그래야만 이 프로그래밍 언어와 해당 기능의 모든 응용 프로그램 측면에서 자신 있게 선언할 수 있습니다.
사실 나는 다른 TK를 가지고 있습니다) 그리고 다시, 나는 이미 진드기에 어떤 문제가 있는지 썼습니다. 로봇이 차트에 교차점을 표시하지 않는 경우 로봇이 거래에 참여한 이유를 어떤 식으로든 고객에게 설명하지 않습니다.
각 틱의 0과 첫 번째 막대에서 MA 값을 취한 다음에만 0 막대에서 MA 크로스오버를 찾을 수 있습니다. 0 이 열리는 동안 첫 번째 막대에서 가져옵니다. 거기에서 MA의 값은 이미 첫 번째 막대를 닫을 때의 값이며 형성 순간이 아닌 값입니다. MA의 값을 늦게 읽었으므로 교차점이 보이지 않습니다. 정규화와 관련이 없습니다. 그리고 그건 그렇고, MA는 가격 값을 표시하기 때문에 값을 _Digits로 정규화해야하며 어떤 값 정규화가 필요한지 추측하지 않아야합니다 ...
포럼 참가자 여러분. 포럼에서 분해를 중단하지 마십시오. 주제 주제에 대해서만.
주제를 닫을 수 있다고 생각합니다. 진술의 저자(주제 아님)가 합의에 이르지 못했습니다. 환영받지 못하는 쇼비니즘의 순간들이 있었습니다.
그러나 어느 쪽도 두 번째도 자신의 주장을 입증하지 못했습니다. 그것이 내가 주제를 닫는 이유입니다. 추가 토론은 처벌될 수 있습니다(최대 일일 금지).
정상적인 증거가 제시된다면 환영합니다.
Volodya와 내가 심사 위원이 될 것입니다.
이것은 논의되지 않습니다.
여기에 있는 모든 것을 보지 못했기 때문에 주제의 틀 내에서 어떤 주장이 주어졌는지 모릅니다. 그러나 나는 우리가 이 게시물 (그리고 이 주제의 앞부분)에서 Artyom의 입장과 일치하는 내 입장 의 증거에 대해 이야기하고 있다고 믿기 때문에, 실수로 작업할 때 하나 또는 다른 방법으로 일반적으로 정규화를 적용하는 데 필요합니다.
스크린샷과 테스트 코드의 변형 포함.
Artyom은 위의 게시물에서 다음과 같이 썼습니다.
И, кстати, раз МА показывают значения цены, то и нормализовать значения нужно до _Digits, а не гадать до какого же значения нормализация нужна...
그리고 나는 또한 이것이 가장 일반적인 작업 영역에서 간단하고 효과적인 방법이라고 생각하기 때문에(많은 사람들처럼, 다른 사람들도 생각합니다), 나는 나 자신으로부터 다음과 같은 작은 추가 사항만 만들 것입니다.
MA 라인을 표시하기 위한 소수 자릿수 또는 소수 자릿수에 기반한 계산(동일한 비교), 소수 자릿수 및 정규화(특정 소수 자릿수로 반올림).
/* 일부 개별 작업의 경우 "예외"가 있을 수 있으며 원하는 결과를 얻기 위해 다양할 수 있습니다(예: 소수점 이하 값을 소수점 이하 값보다 높은 값과 비교). 그러나 이것이 작업을 해결하는 데 필요한 경우 내 관점에서 필요한 경우 위의 방법과 함께 결과 값을 인쇄하고 얻은 값을 시각적으로 비교하는 것이 좋습니다. 차트에 표시되는 렌더링 */
이중 값을 텍스트로 표시해야 하는 경우(Print, Comment, OBJ_LABEL 등을 통해) 숫자가 텍스트로 변환 되므로 DoubleToString 을 사용해야 합니다.
이제 소개 설명에서 명확성을 위해 다음을 수행합니다.
스크린샷:
테스트 스크립트 데이터는 iMA 기능을 사용하여 얻은 MA 값입니다(문서에서 실제 유형 작업에 대해 설명된 기능을 사용한 데이터 변환 및 변환 없음).
데이터 창과 차트에서 더 작은 소수점 기호가 있는 선이 현재 값을 세지 않고 차트의 세 번째 막대에 있는 값으로 균등화되었음을 알 수 있습니다. 또한 차트의 소수점 이하 자릿수로 그린 표준 세트에서 터미널까지의 MA 값이 동일하지 않고 차트에서 조금 더 일찍 시각적으로 균등화되었음을 알 수 있습니다.
즉, 첨부된 테스트 스크립트나 자체 코드를 사용하여 스크린샷을 확대하거나 실험을 수행하면 차트와 같은 소수점 이하 자릿수를 가진 MA 선이 조금 더 일찍 교차하는 것을 볼 수 있습니다.
그리고 이것은 이해할 수 있습니다. 유추를 그리면 소수점 이하 자릿수가 1 미만인 선은 두 자리 따옴표로 작성된 선입니다. 세 자리 따옴표가 있는 차트에 표시됩니다. 이를 통해 터미널의 3-5자리 따옴표가 아직 널리 보급되지 않은 "오래된" 시점에서 명확하게 볼 수 있으며 동시에 따옴표의 이점을 소수점 이하 자릿수까지 확장할 수 있습니다. 거래 작업(더 작은 스프레드 포함) .
즉, 소수점 이하 자릿수가 적은 값으로 작성된 라인은 "노이즈"가 적습니다.
그러나 값의 반올림이 적용되지 않으면(이 경우 정규화 함수 사용) 특정 소수점으로 명확하게 제한된 숫자를 얻는 것이 더 문제가 됩니다.
또는 숫자로만 표시되는 경우:
123.4561과 123.4556은 같지 않습니다. 그리고 그들의 차이는 0이 아닙니다.
그러나 반올림하면 첫 번째 숫자와 두 번째 숫자가 모두 123.456과 같게 됩니다. 따라서 그들 사이의 차이는 0과 같습니다.
결과 값을 반올림 할 소수점 이하 자릿수는 해결되는 작업에 따라 다릅니다.
그리고 스크린샷의 "Experts" 잡지에서 문서에 설명된 변환과 결과 값의 변환 없이 iMA를 사용하여 파생된 MA 값을 볼 수 있습니다. 테스트 스크립트의 MA 설정은 차트의 지표 설정과 동일합니다.
두 번째 화면은 변환이 있거나 없는 두 MA 값 사이의 델타를 보여줍니다.아래는 언급한 대로 작은 테스트 코드입니다. 최적화되어 있지는 않지만 매개변수 변경을 포함하여 MA 값으로 몇 가지 다른 실험을 수행할 수 있습니다.
그 안에 있는 막대의 수는 다음 줄에 설정되어 있습니다.
P./S.: 첨부된 테스트 스크립트를 교체했습니다. 그 옵션은 게시물에 대한 내 간행물에 포함되지 않았습니다. 한 사람이 아닙니다. 죄송합니다.
이전에 첨부한 스크린샷을 교체할 필요가 없으므로 그대로 둡니다.