F# — Pipe Forward and Pipe Backward

I’m tak­ing a bit of time to brush up my knowl­edge of F# and see if I can write bet­ter F# code and one of the things I notice is that whilst I use pipe-forward oper­a­tor (|>) often when work­ing with col­lec­tions I don’t nearly use the pipe-backward oper­a­tor (<|) as fre­quently as I should. It makes sense as the pipe-forward oper­a­tor works sim­i­lar to the way LINQ and IEnu­mer­able works, just to remind myself and oth­ers like me how these work:

Pipe-forward oper­a­tor (|>)

Pipe-forward oper­a­tor lets you pass an inter­me­di­ate result onto the next func­tion, it’s defined as:

let (|>) x f = f x

For instance, to apply a fil­ter (i.e. IEnumerable.Where) for even num­bers to a list of inte­gers from 1 to 10, you can write:

You can add fur­ther pro­cess­ing steps to this inter­me­di­ate result:

For­ward com­po­si­tion operator (»)

The for­ward com­po­si­tion oper­a­tor lets you ‘com­pose’ func­tions together in a way sim­i­lar to the way the pipe-forward oper­a­tor lets you chain func­tion del­e­gates together, it is defined as:

let (») f g x = g (f x)

Now imag­ine if you have two functions:

You can use them to build a high-order func­tion that returns triples the square of a float, n, using the » operator:

This is syn­tac­ti­cally cleaner and eas­ier to read than:

and it’s espe­cially use­ful when chain­ing together a large num­ber of functions.

Pipe-backward oper­a­tor (<|)

The pipe-backward oper­a­tor takes a func­tion on the left and applies it to a value on the right:

let (<|) f x = f x

As unnec­es­sary as it seems, the pipe-backward oper­a­tor has an impor­tant pur­pose in allow­ing you to change oper­a­tor prece­dence with­out those dreaded paren­the­ses every­where and improve read­abil­ity of your code,.

For exam­ple:

can be writ­ten as

Back­ward com­po­si­tion operator («)

The inverse of the for­ward com­po­si­tion oper­a­tor, the « oper­a­tor takes two func­tions and applies the right func­tion first and then the left, it’s defined as:

let («) f g x = f (g x)

Mostly I find it more suit­able than the for­ward com­po­si­tion oper­a­tor in cases where you want to negate the result of some func­tion, for exam­ple, to find the odd num­bers in a list:

Can you solve the google puzzle?

You can find the google puz­zle here, it’s extremely cool and equally frus­trat­ing! That’s half an hour of my life I won’t be get­ting back but at the end of it well sat­is­fied to have solved it!

Enjoy!

The cost of throwing exceptions

After read­ing Ayende’s post today, it got me think­ing, just exactly what’s the cost of a try/catch block and more impor­tantly what’s the cost of throw­ing excep­tions.

Like Ken Egozi men­tioned in the com­ments, I too believe the test was unfair as the try/catch block was applied to the top level code as opposed to each iter­a­tion. How­ever, based on every­thing I know about excep­tion in .Net I’d imag­ine what­ever per­for­mance cost will be asso­ci­ated with throw­ing the excep­tions rather than sim­ply try­ing to catch them. With that in mind, I decided to carry out my own set of tests to try out three sim­ple cases:

1. 10000 invo­ca­tions of a blank Action del­e­gate, this should be con­sid­ered as the ‘base line’ of the cost of iter­at­ing through the inte­gers 1 – 10000 and what­ever cost of invok­ing a delegate

2. 10000 invo­ca­tions of a blank Action del­e­gate INSIDE a try-catch block, this should indi­cate the addi­tional cost of try­ing to catch an excep­tion when com­pared with 1.

3. 10000 invo­ca­tions of an Action del­e­gate that throws an excep­tion INSIDE a try-catch block, this should indi­cate the addi­tional cost of throw­ing and catch­ing the excep­tion when com­pared with 2.

Each test of 10000 invo­ca­tions are repeated 100 times (no debug­ger attached) and here are the aver­age exe­cu­tion times in milliseconds:

For any­one who wants to try it out them­selves, I’ve posted the code on github here.

