Un vasito de leche calentita y a dormir

¿Qué encontrarás en esta entrada?

• Demostración del problema del vaso de leche y café.
• Extensión a varias iteraciones.

Hace unos días me salió en redes sociales un vídeo de Quantum Fracture sobre un vaso de leche y otro de café. El vídeo se basaba en un problema propuesto por el Instituto de Ciencias Matemáticas un poco antes, y consiste en lo siguiente:

 

Tienes dos vasos iguales: uno de leche y otro de café. A continuación, tomas una cucharada del vaso de leche, la depositas en el de café y lo mezclas. Seguidamente, coges una cucharada de igual tamaño de la mezcla que ha resultado y la depositas en el de leche. Lo curioso de esto es que la cantidad de café en el vaso que originalmente era de leche es la misma que la de leche en el vaso que originalmente era de café.

 

La explicación de Quantum Fracture, si bien orientada a la divulgación, me pareció que simplificaba demasiado, partiendo de un supuesto muy concreto en el que el tamaño de la cuchara era la mitad del vaso, y así se puede ver gráficamente que el líquido en vaso ajeno es de 1/3.

 

Estoy con gripazo, y la cantidad de leche calentita y café que consumo ahora mismo como remedio creo que me autorizan a dar mi opinión, así que ahí voy. 

 

Demostración

Lo primero que hay que hacer es ser riguroso con el lenguaje. Cuando hablamos de "cantidad" nos estamos refiriendo a volumen, ni a moléculas, ni a masa, ni a ninguna otra cosa que no sea el volumen. También vamos a suponer que los líquidos se mezclan perfectamente, de forma totalmente homogénea, y no reaccionan entre sí químicamente de forma que pueda variar la densidad que tenían ambos líquidos antes de la mezcla. Así, 1 l de leche más 1 l de café son 2 l de mezcla.

 

Con ello, esta es mi demostración:

 

 

Script y extensión iterativa

Llegados a este punto pensé: ¿podría generalizarse y repetir el proceso una y otra vez? Y aquí es donde creo prudente recordar que, ante cualquier fallo que detectéis en mis cálculos, estoy haciendo esto con fiebre.

 

Me puse a programar un bucle iterativo en Octave/Matlab de la siguiente forma:

 

function [L1,C1,L2,C2] = Cucharadas (N,V,v)
%
%    ASTAROTH'S WORLD
%    https://astarothsworld.blogspot.com/
%
% Este script calcula N iteraciones del siguiente problema:
%
% Partimos de dos vasos: uno de leche y otro de café, ambos de volumen V.
%A continuación, pasamos una cucharada de tamaño v del vaso de leche al de
%café, y removemos. Después, cogemos otra cucharada del mismo tamaño de la
%mezcla y la devolvemos al vaso de leche. Se trata de ver cuánta leche y
%café componen las dos mezclas finales después de N iteracciones.
%
disp('')
disp('SITUACIÓN INICIAL:')
disp('')
%Inicialización de valores
L1=V;
C1=0;
V1=L1+C1;
L2=0;
C2=V;
V2=L2+C2;
disp(['Volumen total en el vaso 1: ',num2str(V1),' l'])
disp(['Cantidad de leche en el vaso 1: ',num2str(L1),' l'])
disp(['Cantidad de café en el vaso 1: ',num2str(C1),' l'])
disp('')
disp(['Volumen total en el vaso 2: ',num2str(V2),' l'])
disp(['Cantidad de leche en el vaso 2: ',num2str(L2),' l'])
disp(['Cantidad de Café en el vaso 2: ',num2str(C2),' l'])
disp('')
disp(['Volumen en una cucharada: ',num2str(v),' l'])
for i=1:N
    rhocini=C1/V1;
    rholini=L1/V1;
    rhoc=(C2+rhocini*v)/(V2+v);
    rhol=(L2+rholini*v)/(V2+v);
    L1=L1-rholini*v+rhol*v;
    C1=C1-rhocini*v+rhoc*v;
    V1=L1+C1;
    L2=L2+rholini*v-rhol*v;
    C2=C2+rhocini*v-rhoc*v;
    V2=L2+C2;
    disp('')
    disp(['ITERACIÓN: ',num2str(i)])
    disp('')
    disp(['Volumen total en el vaso 1: ',num2str(V1),' l'])
    disp(['Cantidad de leche en el vaso 1: ',num2str(L1),' l (',num2str(L1/V1*100),'%)'])
    disp(['Cantidad de café en el vaso 1: ',num2str(C1),' l (',num2str(C1/V1*100),'%)'])
    disp('')
    disp(['Volumen total en el vaso 2: ',num2str(V2),' l'])
    disp(['Cantidad de leche en el vaso 2: ',num2str(L2),' l (',num2str(L2/V2*100),'%)'])
    disp(['Cantidad de Café en el vaso 2: ',num2str(C2),' l (',num2str(C2/V2*100),'%)'])
    %Graficar:
    LA1(i)=L1;
    CA1(i)=C1;
    VA1(i)=V1;
    LA2(i)=L2;
    CA2(i)=C2;
    VA2(i)=V2;
