Scikit-learn: CategoricalEncoder API를 재고하고 있습니까?

요약 @jorisvandenbossche에 감사드립니다. 나는 옵션 2에 찬성한다고 생각합니다. OneHotEncoder 클래스를 재사용하고, 이상한 속성을 더 이상 사용하지 않으며, 생성자 매개변수를 추가하여 기본 동작이 변경되지만 쉽게 침묵할 수 있다는 향후 경고와 함께 동작을 선택합니다. 해당 옵션에 대한 값을 전달하는 것만으로 해당 경고가 표시됩니다.

CategoricalEncoder를 되돌린다는 아이디어는 나를 상당히 슬프게 하지만 제 생각에는
미래의 사용자가 옵션 2에 대해 덜 신비스러워할 것이라는 말이 옳습니다.
문제는 우리가 이것을 OHE에 대한 변경으로 구현하려고 시도했다는 것입니다.
오랜 시간 동안 그것은 결코 날지 않았습니다. 아마도 시도하는 것이 좋을 것입니다.
제안된 내용에 따른 OneHotEncoder 독스트링 수정
변경하여 정상적인지 확인할 수 있습니다.

조엘이 말한 것에 +1

내 폰에서 보냈습니다. 오타와 짤막함을 용서해 주십시오.

2018년 1월 23일 12:28, 12:28에 Joel Nothman [email protected]이 다음과 같이 썼습니다.

CategoricalEncoder를 되돌린다는 아이디어는 나를 상당히 슬프게 하지만,
생각한다
미래의 사용자가 옵션 2에 대해 덜 낯설게 하는 것이 맞습니다. 내
기본
문제는 우리가 이것을 OHE에 대한 변경으로 구현하려고 시도했다는 것입니다.
NS
오랜 시간 동안 그것은 결코 날지 않았습니다. 아마도 시도하는 것이 좋을 것입니다.
제안된 내용에 따른 OneHotEncoder 독스트링 수정
변경하여 정상적인지 확인할 수 있습니다.

--
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/scikit-learn/scikit-learn/issues/10521#issuecomment -359761818

CategoricalEncoder를 되돌리는 아이디어는 나를 매우 슬프게 만듭니다.

분명히 말하면 되돌리기가 아니라 모든 기능을 유지하는 리팩터링/이름 변경이 될 것입니다!
그러나 나는 또한 "CategoricalEncoder"라는 이름을 좋아하는데, 그것은 참으로 슬플 것입니다.

즉, 이것을 OnehotEncoder에 통합하는 것이 얼마나 가능한지 아이디어를 얻기 위해 빠르게 변경을 시도할 것입니다.

좋아, 개념 증명으로 PR을 열었습니다: https://github.com/scikit-learn/scikit-learn/pull/10523.
아직 완료되지 않았습니다(사용 중단 경고 및 새 속성이 이전 동작에서 아직 계산되지 않음).

주요 API 질문은 입력 데이터의 형식에 관한 것입니다.
요약하자면 현재 범주형 데이터를 처리하는 두 가지 방법 이 있습니다.

1) 실제로서 아직 인코딩되지 않은(정수 또는 문자열), 범주형 데이터( CategoricalEncoder 에서 수행되는 방식) -> 교육 데이터의 고유 값에서 범주 추론
2) 정수로 이미 인코딩된 데이터(현재 OneHotEncoder 에서 수행되는 방식) -> 교육 데이터의 최대값에서 범주를 추론합니다.

질문은 다음과 같습니다. 두 경우 모두 지원할 가치가 있습니까? 따라서 잠재적으로 병합된 OneHotEncoder에서 둘 다 수행할 수 있는 기능을 유지합니까, 아니면 서수 입력을 처리하는 기능을 완전히 사용하지 않고 제거합니까?

둘 다 처리할 수 있는 기능을 원하면 부울 키워드를 추가하여 입력 데이터 유형을 지정할 수 있습니다(지금은 encoded_input=False/True 을 사용하지만 다른 아이디어는 ordinal_input , ...)

비추천 기간 동안, 우리는 어쨌든 둘 다 지원해야 하고, 또한 동작을 선택하기 위해 키워드를 도입해야 합니다(경고를 없애고 새로운 동작을 선택할 수 있도록).
따라서 원칙적으로 키워드를 나중에 유지할 수 있습니다.

둘 다 처리하고 싶다는 점을 감안할 때 OneHotEncoder의 작동 방식에 대한 개요는 다음과 같습니다.

• 현재 encoded_input=None 이며 데이터를 기반으로 기본값을 추론합니다.
• int-like 데이터(이전에 OneHotEncoder에서 처리됨) encoded_input 가 내부적으로 True로 설정되고 사용 중단 경고가 발생하는 경우. 사용자가 현재 동작을 유지하려는 경우 수동으로 OneHotEncoder(encoded_input=True) 로 지정하여 경고를 끌 수 있습니다.
• 입력이 int와 같지 않으면 내부적으로 encoded_input 를 False로 설정하고 경고 없이 새 동작(= 현재 CategoricalEncoder 동작)을 사용합니다.
• 미래에 우리는 encoded_input 기본값을 None에서 False로 변경합니다(기본적으로 새로운 동작, int류 데이터에도 적용)

