Charla de Wikipedia: WikiProject Matemáticas

Transición a la representación de MathML como predeterminada

Se está llevando a cabo un posible cambio importante en el motor de matemáticas T271001  • Transición a la representación de MathML como predeterminada. Hay una introducción en fases, con la creación de una wiki de prueba primero y la implementación en las wikis de producción en diciembre. Dependerá de la compatibilidad nativa con MathML en Firefox, Chrome versión > 109 (actualmente estamos en la v128). Creo que esto significa el fin de la representación de ecuaciones matemáticas del lado del servidor.

Parece que el trabajo técnico está hecho y la siguiente fase es...

Fase 2A: Producción

Comunicación a noticias tecnológicas y wikitech-l sobre planes y wikis piloto

Así que parece que es el momento adecuado para mencionarlo aquí. Salix alba ( discusión ): 07:51 18 sep 2024 (UTC) [ responder ]

Esto es malo. Muchos de los elementos de la "prueba de tortura" en https://www-archive.mozilla.org/projects/mathml/demo/texvsmml.xhtml se ven extremadamente mal tanto en Firefox como en Chrome. (Ejemplos: en la fracción continua del n.° 6, para mí, el 1 en la parte superior es diminuto, mucho más pequeño que el resto, para mí en ambos navegadores. En el n.° 14, el varphi se ha convertido en el otro tipo de phi. En el n.° 17, hay un espacio enorme entre los signos integrales). Espero que este no sea "el fin de la representación del lado del servidor de ecuaciones matemáticas" porque si hay una preferencia por mantener la representación antigua, probablemente la usaré. Pero los lectores que no hayan iniciado sesión no tendrán esa opción. — David Eppstein ( discusión ) 07:59, 18 de septiembre de 2024 (UTC) [ responder ]

Para ser justos, nunca se debería transmitir un significado a través de la diferencia entre phi y varphi y epsilon y varepsilon. Se trata simplemente de una diferencia en la fuente, que por razones misteriosas Knuth decidió asignar a comandos diferentes.

En cuanto a la prueba de tortura, las que me molestan son los tamaños incorrectos de los coeficientes binomiales en los números 8 y 9, los tamaños incorrectos del símbolo de suma en los números 10, 12 y 21, los tamaños incorrectos de los signos integrales en los números 16, 17 y 21, y el tamaño incorrecto del símbolo determinante en el número 24. Eso es para Firefox. Chromium tiene problemas mucho más profundos. Tercer ( discusión ) 09:36 18 sep 2024 (UTC) [ responder ]

La constante de lemniscata se denota por varpi, fwiw. Tito Omburo ( charla ) 09:40, 18 de septiembre de 2024 (UTC) [ respuesta ]

La prueba de tortura de MathML es un documento muy antiguo, el primer comentario tiene 23 años. MathML está codificado como código MathML sin procesar y puede que no sea la mejor manera de representar el código Latex correspondiente. Por ejemplo, tomemos el número 12, si configuro mi modo de representación de Wikipedia en MathML e ingreso el código Latex obvio para esto, obtengoMucho mejor que en la prueba de tortura.

Podría valer la pena intentar codificar el resto de la Prueba de Tortura, que carece del LaTeX correspondiente, para que podamos obtener una comparación verdadera. -- Salix alba ( discusión ): 15:49 18 sep 2024 (UTC) [ responder ]

Buen punto, no sabía que estaba obsoleto. He escrito algunas pruebas más en User:Tercer/math . Se ven bien. No pude descubrir cómo obtener la representación en paralelo, así que para obtener la comparación abrí esa página en una pestaña, luego cambié mi preferencia de representación matemática y la abrí nuevamente en otra pestaña.

Cualquiera puede escribir más pruebas allí. Tercer ( discusión ) 20:15 18 sep 2024 (UTC) [ responder ]

En phab dicen que eventualmente cambiaremos los valores predeterminados y entregaremos imágenes de respaldo realmente como una opción de respaldo , entonces, ¿eso no significa que tienen la intención de mantener la representación de texto a imagen del lado del servidor como una opción de respaldo? Dados los problemas persistentes en la prueba de tortura que mencionas (aunque recién estoy viendo el comentario anterior que dice que deberíamos volver a probar la prueba de tortura), diría que esta opción será necesaria en el futuro previsible. También como respaldo para la accesibilidad. SamuelRiv ( discusión ) 15:55, 18 de septiembre de 2024 (UTC) [ responder ]

Esta parece una idea mala y bastante inútil que ignora por completo las antiguas peticiones prácticas de la gente de mejoras en el renderizador actual. ¿Por qué el equipo técnico nunca pide lo que necesitan los autores matemáticos en lugar de perder toneladas de tiempo en lo que sea que cumpla con los requisitos de marketing? "Lanzamiento a wikis de producción en diciembre" : si las páginas actuales se muestran mal, entonces ciertamente no es aceptable implementarlo en "producción" en la Wikipedia en inglés. Los editores de matemáticas y el resto de la comunidad de Wikipedia lucharán contra usted en cada paso del camino. – jacobolus (t) 02:53, 19 de septiembre de 2024 (UTC) [ responder ] 

No tiene sentido seguir diciendo lo malo que es MathML, ya que no hay necesidad de insistir en algo que ya está muy de moda. Por lo tanto, diré simplemente que TeX es el estándar de oro para la composición tipográfica matemática y Computer Modern es la familia de fuentes matemática de oro. MathML ni siquiera se acerca, pero MathJax y KaTeX sí. Los sitios de matemáticas populares como Stack Exchange y Brilliant usan MathJax/KaTeX; en mi opinión, MathJax con salida SVG es el que se ve mejor.

Por lo tanto, Wikipedia debería dejar de lado la representación de MathML como predeterminada y, en su lugar, debería arreglar su implementación defectuosa de MathJax y convertirla en predeterminada (o implementar KaTeX), siempre que realmente necesitemos un cambio. A1E6 ( discusión ) 18:16, 21 de septiembre de 2024 (UTC) [ responder ]

Familia matemática dorada : Computer Modern no es inherentemente mejor que otras fuentes matemáticas bien producidas, y hay mucha tipografía matemática excelente que utiliza una variedad de otras fuentes (aunque debido a que la composición tipográfica matemática requiere muchos símbolos inusuales, hay una elección significativamente menor que con las fuentes de uso general). Computer Modern es la más común en los últimos años porque es la predeterminada de LaTeX, pero ciertamente no tenemos que usarla. No es mi favorita personal, y con un proceso deliberado creo que Wikipedia podría elegir una mejor colección de fuentes: para encabezados, cuerpo de texto, subtítulos, tablas, notas al pie, notación matemática, ..., y tal vez incluso promover el uso de fuentes consistentes en mapas y diagramas. Estoy seguro de que si se hiciera un alcance significativo a la comunidad en general (incluidos matemáticos, tipógrafos matemáticos, diseñadores tipográficos, expertos en TeX, ...) podríamos obtener algunos comentarios de calidad, si hubiera un objetivo de elegir una fuente diferente. Cualquier fuente matemática utilizada por Wikipedia debe tener soporte adecuado para todas las características utilizadas por los artículos de Wikipedia. O podríamos intentar elegir fuentes para el cuerpo del texto que armonicen mejor con Computer Modern. (Para cualquiera de los criterios, permítanme incluir a Charis SIL como un ejemplo que al menos vale la pena analizar). El capítulo correspondiente de TeX Unbound de Hoenig (1998) puede resultar útil.

Independientemente de las fuentes que elijamos, hay muchos detalles sutiles de espaciado, tamaño y posicionamiento de elementos en la página impresa con un conjunto de convenciones tradicionales bien establecidas desde hace siglos cuyos detalles se pueden encontrar en libros como Chaundy, Barrett y Batey (1954) The Printing of Mathematics, Swanson (1971) Mathematics into Type, Krantz (2000) Handbook of Typography for Mathematical Sciences , etc. Cualquier tipo de tecnología de renderizado debe implementarse con cuidado para sudar los detalles, de modo que el resultado sea legible, consistente e idealmente hermoso.

La salida tipográfica de LaTeX no es la única forma de hacer las cosas, y a menudo encuentro que LaTeX toma decisiones tipográficas con las que no estoy de acuerdo en casos extremos, a veces en función de diferencias de gusto/preferencia y a veces por razones técnicas. Como ejemplo simple, los paréntesis alrededor de las sumas ⁠ ⁠ ${\displaystyle \textstyle \sum }$ que usan \left( y \right) son casi siempre demasiado grandes en LaTeX porque estos comandos eligen el tamaño en función de las dimensiones de una "caja" de contenido en el interior, y no son lo suficientemente sofisticados como para implementar la convención de la excelente tipografía matemática tradicional de que los paréntesis deben cubrir el símbolo ⁠ ⁠ ${\displaystyle \textstyle \sum }$ pero en general no extenderse más allá de los índices.

– jacobolus  (t) 19:31 21 septiembre 2024 (UTC) [ responder ]

Ciertamente no tenemos que usar Computer Modern, pero a los matemáticos les encanta usarlo. :) A1E6 ( discusión ) 19:58 21 sep 2024 (UTC) [ responder ]

Y, por supuesto, habrá algunos tipógrafos que puedan justificar el uso de familias de fuentes distintas a Computer Modern. El caso es que creo que MathJax con salida SVG y KaTeX son las mejores soluciones que existen. No podemos dejar que MathML sea la opción predeterminada. A1E6 ( discusión ) 00:24 22 sep 2024 (UTC) [ responder ]

Intenté habilitar la representación exclusiva de MathML en Firefox y miré cuatro artículos con muchas ecuaciones. Había muchos problemas visibles. Se vuelve mucho más obvio si ves el mismo artículo con ambas representaciones una al lado de la otra en pestañas o ventanas separadas.

• El estilo de visualización de Mathml está centrado y es mucho más pequeño que SVG en general. Tal vez este tamaño coincida con el texto del cuerpo, pero me parece demasiado pequeño, más como un estilo de texto que como un estilo de visualización. La visualización centrada frente a la visualización con sangría a la izquierda para otras representaciones hace que sea imposible que coincida con otro formato que no sea puramente matemático en cada línea (como una ecuación mostrada más una nota al pie de referencia): si formatea esas otras líneas para que coincidan con la visualización centrada de Mathml, no coincidirá con la visualización con sangría a la izquierda de SVG y viceversa.
• En la proporción áurea , la barra superior del signo de la raíz cuadrada está desalineada. La primera tiene un grosor visiblemente más estrecho que el signo radical al que se conecta, y algunas otras tienen espacios visibles. ${\displaystyle {\sqrt {5}}}$
• En la función Gamma , la ecuación multilineal en "La definición de Euler como un producto infinito" tiene varias anotaciones "[8pt]" visibles y hay muy poco espacio alrededor de los puntos. Más adelante, después de "En particular, con z = a + bi, este producto es", la ecuación mostrada tiene una barra vertical izquierda enorme, que no coincide con la barra vertical derecha.
• En Dehn invariante , en "Sólidos platónicos", la fórmula tiene un espaciado inusualmente amplio alrededor del signo de división. En "Realizabilidad", hay demasiado espacio entre los dos símbolos en . Más problemas con sqrt5: la parte inferior del signo sqrt se encuentra por encima de la línea base cuando debería estar por debajo. En , el signo menos es mucho más pesado que el sólido. Curiosamente, cuando veo exactamente la misma fórmula en esta página, se ve diferente, con un sólido más grueso y un espaciado mucho más estrecho entre el signo menos y el sólido. ${\displaystyle \pi /2}$ ${\displaystyle \mathbb {R} ^{3}}$ ${\displaystyle -{\tfrac {1}{3}}}$
• En la fracción continua , en la sección "Fórmula básica", los numeradores y denominadores se hacen cada vez más grandes a medida que se avanza en la fracción: b2 es más grande y está más en negrita que b1, y b3 es más grande y está más en negrita que b2. Lo mismo ocurre con otras fracciones continuas en la misma página.

Cuando veo matemáticas con SVG no veo estos problemas. — David Eppstein ( discusión ) 21:02 18 sep 2024 (UTC) [ responder ]

Parece que todavía hay muchos errores. Aquí hay otro: en Tsirelson's_bound#Tsirelson's_problem el redimensionamiento automático de \langle y \rangle se realiza incorrectamente, lo que estropea los sujetadores y los kets. ¿Tal vez exista un lugar adecuado para informar sobre ellos? No creo que sea productivo hacer una lista exhaustiva aquí. Tercero ( discusión ) 07:56 19 sep 2024 (UTC) [ responder ]

Estoy confundido. Pensé que "Transición a la representación de MathML como predeterminada" estaba muerta, básicamente por la falta de compatibilidad de los navegadores. Mi impresión es que MathML es una idea aparentemente agradable que no llegó a ninguna parte, tal vez porque ya tenemos Latex. Por lo tanto, no podemos esperar un futuro en el que los navegadores principales admitan MathML de forma nativa y, por lo tanto, hablando en términos generales, apuntar a MathML como predeterminado parece incorrecto. Entiendo que los desarrolladores son voluntarios, por lo que pueden trabajar en lo que quieran y también proporcionar MathML como una opción en sí misma no tiene por qué estar prohibido. Pero no creo que pueda ser un valor predeterminado en el futuro cercano (no sé sobre el futuro lejano como 2044). Taku ( discusión ) 05:23, 19 de septiembre de 2024 (UTC) [ responder ]

@ TakuyaMurata : Descargo de responsabilidad: comencé como voluntario. Ahora trabajo en FIZ Karlsruhe , que organiza zbMATH Open . Esto me permite mantener un contacto regular con la Unión Matemática Internacional y con representantes locales de la comunidad matemática.

Desde principios de 2023, Chrome es compatible con MathML, lo que parece cambiar las reglas del juego y convertir a MathML, que fue parte de HTML5 desde el principio, en un estándar de facto. El nuevo lenguaje MathML, que se adaptó a los desarrollos CSS "modernos", también tiene una versión actualizada de la prueba de tortura. Para mí, los problemas señalados por @ David Eppstein : son útiles. Estos ejemplos se pueden utilizar para comprobar si hay un problema con el código MathML (que probablemente pueda solucionar en unos minutos) o si hay un problema en el navegador (en ese caso, es posible que se solucione cuanto antes cuanto más ruido haga uno). Personalmente, creo que es una buena idea cambiar a MathML después de que se solucionen los errores reales y tolerar las cosas que no verías si no usas dos ventanas (como sugirió @ David Eppstein : ). Con los años, me acostumbré a la forma en que HTML muestra las fórmulas y hoy puedo vivir con eso, aunque creo que un estilo Wikipedia como https://latex.vercel.app/ sería mejor.

Plan para la transición a la representación nativa de MathML. Ver phab:T271001

Algunos argumentos a favor de MathML

• MathML ahora es compatible con todos los navegadores principales
• Es accesibilidad para personas con visión limitada por ejemplo a través de teclados Braille.
• Admite copiar y pegar.
• La página es mucho más pequeña y por lo tanto se carga más rápido y consume menos energía.
• ...

Por lo que tengo entendido, no es posible, por razones técnicas, mantener el sistema actual basado en SVG en funcionamiento durante más de noviembre + \epsilon este año. Los detalles están por encima de mi nivel de comprensión. Physikerwelt ( discusión ) 14:59 19 sep 2024 (UTC) [ responder ]

No es posible por razones técnicas mantener el sistema actual basado en SVG funcionando más allá de noviembre + \epsilon este año. – "¿No es posible" o simplemente "nadie quiere hacerlo"? El esfuerzo social/técnico debería ir en cambio a arreglar eso, porque la representación actual de MathML es completamente inaceptable y adoptarla por defecto haría que los artículos de matemáticas de Wikipedia se vean peor de lo que se han visto en cualquier momento en la historia de Wikipedia. La antigua representación de imágenes PNG pixeladas en LaTeX era significativamente mejor. El problema es que el espaciado de todo en la versión MathML es completamente irregular y está roto: a veces los símbolos están demasiado amontonados, otras veces están demasiado espaciados, a veces las líneas de base son demasiado altas, otras veces demasiado bajas. Muchos de los símbolos individuales son feos, ilegibles y de tamaño inadecuado para el contexto; a veces su apariencia es gratuitamente diferente de la versión LaTeX prevista por los autores.

No sé si los diversos problemas se deben a un mal diseño de MathML, malas implementaciones de MathML en el navegador, CSS descuidado, una mala elección de fuentes o qué, pero imagino que se necesitaría un esfuerzo técnico significativo (estamos hablando de años de espiar y ajustar los detalles) para que la propia Wikipedia pudiera solucionar todos los errores y peculiaridades de MathML y ​​presentar algo que se viera profesional, mucho más allá de mi comprensión de la capacidad técnica de Wikipedia. Pero lo que hay ahora parece un garabato incompetente y perturbado.

Si realmente no es posible mantener el renderizador SVG actual, entonces deberíamos intentar adoptar MathJax o KaTeX en su lugar. Según mi experiencia personal, se pueden utilizar para reproducir tipografías matemáticas de aspecto profesional. Seguiría siendo una enorme y molesta cantidad de trabajo reemplazar todos los ajustes sutiles realizados en el marcado matemático de los artículos suponiendo que el renderizador actual se adapte a un nuevo renderizador, pero al menos habría algo de luz al final del túnel. – jacobolus  (t) 15:50, 19 de septiembre de 2024 (UTC) [ responder ]

Por supuesto, en principio es posible mantener en funcionamiento el sistema de renderizado SVG, pero nadie quiere dedicar el enorme esfuerzo necesario para algo que de todos modos no tiene futuro. Internet en su totalidad ha dejado de ofrecer matemáticas en forma de imágenes, por muy buenas razones. Solo Wikipedia está estancada en el siglo XX. Ese esfuerzo se emplearía mucho mejor en corregir errores en MathML y ​​MathJax. Tenga en cuenta que el renderizado de MathJax ya es una opción. Tercer ( discusión ) 16:18, 19 de septiembre de 2024 (UTC) [ responder ]

La versión actual de renderizado de "MathJax" también es pésima, con muchos fallos en casos extremos. ¿Quizás no se estén enviando o utilizando las fuentes correctas? El siglo XX fue un siglo maravilloso, y lo que les importa a los editores y lectores es si su contenido se reproduce correctamente, no lo modernos que sean los desarrolladores. – jacobolus  (t) 03:33, 20 de septiembre de 2024 (UTC) [ responder ]

No se trata de estar "a la moda". Presentar matemáticas en forma de imágenes es una idea terrible, y me alegra que Wikipedia finalmente se esté alejando de ello. Tenga en cuenta que no hay nada malo con MathJax en sí; Stack Exchange lo usa, por ejemplo, y se ve genial. Wikipedia solo necesita corregir sus errores. Tercer ( discusión ) 10:03, 20 de septiembre de 2024 (UTC) [ responder ]

@ Tercero No hay nada malo con MathJax per se como tecnología, y he usado MathJax para crear tipografía matemática de excelente apariencia en mis propios proyectos fuera de la wiki, pero los resultados visuales cuando hago clic en "MathJax" en mis preferencias de Wikipedia son inaceptablemente malos, por lo que sería necesario hacer un esfuerzo para descubrir cuál es el problema y solucionarlo antes de que podamos considerar de manera significativa adoptarlo como predeterminado.

