April 11, 2009
bearophile wrote:
> Andrei Alexandrescu:
> 
>> Then please vote up my comment which shows a solution that is simple *and* efficient :o).
> 
> I am not registered there, so I can't vote, I guess.
> Generally I don't like reduce() HOF, because it generally leads to less readable code (and often people use it only to compute a sum or product of items), but this time it's a good enough usage.
> You have forgotten to compute the average, as requested by the original article.
> 
> Regarding field access:
> assert(r.field[0] == 2); // minimum
> assert(r.field[1] == 11); // maximum
> I've found that sometimes a shorter syntax is nice, I use d0, d1, etc:
> assert(r.d0 == 2);
> assert(r.d1 == 11);
> (It doesn't replace the general [] access).

Yah, I had _0 but removed it. The plan is to use alias this to get rid of field altogether so you write r[0], r[1] etc. but it turns out alias this still has a few bugs.


Andrei
April 11, 2009
bearophile wrote:
> Andrei Alexandrescu:
>> Then please vote up my comment which shows a solution that is simple *and* efficient :o).
> 
> Does it work with (the keys of) an AA too? For example:
> int[double] aa = [3.0:0, 4:0, 7:0, 11:0, 3:0, 2:0, 5:0];
> auto r = reduce!(min, max)(aa);

No, AAs are poorly designed (no iteration etc.) so std.algorithm is not even attempting to support them. My plan is to cajole Walter and Sean into making AA real types, after which I can add the appropriate functionality.

Andrei
April 11, 2009
Andrei Alexandrescu wrote:
> bearophile wrote:
>> For even bigger data you may use muds:
>> "On the Complexity of Processing Massive, Unordered, Distributed Data", by Jon Feldman, S. Muthukrishnan, Anastasios Sidiropoulos, Cliff Stein, Zoya Svitkina:
>> http://arxiv.org/abs/cs.CC/0611108
> 
> I've developed a skepticism towards arxiv.org. My understanding is that it's not high-quality so a paper that only appears of it is highly questionable.
> 
> Andrei

I'm not sure how it is in CS, but at least in physics, *everything* is posted on arXiv -- papers, talks, lectures, etc. Since it (usually) takes quite a while to get a paper published in a peer-reviewed journal, it allows for rapid communication of research results. For each paper on arXiv there is a "journal-ref" field that can be filled in when the paper is quality-assured and published.

Another nice thing about arXiv is that it's free. Scientific journals usually require subscriptions -- expensive ones, at that, normally paid for by university libraries. Therefore, when I want to send someone a link to a paper of mine, I usually direct them to the arXiv version, since then I'm sure they can actually read it.

So I guess my point is: don't diss arXiv. :)

-Lars
April 11, 2009
Lars Kyllingstad wrote:
> Andrei Alexandrescu wrote:
>> bearophile wrote:
>>> For even bigger data you may use muds:
>>> "On the Complexity of Processing Massive, Unordered, Distributed Data", by Jon Feldman, S. Muthukrishnan, Anastasios Sidiropoulos, Cliff Stein, Zoya Svitkina:
>>> http://arxiv.org/abs/cs.CC/0611108
>>
>> I've developed a skepticism towards arxiv.org. My understanding is that it's not high-quality so a paper that only appears of it is highly questionable.
>>
>> Andrei
> 
> I'm not sure how it is in CS, but at least in physics, *everything* is posted on arXiv -- papers, talks, lectures, etc. Since it (usually) takes quite a while to get a paper published in a peer-reviewed journal, it allows for rapid communication of research results. For each paper on arXiv there is a "journal-ref" field that can be filled in when the paper is quality-assured and published.
> 
> Another nice thing about arXiv is that it's free. Scientific journals usually require subscriptions -- expensive ones, at that, normally paid for by university libraries. Therefore, when I want to send someone a link to a paper of mine, I usually direct them to the arXiv version, since then I'm sure they can actually read it.
> 
> So I guess my point is: don't diss arXiv. :)

Thank you, this is very useful information.

Andrei
April 11, 2009
Andrei Alexandrescu wrote:
> Hi everybody,
> 
> 
> I just committed all of Phobos into svn on dsource.org. That is not an
> official release and has known and unknown bugs, limitations, and
> rhinodemons. I expect some ripples before we stabilize, but when we will
> we'll stabilize at a higher potential.

Some corrections/suggestions to std.range, if you are ready for such yet:

From the documentation it seems that the function series() is meant to be called recurrence(). (Personally I think recursiveSequence() is more fitting.)

The function sequence() is missing from the documentation, only struct Sequence is listed. Guess there should be a ///ditto in there.

I think isInfinite!() should be called isInfiniteRange!(). The current name is, in my opinion, too general.

-Lars

April 11, 2009
Lars Kyllingstad wrote:
> Andrei Alexandrescu wrote:
>> Hi everybody,
>>
>>
>> I just committed all of Phobos into svn on dsource.org. That is not an
>> official release and has known and unknown bugs, limitations, and
>> rhinodemons. I expect some ripples before we stabilize, but when we will
>> we'll stabilize at a higher potential.
> 
> Some corrections/suggestions to std.range, if you are ready for such yet:

Thanks!

>  From the documentation it seems that the function series() is meant to be called recurrence(). (Personally I think recursiveSequence() is more fitting.)

Fixed. (I'm trying to stay with one-word names when possible.)

> The function sequence() is missing from the documentation, only struct Sequence is listed. Guess there should be a ///ditto in there.

Oops... fixed.

> I think isInfinite!() should be called isInfiniteRange!(). The current name is, in my opinion, too general.

I'm undecided about this (and similar cases). isInfinite sits inside std.range, so std.range.isInfinite is clear and std.range.isInfiniteRange feels redundant. On the other hand, I don't want to use too common symbols because then the user will be forced to prefix them whenever they clash.

I fixed everything and checked in. Speaking of which, I'd be glad if interested people could take a look at std.file and compare it against the old:

http://dsource.org/projects/phobos/browser/trunk/phobos/std/file.d

Previously many phobos modules, e.g. std.file, looked like this:

version(Windows)
{
    ... big chunk ...
}
version(Posix)
{
    ... big chunk ...
}

The advantage of this approach is that it keeps platform-specific code together. The disadvantage is that it encourages code duplication. I found that about 25% of the functions inside std.file actually were not platform dependent; they essentially were duplicated verbatim.

So I suggest we change this to per-declaration granularity where it makes sense:

/**
Doc for read...
*/

version(Windows) void[] read(in char[] filename, void[] data) { ... }

version(Posix) void[] read(in char[] filename, void[] data) { ... }

The current std.file implements this alternative factoring and initial experience seems to suggest it works fine. Also, the code got smaller by 18%. This must also because I got rid of all goto's :o).

By the way, here's a neat trick I think may be used in other situations as well: factoring some constant function arguments together.

version(Windows) void[] read(in char[] name)
{
    alias TypeTuple!(GENERIC_READ,
            FILE_SHARE_READ, (SECURITY_ATTRIBUTES*).init, OPEN_EXISTING,
            FILE_ATTRIBUTE_NORMAL | FILE_FLAG_SEQUENTIAL_SCAN,
            HANDLE.init)
        defaults;
    auto h = useWfuncs
        ? CreateFileW(std.utf.toUTF16z(name), defaults)
        : CreateFileA(toMBSz(name), defaults);
    ...
}

The previous code duplicated all those arguments.


Andrei
April 11, 2009
Andrei Alexandrescu wrote:
>     alias TypeTuple!(GENERIC_READ,
>             FILE_SHARE_READ, (SECURITY_ATTRIBUTES*).init, OPEN_EXISTING,
>             FILE_ATTRIBUTE_NORMAL | FILE_FLAG_SEQUENTIAL_SCAN,
>             HANDLE.init)
>         defaults;

How is that a type-tuple? (As far as I can see, none of those are types...)
April 11, 2009
Frits van Bommel wrote:
> Andrei Alexandrescu wrote:
>>     alias TypeTuple!(GENERIC_READ,
>>             FILE_SHARE_READ, (SECURITY_ATTRIBUTES*).init, OPEN_EXISTING,
>>             FILE_ATTRIBUTE_NORMAL | FILE_FLAG_SEQUENTIAL_SCAN,
>>             HANDLE.init)
>>         defaults;
> 
> How is that a type-tuple? (As far as I can see, none of those are types...)

TypeTuple is a misnomer. A TypeTuple can contain not only types, but also compile-time expressions.

Andrei
April 11, 2009
Andrei Alexandrescu wrote:
> Frits van Bommel wrote:
>> Andrei Alexandrescu wrote:
>>>     alias TypeTuple!(GENERIC_READ,
>>>             FILE_SHARE_READ, (SECURITY_ATTRIBUTES*).init, OPEN_EXISTING,
>>>             FILE_ATTRIBUTE_NORMAL | FILE_FLAG_SEQUENTIAL_SCAN,
>>>             HANDLE.init)
>>>         defaults;
>>
>> How is that a type-tuple? (As far as I can see, none of those are types...)
> 
> TypeTuple is a misnomer. A TypeTuple can contain not only types, but also compile-time expressions.

I know, that's what I was pointing out :).
I figure, you've got commit access to Phobos...
April 11, 2009
Frits van Bommel wrote:
> Andrei Alexandrescu wrote:
>> Frits van Bommel wrote:
>>> Andrei Alexandrescu wrote:
>>>>     alias TypeTuple!(GENERIC_READ,
>>>>             FILE_SHARE_READ, (SECURITY_ATTRIBUTES*).init, OPEN_EXISTING,
>>>>             FILE_ATTRIBUTE_NORMAL | FILE_FLAG_SEQUENTIAL_SCAN,
>>>>             HANDLE.init)
>>>>         defaults;
>>>
>>> How is that a type-tuple? (As far as I can see, none of those are types...)
>>
>> TypeTuple is a misnomer. A TypeTuple can contain not only types, but also compile-time expressions.
> 
> I know, that's what I was pointing out :).
> I figure, you've got commit access to Phobos...

I wonder what a good name would be.

Andrei