I'm trying to solve an easy recursive equation, but I'm encountered with very rudimentary problems that I think a MATLAB expert can easy resolve.
So here is the short version of my code:
clear all
%%%INPUT DATA
gconst = [75 75];
kconst = [200 200];
tau = [.01667 .14153];
%%% TIME Span
t = [0 .001 .002 .003 .004 .005];
%%% Definition of the functions g(x) and k(y)
syms g(x) k(y)
g(x) = gconst(1)*exp(-x/tau(1))+gconst(2)*exp(-x/tau(2));
k(y) = kconst(1)*exp(-y/tau(1))+kconst(2)*exp(-y/tau(2));
%%% Defining initial conditons
nu = zeros(1,7);
nu(1)= 3.64e-1;
nu(2)= 3.64e-1;
%%% nu(3) is required
int(sym('i'))
nu(3)=nu(1)*(3*k(t(3)-t(2))+g(t(3)-t(2))-g(t(3)))...
+symsum(nu(i)*(3*k(t(3)-t(i+1))-3*k(t(3)-t(i-1))... %symsum line 1
+g(t(3)-t(i+1))-g(t(3)-t(i-1))), i, 1, 3))... %symsum line 2
/(3*k(0)+g(0));
You can ignore the whole symsum part, because without, the code still doesn't work.
It is a very straightforward code, but after running it, I get this error:
Subscript indices must either be real positive integers or logicals.
This error is found in the line where I defined nu(3).
I'd like to hear your comments.
EDIT 1: k(y) instead of k(x).
EDIT 2: zeros(1,7) instead of zeros(7).
NOTE 1: The code works without the symsum part and after EDIT 1.
What you want can't be done.
The reason is, that you are indexing an array t = [0 .001 .002 .003 .004 .005] with the symbolic summation index i.
So while
syms i
S1 = symsum( i, i, 1,3)
works
syms t i
t = [1 2 3];
S1 = symsum( t(i), i, 1,3)
won't work, and there is no way around it, because the values 1 ... 3 are evaluated after indexing. You need to rethink your approach completely.
Apart from that you probably want k(y) instead of k(x). That was the reason why the code didn't work without the symsum part neither.
Using i as a variable name is not an issue anymore, but shouldn't be used to avoid misunderstandings.
Related
I've written code to smooth an image using a 3x3 averaging filter, however the output is strange, it is almost all black. Here's my code.
function [filtered_img] = average_filter(noisy_img)
[m,n] = size(noisy_img);
filtered_img = zeros(m,n);
for i = 1:m-2
for j = 1:n-2
sum = 0;
for k = i:i+2
for l = j:j+2
sum = sum+noisy_img(k,l);
end
end
filtered_img(i+1,j+1) = sum/9.0;
end
end
end
I call the function as follows:
img=imread('img.bmp');
filtered = average_filter(img);
imshow(uint8(filtered));
I can't see anything wrong in the code logic so far, I'd appreciate it if someone can spot the problem.
Assuming you're working with grayscal images, you should replace the inner two for loops with :
filtered_img(i+1,j+1) = mean2(noisy_img(i:i+2,j:j+2));
Does it change anything?
EDIT: don't forget to reconvert it to uint8!!
filtered_img = uint8(filtered_img);
Edit 2: the reason why it's not working in your code is because sum is saturating at 255, the upper limit of uint8. mean seems to prevent that from happening
another option:
f = #(x) mean(x(:));
filtered_img = nlfilter(noisy_img,[3 3],f);
img = imread('img.bmp');
filtered = imfilter(double(img), ones(3) / 9, 'replicate');
imshow(uint8(filtered));
Implement neighborhood operation of sum of product operation between an image and a filter of size 3x3, the filter should be averaging filter.
Then use the same function/code to compute Laplacian(2nd order derivative, prewitt and sobel operation(first order derivatives).
Use a simple 10*10 matrix to perform these operations
need matlab code
Tangentially to the question:
Especially for 5x5 or larger window you can consider averaging first in one direction and then in the other and you save some operations. So, point at 3 would be (P1+P2+P3+P4+P5). Point at 4 would be (P2+P3+P4+P5+P6). Divided by 5 in the end. So, point at 4 could be calculated as P3new + P6 - P2. Etc for point 5 and so on. Repeat the same procedure in other direction.
Make sure to divide first, then sum.
I would need to time this, but I believe it could work a bit faster for larger windows. It is sequential per line which might not seem the best, but you have many lines where you can work in parallel, so it shouldn't be a problem.
This first divide, then sum also prevents saturation if you have integers, so you might use the approach even in 3x3 case, as it is less wrong (though slower) to divide twice by 3 than once by 9. But note that you will always underestimate final value with that, so you might as well add a bit of bias (say all values +1 between the steps).
img=imread('camraman.tif');
nsy-img=imnoise(img,'salt&pepper',0.2);
imshow('nsy-img');
h=ones(3,3)/9;
avg=conv2(img,h,'same');
imshow(Unit8(avg));
Is there some advantage of writing
t = linspace(0,20,21)
over
t = 0:1:20
?
I understand the former produces a vector, as the first does.
Can anyone state me some situation where linspace is useful over t = 0:1:20?
It's not just the usability. Though the documentation says:
The linspace function generates linearly spaced vectors. It is
similar to the colon operator :, but gives direct control over the
number of points.
it is the same, the main difference and advantage of linspace is that it generates a vector of integers with the desired length (or default 100) and scales it afterwards to the desired range. The : colon creates the vector directly by increments.
Imagine you need to define bin edges for a histogram. And especially you need the certain bin edge 0.35 to be exactly on it's right place:
edges = [0.05:0.10:.55];
X = edges == 0.35
edges = 0.0500 0.1500 0.2500 0.3500 0.4500 0.5500
X = 0 0 0 0 0 0
does not define the right bin edge, but:
edges = linspace(0.05,0.55,6); %// 6 = (0.55-0.05)/0.1+1
X = edges == 0.35
edges = 0.0500 0.1500 0.2500 0.3500 0.4500 0.5500
X = 0 0 0 1 0 0
does.
Well, it's basically a floating point issue. Which can be avoided by linspace, as a single division of an integer is not that delicate, like the cumulative sum of floting point numbers. But as Mark Dickinson pointed out in the comments:
You shouldn't rely on any of the computed values being exactly what you expect. That is not what linspace is for. In my opinion it's a matter of how likely you will get floating point issues and how much you can reduce the probabilty for them or how small can you set the tolerances. Using linspace can reduce the probability of occurance of these issues, it's not a security.
That's the code of linspace:
n1 = n-1
c = (d2 - d1).*(n1-1) % opposite signs may cause overflow
if isinf(c)
y = d1 + (d2/n1).*(0:n1) - (d1/n1).*(0:n1)
else
y = d1 + (0:n1).*(d2 - d1)/n1
end
To sum up: linspace and colon are reliable at doing different tasks. linspace tries to ensure (as the name suggests) linear spacing, whereas colon tries to ensure symmetry
In your special case, as you create a vector of integers, there is no advantage of linspace (apart from usability), but when it comes to floating point delicate tasks, there may is.
The answer of Sam Roberts provides some additional information and clarifies further things, including some statements of MathWorks regarding the colon operator.
linspace and the colon operator do different things.
linspace creates a vector of integers of the specified length, and then scales it down to the specified interval with a division. In this way it ensures that the output vector is as linearly spaced as possible.
The colon operator adds increments to the starting point, and subtracts decrements from the end point to reach a middle point. In this way, it ensures that the output vector is as symmetric as possible.
The two methods thus have different aims, and will often give very slightly different answers, e.g.
>> a = 0:pi/1000:10*pi;
>> b = linspace(0,10*pi,10001);
>> all(a==b)
ans =
0
>> max(a-b)
ans =
3.5527e-15
In practice, however, the differences will often have little impact unless you are interested in tiny numerical details. I find linspace more convenient when the number of gaps is easy to express, whereas I find the colon operator more convenient when the increment is easy to express.
See this MathWorks technical note for more detail on the algorithm behind the colon operator. For more detail on linspace, you can just type edit linspace to see exactly what it does.
linspace is useful where you know the number of elements you want rather than the size of the "step" between them. So if I said make a vector with 360 elements between 0 and 2*pi as a contrived example it's either going to be
linspace(0, 2*pi, 360)
or if you just had the colon operator you would have to manually calculate the step size:
0:(2*pi - 0)/(360-1):2*pi
linspace is just more convenient
For a simple real world application, see this answer where linspace is helpful in creating a custom colour map
Because I am trying to let a GUI element slice my array, there will be a : (colon) sign in the variables. This returns me an error:
Error in gui_mainfcn (line 96)
feval(varargin{:});
line 96 refers to this code:
image(handles.data(1:handles.rows,1:handles.cols, temp))
Temp looks like this
temp =
1 1 1 1 2 1 1 1 1
And both handles.rows and cols are the value 64. So the problem seems to be that I use colons in the gui function. However, to slice I need to use colons. My question now is: Any idea how to work around this?
To clarify as requested below
The above code works when I manually enter it in the console. Also when I use handles.data(:,:,1,1,1,1,2,1,1,1,1), handles.data(1:end,1:end,1,1,1,1,2,1,1,1,1), handles.data(1:64,1:64,1,1,1,1,2,1,1,1,1), etc I get the same error from the gui. Manually they all work and return a 64 by 64 array of doubles which I can plot with image().
Might be related to these questions, however those deal with parfor difficulties and dont seem to answer my question:
matlab-parfor-slicing-issue
index-inside-parfor-slicing
I am now also reading the advanced topics for slicing variables. Still dont see what I am doing wrong though, so any help or explanation would still be greatly apprectiated. Thanks!
Explanation
By putting the vector temp as the third index into your data, you are not indexing the higher dimensions - you are repeatedly indexing the third. In other words, you get handles.data(:,:,[1 1 1 1 2 1 1 1 1]) instead of handles.data(:,:,1,1,1,1,2,1,1,1,1).
Solution
Here's a solution that doesn't require squeeze or eval. It exploits the comma-separated lists output of the {:} syntax with cell arrays, and the ability to apply linear indexing on the last subscripted dimension.
ctemp = num2cell(temp); % put each index into a cell
sz = size(handles.data); % i.e. sz = [256 256 1 1 2 1 2]
sliceind = sub2ind(sz(3:end),ctemp{:}); % compute high dim. linear index (scalar)
image(handles.data(:,:,sliceind));
This performs subscripting of a >3D array with only 3 subscripts by computing the last subscript as a linear index. It's weird, but convenient sometimes.
A heads up for people with the same problem, this error can not only result from not knowing how to slice, it could also result from not having defined your variables correctly: http://www.mathworks.nl/matlabcentral/answers/87417-how-to-slice-inside-gui-without-error-feval-varargin
Consider the following code snippet
for i = 1:100
Yi= x(i:i + 3); % i in Yi is not an index but subscript,
% x is some array having sufficient values
i = i + 3
end
Basically I want that each time the for loop runs the subscript changes from 1 to 2, 3, ..., 100. SO in effect after 100 iterations I will be having 100 arrays, starting with Y1 to Y100.
What could be the simplest way to implement this in MATLAB?
UPDATE
This is to be run 15 times
Y1 = 64;
fft_x = 2 * abs(Y1(5));
For simplicity I have taken constant inputs.
Now I am trying to use cell based on Marc's answer:
Y1 = cell(15,1);
fft_x = cell(15,1);
for i = 1:15
Y1{i,1} = 64;
fft_x{i,1} = 2 * abs(Y1(5));
end
I think I need to do some changes in abs(). Please suggest.
It is impossible to make variably-named variables in matlab. The common solution is to use a cell array for Y:
Y=cell(100,1);
for i =1:100
Y{i,1}= x(i:i+3);
i=i+3;
end
Note that the line i=i+3 inside the for-loop has no effect. You can just remove it.
Y=cell(100,1);
for i =1:100
Y{i,1}= x(i:i+3);
end
It is possible to make variably-named variables in matlab. If you really want this do something like this:
for i = 1:4:100
eval(['Y', num2str((i+3)/4), '=x(i:i+3);']);
end
How you organize your indexing depends on what you plan to do with x of course...
Yes, you can dynamically name variables. However, it's almost never a good idea and there are much better/safer/faster alternatives, e.g. cell arrays as demonstrated by #Marc Claesen.
Look at the assignin function (and the related eval). You could do what asked for with:
for i = 1:100
assignin('caller',['Y' int2str(i)],rand(1,i))
end
Another related function is genvarname. Don't use these unless you really need them.
I'm trying to program an array retrieval in swi-prolog. With the current code printed below I can retrieve the element at the given index but I also want to be able to retrieve the index[es] of a given element.
aget([_|X],Y,Z) :- Y \= 0, Y2 is (Y-1), aget(X,Y2,Z).
aget([W|_],Y,Z) :- Y = 0, Z is W.
Example 1: aget([9,8,7,6,5],1,N) {Retrieve the element 8 at index 1}
output: N = 9. {Correct}
Example 2: aget([9,8,7,6,5],N,7) {retrieve the index 2 for Element 7}
output: false {incorrect}
The way I understood it was that swi-prolog would work in this way with little no additional programing. So clearly I'm doing something wrong. If you could point me in the right direction or tell me what I'm doing wrong, I would greatly appreciate it.
Your code it's too procedural, and the second clause it's plainly wrong, working only for numbers.
The functionality you're looking for is implemented by nth0/3. In SWI-Prolog you can see the optimized source with ?- edit(nth0). An alternative implementation has been discussed here on SO (here my answer).
Note that Prolog doesn't have arrays, but lists. When an algorithm can be rephrased to avoid indexing, then we should do.
If you represent arrays as compounds, you can also use the ISO standard predicate arg/3 to access an array element. Here is an example run:
?- X = array(11,33,44,77), arg(2,X,Y).
X = array(11, 33, 44, 77),
Y = 33.
The advantage over lists is that the compound access needs O(1) time and whereas the list access needs O(n) time, where n is the length of the array.