www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Implementing Half Floats in D

reply Walter Bright <newshound2 digitalmars.com> writes:
http://www.drdobbs.com/cpp/implementing-half-floats-in-d/240146674

Anyone care to do the reddit honors?
Jan 28 2013
next sibling parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Monday, 28 January 2013 at 23:11:11 UTC, Walter Bright wrote:
 http://www.drdobbs.com/cpp/implementing-half-floats-in-d/240146674

 Anyone care to do the reddit honors?
[quote] and crushed back down to 16 bytes for storage. [/quote] Should be bits. Otherwise it looks really well done.
Jan 28 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/28/2013 3:30 PM, Era Scarecrow wrote:
 On Monday, 28 January 2013 at 23:11:11 UTC, Walter Bright wrote:
 http://www.drdobbs.com/cpp/implementing-half-floats-in-d/240146674

 Anyone care to do the reddit honors?
[quote] and crushed back down to 16 bytes for storage. [/quote] Should be bits. Otherwise it looks really well done.
thank you. Sorry that didn't get caught in review!
Jan 28 2013
parent reply "Tove" <tove fransson.se> writes:
On Monday, 28 January 2013 at 23:58:40 UTC, Walter Bright wrote:
 On 1/28/2013 3:30 PM, Era Scarecrow wrote:
 On Monday, 28 January 2013 at 23:11:11 UTC, Walter Bright 
 wrote:
 http://www.drdobbs.com/cpp/implementing-half-floats-in-d/240146674

 Anyone care to do the reddit honors?
[quote] and crushed back down to 16 bytes for storage. [/quote] Should be bits. Otherwise it looks really well done.
thank you. Sorry that didn't get caught in review!
"HalfFloat h = hf!1.3f;" Maybe you could also demonstrate that it's possible to implement another literal syntax? HalfFloat h = 1.3.hf; some people will prefer that for sure.
Jan 28 2013
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2013-49-29 08:01, Tove <tove fransson.se> wrote:

 On Monday, 28 January 2013 at 23:58:40 UTC, Walter Bright wrote:
 On 1/28/2013 3:30 PM, Era Scarecrow wrote:
 On Monday, 28 January 2013 at 23:11:11 UTC, Walter Bright wrote:
 http://www.drdobbs.com/cpp/implementing-half-floats-in-d/240146674

 Anyone care to do the reddit honors?
[quote] and crushed back down to 16 bytes for storage. [/quote] Should be bits. Otherwise it looks really well done.
thank you. Sorry that didn't get caught in review!
"HalfFloat h = hf!1.3f;" Maybe you could also demonstrate that it's possible to implement another literal syntax? HalfFloat h = 1.3.hf; some people will prefer that for sure.
Except that's not a literal. 1.3.hf would be a function call, while hf!1.3f is a template instantiation. -- Simen
Jan 29 2013
next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Tuesday, 29 January 2013 at 08:48:24 UTC, Simen Kjaeraas wrote:
 On 2013-49-29 08:01, Tove <tove fransson.se> wrote:
 Maybe you could also demonstrate that it's possible to 
 implement another literal syntax?
 HalfFloat h = 1.3.hf;

 some people will prefer that for sure.
Except that's not a literal. 1.3.hf would be a function call, while hf!1.3f is a template instantiation.
Unless it's an enum or something that requires it to know it during compile-time. enum h = 1.3.hf; //potentially correct But I doubt it would be that useful. More likely during optimization static values would be equal to it.
Jan 29 2013
prev sibling parent reply "TommiT" <tommitissari hotmail.com> writes:
On Tuesday, 29 January 2013 at 08:48:24 UTC, Simen Kjaeraas wrote:
 Except that's not a literal. 1.3.hf would be a function call, 
 while hf!1.3f
 is a template instantiation.
Can't help but point out, that some time ago, I made a suggestion to add a new function attribute to the language that would mean "evaluate any call to this function at compile time whenever it's possible". That would enable literals like: 1.3.hf and ComplexToConstruct(2.5, 7.5) Given: property HalfFloat hf(float v) aggressive_ctfe; and... struct ComplexToConstruct { this(float x, float y) aggressive_ctfe; }
Jan 29 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/29/2013 11:40 AM, TommiT wrote:
 On Tuesday, 29 January 2013 at 08:48:24 UTC, Simen Kjaeraas wrote:
 Except that's not a literal. 1.3.hf would be a function call, while
 hf!1.3f
 is a template instantiation.
Can't help but point out, that some time ago, I made a suggestion to add a new function attribute to the language that would mean "evaluate any call to this function at compile time whenever it's possible". That would enable literals like: 1.3.hf and ComplexToConstruct(2.5, 7.5) Given: property HalfFloat hf(float v) aggressive_ctfe; and... struct ComplexToConstruct { this(float x, float y) aggressive_ctfe; }
I'd call it constfold.
Jan 29 2013
parent "TommiT" <tommitissari hotmail.com> writes:
On Tuesday, 29 January 2013 at 11:26:00 UTC, Timon Gehr wrote:
 I'd call it  constfold.
That's a good name. Descriptive and short. I'm not going to try to push this suggestion any harder, since it got no support on the first time I tried it. But I'd like to mention just one thing that came to mind: The generic solution without any extra function attributes: template ct(alias expr) { enum ct = expr; } Literal of type TypeWithNonTrivialConstructor: ct!(TypeWithNonTrivialConstructor(2.5, 7.5)) The above solution throws the responsibility of the correct use of TypeWithNonTrivialConstructor on the end-user. Whereas a constfold attribute on the constructor of TypeWithNonTrivialConstructor automates the correct behaviour.
Jan 29 2013
prev sibling next sibling parent reply Justin Whear <justin economicmodeling.com> writes:
On Mon, 28 Jan 2013 15:11:06 -0800, Walter Bright wrote:

 http://www.drdobbs.com/cpp/implementing-half-floats-in-d/240146674
 
 Anyone care to do the reddit honors?
Posted to /r/d_language, perhaps a x-post to /r/programming would be in order? http://www.reddit.com/r/d_language/comments/17gkrk/ implementing_half_floats_in_d_dr_dobbs/
Jan 28 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/28/13 6:40 PM, Justin Whear wrote:
 On Mon, 28 Jan 2013 15:11:06 -0800, Walter Bright wrote:

 http://www.drdobbs.com/cpp/implementing-half-floats-in-d/240146674

 Anyone care to do the reddit honors?
Posted to /r/d_language, perhaps a x-post to /r/programming would be in order? http://www.reddit.com/r/d_language/comments/17gkrk/ implementing_half_floats_in_d_dr_dobbs/
Not sure what's going on, I tried to submit and got "already submitted" and then got redirected to http://www.reddit.com/r/programming/comments/16ycws/implementing_half_floats_in_d/ Hoever, I can't find the post in http://www.reddit.com/r/programming/new/ Andrei
Jan 28 2013
next sibling parent Justin Whear <justin economicmodeling.com> writes:
On Mon, 28 Jan 2013 18:50:22 -0500, Andrei Alexandrescu wrote:

 On 1/28/13 6:40 PM, Justin Whear wrote:
 On Mon, 28 Jan 2013 15:11:06 -0800, Walter Bright wrote:

 http://www.drdobbs.com/cpp/implementing-half-floats-in-d/240146674

 Anyone care to do the reddit honors?
Posted to /r/d_language, perhaps a x-post to /r/programming would be in order? http://www.reddit.com/r/d_language/comments/17gkrk/ implementing_half_floats_in_d_dr_dobbs/
Not sure what's going on, I tried to submit and got "already submitted" and then got redirected to http://www.reddit.com/r/programming/comments/16ycws/
implementing_half_floats_in_d/
 
 Hoever, I can't find the post in
 http://www.reddit.com/r/programming/new/
 
 
 Andrei
Possibly this: http://code.reddit.com/wiki/help/ faq#Whyisntmysubmissioncommentshowingup Walter is an admin; maybe he can check on it?
Jan 28 2013
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/28/2013 3:50 PM, Andrei Alexandrescu wrote:
 Not sure what's going on, I tried to submit and got "already submitted" and
then
 got redirected to
 http://www.reddit.com/r/programming/comments/16ycws/implementing_half_floats_in_d/
8 days old, durn, it's sunsetted.
Jan 28 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 http://www.drdobbs.com/cpp/implementing-half-floats-in-d/240146674
From the article:
Built-in types tend to run faster because the optimizer can take 
advantage of mathematical identities,<
Generally in D we like the compiler to verify user-applied annotations like pure and const. For the compiler of a normal language today it's probably too much difficult to prove the theorems coming from those identities on user defined types. But if the compiler assumes the programmer to be right on this (because such types are usually defined in well reviewed libraries), then I think it's not too much hard to invent a small set of annotations that attached to a user defined struct tell the compiler to allow some optimizations typical of integral numbers, floating point numbers, complex numbers, gaussian integers, quaternions, octonions and few others, according to them having associative, commutative, etc, properties, or not having them. Bye, bearophile
Jan 28 2013
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 29, 2013 at 01:44:20AM +0100, bearophile wrote:
 Walter Bright:
 
http://www.drdobbs.com/cpp/implementing-half-floats-in-d/240146674
From the article:
Built-in types tend to run faster because the optimizer can take
advantage of mathematical identities,<
Generally in D we like the compiler to verify user-applied annotations like pure and const. For the compiler of a normal language today it's probably too much difficult to prove the theorems coming from those identities on user defined types. But if the compiler assumes the programmer to be right on this (because such types are usually defined in well reviewed libraries), then I think it's not too much hard to invent a small set of annotations that attached to a user defined struct tell the compiler to allow some optimizations typical of integral numbers, floating point numbers, complex numbers, gaussian integers, quaternions, octonions and few others, according to them having associative, commutative, etc, properties, or not having them.
[...] +1. I've always wanted a language capable of user-specified optimizations for custom types. This would be very useful on things like matrix types, which would otherwise require heavy trickery with expression templates in order to produce efficient code. T -- May you live all the days of your life. -- Jonathan Swift
Jan 28 2013
prev sibling next sibling parent reply "Stephan" <stephan_schiffels mac.com> writes:
On Monday, 28 January 2013 at 23:11:11 UTC, Walter Bright wrote:
 http://www.drdobbs.com/cpp/implementing-half-floats-in-d/240146674

 Anyone care to do the reddit honors?
Very nice. I learnt quite a bit there. btw: "In order to restrict it to only accepting floats, turn it into a template and check the type with static if:" - you actually use a static assert. But while we're at it: Why *don't* you use a signature constraint with if? I feel it would be more fitting to constrain the constructor usage. Stephan
Jan 29 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/29/2013 2:43 AM, Stephan wrote:
 Why *don't* you use a signature constraint with if?
To get a custom error message.
Jan 29 2013
prev sibling next sibling parent reply "Don" <don nospam.com> writes:
On Monday, 28 January 2013 at 23:11:11 UTC, Walter Bright wrote:
 http://www.drdobbs.com/cpp/implementing-half-floats-in-d/240146674
