일반 클래스 라이브러리 - 버그, 설명, 질문, 사용 기능 및 제안 사항 - 페이지 8

새 코멘트
 

다음은 입력 필드 와 함께 코드입니다. (누군가가 도움이 될 것입니다. 개선할 수 있습니다.)

 //+------------------------------------------------------------------+
//|                                                   Dictionary.mq5 |
//|                                                      Peter Konow |
//|                                             https://www.mql5.com |
//+------------------------------------------------------------------+
#property copyright "Peter Konow"
#property link        ""
#property version    "1.00"
#property strict
//+------------------------------------------------------------------+
//| Expert initialization function                                   |
//+------------------------------------------------------------------+
#define Max_possible_collisions     100
#define Max_letters_in_word         100
#define All_letters_in_alphabet     255 
//------------------------------------
string Dictionary[Max_possible_collisions][All_letters_in_alphabet][Max_letters_in_word];
//-------------------------------------------------------------------
int OnInit ()
  {
//---
   Create_text_box();
//---
   return ( INIT_SUCCEEDED );
  }
//+------------------------------------------------------------------+
//| Expert deinitialization function                                 |
//+------------------------------------------------------------------+
void OnDeinit ( const int reason)
  {
   ObjectDelete ( 0 , "Text_box" );
  }
//+------------------------------------------------------------------+
//+------------------------------------------------------------------+
//| ChartEvent function                                              |
//+------------------------------------------------------------------+
void OnChartEvent ( const int id,
                   const long &lparam,
                   const double &dparam,
                   const string &sparam)
  {
     if (id == CHARTEVENT_OBJECT_ENDEDIT )
      { 
       //-----------------------
       string Text;     
       //---------------------
       ObjectGetString ( 0 , "Text_box" , OBJPROP_TEXT , 0 ,Text);
       //-------------------------------------
       Add(Text);
      } 
  }
//+------------------------------------------------------------------+

void Add( string word)
{
 uchar First_letter = ( uchar ) StringGetCharacter (word, 0 ) - 97 ;
 //-----------------------
 int All_letters_in_word = StringLen (word);
 //-----------------------
 for ( int a1 = 0 ; a1 < Max_possible_collisions; a1++)
   {
     string word_inside = Dictionary[a1][First_letter][All_letters_in_word];
     //-----------------------   
     if (word_inside == NULL )
      {
       Dictionary[a1][First_letter][All_letters_in_word] = word;
       Print ( "Your word has been added to our dictionary!" );
       break ;
      }
     if (word_inside == word)
      {
       Print ( "This word already exists in our dictionary" );
       break ;
      } 
   }   
 //------------------------   
}
//--------------------------------------------------------------------+


//--------------------------------------------------------------------
void Create_text_box()
{
   ObjectCreate ( 0 , "Text_box" , OBJ_EDIT , 0 , 0 , 0 );
   ObjectSetInteger ( 0 , "Text_box" , OBJPROP_XDISTANCE , 500 );
   ObjectSetInteger ( 0 , "Text_box" , OBJPROP_YDISTANCE , 250 );
   ObjectSetInteger ( 0 , "Text_box" , OBJPROP_XSIZE , 400 );
   ObjectSetInteger ( 0 , "Text_box" , OBJPROP_YSIZE , 30 );
   ObjectSetString ( 0 , "Text_box" , OBJPROP_TEXT , "Please enter your word here..." );
   ObjectSetString ( 0 , "Text_box" , OBJPROP_FONT , "TimesNewRoman" );
   ObjectSetInteger ( 0 , "Text_box" , OBJPROP_STATE , 1 );
   //----------------------------------------------
   ObjectSetInteger ( 0 , "Text_box" , OBJPROP_FONTSIZE , 12 );
   ObjectSetInteger ( 0 , "Text_box" , OBJPROP_BGCOLOR , clrWhite );
   ObjectSetInteger ( 0 , "Text_box" , OBJPROP_COLOR , clrBlack );
   ObjectSetInteger ( 0 , "Text_box" , OBJPROP_BORDER_COLOR , clrBlack );
   ObjectSetInteger ( 0 , "Text_box" , OBJPROP_ALIGN , ALIGN_CENTER );
   //----------------------------------------------
   ObjectSetInteger ( 0 , "Text_box" , OBJPROP_CORNER , CORNER_LEFT_UPPER );
   ObjectSetInteger ( 0 , "Text_box" , OBJPROP_ANCHOR , ANCHOR_LEFT_UPPER );  
   //---------------------------------------------- 
}
//-----------------------------------------------------------------------

