Thanks, Satya. I post more Open RAN articles to my LinkedIn account. Follow me there if you are interested in Open RAN. https://www.linkedin.com/in/russelllundberg/

]]>Very comprehensive and concise.

Looking forward for more. ]]>

Peter, thanks for your comment. I suspect there are several reasons for the unpopularity of GETPIVOTDATA().

- Generating GETPIVOTDATA() functions might not be the default setting for Excel. So people would only find it if they knew exactly what they were looking for.
- If enabled, one must follow the procedure I described to generate a GETPIVOTDATA() function: enter “=”, then click in a Pivot Table.
- As you point out, the Item string renders the function rather less usable than it could be. The string must be replaced with something like you describe, or by a cell reference, which I did.

Possibly a general lack of understanding about Pivot Tables also could contribute to GERTPIVOTDATA() unpopularity.

For the type of dashboards routinely produced by me and my teams, GETPIVOTDATA() is indispensable. I would not know how to automate those dashboards without it.

]]>You show how the parameter can be replaced by a cell reference, making the function more useful. Something I also do is to use a named array as the item parameter. This may be a full list of items in any order or any subset.

The requested data may be output as a multi-cell array formula or may be further aggregated by nesting the function within SUM, AVERAGE, AGGREGATE etc.

I don’t think GETPIVOTDATA deserves its dubious reputation.

]]>Great job, Alex! Thank you so much for finding that.

I really appreciate that you found that and reported it. Removing that error might help someone else so much!

]]>Hi Peter, many thanks for your comment.

I never forced myself to learn Excel Tables, and clearly I should. I have seen elsewhere that in some situations Excel Tables were simpler than the method I used. For example, there may be times when an Excel Table is simpler than using a Dynamic Named Range. Excel Tables might someday be a topic for its own blog post.

I really appreciate how simply your formulas express the concept, eg = 1 + FLOOR( k-1, n ) / n. This is a much clearer expression than what I presented.

Many thanks for your contributions! Russell

]]>I have just had a look at your latest (December) post and, broadly, would take a similar approach. I may use tables more than you to hold input data (particularly relevant for the dynamic range post).

I think your array of ranges (with its use of relative addressing) is somewhat overkill for the task in hand of generating a counter. I tend to assign a named formula ‘k’ to the task, where the name refers to

= ROW() – ROW(Table1[#Headers])

I only use that definition within the table (where the rows may be assumed to be aligned). For more general use within multi-cell array formulas I would replace that definition by

{= ROW(Table1) – ROW(Table1[#Headers])}

so that the index always starts at 1 irrespective of its location on the worksheet.

I am not convinced by your description of the data structure as a hierarchical list. I would see it more as a 2D array or cross-tab since the number of ‘cycler’ fields is defined to be the same for every level of ‘incrementor’.

My formula for ‘Cycler’ would be the same as yours

= 1 + MOD( k-1, n )

but I have, in recent years, adopted a slightly different formula for ‘Incrementor’, namely

= 1 + FLOOR( k-1, n ) / n

That calculation requires only integer arithmetic but otherwise there is little to choose between it and INT().

This may not be the level of automation you set out to achieve but at least the table can be extended simply by dragging the resize handle. A check on its ROWS property would not go amiss if you think there is a chance that you or an end user may forget to adjust the table. I will look out for your notifications of posts from now.

Best Wishes for the New Year

Peter