No soy un confirmador, pero ¿podemos apuntar a la API de PySpark para 1.0?
Problema: # 3370
RP actual: # 4656

para otros colaboradores que no tienen permiso para editar la publicación, comenten aquí sobre lo que creen que debería estar en 1.0.0

Además, ¿deberíamos apuntar a movernos exclusivamente al rastreador Rabit basado en Scala (para Spark) en 1.0?

Tampoco soy un comprometido, pero yo y la empresa en la que trabajo estamos muy interesados ​​en solucionar el problema de rendimiento con puntos de control (o al menos mitigarlo) # 3946

@trams @thesuperzapper Creo que esta es una descripción general para que todos tengan una idea de lo que viene a continuación. Sería difícil enumerar todo lo que viene ya que XGBoost es un proyecto impulsado por la comunidad. Simplemente abra un PR cuando esté listo.

No soy un confirmador, pero ¿podemos apuntar a la API de PySpark para 1.0?

@thesuperzapper Hagamos un seguimiento del progreso. Ciertamente espero poder empezar a probarlo. :-)

También existe la consideración secundaria, que es posible que no estemos listos para 1.0, y las garantías de API que vienen con eso, por ejemplo, ¿podríamos hacer 0.10.0 a continuación?

@thesuperzapper 1.0 no será una versión final. Es solo que estamos tratando de hacer versiones semánticas.

Se agregaron algunos elementos relacionados con gpu.

quisiera tener una corrección nativa xgb incluida.
https://github.com/dmlc/xgboost/issues/4753

JSON se elimina de la lista. Ver https://github.com/dmlc/xgboost/pull/4683#issuecomment -520485615

Presenté un problema para mi sugerencia anterior: # 4781 (Para eliminar el rastreador de Python Rabit)

FeatureImportance en la versión Spark también será excelente (es decir, tendrá fácilmente la característica Importance)
https://github.com/dmlc/xgboost/pull/988

Prueba de regresión agregada.

@chenqin Me gustaría saber de ti sobre las pruebas de regresión, ya que tienes experiencia en la gestión de ML en producción. ¿Alguna sugerencia?

@chenqin Me gustaría saber de ti sobre las pruebas de regresión, ya que tienes experiencia en la gestión de ML en producción. ¿Alguna sugerencia?

Creo que deberíamos cubrir la prueba de regresión en varias cargas de trabajo y compararlas con la precisión y estabilidad de la predicción (igual o mejor) que la versión anterior en aproximadamente el mismo tiempo. Dos candidatos encima de mi cabeza son

https://archive.ics.uci.edu/ml/datasets/HIGGS

escasa Dmatrix
https://www.kaggle.com/c/ClaimPredictionChallenge

Podemos probar varios métodos y configuraciones de árbol para asegurar una buena cobertura.

tree_method, configuraciones / dataset / standalone o cluster

declamador:
Creo que vale la pena aclarar un poco.

• La regresión de la versión no es algo que ya hicimos en la empresa en la que trabajaba.

• Los conjuntos de datos que propuse son arbitrarios y pueden no usarse como punto de referencia para reclamar un marco mejor que otro. (esto es más preocupante cuando vi puntos de referencia sesgados de vez en cuando)

• De hecho, la esencia de sintonizar y descubrir las características / configuraciones adecuadas siempre ha sido más importante. Desafortunadamente, es posible que no cubramos esto en las pruebas de regresión.

Puede que el plan más organizado sea construir una herramienta de automatización donde el usuario pueda tomar y comparar varias configuraciones con su conjunto y modelo de datos privados en su propio centro de datos.

Deberíamos agregar el arreglo # 4779 como requisito para enviar 1.0

Agrego # 4899 como paso de limpieza.

@ dmlc / xgboost-committer Dado que nos quedan bastantes tareas para la versión 1.0, ¿quizás deberíamos hacer una versión provisional 0.91?

@ hcho3 O quizás 0.10.0

@thesuperzapper Eso confundirá al sistema de versiones. No me importa una versión 0.91, pero aún así quiero ver los procedimientos adecuados para las pruebas de regresión.

@trivialfis Si el maestro tiene cambios en la API, ¿no deberíamos agregar una versión principal, que supongo que se vería como 0.100.0?

@thesuperzapper La versión 1.0.0 es la primera versión que adoptaríamos el esquema de control de versiones semántico, así que no, el control de versiones semántico no se aplicará a la versión provisional. Es un poco complicado, ya que tenemos mucho que hacer hasta que se lance 1.0.0.

