Implementing Half Floats in D

[Don]

On Thursday, 31 January 2013 at 13:41:13 UTC, Andrei Alexandrescu 
wrote:
> On 1/31/13 5:18 AM, Don wrote:
>> std.numeric is not superficially flawed, it's fundamentally 
>> flawed. What
>> is it for? What is its theme? The problem is, std.numeric is 
>> one of the
>> few good names which are left as a possible package name, 
>> after C
>> insulted the mathematical community by creating a module 
>> called 'math'.
>
> Guilty as charged. I've put stuff in std.numeric as I was 
> working on my thesis. I recall you added some stuff there too. 
> As I'm sure you remember the state of D in 2007 was rather 
> different than that of today. Overall no need to get agitated 
> here, we're all on the same boat and aiming for the same shore.

Sorry if that came across as agitated, it wasn't intended to be.
As you noted, I have code in there as well.
It's just one of those old modules that needs to be cleaned up, 
though it reveals a deeper issue - see below.

> Let's see what we have there:
>
> entropy
> CustomFloat
> kullbackLeiblerDivergence
> Fft
> gapWeightedSimilarityIncremental
> gapWeightedSimilarity
> gapWeightedSimilarityNormalized
> FPTemporary
> findRoot
> euclideanDistance
> dotProduct
> cosineSimilarity
> gcd
> jensenShannonDivergence
> normalize
> secantMethod
>
> The general theme is obvious - numeric algorithms and data 
> structures. Many are obvious and with obvious utility to one 
> interested in numerics: entropy, various distance and 
> similarity measures. I think you wrote findRoot.

Yes.
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.

> The gapWeightedSimilarity algorithms are string kernels. They 
> are somewhat niche but quite powerful to anyone interested in 
> string similarity (technically they are string edit distance on 
> steroids). They might belong in std.string but I figured they 
> have enough numeric algorithm flavor to put them in there.
>
> So let's itemize the grievances and see how we can sort this 
> out.

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?

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.

The current approach of putting everything directly into a single 
level in std doesn't scale very far -- it will look very clumsy 
once it gets more than (say) three times larger. This argues for 
SmallPhobos.

But if it doesn't get to be at least ten times larger, some of 
this niche stuff shouldn't be in there, they are functions from 
LargePhobos. If we go with SmallPhobos then we need to move the 
niche stuff somewhere else.