Alex Converse <[email protected]> writes: > On Mon, Sep 19, 2011 at 4:43 PM, Ronald S. Bultje <[email protected]> wrote: >> Hi, >> >> On Mon, Sep 19, 2011 at 4:27 PM, Alex Converse <[email protected]> >> wrote: >>> On Mon, Sep 19, 2011 at 7:44 AM, Sean McGovern <[email protected]> wrote: >>>> >>>> >>>> On Sunday, September 18, 2011, Anton Khirnov <[email protected]> wrote: >>>> > From: Stefano Sabatini <[email protected]> >>>> > >>>> > --- >>>> > doc/eval.texi | 4 ++++ >>>> > libavutil/avutil.h | 2 +- >>>> > libavutil/eval.c | 6 ++++++ >>>> > tests/ref/fate/eval | 6 ++++++ >>>> > 4 files changed, 17 insertions(+), 1 deletions(-) >>>> > >>> >>> FFmpeg fixed this with >>> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=16a565d0cbb7e753f594236c60bbcc66657024f6 >> >> That's not a fix. The values are still different. A fix would be to >> actually change the result of eval(sqrt(-1)) to nan if it is -nan, not >> to print nan but leave the value as -nan. >> > > sqrt(-1) and a variety of other functions that return NaN are only > required to return "a NaN" and not any specific NaN. When printing > these NaNs with "%f" libc has the freedom to print an arbitrary > character after "[-]nan". Why is it better to try to catch these and > replace them with whatever the present libc prints as "nan" rather > than just normalize these when we print them?
That provision is probably there to allow an signalling nans to be distinguished from quiet ones. If we make sure to only return quiet nans, there should be no problem. Printing something other than the actual value is just wrong. -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
