I already mentioned the lack of file open icon, and previously I have talked about the ridiculous blob. And the initial flashing they had to incorporate to tell us its a button. But when you actually get closer it just gets sillier – I really wouldn’t have thought that was possible!

When you click and look, if you decide to cancel and move to the traditional cancel location (lower right) and click that button, does it close the file open dialog/ribbon? Or does it close Excel?

Everyone I have asked (and me) has accidentally closed Excel numerous times before eventually learning that this particular piece of the interface is not ‘normal’. In fact to cancel that thing you click anywhere else in Excel – and Excel ignores the click but closes the dialog! How ridiculous is that?

They have created a thing that is not as powerful or controllable as a dialog, but is too big and intrusive to be a menu or toolbar so they butchered an existing UI concept – the click away to cancel menu concept to work with this quasi dialog. But dialogs never worked like that before or in other applications. So now Office is the most friction-full application in the widows world (excluding perhaps Ulead products).

So, does the Office button bring up a (poor) dialog, or is it just a menu?

Sorry Simon but I have to disagree with you on this one (I seem to recall being told I was the voice of balance on smurfonspreadsheets by someone…).

Just because you think it’s a dialogue and call it a dialogue does not mean it is a dialog or should behave like one. Shredding a straw man / ribbon does not make a valid argument. To me it looks and behaves pretty much like I would expect a menu to behave:

• It appears from a button above it, and remains in that fixed position (unlike normal dialog which are windows which can be moved about).
• It has items which when hovered over reveal sub-menus of related items. The ones which do this are correctly indicated with a small arrow to the right.
• Since it is not a dialogue, it has no "X" close button in the window title bar because it does not have a title bar. (as an aside, I would wager this is just as popular a method of closing an unwanted dialogue as going for the Cancel button)

Why would I expect a Cancel button on a menu anyway?

Well, I wouldn’t. But even if I did, I would look for it specifically – the cancel button is not always in the bottom right of a dialog (nor always there at all). However, I do find that the Cancel button is usually the one labelled "Cancel" rather than the one labelled "Print" or "Exit Excel". This principle has stood me in good stead with most applications.

Anyone familiar with the old file menu and expecting things to be the same or similar in the new version would not be at all surprised to find that the option to exit the application was the last one in this list, I would have thought.

Fair enough, it’s not a regular, old style menu

A couple of ways this does not behave like a regular menu in the traditional standard interface design we have all come to love (or at least get very very used to):

• The “recent documents” list appears in the right hand half when the left hand menu does not require a submenu, rather than extending the menu to ridiculous lengths (especially if you crank up the setting to show the maximum of 50). Unusual? Non-(old)-standard? Sure, but you have to admit it’s useful, makes good sense and requires less mouse travel. And who does not love the ability to pin documents to the recent list by the way?
• yes, some of the menu items (such as Save As) have something like that weird dual-purpose behaviour where you can click the button and you get something very like it used to be, or you can hover and move to the right for the submenu. But these are better than the similar behaviour of split buttons on the ribbon in a big way – you only have to hover to immediately discover the submenu, unlike the buttons where you have to click one half or the other to see what is going on.
  The only menu item where this actually makes any difference is Save As. You click the left half and the SaveAs dialog is presented with the current saved workbook format selected (or .xlsx for a new unsaved workbook or some other default if you have a group policy in force to keep people in compatibility mode for some reason). A click in the right brings up the same box with the chosen format selected. Big deal. (The Print menu has print as an option on the right too, and no discernible difference to me which you choose to click on, so although it has the dual-control thing there is no downside to the user if they don’t understand it).

For me the only behaviour which is odd enough (in that it is unexpected for a normal menu) to warrant special mention on my Excel 2007 or Office 2007 update training courses is that the menu items can be added to the QAT with a right click, thus proving that they are buttons, this is therefore a dialog not a menu and Simon was right after all! Well, up to a point…

Should File actions be mixed with application Options?

As for “Excel Options” (or Word, PowerPoint etc. options) being out of place in here when everything else is “file” stuff, the same could be said for Options being on the Tools menu historically when everything else there was to do with content (of a spreadsheet or document or whatever) – like spelling checker, track changes or Goal Seek. It was never intuitive in the first place, we just got so used to it over time that anything seems weird (like non-Qwerty keyboards). Other application authors had options (or preferences) on the file menu years ago (Jasc Paint Shop Pro being one example I know of) or put it somewhere else such as the Edit menu. I don’t use Acrobat reader anymore, but I’m pretty sure Adobe put the preferences on the edit menu, which actually sounds right when you want to edit your preferences for the application, but never felt right because I was not editing anything in the usual sense.

