Apologies if the title is confusing, but I couldn’t think of better phrasing in short text.

Whenever we define / specify a certain automaton (such as a finite state machine or a turing machine) by defining all of its States, transition function, etc., this feels awfully similar to defining an algorithm. For example, I can define a machine that can tell if a number is divisible by 3. It is very similar to writing an algorithm and the steps to solving the problem.

Now I understand that the two aren’t exactly equivalent. But would it be incorrect to say that the specification of a machine is a type of algorithm, since we’re defining the steps it takes to solve a problem (how to respond to a specific state or input to solve a specific problem)?

  • Corbin@programming.dev
    link
    fedilink
    English
    arrow-up
    1
    ·
    7 months ago

    It would be incorrect, but only because you’ve learned from vague teaching materials. You’re on the right track; let’s just be a bit more precise about terminology.

    An algorithm is a sequence of numbered steps, where some steps make decisions and some steps point towards other steps. Equivalently (thanks to the structured-programming theorem) an algorithm is a flowchart with decision nodes. Machines typically evaluate algorithms directly; the numbered steps can be mapped to sequences of machine instructions. Machine states arise from considering how a particular algorithm behaves on a given machine.

    A specification is a pair of claims, often called the precondition and postcondition, which logically connect the inputs and outputs of a machine. The idea is that, if we fulfill the precondition prior to running the machine, then the outputs of the machine will fulfill the postcondition. The study of specifications is often called “formal methods”, a terrible name for a great idea.

    The connection is hopefully straightforward to see: an algorithm might happen to fulfill a specification. In general, there are often multiple algorithms for a given specification; for example, there’s usually an infinite number of ways to add a do-nothing instruction to an algorithm without changing any of its behaviors. A classic example is sorting; there are many sorting algorithms, all of which fulfill the postcondition that the output list is sorted, usually with the precondition that the input list contains sortable/orderable elements.