TM1 Forum

How do I feed this rule? :

['dim1', 'dim2'] = 3;

nhavis wrote:How do I feed this rule? :

['dim1', 'dim2'] = 3;

Depends.

What other element(s) need to have a value for ['dim1', 'dim2'] to return a value?

That's always the key question. Answer that one, and you know where you need to feed from.

It's easier when the right hand side is a formula since typically the answer will be one of the elements that makes up that formula; in a Revenue = Sales * Yield rule, for example, it would normally be Sales since you'll only want an output when there's a sales value. (You'll probably have a yield even when there are no sales, but who cares about that value since it'll be 0 anyway?) It's less clear when the right hand side is a constant as you have here, but there should still be some "trigger" cell or combination which will be the logical feeder.

Alan Kirk wrote:

nhavis wrote:How do I feed this rule? :

['dim1', 'dim2'] = 3;

Depends.

What other element(s) need to have a value for ['dim1', 'dim2'] to return a value?

Sorry, I should have added (with due deference to John) that this presupposes that you need a feeder at all. If it's a small cube which is just used for lookup purposes (say, a cube which contains rates, which would be relevant if you're talking about constants) then you may be able to simply not use SkipCheck. In such a case, feeders become redundant.

However equally it would raise the question of whether you need the values in the cube to BE rule driven, or simply entered. I can't think of too many cases where you need a rule to be returning a constant value; a direct input into the cell (with security as needed) may well be a preferable approach.

These cells will always need to be fed as the constant will always be non-zero, ie. there are no 'trigger' cells from which to feed from.

So how can I feed these cells? Note that a rule driven cell does not necessarily have a calculation based on another cell, for example a rule could make use of the RAND, DATE, TIME functions without using another cell in which it would then feed from. As another example, ['dim1'] = COS('dim2') would need to be fed even when dim2's value was zero (as cos(0) = 1 and not non-zero).

So how can you feed these cells properly?

nhavis wrote:These cells will always need to be fed as the constant will always be non-zero, ie. there are no 'trigger' cells from which to feed from.

Which again begs the question of why on earth you're using rules to populate these cells instead of just populating the cells themselves with the constant numbers.

nhavis wrote:So how can I feed these cells? Note that a rule driven cell does not necessarily have a calculation based on another cell, for example a rule could make use of the RAND, DATE, TIME functions without using another cell in which it would then feed from. As another example, ['dim1'] = COS('dim2') would need to be fed even when dim2's value was zero (as cos(0) = 1 and not non-zero).

Nothing needs to be fed if you don't use skipcheck.

However if you insist, why not just populate a cell by punching a number directly into it, and feed your constant cells or your cos() function cells from THAT?

I suppose the only way then is to feed from a cell that is guaranteed to be defined.

nhavis wrote:I suppose the only way then is to feed from a cell that is guaranteed to be defined.

As a general rule, that would depend on how much of a fan of overfeeding you are. In the example that I gave earlier a user could feed from the Yield element (always defined) instead of the Sales element (only defined when there are sales), but it would result in a ridiculous number of Revenue cells (which would never have a value) being fed.

So for most users, most of the time, that would definitely be the wrong way to go about it.

However, in the sort of circumstances that you've referred to, the answer yould be yes... but again using rules to generate constants is a bad idea. It requires processing overhead that you really don't need to expend. If a value is a constant, it should be simply written into a cell, then (if necessary) locked off by security. In that way the server doesn't need to feed the calculation (which it still doesn't have to if you simply don't use SkipCheck), and it doesn't need to "calculate" the value every time someone reads it.

I think it would be impossible to overfeed a constant in the typical sense, as the cell always needs to be calculated. Though you would still be overfeeding in the sense that the feeder is still setting feeder flags from 1 to 1 again unnecessarily.

Alan Kirk wrote:However, in the sort of circumstances that you've referred to, the answer yould be yes... but again using rules to generate constants is a bad idea. It requires processing overhead that you really don't need to expend. If a value is a constant, it should be simply written into a cell, then (if necessary) locked off by security. In that way the server doesn't need to feed the calculation (which it still doesn't have to if you simply don't use SkipCheck), and it doesn't need to "calculate" the value every time someone reads it.

I think it would be impossible to overfeed a constant in the typical sense, as the cell always needs to be calculated. Though you would still be overfeeding in the sense that the feeder is still setting feeder flags from 1 to 1 again unnecessarily.

A better example would not simply be a constant, but a calculation not dependent on another cell. For example ['elem1'] = IF(TIME()='something', 3, 5); is a rule which is not dependent on another cell, still requires feeding, but cannot be entered manually.

nhavis wrote:I think it would be impossible to overfeed a constant in the typical sense, as the cell always needs to be calculated. Though you would still be overfeeding in the sense that the feeder is still setting feeder flags from 1 to 1 again unnecessarily.

I wasn't talking about feeding a constant rule. You made a general, unqualified statement that:

nhavis wrote:I suppose the only way then is to feed from a cell that is guaranteed to be defined.

This would be a bad principle to follow in general rule design. It may be a necessary evil if one is insistent on having a rule that returns a constant (unless one elects not to use SkipCheck, as I keep reiterating; not ALL rules need feeders), but the general principle of Rules design could be better expressed as "feed from a cell which has a value only when the calculation itself should have a value".

nhavis wrote:

Alan Kirk wrote:However, in the sort of circumstances that you've referred to, the answer yould be yes... but again using rules to generate constants is a bad idea. It requires processing overhead that you really don't need to expend. If a value is a constant, it should be simply written into a cell, then (if necessary) locked off by security. In that way the server doesn't need to feed the calculation (which it still doesn't have to if you simply don't use SkipCheck), and it doesn't need to "calculate" the value every time someone reads it.

I think it would be impossible to overfeed a constant in the typical sense, as the cell always needs to be calculated.

No, it doesn't. If it's a constant, nothing needs to be calculated. If it's a constant, then it should be a number sitting in a cell which the server can read directly, not a number that the server needs to look up rules calculations for. It's a waste of processing cycles, and means that your users will be getting slower results.

nhavis wrote: Though you would still be overfeeding in the sense that the feeder is still setting feeder flags from 1 to 1 again unnecessarily.

A better example would not simply be a constant, but a calculation not dependent on another cell. For example ['elem1'] = IF(TIME()='something', 3, 5); is a rule which is not dependent on another cell, still requires feeding, but cannot be entered manually.

And IS that what you're actually trying to do? Because that's somewhat different from what you initially described.

And the answer would still be the same... either feed from something that's guaranteed to have a value, or don't use skipcheck and don't bother feeding at all.

How do I feed this rule? :

['dim1', 'dim2'] = 3;

I probably would not set my system up with constants defined in the rule sheet. I put my constants in a 2d cube. This has 2 advantages, sometimes with version and period too.

1. I have something to feed with since I now have an input value driving the constant. The way you are doing it there is no natural feeder and as you say you need to pick an "always populated value" to feed it with, since you need to do this you may as well have the constant itself being the always populated value.
2. You can change the constant without saving the rules. Reducing save times and downtime for the user.

Cheers,