No vull entrar en detall aquí, però també hi ha d’altres compiladors que generen descripcions de baix nivell (a nivell de transistor, per exemple) a partir de llenguatges de descripció de circuits (a nivell de circuits, per exemple), compiladors dinàmics de codi màquina d’un tipus a codi màquina d’un altre, etc. No fos cas que ens penséssim que els compilador només escupen instruccions a partir d’un llenguatge de programació.

Tornant als compiladors més habituals mencionats al primer paràgraf, cal indicar que normalment s’executen en mode natiu. Això vol dir que el compilador s’executa en el mateix entorn on s’executarà el programa que està generant. Això sembla obvi quan estem desenvolupant una aplicació i estem corregint els possibles problemes que puguin sorgir. Exemples d’això són els entorns integrats de desenvolupament a Windows com ara Microsoft Visual Studio. Res impedeix, però, que el compilador s’executi en un altre entorn, diferent al que té com a objectiu (target). Només hem de ser capaços de poder executar el programa generat a l’entorn objectiu.

Això que a primer moment podria semblar estrany no ho és. Tots els programes que s’executen en màquines encastades (empotrades) com ara telèfons mòbils, càmeres digitals, equips de televisió moderns, etc. s’acaben desenvolupant mitjançant aquesta tècnica. L’eina de desenvolupament del programador és normalment un PC, llavors per comprovar que tot funciona com s’espera aquest utilitza alguna representació, o una versió, de l’entorn objectiu. Per a productes nous per als quals no existeix una versió al mercat se solen usar programes emuladors (per exemple, molta feina es va fer a l’emulador del CELL i encara se’n fa) o en models prototipus (no es estrany trobar-nos amb gent que executa els programes en una especie de placa electrònica que poc aspecte té de telèfon mòbil).

La qüestió, és que en tots aquests casos el compilador s’executa en un lloc i el programa generat en un altre. Quan això passa parlem d’un compilador creuat. A vegades la línia que separar un compilador creuat d’un natiu és fina. L’entorn XCode 2.1 de MacOSX permet crear aplicacions PowerPC (destinades a córrer, per exemple, en un PowerBook G4) o aplicacions Intel (que corren en un MacBook). Es dóna el cas que a Intel podem executar, gràcies al suport que té MacOSX, aplicacions PowerPC i Intel. Una cosa similar es dona en les arquitectures IA32-EMT64 i AMD64 (són quasibé idèntiques i se solen anomenar col·lectivament com x86-64) on podem executar codi de 32-bits de PC (anomenat, entre d’altres, x86 o IA32) i codi de 64-bits. En aquests entorns sol estar disponible un compilador capaç de generar per als dos entorns alhora.

El compilador GCC, el més usat a GNU/Linux, permet la possibilitat de construir un compilador creuat. De fet, aquest article és una forma de mostrar les meves frustracions durant aquest procés, que afortunadament he pogut dur a bon port, després d’un dia i mig de lluita.

Un dels problemes principals alhora de començar algun nou entorn és el problema de l’ou i la gallina. Podem entendre el compilador com l’ou i els programes (i biblioteques de codi) de la nova plataforma com la gallina, o al revés si voleu. Resulta que per poder crear els programes del nou entorn ens cal un compilador. Ara bé, a vegades el compilador requereix parts del nou entorn, que es generen amb un compilador.

Quan volem crear un compilador creuat amb gcc ens hem de plantejar fins a quin punt volem tornar enrere. Com més enrere tornem, el risc del problema de l’ou i la gallina serà major. Què vol dir això? Doncs vol dir que acabarem trobant-nos com es va trobar la primera persona que va desenvolupar per aquella plataforma en particular. I això, segurament no és bo.

Si volem crear un compilador gcc creuat al 100% la recepta de cuina sembla, però no ho és, senzilla:

1. Cal crear les eines binàries, binutils, per la plataforma objectiu. Aquí creem eines de molt baix nivell com ara l’assemblador o l’enllaçador (linker).

2. Cal compilar una primera versió de gcc creuat que usarà les eines binàries del punt anterior. Aquest compilador està a mitges però.

3. Cal compilar, usant el compilador acabat de crear una primera versió de la biblioteca del sistema.

4. Cal compilar, una nova versió del compilador creuat que utilitzi aquesta biblioteca del sistema. Aquest segon compilador és el que usarem com a creuat.

He omès intencionadament certs detalls. Per començar, el primer compilador requereix informació de baix nivell de l’entorn objectiu. Si l’entorn objectiu és Linux ens caldran les capçaleres del kernel apropiades per l’objectiu. Aquesta informació també l’usarà la biblioteca del sistema, normalment glibc (o alguna altra implementació com ara newlib).

