After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 417559 - COUNTIF problems
COUNTIF problems
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: General
git master
Other All
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2007-03-12 18:29 UTC by Luke Hutchison
Modified: 2009-12-09 22:19 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Luke Hutchison 2007-03-12 18:29:29 UTC
countif(range,"value") generally works the same as countif(range,"=value") even if the value is a string.  However countif(range,"") does not usually count blank cells, and neither does countif(range,"=") or countif(range,"=''").  I say "usually" because I have seen countif(range,"") work once with a Gnumeric sheet (in one snapshot in the 1.7.x series) but it failed when I imported the .gnumeric file into EditGrid (which is currently based on gnumeric-1.6.4), which alerted me to the problem.  I have since updated from SVN and haven't been able to get the latest snapshot to support it.  Note that countif(range," ") works as expected (counting the number of cells containing a single space).

I don't have access to an Excel install right now to check on the behavior there.  I know that Excel has weird inconsistent logic for ranges if they are beyond the end of content-containing cells in the sheet, but this countif usage seems broken even when the range is a set of formulas like: if(cond,"x","")

Perhaps regardless of Excel's logic, A justification for fixing this is that countif(range,"") seems to always return zero regardless of what is or isn't in the range, making it a pretty useless call.  Being able to count blanks is pretty important.

I am aware of bug 404095, but it seems to me that this can be fixed within the current framework without adding a new function.
Comment 1 Luke Hutchison 2007-03-12 18:30:34 UTC
Word wrap split one of the lines:
Note that countif(range," ") works as expected (counting the number of cells containing a single space).
Comment 2 Morten Welinder 2007-03-12 22:00:39 UTC
I really need concrete samples that you think are not evaluating right.
Comment 3 Luke Hutchison 2007-03-13 00:46:05 UTC
In a blank sheet, into b1 type: =countif(a1:a5,"")
Observe the result is 0.  I would expect it to be 5.

Typing things into some but not all the cells a1:a5 doesn't change the answer.

Also if you fill a1:a5 with =if(mod(row(),2)=0,"x",""), it still doesn't give the expected result of 2.
Comment 4 Luke Hutchison 2007-03-13 00:48:50 UTC
Oops, that last comment should say the expected result is 3 not 2.
Comment 5 Morten Welinder 2007-03-13 13:36:33 UTC
Ok, I see.  We don't seem to have a formal description of what "criteria"
is supposed to be.

We seem to ignore blanks.
#warning 2006/May/31  Why do we not filter non-existent as a flag, rather than checking for NULL in cb_countif

I don't see code to handle criteria like "xxx?yy*z"

What about strings that look like numbers?  (Does "10" match "10.0"?)
Comment 6 Andreas J. Guelzow 2009-12-09 20:17:43 UTC
> In a blank sheet, into b1 type: =countif(a1:a5,"")
> Observe the result is 0.  I would expect it to be 5.
In current git the result is 5

> Also if you fill a1:a5 with =if(mod(row(),2)=0,"x",""), it still doesn't give
> the expected result of 3.
In current git the result is 3.

So I think the initial report can be considered fixed. (Morten's thoughts in comment 5 would really first need to become some behaviour expectations.
Comment 7 Luke Hutchison 2009-12-09 22:19:37 UTC
Thanks, created Bug 604214 to deal with Morten's thoughts in comment 5 so they don't get lost.