If the data are defined as:
d1=repmat([2:5],5,1); d1=d1(:);
d2=repmat(1:5,1,4);d2=d2(:);
d3=100:100:2000;d3=d3(:);
then the lookup function can be defined as
fnVLU=@(i1,i2) d3(all([i1 i2]==[d1 d2],2));
Example:
Above includes the specific table in the function; if they change routinely then the table can also be arguments.
ADDENDUM
An alternate if the lookup values are always constructed as shown...
N1=max(d2);
fnIX=@(i1,i2) N1*(i1-d1(1))+d2(i2);
>> fnIX(3,4)
ans =
9
>> d3(ans)
ans =
900
>>
ADDENDUM
The actual problem is very far removed from the illustration so I'll leave it for pedagogical purposes.
For the last set of code that has issues outlined in comments below, a functional implementation awaiting resolution of those issues would look like (from the point onward I made a change)--
...
...
Table = [1:10;1:10;100:100:1000];
fnL=@(SI,K) Table(3,all(Table(1:2,:)==[SI; K]));
for i=1:length(D_Outer)
for j=1:length(Pitch)
for k=1:length(Free_Length)
for q=1:length(D_Wire)
if strcmp(Spring_Type,'Open');
Pitch(k) = (Free_Length(k) - D_Wire(q))/A_Coils;
elseif strcmp(Spring_Type,'Open and Ground');
Pitch(k) = Free_Length(k)/Tot_Coils;
elseif strcmp(Spring_Type,'Closed');
Pitch(k) = (Free_Length(k) - (3*D_Wire(q)))/A_Coils;
elseif strcmp(Spring_Type,'Closed and Ground');
Pitch(k) = (Free_Length(k) - (2*D_Wire(q)))/A_Coils;
end
Factor_K(k) = Pitch(k)/D_Wire(q);
Spring_Index(i) = D_Outer(i)/D_Wire(q);
try
Factor_L(i)=fnL(Factor_K(k),Spring_Index(i));
catch
Factor_L(i)=0;
end
end
end
end
end
Owing to the lack of points intersecting in the table and the issue with overwriting the indices in the result vectors, this yields less than satisfying result of
>> [[Spring_Index nan(1,5)];Factor_K;[Factor_L nan(1,5)]]
ans =
2.0000 4.0000 6.0000 8.0000 10.0000 12.0000 14.0000 16.0000 18.0000 20.0000 NaN NaN NaN NaN NaN
0 0.5000 1.0000 1.5000 2.0000 2.5000 3.0000 3.5000 4.0000 4.5000 5.0000 5.5000 6.0000 6.5000 7.0000
0 0 0 0 0 0 0 0 0 0 NaN NaN NaN NaN NaN
>>
in that no results were saved that had intersecting values in Table
I added another diagnostic display just to illustrate the code itself functions properly and that it's the data and indexing issues that are the problem where output
disp([i k Factor_K(k),Spring_Index(i) Factor_L(i)])
in the try block so could see the successes overall in the loop besides just the failures that finally were saved. That resulted in
>> jsmith
i k F_K SI F_L
1 5 2 2 200
1 5 2 2 200
1 5 2 2 200
1 5 2 2 200
1 5 2 2 200
1 5 2 2 200
1 5 2 2 200
1 5 2 2 200
1 5 2 2 200
1 5 2 2 200
1 5 2 2 200
1 5 2 2 200
1 5 2 2 200
1 5 2 2 200
1 5 2 2 200
2 9 4 4 400
2 9 4 4 400
2 9 4 4 400
2 9 4 4 400
2 9 4 4 400
2 9 4 4 400
2 9 4 4 400
2 9 4 4 400
2 9 4 4 400
2 9 4 4 400
2 9 4 4 400
2 9 4 4 400
2 9 4 4 400
2 9 4 4 400
2 9 4 4 400
3 13 6 6 600
3 13 6 6 600
3 13 6 6 600
3 13 6 6 600
3 13 6 6 600
3 13 6 6 600
3 13 6 6 600
3 13 6 6 600
3 13 6 6 600
3 13 6 6 600
3 13 6 6 600
3 13 6 6 600
3 13 6 6 600
3 13 6 6 600
3 13 6 6 600
>>
This illustrates clearly the over-storing into i, k indices that are repeated and that only the locations in the Table with same values match as presently constructed.
But, the lookup works as supposed to; it's just that there's no data available for almost all the cases.
Best Answer