Thread overview | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
August 30, 2012 Wrote a blog post about CTFE and D | ||||
---|---|---|---|---|
| ||||
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 |
August 30, 2012 Re: Wrote a blog post about CTFE and D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Danny Arends | 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
|
August 30, 2012 Re: Wrote a blog post about CTFE and D | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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 |
August 30, 2012 Re: Wrote a blog post about CTFE and D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Danny Arends | 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 |
August 30, 2012 Re: Wrote a blog post about CTFE and D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dmitry Olshansky | 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 |
August 30, 2012 Re: Wrote a blog post about CTFE and D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Danny Arends | 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; |
August 30, 2012 Re: Wrote a blog post about CTFE and D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Philippe Sigaud | 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... |
August 31, 2012 Yaw, Pitch and Roll with D 2.0 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Danny Arends | Another post: http://www.dannyarends.nl/?viewDetailed=00030 Again all comments are welcome Danny Arends |
September 01, 2012 Re: Yaw, Pitch and Roll with D 2.0 | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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
|
September 01, 2012 Re: Wrote a blog post about CTFE and D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Danny Arends | 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.
|
Copyright © 1999-2021 by the D Language Foundation