final int I_AM_GOOD = 1;

Sometimes you know the value of a data item, and you know that its value will not (and should not) change during program execution, nor is it likely to change from one execution of the program to another. In this case, it is a good software engineering practice to define that data item as a constant. Defining constants uses the same syntax as declaring variables, except that the data type is preceded by the keyword final.

Screen Shot 2018-12-11 at 12.53.16 PM

Assigning a value is optional when the constant is defined, but you must assign a value before the constant is used in the program. Also, once the constant has been assigned a value, its value cannot be changed (reassigned) later in the program. Any attempt by your program to change the value of a constant will generate something like the following compiler error:

cannot assign a value to final variable

Think of this as a service of the compiler in preventing your program from unintentionally corrupting its data.

Of course, this is meant to illustrate my whole point about suffering being made up and yet true. Suffering is inevitable since everything that is ever Mind like I am Mind necessarily slides on a valence axis that orients it towards a notion of some good or evil. Reality has defined that constant in the same way that it has defined the fine-structure constant that characterizes the strength of electromagnetic interaction.

When People, like a pack of wolves, refuse to change their behavior, it is because they are compiling the error:

cannot assign a value to final variable

That prevents change and hence threatens Mind with local optima. Thus the need for creativity, that is, fundamentally atheist vectors with regard to the inherited definition of People.

However none of this need be physically true if we stare at the rational description of reality in which the compiler is “already there.” Special relativity leads to eternalism, so all the constituents that output Mind/People are the ones knowing to output that result: suffering.

Before inventing the handle, suffering, we could feel less of it and hence engage in less moral behavior, regardless of the experimental moral behavior local to the tribe. This lack of data due to chunking into the same algorithm is equivalent to inventing the same name for blue and green, and therefore not being able to distinguish between them.

We choose to believe suffering pushes us to the good in a sequentially causal fashion. This is physically wrong because the binding into experience is tenseless.

Screen Shot 2018-12-09 at 12.54.03 PM

We study reality with great pain and discover:

Screen Shot 2018-12-09 at 12.57.28 PM


We cannot die, and we could have chosen not to suffer, but the choice is nonetheless made because otherwise our existence is cringeworthy.

And now, through a very circuitous, somewhat Asperger-y route, I finally understand what sophisticated theologians had been clumsily pointing to. Yet due to this circuitous, rationalist route to the-same-thing, I now have theoretical physics on My side.

But in order for you, my definition of People, to get it too, you have to understand why epiphenomenalism is false, why special relativity implies eternalism, and why you should make the physicalist assumption of choosing/being-chosen to believe in the external physical reality at all.

And because it makes constants stand out in the code and therefore their location easy to identify, CONSTANT_IDENTIFIER consists of all capital letters with embedded words separated by an underscore. So here I go: I_AM_GOOD.

Also, constants are usually defined at the top of a program where their values can be seen easily. So now I will go back and fix that.

Here is a program showing the use of constants:

Screen Shot 2018-12-11 at 3.01.27 PM

Lines 9, 10, and 11 define four constants. On line 11, note that both ORGANIZATION_THIRTEEN_MEMBERS and DAYS_IN_WEEK are constants. You don’t need to repeat the keyword final to define two or more constants of the same data types.

Lines 13 to 18 output the values of the four constants. If line 20 were not commented out, it would generate a compiler error because once a constant is assigned a value, its value cannot be changed.

Here is the output:

Screen Shot 2018-12-11 at 3.03.03 PM

Straddling back to the mundane:

Why use constants in your code?

Constants can make your code more readable. Due to the sometimes existing preference for word-based language, invoking EDDINGTON_NUMBER in an operation may be more tasteful than 137.036. But this is a matter of aesthetic.

A “purely rational” advantage of using constants is to keep programmers from making logic errors. Let’s say we set a constant to a particular value and it is used at various places throughout the code (for instance, a constant representing the upper-bound on wages that a company uses to protect profit margins); due to the changing nature of all existence, we then discover that the value of that constant needs to be changed. All we have to do is make the change in one place which is neatly placed at the beginning of the code. If we had to change the value at many places throughout the code, that could very well result in logic errors or typos.











