Monthly Archives: February 2012

CS371p Week 5

We have begun work on a new project: Allocator.  I am enjoying it, as I feel it’s brightened the black box of the heap a little bit, and it seems to be something of a respite after Voting and a test in the same week.  Voting took a lot of concentration for me to break down the problem,  but I feel like Allocator will be a little easier.  Chris and I got a late start because we were both out of town, but hopefully we will be OK.

Either my taste for books has gotten drier or the OOP book is just very readable.  Nothing in it has been very enlightening yet, but it has been a nice review.  I’m hoping to keep up with the readings, as it seems like a textbook worth finishing.  The only other textbook that I have felt more compelled to read than books of my own choosing is my OS book.  I definitely won’t be finishing that, though.

Interview season is winding down and  I’ll be happy if I never have to go through this song-and-dance again.  I feel like I can almost stop carrying around a small notebook and practicing binary search, tree printing, and Fibonacci sequencing.  It’s interesting–I’ve realized that there’s something to be said for those business school kids dressed in suits on their way to a class about how to communicate with other business professionals.  I’ve messed up at least one interview for which I was technically qualified for by sheer behavioral blundering.

Supercompute!

Several nights ago I had an idea for a game I’m going to write in Java .  I wrote down the main concepts and have been fleshing them out since then in a rules spec.  At the same time, I’ve started coding some of the necessary classes.

The source  code is available at: https://www.assembla.com/code/Supercompute/git/nodes/master/src

The current rules spec is sparse and inconsistent.  For example, “Action” is still mentioned several times, but it is no longer keyworded.  I was using it as a root class for Function objects until I realized that everything that extended “Action” also extended “Function”

Supercompute

Objective: Reduce your opponent’s fault tolerance to 0.

Fault Tolerance

A player starts with a fault tolerance of 100.  Certain events throughout the game have a higher probability of adversely affecting a player with a low fault-tolerance, so losing fault tolerance can cause a negative feedback loop.

//challenge will be to make the negative momentum for the less fault tolerant player surmountable

Functions

Players begin with three random concealed functions in their function bag, which are taken from their function library.  Players may use any number of functions per turn as long as they provide the proper parameters.  When a function has finished, it moves to the back of its owner’s degradation queue.  Once a turn, any parametric action of your choice can be queued for degradation(put in the back of the degradation unit) in exchange for instantiating a generic foundational unit of any type of specific basic resource that function takes as a parameter.

//use parameters such as CPU power, genome

Constructions: initializes some data instance that has an adhesion number

Instance Attributes

Adhesion: if an amalgam is disrupted for x, its top level extension loses x adhesion; if an extension has no adhesion, it falls off and moves to the back of the player’s degradation queue; at the end of the turn, an extension’s adhesion is refreshed.

Disruptive Capacity:   Disruptive capacity is a number representing how much an instance can disrupt a target during a routine disruption.  Unless stated otherwise, an instance can only use its disruptive capacity during one of the two routine disruption phases of its controller’s turn.  If an object is disrupted for x, its top-level extension loses x adhesion; if an extension has no remaining adhesion, it falls off whatever instance it was built upon.   By default, objects can be disrupted only at top-level.  Also by default, if an instance disrupts a target for x, and the target instance’s adhesion is less than x, the extraneous disruption has no effect.  However, if the disruptive instance has disruption cascade, the extraneous disruption disrupts the highest-level extension beneath the initial target of the disruption. If you have an instance with remaining disruptive capacity at the end of a Routine Disruption and there are no legal adhering targets, you may decrement a player’s fault tolerance by that much.

Nullness: A null instance will not have value extracted from it, cannot be disrupted by routine disruption unless it is the root instance(see “Disruptive Capacity” above) and cannot have any actions used; all abstractions on a higher level than it are also rendered null

Productivity: a productive instance is extracted by default during preparation.

 

Instances

Anything instantiated by a construction action is an instance.  Any abstraction and any semaphore is an instance. Any actions that are defined as instantiated are instances.  Null instances still count as instantiated.

Foundational Units

-genetic: extracts for g

-byte

//need generic semaphores for generic extensions

Semaphore: A resource counter.  For the sake of simplicity, there are currently only two types of semaphores, both basic: CPU power and genome.  Both are associated with the generic instances “evolute” and “byte”.  Semaphores don’t lose their resources at end of turn and can accumulate an unlimited amount unless otherwise specified.

//may have to limit the amount they can accumulate to encourage action

Before the game begins, players declare a concealed number and reveal it at the same time.  The player who reveals the higher number loses that much fault tolerance and takes the first turn.  If there is a tie, repeat this process.  If there is another tie after that, decide who goes first randomly.

Taking a turn:

//during each defined phase, all instances are checked for “phase actions”

Preparation

-add a random parametric action from your actions library to your action bag

Extraction

-extract value from all your productive instances; they yield x semaphoric value where x is the lowest-cost action on each of their top-level abstractions that .  Increment by a total of x any number of semaphores that provide resources that the extracted instance’s parameters could take.

//Unlike Magic, actions can take place during this phase

Evaluation

-active player can use construction

-use functions for whatever their parameters

-use actions of objects

Routine Disruption

-use functions for whatever their parameters unless they say that they can’t be used during routine disruption

-use actions of objects unless they say that they can’t be used during routine disruption

-objects can disrupt for their disruption capacity

-at the end of routine disruption, extensions with no adhesion and all of their higher level classifications are put in the degradation unit

 

Evaluation and Routine Disruption

-use functions for whatever their parameters unless they can’t be used during routine disruption

-use actions on objects

-objects can use disruption actions

-active player can use construction

-players can use actions of objects

-at the end of routine disruption, extensions with no adhesion and all of their higher level classifications are put in the degradation unit

 