"Nadie quiere dedicar el enorme esfuerzo necesario" – Lo que estás defendiendo como alternativa es obligar a los autores voluntarios a dedicar probablemente >100 veces más que ese supuesto "enorme esfuerzo" para arreglar todas las páginas que utilizan matemáticas en el sitio, con un resultado final que seguirá siendo visualmente peor que lo que teníamos antes, pero al menos esperamos que no esté completamente roto. Creo que hablo en nombre de la mayoría de los autores de wikis cuando digo que nadie quiere dedicar ese esfuerzo a las tareas posteriores. De hecho, creo que la propuesta está cerca de ser una locura y es profundamente ofensiva para los autores de artículos.

Servir matemáticas como imágenes es una idea terrible . Objetivamente, ha funcionado bien durante años, aunque ciertamente, si se hubiera puesto más esfuerzo por parte de los desarrolladores en el sistema actual, muchos de sus problemas podrían mejorarse, como una mejor compatibilidad con copiar y pegar, un mejor soporte para herramientas de accesibilidad, etc. Pero, en general, SVG parece una tecnología bastante apropiada para diseñar gráficos bidimensionales complicados, como la notación matemática. KaTeX (ab)usa HTML en su lugar. La tecnología de diseño subyacente no es realmente la parte importante: lo que importa es que alguien haga las miles de horas de espionaje y ajustes cuidadosos del código para asegurarse de que la tipografía se represente correctamente, lo que implica muchas decisiones minúsculas de espaciado y posicionamiento. No sé si es técnicamente posible o no hacer esto bien con MathML, pero la demostración actual de MathML es inaceptablemente mala. – jacobolus  (t) 15:24, 20 de septiembre de 2024 (UTC) [ responder ]

No, las imágenes no han funcionado bien. Han sido un dolor de cabeza desde que existe Wikipedia. Chocan con la fuente del texto, son difíciles de alinear correctamente, hacen que las páginas sean significativamente más pesadas y no se pueden copiar y pegar. Como son malas, la gente siempre ha intentado usar alternativas, como usar texto en cursiva para variables simples o trucos como , , y . Se ven terribles y son difíciles de editar. Lo que necesitamos es un <math> que funcione correctamente, y esto nunca sucederá mientras siga generando imágenes.{{math}}{{radic}}{{sfrac}}

Pero en general, SVG parece una tecnología bastante apropiada para diseñar gráficos bidimensionales complejos, como la notación matemática. Es una tecnología tan inadecuada que nadie más la usa. Ni otros sitios web, ni editoriales científicas, ni LaTeX, ni Word, ni nada.

Creo que hablo en nombre de la mayoría de los autores de wikis cuando digo que nadie quiere dedicar ese esfuerzo a la parte final. De hecho, creo que la propuesta es casi una locura y profundamente ofensiva para los autores de artículos. Soy un autor de wikis y estoy dispuesto a dedicar el esfuerzo, así que puedes dejar de decir "nadie". Tercer ( discusión ) 16:07 20 sep 2024 (UTC) [ responder ]

"Enfrentan problemas con la fuente del texto" : no se trata de un problema de tecnología, sino de la pésima estrategia de Wikipedia para la tipografía de los artículos en general. Wikipedia debería incluir una fuente matemática serif (y debería considerar seriamente cambiar todo el texto principal a una fuente serif para facilitar su lectura en las pantallas de alta resolución, que ahora son omnipresentes), y debería usarla tanto en HTML simple como en las etiquetas <math>. Esta fuente o fuentes deberían incluir todas las sutilezas tipográficas necesarias para representar correctamente todas las matemáticas necesarias en cualquier artículo, incluidos múltiples tamaños ópticos para su uso en fracciones anidadas, superíndices, supersuperíndices, etc.

Difícil de alinear correctamente ¿Quieres decir que la alineación de la línea base vertical está mal? Este debería ser un problema técnicamente solucionable y parece algo en lo que el equipo técnico podría querer trabajar como una mejora útil si les importa brindar el mejor soporte a los autores de wikis.

Hacer que las páginas sean significativamente más pesadas : ¿puedes explicar qué quieres decir con "más pesadas"? Las imágenes SVG no requieren un ancho de banda de red particularmente alto.

No se puede copiar y pegar : Wikimedia debería considerar donar algo de dinero a los desarrolladores de MathJax para que trabajen en este problema. Ninguna de las opciones de visualización que actualmente se pueden marcar con preferencias tiene un buen soporte para copiar y pegar. Averiguar qué se debe copiar cuando alguien intenta seleccionar alguna notación matemática es un problema técnico difícil que no es exclusivo de Wikipedia.

Debido a que apestan, la gente siempre ha tratado de usar alternativas ; no, la gente usa alternativas porque esta es una wiki seudónima mundial y hay miles de personas al azar con distintos niveles de conocimiento, interés y habilidad, y muchas personas tienen preferencias contradictorias; este no es realmente un problema técnicamente soluble, aunque estoy de acuerdo en que sería bueno si pudiéramos hacer un mejor trabajo agilizando la entrada de matemáticas.

"Soy un autor de wiki y estoy dispuesto a hacer el esfuerzo" (a) ¿Te estás ofreciendo personalmente a corregir todos los artículos que utilizan matemáticas en la Wikipedia en inglés y (b) tienes la competencia tipográfica para hacer que cada ejemplo se vea tan bien o mejor bajo una nueva versión de lo que se veía? "Una persona está dispuesta a corregir un puñado de páginas", e incluso podría ser capaz de reclutar a algunas otras personas no es una solución convincente para un problema que potencialmente requerirá muchos años de esfuerzo. A juzgar por tu creencia personal de que la salida MathML se ve mejor que la salida LaTeX->SVG, no tengo fe en tu competencia tipográfica, con el debido respeto a tus intenciones. – jacobolus  (t) 19:46, 20 de septiembre de 2024 (UTC) [ responder ]

Estás siendo hipócrita y, además, me estás insultando. Me niego a seguir interactuando contigo y te agradecería que también te abstuvieras de hablar conmigo. Tercer ( discusión ) 20:38 20 sep 2024 (UTC) [ responder ]

Cuando llamas a alguien mentiroso intencional aquí, como lo acabas de hacer, debes ser específico sobre qué crees exactamente que dijo falsamente y con la intención de mentir. De lo contrario, la gente podría pensar que estás violando la WP:NPA . — David Eppstein ( discusión ) 21:14, 20 de septiembre de 2024 (UTC) [ responder ]

Estoy siendo bastante duro aquí, en respuesta a varias de sus afirmaciones que considero que están en algún punto entre equivocadas y completamente fuera de lugar. Pero por lo que puedo decir, su argumento sobre la apariencia per se se reduce a "Creo que las fuentes desiguales son realmente feas"; esa parte es una cuestión de gustos y no estoy del todo en desacuerdo, pero (a) hay muchas cosas alternativas que podríamos intentar hacer como proyecto para lograr que las fuentes coincidan mejor, lo que valdría la pena discutir (la elección de la fuente es independiente de la elección de la tecnología de renderizado) y (b) pisotear el resto de los detalles de las convenciones tipográficas matemáticas en pos del beneficio principal de tener fuentes coincidentes es, en mi opinión como alguien a quien le importa mucho la tipografía matemática, una compensación completamente inaceptable. Me sorprendería sinceramente si pudiera encontrar una sola persona con una experiencia tipográfica significativa (por ejemplo, un tipógrafo profesional de libros de matemáticas, ya sea que utilice herramientas digitales o impresiones en metal hechas a mano) que considere que los ejemplos de MathML generados por Wikipedia con la configuración de preferencias actual son mínimamente aceptables. – jacobolus  (t) 21:54, 20 de septiembre de 2024 (UTC) [ responder ]

Gracias por tu comentario. Sin embargo, no sé qué conclusión sacar de ello.

Puedo trabajar con la lista de David anterior, investigar la diferencia caso por caso y explicar las diferencias.

Por ejemplo, \sqrt5se traducirá y se reproducirá en el navegador. Demostración en vivo<msqrt><mn>5</mn><msqrt>

viejo: vs nuevo: ${\displaystyle {\sqrt {5}}}$${\displaystyle \sqrt{5}}$

Por lo tanto, este es un muy buen ejemplo (mínimo) para definir lo que está mal. Al menos en mi pantalla no veo "grosor más estrecho" ni "huecos visibles". Physikerwelt ( discusión ) 17:39 19 sep 2024 (UTC) [ responder ]

La apariencia de la segunda raíz cuadrada presumiblemente depende de la fuente que se use. La lista presentada en el CSS es "Latin Modern Math", "STIX Two Math", "XITS Math", "STIX Math", "Libertinus Math", "TeX Gyre Termes Math", "TeX Gyre Bonum Math", "TeX Gyre Schola", "DejaVu Math TeX Gyre", "TeX Gyre Pagella Math", "Asana Math", "Cambria Math", "Lucida Bright Math", "Minion Math", STIXGeneral, STIXSizeOneSym, Symbol, "Times New Roman", serif; en mi navegador, esto termina siendo representado usando STIXGeneral, que está instalado.

Dejar que la apariencia dependa del navegador de cada lector (según las fuentes que tenga instaladas) es una idea extremadamente mala. Nos vemos obligados a depurar no solo problemas de MathML y ​​del analizador, sino también errores y peculiaridades de las fuentes en más de 17 fuentes completamente diferentes. No hay forma de que los autores puedan solucionar ese tipo de incertidumbre/variedad sin comprometer por completo la buena apariencia (y mucho menos la consistencia).

Cualquier representación matemática en la que el contenido escrito en un lugar esté destinado a ser leído por una amplia variedad de personas con compatibilidad inconsistente con las fuentes de la plataforma debería incluir explícitamente una fuente específica para su uso. Yo recomendaría incluir algo relativamente similar a Computer Modern porque esto causará muchas menos interrupciones y brindará una mejor comparación entre tecnologías.

De todos modos, la elección entre tus dos ejemplos se reduce a preferencias personales sobre la apariencia de los símbolos √ y 5 en Computer Modern (a la izquierda) vs. lo que elija tu computadora (a la derecha), porque esta es una fórmula trivialmente simple que no involucra mucho espaciado complicado o enfatiza las peculiaridades de la implementación (supongo que más allá de cumplir con los requisitos mínimos de adjuntar la línea superior al √). Creo que el símbolo de raíz cuadrada "viejo" se ve mejor que el "nuevo" en mi navegador, pero el nuevo también está más o menos bien. Pero este no es el tipo general de ejemplo con el que la gente estará más descontenta. – jacobolus  (t) 03:50, 20 de septiembre de 2024 (UTC) [ responder ]

Usando Firefox en mi teléfono, sin personalización de fuentes ni nada por el estilo, la parte diagonal y el segmento horizontal en el "nuevo" no se unen correctamente. XOR'easter ( discusión ) 23:46 22 sep 2024 (UTC) [ responder ] ${\displaystyle {\sqrt {5}}}$

MathML debería funcionar bien para la gran mayoría de usos de <math> en wikis. Pero hay una pequeña cantidad de artículos de WP en los que la representación consistente de fórmulas clave es fundamental. Si realmente hay que desechar el sistema de representación de svg a gran escala (lo ideal sería tener una propiedad de forzado dentro de la etiqueta <math>), igualmente propondría mantener disponible el sistema base para generar svg estáticos en Commons, de modo que las fórmulas que requieran dicha consistencia se puedan seguir editando en la plataforma, al tiempo que se reduce la carga en ese servicio a un nivel insignificante. SamuelRiv ( discusión ) 17:01, 19 de septiembre de 2024 (UTC) [ responder ]

Según mi opinión, las razones técnicas por las que no podemos mantener en funcionamiento el sistema actual basado en SVG son que depende de RESTBase, que básicamente almacena en caché las imágenes generadas. RESTBase ya tiene 10 años, es un poco complicado de instalar y tiene un montón de problemas. Los demás servicios que utilizaban RESTBase, como el Editor visual, ya no lo utilizan, por lo que la fundación ha decidido retirarlo (desaparecer). Esto, por supuesto, crea un problema para el motor de renderizado matemático. Se ha hecho un esfuerzo considerable para arreglar las cosas para que las matemáticas funcionen de una forma u otra. Physikerwelt ha trabajado mucho y yo solo soy un observador.

Lo que podría ser una posible alternativa, si queremos dar a los usuarios una opción, es MathJax del lado del cliente. Las imágenes SVG son, creo, generadas por MathJax. Hace unos años, la última vez que surgió la representación matemática y reemplazamos las horribles imágenes PNG, MathJax del lado del cliente era la única opción. Hay algunos problemas con esto, ya que las imágenes son generadas sobre la marcha por el navegador, y puede llevar unos segundos que las páginas con muchas fórmulas se representen por completo, probablemente ahora sea más rápido. En ese momento, la fundación dijo que no a MathJax del lado del cliente como opción predeterminada (siempre ha estado disponible como una opción). En cambio, el equipo de MathJax hizo un gran esfuerzo para hacer la representación del lado del servidor que produzca SVG. Entonces, aparte de algunos problemas como la alineación de la línea base, deberían verse iguales.

Como acotación al margen, Help:Formula se procesa rápidamente con MathJax del lado del cliente, pero hay varios errores de entrada y de salida de matemáticas. Probablemente valga la pena informar de un error. -- Salix alba ( discusión ): 18:21 19 sep 2024 (UTC) [ responder ]

Quiero responder a la reclamación de User:Physikerwelt de que hay un problema en el navegador (en ese caso, es posible que se solucione cuanto antes, cuanto más ruido se haga) . Estoy totalmente en desacuerdo. Si hay problemas con la representación del navegador, como parece que los hay, entonces nuestras matemáticas se verán mal y los lectores pensarán que Wikipedia es mala en matemáticas. No se les ocurrirá presionar a los proveedores de navegadores para que cambien el navegador, y si se les ocurriera, es poco probable que sea efectivo. Cuando se quejen a Wikipedia, es probable que reciban respuestas inútiles como el comentario que he citado, que se resume en "no lo solucionaremos y no podrán ir a ningún otro lado para solucionarlo".

Así que, para mí, el mensaje neto que estoy recibiendo de este giro de los acontecimientos es: Wikimedia sigue mostrando su preferencia de décadas por la pureza ideológica del lenguaje de programación por sobre la representación matemática legible que ha causado durante décadas que Wikipedia esté muy por detrás de la curva en la visualización de fórmulas matemáticas, tiene la intención de romper la visualización actual a favor de algo que funciona mal pero es más ideológicamente puro, y evitará la responsabilidad por la ruptura diciéndoles a todos que es culpa del navegador. — David Eppstein ( discusión ) 18:50, 19 de septiembre de 2024 (UTC) [ responder ]

No conozco los detalles técnicos para decir si alguien tiene razón o no, pero me preocupa y me refiero específicamente a la retórica: al no abordar ni reconocer las motivaciones técnicas o las soluciones constructivas, su comentario parece decirle a Physikerwelt que está a favor de algo que funciona mal pero que es más puro ideológicamente. SamuelRiv ( discusión ) 18:59 19 sep 2024 (UTC) [ responder ]

Lo contrario. MathML es ideológicamente puro (se basa en el marcado *ML); MathJax no lo es (se basa en JavaScripts que se arrastran por el contenido para encontrar un marcado que no se parezca a *ML y reemplazar su representación). MathML no funciona como un formato de marcado escribible por humanos e históricamente ha funcionado bastante mal en el lado de la representación; MathJax funciona bien para ambos. No me importa la pureza ideológica en mi canalización de servidor web a navegador; me importa poder escribir fórmulas de manera simple y natural y obtener un resultado visual de alta calidad. Mi fuerte impresión es que esas prioridades están invertidas dentro de Wikimedia. — David Eppstein ( discusión ) 19:16, 19 de septiembre de 2024 (UTC) [ responder ]

Soluciones constructivas – La solución constructiva es una solución política: Wikimedia debería gastar el dinero y el tiempo de los desarrolladores para solucionar cualquier problema que surja con el renderizador actual o la plataforma en la que está construido, al menos hasta que se pueda demostrar de forma clara y convincente que existe un reemplazo directo, algo que los renderizadores alternativos que hoy se apoyan como opción preferida no están ni cerca de hacer. Si seguimos adelante con un plan que provoca regresiones tipográficas significativas en todos los artículos relacionados con las matemáticas en Wikipedia, algunas de las cuales pueden ser imposibles de solucionar, eso va a ser un problema grave para el proyecto Wikipedia: obstaculizará la lectura, hará que todos piensen que somos incompetentes y enojará a los autores que han invertido cantidades increíbles de trabajo en algo que solía parecer profesional y de repente ya no lo es. – jacobolus  (t) 04:26, 20 de septiembre de 2024 (UTC) [ responder ]

@ Physikerwelt : No sabía que una nueva versión de Chrome admitiera MathML, así que tal vez MathML no esté muerto después de todo (lo último que escuché fue que Chrome dejó de admitir MathML, pero aparentemente esa no era una noticia vieja). Pero dado que los navegadores antiguos, como Chrome o Internet Explorer, no admiten MathML, diría que aún faltan navegadores que los admitan. *Obviamente*, Wikipedia debe ser accesible para quienes tengan navegadores antiguos.

Para reiterar algunos de mis puntos de manera más explícita, la pregunta que se debe hacer no es qué son los errores y cómo se pueden solucionar. No. Pero la pregunta debería ser sobre la dirección. ¿Es el renderizado MathML un estándar ahora? Es decir, ¿muchos sitios web convencionales como blogs o foros que involucran fórmulas matemáticas usan MathML? Entiendo que el estándar sigue siendo MathJax. Entonces, si bien un desarrollador como usted debe trabajar en lo que quiera, en términos de dirección para Wikipedia, un curso razonable parece ser (1) posponer la finalización del renderizado actual y (2) mientras tanto arreglar la implementación actual de MathJax (que actualmente está rota). —- Taku ( discusión ) 07:09, 20 de septiembre de 2024 (UTC) [ responder ]

Prueba de tortura de MathML actualizada

La página de la prueba de tortura vinculada arriba tiene varias décadas de antigüedad e incluye errores en la traducción a MathML. La actualización moderna que obtuve de igalia se ve mucho mejor. Dicklyon ( discusión ) 22:28 19 sep 2024 (UTC) [ responder ]

Y si alguien quiere recopilar una página de ejemplos que no se muestran de forma satisfactoria, apuesto a que estará encantado de verlo. Dicklyon ( discusión ) 22:29 19 sep 2024 (UTC) [ responder ]

Vaya, eso es terriblemente malo. ¿Los desarrolladores realmente van a impulsar esto? Tito Omburo ( discusión ) 22:36 19 sep 2024 (UTC) [ responder ]

Hay un menú desplegable para elegir la fuente que se va a utilizar. ¿Cuál debería consultar? Parece que no solo cambia las fuentes, sino también cosas como la altura de los paréntesis y, en algunos casos, el espaciado muy importante, por ejemplo, el espacio entre fracciones en el n.° 9.

Algunas fuentes me parecen muy satisfactorias en algunos navegadores, pero en otros no se reproducen bien. (¿Será culpa de mi propio ordenador?)

De todas formas, nunca he entendido por qué los desarrolladores de la wiki no pueden hacer que el latex etiquetado con <math> aparezca de forma consistente en las mismas líneas horizontales que el texto circundante. Me parece que esa sería la solución perfecta y no parece (?) tan difícil. Gumshoe2 ( discusión ) 23:14 19 sep 2024 (UTC) [ responder ]