Ben mirat tot això sembla fàcil si un sap què ha de fer oi? D’acord, anem a provar de fer un compilador creuat per a Itanium.

Itanium és la fracassada arquitectura proposada per Intel com a substituta de IA32, o sigui pretenia ser l’evolució dels nostres PCs. Fruit d’un desenvolupament massa acadèmic, el resultat és una arquitectura rara, on rara vol dir que els que la van dissenyar no se sap molt bé en què pensaven. Això, juntament al fet que no permetia l’execució dels programes IA32 a velocitats decents i que el rendiment pràctic que se li pot obtenir dista molt del teòric (precisament perquè és una arquitectura centrada en el compilador i els compiladors fan el que poden), van acabar d’enfonsar aquesta arquitectura. Avui dia només sobreviu gràcies a grans servidors de SGI (amb Linux) i de HP (amb el sistema operatiu HP-UX).

Fer un compilador creuat que s’executi a IA32 i que generi codi Itanium és quasibé impossible. Almenys des de zero. Per començar, l’arquitectura defineix una cosa anomenada unwind i que no es troba implementada dins del compilador sinó en una biblioteca externa, la biblioteca libunwind. El problema és que libunwind requereix d’un compilador i una llibreria del sistema per funcionar. En realitat el problema fins aquí no és tan greu ja que és possible crear un compilador fins i tot si no es disposa d’aquesta libunwind. Però clar, el que no podrem és generar cap programa ja que els mancarà la biblioteca. Si no podem generar cap programa, ni biblioteca, amb aquest compilador tampoc podrem compilar la biblioteca del sistema glibc. En fi, un bunyol com una casa.

D’acord, anem a procurar no haver d’anar tan enrere per evitar aquest problema. Fem-nos amb els fitxers binaris essencials ja compilats, bàsicament glibc i libunwind. Podem obtenir aquests fitxers de versions de Linux ja existents per a l’arquitectura Itanium, anomenada IA64 per abreviar. Si fem això és possible saltar-nos tots alguns passos per crear el compilador: només cal compilar binutils i el compilador creuat definitiu. Vaig decidir usar els binaris de Debian Testing.

Però clar, no tot havia de ser fàcil en aquesta arquitectura recargolada com és IA64. Pels vols del 2003, els desenvolupadors de gcc i binutils es van adonar que el codi que generaven no estava conforme amb les convencions binàries de l’arquitectura, definides per Intel. Aquestes convencions s’anomenen col·lectivament ABI i tots els compiladors, per anar bé, s’han d’adherir estrictament a aquesta convenció. Un error pot provocar que els programes no funcionin bé o, ja de forma més elevada, no puguem mesclar binaris generats per diferents compiladors (això que sembla terrible era encara pitjor a Windows on Borland C++ i Microsoft C++ generaven binaris incompatibles a nivell de fitxers objecte de forma que no era fàcil generar un únic programa amb parts compilades pels diferents compiladors, afortunadament al món Linux només s’usa un contenidor binari anomenat ELF i això no passa).

En qualsevol cas, i de forma molt raonable, el que no podien fer era incorporar la correcció de forma silenciosa, ja que llavors seria impossible saber si un binari estava compilat correctament o no. Total que van decidir afegir una marca als fitxers correctament generats. Resulta que la màquina on havia d’executar els programes, una SGI Altix 4700 porta un Linux que tot i reconèixer els fitxers corregits no els suporta. Total, que vaig perdre 4 hores investigant perquè els meus binaris no s’executaven i donaven un error File format not supported, quan aparentment eren binaris correctes de l’arquitectura IA64.

Cal mencionar que donat que l’arquitectura IA64 és tan rara és ridículament difícil trobar binaris per aquesta i tot que hi són trobar les versions antigues és quasi impossible. Cal donar gràcies que existeixi Debian amb suport IA64 perquè si m’he de refiar d’altres distribucions aniria ben servit. Per sort, els fitxers de Debian Stable sí que són compatibles amb el Linux que hi havia instal·lat a la màquina Altix: o sigui, eren prou vells.

Al final vaig poder generar un compilador creuat i386->ia64! ueee :) Només vaig tardar tot un cap de setmana. Un triomf en productivitat, vaja xD.

Introducció

Podríem distingir una categoria de llenguatges moderns de propòsit general com C#, Java o bé tota la família de llenguatges d’scripting Python, Ruby, Perl i també els llenguatges funcionals com Haskell, ML, etc. Tots ells es caracteritzen perquè l’entorn d’execució de l’aplicació ja proporciona mecanismes automàtics de gestió de memòria. És el que la majoria de la gent coneix populament com el fet que aquests llenguatges tenen un «garbage collector».

