Corsis Research

2011 - Logo




Solidity, growth, and new dimensions!

Comments

Post a Comment

Popular posts from this blog

Levenshtein Distance Algorithm: Fastest Implementation in C#

Image
Here is a cleaned-up performance test for several different implementations of levenshtein I have blogged about recently. This test was emailed to me by Ahmed Ghoneim, who has also kindly agreed to its publication on my blog. I am very grateful to him for his excellent contribution. I have slightly altered his file to do away with the unnecessary local variables in my C2C# port of the GNULevenshtein method. I would like to hear from you which methods perform best on your machine. Please drop a comment ^_^! LevenshteinAlgorithmPerformanceTest.cs code only Packages code, data and sample binary in zip and self-executable zip formats Please note that the GNULevenshtein method was found to be buggy! Here is the new replacement method .
Read more

Levenshtein Distance Algorithm: Fastest Implementation in C#

Image
While reading some interesting stuff about minimum edit distances in preparation for today's lecture ( ECL/ICL ), which is just about 45 minutes ahead in time as I'm writing this, I had the chance to test 5 different implementations of the Levenshtein minimum edit distance algorithm. Here is a screenshot first: I'll get into details later but let me announce the winner! And the winner is ... gLDp! gLDp is a funny display name for a levenshtein implementation from a C project. original implementation in C: levenshtein.c my C# port: libcorsis code C vs CIL vs C# Now I want to get mercilessly picky with my own port and today's C# compilers. The ternary conditional expressions in my port (lines: #516 , #524 , #533 ) are there to circumvent the following restriction: // valid C int x = 0; int y = 0; int z = 0; z += x == y; x, y and z are initialized 0 and in the final line z gets incremented by 1. This is valid code in C but causes a compile-time error in C#: C# does no...
Read more

Haskell and F#: Language Design

Image
After watching a taste of Haskell by Simon Peyton-Jones and having a look at A History of Haskell: being lazy with class , I am left with some open questions regarding the design of F#: Why is F# not lazy?: What is the advantage of eagerness? Is there a point in encapsulating side-effectful operations in monads while programming in F#? IO Monads etc.? #light // Sample F# IO Monad : OSCON Haskell Video Part 2 type IO<'a> = IO of 'a // get: unit -> IO<string> let get () = IO(read_line ()) // put: string -> IO<unit> let put x = IO(print_string x) // bind.e: IO<'a> -> 'a // bind: IO<'a> -> ('a -> IO<'b>) -> IO<'b> let bind (x:IO<'a>) (y:('a -> IO<'b>)) = let e (IO(a)) = a in y (e x) let (>>=) = bind // gp: unit -> IO<unit> let gp () = get () >>= put gp () Why did the F# team chose ML and OCaml over Haskell? I hope someone from the F# team...
Read more