No existe (que yo sepa) un modo de aumentar el tamaño del array de bits de un filtro Bloom una vez que ya se han empezado a añadir elementos. El modo de implementar un filtro escalable no es ni más ni menos que utilizar más de un filtro a la vez.

Para ello, cada vez que un filtro se llena se crea uno nuevo de mayor capacidad. Los nuevos elementos se van añadiendo al último filtro creado y a la hora de buscar un elemento se busca en todos uno por uno.

La base del filtro escalable es por tanto muy sencilla. La mayor complicación sería escoger el modo de escalar la capacidad de los filtros, es decir, cómo de grande debe ser el nuevo en comparación con el anterior. En su momento me vino a la cabeza la posibilidad de que todos tengan el mismo tamaño e incluso de que fuesen cada vez más pequeños, pero hasta la fecha no se me ha ocurrido ningún extraño caso en el que pueda resultar útil.

Lo normal es utilizar una función lineal o exponencial. Yo he optado por permitir ambas ya que no era ningún esfuerzo pero en la práctica siempre me ha venido mejor la exponencial. Los cálculos son muy sencillos:

# initial_capacity = capacidad del primer filtro
# scale_factor = factor de aumento
# filters = array de filtros, len(filters) es el número de filtros que ya haya
# Función lineal:
capacity = int(initial_capacity * (scale_factor * len(filters)))
# Función exponencial:
capacity = int(initial_capacity * (scale_factor ** len(filters)))

Añadir y buscar elementos también es muy sencillo:

def add(element):
    if filters[-1].is_full():
        # En el ejemplo del artículo anterior, el filtro se creaba pasando como parámetros la capacidad y el margen de error.
        filters.append(BloomFilter(calc_next_capacity(), error_rate))
    filters[-1].add(element)
#
def lookup(string):
    for f in reversed(filters):
        if f.lookup(string): return True
    return False

Lo único destacable es que al buscar es más eficiente recorrer los filtros en orden inverso (del último al primero), ya que de media se tardará menos en encontrar el elemento. Aunque en caso de no encontrarse la búsqueda tardará lo mismo se haga en un sentido u otro.

El código completo comentado se puede ver en Google Code.

Cuando sabes lo que buscas es muy fácil fabricar un listado de URLs que necesitas revisar. Puede incluso ser una sola URL. Sin embargo, cuando necesitas ir detectando sobre la marcha nuevas URLs tienes que guardar un registro de las que ya has visitado. De lo contrario te encontrarás visitando las mismas páginas enlazadas entre sí una y otra vez hasta el fin de los tiempos.

Si sabemos que serán pocas las URLs a visitar, esto no es un gran problema. Simplemente nos guardamos una lista de las que vamos visitando y nos aseguramos de no repetir. El problema está cuando nos enfrentamos a sitios web muy grandes de los que necesitamos revisar una gran cantidad de páginas. Entonces eso de tener la lista de URLs en memoria se convierte rápidamente en una mala idea.

En estos casos, si las URLs en sí son relevantes (es decir, si cada URL es un dato que necesitas guardar por alguna otra razón) seguramente necesites una base de datos. Pero si lo único que necesitas saber es si ya has visitado antes una URL, los filtros Bloom son una opción increíblemente eficiente y rápida.

Bonita historia, pero ¿qué es un filtro Bloom?

No lo voy a explicar en profundidad ya que aparece muy bien explicado en la Wikipedia (inglés), incluyendo muchas referencias interesantes al final del artículo. De modo que comentaré lo más importante.

Las características principales de los filtros Bloom son las siguientes:

• Tiene un cierto margen de error (falsos positivos), calculable y ajustable.
• Al buscar un elemento, un resultado negativo significa que con toda seguridad no está en la lista.
• Un resultado positivo significa que un elemento probablemente está en la lista (debido a la posibilidad de falsos positivos).
• Requiere muy poco espacio en memoria y las consultas son muy rápidas.

El funcionamiento es muy sencillo, para implementarlo necesitaremos:

• Encontrar una implementación ya realizada que nos guste (nos parezca apropiada) y podamos utilizar (licencia), en cuyo caso ya habremos terminado :D.

o

• Una lista de elementos binarios (bit array).
• Una o más funciones de hashing.