Els problemes amb la gestió de la memòria del programa és doble. Per una banda, la memòria no deixa de ser un recurs que es pot exhaurir i cal anar alliberant a mesura que no s’utilitzi. Quan una aplicació no allibera els recursos de memòria s’anonema que té «memory leaks». Els memory leaks no sempre són problemàtics ja que la majoria de sistemes operatius recuperen tota la memòria gastada per un programa en el moment que aquest acaba. Si el programa no acaba, o està designat perquè s’executi durant molt de temps abans no acabi (per al primer cas un servidor web com Apache seria un exemple i per al segon un editor com Eclipse o Emacs, els usuaris són reticents a tancar-los i és d’esperar que estiguin molt de temps amb el programa) llavors sí que es converteix en un problema.

L’altre problema amb la gestió de la memòria és el que podríem anomenar el problema de les referències compartides. Sovint, i és l’estratègia de llenguatges com Java i C#, per no duplicar les entitats que representen la informació del programa tenim referències a les dades. En comptes de tenir valors directament, que suposaria anar-los arrossegant (copiant-los) amunt i avall treballem amb referències a les dades. Per exemple, si treballo amb objectes que representen persones i necessito un subconjunt d’aquestes m’apuntaré referències a aquestes persones (o sigui, una fletxa que em duu a cada persona) en comptes de guardar tota la persona en si (copiant tots els seus atributs d’informació).

En llenguatges no gestionats com C o C++, treballar d’aquesta manera corre el risc que no quedi clar quan lliberar el recurs de memòria, ja que les referències no ens diuen res de l’ús i el propietari de la dada referenciada. Així, si alliberem l’espai associat a un objecte, ens hem d’assegurar que totes les referències a aquell objecte ja no s’utilitzaran. Altrament estarem sofrint el problema dels «dangling pointers». Addicionalment ens hem d’assegurar que no lliberem dos cops un objecte, això s’anomena «double free».

Els llenguatges gestionats, com C# o Java, resolen tots aquests problemes excepte, possiblement, el del «memory leak». És possible seguir tenint «memory leaks» en llenguatges gestionats, però això és degut a un control inadequat de les referències. Per exemple, si tenim objectes «cache» que emmagatzemen referències a d’altres objectes, ens hem d’assegurar que això no causa que moltíssimes referències que no s’usaran més queden allà estancades. No fer-ho, impediria que les dades s’alliberessin correctament i el consum de memòria creixeria al llarg del temps.

Avui considerarem un cas senzill de gestió de memòria que no es basa en un «garbage collector» sinó en comptatge de referències.

Comptatge de referències

Hem mencionat que a C i C++ quan tenim una referència, i això es tradueix el 90% de cops en tenim un punter a alguna cosa, no sabem res de quantes persones apunten a l’objecte. Una solució naïf que funciona per molts casos és un comptador de referències. Aquest comptador mantindrà el número de referències que hi ha en un moment donat a l’objecte.

El comptatge de referències té avantatges i inconvenients respecte el garbage collection tradicional. Com a avantatge cal destacar que el comptatge de referències es pot anar fent a mesura que s’executa el programa, això disminueix els moments en què l’aplicació queda congelada. Els garbage collectors més simples senzillament esperen que es consumeixi tota la memòria prevista i llavors comencen la neteja, això pot suposar interrupcions llargues en l’execució. Els garbage collectors més moderns van alliberant progressivament i utilitzen estratègies sofísticades en forma de «guarderia» on hi tenen els punters més joves (s’observa que aquests són els que queden «leakejats» més aviat).

Un inconvenient dels mecanismes basats en comptatge de referències és que ens cal extendre els objectes amb el comptador. A més, això pot empitjorar el comportament de la cache ja que certes operacions aparentment tan simples com assignar un punter en un altre ara impliquen més maquinària. Aquest overhead és inexistent en sistemes basats en garbage collector.

Considerem la següent classe en C++ per a objectes amb comptador de referències.

class ref_countable
{
  private:
    int _refcounter;
  public:
    // Constructor
    ref_countable() : _refcounter(1) { }

    // Destructor, haurà de ser virtual
    virtual ~ref_countable() { }

    // Una referència més a l'objecte
    void object_ref()
    {
      ++_refcounter;
    }

    // Una referència menys a l'objecte
    void object_unref()
    {
      --_refcounter;
      // Si arribem a zero, ens destruïm
      if (_refcounter == 0)
        delete this;
    }

    // La funció dels "fills", es comenta al final
    virtual std::vector<ref_countable**> get_references() = 0;
};

