Half Way

It is time to celebrate! Today, I officially reached the half-way point, meaning to be half way through the book, after about 6 months. Last year in September I started my journey, this blog followed about a month, and 3 chapters, later. So instead of writing about my experiences with this chapter, I will tell you about my past experience with programming and programming languages. 

I started out with the Basic language, back in the day on a Commodore 64. I never got very far into it, mostly typing in long listings, then enjoying some game or other. Around 2005 another programming language entered my life, Visual Basic this time. It and I haven't been compatible to each other. Quite frankly, I didn't understand the language, the syntax, I didn't like it, yet had to learn it. I failed, and since I wouldn't need it anyway, simply gave up on it. Yet I always wanted to write my own game someday, and this would most likely require to learn a language to realize it. 

2015 was the year of experimenting around with some programming languages. I tried Java, didn't like it, C# - which I tried once before, and seemed a good choice, then Perl and finally Monoscript. It is part of Unity, so I did some tutorials the company had to offer, and bought a book or two. Eventually I managed to finish the tutorials, but when it came to realize something on my own, I could not. It was the lack of knowledge about pointers, arrays, classes, you name it. Sticking to the approach of taking a shortcut ended in the realization that without solid knowledge of at least one language, my dream will remain to be just that, and as I'm not the person to give up on anything, no matter how long it takes me to get there, this was no option.

Last year, then, closing the circle, I found the book Starting Out With C++ and bought it. It wasn't cheap, but good things come with a price-tag attached to it, so I said to myself - Here goes nothing! bought it, and finally found not only a resource I could work with, but also the language most compatible to my style. (For lack of any better word). To sum it up, despite having knowledge of html, css, melscript, some basic, close to no knowledge of VB and some other languages, I was - and still consider myself to be, a newbie. 

It started out easy, "Hello World!", and, looking back, hasn't gotten any more difficult since then. Sounds strange to say, when looking at some of my most recent struggles, particularly the one concerning the discovery of mode(s) in an array of integers. That is to say that most of the time it wasn't coming up with a way to write code for the challenges, but rather to understand the nature of the problem, and to find a way to solve it. 

Here is an example. The median function I have written for one of the challenges. Below you find part of the code that does all the work: 

   int      middleElem = numels / 2,
             midLower = 0,
             midUpper = 0;

   numels % 2 == 0 ? midLower = *(numList + middleElem - 1),
                                  midUpper = *(numList + middleElem),
                                  median = (midUpper + midLower) / 2 :
                                  median = *(numList + middleElem);

But how did I come up with this ternary, or rather this particular solution? At first I thought that I would use the subtle hint given in the problem statement in my code somehow: 

"If the set contains an even number of values, the median is the mean or average, of the two middle values."

It was clear that if there is an even number, there has to be an odd number, and to find it would necessitate to use the modulo operator, to find out whether the number of elements is odd or even. To find a mode in an odd-numbered set would be straightforward, so my first thought was to implement a binary-search, which would find the middle-value. I tried, then reconsidered. 

What would a binary-search actually do? It would solve one half of the problem, but how would this look like? Should I call this function to do the search if a number is odd, and then call another function if it isn't? No, there must be a more straightforward solution to this, revolving around the central idea of odd and even numbers. I sat back, thinking, and taking a closer look at a different part of my code:

  *(numList + startScan) = minEl;

This line is part of the sorting function. And seeing how startScan is used there, and how it is used in the search function, I started seeing a connection to my problem, and how I can solve it. I knew that it is about odd and even numbers, and that an even-numbered array would contain two middle values, one in the upper, one in the lower half. So why don't I use this, initialize middleElem to calculate the halfs, reverse the condition by assigning to variables the numbers in the upper half and in the lower half? This is what I did, and it worked. All because I found this connection between the line of code I so often used to perform a sort on numbers, I found the key to solve the problem, by combining everything in a single ternary operator. 

Ternary, in my opinion, is a misnomer. In or around chapters 7 and 8 I found out that it is very well possible to chain ternaries, there is practically no limit. You only have to replace the : with another condition. condition ? condition1 ? condition2 ? condition 3? x : y. I tried in one of my programs, but refrained from actually using the piece of code, even though it worked. Because something works doesn't mean you should use it, as it would guarantee to make it nigh impossible to read, as well as difficult to understand for others what the piece of code actually does. Ternary being a mighty tool making for short, yet still readable code, if done right. This is why I so like it, as in the above example, one line of code does it all. 

Back to this line of code once more:

*(numList + startScan) = minEl;

To discover that it holds the key to solve the above mentioned problem also was key to solve the Reverse Array, Array Expander and Element Shifter challenges. The only challenge has been to figure out the counters, as in one challenge the counter had to count up, the other down in one challenge, and in one of the others both had to count up. This took a while to find out, but was no major hurdle, just a matter of switching the counter variables around several times. And again the key has been a line of code from the sorting function:

*(numList + minIndex) = *(numList + startScan);

to come up with this one line in the Array Expander challenge:

 

*(expanded + count) = *(numbers + count); 

But what about pointers, since this chapter has been all about it, and I haven't yet lost a single word on them? Well, at first I felt a little intimidated and insecure in the early challenges, always thinking: Am I doing things right? Luckily the first couple of challenges fostered some confidence. This was quickly destroyed by the mode challenge. 3 weeks, the longest time it has taken to finish a challenge! And it wasn't even the pointers, but enough of this one, I will not wish to be reminded of it - ever - period. Summarily I can say that I feel rather comfortable working with pointers now, and that I very much like what I can do with them, as well as the pointer notation. I like it more than array notation, so I think you will see more of it in the near future. 

For now I deserve some rest, before I dive into the 10th chapter. This one will be about C-Strings, Characters and the string Class, which I do not yet know I will like, the topics, that is. But as it is a part of the book, I will make the best of it. Rest assured that I will be back soon with more code. Until then I wish my fellow learners that they be soon finished with this chapter, and that they be able to make such important discoveries as i did. To my readers, regular or otherwise, thanks for your visit!