Aquí hay un collage de mis representaciones: Cambria (selección de fuente predeterminada de Windows) tiene sus problemas únicos (#13 y #29), lo cual es extraño. DejaVu fue generalmente satisfactorio, así que no lo subí. Libertinus tiene un kerning incómodo en #14. STIX cambia abruptamente entre símbolos de raíz cuadrada rectos e inclinados en #13 (pero como puede ver, esto se replica en la representación de tex2svg; otras fuentes se representan en una gradación suave). El kerning después de la combinación de paréntesis en #9 parece ser un poco ajustado en todas las fuentes. Además, la representación de fracciones adyacentes con diferentes denominadores de altura será inconsistente con diferentes fuentes en #9 - TeX solo conserva la altura en su fuente predeterminada para x ² y similares, pero más allá de eso obtienes problemas de consistencia de alineación similares que generalmente soluciono usando caracteres fantasma (algo para probar en tus representaciones MathML). SamuelRiv ( discusión ) 19:09 20 sep 2024 (UTC) [ responder ]

La nueva prueba de tortura tiene múltiples problemas visibles:

• #3, #4. La barra de fracciones es mucho más delgada que el texto (Firefox)
• #4. El denominador de la fracción en el exponente está demasiado cerca del tamaño y la línea base del texto principal, lo que hace que parezca que está unido a la base del exponente en lugar de a la fracción (Firefox+Chrome)
• #5, #8, #14. El espacio alrededor del sólido es demasiado amplio. (Firefox + Chrome)
• #7. Las barras de fracciones debajo de la superior son demasiado delgadas (Firefox) o la inferior es demasiado delgada (Chrome)
• #13, #29. Las barras sobre la raíz cuadrada están un poco demasiado bajas, lo que provoca un error en el lugar donde se conectan (Firefox); o un poco demasiado altas, lo que provoca un error similar (Chrome)
• #14. Varphi feo demasiado cerca de la barra vertical (Chrome)
• #18. El "0" está centrado incorrectamente en los dos casos anteriores, en lugar de estar justificado a la izquierda (Firefox+Chrome); "elsewhere" no se alinea con las líneas anteriores (Chrome)
• #19, 22. Las anotaciones textuales son significativamente más pequeñas que las que presenta TeX, lo que dificulta su lectura (Firefox+Chrome).
• #28. Los números primos triples están demasiado cerca uno del otro y demasiado lejos de y, lo que hace que parezcan una única mancha oscura que ni siquiera forma parte de la fórmula (Chrome)
• #29 El signo más en el límite está espaciado como un operador binario entre la flecha y el infinito en lugar de un operador unario adjunto al infinito (Firefox+Chrome).
• #30 blobby varepsilon es difícil de distinguir del signo de membresía del conjunto (Firefox + Chrome)

- David Eppstein ( discusión ) 23:09, 19 de septiembre de 2024 (UTC) [ respuesta ]

¿Qué fuente(s) estás viendo? No había visto el menú que mencionó Gumshoe2, pero encuentro que algunas fuentes no son terribles y otras sí. Y no estoy seguro de qué controlaría la fuente utilizada por MathML en Wikipedia; ¿probablemente una configuración de preferencias, con un valor predeterminado razonable? Dicklyon ( discusión ) 01:52, 20 de septiembre de 2024 (UTC) [ responder ]

"No estoy seguro de qué controlaría la fuente utilizada por MathML en Wikipedia", sea cual sea el navegador o sistema operativo que se incluya y utilice de forma predeterminada, si no me equivoco. Especialmente los usuarios de matemáticas que hayan instalado sus propias fuentes matemáticas podrían estar viendo resultados que difieran de los que verían la mayoría de los usuarios. — Th e DJ ( discusión • contribuciones ) 02:39, 20 de septiembre de 2024 (UTC) [ responder ]

"Tus fuentes matemáticas son incorrectas y necesitas pasar por [un procedimiento técnico largo y complicado] para arreglarlas antes de que Wikipedia sea legible" es exactamente el tipo de respuesta inútil que esperaría que los defensores de mathml dieran a los lectores de Wikipedia no sofisticados en lugar de, ya sabes, proporcionar un flujo de procesamiento matemático que funcione de inmediato. En cuanto a mi configuración personal, no he tocado las fuentes desde que compré esta computadora portátil (Apple) en particular, pero quién sabe qué podría haberse transferido cuando su procedimiento de configuración copió mis archivos a través de múltiples generaciones de computadoras portátiles anteriores durante varios años cuando podría haber hecho algo hace mucho tiempo que podría seguir afectando las cosas hoy. Además, recuerda que los lectores que no han iniciado sesión no tienen preferencias que puedan ajustar. Intenté ver a los que no han iniciado sesión y no vi ninguna diferencia obvia con los que sí lo han hecho. — David Eppstein ( discusión ) 05:27, 20 de septiembre de 2024 (UTC) [ responder ]

Aquí hay un ejemplo de notaciones de fracciones continuas § , tal como se representa actualmente utilizando el renderizador LaTeX→SVG predeterminado a la izquierda frente a MathML a la derecha, en mi navegador conectado.

El de la derecha no parece estar listo para su uso en "producción". – jacobolus  (t) 06:07, 20 de septiembre de 2024 (UTC) [ responder ]

Por cierto, hay un comentario sobre el marcado para el látex en la notación de Leibniz: <!--solución muy complicada; el látex de mediawiki no tiene un buen soporte para los comandos de alineación vertical-->. Me pregunto cuántos ajustes fueron necesarios para que se viera bien usando nuestro tex2svg. En secciones específicamente marcadas para notaciones históricas no estándar, es un poco extraño que esperes que dos renderizadores, incluso dos fuentes, den un resultado consistente. (Si una imagen es lo único que garantiza la consistencia, estoy de acuerdo, y hay muchas formas en las que podemos ejecutar tex2svg sin regenerarlo cada vez dentro del artículo).

De todos modos, ahora que sabemos que esa sintaxis de espacios en blanco personalizada no se reconoce, en principio uno podría simplemente ejecutar AWB para configurar cualquier ecuación con ese código para que use explícitamente una representación de respaldo (aunque estoy esperando escuchar específicamente cuáles son las opciones para esto). SamuelRiv ( discusión ) 07:04, 20 de septiembre de 2024 (UTC) [ responder ]

La fuerte impresión que me da este hilo, especialmente el de Physikerwelt de que "no es posible por razones técnicas mantener en funcionamiento el sistema actual basado en SVG", es que Wikimedia pretende desechar cualquier otro sistema de representación, dejándonos sin opciones de respaldo. — David Eppstein ( discusión ) 07:50, 20 de septiembre de 2024 (UTC) [ responder ]

No hay una "sintaxis de espacios en blanco personalizada". Esto es LaTeX normal. Solo necesita una solución engorrosa porque a nuestra herramienta LaTeX→SVG le faltan algunas características básicas de TeX/LaTeX.† Pero no es solo la parte de notación "Leibniz" la que es terrible en la versión MathML: todas las variantes de notación posteriores también son tipográficamente malas y significativamente menos legibles porque tienen una alineación y un espaciado muy deficientes. Pero el ejemplo de Leibniz más dramáticamente defectuoso es un buen ejemplo de los tipos de ecuaciones complicadas que cualquier reemplazo directo debe poder manejar, porque hay una gran cantidad de expresiones matemáticas en todo el proyecto en las que los autores confiaron en el comportamiento específico de nuestra herramienta LaTeX→SVG y se asumió que se representaría para cada lector de la misma manera que aparece para el autor. La cantidad de tiempo y esfuerzo que se necesitaría para encontrar y "arreglar" todos estos ejemplos que funcionan actualmente para que funcionen de alguna manera con una nueva herramienta de representación va a ser increíblemente alta. Estamos hablando de miles a decenas de miles de horas de trabajo.

†: Si alguien que trabaja en el aspecto técnico quisiera ayudar a los autores de artículos, agregar soporte para algunas características fundamentales pero actualmente faltantes de espaciado y tamaño de TeX/LaTeX sería una mejora que al menos yo estaría feliz de aplaudir. – jacobolus  (t) 09:28, 20 de septiembre de 2024 (UTC) [ responder ]

Vaya, la representación de la derecha es mala. XOR'easter ( discusión ) 19:11 20 sep 2024 (UTC) [ responder ]

Me parece extraño que la prueba de tortura no incluya ninguna representación de entornos de alineación de LaTeX, que están realmente dañados. Véase, por ejemplo, la regla de la cadena #Composiciones de más de dos funciones . Tito Omburo ( discusión ) 13:06, 20 de septiembre de 2024 (UTC) [ responder ]

He añadido un error T375317 sobre los campos alineados al centro para la alineación \align en lugar de rlrl... -- Salix alba ( discusión ): 02:27 21 sep 2024 (UTC) [ responder ]

Dejando de lado el \align roto, hay una cornucopia de otros problemas tipográficos en ese ejemplo, por ejemplo,

• La misma fuente se utiliza para símbolos de tamaño normal y símbolos más pequeños en fracciones en línea, exponentes, etc., pero para una tipografía decente, estos deben ser símbolos de tamaño óptico que sean relativamente más audaces, tengan proporciones más amplias, etc., de lo contrario, los símbolos encogidos aparecen delgados y son difíciles de leer.
• Los símbolos ∘ (composición de función) y ′ (primo) son demasiado pequeños y el último está colocado en el lugar completamente equivocado y aparentemente arruina por completo el espaciado horizontal después.
• La barra vertical que indica la evaluación en un punto determinado está colocada demasiado cerca de la barra adyacente dy / du , etc.
• El espaciado alrededor de los signos = es horrible, incluso en ecuaciones que no utilizan el entorno de alineación
• Los paréntesis en su mayoría tienen un tamaño incorrecto, especialmente notable en los exponentes, pero también los paréntesis que envuelven material más grande no crecen correctamente y el resultado se ve terrible.
• El subíndice en ⁠ ⁠ ${\displaystyle f}$ no tiene el interletraje correcto,
• El símbolo ⁠ ⁠ ${\displaystyle \textstyle \prod }$ es demasiado pequeño y la alineación vertical de los límites arriba y abajo es incorrecta,
• Las ecuaciones en límites tienen demasiado espacio alrededor del signo =,
• ....

@Physikerwelt – Lo siento, pero esto no está ni cerca de estar listo para un uso serio. – jacobolus (  t) 15:01, 20 de septiembre de 2024 (UTC) [ responder ]

Estoy de acuerdo con todo esto. Tito Omburo ( discusión ) 15:23 20 sep 2024 (UTC) [ responder ]

Más enérgicamente, @Physikerwelt : si desea proporcionar una demostración convincente al mundo de que MathML hace que las matemáticas sean feas y no se deben usar, seguir adelante es una forma prometedora de hacerlo. No se trata solo de los problemas obvios enumerados anteriormente, sino de cosas más pequeñas en las que los símbolos aproximadamente correctos están aproximadamente en los lugares correctos, pero de manera mucho menos armoniosa que en el diseño de TeX. En la captura de pantalla de la fracción continua de jacobolus anterior, observe la notación atribuida a Gauss, . En TeX parece natural, como si fuera una notación estándar. En la captura de pantalla de MathML, todos los símbolos flotan desconectados entre sí, con demasiado espacio entre ellos, lo que hace que parezcan demasiado pequeños y que la notación parezca improvisada y no natural. La fracción vertical es demasiado apretada y su denominador está descentrado. No es matemáticamente incorrecto, pero es feo. Este es el tipo de fealdad que la gente aprenderá que es causada por MathML. - David Eppstein ( discusión ) 17:56, 20 de septiembre de 2024 (UTC) [ respuesta ] ${\displaystyle x=a_{0}+{\underset {i=1}{\overset {4}{\mathrm {K} }}}~{\frac {1}{a_{i}}}}$

Este es un problema de diseño que también será feo en TeX. Por ejemplo, la puntuación terminal con algo así como una fracción, límites anchos o asimétricos en la sigma (pruebe con una fuente diferente o una expresión más larga). (Parte de la razón por la que lo tolera puede ser que está acostumbrado a ello, o que es un estándar de la industria; personalmente no puedo soportar el hecho de que la preferencia declarada de Knuth por puntuar las líneas de ecuación signifique que todos tengamos que lidiar con esa porquería fea, pero al final del día, probablemente debería aceptar que no es tan importante .

Si tu argumento es que parece poco profesional, entonces el estándar profesional, TeX, se representa de una manera diferente utilizando fuentes especialmente diseñadas que no se llevan bien con nuestro texto en línea (una queja común, de ahí la plantilla {{ math }} y, peor aún, el wikitexto sin serifa). El hecho de que las ecuaciones sean seleccionables mejora potencialmente la accesibilidad del lector. Cuál es la implementación para hacer esto, y cuál es la alternativa, cómo continuar con tex2svg cuando sea necesario, cómo y cuándo se implementa; estas son cosas que se pueden discutir de manera constructiva. Por otro lado, varios de tus comentarios hasta ahora, a saber, la oración inicial de los dos anteriores ("Wikimedia pretende tirar basura" y "exactamente el tipo de respuesta inútil" (después de una cita de una no cita)) son simplemente de mala fe. SamuelRiv ( discusión ) 19:44, 20 de septiembre de 2024 (UTC) [ responder ]

Donald Knuth no inventó la colocación de signos de puntuación al final de una ecuación. Esencialmente, todas las publicaciones matemáticas han hecho esto desde que se desarrolló la imprenta matemática en el siglo XVIII. Tito Omburo ( discusión ) 21:28 20 sep 2024 (UTC) [ responder ]

Por ejemplo, es la práctica recomendada por Halmos (1970), que se cita en nuestro manual de estilo , y que Knuth leyó (cita de ella en la p. 183 de The TeXbook ). También la recomienda Chaundy, Barrett y Batey en The Printing of Mathematics (Oxford UP, 1954), que Knuth también leyó (véase la p. 197 de The TeXbook ). XOR'easter ( discusión ) 06:38 21 sep 2024 (UTC) [ responder ]

Simplemente de mala fe : toda esta propuesta técnica me parece despreciativa de la experiencia y las necesidades prácticas de los autores, hasta el punto de ser insultante. Criticar eso con dureza es, en mi opinión, la respuesta adecuada, y llamar a esa respuesta "mala fe" es un profundo malentendido de lo que estamos tratando de hacer en este proyecto llamado Wikipedia. Lo que estamos viendo es una especie de reacción inmune por parte de personas que se verán extremadamente afectadas por los cambios impulsados ​​por personas que no van a sentir el impacto. Este tipo de respuesta es común cada vez que entras en un sistema complejo relativamente estable y comienzas a romper componentes esenciales. – jacobolus  (t) 21:34, 20 de septiembre de 2024 (UTC) [ responder ]

He creado una versión de TortureTest que va desde nuestra <math>versión de extensión de LaTeX y es renderizada por nuestro sistema, Usuario:Salix alba/TortureTest . Hay un par de partes en las que nos perdemos cosas como \substack que causan problemas, pero en su mayor parte funciona bien. Hay un par de errores con la renderización de MathJax del lado del cliente que parecen tener soluciones en proceso T375241.-- Salix alba ( discusión ): 17:21, 20 de septiembre de 2024 (UTC) [ responder ]

No necesitas \substack, puedes usar simplemente \atop: Tercero ( discusión ) 17:40 20 sep 2024 (UTC) [ responder ] ${\displaystyle \sum _{{0\leq i\leq m} \atop {0<j<n}}P(i,j)}$

Solo por diversión, pensé en probar la prueba de tortura actualizada de DickLyon con Chrome en Android en un teléfono Pixel de modelo reciente; esto es lo que obtengo cuando hago clic en su enlace desde la aplicación de Wikipedia y sospecho que es muy similar a lo que obtendría si se usara la representación MathML dentro de la aplicación de Wikipedia. No he hecho nada para configurar fuentes no estándar en el teléfono. Es mucho peor que en los navegadores de mi computadora portátil.

• En general: las letras cursivas están en una fuente serif, pero los dígitos están en una fuente sans-serif. Cuando aparecen una al lado de la otra con el mismo tamaño, la sans-serif parece notablemente más pesada que la serif.
• #8, #9: Los coeficientes binomiales se representan con paréntesis de tamaño normal, no con los paréntesis extendidos correctos.
• #9. El espaciado es tan malo que el primer paréntesis de cierre toca la x siguiente, y la y toca su exponente. Los denominadores de las dos fracciones verticales no tienen la misma línea de base.
• #10, #12. El signo de suma es sans-serif y del mismo tamaño que el texto. La i debajo de la 1 en #10 casi la toca. La p y la q sobre las 12 sí la tocan. La r en #12 tiene una línea de base más baja que la p y la q, tan baja que casi toca su signo de suma.
• #13. Los signos sqrt son todos del mismo tamaño y, para poder anidarse unos dentro de otros, flotan muy por encima de sus argumentos. Solo el más interno está cerca de su tamaño y ubicación adecuados, pero incluso este es demasiado pequeño, con su punto inferior solo a la mitad de la línea base de su argumento (debería estar debajo de la línea base). Hay espacios visibles donde se conectan con sus líneas superiores.
• #14. Los delimitadores izquierdo y derecho (tanto paréntesis como barra vertical) tienen el mismo tamaño que el texto. Los signos parciales son sans-serif.
• #15. La x es tan pequeña que resulta ilegible. Tengo que hacer un zoom mucho mayor que el de TeX para poder leerla.
• #16. El signo integral tiene un tamaño similar al del texto y es de tipo sans serif. La x está ubicada tan cerca de ella que el punto superior del signo integral casi toca el punto de intersección de la x y se encuentra entre las partes superior e inferior izquierdas de la x.
• #17. El mismo ridículo letrero integral sin serifas con un tamaño de texto.
• #18. Centrado en lugar de justificado a la izquierda; el texto es sans-serif.
• #19. La llave horizontal es demasiado pequeña, solo cubre el "..." del medio y está demasiado cerca del texto que está encima, que es demasiado pequeño y sin serifas.
• #21. La misma suma incorrecta, signos integrales y texto sin serifa. La π tiene aproximadamente la altura correcta, pero es ridículamente ancha, tal vez tres veces el ancho de la mayoría de las letras cursivas.
• #22. Los mismos corchetes horizontales diminutos y las etiquetas sin serif demasiado cercanas. La \ell es sin serif, no se acerca a la k en apariencia ni en grosor, y su trazo comienza en algún lugar del medio en lugar de en la parte inferior, por lo que parece más una e cursiva que una ell.
• #23. Una dispersión aleatoria e ilegible de letras cursivas serif, un dígito sin serifa y paréntesis del tamaño de un texto. Me resultaría difícil adivinar que se trata de una matriz de matrices.
• #24. Las barras verticales tienen el tamaño del texto y aún así aparecen un poco más abajo que la línea de base del material circundante.
• #26. El mismo pi malo.
• #28. El mismo problema que vi en mi computadora portátil: los primos triples son diminutos, están demasiado cerca uno del otro y tan lejos de la y que no tendría idea de que se supone que deben modificarla.
• #29. La misma raíz cuadrada desalineada y demasiado pequeña. 2 π n se encuentran en tres estilos de fuente no relacionados. El signo de exclamación parece ser sans-serif y los paréntesis tienen el tamaño del texto. El signo de límite es sans-serif. Pero al menos esta vez el espaciado de n\to+\infty se ve mejor que en mi computadora portátil.
• #30. Det es una fuente sin serifas. Ahora que los veo juntos, el símbolo de suma, el símbolo de producto y las letras griegas minúsculas parecen ser de la misma fuente; es decir, no hay distinción visual entre una suma y una sigma mayúscula, ni entre un producto y una pi mayúscula. Tal vez eso explique por qué las letras griegas minúsculas son tan grandes; es un paso hacia hacer que las sumas y los productos sean un poco menos horribles. La n toca el símbolo de producto. Pero al menos puedo distinguir el símbolo de pertenencia a un conjunto de la épsilon.

Hoy estuve mirando uno de esos libros de matemáticas antiguos, anteriores a TeX, en los que todo se configuraba con una máquina de escribir, utilizando la mejor aproximación a la colocación correcta de los símbolos que se podía lograr con una máquina de escribir. Eso no es bueno, según los estándares actuales. Pero esto me parece peor, porque es igual de feo y no tiene excusa. Hemos podido componer matemáticas mucho mejor que esto durante más de 45 años. Si esto es lo que las matemáticas van a representar en un dispositivo móvil, está absolutamente lejos de estar listo para el gran momento. Con la representación SVG, he estado prefiriendo firmemente el marcado matemático de LaTeX a nuestras plantillas sucedáneas, pero esto me haría volver atrás. Literalmente, las únicas fórmulas para las que puede producir resultados aceptables son aquellas para las que template-math funciona mejor. — David Eppstein ( discusión ) 07:27, 21 de septiembre de 2024 (UTC) [ responder ]

Esos símbolos pi alargados son como una historia de terror de los años 90: una ecuación que alguien escribió en Word y modificó su tamaño en PowerPoint, y que luego mostró un evangelista del código abierto como ejemplo de por qué los amigos no dejan que sus amigos usen productos de Microsoft. Que cualquier descendiente de TeX produzca un resultado como ese es una broma extraña. XOR'easter ( discusión ) 23:43 22 sep 2024 (UTC) [ responder ]

@ David Eppstein Creo que las impresiones basadas en máquinas de escribir fueron un paso atrás en comparación con la impresión basada en LED que se utilizaba anteriormente. Tal vez alguien también podría afirmar que la composición tipográfica de hace 100 años se ve mejor que MathML. Estaba mirando algunas publicaciones de 1924 y es difícil decirlo.

Sin embargo, RESTbase se desactivará de todas formas. Los errores de Phabricator se pueden solucionar (fácilmente) hasta el punto de que puede llegar a ser tan bueno como la prueba de tortura de MathML. Con la opción MathJax, se mejora el espaciado para los usuarios que han iniciado sesión. Afirmo que es posible mantener la antigua representación SVG incluso sin RESTbase. Sin embargo, eso dificultaría la extensión de la funcionalidad actual. Las opciones de MathJax implementadas actualmente vuelven a MathML si se deshabilita JavaScript, por lo que creo que esto también podría convertirse en el valor predeterminado para los usuarios que no hayan iniciado sesión.

Se han informado dos problemas relacionados con la opción MathJax. He corregido uno y el otro está actualmente a la espera de la revisión del código. Si selecciono SVG como opción de renderizado en MathJax del lado del cliente, me parece muy similar al renderizado actual basado en SVG. Esto se debe a que la base de código de MathJax sirvió como modelo para la implementación nativa de MathML. Incluso los datos especiales de MathJax, como `data-mjx-texclass`, están en el MathML nativo generado para ayudar a MathJax a generar el espaciado correcto, lo que parece ser casi imposible solo con la entrada de MathML.

Si hay una mayoría que apoya esa opción, ¿el grupo de la comunidad de Wikimedia Math podría votar sobre esto?

Por el momento, estoy esperando la revisión del código para los errores informados. Una vez que esto se fusione, analizaré los próximos errores. Physikerwelt ( discusión ) 13:42, 5 de octubre de 2024 (UTC) [ responder ]

Las impresiones a máquina de escribir supusieron un paso atrás . Sí, precisamente ése es el punto. Los "manuscritos" a máquina de escribir eran una alternativa a los manuscritos escritos a mano, que eran más fáciles y rápidos de producir, especialmente para personas con una letra descuidada. Comparados con la tipografía producida en una imprenta especializada en matemáticas, parecían una basura total, pero tenían la ventaja de no requerir los costosos servicios de un tipógrafo profesional ni el costoso equipo de una prensa y tipos de metal. Si alguien compara su tipografía matemática con la producida por una máquina de escribir, esa no es una comparación halagadora.

Tal vez alguien también podría afirmar que la tipografía de hace 100 años tiene mejor aspecto que la de MathML. Sí, hay libros de matemáticas de más de 200 años con tipografía que tiene mucho mejor aspecto que la actual versión de MathML de Wikipedia.

RESTbase se apagará de todos modos : la alternativa simplemente no es aceptable en este momento, por lo que básicamente siguen amenazando con hacer que de la noche a la mañana toda la Wikipedia técnica luzca fea, ilegible y amateur, sin ningún plan de respaldo.

Si selecciono SVG como opción de renderizado en MathJax del lado del cliente, me parece muy similar al renderizado actual basado en SVG. Debes probar esto en una variedad extremadamente amplia de dispositivos y sentarte al lado de alguien que sea sensible a los detalles de la tipografía matemática mientras lo haces, y dejar que te señale cualquier problema. En mi opinión, esta opción solo es viable si Wikipedia envía fuentes a todos los lectores, y después de eso va a requerir un período prolongado de corrección de errores antes de que esté lista. – jacobolus  (t) 14:08, 5 de octubre de 2024 (UTC) [ responder ]

"RESTbase se desactivará de todos modos; la alternativa simplemente no es aceptable en este momento". Quejarse aquí tendrá poco efecto, nadie aquí tiene el poder de detener el cambio. Realmente necesitas hablar de esto con la fundación. Tal vez exista la posibilidad de un servicio alternativo de almacenamiento en caché de imágenes, pero eso requeriría desarrolladores de nivel de fundación, en lugar de un par de voluntarios.

Lo que podemos hacer es que sea menos complicado. Para ello, podemos identificar un ejemplo concreto de cuándo falla el renderizador. Me complace convertirlos en informes de errores y Physikerwelt ha trabajado mucho para corregir los errores informados. Algunos de los errores podrían solucionarse con información sobre lo que realmente queremos lograr. Por ejemplo, ¿debería tener siempre \operatorname{foo} un espacio antes y después, o hay casos en los que este no es el resultado deseado? T375861

Tuvimos un debate similar cuando se introdujo MathJax del lado del servidor, también conocido como SVG, y de alguna manera logramos obtener un resultado aceptable. -- Salix alba ( discusión ): 19:58, 5 de octubre de 2024 (UTC) [ responder ]

Es muy importante que hables de esto con la fundación. ¿Alguien le ha dicho a la fundación que se trata de un problema grave y urgente? ¿Quién es la persona de contacto adecuada? ¿Cuál es el lugar adecuado?

\operatorname{sin}debe aparecer igual que \sin, etc. El espaciado apropiado depende del contexto y, con suerte, el comportamiento debería ser idéntico al del renderizador actual, porque muchos artículos han tenido soluciones manuales para el espaciado. (Aunque si el renderizador actual difiere del comportamiento de LaTeX estándar por alguna razón, entonces podría imaginar un caso para "arreglar" cualquier diferencia y luego los editores simplemente tendrían que intentar verificar cualquier artículo que haya modificado explícitamente el espaciado).

Debate similar cuando se introdujo MathJax del lado del servidor : sí, y el reemplazo tenía un diseño y una apariencia casi idénticos, excepto por ser una imagen vectorial en lugar de un mapa de bits. Si puede lograr el mismo resultado casi idéntico con el renderizador actual en todos los dispositivos y configuraciones de los lectores, entonces tampoco tendremos ningún problema esta vez, pero actualmente eso no está ni cerca de ser el caso. – jacobolus  (t) 20:46, 5 de octubre de 2024 (UTC) [ responder ]

Si comentarios como "RESTbase se desactivará de todos modos" no proporcionan una imagen suficientemente clara de que a Wikimedia no le importa el contenido técnico de Wikipedia y está dispuesta a romper ese contenido durante meses o años, considere el triste destino de la extensión gráfica ( Help:Graph ), "temporalmente" deshabilitada desde abril de 2023 con su supuesto reemplazo "Charts" muy retrasado y sin actualizaciones.

Tal vez sea el momento de empezar a preparar contramedidas más extremas, en el probable caso de que el formato matemático se vuelva defectuoso y ilegible. Algo que me viene a la mente: un bot o script que lea una página de Wikipedia, encuentre todas sus fórmulas matemáticas, cree imágenes de mapa de bits o svg usando LaTeX, las suba a Wikipedia y use una imagen como reemplazo de la fórmula. — David Eppstein ( discusión ) 21:02, 5 de octubre de 2024 (UTC) [ responder ]

Tal vez podríamos simplemente agregar un banner colorido en la parte superior de cada artículo técnico que diga algo como "La fundación Wikimedia acaba de romper la representación matemática en Wikipedia. Comuníquese con XYZ si desea restaurar la representación con aspecto profesional". Intentar reemplazar cada fórmula con imágenes explícitas suena como una pesadilla logística. – jacobolus  (t) 21:33, 5 de octubre de 2024 (UTC) [ responder ]

Lo pensé, pero sospecho firmemente que la pancarta sería eliminada como una acción administrativa.

Por cierto, dado que mi experiencia con la prueba de tortura fue que pasar de un navegador web en una computadora a un dispositivo móvil hizo que MathML fuera mucho peor, no solo extremadamente feo sino totalmente ilegible: ¿alguien sabe si hay alguna manera de convencer a la aplicación de Wikipedia para Android de que se renderice usando MathML para que pueda ver cómo sería? No parece respetar mi preferencia de usuario para eso. —— David Eppstein ( discusión ) 22:06, 5 de octubre de 2024 (UTC) [ responder ]

Errores del fabricante

He estado creando un conjunto de errores de Phabricator bajo la tarea T375318  • Errores de formato del modo TNative MathML y ​​ha habido avances en algunos de los errores durante la última semana.

• T375317 \align alinea los campos en el centro en lugar de a la izquierda en el modo MathML - ahora resuelto.
• T375295 \begin{align} con tamaños de fuente especificados, mostrar anotación de tamaño de fuente 6pt en modo MathML - ahora resuelto.
• T375337 Demasiado espacio alrededor/en el modo de formato MathML: probablemente tenga solución.
• T375349 \int\limits_a^b límites en posición incorrecta en modo MathML - probablemente solucionable
• T375340 Demasiado espacio entre las cercas y el contenido en el modo de formato MathML
• T375346 Mucho espacio alrededor de las celdas en entornos matriciales en modo MathML

Los dos últimos dependen un poco de la elección de la fuente, en particular de la fuente establecida por el navegador correspondiente a los elementos font-family: mathfor <mi>y <mo>, por lo que no estoy seguro de qué se debe hacer con estos. También se han corregido un par de errores más relacionados con la representación de MathJax del lado del cliente T375241 y To T375241.

Estoy dispuesto a traducir otros problemas en errores, pero necesito tener una idea clara de cuáles son los problemas más urgentes. -- Salix alba ( discusión ): 21:46 26 sep 2024 (UTC) [ responder ]

@ Salix Alba : Puedo dar algunos ejemplos de los problemas más urgentes ( MathJax con salida SVG ):

1: \\[8mu] etc. en "align" está roto , vea por ejemplo

$${\displaystyle {\begin{aligned}\varpi &=[2,1,1,1,1,1,4,1,2,\ldots ],\\[8mu]2\varpi &=[5,4,10,2,1,2,3,29,\ldots ],\\[5mu]{\frac {\varpi }{2}}&=[1,3,4,1,1,1,5,2,\ldots ],\\[2mu]{\frac {\varpi }{\pi }}&=[0,1,5,21,3,4,14,\ldots ].\end{aligned}}}$$

2: \mathcal no se puede representar y en su lugar se reemplaza por \mathscr , consulte el ejemplo

${\displaystyle {\mathcal {A}}}$(esto no es matemático)

3: \operatorname está roto , ver por ejemplo

${\displaystyle \operatorname {operator} }$

4: \displaystyle\sum_{n\in\mathbb{Z}} y \displaystyle\prod_{n\in\mathbb{Z}} colocan el índice en una posición incorrecta (debería estar debajo, pero está a la derecha)

${\displaystyle \displaystyle \sum _{n\in \mathbb {Z} }}$

5: los símbolos "!" y ":" están sesgados cuando no deberían estarlo , véase por ejemplo

${\displaystyle \{x:\Phi (x)\},\,{\frac {(4n)!}{n!^{4}}}.}$ A1E6 ( discusión ) 08:02 27 sep 2024 (UTC) [ responder ]

1. Pensé que se había solucionado con T375295, pero no funcionó para su ejemplo, por lo que lo volví a abrir y estamos trabajando en una solución.
2. es T375932 pero no estoy seguro de que se pueda resolver, ya que Unicode no tiene estilos de escritura y caligrafía separados (ver Símbolos alfanuméricos matemáticos .
3. Ahora es T375861, pero hay un error peor T375863 para el modo MathJax del lado del cliente.
4. Ahora es T375907.
5. Para mí, en el modo MathML, el signo ! está en posición vertical. Pero es un error T375935 en el modo MathJax del lado del cliente. -- Salix alba ( discusión ): 20:24 27 sep 2024 (UTC) [ responder ]

   ¡Gracias! A1E6 ( discusión ) 21:28 27 sep 2024 (UTC) [ responder ]

Errores de MathML:

1. El cambio de tamaño automático de \rangle y \langle no tiene en cuenta lo que está dentro del ket, sino lo que está fuera. Esto estropea casi todos los artículos de mecánica cuántica. Ejemplo: S. En general, creo que el cambio de tamaño automático es una idea terrible y nunca debería activarse de forma predeterminada, sino que debería controlarse con los comandos \left y \right como en LaTeX.

2. Los límites de integración se muestran arriba y debajo del signo de la integral, cuando deberían mostrarse a la derecha. Ejemplo: . ${\displaystyle \int _{a}^{b}}$

3. La barra vertical "|" introduce un espaciado espurio, lo que altera las probabilidades condicionales, entre otras cosas. Ejemplo: . ${\displaystyle p(a|b)}$

Errores de MathJax:

1. El cambio de tamaño automático de \rangle, \langle y | observa el operador más grande en una ecuación. Ejemplos: , , . Nuevamente, esto ilustra cómo el cambio de tamaño automático es una idea terrible. ${\displaystyle \prod |\psi \rangle }$ ${\displaystyle \sum \langle \psi |}$ ${\displaystyle \sum p(a|b)}$

2. El glifo de la tubería simplemente no se representa en la siguiente expresión: . Supongo que se redimensiona automáticamente y el glifo de ese tamaño no existe. Tercer ( discusión ) 10:09 27 sep 2024 (UTC) [ responder ] ${\displaystyle \max _{B_{y}^{b}|\psi \rangle }}$

MathML #1 Ahora es T375959 y parece que se solucionará pronto. Un error antiguo T137788 agrega el comando \middle, que se necesita para un corchete completo. ¿Es necesario?

MathML #2 Este es T375349

MathML #3 parece un problema similar a T375337. Estamos discutiendo el comportamiento deseado, ya que LaTeX y MathML tienen ideas diferentes sobre cuál debería ser el espaciado.

MathJax #1, con suerte corregido al mismo tiempo que la versión MathML.

MathJax #2, no puedo reproducir esto. ¿Qué navegador y sistema operativo estás usando? -- Salix alba ( discusión ): 22:03 28 sep 2024 (UTC) [ responder ]

¡Gracias por todo tu trabajo!

MathML #1: \middle ciertamente sería bueno tenerlo, pero no lo consideraría necesario, ya que siempre es posible dimensionarlo manualmente.

MathML #3: No creo que haya muchas opciones aquí, si no sigues el estándar LaTeX romperás la mitad de Wikipedia. Encontré otro glifo problemático: los dos puntos introducen espaciado en LaTeX, pero no en MathML/MathJax. Esto estropea, por ejemplo , . ${\displaystyle f:X\to Y}$

MathJax #2: Firefox 130 en Ubuntu 22.04. Probablemente sea un problema de fuentes, porque tengo otra máquina con el mismo navegador y sistema operativo, y la tubería aparece allí. Sin embargo, no sé cómo diagnosticarlo. Tercer ( discusión ) 11:14 29 sep 2024 (UTC) [ responder ]

{code|f:X \to Y} ahora es T375974. Los dos puntos se tratan como un identificador <mi>:</mi>en lugar de un operador <mo>:</mo>. Hay muchos otros símbolos que probablemente deberían tratarse como operadores. -- Salix alba ( discusión ): 14:24 29 sep 2024 (UTC) [ responder ]

Encontré otro problema urgente: tanto en MathML como en MathJax, \| se representa como una sola tubería, en lugar de una tubería doble. Esto altera la visualización de normas y entropías relativas, entre otras cosas. Ejemplo: . Tercer ( discusión ) 10:19, 4 de octubre de 2024 (UTC) [ responder ] ${\displaystyle \|A\|,D(p\|q)}$

T376546 Tengo la corazonada de que será fácil solucionarlo. -- Salix alba ( discusión ): 20:30 5 oct 2024 (UTC) [ responder ]

¡Gracias! Tercero ( discusión ) 21:01 5 oct 2024 (UTC) [ responder ]

Actualizaciones sobre el progreso

Le he transmitido algunas de sus inquietudes a un empleado de la fundación involucrado, en T271001, y me ha brindado algunos comentarios útiles.

Sobre el tiempo:

Actualmente estamos esperando la ronda final de control de calidad y tenemos varios informes de errores iniciales que debemos resolver. En este momento, no tenemos prisa por invitar a más usuarios o a wikis piloto completos.

Aún no hay una fecha límite establecida para Mathoid y no está habilitado en ningún lado de forma predeterminada (más allá de las pruebas de grupo 0 y del grupo beta). Como puede ver arriba, no faltan comentarios en este momento, por lo que no tenemos prisa por obtener comentarios más amplios o habilitarlo todavía.

Sobre las opciones:

• Si se prefiere la interacción y el estilo exactos de la representación actual, se habilita la preferencia "del lado del cliente de MathJax". Esto se mantendrá a largo plazo.
• Está previsto eliminar en el futuro la opción "SVG", desarrollada por Mathoid con MathJax del lado del servidor.

Sobre la comunicación:

Aún no tenemos prisa por obtener comentarios más amplios ni por permitir que se implemente. Solo haría que la gente pierda tiempo informando errores duplicados o conocidos y sería menos probable que lo intenten nuevamente más tarde para encontrar otros problemas.

Prefiero que la Fundación haga desarrollo de software en público, ya que así el borrador está disponible para que todo el mundo lo vea.

Decidí no anunciarlo ampliamente hasta que estemos más seguros de ello.

Generalmente alentamos a los miembros de la comunidad que son expertos en tecnología a que hagan esta divulgación directamente, exactamente como lo hiciste tú, y que envíen los informes de errores aquí. No me importa hacer más divulgación yo mismo también en un puñado de páginas de discusión sugeridas. Hablo holandés, inglés y un poco de alemán :)

Sobre las pruebas de aceptación del usuario:

Por supuesto. La aceptación se basa en casos de prueba conocidos que se aprueban sin problemas y en informes de errores como los anteriores. Consideraría los siguientes tipos de errores como bloqueadores:

• Fallos donde aparecen símbolos que no deberían.
• fallos donde no aparecen símbolos que deberían aparecer.
• fallos donde los símbolos aparecen en un lugar obviamente incorrecto.

El objetivo no es una representación idéntica en píxeles a MathJax, por lo que el tamaño exacto de la fuente y el espaciado pueden variar. Esto es en parte una característica que permite que estos aspectos ahora se puedan personalizar con CSS a través de estilos de usuario y los navegadores web individuales lo decidan. Tenemos algunas conexiones con los proveedores de navegadores (Mozilla/Google/Apple), por lo que si hay errores causados ​​por la representación HTML>pantalla en los navegadores, en lugar de la representación HTML LaTeX>MathML en MediaWiki, también podemos ayudar a escalar los informes de errores. Puedes compartir enlaces a https://bugs.webkit.org/, https://bugzilla.mozilla.org/ o al rastreador de problemas de Chromium.

También se recomienda ir a https://www.mediawiki.org/wiki//Extension:Math/Native_MathML_rollout_(2024) donde se pueden publicar los problemas encontrados. -- Salix alba ( discusión ): 07:27 9 oct 2024 (UTC) -- Salix alba ( discusión ): 07:27 9 oct 2024 (UTC) [ responder ]

Página de implementación de MathML en mi navegador: ¿La parte superior e inferior de la captura de pantalla deben verse aproximadamente iguales?

"El objetivo no es una representación idéntica en píxeles a MathJax, por lo que el tamaño exacto de la fuente y el espaciado pueden variar. Esto es en parte una característica que permite que estos aspectos ahora se puedan personalizar con CSS a través de estilos de usuario, y los decide cada navegador web". – Esta es una idea terrible. Hay muchos ajustes manuales necesarios para que la representación matemática se vea bien en casos extremos o brechas en la representación predeterminada, pero el ajuste necesario difiere según la fuente que se use. Además, muchas fuentes simplemente tienen métricas integradas deficientes, sin mencionar símbolos mal distinguidos, etc. Todo este esfuerzo no va a funcionar a menos que elija un solo conjunto específico de fuentes matemáticas y lo envíe a cada lector, de modo que los autores tengan la seguridad de que los lectores ven un resultado casi idéntico. El plan de dar a cada lector y a cada dispositivo fuentes diferentes no es una forma aceptable de avanzar para Wikipedia. – jacobolus  (t) 14:17, 9 de octubre de 2024 (UTC) [ responder ]

Intentaré traducir tu comentario sobre Phabricator en errores individuales.

1. Hay muchos defectos sutiles de espaciado (por ejemplo, el espaciado vertical es incorrecto en la fracción x/2)
2. El superíndice 2 utiliza la fuente incorrecta (usa una fuente 2 reducida de una fuente destinada a un tamaño normal en lugar de una fuente 2 con la escala óptica adecuada destinada a un tamaño de superíndice)
3. Las dos líneas de la parte inferior se han aplastado juntas.
4. Los tachados de las letras "y" son demasiado pequeños (y en esta fuente, y no es un carácter legible para tachar porque el tachado se superpone a la pata de la y)
5. el renderizador no entiende las direcciones de alineación explícitas del marcado de origen (que solicitaba alineación a la izquierda, alineación al centro y alineación a la derecha), aunque este es un mal ejemplo porque la gente debería usar LaTeX \align en lugar de \array para esta cosa específica.

No 4. Es un error. Es peor en Chrome que en Firefox, ya que el aviso no se muestra en absoluto. T376829

No 5. He iniciado un nuevo error T376838 para esto, bastante cerca de T375317 pero es para \begin{align}, en lugar de \begin{array}.

No 1. No puedo ver esto. Aquí hay una variedad de fracciones en modo SVG y MathML. SVG: MathML: ${\displaystyle {\frac {x}{x}}\quad {\frac {x}{y}}\quad {\frac {x}{l}}\quad {\frac {x}{2}}}$${\displaystyle \frac{\mathrm{incógnita}}{\mathrm{incógnita}}\frac{\mathrm{incógnita}}{y}\frac{\mathrm{incógnita}}{\mathrm{yo}}\frac{\mathrm{incógnita}}{2}}$SVG: MatemáticaML: ${\displaystyle {\frac {x}{x}}\quad {\frac {y}{x}}\quad {\frac {l}{x}}\quad {\frac {2}{x}}}$${\displaystyle \frac{\mathrm{incógnita}}{\mathrm{incógnita}}\frac{y}{\mathrm{incógnita}}\frac{\mathrm{yo}}{\mathrm{incógnita}}\frac{2}{\mathrm{incógnita}}}$El espaciado se ve correcto con una línea de base consistente y dejando espacio para ascendentes/descendentes.

No 2. No lo entiendo muy bien, el SVG usa <use transform="scale(0.707)" xlink:href="#E1-MJMAIN-32" x="613" y="583"/>para el 2 , por lo que es una transformación lineal de la fuente. El MathML usa un font-family: math; font-size: 11.89px;en comparación con una fuente de 16px para el mc . Este parece un mejor comportamiento, los diseñadores de fuentes ajustan las fuentes para diferentes tamaños de fuente. Esto es lo que se obtiene de una instalación de MathJax simple, recuerde que SVG fue un truco para que MathJax funcionara en el servidor.

No 3. ¿Podrías explicarme esto más? -- Salix alba ( discusión ): 21:05 9 oct 2024 (UTC) [ responder ]

(1) Así es como se ve tu ejemplo en mi navegador:

En mi opinión, las versiones de MathML están completamente rotas. Puede que se vean bien en un navegador diferente, en un dispositivo diferente o en una versión diferente del navegador. Ese es el punto principal de la crítica: MathML no se reproduce de manera uniforme en todos los dispositivos, especialmente si la fuente no está estandarizada, lo que hace que sea prácticamente imposible para los autores de páginas escribir un marcado que se reproduzca de manera uniforme (o incluso apenas legible) en todos los navegadores de los lectores. Hasta que la versión de MathML no se haya probado en cientos de configuraciones diferentes de dispositivos y navegadores, incluidos dispositivos de 10 años de antigüedad que ejecutan software de 10 años de antigüedad, no estará lista para producción para los propósitos de Wikipedia, que tiene una audiencia extremadamente amplia que incluye a muchas personas que ejecutan hardware/software antiguos. No deberíamos impedir que las personas lean artículos técnicos de Wikipedia porque su computadora portátil o teléfono estén desactualizados.

En relación a sus otras preguntas:

(2) Siempre que se utilicen símbolos de varios tamaños uno al lado del otro, es necesario utilizar una fuente diferente para cada uno (o una " fuente variable " sofisticada que ajuste sus proporciones para cada tamaño); los tamaños más grandes necesitan trazos proporcionalmente más finos y proporciones más estrechas, los tamaños más pequeños necesitan trazos proporcionalmente más gruesos y proporciones más achaparradas. Consulte Fuente § Tamaño óptico . Las tipografías matemáticas típicas de LaTeX tienen varias fuentes diferentes destinadas a diferentes tamaños, incluida una fuente "estándar" y también fuentes separadas para fracciones en línea, superíndices/subíndices, super-superíndices, etc. Si utiliza la misma fuente para símbolos en varios tamaños diferentes, las que se han escalado uniformemente son incorrectas: tienen un peso visual distrayentemente desigual que es feo y menos legible. Solo se deben utilizar fuentes matemáticas que tengan varios tamaños ópticos diferentes para representar tipografía complicada, como notación matemática, y cualquier renderizador utilizado debe poder elegir correctamente la fuente correcta para diferentes tamaños de símbolos.

(3) Aparentemente, se suponía que debían existir dos líneas separadas de ecuaciones no relacionadas, pero se juntaron en una sola línea sin ningún espacio entre ellas. No está claro qué está pasando allí.

– jacobolus  (t) 22:55 9 octubre 2024 (UTC) [ responder ]

(1) ¿Qué navegador y qué sistema operativo? Es evidente que la captura de pantalla no supera la prueba de aceptación, pero necesitamos poder reproducir el error.

(2) Tener la font-family: mathsregla CSS debería indicar al navegador que debería usar una fuente con capacidad matemática. Chrome respeta esta opción y puedes ver la opción en chrome://settings/fonts con las fuentes matemáticas predeterminadas siendo Cambria math en Windows. Firefox hace las cosas un poco diferente, pero parece que usa por defecto Latin Modern Math en Windows. Ambas son fuentes que respetan la tabla matemática OpenType , por lo que deberían escalar correctamente. Nuevamente, conocer el navegador y el sistema operativo ayudará. Pero necesitamos ejemplos concretos de fallas para poder hacer un informe de errores o hacer algo.

(3) También es algo que puedo reproducir con mis navegadores de Windows. Salix alba ( discusión ): 00:25 10 oct 2024 (UTC) [ responder ]

Necesitamos poder reproducir errores para corregirlos, pero es inaceptable decirles a los lectores de Wikipedia que la razón por la que no pueden leer los artículos de matemáticas de Wikipedia es que tienen el navegador, el sistema operativo o la base de fuentes instalada incorrecta. Debe funcionar de inmediato, para lectores en entornos muy diferentes, en plataformas muy diferentes y con niveles muy diferentes de experiencia técnica. Obviamente, eso no es cierto para MathML hoy en día, y es por eso que creo que MathML es una opción inaceptable. — David Eppstein ( discusión ) 00:51, 10 de octubre de 2024 (UTC) [ responder ]

Este es Safari v. 15.6.1 que se ejecuta en MacOS 10.15.7, pero el espaciado de la barra de fracción también es inaceptable en el Safari reciente de iPhone, la apariencia es mediocre pero en la vaga dirección de correcta en Firefox v. 131, y MathML no se representa en absoluto en Chrome v. 87. – jacobolus  (t) 02:47, 10 de octubre de 2024 (UTC) [ responder ]

En cuanto al punto (2), como he dicho en repetidas ocasiones, pedir a los lectores que traigan su propia fuente matemática es estrictamente inaceptable para el uso en producción en Wikipedia en inglés. Wikipedia necesita enviar todas las fuentes necesarias de una única y buena fuente matemática (hay varias disponibles de forma gratuita) a cada lector para que las opciones de MathML o MathJax del lado del cliente sean mínimamente aceptables. No es posible ni siquiera evaluar qué es un error en el renderizador, qué es un error en el mecanismo de reserva de fuentes y qué es un error en cada fuente individual sin tener una línea de base consistente.

Para ser honesto, dudo que continuar con esta conversación sea un uso súper productivo del tiempo. Mi recomendación sería que, si la Fundación quiere seguir este camino, entonces deberían pagarle a alguien para que elabore una configuración de prueba con varias docenas de dispositivos variantes de una amplia variedad y contratar a alguien con una experiencia significativa en los detalles de la tipografía matemática para que se siente junto al desarrollador o desarrolladores de esta función y revise en detalle la representación actual en varios dispositivos sentados uno al lado del otro (esto llevará días de trabajo a tiempo completo, si no semanas, solo para documentar y comprender todos los errores de representación actuales). Desde mi punto de vista, parece que la queja aquí no se está escuchando ni entendiendo, y siento que estamos desperdiciando nuestro aliento. Mi propia estimación es que la compatibilidad de MathML en los navegadores está literalmente a años de ser lo suficientemente consistente en todos los dispositivos de los usuarios finales como para ser un objetivo de representación productivo, y la salida actual de MathML de Wikipedia también está literalmente a años de correcciones de errores de verse profesional. El MathJax del lado del cliente es mucho más prometedor, pero también va a requerir al menos meses de trabajo serio, después de decidirse por un único tipo de letra para enviar a los lectores. – jacobolus  (t) 02:51, 10 de octubre de 2024 (UTC) [ responder ]

(1) Esto ahora es T376883

(3) Ahora es T376887

(2) Estoy totalmente de acuerdo contigo y con David en que no deberíamos exigir a los usuarios que instalen fuentes específicas ni que modifiquen la configuración de ninguna manera, y que el sistema debería funcionar bien, sin "fallos" en casi todas las combinaciones de plataformas y navegadores. Este debería ser el tipo de cosas que el equipo de control de calidad web evaluará. Podemos ayudar a garantizar un producto de calidad o retrasar la implementación reuniendo un buen corpus de ejemplos problemáticos para probar. Sabemos más sobre las complejidades de la tipografía matemática que el equipo de control de calidad.

User Agent Breakdowns es útil para ver la variedad de sistemas en los que necesita funcionar. -- Salix alba ( discusión ): 11:25 10 oct 2024 (UTC) [ responder ]

Tu prueba de tortura en cualquier tipo de Chrome/Chromium está rota. Aparte de los problemas de interletraje, tamaño y fuentes, todo lo que involucra matriz/alineación/mayúsculas y superposición/subposición está completamente roto. Publicaría una captura de pantalla, pero supongo que alguien en WMF es responsable de verificar cosas como el navegador más popular que se usa para acceder a Wikipedia. Tito Omburo ( discusión ) 11:45, 10 de octubre de 2024 (UTC) [ responder ]

Salix alba , ¿ha intentado buscar en en.wikipedia.beta.wmflabs.org/wiki//Help:MathTestNative? Es terriblemente malo. Además del problema de que todos los símbolos escalados usan la fuente "normal", aquí hay algunos problemas más:

(1) Cada acento diacrítico se representa incorrectamente, por ejemplo, \hat a se representa con el acento superpuesto a la letra, (2) los subíndices se representan incorrectamente con una posición vertical incorrecta (pero a veces demasiado alta y a veces demasiado baja), (3) \operatorname se representa incorrectamente, (4) \left\vert se representa incorrectamente, (5) \partial está demasiado cerca de la letra, (6) f' está completamente rota, (7) f^{(3)} tiene el superíndice dentro de la letra, (8) una raíz cuadrada con una fracción dentro se representa con una línea demasiado delgada en la parte superior, (8) podría decirse que esta es una mala manera de lograr el resultado pero \overset{\underset{\mathrm{def}}{}}{=} tiene las letras demasiado espaciadas, (9) \overline{abc} se representa con más o menos un guión que cruza la parte superior de la b, (10) los límites de \prod y \sum tienen una alineación vertical incorrecta y los símbolos \prod y \sum son demasiado pequeños, (11) \xrightarrow[T]{n\pm i-1} tiene una flecha de tamaño incorrecto y una alineación horrible de las partes de arriba/abajo, (12) \overbrace coloca una llave de tamaño normal girada hacia un lado sobre el medio de lo que sea que se esté arriostrando que no se estira y de todos modos es demasiado pequeña, (13) las barras de fracción consistentemente no son lo suficientemente anchas (aparte del problema del espaciado vertical), (14) \lim_{n \to \infty} tiene demasiado espacio horizontal alrededor de \to, (15) \int se representa con un símbolo demasiado pequeño y se superpone a una fracción siguiente, (16) x^3\, dx tiene demasiado espacio entre las partes, (17) 0.5 tiene demasiado espacio alrededor del punto decimal, (18) \binom{n}{k} usa paréntesis que son demasiado pequeños, (19) \begin{Vmatrix} x & y \\ z & v \end{Vmatrix} tiene tamaños desiguales para los || circundantes, (20) \bigl( representa un paréntesis de tamaño normal en lugar de uno más grande, (21) \begin{cases} ... usa una llave demasiado pequeña, (22) \begin{alignat} ... no se alinea correctamente en los puntos & indicados, (23) \begin{array}{lcl} no respeta las direcciones de alineación especificadas, (24) \hline en una matriz no se representa, y las líneas verticales indicadas no se representan en los anchos correctos, (25) | se representa con un símbolo demasiado pequeño que no coincide con otros corchetes como \langle, (26) el kerning es deficiente para las mayúsculas griegas (demasiado ancho) y las minúsculas griegas (en su mayoría demasiado ajustado, pero algunos demasiado anchos), (27) los símbolos en negrita de pizarra son demasiado débiles para ser legibles con doble línea, (28) \mathsf se representa más pequeño que las otras fuentes matemáticas, (29) \pm no está alineado verticalmente correctamente (demasiado bajo), (30) los paréntesis a veces se superponen al contenido interior, (31) el espaciado horizontal de los paréntesis con el contenido circundante es inconsistente y generalmente al menos ligeramente incorrecto, (32) aparte de representar el primo completamente incorrecto en x', el espaciado posterior es demasiado amplio, (33) el espaciado entre una variable regular y una función nombrada siguiente es demasiado ajustado, (34) el posicionamiento vertical de las líneas en \begin{cases} es inconsistente, (35) el espaciado entre los números y una variable siguiente es demasiado ajustado, (36) el espaciado alrededor de \cdots es demasiado ajustado, (36) el espaciado antes de ; es demasiado amplio, (37) \tfrac se representa incorrectamente (no es lo suficientemente pequeño,el espaciado vertical es demasiado estrecho), (38) las raíces cuadradas en fracciones son demasiado grandes y se extienden demasiado por debajo de la línea de base.

Y esta página ni siquiera tiene muchas expresiones complicadas en las que entran en juego cuestiones de espaciado más sutiles. – jacobolus  (t) 15:06, 10 de octubre de 2024 (UTC) [ responder ]

Firefox funciona considerablemente mejor con https://en.wikipedia.beta.wmflabs.org/wiki//Help:MathTestNative pero aún hay una larga lista de problemas. El uso de una fuente con una escala ingenua para fracciones en línea y superíndices, etc. sigue siendo un problema. Más allá de eso:

(1) los diacríticos no están bien posicionados, a veces demasiado bajos, a veces no centrados horizontalmente en relación con la parte superior visual de la letra, (2) el símbolo \hat tiene la forma incorrecta, parece una cuña en lugar de un sombrero y \widehat usa el mismo símbolo, (3) \lVert z \rVert tiene demasiado espacio horizontal alrededor de la z, (4) \operatorname{d}\!t tiene las dos letras superpuestas (\operatorname es incorrecto para este uso que debería ser simplemente \mathrm{d}, pero \operatorname necesita agregar espacio, que el espacio negativo se agregó como un ajuste para eliminar; este tipo de ajuste para el comportamiento del renderizador anterior se encontrará en toda la wikipedia y cualquier renderizador nuevo debe tener un espaciado lo suficientemente cercano al renderizador anterior para no romperlos todos), (5) \nabla\psi tiene demasiado espacio entre ellos, (6) las barras de fracción son demasiado delgadas, (7) dy/dx tiene demasiado espacio alrededor de la barra, (8) dy, dx tienen demasiado espacio entre letras, (9) f' está completamente roto aquí también, (10) \ddot y necesita que los puntos se empujen ligeramente hacia la derecha, (11) \shortmid usa el mismo símbolo que \mid, lo cual es incorrecto, (12) las raíces cuadradas tienen líneas superiores que son demasiado delgadas y no se alinean con la parte √ del símbolo, (13) \setminus y \smallsetminus usan el mismo símbolo, lo cual es incorrecto, (14) := se representa con demasiado espacio entre ellas, (15) 45^\circ tiene un círculo demasiado pequeño, (16) \not\operatorname{R} tiene un tachado desalineado, (17) \textstyle \prod_{i=1}^N x_i tiene el límite superior de la suma demasiado alto, y los límites no están alineados consistentemente a la izquierda, (18) \lim_{n \to \infty}x_n tiene demasiado espacio alrededor de \to, (19) \int\limits_{1}^{3}\frac{e^3/x}{x^2}\, dx tiene un límite superior desalineado horizontalmente y no hay suficiente espacio entre la integral y la fracción, (20) 0.5 tiene demasiado espacio alrededor del punto decimal, (21) \cancel{y} tiene un tachado mal alineado (no centrado verticalmente), (22) vmatrix y Vmatrix no tienen suficiente espacio entre el contenido y los delimitadores circundantes, (23) smallmatrix no se representa en small, (24) \begin{cases} tiene una llave con un trazo desproporcionadamente grueso en relación con la fuente y demasiado espacio vertical entre mayúsculas y minúsculas, (25) alignat no obtiene la alineación correcta en el & indicado, (26) \begin{array}{lcl} no aplica las direcciones de alineación indicadas, (27) \begin{cases} no tiene suficiente espacio horizontal entre la llave y el contenido, (28) \hline en una matriz se representa pero no va de borde a borde, y las líneas externas no se representan lo suficientemente gruesas, (29) \left / se representa demasiado pequeño alrededor de contenido grande, (30) |\bar{z}| se representa con un tamaño/alineación inconsistente || y ninguno de los lados tiene el tamaño o la alineación correctos.

– jacobolus  (t) 17:47 10 octubre 2024 (UTC) [ responder ]

Probé en.wikipedia.beta.wmflabs.org/wiki//Help:MathTestNative en Chrome en Android (teléfono Pixel, configuración predeterminada) y descubrí que se representaba muy mal en muchos sentidos:

• Diacríticos diminutos, demasiado por encima de sus letras
• La fuente del operador tiene una altura x significativamente mayor y un peso mayor que la fuente de la variable matemática, y no hay espacio entre los operadores y sus argumentos.
• Las letras griegas son demasiado anchas y están fuera de escala con las romanas.
• En diferenciales y derivadas, comas colocadas demasiado cerca de las fracciones en las que aparecen, tan cerca que parecen primos en las variables.
• Los primos reales se colocan diminutos y altos sobre la letra que modifican, indistinguibles de los diacríticos.
• Ell no parece una letra y, desde luego, no parece una ell. ¿Quizás sea una arroba extraña?
• El signo radical es mucho más pesado que su barra transversal, con un espacio visible donde deberían conectarse, y es demasiado alto y pequeño, hasta el punto de que en la expresión sqrt(x^3+y^3) parece que la raíz cuadrada solo está en los exponentes y no en toda la expresión. Supongo que esto solo empeoraría para los radicales anidados.
• En las pruebas de alfa y omega superpuestas, el alfa es minúsculo en comparación con el omega, independientemente de que esté por encima o por debajo. El gamma también es minúsculo.
• Las flechas superiores, las llaves superiores y las llaves inferiores tienen el tamaño de un solo carácter, independientemente de sobre qué se encuentren.
• El ejemplo de "Flechas" se ha vuelto completamente Zalgo (él viene). Los caracteres están todos superpuestos. Totalmente ilegible.
• En muchos casos, los límites de las sumas, productos e integrales tocan el signo de suma, producto o integral. Los signos de suma y producto son indistinguibles de las letras mayúsculas sigma y pi, demasiado pequeñas. El signo integral también es demasiado pequeño y se parece más a una letra sans serif en negrita con una s larga. El mismo problema con los límites que tocan los signos también se aplica a las letras bigcap y bigcup.
• Uno pensaría que traducir "0,5" sería tan fácil que no presentaría problemas. Se equivocaría. Hay demasiado espacio alrededor del punto decimal.
• Los coeficientes binomiales solo utilizan paréntesis que indican el tamaño y el peso del texto. Incluso en el caso de tbinom esto es incorrecto (parecen demasiado pesados).
• Los delimitadores izquierdo y derecho de la matriz solo utilizan el tamaño del texto. Esto nunca es correcto. En el caso en el que se ha utilizado explícitamente \bigl, el tamaño no ha cambiado, pero ahora hay un espacio en blanco adicional innecesario entre el delimitador y la matriz.
• Los casos y las fórmulas alineadas no están alineados. El corchete izquierdo de los casos es el tamaño del texto, lo cual nunca es correcto.
• En el caso de las "expresiones grandes entre paréntesis", tanto el ejemplo "malo" como el "bueno" parecen idénticos. Ambos son malos. Todas estas expresiones entre paréntesis utilizan solo delimitadores de tamaño de texto, lo que es incorrecto en todas ellas. Especialmente malas son las funciones de piso y techo en una fracción vertical, donde los delimitadores de piso y techo se elevan por encima de la línea media para que parezcan aplicarse solo a la parte superior de la fracción, lo que cambia el significado. En los ejemplos de paréntesis anidados con calificadores de tamaño diferente, todos se representan en un solo tamaño. Por alguna razón, el último de estos ejemplos, con las barras diagonales anidadas, coloca mucho más espacio alrededor de las barras diagonales que de las barras diagonales inversas.
• Los ejemplos con mathbf no funcionan. El resultado parece cursiva, con un peso de texto normal. El griego en negrita también es idéntico al griego sin negrita. Las mayúsculas cursivas griegas no son cursivas (están en posición vertical, como el griego predeterminado).
• La tipografía romana se muestra como sans-serif, pero la tipografía sans-serif se muestra como cursiva serif. La tipografía griega sans-serif es sans-serif, pero esto es igual que para todas las demás fuentes griegas; no hay cambios en la apariencia visible.
• Mathcal produce la apariencia que yo esperaría que produjera mathscr (letras rizadas). (Consulte Archivo:Mathscr-vs-mathcal.png para ver cómo se supone que deben verse).
• Fraktur no tiene ningún efecto; produce el mismo texto en cursiva que obtendría de forma predeterminada.
• En el texto "una expresión en línea como [integral] debería verse bien", no se ve bien, porque las integrales en línea deberían poner los límites a la derecha, pero aquí están colocados verticalmente arriba/abajo, lo que genera un mal espaciado de línea.
• No revisé cuidadosamente los ejemplos individuales al final del enlace, pero mi impresión general fue de fealdad, con muchos de los mismos problemas anteriores y algunos otros (como límites con signos de infinito que se vuelven demasiado grandes y dominan cualquier cosa para la cual se suponía que eran un límite).

Un comentario aparte sobre "la convención [de usar HTML para matemáticas en línea en lugar de formato matemático] es realmente molesta": estoy de acuerdo, pero predigo que cambiar a MathML aumentará el uso de esta convención, porque el formato MathML es tan malo que las matemáticas con formato HTML se verán mejor. — David Eppstein ( discusión ) 20:19, 10 de octubre de 2024 (UTC) [ responder ]

Gracias a Jacobolus, Tito y David por esto. Será necesario que haya un poco de triage aquí, ya que son muchos problemas y básicamente somos dos los que trabajamos en esto, y realmente solo podemos trabajar en unos pocos a la vez.

Tratando de pensar en prioridades 1) Los tres fallos que mencionó Krinkle: fallos donde aparecen símbolos que no deberían; fallos donde no aparecen símbolos que deberían; fallos donde los símbolos aparecen en un lugar obviamente incorrecto. 2) Los problemas que afectan a todos los navegadores, tienen una prioridad más alta que aquellos específicos de un navegador/SO. 3) Para un navegador/SO específico, por razones prácticas, es probable que se aborden primero los errores de Windows, ya que en la máquina que uso, puedo acceder a una Mac en la biblioteca del trabajo, pero el progreso allí será más lento.

