인간 디버거의 로그 찍기

[AI] Visualizing and Understanding Convolutional Networks 논문 리뷰

developer-ellen — Mon, 16 Sep 2024 16:43:25 +0900

https://arxiv.org/pdf/1311.2901

0. Abstract

AlexNet부터 Large Convolutional Network models들이 ImageNet에서 상당히 안정적인 성능을 보임
그러나, 왜 모델들이 잘 동작하는지, 어떻게 개선이 된건지에 대해 명확한 이해가 없음
해당 paper를 통해 새로운 visualization techinique을 제시하여 intermediate feature layer들과 분류기의 operation에 대한 함수의 통찰력을 제공함
서로 다른 layer들이 미치는 performance contribution을 측정하기 위해, 하나씩 제거해보는 연구를 수행
추가적으로, ImageNet model의 다른 dataset들을 이용해서 일반화 특성을 파악함

1. Introduction

1990년대 초반, LeCun의 연구에서는 CNN이 손글씨 인식이나, face detection등에 우수한 성능을 보인다고 소개됨
2012년도 ImageNet 대회에서 AlexNet이 PASCAL VOC 데이터 셋에 대해 error가 16.4%로 1등을 함(2등 model은 26.1%)
- → 성능 향상 요인
  - 레이블링된 수백만개의 샘플 학습 데이터 셋
  - 강력한 GPU 파워가 제공되어 큰 규모의 모델들의 practical한 학습 가능
  - Dropout과 같은 모델의 regulation 전략이 발전됨
이러한 계속되는 발전에도 불구하고, 이런 복잡한 모델들의 내부 operation과 behavior들에 대한 인사이트가 거의 없음 → trial-and-error가 시행됨
해당 논문의 제안
- 각각의 feature map들을 자극하는 입력 stimuli를 나타내기 위해 visualization techinique을 제안
  - 시각화는 training동안 feature들의 진화를 관찰할 수 있게 해줌
  - 모델의 잠재적인 문제를 진단 가능하게 함
- 제안한 visualization technique는 Zeiler라는 사람이 제안한 Deconvolutional Network(deconvnet)을 사용함
  - input pixel 공간에 feature activation을 투영시킴
  - classification할 때 어느 부분이 중요한지 분석함
해당 논문에 활용지점
- 해당 tool을 사용해서 ImageNet에서 1등한 Alexnet을 탐구함
- 모델의 일반화 능력을 위해 다른 데이터로도 탐험함

1) Related Work

기존 Visualizing feature
- 현실에서 network를 파악하기 위해, 시각화 방법을 많이 사용함 → 대부분 pixel공간으로 projection이 가능한 1번째 레이어로 제한됨
- 상위 Layer를 시각화 하는 방법 중 하나인 unit activation을 최대화 하기 위해 이미지 공간의 gradient descent를 수행하며 각 unit의 최적의 stimuli를 찾는 방법
  - unit? CNN의 뉴런, 예를 들어 Convolutional Layer의 필터의, Fully Connected Layer의 뉴런 등..)
  - 조심스러운 initialization이 필요하며, unit들의 불변성(invariance)에 대해 어떠한 정보도 받지 못하는 어려움 존재

Unit’s Invariance
- Invariance한 뉴런은 입력이 특정 변환을 거치더라도 해당 feature로 high response를 유지하는 것
- 예를 들어, 얼굴 특징을 탐지하는 뉴런의 경우 얼굴이 rotate되더라도 recognition을 잘 하는 것

해당 논문에서 제시하는 Visualizing techinique
- 학습 데이터셋에 대해 어떤 패턴이 feature map을 activation시키는지 보기 위해 invariance(불변성)을 non-paramatric한 view에서 제공한 기법을 제안
- 본 논문에서 사용하는 Convolution layer대신 Convet의 Fully Connected layer로부터 투영하게 saliency map을 얻는 기법과 상당히 유사함
  - input image를 crop하지 않고,각 feature map에 top-down structure에 투영함

2. Approach

본 논문은 표준 fully supervised convnet model인 Alexnet을 사용

Alexnet

8개의 layer로 구성 → 5개의 Conv layer, 3개의 FC layer

1) Visualization with a Deconvnet

CNN의 동작을 이해하기 위해, 중간의 hidden layer들의 feature activity에 대한 해석이 필요함
- input space로 다시 mapping 시키는 Deconvolutional Network에 기반한 새로운 방법을 제시
이러한 mapping을 Deconvolutional Network(deconvnet)등을 사용함
- 네트워크, 즉 pixel의 mapping 되는 과정에 정반대라고 생각하면 됨
convnet을 진단하기 위해, deconvnet은 각 layer들에 부착됨
Image pixel들까지 다시 되돌아오는 경로가 제공됨

시각화 방법
1. 입력 Image가 주어지면, convnet에 제공되고 feature가 각 layer를 통과하며 계산함
2. 주어진 convnet의 activation을 진단하기 위해, layer내에 다른 모든 activation을 0으로 setting하고, feature map에 통과하게 함으로써, deconvnet layer의 입력이 되도록 함
  1. unpool 수행
  2. rectification을 수행
  3. filter을 수행하여 layer아래의 activation들을 restruct해줌 → 선택된 activation를 시각화

Unpooling

convnet에서 maxpooling 연산은 non-invertible(역을 계산할 수 없는) 연산
- maxpooling을 가장 큰 값만을 가지고 나머지는 버리는 연산이기 때문
maxima값의 location 정보를 저장한 것을 switch variables 기록하며, inverse를 근사하는 값을 얻을 수 있음
switch layer로 reconstruction하는 과정에서 적절한 위치를 잡게함으로써 stimulus의 구조를 보존함

Rectification

Rectification? ReLU의 활성화함수 적용
- f(x)=max(0,x)
해당 논문에서 convnet은 Relu(비선형) 함수를 사용함
- feature map들이 rectifiy되며 feature map들이 항상 positive한 상태를 보장받음
Relu를 거치면 양수인 부분은 그대로라서 상관이 없지만, 음수 부분은 아예 0이 되어버려서 살릴 수 있는 방법이 없음 → 해당 논문에서 음수부분은 우리가 원하는 stimulus를 찾는데는 영향을 끼치지 않아 문제가 되지 않다고함

Filtering

convolution연산을 inverse 하기위해 같은 filter들의 transpose하고, 연산된 결과와 곱함
참고 : https://medium.com/apache-mxnet/transposed-convolutions-explained-with-ms-excel-52d13030c7e8

3. Training Details

ImageNet dataset의 classfication 수행을 위해 AlexNet model 사용
- 3, 4, 5번째의 layer의 sparse connection을 dense connection으로 대체
  - AlexNet의 training할 때는 GPU를 분리해서 병렬 수행했기 때문
학습 데이터
- 해당 모델은 ImageNet 2012 dataset으로 학습(1.3 milion image, 1000개의 class)
- 입력 크기는 256x256으로 cropping한 후, 224x224로 sub cropping을 수행
hyperparameters
- 128 mini batch size, learning rate 0.01
학습하는 도중 첫 번째 layer의 시각화는 일부가 dominant한 것을 확인 가능함
- 이를 위해, convolutional layer의 각 filer를 renormalize함
학습
- 70 epoch 이후 학습을 멈추고, 12일간 GTX 580로 학습 진행

4. Convnet Visualization Result

1) Feature Visualization

training된 model의 feature들을 시각화한 결과
- deconvnet을 사용해서 ImageNet의 validation set에 대해서, feature activation을 시각화함
Results
- layer1, 2는 edge, corner와 같은 low level의 feature들을 추출함
- layer3의 경우, 좀 더 깊어진 high level의 feature, 사물의 texture나 어느정도의 물체를 추출함
- layer4는 사물이나 개체의 일부분의 feature를 시각화
- layer5는 사물이나 개체의 위치 및 자세 변화를 포함하는 전체모습을 시각화함
- layer가 더 깊어질 수록 더 세밀한 특징을 잡아냄

2) Feature Evolution during Training

각 feature들을 학습하는데 1, 2, 5, 10, 20, 30, 40, 64 epoch가 소요됨
- epoch가 커짐에 따라 특징을 제대로 추출 가능함

3) Feature Invariance

invariance
- 함수의 입력이 바뀌어도 출력은 그대로 유지되는 것
그림에서 행
- a는 사진을 translation했을 때
- b는 scale 했을 때
- c는 rotation 했을 때를 의미
Results
- a,b, c2와 a, b,c3은 layer1과 layer7에서 원본과 변형된 이미지의 feature vector 사이의 Euclidean distance를 나타낸 그래프
- a, b, c4는 각 이미지에 변형됨에 따라각 이미지를 옳게 분류할 확률을 나타냄
- layer1에서는 작은 변화에도 민감하게 변하지만, layer7에서는 불변성이 얻어지는 것을 확인

4) Architecture Selection

Alexnet을 visualization하면서, 더 좋은 모델을 만들기 위해 노력함
- Layer 1: 11x11 filter를 7x7 filter로 줄임
- Layer 2: Stride size를 4에서 2로 줄임
더 선명하고, 다양한 filter를 얻을 수 있었음

5) Occlusion Sensitivity

해당 paper의 저자들은 input image에 특정 부분을 가리면, 분류가 어떻게 동작되는지 확인하는 실험을 함
이를 확인하기 위해 obejction의 일부분을 회색 박스로 가리고 학습을 진행
- 결과로, 물체를 가리면 그 물체를 제대로 분류할 가능성이 떨어진다는 것을 확인함

