Peter, 문제는 포럼에 모든 사람이 색상 분해를 보고 적용할 수 있는 기능을 게시했다는 것입니다. 그러나 이 함수는 원하는 색상 배열을 형성하지 않고 화면에 그라데이션을 표시하는 대신 Print 출력 에만 적합한 문자열 배열만 형성합니다. 이것은 찌르는 돼지이며 다른 사람을 존중하지 않습니다. 누군가 필요하면 번역하십시오.
이것은 노골적인 비방이자 개그입니다. 구성 요소를 더 쉽게 보고 분리할 수 있도록 의도적으로 문자열 유형을 선택했습니다. 내 솔루션의 기술을 첫 페이지에서 자세히 설명했습니다. 당신은 아무것도 설명하지 않았습니다. 나는 당신이 당신의 색 분해 방법이 어떻게 작동하는지 완전히 이해하고 있는지 확신하지 못합니다. 그렇지 않다면 저처럼 자세히 설명해 주십시오.
그리고 그런 큰 비난은 하지 마세요. 당신은 정말로 그들에게 스스로 미끄러질 수 있습니다.
이것은 노골적인 비방이자 개그입니다. 구성 요소를 쉽게 보고 분리할 수 있도록 의도적으로 문자열 유형을 선택했습니다. 내 솔루션의 기술을 첫 페이지에서 자세히 설명했습니다. 당신은 아무것도 설명하지 않았습니다. 나는 당신이 당신의 색 분해 방법이 어떻게 작동하는지 완전히 이해하고 있는지 확신하지 못합니다. 그렇지 않다면 저처럼 자세히 설명해 주십시오.
그리고 그렇게 큰 비난은 하지 마세요. 당신은 정말로 그들에게 스스로 미끄러질 수 있습니다.
죄송합니다. 방금 귀하의 설명을 읽었습니다.
먼저 색상을 세 가지 주요 구성 요소로 분해하여 최고, 중, 최저를 결정했습니다.
또한 구성 요소의 값을 통해 그래프를 만들고 선을 그리기 시작했습니다.
슬라이더를 끌 때 팔레트에서 숫자의 변화를 관찰하면서 특정 순간에 숫자의 변화율이 바뀌었기 때문에 선의 상승 각도의 굴절이 있다는 것을 깨달았습니다.
선의 굴절축을 그래프의 중앙으로 설정하고 각 선이 각각 고유한 상승각을 갖는 두 개의 세그먼트로 구성되어 있음을 확인했습니다.
또한 색상 팔레트를 실험하면서 가장 높은 구성 요소의 최대 상승 각도가 있음을 깨달았습니다. 처음에는 67.5도인 줄 알았습니다. 그러나 실습에 따르면 63.5도와 같습니다.
오랫동안 나는 색상 성분의 선분을 올바르게 그리는 방법을 알 수 없었습니다. 알려지지 않은 것이 많았습니다. 그러나 가장 중요한 것은 차트에서 원래 색상의 좌표를 찾는 방법입니다.
팔레트를 계속 실험하면서 색상 값 을 특정 숫자만큼 변경하면 슬라이더가 특정 거리를 이동한다는 것을 알았습니다. 점차적으로 슬라이더의 이동 거리는 보조 구성 요소 값의 절반과 같다는 것을 깨달았습니다.
최대상승각선에서 가장 높은 성분의 좌표를 찾아 이 점에 가장 낮은 성분의 값의 절반을 더하면 그래프에서 원래 색의 좌표를 찾게 된다고 가정했다. 실습을 통해 가정이 옳았다는 것이 입증되었습니다.
원래 색상의 좌표와 굴절 축이 주어지면 각 세그먼트의 각도를 계산하고 해당 선을 따라 각 구성 요소에 대한 값을 얻을 수 있습니다. 이를 위해 학교 삼각법을 사용했습니다.
난 할 수 없어. 모든 것이 나에게 더 산문적이고 원시적입니다. 코드 자체보다 더 광범위하게 설명하기는 어렵습니다.
당신은 내 알고리즘을 취하고 당신의 재량에 따라 라인을 변경 한 다음 다른 플랫폼에서 시작하여 그리기 기술에 따라 화면에 표시했습니다. 독립적인 변경을 너무 많이 해서 내 알고리즘을 자신이 어떻게 변경했는지 눈치 채지 못한 것처럼 판단하고 다른 조건에 넣습니다. 자신이 착각할 수 있는 조건. 그럼 알아보도록 하겠습니다.
당신은 내 알고리즘을 취하고 당신의 재량에 따라 라인을 변경 한 다음 다른 플랫폼에서 시작하여 그리기 기술에 따라 화면에 표시했습니다. 독립적인 변경을 너무 많이 해서 내 알고리즘을 자신이 어떻게 변경했는지 눈치 채지 못한 것처럼 판단하고 다른 조건에 넣습니다. 자신이 착각할 수 있는 조건. 그럼 알아보도록 하겠습니다.
Peter, 세 숫자의 256 조합 형태로 경고에 색상이 필요하지 않습니다. 색상이 필요합니다. 함수에서 내가 한 것은 색상을 문자열 대신 uint로 변환하는 것뿐이었습니다. 나는 당신의 알고리즘에 맞지 않았습니다. 그 논리가 저를 넘어섰기 때문입니다.
흰색 또는 검정색으로 한 가지 색상의 그라디언트가 필요한 경우 이 기능을 사용하여 이러한 방식으로 얻을 수 있습니다.
color clr= clrViolet ;
uint CLR[];
Gradient( clrWhite , clr, CLR, 100 ); // получаем массив из 100 элементов градиента от белого цвета до цвета clr
Gradient(clr, clrBlack , CLR, 100 ); // получаем массив из 100 элементов градиента от цвета clr до черног цвета
Peter, 문제는 포럼에 모든 사람이 색상 분해를 보고 적용할 수 있는 기능을 게시했다는 것입니다. 그러나 이 함수는 원하는 색상 배열을 형성하지 않고 화면에 그라데이션을 표시하는 대신 Print 출력 에만 적합한 문자열 배열만 형성합니다. 이것은 찌르는 돼지이며 다른 사람을 존중하지 않습니다. 누군가 필요하면 번역하십시오.
이것은 노골적인 비방이자 개그입니다. 구성 요소를 더 쉽게 보고 분리할 수 있도록 의도적으로 문자열 유형을 선택했습니다. 내 솔루션의 기술을 첫 페이지에서 자세히 설명했습니다. 당신은 아무것도 설명하지 않았습니다. 나는 당신이 당신의 색 분해 방법이 어떻게 작동하는지 완전히 이해하고 있는지 확신하지 못합니다. 그렇지 않다면 저처럼 자세히 설명해 주십시오.
그리고 그런 큰 비난은 하지 마세요. 당신은 정말로 그들에게 스스로 미끄러질 수 있습니다.
이것은 노골적인 비방이자 개그입니다. 구성 요소를 쉽게 보고 분리할 수 있도록 의도적으로 문자열 유형을 선택했습니다. 내 솔루션의 기술을 첫 페이지에서 자세히 설명했습니다. 당신은 아무것도 설명하지 않았습니다. 나는 당신이 당신의 색 분해 방법이 어떻게 작동하는지 완전히 이해하고 있는지 확신하지 못합니다. 그렇지 않다면 저처럼 자세히 설명해 주십시오.
그리고 그렇게 큰 비난은 하지 마세요. 당신은 정말로 그들에게 스스로 미끄러질 수 있습니다.
죄송합니다. 방금 귀하의 설명을 읽었습니다.
난 할 수 없어. 모든 것이 나에게 더 산문적이고 원시적입니다.
코드 자체보다 더 광범위하게 설명하기는 어렵습니다.
다시:
이것은 알고리즘의 정확성에 대한 최상의 테스트입니다.
그런 다음 속도 테스트로 이동할 수 있습니다.
당신은 내 알고리즘을 취하고 당신의 재량에 따라 라인을 변경 한 다음 다른 플랫폼에서 시작하여 그리기 기술에 따라 화면에 표시했습니다. 독립적인 변경을 너무 많이 해서 내 알고리즘을 자신이 어떻게 변경했는지 눈치 채지 못한 것처럼 판단하고 다른 조건에 넣습니다. 자신이 착각할 수 있는 조건. 그럼 알아보도록 하겠습니다.
다시:
이것은 알고리즘의 정확성에 대한 최상의 테스트입니다.
그런 다음 속도 테스트로 이동할 수 있습니다.
당신은 내 알고리즘을 취하고 당신의 재량에 따라 라인을 변경 한 다음 다른 플랫폼에서 시작하여 그리기 기술에 따라 화면에 표시했습니다. 독립적인 변경을 너무 많이 해서 내 알고리즘을 자신이 어떻게 변경했는지 눈치 채지 못한 것처럼 판단하고 다른 조건에 넣습니다. 자신이 착각할 수 있는 조건. 그럼 알아보도록 하겠습니다.
Peter, 세 숫자의 256 조합 형태로 경고에 색상이 필요하지 않습니다. 색상이 필요합니다. 함수에서 내가 한 것은 색상을 문자열 대신 uint로 변환하는 것뿐이었습니다. 나는 당신의 알고리즘에 맞지 않았습니다. 그 논리가 저를 넘어섰기 때문입니다.
Peter, 세 숫자의 256 조합 형태로 경고에 색상이 필요하지 않습니다. 색상이 필요합니다. 함수에서 내가 한 것은 색상을 문자열 대신 uint로 변환하는 것뿐이었습니다. 나는 당신의 알고리즘에 맞지 않았습니다. 그 논리가 저를 넘어섰기 때문입니다.
번호 확인이 가장 좋습니다. 색상의 색조를 눈으로 실제로 비교할 수는 없습니다. 여기에서 모니터가 다르고 인식이 다를 수 있습니다. 따라서 숫자는 최고의 테스트입니다.
그리고 거기에는 초월적인 논리가 없습니다. 학교 삼각법.
1. 6개의 선분의 각도를 계산해야 합니다.
2. 그런 다음 이러한 세그먼트의 각 지점에서 값을 계산하고 배열에 씁니다.
모두.
번호 확인이 가장 좋습니다. 실제로 색상의 색조를 눈으로 비교할 수는 없습니다. 여기에서 모니터가 다르고 인식이 다를 수 있습니다. 따라서 숫자는 최고의 테스트입니다.
그리고 거기에는 초월적인 논리가 없습니다. 학교 삼각법.
1. 6개의 선분의 각도를 계산해야 합니다.
2. 그런 다음 이러한 세그먼트의 각 지점에서 값을 계산하고 배열에 씁니다.
모두.
그러나 실제로 내 기능은 결함 없이 작동하며 4배 더 빠릅니다. 5-ke에 알고리즘을 제공하면 결과를 기다리고 있습니다. 단순히 클립보드를 통해 복사하는 데 시간이 걸렸지만 당신을 위해 조금 더 오래 걸렸습니다.
그러나 실제로 내 기능은 결함 없이 작동하며 4배 더 빠릅니다. 5-ke에 알고리즘을 제공할 때 결과를 기다리고 있습니다. 단순히 클립보드를 통해 복사하는 데 시간이 걸렸지만 당신을 위해 조금 더 오래 걸렸습니다.
니콜라이, 유치원 같아요. "4배 더 빠르다"는 진술은 입증되지 않았기 때문에 유효하지 않습니다.
어떤 이유에서인지 이 선은 전체 사각형의 그리기에 영향을 줍니다. 그러나 이것은 내 결함이 아닙니다. 확인하다.
나는 당신이 나타난 결함을 계속 이해합니다. 내 알고리즘 때문에 유효한지 알고 싶습니다.
그리고 불필요한 숫자 깜박임을 끕니다. 불필요한 것을 모두 제거하십시오. 하나의 초기 색상의 그라디언트가 있는 간단한 직사각형이 한 번 표시되도록 합니다. 추가 주름이 없습니다.
흰색 또는 검정색으로 한 가지 색상의 그라디언트가 필요한 경우 이 기능을 사용하여 이러한 방식으로 얻을 수 있습니다.
번호 확인이 가장 좋습니다. 색상의 색조를 눈으로 실제로 비교할 수는 없습니다. 여기에서 모니터가 다르고 인식이 다를 수 있습니다. 따라서 숫자는 최고의 테스트입니다.
나는 "고발"에 합류 할 것입니다, 나는 그것을 참을 수 없었습니다 :)
프로그래밍하지 않는 방법의 좋은 예입니다. 전체 GUI가 이런 식으로 작성되면 곧 볼 수 없습니다. :(
모든 라인은 "걸작"입니다. 오류와 실수의 덩어리, mql4가 그것을 제거하기를 희망합니다. 이제 MT4가 사용되는 이유가 명확해졌습니다.
그런 코드의 공개와 그에 따른 비판에 대한 반응은 포럼의 청중을 존중하는 것이 아니라고 생각합니다. 당신은 피해를 원하지 않습니다 - 그들은 당신을 돕고 싶어합니다.
그리고 알고리즘 비교에 대해서는 시각적으로 비교할 수 있습니다. 알고리즘이 "Windows 음영"에 99% 가까운 음영을 제공한다는 숫자의 증거를 제공하지 않았습니다.
왼쪽 - 접근하는 것처럼 오른쪽 - Nikolai Semko . (수정된 Nikolai Semko 스크립트가 사용되었습니다)