Friday, 27 August 2010

NAG at Quant Congress, New York

Last month I was in New York with my sales colleagues Mike Modica and Rick Guido from NAG's US office, attending Quant Congress USA. This is a meeting which is devoted to the latest developments in financial derivatives, risk management and the associated use of numerical techniques; NAG has been associated with it for the past five years because our software has found extensive use in the quantitative analysis community. Each day of the conference program opened with a plenary session of two presentations, followed by around twenty talks divided across two streams. The meeting had nearly a hundred attendees, not all of whom attended both days (perhaps it's worth noting that, whilst the technical program undoubtedly had its own attractions and merits, the attendance might have been enhanced still further by the fact that the two days of the meeting saw heavy rain fall on the city - in the middle of an otherwise-sweltering week). NAG was one of five exhibitors at the meeting, and we found that the relatively small size of the event meant that everyone who wanted to view our stand - almost exclusively during the breaks from the talks - was able to.

We were kept busy by a steady stream of stand visitors throughout the event, which made for an interesting couple of days. Most of the queries and comments we received were focussed on technical queries about the functionality of the NAG libraries, with a particular interest, of course, in those routines which have proved valuable in the finance industry. There was also a lot of interest in the work that NAG has been doing on numerical routines for GPUs, partly because of the speedup that has been observed by customers when running Monte Carlo simulations on GPUs - as compared to running on a single CPU - using NAG routines (see this post for more details).

We also had a lot of questions about the NAG Toolbox for MATLAB®, while some users - or prospective users - were interested in being able to call NAG routines from within Python. I had an interesting discussion on this latter topic with Professor Dennis Allison (who is famous for, amongst other things, being one of the founders of Dr Dobb's Journal). I found that providing answers to a few of the most technical queries about numerics in quantitative finance was somewhat beyond my abilities, notwithstanding the recent education I'd received in some aspects of this field from my colleague Marcin Krzysztofik (and our collaborations involving the NAG option pricing routines), but we were able to deal with all outstanding issues by email within a few days of the conference's end.

Whilst in New York, we also made a series of site visits, mainly in the financial sector. During one of these, I was told by the customer that they thought the technical support which they received from NAG was excellent - in fact, they said it was often better than what they received from their own in-house team. Since the support service is one of the things that NAG prides itself on (and which the customer pays for), this was good to hear, particularly as I felt it made up for some less gratifying - but still memorable - experiences I'd had earlier in the trip. These included celebrating my arrival in the city by falling off a barstool - apparently without any provocation at all (apart from the fact that the barroom singer was playing a cover of Tom Petty's "Free Fallin'" at the time). Any damage that my self-esteem may have suffered was, however, assuaged by the (re)discovery of this bar. Always nice to be where everybody knows your name, I think.

Thursday, 26 August 2010

Why quality has always been essential for NAG’s own internal process (and a holiday).

Quality is one of the things that matters a lot to our users.

That is certainly true, but another reality is that the NAG Library could not exist at all without the checks and tests that result in the best quality software. The NAG Library is particularly complex and involves many different people doing very different types of task and activities. The Library is created from intricate actions including:

- Investigating lots of numerical problems and potential approaches and solutions
- Designing hundreds of methods for the various chapters
- Producing example code, data and plots
- Creating installer and user notes
- Writing the detailed documentation and descriptions of routines
- Building the multiple different processor and compiler implementations of the Library
- etc…

The best approach to quality is essential, in making the NAG Library, precisely because it is this multifaceted combination of numerical mathematics, software engineering and evolved process. If it were not for the quality checks, at all points through the product organization, it would be impossible to get all the bits to mesh and work together.
NAG learnt this fact many, many years ago!

NAG quality methods are continuously scrutinised because of this internal need, as much as for users. Levels of peer review of documentation are increased, as new expert knowledge come to the fore. The frequency of automated implementation testing carried out during the development process is escalated, as the availability of test platforms increases. And so on.

The results are self-evident. The quality and reliability of the Library never falters, even as new content is added and further software environments are supported. The NAG quality process benefits all parties.
On a much lighter note I’ve just returned from our family holiday. I, my wife and our three young children flew to Athens, stayed for 3 days to revise the history, and then moved, about 100 nautical miles by ferry, to an island to explore and relax on beautiful beaches...

…in summary the vacation was made up of different sections, and was enjoyed by all five of us, because of the quality and detail that went into the planning and booking. Perhaps it was also made easier since we are all hardened travellers.

This leaves me with a question, both for people and organisations
– ‘Can we all manage just as well with a top quality process but only limited experience?’

I’d be interested to hear your view…

Friday, 20 August 2010

What's in a Name?

Newcomers to NAG often ask about the names of NAG routines. Certainly the names appear strange and unfamiliar at first, but to many NAG users the name encapsulates the heritage of quality and precision offered by NAG.

