randn function with so many digits or huge numbers

Hallo my question is about generating normal distributed random numbers with randn function of MATLAB, e.g.

    x=25.589665545.*(1+0*randn(100,1));
std(x)
ans =
1.7853e-014

or with huge numbers :

y=10^25.*(1+0*randn(10000,1));
  std(y) 
ans =1.0631e+012

is that not strange? to be sure there are some other ways to generate array with constant numbers, but I see this when I want to generate variables with different deviations, for any command pthanks in advance

Answer 1

[Geoff Hayes]

Metin - the result is not strange for the first example, since your vector of 100 elements is all ones (due to the 0*randn) and once multiplied by the scalars, then all 100 elements will be 25.589665545…and so the standard deviation will be 0 (or close to it).

The second example is odd - I would expect the same result as the first since all numbers in the array are identical and so the standard deviation of that vector should (once again) be zero or close to it. And it isn't! Running that on my version of MATLAB, I get the same result as yours. Note that this may be an example of arithmetic overflow. If I do:

std(y(1:33));

the result is zero (as expected). If I increase this to

std(y(1:34));

the answer is 2179778447.36383. Which is unexpected since the first 34 elements are identical. Shifting the standard deviation calculation to:

std(y(2:34));

once again returns a zero. So there isn't a problem with y(34) and it seems that the standard deviation of any 33 elements is fine - it is just once you add one or more to that list, then the overflow occurs. See standard deviation equation used in MATLAB for details.

Geoff

[James Tursa]

The 2nd example is not odd at all ... it is essentially the same as the first. See Sean's explanation. It is the eps of the numbers you are working with that is relevant here, not how close the numbers are to 0 in an absolute sense.

[Geoff Hayes]

I think what Metin was asking about is why, if you have two vectors each with their own set of identical numbers, is the standard deviation of one vector close to zero and the standard deviation of the second vector 1063057559966.89. The standard deviation of 33 elements from the second vector is 0, but as soon as you add a 34th element, then the standard deviation blows up.

[James Tursa]

Again, "close to zero" is not the correct measure here. It is how they measure in relation to eps of the numbers in question that is important. E.g.,

>> x=25.589665545.*(1+0*randn(10000,1));
>> std(x)
ans =
  3.6097e-012
>> std(x)/eps(x(1))
ans =
  1.0161e+003

>> y=10^25.*(1+0*randn(10000,1));
>> std(y)
ans =
  1.0631e+012
>> std(y)/eps(y(1))
ans =
  495.0248

So in both cases the std was about 3 orders of magnitude larger than the eps of the individual numbers. I would say this behavior is pretty close to being the same between both examples. As to why the std for a partial array is 0 until suddenly non-zero ("blows up"), that is just an artifact of when the floating point arithmetic errors for the sum build up to the point that the x-bar calculation no longer matches the individual numbers exactly. That will depend on what the trailing bit pattern of the individual numbers are (how many 0's are at the end). But, regardless, the large "blow up" number you refer to is much larger than zero, sure, but not much larger than eps of the numbers in the array ... same as the first example. E.g.,

>> std(y(1:33))
ans =
     0
>> std(y(1:34))
ans =
    2.179778447363826e+009
>> std(y(1:34))/eps(y(1))
ans =
   1.01503843784510

[Metin]

Thanks for the answers Wolski and Turs now it become more clear

Answer 2

[Sean de Wolski]

Not strange at all!

(1+0*randn(10,1))

Note the zero times randn - all of those components are zero. The very small standard deviation is pretty close to the eps(x) so it's just roundoff error in the calculation of x.

[Sean de Wolski]

Oh and if you want to grow an array of identical values

zeros(10,1)
ones(10,1)

[Metin]

I now zeros and ones, my question why std of

 std(1.365.*(1+0*randn(48,1)))

ans =

4.4879e-016

is not zero?

[Sean de Wolski]

round off error in the floating point calculations of standard deviation.

[Sean de Wolski]

http://www.mathworks.com/help/releases/R2014a/matlab/matlab_prog/floating-point-numbers.html#f2-98690

And the next section too:

http://www.mathworks.com/help/releases/R2014a/matlab/matlab_prog/floating-point-numbers.html#bqxyrhp