www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Wrote a blog post about CTFE and D

reply "Danny Arends" <Danny.Arends gmail.com> writes:
I wrote a blog post about the stuff I've been doing last weekend 
using CTFE.
All comments are welcome, you can find the blog post at:

http://www.dannyarends.nl/index.cgi?viewDetailed=00029

Danny Arends
http://www.dannyarends.nl
Aug 30 2012
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Danny Arends:

 http://www.dannyarends.nl/index.cgi?viewDetailed=00029
struct Coord(T : float){ T[] d = [1.0, 0.0]; Maybe better ==> struct Coord(T) if (isFloatingPoint!T) { T[2] d = [1.0, 0.0]; (isFloatingPoint is in std.traits) Bye, bearophile
Aug 30 2012
parent "Danny Arends" <Danny.Arends gmail.com> writes:
Thanks for the feedback, I'll update it..

I was thinking to remove the struct all together, but when doing 
the rotation matrices its actually more clean / useful to have 
structures.

Danny Arends
http://www.dannyarends.nl

On Thursday, 30 August 2012 at 11:25:55 UTC, bearophile wrote:
 Danny Arends:

 http://www.dannyarends.nl/index.cgi?viewDetailed=00029
struct Coord(T : float){ T[] d = [1.0, 0.0]; Maybe better ==> struct Coord(T) if (isFloatingPoint!T) { T[2] d = [1.0, 0.0]; (isFloatingPoint is in std.traits) Bye, bearophile
Aug 30 2012
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 30-Aug-12 13:41, Danny Arends wrote:
 I wrote a blog post about the stuff I've been doing last weekend using
 CTFE.
 All comments are welcome, you can find the blog post at:

 http://www.dannyarends.nl/index.cgi?viewDetailed=00029

 Danny Arends
 http://www.dannyarends.nl
Nice read. A couple of nits: Use T[2] for fixed arrays like Cord one. It also helps tremendously for lookup speed of the final lookup table. Thus instead of array of arrays you'd have an array of pairs i.e. 2 indirections ---> 1 indirection and cache friendly layout. And an awful typo in degreeloop function I think: pure int degreeloop(int deg){ while(deg < 0 || deg >= 360){ if(deg < 0) deg += 360; if(deg >= 0) deg -= 360; //shouldn't it be >= 360 ?? } return deg; } -- Olshansky Dmitry
Aug 30 2012
parent reply "Danny Arends" <Danny.Arends gmail.com> writes:
On Thursday, 30 August 2012 at 16:27:05 UTC, Dmitry Olshansky 
wrote:
 On 30-Aug-12 13:41, Danny Arends wrote:
 I wrote a blog post about the stuff I've been doing last 
 weekend using
 CTFE.
 All comments are welcome, you can find the blog post at:

 http://www.dannyarends.nl/index.cgi?viewDetailed=00029

 Danny Arends
 http://www.dannyarends.nl
Nice read. A couple of nits: Use T[2] for fixed arrays like Cord one. It also helps tremendously for lookup speed of the final lookup table. Thus instead of array of arrays you'd have an array of pairs i.e. 2 indirections ---> 1 indirection and cache friendly layout.
You're right about that, I made it initially to be variable length. because I was also planning on storing the other ones (tan, cosh, sinh) but didn't get around to that yet.
 And an awful typo in degreeloop function I think:
 pure int degreeloop(int deg){
   while(deg < 0 || deg >= 360){
     if(deg < 0) deg += 360;
     if(deg >= 0) deg -= 360; //shouldn't it be >= 360 ??
   }
   return deg;
 }
Thanks for the spot ;) it actually doesn't matter seeing as the while condition already forced it to be out of array bounds. I could just as well use an else Thanks for the feedback ! And I'll create a blog post about the rotation matrices also when I finish off that code Danny Arends http://www.dannyarends.nl
Aug 30 2012
parent reply Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Thu, Aug 30, 2012 at 7:10 PM, Danny Arends <Danny.Arends gmail.com> wrote:

 I wrote a blog post about the stuff I've been doing last weekend using
 CTFE.
 All comments are welcome, you can find the blog post at:

 http://www.dannyarends.nl/index.cgi?viewDetailed=00029
Nice article, Danny! A few remarks: degToRad!(float,int) 45 First, it seems like you missed a parenthesis pair? The compiler will be able to determine V in degToRad, you can call it like this: degToRad!(float)(45) Following bearophile's use of isFloatingPoint, you can use a default value, if that's what you need most of the time: import std.traits; pure U degToRad(U = float, V)(in V deg) if (isFloatingPoint!U && isIntegral!V) { return (deg * PI) / 180.0; } Then, to call it: degToRad(45) => automatically expand to detToRad!(float,int)(45) And the same type deduction for cordic gives you cordic( degToRad(45) ); instead of cordic!(float)(degToRad!(float,int) 45); In gen_trigonometric, I think the float call should be a T: result ~= cordic!T(degToRad!(float,int)(i), iter); => result ~= cordic( degToRad!(T)(i), iter); And, since you know the result's size in advance, you might want to generate it at once: T[2][] result = new (T[2][])(iter); foreach(i; 0 .. 360) result[i] = cordic(degToRad!(T)(i), iter); return result; (no need for braces for a one-expression foreach) Or even, using map: import std.algorithm, std.array; return map!( i => cordic(degToRag!(T)(i), iter) )(result).array;
Aug 30 2012
parent reply "Danny Arends" <Danny.Arends gmail.com> writes:
On Thursday, 30 August 2012 at 17:40:16 UTC, Philippe Sigaud 
wrote:
 On Thu, Aug 30, 2012 at 7:10 PM, Danny Arends 
 <Danny.Arends gmail.com> wrote:

 I wrote a blog post about the stuff I've been doing last 
 weekend using
 CTFE.
 All comments are welcome, you can find the blog post at:

 http://www.dannyarends.nl/index.cgi?viewDetailed=00029
Nice article, Danny! A few remarks: degToRad!(float,int) 45 First, it seems like you missed a parenthesis pair?
Indeed, fixed
 The compiler will be able to determine V in degToRad, you can 
 call it like this:

 degToRad!(float)(45)

 Following bearophile's use of isFloatingPoint, you can use a 
 default
 value, if that's what you need most of the time:

 import std.traits;
 pure U degToRad(U = float, V)(in V deg) if (isFloatingPoint!U 
 && isIntegral!V)
 { return (deg * PI) / 180.0; }
Interesting, I knew about defaults but I tend to forget about them, when I can use them...
 Then, to call it:

 degToRad(45) => automatically expand to detToRad!(float,int)(45)

 And the same type deduction for cordic gives you

 cordic( degToRad(45) );

 instead of

 cordic!(float)(degToRad!(float,int) 45);

 In gen_trigonometric, I think the float call should be a T:

 result ~= cordic!T(degToRad!(float,int)(i), iter);
Indeed, fixed !
 =>

 result ~= cordic( degToRad!(T)(i), iter);

 And, since you know the result's size in advance, you might 
 want to
 generate it at once:

 T[2][] result = new (T[2][])(iter);
 foreach(i; 0 .. 360)
     result[i] = cordic(degToRad!(T)(i), iter);
 return result;

 (no need for braces for a one-expression foreach)
Again valid point. Though the compile time benefits will be minor with all the memory CTFE is gobbling up anyway.
 Or even, using map:

 import std.algorithm, std.array;

 return map!( i => cordic(degToRag!(T)(i), iter) )(result).array;
I like the map syntax, that's prob. because I've got an R background where we have lapply (1D) and apply (2D) Still I don't seem to get used to the => syntax... Thanks for the feedback, Gr, Danny If I get round to it I'll also update the code to use default return types. Though I like being explicit with types, if you got them flaunt them...
Aug 30 2012
parent reply "Danny Arends" <Danny.Arends gmail.com> writes:
Another post: http://www.dannyarends.nl/?viewDetailed=00030

Again all comments are welcome
Danny Arends
Aug 31 2012
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Danny Arends:

 Another post: http://www.dannyarends.nl/?viewDetailed=00030
pure mat!(T)[3][] gen_rotationmatrices(T = float)(){ I suggest to write something like this (note the casing and other details): Mat!T[3][] genRotationMatrices(T = float)() pure { tmp += mixin('A[i][k] '~op~' B[k][j]'); This seems OK, but it looks a bit convoluted. Maybe something like this works (untested): tmp += A[i][k].opBinary!op(B[k][j]); pure auto yaw(int deg){ deg = degreeloop(deg); return cast(matrix)rmatrix[deg][YAW]; } I suggest generally to try to avoid casts, where possible. Bye, bearophile
Aug 31 2012
parent "Danny Arends" <Danny.Arends gmail.com> writes:
On Saturday, 1 September 2012 at 00:47:20 UTC, bearophile wrote:
 Danny Arends:

 Another post: http://www.dannyarends.nl/?viewDetailed=00030
pure mat!(T)[3][] gen_rotationmatrices(T = float)(){ I suggest to write something like this (note the casing and other details): Mat!T[3][] genRotationMatrices(T = float)() pure {
Again many thanks for the feedback. I'll fix this indeed :)
 tmp += mixin('A[i][k] '~op~' B[k][j]');

 This seems OK, but it looks a bit convoluted. Maybe something 
 like this works (untested):

 tmp += A[i][k].opBinary!op(B[k][j]);
I'll test it, though I wanted to show off the mixin concept, I put a hyper link to the Dlang information page about mixins. So that people can read up on what they are.
 pure auto yaw(int deg){
    deg = degreeloop(deg);
    return cast(matrix)rmatrix[deg][YAW];
 }

 I suggest generally to try to avoid casts, where possible.
Do you have a suggestion to get around this cast ?
 Bye,
 bearophile
Gr, Danny Arends
Sep 01 2012
prev sibling next sibling parent reply "Rene Zwanenburg" <renezwanenburg gmail.com> writes:
On Thursday, 30 August 2012 at 09:41:43 UTC, Danny Arends wrote:
 I wrote a blog post about the stuff I've been doing last 
 weekend using CTFE.
 All comments are welcome, you can find the blog post at:

 http://www.dannyarends.nl/index.cgi?viewDetailed=00029

 Danny Arends
 http://www.dannyarends.nl
It's always good to see someone write about the unusual features of D, but I have a non-D related point of criticism regarding your post: lookup tables for trig functions are a thing from the nineties. I'm not trying to make some bad 'the nineties called' joke ;). Since at least a decade, calling the trig functions will usually be significantly faster in a real application than a lookup table. Simple benchmarks may show a performance improvement, but that's because the table still resides in the L1 cache. A real application will often have to read the table from main memory, which is orders of magnitude slower than simply doing the computation. Use caching for data which is really expensive to calculate. For relatively trivial stuff like sin(), just calculate it during runtime.
Aug 31 2012
next sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Sat, Sep 1, 2012 at 3:46 AM, Rene Zwanenburg
<renezwanenburg gmail.com> wrote:

 Use caching for data which is really expensive to calculate. For relatively
 trivial stuff like sin(), just calculate it during runtime.
On a somewhat related note, I remember realizing a few years ago that it was faster to generate the first thousands of primes on the fly than to pre-generate them and read them from a file.
Sep 01 2012
prev sibling parent "Danny Arends" <Danny.Arends gmail.com> writes:
On Saturday, 1 September 2012 at 01:46:38 UTC, Rene Zwanenburg 
wrote:
 On Thursday, 30 August 2012 at 09:41:43 UTC, Danny Arends wrote:
 I wrote a blog post about the stuff I've been doing last 
 weekend using CTFE.
 All comments are welcome, you can find the blog post at:

 http://www.dannyarends.nl/index.cgi?viewDetailed=00029

 Danny Arends
 http://www.dannyarends.nl
It's always good to see someone write about the unusual features of D, but I have a non-D related point of criticism regarding your post: lookup tables for trig functions are a thing from the nineties.
Thanks for reply! I see you got the point from the post :) The stuff I implemented in CTFE is course many times worse then the std.math sine and cosine functions (they fall back to single operators in ASM)I could have just as well done: pure T[2][] gen_trigonometric(){ T[2][] result = new T[2][](360); foreach(i; 0 .. 360){ result[i] = [sin(x), cos(x)]; } return result; } But well then showing off D's feature to call (polymorphic) user functions in CTFE is then less clear :)
 I'm not trying to make some bad 'the nineties called' joke ;). 
 Since at least a decade, calling the trig functions will 
 usually be significantly faster in a real application than a 
 lookup table. Simple benchmarks may show a performance 
 improvement, but that's because the table still resides in the 
 L1 cache. A real application will often have to read the table 
 from main memory, which is orders of magnitude slower than 
 simply doing the computation.

 Use caching for data which is really expensive to calculate. 
 For relatively trivial stuff like sin(), just calculate it 
 during runtime.
I don't try to advocating people start using look-up tables for sine and cosine. It's an example to show how cool I think CTFE is for stuff like this. I could have also taken the much more used example of CTFE calculating primes. However in that case (primes) it is not useful to have a user function doing it for floats, doubles and reals. :-P Gr, Danny Arends
Sep 01 2012
prev sibling next sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 08/30/2012 02:41 AM, Danny Arends wrote:
 I wrote a blog post about the stuff I've been doing last weekend using
 CTFE.
 All comments are welcome, you can find the blog post at:

 http://www.dannyarends.nl/index.cgi?viewDetailed=00029

 Danny Arends
 http://www.dannyarends.nl
Thanks for the blog posts. I wanted to mention that the community has been moving away from the D 1 and D 2 namings. D1 is being discontinued by the end of the year and D2 wants to be called simply D, like in the subject of this thread. ;) Ali
Sep 03 2012
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/30/12 11:41 AM, Danny Arends wrote:
 I wrote a blog post about the stuff I've been doing last weekend using
 CTFE.
 All comments are welcome, you can find the blog post at:

 http://www.dannyarends.nl/index.cgi?viewDetailed=00029
On reddit: http://www.reddit.com/r/programming/comments/zcd19/using_ds_compiletime_evaluation_to_speed_up_sine/ Andrei
Sep 04 2012
parent "Danny Arends" <Danny.Arends gmail.com> writes:
Thanks for redditting, also put the second blog post on there

http://redd.it/zcj4p

I'll update both blogs (due to previous comments )as soon as I 
get round 2 it.

On Tuesday, 4 September 2012 at 16:55:14 UTC, Andrei Alexandrescu 
wrote:
 On 8/30/12 11:41 AM, Danny Arends wrote:
 I wrote a blog post about the stuff I've been doing last 
 weekend using
 CTFE.
 All comments are welcome, you can find the blog post at:

 http://www.dannyarends.nl/index.cgi?viewDetailed=00029
On reddit: http://www.reddit.com/r/programming/comments/zcd19/using_ds_compiletime_evaluation_to_speed_up_sine/ Andrei
Sep 04 2012