FAQ 작성에 대한 Subbotnik(자주 묻는 질문). 동료들을 도우자! - 페이지 14

새 코멘트
 
TheXpert :
그리고 가장 정확한 IMHO는 항상 단말기에 최신 정보를 요청하는 것입니다.

아무도 이 논문에 이의를 제기하지 않습니다. 주문 상태 (배열)는 작업이 필요할 때 정확히 요청됩니다.

어레이를 사전에 사용하지 않고 그것 없이는 할 수 있다고 주장하지 않습니다. 그리고 OrderSelect 후 수요가 있는 곳에서 즉시 주문 현황을 분석하고 매직, 기호 등으로 불필요한 것을 걸러냅니다.

그러나 당신은 티켓 배열이 UG라고 말합니다. 이유를 정당화하십시오.

--------------

Taras는 주문에 대한 모든 정보가 어레이에 기록될 때 "울트라" 옵션을 제안했습니다. 이 모든 정보가 필요하지 않다는 입장에서만 동의할 수 있습니다. 그리고 단순화된 버전에서는 대체로 티켓만 필요합니다.

 
TheXpert :
나는 제안하지 않을 것이다. 대부분의 경우 일련의 티켓이 전혀 필요하지 않습니다. 그리고 가장 정확한 IMHO는 항상 단말기에 최신 정보를 요청하는 것입니다.
배열에서 1틱 동안 조건부로 존재하는 정보를 얻습니다. 어떤 "신선한" 정보가 더 필요합니까? 2-4명의 다중 통화 거래자(데모에 대해 이야기하고 있음)가 동시에 내 계정에서 작업할 수 있는 내 연습에서 진행합니다. 다시 한 번 "아무것도 없이 서버를 방해"하는 것은 허용되지 않습니다.

일반적으로 이것은 귀하의 개인 및 제 관점입니다. 그리고 사용자는 항상 더 합리적인 주장을 할 수 있는 선택권을 주어야 합니다. ;)

추신 그리고 방금 FAQ에 제기된 질문에 대한 답변을 드렸습니다. :)

 

좋아, IMHO UG, 왜냐하면 IMHO 는 주문에 대한 최신 정보를 갖는 것이 좋기 때문입니다. 그리고 IMHO 는 95%의 경우에 일련의 주문 없이 할 수 있습니다.

자유롭게 추가하십시오. 나는 단지 내 의견을 표현한 것입니다.

 

다음과 같이 생각해보자.

- 모델의 편의성과 추상화의 관점에서 - 배열을 사용하는 것이 좋습니다.
- 작업 속도를 높이려면 - 배열 없이.

여기에 있는 정보 의 관련성 은 관련이 없습니다. 어레이 유무에 관계없이 두 옵션 모두 관련성이 100% 신선합니다.

 
sergeev :

--------------

Taras는 주문에 대한 모든 정보가 어레이에 기록될 때 "울트라" 옵션을 제안했습니다. 이 모든 정보가 필요하지 않다는 입장에서만 동의할 수 있습니다. 그리고 단순화된 버전에서는 대체로 티켓만 필요합니다.

알렉세이! 나는 이 질문을 FAQ("귀하의" 주문에 대한 일련의 티켓 받기)에 입력함으로써 "이 모든 정보가 필요하지 않다는 입장"을 의미했다고 생각하는 것과는 거리가 멉니다.
아니면 내가 뭔가를 잘못 이해 했습니까?
 
TarasBY :
알렉세이! 나는 이 질문을 FAQ("귀하의" 주문에 대한 일련의 티켓 받기)에 입력함으로써 "이 모든 정보가 필요하지 않다는 입장"을 의미했다고 생각하는 것과는 거리가 멉니다.
아니면 내가 뭔가를 잘못 이해 했습니까?

당신은 어떤 이유로 티켓과 그 모든 속성 외에 "당신의 티켓"이라는 개념을 추가했습니다.

그러나 나는 당신의 제안을 "그냥 티켓"의 확장 가능성으로 소개했습니다.