사진 예시
- (c)는 최상단인 feature map에서 deconvent을 이용한 결과 → 강아지 얼굴이 가장 강력한 feature로 추출됨
- (d)는 가린 부분을 옮겨가며, feature map의 활성도 결과를 보여줌 → activation이 확 떨어지는 것을 확인
- (e)는 가린 부분을 옮겨가며, 분류에 대한 결과
4.3 Correspondence Analysis
- 아래 실험은 강아지의 location(오른쪽 눈, 왼쪽눈, 코, 랜덤선택)을 회색박스로 가린 후 original 사진과 feature vector의 오차값을 계산했음
- 해당 차이값으로 서로 다른 이미간에 Hamming distance로 계산해서, 그 값이 작다면 서로 다른 이미지들에서 feature가 달라진 방식이 유사하다는 것을 의미
- 실험 결과 5번째 레이어에서 낮은 점수를 기록함→ CNN모델이 특정 물체를 구성하는 부분간의 대응을 계산함

5. Experimental

우리는 AlexNet model을 구조를 거의 복제하고, Image Net의 data를 이용해서 training
- 거의 error rate가 비슷함

1) Varying ImageNet Model Sizes

Layer 3, 4, 5의 크기를 각각 384, 1024, 512로 변경했을 때 더 나은 성능을 보였음
- middle layers들의 size를 변형하면 performance가 좋아짐
FC layer인 Layer 6, 7의 size를 늘렸을 경우 오히려 Overfitting이 발생해 더 낮은 성능을 보였음
- fully connected layers들의 size를 변형하면 눈에 띄게 performance가 안 좋아짐

2) Feature Generalization

다른 data set(Caltech-101, Caltech-256, PASCAL VOC 2012)를 이용해 해당 모델의 generalizaiton한 feature 탐구
Alexnet 기반에서 위에서 성능이 좋다고 평가된 모델 구조로 new training data를 가지고 학습
Caltech-101, Caltech-102는 ImageNet dataset 결과와 비슷, PASCAL은 다름
- PASCAL은 아마 data bias가 있음…

6. Discussion

해당 논문에서 제시한 Visualizing Techinique으로 각 Layer의 feature map의 분포를 살폈음
- 각 layer들의 feature map을 디버깅하며 더 좋은 성능을 보여주는 모델의 구조를 찾음
여러 occlusion 실험을 통해 local structure에는 매우 민감하다는 것을 알게됨
layer를 하나씩 제거해보면서, 적은 depth를 갖는 네트워크 모델은 performance에 치명적이라는 것을 알게됨
ImageNet으로 pretraining된 model을 다른 데이터셋에 적용해보면서 generalization feature를 알아봄

[AI] Deep Residual Learning for Image Recognition

developer-ellen — Mon, 16 Sep 2024 16:13:20 +0900

https://arxiv.org/pdf/1512.03385

0. Abstract

그 전의 ImageNet 모델에서 상 받은 모델들
- AlexNet(8 Layer) → VGGNet(19 Layer) → GoogleLeNet(22 Layer)
- 신경망의 depth가 깊어질수록 accuracy가 좋아짐
해당 논문의 배경
- Neural Networks가 깊어질수록 Train이 어려워지는 문제 발생
  - → 해당 paper에서 이것을 해결위해 Residual learning framework를 제안함
Residual Learning Framework
- east to opitimize, accuracy increased by deeper depth
- VGGNet보다 8배(152 layers) 더 깊어졌지만, Complexity는 더 낮음
- ResNet 모델로 3.57%의 error를 거둠→ ILSVRC2015 classification 대회에서 1등
Depth의 중요성
- 많은 visual recognition task에서 중요함
- Deep Residual Net은 ILSVRC & COCO 2015 대회에서도 1등을 함

1. Introduction

1) Deep convolutional neural networks

Deep CNN은 image classfication에서 돌파구와 같은 혁신을 가져옴
end-to-end multi-layer 방법으로 low / mid / high level의 특징 및 분류기를 자연스럽게 통합함
- low-level에서 high-level로 갈 수록, 기본적인(엣지, 텍스처)와 같은 특징에서 더 추상적이고 복잡한 특징들이 확인 가능함 → layer가 더 추가될수록 이런 특징들이 자연스럽게 통합됨

최근의 evidence, 즉 성능이 좋아지는 “very deep” model들을 살펴보면, depth의 중요성은 커지고 있음

2) Is learning better networks as easy as staking more layers?

Vanishing/Exploding gradients

해당 question의 가장 큰 장해물은 Vanishing/Exploding gradients
- 하지만 해당 문제는 SGD를 적용해 10개의 layer까지는 normalization 기법과 Batch normalization과 같은 intermediate normalization layer를 사용할 경우 해당 문제가 없음

Batch Normalization은 딥러닝 모델에서 Gradient Vanishing 문제를 해결하는데 중요
1. 출력 정규화
: 각 층의 출력을 정규화하여 안정적인 기울기 흐름을 유지
2. 기울기 흐름 개선
: 기울기 소실 문제를 완화하여 깊은 네트워크에서도 효과적으로 학습
3. 학습 가속화
: 더 높은 학습률을 사용할 수 있게 하여 학습 속도를 높임

Degradation

depth가 점점 증가면서, accuracy는 어느 순간 급격히 저하됨
이런 degradation의 문제는 예상외로 overfitting 때문이 아님
- 어느 순간 정확도가 더 이상 증가하지 않고, 오히려 감소하는 현상이 발생
depth를 높이면 → Training Error가 올라감

Identity mapping

해결책으로 Identity mapping을 추가함
- Identity mapping ? 입력 x를 그대로 출력하는 함수, f(x) = x
- Residual Learning에서 중요한 역할을 함
deeper model를 설계할 때, Identity mapping이라는 layer를 추가함
- identity mapping이면 연산량도 증가하지 않고, training error가 증가하는 일도 없음 → 단순히 depth만 깊어짐

Deep Residual Learning

우리는 deep residual learning frame을 제안하며, degradation problem을 해결함
기존 network는 input x를 받고, layer를 거쳐 H(x)를 출력함
- input x를 타겟값 y로 mapping하는 함수 H(x)를 얻는 것이 목적이었음
ResNet의 Residual Learning은 H(x)가 아닌, 출력과 입력의 차인 H(x) - x를 얻도록 목표를 수정함
Residual function F(x) = H(x) - x
- F(x)를 최소화 시켜야 하고, 출력과 입력의 차이를 줄임
- input x는 값을 변경하지 못하니, H(x)= x로 mapping하는 것이 학습의 목표가 됨
이전에는 Unreference mapping인 H(x)를 학습시켜야 한다는 점에서 어려움이 있었으나, 단순히 H(x) = x라는 최적 목표값이 제공되어 학습이 더 쉬워짐
H(x) = F(x) + x로 네트워크 구조도 크게 변경할 필요가 없음
- 단순히 입력에서 출력으로 바로 연결되는 shortcut만 추가하면 됨
  - short cut? 하나 또는 그 이상의 layer의 연결을 skip하는 것
- 파라미터 수에 영향이 없으며, 덧셈이 늘어나는 것을 제외하면 연산량 증가는 없음
Vanishing gradient 문제를 해결 가능
- 곱셈 연산에서 덧셈 연산으로 변형되어, 몇 개의 layer를 건너뛰는 효과가 있음

2. Related Work

Residual Representations, Shortcut Connections이 적용된 사례를 설명

Shortcut Connections

“Inception” layer에서도 Shortcut branch를 가짐
경쟁인, “highway networks”도 shortcut connections을 가지지만, data-dependent해서 parameter를 가짐
그러나 ResNet의 shortcut connection은 parameter가 전혀 추가되지 않으며, 지속적으로 residual function 학습이 가능함

3. Deep Residual Learning

1) Residual Learning

Residual function
- F(x) = H(x) - x
이러한 residual learning layer를 추가하면서, 더 deeper한 model이 될 수 있음
identity mapping이 추가되기 때문에, 더 deeper한 model이 더 얕은 모델보다 training error가 커지지않음 → degradation problem의 해결
Identity mapping이 최적인가?
- 해당 paper의 저자는, Identity mapping이 최적의 해법일 가능성을 낮다라고 주장
- 그러나, ResNet에서 사용하는 재구성방법이, degradation 문제를 더 쉽게 풀 수 있도록 도움을 줄 수 있다라고 주장
- 최적 함수가 Zero mapping보다는 Identity Mapping에 더 가깝다면, Identity mapping을 기준으로 학습하는게, 더 쉬움
  - Zero Mapping
    - 모든 입력을 0으로 매핑하는 함수
    - H(x)≈0인 경우, 네트워크는 완전히 새로운 함수를 학습해야 하며, 이는 더 어려운 작업이 될 수 있음

2).Identity Mapping by Shortcuts

제안하는 공식
- x : input vector
- y : output vector
- F(x. {Wi}) : 학습에 매핑될 잔차
shortcut은 파라미터나, 복잡한 연산 복잡성을 추가하지 않음
F(x) + x 연산을 위해, x(input)과 F(output)의 차원이 같아야함
- 만약 차원이 다를 경우

linear projection인 Ws를 추가로 곱하여 차원을 같게 만듦

3) Network Architecture

Plain Network

base model로 VGGNet을 사용
conv filter 3x3이고 다음 design rule로 설계함
- 만약 같은 output feature map size라면, 같은 layer들은 모두 같은 수의 conv filter를 사용
- 만약 output feature map size가 반으로 되면, filter의 수를 2배 늘림 → 각 layer의 time complexity를 동일하게 유지하기 위해
- downsampling을 할 때, stride가 2인 conv filter를 사용함
- 모델 끝에, global average pooling layer를 사용하고, 사이즈가 100인 fully-connected layer와 softmax를 적용함
전체 layer의 갯수는 34인데, VGGNet보다 적은 필터와 복잡성을 가짐
- 우리 네트워크는 FLOPs(multiply-adds)가 3.6billion, VGG-19는 19.6billion

Residual Network

Residual Network는 Plain 모델에 기반해, Shortcut connection을 추가해서 구성함
input과 output의 차원
- 같을 땐, identity shortcut를 바로 사용
- 다를 땐, 다음 두 가지 방법을 사용
  - zero-padding을 적용하여 차원을 늘림
  - 앞에서 다룬, projection shortcut을 사용 (1 x 1 convolution)

4) Implementation

모델의 구현
- 짧은 쪽이 [256, 480] 사이가 되도록 랜덤하게 resize
- 224 x 224 사이즈로 랜덤하게 crop
- horizontal flip을 부분적으로 적용, per-pixel mean을 제거함
- standard color argmentation 적용
- BN(Batch Normalization), Opitimizer는 SGD를 적용
- learning rate는 0.1에서 시작, 학습정체시에 10으로 나눠줌
- Weight Decay는 0.0001, Momentum은 0.9
테스트 단계
- 10-cross validation 방식을 적용하고, multiple scalue을 적용해, 평균 score를 산출
  - 데이터를 10개의 동일한 크기로 나누어, 훈련하고 테스트하는 과정

4. Experimental

1) ImageNet Classification

plainnet과 resnet을 대상으로 ImageNet을 이용해 수행한 결과를 평가

PlainNet

18-layer가 34-layer의 더 깊은 모델이 높은 validation error가 발생함
- training error도 높아 degradation 문제가 있다고 판단
이러한 문제는 vanishing gradient 때문에 발생하는 게 아니라고 주장
- 해당 모델은 Batch Normalization이 적용되어, forward propagated의 variance 는 0 이나며, backward propagated gradients도 healthy norm을 보임
  - 순전파, 역전파 모두 사라지지 않음
해당 paper의 저자는, exponentially low convergence rate가 training error 감소에 좋지못한 영향을 미쳤다라고 주장
- 지수적으로 낮은 수렴 속도(Exponentially Low Convergence Rate): 알고리즘이 최적의 결과에 도달하는 속도가 매우 느리다는 것을 의미. 특히, 수렴 속도가 지수적으로 느리다는 것은 학습 속도가 매우 느려지고, 결과가 개선되는 속도가 기하급수적으로 떨어진다는 뜻

ResNet

18 layer와, 34 layer ResNet을 plain 모델과 비교
- residual learning으로 34-layer가 18-layer보다 2.8% 가량 더 우수한 성능
  - degradation 문제가 잘 해결되었으며, depth가 증가해도 좋은 accuracy를 더을 수 있음을 의미

34-layer의 top-1 error는 3.5가량 줄었음
- PlainNet보다 더 빠르게 optimization에 수렴 가능

2) Identity vs. Projection Shortcuts

parameter-free한 identity shortcut이 학습에 된다는 것을 알았으며, 이번엔 projection shortcut에 대해 알아봄
다음 3가지 옵션을 비교
- A) zero-padding shortcut을 사용
  - dimention matching에 사용, 완전히 paremeter-free함
- B) projection shortcut을 사용
  - dimention을 키울 때 사용, 다른 모든 shortcut은 identity함
- C) 모든 shortcut으로 projection shortcut한 경우

3가지 option 모두 plainnet보다 좋은 성능을 보임
- 성능의 순위는 A < B < C
3가지 옵션의 성능 차이가 미미하기 떄문에, projection shorcut이 degradation문제를 해결에 필수적이지 않다는 것을 확인 가능
memory / time complexity와 model size를 줄이기 위해서는, C 옵션을 사용하지 않음

3) Deeper Bottleneck Architectures

ImageNet에 대해 모델 학습할 때, training time이 매우 길어질 것 같아서, bottleneck design으로 수정함
- 두 개의 design은 비슷한 time complexity를 가짐

3-layer stack 구조로 바꿈
- 1x1, 3x3, 1x1의 conv로 구성
  - 입력 → 1x1 Conv (채널 수 축소)
  - 3x3 Conv (공간적 특성 학습)
  - 1x1 Conv(채널 수 복구)
parameter-free한 identity shortcut은 bottleneck 구조에서 중요함→ 더 효율적인 모델로 만듦
- 계산의 효율성 : 1x1 Conv를 사용해, 중간 계산을 줄여줌 → 메모리, 연산량을 줄임
- 더 깊은 네트워크 : 성능 저하 없이 깊이는 늘림

3-layer stack 구조로 바꿈
- 1x1, 3x3, 1x1의 conv로 구성
  - 입력 → 1x1 Conv (채널 수 축소)
  - 3x3 Conv (공간적 특성 학습)
  - 1x1 Conv(채널 수 복구)
parameter-free한 identity shortcut은 bottleneck 구조에서 중요함→ 더 효율적인 모델로 만듦
- 계산의 효율성 : 1x1 Conv를 사용해, 중간 계산을 줄여줌 → 메모리, 연산량을 줄임
- 더 깊은 네트워크 : 성능 저하 없이 깊이는 늘림

50-layer ResNet

34-layer의 2-layer block은 3-layer bottleneck block으로 대체해서 구성, B옵션 사용

101-layer and 152-layer ResNet

더 많은 3-layer block을 사용해서 구성함
VGG- 16/19 모델보다 더 낮은 복잡성을 가졌으며, degradation 문제없이 상당히 높은 정확도를 보임

ResNet의 single모델은 이전의 다른 모델의 성능을 능가함, top-5-error를 3.57%를 달성함

4) CIPAR-10 and Analysis

ImageNet 말고도, CIFAR-10의 dataset을 가지고 모델의 학습 및 검증

Exploring Over 1000 layers

1000개 이상의 layer가 사용된 ResNet 모델은 110-layer ResNet보델과 training error가 같았지만, test 결과는 좋지못함
- overfitting 때문인 것으로 판단 → 모델의 복잡도보다 dataset이 적기 때문에

5) Object Detection on PASCAL and MS COCO

PASCAL VOC 2007/2012, COCO 에서도 VGG-16보다 6% 더 좋은 accuracy를 보임
- ILSVRC & COCO 2015 대회에서 1등을 차지

[AI] MobileNets:Efficient Convolutional Neural Networks for Mobile Vision Applications 논문 리뷰

developer-ellen — Sun, 15 Sep 2024 14:30:05 +0900

papers(https://arxiv.org/pdf/1704.04861)

0. Abstract

해당 paper는 mobile과 embedding vision application에서 적용 가능한 efficient한 모델인 MobileNets을 제안
MobileNets은 가벼운 DNN을 만들기 위해 depth-wise seperable convolution을 수행
latency와 accuracy 사이의 trade-off를 조절하기 위해 두 개의 hyperparameter를 제시
여러가지 use-case에서 MobileNet의 효과를 봄

1. Introduction

Alexnet 이후 accuracy는 엄청 높이기 위해 모델이 구조가 더 deep하고 복잡해짐
그러나 모델이 정확도가 좋은 것과 별개로, 모델의 size와 speed 측면의 효율성은 떨어짐
- 그러나, 로보틱스 or AR등의 현실세계인 모바일이나 임베디드의 제한된 computation platform에서 구동될 모델들이 이런 모델로 수행하긴 어려움
해당 paper에서는 hyperparameter 두 개로 모델의 성능(사이즈)을 선택할 수 있는 모델을 제시
- 즉, 해당 모델은 개발자가 직접 제한된 resouce에 맞는 network size의 모델을 사용할 수 있도록 함

2. Prior Work

모델을 경량화 연구는 크게 두 가지
- 큰 사이즈로 Pretrained된 모델의 Network를 압축하는 경우
- 처음부터 소규모 네트워크를 직접 학습하는 경우
모델 사이즈를 줄이는 이전에 많은 모델들
- Inception, Xception
모델을 Compression 하는 기법
- qunatization, pruning, 등등 기법들..
그러나 해당 paper는 이전 연구들고 다르게 제한된 resource에서 latency와 size를 직접 결정할 수 있는 network architecture

3. MobileNet Architecture

MobileNet은 standard convolution을 depthwise convolution와 1x1 convolution(=point wise conovolution)으로 분리(=factorization)하여 연산을 수행함
- 따라서 연산량을 엄청 감소시킴
기존 standard conv의 경우 전체 연산량은 다음과 같음
- Dk는 입력값의 크기(가로, 세로)
- M은 입력의 채널 수
- N는 출력 채널의 수
- Df는 FM의 크기(가로, 세로)

1) Depthwise convolution

Depthwise convolution은 각 입력의 채널마다 채널별 1개의 필터를 적용하는 것
각 input channel에 대해 3x3 conv 하나의 필터가 연산을 수행하여 하나의 Feature Map을 생성함
- 입력 채널 수가 M개면 M개의 FM을 생성
각 채널마다 독립적으로 연산을 수행하여, spatial correlation을 계산
- 예를 들어, 5개 채널의 입력값에, 5개의 3x3 conv가 각 채널에 대해 연산을 수행하고, 5개의 FM을 생성함
다음은 연산량의 식
- Dk는 입력값의 크기
- M은 입력의 채널 수
- Df는 FM의 크기(가로, 세로)

2) Pointwise convolution

depthwise에서 생성한 FM들을 1x1 conv로 output 채널 수를 조정함
- 1x1 conv는 모든 채널에 대해서 연산을 수행하므로, cross-channel correlation을 계산하는 역할
다음은 연산량의 식
- M은 입력 채널 수
- N는 출력 채널 수
- Df는 FM의 크기 (가로, 세로)

