1 puntos por GN⁺ 2024-09-15 | 1 comentarios | Compartir por WhatsApp
  • Cuando los datos de investigación genética se manejan en hojas de cálculo, el formato automático de Excel cambia nombres de genes y provoca errores en artículos
  • Este tipo de error se encontró en uno de cada cinco artículos de genética de revistas científicas de alto nivel, lo que expone debilidades en el proceso de validación de datos
  • La causa principal es que los nombres de genes se convierten automáticamente en valores de fecha o numéricos en Excel, por lo que el valor ingresado y el guardado terminan siendo distintos
  • Abreviaturas que pueden interpretarse como fechas, como SEPT2, se convierten en 2-SEP y pueden guardarse como un valor de fecha, por ejemplo 2 de septiembre de 2016
  • Si se sigue usando Excel, hay que definir las columnas con formato de texto y revisar manualmente los resultados; Google Sheets puede ser una alternativa para evitar el mismo error de conversión automática

Errores en nombres de genes causados por el formato automático de Excel

  • La función de formato automático de Microsoft Excel generó errores en datos de artículos de genética, y un nuevo análisis confirmó que uno de cada cinco artículos de genética en revistas científicas de alto nivel contiene este tipo de errores
  • El problema ocurre cuando la hoja de cálculo interpreta algunos nombres de genes como fechas de calendario o valores numéricos
  • El usuario cree haber ingresado un nombre de gen, pero los datos guardados pueden cambiarse por otro valor

Caso representativo

  • El gen Septin-2 suele abreviarse como SEPT2
  • Excel convierte SEPT2 en 2-SEP y puede guardarlo como la fecha 2 de septiembre de 2016
  • Esta conversión puede afectar la confiabilidad de listas de genes o datos de análisis incluidos en artículos

Métodos de mitigación y alternativas

  • Si se sigue usando Excel, se deben definir esas columnas con formato de texto y revisar cuidadosamente que no haya ocurrido una conversión automática
  • Google Sheets guarda los nombres de genes tal como se ingresan, por lo que puede ser una alternativa para evitar el mismo tipo de error de conversión automática
  • El análisis relacionado se publicó en Genome Biology

