SYDev

블로그 이전(tistory -> velog)

시데브 — Tue, 20 Jan 2026 01:27:29 +0900

앞으로 https://velog.io/@tkddud386 에 포스트 게시할 예정입니다

tkddud386 (sydev) / 작성글 - velog

velog.io

[컴파일러] Chapter 6. Activation Records

시데브 — Wed, 23 Apr 2025 21:24:24 +0900

경희대학교 허선영 교수님의 컴파일러 수업을 기반으로 정리한 글입니다.

0. Backgrounds

Process in Memory

Memory Layout
- Text section: 프로그램 코드
- Data section: (uninitialized and initialized) 전역 변수
- Stack section: 일시적 데이터
  - 함수 파라미터, 리턴 어드레스, 지역 변수
- Heap section: 런타임에 동적으로 할당되는 메모리

ELF File Format

Excecutable and Linkable Format
source program -> compiler -> target binary
- target binary의 포맷 중 하나가 ELF

컴파일 결과를 sections 나누어서 저장
단순히 machine codes만 저장하는 것이 X -> 프로그램을 실행하기 위해 필요한 정보들을 포함
stakc pointer: stack의 마지막 주소

1. Stack Frames

1.1. Stack

LIFO data structure to hold local variables
Higher Address에 위치하고, lower address를 향함
Stack Pointer
- top of the stack을 가리킴
- stack pointer의 아랫 부분 -> garbage
- stack pointer의 윗 부분 -> local variables
Memory -> byte addressable
- 1 bytes = 8 bits = 8 binary digits = 2 hexadecimal digits

- operations

CPU 명령어
Push(x)
- stack_pointer--;
- M[stack_pointer] = x;
x = Pop()
- x = M[stack_ponter];
- stack_pointer++;

1.2. Stack Frames

Activation Record
함수 하나하나에 할당이 된 Area on the stack
- On entry: stack grows -> 새로운 stack frame을 유지
  - 함수를 호출할 때, 생성
  - stack overflow? -> 재귀적으로 자신을 계속 호출하면서, stack frame을 새로 쌓아가다가, stack size를 넘어서면 발생
- On retrun: stack shrinks
Frame Pointer(FP): 현재 함수의 stack frame의 시작점을 가리킴

- 함수 호출 과정

g가 Caller, f가 Callee

f 호출
1. 기존 FP 저장
2. 현재 SP를 FP에 할당
3. SP는 새로운 stack frame의 크기(N)만큼 아래로
return
1. 현재의 FP를 SP에 할당
2. 저장된 FP를 FP에 복원

함수의 호출은 다음의 인스턴스화를 의미
- Local Variables
- Parameters
- Return Addresses
- Other temopraries
Arguments accessed by offset from FP
- argument 1: M[ FP + a1 ]
- argument 2: M[ FP + a2 ]
- Caller Frame에 존재
Local Variables accessed by offset from FP
- local variable 1: M[ FP - i1 ]
- local variable 2: M[ FP - i2]
- Frame 내부에 존재
Dynamic Link(Control Link)
- FP 백업 -> caller의 stack frame을 가리킴
- current stack frame의 return 시에 복원하기 위함
- compile time 시에, caller frame의 사이즈가 고정됐다는 것을 알 수 있으면 필수 X

1.3. Stack Frame Organization

- Calling Convention

Calling Convention
- 마이크로 프로세서 제조사는 모든 컴파일러가 사용하는 "표준" 레이아웃 방식을 지정
  - ex) 매개변수는 어디에 배치되는가? 매개변수는 어떤 순서로 전달되는가?
- 모든 컴파일러가 같은 calling conventions 사용 -> 하나의 컴파일러로 다른 컴파일러로 컴파일된 함수를 호출 가능
- OS/Libraries와 상호작용에 필수적

2. Registers

Registers are faster than memory
- 컴파일러는 가능한 register에 값을 저장해놔야 함
Calling conventio
- Caller-save registers: caller가 저장해야 하는 레지스터
  - callee 호출 이후 사용될 레지스터 values -> 미리 stack에 저장
  - Callee function은 해당 레지스터 값들을 저장하지 않고, caller-save registers 사용
- Calle-save registers: callee가 저장해야 하는 레지스터

-> caller save registers, callee save registers의 저장 >> 해당 레지스터들을 callee 내부에서 자유롭게 사용 가능

Registers가 저장하는 것들
- Parameters
- Return Values
- Intermediate results of expressions(temporaries) -> 프로그램 실행 중간 결과
Stack Frame이 저장하는 것들
- register에 저장하기에 크기가 큰 variables
- Array variables

3. Passing Parameters

f(a1, a2, ..., an)
Modern calling convention
- a1, ..., ak를 registers r1, ..., rk에 저장
- 나머지 ak, ..., an을 stack에 저장

-> 나중에 해당 레지스터들을 사용할 필요가 생기면, 해당 레지스터 값들도 f함수 내부에서 push 진행될 수 있음

C language에서는 former parameter(argument)의 주소(pointer)에 접근 가능
- pointer -> 메모리에 해당 주소값이 저장돼있다는 의미
- parameters가 레지스터로 옮겨지더라도, 주소를 위한 공간은 반드시 할당되어야 함!!
  - stack frame이 사라질 때, 해당 주소값이 함께 사라질 수 있음 -> Dangling Reference 발생
Nested Functions with Returned Function
- 현대 언어의 nested function의 경우 local variables를 heap에 저장해야 함
- ex) 함수 f(x)는 g(y)라는 함수를 반환하는데, g(y)는 x + y를 반환하는 함수이다.
- 하지만, 함수 f(x)가 종료된 시점에 x에 대한 정보가 사라지면 g(y)에서는 이를 사용할 수가 없다.
- 따라서 stack이 아닌 heap에 x를 저장하여 보존

4. Return Address

function call을 모두 수행하고 나서, 다시 돌아가야할 명령어의 주소
calling convention에 따라
- x86 -> on the stack
- arm -> in a register
Callee-save register

5. Static Links

Dynamic Link: 이런 frame의 시작점을 FP에 할당하는 방식
Static Link
- outer function's stack frame에 접근하고자할 때 사용

[알고리즘] Chapter 3. 동적계획(Dynamic Programming)

시데브 — Mon, 21 Apr 2025 01:01:46 +0900

경희대학교 한치근 교수님의 알고리즘 수업을 기반으로 정리한 글입니다.

Dynamic Programming

divide-and-conquer(분할정복식, 재귀): top-down 해결법
Dynamic Programming: bottom-up 해결법
- 작은 문제 해결 먼저 -> 결과를 큰 문제의 해결로 확산
  1. 재귀 관계식(recursive property) 정립
  2. 작은 사례를 먼저 해결하는 상향식 방법으로 진행

1. 이항계수 구하기

문제: 이항계수를 계산
입력: 음수가 아닌 정수 n과 k, 여기서 k <= n
출력: bin, nCk

- 시간복잡도(분할정복식 접근방법)

귀납증명에 따라, nCk를 구하기 위해서 알고리즘이 계산하는 항(term)의 개수는 2*nCk - 1

- 동적계획법 알고리즘 설계전략

recursive property 정립
nCk를 구하기 위해서 B[0][0]부터 시작하여 위에서 아래로 재귀 관계식을 적용하여 배열을 채워 나가면 됨

총 수행횟수는 ∈ Θ(nk)

2. 최단경로 문제(all-pairs shortest paths problem)

- 그래프 용어

정점(vertex, node), 이음선(edge, arc)
방향 그래프(directed graph/digraph)
가중치(weight), 가중치 포함 그래프(weighted graph)
경로(path): 각 정점에서 다음 정점을 잇는 이음선이 존재하는 일련의 정점들
단순경로(simple path): 같은 정점을 두 번 지나지 않는 경로
순환(cycle): 한 정점에서 다시 그 정점으로 돌아오는 경로
순환 그래프(cyclic graph) vs 비순환 그래프(acyclic graph)
- cycle이 있는 그래프 vs 없는 그래프
길이(length): 경로상에 있는 가중치의 합(가중치 포함 그래프). 경로상의 이음선의 개수(가중치가 없는 그래프)

2.1. all-pairs shortest paths problem

문제: 가중치 포함, 방향성 그래프에서 최단경로 찾기
최적화문제(optimization problem)
- 주어진 문제에 대하여 하나 이상의 많은 해답이 존재할 때, 이 가운데에서 optimal solution을 찾아야 하는 문제

- Adjacency Martix: W

- Brute-force algorithm

한 정점에서 다른 정점으로의 가능한 모든 경로들의 길이를 구한 뒤, 그들 중에서 최소 길이의 경로를 탐색
분석
- n개의 정점이 모두 연결된 상태
- 처음에 선택 가능한 정점 n-2개, n-1개, ...
- 총 경로의 개수는 (n-2)! -> 지수함수보다 큰 시간복잡도 비효율적!

- Dynamic Programming

case 1: { v1, v2, .. ,vk }의 정점들만을 통해서, v_i에서 v_j로 가는 최단경로가 v_k를 거치지 않는 경우
case 2: { v1, v2, .. ,vk }의 정점들만을 통해서, v_i에서 v_j로 가는 최단경로가 v_k를 거치는 경우

2.2. Floyd의 알고리즘 1

문제: 가중치 포함 그래프의 각 정점에서 다른 모든 정점까지의 최단거리를 계산하라
입력: 가중치 포함, 방향성 그래프 W와 그 그래프에서의 정점의 수 n
출력: 최단거리의 길이 포함된 배열 D

- 시간복잡도

every case
단위연산: for-j 루프 안의 지정문
입력크기: 그래프에서의 정점의 수 n
- T(n) = n * n * n = n^3 ∈ Θ(n^3)

- 3차원 배열이 필요하지 않은 이유

k는 가장 늦게 증가하기 때문에, k번째 node를 경유하는 상태를 계산할 때, k를 중간에 넣기 전 상태이므로 덮어써도 문제 없음

2.3. Floyd의 알고리즘 2

