| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 |
- 백준
- 컴퓨터 비전
- 브루트포스
- 이분탐색
- dp
- 최적화
- 2018 KAKAO BLIND RECRUITMENT
- java
- 구현
- dfs
- 누적합
- 임베디드
- 프로그래머스
- level3
- lv2
- c++
- 다이나믹프로그래밍
- kotlin
- 동적계획법
- 컴퓨터비전
- JavaScript
- 우선순위큐
- C
- level2
- 자바
- cpp
- BFS
- 그리디
- 코틀린
- 다이나믹 프로그래밍
- Today
- Total
목록전체 글 (166)
코드를 느껴바라
문제링크성공 여부(걸린 시간): 실패 (44분 24초)시간 내에는 풀지 못했고, 이후 풀이를 다시 정리하면서 해결했다.아이디어처음 문제를 봤을 때 조건을 잘못 읽었다.m * n 그래서 처음부터 어떻게 접근해야 할지 감을 못 잡았고, 제한을 다시 확인하고 나서야 2차원 배열을 사용해도 된다는 것을 알았다.처음 생각한 방법은 각 빗방울이 떨어질 때마다 해당 빗방울의 영향을 받을 수 있는 영역을 모두 표시하는 방식이었다.각 칸에 가장 먼저 영향을 주는 빗방울의 순번을 저장해두고, 가능한 모든 h * w 영역을 확인하여 가장 늦게 비를 맞는 위치를 찾으려고 했다.그런데 생각해보니 굳이 빗방울 하나를 기준으로 여러 영역에 정보를 퍼뜨릴 필요가 없었다.각 칸에 그 칸에 빗방울이 떨어지는 순번만 저장하면 된다.예를 ..
문제 링크성공 여부(걸린 시간) : 성공 ( 1시간 57분 )아이디어각 파이프에는 1번, 2번, 3번 중 하나의 종류가 지정되어 있다.한 번의 동작에서는 세 종류 중 하나를 선택해 해당 종류의 파이프를 열 수 있으며, 총 K번 파이프를 열었을 때 감염시킬 수 있는 배양체의 최대 개수를 구해야 한다.핵심은 다음 두 단계로 나눌 수 있다.K번 동안 열 파이프의 종류를 모두 생성한다.생성한 순서대로 감염을 시뮬레이션한다.1. 파이프를 여는 순서 완전 탐색한 번의 동작마다 선택할 수 있는 파이프 종류는 세 가지다.1번 파이프2번 파이프3번 파이프따라서 K번 동안 파이프를 여는 모든 경우의 수는 다음과 같다.3^K예를 들어 K = 2라면 가능한 순서는 다음과 같다.1 11 21 32 12 22 33 13 23 3..
문제 링크성공 여부(걸린 시간): 성공 (21분 48초)아이디어던전의 개수가 최대 8개이므로, 가능한 모든 던전 방문 순서를 DFS로 탐색해도 충분하다고 판단했습니다.먼저 던전을 최소 필요 피로도 기준으로 오름차순 정렬했습니다. 최소 필요 피로도가 같다면 소모 피로도가 적은 던전이 앞에 오도록 정렬했습니다. 정렬했기 때문에 DFS 탐색 중 현재 피로도로 특정 던전에 입장할 수 없다면, 이후 던전에도 입장할 수 없으므로 해당 분기의 반복을 종료할 수 있습니다.DFS는 다음 세 가지 상태를 관리합니다.depth: 현재까지 탐험한 던전 수tired: 현재 남아 있는 피로도visited: 방문한 던전을 기록하는 비트마스크각 DFS 호출에서는 먼저 depth를 이용해 최대 탐험 던전 수를 갱신합니다. 이후 모든 ..
부트로더란 무엇인가?이번에 OTA 프로젝트를 진행하면서 커스텀 부트로더를 직접 다뤄볼 일이 있었다.프로젝트에서는 커스텀 부트로더를 PFLASH 영역에 저장해두고, 부팅 시 가장 먼저 부트로더가 실행되도록 구성했다.부트로더는 업데이트할 펌웨어가 있는지 확인한 뒤, 업데이트가 필요한 경우에는 새 이미지를 반영하고, 업데이트할 사항이 없다면 기존 실행 파일(Application)로 점프하도록 동작했다.이 과정에서 부트로더가 정확히 어떤 역할을 하는지, 왜 필요한지, 그리고 OTA와 어떤 관계가 있는지 공부하게 되었고, 그 내용을 정리해보려고 한다.부트로더란?부트로더(Bootloader)는 시스템에 전원이 인가되거나 CPU가 리셋되었을 때 가장 먼저 실행되는 프로그램이다.일반적으로 CPU는 리셋 이후 정해진 시..
문제 링크성공 여부(걸린 시간): 성공(20분)아이디어해당 문제는 단순 중첩 반복문으로 풀면 안되는 문제이다.왜냐면 Follow-up: Can you come up with an algorithm that is less than O(n^2)time complexity?라고 대놓고 적어 놓았기 때문이다. 그래서 처음에는 투포인터로 풀어야겠다. 생각을 했지만 문제에서 요구하는 것은 처음 주어지는 nums 벡터에서의 해당 값들의 원래 인덱스이다. 그렇기 때문에 어차피 map을 사용해서 순서를 저장해둬야 하니 이보다 간단하게 map하나만 사용해서 푸는 방법으로 고쳤다. map_num으로 기존 인덱스를 저장하며 값을 저장해준다.단 그 전에 target값에서 해당 num값을 뺀 값이 map에 존재한다면?이 둘의..
https://github.com/sernan96 sernan96 - Overviewsernan96 has 12 repositories available. Follow their code on GitHub.github.com프로젝트 및 개인 작업물이 궁금하신 분들 구경하세요~
문제 링크성공 여부(걸린 시간): 성공 (약 3시간 30분)아이디어이 문제는 BFS 자체보다“턴마다 상태를 갱신하는 빡 구현 시뮬레이션 문제”이다.핵심은 매 턴마다 아래 흐름을 정확하게 반복하는 것이다.1. 공격자 선정2. 공격 대상 선정3. 레이저 공격 시도 (BFS) → 실패 시 포탄 공격4. 공격 결과 반영 + 포탑 정비이 구조만 정확하게 잡으면 구현은 크게 어렵지 않다.오히려 예외 처리에서 대부분 틀린다.공격자 / 피해자 선정이 문제에서 첫 번째 핵심은 정렬 기준 구현이다.단순히 “가장 약한 / 강한”이 아니라여러 조건이 동시에 걸려 있기 때문에PriorityQueue로 정렬 기준을 그대로 코드로 옮겼다.공격자 선정가장 약한 포탑을 선택한다.우선순위는 다음과 같다.공격력 낮은 순최근에 공격한 ..
차량 내부에는 CAN, LIN, Ethernet, FlexRay, SPI 등 다양한 통신 방식이 혼재되어 있습니다. 겉보기엔 그저 데이터를 주고받는 '통신' 같지만, 하드웨어 레벨로 내려가면 이들의 내부 동작 방식은 완전히 다릅니다. AUTOSAR(오토사)의 핵심 철학은 이러한 통신 방식의 물리적 차이를 없애는 것이 아닙니다. 철저한 계층(Layer) 구조를 통해 아래의 복잡한 하드웨어 차이를 흡수하고, "상위 애플리케이션에서는 하드웨어를 몰라도 되게" 만드는 것입니다. 전체적인 구조를 파악하기 위해, 가장 아래에 있는 하드웨어 계층부터 위로 올라가며(Bottom-up) 각 계층의 역할과 흐름을 정리해 보겠습니다.1. MCAL (Microcontroller Abstraction Layer)한 줄 요약: ..
RTOS를 공부하다 보면 가장 먼저 듣는 말 중 하나가 "우선순위가 높은 태스크가 먼저 실행된다"는 것이다. 중요한 작업에는 높은 우선순위를 주고, 덜 중요한 작업에는 낮은 우선순위를 주면 되니 얼핏 보면 단순해 보인다. 하지만 실제 시스템에서는 이 원칙이 그대로 지켜지지 않는 경우가 있다. 바로 우선순위 역전(Priority Inversion) 현상이다.처음 이름만 들으면 단순히 낮은 우선순위 태스크가 높은 우선순위 태스크보다 먼저 실행되는 현상처럼 느껴질 수 있다. 하지만 실제로는 더 복잡하고 위험하다. 원래 가장 먼저 실행되어야 하는 높은 우선순위 태스크가 오히려 낮은 우선순위 태스크 때문에 기다리게 되는 상황이 발생하는 것이다. 이 현상은 단순한 지연 문제가 아니라, 실시간성이 중요한 시스템에서는..
오늘은 자동차 소프트웨어 구조를 공부하다가 AUTOSAR(AUTomotive Open System ARchitecture)라는 개념을 접하게 되었다. 처음에는 단순히 자동차용 소프트웨어 표준 정도로 생각했지만, 구조를 하나씩 살펴보다 보니 오히려 "왜 이런 구조가 필요해졌을까?"라는 배경이 더 궁금해졌다. 과거 자동차는 ECU(Electronic Control Unit) 단위로 기능이 나뉘어 있었고, 각 ECU는 특정 기능을 수행하는 독립적인 시스템처럼 동작했다. 문제는 ECU마다 사용하는 하드웨어, 운영체제, 통신 방식이 제각각이었다는 점이다. 예를 들어 엔진 제어 ECU, 브레이크 ECU, 센서 ECU가 서로 다른 벤더에서 개발되면 코드 구조도 다르고, 인터페이스도 다르고, 같은 기능을 구현하더라도 ..