August 15, 2008 at 14:08 · Filed under Estructuras de datos, Python
Las listas son un tipo de objeto mutable de Python. Por mutable, en Python se entiende que el objeto es modificable una vez definido, por ejemplo:
>>> a=[1,2]
(definimos la lista a con dos elementos)
>>> a.append(3)
(añadimos otro elemento)
>>> a
[1, 2, 3]
A diferencia de las tuplas, que no son modificables:
>>> b=(1,2)
(definimos la tupla b, que se quedará así por los siglos de los siglos…)
>>> b=None
(…o hasta que pase el recolector de basura)
Las listas por ser mutables tienen definidas unas operaciones sobre ellas de las que las tuplas carecen, por ejemplo el método append(<elemento>) que se ha visto antes, o por ejemplo los siguientes métodos:
>>> c=["a","b","c"]
>>> c
['a', 'b', 'c']
>>> c.insert(0,”d”)
>>> c
['d', 'a', 'b', 'c']
>>> c.insert(2,”e”)
>>> c
['d', 'a', 'e', 'b', 'c']
>>> c.pop()
‘c’
>>> c
['d', 'a', 'e', 'b']
>>>
Como se puede apreciar pop() toma el último elemento (, o c[len(c)-1], como se prefiera), lo saca de la lista (la lista se queda sin ese valor) y nos lo devuelve. Junto con append() es lo justo para crear una pila:
>>> pila=[]
(creamos la pila, vacía)
>>> pila.pop()
(sacamos datos de una pila vacía, y nos dan una excepción)
Traceback (most recent call last):
File “<stdin>”, line 1, in ?
IndexError: pop from empty list
>>> pila.append(1)
(añadimos datos a la pila)
>>> pila.append(2)
>>> pila.append(3)
>>> pila
[1, 2, 3]
>>> while pila:
… print “Ultimo elemento de la pila: %d (pila: %s)” % (pila.pop(),pila)…
Ultimo elemento de la pila: 3 (pila: [1, 2])
Ultimo elemento de la pila: 2 (pila: [1])
Ultimo elemento de la pila: 1 (pila: [])
>>>
El otro método utilizado era insert(<posición>,<elemento>), que como creo que cabe esperar realiza este comportamiento:
>>> lista=[]
(creamos la lista)
>>> lista.insert(1,”a”)
(insertamos en la posición 1, pero como está vacía realmente queda en la posición lista[0])
>>> lista
['a']
>>> lista.insert(5,”a”)
(insertamos en la posición 5, pero como está vacía realmente queda en la posición lista[1])
>>> lista
['a', 'a']
>>> lista.insert(0,”b”)
(insertamos al principio)
>>> lista
['b', 'a', 'a']
>>> lista.insert(-1,”c”)
(insertamos justo antes de la última posición)
>>> lista
['b', 'a', 'c', 'a']
>>> lista.insert(-2,”d”)
(insertamos en la antepenúltima posición)
>>> lista
['b', 'a', 'd', 'c', 'a']
>>>
¿Y para insertar en la última posición? lista.append(‘u’), mismamente:
>>> lista.append(‘u’)
>>> lista
['b', 'a', 'd', 'c', 'a', 'u']
>>>
Ahora ya crear una cola es coser y cantar, a base de insert(0,<elemento>) y pop():
>>> cola=[]
(crear la cola)
>>> cola.pop()
(sacar de una cola vacía nos da una excepción
IndexError
, como en la pila)
Traceback (most recent call last):
File “<stdin>”, line 1, in ?
IndexError: pop from empty list
>>> cola.insert(0,”1″) (
introducimos datos)
>>> cola.insert(0,”2″)
>>> cola.insert(0,”3″)
>>> cola
['3', '2', '1']
>>> while cola:
(y vamos sacando…)
… print “Cabeza de la cola: %c (cola: %s)” % (cola.pop(),cola)
…
Cabeza de la cola: 1 (cola: ['3', '2'])
Cabeza de la cola: 2 (cola: ['3'])
Cabeza de la cola: 3 (cola: [])
>>>
¿Cuánto tiempo nos podemos ahorrar por programarlo en Python en vez de en C?
Aunque también es mucho más ineficiente ejecutarlo en Python que en C, pero normalmente es preferible ahorrar tiempo de programación que tiempo de ejecución: mi tiempo es importante, el del microprocesador no tanto.
August 12, 2008 at 18:26 · Filed under Python
Necesitaba parsear ficheros Makefile desde Python, y buscando… me cuesta encontrar cosas.
- Makefile::Parser, en Perl, parsea Makefiles, pero no soporta toda la gramática, y está en pre-alpha. Además es en Perl y no en Python, y para prototipar no hay problema, pero para sacar algo más sólido me deja un poco “descubierto”.
- Makefile::Parser::GmakeDB ejecuta make, y toma la base de datos que genera este comando (primera noticia de que hace esto, aunque si le quitamos los comentarios la base de datos es como un Makefile, pero ampliado). Parece estar más maduro que el anterior, aunque eso de requerir de un comando externo me sigue pareciendo un poco cojo.
- Makefile::AST parte también del análisis de tal base de datos para generar ASTs (Abstract Syntax Trees).
- Y Makefile::DOM genera árboles DOM a partir del fichero entero (cabía esperarse ésto, ¿no?).
¿Y qué tal si nos hacemos con la gramática y luego generamos un parser vía bison (o similares)? La gramática de los Makefiles no la encuentro, y eso que he visto varios mensajes en diferentes listas de correo solicitando el BNF de la gramática, así que tocará ir abriendo boca con un subconjunto de la gramática, y luego ya se irá ampliando si es preciso (gracias al manual de GNU Make).
Generadores de parsers en Python ando buscando, así que ya escribiré qué es lo que he encontrado.
Y por último mencionar SCons, que sigue la misma idea de make, pero está hecho sobre Python y usa la sintaxis de Python (ejemplos). En mi opinión, es poco práctico usar esa sintaxis para un Makefile (¿exceso de costumbre con los makes? ¿falta de bregaje con makes complicados?), pero desde luego le da la potencia de Python al script de compilación.
August 2, 2008 at 13:19 · Filed under Linux, Vision artificial
Michel Xhaard hace algún tiempo se hizo famoso por haber escrito los drivers para Linux para más de 200 webcams.
Michel, que tiene algo más de 60 años, es un médico francés que está especializado en procesar imágenes de ultrasonidos. En cuestión de cuatro años fue capaz de desarrollar drivers para múltiples webcams, inicialmente empezó para el chipset Sunplus SPCA y ahora cubre muchos más, principalmente a base de reutilizar el código de unos drivers en otros.
Las cámaras con los chipsets soportados por la familia SPCA son de múltiples fabricantes y modelos.
El caso de Michel no es el único caso de un médico que tiene como pasatiempos la informática: Con Kolivas es anestesista y ha hecho importantes desarrollos para el kernel de Linux.
August 2, 2008 at 12:36 · Filed under Linux, Vision artificial
El soporte para webcams en Linux es una de las materias que aún quedan pendientes para que Linux esté tan cerca del usuario doméstico como lo están Windows o MacOS X.
Philips destaca por fabricar buenas cámaras con buenos sensores, siendo uno de los proveedores de Logitech — así que al comprar Logitech realmente gran parte de las piezas importantes son Philips en muchos modelos (que no en todos). Hasta la fecha en Linux gran parte de las cámaras Philips estaban soportadas por el driver PWC. Este driver tiene dos partes, el PWC propiamente dicho, que es código abierto y está dentro del kernel, y el PWCX que es una parte binaria que opera fuera del kernel (obviamente, por temas de licencia) e interactúa con el PWC a través de un hook.
El código del PWCX es algo que Philips quiere mantener escondido, por lo que al desarrollador inicial del PWC (Nemosoft Unv) Philips le obligó a firmar un NDA (Non-Disclosure Agreement) con caducidad a los tres años –ya vencidos, aunque aún no ha desvelado nada. La inclusión de esta parte binaria es lo que hizo que el equipo del kernel Linux se empeñara en no incluir el PWC como parte del kernel, por lo que Nemosoft Unv al final decidió dejar el desarrollo. En definitiva, este código lo que permitía era hacer una descompresión del flujo de datos recibido para así poder trabajar con resoluciones altas (640×480).
Actualmente Luc Saillard ha retomado el desarrollo principalmente para el kernel 2.6, y permite hacer esa descompresión para gran resolución sin necesidad de parte binaria.