En lugar de intentar hacer 90 informes de errores, copiaré los comentarios en mw:Extension:Math/Native MathML rollout (2024) y haré un triage/análisis allí. Con suerte, es más probable que los equipos de control de calidad web lo vean que aquí. -- Salix alba ( discusión ): 06:38, 11 de octubre de 2024 (UTC) [ responder ]

Si sólo estás haciendo esto con una única plataforma como referencia, entonces lo estás haciendo mal.

Por cierto, observo que en otro lugar User:Physikerwelt le dice a la gente que solo hay "problemas de diseño relativamente menores" con MathML, que "la mayoría de los navegadores tienen un buen soporte de MathML" y que "algunos wikipedistas aún prefieren imágenes sobre HTML" [1]. Todas estas afirmaciones son inexactas. Los problemas no son menores, las pruebas anteriores han encontrado una mala representación de MathML en varios navegadores y (hablando por mí mismo en lugar de por otros wikipedistas) preferiría una solución basada en HTML (que incluya también MathJax del lado del cliente en esa categoría) en lugar de una solución basada en imágenes, pero la prioridad en mi preocupación aquí es mucho más sobre lograr una apariencia de alta calidad en una amplia base de plataformas, y mucho menos sobre el medio a través del cual se representa. — David Eppstein ( discusión ) 07:10, 12 de octubre de 2024 (UTC) [ responder ]

