Entity Collision

So I have been working on my Physics Engine recently, and I've happened upon a rather interesting conundrum. In logic, it is rather simple to detect when an falling entity collides with a box; It's easy tell when the ball hits the ground. However, it is not at all easy to tell when a ball hits another ball, the algorithms just don't work that way. After a little bit of research, I have discovered that no Java library handles anything to do with collision boxes of circles, and I have to write my own. My approach right involves a rather tedious and heavyweight process of calculating the distance from center to center of one ball to every other ball, then comparing that distance to the sum of their respective radii. If that number is greater than the distance, then I must do further calculations to determine the angle of collision. Like the picture on the left, I can use the differences in x and y coordinate values to calculate that angle, but what do I do from there? Well, once I have that angle, I plan to apply the great and powerful Law of Conservation of Momentum, to determine the outcome, and here comes the tricky part. In Physics, many of the collision problems we are required to solve are called elastic collisions, in which no kinetic energy is lost during the collision.

I have noticed, however, that in the simulation, this results in an unreal behavior of bouncing, which makes sense, considering all real-life collisions (including the one one the right) are inelastic. This means that I need to assign some arbitrary dampening value to collisions (in the previous post, this value was set to 10%). So, like I said, this wasn't easy, and I haven't quite got the algorithm working perfectly, yet. But I plan to keep working on it and get it nice and optimized for my presentation.

Thanks for reading!

- Jeff 

A Visual Conclusion

The time has come to start considering how to structure my presentation. While it is necessary to show my data that I have collected and show my statistical analysis, I need to keep it interesting. I plan to show, as well as prove, the complicated differences in Java and C++. It may be easier for me to stand up in front of a powerpoint full of numbers, and explain how I derived my conclusions, but I want to allow my audience to make those conclusions as well. It is for this reason that I have been working on a couple programs, one in Java and one in C++. These programs, called Physics Engines are designed to replicate the behavior of real objects (in my case, in two dimensions). Having the ability to visual demonstrate the differences in Java vs. C++, I think, is going to make my presentation that much more compelling. As Mr. Mac said to our Physics class, "You want to make your audience feel smart at the end of your presentation." I think that this is the best way to do that. To allow my audience to see for themselves the numbers and data that I can rattle off like an auctioneer, will make the biggest impact to my audience.

Thanks for reading,
- Jeff

// Commenting Code

Comments segments of text placed inside of source code that are not compiled. They serve simply to help the programmer and user to understand what the code is doing and why. There are many different types of comments, as well. Among others, there can be title comments, documentation comments, even legal comments. For example, many commercial Open Source projects must add in the GNU Public License, in the form of a large block comment, to the top of every file in their code.

/*
* This is a block comment.
* It is not compiled. It is only used for    
* notation purposes.
*/

