Sorry, no: Both of your programs lead to an average value
of 0.5 for the first variable, I think.

I suggest:
Public Function TRAT() As Variant
Dim vTemp As Variant
Dim i1, i2, i3 As Integer

Application.Volatile
ReDim vTemp(0 To 2)

i1 = Int(Rnd * 3)
i2 = (i1 + 1) Mod 3
i3 = (i1 + 2) Mod 3
vTemp(i1) = Round(Rnd, 15)
vTemp(i2) = Round(Rnd * (1 - vTemp(i1)), 15)
vTemp(i3) = 1 - vTemp(i1) - vTemp(i2)
TRAT = Application.Transpose(vTemp)
End Function

Kind regards,
sulprobil

how about something like:

Public Function ThreeRandsAddToOne() As Variant
Dim vTemp As Variant
Dim sum as Double
Application.Volatile
ReDim vTemp(0 To 2)
vTemp(0) = Round(Rnd, 15)
vTemp(1) = Round(Rnd, 15)
vTemp(2) = Round(Rnd, 15)
For i = 0 To 2
Sum = Sum + vTemp(i)
Next
vTemp(0) = Round(vTemp(0) / Sum, 15)
vTemp(1) = Round(vTemp(1) / Sum, 15)
vTemp(2) = Round(1 - (vTemp(0) + vTemp(1)), 15)
ThreeRandsAddToOne = Application.Transpose(vTemp)
End Function

--
Regards,
Tom Ogilvy

"sulprobil" wrote in message
...
Sorry, no: Both of your programs lead to an average value
of 0.5 for the first variable, I think.

I suggest:
Public Function TRAT() As Variant
Dim vTemp As Variant
Dim i1, i2, i3 As Integer

Application.Volatile
ReDim vTemp(0 To 2)

i1 = Int(Rnd * 3)
i2 = (i1 + 1) Mod 3
i3 = (i1 + 2) Mod 3
vTemp(i1) = Round(Rnd, 15)
vTemp(i2) = Round(Rnd * (1 - vTemp(i1)), 15)
vTemp(i3) = 1 - vTemp(i1) - vTemp(i2)
TRAT = Application.Transpose(vTemp)
End Function

Kind regards,
sulprobil

Hmm, I think your solution would generate too many nearly
equal values (0.333, 0.333, 0.334 for example) and less
extreme values such as (0.95, 0.04, 0.01). But here we
have to ask the original poster, what he intends to
simulate, do you agree? :-)

Was fun.
sulprobil

No. Why would it generate nearly equal values? The distribution will be
uniform to the extent that RND's distribution is...

In article ,
"sulprobil" wrote:

Hmm, I think your solution would generate too many nearly
equal values (0.333, 0.333, 0.334 for example) and less
extreme values such as (0.95, 0.04, 0.01). But here we
have to ask the original poster, what he intends to
simulate, do you agree?

I suspect that would be the mode, because if one number is 1/3, then all
three would be 1/3. However, your presumption that that is incorrect is
flawed. If you expect to generate 3 random numbers that sum to 1 and the
distribution of all such numbers should be uniformly distributed (which
appears to be your expectation); that seems to where the faulty logic lies.
Once two numbers are generated, the third is not random. Similarly, once
the first in generated, the 2nd and 3rd are constrained. If I generated an
extreme number then I would have a high probability of generating two less
extreme numbers to go with it. The distribution of each element of the
array appears to be the same - normal like with a mode around 1/3.

Put up your solution and let's have a look at it.


--
Regards,
Tom Ogilvy

"sulprobil" wrote in message
...
Hmm, I think your solution would generate too many nearly
equal values (0.333, 0.333, 0.334 for example) and less
extreme values such as (0.95, 0.04, 0.01). But here we
have to ask the original poster, what he intends to
simulate, do you agree? :-)

Was fun.
sulprobil

Tom,

I do not think your solution is wrong. I think it produces
(relatively) more values in the [0.1,0.9]-intervall than
in (0,0.1) and (0.9,1), for example.

This is because if your algorithm creates a first extreme
value of 0.9999, for example, then a high likelihood
exists that it will be shifted into direction 0.5 due to
your sum- and 1/sum-calculation.

A quick simulation shows that my solution generates about
1% numbers < 0.01, 8% numbers < 0.1 and 14% numbers < 0.2;
where your algorithm generates about 0.5% numbers < 0.01,
3% numbers < 0.1 and 8% numbers < 0.2.

The stated problem introduced two restrictions (on all
three numbers, not the third or any other):
1. All numbers are 0.
2. All numbers sum to 1.

With my algorithm I try to simulate this problem
efficiently without introducing further restrictions or
making further assumptions.

Kind regards,
sulprobil
Reverse(moc.liborplus.www)

With my algorithm I try to simulate this problem
efficiently without introducing further restrictions or
making further assumptions

I believe I could make the same statement.

Your algorithm produces less than 15% of your numbers at .5 so naturally
you will have a higher percentage in the lower half of the numbers, but I am
not sure how that achieves all the above.

You stated:
I think it produces
(relatively) more values in the [0.1,0.9]-intervall than
in (0,0.1) and (0.9,1), for example.