출력: 최단경로의 길이가 포함된 배열 D, 다음을 만족하는 배열 P
P[i][j]: i에서 j까지 가는 최단 경로 중, j 바로 이전에 들른 노드
- vi에서 vj까지 가는 최단경로의 중간에 놓여 있는 정점이 최소한 하나는 있는 경우 -> 놓여 있는 정점 중에서 가장 큰 인덱스
- 최단경로의 중간에 놓여 있는 정점이 없는 경우 -> 0

2.4. 최적의 원칙

the principle of optimality: 어떤 문제 사례에 대한 최적 해가 그 사례를 분할한 부분 사례에 대한 최적해를 항상 포함하고 있는 경우
최적의 원칙이 적용되어야 -> 동적 계획법 사용 가능
- ex) 최단 경로 구하는 문제에서, vk를 vi에서 vj로 가는 최적 경로 상의 정점이라고 하면
- vi에서 vk로 가는 부분경로 & vk에서 vj로 가는 부분경로도 반드시 최적이어야 함

- 최적의 원칙이 적용되지 않는 예: 최장경로(longest path) 문제

v1에서 v4로의 최장경로는 [v1, v3, v2, v4]
그러나 이 경로의 부분경로인 v1에서 v3으로의 최장경로는 [v1, v3]이 아니고, [v1, v2, v3]이다.

3. 연쇄 행렬 곱셈(matrix-chain multiplication)

i x j 행렬과 j x k 행렬을 곱하기 위해서는 i x j x k번의 곱셈이 필요
연쇄적으로 행렬곱셈을 수행할 때, 어떤 행렬곱셈을 먼저 수행하느냐에 따라 필요한 총 곱셈의 횟수가 달라짐
ex) A1 x A2 X A3
A1의 크기는 10 X 100, A2의 크기 100 X 5, A3의 크기 5 X 50
(A1 X A2) X A3 곱셈의 총 횟수 7500 = 5000 + 2500
- (10 * 100 * 5) + (10 * 5 * 50)
A1 X (A2 X A3) 곱셈의 총 횟수 75000 = 25000 + 50000
- (10 * 100 * 50) + (100 * 5 * 50)

3.1. Brute-force

시간복잡도 최소 exponential-time

Brute Force의 모든 가능한 가지 수 P(n)
- P(n) = C(n - 1): Catalan Number

-> n이 커질수록 기하급수적으로 커지므로 최적화 필요

3.2. Dynamic Programming

DP 기본 개념
- i ~ k 범위에서의 최소곱셈 & k + 1 ~ j까지의 범위에서의 최소 곱셈
- 그 둘을 곱하는 곱셈의 횟수

- example

- 최적 순서의 구축

-> M[i][j]를 구하기 위해서는 M[i][k]와 M[k+1][j]가 이미 구해져 있어야 함

- 시간복잡도

every case ∈ Θ(n^3)

4. 최적 이진검색 트리

Optimal Binary Search Tree: 키를 찾는데 걸리는 평균시간이 최소가 되도록 구축된 트리
각 키를 찾을 확률이 주어져 있을 때(모두 같지 않음), 키를 찾는데 걸리는 평균시간이 최소가 되도록 이진트리를 구축하는 문제
notation
- p_i = key_i의 검색 빈도 -> 얼마나 자주 검색되는지
- c_i = 주어진 트리에서 Key_i를 찾는데 필요한 비교횟수
- 평균검색시간 = Σ(c_i * p_i)

-> DP에서는 매 단계가 1층 기준이므로, c_i = 1 ->> Σp_i

-> 일반화 버전

-> 해당 일반화 식을 이용하여 표를 채운 이후, A[1][n]을 구하면, 해당 값이 최적값

A 배열: 최적 BST의 평균 검색 시간 -> 최적 BST의 모양은 알 수 없음
R 배열: A 배열에 최적값을 넣는 순간 k의 값 -> 루트 노드가 k(좌측 서브트리가 1~k-1, 우측 서브트리가 k+1 ~ n)

5. DNA 서열 맞춤(sequence alignment)

동족서열(homologous sequence)
- 하나의 종에서 출발하여, 교환, 삽입, 삭제 돌연변이에 의해 서열이 달라짐
- 달라진 두 종에서 추출한 염기서열을 동족서열이라 함
- 이 두 서열이 얼마나 다른지를 확인해서, 종족 간의 거리를 측정
- 두 개의 염기서열을 어떻게 맞춰야 할까?
DNA 서열 맞춤 문제: 두 개의 서열을 최소비용으로 맞추는 방법을 찾는다.

opt(i, j): 부분 서열 x[i, ..., 9]와 y[j, ..., 7]의 최적 맞춤 비용
opt(0, 0): 부분 서열 x[0, ..., 9]와 y[0, ..., 7]의 최적 맞춤 비용 -> 구하려는 최종 비용

둘을 맞추는 경우 -> penalty = 0
못 맞추는 경우 -> penalty = 1
y쪽을 틈으로 비워두는 경우 -> +2
x쪽을 틈으로 비워두는 경우 -> +2

- Divide-and-Conquer 구현

-> 중복호출하는 경우가 너무 많아 비효율적

- Dynamic Programming

1. 틈 행과 틈 열을 채워 넣음

2. 우측 아래부터 대각원소들을 채워 넣음

>> 최적서열맞춤 찾아가는 방법

[0][0] 선택
경로에 넣을 둘째 항목을 찾는다
1. [0][1] 검사
2. [1][0] 검사
3. [1][1] 검사

>> 맞춤된 서열을 구성하는 방법

최적배열의 오른쪽 맨 아래 구성에서 시작하여 표시해둔 경로를 따라감
배열의 [i][j]칸에 도달하기 위해서 대각선으로 이동할 때 마다,
- i번째 행에 해당하는 문자를 x서열에 넣고
- j번째 행에 해당하는 문자를 y 서열에 넣음
배열의 [i][j]칸에 도달하기 위해서 위로 이동할 때 마다,
- i번째 행에 해당하는 문자를 x서열에 넣고
- 틈 문자를 y서열에 넣음
배열의 [i][j]칸에 도달하기 위해서 아래로 이동할 때 마다
- 틈 문자를 x서열에 넣고
- j번째 행에 해당하는 문자를 y서열에 넣음

참고자료

https://gsmesie692.tistory.com/116

최적 이진 탐색 트리 (Optimal Binary Search Tree)

이전 포스팅에서 설명했던 이진 탐색 트리 (BST) 의 활용 예를 보자. 설명할 때는 보통 이해하기 쉽게 노드에 들어있는 데이터를 숫자로 가정하지만, 실제로 쓰일 때는 문자열이라던가 더 다양한

gsmesie692.tistory.com

[알고리즘] Chapter 2. 분할정복법(Divide-and-Conquer)

시데브 — Thu, 17 Apr 2025 02:30:45 +0900

경희대학교 한치근 교수님의 알고리즘 수업을 기반으로 정리한 글입니다.

분할정복(Divide-and-Conquer)식 설계 전략

분할(Divide): 해결하기 쉽도록 문제를 여러 개의 작은 부분으로 나눔
정복(Conquer): 나눈 작은 문제를 각각 해결
통합(Combine): (필요하다면) 해결된 해답을 모음

-> 이런 문제 해결 방법을 하향식(top-down) 접근방법이라 함

1. 이분검색(binary search): 재귀식 방식

설계 전략
- x가 배열의 중간에 위치한 항목과 같으면 stop, 그렇지 않으면
  - Divide: 배열을 반으로 나누어 x와 중앙값을 비교하여 배열 반쪽을 선택
  - Conquer: 선택된 반쪽 배열에서 x를 찾음

def bs(data, item, low, high):
    # item 존재 X
    if(low > high):
        return -1
    
    mid = (low + high) // 2

    # 탐색 성공
    if(item == data[mid]):
        return mid
    # 우측 배열
    elif(item > data[mid]):
        return bs(data, item, mid + 1, high)
    # 좌측 배열
    else:
        return bs(data, item, low, mid - 1)
    
data = [1, 3, 5, 6, 7, 9, 10, 13, 17, 19]
n = 10
location = bs(data, 17, 0, n - 1)
print(location)

- 시간복잡도

2. 합병정렬(mergesort)

- Mergesort

문제: n개의 정수를 비내림차순으로 정렬
입력: 정수 n, 크기가 n인 배열 S[1..n]
출력: 비내림차순으로 정렬된 배열 S[1..n]
보기: 27, 10, 12, 20, 25, 13, 15, 22

배열 S를 U와 V로 분할
U와 V에 대해서 mergesort 호출
U와 V에 대해서 merge 호출

- Merge

문제: 두 개의 정렬된 배열을 하나의 정렬된 배열로 합병하시오.
입력: (1) 양의 정수 h, m, (2) 정렬된 배열 U[1..h], V[1..m]
출력: U와 V에 있는 키들을 하나의 배열에 정렬한 S[1..h+m]

U, V의 iterator i, j를 선언, i, j를 모두 추적하는 k를 선언
크기에 따라 i, j를 ++ -> k++
i가 모두 돌았으면, j부터 m까지(나머지 부분)를 S에 copy | j가 모두 돌았으면 i부터 h까지를 S에 copy

- 시간복잡도

단위연산: U[i]와 V[j]의 비교
입력크기: 2개의 입력 배열에 들어 있는 항목의 개수: h&m
- i = h + 1, j = m인 상태로 loop에서 빠져나가는 경우
- ex) U: 4 5 6 7, V: 1 2 3 8
- W(h, m) = h + m - 1
단위연산: 합병 알고리즘 merge에서 발생하는 비교
입력크기: 배열 S에 들어 있는 항목의 개수 n
- W(h, m) = W(h) + W(m) + h + m - 1
- W(n) = 2W(n/2) + n - 1, W(1) = 0
- W(n) ∈ Θ(nlgn) -> 도사정리 적용

- 공간복잡도

제자리정렬(in-place sort) 알고리즘: 추가적인 저장장소를 사용하지 않고 정렬하는 알고리즘
mergesort는 제자리 정렬이 X

총 저장 장소의 크기: n + n/2 + n/4 + ... = 2n
- 2n ∈ Θ(n)

def mergeSort(n, s):
    mid = n // 2
    u = s[:mid]
    v = s[mid:]
    h = len(u) 
    m = len(v) 
    
    if(n > 1):
        mergeSort(h, u)
        mergeSort(m, v)
        merge(h, m, u, v, s)
    

def merge(h, m, u, v, s):
    i = j = k = 0
    
    while(i < h and j < m):
        if(u[i] < v[j]):
            s[k] = u[i]
            i += 1
        else:
            s[k] = v[j]
            j += 1
        k += 1

    if(i >= h):
        remained = v[j:m]
        for value in remained:
            s[k] = value
            k += 1
    else:
        remained = u[i:h]
        for value in remained:
            s[k] = value
            k += 1

- 공간복잡도가 향상된 알고리즘

-> 공간 재사용

-> 반으로 나눠진 S의 정렬된 형태를 U에 저장하다가, 마지막에 S로 최종 결과물을 복사

def mergeSort2(s, low, high):
    if(low < high):        
        mid = (low + high) // 2
        mergeSort2(s, low, mid)
        mergeSort2(s, mid + 1, high)
        merge2(s, low, mid, high)

def merge2(s, low, mid, high):
    u = [0 for i in range(high - low + 1)]
    i = low
    j = mid + 1
    k = 0
    
    while(i <= mid and j <= high):
        if(s[i] < s[j]):
            u[k] = s[i]
            i += 1
        else:
            u[k] = s[j]
            j += 1
        k += 1

    if(i > mid):
        remained = s[j:high+1]
        for value in remained:
            u[k] = value
            k += 1
    else:
        remained = s[i:mid+1]
        for value in remained:
            u[k] = value
            k += 1
    
    for i in range(len(u)):
        s[low + i] = u[i]

-> index 유의하여 구현

3. 빠른정렬(Quicksort)

분할 교환 정렬(partition exchange sort)
문제: n개의 정수를 비내림차순으로 정렬
입력: 정수 n>0, 크기가 n인 배열S[1..n]
출력: 비내림차순으로 정렬된 배열 S[1..n]

- quicksort

partition 수행한 값을 pivotpoint에 할당
quicksort(low, pivotpoint - 1)
quicksort(pivotpoint + 1, high)

- partition

pivotitem으로 첫 번째 항목 선택
i = pivotitem + 1, i번째 item이 pivotitem보다 작으면 j번째 항목과 i번째 항목 위치 변경, 이후 j++ -> j 왼쪽의 아이템들은 모두 pivotitem보다 작은 items
pivotpoint = j & pivotitem을 pivotpoint에 위치

def exchange(index1, index2, s):
    temp = s[index1]
    s[index1] = s[index2]
    s[index2] = temp

def partition(s, low, high):
    pivotItem = s[low]
    j = low
    
    for i in range(low + 1, high + 1):
        if(s[i] < pivotItem):
            j += 1
            exchange(i, j, s)
    pivotPoint = j
    
    exchange(low, pivotPoint, s)
    return pivotPoint
    

def quickSort(s, low, high):
    if(low < high):
        pivotPoint = partition(s, low, high)
        quickSort(s, low, pivotPoint - 1)
        quickSort(s, pivotPoint + 1, high)

s = [3, 5, 2, 9, 10, 14, 4, 8]
quickSort(s, 0, 7)
print(s)

- partition 시간복잡도

단위연산: S[i]와 pivotitem 비교
입력크기: 부분배열이 가지고 있는 항목의 수, n = high - low + 1
분석: 배열의 첫 번째 항목만 제외하고 모든 항목을 한 번씩 비교하므로, T(n) = n - 1

- quicksort 분석

단위연산: partition의 S[i]와 pivotitem 비교
입력크기: 배열 S가 가지고 있는 항목의 수, n
분석: 입력이 비내림차순으로 정렬된 경우가 최악, pivotitem보다 작은 항목이 없으므로,
- 피벗 아이템의 좌측: 크기가 0인 배열
- 피벗 아이템의 우측: 크기가 n-1인 배열
- T(n) = T(0) + T(n - 1) + n - 1, T(0) = 0

-> W(n) ∈ Θ(n^2)

+ A(n) ∈ Θ(nlgn)

+ B(n) ∈ Θ(nlgn)

4. 행렬 곱셈(matrix multiplication)

문제: n x n 크기의 행렬의 곱을 구하시오
입력: 양수 n, n x n 크기의 행렬 A와 B
출력: 행렬 A와 B의 곱인 C

- 시간복잡도

단위연산: 가장 안쪽의 루프에 있는 곱셈하는 연산
입력크기: 행과 열의 수, n
Every case: 총 곱셈의 횟수
- T(n) = n * n * n = n^3 ∈ Θ(n^3)

-> 한 단계 당 8번의 곱셈 연산 필요

- 개선된 알고리즘 시간복잡도

단위연산: 가장 안쪽의 루프에 있는 덧셈하는 연산
입력크기: 행과 열의 수, n
Every case: 총 덧셈의 횟수
- T(n) = (n - 1) * n * n = n^3 - n^2 ∈ Θ(n^3)

- Strassen algorithm

n이 2의 거듭제곱이고, 각 행렬을 4개의 submatrix로 나눈다고 가정. 두 n x n 행렬 A와 B의 곱 C

Strassen의 해

문제: n이 2의 거듭제곱일 때, n x n 크기의 두 행렬의 곱을 구하시오.
입력: 정수 n, n x n 크기의 행렬 A와 B
출력: 행렬 A와 B의 곱인 C

A, B를 4개의 부분 행렬로 분할
Strassen 방법을 사용하여 C = A * B 계산 - strassen(n/2, A11 + A22, B11 + B22, M1)
임계점에서 단순 알고리즘 계산

from numpy import *

def strassen(n, A, B, C):
    threshold = 2
    A11 = array([[A[rows][cols] for cols in range(int(n/2))]for rows in range(int(n/2))])
    A12 = array([[A[rows][cols] for cols in range(int(n/2), n)]for rows in range(int(n/2))])
    A21 = array([[A[rows][cols] for cols in range(int(n/2))]for rows in range(int(n/2), n)])
    A22 = array([[A[rows][cols] for cols in range(int(n/2), n)]for rows in range(int(n/2), n)])
    
    B11 = array([[B[rows][cols] for cols in range(int(n/2))]for rows in range(int(n/2))])
    B12 = array([[B[rows][cols] for cols in range(int(n/2), n)]for rows in range(int(n/2))])
    B21 = array([[B[rows][cols] for cols in range(int(n/2))]for rows in range(int(n/2), n)])
    B22 = array([[B[rows][cols] for cols in range(int(n/2), n)]for rows in range(int(n/2), n)])
    
    if(n <= threshold):
        C = array(A) @ array(B)
    else:
        M1 = M2 = M3 = M4 = M5 = M6 = M7 = array([])
        M1 = strassen(int(n/2), (A11 + A22) , (B11 + B22), M1)
        M2 = strassen(int(n/2), (A21 + A22) , B11, M2)
        M3 = strassen(int(n/2), A11 , (B12 - B22), M3)
        M4 = strassen(int(n/2), A22 , (B21 - B11), M4)
        M5 = strassen(int(n/2), (A11 + A12) , B22, M5)
        M6 = strassen(int(n/2), (A21 - A11) , (B11 + B12), M6)
        M7 = strassen(int(n/2), (A12 - A22) , (B21 + B22), M7)
        
        C = vstack([ hstack([M1 + M4 - M5 + M7, M3 + M5]), hstack([M2 + M4, M1 + M3 - M2 + M6]) ])
    return C

n = 4

A=[ [1,2,0,2], [3,1,0,0], [0,1,1,2],[2,0,2,0]]
B=[ [0,3,0,2], [1,1,4,0], [1,1,0,2],[0,5,2,0]]
C = array(A)@array(B)
D = [[0 for cols in range(n)]for rows in range(n)]
print(C)
D=strassen(n, A, B, D)
print(D)

- Strassen 알고리즘 시간복잡도

단위연산: 곱셈 연산
입력크기: 행과 열의 수, n
Every case:
- T(n) = 7T(n/2), T(1) = 1

-> strassen에서는 곱셈이 7번!!

- Strassen 알고리즘 시간복잡도 2

단위연산: 덧셈/뺄셈 연산
입력크기: 행과 열의 수, n
Every case:
- T(n) = 7T(n/2) + 18(n/2)^2 , T(1) = 0 -> 7회의 곱셈과 18회의 덧셈

- Discussion

5. 큰 정수 계산법

문제: 2개의 큰 정수 u와 v를 곱하라
입력: 큰 정수 u와 v, 크기 n
출력: prod(u와 v의 곱)

-> 2개의 큰 정수 곱셈을 4개의 작은 정수 곱셈으로 변환 가능

- 개선된 방법(Karatsuba)

ex) a = a1 * 10 + a0, b = b1 * 10 + b0
- 기존 방식: a * b = (a1 * 10 + a0)(b1 * 10 + b0)
  - a1b1, a1b0, a0b1, a0b0
- 카라츠바
  - z0 = a0 * b0
  - z2 = a1 * b1
  - z1 = (a0 + a1) * (b0 + b1) - z0 - z2
  - -> 곱셈이 4번에서 3번으로 줄어듦

- 시간복잡도

기존: W(n) ∈Θ(n^lg4) = Θ(n^2)
카라츠바: W(n)∈Θ(n^lg3) ~= Θ(n^1.58)

6. 임계값결정

어느 크기의 문제가 딜 때까지 분할할 것인가
optimal threshold value를 결정하는 방법

- 분할정복을 사용하지 말아야 하는 경우

크기가 n인 입력이 2개 이상의 조각으로 분할되며, 분할된 부분들의 크기가 거의 n에 가깝게 되는 경우 -> exponential
- ex) T(n) = 2T(n - 1) + n
크기가 n인 입력이 거의 n개 조각으로 분할되며, 분할된 부분의 크기가 n/c인 경우. 여기서 c는 상수 -> Θ(n^lgn)
- ex) T(n) = nT(n/2) + n

7. 도사 정리(The Master Theorem)

1보다 큰 상수 a, b, 어떤 함수 f(n), 음이 아닌 정수 n에 대해서 정의된 재현식 T(n)이 다음 형태라 가정
- T(n) = a x T(n/b) + f(n)
- T(n)은 다음과 같은 점근적 한계점(asymptotic bound)을 가질 수 있음

[컴파일러] Chapter 5. Semantic Analysis

시데브 — Tue, 15 Apr 2025 02:40:36 +0900

경희대학교 허선영 교수님의 컴파일러 수업을 기반으로 정리한 글입니다.

0. Introduction

Understanding the meaning of a sentence -> 문장의 의미를 유추
- Check ambiguity & type
- ex) Jack and Jack left her homework at home
  - 잭은 몇 명?
  - jack과 her의 미스매치

1. Semantic Analysis

each expression이 correct type을 가지는지
- x + y -> x는 int, y는 string이면 error
translate Abstract Syntax Tree -> Intermediate Representation(IR) Trees

Semantic analyzer also can check
- All identifiers(Variable, Class, Functions, Methods, ...) -> 한 번만 선언됐는지
  - parser에서도 가능 -> compiler designer들이 결정
- Inheritance Relationship - 상하관계
- Types are well defined and related
- Reserved Identifiers가 잘못 사용되지는 않았는지

- Motivation

Lexical Analysis: 잘못된 Tokens를 Detecting
- ex) 123foo -> 처리할 수 없는 토큰
Parsing: 문법을 잘못 작성한 경우
- ex) if then 절에 if(조건문) -> 조건문 부분을 뺀 경우
Semantic Analysis
- ex) abc + 3 -> parser cannot catch the error

2. Symbol Table

Symbol Table(Environment)
- main data structure in semantic analysis
- Identifiers(variables, functions, class name, ..)-> types & loactions 매핑
- identifier가 어떤 type에 mapping됐는지를 저장 -> bindings라 부름
- ex){g ↦ string, a ↦ int}

- exmaple

0: Initial environment

-> 가장 가까운 binding 사용

-> 범위를 벗어나면 이전 정의로 회귀

2.1. Symbol Table - Implementation

Imperative Style
- single global environment
- beginning-of-scope 진입
  - table에 entries 추가
- end-of-scope 도달
  - previous addition을 제거
Functional Style
- beginning-of-scope 진입
  - old one에 추가함으로써, 새로운 environment 생성
  - old table remains pristine
- end-of-scope 도달
  - retrieve old table

2.3. Imperative Symbol Table

Symbol tables must permit efficient lookup of identifiers -> id의 type을 빠르게 찾아낼 수 있어야 함
- Hash Tables - an array of buckets
- Bucket - linked list of entires(각 entry에 binding 하나 존재)

simplest example) string length를 bucket id로 사용 -> length에 대한 modulo 연산을 id로 사용
Symbol table을 하나만 유지!!
- Insert new element at front of bucket
  - example) val a: string = "x" -> h(a) = 0
- Remove each symbol at the end of the scope
  - example) pop(a)

2.4. Functional Symbol Table

기존 테이블을 수정하는 방식 X -> new table을 생성
- example) val a: string = "x"
- 기존 테이블을 link하는 식으로 효율적으로 테이블 생성

- Better Medhot: use binary search trees

BST
- easy insertion
- tree build 시에 ordering이 필요할 시에

3. Type System

Type System
- typing rules의 집합으로 구성
  - typing rules -> expressions에 types 할당
- 어떤 type에 어떤 operations가 valid한지 특정
Type Checking
- expression의 type이 type system에 따라 유효한지 검사
- operations가 올바른 type과 사용되었는지 보장
Type Inference(타입 추론)
- type system에 따라, type을 자동으로 추론
- 생략된 타입 정보를 자동으로 채움
  - ex) let = 3일 때, x의 타입은 자동으로 int로 추론

3.1. Typing Rule

expression에 type을 할당하기 위한 유도 법칙
if hypothesis(가정) is true -> conclusion is true
- ex) if e1 has type t1 & e2 has type t2 -> e3 has type T3
A typing rule: 1: 1 ∧ ⋯ ∧ : ⇒ :
- Hypothesis ⇒ Conclusion
  - if hypothesis is true, then conclusion is true
- e: T
  - e has type T
- Symbol ∧
  - and

- example

( 1: ∧ 2: ) ⇒ 1 + 2:

axiom: inference rule with no premise(가정) -> always true

3.2. Type Inference

expression의 type을 유도하기 위해 -> type system의 typing rules 사용
- Build a Derivation tree(Typing Derivation) by applying typing rules

- example

Grammar
- E -> NUM
- E -> E + E
Type System

Type Inference: 1 + 2

-> 완성된 derivation tree

-> axiom으로부터 하나씩 type 추론

3.3. Type Environment

Problem: What is the type of a variable?

Solution
- Put more informaiton in the rules
- Type environment gives the types of variables

Γ ⊢ ∶ ⇔ expression e has type A under type environment Γ

- example

- What is type of the following expression?

- Fun & Arg

Type System

4. Subtyping

Subtyping: Compatibility(호환성) of interfaces
- A에 대한 subtype B -> A 객체에서 호출 가능한 모든 함수: B 객체에서도 호출 가능
- A를 호출하는 function에 B가 대신 들어갈 수 있는가!!
Inheritance: Reuse of implementations
- A를 상속하는 B -> A의 구현을 재사용할 수 있다는 뜻

-> input 1개로 f를 호출 가능하지만, g는 호출 불가능: g는 f의 subtype X

-> input 2개로 g를 호출 가능, 또한 f도 호출 가능: f는 g의 subtype 가능

4.1. Subtyping Rules

Reflectivity: 스스로의 subtype이 될 수 있음

Transitivity: t1이 t2의 subtype & t2가 t3의 subtype이면 -> t1은 t3의 subtype

Depth: tuple의 길이가 동일할 때, 내부 scalar가 모두 subtype 관계를 가져야, tuple의 subtype 관계가 성립

Width: tuple의 일정 길이를 자른 tuple을 T2, 전체 tuple을 T1이라 할 때, T1은 T2의 subtype

추가적으로, int와 <int>는 다른 타입, subtype 관계도 가지지 않음
Function: argument는 일반화, return은 구체화돼야 subtype이 될 수 있음

-> 기존에 f를 사용하던 자리에서는 int를 2개만 받아도 됐음,

-> g로 교체되면 input이 2개만 들어오면 문제가 발생

-> g는 f의 subtype이 될 수 없음

- return 또한 마찬가지

-> 기존 f를 사용하던 자리에서는 2개의 return이 필요

-> g로 교체되면 return이 1개만 발생

-> 2개가 필요한 경우 문제 발생

4.2. Subtyping - Join

Motivation: 다음 expression의 return type?
- if a > 0 then <<3,4>, 5> else <<6>, 7, 8>
- -> if, then, else의 type이 각각 다름
Join: find least common supertype
- 짧은 쪽 tuple에 맞춤
- join <int> & int -> int?: impossible

-> 짧은 쪽으로 맞추기!!

-> subtype에 가까운 방향

4.3. Subtyping - Meet

Meet: find most common subtype
- supertype에 가까운 방향
함수의 subtype 구할 때,
- argument type: supertype -> meet
- return type: subtype -> join
- ( 이 부분 개념 질문 후에 수정 예정.. )

5. Static Typing vs Dynamic Typing

Statically Typed Language
- 컴파일 과정에서 all or almost type checking이 완료되는 언어
  - 컴파일 단계에서 많은 programming errors 검출
  - runtime type checking overheads를 피함
- ex) C, Java, Fun
Dynamically Typed Language
- Almost all type checking이 프로그램 실행 단계에서 완료되는 언어 -> 실행하면서 타입 유추
  - static type systems are restrictive
  - rapid prototyping is difficult within a static type system
- ex) PHP, Scheme, Python
Untyped Language
- No type checking
- ex) Machine codes -> binary 형태이기에 checking 필요 X
in practice, 정적 Language에도 escape mechanism 존재
- Unsafe casts in C, Java

[알고리즘] Chapter 1. 알고리즘: 효율, 분석 그리고 차수

시데브 — Mon, 14 Apr 2025 19:35:06 +0900

경희대학교 한치근 교수님의 알고리즘 수업을 기반으로 정리한 글입니다.

1. 알고리즘

문제를 해결할 수 있는 잘 정의된(well defined) 유한(finite) 시간 내에 종료되는 계산적인(computational) 절차(prodcedure)
input -> output: 일련의 계산 절차

- 알고리즘과 Method의 차이

Algorithm: 유한 시간 내에 종료
Method: 유한 시간 내에 종료하는지 모름

문제의 표기 방법

문제: 답을 찾고자 던지는 질문
Parameter: 문제에서 특정 값이 주어지지 않은 변수 - 매개변수
Instance(입력): 파라미터에 특정 값을 지정한 것
Solution(출력): 주어진 사례에 관한 질문에 대한 답

수학적 귀납법(mathematical induction)

귀납 출발점(basis, base case): n = 0(또는 1)일 때, 주장이 사실임을 보임
귀납 가정(induction(inductive) hypothesis): 어떤 n에 대해서 주장이 사실임을 가정
귀납 절차(inductive step): n + 1에 대해서 주장이 사실임을 보임

-> n >= 2인 모든 n에 대해서 T(n) > 2^(n/2)

두 Fibonacci algorithm의 비교

2. 알고리즘의 분석(analysis)

공간복잡도(space(memory) complexity 분석)
- 입력 크기에 따라서 작업 공간(memory)이 얼마나 필요한지 결정하는 절차
- 표현 척도: input size
시간복잡도(time complexity) 분석
- 입력 크기에 따라서 단위연산이 몇 번 수행되는지 결정하는 절차
- 알고리즘이 수행되는 machine에 따라 문제 해결 시간이 달라짐
- 표현 척도: comparison, assignment

