4 puntos por GN⁺ 2024-12-09 | 1 comentarios | Compartir por WhatsApp
  • Mathics Core 7.0.0 reorganiza el motor central del sistema de cómputo open source compatible con Mathematica, sentando las bases para la futura carga diferida de funciones integradas
  • Se agregan nuevas funciones integradas como ComplexExpand, ConjugateTranspose, LeviCivitaTensor y otras relacionadas con expresiones, álgebra lineal y detección de valores reales
  • Se corrigen vacíos de compatibilidad existentes en Range[], DirectedInfinity, Indeterminate, la visualización de errores en Graphics y los cambios en $CharacterEncoding
  • La carga de funciones integradas deja de depender de imports implícitos y pasa a usar una llamada explícita a import_and_load_builtins()
  • Incluye soporte para Python 3.11 y SymPy 1.12, junto con correcciones relacionadas con Quantity, SparseArray, Derivative, Exit[] y BaseForm

Dirección del lanzamiento y reorganización interna

  • Mathics Core 7.0.0 incluye una reorganización interna para soportar en el futuro la carga diferida de funciones integradas
  • Se modernizó el código y el estilo de Python, se ampliaron las anotaciones de tipos y se corrigieron varios errores ortográficos
  • También se actualizaron las dependencias de SymPy y Python a versiones más recientes
  • Además, se avanzó en mejoras para acelerar la carga inicial y reducir el uso de memoria al inicio

Nuevas funciones integradas

  • Las nuevas funciones integradas agregadas en esta versión son las siguientes
    • $MaxLengthIntStringConversion
    • Elements
    • ComplexExpand
    • ConjugateTranspose
    • LeviCivitaTensor
    • RealAbs, RealSign
    • RealValuedNumberQ

Mejoras en documentación y generación de pruebas

  • Se corrigieron varios problemas de formato en la documentación PDF
    • Se amplió el espaciado de los números de sección en el índice de capítulos y secciones
    • Se aumentó el margen alrededor de las definiciones de funciones integradas
    • Se limpiaron errores ortográficos a lo largo de la documentación
  • El código para ejecutar doctests y generar documentación LaTeX fue revisado y refactorizado
    • Ahora permite actualizaciones incrementales de funciones integradas
    • También se reorganizó para reducir código duplicado
  • En “Expression Structure” se agregó una nueva sección: Section Head-Related Operations
  • El título del PDF cambió de Mathics a Mathics3, y también se actualizó el texto introductorio
  • Los doctests antiguos en formato obsoleto, no públicos y no educativos, se migraron a pytest

Compatibilidad y cambios visibles para el usuario

  • *Plot no muestra mensajes durante la evaluación
  • Range[] ahora maneja di negativo
    • PR relacionada: #951
  • Mejoró el soporte para DirectedInfinity e Indeterminate
  • Graphics y Graphics3D se muestran con fondo rosa cuando incluyen primitivas o directivas inválidas
    • En la interfaz Mathics-Django también se muestran mensajes de error en tooltips
  • $CharacterEncoding puede cambiarse dentro de la sesión

Implementación interna y cambios de API

  • En Abs y Sign, eval_abs y eval_sign se separaron y se añadieron a mathics.eval.arithmetic
  • La cantidad máxima de dígitos numéricos permitidos en cadenas se fijó en 7000
    • En entornos como pyston, donde Python no lo ajusta automáticamente, puede configurarse con la variable de entorno MATHICS_MAX_STR_DIGITS
  • La implementación de comparación de números reales ahora entra internamente en la implementación de RealSign
  • En Python 3.11, $MaxLengthIntStringConversion controla el tamaño máximo de conversión literal entre enteros grandes y cadenas
  • La carga del código integrado cambió de un método implícito a uno de instrucción explícita
    • Este cambio busca habilitar en el futuro la carga diferida de funciones integradas o un “autoload” al estilo GNU Emacs
  • Con la nueva API hay que llamar explícitamente a import_and_load_builtins()
    • Antes, el momento de carga de las funciones integradas era implícito e indeterminado según el orden de importación
  • Se agregó una caché LRU a mpmath

Correcciones de errores en Quantity, SparseArray y otros

  • Definitions ahora es compatible con pickle
  • Mejoró el soporte para expresiones Quantity
    • Incluye conversión, formateo y operaciones aritméticas
  • La opción Background de Graphics y Graphics3D vuelve a funcionar
  • Se corrigió un problema de comparación numérica en expresiones que incluyen String
    • Issue relacionada: #797
  • Se corrigió un problema de Switch[] con Infinity
    • Issue relacionada: #956
  • Se corrigió un problema de Outer[] sobre SparseArray
    • Issue relacionada: #939
  • ArrayQ[] detecta SparseArray
    • PR relacionada: #947
  • Se maneja la excepción BoxExpressionError
  • Se corrigió el comportamiento de Derivative al evaluar True, False y List[]
  • Se incluyen correcciones en el paquete Combinatorica
  • Se corrigió Exit[], que no estaba funcionando
  • BaseForm se incluye en $OutputForms