3) 전체 연산량

3x3 depthwise separable conv를 하면 기존 standard conv보다 연산량이 8~9배 정도 줄어듦

4. Network Structure and Training

왼쪽은 Strandard Conv의 구조, 오른쪽은 Depthwise seperable Conv의 구조

궁금증 ?
[ 왜 Depthwise Conv 이후에 BN, ReLU가 있나요? ]
- Depthwise Convolution 후에 BN, ReLU가 있는 이유는 각 채널별 필터링 결과에 안정성과 비선형성을 부여하여 더 복잡한 특징을 추출하기 위함
[ 왜 Pointwise Conv 이후에도 BN, ReLU가 있나요? ]
- 채널 간의 상호작용을 한 후에도, 출력이 안정적이면서도 비선형을 유지하여 더 풍부한 특징을 학습하기 위함

MobileNet의 Depthwise 연산으로 충분히 작고 latency를 가지게 되었지만, 특정 task에서 더 빠른 모델이 필요할 수 있음
MobileNet은 모델의 latency와 accuracy를 조절하는 두 개의 hyperarameter가 있음

1) Width Multiplier : Thinner Models

해당 hyperparameter인 α는 model의 두께를 결정
- α는 0에서 1사이, 대체적으로 1, 0.75, 0.5, 0.25 사용(1이 base)
- 여기서 두께란 각 layer에서 filter의 수를 의미함
- α는 입력 채널에 각각 곱해져 전체적인 채널 수를 줄여 parameter와 computation cost을 감소시킴
더 얇은 모델이 필요할 때, 입력 채널 M과 출력 채널 N에 적용하여 αM, αN이 됨
각 α에 맞춰 진행한 실험 결과는 다음과 같음

2) Resolution Multiplier: Reduced Representation

해당 hyperparameter인 ρ는 입력 이미지에 곱하여 전체 모델의 연산량을 감소시킴
- ρ는 입력 이미지에 적용하여, 해상도를 낮춤
- ρ의 범위는 0~1(1이 base)
연산량은 다음과 같으며, 논문에서 이미지 크기가 224, 192, 169, 128 일때를 비교함

3) 두 개의 hyperparameter 적용

5. Experimentals

1) Model Choices

depthwise separable한 경우 일반적인 full conv에 비해 accuracy가 1퍼정도만 줄음

비슷한 연산량과 파라미터를 가진 Shallow MobileNet(depth를 줄임)보다 조절한 0.75 MobileNet(Narrow MobileNet)이 성능 더 나음
- Shallow MobileNet은 중간에 pooling 없이 연산되는 5개의 층을 제외해 경량화 시킨 것

2) Model Shrinking Hyperparameters

accuracy와 computation의 trade-off
- 16 model
  - α = { 1, 0.75, 0.5, 0.25 }
  - ρ = { 224, 192, 160, 128 }
- log linear함( α = 0.25에서 점프..)

다른 유명 모델들과의 비교

3) Fine Grained Recognition

noisy한 web data로 pretrain하고, Strandard Dogs training set으로 model을 fine tune
mobilenet model을 거의 좋은 성능을 달성함(computation, model size 고려해도)

4) Large Scale Geolocalization

5) Face Attributes

6) Object Detection

7) Face Embeddings

[모던 c++의 디자인 패턴] 3장. 팩터리

developer-ellen — Wed, 10 Apr 2024 01:16:00 +0900

팩터리 패턴

팩터리 메서드는 생성할 타입의 멤버 함수로, 객체러르 생성하여 리턴함 -> 생성자를 대신함
패터리는 별도의 클래스로, 목적하는 객체의 생성 방법을 알 수 있음
추상 팩터리는 구현 클래스에서 상속받는 추상 클래스이며, 여러 타입의 팩터리를 생성할 때 사용됨
팩터리는 캐싱과 같은 메모리 최적화 구현이 가능함 -> pooling이나 sigleton pattern

3.2 팩터리 메서드

어떤 객체를 생성할지 이름으로 명확하게 나타낼 수 없는 생성자 대신 객체를 생성해서 리턴하도록 하는 메서드
각각의 팩터리 메서드는 static 함수로 표현

struct Point
{
protected:
	Point(const float x, const float y)
    	: x{x}, y{y} {}
public:
	static Point NewCatesian(float x, float y)
    {
    	return Point{ x, y };
    }
    static Point NewPolar(float r, float theta)
    	return Point{ r*cos(theta), r*sin(theta) };
    }
    
	// 다른 멤버들...
};

auto p = Point::NewPolar(3, 4);

3.3 팩터리

빌더와 마찬가지로 객체를 생성하는 함수들을 별도의 클래스에 몰아넣을 수 있는데, 그러한 클래스를 팩터리라고 부름

struct Point
{
	float x, y;
	friend class PointFactory;
private:
	Point(float x, float y) : x(x), y(y) {}
};


struct PointFactory
{
	static Point NewCatesian(float x, float y)
    {
    	return Point{ x, y };
    }
    static Point NewPolar(float r, float theta)
    	return Point{ r*cos(theta), r*sin(theta) };
    }
};

auto my_pint = PointFactory::NewCatesian(3, 4);

3.4 내부 팩터리

내부 팩터리는 생성할 타입의 내부 클래스로서 존재하는 간단한 팩터리
내부 팩터리의 장점은 생성할 타입의 내부 클래스이기 때문에 private 멤버들에 자동적으로 자유로운 접근 권한을 가진다는 점
내부 팩터리는 팩터리가 생성해야할 클래스가 단 한종류일 때 유용
- 팩터리가 여러 타입을 활용하여 객체를 생성한다면 내부 팩터리 방식은 적합하지 않음

struct Point
{
private:
	Point(float x, float y) : x(x), y(y) {}
};


    struct PointFactory
    {
    private:
        PointFactory() {}

    public:
        static Point NewCatesian(float x, float y)
        {
            return Point{ x, y };
        }
        static Point NewPolar(float r, float theta)
            return Point{ r*cos(theta), r*sin(theta) };
        }
    }

public:
	float x, y;
	static PointFactory Factory;
};

auto pp = Point::Factory.NewCatesian(3, 4);

3.5 추상 팩터리

여러 종류의 연관된 객체들을 생성해야할 경우가 있으며, 이때 사용되는 패턴은 추상 팩터리
다음 예시는 , DrinkFactory라는 추상 팩터리를 두어 사용 가능한 다양한 팩터리들에 대한 참조를 내부에 가짐

//뜨거운 료에 대해 추상화하는 Factory
struct HotFactory
{
	virtual unique_ptr<HotDrink> make() const = 0;
}


struct CoffeeFactory : HotDrinkFactory
{
	unique_ptr<HotDrink> make() const override
    {
    	return make_unique<Coffee>();
    }
}

struct TeaFactory : HotDrinkFactory
{
	unique_ptr<HotDrink> make() const override
    {
    	return make_unique<Tea>();
    }
}


class DrinkFactory 
{
	map<string, unique_ptr<HotDrinkFactory>> hot_factories;
public:
	DrinkFactory()
    {
    	hot_factories["coffee"] = make_unique<CoffeeFactory>();
        hot_factories["tea"] = make_unique<TeaFactory>();
	}
    
    unique_ptr<Hot_Drink> make_drink(const string& name)
    {
    	auto drink = hot_factories[name]->make();
        drink->prepare(200);
        return drink;
    }
 };

3.6 함수형 팩터리

저장된 팩터리를 직접 호출하는 과정을, 함수형 팩터리를 이용해서 생략 가능함

class DrinkWithVolumeFactory
{
	map<string, function<unique_ptr<HotDrink>()>> factories;
public:
	DrinkWithVolumneFactory()
    {
    	// prepare 하는 절차 제체를 팩터리 내에 내장 가능 -> 함수블록으로 쉽게 수정
    	factories["tea"] = [] {
        	auto tea = make_unique<tea>();
            tea->prepare(200);
            return tea;
         };
     }
 };
 
 
 // 저장된 팩터리를 직접 호출하는 과정
 inline unique_ptr<HotDrink>
 DrinkWithVolumeFactory::make_unique<const string& name)
 {
 	return factories[name]();
 }

? 팩터리 패턴과 빌더 패턴의 차이점

목적 : 팩터리 패턴은 객체 생성 인터페이스를 제공하여 클라이언트가 직접 생성하는 것을 방지함, 빌더 패턴은 복잡한 객체의 생성 과정을 추상화하여 단계별로 구성할 수 있도록 함
사용 방법 : 팩터리 패턴은 단순한 객체 생성을 추상화하고 변경 가능성이 낮을 때 사용되며, 빌더 패턴은 복잡한 객체 생성 과정이 단계별로 처리되어야할 때 유용함
구조 : 팩터리 패턴은 인터페이스를 정의하고 이를 통해 구체적인 객체를 생성하는 메서드를 제공하며, 빌더 패턴은 빌더 클래스를 사용하여 객체 생성 과정을 단계적으로 처리함
유연성 : 팩터리 패턴은 유연성이 낮고 변경이 필요한 경우 인터페이스를 수정해야 하지만, 빌더 패턴은 각 단계를 자유롭게 조절할 수 있어 유연성이 높음
적합한 상황 : 팩터리 패턴은 단순한 객체 생성이 필요하고 생성 과정이 자주 변경되지 않을 때, 빌더 패턴은 복잡한 객체 생성이 필요하거나 생성 과정이 자주 변경될 때 적합함

[모던 c++의 디자인 패턴] 2장. 빌더

developer-ellen — Tue, 9 Apr 2024 23:22:31 +0900

빌더

빌더 패턴(Builder pattern)은 생성이 까다로운 객체를 쉽게 처리하기 위한 패턴
빌더 패턴은 단순하게 개별 객체의 생성을 별도의 다른 클래스에게 위임
빌더 하나의 인터페이스가 여러 하위 빌더를 노출할 수 있음
- 상속과 흐름식 인터페이스를 요령있게 활용하면, 여러 빌더를 거치는 객체 생성을 쉽게 할 수 있음

2.2 단순한 빌더

struct HtmlBuilder
{
    HtmlElement root;

    HtmlBuilder(string root_name) { root.name = root_name; }

    void add_child(string child_name, string child_text)
    {
        HtmlElement e{ child_anme, child_text };
        root.elements.emplace_back(e);
    }

    string str() { return root.str(); }
};

HtmlBuilder builder{ "ul" };
builder.add_child("li", "hello");
builder.add_child("li", "world");
cout << builder.str() << endl;

위의 코드를 보면, HtmlBuilder는 HTML 구성 요소의 생성만을 전담하는 클래스
add_child() 메서드는 리턴 값은 사용되는 고싱 없어서, void로 선언되어 있음
- 리턴 값을 활용한다면 좀 더 편리한 흐림식 인터페이스 스타일의 빌더로 만들 수 있음

2.3 흐름식 빌더

흐름식 인터페이스(fluent interface) : 빌더 자기 자신이 참조로서 리턴되기 때문에, 다음과 같은 메서드들이 꼬리를 무는 호출이 가능해짐
다음은 리턴을 참조타입으로 한 경우이다.

HtmlBuilder& add_child(string child_name, string child_text)
{
    HtmlElement e{ child_anme, child_text };
    root.elements.emplace_back(e);
    return *this;
}


...


HtmlBuilder builder{ "ul" };
builder.add_child("li", "hello").add_child("li", "world");
cout << builder.str() << endl;

다음은 리턴을 포인터로 한 경우이다.

HtmlBuilder* add_child(string child_name, string child_text)
{
    HtmlElement e{ child_anme, child_text };
    root.elements.emplace_back(e);
    return this;
}


...


HtmlBuilder* builder{ "ul" };
builder->add_child("li", "hello")->add_child("li", "world");
cout << builder.str() << endl;

2.4 의도 알려주기

사용자가 빌더 클래스를 사용해야한다는 것은 어떻게 알 수 있을까?
한 가지 방법은 빌더를 사용 안하면 객체 생성이 불가능하도록 강제하는 것이다.
- 첫 번째로, 모든 생성자를 숨겨서 사용자가 접근할 수 없게 하는 것이다.
- 두 번쨰로, 생성자를 숨긴 대신 Element class 자체에 팩터리 메서드(static 형태)를 두어 빌더를 생성할 수 있게 한다.

2.6 컴포지트 빌더

객체 하나를 생성하는데 복수의 빌더가 사용되는 경우에 활용됨
개인 신상 정보를 저장하는 프로그램의 예시

class Person
{
	// 주소
    std:: string street_address, post_code, city;
    
    
    // 직업
    std::string company_name, position;
    int annual_income = 0;
    
    Person() {}
 };

빌더를 각 정보마다 따로 두고 싶으면, API는 어떻게 만드는 것이 가장 편리할까?

class PersonBuilderBase
{
protected:
	Person& person;  // 현재 생성되고 있는 객체에 대한 참조
    explicity PersonBuilderBase(Person& person)
    	: person{ person }
    {
    // 자식 클래스에서만 이용 가능
    }
public:
	operator Person()
    {
    	return std::move(person);
    }
    
    // 빌더의 한 측면
    
    // 하위 빌더의 인터페이스를 리턴
    PersonAddressBuilder lives() const;
    PersonJobBuilder works() const;
 };

// 실제 사용자가 사용하는 클래스
class PersonalBuilder : public PersonalBuilderBase
{
	Person p; // 생성중인 객체
public:
	PersonBuilder() : PersonBuilderBase{p} {}
};

// PersonalBuilder는 Person의 주소를 생성하는데 플루언트 인터페이스 스타일을 지원함
class PersonAddressBuilder : public PersonBuilderBase
{
	typedef PersonAddressBuilder self;
public:
	explicit PersonAddressBuilder(Person& p)
    	: PersonBuilderBase{ person } {}
    
    self& at(std::string street_address)
    {
    	person.street_address = street_address;
        return *this;
    }
    
    self& with_postcode(std::string post_code) { ... }
    
    self& in(std::string city) { ... }
 };

// PersonJobBuilder도 같은 방식으로 구현됨

// 사용자가 빌더에 접근하는 방법

Person p = Person::create()   // 빌더를 얻음
	.lives().at("123 London Road")  // PersonAddressBuilder를 얻어, 주소정보 설정
    		.with_postcode("SW1 1GB")
    		.in("London")
    .works().at("PragmaSoft") // PersonalJobBuilder를 얻어, 직업 정보 설정
    		.as_a("Consultant")
            .earning(10e6);

생성된 객체가 이전될 때, std::move()를 사용하기 때문에 이전한 빌더에서는 더 이상 인스턴스를 접근할 수 없음

모던 c++ 디자인 패턴 책을 보면서 공부한 내용을 정리했습니다.

[모던 c++의 디자인 패턴] 1장. SOLID 디자인 원칙

developer-ellen — Mon, 4 Mar 2024 23:31:50 +0900

디자인 패턴

2000년대 초 로버튼 마틴(Robert C. Martin)에 의해 소개됨
SOLID 디자인 패턴은, 우리가 앞으로 살펴볼 디자인 패턴에 전반적으로 녹아져 있음

SOLID 디자인 패턴

1) 단일 책임 원칙(Single Responsibility Principle, SRP)

단일 책임 원칙에서 각 클래스는 단 한 가지의 책임을 부여받아, 수정할 이유가 단 한가지여야 한다.
전지전능한 객체 (여러 기능을 담고 있는)는 SPR를 위배한다.
기록을 위한 메모장 클래스가 있을 때, 이 클래스는 vector에 파라미터로 주어지는 값을 추가하는 함수가 존재한다.
이때, 추가로 영구적인 파일을 저장하는 기능을 만든다고 할 때 디스크에 파일을 쓰는 기능 또한 메모장 클래스의 역할일까?
작은 수정을 여러 클래스에 걸쳐서 해야 하나다면 아키텍처에 뭔가 문제가 있다는 징조이다.

2) 열림-닫힘 원칙 (Open-Closed Principle, OCP)

열림-닫힘 원칙은 타입이 확장에는 열려 있지만, 수정에는 닫혀 있도록 강제하는 것을 뜻한다.
- 따라서, 기존 코드의 수정없이 기능을 확장할 수 있어야 한다.
색상과 크기로 구별되는 상품들이 존재하고, 이를 필터링하는 기능을 만들 때 코드는 다음과 같다.

enum class Color { Red, Green, Blue };
enum class Size { Small, Medium, Large };

struct Product
{
    string name;
    Color color;
    Size size;
}

struct ProductFiler
{
    typedef vector<Product *> Items;
}

ProductFilter::Items ProductFilters::by_color(Items item, Color color)
{
    Item result;
    for (auto &i : items)
        if (i->color == color)
            result.push_back(i);
    return result;
}

만약 색상과 크리를 모두 지정해서 필터링해야 하는 요구 상황이 생긴다면?
- by_color_and_size와 같은 새로운 함수를 또 추가해서 구현할 수도 있다.
- 하지만, 요구사항은 언제든 변경될 가능성이 있어서 기존의 코드 수정없이 필터링을 확장할 수 있는 방법이 필요하다.
  - 필터링 절차를 두 개의 부분으로 나눈다. (필터와 명세)

template <typename T> struct Specification
{
    virtual bool is_saisfied(T* item) = 0;
};

template <typename T> struct Filter
{
    virtual vector<T*> filter (
        vector<T*> items,
        Specification<T>& spec) = 0;
    )
};

struct BetterFilter : Filter<Product>
{
    vector<Product *> filter(
        vector<Product*> items,
        Specification<Product*>& spec) override
    {
        vector<Product *> result;
        for (auto &p : items)
            if (spec.is_saisfied(p))
                result.push_back(p);
        return result;
    }
};

여기서, 크기와 색상을 동시에 피렅링 조건으로 하는 경우는 어떻게 만들 수 있을까?
- 복합 명세를 만들면 된다. 여기서는 C++의 강력한 연산자 오버로딩을 활용해서 훨씬 더 단순하게 구현하겠다.
- && 연산자를 이용하면 두 개 이상의 Specification<T> 객체를 대단히 쉽게 복합 명세로 엮을 수 있다.

template <typename T> struct AndSpecification : Specification<T>
{
    Specification<T>& first;
    Specification<T>& second;

    AndSpecification(Specification<T>& first, Specification<T>& second)
        : first(first), second(second) {}
    
    bool is_satis
};

template<typename T> struct Specification
{
    virtual bool is_satisfied(T* item) = 0;

    AndSpecification<T> operator &&(Specification && other)
    {
        return AndSpecification<T>(*this, other);
    }
};

SizeSpecification large(Size::Large);
ColorSpecification green(Color::Green);
AndSpecification<Product> green_and_large{ large, green };

auto big_green_things = ColorSpecification(Color::Green) && SizeSpecification(Size::Large);
for (auto& x : big_green_things)
    cout << x->name << " is large and green" << endl;

