Mathemat : 지표에 적용된 규칙을 기반으로 전략을 시각적으로 생성하는 기능. Trading Solutions의 시각적 환경에서 구현되는 것과 같습니다. 신호를 확인하기 위해 어드바이저의 코드를 생성하여 표시기를 어지럽힐 필요가 없어 편리합니다.
과하다고 생각합니다.
어셈블리 언어가 필요하지 않을 수도 있지만 모든 임시 기록은 코드에서 손으로 만들어야 합니다. 그렇지 않으면 많은 전략이 시각 기술의 가능성에 의해 제한될 것입니다. 오히려 이런 방향으로 도서관이 필요하다.
-------
어떻게든 지역 변수와 전역 변수의 이름이 일치하는 경우를 처리해야 합니다. 허용하지 않습니다.
----
터미널이 로그 파일이 많은 조건에서 작동하면 성능이 크게 저하됩니다. 테스트 및 반나절 작업 후 길을 잃은 것은 이것을 분명히 보여줍니다. 주기적으로 디스크에 대량의 정보를 덤프하여 파일 이름을 날짜뿐 아니라 시간별로 지정해야 합니다. 일반적으로 주기적으로 완화 .. :)
어떻게든 지역 변수와 전역 변수의 이름이 일치하는 경우를 처리해야 합니다. 허용하지 않습니다.
왜 그런 전역 변수 가 필요한지 전혀 명확하지 않습니다. 한 번 사용하고 나에게 쓸모가 없다는 것을 깨달았습니다. 많은 작업이 거의 쓸모가 없습니다 ... 그리고 지역 변수에 관해서는이 경우에보고 싶습니다. 클래스뿐만 아니라 네임스페이스도 확장되고 결국 응용 프로그램이 상당할 수 있으며 이러한 유쾌한 혼란이 시작되어 특히 프로젝트가 장기간인 경우 수천 개의 이름의 혼란에 빠지게 됩니다. 물론 수천 줄짜리 코드라면 아무 소용이 없지만 관점과 지원, 툴킷의 확장까지 생각한다면 그것 없이는 할 수 없다. 그러나 여기에서는 포럼과 동일할 것 같아서 MQL을 별로 믿지 않습니다. MQL 주제가 하나뿐인 경우 포럼에 섹션이 필요한 이유는 무엇입니까? 굳이 읽을 필요가 있는지 이해하기 위한 주제, 많은 행동, 부족함, 바로 관점입니다 :)
추신: 아마도 여기에서 내가 실제로 하는 유일한 일이 이것뿐이라는 사실로 판단하면 언젠가 나는 유명한 비평가가 될 것입니다. :) 솔직히, 나는 비판하기를 좋아하지 않지만 해야 합니다.
MQL5의 소원에 5개의 코펙을 기부하고 싶습니다. 그리고 겸손한 생각으로 우리가 어디로 움직여야 하는지 말씀드리고 싶습니다.
프로그래밍 언어 개발의 역사는 기계 코드로 시작하여 어셈블러, Fortran 등, 그 다음 OOP C++ 등, MathLab, MathСad가 최고의 성과라고 생각하는 특수 패키지(프로그래밍 언어)를 보여줍니다. . 저것들. 그들은 프로그래밍(기계어)에서 가능한 한 사람에게 더 가깝고 더 이해하기 쉬운 언어로 멀어지려고 노력합니다.
결국 MathCad에서 하는 것과 같은 형태로 프로그램(절차)을 작성하는 것이 훨씬 편리하고, 프로그래밍을 한 번도 해보지 않았지만 책에서 그런 공식을 본 사람도 이해할 수 있다.
그리고 이 형식으로 계산을 위해 호출합니다.
모든 것이 간단하고 쉬운 확률 = 0.5, 정규 분포 법칙 MOJ=mu, RMS=sigma의 적분을 적었습니다. 그리고 사건에 부딪힐 확률을 계산했습니다. 간격 Y1...Y2의 값(각각 10 및 무한대와 동일). 여기에 프로그래밍 언어 MathCad로 작성된 경우를 대비하여 설명합니다 :-)
동의합니다. 적분을 계산하는 방법과 사다리꼴 또는 Simpson + 기계어로 모든 것을 기록하고 모든 것을 디버그하는 방법을 기억하는 것보다 쉽습니다. 그것에 얼마나 많은 시간이 소요됩니다. MQL4에서 유사한 절차 Ver(.....)을 만들려고 하지만 여기 MathCad에서는 보시다시피 모든 것이 간단합니다.
따라서 개발자들에게 MathCad 프로그래밍 언어(많은 사람들은 이것이 더 이상 프로그래밍 언어가 아니라고 생각하기도 합니다 :-))에 관심을 가져달라고 요청합니다.
지표에 적용된 규칙을 기반으로 전략을 시각적으로 생성하는 기능. Trading Solutions의 시각적 환경에서 구현되는 것과 같습니다. 신호를 확인하기 위해 어드바이저의 코드를 생성하여 표시기를 어지럽힐 필요가 없어 편리합니다.
과하다고 생각합니다.
어셈블리 언어가 필요하지 않을 수도 있지만 모든 임시 기록은 코드에서 손으로 만들어야 합니다. 그렇지 않으면 많은 전략이 시각 기술의 가능성에 의해 제한될 것입니다. 오히려 이런 방향으로 도서관이 필요하다.
-------
어떻게든 지역 변수와 전역 변수의 이름이 일치하는 경우를 처리해야 합니다. 허용하지 않습니다.
----
터미널이 로그 파일이 많은 조건에서 작동하면 성능이 크게 저하됩니다. 테스트 및 반나절 작업 후 길을 잃은 것은 이것을 분명히 보여줍니다. 주기적으로 디스크에 대량의 정보를 덤프하여 파일 이름을 날짜뿐 아니라 시간별로 지정해야 합니다. 일반적으로 주기적으로 완화 .. :)
어떻게든 지역 변수와 전역 변수의 이름이 일치하는 경우를 처리해야 합니다. 허용하지 않습니다.
왜 그런 전역 변수 가 필요한지 전혀 명확하지 않습니다. 한 번 사용하고 나에게 쓸모가 없다는 것을 깨달았습니다. 많은 작업이 거의 쓸모가 없습니다 ... 그리고 지역 변수에 관해서는이 경우에보고 싶습니다. 클래스뿐만 아니라 네임스페이스도 확장되고 결국 응용 프로그램이 상당할 수 있으며 이러한 유쾌한 혼란이 시작되어 특히 프로젝트가 장기간인 경우 수천 개의 이름의 혼란에 빠지게 됩니다. 물론 수천 줄짜리 코드라면 아무 소용이 없지만 관점과 지원, 툴킷의 확장까지 생각한다면 그것 없이는 할 수 없다. 그러나 여기에서는 포럼과 동일할 것 같아서 MQL을 별로 믿지 않습니다. MQL 주제가 하나뿐인 경우 포럼에 섹션이 필요한 이유는 무엇입니까? 굳이 읽을 필요가 있는지 이해하기 위한 주제, 많은 행동, 부족함, 바로 관점입니다 :)
추신: 아마도 여기에서 내가 실제로 하는 유일한 일이 이것뿐이라는 사실로 판단하면 언젠가 나는 유명한 비평가가 될 것입니다. :) 솔직히, 나는 비판하기를 좋아하지 않지만 해야 합니다.
표시기 속성의 임의 창을 만들어야 합니다.
이러한 옵션의 속성을 변경할 수 있는 기능으로 이 창에 추가 옵션을 추가할 수 있습니다.
속성 창에 페이지를 추가할 수 있습니다. 이 페이지에 매개변수 그룹 배치...
MQL5의 소원에 5개의 코펙을 기부하고 싶습니다. 그리고 겸손한 생각으로 우리가 어디로 움직여야 하는지 말씀드리고 싶습니다.
프로그래밍 언어 개발의 역사는 기계 코드로 시작하여 어셈블러, Fortran 등, 그 다음 OOP C++ 등, MathLab, MathСad가 최고의 성과라고 생각하는 특수 패키지(프로그래밍 언어)를 보여줍니다. . 저것들. 그들은 프로그래밍(기계어)에서 가능한 한 사람에게 더 가깝고 더 이해하기 쉬운 언어로 멀어지려고 노력합니다.
결국 MathCad에서 하는 것과 같은 형태로 프로그램(절차)을 작성하는 것이 훨씬 편리하고, 프로그래밍을 한 번도 해보지 않았지만 책에서 그런 공식을 본 사람도 이해할 수 있다.
그리고 이 형식으로 계산을 위해 호출합니다.
모든 것이 간단하고 쉬운 확률 = 0.5, 정규 분포 법칙 MOJ=mu, RMS=sigma의 적분을 적었습니다. 그리고 사건에 부딪힐 확률을 계산했습니다. 간격 Y1...Y2의 값(각각 10 및 무한대와 동일). 여기에 프로그래밍 언어 MathCad로 작성된 경우를 대비하여 설명합니다 :-)
동의합니다. 적분을 계산하는 방법과 사다리꼴 또는 Simpson + 기계어로 모든 것을 기록하고 모든 것을 디버그하는 방법을 기억하는 것보다 쉽습니다. 그것에 얼마나 많은 시간이 소요됩니다. MQL4에서 유사한 절차 Ver(.....)을 만들려고 하지만 여기 MathCad에서는 보시다시피 모든 것이 간단합니다.
따라서 개발자들에게 MathCad 프로그래밍 언어(많은 사람들은 이것이 더 이상 프로그래밍 언어가 아니라고 생각하기도 합니다 :-))에 관심을 가져달라고 요청합니다.
안녕하세요!
향후 터미널에서 폴더에서 인용문을 가져오는 것을 보고 싶습니다.
따라서 MQL 웹사이트에서 견적 아카이브를 파일로 간단히 다운로드할 수 있습니다.
바로 설명하겠습니다.
특히 긴 역사의 경우 인용 아카이브를 로드할 때 많은 시간이 걸립니다.
그리고 파일을 다운로드하고 폴더에 넣고 밤 에 이 폴더에 터미널을 설정할 수 있습니다! :)
아침이 되면 시세 아카이브에 모든 악기에 대한 모든 데이터가 있을 것입니다! :)
특히 긴 역사의 경우 인용 아카이브를 로드할 때 많은 시간이 걸립니다.
파일을 다운로드할 수 있도록 폴더에 넣습니다.
이것은 개인적인 일시적인 어려움과 얇은 채널과 관련된 나쁜 주장입니다. 그런 기능에 시간을 낭비할 이유가 없다고 생각합니다.
전문가의 속성 패널에서 가져온 함수의 외부 변수를 표시할 수 있으면 좋을 것입니다.
(기본 프로그램은 사용자 기능을 연결하는 표준 기능이 있는 ex4라고 가정합니다. 튜닝 및 특히 최적화 시 외부 변수가 필요합니다)
특히 긴 역사의 경우 인용 아카이브를 로드할 때 많은 시간이 걸립니다.
파일을 다운로드할 수 있도록 폴더에 넣습니다.
이것은 개인적인 일시적인 어려움과 얇은 채널과 관련된 나쁜 주장입니다. 그런 기능에 시간을 낭비할 이유가 없다고 생각합니다.
그리고 1999년의 분 기록을 다운로드한 다음 모든 시간 프레임을 다시 계산하려고 합니다.
그리고 결과 시간 에 도구 수를 곱하십시오.
또한 이 작업을 수행하려면 컴퓨터를 떠나서는 안 됩니다.
옵션으로 "모든 상품에 대한 기록 다운로드" 또는 "선택한 상품에 대해..." 버튼을 견적 아카이브에 추가하십시오.
전적으로 동의합니다 !!!
더. (터미널과 일반적으로 상호 관련됨)
1. 딜러가 사이트에 일부 정보를 게시한다는 사실이 좋으며,
그러나 이 정보가 터미널에 브로드캐스트되면 훨씬 더 유용 할 것 입니다.
따라서 μl 을 통해 정보에 액세스하려면 ...
2. 아마도 더 좋을 것입니다 ...
바로 이 정보가 수집되어 단일 센터에 보관되었습니다.
저것들. "재정 문제"를 제거하고 딜러는 구독 여부를 선택합니다.
정보는 일부 정적이고 접근 가능한 정보로 이해되며,
예: 금리 , 숫자로 된 뉴스...등...
"03/01/2008 15:30 CPI = 100 102" 형식의 "날짜, 시간, 무엇, 값, 예측,"
딜러의 캘린더(자신의 캘린더)는 터미널에서 보기가 훨씬 더 편리합니다.
또한 차트에 출력을 동시에 자동화할 수 있습니다. ..