ETIS en la UOC: Asignaturas del pasado semestre

Este es el análisis de la asignatura que hice el semestre pasado en la UOC: Matemàtica Discreta.

El temario de la asignatura se divide en dos partes principales: combinatoria y teoría de grafos. Es un temario bastante extenso y requiere de bastante trabajo para estudiarla y prepara el examen. No hay que confiarse.

La evaluación continua consiste en dos PACs, una sobre cada parte. Son largas, pero te dan mucho tiempo para hacerlas. Mi recomendación es seguir la evaluación continua y hacer las PACs porque son una buena manera de empezar a preparar la asignatura, y porque sacar buena nota en las PACs te ayuda a mejorar la nota final. Otra cosa importante es explicar y razonar muy bien todas tus respuestas en las PACs porque los tutores lo valoran mucho, y te pueden puntuar bien una respuesta aunque te hayas equivocado en algún cálculo o resultado.

Preparar y entender esta asignatura requiere realizar muchos ejercicios y problemas, sobre todo para la parte de combinatoria. En cambio, los problemas de la parte de teoría de grafos me resultaron bastante más sencillos. Lo malo de esta segunda parte es que tiene mucha más teoría, demostraciones y conceptos, que hay que entender y aprender bastante bien, porque al examen final no dejan llevar ningún tipo de formulario.

Existe una colección muy extensa de problemas resueltos de la asignatura, pero a mi no me dio tiempo de mirarla.

Lo que hice para preparar el examen final fue leerme toda la teoría varias veces haciendo los ejercicios y ejemplos de los apuntes, rehacer las PACs (me llevó una tarde lo que la primera vez me llevó semanas), y hacer tantos exámenes de años anteriores como me dio tiempo. Esto último creo que fue muy útil porque las preguntas de los exámenes pueden ser bastante rebuscadas, y te fuerzan a entenderlo todo del derecho y del revés.

Creo que un error que mucha gente comete es no mirarse las ecuaciones recurrentes porque a primera vista parecen complicadas, pero, en mi opinión, son el tipo de problema más sencillo de toda la parte de combinatoria, ya que son muy mecánicos, y practicando puedes asegurarte unos puntos vitales en el examen porque siempre caen.

Los problemas de funciones generadoras también son muy fáciles, siempre que no te pidan calcular los coeficientes. Dado el tiempo que tenía para preparar el examen, decidí arriesgarme y ni siquiera miré la parte del cálculo de coeficientes porque casi nunca cae y son muy laboriosos. Tuve suerte.

En cuanto a los resultados finales estoy muy contento.
A pesar de pasarlo mal en el examen porque me equivoqué en el problema de ecuaciones recurrentes (lo que mejor llevaba), luchando hasta el final pude remontar gracias a los problemas de grafos (lo segundo que mejor llevaba), y, sorprendentemente, a las demostraciones teóricas de grafos (lo que peor llevaba) hasta llegar a un Notable. Después los puntos de la evaluación continua mejoraron la nota final hasta un Excelente.

Sólo tengo una queja. En el examen los responsables de la asignatura pretendían que hiciéramos el examen en una hoja y media (cuando sólo el problema de ecuaciones recurrentes se te llevaba una...). Tuvimos que protestar para que, al final, después de consultar con algún responsable accedieran a dejarnos usar más hojas en las contestaciones. Alucinante...

Bueno, en general, la asignatura me gustó bastante, sobre todo la parte de grafos. La parte de combinatoria también me pareció muy interesante, pero no acabé de entenderla bien del todo.

ETIS en la UOC: Asignaturas del pasado semestre

Hace ya unos meses hablaba del nuevo semestre que comenzaba en ETIS en la UOC. Ahora que terminó el semestre y tengo un poco más de tiempo, llegó el momento de hacer una retrospectiva y de analizar las asignaturas.

De nuevo, tuve que dejar una de las asignaturas, Matemàtica Discreta, porque entre el trabajo y los pet projects que estoy haciendo con @remosu no me dió tiempo de seguirla. Aunque ya en mi anterior retrospectiva había llegado a la conclusión de que mi límite estaba en 15 créditos por semestre, en el último momento me dejé llevar por un impulso y cogí tres asignaturas pensando que podría con todo. Fue un error.

En el lado positivo, este semestre saqué de nuevo matrícula de honor en dos asignaturas. Estas son mis impresiones sobre estas dos asignaturas:

• Teoria d'autòmats i llenguatges formals I
Esta asignatura me la habían recomendado varios compañeros de trabajo, y tenían razón, es muy bonita. Me costó entender algunas partes del temario, y tuve que dedicarle mucho tiempo. Aún habiendo obtenido buenos resultados, creo que todavía no acabo de entender del todo bien algunos conceptos de la asignatura.
El temario de TALF I es bastante corto pero no se la debe subestimar por ello, ya que en ella se ven conceptos que lleva su tiempo entender. Creo que el camino se allana bastante si se consigue aprobar la evaluación contínua porque, en ese caso, el temario que entra en la Prueba de Validación se limita a los temas que entraron en las PACs: aproximadamente un 80% del temario de la asignatura. Ir al examen final es más complicado porque entra el 100% del temario y algunas partes son bastante duras.
Para hacer las PACs usé sólo el material de la asignatura, que es un poco escaso, y un montón de horas. Supongo que si hubiera mirado PACs y/o exámenes de años anteriores me hubiera ayudado. En cada PAC ponía que el tiempo estimado de realización eran tres horas, pero para algún apartado de la segunda PAC (el de gramáticas) me pasé más de 5 horas... No hay que agobiarse porque la cosa mejora con la práctica. Antes de hacer la PV, ya era capaz de resolver rápidamente ejercicios similares a los de las PACs.
Para preparar la PV me lei de nuevo toda la teoria. Este repaso general me sirvió para acabar de entender cosas que no había comprendido bien cuando hice las PACs. Después hice todos los ejercicios de autoevaluación relacionados con los temas que habían salido en las PACs e hice unos cuantos exámenes (sólo los problemas relacionadas con las PACs). Esto me llevó unos tres días y medio (no tenía más).

• Ampliació d'estructura i tecnologia de computadors
  Esta asignatura es la continuación de Estructura i tecnologia de computadors. Tiene dos PACs y dos prácticas, una obligatoria con la que puedes conseguir hasta un 70% de la nota práctica, y otra opcional con la que puedes conseguir lo que falta para el 100%.
  El tema que me fue más útil para el trabajo fue el estudio de la jerarquía de memoria, y en especial de la memoria cache. Los materiales de la asignatura están disponibles en el OCW de la UOC
  Las prácticas consistieron en escribir programas con partes escritas en ensamblador y partes escritas en C. A partir de cosas que aprendí resolviéndolas salieron varios posts de este blog (este, este y este). Si quieres ver el código de las prácticas, está publicado aquí y aquí.
  Los profesores colgaban cada semana ejercicios teóricos y prácticos que había que resolver en unos 5 días. Si uno tiene tiempo, está muy bien hacerlos porque vas desarrollando poco a poco los conocimientos que necesitas para hacer las PACs y las prácticas. Yo no hice ninguno de los ejercicios porque no tuve tiempo, con lo que, luego tuve que hacer las PACs y prácticas a contrarreloj.
  Para preparar el examen, rehice todos los ejercicios de las PACs, hice los ejercicios teóricos semanales y miré algunos exámenes de años anteriores. También repasé la solución oficial de las prácticas.
  La asignatura no es muy difícil, quizás, lo más complicado es cogerle el truco al ensamblador.

Me costó mucho esfuerzo simultanear estas asignaturas con el trabajo, las lecturas técnicas y mis pet projects con @remosu, pero, mirando hacia atrás, creo que valió la pena.

Using the stack to pass parameters between assembly functions

For a new assignment in AETC I have to pass parameters between assembly functions using the stack instead of registers.

I've made a simple test using again the power example (like in previuos posts: [1] and [2]).
In this case, an assembly function called pow_caller, which in turn calls the p_pow function, is being called from C.

This is the calling C code:

#include "stdlib.h"
#include "stdio.h"
#include "assert.h"

extern int pow_caller(int, int);

int main(void) 
{   
  assert(1 == pow_caller(3, 0)); 
  assert(9 == pow_caller(3, 2));
  assert(25 == pow_caller(5, 2));   
  assert(36 == pow_caller(6, 2));   
  assert(27 == pow_caller(3, 3));      
  printf("All tests passed!\n");
  return EXIT_SUCCESS;
}

This code is calling the pow_caller function:

pow_caller:             
  push rbp      ; Store stack initial state
  mov  rbp, rsp   

  sub rsp, 8    ; We make space for p_pow result by
                ; subtracting 8 bytes to the stack 
                ; pointer (RSP)
  push rdi      ; We push the base (b) to the stack
  push rsi      ; We push the exponent (e) to the stack
  
  call p_pow    ; Now we call p_pow
  
  add rsp, 16   ; We make RSP point to the 
                ; position were the result is.
  pop rax       ; And move the result to rax so 
                ; that it's returned to the C program
  
  mov rsp, rbp  ; Restore stack initial state
  pop rbp

  ret

As you can see, pow_caller is passing the parameters (base and exponent) to p_pow using the stack.
Before passing the parameters it's also reserving some space (8 bytes) for the result of p_pow to be returned. That's what sub rsp, 8 is doing, (remember that the stack grows towards decreasing addresses).

Once p_pow finishes, we have to get the result from the stack. To do it we go to the place where the result is by moving the stack pointer RSP (add rsp, 16) and, once there, get the result from the stack moving it to the RAX register (pop rax), so that it's returned to the C program when pow_caller ends.
Before executing add rsp, 16, the result of p_pow was in memory at address rbp+16, but after executing add rsp, 16 it was at address rbp, so it can be reached just using pop.

It's very important to remark that the state of the stack (RSP and RBP) must be the same before and after the function to avoid funny bugs when you go back to the caller.

In pow_caller we've pushed the content of 3 registers (RBP, RDI and RSI) to the stack (24 bytes) and subtracted 8 bytes to store the result of p_pow, that's 32 bytes, so that, $rsp' = $rsp - 32, where $rsp is the content of RSP when entering p_pow_caller and $rsp' is its current value.
After p_pow finished, we added 16 bytes to RSP and then made two pops (another 16 bytes), so at the end $rsp' = $rsp again.
That last pop made also that $rbp' = $rbp again.

It only remains to see how p_pow accesses the stack to get the parameters and store the result.

This is the code of p_pow:

p_pow:
  push rbp
  mov  rbp, rsp    ; Store stack initial state
  push rax                   
  push rbx 
  push rcx
  push rdx  
  
  mov eax, 1       ; Initialize rax  

  ; We move the base (b) from the stack to ebx
  mov ebx, dword[rbp+24]  

  ; We move the exponent (e) from the stack to ecx
  mov ecx, dword[rbp+16]  

  cmp ecx, 0       ; if e==0 -> b^0=1, and we are done
  jle p_pow_end             
  
  p_pow_loop:              
    mul ebx        ; eax*ebx=edx:eax
    dec ecx        ; ecx = ecx - 1
    jg  p_pow_loop ; If ecx > 0 it iterates again
  p_pow_end:

  ; Move the result to the space reserved for it in the stack
  mov [rbp+32], rax      
  
  pop rdx          ; Restore stack initial state
  pop rcx
  pop rbx
  pop rax
  mov rsp, rbp
  pop rbp
  
  ret

Ok, so again the first thing we do is pushing the initial value of RBP (the value in p_pow_caller), so that we can get it back once the function has finished.

Then we copy in RBP the initial content of RSP+8 (because we did a pop). We do this because we want to be able to go on using the stack doing push and pop (which changes RSP), but we also want to be able to reach the parameters that are at certain distance in memory of the original RSP.
This explains why to get a parameter from the stack we use [rbp+distance].
In p_pow_caller we pushed the base first and then the exponent. Since the stack is a LIFO data structure, the exponent is closer to RBP than the base.
How far is it? Well, before pushing p_pow initial RBP content, the exponent was at a distance of 8 bytes from the caller's RSP and the base at a distance of 16. After pushing RBP, the distance is 8 bytes more: base at 28 and exponent at 16 bytes distance.
In that moment we stored the content of RSP inside RBP, so that later changes to RSP cannot change the distance to the parameters. That's the reason why we are able to grab the base and exponent by doing mov ebx, dword[rbp+24] and mov ecx, dword[rbp+16], respectively.

When we've computed the power, we store it in the place that we reserved for it before pushing the parameters (which is 8 bytes farther than the base) doing mov [rbp+32], rax

At the end of p_pow we restore the initial state of the stack (RBP and RSP) again before returning to p_pow_caller.

Calling an assembly function from C passing parameters by reference

In a recent post I showed how to call an assembly function from C. In that example we passed the exponent and base parameters by value to an assembly function, p_pow.
In this example, we'll see how to pass parameters by reference.

