일반적으로 분기 주제에 대해 이야기하면서 캔버스에 그리는 완전히 대안적인 접근 방식을 구현했습니다. CCanvas 클래스 를 사용하지 않습니다.
즉, 별도의 기능 집합을 수정하는 것이 아니라 단일 블록으로 구성된 통합 그리기 메커니즘을 만드는 것입니다.
(물론 코드가 많고 비표준으로 작성되어 있기 때문에 이 모든 것을 코드로 보여주기는 어렵지만 일반적인 용어로 말씀드리고 싶습니다.)
그래서:
1. 차단(기능)
void Нарисовать_элемент( int Канвас, int Элемент = 0 )
Canvas와 Element의 2가지 매개변수만 사용합니다.
Canvas 는 MT 객체이며,
요소 - 그림.
2. 각 MT-object는 자체 리소스를 가지고 있습니다. ResourceReadImage()를 사용하여 "픽셀 배열"에 즉시 로드됩니다. 리소스가 아직 존재하지 않으면 나중에 코어를 통한 루프 범위를 결정하는 플래그가 설정됩니다.
3. 핵심, - 모든 요소의 속성 배열. 또한 개체의 크기와 다양한 상태의 색상에 대한 데이터도 포함합니다. 그리고 다른 많은 데이터. 각 개체에 대해 총 235개의 속성이 있습니다. 동시에 각 요소(유형에 따라 다름)는 1개에서 11개까지의 개체를 포함할 수 있습니다(제한 없음).
4. 도면 블록에서 각 개체는 도면의 "상세"를 의미합니다. 따라서 코어에 있는 객체를 통한 주기는 각 Part의 이미지가 생성되는 드로잉 주기입니다. Canvas가 아직 생성되지 않은 경우 이 Canvas의 모든 세부 정보에 대해서만 전체 주기가 만들어집니다. 각 Detail에 대해 Core에 Canvas에 속해 있음을 등록합니다. 즉, 모든 캔버스(및 세부 정보)에는 일련 번호가 있습니다. 이 숫자를 통해 원하는 Canvas의 내용만 그릴 수 있습니다.
4. Canvas가 이미 존재하고 해당 이미지가 픽셀 배열에 로드되고 단일 요소(예: 색상 변경 이벤트)만 다시 그려야 하는 경우 코어를 통과하는 루프 범위가 경계로 좁아집니다. 하나의 요소 중 하나의 숫자는 그리기 기능으로 얻은 것입니다.
그림 자체는 간단합니다. 이것은 1차원 배열의 셀을 왼쪽에서 오른쪽으로 순환하는 것입니다. 주기가 설정되기 전:
1. 초기 셀(포인트 A).
2. 끝 세포(B 지점).
3. 건너뛰기.
1500줄의 코드로 구성된 블록의 동작을 간략하게 설명하기는 어렵다. 이것은 20개월 동안 성장하고 연마한 기능 중 하나입니다. 나는 그것을 거의 마음으로 알고 있기 때문에 개발을 계속하기 쉽습니다.
커널과 포커스를 사용하여(중요한 변수를 전역 범위에 두는) 블록은 엄청난 힘을 얻습니다. 그들의 경계는 오늘날까지 나에게 보이지 않습니다.
코드에 대해 다시 한 번 감사드립니다. 나는이 이중 유형 비트 마스크로 내 두뇌를 쌓았습니다. 그것은 내가 전에 생각했던 것만큼 간단하지 않다는 것이 밝혀졌습니다. 나는 당신에 맞게 내 버전 을 약간 조정했습니다. -1>x>0 Ceil(-0.1)= - 0.0 의 값으로 반환된 버전과 광산 0.0 이라는 한 가지 차이점만 있었습니다. 이것이 언제 유용할 수 있는지 진실은 분명하지 않습니다.
그리고 다음과 같은 일이 일어났습니다.
//double Ceil(double x) { return double((x!=x || x>(long)1<<53 || x<-(long)1<<53)?x:(x-(long)x>0)?(long)x+1:(long)x);}double Ceil( double x) { returndouble ((x!=x || x>( long ) 1 << 53 || x<-( long ) 1 << 53 )?x:(x-( long )x> 0 )?( long )x+ 1 :(x>- 1 && x< 0 )?- 0.0 :( long )x);}
동일, 읽기만 가능하고 주석:
double Ceil( double x)
{
if (x!=x || // если x = NaN(SNaN) т.е. переполнение или ошибка
x> ( long ) 1 << 53 || // или число x положительное и превышает максимальную возможную мантиссу, т.е. дробная часть в x точно отсутствует
x<-( long ) 1 << 53 ) // или число x отрицательное и превышает максимальную возможную мантиссу, т.е. дробная часть в x точно отсутствует return (x);
if (x-( long )x> 0 ) // Если число положительное или дробная часть не равна нулюreturn ( long )x+ 1.0 ; // добавляем к бездробной части 1elseif (x>- 1 && x< 0 ) // Если -1 < x < 0return - 0.0 ; // то возвращаем -0.0elsereturn ( double ) long (x);
}
귀하의 버전과 작업의 100% 동일성을 확인하는 스크립트(첨부)를 작성했습니다. 그러나 동시에이 옵션은 더 빠르고 컴팩트하며 읽기 쉽습니다.
또한 4개의 8바이트 변수를 생성하는 동안 함수 본문에는 단일 변수도 생성되지 않습니다. 어쩌면 내가 틀렸어?
입력 x에 항상 소수 부분이 있는 경우의 결과:
2018.08 . 2718 : 42 : 37.616 TestCeil (EURUSD,M1) Время выполнения функции CeilI = 1.321 наносекунд, Контрольная сумма = 5250492895.02018.08 . 2718 : 42 : 37.619 TestCeil (EURUSD,M1) Время выполнения функции CeilN = 1.094 наносекунд, Контрольная сумма = 5250492895.02018.08 . 2718 : 42 : 37.623 TestCeil (EURUSD,M1) Время выполнения функции ceil = 2.962 наносекунд, Контрольная сумма = 5250492895.02018.08 . 2718 : 42 : 37.623 TestCeil (EURUSD,M1) Идет бесконечный поиск расхождения по случайным числам double ... Прервите скрипт, когда надоест ждать
입력 x에서 소수 부분이 드문 경우의 결과:
2018.08 . 2718 : 49 : 45.734 TestCeil (EURUSD,M1) Время выполнения функции CeilI = 0.307 наносекунд, Контрольная сумма = 1.15583114403606 e+ 232018.08 . 2718 : 49 : 45.736 TestCeil (EURUSD,M1) Время выполнения функции CeilN = 0.102 наносекунд, Контрольная сумма = 1.15583114403606 e+ 232018.08 . 2718 : 49 : 45.738 TestCeil (EURUSD,M1) Время выполнения функции ceil = 1.026 наносекунд, Контрольная сумма = 1.15583114403606 e+ 232018.08 . 2718 : 49 : 45.738 TestCeil (EURUSD,M1) Идет бесконечный поиск расхождения по случайным числам double ... Прервите скрипт, когда надоест ждать
일리아스 :
2. 자체 작성 함수는 최적화가 비활성화되어 있을 때 디버깅을 위해 컴파일할 때 내장 함수보다 훨씬 느립니다.
디버깅에 속도가 필요한 이유는 명확하지 않습니다. 그러나 정말로 필요한 경우 옵션으로 구성을 사용할 수 있습니다.
와 멋있다! 고맙습니다. 그리고 저는 생각했습니다. 모든 시간이 중요합니다. 네, 논리적입니다. 이미 컴파일 단계에서 계산할 수 있습니다.
다음과 같이:
사실, 53 대신 DBL_MANT_DIG 를 쓰는 것이 더 정확할 것입니다.
모든 이중 값이 소수인 경우 최소 승리 사례입니다.
1. 구현이 불완전하며 가능한 값의 범위를 미리 알고 있는 경우에만 사용할 수 있습니다.
전체 구현 코드는 다음과 같습니다.
2. 자체 작성 함수는 최적화가 비활성화되어 있을 때 디버깅을 위해 컴파일할 때 내장 함수보다 훨씬 느립니다.
1. 구현이 불완전하며 가능한 값의 범위를 미리 알고 있는 경우에만 사용할 수 있습니다.
전체 구현 코드는 다음과 같습니다.
2. 자체 작성 함수는 최적화가 비활성화되어 있을 때 디버깅을 위해 컴파일할 때 내장 함수보다 훨씬 느립니다.
훌륭한 코드에 대해 Ilyas에게 대단히 감사합니다.
물론 여기에는 Union이 큰 도움이 됩니다.
공부중...
위협 그리고 이 옵션은 확실히 동일하지 않습니까?니콜라스, 안녕. 나는 당신이 그래픽에 종사하는 것을 알지만 실제로 작업이 무엇인지 완전히 이해하지 못합니다. 무슨 일을하고 있니?
렌더링 기능의 속도를 높이시겠습니까?
일반적으로 분기 주제에 대해 이야기하면서 캔버스에 그리는 완전히 대안적인 접근 방식을 구현했습니다. CCanvas 클래스 를 사용하지 않습니다.
즉, 별도의 기능 집합을 수정하는 것이 아니라 단일 블록으로 구성된 통합 그리기 메커니즘을 만드는 것입니다.
(물론 코드가 많고 비표준으로 작성되어 있기 때문에 이 모든 것을 코드로 보여주기는 어렵지만 일반적인 용어로 말씀드리고 싶습니다.)
그래서:
1. 차단(기능)
Canvas와 Element의 2가지 매개변수만 사용합니다.
2. 각 MT-object는 자체 리소스를 가지고 있습니다. ResourceReadImage()를 사용하여 "픽셀 배열"에 즉시 로드됩니다. 리소스가 아직 존재하지 않으면 나중에 코어를 통한 루프 범위를 결정하는 플래그가 설정됩니다.
3. 핵심, - 모든 요소의 속성 배열. 또한 개체의 크기와 다양한 상태의 색상에 대한 데이터도 포함합니다. 그리고 다른 많은 데이터. 각 개체에 대해 총 235개의 속성이 있습니다. 동시에 각 요소(유형에 따라 다름)는 1개에서 11개까지의 개체를 포함할 수 있습니다(제한 없음).
4. 도면 블록에서 각 개체는 도면의 "상세"를 의미합니다. 따라서 코어에 있는 객체를 통한 주기는 각 Part의 이미지가 생성되는 드로잉 주기입니다. Canvas가 아직 생성되지 않은 경우 이 Canvas의 모든 세부 정보에 대해서만 전체 주기가 만들어집니다. 각 Detail에 대해 Core에 Canvas에 속해 있음을 등록합니다. 즉, 모든 캔버스(및 세부 정보)에는 일련 번호가 있습니다. 이 숫자를 통해 원하는 Canvas의 내용만 그릴 수 있습니다.
4. Canvas가 이미 존재하고 해당 이미지가 픽셀 배열에 로드되고 단일 요소(예: 색상 변경 이벤트)만 다시 그려야 하는 경우 코어를 통과하는 루프 범위가 경계로 좁아집니다. 하나의 요소 중 하나의 숫자는 그리기 기능으로 얻은 것입니다.
그림 자체는 간단합니다. 이것은 1차원 배열의 셀을 왼쪽에서 오른쪽으로 순환하는 것입니다. 주기가 설정되기 전:
1. 초기 셀(포인트 A).
2. 끝 세포(B 지점).
3. 건너뛰기.
1500줄의 코드로 구성된 블록의 동작을 간략하게 설명하기는 어렵다. 이것은 20개월 동안 성장하고 연마한 기능 중 하나입니다. 나는 그것을 거의 마음으로 알고 있기 때문에 개발을 계속하기 쉽습니다.
커널과 포커스를 사용하여(중요한 변수를 전역 범위에 두는) 블록은 엄청난 힘을 얻습니다. 그들의 경계는 오늘날까지 나에게 보이지 않습니다.
이것은 캔버스에 그리는 표준 접근 방식에 대한 대안입니다.
추신 세부 사항에 관심이 있으시면 설명할 수 있습니다.
블록의 시작 부분은 다음과 같습니다.
1. 구현이 불완전하며 가능한 값의 범위를 미리 알고 있는 경우에만 사용할 수 있습니다.
전체 구현 코드는 다음과 같습니다.
코드에 대해 다시 한 번 감사드립니다. 나는이 이중 유형 비트 마스크로 내 두뇌를 쌓았습니다. 그것은 내가 전에 생각했던 것만큼 간단하지 않다는 것이 밝혀졌습니다.
나는 당신에 맞게 내 버전 을 약간 조정했습니다. -1>x>0 Ceil(-0.1)= - 0.0 의 값으로 반환된 버전과 광산 0.0 이라는 한 가지 차이점만 있었습니다. 이것이 언제 유용할 수 있는지 진실은 분명하지 않습니다.
그리고 다음과 같은 일이 일어났습니다.
동일, 읽기만 가능하고 주석:
귀하의 버전과 작업의 100% 동일성을 확인하는 스크립트(첨부)를 작성했습니다.
그러나 동시에이 옵션은 더 빠르고 컴팩트하며 읽기 쉽습니다.
또한 4개의 8바이트 변수를 생성하는 동안 함수 본문에는 단일 변수도 생성되지 않습니다.
어쩌면 내가 틀렸어?
입력 x에 항상 소수 부분이 있는 경우의 결과:
입력 x에서 소수 부분이 드문 경우의 결과:
2. 자체 작성 함수는 최적화가 비활성화되어 있을 때 디버깅을 위해 컴파일할 때 내장 함수보다 훨씬 느립니다.
디버깅에 속도가 필요한 이유는 명확하지 않습니다.
그러나 정말로 필요한 경우 옵션으로 구성을 사용할 수 있습니다.
그리고 여전히 한 가지 오해가 있습니다.
문서와 실제로 DBL_MANT_DIG = 53인 이유는 무엇입니까?
동일한 Wikipedia 에 따르면 = 52.
그리고 귀하의 코드 에서 52 ?
니콜라스, 안녕. 나는 당신이 그래픽에 종사하는 것을 알지만 실제로 작업이 무엇인지 완전히 이해하지 못합니다. 무슨 일을하고 있니?
렌더링 기능의 속도를 높이시겠습니까?
이봐 피터!
비공개로 답변드리겠습니다.
그리고 여전히 한 가지 오해가 있습니다.
문서와 실제로 DBL_MANT_DIG = 53인 이유는 무엇입니까?
동일한 Wikipedia 에 따르면 = 52.
그리고 코드 에서 52 ?
스스로 답을 찾아보셨나요?
힌트: Google 검색창에 "DBL_MANT_DIG 53 52"를 입력하세요.