특히 주문 에 대한 과거 데이터를 분석하고 비교할 때 종종 필요합니다.

 
sergeev :


다음과 같이 생각해보자.

- 모델의 편의성과 추상화의 관점에서 - 배열을 사용하는 것이 좋습니다.
- 작업 속도를 높이려면 - 배열 없이.

여기에 있는 정보 의 관련성 은 관련이 없습니다. 어레이 유무에 관계없이 두 옵션 모두 관련성이 100% 신선합니다.

두 번째 것("배열 없이 작업 속도 향상")에 관해서는 범주형으로 서두르지 않을 것입니다.
간단한 논리는 "신선한 정보"를 위해 서버에 추가 호출이 추가 시간임을 나타냅니다. 그리고 어레이에서 동일한 정보를 선택하는 것과 제 시간에 경쟁할 수 없습니다.
코드 속도에 대한 전문가인 Victor(Vinin)가 있으므로 그의 의견이 흥미로울 것입니다!
 
TarasBY :
두 번째("배열 없이 작업 속도 향상")에 관해서는 범주형으로 서두르지 않을 것입니다.
간단한 논리는 "신선한 정보"에 대한 서버에 대한 추가 호출이 추가 시간임을 나타냅니다. 그리고 어레이에서 동일한 정보를 선택하는 것과 제 시간에 경쟁할 수 없습니다.
코드 속도에 대한 전문가인 Victor(Vinin)가 있으므로 그의 의견이 흥미로울 것입니다!

주문 속성 으로 작업할 때 서버에 대한 호출이 없음을 다시 한 번 상기시켜 드리겠습니다!

거래에서 가장 중요한 규칙은 관련성입니다(Xpert가 쓴 UG로 바뀌지 않도록).
따라서 각 함수의 주문 목록을 참조하여 배열을 다시 생성하면 확실히 느려집니다. 어레이가 가득 찼기 때문입니다.

즉, 일반적으로 어레이 및 re-OrdeSelect(이미 티켓에 있음)를 업데이트할 때만 저장할 수 있습니다.

1-2개의 작업 주문이 있는 경우 어레이가 중요하지 않지만 50-100인 경우 이미 중요합니다.

 
더 말하겠습니다. 앞서 "서버의 부하를 줄입니다"라는 개념을 기반으로 합니다(더 정확하게는 "코드 속도 최적화"라고 정의합니다). 시작 부분에서 또한 모든 가격을 별도의 배열로 가져옵니다(필요한 경우 여러 도구에 걸쳐). 그리고 거래 작업 을 수행해야 하는 경우 RefreshRates()를 수행합니다.

나는 이 접근 방식을 누구에게도 강요하지 않습니다. 나는 단지 그 안에 합리적인 입자를 보고 이 원칙을 개발에 사용합니다.

추신: 이것은 이 주제에 대한 논쟁을 시작하려는 것이 아니라 위의 주장일 뿐입니다.

 
sergeev :

따라서 각 함수의 주문 목록을 참조하고 배열을 다시 생성하면 확실히 느려집니다. 어레이가 가득 찼기 때문입니다.

내가 그렇게 주장했습니까? EA가 모든 틱 에서 작동하는 경우 티켓 배열은 틱당 한 번씩 채워집니다. 그런 다음 일반적인 선택 대신: 
     for ( int li_int = li_total - 1 ; li_int >= 0 ; li_int--)
    {
         if ( OrderSelect (li_int, SELECT_BY_POS))
        {
        .......
        }
    }
나는에서 샘플링하고있다
 for ( int li_TIC = 0 ; li_TIC < gi_cnt_Tickets; li_TIC++)
{

}

또는: 
     for ( int li_SMB = 0 ; li_SMB < ArraySize (gsa_Symbols); li_SMB++)
    {
    }
특정 기능에 대해 나에게 더 편리한 것에 따라.
이 접근 방식의 합리성은 소수에 속하는 다중 통화 시스템에서 더 두드러진다는 데 동의해야 합니다.
1...789101112131415161718192021...24
새 코멘트