Recently, I switched from learning Racket to Chez Scheme. I wanted to try to repeat some of my previous Racket exercises in Chez Scheme, but quickly ran into a barrier when my first choice required drawing random variates from a normal distribution. I looked for existing Chez Scheme libraries but came up empty. I considered SRFI 27: Sources of Random Bits, which includes example code for generating random numbers from a normal distribution, and reached out for guidance. Ultimately, I decided that it would be a good exercise to write a library for generating random variates from different distributions. As I started to write the random variate procedures, I realized that I minimally needed procedures for calculating mean and variance to test the output of the random variate procedures. And, thus, the scope of the library started to expand and the chez-stats library was born.

I recently decided to switch my attention from learning Racket to Chez Scheme. One of the reasons that I chose Racket was because of how easy it is to get up and running. Setting up a development environment for Chez requires jumping through a few more hoops. In this post, I document those hoops. Disclaimer: The suggestions in this post may not represent best practice. I will update the post as I become more experienced with Chez and Emacs.

Over the last 6 months, I have been learning Racket in my free time. One of my first posts on this blog laid out my reasons for choosing Racket. The relatively low barrier to entry (e.g., easy installation of Racket and packages, DrRacket IDE, good docs, etc.) allowed me to build momentum with Racket and I was feeling satisfied with my choice of Racket as an alternative to Python.

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.

Racket's if is not vectorized like ifelse in R. Instead, this Racket code