Finalization

-environment modifications that say “ends upon turn finalization” end

-the front item in the degradation queue gets degraded

 

 

CS371p Week 4

It’s hard to write about Computer Science this week because I’ve spent every waking hour of the past six days immersed in it. My week was a grotesque ballet of time management.  Between classes, projects, interviews, and work, something(s) had to give.  Unfortunately, that something was my understanding of OOP material pertinent to the test.  The day of a certain crucial lecture, I had an interview scheduled for 9:30, so I arrived to class late, took the quiz at 11:00, and left to go bother a professor for a recommendation letter.  If only I would have just stayed for that one class…

Thursday evening, I went through almost all of the lectures, planning to wake up at 7:00 AM and do the rest.  Friday morning, as I made my cheat sheet at the last minute, I forgot to even look at what I had missed, much less throw some information about it on my cheat sheet.  Needless to say, when it came to a problem involving that very topic, I cringed.  My guess of  a solution involved some very incorrect syntax.  At this point, I think I have a solid understanding of what I previously misunderstood, but I am looking forward to reading blogs for clarification.

The most valuable thing I learned this week about getting a *career* in Computer Science is how much it helps to have personal projects.  Top companies really do want people that are passionate about programming and have tangible proof of it.  I know many people who say they enjoy programming, but only seem to do it for work or school.  That makes no sense to me.  I have had the most fun writing my own code.

I will be happy when interview season is over.  I think I’m also going to reduce my work hours.  School is paramount.

CS371p Week 3

As much as I would like to uphold my streak of blog posts citing extracurricular material, I am too swamped this week and my standards have flagged.  I’m just going to briefly rehash my notes in factoid bullets, then discuss my life in CS so I can get my beauty sleep.

  • “throwable” is a class; exception x must extend it if we want to say “int foo throws x”
  • you can’t compile with unchecked exceptions that could be thrown
  • e.what() gives you a c string(char *)
  • strcomp is like .equals() except it does lexicographical comparison; -1 if first arg is lexicographically less than, 0 if they are ==, 1 if first arg is greater than the second
  • domain error is a child of logic error
  • never catch by value or address; ALWAYS by reference
  • unchecked exception == runtime exception
  • If you override a method in Java and throw an exception, it must throw the same exception or a child of that exception
  • int a[100] goes on the stack
  • int* p = new int[5] goes on the heap
Variables.c++ is the most helpful slide we have covered so far.  I’m glad we are going through nitpicky examples while simultaneously getting to work with it in the Voting project.  Without the extra exposure, the Voting project would be much more fearsome.
This is going to be a tough week.  Projects due in OS and OOP, a test in OOP, and lots of other minutiae.  I’m very thankful for whatever is happening to prevent those textbooks from arriving, as there’s no way I would be doing anything but reading the chapter summaries and hoping to get lucky on the quizzes and tests.
I really hope my post is less lame next week.

CS371p Week 2

At the end of the week, my feeble understanding of L and R values was as follows:

  • if the operator doesn’t modify the argument, then the argument is an r-value
  • r-values are immutable
  • l-values are mutable
  • + takes two r-values and returns an r-value
  • Java ALWAYS returns r-values
  • += takes an r-value on the right and an l-value on the left; produces an r-value in C and Java, produces an l-value in C++
  • left hand side of an assignment NEEDS an L-value
  • ++i increments i, returns new value (so it is cheaper; it returns an L-value)
  • ++(x++) doesn’t make sense; you can’t perform ++ on an r-value
Feeling inadequate, I did some research and now feel more solid in my understanding.  I’ll begin with a weak analogy.  The l- and r- value modes seem to fall under the programming motif of protection, much like access modifiers, although with access modifiers the programmer is required to perform his own due diligence.  In my experience, access modifiers are as much about error prevention as they are about forcing the programmer to understand his program by finely tuning scope throughout the areas of the program.  L-values and r-values emphasize the former concept.  This was exemplified for me today when I got a C compiler error mentioning the necessity of an l-value.
The comparison is tenuous, but I’m trying to segue into the reasoning behind the creation of l- and r- values.  First defined in CPL, a not-too-distant ancestor of C, l-values and r-values were created “in order to help explain assignment, binding and other fundamental concepts”.  One could argue that access modifiers were created in order to explain the fundamental concept of encapsulation.Like access modifiers, value modes are a feature of constriction rather than liberation.  However, rather than the programmer enforcing himself, we have a case of the language enforcing the programmer.  What compels the CPL linguist to include such a feature in his language?  Consider the following quote from “The Fundamentals of a Programming Language“:

The simplest forms of assignments such as
x := 3
x := y + 1
x := x + 1
lend themselves to very simple explications. ‘Set x equal to 3’, ‘Set x to be the value of
y plus 1’ or ‘Add one to x’. But this simplicity is deceptive; the examples are themselves
special cases of a more general form and the first explications which come to mind will not
generalise satisfactorily. This situation crops up over and over again in the exploration of a
new field; it is important to resist the temptation to start with a confusingly simple example.

While studying language semantics, the creators of CPL undoubtedly had this in mind.  “Fundamentals” continues with the following cryptic example:

i := a > b j,k
A[i] := A[a > b j,k]
A[a > b j, k] := A[i]
a > b j, k := i .

We are tempted to write them all in the general form
“1 := “2
where “1 and “2 stand for expressions, and to try as an explication something like ‘evaluate
the two expressions and then do the assignment’. But this clearly will not do, as the meaning
of an expression (and a name or identifier is only a simple case of an expression) on the left
of an assignment is clearly different from its meaning on the right.

Therein lies the crux.  Hopefully this roundabout explanation has made sense.