Scikit-learn: Sugerencia: elimine la predicción de plot_confusion_matrix y simplemente pase las etiquetas predichas

Definitivamente deberíamos mantener la compatibilidad con versiones anteriores, pero agregar un argumento de palabra clave y_pred me parece razonable. Deberíamos generar un error si se pasa y_pred pero también se pasa X o el estimador.

¿Le gustaría enviar un PR @jhennrich ?

Envié un PR, pero creo que actualmente hay un problema con el CI, por lo que aún no se ha aprobado.

Estoy de acuerdo en que deberíamos admitir plot_XXX(y_true, y_pred) para evitar calcular la predicción varias veces.
También tenemos problemas similares en plot_roc_curve y plot_precision_recall_curve.
Agregar y_pred parece aceptable, pero honestamente no creo que sea una buena solución.
Para aquellas funciones que aceptan ** kwargs (por ejemplo, plot_precision_recall_curve), ¿parece que es imposible mantener la compatibilidad con versiones anteriores?

¿Por qué es imposible mantener la compatibilidad con versiones anteriores? Me parece que la propuesta en # 15883 está bien

¿Por qué es imposible mantener la compatibilidad con versiones anteriores? Me parece que la propuesta en # 15883 está bien

porque no admitimos ** kwargs en plot_confusion_matrix. @NicolasHug

¿Por qué los kwargs son un problema?

Hmm, entonces hay otra cosa molesta, admitimos ** kwargs en plot_roc_curve y plot_precision_recall_curve (y plot_partial_dependence), pero no lo admitimos en plot_confusion_matrix

¿Por qué los kwargs son un problema?

si agregamos el nuevo parámetro antes de ** kwargs, podemos mantener la compatibilidad con versiones anteriores, ¿verdad?

Los cambios en mi PR son compatibles con versiones anteriores y aún se pueden agregar ** kwargs. Pero estoy de acuerdo con @ qinhanmin2014 , una solución mucho más limpia sería descartar estimator y X y usar argumentos posicionales (y_true, y_pred, ...) que sean consistentes con la mayoría de los otras cosas de sklearn.

si agregamos el nuevo parámetro antes de ** kwargs, podemos mantener la compatibilidad con versiones anteriores, ¿verdad?

sí

una solución mucho más limpia ...

Desafortunadamente, eso requeriría un ciclo de desaprobación (a menos que lo hagamos muy rápido en la versión de corrección de errores, pero lo dudo ...)

@thomasjpfan , ¿alguna razón para pasar el estimador como entrada en lugar de las predicciones?

Gracias, primero agreguemos y_pred, ** kwags es otro problema.

Desafortunadamente, eso requeriría un ciclo de desaprobación (a menos que lo hagamos muy rápido en la versión de corrección de errores, pero lo dudo ...)

Esto parece imposible, suspiro

@thomasjpfan , ¿alguna razón para pasar el estimador como entrada en lugar de las predicciones?

Estoy de acuerdo en que debemos reconsiderar nuestro diseño de API. también intenta hacer ping a @amueller

Si un usuario desea proporcionar su propia parte de trazado y proporcionar su propia matriz de confusión:

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

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

Esto se puede hacer de manera similar para las otras funciones de trazado métrico.

El plot_confusion_matrix está diseñado como los anotadores que pueden manejar bien la salida de los estimadores. En otras palabras, es un contenedor conveniente para interactuar con ConfusionMatrixDisplay y el estimador.

Al aceptar primero el estimador, existe una interfaz uniforme para las funciones de trazado. Por ejemplo, plot_partial_dependence hace todo el cálculo necesario para crear las gráficas de dependencia parcial y lo pasa a PartialDependenceDisplay . Un usuario aún puede crear el PartialDependenceDisplay sí mismo, pero en ese caso estaría más involucrado.

Aunque, estoy abierto a tener una "ruta rápida", lo que permite que y_pred se pasen a las funciones de trazado relacionadas con las métricas, que se pasarán directamente a confusion_matrix y dejarán que se ocupe de la validación.

El cálculo de las predicciones necesarias para construir un PDP es bastante complejo. Además, estas predicciones normalmente no se pueden utilizar, por ejemplo, en un anotador o una métrica. Solo son útiles para trazar el PDP. Entonces, tiene sentido en este caso aceptar solo el estimador en plot_partial_dependence.

