It's pretty straightforward to do basic benchmarking of a single, self-contained piece of code in .NET. You just make a Stopwatch sandwich (
let sw = Stopwatch.StartNew(); <code goes here>; sw.Stop()), then read off the elapsed time from the Stopwatch.
What about measuring the throughput of a data pipeline? In this case one is less interested in timing a single block of code from start to finish, and more interested in bulk metrics like computations/sec or milliseconds/item. Oftentimes such pipelines are persistent or very long-running, so a useful benchmark would not be a one-time measurement, but rather something that samples repeatedly.
Furthermore, it's sometimes difficult to determine where the bottleneck in a chain of computations lies. Is the root data source the culprit? Or is it perhaps an intermediate transformation that's slow, or even the final consumer? Continue reading Benchmarking IEnumerables in F# - Seq.timed
I've recently had reason to do a bit of work with JNI . Throughout the course of this work I had to do quite a lot of Googling in order to figure out how to properly manage the caching of various JNI objects used by my C++ code. Some JNI objects can be safely cached and re-used at any point, while others have limited lifetimes and require special handling. Obtaining JNI objects through JNI APIs is, broadly speaking, fairly expensive, so it's smart to persist those objects which will be re-used in multiple places. You just need to be careful.
I expected to find a big table somewhere that documented the lifetime restrictions (or lack thereof) for each of the JNI object types, but sadly I was unable to locate one. Instead, I wound up trawling through numerous Stack Overflow replies, blogs, forums, and other documentation to obtain this information.
This post is my effort to provide to others the missing quick reference I wish I'd found. I recommend this Android documentation as further reading if you want more details. Continue reading JNI object lifetimes - quick reference
Pentago is a favorite board game of mine, which I used to play regularly with coworkers during lunch (and occasionally during not-lunch). The rules are very simple, and casual games can be played in just a few minutes, but it's deep enough to still be satisfying if you're willing to put some thought into your strategy.
In 2009 I wrote a computer player for Pentago in C#, and even managed to cobble together Silverlight and Windows Phone UIs for it that aren't terrible. The engine uses a negamax algorithm with alpha-beta pruning.
Continue reading Pentago
The near-complete obviation of nulls is perhaps the most frequently- (and hilariously-) cited benefit of working in F#, as compared to C#. Nulls certainly still exist in F#, but as a practical matter it really is quite rare that they need to be considered explicitly within an all-F# codebase.
It turns out this cuts both ways. On those infrequent occasions where one does need to check for nulls, F# actually makes it surprisingly difficult to do so safely and efficiently.
In this post I've tried to aggregate some best practices and pitfalls, in the form of DOs and DON'Ts, for F# null-checking.
Continue reading Null-checking considerations in F# - it's harder than you think
Working on the command line with Powershell, much of the time I have the luxury of dealing directly with rich .NET objects. If I need to sort, filter, or otherwise process cmdlet output, I have easy access to typed properties and methods right at the prompt.
Often, though, I'll need to wrangle plain text, perhaps from a log file or the output of an executable. In these cases an intermediate step is required in order to extract the typed information (timestamps, substrings, numerical fields, etc) from the plain strings.
This comes up often enough that I whipped up a handy Powershell filter, 'ro' (for 'regex object'), to make it easy:
Continue reading A handy Powershell filter for converting plain text to objects
5 years ago today, I sent the following bug report to the Powershell team.
From: Lincoln Atkinson
Sent: Thursday, April 01, 2010 10:33 PM
To: PowerShell Discussions
Subject: Problem with get-date
Hey experts, maybe you can help me with this issue.
Get-Date seems totally broken for me. I've tried it multiple times with all different parameters, but it's just not working in my environment. I'm still single and I haven't gotten a date in months :-(
Get-Help really wasn't useful this time. Funny, since many of the ladies I wanted to Get-Date with specifically suggested I “get-help.” A few told me to try “get-life” and “get-bent,” as well, but I couldn't find those cmdlets. They must be running some V3 beta.
I've debugged this a bit, and have eliminated some possibilities:
Localization – I live in Seattle, seems there should be a pretty good social scene there.
Build – I'm average height/weight, don't see this as holding me back.
Concurrency – In our modern era of tolerance I'd like to think this isn't a race condition.
Hardware – Not the issue.
Low Resources – Get-Job worked ok for me so I have at least a little money saved.
Any thoughts? I just want to allocate some memories with someone and maybe attend a few advanced functions.
The report was forwarded to the Powershell MVPs, who weighed in with reasoned opinions and sage advice.
Tibor Soós -- And if there is a parent object, he should also use the –confirm switch.
Hal Rottenberg -- I do NOT recommend concurrent job scenarios with this cmdlet. I have heard of it being done, but it never ends well.
Hal Rottenberg -- I just hope he didn't try the Force parameter. That one has some illegal page fault regression bugs in v2.
Susan Bradley -- Not to mention you really want to run with antivirus or have some protection in this scenario.
Oisín Grehan -- His deduction on localization might be flawed: Get-Date typically only works at places where Get-Culture returns a non-null value. [ouch!]
Tobias Weltner -- You also want to make sure not to use the undocumented –recurse switch which leads to unexpected results.
[All code from this post available as a GitHub gist here]
For Christmas this year, I got myself a fun mathematical gift: a set of 10 non-transitive dice, namely Grime Dice! You can get your own set here. Behold their dicey splendor:
These dice possess the fascinating property that their winning relationships (in the sense of "winning" = "rolls a higher number > 50% of the time") are non-transitive. i.e. if die A wins against die B, and die B wins against die C, it actually does *not* hold, in general, that die A wins against die C. In fact, die C might win against die A! Continue reading Non-transitive Grime Dice, via Mathematica
By now, most everyone is aware of Pi Day, celebrating the famous mathematical constant on 3/14. On this day each year, students and math enthusiasts eat pie and engage in light-hearted -related activities. Then there is e Day, a day for commemorating the equally-important-if-somewhat-less-famous constant on 2/7. The activities are similar, though it's less clear-cut what food one should eat (a high school teacher of mine insisted that the proper e Day food is waffles, evocative of the Cartesian coordinate system). Even events like Pi Approximation Day (22/7 in day/month format), and Mole Day (6:02 10/23) have gained enough momentum to warrant dedicated results from both Google and Bing.
So when is Phi Day? Continue reading Today is Phi Day -- at least, it ought to be
This post is the December 26th entry in the 2014 English F# Blog Advent Calendar. Check out the other great posts from earlier in the month, or head over to the Japanese-language edition!
Ho ho ho! It's the day after Christmas, and hopefully everyone has some snazzy new toys to play with. But just in case Santa left you a lump of coal ("... little Billy used mutable state this year ..."), don't pout, don't cry, I've got you covered. My gift for all the naughty F# developers out there: a mini-framework for imperative-style looping in F#, adding the functionality of "break," "continue," and "return," along with the ability to nest loops down to programmatic depth. Continue reading Nested looping to programmatic depth in F#
Continuing the recent theme of awesome .NET development news, a blog post from Thursday by the .NET team provided more details on the platform's future, ".NET Core."
The ensuing comment thread on Hacker News had some nice F# discussion. One commenter, though, was not a huge fan, and in particular lamented perceived limitations in the F# units of measure feature: Continue reading Extending a 3rd-party API with F# units of measure