Phone number:

Cost:

Category:

Subcategory:

In Switzerland, you can buy custom mobile numbers starting with 079 or 075. As with other issued numbers (e.g. license plates for cars), some combinations of numbers are more popular than others.

But what exactly makes a number “special”, simple or memorable? Swisscom introduces categories (or “classes”) with certain prices, the simpler the number, the more you pay for it. You can have a look at the whole table here: Einfache Rufnummer

The script above recognizes the categories and shows the matching price.

Have fun!

]]>(Or: How many hash-digits should I check to be somewhat sure to not have a collision?)

Expected tries:

Max. collision probability (in %):

Min. space of possible values:

Example of random hash:

(better collision probability approx.: {{prob}})

Last week at work, I worked on some piece of code and everytime after a change, a new build artifact would be assembled which I had to test.

They would look like this:

- build_
**760aa1cd**.zip - build_
**ef08028e**.zip - build_
**081b0505**.zip

with the last part being some kind of random hash (of the SHA family). Now for testing I had to be sure that I wouldn’t pick an old build and I just memorized the first three letters of the random hash, for example “build_**ef0**“.

I then wondered, how many digits should I have to memorize for being reasonably certain that I wouldn’t have a “collision” with an already existing build artifact? I was searching for how big the sample space should be.

Jeff Preshing wrote a nice post about Hash Collision Probabilities, and it contains the following formula:

where

**p**: probability that at least two of them are equal**k**: number of randomly generated values**N**: the sample space

With the simplified versions, we can easily calculate how big the space should be:

Solving for **N**, we now know:

If you expect to compare

50different hashes and you want to have a maximum collision probability of20%, you should have a space of at least6125, or3.15hexadecimal hash digits.

Which means that my initial 3 digits are just not enough to get a collision in only 20% of the time. In reality, if one would pick 50 random 3-digit hashes, the collision probability would be around 26%.

You can punch in some other numbers in the calculator at the beginning of this post. The sample space is an approximation (which performs good for low probabilities, see Jeff’s post), the better probability approximation of having a collision is calculated separately below the calculator.

Happy hacking!

]]>Another minigame, inspired by the Voyage 200 game Phoenix.

Made with ProcessingJS, code is on Github.

]]>

*Some of my Rubik’s Cubes*

I tried some different methods, starting with the Beginner’s Method, working my way into the more complex ways to solve the cube, ending at some tutorial with the following statement:

OLL: There is nothing in this step except learning 57 algorithms for 57 cases.(Link)

**Nope thanks.**

I then realized a simple fact: Solving the Rubik’s Cube isn’t that hard, but memorizing algorithms is, at least for me, and especially keeping all those algorithms in memory. I also realized that for me, as an occasional cuber, it would be more important to just be able to solve it, even if I didn’t do it for some months or years.

After the maybe 10th time I decided I needed some special recipe, specifically tailored to fit my needs:

- Only a few algorithms to learn, use intuition as far as possible
- Some mnemonics to memorize the algorithms
- Still able to solve the cube in 2-3 minutes
- Should be expandable / reusable if I wanted to improve or get faster

So that’s when I decided to create my own, customized sequence of steps for solving the cube and made a recipe for me to reduce the algorithms and being able to memorize them.

It’s somewhere between this very simple method by Badmephisto (only available as WebArchive backup) and the little more sophisticated approach of Jasmine’s Beginner Method.

On a high level, I’m using the CFOP-method (popularized by Jessica Fridrich), which means we don’t solve the cube side by side, but use a layered approach.

The steps are as follows:

**Cross****F2L**– first 2 layers**OLL**– orientation of the last layer**PLL**– permutation of the last layer

To understand the algorithms, you’ll need to understand basic cube notation, but only the real basiscs, e.g. L R U D F B and that ‘ means backwards.

The beginning is always the cross on the first, white layer, extending to the middle layer. If you tried solving the Rubik’s Cube before this should be easy to do by intuition, and after this first step you should have something looking like this:

*front and back of a solved cross*

After this step, the white side is turned down and everything from now on is done from this new point of view.

The first two layers are most time-consuming, even for real speedcubers. I decided to take the approach where we first allocate the two missing pieces, bring them together and then put them into place in the correct slot. (Opposed to the approach where you first bring the corner into position and then the middle piece, which I think is far even complicated.)

