Version control, gitbucket and SourceTree style

Last time I wrote about version control using Subversion (and its implementation in Eclipse). I still haven’t given up on it, but since I’m using a private repository, sharing code has been a bit tedious.

I was introduced to git a while ago, but somehow decided to go for Subversion. A few days ago a friend of mine pointed out SourceTree, a git GUI client for Windows and Mac. It’s not all GUI, all you die-hard CLI users are able to use their favorite tool. It hooks well with BitBucket, Stash, GitHub and Kiln. I opted for BitBucket, because it offers free private repositories.

The interface is, to my mind, very intuitive. You have a bookmark sidebar with your favorite projects, main window where most of the magic happens and of course the toolbar, where you can commit, checkout, remove, pull, push, branch, merge (and more) projects. For understanding git, Git Reference site can be helpful.

Once you create a new (local or remote) repository, the program will scan for any possible changes. Once a change has been detected, you will be able to commit them. In git lingo, this means that you will acknowledge these changes and apply them. SourceTree will keep a nice history tab for you, and you can revert to previous versions by simply “checking it out”. Once you’re happy with all the changes and you think your repo should see the light of day, you can Push it to your favorite git site, like BitBucket or GitHub. If you’re collaborating with others, you can always Fetch/Pull changes from the main site and have you repo up to date.

If you’re looking for version control, and you see yourself as a prospective (or current) collaborator, do give git and SourceTree a try.

SC in action

SourceTree in action. Left is the bookmark sidebar and the main window is showing the history of my master branch. Click on image to enlarge (the image).

Categories: Uncategorized

How to branch/fork a (StatET) project with SVN

August 14, 2012 1 comment

I was introduced to version control at the 2011 Belgrade R+OSGeo in higher education summer school. I’ve been using it in my daily work ever since.

Recently the need to branch my project came up and this post describes how after a few hours of reading teh internets satisfied my need. In a nutshell, you should prepare your SVN repository to accept branches, branch your local project, dance. Yes, it’s as simple as that.

First, you need to prepare your repository to be able to accept branches. You do that by creating a “branches” directory. Probably the correct location is root of your SVN repository. At least that’s how it works for me.

You now swith to StatET view and “branch” your project. Right-click your project, Team > Branch. Name your branch and check “Start working in the branch”.

If you refresh your SVN repository, you should now see your branched project.

And if you checked the “Start working in this branch” your (local) project should automatically be looking at this branch.

You’re ready to work on your branched/forked project. After you’re done, you can merge this branch with your original project. This aids in casual experimentation without long term consequences. Keep off of drugs, use protection, stay in school!

Categories: Uncategorized Tags: , , , , , ,

Show me yours and I’ll show you mine

August 9, 2012 9 comments

I remember when I started with R, there was little processing power directed toward an IDE. I had enough problems with the syntax, loops and the like and R gui seemed adequate. When I started working on a heavy project, I had to knock it up a notch (bam!). After weeks of trial and error with various IDEs I settled for Eclipse. Year was 2010.
After two years, I feel very comfortable in my IDE of choice but I’ve always felt there’s some things I might be missing. That’s why I’m starting “show me yours and I’ll show you mine” project where I wish to collect workflow setup for working for programming and/or data analysis. The idea is to present your setup and comment on why you think it’s (in)efficient for you. I’ll start!

As mentioned, I use Eclipse with a plugin StatET. Eclipse (and StatET) depend on Java, so you’ll probably have to install either JDK or SDK. This may be a limiting factor for some. Eclipse offers a number of handy keyboard shortcuts (for instance CTRL+r+3 sends line/chunk to R, CTRL+r+s sources the entire file…), manages windows, provides different views and more.

My setup has two code editing windows in the upper left corner, project explorer and task list (kudos to Andrie) on the right. Bottom half holds the R console and R help/tasks. I can easily navigate through files while debugging programs and handy keyboard shortcuts really cut down production time. I like having all windows handy. This is aided by Mylyn Task List plugin that helps you store and switch between individual sets of scripts. More about Mylyn can be found here. I also have a button to run knitr script which produces a pdf report (see previous post). I connect to a SVN server where I store my work. Switching to a SVN look is achieved by clicking the “SVN” icon in the top right corner.

I would encourage anyone interested in sharing their ideas about how to set up their workflow on this blog to send me a screenshot and a short description to my gmail account (romunov) or post about it on their own internet outlet (blog, personal website…) and send a traceback back here.

Read more…

Categories: R Tags: , , , , ,

Getting knitr to work with StatET

April 13, 2012 2 comments

StatET (an Eclipse plug-in that can handle, among other things, R) offers support for writing Sweave (.Rnw) documents. This is done via the external tool dialog, where one creates a new “device” that takes in a document and runs it over appropriate functions and programs. In this case, Sweave and LaTeX. This dialog can, however, be modified to use function knit from package knitr. With a little luck, you can will be able to produce handsome looking pdfs with one click.

As I’ve already said, you will need to create your “knitr device”. You can reach the appropriate menu to external tools via Run > External tools > External tools configuration and create new “Sweave document processing” launch configuration. I have used the following options. Make sure you have package knitr installed.


Assuming you have everything configured correctly, you can run the file through knitr with a single click*. You can do that by clicking the icon with three red arrows pointing at 010.



* Side note: You will probably need to put the documents you want to weave inside your workspace directory.

Categories: R

Write data (frame) to Excel file using R package xlsx

