when I calculate a very small number, matlab gives
1.12345e-15
What is this?
I can interpret it as 1.12345*10^(-15)
or its 1.12345*e^(-15)
I am in very hurry. Sorry for the stupid question.
e represents exponential. Its the scientific notation of writing numbers.
The base is 10. For example:
1e2 =100
1e-2= 0.01
e represents scientific notation as Rahul said but it is base 10, not base e.
Run the following code to confirm.
1e1
It gives you
ans = 10
Related
I have a few simple equations that I want to pipe through matlab. But I would like to get exact answers, because these values are expected to be used and simplified later on.
Right now Matlab shows sqrt(2.0) as 1.1414 instead of something like 2^(1/2) as I would like.
I tried turning on format rat but this is dangerous becasue it shows sqrt(2) as 1393/985 without any sort of warning.
There is "symbolic math" but it seems like overkill.
All I want is that 2 + sqrt(50) would return something like 2 + 5 * (2)^(1/2) and even my 5 years old CASIO calculator can do this!
So what can I do to get 2 + sqrt(50) evaluate to 2 + 5 * (2)^(1/2) in matlab?
As per #Oleg's comment use symbolic math.
x=sym('2')+sqrt(sym('50'))
x =
5*2^(1/2) + 2
The average time on ten thousand iterations through this expression is 1.2 milliseconds, whilst the time for the numeric expression (x=2+sqrt(50)) is only 0.4 micro seconds, i.e. a factor of ten thousand faster.
I did pre-run the symbolic expression 50 times, because, as Oleg points out in his second comment the symbolic engine needs some warming up. The first run through your expression took my pc almost 2 seconds.
I would therefore recommend using numeric equations due to the huge difference in calculation time. Only use symbolic expressions when you are forced to (e.g. simplifying expressions for a paper) and then use a symbolic computation engine like Maple or Wolfram Alpha.
Matlab main engine is not symbolic but numeric.
Symbolic toolbox. Create expression in x and subs x = 50
syms x
f = 2+sqrt(x)
subs(f,50)
ans =
50^(1/2) + 2
688^79 mod 3337 = 1570.
When I tried this at wolfram alpha I got:
but When I entered the same thing in Matlab, I get 364 as the answer. I got to be doing something wrong.
Any light on this will be appreciated.
The reason is that Matlab uses double floating-point arithmetic by default. A number as large as 688^79 can't be represented accurately as a double. (The largest integer than can be accurately represented as a double is of the order of 2^53).
To obtain the right result you can use symbolic variables, which ensures you don't lose accuracy:
>> x = sym('688^79');
>> y = sym('3337');
>> mod(x, y)
ans =
1570
My calculator is sending me the same answer than Wolfram, it also calculated the value for 688^79 so I would tend to believe Wolfram is right.
You probably have overrun the capacities of Matlab with such a huge number and it is why it did not send the right answer.
I have a question about adding the number 1 to very small numbers. Right now, I am trying to plot a circular arc in the complex plane centered around the real number 1. My code looks like:
arc = 1 + rho .* exp(1i.*theta);
The value rho is a very small number, and theta runs from 0 to pi, so whenever 1 is added to the real part of arc, MATLAB seems to just round it to 1, so when I type in plot(real(arc),imag(arc)), all I see is a spike instead of a semicircle around 1. Does anyone know how to remedy this so that MATLAB will not round 1 + real(arc) to 1, and instead conserve the precision?
Thanks
rho=1e-6; theta=0:pi/100:pi; arc=1+rho*exp(1i.*theta); plot(arc); figure(); plot(arc-1);
Shows, that the problem is in plot, not in loss of precision. After rho<1e-13 there will be expected trouble with precision.
The two other possible misconceptions:
- doubles have finite precision. 16 decimal digits or 1+2^-52 is the limit with doubles.
- format short vs. format long -- matlab shows by default only 6 or 7 digits
It also happens to be that 6-7 digits is the limit of a 32-bit float, which could explain also that perhaps the plot function in Octave 3.4.3 is also implemented with floats.
Left: 1+1e-6*exp, Right: (1+1e-6*exp)-1
There is a builtin solution for exactly this probem:
exp1m()
log1p()
explicitly:
log(arc)=log1p(rho*exp(1i*theta))
to get what you need.
Of course you need to work in log space to represent this precision, but this is the typical way this is done.
In double precision floating point representations, the smallest number strictly greater than 1 that can be represented is 1 + 2^-52.
This is a limitation imposed by the way non-integer numbers are represented on most machines that can be avoided in software, but not easily. See this question about approaches for MATLAB.
I am using Matlab and using numbers in scientific notation, which are represented with the letter e for the exponent. An example in Matlab:
>> 2e5
ans =
200000
Now would like to work with numbers in scientific notation, but using variables to hold the values of the mantissa and the exponent (left and right side of the e respectively). I do not understand how this can be done without the variable names merging with the letter e for the exponent. Eg:
>> rr=5;
>> 2err
??? 2err
|
Error: Unexpected MATLAB operator.
Can this still be done? Or must I use the manual approach:
>> 2*10^rr
ans =
200000
You must use the manual approach; you can't use scientific notation like that with variables. You might want to use 2.*10.^rr, with the ., to enable you to use the same statement with arrays of numbers.
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.