OTOH para la matriz de confusión, las predicciones son realmente solo est.predict(X) .

No creo que queramos una interfaz uniforme aquí. Estos son 2 casos de uso de entrada muy diferentes

EDITAR: Además, los PDP basados ​​en árboles ni siquiera necesitan predicciones en absoluto

Hay otras cosas con las que nos encontraremos sin el estimador. Por ejemplo, si plot_precision_recall_curve aceptara y_pred , necesitará pos_label porque ya no se puede inferir. En este caso, preferiría usar PrecisionRecallDisplay directamente y que el usuario calcule los parámetros necesarios para reconstruir la trama.

Esto se reduce a qué tipo de pregunta estamos respondiendo con esta API. La interfaz actual gira en torno a la evaluación de un estimador, utilizando así el estimador como argumento. Está motivado respondiendo "¿cómo se comporta este modelo entrenado con estos datos de entrada?"

Si aceptamos y_pred, y_true , ahora la pregunta es "¿cómo se comporta esta métrica con estos datos?" Estos datos pueden o no ser generados por un modelo.

Es cierto que en este caso específico, @jhennrich podría estar usando directamente ConfusionMatrixDisplay.

Un inconveniente es que debe especificar display_labels ya que no tiene un valor predeterminado.

@thomasjpfan , ¿cree que, en general, podríamos proporcionar valores predeterminados razonables para los objetos de visualización, y así seguir haciendo práctico el uso directo de los objetos de visualización?

Para algunos parámetros, como display_labels , existe un valor predeterminado razonable. Los otros parámetros del objeto Display pueden tener valores predeterminados razonables. Sin embargo, se deben proporcionar algunos parámetros. Por ejemplo, confusion_matrix debe proporcionarse para ConfusionMatrixDisplay o precision y recall para PrecisionRecallDisplay .

Un patrón clásico para este tipo de cosas es definir:

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

pero esto no es muy idiomático para scikit-learn.

Empiezo a confundirme. El objetivo de la API actual es evitar calcular varias veces si los usuarios quieren trazar varias veces, pero si aceptamos y_true e y_pred, ¿los usuarios aún no necesitan calcular varias veces? (Sé que las cosas son diferentes en PDP)

@jnothman ¡ Esa API es muy bonita!

@ qinhanmin2014 Pasar un estimator, X, y o y_true, y_pred funciona para satisfacer la API de "no calcular varias veces". En ambos casos, la matriz de confusión se calcula y almacena en el objeto Display .

La diferencia entre ellos es donde comienza el cálculo de la matriz de confusión. Se puede pensar en pasar y_pred como el valor "precalculado" del estimador.

Entonces creo que y_true, y_pred es mejor que estimator, X, y (no en PDP, por supuesto), porque a veces (¿a menudo?) Los usuarios no solo quieren trazar las predicciones, también quieren analizar las predicciones. Con la API actual, deberán calcular las predicciones varias veces.

Para las métricas, puedo ver la preferencia por usar y_true, y_pred sobre estimator, X, y . Imagínese si el trazado de las métricas solo admite 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, ...)

Actualmente, la API se ve así:

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, ...)

Preferiría tener una API que admita ambas opciones (de alguna manera).

Para las métricas, puedo ver la preferencia por usar y_true, y_pred sobre el estimador, X, y. Imagínese si el trazado de las métricas solo admite y_true, y_pred

Sí, esto es lo que quiero decir.

Preferiría tener una API que admita ambas opciones (de alguna manera).

Creo que esta es una solución práctica. Una cosa molesta es que solo podemos agregar y_pred al final (es decir, plot_confusion_matrix (estimator, X, y_true, ..., y_pred))

Sí, estará al final y la API se vería así:

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

con lo que creo que estoy de acuerdo. Este es esencialmente el PR https://github.com/scikit-learn/scikit-learn/pull/15883

Sí, estará al final y la API se vería así plot_confusion_matrix (y_true = y_true, y_pred = y_pred, ...)

Supongo que quieres decir que deberíamos agregar y_true y eliminar est & X, ¿verdad? ¿Supongo que es imposible? (porque solo podemos agregar y_pred al final)