end 
x=1:N;
close all;
subplot(1,2,1)
plot(x,LA1,'b--')
hold on
title('VOLUMEN DE LECHE Y CAFÉ EN CADA VASO EN CADA ITERACCIÓN')
xlabel('Iteracciones')
ylabel('Volumen (l)')
plot(x,CA1,'k--')
plot(x,LA2,'b+')
plot(x,CA2,'k+')
plot(x,VA1,'b')
plot(x,VA2,'k')
legend('Volumen de leche en el vaso de leche', 'Volumen de café en el vaso de leche','Volumen de leche en el vaso de café', 'Volumen de café en el vaso de café','Volumen total en el vaso de leche','Volumen total en el vaso de café')
subplot(1,2,2)
axis([0 5 0 3])
hold on
rectangle('Position',[1 1 1 0.75],'FaceColor',[L1/V1 L1/V1 L1/V1])
rectangle('Position',[3 1 1 0.75],'FaceColor',[L2/V2 L2/V2 L2/V2])
title('VASOS')
text(1.5,0.7,['Leche: ',num2str(L1/V1*100),'%'],'HorizontalAlignment','center')
text(1.5,0.6,['Café: ',num2str(C1/V1*100),'%'],'HorizontalAlignment','center')
text(3.5,0.7,['Leche: ',num2str(L2/V2*100),'%'],'HorizontalAlignment','center')
text(3.5,0.6,['Café: ',num2str(C2/V2*100),'%'],'HorizontalAlignment','center')
text(1.5,2,'VASO 1','HorizontalAlignment','center')
text(3.5,2,'VASO 2','HorizontalAlignment','center')

 

 Y con él he obtenido los siguientes resultados:

 

1.- Caso realista: un vaso de unos 250ml, una cuchara de postre 5ml, 1 iteracción 

 

Se verifica, efectivamente, que hay la misma cantidad de café en el vaso de leche que de leche en el de café (un 1,96% del volumen del vaso), conservando cada vaso gran parte de su naturaleza inicial, puesto que la cuchara es muy pequeña en comparación con el volumen de los vasos.

 

2.- Caso de Quantum Fracture: cuchara con la mitad del volumen que el recipiente

 

En este caso recuperamos el resultado de 1/3.

 

3.- Extensión del caso realista: un vaso de unos 250ml, una cuchara de 5ml, 30 iteracciones 

 

Como era de esperar, vemos que se tiende a que ambos vasos se conviertan en mezclas iguales, conservando en cada paso aquello de que la cantidad de café en el primer vaso es la misma que la de leche en el segundo.

 

4.- Extensión del caso realista: un vaso de unos 250ml, una cuchara de 5ml, 200 iteracciones  

 

 

Aquí continuamos las iteraciones hasta 200, viendo que efectivamente cada vez las mezclas de ambos vasos son más parecidas entre sí hasta ser casi iguales. 

 

La verdad es que el script lo he hecho un poco a ojo y con fiebre, por lo que no descartaría algún error, pero creo que más o menos reproduce lo que se podría esperar de un caso como este.

 

Al final, como ya apuntaba algún seguidor de Quantum Fracture, esta propiedad no es tan rara si tenemos en cuenta que partimos de un mismo volumen de leche y café repartido en dos vasos que, al final de cada iteración, acaban con ese mismo volumen. Dada la mezcla que sea en el vaso de café, todo lo que le falte de café para rellenar el vaso tiene que ser necesariamente leche, y el resto de leche debe estar en el otro vaso, y para completar ese otro vaso, sólo hay café.

 

 

Así que visto así es más evidente que la cantidad de cualquiera de los líquidos debe ser la misma que su opuesto en el otro vaso, sea cual sea la mezcla. Quizás lo que aporta esta entrada, si es que aporta algo, sea el cálculo exacto de esa cantidad en cada iteración dado el volumen del vaso y la capacidad de la cuchara.

ComfyUI

¿Qué encontrarás en esta entrada?

• Presentación de ComfyUI.
• Vídeos juntando imágenes generadas por IA.

Como podéis haber visto en mi última entrada, ha vuelto a picarme el gusanillo de la generación de imágenes por IA, lo cual me ha llevado a descubrir ComfyUI. Aunque parece ser que tiene interfaz web, siguiendo las instrucciones de Yushan777 (a quien estoy muy agradecido por ello), me lo he instalado en local y estoy a tope con él.

 

Lo que me ha impresionado de esta interfaz de usuario para Stable Diffusion es que está planteada como un diagrama de nodos, lo que permite, de forma muy visual, configurártelo como quieras y desatar toda la potencia y personalización que desees.

Yo llevo unos días jugando con esto y abajo os dejo el esquema que estoy utilizando y una muestra de cómo funciona (siendo consciente de que, por mi inexperiencia, probablemente tenga muchas carencias).

La ventaja de construirte modularmente una interfaz a tu medida, es que le puedes añadir lo que desees. Yo, por ejemplo, le he añadido a través de un LoRa un módulo LCM, que me permite disfrutar de una previsualización casi a tiempo real según voy escribiendo, lo cuál es muy útil como paso inicial para afinar prompts.

Otra ventaja, es que puedes sacar los parámetros como variables y hacer un barrido, lo que permite, de forma fácil crear vídeos como los siguientes (en los que he variado el cfg).

Todo esto lo podéis ver en Mephisto's Dream, que está últimamente más activo que nunca. ¡Os veo por allí!

Perseverance

¿Qué encontrarás en esta entrada?

• Un poco de info sobre la misión de la NASA en Marte.
  
• Seguimiento de la Perseverance.
• Scripting en Celestia y mi primer ejemplo con la Perseverance. 

Es el tema del momento: febrero de 2021 es el mes en el que varias misiones llegarán al planeta rojo. Quizás la más sonada de todas ellas sea la misión Mars 2020, de la NASA. En ella, un vehículo de tipo "rover" llamado Perseverance aterrizó el pasado 18 de febrero de 2021 a las 20:56 UTC y desde entonces está por ahí dándose vueltas por la superficie marciana, sacando fotos y recogiendo muestras.