I find that people quickly grasp the idea that anything to do with the whole document or whole application is on the Office button. It’s (sort of) a separation of content editing tools (on the Ribbon) and meta-tools (on the Office button).

What about other “whole document” options like Page Setup?

Arguably, Page Setup could have been left there for most people’s purposes (and Print Area in Excel), but they make good sense on the Page Layout ribbon, especially since they can differ from sheet to sheet in Excel or section to section in Word (thus failing my “whole document” test).

I actually prefer the visibility of the options on the Ribbon, especially Scale to Fit – how many times have you wasted a trip to the Page Setup dialog only to find the “fit to 1 page” option you wanted was already set. Now you see it before you go there. And having a true “Automatic” setting rather than a kludge of putting in more pages than you ever expected to need, (which worked until some twit turned on borders for a huge cell range or even the whole sheet). Now I just want the current margins to be obvious, and ideally adjustable from the Ribbon rather than another dialog – “Last custom setting” that I used is not the same as what is current for this document. Especially since Page Setup is one of the few dialogs which is still modal so I have to click OK, find out if everything now fits and wraps where I want it and try again.

To me it would also have made some sense to include other “whole file” operations such as Protect Workbook and Share Workbook on the Office button menu in Excel (maybe in the Prepare sub-menu) as well as on the Review tab of the Ribbon, in order to provide more discoverability? I think it makes as much sense as the Restrict Permission options being there, making it really easy for users to discover that they can’t use this feature without jumping through hoops or having a clued-up IT department to sort out certificate goodies for them.

What would you like to see on the Office button menu? Or on the Ribbon in general?

Styles in Excel are one of those things that sound good in theory, but are significantly worse than useless in reality. In an isolated world they may work but as soon as you start copying a pasting between workbooks…then you get a right royal style mess.

Cell styles as a concept seem pretty weak to me. The built-in ones are hopeless; I know hardly anyone (actually no-one that I could name right now) that uses them.

I have recently done some extensive work for a client on a set of templates, themes, etc for the whole Office suite. For the Excel templates I included some cell styles to make it quick to format things in “corporate” colours for headings and so on (as well as default table styles for the same reason). This provides user convenience and helps them create more consistent documents with more of a “branded” feel to them.

As to imposing a regime of “pink means bad” and “orange double underline means linked” (linked to what?), no chance.

Why styles don’t address the real need for good formatting

I teach students on my Excel training courses that formatting of spreadsheets should be used for three purposes:

• to highlight (data outliers; estimates as opposed to actuals)
• to group or associate data together (months in the same quarter or year having a light shaded background say, next group no background; using matching colour for axes and lines in a two-series chart with two different scales)
• to separate data by category or type (line above the first month of a new year; making the title row bold)

These principles of using formats to help interpret the data, rather than help it look pretty tend to get people focussed on the task rather than the appearance. The built-in cell styles only seem to address the concept of highlighting, rather than being useful for grouping or separating. The highlighting they provide seems arbitrary at best, and quite likely to cause headaches with some of the colours involved.

They also apply too aggressively for my liking. For example, if I apply a format to a cell to show that it is an estimate, and someone else wants to style it to say it should be checked (or updated or whatever), my original formatting is irrecoverably lost. Resetting the cell style to “normal” simply applies this instead. By using precise formatting I could control this better – for example my estimates might be indicated by use of italics and a different font colour. I could then highlight this cell to be checked by adding a border or background fill, which can be separately removed later once done, leaving my original font format in place. Or I can change the format to represent an actual rather than estimate figure, but still leave the border to make sure it gets checked.

Cell styles are all-or-nothing, and that does not work for me.

Surely styles help people apply formatting more quickly?

Don’t get me wrong, I’m not for people formatting everything by hand, one property at a time. Paragraph styles are a great way to format Word documents (the only sensible way for a consistent approach to layout and formatting). How a document is structured and how it looks are closely tied together, and providing users with an easy way to show heading hierarchies, properly legal-numbered lists and so on is really valuable, and saves a ton of time versus bold, italic, indent-a-bit, font size 24 etc. Re-using the hierarchical structure this gives for things like table of contents or an outline make good sense too. Marketing departments typically like templates as a convenient way to give end users some built-in branding and good design, making it easier for everyone to create documents which look similar, and meet the guidelines they have chosen for colours, layouts, even choice of bullet points. I just can’t see how this sort of model translates to Excel.