¿Queremos resolver esto en 0.22.1? @NicolasHug @thomasjfox Creo que vale la pena poner esto en 0.22.1, pero al mismo tiempo, parece que esta es una característica nueva.

No, no lo pongas en 0.22.1. es una clara violación de semver

@ qinhanmin2014 Agregar y_pred al final o eliminar est, X parece una nueva característica que pertenece a la próxima versión.

Supongo que quieres decir que deberíamos agregar y_true y eliminar est & X, ¿verdad? ¿Supongo que es imposible?

Al final, preferiría admitir ambas interfaces, porque tienen un caso de uso ligeramente diferente.

1. est, X es más fácil de hacer un análisis rápido, porque la función se encarga de elegir la función de respuesta, dividir el resultado y pasarlo a la métrica.
2. y_true, y_pred es para usuarios que entienden cómo trabajar con la métrica subyacente y ya tienen las predicciones guardadas.

¿Cuál es el problema de hacer https://github.com/scikit-learn/scikit-learn/issues/15880#issuecomment -565489619?

No he leído todo este hilo, pero si permitimos la interfaz aquí, también debemos hacerlo por plot_roc_curve donde la interfaz será bastante diferente entre proporcionar predicciones y proporcionar el estimador (uno necesita pos_label y el otro no 't).
Así que creo que permitir ambos en la misma interfaz es una mala idea (alguien pasará pos_label cuando pase un estimador y obtendrá un resultado que no espera).

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

Podría funcionar, pero básicamente haría que plot_confusion_matrix redundante, por lo que eliminaríamos las funciones nuevamente y cambiaríamos las responsabilidades entre la clase y la función (dijimos que la clase no hace el cálculo).

Si queremos agregar un from_predictions a plot_roc_curve , básicamente necesita reflejar perfectamente la interfaz roc_curve . Así que no creo que sea tan malo que el usuario llame directamente a la función roc_curve y luego pase los resultados al objeto Display.

Todo el propósito del diseño de los objetos de visualización era permitir el caso de uso mencionado por @jhennrich y por qué separamos el cálculo de la función. No he visto un argumento sobre por qué deberíamos dar marcha atrás en esa decisión todavía.

@amueller Técnicamente tienes razón, la solución actual a mi problema es usar ConfusionMatrixDisplay . Sin embargo, es muy torpe de usar:

• tienes que pasar las etiquetas explícitamente
• primero tienes que calcular la matriz de confusión
• tienes que crear un objeto de la clase y luego aún llamar al método plot

Para todas las aplicaciones, puedo pensar en una firma plot_confusion_matrix con (y_true, y_pred, ...) que sería mucho más conveniente de lo que tenemos actualmente. En mi opinión, hay muchos más casos de uso en los que desea calcular explícitamente las predicciones (aunque estoy seguro de que mi opinión está sesgada).

Si tiene una firma plot_confusion_matrix(y_true, y_pred) y realmente desea usarla en los datos estimator , x , y , solo hay muy poco código adicional para escribir : plot_confusion_matrix(y, estimator.predict(x)) .
En comparación, si tiene la firma actual y desea trazar desde y_true y y_pred , debe escribir mucho más código.

En mi opinión, la firma plot_confusion_matrix(y_true, y_pred) debería ser la predeterminada y otra función que tome estimator , x , y debería construirse en la parte superior.

Por último, pero no menos importante, honestamente no entiendo la idea detrás de la clase ConfusionMatrixDisplay . La función solo tiene un único constructor y exactamente un método, por lo que cada vez que la usa, termina creando una instancia y llamando a la función plot . No veo por qué esto debería ser una clase y no solo una función. También hay otras clases *Display (PrecisionRecall, ROC, ...), pero sus firmas de constructor y plot() son completamente diferentes, por lo que no se pueden intercambiar de todos modos.
Quizás esto vaya más allá del alcance de este tema.

@jhennrich

Si tiene una firma plot_confusion_matrix (y_true, y_pred) y realmente desea usarla en estimador, datos x, y, solo hay muy poco código adicional para escribir: plot_confusion_matrix (y, estimator.predict (x)).

Para el caso de la matriz de confusión, es simple pasar estimator.predict si tuviéramos una interfaz y_true, y_pred . Por otro lado, por plot_roc_auc , el usuario necesitaría hacer un corte:

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])

