SOLVED

Is it possible to Rank repeating strings without repeating same ranks in an Excel Table?

Brass Contributor

I want to automate batch no. for concatenated items in a column.
The problem is if the concatenation is not unique, I want to add a serial no. to the batch no. 
on the item which is repeated later in the column

I did this with the help of rank and countif function with variable array.
However, when I use this variable array in an table, the calculated formula goes wrong on table expansion

Is there a way to solve this?
I'm attaching a sample excel. If you can solve the problem in it, it would be much appreciated.

14 Replies

@Nishkarsh31 If you are willing to add a helper column to your table that counts the occurrence of each fruit, then the picture below might work for you. It's perhaps not the most elegant solution, but it's easy and it works.

Screenshot 2021-01-02 at 16.23.41.png

@Riny_van_Eekelen 

With same idea that could be slightly modified initial formula (without helper column)

=[@Date]&[@Fruit]&COUNTIFS($C$2:$C2,[@Fruit],$B$2:$B2,[@Date])

However, batch number is changing if transform the table, e.g. to sort it.

Hi @Sergei Baklan , I've tried this already.
For some unknown reason when we expand a variable range like $C$2:C4
As soon as table expands by one row
it becomes $C$2:C6 instead of $C$2:C5
and the formula doesn't work anymore

I don't know if it's a glitch or something.
Let me know if you can find a solution to this

Hi @Riny_van_Eekelen , I'm good with adding helper column.

However, For some unknown reason when we expand a variable range like $C$2:C4
As soon as table expands by one row, it becomes $C$2:C6 instead of $C$2:C5
and the formula doesn't work anymore

I don't know if it's a glitch or something.
Let me know if you can find a solution to this

best response confirmed by Nishkarsh31 (Brass Contributor)
Solution

@Nishkarsh31 

I see. Excel Table "remembers" that, for example, C5 is in the last row of the table. If you expand the table it adjust formula in row 5 such way it reference on the last row of expanded table. Thus you have two formulas with C6 an no one with C5.

 

Workaround could be

=[@Date]&[@Fruit]&
  COUNTIFS(
    $C$2:INDEX([Fruit],ROW()-ROW(Table1[[#Headers],[Fruit]])),
    [@Fruit],
    $B$2:INDEX([Date],ROW()-ROW(Table1[[#Headers],[Date]])),
    [@Date])

Woah. Mind blown
That row() - header row is inspired @Sergei Baklan 

One doubt though, why did you subtract the header Row?
" ROW()-ROW(Table1[[#Headers],[Fruit]])"
Why don't we just use " ROW() - 1 "

I tried, it's working
Any particular reason?

@Nishkarsh31 

The usual reason is to safeguard against the possibility that someone might insert a row above the tables at some later date and not notice that the record numbers are now out of step.  It is a more robust style of programming Excel.

@Nishkarsh31 , in addition to @Peter Bartholomew comment - on development phase always think about the maintenance. More time you invest in development much more time you save on maintenance. Avoid hardcoding in formulas (in particular like here, use reference instead of constant 1), keep errors handling, etc - future life will be much easier.

All the best in new year!

Genius, I appreciate it. @Peter Bartholomew 
One follow up question

I've always wondered that hardcoding values would save up on the calculation speed.

Writing 1 instead of referencing header row, would prevent one wheel of calculation, in case the
sheet is very heavy.
Is there any evidence of this?

Thank you so much sir @Sergei Baklan 

I have that same follow up question

I've always wondered that hardcoding values would save up on the calculation speed.

Writing 1 instead of referencing header row, would prevent one wheel of calculation, in case the
sheet is very heavy.
Is there any evidence of this?

@Nishkarsh31 

That's always a compromise - save few milliseconds on recalculation of few hours of your own time on maintenance. Depends on concrete case, if recalculation is really slow when it's worth to re-build formulae.

@Nishkarsh31 

If you are going to attempt to optimise a sheet for speed then I suggest you use tools to analyse the performance such as that offered by Charles Williams's FastExcel.  Otherwise, it is only too easy to commit too much effort to changing code that is not consuming significant resource in the first place.

 

Usually the first consideration is to select computationally efficient algorithms, then to program them to be as transparent as possible.  Rather than hard-wiring values which cannot be guaranteed to be constant, I would prefer to add the record sequence as a helper range; it would do little for speed but, given a suitable variable name, may add clarity to downstream formulas.

While working with Table, this is what you need to do:

 

=[@Date]&[@Fruit]&COUNTIFS(INDEX([Fruit],1):[@Fruit],[@Fruit])

 

I would strongly discourage using relative referencing while working with Tables.

 

I have also attached the file.

 

@Nishkarsh31 

A slightly modified solution I would recommend is here

=[@Date]&[@Fruit]&
  COUNTIFS(
    INDEX([Fruit],1):[@Fruit],
    [@Fruit],
    INDEX([Date],1):[@Date],
    [@Date])

 

It pretty much achieves the same thing. But I recommend that we avoid cell referencing while working with Tables.

 

@Sergei Baklan 

1 best response

Accepted Solutions
best response confirmed by Nishkarsh31 (Brass Contributor)
Solution

@Nishkarsh31 

I see. Excel Table "remembers" that, for example, C5 is in the last row of the table. If you expand the table it adjust formula in row 5 such way it reference on the last row of expanded table. Thus you have two formulas with C6 an no one with C5.

 

Workaround could be

=[@Date]&[@Fruit]&
  COUNTIFS(
    $C$2:INDEX([Fruit],ROW()-ROW(Table1[[#Headers],[Fruit]])),
    [@Fruit],
    $B$2:INDEX([Date],ROW()-ROW(Table1[[#Headers],[Date]])),
    [@Date])

View solution in original post