Dear,
1/

i would like have a code near as this haskell code:

fibs = 1 : 1 : zipWith (+) fibs (tail fibs)

main = do
	print $ sum (filter even (takeWhile (<4000000) fibs))




Ii know in D:
- auto fib = recurrence!("a[n-1] + a[n-2]")(1, 1);
- std.algorithm.until
- std.algorithm.filler
- std.algorithm.reduce
- std.range.InputRange.popFront
- std.range.take
- std.array.appender

      but i do not see how to these feature together to have a code
close to the haskell code.

Someone?

2/
Someone  know to generate a fibonacci list directly with a lambda
syyntax and not from string ("a[n-1] + a[n-2]") ?

thanks

On Mon, 06 Aug 2012 11:53:18 +0200, bioinfornatics <bioinfornatics@gmail.com> wrote:

> Dear,
> 1/
>
> i would like have a code near as this haskell code:
>
> fibs = 1 : 1 : zipWith (+) fibs (tail fibs)
>
> main = do
> 	print $ sum (filter even (takeWhile (<4000000) fibs))
>
>
>
>
> Ii know in D:
> - auto fib = recurrence!("a[n-1] + a[n-2]")(1, 1);
> - std.algorithm.until
> - std.algorithm.filler
> - std.algorithm.reduce
> - std.range.InputRange.popFront
> - std.range.take
> - std.array.appender
>
>        but i do not see how to these feature together to have a code
> close to the haskell code.
>
> Someone?
>
> 2/
> Someone  know to generate a fibonacci list directly with a lambda
> syyntax and not from string ("a[n-1] + a[n-2]") ?
>
> thanks

This is what you want, isn't it?

recurrence!((a,n)=>a[n-1]+a[n-2])(1,1).until!(a=>a>=40000)()



-- 
Simen

On Mon, 06 Aug 2012 11:59:29 +0200, Simen Kjaeraas <simen.kjaras@gmail.com> wrote:

> This is what you want, isn't it?
>
> recurrence!((a,n)=>a[n-1]+a[n-2])(1,1).until!(a=>a>=40000)()

That is, the meat of it. The full line:

writeln(recurrence!((a,n)=>a[n-1]+a[n-2])(1,1).until!(a=>a>=40000)().filter!(a=>a%2==0)().reduce!((a,b)=>a+b)())

-- 
Simen

On Mon, 2012-08-06 at 12:15 +0200, Simen Kjaeraas wrote: […]
> writeln(recurrence!((a,n)=>a[n-1]+a[n-2])(1,1).until!(a=>a>=40000)().filter!(a=>a%2==0)().reduce!((a,b)=>a+b)())

Do a JVM backend to D and D could wipe the floor with Scala :-)

-- 
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 Monday, 6 August 2012 at 13:10:50 UTC, Russel Winder wrote:
> On Mon, 2012-08-06 at 12:15 +0200, Simen Kjaeraas wrote:
> […]
>> writeln(recurrence!((a,n)=>a[n-1]+a[n-2])(1,1).until!(a=>a>=40000)().filter!(a=>a%2==0)().reduce!((a,b)=>a+b)())
>
> Do a JVM backend to D and D could wipe the floor with Scala :-)

Why is that? Can't Scala do the same?

On Mon, 2012-08-06 at 15:13 +0200, Tobias Pankrath wrote:
> On Monday, 6 August 2012 at 13:10:50 UTC, Russel Winder wrote:
> > On Mon, 2012-08-06 at 12:15 +0200, Simen Kjaeraas wrote: […]
> >> writeln(recurrence!((a,n)=>a[n-1]+a[n-2])(1,1).until!(a=>a>=40000)().filter!(a=>a%2==0)().reduce!((a,b)=>a+b)())
> >
> > Do a JVM backend to D and D could wipe the floor with Scala :-)
> 
> Why is that? Can't Scala do the same?

Scala can definitely do the same, possibly more, but it's syntax gets annoying and compilation time is horrendous. Of course it will have an Eclipse plugin that works fairly soon, which will probably cement it's standing as successor to Java.

-- 
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 3:17 PM, Russel Winder <russel@winder.org.uk> wrote:

>> > Do a JVM backend to D and D could wipe the floor with Scala :-)
>>
>> Why is that? Can't Scala do the same?
>
> Scala can definitely do the same, possibly more, but it's syntax gets annoying and compilation time is horrendous.

>From what I know of Scala, for the OP qustion the syntax would be
about the same as D (that is, far more cluttered than Haskell). About compilation time, I didn't know that. Do you happen to have some personal experience on this? (this is not a quip, just an honest question).

What I'd like to know and may test myself is: is there any speed difference in this functional-oriented D code and a more standard (C-ish) way to obtain the same result?


As for the OP question, use std.algo.until as your takeWhile, as Simen showed. I also coded takeWhile in a D a few years ago, it's not difficult and is a good exercice in range coding.

On Mon, Aug 6, 2012 at 5:32 PM, Philippe Sigaud <philippe.sigaud@gmail.com> wrote:

> What I'd like to know and may test myself is: is there any speed difference in this functional-oriented D code and a more standard (C-ish) way to obtain the same result?

Here it is. Answer: no noticeable difference. The functional way also
works at CT, that's great.
Of course, the functional code is (to my eyes) easier to read, easier
to debug and easier to modify.

import std.stdio;
import std.algorithm;
import std.range;

void main()
{
	enum max = int.max;

	// C-ish
	long a,b, temp, sum;
	a = 1;
	b = 1;
	while ( b < max)
	{
		if (b % 2 == 0) sum += b; // filter and sum
		temp = b;
		b = a + b;
		a = temp;
	}
	writeln(sum);

	// Haskell-ish
	writeln(recurrence!((a,n) => a[n-1]+a[n-2])(1L,1L)
	        .until!(a => a >= max)()
			.filter!(a => a%2 == 0)()
			.reduce!((a,b) => a+b)());

	// Works at CT too!
	pragma(msg, recurrence!((a,n) => a[n-1]+a[n-2])(1L,1L)
	        .until!(a => a >= max)()
			.filter!(a => a%2 == 0)()
			.reduce!((a,b) => a+b)());

}

On Mon, 06 Aug 2012 17:49:19 +0200, Philippe Sigaud <philippe.sigaud@gmail.com> wrote:

> On Mon, Aug 6, 2012 at 5:32 PM, Philippe Sigaud
> <philippe.sigaud@gmail.com> wrote:
>
>> What I'd like to know and may test myself is: is there any speed
>> difference in this functional-oriented D code and a more standard
>> (C-ish) way to obtain the same result?
>
> Here it is. Answer: no noticeable difference.

Great, but is that only because it goes too quickly anyways?

I changed it a bit to use BigInt in both places, and for a max of 2^512,
I got the following numbers, fairly consistently:

C:       139288 ns
Haskell: 165104 ns

About 20% difference. Not bad.


> The functional way also works at CT, that's great.
> Of course, the functional code is (to my eyes) easier to read, easier
> to debug and easier to modify.

Indeed.


-- 
Simen