On Tue, Aug 13, 2019, at 8:32 AM, Fredrik Johansson wrote:
> 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> 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


So for SymPy documentation, I am now thinking we should just use SymPy to 
represent all the equations (and add all missing functionality that's needed to 
do that), I think that can be more readable than LaTeX (what do you think 
Jason?), and we can still write tooling to convert it to nice equations online.

> > 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.

A few suggestions:

* You should enable https on the website and use https in the source code.
* how do you generate the text math, e.g., the second line in:

        /* http://fungrim.org/entry/07a654/ */
        /* F''/2 = q F,   q = (2eta/z + l(l+1)/z^2 - 1)/2 */

the website itself might be able to give such text in many cases.

Ondrej

-- 
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/535fb8c0-f188-44ea-a4fa-60d683b14a45%40www.fastmail.com.

Reply via email to