class MyClass : public ref_countable
{
  public:
    MyClass();
    ~MyClass();
    void foo();
};

El que fem és enriquir l’objecte amb informació de comptatge. Quan es crea un objecte, només hi ha una referència a ell per part de qui l’ha creat, per això el posem a u. Si operem aquest objecte per valor (o com es diu tècnicament amb «automatic storage»), o sigui com una variable local, funcionarà com sempre. Però en realitat no volem l’objecte per valor, sinó que volem manipular referències a ell. Per això ens caldrà un punter, però no volem un MyClass* sinó alguna cosa més intel·ligent que sàpiga comptabilitzar bé les referències. La següent és un trosset d’una classe d’aquest estil.

// _T ha de ser una classe que heredi de ref_countable
<template typename _T>
class ref_ptr
{
  public:
    // Inicialització a nul
    ref_ptr() : _ref(0) { }

    // Ens apropiem del punter
    explicit ref_ptr(_T* ref)
      : _ref(ref) { }

    // Constructor de copia
    ref_ptr(const ref_ptr<_T>& p)
     : _ref(p._ref)
    {
      if (_ref)
        _ref->object_ref();
    }

    // Assignació
    ref_ptr operator=(const ref_ptr<_T>& p)
    {
      ref_ptr<T> temp(p);
      // Intercanviem amb una referència temporal
      this->swap(temp);
      return *this;
    }

    // Rutina d'intercanvi de punters
    void swap(ref_ptr<_T>& p)
    {
      _T *const temp = _ref;
      _ref = p._ref;
      p._ref = temp;
    }

    // Destructor
    ~ref_ptr()
    {
      if (_ref)
        _ref->object_unref();
    }

    // Per poder usar el ref_ptr<_T> com un
    // punter normal
    _T* operator->() const
    {
      return _ref;
    }
  private:
    // El punter, pròpiament
    _T* _ref;
};

Ara podem fer coses de l’estil següent,

ref_ptr<MyClass> f()
{
  ref_ptr<MyClass> pMyClass(new MyClass());
  return pMyClass;
}

void g()
{
    ref_ptr<MyClass> p;

    p = f();

    p->foo();

    // Aquí s'alliberarà el punter 'p'
}

int main()
{
  g();
}

Problemes

Els mecanisme de comptatge de referències funciona bé excepte en un cas. Quan tenim cicles de punters. Considereu l’exemple següent.

class B;
class A
{
  private:
    ref_ptr<B> _b;
  public:
    A() { }
    ~A() { }
    setB(ref_ptr<B> b) : _b(b) { }
};

class B
{
  private:
    ref_ptr<A> _a;
  public:
    B() { }
    ~B() { }
    setA(A* a) : _a(a) { }
};

int main()
{
  ref_ptr<A> a(new A());
  ref_ptr<B> b(new B());

  a->setB(b);
  b->setA(a);

  // No s'alliberarà cap dels dos
}

Fixeu-vos, just abans d’acabar main tant a com b tindra 2 de comptador de referències. En sortir de main s’invocaran els destructors de ref_ptr<A> i ref_ptr<B>, reduint el seu comptador a 1. Com que no és zero cap dels dos s’alliberarà. El problema es troba en que tenim un cicle de brossa.

Recol·lectar els cicles

Com ho podem fer per destruir els cicles? Primer ens hem de mirar les referències com un graf. Els nodes són els objectes i les referències que tenen a d’altres objectes són les arestes. D’aquí aviat deduïm que un cicle de brossa que pot ser alliberat forma el que s’anomena una «component connexa forta». Això vol dir que des de qualsevol node del cicle de brossa podem arribar a qualsevol dels altres nodes (sempre hi ha un recorregut entre dos nodes del cicle de brossa). Una altra propietat molt important dels cicles de brossa és que no són accessibles des de les referències vives del programa.

Un algorisme, proposat per Bacon i Rajan, per resoldre aquest problema adopta l’estratègia següent. Tindrem un pool d’objectes que seran objectes que potencialment comencen un cicle. L’estat dels objectes durant la cerca dels cicles es caracteritzarà per quatre colors. Quan un objecte estigui lliure o en ús de forma normal el considerarem de color negre. Si l’objecte ha estat afegit al pool el considerarem de color lila. Mes avall veurem que ens caldran dos colors més: el gris i el blanc.

Per començar cal deixar clar que si a un objecte li incrementem el comptador de referències, incondicionalment el marcarem negre, independentment de si es troba al pool d’objectes o no. Quan disminuïm el número de referències d’un objecte, poden passar dues coses, la primera és que el comptador fos 1 i ara sigui zero. En aquest cas alliberarem l’objecte de forma normal. Si el comptador era major que 1 el que farem és marcar l’objecte de color lila i si no s’hi trobava, afegir-lo al pool d’objectes potencialment arrels d’un cicle.