February 12, 2012 25 comments

Writing to Excel files comes up rather often, especially if you’re collaborating with non-OSS users. There are several options, but I like the xlsx package way of doing things. Authors use Java to write to Excel files, which are basically compressed XML files.

Alright, let’s get cracking.

First, let’s create some data.


If you don’t have the file created yet, you can just write the data into a new file.

library(xlsx) #load the package
write.xlsx(x = sample.dataframe, file = "test.excelfile.xlsx",
        sheetName = "TestSheet", row.names = FALSE)

If you already have a file created, you can add data to a new sheet, or just add it to the existing one. Here’s how you would add a data.frame to columns D and E (result not shown).

workbook.sheets workbook.test addDataFrame(x = sample.dataframe, sheet = workbook.test,
   row.names = FALSE, startColumn = 4) # write data to sheet starting on line 1, column 4
saveWorkbook(workbook.sheets, "test.excelfile.xlsx") # and of course you need to save it.

You can now open the file in your WYSIWYG editor.

Categories: R Tags: , , , ,

Adding lines or points to an existing barplot

January 15, 2011 5 comments

Sometimes you will need  to add some points to an existing barplot. You might try

par(mfrow = c(1,2))
df <- data.frame(stolpec1 = 10 * runif(10), stolpec2 = 30 * runif(10))
lines(df$stolpec2/10) #implicitno x = 1:10

but you will get a funky looking line/points. It’s a bit squeezed. This happens because bars are not drawn at intervals 1:10, but rather on something else. This “else” can be seen if you save your barplot object. You will notice that it’s a matrix object with one column – these are values that are assumed on x axis. Now you need to feed this to your lines/points function as a value to x argument and you’re all set. <- barplot(df$stolpec1)
lines(x =, y = df$stolpec2/10)
points(x =, y = df$stolpec2/10)

Another way of plotting this is using plotrix package. The controls are a bit different and it takes some time getting used to it.


barp(df$stolpec1, col = "grey70")


Categories: R Tags: , , , , , ,

Modeling sound pressure level of a rifle shot

November 1, 2010 3 comments

Noise can be classified as pollution and lawmakers often (always?) treat it as such. Noise can have different origin points, point source being among the simplest to model. Because noise has broader health implications, being able to understand its propagation, a simple model can further our understanding in toning down or preventing excessive noise burden on the environment and its inhabitants. In this work, I will focus on firing range noise and the propagation of sound to the surrounding area.
Small scale firing ranges can be considered as point origin of noise. To make a simple predictive model, a number of assumptions and generalization are made. The reader should realize that this makes the model a bit less realistic.

When talking to experienced people, they will tell you that the distance between a firing range and the first house should be roughly 200 m. While there is no explicit mention of this number in Slovenian laws (yes, I’ve checked), there is a threshold of sound pressure level (SPL) of 75 dB. So, knowing the SPL of the rifle and we know the legal threshold, we can use a simple model to estimate approximate distance at which the SPL will fall to or below the aforementioned legal threshold.

A rifle shot produces a sound pressure level of about 170 dB, which is roughly the sound of a jet engine at a 30 m distance (see here).

Noise propagates and dissipates through the air with roughly (source)

p ~ 1/r

which gives us

L_2 = L_1 - 20 × log(r_2/r_1)


L_2 = sound level at  measured distance
L_1 = sound level at reference distance
r_1 = reference distance from source of the sound
r_2 = measured distance from the source

Using this model, we have accepted all sorts of assumptions, like calm weather, even terrain, even air pressure, no air resistance… Come to think of it, this model would be best suited for a desert in lovely weather. Nonetheless, it gives us a starting point.

I would be interested to hear from more knowledgeable readers on any potential mistakes and how to improve the model with regards to at least above assumptions.

Modeling this equation in R is trivial. Let’s write a function that will calculate L_2 for a sequence of r_2 values.

soundPressure <- function(r2, r1, L1) {
 L2 <- L1 - 20 * log(r1/r2)
 dL <- L1 - abs(L1 - L2) # this will give us the appropriate delta that we can use to plot our graph

# let's define some parameters
distance <- seq(1, 1000, 1) # a vector of distances to be used as r_2
L1 <- 170
r1 <- 1

# this is the threshold level defined by the lawmaker
# we're actually interested in finding at what distance, the noise
# dissipates to this level
dB.level <- 75

# apply the above formula to every value in "distance"
dB <- sapply(distance, soundPressure, r1 = r1, L1 = L1)

# plotting
find.x <- which(round(dB) == dB.level)[1] # find which value is ~75 dB

plot(x = distance, y = dB, ylim = c(1, L1), xlab = "Distance (m)",
 ylab = "Sound pressure level (dB)", type = "l")
abline(h = dB.level, col = "red")
abline(v = find.x, col = "red")
# distance label
text(x = distance[find.x], y = 0, offset = 0.5, col = "black",
 pos = 4, labels = paste(distance[find.x], "m"), cex = 1.3)
text(x = 0, y = dB.level, col = "black", labels = paste(dB.level, "dB"),
 cex = 1.3, offset = 1, pos = 1)

Result of the plotting is

This tells us that the sound pressure level at roughly 113 m away from the rifle will be 75 dB (the legal threshold). Based on these results, a 200 m buffer around a firing range gives an estimate with a margin of around 100 m buffer.

As already mentioned, I would be happy to hear your comments on errors and how to improve the above model.