Etiqueta de limpiezaEn el artículo sobreAlexéi PogorelovDurante los últimos 5 años

Hay un artículo sobre uno de los geómetras diferenciales más famosos. Lo primero que uno encuentra allí es este mensaje: " este artículo puede requerir limpieza para cumplir con los estándares de calidad de Wikipedia. El problema específico es: abreviarlo, especialmente la sección "Intereses científicos". Por favor, ayude a mejorar este artículo si puede ". ¿Por qué debería acortarse? ¿Qué debería eliminarse para que cumpla con los estándares de calidad? PadawanDG (discusión) 23:54 2 oct 2024 (UTC) [ responder ]

Simplemente divide la sección larga en subsecciones lógicas con encabezados, luego elimina la etiqueta y agrega referencias. Johnjbarton ( discusión ) 00:05 3 oct 2024 (UTC) [ responder ]

"Agregar referencias" debería significar: agregar referencias de otras personas que no sean Pogorelov, que discutan el trabajo de Pogorelov en profundidad. Las propias publicaciones de Pogorelov no son buenas referencias para afirmaciones sobre sus contribuciones a la investigación. — David Eppstein ( discusión ) 00:41 3 oct 2024 (UTC) [ responder ]

Ya veo. Gracias por las respuestas. He encontrado "En el centenario del nacimiento de Aleksei Vasil'evich Pogorelov" de AA Borisenko, A. Yu. Vesnin y NM Ivochkina, pero está detrás de un muro de pago . PadawanDG (discusión) 02:25 3 oct 2024 (UTC) [ responder ]