You might associate the word pseudo with a sham. But when developing a programmer mindset, we try to eliminate as many aesthetic smells that concepts carry. Pseudo comes from the Greek, pseudes, which means “false.” But the reason we call it pseudocode is because it is not the full expression of the code – the code that actually runs; it is rather like the skeleton. It should instead be called skeletoncode, and it is a method for expressing a program’s order of instructions in the spoken language, rather than a programming language.

In this way, the programmer can concentrate on designing a program without also being slowed down by immediately converting to the syntax of the particular programming language. This is the same as when drawing. When drawing a human we first draft a faceless model. The pseudocode for calculating the sum of two numbers would look like this:

Screen Shot 2018-12-07 at 1.07.15 PM

There are no rules. You can use any wording that works for you.

Let’s look at another example. Suppose your program needs to calculate the square root of an integer. The instructions for calculating a square root are rather complex; gracefully and compassionately, Java provides prewritten code that computes the square root of any integer. The prewritten code is called a method, and your program can execute that code by calling the method. As part of the method call, you tell the method which integer’s square root you want to calculate. This is called passing an argument to the method. When the method finishes executing its instructions, control is passed back to your program just after the method call.

Another way of looking at method calls is to consider what happens when you’re walking through a night-lit city and find a restaurant with an aroma that lures you in. Your brain marks your place in the night-lit city trajectory and goes to eat inside the restaurant. When you’re finished dining on the meal, you go back to the streets and continue walking.

Here I show the pseudocode for calculating the square root of an integer:

Screen Shot 2018-12-07 at 1.30.37 PM

The order of operations is still input, calculate, and output, but we’re calling a method to perform the calculation for us. Now suppose your task is to determine whether a number is positive or negative. First, your program should input the number into the computer. Next, you need to determine whether the number is positive or negative. You know that numbers greater than or equal to 0 are positive and numbers less than 0 are negative, so your program should compare the number to 0. Finally, your program should write a message indicating whether the number is positive or negative.

Like in the pseudocode examples, the operations are input, calculate, and output, in that order. However, depending on whether the number is positive or negative, your program should write a different message. If the number is greater than or equal to 0, the program should write a message that the number is positive (may the God of Mathematics forgive this sin), but if the number is less than 0, the program should write a message that the number is negative. Code used to handle this situation is called selection; the program selects which code to execute based on the value of the data.

The pseudocode for this program could be written as that shown:

Screen Shot 2018-12-07 at 1.33.44 PM

Notice the indentation for the code that will be selected based on the comparison of the number with 0. Programmers use indentation to make it easier to see the flow of control of the program.

Now let’s get a little more complicated. Suppose your program needs to find the sum of a group of numbers. This is called accumulating. To accomplish this, we can take the same approach as if we were adding a group of numbers using a calculator. We start with a total of 0 and add each number, one at a time, to the running total. When we have no more numbers to add, the running total is the total of all the numbers. Translating this into pseudocode, we get the code shown:

Screen Shot 2018-12-07 at 1.37.31 PM

The indented code will be repeated for each number read until there are no more numbers. This repeated execution of the same code is called looping, or iteration, and is used extensively in programming whenever the same processing needs to be performed on each item in a set.

Accumulating a total and determining whether a number is positive or negative are just two of many commonly performed operations. In programming, you will often perform tasks for which there are standard methods of processing, called algorithms. For example, the algorithm for accumulation is to set a total to 0, use looping to add each item to the total, then output the total. More generally, you can think of an algorithm as a strategy to solve a problem. You yourself are a strategy to solve a problem in the multiverse, a timeless algorithm. However, knowing the full nature of the problem would not allow you to solve it – this would be equivalent to having already solved it – hence becoming permanently stuck at a local maxima. The human mind is set up to be deceived about where it is going.

