======Part 2====== =====Entries===== ====Entry 5: March 11, 2012==== For the UNIX course I am playing around with the IRC bot phenny. It's pretty cool, but since I had a ton of trouble with scripting, the scripting for this case study is taking me awhile to take care of. The idea behind bots is really cool though, just whenever you need something done based on some condition, you can get a bot to do it for you. Quite neat. ====Entry 6: March 18, 2012==== In C++ this past week we worked on Project 2 and more stuff on classes and whatnot in C++. This C++ material is something I've never been exposed to before, but it makes sense if you have a very very large program and want it to be even more organized. We also dealt with header files, which are useful as they make the code less cluttered. Regarding Project 2, it's the first thing that I had to resort to using pencil and paper to get it all organized before coding it, which I know is a good habit. Hopefully I will stay on that same track. ====Entry 7: March 30, 2012==== This past week in C++ we did a lot of playing around with inheritance and all that good stuff. We basically build classes and functions within the classes that would run logical operations and returning the boolean values. At first it was like hitting a brick wall, I would bet because the syntax was unlike anything I have ever seen before. It does make sense why one would want to do this however... for a large scale team effort on something, it would provide a good means for organization. But when it comes to my own programming, I can't really see myself using it unless I was working on something very big and very segmented where it would be a good advantage. It took awhile to understand it, but once I did the actual coding was fairly smooth sailing, I've managed to create classes and functions to perform and, or, not, nor, and nand operations. ====Entry 8: April 17, 2012==== In unix I did a bunch of pattern matching and regexp stuff. At first it was kind of hard, but once I got the syntax down it was fairly easy. I can see how it's useful, especially in word processing and stuff. It helps you manipulate information much more quickly. Which is never a bad thing. =====Keywords===== {{page>cprogpart2&nofooter}} {{page>unixpart2&nofooter}} =====Experiments===== ====Experiment 4==== ===Question=== I'm not trying to answer a specific question, but the goal of this whole thing is to figure out all that inheritance stuff in C++ using the 'project' that Haas proposed to us in class. Of making a program that will perform and, or, not, nand, nor, etc. ===Resources=== All the stuff that we've done in class. ===Hypothesis=== The result will be a working program that will perform various logic functions using boolean values, and ===Experiment=== Working on coding the program. ===Data=== So far I have classes and inheritance working for and, or, and not. I have multiple inheritance applying to nor and nand working right now. I believe the only thing left is XOR. All the files are in /home/smalik2/src/cprog/c++ ===Analysis=== It's working well, the main obstacle was the syntax behind it all, as it is unlike anything I have ever seen. ===Conclusions=== When the material was originally taught, I understand the concept behind it but not how to do it. Now I have a very in depth understanding of it and how to utilize it. ====Experiment 5==== ===Question=== In Case Study B for Unix/Linux, we were having fun with the dd command. At one point in the lab, Mason and I were combining our problem solving ability to tackle some of the more difficult questions, one of them being to add 17 bytes of information to the end of an 8kB file. We are supposed to pull JUST THOSE 17 BYTES from the file, using dd. Eventually, Mason came up with the proposed spell: dd if=test.file ibs=c count=8017 skip=8kB of=testA.file Which worked beautifully. It occurred to me that the count=8017 might be redundant, because the full file size is 8017 anyway - why would dd default to anything else? So, my question is: would that command still work if we didn't specify count? I'm betting yes. ===Resources=== None really, except maybe: man dd ===Hypothesis=== Oh I kind of already did this in the question section. I'm betting that the command will still work if we don't specify count, because count in that case was the full file size anyway. ===Experiment=== Do it with count, check result. Reset. Do it without count being specified, check result. ===Data=== lab46:~$ dd if=test.file ibs=c count=8017 skip=8000 of=testA.file 17+0 records in 0+1 records out 17 bytes (17 B) copied, 0.0441264 s, 0.4 kB/s lab46:~$ cat testA.file more information lab46:~$ dd if=test.file ibs=c skip=8000 of=testB.file 17+0 records in 0+1 records out 17 bytes (17 B) copied, 0.0454818 s, 0.4 kB/s lab46:~$ cat testB.file more information lab46:~$ ===Analysis=== Yes, I was right. It still worked. Same result. Ohhhh I love being right. There were no shortcomings in any way, and my hypothesis was nicely applicable. Very smooth experiment. ===Conclusions=== When using dd, the count argument need only be used if you need to stop copying before you reach the end of the file. For example, in a 50 byte file, let's say you need bytes 3-18. dd if=input.file ibs=c skip=3 count=15 of=output.file ====Retest 2==== Perform the following steps: ===State Experiment=== http://lab46.corning-cc.edu/opus/spring2012/jcavalu3/start#experiment_1 Josh Cavaluzzi What would be printed if I replace the %u with the $d for an unsigned integer? ===Resources=== * Do you feel the given resources are adequate in providing sufficient background information? Yes * Are there additional resources you've found that you can add to the resources list? Not particularly, it's a pretty simple concept that can be easily surmised. * Does the original experimenter appear to have obtained a necessary fundamental understanding of the concepts leading up to their stated experiment? Yes. * If you find a deviation in opinion, state why you think this might exist. I agree with everything stated. ===Hypothesis=== Hypothesis: __________________________________________________________________________________________________ I believe that the printed value will be the same ONLY if it is within the range of the signed integer data type. Ex. If the user inputs a value between 0 and 2,147,483,647, then it should print out fine, but if the value is greater than that range, then the value will “roll over” to the next integer in the signed integer data type, which would make the value a negative number. Due to the data type only covering positive numbers (unsigned integer), it can go to larger numbers in the 4 bytes it is given for memory, but if it is printed as a signed integer, then it will only be able to print out half of the positive integers that it could as an unsigned integer, so it will go back over into the negative numbers until it satisfies the amount of digits it has. __________________________________________________________________________________________________ * Do you feel their hypothesis is adequate in capturing the essence of what they're trying to discover? Yes * What improvements could you make to their hypothesis, if any? None. ===Experiment=== * Are the instructions correct in successfully achieving the results? Yes * Is there room for improvement in the experiment instructions/description? What suggestions would you make? Not realy. * Would you make any alterations to the structure of the experiment to yield better results? What, and why? Nope. ===Data=== Publish the data you have gained from your performing of the experiment here. I used his code and got the exact same results. ===Analysis=== Answer the following: * Does the data seem in-line with the published data from the original author? Yes * Can you explain any deviations? There weren't any. * How about any sources of error? Not really. Unless a computer has a different definition for an integer.. but we were using the same system. * Is the stated hypothesis adequate? Yes. ===Conclusions=== Answer the following: * What conclusions can you make based on performing the experiment? He's right. * Do you feel the experiment was adequate in obtaining a further understanding of a concept? Yes * Does the original author appear to have gotten some value out of performing the experiment? Yes * Any suggestions or observations that could improve this particular process (in general, or specifically you, or specifically for the original author). Nope