Colour schemes do make sense to help “brand” Excel documents with corporate colours for headings and the like, and to make sure that visual elements such as charts or diagrams have a sensible and consistent palette (not necessarily in corporate colours, which may be too saturated or distinctive in many cases).

Cell styles don’t seem to meet any actual need that is not just as well addressed for the majority of users by the format painter tool, and learning to use it properly – I have lost count of the people I see on intermediate or advanced courses who have never double clicked this to lock it on and apply a format to multiple targets, whether in Excel, Word or PowerPoint

Workbooks that have lived for a while in 2003 and been reformatted over time seem to generate loads of horrid pointless cell styles when converted to 2007 (equally PowerPoint files create large numbers of colour schemes so that existing slides can retain their colours while still pretending to be theme-aware). Copying sheets between workbooks seems to compound this (although because I hardly even look at the styles gallery it is hard to know exactly how bad this gets). The style gallery quickly becomes useless, and as Simon highlights, it is tedious beyond belief to sort out. Some kind of proper style manager interface might redeem this. I tend to crack open the zip file and reach for Notepad++ for some XML-hacking – not what I would expect most users to do, or even many power users.

Styles gallery is a waste of space – literally

My biggest gripe with cell styles is that for a feature which is very rarely used it gets given a lot of space. Right now my ribbon is maxed out on my 1920×1200 widescreen. The Home ribbon is 47cm wide, and the styles gallery is showing 10 items in 5 columns taking up 15 cm – nearly a third of the ribbon. The same space could show various groups which many people might find more useful, any of these pairs would fit in the same space or less:

• names and formula auditing
• page setup and scale to fit
• changes (protection) and workbook views

I know some things have been made more prominent on the ribbon to get people to consider features they did not even know were there – conditional formatting and defined names being two of the most underused in my opinion, and I’m very glad to see them given a useful amount of space. But getting people to use cell styles simply won’t set the world on fire, or make spreadsheets more efficient, or easier to maintain, or less prone to user errors. If anything, they distract from good practice and promote eye-candy – will “death by PowerPoint” spread to “death by spreadsheet”?

What can you do to change many cells at once by a specific amount?

A few approaches spring to mind, depending on the scale of the problem and the structure of your data.

1 – Write a macro

You could create a macro to go to all the relevant cells and change them by the appropriate amount (multiply by 115/117.5 in our case). But you can’t change historical cells, and you shouldn’t change any values too far into the future (the new rate only applies for one year it seems). So for every worksheet of every workbook you need to make sure you only apply your wonder macro to the right cells.

Sounds like a lot of effort to me, and too open to risk of changing values you should not (and possibly without any audit trail), but the up-front investment of time might pay off if you had loads of identical sheets to run it on.

2 – Use temporary formulas and paste special (values)

Easy enough – in an unused column or row, create a formula to calculate the right values from the original data (eg =A1*115/117.5). Copy this down (or across) to build a new range of corrected data. Copy all these cells then use edit > paste special > values to paste this over the original data.

Not bad, but laborious, and if you have lots of separate ranges to do this could take a while.

3 – Use paste special on its own

About 90% of people I meet when doing training courses have only ever used Paste Special to copy values without the formats and formulas; it’s like the rest of the dialogue box is just a blur. This is even worse in Excel 2007′s ribbon, where you use the drop-down arrow under the Paste button and choose Paste Special Values directly without ever seeing the full range of options. I like that the frequently-used option is even quicker to find and use now, but wonder if some people won’t ever discover the rich set of options they could be using. This technique will utilise one of the lesser used options of paste special.

Find a single unused cell in your spreadsheet and put in the correction factor – a formula such as =115/117.5 would be great for our purposes (0.978723 to be precise). Now copy that cell (CTRL-C). While that selection is still copied (showing the “marching ants” border round it), select some of the cells you want to change and go to edit > paste special (or use the drop down under the Paste button in Excel 2007).

