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

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

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

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

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

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;

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

Another post: http://www.dannyarends.nl/?viewDetailed=00030

Again all comments are welcome
Danny Arends

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

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.