EncapsulatedWorld

Combat Arms

2008-08-02T01:27:00.000-07:00

Well a friend of mine found a new game, and, cheap ass that he is its a freebie.

Actually turns out its a pretty fun. Like, mindless Counter-strike fun, only more mindless. And less polished.

The game is called Combat Arms by Nexon. It's a free-to-play fps with a level system that unlocks new toys and an in-game currency that you use to rent items for a time to play with. Overall I'm having a lot of fun with the game. Started an 8v8 with my friend on Cold Seed and it was 1v1 for awhile. And then someone joined, so it was 1v2. Me, a sniper, against two with assault rifles. And I was kicking ass (considering the sniper is one-shot, one-kill). And then another joined, and it was 2v2.

Overall I'm enjoying myself.

If you're interested... www.nexon.net

Recursion continued

2008-06-21T14:14:00.000-07:00

A friend of mine likes Palindromes, and was trying to figure out a way of seeing which sentences are Palindromes from a list of combinations of words. I don't exactly know how the combination maker works, but that part is recursive.

The part of his code that checks for a Palindrome is iterative, however. It checks the String from its beginning and its end, and makes comparisons based on those. If a letter pair doesn't match, it terminates. Otherwise it returns true.

It's pretty fast.

My recursive method, on the other hand, takes a String and splits it into two halves, and reverses the second half (so that ecar = race), and then does comparisons based on that.

It's pretty slow. But its also turning up an extra Palindrome or two every now and then. Which I think has to do with how its doing its calculations.

If I could somehow optimize my recursion to break if it knows its false i could probably speed it up greatly.

Which one's better? I don't know.

Also, for if tests, especially when calling a method in a return line, I think I found a pretty nifty way of indenting my code.

take


function foo (int num) {
     if (num == 0) {
          return 1;
     }
     else {
          return
               1
               + foo(num--);
     }
}

i think this is a lot better than


function bar(int num) {
     if (num == 0)
          return 1;
     else return 1 + bar(num--);
}

With the former, you can easily tell that it's returning a number and then calling itself. With the latter, you have to take in both as one step. This isn't so bad at first, but when you have something like


public String flip(String word) {
     if (word.length() ==1) {
          return 
               word.substring(word.length() - 1, word.length());
     }

     else {
          return 
               word.substring(word.length() - 1, word.length()) 
                    + flip(word.substring(0, word.length() - 1));
     }
}

Where the return statements get a little long winded, it can be quite nice to break them up into smaller pieces. Of course, all the indention can get a little long winded, but, indenting has always been a sign that you're going a little bit deeper into the logic of an operation (nested if tests, nested loops, etc)

Since recursion breaks down a problem into its subproblems, and then returns a combined result, I believe this way makes sense, too. When you break a problem into a smaller part, you're going further into the logic... When you're done, you're coming out.

Recursion is recursion is recursion is recursion is recursion . . .

2008-06-19T03:28:00.000-07:00

So, bought a book the other day, called "Introduction to Algorithms", which is a heavy, thick book that covers well, algorithms in computing, makes a case for them as a technology (it is not enough to have fast hardware, the instruction set must be efficient, as well), and goes on and on with tons of heavy calculus that I don't well, understand all that well. So far I've read up on insertion sort and merge sort, and, while I actually did make (read: copy) an insertion sort algorithm and make it work (correctly), I never did a merge sort.