나는 여전히 당신이 제안하는 것이 최대 값에서 범주를 추론하기 때문에 실질적인 차이인지 확실하지 않습니다.

@jnothman 연습에 차이가 있을 수 있다는 점을 알고 계시나요 ? (가지고 있는 데이터에 따라 얻을 수 있는 출력)

그러나 이 차이가 실제로 중요한지 여부는 모르겠습니다. 그곳에서 피드백을 보고 싶습니다. 누군가가 실제로 이 "최대값" 기반 방법을 원하는지 , 아니면 "고유한 값" 기반 방법만 갖는 것이 좋은지(향후 사용 중단 후) 여부.

나는 개인적으로 이 최대값 기반 방법이 절대 필요하지 않을 것이라고 생각하지만 OneHotEncoder는 수년 동안 (합당한 이유가 있든 없든) 그렇게 되어 왔습니다.

실제로 최대값 기반 범주화를 중단하면 구현(지원 중단 후)이 더 간단해집니다.
그리고 우리가 그 경로를 선택한다면 옵션이 encoded_input / ordinal_input 가 아니라 legacy_mode=True/False 여야 한다는 데 동의합니다.

n_values='auto'일 때 출력의 실제 차이가 무엇인지 상기시켜 주십시오.
제발? 나는 active_features_가 그것들을 기본적으로 만들었다고 생각했습니다.
동일하지만 아마도 뭔가를 잊고 있을 것입니다.

아하, 오해가 풀렸습니다 :-)
현재 OneHotEncoder가 실제로 어떻게 작동하는지 잘못 이해했습니다. 값이 [2, 3, 5, 2]인 특성이 하나 있다고 가정합니다. 현재 OneHotEncoder에는 [0, 1, 2, 3, 4, 5] 범주가 있다고 생각했습니다(현재 CategoricalEncoder에는 범주 [2, 3, 5]). 그러나 active_features_ 도 [2, 3, 5]일 뿐이며 기본적으로 n_values='auto' 의 기본값과 동일하게 만드는 것이 맞습니다.

따라서 n_values 정수를 전달하는 경우(위의 경우 category=[0, 1, 2, 3, 4, 5]의 경우 n_values=6 ) 실제로 API 변경이 될 카테고리의 수(더 이상 사용되지 않음/제거됨).
그리고 categories=range(6) 사용자가 쉽게 교체할 수 있습니다.

혼란을 드려 죄송합니다.
그런 점에서 우리는 legacy_mode 옵션조차 필요하지 않다고 생각합니다. 내부적으로 n_values=6 를 categories=range(6) 하고 이에 대한 경고를 표시할 수 있습니다(하지만 실제 테스트에서 이를 확인해야 함).

다른 차이점은 보이지 않는 범주를 처리하는 것입니다. OneHotEncoder의 현재 동작으로, 보이지 않는 값이 범위(0, max) 내에 있으면 handle_unknow='error' (기본값)이더라도 오류가 발생하지 않습니다. 그러나 기존 동작을 유지하려면 사용자가 수동으로 handle_unknown='ignore' 설정해야 한다는 경고를 표시하여 별도로 해결할 수도 있습니다.

우리가 놓칠 수 있는 유일한 기능은 범위(0, max)(현재 OneHotEncoder에서는 '알 수 없음'으로 간주되지 않음) 내에 있는 알 수 없는 범주와 그보다 큰 범주(> max, 현재 이미 간주되고 있음) 간의 구별입니다. OneHotEncoder에서 알 수 없음).

아니요, 그것은 우리가 전에 시도한 종류의 것입니다.
까다롭게. 현재 행동을 유지할 합당한 이유가 없는 한,
우리를 천천히 미래로 데려가려면 legacy_mode가 있어야 합니다.

아니요, 그것은 우리가 이전에 시도한 종류이며 너무 까다롭습니다.

이 "아니오"가 어떤 측면을 의미하는지 명확히 할 수 있습니까?
내가 생각하기에 legacy_mode 는 필요없다고?

네, 거꾸로 된 무언가를 만들 수 있다는 생각으로
호환 가능하고 앞으로 우리가 원하는 것

네, 이전 버전과 호환 가능하고 앞으로 우리가 원하는 것을 만들 수 있다는 생각에

그것은 내가 제안하려고 한 것이 아닙니다. 나는 legacy_mode 키워드가 없는 것이 가능하다고 생각한다는 것을 분명히 하고 싶었습니다. 마술처럼 역방향과 우리가 원하는 것과 호환되도록 하는 것이 아니라 기존 키워드의 동작을 더 이상 사용하지 않는 것입니다.

구체적으로 말하자면 n_values 의 기본값이 아닌 값은 더 이상 사용되지 않을 수 있으며 categories 사양으로 대체되어야 합니다. handle_unknow 정수 데이터의 경우 현재 혼합 대신 전체 무시 또는 전체 오류를 선택하도록 사용자가 명시적으로 설정해야 합니다(그렇지 않으면 사용 중단 경고가 발생함).

