Of Table Calculations
So now we know a little more about table calculations, typically where are they used and more importantly, how do they differ from normal and levelofdetail calculations?
Lets tackle this in stages:
How do Table Calculations Differ from the other Calculations
Well it is simple really, with exception of the First(), Index(), Last() and Size() calculations, all table calcs are aggregate which means the value they are working with, first needs to be aggregated such as Sum(Sales), Count(Product) or {Include [Region] : Sum(Sales)} and secondly, these calculations take place inside Tableau, directly on the data that is visible (including scrolling) to you.
As a result, table calcs are used in connection with normal and LOD calcs rather than in place of them.
So How do Table Calculations Actually Work?
As data is returned to Tableau and materialised (by you) into the working window, table calculations are generated at this time, which means that table calculations are dependant on the filters that have been applied to your view.
Once you materialise your data, Tableau is simply running your selected calculation against teh defined scope but crucially, only against the data in your working window, all other data that is not materialised into the view will bear no relevance on the output of the expression used, even if you have defined the scope at the expressionlevel in the expressions editor.
And Finally, How and Where Will I Use Them?
How breaks down to two important criteria:
 Type of calculation / purpose
 Scope
Calculation Type
Is down to what you are trying to achieve, with row numbering calculations simply written as FunctionName() so the Index function for example is written simply as Index()
Whereas the remaining calculations (see the table above) all enclose an aggregate calculation on number in some form for example the running_sum() calculation for Sales would be Running_Sum(Sum(Sales)).
Scope
Arguably the most important part about table calculations is that of scope.
The scope of a calculation arguably detracts from the simplicity of Tableau, as no other function within the software requires you to consider beyond the draganddrop interface, exactly how Tableau needs to address the data.
Normally, when cutting data, it is enough to use case and/or if statements to determine which data is including in the calculation or, in the case of LOD calcs, what additional fields need to be considered (or removed); this is still true of table calculations as those calcs are wrapped inside table calcs, however, when you are writing your table calculation, you will be presented with the "Default Table Calculation" indicator:
Normal Calculation  Table Calculation 


Upon first creating your calculation, Tableau will default the table calc to Table (across)  do not worry if you have no data running across your table, i this instance, Tableau will switch to Table (down) in this instance.
Warning  

 
Be careful when setting the scope from the calculation editor:

About: Use
So you have thoroughly explained how table calculations work, although I am still unsure as to when and where I shall use them?
Where you use them will be down to your requirements, however it is possible that you may have already used them such as:
Lookup comparisons  Such as when testing for change in the case of A/B testing  variant vs control or, period over period eg:
Will enable you to compare the current row to the previous row  
% Total  You can easily use a levelofdetail calculation to calculate total: {Sum(Sales)} however, what if you want your total to be a subtotal?  
Rank  The classic Top n.  
Running_Sum  Without which, generating cumulatives would be impossible 
Many of the more complex charts require the table calculations for positioning in order hang data from them  the measure waterfall I built could not work without table calculations.
And performing calculations when using an OLAP source cannot be done without them (unless you use MDX which then only creates specific outputs):
OLAP sources (cubes), or any source of preaggregated data held within a rigid structure is often limited to simply retrieving data from an intersection of onetomany members such that ifthenelse logic calculations are usually unavailable, such the it then becomes necessary to use a lookup calculation to step in.