Estructura de álgebra de Boole

En una entrada anterior publicada hace más de 4 años, en primer lugar se explicaba cómo simplificar expresiones booleanas en nuestro código a partir de las propiedades fundamentales o axiomas del álgebra de Boole y de sus propiedades derivadas, así como a partir del complemento de una función booleana. Finalmente, se añadía una nota en la que se comentaba la similitud entre el álgebra de Boole, la lógica de primer orden y la teoría básica de conjuntos (la formulada por Georg Cantor). Con el presente artículo se pretender dar orden y exponer correctamente el porqué de está relación que se dejó caer en forma de una breve nota.

En su breve obra titulada «El análisis matemático de la lógica» publicada en 1847, el matemático británico autodidacta George Boole tuvo la originalidad de utilizar las técnicas algebraicas para tratar expresiones de la lógica. En su sistema se definen unas operaciones sobre unas variables abstractas que tienen que cumplir unas propiedades, de forma similar a como en el álgebra de las fracciones se definen las operaciones de suma, resta, multiplicación y división y deben cumplir unas determinadas propiedades. Con esta obra puso fin a la lógica aristotélica e inició la lógica formal matemática contemporánea.

No obstante, no fue hasta 1860 que en los trabajos del también británico economista y lógico William Jevons y el filósofo, lógico y matemático norteamericano Charles Sanders Peirce apareció el concepto más general de álgebra de Boole. Un álgebra de Boole es una estructura algebraica, es decir, consta de un conjunto no vacío de elementos y un conjunto no vacío de operaciones sobre dicho conjunto. Además, una estructura algebraica es axiomática, es decir, debe cumplir una serie de propiedades.

William Jevons

William Jevons, principalmente conocido por la paradoja de Jevons.

Sigue leyendo

La simplificación de la complejidad de la arquitectura de las aplicaciones web

La nueva generación de javascripters cree que inventó justo ayer la programación web, pero resulta que hace 25 años ya se libraba la misma batalla que libran ahora, sólo que exclusivamente con LAMP. A Docker y Kubernetes no se llegó precisamente de sopetón… La solución a los problemas fue aumentar la complejidad, lo que a su vez creó nuevos problemas, esta situación y su evolución se describe en este breve artículo de Ben Johnson de lectura muy recomendable.

Asimismo, propone una solución en la que se deshace gran parte de la complejidad añadida durante más de 2 décadas. Esta solución consiste en aumentar la capacidad de un servidor en vez de aumentar el número de los mismos y emplear… ¡el denostado SQLite! (Al menos denostado para las aplicaciones web) Hoy en día Amazon, a través de AWS, ofrece servidores con 96 núcleos y cientos de gigas de RAM. En un servidor bastante más grande, pero dentro de lo que puede administrar un kernel de Linux, se ha conseguido con SQLite la friolera de 4 millones de consultas SQL por segundo con un solo hilo.

El inconveniente de SQLite, es que a diferencia de los sistemas gestores de bases de datos relacionales como MySQL u Oracle, no tiene capacidades de red, con lo que no hay replicación de los datos a otros servidores, entre otros inconvenientes, por lo que si el servidor revienta, se perdieron los datos desde la última copia de seguridad realizada. Para solucionar este problema, Ben ha creado Litestream, una herramienta que se encarga de replicar continuamente una base de datos SQLite en un Amazon S3 (un servicio de almacenamiento en la nube).

Curiosa e interesante iniciativa, que lleva el principio KISS (Keep it simple, stupid!) al extremo. A ver cómo evoluciona…

Difícilmente habrá inmunización cuando empiece el verano

En los últimos meses se ha vendido la esperanza de que una vez llegue la vacuna esta pandemia será historia, a más tardar llegado el verano, pero esta idea parece que no pasa de las buenas intenciones si hacemos un elemental cálculo matemático. A continuación, se verá el caso concreto de España pero fácilmente podrá el lector extrapolarlo a su país.

vacunas covid-19 Sigue leyendo

¿Qué representa el producto escalar?

