Scikit-learn: 제안: plot_confusion_matrix에서 예측을 제거하고 예측된 레이블만 전달

우리는 확실히 하위 호환성을 유지해야 하지만 y_pred 키워드 arg를 추가하는 것이 합리적으로 들립니다. y_pred가 전달되었지만 X 또는 estimator도 전달되면 오류가 발생해야 합니다.

@jhennrich PR을 제출하시겠습니까?

PR을 제출했는데 현재 CI에 문제가 있는 것 같아서 아직 통과되지 않았습니다.

여러 번 예측을 계산하지 않도록 plot_XXX(y_true, y_pred) 를 지원해야 한다는 데 동의합니다.
plot_roc_curve 및 plot_precision_recall_curve에서도 유사한 문제가 있습니다.
y_pred를 추가하는 것은 괜찮은 것 같지만 솔직히 좋은 해결책은 아니라고 생각합니다.
**kwargs를 허용하는 함수(예: plot_precision_recall_curve)의 경우 이전 버전과의 호환성을 유지하는 것이 불가능한 것 같습니까?

이전 버전과의 호환성을 유지할 수 없는 이유는 무엇입니까? #15883의 제안이 괜찮은 것 같습니다.

이전 버전과의 호환성을 유지할 수 없는 이유는 무엇입니까? #15883의 제안이 괜찮은 것 같습니다.

우리는 plot_confusion_matrix에서 **kwargs를 지원하지 않기 때문입니다. @NicolasHug

콰르그가 왜 문제인가?

흠, 그래서 또 다른 성가신 것이 있습니다. 우리는 plot_roc_curve 및 plot_precision_recall_curve(및 plot_partial_dependence)에서 **kwargs를 지원하지만 plot_confusion_matrix에서는 지원하지 않습니다.

콰르그가 왜 문제인가?

**kwargs 앞에 새 매개변수를 추가하면 이전 버전과의 호환성을 유지할 수 있습니다. 그렇죠?

내 PR의 변경 사항은 이전 버전과 호환되며 **kwargs를 계속 추가할 수 있습니다. 하지만 @qinhanmin2014 에 동의합니다. 훨씬 깨끗한 솔루션은 estimator 및 X 버리고 대부분의 내용과 일치하는 위치 인수(y_true, y_pred, ...)를 사용하는 것입니다. 다른 sklearn 물건.

**kwargs 앞에 새 매개변수를 추가하면 이전 버전과의 호환성을 유지할 수 있습니다. 그렇죠?

예

훨씬 더 깨끗한 솔루션 ....

불행히도 그것은 사용 중단 주기가 필요합니다(버그 수정 릴리스에서 매우 빠르게 만들지 않는 한 하지만 의심스럽습니다...)

@thomasjpfan , 예측 대신에 추정기를 입력으로 전달해야 하는 이유가 있습니까?

감사합니다. 먼저 y_pred를 추가해 보겠습니다. **kwags는 또 다른 문제입니다.

불행히도 그것은 사용 중단 주기가 필요합니다(버그 수정 릴리스에서 매우 빠르게 만들지 않는 한 하지만 의심스럽습니다...)

불가능한 것 같아 한숨

@thomasjpfan , 예측 대신에 추정기를 입력으로 전달해야 하는 이유가 있습니까?

API 설계를 재고해야 한다는 데 동의합니다. @amueller 도 ping을 시도

사용자가 자신만의 플로팅 부분을 제공하고 자신만의 혼동 행렬을 제공하려는 경우:

from sklearn.metrics import ConfusionMatrixDisplay
confusion_matrix = confusion_matrix(...)
display_labels = [...]

disp = ConfusionMatrixDisplay(confusion_matrix=confusion_matrix,
                              display_labels=display_labels)
disp.plot(...)

이것은 다른 메트릭 플로팅 기능에 대해서도 유사하게 수행할 수 있습니다.

plot_confusion_matrix 는 추정기의 출력을 훌륭하게 처리할 수 있는 스코어러처럼 설계되었습니다. 즉, ConfusionMatrixDisplay 및 estimator와 상호작용하기 위한 편리한 wrapper입니다.