Now choose one of those options you usually ignore – multiply. Click OK and hey presto! The target cells are all multiplied by the source multiplicand. Even better – it is still selected as a copy source, so you can just go find your next range and select that and paste special > multiply again. And again, and switch to the next worksheet in your workbook and do it some more.

For the keyboard lovers out there, the easiest way to get to paste special is Alt then E, S, then M (for multiply) and Enter for the OK button. So, copy the source cell, select your target, Alt, E, S, M, Enter. This will still take a while, but I think it could turn out to be the most efficient in terms of actual clicks, and it is all undo-able one step (pasted range) at a time if you click on the wrong thing at any point.

Differences between versions

If you use this Paste Special > Multiply function (or similar ones such as divide, add etc) you should be aware that the different versions of Excel achieve this in slightly different ways. In all cases any formula in your target cells will be preserved, but numbers may get overwritten or not, depending on the source cells and your version of Excel.

In all versions that I have available to test*, if both source and target contain just numeric values (no formulas) then it calculates the result and pastes this straight in. In Excel 2007 if the destination you paste over had a formula in to start with it writes in a new formula to do the multiplication, using the value of the source cell, but it never creates a formula because the source cell had one, it always uses the resulting value from there.

Using Excel 2000 and 2003, if either the source or destination cells have a formula in then in it builds a formula in your target cell to do the calculation without asking. So if you use the formula =115/117.5 to get your multiplier, then this forces Excel 2000/2003 to create formulas in the target cells even if they only had plain numbers in them, which you may not want. You could be better off using the explicit value 0.978723 so that it will only create formulas if it needs to. Alternatively, select “values” as well as “multiply” to force it to use the result from the source cell, rather than the cell contents as a formula (so the key sequence becomes Alt, E, S, V, M, Enter).

*I don’t have Excel 2002 / XP, but I am pretty sure it will be identical to 2000 and 2003 since it comes between those versions

Warning!

OK, nothing is perfect. When you use this feature of paste special, blank cells are replaced with 0 (zero). Ticking the “skip blanks” option has no effect, it multiplies the implied zero by our number to give a zero result.

Why does this matter? Well, it might not matter if you select specific cell regions, but if you select whole rows or columns at a time, you will get all zeroes to the end / bottom which may not be ideal – it may try to print pages with these on, for example, if you have page layout settings such as “1 page wide x 20 pages tall”, and you were relying on the fact that it never prints past page 12 if everything below there is blank.

