Using Rand(Random) Function

[Venki@1688]

Hi all,

I want to perform a calcualtion based on the Random numbers generated using Rand function.. The following is the requirement,

I have a Cube which contains 2 dimensions,

(i) Cases - contains 100 elements case1...case100
(ii) Values - contains Random Values, B,C,D & E as its elements

The Rule i have written

Random Values = Rand;
C = B * Random Values ;
E = D * Random Values ;

The problem is that whenever i 'Recalculate' the values for the Random Values element against elements in Case dimension is 'Changing'(coz of Random function), but the Values of C is not changing based on the updated 'Random Values'.
Also 'Random Values' used for calculating C and E itself is different. How can it be sorted out ?

Need help on this.

[declanr]

Can't say I have ever used the rand function but a rule is dynamic so everytime it is interacted with it will recalc what it is doing and that means re-initiating the Rand function.

If you want to generate a random value and then keep said value; you're probably going to need to go down the TI route rather than a rule.

[Venki@1688]

Here are the Screenshots , you can see i have assigned the element 'RandV' Random function and the other elements say is the product of 'RandV' and 1

Eventhough i am multiplying by 1 , all the values are not same. This is where i face the issue.

I hope the issue is defined clearly.

Thanks in advance.

[declanr]

Venki,

I think you are slightly missing the point of rules.

Where you have ['RandV'] =N: Rand; that is calculating it for every case element separately and the random number generated will be different for each one.

Like I said earlier you should probably go down the TI route but if you wanted to do that through a rule I suppose you could do it by having a consolidated element called 'All Cases'.

['RandV']=
If ( Ellev ( 'Cases',!Cases)=1, RAND ,
If ( Ellev ( 'Cases',!Cases) = 0, DB('test', elpar ( 'cases',!cases,1),'RandV'), Continue ) );

The above is very generic and you will need to change it a bit but based on the assumption that your cases dimension only has 2 levels; the "N" level and 1 element consolidating all of them.
It calculates a Random number for the consolidated element and then all the N-level elements below that will equal that number.


Edit - A cleaner way to do this would probably be calculating the random number within a control cube and then dragging that across.

[lotsaram]

Interesting. It would appear that RandV is being re-evaluated when referenced from Overhead and Profit, which you are quite right is not what should happen! Once RandV is evaluated the value should stay fixed until the calculation cache of the cube is cleared by data entry.

The exercise you're doing seems entirely hypothetical and I have never had any cause to use RAND in any TM1 model but nonetheless this does look like a bug to me.

[declanr]

Ah I see, I mis-read the issue and thought you were wanting each case to be the same random value.

I'm not sure it is a bug though, as I understand it when you ask TM1 to calculate a value in rule it will re-evaluate every calculation which that calculation is based on. So although it is quite annoying that it doesn't evaluate in the order you are wanting it to, I'm not sure that would constitute a bug?

[lotsaram]

... as I understand it when you ask TM1 to calculate a value in rule it will re-evaluate every calculation which that calculation is based on. So although it is quite annoying that it doesn't evaluate in the order you are wanting it to, I'm not sure that would constitute a bug?

That's not my understanding which is the first time the calc engine is asked to evaluate an N rule it will be evaluated as per the rule and the value will be stored in the calculation cache without going back to the rule. On subsequent retrievals of the same cell the value will be retrieved from the cache. This should be what happens until such time as the cache is cleared which would happen either via data entry in the cube or a change somewhere else in the model that is linked via cube dependency.

Maybe as all lines are part of the same view the whole retrieval counts as 1 go? I'd be interested to see if from a fresh start the view contained only RandV and then the other measures were introduced what would happen.

[declanr]

declanr wrote:
... as I understand it when you ask TM1 to calculate a value in rule it will re-evaluate every calculation which that calculation is based on. So although it is quite annoying that it doesn't evaluate in the order you are wanting it to, I'm not sure that would constitute a bug?
That's not my understanding which is the first time the calc engine is asked to evaluate an N rule it will be evaluated as per the rule and the value will be stored in the calculation cache without going back to the rule. On subsequent retrievals of the same cell the value will be retrieved from the cache. This should be what happens until such time as the cache is cleared which would happen either via data entry in the cube or a change somewhere else in the model that is linked via cube dependency.

Sorry I am having a blond day obviously.

Maybe as all lines are part of the same view the whole retrieval counts as 1 go? I'd be interested to see if from a fresh start the view contained only RandV and then the other measures were introduced what would happen.

A similar thought had entered my head so I did a quick test to see the results:
1/ Both values calc'd at the same time = no match
2/ First value calc'd with second value not visible = match
3/ Second value calc'd with first value not visible = no match

Edit - to clarify "First Value" is the "Rand" value whereas "Second Value" simply equals "First Value".

[Duncan P]

it will be evaluated as per the rule and the value will be stored in the calculation cache without going back to the rule

