On Sat, Mar 12, 2016 at 11:42 AM, Reimar Döffinger
<reimar.doeffin...@gmx.de> wrote:
> On Sat, Mar 12, 2016 at 11:11:32AM -0500, Ganesh Ajjanagadde wrote:
>> On Sat, Mar 12, 2016 at 11:02 AM, Michael Niedermayer
>> <mich...@niedermayer.cc> wrote:
>> >> +static inline double ziggurat(AVLFG *lfg)
>> >> +{
>> >> + while (1) {
>> >
>> >> + uint64_t r = (((uint64_t)av_lfg_get(lfg) << 32) +
>> >> av_lfg_get(lfg)) & 0x000fffffffffffff;
>> >
>> > the order of Function evaluations is undefined here i think
>>
>> And why would that matter? Aren't these just approximations to truly
>> uniform 32 bits? rand()<<32 + rand() is common:
>
> Because you generally don't want the randomness to include the
> compiler/compiler options used.
> You can end up with a case where a bug only happens when you get
> a specific value.
> To debug you compile with -O1. Now the compiler changes the order
> here and suddenly the bug is gone!
> So I think the more appropriate question would be: why is having
> them in a single line so important that you would risk doing
> this to yourself or a fellow developer?
> Personally I am fan of splitting things into lines anyway when
> the cost is minimal, like
> uint64_t r = (uint64_t)av_lfg_get(lfg) << 32;
> r += av_lfg_get(lfg);
> r &= 0x000fffffffffffff;
No problem, I don't mind at all and actually like multiple lines
myself. Changed and posted v3. Thanks.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