Quan el pool superi un llindar d’objectes potencialment arrels d’un cicle farem una recol·lecció. Aquesta recol·lecció té tres fases. En una primera fase identificarem els objectes «grisos». Aquí intentem identificar quantes referències són exclusivament degudes a un recorregut iniciat des de dins del cicle potencial. Ho farem així: per cada objecte que tenim al pool (que sigui encara de color lila) ens mirarem els seus «fills», o sigui, els objectes a qui actualment apunta. Si aquests objectes no són de color gris (segurament seran negres però podrien ser lila, si aquest objecte referenciats també es troba dins del pool) els disminuirem el comptador de referències i recursivament marcarem en gris els seus fills. Això el que fa és restar de les referències als objectes, aquelles referències que tenen origen a objectes potencialment origen de cicles.

Noteu que si durant el marcatge en gris algun comptador de referències esdevé zero, vol dir que tots els accessos a aquest objecte provenen exclusivament de nodes que són accessibles des de l’arrel del cicle en potència. En canvi, si el comptador d’un objecte marcat amb gris no és zero vol dir que hi ha algun altre objecte (que no pertany al cicle) que hi apunta.

La següent fase consisteix en marcar de blanc els nodes grisos que tenen comptador de referència zero. Per cada objecte del pool que és gris ens mirem el seu comptador de referències. Si és zero marquem l’objecte com a blanc i tornem a repetir per a tots els seus fills. Si algun dels fills grisos, o objecte al pool gris, no té comptador de referències a zero, ara el que fem és remarcar en negre tots els objectes accessibles des de l’objecte en qüestió, a mesura que ho fem els incrementarem el seu comptador de referències.

Noteu que el procés de remarcat en negre el que ve a fer és actualitzar les referències degudes a un objecte que encara és referit per algun objecte extern al cicle. Considereu el cas en què nostre cicle només té un únic element referenciat des de fora del cicle, això provocaria que tots els objectes, menys aquest, fossin marcats com a blancs. En fer el remarcat en negre, aquests nodes veurien correctament incrementat el seu comptador de referències.

La tercera fase consisteix en alliberar els objectes que encara romanen de color blanc (i que el seu comptador de referències és zero). Noteu que per a C++ eliminar objecte a objecte té conseqüències terrorifiques. En invocar el destructor de l’objecte aquest reduirà els comptadors de referències dels ref_ptr<T> que tingui apuntats. Aixo pot provocar problemes de double free (ja que hem modificat els comptadors de referències reals!), per evitar-ho hem de ser capaços d’ignorar aquestes referències (per exemple posant-les a nul) de forma que el destructor s’abstindrà de no fer-hi res.

Això últim lliga amb el fet que tot i que el mecanisme és força automàtic, en C i C++ la manca de «consciència» sobre els tipus definits (en llenguatges de programació es coneix com «reflexivitat») ens obliga a proporcionar una funció que donat un objecte ens dóni tots els objectes que apunta. En llenguatges com Java o C#, el propi runtime del llengutge és capaç de coneixer aquests objectes. En aquest cas cal fer-ho manualment.

La funció ‘fills’ és necessària en qualsevol sistema de gestió automàtica de memòria, ja sigui basada en comptatge de referències o en sistemes de garbage collection. Un exemple sofisticat d’automatitzar la construcció d’aquesta funció (per no haver-la d’escriure un cada cop) és el compilador GCC. Mitjançant unes marques al propi codi del GCC, una eina és capaç de sintetitzar quines referències té una classe.

Més informació

• Glib::RefPtr Un punter intel·ligent usat a la lliberia glibmm. El punter intel·ligent d’aquest post està basat en aquest.

• Concurrent Cycle Collection in Reference Counted Systems, David F. Bacon, V.T. Rajan in Proceedings European Conference on OOP June 2001, LNCS, vol 2072

• Memory Management and Type Information Aquí explica el mecanisme utilitzat a dins del compilador GCC
• A garbage collector for C and C++. Aquest és un garbage collector molt popular utilitzat en molts projectes de codi open source. És de tipus conservador i treballa analitzant el heap i deduint-ne les referències.

Donc sí, vaig néixer el dia 27 d’abril de 1982 o sigui que fa pocs dies vaig fer 25 anys. Vint-i-cinc anys!!! Això són molts anys!!! T_T. En qualsevol cas no penso lamentar-me de l’edat ja m’arribarà una edat més convenient per queixar-me, no sé, quan en tingui vuitanta o així potser podré queixar-me amb raó xD.

