I wonder, how could I test my implementation of any given algorithm?
What are the different options for the test approach?
Is algorithm decomposing on determinate / non-determinate final state machine required?
Unit-testing?
Something else?
In practice, the first test to perform is usually to verify the implementation against a (big enough) set of known test vectors. This is more or less unit testing.
If the implementation is not too complex, one can also construct mathematical proof that the implementation transforms the given, known set of pre-conditions into the given, known set of post-conditions. This is the most complete way to ensure an algorithm/implementation is correct, albeit probably the most hard to do for reasonably complex implementations.
Related
More specially, given arbitrary Lean proof/theorem, is it possible to express it solely using first-order logic? If so, is it practical, i.e. the generated FOL will not be enormously large?
I have seen https://www.cl.cam.ac.uk/~lp15/papers/Automation/translations.pdf, but since I am not an expert, I am still not sure whether all Lean's proof code can be converted.
Other mathematical proof languages are also OK.
The short answer is: yes, it is not impractically large and this is done in particular when translating proofs to SMT solvers for sledgehammer-like tools. There is a fair amount of blowup, but it is a linear factor on the order of 2-5. You probably lose more from not having specific support for all the built in rules, and in the case of DTT, writing down all the defeq proofs which are normally implicit.
As the question describe itself "What is the core difference between algorithm and pseudocode?".
algorithm
An algorithm is a procedure for solving a problem in terms of the actions to be executed and the order in which those actions are to be executed. An algorithm is merely the sequence of steps taken to solve a problem. The steps are normally "sequence," "selection, " "iteration," and a case-type statement.
Pseudocode
Pseudocode is an artificial and informal language that helps programmers develop algorithms. Pseudocode is a "text-based" detail (algorithmic) design tool.
The rules of Pseudocode are reasonably straightforward. All statements showing "dependency" are to be indented. These include while, do, for, if, switch. Examples below will illustrate this notion.
I think all the other answers give useful explanations and definitions, but I'm going to give mine.
An algorithm is the idea of how to obtain some result from some input. It is an abstract concept; an algorithm is not something material by itself, but more something like an imagination or a deduction, a thing that only exists in the mind. In the broad sense, any sequence of steps that give you some thing(s) from other thing(s) could be called an algorithm. For example, if the screen of your computer is dirty, "spraying some glass cleaner on it and wipe it with a cloth" could be said to be an algorithm to solve the problem of how to obtain a clean screen form a dirty screen. It is important to note the difference between the problem itself (getting a clean screen) and the algorithm (wiping it with a cloth and cleaner); generally, several different algorithms are possible to solve the same problem. The idea of complexity is inherent to the algorithms itself, not the problem or the particular implementation or execution of the algorithm.
Pseudocode is a language to express algorithms. Since, as said before, algorithms are only concepts, we need to use something to express them and explain them to other people. Pseudocode is a convenient way for many computer science algorithms, because it is usually unambiguous, easy to read and somewhat similar to many programming languages. However, a specific programming language like C or Java can also be used to express and algorithm (it's just less convenient to those not familiarized with that language). In other cases, pseudocode may not be the best way to express an algorithm; for example, many graph and tree algorithms can be explained more easily with drawings or diagrams. In the previous example, the algorithm to get your screen cleaned is probably better expressed in a natural language like English, because it is simple and specific enough for that case.
Obviously, terms are frequently used loosely and exchanged depending on the context, and there's no need to be nitpicky about it, but I think it is important to have the difference clear. An algorithm doesn't stop being an algorithm just because it is written in Python instead of pseudocode. Pseudocode is just a convenient and widespread communication tool to express them.
An algorithm is something (a sequence of steps) you can do. Pseudocode is a notation to describe an algorithm.
Algorithm is something which is represented in mathematical terms. It includes, analysis, complexity considerations(best, average and worstcase analysis etc.).Pseudo code is a human readable representation of a program.
From Wikipedia :
Starting from an initial state and initial input (perhaps empty), the instructions describe a computation that, when executed, proceeds through a finite number of well-defined successive states, eventually producing "output" and terminating at a final ending state.
With a pseudo language one can implement an algorithm without using a programming language such as C.
An example of pseudo language is Flow Charts.
I have this teacher who asked to study AES encryption algorithm, a C code implementation and do a bench testing of it.
So, I've not even tried to do a calculation of the number of steps it would take, but rather I'd like to have these rational reasons why a human can´t or might not go for it.
There is enough scope for misunderstanding and ambiguity in a cryptographic algorithm that it is standard practice to release example inputs and outputs (test vectors) with the specification of the algorithm, so you don't have to work through the algorithm by hand. There appear to be test vectors in the specfication at http://csrc.nist.gov/groups/STM/cavp/. In fact, appendix B of fips-197.pdf appears to show how the state table evolves during a single encryption.
Of course, for a system like AES, where it is not practical to test every possible input and key, you can always argue that while testing can find errors it can never prove the absence of errors.
Anything a computer can do - you can do as well.... they don't use magic for calculation.
To test your algorithm, you should encrypt a small text and than decrypt and see that you get the same results (it will prove the algorithm works, it won't prove it's AES....)
Good programmers who write programs of moderate to higher difficulty in competitions of TopCoder or ACM ICPC, have to ensure the correctness of their algorithm before submission.
Although they are provided with some sample test cases to ensure the correct output, but how does it guarantees that program will behave correctly? They can write some test cases of their own but it won't be possible in all cases to know the correct answer through manual calculation. How do they do it?
Update: As it seems, it is not quite possible to analyze and guarantee the outcome of an algorithm given tight constraints of a competitive environment. However, if there are any manual, more common traits which are adopted while solving such problems - should be enough to answer the question. Something like best practices..
In competitions, the top programmers have enough experience to read the question, and think of some test cases that should catch most of the possibilities for input.
It catches most of the bugs usually - but it is NOT 100% safe.
However, in real life critical applications (critical systems on air planes or nuclear reactors for example) there are methods to PROVE some piece of code does what it is supposed to do.
This is the field of formal verification - which is way too complex and time consuming to be done during a contest, but for some systems it is used because mistakes could not be tolerated.
Some additional information:
Formal verification basically consists of 2 parts:
Manual verification - in here we use proving systems such as Hoare logic and manually prove the program does what we wants it to do.
Automatic model checking - modeling the problem as state machine, and use Model Checking tools to verify that the module does what it is supposed to do (or not doing something "bad").
Specifying "what it should do" is usually done with temporal logic.
This is often used to verify correctness of hardware models as well. For example Intel uses it to ensure they won't get the floating point bug again.
Picture this, imagine you are a top programmer.Meaning you know a bunch of algorithms and wouldn't think think twice while implementing them.You know how to modify an already known algorithm to suit the problem's needs.You are strong with estimating time and complexity and you expect that in the worst case your tailored algorithm would run within time and memory constraints.
At this level you simply think and use a scratchpad for about five to ten minutes and have a super clear algorithm before you start to code.Once you finish coding, you hit compile and there is usually no compilation error.Because the code is so intuitive to you.
Then based on the algorithm used and data structures used, you expect that there might be
one of the following issues.
a corner case
an overflow problem
A corner case is basically like you have coded for the general case, however when say N=1, the answer is different from others.So you generally write it as a special case.
An overflow is when intermediate values or results overflow a data type's limits.
You make note of any problems which arise at this point, and use this data during Challenge phase(as in TopCoder).
Once you have checked against these two, you hit Submit.
There's a time element to Top Coder, so it's not possible to test every combination within that constraint. They probably do the best they can and rely on experience for the rest, just as one does in real life. I don't know that it's ever possible to guarantee that a significant piece of code is error free forever.
There are research articles (e.g. Chakrapani & Palem) and devices (e.g. Lyric) that use a so-called probabilistic logic. I suppose the idea is that the outputs of such a device, given some inputs, will converge to some probability distribution. What is the difference between these devices and those using analog signals? That is, are these devices still considered digital, analog, mixed-signal?
This paper seems to describe some novel kind of (probabilistic) boolean logic, and it is not about implementation. I only skimmed through the paper, but it seems to be just another one of those theories. There is, by the way, a simple reason why probabilistic logics don't give you what classical logics give you, namely, they are not truth functional (i.e. the value of A & B does not depend solely on the value of A and the value of B).
As for implementing such a thing on a chip: I think both are possible. If you do it digitally, then you're calculating probabilities, and you can just as well run some code on a CPU. I don't really know about analog implementations, but I guess any elementary analog component (transistor, opamp etc) can be seen as performing some kind of basic arithmetic operation on voltages and currents. Whether a circuit gives outputs that adhere to, or approximate, the Kolmogorov laws of probability, that's another question, but my guess is: it is somehow possible and maybe it has been done.