On 30 December 2015 at 03:15, Ganesh Ajjanagadde <gajja...@mit.edu> wrote:
> On Mon, Dec 28, 2015 at 10:27 PM, Matt Oliver <protogo...@gmail.com> > wrote: > > On 29 December 2015 at 11:51, Ganesh Ajjanagadde <gajjanaga...@gmail.com > > > > wrote: > > > >> On Mon, Dec 28, 2015 at 8:22 AM, Paul B Mahol <one...@gmail.com> wrote: > >> > On 12/27/15, Ganesh Ajjanagadde <gajjanaga...@gmail.com> wrote: > >> >> Replaces by real arithmetic. Tested the validity of these > >> transformations > >> >> separately. > >> >> > >> >> Signed-off-by: Ganesh Ajjanagadde <gajjanaga...@gmail.com> > >> >> --- > >> >> configure | 1 - > >> >> libavfilter/af_anequalizer.c | 25 +++++++++++++++++-------- > >> >> 2 files changed, 17 insertions(+), 9 deletions(-) > >> >> > >> > > >> > If those are mathematically equivalent ok. > >> > >> mathematically equivalent, tested offline, numerical differences of > >> the order of ~ 1e-15 or so, which is perfectly fine IMHO for double > >> precision especially since it is a priori not clear which is more > >> precise. Pushed, thanks. > > > > > > Wouldn't it also be a good idea to remove the COMPLEX_FUNCS list from > > configure as now neither cabs or cexp are used so configure can be > > simplified by removing the checks for them. > > I asked Paul about this (when I removed them from some other filter). > That time he said he wanted them for another filter (anequalizer) > since the expressions were complicated. Judging from this commit, I > think that was a fair assessment. > > In short, this is really a question for Paul (or others who use > complex numbers): if there are plans on doing something with complex > numbers that is not trivial to rewrite, it may be helpful not to > remove as you suggest. If not, then it is perhaps ok. > > Personally, over the long term, I think there will be further > instances of complex number usage. If we remove it now, I suspect it > will get added back in at some point. As such, I won't write a patch > for this; really upto others especially Paul. > > Maybe long run we can create an av_complex or something like that. A > few problems are (among possibly many others): > 1. Syntactic sugar for *, / , +, - will be lost, and one will need to > create something like cmult, cdiv, and call at an increased verbosity > cost. In C++, these basic operators can be overloaded (but then again > stdc++ has a complex header); AFAIK there is no such mechanism that we > can use in FFmpeg's "least common denominator" C. > 2. Natural promotion rules will be lost, e.g suppose one passes a > double to a complex function, say while multiplying a double complex > by a double as in anequalizer. With proper complex number support, > promotion rules kick in and everything works. With av_complex, this > does not work, and explicit setting of imaginary part to 0 will be > needed. Fair enough, I was just checking. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
