알고리즘, 결정 방법, 성능 비교 - 페이지 15

새 코멘트
 
fxsaber :

커뮤니티에 대한 반복적인 무례함과 명백한 도발이 분명히 나타납니다.

이것을 읽지 않는 것이 항상 가능한 것은 아닙니다(다양한 건설적인 분야에 있는 사람의 게시물). 그 후에는 보지 않고 잊어버릴 수 있습니다.

도움의 손길에 트롤링 및 침 뱉기,이 자원을 긍정적 인면과 크게 구별하는 수.


아마도 내가 틀렸다.

감정을 조절해주세요. 다른 사람의 입장을 받아들이지 않으면 토론에 참여할 수 없습니다. 아무도 당신에게 강요하지 않습니다.

 
Vladimir Karputov :

정정합니다. 하지만 문자열 길이가 유한하지 않습니까?

https://msdn.microsoft.com/en-us/library/sx08afx2.aspx

MQL5에 대한 이 제한을 찾을 수 없습니다...

문자열은 자동 재분할을 위한 자체 기능이 있는 uchar 배열입니다. 따라서 문자열의 길이는 적어도 명시적으로 제한되지 않으며 배열의 크기도 제한되지 않습니다. 그러나 ERR_STRING_RESIZE_ERROR(문자열을 재할당할 메모리가 부족함)와 같은 특정 오류 코드로 표시되는 것처럼 매우 긴 문자열은 메모리가 부족할 수 있습니다.


 
Vasiliy Sokolov :

문자열은 자동 재분할을 위한 자체 기능이 있는 uchar 배열입니다. 따라서 문자열의 길이는 적어도 명시적으로 제한되지 않으며 배열의 크기도 제한되지 않습니다. 그러나 ERR_STRING_RESIZE_ERROR(문자열을 재할당할 메모리가 부족함)와 같은 특정 오류 코드로 표시되는 것처럼 매우 긴 문자열은 메모리가 부족할 수 있습니다.


저에게도 소중한 정보입니다. 고맙습니다.
 
fxsaber :

메모리에 의해서만 제한됨

길이 유형에 대한 제약 조건, 즉 INT_MAX 옆
 
Реter Konow :

1. 즉, 알고리즘의 속도는 중요하지 않습니다. 솔루션은 "개념적으로 강력"하고 그것으로 충분합니다. 확인.

2. 즉, 포함을 통해 연결되고 그게 다야? 좋은.

//------------------------------------------------ --------------------

알고리즘을 평가하는 주요 기준이 " 개념적 힘 "이라면 나는 졌다.

알고리즘을 평가하는 주요 기준이 단순성, 속도 및 편의성 이면 이깁니다.

이 주제는 닫을 수 있습니다.


문자열을 같은 크기의 두 int[]로 바꾸고 하나에는 거래 번호를 저장하고 다른 하나에는 매직 번호를 저장하고 거래 배열의 해당 열거로 원하는 매직 인덱스를 찾습니다. 더 빨라질 것입니다. 물론 이것은 귀하의 예를 따르는 특별한 경우입니다.

Petr는 배열을 알게 되었고 이것이 보편적이고 강력한 도구라는 것을 깨닫고 문자열을 배우기 시작했습니다... 그리고 그가 구조에 익숙해지면 어떤 일이 일어날지 상상할 수 있습니까? 그리고 그가 템플릿에 대해 알게 되었을 때 어떤 일이 일어날지 생각하는 것이 두렵습니다. :)

Peter는 자신의 예에서 다음 기능을 대체합니다.

 struct SDealMagic { int deal,magic;} array[];
//
void Trading()
{
   Random_orders_of_strategy= MathRand ();
   ArrayResize (array,Random_orders_of_strategy);
   for ( int i= 0 ; i<Random_orders_of_strategy; i++)
   {
      array[i].deal=i;
      array[i].magic= MathRand ()
   }
}
//
int Get_magic( int deal_number)
{
   for ( int i= 0 ; i<Random_orders_of_strategy; i++)
       if (array[i].deal==deal_number) return (array[i].magic);
   return (- 1 );
}