This time, instead of using the RAX register to return the result of the p_pow function, we pass a third parameter by reference that will hold the result.
This is the calling C code:

#include "stdlib.h"
#include "stdio.h"
#include "assert.h"

// Assembly function declaration
extern void p_pow(int, int, int *);

int main(void) 
{  
  int result;

  p_pow(2, 2, &result);
  assert(4 == result);
  
  p_pow(3, 2, &result);
  assert(9 == result);
  
  p_pow(5, 2, &result);
  assert(25 == result);   
  
  p_pow(6, 2, &result);
  assert(36 == result);   
  
  p_pow(3, 3, &result);
  assert(27 == result);      
  
  p_pow(3, 0, &result);
  assert(1 == result);
  
  p_pow(1, 5, &result);
  assert(1 == result);
  
  p_pow(-2, 2, &result);
  assert(4 == result);
  
  p_pow(-2, 3, &result);
  assert(-8 == result);

  printf("All tests passed!\n");
  return EXIT_SUCCESS;
}

Look at the prototype of the p_pow function.

extern void p_pow(int, int, int *);

We want to pass result by reference. Since in C everything is passed by default, to pass a parameter by reference what we actually do is passing by value the memory address where result is stored. That's why we've used a pointer.
This is the assembly code:

section .data          
  
section .text                

  ; Make the function name global so it can be seen from the C code
  global p_pow              

p_pow:
  push rbp
  mov rbp, rsp ; Stack initial state is stored
  
  push rdx     ; Store initial value of RDX 
               ; (memory address where the result will be stored)
               ; because RDX can be modified by MUL operation
  
  ; The base (b) is being passed in RDI register
  ; and the exponent (e) is being passed in RCX register
  
  mov eax, 1   ; Register RAX will hold the result temporarily
  
  cmp esi, 0   ; if (e == 0) -> b^0 = 1, and we're done
  jle pow_end   
  
  mul_loop:
   mul edi     ; eax*ebx = edx:eax (when operating 
               ; with ints, edx is not used).
   dec esi     ; esi = esi - 1
   jg mul_loop ; If esi > 0, it continues iterating
  
  pow_end:
  
  pop rdx      ; Restore initial value of RDX
               ; (memory address where the result will be stored)
  
  mov [RDX], dword eax ; Copy final result in memory
  
  mov rsp, rbp ; Stack initial state is restored
  pop rbp                     
  ret           

Now we compile, link and execute the program and we get:

$ yasm -f elf64 -g dwarf2 pow.asm 
$ gcc -g -o pow pow.o pow_c.c
$ ./pow
All tests passed!

Note that in the assembly code, the RDX register is holding the memory address where result is stored. That's how the assembly program is able to change its value. As I explained in a previous post, in the calling convention of the System V AMD64 ABI the registers RDI, RSI, RDX, RCX, R8 and R9 are used for integer and pointer arguments.
To see it better, we'll use gdb.
This is the content of the registers in the first call to p_pow right after executing mov [RDX], dword eax:

(gdb) info register
rax            0x4 4
rbx            0x0 0
rcx            0x0 0
rdx            0x7fffffffe0fc 140737488347388
rsi            0x0 0
rdi            0x2 2
rbp            0x7fffffffe0e0 0x7fffffffe0e0
rsp            0x7fffffffe0e0 0x7fffffffe0e0
r8             0x7ffff7dd7300 140737351873280
r9             0x7ffff7deb5f0 140737351955952
r10            0x7fffffffdf50 140737488346960
r11            0x7ffff7a76c90 140737348332688
r12            0x400460 4195424
r13            0x7fffffffe1e0 140737488347616
r14            0x0 0
r15            0x0 0
rip            0x400568 0x400568 <pow_end+3>
eflags         0x246 [ PF ZF IF ]
cs             0x33 51
ss             0x2b 43
ds             0x0 0
es             0x0 0
fs             0x0 0
gs             0x0 0

The RDX register contains the memory address of result and the content of that memory address is 4:

(gdb) x/d $rdx
0x7fffffffe0fc: 4

We've seen how by passing its memory address by value, we were able to change the content of a variable from inside an assembly function, as though we were passing the variable by reference.

Calling an assembly function from C: simple example

This semester I'm studying AETC in ETIS in the UOC.
For one of the course assignments I had to use some C mixed with assembly.
To make things simpler in this first assignment, we were asked to use only global variables to pass information between the main C programs and the assembly subroutines.
Since I wanted to know how to do it without global variables, I started to explore a bit.

