MQL4 마스터에 대한 질문입니다. 다시 Double Compare에 대해. - 페이지 7

 
SK. писал (а):

이 대화는 영원히 계속될 것 같습니다. 새로운 사용자가 적절한 경험과 지식을 얻을 때까지 그는 일반적으로 정규화에 여러 번 걸려 넘어집니다.

아마도 MT5에서는 비교 연산을 수행할 때 실수의 정확도를 소수점 이하 8자리로 강제로 제한하는 것이 합리적입니다(즉, digit=8로 NormalizeDouble ()을 강제 실행).

글쎄, 나는 당신에게서 그것을 기대하지 않았습니다. 결코 아니다!
비교 연산이 반복적으로 사용되는 경우(반복 계산 등) 입력에서 8자로 반올림할 때 출력의 오류는 1에 상응할 수 있습니다.

나는 SmoothedAvarege 계산에 대해 1년 전에 내 응용 프로그램에서 계산한 경험이 있습니다. 그 후에는 복식의 비트 깊이에 닿지 않는 작업 방식을 선택하려고 합니다.
또는, gravity001 이 제안한 대로 INT로 이동합니다(이는 매우 힘든 작업입니다).
 
SK. писал (а):

아마도 MT5에서는 비교 연산을 수행할 때 실수의 정확도를 소수 8자리로 강제로 제한하는 것이 합리적입니다(예: digit=8로 NormalizeDouble ()을 강제 실행).


그러나 단말기는 사용자가 설정한 조작뿐만 아니라 사용자에게 숨겨진 조작으로 인해 속도가 느려집니다. 단순히 ComparePrice 기능을 언어에 도입하는 것이 더 나은 것 같습니다. 그건 그렇고, Irtron과 마찬가지로 Point / 2를 자연스러운 척도로 간주합니다 (Point * 0.5가 더 나을 것입니다). 매번 나누거나 곱하지 않기 위해 이 절반을 미리 정의된 변수로 만들 수 있습니다. 그 동안에는 그렇지 않으며, 이러한 변수를 직접 입력하고 처음 시작할 때 한 번 계산할 수 있습니다. 개발자는 주어진 정밀도로 이중 비교 기능을 만들 수 있지만, 즉 동일한 것이지만 Point / 2 대신 숫자를 사용합니다.
 
Depfy :

보상 잘 받았습니다... :)

부동 소수점 비교 - 차이 계수를 작은 임계값과 비교하여 수행됩니다.

예를 들어 (fabs(d1-d2) < 1e-10)을 반환합니다.

왜 물이 흐려지는가... NormalizeDouble (...) 함수는 아름다운 보고서에 필요하며 그 이상은 아닙니다.

예를 들어 주셔서 감사합니다.
그러나 문제의 본질을 파악하지 못했기 때문에 더 자세히 읽어야 합니다. 질문의 본질은 일반적으로 프로그래밍 스타일이며 MT4의 특정 경우에 있습니다.
 
VBAG :
데피 :

보상 잘 받았습니다... :)

부동 소수점 비교 - 차이 계수를 작은 임계값과 비교하여 수행됩니다.

예를 들어 (fabs(d1-d2) < 1e-10)을 반환합니다.

왜 물이 흐려지는가... NormalizeDouble (...) 함수는 아름다운 보고서에 필요하며 그 이상은 아닙니다.

예를 들어 주셔서 감사합니다.
그러나 문제의 본질을 파악하지 못했기 때문에 더 자세히 읽어야 합니다. 질문의 본질은 일반적인 프로그래밍 스타일과 MT4의 특정 경우입니다.

그리고 그들은 문제의 본질이 무엇인지 말할 것입니다 ... 그렇지 않으면 힌트 - 저는 모릅니다! 이해합니다 :)

우리가 속도에 대해 이야기하고 있다면 현대입니다. 부동 작업은 프로세서에서 수행됩니다.

거의 정수만큼 빠릅니다. STYLE에 관해서는 죄송합니다. 실용주의 규칙 ...