2.1. 분석 방법의 종류

Every-case analysis(모든 경우 분석)
- 입력 크기에만 종속, 입력 값과는 무관하게 결과 값이 항상 일정
Worst-case analysis(최악의 경우 분석)
- 입력 크기와 입력 값 모두에 종속
- 단위연산이 수행되는 횟수가 최대인 경우 선택
Average-case analysis(평균의 경우 분석)
- 입력 크기에 종속
- 모든 입력에 대해서 단위연산이 수행되는 기대치(평균)
- 각 입력에 대해서 확률 할당 가능
- 일반적으로 최악의 경우보다 계산이 복잡
Best-case analysis(최선의 경우 분석)
- 입력 크기와 입력 값 모두에 종속
- 단위연산이 수행되는 횟수가 최소인 경우 선택

- 배열 덧셈 시간복잡도 분석

- 교환 정렬 시간복잡도 분석

단위연산: 조건문(S[j]와 S[i]의 비교)
- every case
- j loop 수행 횟수: T(n) = n -1 + n -2 + ... + 1 = ((n-1)n)/2

단위연산: 교환 연산(exchange)
- worst case
- 조건문이 항상 true인 경우 -> W(n) = ((n-1)n)/2

- 행렬 곱셈 시간복잡도 분석

단위 연산: 가장 안쪽 for loop에 위치한 곱셈
- every case
- T(n) = n * n * n = n^3

- 순차 검색 시간복잡도 분석

단위 연산: 배열이 아이템과 키 x와 비교 연산(S[location] != x)
- worst case
  - x가 last item | x가 배열에 없는 경우 -> W(n) = n
- average case

best case
- x가 S[1]에 위치할 때, B(n) = 1

2.2. Discussion

complexity function: 음이 아닌 정수가 주어지면, 음이 아닌 실수를 내주는 함수 -> 정수 n을 시간으로 매핑!!
f(n) = n, lg n, 3n^2, ...

2.3. 정확도 분석

알고리즘이 의도한 대로 수행되는지 증명하는 절차
정확한 알고리즘: 어떠한 입려겡 대해서도 답을 출력하면서 멈추는 알고리즘
정확하지 않은 알고리즘: 어떤 입력에 대해서 멈추지 않거나, 틀린 답을 출력하면서 멈추는 알고리즘

3. 차수(order)

대표적인 복잡도 함수
- Θ(lg n)
- Θ(n): 1차 - linear
- Θ(nlg n)
- Θ(n^2): 2차 - quadratic
- Θ(n^3): 3차 - cubic
- Θ(2^n): 지수 - exponential
- Θ(n!)
- Θ(n^n)

3.1. 복잡도 함수의 증가율

3.2. Asymptotic(점근적) Behavior

n이 큰 수가 될 때의 함수 f(n)이 갖는 특성

3.3. 복잡도 함수 표기법

O() - big oh: aymptotic upper bound
o() - small oh: upper bound that is not asymptotically tight
Ω() - omega: aymtotic lower bound
ω() - small omega: lower bound that is not asymptotically tight
Θ() - theta: asymptotic tight bound

- big O notation

ex) 어떤 함수 g(n)이 O(n^2)에 속한다.
- n이 N보다 커진 시점에서 어떤 2차함수 cn^2보다는 반드시 작은 값을 가짐
- 함수 g(n)은 N보다 n이 큰 시점에, n^2보다는 반드시 성능이 좋다는 의미
- 시간 복잡도가 O(f(n)) -> 입력 크기 n에 대해서 알고리즘의 수행 시간이 아무리 늦어도 cf(n)은 된다는 의미
ex) n^2 + 10n이 O(n^2)에 속하는지?
- n >= 10인 모든 정수 n에 대해서 n^2 + 10n <= 2n^2 성립
- c = 2, N = 10에 대해서 n^2 + 10n이 O(n^2)에 속함

- Ω notation

ex) 함수 g(n)이 Ω(n^2)에 속한다.
- 정수 n이 N보다 커지는 순간부터, 함수 g(n)은 어떤 2차함수 cn^2보다는 반드시 큰 값을 가짐
ex) 어떤 알고리즘의 시간복잡도가 Ω(f(n))이라면,
- 이 알고리즘의 수행 시간은 cf(n)보다 절대로 더 빠를 수 없음

- Θ notation

- small O notation

complexity functions끼리의 관계를 나타내기 위한 notation

Big O와의 차이점
- Big O: 실수 c>0 중 하나만 성립해도 됨
- small o: 모든 실수 c>0에 대해서 성립해야 함

- ω notation

3.4. 차수의 주요 성질

3.5. 극한을 이용하여 차수를 구하는 방법

-> n이 충분히 커지면, n/2의 천장함수가 a^4보다 커짐

4. 알고리즘 복잡도와 컴퓨터 능력

알고리즘 복잡도가 cn일 때 t시간 동안
- 현재의 기계가 문제 크기 m개의 문제 해결
- 기계 처리 속도 2배 -> t시간 동안 2m개 문제 해결
알고리즘 복잡도가 cn^2일 때 t시간 동안
- 현재의 기계가 문제 크기 m개의 문제 해결
- 기계 처리 속도 4배 -> t시간 동안 2m개 문제 해결
알고리즘 복잡도가 c2^n일 때 t시간 동안
- 현재의 기계가 문제 크기 m개의 문제 해결
- 기계 처리 속도 2배 -> t시간 동안 m+1개 문제 해결
- 기계 처리 속도 100배 -> t시간 동안 m+6개 문제 해결
알고리즘 복잡도가 (A)일 때 t시간 동안
- 현재의 기계가 문제 크기 m개의 문제 해결
- 기계 처리 속도 (B)배 -> t시간 동안 (C)개 문제 해결

A	B	C
cn	2	2m
cn^2	4	2m
cn^3	8	2m
c2^n	2	m+1
c2^n	100	m + 6

-> t시간에 cm^3만큼의 연산이 가능

-> 기계 성능이 8배 되었으므로, t시간에 8cm^3 만큼 연산 가능

-> 증가된 문제 크기를 m'라 가정

-> c(m ')^3 = 8cm^3

-> m' = 2m

[컴파일러] Chapter 3. Syntax Analysis(Part 2)

시데브 — Mon, 14 Apr 2025 02:31:27 +0900

경희대학교 허선영 교수님의 컴파일러 수업을 기반으로 정리한 글입니다.

1. Shift-Reduce Parsing - LR(k) Parsing

predictive parser: 어떤 production이 사용될지 예측
오른쪽 항 전체에 해당하는 입력 토큰을 볼 때까지 결정을 미룲
LR(k)
- Left-to-right parse
- Rightmost derivation
- k-token lookahead
predictive parsing(LL aprsing)보다 더 많은 grammars에 대해서 parsing 가능

- 동작 방식

parser는 stack & input을 가짐
- stack contents & next input token에 의해서, 2가지 동작 중 하나가 결정됨
  - Shift: top of stack에 next input을 push
  - Reduce: choose a production X -> ABC
    - Pop off C, B, A
    - Push X

Initialization
- Stack is Empty
- Parset is at the beginnig of input stream
if $ is shifted -> input stream has been successfully parsed

- Example

-> 어떤 타이밍에 shift/reduce를 진행할지 결정해야 함

to make shift/reduce decisions -> parser uses deterministic finite automata(DFA)
- each state -> corresponds to the contents of stack at some time
- each edge -> is labeled with a symbol(terminal or non-terminal)
DFA를 사용하여 transition table을 build
- make decisions based on transition table

sn: shift in to state n
gn: goto state n
rk: reduce by rule k
a: accept

- Example

shift + state num
reduce + production num

- 4 Actions

Shift(n)
- 입력을 한 칸 앞으로 진행
- 현재 input token과 new state n을 stack에 push
Reduce(k)
- rule k의 우변 길이(symbols 개수) 만큼 stack을 pop
- goto n 수행
- 전이된 new state n을 stack에 push

Accept
- Stop parsing, report success
Error
- Stop parsing, report error

2. LR(k) Parsing

LR(k) parsing -> content of its stack & next k tokens 사용
- 실제로는 k>1은 사용되지 않음 -> parsing algorithm이 복잡해지고, memory도 많이 사용됨
- 대부분의 programming languages는 LR(1) grammars로 표현됨
LR(0) parsing
- lookahead를 아예 보지 않고, shift/reduce decisions 진행

2.1. LR(0) Parsing

stack is empty
input contains 'S' string followed by a '$'
parser position: parser가 보고있는 위치

- Basic Operations

Closure(I): parser position 오른쪽에 위치한 non-terminal로 시작하는 모든 productions를 LR(0) items를 나타내는 I에 추가 -> I가 변하지 않을 때까지

-> S로 시작되는 모든 productions 추가

Goto(I, X): 모든 items에서 parser position을 symbol X 이후로 이동하는 함수
- 현재 state I에서 symbol X를 읽었을 때, 다음 state는 무엇인지 알려줌
- item 집합 I 내부에서, parser position 바로 우측에 X가 있는 items만 골라서 해당 items의 parser position을 한 칸 오른쪽으로 이동 -> 해당 아이템들로 만든 집합에 Clousre 연산 적용

- Example(DFA 생성)

-> DFA 완성

- Building Transition Table

-> DFA 이용하여 작성

-> conflict 발생 시에, LR(0)로 parsing 불가능한 grammar

- 최종 Example

2.2. Simple LR Parsing

LR(0) parser를 기반으로 하지만, reduce할 때 FOLLOW 집합을 사용해 reduce의 범위를 제한

-> state3에서 기존에는 모든 terminals에 대해서 reduce 진행

-> SLR에서는 T의 follow인 +, $에 대해서만 reduce를 진행

-> r3에서도 마찬가지로 E의 follow인 $에 대해서만 reduce 진행

-> LR(0)로는 parsing 불가능, but SLR로는 parsing 가능한 gammar!!

2.3. LR(1) Parsing

LR(0): A의 follower를 모두 고려
SLR: 모든 terminal 고려
LR(1): lookahead symbol만 고려

LR(1) item은 2개의 components를 가짐
- Production: A -> α.β
  - parser position은 현재 분석이 어디까지 진행되었는지 나타냄
- Lookahead symbol: x
  - 아이템이 적용될 수 있는 다음 input symbol
ex) E -> T.+E, $ : T까지 분석을 완료했고, +E를 남겨두었으며, 해당 production은 input symbol이 $일 때 사용 가능하다는 뜻

