Renat : 가격을 정수로 변환해도 특별한 이점은 없습니다. 예, 효과적으로 볼륨을 줄이지만 불가피하게 두 배로 레코딩하기 때문에 속도가 몇 배나 떨어집니다. 전체 시스템을 정수로 절대적으로 만드는 것이 불가능하기 때문에 정확히 피할 수 없는 것이므로 계산 가능한 수학은 여전히 2배(충분히 정확하지 않음)로 수행되어야 합니다.
나는 지원한다. 그렇기 때문에 이전에 다음과 같이 썼습니다.
hrenfx :
추신: 수치에서 명확한 부정확성이 있습니다. INT의 기록은 2.1Gb, DOUBLE - 7Gb를 차지할 수 없습니다. 그 차이는 항상 정확히 2배( USHORT로는 충분하지 않음 )여야 합니다. 가격이 있는 정수 산술로 전환하면 EA의 모든 논리가 정수 1로 대체될 수 있을 때 상당한 이점이 있습니다. 자주 발생하지 않습니다.
내 가장 어리석고 가장 빈번하지만 가장 빠른 계산 운에서는 더하기, 빼기 및 비교 연산만 있기 때문에 모든 것이 전체입니다. 각각 INT에서 DOUBLE로의 전환은 필요하지 않습니다.
일반적으로 특수한 경우의 알고리즘 최적화는 보편적인 접근 방식보다 실행(쓰기가 아닌) 속도에서 항상 이점을 제공합니다. 따라서 예를 들어 Expert Advisor가 매개변수의 자동 최적화를 사용하는 경우 자동 최적화 속도 문제는 매우 중요합니다. 그리고 DLL에서 또는 MQL5에서 직접 알고리즘적으로 최적화된 자신만의 운율을 만드는 것이 합리적입니다. 그리고 자동 최적화의 경우 MT5 옵티마이저를 사용하지 마십시오. 불행히도 EA 자동 최적화를 위한 MT5 옵티마이저는 매우 제한된 경우에 적합합니다.
내 가장 어리석고 가장 빈번하지만 가장 빠른 계산 운에서는 더하기, 빼기 및 비교 연산만 있기 때문에 모든 것이 전체입니다. 각각 INT에서 DOUBLE로의 전환은 필요하지 않습니다.
일반적으로 특수한 경우의 알고리즘 최적화는 보편적인 접근 방식보다 실행(쓰기가 아닌) 속도에서 항상 이점을 제공합니다. 따라서 예를 들어 Expert Advisor가 매개변수의 자동 최적화를 사용하는 경우 자동 최적화 속도 문제는 매우 중요합니다. 따라서 DLL에서 또는 MQL5에서 직접 알고리즘적으로 최적화된 고유한 운을 만드는 것이 합리적입니다. 그리고 자동 최적화의 경우 MT5 옵티마이저를 사용하지 마십시오. 불행히도 자동 최적화 기능이 있는 EA용 내장 옵티마이저는 제한된 경우에 적합합니다.
이중으로 전송하지 않고는 할 수 없는 경우의 예를 들어 주십시오.
예를 들어, 어떤 것의 백분율이나 확률을 계산해야 합니다.
첫 번째 경우에 0.0001%로 포인트를 취한 다음 1.2345%는 12345포인트가 됩니다.
나는 말한다 - 초보자 ... 이해는 경험이 올 것입니다.
좋은 주장입니다. 아무 말도 하지마 :)
초보자와 함께 당신은 흥분했습니다. 우리는 지금 무엇에 대해 논쟁하고 있습니까? :)
수학을 발견하십시오. :)
==
추가하겠습니다 - 아마도 누군가 할 것입니다 ... 여기에서 검색을 시작해야 합니다.
http://en.wikipedia.org/wiki/%E2%84%9A
여기 http://devilions.wolfram.com/RationalNumberExplorer/
여기 http://www.solarix.ru/for_developers/cpp/boost/rational/ru/rational.shtml
다음 게시물의 웃음은 잘립니다. 이걸 고려하세요.
가격을 정수로 변환해도 특별한 이점은 없습니다. 예, 효과적으로 볼륨을 줄이지만 불가피하게 두 배로 레코딩하기 때문에 속도가 몇 배나 떨어집니다. 전체 시스템을 정수로 절대적으로 만드는 것이 불가능하기 때문에 정확히 피할 수 없는 것이므로 계산 가능한 수학은 여전히 2배(충분히 정확하지 않음)로 수행되어야 합니다.
나는 지원한다. 그렇기 때문에 이전에 다음과 같이 썼습니다.
추신: 수치에서 명확한 부정확성이 있습니다. INT의 기록은 2.1Gb, DOUBLE - 7Gb를 차지할 수 없습니다. 그 차이는 항상 정확히 2배( USHORT로는 충분하지 않음 )여야 합니다. 가격이 있는 정수 산술로 전환하면 EA의 모든 논리가 정수 1로 대체될 수 있을 때 상당한 이점이 있습니다. 자주 발생하지 않습니다.
내 가장 어리석고 가장 빈번하지만 가장 빠른 계산 운에서는 더하기, 빼기 및 비교 연산만 있기 때문에 모든 것이 전체입니다. 각각 INT에서 DOUBLE로의 전환은 필요하지 않습니다.
일반적으로 특수한 경우의 알고리즘 최적화는 보편적인 접근 방식보다 실행(쓰기가 아닌) 속도에서 항상 이점을 제공합니다. 따라서 예를 들어 Expert Advisor가 매개변수의 자동 최적화를 사용하는 경우 자동 최적화 속도 문제는 매우 중요합니다. 그리고 DLL에서 또는 MQL5에서 직접 알고리즘적으로 최적화된 자신만의 운율을 만드는 것이 합리적입니다. 그리고 자동 최적화의 경우 MT5 옵티마이저를 사용하지 마십시오. 불행히도 EA 자동 최적화를 위한 MT5 옵티마이저는 매우 제한된 경우에 적합합니다.
나는 지원한다. 그렇기 때문에 이전에 다음과 같이 썼습니다.
내 가장 어리석고 가장 빈번하지만 가장 빠른 계산 운에서는 더하기, 빼기 및 비교 연산만 있기 때문에 모든 것이 전체입니다. 각각 INT에서 DOUBLE로의 전환은 필요하지 않습니다.
일반적으로 특수한 경우의 알고리즘 최적화는 보편적인 접근 방식보다 실행(쓰기가 아닌) 속도에서 항상 이점을 제공합니다. 따라서 예를 들어 Expert Advisor가 매개변수의 자동 최적화를 사용하는 경우 자동 최적화 속도 문제는 매우 중요합니다. 따라서 DLL에서 또는 MQL5에서 직접 알고리즘적으로 최적화된 고유한 운을 만드는 것이 합리적입니다. 그리고 자동 최적화의 경우 MT5 옵티마이저를 사용하지 마십시오. 불행히도 자동 최적화 기능이 있는 EA용 내장 옵티마이저는 제한된 경우에 적합합니다.
이중으로 전송하지 않고는 할 수 없는 경우의 예를 들어 주십시오.
예를 들어, 어떤 것의 백분율이나 확률을 계산해야 합니다.
첫 번째 경우에 0.0001%로 포인트를 취한 다음 1.2345%는 12345포인트가 됩니다.
아마 같은.
2배의 비트 깊이도 한계가 있고 항상 숨겨진 항목이 있다는 것을 이해해야 합니다.
이중으로 전송하지 않고는 할 수 없는 경우의 예를 들어 주십시오.
예를 들어, 어떤 것의 백분율이나 확률을 계산해야 합니다.
첫 번째 경우에 0.0001%로 포인트를 취한 다음 1.2345%는 12345포인트가 됩니다.
아마 같은.
2배의 비트 깊이도 한계가 있고 항상 숨겨진 항목이 있다는 것을 이해해야 합니다.
글쎄, 얼마나 매복! 인류는 잘못된 방향으로 숫자 과학을 발전시키고 있습니다. 실수와 더 복잡한 숫자는 헛되이 발명되었습니다. - 아주 간단하게, 일부는 다수의 정수를 관리하는 것으로 나타났습니다!
나는 예를 보지 않는다?