effiecency of rule calc. If statment vs seperate area blocks

[shockwave]

Hi Guys,

Building a rule and not sure whether this makes a diff, but dont think it really does but wanted to see whether I am wrong and needed an expert opion on this one. I want to know whether or not having a statments in 1 block makes it more effiecnet when a rule is calulating. Is "THIS" statement quicker than "or that" statement in terms of the load it will put on the the server??????? Can someone tell me whether or not writing it either way will make any differencce on calculation time. Comparison statments below:

# this #

['COS_AAPT_N','Data',{'e2e Reported','Current Forecast'},{'2009','2010','2011'},'e2e Financial']=N:
if(dimix('e2e version',!e2e version)=dimix('e2e version','e2e Reported'),
DB('reportingaapt','TAIL_GRP','All Trading Partners',!coo_ausext,'COS_AAPT','DATA','All Indicators','All Access Methods',
if(dimix('year',!year)=dimix('year','2009'),'2009',if(dimix('year',!year)=dimix('year','2010'),'2010',if(dimix('year',!year)=dimix('year','2011'),'2011',stet))),
!Month,
'Reported',
'Financial'),
if(dimix('e2e version',!e2e version)=dimix('e2e version','Current Forecast'),
DB('reportingaapt','TAIL_GRP','All Trading Partners',!coo_ausext,'COS_AAPT','DATA','All Indicators','All Access Methods',
if(dimix('year',!year)=dimix('year','2009'),'2009',if(dimix('year',!year)=dimix('year','2010'),'2010',if(dimix('year',!year)=dimix('year','2011'),'2011',stet))),
!Month,
'Sep Forecast',
'Financial'),
Continue))
;


# or that #

['COS_AAPT_N','Data','e2e Reported',{'2009','2010','2011'},'e2e Financial']=N:
DB('reportingaapt','TAIL_GRP','All Trading Partners',!coo_ausext,'COS_AAPT','DATA','All Indicators','All Access Methods',
if(dimix('year',!year)=dimix('year','2009'),'2009',if(dimix('year',!year)=dimix('year','2010'),'2010',if(dimix('year',!year)=dimix('year','2011'),'2011',stet))),
!Month,
'Reported',
'Financial');


['COS_AAPT_N','Data','Current Forecast',{'2009','2010','2011'},'e2e Financial']=N:
DB('reportingaapt','TAIL_GRP','All Trading Partners',!coo_ausext,'COS_AAPT','DATA','All Indicators','All Access Methods',
if(dimix('year',!year)=dimix('year','2009'),'2009',if(dimix('year',!year)=dimix('year','2010'),'2010',if(dimix('year',!year)=dimix('year','2011'),'2011',stet))),
!Month,
'Sep Forecast',
'Financial');


Thanks
Shock

[lotsaram]

To answer your question the construction with a tighter area statement and no conditional logic in the rule calculation would be expected to calculate faster with less overhead. (Although for a pretty simple rule the difference may be slight). Generally it would be better practice to use area statements and area definition precedence to handle the conditional logic of what rule calculation applies to what rule area and keep the rule calculations themselves as simple as possible. Obviously sometimes conditional logic even very complex conditional logic within a rule is necessary, but where it is possible to avoid via tighter area statements it should be.

A couple of additional suggestions for you:
I'm not sure what you are trying to achieve with the If(!Year = this, then, else, that) statement but it seems to me that you would be better off leaving this out and just having !Year since you should either have !Year or '' in place of Stet anyway. (Stet should be used in the sense of "no rule applies" for a cube area, it has no meaning or is incorrect in the context you have used it.)
Consider using a lookup cube to hold values for "current year", "current month", "last month", "forecast year", etc. rather than hard coding these concepts/values within the rule code. It will make your rules much more flexible and easy to maintain.

[shockwave]

Thanks for your advice lotsaram. Will try to avoid the nested if statments where i can. Thanks for curing my curiosity on this one, b4 I go to rewite my statements.
Cheers