3) 리스코프(Liskov) 치환 원칙(Liskov Subsititution Principle, LSP)

어떤 자식 객체에 접근할 때, 그 부모 객체의 인터페이스에 접근하더라도 아무 문제가 없어야 하는 원칙이다.
예를 들어, 부모 객체인 Rectangle class(사각형)과 자식 객체인 Squre(정사각형)가 있다고 가정한다.
- 사각형내에 넓이를 구하는 함수에서 get_width(), set_width(), get_height(), set_heigh()를 구현했다.
- 그러나 정사각형 내 상속받은 함수인 set_width()와 set_height()는 width나 height를 set하면서, 동시에 height나 width도 동일하게 set하도록 구현했다.
- 여기서, 이 객체를 그 부모인 Rectangle 객체로 접근해서 area(width*height)를 구하면, 의도치 않은 상황이 발생한다.

void process(Rectangle& r)
{
    int w = r.get_width();
    r.set_height(10);
    
    cout << "expected area = " << ( w*10 )
     << ", got " << r.area() << endl;
}


Square{5};
process(s); // 기대된 결과 = 50, 구해진 값 = 25

여기서 해결책은, 애당초 서브 클래스를 만들지 않아야 한다.
서브 클래스를 만드는 대신 아래와 같이 Factory 클래스를 두어 직사각형과 정사각형을 따로따로 생성한다.

struct RectangleFactory
{
    static Rectangle create_rectangle(int w, int h);
    static Rectangle create_squre(int size);
}

4) 인터페이스 분리 원칙(Interface Segregation Principle, ISP)

인터페이스 분리 원칙이 의미하는 바는 필요에 따라 구현할 대상을 선별할 수 있도록 인터페이스를 별개로 두어야 한다는 것이다.
한 덩어리의 복잡한 인터페이스를 목적에 따라 구분하여, 인터페이스 모든 항목에 대한 구현을 강제하지 않고 실제 필요한 인터페이스만 구현할 수 있도록 하는 것이다.
예를 들어, 복합 기능 프린터를 구현할 떄 프린트, 스캔 팩스 기능이 합쳐져 있다.

struct IMachine
{
    virtual void print(vector<Document*> docs) = 0;
    virtual void fax(vector<Document*> docs) = 0;
    virtual void scan(vector<Document*> docs) = 0;
}

여기서, 만약 프린트와 스캔 기능만 가진 프린터를 구현하고 싶을 땐, fax를 빈 함수로 구현해야 한다.

struct IPrinter
{
    virtual void print(vector<Document*> docs) = 0;
}

struct IScanner
{
    virtual void scan(vector<Document*> docs) = 0;
}

struct IMachine : IPrinter, IScanner
{
};

struct Machine : IMachine
{
    IPrinter& printer;
    IScanner& scanner;

    Machine(IPrinter& printer, IScanner& scnaner)
        : printer(printer),
          scanner(scanner)
    {
    }

    void printer(vector<Document*> docs) override {
        printer.print(docs);
    }

    void scan(vector<Document*> docs) override {
        scanner.scan(docs);
    }
};

5) 의존성 역전 원칙(Dependency Inversion Principle, DIP)

상위 모듈이 하위 모듈에 종속성을 가져서는 안된다. 양쪽 모두 추상화에 의존해야 한다.
추상화가 세부 사항에 의존해서는 안된다. 세부 사항이 추상화에 의존해야 한다.
오늘날, 의존성 역전 원칙을 구현하는 가장 인기 있는 방법은 종속성 주입 테크닉을 활용하는 것이다.
- 종속성 주입은 Boost.DI와 같은 라이브러를 사용하면, 어떤 컴포넌트의 종속성 요건이 자동적으로 만족되게 한다는 의미이다.
예를 들어, 자동차는 엔진과 로그 기능을 필요하다. 이때, 두 기능에 자동차가 의존성을 가진다.

#include <iostream>
#include <memory>
#include <string>
using namespace std;

struct Engine
{
    float volume = 5;
    int horse_power = 400;

    friend ostream& operator<< (ostream& os, const Engine& obj)
    {
        return os
            << "volume: " << obj.volume
            << " horse_power: " << obj.horse_power;
    }
};

struct ILogger
{
    virtual ~ILogger() {}
    virtual void Log(const string& s) = 0;
};

struct ConsoleLogger : ILogger {
    ConsoleLogger() {}

    void Log(const string& s) override
    {
        cout << "LOG: " << s << endl;
    }
};

struct Car
{
    unique_ptr<Engine> engine;
    shared_ptr<ILogger> logger;

    Car(unique_ptr<Engine> engine, 
        const shared_ptr<ILogger>& logger)
        : engine{move(engine)},
          logger{logger}
    {
        logger->Log("making a car");
    }

    friend ostream& operator<<(ostream& os, const Car& obj)
    {
        return os << "car with engine: " << *obj.engine;
    }
};

int main() {
    auto engine = make_unique<Engine>();
    auto logger = make_shared<ConsoleLogger>();

    Car car(move(engine), logger);

    cout << car << endl;

    return 0;
}

여기서 "종속성 주입"인 Boost.DI를 이용하면, ILogger를 ConsoleLogger에 연결하는 bind를 정의한다.
- 이 정의는 누구든 ILogger를 요청하면 ConsoleLogger를 전달하라"라는 의미이다.
아래의 코드는 온전히 인스턴스화된 Car객체를 가리키는 shared_ptr<Car>를 만든다.
- 사용할 ILogger 인스턴스의 타입을 바꿀 때, 즉 bind가 수행되는 부분만 수정하면 자동으로 ILogger를 사용하는 모든 곳에서 적용된다는 점이다.
- 이것은 단 한줄만 수정하여 종속성이 있는 객체에 실제 동작하는 구현객체를 사용할 수 있고, 테스트용 더미 객체를 사용하게 바꿀 수도 있다.

auto injector = di::make_injector(
    di::bind(ILogger)().to<ConsoleLogger>()
);

// injection이 설정된 후, 아래와 같이 Car를 생성해서 이용할 수 있다.
auto car = injector.create<shared_ptr<Car>>();

모던 c++ 디자인 패턴 책을 보면서 공부한 내용을 정리했습니다.

BOJ - 단어 수학 1339번 (JAVA)

developer-ellen — Thu, 12 Jan 2023 15:19:30 +0900

❓ 문제 - 백준 단어 수학 1339번 - JAVA 풀이법

출처