Parece que una gran parte (y quizás toda) de la sección "Intereses científicos" de la página wiki de Pogorelov ha sido plagiada de este artículo. ¿Quizás debería eliminarse hasta que se pueda escribir algo más adecuado? No conozco bien las políticas de la wiki sobre esto. Gumshoe2 ( discusión ) 02:45, 3 de octubre de 2024 (UTC) [ responder ]

Por ejemplo, con un párrafo elegido al azar, compare wiki:

El primer trabajo de AV Pogorelov sobre superficies de curvatura extrínseca acotada se publicó en 1953. En 1954, J. Nash publicó el artículo sobre inmersiones С1-isométricas, que fue mejorado por N. Kuiper en 1955. De estos estudios se desprende que una métrica de Riemann definida en una variedad bidimensional, bajo supuestos muy generales, admite una realización en una superficie С1-lisa en un espacio euclidiano tridimensional. Además, esta realización se lleva a cabo tan libremente como una inmersión topológica en el espacio de la variedad en la que está dada la métrica. Por lo tanto, está claro que para superficies С1, incluso con una buena métrica intrínseca, es imposible preservar las conexiones entre las curvaturas intrínsecas y extrínsecas. Incluso en el caso de que una superficie C1 tenga una métrica regular de curvatura gaussiana positiva, esto no implica la convexidad local de la superficie. Esto enfatiza la naturalidad de la clase de superficies de curvatura externa acotada introducida por Pogorelov.

a Borisenko-Vesnin-Ivochkina:

El primer artículo de Pogorelov sobre superficies con curvatura extrínseca acotada apareció en 1953. Sin embargo, en 1954 J. Nash publicó un artículo sobre inmersión isométrica C1, cuyos resultados fueron mejorados por N. Kuiper en 1955. Su trabajo mostró que, bajo supuestos bastante generales, una métrica de Riemann en una variedad de 2 puede realizarse en una superficie C1-suave en un espacio euclidiano tridimensional. Además, tal realización puede implementarse tan libremente como una inmersión topológica de la variedad con métrica en el espacio ambiente. De esto está claro que para las superficies C1 no puede haber tal conexión entre las curvaturas extrínseca e intrínseca, incluso con una métrica intrínseca agradable. E incluso cuando una superficie C1 tiene una métrica regular con curvatura gaussiana positiva, esto no significa que sea localmente convexa. Todo esto subraya que la clase de superficies de Pogorelov con curvatura extrínseca limitada es una clase natural.

Parece que todo esto fue añadido por Vlasenko D  ( discusión  · contribs ) en 2017. Gumshoe2 ( discusión ) 02:51, 3 de octubre de 2024 (UTC) [ responder ]

Copiar textualmente es malo . Siéntete libre de eliminarlo. XOR'easter ( discusión ) 03:10 3 oct 2024 (UTC) [ responder ]

Solo para aclarar, el documento del centenario es una gran fuente, pero copiar su contenido es, bueno, ilegal .

Solo como sugerencia, usaría Google Scholar para enumerar las publicaciones que citan una obra, por ejemplo, geometría extrínseca de superficies convexas y haría clic en Buscar dentro de los artículos citados, luego escribiría "revisión" en la barra de búsqueda. Esto muestra algunas fuentes que pueden ser revisiones de la obra, en otras palabras, fuentes secundarias . Las obras para física pueden funcionar para matemáticas. Johnjbarton ( discusión ) 03:13, 3 de octubre de 2024 (UTC) [ responder ]

Estoy de acuerdo con la opinión de Gumshoe2, los fragmentos que comparó están demasiado cerca unos de otros. Por cierto, editaré tu comentario, si no te importa, Gumshoe2, porque como otros señalaron, no podemos mostrar material con derechos de autor, incluso si es solo para comparar. Es más seguro de esta manera. PadawanDG (discusión) 03:27 3 oct 2024 (UTC) [ responder ]

Aquí el material es limitado (solo un párrafo) y claramente atribuido, creo que no es necesario editar mi comentario. Gumshoe2 ( discusión ) 03:29 3 oct 2024 (UTC) [ responder ]

¡Está bien! Deshice mi edición. PadawanDG (discusión) 03:31 3 oct 2024 (UTC) [ responder ]

Si el contenido plagiado sigue estando disponible cuando tenga más tiempo, lo eliminaré. De todos modos, aquí hay algunas referencias que pueden ser fuentes secundarias útiles para ciertas afirmaciones sobre el trabajo de Pogorelov:

• Trudinger, Neil S. ; Wang, Xu-Jia (2008). "La ecuación de Monge–Ampère y sus aplicaciones geométricas". En Ji, Lizhen ; Li, Peter ; Schoen, Richard ; Simon, Leon (eds.). Manual de análisis geométrico. N.º 1. Advanced Lectures in Mathematics. Vol. 7. Somerville, MA: International Press. págs. 467–524. ISBN 978-1-57146-130-8.MR  2483373.Zbl 1156.35033  .​
• Gilbarg, David ; Trudinger, Neil S. (2001). Ecuaciones diferenciales parciales elípticas de segundo orden . Classics in Mathematics (Segunda edición revisada de la edición original de 1977). Berlín: Springer-Verlag . doi :10.1007/978-3-642-61798-0. ISBN 3-540-41160-7.MR  1814364.Zbl 1042.35002  .​
• Li, An-Min; Simon, Udo; Zhao, Guosong; Hu, Zejun (2015). Geometría diferencial afín global de hipersuperficies . De Gruyter Expositions in Mathematics. Vol. 11 (segunda edición revisada y ampliada de la edición original de 1993). Berlín: De Gruyter . doi :10.1515/9783110268898. ISBN . 978-3-11-026667-2.MR  3382197.Zbl 1330.53002  .​
• Caffarelli, L. ; Nirenberg, L. ; Spruck, J. (1984). "El problema de Dirichlet para ecuaciones elípticas no lineales de segundo orden. Ecuación de I. Monge–Ampère". Communications on Pure and Applied Mathematics . 37 (3): 369–402. doi :10.1002/cpa.3160370306. MR  0739925. Zbl  0598.35047. (Errata:  doi :10.1002/cpa.3160400508)
• Cheng, Shiu Yuen ; Yau, Shing Tung (1976). "Sobre la regularidad de la solución del problema de Minkowski n -dimensional". Communications on Pure and Applied Mathematics . 29 (5): 495–516. doi :10.1002/cpa.3160290504. MR  0423267. Zbl  0363.53030.
• Cheng, Shiu Yuen ; Yau, Shing Tung (1977). "Sobre la regularidad de la ecuación de Monge–Ampère det(∂ ² u/∂x ⁱ ∂x ^j ) = F(x,u) ". Comunicaciones sobre Matemática Pura y Aplicada . 30 (1): 41–68. doi :10.1002/cpa.3160300104. MR  0437805. Zbl  0347.35019.
• Cheng, Shiu Yuen ; Yau, Shing-Tung (1986). "Hipersuperficies afines completas. I. La completitud de las métricas afines". Communications on Pure and Applied Mathematics . 39 (6): 839–866. doi :10.1002/cpa.3160390606. MR  0859275. Zbl  0623.53002.
• Nomizu, Katsumi ; Sasaki, Takeshi (1994). Geometría diferencial afín . Cambridge University Press . ISBN 0-521-44177-3.MR  1311248.Zbl 0834.53002  .​
• Calabí, Eugenio (1972). Hiperesferas afines completas. I . Convegno di Geometria Differenziale (24-28 de mayo de 1971); Convegno di Analisi Numerica (10-13 de enero de 1972). Istituto Nazionale di Alta Matematica, Roma. Simposios Matemáticos. vol. X. Londres: Academic Press . págs. 19–38. SEÑOR  0365607. Zbl  0252.53008.

(Por supuesto, para algunas afirmaciones, algunas de estas serían fuentes primarias y no secundarias). Gumshoe2 ( discusión ) 03:47 3 oct 2024 (UTC) [ responder ]

Justo antes de que estuviera a punto de eliminar el contenido en cuestión, me di cuenta de que su inclusión en diciembre de 2017 es anterior al artículo de la revista, publicado en 2019. ¿Entonces tal vez el plagio esté en la otra dirección? Sería inusual, ya que (algunos de) los autores de 2019 habían publicado previamente en Pogorelov, por lo que no habría ninguna necesidad aparente de que tomaran material de Wikipedia. No he podido encontrar ningún escrito anterior a 2017 del que se pudiera tomar el material. Así que no eliminaré ningún material por ahora. Gumshoe2 ( discusión ) 16:58, 5 de octubre de 2024 (UTC) [ responder ]

El artículo de la revista es en sí mismo una traducción de N. Kruzhilin de un original en ruso publicado en una revista paralela en ruso. Una posibilidad que podría imaginar es que la versión en ruso se completó y circuló considerablemente antes de la fecha de publicación de la edición dual inglés-ruso de 2019, y que el texto de nuestro artículo sea una traducción separada y cercana del mismo texto en ruso. Felix QW ( discusión ) 16:28 9 oct 2024 (UTC) [ responder ]

Creo que gran parte del contenido del artículo de 2019 está tomado de un artículo anterior de Borisenko de 2006: Борисенко, Александр Андреевич (2006). "Алексей Васильевич Погорелов—математик удивительной силы". Física matemática diaria, análisis, geometrías . Фізико-технічний інститут низьких температур ім. БІ Вєркіна НАН України.En particular, el párrafo utilizado como ejemplo arriba se repite textualmente (en ruso). Se puede encontrar una traducción al inglés aquí en arXiv. Pagliaccious ( discusión ) 18:03 9 oct 2024 (UTC) [ responder ]

Fusión de sólidos arquimedianos y catalanes

Ambos artículos, el sólido arquimediano y el sólido catalán , tienen propiedades similares y temas relacionados: son duales entre sí, por lo que tienen la misma simetría; dos de ellos tienen la propiedad de quiralidad, por lo que sus duales también son quirales. Sin embargo, esta razón no es lo suficientemente fuerte como para mantenerlos fusionados, a menos que haya más antecedentes en algunas fuentes. De todos modos, supongo que algunos de los miembros de este proyecto no están de acuerdo con esta idea. Dedhert.Jr ( discusión ) 12:28, 6 de octubre de 2024 (UTC) [ responder ]

