Why does argmin index of NaN array have a value of 1 and not NaN?

[M, I] = min([NaN, NaN])

produces

M =

   NaN


I =

     1
     

Why? When there is no minimum (M=NaN) there should be no index returned for the minimum (the output variable I should also be NaN). This seems odd behaviour.

[Dyuman Joshi]

Because that's how it is defined.

From the documentation of min - "If all elements in the operating dimension are missing, then the corresponding element in M is missing."

M is the output array here.

[Michael]

In this case, I'm interested in the I output of the min function:

Index, returned as a scalar, vector, matrix, multidimensional array, or table. I is the same size as the first output.

When "linear" is not specified, I is the index into the operating dimension. When "linear" is specified, I contains the linear indices of A corresponding to the minimum values.

If the smallest element occurs more than once, then I contains the index to the first occurrence of the value.

Answer 1

[Matt J]

I imagine it is so that the logical test tf (below) will always return true. If the I output were NaN, an error message would result.

A=[NaN, NaN];

[M, I] = min(A);


tf=isequaln(M, A(I)) %We want this to be true, always

ans = logical
   1

Answer 2

[Fangjun Jiang]

Maybe the index is indeed returned by matching the min value to the input vector. Why does it matter? What is the significance in the case of min([nan nan])?

[M, I]=min([])

M =

     []


I =

     []

[M, I]=min([inf,nan])

M = Inf

I = 1

[M, I]=min([nan,inf])

M = Inf

I = 2

[M,I]=min([nan nan])

M = NaN

I = 1

[M,I]=min([inf inf])

M = Inf

I = 1

[Michael]

It may matter where (for example) a code returns an array of values, some of which are NaNs, and then a min function is required to identify indices of the minimum values over a specified dimension, which are in turn used to index some other array. If the array to which min() is applied has some occurrences of all NaNs over the dimension input to min(), then there is ambuity over whether the returned indices represent the actual minimum or are simply 1 because that is what is returned when the first array has NaNs on that dimension.

That ambiguity can be resolved of course, by also outputting the M array and indexing it with I, but that is an extra step or two. It seems odd that a numerical index for a min (or max) is returned when there is no numerical min or max value, because the inputs are not numerical values.

[Torsten]

@Michael

NaN values are indicating that something goes wrong in your code. They should be taken as exceptions and not as normal inputs to all kinds of MATLAB functions while expecting they will nonetheless return something useful.

[Michael]

Sorry, I don't agree with that. Returning NaNs can be a very natural part of many applications. Handling NaNs carefully is important and is not necessarily an indication of a problem in a code.

[Torsten]

In former computer languages, NaN values immediately let the code crash. Nowadays, packages like MATLAB decided to accept NaN in some contexts and work with them as good as possible - but I think such relaxations indirectly cause that codes get more and more errorprone with programmers being unable to locate problems they encounter - like in your case, as I suspect from what you write.

And I don't think that taking the min of a list of NaN values means that you "handled NaN values carefully".

[Walter Roberson]

The IEEE 754 committee that defined NaN explicitly created two kinds of NaN: "signalling NaN" and "quiet NaN".

Signalling NaN are intended to trigger a processor exception as soon as they are detected. They are for cases that "Something has gone wrong in the code and the code needs to know right away!". The processor itself is responsible for raising an interrupt when a Signalling NaN is detected.

Quiet NaN are for cases where "Something unusual has happened in the code, but as long as it is marked, the code will take care of detecting and any repairs afterwards."

MATLAB choose not to implement signalling NaNs -- with the limited exception of "dbstop if naninf" (which uses a different detection mechanism)

When IEEE 754 was defined, at least different NaN were defined for each of "quiet" and "signalling". The intent was that code libraries could use different NaN bit patterns to indicate different causes for the NaN; there was no standardization at all about particular patterns having specific meaning, so meanings were not inherently compatible between library implementations... but it was expected that standardization might come in time if it was going to be useful.

MATLAB treats all NaN the same way. It does not make any effort to preserve NaN bit patterns.

So, what happened in practice with signalling NaNs? Well, they have limited use, but it turned out that in practice the hardware handling of signalling NaNs gums up high speed computation. Hardware makes use of parallel execution, and of speculative execution, and of out-of-order execution, but when a signalling NaN is encounted, the state needs to be unwound and reconstructed as if the instructions had been done in serial in strict sequential order. Just keeping track of everything is non-trivial overhead that slows down computation whenver the processor bits are set to permit Signalling NaN to interrupt.

Because of this, there are some very specialized programmes where it is important to detect the exception ASAP that might use signalling NaN -- but that it turns out that for the great majority of programs, that inserting a quiet NaN and doing fix-ups later is fine.

[Michael]

@Torsten, in the case of my application, the NaNs originally arise because a NaN array is assigned using NaN(). Then the array is partially filled in with values where values should be. It is an intentional part of the code design. Thanks for your note of caution and for commenting on the question.

@Walter Roberson thanks for the historical background, this is interesting to know!

[Torsten]

in the case of my application, the NaNs originally arise because a NaN array is assigned using NaN(). Then the array is partially filled in with values where values should be. It is an intentional part of the code design.

If you have "control" over your NaN values, I apologize for my provocative comments.

Answer 3

[Steven Lord]

If the second output from min in the case where the input is all NaN values were NaN, every single call to min that wanted to use that second output as an index into the input would have to guard themselves against the all-NaN input case using isnan. With the current behavior, that second output is always* usable as an index.

x = [NaN, NaN]

x = 1×2

NaN NaN

[minvalue, minindex] = min(x)

minvalue = NaN

minindex = 1

x(minindex) % Current behavior

ans = NaN

x(NaN) % Your proposed behavior

Array indices must be positive integers or logical values.

Why is minindex equal to 1? Well, since all the elements are the same 1 is as good as any other index. And there are other places in MATLAB where we default to the first dimension / element / etc. (functions that accept a dim argument and get passed a scalar and no dimension as input, for example.)

* There may be a case where it's not, involving very tall sparse matrices and linear indices. But I don't remember off the top of my head what that does; I'd have to double-check. That might just throw an error.

[Stephen23]

"...since all the elements are the same..."

Yet the documentation states:

• "NaN values are not equal to each other..."
• "NaN values in a vector are treated as different unique elements..."

https://www.mathworks.com/help/matlab/ref/nan.html#f91-998324

[Steven Lord]

I was speaking colloquially. I should have been more precise. All the elements are NaN. There's no inherent reason based on the value of the NaN elements to favor one over another. We could have chosen to return the index of the first element, the last element, the middle element, or any of the elements in the array. I suspect that it was Cleve's decision to keep it simple and just use the first element.

[Matt J]

Why is minindex equal to 1? Well, since all the elements are the same 1 is as good as any other index. And there are other places in MATLAB where we default to the first dimension

It's also the most efficient choice. Why update a register when you don't have to?