적용하기 전에 검토하세요
실제 동작을 예상 결과와 비교하세요. 검사가 실패하면 다음 변경을 하기 전에 원인을 조사하세요.
● ● ●ParityOchre●
작업 흐름 · 해밍 1비트 오류 정정 ×
def correct_hamming(word):
word = list(word)
if len(word) != 7 or any(type(b) is not int or b not in (0, 1) for b in word):
raise ValueError("hamming.word")
syndrome = 0
for parity in (1, 2, 4):
value = 0
for position in range(1, 8):
if position & parity:
value ^= word[position-1]
if value:
syndrome |= parity
if syndrome:
word[syndrome-1] ^= 1
data = (word[2] << 3) | (word[4] << 2) | (word[5] << 1) | word[6]
return data, syndrome✳뒤집힌 비트가 최대 하나라는 명시적 가정으로 7비트 해밍 코드워드를 해독합니다.
✓ 변경 사항적용하기 전에 검토하세요 ↗
작업 공간 예시 화면
모델
기본 URL과 필요한 API 키로 OpenAI 호환 또는 Anthropic 엔드포인트를 설정하고 연결을 테스트하세요. 로컬 모델 서버는 실행 중이어야 합니다. 원격 도구는 데이터를 별도로 전송할 수 있습니다.
프로젝트
정상 코드워드와 모든 단일 비트 위치를 시험하고 잘못된 형태나 이진이 아닌 입력을 거부하며 다중 오류 검출을 보장하지 않습니다.
작업 흐름
def correct_hamming(word):
word = list(word)
if len(word) != 7 or any(type(b) is not int or b not in (0, 1) for b in word):
raise ValueError("hamming.word")
syndrome = 0
for parity in (1, 2, 4):
value = 0
for position in range(1, 8):
if position & parity:
value ^= word[position-1]
if value:
syndrome |= parity
if syndrome:
word[syndrome-1] ^= 1
data = (word[2] << 3) | (word[4] << 2) | (word[5] << 1) | word[6]
return data, syndrome실험 코드의 동작 가정을 명확히 유지하세요
ParityOchre는 작은 기술 실험을 범위가 명확한 소프트웨어 구성 요소로 발전시키는 Windows용 AI 코딩 작업 공간입니다. 소스 폴더를 열고 결과가 사용될 조건을 설명하세요. 특히 출력이 복구 성공의 증거로 해석될 수 있는 부분에서 계산과 호출 코드를 모두 검토하도록 모델에 요청하세요.
예를 들어 단일 비트 오류를 가정하여 hamming.py 검토를 요청하세요. 손상되지 않은 워드와 비트 하나를 바꾼 워드를 제공하고 반환된 데이터와 신드롬을 애플리케이션에 어떻게 표시할지 명시하세요. 그럴듯한 결과가 모든 손상 입력이 수정되었다는 뜻이 되지 않도록 이 가정 밖의 실패를 별도로 논의하세요.
수정 제안을 바탕으로 실험 주변의 인터페이스를 살펴보세요. 입력 길이와 비트 값을 확인하고 자신의 환경에서 독립적인 테스트 데이터를 실행하며 사용 코드가 표시하는 메시지를 검토하세요. 여기서는 명확한 출력 이름이 중요합니다. 제한된 예시를 더 광범위한 신뢰성 주장으로 바꾸지 않고 루틴이 실제로 보고하는 내용을 전달해야 합니다.
ParityOchre는 OpenAI 호환 또는 Anthropic 엔드포인트를 통한 모델 연결을 지원하며 필요하면 자격 증명을 사용합니다. 무검열 AI 모델은 제공되는 경우 선택할 수 있으며 제공업체의 제한을 따릅니다. 사용 가능한 도구와 컨텍스트는 선택한 모델 및 서버에 따라 달라집니다. 제안된 소프트웨어 동작을 검토할 때는 여전히 테스트 데이터에서 나온 증거가 필요합니다.
범위가 제한된 복구 실험에 관한 질문
값이 반환되면 워드가 복구되었다는 증거인가요?
루틴과 입력에 대해 정한 가정 안에서만 그렇습니다. 그럴듯한 데이터 값만으로 임의의 손상을 성공적으로 수정했다고 입증할 수는 없습니다. 실험이 뒷받침하는 수준을 넘는 확신을 사용자에게 주지 않도록 애플리케이션의 결과 설명을 검토하세요.
입력 검증에는 무엇이 포함되어야 하나요?
프로젝트 계약의 예상 워드 길이와 허용 비트 값을 사용하세요. 잘못된 길이와 비트가 아닌 항목을 테스트 데이터에 포함하세요. 헬퍼의 예외가 반드시 유용한 애플리케이션 응답인 것은 아니므로 호출 코드를 통한 거부 처리도 검토하세요.
테스트에 손상되지 않은 워드를 포함하는 이유는 무엇인가요?
변경 없는 경로와 수정이 표시되지 않을 때 보고되는 신드롬의 의미를 확인합니다. 추출된 데이터를 독립적인 예상값과 비교하세요. 손상된 예시만 테스트하면 정상 입력 처리나 출력 해석의 결함을 놓칠 수 있습니다.
더 광범위한 오류 처리는 어떻게 요청하나요?
추가 오류 사례와 이를 구분하기 위해 애플리케이션에 필요한 증거를 명시하세요. 기존 예시에 대한 작은 패치가 아니라 새로운 설계 요구 사항으로 다루세요. 더 강한 복구 보장을 지원한다고 가정하기 전에 제안된 인터페이스와 테스트를 검토하세요.
ParityOchre · 업데이트 2026-10-25