Comments on: New Years Resolution: No More Offset

By: Contextures Blog » Something Fishy: Using the Excel OFFSET Function

Contextures Blog » Something Fishy: Using the Excel OFFSET Function — Wed, 20 Jan 2010 06:02:00 +0000

[...] I like the OFFSET function, and use it to create dynamic ranges in some of my workbooks. There are alternatives to using the Excel OFFSET function, such as the Excel INDEX Function. There’s an interesting discussion of the merits of each function on Dick Kusleika’s Daily Dose of Excel Blog: New Year’s Resolution: No More Offset. [...]

By: Charles Williams

Charles Williams — Tue, 12 Jan 2010 20:14:00 +0000

There is some information about the dependency tree limits at
http://www.decisionmodels.com/calcsecretsf.htm

By: fzz

fzz — Tue, 12 Jan 2010 17:10:00 +0000

Showing completed calculations has its merits. From my perspective, OFFSET is used most often for dynamic chart ranges and interpolation. I have no problem with OFFSET used in chart ranges because there won't be many OFFSET calls. OTOH, interpolation usually involves cell formulas like

=IF(x=MAX(x_Range),INDEX(y_Range,ROWS(y_Range)),
FORECAST(x,OFFSET(y_Range,MATCH(x,x_Range)-1,0,2,1),OFFSET(x_Range,MATCH(x,x_Range)-1,0,2,1))))

This can be done, arguably better, using nonvolatile udfs which look like

=LININTERP(x,x_Range,y_Range)

There are many implementations in the newsgroups. Much simpler/shorter/less error prone than the OFFSET approach, and Excel would only recalculate it when x, x_Range or y_Range change rather than at every recalc. When x_Range and y_Range are static and x changes rarely, recalc will be faster using such udfs than using OFFSET. The only down side is needing VBA.

By: Rick Williams

Rick Williams — Tue, 12 Jan 2010 03:38:00 +0000

@Jan.

I've had the persistent 'Calculate' message left behind before in workbooks, a problem which I never understood. How did you know to convert to volatile functions (or that this would work)?

Do you (or any one here really!) have any information about the calculation tree limit? Is it number of levels, overall size, or something else? In addition, are there ways to analyse the depth or size of your current calc tree for comparison?

By: Paul Hollinger

Paul Hollinger — Mon, 11 Jan 2010 02:40:00 +0000

This was mentioned on Simon’s blog, but another reason I sometimes prefer INDEX is that a cell that references another cell via OFFSET does not show up as a dependent in the auditing tools. Coming back to one of my own complicated workbooks a year later, Trace Dependents is a very useful tool for me, and it doesn’t work for OFFSET.

By: Jan

Jan — Sun, 10 Jan 2010 23:18:00 +0000

In the past the only reason I have had to resort to Offset was at the point when a very large model broke the calculation tree limit and left behind that frustrating "Calculate" in the status bar instead of the normal "Ready". By replacing large swathes of Indexes with the volatile Offset I have been able to force the model to demonstrate a completed calculation. I have often wondered whether this was actually an improvement or just simply aesthetically more pleasant result. In either case the models would work even though a basic F9 on the "Index" Scenario was insufficient to clear the Calculate message.

Was there any real benefit other than appearance? (albeit at an accepted cost to both best practice and speed)

By: Sebastien Labonne

Sebastien Labonne — Sun, 10 Jan 2010 17:44:00 +0000

Those are interesting solutions and substitutes for OFFSET. However, I think that we have to consider more than the volatility or non-volatility of a solution.

1- While OFFSET might seem complicated to some users, I think it pales in comparison to many substitutes presented here.
2- Longer formulas are more error prone and harder to read, not to mention the character limit that might become an issue.
3- Slow recalculation is not a problem for many workbooks.

I think we may blinded and biased by the context we work with.

Personnally, I use OFFSET extensively, maybe too much, but that's not an issue in most of the models I develop. So I don't see why I should substitute it's convenience with some hyper-robust solution twice the lenght.

And you know what, I might have some sub-optimal code too.

Sebastien

By: Jon Peltier

Jon Peltier — Sun, 10 Jan 2010 16:49:00 +0000

To answer Ikkeman’s question, without doing any testing I would expect ADDRESS to be a lot slower. You first have to construct the address as a string, then use INDIRECT to interpret the string.

By: sam

sam — Sun, 10 Jan 2010 15:58:00 +0000

Dough...Nice technique to prevent # ref if the header row got deleted.

if only MS simply had created a built in function called LastRow which would work like this

=LastRow(A:A) to return a number indicating last non blank row in Col A (irrespective of blanks in between)
=A1:LastRow(A:A) to return the Address of the last non blank row or A1

off course till then there is one in MoreFunc.xll....

By: Doug Glancy

Doug Glancy — Sat, 09 Jan 2010 18:18:00 +0000

To add to Sam's I'd alter it to:

=INDEX(Sheet2!$A:$A,1):INDEX(Sheet2!$A:$A,LastRow)
because $A$1:Index($A:$A,LastRow) yields a #REF error if row 1 is deleted. In practice my dynamic ranges have headers, so to start on row 2 I'd use

=INDEX(Sheet2!$A:$A,2):INDEX(Sheet2!$A:$A,LastRow)
Of course that can cause problems if all the non-header rows are deleted because it will refer to A1:A2, so I'd change the definition for LastRow to:
=MAX(2, COUNTA(Sheet2!$A:$A))

Comments on: New Years Resolution: No More Offset