Vull agrair sobretot als meus bons companys de feina i millor persones que m’aguanten cada dia. A tots ells i en particular al Jordi, al Teru, al Cid, al Rodi i al Jairo els vull donar les gràcies per tot. Als mencionants, agrair-los les dues caixes de Ferrero Rocher, pel Wario Ware Smooth Moves de Nintendo Wii, i per les tres guardioles (la gallina, la vaca i la marieta…) que em vau regalar. També vull agrair a l’Àlex i al Juanjo que em regalessin un llibre de cuina de l’Ada Parellada i que no només hi hagués receptes de pastissos :P.

També vull agrair als companys del BSC i del DAC que van venir a celebrar els aniversaris tant del Jonathan, que també feia 25 anys el mateix dia, i meu.

També vull agrair-li al KiM que em regalés la samarreta amb la que triomfaré tots els dies xDDDD. Moltes gràcies KiM!

Gràcies a tots :)

Però no escric aquest post per parlar de Amazon i les seves increïbles habilitats per fer-me comprar alguna cosa cada cop que hi entro. Més aviat, avui parlarem d’una història que m’ha succeït recentment amb Amazon.

Tot comença el març del 2005, sí, 2005, no és un error. Per aquelles dates vaig decidir comprar-me un llibre que tot enginyer en informàtica hauria de tenir al seu prestatge. El llibre és força car ja que no em vaig estar de res i vaig demanar l’edició amb tapa dura. Els llibres tècnics, en general, són força cars i aquest, òbviament, no n’és una excepció.

En qualsevol cas, el llibre no va arribar mai. Almenys en el termini raonable que un dóna als enviaments fets des dels Estats Units. Jo normalment espero un mes. Segurament l’enviament des d’allà, pròpiament dit, deuen ser 2 o 3 setmanes. És el nostre fabulós servei de Correus qui afegeix un imprevisible retard addicional. Coses que té viure en un poble :)

Cal comentar el problema que pot suposar a vegades encarregar productes a fora de la Unió Europea. Molts productes, contràriament al que dictarien els principis de lliure mercat però coherentment amb les idees de protecció dels mercats propis, tenen aranzels. Això vol dir que, tècnicament, productes comprats als EUA són susceptibles de pagar aranzels.

No puc explicar la raó profunda, algun dia ho esbrinaré, però els enviaments postals ordinaris per correu aeri no solen suposar aranzels. L’explicació més simple sol ser la més correcta. Per tant, assumirem que a l’aduana el tràfic de correu és tan exagerat que no estan per tonteries i només alguns paquets sel·leccionats se’ls deu aplicar l’impost d’entrada.

Continuant amb la història després d’aquest breu incís, quan va arribar abril vaig decidir queixar-me a Amazon que no m’havia arribat el llibre. Molt amablement Amazon em va respondre que cap problema que me n’enviaven un altre.

Malaguanyat llibre. No va arribar mai tampoc xD

Ara segurament em titllareu, pel cap baix, de tonto si us dic que davant de la maledicció del llibre en qüestió, un servidor va decidir abandonar aquest enviament. Ras i curt, vaig llençar els diners d’aquesta comanda en particular.

El meu interès pel llibre, tanmateix, no havia minvat en absolut. Per tant vaig decidir tornar-lo a demanar. Aquest cop, per tal de garantir el tret, vaig encarregar-lo amb l’enviament pijo. O sigui, a través d’una empresa de transport (UPS, DHL o TNT, alguna d’aquestes que opera internacionalment).

Lamento informar-vos que, aquesta vegada, tampoc va arribar. De fet, vaig trucar a l’empresa de transport i em van dir que el llibre ja estava de tornada als EUA (!). Un cop els va ser retornat el llibre, Amazon em va reemborsar les despeses. O sigui, que per aquesta segona comanda no vaig perdre diners.

Recuperant la qüestió dels aranzels. Quan hom escull utilitzar una empresa de transport, aquesta declara absolutament tot a l’aduana. De forma que jo ja sabia que el que farien és posar-se en contacte amb mi per tal de pagar els aranzels que meritava el maleït llibre. Però no ho van fer, i això em va fer sospitar.

Amazon està dissenyada com un supermercat. Està tot suficientment ordenat com per trobar les coses, o com a mínim poder-t’hi aproximar, però suficientment desendreçat com per fer-te perdre temps donant voltes. També cal dir que jo no he estat mai massa hàbil amb Amazon. Les meves sospites es van dirigir a l’adreça d’enviament de les comandes estava malament!!!

