On Tuesday, August 13, 2019 at 8:59:23 AM UTC+2, Aaron Meurer wrote: > > On Mon, Aug 12, 2019 at 8:39 PM Ondřej Čertík <ond...@certik.us > <javascript:>> wrote: > > > > > > > > On Mon, Aug 12, 2019, at 7:47 PM, Aaron Meurer wrote: > > > A possible middle ground would be to print the definition as a SymPy > > > expression. The docstrings in the ODE module use the ODE module to > > > pretty print the general solution > > > https://docs.sympy.org/latest/modules/solvers/ode.html > (unfortunately, > > > using the ASCII pretty printer, we could potentially use Unicode if we > > > fix https://github.com/sympy/sympy/issues/15700. > > > > > > It doesn't apply to every function. Some formulas aren't expressible > > > in SymPy. I think a good middle ground would be to show the LaTeX, so > > > that it looks nice in the HTML, but also pretty print the formula in a > > > doctest so that it is readable in plain text (and also you get the > > > SymPy code for the definition formula). The only downside is that the > > > information becomes duplicated. > > > > > > Another idea, I don't know how hard it would be, or how confusing the > > > output would be to people reading the page, would be to have a special > > > pretty print function that shows the pprint() output in the docstring > > > itself, but the Sphinx build would replace that with a LaTeX > > > representation. > > > > We can port all missing features from Fungrim into SymPy, so that we can > use SymPy itself to represent any math. There are a few things that can't > be represented by SymPy naturally: > > > > * such as "x+x". > > * order of terms "x*y" vs "y*x", the same with "x+y" vs "y+x" > > > > That is a fundamental design choice, needed for performance (even more > so in SymEngine). Besides those, I don't know if there is some other > obstacle to represent all the things from Fulgrim. When looking at the > formulas that we need to represent, I don't think we ever need things like > "x+x", but it would be useful to preserve the order of terms. > > > > I don't know if there are other semantic differences between SymPy and > Fungrim. Fredrik, do you know if there are other issues? > Apart from specific objects and functions that don't have definitions yet, nothing major as far as I know. There are probably differences in special values and the like; for example, log(0) is zoo in SymPy but it is (tentatively) -Infinity in Fungrim.
Here are some concrete limitations of the Fungrim formula language for writing semantic math right now: * No formalization of variable-length tuples, variable-size matrices etc * No formalization of functions (as mathematical objects, as opposed to just their defining expressions) and function spaces * No formalization of formal variables (e.g. x as a formal generator of R[x], as opposed to a variable x representing an unknown value) * No formalization of abstract algebraic structures * The constructions for defining bound variables are not yet fully defined / consistent / unambiguous, making fully automatic semantic parsing problematic Not all function definitions can be represented in SymPy. For instance > the Meijer G-function is defined by a path integral > ( > https://docs.sympy.org/latest/modules/functions/special.html#sympy.functions.special.hyper.meijerg), > > > and there's no way to make an Integral object in SymPy that is over a > path L. I don't know if the G-function is in fungrim. Fungrim seems to > be lacking a search functionality. > You can search the git repository, and http://fungrim.org/definitions.html currently has a list of symbols (though not every implemented symbol has been defined there yet). Indeed, the Meijer G-function does not have a symbol yet. Paths and integrals over paths are also on the todo list! At any rate, this all seems out of scope for Lauren's project. I think > we should decide on something that we can do now for our docstring > standard. If we later decide that something like fungrim can replace > it, and we have the tooling written, we can change the standard. > +1 However, there is some potential for collaboration already, related to this issue. One of the (many) reasons for creating Fungrim was that I find it cumbersome to put a lot of math in the documentation for mpmath and Arb; putting in links to Fungrim is an alternative. Here is an example: I recently put the Coulomb wave functions in Arb, and on http://arblib.org/acb_hypgeom.html#coulomb-wave-functions I just link to the page in Fungrim instead of giving all the formulas in the Arb documentation. In the source code https://github.com/fredrik-johansson/arb/blob/master/acb_hypgeom/coulomb.c https://github.com/fredrik-johansson/arb/blob/master/acb_hypgeom/coulomb_jet.c I put in comments referencing the formula in Fungrim that is used in each case. What I would like to do is to replace more of the existing formula-heavy documentation in mpmath and Arb with Fungrim links, as soon the content exists in Fungrim. Perhaps this would make sense for the SymPy documentation too. Fredrik -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/bfcadcbc-c87e-4786-98d3-f72e3e55e4ba%40googlegroups.com.