Por último, pero no menos importante, honestamente no entiendo realmente la idea detrás de la clase ConfusionMatrixDisplay. La función solo tiene un único constructor y exactamente un método, por lo que cada vez que la usa, termina creando una instancia y llamando a la función plot. No veo por qué esto debería ser una clase y no solo una función.

El propósito de los objetos Display es almacenar los valores calculados permitiendo a los usuarios llamar a plot muchas veces sin volver a calcular. Esto se puede ver usando 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"})

Honestamente, estoy indeciso sobre este tema. Estoy +0.1 para moverme hacia la copia de la interfaz de métricas para trazar métricas y eliminar la interfaz est, X, y . : /

Para el caso de la matriz de confusión, es simple pasar estimator.predict si tuviéramos una interfaz y_true, y_pred. Por otro lado, para plot_roc_auc, el usuario necesitaría hacer un corte:

Sí, pero al hacerlo, evitamos calcular la predicción varias veces (aunque la predicción a menudo no es tan costosa)

Quizás una solución práctica sea admitir y_true, y_pred en plot_XXX (cuando corresponda) en 0.23.

@jhennrich ¿Cómo va a hacer esto sin pasar las etiquetas explícitamente? Si las etiquetas se pueden inferir de lo que se da, confusion_matrix lo hará por usted.

Pero de hecho tienes razón, son tres líneas en lugar de una.

En el caso de confusion_matrix, tiendo a estar de acuerdo en que el caso más común podría ser pasar y_true y y_pred .
La razón por la que la interfaz está actualmente como está es para ser coherente con las otras funciones de trazado de métricas. Como dijo @thomasjpfan , la curva roc es menos obvia de trazar.

En este momento, el código para trazar una matriz de confusión y trazar una curva roc es el mismo. Con el cambio sugerido, ya no serán los mismos y no habrá una manera fácil de hacerlos iguales.

La pregunta es si en este caso es mejor tener interfaces consistentes o tener una interfaz simple.
@jhennrich Para mí, la verdadera pregunta es cuál es la interfaz correcta para plot_roc_curve . ¿Tienes pensamientos sobre eso?

@thomasjpfan, ¿te inclinas por tomar y_store para trazar roc auc?

Ciertamente, existen pros y contras de usar la interfaz de anotador en lugar de usar la interfaz métrica. Pero para cosas más complejas, es mucho más seguro usar la interfaz de anotador.

@ qinhanmin2014
Creo que estaría bien agregar y_pred a plot_confusion_matrix . La pregunta es si queremos agregar y_score a plot_roc_curve y plot_precision_recall_curve . Si lo hacemos, también tenemos que agregar pos_label como dije anteriormente, y las cosas se volverán más complicadas.

Veo tres formas de salir de esto:
a) Solo agregue y_pred a plot_confusion_matrix , pero no agregue y_score a plot_roc_curve etc. Desventaja: el problema de llamar a predict_proba varias veces sigue existiendo para estas métricas.
b) Facilite el uso del objeto Display directamente (aunque realmente no sé cómo).
c) Agregue otro método o función que refleje la interfaz métrica. Desventaja: mayor superficie API.

No creo que tener la función plot_X refleje tanto la interfaz del marcador como la métrica al mismo tiempo sea una buena idea en general.

Creo que sería genial resolver esto de alguna manera @adrinjalali, ¿tal vez quieres discutirlo en la próxima reunión?

A veces tengo pesadillas sobre este tema. Tal vez podamos agregar un método estático que tome la salida de la métrica directamente:

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

Para curva roc:

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

En una nota al margen, al mirar las bases de código, creo que más usuarios están familiarizados con la interfaz de métricas que con la interfaz de puntuación.

A veces tengo pesadillas sobre este tema.