어떤 이유로 만 4 개에서 완전히 작동합니다. 5에서는 필드가 나타나지 않습니다. 이유를 찾아봤는데 안나오네요.

 
fxsaber :

저것들. 각 작업에 대해 사전(RAM)의 크기와 해시 함수(CPU)의 계산 복잡성 사이의 중간 지점을 찾아야 합니다.


상대적으로 그렇습니다.
요소 값이 작은 경우 최적의 사전은 요소 수의 제곱이 됩니다(3년 전 과정에서 기억하는 한 항상 두 번 확인하는 것이 좋습니다).
많은 수의 요소로 인해 최적의 크기를 선택할 수 없는 경우 사전 크기는 예상 요소 수보다 몇 배 더 크게 취해지며 충돌 해결은 예를 들어 각 충돌에 대한 내부 해시 테이블을 통해 최적화됩니다. .

그들은 가능한 한 빨리 검색되는 방식으로 해시를 선택하려고 시도하지만 사전의 크기에 따라 얻은 결과의 균일한 분포를 보장합니다.
분포의 균일성은 해시에 소수를 사용하는 것과 관련이 있습니다.

 
피터 코노우 :
대문자의 코드가 다르고 배열에서 "드롭아웃"되기 때문에 배열의 크기를 늘려야 했습니다.

문자 "A"의 코드는 문자 "a"의 코드와 정확히 32만큼 다릅니다. 따라서 다른 모든 문자도 32의 차이가 있습니다.

배열의 크기 를 늘릴 필요가 없었을 수도 있지만 단순히 첫 번째 문자를 바꾸면 됩니다.
 
알렉세이 빅토로프 :

문자 "A"의 코드는 문자 "a"의 코드와 정확히 32만큼 다릅니다. 따라서 다른 모든 문자도 32의 차이가 있습니다.

배열의 크기를 늘릴 필요가 없을 수도 있지만 단순히 첫 번째 문자를 바꾸면 됩니다.

동의한다. 이 알고리즘은 잘 개발되지 않았습니다.

배열 크기가 너무 큽니다. 어제, 나는 글자의 코드를 잘 이해하지 못했습니다.

 
피터 코노우 :

다음은 입력 필드 와 함께 코드입니다. (누군가 도움이 될 것입니다. 당신은 그것을 개선할 수 있습니다).

어떤 이유로 만 4 개에서 완전히 작동합니다. 5에서는 필드가 나타나지 않습니다. 이유를 찾아봤는데 안나오네요.

그리고 한 가지 더 참고 사항: Vasily의 예에는 배열에 대한 언급이 있습니다.

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

일반 클래스 라이브러리 - 버그, 설명, 질문, 사용법 및 제안

바실리 소콜로프 , 2017.12.07 14:30

연관 배열 #1에 대해 가능한 한 간단합니다.

Generic에 제공된 많은 알고리즘은 연관 배열 또는 사전을 기반으로 합니다. 또한 가장 일반적으로 사용되는 두 가지 알고리즘 중 하나입니다. 프로그래밍의 모든 작업의 90%가 배열과 사전으로 이루어진다고 하면 진실에 가까울 것이라고 생각합니다. 연습을 진행하기 전에 사전 작업을 가능한 한 간단하고 알기 쉽게 설명하여 일부 세부 사항을 의도적으로 단순화합니다.

우리는 아주 간단한 예를 사용하여 사전을 분석할 것입니다: 일반적인 단어 사전. 이 단어 중 몇 개만 있고 모두 다른 알파벳 문자로 시작한다고 가정합니다.

 string words[] = { "apple" , "cat" , "fog" , "dog" , "walk" , "zero" };