Perseverance está equipada con la última tecnología, incluyendo MEDA, una estación meteorológica fabricada en España, en el INTA. La misión de este rover es buscar restos de vida pasada en el planeta vecino, tomar muestras minerales y de la atmósfera y recopilar datos en general para preparar el terreno para posibles misiones con presencia humana en un futuro no muy lejano.

La localización de su aterrizaje no es casual. De hecho, ha sido el aterrizaje más complicado que se ha realizado en Marte. La idea es que el cráter de Jezero sea una localización idónea para buscar rastros biológicos ya que en su pasado fue un gran lago en el que confluían varias corrientes y, por tanto, un lugar propicio para la vida.

Y con todo esto, unido a alguna serie de ciencia ficción que estaba viendo, he retomado un poco el contacto con Celestia, ese simulador espacial gratuito que merece todas mis alabanzas. Me he metido por primera vez en el scripting (gracias a este manual) y qué mejor forma de empezar que siguiendo un poco el camino de la Perseverance. Eso es lo que he realizado en este, mi primer script ".cel". Con Celestia se pueden hacer vídeos de manera bastante fácil, por lo que os dejo el vídeo de lo que hace el script a continuación.

Esperemos que todas estas misiones, que parecen sacadas de la ciencia ficción, nos traigan un próspero futuro y no una distopía futurista como se acostumbra a ver en el cine.

El chacachá del tren

¿Qué encontrarás en esta entrada?

• Análisis empírico de las aceleraciones sentidas dentro de un tren.

Como os comentaba hace unos días, quedé embelesado con Physics Toolbox Sensor Suite y, desde entonces, he estado haciendo "pequeños experimentos".

Una de las cosas que he estado midiendo es el traqueteo del tren. Sin embargo, con el confinamiento declarado en España ayer con motivo del COVID-19, me parece a mi que la toma de datos ha llegado a su fin.

En primer lugar, quiero dejar claro desde el principio que esto sólo es un juego. Es decir, las medidas no se han tomado con el rigor científico que se debería y los sensores (los de mi móvil) pueden que no tengan la precisión adecuada. Por ejemplo, no he fijado el móvil con cinta a un asiento para medir la aceleración que siente rígidamente sobre él, sino que lo he llevado encima de mi regazo, con la consiguiente amortiguación.

¿Qué pretendo medir?

Lo que pretendo es medir en qué asientos del tren se siente una mayor aceleración perpendicular al movimiento, tanto los "botes" (eje z) como los empujones laterales (eje x).

¿Cómo lo voy a medir?

Para ello, voy a considerar el tramo de vía de Torrejón de Ardoz a San Fernando de Henares y trenes de uno o dos pisos en ambos sentidos de circulación. Me gustaría haber tenido datos con todas las combinaciones pero, antes del COVID-19, sólo he podido recopilar lo siguiente:

Casuística 1:

Trayectos de Torrejón de Ardoz a San Fernando de Henares en tren de dos plantas (medida en la planta inferior). 2 juegos de datos.

Casuística 2:

Trayectos de Torrejón de Ardoz a San Fernando de Henares en tren de dos plantas (medida en la planta superior). 2 juegos de datos.

Casuística 3:

Trayectos de San Fernando de Henares a Torrejón de Ardoz en tren de un solo piso. 2 juegos de datos.

Las medidas las he tomado con un móvil Samsung Galaxy Note 9 sobre mi regazo con Physics Toolbox Sensor Suite PRO en modo 'Reporte Múltiple'. El móvil estaba orientado en la dirección de avance (eje y), de manera que las aceleraciones que me interesarán serán los otros dos ejes (eje x y eje z).

Análisis

De los datos recogidos en el modo 'Reporte Múltiple', me he quedado con la aceleración en el eje x (empujones laterales) y en el eje z (botes). También he recogido los tiempos y la velocidad por GPS.

 

Todo ello lo he analizado en un script en Octave que he realizado yo mismo para este fin. En él, se calculan los valores medios máximos y mínimos de las distintas magnitudes en cada casuística y se representan esas aceleraciones (fuera de la dirección del movimiento) en comparación con la velocidad que alcanza el tren.

Resultados

En relación a la aceleración transversal horizontal (eje x), los resultados son los siguientes.

Es decir, atendiendo a los valores medios, la aceleración sentida en el piso de abajo es tan solo un 65% la que se siente en el piso de arriba. Esto es lógico, ya que en un movimiento circular, la aceleración tangencial crece linealmente con el radio, como se ve en la siguiente ilustración.

Menos intuitivo es el caso del tren de un solo piso, que parece que en media el viaje es más movidito que en los trenes de dos pisos. Podría ser por la construcción de los mismos, que los trenes de dos pisos se hayan diseñado en general más estables porque son los que más riesgo de volcar tienen debido a su altura.

Otra cosa que se puede ver en la ilustración es que la aceleración transversal no es sólo en el eje x, sino que tiene una componente también en el eje z y que es más relevante en el piso de abajo (con menor distancia al eje de giro). Para nuestra tranquilidad, los trenes no suelen inclinarse de esa forma: estamos suponiendo inclinaciones infinitesimales y, por tanto, de manera aproximada podemos suponer que la mayor parte de la aceleración sentida por empujes laterales es en el eje x. Un análisis más en detalle podría incluir las medidas de los ángulos de posición (que también se midieron), o el efecto de la amortiguación, pero el objetivo de este "experimento" es dar una visión más bien cualitativa.

