Numbers broken in IOS 18.0 and MacOS 15.0 Sequoia

SGIII: You should read the message I left for user Camelot on Sep 29, 2024 at 10:41 PM EDT

This will address, and may even answer, your questions about so-called "volatile" formulas.

But I will repeat here, because it obviously needs to be repeated (and quite often), that these problems never occurred until I updated my iPhone 12 Pro Max to IOS 18.0, and my MacBook Pro which I purchased NEW in April 2021 to MacOS 15.0 Sequoia.

Moreover, these problems have never occurred on my much older MacBook Pro which I purchased NEW in June 2013. For some years now, it has been running the last possible MacOS version that was available for it, which is MacOS 10.15.7 Catalina.

Not only that, I also have Microsoft Excel For Mac on BOTH of my MacBook Pros. Among other uses, I use Mac Excel to maintain FUNCTIONALLY EQUIVALENT versions of the spreadsheet that Numbers is currently mishandling on my iPhone running IOS 18.0 and MacBook Pro running MacOS 15.0 Sequoia.

I have never had these problems with the Mac Excel versions of this spreadsheet.

There are exactly 10,125 rows as of right now in the spreadsheet BEFORE the first row that Numbers is mishandling. These rows BEFORE the mishandled row are comprised of about 60% rows which have at least 1 cell with a formula, and 40% rows which are strictly comment lines with no formulas. Nearly all of the rows in the 60% contain cells which are performing some rather complex calculations involving the OFFSET(), INDIRECT() and ROW() functions. NUMBERS IS PROCESSING ALL OF THESE 10,125 ROWS WITHOUT ERROR. Clearly, some type of flaw has been introduced into Numbers under IOS 18.0 and MacOS 15.0 Sequoia that is causing it to mishandle the rows from the row with the 3 cells described above through to the end of the spreadsheet.

SGIII: I powered off my iPhone 12 Pro Max running IOS 18.0 and MacBook Pro running MacOS Sequoia 15.0, and left them off for 1 minute.

Then, I powered-up the MacBook Pro and viewed the spreadsheet with Numbers in iCloud. The same problems persist.

Then I powered-up the iPhone and viewed the spreadsheet with Numbers in iCloud. This time the problems are WORSE. Previously, I would see the correct data in the 3 cells which I mentioned in my original post regarding these problems for about 2 or 3 seconds BEFORE Numbers inexplicably mishandled the formulas in them and displayed red/white error triangles in these cells, as well as all other cells AFTER them and to the end of the spreadsheet which contain formulas. But now, when viewing the spreadsheet with Numbers in iCloud on my iPhone, the mishandled cells IMMEDIATELY display the red/white error triangles. There is now NO DELAY in seeing these error triangles in the cells whose formulas are being mishandled.

There is an additional problem in this regard that has in the past been associated with IOS updates and the functioning of Numbers in iCloud. When I powered-up my iPhone but before viewing the mishandled spreadsheet earlier today, the main Numbers screen showed a file size of 2.3mb below the spreadsheet icon. PRIOR TO THIS, the displayed file size was 2.8mb. BUT I DID NOT CHANGE THE SPREADSHEET!!! This is the problem with Numbers in iCloud that I have seen previously. This file size problem would then be fixed in the next IOS update.

However, as I've said previously, ALL formulas in the spreadsheet PRIOR TO the ones being mishandled continue to be properly processed.

It should be clear beyond a reasonable doubt that there are flaws in Numbers that have been caused by the recent updates of IOS to 18.0 and MacOS to Sequoia 15.0.

SGIII: I just now submitted a bug report via 'Numbers > Provide Numbers Feedback'. Not surprisingly, the immediate reply was that they USUALLY do not reply directly to an individual report, and thanked me for 'helping to make Numbers better'. Yet, the online report form listed an optional field for my e-mail address, with the explanation that it may be used to communicate with me. NOT!!!

I seriously doubt that my bug report, ON ITS OWN, is going to be involved in repairing these VERY OBVIOUS FLAWS in Numbers under IOS 18.0 and MacOS Sequoia 15.0. Unless, that is, my bug report is somehow the proverbial straw that breaks the camel's back, which by some miracle of the universe is what finally convinces Apple that these are problems WORTHY of being fixed AS SOON AS POSSIBLE WITH AN OPERATING SYSTEM UPDATE.

Then again, why should a 3 trillion dollar company fix something that it may feel is not having, and is not likely to have, a sufficiently adverse impact on its profitability that it really should be concerned?