See, the problem with recursion is that, its not very easy to see where its going. Yet, for some problems, recursion is the way to go. Take the game Portal and its view of looking through portals like in a mirror (It's really something better shown than explained... but the next time you see two mirrors directly opposite each other, its like that). They explain in the commentary that this is done recursively. And it makes sense. I couldn't see how it'd be doing using iterations.

Except... recursion is a type of loop. But a special type of loop. One that is actually very elegant and beautiful. It is also not all that verbose, compared to that of say a for loop or while loop.
// sorry about the lack of indents. Blogger doesn't like lots of spaces for some reason
Consider . . . (in Java syntax, at least. Well, I think this is correct. Merge sort isn't working but this is from the book)


merge (A, p, r) {
     if p < r) {
          q = (p + r) / 2;
          merge (A, p, q);
          merge (A, q + 1, r);
          merge (A, p, q, r);
    }
}

where the method merge (A, p, r) calls itself several times, breaks its problem down through both halves of the array and then reassembles the list in sorted order, which is what the last method does. At least, this is how I understand it.

Merge sort I do not actually have working. I have something, and by something I mean it sort of sorts an array and loses a huge chunk of data by the time its done. And why I don't know.

This is a lot more elegant than, say, the insertion sort with its for loop and while loop, although a bit harder to grasp. Merge sort, however, is quite efficient for large arrays.

Where was I going with this? Well, I just built a word-counter program that solves counting words line by line recursively. It reads in a line, takes out the first word, and calls itself with the new sentence. It's exit condition is satisfied when the line it is working with no longer contains a space.

It isn't perfect by any means. A long trail of spaces, or, say, a blank line will up the word count per space or per line. Putting in the wrong file name will terminate the program without any explanation as to why. That I need to fix. Maybe I could throw some other checks in there to make sure that the line doesn't contain nothing or doesn't count extra spaces. I mean, maybe that would be easy. But it means more steps, too.

But then computers are fast, anyway. No, I mean, seriously fast.

Top coder competition

2008-05-30T23:48:00.000-07:00

www.topcoder.com

Basically an outsourcing site where you can (supposedly) win money by competing to build software components on demand, or do algorithm contests for fun and some money.

I did a competition the other day, even though I knew they'd be hard. I mean, you know, worst case scenario is I had no idea how to solve it and I just go and move on to something else. But it turns out the problem wasn't all that hard (except for the third one), and they were all related to eachother.

So once I figure out problem 1 I just copy some code over for problem 2, make some changes, get in the top 7 after the coding phase is done and am feeling pretty good about myself. Well, the challenge phase comes along and my second program fails.

The reason? Time. TopCoder wants their programs to run, but run fast. Any algorithm that will take longer than 2 seconds will fail. I think the weakness here, for me at least, is my lack of math skill. I looked at source of some of the competitors and it seemed that the ones that did well were based in math.

Oh well. Lesson learned, plus, it was fun.

Words cannot describe the atrocites I've committed

2008-04-29T23:54:00.000-07:00

So, I'm working on making Mastermind as a way to learn more about programming with graphical user interfaces in mind. The core logic for checking this and that took maybe 2-3 hours of programming, tops, to build. Plus a day or two to think of how to solve a really tough part (Which, to my knowledge, works correctly now, but I suck at Mastermind so I can't tell 100%. but it seems to be correct).

While I developed the game from the console first with the concept of switching over to a graphical user interface later, I quickly found that I didn't structure my code well enough for the changeover and, well, what started as a project that should take a few days and be somewhat elegant (as I try to be... well, elegant isn't the right word... I just mean like... not using more lines than needed) into something that's bogged me down and forced me to give up a feature I had planned (Just as well... I can't manipulate AutoCad like I used to anyway).

Once frustration set in I stopped caring about code elegance and just started bulldozing whatever wasn't finished (It's a decision based on time spent on coming up with a good solution vs. time spent forcing the solution into place which a computer can still solve pretty fast... whichever saves me more time I pick) because I'm just getting frustrated with it all.

Oh, don't get me wrong. It's almost finished (I just need to refactor a few things). Well, single player anyway.

Then comes two-player support and computer play. Yeah, making an AI will be real fun.

I think after this I'll go make Battleship.

Opening really large text files

2008-01-20T22:10:00.000-08:00

So I have this problem. I have a 500MB text file filled with prime numbers.