Oh no :(

En una nota al margen, al mirar las bases de código, creo que más usuarios están familiarizados con la interfaz de métricas que con la interfaz de puntuación.

Creo que esto es definitivamente cierto. Pero también estoy bastante seguro de que las personas usan y_pred cuando deberían usar y_score y obtienen resultados incorrectos porque la interfaz no le dice que debe hacer algo diferente y no- uno alguna vez lee los documentos.

No estoy seguro de en qué se diferencia el método estático que propones del constructor, pero tal vez estoy pasando por alto algo.

Hola, acabo de votar el problema: como usuario de sklearn desde hace mucho tiempo, encontré la API actual para plot_confusion_matrix muy ... bueno, confusa. Realmente me gusta su adición (menos copiar y pegar), pero las funciones de métricas siempre usaron el esquema (y_true, y_pred) que es más flexible y a lo que ya estoy acostumbrado.

En mi caso, no tiene sentido pasar un estimador, ya que es un modelo muy lento y prefiero cargar las predicciones de un archivo que volver a ejecutarlo cada vez que quiero analizar los resultados. Estoy feliz de haber descubierto en este hilo que hay una solución alternativa para usar el objeto * Display, pero su capacidad de descubrimiento no es excelente; sugeriría al menos agregar eso a la documentación de plot_confusion_matrix o tal vez a la guía del usuario de la matriz de confusión ?

En mi caso, no tiene sentido pasar un estimador, ya que es un modelo muy lento y prefiero cargar las predicciones

Gracias por tu contribución. Si la API actual es confusa, cada vez tendría más sentido pasar a una interfaz similar a la API de métricas y pasar por un ciclo de desaprobación doloroso.

La mayor preocupación que tenemos con el uso de la interfaz de métricas es:

Pero también estoy bastante seguro de que las personas usan y_pred cuando deberían usar y_score y obtienen resultados incorrectos porque la interfaz no le dice que debe hacer algo diferente y nadie lee los documentos.

@pzelasko ¿Qué piensas sobre este asunto?

@thomasjpfan Entiendo el problema, es difícil. ¿Quizás un compromiso razonable sería permitir solo argumentos de palabras clave para esta función (ahora que ya no tiene que admitir Python 2)? Me gusta: def plot_confusion_matrix(*, y_true, y_pred, ...) . Todavía es diferente del resto de las métricas, pero 1) tiene una buena razón para eso, 2) al menos está usando el mismo tipo de entradas que las otras funciones.

De todos modos, sé por qué duda en realizar cambios en la API, por eso sugerí al menos mencionar la solución en los documentos. (¡De hecho, los he leído muchas veces y realmente los aprecio!)

La forma actual de usar y_true y y_pred se muestra aquí: https://scikit-learn.org/stable/auto_examples/miscela/plot_display_object_visualization.html#create -confusionmatrixdisplay

Sé que me estoy estirando aquí, pero ¿qué pasa con esto?

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

donde la segunda posición acepta y_true como predicciones si estimator='precomputed .

si desea estirar aún más, preferiría plot_confusion_matrix((estimator, X, y), ...) o plot_confusion_matrix((y_true, y_pred), ...) pero no estoy seguro de que esté resolviendo los problemas planteados por @amueller con respecto a la API de tipo métrico

Hay algunas nuevas utilidades de trazado en las que permitir una API metric realmente tendría sentido:

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

Entiendo el problema que @amueller mencionó sobre la necesidad de pasar pos_label , etc., pero esto no es un problema para ninguna de las funciones mencionadas anteriormente.

¿Estamos de acuerdo en admitir tanto la API de anotador como la de métricas para estos dos? No tenemos que preocuparnos por la compatibilidad con versiones anteriores.

Todavía estoy a favor de mi sugerencia de usar precomputed , que usamos comúnmente en nuestros estimadores. En este caso, la firma sería:

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

Reuniré relaciones públicas para ver cómo se ve esto.

Realmente no estoy discutiendo la API todavía, solo estoy preguntando si estamos bien para admitir ambas opciones para nuevos RP.

(Pero con respecto a la API, no creo que 'precalculado' ayude mucho: ¿qué hacemos con X ? Creo que deberíamos mantener (y_pred) y (estimador, X) mutuamente excluyentes, equivocando correctamente Además, ¿qué significa que un estimador esté calculado previamente?)

O estimator='none' , estimator='predictions' , estimator='precomputed_predictions' , y luego X convierte en y_pred o y_score . Es casi como manejamos distancias precalculadas con X en estimadores.

¿Estamos de acuerdo en admitir tanto la API de anotador como la de métricas para estos dos?

