Following my back-to-back talks with the UK Developers Group and NxtGenUG Southampton, I just like to say thanks those guys for having me, it’s been a great pleasure :-)
For anyone interested, here are the links to the slides and the source code I used for the demo.
Slides: http://www.slideshare.net/theburningmonk/introduction-to-aspect-oriented-programming
Source Code: http://aop-demo.s3.amazonaws.com/AopDemo.zip
The square root of 2 can be written as an infinite continued fraction.
The infinite continued fraction can be written, ?2 = [1;(2)], (2) indicates that 2 repeats ad infinitum. In a similar way, ?23 = [4;(1,3,1,8)].
It turns out that the sequence of partial values of continued fractions for square roots provide the best rational approximations. Let us consider the convergents for ?2.
Hence the sequence of the first ten convergents for ?2 are:
1, 3/2, 7/5, 17/12, 41/29, 99/70, 239/169, 577/408, 1393/985, 3363/2378, …
What is most surprising is that the important mathematical constant,
e = [2; 1,2,1, 1,4,1, 1,6,1 , … , 1,2k,1, …].
The first ten terms in the sequence of convergents for e are:
2, 3, 8/3, 11/4, 19/7, 87/32, 106/39, 193/71, 1264/465, 1457/536, …
The sum of digits in the numerator of the 10th convergent is 1+4+5+7=17.
Find the sum of digits in the numerator of the 100th convergent of the continued fraction for e.
If you look at the convergents of ?2 and the numerators in the convergents of e, you’ll see a pattern emerging:
1 + 2 * 1 = 3
2 + 3 * 2 = 8
3 + 8 * 1 = 11
8 + 11 * 1 = 19
11 + 19 * 4 = 87
If you look at the sequence of numerators in the convergents of e ( 2, 3, 8, 11, … ) and the sequence of numbers in the convergents of ?2 ( 1, 2, 1, 1, 4, 1, … ), given the current numerator ( n ) and the previous numerator ( n-1 ) in the sequence and the corresponding number in the convergents of ?2 ( i )the next numerator ( n+1 ) can be calculated using the formula:
( n+1) = ( n-1 ) + n * i
Once we have this formula to work with, the rest is simple, the solution runs in 7 milliseconds on my machine.
Consider the fraction, n/d, where n and d are positive integers. If n < d and HCF(n,d)=1, it is called a reduced proper fraction.
If we list the set of reduced proper fractions for d <= 8 in ascending order of size, we get:
1/8, 1/7, 1/6, 1/5, 1/4, 2/7, 1/3, 3/8, 2/5, 3/7, 1/2, 4/7, 3/5, 5/8, 2/3, 5/7, 3/4, 4/5, 5/6, 6/7, 7/8
It can be seen that 2/5 is the fraction immediately to the left of 3/7.
By listing the set of reduced proper fractions for d <= 1,000,000 in ascending order of size, find the numerator of the fraction immediately to the left of 3/7.
This problem is fairly easy, given that the answer we’re looking for much be very close to 3 / 7 (0.4285714286) I simply iterate through the denominators, d, and find the closest numerator, n, which will produce a value less than 3 / 7. Then filter the set so we end up with only the n, d pairs that have a GCD of 1 and pick the numerator from the n, d pair whose n / d fraction is the biggest.
Note: Don’t forget to check out Benchmarks page to see the latest round up of binary and JSON serializers.
Follow on from my previous test which showed that the ServiceStack.Text JSON serializer was the top dog in town, I came across a little library called fastJson on codeplex so naturally I had to test it out and see how it compares to the rest!
So using my SimpleSpeedTester and repeating the same test as before I got the following results:
And graphically, this is how they look:
fastJson was the fastest in serialization and ServiceStack.Text was fastest in deserialization but there is very little separating the two libraries in both cases. Given a different data structure to serialize/deserialize you might end up with slightly different results but at the end of the day the two serializers have similar performance characteristics and both are some way ahead of the other JSON serializers I’ve tested.
Following on from request by @ICooper, I’ve included JayRock in the mix. However, as I had trouble deserializing (serializing was fine) the List<int> with JayRock I modified the test object slightly:
Otherwise, the conditions of the test are as before, and the results are as follows:
And graphically:
ServiceStack and fastJson still offer by far the best performance, especially with deserialization, but this time around ServiceStack proved to be the slight better of the two, why that’s the case with an int[] instead of a List<int> is beyond me though!
Again, if you’re interested in seeing the test code yourself, you can browse it here on Codeplex.
If your have a type that represents a collection of values, adding a custom indexer gives you a natural way to index directly into the object using the .[ ] operator.
Take this simple Calendar class for instance, which keeps a map (F# equivalent of a Dictionary<TKey, TValue>) of notes against DateTime values:
By adding a custom indexer here I’m now able to write code like this:
Also, as you may have noticed already, F# allows you to use non-integer parameters in your indexer! In this case, I’m using a tuple of int * string * int. You can use this indexer from your C# code too:
That’s pretty cool, but we can go a step further by allowing you to use slicers on our types too. To allow users to get all the notes associated with a range of years, e.g. from 1999 to 2009, let’s add a slicer:
So now we can do this:
Pretty awesome, right? But what if we want to refine our search criteria even more and let you specify a year range as well a range of months, e.g. get me all notes for April/May/June in the years 1999 to 2009. Thankfully, F# lets you define a two-dimensional slicer too:
This two-dimensional slicer allows me to query the calendar with a year range as well as a month range:
As you can see, indexers and slicers give the consumers of your code a much more intuitive way to interact with the data encapsulated in your type. Keep in mind though, that F# does not allow you to add slicer with more than two dimensions, but I think two-dimensional slicers should be good enough for most day-to-day requirements.
Swapped out my verbose optional argument handling with defaultArg as Arseny Kapoulkine pointed out in the comments.
