std.string and ranges

[Denis Koroskin]

On Wed, 11 Feb 2009 19:14:38 +0300, Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> wrote:

> 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.
>

I'm with bearophile here. Not because his version is shorter, but because
1) some containers/ranges might not have a dup method
2) it is potentially faster because it may avoid unnecessary data copying (relevant for large arrays).

That said, having both versions is preferred by me with names like shuffle and shuffledCopy.
The same could be applied to sort - sortedCopy might be useful, too.

>>>> - 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