영어 알파벳은 26자입니다. 차원이 26개 요소인 문자열 배열을 생성해 보겠습니다.

 string dictionary[ 26 ];

이제 첫 글자에 해당하는 인덱스에 단어를 저장하는 데 동의하면 가장 간단한 사전을 얻습니다. 처음부터 인덱싱을 수행합니다. "apple"이라는 단어는 인덱스 0에 저장됩니다. 문자 'a'가 알파벳의 첫 글자이기 때문입니다. "cat" - 인덱스 1, "dog" - 인덱스 3, fog - 인덱스 4, 걷기 - 인덱스 24이고 0은 마지막 25번째 인덱스입니다.

인덱스 5~23은 사용되지 않습니다. 이것은 추가 메모리 소비 이지만, 예를 들어 "walk"라는 단어를 즉시 참조할 수 있습니다. 존재하는 경우 인덱스 24에 있다는 것을 알기 때문입니다.

첫 번째 빈 사전을 작성해 보겠습니다.



그리고 당신의 예에서

 #define Max_possible_collisions     100
#define Max_letters_in_word         100
#define All_letters_in_alphabet     255 
//------------------------------------
string Dictionary[Max_possible_collisions][All_letters_in_alphabet][Max_letters_in_word];

3D 어레이는 얼마나 많은 메모리를 사용합니까? 사이즈를 늘려야 한다면?

 
알렉세이 빅토로프 :

그리고 한 가지 더 참고 사항: Vasily의 예에는 배열에 대한 언급이 있습니다.


그리고 당신의 예에서

3D 어레이는 얼마나 많은 메모리를 사용합니까? 사이즈를 늘려야 한다면?

다음과 같은 이유로 어레이 크기가 너무 큽니다.

1. 나는 한 단어의 최대 글자 수를 100자로 정했다. 명백히 과잉이다. 30으로 줄일 수 있습니다.

2. 가능한 글자수도 과도하게 많다. 나는 가능한 한 많은 다른 캐릭터를 대신하기로 결정했습니다. 줄일 수 있습니다.

3. "collisions"의 수, 즉 첫 글자와 단어의 글자 수에 의한 단어의 일치가 100으로 설정됩니다. 너무 많습니다. 50으로 줄일 수 있습니다.


크기를 늘리는 데 의미가 없습니다. 다른 사전을 만들면 됩니다.

 
피터 코노우 :

다음과 같은 이유로 어레이 크기가 너무 큽니다.

1. 나는 한 단어의 최대 글자 수를 100자로 정했다. 명백히 과잉이다. 30으로 줄일 수 있습니다.

2. 가능한 글자수도 과도하게 많다. 나는 가능한 한 많은 다른 캐릭터를 대신하기로 결정했습니다. 줄일 수 있습니다.

3. "collisions"의 수, 즉 단어의 첫 글자와 글자 수로 일치하는 단어가 100으로 설정되어 있습니다. 너무 많습니다. 50으로 줄일 수 있습니다.


크기를 늘리는 데 의미가 없습니다. 다른 사전을 만들면 됩니다.

질문은 사전에 없습니다. 사전은 알고리즘을 구축하는 예일 뿐입니다. 그리고 귀하의 예에서와 같이 100개 요소에서 멀리 있을 수 있지만 1e10 이상 ... 이 경우 배열의 크기는 얼마가 될까요???

예를 들어 사용 가능한 전체 틱 기록을 배열로 수집합니다. 1밀리초에는 2개 이상의 틱이 있을 수 있으므로 배열은 1차원이 될 수 없습니다... 그리고 밀리초당 틱은 최대 몇 개인가요??? 2개 5개??? 이 경우 배열의 차원은 무엇이어야 합니까??? 얼마나 많은 메모리가 낭비됩니까?

 
알렉세이 빅토로프 :

예를 들어 사용 가능한 전체 틱 기록을 배열로 수집합니다.