Shock

[LoadzaGrunt]

With the rules that you've posted, I think that the timing difference in their evaluation would be negligible. The second set of rules is better though. I would use a subset on the left hand side (your {'e2e Reported','Current Forecast'}) only if the right hand side applied to both elements. In your case, you force yourself into using an IF statement as you want to treat the two elements differently.

Also, there is no need for this:

Code: Select all

if(dimix('year',!year)=dimix('year','2009'),'2009', ....

You could just have the rule like this:

Code: Select all

['COS_AAPT_N','Data','e2e Reported',{'2009','2010','2011'},'e2e Financial']=N:
DB('reportingaapt','TAIL_GRP','All Trading Partners',!coo_ausext,'COS_AAPT','DATA','All Indicators','All Access Methods',
!year,
!Month,
'Reported',
'Financial');

Often writing a clearer easier-to-read rule allows for easier system maintenance down the track. Not always possible ....

HTH

[shockwave]

Hi,

Just quickly... won't the !year calculate all years? in the Db('reportingaapt'......). The reason I dimix the years was to only have the $ calculate against those years in question ( i thought i needed to specify exactly what elements I wanted to calulate against). Are you saying that the LHS will only find whatever is on the right hand side if those elements exists, and the rule will ignore those other elements ie being 2012, 2013??? 0r are you saying the dimix statement though it is correct is neglible since the calculation time will be neg? ie just use !year?

Thanks

Shock

[Steve Rowe]

Hi Shock,

The !Year values in the RHS of the rule can only ever be what you specify on the LHS of the rule so when {'2009','2010','2011'} is 2009 then the RHS will be 2009 and so you only need to use !year on the RHS.

HTH

Cheers,

[shockwave]

Thanks steve. Always thought I had to specify on the RHS. So as long as I get it right on the LHS and the elements exists on the RHS then all is good. For whatever reason I thought that I might need to specify on the RHS cause of some efficency gain in calc time etc? Obviously you need to specify on the RHS if the elements need a home to be put against if say for args dimensions are different on both the RHS and LHS.

Thanks again!

Shock

[Kyro]

Just another quick side-note:

if(dimix('year',!year)=dimix('year','2009'),'2009', ....

The primary reason to compare the dimix of two elements is to test where case sensitivity may be involved. So since the above is all numeric it is ok to do:

Code: Select all

if( !year @= '2009' ,

The above was making TM1 lookup elements unnecessarily - Thought I'd mention since the thread is about efficiency
I'm guessing you tried this first, came across the 'logical expression' error and found dimix as an alternative.

[shockwave]

Yep, bingo thats what happened. However looking at the rest of the post my whole dimix argument is kind of redundant where I only need to really specify on the LHS unless there is the real need to do some logic testing on the RHS. I guess this also applies to feeders as well, since the calc is just reflection of the feeder.

Thanks for you input.

Cheers

Shock

[lotsaram]

The primary reason to compare the dimix of two elements is to test where case sensitivity may be involved.

I agree with your comment that the Dimix statement in Shock's rule is unnecessary and I think I made that point originally (in fact the whole IF statement around the Dimix is unnecessary). But the statement quoted above isn't correct. Element information functions are not case sensitive or space sensitive just as element names are not case sensitive or space sensitive. If you need convincing see the attached example.

CaseInsensitive.JPG (43.94 KiB) Viewed 7629 times

[Kyro]

Uh, yup. Although I didn't realize that raw String comparison was not case sensitive , that's a little dangerous not to know, or is it just dangerous. Where does that leave you if your datasource has a case sensitive flag column?

[Alan Kirk]

Uh, yup. Although I didn't realize that raw String comparison was not case sensitive , that's a little dangerous not to know, or is it just dangerous. Where does that leave you if your datasource has a case sensitive flag column?

If it's a single character flag you can always use the Code function and compare to the ASCII code value(s)... alternatively the Scan function is case sensitive, and that could be put to use for that purpose.