En mi caso necesitaba una implementación en Python ya que es el lenguaje que suelo utilizar para las tareas de scraping. La implementación de pybloom la verdad es que no me gustó nada y no encontré ninguna otra que me sirviese. De modo que opté por hacerme la mía.

La elección de la función de hashing es muy importante. El requisito indispensable es que sea uniforme (todos los posibles valores tienen la misma probabilidad de aparecer como resultado) y determinista (un mismo valor de entrada genera siempre el mismo valor de resultado). También es importante, aunque no imprescindible, que sea no criptográfica. Las funciones de hashing criptográficas están muy bien para otros usos, pero son más lentas (este es uno de los principales inconvenientes que le veo a pybloom). No soy ningún experto en hashing, pero leyendo un poco la que más me convence por el momento es MurmurHash3.

Resumiendo, para la implementación en Python utilicé lo siguiente:

# Requiere instalar previamente bitarray y mmh3 (murmurhash3)
# sudo pip install bitarray
# sudo pip install mmh3

from bitarray import bitarray
import mmh3
from math import log, ceil

Añadir un elemento al filtro:

Para añadir un elemento realizaremos varios hashes del mismo. Se pueden utilizar distintas funciones de hashing o una sola función con diferentes semillas. Teniendo ya una función que me gusta y sin saber cuántos hashes diferentes voy a necesitar, me parece más lógico utilizar una sola con diferentes semillas:

# hash_count = número de hashes a realizar.
# size = tamaño del bitarray.
for seed in xrange(hash_count):
	position = mmh3.hash(element, seed) % size
	bit_array[position] = 1
element_count += 1

Los hashes mmh3 son numéricos, de modo que se pueden ajustar al tamaño del bitarray calculando el “módulo” (resto de división) con el operador “%”. El resultado es la posición del bitarray que marcamos a 1.

Buscar un elemento en el filtro:

Buscar un elemento en el filtro es muy parecido, simplemente comprobamos las posiciones que corresponderían al elemento que estamos buscando.

# hash_count = número de hashes a realizar.
# size = tamaño del bitarray.
for seed in xrange(self.hash_count):
	position = mmh3.hash(element, seed) % self.size
	if self.bit_array[position] == 0:
		return False
return True

Imagen extraída de la Wikipedia, donde se muestra la idea básica de un filtro Bloom utilizando 3 hashes para cada elemento.

El tamaño del bitarray y el número de hashes:

La mayoría de implementaciones que encontré eran clases cuyo constructor recibía como parámetros el tamaño del bitarray y el número de hashes a utilizar. Aunque se puede utilizar de esta manera, en la práctica creo que es mucho más cómodo especificar lo que realmente me importa: el número de elementos que quiero guardar y el margen de error que estoy dispuesto a permitir.

Para esto es necesario calcular el tamaño del bitarray y el número de hashes necesarios para poder almacenar el número de elementos que queremos con un margen de error menor o igual al especificado. Las fórmulas y su explicación se pueden ver también en la Wikipedia, pero escritas en Python serían algo así:

# capacity = número de elementos a guardar.
# error_rate = tasa de error, entre 0 (0%) y 1 (100%). Por ejemplo, 0.01 sería un 1%.
def calc_size():
	return int(ceil(- (float(capacity) * log(float(error_rate))) / (log(2))**2))

# Para calcular el número de hashes tenemos que haber calculado primero el tamaño del bitarray.
# size = tamaño del bitarray.
def calc_hash_count():
	return int(ceil((float(size) / float(capacity)) * log(2)))

Utilizo la función “ceil” para asegurarme de que se cumplen los requisitos (redondeando hacia arriba).

Uniones e intersecciones:

Algo que no he visto hasta la fecha en ninguna implementación de filtros Bloom, al menos en Python, son las operaciones de unión e intersección entre dos filtros (desde el punto de vista de teoría de conjuntos). Son increíblemente fáciles de implementar y en concreto la unión de filtros me ha resultado bastante útil.

Las intersecciones también pueden ser útiles, pero en mi caso (pocos o ningún elemento en común) los resultados no me han parecido lo bastante fiables.

Más abajo en el código final de la clase se puede ver la implementación de estas dos operaciones, pero es tan sencillo como realizar las operaciones a nivel de bit AND (&) y OR (|) entre los dos bitarray.

Mi implementación:

Esta es la clase que me hice. No es la que uso actualmente ya que más tarde hice un filtro Bloom escalable, más avanzado, que detallaré en otro artículo ya que este me está quedando más grande de lo que esperaba.

Los filtros Bloom tienen una infinidad de utilidades. Cabe destacar que esta clase fue creada específicamente para cubrir mis necesidades, por lo que hay algunas decisiones de implementación (como permitir añadir más elementos aunque el filtro esté al máximo de capacidad o devolver un valor vacío si no se puede realizar una unión) que pueden no ser buenas en otros contextos.

#!/usr/bin/python
# -*- coding: utf-8 -*-
#

# Requires bitarray and mmh3 (murmurhash3)
# sudo pip install bitarray
# sudo pip install mmh3

from bitarray import bitarray
import mmh3
from math import log, ceil

class BloomFilter:

        def __init__(self, capacity, error_rate):
                if not capacity > 0: raise ValueError("capacity must be > 0")
                if not (0 < error_rate < 1): raise ValueError("error_rate must be between 0 and 1.")
capacity.
                self.capacity = capacity
                self.element_count = 0
                self.error_rate = error_rate
                self.size = self.calc_size()
                self.hash_count = self.calc_hash_count()
                self.bit_array = bitarray(self.size)
                self.bit_array.setall(0)

        def add(self, element):
                for seed in xrange(self.hash_count):
                        position = mmh3.hash(element, seed) % self.size
                        self.bit_array[position] = 1
                self.element_count += 1

        def lookup(self, element):
                for seed in xrange(self.hash_count):
                        position = mmh3.hash(element, seed) % self.size
                        if self.bit_array[position] == 0:
                                return False
                return True

        def union(self, b):
                if self.size != b.size: return None
                if self.hash_count != b.hash_count: return None
                result = BloomFilter(self.capacity, self.error_rate)
                result.bit_array = self.bit_array | b.bit_array
                result.element_count = self.element_count + b.element_count
                return result

        def intersection(self, b):
                if self.size != b.size: return None
                if self.hash_count != b.hash_count: return None
                result = BloomFilter(self.capacity, self.error_rate)
                result.bit_array = self.bit_array & b.bit_array
                result.element_count = result.calc_element_count()
                return result

        def is_full(self):
                if self.element_count < self.capacity: return False
                else: return True

        def calc_size(self):
                return int(ceil(- (float(self.capacity) * log(float(self.error_rate))) / (log(2))**2))

        def calc_hash_count(self):
                return int(ceil((float(self.size) / float(self.capacity)) * log(2)))

        def calc_error_rate(self, use_capacity = False):
                if use_capacity: n = float(self.capacity)
                else: n = float(self.element_count)
                return (1.0 - (1.0 - 1.0 / float(self.size)) ** (float(self.hash_count) * n)) ** float(self.hash_count)

        def calc_element_count(self):
                x = float(self.bit_array.count())
                return int(ceil(- (float(self.size) * log(1.0 - (x / float(self.size)))) / float(self.hash_count)))

        def __contains__(self, string):
                return self.lookup(string)

El código completo comentado, incluyendo la versión escalable, está alojado en Google Code.

Se trata básicamente de crear un controlador para cada jugador y asignarle un personaje. Luego se van asignando eventos de pulsación de teclas (sólo teclas de momento) a funciones que afectarán a dicho personaje.

Sobre la gestión de colisiones…, menudas locuras he estado haciendo, hasta que me dí cuenta de que estaba cometiendo un error que parece ser (por lo que he leído luego en otros sitios) muy típico de novatos en esto de la programación de videojuegos: comprobar la colisión después de haber movido al personaje en lugar de hacerlo antes. En otras palabras, yo me preguntaba “¿ha chocado?” cuando lo que debería preguntarme es “¿chocaría?”. Cuando caí en la cuenta fue muy rápido de implementar.

Como siempre, me queda el consuelo de que no volveré a caer en un error de ese estilo.

Por último, he estado pensando en la cantidad de información que voy a tener que guardar sobre los mapas. Cuando empiece a pensar en un juego “de verdad” tendré que almacenar mucho más que el propio escenario: necesitaré los objetos y personajes no jugadores (NPC’s) que aparezcan en él, las coordenadas donde aparecerán, las acciones que realizarán… En fin, que toca pensar en bases de datos.

