About rules for numbers and for string

[EP_explorer]

I run against with the strange (for me) behaviour of rules for numbers and for strings.
For illustration:
1. I create 3 cubes with the same dimensions - Numbers (from 1 to 10), and Numb_Str (with elements - Numb (type is Number) and Strin (type is String)
1) Numb_str
2) Numb_str1
3) Numb_str2

2. I put rules in Numb_str1

Code: Select all

SKIPCHECK;
[ ]  = N: DB('Numb_str', !Numbers, !Numb_Str);
[ ]  = S: DB('Numb_str', !Numbers, !Numb_Str);

3. I put rules in Numb_str2

Code: Select all

SKIPCHECK;
[ ]  = N: DB('Numb_Str1', !Numbers, !Numb_Str);
[ ]  = S: DB('Numb_Str1', !Numbers, !Numb_Str);

4. Input numbers and strings in Numb_str Cube

The result of calculation you could see next (at left Cube Numb_str, at the middle - Numb_str1, at right - Numb_str2) :

01.jpg (57.08 KiB) Viewed 10449 times

So that is the problem with string rule? What I have to do to put String in the third cube?

[jim wood]

So I take it your not feeding at all? You haven't used skipcheck?

[EP_explorer]

No - i didn't feed.

I only want to show numbers and strings (example is simple - in real life - task is more complicated of course) and I don't need to feed.
And also I don't want to calculate.

And it seems for strings - Tm1 allows that there is no string data in Numb_str1 - but why?

[tomok]

You'll have to feed the strings in Numb_Str1 in order for them to carry forward into Numbr_Str2.

[lotsaram]

You'll have to feed the strings in Numb_Str1 in order for them to carry forward into Numbr_Str2.

I wouldn't have thought that feeding would make any difference here. It should work without. Rule calculated string values are never cached and always calculated from scratch. At the point where the rule in Numb_str2 picks the value from the cell in Numb_str1 that cell should be evaluated which in turn should pull the original data entry value from the Numb_str cube.

Could be some weird issue with rule precedence and the N rule impeding the S rule. Have you tried either of these alternatives?
1/ Reverse the order of the N & S area qualifiers.

Numb_Str1

Code: Select all

[ ]  = S: DB('Numb_str', !Numbers, !Numb_Str);
[ ]  = N: DB('Numb_str', !Numbers, !Numb_Str);

Numb_Str2

Code: Select all

[ ]  = S: DB('Numb_Str1', !Numbers, !Numb_Str);
[ ]  = N: DB('Numb_Str1', !Numbers, !Numb_Str);

2/ Limit the area to only the relevant N or S area

Numb_Str1

Code: Select all

['Numb']  = N: DB('Numb_str', !Numbers, !Numb_Str);
['Strin']  = S: DB('Numb_str', !Numbers, !Numb_Str);

Numb_Str2

Code: Select all

['Numb']  = N: DB('Numb_Str1', !Numbers, !Numb_Str);
['Strin']  = S: DB('Numb_Str1', !Numbers, !Numb_Str);

[BrianL]

Perhaps this is the issue: http://www-01.ibm.com/support/docview.w ... wg1PI13072

[mattgoff]

Since it's working on the first set of rules and not on the second, it sure looks like a feeder issue to me. If you zero suppress, does the string column in the middle cube disappear? What happens if you remove the SKIPCHECK in your rules? If it works w/o SKIPCHECK, add some feeders (and a FEEDSTRINGS at top) and see if that works.

Matt

[lotsaram]

Since it's working on the first set of rules and not on the second, it sure looks like a feeder issue to me. If you zero suppress, does the string column in the middle cube disappear? What happens if you remove the SKIPCHECK in your rules? If it works w/o SKIPCHECK, add some feeders (and a FEEDSTRINGS at top) and see if that works.

Matt

Matt, (& Tom, Jim)... look at the cubes. 2D with all leaf cells. It can't be a feeding issue because feeding drives consolidation of rule calculated values, nothing else. When querying a single cell the value should still be returned regardless of whether a cell is fed or not. Besides strings don't consolidate, the one and only reason to feed a string rule is for it to display in a zero suppressed view.

[mattgoff]

You're right, Lotsa. I just built this in TM1 10.2.2 FP1 (10.2.20100.123), and it works as intended. I think this one can be chalked up to a bug in EP_explorer's version (10.1.1 based on profile). At the risk of being accused of being an IBM support sleeper agent: upgrade to latest version.

1.gif (17.24 KiB) Viewed 10355 times

[blackhawk]

Well, you got my curiosity up, so I checked it out on my version (10.2.2) and it seems to work fine.

Screenshot.png (17.89 KiB) Viewed 10354 times

[BrianL]

I just checked my copy of 10.1.1 fp2 and it seems to work fine there too.

[rmackenzie]

2/ Limit the area to only the relevant N or S area

Numb_Str1

Code: Select all

['Numb']  = N: DB('Numb_str', !Numbers, !Numb_Str);
['Strin']  = S: DB('Numb_str', !Numbers, !Numb_Str);

IMO this is the correct approach although it's going to be a problem in a moving dimension where you aren't sure what new string elements have been added. I've seen a problem where there seems to be confusion in the results where S: rules at the leaf level of the cube not calculating when there was an N: rule applying to the same intersection. It's probably always worth it to try to be specific as possible on the left-hand side of the rule.

[EP_explorer]

You know

Code: Select all

SKIPCHECK;
['Numb' ]  = N: DB('Numb_Str1', !Numbers, !Numb_Str);
['Strin' ]  = S: DB('Numb_Str1', !Numbers, !Numb_Str);

works

Also I check in 10.2.1 and

Code: Select all

SKIPCHECK;
[ ]  = N: DB('Numb_str1', !Numbers, !Numb_st);
[ ] = S: DB('Numb_str1', !Numbers, !Numb_st);

works as well

[rmackenzie]

Yep, both ways ways are syntactically OK but sometimes the latter stuffs up. Its going to depend on all the other rules and interlinking cubes and so forth. Its still worthwhile keeping the hand side as tight as possible.

[jim wood]

Matt, (& Tom, Jim)... look at the cubes. 2D with all leaf cells. It can't be a feeding issue because feeding drives consolidation of rule calculated values, nothing else. When querying a single cell the value should still be returned regardless of whether a cell is fed or not. Besides strings don't consolidate, the one and only reason to feed a string rule is for it to display in a zero suppressed view.

I only asked if he was feeding or skipcheck switched to try and narrow the issue down. I didn't say that feeding was the issue, but hey ho.