0411 TIL

looggi·2023년 4월 11일
0

TILs

목록 보기
59/114
post-thumbnail

신은 없다

에피쿠로스의 역설(Epicurean paradox)

신이 악을 막을 의지는 있지만 능력이 없는가? 그렇다면 신은 전능하지 않다.
신이 악을 막을 능력은 있는데 의지가 없는가? 그렇다면 신은 선하지 않다.
신이 악을 막을 능력도 있고 의지도 있는가? 그렇다면 이 세상의 악은 어디에서 기인한 것인가?
신이 악을 막을 능력도 없고 의지도 없는가? 그렇다면 왜 우리가 그를 신으로 불러야 하는가?

나는 해시테이블을 안다..

해시테이블은 키-밸류 쌍으로 데이터를 저장하는 자료구조로 키값에 해시함수를 적용해 배열의 인덱스로 변환해서 데이터를 저장한다
실제 데이터가 저장되는 공간은 버킷/슬롯이라고 한다
해시테이블의 평균 시간 복잡도는 O(1)이다.. O(N)까지 증가할 수 있다(아래의 경우)

인덱스 값이 동일한 경우 seperate chaining과 open addressing으로 해결할 수 있다.
https://velog.io/@loooggi/0218-TIL
https://velog.io/@loooggi/0309-TIL

인덱스 진짜 뭔지 안다..

인덱스는 색인이다 빨리 찾을 때 쓰는거 데이터가 너무 크거나 적을 때는 쓰면 오히려 비효율적인거..
디스크 저장소 액세스를 줄이고 루트-리프 왕복횟수를 줄이는 것이 핵심
인덱스가 많아지면 중복수정이 필요하게 되어 성능 저하를 유발할 수 있고 인덱스또한 공간을 차지하므로 설정에 유의해야한다

보통 인덱스라함은 넌클러스터를 말하고 (데이터 페이지를 건드리지 않은 채로 인덱스를 따로 만드는 것) 인덱스 공간을 거치고 나서야 데이터 페이지로 이동하기때문에 검색(조회) 속도는 느리지만 데이터의 입력 수정 및 삭제는 더 빠르다

클러스터는 테이블당 하나만 생성할 수 있으며 트리 형태를 가지는 인덱스로 인덱스 페이지가 따로 있지 않고 항상 정렬된 상태를 유지하여 넌클러스터와 비교했을 때 조회는 더 빠르고 입력 수정 및 삭제는 더 느리다(밸런싱 트리의 형태로 페이지 분할이 발생할 수 있기 때문)

심지어 결합 인덱스도 안다..
결합 인덱스를 구성할 땐 순서가 중요하다
첫번째 칼럼은 쿼리에 사용되어야하며 유니크해서 데이터를 보다 크게 그룹화를 할 수 있는 것이 좋다
https://velog.io/@loooggi/0126-TIL
https://velog.io/@loooggi/0204-TIL
https://velog.io/@loooggi/0222-TIL
https://velog.io/@loooggi/0302-TIL

깃 버전 관리

깃이란 소스코드를 효과적으로 관리하기 위해 개발된 '분산형 버전 관리 시스템'
소스 코드가 변경된 이력을 쉽게 확인할 수 있다
특정 시점에 저장된 버전과 비교하거나 특정 시점으로 되돌아갈 수 있다
에드(스테이징), 커밋.. 흠

기능별로 브랜치를 따로 만들어서 커밋하고 PR날리고 머지하면 PULL해서 작업하고..

https://backlog.com/git-tutorial/kr/intro/intro1_1.html

HTTP 상태코드

200 OK
the request has succeeded. A 200 response is cacheable by default.

201 Created
the request has succeeded and has led to the creation of a resource. The new resource, or a description and link to the new resource, is effectively created before the response is sent back and the newly created items are returned in the body of the message, located at either the URL of the request, or at the URL in the value of the Location header.

The common use case of this status code is as the result of a POST request.

