This question already has answers here:
MATLAB generate random numbers
(5 answers)
Closed 6 years ago.
I am trying to generate random numbers from 0.1 - 0.7.
My current code is close to what I need, but is giving me numbers lower than 0.1:
frameDur1 = roundn((((7)*rand(1))/10), -2);
If you have suggestions on another/easier function I could use, that would be appreciated as well.
Thanks in advance!
*Don't believe this question is a duplicate, but thanks to Ali Rokni for the answer.
rand generate uniformly distributed random numbers between (0,1).
Your range size is
0.7 - 0.1 = 0.6 % max - min
First you should change the range to (0, 0.6). And then you add the minimum for changing the offset.
Therefore ultimately you have
0.1 + (0.7 - 0.1) * rand
Generally speaking assuming your desired range is (min, max)
min + (max - min) * rand
Related
This question already has answers here:
Draw random numbers from pre-specified probability mass function in Matlab
(1 answer)
Generate random number with given probability matlab
(7 answers)
Closed 6 months ago.
The community reviewed whether to reopen this question 6 months ago and left it closed:
Original close reason(s) were not resolved
I need to generate 5 integer number which must be from a given set of numbers {1,2,4,8,16}.
I need different values to have different probabilities of generating eg.
0.10 chance of 1
0.15 chance of 2
0.30 chance of 4
0.25 chance of 8
0.20 chance of 16
How can I do this in Matlab?
You can simply draw a random number between 0 and 1. Then assign each interval one of your numberset. E.g.: random number is 0.12 -> your number will be 2.
The first 0.0 to 0.1 will be therefor 1, 0.1 to 0.15 will be 2 and so on...
I'm currently evaluating the performance of several modulations in 5G NR for various SNR values. In this situation, it's more important to acquire data from the -17 to -5 SNR interval.
And as such, I'm trying to generate a exponentially incremented SNR vector from -17 to 11, but I am unable to think of any 'proper' solution to this problem.
Example pretended growth
Its mostly a mathematical problem, sorry if it's not a proper question for stack overflow.
Thanks in advance for any help provided.
Here is an example to generate a an exponential sequence within a range. The value num_values specifies the number of values within the sequence. The sequence is initially generated with a range >= 1 and then afterwards scaled to the negative range as the log of a negative value is complex.
num_values = 100;
min_value = -17;
max_value = 11;
value_range = max_value - min_value;
sequence = exp(linspace(log(1),log(value_range+1),100)) + (min_value - 1);
This generates:
This question already has answers here:
Why is 24.0000 not equal to 24.0000 in MATLAB?
(6 answers)
Closed 7 years ago.
I've written the following code*:
function val = newton_backward_difference_interpolation(x,y,z)
% sample input : newton_backward_difference_interpolation([0.70 0.72 0.74 0.76 0.78 0.80 0.82 0.84 086 0.88],[0.8423 0.8771 0.9131 0.9505 0.9893 1.0296 1.0717 1.1156 1.1616 1.2097],0.71)
% sample output:
% X-Input must be equidistant
% -1.1102e-16
n=numel(x);% number of elements in x (which is also equal to number of elements in y)
h=x(2)-x(1);% the constant difference
%error=1e-5;% the computer error in calculating the differences [It was workaround where I took abs(h-h1)>=error]
if n>=3% if total elements are more than 3, then we check if they are equidistant
for i=3:n
h1=x(i)-x(i-1);
if (h1~=h)
disp('X-Input must be equidistant');
disp(h1-h);
return;
end
end
end
...
I also wrote a function for calculating inverse of a matrix** where this:
a=[3 2 -5;1 -3 2;5 -1 4];disp(a^(-1)-inverse(a));
displays this:
1.0e-16 *
0 -0.2082 0.2776
0 0.5551 0
0 0.2776 0
Why is there a small difference of 1e-16 occuring? Am I right in saying that this is because computer calculations (especially divisions are not exact)? Even if they are inexact, why does a^(-1) provide more accurate/exact solution (Sorry If this question is not programming related in your view.)
Can this be avoided/removed? How?
*for newton backward difference interpolation: (whole code at this place), the expected output is 0.85953 or something near that.
**using Gauss-Jordan Elimination: (whole code at this place)
That's in the nature of floating point calculations. There habe been many questions about this topic here already.
E.g.
Floating point inaccuracy examples
What range of numbers can be represented in a 16-, 32- and 64-bit IEEE-754 systems?
https://www.quora.com/Why-is-0-1+0-2-not-equal-to-0-3-in-most-programming-languages
The problem is that non-integer numbers in most cases have no exact representation by a 64bit double or 32bit float, not even in a 10000bit floating point value if that existed.
0.5, 0.25 and all powers of 2 (also those with negative exponents, 0.5 is 2^-1) can be stored exactly, and many others as well. Floating point numbers are saved as 3 separate parts: sign (1bit), mantissa (the 'number') and exponent for the base 2. Every possible combination of mantissa and exponent will result in a precise value, e.g. 0.5 has mantissa 'value' of 1 and exponent -1. the exact formula is
number = (sign ? -1:1) * 2^(exponent) * 1.(mantissa bits)
from
http://www.cprogramming.com/tutorial/floating_point/understanding_floating_point_representation.html
Try this formula and you'll see for example that you can't create a precise 0.1
This question already has answers here:
Why is 24.0000 not equal to 24.0000 in MATLAB?
(6 answers)
Closed 7 years ago.
I have a question about the precision in Matlab. I searched the questions here and they mention that there are precision problems when using very large or very small numbers and other posts looking at the comparison of numbers. My case is a bit different
I do not have that, my numbers have only 4 decimal places and I want them to add up to one.
Example:
Initial data:
aeb =
0.231215677537590 0.470472652172102 0.203009018534716
0.087759104877338 0.007588684370711
Then I rounded it to get 4 decimals:
aeb = round(aeb*10000)/10000
0.231200000000000 0.470500000000000 0.203000000000000
0.087800000000000 0.007600000000000
Then I identify the largest number and replace it by the difference with one
[~, idx]=max(aeb);
aeb(idx)=0;
aeb(idx)= 1 - sum(aeb);
But when I then do:
1 - sum(aeb)
1.110223024625157e-16
Does anyone know how I can make them add to one ? I just want 3-5 decimal places.
Their sum is within machine epsilon of the number one. The short answer is that any difference that small is indistinguishable from zero.
A practical point to be aware of....
In a lot of computing contexts, you don't want to test for equality, you want to test if the difference is within a certain tolerance. Eg.
abs(x - y) < tol
This question already has answers here:
Is this a Matlab bug? Do you have the same issue? [duplicate]
(3 answers)
Closed 9 years ago.
I tried to compile the following code.
x = 0
while x <= 1
x = x+0.02
end
The last value of x that I should get is equal to 1.02 (which make a false condition in while loop)
However, I am very wondered that I always got the last value of x equal to 1 and the while loop is stopped. I don't know what's wrong with my code.
Could anyone please help me find out?
0.02 cannot be represented exactly in a floating point binary number (double), so you'll get some rounding errors. The result is that you don't reach one, but a number which is slighly larget than one.
Try to append disp(x-1) after your code, to see that x is not exactly 1.
This site shows how 0.02 is represented in IEEE754 double precision floating point: http://www.binaryconvert.com/result_double.html?decimal=048046048050
The essential thing here is that it is a little bit larger than 0.02
One way to solve this would be to use an integer loop variable. It's still of type double, but it only has integer values, which don't have rounding issues unless you use very large numbers (>=2^56?)
for n=0:100
x = n/100;
end
Try format long before running you will get this:
x = 0.920000000000000
x = 0.940000000000001
x = 0.960000000000001
x = 0.980000000000001
x = 1.000000000000000
Note the 1 at the very end. 0.02 cannot be represented exactly with floating point arithmetic. So although it looks like 1 when you compare it, it is actually larger so it comes up as false and exists the loop.