I'm not entirely sure how it got to be so big or how it was even made without the JVM crashing in protest (I guess file access for programs other than the end-user don't use RAM) like it did when I tried holding stuff in arrays, bt suffice it to say I'm not going to be able to open this file with any basic program (I know because opening a 4MB program in notepad takes about 1-2 hrs). Yet my programming teacher keeps talking about how stuff like this is always handled as a string (Primitive data types are so limited in that they can go up to 64 bit at most), so I got to thinking and googled "opening really large text files", thinking that there was probably some top-secret technology that only the super computer gurus had.

Turns out that I'm not the only one with this problem, and the solution seems to be a little program called TextPad (www.textpad.com). Even the evaluation copy is powerful enough to open files larger than 500MB in a little over ten seconds. OpenOffice exited after it tried, and wordpad struggled (it opened part of it then froze... well not froze, it was still working but was unresponsive).

I'm not sure why it works so fast while others struggle or even just crash outright. I wish I knew, because I think it'd be nice to write a text editor one day (among a whole slew of other things, of course), and knowing that this is a problem that can crop up from time to time (usually when trying to read files from mySQL servers, apparently)

Calculating Big (really really really really really MONSTEROUSLY BIG) numbers

2007-12-26T21:55:00.001-08:00

The curious thing about programming and mathematics is that I'm not at all a good mathematician (C in Algebra 1, B in Geometry, D in Algebra 2), except when it comes to the computer, and the thing that has intrigued me most so far is the concept of computers being able to calculate extremely large numbers. Pi has been found to some odd billion digits, prime numbers (as far as we know) have been found using computers up to and beyond the 10 millionth digit (www.mersenne.org), and computers are used for other mathematical purposes as well (Seti, folding@Home, protein formations, etc).

The list is quite endless, I'm sure.

So as a novice programmer I also wanted to do something with higher math. Simply squaring numbers and all that is a little boring, yet the fibonacci sequence fascinated me, so I wrote a program to calculate that.

But it died after runs through the sequence. The 64 bits of data become clogged after about 19 digits, and fibonacci has been calculated to 10 million with some god-awful C++ code that was several lines long. So I asked the gods at www.javaranch.com, and they helped. The program no longer died after 91 runs through.

But then I realized that with an output to screen I couldn't retrieve the information, at all (what's the use of calculating a really really really big number if you can't get to it), which meant I had to solve another problem.

So I went searching, went on a journey, tried a bunch of things, looked at the hard-to-decipher-if-you-try-to-read-deep-in java docs, and then realized that the solution was right under my nose. The BigInteger class used to represent numbers larger than 64 bit (that is, 19 digits long or so) is an object. Every object has a toString method (returns it as a series of text). Text is savable to a file. My teacher went on about how these really big ass numbers are just strings of text..............

CLICK!

The only problem now is processing. The only solution for that is time.

Guess I'll be leaving something on overnight. Hey, fibonacci is already to the 100,000th digit :)

Welcome to Code Hell

2007-12-25T03:04:00.000-08:00

Why the hell did I do my combat system that way?

With the way it was before, I was using about three different methods to do things I could use with just if-then logic. I dunno why I was doing it that way other than the idea that I was maybe only thinking one step at a time.

Building a game is a precarious thing. It's already 1500 some-odd lines (a lot are printouts, and stuff like that, but there's also some stuff that goes into the guts of the program) and I really don't feel like I've done that much at all with it, yet.

It doesn't help that my first draft of the game was something that meant one little change required a lot of stuff. The applications we write in CS are just quick and dirty little things that teach a lot about one little aspect of the language, but not necessarily how it all meshes too well. I had to learn that the hard way when I started on the game. The way I had learned coding up to that point would make anything semi-big unmaintainable.

Don't get me wrong, I'm not knocking my computer science course. It's nothing too advanced because its a first-year program but its nothing to laugh about either because it is an AP course. I'm just saying that my limited experience, trying to work on a big project has actually been a good thing. I've gotten my head around classes and objects a little before the need to do so was required (something I'm glad happened before I got my Gridworld assignment, or i'd have been lost) and am looking at applying new concepts I learn to the game.

The irony of it is its a text-based RPG. Right now its just singleplayer but i might make it into a MUD if its any good. The ironic thing is I don't play MUDS, really. Because they're just so dang complex that its hard to understand, or i feel lost, not having a map, and stuff.