Antes creo que voy a tratar de implementar el “scrolling” de los mapas para poder mover a los personajes por mapas que excedan la resolución de la pantalla. Después comenzaré a pensar en el modelo de datos.

La principal diferencia entre los distintos tipos de personajes va a ser el movimiento. De momento voy a distinguir entre el movimiento tipo puzzle (el personaje se mueve tile por tile, no puede parar de moverse entre dos tiles) y el movimiento normal (el personaje se mueve “libremente”, sin la restricción anterior). He comenzado por implementar el movimiento normal ya que el movimiento tipo puzzle será un caso especial de éste.

El problema vendría al realizar juegos de plataformas, en los que el personaje sólo se mueve de izquierda a derecha y además “salta”. Éste caso lo voy a dejar para más adelante, tengo que estudiar cómo implementar el tema de la “gravedad”.

Por otra parte he creado una clase Player para el caso especial del jugador. He hecho algunas pruebas de movimiento, de animación e incluso de cambios de velocidad (para andar y correr, por ejemplo). Ya ayer subí los avances del proyecto. Para la prueba uso las flechas del teclado para mover al personaje y la tecla Z para “correr”.

Lo siguiente que quiero hacer es buscar alguna manera un poco más elegante de implementar el control del personaje y comenzar con la gestión de colisiones.

En principio he pensado en un escenario compuesto por una imagen de fondo y un mapa de tres capas basado en tiles. ¿Por qué tres capas? Pues porque las usaré para representar lo que está por detrás de los personajes, lo que está al mismo nivel y lo que está por delante. Combinado con un fondo creo que se pueden crear mapas decentes para casi cualquier tipo de juego.

En realidad voy a utilizar una cuarta capa para las colisiones con el escenario, que no se dibujará en pantalla ya que servirá para saber por qué partes del escenario no se pueden mover los personajes. Al principio pensé en considerar que el personaje colisionaría con todo lo que estuviese en la capa intermedia (supuestamente a su mismo nivel), pero creo que va a ser útil tenerlo por separado.

Existen bastantes herramientas para generar mapas basados en tiles, como Tile Mapper, Mappy o Tiled. Como no voy a meterme en mapas muy complejos y Tiled me ha gustado bastante, me quedo con él. En su wiki se explica el formato que utiliza y en Razón Artificial hay un buen ejemplo de cómo usarlo, entre otros artículos y tutoriales muy interesantes.

En cuanto al código, ya he subido la primera versión de las clases que gestionarán los mapas. Al proyecto le he llamado Paige y cualquiera queda invitado a colaborar.

Comento brevemente su estructura:

• La clase Map es la que se encarga de cargar los mapas y dibujar en pantalla el fondo y las distintas capas.
• La clase Tileset carga las imágenes de los tileset y las “trocea” para obtener la tabla de tiles individuales, además de dibujar tiles en la pantalla.
• La clase Layer carga las capas del mapa y las dibuja en pantalla.

También he subido unas imágenes y un mapa de prueba para ir viendo los resultados. De momento el mapa debe ser del mismo tamaño que la pantalla, más adelante trataré el tema del “scrolling”. El siguiente paso será el personaje.

Leyendo tanto sobre programación de videojuegos en general como temas más específicos de Python (principalmente pygame) he encontrado tantas cosas que llamaban mi atención que me he saturado. Aún no había resuelto cómo dibujar el escenario y ya me encontraba debatiendo conmigo mismo qué algoritmo de búsqueda de caminos implementar para los enemigos.

Al final he optado por hacer un experimento: voy a desarrollar al mismo tiempo una especie de “motor” y un videojuego, de manera que iré implementando funciones en el motor según las vaya necesitando, aunque trataré de hacerlo lo más general posible de manera que sirva para otros tipos de juegos. Para no partir totalmente de cero voy a basarme en pygame.

Ya he visto algunas cosillas por ahí parecidas a lo que quiero hacer, pero como lo que realmente me interesa es aprender prefiero hacerlo yo mismo desde el principio, aunque investigue cómo lo hacen los demás, claro está. El código del motor lo alojaré en Google Code y aquí iré comentando la experiencia. No tengo intención de hacer una especie de tutorial, sino más bien comentar las dificultades que encuentre, decisiones a las que me enfrente, errores que cometa, etc.