신규유저 들 에게 똑같은걸 1000번씩 설명 해줘야 하는 개발자분들께 심심한 위로의 말씀을 전합니다..
이미 노골적인 배신이다...
동의한다. 비록 SK. 포럼에 대한 권위가 있지만 "특정 컴퓨터 기술"도 나에게 의심을 불러일으킵니다. 메모리에 실수를 저장하는 것은 교과서에 기록되어 있으며 변수가 스스로 변할 수 있다는 사실에 대해서는 아무 말도 없습니다. 이 포럼에서 나는 SK에서만 그런 이야기를 들은 것이 아닙니다. 따라서 모든 신규 사용자를 1000번 잘못 인도했다면 이제 해당 사용자를 찾아 내 말에 대해 사과해야 합니다!
나는 Simca 에 동의합니다. 산술 연산 을 수행할 때 결함이 있을 수 있지만 저장, 쓰기 또는 읽기에서는 제외됩니다!
그래서 NormalizeDouble() 함수의 알고리즘에 질문했습니다. 아마도 오류로 이어지는 산술 연산도 있을 수 있습니까? 심카 는 어떻게 생각하세요?
얼마 전까지는 256MB RAM이 장착된 구형 PC에서 작업해야 했습니다. 여러 프로그램을 로드할 때 운영 체제는 데이터의 일부를 디스크로 언로드한 다음 다시 로드했습니다. 코드를 변경한 이후(비교 연산자의 정규화를 나타냄) 오류가 더 이상 나타나지 않습니다. 그러나 당신의 말 후에 나는 이미 의심했습니다. 내가 정말로 거기에서 무언가를 수정하고 그것을 눈치 채지 못했다면 어떨까요?
gravity001 : 메모리에 실수를 저장하는 것은 교과서에 기록되어 있으며 변수가 스스로 변할 수 있다는 사실에 대해서는 아무 말도 없습니다. 이 포럼에서 나는 SK에서만 그런 이야기를 들은 것이 아닙니다.
저장될 때 자체적으로는 아무 것도 변경되지 않습니다 . 그러나 컴퓨터 메모리에서 실수가 표현되는 방식은 저장된 값의 정확도 (자릿수 용량)에 영향을 미칩니다. 실수를 사용한 산술 연산에서 결과는 종종 "충분히 정확하지 않은"(인간의 관점에서 볼 때), 그래서 때때로 연산 결과를 정규화해야 합니다. 같은지 (종종 > , < 에도 해당 ) 후속 비교 동안 연산 결과를 정규화해야 합니다. 또한 필요한 하드 코딩된 비트 깊이 (예 : 가격 )가 있는 값으로 작업하는 경우 결과를 정규화해야 합니다. 그 자체로 실수를 사용한 중간 계산에는 원칙적으로 정규화가 필요하지 않습니다. 그러나이 모든 것은 계산을 참조하지만 값은 정규화 여부에 관계없이 변경되지 않고 메모리에 저장됩니다.
중력001 : 그래서 NormalizeDouble () 함수의 알고리즘에 질문했습니다. 아마도 오류로 이어지는 산술 연산도 있을 수 있습니까? 심카 는 어떻게 생각하세요?
글쎄, NormalizeDouble 함수의 알고리즘에 대해서는 내가 아닌 개발자에게 물어봐야합니다. :) 게다가, 이것은 NormalizeDouble 함수가 절대적으로 동일한 애플리케이션의 두 코드 조각에 모두 나타났기 때문에 분쟁의 주제에는 적용되지 않습니다. 유일한 차이점은 두 정규화의 결과를 직접 비교하는 것과 이러한 결과를 변수에 미리 작성한 다음 변수의 값을 비교하는 것입니다. NormalizeDouble 함수에 의해 반환된 값의 유형이 저장에 사용된 변수의 유형과 일치하기 때문에 위의 조각 간에 차이가 없음을 알았습니다. 이제 NormalizeDouble 함수가 자신이 배치된 변수보다 더 큰 비트 깊이 값을 반환하면 차이가 나타날 수 있으며 identity 에 대해 이야기하는 것은 확실히 불가능합니다 . 그러나 MetaEditor의 HELP로 판단하면 두 경우 모두 데이터 유형이 double 이므로 NormalizeDouble 함수가 구현되는 방식에 관계없이 차이가 없어야 합니다.
그러나 이것은 각각의 새로운 사용자에게 적용되는 것과 같이 저는 절대적으로 동의합니다 . 그것이 무엇이며 어떻게 작동하는지에 대한 명확한 아이디어가 없다면 더 안전하고 신뢰할 수있는 경로를 따르는 것이 가장 합리적입니다! 그러나 그것은 당신과 나에게 적용되지 않습니다. :) 그리고 내 입장에서는(문제의 본질을 완전히 이해하지 못하는 사람들을 위해) 다음을 추천할 수도 있습니다.
(그러나 여전히 다음과 같은 경우 직접 정규화하는 것이 좋습니다. 비교 연산을 계산합니다 :)
죄송하지만 효율성 면에서 정규화가 필요한 데이터 비교를 위한 훨씬 더 나은 구현이 있습니다. 일반적으로 이것은 표준(비교 알고리즘)입니다. 스케일의 절반 치수와의 차이를 비교할 필요가 있습니다. 무슨 말입니까: 가격을 비교하려면(차이가 있든 없든) 차이를 가져와 0.5*Roint 값과 비교해야 합니다(expert\script\indicator 초기화 중에 한 번만 계산할 수 있음) 이것은 하나의 함수를 호출하는 것보다 훨씬 더 효율적이며 두 개를 호출하는 것보다 훨씬 더 효율적입니다.
mql4의 더블 비교 연구. 첫째, 복식으로 작업하는 것은 순전히 컴파일러 트릭이므로 본질적으로 인터프리터가 있는 스크립트인 mql4에서 편의를 요구하는 것은 적절하지 않습니다. 메인, 개발자가 길을 냈고 비교의 정확한 결과를 보장하고 펜으로 확인했습니다. 물론 문법이지만 작동 중입니다 !!! 문서에 "!=" 또는 "=="의 경우 전류를 정규화해야 한다고 명시되어 있지만, 당사의 독립적인 전문가 테스트에 따르면 (a>b) a가 회전하는 경우 올바른 결과를 보장하지 않습니다(!) b와 같도록! 와 b를 모두 정규화하더라도 숫자가 같으면 결과를 예측할 수 없습니다. 그러나 개발자의 구조::: NormalizeDouble (ab, Digits)>0은 안정적으로 작동합니다! 뽕나무 동지들이 왜 정규화 기능을 좋아하지 않았는지 모르겠습니다... 아마도 (INSIDE)는 다음과 같이 상당히 의미론적으로 수행됩니다. 그리고 그 후 - 전체는 문제가 없습니다.
.FG писал (а): mql4의 더블 비교 연구. 첫째, 복식으로 작업하는 것은 순전히 컴파일러 트릭이므로 본질적으로 인터프리터가 있는 스크립트인 mql4에서 편의를 요구하는 것은 적절하지 않습니다. 메인, 개발자가 길을 냈고 비교의 정확한 결과를 보장하고 펜으로 확인했습니다. 물론 문법이지만 작동 중입니다 !!! 문서에 "!=" 또는 "=="의 경우 전류를 정규화해야 한다고 명시되어 있지만, 당사의 독립적인 전문가 테스트에 따르면 (a>b) a가 회전하는 경우 올바른 결과를 보장하지 않습니다(!) b와 같도록! 와 b를 모두 정규화하더라도 숫자가 같으면 결과를 예측할 수 없습니다. 그러나 개발자의 구조::: NormalizeDouble (ab, Digits)>0은 안정적으로 작동합니다! 뽕나무 동지들이 왜 정규화 기능을 좋아하지 않았는지 모르겠습니다... 아마도 (INSIDE)는 다음과 같이 상당히 의미론적으로 수행됩니다. 그리고 그 후 - 전체는 문제가 없습니다.
개발자 사이트(러시아어)에 대한 링크를 제공하고 저자의 정의만 사용할 것을 약속합니다. :) 내 생각에 당신의 언어는 나보다 정확하지 않지만 개인적으로 이해하지 못한다면 전문가 평가에서 blah blah를 분리할 수 없다면 "for Rosh"로 번역하겠습니다. 너한테 쓴게 아니라 1001번째 신인한테 쓴거니까. :)
.FG писал (а): 개발자 사이트(러시아어)에 대한 링크를 제공하면 저자의 정의만 사용할 것을 약속합니다. :) 내 생각에 당신의 언어는 나보다 더 정확하지 않지만 당신이 개인적으로 그것을 이해하지 못한다면 전문가 평가와 blah blah를 분리할 수 없다면 "for Rosh"로 번역하겠습니다. 너한테 쓴게 아니라 1001번째 신인한테 쓴거니까. :)
이 경우 stringo는 프로그래밍 성공에 대한 명예 인증서와 함께 Cyril과 Methodius에 갈 것입니다! :) 당신은 동료의 떼를 고쳤지만 그들은 메아리에 만족하지 않았습니다. 나는 현재 버전에서 편리한 방식으로 오랫동안 구현되어온 무료 DOS 컴파일러의 정규화로 이러한 모든 문제를 만났습니다. 따라서 일부 프로그래머는 이러한 홍수 전 복식 검사를 이해하지 못합니다. 그들이 코드를 다시 작성하고 모든 곳에서 0에 비해 normalize를 쌓을 때 자신의 "C-논리"에 오류가 없고 아버지 구현자의 LITERAL 설명이 충분하지 않다는 사실에 놀랄 것입니다. 최적화 및 기타 사소한 일, 쓸모없는 통계 기술의 공식화에 대한 교육에 대해 낯설어질 때까지 여기에 게시할 수 있기 때문에 기본 계산의 결과와 관련된 문제는 초석으로 남아 기본 범위를 필요로 합니다. 그리고 당신이 떠나겠다고 위협한다면, 우리는 일부 CME에 갈 것입니다. 우리는 그들로부터 문서와 FIX 및 기타 종소리와 휘파람이 있는 프로그램을 ALBANSKY에서 가져갈 것입니다. :) 그리고 당신은 직업 없이 남게 될 것입니다. mq6을 만들고 물에 앉아 일어나면 최소한 누군가가 당신의 제품을 테스트하기를 원합니다. 글쎄요, 적어도 알바니아어로는 하지만 아니요, 그들은 더 이상 우리를 깨우지 않습니다 ... 당신 자신이 조용히 우리를 금지했기 때문에 .. . :)))))) )))))))))))))))))))) 000
신규유저 들 에게 똑같은걸 1000번씩 설명 해줘야 하는 개발자분들께 심심한 위로의 말씀을 전합니다..
이미 노골적인 배신이다...
메모리에 실수를 저장하는 것은 교과서에 기록되어 있으며 변수가 스스로 변할 수 있다는 사실에 대해서는 아무 말도 없습니다. 이 포럼에서 나는 SK에서만 그런 이야기를 들은 것이 아닙니다.
따라서 모든 신규 사용자를 1000번 잘못 인도했다면 이제 해당 사용자를 찾아 내 말에 대해 사과해야 합니다!
나는 Simca 에 동의합니다. 산술 연산 을 수행할 때 결함이 있을 수 있지만 저장, 쓰기 또는 읽기에서는 제외됩니다!
그래서 NormalizeDouble() 함수의 알고리즘에 질문했습니다. 아마도 오류로 이어지는 산술 연산도 있을 수 있습니까?
심카 는 어떻게 생각하세요?
확인. 당신은 이것에 대해 너무 자신있게 말해서 나는 이미 내 말을 의심했습니다.
얼마 전까지는 256MB RAM이 장착된 구형 PC에서 작업해야 했습니다. 여러 프로그램을 로드할 때 운영 체제는 데이터의 일부를 디스크로 언로드한 다음 다시 로드했습니다. 코드를 변경한 이후(비교 연산자의 정규화를 나타냄) 오류가 더 이상 나타나지 않습니다. 그러나 당신의 말 후에 나는 이미 의심했습니다. 내가 정말로 거기에서 무언가를 수정하고 그것을 눈치 채지 못했다면 어떨까요?
지금은 모르겠어-사과할지 말지.. 내가 틀렸다면 1000명의 유저들이 나를 용서하자.
(그래도 비교 연산을 계산할 때 직접 정규화하는 것이 좋다 :)
메모리에 실수를 저장하는 것은 교과서에 기록되어 있으며 변수가 스스로 변할 수 있다는 사실에 대해서는 아무 말도 없습니다. 이 포럼에서 나는 SK에서만 그런 이야기를 들은 것이 아닙니다.
그러나이 모든 것은 계산을 참조하지만 값은 정규화 여부에 관계없이 변경되지 않고 메모리에 저장됩니다.
그래서 NormalizeDouble () 함수의 알고리즘에 질문했습니다. 아마도 오류로 이어지는 산술 연산도 있을 수 있습니까?
심카 는 어떻게 생각하세요?
(그래도 비교 연산을 계산할 때 직접 정규화하는 것이 좋다 :)
그리고 내 입장에서는(문제의 본질을 완전히 이해하지 못하는 사람들을 위해) 다음을 추천할 수도 있습니다.
그러나 여전히 비교 연산 (c) SK를 계산할 때 직접 정규화하는 것이 좋습니다.
(그러나 여전히 다음과 같은 경우 직접 정규화하는 것이 좋습니다.
비교 연산을 계산합니다 :)
죄송하지만 효율성 면에서 정규화가 필요한 데이터 비교를 위한 훨씬 더 나은 구현이 있습니다. 일반적으로 이것은 표준(비교 알고리즘)입니다. 스케일의 절반 치수와의 차이를 비교할 필요가 있습니다. 무슨 말입니까: 가격을 비교하려면(차이가 있든 없든) 차이를 가져와 0.5*Roint 값과 비교해야 합니다(expert\script\indicator 초기화 중에 한 번만 계산할 수 있음) 이것은 하나의 함수를 호출하는 것보다 훨씬 더 효율적이며 두 개를 호출하는 것보다 훨씬 더 효율적입니다.
행운을 빕니다.
mql4의 더블 비교 연구. 첫째, 복식으로 작업하는 것은 순전히 컴파일러 트릭이므로 본질적으로 인터프리터가 있는 스크립트인 mql4에서 편의를 요구하는 것은 적절하지 않습니다. 메인, 개발자가 길을 냈고 비교의 정확한 결과를 보장하고 펜으로 확인했습니다. 물론 문법이지만 작동 중입니다 !!! 문서에 "!=" 또는 "=="의 경우 전류를 정규화해야 한다고 명시되어 있지만, 당사의 독립적인 전문가 테스트에 따르면 (a>b) a가 회전하는 경우 올바른 결과를 보장하지 않습니다(!) b와 같도록! 와 b를 모두 정규화하더라도 숫자가 같으면 결과를 예측할 수 없습니다. 그러나 개발자의 구조::: NormalizeDouble (ab, Digits)>0은 안정적으로 작동합니다! 뽕나무 동지들이 왜 정규화 기능을 좋아하지 않았는지 모르겠습니다... 아마도 (INSIDE)는 다음과 같이 상당히 의미론적으로 수행됩니다. 그리고 그 후 - 전체는 문제가 없습니다.
올바른 러시아어로 작성하십시오.
개발자 사이트(러시아어)에 대한 링크를 제공하면 저자의 정의만 사용할 것을 약속합니다. :) 내 생각에 당신의 언어는 나보다 더 정확하지 않지만 당신이 개인적으로 그것을 이해하지 못한다면 전문가 평가와 blah blah를 분리할 수 없다면 "for Rosh"로 번역하겠습니다. 너한테 쓴게 아니라 1001번째 신인한테 쓴거니까. :)
예: www.gramota.ru
포럼에는 Albany 섹션이 없습니다. 그러나 러시아어가 아닌 다음 메시지 이후에는 그곳으로 보내질 것입니다. 위대하고 강한자를 왜곡하지 마십시오.