Blog & White

Let's consider base 10 logarithms and the basic equality

log(a×b) = log(a) + log(b)

Rounding to two places after the decimal separator, we also start with

log(2) = 0.30

and

log(10) = 1

Therefore, we have

log(4) = 2⋅log(2) = 0.60

and

log(8) = 3⋅log(2) = 0.90

Also,

log(10) = log(2) + log(5) = 1

therefore

log(5) = 0.70

Then a bit more approximation: 81 ≈ 80, therefore

2⋅log(9) ≈ log(10) + log(8)

This gives us

log(9) ≈ 0.95

and

log(3) = log(9)/2 = 0.48

as well as

log(6) = log(2) + log(3) = 0.78

In the same way, 50 ≈ 49, therefore

log(5) + log(10) ≈ 2⋅log(7)

in other words,

log(7) ≈ 0.85

With more approximations, one will find the logs of more prime numbers without the need for a calculator.

Voici le circuit millésime juillet 2014, tout en virages, il n'est pas facile à parcourir. Cette année, les voitures rouge et bleue sont devenues poussives vers la fin des vacances. Difficile de savoir si le problème vient d'un mauvais contact entre les rails et la voiture, des balais ou d'un frottement mécanique (au niveau de l'axe du moteur ?). Un patin de la rouge s'est percé à force de frotter contre les rails, je l'ai réparé en y mettant un peu d'étain à souder (et comme il s'agit d'un alliage à 60% de plomb, ça doit polluer un peu en prime…)

On the radio the other day, I heard a mathematician warning about too hastily interpreting probability results. Here's the example he gave.

Imagine a population of 100,000 people, 100 of which having a rare disease (but not knowing about it) and therefore 99,900 of which not being sick. Imagine moreover there is a test that can detect this disease with a 99% accuracy: this means that the test will on average give a positive result on 100 × 0.99 = 99 of the 100 sick persons and a negative result on 100 × (1 - 0.99) = 1 of them. It will also give a negative result on 99,900 × 0.99 = 98901 non-sick persons and a (false) positive result on 99,900 × (1 - 0.99) = 999 non-sick persons.

This means that out of the 99 + 999 = 1098 persons (out of the whole population) who got a positive result, only 99 actually have the disease. This means that the test indicates, for a random person taken from the whole population, only a 99 / 1098 ≈ 9% probability of being sick. In other words, even if the test is positive, there is still a 91% chance of not being sick! This new result needs to be put into perspective with the probability of being sick before doing the test (0.1%) and after getting a positive test result (9%, i.e., 90 times higher chance of being sick). But it also means that because of the imbalance between sick and non-sick populations, the 1% failure of the test will yield a lot more false positive results among the non-sick population than correct positive results among the sick population.

