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!

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.

Ronald
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to