"Opposite" of idempotent operation?
I know this question is more than a year old, but for the sake of posterity, the correct term for "the opposite of idempotent" (at least in computer science) is non-idempotent.
For example, see section 9.1.2 of Hypertext Transfer Protocol -- HTTP/1.1 (RFC 2616):
9.1.2 Idempotent Methods
Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Also, the methods OPTIONS and TRACE SHOULD NOT have side effects, and so are inherently idempotent.
However, it is possible that a sequence of several requests is non- idempotent, even if all of the methods executed in that sequence are idempotent. (A sequence is idempotent if a single execution of the entire sequence always yields a result that is not changed by a reexecution of all, or part, of that sequence.) For example, a sequence is non-idempotent if its result depends on a value that is later modified in the same sequence.
A sequence that never has side effects is idempotent, by definition (provided that no concurrent operations are being executed on the same set of resources).
Emphasis mine.
I feel that you have an invalid idea of what idempotent really means. It doesn't matter whether the outcome of the operation relates to the current value of a variable. Let me give you some examples:
$i = 3 + 1$ is surely idempotent, while:
$i = i + 1$ is surely not. However:
$i = i + 0$ is idempotent, even though the new value is calculated based on the current value. Same goes for:
$i = i * 1$, which is also idempotent. However:
$i = rand(0, 1)$ is non-idempotent, even though it doesn't relate to it's old value.
To sum up, we say that the operation is idempotent when performing it multiple times yields the exact same result as performing it exactly once.
Answering the question asked in the subject of this thread, there are two contrasting terms:
- An operation is nullpotent, when performing it any number of times has the same result as performing it zero times.
- An operation is non-idempotent, when performing it multiple times doesn't necessarily yield the same result every time it is performed.
Let me provide another example, expanding upon example RJ Cuthbertson provided. RJ's example shows how HTTP methods work from the perspective of the client of a service. However, let's glimpse into the service's inner model:
- GET method is nullpotent. Operation of getting a resource is pure query and has no impact on the internal model.
- PUT method is idempotent. Operation of putting a resource allows the user to designate the exact location it should be made available at. Putting the same resource in the same location multiple times yields the same internal state of the system as posting it exactly once.
- POST method is non-idempotent. When posting a resource, the server decides the location it should be made available at. Posting the same resource multiple times will make it available at multiple locations.
Mind you, this is just a pure abstraction. The coder might just as well implement any of these methods to do anything he chooses. This is the way we expect it to behave, though.
"Idempotent" means that repeating the operation doesn't change the outcome. That doesn't mean that it doesn't do changes. I.e., asignment is idempotent (asign 10 five times in a row, the result will always be 10); increment isn't (doing i++ once or twice in C gives different results). Perhaps you mean it has no side effects, or is a "pure" function (each time you call it with the same arguments, the value returned is the same)? Note that e.g. $\sin x$ is pure in this sense (each time you ask for $\sin 1$ you'll get the same result), functions like printf(3) or malloc(3) in C aren't.