Difference between revisions of "IntraTable"

(Added a model with the example shown on this page.)
 
(8 intermediate revisions by 3 users not shown)
Line 1: Line 1:
[[IntraTable]] is an internal, experimental, unsupported function that is subject to change in the future.  It has been included behind the scenes in release 4.1.2 to allow interested users to try it out and give us feedback, and to locate and fix flaws and bugs before exposing it.  In the future, we may incorporate these features directly into [[Table]] and not expose this function, or perhaps we will continue to keep them separate.  That may depend on experience we gain in experimental uses of it in your models.
+
[[Category:Functions that create arrays]]
 +
[[Category:User-interface functions]]
 +
[[category:Top level functions]]
 +
[[Category:Table functions]]
  
= IntraTable(I,J,...)(x1,x2,....) =
+
== IntraTable(I, J,...)(x1, x2,....) ==
  
 
[[IntraTable]] is a generalization of [[Table]].  Like [[Table]], it creates a multi-dimensional edit table that allows users to edit individual cells, placing numbers, text and expressions in each cell.  However, unlike [[Table]], it allows individual cells to contain formula that reference others cells ''in the same table'', much like the cells of a spreadsheet reference other cells in the same spreadsheet.
 
[[IntraTable]] is a generalization of [[Table]].  Like [[Table]], it creates a multi-dimensional edit table that allows users to edit individual cells, placing numbers, text and expressions in each cell.  However, unlike [[Table]], it allows individual cells to contain formula that reference others cells ''in the same table'', much like the cells of a spreadsheet reference other cells in the same spreadsheet.
Line 7: Line 10:
 
[[IntraTable]] has precisely the same expression syntax as [[Table]].  You can change any valid top-level [[Table]] definition to an [[IntraTable]] (by changing the word "Table" in expression view to "IntraTable"), and things will operate exactly the same -- the edit table will operate the same way, the result will be the same, etc.  The only difference occurs when you place a formula in a cell that references other cells in the same table. A normal [[Table]] will reject these expressions, treating them as disallowed circular dependencies, while [[IntraTable]] allows them.
 
[[IntraTable]] has precisely the same expression syntax as [[Table]].  You can change any valid top-level [[Table]] definition to an [[IntraTable]] (by changing the word "Table" in expression view to "IntraTable"), and things will operate exactly the same -- the edit table will operate the same way, the result will be the same, etc.  The only difference occurs when you place a formula in a cell that references other cells in the same table. A normal [[Table]] will reject these expressions, treating them as disallowed circular dependencies, while [[IntraTable]] allows them.
  
= When to use =
+
== When to avoid and when to use ==
  
In order to hand these, [[IntraTable]] uses a totally different evaluation method than [[Table]], which in general is substantially slower. Thus, if you don't have intra-cell dependencies, you're better off sticking with [[Table]].
+
Avoid using [[IntraTable]] unless you really need complex dependencies among cells within an input Table. Intra-table dependencies are common in spreadsheets and it's tempting to use [[IntraTable]] if you are used to spreadsheets -- and especially, when you are rewriting a spreadsheet into Analytica. But, intra-table dependencies have many of the familiar problems of spreadsheets that we designed Analytica to avoid: Inflexibility and liability to errors when modifying an index or adding an index (dimension) to a table. It also creates redundancy by requiring multiple copies of what is essentially the same formula. You often need to paste copies of such formulas when extending a dimension of a Table.
  
Dependendies between cells within an edit table is very bad practice stylistically, and therefore, should be discouraged. If overused, it can bring with it many disadvantages that we are all familiar with from the spreadsheet world, including easy sources of errors, flexibility limitations when adapting to dimensionality changes (possibly introducing a need to copy/paste formula when dimensions change), undesireabe redundancy with multiple copies of the same formulas, and an increase in effort to validate the correctness of models. Therefore, it is recommended that you avoid the urge to use this ubiquitously just because you are used to doing it this way in spreadsheets.
+
It's usually simpler and faster to split out a few rows or columns that depend on each other into separate named variables, each with a single formula specifying its relationship to other rows or columns. If you have a table with recurrence relationships over an index, such as where each cell in a row is dependent on the preceding row, you can sometimes use built-in functions like [[Cumulate]] or [[Uncumulate]]. Otherwise, [[Dynamic]] is often useful. By default [[Dynamic]] works across the Time index. But, you can also specify another index to work across. By default, [[Dynamic]] goes from the first to last element of the index, but you can also use it in the reverse direction.  
  
If used sparingly, it can be very useful and convenient.  Some heavily recurrent spreadsheet calculations can be directly translated into an [[IntraTable]], thus simplifying that initial conversion (although you may want to consider cleaning these up later for reasons discussed already).  The [[Dynamic]] function has a basic limitation that recurrent [[Dynamic]] formula can only recur over the [[Time]] index, so in some cases [[IntraTable]] can provide one way around that.  And, unlike Dynamic, [[IntraTable]] allows the dependencies to be in an arbitrary order -- they don't have to be left-to-right, so when you have dependencies that are not simply left-to-right, they can be easier to encode with an [[IntraTable]].
+
Another reason to avoid [[IntraTable]] is that it has to use a less efficient evaluation method than [[Table]] (as do Spreadsheets), and so can be much slower to compute.  
  
= Using other cells in the same table =
+
Occasionally, however, the relationships among cells of a table are such that it's hard to represent them by splitting out slices into separate variables or by using [[Dynamic]].  For example, if the table contains dependencies across more than one index.  In such cases, [[IntraTable]] can be very convenient.
  
You can refer to other cells by using the [[Slice]] and [[Subscript]] functions on the keyword [[Self]], slicing or subscripting over the table indexes themselves.  The following table shows several examples:
+
== Using other cells in the same table ==
  
[[image:intraTableExample.png]]
+
You can refer to other cells by using the [[Slice]] and [[Subscript]] functions on the keyword [[Self]], slicing or [[subscript]]ing over the table indexes themselves.  The following table shows several examples ([[media:IntraTable example.ana|download as model]]):
  
Consider the expression in the cell [Year=2009.25, Level=5]:
+
:[[image:intraTableExample.png]]
:1+Self[@Year=@Year-1]
 
This expression refers to the value in the cell ''A[Year=2009,Level=5]''.  Notice that the slice on ''Level=5'' is implicit, since the cell is already located in row Level=5.  Thus, you only need to name those indexes that are shifted.  You can have one cell that depends on another cell, that depends on a third cell, and so forth, with arbitrary recurrences as long as the dependencies don't eventually wrap back to where a cell depends on itself again.  If a cell does indirectly depend on itself, then a cyclic dependency error results at evaluation time.
 
  
 +
Consider the expression in the cell <code>[Year=2009.25, Level = 5]</code>:
 +
:<code>1 + Self[@Year = @Year - 1]</code>
  
 +
This expression refers to the value in the cell <code>A[Year = 2009, Level = 5]</code>.  Notice that the slice on <code>Level = 5</code> is implicit, since the cell is already located in row <code>Level = 5</code>.  Thus, you only need to name those indexes that are shifted.  You can have one cell that depends on another cell, that depends on a third cell, and so forth, with arbitrary recurrences as long as the dependencies don't eventually wrap back to where a cell depends on itself again.  If a cell does indirectly depend on itself, then a cyclic dependency error results at evaluation time.
  
= See Also =
+
==History==
 +
[[IntraTable]] was introduced in [[What's new in Analytica 4.2?|Analytica 4.2]]''.
  
* [[Table]], [[ProbTable]], [[DetermTable]], [[SubTable]]
+
== See Also ==
* [[Dynamic]], [[Iterate]], [[While..Do]]
+
<div style="column-count:2;-moz-column-count:2;-webkit-column-count:2">
* [[Subscript]], [[Slice]]
+
* [[Table]]
 +
* [[ProbTable]]
 +
* [[DetermTable]]
 +
* [[SubTable]]
 +
* [[Dynamic]]
 +
* [[Iterate]]
 +
* [[While..Do]]
 +
* [[Subscript]]
 +
* [[Slice]]
 +
</div>

Latest revision as of 19:09, 22 October 2021


IntraTable(I, J,...)(x1, x2,....)

IntraTable is a generalization of Table. Like Table, it creates a multi-dimensional edit table that allows users to edit individual cells, placing numbers, text and expressions in each cell. However, unlike Table, it allows individual cells to contain formula that reference others cells in the same table, much like the cells of a spreadsheet reference other cells in the same spreadsheet.

IntraTable has precisely the same expression syntax as Table. You can change any valid top-level Table definition to an IntraTable (by changing the word "Table" in expression view to "IntraTable"), and things will operate exactly the same -- the edit table will operate the same way, the result will be the same, etc. The only difference occurs when you place a formula in a cell that references other cells in the same table. A normal Table will reject these expressions, treating them as disallowed circular dependencies, while IntraTable allows them.

When to avoid and when to use

Avoid using IntraTable unless you really need complex dependencies among cells within an input Table. Intra-table dependencies are common in spreadsheets and it's tempting to use IntraTable if you are used to spreadsheets -- and especially, when you are rewriting a spreadsheet into Analytica. But, intra-table dependencies have many of the familiar problems of spreadsheets that we designed Analytica to avoid: Inflexibility and liability to errors when modifying an index or adding an index (dimension) to a table. It also creates redundancy by requiring multiple copies of what is essentially the same formula. You often need to paste copies of such formulas when extending a dimension of a Table.

It's usually simpler and faster to split out a few rows or columns that depend on each other into separate named variables, each with a single formula specifying its relationship to other rows or columns. If you have a table with recurrence relationships over an index, such as where each cell in a row is dependent on the preceding row, you can sometimes use built-in functions like Cumulate or Uncumulate. Otherwise, Dynamic is often useful. By default Dynamic works across the Time index. But, you can also specify another index to work across. By default, Dynamic goes from the first to last element of the index, but you can also use it in the reverse direction.

Another reason to avoid IntraTable is that it has to use a less efficient evaluation method than Table (as do Spreadsheets), and so can be much slower to compute.

Occasionally, however, the relationships among cells of a table are such that it's hard to represent them by splitting out slices into separate variables or by using Dynamic. For example, if the table contains dependencies across more than one index. In such cases, IntraTable can be very convenient.

Using other cells in the same table

You can refer to other cells by using the Slice and Subscript functions on the keyword Self, slicing or subscripting over the table indexes themselves. The following table shows several examples (download as model):

IntraTableExample.png

Consider the expression in the cell [Year=2009.25, Level = 5]:

1 + Self[@Year = @Year - 1]

This expression refers to the value in the cell A[Year = 2009, Level = 5]. Notice that the slice on Level = 5 is implicit, since the cell is already located in row Level = 5. Thus, you only need to name those indexes that are shifted. You can have one cell that depends on another cell, that depends on a third cell, and so forth, with arbitrary recurrences as long as the dependencies don't eventually wrap back to where a cell depends on itself again. If a cell does indirectly depend on itself, then a cyclic dependency error results at evaluation time.

History

IntraTable was introduced in Analytica 4.2.

See Also

Comments


You are not allowed to post comments.