which seems to be true for your algorithm as well, although your
distribution is decreasing exponential like from the left, so you have a
large amount in [0,0.1] from what I could see.

A quick simulation shows that my solution generates about
1% numbers < 0.01, 8% numbers < 0.1 and 14% numbers < 0.2;

A quick simulation for me showed
your solution generates about
4.1% numbers < 0.01, 25.4% numbers < 0.1 and 41% numbers < 0.2;

based on 10000 calls to your function (30000 numbers generated).

Public Function TRAT() As Variant
Dim vTemp As Variant
Dim i1, i2, i3 As Integer
Randomize
Application.Volatile
ReDim vTemp(0 To 2)

i1 = Int(Rnd * 3)
i2 = (i1 + 1) Mod 3
i3 = (i1 + 2) Mod 3
vTemp(i1) = Round(Rnd, 15)
vTemp(i2) = Round(Rnd * (1 - vTemp(i1)), 15)
vTemp(i3) = 1 - vTemp(i1) - vTemp(i2)
' TRAT = Application.Transpose(vTemp)
TRAT = vTemp
End Function

Sub Tester1()
For i = 1 To 10000
varr1 = TRAT
For j = LBound(varr1) To UBound(varr1)
If varr1(j) <= 0.1 Then
m = m + 1
ElseIf varr1(j) <= 0.9 Then
n = n + 1
Else
o = o + 1
End If
Next j
Next i
Range("C1") = m
Range("C2") = n
Range("C3") = o
End Sub
--
Regards,
Tom Ogilvy

"sulprobil" wrote in message
...
Tom,

I do not think your solution is wrong. I think it produces
(relatively) more values in the [0.1,0.9]-intervall than
in (0,0.1) and (0.9,1), for example.

This is because if your algorithm creates a first extreme
value of 0.9999, for example, then a high likelihood
exists that it will be shifted into direction 0.5 due to
your sum- and 1/sum-calculation.

A quick simulation shows that my solution generates about
1% numbers < 0.01, 8% numbers < 0.1 and 14% numbers < 0.2;
where your algorithm generates about 0.5% numbers < 0.01,
3% numbers < 0.1 and 8% numbers < 0.2.

The stated problem introduced two restrictions (on all
three numbers, not the third or any other):
1. All numbers are 0.
2. All numbers sum to 1.

With my algorithm I try to simulate this problem
efficiently without introducing further restrictions or
making further assumptions.

Kind regards,
sulprobil
Reverse(moc.liborplus.www)

I get the following distribution for 10,000 runs (example):

Likelihood(0,0.1) 0.2471 0.2615 0.2513 0.1087
0.1085 0.107
Likelihood(0.1,0.2) 0.1614 0.1578 0.1593 0.143
0.1407 0.1427
Likelihood(0.2,0.3) 0.1195 0.1276 0.1288 0.1761
0.1764 0.1821
Likelihood(0.3,0.4) 0.1114 0.1022 0.1045 0.2195
0.2294 0.2222
Likelihood(0.4,0.5) 0.0886 0.0905 0.0897 0.1849
0.1784 0.1829
Likelihood(0.5,0.6) 0.0701 0.0738 0.0705 0.0973
0.0926 0.0903
Likelihood(0.6,0.7) 0.0639 0.0602 0.0617 0.0409
0.0431 0.044
Likelihood(0.7,0.8) 0.0578 0.0521 0.0501 0.0175
0.0207 0.0205
Likelihood(0.8,0.9) 0.0443 0.0402 0.0465 0.0105
0.0084 0.0069
Likelihood(0.9,1) 0.0359 0.0341 0.0376 0.0016
0.0018 0.0014

First 3 numbers are produced by my algorithm, last 3 by
yours. You are right: my algorithm gets 25% numbers < 0.1
and 41% < 0.2. But numbers 0.5 are not below 15%, they
are about 26.5% (yours about 16.5%).

Now that's what I meant: We should ask the original poster
what he intends to simulate - your distribution is
concentrated in the (0.2,0.5)-intervall while mine is
decreasing strictly.

And please do not misunderstand me: I think my
distribution reflects the stated problem with given
restrictions in a canonic way while your distribution is
influenced substantially by the 1/sum-calculation.

Kind regards,
sulprobil

Yup. Misplaced parens:

Public Function ThreeRandsAddToOne() As Variant
Dim vTemp As Variant
Dim dTemp As Double
Dim nRnd As Long
Dim i As Long
Application.Volatile
ReDim vTemp(0 To 2)
vTemp(0) = Round(Rnd, 15)
vTemp(1) = Round(Rnd * (1 - vTemp(0)), 15)
vTemp(2) = 1 - (vTemp(0) + vTemp(1))
For i = UBound(vTemp) To 1 Step -1
nRnd = Int(Rnd * (i + 1))
dTemp = vTemp(nRnd)
vTemp(nRnd) = vTemp(i)
vTemp(i) = dTemp
Next i
ThreeRandsAddToOne = Application.Transpose(vTemp)
End Function


In article ,
"sulprobil" wrote:

Sorry, no: