mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Junru Shao <junrushao1...@gmail.com>
Subject Re: How should MXNet treat nan values?
Date Sat, 21 Jul 2018 19:23:37 GMT
I think it is worth discussing.

NunPy has defined its own rules to handle with numeral exceptions, which makes a lot of sense
to me. [Link](https://docs.scipy.org/doc/numpy/user/misc.html#how-numpy-handles-numerical-exceptions)


On 2018/07/20 22:19:46, Leonard Lausen <leonard@lausen.nl> wrote: 
> Hello MXNet community,
> 
> It seems that there is currently no agreed upon principle to handle
> `nan` values in operators. This has led to inconsistencies between
> operators and also to inconsistency over releases. Some operators ignore
> nan values (eg. argmax), others treated it as maximum (e.g. topk up to
> mxnet v1.2) or just return “undefined” output (e.g. topk starting with
> mxnet v1.3).
>  
> Initially the change in topk was reported as a bug
> (https://github.com/apache/incubator-mxnet/issues/8510) as some users
> relied on the behavior. However (and rightfully) @asmushetzel, who
> contributed the improved topk operator for mxnet v1.3 pointed out that
> the change did not break any documented behavior.
>  
> To go forward, please share your opinion how MXNet should handle `nan`
> values. Should we continue to treat the behavior as undefined and
> possibly silently changing between releases? Should we define a
> reasonable standard (e.g. follow numpy) and treat operators that deviate
> as buggy? Should we just document how operators behave currently and
> warn if the behavior changes? Something else?
>  
> Please make your opinion known so above issue can be resolved/closed and
> general guidelines can be defined for future contributions, following
> whatever consensus emerges.
>  
> Thanks!
> Leonard
> 

Mime
View raw message