After some googling and reading several blog posts I found out that, first of all, I needed to identify which calling convention to use. There are many different calling conventions, which one you use depends on your architecture, language or even operative system.
I was using a x86-64 architecture in a 64 Bit Linux, so checking this Wikipedia list of different x86 calling conventions I finally found out that the one I needed to use was: the System V AMD64 ABI convention.
From Wikipedia:

System V AMD64 ABI convention
The calling convention of the System V AMD64 application binary interface is followed on Linux and other non-Microsoft operating systems. The registers RDI, RSI, RDX, RCX, R8 and R9 are used for integer and pointer arguments while XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6 and XMM7 are used for floating point arguments. For system calls, R10 is used instead of RCX.[9] As in the Microsoft x64 calling convention, additional arguments are pushed onto the stack and the return value is stored in RAX.

Once I knew how to pass parameters to an assembly function from C, I coded a simple integer power computation to test it.
This is the calling C code (pow_c.c):

#include "stdlib.h"
#include "stdio.h"
#include "assert.h"

// Assembly function declaration
extern p_pow(int, int);

int main(void) {  
  assert(4 == p_pow(2, 2));
  assert(9 == p_pow(3, 2));
  assert(25 == p_pow(5, 2));   
  assert(36 == p_pow(6, 2));   
  assert(27 == p_pow(3, 3));      
  assert(1 == p_pow(3, 0));
  assert(1 == p_pow(1, 5));
  assert(4 == p_pow(-2, 2));
  assert(-8 == p_pow(-2, 3));
  printf("All tests passed!\n");
  return EXIT_SUCCESS;
}

And this is the assembly code (pow.asm):

section .data          
  
section .text                

; Make the function name global so it can be 
; seen from the C code
global p_pow              

; Function that computes the power of an integer.
; The base (b) is being passed in RDI register
; and the exponent (e) is being passed in RSI register
; The result is returned in the RAX register
p_pow:
 push rbp
 mov rbp, rsp ; Stack initial state is stored
    
 mov eax, 1   ; Register RAX will hold the result
 cmp esi, 0   ; if (e == 0) -> b^0 = 1, and we're done
 jle pow_end   
  
 mul_loop:
  mul edi     ; eax*ebx = edx:eax (when operating 
              ; with ints, edx is not used).
  dec esi     ; esi = esi - 1
  jg mul_loop ; If esi > 0, it continues iterating
 pow_end:
  
 mov rsp, rbp ; Stack initial state is restored
 pop rbp                      
 ret

To compile the assembly code I used Yasm which is a rewrite of the NASM assembler under the “new” BSD License. If you have it already installed, you just need to open a console and write this:

$ yasm -f elf64 -g dwarf2 pow.asm

Doing this you'll get an object file: pow.o
Actually only yasm -f elf64 pow.asm is needed to get an object file, but I added -g dwarf2 to obtain debug information so I could use gdb to debug the program.
The elf64 object format is the 64-bit version of the Executable and Linkable Object Format. DWARF is a debugging format used on most modern Unix systems.

To compile the C code and link it with pow.o:

$ gcc -g -o pow pow.o pow_c.c

which produces the executable pow, that when executed yields the following output:

$ ./pow
All tests passed!

ETIS en la UOC: Nuevo semestre

Hoy empieza un nuevo semestre en la UOC.
Me matriculé de las siguientes asignaturas:

1. Ampliació d'estructura i tecnologia de computadors
   Es la continuación de Estructura i tecnologia de computadors que hice el semestre anterior. Por lo poco que he visto parece que, aún teniendo menos créditos, me llevará mucho más tiempo que ETC.
2. Matemàtica discreta
   Esta es la que tuve que dejar el semestre anterior. A ver si esta vez lo consigo.
3. Teoria d'autòmats i llenguatges formals I
   Esta la cogí porque me entró la curiosidad después de oir decir que es una asignatura muy bonita a varios compañeros de trabajo que son ingenieros informáticos. Espero que me guste a mi también.

En cuanto al calendario de entregas, este semestre no están tan repartidas como el pasado. Hay dos puntos del semestre (a mitad de Abril y a final de Mayo) en los que en 8 días tendré que hacer 4 entregas.
Parece que tendré que organizarme mejor que el semestre pasado y empezar las PACs y prácticas con más antelación.
Ya contaré por aquí como fue todo.