En un artículo anterior acerca del producto escalar, se explicó detalladamente cómo se define matemáticamente esta operación. En la presente entrada se explicará qué representa realmente esta operación entre dos vectores, la noción «intuitiva» del mismo; algo imprescindible para entender qué estamos calculando realmente en otras ciencias (por ejemplo física) cuando es empleado.

Dados dos vectores, desde un punto de vista estrictamente matemático podríamos definir infinitas operaciones con ellos, por ejemplo el «producto payaso» de los vectores de n dimensiones u y v, se denota mediante u 🤡 v y se define así:

u 🤡 v = (u1·vn·|u|, u2·vn-1·|v|, u3·vn-2·|u|, …, un·v1·|v|)

Donde las coordenadas impares se multiplican por |u| y las pares por |v|.

Entonces, ¿por qué la operación conocida como producto escalar es importante? Un profesor de matemáticas podría responder a esta pregunta de sus alumnos afirmando que entenderán su importancia en la asignatura de física, donde es muy usado, pues tal vez en matemáticas no tenga un valor especial, pero esta respuesta es un tanto esquiva. La razón por la que es importante en física es precisamente por su interpretación geométrica (ergo matemática), pero esta sistemáticamente se omite, de manera que en física los alumnos deben resignarse a aplicarlo ciegamente.

La explicación a grosso modo no debería rehuirse pues no es ningún concepto especialmente complejo ni requiere de matemáticas «superiores»: el producto escalar de dos vectores, u·v, expresa «cuánto» de u «descansa» en la dirección de v, escalado al tamaño de v. (Esto ya se expresó sucintamente en el artículo anterior) Una vez expuesto esto, resulta mucho más intuitivo entender porqué en física se emplea para:

El trabajo

En la mítica representación del trabajo en Bachillerato:

trabajo en fisica

Sigue leyendo

Evolución de casos de coronavirus en España

En la anterior entrada estimé el crecimiento de casos en España a partir de un titular de un diario, en el presente se pretende hacer una estimación mejor fundamentada. En todo caso, ni en el anterior ni en el presente artículo estoy haciendo nada más que un pasatiempo, sin mayores pretensiones. Una vez aclarado que para cualquier estudio serio del tema deben consultarse fuentes oficiales, podemos empezar. En primer lugar, vamos a trabajar con los datos que proporciona el Ministerio de Sanidad del Gobierno de España:

Fecha Día Casos Ln(Casos)
24/02/20 1 4 1,3862943611
25/02/20 2 8 2,0794415417
26/02/20 3 14 2,6390573296
27/02/20 4 26 3,258096538
28/02/20 5 45 3,8066624898
29/02/20 6 59 4,0775374439
01/03/20 7 84 4,4308167988
02/03/20 8 125 4,8283137373
03/03/20 9 169 5,1298987149
04/03/20 10 228 5,429345629
05/03/20 11 282 5,6419070709
06/03/20 12 365 5,8998973536
07/03/20 13 430 6,0637852087
08/03/20 14 674 6,5132301109
09/03/20 15 1231 7,1155821262
10/03/20 16 1695 7,4354380198
11/03/20 17 2277 7,7306140661
12/03/20 18 3146 8,0538870836
13/03/20 19 5232 8,5625488931
14/03/20 20 6332 8,753371421
15/03/20 21 7844 8,9675041873
16/03/20 22 9942 9,2045234867
17/03/20 23 11178 9,3217028398
18/03/20 24 14769 9,6002856684
19/03/20 25 18077 9,802395691
20/03/20 26 20410 9,9237802558
21/03/20 27 25374 10,1414803067
22/03/20 28 28768 10,2670189373
23/03/20 29 33089 10,4069561798

Las columnas «Fecha» y «Casos» son los datos oficiales, mientras que las columnas «Día» y «Ln(Casos)» se han añadido para realizar las estimaciones. Desde los medios de comunicación se repite que el crecimiento es exponencial, algo que podemos comprobar que es cierto si hacemos una representación gráfica a partir de los datos de la tabla:

casos coronavirus españa

(1)

Sigue leyendo