The Tosser

Here’s a LEGO dice-tossing machine I built.

The two complicated parts are the reduction gear train and the flaps that re-center the dice so that the machine can pick it up correctly each time.

The gear train is composed of several gear reducers, which are composed of a small gear driving a larger gear (thus many turns of the small, driving gear, are needed for the big one to make a complete rotation). Each large gear share its spindle with a small gear that drives the next stage. The gear box yields a 243:1 reduction (which is to 1). Otherwise the motor spins too fast and just, well, eject the dice from the machine.

The flaps are used to funnel the dice back in the middle of the tray, where it can be picked up again.

*
* *

The next step would be to use OCR to read the dice value and see if, in the long run, the tosser is a strong number generator or if it is flawed in some way. Can’t really remember where I got the 16-sided dice, but there are some to be found online.

The Cutest Littlest Forkbomb

In one of his last tweets @levans posted the cutest Rust-lang fork bomb:

fn main(){std::thread::spawn(main);main()}

at 42 characters longs, which he sees like a sign. Excluding headers, you can do even shorter in C++:

main(){boost::thread x(main);main();}

It’s not really a terrifying forkbomb (as Linux, for e.g., kills everything after a while because processes run out of memory), and we could have done much worse with a process-level (rather than a thread-level) forkbomb:

main() { fork(); main(); }

This variant creates separate processes… none of which individualy can exhaust its memory! Don’t try this one on your main box (but it could be fun in a virtual machine).

Easy Timestamping with Bash

Here’s a quick Bash script to prefix lines read from standard input by a time stamp.

#!/usr/bin/env bash

while read line
do
    echo $(date "$@") "$line"
done

This script takes the same arguments as the traditional Unix date program. With no arguments, it prints some default-formatted date, but if you feel like it, you can pass it the same arguments as date. For example:

.../geolocalisation> cat /dev/ttyACM0 | ts.sh +"%H:%I:%M:%S.%N" | grep GPRMC | tee $(date | tr \  - | tr : - ).dat
15:03:42:57.355437828 $GPGGA,204226.000,4821.6737,N,06844.4790,W,1,08,1.2,-0.9,M,,,,00$GPRMC,204247.000,A,4821.6740,N,06844.4799,W,0.00,181.2,060215,,*2B
15:03:42:57.629415235 $GPRMC,204248.000,A,4821.6740,N,06844.4799,W,0.00,181.2,060215,,*24
15:03:42:57.881812555 $GPRMC,204249.000,A,4821.6740,N,06844.4800,W,0.00,181.2,060215,,*2A
15:03:42:58.150091204 $GPRMC,204250.000,A,4821.6740,N,06844.4800,W,0.00,181.2,060215,,*22
15:03:42:58.420285771 $GPRMC,204251.000,A,4821.6740,N,06844.4800,W,0.00,181.2,060215,,*23
15:03:42:58.682492676 $GPRMC,204252.000,A,4821.6740,N,06844.4800,W,0.00,181.2,060215,,*20

So Let’s examine the script more closely. The $@ passed as argument to date is the series of all arguments passed to the script. Why is it enclosed in quotes? Because it preserves the structures of the arguments passed to the script for date. In the specific case of date it might not be necessary because of the nature of its arguments, but should you replace date with some other command, it may cause problems to remove the quotes. The $line is also enclosed in quotes because otherwise the script misbehaves: it would, for example, try to expand *.

Comparing GPSes (yet more GPS data)

In a few other entries, I’ve toyed with GPS, either getting or parsing the data with Bash, assessing or using the GPS data. However, when we use GPS, we suppose that the precision varies by brand and model&mdashsome will have greater precision—but our intuition tells us that two GPS devices of the same brand and model should perform identically. That’s what we’re used to with, or at least expect from, computers. But what about USB GPS devices?

So I got two instances of the same model+brand GPS. Let them call them GPS-1 and GPS-2. Do they perform similarly?

Building a Book Scanner (Part II: Tray)

Last week, I showed how I built the lectern for my book scanner prototype. This week, let’s have a look at the tray holding the glass needed to keep the book evenly opened.

Building a Book Scanner (Part I: Lectern)

I’ve been thinking of making my own book scanner for a while now. Since only thinking about something doesn’t get you anywhere, I’ve actually started building it.

But before we get to the building of the device—still in progress—let me explain by design goals. The first and foremost goal is that the scanner has to be book-friendly. If you’re going to destroy the book, you might as well use a bandsaw and cut its back off, and use a paper-feed scanner of some sort. So to avoid damage, the lectern on which the book will rest has to be soft, and avoid the need to split the book open.

Swatches!

I’ve been using fountain pens for a long time, but I only recently began to appreciate ink. Yes, there are more colors than black and blue-black.

One of the more difficult thing is to choose a color that actually pleases you. Of course, you can browse online stores to get ink, but the colors presented in the swatches are not all that fateful to the actual color you will get out of your fountain pen. Sometimes you have a nice surprise, sometimes you’re disappointed.

Stirling’s series

Last week, we had a look at how g++ handles tail-recursion. Turns out it does a great job. One of the example used for testing the compiler was the factorial function, .

We haven’t pointed it out, but the factorial function in last week’s example computed the factorial modulo the machine-size (unsigned) integer. But what if we want to have the best possible estimation?

Of tails.

In a previous post, I explored the effect of pruning on a recursive function, namely, the Collatz function. Richard (see comment) asked “does your compiler know about tail recursion?”. Well, I didn’t know for sure. Let’s find out.

Of Colorspaces and Image Compression (Part III)

Last week, we continued on color spaces, and we showed—although handwavingly—that we’re not very good at seeing color differences in hue and saturation, and that we’re only good at seeing difference in brightness. In this last part, we’ll have a look at how JPEG exploits that for image compression.