Comments on: non error error

By: Harlan Grove

Harlan Grove — Tue, 08 Jun 2010 18:24:33 +0000

Backwards compatibility. Workarounds needed in one version should continue to work in subsequent versions.

But the single quote is the syntactic means of entering a zero-length string constant. While it’s possible to generate a zero-length string constant by entering the formula =”", copying it, then pasting it in-place as a value, such a cell will APPEAR identical to a blank cell in the formula bar, but it won’t be a blank cell. To me that’s far more questionable than treating a single quote as equivalent to “”.

By: sam

sam — Tue, 08 Jun 2010 17:00:52 +0000

@Harlan,
You are right of course….I should have made that more clear.
I am amazed at how things like this have continued uncorrected across versions….

By: Harlan Grove

Harlan Grove — Tue, 08 Jun 2010 15:38:36 +0000

@sam – differences between SUMPRODUCT and COUNTIF need to be expressed precisely. SUMPRODUCT(–(x=”")) and COUNTIF(x,”") will return the same result, but SUMPRODUCT(–ISBLANK(x)) can return a different result. A single quote should be treated as identical to “”.

By: sam

sam — Tue, 08 Jun 2010 08:28:48 +0000

There are other such inconsistencies

A classic example is a the way in which a cell containing a single quote is treated by different features and formulas

a) Autofilters , Find, CountBlank, Sumproduct/CountIF(s) treats the Cell as Blank
b) Advanced Filters ,Sort, CountA,ISBLANK GoTo Special Blanks doesn’t

By: Harlan Grove

Harlan Grove — Wed, 02 Jun 2010 14:44:15 +0000

And the 3rd through 5th formulas should be

=SUMIF(A1:A2,”<>1″,B1:B2)
=SUMIF(A1:A2,”<>1*”,B1:B2)

=SUMIF(A,”<>x”,B)

By: Harlan Grove

Harlan Grove — Wed, 02 Jun 2010 14:41:48 +0000

That’s ‘criteria beginning with <>’.

By: Harlan Grove

Harlan Grove — Wed, 02 Jun 2010 14:36:51 +0000

This works the same in all versions which have SUMIF. It only works when error values are criteria, and that may be because criteria arguments are always handled as text strings. That is, Excel always and automtically converts the #REF! in the criteria arguments into “#REF!” (or maybe “=#REF!”).

FAR WORSE, criteria beginning with don’t always produce the complementary result to criteria otherwise the same but beginning with =. For example, enter 1 in A1, =”1″ in A2, 5 in B1 and 66 in B2. Then compare the formulas

=SUMIF(A1:A2,1,B1:B2)
=SUMIF(A1:A2,”1″,B1:B2)
=SUMIF(A1:A2,”1″,B1:B2)
=SUMIF(A1:A2,”1*”,B1:B2)

How many people would you think would be caught short by

=SUMIF(A,”x”,B)

not returning the same value as

=SUM(B)-SUMIF(A,”x”,B)

The problem is that Excel treats = criteria as matching both numbers and text when the criteria is numeric, but reverts to standard Excel semantics and distinguishes between text and numbers in criteria.

This is old news. Poor design, but at this point I don’t see this changing.

By: Biggus Dickus

Biggus Dickus — Wed, 02 Jun 2010 13:55:30 +0000

Yes this is an inconsistency IMHO. It does mean that it would be possible to have a missing reference value in your total and that is not a good thing.

It defininitely will make it hard to completely trust these formulae as the error will not be visible unless you select the cell and look at the refernce itself.

Unfortunate but it’s the way it is and we have to watch out for it I guess.

OTOH MS could fix this in a Service pack because there would be no argument for leaving it this way to protect legacy spreadsheets (??)

Better send it on to the Excel Team, but I’m not sure to who as our friend Dave G isn’t there anymore :-(

Dick

By: Patrick O'Beirne

Patrick O'Beirne — Wed, 02 Jun 2010 13:32:23 +0000

COUNTIF, DCOUNT, DSUM all treat the #REF! as a value to be matched.
MATCH & LOOKUP propagate the error.
That’s Excel’s way, I guess :-)
Another one for the cabinet of curiosities.

By: Simon

Simon — Wed, 02 Jun 2010 10:39:57 +0000

I’d expect them to propogate like they do in most other cases (and on OO calc), so they can be traced and fixed.