(https://www.acmicpc.net/problem/1339)

1339번: 단어 수학

첫째 줄에 단어의 개수 N(1 ≤ N ≤ 10)이 주어진다. 둘째 줄부터 N개의 줄에 단어가 한 줄에 하나씩 주어진다. 단어는 알파벳 대문자로만 이루어져있다. 모든 단어에 포함되어 있는 알파벳은 최대

www.acmicpc.net

문제해결법

1. 문제

알파벳 대문자를 0~9의 숫자로 치환할 때, 모든 알파벳을 더한 값이 최대값이 되도록 각 알파벳에 할당될 숫자를 정해야한다.
따라서 선정된 알파벳 숫자에 의해 더한 값의 최대값을 정답으로 출력한다.

2. 해결 방법

그리디 알고리즘의 방법으로 문제를 접근한다.
각 알파벳은 각각의 자릿수가 있으므로 주어진 알파벳 인덱스에 해당하는 곳에 자릿수를 계속 더한다.

예를 들어, ABC 라고 할 때
A는 alpha 인덱스에 0번이고 alpha[0]에는 100이 더해져 있다.
B는 alpha 인덱스에 1번이고 alpha[1]에는 10이 더해져 있다.
C는 alpha 인덱스에 2번이고 alpha[2]에는 1이 더해져 있다.

다음 AB를 입력받는다면,
alpha[0] += 10
alpha[1] += 1

이 더해진 상태로 되어 있을 것이다.

위와 같은 상태로 alpha를 계속 더한 후에, alpha를 정렬해주고 값이 가장 큰 값부터 숫자 9 부터 할당해준다.
따라서 숫자를 할당해준 후, 각 자릿수에 있는 숫자 x 자릿수 값 x 할당된 값을 answer에 계속 더해가면 답을 구할 수 있게된다.

3. 느낀점

처음에 리스트랑, 해쉬를 사용해서 구현이 복잡하도록 풀이를 생각했는데.. 이건 도저히 아닌 것 같아서 다른 사람들의 풀이를 봤다. 그리디 알고리즘 답게 심플한 풀이법을 잡아서 해결해야했다...
그리디 문제들을 많이 풀면서 해결방법의 센스를 좀 높이도록 노력해야지..!

소스코드 (JAVA)

import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.util.Arrays;


public class Main_1339 {
    public static void main(String[] args) throws Exception {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        int n = Integer.parseInt(br.readLine());

        long[] alpha = new long[26];
        for(int i=0;i<n;i++){
            String str = br.readLine();
            for(int j=0;j<str.length();j++){
                alpha[str.charAt(j) - 'A'] += Math.pow(10, str.length()-j-1);
            }
        }

        Arrays.sort(alpha);
        int num = 9;
        long answer = 0;
        for(int i=25;i>=0;i--){
            if(alpha[i] == 0) continue;
            String s = String.valueOf(alpha[i]);
            char[] c = s.toCharArray();
            for(int j=0;j<c.length;j++){
                if(c[j] == '0') continue;
                answer += (c[j]-'0') * num * Math.pow(10, c.length-j-1);
            }
            num--;
        }

        System.out.println(answer);


    }
}

SSAFY 7기, 최고의 순간들

developer-ellen — Mon, 26 Dec 2022 14:49:15 +0900

SSAFY 7기 수료와 최고의 순간들

SSAFY 7기 전체 후기와 내용 정리는 다른 글로 자세히 적을 예정이며,

이것은 좋았던 순간들을 티저 형식으로 미리 정리하는 글이다..!

누구에겐 SSAFY는 SW 개발자로 역량을 쌓을 수 있는 순간, 취업으로 위한 하나의 과정이었을지 모르겠다.

하지만 나에겐 SSAFY 7기 과정은

다시는 받을 수 없는 황금같은 선물이었고, 인생 최고의 기간이라고 생각한다.

가끔 일생에 운들을 2022년도에 몰빵으로 쓴 게 아닐까?라고 자주 생각했다. ㅋㅋㅋ

일단 SSAFY 1년동안 BEST 3의 순간을 떠올린다면 다음 순간이 아닐까 ?

~~(근데 선택.. 너무 어려웠고 싸피 과정 다 너무 좋았다.. )~~

1. 2학기 첫 프로젝트인, 공통프로젝트 직전에 수행한

팀 친화 프로그램 !

2학기 온오프로 병행하면서 처음으로 SSAFY 광주캠퍼스를 다녔고

이 날은 오프라인 병행 첫 주, 화요일이었다!

이거 팀 친화 프로그램 이름이 굉장히 감성적이었는데 ㅋㅋㅋㅋ

그 때 이름 보고 팀원들끼리 같이 경악을 했는데 막상 해보니 너무 좋은 시간이었다!

팀 친화 프로그램으로, 팀원들이 가지고 있는 성향을 MBTI가 아닌 일하는 성향을 파악하고

이것에 대해 토론하면서 서로를 알아가는 시간을 가졌다!

그리고 사진들은 여러 프로그램을 하면서, 팀 사진을 찍어야 하는 게 있었는데 그 때 찍은 거다ㅋㅋㅋㅋ

이땐 존댓말로 주고 받고, 굉장히 어색한 사이였는데 ㅋㅋㅋㅋㅋ

지금은 이 팀원들이 한 가족이 되었다!

이 후에도 우리 담당 교육프로님께서

굉장히 철학적이면서? 재밌는 질문을 오고가면서

팀끼리 재밌게 미팅할 수 있는 시간을 열어주셨는데

그 때도 서로를 알 수 있고 정말 기억 남는 좋은 순간인데...

사진은 없다....ㅠ

하지만 그 순간의 스냅샷은 내 머리 속에 있으니깐 괜찮지~!

프로젝트를 처음 시작해서

필요한 기술들을 하나 하나 배우면서 적용하는 게 너무 재밌었고..

진짜 노력하면 아웃풋으로 바로바로 보여서 더 열심히 프로젝트에 참여했던 것 같다!

실제 프로젝트 하면서 팀원들이 다 같이 욕심이 많이 생겨서

거의 밤샘도 밥먹듯이 하고 ㅋㅋㅋㅋ

#오운완이라는 운동 프로젝트를 해서

밤새 코딩하면서 테스트하기 위해 운동도 하느라 많이 힘들었다.

하지만 6명 모두 같이 밤새며 코딩하고, 운동하느라 그냥 매순간이 재밌었다.

덕분에 공통 프로젝트 2등이라는 좋은 결과도 얻을 수 있었다.

근데 마지막 주엔,, 진짜 운이 좋았던 게 이미지 처리 관련해서

기술 변경하다가 자꾸 안되서 다음날 발표였는데 기능 자체가 아예 안돌아가서

진짜 고생을 많이 했다 ㅠㅠㅠㅠ

하지만 지은이가 초반을 잘 잡아주고 내가 밤 12시쯤에

갑자기 폭풍 코딩으로 문제 해결해서

라이브 시연, 발표까지 잘 끝낼 수 있었다...ㅠㅠㅠㅠㅠ

내가 했던 모든 프로젝트는 소중하고 사랑하지만

#오운완은 제일 많이 아낀 프로젝트 같다.. !

그리고 상을 받은 순간도 너무 좋았지만..

교육장에서 다른 교육생들이 우리 오운완을 너무 재밌어 하면서 테스트 했을 때

정말 뿌듯했다 ㅋㅋㅋㅋㅋ

우리가 쫌 잘 만들긴 한 듯 ~~

2. 싸피 들어오기 전부터 굉장히 하고 싶었던

SSDC 삼성전자 연계 프로젝트 !

SSAFY 7기 우수 교육생들을 선발해서 진행했던

삼성전자 SSDC 연계 프로젝트!

사실,, 싸피에 들어오기 전부터 오픈소스에 관심이 많았고

유튜브 영상에서 SOSCON 영상을 보다가 SSAFY가 삼성의 오픈소스에 참여하여 발표하는 것들을 봤다..

그 영상들을 보면서 싸피에 합격하기 전이지만 나도 꼭 이런 활동해보고 싶다!!!! 라고 꿈을 가진채 싸피에 도전하게 되었다.

합격 후 신청할 기회에서 내가 왜 SSDC가 필요한지, 그리고 내가 얼마나 SSDC를 잘 수행할 역량과 경험을 가졌는지 잘 어필했고..!!! 나의 간절함들을 좋게 봐주셔서 운이 좋게 선발되었다.

선발된 순간부터 SSDC 프로젝트 기간은 정말 좋은 지원들을 받으면서 다양한 경험을 많이 할 수 있었다.

덕분에 SSAFY 다른 지역 캠퍼스의 교육생들과 프로젝트도 진행도 해보고,

삼성리서치 멘토님께 기술적인 조언도 많이 받았다.

그리고, 필요할 때는 숙박, 교통비 지원도 다 해주셔서

서울 캠퍼스에서 1박 2일, 2박 3일 지내면서 퀄리티 있는 프로젝트에 집중할 수 있도록 도와주셨다..!

그리고 우수 교육생들인, 좋은 팀원들을 만나

서로 다같이 열심히 해서 SSDC 1등을 할 수 있었고, 우리 팀 프로젝트가

실제 SSDC 삼성의 컨퍼런스 발표 기회까지 얻을 수 있었다..!

그리고 SSDC 프로젝트를 하면서 SSAFY 최초로 수원사업장을 방문하게 되었다!

저기서 맛있는 삼성의 밥도 먹고.. 커피를 마시며 센트럴 파크..?를 돌며

수원사업장 투어를 하였다..

저기 안에.. 헬스장, 수영장, 병원,,, 등등 없는 게 없다..

아 찾았다.

나만 없을 듯?ㅋㅋ

그리고 삼성리서치 투어도 하며 즐겁게 프로젝트 하고

1등을 !! 이름 불려진 순간이 아직도 기억에 남는다!!!!!!

SSDC를 수행하며 Z플립도 받고 1등으로 버즈 프로2와 상금도 ㅎㅎ

3. SSAFY의 최고점인, 자율프로젝트 !

사랑하는 93%(프로) 우리팀 ~~~

7기, 그리고 7팀으로 100%(프로)로 되자며

정말 많이 고생했다.

3개의 프로젝트 중에, 제일 마음적으로 고생많이 했지만

덕분에 버틸 수 있었다!

함께 해서 영광이었어 ㅎㅎ

열심히 코딩하는 컨셉샷 하나 올리구~~

가장 감동의 순간..

배포 관련해서 이슈 생기니

세 분의 코치님께서 달려와주셔서 봐주시고,,,ㅠㅠㅠ

든든한 코치님들 덕분에

프로젝트 위기의 순간들을 잘 넘길 수 있었던 것 같다..

정말 감사합니다 ㅠㅠㅠ

그리고 SSAFY 행사날!

서울캠퍼스에서 라이브 생중계 해주고

우리는 강당에서 같이 즐겨봤다.

재미는.... 큼큼..

그래도 팀원들과 같이 강당에 앉아 도란도란 얘기도 나누며 시청할 수 있어서 재밌었다 ㅎㅎ

그리고 과열된 프로젝트 기간에 리프레쉬를 줄 수 있는 시간이어서 지금 생각해보면 좋았던 것 같다..!

갑자기 교육이 오프라인으로 바뀌고, 반도 바뀌고

정신도 많이 없었지만

오히려 오프라인 교육만의 장점인

팀원들간에 더 친밀감 쌓으면서 프로젝트 매진할 수 있었던 것 같다...!

그리고... 회장님의 방문.. 셀카,,, 사진 기회,,,

삼성 직원이어도 회장님을 뵙기 어렵다는데..!

싸피 활동중에 제일 못 잊을 순간이지 않을까?ㅎㅎㅎ (아마 인생 전체로 봐도...그럴듯..ㅎ)

GPS 기반 프로젝트를 하다보니 실데이터 쌓기 위해

렌트카 빌려서.. 테스트한 날이다!

근데 중간에 이슈가 생겨서 차 멈추고 이슈체킹,,,

길바닥에서 코딩하는 모습도 정말 잊을 수 없는 순간 같다!!!!!

미라클 모닝도 매일 하고, 자율 프로젝트 마지막쯤에

밤샘도 너무 많이 하고 잠을 못 자다보니 중간중간..

드르렁 타임이 있었다..

원래.. 이렇게 아무곳에서나 쉽게 자는 사람 아닌데.. 역시 침대같은 포근함이 있는 광주 캠퍼스 최고...

자율프로젝트 발표까지 잘 마무리 하고..!

프로젝트 마지막 회고 ㅎㅎ

처음 프로젝트부터 매일 스크럼 회의,각 주마다 스프린트 회고를 진행하며

내가 뭘 잘했고, 뭘 잘못했고 거기서 뭘 배웠는지 얘기를 나눴다.

이런 시간들을 가질 수 있다는 게 SSAFY 프로젝트의 큰 장점 아닐까?ㅎㅎ

그리고 마지막 폴라로이드 샷!

교육장 또 가고 싶다 ㅠㅠㅠ

광주 캠퍼스의 트리는 11월쯤 설치해주시는데

덕분에 코딩하면서 분위기 전환도 되고 너무 좋았다..!

그리고 수료식 사진 촬영!

머리, 메이크업도 해주시고

SSAFY를 잘 마무리 할 수 있는 시간이었다..

이 땐.. 몰랐다 ㅠ

이게 나의 마지막 교육장 방문이라는 것을..

수료식에는 회사 OT 참석 때문에 못 했는데 ㅠㅠㅠ

이게 너무너무 아쉽다...ㅠㅠㅠㅠ

SSAFY를 하면 어떤 걸 제일 얻을 수 있나요? 라는 질문에

여러 개가 떠오르지만

같이의 가치를 얻을 수 있습니다!

라고 대답할 것 같다.

SSAFY에서 만난 소중한 나의 인연들 덕분에

다신 없을 인생의 황금같은 시간들을

잘 선물 받았습니다 ㅎㅎ

덕분에 얻었던 행복, 성장, 자신감들을 소중히 가지고

인생의 또 다른 챕터로 잘 넘어갈 것 같습니다!

SSAFY 진짜 안녕!

BOJ - 수들의 합4 2015번 (JAVA)

developer-ellen — Wed, 7 Dec 2022 20:42:32 +0900

❓ 문제 - 백준 수들의 합4 2015번 - JAVA 풀이법

출처

(https://www.acmicpc.net/problem/2015)

2015번: 수들의 합 4

첫째 줄에 정수 N과 K가 주어진다. (1 ≤ N ≤ 200,000, |K| ≤ 2,000,000,000) N과 K 사이에는 빈칸이 하나 있다. 둘째 줄에는 배열 A를 이루는 N개의 정수가 빈 칸을 사이에 두고 A[1], A[2], ..., A[N]의 순서로

www.acmicpc.net

문제해결법

1. 문제

A[1], A[2], A[3], A[4]. ... A[N]의 N개의 정수가 있을 때 i~j 구간의 부분합이 K인것이 몇 개인지 구하시오.

2. 해결 방법

일단 누적합 + 각 구간 합의 숫자를 카운팅한 HashMap 이용으로 문제를 해결해야한다.
만약 다음과 같은 경우로 답을 구한다면 시간 복잡도 O(N^2)로 시간초과가 발생한다.

4 0
2 -2 2 -2

========
누적합(0~4)

0 2 0 2 -2

=======
누적합에서 K(0)과 같아지는 경우는 우선 1개(1~3 누적)이다.

그리고 예를 들어 누적 1~4 구간에서 부분 합이 다시 K(0)과 같아지는 경우를 구하려면
구간 1~4, 1~3, 1~2, 2~4, 2~3, 3~4 를 다 살펴야 하며 이것은 시간복잡도 O(N(N+1)/2) 즉 O(N^2)을 야기한다.

위에 지금까지 누적합 구간안에 부분 합을 다시 살피려면, 현재까지 구간합 - (현재까지 구간 합 사이에 부분합) = K인 경우를 살피면 된다.
따라서 구간 합에 대한 카운팅 정보를 hashMap에 넣어서 관리한다. 현재까지 구간합 - k의 숫자를 key로 hashMap에서 value를 찾아 answer에 더해준다.

3. 느낀점

누적합이라는 아이디어로 문제를 바라봤는데.. 수학적인 공식에서 오는 풀이가 큰 문제인것 같다...

소스코드 (JAVA)

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.HashMap;
import java.util.StringTokenizer;

public class Main_2015 {
    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine(), " ");
        int n = Integer.parseInt(st.nextToken());
        int m = Integer.parseInt(st.nextToken());
        int[] sum = new int[n+1];
        HashMap<Integer, Integer> hash = new HashMap<>();
        st = new StringTokenizer(br.readLine(), " ");
        long answer = 0;
        for(int i=1;i<n+1;i++){
            int num = Integer.parseInt(st.nextToken());
            sum[i] = num + sum[i-1];
            if(sum[i] == m) answer++;
            answer += hash.getOrDefault(sum[i]-m, 0);
            hash.put(sum[i], hash.getOrDefault(sum[i], 0)+1);
        }

        System.out.println(answer);

    }
}