Bé, malament malament no. Només que al numéro de telèfon li faltava una xifra. La resta estava bé. Això va ser suficient com per impedir que el transportista es posés en contacte amb mi, però no hauria d’haver afectat en absolut la primera comanda, vaja, crec que no els hauria de preocupar que el número de telèfon estigués bé o malament en un vulgar enviament postal.

I llavors sí que em vaig oblidar definitivament de tot l’assumpte. Aquí cal remarcar que a partir d’ençà prioritzo les compres a la Unió Europea, tarden una mica menys i no hi ha aranzels, o sigui que compro a Amazon UK i Amazon França. El problema és que els millors preus, donat el canvi Euro/Dòlar i fins i tot si hom hi inclou les despeses d’enviament, els llibres a Amazon USA a vegades surten més barats.

Com deia em vaig oblidar de l’assumpte d’aquest llibre en qüestió. El llibre maleït.

♦ ♦ ♦

Fa uns dies vaig rebre dos avisos postals, 1º aviso, de paquet a Correus. Un venia d’Alemanya i l’altre d’Estats Units. Per al d’Alemanya podria, a molt estirar, coincidir amb una comanda que no m’ha arribat encara (¬_¬”) de CDJShop.com (hauré de revisar l’adreça? xD). Però aquesta empresa és britànica, crec, i no té molt de sentit que vingués d’Alemanya. Clar que a correus treballen d’una forma peculiar, un cop tenia un paquet de Jamaica i després va resultar ser que venia del barri de Jamaica al districte de Queens de Nova York… Pel segon avís, no tenia ni la més remota idea de què podria ser.

Quan vaig anar a correus a buscar els dos paquets, ja la treballadora em va fer una mala cara com dient ahà!. Quan va tornar venia amb dos saques blaves, que si no ho vaig entendre malament, se suposa que ells no poden obrir, que l’havia d’obrir jo. I la dona em va dir que feia molt de temps que ho tenien allí. Va mirar l’etiqueta del paquet i segons aquesta el estava allí des del juliol del 2006 (???). Cada saca contenia un paquet d’Amazon :D Quan els vaig obrir a casa eren dos exemplars del llibre que vaig encarregar feia 2 anys abans i dels quals només havia pagat un, el segon era el reenviat per Amazon quan vaig queixar-me.

Segurament a correus es van oblidar o van perdre la informació del paquet. La qüestió és que jo no vaig rebre mai els avisos originals, tot i que la treballadora va dir-me que sí (què ha de dir, és clar). En fi, segurament mai no treuré l’aigua clara de què va passar amb aquesta comanda allà al 2005.

L’única cosa dolenta de la història és que quan jo vaig fer la comanda el 2005 el llibre anava per la tercera edició i ara fa poc ha sortit la quarta ^_^U

Imagina que tens un sac infinit de boletes de colors i que totes, absolutament totes, les boles són diferents entre elles. En tens infinites, d’acord ? Sempre en pots treure una més. Per moltes que en tinguis, a cada boleta de colors podries pintar-li un número a mesura que les vas treient. La primera boleta que treus tindria l’1, la segona el 2, la segona el 3,… Òbviament no acabaries mai, però cada boleta podria tenir un número, oi que sí? El que estàs fent és comptar les boletes, no hi ha cap problema que el teu sac sigui infinit.

Ara imagina que en realitat el teu sac de boletes és finit. Posem que en tens 3, la vermella, la blava i la verda d’acord ? Ara suposem que fas grupets de boletes. Primer comences fent grupets de 1, per tant tens la vermella en un grupet ella sola, la blava en un grupet ella sola i la verda en un grupet ella sola. Et surten 3 maneres d’agrupar les boles d’una en una.

Continues i fas grupets de 2, per tant tens la vermella i la blava, la blava i la verda i la vermella amb la verda. Tens 3 maneres d’agrupar les boletes de dos en dos. Finalment si fas un grup de 3 boletes, com que en tens només tres, només pots fer un únic grup de tres boletes: el que les té totes. Mirem quants grups en surten de cada: 3 grupets de 1 bola, 3 grupets de 2 boles i 1 grupet de 1 bola. Això són 7 grupets.

Si ara afegíssim una boleta rosa al teu sac i miressis de nou quants grupets hi ha et sortirien 15, a saber: 4 grupets de 1 bola, 6 grupets de 2 boles, 4 grupets de 3 boles i 1 grupet de 4 boles. Creu-me, i sinó, fes tots els grupets.

Ara ve la part complicada, imagina’t que vas a fer això dels grupets amb el teu sac infinit de boletes.