그래서 내가 .fit([[5]]).transform([[4]]) 하면 n_values의 값은,
category 및 handle_umknown 오류가 발생합니까?

2018년 1월 25일 오전 9시 32분, "Joris Van den Bossche" [email protected]
썼다:

네, 거꾸로 된 무언가를 만들 수 있다는 생각으로
호환 가능하고 앞으로 우리가 원하는 것

그것은 내가 제안하려고 한 것이 아닙니다. 나는 그것을 생각한다는 것을 분명히하고 싶었습니다.
마법처럼 가짐으로써가 아니라 legacy_mode 키워드를 갖지 않을 수 있습니다.
이전 버전과의 호환성과 우리가 미래에 원하는 것 모두
기존 키워드의 동작.

구체적으로 말하자면 기본값이 아닌 n_values ​​값은 더 이상 사용되지 않으며
범주 사양으로 대체되어야 합니다. 핸들_알 수 없는 경우
정수 데이터는 사용자가 명시적으로 설정하여 전체
현재 혼합 대신에 무시 또는 전체 오류 발생(그렇지 않으면 비추천
경고가 발생함).

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/scikit-learn/scikit-learn/issues/10521#issuecomment-360296569 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAEz6-DrQWep22_gs-hg9cC0u19B1_PSks5tN6-HgaJpZM4RpUE8
.

더 이상 사용되지 않는 동안 범주를 설정해야 하도록 만들 수 있습니까?
명시적으로 경고가 있는 레거시 모드가 적용됩니까? 그거야?
당신이 제안하는 것은 무엇입니까?

지원 중단 중에 카테고리를 명시적으로 설정해야 하고 경고가 있는 레거시 모드가 적용되도록 만들 수 있습니까? 그것이 당신이 제안하는 것입니까?

예, 여전히 누락된 케이스일 수 있지만 이것이 가능 하다고 생각 합니다(다음 주에 실제 코딩하여 확인할 것입니다).

다양한 '레거시' 사례:

• n_values='자동'(기본값)
  
  
  
  • handle_unknown='무시' -> 괜찮음, 동작에 변화 없음
  
  
  • handle_unknown='error' -> 문제, 범위의 값은 여전히 ​​무시되고 범위를 초과하는 값은 오류입니다.
    
    
    
    
    
    • 가능한 해결책:
      
      
      
      
      
      
      
      • 범위가 연속적이면 => 괜찮음, 동작에 변화가 없음
      
      
      
      
      • 그렇지 않은 경우: 이 동작을 유지하고 내부적으로 레거시 모드를 사용하려면 카테고리를 명시적으로 설정해야 한다는 비추천 경고 발생
      
      
      
      
    
    
    
  
  
• n_values=값
  
  
  
  • 이것은 내부적으로 category=[range(value)]로 변환될 수 있으며, 사용자가 나중에 직접 해야 한다는 비추천 경고를 발생시킵니다.
  
  
  • 이 경우 handle_unknown='error' / 'ignore' 는 예상대로 작동합니다.
  
  

경우에 중단 경고 n_values='auto' 만에 인상 될 것입니다 fit (정말 적합하지 않습니다)하지 건설에 있지만, 우리는 사용자가 그것을 전달하고 있는지 알고에만 적합에 문자열 데이터가 아닌 숫자 데이터입니다.

우리는 일반적으로 어떤 경우에도 적합할 때까지 경고를 발생시키지 않으므로 걱정하지 마십시오.
저것.

그 전략은 대부분 좋은 것 같습니다.

실제로 데이터의 문자열을 스니핑해야 하는지 확실하지 않습니다.
그렇지만. 기본적으로 다음과 같이 하고 싶습니다. 카테고리가 다음과 같은 경우 레거시 모드가 활성화됩니다.
설정되지 않은 데이터는 모두 정수의 경우?

한 가지 질문: 범주 및 n_values ​​매개변수가 기본값인 경우 다음을 수행하십시오.
우리는 카테고리를 게시합니다_? n_values가 명시적으로 설정된 경우 게시합니까?
카테고리_?

2018년 1월 29일 오전 10시 "Joris Van den Bossche" 알림 @github.com
썼다:

더 이상 사용되지 않는 동안 범주를 설정해야 하도록 만들 수 있습니까?
명시적으로 경고가 있는 레거시 모드가 적용됩니까? 그거야?
당신이 제안하는 것은 무엇입니까?

예, 여전히 누락된 케이스일 수 있지만 이것이 가능 하다고 생각 합니다.
다음주 실제 코딩으로 확인).

다양한 '레거시' 사례:

• n_values='자동'(기본값)
  
  
  
  • handle_unknown='무시' -> 괜찮음, 동작에 변화 없음
  
  
  • handle_unknown='오류' -> 문제, 범위의 값이 여전히
    
    무시됨, 범위 초과 값 오류
    
    
    
    
    
    • 가능한 해결책:
      
      
      
      
      
      
      
      • 적합, 범위가 연속적이면 => 양호, 변경 없음
        
        
        
        행동(이제 LabelEncoder를 결합한 모든 사람들을 위해, 이는
        
        
        
        내가 생각하는 전형적인 사용 사례)
      
      
      
      
      • 그렇지 않은 경우: 사용 중단 경고 발생
        
        
        
        그들은 이 행동을 유지하기 위해 카테고리를 명시적으로 설정해야 합니다(그리고
        
        
        
        내부적으로 레거시 모드 사용)
      
      
      
      
    
    
    
    • n_values=값
    
    
    
  
  
  • 이것은 내부적으로 category=[range(value)]로 변환될 수 있습니다.
    
    사용자가 직접 해야 한다는 비추천 경고를 제기합니다.
    
    미래
  
  
  • 이 경우 handle_unknown='error' / 'ignore'가 예상대로 작동합니다.
  
  

