Graphs from tables
Debugging in R
Anyone who starts writing serious R code (i.e., code that involves user-written functions) soon finds the need to use debugging tools. There are a few basic tools in R that are worth knowing about.
The function debug() allows one to step through the execution of a function, line by line. At any point, you can print out values of variables or produce a graph of the results within the function. While debugging, you can simply type “c” to continue to the end of the current section of code (e.g., to the end of a for loop, or the end of the function itself).
The function browser() stops the execution of a function until the user allows it to continue. This is useful if you don’t want to step through all the code, line-by-line, but you want it to stop at a certain point so you can check out what is going on.
If your code has already crashed and you want to know where the offending line is, try traceback(). This will (sometimes) show where abouts in the code the problem occurred.
Check out the help files for the above functions for the details.
Duncan Murdoch also has an excellent debugging page on the web: Debugging in R which contains a wealth of extremely helpful information.
Debugging in R
Anyone who starts writing serious R code (i.e., code that involves user-written functions) soon finds the need to use debugging tools. There are a few basic tools in R that are worth knowing about.
The function debug() allows one to step through the execution of a function, line by line. At any point, you can print out values of variables or produce a graph of the results within the function. While debugging, you can simply type “c” to continue to the end of the current section of code (e.g., to the end of a for loop, or the end of the function itself).
The function browser() stops the execution of a function until the user allows it to continue. This is useful if you don’t want to step through all the code, line-by-line, but you want it to stop at a certain point so you can check out what is going on.
If your code has already crashed and you want to know where the offending line is, try traceback(). This will (sometimes) show where abouts in the code the problem occurred.
Check out the help files for the above functions for the details.
Duncan Murdoch also has an excellent debugging page on the web: Debugging in R which contains a wealth of extremely helpful information.
Geometric shapes
The data includes cubes, spheres, simplexes, polyhedra, polytopes, and mobius-like objects, ranging from from 3d
to 10d. For each object Barret has made a data set, image, short movie and the R code necessary to recreate the data.
http://streaming.stat.iastate.edu/~dicook/geometric-data/
Execute system commands within an R Script
write.csv(mydat, "mydat.csv")
system("gzip mydat.csv", wait=FALSE)
119 days of number crunching…
Just checked on the 70000+ simulations I submitted to the Cow last night. The purpose of these runs is to explore a given system (the logistic growth model in this case) using different implementations of the stochastic simulation algorithm (aka SSA methods). In this batch of runs I am utilizing Gillespie’s Direct method, which is the exact implementation, and three tau-leap methods (Explicit tau-leap, Binomial tau-leap, and Optimized tau-leap), all which are approximate implementations of the SSA.
Here’s the status so far. All of the tau-leap methods have finished. The Explicit tau-leap method took 75 minutes to crunch through 10000 simulations, the Binomial tau-leap took 17 minutes, and the Optimized tau-leap took 121 minutes. Although there are substantial timing differences between the methods it all appears rather minute compared to the timings of the Direct method which still is working on it’s 10k runs (about 12 hours after starting). A simple extrapolation reveals an estimated wall time to completion of 119 days!!! I am (was) intending to have this manuscript submitted well before that. On the bright side though – at least the results will be exact!
Cow chewing on GillespieSSA
Sorry blog for the long silence. Lately I have been juggling several time critical projects and there hardly seems to be time for such mundane activities such as sleeping, eating, never mind shaving (someone pointed out that I am starting to resemble a real Canadian, which of course is rather fitting since I recently became one).
After a brief breather and regrouping following the initial release of my R package, GillespieSSA, it was time to hit the supersonic lane again. The initial incentive for making this package was to simplify and streamline the process of setting up stochastic simulation models of continuous time rate equations (coupled ODE models) and to enable me to rapidly prototype and run large scale stochastic simulations. Ultimatelly the goal is, of course, to speed up the process of going from an idea, to results, and a paper product. So now that the package is “finished” I have “enrolled” it in several projects. For example, I just submitted 70000 runs to our in-house cluster, the Cow (remember this is Davis, the home of the fistulated cow). That should keep her busy chewing for a while. These runs are part of a paper I am writing on using stochastic simulation algorithms and GillespieSSA for ecological, epidemiological and evolutionary models.
Of course throwing various novel models at the package has also unraveled a few bugs along the way – so all those of you that are just itching to take the package for a spin might want to consider holding your horses (or cows) a tad longer. The next version, GillespieSSA 0.1-1, will be posted by the end of this month and will, in addition to a bunch of bug fixes, have a ton of new features, e.g. improved plotting utilities, management of large data sets (how large still remains to be seen), better handling of systems with a very large number of states and/or reaction channels, more model templates (just finished a very cool daisy chain SIRS model giving you a diagonal state-transition matrix [more on this in a later post, in the meantime please do not overwhelm me with request 
]), etc…. Somewhere along the way I am also supposed to write a manuscript, attempt to resuscitate (or cremate) one that got rejected, review two papers, prepare a lab meeting, analyze the results from another project and send it back to my collaborator, and revise the manual for the package. Oh, someone hinted to me that I should also consider providing a package for Windows (?). When did I say all of this would be done…? Right – I should get back to work, like, right now, it’s not past midnight just yet… Gad I love the academic life (no irony intended).
GGobi 2.1.6
Just a quick note to let you know that GGobi 2.1.6 has been released
and is available from Windows, Mac (with easy installer) and Linux
from http://www.ggobi.org/downloads. The changes are largely internal
with a few more bugs being fixed.
We are working on getting rggobi on to CRAN now, and we hope that it
will be available for all platforms within the next week. If you are
using rggobi, you might want to hold off on upgrading GGobi until
then.
Again, GGobi 2.1.6 is available from http://www.ggobi.org/downloads
GillespieSSA 0.1-0 is released
I just submitted the first release of the GillespieSSA package to CRAN. After much debating I finally decided to adhere to the unwritten R version numbering policy of starting really really low (and asymptotically approaching 1.0-0) . Thus, the first release is versioned as GillespieSSA 0.1-0. At this point the package is only available as a tar ball but I will be working on making a zip package.
The package is about 10 days late! Ever since I got back from the useR! meeting I have been single handedly dedicating my time writing the reference manual for the package (the so called Rd files). I have to admit that I seriously underestimated the amount of work this takes. Of course it does not have to take this long but if anyone is supposed to be able to use the package then proper documentation is critical. Academically speaking this may of course appear as a bit of a waste of time. I figure, however, that producing a piece of software as technical as an R package should count for something (it’s not the typical achievement the average Joe blow pulls off). After all most of the R Development Core Team and many package authors are academic researchers and I am sure they put their extRacuRRiculaR activities in their CV. Any enlightened person realizes, of course, that the world is a better place thanks to all the these seriously committed people. Another reason I am spend all this time on writing the documentation is because I will use parts of it as the framework for (at least one) publication to be submitted to a peer-reviewed journal.
Ok, it’s way to late for any sane person to stay up. Gotta go, it’s time to snooze.
Offset in glm ()
E-mail updates
