Dragon4 and Grisu3: algorithms to display floating point numbers

November 13, 2012 Gary Kennedy — 2 Comments

Fractal_dragon_curveI recently encountered a reference to algorithms called Dragon4 and Grisu3; curious as to what they were I read an enlightening blog “Here be dragons: advances in problems you didn’t even know you had”. I was quite astonished that the display of floating point numbers was even a difficult problem and that there was a significant advance on the topic relatively recently.

The recent advance is the article “Printing floating-point numbers quickly and accurately with integers” by Florian Loitsch (2010), and is worth reading, if only to get a flavour of the problem and the history of attempted solutions.

  • MattF

    Enjoying the blog! I’ve always been uneasy about the mismatch between finance-friendly numbers which need to be communicated between entities and the floating point numbers used in numerical calculations. The former are invariably integers or decimals specified to a fixed number of places so they can be compared exactly with reference data. However the floating point numbers in calculations are usually approximations which opens the door for all the silly failures of tests for equality or less than when two essentially equal floating point numbers end up microscopically different due to their derivation.

    One solution is to have a very clear separation of data types. You thus remove the need for ever printing a floating point number as the data is converted as it passes in and out of your numeric calculator. A value representing a barrier strike for example might not be precisely representable in the floating point world so might be transformed into an interval [largest float less than strike, smallest float greater than strike] or some other representation involving an epsilon. This is in turn means standard algorithms need to be tweaked but hopefully in a well-defined and easily identifiable way.

    • http://www.clarusft.com/ Gary Kennedy

      Glad you are enjoying the blog. Certainly the separation of data types solves many of the naive mistakes one tends to encounter. The one case that bothers me slightly is the calculation of known coupon flows, say on a swap. For pricing and risk, floating point numbers are fine, however if you are actually delivering a cashflow to someone’s account, then a conversion from floating point to decimal has to occur, assuming intermediate calculations are being done with floating point numbers. Often I have seen very clear guidance on rounding conventions in deal confirmations, but I don’t think I have ever noticed specification of the algorithm to convert floating point to decimal and yet it has to occur. I suppose the assumption is that Excel would be used to check such calculations, so it’s conversion routine is almost the definition.