However I think its largely due to the fact that I never could quite immerse yself into them, not that MUDs were bad. But with my game I can make it how I want, and strip away the complex learning curve (all those bajillion commands) and hopefully add depth.

Maybe.

All else fails I'll just work on it to learn CS.

But I have so many ideas for the thing, where I want to take it... And it's just a baby right now. Maybe when it's matured a bit it'll be something awesome.

Winter Break

2007-12-20T22:55:00.000-08:00

WINTER BREAK IS HERE!!!!!!!!!!!!

Whew.

I'm exhausted.

And I have no idea why.

I mean I have an idea asto why, and I think it pertains to the fact that I've pretty much worked my ass off the past few months (gaming, school, work, we all know that gaming is actually hard work) but was kept in a perpetual state of work until now.

And the week has winded down, and its now catching up to me. It's the whole time dilation effect, you know. When you don't have time to think until its all over. And then it hits you. HITS you.

So, yeah.

I have nothing over winter break save a lot of programming to do. Which means it'll be an awesome two weeks, sans work.

Perfect Simulation

2007-12-13T00:31:00.000-08:00

Computer Science, at its core, takes a model of a real-world situation and simulates it, perfectly. If two programmers utilize this concept to a perfect degree their code will look the same, raising an eerie question of "how do you judge who's a better programmer?"

Of course, always holding onto such an ideal is difficult, if not impossible in practice, because it entails not only solving a problem to get from point A to point B, but solving it in such a way that the underlying logic FITS in with how the world works.

This raises quite a few interesting questions.

1. What is a real-world situation? Do we interact with the world using windows user interfaces on a daily basis? Are games "real-world" situations? They could be an extension of fiction, but, how do you quantify the underlying code?

2. How do you quantify a programmer's skills, if both of them code in the same manner? Time spent?

3. Does this concept include the idea of getting it right, the first time?

4. Does this include variable names? XP :)

Of course, before a developer could even begin to do this, he would have to have a solid command of the language, and, of course, as humans we are not perfect, so do to this on a regular basis would be impossible.

However, I think it does say that there is always improvement in some aspects of code, which, when studied long enough, will allow for programs to run better if the necessary changes are made.

These are just my thoughts of course. We haven't explored the concept too much.

AP practice tests for CS

2007-12-05T15:48:00.001-08:00

Had two tests this week. The one yesterday was a 40 question multiple choice in which we were required to answer 30. A majority of them dealt with classes, which is a JAVA concept I have been wrapping my head around the past few months (the concept finally clicked when some classmates showed me a few things). Actually the concept of classes was something I had in my mind before I knew how to go about programming in such a manner (You develop a very ambitious project and you begin to realize very quick that its not just a quick and dirty application).

The second portion of the practice test was a free-response question. The first involved the simulation of a parking garage, and I had to write code for three different parts.

The first part was to find out if the parking garage is full. This was simple enough. Check each level and if a level isn't full, then the garage isn't full.

The second part was to place a car in the next available space in the garage, and the third part was to remove a car. Since the value of "null" represented an empty space, it was just a matter of finding this empty spot and placing the car there. The third part was also quite similar, but a little different because it involved comparisons between two strings (sentences) and I'm not sure if I got it right. The problem is I'm not too keen on how objects work (something I need to practice on if I am to do good on the real thing).

Unfortunately, this took me around an hour to code. The one disadvantage with AP testing is that I don't have the compiler on hand to trace through code. I'm not talking about the debugger, but actually running the program and seeing where it goes as opposed to where I think it might go.

The second problem involved HTML processing. Since strings can't be deleted (for whatever reason), I got stuck on the whole "remove things from a string" idea. The ironic thing is I could have completed this easily if I would have realized that the second and third problems were really just variations of the first one.

Oh well. Chalk it up to learning lesson 2 about AP style testing :)

I can't wait until Christmas break. Two weeks of sheer, no-school bliss!