I finally built the timer for the new Leffakone. It is based on an Arduino Uno, which controls two reed relays and one LED. The reed relays can be activated with a very low current (10 mA), meaning that the Arduino can drive them directly from any I/O pin. The relays' contacts are connected in parallel to the power button and the reset button. The Arduino's serial-over-USB port is connected to one of the USB headers of the motherboard with a home-made cable, and the timer is set by software through this serial connection. All the wires coming from the computer case's front panel are connected to the circuit (to the 8-pin header protruding from the protoboard), and wires go from there to the motherboard's front-panel header (2 white wires for the power button, 2 grey wires for the reset button, and 2 blue+black wires for the power-on LED. The two boards are screwed on the bottom plate of the case of an old CD drive; for installation, I closed the case and put it into the computer as a regular CD drive.

While the timer is counting down, it blinks the computer case's HDD LED (which therefore is not anymore indicating the HDD activity).

When the timer expires, it closes the power button's relay for 500 ms. An optional watchdog timer would close the reset button's relay if the machine does not boot correctly i.e., if the timer is not reset within 30 s. This watchdog timer is currently disabled in the code, since the problems I have had with GRUB freezing on startup seem to be related to manually powering the device and switching the TV on shortly after. I'll enable it if it seems necessary. Here is the code for the Arduino.

The software client for the timer is written in Python and is very straightforward: send ASCII digits to the serial port, ending with a newline character. It interprets this number as a number of seconds, and starts counting down. When disconnecting the client from the serial port, the Arduino resets and forgets all about the timer value; I found out that setting the DTR line to False in the Python Serial object prevents this from happeining. I haven't however found out how to prevent a reset when connecting to the Arduino; this is less a problem, since when I connect to it, I want to reset the timer, and reseting the whole program does just that. It seems that it's the Linux driver that asserts the DTR line when opening the serial port; I haven't investigated further. It is worth noting that when the machine boots, it does not reset the Arduino.

Finally, the cristal in the Arduino is accurate to 99.5% which is not enough to guarantee that the timer will wake up the computer within a minute after a countdown of several days. I therefore apply a corrective factor to the time sent to the Arduino. The factor was estimated from a 15.5 hour countdown, which lasted about 90s more than it should have. Over a 7-days countdown, it would cause the timer to expire about 16 minutes too late.

Before Easter, the supermarket was selling Rölli suprise-eggs, announcing that every fifth egg contained a figurine related to Rölli's universe. This made me wonder: how many eggs you need to buy to ensure that you get at least one such figurine?

The following formula gives the probability (p) of getting at least one Rölli figurine given that one has bought n eggs, and that every k egg contains such a figurine:

p = 1 − (1 − 1/k)ⁿ

The answer to the first question is not straightforward, though. To be absolutely sure to get at least one figurine, you need to buy 4/5 of the egg production plus one egg, because there is always an (admitedly slim) chance that the 4/5 of are made entirely of eggs containing something else than a Rölli figurine, and that the 1/5 that is left is made only of eggs containing Rölli figurines. The extra egg that you need to buy is therefore taken from this last 1/5, and is guaranteed to contain a Rölli figurine.

If you are not willing to spend so much time and money tracking and buying most of the egg production, you can trade time and money for a tiny bit of uncertainty. For example, if you can accept to have only 90% chance of getting a Rölli figurine instead of 100%, it is enough to buy 11 eggs. If you want a better chance yet and want to go for 95%, you need to buy 14 eggs. Finally, if you want a 99% chance, you need to get 21 eggs. These values were computed from the formula above, setting k = 5 (“every fifth egg”), p = 0.90 or p = 0.95 or p = 0.99, solving the equation for n and rounding the result to the nearest, larger integer.

It is also worth noticing that if you decide to buy 5 eggs (because every 5th egg contains a Rölli figurine), you have only about 2 in 3 chances of getting a Rölli figurine.

The table below gives the minimum values of n for a given value of k and different probability thresholds. It also gives the ratio n over k, i.e., given a “one in k” probability, how many times k does one need to get to have a probability greater than the thresold. The second column also indicates, given a “one in k” probability, what are you chances of getting what you want if you get k items. Notice that these values grow toward a given, finite limit when k grows larger.

k	p(n=k)	p≥0.90 (n/k)	p≥0.95 (n/k)	p≥0.99 (n/k)
2	0.750	4 (2.000)	5 (2.500)	7 (3.500)
3	0.704	6 (2.000)	8 (2.667)	12 (4.000)
4	0.684	9 (2.250)	11 (2.750)	17 (4.250)
5	0.672	11 (2.200)	14 (2.800)	21 (4.200)
6	0.665	13 (2.167)	17 (2.833)	26 (4.333)
7	0.660	15 (2.143)	20 (2.857)	30 (4.286)
8	0.656	18 (2.250)	23 (2.875)	35 (4.375)
9	0.654	20 (2.222)	26 (2.889)	40 (4.444)
10	0.651	22 (2.200)	29 (2.900)	44 (4.400)
20	0.642	45 (2.250)	59 (2.950)	90 (4.500)
37	0.637	85 (2.297)	110 (2.973)	169 (4.568)
50	0.636	114 (2.280)	149 (2.980)	228 (4.560)
100	0.634	230 (2.300)	299 (2.990)	459 (4.590)
500	0.632	1151 (2.302)	1497 (2.994)	2301 (4.602)
1000	0.632	2302 (2.302)	2995 (2.995)	4603 (4.603)

One can use this table to find out how many times one needs to play the roulette in a casino to have 95% chance of winning at least once: a european roulette has 37 numbers (k = 37), and the limit of the n/k ratio is about 3; one therefore needs to play about n ≅ 37 × 3 = 111 times (the row for k = 37 indicates the actual value is n = 110).

My new computer has a UEFI firmware. I installed Debian Wheezy, which in turn installed the EFI variant of GRUB. For that purpose, the Debian installer made the first partition on the hard disk drive of type VFAT and mounted in /boot/efi.

My problem is that GRUB tends to freeze, either just before booting the kernel (showing forever “Loading initial ramdisk”) or just after the welcome message (“Welcome to Grub!”). Pressing the computer's reset button allowed to reboot the computer, and everying went then fine. It seems to be possible to reproduce the bug at will by switching off the power supply, waiting 15 seconds for the capacitors to get empty and then reboot the computer. Booting however also hangs quite often after powering the computer off in software (where the power supply still provides some power to the motherboard).

I read here and there that EFI GRUB was quite buggy, so I decided to switch to PC GRUB (the variant for booting with the Legacy firmware, aka BIOS).

In a first attempt, I configured the motherboard's firmware to use “Legacy ROM only” instead of “UEFI only”. Debian continued to boot normally with the still installed EFI GRUB, and the freeze when rebooting after having switched off the power supply seemed to have disappeared. It howerver froze again today and so I decided to change from EFI GRUB to BIOS GRUB.

I first ran apt-get install grub-pc, which complained that

/usr/sbin/grub-setup: warn: This GPT partition label has no BIOS Boot
 Partition; embedding won't be possible!.
/usr/sbin/grub-setup: warn: Embedding is not possible.
 GRUB can only be installed in this setup by using blocklists.
 However, blocklists are UNRELIABLE and their use is discouraged..

After a bit of research on the Web, I found someone's advice to change the flag of the FAT partition to bios_grub. I then forced the reinstallation of grub-pc with apt-get install --reinstall grub-pc, which didn't complain anymore.

On the next reboot however, the startup script indicated that “fsck died with status 6”. I found out that it tried to check the VFAT partition, but since GRUB is now installed there, it is not anymore recognized as a VFAT partition, and fsck was legitimately skipping it. parted confirmed that fact, and blkid does not list the VFAT partition anymore either. I therefore commented it out in /etc/fstab and now the boot does not fail anymore.