What's wrong with my program and or function?

so this is my function

function [m] = ImperialToMetric(ft,in)
% This function converts imperial measurement (in feet and inches)
% to a metric measurement (in metres)
% Input:    ft = number of feet
%          in = number of inches
% Output:   m  = measurement in metres
% Author: Tapiwa Zvenyika

% Convert foot to inches and add to existing inches
TotalInches = ((ft * 12) + in);

% Calculate the total number of m
m = ((TotalInches) / 39.3701);

end

and this is my test script

% LabTwoTaskThree.m test the function I wrote in Task 2 with the data 
% I supplied and other randoms
% Author: Tapiwa Zvenyika

if ImperialToMetric(7,10) == 2.3876
    disp('There is no problem with the code')
    else
    disp('There is a problem with the code')
end

if ImperialToMetric(6,2) == 1.8796
    disp('There is no problem with the code')
    else
    disp('There is a problem with the code')
end

if ImperialToMetric(5,10) == 1.7780
    disp('There is no problem with the code')
    else
    disp('There is a problem with the code')
end
disp('The Test was ran!')

I keep getting the opposite of what i want

[Stephen23]

Floating-point numbers have been explained many times on this forum:

https://www.mathworks.com/matlabcentral/answers/57444-faq-why-is-0-3-0-2-0-1-not-equal-to-zero

https://www.mathworks.com/matlabcentral/answers/69-why-does-1-2-3-1-3-not-equal-zero#answer_271

https://www.mathworks.com/matlabcentral/answers/316889-why-two-equal-numbers-are-not-equal

https://www.mathworks.com/matlabcentral/answers/41536-why-is-2-24-10-22-4-not-equal-to-0

https://www.mathworks.com/matlabcentral/answers/20830-1-0010-does-not-equal-1-0010

etc, etc, etc

"What's wrong with my program and or function?"

Always use a tolerance when comparing floating point values.

Answer 1

[Walter Roberson]

http://matlab.wikia.com/wiki/FAQ#Why_is_0.3_-_0.2_-_0.1_.28or_similar.29_not_equal_to_zero.3F

[Walter Roberson]

In other words, do not do equality comparisons on floating point numbers.

[Tapiwa Zvenyika]

Sorry I'm new to MATLAB, I'm not too sure what you're trying to say? can you please explain (for a dummy) :)

[Walter Roberson]

Give the command

format long g

Now,

>> (7*12+10)/39.3701
ans =
           2.3875987106967

Does that exactly equal 2.3876 ?

Now look at https://en.wikipedia.org/wiki/Metre

"The imperial inch is defined as 0.0254 metres (2.54 centimetres or 25.4 millimetres)"

So instead of dividing by 39.3701 we can use

>> (7*12+10) * 0.0254
ans =
                    2.3876

Is that exactly 2.3876?

>> (7*12+10) * 0.0254 - 2.3876
ans =
     0

Yes, it is, in that case; in the other cases you get lucky; and you also get lucky with the others. But look at this:

>> 61*0.0254
ans =
                    1.5494
>> 61*0.0254 - 1.5494
ans =
     -2.22044604925031e-16

The output looks identical to 1.5494, but it is not identical to what MATLAB would use for an explicitly coded 1.5494. Let us have a look at what the exact values are:

>> fprintf('%.999g\n', 1.5494)
1.5494000000000001104893954106955789029598236083984375
>> fprintf('%.999g\n', 61*0.0254)
1.549399999999999888444790485664270818233489990234375

Those are not the same. The explicitly calculated one is slightly less than the value for the literal digits. How close are those in terms of internal representation?

>> num2hex(1.5494)
ans =
    '3ff8ca57a786c227'
>> num2hex(61*0.0254)
ans =
    '3ff8ca57a786c226'

... so they differ only in the very last bit (in this case.)

Therefore, when you calculate a number, the exact value you get might not be exactly the same as what you would expect if you did the same calculation in decimal.

Because of this, it is a mistake to use "==" to compare the results of a floating point computation with a known value. You need to instead test whether the values are "sufficiently close" to be acceptable to you. You can do that by looking at abs() of their difference, or you can use ismembertol() if you have a new enough MATLAB.

The version with dividing by 39.3701 is just not accurate:

>> fprintf('%.999g\n',1/0.0254)
39.370078740157481433925568126142024993896484375

0.0254 is the defined conversion factor. 1/39.3701 is an approximation of 1/0.0254 . This gives further evidence that you need to compare with tolerance... especially if you have a division involved.

[Tapiwa Zvenyika]

thank you so much, it actually makes sense now :)

Answer 2

[Image Analyst]

Just do this:

% LabTwoTaskThree.m test the function I wrote in Task 2 with the data 
% I supplied and other randoms
% Author: Tapiwa Zvenyika

if ismembertol(ImperialToMetric(7,10), 2.3876, 0.00001)
    disp('There is no problem with the code')
    else
    disp('There is a problem with the code')
end

if ismembertol(ImperialToMetric(6,2), 1.8796, 0.00001)
    disp('There is no problem with the code')
    else
    disp('There is a problem with the code')
end

if ismembertol(ImperialToMetric(5,10), 1.7780, 0.00001)
    disp('There is no problem with the code')
    else
    disp('There is a problem with the code')
end
disp('Done! The Test was run!')

function [m] = ImperialToMetric(ft,in)
% This function converts imperial measurement (in feet and inches)
% to a metric measurement (in metres)
% Input:    ft = number of feet
%          in = number of inches
% Output:   m  = measurement in metres
% Author: Tapiwa Zvenyika

% Convert foot to inches and add to existing inches
TotalInches = ((ft * 12) + in);

% Calculate the total number of m
m = ((TotalInches) / 39.3701);

end