Originally the NAG Libraries were created by contributors from U.K. academia. Some of these wrote in Algol 60 and others in Fortran. It was agreed to have two libraries of identical content, so that every contribution in one language had a counterpart in the other. Thus both communities were appeased. Early printed documentation included both language versions.

It was clearly desirable to be able to distinguish one language version of an algorithm from the same algorithm implemented in the alternate language and in general this is still desirable if a single program needs to call both instances of the algorithm.

Equally the early developers saw that, as new algorithms were developed, replacement routines would be required with perhaps different calling sequences, so that any naming scheme chosen needed to accommodate the ongoing development of the libraries. Another desirable feature would be to naturally group by name routines that lay in the same field of numerical computation.

With these goals in mind the founders of NAG considered two lines of approach.

The first idea looked at the concept of 'meaningful' names, names which might convey the algorithm being used or the problem addressed. Even today this is difficult, but in the early 1970s standard Fortran did not permit more than 6 characters for any routine name. And NAG certainly did not want to have Fortran and Algol names so radically different from each other that the algorithmic connection was obscured. The problem of updating also needed to be solved.

The alternative looked much more appealing. At that time a modified SHARE classification system had been published and NAG decided to base its routine names on that. This gave rise to the names we now see. Each name is 6 characters long, the final letter denoting the language of implementation. In those days 'F' denoted Fortran and 'A' denoted Algol 60. Subsequently this would be extended as NAG produced both single and double precision libraries in Fortran and as NAG produced other language versions such as C. The first characters, generally the first 3, indicated the broad subject ( or chapter) area to which the algorithm belonged. (Characters in positions 2 and 3 are always digits.) Thus E04WDF is a routine in the FORTRAN Library that lies in the E04 chapter. This chapter deals with 'Minimizing or Maximizing a Function'. The letters 'WD' uniquely identify the algorithm.

Of course modern Fortran no longer has a restriction of only 6 characters for routine names and so it is perhaps worthwhile to consider whether the NAG naming scheme can usefully take advantage of this relaxation.

The debate rages within NAG. Certainly the old problems remain if we wish to have 'meaningful' names, since routines will change with time. Do we describe the problem to be tackled or the algorithm used? If the former then NAG may wish to offer several techniques. In the C06 chapter we offer both Weeks' and Crump's method for Inverse Laplace transforms for example. Problem addressed is evidently not enough to uniquely identify an algorithm. Description of the routine by algorithm alone falls down heavily in the optimisation chapter where 'Sequential Quadratic Programming' and 'Quasi-Newton' and 'Modified-Newton' account for the vast majority of routines. We are thus led towards a combination of the two.

Looking in detail at the effect of combining problem and method into a meaningful name we rapidly encounter the very powerful and flexible routines of the NAG optimisation chapter. Here one routine often addresses several related, but different, problems and has both sparse and dense counterparts. Long names might indeed become very long if they are to convey any useful meaning and not deceive.

We see an early attempt by NAG to provide long, meaningful, names in its C Library. Users will be familiar with nag_opt_lin_lsq to denote the C routine e04ncc. This routine also solves convex qp problems, something the reader would not deduce from this name, yet this is probably its most important role.

Proponents of meaningful long names argue that the solution to this is to have separate routines with only a single purpose. Their opponents argue that it is easy for users to effectively choose their own names for routines, given the variety of options open to them: pre-processors, wrappers and aliasing for example.

What do you think? How many characters in a long name would you tolerate and how would you name NAG routines?

Wednesday, 18 August 2010

A day in the life of...

... a Numerical Analyst:

Wow, this could be fairly boring, but here goes...

I arrive at my desk, slightly dishevelled from my daily cycle to work, whip my laptop out of the draw and unhibernate my old faithful friend. He and I have had some ups and downs over the past year but I am happy to say that we are still on good terms.

Having gone through the usual email checking routine, I ssh (remotely logon) onto one of the local linux work servers, to pick up from where I finished the day before.

And then it's on to slogging at the current routine, improving it's accuracy or speed, checking it works properly, documenting the code, screaming (under my breath) in frustration at the latest problem, or quickly writing a blog post to give my mind a break from the overflows and NaN's (think they are grandmas? Think again) of the numererical analyst's life.

But it's not all slog. One of the highlights for me, is in the cracking of problems. The simple answers, and the not so simple answers that when found, bring a smile of victory to the lips. Another highlight is in automating repetetive tasks, and creating/finding useful tools to speed up the work cycle. As I read in a magazine a while back, that if you do something a few times, it's worth making a quick tool to do the job for you.

At the end of the day, it's back home to my lovely wife, and to feed and bath my young son, only a Numerical Analyst in the back of my mind.