ASHIPS가 주변에 있을 때 우리는 어떤 스타일에 대해 이야기하고 있습니까? ... 효과만 있다면. ..

그리고 두 숫자를 비교하는 것 외에 다른 문제는 없습니다 :))))))))

 
VBAG :
글쎄, 나는 당신에게서 그것을 기대하지 않았습니다. 결코 아니다!
비교 연산이 반복적으로 사용되는 경우(반복 계산 등), 입력에서 8자까지 반올림할 때 출력의 오류는 1에 상응할 수 있습니다.

나는 SmoothedAvarege 계산에 대해 1년 전에 내 응용 프로그램에서 계산한 경험이 있습니다. 그 후에는 복식의 비트 깊이에 닿지 않는 작업 방식을 선택하려고 합니다.
또는, gravity001 에서 제안한 대로 INT로 이동합니다(이는 매우 힘든 작업입니다).


잠깐 기다려요. 성급한 결론은 필요 없습니다.

가장 먼저. 실제 변수 자체의 실제 값을 강제로 반올림하라는 것이 아닙니다. 비교 연산 결과를 계산할 때 변수의 비교 값(사본)을 강제 반올림하는 것을 제안합니다(기본 경우). 물론 변수의 실제 값은 만질 수 없습니다. 이 경우 다른 계산된 값은 영향을 받지 않습니다. 비교 작업에 사용된 변수의 초기 값은 값을 유지하고 순환 계산의 오류는 누적되지 않습니다.

둘째. 나는 더 심각한 결과를 초래하는 오류를 제거하기 위해 이렇게 할 수 있다고 말했습니다. 그러나 훨씬 더 까다로운 계산을 제공하려면 주어진 매개변수와 함께 NormalizeDouble () 함수를 정기적으로 사용할 가능성을 유지해야 합니다.

따라서 내 제안은 언어의 가능성을 제한하지 않고 확장합니다.

또 다른 것은 이러한 변환에 대해 알지 못하는 불운한 사용자가이 경우 이해할 수없는 결과를 얻을 수도 있다는 것입니다. 그러나 비교 작업이 일반적으로 가격 값(즉, 숫자 = 4)을 사용한다는 점을 감안할 때 대부분의 경우 이 오류는 발생하지 않습니다. 따라서 제안된 기술을 사용하면 예측할 수 없는 결과를 초래하는 오류의 수를 줄일 수 있습니다.

 
lna01 :
그 동안에는 그렇지 않으며, 이러한 변수를 직접 입력하고 처음 시작할 때 한 번 계산할 수 있습니다.

금지되어 있습니다.

또는 프로그램 라인을 작성할 수 있지만 그 누구도 (개발자를 포함하여) Expert Advisor의 전체 수명 동안 이 변수의 값이 엄격하게 변경되지 않을 것이라고 보장하지 않습니다. 여기서 요점은 프로그램 코드의 정확성이 아니라 계산의 기술적 특징과 변수 값을 저장하는 기술적 규칙입니다. 이것이 아니었다면 질문이 발생하지 않았을 것입니다.

그리고 현 상황에서 변수 123.00000000000이 계산에 사용되는 시점에서 초기값은 122.999999999999로 판명될 수 있다. 그리고 이것은 변수가 발견된 이후로 그 값이 변경되지 않았음에도 불구하고 프로그램에서 다른 계산에 참여하도록 요청했을 뿐입니다.

사실, 그것이 모든 소란을 일으키는 이유입니다. 그렇기 때문에 NormalizeDouble ()을 실제 계산에 최대한 가깝게, 가급적이면 if, for, while 문의 조건에서 바로 사용해야 합니다.

 
SK. писал (а):
lna01 :
그 동안에는 그렇지 않으며, 이러한 변수를 직접 입력하고 처음 시작할 때 한 번 계산할 수 있습니다.

금지되어 있습니다.

