instruction:
In this task, you are given a paper review. Based on the review, your job is to identify language and generate "en" if the review is in English or generate "es" if the review is in Spanish. Note that URLs in the text have been replaced with [Link].
question:
Summary: The paper proposes a neural model for predicting Python syntax trees from text descriptions. Guided by the actual Python grammar, the model generates tree nodes sequentially in a depth-first fashion. Key ideas include injecting the information from the parent node as part of the LSTM input, a pointer network for copying the terminals, and unary closure which collapses chains of unary productions to reduce the tree size. The model is evaluated on three datasets from different domains and outperforms almost all previous work.  Strengths:  The paper is overall very well-written. The explanation of system is clear, and the analysis is thorough.  The system itself is a natural extension of various ideas. The most similar work include tree-based generation with parent feeding (Dong and Lapata, 2016) and various RNN-based semantic parsing with copy mechanism (Jia and Liang, 2016; Ling et al., 2016). [The guidance of parsing based on grammar is also explored in Chen Liang et al., 2016 ([Link] where a code-assist system is used to ensure that the code is valid.] Nevertheless, the model is this paper stands out as it is able to generate much longer and more complex programs than most previous work mentioned.   Weaknesses:  The evaluation is done on code accuracy (exact match) and BLEU score. These metrics (especially BLEU) might not be the best metrics for evaluating the correctness of programs. For instance, the first example in Table 5 shows that while the first two lines in boxes A and B are different, they have the same semantics. Another example is that variable names can be different. Evaluation based on what the code does (e.g., using test cases or static code analysis) would be more convincing.  Another point about evaluation: other systems (e.g., NMT baseline) may generate code with syntactic error. Would it be possible to include the result on the highest-scoring well-formed code (e.g., using beam search) that these baseline systems generate? This would give a fairer comparison since these system can choose to prune malformed code.  General Discussion:  * Lines 120-121: some approaches that use domain-specific languages were also guided by a grammar. One example is Berant and Liang, 2014, which uses a pretty limited grammar for logical forms (Table 1). In addition to comparing to that line of work, emphasizing that the grammar in this paper is much larger than most previous work would make this work stronger.  * Lines 389-397: For the parent feeding mechanism, is the child index being used? In other words, is p_t different when generating a first child versus a second child? In Seq2Tree (Dong and Lapata, 2016) the two non-terminals would have different hidden states.  * Line 373: Are the possible tokens embedded? Is it assumed that the set of possible tokens is known beforehand?  * The examples in the appendix are nice.  ---  I have read the author response.
answer:
en


question:
Abstract: Needs to have a definition of ERP - can't assume the reader knows what this means.  Intro: Avoid 1 sentence paragraphs (page 1) The introduction is rather long - it seems to actually be two different sections: an introduction (1st four paragraphs) and 1+ page of background and hypothesis. Overall - at 1.5 pages the intro is rather long for a paper that is 4 pages total.  Methodology: I think there are a lot of assumptions in regards to what ERP are and how they work.  While the paper is a statistical study, it would have benefited with a context of an actual example.  The samples are from small to medium size companies (how many?) with 49 use case (how do these relate?).  Results: Discussion is too limited - it assumes that a reader is very familiar with the area, and that may not be the case.
answer:
en


question:
El documento intenta mostrar una evaluación de atributos de calidad de software basada en el estándar ISO 9126. El documento muestra una propuesta de una plantilla con una serie de preguntas para analizar la calidad de diferentes atributos de calidad de un producto software desarrollado. Sin embargo, el documento carece de estructura. La redacción es deficiente. En algunas partes del documento no se siguen los parámetros de formato exigidos en la guía de autores. Por ejemplo, el resumen (abstract) está centrado y según la guía del evento debe estar justificado. De la misma forma se presentan algunos párrafos del documento. En cuanto a la redacción, el documento es difícil de leer, faltan o están mal ubicados los signos de puntuación. Las palabras claves no coinciden como palabras claves del artículo. Faltan referencias bibliográficas que sustenten las afirmaciones que se hacen. A pesar de que la plantilla puede ser tan útil como intentan asegurar en el trabajo, es necesario buscar una validación más consolidada que permita asegurar su utilidad. Las estadísticas presentadas carecen de justificaciones válidas y el formato de presentación es deficiente. Gran parte del documento se centra en hacer afirmaciones descritas en el estándar ISO 1926 y: 1. No se encuentra debidamente citado como referencia principal del trabajo. 2. Centrar el artículo para resumir la definición de cada característica o subcaracterística del estándar no parece muy apropiado para este tipo de trabajos. El formato de presentación de la plantilla carece de claridad. Pareciera que es un formato de cuestionario pero no se muestra como tal. Existe un listado de afirmaciones y preguntas poco claras. Algunas de dichas preguntas son mencionadas en los resultados, sin embargo no aparecen en el listado denominado por la autora como "plantila", es el caso de: ¿El sistema opera junto con otro sistema?. En términos generales el trabajo debe refinar mucho más.
answer:

es