추정기를 먼저 수락하면 플로팅 기능에 대한 균일한 인터페이스가 생깁니다. 예를 들어, plot_partial_dependence 는 부분 종속 플롯을 생성하는 데 필요한 모든 계산을 수행하고 이를 PartialDependenceDisplay 합니다. 사용자는 여전히 PartialDependenceDisplay 직접 생성할 수 있지만 이 경우 더 많이 관여하게 됩니다.

비록 y_pred 가 confusion_matrix 직접 전달되고 유효성 검사를 처리하도록 하는 플로팅 기능과 관련된 메트릭으로 전달될 수 있도록 "빠른 경로"를 가질 수 있습니다.

PDP를 구축하는 데 필요한 예측 계산은 상당히 복잡합니다. 또한 이러한 예측은 일반적으로 예를 들어 스코어러 또는 메트릭에서 사용할 수 없습니다. PDP를 플로팅할 때만 유용합니다. 따라서 이 경우에는 plot_partial_dependence의 추정기만 허용하는 것이 합리적입니다.

혼동 행렬의 OTOH에서 예측은 실제로 est.predict(X) 입니다.

나는 우리가 여기에서 균일한 인터페이스를 원하지 않는다고 생각합니다. 이것은 2가지 매우 다른 입력 사용 사례입니다.

편집: 또한, 트리 기반 PDP는 예측이 전혀 필요하지 않습니다.

추정기 없이 마주하게 될 다른 것들이 있습니다. 예를 들어 plot_precision_recall_curve 가 y_pred 를 수락하는 경우 더 이상 유추할 수 없기 때문에 pos_label 가 필요합니다. 이 경우 PrecisionRecallDisplay 직접 사용하고 사용자가 플롯을 재구성하는 데 필요한 매개변수를 계산하도록 하고 싶습니다.

이것은 우리가 이 API로 어떤 종류의 질문에 대답하는지에 달려 있습니다. 현재 인터페이스는 추정기를 평가하는 것을 중심으로 회전하므로 추정기를 인수로 사용합니다. "이 훈련된 모델이 이 입력 데이터로 어떻게 작동합니까?"

y_pred, y_true 수락하면 이제 "이 메트릭이 이 데이터로 어떻게 작동합니까?"라는 질문이 생깁니다. 이 데이터는 모델에 의해 생성되거나 생성되지 않을 수 있습니다.

이 특정 경우 @jhennrich 에서 ConfusionMatrixDisplay를 직접 사용할 수 있다는 것이 사실입니다.

한 가지 단점은 기본값이 없기 때문에 display_labels 를 지정해야 한다는 것입니다.

@thomasjpfan 일반적으로 Display 개체에 합리적인 기본값을 제공하여 Display 개체를 직접 사용할 수 있다고 생각하십니까?

display_labels 와 같은 일부 매개변수의 경우 합리적인 기본값이 있습니다. 다른 Display 개체 매개변수도 적절한 기본값을 가질 수 있습니다. 일부 매개변수를 제공해야 합니다. 예를 들어, confusion_matrix 제공해야 ConfusionMatrixDisplay 또는 precision 및 recall 에 대해 PrecisionRecallDisplay .

이런 종류의 고전적인 패턴 중 하나는 다음을 정의하는 것입니다.

ConfusionMatrixDisplay.from_estimator(...)
ConfusionMatrixDisplay.from_predictions(...)

그러나 이것은 scikit-learn에 매우 관용적이지 않습니다.

헷갈리기 시작합니다. 현재 API의 목표는 사용자가 여러 번 플롯하려는 경우 여러 번 계산하는 것을 피하는 것이지만 y_true 및 y_pred를 허용하면 사용자가 여러 번 계산할 필요가 없습니까? (PDP에서는 상황이 다르다는 것을 알고 있습니다)

@jnothman 그 API는 꽤 멋져 보입니다!

@qinhanmin2014 estimator, X, y 또는 y_true, y_pred 하면 "여러 번 계산하지 않음" API를 충족하는 데 작동합니다. 두 경우 모두 혼동 행렬이 계산되어 Display 개체에 저장됩니다.