오히려 프로그램 라인을 작성할 수 있지만 그 누구도 (개발자를 포함하여) Expert Advisor의 전체 수명 동안 이 변수의 값이 엄격하게 변경되지 않을 것이라고 보장하지 않습니다. 여기서 요점은 프로그램 코드의 정확성이 아니라 계산의 기술적 특징과 변수 값을 저장하는 기술적 규칙입니다. 이것이 아니었다면 질문이 발생하지 않았을 것입니다.

그리고 현 상황에서 변수 123.00000000000이 계산에 사용되는 시점에서 초기값은 122.999999999999로 판명될 수 있다. 그리고 이것은 변수가 발견된 이후로 그 값이 변경되지 않았음에도 불구하고 프로그램에서 다른 계산에 참여하도록 요청했을 뿐입니다.

사실, 그것이 모든 소란을 일으키는 이유입니다. 그렇기 때문에 NormalizeDouble ()을 실제 계산에 최대한 가깝게, 가급적이면 if, for, while 문의 조건에서 바로 사용해야 합니다.

전나무, 나는 전체 시장이 무엇을위한 것인지 이해하기 시작한 것 같습니다 ...

결국, 나는 아무것도 발명할 필요가 없다고 생각합니다. 그것은 모두 특정 상황에 달려 있기 때문입니다. 목적이 무엇입니까? 두 숫자가 0.1의 가수만큼 다르면 CRITICAL이면 1개의 옥양목입니다. 중요하지 않은 경우 - 다른. 서로 비교하려고 합니다. 그러나 NORMAL 컴파일러가 군더더기 없이 제공하는 FLEXIBILITY는 충분하고 필요한 것, IMHO입니다.

:)

 
SK. писал (а):
여기서 요점은 프로그램 코드의 정확성이 아니라 계산의 기술적 특징과 변수 값을 저장하는 기술적 규칙입니다. 이것이 아니었다면 질문이 발생하지 않았을 것입니다.
컴퓨팅에서는 이것이 사실이지만 스토리지에서는 상황이 더 좋아져야 한다고 생각했습니다. 그리고 숫자 가 4인 경우에도 15번째 기호의 차이가 역할을 해서는 안 됩니다.
 
Depfy :

전나무, 나는 전체 시장이 무엇을위한 것인지 이해하기 시작한 것 같습니다 ...

결국, 나는 아무것도 발명할 필요가 없다고 생각합니다. 그것은 모두 특정 상황에 달려 있기 때문입니다. 목적이 무엇입니까? 두 숫자가 0.1의 가수만큼 다르면 CRITICAL이면 1개의 옥양목입니다. 중요하지 않은 경우 - 다른. 서로 비교하려고 합니다. 그러나 NORMAL 컴파일러가 군더더기 없이 제공하는 FLEXIBILITY는 충분하고 필요한 것, IMHO입니다.

:)


"발명"에 관해서는 대답할 수 없습니다. 어떻게 생각하느냐에 따라 달라지는 것 같습니다. :)

예를 들어 Point/2 유형의 발명품은 실제로 많은 경우에 특정 지정된 정확도로 계산을 수행하는 것을 가능하게 합니다. 그러나 개발자의 권장 사항을 사용하는 것이 좋습니다. 즉, 새 문서가 나올 때까지 비교 작업을 계산할 때 표준 NormalizeDouble () 함수를 사용하는 것을 규칙으로 만드십시오.

 
lna01 :
SK. (a)는 다음과 같이 썼다.
여기서 요점은 프로그램 코드의 정확성이 아니라 계산의 기술적 특징과 변수 값을 저장하는 기술적 규칙입니다. 이것이 아니었다면 질문이 발생하지 않았을 것입니다.
컴퓨팅에서는 이것이 사실이지만 스토리지에서는 상황이 더 좋아져야 한다고 생각했습니다. 예, 숫자가 4인 경우 15번째 기호의 차이가 역할을 해서는 안 됩니다.

NormalizeDouble ()을 사용하면 재생되지 않습니다. 그리고 당신이 사용하지 않는다면 얼마나 운이 좋은지.