Unexpected inequality in Matlab

  • Context: MATLAB 
  • Thread starter Thread starter hokhani
  • Start date Start date
  • Tags Tags
    Inequality Matlab
Click For Summary

Discussion Overview

The discussion revolves around an unexpected inequality encountered in a MATLAB program related to numerical computations involving floating-point arithmetic. Participants explore the implications of mathematical operations and the behavior of the MATLAB programming language in this context.

Discussion Character

  • Technical explanation
  • Debate/contested
  • Mathematical reasoning

Main Points Raised

  • One participant notes that the result of "difr" is not zero as expected, questioning the underlying issue with the calculation involving qx.
  • Another participant points out that the equation x = sqrt(x^2) holds only when x is non-negative, suggesting that (ef-u)/hbarv_f may be negative.
  • There is a discussion about the difference between the ^ and .^ operators in MATLAB, with some clarification that they behave the same for scalars but differ for arrays.
  • A participant mentions that the problem persists even when changing the value of ef, prompting a question about recalculating qx.
  • After recalculating with ef=10, a participant reports a very small value for difr, which leads to a discussion about floating-point arithmetic and rounding errors.
  • Concerns are raised about the sensitivity of the program to tiny numerical values, with inquiries about how to mitigate such errors.
  • Another participant advises that one must learn to deal with floating-point errors and suggests avoiding direct comparisons of floating-point numbers.
  • A further question is posed regarding the handling of fractions that may take infinite values, debating whether to use epsilon in the denominator or to factor out zero factors from equations before programming.

Areas of Agreement / Disagreement

Participants express differing views on how to handle floating-point errors and the implications of negative values in calculations. There is no consensus on the best approach to mitigate these issues, indicating ongoing debate.

Contextual Notes

Participants highlight limitations related to floating-point arithmetic and the behavior of mathematical operations in MATLAB, without resolving these complexities.

Who May Find This Useful

This discussion may be useful for programmers and researchers working with numerical computations in MATLAB, particularly those interested in understanding floating-point arithmetic and its implications in programming.

hokhani
Messages
601
Reaction score
22
In the program below, the result of "difr" is not zero but according to the definition of qx in the second line, I expect it to be zero (because [itex]qx^2+ky^2=(\frac{ef-u}{hbarv_f})^2[/itex]). What is the problem?
Code:
ef=1;hbarv_f=658;ky=0.0011;u=2.5;
qx=sqrt(((ef-u)/hbarv_f)^2-ky.^2);
difr=(ef-u)/hbarv_f-sqrt(qx^2+ky^2)
 
Physics news on Phys.org
You are not taking into account that ##x = \sqrt{x^2}## is only true when ##x \ge 0##. (ef-u)/hbarv_f is negative.
 
I don't know MATLAB well, but isn't ^ a different operator than .^
 
DaleSpam said:
I don't know MATLAB well, but isn't ^ a different operator than .^
The two operators act the same way on scalars. It is only for arrays that the behavior is different.
 
DrClaude said:
You are not taking into account that ##x = \sqrt{x^2}## is only true when ##x \ge 0##. (ef-u)/hbarv_f is negative.
But this problem exists even if you put, for instance, ef=10!
 
hokhani said:
But this problem exists even if you put, for instance, ef=10!
No. Did you recalculate qx after having changed ef?
 
DrClaude said:
No. Did you recalculate qx after having changed ef?
Yes, the result is:
Code:
ef=10;hbarv_f=658;ky=0.0011;u=2.5;
qx=sqrt(((ef-u)/hbarv_f)^2-ky.^2);
difr=(ef-u)/hbarv_f-sqrt(qx^2+ky^2)

difr =

  1.7347e-018
 
That's what I call zero. You are doing numerical computations: you have to allow for rounding errors. Look up floating-point arithmetic.
 
  • Like
Likes   Reactions: hokhani
DrClaude said:
That's what I call zero. You are doing numerical computations: you have to allow for rounding errors. Look up floating-point arithmetic.
My program is sensitive even to this tiny value. What should I do to get rid of such errors?
 
  • #10
hokhani said:
My program is sensitive even to this tiny value. What should I do to get rid of such errors?
You can't. You have to learn to deal with those errors. If the rest of your program is affected, it means that it is not properly written. For example, you should never compare the equality of two floating point numbers (or the equality of a float with an integer).
 
  • #11
DrClaude said:
You can't. You have to learn to deal with those errors. If the rest of your program is affected, it means that it is not properly written. For example, you should never compare the equality of two floating point numbers (or the equality of a float with an integer).
If I had in my program the fractions which take infinite values at some points, is it reasonable only putting eps (epsilon) in denominator or I must first factorize the "zero factor" out by trying (hardly in some cases) to change my equations (writing on paper) and then use them in the program?
 
Last edited:

Similar threads

  • · Replies 1 ·
Replies
1
Views
1K
  • · Replies 7 ·
Replies
7
Views
2K
  • · Replies 4 ·
Replies
4
Views
4K
  • · Replies 2 ·
Replies
2
Views
2K
  • · Replies 2 ·
Replies
2
Views
3K
  • · Replies 4 ·
Replies
4
Views
7K
  • · Replies 6 ·
Replies
6
Views
4K
Replies
2
Views
3K
Replies
1
Views
3K
  • · Replies 2 ·
Replies
2
Views
2K