Respecto a las máximas, sí vemos una diferencia. Aunque el tren de un solo piso es en media el más inestable, las aceleraciones máximas que siente son las menores de las tres casuísticas. El piso de abajo de un tren de dos plantas le dobla y las aceleraciones en el piso de arriba son siete veces mayores que en el tren monoplanta.

Otra curiosidad es que ordené los valores por la velocidad GPS, suponiendo que, contra más rápido fuese el tren, más vibraría. Sin embargo, en las gráficas se ve que no es así. El tren pasa de estar parado a superar los 100 Km/h, pero las máximas vibraciones tienen dos picos: uno en 40 km/h y otro en 80 Km/h (también parece haber uno más pequeño a 60 Km/h). Esto me hace suponer que depende del estado de la vía: hay zonas en las que las vías están en buen estado y se pueden alcanzar los 100 Km/h sin vibraciones pero debe haber tres tramos de vías en los que las vibraciones son mayores (y, por estos tramos, el tren se ve obligado a reducir su velocidad a 80, 60 o 40 Km/h).

A continuación, analizaremos los botes verticales (eje z).

En esa ocasión vemos que la aceleración vertical sentida en la primera planta de un tren con dos pisos es ligeramente mayor (101,7%) en media que la del piso superior. En este caso se esperaría que fuesen prácticamente iguales y, quizás, la diferencia (del orden del 2%) podría venir de lo comentado anteriormente: que en el piso inferior las fuerzas horizontales tienen una mayor aportación en el eje z que en el piso superior. Me parece más difícil justificar el la diferencia entre las máximas (la máxima en el piso de abajo es un 161,1% el valor de la máxima en el piso de arriba). Creo que habría que hacer más medidas para ver si fue un error puntual en la toma de datos.

Indicar que, de hecho, las máximas en el eje x y en el eje z son del mismo orden en todos los casos menos en el de la primera planta de un tren con dos pisos (lo que podría apoyar un error en esta medida). Sin embargo, viendo la gráfica, esta aceleración máxima se repite en al menos en tres puntos del trayecto.

Descartando este juego de datos, los resultados son bastante distintos (baja la media y, sobre todo, la máxima).

Lo que nos lleva a pensar que, para que esto tenga alguna validez, deberían hacerse muchas más medidas que hagan el sistema más robusto ante errores en mediciones o circunstancias especiales de algunos de los trayectos.

Indicar que, en este caso, el traqueteo vertical es sin duda menor en el tren de un sólo piso.

Conclusiones

Si te gusta ir durmiendo en el tren sin que te estén balanceando hacia los lados, lo mejor es que vayas en el piso de abajo de un tren de dos plantas aunque, cuidado, puedes sentir algún empujón puntual que te despierte. Si no te importa un leve balanceo siempre que no haya sobresaltos fuertes, lo mejor es coger un tren de una sola planta que, además, es el que menos botes da.

Todo lo que un físico necesita llevar en un bolsillo

Qué encontrarás en esta entrada?

• Análisis de Physics Toolbox Sensor Suite.
• Comparación con otras aplicaciones similares.
• Ejemplos de uso. 

Hoy vamos a hablar de Physics Toolbox Sensor Suite.

Click para ampliar

En concreto, de su versión gratuita disponible en Google Play Store. Esta aplicación consiste en un conjunto de herramientas para la visualización y captura de los datos de los distintos sensores de tu dispositivo móvil, con la posibilidad de exportación para el posterior análisis más detallado en programas como MATLAB/Octave (por ejemplo).

En este blog no es la primera vez que tratamos un tema similar. Por ejemplo, aquí analizábamos Science Journal vs AndroSensor (spoiler: en mi opinión, el primero gana en lo que se refiere a la interfaz y experiencia de usuario, pero el segundo es mucho más detallado en lo que se refiere a la recolección de datos). ¿Existirá un término medio entre ambas aplicaciones? Pues creo que Physics Toolbox Sensor Suite está en ese deseado punto medio y con algunas cosas propias que aportar.

Diseño de Physics Toolbox Sensor Suite en la vista de gráficas por cada componente del magnetómetro

En mi opinión, Physics Toolbox Sensor Suite tiene ya un diseño más atractivo con respecto a Androsensor y cuenta una apariencia más profesional que Science Journal.

Science Journal mostrando una anotación en cierto punto de la gráfica

Diseño espartano de AndroSensor (con publicidad)

Sin embargo, seguimos sin disponer de herramientas de usabilidad como las anotaciones en ciertos puntos de la gráfica con las que sí contaba Science Journal (y que personalmente creo que son una genialidad). En relación a los datos que muestra/registra cada aplicación, abajo podéis ver una tabla con la comparativa (basado en los sensores de un SAMSUNG Galaxy Note 9).

Click para ampliar

Como veis, lo primero que salta a la vista es que Science Journal es bastante más simple que los demás. Respecto a los otros dos, están bastante empatados, aunque es verdad que Physics Toolbox Sensor Suite parece que le da más importancia los datos visualizados que a los registrados. Esto es una lástima, porque muestra una gran cantidad de datos asociados, por ejemplo, al GPS, pero cuando haces una medida múltiple no guarda cosas tan básicas como la altitud (aunque este valor se pueda estimar a partir de la presión atmosférica, que sí queda registrada).

También hay varias herramientas en Physics Toolbox Sensor Suite muy originales para analizar la frecuencia sonora (de las que AndroSendor no dispone), pero ninguna de ellas registra datos a la hora de hacer medias (son sólo para visualización en el momento).