Camelot: Regarding your question "Did you just add to the 10,000+ rows"

I have been adding rows to the spreadsheet at the rate of about 4 to 7 rows every two or three days since I originally created it in June of 2013.

As of this writing, the spreadsheet consists of a grand total of 10,155 rows.

Your statement regarding the number of calculations "that have to be done to evaluate the last cell" aligns neither in theory nor actual fact with the reality of what is occurring in the spreadsheet.

The first 9,893 rows are the detail section of the spreadsheet. Of these first 9893 rows, no more than about 50% have a cell with a formula, it is just one cell, and it is ALWAYS IN THE SAME COLUMN (which is column G). This is the formula in the currently last such cell (G9892) in the spreadsheet, as copied from the formula editor and pasted here:

SUM(OFFSET(G9892,−2,0),F9892)−E9892

This means "sum the cell TWO ROWS ABOVE cell G9892 with cell F9892, and subtract from this sum cell E9892".

Of the approximately other 50% of the first 9893 rows, ALL OF THEM ARE COMMENT LINES. THE VAST MAJORITY (ABOUT 99%) OF THESE COMMENT LINES ARE STRICTLY TEXT WITH NO FORMULAS WHATSOEVER. THOSE THAT DO HAVE A FORMULA USE ONLY THE ROW() FUNCTION WITH NO PARAMETERS TO DISPLAY THE NUMBER OF THE ROW WHICH CONTAINS THE COMMENT LINE.

There have never been any problems with Numbers evaluating the cells in the detail section of the spreadsheet.

There had never been any problems with Numbers evaluating the cells in the spreadsheet AFTER the detail section until the recent updates of IOS to 18.0 and MacOS to 15.0 Sequoia. Since these updates are the only things that have changed relative to HOW the spreadsheet is processed, they must be the cause of the mishandling of the spreadsheet.

Consequently, I am uncertain of the relevance of your statements "Quite simply, I'm going to guess you're running out of memory" and "The time delay is simply a facet of how many calculations the system can perform before it hits the limit" to the reality of what is occurring in the spreadsheet.

Regarding your question "Is it possible to trim the table, at least for testing, to see if the problem remains?", I am not as of this writing aware of any possibility of trimming the table for any reason.

As for tapping on the warning triangle, the resulting message is woefully unhelpful and inadequate, stating only that "This formula can't reference its own cell, or depend on another formula that references this cell". It does not give any indication whatsoever as to HOW Numbers has made this determination. The reason for this is obvious: IT IS NOT IN FACT HAPPENING.

The first cell which contains a formula that Numbers is mishandling is A10126. This is the formula in cell A10126, as copied from the formula editor and pasted here:

OFFSET(INDIRECT("a"&ROW(cell),addr-style),−2,0,rows,columns)

where cell, addr-style, rows and columns REPRESENT optional parameters that are not in fact specified. This means the following: "the cell that is in column a TWO ROWS BEFORE THE ROW WITH THE CELL CONTAINING THIS FORMULA".

SGIII: I think you misunderstand what I said.

I did not say that Numbers and Excel, AS RUNNING PROGRAMS OR APPLICATIONS, are functionally equivalent. I said that "I use Mac Excel to maintain FUNCTIONALLY EQUIVALENT versions of the spreadsheet . . .".

I was clearly saying that the SPREADSHEETS THEMSELVES, AS DISTINCT ENTITIES FROM THEIR PROCESSING PROGRAMS, are FUNCTIONALLY EQUIVALENT. They produce EXACTLY THE SAME RESULTS with their respective processing applications, except for the items Numbers is mishandling. Is not "EXACTLY THE SAME RESULTS" the essence of "FUNCTIONALLY EQUIVALENT"?

Camelot: The reason for using OFFSET() is as follows.

In my actual spreadsheet in question, there is cell G9982. In the row immediately AFTER it, there is a comment that has important information about the contents of row 9982.

When, as per usual, I insert new rows AFTER row 9983 (the comment line for row 9982), there must be a means for cell new cell G9984 to refer BACK TO cell G9982. But, the new rows always come from other rows in the spreadsheet, so there is no way for these other rows to know anything about their copy destination. Yet, as I just mentioned, new cell G9984 must be able to refer BACK TO cell G9982, without actually being aware of it as cell G9982. The only way this can be implemented is through the relative reference capabilities of OFFSET(), since I can tell OFFSET() to offset its cell reference by -2 rows, i.e., to the cell in the same column as OFFSET() that is 2 rows BEFORE it.