Intersecting Calculated Slices: which rule sets the value?

[John Hammond]

Folks

It helps to visualise 2 intersecting planes at right angles within a cube so that they form a cross when seen from one end of the cube.

We have

A = {a1,a2,a3}
B = {b1,b2,b3}
C = {c1,c2,c3}

(sort of a rubiks cube)

We have
[a2] = n: 1000 ;
[b2] = n: 2000 ;

This means the intersection cells are {a2,b2,c1} , {a2,b2,c2}, {a2,b2,c3}

So what value do we have contained within these after execution, 1000 or 2000?

We have rules that the more dimensionally precise rule takes precedure thus if we had
[a2,b2] = N; 3000 ;
we would know that the intersection would be set to 3000 regardless of where the order of the rule within the .rux file.

so clearly with forsight we can prevent this dilemma, and thus maybe the question should never arise.

But lets say you had somebody who had coded this without explicitly setting the intersection.

So who wins out of the 2 slices?

Does it depend on the order of the rule within the .rux file (unlikely as it goes against TM1 philosophy)
Does it depend on the order of the dimensions within the cube? More likely.

I could build this and find out but I think this is a topic of some interest so I am putting this up on the forum before I do that.

Thanks

[nataraja.pl@tcs.com]

It Depends on Order of dimension in a cube
D1=a+b
D2=c*d

if oreder of dimension on your cube is D1,D2,then D2 calculation overwrites D1 calculation on intersection cell.

[Wim Gielis]

Cells/areas will be calculated based on the order of the rules in the .rux file.

The first rule (top to bottom) whose area matches the cell/area to be calculated, will be the one executed for that cell/area.

I bet you knew this already, but that being said, I do not see the problem.

Can you clarify a bit more please?

[Martin Ryan]

We have
[a2] = n: 1000 ;
[b2] = n: 2000 ;

This means the intersection cells are {a2,b2,c1} , {a2,b2,c2}, {a2,b2,c3}

Pretty much ditto to what Wim said. You have rule precedence here, the first rule says 1000, so all three intersections will say 1000. However {a1, b2, c1} will be 2000.

Does it depend on the order of the rule within the .rux file (unlikely as it goes against TM1 philosophy)

This is precisely TM1 philosophy. The first rule that can be applied, will be applied (except "continue"). All subsequent rules will be ignored.

E.g. if you have
['Budget'] = 0;
['Budget', '2011'] = 10;

Then the second rule will never be applied, because the blanket rule would have been applied first. Thus you must write the exceptions before the general rule.

Martin

[John Hammond]

Thanks Martin/Wim

As usual I have overcompensated my ideas in that originally I thought rules order was absolutely crucial in that you had to define a subresult in the rule before using it later on.

http://www.tm1forum.com/viewtopic.php?f ... 711#p14763

This set me right and I forgot about the stipulation which I knew about that subareas should be defined before a larger area because I got into the idea that the compiler would take care of it all.

At rule save/load time the compiler must place a pointer back to the calculation in the cell to be calculated. Clearly there can only be one pointer and there has to be some rule of precedence which pointer is set when the cell is referred to in multiple areas. This was determined as the order the rule appears in the file. (possibly might have worked with latest wins as well but easier to implement).

I sort of got it in my head that in a cube with 3 dimensions the compiler would go through all areas qualified by

3 dimensions
2 dimension
and then
1 dimension

and assign pointers.
It is a scheme that could be adopted but then there is the intersecting calculated slice as described above where it becomes a cropper so the designers probably decided to stick with:

First rule in a .rux file to refer to the area containing a cell is used to calculate that cell.

Not very snappy though if anyone can come up with a better mnemonic.