Are algorithms the basis for problem solving?

Problem solving through algorithms - specification or expert opinion?

In the last few weeks I have tried to explain in small sections the creation of the individual letters and numbers from a simple mechanical process. I am of the opinion that it does not need to be deepened, the only important thing (mMn) is that you have an idea of ​​how they can be visualized at all. Accordingly, this week we return to the actual topic, to programming, and thus to the possibility of problem solving through algorithms.

Before you start programming, you should first decide what kind of problem you want to solve, or what the program should do (specification). Just as one thinks about the basis of a claim before creating an expert opinion, looking for the problems in the facts in the training, the specification is used as a starting point for programming and the problem is described as completely and in detail as possible and unambiguously, a kind of factual analysis and preliminary consideration. In order to be able to draw up our expert opinion (specification), the relevant information must first be sifted out, any aids that could help to the solution must be collected and, most importantly, clear criteria must be defined as to when a solution can be accepted.

 

So up to the last point, a computer scientist does a similar job to a lawyer, but in the end the job is different. While a specialist lawyer in criminal law will probably try to filter out all disputes, seek out arguments and opinions and try to form his own argumentation strategy, should a program only be able to travel one way. This is precisely where the difficulties arise, because if a program gets into a dilemma situation and cannot make a decision, you will often only receive an error message as the result.

The specification at the beginning is often colloquial and informal, so that they are usually not suitable for setting up a solution and in any case rarely meet the above criteria. For example:

Sections 107 et seq. Of the German Civil Code (BGB) apply to a situation involving a minor.

This “specification” is rather imprecise because:

What does underage mean? All persons under 18, including 3 years old? How does the program know how minority is defined? Are all standards always applicable side by side at the same time? What does apply mean? Do these standards always have to be used in any case? What happens in situations in which the content of the norm leads to different results? Up to where does the referral apply and for which areas of life? Is everything that a minor does by §§107 ff BGB?

Of course you notice that quite a lot of questions arise here, which you learn in the training, which you define, etc. Which lawyers are known (or should be) in any case. But the specification must also contain these definitions so that the program knows exactly when to do what. Seen in this way, the specification must go through the basic legal training and accordingly be further improved, for example:

The effectiveness of a declaration of intent by a minor with limited legal capacity according to §§ 106, 2 BGB depends initially on the consent according to § 182 BGB of the legal representative according to § 107 BGB.

Although this is much more specific and detailed, some information is still missing. What a declaration of intent is, how it is composed, when it is effective, etc. would have to be determined further. In addition, the definition of the legal representative is missing here.
In short: a program works like a good lawyer. If a lawyer knows the definitions, he can also subsume neatly. The same is true for a program. If this receives the data that it is supposed to process correctly and without subjective options, it can also run without errors.

As soon as the specification has been established, it is a matter of solving the solution with the help of an algorithm. Put simply: the algorithm is our report, with the small difference that disputes of opinion cannot occur (see above). Whenever something is to be subjectively evaluated or has been left open, our algorithm will stop and ask again and again until you have made a decision and come to a decision. Just by the way: this is also the reason why the typical dilemma situations from criminal law are so important in the context of the programming of autonomous vehicles. Every lawyer has known the classic turnout case at least since the criminal law AT lecture, but it has not yet been possible to find a clear solution, so that programs in the same situation will (have to) ask again and again about human interaction.

An algorithm can be formulated in various ways, including in natural language. E.g .:

Algorithm to determine the presence of minors in a group

1. Go to the first person!

2. Ask person about age!

3. Remember the person if you are under 18!

4. Unless everyone is interviewed, repeat steps 4.1. until March 4th!

4.1. Go to the following person!

4.2 Ask person about age!

4.3 If the age is less than 18, then remember the person!

5. A minor in the group is a registered person.

A working algorithm could look like this or something like that. It is only important, as a short repetition and summary, that this leads to a goal, possibly solving the problem identified at the beginning in the specification. In addition, no dilemma situations must be included, since the algorithm itself cannot make a decision that has not been given to it in some way.

For a better understanding: An algorithm is like a recipe written by the mothers for the newly moved child. Unless the phrase “the baking time varies depending on the oven” is omitted. What a pinch of salt is must also be specified. But if no questions remain unanswered and everything is precisely predefined, nothing stands in the way of a perfectly successful cake.

NoteMarkenMarket

Remember

Remember

NoteMarkenMarket

Published in Basics of Computer Science, Programming for Lawyers