Re: drand48() gives wrong sequence?

Re: drand48() gives wrong sequence?

[Nadav Har'El]

[-- Attachment #1: Type: text/plain, Size: 1130 bytes --]

>Am Sonntag, den 21.09.2014, 14:45 +0300 schrieb Nadav Har'El:
>> Any ideas why I'm getting the wrong sequence?
>
>I don't think you are getting the wrong sequence, you are just
>printing it wrong. "%ld" is for long double and not for double.
>
>Jens

(I tried to subscribe to the mailing list but it didn't work, so please CC
me with further responses).

"%ld" is not a double at all, it's an int.

My message's title was indeed somewhat confusing, because I mentioned
drand48() in the title but used lrand48() in my example code. I saw the
same problem of a different sequence also with drand48() (printed with %g
of course) - but at the end decided to include code which printed lrand48().

Anyway, "%ld" is the right thing to use here because lrand48() returns a
"long int".
Replacing it with "%d" makes no difference and the sequences are still
different (I tried). This is because while lrand48()'s type is officially
"long", its return value is just 32-bit, so one can treat it just fine as
either long (64-bit on my 64-bit machine) or int (32-bit) and you get the
same result.



-- 
Nadav Har'El
nyh@cloudius-systems.com

[-- Attachment #2: Type: text/html, Size: 1564 bytes --]

Re: Re: drand48() gives wrong sequence?

[Jens Gustedt]

[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]

Am Sonntag, den 21.09.2014, 15:20 +0300 schrieb Nadav Har'El:
> >Am Sonntag, den 21.09.2014, 14:45 +0300 schrieb Nadav Har'El:
> >> Any ideas why I'm getting the wrong sequence?
> >
> >I don't think you are getting the wrong sequence, you are just
> >printing it wrong. "%ld" is for long double and not for double.
> >
> >Jens
> (I tried to subscribe to the mailing list but it didn't work, so
> please CC me with further responses).
> 
> 
> "%ld" is not a double at all, it's an int.

> My message's title was indeed somewhat confusing, because I mentioned
> drand48() in the title but used lrand48() in my example code.

ah, right, still my association of %ld to long double was a bit hasty,
sorry for the noise.

Jens

-- 
:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::




[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Re: drand48() gives wrong sequence?

[Jens Gustedt]

[-- Attachment #1: Type: text/plain, Size: 1444 bytes --]

Am Sonntag, den 21.09.2014, 15:57 +0200 schrieb Jens Gustedt:
> Am Sonntag, den 21.09.2014, 15:45 +0200 schrieb Jens Gustedt:
> > Am Sonntag, den 21.09.2014, 14:27 +0100 schrieb Justin Cormack:
> > > Hmm, just checked on a non-OSv Musl system and get the same result as
> > > you. I also checked on NetBSD and FreeBSD and they give the same
> > > result as glibc, so I think there must be a Musl bug.
> > 
> > In __rand48_step there is this line
> > 
> > 	x = xi[0] | xi[1]<<16 | xi[2]+0ULL<<32;
> > 
> > on arch with 16bit int this would be UB, no? Do we have such archs,
> > still?
> 
> Thinking of it, it is UB even on platforms with 32bit if the high
> order bit in the unsigned short is set. We then have
> 
> unsigned short --> int --> shifted value inside int --> unsigned long
> 
> So we better shouldn't do that in any case.

Changing the code as I indicated early (adding these "casts") seems to
fix the problem for me.

In fact the problem didn't occur directly with your initial seed, but
simply with the default value of the multiplicator "A", which has bit
16 set.

I prepare a patch.

Jens


-- 
:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Re: drand48() gives wrong sequence?

[Jens Gustedt]

[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]

Am Sonntag, den 21.09.2014, 15:45 +0200 schrieb Jens Gustedt:
> Am Sonntag, den 21.09.2014, 14:27 +0100 schrieb Justin Cormack:
> > Hmm, just checked on a non-OSv Musl system and get the same result as
> > you. I also checked on NetBSD and FreeBSD and they give the same
> > result as glibc, so I think there must be a Musl bug.
> 
> In __rand48_step there is this line
> 
> 	x = xi[0] | xi[1]<<16 | xi[2]+0ULL<<32;
> 
> on arch with 16bit int this would be UB, no? Do we have such archs,
> still?

Thinking of it, it is UB even on platforms with 32bit if the high
order bit in the unsigned short is set. We then have

unsigned short --> int --> shifted value inside int --> unsigned long

So we better shouldn't do that in any case.

Jens

-- 
:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Re: drand48() gives wrong sequence?

[Jens Gustedt]

[-- Attachment #1: Type: text/plain, Size: 913 bytes --]

Am Sonntag, den 21.09.2014, 14:27 +0100 schrieb Justin Cormack:
> Hmm, just checked on a non-OSv Musl system and get the same result as
> you. I also checked on NetBSD and FreeBSD and they give the same
> result as glibc, so I think there must be a Musl bug.

In __rand48_step there is this line

	x = xi[0] | xi[1]<<16 | xi[2]+0ULL<<32;

on arch with 16bit int this would be UB, no? Do we have such archs,
still?

In any case, doing something like

	x = xi[0]+0ULL | xi[1]+0ULL<<16 | xi[2]+0ULL<<32;

shouldn't cost anything and should ensure the correct conversion in
all cases.

Jens

-- 
:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]