BOJ - 거짓말 1043번 (JAVA)

developer-ellen — Tue, 6 Dec 2022 23:46:38 +0900

❓ 문제 - 백준 거짓말 1043번 - JAVA 풀이법

출처

(https://www.acmicpc.net/problem/1043)

1043번: 거짓말

지민이는 파티에 가서 이야기 하는 것을 좋아한다. 파티에 갈 때마다, 지민이는 지민이가 가장 좋아하는 이야기를 한다. 지민이는 그 이야기를 말할 때, 있는 그대로 진실로 말하거나 엄청나게

www.acmicpc.net

문제해결법

1. 문제

지민이가 파티장에 가서 거짓을 얘기하거나 진실을 얘기하게 된다.
그러나 어떤 사람들은 지민이가 거짓말을 얘기하는지 알게 된다. 그리고 그 지민이가 거짓말을 얘기하는지, 진실을 얘기하는지 아는 사람들과 같이 파티장에 있는 사람들도 이런 거짓말을 하게 되는지 알게된다.
따라서 다른 파티장에서는 거짓말을 한 것을 모르지만, 다른 파티에서는 거짓말을 하는지 알고 있는 파티원과 같이 있으면 모순을 느끼며 거짓말 쟁이로 판단된다.
이렇게 모순을 피해 지민이가 거짓말 쟁이가 안되며 최대한 거짓말을 할 수 있는 파티장의 갯수를 구하여라.

2. 해결 방법

union find(합집합) 알고리즘을 사용하여 문제를 해결한다.
우선, 진실인지 거짓인지 아는 파티원들을 boolean true로 관리하며, 각 파티장에 참석한 사람에 대한 정보를 HashSet으로 저장한다.
그리고 각 파티장에 대한 정보를 받을 때 각 멤버들을 union find로 해서 같은 집합으로 만든다.
그리고 다시 한번, 진실인지 거짓인지 아는 파티원을 기준으로 자신과 같은 집합인 경우인 사람들은 다 진실과 거짓을 판별할 수 있게 되므로 boolean을 true로 변경해준다.
그리고 다시 한번, 각 파티장마다 혹시 진실을 아는 사람이 존재한다면 스킵하고 각 파티장에 진실을 아는 사람이 아무도 없을 때 answer 1증가시켜주고, answer를 답으로 출력한다.

3. 느낀점

처음에 union find말고 boolean으로 체킹하면서 비슷하게 로직을 구현했는데, 예제 인풋 아웃풋은 맞았지만.. 틀렸다.. 알고 보니 union find의 합집합으로 진실을 아는 사람 + 진실을 알게 될 사람을 묶고 나중에 다시 한번 더 진실을 알게되는 사람들의 연관관계를 다시 계산해줘야했다.
union find가 이런 식으로 풀이에 적용될 수 있구나 느꼈다..!

소스코드 (JAVA)

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.HashSet;
import java.util.StringTokenizer;

public class Main_1043 {
    public static int[] parent;
    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine(), " ");
        int n = Integer.parseInt(st.nextToken());
        int m = Integer.parseInt(st.nextToken());
        boolean[] know = new boolean[n+1];
        HashSet<Integer>[] party = new HashSet[m+1];
        parent = new int[n+1];
        for(int i=1;i<=m;i++){
            party[i] = new HashSet<>();
        }
        st = new StringTokenizer(br.readLine(), " ");
        int know_cnt = Integer.parseInt(st.nextToken());
        for(int i=1;i<=know_cnt;i++){
            int tmp = Integer.parseInt(st.nextToken());
            know[tmp] = true;
        }

        for(int i=1;i<=n;i++){
            parent[i] = i;
        }

        // 진실을 아는 사람과 같은 파티 공간에 있으면 진실을 아는 것으로 체크
        for(int i=1;i<=m;i++){
            st = new StringTokenizer(br.readLine(), " ");
            int num = Integer.parseInt(st.nextToken());
            if(num <= 0) continue;
            int pre = Integer.parseInt(st.nextToken());
            party[i].add(pre);
            for(int j=0;j<num-1;j++){
                int p = Integer.parseInt(st.nextToken());
                if(find_parent(pre) != find_parent(p)){
                    union(pre, p);
                }

                party[i].add(p);
                pre = p;
            }
        }

        // 진실을 아는 사람과 연관관계가 있음
        boolean[] check = new boolean[n+1];
        for(int i=1;i<=n;i++){
            if(know[i] && !check[i]){
                int p = find_parent(i);
                for(int j=1;j<=n;j++){
                    if(find_parent(j) == p){
                        know[j] = true;
                        check[j] = true;
                    }
                }
            }
        }

        int answer = 0;
        for(int i=1;i<=m;i++){
            boolean c = false;
            for(int p:party[i]){
                if(know[p]){
                    c = true;
                    break;
                }
            }
            if(!c) answer++;
        }

        System.out.println(answer);
    }

    public static int find_parent(int x){
        if(parent[x] == x) return x;
        return parent[x] = find_parent(parent[x]);
    }

    public static void union(int a, int b){
        a = find_parent(a);
        b = find_parent(b);
        if(a <= b){
            parent[b] = a;
        } else {
            parent[a] = b;
        }
    }


}