202 Accepted non-committal
the request has been accepted for processing, but the processing has not been completed; in fact, processing may not have started yet. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place.

204 No Content
a request has succeeded, but that the client doesn't need to navigate away from its current page.

This might be used, for example, when implementing "save and continue editing" functionality for a wiki site. In this case a PUT request would be used to save the page, and the 204 No Content response would be sent to indicate that the editor should not be replaced by some other page.

cacheable by default

400 Bad Request
server cannot or will not process the request due to something that is perceived to be a client error (for example, malformed request syntax, invalid request message framing, or deceptive request routing).

401 Unauthorized
the client request has not been completed because it lacks valid authentication credentials for the requested resource

402 Payment Required
nonstandard response status code that is reserved for future use.
requested content is not available until the client makes a payment

403 Forbidden
server understands the request but refuses to authorize it

https://velog.io/@loooggi/0117-TIL
https://velog.io/@loooggi/1204-TIL
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status

프로그래머스 문제풀기

📞 전화번호 목록

해시를 풀어본다
https://velog.io/@loooggi/0301-TIL

def solution(phone_book):
    answer = True
    for p in phone_book:
        for q in phone_book:
            if len(p)<len(q):
                if q[:len(p)]==p:
                    answer=False
    return answer

너무 단순하게 생각해서 for문을 두번 돌렸더니 효율성 테스트에서 시간초과

def solution(phone_book):
    answer = True
    phone_book.sort()
    for i in range(len(phone_book)-1):
        if len(phone_book[i]) < len(phone_book[i+1]):
            if phone_book[i + 1][:len(phone_book[i])] == phone_book[i]:
                answer = False
                break
    return answer

정렬 후 앞 뒤의 요소를 비교해주면 반복문을 이중으로 사용하지 않아도 된다

def solution(phoneBook):
    phoneBook = sorted(phoneBook)

    for p1, p2 in zip(phoneBook, phoneBook[1:]):
        if p2.startswith(p1):
            return False
    return True

깔끔하게 정렬해서 앞의 문자열이 뒤의 문자열이 앞의 문자열로 시작되는지를 판단하는 것 결국 for문을 두번 돌린 것과 마찬가지의 효과가 나타난다..
아니 그러고보니까 처음에 생각했던 코드가 진짜 겁나 비효율적이었던 게 이미 비교한 것도 또 비교를 하고 break도 없어서 바로 탈출하지도 못한다 하나만 발견되어도 False인 건 변함이 없는데 리턴으로라도 하지..

def solution(phone_book):
    answer = True
    hash_map = {}
    for phone_number in phone_book:
        hash_map[phone_number] = 1
    for phone_number in phone_book:
        temp = ""
        for number in phone_number:
            temp += number
            if temp in hash_map and temp != phone_number:
                answer = False
    return answer

해시 풀이의 정석 ⭐⭐⭐
첫번째 반복문에서 해시맵을 먼저 만들어주고
두번째 반복문에서 각 요소의 각 숫자들을 temp에 이어붙여가면서 temp가 해시맵의 밸류값에 있으면서 지금 비교대상이 된 phone_number는 아닐 때(한개씩 붙이다가 전체를 이어붙인 경우) False가 된다

import re

def solution(phoneBook):

    for b in phoneBook:
        p = re.compile("^"+b) # 컴파일된 패턴 객체
        for b2 in phoneBook:
            if b != b2 and p.match(b2):
                return False
    return True

정규식을 사용한 방법- 지금은 더 이상 완전 통과는 안된다고 함
문자열의 시작이 phonebook의 요소와 일치하는지를 체크
https://wikidocs.net/4308

from itertools import combinations as c

def solution(phoneBook):
    answer = True
    sortedPB = sorted(phoneBook, key= len)
    for (a,b) in c( sortedPB,2):
        if a == b[:len(a)]:
            answer = False
    return answer

combination을 써서 중복을 피함- 지금은 더 이상 완전 통과는 안된다고 함
key=len을 사용해서 sort의 속도 향상

profile
looooggi

0개의 댓글