Mathics 7.0 – alternativa open source ao Mathematica

 (github.com/Mathics3)
4 pontos por GN⁺ 2024-12-09 | 1 comentários | Compartilhar no WhatsApp
  • O Mathics Core 7.0.0 reorganiza o motor principal do sistema de computação open source compatível com o Mathematica e prepara a base para o futuro carregamento preguiçoso de funções internas
  • Novas funções internas, como ComplexExpand, ConjugateTranspose e LeviCivitaTensor, adicionam recursos relacionados a expressões, álgebra linear e identificação de valores reais
  • Lacunas de compatibilidade existentes foram preenchidas, incluindo Range[], DirectedInfinity, Indeterminate, exibição de erros em Graphics e alteração de $CharacterEncoding
  • O carregamento de funções internas deixa de depender de imports implícitos e passa a chamar explicitamente import_and_load_builtins()
  • Inclui suporte a Python 3.11 e SymPy 1.12, além de correções relacionadas a Quantity, SparseArray, Derivative, Exit[] e BaseForm

Direção da release e reorganização interna

  • O Mathics Core 7.0.0 inclui uma reorganização da estrutura interna para dar suporte, no futuro, ao carregamento preguiçoso de funções internas
  • O código e o estilo em Python foram modernizados, mais anotações de tipo foram adicionadas e vários erros de ortografia foram corrigidos
  • As dependências de SymPy e Python foram atualizadas para versões mais recentes
  • Também foi realizado trabalho para acelerar o carregamento inicial e reduzir o uso inicial de memória

Novas funções internas

  • As funções internas adicionadas nesta release são as seguintes
    • $MaxLengthIntStringConversion
    • Elements
    • ComplexExpand
    • ConjugateTranspose
    • LeviCivitaTensor
    • RealAbs, RealSign
    • RealValuedNumberQ

Melhorias na documentação e na geração de testes

  • Vários problemas de formatação na documentação em PDF foram corrigidos
    • O espaçamento entre números de seção foi aumentado no sumário de capítulos e seções
    • As margens ao redor das definições de funções internas foram aumentadas
    • Erros de ortografia em toda a documentação foram revisados
  • O código de execução de doctests e de geração de documentação LaTeX foi revisado e refatorado
    • Permite atualizações incrementais de funções internas
    • Foi reorganizado para reduzir código duplicado
  • Em “Expression Structure”, foi adicionada a nova seção Section Head-Related Operations
  • O título do PDF mudou de Mathics para Mathics3, e o texto introdutório também foi atualizado
  • Doctests antigos, ocultos e sem finalidade educativa, foram convertidos para pytest

Compatibilidade e mudanças de comportamento visíveis ao usuário

  • *Plot não exibe mensagens durante a avaliação
  • Range[] passa a lidar com di negativo
    • PR relacionado: #951
  • O suporte a DirectedInfinity e Indeterminate foi aprimorado
  • Graphics e Graphics3D são exibidos com fundo rosa quando contêm um primitive ou uma directive inválidos
    • Na interface Mathics-Django, também é exibida uma mensagem de erro em tooltip
  • $CharacterEncoding pode ter seu valor alterado dentro da sessão

Implementação interna e mudanças de API

  • Em Abs e Sign, eval_abs e eval_sign foram separados e adicionados a mathics.eval.arithmetic
  • O número máximo de dígitos permitido em uma string foi definido como 7000
    • Em ambientes como pyston, nos quais o Python não ajusta isso automaticamente, é possível ajustar com a variável de ambiente MATHICS_MAX_STR_DIGITS
  • A implementação de comparação de reais passa a entrar internamente na implementação de RealSign
  • No Python 3.11, $MaxLengthIntStringConversion controla o tamanho máximo de conversões literais entre inteiros grandes e strings
  • O carregamento de código interno deixou de ser implícito e passou a ser feito por instrução explícita
    • A mudança prepara o caminho para o carregamento preguiçoso de funções internas ou para um “autoload” no estilo do GNU Emacs
  • Na nova API, é preciso chamar explicitamente import_and_load_builtins()
    • Antes, o momento de carregamento das funções internas era implícito e indefinido, dependendo da ordem dos imports
  • Foi adicionado cache LRU ao mpmath

Correções de bugs em Quantity, SparseArray e outros

  • Definitions agora é compatível com pickle
  • O suporte a expressões Quantity foi aprimorado
    • Inclui conversão, formatação e operações aritméticas
  • A opção Background de Graphics e Graphics3D voltou a funcionar
  • Foi corrigido um problema de comparação numérica em expressões contendo String
    • Issue relacionada: #797
  • Foi corrigido um problema de Switch[] contendo Infinity
    • Issue relacionada: #956
  • Foi corrigido um problema de Outer[] com SparseArray
    • Issue relacionada: #939
  • ArrayQ[] passa a detectar SparseArray
    • PR relacionado: #947
  • A exceção BoxExpressionError agora é tratada
  • Foi corrigido o comportamento de Derivative ao avaliar True, False e List[]
  • Inclui correções no pacote Combinatorica
  • O Exit[], que não funcionava, foi corrigido
  • BaseForm foi incluído em $OutputForms

