average the elements of an array
in [Matlab]
|
From: Matt on 15 Apr 2010 18:49 So I'm quite new to Matlab, so excuse me if my question is simple or dumb but I have this line of code in my program that doesn't give any errors, but doesn't appear to do anything either: matrix(x,y) = ((matrix((x-1),y)+matrix(x,y)+matrix((x+1),y))/3); this line is inside a double for loop with the x's and y's being the for loop variables. What I think this line is doing is taking the x row and averaging the element at the x position of the elements before and after itself and then putting that value back into the the same element. However, when I run this code, my matrix never changes. I know I'm missing something simple, but I cannot seem to find it for the life of me. Sidenote: I realize I probably have 3sets of parenthesis that are unnecessary.
From: ImageAnalyst on 15 Apr 2010 21:29 Matt: This is a strange thing to do. Do you realize that this recursive way of taking the mean could lead to deceptive results? When you set the value of (x,y) then move over one in the x direction, now your x-1 is your old x, which is the new, output value, not your original input values. Better would be to just use conv2() and set the result equal to a separate output matrix, like this: clc; % Read in standard MATLAB grayscale demo image. grayImage = double(imread('cameraman.tif')); subplot(1, 2, 1); imshow(grayImage, []); title('Original Grayscale Image'); set(gcf, 'Position', get(0,'Screensize')); % Maximize figure. % Blur it horizontally blurWidth = 3; kernel = ones(1, blurWidth)/3 horizontallyBlurred = conv2(grayImage, kernel, 'same'); subplot(1, 2, 2); imshow(horizontallyBlurred, []); title('Horizontally Blurred Image');
From: Jan Simon on 16 Apr 2010 15:45 Dear Matt! > matrix(x,y) = ((matrix((x-1),y)+matrix(x,y)+matrix((x+1),y))/3); > However, when I run this code, my matrix never changes. This line is correct - although it is a really unusual computation as mentioned already. I assume your program has another problem. You cna inspect this by stopping the execution with the debugger: Set a break point with the debugger and step through your program line by line. You can show the contents of variables in the command line. Good luck, Jan
From: Roger Stafford on 16 Apr 2010 20:59 "Jan Simon" <matlab.THIS_YEAR(a)nMINUSsimon.de> wrote in message <hqaeol$t5q$1(a)fred.mathworks.com>... > Dear Matt! > > This line is correct - although it is a really unusual computation as mentioned already. I assume your program has another problem. You cna inspect this by stopping the execution with the debugger: Set a break point with the debugger and step through your program line by line. You can show the contents of variables in the command line. > > Good luck, Jan Jan, it may be a bit misleading to state to Matt that the line is "correct". Whether it is correct or not, embedded as it is within the two x and y for-loops, depends on the intent of the coding. If the intent is to substitute for each element (except those on the left and right boundaries) the average of its previous value along with those of the previous values of the elements to the immediate left and right, then it would *not* be correct. As you and ImageAnalyst are already aware, as x advances it is using as its x-1 value, not the original value but the value as altered just before that, which is an unusual procedure. In the end that makes each subsequent value some sort of weighted average of all elements to the left along with the one to the right. For example the new m_new(3,:) would equal 1/9*m_old(1,:)+1/9*m_old(2,:)+4/9*m_old(3,:)+3/9*m_old(4,:) where these latter m_old values refer to previous values. I seriously doubt that this is the intent of the coding, and Matt may not yet be aware of this. To do what I suspect was the actual intent would require making the replacements in a separate matrix as they occur and then substituting all the new values back into the old matrix after the for-loops are finished, (though of course this can more easily be done in a vectorized manner.) The only explanation I have for not seeing an alteration in your matrix, Matt, would be that each row already varies linearly along its length. Then it would remain unchanged by the code. For example 3,3.25,3.5,3.75,4,4.25, etc., along a row would remain unaffected (except for small round off errors.) Roger Stafford
From: Roger Stafford on 16 Apr 2010 23:00
"Roger Stafford" <ellieandrogerxyzzy(a)mindspring.com.invalid> wrote in message <hqb14t$t62$1(a)fred.mathworks.com>... > ... If the intent is to substitute for each element (except those on the left and right boundaries) the average of its previous value along with those of the previous values of the elements to the immediate left and right, then it would *not* be correct. As you and ImageAnalyst are already aware, as x advances it is using as its x-1 value, not the original value but the value as altered just before that, which is an unusual procedure. In the end that makes each subsequent value some sort of weighted average of all elements to the left along with the one to the right. For example the new m_new(3,:) would equal > > 1/9*m_old(1,:)+1/9*m_old(2,:)+4/9*m_old(3,:)+3/9*m_old(4,:) > > where these latter m_old values refer to previous values. I seriously doubt that this is the intent of the coding, and Matt may not yet be aware of this. To do what I suspect was the actual intent would require making the replacements in a separate matrix as they occur and then substituting all the new values back into the old matrix after the for-loops are finished, (though of course this can more easily be done in a vectorized manner.) > > The only explanation I have for not seeing an alteration in your matrix, Matt, would be that each row already varies linearly along its length. Then it would remain unchanged by the code. For example 3,3.25,3.5,3.75,4,4.25, etc., along a row would remain unaffected (except for small round off errors.) > > Roger Stafford -------- My apologies. My directions are turned around in the above. Where I said 'left' and 'right' should read 'up' and 'down', respectively, and where I said 'row' should read 'column'. Roger Stafford |