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