If you do this often enough, this should be manageable to do by intuition. I’m not going to focus on this here, because it’s really individual how you’re approaching the solving by intuition, and also because it takes some time and practice to really grok it.

For some practical tips and inputs have a look at this video tutorial (which is one of few being reasonably slow):

The big advantage of learning to solve F2L by intuition is that it’s nearly impossible to forget! Even if you’re missing some parts you can re-learn it really quick by practicing.

Now to our first algorithm. Hooray! We have the first two layers and want to build a cross, like in the beginning, except now we only care for the **orientation** of the last layer, nothing else.

I memorized this as always starting with the front side **F**, then **R** and **U** in the middle, first normally and then backwards, and at the end move the front backwards again. To distinguish between the two cases above: If it’s a line, break that line by first moving **R**, else first move **U**, everything else is the same.

Oh, and if there’s only the center of the face yellow, do one of them at random and you should get a state from above. Then do the appropriate one to complete the yellow cross.

Next up is a neat little algorithm which I memorized by “twist and turn”. It’s really simple if you take apart the two hands: Your right hand just moves up and down, simple as that. Your left hand just turns the uppermost layer clockwise – two times one turn, and the third time two turns to complete a full rotation.

For the second algorithm on the right, just do the same for the right hand, but start at the end and move anti-clockwise with your left hand.

This was the most difficult algorithm for me, and needed a good technique for memorizing. The start is on the right, like all the other ones except for the first one. Then, it gets quite simple: Just go back and forth between the back and front (over the right side) until you’re finished. This was my main insight for remembering this one.

There are some other helpful observations:

- On the back, always do a double turn.
- For right and front, alternate between clockwise and anti-clockwise – after coming back the first time from the back, go clockwise, the next time you pass anti-clockwise, and so on. As you may notice, this doesn’t add up in the end, but by then, it’s pretty clear how to finish the algorithm with some additional R turning.

This one is my favourite algorithm. Partly because it’s the last one and after that you’re finished, but also because you can hold the middle while turning.

You prepare with R2 and U, and then the **F B’** part happens, where you can turn the sides to the right. After a quick R2, you can turn them back with **F’ B**, and you’re nearly done. I call this one the whopper because the rorating sides with the stable middle always reminds me of a hamburger :-)

It’s possible that you’ll have to repeat this one, if all four edges on the last layer are incorrectly placed. If this is the case, make sure to think of how they’re going to be aligned after you do it once.

That’s all! **4 algorithms** (partly with some second variation) are enough to solve the cube, keeping the amount of moves to memorize really low, but also enable you to solve the cube within 2-3 minutes with some practicing. I encourage you to give them some silly names yourself as they will stick far better that way :-)

Here’s a cheat sheet with the moves:

You can also download a printable PDF here.

]]>The problem is, as an external developer, I only have access to the load balancer, and not to the nodes themselves. To test it – we had some problems with authentication on the development system – I would have to make sure that every node could be reached.

I wondered: **If the load balancer would route me to each node with an equal probability of 1/6th, how many times would I have to try to get to all nodes?** 10 times? 15 times? And how sure could I be that all nodes would have been reached?

I googled around and found out that my problem’s essentially the same as **throwing a dice and getting each number at least one time**. It’s called the Coupon collector’s problem – how long does it take to collect a certain number of items – and I found out quickly some calculations about the expected value: It’s 14.7.

But that wasn’t enough for me, I wondered, what if I want to be at least 95% sure to get to all nodes? Calculating the exact probability density function apparently is a lot harder than just calculating the expected value. But hey, who needs complex math if a 30 line python script and some computing power can produce a nice approximation? :-)

This is the **empirical probability density function** for 10**8 (a hundred million) tries:

Code: Gist

Some interesting observations here:

- The best case was 6 throws (obviously, if we got lucky), which is pretty rare (only about 1.54% of the cases), but the worst case was a whopping 126 tries, once out of a hundred million. Bad luck!
- The graph has positive skew, which means mode, median and mean are note the same.
- The mode is at 11 throws, with 8 441 391 (8.44%) results it’s the most common value.

So based on the experimental data, the percentiles I searched for are the following:

**50% → 13 throws****90% → 23 throws****95% → 27 throws****99% → 36 throws**

So to be **95% sure** to get to every node, I would have to fire a total of **27 requests** at the load balancer.

Thanks for reading!

]]>