- Basic Functions

Closure

좌측: LR(0), 우측: LR(1)

-> lookahead symbol인 z까지 고려,

- β is empty: FIRST(βz) = FIRST(z)

- β is nullable: FIRST(βz) = FIRST(β) ∪ FIRST(z)

- β is not nullable: FIRST(β)만 확인

Goto

좌측: LR(0), 우측: LR(1)

-> LR(0)에서는 단순히 parser position 이동 후 closure 적용

-> LR(1)에서는 parser position 이동 후 closure를 적용하는데, lookahead가 유지돼야 함

- Example

1) First State 빌드 - Closure 연산

- V -> x, $과 V -> x, =는 다른 것으로 취급!!

2) Goto

-> $ sign이 나오는 경우에만 reduce 연산 수행

-> 기존 LR(0), SLR이 수행하던 범위보다 축소

-> but, state 개수가 많아지고 구조가 복잡해짐

2.4. LALR(1)

LR(1)의 table 크기가 너무 커지는 문제
production이 같은데, lookahead symbol이 다른 경우를 merge
LALR(1): Look-Ahead LR(1)

2.5. Parsing Power

3. Real-world Parser Generators

Parser Generator: 문법만 정의해주면, 해당 문법에 맞는 parser를 자동으로 생성해주는 프로그램
- yacc, bison: LALR parser generators for C
Parser Generator Specification
- Input: a set of context-free grammars specifying a parser
  - context-free grammar: 문맥에 상관 없이 어떤 Non-terminal이 들어와도, 그에 대한 production-rule이 존재하는 문법
- Outputs
  - a parser in target language -> 파서 코드 자동 생성
  - a description of state machine -> 어떤 state에서 어떤 symbol을 만나면 어떻게 전이되는지
- Rules: pattern & action
  - pattern: context free grammar
  - action: 문법이 만족되었을 때 실행할 code fragment
  - example) exp: exp PLUS exp { $$ = $1 + $2; }
    - exp PLUS exp라는 pattern -> { $$ = $1 + $2 ; }라는 코드 실행

- Parser Generator Example: GNU Bison

-> yyparse() 호출로 파서 실행

User Declaration
- rules section에서 사용가능한 various values 정의
- terminal, non-terminal symbols, and thier types 선언
  - %token NUM
  - %token <type> NUM
  - %token <type> exp
- precedences(우선순위)선언 -> shift-reduce conflicts 해결
- (optionally) specify start symbol
  - %start prog
Rules
- pattern & action -> pattern에 따라 어떤 action을 취할지
Location
- @$: location of the whole group
- @1: location of the first subexpression

4. Ambigous Grammar

Ambiguous Grammar: 같은 expression에 대해서 2개 이상의 parse tree가 존재하는 grammar
example) 4 + 5 * 6

4.1. Handling Ambiguous Grammar

YACC -> shift-reduce conflicts로 알림
- 4 + 5 * 6
  - stack에 expr + expr이 쌓인 상태에서, current token으로 *가 들어옴
  - parser: expr -> expr + expr rule을 통해서 reduce or shift
  - Prefer shift
- 4 + 5 + 6
  - stack에 expr + expr이 쌓인 상태에서, current token으로 +가 들어옴
  - parser: expr -> expr + expr rule을 통해서 reduce or shift
  - Prefer reduce

-> shift 이후, 위에부터 reduce 진행하니까, 6 * 5를 먼저 reduce

4.2. Directives

Three Solutions
1. Let YACC complain, but check if the choice (shift) is correct
2. Rewrite grammar to eliminate ambiguity
3. Keep grammar, but add precedence directives -> conflicts가 해결되는 방향으로
  - %left, %right, %nonassoc
  - for this grammar -> 라인의 순서가 낮으면 우선순위가 높음
    - $left PLUS MINUS -> PLUS MINUS 동등
    - $left MULT DIV -> MULT DIV 동등
주어진 directives에 따라, YACC은 each terminal & rule에 precedence 부여
- rightmost terminal과 shift할 terminal의 precedence 비교

주어진 shift-reduce conflict에 따라, YACC는 action 수행
- reduce 수행할 rule과 shift 수행할 terminal의 precedence find
  - prec(terminal) > prec(rule): shift
  - prec(terminal) < prec(rule): reduce
  - prec(terminal) = prec(rule)
    - assoc(terminal) = left : reduce
    - assoc(terminal) = right: shift
    - assoc(terminal) = nonassoc : report error -> 결합 불가(오류 처리)
    - associativity(결합법칙): 연산자끼리 우선순위가 같을 때, 어느 방향으로 묶을 것인지 결정하는 규칙

4.3. Dangling Else Problem

Valid Program: if a then if b then S1 else S2

-> if a then if b then s1 else s2 동작을 원하지만, S1이 stack의 top에 위치할 때 shift-reduce conflict 발생

solution: eliminate ambiguity by modifying grammar(matched/unmatched)

4.4. Default Behavior

Directives not specified
- shift-reduce: report error, shift by default
- reduce-reduce: report error, reduce by rule that occurs first
What to do
- shift-reduce: acceptable in well defined class, 그러나 웬만하면 없애는 것이 좋음
- reduce-reduce: unacceptable, rewrite grammar

4.5. %prec Directive

commonly used for the unary minus problem
- %left PLUS MINUS
- %left MULT DIV
consider - 4 * 6
unary minus가 우선순위가 높을 것을 권장, but MINUS의 precedence가 MULT보다 낮음
- -( 4 * 6 ) not ( -4 ) * 6
solution
- %token NUM PLUS MINUS MULT DIV UMINUS
- %left PLUS MINUS
- %left MULT DIV
- %left UMINUS
- expr: MINUX expr %prec UMINUS {}
  | expr PLUS expr {}

참고자료

https://velog.io/@legionary7931/%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D%EC%96%B8%EC%96%B4-Context-Free-grammar

[프로그래밍언어] - Context-Free grammar

Parser * Parser의 역할* Parser는 scanner로부터 tokenized 된 word stream을 받아 syntax를 확인하고, 올바른 syntax라면 중간 표현(Intermediate Representation, IR)을 도출해내는 컴파

velog.io

Elasticsearch 기본 개념 + ELK stack

시데브 — Sat, 12 Apr 2025 23:05:52 +0900

Elasticsearch

Elasticsearch: Apache Lucene 라이브러리를 기반으로 하는 오픈 소스 검색 및 분석 엔진
- 주로 대량의 데이터를 실시간으로 검색하고 분석하는 데에 사용 -> log, metric, full text ...

장점

검색 엔진: 단순한 텍스트 매칭 검색이 아닌 전문 검색이 가능, 다양한 종류의 검색 쿼리를 지원
분산 처리: 데이터를 여러 노드에 분산 저장하여 검색이나 집계 작업 등을 수행할 때도 분산 처리 지원
고가용성 제공: 클러스터를 구성하고 있는 일부 노드에 장애가 발생해도, 복제본 데이터를 이용해 중단 없이 서비슬르 지속
수평적 확장성: 더 많은 처리가 필요할 때, 새로운 노드에 elasticsearch를 설치하려 클러스터에 참여시키는 것만으로도 확장 가능
JSON 기반의 REST API 제공: JSON 형태의 문서를 저장, 색인, 검색하며, 작업 요청을 보낼 때도 JSON 기반의 REST API를 사용
데이터 안정성: 데이터 색인 요청 후 200 OK를 받았다면 데이터는 확실히 Disk에 기록
다양한 플러그인을 통한 기능 확장 지원
준실시간 검색: 최대 1초 정도의 시간이 걸림

단점

트랜잭션 지원 X
조인 연산 지원 X

Apache Lucene?

Java로 작성된 무료 오픈 소스 검색 엔진 라이브러리
-> 검색 기능을 가지고 있는 application을 개발할 때 사용 가능한 라이브러리 (자체 수집 기능 제공 X)

- 동작 방식

1) 검색 대상 분석

검색 대상 텍스트 확보
- 내부적으로 수집 기능 제공 X
- 외부에서 대상을 수집해서 전달해줌으로써 검색 대상 텍스트 확보
루씬 문서 생성
- document: 루씬에서 사용하는 개별 단위
- lucene document는 여러 개의 field로 구성됨
document 텍스트 분석
- 텍스트 분석기를 사용하여 텍스트를 token이라 불리는 단위로 분리
index에 document 추가
- indexing 과정이 끝난 해당 document를 index에 추가

2) 검색 과정

검색 화면 인터페이스를 통해 검색어 전달 받음
검색 질의 생성
- 전달받은 검색어를 검색 엔진에서 인식하는 query 객체로 변
query를 통해 검색
- query 객체에 해당하는 결과를 받아옴
- 순수 불리언 모델: 지정된 질의에 문서가 해당하는지 여부 확인, 점수 계산 X
- 벡터 공간 모델: 질의와 문서 모두 고차원 공간의 벡터로 표현, 거리를 계산하여 문서와 질의 사시의 연관도나 유사도 확인
- 두 모델을 필요에 따라 선택

apache lucene 검색 과정

ELK Stack

엘라스틱 서치는 단독으로 검색을 위해 사용하거나, ELK stack을 기반으로 사용
ELK stack: Elasticsearch + Logstash + Kibana + Beat
- Filebeat: 서버에서 생성하는 log를 수집하여 logstash 서버로 log를 전송
- Logstash: 로그 및 트랜잭션 데이터를 수집하여 집계 및 파싱(정제 및 전처리)을 하고 ES로 전달
- Elasticsearch: logstash로부터 전달받은 데이터를 저장하고, 검색 및 집계 등의 기능 제공
- Kibana: 저장된 로그를 Elasticsearch의 빠른 검색을 통해 가져와 시각화 및 모니터링 기능 제공