Por otra parte, una gran ausente en Physics Toolbox Sensor Suite respecto a AndroSendor es la medida de la gravedad. Ambas aplicaciones te permiten ver los valores del acelerómetro y los de la aceleración lineal que queda al descontar los efectos gravitatorios, pero AndroSensor te muestra (y registra) expícitamente cómo afectaba la gravedad a tu dispositivo mientras que no es así en Physics Toolbox Sensor Suite. Pese a ser una medida indirecta que podría obtenerse de las demás, me parecía interesante tenerla.

También quería comentar que los datos exportados dependen del modo en el que estemos. Physics Toolbox Sensor Suite permite realizar medidas de magnitudes concretas cuando las estemos visualizando, o medidas de varias magnitudes simultáneamente (que creo que es mucho más interesante para ver relaciones entre ellas). Respecto a esto segundo, hay dos modos: 'Sensor Dual' y 'Reporte Múltiple'. El primero visualiza gráficamente sólo dos magnitudes que registra de forma simultánea. El problema es que no todas las magnitudes están disponibles para seleccionar y que sólo se pueden medir de dos en dos. El segundo modo permite el registro de la mayoría de las magnitudes simultáneamente (es el modo en el que he basado la tabla de unos párrafos más arriba), pero la visualización en el momento de realizar la medida deja bastante que desear (son sólo una ristra de números cambiando velozmente). Si no afectase demasiado a la frecuencia de muestreo, me gustaría un término medio: poderlo registrar todo a la vez con una interfaz a tiempo real que te permita ver cómo cambia de una manera visualmente atractiva.

En relación a la exportación de datos, la primera dificultad con Physics Toolbox Sensor Suite me la encuentro con el formato. Aunque he leído que es posible, no encuentro dónde cambiar el formato del ".csv" generado. Por defecto me aparece:

• Separador de columnas: ";"
• Separador de decimales: "," (formato español)

El problema es que muchos programas, como MATLAB/Octave, pueden tener problemas con este formato (ya que suelen trabajar en formato anglosajón). En los citados programas existe la  función 'csvread' que requiere lo contrario:

• Separador de columnas: ","
• Separador de decimales: "."

También se puede utilizar 'dlmread', ya que aquí se permite cambiar el separador al gusto, pero el propio MATLAB no lo recomienda y, en cualquier caso, estaría el problema del separador de decimales. Mi solución a esto ha sido realizar una pequeña transformación previa con un script de Linux de la forma:

cat $1 | sed -e 's/,/./g' | sed -e 's/;/,/g' > trans_$1

Donde '$1' es el fichero a transformar. Ahora sólo tengo que ejecutar el script la primera vez que quiera leer unos datos y puedo trabajar con ellos.

Con respecto a la frecuencia de muestreo, AndroSensor no recomienda tomar medidas cada menos de 0,1s, aunque se puede configurar para que las tome cada 0,005s. Sin embargo, esto no funciona del todo bien (como veremos algo más abajo). Por parte de Physics Toolbox Suite, cada sensor tiene su propia frecuencia.

He hecho un par de medidas globales con los siguientes resultados (que, una vez más, dependerán de mi dispositivo).

Muestreo en AndroSensor

Muestreo en Physics Toolbox Sensor Suite

Si calculamos la frecuencia media de muestreo, es algo menor de 5ms para AndroSensor (con un máximo de 11ms) y de algo más de 6ms (con un máximo de 56ms) para Physics Toolbox Sensor Suite. Aunque estas estadísticas parecen poner a AndroSensor como claro ganador, hay que tener en cuenta algo más antes de emitir veredicto. Se han ocultado columnas para mejorar la visualización del muestreo de AndroSensor, por lo que deberéis hacer un pequeño acto de fe y creedme cuando os digo que las filas marcadas en amarillo no contienen ningún cambio salvo la marca de tiempo. Las celdas en rojo muestran los cambios de una medida a otra y podemos ver fácilmente que en el caso de Physics Toolbox Sensor Suite siempre hay algún elemento relevante que cambia con cada toma de datos.

Es decir, dado lo improbable de obtener exactamente lo mismo en dos medidas consecutivas de sensores como el acelerómetro, creo que está mejor optimizado Physics Toolbox Sensor Suite para guardar datos sólo cuando la frecuencia de muestreo nativa de los distintos sensores permita que haya algún cambio en alguno de ellos. Por otra parte, creo que AndroSensor toma demasiadas medidas "irrelevantes" cuando los sensores no han tenido tiempo para reaccionar, "guarreando" un poco los datos recogidos. Dicho esto, es cierto que intervalos de 56ms son muy dilatados si tenemos en cuenta que la frecuencia del acelerómetro en mi caso está en torno a los 500Hz (una medida cada 2ms). También es verdad que hay un gran número de medidas entorno a 1-2ms, pero supongo que la media sube por momentos puntuales de colapso por la cantidad tan grande de datos que deben recopilar y escribir estas aplicaciones en un corto periodo de tiempo (sin contar con que en paralelo he podido estar haciendo otras cosas con el móvil, como escuchar música, para lo cual debe estar leyendo del almacenamiento).

En resumen, creo que las tres aplicaciones comentadas son realmente buenas. Creo que Science Journal peca de simple, pero lo sumple con una interfaz muy amigable. AndroSensor es tremendamente completo, pero es estéticamente feo, algo engorroso de usar y con publicidad. Por último, Physics Toolbox Sensor Suite es muy similar a AndroSensor en funcionalidades, cuenta con algunos extras interesantes y tiene una interfaz agradable y profesional.