No creo que deban fusionarse, aunque puede haber material sustancial repetido en ambos artículos. – jacobolus  (t) 15:51, 6 octubre 2024 (UTC) [ responder ]

Cuando pienso en reestructurar el artículo añadiendo fuentes y eliminando algunas investigaciones originales, dudo que su contenido sea demasiado breve. Los sólidos arquimedianos eran reconocibles por sus apariciones durante el Renacimiento , incluidas las obras de artistas y matemáticos; he realizado varios cambios en el artículo y he añadido algunas referencias para leer más. Sin embargo, los sólidos catalanes parecen menos reconocibles en absoluto en el contexto del descubrimiento; algunas fuentes mencionan que se les atribuye a Eugene Catalan y que todos los ángulos diedros de sus caras adyacentes son iguales (aunque tengo que encontrar esta afirmación pronto). Dedhert.Jr ( discusión ) 00:44 13 oct 2024 (UTC) [ responder ]

Rectas, semirrectas y segmentos orientados

Las líneas y los segmentos de línea normalmente no están orientados ni dirigidos . Por lo tanto, los conceptos de línea orientada y segmento de línea dirigido se introducen cuando la distinción es necesaria. Ahora bien, las semirrectas se definen a menudo como líneas semiinfinitas no orientadas o no dirigidas (véase, por ejemplo, Encyclopedia of Mathematics). Pero "rayo" es un sinónimo común de semirrecta, lo que puede causar cierta confusión con las semirrectas orientadas o dirigidas (véase, por ejemplo, PlanetMath). Es útil como modelo matemático para un rayo de luz físico (en medios homogéneos). Me preguntaba si un editor no involucrado podría proporcionar comentarios constructivos en Line (geometry) , por favor. ¡Gracias! fgnievinski ( discusión ) 03:18, 8 de octubre de 2024 (UTC) [ responder ]

Véase también varias fuentes en Talk:Laguerre transformations § List of references . La palabra de Laguerre para una línea orientada era "semi-droite" (literalmente "semi-recta"; en Euclides el equivalente griego de "línea" significa curva y las líneas rectas necesitan un calificador, pero en inglés finalmente abreviamos "línea recta" como "line"; en francés "línea recta" se abrevió en cambio como "straight"). Más tarde, en alemán e inglés, se usaron los nombres "spear" y "ray". Para los propósitos de Wikipedia en inglés, creo que un término como "línea orientada" (o quizás "línea dirigida") es el más explícito e inequívoco. – jacobolus  (t) 04:07, 8 de octubre de 2024 (UTC) [ responder ]

Todavía no he obtenido una respuesta directa sobre cómo se supone que un rayo orientado es algo diferente a simplemente, ya sabes, un rayo. fgnievinski ha estado publicando párrafos llenos de tecnicismos sobre esto que no me transmiten ninguna información.

Ahora que estás aquí, fgnievinski, tal vez esta pregunta se centraría en lo que me confunde de tus ediciones. ¿Permites que los rayos se dirijan solo hacia su ápice, solo en dirección contraria a su ápice, o imaginas que hay dos tipos de rayos, uno hacia y otro en dirección contraria? Si solo hay una orientación posible para cualquier rayo, entonces no tiene sentido elegir una orientación de una línea y luego usarla para orientar el rayo, porque no hay elección en cómo orientar el rayo. Por otro lado, si imaginas que hay dos tipos diferentes de rayos orientados, entonces deberías decirlo más claramente (con una fuente que lo diga claramente) en lugar de toda esta tontería sobre líneas orientadas. — David Eppstein ( discusión ) 04:32, 8 de octubre de 2024 (UTC) [ responder ]

Un punto y la orientación de una línea definen un rayo. A la inversa, un rayo define una línea orientada con un punto específico. Por lo tanto, la frase "rayo orientado" es, en el mejor de los casos, un pleonasmo y, en el peor, confusa (véase la publicación de David). No debe usarse en Wikipedia, a menos que haya (dudo) fuentes confiables que lo discutan. D.Lazard ( discusión ) 10:08 8 oct 2024 (UTC) [ responder ]

¿Es posible que el problema sea el mismo que en el caso de DAG (que, cuando se analiza literalmente, debería significar “bosque orientado”, pero en realidad significa “grafo dirigido sin ciclos”)? Por ejemplo, ¿quizás algunas personas usan la frase “media línea orientada” no con el análisis literal sino para referirse a la construcción que menciona D.Lazard (comenzar con una línea orientada, luego tomar la mitad de ella)? No veo dónde fgnievinski ha usado la frase “rayo orientado”. 100.36.106.199 ( discusión ) 10:06, 9 de octubre de 2024 (UTC) [ responder ]

La frase exacta fue "Una línea orientada semi-infinita se llama rayo", lo que no parece correcto. – jacobolus  (t) 14:08, 10 de octubre de 2024 (UTC) [ responder ]

La definición de "semilínea" de EoM y la primera definición de PM, citada anteriormente, no dicen nada sobre la orientación, solo definen un lugar geométrico. De manera similar, Pedoe (1988) define "semilínea" como un conjunto de puntos, sin implicar ninguna orientación, y llamando al punto A un "punto final" en lugar de "punto inicial". Wylie (1964) no menciona "semilínea", define un "rayo" e inicialmente no dice nada sobre la orientación: el punto A divide una línea en dos y el punto B selecciona una de las dos mitades. La orientación solo aparece más adelante en la discusión, cuando dice que la otra mitad tiene la dirección opuesta . Sería beneficioso para el lector hacerlo más explícito, indicando que a menudo se implica una dirección (de A a B), aunque estrictamente no es necesario. Por ejemplo, la definición de ángulo plano no requiere que los lados estén orientados, solo que sean concurrentes (que se encuentren en un vértice).

Empecé a asumir que la "media línea" no estaba orientada:

Ahora me doy cuenta de que a menudo se supone que la "media línea" está orientada:

En cualquier caso, el concepto de "la mitad de una línea no orientada" existe, como quiera que se le llame. fgnievinski ( discusión ) 17:32 10 oct 2024 (UTC) [ responder ]

Sigues sin abordar el tema. — David Eppstein ( discusión ) 19:40 10 oct 2024 (UTC) [ responder ]

El concepto de "la mitad de una línea no orientada" existe; sí, se llama "media línea" o "rayo" y se define típicamente como un lugar geométrico de puntos. Solo tiene una orientación implícita. No creo que un concepto separado de "la mitad de una línea orientada " sea muy útil o ampliamente utilizado, y no deberíamos dar a entender que así es como se define la palabra "rayo". Para adoptar su método de tabla:

– jacobolus  (t) 20:09 10 octubre 2024 (UTC) [ responder ]

Si nos atenemos a las fuentes citadas, algunos definen una semirrecta o un rayo como un objeto orientado, otros no. No logro ver qué se pierde al reconocer la distinción y transmitir más información sobre el tema. También veo cierta contradicción entre "tiene una orientación implícita" y "orientado: N/A".

En física y gráficos por ordenador, a menudo se trabaja con dos rayos que tienen direcciones opuestas pero el mismo lugar geométrico. Se denominan rayos entrantes y rayos salientes,[2] como si incidiesen sobre una antena receptora o emanasen de una antena transmisora, respectivamente. Utilizando la formulación vectorial, un rayo saliente es r(t)=p+t*d (para un tiempo positivo t>0, un punto inicial p y una dirección unitaria d); mientras que un rayo entrante es r'(t)=p+t*d' (para un tiempo negativo t<0, un punto final p y una dirección de visión invertida d'=-d). Los dos rayos trazan el mismo camino -por ejemplo, r(t=1)=p+d y r'(t=-1)=p+d- pero en tiempo inverso. Estos dos rayos orientados ocupan la misma semirrecta no orientada. fgnievinski ( discusión ) 03:24, 12 de octubre de 2024 (UTC) [ responder ]

Creo que esto resuelve el problema. De lo contrario, por favor, avísenme de cualquier problema pendiente. fgnievinski ( discusión ) 18:01 15 oct 2024 (UTC) [ responder ]

No, te estás confundiendo y estás sintetizando solo material vagamente relacionado. Cuando la gente habla de rayos "entrantes" y "salientes", por ejemplo, en el trazado de rayos (física) o el trazado de rayos (gráficos) , el contexto son rayos de luz físicos (o simulados) (ver Ray (óptica) ), no "rayos" como objetos de libros de geometría elemental. Como señalas, los objetos matemáticos utilizados para este modelado son principalmente puntos y vectores. – jacobolus  (t) 19:45, 15 de octubre de 2024 (UTC) [ responder ]

Los rayos de luz físicos o simulados tienen una formulación matemática en términos de un objeto geométrico. Reconozco que el tratamiento elemental de los rayos geométricos supone una dirección fija ( desde el punto final) o ninguna dirección en absoluto. Pero acabo de demostrar que los rayos geométricos suelen formularse con la dirección opuesta (y el mismo lugar geométrico) en algunas disciplinas con uso intensivo de las matemáticas.

Este debate plantea una cuestión más amplia y, a menudo, un punto de conflicto entre los wikipedistas que trabajan en artículos sobre conceptos geométricos: ¿deberían los artículos de Wikipedia sobre conceptos matemáticos servir sólo o principalmente a los matemáticos o también a un público más amplio? Porque una y otra vez encuentro que la cobertura de aplicaciones en física, mecánica e ingeniería no es bien recibida en los artículos sobre geometría. No es raro que los editores que son "dueños" del artículo comiencen a actuar de manera despectiva.

Estoy de acuerdo si el consenso es mantener los artículos matemáticos confinados a la visión más estricta o más estrecha de los matemáticos profesionales. Entonces sus aplicaciones podrían estar bien segregadas en otros artículos, por ejemplo, Ray (óptica)#Formulación . fgnievinski ( discusión ) 03:13, 16 de octubre de 2024 (UTC) [ responder ]

Los rayos de luz físicos o simulados tienen una formulación matemática en términos de un objeto geométrico. – En mi opinión, esto no es lo mismo que lo que se llama un "rayo" en los libros de geometría y trigonometría de la escuela secundaria, aunque ambos se nombran en base a una analogía con los rayos de luz. El objeto llamado "rayo" en los libros de texto de primaria se define como nada más ni menos que una media línea, y no tiene ninguna orientación explícita (pero como dije, se puede pensar que tiene una orientación implícita hacia el fin infinito, solo en el sentido de que es infinito en esta dirección; no hay movimiento real involucrado aquí, sin embargo, como lo habría con los rayos de luz físicos, en un modelo donde el espacio + el tiempo se dividen y se tratan por separado). Inventar que hay diferentes tipos de rayos "entrantes" y "salientes" (en el sentido de geometría de la escuela secundaria) con diferentes orientaciones en mi opinión es una definición personal idiosincrásica tuya que no está respaldada por fuentes y no se puede afirmar con la voz de Wikipedia sin violar las políticas sobre NPOV/OR.

– jacobolus  (t) 05:36, 16 de octubre de 2024 (UTC) [ responder ]

Además, una distinción importante entre objetos como rayos, líneas y segmentos tal como se definen habitualmente y líneas orientadas es que los primeros se consideran lugares geométricos de puntos, mientras que las líneas orientadas se consideran objetos primarios en sí mismas. Creo que probablemente deberíamos tener un artículo independiente titulado Línea orientada y, eventualmente, otro titulado Geometría de Laguerre que describa la geometría resultante cuando las líneas orientadas se toman como objetos fundamentales en lugar de puntos.

En lugar de decir "Una línea orientada semi-infinita se llama rayo", sería más defendible decir algo como "Un rayo es la mitad de una línea que ha sido dividida por un punto, que es infinita en una dirección y, por lo tanto, es similar a una línea orientada en la medida en que tiene una orientación implícita". – jacobolus  (t) 17:01, 8 octubre 2024 (UTC) [ responder ]

Creo que también es bastante común en otros tipos de geometría, como la geometría proyectiva, pensar en puntos y líneas como objetos primarios con una relación de incidencia, en lugar de líneas como subconjuntos de puntos. La diferencia es que la conceptualización de subconjuntos todavía funciona, mientras que en la geometría orientada necesitas que las líneas sean objetos para poder asignarles orientaciones. — David Eppstein ( discusión ) 17:51, 8 de octubre de 2024 (UTC) [ responder ]

Nuevamente, la única diferencia real entre las líneas definidas como objetos primitivos y las líneas definidas como conjuntos de puntos es que la relación de incidencia se denota con ⁠ ⁠ ${\displaystyle \in }$ en el último caso.

Al editor Jacobolus : "mitad de una línea" es una formulación confusa, ya que implica que una línea tiene más de dos mitades. Por lo tanto, yo diría: "Un rayo es la parte de una línea que se encuentra en un lado de un punto de la línea; por lo tanto, un rayo es infinito en una dirección y tiene una orientación implícita (desde el punto hacia el infinito en el rayo), que define una orientación de la línea que contiene el rayo". D.Lazard ( discusión ) 22:29 15 oct 2024 (UTC) [ responder ]

Invitación

El Consejo de WikiProjects de Wikipedia es un grupo que habla sobre cómo organizar y apoyar WikiProjects. Si estás interesado en ayudar a WikiProjects o aprender más sobre ellos, agrega esa página a tu lista de seguimiento y únete a las discusiones que se realizan allí. Gracias, WhatamIdoing ( discusión ) 18:42 8 oct 2024 (UTC) [ responder ]

@WhatamIdoing No estoy seguro de qué hace este mensaje, pero ¿hay alguna razón por la que te gustaría preguntar aquí? Dedhert.Jr ( discusión ) 01:58, 9 de octubre de 2024 (UTC) [ responder ]

Este (WikiProject Mathematics) es uno de los WikiProjects más activos, según la cantidad de editores que visitan esta página de discusión. El Consejo de WikiProjects es un lugar para que la gente hable sobre WikiProjects: cuándo crearlos o fusionarlos, cómo reclutar nuevos participantes, dónde encontrar ayuda con las plantillas, etc. Si te interesa trabajar en equipo y quieres que tu grupo lo haga mejor, o ayudar a otros grupos a aprender de tus experiencias y éxitos, ¡únete a nosotros! WhatamIdoing ( discusión ) 02:15 9 oct 2024 (UTC) [ responder ]

Está bien. Pensé que estabas diciendo algo implícito sobre WPM, pero bueno... Dedhert.Jr ( discusión ) 13:58 9 oct 2024 (UTC) [ responder ]

"Isometría (matemáticas)" listado enRedirecciones para discusión

La redirección Isometría (matemáticas) ha sido incluida en redirecciones para discusión para determinar si su uso y función cumplen con las pautas de redirección . Los lectores de esta página pueden hacer comentarios sobre esta redirección en Wikipedia:Redirecciones para discusión/Registro/9 de octubre de 2024 § Isometría (matemáticas) hasta que se alcance un consenso. Esta discusión se beneficiaría particularmente de las contribuciones de aquellos familiarizados con el tema. Thryduulf ( discusión ) 10:36 9 oct 2024 (UTC) [ responder ]

Poliedro semirregular y sólidos arquimedianos

El término poliedro semirregular se utilizó como sinónimo de los sólidos arquimedianos en muchas obras. Pero, ¿cuál fue la razón y cómo los definieron antes de que otros matemáticos definieran esa clase de manera más general? Dedhert.Jr ( discusión ) 02:13 12 oct 2024 (UTC) [ responder ]

Reseña de Emmy Noether FA

Sería muy apreciado que la gente leyera el artículo de Emmy Noether y comprobara si hay afirmaciones poco claras, poco citadas o que no sean propias del proyecto de la enciclopedia. XOR'easter ( discusión ) 22:06 12 oct 2024 (UTC) [ responder ]

Para aquellos que conozcan mejor el tema que yo, las dos secciones que pueden necesitar más citas son las que tratan sobre las condiciones de cadena ascendente y descendente y la teoría de invariantes algebraicos . Sgubaldo ( discusión ) 23:29 12 oct 2024 (UTC) [ responder ]

Mi impresión, después de trabajar en el artículo anteriormente, fue que todo lo que se discute en él se aborda en las referencias ya presentes (y, para un tema de matemáticas, tener un número de enlace azul con un clic para cada oración no necesariamente satisface más a WP:V que tener uno por subsección). Pero esta sería una buena oportunidad para señalar a los lectores las referencias que son particularmente buenas. ¿Alguien tiene libros favoritos sobre cualquiera de esos temas? XOR'easter ( discusión ) 18:30, 13 de octubre de 2024 (UTC) [ responder ]

La sección sobre la teoría de invariantes algebraicos no hace suficiente contacto con el trabajo de Noether en el área, que fue eclipsado por el de Hilbert. Tanto la fuente de Rowe como la de Dick describen su disertación realizada bajo la dirección de Gordan, que se dedicó al cálculo simbólico de invariantes y, de hecho, fue una fuente posterior de cierta vergüenza. La sección se beneficiaría si enfatizara esto y resumiera mejor las fuentes (y hiciera referencia a ellas). Tito Omburo ( discusión ) 19:33 13 oct 2024 (UTC) [ responder ]

¿Te animas a abordar este tema? Podría intentarlo, pero no estoy seguro de cuándo tendré un bloque de tiempo ininterrumpido lo suficientemente largo. XOR'easter ( discusión ) 21:00, 13 de octubre de 2024 (UTC) [ responder ]

¿Pseudomatemático?

No puedo leer la fuente de esta edición y está publicada en una revista aparentemente legítima (de biología), pero la afirmación que hace me hace poner los ojos en blanco, al menos a mí. ¿Qué opinas? 100.36.106.199 ( discusión ) 10:35 15 oct 2024 (UTC) [ responder ]

Yo lo clasificaría dentro de la tendencia general de encontrar la proporción áurea/Fibonacci en la naturaleza. No lo llamaría pseudociencia, pero me parece controvertido. Tito Omburo ( discusión ) 15:30 15 oct 2024 (UTC) [ responder ]

El artículo al que se hace referencia es 2024 y una referencia primaria no citada. En el Wikiproyecto de física, a menudo eliminamos estas fuentes porque no son importantes ni enciclopédicas. Johnjbarton ( discusión ) 15:43 15 oct 2024 (UTC) [ responder ]

Me parece una basura total, que merece ser eliminada, pero no es tan dañina como los consejos financieros basura basados ​​en los números de Fibonacci. — David Eppstein ( discusión ) 17:37 15 oct 2024 (UTC) [ responder ]

Estoy de acuerdo con la eliminación. Cualquier afirmación en un área que está plagada de afirmaciones tontas necesita un respaldo mucho más sólido que ese. XOR'easter ( discusión ) 22:11 15 oct 2024 (UTC) [ responder ]

¡Gracias a todos! 100.36.106.199 ( discusión ) 10:13 17 oct 2024 (UTC) [ responder ]

Evento del día Pi

Yo y @ Daniel Mietchen estábamos discutiendo posibles eventos comunitarios para mejorar los artículos de matemáticas en la wiki, y una idea que surgió fue un evento para el día Pi (o Mes Pi). Ha habido algunas actividades en todo el sitio en el pasado, como la campaña de artículos vitales de 30kB , que fue exitosa, y podríamos modelar algo similar u optar por un enfoque más interactivo, como un edit-a-thon virtual . Dado que el día Pi todavía está a varios meses de distancia, hay mucho tiempo para planificar. Estoy publicando esto aquí para medir el interés y recopilar ideas iniciales. ¿Sería esto algo en lo que la gente querría participar? Y si es así, ¿alguien estaría interesado en unirse a un comité de planificación para ayudar a organizar y dar forma al evento? Mathnerd314159 ( discusión ) 15:20, 16 de octubre de 2024 (UTC) [ responder ]

Esa es una idea discutible. La mejora de un artículo sobre matemáticas la hacen mejor las personas que conocen y se preocupan por el tema y tienen una buena formación en matemáticas y razonamiento lógico, por no hablar de la claridad de la exposición. No queremos que estudiantes universitarios al azar empiecen a editar artículos a lo loco, que luego tendrán que ser retocados por otros. Si hay una forma de garantizar la competencia de los participantes, bien. De lo contrario, tengo mis dudas. PatrickR2 ( discusión ) 05:33, 18 de octubre de 2024 (UTC) [ responder ]

No estoy de acuerdo en absoluto con esa postura. Es elitista y contraria al principio fundamental de Wikipedia, una enciclopedia que cualquiera puede editar. No es necesario tener conocimientos de matemáticas para editar artículos sobre matemáticas. Además, se podría pensar que cualquiera que asista a un maratón de edición del día Pi tendrá interés en el tema. Polyamorph ( discusión ) 09:06 18 oct 2024 (UTC) [ responder ]

Bueno, es cierto que la calidad de los artículos producidos es una preocupación. Estaba pensando particularmente en empezar con la lista de artículos solicitados , donde (en términos generales) cualquier artículo es mejor que ninguno. Y luego, como dice Polyamorph, cualquiera (incluidos "estudiantes universitarios al azar") puede producir un buen artículo; es solo una cuestión de educarlos en las políticas de Wikipedia y brindarles los recursos adecuados para escribir el artículo. Mathnerd314159 ( discusión ) 14:53, 18 de octubre de 2024 (UTC) [ responder ]

Escribí una página de consejos generales para ayudar con ese tipo de cosas. XOR'easter ( discusión ) 03:08 19 oct 2024 (UTC) [ responder ]

Especialmente cuando se trata de la lista de artículos solicitados, es importante estar familiarizado tanto con las normas de Wikipedia como con el tema en cuestión, porque la lista no ha sido seleccionada por su notoriedad o importancia y muchas de sus solicitudes duplican artículos existentes, consisten en lagunas muy necesarias en la literatura o son intentos de autopromoción. No esperaría necesariamente suficiente discernimiento de los participantes típicos de un maratón de edición. — David Eppstein ( discusión ) 06:52, 19 de octubre de 2024 (UTC) [ responder ]

Considero que estos comentarios son desagradables, elitistas y restrictivos. Cualquiera, incluidos los participantes del maratón de edición, es más que bienvenido a editar cualquier artículo que desee. Los usuarios nuevos y antiguos aprenden sobre la política y las mejores prácticas a lo largo del camino. Desalentar a los usuarios basándose en una idea preconcebida de su competencia va en contra del tercer pilar WP:5P3 . Wikipedia necesita nuevos usuarios, se los debe alentar. Polyamorph ( discusión ) 07:00, 19 de octubre de 2024 (UTC) [ responder ]

Bueno, el triste hecho es que muchas ediciones de estudiantes (por ejemplo, las que se hacen para las tareas de clase) han resultado mal. Si queremos que un maratón de edición salga bien, alguien tiene que hacer el trabajo preliminar primero, como por ejemplo, seleccionar una mejor lista de artículos potenciales. Al revisar las sugerencias vinculadas arriba , veo muchos ejemplos en los que los aficionados y los estudiantes universitarios no tendrían idea de lo que significa el tema. Una lista de posibles artículos biográficos podría ser un mejor punto de partida. XOR'easter ( discusión ) 16:42 19 oct 2024 (UTC) [ responder ]

Sí, iba a mencionar la limpieza que se requiere después de las tareas de clase. Una cosa es crear artículos nuevos y otra cosa es intentar reescribir el contenido de matemáticas. Tito Omburo ( discusión ) 16:56 19 oct 2024 (UTC) [ responder ]

Las tareas de clase, en las que se pide a los estudiantes que editen, no son lo mismo que un maratón de edición, en el que la gente se ofrece voluntariamente a editar con la misma motivación y objetivos que el resto de nosotros. Estoy de acuerdo en que a veces hay problemas con las actividades de WikiEd, pero esto no es lo que propone Mathnerd314159 . Como ocurre con cualquier edición, si se comete un error o el contenido no es adecuado, por cualquier motivo, se tratará de la forma habitual. Se debe fomentar cualquier actividad que fomente la edición de buena fe por parte de los nuevos usuarios, y ningún artículo debería estar prohibido. Polyamorph ( discusión ) 17:15 19 oct 2024 (UTC) [ responder ]

Sí, la gente que se ofrece como voluntaria va a tener un mayor nivel de entusiasmo, en igualdad de condiciones, lo cual es bueno. Sin embargo, creo que muchas de las mismas preocupaciones que hemos tenido con las contribuciones a WikiEd seguirán siendo válidas: falta de familiaridad con lo que se considera una buena referencia, falta de familiaridad con el estilo de escritura enciclopédica, abarcar más de lo que un novato puede manejar, etc. No quiero desanimar a nadie a que pruebe suerte en la edición, y no quiero desanimar a los editores experimentados a que lleven a cabo una actividad como esta; sólo digo que necesitamos tener una idea realista de los desafíos y un plan sólido para abordarlos. Por ejemplo, como se señaló anteriormente, podemos hacerlo mejor a la hora de sugerir nuevos artículos para crear y artículos existentes para mejorar. También podemos identificar buenas referencias con antelación y asegurarnos de que estén disponibles para los participantes del maratón de edición. Podemos seleccionar una colección de artículos de Wikipedia de alta calidad que puedan servir como ejemplos para que los nuevos editores aprendan de ellos. XOR'easter ( discusión ) 19:05 19 oct 2024 (UTC) [ responder ]

Eso es muy razonable y estoy de acuerdo en que una buena planificación ayudará a mejorar las posibilidades de obtener resultados exitosos. Polyamorph ( discusión ) 07:03 20 oct 2024 (UTC) [ responder ]

Un comentario meta: Creo que no deberías preocuparte tanto por defender esta propuesta; la gente que se enoja con ella se enojará con ella, y el que tenga éxito o no no dependerá en gran medida de tratar de convencer a la gente que se enoja al pensar en ella de que en realidad es una buena idea. JBL ( discusión ) 20:03 19 oct 2024 (UTC) [ responder ]

Vale, pero la suposición de que cualquier recién llegado va a ser un resultado negativo cuando tanto contenido matemático ya está en un estado lamentable va completamente en contra de los principios básicos del proyecto. Polyamorph ( discusión ) 06:57 20 oct 2024 (UTC) [ responder ]

"Clase" vs "editatón" parece una distinción sin diferencia. Básicamente estamos hablando de una especie de taller, ¿no? Tito Omburo ( discusión ) 21:37 19 oct 2024 (UTC) [ responder ]

Muchas ediciones de los estudiantes (por ejemplo, las que se hacen para las tareas de clase) han resultado mal. – Realmente creo que esto se debe a una mala planificación y apoyo de los instructores del curso que realizan dichas tareas y de cualquier personal del lado de Wikipedia que se supone que debe ayudar. Cada vez que he intentado iniciar una conversación con estudiantes o instructores del curso sobre cómo ayudar a los estudiantes a que sus proyectos sean exitosos, no he obtenido una respuesta útil. Entiendo que algunos proyectos de cursos (que no pertenecen a las áreas temáticas a las que presto atención) han tenido mucho éxito, en función de que el instructor tenga suficiente conocimiento y compromiso de trabajo/atención para que funcione. Creo que es plausible hacer que las ediciones de los estudiantes sean valiosas, pero es necesario que el estudiante elija un alcance apropiado para sus ediciones y luego realice una investigación cuidadosa en fuentes confiables para respaldar los cambios. – jacobolus  (t) 19:45, 19 de octubre de 2024 (UTC) [ responder ]

@ Polyamorph Esta no es una posición elitista. No queremos disuadir a nadie de editar Wikipedia. Pero al mismo tiempo, es más fácil para alguien empezar a editar artículos en ciencias como la física o la biología, diría yo, ya que probablemente haya más fuentes en estas áreas escritas para un público general a las que los editores puedan recurrir. Pero, como dicen, "no hay un camino real hacia las matemáticas". PatrickR2 ( discusión ) 06:12 20 oct 2024 (UTC) [ responder ]

Obviamente, eso es una completa tontería. Hay una gran cantidad de fuentes matemáticas accesibles para los simples mortales. Polyamorph ( discusión ) 06:50 20 oct 2024 (UTC) [ responder ]

Eso me recuerda a Anton Ego en Ratatouille, una de las mejores películas animadas de la historia: ... el famoso lema del chef Gusteau, "Cualquiera puede cocinar". Pero me doy cuenta de que solo ahora entiendo realmente lo que quería decir. No todo el mundo puede convertirse en un gran artista; pero un gran artista *puede* venir de *cualquier lugar*. No todo el mundo puede ser un gran editor de matemáticas de Wikipedia, pero un gran editor de matemáticas de Wikipedia puede venir de cualquier lugar :-) PatrickR2 ( discusión ) 18:55 22 oct 2024 (UTC) [ responder ]