그들 사이의 차이점은 혼동 행렬의 계산이 시작되는 위치입니다. y_pred 전달을 추정기의 "미리 계산된" 값으로 생각할 수 있습니다.

그래서 y_true, y_pred 가 estimator, X, y (물론 PDP는 아님)보다 낫다고 생각합니다. 왜냐하면 때때로(종종?) 사용자는 예측을 플로팅할 뿐만 아니라 예측도 분석하기를 원하기 때문입니다. 현재 API를 사용하면 여러 번 예측을 계산해야 합니다.

메트릭의 경우 y_true, y_pred 보다 estimator, X, y y_true, y_pred 사용에 대한 선호도를 확인할 수 있습니다. 메트릭에 대한 플로팅이 y_true, y_pred 만 지원한다고 상상해 보세요.

est = # fit estimator

plot_partial_dependence(est, X, ...)

# if plot_confusion_matrix accepts `y_true, y_pred`
y_pred = est.predict(X)
plot_confusion_matrix(y_true, y_pred, ...)

# if plot_roc_curve supports `y_true, y_score`
y_score = est.predict_proba(X)[: , 1]
plot_roc_curve(y_true, y_score, ...)
plot_precision_recall_curve(y_true, y_score, ...)

현재 API는 다음과 같습니다.

est = # fit estimator
plot_partial_dependence(est, X, ...)
plot_confusion_matrix(est, X, y, ...)
plot_roc_curve(est, X, y, ...)

# this will call `predict_proba` again
plot_precision_recall_curve(est, X, y, ...)

두 가지 옵션을 모두 지원하는 API를 갖고 싶습니다(어쨌든).

메트릭의 경우 estimator, X, y보다 y_true, y_pred 사용에 대한 선호도를 볼 수 있습니다. 메트릭에 대한 플로팅이 y_true, y_pred만 지원한다고 상상해 보세요.

예, 이것이 제가 말하고자 하는 바입니다.

두 가지 옵션을 모두 지원하는 API를 갖고 싶습니다(어쨌든).

이것이 실용적인 해결책이라고 생각합니다. 성가신 일은 끝에 y_pred만 추가할 수 있다는 것입니다(즉, plot_confusion_matrix(estimator, X, y_true, ..., y_pred)).

네, 마지막에 있을 것이고 API는 다음과 같을 것입니다:

plot_confusion_matrix(y_true=y_true, y_pred=y_pred, ...)

내가 괜찮다고 생각하는 것. 이것은 본질적으로 PR입니다. https://github.com/scikit-learn/scikit-learn/pull/15883

네, 끝에 있을 것이고 API는 다음과 같이 보일 것입니다. plot_confusion_matrix(y_true=y_true, y_pred=y_pred, ...)

y_true를 추가하고 est & X를 제거해야 한다는 말씀이신가요? 불가능할 것 같은데요? (마지막에 y_pred만 추가할 수 있기 때문에)

0.22.1에서 이것을 해결하고 싶습니까? @NicolasHug @thomasjfox 이것을 0.22.1에 넣는 것이 좋다고 생각하지만 동시에 이것이 새로운 기능인 것 같습니다.

아니요, 0.22.1에 넣지 마십시오. 명백한 semver 위반입니다.

@qinhanmin2014 마지막에 y_pred 를 추가하거나 est, X 제거하는 것은 다음 릴리스에 속하는 새로운 기능처럼 보입니다.

y_true를 추가하고 est & X를 제거해야 한다는 말씀이신가요? 불가능할 것 같은데요?

결국 나는 사용 사례가 약간 다르기 때문에 두 인터페이스를 모두 지원하는 것을 선호합니다.

1. est, X 는 응답 함수 선택, 결과 분할 및 메트릭에 전달을 처리하기 때문에 빠른 분석을 수행하는 것이 더 쉽습니다.
2. y_true, y_pred 는 기본 메트릭으로 작업하는 방법을 이해하고 예측을 이미 저장한 사용자를 위한 것입니다.

https://github.com/scikit-learn/scikit-learn/issues/15880#issuecomment -565489619를 수행하는 데 문제가 있습니까?

