On Wednesday, 19 March 2014 at 01:52:07 UTC, bearophile wrote:
>> nor to contain the most optimized algorithms around.
>
> This D1 code adapted from C code is much more efficient (and in D2 with ranges and TypeTuple-foreach it could become more efficient and much shorter), but I think something like this is overkill for Phobos:
>
> http://dpaste.dzfl.pl/cf97d15ade27
>
> Bye,
> bearophile

If all that complexity is nicely encapsulated from the user, then why not put it in some theoretical Phobos package? Are you thinking of highly-optimized functionality that makes a usability tradeoff to be even faster?

On Wednesday, 19 March 2014 at 01:29:16 UTC, bearophile wrote:

> I suggest a Phobos module named "combinatorics" (or just "combs"?). It's not meant to be a complete library of combinatorics algorithms, nor to contain the most optimized algorithms around. It's meant to be a collection of efficient but sufficiently short implementations of the few algorithms/ranges you need most often. Everything else, including the most efficient code, I my opinion should be left to specialized numerical libraries external to Phobos (or could be added later if Phobos gains more developers).
>
> I think the most commonly useful functions are:
>
> - A lazy range (a simple unbounded segmented Sieve) that generates primes numbers very quickly, in a given range, or from 2;
> - A isPrime() function. Probably it should cache some of its computations.
>
> - A function to compute the GCD on ulongs/longs/bigints is useful.
> (Issues 4125 and 7102).
>
> - An efficient and as much as possibly overflow-safe binomial(n,k) that returns a single number.
>
> I'd also like permutations/combinations/pairwise ranges (Phobos already has a permutations, but it's designed on the legacy C++ style of functions, so it's not good enough).
> (See ER issue 6788 for pairwise. A the moment I can't find my Bugzilla ER entry for permutations/combinations, but you can see the good API for the permutations/combinations ranges in the code I have written here: http://rosettacode.org/wiki/Permutations#Fast_Lazy_Version  See also the good API of the Python combinations/permutations here: http://docs.python.org/3/library/itertools.html#itertools.permutations
>  note also the useful "r" and "repeat" arguments).
>
> With such 7 functions/ranges you can do lot of things :-)
>
> Bye,
> bearophile


I've wanted exactly this. I was doing the euler project problems and had to implement my own prime sieve, isPrime range, GCD, binomial, and combination function (I used Phobos' permutation function, but was a bit disappointed that it wasn't implemented as a range). Being familiar with the Python combinations/permutations functions, I was looking for similar functionality in Phobos and was sad to find it missing. So +1 for a combinatorics module, and for a numerical/prime module.

Meta:

> If all that complexity is nicely encapsulated from the user, then why not put it in some theoretical Phobos package?

For practical reasons. You have to maintain Phobos code. So you need people that understands the code. A very complex implementation is understood only by few persons. Also a very long piece of code needs more work to be maintained. Every line of code has a live cost.

Bye,
bearophile

I miss so much a std.geometry library with operations on 1d 2d and 3d objects (intersections, unions, difference, and so on...) in d style...

It would open a whole new world for me :)

On Wednesday, 19 March 2014 at 01:42:38 UTC, bearophile wrote:
>> - A function to compute the GCD on ulongs/longs/bigints is useful.
>> (Issues 4125 and 7102).
>
> A GCD is already in Phobos but it doesn't work with bigints. And putting it in the std.combinatorics is better.
>
> Bye,
> bearophile

Dan Killebrew:

>and had to implement my own prime sieve, isPrime range,<

The sieve is a range, but isPrime() is just a predicate function (possibly only logically pure, to store some precedent computation), it's not a range.

Bye,
bearophile

Am Wed, 19 Mar 2014 11:22:55 +0000
schrieb "Andrea Fontana" <nospam@example.com>:

> I miss so much a std.geometry library with operations on 1d 2d and 3d objects (intersections, unions, difference, and so on...) in d style...
> 
> It would open a whole new world for me :)

