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:
- Propuesta innovadora de aplicación de una metodología de ingeniería industrial, al campo de ingeniería de requisitos.  - No presenta unificación de términos a lo largo del documento, relacionado con la fase de ingeniería de requisitos: ‘educción’, ‘elicitación'... Debe utilizarse siempre el mismo término. - No se evidencia cómo se cuantifica las ‘mejoras’ graduales del proceso de educción, y la ‘mejoría’ en la calidad de la documentación.. cómo miden esa mejora?? - Hay errores de redacción y ortográficos, particularmente en el uso del acento (tildes) y de signos de puntuación (uso de la coma y punto y coma).  El artículo propone la utilización de una filosofía de trabajo de otra área de ingeniería, para mejorar los niveles de calidad de los documentos de requisitos generados en un proceso de educción de requisitos.  Considero que desde el punto de vista técnico sería importante que sustentaran el análisis de resultados que plantean en una medición o comparación cuantificada, que permita por medio de un método más formal que el descriptivo generar las conclusiones de 'mejora' en la calidad de los productos asociados al proceso de ingeniería de requisitos.  No se evidencia cómo llegan a las conclusiones generadas, en qué se basan para decir que es mejor o no, en que tiene menos errores o no ??  Es una propuesta interesante que puede ser aplicado en casos reales de procesos de ingeniería de requisitos. Actualmente aporta a disminuir la crisis asociada a esta fase de desarrollo de productos software.  La organización del documento se puede mejorar considerablemente. Considero que dedican gran parte del artículo a expresar el marco conceptual asociado, y menos a la aplicación de la técnica en el caso de estudio y al análisis de resultados, apartados en los que se puede sustentar más la propuesta presentada. Así mismo, hay errores ortográficos y de redacción que, si se evitan, pueden darle mayor valor a la presentación del artículo.
answer:
es


question:
The primary point made by this paper is that given certain architectural characteristics of multi-GPU systems, namely the use of bi-directional PCI-E for communication and the integration of two independent DMA engines on recent GPU devices (providing support for simultaneous independent communications), and given the characteristics of the communications patterns required by synchronous SGD trainers for deep neural networks, namely that the messages are large, dense, and have a fixed length, it makes sense to design communication collectives such as broadcast, reduce, and allreduce specifically for the use case of synchronous SGD training on a multi-GPU system.  The paper describes the implementation of these three collectives (broadcast, reduce, and allreduce) using a linear pipelining (LP) scheme on a (logical) ring topology.  The paper compares the LP collectives to two alternatives:  collectives based on a minimal spanning tree (MST) topology and collectives based on bidirectional exchange (BE).  First, a theoretical comparison is made using a standard cost model used in the high performance computing community.  When assumptions based on multi-GPU system architecture (very low latency for messages) and on the communication characteristics of synchronous SGD training (very large messages) are integrated into the model, the paper finds that the LP collectives should be less costly than BE collectives by a factor of 2 and less costly than MST collectives by a factor of log(p), where p is the number of GPUs being used.  Second, an empirical comparison is performed in which (1) the time required to perform each of the different collectives on a 4-device (k40m) system is measured as a function of message size and (2) the time required to perform each of the different collectives with a 200 MB message length is measured as a function of the number of devices in the system.  These measurements show that the LP-based collectives are consistently the fastest.  Third, DNN training experiments with AlexNet and GoogLeNet are performed on a 4-device system using three different synchronous SGD algorithms with the different implementations of the collectives (a total of 6 different algorithms in all).  Measurements of the communication and computation costs show that the LP collectives reduce communication costs without affecting computation costs (as expected).  Measurements of the convergence of the training loss as a function of time for the two DNN architectures show that use of the LP collectives leads to faster training.  While the theory says that the costs of LP collectives should be invariant to the number of devices in a multi-GPU system, the empirical work shows that in practice this does not hold going from 4 to 5 devices (in the tested configuration) because in a 5-device system messages must traverse the QPI.  Are there other practical considerations that the authors are aware of that affect the scaling of the LP collectives?  If so, these should be mentioned in the paper.  In the sentence "Worringen (2003) proposed a pipeline collective model in shared memory environment for CPU data, but communications of different MPI processes sharing the same CPU memory bus within the same CPU socket." I really can't figure out what the words after "but communications of different MPI processes" are trying to convey.  This sentence is not comprehensible.  "Please note the latency term is log pα, which is the smallest among algorithms in Table.1. Therefore, MST only suits for high frequent short messages."  The claim that MST collectives are only suitable for high-frequency, short messages does not follow from the statement that MST collectives have the smallest latency term.  You also need to consider the way the cost scales with message size (the bandwidth term).  If the MST collectives had a better bandwidth term than the other collectives, then they would also be superior for large messages.  "Let’s take an appropriate block size b to ensure n/b ≪ α."  This looks wrong, since n > b.  Should it be b/n ≪ α?  "However, the parameters are not consistent after several iterations due to the precision issues of float multiplications in Gradient Update."  Are you sure the inconsistency in weight estimates across devices is due to multiplication?  I would expect that it would be due to gradients being accumulated in different orders; that is, because floating point addition is not commutative.  I recommend replacing the term "sub-gradients" in this paper with "partial gradients."  In the optimization literature, the term "sub-gradient" has a very specific meaning that differs from this paper's use of the term (see
answer:
en


question:
Es una buena aplicación, que usa los recursos de desarrollo disponibles para tecnologías móviles.. El valor que tiene es su clara presentación y explicación de las herramientas que utiliza hasta este instante. Se encuentra aún en fase de desarrollo, porque presenta servicios ya bastante explotados, por ejemplo, podría asistir al usuario en buscar rutas óptimas para llegar al estacionamiento u otras factibles donde ya hay herramientas que pueden servir para brindar otros servicios. Lo novedoso  al parecer es  el uso en tecnología móvil para ambos sistemas operativos IOS y Android.   Debe corregir lo siguiente:  Página 1	resumen	Usa paper para describir el trabajo. No define nemotécnicos, ejemplo, GPS.  Página 1	introducción	No referencia la figura 1 y no la explica  Página 1 y 2	Trabajos previos	No analiza literatura especializada  y realiza una tabla comparativa de las aplicaciones.. esto debería ser parte de un análisis comparativo de su aplicación con las existentes..  Página 2 Fuera de formato la referencia, en Ingeniare no se permite conferenciar con et al., o su equivalente y otros  Página 3 Sin referencia Las figuras 3 y 4, tampoco son referenciadas en el texto  Página 4 y 5 	Figuras sin referencias	Figuras 5, 6  y 7 tampoco son referenciadas
answer:

es