401 reputation
213
bio website
location Moscow, Russia
age
visits member for 4 years, 3 months
seen Oct 30 at 17:59

isidore.john.r at gmail dot com


Oct
1
comment How to efficiently generate large, uniformly distributed, random integers in bash?
indeed, uL (long) is the minimum that bash must support, gnu bash uses maxint_t type that is equal or larger than long. od should be extended to support maxint_t.
Sep
30
revised How to convert an unsigned decimal (less than 1<<32) to 4 bytes (binary) in bash?
remove unnecessary quotes
Sep
30
suggested approved edit on How to convert an unsigned decimal (less than 1<<32) to 4 bytes (binary) in bash?
Sep
30
comment How to convert an unsigned decimal (less than 1<<32) to 4 bytes (binary) in bash?
I don't see how dc converts a decimal number e.g., 1193046 to 4 bytes as the code in my question and the other two answers does.
Sep
30
revised How to convert an unsigned decimal (less than 1<<32) to 4 bytes (binary) in bash?
4 bytes, not 8
Sep
30
comment How to convert an unsigned decimal (less than 1<<32) to 4 bytes (binary) in bash?
+1. It produces the correct 4 bytes for 0..2**32-1 range, It uses only builtin printf command, and It is faster (for a single number).
Sep
30
comment How to efficiently generate large, uniformly distributed, random integers in bash?
if you want to support the full bash range then uL (long) might be too small if bash uses maxint_t (or long long if they are different). long long is not a typo.
Sep
30
comment How to efficiently generate large, uniformly distributed, random integers in bash?
there is long long that can be 64bit while int=long=32bit on some platforms. You should not claim 0..2**60 range if you can't guarantee it on all platforms. On the other hand bash might not support this range itself on such platforms (I don't know, perhaps it uses maxint_t and then u8 is more correct if you want to assert the fixed range (od doesn't support specifying maxint if yours range is whatever bash's platform-dependent? range is). If the bash range depends on sizeof long then uL might be more appropriate). Do you want the full range that bash supports on all OSes or a fixed range?
Sep
27
comment How to efficiently generate large, uniformly distributed, random integers in bash?
uL implies sizeof(long)>=8 for the range. It is not guaranteed. You could use u8 to assert that platform has such integer.
Sep
27
comment How to efficiently generate large, uniformly distributed, random integers in bash?
your solution reminds me how random.py is written. random.Random class uses 53bit? generator to return arbitrary large random numbers (multiple invocations), random.SystemRandom does the same using os.urandom() that can be implemented using /dev/urandom.
Sep
27
comment How to efficiently generate large, uniformly distributed, random integers in bash?
your solution assumes that sizeof(int) == 8 (64bit) due to --format=u
Sep
27
awarded  Yearling
Sep
27
revised How to convert an unsigned decimal (less than 1<<32) to 4 bytes (binary) in bash?
update random generator to correspond to the question
Sep
27
suggested approved edit on How to convert an unsigned decimal (less than 1<<32) to 4 bytes (binary) in bash?
Sep
27
accepted How to convert an unsigned decimal (less than 1<<32) to 4 bytes (binary) in bash?
Sep
27
revised How to convert an unsigned decimal (less than 1<<32) to 4 bytes (binary) in bash?
generate 32bit number, print 4 bytes always
Sep
26
comment How to efficiently generate large, uniformly distributed, random integers in bash?
@l0b0: I'm sure there are many issues with /dev/(u)random on different systems. It doesn't change the suggestion that you should use /dev/urandom by default
Sep
26
comment How to efficiently generate large, uniformly distributed, random integers in bash?
--format=u should be replaced with --format=u4 because sizeof(int) may be less than 4 in theory.
Sep
26
comment How to efficiently generate large, uniformly distributed, random integers in bash?
@MalteSkoruppa: I stands for sizeof(int) that may be less than 4 in principle. btw, od -DAn fails for (2**32-1) but od -N4 -tu4 -An continues to work.
Sep
26
comment How to efficiently generate large, uniformly distributed, random integers in bash?
It should be the exact opposite: use /dev/urandom unless you know that you need /dev/random. It is incorrect to assume that /dev/urandom results are so much worse than /dev/random that urandom is not usable in most cases. Once /dev/urandom is initialized (at the start of the system); its results are as good as /dev/random for almost all applications on Linux. On some systems random and urandom are the same.