이 전체 스레드를 읽지는 않았지만 여기에서 인터페이스를 허용하면 plot_roc_curve 대해서도 수행해야 합니다. 여기서 인터페이스는 예측을 제공하는 것과 추정기를 제공하는 것 사이에서 상당히 다릅니다(하나는 pos_label이 필요하고 다른 하나는 그렇지 않습니다) 'NS).
따라서 동일한 인터페이스에서 둘 다 허용하는 것은 나쁜 생각이라고 생각합니다(누군가 추정기를 전달할 때 pos_label을 전달하고 예상하지 못한 결과를 얻음).

ConfusionMatrixDisplay.from_estimator(...)
ConfusionMatrixDisplay.from_predictions(...)

작동할 수 있지만 기본적으로 plot_confusion_matrix 중복되므로 함수를 다시 제거하고 클래스와 함수 간의 책임을 변경합니다(클래스가 계산을 수행하지 않는다고 말했습니다).

from_predictions 를 plot_roc_curve 하려면 기본적으로 roc_curve 인터페이스를 완벽하게 미러링해야 합니다. 따라서 사용자가 roc_curve 함수를 직접 호출한 다음 결과를 Display 개체에 전달하도록 하는 것도 나쁘지 않다고 생각합니다.

표시 객체 디자인의 전체 목적은 @jhennrich가 언급한 사용

@amueller 기술적으로 당신이 맞습니다. 내 문제에 대한 현재 솔루션은 ConfusionMatrixDisplay 입니다. 그러나 다음을 사용하는 것은 정말 서투릅니다.

• 레이블을 명시적으로 전달해야 합니다.
• 먼저 혼동 행렬을 계산해야 합니다.
• 클래스의 개체를 만든 다음 여전히 plot 메서드를 호출해야 합니다.

내가 생각할 수있는 모든 응용 프로그램의 경우 plot_confusion_matrix 에 서명 (y_true, y_pred, ...) 우리가 현재 가지고있는 것보다 훨씬 더 편리 할 것입니다. 내 생각에는 예측을 명시적으로 계산하려는 훨씬 더 많은 사용 사례가 있습니다(내 견해가 편향되어 있다고 확신하지만).

plot_confusion_matrix(y_true, y_pred) 서명이 있고 실제로 estimator , x , y 데이터에 사용하려는 경우 작성할 추가 코드가 거의 없습니다. : plot_confusion_matrix(y, estimator.predict(x)) .
이에 비해 현재 서명이 있고 y_true 및 y_pred 에서 플롯하려면 더 많은 코드를 작성해야 합니다.

제 생각에는 plot_confusion_matrix(y_true, y_pred) 서명이 기본값이어야 하고 estimator , x , y 하는 다른 함수가 맨 위에 빌드되어야 합니다.

마지막으로 ConfusionMatrixDisplay 클래스의 이면에 있는 아이디어를 솔직히 이해하지 못합니다. 이 함수에는 단일 생성자와 정확히 하나의 메서드만 있으므로 사용할 때마다 결국 인스턴스를 만들고 plot 함수를 호출하게 됩니다. 왜 이것이 단지 함수가 아니라 클래스여야 하는지 모르겠습니다. 또한 다른 *Display 클래스(PrecisionRecall, ROC, ...)가 있지만 생성자와 plot() 서명이 완전히 다르기 때문에 어쨌든 교체할 수 없습니다.
아마도 이것은 이 문제의 범위를 벗어납니다.

@jhennrich

plot_confusion_matrix(y_true, y_pred) 서명이 있고 실제로 이를 추정기, x, y 데이터에 사용하려는 경우 작성해야 할 추가 코드는 거의 없습니다: plot_confusion_matrix(y, estimator.predict(x)).

혼동 행렬의 경우 y_true, y_pred 인터페이스가 있는 경우 estimator.predict 를 전달하는 것은 간단합니다. 반면에 plot_roc_auc 의 경우 사용자는 슬라이싱을 수행해야 합니다.

y_pred = est.predict_proba(X)
plot_roc_curve(y_true, y_pred[:, 1])

# or
y_pred = est.decision_function(X)
plot_roc_curve(y_true, y_pred[:, 1])