Elasticsearch 기본 구조

https://www.youtube.com/watch?v=B1Aq2GQ4E78&ab_channel=MinsukHeo%ED%97%88%EB%AF%BC%EC%84%9D

-> 각 document들을 미리 indexing하여 key, value 형태로 mapping

-> 따라서 기존 rdbms보다 빠를 수 밖에 없음

일반적으로 사용하는 아키텍처

https://sudarlife.tistory.com/entry/Elasticsearch-%EA%B0%84%EB%8B%A8-%EA%B0%9C%EB%85%90-%EC%9E%A5%EB%8B%A8

특정 서버에서 생성되는 데이터(일반적으로 log)를 RDBMS or Non-RDBMS에 저장하고, 검색 혹은 분석이 필요한 부분만을 데이터 추출하여 ES에 자동 저장
이때 DB에서 필요한 데이터를 추출하여 자동적으로 ES에 데이터를 전송하는 부분을 담당하는 것이 Logstash
MongoDB에 ES를 연결하는 task에 특화된 Monstache도 존재

https://sudarlife.tistory.com/entry/MongoDB-ElasticSearch-Monstache-%EB%8F%84%EC%BB%A4-%EA%B8%B0%EB%B3%B8-%EC%85%8B%ED%8C%85%EC%9D%84-%ED%95%B4%EB%B3%B4%EC%9E%90

[ MongoDB + ElasticSearch + Monstache ] 도커 기본 셋팅을 해보자

회사 내부에서 검색엔진을 적용하게 되면서 구글링을 해보니 생각보다 많은 정보가 없었다. 내가 추구하는 개발 환경은 Docker로 구축하는 것이었다. 국내 자료가 많이 없고 , 외국 자료 역시 그

sudarlife.tistory.com

MongoDB와 ES를 동기화하는 이유

https://velog.io/@emily2307/MongoDB-Elasticsearch-%EB%8F%99%EA%B8%B0%ED%99%94-using-Monstache

MongoDB - Elasticsearch 동기화 (using Monstache)

velog.io

ES는 transaction, ACID 속성 보장 X
ES의 강점은 실시간에 가까운 검색이 가능하다는 것 -> 인덱싱 비용이 높기 때문에 데이터 입력이 많으면, 빠른 검색 기능 제대로 활용 불가능
따라서, 메인 저장소로 MongoDB를 따로 두고, 검색과 분석에 필요한 필드만 커스텀 매핑으로 ES에 동기화
대부분의 기업은 ES를 Main DB 보조하는 search engine으로 사용

참고자료

Lucene in Action: Covers Apache Lucene V.3.0, Michael McCandless / Erik Hatcher / Otis Gospodnetic | Manning Publications | 2010년 07월 28일
https://www.ibm.com/kr-ko/topics/elasticsearch

Elasticsearch란 무엇인가요? | IBM

Elasticsearch는 애플리케이션을 강화하고 개발 및 관리 작업을 간소화하는 등 다양한 작업을 수행할 수 있는 오픈 소스 검색 및 분석 엔진입니다.

www.ibm.com

https://steady-record.tistory.com/entry/Elasticsearch-%EA%B2%80%EC%83%89-%EC%97%94%EC%A7%84-ElasticsearchELK

[Elasticsearch] 검색 엔진 : Elasticsearch 설치하기(+ELK)

Elasticsearch 자바로 만들어진 루씬 기반의 오픈 소스 검색 엔진이다. 다량의 데이터를 저장한다는 측면에서는 DB와 비슷해보이지만, 전혀 다르다. 주로 대량의 데이터를 실시간으로 검색하고

steady-record.tistory.com

https://jackjeong.tistory.com/78

[루씬 인 액션] 1. 루씬(Lucene)의 개념 및 구조

루씬이란? → 루씬은 자바로 만들어진 고성능 정보 검색(IR : information retrieval) 라이브러리입니다 (IR : 문서를 검색하거나, 문서의 내용을 검색하거나, 문서와 연관된 메타 정보를 검색하는 과정

jackjeong.tistory.com

https://velog.io/@soyeon207/%EC%9D%B4%EB%A1%A0-Elasticsearch-%EB%9E%80

[ES] 1. Elasticsearch 와 루씬

루씬(Lucene) 기반의 Java 오픈소스 분산 검색 엔진

velog.io

https://backtony.tistory.com/79

Elasticsearch - 기본 콘셉트와 구조도

ElasticSearch 기본 콘셉트 루씬은 데이터를 색인하고 검색하는 기능을 제공하는 검색 엔진의 코어 라이브러리입니다. 엘라스틱서치는 루씬을 코어로 이용하여 JSON 문서의 저장, 색인, 검색 등의 작

backtony.tistory.com

https://velog.io/@shinychan95/Elasticsearch-%EA%B8%B0%EB%B3%B8-%EA%B0%9C%EB%85%90-%EB%B0%8F-%ED%8A%B9%EC%A7%95-%EC%A0%95%EB%A6%AC

Elasticsearch 기본 개념 및 특징 정리

What is Elasticsearch?

velog.io

[컴파일러] Chapter 3. Syntax Analysis(Part 1)

시데브 — Sat, 12 Apr 2025 17:51:53 +0900

경희대학교 허선영 교수님의 컴파일러 수업을 기반으로 정리한 글입니다.

1. Front-end Compilation

- Lexical Analysis

문장을 토큰 단위로 분류하는 과정
정규 표현식을 사용하여 문장을 의미 단위로 구분

- Syntax Analysis

Lexical Analysis 과정에서 생성된 토큰을 기반으로 parse tree를 생성

- Semantic Analysis

프로그램의 선언과 진술이 의미론적으로 정확한지 확인하는 작업
syntax analysis와 달리 type checking 진행

2. Syntax Analysis

Abstract Syntax Tree(AST)를 빌드 -> token stream이 valid한지 체크
if the token stream is not valid -> syntax error & recover
ex) c++에서는 if 다음에 () 괄호 구조가 등장하지 않으면 문법 오류 -> syntax error

expression: value를 가지는 표현
- 1 + 2 -> 3
statement: 명령, side-effect
- c = 1 -> 명령 자체가 따로 값을 가지진 않음
ex) print("x")라는 명령어 자체는 expression X, but x라는 string은 expression

-> 토큰의 가장 말단에는 token이 위치

-> IF-THEN-ELSE도 어떤 값을 가지는 건 아니므로 statement

Why do we need a parser in addiotion to a lexer? -> 왜 Lexer에서는 문법을 체킹하지 못하는가
- 몇몇 프로그램은 recursive structures를 가질 수 있음
- Finite automata는 recursive contructs를 잡아내지 못함
- ex) digits = [0-9]+, expr = {digits} | "(" {expr} "+" {expr} ")"
(((1+2)+3)+4)와 같은 구조는 괄호가 얼마나 깊게 중첩되었는지 기억해야 함 -> but N개의 상태를 가지는 Finite Automata는 N보다 더 깊게 괄호가 중첩되면 기억이 불가능함

3. Context-Free Grammar

Regular Expressions: 토큰의 lexical structure 결정
Context-Free Grammars(CFG): 프로그램의 syntactic structure 결정

Grammar: set of productions
- production: 하나의 symbol이 여러 개의 symbol로 확장되는 구조
Symbol에는 2가지 종류가 존재
- Terminal: lexical anlysis에서 정의한 Token -> 확장이 불가능한 symbol
- Nonterminal: production의 left-side에 위치한 symbol -> 확장이 가능한 symbol
  - One of the nonterminals가 grammar의 start symbol이 됨

- example: Syntax for Straight-line program

straight-line program: 하나의 statement 당 세미콜론으로 한 줄씩 존재하는 프로그램

3.1. Derivation

Derivation(Execution of Parsing)
1. start symbol에서 시작
2. nonterminal을 right-hand sides를 이용하여 교체
Derivation을 수행하는 2가지 방식
- Leftmost Derivation: leftmost nonterminal 교체 in each step
- Rightmost Derivation: rightmost nonterminal 교체 in each step

-> leftmost or rightmost derivation

-> Start Symbol에서 시작해서 주어진 program과 동일하게 derivation 성공 시에 well-formed program

-> leftmost derivation, rightmost derivation

3.2. Parse Tree

derivation의 시각적 표현
internal node(leaf nodes를 제외한 nodes): nonterminal
leaf node: terminal

3.3. Ambiguous Grammars

parse tree를 통해서 grammar가 ambiguous한지 판단
같은 프로그램을 2개 이상의 parsing trees로 유도 가능 -> A grammar is ambiguous

-> grammar 재작성 필요!

- Problem

Different parse trees may have different meanings -> resulting in different interpreted results
example) 1 + 2 * 3

-> 둘의 결과가 다름!!

- Solution: 문법의 재정의

operators에 상대적 우선순위 부여
- *는 +보다 높은 우선순위 가짐
같은 우선순위를 가지는 경우에는 associativity로 묶기
- 1 + 2 + 3 -> ( 1 + 2 ) + 3 or 1 + ( 2 + 3 )

3.4. Inefficiency in Parse Tree

Concrete parse tree
- internal node - nonterminal
- leaf node - terminal
Concrete parse tree는 사용 불편
- 불필요한 터미널이 많아짐
Make parse trees simple -> Abstract Syntax Tree(AST)

-> tree 구조가 완성되고 나서는 (, ), ;, := 등의 symbol 정보는 필요없어짐

Abstract Syntax Tree(Abstract Parse Tree): concrete parse tree에서 불필요한 토큰 제거

example)

3.5. End-of-File Marker

parsing의 종료를 위해서는 EOF 존재해야 함
- program이 file 형태로 존재하기 때문
EOF marker: $
S' -> S$

4. Recursive Descent Parsing(Predictive Parsing)

