what is this code meaning?
k = round(Q/12. + Q/123.)-1;
I couldn't understand why that point(.) needed.
That code is from RSA code. Part of calculating coprime number.
The decimal point does not do anything here. It is probably the result of someone porting the code from another language with different data type conventions.
As hbaderts said, in Matlab the default numeric type is double precision; other numeric types must be explicitly set. You can test this yourself:
>> x = 123;
>> whos x
Name Size Bytes Class Attributes
x 1x1 8 double
You will often see the dot (.) preceding the division, multiplication, or power sign; there it means an elementwise operation.
Related
In the code below image index range only accept to deal with int16 however I can't find a proper explanation for this case. In the same code, you can notice if I change the data type to int8 for same value error will present.
K>> t2 = int8(t)
t2 =
int8
45
K>> I2 = flt_rot(t:end,:);
K>> I2 = flt_rot(t2:end,:);
Error using :
Colon operands must be in the range of the data type.
Why did this happen?
To understand this problem, first a little background:
MATLAB has a rather unique behavior with respect to numeric values of different types. Originally, MATLAB only used double-precision floating point values (double). At some point it became possible to store arrays of other types, but it was not possible to use those for much. It was not until MATALB 7.0 or so that arithmetic with non-doubles was possible (I'm a bit hazy exactly when that was introduced). And these operations are still a bit "awkward", if you will.
For one, MATLAB does not allow operations with mixed types:
>> int8(4)+int16(6)
Error using +
Integers can only be combined with integers of the same class, or scalar doubles.
Note that error message: "scalar doubles". The one exception to mixed types is that any operation is possible if one of the operands is a scalar double.
Another thing to note is that any operation with a non-double type and a double type results in values of the non-double type:
>> int8(4)+6
ans =
int8
10
The color operator (:) is no exception:
>> int8(4):6
ans =
1×3 int8 row vector
4 5 6
Finally, the last thing to know to understand this problem is that end is a function that returns a double scalar value (yes, it really is a function, albeit a very special one, see help end).
If you have an array flt_rot that is 200x300, end in the first index returns 200. That is, flt_rot(t2:end,:) is the same as flt_rot(t2:200,:). Since t2 is a int8 type:
>> t2=int8(45);
>> t2:200
Error using :
Colon operands must be in the range of the data type.
The solution to your problem is to not use numeric values of type other than double for anything except in large data sets where the amount of memory used matters. For indexing, using an integer is not going to give you any speedup over using doubles, but will give you lots of other problems. There is a reason that the default values are always doubles.
This will work:
I2 = flt_rot(double(t2):end,:);
I am trying to calculate some integrals that use very high power exponents. An example equation is:
(-exp(-(x+sqrt(p)).^2)+exp(-(x-sqrt(p)).^2)).^2 ...
./( exp(-(x+sqrt(p)).^2)+exp(-(x-sqrt(p)).^2)) ...
/ (2*sqrt(pi))
where p is constant (1000 being a typical value), and I need the integral for x=[-inf,inf]. If I use the integral function for numeric integration I get NaN as a result. I can avoid that if I set the limits of the integration to something like [-20,20] and a low p (<100), but ideally I need the full range.
I have also tried setting syms x and using int and vpa, but in this case vpa returns:
1.0 - 1.0*numeric::int((1125899906842624*(exp(-(x - 10*10^(1/2))^2) - exp(-(x + 10*10^(1/2))^2))^2)/(3991211251234741*(exp(-(x - 10*10^(1/2))^2) + exp(-(x + 10*10^(1/2))^2)))
without calculating a value. Again, if I set the limits of the integration to lower values I do get a result (also for low p), but I know that the result that I get is wrong – e.g., if x=[-100,100] and p=1000, the result is >1, which should be wrong as the equation should be asymptotic to 1 (or alternatively the codomain should be [0,1) ).
Am I doing something wrong with vpa or is there another way to calculate high precision values for my integrals?
First, you're doing something that makes solving symbolic problems more difficult and less accurate. The variable pi is a floating-point value, not an exact symbolic representation of the fundamental constant. In Matlab symbolic math code, you should always use sym('pi'). You should do the same for any other special numeric values, e.g., sqrt(sym('2')) and exp(sym('1')), you use or they will get converted to an approximate rational fraction by default (the source of strange large number you see in the code in your question). For further details, I recommend that you read through the documentation for the sym function.
Applying the above, here's a runnable example:
syms x;
p = 1000;
f = (-exp(-(x+sqrt(p)).^2)+exp(-(x-sqrt(p)).^2)).^2./(exp(-(x+sqrt(p)).^2)...
+exp(-(x-sqrt(p)).^2))/(2*sqrt(sym('pi')));
Now vpa(int(f,x,-100,100)) and vpa(int(f,x,-1e3,1e3)) return exactly 1.0 (to 32 digits of precision, see below).
Unfortunately, vpa(int(f,x,-Inf,Inf)), does not return an answer, but a call to the underlying MuPAD function numeric::int. As I explain in this answer, this is what can happen when int cannot obtain a result. Normally, it should try to evaluate the the integral numerically, but your function appears to be ill-defined at ±∞, resulting in divide by zero issues that the variable precision quadrature methods can't handle well. You can evaluate the integral at wider bounds by increasing the variable precision using the digits function (just remember to set digits back to the default of 32 when done). Setting digits(128) allowed me to evaluate vpa(int(f,x,-1e4,1e4)). You can also more efficiently evaluate your integral over a wider range via 2*vpa(int(f,x,0,1e4)) at lower effective digits settings.
If your goal is to see exactly how much less than one p = 1000 corresponds to, you can use something like vpa(1-2*int(f,x,0,1e4)). At digits(128), this returns
0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000086457415971094118490438229708839420392402555445545519907545198837816908450303280444030703989603548138797600750757834260181259102
Applying double to this shows that it is approximately 8.6e-89.
I want to use xor for my double numbers in matlab,but bitxor is only working for int numbers. Is there a function that could convert double to int in Matlab?
The functions You are looking for might be: int8(number), int16(number), uint32(number) Any of them will convert Double to an Integer, but You must pick the best one for the result You want to achieve. Remember that You cannot cast from Double to Integer without rounding the number.
If I understood You correcly, You could create a function that would simply remove the "comma" from the Double number by multiplying your starting value by 2^n and then casting it to Integer using any of the functions mentioned earlier, performing whatever you want and then returning comma to its original position by dividing the number by 2^n
Multiplying the starting value by 2^n is a hack that will decrease the rounding error.
The perfect value for n would be the number of digits after the comma if this number is relatively small.
Please also specify, why are You trying to do this? This doesn't seem to be the optimal solution.
You can just cast to an integer:
a = 1.003
int8(a)
ans =
1
That gives you an 8 bit signed integer, you can also get other size i.e. int16 or else unsigned i.e. uint8 depending on what you want to do
I'm trying to perform a bit shift right operation on a double value in MATLAB 2010b. It seems that in newer MATLAB versions, this can be done using bitsra(), e.g.:
y = double(128);
bitsra(y,3)
but this function is not available in older versions.
What is the best way to achieve this?
You can use the bitshift function, which is available from at least MATLAB 2009a. From the documentation
c = bitshift(a, k) returns the value of a shifted by k bits.
When k is positive, 0-valued bits are shifted in on the right.
When k is negative, and a is unsigned, or a signed and positive, 0-valued bits are shifted in on the left.
When k is negative and a is a signed and negative, 1-valued bits are shifted in on the left.
On MATLAB 2012b
>> bitsra(128, 3)
ans =
16
On MATLAB 2009a:
>> bitshift(128, -3)
ans =
16
Edit: bitshift works with any fixed-point data type, although the error message generated by calling bitshift(128.5, -3) would suggest that it requires integer values. So bitshift(128.5, -3), for example, will not work since 128.5 is, by default, a floating point double precision variable. From the documentation for bitshift you can use the fi function from the floating-point toolbox to create fixed-point numbers. So to work with fractions one could do something like
>> bitshift(fi(128.5), -3)
ans =
16.025
MATLAB does not satisfy matrix arithmetic for inverse, that is;
(ABC)-1 = C-1 * B-1 * A-1
in MATLAB,
if inv(A*B*C) == inv(C)*inv(B)*inv(A)
disp('satisfied')
end
It does not qualify. When I made it format long, I realized that there is difference in points, but it even does not satisfy when I make it format rat.
Why is that so?
Very likely a floating point error. Note that the format function affects only how numbers display, not how MATLAB computes or saves them. So setting it to rat won't help the inaccuracy.
I haven't tested, but you may try the Fractions Toolbox for exact rational number arithmetics, which should give an equality to above.
Consider this (MATLAB R2011a):
a = 1e10;
>> b = inv(a)*inv(a)
b =
1.0000e-020
>> c = inv(a*a)
c =
1.0000e-020
>> b==c
ans =
0
>> format hex
>> b
b =
3bc79ca10c924224
>> c
c =
3bc79ca10c924223
When MATLAB calculates the intermediate quantities inv(a), or a*a (whether a is a scalar or a matrix), it by default stores them as the closest double precision floating point number - which is not exact. So when these slightly inaccurate intermediate results are used in subsequent calculations, there will be round off error.
Instead of comparing floating point numbers for direct equality, such as inv(A*B*C) == inv(C)*inv(B)*inv(A), it's often better to compare the absolute difference to a threshold, such as abs(inv(A*B*C) - inv(C)*inv(B)*inv(A)) < thresh. Here thresh can be an arbitrary small number, or some expression involving eps, which gives you the smallest difference between two numbers at the precision at which you're working.
The format command only controls the display of results at the command line, not the way in which results are internally stored. In particular, format rat does not make MATLAB do calculations symbolically. For this, you might take a look at the Symbolic Math Toolbox. format hex is often even more useful than format long for diagnosing floating point precision issues such as the one you've come across.