«Qui voldria fer això?!? Però si tinc infinites boletes!!! Això no es pot comptar!!!», deus pensar.

Al principi ja t’he ensenyat que les hem estat comptant, cada boleta individualment li hem pintat un número i això no suposava cap problema encara que el teu sac de boletes fos infinit.

Ara el que farem es provar de comptar les boletes grupet a grupet, d’acord ? Viam, comencem, agafarem les boletes d’una en una i cada una la posarem en una bossa i llavors pintarem el número a la bossa, d’acord? Després treurem les boletes de les bosses i llavors farem grupets de dos i posarem els grupets de dos boletes a una bosses diferents (bosses noves que no hem pintat) i pintarem la bossa, li pintarem un número. I així bossetes una rere l’altra, primer les bossetes amb una bola, després les bossetes de dos boles, després les bossetes de tres boles, etc. Fixa’t que cada bosseta té un número finit de boletes a dins i que cada bosseta té un conjunt de boletes diferent a totes les altres. Òbviament aquí tampoc acabaries mai perquè tens infinits grupets de 1, de 2, de 3, … però almenys aparentment sembla que podríem comptar totes les bossetes. Insisteixo aquí comptar vol dir pintar un número a les coses que comptes.

Suposo que ja estàs pensant, «però no acabaré mai de comptar les bosses amb una bola per començar a comptar les de dues boles!!! No les comptaria pas totes!!!». D’acord, provem de posar números a les bosses d’una forma diferent. Mira, se m’acut que podem fixar una boleta a cada pas. Escollim una boleta i la posem en una bossa. Pintem la bossa. Treiem la bola, la posem en una altra bossa i n’agafem un altra. Pintem aquesta segona bossa. Treiem les dos boles, les posem en una bossa nova i pintem un número a aquesta bossa de tres boles. Mmm, no, tampoc, perquè no les comptaré pas totes així tampoc.

No cal que pensem més estratègies, no n’hi ha cap que et permetria comptar totes les bossetes. Quan teníem un simple sac de boletes el mecanisme d’agafar cada bola i pintar-li un número ens permetria comptar-les totes. Però ara no podem fer el mateix quan volem comptar els grups de boles (les bossetes), sempre ens en deixarem sense comptar.

Perquè? Imagina per un moment que sí que poguessis comptar totes les formes d’agrupar les boles, o sigui, ets capaç de pintar-me cada bosseta amb un número, les pots comptar totes. El que tindries seria un conjunt de bossetes amb un número pintat a les quals els havies posat un cert número de boles, en algunes els vas posar només una bola, en d’altres dues, en d’altres tres, etc. Anem a fer una bosseta nova (li direm la bossa maligna) que no tingui cap bola de la bosseta que li vas pintar el número 1 (no sé quantes boles vas posar en aquesta bossa, no és rellevant), però que tampoc tingui cap bola en la bosseta que li vas pintar el número 2 (de nou tampoc sé quantes boles hi vas posar), ni tampoc del número 3 (ni idea de quantes voles vas posar tampoc), i així successivament, que no tingui boles de la bosseta 4, tampoc de la bosseta 5, etc.

No pateixis, tens infinites boles, la bossa maligna sempre la pots fer perquè cada bosseta la vas fer amb un número finit de boles i sempre en trobaràs una que no hi és. Bé, doncs em plau comunicar-te que la bossa maligna no l’has comptada perquè si ho haguessis fet voldria dir que alguna bossa té exactament aquestes boles però en omplir de boles la bossa maligna només hem agafat boles que no es trobaven en cap altra bossa i si l’haguessis comptada tindríem ja una segona bossa maligna, però en construir la bossa maligna no agafaríem les boles d’aquesta segona bossa maligna!!! Què absurd tot plegat!!! L’absurditat apareix d’assumir que podies comptar les bossetes on agrupaves boles! (o sigui, pintar un número a totes les bossetes)

Sense entrar en massa precisions matemàtiques que no venen al cas, el teu sac de boles infinites clarament té infinites boles (diguem-li “infinit-A”). Tot i tenir ‘infinit-A’ boles cada bola la podies etiquetar amb un número, totes les boles acabarien tenint un número. Però a les bossetes (que també en tindràs infinites, anomenem-lo ‘infinit-B’) sempre t’acabes deixant bossetes sense etiquetar. I això és perquè d’alguna manera infinit-B és molt més gran que infinit-A. D’acord que ambdós són infinits, però el infinit del sac de boles es suficientment ‘petit’ com perquè les puguis comptar, en canvi l’infinit de les bossetes és massa gran, no el pots comptar, no pots pintar un número a totes les bossetes mentre que sí que podies fer-ho a totes les boletes.