View mode: basic / threaded / horizontal-split · Log in · Help
April 11, 2009
Re: The new, new phobos sneak preview
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
Re: The new, new phobos sneak preview
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
Re: The new, new phobos sneak preview
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
Re: The new, new phobos sneak preview
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
Re: The new, new phobos sneak preview
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
Re: The new, new phobos sneak preview
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
Re: The new, new phobos sneak preview
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
Re: The new, new phobos sneak preview
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
Re: The new, new phobos sneak preview
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
Re: The new, new phobos sneak preview
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
2 3 4 5 6 7 8 9 10
Top | Discussion index | About this forum | D home