Whether a calculated value is stored in the cache depends on whether the evaluation of it took more than CalculationThresholdForStorage (http://publib.boulder.ibm.com/infocente ... orage.html) steps. If you set this parameter to 1 in TM1S.CFG then your calculations will match the RandV. However your memory use will probably be higher as all calculated values will the stored, instead of only the expensive ones. Unfortunately this parameter applies uniformly across the whole server.

[lotsaram]

It's great when a mystery get's solved!

[Venki@1688]

I thank you all for providing me more insight into TM1.
Actually i have 1000 elements in the Cases dimension. My expectation was to create to get 1000 random values(one for each element) and use in a particular Monte Carlo simulation.

http://www.vertex42.com/ExcelArticles/m ... ecast.html

With the help of this 1000 values i get an option to calculate random values for Profit etc.. thereby simulating that model.

[lotsaram]

I thank you all for providing me more insight into TM1.
Actually i have 1000 elements in the Cases dimension. My expectation was to create to get 1000 random values(one for each element) and use in a particular Monte Carlo simulation.

http://www.vertex42.com/ExcelArticles/m ... ecast.html

With the help of this 1000 values i get an option to calculate random values for Profit etc.. thereby simulating that model.

Always good to have the additional information at the outset. If you want to do a Monte Carlo simulation then fully or at least partially utilizing TI I would think would give you a better solution anyway and avoid this issue.

[Venki@1688]

If i have to do this using TI should i go for populating the cube with the help of scripts and then make use of the data ?
but i have a concern in doing so, i want the different set of random values to get generated whenever the cube is recalculated.
If i do it by TI, i would have to run the process whenever i want the new set of values. Can you help me how can it be achieved using TI ?

Thanks

[Venki@1688]

When i set CalculationThresholdForStorage = 1 in tm1s.cfg, the same values are used for calculation of both the components(Proft & overhead) but the random values are not generated everytime the cube is recalculated. It may be beacuse it keeps the same value till the data cache is cleared(happens when only the data server is shutdown). If i don't set the parameter the random values are generated everytime the cube is recalculated.

[Duncan P]

This is why using TI is a better option in that you have complete control over when the numbers are generated.

You talk of the cube being recalculated but that is not really what happens. I presume that you are pressing the recalculate button in the cube viewer or some similar mechanism. This recalculates the view, not the cube. In that recalculation of the view it is still reading from the same calculation cache, which unless it is invalidated by data-entry still contains the same values. If you want to clear the cache then you need to change any value in the cube, or in any cube that feeds into it.

[BariAbdul]

Something more about random function ,Which is not random

https://everanalytics.wordpress.com/201 ... after-all/

[bgregs]

I apologize in advance for necro-ing a very, very old thread, but I felt the need to clear the air on how TM1 implements random numbers. The article referenced in the previous post (everanalytics) misses the entire point of the RAND implementation, and quite frankly is establishing the obvious truth about uniform deviate random number generators. For anyone who is already aware of what I am about to cover, I apologize. For the others, let's take a peek under the hood.

The type of RAND implementation that TM1 uses (judged by its obvious maximum number of return values) is called
a linear congruential generator. These are the most common system-supplied generators and operate as follows (please excuse my lack of formatting):

I(j+1) = aI(j) + C (mod m)

The standard ANSI C implementation looks like this:

Code: Select all

unsigned long next = 1;

int rand(void)
{
        next = next * 1103515245 + 12345;
        return (unsigned int)(next/65536) % 32768;
}

void srand(unsigned int seed)
{
        next = seed;
}

Notice anything familiar about that? Yep, that's our magic 65536 integer. What happens is that when the TM1 server starts, a "seed" is generated and will be supplied to "next" in the function above. Given the above formula, we would expect that 65536 would be the repeating point. I won't get into the weeds of this too much, but the rest of the calculation should be pretty obvious.

There are recommended standards for what to make the starting point integers for these types of functions, but historically IBM has used the following in its mainframe RANDU function:

a = 65539
m = 2^31

This is a well-documented example of HOW NOT to implement a random number generator, but it appears TM1 has picked it up anyway. Not even that, but we appear to have the EXACT default rand function from ANSI C. To add insult to injury, the ANSI committee calls the C implementation an "example", implying that it should probably be updated before being used..... Needless to say, we see how that went.

Hopefully that helps clear up what's happening. It's important to remember that computers are exact machines, and that there isn't really such a thing as a "random" number. The official term for this would be "pseudo-random".

To cite my sources: "Numerical Recipes in C: Second Edition", because the authors do a much better job of summarizing the ideas than I would.

EDIT:

Upon further testing, it appears that TM1 doesn't even use the ANSI C standard, and instead more closely resembles the old RANDU function:

I = a*I % m

Notice how there is no "c" increment variable present that is found in most other implementations. This, and poor initial variable decisions, would produce the repeating sequence (which I verified with a sample C program).

In order to produce better quality pseudo-random numbers, the following TI code can be implemented:

Code: Select all

nSeed = 1;

i = 1;
while (i < 70000);
        nA = (1103515245 * nSeed) + 12345;
        nB = MOD((nA / 65536), 32768);
        nSeed = nB;

        asciioutput('test123.csv', NumberToString(nB));
        i = i + 1;
end;

Obviously, the above code is a sample and the seed would need to be stored outside the context of the TI, but that code snippet will produce 70000 results without repeating numbers. It is also written to ANSI C standard, which is at least a guideline to base it off of for the future.

Whew, I dug into that more than I thought I would, but hopefully it's useful to someone!