I wonder if we could finally have that experimental package,
call it "ext" or "etc" or whatever that has only one barrier
to entry: the intent of the module must pass review. The
API and code can build up over time as people start using
it. At some point it can be called finished and thoroughly
reviewed. I think the barrier of entry is currently very high
since the reviews expect perfect quality from the start, but
good things need time to collect corner cases and use cases
that might cause major refactorings.

It's straight forward to implement for rectangles or circles,
but would any design still be good when someone tries to
implement a 2D physics engine on top of that? Would CSG
operations be part of the module? What about paths, curves and
loading from and saving to vector graphics (SVG)?
(I.e. you could literally draw the collision shape of a tree
bitmap in Inkscape and load it as 2D geometry.)

-- 
Marco

Am Wed, 19 Mar 2014 10:39:36 +0000
schrieb "bearophile" <bearophileHUGS@lycos.com>:

> Meta:
> 
> > If all that complexity is nicely encapsulated from the user, then why not put it in some theoretical Phobos package?
> 
> For practical reasons. You have to maintain Phobos code. So you need people that understands the code. A very complex implementation is understood only by few persons. Also a very long piece of code needs more work to be maintained. Every line of code has a live cost.
> 
> Bye,
> bearophile

For starters there are a lot of code blocks that differ only in 1 or 2 values. These should be extracted into inline functions with a nice name.

-- 
Marco

On 3/19/14, 7:07 AM, Marco Leise wrote:
> I wonder if we could finally have that experimental package,
> call it "ext" or "etc" or whatever that has only one barrier
> to entry: the intent of the module must pass review.

I think it's time to add an experimental package.

Andrei

I don't need a package to build an engine on top of it. If you're going to write a game with 3d and physic probably you're going to use ogre, irrlicht, physx or everything else. And they have their own optimized implementation of these objects.

But a geometry package is not only for game or physics. Just an example: I wrote (in c++) an app to merge two images. Here a test: http://www.e-nuts.net/test2.jpg (the right image is an automatic merge of the other two). In this case a geometry package would simplify my life a lot :)

Another thing I would like to do is a generator of solids to print with a 3d printer. Some strange math objects. Or maybe a slicer for 3d printer's software stack. Or something like openscad.

Here we need productivity rather than realtime performance.

On Wednesday, 19 March 2014 at 14:05:19 UTC, Marco Leise wrote:
> Am Wed, 19 Mar 2014 11:22:55 +0000
> schrieb "Andrea Fontana" <nospam@example.com>:
>
>> I miss so much a std.geometry library with operations on 1d 2d and 3d objects (intersections, unions, difference, and so on...) in d style...
>> 
>> It would open a whole new world for me :)
>
> I wonder if we could finally have that experimental package,
> call it "ext" or "etc" or whatever that has only one barrier
> to entry: the intent of the module must pass review. The
> API and code can build up over time as people start using
> it. At some point it can be called finished and thoroughly
> reviewed. I think the barrier of entry is currently very high
> since the reviews expect perfect quality from the start, but
> good things need time to collect corner cases and use cases
> that might cause major refactorings.
>
> It's straight forward to implement for rectangles or circles,
> but would any design still be good when someone tries to
> implement a 2D physics engine on top of that? Would CSG
> operations be part of the module? What about paths, curves and
> loading from and saving to vector graphics (SVG)?
> (I.e. you could literally draw the collision shape of a tree
> bitmap in Inkscape and load it as 2D geometry.)

Andrei Alexandrescu píše v St 19. 03. 2014 v 08:02 -0700:
> On 3/19/14, 7:07 AM, Marco Leise wrote:
> > I wonder if we could finally have that experimental package, call it "ext" or "etc" or whatever that has only one barrier to entry: the intent of the module must pass review.
> 
> I think it's time to add an experimental package.
> 
> Andrei
> 
> 
+1 it will be improvement