Since it got lost in the old thread on this topic, I'll repost my versions of floatToshort and shortToFloat, which are extremely fast (no unpredictable branches, no lookup tables) and respect the current rounding mode: ----------------- float shortToFloat(ushort s) { // note this is a signed shift, so sign bit gets smeared all the way into the int bit! uint u = ((cast(int)cast(short)s) << 13); if ( (s & EXPMASK) == 0 ) { // Subnormal or 0. // The simple conversion is wrong in two ways: // (1) it's added an implicit bit. This has value 0x1p-15. // (2) the mantissa bits got shifted along to make space for the hidden bit. // So we need to multiply the result by 2. // Note that 0x3880_0000 means 0x1p-14. uint v = (u & 0x0FFF_FFFF ) + 0x3880_0000; float f = *cast(float *)&v - 0x1p-14; u = (u & 0x8000_0000) | *cast(uint *)&f; return *cast(float *)&u; } u = (u & 0x8FFF_FFFF) + 0x3800_0000; if ( (s & EXPMASK) == EXPMASK ) { // infinity or NaN u |= FEXPMASK; } return *cast(float *)&u; } ----------------- NOTE: this only works on 64-bit runtime, for 32bit or CTFE with 80-bit intermediates, the constants need to be changed. Unfortunately I don't know of a nice way to detect the size of the intermediates. ----- ushort floatToShort(float f) { // Remember the sign uint x = *cast(uint *)&f; ushort sgn = (x >> 16) & 0x8000; // Need to treat NaN and Inf specially, otherwise the // mantissa shortening step would generate a new NaN. if ( (x & FEXPMASK) == FEXPMASK) return ( (x >> 13) & 0x7FFF) | sgn; // Shorten the mantissa, rounding it according to the current rounding mode f = (f * (1.0f + 0x1p-13f) -f) * 0x1p13f; // Force large numbers to overflow my moving near float.max f *= 0x1p112f; f *= 0x1p-112f; // Then undo it // Force small numbers to underflow, and shift into position f *= 0x1p-112f; uint u = *cast(uint *)&f; return ((u>>13) & 0x7FFF) | sgn; }
Jan 29 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/29/2013 4:31 AM, Don wrote:
 Since it got lost in the old thread on this topic, I'll repost my versions of
 floatToshort and shortToFloat, which are extremely fast (no unpredictable
 branches, no lookup tables) and respect the current rounding mode:
I was waiting on incorporating your improvements until after std.halffloat was merged into Phobos. This is because the old ones were easier to understand, and I wanted them in the repository history.
Jan 29 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-29 20:06, Walter Bright wrote:

 I was waiting on incorporating your improvements until after
 std.halffloat was merged into Phobos. This is because the old ones were
 easier to understand, and I wanted them in the repository history.
Oh, please no, not another module at the "std" level. -- /Jacob Carlborg
Jan 29 2013
next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Tuesday, 29 January 2013 at 19:51:03 UTC, Jacob Carlborg wrote:
 On 2013-01-29 20:06, Walter Bright wrote:

 I was waiting on incorporating your improvements until after
 std.halffloat was merged into Phobos. This is because the old 
 ones were
 easier to understand, and I wanted them in the repository 
 history.
Oh, please no, not another module at the "std" level.
+1 David
Jan 29 2013
prev sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
Jacob Carlborg wrote:

 On 2013-01-29 20:06, Walter Bright wrote:
 
 I was waiting on incorporating your improvements until after
 std.halffloat was merged into Phobos. This is because the old ones were
 easier to understand, and I wanted them in the repository history.
Oh, please no, not another module at the "std" level.
+11111111 I can't agree more to this, Jacob... Seriously people... "std.halffloat" ??? -- Dejan Lekic dejan.lekic (a) gmail.com http://dejan.lekic.org
Jan 29 2013
parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
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.
Jan 30 2013
parent 1100110 <0b1100110 gmail.com> writes:
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...
Jan 30 2013
prev sibling next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 29 January 2013 19:06, Walter Bright <newshound2 digitalmars.com> wrote:

 On 1/29/2013 4:31 AM, Don wrote:

 Since it got lost in the old thread on this topic, I'll repost my
 versions of
 floatToshort and shortToFloat, which are extremely fast (no unpredictable
 branches, no lookup tables) and respect the current rounding mode:
I was waiting on incorporating your improvements until after std.halffloat was merged into Phobos. This is because the old ones were easier to understand, and I wanted them in the repository history.
I'm sure this was mentioned before, but what does halffloat have over std.numeric.CustomFloat? Thanks -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Jan 29 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/29/2013 2:27 PM, Iain Buclaw wrote:
 I'm sure this was mentioned before, but what does halffloat have over
 std.numeric.CustomFloat?
There was a long discussion about it, I don't remember if it was in the ng or on github.
Jan 29 2013
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 29, 2013 at 04:36:48PM -0800, Walter Bright wrote:
 On 1/29/2013 2:27 PM, Iain Buclaw wrote:
I'm sure this was mentioned before, but what does halffloat have over
std.numeric.CustomFloat?
There was a long discussion about it, I don't remember if it was in the ng or on github.
It was on github. But IIRC no conclusion was ever reached. T -- Живёшь только однажды.
Jan 29 2013
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 01/29/2013 11:27 PM, Iain Buclaw wrote:
 I'm sure this was mentioned before, but what does halffloat have over
 std.numeric.CustomFloat?
"These formats are for storage only; all operations on them are performed by first implicitly extracting them to real first." ... whereas HalfFloat extracts to float, and so should be faster, which is probably one of the main goals here. But since std.numeric was mentioned, why not add HalfFloat there rather than its own separate module?
Jan 29 2013
next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 29 January 2013 at 22:49:02 UTC, Joseph Rushton 
Wakeling wrote:
 But since std.numeric was mentioned, why not add HalfFloat 
 there rather than its own separate module?
+1
Jan 29 2013
prev sibling parent reply "Don" <don nospam.com> writes:
On Tuesday, 29 January 2013 at 22:49:02 UTC, Joseph Rushton 
Wakeling wrote:
 On 01/29/2013 11:27 PM, Iain Buclaw wrote:
 I'm sure this was mentioned before, but what does halffloat 
 have over
 std.numeric.CustomFloat?
"These formats are for storage only; all operations on them are performed by first implicitly extracting them to real first." ... whereas HalfFloat extracts to float, and so should be faster, which is probably one of the main goals here. But since std.numeric was mentioned, why not add HalfFloat there rather than its own separate module?
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.
Jan 30 2013
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
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. 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). -- Simen
Jan 30 2013
parent reply "Don" <don nospam.com> writes:
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'.
Jan 31 2013
next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
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
Jan 31 2013
prev sibling next sibling parent Jens Mueller <jens.k.mueller gmx.de> writes:
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
Jan 31 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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 ... ?
Jan 31 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 31 2013
parent reply "Don" <don nospam.com> writes:
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.
Jan 31 2013
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
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 s=
tuff shouldn't be in there, they are functions from LargePhobos. If we go wi= th 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 a= rgue for SmallPhobos plus that. Everything in Phobos proper has to be mainta= ined as a part of Phobos, after all.=20=
Jan 31 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
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.
Jan 31 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 31 2013
next sibling parent "Paul D. Anderson" <paul.d.removethis.anderson comcast.andthis.net> writes:
I agree that we need a distinct package for numerics, both 
numbers and algorithms.

I proposed a birds-of-a-feather discussion on this topic for 
DConf2013, but haven't heard back yet. If not officially, we can 
still discuss this there, perhaps?

Paul D. Anderson
Feb 01 2013
prev sibling parent reply "Paul D. Anderson" <paul.d.removethis.anderson comcast.andthis.net> writes:
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
Feb 01 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-01 20:15, Paul D. Anderson wrote:

 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.
Isn't this what the whole community is about and what we're already doing. Just not very formal or official. -- /Jacob Carlborg
Feb 01 2013
parent "Paul D. Anderson" <paul.d.removethis.anderson comcast.andthis.net> writes:
On Friday, 1 February 2013 at 20:04:47 UTC, Jacob Carlborg wrote:
 Isn't this what the whole community is about and what we're 
 already doing. Just not very formal or official.
You're right, but what I was looking for was something that actually was more formal. I think the only thing that's missing is someone to keep track of and check up on development efforts. So I'll revise my proposal: I'll volunteer to try to gather information on the projects that are in-work and see what I can do to find their status and gauge their progress. If doing this turns out to be too difficult to manage or of little value I'll announce that and shut up. But if it works, I thik it will add value to our efforts. Paul
Feb 01 2013
prev sibling next sibling parent reply "Zach the Mystic" <reachBUTMINUSTHISzach gOOGLYmail.com> writes:
On Thursday, 31 January 2013 at 15:38:04 UTC, Don wrote:
 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?
Purely by chance I read an article on the blog of Jarrett Billingsley about this topic: http://www.jfbillingsley.com/blog/?p=206
Jan 31 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jan 31, 2013 at 07:53:58PM +0100, Zach the Mystic wrote:
 On Thursday, 31 January 2013 at 15:38:04 UTC, Don wrote:
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?
Purely by chance I read an article on the blog of Jarrett Billingsley about this topic: http://www.jfbillingsley.com/blog/?p=206
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). Even if we don't actually split Phobos up in that way, this may help us reorganize Phobos in a better way. The current flat std hierarchy is slowly approaching the point where it's starting to tear at the seams. We should consider starting a 3rd level of hierarchy sooner rather than later. T -- Help a man when he is in trouble and he will remember you when he is in trouble again.
Jan 31 2013
next sibling parent "Zach the Mystic" <reachBUTMINUSTHISzach gOOGLYmail.com> writes:
On Thursday, 31 January 2013 at 19:04:05 UTC, H. S. Teoh wrote:
 On Thu, Jan 31, 2013 at 07:53:58PM +0100, Zach the Mystic wrote:
 On Thursday, 31 January 2013 at 15:38:04 UTC, Don wrote:
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?
Purely by chance I read an article on the blog of Jarrett Billingsley about this topic: http://www.jfbillingsley.com/blog/?p=206
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). Even if we don't actually split Phobos up in that way, this may help us reorganize Phobos in a better way. The current flat std hierarchy is slowly approaching the point where it's starting to tear at the seams. We should consider starting a 3rd level of hierarchy sooner rather than later. T
I don't know if this is relevant, but I find Jarret's writings to be quite brilliant. He designed a Lua-like language called miniD, based partly on D, but renamed Croc after he left the D community. I feel like I've learned a lot about programming just by reading the spec for his language.
Feb 01 2013
prev sibling parent "Zach the Mystic" <reachBUTMINUSTHISzach gOOGLYmail.com> writes:
On Thursday, 31 January 2013 at 19:04:05 UTC, 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).

 Even if we don't actually split Phobos up in that way, this may 
 help us
 reorganize Phobos in a better way. The current flat std 
 hierarchy is
 slowly approaching the point where it's starting to tear at the 
 seams.
 We should consider starting a 3rd level of hierarchy sooner 
 rather than
 later.


 T
Whoops. Forgot to actually give the site: http://www.jfbillingsley.com/croc/
Feb 01 2013
prev sibling next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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++.
Feb 02 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-02 14:42, Joseph Rushton Wakeling wrote:

 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++.
I can tell you this about Ruby. Its package manager, RubyGems, is one its greatest assets. Just because a library has many dependencies doesn't mean it's badly designed. It could just mean that it's flexible and modular. When Ruby on Rails 3.0 (a web framework for Ruby) was released it had a lot more dependencies than Rails 2.0. One reason was it was more modular designed. They extracted package that could be used without the rest of Rails, like ActiveRecord (database access), ActiveSupport (a general utility package) and so on. Do you rather prefer how most C and C++ library works. They all implement everything from scratch. String classes, containers, algorithms and so on. Or they bundle a third party library within their own library forcing me to use it even though I already have it installed out of the box. -- /Jacob Carlborg
Feb 02 2013
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/2/13 11:50 AM, Jacob Carlborg wrote:
 I can tell you this about Ruby. Its package manager, RubyGems, is one
 its greatest assets.

 Just because a library has many dependencies doesn't mean it's badly
 designed. It could just mean that it's flexible and modular.

 When Ruby on Rails 3.0 (a web framework for Ruby) was released it had a
 lot more dependencies than Rails 2.0. One reason was it was more modular
 designed. They extracted package that could be used without the rest of
 Rails, like ActiveRecord (database access), ActiveSupport (a general
 utility package) and so on.

 Do you rather prefer how most C and C++ library works. They all
 implement everything from scratch. String classes, containers,
 algorithms and so on. Or they bundle a third party library within their
 own library forcing me to use it even though I already have it installed
 out of the box.
I agree with all of the above. While knowing very little about design of package managers, I really appreciate using such (either at Facebook or for other languages). It would be really meaningful to the future of D if a strongly motivated expert in package management would want to propose what it takes to get us where we should be in that regard. As a simple question - what would be an existing design that would be most appropriate for us to take inspiration from? Andrei
Feb 02 2013
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 02/02/2013 05:50 PM, Jacob Carlborg wrote:
 I can tell you this about Ruby. Its package manager, RubyGems, is one its
 greatest assets.
Don't get me wrong. I'm not speaking out against a package library per se, I think that would be an excellent idea. I'm just against the idea of narrowing Phobos' scope too strongly in favour of various things being provided by contributed libraries.
 Just because a library has many dependencies doesn't mean it's badly designed.
 It could just mean that it's flexible and modular.
I agree, but the example I was talking about really was just frustrating and opaque.
 Do you rather prefer how most C and C++ library works. They all implement
 everything from scratch. String classes, containers, algorithms and so on. Or
 they bundle a third party library within their own library forcing me to use it
 even though I already have it installed out of the box.
No, I don't like the typical C/C++ library situation -- that's why I'd like to see as much functionality as possible in a well-designed and supported standard library implementation.
Feb 02 2013
parent "Peter Sommerfeld" <noreply rubrica.at> writes:
Joseph Rushton Wakeling <joseph.wakeling webdrake.net> wrote:

 No, I don't like the typical C/C++ library situation -- that's
 why I'd like to see as much functionality as possible in a well-designed  
 and supported standard library implementation.
As d-newcomer I want to support this! A large standard library is an attractive argument for the language because it makes sure that its features will be supported as the language evolves. Its organization is currently rather confusing and I suggest to seriously think about a deeper nested structure like it has been suggested for std.numeric: std.numeric.~, std.concurrent.~, std.io.~ etc. The pain of transformation is once, to keep it, it is recurring. Peter
Feb 02 2013
prev sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 02/02/2013 02:42 PM, Joseph Rushton Wakeling wrote:
 I've on occasion had cause to call on ....

 A while ago I had cause to call on ....
Oh bugger. Overly verbose _and_ repetitive. :-P
Feb 02 2013
prev sibling parent reply "SomeDude" <lovelydear mailmetrash.com> writes:
On Thursday, 31 January 2013 at 15:38:04 UTC, Don wrote:
 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 am all for a "small" Phobos. And specialized libraries in Deimos, which should get the same level of attention as Phobos.
Feb 02 2013
parent "David Nadlinger" <see klickverbot.at> writes:
On Sunday, 3 February 2013 at 07:43:57 UTC, SomeDude wrote:
 I am all for a "small" Phobos. And specialized libraries in 
 Deimos, which should get the same level of attention as Phobos.
Huh? Deimos is specifically for C headers translated to D. David
Feb 03 2013
prev sibling parent "TommiT" <tommitissari hotmail.com> writes:
On Monday, 28 January 2013 at 23:11:11 UTC, Walter Bright wrote:
 http://www.drdobbs.com/cpp/implementing-half-floats-in-d/240146674
In the heat of coding, I think, the end-user is quite likely to make the honest mistake of writing: HalfFloat h = HalfFloat(1.3f); ...when he should be writing: HalfFloat h = hf!1.3f;
Jan 29 2013