전부 NA인 그룹에 na.rm = TRUE

세 결과에 규칙이 하나 있는데 저는 그게 좀 예쁘다고 생각해요. 각각 자기 연산의 항등원을 돌려줘요. 0을 더해도 아무것도 안 바뀌고, -Inf는 무엇보다 작으니 누적 최댓값을 시작하기에 딱 맞는 값이에요. 같은 이유로 아무것도 없을 때 prod는 1을, min은 Inf를 줘요. 평균은 기댈 항등원이 없어서 0/0으로 가고요. R이 대충 하는 게 아니라 대수에 충실한 거예요. 그룹 합계 0이 표에 들어가도 되느냐는 그거랑은 다른 문제고요. 전부 NA인 그 그룹에 prod(x, na.rm = TRUE)를 돌려 보세요. 1도 0만큼 거슬리는지 궁금해요.

아, 이거요. 끝까지 tapply만 쓰시나요, 아니면 어딘가에 aggregate도 있나요? aggregate의 공식 메서드는 기본값이 na.action = na.omit이라서 응답값이 NA인 행은 함수가 보기도 전에 빠져요. 전부 NA인 그룹은 거기서 0으로 나오는 게 아니라 결과에서 아예 사라져요. 저도 그룹 수가 하나 줄어서 겨우 알았어요. 행이 이미 없어졌다면 sum_or_na가 NA를 돌려줄 기회나 있을까요?

일관적인 건 맞습니다. 다만 그 일관성은 축약 연산의 것이지 표의 것이 아닙니다. 아무것도 없는 합과 실제 값의 합이 둘 다 숫자 하나로 도착하니 호출하는 쪽은 둘을 구별할 수 없습니다. 고치는 모양은 두 가지입니다. NA를 돌려주면 모든 호출자가 빈 경우를 처리하거나 그대로 넘겨야 합니다. 아니면 합계 옆에 그 합에 들어간 값의 개수를 함께 돌려줍니다. 옆에 개수 0이 붙어 있으니 합계 0도 정직해집니다. 요약표에는 첫째가 더 쌉니다. 둘째는 열 하나가 더 들지만, 나중에 누군가 그룹을 데이터 양으로 가중하려 할 때 값을 합니다.

알고 보니 둘 다였다. 0을 낸 스크립트는 tapply를 썼다. 같은 폴더의 예전 스크립트는 공식과 함께 aggregate를 썼는데 출력 그룹이 하나 적었고, 나는 그걸 어딘가의 필터 탓으로 넘겼다. 원인은 na.omit이었다. 둘 다 g의 모든 수준을 남기는 tapply(x, g, sum_or_na)로 바꾸자 두 출력이 일치했다. 0이 있던 자리에는 NA가 들어갔고, 사라졌던 그룹도 NA로 돌아왔다. 같은 데이터에서 서로 다른 틀린 답이 두 개 나온 셈이다. 이제부터는 그룹마다 NA 개수를 셋째 열에 적는다.