그리고 속도는 템플릿을 만들 것입니다 :)

 
Реter Konow :

1. 즉, 알고리즘의 속도는 중요하지 않습니다. 솔루션은 "개념적으로 강력"하고 그것으로 충분합니다. 확인.

2. 즉, 포함을 통해 연결되고 그게 다야? 좋은.

//------------------------------------------------ --------------------

알고리즘을 평가하는 주요 기준이 " 개념적 힘 "이라면 나는 졌다.

알고리즘을 평가하는 주요 기준이 단순성, 속도 및 편의성 이면 이깁니다.

이 주제는 닫을 수 있습니다.


가장 일반적인 예가 표시됩니다. 많은 추가 정보가 있습니다. 적어도 인쇄를 위한 디버그 및 정의 핸들러는 없습니다. 그렇지 않으면 300줄이 추가되었을 것입니다.

그러나 마치 전체 코드가 완전히 ....

라이브러리를 통해 추가하고 호출하는 데 필요한 코드 부분은 훨씬 더 편리하고 코드가 적고 가독성이 높습니다.

 
Alexandr Andreev :

마법이 있는 시세 표시기가 옵니다. 저장한 다음 시세 또는 마법에서 편리한 방법으로 당겨야 합니다. 글쎄, 조금 복잡하게 하자 - 즉. 모든 값, 매직 티커 TR SL 주석, 시가, 시간, 종가를 저장합니다. - 가상 주문을 고려하기 위한 것이라고 가정해 보겠습니다.

사실, 가장 빠른 솔루션은 모든 정보를 구조에 저장합니다. 그러나 링크 인덱스의 정렬된 요약을 통해 액세스를 만듭니다. 그리고 majik과 tekr에서. 저것들. 그 중 두 가지가 있을 것입니다. 기억으로는 물론 합리적이지 않습니다. 하지만 자주 주문을 받는다면 속도 면에서는 최고입니다.

이것은 정면 솔루션이므로 가장 빠르지 않습니다. HashMap을 통해 하는 것이 좋습니다. 그러나 현재 구현에서는 구조가 필요하지 않지만 해당 주문의 필드를 설명하기 위해 특정 인터페이스에서 상속된 클래스가 필요합니다.

 
Yury Kulikov :

문자열을 같은 크기의 두 int[]로 바꾸고 하나에는 거래 번호를 저장하고 다른 하나에는 매직 번호를 저장하고 거래 배열의 해당 열거로 원하는 매직 인덱스를 찾습니다. 더 빨라질 것입니다. 물론 이것은 귀하의 예를 따르는 특별한 경우입니다.


흥미롭고 합리적인 제안입니다. 병렬 기록을 유지합니다. 다른 솔루션에서 이 작업을 수행했습니다.

유일한 것은 처음에는 고문이 주문할 주문 수를 알지 못한다는 것입니다. int 배열의 크기는 얼마입니까?

그래서 라인을 잡기로 했습니다.

 
fxsaber :

이것은 정면 솔루션이므로 가장 빠르지 않습니다. HashMap을 통해 하는 것이 좋습니다. 그러나 현재 구현에서는 구조가 필요하지 않지만 해당 주문의 필드를 설명하기 위해 특정 인터페이스에서 상속된 클래스가 필요합니다.


Generic 파일을 찾지 못했는데도 예전 빌드 때문인 것 같습니다. 글쎄, 오리,하지만 탐색 원리는 어떻게 제공됩니까? 소스 코드는 무엇입니까?

 
Реter Konow :

흥미롭고 합리적인 제안입니다. 병렬 기록을 유지합니다. 다른 솔루션에서 이 작업을 수행했습니다.

유일한 것은 처음에는 고문이 주문할 주문 수를 알지 못한다는 것입니다. int 배열의 크기는 얼마입니까?

그래서 라인을 잡기로 했습니다.

Peter, ArrayResize()라는 훌륭한 함수가 있습니다. 프로그램 실행 시 배열의 크기를 늘릴 수 있습니다.

1...891011121314151617181920212223
새 코멘트