고정 크기를 가진 개체의 경우: OBJ_BUTTON, OBJ_RECTANGLE_LABEL 및 OBJ_EDIT, OBJPROP_XDISTANCE 및 OBJPROP_YDISTANCE 속성은 X 및 Y 좌표(픽셀 단위)가 계산되는 차트 모서리(OBJPROP_CORNER)를 기준으로 개체의 왼쪽 위 지점 위치를 설정합니다.
MT5:
고정 크기를 가진 개체의 경우: OBJ_BUTTON, OBJ_RECTANGLE_LABEL, OBJ_EDIT 및 OBJ_CHART, OBJPROP_XDISTANCE 및 OBJPROP_YDISTANCE 속성은 X 및 Y 좌표가 시작되는 차트 모서리(OBJPROP_CORNER)를 기준으로 개체의 왼쪽 상단 지점 위치를 설정합니다. 계산.
MT4에만 OBJ_LABEL에 대한 개체의 왼쪽 점이 없습니다. 오른쪽이 있지만 이것은 내 분노를 일으키지 않았습니다. 사실 ObjectSet을 사용하는 이전 MT4 코드에서 개체를 상대적으로 배치할 수 있었습니다. 모서리(모서리) - 왼쪽에 있는 개체의 경우 픽셀은 첫 번째 문자부터 계산되고 오른쪽의 경우에는 마지막 문자부터 계산되며 새 버전은 항상 첫 번째 문자부터 들여쓰기를 계산하므로 레이블을 배치하기 어렵습니다. 텍스트 문자가 몇 개인지 항상 알 수 있는 것은 아니기 때문에 개발자들에게 텍스트 정렬 방식 선택 추가 부탁드립니다!
MT5에서 좌우 정렬 방법을 아시는 분 계시면 해당 기능 공유 부탁드립니다!
그리고 당신은 화를 내지 않고 도움말을주의 깊게 읽으십시오.
OBJ_LABEL, OBJ_BITMAP_LABEL 및 OBJ_RECTANGLE_LABEL 개체의 경우 개체의 기준점이 배치되는 차트 각도를 상대적으로 설정할 수 있습니다. 이 모서리는 4개의 ENUM_BASE_CORNER 열거 값 중 하나를 가질 수 있는 개체의 OBJPROP_CORNER 속성을 통해 설정됩니다.
식별자
설명
CORNER_LEFT_UPPER
앵커 포인트 좌표는 차트의 왼쪽 상단 모서리를 기준으로 설정됩니다.
CORNER_LEFT_LOWER
앵커 포인트 좌표는 차트의 왼쪽 하단 모서리를 기준으로 설정됩니다.
CORNER_RIGHT_LOWER
앵커 포인트 좌표는 차트의 오른쪽 하단 모서리를 기준으로 설정됩니다.
CORNER_RIGHT_UPPER
앵커 포인트 좌표는 차트의 오른쪽 상단 모서리를 기준으로 설정됩니다.
객체의 앵커 포인트 자체의 위치는 OBJPROP_ANCHOR 속성에 의해 지정되며 ENUM_ANCHOR_POINT 열거형의 9개 값 중 하나일 수 있습니다.
OBJ_LABEL, OBJ_BITMAP_LABEL 및 OBJ_RECTANGLE_LABEL 개체의 경우 개체의 기준점이 배치되는 차트 각도를 상대적으로 설정할 수 있습니다. 이 모서리는 4개의 ENUM_BASE_CORNER 열거 값 중 하나를 가질 수 있는 개체의 OBJPROP_CORNER 속성을 통해 설정됩니다.
식별자
설명
CORNER_LEFT_UPPER
앵커 포인트 좌표는 차트의 왼쪽 상단 모서리를 기준으로 설정됩니다.
CORNER_LEFT_LOWER
앵커 포인트 좌표는 차트의 왼쪽 하단 모서리를 기준으로 설정됩니다.
CORNER_RIGHT_LOWER
앵커 포인트 좌표는 차트의 오른쪽 하단 모서리를 기준으로 설정됩니다.
CORNER_RIGHT_UPPER
앵커 포인트 좌표는 차트의 오른쪽 상단 모서리를 기준으로 설정됩니다.
객체의 앵커 포인트 자체의 위치는 OBJPROP_ANCHOR 속성에 의해 지정되며 ENUM_ANCHOR_POINT 열거형의 9개 값 중 하나일 수 있습니다.
Строковая в double переводится без проблем. Обратно - получаем другой результат.
저것들. 문자열 "8.905"를 가져 와서 double로 변환하고 즉시 문자열로 변환하여 8.904999999999999를 얻었습니다. 그러나 OnStart의 첫 번째 줄은 (double)"8.905" == 8.905임을 보여줍니다. 저것들. 출력은 8.905이어야 합니다.
이중 -> 문자열 변환이 여전히 올바른 것으로 간주되는 이유를 설명하십시오. 마지막 예는 완전히 마음을 울리는 것입니다.
마지막 예에 대한 의견
실수에 대해 동일한 변환이 수행된 경우 실수는 동일한 것으로 간주될 수 있습니다. num*0.5 및 num/2.0과 같이 겉보기에 동일한 변환이라도 결과가 다릅니다. 미러 작업에 대해서도 마찬가지입니다. 숫자*=숫자2, 숫자/=숫자2. 결과 숫자는 원래 숫자와 같지 않습니다. 실수의 세계에 오신 것을 환영합니다.
이 예에서는 실수로 정규화하는 과정에서 num*=1000, num+=0.5, num/=1000의 3가지 연산을 수행했습니다.
실수에 대해 동일한 변환이 수행된 경우 실수는 동일한 것으로 간주될 수 있습니다. num*0.5 및 num/2.0과 같이 겉보기에 동일한 변환이라도 결과가 다릅니다. 미러 작업에 대해서도 마찬가지입니다. 숫자*=숫자2, 숫자/=숫자2. 결과 숫자는 원래 숫자와 같지 않습니다. 실수의 세계에 오신 것을 환영합니다.
이 예에서는 실수로 정규화하는 과정에서 num*=1000, num+=0.5, num/=1000의 3가지 연산을 수행했습니다.
디버거에서 단계별로 확인할 수 있습니다.
매우 건설적인 설명, 감사합니다!
그러나 여기에 몇 개의 두뇌를 앗아가는 반례가 있습니다.
voidOnStart ()
{
constdouble Num = 8.274 ;
constdouble Norm = NormalizeDouble (Num, 3 );
Print (Num); // 8.273999999999999Print (Norm); // 8.274000000000001Print (( double ) DoubleToString (Num, 3 ) == Num); // true - без нормализации все замечательноPrint (( double ) DoubleToString (Norm, 3 ) == Norm); // false - а после нормализации полный облом!
}
아침이 저녁보다 현명하다... :)
도움으로
MT4:
고정 크기를 가진 개체의 경우: OBJ_BUTTON, OBJ_RECTANGLE_LABEL 및 OBJ_EDIT, OBJPROP_XDISTANCE 및 OBJPROP_YDISTANCE 속성은 X 및 Y 좌표(픽셀 단위)가 계산되는 차트 모서리(OBJPROP_CORNER)를 기준으로 개체의 왼쪽 위 지점 위치를 설정합니다.
MT5:
고정 크기를 가진 개체의 경우: OBJ_BUTTON, OBJ_RECTANGLE_LABEL, OBJ_EDIT 및 OBJ_CHART, OBJPROP_XDISTANCE 및 OBJPROP_YDISTANCE 속성은 X 및 Y 좌표가 시작되는 차트 모서리(OBJPROP_CORNER)를 기준으로 개체의 왼쪽 상단 지점 위치를 설정합니다. 계산.
MT4에만 OBJ_LABEL에 대한 개체의 왼쪽 점이 없습니다. 오른쪽이 있지만 이것은 내 분노를 일으키지 않았습니다. 사실 ObjectSet을 사용하는 이전 MT4 코드에서 개체를 상대적으로 배치할 수 있었습니다. 모서리(모서리) - 왼쪽에 있는 개체의 경우 픽셀은 첫 번째 문자부터 계산되고 오른쪽의 경우에는 마지막 문자부터 계산되며 새 버전은 항상 첫 번째 문자부터 들여쓰기를 계산하므로 레이블을 배치하기 어렵습니다. 텍스트 문자가 몇 개인지 항상 알 수 있는 것은 아니기 때문에 개발자들에게 텍스트 정렬 방식 선택 추가 부탁드립니다!
MT5에서 좌우 정렬 방법을 아시는 분 계시면 해당 기능 공유 부탁드립니다!
그리고 당신은 화를 내지 않고 도움말을주의 깊게 읽으십시오.
OBJ_LABEL, OBJ_BITMAP_LABEL 및 OBJ_RECTANGLE_LABEL 개체의 경우 개체의 기준점이 배치되는 차트 각도를 상대적으로 설정할 수 있습니다. 이 모서리는 4개의 ENUM_BASE_CORNER 열거 값 중 하나를 가질 수 있는 개체의 OBJPROP_CORNER 속성을 통해 설정됩니다.
식별자
설명
CORNER_LEFT_UPPER
앵커 포인트 좌표는 차트의 왼쪽 상단 모서리를 기준으로 설정됩니다.
CORNER_LEFT_LOWER
앵커 포인트 좌표는 차트의 왼쪽 하단 모서리를 기준으로 설정됩니다.
CORNER_RIGHT_LOWER
앵커 포인트 좌표는 차트의 오른쪽 하단 모서리를 기준으로 설정됩니다.
CORNER_RIGHT_UPPER
앵커 포인트 좌표는 차트의 오른쪽 상단 모서리를 기준으로 설정됩니다.
객체의 앵커 포인트 자체의 위치는 OBJPROP_ANCHOR 속성에 의해 지정되며 ENUM_ANCHOR_POINT 열거형의 9개 값 중 하나일 수 있습니다.
식별자
설명
ANCHOR_LEFT_UPPER
왼쪽 상단 모서리의 앵커 포인트
ANCHOR_LEFT
기준점 왼쪽 중앙
ANCHOR_LEFT_LOWER
왼쪽 하단 모서리의 앵커 포인트
ANCHOR_LOWER
앵커 포인트 하단 중앙
ANCHOR_RIGHT_LOWER
오른쪽 하단 모서리의 앵커 포인트
ANCHOR_RIGHT
기준점 오른쪽 중앙
ANCHOR_RIGHT_UPPER
오른쪽 상단 모서리의 앵커 포인트
ANCHOR_UPPER
앵커 포인트 상단 중앙
ANCHOR_CENTER
대상의 중심에 있는 기준점
거기에 없는 숫자 4로 지정하려고 하는 목록 항목을 위로 이동해야 합니까? 0이 되고 모든 것이 제자리에 있습니다.
물론, 나는 모든 것을 옮겼습니다. 아마도 내가 바보 일 것입니다 ..
그리고 당신은 화를 내지 않고 도움말을주의 깊게 읽으십시오.
OBJ_LABEL, OBJ_BITMAP_LABEL 및 OBJ_RECTANGLE_LABEL 개체의 경우 개체의 기준점이 배치되는 차트 각도를 상대적으로 설정할 수 있습니다. 이 모서리는 4개의 ENUM_BASE_CORNER 열거 값 중 하나를 가질 수 있는 개체의 OBJPROP_CORNER 속성을 통해 설정됩니다.
식별자
설명
CORNER_LEFT_UPPER
앵커 포인트 좌표는 차트의 왼쪽 상단 모서리를 기준으로 설정됩니다.
CORNER_LEFT_LOWER
앵커 포인트 좌표는 차트의 왼쪽 하단 모서리를 기준으로 설정됩니다.
CORNER_RIGHT_LOWER
앵커 포인트 좌표는 차트의 오른쪽 하단 모서리를 기준으로 설정됩니다.
CORNER_RIGHT_UPPER
앵커 포인트 좌표는 차트의 오른쪽 상단 모서리를 기준으로 설정됩니다.
객체의 앵커 포인트 자체의 위치는 OBJPROP_ANCHOR 속성에 의해 지정되며 ENUM_ANCHOR_POINT 열거형의 9개 값 중 하나일 수 있습니다.
식별자
설명
ANCHOR_LEFT_UPPER
왼쪽 상단 모서리의 앵커 포인트
ANCHOR_LEFT
기준점 왼쪽 중앙
ANCHOR_LEFT_LOWER
왼쪽 하단 모서리의 앵커 포인트
ANCHOR_LOWER
앵커 포인트 하단 중앙
ANCHOR_RIGHT_LOWER
오른쪽 하단 모서리의 앵커 포인트
ANCHOR_RIGHT
기준점 오른쪽 중앙
ANCHOR_RIGHT_UPPER
오른쪽 상단 모서리의 앵커 포인트
ANCHOR_UPPER
앵커 포인트 상단 중앙
ANCHOR_CENTER
개체의 중심에 있는 기준점
감사합니다 내일 해봐야겠네요...
아침은 저녁보다 현명하다... :)
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
오류, 버그, 질문
fxsaber , 2017.07.18 09:51
거의 유치한 질문: 왜 그럴까요?어떤 이유에서인지 정규화 후에 DoubleToString이 의미가 없다고 확신했습니다. 그러나 스크립트가 보여주듯이 아닙니다. 왜 그런 겁니까?
이중 -> 문자열 캐스트가 제대로 작동하지 않는 것 같습니다.
예제는 이해하기가 매우 어렵습니다. 그래서 나는 다른 것을 주었습니다.
여기에 대한 내용이 있습니다.
Строковая в double переводится без проблем. Обратно - получаем другой результат.
저것들. 문자열 "8.905"를 가져 와서 double로 변환하고 즉시 문자열로 변환하여 8.904999999999999를 얻었습니다. 그러나 OnStart의 첫 번째 줄은 (double)"8.905" == 8.905임을 보여줍니다. 저것들. 출력은 8.905이어야 합니다.
물론 명백한 null 종료 상황은 작동하지 않아야 합니다.
문제를 조금 조사한 후이 상황에 이르렀습니다.
이중 -> 문자열 변환이 여전히 올바른 것으로 간주되는 이유를 설명하십시오. 마지막 예는 완전히 마음을 울리는 것입니다.
이중 -> 문자열 변환이 여전히 올바른 것으로 간주되는 이유를 설명하십시오. 마지막 예는 완전히 마음을 울리는 것입니다.
마지막 예에 대한 의견
실수에 대해 동일한 변환이 수행된 경우 실수는 동일한 것으로 간주될 수 있습니다. num*0.5 및 num/2.0과 같이 겉보기에 동일한 변환이라도 결과가 다릅니다. 미러 작업에 대해서도 마찬가지입니다. 숫자*=숫자2, 숫자/=숫자2. 결과 숫자는 원래 숫자와 같지 않습니다. 실수의 세계에 오신 것을 환영합니다.
이 예에서는 실수로 정규화하는 과정에서 num*=1000, num+=0.5, num/=1000의 3가지 연산을 수행했습니다.
디버거에서 단계별로 확인할 수 있습니다.
SD에서는 이 경우 모든 것이 옳다고 말합니다.
그리고 왜 부끄럽습니까?
10진수 실수의 대다수는 나머지가 없는 이진 분수로 나타낼 수 없습니다. 우리는 그것에 저장 형식 번호를 두 배로 부과하고 그런 추함을 받습니다.
일반적으로 10진수 유형은 문제가 되지 않으며 편리한 것입니다.
마지막 예에 대한 의견
실수에 대해 동일한 변환이 수행된 경우 실수는 동일한 것으로 간주될 수 있습니다. num*0.5 및 num/2.0과 같이 겉보기에 동일한 변환이라도 결과가 다릅니다. 미러 작업에 대해서도 마찬가지입니다. 숫자*=숫자2, 숫자/=숫자2. 결과 숫자는 원래 숫자와 같지 않습니다. 실수의 세계에 오신 것을 환영합니다.
이 예에서는 실수로 정규화하는 과정에서 num*=1000, num+=0.5, num/=1000의 3가지 연산을 수행했습니다.
디버거에서 단계별로 확인할 수 있습니다.
매우 건설적인 설명, 감사합니다!
그러나 여기에 몇 개의 두뇌를 앗아가는 반례가 있습니다.
이것이 정규화가 작동하는 방식입니까?
그리고 왜 부끄럽습니까?
설명이 끝나면 Glory는 더 이상 창피하지 않지만 이제 NormalizeDouble 자체 작업의 정확성을 의심하게 만드는 예가 나타났습니다.