Comments must be led by a specific language-defined character or characters that tells the compiler, "This is a comment, please ignore." As an example, Java uses double slashes (//), and Shell Scripts use pound symbols (#). In the picture is my testing script that I wrote two weeks ago. All the gray text is commented code. Obviously, I went a little overboard on the comments, as most of what was said in them can be easily inferred from the actual code. This style of commenting is typically frowned upon in larger programming projects, because some say that it clutters the code even more. A popular saying among programmers is, "Don't comment code, comment decisions." This limits comments to only the most important statements.

Interestingly enough, the Java JDK includes a tool, called Javadoc, that allows programmers to make code documentations from their comments, using keywords like "@params ... " and "@returns ... ." Using Javadoc may be one of the only times where it is necessary for the programmer to heavily comment every public method in all their classes.

In conclusion, comments are a good way for a programmer to write down what his intentions are for the code, and note any important or confusing code. As long as they are not overdone, comments can be incredibly helpful.

// Thanks for reading, as always!
// -Jeff

C++ Test Results Are In!

Feel free to click on this photo to enlarge it!

Above you can see some results that I have collected from the students of Dr. Bazzi. I concealed their full names for privacy reasons.  And of couse, Dr. Bazzi has many more students than just nine; I only used the programs that passed all of his tests and received 100%.

In the above tests, I had the compilers compile and run my own custom-written programs, which were considerably more cpu-intensive than the default test files. It is important to note that the students wrote these programs to pass the tests, not for speed, so optimization was not a factor in their programming. However, I believe that this fact does not ruin the integrity of the tests, as both Java and C++ programs will have been written sans-optimizations.

The runtimes are measured in seconds, using the GNU "time" command specified for "User Time." This means that the run times do not include system I/O, only pure computation times. The reason we do not want to record system I/O time is because that time can vary huge amounts on different machines and different hardware. It can even vary based on where the program is reading/writing in the computers file system!

 I find it quite interesting to see the massive amount of differences in runtimes between the programs (ak vs. cm, for example). And I will be going into much more detail about the nature of the tests run in my presentation, and this is by no means a formal explanation of the data. I just thought that you may want to see a little glimpse of some of the data I am collecting. Thanks for reading, and stay tuned!

-Jeff

Fighting bugs

For the last few days I've been fighting bugs. I've started work on a secret Java project (oh boy!), and as with any big project, there are always bugs. I've squashed a few of 'em, yet more seem to keep working their way out of the cracks, those sneaky little punks. Below is one of the nastiest bugs I've encountered so far. It's a null pointer exception seemingly coming from within the Java virtual machine, but I highly doubt that. Usually, these kinds of exception print out exactly which line of code is causing the issue, but this one is a little more difficult. What I have to do is retrace all my steps and work my way through the flow of variables until I find it, because someone somewhere is calling a method on a null object and it's my job to hunt it down and squish it.

So rather than fix it right this minute, I'm going to blog about it. Because why not?

When a critical error occurs within any higher-level programming language, the code does something called "throwing an exception." When the code throws an exception, it immediately stops what it's doing and follows its path all the way up the program stack, recording every step it takes so that it can print out something useful for the debugger. In the picture, all the lines that start with "at" are steps that the exception took before it printed this error message. If the exception works its way all the way up the program stack without being caught, it kills the program and prints its message to the computer's console. If the programmer is expecting an error like this and wants to handle it in a specific way, he can put the problematic code inside a try{} catch{} statement, and any exception that matches the exception specified in the catch's parameters will stop right there and execute the code inside the catch's block.

 Using these techniques it is possible to make a program more "robust" by being very thorough and catching any error that could possibly occur during normal program usage. If your program is designed for security reasons, like a bank account application, it is imperative that it catch any and all exceptions, so that the bank's servers can remain operational. Otherwise, it would be easy for any hacker to input some malformed code and gain access to the bank's private information and money. So yeah, in today's society, programmers can have just as much responsibility as an armed guard in a bank.

Well, thanks for reading, and everyone enjoy your spring break! (I know I will) 

-Jeff

A day in the life of a Computer Science student.

So today I impersonated a Computer Science student, and attended CSE 340, a class that Dr. Bazzi teaches. It was very interesting, and quite different from my current Computer Science class at BASIS. First of all, at the 340 level, the students are assumed to know how to program, so the course is not teaching students to program. Instead, it is much more abstract and theoretical, like the difference between learning Calculus and learning Calculus-based Physics. It is already assumed that you know Calculus when you enter a Calculus-based Physics class. For example, in my current CS class we learned about variable types and their significance. In CSE 340, we learned about what makes data types equivalent and to what extent can we allow them to be equivalent. Let me explain.

Equivalence Types:

There are two basic forms of equivalency, name equivalency and structural equivalency.

According to name equivalency, we can say that two types are equivalent if they are declared to be of the same built-in types or the same programmer-named type. This is a simple definition, created by the syntax and semantics of specific programming languages, but why are they defined this way? What are the underlying reasons for name equivalency? That's where structural equivalency comes into play.

Structural equivalency is where the definitions get much more complicated. When we got to this point in Dr. Bazzi's class, he projected a sheet of information onto the board that looked more to me like Math than Computer Science. I quickly copied down five definitions of structural equivalency.

The following are the limitations that Computer languages must follow when defining their variable's equivalency rules, called permissive structural equivalency.

We can say T1 and T2 are structurally equivalent if
1. T1 and T2 are the same basic type 

2. T1 = pointer to t1
     T2 = pointer to t2 

3. T1 = struct {
a : t1;
a2 : t2
}
     T2 = struct {
         a : t1
 a2 : t2
    }
    and ti is tructurally equivalent to t'i for i'=1 to k 

4. T1 is array range1 of t1
     T2 is array range2 of t2
     AND
  a) range1 and range2 have (1) the same number of dimensions and (2) the same number of entries in each dimension

  b) t1 and t2 are structurally equivalent 

5. T1 = fuction of (t1, t2, ... tk) returns t
     T2 = function of (t'1, t'2, ... t'l) returns t'
 AND
  a) is structurally equivalent to t'i and
  b) t is structurally equivalent to t'

It's amazing how much Computer Science is similar to Math. As Dr. Bazzi told me in our first meeting, "Math is very important. Computer Science is just another way to write Math."

I enjoyed getting a glimpse into the world of a Computer Science student at ASU, and I hope you enjoyed reading about it. Stay tuned!

-Jeff

Finally, Data!

Below, you are seeing a Terminal output of one of ASU's Ubuntu servers. I ran my new and improved script on it, and finally, I got data! After hours of debugging my stupid mistakes, I finally got it to work. On the top of the screen is my verbose output version I had to write in order to debug the problems, and on the bottom is the data. It's not much now, but it will grow. With this tool that I have written I can easily modify the commands to test different aspects of the computer language, and print it to the terminal. I plan to gather all this information into spreadsheets and use it to create both comprehensive and comprehendible graphs for my audience.

Ubuntu's XTerm successfully running Jeff's Testing Script v2.0

About the Script: 

I rewrote my first shell script to be much more robust and much more comprehensive. I cracked down on integer overflow and avoided executing any commands inside my timing loop besides the target program. On top of that, I rewrote my timing function to average the results of over 20 tests, giving me much more accurate, and much more trustable data. While testing my script, I noticed that the first result  of the timing tests was always slightly slower than the others, I suspect this is due to some program initializations that go way over my head. Regardless, I took this into account in my script and subtracted the first value from every test in order to reduce any inaccuracies caused by it.

In conclusion, I have finished construction of my program testing script, a tool that is going to help me collect the necessary data I need to back up claims in my report. Next thing I need to do is begin gathering all the data on as many programs as necessary. That's all for this week, and thanks for reading!

-Jeff