기고글 토론 "자동 거래 시스템(Automata-Based Programming)을 위한 새로운 접근 방식" - 페이지 3

새 코멘트
 
Rorschach:

"3. 호기심이 생겨서 실제 진드기의 백색 소음을 듣고 싶었는데, WaveLab 6.0 소프트웨어를 사용하여 그렇게 할 수 있었습니다."

Hee. 저만 이런 미친놈이 아니었나 봐요))))) 제가 얻은 결과물입니다. Adobe Audience를 통해 만들었습니다.

가격을 어떻게 정상화했나요?

평소와 같이 긴 꼬리를 잘라내어 3 * 스코를 초과하는 모든 것을이 값으로 가져옵니다.
 

수많은 감정

1) 많은 부카프 아무것도 ...

2) 이것을 보면 왜 미국인들이 지금 화성에 있고 우리가 아닌지 깨닫기 시작합니다.

3) 나머지에 대해서는 침묵하고 싶습니다 (감정만을 위해).

 

특히 현대의 프로그램 개발 및 문서화 관행에 관한 기사가 마음에 들었습니다. 그게 바로 그것입니다.

물론이 기사는 오토 마타 방법을 기반으로 한 가장 간단한 전문가 조언자를 보여 주었어야했습니다. 아니면 다음 기사에서 다룰 예정인가요?

그리고 제 생각에는 오토마타 방법의 한 가지 큰 문제점이 있습니다. 실제 전문가 어드바이저의 경우 상태를 명확하게 정의하는 것이 불가능합니다. 전문가 조언자의 상태는 사용자 컴퓨터의 일부 내부 변수와 서버의 포지션 상태(현재 금리, 편일예탁잔고, 주문 체결)에 의해 결정됩니다. 내부 상태는 명확하게 결정되지만 서버의 포지션 상태는 알 수 없거나 지연되어 알려지거나 불분명 한 상태 (일부 주문 및 요청이 실행되고 일부는 실행되지 않으며 그 이유를 알 수 없음)일 수 있습니다.

그리고 어드바이저의 현재 상태를 알 수 없으므로 주문과 요청이 실행되지 않으므로 명확한 오토마타 로직을 구축하는 것은 불가능합니다. 실제로는 다음과 같은 알고리즘을 얻습니다:

comp: 서버, 나한테 몇백 유로를 사줘.

server: 엿 먹어, comp, 요청의 정류장이 잘못되었습니다.

comp: 왜 잘못된 건가요?

server: 그래서 가격이 뛰었죠.

comp: 그럼 스탑 없이 사세요.

서버가 침묵합니다.

comp: 그럼 뭘 샀어요?

서버가 침묵합니다.

comp: 뭐, 엿 먹어. 8분 동안 낮잠을 자자.

8분 후 컴: 어때요?

서버: 유로 벅스를 샀는데, 사는 동안 가격이 다른 곳으로 갔어요.

컴프: 젠장. 한 시간 더 낮잠을 자자.

그런 식으로요.

 
진화는 원을 그리며 진행됩니다. 이제 (비)유한 오토마타로 돌아가서 튜링 머신을 만들 때입니다.
 
Virty:

...

그리고 제 생각에는 오토마타 방법의 한 가지 큰 문제점이 있습니다. 실제 전문가 어드바이저의 경우 상태를 명확하게 정의하는 것은 불가능합니다. 전문가 어드바이저의 상태는 사용자 컴퓨터의 일부 내부 변수와 서버의 포지션 상태 (현재 비율, 자본, 주문 실행)에 의해 결정됩니다. 내부 상태는 명확하게 결정되지만 서버의 포지션 상태는 알 수 없거나 지연되어 알려지거나 불분명 한 상태 (일부 주문 및 요청이 실행되고 일부는 실행되지 않으며 그 이유를 알 수 없음)일 수 있습니다.

EA의 현재 상태를 알 수 없고 주문과 요청이 실행되지 않기 때문에 오토마타의 명확한 로직을 구축하는 것은 불가능합니다.

...

이것은 새로운 것입니다. 모든 (예외없이) TS는 TS 상태에 대한 분석과 명확한 이해를 기반으로 구축됩니다. 가장 간단한 상태: 주문 개시/종료/수정을 위한 신호 처리 등입니다.

"EA의 현재 상태가 명확하게 알려지지 않았다"면 이는 분명 EA가 아니며 프로그램도 아니며 EA와 관련된 "알고리즘"이라는 단어는 지우고 영원히 잊어 버려야합니다.

 

감정이 많네요.

좋아요, 저는 토론을 실용적인 방향으로 전환 할 것을 제안합니다. 유한 오토마타 이론에 기반한 구체적인 알고리즘을 분석해 봅시다. 그 강점과 약점에 대해 논의 해 봅시다. 나는이 방법으로 직접 글을 쓰지는 않지만 질문과 알고리즘에 대해 조금 익숙하므로 이제이 제어의 일반적인 원리를 스케치하겠습니다:

//СХЕМА + ПСВЕДОКОД
enum eTradeState {NoTradeRegim, BuyRegim, SellRegim, WaitRegim};
eTradeState TradeState = eTradeState.NoTradeRegim;
int Trade()
{
   switch (TradeState)
   {
       case eTradeState.NoTradeRegim:
          NoTradeRegim();
          break;
       case eTradeState.WaitRegim:
          WaitRegim();
          break;
       case eTradeState.SellRegim:
          SellRegim();
          break;
       case eTradeState.BuyRegim:
          BuyRegim();
          break;
   }
}
//여기서는 전문가 어드바이저가 트레이딩을 시작하는 조건에 대해 설명합니다. 예를 들면 다음과 같습니다.
void NoTradeRgim()
{
   //추가 의사코드는 다음과 같습니다. 
   if(CurrentDay == WorksDays && Market.Enable = true)
      TradeState = eTradeState.WaitRegim;
}
//여기서 롱 또는 숏 포지션에 진입하기 위한 신호를 포착합니다.
void WaitRegim()
{
   if(CheckForNoTrade() == true)
   {
      TradeState = eTradeState.NoTradeRegim;
   }
   if(CheckForBuy() == true)
   {
      BuyAtStop(...)
      TradeState = eTradeState.BuyRegim;
   }
   if(CheckForSell() == true)
   {
      SellAtStop(...);
      TradeState = eTradeState.SellRegim;
   }
}
//이 함수에서 우리는 긴 거래를 동반합니다.
void BuyRegim()
{
   //거래가 청산되거나 손절매 또는 기타 매개변수가 변경되는 조건 등을 여기에 입력합니다.
   if(StopLossChanged() == true)
      NewStop = ...;
   if(profit >= takeprofit)
   {
      CloseDeal(...);
      TradeState = eTradeState.WaitRegim;
   }

}
//이 함수에서는 숏 트레이딩을 동반합니다.
void SellRegim()
{
   //거래가 청산되거나 손절매가 이동되는 조건 등을 여기에 입력합니다.
   if(StopLossChanged() == true)
      NewStop = ...;
   if(profit >= takeprofit)
   {
      CloseDeal(...);
      TradeState = eTradeState.WaitRegim;
   }

}

개략적으로 설명하지만 기본 아이디어는 명확하다고 생각합니다. 전문가 고문은 매 순간마다 하나의 상태 (비 시장 모드, 신호 대기 모드, 구매 모드, 판매 모드) 만 있습니다. 각 상태에는 현재 상태에서 다른 상태로 전환되는 특정 동작과 조건이 있습니다. 아이디어는 우리가 각 상태를 명확하게 제어하므로 내부 논리가 엄격하게 현지화되어 존재하지 않거나 이미 마감 된 거래를 마감하는 것과 같은 논리적 오류가 발생할 수 없다는 것입니다.

저는이 기술로 직접 작성하지 않으며 모든 알고리즘에 적합하지 않다고 생각합니다. 그러나 여전히 고전적인 접근 방식보다 일부 작업을 더 잘 해결합니다.

전문가들은 이에 대해 어떻게 생각하나요?

 
C-4:
...

나는이 기술로 직접 글을 쓰지 않고 모든 알고리즘에 적합하지 않다고 생각합니다. 그러나 여전히 고전적인 접근 방식보다 몇 가지 문제를 더 잘 해결합니다.

전문가들은 그것에 대해 어떻게 생각합니까?

그리고 "고전적 접근 방식"이라는 문구가 무엇을 의미하는지 물어봐도 될까요?

모든 사람은 현실에 대한 자신의 반영을 가지고 있기 때문입니다.

 
Urain:

"고전적 접근"이 무슨 뜻인지 물어봐도 될까요?

사람마다 현실을 바라보는 시각이 다르기 때문이죠.

제가 잘못 말했나 봐요. 물론 모든 사람은 자신만의 방식으로 글을 씁니다. 저는 각 단계의 시스템 상태가 명확하게 정의되지 않은 대부분의 접근 방식을 의미했습니다. 전문가 고문을 실행하는 동안뿐만 아니라 결정해야합니다. 가장 간단한 예는 하나의 블록 OnTick()으로 작성된 코드입니다. 어떤 모드도 분석되지 않습니다. 솔루션의 선택은 if(...) 블록 분기를 기반으로 이루어집니다.
Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров
Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров
  • www.mql5.com
Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров - Документация по MQL5
 
C-4:
각 단계의 시스템 상태가 명확하게 정의되지 않은 경우 대부분의 접근 방식을 언급했습니다. EA 실행 시점에 결정해야 합니다.

상태가 "명확하게 정의되지 않은" 경우, "명확하게 정의되지 않은"을 어떻게 정의할 수 있나요? 주문/포지션 작업의 경우 EA가 매 틱마다 어떤 상태인지 파악할 필요가 없나요? 아니면 모든 틱의 EA가 "정의되지 않은 상태"인가요? 모든 틱에서 무엇을 해야 할지 모르는 EA는 어떤 종류입니까?

 

이 문서에서는 스위치가 있다는 점을 제외하고는 해당 주제를 전혀 다루지 않습니다. 존재 여부는 중요하지 않고 if로 전환할 수 있습니다.

제가 EA를 작성할 때 주문이 매우 복잡한 시스템이 있었습니다. 주문 없음, 대기 중, 시장가 주문 1개, 대기 중 주문 2개, 대기 중 주문 1개, 시장가 주문 1개 등의 상태 목록을 만들고 진지하게 분석해야 했습니다. 이런 식으로 만 극복 할 수있었습니다. 그러나 그것은 매우 보편적이고 빠르게 재 프로그래밍 할 수있는 것으로 밝혀졌습니다. 기사로 쓰기에는 꽤 흥미로운 주제입니다.

1234567
새 코멘트