오름차순 정렬 후에 dy에는 해당 인덱스의 벽돌이 가장 밑에 있을 경우로 생각해서 코드를 작성 했는데 제 논리에서는 엣지 케이스가 없는데 이런 아이디어로 dp를 풀어도 괜찮을까요? dp에는 자신이 가장 아래 있을 경우에 가장 높은 높이를 넣어줬고 내림차순이니 앞에 인덱스보다 무게가 더 높다면 해당 인덱스의 높이를 현재 인덱스의 벽돌에 올릴 수 있다는 생각으로 문제 풀이에 접근 했습니다. public void solution(int[][] arr, int n) { Arrays.sort(arr, Comparator.comparingInt((int[] a) -> a[0])); int[] dy = new int[n]; dy[0] = arr[0][1]; int maxHeight = dy[0]; for (int i = 1; i < n; i++) { int height = arr[i][1]; int weight = arr[i][2]; int mh = height; for (int j = i - 1; j >= 0; j--) { if (weight > arr[j][2]) { mh = Math.max(mh, height + dy[j]); } } dy[i] = mh; maxHeight = Math.max(maxHeight, mh); } System.out.println(maxHeight); }
1. 현재 학습 진도 몇 챕터/몇 강을 수강 중이신가요? 3-9강 여기까지 이해하신 내용은 무엇인가요? B+Tree 작동 원리, INDEX 생성 2. 어려움을 겪는 부분 select o1_0.id, o1_0.created_at, o1_0.member_id, o1_0.order_date, o1_0.order_number, o1_0.status, o1_0.total_amount, o1_0.updated_at from ch3_orders o1_0 where o1_0.order_date>='2023-01-01T00:00' and o1_0.status= 'COMPLETED' and o1_0.total_amount>=500 order by o1_0.order_date desc; 위와 같은 쿼리를 실행할 때, INDEX의 첫번째 필드를 date로 하였을 때, date의 정렬 방식에 따라서 속도가 달라지는 이유가 궁금합니다. (즉, 아래처럼 2가지 방식의 INDEX) CREATE INDEX ids_order_date_status_amount ON ch3_orders(order_date desc, status, total_amount); CREATE INDEX ids_order_date_status_amount ON ch3_orders(order_date, status, total_amount); 날짜 기준으로 최신 데이터를 100개 가져오는 쿼리를 실행시켰을 때, B+Tree의 leaf 노드에서는 양방향으로 이동할 수 있기 때문에 date가 ASC 정렬된 상태에서 역방향으로 읽어 최신 데이터를 읽으나, DESC 정렬된 상태에서 순방향으로 읽어 가져오나 읽는 노드의 수는 동일하다고 생각이 듭니다. 실제로 date를 각각의 정렬조건으로 INDEX를 만들어서 실제로 실행을 시켰을 때에도 거의 차이가 존재하지 않았습니다. (데이터가 많지 않아서 그런지는 모르겠습니다...) 하지만 제가 시도 한 내용이 맞는지 잘 모르겠습니다. 3. 시도해보신 내용 ASC, DESC 정렬을 시킨 INDEX를 사용하여 analyze 한 결과입니다. Limit: 100 row(s) (cost=50413 rows=100) (actual time=0.874..0.899 rows=100 loops=1) -> Index range scan on o1_0 using ids_order_date_status_amount over ('2023-01-01 00:00:00.000000' <= order_date AND 'COMPLETED' <= status AND 500 <= total_amount)... Limit: 100 row(s) (cost=50413 rows=100) (actual time=0.43..0.446 rows=100 loops=1) -> Index range scan on o1_0 using ids_order_date_status_amount over (order_date <= '2023-01-01 00:00:00.000000' AND status <= 'COMPLETED'), with index condition: (... 1번은 ASC로 정렬한 INDEX입니다. 2번은 DESC로 정렬한 INDEX입니다. 여기에서 desc로 정렬한 acutal time이 거의 2배 빨라진 것을 확인 할 수 있습니다. analyze가 정확한 값을 알려주지 않을 수도 있다는 사실을 알고 있지만, 제가 판단한 내용이 맞는지 의심이 듭니다. 딩코딩코님도 desc로 정렬을 하신거 보면 이유가 있을 것이라고도 생각합니다. Q1. 위 상황에서 INDEX의 첫번째 칼럼은 정렬 조건이 의미가 없는 게 맞나요? Q2. 만약 의미가 있다면 어떤 부분에서 의미가 있는지 궁금합니다.
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 예 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 예 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) 예 [질문 내용] 커맨드 패턴 개념 설명을 어떤 강의에서 진행하셨을까요? 바로 커맨드 패턴 적용으로 들어가는 것 같습니다!
5회기출문제 작업형2에서 평가지표가 RMSE가 나왔는데 다른 평가지표를 사용해도 무방하다고 하셔서 MSE로 작업을 해봤어요 그런데 결과값이 너무 크게 차이가 나는데 상관없나요? 값이 작을수록 좋다고 하셔셔.. ㅜ 만약 시험에서 RMSE로 나올경우 , 대신 쓸 수 있는 평가지표를 추천해주세요
학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요! 질문과 관련된 영상 위치를 알려주면 더 빠르게 답변할 수 있어요 먼저 유사한 질문이 있었는지 검색해보세요 문제 7번에서 index '2001' 데이터(행)의 평균보다 큰 값의 갯수와 index '2003' 데이터(행)의 평균보다 작은 값의 갯수를 더하시오 위 말이 2001의 데이터행의 평균과 2001의 데이터를 비교해서 큰 값인지 df내 전체 데이터와 비교하라는 것인지 비교군이 명확하지 않아 혼동이 옵니다. 설명 영상을 보고서야 같은 행에 대한 비교란 것을 알았습니다. 아래 2003도 마찬가지고요
@Entity public class Member{ ... @OneToMany(cascade = CascadeType.ALL, orphanRemoval = true) @JoinColumn(name = "MEMBER_ID") private List<AddressEntity> addressHistory = new ArrayList<>(); ... } 강의에서 위와 같이 값타입 컬렉션을 사용하지않고, 일대다 연관관계를 위한 엔티티를 만들어서 사용하라고 하셨는데요. 그 부분에 대해서 설명을 못 들은 부분이 있어서 질문드립니다. 1. 다대일 양방향 연관관계를 사용해서 해도 될거같은데, 다대일 양방향 연관관계를 사용하지않고 굳이 일대다 단방향 연관관계를 사용한 이유가 무엇인가요?? 단순히 AddressEntity에서 Member에 대해서 조회할 일이 없고 Member에서만 AddressEntity에 대해서 조회할 일이 있으므로 그런것일까요? 2. cascade와 orphanRemoval을 사용하셨는데, 그 이유가 무엇이고 사용하지않으면 안되는 이유도 같이 궁금합니다ㅠㅠ
안녕하세요, 시나공 책을 보니 object 컬럼의 nunique 값이 다를 때는 train, test 데이터를 concat한 뒤 원핫 인코딩을 해주어야한다고 나와있는데 레이블 인코딩도 마찬가지인가요? 모의문제 2에서는 neighbourhood의 nunique값이 다른데 concat 없이 레이블 인코딩을 진행하신 것 같아서 질문 남깁니다.
학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요! 질문과 관련된 영상 위치를 알려주면 더 빠르게 답변할 수 있어요 먼저 유사한 질문이 있었는지 검색해보세요 # 원산지와 메뉴 기준 (평균, 합계) df.groupby(['원산지','메뉴']).agg(['mean','sum']) # 원산지와 메뉴 기준 (평균, 합계) df.groupby(['메뉴']).agg(['mean','sum'], numeric_only=True) 원산지와 메뉴기준으로 agg하여 mean 과 sum을 구했을때 코드를 알려주셨는데요, 원산지 하나의 칼럼의 mean과 sum을 보고싶을 때는 어떻게 해야하나요? 에러가 나네요,, 아마 원산지가 빠져서 문자열이라 그런거같은데, numeric_only = True을 어디에 넣어야하나요?
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문 전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? - 예 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? - 예 3. 질문 잘하기 메뉴얼을 읽어보셨나요? - 예 [질문 내용] 안녕하세요, 강의 즐겁게 듣고 있습니다. 강의: 섹션 13. 병렬 스트림 - 병렬스트림 사용시 주의점1 질문: 강의 내용 중 'Fork/Join 프레임워크를 I/O 바운드 작업에는 사용하지 않는다'는 내용에서 I/O 바운드 작업을 '소요시간이 긴 작업'으로 이해해도 될까요? 세부 I/O 바운드 작업을 공용 풀에서 처리할 경우 발생하는 문제들이 I/O 작업 자체보다는 긴 시간이 소요되는 작업으로 풀의 한정된 수의 스레드를 점유하는 것이 원인이라 이해했는데 강의내용이 I/O 바운드 작업에 초점을 맞추어 제 이해에 오해가 있는가 싶습니다. 병렬 스트림 등의 기능을 통해 공용 풀에서 I/O 바운드 작업이 처리되면 스레드 블로킹에 의한 CPU 낭비, 스레드 수를 증가시킨다면 컨텍스트 스위칭 오버헤드 증가, 작업 훔치기 기법 무력화 등의 부작용이 있는데 이는 긴 시간이 소요되는 작업으로 풀의 한정된 수의 스레드가 오래 점유되면서 발생하는 문제로 이해했습니다. CPU 바운드 작업이라도 소요시간이 길다면 CPU 낭비를 제외하고 위와 같은 문제가 발생되리라 생각합니다. (I/O 바운드 작업이 긴 시간 CPU를 사용하지 않으면서 스레드를 점유한다면 무거운 CPU 바운드 작업은 긴 시간 CPU를 사용하면서 스레드를 점유, 이로 인해 공용풀의 스레드를 늘린다면 컨텍스트 스위칭 오버헤드 증가, CPU 바운드 작업이더라도 작업이 빨리 끝나지 않아 훔치기 기법 무력화 등) 일반적으로 I/O 바운드 작업은 CPU 바운드 작업보다 긴 시간이 소요되는 것이 경험적/현실적 가정으로 알고 있습니다. 이런 일반적인 현상을 전제로 I/O 바운드 작업을 '소요시간이 긴 작업'을 대표하는 의미로 사용하신 것인지, 아니면 제가 놓친 다른 의미, I/O 바운드 작업만이 가지는 특징을 염두에 두신 것인지 궁금합니다. 좋은 5월 보내시길 바랍니다. 감사합니다.
