gipplab / 19ajimtranslator Goto Github PK

Rev 1:

As for the PoM-tree parser. The author also mentions that the algorithm 1 is not complete feasible for command with argument. Then why bothering mention it?

@AndreG-P @physikerwelt

When the term appropriate is used later in the paper, italics are sometimes used. I think that the italics need only be used when the term is being introduced, and not later. Perhaps the later italics should be removed. Either that or it should be made sure to be used consistently throughout the paper.

Can you check this Andre?

Delete front page, German abstract, etc. and apply the general template form.

I this paper the words "get" and "look" and "like" and "seems" and "yet" are used sometimes. These are informal words, unless used in a precisely defined way. Can you search throughout and find better words as necessary?

Reviewer 1:

Though the section 4 is named as “The translator”, there is no overview of the whole system.

Hi @physikerwelt @AndreG-P

I need more time to look at things. At least 24 hours, maybe more.

I'll let you know on this thread when I am finished checking things, and when I have updates.

Reviewer 1 said:

Section 3 gives a good summarization of the possible problems during the translation, including undefined function, alteration and branch cuts, insufficient semantic label, ambiguity for the tokenization and structure analysis. However, it would be easier for reader to quickly capture these ideas if they are organized in subsections.

The official author guidelines said about headings:

Headings must be concise, with a clear indication of the distinction between the hierarchy of headings. The preferred format is for first level headings to be presented in bold format and subsequent sub-headings to be presented in medium italics.

on p.25, there is ${\mathbb N}_0$ It should be defined, something like

${\mathbb N}_0:={0,1,2,\ldots}$

(unless I missed the definition somewhere else).

In the abstract, insert "Bruce Miller" @ NIST in "Approach"

@physikerwelt @AndreG-P Look at our CICM papers. It should be something like this:

Miller, B.R.: LaTeXML: A LaTeX to XML/HTML/MathML Converter. http://dlmf.nist.gov/LaTeXML/. Accessed June 2018

or something like that. Look at his page.

@AndreG-P @physikerwelt

In this paper, CAS and CASs are introduced. However, it seems to me that they are used interchangably throughout the paper, which perhaps is not good.

I reccomend we use CAS to represent both singular and plural and get rid of CASs.

What do you think?

Otherwise, we need to go through the entire file and change all cases where CAS really represents plural.

@physikerwelt @AndreG-P

In the current title, it states "Representations of Special Functions".

This seems a bit strange.

Don't you mean "Expressions involving Special Functions" ?

"Representaitons of Special Functions" implies that you are just dealing with the special functions themselves and not expressions involving them, which you are.

Currently, it is about 33k words (limit is 10k).

Both reviews mentioned some flaws in the structure.
Rev 1:

This paper illustrates the challenges of the parsing with lots of examples. The organization of example by example, without a smooth transition or clear outline/organization of the example make it very hard to capture the main idea and the main contribution of this paper. Related is the writing style of this paper. For example, in the section 5.2, the first two paragraph are about the detail of conditions that this system might failed and some fix to improve it. The pseudo code is given after the too detailed discussion. On the other hand, the algorithm 3 is very important, but the author did not give enough explanation to it.

Rev 2:

The paper therefore is a mixture of (relatively subtle) parsing technology (largely sections 4,5), and a significant amount of mathematics, and the transitions are not always obvious. Might it be worth putting one (my preference would be the parsing) in an appendix? There is also a certain amount of Maple hacking (6.1) which is not very helpful to the reader who doesn't know Maple, and should probably be placed in an Appendix.

Maybe an Appendix suggested by Rev2 would be helpful? Let's say for Table 6, some Algorithms, MathML (see #8)?

But generally I think we should not change the structure too much after the reviewing process?

In #5 we will include subsections also. This, an Appendix, and a paragraph for a better overview (e.g. in #4) might solve this issue?

@HowardCohl @physikerwelt
One reviewer pointed out that

The paper is not as precise as it could be. [...] The key point is that there are several different concepts of equivalent. [...] In general, there is not enough discussion of the removable singularities issue.

He said that the translations (6), (7), and (8) based on different concepts of equivalence. I have rewritten this paragraph and cited the Corless et al. paper. The translations (7) and (8) are adapted from (23) and (25) in Corless et al.

However, how can we respond to the reviewer now?
I would say, that we think the audience of this Journal are rather mathematicians but computer scientists. Thus we decided to introduce the wordings appropriate and unappropriate translations rather than handling different equivalence concepts. We hope that this decision helps the reader to focus on the problems of translations.

In the last section, it is stated:

An extensive weakness is the dependency on the special macros from the DLMF. The translator is not able to translate functions without using these macros. Currently, we are working on mathematical information retrieval techniques which will allow for an extension of the translator to generic LaTeX inputs.

I do not see this as a weakness. I like the last sentence of this paragraph, but the rest is not good. It needs to be repaired, or explained more clearly. Even with a generic to semantic converter, one still relies on the
semantic macros, or something needs to be explained better.

Reviewer 1:

Another related work on the semantic understanding of mathematical express are the Miller’s LaTeXML, it’s worth to compare the current translation system with the LaTeXML. The LaTeXML have mathematical grammar build in and could export the ME as content mathML, which could be imported into the Mathematica as far as I know.

and

The three evaluation criteria designed are smart to make use of large amount of un-annotated dataset. As for the comparison with existing system, it is highly desired to compare the current system with the LaTeXML.

I think we can simply add a MathML example for \JacobiP{\alpha}{\beta}{n}@{x} in the appendix. It should show the output for content MathML when exporting the function in Maple and Mathematica and use LaTeXML (see examples below).

We can than argue, that we give the PoM-Tagger a favour, because

