Implementing Half Floats in D

Joseph Rushton Wakeling joseph.wakeling at webdrake.net
Sat Feb 2 05:42:17 PST 2013


On 01/31/2013 08:02 PM, H. S. Teoh wrote:
> Interesting. I think Phobos can be easily divided into two parts, with
> core stuff like std.algorithm, std.range, std.stdio, etc., in one, and
> less common but still widely applicable stuff like numeric algorithms in
> a "2nd party" library (or libraries).

Speaking as a researcher, I've on occasion had cause to call on stuff from such 
"2nd party" libraries, and it's not necessarily a happy experience.

A while ago I had cause to call on a package in CRAN, the contributed package 
archive for the R statistical programming language.  It wasn't one of the 
modules that's packaged for Debian et al., so I had to pull things in directly 
from R's own package management and build and install locally.

In and of itself, R makes this very easy, but what I wasn't prepared for was 
that in installing the one package I was interested in, it would pull in and 
install dozens of other CRAN packages.  And then, when I looked inside the code, 
actually finding out what it was doing was nightmarish, because the module of 
interest was built on top of several other contributions by the same authors. 
Understanding the code involved a massive wild goose chase through all those 
other contributed modules to find what functions were being called and what they 
did.

I don't know if this is typical of CRAN packages, because I tend to use R 
infrequently, but my strong impression was of code that had been built, thrown 
over the wall and then built on top of without any attention to design, 
integration or performance (when I re-implemented the algorithms using 
Octave/MATLAB they were much faster, and I doubt this was down to the 
superiority of the language or interpreter).

And this code wasn't built by stupid people -- they were very good 
statisticians.  In their defence, I suspect the reason they built 
higgledy-piggledy as they did was because they knew their earlier modules 
_worked_ and reliability was the most important thing for them.

That's the cost of 2nd-party libraries -- they are very hit-and-miss in terms of 
design, sustainability and hence, reliability.

Now, that said, I think a "2nd-party" repository for D could be a great project, 
but what I _wouldn't_ like to see was that repository being considered an 
adequate replacement for carefully designed standard library functionality.  One 
of the things I love about D is precisely the breadth of Phobos' support, and it 
feels like the solution to Phobos' problems is a better design and review 
process rather than ringfencing a too-small set of core functionality.

Of course, a 2nd-party repository could be part of the prototyping and 
experimentation behind new standard-library work, just as Boost is for C++.


More information about the Digitalmars-d mailing list