Can drand48() ever return 1?
up vote
3
down vote
favorite
The manual of drand48()
says:
The drand48() and erand48() functions return non-negative,
double-precision, floating-point values, uniformly distributed over
the interval [0.0 , 1.0].
(source)
So just for clarification: Does this mean that 1.0 can be returned by drand48()
? Or does it mean that the return value will be < 1.0?
I'm asking because in a brute force test drand48()
never seems to return 1.0. It often returns 0, but never 1.0. However, for me the manual of drand48()
seems to say that 1.0 is indeed a result that could come up, although I haven't been able to make drand48()
return 1.0 in practice.
Anybody here who can shed some light onto this? Will the result always be less than 1.0 or can it also be equal to 1.0?
c random posix
add a comment |
up vote
3
down vote
favorite
The manual of drand48()
says:
The drand48() and erand48() functions return non-negative,
double-precision, floating-point values, uniformly distributed over
the interval [0.0 , 1.0].
(source)
So just for clarification: Does this mean that 1.0 can be returned by drand48()
? Or does it mean that the return value will be < 1.0?
I'm asking because in a brute force test drand48()
never seems to return 1.0. It often returns 0, but never 1.0. However, for me the manual of drand48()
seems to say that 1.0 is indeed a result that could come up, although I haven't been able to make drand48()
return 1.0 in practice.
Anybody here who can shed some light onto this? Will the result always be less than 1.0 or can it also be equal to 1.0?
c random posix
1
Often 0 is suspicious.
– Yves Daoust
Nov 22 at 15:58
What documentation are you looking at? Theman
page fordrand48
on my macOS system says “The full 48 bits of r(n+1) are loaded into the mantissa of the returned value, with the exponent set such that the values produced lie in the interval [0.0, 1.0).”
– Eric Postpischil
Nov 22 at 16:05
1
The old Open Group page fordrand48
does have a closed interval. That may be a bug in the documentation. The 2018 edition seems to have fixed it.
– Eric Postpischil
Nov 22 at 16:06
See my edit for link.
– Andreas
Nov 22 at 16:06
add a comment |
up vote
3
down vote
favorite
up vote
3
down vote
favorite
The manual of drand48()
says:
The drand48() and erand48() functions return non-negative,
double-precision, floating-point values, uniformly distributed over
the interval [0.0 , 1.0].
(source)
So just for clarification: Does this mean that 1.0 can be returned by drand48()
? Or does it mean that the return value will be < 1.0?
I'm asking because in a brute force test drand48()
never seems to return 1.0. It often returns 0, but never 1.0. However, for me the manual of drand48()
seems to say that 1.0 is indeed a result that could come up, although I haven't been able to make drand48()
return 1.0 in practice.
Anybody here who can shed some light onto this? Will the result always be less than 1.0 or can it also be equal to 1.0?
c random posix
The manual of drand48()
says:
The drand48() and erand48() functions return non-negative,
double-precision, floating-point values, uniformly distributed over
the interval [0.0 , 1.0].
(source)
So just for clarification: Does this mean that 1.0 can be returned by drand48()
? Or does it mean that the return value will be < 1.0?
I'm asking because in a brute force test drand48()
never seems to return 1.0. It often returns 0, but never 1.0. However, for me the manual of drand48()
seems to say that 1.0 is indeed a result that could come up, although I haven't been able to make drand48()
return 1.0 in practice.
Anybody here who can shed some light onto this? Will the result always be less than 1.0 or can it also be equal to 1.0?
c random posix
c random posix
edited Nov 22 at 16:06
asked Nov 22 at 15:57
Andreas
2,17712144
2,17712144
1
Often 0 is suspicious.
– Yves Daoust
Nov 22 at 15:58
What documentation are you looking at? Theman
page fordrand48
on my macOS system says “The full 48 bits of r(n+1) are loaded into the mantissa of the returned value, with the exponent set such that the values produced lie in the interval [0.0, 1.0).”
– Eric Postpischil
Nov 22 at 16:05
1
The old Open Group page fordrand48
does have a closed interval. That may be a bug in the documentation. The 2018 edition seems to have fixed it.
– Eric Postpischil
Nov 22 at 16:06
See my edit for link.
– Andreas
Nov 22 at 16:06
add a comment |
1
Often 0 is suspicious.
– Yves Daoust
Nov 22 at 15:58
What documentation are you looking at? Theman
page fordrand48
on my macOS system says “The full 48 bits of r(n+1) are loaded into the mantissa of the returned value, with the exponent set such that the values produced lie in the interval [0.0, 1.0).”
– Eric Postpischil
Nov 22 at 16:05
1
The old Open Group page fordrand48
does have a closed interval. That may be a bug in the documentation. The 2018 edition seems to have fixed it.
– Eric Postpischil
Nov 22 at 16:06
See my edit for link.
– Andreas
Nov 22 at 16:06
1
1
Often 0 is suspicious.
– Yves Daoust
Nov 22 at 15:58
Often 0 is suspicious.
– Yves Daoust
Nov 22 at 15:58
What documentation are you looking at? The
man
page for drand48
on my macOS system says “The full 48 bits of r(n+1) are loaded into the mantissa of the returned value, with the exponent set such that the values produced lie in the interval [0.0, 1.0).”– Eric Postpischil
Nov 22 at 16:05
What documentation are you looking at? The
man
page for drand48
on my macOS system says “The full 48 bits of r(n+1) are loaded into the mantissa of the returned value, with the exponent set such that the values produced lie in the interval [0.0, 1.0).”– Eric Postpischil
Nov 22 at 16:05
1
1
The old Open Group page for
drand48
does have a closed interval. That may be a bug in the documentation. The 2018 edition seems to have fixed it.– Eric Postpischil
Nov 22 at 16:06
The old Open Group page for
drand48
does have a closed interval. That may be a bug in the documentation. The 2018 edition seems to have fixed it.– Eric Postpischil
Nov 22 at 16:06
See my edit for link.
– Andreas
Nov 22 at 16:06
See my edit for link.
– Andreas
Nov 22 at 16:06
add a comment |
2 Answers
2
active
oldest
votes
up vote
6
down vote
accepted
"over the interval [0.0 , 1.0]." It is safe to assume mathematical notation of interval. Parenthesis interval ends are exclusive and square brackets interval ends are inclusive. So according to the notation the returned value can be 1.0
.
However this is a documentation of an old version and the current ones specify [0.0, 1.0)
as the interval (which means it can't be 1.0
):
The Single UNIX ® Specification, Version 2 http://pubs.opengroup.org/onlinepubs/7908799/xsh/drand48.html
lists
[0.0, 1.0]
while
The Open Group Base Specifications Issue 7, 2018 edition
http://pubs.opengroup.org/onlinepubs/9699919799/functions/drand48.htmlLinux Man Pages - POSIX.1-2001
https://www.systutorials.com/docs/linux/man/3-drand48/Linux man page - POSIX.1-2001.
https://linux.die.net/man/3/erand48
all list
[0.0, 1.0)
So I would be inclined to believe [0.0, 1.0)
is the correct specification. (it could be that the definition changed since SUS2 which is from 1997 or that it is a typo on the page, but I have no expertise on this so I won't weigh in)
in a brute force test drand48() never seems to return 1.0. It often
returns 0, but never 1.0.
This seems highly suspicious. 0.0
should be have the same probability to appear as any other number in the interval so "It often returns 0" doesn't look right. Check that you print with full precision.
As a side note be aware that dran48 and friends are obsolete
So can we assume that the first link contains a typo? That would confirm my observations that 1.0 indeed never comes up.
– Andreas
Nov 22 at 16:09
@Andreas I think yes
– bolov
Nov 22 at 16:12
@Andreas Since the SUS2 is from 1997 it is also possible that the definition changed since then.
– Swordfish
Nov 22 at 16:12
Is that possible? Aren't those APIs required to be stable?
– Andreas
Nov 22 at 16:15
@Swordfish ty for the link and yes, it could be. I absolutely don't know
– bolov
Nov 22 at 16:18
|
show 3 more comments
up vote
0
down vote
You are looking at a very old POSIX documentation. The POSIX 2017 for drand48 says:
The drand48() and erand48() functions shall return non-negative,
double-precision, floating-point values, uniformly distributed over
the interval [0.0,1.0).
This is also consistent with Linux man pages (which typically represents glibc implementation).
The same appears in POSIX 2001 too.
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
6
down vote
accepted
"over the interval [0.0 , 1.0]." It is safe to assume mathematical notation of interval. Parenthesis interval ends are exclusive and square brackets interval ends are inclusive. So according to the notation the returned value can be 1.0
.
However this is a documentation of an old version and the current ones specify [0.0, 1.0)
as the interval (which means it can't be 1.0
):
The Single UNIX ® Specification, Version 2 http://pubs.opengroup.org/onlinepubs/7908799/xsh/drand48.html
lists
[0.0, 1.0]
while
The Open Group Base Specifications Issue 7, 2018 edition
http://pubs.opengroup.org/onlinepubs/9699919799/functions/drand48.htmlLinux Man Pages - POSIX.1-2001
https://www.systutorials.com/docs/linux/man/3-drand48/Linux man page - POSIX.1-2001.
https://linux.die.net/man/3/erand48
all list
[0.0, 1.0)
So I would be inclined to believe [0.0, 1.0)
is the correct specification. (it could be that the definition changed since SUS2 which is from 1997 or that it is a typo on the page, but I have no expertise on this so I won't weigh in)
in a brute force test drand48() never seems to return 1.0. It often
returns 0, but never 1.0.
This seems highly suspicious. 0.0
should be have the same probability to appear as any other number in the interval so "It often returns 0" doesn't look right. Check that you print with full precision.
As a side note be aware that dran48 and friends are obsolete
So can we assume that the first link contains a typo? That would confirm my observations that 1.0 indeed never comes up.
– Andreas
Nov 22 at 16:09
@Andreas I think yes
– bolov
Nov 22 at 16:12
@Andreas Since the SUS2 is from 1997 it is also possible that the definition changed since then.
– Swordfish
Nov 22 at 16:12
Is that possible? Aren't those APIs required to be stable?
– Andreas
Nov 22 at 16:15
@Swordfish ty for the link and yes, it could be. I absolutely don't know
– bolov
Nov 22 at 16:18
|
show 3 more comments
up vote
6
down vote
accepted
"over the interval [0.0 , 1.0]." It is safe to assume mathematical notation of interval. Parenthesis interval ends are exclusive and square brackets interval ends are inclusive. So according to the notation the returned value can be 1.0
.
However this is a documentation of an old version and the current ones specify [0.0, 1.0)
as the interval (which means it can't be 1.0
):
The Single UNIX ® Specification, Version 2 http://pubs.opengroup.org/onlinepubs/7908799/xsh/drand48.html
lists
[0.0, 1.0]
while
The Open Group Base Specifications Issue 7, 2018 edition
http://pubs.opengroup.org/onlinepubs/9699919799/functions/drand48.htmlLinux Man Pages - POSIX.1-2001
https://www.systutorials.com/docs/linux/man/3-drand48/Linux man page - POSIX.1-2001.
https://linux.die.net/man/3/erand48
all list
[0.0, 1.0)
So I would be inclined to believe [0.0, 1.0)
is the correct specification. (it could be that the definition changed since SUS2 which is from 1997 or that it is a typo on the page, but I have no expertise on this so I won't weigh in)
in a brute force test drand48() never seems to return 1.0. It often
returns 0, but never 1.0.
This seems highly suspicious. 0.0
should be have the same probability to appear as any other number in the interval so "It often returns 0" doesn't look right. Check that you print with full precision.
As a side note be aware that dran48 and friends are obsolete
So can we assume that the first link contains a typo? That would confirm my observations that 1.0 indeed never comes up.
– Andreas
Nov 22 at 16:09
@Andreas I think yes
– bolov
Nov 22 at 16:12
@Andreas Since the SUS2 is from 1997 it is also possible that the definition changed since then.
– Swordfish
Nov 22 at 16:12
Is that possible? Aren't those APIs required to be stable?
– Andreas
Nov 22 at 16:15
@Swordfish ty for the link and yes, it could be. I absolutely don't know
– bolov
Nov 22 at 16:18
|
show 3 more comments
up vote
6
down vote
accepted
up vote
6
down vote
accepted
"over the interval [0.0 , 1.0]." It is safe to assume mathematical notation of interval. Parenthesis interval ends are exclusive and square brackets interval ends are inclusive. So according to the notation the returned value can be 1.0
.
However this is a documentation of an old version and the current ones specify [0.0, 1.0)
as the interval (which means it can't be 1.0
):
The Single UNIX ® Specification, Version 2 http://pubs.opengroup.org/onlinepubs/7908799/xsh/drand48.html
lists
[0.0, 1.0]
while
The Open Group Base Specifications Issue 7, 2018 edition
http://pubs.opengroup.org/onlinepubs/9699919799/functions/drand48.htmlLinux Man Pages - POSIX.1-2001
https://www.systutorials.com/docs/linux/man/3-drand48/Linux man page - POSIX.1-2001.
https://linux.die.net/man/3/erand48
all list
[0.0, 1.0)
So I would be inclined to believe [0.0, 1.0)
is the correct specification. (it could be that the definition changed since SUS2 which is from 1997 or that it is a typo on the page, but I have no expertise on this so I won't weigh in)
in a brute force test drand48() never seems to return 1.0. It often
returns 0, but never 1.0.
This seems highly suspicious. 0.0
should be have the same probability to appear as any other number in the interval so "It often returns 0" doesn't look right. Check that you print with full precision.
As a side note be aware that dran48 and friends are obsolete
"over the interval [0.0 , 1.0]." It is safe to assume mathematical notation of interval. Parenthesis interval ends are exclusive and square brackets interval ends are inclusive. So according to the notation the returned value can be 1.0
.
However this is a documentation of an old version and the current ones specify [0.0, 1.0)
as the interval (which means it can't be 1.0
):
The Single UNIX ® Specification, Version 2 http://pubs.opengroup.org/onlinepubs/7908799/xsh/drand48.html
lists
[0.0, 1.0]
while
The Open Group Base Specifications Issue 7, 2018 edition
http://pubs.opengroup.org/onlinepubs/9699919799/functions/drand48.htmlLinux Man Pages - POSIX.1-2001
https://www.systutorials.com/docs/linux/man/3-drand48/Linux man page - POSIX.1-2001.
https://linux.die.net/man/3/erand48
all list
[0.0, 1.0)
So I would be inclined to believe [0.0, 1.0)
is the correct specification. (it could be that the definition changed since SUS2 which is from 1997 or that it is a typo on the page, but I have no expertise on this so I won't weigh in)
in a brute force test drand48() never seems to return 1.0. It often
returns 0, but never 1.0.
This seems highly suspicious. 0.0
should be have the same probability to appear as any other number in the interval so "It often returns 0" doesn't look right. Check that you print with full precision.
As a side note be aware that dran48 and friends are obsolete
edited Nov 22 at 16:25
answered Nov 22 at 16:01
bolov
30.2k668128
30.2k668128
So can we assume that the first link contains a typo? That would confirm my observations that 1.0 indeed never comes up.
– Andreas
Nov 22 at 16:09
@Andreas I think yes
– bolov
Nov 22 at 16:12
@Andreas Since the SUS2 is from 1997 it is also possible that the definition changed since then.
– Swordfish
Nov 22 at 16:12
Is that possible? Aren't those APIs required to be stable?
– Andreas
Nov 22 at 16:15
@Swordfish ty for the link and yes, it could be. I absolutely don't know
– bolov
Nov 22 at 16:18
|
show 3 more comments
So can we assume that the first link contains a typo? That would confirm my observations that 1.0 indeed never comes up.
– Andreas
Nov 22 at 16:09
@Andreas I think yes
– bolov
Nov 22 at 16:12
@Andreas Since the SUS2 is from 1997 it is also possible that the definition changed since then.
– Swordfish
Nov 22 at 16:12
Is that possible? Aren't those APIs required to be stable?
– Andreas
Nov 22 at 16:15
@Swordfish ty for the link and yes, it could be. I absolutely don't know
– bolov
Nov 22 at 16:18
So can we assume that the first link contains a typo? That would confirm my observations that 1.0 indeed never comes up.
– Andreas
Nov 22 at 16:09
So can we assume that the first link contains a typo? That would confirm my observations that 1.0 indeed never comes up.
– Andreas
Nov 22 at 16:09
@Andreas I think yes
– bolov
Nov 22 at 16:12
@Andreas I think yes
– bolov
Nov 22 at 16:12
@Andreas Since the SUS2 is from 1997 it is also possible that the definition changed since then.
– Swordfish
Nov 22 at 16:12
@Andreas Since the SUS2 is from 1997 it is also possible that the definition changed since then.
– Swordfish
Nov 22 at 16:12
Is that possible? Aren't those APIs required to be stable?
– Andreas
Nov 22 at 16:15
Is that possible? Aren't those APIs required to be stable?
– Andreas
Nov 22 at 16:15
@Swordfish ty for the link and yes, it could be. I absolutely don't know
– bolov
Nov 22 at 16:18
@Swordfish ty for the link and yes, it could be. I absolutely don't know
– bolov
Nov 22 at 16:18
|
show 3 more comments
up vote
0
down vote
You are looking at a very old POSIX documentation. The POSIX 2017 for drand48 says:
The drand48() and erand48() functions shall return non-negative,
double-precision, floating-point values, uniformly distributed over
the interval [0.0,1.0).
This is also consistent with Linux man pages (which typically represents glibc implementation).
The same appears in POSIX 2001 too.
add a comment |
up vote
0
down vote
You are looking at a very old POSIX documentation. The POSIX 2017 for drand48 says:
The drand48() and erand48() functions shall return non-negative,
double-precision, floating-point values, uniformly distributed over
the interval [0.0,1.0).
This is also consistent with Linux man pages (which typically represents glibc implementation).
The same appears in POSIX 2001 too.
add a comment |
up vote
0
down vote
up vote
0
down vote
You are looking at a very old POSIX documentation. The POSIX 2017 for drand48 says:
The drand48() and erand48() functions shall return non-negative,
double-precision, floating-point values, uniformly distributed over
the interval [0.0,1.0).
This is also consistent with Linux man pages (which typically represents glibc implementation).
The same appears in POSIX 2001 too.
You are looking at a very old POSIX documentation. The POSIX 2017 for drand48 says:
The drand48() and erand48() functions shall return non-negative,
double-precision, floating-point values, uniformly distributed over
the interval [0.0,1.0).
This is also consistent with Linux man pages (which typically represents glibc implementation).
The same appears in POSIX 2001 too.
edited Nov 22 at 16:20
answered Nov 22 at 16:14
usr
13.6k22039
13.6k22039
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53434572%2fcan-drand48-ever-return-1%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Often 0 is suspicious.
– Yves Daoust
Nov 22 at 15:58
What documentation are you looking at? The
man
page fordrand48
on my macOS system says “The full 48 bits of r(n+1) are loaded into the mantissa of the returned value, with the exponent set such that the values produced lie in the interval [0.0, 1.0).”– Eric Postpischil
Nov 22 at 16:05
1
The old Open Group page for
drand48
does have a closed interval. That may be a bug in the documentation. The 2018 edition seems to have fixed it.– Eric Postpischil
Nov 22 at 16:06
See my edit for link.
– Andreas
Nov 22 at 16:06