On Sunday, 23 December 2012 at 14:43:25 UTC, Andrei Alexandrescu
wrote:
On 12/23/12 9:08 AM, foobar wrote:
Regarding std.algorithm, the module isn't called - 'classic,
consecrated
algorithms the kind you'll find in a book entitled
"Algorithms"'. It is
simply called 'std.algorithm' and there are many, *many* books
on
algorithms. Should this module include concurrent algorithms?
Should it
include distributed algorithms? Should it include statistic
algorithms?
Should it include natural language processing algorithms?
Should it
include genetic algorithms? I think it's clear by now that the
name does
not convey what you intend it to convey.
Importing std.container doesn't mean all containers conceivable
will be there, and so on. Sense and sensibility must always be
exercised.
A much better and more user friendly scheme would be to
classify the
algorithms by their *functionality* and not by some undefined
"belongs
to classical algorithms books" relation.
e.g. "Sorting algorithms", "Set operations", etc.
Now, if I want to sort something I know to "shop" at the
"sorting
algorithms" outlet and don't need to spend time going over a
potentially
infinite list of algorithms.
I like std.algorithm the way it is.
Andrei
On Sunday, 23 December 2012 at 14:43:25 UTC, Andrei Alexandrescu
wrote:
On 12/23/12 9:08 AM, foobar wrote:
Regarding std.algorithm, the module isn't called - 'classic,
consecrated
algorithms the kind you'll find in a book entitled
"Algorithms"'. It is
simply called 'std.algorithm' and there are many, *many* books
on
algorithms. Should this module include concurrent algorithms?
Should it
include distributed algorithms? Should it include statistic
algorithms?
Should it include natural language processing algorithms?
Should it
include genetic algorithms? I think it's clear by now that the
name does
not convey what you intend it to convey.
Importing std.container doesn't mean all containers conceivable
will be there, and so on. Sense and sensibility must always be
exercised.
A much better and more user friendly scheme would be to
classify the
algorithms by their *functionality* and not by some undefined
"belongs
to classical algorithms books" relation.
e.g. "Sorting algorithms", "Set operations", etc.
Now, if I want to sort something I know to "shop" at the
"sorting
algorithms" outlet and don't need to spend time going over a
potentially
infinite list of algorithms.
I like std.algorithm the way it is.
Andrei
Same here. In my mind it's about generality:
General purpose algorithms (sort, partition etc.) belong in
std.algorithm and more specific algorithms belong in their own
appropriately named modules.
