여기. 그러나 1000개의 세그먼트가 있으면 도움이 되지 않습니다. 너무 많은 옵션을 얻었습니다. 메모리가 충분하지 않을 수도 있습니다.
다른 방법으로 갈 수 있습니다. 각 세그먼트의 끝에 다음 세그먼트를 가리키는 인덱스가 있는 배열을 연결합니다. 따라서 메모리를 채우지 않고 모든 옵션을 통과할 수 있습니다. 그러나 똑같이 많은 옵션이 있습니다 ... 열거하는 데 오랜 시간이 걸립니다. 필요한 경우(스포츠 관심을 위해) 변형에 대한 액세스를 번호로 제공하는 방법에 대해서도 생각할 수 있습니다.
그러나 옵션이 너무 많으면 의미가 있습니까? 아마도 그것이 더 현실적이라는 작업을 구체화하기 위해?
여기. 그러나 1000개의 세그먼트가 있으면 도움이 되지 않습니다. 너무 많은 옵션을 얻었습니다. 메모리가 충분하지 않을 수도 있습니다.
다른 방법으로 갈 수 있습니다. 각 세그먼트의 끝에 다음 세그먼트를 가리키는 인덱스가 있는 배열을 연결합니다. 따라서 메모리를 채우지 않고 모든 옵션을 통과할 수 있습니다. 그러나 똑같이 많은 옵션이 있습니다 ... 열거하는 데 오랜 시간이 걸립니다. 필요한 경우(스포츠 관심을 위해) 변형에 대한 액세스를 번호로 제공하는 방법에 대해서도 생각할 수 있습니다.
그러나 옵션이 너무 많으면 의미가 있습니까? 아마도 그것이 더 현실적이라는 작업을 구체화하기 위해?
많은 대상이 있을 수 있습니다. 가장 작은 간격, 가장 긴 세그먼트, 가장 짧은 세그먼트, 가장 동일한 부분)
다른 방법으로 갈 수 있습니다. 각 세그먼트의 끝에 다음 세그먼트를 가리키는 인덱스가 있는 배열을 연결합니다. 따라서 메모리를 채우지 않고 모든 옵션을 통과할 수 있습니다. 그러나 똑같이 많은 옵션이 있습니다 ... 열거하는 데 오랜 시간이 걸립니다. 필요한 경우(스포츠 관심을 위해) 변형에 대한 액세스를 번호로 제공하는 방법에 대해서도 생각할 수 있습니다.
내가 올바르게 이해했다면 조합을 순차적으로 계산하고 즉시 평가하고 평가 결과를 저장하고 다음 조합으로 이동하는 것이 좋습니다. 새 결과(또는 top10)가 이전 결과보다 더 나은 경우 배열/변수에서 이를 대체합니다. 그리고 예, 조합으로 구성된 배열의 첫 번째 수준의 인덱스 체인을 얻는 방법을 묻고 싶었습니다.
드미트리 페도세예프 :
그러나 옵션이 너무 많으면 의미가 있습니까? 아마도 그것이 더 현실적이라는 작업을 구체화하기 위해?
현재 지점에서 제한된 수의 세그먼트를 반복하는 옵션(n개의 세그먼트가 이미 선택된 경우 결합 단계)이 적합하지 않은 이유는 무엇입니까?
그러나 업데이트의 본질을 잘 이해하지 못했습니다. 코드가 수정되었습니까? 지난 번에는 613개의 조합이 있었고 이번에는 1507개였습니다.
작업 속도는 줄어들었지만 이것은 분명히 조합의 수 때문입니다.
과거 옵션:
현재 옵션:
내가 올바르게 이해했다면 조합을 순차적으로 계산하고 즉시 평가하고 평가 결과를 저장하고 다음 조합으로 이동하는 것이 좋습니다. 새 결과(또는 top10)가 이전 결과보다 더 나은 경우 배열/변수에서 이를 대체합니다. 그리고 예, 조합으로 구성된 배열의 첫 번째 수준의 인덱스 체인을 얻는 방법을 묻고 싶었습니다.
현재 지점에서 제한된 수의 세그먼트를 반복하는 옵션(n개의 세그먼트가 이미 선택된 경우 결합 단계)이 적합하지 않은 이유는 무엇입니까?
그러나 업데이트의 본질을 잘 이해하지 못했습니다. 코드가 수정되었습니까? 지난 번에는 613개의 조합이 있었고 이번에는 1507개였습니다.
작업 속도는 줄어들었지만 이것은 분명히 조합의 수 때문입니다.
이전 버전:
현재 옵션:
내가 올바르게 이해했다면 조합을 순차적으로 계산하고 즉시 평가하고 평가 결과를 저장하고 다음 조합으로 이동하는 것이 좋습니다. 새 결과(또는 top10)가 이전 결과보다 더 나은 경우 배열/변수에서 이를 대체합니다. 그리고 예, 조합으로 구성된 배열의 첫 번째 수준의 인덱스 체인을 얻는 방법을 묻고 싶었습니다.
현재 지점에서 제한된 수의 세그먼트를 반복하는 옵션(n개의 세그먼트가 이미 선택된 경우 결합 단계)이 적합하지 않은 이유는 무엇입니까?
그리고 어디에서 무엇을 찾고 있는지 모르겠습니다. 일반적으로 시작할 때마다 새로운 초기 세그먼트 세트가 생성되며 항상 다릅니다.
인덱스 체인은 세그먼트가 아닌 세그먼트 인덱스에서 조합을 생성하거나 두 번째 차원에 세 번째 요소를 추가하고 인덱스를 저장해야 함을 의미합니다.
일부 제한된 수의 어떤 종류의 열거가 적합하지 않은 이유를 모르겠습니다. 모든 조합에 대해 썼습니다.
위에서 Alexey Tarabanov에 답할 때 어디서 무엇을 자세히 썼습니다. 그러나 이것은 이론입니다. 아직 필요한 것을 완료하지 못했습니다.
드미트리 페도세프 :
일반적으로 시작할 때마다 새로운 초기 세그먼트 세트가 생성되며 항상 다릅니다.
그렇다면 분명합니다. 저는 이해하지 못하고 두 개의 스크립트를 실행했습니다. 세트가 다른 경우 동일한 세트로만 평가할 수 있습니다.
드미트리 페도세프 :
인덱스 체인은 세그먼트가 아닌 세그먼트 인덱스에서 조합을 생성하거나 두 번째 차원에 세 번째 요소를 추가하고 인덱스를 저장해야 함을 의미합니다.
세 번째 요소가 더 편리한 옵션이라고 생각합니다. 이 구현에서 올바르게 작동하도록 코드를 조정할 수 있습니까?
드미트리 페도세프 :
일부 제한된 수의 어떤 종류의 열거가 적합하지 않은 이유를 모르겠습니다. 모든 조합에 대해 썼습니다.
맞습니다. 처음에는 모든 조합에 대해 썼지만 그 과정에서 당신 덕분에 이것이 매우 비싸고 경험적으로 완전한 열거보다 나쁘지 않을 수 있는 옵션이 필요하다는 것이 분명해졌습니다. 세그먼트가 조각으로 구성되면 최고의 조각을 n개의 조합으로 제한하여 새 조각을 추가할 때 제한 없이 가능한 모든 조합에서 최상의 옵션에 더 가까워질 수 있다고 가정합니다.
1. 이 계수는 어디에 있습니까?
2. 항목 1은 어떻습니까?
3. 아니요, 모든 것이 더 간단합니다. 알겠습니다. 내일은 속도를 내도록 하겠습니다.
1. 각 세그먼트의 계수(요약 표시기)는 특성에 따라 결정됩니다. 그런 다음 실험적으로 공식을 결정하지만 조건부로 존재한다고 가정할 수 있습니다.
2. 따라서 별도의 세그먼트에 있으므로 계산되는 3개 중 1개의 지표만 모든 사람에게 배포할 수 있고 다른 2개는 배포할 수 없습니다.
3. 고마워요, 기다릴게요.
여기. 그러나 1000개의 세그먼트가 있으면 도움이 되지 않습니다. 너무 많은 옵션을 얻었습니다. 메모리가 충분하지 않을 수도 있습니다.
다른 방법으로 갈 수 있습니다. 각 세그먼트의 끝에 다음 세그먼트를 가리키는 인덱스가 있는 배열을 연결합니다. 따라서 메모리를 채우지 않고 모든 옵션을 통과할 수 있습니다. 그러나 똑같이 많은 옵션이 있습니다 ... 열거하는 데 오랜 시간이 걸립니다. 필요한 경우(스포츠 관심을 위해) 변형에 대한 액세스를 번호로 제공하는 방법에 대해서도 생각할 수 있습니다.
그러나 옵션이 너무 많으면 의미가 있습니까? 아마도 그것이 더 현실적이라는 작업을 구체화하기 위해?
여기. 그러나 1000개의 세그먼트가 있으면 도움이 되지 않습니다. 너무 많은 옵션을 얻었습니다. 메모리가 충분하지 않을 수도 있습니다.
다른 방법으로 갈 수 있습니다. 각 세그먼트의 끝에 다음 세그먼트를 가리키는 인덱스가 있는 배열을 연결합니다. 따라서 메모리를 채우지 않고 모든 옵션을 통과할 수 있습니다. 그러나 똑같이 많은 옵션이 있습니다 ... 열거하는 데 오랜 시간이 걸립니다. 필요한 경우(스포츠 관심을 위해) 변형에 대한 액세스를 번호로 제공하는 방법에 대해서도 생각할 수 있습니다.
그러나 옵션이 너무 많으면 의미가 있습니까? 아마도 그것이 더 현실적이라는 작업을 구체화하기 위해?
많은 대상이 있을 수 있습니다. 가장 작은 간격, 가장 긴 세그먼트, 가장 짧은 세그먼트, 가장 동일한 부분)
이것은 무엇을 위한 것입니까?
인접 세그먼트에 대한 포인터가 있는 배열은 이미 만들어진 모든 조합을 포함하는 배열에 비해 메모리 양이 적습니다.
여기. 그러나 1000개의 세그먼트가 있으면 도움이 되지 않습니다. 너무 많은 옵션을 얻었습니다. 메모리가 충분하지 않을 수도 있습니다.
고맙습니다!
그러나 업데이트의 본질을 잘 이해하지 못했습니다. 코드가 수정되었습니까? 지난 번에는 613개의 조합이 있었고 이번에는 1507개였습니다.
작업 속도는 줄어들었지만 이것은 분명히 조합의 수 때문입니다.
이전 버전:
현재 옵션:
다른 방법으로 갈 수 있습니다. 각 세그먼트의 끝에 다음 세그먼트를 가리키는 인덱스가 있는 배열을 연결합니다. 따라서 메모리를 채우지 않고 모든 옵션을 통과할 수 있습니다. 그러나 똑같이 많은 옵션이 있습니다 ... 열거하는 데 오랜 시간이 걸립니다. 필요한 경우(스포츠 관심을 위해) 변형에 대한 액세스를 번호로 제공하는 방법에 대해서도 생각할 수 있습니다.
내가 올바르게 이해했다면 조합을 순차적으로 계산하고 즉시 평가하고 평가 결과를 저장하고 다음 조합으로 이동하는 것이 좋습니다. 새 결과(또는 top10)가 이전 결과보다 더 나은 경우 배열/변수에서 이를 대체합니다. 그리고 예, 조합으로 구성된 배열의 첫 번째 수준의 인덱스 체인을 얻는 방법을 묻고 싶었습니다.
그러나 옵션이 너무 많으면 의미가 있습니까? 아마도 그것이 더 현실적이라는 작업을 구체화하기 위해?
현재 지점에서 제한된 수의 세그먼트를 반복하는 옵션(n개의 세그먼트가 이미 선택된 경우 결합 단계)이 적합하지 않은 이유는 무엇입니까?
고맙습니다!
그러나 업데이트의 본질을 잘 이해하지 못했습니다. 코드가 수정되었습니까? 지난 번에는 613개의 조합이 있었고 이번에는 1507개였습니다.
작업 속도는 줄어들었지만 이것은 분명히 조합의 수 때문입니다.
과거 옵션:
현재 옵션:
내가 올바르게 이해했다면 조합을 순차적으로 계산하고 즉시 평가하고 평가 결과를 저장하고 다음 조합으로 이동하는 것이 좋습니다. 새 결과(또는 top10)가 이전 결과보다 더 나은 경우 배열/변수에서 이를 대체합니다. 그리고 예, 조합으로 구성된 배열의 첫 번째 수준의 인덱스 체인을 얻는 방법을 묻고 싶었습니다.
현재 지점에서 제한된 수의 세그먼트를 반복하는 옵션(n개의 세그먼트가 이미 선택된 경우 결합 단계)이 적합하지 않은 이유는 무엇입니까?
문제의 원래 버전을 고려하시겠습니까?
문제의 원래 버전을 고려하시겠습니까?
컷이 없습니다.
문제의 원래 버전을 고려하시겠습니까?
컷이 없습니다.
그런 옵션이 있었나요?
초기 옵션은 배열 형태의 디지털 시리즈를 세그먼트(범위)로 이상적으로 분할하는 것입니다. 위반 기준:
1. 숫자의 최소 5%가 -% R 범위에 속합니다.
2. 동일한 크기의 다른 이진 배열에 대한 세그먼트의 응답을 추정합니다(-0이 아닌 -1 범위에 속하는 숫자가 있음). 반면 세그먼트의 응답은 전체 이진의 평균 값과 달라야 합니다. 배열 최소 5% - dP%;
3. 어레이 깊이를 따라 10개의 동일한 세그먼트에 대해 SCO dP%를 계산합니다. 이는 1.5 - K_SKO를 넘지 않아야 합니다.
이제 다른 방법으로 범위를 결정하지만 다른 방법으로 위의 기준을 충족하는 다른 범위를 선택할 수 있습니다. 따라서 목표는 분할의 모든 변형을 서로 다른 방법의 세그먼트로 가져오고 최상의 방법을 결합하는 것입니다.
고맙습니다!
그러나 업데이트의 본질을 잘 이해하지 못했습니다. 코드가 수정되었습니까? 지난 번에는 613개의 조합이 있었고 이번에는 1507개였습니다.
작업 속도는 줄어들었지만 이것은 분명히 조합의 수 때문입니다.
이전 버전:
현재 옵션:
내가 올바르게 이해했다면 조합을 순차적으로 계산하고 즉시 평가하고 평가 결과를 저장하고 다음 조합으로 이동하는 것이 좋습니다. 새 결과(또는 top10)가 이전 결과보다 더 나은 경우 배열/변수에서 이를 대체합니다. 그리고 예, 조합으로 구성된 배열의 첫 번째 수준의 인덱스 체인을 얻는 방법을 묻고 싶었습니다.
현재 지점에서 제한된 수의 세그먼트를 반복하는 옵션(n개의 세그먼트가 이미 선택된 경우 결합 단계)이 적합하지 않은 이유는 무엇입니까?
그리고 어디에서 무엇을 찾고 있는지 모르겠습니다. 일반적으로 시작할 때마다 새로운 초기 세그먼트 세트가 생성되며 항상 다릅니다.
인덱스 체인은 세그먼트가 아닌 세그먼트 인덱스에서 조합을 생성하거나 두 번째 차원에 세 번째 요소를 추가하고 인덱스를 저장해야 함을 의미합니다.
일부 제한된 수의 어떤 종류의 열거가 적합하지 않은 이유를 모르겠습니다. 모든 조합에 대해 썼습니다.
그리고 어디에서 무엇을 찾고 있는지 모르겠습니다.
위에서 Alexey Tarabanov에 답할 때 어디서 무엇을 자세히 썼습니다. 그러나 이것은 이론입니다. 아직 필요한 것을 완료하지 못했습니다.
일반적으로 시작할 때마다 새로운 초기 세그먼트 세트가 생성되며 항상 다릅니다.
그렇다면 분명합니다. 저는 이해하지 못하고 두 개의 스크립트를 실행했습니다. 세트가 다른 경우 동일한 세트로만 평가할 수 있습니다.
인덱스 체인은 세그먼트가 아닌 세그먼트 인덱스에서 조합을 생성하거나 두 번째 차원에 세 번째 요소를 추가하고 인덱스를 저장해야 함을 의미합니다.
세 번째 요소가 더 편리한 옵션이라고 생각합니다. 이 구현에서 올바르게 작동하도록 코드를 조정할 수 있습니까?
일부 제한된 수의 어떤 종류의 열거가 적합하지 않은 이유를 모르겠습니다. 모든 조합에 대해 썼습니다.
맞습니다. 처음에는 모든 조합에 대해 썼지만 그 과정에서 당신 덕분에 이것이 매우 비싸고 경험적으로 완전한 열거보다 나쁘지 않을 수 있는 옵션이 필요하다는 것이 분명해졌습니다. 세그먼트가 조각으로 구성되면 최고의 조각을 n개의 조합으로 제한하여 새 조각을 추가할 때 제한 없이 가능한 모든 조합에서 최상의 옵션에 더 가까워질 수 있다고 가정합니다.