search

gipplab / LaCASt

LaCASt - A LaTeX Translator for Computer Algebra Systems
MIT License
7 stars 1 forks source link

Split API Endpoints for generic LaTeX #204

Closed AndreG-P closed 3 years ago

AndreG-P commented 3 years ago

Split the API endpoints for generic LaTeX into the endpoints described below. The general workflow from generic latex to CAS computations would be via steps (2), (3 or 4), and (5).

Total Pipeline API

(1) Wikitext content without computations (slow)

Input: wikitext content Output: JSON array with all MOI, dependency graph, translations but NO computations Desc: Does the entire pipeline

Generic to Semantic API

(2) Wikitext Content to Dependency Graph (slow)

Input: Wikitext content Output: JSON Dependency graph with definiens Desc: First part of the process. Generates a JSON of the dependency graph including the definiens for each node.

(3) Dependency Graph to Semantic LaTeX and CAS (fast)

Input: Output of (2) Output: Semantic LaTeX and CAS representations for each node Desc: Takes the output from (2) and translates every MOI to semantic latex and CAS representations

(4) Dependency Graph and Formula to semantic LaTeX and CAS (fast)

Input: Output of (2) and formula in LaTeX Output: Semantic LaTeX and CAS representation for the given formula Desc: Same as (3) but for a single formula

Semantic to Computation API

(5) Semantic LaTeX and CAS to Computations (slow)

Input: Semantic LaTeX and CAS name (Maple or Mathematica) Output: Symbolic and Numeric Results Desc: Computations are only allowed for single formula.

physikerwelt commented 3 years ago

5) I think we already have 5, don't we? 2) I assume it is an acyclic graph. How large will the json set become? Will it be super large?

6) We would really need 4+5 so reduce the number of serial requests.

In general LGTM. Extension:MathSearch would call 2 for each document and 6 on demand

AndreG-P commented 3 years ago

  1. Only partially. There is no computation involved by now. Just the translation to cas. I thought there should be better an extra endpoint to compute expressions rather than just translating them.

  2. Yes it's acyclic and disconnected. The size directly depends on the number of math in a document. The Jacobi polynomial has 48 nodes, hence the graph is rather small. In addition every node is annotated with definitions which blow up the graph more. I think for the bessel function we almost reach MB size.

  3. Alright. I usually limit the time a CAS can use to compute the test case to 30 seconds. So you better keep that in mind.

Ps: I will try to figure out if I can restart the cas on the fly. Wenn I do my DLMF tests, Maple ignores my time limit and hangs forever sometimes. That would kill the entire backend.

AndreG-P commented 3 years ago

@physikerwelt Sorry the graph is not acyclic because there can be a directed edge in both directions between two nodes. For example, consider the formulae:

P_{n}^{(\alpha, \beta)}(x)
P_{n}^{(\alpha, \beta)}(y)
P_{n}^{(\alpha, \beta)}(z)

Since all MOI exist in the document and they are not equal, we have three nodes in total. Every node depends on each other.

I know it would make sense to merge all three MOI to just one node. But in this case, a single node in the graph could represent multiple MOI in a document, which is no longer practical.

AndreG-P commented 3 years ago

Alright. Done with c586675

It's not implemented within vmext-demo. But that shall be a different issue.