As an impatient person, I typically use progress bars for any code that takes more than a few minutes to run. In a previous post, I wrote about creating ASCII progress bars in R and Racket. The Racket version depended on the raart module, which "provides an algebraic model of ASCII that can be used for art, user interfaces, and diagrams." Because I'm not aware of any such library for Chez Scheme [1], I was left feeling stuck.

One of the advantages of open source software is being able to view, review, and learn from source code. Both R and Chez Scheme provide tools for accessing source code.

I have previously written about how to read and write JSON files in R and Racket. In re-reading that old post, I'm struck by how it shows me tinkering without understanding. Now that I have pivoted from learning Racket to learning Chez Scheme, I'm revisiting JSON as a data serialization format and actually reading about JSON instead of just playing with JSON packages.

I was reading a blog post that mentioned that Julia has "[w]eak conventions about namespace pollution" and it got me thinking about how I manage namespace pollution in R and Chez Scheme. The short answer is that I don't. I developed bad habits in R centered around writing overly terse code.

In the process of learning Chez Scheme, I've missed R's ability to quickly pull up documentation from the console via help or ?. I've toyed with the idea of trying to format the contents of the Chez Scheme User's Guide for display in the REPL (similar to Clojure Docs). But that is probably too big of a task for me at this point. It recently occurred to me, though, that I can write a simple library, chez-docs, with only one procedure, doc, that will make it a bit easier to access the Chez Scheme User's Guide.

In a previous post, I used GUI toolkits to make progress bars in R and Racket. However, I usually prefer the ASCII progress bars of the progress package in R. The progress package includes several options for formatting the progress bar. I particularly like the option to display the estimated time remaining. However, for this post, we will stick to the basic progress bar.

As an impatient person and an insecure programmer, I typically use progress bars for any code that takes more than a few minutes to run. In R, a progress bar widget is available through the tcltk package.

In learning about reading CSV files in Racket, I have started to reconsider whether storing small(ish) datasets in CSV files is the best default behavior [1]. My default was set by primarily working in R, where reading and writing CSV files plays a central role in data analysis. When working solely in R, I expect that my old habits will die hard and CSV files will continue to play a prominent role. However, when passing small(ish) data between R and Racket, I think JSON might be a better alternative [2].

In a previous post, I wrote about reading and writing data to file while retaining the structure and attributes of the data (i.e., data serialization). However, I more commonly pass data around as text files (usually, CSV files). For this post, I created an example CSV file with a tool for generating test data, which allows for including different data types (e.g., dates, integers, names, phone numbers) in the output file.

One of the areas of expertise at Cramer Fish Sciences is watershed and habitat restoration. In the context of that work, we are often faced with estimating how much rearing habitat is needed to support a specified number of juvenile salmonids (or how many juvenile salmonids are supported by a specified amount of rearing habitat). Our typical approach for generating these estimates is to use the territory size-fork length relationship from Grant and Kramer (1990). To simplify that calculation, we often assume that all the fish are the same size.

In a previous post, I wrote a function to perform repeated timings of untyped and typed versions of the same Racket functions.

In a previous post, I wrote that Racket's if is similar to ifelse in R. That's not quite right. This is a short post to clarify the comparison. The more accurate description is that this Racket code

On my journey to learn Racket, I look for small pieces of R code to try to implement in Racket. A blog post about speeding up population simulations in R with the Rcpp package seemed like a good candidate for implementing in Racket. I was particularly interested in the (superficial?) parallels between R/Rcpp and Racket/Typed Racket.

R makes it easy to generate random numbers from a wide variety of distributions with a consistent interface. For example, runif, rnorm, and rpois generate random numbers from uniform, normal, and Poisson distributions, respectively.

When programming in R, I generally pass data around by reading and writing text files (typically, CSV files). The ubiquity of CSV files means that many different types of software will open them easily (e.g., Notepad, Excel, TextEdit, etc.). However, if the data structure is not flat or contains other attributes, then writing to CSV requires flattening and/or dropping attributes. The general solution to writing data to a file while retaining structure and attributes is serialization.

The Delta Simulation Model II (DSM2) is a hydrodynamic model used for Sacramento-San Joaquin Delta planning and management. When working with DSM2 output, I frequently need to look up the location of channels, nodes, and stations in the model. A map of all of the channels, nodes, and stations (and more) is provided with DSM2 as a PDF file, but that file is not easy to search.

When building a simulation model in R, I might want to group related input parameters into a data structure. For example, in a life cycle model with resident and anadromous fish, you might use different fecundity parameters for each life history type. One option is to create different objects for each fecundity parameter.

I have recently started learning Racket. For a first task, I tried to build a simple age-structured population model. I hit a stumbling block and reached out to the helpful folks on the Racket mailing list. In this post, I recap the mailing list exchange with a target audience of R programmers that are interested in learning more about Racket.

Shiny Scorekeeper is a basketball scorekeeper app built with the Shiny web framework for R. I needed a new app for scoring video of my son's basketball games and I decided it would be a good learning experience to try to build my own. In this post, I describe using DataTables from the DT package as the interface to the CRUD (create-read-update-delete) features in Shiny Scorekeeper. The post assumes familiarity with features of Shiny apps, particularly reactiveValues(), observe(), and observeEvent().

In developing the DSM2 HYDRO Viz Tool, we were faced with deciding how to deploy a Shiny app that required interaction with large local files. I first heard about the possibility of using Electron to deploy Shiny apps as standalone desktop applications in this talk by Katie Sasso, but it wasn't until I discovered the R Shiny Electron (RSE) template that I decided to take the plunge.