GNOME Bugzilla – Bug 336212
Implicit interaction problem with certain "node" functions
Last modified: 2006-04-04 22:25:34 UTC
Please describe the problem: when you enther an expression like =AND(named1>x,named2>y) the answer is wrong. If you export it to excel and then open it into oocalc or msexcel, this works ok. Steps to reproduce: 1. Fill columns A,B with numbers (some above and below 2), and give them names x,y 2. calculate =AND(x<2,y<2) in a third column C Actual results: no logic in the result in C when compared to A,B Expected results: if both x,y are <2 then column C value should be "true" Does this happen every time? yes Other information: This is an example: with C=and(x<2;y<2) A B C x y 1 5 FAUX 2 2 FAUX 1 1 FAUX More over, when you delete column A, then named array x remains in memory (should be deleted if the corresponding cells are deleted) and location of y becomes wrong.
Created attachment 62134 [details] gnumeric file to reproduce the 336212 bug
The named ranges are defined as absolute (Feuille1!$A$1:$A$6, for example). Evidently that is to be ignored. (This has nothing to do with "and", btw.)
(In reply to comment #2) Dear Morten, You are right in saying that this are two separeted discussions: one about the "and" and the other about the absolute definition of named ranges. But still remains the problem with the "and", or not? Jota. > The named ranges are defined as absolute (Feuille1!$A$1:$A$6, for example). > Evidently that is to be ignored. > > (This has nothing to do with "and", btw.) > (In reply to comment #1) > Created an attachment (id=62134) [edit] > gnumeric file to reproduce the 336212 bug > (In reply to comment #2) > The named ranges are defined as absolute (Feuille1!$A$1:$A$6, for example). > Evidently that is to be ignored. > > (This has nothing to do with "and", btw.) >
Well, it problem is that "and" is a function that takes an arbitrary number of arguments but unlike (for example) "sum", x<2 is not turned into 3 or 5 different arguments. Jody: this patch is about as ugly as they come. We seem to need either 1. A flag on "node" functions telling function_call_with_exprs that we want the single argument behaviour. or 2. A flag on "value" functions saying that the there can be any number of arguments. Maybe "SS*" in this case. Ideas? [And clearly OR and XOR need the same treatment.] M. --- functions.c.~1.82.~ 2006-03-11 09:57:55.000000000 -0500 +++ functions.c 2006-03-27 13:28:54.102510000 -0500 @@ -72,37 +72,24 @@ }; static GnmValue * -callback_function_and (GnmEvalPos const *ep, GnmValue const *value, void *closure) +gnumeric_and (FunctionEvalInfo *ei, GnmValue const * const *args) { - int *result = closure; + int i; + gboolean got1 = FALSE; - if (!VALUE_IS_STRING (value)) { - gboolean err; - *result = value_get_as_bool (value, &err) && *result; - if (err) - return value_new_error_VALUE (ep); + for (i = 0; i < ei->func_call->argc; i++) { + const GnmValue *v = args[i]; + if (VALUE_IS_STRING (v)) + continue; + if (!value_get_as_checked_bool (v)) + return value_new_bool (FALSE); + got1 = TRUE; } - return NULL; -} - -static GnmValue * -gnumeric_and (FunctionEvalInfo *ei, int argc, const GnmExprConstPtr *argv) -{ - int result = -1; - - /* Yes, AND is actually strict. */ - GnmValue *v = function_iterate_argument_values - (ei->pos, callback_function_and, &result, - argc, argv, TRUE, CELL_ITER_IGNORE_BLANK); - if (v != NULL) - return v; - - /* See if there was any value worth using */ - if (result == -1) + if (got1) + return value_new_bool (TRUE); + else return value_new_error_VALUE (ei->pos); - - return value_new_bool (result); } /***************************************************************************/ @@ -356,8 +343,8 @@ /***************************************************************************/ const GnmFuncDescriptor logical_functions[] = { - { "and", NULL, N_("number,number,"), help_and, NULL, - gnumeric_and, NULL, NULL, NULL, + { "and", "S|SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS", N_("number,number,"), help_and, + gnumeric_and, NULL, NULL, NULL, NULL, GNM_FUNC_SIMPLE + GNM_FUNC_AUTO_UNITLESS, GNM_FUNC_IMPL_STATUS_COMPLETE, GNM_FUNC_TEST_STATUS_BASIC }, { "or", NULL, N_("number,number,"), help_or, NULL,
Created attachment 62160 [details] Pile of weird AND testcases Above patch is no good. This testcase shows... 1. We get empty arg wrong. (An empty arg seems to be FALSE. Apart from making us produce the wrong truth value, it also should prevent the all- blank clause from triggering.) 2. We get explicit-string argument wrong. [Known] 3. We get the non-array intersection of X==3 wrong. This happens both for a name and for an explicit range.
A patch for this went in a few days ago, and I've got one queued up to go in tonight that will fix a related issue where we'd fail when entering this as a 1x1 array formula. This code will note be backported. It is 1.7.0 only.