For example, I have the symbolic value which is 's+5/2'. Is there a way to display it like 's+2.5'?
Yes, use vpa. Simply take your symbolic expression and use the vpa function to facilitate the conversion. vpa evaluates each term in the symbolic expression and converts each value to using up to 32 significant digits whenever possible. You can also override the amount of significant digits with the second parameter to vpa, but that's not needed in your case.
Here's a quick example:
>> syms s
>> A = s + 5/2
A =
s + 5/2
>> vpa(A)
ans =
s + 2.5
You can also set the initial approximation mode of the numeric literal to decimal mode, where the precision is dictated by digits, using the 'd' flag of the sym function:
>> expr = sym('s') + sym(5/2,'d')
expr =
s + 2.5
Related
In this simple example, using the function vpa in a symbolic expression one can convert the outer fraction into decimal:
>> syms x
>> diff(2*x^(3.7))
(37*x^(27/10))/5
>> vpa(diff(2*x^(3.7)))
7.4*x^(27/10)
But the result still preserves a fraction in the exponent.
How could force Matlab to use decimals whenever possible?
Only for MATLAB 2019a and later:
>> sympref('FloatingPointOutput',true);
>> diff(2*x^(3.7))
ans =
7.4000*x^2.7000
And to return to the defaults:
>> sympref('FloatingPointOutput','default');
>> diff(2*x^(3.7))
ans =
(37*x^(27/10))/5
documentation
If input into a Matlab script, the following are deemed as unacceptable:
i) 8.8*e-2
ii) 3.2e1.5
iii) 1.25e+005
But why doesn't i), ii) and iii) work?
Is it because e is undefined?
I would have thought the reason for i) is because of the unnecessary *, but there is no * in either ii) or iii) and I believe they are also unacceptable.
i:
>> 8.8*e-2
Undefined function or variable 'e'.
This is self explanatory; you're asking to multiply with the * operator. It should be 8.8e-2
ii:
>> 3e1.5
3e1.5
↑
Error: Unexpected MATLAB expression.
From Wikipedia (emphasis mine):
Scientific notation (also referred to as scientific form or standard index form, or standard form in the UK) is a way of expressing numbers that are too big or too small to be conveniently written in decimal form. [...]
In scientific notation, all numbers are written in the form m × 10^n
(m times ten raised to the power of n), where the exponent n is an integer, and the coefficient m is any real number.
You want to use
>> 3*10^1.5
ans =
94.8683
iii:
>> 1.25e+005
ans =
125000
What's the problem?
2 ARE acceptable: 6,10 and .0
Can you clarify this question? It doesn't seem to be about scientific notation.
>> 6,10
ans =
6
ans =
10
>> .0
ans =
0
I have a problem with the mod function output in Matlab. I am trying to perform some calculations for ECC double and add algorithm. I am reading data from a file and storing it in a variable and then performing some operations. All works smoothly except that I get 0 in temp1 when I use mod(X2,P). However if I put in values stored in X2(3.0323e+153) and P(1.1579e+77) on command window (mod( 3.0323e+153, 1.1579e+77)), I get the correct values. Can anyone please help me? Below is the part of script which is problematic.
P = hex2dec('FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F');
line = fread(fileID,[1,67],'*char');
while ~feof(fileID)
PX = line(4:67);
X = hex2dec(PX);
X2 = X^2;
temp1= mod(X2 , P)
end
line = fread(fileID,[1,69],'*char');
end
fclose(fileID);
I think the problem lies with how you're initializing P. From the documentation for hex2dec (emphasis mine):
d = hex2dec('hex_value') converts hex_value to its floating-point integer representation. The argument hex_value is a hexadecimal integer stored as text. If the value of hex_value is greater than the hexadecimal equivalent of the value returned by flintmax, then hex2dec might not return an exact conversion.
And the value of flintmax is:
>> flintmax
ans =
9.007199254740992e+15
Quite a bit smaller than your value for P. In fact, if we use num2hex to look at the two ways you initialize P, you can see a clear difference:
>> P = hex2dec('FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F');
>> num2hex(P)
ans =
4ff0000000000000
>> num2hex(1.1579e+77)
ans =
4fefffda293c30de
As it turns out, the inexact conversion done by hex2dec results in a number that evenly divides into 3.0323e+153, thus giving you a remainder of 0:
>> mod(3.0323e+153, P)
ans =
0
>> mod(3.0323e+153, 1.1579e+77)
ans =
8.795697942083107e+76
realmax on my machine is:
1.7977e+308
I know I have to write my code in a way to avoid long integer calculations, but is there any way to increase the limit?
I mean something like gmp library in C
You may find vpa (variable- precision arithmetic) helpful:
R = vpa(A) uses variable-precision arithmetic (VPA) to compute each element of A to at least d decimal digits of accuracy, where d is the current setting of digits.
R = vpa(A,d) uses at least d significant (nonzero) digits, instead of the current setting of digits.
Here's an example how to use it:
>> x = vpa('10^500/20')
ans =
5.0e498
Note that:
The output x is of symbolic (sym) type. Of course, you shouldn't convert it to double, because it would exceed realmax:
>> double(x)
ans =
Inf
Use string input in order to avoid evaluating large input values as double. For example, this doesn't work
>> vpa(10^500/20)
ans =
Inf
because 10^500 is evaluated as double, giving inf, and then is used as an input to vpa.
newT = [b(i) d(i) a(i) z(i)];
newT, b(i), a(i)
Prints
newT =
123 364 123 902
ans =
1.234e+02
ans =
1.234e+02
What is the problem here? Why are the first and third entry in newT rounded to integer values? Why aren't they correctly assigned?
Unlike most other programming languages, integer types in Matlab take precedence over floating point types. When you combine them, either through concatenation or arithmetic, the floating point values are implicitly narrowed to integers, instead of the integers being widened to floating point.
>> int32(3) + 0.4
ans =
3
>> [int32(3) 0.4]
ans =
3 0
This is for historical reasons, because (IIRC) Matlab originally didn't have support for integers at all, so all numeric constants in Matlab produce double values, and the promotion rules were created to make it possible to mix integer types with floating-point constants.
To fix this, explicitly convert those int types to doubles before concatenating.
newT = [b(i) double(d(i)) a(i) double(z(i))];