Y podemos pasar al ¿y para qué vale todo esto? Pues básicamente para sentirse como T'Pol en Star Trek Enterprise: un oficial científico en exóticos planetas investigando su entorno con su escáner.

Bueno, a lo mejor me he flipado un poco, pero sí es cierto que nos permite medir nuestro entorno y poder ver cosas curiosas que, de otra forma, no podríamos. Un ejemplo es el de mi ascensor y sus extraños campos magnéticos de los que ya os he hablado muchas veces.

En la primera gráfica se muestra cómo oscila el campo magnético cuando voy subiendo por mi ascensor. Tanto es así, que es posible identificar de forma clara los pisos (que están en torno a los 215μT) y entre ellos, un máximo de unos 230μT y un mínimo de aproximadamente 200μT. Por el contrario, si subo por la escalera (segunda gráfica) parece que me enfrento a un campo de unos 280μT, que baja a 230μT en las entreplantas.

En esta segunda imagen se ve de nuevo cómo subo las escaleras. En la parte de abajo de la imagen, mi ganancia en altitud (estimada por el cambio en la presión), mientras que en la parte de arriba se ve cómo van cambiando las distintas magnitudes de manera casi periódica, de tal forma que es fácil distinguir el paso de un piso al siguiente.

De igual manera se pueden sacar muchos datos y analizarlos al gusto. Estas son unas pequeñas representaciones de datos que he estado tomando estos días.

Trayecto en coche por una carretera en el que se pasan dos rotondas

Trayecto en tren

En el caso de la carretera se distinguen perfectamente las dos rotondas en los datos del GPS. Os pongo más detalle de la visualización por GPS Prune (representación cartogrfica a la que estamos más costumbrados) y la representación por Octave (representación en 3D de las coordenadas esféricas que se obtienen del GPS).

Y en el caso del tren, pude comprobar que cada vez que se aceleraba aumentaba el campo magnético. Si bien las lecuras directas de la aceleración no eran tan claras, el cálculo numérico de la tasa de variación de la velocidad GPS sí parecía estar íntimamente ligada a aumentos en el campo magnético.

Lo dicho: un oficial científico en exóticos planetas investigando su entorno con su escáner.

Aquiles y la tortuga

Qué encontrarás en esta entrada?

• Presentación de la paradoja de Zenón: Aquiles y la tortuga.
• Solución de la misma.
• Simulación por OCTAVE/MATLAB. 

Hoy quería hablaros de Zenón de Elea y, en concreto, de una de sus paradojas más famosas: la de la carrera de Aquiles contra la tortuga. Esta paradoja se comenta muchas veces a nivel divulgativo pero, pese a mi formación en ciencias, nunca me la han explicado en un contexto académico como es debida y, a causa de ello, cuando me topé por primera vez con ella me ocasionó un gran desconcierto. Para todos aquellos que estén en mi situación, os invito a que me acompañéis a las entrañas de esta paradoja. 

Zenón fue un filósofo griego que vivió en el siglo V antes de Cristo. Él estaba convencido (entre otras cosas) de que el movimiento era una ilusión y quería demostrar por reducción al absurdo que nuestros sentidos nos engañaban. Para ello, creó una inquietante historia: una carrera entre Aquiles, el héroe griego que interpretó en su día Brad Pitt para la película Troya y... ¿una tortuga?

Brad Pitt mirando fíjamente a la tortuga

Efectivamente, para todos es obvio que Aquiles ganaría la carrera sin despeinarse, pero aquí Zenón introduce por primera vez en la historia (que se tenga constancia) un razonamiento propio del Cálculo Infinitesimal que nos dejará un poco KO. Zenón propone dar un poco de ventaja a la tortuga (¡qué menos!) y hace el siguiente razonamiento:

• Inicialmente, Aquiles está en la posición "0" y la tortuga en una posición más adelantada por su ventaja.

• Empieza la carrera y Aquiles llega hasta donde estaba la tortuga al principio pero, en ese tiempo que ha tardado, la tortuga ha avanzado una distancia igual a su velocidad (por pequeña que ésta sea) multiplicada por el tiempo que ha tardado Aquiles (que por veloz que sea, no tardará un tiempo nulo). Es decir, cuando Aquiles alcanza la posición con la que partía la tortuga, ésta ha avanzado un poquitín más.

Este argumento se puede repetir indefinidamente, por lo que la conclusión parece ser que Aquiles nunca alcanzará a la tortuga puesto que, cada vez que llega a su posición anterior, ésta habrá avanzado un poquitín de nada, pero suficiente para ganarle. 

Personalmente, a mi este razonamiento me producía una gran inquietud y es que me parece tremendamente razonable, pero no concuerda con lo que vemos. ¿No podemos fiarnos de análisis como el de Zenón que parecen tan lógicos? ¿Las matemáticas no funcionan? ¿Toda la física es mentira?

Bueno, realmente a las dos últimas preguntas no me atrevo a contestar, pero os puedo adelantar que Zenón no estaba equivocado y su razonamiento infinitesimal es correcto: la tortuga ganará infinitamente a Aquiles. Lo que está mal es la conclusión: no lo hará eternamente, y finalmente Aquiles tomará ventaja.

¿Cómo conciliar ambas cosas? Pues muy fácil: el "engaño" está en la forma en la que se acerca Aquiles a la tortuga: estamos suponiendo en cada interacción que la tortuga está siempre un poco adelantada y calculamos dónde estará la tortuga en el momento en que Aquiles haya alcanzado la posición anterior que tenía esto. Efectivamente, de esa manera nos sale que en cada interacción la tortuga sacará una nueva ventaja, sin embargo, ésta será cada vez más pequeña y el tiempo en el que Aquiles la alcanza, cada vez más corto. Es tan corto este intervalo de tiempo que a cada interacción avanza cada vez menos sin llegar nunca a sobrepasar el tiempo de intercepción entre ambos contrincantes.