¿Cómo vamos a apoyar ambas opciones? ¿Con dos funciones?

También me hubiera gustado:

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

que serían dos métodos.

La sugerencia de Guillaume de usar tuplas https://github.com/scikit-learn/scikit-learn/issues/15880#issuecomment -670590882 es una opción. Creo que hubiera sido la mejor opción si hubiéramos empezado desde allí desde el principio. Pero me temo que el uso de tuplas rompe la coherencia con las utilidades existentes.

plot_XYZ(estimator=None, X=None, y=None, y_pred=None) con exclusión mutua es otra opción, y es la que estoy defendiendo, por ahora.

Me gusta CalibrationDisplay.from_estimator(...) , pero como señaló Andy, entonces tendríamos que eliminar las funciones plot_XYZ . Podría valer la pena considerarlo.

Creo que podemos pasar a las tuplas y desaprobar el comportamiento actual. (Siempre que aceptemos usar tuplas)

Entonces, esto parece discutir los espacios de nombres, ¿verdad?
Ya sea que tengamos una función y un constructor, o dos métodos de clase o dos funciones, es exactamente la misma funcionalidad y básicamente el mismo código.

@pzelasko @jhennrich ¿cómo te sientes acerca de tener dos métodos de clase o dos funciones? ¿O preferiría una sola función, que es un poco desordenada en Python?

Y si prefiere dos funciones o dos métodos de clase, ¿ve algún beneficio a pesar de la capacidad de descubrimiento? Sin embargo, la capacidad de descubrimiento podría ser una razón suficiente para hacer métodos de clase, no veo un argumento sólido para tener dos funciones.

¿Podríamos agregar la etiqueta del bloqueador aquí? Parece que está impidiendo el progreso en # 18020 y # 17443 (cc @cmarmo)

La etiqueta de bloqueador es para bloqueadores de liberación (cosas que absolutamente deben arreglarse antes de una liberación), no para bloqueadores de relaciones públicas

Ahh es bueno saberlo.

@pzelasko @jhennrich ¿cómo te sientes acerca de tener dos métodos de clase o dos funciones? ¿O preferiría una sola función, que es un poco desordenada en Python?

Y si prefiere dos funciones o dos métodos de clase, ¿ve algún beneficio a pesar de la capacidad de descubrimiento? Sin embargo, la capacidad de descubrimiento podría ser una razón suficiente para hacer métodos de clase, no veo un argumento sólido para tener dos funciones.

Me gusta más el enfoque de dos clases, especialmente el patrón from_xxx , algo como @thomasjpfan propuesto:

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

Parece que no hay una fuerte oposición al uso de métodos de 2 clases, así que hagámoslo. Necesitaremos:

• Introduzca los métodos de clase para las parcelas existentes actualmente:

  • ConfusionMatrixDisplay
  • PrecisionRecallDisplay
  • RocCurveDisplay
  • DetCurveDisplay
  • PartialDependenceDisplay . Para este, no queremos introducir el método from_predictions clase from_estimator .

• Para todas las pantallas enumeradas anteriormente, desapruebe su función plot_... . No necesitamos desaprobar plot_det_curve porque aún no se ha lanzado, simplemente podemos eliminarlo.

• para nuevos PR como # 17443 y # 18020 podemos implementar los métodos de clase de inmediato en lugar de introducir una función plot .

Esto es un poco de trabajo, pero creo que podemos hacerlo antes de 0.24 para que # 17443 y # 18020 ya puedan avanzar.

¿Alguna objeción @thomasjpfan @jnothman @amueller @glemaitre ?

@jhennrich @pzelasko , ¿estaría interesado en enviar un PR para introducir los métodos de clase en uno de los objetos de visualización?

¡Gracias por tomar la decisión @NicolasHug! Entraré en el # 17443 (después de esperar objeciones)

No tengo objeciones.

Tampoco hay objeciones.

Entonces me ocuparé de las otras clases y avanzaré en mi RP estancado.
@lucyleeow en caso de que no haya hecho todo eso y estés buscando algunos PR, hazme un ping :)

Me encantaría contribuir, pero estoy participando en demasiados proyectos en este momento. ¡Gracias por escuchar las sugerencias!

Suena bien :)