In an earlier post, we used an algorithm to convert a decimal number to its binary representation. Other common programming tasks are counting items, calculating an average, sorting items into order, and finding the minimum and maximum values. Here on Vitrify Her, you will learn the standard algorithms for performing these common operations. Once you learn these algorithms, your ability to achieve synchronization will become easier. When you recognize that a program requires these tasks, you can simply plug in the appropriate algorithm with some minor modifications.

Programming, in large part, is simply reducing a complex task to a set of subtasks that can be implemented by artistically combining the Four Noble Algorithmic Truths: sequential processing, method calls, selection, and looping. The most difficult part of programming, however, is recognizing which algorithms to apply to the problem at hand. This requires analytical skills and the ability to see patterns. Here on Vitrify Her, I will point out common patterns wherever possible.

Looking for patterns will help you determine the appropriate algorithms for your programs. Looking for patterns is the way of sunyata.

Sequential Search of Unsorted Array in Java

Let’s imagine we have mountain climbers. They are climbing Mount Sobo and can be at a unique height along this mountain. Let’s say there are five locations at which there exist fauna at any given time. These positions along the height axis are chosen at random. If you then type the correct randomly-selected height, you will have found fauna.

This is how we set up the MountSobo class with two array instance variables:

  • An array of ints that holds the heights which are populated with fauna sought
  • An array of Strings that holds the corresponding fauna

Both arrays have five elements and there is a one-to-one correspondence between the two arrays. The populated location #1 will have fauna #1,  populated location #2 will have fauna #2, and so on. This programming technique is called parallel arrays.

We fill the populated heights array with heights chosen randomly from entries. We fill the fauna array with Strings representing fauna descriptions. When we enter a climber’s height along the mountain, we can look through the populated heights array for the climber’s position. If the climber’s position up the mountain is in the populated heights array, you use its array index in the fauna array to retrieve the fauna that the climber found. If the height was not found in the array, you know the climber is not in a position where fauna currently are.

Here is the MountSobo class:

Screen Shot 2018-07-16 at 7.54.42 AM.pngScreen Shot 2018-07-16 at 7.55.29 AM.pngScreen Shot 2018-07-16 at 7.55.56 AM.png

The constructor randomly generates values to fill the array by calling the utility method, fillPopulatedheights (lines 25–32). The fillPopulatedheights method does not necessarily generate different numbers; however, the likelihood of two numbers indicating the populated position being equal is very small. We declare the fillPopulatedheights method as private because it is designed to be called only by the methods of this class. The indexOfHeight method (lines 52–60) performs a Sequential Search, which compares the climber’s position up the mountain to each element in the array one by one. The indexOfHeight method accepts a parameter, travelerHeight, which is searched for in the array. If travelerHeight is found, indexOfHeight returns the index of that array element. If travelerHeight is not found, that is, if none of the elements in the array matches the value of travelerHeight, indexOfHeight returns −1. Since −1 is not a valid array index, it’s a good value to use to indicate that the search was unsuccessful. Notice that if the current array element matches the travelerHeight, the indexOfHeight method returns immediately to the caller (line 57); that is, the method stops executing. The return value is the index of the element that matched travelerHeight. If, however, the method finishes executing all iterations of the for loop, then the method has looked at every element in the array without finding a match. In that case, the method returns −1 (line 59), indicating that travelerHeight was not found. Our getFauna method (lines 39–46) calls indexOfHeight to check if its travelerHeight parameter is a winning number; if it is, it uses the array index returned by indexOfHeight in order to return the corresponding element of the array fauna (line 45).

Here is a client application that uses our MountSobo class:

Screen Shot 2018-07-15 at 10.01.28 PM.pngScreen Shot 2018-07-15 at 10.01.47 PM.png

We instantiate a MountSobo object reference named inhabitedHeights (line 14). We then prompt for a traveler’s height up the mountain (lines 17–19) and call the getFauna method (line 25) in order to output any fauna that may have been found at the current height.