uniform function from standard library doesn't work correctly with standard BigInt. There are no indications anywhere that it shouldn't work, so I think it is a bug. Code sample: import std.stdio; import std.bigint; import std.random; void main() { BigInt x = uniform!"[]"(BigInt(1), BigInt(1000)); writefln("%s", x); } Compilation error: /usr/include/d/dmd/phobos/std/conv.d(322): Error: function std.bigint.BigInt.toString (void delegate(const(char)[]) sink, string formatString) const is not callable using argument types () /usr/include/d/dmd/phobos/std/conv.d(322): Error: expected 2 function arguments, not 0 Linux i686, dmd 2.052
The error message is the one returned when std.conv.to!string(BigInt) is called. std.bigint doesn't support std.conv.to!string. (You know all about this from 5231.) This has been reported several times already.
(In reply to comment #1) > The error message is the one returned when std.conv.to!string(BigInt) is > called. > > std.bigint doesn't support std.conv.to!string. (You know all about this from > 5231.) This has been reported several times already. Yes, I know. But isn't it strange that the standard library is inconsistent with itself? Shouldn't decisions like "remove a function which other parts of library expect to be" be more deliberate? I haven't seen such problems in any of the languages I used, and I think it is not good for the language itself to have them.
(In reply to comment #1) > The error message is the one returned when std.conv.to!string(BigInt) is > called. > > std.bigint doesn't support std.conv.to!string. (You know all about this from > 5231.) This has been reported several times already. More accurately, to!string doesn't support std.bigint.
Original sample code cannot yet compile, but error messages are different. C:\dmd2\src\phobos\std\random.d(1045): Error: template std.random.uniform does not match any function template declaration C:\dmd2\src\phobos\std\random.d(1043): Error: template std.random.uniform cannot deduce template function from argument types !("[]",igInt,BigInt,MersenneTwisterEngine!(uint,32,624,397,31,-1727483681u,11,7,-1658038656u,15,-272236544u,18))(BigInt,BigInt,MersenneTwistrEngine!(uint,32,624,397,31,-1727483681u,11,7,-1658038656u,15,-272236544u,18)) C:\dmd2\src\phobos\std\random.d(1045): Error: template instance uniform!("[]",BigInt,BigInt,MersenneTwisterEngine!(uint,32,624,397,31-1727483681u,11,7,-1658038656u,15,-272236544u,18)) errors instantiating template test.d(8): Error: template instance std.random.uniform!("[]",BigInt,BigInt) error instantiating test.d(8): Error: template std.bigint.BigInt.__ctor does not match any function template declaration C:\dmd2\src\phobos\std\bigint.d(82): Error: template std.bigint.BigInt.__ctor cannot deduce template function from argument types !()_error_) Because BigInt type is not integral. import std.traits; pragma(msg, isIntegral!BigInt); // pritns false
(In reply to comment #4) > Because BigInt type is not integral. > > import std.traits; > pragma(msg, isIntegral!BigInt); // pritns false Maybe we'll need to add to std.traits a new trait that's true for all integral values, BigInts too.
(In reply to comment #5) > (In reply to comment #4) > > > Because BigInt type is not integral. > > > > import std.traits; > > pragma(msg, isIntegral!BigInt); // pritns false > > Maybe we'll need to add to std.traits a new trait that's true for all integral > values, BigInts too. It's a bit difficult. If BigInt used the same algorithm for random number generation that built-in ints use, the performance would be horrible. For an n-byte number, you'd have O(2n) memory allocations on average, with an unbounded worst case, instead of the single allocation you'd have with a dedicated algorithm. And generating a string of 1 million random bits is the sort of thing that somebody is likely to do. Supporting it with terrible performance isn't any better than not supporting it at all.
(In reply to comment #0) > uniform function from standard library doesn't work correctly with standard > BigInt. There are no indications anywhere that it shouldn't work, so I think it is a bug. Typical existing RNGs may be expected to have an underlying range of 0 .. uint.max, with others perhaps extending that to ulong.max. They inherently can't cover the range of possible values that a BigInt can be expected to take, so there's a strong potential for statistical problems (albeit that those maxima are Very Big Indeed). It might be possible to do some customization so that BigInts falling within the appropriate bounds can be used -- probably your best bet would be to convert to uints, call the integral-type uniform() and convert back -- but in general generating random BigInts would require a BigInt-dedicated RNG.