n_values='auto'인 경우 사용 중단 경고는 다음에서만 발생합니다.
적합하고 건설 시에는 적합하지 않지만(실제로 이상적이지는 않음)
사용자가 문자열이 아닌 숫자 데이터를 전달한다는 것을 알고 있습니다.
데이터.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/scikit-learn/scikit-learn/issues/10521#issuecomment-361104495 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAEz6x8xnyZXBLij-DCC45JyYNf8pA5kks5tPPwXgaJpZM4RpUE8
.

당신은 기본적으로이 원하는 : 레거시 모드는 데이터가 모든 정수의 경우 범주가 설정되지 않은 경우 활성화 및?

그렇습니다(실제로는 거의 같을 것입니다)

한 가지 질문: category와 n_values ​​매개변수가 기본값인 경우 category_를 게시합니까? n_values가 명시적으로 설정된 경우 category_를 게시합니까?

나는 개인적으로 이미 레거시 모드에서도 새 인터페이스의 속성을 가능한 한 많이 제공할 것입니다. 따라서 두 경우 모두 categories_ 계산합니다(조금 더 많은 작업이 필요하더라도)

그래서 위의 논리를 코드에 넣으려고 했고(PR에 대한 일부 업데이트를 푸시함) n_values 또는 categories 가 설정되지 않은 경우 정수 데이터의 경우에 대해 한 가지 더 질문이 있습니다( 'legacy_mode'의 일반적인 경우). 문제는 추론된 범주가 단순히 연속적인 범위(0, 1, 2, 3, ... max)인 경우 새 동작과 이전(레거시) 동작 간에 차이가 없으며 우리는 그렇지 않다는 사실에 있습니다. 반드시 사용 중단 경고를 제기해야 합니다.
이 특정 경우에 수행할 수 있는 몇 가지 가능성:

1) 이 경우(추론된 범주가 연속 범위임)를 감지하고 이 경우 경고를 발생시키지 마십시오.
- 우리가 이미 적합하기 때문에 (조금의 추가 코드 복잡성으로) 감지할 수 있습니다.
- 정수 데이터로 OneHotEncoder를 사용하는 경우가 일반적인 경우 라고 생각 하며, 실제로 사용자가 우리의 리팩토링에 대해 걱정할 필요가 없는 경우이므로 경고로 사용자를 귀찮게 하지 않는 것이 좋을 것입니다.
2) 항상 경고를 표시하고 경고 메시지에 이러한 경우에 수행할 작업을 표시합니다(연속 범위가 없는 경우 수행할 설명과 함께):
- 범주로 연속 범위만 있다는 것을 알고 있는 경우 경고를 무시하기를 원하므로 경고 메시지에 이를 수행하는 방법에 대한 설명을 추가할 수 있습니다(필터 경고와 함께 코드 샘플 추가, 복사 붙여넣기)
- 이것의 잠재적인 이점은 LabelEncoder를 사용하여 정수를 생성한 경우 이제 OneHotEncoder를 직접 사용할 수 있다는 경고 메시지를 추가할 수 있다는 것입니다(현재 이것이 일반적인 사용 패턴이라고 생각합니다). 그렇게하면 경고도 사라집니다
3) 항상 경고를 발생시키되 경고를 침묵시키는 키워드를 제공하십시오(예: legacy_mode=False ).
- filterwarnings 문을 사용하라는 조언(위의 2번 항목 참조)이 너무 번거롭다면 키워드를 추가하여 동일한 결과를 얻을 수도 있습니다.
- 이것의 단점은 사용 중단이 정리될 때 몇 가지 릴리스에서 더 이상 필요하지 않은 키워드를 도입한다는 것입니다.

저는 개인적으로 옵션 1 또는 2에 찬성합니다. OneHotEncoder 전에 LabelEncoder를 사용하는 것이 일반적인 패턴인 것 같습니다(빠른 github 검색에서). 이 경우 항상 연속 범위가 있으며 새로운 구현이므로 경고하지 않아야 합니다. 다른 한편으로, 우리가 경고 경우 우리는 그들이 LabelEncoder를 사용하는 경우, 그들은 더 이상 필요가 그것을 할 수 있다는 사실을 가리킬 수 있습니다. 실제로 이 조언을 명시적으로 제공하는 것이 좋습니다.
문제는 사용자가 이전 단계에서 LabelEncoder를 사용하지 않고 범주와 같은 연속적인 정수를 얼마나 자주 사용하는지입니다.

