Saltar al contenido

¿Cuál es la diferencia entre una función idempotente y una determinista?

Hola, encontramos la solución a tu pregunta, continúa leyendo y la hallarás más abajo.

Solución:

En términos más simples:

  • Función determinista pura: La salida se basa completamente, y solo, en los valores de entrada y nada más: no hay otra entrada (oculta) o estado en el que se base para generar su salida. No hay efectos secundarios ni otros resultados.
  • Función determinista impura: Al igual que con una función determinista que es una función pura: la salida se basa completamente, y solo, en los valores de entrada y nada más: no hay otra entrada o estado (oculto) en el que se base para generar su salida – sin embargo hay otra salida (efectos secundarios).
  • Idempotencia: La definición práctica es que puede llamar de forma segura a la misma función varias veces sin temor a efectos secundarios negativos. Más formalmente: no hay cambios de estado entre llamadas idénticas posteriores.

La idempotencia no implica determinación (ya que una función puede alterar el estado en la primera llamada mientras es idempotente en las llamadas posteriores), pero todas las funciones deterministas puras son inherentemente idempotentes (ya que no existe un estado interno que persista entre las llamadas). Las funciones deterministas impuras no son necesariamente idempotentes.

Determinista puro Determinista impuro Puro no determinista Impuro no determinista Idempotente
Aporte Solo argumentos de parámetro (incl. this) Solo argumentos de parámetro (incl. this) Argumentos de parámetros y estado oculto Argumentos de parámetros y estado oculto Alguna
Producción Solo valor devuelto Valor de retorno o efectos secundarios Solo valor devuelto Valor de retorno o efectos secundarios Alguna
Efectos secundarios Ninguno Ninguno Después de la primera llamada: Quizás.
Después de la segunda llamada: ninguna
Ejemplo de SQL UCASE CREATE TABLE GETDATE DROP TABLE
Ejemplo de C # String.IndexOf List.Add DateTime.Now Random.Next Directory.Create[1]
  • [1] – Directory.Create es idempotente porque si el directorio ya existe, devuelve un nuevo DirectoryInfo instancia como si acabara de crear un nuevo directorio del sistema de archivos (al igual que CreateFile puede ser usado para abierto un archivo existente).

Determinación de funciones puras

Por ejemplo, en SQL UCASE(val), o en C # /. NET String.IndexOf son deterministas porque la salida depende solo de la entrada. Tenga en cuenta que en los métodos de instancia (como IndexOf) el objeto de instancia (es decir, el oculto this parámetro) cuenta como entrada, aunque esté “oculta”:

"foo".IndexOf("o") == 1 // first cal
"foo".IndexOf("o") == 1 // second call
// the third call will also be == 1

Mientras que en SQL NOW() o en C # /. NET DateTime.UtcNow no es determinista porque la salida cambia a pesar de que la entrada sigue siendo la misma (tenga en cuenta que los captadores de propiedades en .NET son equivalentes a un método que no acepta parámetros además de los implícitos this parámetro):

 DateTime.UtcNow == 2016-10-27 18:10:01 // first call
 DateTime.UtcNow == 2016-10-27 18:10:02 // second call

Idempotencia

Un buen ejemplo en .NET es el Dispose() método: Consulte ¿Deben ser idempotentes las implementaciones de IDisposable.Dispose ()?

un método Dispose debe poder llamarse varias veces sin producir una excepción.

Entonces, si un componente principal X hace una llamada inicial a foo.Dispose() entonces invocará la operación de eliminación y X ahora puedo considerar foo para ser desechado. La ejecución / control luego pasa a otro componente Y que luego también intenta deshacerse de foo, después Y llamadas foo.Dispose() también puede esperar foo para ser desechado (que es), aunque X ya lo deseché. Esto significa Y no necesita verificar para ver si foo ya está eliminado, lo que ahorra tiempo al desarrollador y también elimina errores en los que se llama Dispose una segunda vez podría generar una excepción, por ejemplo.

Otro ejemplo (general) está en REST: el RFC para HTTP1.1 establece que GET, HEAD, PUT, y DELETE son idempotentes, pero POST no es (https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html)

Los métodos también pueden tener la propiedad de “idempotencia” en el sentido de que (aparte de errores o problemas de caducidad) los efectos secundarios de N> 0 solicitudes idénticas son los mismos que para una sola solicitud. Los métodos GET, HEAD, PUT y DELETE comparten esta propiedad. Además, los métodos OPTIONS y TRACE NO DEBEN tener efectos secundarios, por lo que son inherentemente idempotentes.

Entonces, si usas DELETE luego:

Client->Server: DELETE /foo/bar
// `foo/bar` is now deleted
Server->Client: 200 OK
Client->Server DELETE /foo/bar
// foo/bar` is already deleted, so there's nothing to do, but inform the client that foo/bar doesn't exist
Server->Client: 404 Not Found
// the client asks again:
Client->Server: DELETE /foo/bar
// foo/bar` is already deleted, so there's nothing to do, but inform the client that foo/bar doesn't exist
Server->Client: 404 Not Found

Entonces ves en el ejemplo anterior que DELETE es idempotente en el sentido de que el estado del servidor no cambió entre los dos últimos DELETE solicitudes, pero no es determinista porque el servidor devolvió 200 para la primera solicitud pero 404 para la segunda solicitud.

Una función determinista es solo una función en el sentido matemático. Dada la misma entrada, siempre obtiene la misma salida. Por otro lado, una función idempotente es una función que satisface la identidad

f(f(x)) = f(x) 

Como un simple ejemplo. Si UCase() es una función que convierte un string a una mayúscula string, entonces claramente UCase(Ucase(s)) = UCase(s).

Las funciones idempotentes son un subconjunto de todas las funciones.

A determinista La función devolverá el mismo resultado para las mismas entradas, independientemente de cuántas veces la llame.

Un idempotente Es posible que la función NO devuelva el mismo resultado (devolverá el resultado en la misma forma, pero el valor podría ser diferente, consulte el ejemplo http a continuación). Solo garantiza que no tendrá efectos secundarios. En otras palabras, no cambiará nada.

Por ejemplo, el GET verbo está destinado a ser idempotente en el protocolo HTTP. Si llama a “~ / employee / 1”, devolverá la información del empleado con ID 1 en un formato específico. Nunca debe cambiar nada, simplemente devolver la información del empleado. Si lo llama 10, 100 o más veces, el formato devuelto siempre será el mismo. Sin embargo, de ninguna manera puede ser determinista. Tal vez si lo llama por segunda vez, la información del empleado ha cambiado o tal vez el empleado ya no existe. Pero nunca debería tener efectos secundarios o devolver el resultado en un formato diferente.

Mi opinión

Idempotent es una palabra extraña, pero conocer el origen puede ser muy útil. ídem sentido mismo y potente sentido poder. En otras palabras, significa teniendo el mismo poder lo que claramente no significa que no efectos secundarios así que no estoy seguro de dónde viene eso. Un ejemplo clásico de Solo hay dos cosas difíciles en la informática, invalidación de caché y nombrar cosas. ¿Por qué no podían simplemente usar solo lectura? Oh, espera, ¿querían sonar extra inteligentes, tal vez? Tal vez como complejidad ciclomática?

Aquí tienes las comentarios y calificaciones

Te invitamos a añadir valor a nuestro contenido informacional aportando tu veteranía en las anotaciones.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *