Wrong evaluation with `NaN` value about mingo HOT 4 CLOSED

Thanks for the bug report @Jaysok. Feel free to submit a PR.

Relevant code points.

https://github.com/kofrasa/mingo/blob/master/src/operators/accumulator/min.ts
https://github.com/kofrasa/mingo/blob/master/src/operators/accumulator/max.ts

Tests can be added here https://github.com/kofrasa/mingo/tree/master/test/operators/accumulator.

Thanks

from mingo.

After some consideration I don't think the behaviour should change as there is no reasonable way to address it except to error out. Unfortunately NaN yields weird results in most cases for almost all operators and this is no different. If NaN exists in your input data or can be generated in some intermediate process in the query, you should either cleanup the input or leverage the type conversion operators to convert before using for calculations.

MongoDB addresses this by failing operations that generate NaN results. I think that is a better way to address this on per operator basis.

from mingo.

An alternative I did not mention was to just make NaN inputs return NaN outputs but that just propagates the nonsense value through the process chain. This might be a better alternative since it can limit the useless values to only parts of some input data depending on what the query is doing. For example in window functions, some windows may contain NaN while others compute correctly.

from mingo.

I think it is best to retain behaviour that is consistent with other accumulator functions. NaN is too weird to work with and passing it through won't be useful. There are many more cases I can conceive where it is ok to ignore the NaN value in computations rather than pass it through. If there is demand to treat it some other way, I will consider putting that behind an option.

from mingo.