clc
clear all
%INPUT SECTION
fprintf('The files selected below must have the same dimensions.\n\n')
s=1;
e=0;
while s > e
p = input('prefix: ','s');
s = input('start file number: ');
e = input('end file number: ');
t = input('file extension: ','s');
if s > e
fprintf('start file number must be < end file number')
end
end
%CALCULATION SECTION
n = abs(e-s+1);
sn = num2str(s);
name = [p sn t];
x = imread(name);
sizex = size(x);
%HEIGHTS
heightl = sizex(1);
oheight = heightl;
%WIDTHS
widthl = sizex(2);
owidth = n*widthl;
%INDEX
index=owidth/widthl;
fa = zeros(oheight,owidth);
for s = s:1:e
sn = num2str(s);
name = [p sn t];
x = imread(name);
for ox = 1:1:owidth
for oy = 1:1:oheight
for lx = (s*widthl-widthl+1):1:s*widthl
for ly = 1:1:heightl
fa(oy,ox) = x(ly,lx);
end
end
end
end
end
%OUTPUT SECTION
Merlin, it's coded so it doesn't have to stop at 0, it could stop at 12, or 2000, etc.
I think a problem would be here: "while s > e" is the start of a loop, every time it goes through the loop it will test to see if s > e, so if you don't want it to loop forever you have to put s-- in there at some point.
Krom wrote:if you don't want it to loop forever you have to put s-- in there at some point
No.
That loop is taking user input for s and e, every time through. It's basically just waiting for the user to input s and e values that are correct in relation to each other. If the user is doing the right thing, that loop should terminate in one single iteration.
ccb, where is the program hanging up? Try putting some print statements every so often so that you can tell how far the code is getting before it freezes. The more information you can give us, the better...
for s = s:1:e
sn = num2str(s);
name = [p sn t];
x = imread(name);
for ox = 1:1:owidth
for oy = 1:1:oheight
for lx = (s*widthl-widthl+1):1:s*widthl
for ly = 1:1:heightl
fa(oy,ox) = x(ly,lx);
end
end
end
end
end
just an overview of what the program is supposed to do
the user has 36 files, they are named file1.bmp to file36.bmp
each bmp is a black/white bmp
the script, loads each bmp as a matrix, each cell in the matrix represents a pixel of the bmp, black is 0 and white is 255
it then, combines all the bmp matrixes into one big matrix
each bmp matrix has the exact same dimensions
the program is taking forever to combine all the bmp matrixes into one big matrix, either I have an infinite loop programed, or its a dog to process, ive got a dualie 1800 with a gig of ram, so im pretty well covered when it comes to hardware, the code has been running for 30 minutes...
The files selected below must have the same dimensions.
prefix: labdoc_
start file number: 1
end file number: 36
file extension: .bmp
??? Attempted to access x(1,35); index out of bounds because size(x)=[1584,34].
Personally I think if you took a job that you can't complete your a moron and you should hand it over to someone who can complete it...c'mon, be a man about it.
To cut the runtime down, you can either
1) use a faster programming language (may not be an option, but MATLAB is generally pretty slow being interpreted)
2) (better) reduce the complexity of that loop. With 5 or 6 nested for loops, I'm not surprised it takes so long.
It's more difficult to tell what causes the error, especially since it's been some time since I used MATLAB at all...
clc
clear all
%INPUT SECTION
fprintf('The files selected below must have the same dimensions.\n\n')
s=1;
e=0;
while s > e
p = input('prefix: ','s');
s = input('start file number: ');
e = input('end file number: ');
t = input('file extension: ','s');
if s > e
fprintf('start file number must be < end file number')
end
end
%CALCULATION SECTION
n = abs(e-s+1);
sn = num2str(s);
name = [p sn t];
x = imread(name);
sizex = size(x);
%HEIGHTS
heightl = sizex(1);
oheight = heightl;
%WIDTHS
widthl = sizex(2);
owidth = n*widthl;
%INDEX
index=owidth/widthl;
fa = zeros(oheight,owidth);
for i = s:1:e
sn = num2str(i);
name = [p sn t];
x = imread(name);
for lx = 1:1:widthl
for ly = 1:1:heightl
oy = ly;
ox = lx + (i - s)*widthl;
fa(oy,ox) = x(ly,lx);
end
end
end
%OUTPUT SECTION
Unless owidth is an exact multiple of widthl, which wouldn't surprise me. And if MATLAB had automatic downcasting ... which, theoretically, is a bad idea, but anyway.
Code looks much nicer now. Something more like O(w * h * n) instead of O(w^2 * h^2 * n)...
Your comment above reminds me of a mistake that a rookie programmer made. Used a Floating point variable then tried to use it where an Integer value was needed.
When they printed the value of the variable it looked like an integer but with a very minor amount of looking at the code, I found the problem very quickly.
The result of their error in coding was that the value was getting truncated to the integer value which was one less than what they expected. So they ended up with the wrong result in their code.
This was a quick lesson to them to use the proper variable types instead of assuming that a floating point number is exchangable directly with an integer value.