# Suppose I have three vector x1,x2 and Y. Iam using optimization algorithm, I want maximum value of Y by using C=max(Y) I can extract the value and the value of x1 and x2 which are giving max Y value accordingly extracted, but I need the min value of

1 view (last 30 days)
RAVI on 7 Sep 2018
Commented: dpb on 8 Sep 2018
My algorithm concentrate only on max Value of Y not minimum value of X=x1+x2.
x1= [ 2 5 6 7 8 3],
x2= [ 3 5 6 8 9 3],
X=x1+x2=[ 5 10 12 15 17 6],
Y= [30 22 40 40 40 40],
max value of Y is 40 so it pick up 12 not 6.

#### 1 Comment

RAVI on 7 Sep 2018
but I need the min value of X=x1+x2 by which we get maximum value of Y.

dpb on 7 Sep 2018
Edited: dpb on 7 Sep 2018
mxy=max(Y); % find max Y
iy=find(Y==mxy); % all locations == max
mxymnx=min(X(iy)); % find corresponding min X for those positions
NB: "==" works for integer values of X,Y as given here; if real data is floating point use ismembertol for comparisons as exact tests may fail on occasion depending on FP rounding and how values are calculated.
NB2: To qualify the above a little-- "==" will work for locating Y==mxy as the value returned will be the exact bit pattern of the maximum value found; the question would be whether there were other values approximating mxy that are close but not exactly the same that would be intended to have been found. This could happen if the population of the array were generated by slightly different routes such that one value came from reading an input file while another was computed internally; those two results could be intended to be the same value but not absolutely identical to the LSB.

RAVI on 8 Sep 2018
is ismembertol is used for floating as well as real value. universally
dpb on 8 Sep 2018
"floating" -- "real" are synonymous.
Use ismembertol for FP comparison if want to find values that are within some relative magnitude of each other but not absolutely identical to the last/least significant bit. "==" will not find any except those that are absolutely identical.
It's easy enough to demonstrate how one can end up with values that are close, but not identical, that might easily be desired to be found to be the same...
Make a 1D grid in a naive manner...
>> dx=0.2;
>> x1=zeros(1,101);for i=2:length(x1), x1(i)=x1(i-1)+dx;end
>> [x1(1), x1(end)]
ans =
0 20.0000
>>
Now someone else uses a different technique--
>> x2=linspace(0,20,101);
>> [x2(1) x2(end)]
ans =
0 20
>>
Let's compare results:
>> all(x1==x2) % they don't all compare!!!???
ans =
logical
0
>> [x1(1:10); x2(1:10)]
ans =
0 0.2000 0.4000 0.6000 0.8000 1.0000 1.2000 1.4000 1.6000 1.8000
0 0.2000 0.4000 0.6000 0.8000 1.0000 1.2000 1.4000 1.6000 1.8000
>>
They're not the same, but to the eye at command line they look alike...and we think they're supposed to represent same thing.
Now try
>> [all(ismembertol(x1,x2)) all(x1==x2)]
ans =
1x2 logical array
1 0
>>
so within default tolerances, they are "close enough".
How many are identical out of the total--
>> sum(x1==x2) % only 12 are actually the same, identically...
ans =
12
>> max(abs(x1-x2)) % how big is largest difference?
ans =
3.9080e-14
>> max(abs(x1-x2))/eps(20)
ans =
11
>>
So, the difference is about 11X the difference between the closest neighboring FP values that could be stored in a double but just using find won't return but a handful when one might expect should return the full set if weren't aware how the two were calculated by different techniques--the first compounds the rounding error in adding the approximate value of 0.2 as stored internally so the rounding approximation accumulates over the series while linspace uses a technique to match the two endpoints as closely as possible (which are exact being representable integers in this case) and splits the error along the way.