Complex networks in D

[Joseph Rushton Wakeling]

On Tuesday, 16 July 2013 at 14:18:02 UTC, bearophile wrote:
>     size_t vertexCount() @property const pure nothrow
>     {
>         assert(_sumHead.length == _sumTail.length);
>         return _sumHead.length - 1;
>     }
>
> Is that better written in a struct/class invariant?

Nice thought -- probably; it's a condition that must always hold.

>         size_t degreeIn(immutable size_t v) const pure nothrow
>         {
>             assert(v + 1 < _sumTail.length);
>             return _sumTail[v + 1] - _sumTail[v];
>         }
>
> Here you are looking for the method pre-condition.

Ahh, you mean inside in { ... } brackets?  I did consider writing 
it like that.  It wasn't clear to me what the benefits were, 
though, especially as I did consider making this an enforce() 
rather than an assert().

> And "in size_t v" is enough compared to "immutable size_t v".

Does "in" allow for subsequent mutation _within_ the function?

> For such kind of code I suggest to use UFCS chains.

Can you explain in a little more detail?  It's not an aspect of 
programming I'm familiar with.

> Also be careful with the performance of such range-based code, 
> writing benchmarks. Unfortunately often DMD doesn't compile it 
> efficiently.

Yes, this is a concern of mine too.  In benchmarks I've carried 
out, the calls to e.g. neighbours() take up a substantial chunk 
of the overall runtime -- but that said, the number of calls to 
them is very, very large.  It works out as on the order of 
between 1e-9 and 1e-8 seconds per call.

These kinds of range-based solutions seem to be a part of D where 
LDC typically produces the best performance.  But I would not use 
DMD for serious number crunching of any kind -- as it stands it 
can't match either of the other two compilers.

Anyway, thanks very much for the useful feedback :-)