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.: {{hashLengthCtrl.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!

]]>

*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.

]]>Last week I had a closer look at LOLCODE!

Code in LOLCODE looks like this:

```
HAI
I HAS A CATNIP ITZ 3
IM IN YR LOOP UPPIN YR CATNIP
VISIBLE SMOOSH "I LUVZ CATNIP ITZ " AN CATNIP MKAY
IM OUTTA YR LOOP
KTHXBYE
```

Lolcode is fun to write and although inefficient, you can indeed do pretty much everything. There’s even a formal Lolcode 1.2 specification and a course on codeschool to learn the basics :-)

I decided to write a program that actually has some use, so I wrote a **Pokemon Go IV rater** in lolcode, check it out on Github.

*A solid Arkani with 91%!*

It calculates the special IV values (individual values) for a given pokemon (which are unique to each pokemon), you’ll just have to enter what kind of pokemon it is and some stats for it:

You can try it here: **repl.it**.

Just hit **Run** and enter your stats at the right. You can also use lol-coffee if you want to run it locally.

Unfortunately, it misses arrays and lists (as for now, there’s a reserved keyword BUKKIT for future versions), so I rewrote those as simple function calls, which is why the program ended up to be ~700 LOC. Other actions like input is really simple, here’s the beginning where the user gets asked all of the input values:

```
HAI
VISIBLE "O HAI!"
BTW GIMMEH GIMMEH GIMMEH!
I HAS A POKEMON_NR, VISIBLE "GIMMEH POEKMON NR", GIMMEH POKEMON_NR
I HAS A MY_CP, VISIBLE "GIMMEH CP", GIMMEH MY_CP
I HAS A MY_HP, VISIBLE "GIMMEH HP", GIMMEH MY_HP
I HAS A MY_DUSTPRICE, VISIBLE "GIMMEH DUSTPRICE", GIMMEH MY_DUSTPRICE
BTW SOEM MAGICAL MAHT FUNTCION HOW TO CALCULAET CP W00T HOW IS THS EVN WURKIN
HOW DUZ I CP_MULTIPLIER YR LVL
BOTH SAEM LVL AN 1, O RLY?, YA RLY, FOUND YR 0.094, OIC
...
```

]]>

*Part of the table at* *Wikipedia*

I immediately wondered if it would be possible to identify some (preferably small) portion of text by its language, solely by looking at the letter frequencies. Obviously there are far more elaborated methods like word recognition etc., but the approach with letter frequency has two advantages:

- no language knowledge necessary (e.g. dictionaries or grammar rules) except for letter frequencies
- simple to implement: little code and measurable results

(Code is on Github)

The basic idea is to first analyze the text and then calculate the mean squared error for each language, something like this:

- loop through text and calculate relative letter frequency (a: 3.3%, b: 2.1%, ….)
- for each language:
- load letter frequency for language
- compare frequency of each letter to frequency in text and add difference^2 to score for that language

- sort and output score for each language

Below are some text examples, and the mean squared error for each language (less is better):

In de prachtige zeestad Genua, de trotsche bijgenaamd, werd omstreeks het jaar 1435 een knaapje geboren, dat nu in alle landen als Christophorus Columbus bekend is. (…)

Solone, il cui petto un umano tempio di divina sapienzia fu reputato, e le cui sacratissime leggi sono ancora alli presenti uomini chiara testimonianza dell’antica giustizia, era, (…)

Jukolan talo, eteläisessä Hämeessä, seisoo erään mäen pohjaisella rinteellä, liki Toukolan kylää. Sen läheisin ympäristö on kivinen tanner, mutta alempana alkaa pellot, joissa, (…)

The three snippets provided are from Project Gutenberg, each one contains only the first 200 lines of the original book.

Interestingly enough, we also see which languages are similar to each other: For the italian text, spanish, french, esperanto and portuguese pop up first:

- Italian: MSE 0.0007 | 1503.6 points
- Spanish: MSE 0.0042 | 237.0 points
- French: MSE 0.0057 | 175.9 points
- Esperanto: MSE 0.0068 | 147.4 points
- Portuguese: MSE 0.0072 | 139.4 points

… while for the dutch text it’s german and danish:

- Dutch: MSE 0.0016 | 639.8 points
- German: MSE 0.006 | 166.3 points
- Danish: MSE 0.0076 | 131.6 points

We can also see that Finnish is quite an outlier, with only Esperanto somewhere near it, and all other languages are quit far away.

With a simple Python script and the table from Wikipedia we get some quite good results on our example texts! It is, however, quite a small subset of languages we’re checking here, so maybe a bigger set would reveal some more results.

Furthermore we also get some “relative” results how the languages stand to each other and how close they match the occurring frequencies of the example text.

Thanks for reading!

]]>