마지막으로 ConfusionMatrixDisplay 클래스의 이면에 있는 아이디어를 솔직히 이해하지 못합니다. 함수에는 단일 생성자와 정확히 하나의 메서드만 있으므로 사용할 때마다 결국 인스턴스를 만들고 플롯 함수를 호출하게 됩니다. 왜 이것이 단지 함수가 아니라 클래스여야 하는지 모르겠습니다.

Display 개체의 목적은 사용자가 다시 계산하지 않고 plot 여러 번 호출할 수 있도록 계산된 값을 저장하는 것입니다. 이것은 plot_partial_dependence 를 사용하여 볼 수 있습니다.

# Does expensive computation
disp = plot_partial_dependence(est, ...)

# change line color without needing to recompute partial dependence
disp.plot(line_kw={"c": "red"})

솔직히, 나는 이 문제에 대해 경계하고 있다. est, X, y 인터페이스를 플로팅하고 제거하기 위해 메트릭 인터페이스를 복사하는 방향으로 이동하는 데 +0.1입니다. :/

혼동 행렬의 경우 y_true, y_pred 인터페이스가 있는 경우 estimator.predict를 전달하는 것이 간단합니다. 반면에 plot_roc_auc의 경우 사용자는 슬라이싱을 수행해야 합니다.

예, 하지만 그렇게 함으로써 예측을 여러 번 계산하는 것을 피할 수 있습니다(예측은 종종 그렇게 비싸지 않지만)

아마도 0.23의 plot_XXX(해당되는 경우)에서 y_true, y_pred 를 지원하는 실용적인 솔루션일 것입니다.

@jhennrich 레이블을 명시적으로 전달하지 않고 어떻게 하시겠습니까? 주어진 confusion_matrix 에서 레이블을 유추할 수 있다면 그렇게 할 것입니다.

그러나 실제로 당신이 옳습니다. 한 줄이 아니라 세 줄입니다.

Confusion_matrix 의 경우 더 일반적인 경우가 y_true 및 y_pred 전달할 수 있다는 데 동의하는 경향이 있습니다.
인터페이스가 현재 그대로인 이유는 다른 메트릭 플로팅 기능과 일관성을 유지하기 위함입니다. @thomasjpfan이 말했듯이 roc 곡선은 플롯하기에 덜 명확합니다.

현재 혼동 행렬을 그리는 코드와 roc 곡선을 그리는 코드는 동일합니다. 제안한 변경 사항으로 인해 더 이상 동일하지 않으며 동일하게 만드는 쉬운 방법도 없을 것입니다.

문제는 이 경우 일관된 인터페이스를 갖는 것이 더 나은지 아니면 단순한 인터페이스를 갖는 것이 더 나은가입니다.
@jhennrich 나에게 진짜 질문은 plot_roc_curve 대한 올바른 인터페이스가 무엇인지입니다. 그것에 대한 생각이 있습니까?

@thomasjpfan roc auc도 플로팅하는 데 y_store 를 사용하는 쪽으로 기울고 있습니까?

메트릭 인터페이스를 사용하는 대신 스코어러 인터페이스를 사용하는 데에는 확실히 장단점이 있습니다. 그러나 더 복잡한 경우에는 스코어러 인터페이스를 사용하는 것이 훨씬 안전합니다.

@qinhanmin2014
y_pred 를 plot_confusion_matrix 에 추가하는 것이 좋을 것 같습니다. 문제는 y_score 를 plot_roc_curve 및 plot_precision_recall_curve 에 추가할지 여부입니다. 그렇게 하면 위에서 말했듯이 pos_label 도 추가해야 하며 상황이 더 복잡해집니다.

나는 이것에서 세 가지 방법을 봅니다.
a) y_pred plot_confusion_matrix 에 추가하고 y_score 를 plot_roc_curve 등에 추가하지 마십시오. 단점: predict_proba 호출 문제 여러 번 이러한 측정항목에 대해 기존 상태를 유지합니다.
b) Display 객체를 직접 사용하는 것을 더 쉽게 만드십시오(사실 방법은 모르지만).
c) 메트릭 인터페이스를 미러링하는 다른 방법이나 기능을 추가합니다. 단점: 더 큰 API 표면.

