Asked by the cyclist
on 21 May 2012

I know that Mathworks pays a lot of attention to this stuff, so I am wondering why the expression

>> min(0,NaN)

is *0*. Returning a *NaN* here seems more logical to me.

Answer by Sean de Wolski
on 21 May 2012

the cyclist
on 21 May 2012

Answer by Walter Roberson
on 21 May 2012

If you initialize the result to inf, and then loop testing whether the current value is less than the result and replace the result if it is, then since NaN < any number is false, the result will never get replaced with NaN. You would have to add special code to return NaN in such a case.

Answer by Daniel
on 22 May 2012

Given the behavior of MIN, I find it odd that there is a NANMIN function.

Jonathan Sullivan
on 21 Jun 2012

That is really interesting. If you look inside nanmin, it has one line.:

[varargout{1:nargout}] = min(varargin{:});

per isakson
on 21 Jun 2012

Answer by M Sohrabinia
on 21 Jun 2012

NaN is considered undefined, so undefined is ignored by most functions (0/0 will be resulted in NaN which is basically undefined but any number divided by 0, say 4/0, will result in inf). However, the question is why Matlab has decided to treat NaNs in a certain way in some functions, e.g., sort function will always arrange NaNs at the top end (A to Z mode). I guess Matlab has just decided to adopt some rules to handle exceptions.

Opportunities for recent engineering grads.

## 0 Comments