분할이 잘못되었나요?다음과 같은 표가 있다고 가정해 보겠습니다.
| 범주 |
목 |
수준 |
| A |
1 |
델타 |
| A |
2 |
폭스트롯 |
| A |
3 |
호텔 |
| B |
1 |
줄리엣 |
| B |
3 |
다섯 |
Category=B, Item=2가 누락되었습니다.
"분할 기준" = 범주, "열 분할" = 수준, "모두 유지"로 이 테이블을 "분할"하려고 하면 다음이 반환됩니다.
| 목 |
A |
B |
| 1 |
델타 |
줄리엣 |
| 2 |
폭스트롯 |
다섯 |
| 3 |
호텔 |
|
새로 분할된 테이블에서는 Item=2,Category=B가 "lima"로 표시되지만 이는 잘못된 내용입니다. 해당 셀은 비어 있어야 하며, "lima"는 Item=3,Category=B 아래에 있어야 합니다.
이건 사용자 오류인가요, 아니면 JMP의 버그인가요?
데이터 블렌딩 및 정리Re: 스태킹이 안 좋은가요?안녕하세요 @BHarris 님 , 그룹에서 항목을 사용해 보세요. 예상하신 결과가 나올 겁니다.
최상의,
Re: 스태킹이 안 좋은가요?네, 효과가 있는 것 같습니다.
무슨 일인지 설명해 주시겠어요? 그룹 단계가 왜 필요했는지 알고 싶습니다.
Re: 스태킹이 안 좋은가요?물론, 그룹 없이 분할하는 것은 행 단위로 문자 그대로 분할하는 것이며, 항목에 범주 구성 요소가 누락되었다는 사실을 인지하지 못합니다. 그룹은 각 범주별로 항목을 먼저 확인한 후 범주를 확인하여 수준별로 분리하도록 강제합니다.
온라인 도움말에서 ( https://www.jmp.com/support/help/en/18.2/?os=mac&source=application#page/jmp/split-columns-in-data-tables.shtml
그룹
선택한 변수의 각 그룹 내에서 데이터를 분할 하려면 그룹 변수를 지정합니다. 각 그룹은 출력 표에 행으로 표시됩니다. 필요한 변수, 분할 기준 및 열 분할도 지정해야 합니다.
참고: 그룹화 기준으로 삼는 변수에 다른 그룹이 포함되어 있거나 무작위 순서로 정렬된 경우, 해당 변수를 그룹 변수로 지정하면 데이터가 적절하게 재구성되고 누락된 값이 적절한 위치에 할당됩니다.
그렇지 않으면 추가 행을 추가하고 범주와 항목을 정의하지만 해당 행의 수준은 비워두어야 합니다.
도움이 되길 바랍니다.
Re: 스태킹이 안 좋은가요?이 문제에 대해 더 생각할수록 이해가 안 됩니다. split 함수가 왜 이런 식으로 동작하는지 전혀 이해가 안 됩니다. 마치 개발자들이 루프를 중첩해서 데이터가 올바른 위치에 있기를 바라는 것처럼 말이죠...
(a) 이런 동작의 근본적인 원리를 이해하기에는 내가 여전히 너무 멍청한 것인지, (b) 입력이 완전 요인 분석이고 사용자가 해당 가정이 이루어졌다는 것을 알아야 하는 고성능(대용량 테이블에서 빠른 분할)을 제공하기 위해 이런 식으로 구현된 것인지, (c) 실제로는 제출/수정이 필요한 버그일 뿐인지 궁금합니다.
((a)라면 기분 나쁘진 않을 거야.;) )
Re: 스태킹이 안 좋은가요?당신의 생각을 자세히 설명해 줄 수 있나요?
나는 반대 방향으로 주장하고 싶습니다.
입력 데이터가 잘 구성되어 있다면, 별다른 주의 없이 분할할 수 있습니다.
입력 데이터가 잘 구성되지 않았지만 일부 그룹화 정보가 있는 경우, 이 그룹화 정보를 사용하여 JMP에 수행해야 할 작업을 알릴 가능성이 항상 있습니다.
작동하지 않는 것:
사용자는 그룹화 정보(열이 있음)를 알고 있지만 JMP(GUI를 통해)에 알리지 않습니다.
그렇다면 JMP가 그룹화 정보를 사용하지 않는 것도 당연합니다.
[JMP가 추측을 적용하고 | 자동 수정을 하는 경우도 있는데, 사용자는 창의성에 대해 궁금해합니다.]
Re: 스태킹이 안 좋은가요?원래 질문에 제공된 데이터 세트에 대해 어떻게 생각하시나요? "잘 구조화되어" 있나요?
그리고 테이블을 분할할 때 JMP가 현재 보이는 동작에 대해 어떻게 생각하시나요?
제가 이해하기로는 "분할 기준" 열은 새 표의 열 머리글에 포함될 값을 가진 열이고, "분할 열"은 새 열의 셀에 포함될 값을 가진 열입니다. 이 맥락에서 "그룹화"가 무슨 뜻인지 아직 잘 모르겠습니다.
Re: 스태킹이 안 좋은가요?초기 데이터 테이블은 "잘 구성되어 있습니다".
그룹화 개념은 특정 출력 행을 정의하기 위해 입력 데이터 테이블의 어떤 행을 그룹화할 것인지에 대한 관점에서 생각해 볼 수 있습니다.
Re: 스태킹이 안 좋은가요?설명하는 또 다른 방법:
"범주" 및 "수준" 열(단독)은 잘 구성되지 않았습니다 . 다음과 같은 추가 정보가 필요합니다.
@BHarris 님 이 쓰셨습니다: Category=B, Item=2가 누락되었습니다.
다른 사람들에게 사실을 알리기 위해: 5번 행과 6번 행 사이에 무언가가 빠졌습니다.
사례 #1:
사용자는 JMP에 "항목" 열의 존재를 알리지 않습니다("항목"은 GUI에서 사용되지 않습니다 **)
그렇다면 JMP는 해당 작업을 제대로 수행할 만큼 충분한 지식이 없습니다.
사례 #2:
3번째 드롭 존이 있습니다. 이를 통해 사용자는
@BHarris 님 이 쓰셨습니다: Category=B, Item=2가 누락되었습니다.
구조화된 방식으로 - 그룹화된 열로.
"그룹화"는 당신이 원하는 것에 아주 잘 맞습니다:
JMP에 추가 정보를 제공하여 입력 데이터의 Rank(행(), 카테고리) 에 의해 결정되는 것이 아니라 그룹화 열을 통해 그룹화되어 항목을 특정 행에 배치할 수 있도록 합니다.
**) 편집하다:
"항목"은 GUI에서 Keep All을 통해 암시적으로 사용 됩니다 .
하지만 이건 너무 "수동적"입니다. 아래를 참조하세요.
Re: 스태킹이 안 좋은가요?@호기 -- 인터페이스 어디에도 항목 열을 포함하지 않았다는 점에서 뭔가 엉뚱한 생각을 하셨네요. 따라서 분할 알고리즘이 그 존재조차 인식하지 못하는 게 아닐까 하는 생각이 듭니다.
분할 작업에서 *모든* 열이 중요하다고 생각했던 것 같습니다. 가능한 한 모든 관계를 유지하려고 했던 것 같습니다. 예를 들어 "lima"는 항목 "3"에만 연결되었습니다. 이제 "모두 유지"를 할 때 다른 모든 열도 그룹화해야 하는지 알아내야 합니다.
언젠가 JMP 마스터 자격을 얻고 완전히 이해하게 되기를 바랍니다. 그러면 JMP가 그룹 역할에서 다른 모든 "보관" 열을 암묵적으로 사용하지 않는 이유를 이해할 수 있을 것입니다. 그때까지는 JMP가 이러한 상황에서 어떻게 동작하는지 명확하지 않고, 식별하기 어려운 조건에서 잘못된 출력 데이터를 생성하며, 제가 이해할 수 있을 만큼 충분히 문서화되어 있지 않기 때문에 계속 불안할 것입니다. 적어도 이러한 불안 덕분에 앞으로 JMP를 사용할 때 더욱 주의를 기울일 수 있을 것입니다.
고맙습니다.
Re: 스태킹이 안 좋은가요?이미 언급하셨지만, 명확하게 쓰는 게 도움이 될 수도 있겠네요.
JMP는 다음 규칙을 적용합니다.
- 그룹 : 보관하여 그룹화하여 사용
- 유지하다 : 유지하다 (~ 떨어뜨리지 않다)
@BHarris 님 이 쓰셨습니다:
이제 "모두 유지"를 선택할 경우 다른 모든 열도 그룹화해야 하는지 알아내야 합니다...
내 생각엔 그럴 것 같아요.
두 가지 방법을 모두 시도해 보고 차이점을 확인한 후 결정할 수 있습니다.
그룹은 데이터를 "구조화"하는 데 도움을 줍니다. 데이터가 이미 구조화되어 있다면 아무런 문제가 없습니다. 구조화되어 있지 않더라도 의미 있는 결과를 보장합니다.
Keep을 사용하려면 무엇을 하는지 정확히 알아야 합니다. 아래는 몇 가지 예시입니다.
커뮤니티에서 이루어지는 이런 작은 토론은 사용자의 지식을 이해하고, 도전하고, 다듬는 데 많은 도움이 됩니다.
사용자 코칭 세션에서 나온 "재미있는" JMP 초보자 질문 모음 입니다. 다른 사용자들이 JMP를 이해하는 데 도움을 드리기 위해 모았습니다. 많은 질문이 단순한 수사학적 표현으로 구성되어 있으며, 때로는 "JMP 속어" 때문에 JMP 논리를 이해하기가 쉽지 않다는 것을 보여줍니다.
@B해리스님 이 작성하셨습니다:
그때까지는 계속 불안할 것 같습니다. 이런 상황에서 제게는 이 기능이 명확하게 보이지 않고, 식별하기 어려운 상황에서 잘못된 출력 데이터를 생성하며, 제가 이해할 수 있을 만큼 충분히 문서화되어 있지 않기 때문입니다. 적어도 그런 불안함이 앞으로 이 기능을 사용할 때 저를 더 경계하게 만들 것입니다.
저도 동의합니다. "JMP가 무슨 일을 하는지 아는 것"이 매우 중요하며, 사용자가 제대로 된 작업을 할 수 있다고 느낄 정도로 세부적인 부분까지 아는 것이 중요합니다. 긴장하거나 놀라지 마세요. 예상치 못한 일이 발생하면 사용자는 불안감을 느끼기 시작합니다. JMP가 예상치 못한 일을 하는 다른 곳은 어디인가요?!?!
JMP에 훌륭한 기능이 있을지 몰라도, 그 기능이 사용자를 짜증나게 하거나 두렵게 할 수도 있습니다. 적어도 JMP의 기능을 예상하지 못한 사람들에게는 말이죠...
이러한 함정문 지도를 가지고 있으면 사용자가 함정에서 빠져나오는 데 도움이 될 수 있습니다. 모든 JMP 사용자는 JMP를 "안전하게" 사용할 수 있도록 이러한 지도를 가지고 있어야 합니다.
세부 사항이 잘 문서화되어 있더라도 JMP는 매우 강력한 반면, 문서가 너무 적거나 너무 많습니다!
이로 인해 올바른 정보를 찾기가 어렵습니다. 런봇 덕분에 훨씬 쉬워졌지만, 여전히 모든 세부 정보를 알고 있지는 않습니다.
Re: 스태킹이 안 좋은가요?그룹화 없이 분할과 유지 의 극단적인 사례
유지하다 : name (이름은 그룹화에 사용되지 않음)
2개의 행이 하나의 행으로 병합되면서 많은 "이름"이 손실됩니다.
첫 번째 *) 항목이 승리하므로 여성 이름부터 시작하고 남성 이름은 모두 삭제합니다.
이름이 전부 남자예요? 아니, 마지막에 남자 학생이 몇 명 남아 있어요.
*) 모든 테이블 플랫폼에 적용되는 보편적인 규칙은 없습니다 . 어떤 가치를 유지하고 어떤 가치를 잃을 것인가.
Join은 첫 번째 값만 유지하고 이후 값은 신경 쓰지 않습니다.
업데이트는 모든 값을 유지하려고 하며 마지막 값은 "고정"됩니다. 이것이 Tables/Update가 매우 느린 이유입니다(명령을 실행하는 데 몇 시간이 걸릴 수 있음): Tables/Update 속도 높이기
Re: 스태킹이 안 좋은가요?
@hogi 님 이 쓰셨습니다:
첫 번째 *) 항목이 승리합니다.
아, 이건 Keep을 통해 추가된 열에만 해당되는군요.
분할 열의 경우 분할은 업데이트와 비슷하게 동작합니다. 즉, 마지막 열이 "고정"됩니다.
이 예시를 통해 설명해 보려고 합니다. 최종 데이터 세트에 포함되는 "이름" 항목과 M/F 분할 항목을 표시했습니다. 다음 내용을 확인할 수 있습니다.
- 유지하다 (이름 등)를 통해 추가된 열 : 순위=1 (첫 번째를 가져오고 이후는 건너뜁니다)
- 열 분할을 통해 추가된 행(높이 --> M/F): RankReverse=1 (마지막 행은 "고정")
Re: 스태킹이 안 좋은가요?이러한 동작은 논리에 따라 이루어지지만, 그 논리가 간단하거나 모든 사용자가 기대하는 것인지에 대해서는 논쟁의 여지가 있습니다. 
Keep All을 기본값으로 설정하는 것이 올바른 선택인지 궁금합니다. JMP가 다음과 같이 시작하면
...그러면 ' 모두 유지' 옵션을 활성화한 사용자는 설명서를 참조하여 해당 옵션이 원하는 대로 작동하는지 확인할 수 있습니다.
JMP에서는 "Keep을 사용하시겠습니까? Group을 사용하는 것이 더 낫습니다."라는 경고를 표시할 수도 있습니다.
줄 아래에: 놀라움 없음 | 해당 옵션을 사용하지 않는 사용자의 불안감.
분할보다 훨씬 더 위험합니다: 테이블/업데이트
기본 인터페이스도 "모두"로 시작합니다.
a) 열 추가
b) 열을 바꾸기 위해 (!)
몇 년 전, 저는 기본 설정을 다음과 같이 바꾸는 AddIn을 작성하는 것이 충분히 위험하다고 생각했습니다.
추가적인 장점은 이 변경으로 인해 플랫폼이 수천 개의 열을 업데이트하려는 설정으로 시작하지 않는다는 것입니다.
이로 인해 원래 것보다 훨씬 더 빨라졌습니다
https://community.jmp.com/t5/JMP-위시-리스트/테이블 속도 향상-업데이트/idc-p/653334/하이라이트/true#M4531
Re: 스태킹이 안 좋은가요?주의: Jmp가 예상치 못한 일을 하는 곳에 대한 주제를 추가했습니다.
Re: 스태킹이 안 좋은가요?언젠가 split(그리고 stack)이 어떻게 동작하는지 보여주는 애니메이션을 보고 싶습니다. split-by 열 값은 열 헤더로, split-columns 값은 새 열의 셀로 이동하는 모습을 상상해 보세요. (특정 split-by 열에 여러 split-columns가 있는 경우, 번호가 매겨진 새 열이 생성된다는 사실을 방금 알고 놀랐습니다.)
하지만 정말 흥미로운 부분은 충돌이 발생할 때입니다. 예를 들어 여러 값이 같은 셀에 들어가려고 할 때입니다. JMP는 이런 일이 발생할 때 경고를 표시합니다(정말 좋은 경고죠!). 하지만 이 글은 정상적으로 분할된 것처럼 보이는 데이터셋에서 작성되었습니다. 하지만 자세히 살펴보니 그렇지 않다는 것을 깨달았습니다. 제가 이해하지 못해서 그 경고를 무시했던 것입니다.
제 생각에는 경고를 "유지할 열의 여러 행(값이 다를 수 있음)이 분할 테이블의 같은 행에 매핑되어 있습니다. 각 열의 값은 하나만 유지됩니다."에서 "같은 셀에 여러 값이 매핑되어 있습니다. 값은 하나만 유지됩니다."로 변경해야 합니다.
Re: 스태킹이 안 좋은가요?
@BHarris 님 이 쓰셨습니다:
방금 주어진 분할 기준 열에 대해 여러 개의 분할 열이 있는 경우 새로운 번호가 매겨진 열이 생성된다는 사실을 알고 놀랐습니다.
여러 개의 분할 열이 사용되는 경우 JMP는 분할 열 이름과 split-by-Column 항목을 조합하여 열 이름을 생성합니다.
분할 열로 열 하나만 선택된 경우, 분할 열의 이름은 열 이름에 포함되지 않습니다.
제가 JMP의 기능을 설명하기 위해 Big Class를 사용하기 시작하면 동료들은 눈을 굴립니다.
하지만 설정을 변경하기 위해 대체 데이터 세트를 사용하는 것은 훌륭한 방법입니다.
"M"과 "F"를 보면 JMP가 무엇을 하는지 명백하고, 원래 데이터 세트에 나타난 "숫자"에 대해 궁금해할 필요가 없습니다.
빅 클래스는 매우 간단해 보이지만, 많은 세부 사항을 설명하기에는 충분히 복잡합니다.
공선성만 누락되었습니다...
