Repository navigation
Source Condition Cases
확인: 2026-10-10 KST. 새 문법과 컴파일러 연결은
PR1439의 원래 CI와 네 플랫폼 준비 검사를
통과해 dev의 92dc06b3에 병합했습니다. 공개 SDK v0.2.28-experimental을 사용합니다.
병합된 소스를 로컬 gooo-typed-dev에 설치했습니다. 공개 배포본0.6.24에는
아직 이 새 문법이 포함되지 않습니다. 병합 후 dev의 CI와 네 플랫폼 준비 검사도 통과했습니다. 공개 배포 준비는 PR1440에서 진행합니다.
병합·설치·새 실제 실행 기록.
컴파일러의 원래 CI에서 일반 테스트·race·의미 검사는 통과했습니다.
형식 검사는 Go 구문 두 곳과 오래된 의존성 기록의 정리를 요구했습니다. 원래 실행이
끝난 뒤 수정하고 SDK v0.2.28을 연결한 a63be8ed의 새 원래 CI는 모두 통과했습니다.
로컬에서는 새 기능의 집중 검사와 네이티브 실행을
확인했습니다. macOS 전체 동시 검사는 기존 플랫폼별 검사와 실행 시간 제한에서
실패도 남아 있어, 전체 로컬 검사가 통과했다고 해석하면 안 됩니다.
병합된 소스로 새로 확인한 모델 없는 조립과 저장 재실행은 각각11/11, 중간 조건은3/3이었고 모델 판단은0회였습니다. 같은 자체 모델의 조건 피드백 조립도 출력7/7·조건3/3을 확인했습니다. 이 결과는 아래 이전 생산자의 실험과 구분해 별도로 보관했습니다.
작은 자체 모델에 “입력이 음수인지 비교한다”는 힌트를 줬는데, 실제로는
0 < input을 골랐습니다. 분기 안의 계산까지 함께 뒤집으면서 최종 반환값은
맞았습니다. 도착지는 맞아도 우리가 생각한 길과 달랐던 셈입니다.
Gooo 소스에 중간 조건의 예시를 적을 수 있도록 했습니다.
condition_case "comparison" input "-1" -> "true"
condition_case "comparison" input "0" -> "false"
condition_case "comparison" input "1" -> "false"
comparison은 이미 선언한 선택의 ID입니다. 해당 if가 입력 -1에서는 참,
0과 1에서는 거짓이어야 한다는 뜻입니다. 최종 출력 예시도 그대로 함께 씁니다.
후보를 실행할 때 그 조건이 실제로 어떤 값을 냈는지 확인합니다. 다른 분기로 빠져 해당 조건을 실행하지 않았다면 ‘미실행’으로 기록하고 후보에서 제외합니다. 맞는 후보가 없으면 실패한 조건과 탐색 기록을 돌려줍니다. 호출자가 다른 경로를 고를 때와 저장한 프로그램을 다시 읽을 때도 같은 조건을 확인합니다.
모델·컴파일러·출력 사례는 같고, 위 세 선언만 추가한 비교입니다.
| 확인한 내용 | 기존 소스 | 조건을 적은 소스 |
|---|---|---|
| 최종 출력 | 11/11 | 11/11 |
| 의도한 중간 조건과 일치 | 1/3 | 3/3 |
| 첫 탐색에서 조건 때문에 제외한 후보 | 0 | 2 |
| 호출자가 확인한 조합 | 1개 | 2개 |
| 모델 판단 | 3회 | 3회 |
| 저장 후 재실행의 새 모델 판단 | 0회 | 0회 |
모델의 첫 제안은 두 경우 모두 같았습니다. 조건을 적은 쪽에서는 그 제안을 제외한 뒤 다른 후보를 확인했고, 호출자의 출력 예시까지 맞는 조합을 찾았습니다. 가중치를 새로 학습한 결과는 아닙니다. Gooo가 명시한 의도를 더 많이 확인하도록 발전한 것입니다.
가중치는 기존 2,759바이트짜리 삼진 모델입니다. 판단 한 번은 이번 측정에서 약13–16µs, 전체 조립·실행은0.84초와1.01초였습니다. 전체 명령의 최대 RSS는 약83.6MiB와82.9MiB였습니다. Go 빌드와 실행 과정이 포함된 한 번의 관측입니다. 컴퓨터 전체 CPU 사용률은 측정하지 않았습니다.
최종 입력에는 ±9007199254740995가 있고, 양수의 최종 결과
18014398509481990도 정수 그대로 확인했습니다. 저장한 프로그램은 모델을
다시 부르지 않고 같은11개 결과를 냈습니다.
후속 SDK PR15는
조건 때문에 제외된 이유를 모델의 다음 입력에 연결합니다. 이전에는 최종 출력의
실패만 전달해서, 출력은 맞고 중간 조건이 틀린 상황을 모델이 전달받지 못했습니다.
원래 push·PR CI와 병합 뒤 CI를 통과해 v0.2.28-experimental로 공개했습니다.
태그의 원래 CI도 통과했습니다.
이제 “후보 0에서 입력 -9007199254740995의 조건은 거짓이어야 했는데 참이었다”처럼 구체적인 반례 한 건을 전달합니다. 조건에 도달하지 않았으면 ‘관측하지 못함’으로 구분합니다. 한 장의 오답 메모를 다음 선택에 붙이는 정도의 구조입니다.
이미 끝난 실행의 첫 반례만 세션에 보관하며 전체 기록은 호출자가 갖습니다. 의도와 소스 입력은 유지하고, 입력 크기를 넘으면 모델 호출을 보류한 채 기존 탐색을 이어갑니다. 가중치는 그대로입니다. 개별 선택과 두·세 선택을 함께 판단하는 경로의 입력 전달, 취소, 큰 정수와 미실행 분기 검사를 포함해 SDK 전체 race·정적 검사가 통과했습니다. 위의 11/11·3/3 비교는 이 수정 이전 컴파일러의 원래 관측입니다.
새 컴파일러 5fba1326과 같은 2,759바이트 모델로 별도 관측을 했습니다.
한글·영문 의도가 있는 같은 소스, 출력 예시 일곱 개, 조건 예시 세 개를 사용했습니다.
| 확인한 내용 | 처음에만 모델 판단 | 실패 후 두 번 재판단 |
|---|---|---|
| 확인한 후보 | 5개 | 3개 |
| 모델 판단 | 3회 | 9회 |
| 출력 예시 | 7/7 | 7/7 |
| 중간 조건 | 3/3 | 3/3 |
| 모델 판단 시간 합계 | 약37µs | 약173µs |
최종 Gooo와 Go 코드는 같았습니다. 추가 판단 여섯 회를 쓰고 후보 검사를 두 번 줄인 한 사례입니다. 모델 가중치는 그대로이고, 작성한 사례를 조립 중 사용했습니다. 조건 메모만의 효과를 분리한 비교나 새 입력의 정확도 측정으로 볼 수는 없습니다.
실패 메모까지 포함한 실제 입력은456~493바이트였습니다. 현재512바이트 제한에 들어왔지만 긴 의도에서는 여유가 작습니다. 전체 명령의 최대 RSS는 약20.8MiB와21.0MiB였고, 컴퓨터 전체 CPU 사용률은 미측정입니다. 두 명령의 벽시계 시간은0.58초와0.01초였으나 순서·캐시·기동 비용이 섞여 있어 속도 향상 수치로 쓰지 않습니다.
같은 가중치와 실제 재판단 입력 여섯 개로 추가 점수 비교를 했습니다. 조건 메모를 삭제하면 비교식 선택이 두 입력에서 뒤집혔습니다. 같은 길이 공백으로 바꾸거나 기대·관측의 참과 거짓을 교환하면 여섯 입력 모두 선택은 그대로였습니다. 현재 모델은 의도와 메모의 글자 조각을 위치별로 읽어, 내용과 길이의 효과가 섞입니다. 조건의 의미를 안정적으로 이해한다고 보기에는 근거가 부족합니다.
추가 학습 없이24회 로컬 판단을 했고 원래 확률은 모두 재현됐습니다. 가상으로 바꾼 조건은 실제 소스나 실행 증거에 반영하지 않았습니다. 후속 SDK PR16에서 의도와 관측값을 별도 배열 구간으로 읽는 입력 함수를 구현했습니다. 다음 학습에서는 Gooo가 확인한 후보 집합을 사용하고 반대 조건 쌍과 새 코드 구조를 평가합니다. 원본24행·Go 재집계·구체적인 한계.
SDK PR16은 원래 push·PR CI를
통과해 main 13d7f010에 병합했습니다. 소스 구조 64칸, 의도 128칸, 조건 관측 64칸으로
나눠 담는 방식입니다. 기대값과 실제값, 미실행 분기를 별도로 표현하며 큰 정수도 보존합니다.
출력 배열은 1,024바이트입니다. 이 입력으로 학습한 첫 자체 모델은
Go 도구에서 선택·본문 생성·사례 확인까지 연결했고, 일반 컴파일러 CLI 연결은 후속 단계입니다.
이미 실행한 여섯 입력을 새 형식으로 바꿔 확인했습니다. 관측값을 없애거나 참거짓을 교환해도 소스·의도 부분은 유지됐고, 참거짓 교환은 해당 네 칸만 바꿨습니다. 새 모델 판단이나 학습 없이 확인한 입력 표현의 성질입니다. 18회 특징 추출과 원본.
지금은 정수 하나를 받아 정수 하나를 돌려주는 typed-path 본문의 if 조건을
대상으로 합니다. branch_layout 또는 if 전체 조건의 operand_order 선택에
연결하며, 최대128개 예시를 적을 수 있습니다. 조건문 안의 현재 변수값을 사용합니다.
동일한 if와 입력의 중복 선언은 다른 ID로 가리켜도 허용하지 않습니다.
세 예시를 맞췄다는 사실과 모든 입력에서 의도가 맞는다는 주장은 범위가 다릅니다. 완전성 기록에는 최종 출력과 중간 조건의 맞은 수를 각각 남깁니다. 적지 않은 조건이나 새 입력의 동작은 여전히 확인해야 합니다.
다음 모델 학습에서는 출력과 중간 조건을 함께 만족하는 후보들을 정답 집합으로 만들 수 있습니다. 가능한 길이 여러 개면 그 여러 길을 보존하고, 새 한글·영어 표현과 새로운 코드 구조를 나누어 평가하려고 합니다. 이번에는 그 학습을 위한 명시적인 언어 조건과 실행 기록을 연결했습니다.
- 문서 홈
- 현재 상태와 지원 범위
- 문자열과 한 조건 조립의 0.6.32
- 문자열을 읽고 찾는 0.6.31
- 실패를 기록하며 조립을 이어가는 0.6.30
- 업무 규칙 예제와 실제 도입 기준
- 요구를 바꾼 뒤 결과 비교하기
- 결과 조회와 자체 모델의 0.6.28 배포
- 저장 결과를 비교하는 0.6.27 배포
- 작은 모델과 조립하는 0.6.26 배포
- 중간 조건을 확인하는 0.6.25 배포
- 분기 구성·재실행의 0.6.24 개발 후보
- 작은 도구로 발전시키는 Gooo
- 흐름도로 보는 Gooo
- 시작하기
- 언어 둘러보기
- 사용 흐름
- 작은 모델과 메타프로그래밍
- 우리 PC의 자체 경로 decision 모델
- 조건을 읽는 자체 모델과 실제 탐색
- SDK 0.2.39 자체 모델 받기
- 모델 선택 점수와 실제 실패
- 설명·변수 이름 변화의 27회 관측
- 작은 모델의 학습 범위를 넓힌 결과
- 같은 계산을 같은 모델 입력으로 읽기
- 사례를 통과해도 의도가 다를 때
- 사례를 모아 읽는 방식을 바꿔 보기
- 자체 결정 모델 받기 · Hugging Face
- 비교와 분기를 따로 배우면 나아질까
- 소스에 적는 중간 조건과 선택
- 지표와 증거
- 참고하고 감사하는 연구
- 최근 연구와 다음 작은 기능