Skip to main content

Command Palette

Search for a command to run...

[LeetCode] 3233. Find the Count of Numbers Which Are Not Special

Updated
2 min read

문제 정의

Link : 3233. Find the Count of Numbers Which Are Not Special

You are given 2 positive integers l and r. For any number x, all positive divisors of x except x are called the proper divisors of x.

A number is called special if it has exactly 2 proper divisors. For example:

  • The number 4 is special because it has proper divisors 1 and 2.

  • The number 6 is not special because it has proper divisors 1, 2, and 3.

Return the count of numbers in the range [l, r] that are not special.

문제 분석

내가 이해한 문제 요약

[l,r] 범위의 수 x에 대해서 x를 제외한 2개의 수로 나누었을 때 나머지가 없는 경우를 special 하다라고 한다.

l, r 이 주어질 때 not special 한 수의 개수를 반환해라

문제를 이해해볼 때 간단한 예시는 다음과 같습니다

4일 경우, (1, 2) → special

5일 경우, (1) → not special

6일 경우, (1, 2, 3) → not special

7일 경우, (1) → not special

8일 경우, (1, 2, 4) → not special

9일 경우, (1, 3) → special

패턴 : 소수의 제곱은 special 하다

해결 방안

import kotlin.math.sqrt

class Solution {
    fun nonSpecialCount(l: Int, r: Int): Int {
        val sqrt = sqrt(r.toDouble()).toInt()
        val isPrime = BooleanArray(sqrt + 1) { true }
        isPrime[0] = false
        isPrime[1] = false

        for (i in 2..sqrt) {
            if (isPrime[i]) {
                for (j in i * 2..sqrt step i) {
                    isPrime[j] = false
                }
            }
        }

        var specialCount = 0
        for (i in 2..sqrt) {
            if (isPrime[i]) {
                val square = i * i
                if (square in l..r) {
                    specialCount++
                }
            }
        }

        return (r - l + 1) - specialCount
    }
}

문제 분석을 바탕으로 소수의 제곱이 스페셜하다라는 것을 알아냈으니 우리는 스페셜하지 않는다는 것을 다음과 같은 flow로 찾아낼 것입니다

  1. 에라토네스체를 이용한 소수 찾기

  2. 찾은 소수가 [l, r] 사이에 있다면, cnt +1

  3. r하위에 포함되는 모든 케이스를 확인할 때까지 2 반복

  4. [l, r] 개수 - 스페셜한 cnt 값 반환

느낀점

솔직히 이번 문제는 너무 어렵고 시간 제한도 빡세게 되어 있어서 도저히 다른 케이스로는 풀 수 가 없었습니다.

또한 ‘소수의 제곱만 스페셜하다’라는 명제를 항상 만족하는지 여전히 확인 및 이해하지 못해서 그냥 공식을 가져다 쓰기만 했던 것 같아서 조금 찝찝한 느낌도 있었고 실제 코딩 테스트에 나온다면 사실 틀릴 수 밖에 없다고 생각이 듭니다

3 views

More from this blog

카프카 입문 시리즈 2편: 토픽, 파티션, 오프셋

이 글은 Apache Kafka 입문 시리즈의 두 번째 글입니다. 1편에서 살펴본 구성 요소들 위에서, 메시지가 실제로 어떤 구조로 저장되고 관리되는지 알아보겠습니다. 1편을 마치며 세 가지 질문을 남겼습니다. 메시지는 브로커 안에서 어떤 구조로 저장될까? 토픽과 파티션은 정확히 무엇이고, 왜 필요할까? 컨슈머의 오프셋은 어떻게 동작할까? 이번 편에서 이 질문들에 하나씩 답하겠습니다. Topic: 메시지의 논리적 분류 토픽(Topic)은...

Mar 19, 202612 min read7

Java GC의 진화 — Serial에서 Generational ZGC까지

Java가 약속한 것 중 하나는 "메모리는 내가 관리할게"였다. C/C++ 개발자들이 malloc과 free로 메모리와 씨름하던 시절, Java는 Garbage Collector(GC)라는 자동 메모리 관리자를 들고 나왔다. 개발자는 객체를 만들기만 하면 되고, 치우는 건 GC가 알아서 한다. 하지만 "알아서"라는 말에는 대가가 있었다. GC가 동작하는 동안 애플리케이션이 멈추는 것이다. 이 멈춤을 Stop-The-World(STW) 일시 정지...

Mar 16, 20269 min read1

Spring의 3대 철학 — DI, AOP, PSA가 만드는 코드의 품격

Spring을 처음 배울 때, 나는 어노테이션 수집가였다. @Autowired를 붙이면 객체가 알아서 들어오고, @Transactional을 붙이면 트랜잭션이 알아서 관리되고, @Cacheable을 붙이면 캐시가 알아서 동작했다. "알아서"라는 말 뒤에 숨은 원리를 몰랐다. 그냥 마법이라고 생각했다. 그러다 문제가 생겼다. @Transactional을 붙였는데 롤백이 안 됐다. 같은 클래스 안에서 메서드를 호출했기 때문이었다. 원인을 찾는 데 ...

Mar 16, 202611 min read9

Spring Boot Docker 이미지, 한 줄 한 줄에 담긴 고민

처음 Spring Boot 애플리케이션을 Docker로 배포했을 때, Dockerfile은 딱 세 줄이었다. FROM openjdk:17 COPY build/libs/app.jar app.jar ENTRYPOINT ["java", "-jar", "app.jar"] 동작은 했다. 하지만 이미지 크기는 700MB를 넘겼고, 코드 한 줄 고칠 때마다 전체 JAR를 다시 빌드해야 했다. 프로덕션에 올릴 때는 root 권한으로 실행되고 있었다. "동작...

Mar 16, 202610 min read4

끄적끄적 테크 블로그

32 posts

물류 회사에 다니고 있는 개발자 블로그입니다. 개발을 너무 좋아해서 정신없이 작업하다가 중간에 끄적거리며 내용들을 몇개 적어봅니다 ㅎㅎ