To get into the holiday spirit and in anticipation of the long-awaited launch of the James Webb Space Telescope (JWST),1 I decided to bake some gingerbread cookies in the shape of JWST’s primary mirror, which is comprised of 18 gold-plated hexagonal segments. The cookies are 10 cm across, with hexagonal segments are 20 mm flat to flat, making them 1:66 scale replicas of the mirror.
The launch is scheduled for Christmas Day, as of writing. ↩
Several weeks ago, my paper on a novel square equal-area map projection was published in ACM Transactions on Spatial Algorithms and Systems, titled A Square Equal-Area Map Projection with Low Angular Distortion, Minimal Cusps, and Closed-Form Solutions. For mathematical details, the reader is directed to the paper, but I’ll discuss what motivated its development and outline the projection’s benefits here. The projection uses a quincuncial arrangement, which places the north pole at the center and splits the south pole between the four corners of the square, forming a quincunx pattern that resembles the “five” marking on a standard six-sided die. This arrangement has been previously used by the Peirce quincuncial projection, the Collignon quincuncial projection, and the Gringorten projection.1
Last month, I climbed Cerro Zapaleri, the 5648 m tall summit of which forms the tripoint of the borders of Chile, Argentina, and Bolivia.1 Its location is quite remote, ~105 km from San Pedro de Atacama, Chile and >40 km from the nearest paved road, both as the crow flies. After researching previous accounts of ascents and poring over high-resolution satellite imagery to map out routes to get to the mountain and to climb it, it was time to depart. As expected, a high-clearance four-wheel drive vehicle would prove to be necessary.
This was at the end of a nine-week trip to Chile for telescope repair and maintenance work. Traveling during the COVID-19 pandemic, even with an N95 mask and PCR tests, was a nightmare, particularly for the flights in the United States, and I would not have done so if the repair work wasn’t necessary. ↩
As a follow-up to my previous entries for the Ashley Book of Knots and Space-Filling Curves, I decided to enter a submission into this year’s Johns Hopkins University Sheridan Libraries’ (virtual) Edible Book Festival contest for Mandelbrot’s The Fractal Geometry of Nature. This raises the questions of which fractal to use and how to make it edible. To this end, I decided to bake a Sierpiński carpet Linzer cookie. The zeroth iteration of the fractal, a square, forms the first layer of the cookie, while the first three iterations of the fractal form three additional layers, for four cookie layers in total.
Recently, I came across a blog post about converting parts of a JavaScript library into WebAssembly. The part that interested me the most was a section about efficiently embedding the WebAssembly binary into the JavaScript code such that the library could be distributed as a single file, instead of the usual method of providing the WebAssembly binary as a separate file. This is accomplished by Base64-encoding the WebAssembly binary as a string and including the resulting string in the JavaScript file. Unfortunately, this significantly inflates the total file size, since the Base64-encoded string does not compress nearly as well as the original binary. To mitigate this issue, the blog post author had the clever idea of gzip-compressing the binary prior to Base64-encoding it and using the zlib.js JavaScript library to decompress the binary client-side, after undoing the Base64-encoding. While this significantly reduced the size of the Base64-encoded WebAssembly binary, it required ~6.5 kB for the decompression code, after gzip compression.1
While I liked the idea of compressing the WebAssembly binary prior to Base64-encoding it, I thought there must be a way of decompressing it with a smaller decompression code. The simplest change would be to use a raw Deflate-compressed payload instead of one encapsulated with gzip, as the zlib.js library also provides a decompression function for this, which is only ~2.5 kB after gzip-compression, saving ~4 kB. However, this is still excessive, since it shouldn’t be necessary to provide a Deflate decompression function as web browsers include such functionality. Although such decompression functionality isn’t exposed directly to JavaScript, PNG images can be decoded from JavaScript, and PNG images use Deflate compression. Thus, I decided to encode the WebAssembly binary as a grayscale PNG image, Base64-encode the PNG as a data URI, and include the resulting string in the JavaScript file. Continue reading
The author mentioned 12 kB of decompression code, but that was without gzip-compression of the JavaScript code. ↩