As you can see, wrap­ping a call inside a try-catch block doesn’t add any mean­ing­ful cost to how fast your code runs, although there’s a mea­sur­able dif­fer­ence when excep­tions are repeat­edly thrown but 300 mil­lisec­onds over 10k excep­tions equates to over 30k excep­tions per sec­ond, which dare I say is more than any­one would ratio­nally expect from a real-world application!

Another thing to con­sider is the impact the stack trace depth has on the cost of throw­ing excep­tions, to sim­u­late that I put together a sec­ond test which exe­cutes a method recur­sively until it reaches the desired level of recur­sion then throws an excep­tion. Each test per­forms this recur­sion 1000 times, and repeated over 100 times to get a more accu­rate read­ing. Here are the aver­age exe­cu­tion times in milliseconds:

Good news is that the cost of going deeper before throw­ing an excep­tion seems to be lin­ear as opposed to exponentially.

Clos­ing thoughts…

Before I go I must make it clear that excep­tions are nec­es­sary and the abil­ity to throw mean­ing­ful excep­tions is a valu­able tool for us devel­op­ers in order to val­i­date busi­ness rules and com­mu­ni­cate any vio­la­tions to the con­sumers of our code. As far as these per­for­mance tests go, they’re merely intended to make you aware that there IS a cost asso­ci­ated with throw­ing excep­tion and not to men­tion a lit­tle bit of fun!

Ulti­mately, throw­ing excep­tions means doing work, and doing work takes CPU cycles, so you really shouldn’t be sur­prised to see that there’s a cost for throw­ing excep­tions. Per­son­ally, I take my excep­tions seri­ously, for all the projects I have worked on I have taken the time to define a set of clear and mean­ing­ful excep­tions, each with a unique error code ;-)

The ques­tion you gotta ask your­self is this – would you trade 0.03ms in excep­tional cases for cleaner, more con­cise code that lets you com­mu­ni­cate errors to users more clearly and help you debug/fix bugs much more eas­ily? Know­ing that you end up pay­ing for it in terms of code main­te­nance, debug­ging time any­way, I sure as hell knows which one I’d pre­fer! Remem­ber, avoid pre­ma­ture opti­miza­tion, pro­file your appli­ca­tion, tar­get the real prob­lems and then opti­mize instead.

Find out which process is listening on a port

I needed to find out which process is lis­ten­ing on a port the other day and a quick search on SO showed me the way and all you need is to run:

net­stat –aon | find /i “listening”

and you will get a list of the ports and the PID of the process lis­ten­ing on that port:

Sweet!

Project Euler — Problem 59 Solution

Prob­lem

Each char­ac­ter on a com­puter is assigned a unique code and the pre­ferred stan­dard is ASCII (Amer­i­can Stan­dard Code for Infor­ma­tion Inter­change). For exam­ple, upper­case A = 65, aster­isk (*) = 42, and low­er­case k = 107.

A mod­ern encryp­tion method is to take a text file, con­vert the bytes to ASCII, then XOR each byte with a given value, taken from a secret key. The advan­tage with the XOR func­tion is that using the same encryp­tion key on the cipher text, restores the plain text; for exam­ple, 65 XOR 42 = 107, then 107 XOR 42 = 65.

For unbreak­able encryp­tion, the key is the same length as the plain text mes­sage, and the key is made up of ran­dom bytes. The user would keep the encrypted mes­sage and the encryp­tion key in dif­fer­ent loca­tions, and with­out both “halves”, it is impos­si­ble to decrypt the message.

Unfor­tu­nately, this method is imprac­ti­cal for most users, so the mod­i­fied method is to use a pass­word as a key. If the pass­word is shorter than the mes­sage, which is likely, the key is repeated cycli­cally through­out the mes­sage. The bal­ance for this method is using a suf­fi­ciently long pass­word key for secu­rity, but short enough to be memorable.

Your task has been made easy, as the encryp­tion key con­sists of three lower case char­ac­ters. Using cipher1.txt (right click and ‘Save Link/Target As…’), a file con­tain­ing the encrypted ASCII codes, and the knowl­edge that the plain text must con­tain com­mon Eng­lish words, decrypt the mes­sage and find the sum of the ASCII val­ues in the orig­i­nal text.