plot_X 기능이 스코어러와 메트릭 인터페이스를 동시에 미러링하는 것은 일반적으로 좋은 생각이라고 생각하지 않습니다.

@adrinjalali 어떤 식으로든 이 문제를 해결하는 것이 좋을 것 같습니다. 다음 회의에서 논의하시겠습니까?

나는 때때로 이 문제에 대해 악몽을 꾼다. 메트릭의 출력을 직접 가져오는 정적 메서드를 추가할 수 있습니다.

result = confusion_matrix(...)
ConfusionMatrixDisplay.from_metric(result).plot()

roc 곡선의 경우:

result = roc_curve(...)
RocCurveDisplay.from_metric(*result).plot()

참고로, 코드베이스를 보면 점수 인터페이스보다 메트릭 인터페이스에 익숙한 사용자가 더 많다고 생각합니다.

나는 때때로 이 문제에 대해 악몽을 꾼다.

안 돼 :(

참고로, 코드베이스를 보면 점수 인터페이스보다 메트릭 인터페이스에 익숙한 사용자가 더 많다고 생각합니다.

나는 이것이 확실히 사실이라고 생각합니다. 그러나 나는 또한 사람들이 사용하는 것이 매우 확신 y_pred 가 사용되어야 할 때 y_score 하고 인터페이스를 사용하면 뭔가 다르고 아니 -을 할 필요가 있음을 말해주지 않기 때문에 잘못된 결과를 얻고있다 한 번은 문서를 읽습니다.

당신이 제안한 정적 방법이 생성자와 어떻게 다른지 잘 모르겠지만 뭔가 간과하고 있는 것 같습니다.

안녕하세요, 방금 문제에 찬성표를 던졌습니다. 오랜 sklearn 사용자로서 plot_confusion_matrix 대한 현재 API가 매우... 혼란스럽습니다. 나는 그것의 추가(복사-붙여넣기가 적음)를 정말 좋아하지만, 메트릭 함수는 항상 (y_true, y_pred) 체계를 사용했는데, 이는 더 유연하고 이미 익숙해져 있습니다.

제 경우에는 모델이 매우 느리고 결과를 분석할 때마다 다시 실행하는 것보다 파일에서 예측을 로드하는 것이 좋기 때문에 추정기를 전달하는 것은 의미가 없습니다. 이 스레드에서 *Display 개체를 사용하는 해결 방법이 있다는 것을 알게 되어 기쁩니다. 그러나 검색 가능성은 그리 좋지 않습니다. 최소한 plot_confusion_matrix 문서나 혼동 행렬 사용자 가이드에 추가하는 것이 좋습니다. ?

제 경우에는 모델이 매우 느리고 예측을 로드하는 것이 좋기 때문에 추정기를 전달하는 것은 의미가 없습니다.

입력해 주셔서 감사합니다. 현재 API가 혼란스럽다면 인터페이스와 같은 더 메트릭 API로 이동하고 고통스러운 사용 중단 주기를 거치는 것이 더 합리적일 것입니다.

메트릭 인터페이스를 사용할 때 가장 큰 문제는 다음과 같습니다.

그러나 나는 또한 사람들이 y_score를 사용해야 할 때 y_pred를 사용하고 잘못된 결과를 얻고 있다고 확신합니다. 인터페이스가 다른 것을 해야 한다고 말하지 않고 아무도 문서를 읽지 않기 때문입니다.

@pzelasko 이 문제에 대해 어떻게 생각하십니까?

@thomasjpfan 문제를 이해합니다. 어려운 문제입니다. 아마도 합리적인 타협은 이 함수에 대해 키워드 인수만 허용하는 것입니다(이제 Python 2를 더 이상 지원할 필요가 없습니다)? 좋아요: def plot_confusion_matrix(*, y_true, y_pred, ...) . 여전히 나머지 메트릭과 다르지만 1) 그럴만한 이유가 있습니다. 2) 최소한 다른 기능과 동일한 유형의 입력을 사용하고 있습니다.

