F#
-
A question came up recently in an internal discussion and I thought I'd share it as it proved so illuminating. If I have an object of a type which implements IDisposable, is it good practice to explicitly dispose it (whether via the using statement or calling Dispose() explicitly)? The quick(ish) answer is: Yes it is, but sometimes you might choose not to as the increase in code simplicity outweighs the benefits derived from manually disposing of the objects. So, naturally, the devil is in the detail. Let's take a look at the three scenarios where you're likely to be working…
-
In this earlier post we saw some C# code that creates 2D, 3D or "live" section geometry in AutoCAD 2007 or higher. I mentioned at the end of the post that I was curious to see how equivalent F# code compared with this C# source, especially in the area of array concatenation. Well, it turns out that there's still a little pain, just different pain (more like a sharp pain that's over quickly, rather than a dull, nagging ache :-). Here's the F# code: #light module SolidSection // Import managed assemblies #I @"C:\Program Files\Autodesk\AutoCAD 2009" #r "acdbmgd.dll" #r "acmgd.dll" open…
-
Some of you may remember my interest in fractals from these two previous posts. Well, while researching a problem in F# (related to the conversion of the last post's code to F#), I stumbled across this post from Luke Hoban, which contains some neat, recursive F# code to generate the Mandelbrot set, sending the result to the console as ASCII text. I couldn't resist modifying the code to generate Solids (filled shapes with 3 or 4 sides, as opposed to Solid3d objects) inside AutoCAD. Here's the F# code: #light module Mandelbrot #I @"C:\Program Files\Autodesk\AutoCAD 2009" #r "acdbmgd.dll" #r "acmgd.dll" #nowarn…
-
Back from a nice long weekend, although I spent most of it sick with a cold. I find this increasingly the way with me: I fend off illness for months at a time (probably through stress, truth be told) but then I get a few days off and wham. A shame, as we had a huge dump of snow over the weekend... we get white Christmases here every five years or so, but it's really uncommon to get a white Easter. I had a very interesting question come in by email from 冷血儿, who wanted to get the technique shown…
-
Someone asked me recently how I categorize different programming paradigms. I thought it was a very interesting question, so here's what I responded. Please bear in mind that this is very much the way I see things, and is neither an exhaustive nor a formally-ratified taxonomy. One way to look at languages is whether they're declarative or imperative: Declarative programming languages map the way things are by building up "truths": this category includes functional programming languages (such as Miranda, Haskell and Erlang) which tend to be mathematical in nature (you define equations) and start with lambda calculus as a foundation.…
-
To start off my series of more in-depth looks at the new APIs provided in AutoCAD 2009, I decided to extend some recently posted F# code to generate and draw transient point clouds to be slightly less transient: we'll see how to use the new transient graphics API in AutoCAD to display a cache of transient graphics, even after the view has been changed. Some of you may be wondering about the amount of code I'm posting in F#. I find the technology extremely interesting and am also increasingly productive with it, so I've found myself gravitating towards using it…
-
At the beginning of the week, we looked at some iterative F# code to generate random point clouds inside AutoCAD. We then took the time to use Reflector to dig under the hood and understand why the previous recursive implementation was causing stack problems. For completeness (and - I admit it - being driven slightly by laziness, as this is a quick post to crank out 🙂 here's the recursive version of the random point cloud generation code in F#: // Use lightweight F# syntax #light // Declare a specific namespace and module name module MyNamespaceRecursive.MyApplication // Import managed assemblies…
-
I've talked about Lutz Roeder's Reflector tool a couple of times and it's proven to be very useful to me, once again. I mentioned in my last post about some problems I was having with tail recursion, and my choice to replace certain recursive functions with iterative versions. Today we're going to use Reflector to take a look under the hood of some compiled assemblies, to determine which recursive functions have been optimised correctly and which have not. Let's start by taking a look at the two recursive functions I mentioned last time, starting with the most simple: // A…
-
On my way back from the US last week, I started thinking more about uses for random numbers inside AutoCAD: especially ones that allow me to try out some possible application areas for F#. There's something deliciously perverse about using random numbers in Engineering systems, where it's really important for outcomes to be deterministic (i.e. predictable) & precise. And that perversity appeals to me quite strongly, for some reason. Feel free to drop me a mail if you have an idea why that might be, any amateur psychologists out there... 😉 So, I got to thinking... an interesting domain area…
-
In the last post we saw some code combining F# with C# to create a random "hatch" - a polyline path that bounces around within a boundary. This post extends the code to make use of Asynchronous Workflows in F# to parallelize the testing of points along a segment. In the initial design of the application I decided to test 10 points along each segment, to see whether it remained entirely within our boundary: the idea being that this granularity makes it very likely the segment will fail the test, should it happen to leave the boundary at any point.…