Andrei Alexandrescu:
> I plan to overhaul a number of modules in Phobos2, such as std.algorithm, std.stdio, and std.random.

Regarding std.stdio: the current function writeln() has a large amount of faults. I have fixed about 20 of them in my put()/putr() and str()/repr() functions, but not all them. You can copy part of the code of them from my libs, and I can list some things in this newsgroup.

-------------

Regarding std.random: it has to reconcile a wide variety of purposes and needs, often one against each other:
1) It has to allow to write short & quick code;
2) It has to give random numbers very quickly;
3) It has to give high quality random numbers;
4) It has to be used in multi-threaded code.
5) It must be able to perform the most handy and common functions.

I think that can be solved adding 3 RND generators and various helper functions. Three different random generators can cover most usage cases: a very fast one, a good one fast enough, and a very good one.
- The very fast one is thread-safe, can be based on R250-521.
- The default one isn't thread-safe and it's designed for most cases. Not being thread-safe you don't need to create a struct/class to use it, so it allows a short and handy syntax. It can be Kiss used by Tango.
- The precise one can be thread-safe, a new version of Mersenne Twister is okay.

The helper functions can generate: random integer in closed interval, random integer in interval open on the right, uniform real value in interval, Gaussian real value, random choice among given items, in-place shuffling of sequence, not in-place shuffling, sampling with and without replacement from a given sequence of items. Many more things are possible, but those cover a lot of cases.

My d.random module is based on this design, even if few bits aren't finished yet (the R250-521 isn't integrated yet, there's a fault I have recently found in the randInt()).

Bye,
bearophile

Andrei Alexandrescu wrote:
> I plan to overhaul a number of modules in Phobos2, such as std.algorithm, std.stdio, and std.random. The changes will render existing code using those modules largely uncompilable. I wonder what a good evolution scheme we should adopt. Walter suggested that I move the old modules in etc/, so changing e.g. std.algorithm to etc.algorithm should make legacy code work.
> 
> Is this agreeable? Are there better possibilities?

Since one of the examples given as an aim of the Tango/Phobos merger was to allow std.algorithm to work with Tango IO, it would be a shame to miss the opportunity to improve compatibility.

Your post appeared 5 times, please check your posting software.

On Sun, 19 Oct 2008 13:28:28 -0700, Walter Bright wrote:

> Your post appeared 5 times, please check your posting software.

I noticed. Pan (my news reader) took quite some time to send that message.
It worked before. :/

KennyTM~ wrote:
> Jason House wrote:
>> Andrei Alexandrescu Wrote:
>>
>>> I plan to overhaul a number of modules in Phobos2, such as std.algorithm, std.stdio, and std.random. The changes will render existing code using those modules largely uncompilable. I wonder what a good evolution scheme we should adopt. Walter suggested that I move the old modules in etc/, so changing e.g. std.algorithm to etc.algorithm should make legacy code work.
>>>
>>> Is this agreeable? Are there better possibilities?
>>>
>>>
>>> Thanks,
>>>
>>> Andrei
>>
>> D has a deprecated keyword... Could that be used?
>>
> 
> vote++ for deprecated;
> 

Perhaps depreciated code could be put under file.deprecated.d (or file.dep.d) and included by the new file, along with the deprecated word, just to keep things tidy.

-Joel