I prefer not to do that. Especially in long formulas, using the explicitly spelled out TRUE or FALSE in a VLOOKUP helps when auditing the formula. A “TRUE” or “FALSE” is much harder to overlook than a “1? or “0? (And I never EVER omit the last parameter, to make sure I WANT the TRUE and haven’t just forgotten to put in the desired value!).
The few extra key strokes don’t matter, if they help with the maintainability of the formula. And with the “intelligent” parameter options in Excel 2007 and later, I just hit “tab” for TRUE or “down arrow” and “tab” for FALSE to fill the parameter, so for “False” it is just “down arrow – tab” – close banana. Done. One more keystroke than typing a zero. But lots of benefits when auditing and revisiting the formula after three months!!!

When you said:
“Every one knows a single match columns and mutiple index columns is faster than vlookup
But a Single Match Column and 1 Array entered index per column is still faster.”

Could you elaborate on the “Single Match Column and 1 Array entered index per column”? Maybe give an example.

Thanks

IFERROR is whitewash which will hide any errors in your formula’s results. ISNA is very specific.

The important points for most lookup functions such as VLOOKUP (with 0 or FALSE parameter) and MATCH (with 0 for exact match) are that a #N/A error specifically means the data you were looking for is not in the lookup range. #REF or #NUM most likely means a malformed lookup (eg VLLOKUP with column range width).
Others errors such as #DIV/0 or #NAME would be the result of bad data in your lookup range, in other words you rlookup returned a result from a cell which itself had an error in (of course this error could be a #N/A or #REF or whatever.

ISNA allows you to much more precisely pin down errors which are the result of missing data in your list and either highlight these or suppress them as appropriate to your model. If I am asked to do some work on a big model that someone else has built I will sometimes do a find for =iferror(*,”") to see if there are formulas which are sweeping all errors under the carpet.

If only we had IFNA(… – but Dick’s method of only using the VLOOKUP once and refering the ISNA to that cell removes the calculation overhead of doing it twice, and the maintenance overhead of updating your function twice (when necessary), so it is not a biggie.

Good response on the use of the True / approximate match. Other examples I use to show True doing something useful are finding the period (eg year/quarter) that a date falls in and getting the discount band for an order depending on volume ordered (bot depending on sorted data, as with the exam grades).
Using “True” is also the only situation where VLOOKUP(value, range, 1, True) makes sense – getting the value back that you just looked up? In these “approximate match” situations this would return the boundary value rather than the category it is in. Again, useful to find the date that the relevant period starts on, or the level at which a discount band starts (maybe the discount only applies to the quantity over that level, not the whole order).

@Mark – you should also be aware that if your data is in sorted order and you use the “True” parameter to lookup something which is there (so no approximation needed) but is repeated, you get the last result found, whereas False returns the first result found. So if you had a product price list in which you never overwrite a price but add the new one with the date it is in effect from, True would give you the current price if the list is sorted in ascending order by product code then date price came into force.
False would give you the original price unless you sort ascending by product code and desceding by date, but this is not very intuitive, most people expect data to have newest info at the bottom generally.

@Sam – I agree, very often a single MATCH can be used for multiple INDEX functions (with or without arrays, depends on the user level) and is easier to maintain than many VLOOKUPS, far more efficient, and lends itself well to the ISNA function being directed only at the MATCH result, rather than for many separate lookup functions.

@David Hager – explicit intersections, good. Explicit intersections using named ranges in place of cell refs, great. Implicit intersections on named ranges / whole columns, even greater (where appropriate). A formula that reads =Units * (SalePrice – Cost) is so easy to read, yet baffles so many users as to how this could possibly work on every row of a large list of data. (Arthur C Clarke and all that)

The long formula used here brought up an old wish I have:
A formula editor with syntax highlighting, identing, intellisense and a debugger. Similar to the VBA IDE. This would make the live of a Excel maniac much easier.

Dominik