Octave o GNU Octave es un programa libre para realizar cálculos numéricos. Como indica su nombre es parte de proyecto GNU. MATLAB es considerado su equivalente comercial. Entre varias características que comparten se puede destacar que ambos ofrecen un intérprete permitiendo ejecutar órdenes en modo interactivo. Nótese que Octave no es un sistema de álgebra computacional como podría ser Maxima, sino que usa un lenguaje que está orientado al análisis numérico.

Peculiares demandantes
Aunque como los propios responsables han reconocido, los peligros de proyectos tan ambiciosos como el LHC no se deben menospreciar, un vistazo al curriculum de los denunciantes es tranquilizador. Wagner ya interpuso una demanda similar para detener un colisionador en el Laboratorio Nacional de Brookhaven que fue desestimada. Además, uno de los físicos citados por Wagner para justificar sus miedos, William Unruh, ya ha afirmado que no ha entendido sus planteamientos.
Por su parte, Sancho tiene una credibilidad aún más incierta. En su web (www.unificationtheory.com) afirma haber desarrollado una Teoría de Unificación que, según él, no prosperará porque “la ciencia aún se basa en el paradigma cartesiano”.

“Está un poco apartado de la principal corriente científica. De hecho, muy lejos de la corriente. Es más, no creo que ni siquiera puedas ver la corriente desde donde él está”, dice sobre Sancho Phil Plait, astrónomo y autor del blog Bad Astronomy .

Yo no me posiciono por ninguna de las partes. Es más me resulta de gran interés los descubrimientos que se pueden generar a raíz de sus investigaciones. Pero aún me resulta de mayor interes, o de mayor incredibilidad, que nieguen que existe riesgo alguno y la gente se lo crea como si tal cosa, cuando se supone que todas las partes que entran en el diálogo son físicos y demás.

El malentendido tiene su raíz en la propia naturaleza de la mecánica cuántica, poco proclive a descartar hipótesis. En mecánica cuántica existe la posibilidad de que si se deja caer un bolígrafo sobre una mesa, se comporte como una onda, la atraviese y caiga al suelo. El fenómeno se conoce como ‘efecto túnel’. La probabilidad de que esto pase no es idéntica a cero, aunque nunca nadie haya visto suceder algo parecido.
Nima Arkani-Hamed, físico teórico del Instituto para Estudios Avanzados de Princeton (EEUU) afirmaba en ‘The New York Times’ que la física cuántica facilita este tipo de afirmaciones aparentemente descabelladas. “Existe una minúscula posibilidad de que el LHC cree dragones que nos devoren”, señaló, con ironía.

Es importante precisar que las posturas de Sancho y Wagner son muy minoritarias entre la comunidad científica. El físico Juan José Gómez Cadenas afirma por ejemplo que la hipótesis de ambos científicos tiene una probabilidad "menor que la de que un meteorito termine con nuestra especie". Una de las razones de este rechazo es que la tesis carece de formalización matemática, un cálculo básico que respalde su razonamiento.

Binding
      When an executable is bound (via the Bind program, for instance), the IMAGE_THUNK_DATA structures in the IAT are overwritten with the actual address of the imported function. The executable file on disk has the actual in-memory addresses of APIs in other DLLs in its IAT. When loading a bound executable, the Windows loader can bypass the step of looking up each imported API and writing it to the IAT. The correct address is already there! This only happens if the stars align properly, however. My May 2000 column contains some benchmarks on just how much load-time speed increase you can get from binding executables.
      You probably have a healthy skepticism about the safety of executable binding. After all, what if you bind your executable and the DLLs that it imports change? When this happens, all the addresses in the IAT are invalid. The loader checks for this situation and reacts accordingly. If the addresses in the IAT are stale, the loader still has all the necessary information from the INT to resolve the addresses of the imported APIs.
      Binding your programs at installation time is the best possible scenario. The BindImage action of the Windows installer will do this for you. Alternatively, IMAGEHLP.DLL provides the BindImageEx API. Either way, binding is good idea. If the loader determines that the binding information is current, executables load faster. If the binding information becomes stale, you're no worse off than if you hadn't bound in the first place.
      One of the key steps in making binding effective is for the loader to determine if the binding information in the IAT is current. When an executable is bound, information about the referenced DLLs is placed into the executable. The loader checks this information to make a quick determination of the binding validity. This information wasn't added with the first implementation of binding. Thus, an executable can be bound in the old way or the new way. The new way is what I'll describe here.
      The key data structure in determining the validity of bound imports is an IMAGE_BOUND_IMPORT_DESCRIPTOR. A bound executable contains a list of these structures. Each IMAGE_BOUND_IMPORT_DESCRIPTOR structure represents the time/date stamp of one imported DLL that has been bound against. The RVA of the list is given by the IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT element in the DataDirectory. The elements of the IMAGE_BOUND_IMPORT_DESCRIPTOR are:

    * TimeDateStamp, a DWORD that contains the time/date stamp of the imported DLL.
    * OffsetModuleName, a WORD that contains an offset to a string with the name of the imported DLL. This field is an offset (not an RVA) from the first IMAGE_BOUND_IMPORT_DESCRIPTOR.
    * NumberOfModuleForwarderRefs, a WORD that contains the number of IMAGE_BOUND_FORWARDER_REF structures that immediately follow this structure. These structures are identical to the IMAGE_BOUND_IMPORT_DESCRIPTOR except that the last WORD (the NumberOfModuleForwarderRefs) is reserved.

      In a simple world, the IMAGE_BOUND_IMPORT_DESCRIPTORs for each imported DLL would be a simple array. But, when binding against an API that's forwarded to another DLL, the validity of the forwarded DLL has to be checked too. Thus, the IMAGE_BOUND_FORWARDER_REF structures are interleaved with the IMAGE_BOUND_IMPORT_DESCRIPTORs.
      Let's say you linked against HeapAlloc, which is forwarded to RtlAllocateHeap in NTDLL. Then you ran BIND on your executable. In your EXE, you'd have an IMAGE_BOUND_IMPORT_DESCRIPTOR for KERNEL32.DLL, followed by an IMAGE_BOUND_FORWARDER_REF for NTDLL.DLL. Immediately following that might be additional IMAGE_ BOUND_IMPORT_DESCRIPTORs for other DLLs you imported and bound against.