MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn moreOpportunities for recent engineering grads.

Apply TodayTo resolve issues starting MATLAB on Mac OS X 10.10 (Yosemite) visit: http://www.mathworks.com/matlabcentral/answers/159016

Asked by K on 11 Dec 2012

Hi everyone, I have one question. I have two values : prior_value and current_value. Is there any easy way or any function that can be used to detect sign change between this two values? positive to negative or the other way. Thank you.

*No products are associated with this question.*

Answer by Jan Simon on 11 Dec 2012

Edited by Jan Simon on 11 Dec 2012

Either:

if ~isequal(sign(previous), sign(current))

Or the trivial:

if previos * current < 0

In both cases the 0 must be considered also, e.g. by "<= 0".

Show 5 older comments

Jan Simon on 16 Dec 2012

@Derek: I cannot follow you. Your question was "What is wrong with `if sign(previous) == sign(current)` ?". What is the first part? Do you mean the hint, that `a*b<0` is prone to errors? If so, I did not see a reason to answer, because this statement was not a question and correct without doubt and I have posted an equivalent test also: Have you seen "~isequal(sign(previous), sign(current))"?

The fact that `previos * current < 0` is prone to underflow is important, when you really get values like "10^(-170) and -10^(-171)". But how often does this happen in a real problem?

Therefore I do not understand, what you are talking about. It is documented that Matlab does not support signed zeros and how are signed infinities connected to the original question? Do you want to stress, that the sign change in [inf, -inf] cannot be detected by the multiplication method? If so, there is no doubt about that.

Derek O'Connor on 18 Dec 2012

@Jan, the statement ``if previos * current < 0 is prone to overflow and underflow which will give the wrong result'', contains an implicit question: do you recommend a statement that is prone to overflow and underflow which will give the wrong result? Sorry for the idiomatic English.

Your argument ``But how often does this happen in a real problem?'' reminds me of Intel's argument that the FDIV BUG didn't matter because it happened very rarely. IBM's analysis found that it happened many thousands of times per day, contrary to Intel's rarely. Remember, this error-prone sign test could be buried deep in a large program, called millions of times, and you have no idea what values are thrown at it.

For a nice history of the Pentium FDIV bug see here:

http://www.scribd.com/doc/117235066/IEEE-FDIV-Bug-Pentium

and for the sign test see here:

http://www.scribd.com/doc/117235915/O-Connor-Common-Errors-in-Numerical-Programming

In a previous comment you say ``Nothing is wrong with the comparison of the SIGNs [ if sign(previous) == sign(current) ], see my first suggestion. It makes it only harder to handle the cases of zero values.''

How about if sign(1/previous) == sign(1/current) ?

Mathematically sign(x) = sign(1/x), x ~= 0, so this test handles all non-zero values along with signed zeros.

The difficulties in defining machine precision are discussed by Nick Higham and Cleve Moler here:

http://www.scribd.com/doc/61226863/Higham-Moler-Three-Measures-of-Precision

Jan Simon on 18 Dec 2012

@Derek: I do not think that this dicussion matchs the complexity level of the OP's question. If a user asks for different signs of two values, the topic "a*b<0" should be mentioned. I hope, that the OP feels encouraged to find such trivial solutions by his own in the future.

There is absolutely no doubt, that a multiplication can lead to numerical difficulties. Neither the famous FDIV story nor a discussion about common errors is required to prove this.

`sign(1/x)` will suffer from `1/realmin ~= realmax`.

## 0 Comments