Es decir, por la forma en la que se formula el problema estamos acercándonos infinitamente, pero sin sobrepasarlo, al instante en que Aquiles alcanza a la tortuga, momento a partir del cual Aquiles ganaría la carrera. En los infinitamente pequeños instantes anteriores a ese momento la tortuga puede estar orgullosa de estar ganando infinitamente a Aquiles. Sin embargo, no lo hará eternamente y la demostración (como apunta por ejemplo Xataka Ciencia) vino de manos de Leibniz, ya que con el Cálculo Infinitesimal se comprobó que existen series de infinitos términos que converge a un resultado finito.

En la Asociación Española de Comunicación Científica podéis encontrar un cálculo detallado donde se demuestra que la serie de los intervalos de tiempo cada vez más pequeños que necesita Aquiles para alcanzar a la tortuga convergen a un número finito, por lo que en un tiempo finito (el tiempo de intercepción), Aquiles sobrepasa a la tortuga.

Ahora vamos a jugar un poco con Octave (podéis descargaros el script de aquí). Supongamos que Aquiles alcanzó el récord de Usain Bolt, corriendo a unos 45 Km/h. Su contrincante, no podría ser menos, por lo que escogeremos a Bertie, la Usain Bolt de las tortugas, con sus casi 5 metros y medio en 20 segundos y vamos a darle una ventaja de 10 metros.

(Pincha para agrandar)

¡Vaya!, contra todo pronóstico, parece que esta vez vuelve a ganar Aquiles. De hecho la veloz Bertie a penas ha recorrido 23 cm cuando Aquiles le da una buena pasada. De las gráficas de arriba, la segunda muestra este acercamiento "al estilo Zenón", y cómo converge cerca de los 10,229 m (las cruces rojas, que marcan la posición de Aquiles, y las azules, que marcan la de la tortuga, cada vez están más cerca entre sí y más cerca al punto de intercepción, pero sin sobrepasarlo).

La tabla de tiempos es clara: Aquiles gana pasados los 0,818313 s (a los 10,229 m). Sin embargo, antes de ese momento, es cierto que la tortuga está ganando infinitamente (llegando un momento en el que la diferencia entre ambos es tan pequeña que es indistinguible de cero para el ordenador):

Espero que con esto haya arrojado algo de luz al problema y tranquilizado las inquietudes de los que sentían tambalearse los pilares de la ciencia con estas afirmaciones.

Time Fracture

Qué encontrarás en esta entrada?

• Viajes en el tiempo en la Ciencia Ficción.
• Viajes en el tiempo en la ciencia.

El otro día mi hermano y yo estuvimos discutiendo sobre la ciencia en la ciencia ficción, y más concretamente sobre un apartado específico de la Avengers: Endgame, por lo que antes de continuar:

AVISO DE SPOILER

En realidad no tengo mucho interés en desvelar spoilers de la película, pero puede que al poner en contexto el problema haga referencia a algo que no quiera saber alguien que no haya visto aún la película.

Antes de nada aclarar que me voy a poner un poco pedante con los viajes en el tiempo, pese a que, hasta que no se desvele la ciencia real que pudiese sostenerlos (si es que esto ocurre en algún momento), realmente este tipo de discusiones no tienen demasiado sentido y son meramente especulativas.

Allá vamos: los viajes en el tiempo. Un tema apasionante en la ciencia ficción. Los pudimos ver en Regreso al Futuro, Terminator, Donnie Darko, Doctor Who, Futurama, Future Man, El Ministerio del Tiempo y un larguísimo etcétera.

El detonante del debate fue el vídeo de QuantumFracture "La Física Cuántica de Avengers Endgame". La verdad es que me gustó mucho ese análisis, y creo que explica muy bien la primera parte de los viajes en el tiempo en la ciencia ficción, pero no estoy de acuerdo con la solución que da al final para parchear el gran fallo de guión que para mi es el último cameo del Capitán América.

Cada película o serie de las nombradas más arriba, y cada una de las muchas otras que hay, tienen sus propias reglas para los viajes en el tiempo, y es que, hoy por hoy, el viaje en el tiempo es ciencia ficción y no sabemos si podrá quitarse algún día su apellido para quedarse sólo en "ciencia". Lo que pedimos es que las obras sean coherentes con el conjunto de reglas que proponen, y en mi opinión Endgame no lo es, y no hay forma de salvarla.

Todas estas reglas suelen agruparse en dos posibilidades, que se explican perfectamente en el vídeo de QuantumFracture, por lo que no ahondaré mucho en ello:

• Retroceso sobre la misma línea temporal: sólo existe una línea temporal, si viajamos al pasado, cualquier cambio que hagamos allá tendrá consecuencias impredecibles en el futuro (mayores contra más atrás). Esto hace que sea una perfecta máquina de crear paradojas (ya que pisar una planta en el Cretácico podría alterar la evolución humana y tu propia existencia, haciendo que no pudieses iniciar nunca tu viaje). Para resolver estas paradojas sólo hay dos soluciones: que no tengamos ninguna capacidad para cambiar absolutamente nada (el único viaje posible es aquel que deja el momento del salto intacto), o pasar a las múltiples líneas temporales.

(click para ampliar)

 