이 모든 것이 작성된 후에는 스레드에서 논의된 방식으로 틱을 저장하는 실용적인 작업이 없다고 생각했습니다. 그것들은 시간순으로 정렬되고 단순한 배열에 놓여 있습니다.

내역 주문/거래와 유사합니다. 저장, HistorySelect 로 판단하면 시간별로 배열에도 저장됩니다. 그리고 (현재 구현에서는) 티켓이나 ID로 레코드를 검색하는 것에 대해 논의한 것이 없다고 생각합니다.

그리고 모든 것은 명명 된 역사의 경우 무언가를 담는 것이 부적절하기 때문입니다. 연습을 위한 간단한 배열이면 충분합니다.

따라서 거래 분야에서 실제 작업을 공식화하는 것은 흥미 롭습니다.


ZY 주문에서 HistorySelect의 가속이 언제 그랬는지, 해시가 있는 사전이 아니라 캐싱을 통해 문제를 해결했다고 확신합니다.

 
fxsaber :

이 모든 것이 작성된 후에는 스레드에서 논의된 방식으로 틱을 저장하는 실용적인 작업이 없다고 생각했습니다. 그것들은 시간순으로 정렬되고 단순한 배열에 놓여 있습니다.

내역 주문/거래와 유사합니다. 저장, HistorySelect로 판단하면 시간별로 배열에도 저장됩니다. 그리고 (현재 구현에서는) 티켓이나 ID로 레코드를 검색하는 것에 대해 논의한 것이 없다고 생각합니다.

그리고 모든 것은 명명 된 역사의 경우 무언가를 담는 것이 부적절하기 때문입니다. 연습을 위한 간단한 배열이면 충분합니다.

따라서 거래 분야에서 실제 작업의 공식화는 흥미 롭습니다 .


ZY 주문에서 HistorySelect의 가속이 언제 그랬는지, 해시가 있는 사전이 아니라 캐싱을 통해 문제를 해결했다고 확신합니다.

나는 논쟁하지 않지만 누군가가 이런 식으로 어떤 작업을 구현하려는 경우 깃발이 그의 손에 있습니다 ...

누군가는 그것이 말이되지 않는다고 생각하고 누군가는 그것을 마스터 할 수 없다고 생각합니다 ... 두 경우 모두 더 간단한 구현이 있습니다. 그러나 "내일" 거래가 어떻게 발전할지 누가 알겠습니까... 아마도, 부재 시 필요한 것보다 청구하지 않고 그대로 두는 것이 더 나을 것입니다.

 
알렉세이 빅토로프 :

질문은 사전에 없습니다. 사전은 알고리즘을 구축하는 예일 뿐입니다. 그리고 귀하의 예에서와 같이 100개 요소에서 멀리 있을 수 있지만 1e10 이상 ... 이 경우 배열의 크기는 얼마가 될까요???

예를 들어 사용 가능한 전체 틱 기록을 배열로 수집합니다. 1밀리초에는 2개 이상의 틱이 있을 수 있으므로 배열은 1차원이 될 수 없습니다... 그리고 밀리초당 틱은 최대 몇 개인가요??? 두 개, 다섯 개??? 이 경우 배열의 차원은 무엇이어야 합니까??? 얼마나 많은 메모리가 낭비됩니까?

편리한 사전 구축 문제를 해결했습니다.

눈금 또는 기타 요소에는 저장 위치에 빠르게 액세스할 수 있도록 성공적으로 인덱싱할 수 있는 고유한 특정 속성이 있습니다.

데이터에 대한 빠른 액세스 작업의 본질은 요소의 여러 분류 속성을 식별하고 색인을 생성하는 것입니다.

요소를 취하고, 색인을 얻을 수 있는 편리한 속성을 찾고, 색인을 통해 저장 위치에 대한 액세스를 얻습니다.

인덱스가 충분하지 않은 경우(예: 단어의 첫 글자와 글자 수를 인덱싱할 수 있지만 나머지 속성은 편리한 인덱스를 제공하지 않는 경우) 주변 영역 내의 요소를 직접 열거합니다.

원칙은 보편적이며 구현은 다를 수 있습니다.

123456789101112131415...38
새 코멘트