Charles Devlen spring2020 Journal
Hello, I'm Charles Devlen. I'm one of the Greater Southern Tier STEM Academy students, majoring in Information Technology. Some of my interests are old radio and stereo maintenance, reading Sci-Fi novels, and retro game emulation. My main pursuit, and overall life goal (for now) is to eventually begin a career in Software Engineering or User Experience Design.
This week was an interesting one in terms of course progression. As mentioned in my last journal, the gfo0 coding was finished on Wednesday of last week, I added comments on Thursday, and submitted it. My output was about .5 or so of a point higher, but after an email confirming my grade was in the ballpark, I was content to move on, especially considering I couldn't find any error in my process. That only left the pctC project, and I was eager to get started on that so I could move on to the eoce. Other classwork interfered, however, and I didn't get a chance to do it until Sunday. That project went very well, again, I don't have much to say about the pctC project, as I used my same process, except borrowing 12 where appropriate and using a number range of 0-11. If anything, I had more of an emphasis on establishing relational chains than doing math in pctC, which is opposite of the way I normally complete these projects. I think my time from start to finish was faster than any other pct I had done before, which felt good, as it means I am starting to get better at logic puzzles (which is what a lot of coding is). On Monday, I started the eoce, and I really enjoyed making the menu for the 0x0 section. I got really hung up on the insertlist() function, and I spent hours trying to troubleshoot it, and by the end of the day, throwing in the towel in frustration. The next day, I took another look at it, and had a thought that should have occurred to me earlier; the problem could be with my readlistfwd() function instead of the insertlist() function. I took one glance at that function, and immediately solved the issue. I had made a typo in where I ended the loop I was using to read my array. Instead of breaking out of the loop when list[count] == -1, I was having it break out of the loop when list[count] != -1. That meant as soon as I inserted a 1 into the 0th element of the array, the loop reading my array back to me immediately exited, and I got no output. I replaced the ! with a =, and that solved the issue. That was a big lesson I learned this week, to always check your associated functions for error, and to not just narrowly focus on the function you think is the issue. I'll definitely be sure to look out for that again in the future. I started 0x1 today, and after some head scratching, I actually have some very functional code for that section. I still need to make the output formatting correct, but my math works great and that will be a fairly easy thing to correct tomorrow. I also sanity checked my process by sending a quick email, and it was very gratifying to know I was going about it in the right manner. I am also trying to be a bit more independent with my coding and push myself to think more creatively to solve issues I'm having, and it seems to be paying off. I'm now able to solve most issues I come across, and I am fairly (except for the aforementioned mishap this week) adept at troubleshooting my code. Overall, I'm feeling satisfied with how this week went, and how the course as a whole is going.
One of the things I learned about this week was the process to find nary() values, as well as getting reminded to never have manual redundancy in my programs. I got the process for reading the range into an array for the cnv0 project down pretty quickly, and I knew what math I needed to do to check the number of factors, but I wasn't properly implementing the math. I was only checking the number of factors once, and then incrementing my number, but in order for it to work properly, all the factors had to be examined, and then have the number increment after the factors were all checked. Once I had this math down for my findingprimary() function, I realized the same math could be used to determine which numbers in a range were other nary(#) values as well. I then majorly screwed up by essentially copying and pasting 16 different versions of this same function and renaming the variables. That was really bad practice on my part. I was having trouble with not checking for factors correctly (although I didn't know it at the time) and sent out an email asking for help. When I got the response, the first thing that was said was “you’re committing one of the cardinal sins”, which was making 16 separate functions. They all could easily be merged into a single function, which I proceeded to do, and that made troubleshooting my math issue much simpler. I can’t believe I hadn’t seen that before it was said, and I will always check for that redundancy in the future. I actually managed to get that project done 2 days before it was due, which is a new record for me, usually I only get the non-pct project done the day before it's due. I then began work on the base 11 puzzle, which I don't have too much to say about in terms of solving, I used basically the same process as usual, just accounting for a different range of 0-10 (A) and borrowing 11 when appropriate. The most noteworthy thing about this puzzle is that it reminded me of a very important lesson: always save your work frequently. I had a version of the project from the day before that was about one page long, and then I proceeded to do the entire project, and finish it from that point without saving once. I copied and pasted it from Notepad into Word to do some spellchecking, spellchecked it, corrected some grammar, and I had a project I was about ready to submit. Of course, it was at that time my computer died, and when I rebooted, all my work was gone, besides the one page I had from the day before. I had 1,900 words in that document, and 13 pages. It really sucked to have to redo all my logic and my writing, so from now on, I will compulsively save my work while doing it. Today, I actually started and (I think) basically completed the gfo0 project due next Wednesday. I wanted to do this so I would have the maximum time possible for the eoce. The output seems to conform to the example, and my average seems to check out pretty well when I compare it using the status cprog command and averaging it on a calculator, so I think it's good, besides it's lack of comments. For the process, I don't have much to say honestly, I feel as though I am really starting to get some of the aspects of C I used to have trouble with, and it definitely has made me feel more confident in my abilities (without being too overconfident). It was a project where I pieced together most of what I know, and I'm fairly proud of how it's turned out. I will not know how correct it is until tomorrow, however, given that it is 10pm as I write this. Overall, I couldn't be happier with how this week went, and I'm looking forward to taking on the eoce.
This week I learned about a lot more about pointers, memory allocation, and functions. In the afn0 project for this week, I first established a math process out on paper for how I would attempt to set up the top number in the subtraction, as well as the bottom number (which was fairly simple, 9-array[count]). Setting up the math on paper helped me work out how I was going to make my program, so I wasn't making it up as I went, and I'll do that in the future now as well. I established my main() function as well as my longint2array() and printarray() functions. I had the processes inside the functions worked out fairly well, due in part to doing my math by hand first, but I was returning my arrays completely wrong, and calling them incorrectly. After some emails back and forth, I was finally calling my functions somewhat correctly, but not capturing the return values, and I had a strange segmentation fault issue that I couldn't for the life of me figure out. After a couple more emails, I got a really great description detailing how memory allocation (both normally and behind the scenes in arrays) worked, as well as a great explanation on how pointers work. Also included in the email was a “delightfully weird” video, which I thoroughly enjoyed, that detailed how pointers, their dereferencing, and how pointer assignment worked. The visual claymation style of it really helped me mentally visualize what was happening with pointers. I plan to save both the video and the email to use as a reference guide for future use. Basically, I was both calling an array (which allocates memory) AND allocating that array as a pointer (which also allocates memory), which made it a double pointer. This basically was causing my longint2array() to reach beyond the memory that was allocated when I declared the array like: unsigned char *array. This was what was causing my segmentation fault error, and so I changed the way I declared the array to:
unsigned char *array = NULL; array = (unsigned char *) malloc (sizeof (unsigned char) * count);
This essentially declared array as a pointer, and then set that pointer equal to an unsigned char array that had a size of count (which was the number of digits in input). This allowed my arrays to be more flexible and fixed my double pointer issue (and my segmentation fault). I then corrected some of the math in my code to reverse the input and read into the array properly, changed the fprintf() and fscanf() statements for my input and math statements to have a format specifier of “%lu”, for unsigned long, and I had a program that worked quite well. As for pctA this week, there is surprisingly little for me personally to say, it was a base 9 puzzle, and that meant 9 had to be added for borrows instead of 10, but once that modification was made, I could use my usual method of plugging possibilities into subtractions and narrowing down the numbers after establishing some basic relational chains. I was actually able to complete this project 2 days ahead of schedule, which was a new personal best. Overall, I am extremely satisfied with how this week went.
This week I learned how to do basic math on a base 8 numeric scale, which is interesting. In the pct9 project, the math was all base 8, and so the numbers that had to be found were 0-7 instead of 0-10. The other trick to solving problems in this manner is that when borrows occur, you have to add 8 instead of 10. The trick I learned last week where you find some rules and then plug and chug values in order to narrow possibilities worked great with this project. I was able to find the solution with about the same amount of effort as the base 10 puzzles, which was great. There was a quirk once I found the solution though; every subtraction in the check worked, but when plugged into a calculator, the math didn't work. After an email, I realized the reason that was happening is because by default, a calculator uses a base 10 number system, and so the solution would be different. When the numbers are plugged into a base 8 calculator, the solutions match. As for sam0, this week I figured out the math for looping Aa to Zz, which is dividing the key using % by 26, so there's no remainder, and once that key is added to byte[count], subtracting 'A' or 'a' respectively, in order to accomplish a loop. However, I have run into several issues with the code now, including not encoding all of the message, not applying my mathematical changes, and getting seg-fault errors when my code is run using a key from the command line.
This week, I discovered the use of argv for my sam0.c project. The actual encoding and decoding math portion (excluding wrapping a to z) was fairly simple, and I found most of my time was actually spent trying to get both encode and decode in the same program. That's where argv came in, as it is the name of the file being run. Seemingly, a simple if() statement would do the trick for differentiating between encode and decode. That was not the case, however, as I had to find a new command called strcmp(). I used strcmp() around the argv value to compare it to a string filename, and verify the statement was true, by using a lengthy if() statement, (if(strcmp(argv,“./encode”)==0). This worked perfectly. Now my only issue is wrapping a to z if the key value is over 26, or if the value of a letter goes over 26. For the pct8 project, I was very stumped for quite a while working on it. I had to devise a new way of solving it, which basically meant taking the one number I found (K=9), and plugging it in to subtractions with 2 unknowns that had an established rule. For example, I knew H had to be half of L, and I had the subtraction K-L=H. Plugging in all the limited possibilities for H, and comparing them to the limited possibilities of L, I could narrow my numbers. This worked great, and is certainly a strategy I plan to use in the future. Overall, I think this week went really well in terms of time management and question asking, I asked many questions, started the project somewhat early, and was definitely benefited by it.
This week the cbf0 project was again due. I had been working on it as much as I could, and had made some progress, but I was still going about it wrong. I had been using a for() loop to try and get the right output, but that isn't a flexible way to do it, as if the file didn't end on the 16 byte mark, “ff” would be printed for the remaining bytes. I instead learned how to use loops inside a loop, and to make an array that the data was read in and stored in one byte at a time. This allowed for a flexible reading of the file. Unfortunately, the project still isn't perfect, there's no sizing throttle for amount of lines displayed, and there was still an unprintable character in my output. I really was able to kick up the amount of time I could allocate to working on the project this week, but yet again, ran out of time. I ran out of time because while I did have questions, I just tried to chug through them instead of ask them, and yet again ended up asking them slightly too late. I did ask far more questions than the previous time, however, but I still should ask more. My takeaway for this week is to always ask questions so you don't get hung up on a small aspect of a project.
This week I learned quite a bit in regards to argument arrays, the gd graphics library, and doing more complex math in C. I learned how to use argument arrays, which take an argument from the command line, and assigns it to an argv variable in the code. When you input numbers as arguments, however, there's a command that's necessary to convert arguments to an int type. This is necessary for doing some of the math and making comparisons such as <,>, or ==. Double was also a variable type I learned, which makes it possible to do math such as sin() cos() and tan(), among other types of math functions. This was very helpful as I needed both sin() and cos() in my math equations for this project. The <math.h> library was also a necessary step, as it included all the commands for sin() and cos(). An odd quirk of C I found out this week was that there is no pi variable that is baked in that can be called. Instead, pi has to be defined as 3.1415… to several decimal places, or acos(-1). This was crucial given I was using equations for circles. Overall, this was a very successful week in which I got quite a bit done in a reasonable time frame.
Filler text- your entry goes here; remove this line to receive full credit.
Filler text- your entry goes here; remove this line to receive full credit.
This week I was able to get more done in advance, and learned how to use if() statements in order to accomplish certain tasks within C. I managed to get the whole of dow0 done by Tuesday, which was nice, as usually I'm working against the deadline much more. I'm becoming better at devising mathematical ways to isolate terms within C, and learned the use of % ==0, which is division except that if that number has a remainder, it is not absolute, and that was very helpful to use in an if() statement for the leap years in dow0. As for pct4, I was able to complete it based of verifiable assumptions I made and the cross verified in some cases, which is a helpful thing to know how to do for the purposes of future pct projects.
This week the pct3 and sof0 projects were due on Wednesday. For the sof0 project, it took me quite a while to be able to learn the proper syntax of various commands, and figure out the math of isolating the number. For the equation to isolate the non-5 numbers I used: (((input/10)-0.5)+1) * ((input/10)-0.5). This when plugged into a calculator and appended with a separate 5*5 function flawlessly output the squared value of numbers ending with 5. I then decided to combine the +1 and -0.5 into a 0.5, but failed to follow it up with the necessary steps to yield the correct result. Yet the program somehow worked flawlessly. After I realized the flaw in the program, however, I couldn't be satisfied with the right answer without knowing why. So eventually, I determined that because it complies to binary, there is no binary representation for a decimal. So yes, it rounds down to zero, meaning that of course the input value that would have a 0.5 at the end (for example, 125/10 = 12.5) would drop the decimal, making my math work perfectly. I also learned how to output using fprintf() to either stdout or stderr. This was absolutely crucial for this project, as without it the checksum would mismatch. For pct3, even though it was a harder project, due to the various and extensive methods I uncovered last week, I actually found it much easier.
Filler text- your entry goes here; remove this line to receive full credit.