¿Qué tienen que ver las tarjetas gráficas con la llegada del hombre a la Luna? En realidad bastante. Esta simulación creada por el fabricante de gráficas Nvidia permite desmontar algunas de las teorías conspiranoicas más populares que tratan de demostrar que la llegada del hombre a la luna fue una puesta en escena de la NASA.
Lo que han hecho los autores de la simulación es recrear en 3D la popular fotografía en la que Neil Armstrong, ya sobre la superficie de la Luna, inmortalizó a su compañero Buzz Aldrin al bajar la escalerilla del Apolo 11. ¿Por qué esa foto en concreto? Porque es una de las que más esgrimen los partidarios de teorías de la conspiración para intentar demostrar que la llegada a la Luna fue un engaño.
La foto fue tomada en 1969. Desde entonces, los detractores de la llegada del hombre a la Luna esgrimen la teoría de que es imposible que esa foto pudiera realizarse sin una fuente secundaria artificial de luz como el foco artificial de un estudio. En la imagen, el sol se encuentra justo detrás del módulo lunar, mientras que Aldrin baja por la parte en penumbra de la nave, que debería estar mucho más oscura. También ponen en duda el hecho de que no se vean estrellas en el espacio que se ve al fondo.
La simulación realizada por Nvidia trata de desmentir ambas teorías utilizando una de las tecnologías de la nueva serie Maxwell de procesadores gráficos: La iluminación global basada en voxels o VXGI. Este tipo de renderizado de luz divide la imagen en miles de unidades cúbicas llamadas voxels que en realidad son algo así como píxeles cúbicos.
VXGI analiza cada voxel en tiempo real para medir su grado de transparencia y refracción, lo que permite calcular qué cantidad de luz (y de qué tonalidad) refleja cada objeto en una escena.
Para reconstruir la fotografía del Apolo 11, los investigadores de Nvidia calcularon los pliegues de los paneles de la nave, midieron la refracción de los trajes de la NASA y hasta las propiedades químicas del polvo lunar de la superficie. Durante esta fase, el equipo descubrió un dato clave: un brillo en la filmación original que se movía junto con la cámara y que solo podía provenir de una fuente externa de luz.
Al reconstruir la escena utilizando el motor gráfico Unreal 4 y calcular los vectores de luz, determinaron que la fuente secundaria de iluminación no es otra cosa que el traje del propio Neil Armstrong reflejando la luz del sol que, a su vez, se reflejaba en el terreno lunar.
En cuanto a la ausencia de estrellas, la demo técnica prueba que están ahí, solo que quedaron completamente ocultas debido a la exposición de la cámara, que estaba calibrada para la luminosa superficie lunar. Al alterar la exposición en el modelo 3D, las estrellas aparecieron donde debieron estar en la imagen.
Ampliar en: GIZMODO
El vídeo que aparece a continuación muestra una demostración publicada por Ryuto en NicoNico en la que el usuario puede simular tocar los pechos de un personaje animado. Para ellos utiliza un LeapMotion como sensor de presión, un Oculus Rift, una placa Arduino y un aparato con unos pechos artificiales.
El problema matemático del viajante (en inglés: Travelling Salesman Problem, TSP) es un clásico en el mundo de los algoritmos: encontrar la ruta más corta posible que visite cada ciudad una sola vez en un mapa, regresando a la ciudad de origen.
Como es de suponer, esto tiene miles de aplicaciones prácticas, pues también es un ejemplo de optimización y muchos problemas de otros campos pueden considerarse –matemáticamente– equivalentes. Si existiera un algoritmo definitivo no solo se podría ahorrar combustible y tiempo en los viajes, también optimizar cómo colocar los libros en una gran biblioteca o recorrer una calle para dejar los sobres de correo.
Por desgracia no existe un algoritmo definitivo: aunque a veces se puede encontrar la mejor solución si aumenta el número de nodos (en este caso: «ciudades») la complejidad del problema crece sobremanera; al cabo de un tiempo es fácil ver que no hay forma de probar todas las posibles soluciones ni de demostrar que una sea mejor que otra.
Ampliar en: microsiervos
La computación en la nube (cloud computing) no sólo es la última revolución en el mundo de las TIC, sino también un promotor clave de la innovación y el desarrollo económico. En el marco del proyecto CLOUDS, investigadores madrileños han logrado avances científicos cruciales en el estado-del-arte de la computación en nube.
La computación en nube es un paradigma emergente para los sistemas de computación distribuida, cuyo objetivo es ofrecer software como servicio a través de internet. El proyecto de investigación CLOUDS en el que IMDEA Networks ha participado, se ha centrado en el avance del estado del arte de esta tendencia tecnológica, que está revolucionando la informática y la forma en que los usuarios y los proveedores de la red interactúan en línea. Como toca todo internet, esta evolución está marcada por la impronta del espíritu de globalización. Desde el dispositivo individual autosuficiente que almacena todos los datos y contiene todas las aplicaciones requeridas por el usuario, estamos evolucionando hacia un modelo de servicio a la carta para la computación, comunicación y almacenamiento de información que se adapta dinámicamente a las variaciones en el consumo y cumple con las necesidades de un mercado global.
La nube permite el cruce de fronteras tecnológicas, geográficas y administrativas, concentrar l información y servicios en los centros de datos y los dispositivos que estén conectados a distancia, siendo accesible en cualquier momento, desde cualquier lugar y desde casi cualquier dispositivo o terminal. El nivel de autonomía, escalabilidad, automatización y flexibilidad que este modelo de computación ofrece no tiene precedentes. Los recursos tecnológicos están distribuidos a nivel mundial y la información se almacena en servidores de internet, liberando al usuario de la tradicional dependencia del dispositivo, la mejora de la movilidad, la accesibilidad y la seguridad, y permitiendo el acceso hasta hace poco impensable para servicios de próxima generación a través de pago por consumo, es decir, sin una inversión económica considerable previa.
El efecto de este modelo en la democratización del acceso al conocimiento y a los recursos es tan palpable tanto en el mundo de los negocios como en el extremo del usuario. Por ejemplo, las PYME pueden competir tecnológicamente, lograr la optimización del uso de los recursos TIC y hacer una inversión mínima, a escala; mientras que a las experiencias del usuario, cómo la gama inconmensurable de información, se añade ahora la posibilidad de utilizar herramientas especializadas, actualizadas y nuevas, el acceso a servicios públicos y privados o el uso de aplicaciones de colaboración, simplemente con la ayuda de un navegador web.
La investigación sobre la computación en la nube plantea desafíos, promesas y avances que van más allá de lo que está cubierto por el proyecto CLOUDS. De hecho, sus aplicaciones potenciales repercuten en diversas áreas que tienen en común un alto grado de innovación. De la telefonía móvil celular (detección de fraudes, procesamiento en tiempo real), banca y finanzas (detectar pagos fraudulentos de tarjetas y lavado de dinero), inteligencia de negocios (almacenamiento de datos en tiempo real y la publicidad dirigida escalable), seguridad (mitigación de denegación de- los ataques del servicio, eventos de procesamiento de seguridad de sistemas), redes de sensores (procesamiento de redes masivas de salidas de sensores) a la domótica (edificios inteligentes), por nombrar sólo algunos.
El proyecto ha sido financiado por el Departamento de Educación, Juventud y Deportes de la Comunidad de Madrid y estuvo en funcionamiento desde enero de 2010 hasta mayo de 2014 Investigadores del Instituto IMDEA Networks han colaborado con grupos de investigación de dos universidades de Madrid, la Universidad Politécnica de Madrid y la Universidad Rey Juan Carlos.
¿Cómo es posible que la nave espacial norteamericana Opportunity haya tardado tanto en superar la distancia recorrida por el Lunojod 2 de la extinta Unión Soviética?
La respuesta la debemos hallar en las diferentes condiciones de las dos misiones espaciales. Los Lunojods eran conducidos en tiempo real desde la Tierra por una tripulación de cinco personas. Es decir, lo que hoy en día llamaríamos ‘telepresencia’. Sin embargo, el retraso en las comunicaciones debido a la distancia que nos separa de Marte hace que sea imposible controlar un vehículo marciano en tiempo real (el retraso puede alcanzar los 40 minutos). Además, los rovers no están en contacto permanente con la Tierra y hay que aprovechar las sesiones de comunicación al máximo (normalmente hay unas dos sesiones usando las sondas Mars Odyssey y MRO). Sólo hace falta echar un vistazo a las instalaciones de control de ambas misiones para entender la diferencia en la filosofía de ambas misiones:
Para ‘conducir’ los rovers marcianos el equipo de tierra planifica una ruta detallada a partir de las imágenes de las cámaras de navegación y panorámicas, normalmente uno o dos días antes. Las instrucciones se mandan al rover y este las cumple diligentemente a no ser que su software detecte algún obstáculo no previsto, en cuyo caso el vehículo se detiene a la espera de nuevas órdenes. Los ordenadores de los rovers marcianos también permiten recorridos ‘automáticos’ de unos cien metros aproximadamente. En estos trayectos el software decide sobre la marcha si es necesario apartarse ligeramente de la ruta programada por los humanos con el fin de evitar rocas, grietas o salientes. Para poder decidir qué acción es la más correcta el rover emplea imágenes de las cámaras de navegación y los datos de las unidades de medida inercial (IMU).
O sea, el ‘conductor’ de Opportunity no dirige el vehículo con un joystick o un volante como si estuviera en un videojuego, sino que usa un ordenador ‘normal y corriente’ para introducir las coordenadas de la trayectoria. La conducción basada en imágenes de Opportunity, denominada ‘odometría visual’, tiene sus limitaciones. El procesador RAD6000 del rover funciona a 200 MHz y necesita unos tres minutos para procesar las imágenes tras recorrer 60 centímetros. Si además el rover se desplaza automáticamente (AutoNav) el tiempo de ejecución se dispara porque el ordenador debe decidir la ruta por sí solo. En AutoNav el rover debe gastar tres minutos de procesado cada 50-150 cm recorridos dependiendo del terreno.
Artículo completo en: El blog de Daniel Marín
El estudio lo ha llevado a cabo la organización ACM y muestra que en 27 de las 39 primeras universidades estadounidenses (el 69%) se enseña Python en alguno de sus dos primeros cursos. Entre ellas están el MIT, Austin-Texas, California-Berkeley, Columbia o Virginia Tech. Eso sí, entre las 12 que no también hay importantes como Stanford o Harvard. Esto hace que Python sea el lenguaje más utilizado en estas prestigiosas instituciones por encima de Java, Matlab (el principal lenguaje científico), el binomio C/C++ o, mira tú por donde, Scratch. Curiosamente lenguajes tan populares como Javascript o PHP no son muy usados en estos menesteres introductorios, aunque no deja de tener su lógica dado lo caóticos que pueden llegar a resultar.
Fuente: GENBETA: dev
Licencia CC
Esta lengua es básica para comunicarnos con personas sordas, y es algo que se ha aprovechado muy poco en internet con herramientas demasiado específicas. Singslator es una web que viene a cambiar eso. El portal no puede ser más sencillo: entras, escribes lo que quieres traducir y una mujer nos lo traducirá a la lengua de signos. Incluso podremos leer en tiempo real las palabras cambiadas que está utilizando, para que nosotros mismos también podamos aprender. Hay más de 12000 palabras que se pueden traducir.
La novedad de la que más se ha hablado en el último WWDC ha sido, con diferencia, un nuevo lenguaje de programación creado por Apple: Swift.
Desde que Apple compró a NeXT hasta la fecha, toda la programación para las plataformas Apple se viene haciendo fundamentalmente en Objective-C, un lenguaje que combina características de C y Smalltalk.
Se trata del tercer lenguaje más usado en el mundo (básicamente debido a iOS) y con usuarios relevantes (aunque poco conocidos) fuera del ecosistema Apple. Por ejemplo, un gran porcentaje de los sms premium que se envían en el Reino Unido, son gestionados por una aplicación creada con Objective-C en su encarnación Open Source: gnuStep.
Cuando lo lanzaron, lo describieron como un lenguaje más rápido, más sencillo y «Objective-C sin C». A poco que se escarba en él, esa descripción empieza a parecer cada vez menos acertada.
No hay motivos para que Swift sea más rápido que Objective-C (y vice versa): ambos usan el mismo compilador y la misma librería de clases. Por supuesto que si uno quiere, puede encontrar casos específicos en los cuales uno de los dos patina de forma espantosa y mostrar eso como «prueba». Sin embargo, en aplicaciones reales, no creo que haya grandes diferencias en favor de cualquiera de los dos.
Una de las razones por las cuales se está generando un enorme interés por Swift, es por su aparente sencillez. Lamentablemente, después de muchas horas con el lenguaje, he de decir que no soy de esa opinión. Objective-C tiene una sintaxis extraña pero sumamente sencilla y homogénea. Swift, por otro lado, tiene una sintaxis más familiar, pero esconde una infinidad de casos especiales, detalles sutiles y variaciones sintácticas para hacer una misma cosa. Bajo una capa de aparente sencillez, se esconde un lenguaje con una complejidad solo comparable a C++.
«Objective-C sin C». Esa frase dio a entender a muchos que se trataba de un nuevo lenguaje que preservaba las características esenciales del lenguaje, eliminando las «rémoras del pasado». Nada más lejos de la realidad. Swift es un lenguaje, no sólo distinto, sino opuesto en casi todo a Objective-C.
Ampliar en: GENBETA: dev
Licencia CC
Uno de los grandes problemas de los SSD – discos de estado sólido, la nueva generación de discos duros mucho más veloces y eficientes – es la vida de dichos dispositivos. Esto se debe a que las primeras generaciones duraban poco tiempo, agotándose después de escribir / sobreescribir demasiados gigabytes de datos.
Esta poca duración de escritura ha desaparecido ya de los nuevos SSD, con los nuevos dispositivos capaces de durar décadas de uso común escribiendo y sobreescribiendo datos, haciendo de la única debilidad de los SSDs (aparte de un mayor precio) prácticamente inexistente.
Hay un programa que basta con pulsar Start y empezar a usar el ordenador como siempre. Al final de una jornada de trabajo, nos dará aproximadamente cuantos datos hemos escrito y leído en el SSD, que a su vez, utiliza para calcular la duración promedio del SSD.
Los datos que SSDReady proporciona son bastante pesimistas, pues está basado en información de un SSD de 40 GBs, cuando éstos eran habituales. La calidad de los SSDs ha mejorado considerablemente.
Fuente: arturogoga
El sistema de patentes en Estados Unidos es muy curioso. Si intentas registrar una patente sobre un método para hacer parejas de personas según el número de características que tengan en común, lo más probable es que te la rechacen por ser una idea abstracta. Pero si intentas registrar el mismo método ejecutado por un ordenador, las cosas cambian y probablemente acabarías con una bonita patente en tu haber.
¿Cuál es la diferencia? En Estados Unidos no se puede patentar una idea abstracta. Sin embargo, sí se pueden patentar máquinas específicas para ese propósito. En 1996, la oficina de patentes estadounidense (USPTO) publicó unas guías para evaluar las patentes, con la siguiente frase:
«Una aplicación práctica de una invención relacionada con ordenadores es patentable. Este requisito puede distinguirlo de las prohibiciones sobre patentes de ideas abstractas, leyes de la naturaleza o fenómenos naturales.
El Tribunal Supremo dice «así no»
Alegaciones que simplemente requieran una implementación genérica en un ordenador, no transforman la idea abstracta en una invención patentable.
Esa es la frase clave de la sentencia unánime del Tribunal Supremo estadounidense en el caso Alice Corp. vs CLS Bank Intl., que según la Electronic Frontier Foundation (EFF) podría invalidar todas las patentes abstractas de software. Otros como IPWatchdog – bastante alejados de las ideas de la EFF – explican que esta sentencia podría invalidar todas las patentes de software, quizá exagerando un poco.
Por ejemplo, patentes como la de Amazon para ajustar el tamaño de una caja al producto a enviar con un programa de ordenador o la de DietGoals sobre un programa de planificación de recetas y comidas serían inválidas, ya que simplemente están aplicando una idea abstracta y genérica a un programa, que es lo que las hace patentables a los ojos de la USPTO.
Fuente: GENBETA
Licencia CC