Los estudiantes universitarios al azar de entre 2005 y 2010 fueron los creadores de una proporción sustancial de nuestros artículos de Wikipedia sobre temas que se ven comúnmente en los cursos de grado. Lo bueno de un proyecto público a largo plazo es que los artículos o secciones mal iniciados se pueden mejorar más tarde, incluso por parte de expertos. – jacobolus  (t) 15:10, 18 de octubre de 2024 (UTC) [ responder ]

Sí. Yo era un estudiante de posgrado cualquiera en ese período, que coincidentemente es cuando comencé a editar :) Polyamorph ( discusión ) 17:19 19 oct 2024 (UTC) [ responder ]

Una de las razones por las que tiendo a evitar los artículos sobre temas estándar de los cursos de grado es que puede ser una experiencia muy frustrante. Estos artículos tienden a leerse como si hubieran sido escritos por estudiantes de grado que estaban tomando el curso y entendían a medias el material (probablemente porque lo estaban haciendo) y requieren mucha limpieza. Peor aún, debido a que los diferentes libros de texto cubren estos temas de maneras superficialmente diferentes, cualquier limpieza es probable que sea rápidamente deshecha por otro estudiante de grado que no reconoce las diferencias, piensa que el artículo es incorrecto porque no sigue exactamente el libro de texto que está usando y reescribe el artículo de nuevo a su nivel anterior de medio entendido siguiendo otra fuente. Entonces toda la limpieza necesita ser rehecha, o los cambios revertidos y otro nuevo editor entusiasta mordido por hacer que sus esfuerzos sean completamente tirados a la basura. — David Eppstein ( discusión ) 18:32, 19 de octubre de 2024 (UTC) [ responder ]

Por otro lado, todavía tenemos muchos temas en el nivel avanzado de pregrado que faltan por completo, y algo es mejor que nada. Creo que el principal problema que tenemos es la falta de trabajo y atención a los temas matemáticos en general y la falta de atención de los expertos, en lugar de demasiada atención por parte de los estudiantes universitarios en sí. Como dices, cierta frustración surge de temas que tienen una terminología/descripción/organización variada en varias fuentes, que a veces incluso son objeto de disputas cuasi ideológicas entre autores, pero los temas que aparecen en múltiples áreas de las matemáticas también suelen estar más conectados centralmente con un alcance más amplio, etc. en comparación con temas más específicos u oscuros.

Pero también es más probable que se haga clic en estos temas y, en general, quizás sea más importante hacerlo bien. Por ejemplo, fue genial poder hacer que Simple Polygon tuviera una prosa clara y concisa, una organización clara y una cobertura relativamente completa, pero sería mejor aún hacer que Polygon tuviera un estándar similar (aunque llevaría más trabajo y sería más frustrante lograrlo).

Si encuentras algún artículo en particular que no sea bueno y que quieras mejorar, podemos intentar organizar a algunas personas para que trabajen en uno o varios a la vez. – jacobolus  (t) 20:05, 19 de octubre de 2024 (UTC) [ responder ]

Me gustaría que Circle mejorara. No se cita lo suficiente, tiene muchos puntos, está desorganizado, etc. Arreglar todo eso sería un gran trabajo, y los colaboradores del maratón de edición podrían perderse en el mar. Pero tal vez mejorar las citas sería una forma de facilitarles la tarea de mejorar los artículos. Sin embargo, habría que hacer un trabajo de preparación con antelación, como encontrar buenos libros de geometría del nivel adecuado y asegurarse de que esos libros estén disponibles para los participantes del maratón de edición. Creo que algunos de los eventos de Mujeres de Rojo se han celebrado en bibliotecas precisamente por esa razón. XOR'easter ( discusión ) 06:38 22 oct 2024 (UTC) [ responder ]

¿Y luego poner el artículo en la clase superior como en GA, o FA si es necesario para presentarlo en la página principal de Wikipedia? Me encantaría ver más artículos mejorados para que se hagan las referencias adecuadas y en un formato espléndido, especialmente cuando el artículo aparece en el día Pi. Si me gustaría ayudar a hacerlo, está bien, pero no tengo idea de cuánto tiempo puedo mejorar esto y cuánto puedo entender el tema. El tema fue un poco más difícil de lo que pensaba, especialmente sobre el trasfondo histórico, al igual que tuve que posponer Seno y coseno .

Hablando del Día Pi del año que viene, ya he propuesto una nueva lista de destacados. Dedhert.Jr ( discusión ) 10:38 22 oct 2024 (UTC) [ responder ]

@ XOR'easter También me gustaría que mejoraran Circle . Tal vez un maratón de edición podría ser un lugar para ello; no tengo mucha experiencia con este tipo de eventos. Un problema es que si la gente empieza a trabajar en serio en esto, para cuando llegue el maratón de edición, es posible que un artículo esté lo suficientemente en forma como para no necesitar más la ayuda de los participantes del evento. Pero supongo que, si es así, lo que se aprenda de eso se podría aplicar a algún próximo tema.

Una cosa que podría hacer que un maratón de edición (u otra colaboración) sea exitoso y un uso efectivo del tiempo de los voluntarios (tanto planificadores/mentores como participantes en el día) si queremos mejorar sustancialmente artículos subdesarrollados o pobremente desarrollados es descubrir un mejor proceso de escritura colaborativa que el común de hacer cambios fragmentados y dispersos a partir del contenido tal como existe en un momento particular, de modo que podamos generar cierto consenso con anticipación y hacer pedidos relativamente concretos de ayuda necesaria para que las personas puedan ponerse a trabajar de inmediato.

Creo que el primer paso más importante (independientemente de quién trabaje en el proyecto) para Circle, por ejemplo, es elaborar una lista mejor de subtemas importantes y estructurarlos y darles un flujo narrativo. No creo que haya mucho que rescatar de la organización actual de ese artículo, y el contenido actual necesita mucho trabajo de reelaboración. Una lista de buenas fuentes en varios niveles también sería genial, especialmente si también se estructura un poco en temas o perspectivas específicos. Si hay un buen esquema estructurado de temas con distintos tipos/cantidades de trabajo necesarios para terminarlos, y una indicación relativamente clara de lo que necesita cada parte, eso podría dar a los voluntarios a corto plazo una parte un poco más manejable de algo en lo que trabajar.

¿Existe algún tipo de lugar adecuado para actividades colectivas previas a la escritura, como hacer esquemas o reunir fuentes? Las páginas de discusión en sí no son muy buenas, en mi opinión. Estoy pensando en algo como Talk:Circle/Brainstorm o Talk:Circle/Rough drafts. – jacobolus  (t) 18:46, 22 de octubre de 2024 (UTC) [ responder ]

Hice una página en el espacio de usuario . XOR'easter ( discusión ) 23:16 22 oct 2024 (UTC) [ responder ]

Re "...que puede ser una experiencia muy frustrante": Es triste escucharlo. Igual que en los días en que solías nominar artículos sobre temas elementales como el triángulo isósceles y la cometa (geometría).

Re "... fueron escritos por estudiantes universitarios que estaban tomando el curso y entendieron a medias el material (probablemente porque lo eran) y requieren mucha limpieza.": ¿Incluso cosas restringidas en Wikipedia como, ya sabes, evitar que usuarios anónimos editen artículos específicos?

Re "...sigue exactamente el libro de texto que están usando y reescribe el artículo hasta que se lo entendía a medias siguiendo otra fuente". Pero en serio, esto es exactamente lo que me pasó hace poco cuando estaba haciendo un curso, buscando los modelos en geometría de incidencia, pero no pude encontrar nada exacto en Wikipedia aquí. Así que simplemente utilizo mi intuición al azar. Y es por eso que dos preguntas frecuentes son útiles para encontrar la razón por la que "no está aquí en Wikipedia", o lo que sea.

Re "otro nuevo editor entusiasta mordido por hacer que sus esfuerzos sean completamente desechados": Sucedió cuando reestructuré el artículo poliédrico Dodecaedro regular , y un nuevo editor que no tocó las herramientas de redacción del artículo se queja sin motivo y exige agregar algo, o una IP en Johnson sólido que quisiera restaurar el artículo; en este caso, creo que no se estaban acostumbrando con el artículo renovado.

Dedhert.Jr ( discusión ) 11:03 22 oct 2024 (UTC) [ responder ]

Borrador: M. Lawrence Glasser- Necesito ayuda

Rechacé este borrador, pero el creador, @Mofembot, se puso en contacto conmigo en mi página de discusión con información adicional, es decir, él es responsable del teorema maestro de Glasser , por lo que es muy probable que sea notable. Sin embargo, obtienen la mayor parte de su información de miembros de la familia, por lo que el borrador actualmente no tiene fuentes o las tiene de manera deficiente y ellos, como yo, no son matemáticos, por lo que tienen algunas dificultades. Se agradece cualquier ayuda. S0091 ( discusión ) 15:46, 18 de octubre de 2024 (UTC) [ responder ]

Desafortunadamente, la mayoría de los académicos vivos no han sido objeto de, por ejemplo, perfiles de revistas o biografías publicadas, lo que dificulta verificar las afirmaciones utilizando lo que Wikipedia considera fuentes confiables, y a menudo la "influencia" solo se encuentra en forma de citas a su trabajo en lugar de encuestas claras o análisis críticos extensos, lo que puede dificultar el establecimiento de la notoriedad. A menudo, los obituarios terminan siendo las mejores fuentes sobre académicos muertos, pero obviamente eso no ayuda con las personas vivas. A veces, una fuente como un artículo que anuncia la jubilación de alguien, un anuncio de premio o la introducción de un Festschrift contendrá material introductorio relevante sobre la vida del homenajeado. Creo que el principal consejo para cualquier artículo de Wikipedia con pocas fuentes es: seguir buscando fuentes. – jacobolus  (t) 16:20, 18 de octubre de 2024 (UTC) [ responder ]

Dos supresiones

Me gustaría invitar a los miembros de este proyecto a lo siguiente:

• Wikipedia:Artículos para eliminar/Lista de poliedros convexos de caras regulares
• Wikipedia:Redirecciones para discusión/Registro/13 de octubre de 2024#3.141592653589793238462643383279502884197169399375105820#3.1415926535…

Dedhert.Jr ( discusión ) 17:19 20 oct 2024 (UTC) [ responder ]

Fracción continua

Por favor, consulte la fracción Discusión:Continuación donde un editor sugiere mover el artículo a un título diferente para que se pueda mover otra cosa en su lugar, y contribuya a la discusión allí si tiene una opinión. — David Eppstein ( discusión ) 17:56 23 oct 2024 (UTC) [ responder ]