• Múltiples líneas temporales: es la forma más fácil de resolver estas paradojas. El simple hecho de viajar al pasado bifurca las líneas de tiempo. A partir de ese instante todo es impredecible, debemos escribir el futuro con cada una de nuestras decisiones, y no importa que este "nuevo futuro" se parezca o no a aquel del cual vinimos, ya que el futuro del que procedíamos realmente fue nuestro pasado en otra línea temporal, y lo que hagamos nosotros a partir de ahora no tiene ningún tipo de relación causal con él. Parece un trabalenguas porque estamos acostumbrados a recorrer el tiempo siempre en la misma dirección, pero es como si alguien fuese de Madrid a Barcelona, y años más tarde regresase. Un punto de vista (más propio de alguien que haya estado en Madrid) es que el viajero regresa al origen. Para el viajero, en este viaje de vuelta, su origen era Barcelona y Madrid era realmente su nuevo destino. Igualmente, el hecho de viajar al pasado es el futuro del viajero que decidió emprender ese viaje, y lo que ocurra a partir de ahí, no puede cambiar su pasado (que en parte será "pasado" para todos, y en parte será "futuro" para todos menos el viajero).

(click para ampliar)

¿Qué pasó en Endgame? Pues después de insistir mucho en esta segunda línea, en la que no se puede cambiar lo que ya ha sucedido, que el pasado, pasado está, el Capitán América viaja al pasado y se queda allí apareciendo como un viejete al final de la película. Es decir, hay causalidad dentro de la misma línea temporal: el Capitán América toma una decisión en su viaje al pasado (quedarse allí) que tiene consecuencias en la línea temporal de la que parte. Esto descuadra toda la película (para mi fue bastante decepcionante), en la que los protagonistas han estado alterando todo el pasado sin preocupación porque eran líneas distintas que no tendrían consecuencias en la línea original.

¿Cómo lo intenta salvar QuantumFracture? Pues incluyendo infinitas líneas temporales simultáneas, de manera que el Capitán América que vemos, no sea el de nuestra línea temporal, sino el de otra línea en la que ha tomado la misma decisión que en la nuestra.

(click para ampliar)

Sin embargo, yo creo que esta teoría está un poco cogida con pinzas. Hay dos alternativas:

• Líneas de tiempo coincidentes: sería el hecho de que al viajar al pasado se bifurcase la línea temporal, pero que esta nueva línea temporal coincidiese con una preexistente. Esto tiene problemas de causalidad, porque si la línea preexistía para todo rango de tiempo, y se añade un viajero, este viajero provocará por el simple hecho de haber llegado cambios que afectarán a los momentos posteriores a su llegada, incluyendo a las circunstancias del salto, pudiendo modificar la trama de la película. No sería una paradoja porque este Capitán América no vendría del salto de la línea temporal en la que se encuentra actualmente, sino que vendría de una línea paralela, pero podría haber tomado medidas contra Thanos o las gemas, por ejemplo, y la historia hubiese cambiado, con lo que no ocurrirían los hechos de la película. Los personajes de la película, que estaban viviendo a lo largo de la línea temporal preexistente, serían alcanzados por una propagación de cambios que modificaría sus recuerdos y podría matar o revivir a personajes. La única forma de que la película siguiese teniendo validez, tal y como la vimos, y no se reescribiera a la llegada del Capitán América, es que éste no haya alterado nada del momento del salto original. Es difícil creer que el Capitán América, con su moral, se mantenga alejado de los conflictos, y también lo es creer que, participando en ellos, haya sido indetectable para todos, especialmente si tenemos en cuenta que ha dado a entender que ha llevado una tranquila vida de pareja con la que era una de las agentes que perseguía más activamente a Hydra.

(click para ampliar)

• Nuevas líneas temporales: para mi tiene mucho más sentido que el hecho de viajar en el tiempo genere una nueva línea temporal. El futuro del viajero no está escrito. Antes del salto no había nada ahí, no existía ni bifurcación ni futuro, el futuro se va escribiendo a partir de la llegada del viajero. Eso significa que todas las películas que hemos visto de Marvel a partir del momento en el que el Capitán América llega al pasado y decide quedarse, han trascurrido en la línea de tiempo generada por el viaje de éste. No hay paradoja porque el Capitán América de la línea de tiempo paralela ya estaba aquí desde el principio: no conocemos cómo hubiese sido nuestro presente sin él, pero lo que sabemos es que con él el presente es el mostrado en las películas, pese a que en ellas nadie supiera de su regreso (nos encontramos de nuevo con la inverosimilitud de que pase desapercibido).

(click para ampliar)

En cualquier caso, el salto a líneas de tiempo arbitrarias, sin la posibilidad de seleccionarlas (ya que hay infinitas y el mismo hecho de saltar crea continuamente más), produce problemas como el del diagrama de arriba. Los viajes en el tiempo con múltiples líneas temporales son sólo de ida, nunca se puede regresar al punto exacto inicial del que partiste, y las personas que te acompañan son como "copias" de las que conociste, con un pasado común pero con nuevas vías de desarrollo.

Por último quería sólo mencionaros las Curvas Cerradas de tipo Tiempo, que para muchos es la forma científica de abordar realmente el viaje temporal. De lo que puedo leer en Wikipedia (no penséis que me acuerdo de algo de esto, lo mismo meto algún gazapo), está relacionado con la distorsión gravitacional, y matemáticamente son soluciones plausibles de las ecuaciones de campo de Einstein dentro de la Relatividad General.

Quién sabe, quizás la máquina del tiempo esté más próxima de lo que creemos. Aunque yo agradecería primero el teletransporte, para tardar menos en llegar al curro.