Versiones de soporte del paquete

  • Soporta Python 3.11
  • Soporta SymPy 1.12

1 comentarios

 
GN⁺ 2024-12-09
Opiniones de Hacker News
  • Llevo varios años siguiendo este proyecto y ha avanzado bien de forma constante. Si te interesan los sistemas de álgebra computacional de código abierto, hay muchas soluciones más maduras, desde opciones clásicas como GNU Octave o Maxima hasta alternativas modernas como SAGEmath, Symbolics.jl y sympy.
    El rango va desde bibliotecas de cálculo simbólico como GiNaC hasta IDE con todo incluido como SAGEmath, y la comunidad también es activa. Por ejemplo, diría que SAGEmath prácticamente fue pionero en la interfaz de notebooks web, que hoy derivó en las distintas formas de Jupyter.
    Personalmente me gusta el estilo tipo Lisp de Mathematica (MMA), pero lo que hace potente a MMA no es solo el núcleo, sino su enorme biblioteca. Tiene soluciones de primer nivel en la industria para temas básicos como integración simbólica, gráficos 2D/3D y métodos de elementos finitos, además de muchas áreas especializadas como la bioinformática.
    Mathics parece haber hecho un buen trabajo replicando el núcleo, pero obviamente le faltan todas esas bibliotecas. Es la misma lógica al comparar Matlab y sus muchos “toolkits” con un clon de numpy, aunque la corriente de Python ya ha llevado al mundo de numpy mucho código nuevo que no funciona en Matlab.

    • Estoy de acuerdo con lo del progreso. Este proyecto me parece un gran ejemplo de profundizar en silencio y de forma constante en algo que a uno le gusta.
      Cuando apareció por primera vez hace unos 5 años, pensé: “El motor de evaluación simbólica está realmente bien hecho; veamos qué pasa ahora”. Cada vez que en el futuro me den ganas de empezar un proyecto nuevo, debería acordarme de este caso de seguir puliendo un proyecto antiguo.
    • Del lado de Lisp, se puede entrar fácilmente a Common Lisp desde Maxima. Por rendimiento, mejor usar SBCL.
    • Puede que esté equivocado, pero no veo a Octave, Matlab y numpy en el mismo ámbito que los sistemas de álgebra computacional. Todos son lenguajes o bibliotecas centrados en el cálculo numérico, así que se usan para obtener soluciones numéricas a problemas más que expresiones simbólicas exactas.
      Son complementarios y a menudo se usan juntos. Mathematica y Mathics parecen soportar ambos paradigmas, pero no son lo mismo.
  • Parece estar basado en sympy: https://www.sympy.org/en/index.html

  • Si solo lo quieres para uso personal, Wolfram Cloud se puede usar gratis. Parece que los archivos se eliminan después de unos 30 días. Wolfram Engine también es una forma de usar Mathematica gratis desde la línea de comandos. Bueno, es mejor que nada.

    • También puedes comprar una Raspberry Pi que incluya una licencia de Mathematica.
    • Si montas WLJS sobre Wolfram Engine, se puede usar de forma bastante entretenida.
  • Aquí hay una introducción más simple a Mathics:
    https://mathics.org/

  • Por alguna razón me da la impresión de que esto terminará integrándose en SageMath :D

    • No sé si hay algún movimiento real para meter Mathics en SageMath. Si tuviera que especular, diría que como SageMath lo desarrollan principalmente matemáticos de investigación y criptógrafos, al incluir componentes el rendimiento suele ser una preocupación central.
      Una de las razones por las que SageMath es el proyecto más grande en Cython es que Cython permite a Sage aprovechar bibliotecas rápidas en C/C++.
      Mathics, por ahora, no parece preocuparse mucho por el rendimiento. Por ejemplo, basta con ejecutar un pequeño microbenchmark como "AbsoluteTiming[Sum[i, {i, 1, 100000}]]" en Mathics o leer su hoja de ruta.
      Por supuesto, eso está bien. El lenguaje de programación de Mathematica tiene muchas aplicaciones interesantes donde el rendimiento no es importante; por ejemplo, seguir cuidadosamente una operación simbólica paso a paso junto con la expresión.
      Pero la motivación principal de los desarrolladores de Sage es la investigación matemática de punta, y ahí el rendimiento casi siempre es muy importante. El rendimiento también es la razón por la que Sage no simplemente usa sympy, sino que implementa por su cuenta muchas funciones similares. sympy prioriza la facilidad de instalación y por eso puede ser relativamente lento, mientras que en SageMath la facilidad de instalación no es una prioridad en absoluto.
      La misión de SageMath es ser una alternativa viable a Mathematica, Matlab, Magma y Maple, pero eso nunca significó convertirse en un clon. Por ejemplo, no significa ejecutar código de Mathematica directamente, sino ser una alternativa que permita apoyar, sobre software matemático de código abierto, la investigación que de otro modo se haría con esos programas de código cerrado.
  • Los ingenieros de software hacen cualquier cosa con tal de no pagar el costo del software.

    • Tengo una licencia de Mathematica, pero este proyecto también me parece bastante genial. También soy ingeniero de software. Me sorprendería si los desarrolladores de Mathics no fueran usuarios de Mathematica.
    • No es cuestión de precio, sino de libertad.
    • Algunas personas crean software para sí mismas, e incluso lo publican como código abierto.
    • Antes pagué 20 dólares por un estuche de 3 DVD de Debian Sarge y un manual del tamaño de una revista.
  • Mathematica se ofrece gratis en Raspberry Pi[1], y la mayoría de las universidades tienen una licencia para todo el sitio. La licencia “Home & Hobby” tampoco es tan cara: la suscripción cuesta 195 dólares al año, la licencia perpetua 390 dólares y la renovación solo 175 dólares[2]
    Siendo honestos, si alguien tiene interés en tinkering pero no puede pagar ese precio, tampoco es difícil encontrar o instalar una versión crackeada
    Personalmente me gusta bastante Mathematica, o más precisamente “Wolfram Language”, y estoy conforme pagando la licencia para uso hobby. No solo creo que vale lo que cuesta, sino que considero que apoyar software matemático es una “buena causa” en la que vale la pena gastar dinero
    Además, es común que fotógrafos aficionados gasten en herramientas como Adobe CC más de lo que muchos programadores gastan en todas sus herramientas, y no entiendo por qué. Lo mismo pasa con quienes gastan 20 a 40 dólares o más al mes en varios servicios de suscripción, pero dudan ante una licencia de 200 a 400 dólares
    Dicho eso, en mi caso paso más tiempo en Mathematica que en casi cualquier otro programa instalado en mi computadora
    Aun así, el software matemático open source sigue teniendo un lugar importante. Aunque Mathematica en general es muy amplio, todavía tiene carencias grandes en matemáticas avanzadas
    En particular, hay dos razones por las que cuesta creer que vaya a cubrir incluso áreas más “de nicho” de las matemáticas. Primero, mientras más avanzada o esotérica es un área, el retorno de la inversión cae drásticamente. Segundo, Wolfram Language ya tiene más de 6000 funciones integradas, así que no tiene mucho sentido agregar cientos más para dar soporte exhaustivo a áreas como teoría de grupos
    Podrían soportarlo mediante paquetes, pero al no tener soporte de primera clase en el kernel hay un costo de rendimiento, y como el usuario tiene que buscarlos y usarlos deliberadamente, también hay un costo de usabilidad
    Por eso software open source como GAP, M2 y PARI/GP cumple un rol importante para cubrir los huecos de Wolfram Language. En mi caso, aporto a proyectos FOSS tanto como gasto en mi licencia de Mathematica. En proyectos donde contribuir dinero no es sencillo, intento aportar tiempo y habilidades para mejorarlos
    Sinceramente, no me interesan demasiado los proyectos que intentan replicar las funciones de Mathematica. Claro que esos proyectos seguirán desarrollándose y mejorando, y como mínimo pueden presionar a Wolfram Research para que siga mejorando las funciones básicas. Pero para que un proyecto así alcance al Mathematica/WL actual, probablemente le faltan unos 10 a 20 años
    [1]: https://www.wolfram.com/raspberry-pi/
    [2]: https://www.wolfram.com/mathematica/pricing/home-hobby/

    • Stephen Wolfram parece ser bastante odiado en HN, pero para matemática experimental, resolver acertijos, visualización rápida de datos y cosas así, Wolfram es un lenguaje profundo y hermoso
      Los notebooks integrados, la documentación al pasar el mouse y, sorprendentemente, un único espacio de nombres enorme con miles de funciones se combinan de alguna manera para ofrecer una experiencia simple y productiva distinta a cualquier otra que haya probado. Y eso que normalmente no soy muy fan de los IDE “pesados”
  • Una de las cosas molestas de Mathematica es que todas las funciones están metidas a la fuerza en el mismo espacio de nombres, y no hay sobrecarga según las distintas opciones de parametrización

    • No sé a qué te refieres con sobrecarga. Las funciones pueden comportarse de forma distinta fácilmente según la cantidad de argumentos. Por ejemplo, están Fold con 2 argumentos y Fold con 3 argumentos, y también pueden tener todas las opciones que quieras, como Graphics, Graphics3D, Solve e Import/Export
      La gran duplicación que se me ocurre son más bien las distintas funciones Plot