Similarly if the blank cells are part of a range which you calculate average values from, these cells will now be counted even though they do not contribute to the sum (so if you previously had 117.5, BLANK, 117.5, BLANK you would now have 115, 0, 115, 0. Your AVERAGE will have shifted from 117.5 (=sum of 235 divided by count of 2) to 57.5 (=sum of 230 divided by count of 4). Other functions such as SMALL, COUNT etc may be distorted by having lots of zeroes to include where previously there were blank cells to ignore. If you are not using such summary functions, or do not have blank cells in the regions you are changing, then there is no problem.

Formatting considerations

You are multiplying a number (our VAT fixing factor of 0.978723) with several decimal places by another number with probably a couple (if your values have pence / cents  / etc). The result will therefore have even more decimal places – anything up to eight, potentially (where you are multiplying 3 one millionths by some number of hundredths). If your cells are already formatting as “Number” with an explicit number of decimal places showing, that will be retained and everything will be fine. If the target cells are formatted as General (but just happen to have two decimal places on their values) your new result will have lots more.

So you will probably have to re-format your target cells either before or after the exercise of multiplying them out (leave the source cell showing its full decimal value). If you are happy to keep the underlying precision of the new calculated numbers, then I would suggest reformatting afterwards so you can see which ones you have done.

Whether your cells are already formatted to two decimals, or you do this afterwards, Excel will as always be storing the actual, detailed, tiny decimals underneath. This could be seen as more accurate, but can make sums appear to be incorrect due to rounding errors. So what if you don’t want that? Read on…

Precision as Displayed

If you turn on “precision as displayed” then whenever Excel performs a calculation, it looks at the format for the cell, displays what you are expecting, and then throws away any additional detail that it is not showing you. Yes, throws it away, discards it, gone for ever. Use this option with extreme caution. Luckily it is a per-workbook thing so this will not affect other files you work on, and it will persist with the file you use it on when other people open it.

So – step one, format your cells to display what you need (probably two decimal places). To turn on the option you want:

• Excel 2000 / 2002 / 2003 go to Tools > Options > Calculation > tick “precision as displayed”, then OK, then OK to acknowledge the warning.
• Excel 2007 go to Office button > Excel options > Advanced > calculation (scroll way down) > tick “precision as displayed”, then OK to acknowledge the warning, then OK to save the settings

Now when you do any calculations in this workbook, what you see is what is stored – but there’s no going back to get more detail out, so make really sure your display formats are what you want before you start.

A better way

No, not a better way to fix it if you already have a problem, but a potentially better way to build your spreadsheets in future:

Create a named range called VATRate (VAT is too short a name for Excel 2007 since there is a column of that name, and everything else up to XFD, but older versions such as Excel 2003 would be fine with it). Don’t put a cell reference in there, just put our formula “=115/117.5″ or just =0.978723 directly. Now we can use this name wherever we like and at any later date just update the formula in one place – our named range. When you build any formulas that calculate out a value including VAT, refer to this named range as part of your formula. Eg, C27=A1*B27*VATRate.

As of today, fixes for this issue in Excel 2007 and Excel Services 2007 are available for download…We are in the process of adding this fix to Microsoft Update so that it will get automatically pushed to users running Excel 2007 or Excel Services 2007.  Additionally, the fix will also be contained in the first service pack of Office 2007 when it is released (the release date for SP1 of Office 2007 has not been finalized).

Microsoft knowledgebase article KB943075 discusses the fix and gives the usual details for what versions and sizes the updated files should have after the fix. The version number of Excel.exe is altered from 12.0.6024.5000 to 12.0.6042.5000. Now read that again – yes, easy to miss the difference from ’24′ to ’42′ if you look too quickly. (NB: you may have a different version, mine is at 12.0.6024 after installing the security update as per KB936509, as far as I can tell.)

The download for the fix for Excel 2007 (33Mb exe file) is linked from the Excel team blog as well as from the KB article. The blog post also has links for Excel Services 2007, both 32 bit and 64 bit.

A few people in the comments thread in the Excel team blog post about the bug seem to have some misconceptions about the seriousness of the problem. Some have asked how often it is likely to come up, implying that they think it is vanishingly unlikely. This seems to be particularly those who have misunderstood that the example of 850*77.1 is only one simple example which is easy to remember and to type, but there are several more simple ones as well as thousands of other combinations which lead to the buggy result (due to floating point rounding errors in the calculation hitting a result which is sufficiently close to 65,535 to cause the false display of 100,000). Nine examples are shown in the screenshot below, and in a table you can easily copy and paste to try this for yourself.

Nine examples of simple calculations which Excel can’t work out*

* yes, I know the underlying value in the answer is as accurate as any previous version within the limits of the floating point calculation method and it just displays wrong, but in the real world that’s just as bad.

To use the examples in the table above, select them, copy (CTRL-C), open Excel.
With cell A1 selected go to Paste Special (use the dropdown arrow on the Paste button or do ALT, E, S). Choose Text and click OK.

If you divide 65,535 by integers starting from 1, then multiply the result by the same integer, you will quickly find many instances of the display bug. For example, A7=65535/7; B7=A7*7 (I actually used the ROW() function to generate these so  I could copy and paste blocks quickly). For the integers 1 to 256, you will get 30 examples, the first being 65536/13=5041.15384615385, and 13*5041.15384615385 = 100,000.

How many more examples are there?

In the first 524,280 results, there are 80,242 bugs, which is approximately 15.3%. I do not consider this many to be rare, although I accept that these are all effectively getting one of a very few values close to 65,535 which have the bug – the number of buggy values is small, but the combinations of number pairs which lead to them is quite large. The nine examples given above all have exactly the same product – 65,534.999999999993 (you can see this as the value stored if you open the XML file for that worksheet)

There are several places where as many as seven consecutive integers lead to the bug; the first sequence this long starts at 100,334, the first set of six begins at 31,745. The longest gap I found in the first half million or so cases is 1,370 between the bugs at 262,589 and 263,959.

There are some interesting patterns to the integers which cause these. For example, 13*2^n, 49*2^n, 81*2^n and many other similar chains produce the bug.

Doing a similar exercise on numbers with exactly one decimal place (1.1, 1.2 … 52429.7 but not 1.0, 2.0 etc.) there are 64,325 bug pairs, about 13.64% of results. There is a sequence of 8 numbers from 28,059.0 to 28,059.7 which all produce the problem. A few simple example pairs include 20.4 * 3,212.5, 40.8 * 1,606.25 and 212.5 * 308.4. It starts to become clearer that there are quite a lot of calculations which could occur in normal business models and give rise to the error.

Can I test my files to see if this is affecting my results?

Simon Murphy has published some code which you can use to test your files for occurrences of the bug. He also discusses how important this bug is overall, in terms of actual impact to real users – noting that the number of people who have moved to excel 2007 so far seems to be relatively small. Not zero, but the problem would have had loads more impact if it had been undiscovered for another three to six months. I have a client who are rolling out as I write, migrating several thousand users from Office 2000 to Office 2007. They generate huge management accounting spreadsheets which spit out pretty reports on the one hand, but on the other the data they generate is piped via CSV into their ERP system. So one person would have a chart or summary table with correct figures, while the back-end systems would be out by a significant margin of error. This could take a long time before anyone could have isolated the error and it’s source.

What about cases where this becomes an actual error in the value?

As previously discussed, there are several ways in which the display error can become fixed as an incorrect value (of 100,000 or 100,001):

• using the ROUND function (but not ROUNDDOWN nor ROUNDUP)
• using “precision as displayed”
• exporting to CSV
• Paste Special > Values
• using the TEXT function to convert to a string

In addition, the MOD function seems to just break down altogether – it does not use the 100,000 but returns totally bogus results.
For example, MOD(850 * 77.1, n) gives -7.27596E-12 for integer values of n including 1 and 5 (which should both return 0). even MOD(65534.999999999999,1) gives a result of 0.999999999999 quite happily. Something quite odd going on with this, as MOD should never return a negative value, mathematically speaking.

So what functions work safely?

In addition to the obvious mundane arithmetical calculations, most functions seem to work just fine. The MAX and MIN functions and their cousins LARGE and SMALL work as normal, as do conditional formats including data bars and colour scales. The screenshot on the right shows how odd this may appear.

The FLOOR and INT functions seem to use the correct underlying values and not propagate the error at all. ABS does not change the value, by design (just lose the sign) so it repeats the 100,000 display bug, but still does not lock this in. ABS(-850*77.1) shows 100,000. Adding 2 to that result gives 65,537.

ROUNDDOWN and ROUNDUP both seem to happily return 65,535 as their result. Of course, as Erich Neuwirth pointed out in the Google Groups thread on the subject of the bug, in a way this should not be the case. We know that the result of 850*77.1 is not actually 65,535 but a tiny fraction under that due to floating point inaccuracies.
So that would mean that ROUNDDOWN (850 * 77.1, 0) should truncate the entire part of the number after the decimal point to give a result of 65,534. Now that would be seen as a bug, since we know that in reality 850*77.1 is actually 65,535 exactly. So there must be something in the algorithm for ROUNDDOWN which assumes if a number is close enough to a whole number, round it up to that value, treat it as an integer input and ROUND it down by precisely nothing. The same applies for ROUNDDOWN used for any number of decimal places up to 30 – it spits out 65,535 as if the inaccurate interim value never existed.

I am happy to continue saying “ROUNDDOWN is correct” in this context, since it is closer to our expectations than if every floating point error introduced were to cause whole numbers to be lost. A dollar here, a barrel of oil there, a square mile of land for someone else. This would not be acceptable, but I can accept that the number stored underneath is inaccurate to some bazillionths of a penny. Same goes for the other functions such as INT and FLOOR – they are actually giving incorrect results, but they are giving the result they should in a normal decimal universe.

Of course, if you are a nuclear physicist you don’t want Excel making these assumptions on your behalf for very small numbers, as they would be considered wrong in that context.

Don’t forget, these floating point errors have been around for a very long time. It is only a bug like this that makes people take notice what is going on “under the hood” and try to grasp the idea that their entire accounting career has been a lie, and every report they ever wrote was probably some kind of approximation. People generally fall into three camps on this:

1. Blissfully unaware that their figures are inaccurate, and totally unaffected by the fact
2. Aware that these errors exist in the n’th decimal place as a matter of fact, but happy to accept that this is not fatal
3. Fully aware of the floating point problem, and careful to check that functions handle very-near-integers sensibly to give a result which would be expected in the real world if calculated in decimal.

Which type are you?

Spread the word :