오버 플로우 감지 및 고정

StackOverflow https://stackoverflow.com/questions/924355

  •  06-09-2019
  •  | 
  •  

문제

16 비트 및 8 비트 버퍼를 사용하기 위해 입자 검출기가 하드 용기가 있습니다. 때때로, 입자 플럭스의 특정 피크가 통과된다. 괜찮아요. 무엇인가요 ~ 아니다 이 플럭스는 일반적으로 버퍼의 용량보다 크기에 도달한다는 것입니다. 따라서 오버플로가 발생합니다. 차트에서, 그들은 플럭스가 갑자기 떨어지고 다시 성장하기 시작하는 것처럼 보입니다. 오버플로로 고통받는 데이터 지점을 감지하는 [대부분] 정확한 방법을 제안 할 수 있습니까?

추신 : 검출기는 물리적으로 접근 할 수 없으므로 버퍼를 교체하여 '올바른 방법'을 고치는 것은 옵션이 아닌 것 같습니다.

업데이트: 요청 된 일부 설명. 우리는 데이터 처리 시설에서 Python을 사용합니다. 탐지기 자체에 사용 된 기술은 매우 모호합니다 (완전히 관련이없는 제 3자가 개발 한 것처럼 취급). 즉, '실제'OS를 실행하지는 않지만 검출기 판독 및 전원 사이클과 같은 원격 명령에 응답합니다. 메모리 부패 및 기타 문제는 지금 문제가되지 않습니다. 오버 플로우는 검출기의 설계자가 입자 플럭스를 계산하기 위해 16 비트 버퍼를 사용했으며 때로는 플럭스가 초당 65535 개의 입자를 초과하기 때문에 발생합니다.

Update 2: 몇몇 독자들이 지적했듯이, 의도 된 솔루션은 플럭스 프로파일을 분석하여 정상적인 변동과 분리하려는 시도에서 급격한 감소 (예 : 순서)를 감지하는 것과 관련이 있습니다. 또 다른 문제가 발생합니다. 복원 (원래 플럭스가 오버플레이션 레벨 아래로 떨어지는 지점)을 간단히 회복 된 수정 프로그램 ( 엑스 축) 플럭스 프로파일?

도움이 되었습니까?

해결책 

int32[] unwrap(int16[] x)
{
   // this is pseudocode
   int32[] y = new int32[x.length];
   y[0] = x[0];
   for (i = 1:x.length-1)
   {
      y[i] = y[i-1] + sign_extend(x[i]-x[i-1]);
      // works fine as long as the "real" value of x[i] and x[i-1]
      // differ by less than 1/2 of the span of allowable values
      // of x's storage type (=32768 in the case of int16)
      // Otherwise there is ambiguity.
   }
   return y;
}

int32 sign_extend(int16 x)
{
   return (int32)x; // works properly in Java and in most C compilers
}

// exercise for the reader to write similar code to unwrap 8-bit arrays
// to a 16-bit or 32-bit array

다른 팁

물론 이상적으로는 탐지기 소프트웨어를 65535에서 최대화하여 슬픔을 일으키는 종류의 랩 어라운드를 방지합니다. 나는 이것이 항상 가능하지 않거나 적어도 항상 빨리 할 수있는 것은 아니라는 것을 이해합니다.

입자 플럭스가 65535를 초과하면 빠르게 빠르게 작동합니까, 아니면 플럭스가 점차 증가한 다음 점차 감소합니까? 이것은 이것을 감지하는 데 사용할 수있는 알고리즘에 차이를 만듭니다. 예를 들어, 플럭스가 천천히 증가하면 :

true flux     measurement  
 5000           5000
10000          10000
30000          30000
50000          50000
70000           4465
90000          24465
60000          60000
30000          30000
10000          10000

그러면 당신은 a를 갖는 경향이 있습니다 크기가 큰 오버플로 된 경우에 부정적인 드롭. 다른 시간에 가질 수있는 것보다 훨씬 더 큰 부정적인 드롭. 이것은 당신이 오버플로 된 신호 역할을 할 수 있습니다. 오버 플로우 기간의 끝을 찾으려면 65535에서 그리 멀지 않은 값으로 큰 점프를 찾을 수 있습니다.

이 모든 것은 가능한 최대 실제 플럭스와 플럭스가 얼마나 빠르게 상승하고 떨어지는 지에 달려 있습니다. 예를 들어, 한 측정 기간에 128k 이상의 카운트를 얻을 수 있습니까? 하나의 측정이 5000이 될 수 있고 다음 측정은 50000이 될 수 있습니까? 데이터가 충분히 잘 작동하지 않으면 오버플로 된 시점에 대한 통계적 판단 만 할 수 있습니다.

귀하의 질문은 구현에 대한 자세한 정보를 제공해야합니다. 어떤 언어/프레임 워크를 사용하고 있습니까?

소프트웨어의 데이터 오버 플로우 (내가 말하는 것)는 나쁜 연습이며 피해야합니다. (이상한 데이터 출력)를 보는 동안 데이터 오버플로를 경험할 때 가능한 한 가지 부작용 일 뿐이지 만 볼 수있는 문제의 빙산의 일각 일뿐입니다.

메모리 부패와 같은 더 심각한 문제를 쉽게 경험할 수있어 프로그램이 크게 충돌하거나 악화 될 수 있습니다. 모호하게.

오버플로가 처음에 발생하지 않도록 할 수있는 검증이 있습니까?

나는 당신이 기본 버퍼를 고치지 않고 그것을 고칠 수 있다고 생각하지 않습니다. 값의 시퀀스 (0, 1, 2, 1, 0)와 (0, 1, 65538, 1, 0)의 차이를 어떻게 말해야합니까? 당신은 할 수 없습니다.

숨겨진 상태가 당신이 오버플로에 있고 배출이 입자 플럭스가 관찰되는지 여부에 관계없이 HMM을 사용하는 것은 어떻습니까?

까다로운 부분은 전환 (기본적으로 피크의 시간 규모를 인코딩하는)과 배출량 (플럭스가 어떻게 행동하는지, 오버 플로우가 측정에 미치는 영향을 알고 있다면 구축 할 수있는)에 대한 확률 모델을 제시 할 것입니다. 이것들은 도메인 별 질문이므로 기성품 솔루션이 없을 것입니다.

그러나 모델이있는 것, 다른 모든 것 --- 데이터에 맞는, 불확실성, 시뮬레이션 등 ---------

연속 값 사이의 실제 점프가 65536보다 훨씬 작은 경우에만이를 수행 할 수 있습니다. 그렇지 않으면, 오버 플로우 유발 계곡 유물은 실제 계곡과 구별 할 수 없으므로 추측 할 수 있습니다. 오른쪽과 왼쪽에서 신호를 동시에 분석하여 오버 플로우를 해당 복원과 일치시킬 수 있습니다 (인식 가능한베이스 라인이 있다고 가정).

그 외에는 다른 원래 입자 흐름으로 반복하여 실험을 조정하여 실제 계곡이 움직이지 않지만 아티팩트는 오버플로 지점으로 이동하도록 실험을 조정하는 것입니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top