[FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double

[Michael Niedermayer]

On Mon, Nov 30, 2015 at 08:03:41PM -0800, Muhammad Faiz wrote:
> On Mon, Nov 30, 2015 at 12:06 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Mon, Nov 30, 2015 at 07:02:47PM +0100, Nicolas George wrote:
> >> Le decadi 10 frimaire, an CCXXIV, Michael Niedermayer a écrit :
> >> > > ISO/IEC 9899:TC3
> >> > >     5.2.4.2.2 Characteristics of floating types <float.h>
> >> > >
> >> > >     8 Except for assignment and cast (which remove all extra range and precision), the values
> >> > >     of operations with floating operands and values subject to the usual arithmetic
> >> > >     conversions and of floating constants are evaluated to a format whose range and precision
> >> > >     may be greater than required by the type. The use of evaluation formats is characterized
> >> > >     by the implementation-defined value of FLT_EVAL_METHOD:19)
> >> > >         -1       indeterminable;
> >> > >         0       evaluate all operations and constants just to the range and precision of the
> >> > >                 type;
> >> > >         1       evaluate operations and constants of type float and double to the
> >> > >                 range and precision of the double type, evaluate long double
> >> > >                 operations and constants to the range and precision of the long double
> >> > >                 type;
> >> > >         2       evaluate all operations and constants to the range and precision of the
> >> > >                 long double type.
> >> > >     All other negative values for FLT_EVAL_METHOD characterize implementation-defined
> >> > >     behavior.
> >> >
> >> > a few more related parts:
> >> >     5 The accuracy of the floating-point operations (+, -, *, /) and of the library functions in
> >> >     <math.h> and <complex.h> that return floating-point results is implementation-
> >> >     defined, as is the accuracy of the conversion between floating-point internal
> >> >     representations and string representations performed by the library functions in
> >> >     <stdio.h>, <stdlib.h>, and <wchar.h>. The implementation may state that the
> >> >     accuracy is unknown.
> >> >
> >> > 6.4.4.2 Floating constants
> >> >     7 The translation-time conversion of floating constants should match the execution-time
> >> >     conversion of character strings by library functions, such as strtod, given matching
> >> >     inputs suitable for both conversions, the same result format, and default execution-time
> >> >     rounding.64)
> >>
> >> I am not sure why you quoting this. Are you implying this is not a compiler
> >> bug, the compiler is actually allowed to do that? Possible. But still, I do
> >
> > yes, i suspect that is not a compiler bug but i certainly do not have
> > deep enough knowledge of C to say that for sure
> >
> >
> >> not think we should apply this unless we actually understand what is going
> >> on here, why a cast that should not change anything does change the result.
> >> Otherwise, it could just be a coincidence, and break in a different way on a
> >> different compiler.
> >
> > I would not be surprised if a strict and litteral reading of C would
> > allow that still to fail, but then theres the question if such
> > equals check is even possible in C in such a strict reading of the
> > standard.
> > and theres also IEEE ...
> 
> But at least the standard said:
> 'Except for assignment and cast (which remove all extra range and precision)'
> so we can be sure that BASEFREQ is in double precision
> when casted to double.
> So, this patch should be OK
> 
> >
> > One could use a special value as default like -1 and check for that
> > which may be less likely to cause problems with float accuracy and
> > rounding in case the cast does not work on some real world case or
> > if the risk of it failing on some obscure plaform should be avoided
> 
> Unless the platform which makes this patch useless is reported,
> the patch should be OK for workaround.

yes
nicolas are you ok with this being applied ? (IIRC you objected to it)

language lawyering note: in a strict reading the standard the 2
occurances of the constant do probably not need to be parsed with teh
same precission nor with precission better or equal than "double".
In that case the code from the patch can fail and probably more or
less every clean alternative could too

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20151201/ffc3e989/attachment.sig>