다음 입력 심볼만 보고, 어떤 production을 적용할지 결정하는 기법
LL(k) parsing - token을 보고 미리 예측, k는 token의 개수
각 subexpression의 첫 번째 terminal symbol만 보고, 어떤 production을 사용해야 할지 결정할 수 있을 때 사용

- Example

-> Lookahead symbol이 IF면 if E ...로, BEGIN이면 begin S L로 확장

eat(): 현재 토큰이 expected token과 일치하면, 그 토큰을 소비(consume)하고 다음 토큰으로 넘어가는 함수
- consume? ['number', '+', 'number'] 상태에서, 파서가 처음에는 tokens[0]를 pointer로 가리키고 있다가, consume 처리 시에 해당 토큰을 처리됐다고 보고 포인터를 다음 토큰으로 이동

4.1. Contructing a Parser

- Basic Functions

nullable(X): X로부터 empty string(ε) 유도가 가능하면, X는 nullable
- production에 존재하는 모든 symbol이 nullable -> 해당 Symbol은 nullable

-> Z가 terminal이 되려면 반드시 d로 확장해야 함

FIRST( ): 로부터 유도된 strings의 시작점에 위치할 수 있는 모든 terminals의 집합

A -> B C D일 때
- B -> ε | b
- C -> c
- D -> d
FIRST(B)는 FIRST(A)에 포함, 추가적으로 B가 nullable이므로 B 자리가 비고, 그 자리에 C가 들어갈 수도 있으므로 FIRST(C) 또한 FIRST(A)에 포함됨

FOLLOW(X): derivation 후에 X 뒤에 위치할 수 있는 모든 terminal symobols의 집합
- Z -> XYZ(Z가 start symbol)
  - X -> Y: FIRST(Y)는 FOLLOW(X)에 포함
  - Y가 nullable이므로, FIRST(Z)는 FOLLOW(Z)에 포함
- X -> Y
  - FOLLOW(X)는 FOLLOW(Y)에 포함, Y의 마지막과 X의 마지막이 동일하기 때문
- → 1 2
  - FIRST( 2)는 FOLLOW(Y)에 포함
  - 2가 nullable일 때, FOLLOW(X)는 FOLLOW(Y)에 포함

- Example

1) Initial

2) Interation 1

3) Iteration 2

4) constructing a parser

nullable, first, follow 계산 이후 contructing a parser
nullable, first, follow -> predictive parsing table
S ->
- if is nullable -> row: S, col: FOLLOW( )에 포함되는 모든 요소
- if is not nullable -> row: S, col: FIRST( )에 포함되는 모든 요소

- Another Example

nullable, first, follow table
- 간단한 것들(소문자 symbols) 위주로 테이블에 삽입
- 이후 대문자 symbols 사이의 관계 rules 정립 -> 테이블 반영
- 정립한 rules가 table 내에서 모두 성립하는지 점검
each production에 대해서 predictive parsing table 빌드

-> 고유한 row, col에 대해서 중복되는 production 발생

-> LL(1)으로 parsing 불가능한 Grammar

4.2. Left-Recursion Problem

- problem

- solution: X를 X'으로 변환

4.3. Left Factoring

- problem: 2개의 productions가 같은 symbol로 시작

S -> if E then A
S -> if E then A else A
FIRST(if E then A) = FIRST(if E then A else A)

- solution: Left Factoring

S -> if E then A V
- V -> ε
- V -> else A

참고자료

https://velog.io/@dbstjd0924/%EC%BB%B4%ED%8C%8C%EC%9D%BC%EB%9F%AC-1.Lexical-Analysis

컴파일러 (1.Lexical Analysis)

주어진 언어로 작성된 컴퓨터 프로그램을 다른 언어의 동등한 프로그램으로 변환하는 프로세스이다.보통 high-level 프로그래밍 언어를 실행 프로그램으로 만들기 위한 lower level언어(어셈블리어,

velog.io

https://velog.io/@dbstjd0924/%EC%BB%B4%ED%8C%8C%EC%9D%BC%EB%9F%AC-2.Syntax-Analysis

컴파일러 (2.Syntax Analysis)

쉽게 말하면 lexical analysis의 결과로 만들어진 token들을 문법에 따라 분석하는 parsing 작업을 수행해서 parse tree를 구성하는 작업이다.parse tree를 만들기 위해서 사용하는 문법이다.여기서 문법을 쉽

velog.io

https://velog.io/@dbstjd0924/%EC%BB%B4%ED%8C%8C%EC%9D%BC%EB%9F%AC-3.Sematic-Analysis

컴파일러 (3.Sematic Analysis)

의미 분석이란, 프로그램의 선언과 진술이 의미론적으로 정확한지 확인하는 작업이다.즉, 프로그램의 의미가 명확하고 제어 구조와 데이터 형식을 사용해야 하는 방식과 일치하는지 확인하는

velog.io

[컴파일러] Assignment 1. Lexical Analysis

시데브 — Sat, 12 Apr 2025 14:48:55 +0900

경희대학교 허선영 교수님의 컴파일러 수업을 기반으로 정리한 글입니다.

Goals of this Assignment

Build a lexical analyzer for a new language, using a lexer generator for OCaml(ocamllex)
know how to write a regular expression to represent a given set of strings
Understand how to write and debug ocamllex specification

ocamllex

ocamllex: lexer generator for OCaml
ocamllex specification consists of three parts as shown in the example in Snippet 1.
1. User Declarations: auxiliary(보조자) values & types 작성
  - Line 0 to 5
2. Lex Definitions: regular expression 정의
  - Line 7
  - Format: let ident = regexp ...
3. Rules: rules for lexical anlysis 포함
  - Line 9 to 11
  - Format: rule entrypoint [arg1 ... argn] = parse regexp { action } | ...

ocamllex provides predefined special operations for lexical analysis
- Lexing.lexeme lexbuf: return the matched string
- Lexing.lexeme_char lexbuf n: return the n-th character in the matched string
- Lexing.lexeme_start lexbuf: return the start position of the matched string
- Lexing.lexeme_end lexbuf: return the end position of the matched string
in addition, ocammlex allowss to define multiple entry points for rules
- can switch to another entry point by calling entrypoint lexbuf.

The Fun Language

Fun: new programming language introducedd in this course
goal of the assignments: to build a compiler for the Fun language

- Specification of the language

Reserved words: fun, in, let, while, do, if, then, else, ref, not
Identifiers
- An identifier is a sequence of letters, digits, and underscores, starting with a letter
- Upper-case letters are distinguished from lower-case letters
Numbers
- Each number is a sequence of digits
- minus sign should be lexed as a separate token
Other Tokens

Comments: start with /* and end with */
Whitespaces: Newlines(\n), carriage-returns(\r), tabs(\t)

Lexical Analyzer for Fun

(* CSE322 Compiler Assignment 1 *)
{
exception Eof

(* create a tuple of the start and end positions *)
let make_pos buf = (Lexing.lexeme_start buf, Lexing.lexeme_end buf)
}

let alpha = ['A'-'Z''a'-'z']
let digit = ['0'-'9']
let projnum = '0' | ['1'-'9'] digit*
let ident = alpha ( alpha | digit | '_')*

rule initial = parse
  | "fun"  { Tokens.tok_fun(make_pos lexbuf) }
  | "->"   { Tokens.tok_arrow(make_pos lexbuf) }
  | "in"   { Tokens.tok_in(make_pos lexbuf) }
  | "let"  { Tokens.tok_let(make_pos lexbuf) }
  | "else" { Tokens.tok_else(make_pos lexbuf) }
  | "then" { Tokens.tok_then(make_pos lexbuf) }
  | "if"   { Tokens.tok_if(make_pos lexbuf) }
  | "assign"   { Tokens.tok_assign(make_pos lexbuf) }
  | "!"    { Tokens.tok_bang(make_pos lexbuf) }
  | "ref"  { Tokens.tok_ref(make_pos lexbuf) }
  | "do"   { Tokens.tok_do(make_pos lexbuf) }
  | "while"    { Tokens.tok_while(make_pos lexbuf) }
  | "||"   { Tokens.tok_or(make_pos lexbuf) }
  | "not"  { Tokens.tok_not(make_pos lexbuf) }
  | "&"    { Tokens.tok_and(make_pos lexbuf) }
  | ">"    { Tokens.tok_gt(make_pos lexbuf) }
  | "="    { Tokens.tok_eq(make_pos lexbuf) }
  | "<"    { Tokens.tok_lt(make_pos lexbuf) }
  | "*"    { Tokens.tok_times(make_pos lexbuf) }
  | "-"    { Tokens.tok_minus(make_pos lexbuf) } 
  | "+"    { Tokens.tok_plus(make_pos lexbuf) }
  | ")"    { Tokens.tok_rparen(make_pos lexbuf) }
  | "("    { Tokens.tok_lparen(make_pos lexbuf) }
  | ":"    { Tokens.tok_colon(make_pos lexbuf) }
  | ";"    { Tokens.tok_semicolon(make_pos lexbuf) }
  | ","    { Tokens.tok_comma(make_pos lexbuf) }

  | "#" projnum as s   { Tokens.tok_proj(make_pos lexbuf, int_of_string (String.sub s 1 (String.length s - 1))) } 

  | ident as id { Tokens.tok_id(make_pos lexbuf, id) } 
  | digit+ as num { Tokens.tok_num(make_pos lexbuf, int_of_string num) } (* num 처리 *)

  | [' ' '\t' '\r'] { initial lexbuf }
  | "\n" { Errormsg.new_line(make_pos lexbuf); initial lexbuf }

  | "/*" { comment 1 lexbuf }

  | eof    { raise Eof }

  | _ {
      let msg = Printf.sprintf "Unexpected character: %s" (Lexing.lexeme lexbuf) in
      Errormsg.impossible msg
    }

and comment depth = parse
  | "/*" { comment (depth + 1) lexbuf }
  | "*/" { if depth = 1 then initial lexbuf else comment (depth - 1) lexbuf }
  | eof  { Errormsg.impossible "Unclosed comment" }
  | _    { comment depth lexbuf }