흠, 내가 잊은 한 가지 경우는 연속적 이지 않은 정수 추론 범주(예: [1,3,5])가 있지만 레거시 동작이 아닌 새로운 동작을 원할 때입니다(이 경우 경고를 무시할 수 없습니다. , 변환 단계에서 보이지 않는 값을 다르게 처리하므로 범위(예: 2) 사이의 값은 오류를 발생시키지 않습니다.
legacy_mode=False 키워드를 제공하지 않는 경우 새 동작을 얻을 수 있는 유일한 방법은 categories=[1,3,5] 를 수동으로 전달하는 것이므로 약간 불편할 수 있습니다. 이것이 옵션 3을 선호하고 임시 키워드 legacy_mode=False 도입에 대한 내 이의를 포기하는 이유일 수 있습니다. 필요)

* 이 경우만 = 연속 범위가 아닌 추론된 범주가 있는 정수 데이터, 범주를 수동으로 설정하거나 handle_unknown을 무시하도록 설정할 수 없거나 원하지 않는 경우.

긴 텍스트에 대해 죄송하지만 상당히 복잡합니다. :)

우리는 n_values가 설정되지 않은 경우에 대해서만 이야기하고 있는 것입니다. 맞습니까?

나는 1로 괜찮습니다. 그리고 그것은 더 이상 비싸지 않을 것입니다.
이미 레이블 집합을 검사해야 합니다. 나는 또한 받아들일 수 있었다,
단순성, 3의 변형입니다. 그것은 "레거시에서 실행되는 OneHotEncoder
방법. 없이 약간 다른 동작에 대해 category='auto'로 설정하십시오.
경고."

우리는 n_values가 설정되지 않은 경우에 대해서만 이야기하고 있는 것입니다. 맞습니까?

예(다른 경우에는 해당하는 categories 값으로 쉽게 변환되고, 좋은 사용 중단 경고와 함께 새 동작과 레거시 동작이 다르지 않음)

3의 변형은 "레거시 모드에서 실행 중인 OneHotEncoder입니다. 경고 없이 약간 다른 동작에 대해 범주를 '자동'으로 설정합니다."

아, 좋은 생각이군요! (연속된 범주의 경우를 감지하는지 여부에 관계없이). 그래서 우리는 코드에서 categories 의 기본값을 None으로 설정했습니다(기본값의 의미를 변경하지 않고), 그래서 우리는 사용자가 그것을 명시적으로 설정했는지 알 수 있고, 그런 식으로 legacy_mode=False 를 나타내는 좋은 방법입니다 추가 키워드 없이

예, 하지만 누군가 통과하지 않고 사용할 때마다 경고하려는 경우에만
카테고리. 저렴한 구현 방식이지만
사용자에게 불필요하게 장황하므로 1을 선호합니다.
간단하게 할 수 있습니다.

이 얼마나 신선한 지옥입니까 :-/

또는 새로운 이름을 DummyEncoder ;) (DummyClassifier와 약간 충돌하지만)

@amueller 위의 내용을 모두 읽지 마십시오!
나는 단지 이 문제의 새로운 독자들을 위해 멋진 요약을 할 계획이었습니다. 위의 논의는 지나치게 복잡합니다 (또한 OneHotEncoder의 현재 복잡한 동작을 아직 완전히 이해하지 못했기 때문에 ... :-))

또는 새 이름을 DummyEncoder로 지정할 수 있습니다.)

"one-hot"이 더 많은 분야에서 알려져 있기 때문에 @GaelVaroquaux 가 반대했다고 생각합니다.

이름 지정의 일관성을 위해 이 작업을 다시 수행하는 것은 가치가 없습니다. 우리는 어디에서나 명명에 일관성이 없습니다. 이에 대한 논의를 요약할 수 있습니까?

나는 "더미"가 통계학자가 사용하는 것이고 팬더가 사용하는 것이라고 생각합니다.

맨 위 게시물은 여전히 ​​정확하고 읽을 가치가 있으며, CategoricalEncoder를 유지하지 않는 이유를 요약합니다(즉, DummyEncoder 대신 OneHotEncoder를 사용해야 한다는 의미는 아닙니다. 별도의 질문입니다)

윗글 잘 읽었습니다. 이것이 내가 "일관성을 위해 이것을 다시 하는 것은 가치가 없다"고 말했을 때 언급한 것입니다.

열린 문제

당신은 그것을 설명할 수 있습니까?

"일관성을 위해 이 작업을 다시 수행하는 것은 가치가 없습니다"

일관성을 가지고 "무엇을 수용하는가"와 "무엇을 하는가"의 명명 체계를 가리키고 있습니까? 그렇다면 그것은 사소한 이유에 불과했습니다. 나에게 그것은 주로 단일 클래스에 더 많은 기능을 추가할 때 확장성의 문제입니다.

열린 문제

