Posts

Showing posts from March, 2010

My early career at NAG…

“Don’t worry you’ve done a mathematics and finance degree and have an engineering masters and you’ve programmed in Pascal and can write VB macros you’ll be just fine.”

“You’ve far more technical experience than any previous sales persons (the last manager used to sell used cars!). If you’re not careful you’ll end up in the technical division.”

Well with such resounding support and confidence from my manager how could I fail? Buoyed by a good track record at previous companies I now felt less daunted by this technology shift… industrial and electronic weighing scales to telecoms to numerical software… what could be more natural?

Thinking about my days selling weighing scales, I can recall a previous manager, John Ruskin Utley’s wise words (that isn’t quite his real name, in fact I suspect his middle name didn’t even begin with R).

“Listen to your customers, listen to your distributors/resellers and ensure those in technical development get the market feedback. Rest assured laddy i…

What’s the next revolution in technical computing?

It’s a question that absorbs the attention of the technical computing community, especially those working at the leading edge of technology and performance (high performance computing, HPC). What is the next disruptive technology? In other words, what is the next technology that will replace a currently dominant technology? Usually a disruptive technology presents a step-change in performance, cost or ease-of use (or a combination of these) compared to the established technology. The new technology may or may not be disruptive in the sense of discontinuous change in user experience.

Why is identifying disruptive technology so important? First, those who spot the right change early enough and deploy it effectively can attain a significant advantage over competitors as a result of a substantial improvement in technical computing capability or reduction in cost. Second, identifying the right technology change in time can help ensure that future investments (whether software engineering, …

Extending, imitating and collaborating

Image
As the name suggests, NAG is most widely-known for its library of numerical algorithms - in fact, it's been around for nearly forty years. Back when the first version was written, the coding language of choice was Fortran and, although it's still widely-used (particularly in high-performance computing), most developers today are working in a myriad of other languages and packages. Accordingly, we've put a lot of work into making the routines from our libraries accessible from these environments, in order to (hopefully) extend the areas in which our algorithms can be used by programmers when building their applications.I was reminded of this extension into other environments recently when I saw a demo written by my colleague Marcin Krzysztofik. Marcin's background is in financial computation, and his application nicely demonstrated some of the models that have been developed for calculating the prices of financial options. New routines for evaluating the results fro…

Using the NAG Library for .NET from F#

NAG is currently running a beta test of a NAG Library for .NET. One noticeable feature of the comments received so far is the relatively large number of users interfacing to the library from F# rather than C# or VB.NET.F# is a functional programming language derived from OCAML, which in turn has a shared ancestry with the Standard ML programming language that I used over 20 years ago while working on theorem proving systems at Manchester university…The .NET area of the NAG website has been updated with a discussion article and example programs showing how to write console applications and windows form applications from F#.Using small wrappers one may provide functional interfaces to the NAG library that work well with the interactive loop of the F# interpreter, allowing calls to the NAG library with essentially no syntactic overhead. The following is a complete F# expression (integrating the sin function between 0 and pi) with the results being echoed back by the F# top level, using a…

What makes a good software developer?

In NAG's development division we hire a variety of people from a variety of backgrounds - in fact we have a very diverse community of technical staff. At the time we hire them, of course usually we have a role in mind for them, whether it's someone with a specialism that enables them to work on a particular piece of software, or someone we want as an "all-rounder" who needs to make software work on lots of different hardware. However, it's not always clear what direction their talents will ultimately take them, and when we're interviewing we can't always tell what virtues a person has. It would be nice if we could know in advance, but usually we just can't. I got to thinking - what are the attributes of a good software developer? I came up with the following list. A logical mindImpatiencePatienceCuriosityAbility to transfer knowledgeKnowing when to let goKnowing the right people Number 1 seems obvious. You can't write software without using l…

Calling the NAG Fortran Library from Freemat

Image
We like to make our libraries easily accessible from other languages and environments other than Fortran and C, for example Excel in VB or Matlab through our toolbox. It allows users to quickly and simply access Library functionality without the hassle of making and compiling a C or Fortran program. Environments like Matlab or Octave are particularly interesting as we can combine their strong codebase and powerful visualisation tools with our libraries (we provide technical reports on how to use the NAG Libraries from Scilab and Octave). A Few days ago, I discovered Freemat, which is another prototyping tool inspired by Matlab and IDL. As Octave or SciLab, Freemat is an open source program which supports Matlab scripting, Mex interfaces and more. But the particularly interesting feature it has is their import function. It allows users to dynamically load a shared library into Freemat and use it directly, without having to write interface script or C code (as in Matlab, Scilab or Octa…

Beta testing and feedback

It is easy to see the value of software Beta releases – they provide the opportunity for potential users to get new functions early and they give the development team excellent feedback about what needs to be altered to advance from a potentially good product to an excellent product that meets users’ needs precisely. However, perhaps like many aspects of life, the way to gather most benefit from a Beta program is to listen really hard to what Beta users are saying. This can be time consuming and quite difficult. The current Beta program that we are running is for the NAG Library for .NET. We have received excellent, detailed feedback that covers issues from logging exceptions from Excel to looking at how to further tune some routines for particular environments (all things that the NAG developers can cover). While this is great, and let me take a moment to thank those in the Beta program for their feedback so far, the question remains: are we listening hard enough? So, for the…