On Wed, 2014-03-19 at 17:01 +0000, Dicebot wrote:
[…]
> I know nothing about OpenGL but it was (and is) huge problem for Java.

Well sort of. Calling from Java into any C, C++ or D library can be a bit of a pain, involving JNI (or possibly JNA). JOGL has shown that Java calling OpenGL is doable and works. Likewise JavaFX connects into the OpenGL infrastructure. So this is now essentially a solved problem.

What is much more of a problem for Java is GPGPU parallelism. There are a couple of groups working on this and there will be a solution. There has to be as the team members of one of the teams actually have to make it work or start losing money.

[…]
> > Personally I avoid dub, so to that end I'm probably biased.
> 
> I avoid it too but it is my personal problem to deal with. dub is de-facto standard in D tool chain and I am pretty sure eventually will be distributed with dmd.

SCons currently has no real "play" in this dependency management area and given that all the support in the D community appears to be for Dub, there seems no point in adding the features to SCons.  Gradle has all the dependency management stuff sorted already and now has C and C++ build capability. I wonder if it might be worth adding D support to that?

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Tuesday, 18 March 2014 at 14:23:32 UTC, bearophile wrote:
> There is a efficient Sieve implementation in C++ here:
>
> http://code.activestate.com/recipes/577966-even-faster-prime-generator/?in=lang-cpp
>
> There are of course far faster implementations, but its performance is not bad, while being still simple and quite short.

Here's a straightforward implementation, if you don't already have one (I assume you're doing this for Rosetta Code). I had to decrease your MAX_N by 100-fold to get a similar runtime, but it's a fairly faithful implementation of Eratosthenes' method as written.

enum uint MAX_N = 10_000_000U;

void calcPrimes() pure nothrow {
    uint[][uint] markers;

    for (uint L = 2; L < MAX_N; L++) {
        uint[]* pList = (L in markers);
        if (pList is null) {
            markers[L + L] = [L];
        }
        else {
            uint[] list = *pList;
            size_t len = list.length - 1;
            for (uint L2 = 0; L2 < len; L2++) {
                uint val = list[L2];
                markers[ L + val ] ~= val;
            }

            // reuse the current list for the last item to save allocations
            list[0] = list[len];
            list.length = 1;
            markers[ L + list[len] ] = list;
        }
    }
}

void main() {
    calcPrimes;
}

Chris Williams:

> Here's a straightforward implementation, if you don't already have one (I assume you're doing this for Rosetta Code).

RosettaCode has already several sieves in D. I am not doing this for RosettaCode. What I am doing in this thread is to ask if there's desire for a efficient (quite more than your version) but still sufficiently simple implementation of a unbounded lazy Sieve range for Phobos.

Bye,
bearophile

On Wednesday, 19 March 2014 at 18:40:49 UTC, Chris Williams wrote:
> enum uint MAX_N = 10_000_000U;
>
> void calcPrimes() pure nothrow {
>     uint[][uint] markers;
>
>     for (uint L = 2; L < MAX_N; L++) {
>         uint[]* pList = (L in markers);
>         if (pList is null) {
>             markers[L + L] = [L];
>         }
>         else {
>             uint[] list = *pList;
>             size_t len = list.length - 1;
>             for (uint L2 = 0; L2 < len; L2++) {
>                 uint val = list[L2];
>                 markers[ L + val ] ~= val;
>             }
>
>             // reuse the current list for the last item to save allocations
>             list[0] = list[len];
>             list.length = 1;
>             markers[ L + list[len] ] = list;
>         }
>     }
> }
>
> void main() {
>     calcPrimes;
> }

Well bummer, my quick and easy optimization broke the result for some reason. Here's a version that actually produces the correct answers, while I try and debug:

enum uint MAX_N = 10_000_000U;

void calcPrimes() {
    uint[][uint] markers;

    for (uint L = 2; L < MAX_N; L++) {
        uint[]* pList = (L in markers);
        if (pList is null) {
            markers[L + L] = [L];
        }
        else {
            uint[] list = *pList;
            for (uint L2 = 0; L2 < list.length; L2++) {
                uint val = list[L2];
                markers[ L + val ] ~= val;
            }
        }
    }
}

void main() {
    calcPrimes;
}

Am Wed, 19 Mar 2014 16:45:45 +0000
schrieb Russel Winder <russel@winder.org.uk>:

> The experimental package was removed from Go once the importing from repositories worked properly. The core had only in it that which had been agreed by the process, nothing experimental. This made everything a lot cleaner.
>
> So I think keeping Phobos with only vetted and approved code is a better solution.

Wait, what? Because Go has special infrastructure in the compiler front-end that enables it to import directly from repositories like this

import (
	"fmt"
	"github.com/user/newmath"
)

we should also keep experimental modules out of the standard library? Shouldn't we first get this technology?

It's a whole different story if the compiler front-end seamlessly downloads missing imports in the background, than if you have to install dub and create a project file first. Besides you are relying on a third party tool you may or may not plan to use for building.

Anyways, I just thought an experimental package right in Phobos would be the straight forward way to give the most exposure to new modules that we want tried in the field before inclusion. That's where my vote goes.

-- 
Marco

On Wednesday, 19 March 2014 at 17:40:50 UTC, Andrei Alexandrescu wrote:
> On 3/19/14, 10:01 AM, Dicebot wrote:
>> I avoid it too but it is my personal problem to deal with. dub is
>> de-facto standard in D tool chain and I am pretty sure eventually will
>> be distributed with dmd.
>
> It may be time to look into this. Who wants to champion this effort? -- Andrei

I think it is _tiny_ bit to early - there are some relatively big intrusive changes planned for dub (like switching to SDL as default description grammar) and it is better to start distributing it once this stuff stabilizes. I'll keep it in my notes though and start poking people once it looks feasible :)

Do you have any personal requirements in mind that need to be met before "legitimization" of dub?

On 3/20/14, 6:07 AM, Dicebot wrote:
> On Wednesday, 19 March 2014 at 17:40:50 UTC, Andrei Alexandrescu wrote:
>> On 3/19/14, 10:01 AM, Dicebot wrote:
>>> I avoid it too but it is my personal problem to deal with. dub is
>>> de-facto standard in D tool chain and I am pretty sure eventually will
>>> be distributed with dmd.
>>
>> It may be time to look into this. Who wants to champion this effort?
>> -- Andrei
>
> I think it is _tiny_ bit to early - there are some relatively big
> intrusive changes planned for dub (like switching to SDL as default
> description grammar) and it is better to start distributing it once this
> stuff stabilizes. I'll keep it in my notes though and start poking
> people once it looks feasible :)
>
> Do you have any personal requirements in mind that need to be met before
> "legitimization" of dub?

I think it should be pig easy to use, battle tested, and have some security mechanism in place.

Andrei

On Wednesday, 19 March 2014 at 17:40:50 UTC, Andrei Alexandrescu wrote:
> On 3/19/14, 10:01 AM, Dicebot wrote:
>> I avoid it too but it is my personal problem to deal with. dub is
>> de-facto standard in D tool chain and I am pretty sure eventually will
>> be distributed with dmd.
>
> It may be time to look into this. Who wants to champion this effort? -- Andrei

I'd support inclusion into the official Dlang package but it has to be ready for distribution. I'm a big fan of it but it doesn't seem 100% stable yet.

For experimental libs i'd rather they were kept out of phobos and placed within the dub registry. We can load and use them at leisure from there without expecting any sort of support from the language maintainers. If included in phobos i can almost guarantee that even though they will be marked experimental devs will moan when they change because they will have an official stamp.

Dub should be more embraced by the official language maintainers especially moving the Deimos repo's into there. I myself have had to duplicate and package a deimos repo and add it just to move on with a project.

On Thursday, 20 March 2014 at 21:31:13 UTC, Gary Willoughby wrote:
> For experimental libs i'd rather they were kept out of phobos and placed within the dub registry. We can load and use them at leisure from there without expecting any sort of support from the language maintainers. If included in phobos i can almost guarantee that even though they will be marked experimental devs will moan when they change because they will have an official stamp.

+1

On Wednesday, 19 March 2014 at 01:29:16 UTC, bearophile wrote:
>
> 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 [Snip]
>
> With such 7 functions/ranges you can do lot of things :-)
>
> Bye,
> bearophile

I think we need a solid integer math module more than anything on this list.
I find myself often reimplementing ilog2, isqrt, isPowerOf2, etc, etc.
This would be a complement to std.math, std.bitmanip and core.bitop.
GCD and binomial would fit well in here.

I've recently made use of a prime sieve[1] and something similar to a pairwise range (triangular range: [0,0],[1,0],[1,1]...)

I think we should be careful about adding an isPrime method, I think adding an isProbablePrime plus the prime sieve should cover most use cases.

I agree that combination/pairwise ranges are high on my wishlist, higher than having GCD/binomial/prime sieve, below having a basic integer math module.
One important feature of the pairwise range I wrote was slicing which makes parallelising O(N^2) algorithms much easier.

[1] http://dpaste.dzfl.pl/e91ffe7e4609 Based on the code from http://create.stephan-brumme.com/eratosthenes/