std.string and ranges

[Andrei Alexandrescu]

bearophile wrote:
> Andrei Alexandrescu:
> 
>> What I see is that the std.algorithm has most of what you ask below,<
> 
> "shuffle"/"shuffler" are of course algorithms, but I think mixing all kind of algorithms into a module isn't good, it's better to move the random-related algorithms into std.random. It helps the memory of the programmer to know where to look for, and avoids lumping too many mixed things into a single module.

It's there. Read The Fine Manual:

http://www.digitalmars.com/d/2.0/phobos/std_random.html

>> int array[100];
>> auto rnd = Random(unpredictableSeed);
>> auto rndElement = array[uniform(rnd, 0, 100)];
> 
> That's just a starting point, now you can wrap that into a nice single function with this interface:
> choice(iterable)
> that works with any iterable, lazy too.
> I know that's slow code, but in many situations you don't care and you want handy and safe functions. And where you need max speed, you don't use it.

That would only work with ranges that know their length, right? I don't 
know how to select a random element of an infinite range or one that has 
an unknown length.

> I don't like this:
> uniform(rnd, 0, 100)
> This seems better:
> rnd.uniform(0, 100)
> Then 0 can be the default lower bound:
> rnd.uniform(100)
> And for simple usages you may just want the default struct:
> uniform(100)

Well this becomes nitpicky.

>>> - randInt: gives a random integer in an interval, the lower bound is zero by default.
>> auto randInt = uniform(rnd, 0, 10);
>>> - uniform: gives a random real/float/double in a given interval
>> double d = uniform(rnd, 0, 1);
> 
> How can uniform return ints or doubles according to the input? I think it may be better to have two different functions.
> (And you can optimize efficiency if you know you need an integral value as result).

I meant:

double d = uniform(rnd, 0.0, 1.0);

The "uniform" function infers the type of its result from its arguments.

> A normal(avg, stddev) function can be good too, where avg may be by default zero again :-)
> 
> A fastNormal(avg, stddev) function too can be useful, less precise but faster.

Where's the underlying random generator?

>>> - shuffled: like shuffle, but creates a copy of the items. Return an array.
>> auto another = array.dup;
>> randomShuffle(another, rnd);
> 
> shuffled() is meant to be used in a single line, so you can use it into an expression.
> And dup works with arrays only, so you need to put into shuffled() a call to something like the array() function of my libs to have something more general.

Right. So what you're saying is that the concern of copying is separated 
from the concern of shuffling. So the two shouldn't be collapsed 
together unless there's an obvious necessity or benefit. Saving a line 
of code doesn't seem convincing.

>>> - weightedChoice: like choice, but the user can specify the relative probability of choosing each item.<
>> auto x = dice(rnd, 70, 20, 10);<
> 
> I don't understand that interface, this isn't good.

Well it would be good if you read the documentation, which seems 
increasingly clear to me you haven't.

>> How does R250/521 compare with linear congruential and the Mersenne Twister engine?<
> 
> R250/521:
> - is generates better rnd values than linear congruential, and is a bit faster.
> - is faster than KISS.
> - is much much faster than Mersenne Twister.
> - needs few good rnd numbers to start, so they can be given by a Mersenne Twister (they may be even hard-coded).
> 
> 
>> Anyhow, it would be great to include more generators in Phobos, so if you plan to contribute some please let me know.<
> 
> I think it's better to not overdo the number of generators, and put there only few of them, that the programmer can tell apart in a simple way.

Well it looks like everyone thinks their favorite generator is the 
"best". As far as Phobos is concerned, the source for the design of 
std.random is inspired from 
http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf, which 
goes for defining several generators.


Andrei