Wonderful.  You hit this:
		/*
		 * FIXME FIXME FIXME
		 * This should return NA but some of the math functions may
		 * rely on this for now.
		 */
		g_return_val_if_fail (a_row<=b_row, NULL);
		g_return_val_if_fail (a_col<=b_col, NULL);

That comment probably has been sitting there for 20 years.

The problem comes from the inverted range in cell IL23.

    =sumproduct(N23:IQ23,N23:IQ23)/columns(N23:IQ23)

Without that cell, no warnings are produced.

I am not entirely certain what should happen in this situation.  I'll have
to investigate.

I doubt you actually meant to use that formula.  You should either make
sure there's room (column-wise) for the entire block, or else use one
block less.  You can change the number of columns by right-clicking on
the sheet-name tab and selecting Resize.

>> I doubt you actually meant to use that formula.

Indeed not.  It's not even my code.  I suspect some student wrote that formula, probably inadvertently.  I have more context than you do, since I brutally stripped down a much more complicated calculation in order to create a relatively concise bug report.  Even in context, it doesn't make sense.

OTOH it doesn't look particularly ungrammatical;  it doesn't look like something that should throw any kind of warning, let alone a "CRITICAL" assertion.  It creates a circular evaluatinn dependency, but there's nothing particularly unusual about that.

In any case, it's odd that one cell can produce 436 messages.

The more I think about it, the more I doubt that that cell IL23 is "the" cause.  At a minimum, I suspect multifactor causation.
  -- getting rid of cell IL23 makes the symptoms go away
  -- deleting some blank rows above cell IL23 makes the symptoms go away.  The cell gets relocated, but its essential meaning does not change.

=============

Question / possibly constructive suggestion:  How hard would it be for assertions like this to figure out which cell or cells provoked the problem?  That might make debugging easier for everybody.

I'm certain of what the problem is.  Don't worry about that.  I just need
to figure you what the right result is.  That could be an error (which?)
or something else.

> How hard would it be for assertions like this to figure out which cell
> or cells provoked the problem?

Fairly hard.  To solution is to attach a debugger and poke around.
Or to turn DEBUG_EVALUATION on in dependent.c

The "right result" should not be a matter of opinion.
I reckon it is pretty well determined by the mathematics.

Because of the circular evaluation dependency, there will be
convergence issues.  Depending on numerical values, the sumproduct()
might converge to some finite value or it might diverge to infinity.
It may take a few "recalculate" cycles before it settles down.

I would just treat it like any other circular dependency.  If there remain other open questions, please clarify the question(s).



BTW just for fun, you can type the following into the first three cells:
  _A_                        _B_   _C_
  =if(B1,4*A1*(1-A1),C1)      0    0.123

Then set B1 to 1.  A1 will take a long, long time to settle down.  Chaotic deterministic map.

This has little to do with sumproduct.  In RC-mode the formula looks like
this:

=sumproduct(RC[5]:RC[24],RC[5]:RC[24])/columns(RC[5]:RC[24])

You have a range here, RC[5]:RC[24], where the end-point goes off the
right side of the entire sheet.  "IL" is column 246.  246 + 24 > 256.
So the problem "what value should this fetch and from where?" and not
"what computation should we do with the values?".  The latter is well
determined.

>> The problem comes from the inverted range in cell IL23.
>> You have a range here, RC[5]:RC[24], where the end-point goes off the
>> right side of the entire sheet.  

We must be careful to distinguish:
 a) the FILED formula as seen in the .gnumeric file, from
 b) the DISPLAYED formula as seen on the spreadsheet.

I assume we are still talking about cell IL23.
I observe the DISPLAYED contents to be =sumproduct(N23:IQ23,N23:IQ23)/columns(N23:IQ23)
The DISPLAYED formula does not extend past the edge of the sheet.
I observe the sheet size to be 256 columns 65536 rows as expected.
I observe the last visible column to be IV as expected.
I consider IQ to be less than IV ... i.e. 251 is less than 256.
This is consistent with the colored highlighting observed when I click on the cell and hit <F2>.
The DISPLAYED formula is not well describes as RC[5]:RC[24].
The DISPLAYED formula involves a circular dependency.

Furthermore I observe that clicking on the cell, hitting <F2> and then <enter> makes the symptoms go away, even though there is no discernible change in the DISPLAYED formula.

====

However it appears that the FILED formula is different.
We are talking about ExprID=3 which is well described as RC[5]:RC[24].
The FILED formula does not exhibit a circular dependency.

I conjecture that the error-handling routines act on the FILED formula to produce the DISPLAYED formula.

===================================
So I assume the question is, what to do when the FILED formula extends past the edge of the sheet.

Background information:  Note that =offset(A1,0,256) returns #REF!

Suggested behavior #1:  Other references to off-sheet cells should do the same, i.e. return #REF!.  This seems consistent, logical, and defensive.

Suggested behavior #2:  The error-handling routines should not make subtle changes to the formula.  I like defensive code.  Subtle changes are the opposite of defensive.
  2a: Whenever possible, leave the formula alone.  If necessary, the formula will evaluate to #REF!, but the formula itself is unchanged.
  2b: If that is not possible, change the formula (or some part of it) to #REF! rather changing it to something that might appear valid but gives the wrong answer.

=================================
Possibly related observations of other inconsistencies.  See attached odd-fill.gnumeric.

Recipe:  Start a fresh copy of gnumeric.
In cell A1 enter =columns(IQ1:IT1)
Fill across 10 columns.
Observe very peculiar results.  Apparently the cell-descriptor wraps around from the right edge of the sheet back to the left.  It counts modulo 256.

In contrast, another recipe:
In cell A3 enter =columns(IQ4:IT4).
Copy that cell to the clipboard.
Paste it into B3, then C3, ... H3.
Observe odd results, different from the peculiar results in row 1.

And another:
In cell B5, enter =columns(A5:D5)
Copy that cell, and paste into A5.
Observe #REF!.  Contrast this with the previous example.  Evidently the fill routines silently patch up cells that extend past the right edge, but are fussy about the left edge.  Obviously they have to be fussy, because there is no good way to represent negative column numbers (or row numbers) in A1 notation.  Still the left/right inconsistency is cause for concern.

Suggested behavior #3:  The fill routines should not make subtle changes to the formula.  Ditto for the paste routines.
  3a: Whenever possible, follow the pattern, even if the resulting formulas reference off-sheet cells.  If necessary, the formula will evaluate to #REF!, but the formula itself is not mutilated.
  3b: If that is not possible, change the formula (or some part of it) to #REF! rather changing it to something that might appear valid but gives the wrong answer.  There are cases where this is already done, e.g. in the 2nd and 3rd example in this section.

Created attachment 326637 [details]
odd and inconsistent fill and paste behavior

Another suggestion:  It might be nice to have a centralized routine for relocating a formula, with due consideration to absolute references, relative references, and sheet boundaries.

All of the following could make a structured call to this routine:
  -- Read file
  -- Paste
  -- Fill
  -- Duplicate sheet

I reckon this would make the program simpler, easier to use, safer to use,  easier to document, easier to maintain, and easier to extend.

I have no idea what this would do to XL compatibility.

This problem has been fixed in our software repository. The fix will go into the next software release. Once that release is available, you may want to check for a software upgrade provided by your Linux distribution.