Si queremos un 0.91, debemos revisar todos los cambios y asegurarnos de que 0.91 sea un
actualización incremental basada en 0.90, y como tal, no dañamos nuestra hoja de ruta de
1.0.0 cambiando varias funciones a 0.9xo cualquier otra versión

Mi sugerencia sería la versión 1.0.0.preview.1, algún otro proyecto también
hace esto antes de un lanzamiento importante

El sábado 5 de octubre de 2019 a las 10:19 a.m. Philip Hyunsu Cho [email protected]
escribió:

@thesuperzapper https://github.com/thesuperzapper La versión 1.0.0 es
la primera versión adoptaríamos un esquema de control de versiones semántico, así que no,
El control de versiones semántico no se aplicará a la versión provisional.

-
Estás recibiendo esto porque eres el autor del hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/dmlc/xgboost/issues/4680?email_source=notifications&email_token=AAFFQ6GBEQSXJKFW6QDPN53QNDEALA5CNFSM4IE5CQGKYY3PNVWWK3TUL52HS4DFVREXWG43WZMV ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAFFQ6BYMDES3537PDMGE5DQNDEALANCNFSM4IE5CQGA
.

@CodingCat 1.0.0.preview.1 es una sugerencia interesante. ¿Maven acepta esta versión?

sí, puede tener letras no numéricas en el número de versión

El sábado 5 de octubre de 2019 a las 11:11 a.m. Philip Hyunsu Cho [email protected]
escribió:

@CodingCat https://github.com/CodingCat 1.0.0.preview.1 es un
sugerencia interesante. ¿Maven acepta esta versión?

-
Recibes esto porque te mencionaron.

Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/dmlc/xgboost/issues/4680?email_source=notifications&email_token=AAFFQ6H64Y75JBSSDRVYIS3QNDKFNA5CNFSM4IE5CQGKYY3PNVWWK3TUL52HS4DFVREXP63KSMVBWX ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAFFQ6BHKVVMQIDMRPY4DSTQNDKFNANCNFSM4IE5CQGA
.

Una versión provisional es una buena idea, hay muchas mejoras desde la 0.9.

Entendido, haré un poco de plomería en el sistema CI en los próximos días y luego prepararé la versión 1.0.0.preview.1.

@CodingCat ¿Qué tal 0.100 o 0.95? "Vista previa" parece que la versión 1.0.0 está a la vuelta de la esquina, pero tenemos algunas características importantes (PySpark) en juego.

¿Soporta peso xgboost?

No me preocupa la impresión de 1.0.0 para los usuarios.

La vista previa de Spark 3.0 se lanzará este mes, pero el lanzamiento formal es el próximo
Abril (alrededor de la cima de la chispa) tal vez

El martes 8 de octubre de 2019 a las 11:41 a.m. Philip Hyunsu Cho [email protected]
escribió:

@CodingCat https://github.com/CodingCat ¿Qué tal 0.100 o 0.95?
"Vista previa" parece que la versión 1.0.0 está a la vuelta de la esquina, pero
tiene bastantes características importantes (PySpark) en la línea.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/dmlc/xgboost/issues/4680?email_source=notifications&email_token=AAFFQ6AOGIWIB6W6TW3R5W3QNTH6TA5CNFSM4IE5CQGKYY3PNVWWK3TUL52HS4DFVDEAXWJWK3TUL52HS4DFVREXWG43V2MNDFVDFVREXWJWKNM39
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAFFQ6HF52HBR7ZNSKLIY3TQNTH6TANCNFSM4IE5CQGA
.

@CodingCat, al menos desde el punto de vista de xgboost4j-spark, esa vista previa 1.0.0 no será útil para la mayoría de las personas, ya que casi nadie está ejecutando Spark en 2.12. Además, no puede obtener fácilmente un binario compilado ya que https://spark.apache.org/downloads.html no distribuye versiones compiladas de Spark para 2.12 con los binarios de Hadoop incluidos.

¿Entonces no deberíamos soltar nada?

El jueves, 10 de octubre de 2019 a las 10:05 p.m. Mathew Wicks [email protected]
escribió:

@CodingCat https://github.com/CodingCat al menos desde el punto de vista
de xgboost4j-spark, esa vista previa 1.0.0 no será útil para la mayoría de las personas, ya que
casi nadie está ejecutando Spark en 2.12. Además, no puede obtener fácilmente
un binario compilado como https://spark.apache.org/downloads.html dosen't
distribuir versiones compiladas de Spark para 2.12 con los binarios de Hadoop
incluido.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/dmlc/xgboost/issues/4680?email_source=notifications&email_token=AAFFQ6AN3FJQ7ZE7EOTXLW3QOACSFA5CNFSM4IE5CQGKYY3PNVWWK3TUL52HS4DFVREXW63WTZVMVDFVREXWJ4WZMVD
o darse de baja
https://github.com/notifications/unsubscribe-auth/AAFFQ6EJRRMTNY7R7JVALTDQOACSFANCNFSM4IE5CQGA
.

