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

[EX Q]: El documento describe un trabajo exploratorio en el desarrollo de una aplicación software en el área de informática médica, concretamente en los sistemas HIS (Hospital Information System). La propuesta es interesante pero el documento denota que es un trabajo insipiente, o se entiende esto, dado que se describe la arquitectura propuesta y la metodología del proyecto, pero no se describe un escenario de prueba o un caso concreto de validación. Igualmente, no se observa en el documento la descripción de un software resultado del proyecto, y por el título del artículo y el abstract se espera la descripción de alguna propuesta software.
[EX A]: es

[EX Q]: The paper describes a novel technique to improve the efficiency of computation graphs in deep learning frameworks. An impressive speedup can be observed in their implementation within TensorFlow. The content is presented with sufficient clarity, although some more graphical illustrations could be useful. This work is relevant in order to achieve highest performance in neural network training.   Pros:  - significant speed improvements through dynamic batching - source code provided   Cons:  - the effect on a large real-world (ASR, SMT) would allow the reader to put the improvements better into context - presentation/vizualisation can be improved
[EX A]: en

[EX Q]: Trata de aplicar una nueva estrategia a la gestión de requerimientos  No se respalda ni considera la aplicabilidad de técnicas propias de procesos de manufactura a procesos de software. Si bien es cierto hay autores como Demming que plantean que es posible hacerlo, existen otros autores como Sommerville que plantean que por las características propias del desarrollo de software, las técnicas de procesos de manufactura no son aplicables al software. Los autores de este artículo no entregan respaldo en relación a la validez de este aspecto. El artículo comienza planteando que la propuesta es para mejorar la educción de requerimientos, sin embargo, luego se deriva en que lo que se mejora es la generación de la SRS. La educción y la generación del documento de requerimientos son aspectos distintos. En el caso de experimentación que se presenta, no se ve por ninguna parte que se solucionen problemas ni en la educción, ni en la generación de la SRS, son más bien problemas de la implementación. Los errores detectados son aspectos básicos que cualquier programador con un mínimo de experiencia sabe cómo solucionarlos, sin necesidad que en la SRS se explicite el tipo de validaciones mínimas que se debe realizar como parte de las pruebas del sistema. La propuesta carece de guías prácticas que ayuden en su aplicación ¿cómo se deben realizar estas revisiones POKA-YOKE? ¿En qué aspectos hay que fijarse? ¿Existen artefactos que guíen la revisión? Hay errores de edición en el texto (palabras repetidas) Existen problemas de ortografía (acentuación de palabras)
[EX A]:
es