LogicAdemy.dev
Skip to Content
De la lógica al algoritmo

Copia la lección y pégala en tu chat para resolver dudas.

De la lógica al algoritmo

¿Cómo conviertes una regla en un proceso que pueda ejecutar un agente o un programa? Necesitas precisar acciones, condiciones y resultados, además de declarar qué estás suponiendo.

Objetivos y conocimientos previos

Partimos de las condiciones e inferencias. Aprenderás a distinguir requisitos y procedimientos, seguir cambios de estado y explicar por qué un proceso termina y qué propiedad debe conservar.

Qué es un algoritmo

Un algoritmo describe operaciones suficientemente precisas y efectivas para resolver una clase de problemas. Aquí estudiaremos procedimientos que terminan tras un número finito de operaciones para cada entrada admitida. El número puede variar según la entrada.

Una descripción corta puede repetir acciones indefinidamente: tener pocas instrucciones escritas no garantiza terminar. Además, un servicio puede mantenerse activo atendiendo eventos; cada solicitud puede tener un procedimiento finito aunque el servicio no esté diseñado para finalizar tras una sola respuesta.

Una receta sirve como analogía, pero «cocina hasta que esté bien» necesita criterios adicionales para convertirse en una instrucción precisa. La precisión depende del conocimiento y las capacidades de quien ejecuta.

Del requisito al procedimiento

El requisito dice qué debe cumplirse: «Las reservas activas no superan las diez plazas». El procedimiento propone cómo mantenerlo. La lógica ayuda a analizar ambos, pero no decide por sí sola qué reglas necesita una actividad.

Antes de delegar, distingue:

ElementoEjemplo
EntradaSolicitud de una persona para una actividad.
Estado previoCapacidad y reservas activas conservadas.
PrecondiciónCapacidad válida y estado inicial sin exceso de reservas.
AcciónAceptar y registrar, o rechazar sin ocupar plaza.
ResultadoRespuesta coherente con el estado que quedó registrado.
InvarianteEl número de reservas activas está entre cero y la capacidad.

Una precondición es lo que suponemos al comenzar. Una postcondición describe lo que debe cumplirse al terminar. Un invariante es una propiedad que debe mantenerse en los estados relevantes del proceso.

Ejemplo desarrollado: una solicitud cada vez

Para este primer modelo suponemos que las solicitudes se atienden de una en una, que la persona está autorizada y que guardar la reserva no falla. Admitimos una reserva por solicitud; las solicitudes repetidas se tratarán después.

  1. Consultar la capacidad y las reservas activas.
  2. Si no queda plaza, rechazar sin modificar las reservas.
  3. Si queda plaza, guardar una reserva activa.
  4. Confirmar únicamente después de guardarla.

Con capacidad diez y nueve reservas activas, una aceptación deja diez. La siguiente solicitud se rechaza y conserva diez. El procedimiento preserva el límite bajo los supuestos declarados.

Cuando cambian los supuestos

Con dos solicitudes simultáneas, ambas podrían observar nueve reservas y aceptar una más. El resultado sería once. La regla del aforo sigue siendo la misma; el procedimiento simplificado necesita un mecanismo que coordine la comprobación y la aceptación.

No basta con pedir «comprobar antes de guardar»: hay que estudiar qué garantías ofrece la solución elegida. El agente puede investigar y proponer un mecanismo; tú debes comprender qué impide la doble aceptación y qué evidencia lo respalda.

Si guardar falla, tampoco se debe confirmar una reserva inexistente. Introducir fallos, repeticiones o concurrencia exige ampliar el modelo y comprobarlo de nuevo.

Repetición y terminación

Para revisar una lista finita de solicitudes, puedes procesar una pendiente en cada vuelta. Si ninguna vuelta añade nuevas solicitudes y cada procesamiento termina, la cantidad pendiente disminuye hasta cero.

En cambio, «reintentar hasta que funcione» puede no terminar. Necesita límites y una salida cuando se agotan, por ejemplo detenerse e informar tras tres intentos. Un límite permite terminar; no garantiza resolver la tarea.

Corrección y coste

Primero examina si el procedimiento cumple sus condiciones y conserva sus invariantes. Después compara costes: tiempo, memoria, consultas o complejidad de mantenimiento. Un proceso correcto no tiene por qué ser el más rápido; uno rápido puede incumplir la regla central.

Puedes pedir al agente alternativas y sus compromisos. La elección debe responder a las necesidades del producto y a evidencia suficiente.

Practica

Se propone un procedimiento de cancelación: «Buscar la reserva; si está activa, marcarla cancelada; si ya estaba cancelada, informar sin cambiarla».

  1. Declara sus entradas y sus supuestos.
  2. Describe qué ocurre al cancelar dos veces la misma reserva.
  3. Añade una salida para una reserva inexistente.
  4. Explica qué falta estudiar si dos cancelaciones llegan simultáneamente.

Criterio de comprensión: solo la transición de activa a cancelada libera una plaza; una repetición no libera otra. Debes separar el recorrido secuencial de las garantías necesarias para solicitudes simultáneas.

Profundiza con IA

Revisa mi procedimiento: [respuesta]. Pídeme que declare precondiciones, postcondiciones, invariante y terminación. Busca un caso que viole alguno de mis supuestos y ayúdame a decidir qué ampliar. No supongas que el proceso ya está implementado.

Referencia y siguiente lectura

El NIST ofrece una definición de algoritmo  y un diccionario para profundizar en conceptos relacionados. El caso de reservas es un modelo didáctico con límites explícitos.

Continúa con Diagramas de flujo.

Last updated on