On Fri, Jul 19, 2019 at 7:44 PM Ulf Zibis <ulf.zi...@cosoco.de> wrote: > > > Am 19.07.19 um 19:23 schrieb Nicolas George: > > Ulf Zibis (12019-07-19): > >> So please give an alternative theory than a rounding issue, why I > >> actually experience a different result. > > Code with doubles is very fragile, changing anything in the structure of > > your formula will give slightly different results. You were just lucky > > that this change made your use case work. > > May be, but I believe single rounding over twice rounding is less fragile. > > If I see right, the expression evaluation in libavutil/eval.c only > rounds once, so the chance of equal results against one rounding in > filter select should be higher. > > >> In the current code there is a 1st rounding with "(double)(time_base.nom > >> / time_base.den)" and then a 2nd with multipliying this value with > >> "frame->pts". In my code there is only 1 rounding after division of > >> (int64_t)(frame->pts * time_base.nom) with "(double)time_base.den". > > There is no rounding, all is done in double. > Try this: > printf("single rounding: %.40f\n", 130560LL * 1 / (double)12800); > printf("twice rounding: %.40f\n", 130560LL * (double)(1 / > (double)12800)); > Result: > single rounding: 10.1999999999999992894572642398998141288757 > twice rounding: 10.2000000000000010658141036401502788066864
This has absolutely nothing to do with "rounding", since there is no rounding being performed, but all to do with that floating point arithmetic is just always inaccurate. What this comes down to is this: a) 130560 / 12800 b) 130560 * (1 / 12800) There is no rounding there, since everything is kept in full double precision. But anyone working with doubles should know that they are inherently inaccurate. Instead of re-ordering the floating point math to somehow give you a slightly more favorable result, maybe there should be actual rounding to something reasonable when its evaluating the conditions, so that such inaccuracies just don't matter in the first place? - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".