@CodingCat @thesuperzapper Pensé que # 4574 permitiría compilar XGBoost con Scala 2.11 y 2.12. En ese caso, deberíamos compilar XGBoost con 2.11 y subir JAR a Maven.

Remoto:

• [] Liberar memoria de Gpu después del entrenamiento # 4668

No creo que podamos llegar allí ahora mismo.

@thesuperzapper Será más fácil desarrollar contra la rama Apache Spark master (3.0) y Scala 2.12 después de que Spark lance una vista previa 3.0 (prevista muy pronto este otoño). Esperaría un cambio mucho mayor a Scala 2.12 en la comunidad Spark después de la versión 3.0 final (dirigida a principios de 2020), pero tiene razón en que ahora no hay mucho uso de 2.12. Creé https://github.com/dmlc/xgboost/issues/4926 para solicitar una discusión sobre el próximo lanzamiento de Spark.

@CodingCat @thesuperzapper Pensé que # 4574 permitiría compilar XGBoost con Scala 2.11 y 2.12. En ese caso, deberíamos compilar XGBoost con 2.11 y subir JAR a Maven.

4574 no permite la compilación cruzada.

Lo que permite es que alguien verifique el código, anule manualmente la versión de Scala y vuelva a compilar

Entonces alguien puede compilar un jar con 2.11 y subirlo a Maven
Tuve una solicitud de extracción con migración a SBT que permitiría la compilación cruzada
También conozco el truco de cómo admitir una compilación cruzada en Maven (lo usamos en nuestra empresa). Puedo compartir si estas interesado

@ hcho3 ¿Es posible utilizar CPack para facilitar la instalación de OSX? Por favor ignore este comentario si no es posible.

¿Es compatible con el aprendizaje multiobjetivo?

@douglasren Lamentablemente no. ¿Podrías iniciar un nuevo número para que podamos discutirlo? El término "multiobjetivo" puede variar según los contextos, como una función de objetivo para múltiples resultados, múltiples objetivos con un solo resultado o múltiples objetivos con múltiples resultados.

También me gustaría emitir mi voto a favor de una liberación provisional.

5146 corrige # 4477.

Remoto:

• [] Compatibilidad con la API de PySpark (https://github.com/dmlc/xgboost/issues/3370) (https://github.com/dmlc/xgboost/pull/4656).

Una versión provisional sería genial, ya que la instalación de macOS sigue siendo un problema en este momento.

¿Podemos obtener soporte documentado para aprender a clasificar (por pares) con XGBoost4J-Spark? Actualmente, no existe una solución concreta sobre cómo especificar los datos de entrenamiento. Existe cierta confusión en torno a la partición por ID de grupo y los datos de entrenamiento que necesitan seguir la misma estrategia de partición, pero es bastante vago.
¡Un ejemplo o documentación clara sería de gran ayuda!

También me gustaría emitir mi voto a favor de una liberación provisional. Esperamos la próxima versión principalmente para la corrección de valor faltante de @cpfarrell (consulte https://github.com/dmlc/xgboost/pull/4805).

¿Existe una estimación de tiempo relacionada con la próxima versión (principal o provisional)?

PD: @thesuperzapper estamos usando 2.11 y 2.12 y una versión provisional sería extremadamente útil para nosotros

@ hcho3 ¿Podemos crear una rama de lanzamiento y tener una semana más o menos para probar?

¡Sí!

@ hcho3 Además de una rama, también podemos hacer un candidato de lanzamiento oficial en las versiones de GitHub para que la comunidad pueda tener más confianza para probarlo también.

¡Esto suena genial! Realmente espero con ansias el próximo lanzamiento. Avísame si podemos ayudarte. Definitivamente lo probaremos en Yelp.

Cortaré una nueva rama release_1.0.0 después de fusionar https://github.com/dmlc/xgboost/pull/5248 . Gracias a todos por su paciencia.

El candidato de lanzamiento ahora está disponible para Python: https://github.com/dmlc/xgboost/issues/5253. Puedes probarlo hoy corriendo

pip3 install xgboost==1.0.0rc1

1.0.0 ya está disponible:

pip3 install xgboost==1.0.0