MQL4 및 MQL5에 대한 초보자 질문, 알고리즘 및 코드에 대한 도움말 및 토론 - 페이지 520

새 코멘트
 
Vitaly Muzichenko :

그런 디자인에 무슨 문제가 있습니까?

아니면 datetime 을 캐스팅하는 것이 더 낫습니까? 길게 입력하려면?

지금까지 나는 어떤 문제도 보지 않는다.
그러나 정확도를 향상시키는 경향은 분명합니다(datetime은 간단히 말해서 time_t보다 큼)
시간을 비교하려면 이 길이를 지정해야 합니다. 컴파일러가 무언가를 최적화하면 버리고 미래를 위한 보증금이 남습니다 :-)
 
Maxim Kuznetsov :
지금까지 나는 어떤 문제도 보지 않는다.
그러나 정확도를 향상시키는 경향은 분명합니다(datetime은 간단히 말해서 time_t보다 큼)
시간을 비교하려면 이 길이를 지정해야 합니다. 컴파일러가 무언가를 최적화하면 버리고 미래를 위한 보증금이 남습니다 :-)

결과 없이 변경 없이 사용할 수 있다는 의미입니까?

 
Vitaly Muzichenko :

결과 없이 변경 없이 사용할 수 있다는 의미입니까?

글쎄, 어떻게 결과없이 :-)

긴 x = TimeCurrent() ; 그들은 이미 괜찮은 회사에서 "대박"을 하고 있습니다 :-) 물리학의 유형이 다를 뿐만 아니라 크기도 다르며 더 큰 차원을 더 작은 차원으로 가져옵니다.

그렇지 않으면 예, (datetime)TimeCurrent의 모든 초가 긴 위치에 배치되는 것 같습니다.

 
Maxim Kuznetsov :

StringFind()라는 멋진 함수 가 있습니다 - "#" 문자열의 발생을 찾거나 즉시 "from #"

설립하다
 StringFind ( OrderComment (), "to #" , 0 )


그리고 어떻게 해야 할까요?

모든 것이 StringSubstr 에서 명확합니다. 우리는 즉시 숫자를 얻었습니다. 티켓이 있지만 여기 StringFind 에서는 주석에 "to #" 이 있다는 것을 이미 알고 있습니다.

 
PolarSeaman :
설립하다


그리고 어떻게 해야 할까요?

모든 것이 StringSubstr 에서 명확합니다. 우리는 즉시 숫자를 얻었습니다. 티켓이 있지만 여기 StringFind 에서는 주석에 "to #" 이 있다는 것을 이미 알고 있습니다.

그러나 우리는 어디에 있는지 모릅니다 :-) StringFind - 원하는 "to #"가 정확히 이 위치에서 왔다고 말할 것입니다. 또는 전혀. 네트워크에서 오는 것에 의존하지 마십시오. 개인적으로 / 개인적으로 통제하지 않습니다 :-) 우리는 여기에서 돈을 벌고 있습니다. 여기에서는 모든 것이 심각합니다.

 
Maxim Kuznetsov :

그러나 우리는 어디에 있는지 모릅니다 :-) StringFind - 원하는 "to #"가 정확히 이 위치에서 왔다고 말할 것입니다. 또는 전혀. 네트워크에서 오는 것에 의존하지 마십시오. 개인적으로 / 개인적으로 제어하지 않습니다 :-) 우리는 여기서 돈을 벌고 있습니다. 모든 것이 여기에서 심각합니다.

댓글에서 티켓을 선택하고 "to #"을 버려야 합니다.

오픈 포지션 의 티켓과 클로즈드 포지션의 댓글에 포함된 티켓을 비교해야 합니다.

왜 우리는 "to #"을 찾고 있습니까?

 

StringSubstr 함수는 주석의 원하는 부분을 반환합니다. 왜 이 함수는 닫힌 위치가 아닌 열린 위치의 이익을 반환합니까? MODE_HISTORY 로 소트

 double prof_cl_pos( string sy= "0" , int op=- 1 , int mn=- 1 ) {
   datetime ta;
   int       i, k= OrdersHistoryTotal ();
   double profit_= 0 ;
   string comment= "" ;
   string substr= "" ;

   if (sy== "" || sy== "0" ) sy= Symbol ();
   for (i= 0 ; i<k; i++) {
     if ( OrderSelect (i, SELECT_BY_POS , MODE_HISTORY )) {
       if ( OrderSymbol ()==sy) {
         if ( OrderType ()== OP_BUY || OrderType ()== OP_SELL ) {
           if (op< 0 || OrderType ()==op) {
             if (mn< 0 || OrderMagicNumber ()==mn) {
              comment= OrderComment ();
               substr = StringSubstr (comment, 4 , 9 );
               if (ticket_op_pos( Symbol (), - 1 ,mn)==substr)
              profit_= OrderProfit ();
            }
          }
        }
      }
    }
  }
   return (profit_);
}
 
Vitaly Muzichenko :

그런 디자인에 무슨 문제가 있습니까?

아니면 datetime 을 캐스팅하는 것이 더 낫습니까? 길게 입력하려면?

datetime은 ulong입니다. 여기에 추가해야 합니다.
 
PolarSeaman :

댓글에서 티켓을 선택하고 "to #"을 버려야 합니다.

오픈 포지션 의 티켓과 클로즈드 포지션의 댓글에 포함된 티켓을 비교해야 합니다.

왜 우리는 그것을 "to #"으로 찾고 있습니까?

댓글에 "to# or from#이 있나요"를 이해하기 위해 찾고 있습니다. 그렇지 않은 경우 이 주문은 마감된 위치의 일부가 아니며 필요하지 않습니다.

StringFind(OrderComment(),"#to")가 0보다 크거나 같으면 주석에 필요한 하위 문자열이 포함되며 이제 이 줄에서 티켓 번호의 위치를 계산할 수 있습니다.

 
PolarSeaman :

StringSubstr 함수는 주석의 원하는 부분을 반환합니다. 왜 이 함수는 닫힌 위치가 아닌 열린 위치의 이익을 반환합니까? MODE_HISTORY 로 소트

그리고 이것은 이 질문에 대한 답입니다.

거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼

MQL4에 대한 모든 초보자 질문, 알고리즘 및 코드에 대한 도움말 및 토론

2018.04.07 00:25

설립하다
 StringFind ( OrderComment (), "to #" , 0 )


그리고 어떻게 해야 할까요?

모든 것이 StringSubstr 에서 명확합니다. 우리는 즉시 숫자를 얻었습니다. 티켓이 있지만 여기 StringFind 에서는 주석에 "to #" 이 있다는 것을 이미 알고 있습니다.


그러나 그렇지 않으면 기대한 것을 전혀 얻지 못할 것입니다.

1...513514515516517518519520521522523524525526527...1953
새 코멘트