How to display coordinate from for loop?

I am trying to find a set of coordinate that gives a result of 1.3 for the given equation using a for loop for a set of x and y values. How do I display the coordinates that gives such result?

qmin = 88;
limit = 1.3;
for i = 1:length(t2)
    hrms = (x.*((qmin)^4 - (y).^4))/4;
    if hrms == limit
    end
end

Answer 1

[Walter Roberson]

if hrms == limit
    disp([x, y])
    break;
end

But what do you want to do if no such point is found?

[Walter Roberson]

t2 = 0:0.1:2;
limit = 1.3;
found_one = false;
for i = 1 : length(t2)
    if t2(i) == limit
        disp(i);
        found_one = true;
        break;
    end
end

if ~found_one
    disp('no matches!')
end

no matches!

[~, idx] = min(abs(t2 - limit));
t2(idx)

ans = 1.3000

t2(idx) - limit

ans = -2.2204e-16

t2(idx) looks like it is the same 1.3 as the limit: why wasn't there a match? Why is t2() at the closest match 2.2204-e16 different than expected?

[Bora Eryilmaz]

You never want to check two floating-point numbers for equality using the "==" operator. The correct approach is to check for equality within a small tolerance:

tol = 1.0e-5; % Some tolerance value
isEqual = abs(hrms-limit) < tol

[Walter Roberson]

@Bora Eryilmaz

Close. The rule is that you should never compare two floating point numbers that are computed different ways. Example:

A = rand(1,10); A(7) = 0.43549;
minA = min(A);
A == minA

ans = 1×10 logical array
   0   0   0   0   0   0   0   0   0   1

A == 0.43549

ans = 1×10 logical array
   0   0   0   0   0   0   1   0   0   0

min() and max() and indexing copy values bit-for-bit (provided they are not being assigned into a different data type... and provided they are not unusual NaN representations), so it is safe to use == to compare an entry extracted from an array to the elements of the array (keeping in mind that nan == nan is false).

Literal values such as 0.43549 in practice always get the same bit pattern (not formally promised by MATLAB though.) But if you were to (for example) 43549/100000 then it is not promised that the result would be bit-for-bit identical to 0.43549

[Bora Eryilmaz]

@Walter Roberson Nope. Even in your example, you don't know what min(A) is doing. There is no guarentee that it will return an element of A exactly without any modification. And a casual MATLAB user would not, in general, know what operations would preserve the bit pattern of a value. Better be safe than sorry.

[Walter Roberson]

@Bora Eryilmaz

Suppose that the true numeric minimum of a vector is Actual, and the value returned by min() is Returned .

Then is Returned < Actual ? If it is then Returned is not the minimum of the vector, but min() is documented as returning the mimimum of the vector.

Is Returned > Actual ? If it is then Returned is not the minimum of the vector, but min() is documented as returning the mimimum of the vector.

Is Returned one of the NaN patterns even though the vector has no NaN patterns at all? NO.

Is Returned one of the NaN Patterns in a case where the vector has some NaN patterns but not all entries are NaN patterns? NO, the default is to omitnan

Is Returned one of the NaN Patterns in the case where all of the entries are NaN ? Yes -- and as per usual in MATLAB, the returned NaN pattern is not guaranteed to be the same as any of the input NaN patterns. MATLAB reserves the right to normalize NaN patterns during any function call that operates on the NaN. So in the case where all of the inputs are NaN, then the output is not guaranteed to be exactly the same bit pattern as any of the inputs. But I specifically noted NaN as an exception in my discussion above. Even if the exact same NaN pattern were returned, NaN == NaN is always false anyhow, so NaN was always going to be an exception no matter whether the exact bit pattern is copied or not.

What possibilities do we have left? Just the one where Actual is "equal to" Returned. Are there (non-nan) circumstances under which two numeric values with the same class might compare equal and yet be different bit patterns? Yes there is for single() and double() precision: in particular, -0 and 0 are "equal" but have different representations. How does min() handle that: if the actual minimum is at a location that is a negative zero, then does it convert the negative zero to a non-negative zero? No!

1./min([1 -0])

ans = -Inf

So if the input is negative zero and zero is the minimum value then the bit-pattern of the negative zero is the one emitted.

(What about the case where there is a negative zero and a non-negative zero in the input and the minimum is zero? In that case, it returns the bit pattern of the first zero.)

So under what circumstances can the output bit pattern not be the same as the input bit pattern associated with the minimum?

• one of the obscure NaN bit patterns
• min() with two numeric inputs of different classes

1./min(-0, single(0))

ans = single -Inf

single(-0) was not either of the inputs but is the output.

... If you mix input classes for two-input min() and you == afterwards and expect == to check the exact bit patterns, then you are asking for problems anyhow, since the == operator will convert datatypes before comparison.