Perl Weekly Challenge 016
As with the previous weekly challenges the problem statements are short and are included in the first comment of the code. The code blocks shown link to GitHub Gists. (I prefer to use the gists rather than linking to the code in the main repo since it seems that the gist URLs are more permanent. The main repo is a fork which might get deleted or substantially re-organized at some point.)
(shown are the person, amount eaten, and amount remaining)
1 1 99
2 1.98 97.02
3 2.9106 94.1094
4 3.764376 90.345024
5 4.5172512 85.8277728
6 5.149666368 80.678106432
7 5.64746745024 75.03063898176
8 6.0024511185408 69.0281878632192
9 6.21253690768973 62.8156509555295
10 6.28156509555295 56.5340858599765
11 6.21874944459742 50.3153364153791
12 6.03784036984549 44.2774960455336
99 9.23929532895044e-39 9.33262154439444e-41
100 9.33262154439444e-41 0
To simplify things I standardize the size of a single pie to be 100. 100 what? Let's call them pie units (not π!).
At first I made some assumptions such as only having integer slices of pie. That is, rounding each calculation to the nearest integer. This resulted in fewer than 100 slices and the spirit of the problem is to have exactly one slice for each of the 100 guests, although each slice would be of vastly different sizes. I then tried different rounding with sprintf() but soon realized that if I didn't do any rounding at all then we would, of course, get 100 slices! The largest slice would be given to the tenth person who would receive ~6.28 pie units. As the slicing continues the last people get only the most minuscule quantum of pie. Not unlike the bread slicing from the Disney classic Mickey and The Beanstalk.
$ perl perl5/ch-2.pl 1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN0
1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN0 is INVALID
$ perl perl5/ch-2.pl 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLY
3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLY is INVALID
$ perl perl5/ch-2.pl 1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2
1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2 is VALID
$ perl perl5/ch-2.pl 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy
3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy is VALID
Probably the most challenging aspect of Part 2 is the use of the unusual base 58. Bitcoin being so popular has led to this being fairly well documented[1, 2], however. The code is broken into essentially two functions, one which converts the address string to bytes and another which validates the bytes (as documented).
As usual I only use modules from CPAN if I really really need to and I think this is a reasonable case, since I don't think there is anything gained here by re-implementing SHA256 myself! CPAN has several good options for this and Digest::SHA seemed like a good choice.