posted by martinmine

posted by aL_

All - The implementation of the Maybe monad used in this project is a much older implementation.  I've continued to improve it, adding operators, and I made a huge investment in improving the performance a number of months ago.  I'm going to drop the latest version of the Maybe monad implementation into this project and see what the performance numbers come out as.  I'll send Brian a pull request so you can see the results.

Beyond the Maybe monad implementation, I'm working on two others: Outcome and Result (which really derive from the Writer monad).  My blog has an *older* post explaining the Maybe monad and it's implementation (I'm in the process of writing an updated post), and you can see the code for all of it on GitHub and try it out through Nuget.  Watch my blog for more info on the Maybe, Outcome, and Result monad implementations.

• http://blog.jordanterrell.com/post/Maybe-The-Uh-Stuff-That-Dreams-Are-Made-Of.aspx
• https://github.com/iSynaptic/iSynaptic.Commons
• http://nuget.org/packages/iSynaptic.Commons

- Jordan

posted by jordanterrell

C

posted by Charles

posted by felix9

posted by faperdue2112

EDIT: Meant Brian Beckman fan But also McN fan too still

posted by bryanedds

My first job out of grad school involved "heavy industrial" Kalman in Fortran II at Jet Propulsion Lab, where we used them to track everything we could track in the solar system. Daily runs had around 1,000 parameters and 25 million observations, but that was decades ago, and that kind of thing can be easily done on a windows phone now (required liquid nitrogren back then  Imagine the applications!

posted by brianbec

I like the way the monadic laws are being expressed here:

https://github.com/iSynaptic/Monad-Comonad-Precis/blob/master/Precis.cs

posted by exoteric

I'm just now exploring what reactive facilities that F# conveniently exposes. I'm using it for declarative simulation building (think objects that transform themselves through time according to their environment without any manual mutation or effectful message passing). Because there is no classical mutation (and no mutation at all in debug mode), it should allow automatic parallelization of the simulation by dependency analysis. It also should make reasoning about large simulations tractable (you should see the simulation engine behind the Sims... a gargantuan mess from the eyes of a functional programmer, yet taken for granted by OO people). For further detail, AML and DOL.

posted by bryanedds

posted by Hamaze

Windows key & "+" -- turn on built-in magnifier

Windows key & "-" -- shrink back down

Control-Alt "i" -- inverse video your whole world

posted by brianbec

Option<T> can be thought as nullable over any "kind" of type (ref or val)

posted by AdamSpeight2008

const int range = 1280;
var kvps = Enumerable
    .Range(0, range)
    .Select(i => new KeyValuePair<int, string>(i, Convert.ToChar(i).ToString()))
    ;

dict = kvps.Aggregate(dict, (d, kvp) => d.AddUnconditionally(kvp));

posted by brianbec

posted by brianbec

posted by Martin

http://fsviterbi.codeplex.com

See F# source here: http://fsviterbi.codeplex.com/SourceControl/changeset/view/64363#1117175

Test script: http://fsviterbi.codeplex.com/SourceControl/changeset/view/64363#1117178

Some differences:

Actual code (excluding comments) is slighly shorter due to F#'s better type inference and buit-in tuple support.

Path copying is avoided due to 'structural sharing' of F# collections (list in this case)

The double loop calculation is parallelized using TPL wapper "PSeq"  but can be easily serialized. This could be useful for very large state sets on multi-core machines.

posted by fwaris

But how about using ReSharper with C#?

posted by Thorium

All - That said, it shouldn't deter anyone from using monads in general or the Maybe implementation.  My team is using it in performance critical production code with no problems.  It entirely depends on your use case.  If you interacting with web services, databases, or other IO, using monads is most likely not going to have a detrimental impact.  However, if you doing computationally intensive work, my suggestion is you profile your code to see where it is spending CPU cycles.  You may, or may not, find that usage of monads isn't the biggest bottleneck.

posted by jordanterrell

And 100% agree that the provability and reliability of monadic functional code is worth it in many (most?) circumstances.  On the perf critical path, profile and compromise as needed, focusing on implementation innards.

posted by brianbec

Anyone taking up my invitation to try a spelling corrector with this?

posted by brianbec

-Josh

posted by Jsoh

posted by PCB

posted by brianbec

posted by Jan de Vaan

posted by brianbec

I also found out it's possible to go generic on numeric types in F# IFF the methods are INLINED. That's because the compiler just "pastes" the inlined code after resolving the generic type, and then the normal method lookup finds the appropriate operator implementations. Not sure if this approach is available in C#.

posted by brianbec

-Josh

posted by Jsoh

http://blog.afterthedeadline.com/2010/07/20/after-the-deadline-bigram-corpus-our-gift-to-you/ 

posted by brianbec

posted by Richard.Hein

posted by CbrAInK

posted by builder66

posted by brianbec

posted by conard

//using alias directive for P: using P = Double;
static IObservable<IDictionary<S, Tuple<P, S>>> ViterbiRx<O, S>
(IObservable<Tuple<O, IEnumerable<S>>> obsStates, Func<S, P> startingProb, Func<S, S, P> transitionProb, Func<S, O, P> emissionProb)
{
    return obsStates.Scan((IDictionary<S, Tuple<P, S>>)null, (v, o) => o.Item2.ToDictionary(target => target, target =>
        v == null ? Tuple.Create(startingProb(target) * emissionProb(target, o.Item1), target)
        : v.Select(source => Tuple.Create(source.Value.Item1 * transitionProb(source.Key, target) * emissionProb(target, o.Item1), source.Key)).Max()));
}

posted by SteffenZeidler

posted by Suspended thread

posted by Richard.Hein

Hi, Steffen -- I was after something a little deeper, such as a user-defined numerical class (sketching, now), say logarithmic doubles, in which operator * is mapped to arithmetic + on doubles.  I couldn't find a way to make Viterbi generic over both user-supplied classes with operator overloads AND over built-in types, where operators are not the same kind of thing as operator overloads.  I could wrapper all the built-in types with operator * that maps to * etc., but that's  a lot of work.  That's essentially implementing my own "Numeric Tower" over the CLR basic types, and it didn't seem worth it to me to get a corner case like logarithmic double.  Maybe there *is* a way, I just couldn't find it.  Now I'm going to look at Richard.Hein's link

Edit: just an aside about why logarithmic doubles might be valuable: multiplying a bunch of small probabilities over and over eventually underflows doubles.  Bad.  Sometimes better to add logarithms of probabilities to get the log of the product of the probabilities. 

posted by brianbec

static IObservable<IDictionary<S, Tuple<P, S>>> ViterbiRx<O, S, P>
(IObservable<Tuple<O, IEnumerable<S>>> obsStates, Func<S, P> startingProb, Func<S, S, P> transitionProb, Func<S, O, P> emissionProb, Func<P, P, P> mul)
{
    return obsStates.Scan((IDictionary<S, Tuple<P, S>>)null, (v, o) => o.Item2.ToDictionary(target => target, target =>
        v == null ? Tuple.Create(mul(startingProb(target), emissionProb(target, o.Item1)), target)
        : v.Select(source => Tuple.Create(mul(mul(source.Value.Item1, transitionProb(source.Key, target)), emissionProb(target, o.Item1)), source.Key)).Max()));
}

Test:

var obsResults = ViterbiRx<string,string,double>(mul: (x1, x2) => x1 * x2, ...);
var res = obsResults.ToListObservable();
Debug.Assert(Math.Round(res.Value[Rainy].Item1, 6) == 0.013440);
Debug.Assert(Math.Round(res.Value[Sunny].Item1, 6) == 0.002592);
Debug.Assert(res.Value.OrderBy(x => x.Value).Last().Key == Rainy);
Debug.Assert(res[2][Rainy].Item2 == Rainy);
Debug.Assert(res[1][Rainy].Item2 == Sunny);

posted by SteffenZeidler