훌륭한 글을 작성해 주신 작성자님께 감사드립니다!
라는 불완전한 아이디어가 있습니다.
따라서 이중 링크된 목록에 대한 노드의 기능은 단일 링크된 노드의 기능과 유사하지만 이전 노드에 대한 포인터를 처리해야 한다는 점이 다릅니다.
단일 링크된 노드의 기능을 갖기 위해 이전 노드에 대한 포인터를 처리해야 할까요? 저자가 전달하고자 하는 요지는 알겠는데, 표현 자체는 별로 좋지 않습니다.....
그림 3 링 이중 링크 목록의노드
1) 최상위 포인터 - 화살표가 약간 구부러져 있습니다.
2) 나는 이것이 기사의 스타일 일 수 있다는 것을 알고 있지만 그림에 대한 설명은 매우 작은 글꼴로되어 있고 다소 어둡습니다 (시력이 좋지 않다는 개인적인 의견).
또한 이중 링크 된 목록의 요구를 충족시킬 이러한 노드가 필요합니다. 이전 노드를참조하는 다른 포인터를 보유한다는 점에서 이전 형식과 다릅니다. 그리고 당연히 목록의 헤드 요소의 이러한 노드는NULL과 같을 것입니다.
1) 이전양식에서 - 무엇에서? 얼마나 이전? 이전으로 검색해야하는 이유는 작성자가 "단일 링크 된 목록의 노드"를 의미하거나 내가 틀렸을 수도 있습니다.
2) " 목록의 헤드 요소의 노드는 NULL과 같을 것입니다". 노드, 아니면 포인터?아마도 "요소가 아닌 노드를 목록에 저장할 수 있습니다."라는앞의 문장을 고려할때 다음과 같이 말하는 것이 더 정확할 것입니다:
" 이중으로 연결된 목록의 헤드 노드 포인터 중 하나는 NULL과 같습니다."라고 말하는 것이 더 정확할 것입니다 .
그러나 꼬리 노드에서는 다음 노드에 대한 링크가 헤드 포인터로 채워지기 때문에 비어 있지 않습니다.
1) 참조가 없을 것입니다- 누가-무엇 ???? 케이스가 유지되지 않습니다.
2) 그러나 꼬리 노드에는 다음 비어있는 (누가-무엇 ????) 에 대한 참조가 없습니다. 미완성 된 생각
3) 그것(참조)은 색인으로 채워질 것입니다. 링크가 포인터로 채워질까요, 아니면 포인터가 여전히 어딘가에 참조를 가질까요 ????.
삭제 작업은 추가 그룹에서 유사한 작업을 거의 복제합니다:
- 헤드 노드 삭제
- 꼬리 노드를 삭제합니다;
- 목록의 지정된 위치에서 노드를 제거합니다;
- 소멸자.
1)추가 그룹에서비슷한 (누가-무엇????) 것들을 거의 복제합니다 . 다시 불완전한 생각입니다.
2) 지정된 목록 위치에서 노드를 삭제하는 것은 "헤드 노드를 삭제"하고 "테일 노드를 삭제"하는 일반적인 경우가 아닌가??? 추가와 유사하게
3)" 삭제작업과관련하여", 그 전에는 "다음은 추가 방법으로 간주 될 수 있습니다."( 메소드, 여기 작업-나는 동일한 형식을 원합니다).
이것은 기사의 이러한 소개 부분이 작성된 무지한 사람의 소개 부분에 대한 개인적인 의견입니다.
마음에 들었어요. 고마워요. 읽은 후 각자의 자리에서 적용할 수 있는 아이디어를 얻을 수 있어서 좋았습니다. )
tol64, 권위 있는 전문가의 의견에 감사드립니다 :-)
저는 스스로를 전문가라고 생각하지 않으며 권위자라고 생각하지도 않습니다. 겸손해서가 아니라 정말 그렇습니다. ))) 여기에는 프로그래밍, 수학 및 거래 분야에서 몇 배 더 경험이 많은 프로그래머가 있습니다. 그리고 저는 여전히 수영하고 수영해야합니다. )))
권위는 주관적인 것이라고 생각합니다. 다른 나라에서 한 나라의 주권을 인정하는 것과 같습니다....
인용:
그래서, 당신의 것은 저에게 인정됩니다 :-)
tol64, 우리는 당신의 새로운 기사를 기다리고 있습니다.
- ru.wikipedia.org
다음은 데이터 세트의 요소에 액세스하는 예제에 대한 코드입니다:
log2(N)의 복잡도를 가진 CList 요소에 대한 바이너리 액세스를 어디서 찾았나요!
CList는 목록이며, log2(N) 복잡도를 가진 이진 액세스는 인덱스가 CurrentIndex +/- (CurrentIndex/2)인 노드로 순간적으로 점프해야 하며, 여기서 CurrentIndex는 목록의 현재 노드입니다.
CList 구현은 표준 QuickSearch()를 사용하는데, 정렬의 경우 실제로 CurrentIndex +/- (CurrentIndex/2) 노드를 참조하여 항목을 검색합니다. 그러나 이 노드 자체는 GetNodeAtIndex() 함수에 의해 검색되며, 그 안에는 기적이 없습니다. 액세스 작업의 모든 복잡성은 특히 이러한 문자열에 있습니다:
if(revers) { //--- 오른쪽에서 왼쪽으로 검색 for(;i>index;i--) { result=result.Prev(); if(result==NULL) return(NULL); } } else { //--- 왼쪽에서 오른쪽으로 검색 for(;i<index;i++) { result=result.Next(); if(result==NULL) return(NULL); } }
이를 살펴보면 목록이 양방향이므로 끝 중 하나에서 요소에 대한 액세스가 N/2 트랜지션을 초과하지 않기 때문에 요소 검색의 복잡성이 한계에서 O(N/2)임이 분명해집니다. 저자는 알고리즘에 대한 기사를 작성하기 전에 알고리즘을 더 철저히 이해하는 것이 좋습니다.
제 경험으로 볼 때 데이터 작업은 거의 항상 검색 및 정렬과 관련이 있기 때문에 실제 작업에 고전적인 CList를 사용하는 것은 거의 항상 비효율적이라고 말할 수 있습니다. 목록은 우선 인덱스별 액세스와 목록별 액세스가 결합된 컬렉션에서 강력합니다.
어떤 이유에서인지 포인터 전환이 인덱스로 직접 주소 지정하는 것보다 훨씬 느리다는 사실을 생각하는 사람은 거의 없습니다. result.Next()를 천 번 실행하는 것은 인덱스를 천 번 실행하는 것보다 훨씬 느립니다.
혼수상태.
이미지에서 바로 시작합니다. 포인터는 데이터가 아닌 노드로 이동하고, 데이터는 노드의 일부일 뿐이므로 구현과 충돌하고 잠재적인 혼란이 있습니다.
텍스트는 대부분 정상입니다.
구현 시에는요. 이러한 것들은 템플릿으로 구현됩니다. STL에서 컨테이너를 표현하는 최적의 변형은 반복자와 함수를 사용하는 것이지만 여기서는 실패입니다.
결과적으로 빈 가상 메서드는 이해할 수 없을 뿐만 아니라 브라이비글라즈만 보입니다. ) 시트 정렬이 전달되었습니다. 일부 메서드의 구현과 심지어 선언은 의심스럽고 심지어 당혹스럽기까지 합니다.
제로 캡슐화.
목록(! gg)에서의 복잡성과 이진(!) 검색에 대한 계시는 끝났습니다.
결과적으로 우리는 현재 모든 것을 이해할 수없고 불편한 쓰레기를 가지고 있으며 학습을위한 예제로도 사용할 수 없습니다 (임호).
) 프로그래머가되고 싶다면 정상적으로 프로그래밍하는 법을 배우십시오. 훨씬 더 잘 구현할 수 있습니다.
이를 살펴보면 목록이 양방향이므로 한쪽 끝에서 요소에 액세스하는 것이 N / 2 전환을 초과하지 않기 때문에 요소를 찾는 복잡성이 한계 O (N / 2) 에 있다는 것이 즉시 분명합니다. 작성자는 알고리즘에 대한 기사를 작성하기 전에 알고리즘을 더 철저하게 이해하는 것이 좋습니다.
또한 위에 쓰여진 O는 첫째로 잘못 계산된 것이고, 둘째로 잘못 적혀 있다는 것을 기억해두는 것이 좋을 것입니다.
_____________________________________
가장 흥미로운 점은 이것이 최악의 리소스 기사와는 거리가 멀다는 것입니다.
...
기분 나쁘게하지 마세요) 프로그래머가되고 싶다면 정상적으로 프로그래밍하는 법을 배우십시오. 당신은 그것을 훨씬 더 잘 깨달을 수 있습니다.
당신은 또한 당신의 기억을 새로 고치는 것이 좋을 것입니다. 위에 쓰여진 O는 첫째로 잘못 계산되고 둘째로 잘못 쓰여졌습니다.
...
새로운 기고글 MQL5 프로그래밍 기본: 목록 가 게재되었습니다:
거래 전략 개발을 위한 프로그래밍 언어의 새 버전인 MQL[MQL5]은 이전 버전[MQL4]에 비해 더 강력하고 효과적인 기능을 제공합니다. 이점은 본질적으로 객체 지향 프로그래밍 기능에 있습니다. 이 글에서는 노드 및 목록과 같은 복잡한 사용자 지정 데이터 유형을 사용할 가능성을 조사합니다. 또한 MQL5의 실제 프로그래밍에서 목록을 사용하는 예를 제공합니다.
이 글에서는 데이터 유형과 그 집합을 설명하는 주제의 확장 또는 연속이 어떤 식으로든 언급하고 싶습니다. 여기에서는 MQL5.community 웹사이트에 게시된 글을 참조하고자 합니다. Dmitry Fedoseev(Integer)는 그의 글 "MQL5 프로그래밍 기본: 배열"에서 배열 작업의 원리와 논리에 대한 매우 상세하고 포괄적인 설명을 제공했습니다.
그래서 오늘 저는 목록으로, 더 정확하게는 연결된 선형목록으로 전환할 것을 제안합니다. 목록 구조, 의미 및 논리부터 시작하겠습니다. 그런 다음 표준 라이브러리에서 이미 사용 가능한 관련 도구를 고려할 것입니다. 결론적으로 MQL5로 작업할 때 목록을 사용하는 방법에 대한 예를 제공합니다.
작성자: Denis Kirichenko