누락된 값을 처리하는 방법에 대한 문제가 있었습니다(https://github.com/scikit-learn/scikit-learn/issues/10465). 이를 위해 서수 및 원 핫 인코딩(또는 그렇지 않은 경우)에 대해 다른 동작을 원할 수 있습니다. 모든 옵션은 둘 다에 대해 유효합니다. ..). 우리는 이미 기존 handle_unknown 가지고 있으며 이는 서수에는 적용되지 않고 원-핫 인코딩에만 관련이 있습니다. 그리고 onehot 인코딩에 대한 기능 가중치에 대한 https://github.com/scikit-learn/scikit-learn/issues/10518이 있었지만 서수와도 관련이 없었습니다(결국 이 문제는 문제가 아니었습니다. ColumnTransformer transformer_weights 인수로 가중치 부여). 또한 원-핫에 drop_first 와 같은 것을 추가하라는 기능 요청도 있습니다. 이는 다시 서수 인코딩과 관련이 없습니다.

제안된 변경 사항이 누락된 값에 얼마나 도움이 될지 모르겠습니다. 그리고 호환되지 않는 옵션을 갖는 것은 scikit-learn에서 자주 발생하는 일입니다. 이상적이지는 않지만 큰 문제는 아닙니다.

제안된 변경 사항이 누락된 값에 얼마나 도움이 될지 모르겠습니다.

이 같은 도움이되지 않습니다, 그러나 덜 복잡 특히 다른 인코딩 유형에 맞는 특정 옵션을 가지고 있습니다.

그리고 호환되지 않는 옵션을 갖는 것은 scikit-learn에서 자주 발생하는 일입니다. 이상적이지는 않지만 큰 문제는 아닙니다.

현재로서는 확실히 괜찮습니다. 호환되지 않는 옵션이 너무 많지 않습니다(하지만 부분적으로는 sparse=True/False 를 encoding 옵션으로 옮겼기 때문이기도 합니다). 그러나 문제는 미래에 scikit-learn에서 인코딩 기능을 어느 정도로 확장하기를 원하는지입니다. 물론 지금 대답 하기 어려운 질문 입니다 .
우리는 이미 '단항 인코딩'에 대한 PR을 가지고 있습니다. 새 클래스 UnaryEncoder를 추가하는 대신 CategoricalEncoder에 추가해야 하지 않습니까? 누군가 '바이너리 인코딩'을 추가하고 싶다면 어떻게 해야 할까요? 또는 '(평균) 대상 인코더'?

"평균 대상 인코더"는 CountTransformer 이고 이에 대한 PR이 있습니다.)

그것에 대한 링크가 있습니까? "CountTransformer"를 검색해도 결과가 표시되지 않습니다.

죄송합니다, CountFeaturer #9614

확실히 관련이 있지만 정확히 의미있는 대상 인코딩은 아닙니다. 또한 대체가 아닌 열을 추가하므로 문자열 범주형 데이터에 대해 기본적으로 작동하지 않습니다(하지만 이는 해당 PR에 대한 더 많은 피드백이며 여기에서 논의하지 않음).

대상 인코딩을 의미하지 않는 이유는 무엇입니까? 하지만 여기에서 너무 많이 우회하지 말자 ;)

따라서 우리가 대답해야 하는 실제 질문의 요약으로 (이 순서로!):

1. 현재 CategoricalEncoder 합니까? 그렇지 않은 경우 아이디어는 각 인코딩 유형(현재 'onehot' 및 'ordinal' 인코딩)에 대해 하나의 클래스인 다른 클래스로 분할하는 것입니다.

2. 여러 클래스로 분할하면 'onehot' 인코딩에 OneHotEncoder를 사용할 수 있지만(이상적으로는?) 이 클래스는 이미 존재합니다. 그렇다면 기존 OneHotEncoder 클래스에 새로운 'onehot' 인코딩(문자열을 지원하고 다른 매개변수를 가짐)을 통합합니까? 아니면 다른 이름을 선택합니까? (예: DummyEncoder)

3. 기존 OneHotEncoder에 통합하기로 선택하면 다음과 같은 결과가 발생해도 괜찮습니까? OneHotEncoder의 여러 키워드/속성을 더 이상 사용하지 않으며 특정 사용 사례(보이는 값 범위 내에서 보이지 않는 값을 자동으로 무시)는 불가능합니다. 더 이상 사용 중단 기간 이후.

위의 논의의 대부분은 질문 3(CategoricalEncoder(encoding='onehot')을 OneHotEncoder에 통합하는 방법에 대한 복잡한 세부 사항)에 관한 것입니다. 그러나 먼저 처음 2개의 질문에 대한 결정에 동의합시다.

나에게 또 다른 요인은 모든 사람들이 현재 자동 모드를
OneHotEncoder가 이상합니다. coo를 csr로 변환하는 구현도
기이 한. 재설계할 가치가 있습니다. 그리고 사람들에게 "당신이 하나의 뜨거운
문자열을 인코딩하려면 대신 CategoricalEncoder로 이동하십시오."는 OHE 때문에 어색합니다.
은(는) 이미 범주형을 위한 것입니다...

흠. OneHotEncoder는 사용할 수 있을 때 더 효율적이기 때문에 유지한 것 같습니다. 이상적으로는 모든 이상한 동작을 제거하는 것입니다. 나는 그것을 비추천하고 싶었지만 우리는하지 않았습니다 ...

나는 그것을 비추천하고 싶었지만 우리는하지 않았습니다 ...