ETIS en la UOC: Asignaturas del pasado semestre

Últimamente no he publicado ningún post porque hasta hace muy poco he estado liado con los exámenes de las asignaturas que matriculé en la UOC
Bueno, al final no me ha ido del todo mal. Tuve que dejar una de las asignaturas, Matemàtica Discreta (6 créditos), porque no me daba tiempo de trabajar y llevar las tres asignaturas al mismo tiempo, pero saqué Matrícula de Honor en las dos asignaturas con las que decidí continuar, Estructura de la Informació y Estrucutura i Tecnología de Computadors, (6+9= 15 créditos). 
Esto último es genial porque la UOC es muy cara, y las dos MH me compensan lo que pagué por la asignatura que tuve que dejar y harán que la próxima matrícula me salga un poco más barata. También he aprendido donde está mi límite: 15 créditos por semestre.

Estas son mis impresiones sobre las dos asignaturas que terminé:

Estructura de la Informació
Me gustó mucho. Aprendí sobre distintas estructuras de datos, su eficiencia, implementación y aplicación. También aprendí algoritmos que no conocía, y sobre complejidad, notación O y todo eso. En otras asignaturas, y por mi cuenta, ya había visto algunas estructuras de datos simples (vectores, listas encadenadas, colas y pilas), pero en esta asignatura además de profundizar en ellas, trabajé con otras que no había usado antes, como colas con prioridad, heaps, árboles, tablas de dispersión y árboles de búsqueda.
En cuanto a la parte práctica de la asignatura, aprendí a usar y crear clases genéricas en Java, y utilicé TDD en el desarrollo de todas las prácticas. Esto último no era necesario, pero decidí que las prácticas por su tamaño, nivel de complejidad y límite de tiempo, podrían servirme como un breakable toy ideal con el que practicar TDD. Este es el código resultante. Si uno sabe defenderse con Java, las prácticas de esta asignatura se pueden hacer sin pasar demasiados apuros.

Estructura i tecnologia de computadors. Esta se me hizo un poco más dura por su extensión (9 créditos) y por la cantidad de trabajo que acarreaba: 4 Proves d'Avaluació Continuada (PACs) y una Pràctica Final.
La mayoría del temario no era nuevo para mi, ya que había hecho una asignatura en Física con contenidos parecidos: Fonaments de Conmutació.
Sin embargo, el enfoque del temario era diferente, porque la asignatura de física daba más importancia a la parte electrónica (se ven más tipos de biestables, más tipos de autómatas, se hacen prácticas en el entorno Quartus II de ALTERA, etc.), mientras que la asignatura de ETIS daba más importancia a los conceptos que son útiles para explicar cómo funciona un ordenador. Por este motivo se hacía más hincapié en la representación numérica de la información, se explicaba los circuitos combinacionales y secuenciales sin entrar en tanto detalle como en la asignatura de física, y finalmente se dedicaba mucho tiempo a describir el funcionamiento de un ordenador sencillo: la máquina rudimentaria (MR).
Este último tema dedicado a la MR es el más importante de la asignatura, ya que la última PAC, la Práctica, y un 40% del examen final se centran exclusivamente en él. De todas formas para entenderlo se necesita haber comprendido bien todos los temas anteriores.
Es una asignatura que da mucho trabajo, pero al final le acabas cogiendo el gusto a “hacer de ordenador”, y entiendes cómo se decodifican y ejecutan las instrucciones de ensamblador. Hacer las PACs te ayuda muchísimo para prepararte para la Práctica y el examen final.
Tengo que darle las gracias a los compañeros que encontre en CAUOC con los que tuve oportunidad de discutir dudas, contrastar resultados y preparar el examen. También me ayudaron mucho en algún momento de desanimo. Muchas gracias a todos, especialmente a juanvmtz y a Lennon.
No sé si me servirá de algo algún día, pero al menos fue un buen sudoku para mantener mi mente activa.

En la UOC el próximo semestre

Después de darle unas cuantas vueltas, me decidí finalmente a matricularme de algunas asignaturas de Enginyeria Tècnica d'Informàtica de Sistemes en la UOC para el semestre de otoño:

• Estructura i tecnologia de computadors.
• Matemàtica discreta.
• Estructura de la informació.

Me volvió a picar el gusanillo y me volví a liar... ;)