실제 상황에서 가장 복잡한 데이터 구조는 무엇입니까? [닫은]

이 질문에 대한 세균은 업계의 동료 개발자 몇 명과의 토론에서 나왔습니다.

많은 장소에서 프로젝트 관리자는 복잡한 데이터 구조에주의를 기울이고 일반적으로 표준 라이브러리 / 패키지에 기본적으로 존재하는 모든 것을 고집합니다. 일반적인 아이디어는 성능이 심각하게 방해받지 않는 한 이미 사용 가능한 것을 조합하여 사용하는 것 같습니다. 이것은 코드베이스를 단순하게 유지하는 데 도움이됩니다. 이는 외교가 아닌 사람들에게 "우리는 높은 마멸을 가지고 있으며 우리가 고용 한 새로운 것은 그리 좋지 않을 수도 있습니다"라는 의미입니다.

따라서 CS 마약 중독자를위한 블룸 필터 또는 건너 뛰기 목록 또는 재생 트리가 없습니다. 여기에 다시 질문이 있습니다. 사무실에서 가장 복잡한 데이터 구조는 무엇입니까?

훌륭하고 정교한 실제 소프트웨어가 어떤지에 대한 이해를 돕습니다.

조회를 위해 건너 뛰기 목록을 사용했습니다. 내가 일하는 곳에는 표준 구현이 있으며 모든 사람들이 그것을 사용하는 것이 좋습니다. IP 주소를 효율적으로 저장하고 검색하기 위해 patricia 시도를 사용했습니다. 다시 구현이 이미 존재했습니다.

저는 Java 개발자입니다. Java Collection Framework 는 90 %의 데이터 구조 문제를 해결할 수 있지만 다른 10 %는 노력이 필요합니다. 전문가가 작성한 정교한 표준 라이브러리를 실제로 이해한다면 대부분의 경우 도움이 될 것입니다.

복잡한 데이터 구조는 실제 환경에서 유지하기가 어렵습니다. 코드가 엉망이되는 것을 피하기 위해 작은 문제로 나눕니다. 각각의 작은 문제는 Java Collection Framework 로 해결할 수 있습니다 . 솔루션이 가장 똑똑하지는 않지만 (더 많은 메모리가 필요하고 느려질 수 있지만) 작동하고 유지 관리하기 쉽습니다. 절충입니다.

복잡한 데이터 구조를 작성해야하는 경우 교과서를 선택합니다 :)

내가 작업에서 사용한 가장 복잡한 데이터 구조는 하나의 문제였습니다. 그러나 그것은 20 년 전이었습니다.

산업용 소프트웨어 개발의 문제점은 대부분의 산업용 프로그래머가 컴퓨터 과학 (CompSci) 졸업생이 아니라는 것입니다. 따라서, 평균 CompSci 대학원생이 당연한 것으로 생각하는 기술은 빵과 버터 프로그래머가 유지하기에는 너무 어려운 것으로 간주됩니다.

업계에서 일반적인 CompSci 지식이 부족한 것은 심각한 문제입니다. 예를 들어, 내가 만난 소프트웨어 개발자의 수를 잃어 버렸습니다.! (a! = 5 && b! = 3) 및 a == 5 || b == 3은 논리적으로 동일합니다. DeMorgan의 정리를 적용하는 방법을 아는 사람은 이러한 표현이 논리적으로 동일하다는 것을 인식 할 수 있습니다. 비 CompSci 졸업생 대부분은 DeMorgan의 정리에 대해 들어 본 적이 없습니다. 상당한 코드 기반을 조사하면 부정적인 논리 하위 표현을 부정하는 많은 표현이 발견됩니다. 부정 논리 하위 표현식이 포함 된 코드의 가독성은 이러한 표현식을 부정이 아닌 형식으로 변환하여 거의 항상 향상됩니다.

한 번은 이벤트 기반 시뮬레이션을 위해 일정 대기열 (O (1) 우선 순위 대기열)을 작성하여 프로파일 링에서 기존 힙이 병목 현상임을 보여주었습니다.

또한 약 80000 개의 상태를 가진 유한 상태 머신을 포함하는 제품을 출시했습니다.이를 생성하는 코드는 조금 어리 석었습니다.

오래 전부터 은하계에서 ... 어셈블러의 RTOS에서 Knuth의 "버디 버퍼"를 사용한 팀에서 일했습니다.

또한 1024 x 1024의 세계에서 256 세대를 지원하는 Conway의 인생 게임.

처음부터 너무 특별한 것을 사용하지 않으면 이중 연결 목록이 됩니다.

그리 흥미롭지는 않지만 다른 구조를 사용했습니다. 그러나 당신의 질문은 처음부터 말했다.

일반적인 재무 데이터 목록을 포함하는 해시 테이블 트리는 묻지 않습니다. 때때로 나는 카우보이 였으면 좋겠다. 별빛 아래의 단순한 삶

스도쿠 솔버를위한 댄싱 링크 알고리즘을 위해 처음부터 원형 이중 링크리스트 구조를 작성해야했습니다 . 루빅스 큐브 디자인처럼 느껴졌습니다. 전체 구조는 기본적으로 목록의 목록입니다. 각 노드는 4 개의 다른 노드를 가리 킵니다.

한 번 특수 캐시에 가중 경로 길이 트리 를 사용했습니다 . 재미있었습니다. 또한 malloc()교체를 위해 자체 힙 관리 루틴을 작성 했지만 많은 사람들이 그렇게했습니다.

내가 처음부터 해본 가장 "복잡한"데이터 구조는 이중 연결 목록을 기반으로 한 요소 네트워크를 모델링하는 것입니다. 그러나 그것은 몇 년 전 시스템 수준 프로그래밍을 할 때 사용되었습니다.

요즘 나는 멋진 데이터 구조를 거의 만들지 않습니다. 대부분의 경우 테이블에 넣는 것을 결정하는 데이터베이스에서 발생하며, 불필요한 조회를 피하기 위해 빠른 검색을 위해 관련 레코드의 ID 일 수도 있습니다.

나는 개인적으로 당면한 과제가 수단을 정의하는 것입니다. 사용하지 않는 이국적인 데이터 구조를 사용하려고 노력하는 이유는 무엇입니까? 그리고 대부분의 실제 응용 프로그래밍에서 말할 수 있다면 아마도 바퀴를 재발 명 할 필요가 없습니다.

우선 순위 대기열이 계산됩니까? 그것은 내가 작성한 거의 모든 실시간 응용 프로그램에서 나타납니다. 최근에야 표준 Java 라이브러리 (Java 1.5)의 일부가되었습니다.

그 외에는 도서관에서 꺼낼 수 없었던 복잡한 것을 생각할 수 없습니다. 나는 그것을 멈추게하지 않을 것이지만, 왜 라이브러리가 포함하기에 너무 이국적인 데이터 구조가 필요한지 의문을 품고있다. 필자는 직접 쓰려고 시도하기 전에 기존의 오픈 소스 구현 트리 또는 블룸 필터 또는 건너 뛰기 목록을 확실히 찾을 것입니다.

일반적으로 라이브러리 버전이 없기 때문에 사용자 정의 데이터 구조를 구축하고 유지 관리하는 데 비용이 너무 비현실적이므로 그로 인한 성능상의 이점보다 중요하다는 점에 관리자의 의견에 동의합니다. 프로파일 링을 통해 일반 라이브러리 구조가 멋진 성능으로 최적화하기 전에 상당한 성능 저하를 초래한다는 것을 보여 주길 원합니다. 일반적으로 엔지니어링주기보다 프로세서주기를 구입하는 것이 더 저렴합니다.