• of the lexicon files that contain many semantic information that help to disambiguate expressions
• the final goal of the PoM-Tagger is a parser that disambiguates latex expressions
• based on previous experiences (texvc) the PoM-Tagger seemed to be the more flexible solution (and for LaTeXML the more simple / less complex solution)

@physikerwelt could you add the output from Mathematica? It should be this function:
ExportString[JacobiP[n,\[Alpha],\[Beta],x], "MathML", "Presentation" -> False, "Content" -> True]

Via LaTeXML latexmlc ...

<math xmlns="http://www.w3.org/1998/Math/MathML" id="p1.1.m1" class="ltx_Math" alttext="P^{(\alpha,\beta)}_{n}\left(x\right)" display="inline">
  <semantics>
    <apply>
      <apply>
        <csymbol cd="dlmf">Jacobi-polynomial-P</csymbol>
        <ci>𝛼</ci>
        <ci>𝛽</ci>
        <ci>𝑛</ci>
      </apply>
      <ci>𝑥</ci>
    </apply>
  </semantics>
</math>

Via Maple MathML[ExportContent](JacobiP(n, alpha, beta, x))

<math xmlns='http://www.w3.org/1998/Math/MathML'>
  <apply id='id6'>
    <csymbol id='id1' definitionURL='http://www.maplesoft.com/MathML/JacobiP'>JacobiP</csymbol>
    <ci id='id2'>n</ci>
    <ci id='id3'>alpha</ci>
    <ci id='id4'>beta</ci>
    <ci id='id5'>x</ci>
  </apply>
</math>

Via Mathematica ExportString[JacobiP[n,\[Alpha],\[Beta],x], "MathML", "Presentation" -> False, "Content" -> True]
TODO

It seems that the word equivalence, equivalent, etc., is used in many places in the paper. I thought we were not going to use this word. If you are to use it, then you need to define what you mean specifically by equivalent.

I have inserted a bunch of [HSC: ...] comments in the text of the paper.

Please have a look at these, solve the issue, and then remove them.

Please find and remove (or merge) any one sentence paragraphs (such as that which occurs at the end of the paper). This is bad form. Paragraphs should be at least two (or prefereably more) sentences.

@AndreG-P @physikerwelt

Currently it states:

DLMF. NIST Digital Library of Mathematical Functions. Release 1.0.19 of 2018-06-22. F. W. J.
Olver, A. B. Olde Daalhuis, D. W. Lozier, B. I. Schneider, R. F. Boisvert, C. W. Clark, B. R.
Miller and B. V. Saunders, editors. url: http://dlmf.nist.gov/.

It should now point to Release 1.0.20 of 2018-09-15

@AndreG-P @physikerwelt

I just pushed a new version of ReviewerReposnse.txt. I tried to improve the readability of the text. I also added several comments labeled as "HSC" which need to be addressed.

Please read what I wrote carefully to make sure I did not change the meaning or correctness of the response.

As for the comparison with existing system, it is highly desired to compare the current system with the LaTeXML.

I think this would go beyond the scope since the LaTeXML approach is not straight forward either (see #8 - Why not use LaTeXML)

• Readers might be very interesting to understand how the lexicon is related with the PoM.
• Table 1. It is worth explaining what the @ symbols in the semantic \LaTeX are doing (encoding function application, as juxtaposition is desperately overloaded in Mathematics).

I noticed that "then" and "then" are used incorrectly.

One says, "If so and so, then such and such"

Not, "If so and so, than such and such".

For instance in the second sentence of Section 6, and just before (17), it is incorrect.

"Rather than" is correct.

@AndreG-P @physikerwelt

For some reason there seems to be a "wrap" for missing something here, which needs to be fixed.

Rev 2:

The paper is not as precise as it could be: see my detailed comment on 6/35. The key point is that there are several different concepts of 'equivalent'.
There is =_{DA} --- has equivalent definitions in terms of differential algebra.
There's =_{LC} --- equality up to a local constant. In the case of functions defined by integrals (but essentially only then) the first two are equivalent.
Then there's =_{\C\rightarrow\C} --- equality as functions on complex numbers.
A slight variant is =^*_{\C\rightarrow\C} --- equality as functions on complex numbers except for removable singularities.
Then the key point on page 6 is that (6) is =_{LC} and (7) and (8) are =^*_{\C\rightarrow\C} (where the singularities happen to be in different places). In general, there is not enough discussion of the removable singularities issue.

Detailed comment on 6/35 is:

Page 6 numbered 35 "Alternative but mathematically equivalent translations", but then you say they are not mathematically equivalent. Probably better say "Apparently mathematically equivalent translations". This is particularly off since at the bottom of page 3 the authors say that they will not use the term equivalent.

I think he is talking about page 6 translations (6), (7), and (8). We introduce the terminology of appropriate and inappropriate translation (bottom of page 3) just to avoid those equivalence problems... I guess, when I call the translations (6), (7), and (8) as "apparently appropriate", this should solve the problem...

@HowardCohl what do you think?

@AndreG-P

Is the paper resubmitted?

@AndreG-P @physikerwelt

The phrase "in consequence," is used 6 times in the text. I personally don't like this language, and rarely see this written.

Please remove it if it is not absolutely necessary.

Otherwise use "therefore" "in summary" "Hence" (only at start of a sentence), etc.

Reviewer 1:

There are two major sections discussing 1) the enhancement of CAS, 2) the enhancement of semantic tag, to resolve ambiguity. The conversion from LaTex to parsing tree is only mentioned very briefly in this section. While in the Youssef paper, there is not too much description of the parsing system either. It would be very valuable describe how the LL parser is constructed. How the grammar is related with the lexicon entries.

and

Readers might be very interesting to understand how the lexicon is related with the PoM.