Sergey Dzyublik : 본질적으로 충돌을 해결하기 위해 초기 데이터 배열과 함께 정적 HashSet 데이터 구조를 사용하고 있습니다. 그러나 구현 - 그냥 눈을 떼십시오 ...
100-500개의 불필요한 매개변수를 사용하여 함수("FindValueInSortArray")를 호출하는 대신 일반적으로 이러한 매개변수가 클래스 필드로 작동하는 클래스를 사용합니다(컴파일러가 암시적 인라인을 고려하지 않은 경우 매개변수 전달 에서 승리). 같은 크기와 같은 사용 목적( int p1[]; int p2[];)을 가진 한 쌍의 배열을 사용해야 하는 경우 일반적으로 구조 배열이 사용됩니다(인덱스에 의한 액세스에서 승리, 축소 캐시 미스 가능성).
네 알겠습니다. 나는 동의한다. 나는 내 자신의 구현에서 멍청하다. 그러나 내 목표는 구현이 아니라 알고리즘입니다. 그들이 말했듯이 알고리즘의 정확성과 속도를 확인하기 위해 "내 무릎에 수집"(약 1시간 30분). 이 스레드는 "불필요한 값의 배열을 지우는 가장 빠른 방법"이라는 질문(나는 인용)에 대해 논의하고 있음을 상기시켜 드리겠습니다.
나만의 알고리즘에 대한 불만이 많지만, 보편적인 것과는 거리가 멀다. 알고리즘을 개선할 방법이 보이지만 코드가 훨씬 더 복잡해질 것입니다. 유감스러운 시간입니다.
ZY HashSet에 대해 처음 듣습니다. tk. 이론상 강하지 않다. 나는 새로운 것을 발명하지 않았지만 모든 것이 나보다 먼저 발명되었다는 것을 완벽하게 이해합니다. :)) 제거할 요소의 배열이 균일한 분포를 갖는다면 이 알고리즘의 장점은 분명합니다. 분포가 균일과 매우 다른 경우 이 구현은 이 분기에 이미 존재하는 다른 구현보다 속도가 떨어질 수 있습니다.
본질적으로 충돌을 해결하기 위해 초기 데이터 배열과 함께 정적 HashSet 데이터 구조를 사용하고 있습니다.
그러나 구현 - 그냥 눈을 떼십시오 ...
100-500개의 불필요한 매개변수를 사용하여 함수("FindValueInSortArray")를 호출하는 대신 일반적으로 이러한 매개변수가 클래스 필드로 작동하는 클래스를 사용합니다(컴파일러가 암시적 인라인을 고려하지 않은 경우 매개변수 전달 에서 승리).
같은 크기와 같은 사용 목적( int p1[]; int p2[];)을 가진 한 쌍의 배열을 사용해야 하는 경우 일반적으로 구조 배열이 사용됩니다(인덱스에 의한 액세스에서 승리, 축소 캐시 미스 가능성).
네 알겠습니다. 나는 동의한다. 나는 내 자신의 구현에서 멍청하다. 그러나 내 목표는 구현이 아니라 알고리즘입니다. 그들이 말했듯이 알고리즘의 정확성과 속도를 확인하기 위해 "내 무릎에 수집"(약 1시간 30분). 이 스레드는 "불필요한 값의 배열을 지우는 가장 빠른 방법"이라는 질문(나는 인용)에 대해 논의하고 있음을 상기시켜 드리겠습니다.
나만의 알고리즘에 대한 불만이 많지만, 보편적인 것과는 거리가 멀다. 알고리즘을 개선할 방법이 보이지만 코드가 훨씬 더 복잡해질 것입니다. 유감스러운 시간입니다.
ZY HashSet에 대해 처음 듣습니다. tk. 이론상 강하지 않다. 나는 새로운 것을 발명하지 않았지만 모든 것이 나보다 먼저 발명되었다는 것을 완벽하게 이해합니다. :)) 제거할 요소의 배열이 균일한 분포를 갖는다면 이 알고리즘의 장점은 분명합니다. 분포가 균일과 매우 다른 경우 이 구현은 이 분기에 이미 존재하는 다른 구현보다 속도가 떨어질 수 있습니다.
합계 계산을 CRC32로 대체)
고맙습니다. 당연히 그게 더 좋습니다.
그러나 내가 이해한 한 CRC32로의 전환은 오류를 나타내지 않았습니다. :)
개인적으로 현대 컴퓨터의 기능과 특히 MQL5의 기능에 깊은 인상을 받았다는 점을 말씀 드리겠습니다.
결국 100만 요소의 배열에서 약 1,000개의 서로 다른 값을 검색하고 삭제(약 100,000개 셀)하고 정리된 배열(!! !)
독창적인 것은 모두 간단합니다! :))
그러나 그러한 알고리즘은 제어할 수 없을 정도로 메모리를 소모하는 것이 사실입니다.
예를 들어 다음을 대체하는 경우:
에
상황은 매우 다릅니다.
고맙습니다. 당연히 그게 더 낫습니다.
그러나 내가 이해한 한 CRC32로의 전환은 오류를 나타내지 않았습니다. :)
네, 하지만 이제 한 알고리즘의 결과를 눈으로 직접 본 사람들은 다른 알고리즘도 동일한 결과를 얻을 수 있음을 확신할 수 있습니다)
나쁜 생각은 아니지만 배열이나 벡터에 음수 값이 있으면 배열이 범위를 벗어남 오류가 발생합니다.
또한 필터링 플래그 가 있는 배열 의 크기 는 2 147 483 647에 도달할 수 있으며 이는 너무 많습니다.
물론 32개의 BOOL 변수 설정을 다음과 같은 비트 마스크로 교체하여 32배로 줄일 수 있습니다.
그러나 여전히 크기가 너무 커서 속도가 약 절반으로 떨어집니다.
독창적인 것은 모두 간단합니다! :))
그러나 그러한 알고리즘은 제어할 수 없을 정도로 메모리를 소모하는 것이 사실입니다.
예를 들어 다음을 대체하는 경우:
에
상황은 매우 다릅니다.
당신의 버전도 좋지만 불행히도 약점도 있습니다. "집" 조건, 즉 ~100 크기의 작은 배열과 ~5-10의 작은 벡터
귀하의 알고리즘은 여기에 제시된 모든 알고리즘보다 느릴 것입니다. 비록 마이크로초의 차이가 너무 미미하여 중요하지 않을 수 있지만 큰 어레이 크기 에서는 더 좋습니다.
추신: 기능이 보편화되기 위해서는 입력 데이터에 따라 선택된 여러 알고리즘을 결합해야 한다고 생각합니다.