So I live in Cambridge about two blocks from Inman Square. My apartment is about 10 minutes walk from both Harvard and MIT. As a self-confirmed geek I’m kind of excited about that – even though I don’t have a snowballs chance in hell getting in either of those places. Here’s Inman Square. I live right on Cambridge St.

It’s 2:50 AM and I’ll be out all day tomorrow so I’ll post later.

Anyways, running so many trials, the results are pretty promising.

Right now I am also considering coding up an automated system which creates 100 datasets, runs the R algorithms to produce 100 solutions, and use the Scheduler to test the 100 solutions and measure their rankings. This would beat manually doing the steps and waiting for the results. Coding this up might is probably going to be pretty hard work, but it would be easy to test various cost-formulation metrics we keep coming up with.

We probably have to create, within the next few days, the data.frame for collecting data, and the memory level v/s time graph too. This should be pretty cool. We think it should be fairly easy too. Let’s see.

It took me a little bit more time to figure out that adding a constant to a TSP cost matrix doesn’t affect the results. The tour-length obviously varies, but each TSP algorithm produces the same permutation over and over again. This result is surprising for by adding a flat constant we are we modifying the ratio of the costs between cities. However, it doesn’t seem to matter.

Research, in test-suite prioritization, is about finding the “best” permutation of the test suite to run. Running the n! permutations of the test suite, to find the best permutation, defeats the whole purpose of saving time. Rather, given all information about a test-suite, researchers should be able to give the software-testers one permutation of the test-suite. The ideal solution which gives the software-tester maximum benefit for his time. This isn’t as easy as it sounds. For even with all information about a test-suite simulating n! possibilities is prohibitively expensive. Prioritizing a Test Suite with 100 test-cases, in this manner, would make us look at 9.33262154 x 10^157 or 9 googol and 3.32 octodecillion possible permutations which is impossible. And real-world Test Suites usually have 1000 or more test-cases!

Research Scientists have developed various metrics and techniques to solve this problem. The metrics are what the researchers think is a reasonable quantity to optimize. This can be average no of faults detected per sec, requirements covered per sec, or any other sophisticated metric. The techniques are strategies to find permutations that optimize the relevant metric. The metrics and strategies research scientists employ belong in a more detailed post, and hopefully I can do that. But I hope you have gleaned from my post what test-suite prioritization is essentially about.

Writing the scheduler and seeing it work visually has given me a few ideas on how to formulate a cost metric. By seeing how Loads and Unloads are executed in real-time has given my back-calculating mind some more leads. Here are some observations:
1. The Memory Constraint is reached fairly quickly in these synthetic test cases.
2. Unloads are almost inevitable for every Test Case after the Memory Constraint is reached.
3. The methods unloaded usually didn’t belong the last Test Case

This has us thinking if there is a meaningful way to calculate a “cost” between 2 test cases? I shall be working on that issue in the next few days.

I also want to write a background article for my research so it should be more approachable. Soon…

> sink(“record.lis”)
>rm(x, y, z, ink, junk, temp, foo, bar)
> x <- c(10.4, 5.6, 3.1, 6.4, 21.7)
>c(10.4, 5.6, 3.1, 6.4, 21.7) -> x

> y <- c(x,0,x) # Note y has 11 elements
> v <- 2*x + y + 1
generates a new vector v of length 11 constructed by adding together, element by element, 2*x
repeated 2.2 times, y repeated just once, and 1 repeated 11 times.

max(x) and min(x) select the largest and smallest elements of a vector respectively.
range(x) gives a vector of length two, namely c(min(x),max(x)).
length(x) is the number of elements in x,
sum(x) gives the total of the elements in x,
and prod(x) their product.
mean(x) which calculates the sample mean, which is just sum(x)/length(x)
and var(x) which gives sum((x-mean(x))^2)/(length(x)-1)
sort(x) returns a vector of the same size as x with the elements arranged in increasing order;
pmax(x,y,z) and pmin return a vector (of length equal to their longest argument) that contains in each element the largest (smallest) element in that position in any of the input vectors.

> seq(-5, 5, by=.2) -> s3 generates in s3 the vector c(-5.0, -4.8, -4.6, …, 4.6, 4.8, 5.0).
> s4 <- seq(length=51, from=-5, by=.2) generates the same vector in s4.

> s5 <- rep(x, times=5) which will put five copies of x end-to-end in s5.
> s6 <- rep(x, each=5)

Logical vectors are generated by conditions. For example
> temp <- x > 13
sets temp as a vector of the same length as x with values FALSE corresponding to elements of x
where the condition is not met and TRUE where it is.

> z <- c(1:3,NA); ind <- is.na(z)
In summary, is.na(xx) is TRUE both for NA and NaN values. To differentiate these,
is.nan(xx) is only TRUE for NaNs.

CHARACTER VECTORS and the PASTE function
> labs <- paste(c(“X”,”Y”), 1:10, sep=”")
makes labs into the character vector
c(“X1″, “Y2″, “X3″, “Y4″, “X5″, “Y6″, “X7″, “Y8″, “X9″, “Y10″)
Note particularly that recycling of short lists takes place here too; thus c(“X”, “Y”) is
repeated 5 times to match the sequence 1:10.

(INDEX VECTORS) p 16

Vectors must have their values all of the same mode. Thus any given vector must be unambiguously
either logical, numeric, complex, character or raw.

Reading Data from Files

> HousePrice <- read.table(“houses.data”, header=TRUE)
where the header=TRUE option specifies that the first line is a line of headings,

Editing Data
> xnew <- edit(xold)
fix(xold), which is equivalent to xold <- edit(xold)
> xnew <- edit(data.frame()) to enter new data via the spreadsheet interface.

I hope I can also blog about other miscellaneous items as I haven’t really blogged before. And btw the blog is named after the now infamous game of CalvinBall. Rules can be found here.