어쨌든, 나는 당신이 API 변경을 주저하는 이유를 알고 있습니다. 그래서 최소한 문서에서 해결 방법을 언급할 것을 제안했습니다. (실제로 여러 번 읽었고 정말 감사합니다!)

y_true 및 y_pred 를 사용하는 현재 방법은 다음과 같습니다. https://scikit-learn.org/stable/auto_examples/miscellaneous/plot_display_object_visualization.html#create -confusionmatrixdisplay

여기에서 스트레칭을 하고 있다는 것을 알고 있지만 이것은 어떻습니까?

plot_confusion_matrix(estimator='precomputed', y_true, y_pred, ...)

여기서 두 번째 위치는 y_true 경우 예측으로 estimator='precomputed 합니다.

더 늘리고 싶다면 plot_confusion_matrix((estimator, X, y), ...) 또는 plot_confusion_matrix((y_true, y_pred), ...) 선호하지만 메트릭과 같은 API와 관련하여 @amueller가 제기한 문제를 해결하는지 확신할 수 없습니다.

metric API를 허용하는 것이 실제로 의미가 있는 몇 가지 새로운 플로팅 유틸리티가 있습니다.

• https://github.com/scikit-learn/scikit-learn/pull/18020의 plot_prediction_error
• https://github.com/scikit-learn/scikit-learn/pull/17443의 plot_calibration_curve (CC @lucyleeow )

@amueller 가 pos_label 등을 전달해야 한다고 언급한 문제를 이해하지만 앞서 언급한 기능에는 문제가 되지 않습니다.

이 두 가지에 대해 스코어러와 메트릭 API를 모두 지원해도 됩니까? 우리는 거기에서 이전 버전과의 호환성에 대해 걱정할 필요가 없습니다.

나는 여전히 우리가 추정기에서 일반적으로 사용하는 precomputed 사용에 대한 제 제안을 지지합니다. 이 경우 서명은 다음과 같습니다.

plot_confusion_matrix(estimator='precomputed', y_true, y_pred, ..., metric_kwargs=None)

나는 이것이 어떻게 생겼는지 보기 위해 PR을 할 것이다.

아직 API에 대해 실제로 논의하는 것이 아니라 새 PR에 대해 두 가지 옵션을 모두 지원해도 되는지 묻는 것뿐입니다.

(하지만 API에 관해서는 '미리 계산된'이 별로 도움이 되지 않는다고 생각합니다. X 무엇을 합니까? 적절한 오류를 통해 (y_pred)와 (estimator, X)를 상호 배타적으로 유지해야 한다고 생각합니다. 또한 estimator가 미리 계산된다는 것은 무엇을 의미합니까?)

또는 estimator='none' , estimator='predictions' , estimator='precomputed_predictions' , X 는 y_pred 또는 y_score 됩니다. 추정기에서 X 로 미리 계산된 거리를 처리하는 방법과 거의 같습니다.

이 두 가지에 대해 스코어러와 메트릭 API를 모두 지원해도 됩니까?

두 가지 옵션을 모두 지원하려면 어떻게 해야 합니까? 두 가지 기능으로?

나는 또한 좋아했을 것입니다 :

CalibrationDisplay.from_estimator(...)
CalibrationDisplay.from_predictions(...)

두 가지 방법이 될 것입니다.

튜플 https://github.com/scikit-learn/scikit-learn/issues/15880#issuecomment -670590882 사용에 대한 Guillaume의 제안은 하나의 옵션입니다. 처음부터 거기서부터 시작했다면 최고의 선택이 되었을 거라고 생각합니다. 그러나 튜플을 사용하면 기존 유틸리티와의 일관성이 깨질까 걱정됩니다.

상호 배제를 포함하는 plot_XYZ(estimator=None, X=None, y=None, y_pred=None) 는 또 다른 옵션이며 현재로서는 이것이 제가 옹호하는 옵션입니다.

나는 CalibrationDisplay.from_estimator(...) 를 좋아하지만 Andy가 언급했듯이 plot_XYZ 함수를 제거해야 합니다. 고려해 볼 가치가 있습니다.

나는 우리가 튜플로 이동하고 현재 동작을 더 이상 사용하지 않을 수 있다고 생각합니다. (튜플 사용에 동의하는 한)