Versões de pacotes suportadas

  • Suporta Python 3.11
  • Suporta SymPy 1.12

Leituras relacionadas

1 comentários

 
GN⁺ 2024-12-09
Opiniões no Hacker News

  • Acompanho este projeto há alguns anos e ele vem evoluindo bem de forma constante. Se você se interessa por sistemas de álgebra computacional open source, há muitas soluções mais maduras, desde opções clássicas como GNU Octave ou Maxima até opções modernas como SAGEmath, Symbolics.jl e sympy
    O espectro vai de bibliotecas de computação simbólica como GiNaC até IDEs com tudo incluído, como SAGEmath, e as comunidades são ativas. Por exemplo, acho que o SAGEmath praticamente desbravou a interface de notebooks na web, que acabou levando às várias formas de Jupyter de hoje
    Pessoalmente, gosto do estilo meio Lisp do Mathematica (MMA), mas o que torna o MMA poderoso não é apenas o núcleo, e sim sua enorme biblioteca. Em temas básicos como integração simbólica, gráficos 2D/3D e método dos elementos finitos, há soluções de nível líder do setor, além de muitos domínios especializados, como bioinformática
    O Mathics parece ter feito um bom trabalho ao replicar o núcleo, mas naturalmente faltam todas essas bibliotecas. A mesma lógica vale ao comparar Matlab e seus vários “toolkits” com clones de numpy, embora o fluxo do Python agora tenha trazido para o mundo numpy muito código novo que não roda no Matlab

    • Concordo com o comentário sobre o progresso. Este projeto parece um ótimo exemplo de seguir trabalhando em silêncio e com constância em algo de que se gosta
      Quando apareceu pela primeira vez, uns 5 anos atrás, pensei: “o motor de avaliação simbólica ficou muito bem feito; agora vamos ver no que dá”. Sempre que eu tiver vontade de começar um projeto novo daqui para frente, vou tentar lembrar deste exemplo de continuar refinando um projeto antigo
    • Pelo lado de Lisp, dá para entrar facilmente em Common Lisp a partir do Maxima. Melhor ainda se usar SBCL por causa do desempenho
    • Posso estar enganado, mas não vejo Octave, Matlab e numpy como pertencentes à mesma área de sistemas de álgebra computacional. Todos eles são linguagens ou bibliotecas voltadas a computação numérica, usadas para encontrar soluções numéricas de problemas, mais do que expressões simbólicas exatas
      Eles são complementares e muitas vezes usados em conjunto. Mathematica e Mathics parecem dar suporte aos dois paradigmas, mas não são a mesma coisa

  • Parece ser baseado em sympy: https://www.sympy.org/en/index.html

  • Se você só quer para uso pessoal, o Wolfram Cloud pode ser usado de graça. Parece que os arquivos são apagados depois de uns 30 dias. O Wolfram Engine também é uma forma gratuita de usar Mathematica pela linha de comando. Bem, é melhor do que nada

    • Também dá para comprar um Raspberry Pi que inclui uma licença do Mathematica
    • Colocar WLJS em cima do Wolfram Engine deixa o uso bem divertido

  • Há uma introdução mais simples ao Mathics aqui:
    https://mathics.org/

  • Por algum motivo, tenho a impressão de que isso vai acabar sendo integrado ao SageMath :D

    • Não sei de nenhum movimento real para colocar o Mathics no SageMath. Se eu tivesse que especular, diria que é porque o SageMath é desenvolvido principalmente por matemáticos pesquisadores e criptógrafos, então desempenho costuma ser uma preocupação central ao incluir componentes
      Um dos motivos de o SageMath ser o maior projeto em Cython é justamente que o Cython permite ao Sage aproveitar bibliotecas C/C++ rápidas
      O Mathics atualmente não parece se preocupar seriamente com desempenho. Por exemplo, basta rodar um pequeno microbenchmark no Mathics como "AbsoluteTiming[Sum[i, {i, 1, 100000}]]" ou ler o roadmap
      Claro, isso não tem problema. A linguagem de programação do Mathematica tem muitos usos interessantes em que desempenho não é importante, como acompanhar cuidadosamente, passo a passo, alguma manipulação simbólica junto com a expressão
      Mas a principal motivação dos desenvolvedores do Sage é matemática de pesquisa de ponta, e nela o desempenho quase sempre é muito importante. Desempenho também é a razão pela qual o Sage implementa diretamente muitas funcionalidades parecidas em vez de simplesmente usar sympy. O sympy prioriza facilidade de instalação e, por isso, pode ser relativamente lento; no SageMath, facilidade de instalação não é prioridade nenhuma
      A missão do SageMath é ser uma alternativa viável ao Mathematica, Matlab, Magma e Maple, mas isso nunca significou ser um clone. Por exemplo, não quer dizer executar código do Mathematica diretamente, e sim oferecer uma alternativa capaz de apoiar, sobre software matemático open source, pesquisas que de outra forma seriam feitas nesses programas de código fechado

  • Engenheiros de software fazem qualquer coisa para não pagar custos de software

    • Tenho uma licença do Mathematica, mas também acho este projeto bem legal. Também sou engenheiro de software. Eu ficaria até surpreso se os desenvolvedores do Mathics não fossem usuários do Mathematica
    • Não é uma questão de preço, é uma questão de liberdade
    • Algumas pessoas criam software para si mesmas e até o publicam como open source
    • Antigamente paguei 20 dólares por uma caixa com 3 DVDs do Debian Sarge e um manual do tamanho de uma revista

  • O Mathematica é oferecido gratuitamente no Raspberry Pi[1], e a maioria das universidades tem licença para todo o campus. A licença “Home & Hobby” também não é tão cara: a assinatura custa US$ 195 por ano, a licença perpétua custa US$ 390, e a renovação sai por apenas US$ 175[2]
    Sinceramente, se alguém tem interesse em tinkering, mas não consegue bancar esse preço, também não é difícil encontrar ou instalar uma versão crackeada
    Pessoalmente, gosto bastante do Mathematica — mais precisamente da “Wolfram Language” — e fico satisfeito em pagar pela licença para uso como hobby. Não só acho que vale o dinheiro, como também vejo apoiar software matemático como uma “boa causa” digna de receber meu dinheiro
    Além disso, é comum fotógrafos amadores gastarem com ferramentas como o Adobe CC mais do que muitos programadores gastam com todo o seu conjunto de ferramentas, e não entendo por quê. O mesmo vale para hesitar diante de uma licença de US$ 200–400 enquanto se gasta US$ 20–40 ou mais por mês em vários serviços de assinatura
    No meu caso, porém, passo mais tempo no Mathematica do que em praticamente qualquer outro programa instalado no meu computador
    Ainda assim, software matemático open source continua tendo um papel importante. O Mathematica é, em geral, abrangente, mas ainda tem grandes lacunas em matemática avançada
    Em especial, há dois motivos para ser difícil acreditar que ele vá atender até as áreas mais “de nicho” da matemática. Primeiro, quanto mais avançada ou obscura é a área, mais o retorno sobre o investimento cai drasticamente. Segundo, a Wolfram Language já tem mais de 6.000 funções embutidas, então não faz muito sentido acrescentar mais centenas delas para oferecer suporte abrangente a áreas como teoria dos grupos
    Isso poderia ser suportado por pacotes, mas, sem suporte de primeira classe no kernel, há um custo de desempenho; e, como o usuário precisa ir atrás deles deliberadamente, também há um custo de usabilidade
    Por isso, softwares open source como GAP, M2 e PARI/GP têm um papel importante em preencher as lacunas da Wolfram Language. No meu caso, contribuo para projetos FOSS tanto quanto gasto com a licença do Mathematica. Em projetos nos quais contribuir financeiramente não é simples, tento ajudar a melhorá-los com tempo e conhecimento técnico
    Sinceramente, não tenho muito interesse em projetos que tentam replicar os recursos do Mathematica. Claro que esses projetos continuarão sendo desenvolvidos e melhorados e, no mínimo, podem pressionar a Wolfram Research a continuar melhorando os recursos básicos. Mas, para um projeto desses alcançar o Mathematica/WL de hoje, provavelmente levaria uns 10 a 20 anos
    [1]: https://www.wolfram.com/raspberry-pi/
    [2]: https://www.wolfram.com/mathematica/pricing/home-hobby/

    • Stephen Wolfram parece ser bastante odiado no HN, mas, para matemática experimental, resolver quebra-cabeças e visualização rápida de dados, o Wolfram é uma linguagem profunda e bonita
      O notebook integrado, a documentação por mouse over e, surpreendentemente, um único namespace gigantesco com milhares de funções se combinam, de alguma forma, para oferecer uma experiência simples e produtiva diferente de tudo que já usei. E isso mesmo eu normalmente não sendo fã de IDEs “pesadas”

  • Uma das coisas irritantes no Mathematica é que todas as funções são enfiadas no mesmo namespace, e não há sobrecarga conforme diferentes opções de parametrização

    • Não sei o que você quer dizer com sobrecarga. Funções podem facilmente se comportar de maneiras diferentes dependendo do número de argumentos. Por exemplo, há o Fold com 2 argumentos e o Fold com 3 argumentos; e elas também podem ter quantas opções quiserem, como Graphics, Graphics3D, Solve e Import/Export
      A grande duplicação que me vem à mente é mais a das várias funções Plot