1 comentarios

 
GN⁺ 2024-09-15
Opiniones en Hacker News
  • Que Excel convierta automáticamente en números cadenas que parecen notación científica es realmente exasperante. Ni siquiera se puede desactivar.
    En exportaciones de datos a gran escala aparecen valores como códigos de ubicación únicos, y en algún momento algunos empiezan a verse raros; no es solo que cambió la visualización, sino que el contenido de la celda en sí fue modificado por Excel sin preguntar.
    No tiene sentido que, después de años, no arreglen estos problemas pequeños pero que siguen haciendo tropezar a la gente. Microsoft suele decir que “solo trabaja en lo que afecta a muchos clientes”, pero si siguen cerrando los reportes de bugs, siempre pueden decir que “solo afecta a una persona” y volver a cerrarlo.
    Más bien, si no se puede reproducir, deberían agregar depuración para la próxima vez, o manejarlo correctamente dejando una razón rastreable como: “hay pocas solicitudes, pero cambiarlo podría romper otras áreas o la compatibilidad con versiones anteriores”.

    • Sí, esa última razón es la clave. Es por la compatibilidad con versiones anteriores, bugs incluidos.
      Incontables macros, scripts VBA y flujos de trabajo creados por usuarios no técnicos dependen sutilmente de este comportamiento. Es parecido a las rarezas de JavaScript: si lo cambias, se rompen cosas viejas en algún lado.
      Microsoft podría decirlo más directamente, pero obviamente preferiría evitar esa discusión.
    • ¿Hay alguna razón para no especificar el formato de datos al importar? Si es un formato de archivo de datos que usan con frecuencia, también podrían automatizar la importación con VBA y especificar el formato de datos correcto.
    • El problema de que cadenas que parecen notación científica se conviertan automáticamente en números me pasa una o dos veces por semana. Me vuelve loco.
    • No entiendo por qué todavía usan MS Office cuando LibreOffice es gratis.
  • Hilo popular anterior de agosto de 2020: https://news.ycombinator.com/item?id=24070385
    Trataba sobre “científicos que cambiaron nombres de genes humanos para que MS Excel no los malinterpretara como fechas”.
    Como detalle relacionado, en 2023 Microsoft lanzó una actualización para evitar el problema de conversión de símbolos genéticos a fechas en Excel, y también existe Gene Updater, que corrige y actualiza automáticamente los nombres de genes que Excel reconoció mal.
    https://www.pcmag.com/news/microsoft-finally-fixes-excel-gli...
    https://www.ncbi.nlm.nih.gov/pmc/articles/PMC9325790/

  • Hay que conocer bien las herramientas. Al ver un título así, me entristece el estado del mundo y los obstáculos que frenan el progreso, me enoja la estupidez de diseñar todas las herramientas para el usuario más perezoso y, al mismo tiempo, me resultan graciosos los fracasos del software propietario y de sus usuarios.
    Puede que la herramienta que usas sea mala. En ese caso, tienes que lidiar directamente con esa mala herramienta, aprender una mejor, o traer a un experto en computación competente que pueda moverse por el ecosistema de herramientas y obtener resultados.
    Ni siquiera he mencionado todavía el problema de validar los resultados. En un entorno de investigación financiado con fondos públicos, pagarle a Microsoft para usar herramientas propietarias y terminar arruinándolo todo es una situación amarga.

    • Si trabajas en este campo, ves que una buena parte del problema está en que las editoriales exigen que los conjuntos de datos pequeños se envíen en formato xls al presentar artículos.
      Entonces alguien en algún punto de la cadena —el autor de correspondencia, el editor, personal de la revista, etc.— abre el archivo con Excel y lo vuelve a guardar. No es que los bioinformáticos estén haciendo análisis con Excel.
    • Exacto, las herramientas no se hacen para los usuarios, sino para los creadores de herramientas. Todos los demás tienen que adaptarse.
  • Una de las razones por las que dejé de usar hojas de cálculo en la enseñanza es que han seguido arrastrando el bug de precedencia de operaciones aritméticas. Aquí, “bug” significa que contradice una convención matemática de larga data.
    Si escribes -3^2 en una celda y presionas Enter, la hoja de cálculo dice 9. Pero en matemáticas, la potenciación tiene prioridad sobre el menos unario, así que debería ser -9. Por ejemplo, si le pides a un estudiante graficar y = -x^2, debería dibujar una parábola que se abre hacia abajo.
    No puedo verificarlo en el Excel más reciente, pero así era en Excel 97, y actualmente LibreOffice Calc también devuelve 9. Probablemente una de las primeras hojas de cálculo implementó mal la precedencia y luego todas las demás la siguieron por compatibilidad.
    En cambio, maxima y Python dan ambos -9. Me pregunto si las personas que copian fórmulas de libros de matemáticas a hojas de cálculo también se topan con este problema.

    • Este problema parece un subproducto del operador binario inventado ^. En matemáticas, el exponente es un superíndice, así que no es un operador binario, sino parte del término.
      En texto de computadora se inventó un operador binario para algo que no se podía representar directamente; el acento circunflejo es común y fue el primero en aparecer, pero ** es otro ejemplo.
      Tradicionalmente, el menos unario se ve como parte del término, por lo que tiene mayor precedencia que los operadores binarios. Pero si conviertes el exponente en un operador y aun así mantienes esa lógica, el asunto se enreda.
      Se ve un problema parecido con la división. / es un operador binario creado en entornos donde no existía un símbolo real de división, y originalmente debería representar la barra horizontal de una fracción. La barra de fracción agrupa toda la expresión a ambos lados, pero si se sustituye simplemente por /, las reglas de precedencia pueden afectar el resultado y producir valores incorrectos.
    • En C, -a*b se parsea como (-a)*b, pero c-a*b se parsea como c-(a*b). El menos unario tiene mayor precedencia que los operadores binarios.
      Normalmente no se nota porque se puede mover el signo, pero aparecen problemas en casos límite relacionados con comportamiento indefinido.
      0 - INT_MIN/2 se parsea como 0 - (INT_MIN / 2) y está bien, pero -INT_MIN/2 se parsea como (-INT_MIN) / 2 y no está bien. Por las características de la representación en complemento a dos, INT_MIN puede no tener inverso aditivo.
    • Esto suena demasiado a buscarle el pelo al huevo como razón para no usar un programa.
      Sé que existen dos convenciones para este problema, así que, si quiero obtener el comportamiento deseado, simplemente uso paréntesis.
      Me iba bien en matemáticas en la escuela, pero no sabía que hubiera gente que pensara que -3^2 debería ser -9; lo veía solo como una característica rara de algunas calculadoras o programas. También me da curiosidad cómo se lee esta expresión en voz alta. Si piensas “el cuadrado de menos 3”, (-3)^2 resulta natural; solo si lo lees como “el negativo del cuadrado de 3” tiene sentido que sea -9.
      En la secundaria nos enseñaron a ingresar una expresión así en la calculadora para ver un resultado distinto al esperado, y desde entonces solo pensé: “tendré que usar paréntesis”. Preferir una convención de precedencia ligeramente distinta no me parece suficiente para tirar la calculadora ni para decirle a otros que no la usen.
    • En el foro de Nim también se habló de algo parecido. En Nim, -2^2=4, pero 0-2^2=-4, porque el primer caso se interpreta como un - unario con prioridad sobre la potenciación.
      Se puede argumentar que técnicamente es correcto, pero para alguien con una formación común en ingeniería o ciencias que intenta hacer tareas normales resulta muy contraintuitivo. Creo que esto podría hacer que mucha gente deje de usar Nim.
    • En Excel, el operador de exponenciación no es más que una forma abreviada de la función POWER. Desde ese punto de vista, aunque matemáticamente pueda estar mal, me parece correcto como comportamiento de Excel.
  • El problema de Excel es que intenta hacer casi todo como una sola herramienta de software: edición y presentación en el front-end, análisis, modelado semántico e incluso almacenamiento de datos/base de datos.
    La mayoría de los ingenieros razonables ven algo mal en ese enfoque. Pero la mayoría de los usuarios cotidianos de computadoras creen que así es como debería ser la computación.
    A veces yo también me pregunto por qué abro Excel voluntariamente para ciertas tareas. Aun así, pese a todas las críticas, Excel para mí ya cruzó el umbral del efecto Lindy y seguirá existiendo.
    https://en.wikipedia.org/wiki/Lindy_effect

    • El costo de desarrollo de crear una solución “un poco mejor” que una hoja de cálculo compleja de Excel suele ser astronómico.
      Muchas startups tecnológicas consisten en “reemplazar con una herramienta dedicada lo que la gente hacía en Excel”.
    • Mi problema con Excel es que me gusta demasiado. Sé que no debería, pero me pasa.
      Como toca el punto perfecto entre datos estructurados y no estructurados, es muy cómodo simplemente llenar celdas y ver qué ocurre.
      La razón por la que se dice “no deberías hacerlo” es que puede ser muy doloroso salir de una solución que funciona bien y pasar a un enfoque basado en código debidamente convertido en producto.
    • Excel puede enviar correos con scripts VBA, así que cumple la ley de Zawinski.
      http://www.catb.org/jargon/html/Z/Zawinskis-Law.html
    • Sin embargo, como es software propietario, algún día dejará de recibir mantenimiento y dejará de funcionar. Pero las hojas de cálculo en general sí entran en el efecto Lindy, y el software de código abierto las mantendrá durante los próximos siglos.
  • En alemán existe el dicho “un mal trabajador siempre le echa la culpa a sus herramientas”.
    Excel tiene muchas rarezas, pero todavía agradezco que exista porque permite juntar números rápidamente y aun así cambiar los valores de entrada de las fórmulas.

    • Al mismo tiempo, en diseño de experiencia de usuario existe la idea de no culpar al usuario.
      Al menos en la época del artículo, no había forma de desactivar la función que convierte automáticamente ciertas cadenas como SEPT2 en fechas. Con solo haber tenido una configuración para desactivarla, se habrían evitado muchos errores cometidos por investigadores trabajando tarde en la noche o bajo presión por una entrega.
      Sin duda hay un punto en el que los usuarios de una herramienta deben esforzarse por aprender a usarla de la mejor manera. Pero del lado de los desarrolladores también se puede hacer un esfuerzo para evitar errores comunes y ahorrarles mucho tiempo a los usuarios.
    • Un mal trabajador le echa la culpa a sus herramientas, pero nadie puede escribir la Biblia sobre una estampilla usando una zanahoria.
    • Hay un matiz en este dicho que suele pasarse por alto: significa no culpar a “tus propias herramientas”.
      No a todas las herramientas. No a herramientas impuestas por estándares industriales obsoletos o por costumbre, ni a herramientas tontas que nunca usarías si tuvieras otra opción.
      Excel tampoco inventó las hojas de cálculo. Si Excel no existiera, se habría usado algo como el sucesor de WhateverCalc de ese momento, y Excel solo le agregó cosas innecesarias.
    • Creo que lo que hay que agradecer aquí no es Excel, sino la existencia de las aplicaciones de hojas de cálculo.
      https://simple.wikipedia.org/wiki/Spreadsheet
    • En polaco existe el dicho “a una mala bailarina de ballet le estorba el dobladillo de la falda”.
  • ¿Por qué diablos no se puede desactivar el reconocimiento automático de fechas? Bastaría con poner una casilla en la configuración para que yo, como usuario, pueda decirle a Excel que no haga esa estupidez.
    ¿Hay alguien que pueda defender de forma irrefutable que esto deba estar siempre activado?

    • Si pones una casilla escondida en lo profundo de la configuración, agregas más caminos por los que las cosas pueden salir mal.
      ¿Cuál es el valor predeterminado? ¿Cambia según la versión? ¿Cómo mantienes la consistencia entre distintas computadoras e instalaciones? ¿Qué pasa si en el momento realmente necesitas esa función?
      Me recuerda a la exportación CSV. No he usado Windows en 10 años, pero recuerdo que para cambiar la forma de exportar números decimales había que cambiar la configuración regional y reiniciar la computadora. Hacer eso solo para cambiar una configuración de Excel es una locura. Repartir parches con casillas por todos lados no es muy distinto.
    • Además de la forma de configurar todas las celdas como texto, ahora se agregó una casilla para este problema.
      https://insider.microsoft365.com/en-us/blog/control-data-con...
  • Hace dos semanas me pasó algo parecido en el trabajo. Estaba extrayendo archivos de log y escribí un script en awk que convertía marcas de tiempo HH:MM:SS.uuuuuu a nanosegundos desde el epoch para que otra herramienta pudiera consumirlas.
    Pero no sabía que awk usa punto flotante internamente para los números, y la función de conversión redondeó mal el resultado, arruinando el análisis posterior de una manera difícil de entender.
    Para empeorar las cosas, al revisar los datos en Visidata volvió a aparecer el mismo problema, aunque había una solución alternativa sencilla que no recuerdo exactamente.

  • En el trabajo he sufrido varias veces que Excel cambie valores numéricos de entrada por culpa de distintos formatos regionales, y muchas veces perdí horas hasta descubrir que la causa era Excel.
    Valores como números de identificación nacional o números de teléfono también son tipos totalmente incómodos para Excel. Son usos mucho más comunes que los genes, así que deberían estar más cerca de los casos de uso estándar de Excel, pero igual los rompe.
    Incluso en 2024, abrir un archivo CSV en Excel no es una tarea simple que debería resolverse con doble clic, sino algo excesivamente complicado. Otros programas de hojas de cálculo manejan los archivos CSV con mucha más facilidad.
    Lo peor es que Excel suele ser usado por usuarios no técnicos, y estos comportamientos raros se malinterpretan y hacen perder tiempo una y otra vez.

    • Mi frustración con Excel en el trabajo no es tanto Excel en sí, sino que la gente rompe, borra, no entiende o “mejora” fórmulas, y el resultado final termina siendo basura.
      Aunque por lo general la culpa es mía por no usar suficientemente bien las funciones de protección y bloqueo. También sé que las notas explicativas se ignoran.
      Por eso, en los archivos compartidos casi siempre dejo una copia de respaldo inicial vacía y mantengo separado el archivo que se va a usar realmente, lo que ayuda un poco.
  • También es interesante el artículo de 2016 sobre el mismo tema, “Gene name errors are widespread in the scientific literature”.
    https://genomebiology.biomedcentral.com/articles/10.1186/s13...
    Según el artículo, el problema de que el software Excel convierta por error símbolos de genes en fechas y números de punto flotante fue descrito por primera vez en 2004. Por ejemplo, símbolos de genes como SEPT2 y MARCH1 se convierten de forma predeterminada en 2-Sep y 1-Mar, respectivamente.