On Mon, Sep 19, 2011 at 5:07 PM, Ronald S. Bultje <[email protected]> wrote: > Hi, > > On Mon, Sep 19, 2011 at 4:58 PM, Alex Converse <[email protected]> > wrote: >> On Mon, Sep 19, 2011 at 4:43 PM, Ronald S. Bultje <[email protected]> wrote: >>> 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? >> >> http://pubs.opengroup.org/onlinepubs/009695399/functions/sqrt.html >> http://pubs.opengroup.org/onlinepubs/009695399/functions/printf.html > > Nobody ever said eval() was going to follow libc standards or > restrictions. We're free to do whatever we want. We can implement an > eval(sqrt(x, y)) function that actually adds, or even eats, the > numbers. The possibilities are endless! >
I don't think arguing that our API *can* behave counterintuitively is the best argument for inventing your own nan semantics. > If we test that sqrt(-1) returns nan, then I expect that to mean that > we expect that behaviour. Else the test should be changed, and this > behaviour documented. > If you want to be the NaN police go ahead. I just think creating our own libav-eval API NaN semantics while implementing the underlying operations on libc and IEEE arithmetic as exposed by C seems like substantially more hassle than just printing all NaNs the same way. --Alex _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
