On Mon, Aug 6, 2012 at 5:33 PM, Minas Mina <minas_mina1990@hotmail.co.uk> wrote:

> // calcuated at O(1) woohoo!

>         return cast(ulong)(a * pow(r0, cast(double)n) + b * pow(r1,

I wonder if there is any rounding error going on with these pow, but yes, even better this way.

> double f = sin(0.5); // calculated at compile time or not?
>
> If it is calculated at compile time, how do I do it for my own functions?

sin is a library function, it has no special rights your own function doesn't as far as I know.

I'd say, put an if(__ctfe) in sin:

if (__ctfe)
{
    pragma(msg, "Yep, CT");
    return 2.0;
}
else
{
    // standard sin code
}

And tell us the result :)

Take a look into std.math:
https://github.com/D-Programming-Language/phobos/blob/master/std/math.d

On Monday, 6 August 2012 at 15:56:52 UTC, Namespace wrote:
> Take a look into std.math:
> https://github.com/D-Programming-Language/phobos/blob/master/std/math.d

I found this:

real sin(real x) @safe pure nothrow; /* intrinsic */

And these:

creal sin(creal z) @safe pure nothrow
{
     creal cs = expi(z.re);
     creal csh = coshisinh(z.im);
     return cs.im * csh.re + cs.re * csh.im * 1i;
}

/** ditto */
ireal sin(ireal y) @safe pure nothrow
{
     return cosh(y.im)*1i;
}

I don't see anything about ctfe. Maybe I didn't understand well
and sin is not evaluated at compile time. Can someone clarify
this?

On Monday, 6 August 2012 at 16:17:22 UTC, Minas Mina wrote:
> On Monday, 6 August 2012 at 15:56:52 UTC, Namespace wrote:
>> Take a look into std.math:
>> https://github.com/D-Programming-Language/phobos/blob/master/std/math.d
>
> I found this:
>
> real sin(real x) @safe pure nothrow; /* intrinsic */
>
> And these:
>
> creal sin(creal z) @safe pure nothrow
> {
>      creal cs = expi(z.re);
>      creal csh = coshisinh(z.im);
>      return cs.im * csh.re + cs.re * csh.im * 1i;
> }
>
> /** ditto */
> ireal sin(ireal y) @safe pure nothrow
> {
>      return cosh(y.im)*1i;
> }
>
> I don't see anything about ctfe. Maybe I didn't understand well
> and sin is not evaluated at compile time. Can someone clarify
> this?

Justly, you see a normal runtime function, and a CTFE function is
a normal runtime function(with some restrictions) that can be
interpreted at runtime.

static res = sin(4); //compile time
auto res = sin(4); //runtime

On Monday, 6 August 2012 at 16:21:04 UTC, Eyyub wrote:
> Justly, you see a normal runtime function, and a CTFE function is
> a normal runtime function(with some restrictions) that can be
> interpreted at runtime.
*compile time, sorry

On Mon, Aug 6, 2012 at 6:17 PM, Minas Mina <minas_mina1990@hotmail.co.uk> wrote:

> I found this:
>
> real sin(real x) @safe pure nothrow; /* intrinsic */

> I don't see anything about ctfe. Maybe I didn't understand well and sin is not evaluated at compile time. Can someone clarify this?

Oh, I thought they were implemented as polynomial approximations.

Never mind, you can test it with any function:

int foo(int i)
{
    if (__ctfe)
    {
        pragma(msg, "CT");
        return -1;
    }
    else
        return 1;
}

void main()
{
    auto i = foo(0);
    static j = foo(0);
    writeln(i); // 1
    writeln(j); // -1
}

So, auto i doesn't provoke CT-evaluation (else it'd be -1).

On Mon, 2012-08-06 at 17:21 +0200, Philippe Sigaud wrote: […]
> Well, you're using the worst possible algorithm to calculate Fibonacci
> (exponential time), so it's no wonder it's taking foverer :)

Memoization is a bit of a help it destroying that problem.

[…]
> Don't try fib(100) at runtime!

Of course the real problem is that quants and such folk often need values of Fibonacci and factorial that cannot be held in an hardware integer.
-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Mon, Aug 6, 2012 at 8:37 PM, Russel Winder <russel@winder.org.uk> wrote:
> On Mon, 2012-08-06 at 17:21 +0200, Philippe Sigaud wrote: […]
>> Well, you're using the worst possible algorithm to calculate Fibonacci
>> (exponential time), so it's no wonder it's taking foverer :)
>
> Memoization is a bit of a help it destroying that problem.

Memoization at compile-time is a bit tricky, though.

Which reminds me... What if someone wants Fibonacci values depending on a runtime value, but would like them to be calculated really fast? Use the "Sabalausky Trick" (aka Nick's Run-Time to Compile-Time Time Machine): Pregenerate desired values at compile-time (for example here in an array), to get O(1) fibonacci access at runtime.

On 8/6/12, Philippe Sigaud <philippe.sigaud@gmail.com> wrote:
> Which reminds me... What if someone wants Fibonacci values depending on a runtime value, but would like them to be calculated really fast?

I think TDPL had some use of the memoize template and used fibonacci as sample code. It even used it internally for a recursive call. It's somewhere in the book.

Am Mon, 06 Aug 2012 14:21:37 +0200
schrieb "Minas Mina" <minas_mina1990@hotmail.co.uk>:

> I want to write a fibonacci(n) function that calculates the
> result.
> a) if n is known at compile time, use a template
> b) if not, use a normal function
> 
> I know how to write a template version:
> template fib(ulong n)
> {
> 	static if( n < 2 )
> 		const fib = n;
> 	else
> 		const fib = fib!(n-1) + fib!(n-2);
> }
> 
> But how can I 'know' if n is known at compile time to make it use the other version? (which I won't post 'cause it is fairly easy).

That's easy: http://dpaste.dzfl.pl/521f47a0

-- 
Marco