The following two sections (Bug and Programming Languages) are not required to solve the task. They are purely informative.

Bug

In geocaching there are TBs, i.e. travel bugs, and term variants like "buggy" can be found on the one hand in the very practical small child transport vehicles, which when folded up look like a bug playing dead in front of an enemy, and on the other hand in some offroad special vehicles, which in their appearance resemble a big, fat bug.

The term bug and buggy is also known in IT. Here the term is used for an error in the program code of a software. If a program is full of programming errors, it is called "quite buggy". Where does this term come from?

Falsely, it is often claimed that the term originated at the end of the 1940s, during the search for a functional error in the computer Mark II Aiken Relay Calculator. After a dead moth was removed from a relay, this malfunction was solved and the technician who carried it out wrote in his notebook "First actual case of bug being found". However, this sentence indicates that the term bug was already a common term for a malfunction or error. For in fact, the term bug was coined in telephone technology. The crackling and hissing during the transmission of sound was attributed to the fact that small bugs would nibble at the wires. You can read more about this on Wikipedia.

The chance that a software program is completely free of error tends normally to zero. The reason for this is that a programmer, no matter how well he masters his craft, is rarely in a position to know, when creating a program, who, for what purpose, in what environment, with what knowledge will later use his software. Some things are known to him, if he has enough experience and tests extensively. For example, that users type all kinds of characters and special characters into input fields that are intended for a normal date, for example. Such things can be easily checked and intercepted. It is more difficult with fields that are used to enter personal names. In the further processing it must be paid attention to the fact that here up to Asian characters everything is entered and the program must get along with it. In addition, each new operating system version brings changes that even the most ingenious programmer would not expect. Thus, the more a program can do, the more complex it becomes, the greater the chance that it will contain bugs. This does not only apply to application software. Operating systems are also affected. Every update that has to be installed for an operating system month after month removes some bugs and brings with it almost as many new ones that have to be corrected later. Such bugs are not only found in software. Hardware is not free of them either. One of the best known hardware bugs was in the 1994 Pentium processor from Intel®. It delivered wrong results with certain floating point divisions.

Now we come to the term "debugging". This is what this cache is all about. This is the process in which a program is freed from its errors. To do this, the program is gone through step by step, it is checked which variables contain which values and it is compared what happens how and what should happen how. In this way, errors can be effectively found and eliminated. More about this below.

Programing languages

Here now a short excursion to programming languages. The first mainframes/computers had no keyboards to enter programs. They were fed with punched cardboard cards, the punched cards, which, depending on where which holes were punched, so the information in machine language told the computing device what to do. The error rate was enormous and if a box of punched cards fell down, it took hours to get them back in the correct order. The screen and the keyboard were invented and the programming language "assembler", of which there was one for each processor, was replaced by meta languages. These resembled punched cards for the time being. For example, the COBOL programming language required the exact position in row and column of the commands entered. Just like on a punch card. Programming languages of the 2nd generation (e.g. C, C++, Pascal, Delphi, ...) are standard today and their commands can now be entered in a "human readable" language. They are then translated by a so-called "compiler" into the machine language that the respective processor can understand. The next generation of programming works via graphical elements. Depending on the scope, building blocks are provided, which are attached to each other according to the desired logic. Parameters can then be used to fine-tune these building blocks. This "picture" is then translated at the end again into machine language and can be executed. Examples for such a language can be found e.g. in the programming of LEGO® robots. Now we have two levels where bugs can occur. On the one hand the programmer can create errors, on the other hand the compiler, which translates the metalanguage into machine language, can be faulty. A further variant are the interpreter programming languages. As the most famous representatives BASIC is to be mentioned here. This language is relatively easy to learn and works in such a way that the program lines are passed line by line to a so-called interpreter, which translates and executes them at runtime, i.e. at the time when the program is executed, into machine code. This has advantages and disadvantages.

Advantages are:

• Simple programming
• Simple debugging
• Source code corrections during debugging possible
• Cross-operating system platform use possible
• ...

Disadvantages are:

• Slow execution times
• A runtime environment must run along and be available
• The source code can be seen and changed by everyone
• ...

Of course there are some more variations. For example programs of the programming language JAVA® are translated into a kind of meta-code, so that they are not readable for humans (copyright, etc.). Nevertheless, this meta language still has to be interpreted so that it can run on as many platforms as possible. But this has the disadvantage of adding a source of errors and making the whole thing rather slow.... but we are already used to that from JAVA® :)

The Cache

Important: As usual with Mysteries, this cache is not located at the coordinates mentioned above. The target coordinates are close to a place with a breathtaking view of Lake Constance and the Alps. The special thing is that there are nevertheless almost no muggles there.
The container is big, but nevertheless it is not suitable for TBs and exchange objects. For this reason I have hidden a second container under a stone at the foot of the tree to which it is attached. This one is meant for TBs and exchange objects.

This cache should demonstrate now, which effects a small error in a program can have. I classify the cache on D4, although for some it is like a D5 and others would probably rate it as D1. Depending on programming experience. Now there are two ways to solve the task:
1.) via Microsoft® Excel®
2.) via JavaScript
The Excel® variant is more comfortable, because there is the possibility to step through the source code and monitor the variables, as described above. If you do not have MS-Office® installed, you can use variant 2, which is described below.

Variant 1: MS Excel® and VBA:

I chose Microsoft® Excel® because I think it is widely used and available, even for MAC® users. Excel® also offers a small programming environment for VBA (Visual Basic for applications). VBA also has the advantage that it is easy to understand and you can learn it very fast. Since certainly not everyone can program and therefore not have a complete programming environment, this variant seems to me the most practical.
For all those who have not yet dealt with VBA, here is a short description of the commands/elements used in this program:

1.) Data types used:

• Integer: positive or negative
• Boolean: binary value, can be TRUE or FALSE
• String: can contain almost all characters of the ASCII table. E.g. the string "123" is not interpreted as a number but as text.

2.) Used characters and operators:

• " ' ": (single apostrophe) No operator. This character marks the beginning of a comment. From here on the interpreter ignores what is written there. Comments are intended to improve the readability of a program for programmers. They give hints, what is done at the concerned lines.(single apostrophe) No operator. This character marks the beginning of a comment. From here on the interpreter ignores what is written there. Comments are intended to improve the readability of a program for programmers. They give hints, what is done at the concerned lines.
• "_": Allows a line break where syntactically none should be. This improves the readability.
• "Dim": Declares a variable. The value of the variable can change during program execution.
• "Const": Declares a constant. The assigned value cannot be changed.
• "=": Depending on the position in the source code, this assigns a value to a variable or compares two values/variables.
• "&": Combines two strings into one: "ABC" & "DEF" --> "ABCDEF".
• "> / < / >= / <=": Compares: greater than / less than / greater than or equal to / less than or equal to.

3.) Functions used:

• CInt: Converts a string to an integer. E.g. "123" to 123.
• CStr: Counterpart to CInt, converts a number to a string. E.g. 123 to "123".
• Mid: Extracts a substring. Parameter 1: Whole string, Parameter 2: Start position of the substring, Parameter 3: Length of the substring.
• Asc: Returns the position of a character in the ASCII table. E.g. Asc("A") --> 65.
• Chr: Counterpart to Asc, returns the character of the specified position from the ASCII table. E.g. Chr(65) --> "A".
• If ... Then ... Else ... End if: Wenn ... dann ... sonst ... :)
• While ... Wend: loop: As long as the condition is met, repeat the statements until "Wend".
• For ... To ... Step ... Next: The For loop is used when it is known from the beginning how often and in which step size it will be run.
• Workbooks(...).Sheets(...).Range(...)... : At these points changes are made to the Excel® table or values are read in. This is where the output of the program happens.

Prerequisites:

To solve the task in variant 1, you need a PC on which Microsoft® Excel® (possible versions: 95-2019) is installed. Macros must be activated and allowed in the security settings. Please do not forget to re-enable this security feature once the task is solved.

Getting started:

Start Excel®. Automatically an empty workbook will be opened. Make sure that there is a worksheet with the name "Tabelle1". Save this file to a location of your choice with the name "bug.xls". Important! Select the file type: "Excel 97-2003 Workbook" when saving, even if you have a newer version of Excel®. To open the Visual Basic Editor of Excel® press the key combination [ALT]+[F11]. In the project window on the top left click with the right mouse button on "VBA Project (Bug.xls)", select "Insert" and then "Module". Now copy the program source code from below (from "Option Explicit" to "End Sub") into the white main window. Now you are ready to start. For testing you can run the program once (press [F5]). A black/white pattern should now appear in the table "Tabelle1". The execution of the program should not produce an error message now. Now you can start debugging. You can execute the program line by line by pressing [F8]. You can display the content of variables by right-clicking on the variable and clicking on "Add watch" + [OK] in the context menu.

What's the task of the program?

Well, as is so common in geocaching, it's all about "secret" coordinates. Someone came up with a way to encrypt the coordinates of his hiding place in such a way that it is not immediately clear how to get coordinates like "N 47° 12.345 E 009° 67.890" from the gibberish of letters and numbers. In order to decode this gibberish again, there is the following program. Unfortunately, however, a bug has crept in at exactly one point...

Variant 2: Java Script:

This variant is an alternative if MS Excel® is not available. All that is required is a text editor (e.g. Notepad) and a web browser that allows Java Script.

Preparation:

• Open a text editor of your choice (e.g. Notepad, VI, etc.).
• Copy the HTML source code (see below) into the editor.
• Save the file with the name "Bug.htm".
• Make sure that your browser allows Java Script. (if necessary activate the security setting again at the end!)
• Double click on the file "Bug.htm" to open it in your browser and view the result of the program.
• Try to understand the program, fix the bug.
• If you made a change, save the file, switch to the browser and refresh the page to see the result (press [F5]).

Short explanations:

• "{ and }" Marks the beginning and end of a statement block.
• "==" Compares two values with each other.
• "=" Assigns the value of the right side to the left.
• "< / > / <= / >=" Compares: less than / greater than / less than or equal to / greater than or equal to.
• "++" Increases the variable by exactly 1.
• ".length" Returns the length of the string.
• ".concat" Concatenates two strings.
• "charCodeAt" Returns the ASCII code of the passed character.
• "parseInt" Converts a string of numbers into an integer.
• "while / for / if...else" See description at variant 1.
• "string[X]" Returns the character at position "X" of a string.
• "document.write" Returns the result as HTML code to the browser.

What's the task of the program?

Well, as is so common in geocaching, it involves "secret" coordinates. Someone has thought of a way to encrypt the coordinates of his hiding place in such a way that it is not immediately clear how to get coordinates like "N 47° 12.345 E 009° 67.890" from the gibberish of letters and numbers. In order to decode this gibberish again, there is the following program. Unfortunately, however, a bug has crept in at exactly one point...

The source code that must be copied for variant 2 (from <HTML> to </HTML>):