이것은 네임스페이스를 논의하는 것처럼 보입니다. 맞습니까?
하나의 함수와 하나의 생성자가 있든, 두 개의 클래스 메서드가 있든, 두 개의 함수가 있든 그것은 정확히 동일한 기능과 기본적으로 동일한 코드입니다.

@pzelasko @jhennrich 두 개의 클래스 메소드 또는 두 개의 기능을 갖는 것에 대해 어떻게 생각하십니까? 아니면 파이썬에서 약간 지저분한 단일 함수를 선호하시겠습니까?

그리고 두 개의 함수 또는 두 개의 클래스 메서드를 선호한다면 검색 가능성에도 불구하고 어떤 이점이 있습니까? 발견 가능성은 classmethods를 수행하는 충분한 이유가 될 수 있지만 두 가지 기능을 갖는 것에 대한 강력한 주장은 보이지 않습니다.

여기에 차단 라벨을 추가할 수 있습니까? #18020, #17443 (cc @cmarmo) 진행을 막고 있는 것 같습니다.

차단제 라벨은 PR 차단제가 아닌 릴리스 차단제(출시 전에 반드시 고쳐야 할 사항)를 위한 것입니다.

아아 다행이다.

@pzelasko @jhennrich 두 개의 클래스 메소드 또는 두 개의 기능을 갖는 것에 대해 어떻게 생각하십니까? 아니면 파이썬에서 약간 지저분한 단일 함수를 선호하시겠습니까?

그리고 두 개의 함수 또는 두 개의 클래스 메서드를 선호한다면 검색 가능성에도 불구하고 어떤 이점이 있습니까? 발견 가능성은 classmethods를 수행하는 충분한 이유가 될 수 있지만 두 가지 기능을 갖는 것에 대한 강력한 주장은 보이지 않습니다.

나는 two-classmethods 접근 방식을 가장 좋아합니다. 특히 from_xxx 패턴 - @thomasjpfan이 제안한 것과 같은 sth:

CalibrationDisplay.from_estimator(...)
CalibrationDisplay.from_predictions(...)

2개의 클래스 방식을 사용하는 것에 대해 강한 반대가 없을 것 같으니 그렇게 해보자. 다음을 수행해야 합니다.

• 현재 존재하는 플롯에 대한 클래스 메서드를 소개합니다.

  • ConfusionMatrixDisplay
  • PrecisionRecallDisplay
  • RocCurveDisplay
  • DetCurveDisplay
  • PartialDependenceDisplay . 이 경우 from_predictions classmethod를 도입하고 싶지 않습니다. 의미가 없기 때문에 from_estimator 만 원합니다.

• 위에 나열된 모든 디스플레이에 대해 해당 plot_... 기능을 더 이상 사용하지 않습니다. plot_det_curve 는 아직 출시되지 않았기 때문에 더 이상 사용하지 않아도 됩니다. 제거하면 됩니다.

• #17443 및 #18020과 같은 새로운 PR의 경우 plot 함수를 도입하는 대신 클래스 메서드를 즉시 구현할 수 있습니다.

이것은 약간의 작업이지만 #17443 및 #18020이 이미 앞으로 나아갈 수 있도록 0.24 이전에 완료할 수 있다고 생각합니다.

@thomasjpfan @jnothman @amueller @glemaitre에 이의가 있습니까?

@jhennrich @pzelasko , Display 개체 중 하나에 클래스 메서드를 도입하기 위해 PR을 제출하는 데 관심이 있으십니까?

결정해주셔서 감사합니다 @NicolasHug! #17443으로 이동합니다(이의 제기를 기다린 후)

나는 이의가 없습니다.

이의도 없습니다.

그 다음에는 다른 수업을 처리하고 지연된 PR을 진행합니다.
@lucyleeow 내가 그 모든 작업을 수행하지 않았고 일부 PR을 찾고 있는 경우를 보내 주세요. :)

기여하고 싶지만 현재 너무 많은 프로젝트에 참여하고 있습니다. 제안을 들어주셔서 감사합니다!

좋은 소리 :)