January 30, 2013
On Tuesday, 29 January 2013 at 22:17:30 UTC, Dejan Lekic wrote:
> Jacob Carlborg wrote:
>> Oh, please no, not another module at the "std" level.
>
> +11111111
> I can't agree more to this, Jacob...
> Seriously people... "std.halffloat" ???

 I'll agree too. HalfFloats are more a special case with certain circles of programmers that need those. The majority of programmers (95%+) won't care about half floats, nor would it be needed; It would be akin to making std.bitop instad of core.bitop.

 You could HalfFloats to std.math; Right next to cos, sin and tan. std.mathspecial doesn't seem like it would be closely enough tied to make it an option.

 Alternatively make a std.customtypes for related misc types like this as they are added to phobos.
January 30, 2013
On 01/30/2013 05:27 PM, Era Scarecrow wrote:
> On Tuesday, 29 January 2013 at 22:17:30 UTC, Dejan Lekic wrote:
>> Jacob Carlborg wrote:
>>> Oh, please no, not another module at the "std" level.
>>
>> +11111111
>> I can't agree more to this, Jacob...
>> Seriously people... "std.halffloat" ???
>
> I'll agree too. HalfFloats are more a special case with certain circles
> of programmers that need those. The majority of programmers (95%+) won't
> care about half floats, nor would it be needed; It would be akin to
> making std.bitop instad of core.bitop.
>
> You could HalfFloats to std.math; Right next to cos, sin and tan.
> std.mathspecial doesn't seem like it would be closely enough tied to
> make it an option.
>
> Alternatively make a std.customtypes for related misc types like this as
> they are added to phobos.

std.typecons?

Seriously,  std.type.cons, tuple, halffloat, bigint, etc...
January 31, 2013
On Wednesday, 30 January 2013 at 12:51:18 UTC, Simen Kjaeraas wrote:
> On 2013-01-30, 09:26, Don wrote:
>
>> The discussion we had on github agreed that std.halffloat isn't a good place.
>> But OTOH std.numeric needs a complete overhaul, it's a mess.
>> It would be a mistake to throw it in there.
>
> So put it somewhere else for the moment, and move it to std.numeric after
> a while? Boy, does that ever sound stupid.

Yes, of course that would be stupid. It will never be in std.numeric.

> I say stuff it in std.numeric, and announce properly that someone should
> probably have look at fixing std.numeric, and that HalfFloat in there may
> be the only thing salvageable (not that I know if it is, but that's how
> you make it sound).

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

January 31, 2013
On 2013-18-31 11:01, Don <don@nospam.com> 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'.

Ah. Now that makes sense.

Suppose we do scrap std.numeric as it is, and find new homes for the
contents that can be salvaged (I sorta like 1100110's suggestion of
std.type.halffloat, std.type.bigint, etc). What would you want in a
refurbished std.numeric?

-- 
Simen
January 31, 2013
Don wrote:
> On Wednesday, 30 January 2013 at 12:51:18 UTC, Simen Kjaeraas wrote:
> >On 2013-01-30, 09:26, Don wrote:
> >
> >>The discussion we had on github agreed that std.halffloat isn't
> >>a good place.
> >>But OTOH std.numeric needs a complete overhaul, it's a mess.
> >>It would be a mistake to throw it in there.
> >
> >So put it somewhere else for the moment, and move it to
> >std.numeric after
> >a while? Boy, does that ever sound stupid.
> 
> Yes, of course that would be stupid. It will never be in std.numeric.
> 
> >I say stuff it in std.numeric, and announce properly that someone
> >should
> >probably have look at fixing std.numeric, and that HalfFloat in
> >there may
> >be the only thing salvageable (not that I know if it is, but
> >that's how
> >you make it sound).
> 
> 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'.

Dimitry said this once. Why not start from scratch with package called
std.numerics?
// for numeric types
std.numerics.halffloat
std.numerics.complex
std.numerics.quaternion
...
// algorithms working with numeric types
std.numerics.algorithms // even std.math could make sense

or something similar.
Wouldn't this work?

Jens
January 31, 2013
On 01/31/2013 11: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

std.numerical ... ?

January 31, 2013
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.

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.

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.


Thanks,

Andrei
January 31, 2013
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.

January 31, 2013
On Jan 31, 2013, at 7:38 AM, "Don" <don@nospam.com> wrote:

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

If D had a package distribution system, the solution would be obvious. I'd argue for SmallPhobos plus that. Everything in Phobos proper has to be maintained as a part of Phobos, after all.
January 31, 2013
On Thursday, 31 January 2013 at 15:38:04 UTC, Don wrote:
> 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.


I think having a large standard library inspires confidence in developers. Rightly or wrongly, code in a standard library has an appearance of permanence, as opposed to being someone's personal project that may or may not disappear/cease to be maintained tomorrow.