내 POC PR(https://github.com/scikit-learn/scikit-learn/pull/10523)에서 이름을 제외하고 OneHotEncoder의 거의 모든 것을 더 이상 사용하지 않습니다...

훨씬 더 효율적이지 않습니다. LabelEncoder에 int에 대한 빠른 경로가 있는 경우
[0, n_values-1] 범위에서 정당화된다면 충분할 것입니다.

@amueller , 인코딩에 따라 궁극적으로 다른 추가 매개변수(예: drop_first, nan 처리)가 필요하고 각 인코딩 형식에 대해 다른 개별 인코더를 갖는 것이 정당화된다는 문제에 설득되었습니까?

2주뒤에 봄방학때 이걸 보려고 노력할게, 알았지? 그 전에 시간이 있을지 모르겠지만 :-/

이것이 잘못된 질문이 아니기를 바랍니다. 그러나 현재 구현은 한 열 내에서 범주형과 비범주형이 혼합된 테이블로 무엇을 합니까? https://github.com/pandas-dev/pandas/issues/17418 에서 예제 가져오기

다음과 같은 데이터 프레임 df = pd.DataFrame([{'apple': 1, 'pear':'a', 'carrot': 1}, {'apple':'a', 'pear':2, 'carrot':3}, {'apple': 2, 'pear':3, 'carrot':1}, {'apple': 3, 'pear':'b', 'carrot': 1}, {'apple': 4, 'pear':4, 'carrot': 1}]) 을 고려하십시오.

  apple  carrot pear
0     1       1    a
1     a       3    2
2     2       1    3
3     3       1    b
4     4       1    4

DictVectorizer는 이 경우에 내가 필요한 것을 정확히 제공합니다.

    from sklearn.feature_extraction import DictVectorizer
    enc = DictVectorizer(sparse = False)
    enc.fit_transform(df.to_dict(orient='r'))

이것은 다음을 제공합니다.

array([[ 1.,  0.,  1.,  0.,  1.,  0.],
       [ 0.,  1.,  3.,  2.,  0.,  0.],
       [ 2.,  0.,  1.,  3.,  0.,  0.],
       [ 3.,  0.,  1.,  0.,  0.,  1.],
       [ 4.,  0.,  1.,  4.,  0.,  0.]])

다음을 사용하여 열의 기능 이름을 볼 수 있습니다.

    enc.feature_names_
    ['apple', 'apple=a', 'carrot', 'pear', 'pear=a', 'pear=b']

새 CategoricalEncoder에 동일한 옵션이 있으면 좋을 것입니다.

나는 우리가 그런 종류의 혼합 사례를 다룰 생각이 없다고 생각합니다.

그건 부끄러운 일이야. 한 가지 간단한 하위 사례는 열이 숫자이지만 일부 누락된 값이 있는 경우입니다. 간단한 해결책은 NaN을 빈 문자열로 변환한 다음 위의 예에서와 같이 DictVectorizer를 사용하는 것입니다. 이렇게 하면 값이 누락된 경우에 대한 새 기능이 효과적으로 생성되지만 그렇지 않은 경우 숫자 값이 변경되지 않은 상태로 유지됩니다. 나는 이것이 매우 유용한 기술임을 발견했습니다.

새로운 CategoricalEncoder가 비슷한 작업을 수행할 수 있습니까?

우리는 사용자가 NaN을 별도의 카테고리로 취급하도록 허용하는 것을 고려했습니다.
또는 유사. 그러나 이는 임의의 숫자 값을 다음과 같이 처리하는 것과는 다릅니다.
문자열과 다릅니다.

그 좋은 소리.

두 가지 사용 사례가 있습니다. 숫자 값을 문자열과 다르게 처리하는 것이 유용한 특정 예를 설명하겠습니다. 더 나은 솔루션이 있을 수 있습니다.

큰 범위의 값을 취하는 정수 숫자 기능이 있다고 가정해 보겠습니다. 그러나 일부 작은 값의 경우 정확한 값이 중요하다고 생각합니다. 더 큰 값의 경우 그렇지 않은 것으로 의심됩니다. 간단한 작업은 모든 작은 값을 문자열로 변환하고 위와 같이 DictVectorizer를 실행한 다음 기능 선택을 수행하거나 선호하는 분류기를 직접 사용하는 것입니다.

그래서 당신은 그것을 비선형 이산화에 사용하고 있습니까? 다음 릴리스는
고정 너비 이산화기를 포함할 가능성이 있지만 로그에서 계속
변환 또는 분위수 변환은 사용자가 수행하는 것과 매우 유사하게 작동해야 합니다.
원하는... 하지만 로그 변환만으로도 설정에 충분할 수 있습니다.

2018년 2월 25일 18시 10분에 lesshaste [email protected]에서 다음과 같이 썼습니다.

그 좋은 소리.

두 가지 사용 사례가 있습니다. 특정 예를 설명하겠습니다
숫자 값을 문자열과 다른 것으로 처리하는 것이 유용한 경우
나를위한. 더 나은 솔루션이 있을 수 있습니다.

큰 범위를 취하는 정수 숫자 기능이 있다고 가정해 보겠습니다.
가치. 그러나 일부 작은 값의 경우 정확한 값이
중요하다. 더 큰 값의 경우 그렇지 않은 것으로 의심됩니다. 간단한
해야 할 일은 모든 작은 값을 문자열로 변환하고 DictVectorizer를 실행하는 것입니다.
위와 같이 선택한 다음 기능 선택을 수행하거나 좋아하는 것을 사용하십시오.
직접 분류기.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/scikit-learn/scikit-learn/issues/10521#issuecomment-368288727 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAEz60cmjwlDVKGyXc6oPyIC9oLbptSgks5tYQdvgaJpZM4RpUE8
.

@jnothman 트위스트를 제외하고는 어떤 의미

제네릭에 대한 변수에 대해 너무 많이 알고 있는 것 같습니다.
필요한 종류로 변환하십시오.

2018년 2월 25일 20시 37분에 lesshaste [email protected]에서 다음과 같이 썼습니다.

@jnothman https://github.com/jnothman
트위스트. 1...1024의 값 중 일부가 의미가 있다고 생각한다고 가정해 보겠습니다.
즉 22는 21과 상당히 다른 특정한 것을 나타냅니다.

1. 여기서 로그를 가져오는 것은 도움이 되지 않습니다. 하지만 나는 모든 가치를 떠나고 싶어
   1024 숫자만큼은 그 특정 값이 큰 의미가 없다고 생각합니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/scikit-learn/scikit-learn/issues/10521#issuecomment-368295895 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAEz65bOdVB6k7rCAcgLBYz_NslxXWV0ks5tYSnggaJpZM4RpUE8
.

@jnothman 좀 더 명확하게 일부 값이 있다고 생각하지만

@lesshaste NaN을 별도의 카테고리로 분류하는 문제는 https://github.com/scikit-learn/scikit-learn/issues/10465를 참조
특정 비선형 이산화 또는 혼합 숫자/문자열 인코딩에 대해 더 자세히 논의하려면 자유롭게 새 문제를 여십시오. 그러나 이 문제는 원래 문제, 즉 CategoricalEncoder/OneHotEncoder의 다른 클래스에서 명명 및 구성에 초점을 맞추고 싶습니다.

2주뒤에 봄방학때 이걸 보려고 노력할게, 알았지? 그 전에 시간이 있을지 모르겠지만 :-/

@amueller 괜찮습니다. 어쨌든 이것에 의해 차단된 PR에 대해 앞으로 2주 동안 작업할 시간이 없을 것입니다. 그 후에는 다시 작업할 시간을 가져야 합니다.

@amueller 시간이 있었나요?

@amueller 내가 OrdinalEncoder와 OneHotEncoder에서 CategoricalEncoder를 분할하기 위한 PR 작업을 진행하는 것에 대해 괜찮습니까?

결석해서 죄송합니다. 괜찮아 보이지만 실제로 검토할 수 있도록 2주를 주실 수 있습니까? 감사 해요!

@amueller 문제 없습니다. 저에게도 마찬가지입니다 :-)
하지만, 나는 지금 이것을 다시 볼 계획이다. 그래서 당신이 이것을 볼 수 있다면 그것은 환영받을 것입니다. PR(https://github.com/scikit-learn/scikit-learn/pull/10523)에 대해 해야 할 일이 있으므로 아직 자세히 검토하지 마십시오. 그러나 우리가 제안하는 것).
많은 시간을 들이기 전에 답변을 보고 싶은 주요 질문은 CategoricalEncoder를 여러 클래스로 분할해도 괜찮은지, 그리고 이 경우 OneHotEncoder를 재사용해도 괜찮은지(즉, 현재 (이상한) 기능 중 일부를 더 이상 사용하지 않음). 해당 질문은 https://github.com/scikit-learn/scikit-learn/issues/10521#issuecomment -363851328 및 https://github.com/scikit-learn/scikit-learn/issues/10521#issuecomment에 요약되어

(그리고 일단 그 부분에 동의하면 PR에서 실제 구현에 대해 논의할 것이 여전히 많습니다 :))

PR을 업데이트했습니다 https://github.com/scikit-learn/scikit-learn/pull/10523 , 검토 준비

조심스럽게 돌아오겠습니다 ;)

IMHO에서 가장 중요한 것은 우리가 논의하는 모든 인코더에 대한 범용 API(예: 매개변수 및 동작 패턴)입니다.

추신 https://github.com/scikit-learn-contrib/categorical-encoding ?

category_encoders 패키지에서 모든 인코더에는 이전 OneHotEncoder의 categorical_features 와 유사한 cols 인수가 있습니다(정확히 같은 종류의 값을 허용하지는 않지만). 예를 들어 http://contrib.scikit-learn.org/categorical-encoding/onehot.html을 참조하십시오
이는 https://github.com/scikit-learn/scikit-learn/pull/10523 에서 categorical_features 사용 중단 여부에 대한 현재 논의와 관련이 있습니다.

나머지는 실제로 충돌하는 키워드가 없다고 생각합니다(이 시점에서 sklearn에 추가하지 않을 데이터 프레임에 특정한 다른 키워드가 있음). OneHotEncoder 및 OrdinalEncoder의 이름은 최소한 category_encoders 패키지와 일치합니다.