따라서 모든 것이 뒤섞여 있습니다. 포럼의 엔진이 다기능입니까? REST에 대해 읽었지만 이것은 베어 아키텍처입니다. 이에 대한 포럼 소스를 찾아야 합니까?
다른 스크립트를 재생할 수 있다는 것은 무엇을 의미합니까? 어디서 재생할 수 있습니까? 단순한 사용자에게 제품을 판매하고 제품이 제공하는 것과 함께 제공되는 것을 인간적인 방식으로 설명하고 싶다고 상상해 보십시오. 꼭 필요하고 중요한 것 같은데 왜 그런지 모르겠네요 감사합니다.
동일한 패턴을 사용하여 Python 라이브러리에서 사용할 수 있는 수백 개의 ML 모델 중 하나를 생성하고 데이터에 대해 훈련할 수 있습니다. 동일한 패턴을 사용하여 Expert Advisor 또는 표시기에서 클라이언트 부분을 생성할 수 있습니다. 초기화 시 모델 파일을 로드한 다음 Predict를 호출하여 틱별로 또는 바별로 폴링합니다. 현재 데이터가 있는 메서드.
NamedPipes 및 REST 프로토콜에 대한 지원을 통해 지정된 스크립트, 조언자 또는 표시기가 로컬 컴퓨터와 네트워크에서 원격으로 MO 모델이 있는 DLL 없이 작동할 수 있습니다. NamedPipes와 달리 REST를 사용할 때 MQL의 스크립트 텍스트는 FileWriteString이 아니라 WebRequest를 통해 네트워크에서 사용할 수 있는 공개 URL(예: 엔진이 실행 중인 VPS)로 보내야 합니다. 그렇지 않으면 모든 것이 동일합니다.
동일한 패턴을 사용하여 Python 라이브러리에서 사용할 수 있는 수백 개의 ML 모델 중 하나를 생성하고 데이터에 대해 훈련할 수 있습니다. 동일한 패턴을 사용하여 Expert Advisor 또는 표시기에서 클라이언트 부분을 생성할 수 있습니다. 초기화 시 모델 파일을 로드한 다음 Predict를 호출하여 틱별로 또는 바별로 폴링합니다. 현재 데이터가 있는 메서드.
NamedPipes 및 REST 프로토콜에 대한 지원을 통해 지정된 스크립트, 조언자 또는 표시기가 로컬 컴퓨터와 네트워크에서 원격으로 MO 모델이 있는 DLL 없이 작동할 수 있습니다. NamedPipes와 달리 REST를 사용할 때 MQL의 스크립트 텍스트는 FileWriteString이 아니라 WebRequest를 통해 네트워크에서 사용할 수 있는 공개 URL(예: 엔진이 실행 중인 VPS)로 보내야 합니다. 그렇지 않으면 모든 것이 동일합니다.
어제 저는 그들이 왜 의사결정나무를 찾는지 생각해 냈습니다. 엔티티를 설명하는 모델? 저것들. 전체 본질을 일반적으로 설명해야 하는 이유는 무엇입니까? 아마도 이 본질에서 가장 이해하기 쉽고 예측 가능한 부분을 찾아야 하는 것일까요? 나는 나무에서 잎을 수집하기 때문에 완전한 의사 결정 트리를 구축하지 않고 그러한 잎을 검색하는 방법을 사용해야 할 수도 있다고 생각했습니다. 컴퓨팅 시간을 보냈다.
나는 인터넷에 머리를 찔러 보았고 어디에도 이와 같은 것을 보지 못했습니다. 누군가가 그러한 발전에 대해 알고 있습니까?
알고리즘을 구상하는 동안 가장 먼저 해야 할 일은 클래스 중 하나의 예측 능력이 두드러지는 예측자를 선택하는 반면 예측자는 분명히 이진화해야 한다고 생각합니다. 각 예측 변수에 대해 고유한 샘플을 구성하거나 일반 샘플에서 제외 범위를 만들어야 합니다(더 합리적인?). 그런 다음 선택한 예측 변수(및 이들의 조합)를 사용하여 특정 클래스(내 경우에는 3개 클래스)에 대한 그루터기를 구축하고 이 그루터기에 나머지 예측자를 구축합니다. 동시에 특정 클래스의 선호도도 확인할 수 있습니다. 그런 다음 아이디어에 따라 특정 대상에서 가장 분류하기 쉬운 영역을 찾습니다. 그리고 나머지 영역은 비활성/대기 영역일 것입니다.
물론 그런 다음 나뭇잎이 서로 겹쳐진 위치를 볼 수 있으며 이러한 경우 평균 결과를 얻을 수 있습니다. 예, 나무 모양은 나중에 이런 방식으로 만들 수 있지만 다른 대상 영역의 다른 영역에 밀도로 인해 투표 요소가 있습니다.
여기 많은 사람들이 아이디어를 표현하고 일부는 메커니즘을 제안하고 알고리즘을 제안하며 때로는 구현에 이르기까지 기성 프로그램을 구현하지만 불행히도 진전이 없고 실질적인 결과가 없으며 기본적으로 모든 것이 홍수와 불합리한 선언으로 끝납니다.
아마도 이것은 데이터 형식, 모델 및 작업 결과에 대한 객관적인 평가와 같은 거래를 위한 ML 도구에 대한 통합된 보기가 없기 때문에 서로 건설적으로 의사 소통하고 실험 결과를 공유하며 합리적인 결론을 도출할 수 없기 때문일 수 있습니다. .
그리고 IR 개발을 위해 모인 팀의 상황이 개별 수행자-개발자에 대한 객관적인 평가 방법이 없다면 요점이 무엇입니까?))
아마도 그러한 방법의 생성 및 조정으로 시작하여 ML 분기에서 이 문제를 제기하려는 시도가 있었지만 지금까지는 상호 이해가 없었습니다. 이 주제의 애호가로서 성공할 수 있을까요?
나는 표준 평가가 적합하지 않다는 데 동의합니다. 앞서 이에 대해 썼습니다. 이것은 트렌드 전략과 관련하여 특히 분명합니다. 몇 가지 기본 전략에 대한 최적의 평가 기준을 찾은 다음 개발을 다른 전략에 이식하는 것이 좋습니다. MO에 대한 스레드에서 그들은 주로 바가 열릴 때 어떻게 닫힐지 예측하려고 노력합니다. 그리고 거기에서 추측/추측하지 않은 메트릭이 계속 나타날 수 있지만 추세 전략은 말할 것도 없고 평가에서 포인트도 고려해야 합니다.
아래 그림에서 사각형 번호 1에서 판매 항목은 사각형 2보다 훨씬 낫습니다(더 많은 이익을 가져옴). 여기에서도 이익이 있지만 이미 사각형 3에는 판매 시 손실이 있는 마감이 있습니다. 자산이지만 이것은 또한 최소 가격이 형성될 때까지 자산을 구매할 때 가져오지 않을 이익입니다.
따라서 항목의 추측 백분율이 클 수 있음을 알 수 있지만 이 큰 값이 첫 번째가 아닌 두 번째 사각형에 더 집중되어 있으면 더 작은 오류 값이 모든 이익을 커버할 수 있습니다.
따라서 이제 내 모델을 평가할 때 신호의 집중도를 고려하고 싶습니다. 어느 영역에서 더 많은 이익 또는 손실을 제공하는지 확인하고 의사 결정 트리를 구축할 때 이를 고려합니다.
따라서 명령이 취소됩니다. )
그리고 관리되는 그룹이 있을 것입니다. )
95%의 확률로 이미 구축된 팀에도 관리를 도입하면 결과가 사라집니다.
그리고 아직 존재하지 않는 것을 관리하려면 매우 강력한 비장의 카드가 있어야 합니다. ))
트럼프 카드를 보여줄 시간입니다.
공급은 있지만 어떤 형태로든 수요의 표현이 없습니다.
이 단계에서 잠재적인 팀원이 활동하기를 원하지 않는다면 그들의 동기가 확실하지 않습니다.
너무 슬퍼.
관리 없이는 앞으로 나아갈 수 없습니다. 참가자가 스스로 이동 방향을 선택하는 계획을 제안했는데 가장 편안한 조건을 상상하기 어렵습니다.
이 목록에서 순무도 GitLab에 등록되지 않았습니다 ...
팀은 Apache 2.0 라이선스에 따라 즉시 구성되어야 했으며, 낯선 사람이 협력 윤리를 준수하도록 강제하고 싶었습니다.
음, nayalnik은 소프트웨어 개발에 대해 전혀 이해하지 못합니다.
등록은 몇 분 만에 완료되며 형식에 불과합니다.
팀은 자신과 팀원 모두의 이익을 위해 일해야 하며 기분에 따라 코를 고르지 않아야 합니다.
아이디어를 개발하는 것과 그것을 코딩하는 것은 별개입니다.
등록은 몇 분 만에 완료되며 형식에 불과합니다.
팀은 자신과 팀원 모두의 이익을 위해 일해야 하며 기분에 따라 코를 고르지 않아야 합니다.
아이디어를 개발하는 것과 그것을 코딩하는 것은 별개입니다.
"분의 문제"라면 왜 완료되지 않습니까? 팀이 없기 때문에 작업 공간이 없습니다. 작업실이 없으니 팀도 없고...
그리고 이 영역에서 아이디어는 최소한 의사 코드로 즉시 구현되어야 합니다.
"분의 문제"라면 왜 완료되지 않습니까? 팀이 없기 때문에 작업 공간이 없습니다. 작업실이 없으니 팀도 없고...
그리고 이 영역에서 아이디어는 최소한 의사 코드로 즉시 구현되어야 합니다.
사람들이 함께 일하기를 원하지 않기 때문에 팀이 없습니다. 모든 사람(대부분)은 다른 사람의 아이디어를 듣는 데 관심이 있으며 Maxim이 제안한 형식은 채팅에 적합합니다.
현재의 불신과 두려움의 단계에서 자신의 성배 를 드러내는 것은 이해관계에 기반한 커뮤니케이션의 변형일 수 있습니다.
이를 수행하기 전에 최종적으로 어떻게 보일지 이해해야 합니다. 계획된 개요가 있어야 합니다. 저는 사람들이 워크플로의 구성에 대해 이야기할 것을 제안했습니다. 이러한 소망을 고려하여 작업 공간을 구성하십시오.
시민 - 모든 것이 우리 손에 있습니다!
시장은 개인의 심리적 문제를 해결하는 곳이 아니라 소득을 창출하는 곳입니다!
이 거상을 혼자 움직이지 마십시오.
따라서 모든 것이 뒤섞여 있습니다. 포럼의 엔진이 다기능입니까? REST에 대해 읽었지만 이것은 베어 아키텍처입니다. 이에 대한 포럼 소스를 찾아야 합니까?
다른 스크립트를 재생할 수 있다는 것은 무엇을 의미합니까? 어디서 재생할 수 있습니까? 단순한 사용자에게 제품을 판매하고 제품이 제공하는 것과 함께 제공되는 것을 인간적인 방식으로 설명하고 싶다고 상상해 보십시오. 꼭 필요하고 중요한 것 같은데 왜 그런지 모르겠네요 감사합니다.
그리고 설명할 것이 무엇인지, 위에서 MQL 스크립트에서 로컬 컴퓨터에 설치된 파이썬에 액세스하고, 신경망 모델을 훈련하고, 파일에 저장하고, 로드하고, 예측 방법.
https://www.mql5.com/ru/forum/261479/page16#comment_8011085
동일한 패턴을 사용하여 Python 라이브러리에서 사용할 수 있는 수백 개의 ML 모델 중 하나를 생성하고 데이터에 대해 훈련할 수 있습니다. 동일한 패턴을 사용하여 Expert Advisor 또는 표시기에서 클라이언트 부분을 생성할 수 있습니다. 초기화 시 모델 파일을 로드한 다음 Predict를 호출하여 틱별로 또는 바별로 폴링합니다. 현재 데이터가 있는 메서드.
NamedPipes 및 REST 프로토콜에 대한 지원을 통해 지정된 스크립트, 조언자 또는 표시기가 로컬 컴퓨터와 네트워크에서 원격으로 MO 모델이 있는 DLL 없이 작동할 수 있습니다.
NamedPipes와 달리 REST를 사용할 때 MQL의 스크립트 텍스트는 FileWriteString이 아니라 WebRequest를 통해 네트워크에서 사용할 수 있는 공개 URL(예: 엔진이 실행 중인 VPS)로 보내야 합니다. 그렇지 않으면 모든 것이 동일합니다.
그리고 설명할 것이 무엇인지, 위에서 MQL 스크립트에서 로컬 컴퓨터에 설치된 파이썬에 액세스하고, 신경망 모델을 훈련하고, 파일에 저장하고, 로드하고, 예측 방법.
https://www.mql5.com/ru/forum/261479/page16#comment_8011085
동일한 패턴을 사용하여 Python 라이브러리에서 사용할 수 있는 수백 개의 ML 모델 중 하나를 생성하고 데이터에 대해 훈련할 수 있습니다. 동일한 패턴을 사용하여 Expert Advisor 또는 표시기에서 클라이언트 부분을 생성할 수 있습니다. 초기화 시 모델 파일을 로드한 다음 Predict를 호출하여 틱별로 또는 바별로 폴링합니다. 현재 데이터가 있는 메서드.
NamedPipes 및 REST 프로토콜에 대한 지원을 통해 지정된 스크립트, 조언자 또는 표시기가 로컬 컴퓨터와 네트워크에서 원격으로 MO 모델이 있는 DLL 없이 작동할 수 있습니다.
NamedPipes와 달리 REST를 사용할 때 MQL의 스크립트 텍스트는 FileWriteString이 아니라 WebRequest를 통해 네트워크에서 사용할 수 있는 공개 URL(예: 엔진이 실행 중인 VPS)로 보내야 합니다. 그렇지 않으면 모든 것이 동일합니다.
일반적으로 계산된 모델을 활성화하기 위한 도구임이 분명합니다.
하지만 나는 여전히 전략 옵티마이저가 어떻게 돌아가는지 이해하지 못합니다...
나는 나무에 나의 생각을 남길 것이고, 그것들은 갑자기 유용할 것입니다.
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
거래에서의 기계 학습: 이론 및 실습(거래 등)
알렉세이 비아즈미킨 , 2018.07.10 14:18
어제 저는 그들이 왜 의사결정나무를 찾는지 생각해 냈습니다. 엔티티를 설명하는 모델? 저것들. 전체 본질을 일반적으로 설명해야 하는 이유는 무엇입니까? 아마도 이 본질에서 가장 이해하기 쉽고 예측 가능한 부분을 찾아야 하는 것일까요? 나는 나무에서 잎을 수집하기 때문에 완전한 의사 결정 트리를 구축하지 않고 그러한 잎을 검색하는 방법을 사용해야 할 수도 있다고 생각했습니다. 컴퓨팅 시간을 보냈다.
나는 인터넷에 머리를 찔러 보았고 어디에도 이와 같은 것을 보지 못했습니다. 누군가가 그러한 발전에 대해 알고 있습니까?
알고리즘을 구상하는 동안 가장 먼저 해야 할 일은 클래스 중 하나의 예측 능력이 두드러지는 예측자를 선택하는 반면 예측자는 분명히 이진화해야 한다고 생각합니다. 각 예측 변수에 대해 고유한 샘플을 구성하거나 일반 샘플에서 제외 범위를 만들어야 합니다(더 합리적인?). 그런 다음 선택한 예측 변수(및 이들의 조합)를 사용하여 특정 클래스(내 경우에는 3개 클래스)에 대한 그루터기를 구축하고 이 그루터기에 나머지 예측자를 구축합니다. 동시에 특정 클래스의 선호도도 확인할 수 있습니다. 그런 다음 아이디어에 따라 특정 대상에서 가장 분류하기 쉬운 영역을 찾습니다. 그리고 나머지 영역은 비활성/대기 영역일 것입니다.
물론 그런 다음 나뭇잎이 서로 겹쳐진 위치를 볼 수 있으며 이러한 경우 평균 결과를 얻을 수 있습니다. 예, 나무 모양은 나중에 이런 방식으로 만들 수 있지만 다른 대상 영역의 다른 영역에 밀도로 인해 투표 요소가 있습니다.
이 아이디어에 대해 어떻게 생각하세요?
나는 나무에 나의 생각을 남길 것이고, 그것들은 갑자기 유용할 것입니다.
여기 많은 사람들이 아이디어를 표현하고 일부는 메커니즘을 제안하고 알고리즘을 제안하며 때로는 구현에 이르기까지 기성 프로그램을 구현하지만 불행히도 진전이 없고 실질적인 결과가 없으며 기본적으로 모든 것이 홍수와 불합리한 선언으로 끝납니다.
아마도 이것은 데이터 형식, 모델 및 작업 결과에 대한 객관적인 평가와 같은 거래를 위한 ML 도구에 대한 통합된 보기가 없기 때문에 서로 건설적으로 의사 소통하고 실험 결과를 공유하며 합리적인 결론을 도출할 수 없기 때문일 수 있습니다. .
그리고 IR 개발을 위해 모인 팀의 상황이 개별 수행자-개발자에 대한 객관적인 평가 방법이 없다면 요점이 무엇입니까?))
아마도 그러한 방법의 생성 및 조정으로 시작하여 ML 분기에서 이 문제를 제기하려는 시도가 있었지만 지금까지는 상호 이해가 없었습니다. 이 주제의 애호가로서 성공할 수 있을까요?
여기 많은 사람들이 아이디어를 표현하고 일부는 메커니즘을 제안하고 알고리즘을 제안하며 때로는 구현에 이르기까지 기성 프로그램을 구현하지만 불행히도 진전이 없고 실질적인 결과가 없으며 기본적으로 모든 것이 홍수와 불합리한 선언으로 끝납니다.
아마도 이것은 데이터 형식, 모델 및 작업 결과에 대한 객관적인 평가와 같은 거래를 위한 ML 도구에 대한 통합된 보기가 없기 때문에 서로 건설적으로 의사 소통하고 실험 결과를 공유하며 합리적인 결론을 도출할 수 없기 때문일 수 있습니다. .
그리고 IR 개발을 위해 모인 팀의 상황이 개별 수행자-개발자에 대한 객관적인 평가 방법이 없다면 요점이 무엇입니까?))
아마도 그러한 방법의 생성 및 조정으로 시작하여 ML 분기에서 이 문제를 제기하려는 시도가 있었지만 지금까지는 상호 이해가 없었습니다. 이 주제의 애호가로서 성공할 수 있을까요?
나는 표준 평가가 적합하지 않다는 데 동의합니다. 앞서 이에 대해 썼습니다. 이것은 트렌드 전략과 관련하여 특히 분명합니다. 몇 가지 기본 전략에 대한 최적의 평가 기준을 찾은 다음 개발을 다른 전략에 이식하는 것이 좋습니다. MO에 대한 스레드에서 그들은 주로 바가 열릴 때 어떻게 닫힐지 예측하려고 노력합니다. 그리고 거기에서 추측/추측하지 않은 메트릭이 계속 나타날 수 있지만 추세 전략은 말할 것도 없고 평가에서 포인트도 고려해야 합니다.
아래 그림에서 사각형 번호 1에서 판매 항목은 사각형 2보다 훨씬 낫습니다(더 많은 이익을 가져옴). 여기에서도 이익이 있지만 이미 사각형 3에는 판매 시 손실이 있는 마감이 있습니다. 자산이지만 이것은 또한 최소 가격이 형성될 때까지 자산을 구매할 때 가져오지 않을 이익입니다.
따라서 항목의 추측 백분율이 클 수 있음을 알 수 있지만 이 큰 값이 첫 번째가 아닌 두 번째 사각형에 더 집중되어 있으면 더 작은 오류 값이 모든 이익을 커버할 수 있습니다.
따라서 이제 내 모델을 평가할 때 신호의 집중도를 고려하고 싶습니다. 어느 영역에서 더 많은 이익 또는 손실을 제공하는지 확인하고 의사 결정 트리를 구축할 때 이를 고려합니다.