Implementing Half Floats in D

[Paul D. Anderson]

On Thursday, 31 January 2013 at 17:05:50 UTC, Andrei Alexandrescu 
wrote:
> On 1/31/13 10:38 AM, Don wrote:
>> The basic problem is that there are hundreds of potential 
>> numeric
>> algorithms and data structures of equal importance to these 
>> ones. In
>> fact, the total number of mathematical algorithms is probably a
>> substantial fraction of the total algorithms in computer 
>> science!
>>
>> Even a module which contained only FFT, could be quite large, 
>> once it
>> included all the important related transforms.
>
> A possible solution would be to make std.numeric a knot for 
> several others, or convert it to a package.
>
>> I'm not sure that we can solve this without addressing the 
>> high-level
>> question: What is the scope of Phobos?
>>
>> How big will it eventually get? Twice its current size? Ten 
>> times? A
>> hundred times?
>
> I think the current trend is to go for large libraries.
>
>> Both SmallPhobos and LargePhobos are reasonable, but we do 
>> have to pick
>> one. Currently we have aspects of both approaches, but they 
>> aren't
>> compatible.
>
> LargePhobos. Agreed that we need to package-ize some of the 
> current modules.
>
>
> Andrei

Another consideration is the process for a package to become 
"standard". Current practice is to implement a package and go 
through a review in this forum. That's a good thing, but I'd like 
to see a more interactive approach, where the community was 
involved sooner:

1. A package is proposed for future inclusion in the library. 
Presumably this is done by someone with an interest in the 
subject, ideally this is someone who wants to spearhead the 
effort and may already have a draft implementation.

2. If there's enough interest to move forward, community members 
could bicker about all the bikeshed stuff: structures, methods, 
implementations, API, etc. until there's enough agreement about 
what the result should look like.

3. Interested parties could collaborate on the implementation and 
release.

4. There would have to be time limits. Many (most?) D projects 
start with a bang but then fizzle out before they're complete. 
There would need to be (monthly?) progress reviews. If the 
discussion or the implementation has dwindled, a reconsideration 
of the project could occur. If unsuccessful, the project would be 
moved off the active list. If there is renewed interest or if 
somebody else wants to take a crack at it the previous work can 
be a resource, but the project should probably go back to step 1.

You all see the problem with this: the very short attention span 
of the D community. But we've got a good start between the DIP 
process and the review queue. The only thing really different 
would be the progress reviews, which would hopefully prevent 
projects falling of the end of the earth.

This is just one possibility and there are probably better ways 
to do this. But I think some sort of maintenance of active 
projects is needed.

Paul